This post describes the last of the 5 Class Design Principles associated with the Principles of Object-Oriented Design. You can read all the posts from my chapter-by-chapter review of Agile Software Development Principles, Patterns, and Practices by Robert Martin.
Chapter 12 is on the Interface-Segregation Principle (ISP):
This principle is very much related to the High Cohesion GRASP Pattern
- High Cohesion GRASP Pattern – how strongly related and focused the responsibilities of an object are
The Interface-Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them. Here are some other descriptions I found while Googling:
- “Many client specific interfaces are better than one general purpose interface“
- “The dependency of one class to another one should depend on the smallest possible interface“
- “Make fine grained interfaces that are client specific.“
- “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“
The idea here is that each client may use a particular object or subsystem in a different way. Take an inventory system for example. Your e-commerce website may only check on the inventory status of a product, but your order fulfillment system may both check on the inventory status of a product as well as manipulate inventory levels. This suggests that you will probably want to have 1 interface for checking product inventory levels and another interface for manipulating inventory levels. This will keep each client independent of interfaces that they do not use. If you need to change one interface, you shouldn’t need to change the other. As you create your application and identify the particular clients and user stories, these cohesive interfaces will become evident.
Robert had a couple examples of the Interface-Segregation Principle. The more interesting one was about an ATM, where it may logically stand to reason that you may have separate interefaces for a person conducting a 1) Deposit Transaction, 2) Withdrawal Transaction, and 3) Transfer Transaction. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need.
You can read Robert’s words about the Interface-Segregation Principle in this PDF.