When should a C# object be immutable, and when is controlled mutation the better model?

Immutable object design and controlled mutation

Chooses immutable values and controlled mutable entities based on identity, concurrency, invariants, allocation cost, and update semantics.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I prefer immutability for value-like data and snapshots, and controlled mutation for identity-bearing objects with a real lifecycle. Money, date ranges, identifiers, and configuration snapshots can be shared without observing partial change. An Order may change status over time, but callers should use Confirm or Cancel rather than set arbitrary properties. Immutability reduces aliasing and concurrency surprises, while controlled mutation keeps business transitions explicit.

Full answer below

Practice focus

Immutable values, identity, records, entities, thread safety, snapshots, with expressions, controlled transitions, and allocation trade-offs.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
I prefer immutability for values and snapshots whose meaning should not change after creation. For identity-bearing entities with a lifecycle, controlled methods can express valid mutation more naturally than replacing the entire object.
I prefer immutability for value-like data and snapshots, and controlled mutation for identity-bearing objects with a real lifecycle. Money, date ranges, identifiers, and configuration snapshots can be shared without observing partial change. An Order may change status over time, but callers should use Confirm or Cancel rather than set arbitrary properties. Immutability reduces aliasing and concurrency surprises, while controlled mutation keeps business transitions explicit.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A read-only interface or get-only property does not guarantee deep immutability if it exposes a mutable collection. Records support value-oriented syntax and with expressions, but referenced members can still mutate. A with expression also performs shallow copying. Large immutable graphs can allocate heavily, so persistent collections, localized mutation during construction, or snapshots may be better than copying everything for each change.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling get-only properties deeply immutable.
Using with expressions as if they deep-copy every member.
Making every entity immutable regardless of lifecycle.
Mutating an object after using it as a hash key.

When should a C# object be immutable, and when is controlled mutation the better model?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement