6 ms·
Why inheritance sucks
- vog 16y agoI was hoping to see a good article about inheritance vs. object composition. Although Ruby's "modules" are indeed preferable to inheritance they are usually as inappropriate as inheritance. To my experience, object composition solves most of the design issues in a more elegant way. And I wonder why this is still so less understood by most programmers. It isn't even particularly new. Even the good old GoF patterns recommend object composition over inheritance, especially in their Smalltalk examples. (In their book, they demonstrate each pattern in a static (C++) and a dynamic (Smalltalk) language, so Ruby programmers should have a deeper look at the Smalltalk part of the book, rather than imitating the C++ variants of the patterns.)
- loup-vaillant 16y agoI think the reason people prefer inheritance is because it gives them the illusion that their code is simpler. They don't see the huge interfaces implied by inheritance because they are implicit. Composition, on the other hand, is explicit. When you use it, you notice the complexities. That gives you an incentive to simplify your design, which makes you write actually simpler code.
- rimantas 16y agoThe other reason as I see is some quite weird perception that OOP == inheritance.
- loup-vaillant 16y agoQuite right. We can correct that by showing the classification of main programming paradigms[1]. It shows that, OO just needs records, procedures, named state and closures. (I personally prefer to say the more understandable "OO needs structs, assignment, and closures".) Now I have a problem, however: what is the difference between OO and stateful functional programming? [1]: http://www.info.ucl.ac.be/~pvr/paradigms.html http://www.info.ucl.ac.be/~pvr/paradigms.html
- barrkel 16y agoPolymorphism is at the core of most OO language features. Sum types aren't a viable substitute in most large apps because they are closed to extension at runtime. Doing it right functionally means rolling your own protocol system.
- samg_ 16y agoOOP is different things to different people. While I agree with you that OOP != inheritance, I believe that polymorphism ∈ OOP and inheritance is a part of polymorphism.
- loup-vaillant 16y agoI don't follow you here. Are you saying that inheritance is mandatory to OOP? (I don't agree nor disagree. I'd just like to know what you mean.)
- barrkel 16y agoPolymorphism is often implemented as at least inheritance of interface in statically typed languages. Without polymorphism you don't get dynamic dispatch, especially open to extension at runtime.
- samg_ 16y agoI am not saying that inheritance is mandatory to OOP. I think "mandatory" is too strong of a word here. As I said, OOP means different things to different people and I am okay with that. Speaking for myself, OOP is a way to orchestrate programming on a large scale. To grow software without growing the frequency, severity, and difficulty of bugs and without growing costs associated with new features is the desired result. Component-ized architecture takes great steps to achieve this result. For this reason, I view OOP as being some combination of: message passing, encapsulation, and polymorphism. I do not believe this is a complete view of OOP, nor that there is no viable alternative view of OOP.
- tkahn6 16y agoAd hoc polymorphism ∈ OOP Parametric polymorphism ∈ FP
- vog 16y agoI disagree. Polymorphism and inheritance are separate concepts. Yes, some statically typed languages like C++ and Java enforce certain inheritance constraints via classes or explicit interfaces before you can use polymorphism. But almost all dynamically typed languages allow for ad-hoc polymorphism. For instance, in Python this is called "duck typing". Just because two objects provide a "foo()" method doesn't mean they are in any inheritance relation to each other. But polymorphism should still work.
- wzdd 16y agoThe problem is that lots of different software engineering styles are implemented using the language feature of inheritance. For example in C++ implementing interface X looks the same syntactically as inheriting from some class X to modify it. Sometimes people refer to the specific problematic inheritance style as "implementation inheritance". I found it very useful just to know that such a distinction could be made.
- zby 16y agoThis is rather well studied subject - but this article does not add anything to the discussion. It talks a lot about names not much about their meaning. The only explanation he gives for the advantages or modules over classes is <blockquote> In Ruby you don't declare your types, so you cannot get ambiguous instance variables: if you have two instance variables with the same name in different modules, then they're the same instance variable. </blockquote> as if this kind of unification of variables would obviously solve anything. Despite linking to the Wikipedia, he also does provide the right definition of the diamond problem: <blockquote> This is the dreaded "diamond" problem that C++ programmers learn to fear: if your class has two superclasses that both define an instance variable named x, then you can have a hard time specifying which x you're using. </blocquote> Where is the diamond here?
- RodgerTheGreat 16y agoRegarding the diamond problem, I think he means that in the event of multiple inheritance, your class heirarchy would look like this: Object / \ A B \ / C Where A and B are parents of the class C. In most OO languages there will be an implied parent of A and B, like Object.
- kenjackson 16y ago"In Ruby you don't declare your types, so you cannot get ambiguous instance variables: if you have two instance variables with the same name in different modules, then they're the same instance variable." That line also bugged me. I struggle to see how that's a good thing. That seems like you could have code breaking in seemingly unrelated code due to seemingly common naming issues. That can't be right, can it?
- nusco 16y ago(From the original poster): You're right that I mischaracterized the diamond problem. I edited the post to fix that. My C++ mind model has been slipping away fast in part years. Definitely not like riding a bicycle.
- jknupp 16y agoI strongly disagree that "code reuse" is a reason to use inheritance in C++/Java. Composition nicely solves that problem. In fact, I would argue that someone who believes code reuse is an appropriate reason to use inheritance does not understand OO programming as well as they believe.
- palish 16y agoThis. In fact, a friend of mine swears by writing C++ in a style called "snippets" --- meaning, whenever it makes sense to do so, he writes new functionality as a single header and cpp file that has no dependencies whatsoever on other headers, etc, then open-sources it so that anyone can add the same functionality to their own C++ projects by just dropping in the code. A math lib, for example.
- deleted 16y ago[deleted]
- kenjackson 16y agoAren't those also just called "functions"? In this case one function per file?
- palish 16y agoNo. As soon as your function has a dependency on anything else whatsoever, it can no longer be copy-and-pasted into another project A snippet consists of functions which accomplish a specific task. The important part is that the entire snippet is a single cpp and a single header. No dependencies.
- substack 16y agoNeat. This style of code reuse is a lot like perl6 roles (http://search.cpan.org/~rkinyon/Perl6-Roles-0.01/lib/Perl6/Roles.pm http://search.cpan.org/~rkinyon/Perl6-Roles-0.01/lib/Perl6/R...) or haskell typeclasses: instead of describing how objects fit into a taxonomic hierarchy, objects or typeclasses are described by what behaviors they fulfill. For instance, in haskell a Complex type has an instance of Num in order to define numeric operations like (+) and (-). The emphasis is on what something does rather than on what it is.
- draegtun 16y agoFor perl5 then Moose Roles would be more appropriate. I have posted a few links about roles to HN. Below are probably best ones: * http://news.ycombinator.com/item?id=1552691 http://news.ycombinator.com/item?id=1552691 * http://news.ycombinator.com/item?id=774694 http://news.ycombinator.com/item?id=774694 * http://news.ycombinator.com/item?id=588391 http://news.ycombinator.com/item?id=588391 * http://news.ycombinator.com/item?id=1620295 http://news.ycombinator.com/item?id=1620295
- eitland 16y ago>instead of describing how objects fit into a taxonomic hierarchy, objects or typeclasses are described by what behaviors they fulfill. Can't this be said about Java interfaces too?
- chromatic 16y agoYes and no. Java interfaces are a very degenerate case of roles. They provide no default behavior (a few constants notwithstanding), they are special cases in at least part of the type system (declaring a class does not also declare a role), and I know of no good way to handle conflicts when implementing multiple interfaces with overlapping requirements.
- seshagiric 16y agoOld joke in my office: Q. What is the object oriented way of getting rich? A. Inheritance (its a Friday :))
- johnzabroski 16y agowhy is this being upvoted