This is the "you're holding it wrong" defense of OOP. Of SOLID, S, O, I and D are rehashing structured programming design principles. LSP is peculiar to it, an

This is the "you're holding it wrong" defense of OOP. Of SOLID, S, O, I and D are rehashing structured programming design principles. LSP is peculiar to it, and not an unreasonable way of thinking of objects, but I don't see people struggling to figure out how to come up with workable class hierarchies. The point of objects was that they were intuitive and easy, and where it tends to fall apart is in the details. It's often small tasks like writing an equality operator correctly that are absurdly complicated[1]. And while we can construct reasonable class hierarchies, the interaction becomes a bear and the bugs are subtle and confusing. What I see in OOP programming is that people avoid various idioms or patch around them because they don't trust their tools. I think the problem with most OOP languages is that some high-level concepts like inheritance were constrained by very low-level implementations, and they often tried to glom several ideas together. There's no "object algebra" even 40 years in. In C-like languages, objects are using a "struct and vtable in the heap" model. In dynamic languages, they're using the "type instance and a hashtable in the heap" model. Then they typically declare that a value is really a variable, unless it's an atom, and often other weird asymmetries like "the bottom type actually does have a value which is 'null'" and, of course, whatever weirdness they pick up such as floating point. Those constructs are then overused; this problem is especially apparent in Java where "everything is an object" means that your class becomes your tuple type, and if you want to combine two tuple types you're going to do that via inheritance. In most of them, you don't have a proper discriminated union, so all the stuff you'd do with sum and product types you now have to shoehorn into classes whether it makes sense or not. It all sort of works, but the reason OOP languages keep adopting non-OOP features is that it doesn't work very well. [1]: http://jtechies.blogspot.com/2012/07/item-8-obey-general-contract-when.html http://jtechies.blogspot.com/2012/07/item-8-obey-general-con...