The getInstance() method can not return a sole instance because the default locale can change via java.util.Locale#setDefault
The purpose of the format setters is to provide similar behavior as found on java.text.NumberFormat with the ability to modify formatting parameters. They provide a convenience to having several methods to alter the parameters for each of the number parts. I would not be in favor of making the type immutable because it is contrary to the design of the standard Format types. On Sun, Jul 27, 2008 at 2:16 PM, Phil Steitz <[EMAIL PROTECTED]> wrote: > Luc Maisonobe wrote: >> >> 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 >> >> 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 ? >> > > I agree with you on the name change s/get/create or "new" but I think users > of ComplexFormat need to be able to pass in formats, so the factory itself > either needs to be mutable or have these things in constructors. In theory, > someone might want to use the setters; though I can't think of a real world > use case. The problem with the name change is backward compatibility. I > would be +1 for deprecation and introducing "create" or "new" methods. > > Base CompositeFormat class looks good. > > Phil >> >> Luc >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
