Hi Tim
Eeek, I didn't mean to start an argument about DI ;)
It sounded a "little" like it ;)
In my humble opinion it's a pretty direct equivalent of a service
locator for most custom applications (which is what most of us
build). I prefer the service locator because I find it simpler/less
magic. Others prefer DI and that's fine too.
They do the same but are also different in their focus.
Either way (push or pull) you're committing to a level of dependency.
A constructor argument or a setter is better than depndency on some
lookup class IMO.
What I like is that I can see my dependencies (those that matter) and
I can easely mock them when unit testing.
How would you else do it? Lookup methods?
Perhaps I wasn't clear in what I was saying. I don't like that the
dependencies are public for everyone to see because in the normal
operation of the class those methods should not be called except by
the thing injecting the dependencies.
I like that they're public so that people CAN see what dependencies they
have. It's really IMO a question of reuse to me. If you don't want reuse
encapsulate all you can (e.g. ServiceLocator), but if you want reuse
make it clear what dependencies your class has so the others can see it.
I really hate when I need to reuse code from other projects and suddenly
I'm faced with a ton of dependencies that I first of all can't see
exists and often ServiceLocators that I suddenly have to understand (how
are do I tell them where they what implementations to use, property
files, xml files, java code). If each project have their own way of
doing ServiceLocators it hurts reuse.
Note: When I talk about doing dependency injection and showing
dependencies then I'm only focusing on course grained objects (services,
DAOs, resources, strategies, infrastructural objects, etc.). Some
dependencies are best encapsulated.
Using private makes unit testing almost impossible (you need to
supply a dependency somehow) and protected makes it harder
(subclassing is needed), so IMO public is the right access level.
Are you still coding C++ ;)
Noooo, gave up on that a long time a go ;-)
I always forget that protected is *weaker* than package access, but
both allow access to all classes in the same package. That's one of
the reasons I always have my unit tests in the same package (though
different source tree) as the production code.
Again, my focus is on displaying my dependencies (for the dependencies
that can change and those that matter in reuse cases) so public is the
right level for me.
I like that I can specify it on the field, but I would still like to
keep my public setter.
All the new stuff is additional. If you want to continue to use the
setter, you will need to annotate the setter though.
Okay, so they injection will happen on the field directly if it's
annotated (as you can understand by my question then I haven't had time
to try it yet)?
/Jeppe
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
