Re: Constructor or getInstance() method

From: Ryan Stewart (zzanNOtozz_at_gSPAMo.com)
Date: 02/08/05 

Date: Mon, 7 Feb 2005 19:06:12 -0600

"Eric Sosman" <eric.sosman@sun.com> wrote in message
news:cu8lvs$6ro$1@news1brm.Central.Sun.COM...
> java.lang.Boolean
> java.lang.Byte
> java.lang.Double
> java.lang.Float
> java.lang.Integer
> java.lang.Long
> java.math.BigDecimal
> java.math.BigInteger
> java.util.Calendar
>
> ... and probably others. (An oddity: Why is java.lang.Character
> not on this list?)
Minus java.util.Calendar (it has protected constructors) and plus
java.lang.Short, yes. I was trying to think of getInstance methods, not factory
methods in general, and since I never use the factory methods of those
classes... That is something I've wondered about in the past, now that I realize
it. The only thing you could really do with java.lang.Character is let it take a
String, and that's probably asking for trouble. I suppose you could also take
ints and a character encoding to interpret it.

>> I don't know of any good
>> reasons to have both public constructors and factory methods.
>
> Joshua Bloch suggests a few in "Effective Java." My
> copy is at home, so these few are from (hazy) memory:
>
> - Efficiency: A constructor must produce a brand-new
> object, whereas a factory method can (sometimes) re-use
> an existing object. `new Boolean(false)' must create
> a brand-new Boolean, whereas `Boolean.valueOf(false)'
> can just return the Boolean.FALSE object.
I wouldn't consider this a good reason to have both. Especially in the case of
Boolean, I would argue that a public constructor is bad.

> - Flexibility: A constructor must produce an object of
> the stated class, whereas a factory method is free to
> return an instance of a subclass. (Conceded: In this
> sort of situation, it might be more usual to expose only
> the factory methods and hide the constructors.)
My thoughts exactly.

> - Clarity: Constructors are nameless, so if you want to
> provide multiple constructors you must give them different
> argument signatures. Factory methods have names, so they
> can be distinguished even if their signatures are identical.
> Thing of a complex-number class providing a constructor
> `Complex (double x, double y)' for numbers in Cartesian
> form, plus `static Complex polar(double rho, double theta)'
> as a factory method for numbers in polar coordinates. (For
> symmetry, `static Complex cartesian(double x, double y)'
> would probably be there, too.)
That does make some sense, though for ease of reading and maintenance in this
situation, I would go with all factory methods, because who is really going to
go in looking for a constructor to create objects one way and a method to create
them another? It it's inconsistent and illogical.

Relevant Pages

  • Re: =?UTF-8?B?SmF2Ye+/vXMgQnJva2VuIEJvb2xlYW5z?=
    ... Ian Shef wrote: ... Obviously the choice balances the cost of the one idiom against the other. ... Joshua Bloch's /Effective Java/, Item 1, is, "Consider static factory methods instead of constructors". ...
    (comp.lang.java.programmer)
  • Re: General rule for constructors
    ... work out the ratio of public constructors to factory methods. ... Connection con = DriverManager.getConnection; ...
    (comp.lang.java.programmer)
  • Re: Could an object refuse to be created!?
    ... Justin Rogers wrote: ... > to valid input criterion, that you might instead use a factory method. ... > Factory methods demonstrate, better than constructors, that work is going ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: General rule for constructors
    ... work out the ratio of public constructors to factory methods. ...
    (comp.lang.java.programmer)