james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: SpringJames vs. JamesNG
Date Wed, 06 Apr 2005 20:47:38 GMT

> No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I
> prefer using the
> JavaBean approach instead of CDI.
> My concern is that CDI does not facilitate optional
> properties very well.
> If you have some POJO, with just 2 optional properties that
> will lead to 4
> constructors!! This is what I call constructor bloat.

Many of my thoughts regarding a container for James are already recorded in
the mailing lists. I will not repeat them here.

My interpretation of the CDI metaphor allows no tolerance for ambiguity.
There should be exactly one public constructor for a Class that encompasses
all possible parameters. Optional parameters may be passed into this
constructor as null. This is the contract a Class honours. As there is only
one constructor, there is no "constructor bloat".

You might worry that this leads to "parameter bloat", but practical
experience reveals that with a well structured architecture the number of
parameters passed is not overwhelming. Moreover, it helps in the creation of
this well structured architecture by focusing thought on the exact needs and
responsibilities of each Class. This follows the old adage of "do one thing,
do it well".

On the rare occasions when this approach leads to too many redundant
parameters for a particular application's usage of the Class, the
application's developer may create or re-use a subclass with a public
constructor that offers just the required parameters. Of course this will
not work if the Class of interest has been marked final. Then a proxy Class
is required to do the same job.

Another way of avoiding "parameter bloat" is to identify those parameters
common to many of an application's Classes and gather them together in a
single Class so that instances can be injected as a single object.

The key point is that CDI does not force us to deal with a n*n-1 constructor
problem. There are a number of patterns that can be applied to avoid this
and the associated "parameter bloat" problem.

Getting into the CDI mindset is an evolutionary journey. First forsaking
Service lookup, then appraising the upsides and downsides of each of the
dependency injection approaches.

Much of my commercial time is currently spent facilitating architects and
developers making this journey. A good starting point is to visit
http://picocontainer.codehaus.org. Next, choose a component (set of
inter-operating classes) with which you are familiar and refactor them to
follow the CDI metaphor. As understanding grows the entirely reasonable
doubts dissipate.

Prior to this journey being completed there are no criteria to evaluate the
strengths and weaknesses of any given container. As we don't know what we
need a container to do, how can we say it satisfies our needs?

This is why I have steered clear of advocating any particular container thus
far. However, if you hadn't guessed already, my view is that CDI is the best
of the current bunch of DI approaches.

One further point is that we do not need to and should not code for a
specific container. Rather we should develop to our chosen DI metaphor. This
leaves people free to deploy our DI POJOs in any container supporting the
metaphor, or wrap them for deployment in containers supporting other
metaphors, such as flavours of J2EE EJBs and Connectors.


-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message