“In the one and only true way. The object-oriented version of 'Spaghetti code' is, of course, 'Lasagna code'. (Too many layers)." - Roberto Waltman
This week on our show we discuss this quote. Does OOP encourage too many layers in code?
I first saw this phenomenon when doing Java programming. It wasn't a fault of the language itself, but of excessive levels of abstraction. I wrote about this before in the false abstraction antipattern
So what is your story of there being too many layers in the code? Or do you disagree with the quote, or us?
Top comments (12)
Shrek: Object-oriented programs are like onions.
Donkey: They stink?
Shrek: Yes. No.
Donkey: Oh, they make you cry.
Shrek: No.
Donkey: Oh, you leave em out in the sun, they get all brown, start sproutin’ little white hairs.
Shrek: No. Layers. Onions have layers. Object-oriented programs have layers. Onions have layers. You get it? They both have layers.
Donkey: Oh, they both have layers. Oh. You know, not everybody like onions.
Unrelated, but I love both spaghetti and lasagna 😋
I once worked for a project, the codebase had over a hundred classes for quite a simple job to be done. The programmer was no longer available and had almost used every design pattern in the GoF book. We cut it down to ca. 10 classes, hardly losing any functionality. Maybe the unncessary thick lasagne is a symptom of devs looking for a one-size-fits-all solution.
I think there's a very pervasive mentality of "I must to use these tools, design patterns, etc." instead of "I need to solve a problem" and then only use the tools that are really necessary. I'm not sure where it comes from, but there's a kind of brainwashing that people have where they're not happy unless they're applying complicated techniques to accomplish a task. It's a fundamental problem in software development...
I tend to think of layers of inheritance when it comes to OO. I've seen a lot of cases where the developers just build up long chains of inheritance. Nowadays I tend to think that such a static way of sharing code is usually bad. Having a base class with one level of subclasses can be okay, but anything more than that is not a great idea in my book. Composition is almost always a better fit for re-using code.
Inheritance is my preferred option for things that model type hierarchies. For example, widgets in a UI, or literal types in a compiler.
One reason inheritance is over-used is because languages don't offer enough options to do composition correctly. It ends up becoming a lot of boilerplate code. Proper support for mixins would go a long way to reducing bad inheritance.
It is always up to the task. For small programms of course you don't need so many layers, interfaces and so on. For a bigger, more complex one you need it to avoid a lot of issues: code duplications, unreadable code, constant merge conflicts etc.
So build layers only as needed. I would agree with that.
I'm building a personal project as a mean to get something from zero to production for learning purpose, and I am struggling with wiring the front-end with the back. Either I dump all the code in the fetch callback or I use DTOs, two sets of interfaces to describe API data structure and internal data structure... It's a mess really, but I haven't found a good level of compromise.
Thanks for sharing your thoughts!
It's interesting, because a project that gets burned by spaghetti can drift into lasagna code to overcompensate. Still bad, but lasagna code is somewhat more manageable (just a huge headache to reason about).
But having an ungodly combination of those two... I dare not think about it. shudder
Sidenote before I finish listening: I appreciate that I can minimize the browser on mobile and have this keep playing, unlike with others apps(looking at you, YouTube).
Do not build solutions for problems you do not have.
At some point you need to add something because it makes sense.
Until it makes sense, STICK WITH THE SPAGHETTI!!