hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Iignatyev <kgignat...@yahoo.com>
Subject The interface vs. pojo argument rages on.
Date Tue, 28 Dec 2004 17:23:33 GMT
>>For me, part of the distinction between an object (a POJO, a bean,
>>whatever name you like) and a service is that a service implements an
>>interface.

IMO From a user standpoint service is that I get from a factory and a 
POJO, a bean, whatever is that I create with new keyword myself.
How about such a distinction?

>>Services will have a more complex life cycle, and can be intercepted,
>>and can be instantiated on first use (rather than first reference).

It could be applied to classes if they implement lifecycle interface (for extensive cleanup/startup),

or subclass might implement lifecycle interface automatically.

>>It is true that you can "intercept" a class, creating a proxy that's 
>>really a subclass, with every method overridden in some way.  That how
>>EasyMock Class Externsion works, but I'm dubious.  Forces you to use
>>bytecode enhancement to do interception, rather than JDK proxies.

I would not say that subclass based approach forces bytecode manipulation, although it might
be easiest and most 
performant  approach if based on CGLIB (  see performance estimations at http://kgionline.com/articles/aop_1/aop_perf.jsp
).

Alternative to bytecode machinations :) might be good old code generation. Which might well
happen on the fly as long
 as runtime has access to the java compiler. 




Howard Lewis Ship wrote:

>The interface vs. pojo argument rages on.
>
>I hope, in 3.1, to have a way of building POJOs using something like
>BuilderFactory.  One name for these is "resources", I kind of prefer
>"beans" ... distrinct from services.
>
>Services will have a more complex life cycle, and can be intercepted,
>and can be instantiated on first use (rather than first reference).
>
>It is true that you can "intercept" a class, creating a proxy that's
>really a subclass, with every method overriden in some way.  That how
>EasyMock Class Externsion works, but I'm dubious.  Forces you to use
>bytecode enhancement to do interception, rather than JDK proxies.
>
>For me, part of the distinction between an object (a POJO, a bean,
>whatever name you like) and a service is that a service implements an
>interface.
>
>
>On Tue, 28 Dec 2004 09:55:04 -0600, kgignatyev <kgignatyev@yahoo.com> wrote:
>  
>
>>Cool!
>>
>>How about another thing: making Interface optional? I am all for
>>encouraging of the good design, but enforcing it at the price of lessen
>>convenience does not seem right.
>>
>>Less is MORE!
>>
>>And the simplest thing that works is the class itself, when HiveMind
>>factory is used to obtain object instance it should not be different for
>>the rest of application if it returns an implementation of the interface
>>or a subclass that wraps its parent with necessary interceptors.
>>
>>If a need for the class to be an interface will arise (multiple
>>implementations, mocks, etc.), it could be easily done with refactoring:
>>the class becomes interface and interface class parameter will appear in
>>HiveMing factory definition. That should not affect rest of application
>>at all.
>>
>>Also: see http://picocontainer.org/Two+minute+tutorial  when a class
>>gets registered in Pico with
>>pico.registerComponentImplementation(Boy.class); it could be retrieved
>>by its interface Kissable. Having such a feature in HiveMind would not
>>hurt IMO
>>
>>
>>Howard Lewis Ship wrote:
>>
>>    
>>
>>>Knut agrees; he's added some much smarter code to HiveMind's
>>>BuilderFactory that works darn hard to find the right constructor and
>>>provide it with the correct parameters.
>>>
>>>
>>>On Mon, 27 Dec 2004 13:38:33 -0600, kgignatyev <kgignatyev@yahoo.com> wrote:
>>>
>>>
>>>      
>>>
>>>>Why HiveMind requires constructor parameters if there is only one
>>>>constructor, or only one constructor that might be satisfied with
>>>>services from the repository?
>>>>Kind of contradictory to "Less is MORE" ideology.
>>>>
>>>>Could HiveMind in version 1.1 adopt something like Pico's use of
>>>>getGreediestSatisfiableConstructor()?
>>>>
>>>>http://www.picocontainer.org/versions/1.1/apidocs/org/picocontainer/defaults/InstantiatingComponentAdapter.html#getGreediestSatisfiableConstructor(org.picocontainer.PicoContainer)
>>>>
>>>>--
>>>>Thanks,
>>>>
>>>>Konstantin Ignatyev
>>>>
>>>>http://www.kgionline.com
>>>>
>>>>PS: If this is a typical day on planet earth, humans will add fifteen million
tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create
seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one
million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population
by 263.000
>>>>
>>>>Bowers, C.A.  The Culture of Denial:
>>>>Why the Environmental Movement Needs a Strategy for Reforming Universities
and Public Schools.
>>>>New York:  State University of New York Press, 1997: (4) (5) (p.206)
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>      
>>>
>>--
>>Thanks,
>>
>>Konstantin Ignatyev
>>
>>http://www.kgionline.com
>>
>>PS: If this is a typical day on planet earth, humans will add fifteen million tons
of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two
miles of desert, eliminate between forty to one hundred species, erode seventy-one million
tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population
by 263.000
>>
>>Bowers, C.A.  The Culture of Denial:
>>Why the Environmental Movement Needs a Strategy for Reforming Universities and Public
Schools.
>>New York:  State University of New York Press, 1997: (4) (5) (p.206)
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>>
>>
>>    
>>
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message