Programming

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.

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.

The principles are perfectly fine. It's the mindless following of them that's the problem.

Your take is the same take I see with every new generation of software engineers discovering that things like principles, patterns and ideas have nuance to them. Who when they see someone applying a particular pattern without nuance think that is what the pattern means.

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.

Not only loose coupling but also performance reasons. When you initialise a class as it's interface, the size of the method references you load on the method area of the memory (which doesn't get garbage collected BTW) is reduced.

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.

In my experience, not following SOLID principles makes your application an unmaintainable mess in roughly one year. Though SOLID needs to be coupled with better modularity to be effective.

The main thing you are missing is that "loose coupling" does not mean "create an interface". You can have all concrete classes and loose coupling or all classes with interfaces and strong coupling. Coupling is not about your choice of implementation, but about which part does what.

If an interface simplifies your code, then use interfaces, if it doesn't, don't. The dogma of "use an interface everywhere" comes from people who saw good developers use interfaces to reduce coupling, while not understanding the context in which it was used, and then just thought "hey so interfaces reduce coupling I guess? Let's mandate using it everywhere!", which results in using interfaces where they aren't needed, while not actually reducing coupling necessarily.

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.

That one is indeed objective horse shit. If your interface has only one implementation, it should not be an interface. That being said, a second implementation made for testing COUNTS as a second implementation, so context matters.

In general, I feel like OOP principals like are indeed used as dogma more often than not, in Java-land and .NET-land. There's a lot of legacy applications out there run by folks who've either forgotten how to apply these principles soundly, or were never taught to in the first place. But I think it's more of a general programming trend, than any problem with OOP or its ecosystems in particular. Betcha we see similar things with Rust, when it reaches the same age.

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):

1. Learn about patterns and try to apply all of them all the time
2. Don't use any patterns ever, and just go with a "lightweight architecture"
3. 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 :)

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 SOLID yet! S and O say 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. L is literally a theorem of any non-shitty type system; the fact that it fails in Java should be seen as a fault of Java. I is 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, D is merely a consequence of objects not being functions; when we want to apply a functionf to a value x but both are actually objects, both f.call(x) and x.getCalled(f) open a new stack frame with f and x local, and all of the details are encapsulation details.

So, 40%, maybe? S really 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. O makes 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.

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

Yes OOP and all the patterns are more than often bullshit. Java is especially well known for that. "Enterprise Java" is a well known meme.

The patterns and principles aren't useless. It's just that in practice most of the time they're used as hammers even when there's no nail in sight.

I'm a firm believer in "Bruce Lee programming". Your approach needs to be flexible and adaptable. Sometimes SOLID is right, and sometimes it's not.

"Adapt what is useful, reject what is useless, and add what is specifically your own."

"Notice that the stiffest tree is most easily cracked, while the bamboo or willow survives by bending with the wind."

And some languages, like Rust, don't fully conform to a strict OO heritage like Java does.

"Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it. If nothing within you stays rigid, outward things will disclose themselves.

"Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend."

if you have the time, a really good talk on the subject and history.

I think that OOP is most useful in two domains: Device drivers and graphical user interfaces. The Linux kernel is object-oriented.

OOP might also be useful in data structures. But you can as well think about them as "data structures with operations that keep invariants" (which is an older concept than OOP).

The SOLID principles are just that principles, not rules.

As someone else said, you should always write your code to be maintainable first and foremost, and extra code is extra maintenance work, so should only really be done when necessary. Don't write an abstract interface unless multiple things actually need to implement it, and don't refactor common logic until you've repeated it ~3 times.

The DRY principle is probably the most overused one because engineers default to thinking that less code = less work and it's a fun logic puzzle to figure out common logic and abstract it, but the reality is that many of these abstractions in reality create more coupling and make your code less readable. Dan Abramov (creator of React) has a really good presentation on it that's worth watching in its entirety.

But I will say that sometimes these irritations are truly just language issues at the end of the day. Java was written in an era where the object oriented paradigm was king, whereas these days functional programming is often described as what OO programming looks like if you actually follow all the SOLID principles and Java still isn't a first class functional language and probably never will be because it has to maintain backwards compatibility. This is partly why more modern Java compatible languages like Kotlin were created.

A language like C# on the other hand is more flexible since it's designed to be cross paradigm and support first class functions and objects, and a language like JavaScript is so flexible that it has evolved and changed to suit whatever is needed of it.

Flexibility comes with a bit of a cost, but I think a lot of corporate engineers are over fearful of new things and change and don't properly value the hidden costs of rigidity. To give it a structural engineering analogy: a rigid tree will snap in the wind, a flexible tree will bend.

Like anything else, it can be useful in the right context if not followed too dogmatically, and instead is used when there is a tangible benefit.

For example, I nearly always dependency inject dependencies with I/O because I can then inject test doubles with no I/O for fast and stable integration tests. Sometimes, this also improves re-usability, and for example, a client for one vendor’s API can be substituted with another, but this benefit doesn’t materialize that often. I rarely dependency inject dependencies with no side-effects because it’s rare that any tangible benefit materializes, and everyone deals with the additional complexity for years with no reason. With just I/O dependencies, I’ve generally found no need for a DI container in most codebases, but codebases that dependency inject everything make a DI container basically mandatory, and its usually extra overhead for nothing, IMO. There may be codebases where dependency injecting everything makes perfect sense, but I haven’t found one yet.

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.

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.

Congratulations. This is where you wind up, long after learning the basics and start interacting with lots of code in the wild. You are not alone.

Implementing things with pragmatism, when it comes to conventions and design patterns, is how it's really done.