This reminds me why I did not use the pattern in that way:
1) it is inefficient and a maintenance headache if you have lots of
variables. There are 2 copies of all the variables in that example --
one in the builder and one in the enclosing class.
2) One can program around that problem by creating yet another class,
really a C struct, that just holds all the variables. But then there
are visibility issues so it would be cleanest to add this third class
into the Server class.
3) Now the Server class is REALLY getting big and unwieldy for no good
reason. Non-trivial nested classes are another headache and make the
code much harder to read and understand. The way it works now -- all
the grisly details of validating/verifying/setting defaults happens
inside the Info class. The Server object enjoys the fruits of those
labors.
4) I think a new flavor of the Builder Pattern can be used here to make
it friendlier. More details later...
===================
Bill Shannon wrote:
> Byron, here's what we were talking about, in case it wasn't clear to
> you...
>
> http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html
>
>
> Roberto, can you explain again why you don't think this applies to the
> app
> client container case?
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.