Ravioli code - why an anti-pattern? [closed]

Closed. This question is opinion-based. It is not current开发者_JS百科ly accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I recently came across a term 'God object' which was described as an 'anti-pattern'. I'd heard of bad coding practices, but I'd never heard them described thus.

So I headed off to Wikipedia to find out more, and I found that there is an anti-pattern called 'Ravioli code' which is described as being "characterized by a number of small and (ideally) loosely-coupled software components."

I'm puzzled - why is this a bad thing?

---

Spaghhetti:

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.

Regarding the bad side of it, Googling gives a comment in http://developers.slashdot.org/comments.pl?sid=236721&cid=19330355:

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. ...

You gotta judge if it's reasonable :).

---

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.

---

Reading the article, Spaghetti is an anti-pattern; but Ravioli and Lasagna are not anti-patterns.