SOLID In C# – Interface Segregation Principle

This article is part of a series on the SOLID design principles. You can start here or jump around using the links below!

S – Single Responsibility
O – Open/Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion

The interface segregation principle can be a bit subjective at times, but the most common definition you will find out there is :

 No client should be forced to depend on methods it does not use

In simple terms, if you implement an interface in C# and have to throw NotImplementedExceptions you are probably doing something wrong.

While the above is the “definition”, what you will generally see this principle described as is “create multiple smaller interfaces instead of one large interface”. This is still correct, but that’s more of a means to achieve Interface Segregation rather than the principle itself.

Interface Segregation Principle In Practice

Let’s look at an example. If we can imagine that I have an interface called IRepository, and from this we are reading and writing from a database. For some data however, we are reading from a local XML file. This file is uneditable and so we can’t write to it (essentially readonly).

We still want to share an interface however because at some point we will move the data in the XML file to a database table, so it would be great if at that point we could just swap the XML repository for a database repository.

Our code is going to look a bit like this :

interface IRepository
{
    void WriteData(object data);
    object ReadData();
}

public class DatabaseRepository : IRepository
{
    public object ReadData()
    {
        //Go to the database and read data
        return new object();
    }

    public void WriteData(object data)
    {
        //Go to the database and write data
    }
}

public class XmlFileRepository : IRepository
{
    public object ReadData()
    {
        //Go to the database and read data
        return new object();
    }

    public void WriteData(object data)
    {
        //Don't allow a user to write data to the XML Repository.
        throw new NotImplementedException();
    }
}

Makes sense. But as we can see for our XMLFileRepository, because we don’t allow writing, we have to throw an exception (An alternative would to just have an empty method which is probably even worse). Clearly we are violating the Interface Segregation Principle because we are implementing an interface whose methods we don’t actually implement. How could we implement this more efficiently?

interface IReadOnlyRepository
{
    object ReadData();
}

interface IRepository : IReadOnlyRepository
{
    void WriteData(object data);
}

public class DatabaseRepository : IRepository
{
    public object ReadData()
    {
        //Go to the database and read data
        return new object();
    }

    public void WriteData(object data)
    {
        //Go to the database and write data
    }
}

public class XmlFileRepository : IReadOnlyRepository
{
    public object ReadData()
    {
        //Go to the database and read data
        return new object();
    }
}

interface IReadRepository
{
    object ReadData();
}

interface IWriteRepository
{
    void WriteData(object data);
}

public class DatabaseRepository : IReadRepository, IWriteRepository
{
    public object ReadData()
    {
        //Go to the database and read data
        return new object();
    }

    public void WriteData(object data)
    {
        //Go to the database and write data
    }
}

public class MyService
{
    //What if this service also writes? I have to inject the write repository as well?
    public MyService(IReadRepository readRepository, IWriteRepository writeRepository) 
    {

    }
}