Thread by @oliverjumpertz

Just imagine that you need 20 different keys on your keyring to enter your home but only one of them is actually used to unlock the door.

The Interface Segregation Principle tries to solve this problem for software.

🧵🔽

1️⃣ What does it state?

The Interface Segregation Principle (ISP) sets a pretty simple statement:

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

The ISP applied to the extreme will result in single-method interfaces, also called role interfaces.

You can take a look at the following example to get an idea of how the ISP can be violated in one way (it's in TypeScript).

Can you spot the issue?

The class implementing the interface actually doesn't want to implement two of the three methods defined within the interface. But it is forced to do so because the interface is too bulky.

The client in this case is you, satisfying the interface.

2️⃣ What does it try to prevent?

Most importantly it tries to prevent:

- Confusion among client developers
- Sprawling maintenance costs

But we'll take a look to find out what this actually means now.

ℹ️ Confusion among client developers

Imagine you had to implement such a bulky interface, like above, although you only wanted to use a base class to implement employee reports.

Wouldn't you be confused that you also had to implement so much more? I would be.

It's also a sign that the base class maybe tries to do too much.

Nevertheless, you are left with the need to actually do something about the methods you didn't intend to use at all. And even the thoughts you have to put into thinking about what to do are unnecessary work.

ℹ️ Sprawling maintenance costs

Every time the interface changes, several classes implementing it need to change. And in this case, it doesn't even matter if they actually implement all of the methods.

They are forced to if the client wants their code to compile or at least run error-free at runtime.
This is a huge addition to maintenance costs. And this is a driver of unnecessary work for every client developer.

3️⃣ Fixing the issue

One way to fix the issue can now be to actually pull the interface apart, as shown below.

This is the extreme version of the ISP applied, role interfaces which all do exactly one thing.

With a little more thought, however, you can fix the issue even better, by generalizing the interface.

Take a look at the version below. Any notions of specifics were removed due to the fact that you now have a pretty generic interface, which can be implemented in many ways.

4️⃣ Should you care?

I'm pretty sure you already know the answer => Yes, you should.

Bulky interfaces can occur in any language, even in dynamically typed ones like JavaScript.

Although you don't have interfaces at hand, you still define, by the code you write, what you expect a client to pass to you.

Just imagine a function that takes a god object and uses several methods on that object to do its work. Everyone using your function would have to put at least something into those object's methods to make your function work.

The ISP saves you and others from putting in a lot of unnecessary work into the implementation of unwanted dependencies. And as with nearly any other principle associated with clean code, code becomes more readable and tests become better as well as more maintainable.

5️⃣ Show Your Support

You can read this thread in the form of a blog post if that suits you better. You can find the link below.

blog.oliverjumpertz.dev/isp-the-interf…

And did you know that I have a newsletter where I share valuable insights, especially on how to upskill yourself?

You can read all past issues online, so no need to subscribe directly. Test it out first.

getrevue.co/profile/oliver…