A simplistic approach, which may not be appropriate for your context, is
to convert from thinking of the object as implementation multiple
behaviors to one where the object contains and exposes/provides multiple
objects that themselves implement the behaviors. This would entail a
transition from thinking of the object as having multiple "is a" to
having multiple "has a" characteristics.
So instead of
new TheClass().doSomethingFrom_iA_interface();
you would use
new TheClass().getA().doSomething();
The up side of this approach is less replication of code via delegation,
and the interfaces of the contained classes are free to evolve without
need to keep the containing class up to date. The down side is the
additional level of indirection needed to access the objects that
implement these behaviors. There is also the issue of weakened
encapsulation to consider, but this may not be a bad thing because there
may be benefits to making the sources of these behaviors explicit.
^^^^^^^^^^^^^^^^^^^^
Mike Silverstein������������������
SilverMark, Inc.������� �
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L Merrill
> Sent: Wednesday, March 30, 2005 8:31 AM
> To: Research Triangle Java User's Group mailing list.
> Subject: Re: [Juglist] multiple inheritance and/or a better
> aggregation method?
>
>
> Greg Jones wrote:
> > I guess I'm missing your point. Do you mean support multiple-extends
> > not multiple-implements? Java does support multiple-implements?
>
> Neither, really. It isn't "extends" because the class would
> not inherit identity (instanceof) from the default
> implementation classes (only the interfaces that it
> implements). But unlike implementing multiple interfaces, it
> does inherit (in a sense) behavior from those classes.
>
> > Have you reviewed some common object patterns to see if they will
> > satisfy what you need? You may have to re-model what your thinking
> > but it may be a cleaner 'Java' way of doing it.
>
> I've looked at some. None seem to satisfy the requirement
> cleanly. The obvious (and simplest) solution is the delgation
> pattern - encapsulate the default implementation classes and
> implement each of the interface methods with a call to
> encapsulated class. It satisfies all the requirements but
> results in a lot of extra code that could be avoided.
>
> > If this is not what you want, and your are talking about delegates
> > then your are stuck thinking outside the 'Java' box. .Net has this
> > capability but I don't think Java has it in the JDK 1.5.
>
> It would be similar to delegates. But as usual, the M$
> implementation of just delegating a single method signature
> is very procedural. Whereas my vision seems very OO (at least to me).
>
> C
>
>
> --
> --------------------------------------------------------------
> -----------
> Chris Merrill | http://www.webperformanceinc.com
> Web Performance Inc.
>
> Website Load Testing and Stress Testing Software
> --------------------------------------------------------------
> -----------
>
> _______________________________________________
> Juglist mailing list
> [email protected]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
>
> --
> No
> virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.5 - Release Date: 3/29/2005
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.5 - Release Date: 3/29/2005
_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org
