>If this can happen, and it does, the author of the Derived class must KNOW how the Base class has been implemented. And they must be informed about every chang

>If this can happen, and it does, the author of the Derived class must KNOW how the Base class has been implemented. And they must be informed about every change in the Base class since it could break their Derived class in unpredictable ways. Yes...? If you are manually overriding implementation details you must be aware of the implementation details and the contract the parent class is meant to fulfill as well as invariants it must hold. >With Black Box programming, we can be completely ignorant of the implementation since we cannot inject code into the Base class by overriding one of its functions. We only have to concern ourselves with the Interface. >This trend is disturbing… it is not a trend and it should not disturb anyone. It seems author wants to change the behaviour of a type... without knowing or understanding the behaviour to start with. >But if a parent and child could arbitrarily switch places, then clearly something is wrong with this model. If a parent and child can arbitrarily switch places then it's obviously not a hierarchical model. Classes are not folders, they are a convenient subset of type theory. A 'Company'-related file is not a subtype of a 'Document'-related file, or vice versa. They aren't related, let alone related hierarchically. >If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere. >What you won’t find is Categorical Hierarchies. You won't find any hierarchies in the 'real world', they are abstract mental models that we, humans, use to organize things. Which one is more applicable depends on what you're looking at and thinking about. I won't comment in depth on the latter 2 sections as they're comparatively short and nonsensical. Don't get me wrong, I love FP and write Haskell and Elm relatively frequently, but this is not an indictment of OOP as much as it is an indictment of poor practices. And I know that's thrown around a lot as an excuse for the real pitfalls of OOP, and I will refuse to say that it's not "true OOP" for that reason, but, it's at least not good OOP.