Richard Kennard wrote:
Alan,

Thanks for your continued support.

I find the 'static factory method' approach interesting, but I'm a little confused. You cite 'being able to return a subclass' as an advantage. However, you also recommend a private constructor and classes with private constructors can never be subclassed?

Regards,

Richard.



Hi Richard,

I think one of the design goals for this class was to make sure it is easy to use in JSPs. Do you know if it makes much (or any) difference to JSP applications
whether objects are created by constructor or by static factory method.

Static factory methods are definitely useful if we think that it might be useful to
have different implementation classes in the future, or where there may be
important differences in the ways that these objects are created in the future.
This can be addressed by using different createXXXX() method names.
Also, I believe that there will be some work done in jdk7, which addresses
the tagging of factory creation methods more clearly, so they stick out in the
documentation a bit more.

I also quite like the idea of method chaining, but again that is not a critical question at this point. We should discuss this point definitely, when it comes to finalising the API
after the CCC approve the initial proposal.

The main question I think is concerning the mutabilty of the object and whether to expose the implementation map. Clearly, the object has to be mutable, and it probably needs to be specified as being unsynchronized. I think I agree with Alan about the danger of exposing the internal map. Even if it does not cause a problem
initially, it could seriously restrict how the class develops in the future.

- Michael.

Reply via email to