cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Simplifying component handling
Date Sat, 31 Dec 2005 03:47:10 GMT
Torsten Curdt wrote:

> On 30.12.2005, at 20:21, Vadim Gritsenko wrote:
>> Carsten Ziegeler wrote:
>>> Gianugo Rabellino wrote:
>>>> I'm definitely not a fan of constructor injection, exp. when we
>>>> consider how (way too) often we resorted to inheritance in Cocoon
>>>> components. Now, while interface injection is clearly out of  fashion,
>>>> sticking with Avalon/Excalibur also means that it would be difficult
>>>> to get around the container (e.g., how do you release components  with
>>>> your approach? I assume Excalibur still kinda needs that).
>>> Yes, Excalibur still needs it - but it's easy. Bascially, you  
>>> "emulate"
>>> the service() method on construction of the object and then you
>>> "emulate" the dispose method when destroying the object.  Everything 
>>> our
>>> ecm++ needs to know is there. As I said, I've done this in  Fortress 
>>> and
>>> we can use that code in ecm++ as well.
>>> And we could implement setter injection with some kind of auto  
>>> wiring as
>>> well. It's not really that harder. But using setters again  requires to
>>> code more than using a constructor.
>> I'm with Gianugo on this one - I'd better have setter injection  
>> instead of constructor injection.
> Maybe this is becoming a bit OT but could you guys give some reasons  
> why?
> I personally prefer contructor injection over setter injection  
> because of
> the clear contract. As soon as the object is instantiated it can be  
> used.
> With setter injection you have to have some weird behind the scenes  
> object
> life-cycle.

Well, personal preferences aside, there are pros and cons in any 
situation.  First, any component that is able to be accessed is fully 
instantiated.  Nothing more needs to be done.  Setter injection vs. 
Constructor injection doesn't change a thing here.  Both styles of code 
encorage different coding conventions.

Setter Injection
Familiar JavaBean style interface, natural to many Java developers, and 
easy to use introspection based tools.  Encorages failsafe design so 
that almost all components are optional.  In short, the absense of other 
components cause the bean to work with diminished capacity.  An example 
is the DataSource object from the SQL package.  In fact, that component 
would work out of the box in this type of environment.

Constructor Injection
Very robust design, less familiar to many Java developers, but natural 
enough.  Encourages tight encapsulation and failfast design so that 
almost all components are required.  In short, the absense of other 
components can cause the component to crash.  Examples include just 
about any unmodifiable POJO object.

Spring is the XML laden container of choice for Setter Injection while 
Pico is the code it yourself container of choice for Constructor Injection.

My personal preference would be for Pico primarily because it is not 
nearly so XML heavy.  Also note that Pico can work with setter injection 
as well as constructor injection.  My Java5 Dojo container works with 
Setter injection out of the box, and can easily be extended for 
constructor injection.  Through the "Multi-Dojo" wrapper, it could have 
components designed for either style of development work seamlessly with 
each other.  Even if you don't use it, you might take a look at the 
code.  It's pretty straight-forward and a simple design.

View raw message