Giacomo Pati wrote:
On Fri, 30 Dec 2005, 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.
Actually the problem I see with setter injection is that you normally
will open up the setter method (make it public) to your
configurator/instatiator and thus to everybody else.
service() method is already public, so I don't see any departure from existing
practice.
Now, don't tell my
'you can write some IF satements to prevent that. The reason for a
change as Carsten stated was 'I want to write less code'.
The constructor injection IMO allows you to make your member variable
holding the injected objects final as well as checking whether the
component is correctly constructed
If goal is to write *less* code then this code won't have any checks at all :)
Regardless whether it is constructor or setter injection, checks can be written
same way anyway, so I don't see this as an argument.
As for final, that's actually and IMHO a downside: currently you can null out
all component references (and you can do that automatically with setter
injection! whoo-hooo! yeay!) and be *sure* that even if there are any leaks in
system, they are minimized. You can also be sure that you will get clear NPE if
somebody holding & using disposed component, instead of getting undetermined
behavior. So I'm -1 on final references for all of the above reasons.
(especially if it needs a
Configuration object) in the constructor itself. So for me constructor
injection (and only constructor injection, no mixes allowed) is much
more robust over setter injection and needs less code.
For these issues I'm more in favor of constructor injection (if we have
the vision to go the pure way) than setter injection.
In *addition* to setter injection, ecm++ could also recognize
annotations (if running under jdk 1.5).
I do not exclude annotations be it 1.5 annotations or other xdoclet style.
Yep. Xdoclet, though, means pre-processing step - annotations are nicer in this
context.
Vadim
