Re: Composition vs. inheritance
rmoldskr+usenet@online.no wrote:
Arne VajhHj <arne@vajhoej.dk> wrote:
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.
From a strict classification view that is, of course, true, but from a
practical question of organisation it isn't necessarily so. Sometimes, the
easiest way to model something is to specify an underlying, general
behaviour followed by specialisations of that behaviour and, often
overlooked, _exceptions_ to that behaviour.
I think that is the wrong way of doing OO.
Singletons have no need for an equals( ) method and calling clone( ) on one
is downright erronous, but it still makes modelling sense to put equals( )
and clone( ) into the base Object class and rather override them with "throw
new UnsupportedOperationException( "There will be _no_ cloning the
singleton, thank you." )"
clone is automatic that way.
And equals in a singleton should absolutely not be overridden with a
throw exception method.
Of course, if you're modeling birds, you can start with "AbstractBird" and
next go to "FlyingBird extends AbstractBird" and "FlightlessBird extends
AbstractBird", but what about songless birds, non-nesting birds, wingless
birds, tailless birds... at some point it just makes the most sense to say
"Oh, sod it" and define that "birds have wings and tails, they fly, sing and
nest _unless otherwise specified_."
Wrong OO approach.
An array is not a list (in the java.util.List sense).
Yes, in the Java sense it isn't, but when we're modeling and trying to
decide where to use inheritance and where to use something else we're still
in the conceptual space, and there an array is a list (in the lowercase l
sense.)
I can not comment on your personal definitions of classes since I do
not know them.
I think you will get into implementation problems in Java if your
model specify that arrays is a "list" because your arrays will
not match well with Java arrays.
A BigInteger is not an Integer (use Java definitions).
Only because of the particular limits of Java. Conceptually, a big-integer
is a general case of integer.
Same.
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.
No, there is a difference between type and behaviour. Two different
Exception classes share the exact same behaviour, but are different types.
Two different set implementations share the same super-type, but one might
have O(1) behaviour for add() and the other O(log n).
Now, it's true that in Java the difference between type and behaviour is not
very well defined, but I consider that a weaknes of Java.
No.
Is-a type implies same behavior.
And having flying squirrel inherit bird is a very good example
of when not to use inheritance.
Well, a slightly less silly example then -- Slowworms (Anguis Fragilis) are
lizards, but if you're writing a Slowworm implementation for your
SimEverything game you might very well want to inherit the "move" behaviour
from your Snake class. But with the "inheritance denotes type" view of Java
and most other OO languages, that's awkward.
No.
Good OO is inheriting based on true is-as.
Bad OO is inheriting based on "hey I could use some of that
functionality".
Arne