commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [HiveMind] Extend / Override
Date Wed, 10 Sep 2003 14:21:18 GMT


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
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message