Tim Quinn wrote:
> Thanks for the notes. Some added comments inserted...
>
> Bill Shannon wrote:
>> I think Roberto and I disagree on this.
>>
>> I like the builder pattern with static factory methods that return a
>> builder object, from which you get an object representing the running
>> app client container.
>>
>> I think having different builder (config) classes for the different
>> cases is overkill. If some methods really need to be prohibited in
>> certain cases, I think IllegalStateException is fine.
> Easily changed.
I have no problem with this, esp. with future evolution in mind.
>> I definitely don't like having "startContainer" be a static method that
>> operates on a config, rather than being a method *of* the config
>> (builder).
> I have changed this so the start() method is on the builder class and
> returns the running AppClientContainer. I would propose to rename the
> "Config" to "Builder" because, I would not normally expect something
> called a config object to able to construct an ACC whereas I would
> expect that of a builder object.
I'm not so sure about the "builder" terminology. In this case, there are
no "parts" being built and the start() method serves a dual-purpose,
since it also starts the container. Using a fluent interface for easier
property setting doesn't make it into much of a builder. Maybe a name
like AppClientContainerConfigurator would be better.
I'm trying hard to avoid suggesting calling it a "Factory", of
course... :-)