← New search

Other meanings of Immutable object

Software engineering

Immutable object

An immutable object is an object whose state cannot be modified after creation. Its fields or contained values are established by a constructor or factory, and later operations produce a new object rather than altering the original. Immutability simplifies reasoning about aliasing, supports safe sharing, and is central to functional programming, although a reference to an immutable object can still be reassigned and an object is not necessarily deeply immutable.

1
core rule
State fixed after construction
O(1)
typical sharing
Persistent structures can reuse unchanged parts
3
common layers
shallow, deep, and persistent immutability
1

Definition and guarantees

Immutability means that an object's observable state does not change after the object has been constructed. A method such as a string-concatenation operation may return another value, while the original string remains unchanged; Java's String is a standard example.1 The rule concerns the object, not every variable that refers to it: a reference may be redirected to a different object.

Immutable objects are especially useful when several parts of a program share the same reference. No client can alter the shared value behind another client's back, reducing aliasing bugs and often removing the need for locks around read-only access. Immutability does not, however, make every surrounding operation atomic, nor does it guarantee that an object graph is immutable.

2

Construction and implementation

An immutable type normally hides its representation, initializes all state before publication, exposes no mutators, and ensures that operations preserve its invariant. In Java, this commonly involves private final fields, defensive copies of mutable inputs and outputs, and constructors or factories that reject invalid combinations; Java records provide concise transparent carriers but do not automatically make referenced objects immutable.2

Immutability can be shallow or deep. A tuple containing a mutable list is structurally fixed while the list remains changeable. Persistent data structures take a different approach: an update creates a new version while sharing unchanged internal nodes, a technique documented in Clojure's persistent collections.3 Copy-on-write and builder patterns offer related ways to combine convenient construction with immutable published values.

3

Benefits and trade-offs

Immutable objects make programs easier to test, cache, memoize, and use concurrently because their values remain stable. A stable value can safely serve as a key in a hash table, provided its equality and hash code are based only on immutable state. Immutable collections in .NET explicitly provide APIs for producing modified versions without changing the original collection.

The costs are real: updates may allocate objects, copy data, or retain shared structure, and careless designs can create excessive garbage or memory use. Persistent structures reduce copying but add indirection and implementation complexity. A mutable builder, local buffer, or transaction can therefore be appropriate internally, with an immutable object created at the boundary. Immutability is a design choice rather than a universal performance rule.

4

Lesser-known aspects

Immutability is a property of a type's complete observable behavior, not merely the absence of setters. A getter that exposes a mutable array, a callback that changes hidden state, or a lazily populated cache can violate a strict interpretation even when visible fields appear final. Python illustrates a related edge case: tuples are immutable containers, but they can contain mutable objects whose contents change.4

Language ownership systems can enforce stronger guarantees for particular references rather than declaring every object globally immutable. Rust's ownership and borrowing rules distinguish shared access from mutable access and can prevent data races at compile time.5 Serialization, reflection, native code, and unsafe operations may bypass ordinary construction discipline, so claims of immutability should specify the trust boundary. Persistent values also support versioning: old snapshots remain usable after a logical update.

Glossary

Shallow immutability
A guarantee that an object's own fields or container slots cannot change, even though referenced objects may remain mutable.
Deep immutability
A guarantee extending through the reachable object graph, so contained values are immutable as well.
Persistent data structure
A data structure that preserves previous versions while creating updated versions, commonly by sharing unchanged parts.
Defensive copy
A separately created copy used to prevent callers from changing mutable state owned by an immutable object.
Value object
An object identified primarily by its value rather than by mutable identity or location.

The term describes object design in programming languages; it does not mean that a variable, reference, or entire program is unchangeable.