DotNet Developer Blog: February 2026

Friday, 27 February 2026

Interface Segregation Principle - SOLID Principle

In this article we are going to see the Interface Segregation Principle, which is used to separate the interfaces with corresponding methods, because classes should not define the interface methods which is not used.

For example we will have to interface IWork, which consists of two methods one is DoWork and another one is TakeFood. this interface is deriving in classes named HumanWorker and RobotWorker where RobotWorker doesnt need to use the method TakeFood so it should not implemented, please see the below example.

    internal interface IWork
    {
        void DoWork();

        void TakeFood();
    }

    internal class HumanWorker : IWork
    {
        public void DoWork()
        {
            Console.WriteLine("Working");
        }

        public void TakeFood()
        {
            Console.WriteLine("Eating Food");
        }
    }

    internal class RobotWorker : IWork
    {
        public void DoWork()
        {
            Console.WriteLine("Working");
        }

        public void TakeFood()
        {
            throw new NotImplementedException("N/A");
        }
    }

After implementing the ISP, the above interface is segregated in to two interfaces and apply the interface which is really required for that classes.

    internal interface IWork
    {
        void DoWork();
    }

    internal interface ITakeFood
    {
        void TakeFood();
    }

    internal class HumanWorker : IWork, ITakeFood
    {
        public void DoWork()
        {
            Console.WriteLine("Working");
        }

        public void TakeFood()
        {
            Console.WriteLine("Eating Food");
        }
    }

    internal class RobotWorker : IWork
    {
        public void DoWork()
        {
            Console.WriteLine("Working");
        }
    }

From this article we can learn interface segregation principle ISP in SOLID Principle.

Saturday, 21 February 2026

Liskov Substitution Principle - SOLID Principle using C# in .NET10

In this article are going to see what is Liskov Substitution Principle, Objects of the super class can be replaced by objects of the sub classes with out breaking the correctness of the program..

We take one example we take Shape class where we have the Area method which will calculate the area, but when you see the Square which will break the behaviour, if the values are not Equal. the Values of the variable are needs to be Equal for Square

    internal abstract class Shape
    {
        public int Width { get; set; }

        public int Height { get; set; }

        public abstract int Area();
    }

    internal class Rectangle : Shape 
    {
        public override int Area()
        {
            return this.Width * this.Height;
        }
    }

    internal class Square : Shape 
    {
        public override int Area()
        {
            if(this.Width != this.Height)
                throw new InvalidOperationException("All sides 
                        are must be equal for square");

            return this.Width * this.Height;
        }
    }

    public class LiskovSubstitutionPrinciple
    {
        public void CalculateArea()
        {
            Shape obj1 = new Rectangle();
            obj1.Width = 10;
            obj1.Height = 20;
            obj1.Area();

            Shape obj2 = new Square();
            obj2.Width = 20;
            obj2.Height = 10;
            obj2.Area(); // Here Base class behaviour is broken because of exception
        }
    }


Liskov Substitution Principle

How we make this class to LSP, the Base class behaviour should not broke, so we slightly change the code which adhere to Liskov substitution principle.

    internal abstract class Shape
    {
        public abstract int Area();
    }

    internal class Square(int SideLength) : Shape
    {
        public override int Area()
        {
            return SideLength * SideLength;
        }
    }

    internal class  Rectangle(int Width, int Height) : Shape
    {
        public override int Area()
        {
            return Width * Height;
        }
    }

    public class LiskovSubstitutionPrinciple
    {
        public void CalculateArea()
        {
            List<Shape> shapes = new List<Shape>
            {
                new Square(7),
                new Rectangle(4, 6)
            };

            foreach (var shape in shapes)
            {
                Console.WriteLine($"Area of {shape.GetType().Name}: {shape.Area()}");
            }
        }
    }

From the above code you can learn what is Liskov Substitution Principle.

Monday, 16 February 2026

Open Closed Principle - SOLID Principle

In this article we are going to see what is Open Closed Principle (OCP) in SOLID. OCP is open for extension and closed for modification. that means a class can be extended through override and not allow to modify.

we see Employee class in which GetSalary is used to fetch the salary this method can be override in Manager class which is derived from employee class but not allow to modify the employee class.

From this article you can learn the Open Closed Principle

Sunday, 15 February 2026

SOLID - Single Responsibility Principle

In this article we are going to see what is single responsibility principle (SRP) in SOLID. The SRP is about the class should have only one responsibility or we can say like it should talk about only one entity. For Example if it is a Employee class, then it should have behaviour and properties only about Employee. simply says the class should have only one reason to change.

First we will see a class which violating the SRP.

In the above class Salary we see that three methods

1. one is calculating Salary.

2. another one is save to DB

3. another one is Print to Salary.

So the first one is application logic , second one is DB layer, third one is UI layer code, all are three different behaviour, now this is violating the SRP.

How we can convert this to SRP.

Now if you see above example three classes in which each one have one responsibility, first one is business logic, second one is DB logic, third one is UI logic.

Now we can see a Logger class which is in SRP.

The above class is Logger, which have only one responsibility or talks about only one entity Logging message. if we have another method like PrintMessage() in the class then that is irrelevant to the class then that is violating the SRP

Wednesday, 11 February 2026

Implementation of Repository pattern and Unit Of Work in .NET10 - Example 2

In this post we are going to see the example 2 of implementation of repository pattern and unit of work in .Net10. we separate the project in to four layers.

1. Domain or Entities

2. Application or UseCase

3. Infrastructure

4. Controllers

Dependencies:

Solution Structure

Domain or Entities:

It is consists of Entities.
It is consists of Repositories and Unit Of Work Interfaces.

Application or UseCase

It is consists of declaration of Application Service Interfaces with public access.
It is consists of Implementation of Application Services with internal access,
Usage of Repositories in the Application Services
To register the services in main program, we have to declare composition root.

Infrastructure

Consists of implementation of Repositories and Unit Of Work with internal access, which can be changed easily,in the future so business logic wont get change, because the application layer work with abstractions.
To register the repositories in main program we have to declare composition root.

Controller

Uses the Register method from application layer and infrastructure layer.

Let we see this with example.

Domain:

Application or Use Case:

Infrastructure Layer:

Controllers:

From this article you can learn a example of how to implement the Repository pattern and Unit Of Work.

Monday, 9 February 2026

Implementation of Repository Pattern and UnitOfWork in .NET10

In this article we are going to see the what is the repository pattern and it's usage. we will see the implementation of Repository Pattern and UnitOfWork in .NET10.

using repository pattern we can decouple the abstraction and its implementation of DB layer, we can work with abstraction the implementation of that abstraction will be change based on the requirement and we can change the DB layer easily.

Abstraction interface: Domain Layer

Now we will see the interface or abstraction of UnitOfWork.

We have a Domain class named Authors:

Authors:

Create this IRepository class in the Domain layer where it will be referred in App Layer for usage, the implementation must be in infrastructure layer.

Application Layer or UseCase Layer

AuthorService

Infrastructure Layer where the actual implementation will be it can be anything like EFCore or SQL Layer etc. for example we will see that the EF-Core example. and implementation of UnitOfWork.