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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
