Re: Design Questions about static factory classes
Rhino wrote:
Let's say that I want to make a static factory class locale-sensitive but
I don't want to force the user to choose an explicit locale every time
they try to use the class. That suggests to me that I go one of two ways:
1. Provide two private constructors - one that takes a specified locale
and one that uses the default locale - and two corresponding public
getInstance() methods, one of which takes a specified locale and one that
uses the default locale. Then, if the user is comfortable with the
default locale, they use the constructor that doesn't have a locale
parameter, otherwise, they use the constructor that has a locale
parameter and specify the locale of their choice.
Why do you want to provide factory classes at all?
2. Provide a single private constructor that has no locale parameter and
a corresponding public getInstance() method. Also provide getLocale() and
setLocale() methods so that a user can instantiate with the single
getInstance() method and then use setLocale() to alter that locale if it
is not to his liking.
This can be a good solution but can exacerbate concurrency issues.
Generally, not always but generally one should prefer class instances to be
immutable - everything is fixed in the constructor and assigned to final
member variables, and guarded against changes in the internal state of
referenced objects.
Such objects are inherently thread safe.
Even in a single-threaded context, the object that takes a read-only Locale at
construction never risks being used with a different Locale than expected.
Once you make the Locale (or any other attribute) mutable, you have to add
complexity to guarantee that the attribute has a suitable value at any given
time, lest it change between accesses.
For example, collections class instances with an active iterator will throw a
'ConcurrentModificationException' if the collection state changes during the
iteration. This can happen in single-threaded or multi-threaded contexts. In
addition to the complexity in the collection class of checking for and
throwing the exception, there is complexity in the client code of preventing
and/or checking for the exception. Or failing to do so and having a sudden
program crash.
You have to weigh the advantages of having an object whose Locale (or any
other attribute) is fixed at construction for the lifetime of the object,
versus the advantages of permitting an object to alter its state, and perhaps
to live longer. There are also disadvantages to both approaches. (For
example, long-lived objects can put more strain on the garbage-collection
mechanism.)
As for letting "a user ... alter that locale", it's not the user who alters
the locale, it's the code in response to a user action. You could just as
easily instantiate a new object with a different locale in response to a user
action as mutate an existing object.
In your particular case, I'd lay dollars to doughnuts that an immutable Locale
attribute is the better solution.
--
Lew