You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Harish Krishnaswamy <hk...@comcast.net> on 2003/09/10 07:02:21 UTC
[HiveMind] Extend / Override
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
Re: [HiveMind] Extend / Override
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Howard M. Lewis Ship wrote:
>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.
>
Ah, yes, I did not think about that, clearly! Thanks, this is helping me
a lot.
>
>--
>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
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] Extend / Override
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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
>
Re: [HiveMind] Extend / Override
Posted by Harish Krishnaswamy <hk...@comcast.net>.
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
>
>