Composition vs. inheritance

[Arne Vajhøj]

Arne Vajhøj wrote:
...
...

Isn't this just a matter of the immutable vs. mutable issue?

Each individual circle is an ellipse, and has exactly the behavior of an
ellipse whose major axis and minor axis are both equal to the radius of
the circle. There is a problem if you allow an ellipse to change
dimensions while it exists, but is that really a necessary feature of an
Ellipse class?

That is a valid point.

But even in the case of an immutable Ellipsis class, then I am still
not quite comfortable with it.

In case a new Ellipsis instance is created then if the two distances
are the same, then it really is a Circle.

Arne

 

[Arne Vajhøj]

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.

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.

Only because of the particular limits of Java. Conceptually, a big-integer
is a general case of integer.
Same.


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.

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

 

[Arne Vajhøj]

OK, but the OP's question could also be read as 'should I design
my own programs/framework' by creating abstract classes?

And the answer is: yes, if it makes sense.

It's not because the OP is sometimes forced to use badly crafted
frameworks forcing him to extend abstract classes that abstract
classes are a good thing.

In my opinion it's a fundamentally broken design.

As I already pointed out both James Gosling and Bjarne Stroustrup
agree on that one, as do, say, the Spring developers, users, etc.

http://www.artima.com/intv/gosling34.html

(this is really an eye opener).

My other post seems to be lost, so here's Stroustrup's take on this:

http://www.artima.com/intv/modern.html

Stroustrup:

"Since then I have consistently pointed out that one of the major
"ways of writing classes in C++ is without any state, that is,
"just an interface.

Actually they do agree on more then that: they even agree on the
fact that 'concrete inheritance', a.k.a 'implementation inheritance'
is fundamentally broken.

There are even OO languages that explicitely forbids implementation
inheritance (and other that mandates it but that is another story).

And these guys knows way better than me, as do the Spring developer.

I think you read to much into those writings.

That someone thinks a language without extends would be better
does not imply that extend should not be used in a language
that does have it.

That abstract classes can be written with no implementation at
all and that it is a major thing does not imply that abstract
classes with functionality can not be a good thing.

I checked newest Spring. Out of approx. 1600 classes then approx.
300 are abstract.

If there is a comment in the tops saying "extend this class to ...",
then it is probably OK to extend.

Yup... But to me it's also a warning saying: "be very careful when
using this framework, it's probably not been designed by OO gurus".
(I'd rather keep using frameworks like Spring that do the Right Thing
[TM]).

See above.

Arne