Interface Segregation Principle

Back to blogging about some object-oriented principles. This time I examine a simple principle--the Interface Segregation Principle (ISP).

ISP is a sort of the poor man's Single Responsibility Principle (SRP). While SRP addresses high cohesion in the class level, ISP is about high cohesion in the interface level. In other words, you create client (type) specific interfaces so that users will not have to depend on functionality they don't need.

ISP is a special case of a wider principle called "Separation of Concerns" in which each interface deals with a specific aspect of the behavior.

Here is a simple example for applying ISP: Consider a drawing program where you build a a rectangle class that has some logic (e.g. calculate area) as well as drawing logic (e.g. render itself on the screen using DirectX). If you also have some algorithms that also need the area calculation of the triangle, the algorithms are now dependent on DirectX. When applying SRP this would be refactored into two classes, while with ISP it would be refactored into two interfaces and the algorithm would only depend on mathematical oriented one. Robert C. Martin described ISP in detail in Interface Segregation Principle.

ISP can be used as a solution where a class violates SRP from some reason (to help protect the class users). Another common use of this principle is as a second step for increasing cohesion and separation of unrelated parts. Interestingly determining what client specific interfaces you should have can be done using similar principles mentioned in another post : Consumer Driven Contracts. There are several key differences though. Services granularity is very different from classes granularity and more important ISP promoted fine-grained interfaces while contracts promote coarse-grained ones.

Posted by Arnon Rotem-Gal-Oz at 08:47 AM  Permalink