In computer science, an immutable object, as opposed to a mutable object, is a kind of object whose internal states cannot be modified after it was created. An object can be immutable at whole or some attributes in the object immutable, as in C++'s const member data attribute. In some cases, an object is considered immutable while some attributes for internal use change (like for caching purpose) yet the state appears to be unchanging. The initial state of an immutable object is mostly set at its inception, but it can be set right before actual use of the object.

In some languages, objects are handled as a reference rather than a concrete value. Many OOP languages take that scheme, including Java. In that case, it matters whether the state of object can vary or not since objects are shared via references.

If an object is known to be immutable, then instead of creating copies of the entire object, only copies to a reference to it need be made. Because a reference is very often much smaller than the object itself (typically only the size of a pointer), this results in savings of memory usage and boost in execution speed.

This technique is much more difficult to use for mutable objects, because if any user of a reference to a mutable object changes it, all other users of that reference will see that change. If this is not the intended effect, it can be difficult to notify the other users to have them respond correctly. In such situations, copying of the entire object rather than the reference, known as defensive copy, is usually the easiest yet potentially costly solution. For a well-known technique that handles changes to mutable objects, see the discussion on the observer pattern.

The attempt to comprehensively use references in place of copies of equal objects is known as interning . Some languages do this automatically; for example, Python automatically interns strings. If the algorithm which implements interning is guaranteed to do so in every case that it is possible, then comparing objects for equality is reduced to comparing their pointers, a substantial gain in speed for some applications. (Even if that algorithm is not guaranteed to be comprehensive, there still exists the possibility of a fast path case improvement when the objects are equal and use the same reference.) Interning is generally only useful for immutable objects.

A technique which blends the advantages of mutable and immutable objects, and supported in almost all modern hardware, is copy-on-write (COW). Using this technique, when a user asks the system to copy an object, it will instead merely create a new reference which, through hardware trickery, still points to that same object. As soon as a user modifies the object through a particular reference, a real copy is made by the system and that same reference will now refer to the new copy. The other users are unaffected, because they still refer to the original object. Therefore, under COW, all users appear to have a mutable version of their objects, although in the case that users do not modify their objects, the space-saving and speed advantages of immutable objects are retained. COW is popular in virtual memory systems because it allows them to save memory space in the core while still correctly handling anything an application program might do.

Strings or other concrete objects are typically expressed as immutable object to improve readability and runtime efficiency in object-oriented programming. In Python and Java, strings are immutable objects. Java has a class StringBuffer, which is a mutable object in addition to the immutable java.lang.String .

The article contains materials partly from Perl Design Patterns Book.

External links

• Article "Pattern: Immutable Object" by Nat Pryce
• Article "Java theory and practice: To mutate or not to mutate?" by Brian Goetz
• Article "Immutable objects" by vorthys on "Topcoder.com"
• Java Reference Java Practices: Immutable objects
• Descriptions from Portland Pattern Repository
• Chapter "Immutability of Objects" in the Common Lisp Interface Manager Specification
• Chapter "Immutable Classes" from a Sather manual