6 ms·

What’s wrong with subclassing and having default empty implementations of functions? I don’t understand what’s wrong with a default no-op lambda argument (excep

What’s wrong with subclassing and having default empty implementations of functions? I don’t understand what’s wrong with a default no-op lambda argument (except JavaScript or Java doesn’t seem to be able to provide one AFAIK).

nicoburns 5y ago
Subclassing (and inheritance in general) makes it pretty difficult to follow the control flow as a given function call could resolve to one of many implementations, but there's nothing in the calling code to indicate which ones. Better to use composition and code which explicitly delgates to a sub-object where necessary.
- heavenlyblue 5y ago
  How does using a sub-object make it any different? You can’t know which one is going to be called without knowing which object was put in the compositionary scenario exactly the same way as in order to know which implementation is going to be called you need to know the type of an object. I don’t think your argument is strong here.
  - nicoburns 5y ago
    If you are calling a method on a delegated object then you know it's one of the delegated objects rather than a method on the base class. It makes it really easy to see which bits vary by between the delegated/sub objects and which bits are the same for all of them. With inheritance you have to check through every single sub-class to see if they've overridden a method. Code paths where an overridden method in a subclass calls back into a method on the base class are much clearer too, as they have to be explicitly passed in as parameters, the sub-class doesn't have access to any of the parent class's state or methods by default.
3np 5y ago
What if suddenly, after implementing, you have a new requirement of supporting users who are both a Customer and an Admin simultaneously? The resulting refactoring will be a lot more significant.
- heavenlyblue 5y ago
  there is no way to organise code in such a way that it will equally cater to any change of the semantics down the line in an ergonomic fashion. I have argued given the current puzzle, not additional “down the line” puzzle.
  - 3np 5y ago
    I don't see how that holds here. The author's proposed solution is composable, subclasses are not. Maintainability is an important property.
valenterry 5y ago
Subclassing is not only about technique but also about semantics. Once you start with that, I will also be doubtful if the method "doX" or "createY" or "findZ" will do what they promise or behave completely unexpected. That's why we try to follow liskov, and with your suggestion you are breaking this assumption/convention.
ensiferum 5y ago
Subclassing the Usertype is a wrong solution here anyway. In fact this is a classic OO trap. Whether a user is an admin or not is a role of the user. So a better class relationship is User has a Role. Role can be an interface class with multiple implementations. This design trivially lends itself for example to a use case where the user holds multiple roles. The classic OO design would use some form of "multiple" inheritance resulting in complicated class hierarchy.

nicoburns 5y ago

Subclassing (and inheritance in general) makes it pretty difficult to follow the control flow as a given function call could resolve to one of many implementations, but there's nothing in the calling code to indicate which ones. Better to use composition and code which explicitly delgates to a sub-object where necessary.

heavenlyblue 5y ago
How does using a sub-object make it any different? You can’t know which one is going to be called without knowing which object was put in the compositionary scenario exactly the same way as in order to know which implementation is going to be called you need to know the type of an object. I don’t think your argument is strong here.
- nicoburns 5y ago
  If you are calling a method on a delegated object then you know it's one of the delegated objects rather than a method on the base class. It makes it really easy to see which bits vary by between the delegated/sub objects and which bits are the same for all of them. With inheritance you have to check through every single sub-class to see if they've overridden a method. Code paths where an overridden method in a subclass calls back into a method on the base class are much clearer too, as they have to be explicitly passed in as parameters, the sub-class doesn't have access to any of the parent class's state or methods by default.

3np 5y ago

What if suddenly, after implementing, you have a new requirement of supporting users who are both a Customer and an Admin simultaneously? The resulting refactoring will be a lot more significant.

heavenlyblue 5y ago
there is no way to organise code in such a way that it will equally cater to any change of the semantics down the line in an ergonomic fashion. I have argued given the current puzzle, not additional “down the line” puzzle.
- 3np 5y ago
  I don't see how that holds here. The author's proposed solution is composable, subclasses are not. Maintainability is an important property.

valenterry 5y ago

Subclassing is not only about technique but also about semantics. Once you start with that, I will also be doubtful if the method "doX" or "createY" or "findZ" will do what they promise or behave completely unexpected. That's why we try to follow liskov, and with your suggestion you are breaking this assumption/convention.

ensiferum 5y ago

Subclassing the Usertype is a wrong solution here anyway. In fact this is a classic OO trap. Whether a user is an admin or not is a role of the user. So a better class relationship is User has a Role. Role can be an interface class with multiple implementations. This design trivially lends itself for example to a use case where the user holds multiple roles. The classic OO design would use some form of "multiple" inheritance resulting in complicated class hierarchy.