5 ms·
Inheritance is easily overused, but that doesn't mean that we should just avoid it altogether. The problem IMO is that we are stuck in a view that inheritance
by hibikir 13y ago
Inheritance is easily overused, but that doesn't mean that we should just avoid it altogether.
The problem IMO is that we are stuck in a view that inheritance is really about ontology, when what we really mean, and want, is code reuse. It's very hard to make a 5 level deep ontology not break down. This is why we have this whole 'prefer composition over inheritance' business.
But while we are stuck with that kind of mindset in Java (at least pre java 8), we miss the capability of using inheritance as a way of adding mixins. There is much power in using mixins as a way to clarify composition, while we still keep the inheritance tree very shallow.
That's one thing we get with judicious use of the Scala cake pattern, which you could easily reproduce in javascript: Composition without really having to write a bunch of useless boilerplate. There's a nice talk out there about it. Cake Pattern: The Bakery from the Black Lagoon.
The trick, as with most other programming techniques, is to use it carefully.
- kenrikm 13y agoI'm coming at this from the view of an Objective C programmer, which was heavily influenced by smalltalk. Having written Objective C full-time for 5+ years, it is rare to need to use inheritance in classes that actually implement application level logic, however it's used in just about every class you make as you inherit from Apple's base. (UIViewController, UIView, etc..) It's useful to subclass and add categories as needed. At a functional level it's not an issue, however with that in mind I'm not sure it's a great pattern for Javascript.
- chadhietala 13y agoNot trying to be tangental, but I believe this is true with EmberJS which was originally modeled off of Coaco. You inherit from Ember's base Objects (ArrayController, ObjectController, etc) and rarely find yourself extend classes that you write. Here is a hierarchy of the "base" classes. http://emberjs.jsbin.com/bahetoka/1 http://emberjs.jsbin.com/bahetoka/1
- sunir 13y ago"what we really mean, and want, is code reuse" I'm not sure if you meant it this way, so I'll underscore this point. Code reuse is truly the worst "reason" to use inheritance, and in fact an anti-pattern. Composition is the only proper way to reuse code because composition is explicitly stating you are using the composed code.
- jroseattle 13y ago"Composition is the only proper way to reuse code because composition is explicitly stating you are using the composed code." And every other pattern is not suggesting this very same thing?
- parasubvert 13y agoYou're taking it too far. One should prefer delegation/composition in most cases, but if you're trying to direct users to a restricted reuse model (inheritance), then it works fine and is often a much clearer approach than "Joe's custom delegation model". There are plenty of examples of this in practice - someone pointed out NeXT/Apple's UIKit for example elsewhere in this thread (which also uses composition where appropriate). The Java collections hierarchy is also a good one (LinkedHashSet < HashSet < AbstractSet).
- thatthatis 13y agoI disagree that what we want is code re-use. I'd say we rather want encapsulation and single responsibility. I strongly agree with your main point though: that the way we get "good" OO design is through composition and mixins