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.
