One of my lasts posts is a quote from Martin Fowler's Refactoring, in which he says that "inheritance has its downsides. Most obviously, it's a card that can only be played once. If I have more than one reason to vary something, I can only use inheritance for a single axis of variation.".
After some time, I started to wonder if this problem is not solved by multiple inheritance. Fortunately, this is an issue addressed by Steven Lowe's post Composition vs. Inheritance: How to Choose?, in which he argues that inheritance relationships should not cross domain boundaries (implementation domain vs. application domain). Thus, although inheritance can be used for mechanical and semantic needs, using it for both will tangle the two dimensions, confusing the taxonomy. In that sense, even when inheritance is a card that can be played multiple times, you should think carefully if it's not the case to actually play it only once.
No comments
Post a Comment