3 ms·
Coupling behaviors to types is not a problem. Class inheritance and multi-inheritance with their weird taxonomical trees are the problem. There's little practi
by echelon 2y ago
Coupling behaviors to types is not a problem. Class inheritance and multi-inheritance with their weird taxonomical trees are the problem.
There's little practical reason to build a family tree of supertypes and subtypes outside of building GUIs, yet this is how class-based OOP is designed and taught.
Trait-based OOP gets this right. The hierarchy is completely flat. You simply implement the behaviors for the types you want and don't have to think about grandparent behavior and final interfaces.
- whstl 2y agoIMO: The hierarchy part itself is not as problematic when there is no implementation inheritance involved. Hierarchical interface chains can be fine in my experience, but I’m open to changing my mind. The problem IMO arises when you mix both deep hierarchies and implementation inheritance.
- ninetyninenine 2y ago> Coupling behaviors to types is not a problem. Class inheritance and multi-inheritance with their weird taxonomical trees are the problem. I didn’t mention coupling behaviors to types. I said coupling behaviors to state is the problem. When I couple method a to state it’s a big problem. I want method banana but method banana lives in the jungle and has all the other methods related to jungle. So all I wanted was a banana now I have a jungle. Why not think of the banana as modular from the jungle? Why even use oop? I agree with you on the inheritance thing. Thats a different issue.