Re: Interface inheritance vs Implementation inheritance.
Peter Duniho wrote:
On Tue, 19 Feb 2008 13:27:19 -0800, Daniel Pitts
<newsgroup.spamfilter@virtualinfinity.net> wrote:
[...]
I'm not saying that it is always and automatically bad. I guess my
main point was that there are situations where, due to many language
limitations, it is necessary to avoid a massive amounts of
boiler-plate delegation code. If you had a convenient way (say one or
two source lines) to "borrow" all/most implementation from another
class, would you still feel that implementation inheritance is still
necessary?
I guess I can only at this point answer "it depends". It seems to me
that the current, widely-used implementation inheritance syntax is
pretty much just that: a convenient way to borrow implementation from
another class.
Currently, inheritance of classes "borrows" both the implementation
*and* interface. The thing is that interface and implementation are
borrowed together, and you have to take extra steps if you only want the
implementation or only the interface. I think it might be good to
separate those concepts.
I would have to see what this alternative syntax would look like to
answer more definitively, but it's not clear to me that it'd be any
different in practice from simply inheriting an implementation directly
(assuming that, as with interfaces, a "borrowing" class still tests
"true" for whether it "is" one of these "borrowed" things...if that's
not the case, then I'd say that's a glaring omission of the proposal).
If the interface "lives" separately from the implementation, then the
borrow can choose to also borrow the interface (or some parent
interface, or some composite interface).
Or, looking at the question from another angle, if it's okay to "borrow"
implementation from another class, what does it matter whether it was
borrowed in the form of inheritance or in the form of a new type of
composition that looks just like inheritance?
Because the borrowing can be more pick-and-choose in the new way,
instead of the all-or-nothing of inheritance. Also, there are times when
your interface maps one-to-one to another class for a few methods. It
could be easier to pick out those methods.
I'm reading this in the Java newsgroup, and perhaps the "comp.object"
crowd has a more thorough academic understanding of OOP practices and
principles than I do. But I admit, based on what you've written so far
I'm not really clear on the distinction between the way things are now
and what you're suggesting they could be, at least from a practical
standpoint.
I guess the main difference is the syntax, but I believe it adds
flexibility too.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>