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.

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.

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 refractor at will. Even if you do have to change something and it means a refractor that touches a lot, it’ll still be a lot less work than bloating the entire codebase with needless indirections every day.

SOLID is generally speaking a good idea. In practice, you have to know when to apply it.

it sounds like your main beef in Java is the need to create interfaces for every class. This is almost certainly over-engineering it, especially if you are not using dependency inversion. IMHO, that is the main point of SOLID. For the most part your inversions need interfaces, and that allows you create simple, performant unit tests.

You also mention OOP - It has it’s place, but I would also suggest you look at functional programming, too. IMHO, OOP should be used sparingly as it creates it’s own form of coupling - especially if you use “Base” classes to share functionality. Such classes should usually be approached using Composition. Put this another way, in a mature project, if you have to add a feature and cannot do this without reusing a large portion of the existing code without modifications you have a code-smell.

To give you an example, I joined a company about a year ago that coded they way you are describing. Since I joined, we’ve been able to move towards a more functional approach. Our code is now significantly smaller, has gone from about 2% to 60% unit testable and our velocity is way faster. I’d also suggest that for most companies, this is what they want not what they currently have. There are far too many legacy projects out there.

So, yes - I very much agree with SOLID but like anything it’s a guideline. My suggestion is learn how to refactor towards more functional patterns.

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.

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.

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.

The promise of oop is that if you thread your spaghetti through your meatballs and baste them in bolgnaise sauce before you cook them, it’s much simpler and nothing ever gets tangled up, so that when you come to reheat the frozen dish a month later it’s very easy to swap out a meatball for a different one.

It absolutely does not even remotely live up to it’s promise, and if it did, no one in their right mind would be recommending an abstract singleton factory, and there wouldn’t be quite so many shelves of books about how to do oop well.

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.

java is garbage

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.

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

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.

Two words: cargo cult.