Software Development

Immutable classes and objects

This week’s post offers a review of the concept of immutable classes, and suggestions for best practices in implementation.  An immutable class is “a class whose instances cannot be modified” (Bloch, 2018, p. 80) .  There are many well-known immutable classes in the Java platform libraries such as String and primitive classes like Integer and Double (Temre, 2015). To illustrate consider a simple example of a Car class.

A simple Car class might have the attributes ownerName, modelYear, maker, model, licensePlateNumber, and color.  This simple class might do well to collect Car objects for public service reasons such as police patrol or license fee monitoring.  To create this class as immutable, these fields must be declared private and final, create no setter methods, make sure not to use any mutable objects in the constructor, and don’t allow getter methods to be overridden (Tinca, 2018).  Once crafted as an immutable class, each Car object is set and cannot be changed.


There are many advantages of immutable objects derived from immutable classes including (2018, pp. 81-83):

  • Immutable objects are simple and stable, remaining in the original state in which they were created.
  • Immutable objects are thread safe, i.e. they cannot be corrupted by multiple threads accessing them concurrently.
  • Immutable objects can be shared freely.
  • Immutable objects make great building blocks for other objects.

Sheikh has also demonstrated that the use of immutable classes generally leads to easier class and project testing overall (2018). 


Bloch suggests that there is limited downside to using immutable classes, that being primarily that in some cases a large number of instances may be required, expanding program processing demands and hampering performance (2018, pp. 84-86). 

Sheikh emphasizes that “one of the main disadvantages of Immutable objects is that you end up with a lot of boilerplate code” (Sheikh, 2018).  Sheikh continues to explain that the programming requirements for properly coding immutability could be substantial.  Software engineer Luis Espinal agrees with Sheikh, suggesting that “immutability in most OO languages forces you to add artificial artifacts and practices in your model and process. For each complex immutable class you must have an equally complex (at least internally) builder” (Espinal, 2011).

The downside of immutable classes can be seen with the simple Car class example above.  The problems with immutable objects surface when the object once created no longer reflects the reality being studied.  For example, if a Car object is sold ownerName will no longer be valid.  To keep the car object in the class, a new object will have to be created.  When this problem grows large, it can be a burden to the program to have to constantly be creating entire new objects instead of modifying the ones already on hand.

Best Practices

Overall, Bloch recommends that “classes should be immutable unless there’s a good reason to make them mutable,” as they offer “many advantages and their only disadvantage is the potential for performance problems” (2018, p. 86).  However, Bloch’s discussion on the issue falls short of definitive guidance for when an immutable class is the best alternative.

Espinal suggests that the developer should consider carefully the nature of objects being created before committing to an immutable class structure.  He goes on to formalize his recommendation that “small, possibly unitary things can be made immutable,” but more complex things should be made immutable only when it “makes sense” (2011). 

Based on the many advantages of immutable classes, along with the main disadvantages of program complexity and potential processing burden, this post recommends the use of immutable classes wherever feasible, with special emphasis on the three questions posited by Loritsch (2011).

  1. Is there a business reason why an object can change its state?  If so, using an immutable class may present two problems.  First, the class object does not match the business logic which can lead to further development issues.  And, secondly, the frequent construction of replacement objects may lead to processing burden.
  • Are some of the attributes computed?  If so, this raises complexities as immutable objects interact with computed objects from other classes, which must also be immutable.  This chain reaction of immutability needs to be handled carefully.
  • How many values make up the object under consideration?  As Loritsch states, “at some point the complexity of creating and re-creating immutable objects becomes non-trivial and, at that point, having more instances of the object can become a problem” (2011).


Bloch, J. (2018). Effective Java Third Edition. Boston: Addison-Wesley.

Espinal, L. (2011, April 14). At what point to immutable classes become a burden? Retrieved from

Loritsch, B. (2011, April 14). At what point to immutable classes become a burden? Retrieved from

Sheikh, W. (2018, June 9). Understanding immutability. Retrieved from Medium.Com:

Temre, K. (2015, May 2). Complete list of immutable jdk classes? Retrieved from StackOverFlow.Com:

Tinca, I. (2018, March 5). About immutability in OOP. Retrieved from DZone JavaZone:

Leave a Reply