Coding Efficiency

SOLID is a combination of five important design principles:
S – Single Responsibility Principle
O – Open Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

This post is about the Interface Segregation Principle.

Definition:

The Interface Segregation Principle states that client’s shouldn’t depend on methods that they do not use. In other words, a class should only depend on the smallest possible interface of other classes.

Bad Example:

Let’s say you have an IEntityReporter in your application, while you created it, the only required report was a revenue report for customers, yet you wanted it to be generic and called the method therefore CreateReportFrom.

public interface IEntityReporter<T> where T : Entity
{
    IReport CreateReportFrom(T entity);
}

Now you are asked to create revenue reports from products too, as it’s no problem, you just create a ProductReporter that implements the IEntityReporter.

Later, you are asked to create two more reports, an recommendation report for customers and an inventory report for products . The former shows what the particular customer might be interested in, the latter contains stock data of the product.

You might implement it this way:

public interface IEntityReporter<T> where T : Entity
{
    IReport CreateReportFrom(T entity);
    IReport CreateRecommendationReportFrom(T entity);
    IReport CreateInventoryReportFrom(T entity);
}

(It would be way worse if you want to add methods like CreateReport2, CreateReport3 etc.)

It will work but you can’t create an inventory report for customers, so you’ll have to throw a NotImplementedException / NotSupportedException.

As there are just two entities involved and thereby only two implementations of the interface, you might think that it’s not that bad as there is almost no effort required to deal with these additional methods.

Although that is true, what happens if you have to add more reports for other entities like Location, Supplier etc? Do you want to add all those reports to the EntityReporter interface as well?

What do you get if you call CreateReport in the LocationReporter? A revenue report about all customers contained within it? A report about all customers / suppliers in that location?

Even if you create an abstract EntityReporter that implements the interface with empty, virtual methods, do you really want all the IntelliSense clutter if you deal with an EntityReporter, how do you tell other developers what reports are valid for each entity?

Another argument might be that you have to redeploy each and every assembly that contains an IEntityReporter implementation if you change the interface.

How it could be done

I’d say it would be better to get rid of your IEntityReporter and create specific interfaces:

public interface IRevenueReporter<T> where T : Entity
{
    IReport CreateRevenueReportFrom(T entity);
}

public interface ICustomerReporter : IRevenueReporter<Customer>
{
    IReport CreateRecommendationReportFrom(Customer customer);
}

public interface IProductReporter : IRevenueReporter<Product>
{
    IReport CreateInventoryReportFrom(Product product);
}