You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Konstantin Iignatyev <kg...@yahoo.com> on 2004/12/28 18:23:33 UTC
The interface vs. pojo argument rages on.
>>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 <kg...@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 <kg...@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