From: Robert Klemme Date: 2010-11-03T02:40:14+09:00 Subject: Re: the dark side of inherited methods On 02.11.2010 17:37, Intransition wrote: > > On Nov 2, 5:31 am, Robert Klemme wrote: >> On Tue, Nov 2, 2010 at 4:29 AM, Tony Arcieri wrote: >>> On Sun, Oct 31, 2010 at 5:49 PM, James Edward Gray II>>> wrote: >> >>>> It is a problem with inheritance and another reason why inheritance is >>>> almost never what we want. >> >>> That's a pretty extreme position to take. Inheritance is an indispensable >>> tool. That said, I will agree that "is a" relationships come up far less >>> frequently than 'has a" relationships. >> >> I believe this is what James wanted to stress: inheritance is used far >> too often for purposes where it's not appropriate. A real is_a >> relationship is pretty rare yet many people use inheritance, >> especially with core / std lib classes as parents which almost always >> is a code smell. >> >> Side note: there are languages such as Eiffel and C++ which have >> support for implementation inheritance (i.e. the interface changes >> incompatibly from super class to sub class) and in those languages >> inheritance can be used more often than in language which lack these >> features (e.g. Java). > > Indeed, I think inheritance gets a really bad rap in Ruby b/c Ruby's > base classes and inheritance system are so poorly designed to handle > it. I would not subscribe to that. Although Bertrand Meyer is a big fan of implementation inheritance I am not yet convinced that it is such a good idea so often. Of course, there are always uses for any technique present, but I find the "is a" relationship interpretation of inheritance so clear and obvious that I somehow feel bad about polluting inheritance with other uses. I cannot really put forward a more concrete argument or even back this up by some hard (business) numbers, but a world in which "A inherits B" <=> "A is a B" is so much simpler. And in Ruby, whenever you need implementation inheritance you can use a mixin module. Enumerable is a very good example for that. > The other day I was talking to my Father, a Cobol programmer from back > in the day, and he was telling me that when he retired, OOP was just > starting to get hyped. He was quite interested in it at the time and > then rattled off some of the advantages he remembered it was to bring > to the field. Inheritance for code reuse was high on the list and Well, there are other forms of code reuse - even in procedural languages. It's not that you _need_ inheritance to have code reuse. I would even go as far as to claim that it is more difficult to implement classes intended solely for implementation inheritance than classes which implement a particular real world concept and which are only inherited if "is a" is needed. I say this because a class intended for implementation inheritance needs other criteria for including functionality than a class which implements a particular concept. > related to that, one point eally struck me -- instead of versioning > code as we have become accustomed, the idea was to subclass the > original class and implement changes in the subclass. Using some sort > of class name referencing scheme you could use any version. That does not sound like a, um, proper application of inheritance to me. It might be useful to do it that way in some rare conditions but I would not promote this as a big feature of inheritance. > Sadly, I had to inform him that OOP did not quite prove to be the > godsend everyone originally thought it might be. Well, silver bullets - if you know one, you know them all. :-) Btw, I find that we have this type of discussion far too seldom here nowadays and I imagine that we did that more often earlier on. But that is totally subjective. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/