Interface segregation principle

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.^[1] ISP splits interfaces which 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.^[2] ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy. ISP is one of the five SOLID principles of Object-Oriented Design, similar to the High Cohesion Principle of GRASP.^[3]

Importance in object-oriented design

Within object-oriented design, interfaces provide layers of abstraction that facilitate conceptual explanation of the code and creates a barrier preventing dependencies.

According to many software experts who have signed the Manifesto for Software Craftsmanship, writing well crafted and explanatory software is almost as important as writing working software.^[4] Using interfaces to further describe the intent of the software is often a good idea.

It is also true that a system may become so coupled with a lot of levels so that it is no longer possible to make a change in one place without having a ripple effect throughout the design, having to make subsequent changes in many places.^[1] Using an interface or an abstract class can prevent this side effect.

Origin

The ISP was first used and formulated by Robert C. Martin while consulting for Xerox. Xerox had created a new printer system that could perform a variety of tasks like stapling a set of printed papers and faxing. The software for this system was created from the ground up and performed its tasks successfully. As the software grew, making modification became more and more difficult so that even the smallest change would take a redeployment cycle of an hour. This was making it near impossible to continue development.

The design problem was that one main Job class was used by almost all of the tasks. Anytime a print job or a stapling job had to be done, a call was made to some method in the Job class. This resulted in a huge or 'fat' class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.

The solution suggested by Martin is what is called the Interface Segregation Principle today. Applied to the Xerox software, a layer of interfaces between the Job class and all of its clients was added using the Dependency Inversion Principle. Instead of having one large Job class, a Staple Job interface or a Print Job interface was created that would be used by the Staple or Print classes, respectively, calling methods of the Job class. Therefore, one interface was created for each job, which were all implemented by the Job class.

Typical violation

The Xerox example is a clear violation of the Interface Segregation Principle, but not all violations are so clear cut. A more commonly known example is the ATM Transaction example given in Agile Software Development: Principles, Patterns, and Practices ^[1] and in an article also written by Robert C. Martin specifically about the ISP.^[5] This example is about an interface for the User Interface for an ATM, that handles all requests such as a deposit request, or a withdrawal request, and how this interface needs to be segregated into individual and more specific interfaces.

See also

• SOLID The I in SOLID stands for Interface segregation principle

References

External links

• Principles Of OOD – Description and links to detailed articles on SOLID.
• Object Oriented Design Quality Metrics: an analysis of dependencies Robert C. Martin, C++ Report, Sept/Oct 1995