Designing Efficient Immutable .Net Objects
What is an immutable object?
By definition immutable object is the object whose state can not be changed after it is created. That means, after creating the object, its publicly exposed members can not be changed from their initial assigned values. On the contrary, mutable objects are objects whose state can be changed at any point of time.Every developer has to take a important decision whether to make a class mutable or immutable while designing the domain model. While taking this decision, careful considerations can make us avoid the potential pitfall of using immutable object. Why & How using immutable .Net object – is our today’s discussion. Let’s begin with How part .How to implement .Net Immutable Object?
The way I would implement an immutable .Net class – - Make the fields private readonly.- Provide a Public property with get accessor.
- If the class is no longer needed to inherited – making it sealed. Like in the following example, I am implementing an immutable class UserContact which will be inherited in User –
Here is the Implementation of the Immutable classes – public class UserContact
{
private readonly string _Name;
public string Name
{
get { return _Name; }
}
private readonly string _EmailAddress;
public string EmailAddress
{
get { return _EmailAddress; }
}
public UserContact( string name , string emailAddress)
{
_EmailAddress = emailAddress;
_Name = name;
}
}
UserContact get inherited by User as follows [Since User class is no longer inherited – we make it sealed] -
public sealed class User : UserContact
{
private readonly string _UserName;
public string UserName
{
get { return _UserName; }
}
public User(string name, string email, string userName)
: base(name, email) { }
}
So, isn’t it really easy to implement a Truly Immutable class in .Net framework? J Now the question pops into our mind – why we will be using immutable .net objects , what would be benefits of that ? Let’s explore that –
Why use immutable object?
Protection: From the definition we know, Immutable objects can not be changed after its being initialized. So, while using inside application, immutable object can flow in different layers of the application without getting worried about being altered by different layers. Performance: Copying object will be much easier, we just need to copy the reference instead of copying the whole object. It would be much faster to copy reference than the whole object. User user = new User("adil", "adil.bd@hotmail.com", "adak");User userTemp = user; In case of mutable object, we would need to create defensive copy of the object and in .Net term, we need to create a Deep Copy of object otherwise, changing a property in the actual mutable object would reflect everywhere where the object is referenced. For example, let’s consider User as mutable; then changing any thing in user object will have same impact on userTemp as well which is not intended.To avoid this situation, in case of mutable object, we need to make a Deep Copy of the object which is a costly operation. However, for immutable object, copying the reference would be enough since its state can’t be changed. Scalability: Thread synchronization is an issue of concern while designing multithreaded application. Overhead of synchronizing immutable object is far less than mutable object. By default , an individual immutable object does not need to be synchronized as its state will be not be modified by any thread. However, since the immutable object will still be accessed thorough reference , it would require some synchronization. In complex sync scenarios, immutable object would perform far better then mutable version. Consistency:
If we consider inheritance hierarchy, immutability provides a way for the sub-class to maintain consistency in inheritance hierarchy. Consider following mutable objects–
When we instantiate the StudentMutable object, the AccountType is automatically set to Student Account –
public StudentMutable(string name , string email , string userName ) : base(name ,email , userName,"Student Account"){} Now, we can write following lines by which the AccountType property could be anything other than "Student Account” which is completely inconsistent - StudentMutable mutable = new StudentMutable("Adil", "Adil.bd@hotmai.com", "adil");mutable.AccountType = "whatever account"; But if we use Immutable object in inheritance – the object hierarchy will always be consistent.:)
Comments ()