5 ms·

What OOP Isn't

20 points by fogus 16y ago

deleted 16y ago
[deleted]
wccrawford 16y ago
I like how he doesn't even try to defend his stance that inheritance is completely worthless. I would have said it's a LOT more useful.
- jerf 16y ago
  It's a pretty popular idea in OO circles, in that if you are really interested in the topic you should already have heard the arguments. And blog posts have to stop somewhere. You can start at http://c2.com/cgi/wiki?ArgumentsAgainstOop http://c2.com/cgi/wiki?ArgumentsAgainstOop , and follow the links out of "Inheritance" for at least a decent start at the topic if you've never heard of this criticism.
  - davidmathers 16y ago
    That page has top/topmind/tablizer written all over it. http://c2.com/cgi/wiki?TopMind http://c2.com/cgi/wiki?TopMind http://www.geocities.com/tablizer/ http://www.geocities.com/tablizer/
    - jerf 16y ago
      Yes, certainly, but if you follow just the links I cited it's at least a good introduction to the topics. Following everything in that page is somewhat... less recommended.
- raganwald 16y ago
  Implementation Inheritance is a massive can of worms, and a surprisingly emotional topic, but I feel fearless today. How do you feel it is useful?
  - diN0bot 16y ago
    off the top of my head: dynamic dispatch is a great way to re-use code, assuming the subclasses really have a "is-a" relationship. this makes for a double whammy in terms of extensibility, since not only is the code literally more conducive to later changes, but it meets developer's expectations, too. encapsulation and inheritance go hand-in-hand in my book, though i suppose encapsulation, and the necessary concept of interface contracts, is an axiom of sorts from which many other good practices can result, especially if there is also a culture of "communicating for extensibility by new developers later."
    - silentbicycle 16y ago
      What does inheritance give you that pattern matching doesn't? Edit: Also, what raganwald says.
      - jpr 16y ago
        Extensibility of the type without breaking existing code. When you add or remove a case from an algebraic data type, you pretty much need to modify all functions that operate on it since they contain patterns that mention the data-constructors that you either removed, or they don't cover all the cases anymore. (if you meant pattern matching as in text/regular expressions, disregard what I just wrote)
    - raganwald 16y ago
      My experience is almost the exact opposite of yours! The first problem is that the expression "is-a" is notoriously vague. If class A has method a, and class B subclasses a, can B override method a? In what sense is B an A if it does not obey Strict Liskov Substitutability? The second problem is that re-use is an easy problem to solve in any language. We have delegation, we have proxies, we have so many tools. Why use inheritance, which mixes two different concepts (is-a and was-a a/k/a is-implemented-using)? Lastly, how is the code more conducive to later changes? In my experience, you now have a problem where changing class A changes the behaviour of every class that extends A. This is a notoriously tricky problem in the real world. In theory, that change ought to change every subclass and inheritance is a win. In practice, the people writing all those subclasses did so making assumptions about the behaviour of A at the time it was written, much as there are billions of lines of windows code that depend on its bugs and break the moment you fix a bug. Encapsulation is a wonderful thing. I do not see implementation inheritance as having anything whatsoever to do with encapsulation. If anything, I see the opposite. If I write that B is-a A, if these things are fully encapsulated, shouldn't it be a black box as to how B manages to behave exactly like an A? Maybe there's some shared code, but then again, shouldn't it be possible for B to use some other completely different implementation? That's encapsulation to me. Forcing interface inheritance to be twinned with implementation inheritance breaks encapsulation in my opinion.
- akeefer 16y ago
  There are lots of relatively coherent arguments already floating around the interweb around why composition is generally preferable to inheritance when it comes to code reuse; lots of people have strong feelings both ways. I should point out, however, that many OO languages (like Java and C++) make inheritance much easier than composition, and as such inheritance seems more useful than it actually is, simply because it's all you've got. In languages that have better syntactic support for delegation and other compositional techniques, the usefulness of inheritance is significantly lessened. In other words, the usefulness of inheritance is more accidental (i.e. because you often don't have other good options) rather than inherent (i.e. because there simply aren't better options that are possible or available in other languages).
- gnubardt 16y ago
  he did link to another post he'd written elaborating on the subject http://hacksoflife.blogspot.com/2007/01/inheritance-of-implementation-is-evil.html http://hacksoflife.blogspot.com/2007/01/inheritance-of-imple...

