The Principle of Immutability
As covered in previous blogs, my favorite software design and architecture principles are:
- The Git Principle
- The Maven Principle
- The Principle of Immutability
In this blog, I am going to cover the principle of immutability. This is the only principle that is not a side-effect of technology or framework among my core principles.
Immutability & Object-Oriented Design
The immutability principle is so universal that it can be appreciated at the most basic level and at the most advanced level. We can also look at it from an Object-Oriented programming perspective. Every object has a state and behavior. The internal state is its own business, and the only way an object should be modified is via behavior. The internal state of an object being hidden is called encapsulation.
Immutability takes this one step ahead with not even allowing the internal state of an object to be changed. In other words, if the internal state is changed, it’s no longer the same object. This new mutated object needs to be identified with a new identifier. If we use the language of security, it’s equivalent to an object having a different checksum. If we use the language of gitOps, it’s equivalent to an object having a new version.
In n-tier object-oriented design, the principle of immutability is most visible in the creation of data transfer objects or value objects.
Immutability & Gang of 4 Design Patterns
The principle of immutability intersects multiple Gang of 4 design patterns. The immutable artifact creation can be related to the factory method. Artifact cloning can be related to the prototype and memento pattern. Updating artifacts can be related to the state pattern.
Immutable Infrastructure & Environments
When designing the Roost.ai Environments as a Service platform, one of the key considerations was how best we could provide immutable infrastructure for pre-production workloads. Following the pattern in the previous section, roost platform:
- Instantly creates versioned environments (using blueprint created from repository inference).
- Creates as many copies of the environment as needed.
- Update environments as the source repository changes.
This post was created with Typeshare