Spaghetti code is a pejorative term for source code
Ravioli:
Ravioli code is a type of computer program structure, characterized by a number of small and (ideally) loosely-coupled software components. The term is in comparison with spaghetti code, comparing program structure to pasta;
It's comparing them. It isn't saying it's an anti-pattern.
But I agree. The article is confusing. The problem is not with ravioli analogy but with the wikipedia article structure itself. It starts calling Spaghetti as a bad practice, then says some examples and after that say something about Ravioli code.
EDIT: They improved the article. Is an anti-pattern because
While generally desirable from a coupling and cohesion perspective, overzealous separation and encapsulation of code can bloat call stacks and make navigation through the code for maintenance purposes more difficult.
I'd say it's pretty obvious Ravioli code and Lasagna code are both pejorative terms - being intentionally placed alongside their fellow pasta simile 'spaghetti code' - and both terms describe real world anti-patterns. Some code is very time-consuming to maintain and very prone to failure simply because it is broken down into so many separate sub-processes - that is ravioli code. Some code has so many layers of abstraction that it becomes very difficult to implement a change to it and/or understand at what level a failure is occurring - that is lasagna code. The only practical way to make a change to lasagna code is often to simply bypass the layers and write the straightforward code that does the job. I have to maintain some ravioli code, but in general such code suffers from its convolution and fails to find widespread use, so there are few examples of it that we would all be familiar with. By contrast, lasagna code is everywhere at the moment. I like to think I don't write any pasta code myself, but you can at least follow a string of spaghetti...
It's listed in the page of Spaghetti code but that doesn't mean it's a bad thing. It's there because this is a relevant term and not important enough to have its own page.
The problem is that it tends to lead to functions (methods, etc.) without true coherence, and it often leaves the code to implement even something fairly simple scattered over a very large number of functions. Anyone having to maintain the code has to understand how all the calls between all the bits work, recreating almost all the badness of Spaghetti Code except with function calls instead of GOTO. ...
Pretty much the only reason "ravioli code" has survived as a phrase is because programmers have an innate sense of humor. Try as I might - and believe me, I've tried - it's really hard to come up with an example of object oriented code that was both (a) packaged such that it was really hard to navigate in the same meta-sense that "spaghetti code" is hard to navigate, and (b) reflected a frequent anti-pattern in coding practice.
The best example of "ravioli code" I can come up with is a multitude of classes, each tightly packaged, but where it's really hard to dig out where the main flow of execution is. Neural network applications might exhibit this, but that's sort of the point. A more mundane example would be UI code that is very heavily event-oriented, but again, it's hard to go overboard with that - if anything, most UI code isn't event-driven enough.
The problem is that different people use the term "ravioli code" to mean different things.
A reasonable number of reasonably small components is good. A huge pile of tiny components with no apparent overall structure is not so good.
Loosely coupled components are good. Components that hide their interdependencies in order to look loosely coupled are not so good.
Being able to see the relationship between different components is actually a good thing.
Most code bases have the opposite problem though, so moving towards more modularity is usually a good thing. I expect most folks have never even seen "ravioli code" in the bad sense. In practice, it tends to look more like chopped ravioli (where what should be a module is split across multiple "modules" -- none of which make sense on their own, but only in combination with their corresponding other parts), or like ravioli cooked without enough water (so you end up with a giant blob of "modules" all stuck together).
TODO: Write a "Hello world" program as ~100 modules to demonstrate overmodularity.
TODO2: Attempt to build a bridge out of truckloads of ravioli to demonstrate suboptimal structural characteristics.
If you apply a dogmatic rule that all classes in all projects must be loosely coupled regardless of any reason, then I can see there being a lot of potential problems.
You could spin your wheels trying to make a perfectly fine application more and more and more loosely coupled without ever actually adding any value to it.
Let me hasten to add, though, that I think that we should all aim towards loosely coupled classes, components, etc
It's not necessarily, is it? The Wikipedia article doesn't describe it as bad. A number of loosely-coupled software components, where the size and number of these components is sensible in relation to the problem domain, sounds pretty ideal to me.
In fact, if you look up other definitions of ravioli code, you'll find it described as the ideal software design pattern - I still prefer the caveat that the size and number need to be appropriate.
发布评论
评论（8）
意大利面：
：
这是在比较他们。这并不是说这是一种反模式。
但我同意。这篇文章令人困惑。问题不在于馄饨类比，而在于维基百科文章结构本身。它首先将 Spaghetti 称为不好的做法，然后说了一些示例，然后说了一些有关 Ravioli 代码的内容。
编辑：他们改进了这篇文章。是一个反模式，因为
Spaghhetti:
Ravioli:
It's comparing them. It isn't saying it's an anti-pattern.
But I agree. The article is confusing. The problem is not with ravioli analogy but with the wikipedia article structure itself. It starts calling Spaghetti as a bad practice, then says some examples and after that say something about Ravioli code.
EDIT: They improved the article. Is an anti-pattern because
我想说，很明显，Ravioli 代码和 Lasagna 代码都是贬义术语 - 故意与它们的意大利面明喻“意大利面条代码”放在一起 - 并且这两个术语都描述了现实世界的反模式。有些代码维护起来非常耗时，并且很容易失败，因为它被分解为许多单独的子流程 - 这就是馄饨代码。有些代码具有如此多的抽象层，以至于很难对其进行更改和/或理解在哪个级别发生故障 - 这就是烤宽面条代码。更改烤宽面条代码的唯一实用方法通常是简单地绕过各层并编写完成工作的简单代码。我必须维护一些馄饨代码，但一般来说，此类代码因其卷积而未能得到广泛使用，因此我们都熟悉的示例很少。相比之下，烤宽面条代码目前无处不在。
我喜欢认为我自己不写任何意大利面代码，但你至少可以跟踪一串意大利面......
I'd say it's pretty obvious Ravioli code and Lasagna code are both pejorative terms - being intentionally placed alongside their fellow pasta simile 'spaghetti code' - and both terms describe real world anti-patterns. Some code is very time-consuming to maintain and very prone to failure simply because it is broken down into so many separate sub-processes - that is ravioli code. Some code has so many layers of abstraction that it becomes very difficult to implement a change to it and/or understand at what level a failure is occurring - that is lasagna code. The only practical way to make a change to lasagna code is often to simply bypass the layers and write the straightforward code that does the job. I have to maintain some ravioli code, but in general such code suffers from its convolution and fails to find widespread use, so there are few examples of it that we would all be familiar with. By contrast, lasagna code is everywhere at the moment.
I like to think I don't write any pasta code myself, but you can at least follow a string of spaghetti...
它列在 Spaghetti 代码页面中，但这并不意味着它是一件坏事。它在那里是因为这是一个相关术语，但还没有重要到拥有自己的页面。
关于它的不好的一面，谷歌搜索在 http://developers 中给出了评论.slashdot.org/comments.pl?sid=236721&cid=19330355：
你必须判断这是否合理:)。
It's listed in the page of Spaghetti code but that doesn't mean it's a bad thing. It's there because this is a relevant term and not important enough to have its own page.
Regarding the bad side of it, Googling gives a comment in http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355:
You gotta judge if it's reasonable :).
“馄饨代码”作为一个短语得以幸存的唯一原因几乎是因为程序员有与生俱来的幽默感。尽管我可能会尝试 - 并且相信我，我已经尝试过 - 确实很难想出一个面向对象代码的示例，该代码既（a）又被打包，因此很难在相同的元意义上进行导航“意大利面条式代码”很难驾驭，并且 (b) 反映了编码实践中常见的反模式。
我能想到的“馄饨代码”的最好例子是大量的类，每个类都紧密封装，但很难找出主要执行流程在哪里。神经网络应用程序可能会表现出这一点，但这就是重点。一个更普通的例子是 UI 代码非常注重事件导向，但同样，也很难太过分 - 如果有的话，大多数 UI 代码都不够事件驱动足够。
Pretty much the only reason "ravioli code" has survived as a phrase is because programmers have an innate sense of humor. Try as I might - and believe me, I've tried - it's really hard to come up with an example of object oriented code that was both (a) packaged such that it was really hard to navigate in the same meta-sense that "spaghetti code" is hard to navigate, and (b) reflected a frequent anti-pattern in coding practice.
The best example of "ravioli code" I can come up with is a multitude of classes, each tightly packaged, but where it's really hard to dig out where the main flow of execution is. Neural network applications might exhibit this, but that's sort of the point. A more mundane example would be UI code that is very heavily event-oriented, but again, it's hard to go overboard with that - if anything, most UI code isn't event-driven enough.
问题是不同的人使用术语“馄饨代码”来表示不同的事物。
合理数量的相当小的组件是好的。一大堆微小的部件，没有明显的整体结构，这不太好。
松散耦合的组件是好的。为了看起来松散耦合而隐藏其相互依赖关系的组件不太好。
能够看到不同组件之间的关系实际上是一件好事。
不过，大多数代码库都存在相反的问题，因此转向更加模块化通常是一件好事。我想大多数人甚至从未见过不好的“馄饨代码”。在实践中，它往往看起来更像切碎的馄饨（其中应该是一个模块的内容被分割成多个“模块”——它们本身都没有意义，而只有与相应的其他部分组合在一起），或者像馄饨没有足够的水煮熟（所以你最终会得到一大团“模块”都粘在一起）。
TODO：将“Hello world”程序编写为约 100 个模块，以演示过度模块化。
TODO2：尝试用卡车的馄饨建造一座桥梁，以展示次优的结构特性。
The problem is that different people use the term "ravioli code" to mean different things.
A reasonable number of reasonably small components is good. A huge pile of tiny components with no apparent overall structure is not so good.
Loosely coupled components are good. Components that hide their interdependencies in order to look loosely coupled are not so good.
Being able to see the relationship between different components is actually a good thing.
Most code bases have the opposite problem though, so moving towards more modularity is usually a good thing. I expect most folks have never even seen "ravioli code" in the bad sense. In practice, it tends to look more like chopped ravioli (where what should be a module is split across multiple "modules" -- none of which make sense on their own, but only in combination with their corresponding other parts), or like ravioli cooked without enough water (so you end up with a giant blob of "modules" all stuck together).
TODO: Write a "Hello world" program as ~100 modules to demonstrate overmodularity.
TODO2: Attempt to build a bridge out of truckloads of ravioli to demonstrate suboptimal structural characteristics.
如果您应用一条教条规则，即无论出于何种原因，所有项目中的所有类都必须松散耦合，那么我可以看到存在很多潜在问题。
您可以不断尝试使一个完美的应用程序变得越来越松散耦合，而实际上却没有为其增加任何价值。
不过，让我赶紧补充一点，我认为我们都应该以松散耦合的类、组件等为目标
If you apply a dogmatic rule that all classes in all projects must be loosely coupled regardless of any reason, then I can see there being a lot of potential problems.
You could spin your wheels trying to make a perfectly fine application more and more and more loosely coupled without ever actually adding any value to it.
Let me hasten to add, though, that I think that we should all aim towards loosely coupled classes, components, etc
这也不一定，是吗？维基百科的文章并没有将其描述为糟糕。许多松散耦合的软件组件，其中这些组件的大小和数量与问题域相关是合理的，对我来说听起来非常理想。
事实上，如果您查找馄饨代码的其他定义，您会发现它被描述为理想的软件设计模式 - 我仍然更喜欢尺寸和数量需要适当的警告。
It's not necessarily, is it? The Wikipedia article doesn't describe it as bad. A number of loosely-coupled software components, where the size and number of these components is sensible in relation to the problem domain, sounds pretty ideal to me.
In fact, if you look up other definitions of ravioli code, you'll find it described as the ideal software design pattern - I still prefer the caveat that the size and number need to be appropriate.
读这篇文章，意大利面条是一种反模式；但馄饨和烤宽面条并不是反模式。
Reading the article, Spaghetti is an anti-pattern; but Ravioli and Lasagna are not anti-patterns.