5 ms·
It depends if the hierarchy is open or closed. If the hierarchy is open, the behavior is defined in each subtypes and it's easy to add a new subtypes but you c
by _old_dude_ 3y ago
It depends if the hierarchy is open or closed.
If the hierarchy is open, the behavior is defined in each subtypes and it's easy to add a new subtypes but you can not add a new operation (a new method). That's the OOP way.
If the hierarchy is closed, the behavior is defined in each function, it's easy to add a new operation (new function) but you can not add a new subtype. That's the ADT way.
This is known as the https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
- trashburger 3y agoWell, I am a very strong proponent of keeping the hierarchy open in all possible cases; the object should be the one that defines the behavior in all cases, and an object's behavior shouldn't be restricted just because it comes from outside of the object or within. Therefore I agree with your point here.
- 9diov 3y agoThere are cases when the OOP way clearly has the disadvantage. That's why you need visitor pattern (https://en.wikipedia.org/wiki/Visitor_pattern?useskin=vector https://en.wikipedia.org/wiki/Visitor_pattern?useskin=vector). The ADT approach is superior in those cases, as stated in the link above.
- trashburger 3y agoAre you talking about the specific case in the expression problem article? It seems to mainly be a problem when an object's behavior can't be modified, either through the language faculties or through other means like a module system. I don't disagree with its conclusions but I believe it to be a problem of language capabilities.
- munificent 3y agoThere are cases when the FP way clearly has the disadvantage. That's why you need the "record-of-function-pointers" pattern. The interface-and-implementations approach is superior in those cases.
- 9diov 3y agoHaha lovely, clearly we are in agreement here. You even put that in your book isn't it? > The Visitor pattern is really about approximating the functional style within an OOP language (source: https://craftinginterpreters.com/representing-code.html https://craftinginterpreters.com/representing-code.html) The expression problem is one of those "mathematical duality" or yin-yang thing in software design that are less well-known for some reason. People keep pointlessly arguing in favor of one or another without knowing this duality. Another favorite of mine is SQL vs NoSQL which Erik Meijer mathematically proved to be dual of each other using category theory (https://queue.acm.org/detail.cfm?id=1961297 https://queue.acm.org/detail.cfm?id=1961297).
- igouy 3y agoMaybe we'd all be happier with multi-methods https://nice.sourceforge.net/visitor.html https://nice.sourceforge.net/visitor.html
- _old_dude_ 3y agoClosing the hierarchy or not depend on the use cases, for an application most hierarchies are closed. For a library most are open. For example, if your application receive JSON objects, you know all of them so, it's a closed hierarchy.