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.

What’s wrong with making a public static singleton class “isEven” and inheriting it to accomplish your goal class, “isOdd.”

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.

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

deleted by creator

Whoever is demanding every class be an implementation of an interface started thier career in C#, guaranteed.

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.

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.

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.

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.

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.

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

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.

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.

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.