When to use the constructor and when to use the getInstance () method (static factory methods)?

Question

• When and how should we use the constructor

  Foo bar = new Foo(); 

• And when and how should we use getInstance () (static factory methods)

   Foo bar = Foo.getInstance(); 

What is the difference between the two, I always use the first method, but when to use the second method?

Answer 1

Everyone seems to be focused on singles, while I think it's about constructors versus static factory methods.

This is actually Point 1: consider static factory methods instead of Effective Java constructors from Joshua Bloch:

Item 1: Consider static factory methods instead of constructors

The usual way for a class to allow a client to get an instance of itself is to provide a public constructor. There is another method that should be part of every toolkit programmer. A class can provide the public with a static factory, which is just a static method that returns an instance of the class. Here is a simple example from Boolean (a boxed primitive class for a primitive Boolean type). This method translates a Boolean primitive value into a Boolean object reference:

 public static Boolean valueOf(boolean b) { return b ? Boolean.TRUE : Boolean.FALSE; } 

Note that the static factory method does not match the factory template method from design patterns [Gamma95, p. 107]. The static factory method described in this clause does not have a direct equivalent in the design of patterns.

A class can provide its clients with static factory methods instead of or in addition to constructors. Providing a static factory method instead of a public constructor has both advantages and disadvantages.

Benefits (book quoting):

• One of the advantages of static factory methods is that, unlike constructors, they have names.
• The second advantage of static factory methods is that, unlike constructors, they don’t need to create a new object every time theyre called.
• The third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of the return type.
• The fourth advantage of static factory methods is that they reduce the bulk of creating instances with a parameterized type.

Disadvantages (citing a book):

• The main disadvantage of providing only static factory methods is that classes without public or protected constructors cannot be subclassed.
• The second disadvantage of static factory methods is that they are not easily distinguishable from other static methods.

Answer 2

You have two questions: when should I call the getInstance() method, and when should I create it?

If you decide whether to call a getInstance() method , this is easy. You just need to read the class documentation to find out when you should call it. For example, NumberFormat provides a constructor and getInstance() method; The getInstance() method will give you a localized NumberFormat . For Calendar , on the other hand, the constructor is protected. You must call getInstance() to get it.

If you decide to create a getInstance() method, you need to decide what you are trying to execute. Either you don’t want people to call your constructor (you create a singleton or factory ), or you don’t mind (like in NumberFormat above, where they initialize some objects for the convenience of the caller).

---

In short? Don't worry about creating getInstance() methods in your own code. If time arises when they are useful, you will find out. In general, if you can call the constructor of a class, you should probably do it, even if the class provides the getInstance() method.

Answer 3

Using getInstance methods:

• If you want to control / limit construction, for example. Singleton
• implement Factory pattern, for example. DriverManager.getConnection
• If you want to better indicate how the instance is created (constructors must have the same name as the class name), check the NumberFormat Factory methods getCurrencyInstance , getIntegerInstance and others as examples of this.

But most of the time, your object will be a simple POJO and using public constructors is the most practical and obvious solution.

U1: getInstance from another class

To return an instance of another class:

 public class FooFactory { public static Foo getInstance() { return new Foo(); } } 

NumberFormat.getInstance do this the way they actually return DecimalFormat instances.

U2: problems with Singleton

The syntax pattern limits many of the benefits of object-oriented programming. Singletones usually have private constructors, so you cannot extend them. Since you will access it using the getInstance method and not refer to any interface, you cannot replace it for another implementation.

Answer 4

If you can use both, then it sounds like a poorly implemented singleton pattern .

Use the second option if you intend to have only one instance of the class on your system and make it private.

Use the first one to allow the creation of multiple class objects.

BUT do not give your class both possibilities.

Be careful not to convince single games, use them only if there is only one instance in the system, otherwise you would limit the possibilities of reusing your class in other projects. It sounds interesting to be able to call getInstance from around the world in your project, but it is not clear who actually owns this instance: no one and / or all. If you have a lot of singles in the project, you can bet that the system is poorly designed (usually). Singletones should be used with care, the same advice applies as for global variables.

Answer 5

One case where I always prefer a static factory over a regular constructor is when I know that the construction of an object will be slow. I am doing simple initialization on the constructor, but if I need to create something heavy, I will use the static method and document the behavior.

Answer 6

Singleton is evil. The problems that I saw around are not about reusing or expanding the system (although I could see how this could happen), especially since I can’t count the number of times I saw unclear errors in a system that arises from monophonic ones.

If you need to use a singleton, make sure that its area is very narrow, i.e. it is wise to limit the number of other objects in your system that are aware of this.