|
This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.
Message:
Java As It Is
Posted by Bill Venners on 10 Nov 1998, 10:36 AM
> For me this inheritance vs composition issue all comes down to designing solutions which > (a) most effectively model the problem at hand
> (b) which permit evolution
> (c) which are practical > ...in roughly that order of importance. > I therefore find it quite irritating that a language mechanism - an implementation detail if you will - should oblige me to bias my design towards composition, no matter what the situation.
> From the point of view of keeping both compilation and runtime semantics as simple as possible, the single class/multiple interface inheritance solution is undoubtadly a clever trick. But it has nothing to do with OO and developers would be wise to recognise this fact when crafting designs - to avoid inadvertently emphasising (c) as opposed (a).
> May I suggest, therefore, that emphasis/bias which Bill has given to composition in this article is at least in part a consequence of the restrictions imposed by the Java language itself.
> What do you think Bill? Has your mind been corrupted ;-) ??? Thanks for this comment, Mike. Allow me to treat you in third
person here, for the benefit of other readers. I think I know where Mike is coming from here. He and I
had a nice conversation over coffee recently about multiple
inheritance, interfaces, Design by Contract, and Java vs.
Eiffel. Mike's feeling is that the trouble with multiple
inheritance in C++, which we both agreed was relatively
useless, is not the concept of multiple inheritance itself,
but how it is implemented in C++. In Eiffel, Mike contended,
multiple inheritance is implemented in a way that makes
sense and is very useful. He saw Java's approach of only
allowing multiple inheritance of interface (via interfaces)
as a bit of a copout. (Let me know if I got this wrong, Mike.) I'm not sure why Mr. Gosling left full-blown multiple
inheritance out of the language, but I suspect it may have
been one of those many features that he felt did not yield
enough added utility to make it worth the added complexity.
Perhaps because I came to Java from C++, and have had almost
no experience with Eiffel (My only experience with Eiffel was
a seminar I attended taught by Bertrand Russel, which was my
first introduction to object-oriented programming.), I
don't miss plain-old multiple inheritance and it doesn't bother
me that it is excluded in Java. Mike is right on target when
he says that the guidelines I propose in these articles are
"in part a consequence of the restrictions imposed by the
Java language itself." Given the language as it exists, I
try to advise the best way to use it. I also agree with Mike's ordered list of goals of a design: > (a) most effectively model the problem at hand
> (b) which permit evolution
> (c) which are practical My own philosophy is that the primary goal of a design should
be to maximize code flexibility, which I define as the ease
with which code can be understood and changed. Code that
"effectively models the problem at hand" is probably easier
to understand. Code that "permits evolution" is easy to change. But alas, I want to emphasize that I don't emphasize composition
or de-emphasize inheritance in my designs, although I seem
to have come across this way in my article. As I said in this
reply:
http://www.artima.com/flexiblejava/fjf/compoinh/messages/12.html
I think inheritance is appropriate when a subclass has a clear
and permanent is-a relationship to the superclass, such as
a SavingsAccount is-a Account. The is-a relationship means that
a subclass is a more specialized form of a superclass -- that
the superclass is a more general form of the subclass. I believe
modeling such relationships with inheritance "most effectively
models the problem at hand" and helps maximize the readability
of the code. Modeling non-isa relationships (or non-permanent
is-a relationships) with inheritance, on the other hand, I feel
makes code less readable, because it muddies the meaning
of the inheritance relationship. (By meaning, I mean that
the inheritance relationship should always be interpretable
as is-a: the subclass is a more specialized form of the
superclass) That's when some form of composition will usually
come into play, and that's OK in my book, because composition
usually wins compared to inheritance in the ease of change
department. bv
Replies:
|
