The fourth post in the SOLID by Example series deals with the Interface Segregation Principle (ISP). It states that clients should not be forced to implement interfaces they don’t use. Or as Uncle Bob puts it: Make fine grained interfaces that are client specific.
For us developers S.O.L.I.D. is a five letter acronym with each letter pointing to a basic principle of good Object Oriented Design. The principle set was introduced almost twenty years ago by Robert C. Martin (Uncle Bob), a well known author, speaker and thinker on the subject. In this series we discuss each principle with some practical code examples.
In the following example we have a simple Person class with some obvious person-like methods and properties. We also have a BirthdayCalendar class that has an Add() method to add a person’s birthday to the calendar. The Add() method takes a Person object as a parameter.
This makes sure that Person and BirtdayCalendar are tightly coupled. If Person changes, this can have an impact. If we want to add birtdays from entities other than from a Person we’re in trouble. There’s also no need for BirtdayCalendar to know all of Persons interface.
This is why some might say that this class has a fat interface. It has a few useless properties and methods for different clients using the interface. To prevent this we let BirthdayCalendar specify an interface that Person must implement. In this case IBirthday with a Name, Age and DayOfBirth property.
This makes BirthdayCalendar independent of the Person class which makes it easier to maintain and extend. Imagine we also wanted to add the birthdays of pets to the BirthdayCalendar. The Pet class only had to implement the IBirtday interface to achieve that.