Re: Composition vs. Inheritance (Was: colored point redux)

On Mon, Feb 26, 2007 at 01:35:40PM -0500, Daniel Yoo wrote:
> >Perhaps the strength of extension is really in the other scenario I 
> >mentioned: the case where, for example, an Employee is also a Person, 
> >and thus inherits all fields and methods from Person. How would you 
> >implement that with composition? I've seen people recommend something 
> >like
> >
> >class Employee {
> >	Person person;
> >
> >	...
> >}
> >
> >which would then be used like
> >
> >anEmployee.person.someMethod(...)
> >
> >but that feels to me like taking a step back from object-oriented 
> >programming, throwing away its advantages.
> 
> 
> Hi Bob,
> 
> Ok, so we'd like an Employee to look like a Person then?  Employee can 
> dispatch methods off to the Person object.
> 
> /******************************************/
> class Employee {
>     Person person;
>     Object someMethod(...) {
>         return person.someMethod(...);
>     }
>     ...
> }
> /******************************************/

Well, now you are exactly where I wanted you to be. At this point, you 
are explicitly writing down what extension would give you automagically. 
I've seen someone make the argument that this is actually a Good Thing, 
because the interfaces of what would be subclasses under extension won't 
change in response to changes in their superclasses.

However, I contend that matters are actually worse under composition 
than under extension. Instead of having methods from superclasses 
automagically available to subclasses, you have to write wrappers by 
hand. If an incompatible change occurs in a superclass, not only do you 
have to change the code that deals with instances of (subclasses of) 
that class, you also have to go and adapt your wrapper methods. All this 
to get the advantage of more stable subclass interfaces, which you could 
have gotten anyway by adding compatibility methods to your subclass if 
the superclass changed.

> I don't think it's something that conflicts with OOP programming: it's 
> just stateful agents talking to each other across interfaces.  This does 
> bring up the question of multiple composition again, though.  What do we 
> do with:
> 
> /******************************/
> class Employee {
>     Person person1, person2;
>     ...
> }
> /******************************/
> 
> where it's no longer completely obvious what we mean by 
> Employee.someMethod()?  Abstractly, this feels like the whole problem 
> behind multiple inheritance, and I'm not sure what the best solution to 
> this is besides explicitely writing out what Employee.someMethod() means.

As you said, this is a general issue with multiple inheritance. I would 
guess that every object system with multiple inheritance that is worth 
its salt provides a way to indicate which of multiple methods are really 
meant.

> Writing out the dispatch functions isn't technically a big problem, 
> although it is extra typing.  It's a one-time cost,

No, it's a cost that you incur at the onset, and also when underlying 
interfaces change.

> and pretty much no-brain typing that could be automated through 
> something like macros.

At which point you end up with something equivalent to extension.

[macros that automate delegation snipped]

> The point I'm trying to make, though, is that the and the silly amount of 
> typing we have to do delegation is something that can be mostly 
> eliminated, since it's just textual gruntwork.

...provided that the language provides macros. Weren't you arguing 
against macros, earlier?

> Another tangent: perhaps one could do something like "environmental 
> acquisition" to get much of the advantages of inheritance?  It feels like 
> there's something in 
> http://www.ccs.neu.edu/home/lorenz/research/acquisition/ that relates to 
> what you're bringing up; I haven't thought about it deeply yet.

Will read that later.

Thanks for your input so far.

Bob

-- 
This is a Unix email virus. It works on the honor system:

If you're running a variant of Unix, please forward this message to
everyone you know and delete a bunch of your files at random.

Thank you for your cooperation.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF4y2Gfb9wcmD+WN4RApsWAJ0TR6Xr2Xrj5ywGPsI5Vbtghj3p8ACZAW/6
YzDPKtP8aqi3jx09AOq9bIw=
=Xpwx
-----END PGP SIGNATURE-----