As a Java engineer in the web development industry for several years now, having heard multiple times that X is good because of SOLID principles or Y is bad because it breaks SOLID principles, and having to memorize the “good” ways to do everything before an interview etc, I find it harder and harder to do when I really start to dive into the real reason I’m doing something in a particular way.
One example is creating an interface for every goddamn class I make because of “loose coupling” when in reality none of these classes are ever going to have an alternative implementation.
Also the more I get into languages like Rust, the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.
There are definitely occasions when these principles do make sense, especially in an OOP environment, and they can also make some design patterns really satisfying and easy.
What are your opinions on this?
If you are creating interfaces for classes that will not have second implementation, that sounds suspicious, what kind of classes are you abstracting? Are those classes representing data? I think I would be against creating interfaces for data classes, I would use records and interfaces only in rare circumstances. Are you complaining about abstracting classes with logic, as in services/controllers? Are you creating tests for those? Are you mocking external dependencies for your tests? Because mocks could also be considered different implementations for your abstractions. Some projects I saw definitely had taken SOLID principles and made them SOLID laws… Sometimes it’s an overzealous architect, sometimes it’s a long-lasting project with no original devs left… The fact that you are thinking about it already puts you in front of many others…
SOLID principles are principles for Object Oriented programming so as others pointed out, more functional programming might give you a way out.
If it makes the code easier to maintain it’s good. If it doesn’t make the code easier to maintain it is bad.
Making interfaces for everything, or making getters and setters for everything, just in case you change something in the future makes the code harder to maintain.
This might make sense for a library, but it doesn’t make sense for application code that you can refactor at will. Even if you do have to change something and it means a refactor that touches a lot, it’ll still be a lot less work than bloating the entire codebase with needless indirections every day.
Getters and setters are superfluous in most cases, because you do not actually want to hide complexity from your users.
To use the usual trivial example : if you change your circle’s circumference from a property to a function, I need to know ! You just replaced a memory access with some arithmetic ; depending in my behaviour as a user this could be either great or really bad for my performance.
Exactly this. And to know what code is easy to maintain you have to see how couple of projects evolve over time. Your perspective on this changes as you gain experience.
Yeah, this. Code for the problem you’re solving now, think about the problems of the future.
Knowing OOP principles and patterns is just a tool. If you’re driving nails you’re fine with a hammer, if you’re cooking an egg I doubt a hammer is necessary.
True. Open-closed principal is particularly applicable to library code, but a waste much of the time in a consuming application, where you will be modifying code much more.
Really well said!
I remember the recommendation to use a typedef (or #define 😱) for integers, like INT32.
If you like recompile it on a weird CPU or something I guess. What a stupid idea. At least where I worked it was dumb, if someone knows any benefits I’d gladly hear it!
We had it because we needed to compile for Windows and Linux on both 32 and 64 bit processors. So we defined all our Int32, Int64, uint32, uint64 and so on. There were a bunch of these definitions within the core header file with #ifndef and such.
But you can use 64 bits int on a 32 bits linux, and vice versa. I never understood the benefits from tagging the stuff. You gotta go so far back in time where an int isn’t compiled to a 32 bit signed int too. There were also already long long and size_t… why make new ones?
Readability maybe?
It was a while ago indeed, and readability does play a big role. Also, it becomes easier to just type it out. Of course auto complete helps, but it’s just easier.
Very often you need to choose a type based on the data it needs to hold. If you know you’ll need to store numbers of a certain size, use an integer type that can actually hold it, don’t make it dependent on a platform definition. Always using
intcan lead to really insidious bugs where a function may work on one platform and not on another due to overfloeShow me one.
I mean I have worked on 16bits platforms, but nobody would use that code straight out of the box on some other incompatible platform, it doesn’t even make sense.
Emulation code where you expect unsigned integers to wrap around instead of being UB is a good example, because it was guaranteed for programmers working on the emulated systems.
That’s just how it works and have always worked. You can use an unsigned char on a 64 bit system and it’ll behave like on the Commodore 64. I don’t understand what you are trying to show.
Basically anything low level. When you need a byte, you also don’t use a
int, you use auint8_t(reminder thatcharis actually not defined to be signed or unsigned, “Plain char may be signed or unsigned; this depends on the compiler, the machine in use, and its operating system”). Any time you need to interact with another system, like hardware or networking, it is incredibly important to know how many bits the other side uses to avoid mismatching.For purely the size of an
int, the most famous example is the Ariane 5 Spaceship Launch, there an integer overflow crashed the space ship. OWASP (the Open Worldwide Application Security Project) lists integer overflows as a security concern, though not ranked very highly, since it only causes problems when combined with buffer accesses (using user input with some arithmetic operation that may overflow into unexpected ranges).And the byte wasn’t obliged to have 8 bits.
Nice example, but I’d say it’skind of niche 😁 makes me remember the underflow in a video game, making the most peaceful npc becoming a warmongering lunatic. But that would not have been helped because of defines.
If you’re directly interacting with any sort of binary protocol, i.e. file formats, network protocols etc., you definitely want your variable types to be unambiguous. For future-proofing, yes, but also because because I don’t want to go confirm whether I remember correctly that
longis the same size asint.There’s also clarity of meaning;
unsigned long longis a noisy monstrosity,uint64_tconveys what it is much more cleanly.charis great if it’s representing text characters, but if you have a byte array of binary data, using a type alias helps convey that.And then there are type aliases that are useful because they have different sizes on different platforms like
size_t.I’d say that generally speaking, if it’s not an
intor achar, that probably means the exact size of the type is important, in which case it makes sense to convey that using a type alias. It conveys your intentions more clearly and tersely (in a good way), it makes your code more robust when compiled for different platforms, and it’s not actually more work; that extrayou may need to add pays for itself pretty quickly.So we should not have #defines in the way, right?
Like INT32, instead of “int”. I mean if you don’t know the size you probably won’t do network protocols or reading binary stuff anyways.
uint64_t is good IMO, a bit long (why the _t?) maybe, but it’s not one of the atrocities I’m talking about where every project had its own defines.
“int” can be different widths on different platforms. If all the compilers you must compile with have standard definitions for specific widths then great use em. That hasn’t always been the case, in which case you must roll your own. I’m sure some projects did it where it was unneeded, but when you have to do it you have to do it
So show me two compatible systems where the int has different sizes.
This is folklore IMO, or incompatible anyways.
RPython, the toolchain which is used to build JIT compilers like PyPy, supports Windows and non-Windows interpretations of standard Python
int. This leads to an entire module’s worth of specialized arithmetic. In RPython, the usual approach to handling the size of ints is to immediately stop worrying about it and let the compiler tell you if you got it wrong; an int will have at least seven-ish bits but anything more is platform-specific. This is one of the few systems I’ve used where I have to cast from an int to an int because the compiler can’t prove that the ints are the same size and might need a runtime cast, but it can’t tell me whether it does need the runtime cast.Of course, I don’t expect you to accept this example, given what a whiner you’ve been down-thread, but at least you can’t claim that nobody showed you anything.
Bravo, you found an example!
You’re right, we should start using #define INT32 again…
Incompatible? It is for cross platform code. Wtf are you even talking about
Okay, then give me an example where this matters. If an int hasn’t the same size, like on a Nintendo DS and Windows (wildly incompatible), I struggle to find a use case where it would help you out.
The standard type aliases like
uint64_tweren’t in the C standard library until C99 and in C++ until C++11, so there are plenty of older code bases that would have had to define their own.The use of
to make type aliases never made sense to me. The earliest versions of C didn’t havetypedef, I guess, but that’s like, the 1970s. Anyway, you wouldn’t do it that way in modern C/C++.Iirc, _t is to denote a reserved standard type names.
I’ve seen several codebases that have a typedef or using keyword to map uint64_t to uint64 along with the others, but _t seems to be the convention for built-in std type names.
deleted by creator
The main lie about these principles is that they would lead to less maintenance work.
But go ahead and change your database model. Add a field. Then add support for it to your program’s code base. Let’s see how many parts you need to change of your well-architected enterprise-grade software solution.
Sure, it might be a lot of places, it might not(well designed microservice arch says hi.)
What proper OOP design does is to make the changes required to be predictable and easily documented. Which in turn can make a many step process faster.
I guess it’s possible I’ve been doing OOP wrong for the past 30 years, knowing someone like you has experienced code bases that uphold that promise.
We all have or own experiences.
Mine is that it helps in organization, which makes changes easier.
Right, knowing when to apply the principles is the thing that comes with experience.
If you’ve literally never seen the benefits of abstraction doing OOP for thirty years, I’m not sure what to tell you. Maybe you’ve just been implementing boilerplate on short-term projects.
I’ve definitely seen lots of benefits from some of the SOLID principles over the same time period, but I was using what I needed when I needed it, not implementing enterprise boilerplate blindly.
I admit this is harder with Java because the “EE” comes with it but no one is forcing you to make sure your DataAccessObject inherits from a class that follows a defined interface.
I have a hard time believing that microservices can possibly be a well designed architecture.
We take a hard problem like architecture and communication and add to it networking, latency, potential calling protocol inconsistency, encoding and decoding (with more potential inconsistency), race conditions, nondeterminacy and more.
And what do I get in return? json everywhere? Subteams that don’t feel the need to talk to each other? No one ever thinks about architecture ever again?
I don’t see the appeal.
It works in huge teams where teams aren’t closely integrated, for development velocity.
Defining a contract that a service upholds, and that dependents can write code against, with teams moving at will as long as the contract is fulfilled is valuable.
I’ll grant you it is true that troubleshooting those systems is harder as a result. In the huge organization I was in, it was the job of a non-coder specialist even.
But given the scope, it made a ton of sense.
But if the contract were an interface, for example, the compiler would enforce it on both sides, and you would get synchronous communication and common data format for free, and team A would know that they’d broken team B’s code because it wouldn’t pass CI and nothing drastic would happen in production.
At that scale, contracts are multiple interfaces, not just one. And C#/Java /whathaveyou interfaces are largely irrelevant, we’re talking way broader than this. Think protocol, like REST, RPC…
At that scale, contracts are multiple interfaces, not just one.
Good job all the compilers I can remember since the last 30 years or so can compile more than one file into a project then.
We’re taking past each other. I’ll saying that I don’t see how adding networking makes anything simpler and you’re saying that you need a bunch of network protocols. Why?
I’m not saying you shouldn’t ever have networking, but then again, I wouldn’t call it a microservices architecture if you’re only using networking when it’s necessary. At that point you just have services because it’s genuinely a network.
It’s not microservices unless you have unnecessarily added a bunch of networking, and unnecessarily adding a bunch of networking is innecessarily adding a bunch of complexity that I can’t see makes anything better.
One example is creating an interface for every goddamn class I make because of “loose coupling” when in reality none of these classes are ever going to have an alternative implementation.
Sounds like you’ve learned the answer!
Virtual all programming principles like that should never be applied blindly in all situations. You basically need to develop taste through experience… and caring about code quality (lots of people have experience but don’t give a shit what they’re excreting).
Stuff like DRY and SOLID are guidelines not rules.
What about KISS ? Now this SHOULD be a rule. Simple is the best
Even KISS. Sometimes things just have to be complex. Of course you should aim for simplicity where possible, but I’ve seen people fight against better and more capable options just because they weren’t as simple and thus violated the KISS “rule”.
DRY SOLID KISS
Java is bad but object-based message-passing environments are good. Classes are bad, prototypes are also bad, and mixins are unsound. That all said, you’ve not understood
SOLIDyet!SandOsay that just because one class is Turing-complete (with general recursion, calling itself) does not mean that one class is the optimal design; they can be seen as opinions rather than hard rules.Lis literally a theorem of any non-shitty type system; the fact that it fails in Java should be seen as a fault of Java.Iis merely the idea that a class doesn’t have to implement every interface or be coercible to any type; that is, there can be non-printable non-callable non-serializable objects. Finally,Dis merely a consequence of objects not being functions; when we want to apply a functionfto a valuexbut both are actually objects, bothf.call(x)andx.getCalled(f)open a new stack frame withfandxlocal, and all of the details are encapsulation details.So, 40%, maybe?
Sreally is not that unreasonable on its own; it reminds me of a classic movie moment from “Meet the Parents” about how a suitcase manufacturer may have produced more than one suitcase. We do intend to allocate more than one object in the course of operating the system! But also it perhaps goes too far in encouraging folks to break up objects that are fine as-is.Omakes a lot of sense from the perspective that code is sometimes write-once immutable such that a new version of a package can add new classes to a system but cannot change existing classes. Outside of that perspective, it’s not at all helpful, because sometimes it really does make sense to refactor a codebase in order to more efficiently use some improved interface.YAGNI ("you aren’t/ain’t gonna need it) is my response to making an interface for every single class. If and when we need one, we can extract an interface out. An exception to this is if I’m writing code that another team will use (as opposed to a web API) but like 99% of code I write only my team ever uses and doesn’t have any down stream dependencies.
I think the general path to enlightenment looks like this (in order of experience):
- Learn about patterns and try to apply all of them all the time
- Don’t use any patterns ever, and just go with a “lightweight architecture”
- Realize that both extremes are wrong, and focus on finding appropriate middle ground in each situation using your past experiences (aka, be an engineer rather than a code monkey)
Eventually, you’ll end up “rediscovering” some parts of SOLID on your own, applying them appropriately, and not even realize it.
Generally, the larger the code base and/or team (which are usually correlated), the more that strict patterns and “best practices” can have a positive impact. Sometimes you need them because those patterns help wrangle complexity, other times it’s because they help limit the amount of damage incompetent teammates can do.
But regardless, I want to point something out:
the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.
This attitude is a problem. It’s an attitude of ignorance, and it’s an easy hole to fall into, but difficult to get out of. Nobody is “circlejerking OOP”. You’re making up a strawman to disregard something you failed at (eg successful application of SOLID principles). Instead, perform some introspection and try to analyze why you didn’t like it without emotional language. Imagine you’re writing a postmortem for an audience of colleagues.
I’m not saying to use SOLID principles, but drop that attitude. You don’t want to end up like those annoying guys who discovered their first native programming language, followed a Vulkan tutorial, and now act like they’re on the forefront of human endeavor because they imported a GLTF model into their “game engine” using assimp…
A better attitude will make you a better engineer in the long run :)
I get your points and agree, though my “attitude” is mostly a response to a similar amount of attitude deployed by the likes of developers who swear by one principle to the death and when you doubt an extreme usage of these principles they come at you by throwing acronyms instead of providing any logical arguments as to why you should always create an interface for everything
You’ve described my journey to a tea. You eventually find your middle ground which is sadly not universal and thus, we shall ever fight the stack overflow wars.
I dunno, I’ve definitely rolled into “factory factory” codebases that are abstraction astronauts just going to town over classes that only have one real implementation over a decade and seen how far the cargo culting can go.
It’s the old saying “give a developer a tool, they’ll find a way to use it.” Having a distataste for mindless dogmatic application of patterns is healthy for a dev in my mind.
deleted by creator
most things should have an alternate implementation, just in the unit tests. imo that’s the main justification for most of SOLID.
but also I’ve noticed that being explicit about your interfaces does produce better thought out code. if you program to an interface and limit your assumptions about implementation, you’ll end up with easier to reason about code.
the other chunk is consistency is the most important thing in a large codebase. some of these rules are followed too closely in areas, but if I’m working my way through an unfamiliar area of the code, I can assume that it is structured based on the corporate conventions.
I’m not really an oop guy, but in an oop language I write pretty standard SOLID style code. in rust a lot of idiomatic code does follow SOLID, but the patterns are different. writing traits for everything instead of interfaces isn’t any different but is pretty common
Yup. Embracing TDD is what made me embrace SOLID.
OOP is good in a vacuum. In real life, where deadlines apply, you’re going to get some ugly stuff under the hood, even though the app or system seems to work.
Whoever is demanding every class be an implementation of an interface started thier career in C#, guaranteed.
Java started that shit before C# existed.
I’m my professional experience working with both, Java shops don’t blindly enforce this, but c# shops tend to.
Striving for loosely coupled classes is objectively a good thing. Using dogmatic enforcement of interfaces even for single implementors is a sledgehammer to pound a finishing nail.
99% of code is too complicated for what it does because of principles like SOLID, and because of OOP.
Algorithms can be complex, but the way a system is put together should never be complicated. Computers are incredibly stupid, and will always perform better on linear code that batches similar operations together, which is not so coincidentally also what we understand best.
Our main issue in this industry is not premature optimisation anymore, but premature and excessive abstraction.
This is crazy misattribution.
99% of code is too complicated because of inexperienced programmers making it too complicated. Not because of the principles that they mislabel and misunderstood.
Just because I forcefully and incorrectly apply a particular pattern to a problem it is not suited to solve for doesn’t mean the pattern is the problem. In this case, I, the developer, am the problem.
Everything has nuance and you should only use in your project the things that make sense for the problems you face.
Crowbaring a solution to a problem a project isn’t dealing with into that project is going to lead to pain
why this isn’t a predictable outcome baffles me. And why attribution for the problem goes to the pattern that was misapplied baffles me even further.
No. These principles are supposedly designed to help those inexperienced programmers, but in my experience, they tend to do the opposite.
The rules are too complicated, and of dubious usefulness at best. Inexperienced programmers really need to be taught to keep things radically simple, and I don’t mean “single responsibility” or “short functions”.
I mean “stop trying to be clever”.
Wholeheartedly agree. OOP was supposed to offer guardrails that make it harder to write irremediably bad code. When you measure the outcomes in the wild, the opposite is true. Traditional OOP code with inheritance makes it hard to adapt code and to reuse it, as far I’ve been able to measure.
My opinion is that you are right. I switched to C from an OOP and C# background, and it has made me a happier person.
I’m making a separate comment for this, but people saying “Liskov substitution principle” instead of “Behavioral subtyping” generally seem more interested in finding a set of rules to follow rather than exploring what makes those rules useful. (Context, the L in solid is “Liskov substitution principle.”) Barbra Liskov herself has said that the proper name for it would be behavioral subtyping.
In an interview in 2016, Liskov herself explains that what she presented in her keynote address was an “informal rule”, that Jeannette Wing later proposed that they “try to figure out precisely what this means”, which led to their joint publication [A behavioral notion of subtyping], and indeed that “technically, it’s called behavioral subtyping”.[5] During the interview, she does not use substitution terminology to discuss the concepts.
You can watch the video interview here. It’s less than five minutes. https://youtu.be/-Z-17h3jG0A
if you have the time, a really good talk on the subject and history.
