Interface-Segregation Principle (ISP) – Principles of Object-Oriented Class Design

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.

Agile Software Development, Principles, Patterns, and Practices

Book: Agile Software Development, Principles, Patterns, and Practices (Amazon)
Author: Robert C. Martin (Amazon)
Publisher: Prentice Hall; 1st edition (October 15, 2002)
Hardcover: 552 pages

Previous Chapters


Chapter 12 is on the Interface-Segregation Principle (ISP):


Interface-Segregation Principle

Clients should not be forced to depend on methods that they do not use.


This principle is very much related to the High Cohesion GRASP Pattern

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.

This entry was posted in Design Patterns. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>