20 points by fogus 16y ago

deleted 16y ago

[deleted]

I like how he doesn't even try to defend his stance that inheritance is completely worthless. I would have said it's a LOT more useful.

jerf 16y ago
It's a pretty popular idea in OO circles, in that if you are really interested in the topic you should already have heard the arguments. And blog posts have to stop somewhere. You can start at http://c2.com/cgi/wiki?ArgumentsAgainstOop http://c2.com/cgi/wiki?ArgumentsAgainstOop , and follow the links out of "Inheritance" for at least a decent start at the topic if you've never heard of this criticism.
- davidmathers 16y ago
  That page has top/topmind/tablizer written all over it. http://c2.com/cgi/wiki?TopMind http://c2.com/cgi/wiki?TopMind http://www.geocities.com/tablizer/ http://www.geocities.com/tablizer/
  - jerf 16y ago
    Yes, certainly, but if you follow just the links I cited it's at least a good introduction to the topics. Following everything in that page is somewhat... less recommended.
raganwald 16y ago
Implementation Inheritance is a massive can of worms, and a surprisingly emotional topic, but I feel fearless today. How do you feel it is useful?
- diN0bot 16y ago
  off the top of my head: dynamic dispatch is a great way to re-use code, assuming the subclasses really have a "is-a" relationship. this makes for a double whammy in terms of extensibility, since not only is the code literally more conducive to later changes, but it meets developer's expectations, too. encapsulation and inheritance go hand-in-hand in my book, though i suppose encapsulation, and the necessary concept of interface contracts, is an axiom of sorts from which many other good practices can result, especially if there is also a culture of "communicating for extensibility by new developers later."
  - silentbicycle 16y ago
    What does inheritance give you that pattern matching doesn't? Edit: Also, what raganwald says.
    - jpr 16y ago
      Extensibility of the type without breaking existing code. When you add or remove a case from an algebraic data type, you pretty much need to modify all functions that operate on it since they contain patterns that mention the data-constructors that you either removed, or they don't cover all the cases anymore. (if you meant pattern matching as in text/regular expressions, disregard what I just wrote)
  - raganwald 16y ago
    My experience is almost the exact opposite of yours! The first problem is that the expression "is-a" is notoriously vague. If class A has method a, and class B subclasses a, can B override method a? In what sense is B an A if it does not obey Strict Liskov Substitutability? The second problem is that re-use is an easy problem to solve in any language. We have delegation, we have proxies, we have so many tools. Why use inheritance, which mixes two different concepts (is-a and was-a a/k/a is-implemented-using)? Lastly, how is the code more conducive to later changes? In my experience, you now have a problem where changing class A changes the behaviour of every class that extends A. This is a notoriously tricky problem in the real world. In theory, that change ought to change every subclass and inheritance is a win. In practice, the people writing all those subclasses did so making assumptions about the behaviour of A at the time it was written, much as there are billions of lines of windows code that depend on its bugs and break the moment you fix a bug. Encapsulation is a wonderful thing. I do not see implementation inheritance as having anything whatsoever to do with encapsulation. If anything, I see the opposite. If I write that B is-a A, if these things are fully encapsulated, shouldn't it be a black box as to how B manages to behave exactly like an A? Maybe there's some shared code, but then again, shouldn't it be possible for B to use some other completely different implementation? That's encapsulation to me. Forcing interface inheritance to be twinned with implementation inheritance breaks encapsulation in my opinion.
akeefer 16y ago
There are lots of relatively coherent arguments already floating around the interweb around why composition is generally preferable to inheritance when it comes to code reuse; lots of people have strong feelings both ways. I should point out, however, that many OO languages (like Java and C++) make inheritance much easier than composition, and as such inheritance seems more useful than it actually is, simply because it's all you've got. In languages that have better syntactic support for delegation and other compositional techniques, the usefulness of inheritance is significantly lessened. In other words, the usefulness of inheritance is more accidental (i.e. because you often don't have other good options) rather than inherent (i.e. because there simply aren't better options that are possible or available in other languages).
gnubardt 16y ago
he did link to another post he'd written elaborating on the subject http://hacksoflife.blogspot.com/2007/01/inheritance-of-implementation-is-evil.html http://hacksoflife.blogspot.com/2007/01/inheritance-of-imple...