Soren Hilmer wrote:
> On Wednesday 06 April 2005 22:47, Steve Brewin wrote:
<snipped>
> > 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.
I would prefer never to see code with 9 parameters, be they passed via
constructor parameters or setter methods. Such a Class is violating the KISS
principle, which I whole heartedly support. As I said...
> > 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".
... We should not reject CDI on the basis that it surfaces badly structured
code. From my point of view, surfacing it is a good thing as it highlights
violation of the KISS principle. Something is clearly smelly about...
p = new SomePOJO ("bla", null, null, null, null, "bli", null, null, null);
...that we need to fix.
> > 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.
In the unlikely event that there is no sensible refactoring for SomePOJO,
the SDI approach requires EVERY invoking Class in your example to code...
> p = new SomePOJO ();
> p.setBla("bla");
> p.setBli("bli");
...whereas, once we have narrowed the constructor in a subclass with...
SomeNarrowedPOJO (String aBla, String aBli)
{
super(aBla, null, null, null, null, aBli, null, null, null);
}
... with CDI, every invoking Class codes...
p = new SomeNarrowedPOJO("bla", "bli");
...A little upfront work results in less work for EVERY invoking Class. As
we are looking at producing Classes that are simply and often reused, I'd
say that the cost of the upfront work is worth it. We have delivered KISS
for the invoking Class, which should be our priority.
> >
> > 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.
I was trying to illustrate all of the possible patterns here. You will
actually see this one used with both CDI and SDI for similar reasons. In the
SDI case, people object to having to invoke multiple setter methods multiple
times. In both CDI and SDI cases, I would again say that this often
indicates something is smelly that needs fixing. Though there are legitimate
uses, runtime context's for example.
<snipped>
> > 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.
Great!
> 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.
My view is that each and every one of our Classes should be written using
the same metaphor. We no longer want to be in the Avalon world or join the
EJB world where a Class which is a "component" is special. Rather than
presupposing what might be a "component", every Class should be usable as a
"component" which means every class follows the same metaphor. It would be
straying far away from the KISS principle to require every Class to conform
to both the CDI and SDI contracts. Despite my practical experience
indicating that CDI is the better way, I'd rather vote for SDI than a dual
mode (this is not such a vote).
I dislike SDI as there is no clear contract for what is required to
establish a valid instantiated state, something that CDI gives us explicitly
via the public constructor. With SDI both establishing a valid instantiated
state and operating on the instantiated state are achieved via public setter
methods. How do we know which setter methods we can call when and in what
order? Which setter methods must be called to achieve a valid instantiated
state? CDI is totally clear on the instantiation contract, this is declared
via the sole public constructor. A "dual-mode" Class would make the contract
even more obscure. Also, the presence of the default constructor would
destroy a CDI container's ability to "auto-wire" (no arguments == no
dependencies).
As previously noted, where someone wants to use another metaphor, they are
free to subclass or wrapper the Classes they need to expose as "components"
with the appropriate behaviour. CDI to SDI, SDI to EJB, whatever. We should
adopt just one pervasive metaphor and do it well.
Finally, and most importantly, please understand that I think it is great
that we are finally having this discussion. Søren is doing a great job of
presenting the SDI camp's perfectly reasonable views. What do others think?
Cheers
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
