From: Dean Wampler <deanwampler@...>
Date: 2007-10-06T22:21:28+09:00
Subject: Re: The Case for Multiple-Inheritance

------=_Part_14718_26793419.1191676889262
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/5/07, Trans <transfire@gmail.com> wrote:
>
> ...
>   class VideoPlayerApplication < Application
>
>   class LinuxApplication < Applicaiton
>
> Oh no!
>
>   class LinuxVideoPlayerApplication < VideoPlayerApplication
>
> or
>
>   class LinuxVideoPlayerApplication <  LinuxApplication
>
>
To make this issue a bit more concrete, is there ever a time when you'll
have more than one of these objects instantiated in memory and, for example,
a list of Application references where some point to LinuxApplications, some
point to LinuxVideoPlayerApplications, etc.? I suspect you'll only ever have
a LinuxVideoPlayerApplication. In that case, inheritance doesn't solve any
problems. The mixin (module) approach lets you refer to the object
generically as an Application when that makes sense, a Video Player when
that makes sense, etc. without inheritance.

Also, I suspect this hierarchy violates the Liskov Substitution Principle,
which is our most effective definition of what inheritance really means in
software. Is a LinuxVideoPlayerApplication object substitutable everywhere a
LinuxApplication is used? Or, does the former "specialize" the behavior of
the latter in such a way that substitution would break the code expecting a
LinuxApplication? This is very common in "deep" class hierarchies. The idea
that subclasses "specialize" the behavior of superclasses has to considered
carefully.


-- 
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

------=_Part_14718_26793419.1191676889262--