On 5/19/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave wrote:
> I started playing with Guice and found it very easy to understand and
> use. I've looked at Sping IOC a number of times, but I've never been
> able to figure it out. Guice is different -- it's easy enough for a
> dummy like me to understand. I started working on a Guice version of
> Roller and had the basics working in only a couple of hours.
>
> I'm not proposing that we start using Guice (yet), but I would like to
> explore the idea. So please take a look at the changes in the
> branches/roller_guice branch, which are described below, and let me
> know what you think.
After a quick look through the code I am generally unsure how using DI
here is the right decision, but I think we need to improve the way the
backend code is initialized anyways so at least this is progress. I am
definitely a fan of using DI where it make sense, but I don't think that
DI applies in all situations and I'm not yet convinced that the Roller
backend should really use DI.
The question for me is: do we need a framework at all. We can do DI
"manually" and make improvements in the bootstrapping without using a
framework at all.
The advantage of bringing in a DI framework, from my point-of-view, is
that it gives us a standard way to deal with all those cases where we
need some service -- like a DatabaseProvider, etc. Right now, we use a
variety of different mechanisms across the code-base.
In specific, based on the way our code operates, I think it is most
appropriate that any instance of the Roller interface should be treated
as immutable. Our code does not in any way support (or need to support)
modifying an instance of Roller after it has been constructed, so for
proper api practices we should be forcing instances of the Roller object
to be immutable. It is for this reason that I think that DI for the
Roller backend is not appropriate.
This doesn't mean we can't use Guice or some other framework to help
with wiring up the backend, it just means that we should be structuring
our code to properly enforce a solid api. The one big change that I
would make different from what you currently have is that instead of
providing public setXXXManager() methods which can be injected, instead
those manager instances should be passed into the constructor or
whatever is responsible for building the instance. This way we still
use Guice to wire up the backend and we enforce immutability which is
appropriate for our api.
Yes, simply using constructor injection addresses that concern. It's a
trade off. Do you want an ugly constructor with lots of arguments or a
bunch of setters. Neither is exposed in the "public" API of
RollerFactory and the Roller interfaces.
One other thing that I think we should take more seriously in our
backend code is how we enforce the singleton pattern. Currently we do
not enforce that pattern in a proper way and it's always kind of bugged
me. To truly enforce the singleton pattern we should only provide
private constructors and the single instance of the class should be
created statically and returned via a public static method. Since the
code is supposed to enforce the singleton pattern on all backend
instances I think we should be properly following this pattern, but most
importantly this should be the case for the Roller object.
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.
- Dave
