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