Interface Segregation Principle: Sharing the Load Makes Happy Code

You walk into the hospital. Calm down, it's nothing serious, just a minor infection. The receptionist asks you what you're here for, and you tell her you have an appointment with Dr. Smith. She kindly points you at the waiting area, and says the doctor will be right with you. And surely, fifteen minutes of light magazine reading later, you're greeted by... the very same woman... now in a doctor's white coat. After seeing the doctor, she refers you to the lab for some blood work, and... surprise, surprise... the lab technician is the same woman doing receptionist and doctor duties. Weird? Well, not if you live inside some computer programs.

In this hospital situation it's extremely obvious that one person can not do it all. You need a team of trained experts to make that huge hospital machine work. If that wasn't the case, patients would get their appointments mixed up, blood samples would be mislabeled, and surgeries would be put on hold whenever there's someone at the door. In other words: pure chaos!

The Interface Segregation Principle

There is a similar principle in programming, that tries to keep us programmers from giving one interface too much to do. It's called The Interface Segregation Principle (ISP), and the definition is as follows:

No client should be forced to depend on methods it does not use.

What this means in simpler terms is to keep your interfaces focused and clean, so there's nothing in there that runs the risk of something not being used by a child class.

Robert C. Martin (yes, the same guy who coined the Single-Responsibility Principle) formulated this principle, while he was consulting for Xerox. They had this god-like Job-class, handling functions of a printer that could print, but also staple paper together.

This resulted in a staple job running and also having access to all the functionality of the print job, while having no use for these methods. You don't want code like that!

Stressed-Out Staff

Let's start off with a bad example in Java-code, similar to our poor overworked Dr. Smith:

Here, our HospitalStaff interface is overloaded with responsibilities. Just like our overworked hospital worker, any class that implements this interface has to deal with methods it might not need or use. This violates the principles of interface segregation big time, since the code above is about as segregated as your local dog park.

The Good Staff... ahem... Stuff

To fix this, we would just separate out all this hospital staff 'stuff', like so:

In the example above, I've even added some more method declarations. Our receptionist, lab worker and surgeon don't have to change roles (and clothes) two hundred times every day. Now they have a little more time on their hands to take on more focused duties.

No client should be forced to depend on methods it does not use.

Real-World Application: The ISP Checklist

When implementing the Interface Segregation Principle in your real-life code projects, keep these handy pointers in mind:

1. Identify Responsibilities: Break down what your interfaces need to do. Just like separating hospital duties, understand each specific responsibility.

2. Create Focused Interfaces: Design interfaces that focus on a single task or a closely related set of tasks. Think small and specific.

3. Implement Thoughtfully: Only implement the interfaces that are needed. Don’t force a class to wear too many hats—unless you’re trying to win a hat-making competition, and even then, it’s best to stick to one style.

Sharing Is Caring

No one likes a class that does it all. That was clear in part one of the SOLID design principles (The Single-Responsibility Principle), and it's also true of interfaces. Until next time, keep your interfaces clean and your hospital staff separate. Happy coding, and even happier living!

Next Up...

This article is the fourth part in a series of five articles I'm writing about the so-called SOLID design principles. Below, I will add links to the other four, as they release.

- Single-Responsibility Principle: Don't Turn Your Code Into a Swiss Army Knife

- Open-Closed Principle: Don't Give Your Code Too Many Facelifts

- Liskov Substitution Principle: Why Your Code Shouldn't Need a Parachute

- Dependency Inversion Principle: Don't Let Low-Level Details Push You Around