Immutable object

From open-encyclopedia.com - the free encyclopedia.

In computer science, an immutable object, as opposed to a mutable object, is a kind of object whose internal states cannot be modified. 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 immutable while some attributes for internal use change and 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, Python, Lua, and Ruby. In that case, it matters whether the state of object can vary or not.

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) is usually the easiest solution.

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, at the cost of some system complexity, is copy-on-write (COW). Using this technique, references to the same object are created instead of copying the object; however, users are still permitted to modify the object. As soon as a user modifies the object, a copy is made by the system (transparently to the user) and that user receives a new reference to that copy to be used in all future transactions. The other users are unaffected, because they still reference 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 advantage of immutable objects is 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.

Handling mutable objects is usually more cumbersome than immutable ones. To avoid surprising changes, you need to use a defensive copy. This trick often slows down runtime performance.

It is recommended that immutable data should always be passed to the constructor. It should not be set via an accessor. See accumulate and fire for a description of this problem.

Strings or other concrete objects are typically expressed as immutable object to improve readibility and runtime efficiency in object-oriented programming. In Python and Java, strings are immutable objects while Java also has a class StringBuffer as mutable object.

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