Immutable objects in C#

Introduction

There is saying which goes “MAKE THE POT WHILE THE MUD IS WET”. Once Mud becomes dry it cannot be changed. Immutable objects walks on the similar lines. Once the object is created it cannot be modified by anyway.

What are immutable objects?

Immutable objectsare objects which once loaded cannot be changed / modified by anyway external or internal.

Where are immutable objects used?

If I put in one line Immutable objects are used for data WHICH IS STATIC. Below are some of the instances of the same.
• Master data: - One of the biggest uses of immutable objects is to load master data. Master data like country,currency , region etc rarely change. So we would like to load master data once in the memory and then we do not want it to be modified.

• Configuration data: - All application needs configuration data. In Microsoft world we normally store these configuration data in to Web.config or App.config file. Such kind of data is represented by objects and these data once loaded in the application memory will not change.Its again a good practice to make these kind of configuration data objects as immutable.

• Singleton objects: -In applications we normally create singleton objects for shared static data. So if the shared data is not changing it’s aawesome candidate for immutable objects. In case you are new to Singleton pattern please refer this article Singleton Pattern in C#
 

How can we create immutable objects in C#?

Immutable objects can be created only from immutable classes. To create an immutable class is a three step process :-

• Step 1:- Remove the setters of the class only have getters.
The first step towards creating an immutable class is to remove the setters. As we said values of a immutable class cannot be modified EXTERNALLY or INTERNALLY. So by removing the getters any client who creates the object of this class cannot modify the data once loaded.
 

• Step 2:- Provide parameters via constructor.
We have removed the getters so there is no way to load data in to the class. So to provide data we need to create constructors with parameters via which we can pass data to the object. Below is the modified code for the same.
 


• Step 3 :- Make the variables of the property READONLY

As we said in the previous definition immutableobjects cannot be modified by ANYWAY once the data is loaded. I will go one step further and say it cannot be modified EXTERNALLY by client or INTERNALLY by the class code himself.
 
But if you see our currency class the variables can be modified after the object creation. In other words see the below class code. We have created a method in the class called as “SomeLogic”. This method is able to successfully modify the variables after the object has been created.

So the solution for the above to make the variables “READONLY”. Below is the currency class modified where the property variables are made readonly.Readonly variables can be only initialized in the constructor and later they cannot be modified.

Hope you enjoyed this short note on Immutable objects. Immutable objects is a design pattern which was first officially discussed in Java concurrency in practice book. In case you are interested to learn design pattern I would suggest creating a full blown project and starting implementing design pattern in the same.
 
You can start from the below youtube video in which I have demonstrated design pattern with a full blown project.
CodeProject

What is IOC and Dependency injection and how do they differ from each other?(Design pattern interview questions with answers)

When we talk about software programs they have LOGIC’s and LOGIC’s have FLOW. Take the below simple code. We have a “Customer” class which is instantiated from a console application.

class Customer

    {

        private SQLServer Dal = new SQLServer();

        public bool validate()

        {

            return true;

        }

        public void Add()

        {

            if (validate())

            {

                Dal.Add();

            }

        }

    }

    class SQLServer

    {

        public void Add()

        {

        }

    }

Customer obj = new Customer();

obj.Add();

If you watch the program flow of the customer object it is as follows:-

• Client creates object of the customer class.
• Customer class creates the object of SQL Server data access layer.
• Customer object then invokes “Validate” method.
• Once the “Validate” method is successful then it invokes the “Add” method.

In other words the “Customer” class is in control of his FLOW. Now let us complicate the situation.  Let’s say we have different flavors of data access layer.  So let’s say we have “SqlServer” and “Oracle” as shown below.

So the best way to implement the same is my creating a generic interface “Dal” and pointing that generic interface to “SQLServer” or “Oracle” object depending on situations. So if you see the flow now:-

• Client creates object of the customer class.
• Customer class depending on configuration decided to create SQL Server object or Oracle object.
• Customer object then invokes “Validate” method.
• Once the “Validate” method is successful then it invokes the “Add” method.

A good code is that code which takes care of his own logic rather than overloading with logic which he is not concerned with. For instance in this case the customer class is now taking care of logics like deciding which data access layer objects to be created.

class Customer

    {

        private Dal dal;

        public Customer(int DalType)

        {

            if (DalType == 1)

            {

                dal = new SQLServer();

            }

            else

            {

                dal = new Oracle();

            }

        }

        public bool validate()

        {

            return true;

        }

        public void Add()

        {

            if (validate())

            {

                dal.Add();

            }

        }

    }

interface Dal

    {

        void Add();

    }

    class SQLServer : Dal

    {

        public void Add()

        {

        }

    }

    class Oracle : Dal

    {

        public void Add()

        {

            throw new NotImplementedException();

        }

    }

This makes the customer class tightly coupled to the data access layer changes and second in long run this code becomes difficult to maintain. So the solution here  is customer class should perform his own concerned logic like validating customer class , calling add method of data access layer. But deciding which data access layer to create is not his part.

So if this logic or this control is given to some other entity or can be INVERTED to some one else then the code would look much better.

So if we change the code to something as shown below. Where the customer class say’s hey  look I am not concerned its Oracle or SQL Server. Pass me the generic interface object from the constructor and relieve me from the decision making logic of Data access layer.

class Customer

 {

        private Dal dal;

        public Customer(Dal obj)

        {

            dal = obj;

        }

      …

      …

}

So now it’s the work of client or the invoker to decide which data access layer object has to be passed.

If you visualize this scenario the flow of “Customer” class now takes care of his logic and the unconcerned logic is now passed to an external entity. This is termed as “Inversion of control”. The control or logic which is not part of that entity is taken care by someone else.

Also if you put in other terms the flow of “Customer” class is now affected by external entities depending on whether they inject “SqlServer” object or “Oracle” object.

A word of caution here, do not conclude that IOC can  only be implemented by exposing abstraction via constructor.  You can delegate the control flow by callback delegates, observer pattern, events, and lot of other ways.

The above way of sending abstraction from constructor is termed as “dependency” injection.IOC (Inversion of control) is a general parent term while DI (Dependency injection) is a subset of IOC.

DI provides objects that an object needs.  So rather than the dependencies construct themselves they are injected by some external means.  For instance let’s say we have the following below class “Customer” who uses a “Logger” class to log errors. So rather than creating the “Logger” from within the class, you can inject the same via a constructor as shown in the below code snippet.

The biggest benefit achieved by the above approach is “Decoupling”. You can now invoke the customer object and pass any kind of “Logger” object as shown in the below code.

Customer obj = new Customer(new EmailLogger());

Customer obj1 = new Customer(new EventViewerLogger());

Inversion of control	Dependency injection
It’s a generic term and implemented in several ways (events, delegates etc).	DI is a subtype of IOC and is implemented by constructor injection, setter injection or method injection.