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?
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.
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.
Reading the article, Spaghetti is an anti-pattern; but Ravioli and Lasagna are not anti-patterns.
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 :).
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
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.