Immutability comes with design patterns

Recently I have tried to implement some design patterns using only immutable data structures/classes. Immutable data structures - what does it mean?
* no setters - properties with get only
* readonly fields used everywhere
* if method changes something, then it returns a brand new and changed object (initialized with modified data)

Example class:

public class ImmutableClass  
    public string StringProperty { get; }
    private int readonly _intField;
    public ImmutableClass(string stringProperty, int intField){
      StringProperty = stringProperty;
      _intField = intField;
    ImmutableClass Mutate(){
      var value = SomeVeryCostlyOperation();
      return new ImmutableClass(StringProperty, value);
    ImmutableClass MutateDifferently(){
      return new ImmutableClass(StringProperty, _intField+1);

Once the class is created it cannot change. I'm not going to write about all features of immutability. The object can be validated once (on creation) and cannot be changed, nothing bad can happen then, and much much more. I want to draw attention to something else.

Prototype pattern

Let's consider object that is costly to create. In case of that we use Prototype pattern, and try to clone that object to save time/space. When we use immutable class, we can create a prototype and then specified object just using standard method call!
You can call Mutate() (which is very costly) once, and then use that object as prototype.

Strategy pattern

If you provide a method that can configure inner working of the object, it is easily noticeable that it has to change some specified set of values in order to adjust itself as needed. Creation of new object with new parameters can help identify set of fields and methods that are coupled and extract them as some kind of behaviour to other object. That is how the strategy pattern comes out. Of course this coupling can be noticed even without immutability, but is not as nearly as conspicuous!

Forcing single responsibility

When mutating object has to know it's inner structure. It is ok - object knows everything about itself, and in standard situation can change state according to some operations. What I have found that, when using immutability, you can identify smells pretty fast, because any relationship between objects cannot been hidden. You have to create new object and return it, right? Then you cannot simply call a method and change other object when nobody expects that (nobody - I mean objects that hold reference to the same object). That forces the object to be responsible for one thing or it will end up looking very bad - and that's a good thing.

You can see the point? Use of immutable structures often can force a programmer to use good techniques and patterns without even noticing. And that is great!

Probably this post reads pretty "dry", but there is no way to feel it instead of just trying and implementing something. You can cheat a lil' bit and just read some of my code.