[throwAGIway]

Just having a huge bikeshedding festival at work after I wrote this sentence into guidelines...

The worst thing is how hard it is to talk about it because all the books - by authors making more money from talking about software than from writing and maintaining code - recommend it, and it's just so SOLID and Hexagonal and looks obviously intuitively correct.

[prerok]

Can you elaborate, you have piqued my interest :)

The sentence for preferring "composition over inheritance" for code reuse is in the book by the gang of four (the design patterns book). I really don't understand how we ended up in the situation, where 30 years old advice is still valid and still not followed. I lay, perhaps too much, blame on Java, which seems to have this baked into its infrastructure, but similar approaches have also been adopted in C++ with multiple inheritance making things even worse.

I mean, SOLID, when used appropriately, is also valid. The problem is that the design patterns are used where a simpler solution would work just as well.

[throwAGIway]

This is exactly the problem - the advice is valid, but the developers can't see their implementation is not, and my examples of maintainable code seemingly go against the advices.

They think their huge class diagrams and statically unverifiable mess of many structurally identical classes (in Typescript) is an example of DRY, composition, separation of concerns, inversion of control and encapsulation - all the great advice neatly packed into 50 files opaquely interconnected through dependency injection containers, where a simple 100 line function would have done the job and wouldn't cause a major headache for the poor guy who has to fix a bug in 3 years.

The root issue is that these guys never were the poor guy who has to fix a bug after 3 years. They moved on after a year or two of "implementing best practice approaches" to the next job.