Mutable vs immutable objects

by

Well, there are a few aspects to this.

  1. Mutable objects without reference-identity can cause bugs at odd times. For example, consider a Person bean with a value-based equals method:

    Map<Person, String> map = ...
Person p = new Person();
map.put(p, "Hey, there!");

p.setName("Daniel");
map.get(p);       // => null

    The Person instance gets “lost” in the map when used as a key because its hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. Theorists like to harp on this point, but in practice I haven’t found it to be too much of an issue.

  2. Another aspect is the logical “reasonability” of your code. This is a hard term to define, encompassing everything from readability to flow. Generically, you should be able to look at a piece of code and easily understand what it does. But more important than that, you should be able to convince yourself that it does what it does correctly. When objects can change independently across different code “domains”, it sometimes becomes difficult to keep track of what is where and why (“spooky action at a distance“). This is a more difficult concept to exemplify, but it’s something that is often faced in larger, more complex architectures.

  3. Finally, mutable objects are killer in concurrent situations. Whenever you access a mutable object from separate threads, you have to deal with locking. This reduces throughput and makes your code dramatically more difficult to maintain. A sufficiently complicated system blows this problem so far out of proportion that it becomes nearly impossible to maintain (even for concurrency experts).

Immutable objects (and more particularly, immutable collections) avoid all of these problems. Once you get your mind around how they work, your code will develop into something which is easier to read, easier to maintain and less likely to fail in odd and unpredictable ways. Immutable objects are even easier to test, due not only to their easy mockability, but also the code patterns they tend to enforce. In short, they’re good practice all around!

With that said, I’m hardly a zealot in this matter. Some problems just don’t model nicely when everything is immutable. But I do think that you should try to push as much of your code in that direction as possible, assuming of course that you’re using a language which makes this a tenable opinion (C/C++ makes this very difficult, as does Java). In short: the advantages depend somewhat on your problem, but I would tend to prefer immutability.

More Related Contents:

  1. What is immutability and why should I worry about it?
  2. Interface vs Abstract Class (general OO)
  3. Immutable vs Mutable types
  4. Examples of GoF Design Patterns in Java’s core libraries
  5. Interface vs Base class
  6. What is the difference between association, aggregation and composition?
  7. What is Inversion of Control?
  8. When to use an interface instead of an abstract class and vice versa?
  9. What does “program to interfaces, not implementations” mean?
  10. What is the difference between loose coupling and tight coupling in the object oriented paradigm?
  11. Why do we use Interface? Is it only for Standardization? [closed]
  12. What is the use of making constructor private in a class?
  13. Is returning null bad design? [closed]
  14. OOP vs Functional Programming vs Procedural [closed]
  15. Why don’t associated types for protocols use generic type syntax in Swift?
  16. Simple way to understand Encapsulation and Abstraction
  17. When should I use static methods in a class and what are the benefits?
  18. What is an abstract data type in object oriented programming?
  19. Interface Segregation Principle- Program to an interface
  20. What is an example of the Single Responsibility Principle? [closed]
  21. Mediator Vs Observer Object-Oriented Design Patterns
  22. How to preallocate an array of class in MATLAB?
  23. Can’t seem to understand SOLID principles and design patterns [closed]
  24. Why not use instanceof operator in OOP design?
  25. Is it bad practice for a class to have only static fields and methods?
  26. Why are integers immutable in Python?
  27. How to create a “single dispatch, object-oriented Class” in julia that behaves like a standard Java Class with public / private fields and methods
  28. What is the difference between Composition and Association relationship?
  29. Coupling, Cohesion and the Law of Demeter
  30. What is difference between mutable and immutable String in java

Leave a Comment