james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Soren Hilmer <soren.hil...@tietoenator.com>
Subject Re: SpringJames vs. JamesNG
Date Fri, 08 Apr 2005 08:56:33 GMT
On Wednesday 06 April 2005 22:47, Steve Brewin wrote:
> > 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".
>
Okay, so you prefer code looking like:
p = new SomePOJO ("bla", null, null, null, null, "bli", null, null, null); 

to code looking like:
p = new SomePOJO ();
p.setBla("bla");
p.setBli("bli");

I must say, I prefer the latter.

> 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.

This I find complex, and a good argument against CDI. I favour the KISS 
principle.

>
> 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.
>

Sure this works, but unfortunately have the effect that classes are created 
for the sole purpose as being place-holders. This leads to a more complicated 
class-hierarchy. Which IMO is to be avoided. Again KISS.

> 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.
>

Unfortunately all these patterns to deal with parameter bloat introduces more 
complexity and are thus violating the KISS principle.

> 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.

I agree that we should not focus on any given container. Apparently we cannot 
agree upon which concept JavaBean/CDI is the way to go, so I then move in 
favour of supporting both. That way we can run in any POJO container. As 
someone (sorry forgot who) posted earlier this is quite easy as the CDI 
constructor can be implemented like:

SomePOJO (String a, String b, String c, String d) 
{ 
   this();
   setA(a); setB(b); setC(c); setD(d);
}

Alongside the mandatory no-args constructor.

--Søren
-- 
Søren Hilmer, M.Sc.
R&D manager		Phone:	+45 72 30 64 00
TietoEnator IT+ A/S	Fax:	+45 72 30 64 02
Ved Lunden 12		Direct:	+45 72 30 64 57
DK-8230 Åbyhøj		Email:	soren.hilmer <at> tietoenator.com

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


Mime
View raw message