Re: Composition vs. inheritance
rmoldskr+usenet@online.no wrote:
Todd <todd.heidenthal@lmco.com> wrote:
Hello all,
While I have been programming for many years, I have decided that I
need to start thinking more like a developer than a programmer. As
such, I have been trying to improve my Java skills and OOAD skills.
One of the items I have run across in my self-education is the axiom
to "favor composition over inheritance" as it leads to more loosely
coupled designs. I am finding this difficult as I am a big user of
inheritance (I get the "is-a" relationship thing).
I've slowly come to the view that the famous "is-a" test is rather flawed.
The problem lies in that "is-a" is a question of _type_ -- an emu is a bird,
an array is a list, a BigInt is an integer, while what's inherited is
_behaviour_. An emu _is_ a bird, but it doesn't _behave_ like a bird; an
array _is_ a list, but it doesn't _behave_ like a list; a BigInt _is_ an
integer, but it doesn't _behave_ like an integer, a circle _is_ an ellipse,
but it doesn't _behave_ like an ellipse and so on and on.
In other words, just because something is a more specialised type of
something else, it's not necessarily useful to use inheritance between them.
(And, the other side of the coin, even when something is _not_ a subtype of
something, it _could_ be a good idea to inherit behaviour -- a flying
squirrel isn't a bird, but it might be useful to inherit bird's fly
behaviour.)
An emu is a bird and it behaves like a bird. If you have put
functionality in bird that an emu does not have then you have put
functionality in bird that does not belong there. That is design
error not a problem with is-a.
An array is not a list (in the java.util.List sense).
A BigInteger is not an Integer (use Java definitions).
Circle-ellipsis could be a problem. I think that OO and math
may have slightly different definitions of is-a.
Is-a is type, but type in OO means behavior.
And having flying squirrel inherit bird is a very good example
of when not to use inheritance.
Arne