Immutable object
 |
In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created. An object can be either entirely immutable or some attributes in the object may be declared immutable; for example, using the const member data attribute in the C++ programming language. In some cases, an object is considered immutable even if some internally used attributes change but the object's state appears to be unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object. The initial state of an immutable object is usually set at its inception, but can also be set before actual use of the object.
Immutable objects are often useful because some costly operations for copying and comparing can be omitted, simplifying the program code and speeding execution. However, making an object immutable is usually inappropriate if the object contains a large amount of changeable data. Because of this, many languages allow for both immutable and mutable objects.
Background
Before the advent of OOP, values held in program variables whose content never changed were known as 'constants' to differentiate them from variables that could be altered during execution. Examples might include conversion factors from kilogram weights to pounds or the value of Pi to several decimal places. In most object-oriented languages, objects can be referred to using references. Some examples of such languages are Java, C++, C#, VB.NET, and many scripting languages, such as Python and Ruby. In this case, it matters whether the state of an object can vary when objects are shared via references.
If an object is known to be immutable, it can be copied simply by making a copy of a reference to it instead of copying the entire object. Because a reference (typically only the size of a pointer) is usually much smaller than the object itself, this results in memory savings and a boost in execution speed.
The reference copying 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 the change. If this is not the intended effect, it can be difficult to notify the other users to have them respond correctly. In these situations, defensive copying of the entire object rather than the reference is usually an easy but costly solution. The observer pattern is an alternative technique for handling changes to mutable objects.
Immutable objects can be useful in multi-threaded applications. Multiple threads can act on data represented by immutable objects without concern of the data being changed by other threads. Immutable objects are therefore considered to be more thread-safe than mutable objects.
The practice of always using references in place of copies of equal objects is known as interning. If interning is used, two objects are considered equal if and only if their references, typically represented as integers, are equal. Some languages do this automatically: for example, Python automatically interns short 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 in most applications. (Even if the 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.
Sometimes one talks of certain fields of an object being immutable. This means that there is no way to change those parts of the object state, even though other parts of the object may be changeable. (If all fields are immutable then the object is immutable.) This might, for example, help to explicitly enforce certain invariants about certain data in the object staying the same through the lifetime of the object. In some languages, this is done with a keyword (e.g. const in C++, final in Java) which designates the field to be immutable. In some languages, it is reversed: in OCaml, fields of an object or record are by default immutable, and need to be explicitly marked "mutable" to be mutable.
Implementation
Immutability does not imply that the object as stored in the computer's memory is unwriteable. Rather, immutability is a compile-time construct that indicates what a programmer can do through the normal interface of the object, not necessarily what they can absolutely do (for instance, by circumventing the type system or violating const correctness in C or C++).
Java
A classic example of an immutable object is an instance of the Java String class.
String s = "ABC";
s.toLowerCase();
The method toLowerCase() will not change the data "ABC" that s contains. Instead, a new String object is instantiated and given the data "abc" during its construction. A reference to this String object is returned by the toLowerCase() method. To make the String s contain the data "abc", a different approach is needed.
s = s.toLowerCase();
Now the String s references a new String object that contains "abc". There is nothing in the syntax of the declaration of the class String that enforces it as immutable; rather, none of the String class's methods ever affect the data that a String object contains, thus making it immutable.
The following is an example of an object in the Java programming language. According to different definitions of mutability it could be considered mutable or immutable. If you consider the mutability of referenced objects to be part of the mutability of the object that holds the reference (a kind of "deep immutability"), then the object below is mutable, because it holds a reference to a List object, which may be mutable. If, however, for references you simply consider the value of the reference itself, and not the object it may point to (a kind of "shallow immutability"), then the object below is immutable, because it provides no interface (methods or non-private fields) to change the value of any of its fields (including the value of the List reference) from the outside.
class Cart {
private final List items;
public Cart(List items) { this.items = items; }
public List getItems() { return items; }
public int total() { /* return sum of the prices */ }
}
If you wanted to make sure that the List object that it references is also immutable, then the following change partially solves this problem. In the ImmutableCart class, the list is immutable: you cannot add or remove items. However, there is no guarantee that the items are also immutable. One solution is to use the decorator pattern as a wrapper around each of the list's items to make them also immutable. The other solution will be to not let any references to List items escape from the ImmutableCart class by using the statement return new ArrayList(items); in the getItems() method.
class ImmutableCart {
private final List items;
public ImmutableCart(List items) {
this.items = Collections.unmodifiableList(new ArrayList(items));
}
public List getItems() {
return items;
}
public int total() { /* return sum of the prices */ }
}
C++
In C++, a const-correct implementation of Cart would allow the user to declare new instances of the class as either const (immutable) or mutable, as desired, by providing two different versions of the getItems() method. (Notice that in C++ it is not necessary — and in fact impossible — to provide a specialized constructor for const instances.)
template<typename T>
class Cart {
private:
std::vector<T> items;
public:
Cart(const std::vector<T>& v): items(v) { }
std::vector<T>& getItems() { return items; }
const std::vector<T>& getItems() const { return items; }
int total() const { /* return sum of the prices */ }
};
Note that, if there were a field which is a pointer or reference to another object, then it may still be able to mutate the object pointed to by such a pointer or reference within a const method, without violating const-correctness. Some would argue that in such a case the object is not really immutable.
Perl
In Perl, creating an immutable class requires two steps: first, creating accessors (either automatically or manually) that prevent modification of object attributes, and secondly, preventing direct modification of the instance data of instances of that class (this is usually stored in a hash reference, and can be locked with Hash::Util's lock_hash function):
package Immutable;
use strict;
use warnings;
use base qw(Class::Accessor);
# create read-only accessors
__PACKAGE__->mk_ro_accessors(qw(value));
use Hash::Util 'lock_hash';
sub new {
my $class = shift;
return $class if ref($class);
die "Arguments to new must be key => value pairs\n"
unless (@_ % 2 == 0);
my %defaults = (
value => 'data',
);
my $obj = {
%defaults,
@_,
};
bless $obj, $class;
# prevent modification of the object data
lock_hash %$obj;
}
1;
Or, with a manually written constructor:
package Immutable;
use strict;
use warnings;
use Hash::Util 'lock_hash';
sub new {
my $class = shift;
return $class if ref($class);
die "Arguments to new must be key => value pairs\n"
unless (@_ % 2 == 0);
my %defaults = (
value => 'data',
);
my $obj = {
%defaults,
@_,
};
bless $obj, $class;
# prevent modification of the object data
lock_hash %$obj;
}
# read-only accessor
sub value {
my $self = shift;
if (my $new_value = shift) {
# trying to set a new value
die "This object cannot be modified\n";
} else {
return $self->{value}
}
}
1;
Python
In Python some built-in types are immutable, but custom classes are generally mutable. To simulate immutablity in a class, one should override attribute setting and deletion to raise exceptions:
class Immutable(object):
"""An immutable class with a single attribute 'value'."""
def __setattr__(self, *args):
raise TypeError("can't modify immutable instance")
__delattr__ = __setattr__
def __init__(self, value):
# we can no longer use self.value = value to store the instance data
# so we must explicitly call the superclass
super(Immutable, self).__setattr__('value', value)
Scala
In Scala any variable can be defined as mutable or immutable: simply in the declaration one can use val (value) for immutable objects and var (variable) for mutable ones.
E.g. the following code snippet:
val maxValue = 100
var currentValue = 1
defines an immutable entity maxValue (the integer type is inferred at compile time) and a mutable entity named currentValue.
Actually one should talk about variables only for the mutable objects, and call the immutable entities values or constants.
Ada
In Ada any object is declared either variable (then, mutable), or constant (then, immutable), with the constant keyword.
type Some_type is new Integer; -- could be anything more complicated
x: constant Some_type:= 1; -- immutable
y: Some_type; -- mutable
Subprogram parameters are immutable in the in mode, and mutable in the in out and out modes.
procedure Do_it(a: in Integer; b: in out Integer; c: out Integer) is
begin
-- a is immutable
b:= b + a;
c:= a;
end Do_it;
Copy-on-write
A technique which blends the advantages of mutable and immutable objects, and is supported directly 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 still points to the same object. As soon as a user modifies the object through a particular reference, the system makes a real copy and sets the reference to 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 preserved. Copy-on-write is popular in virtual memory systems because[citation needed] it allows them to save memory space while still correctly handling anything an application program might do.
Usage
Strings and other concrete objects are typically expressed as immutable objects to improve readability and runtime efficiency in object-oriented programming. In Python, Java and the .NET Framework, strings are immutable objects. Both Java and the .NET Framework have mutable versions of string. In Java these are StringBuffer and StringBuilder (mutable versions of Java String) and in .NET this is StringBuilder (mutable version of .Net String). Python 3 will have a mutable string (bytes) variant, named buffer.[citation needed]
Additionally, all of the primitive wrapper classes in Java are immutable.
Enforcement of the pattern can be checked by using specialized compilers (see for example http://pec.dev.java.net/), and there is a proposal to add immutable types to Java.
Similar patterns are the Immutable Interface and Immutable Wrapper.
In pure functional programming languages it is not possible to create mutable objects, so all objects are immutable.
See also
References
This article contains some material from the Perl Design Patterns Book
External links
- Article "Java theory and practice: To mutate or not to mutate?" by Brian Goetz, from IBM DeveloperWorks
- Immutable objects from JavaPractices.com
- Immutable objects from Portland Pattern Repository
- Chapter "Immutable Classes" from a Sather manual, via Berlin Institute of Technology