commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] Extend / Override
Date Wed, 10 Sep 2003 14:09:21 GMT
I think the encapsulation is better when you delegate to the existing service (the approach
on the
HiveMind site), rather than subclass it.

In the world of HiveMind, there may not be a "class" to subclass from; lots of stuff could
be
generated on the fly using Javassist magic. For example, you may want to override an EJBProxy.

In addition, subclassing is just the start; there's also issues related to the properties
of the
super-class: you have to duplicate its configuration/initialization.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
> Sent: Wednesday, September 10, 2003 10:04 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] Extend / Override
> 
> 
> Thinking again with a clear mind this morning it is apparent 
> to me that 
> the extends is bad when you don't know what the 
> implementation is going 
> to be. Never mind.
> 
> -Harish
> 
> Harish Krishnaswamy wrote:
> 
> > I think the multi-override feature will become important 
> when it comes
> > to distributing service components/modules so I can package 
> and ship a 
> > service component and let the clients override their desired 
> > functionality. Talking of overrides, is it severly bad to extend a 
> > default service instead of implementing the interface and 
> delegating 
> > the common behavior? After all it is the same service and clients 
> > still code against interfaces. And it will be much easier 
> to implement 
> > the extend feature than the override, right?
> >
> > -Harish
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


Mime
View raw message