Immutable class/object, private Constructor, factory method

Question

Having already read how to make a class Immutable by following steps

1. Don't provide "setter" methods — methods that modify fields or objects referred to by fields.
2. Make all fields final and private.
3. Don't allow subclasses to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in factory methods.
4. If the instance fields include references to mutable objects, don't allow those objects to be changed:
   a. Don't provide methods that modify the mutable objects.
   b. Don't share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid returning the originals in your methods.

AM not sure I clearly understand the utility of private constructor and factory method in the context of immutability. If I make class final, basically am closing all paths of any other class extending it. How is the stated a more sophisticated approach

I have seen private constructor,factory method in Singleton pattern which makes sense. But when we talk of object immutability, are we also restricting object construction/instantiation when we mention private constructor and static factory methods??

Answer 1

Firstly, there are several reasons why immutable class generally should not be overriden, you can find them here.

That said, making a constructor private is just one way to prevent class from being overriden. Why? Because in sub-class, every constructor (implicitly) calls super(), a default constructor of base class. But if you make this constructor private, sub-class cannot call it and thus cannot override the base class. This approach is very suitable when you want to control the total number of instances of particular class, for example in case of singletons.

Answer 2

I think the big issue here is future refactoring. Suppose, in a later version, you find it would make something much simpler if you could split out some new special case of MyClass into a subclass, MySpecialClass.

If MyClass were a mutable class with a public constructor, you could just do it and tell users of the new features to create a new MySpecialClass. Existing uses are not affected.

If MyClass has a private constructor and a factory method, there is no problem. You declare MySpecialClass nested in MyClass, also with a private constructor. Add and/or modify the factory methods to choose which to create, but make sure existing calls go on working compatibly.

What would you do if MyClass were immutable, and final, but had a public constructor?

Answer 3

After thoroughly reading the below point

Dont allow subclass to over ride methods. The simplest way to do this is to declare the class final. A more sophisticated approach is to make constructor private and construct instances in factory method.

I think the point here is not

Making class final and private constructor.

The point is

Either you make your class final or have a private constructor.

Hope it helps!!

source

Answer 4

Yeah, you are right. It does not make any sense to make constructor private. By doing this, we are restricting the instance creation, which is not a desired scenario for immutability.

In example mentioned in sun site does not make constructor private http://docs.oracle.com/javase/tutorial/essential/concurrency/syncrgb.html

Answer 5

IMMUTABILITY - Very helpful for concurrency as it avoids creation of various invariant that are possible in threading environment.

FACTORY METHODS - Just a naming convention, as they are more verbose to read and easy to understand from their custom name. For example: copyOf() method would make more sense than creating a copy constructor. As said by Joshua Bloch in Effective Java

PRIVATE CONSTRUCTORS - They have their own uses in patterns like Singleton, but have their own limitations.

Answer 6

Some of my own findings from Effective Java Item 15, pasting relevant statements from the same

"Recall that to guarantee immutability, a class must not permit itself to be subclassed. Typically this is done by making the class final, but there is another, more flexible way to do it. The alternative to making an immutable class final is to make all of its constructors private or package-private, and to add public static factories in place of the public constructors (Item 1).

While this approach is not commonly used, it is often the best alternative. It is the most flexible because it allows the use of multiple package-private implementation classes. To its clients that reside outside its package, the immutable class is effectively final because it is impossible to extend a class that comes from another package and that lacks a public or protected constructor. Besides allowing the flexibility of multiple implementation classes, this approach makes it possible to tune the performance of the class in subsequent releases by improving the objectcaching capabilities of the static factories.

"

static factory vs constructor advantages are then discussed

Answer 7

That is because with private constructor we can not make a subclass of it, and thus restricting all paths of any other class extending it. It is sophisticated because it has its own limitations/complications like in singleton pattern.

Answer 8

The idea behind the private constructor is that you want to hide the immutable implementation of the class data whilst allowing construction of a new instance with different data of the same internal type.

For example

public class Temperature
{
    private readonly double temperatureInCelsius;

    public Temperature(string temperatureInCelsius)
    {
         this.temperatureInCelsius = System.Convert.ToDouble(temperatureInCelsius);
    }
    private Temperature(double temperatureInCelsius)
    {
         this.temperatureInCelsius = temperatureInCelsius;
    }

    public Temperature AddCelsius(string temperatureToAddInCelsius)
    {
         return new Temperature(System.Convert.ToDouble(temperatureToAddInCelsius) + temperatureInCelsius);
    }
    public void PrintCelsius(Display display)
    {
        display.Print(temperatureInCelsius);
    }
    public void PrintFarenheit(Display display)
    // ... etc
}

Ignoring the semi stupidity of the example, if your requirements are that the class can be constructed from a string representing the temperature. The way it actually stores the temperature is subject to change and is an implementation detail. This class can be changed to use floats, strings, doubles, ints etc. This method maintains immutability whilst allowing flexibility on implementation. Obviously this becomes much more powerful when you are wrapping more complex objects such as collections, dictionaries etc.