After having covered The Open-Close Principle (OCP), The Liskov Substitution Principle (LSP) and the Single Responsibility Principle (SRP) let’s talk about the Interface Segregation Principle (ISP) which is the I in the SOLID acronym. The ISP definition is:

Client should not be forced to depend on methods it does not use.

It is all about interface, the common abstractions available in most OOP language such as C#, VB.NET or Java. A more complete and actionable explanation of ISP is:

ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.

Roles and Responsibilities

When a class implements several shrunken role interfaces, it has several roles which might lead to think that such class has several responsibilities: it would then violate the Single Responsibility Services.

But a role is a finer-grained concept than a responsibility. An example of a role is the IDisposable interface:

This interface has a single method but it is implemented by a wide variety of classes: DB or network connections that need to be closed gracefully, UI elements that need to deallocate some bitmaps in memory… The only thing the IDisposable interface says to clients is that instances of IDisposable class needs a graceful shutdown.

Hence IDisposable represents a technical detail that the client needs to be aware of. It is much finer-grained concept than a responsibility.

A small interface is not necessarily a good abstraction

A single method interface often makes sense, an IExecutor that Execute(), an IVisitor that Visit(), an IParent that exposes Children { get; }. Often, such minimalist interface should be generic. For example the interface ICloneable available since the .NET Framework v1.1 is nowadays considered as a code smell: when using it the client needs to downcast the cloned Object reference returned to do anything useful with the cloned instance.

ICloneable has another major drawback: it doesn’t inform the client if the clone operation is deep or shallow. This problem is even more serious than the Object reference downcasting one: it is a real design problem. As we can see a minimalist interface is not necessarily a good abstraction. In this example, the lack of information means ambiguity for the client. This would have been better design:

A fat interface is not necessarily a design flaw

A rule like Avoid too large interfaces can certainly pinpoint most of the ISP violations. A threshold of 10 methods is proposed by default to define a too large interface.

However, as always with code metrics and static analysis, such rule can also spit some false positives. For example this fat interface is valid:

In such case the SuppressMessageAttribute can be used with a proper justification. Such justification embeds in the code itself the design decisions. It makes the source code more understandable and more maintainable:

ISP and the Liskov Substitution Principle (LSP)

ISP and LSP are like 2 faces of the same coin:

• ISP is the client perspective: If an interface is too fat probably the client sees some behaviors it doesn’t care for.
• LSP is the implementer perspective: If an interface is too fat probably a class that implements it won’t implement all its behaviors. Some behavior will end up throwing something like a NotSupportedException.

Remember the ICollection<T> interface already discussed in the LSP article. This interface forces all its implementers to implement an Add() method. From the Array class perspective, implementing ICollection<T> is a violation of the LSP because array doesn’t support element adding:

The same way many clients will only need a read-only view of consumed collections. ICollection<T> also violates the ISP: it forces those clients to be coupled with Add() / Insert() / Remove() methods they don’t need. The introduction of IReadOnlyCollection<T> solved both ISP and LSP violations.

This example also shows that ISP doesn’t necessarily mean that a class should implement several lightweight interfaces. It is fine to nest interfaces like russian-nesting-dolls. ICollection<T> is a bit fat, it does a lot, read, add, insert, remove, count… But this interface is well-adapted both for classes that are read/write collections and for clients that work on read/write collection. It makes more sense to nest both read/write behaviors into ICollection<T> than to decompose both behaviors into IReadOnlyCollection<T> and an hypothetical IWriteOnlyCollection<T> interface.

Btw, maybe you noticed that ICollection<T> actually doesn’t implement IReadOnlyCollection<T>. In an ideal world it should implement it but IReadOnlyCollection<T> was introduced several years after ICollection<T> and backward compatibility must be preserved: for example this class would have been broken if ICollection<T> was implementing IReadOnlyCollection<T>, because of the explicit interface implementation usage on ICollection<T>.Count:

Conclusion

ISP is about preventing inadvertent coupling between a client and some behaviors he/she won’t need. Being coupled with something unneeded is a problem:

• In the best case it is a waste: this forces the client to consume precious brain-cycles to consider something he/she doesn’t need.
• In the worst case it is error-prone: the client ends-up misusing the extra behaviors, like attempting to add an element to an array through ICollection<T>.Add().

As for all SOLID principles, ISP is better applied if you practice test-first, or at least, if you write tests and code at the same time. ISP is about the client perspective and writing tests transforms you for a while into a client of your code.

Out of curiosity I wrote this code query that can be re-used to attempt to measure compliance with the ISP.

This query estimates the ratio of usage of the methods of an interface over the maximum usage (maximum usage being when all types consuming an interface call all methods of the interface). Some work would be needed to transform this experimental query into a formal rule. For example the query needs to be smart about methods overloaded that can arguably be considered as a single method.

Nevertheless here are the raw results for non-public interfaces of the .NET framework implementation. Only non-public interfaces are considered because we need to also analyze some real clients of the interface:

Patrick Smacchia

Website

My dad being an early programmer in the 70's, I have been fortunate to switch from playing with Lego, to program my own micro-games, when I was still a kid. Since then I never stop programming.

I graduated in Mathematics and Software engineering. After a decade of C++ programming and consultancy, I got interested in the brand new .NET platform in 2002. I had the chance to write the best-seller book (in French) on .NET and C#, published by O'Reilly and also did manage some academic and professional courses on the platform and C#.

Over my consulting years I built an expertise about the architecture, the evolution and the maintenance challenges of large & complex real-world applications. It seemed like the spaghetti & entangled monolithic legacy concerned every sufficiently large team. As a consequence, I got interested in static code analysis and started the project NDepend in 2004.

Nowadays NDepend is a full-fledged Independent Software Vendor (ISV). With more than 12.000 client companies, including many of the Fortune 500 ones, NDepend offers deeper insight and full control on their application to a wide range of professional users around the world.

I live with my wife and our twin kids Léna and Paul in the beautiful island of Mauritius in the Indian Ocean.