commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] formatting composite objects
Date Sat, 26 Jul 2008 14:31:31 GMT
Partially answering to myself ...

Luc Maisonobe a écrit :
> Hello,
> I am writing a new Vector3DFormat class in the spirit of the
> ComplexFormat class for input/output.
> Since some parts are common (parsing one component, handling locales), I
> have extracted a CompositeFormat base class from ComplexFormat and will
> use it as the base class for Vector3D and perhaps for future other classes.
> I see that the current ComplexFormat class provides two getInstance()
> static methods whose javadoc is: "Returns the default complex format for
> the current locale". The instance returned is *not* a singleton, it is
> rebuilt each time but the javadoc doesn't says it. Since the class is
> not immutable (there are set methods), it may lead to surprising results
> to users.
> I see two options here:
>  1) We keep a mutable class, and either we replace the two getInstance()
>     static methods by constructors or we rename them createInstance()
>  2) We change the class to immutable and we remove the set methods

The two static getInstance() and getInstance(Locale) methods are
specified in java.test.Format javadoc (but the language cannot enforce a
derive class to implement a static method), so these methods can neither
be removed not be renamed.

The javadoc also recommands creating separate instances for separate

Here is my new proposal, which is basically an extension of option 2 above:

 - we change the class to immutable
   (removing set methods and using final instance fields)
 - we add a comment to the getInstance() javadoc to say the methods
   create new instances each time they are called


> My preference is 2). I don't like mutable objects, especially for a low
> level library which can be reused differently from various other middle
> level libraries and directly by users. Each part of the code should know
> exactly what the instances it uses do, and either use the default one
> provided by getInstance for general purpose, being sure nobody with
> change its settings under the hood or use a specific instance with
> custom settings.
> What do you think about it ?
> Luc
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message