I don't think we are talking about annotating a private variable, IMO
the way the Roller implementations should be injected using Guice is as
such ...
@Singleton
public class RollerImpl implements Roller {
private final xxxManager = null;
private final yyyManager = null;
@Inject
public RollerImpl(XXXManager xxx, YYYManager yyy) {
this.xxxManager = xxx;
this.yyyManager = yyy;
}
public XXXManager getXXXManager();
public YYYManager getYYYManager();
}
... this allows us to adequately use DI to wire up the Roller backend
using Guice while maintaining an appropriate api for how the Roller
implementations are meant to be used, namely being immutable.
One other thing that I forgot to mention before but while I am not a fan
of is the separate init() method which was added. I can't really tell
from the code why this is needed, my only guess being that you had to
externalize the init() code from the constructor because the
dependencies are injected after construction. If that's the case then
that would be another reason why I favor injecting into the constructor
rather than public setter methods, because then the init() code can take
place in the constructor where it is 1) most appropriate and 2)
guaranteed to happen before the object is returned for use.
-- Allen
Matt Raible wrote:
If to use the annotations stuff from Guice or Spring 2.1, you can
annotate private variable. While this is a cool feature, it doesn't
make things easier to test AFAIK.
Matt
On 5/19/07, Dave <[EMAIL PROTECTED]> wrote:
On 5/19/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> > Some objects are going to be singletons, and we can declare that, but
> > I don't see the need to "enforce" it. Who are we protecting ourselves
> > from? If a DI framework wants public constructors, I don't think that
> > is a problem at all.
>
> don't see the need to enforce it? i don't understand that logic, if a
> class is supposed to be a singleton then why would you not enforce it?
> the whole point of a singleton is that it's supposed to allow for
*only*
> one instance, if you don't enforce that then someone can do the wrong
> thing with your code.
Yes, I agree. Generally, it's a good thing to enforce singletons, but...
> enforcing that is to protect potential Roller users who want to
build on
> the Roller code as a platform so that they do the right thing.
If a DI framework requires classes to have public constructors, even
those that are singletons -- you would completely rule out the usage
of that framework? I think that rules out both Spring IOC and Guice
and I'm not ready to rule out either.
There is some discussion of implementing singletons with straight
Java, Spring and Guice here:
http://docs.codehaus.org/display/GROOVY/Singleton+Pattern
- Dave
