ISP: The Interface Segregation Principle

Introduction

This is the 11th article in the System Design and Software Architecture series. In this article, we are discussing the sub-topic of the design principle, ISP: Interface Segregation Principle.

What is The Interface Segregation Principle?

The Interface Segregation Principle states that clients should not be forced to run interfaces that they do not use. Instead of a single huge interface, many smaller interfaces are more optimal based on the methodology, each serving one sub-module.

ISP divides interfaces that are too large into smaller and more specialized interfaces so that clients only need to execute the methods that interest them.

The purpose of ISP is to facilitate the disassembly, modification, and re-deployment of a system. Because a system is connected at different levels, changes cannot be made in one place without needing additional changes elsewhere. These side effects can be prevented by using an interface or an abstract class.

An Accurate Summary is Key to the Interface Segregation Principle

Finding the right abstractions is more than just an art. You have to explore your domain, often create interpretation nets, submit user stories, and draw interaction diagrams—all of which may not lead you to correct abstractions. Wrong abstractions are worse than no abstractions at all, so do not forget about the third rule.

When you think you are done with some of your abstractions, portray them as interfaces. The techniques mentioned above make them a terrestrial interface. With this approach, concrete classes function only to the extent necessary for those abstractions. So we end up with satisfaction without knowing that the Interface Segregation Principle exists.

Violation of Interface Segregation Principle

When a client relies on methods that it does not use, it means your abstraction is wrong. Martin Fowler’s role example of an interface (a natural encyclopedia of ISP applications) reveals incorrect initial object decomposition. It does not take an independent policy to express it. The code is clearly not compact. So do not meditate on whether your code violates the principle of interface segregation; think about whether your abstractions are correct.

Importance

In object-oriented design, the code simplifies and creates abstract layer interfaces that create a barrier to prevent interaction with dependencies.

According to many software experts who have signed the Policy Statement for Software Technology, writing well-designed and self-explanatory software is as important as writing working software. It is often a good idea to use interfaces to further explain the intent of the software.

Because a system is connected on multiple levels, changes cannot be made in one place without needing additional changes elsewhere. These side effects can be prevented by using an interface or an abstract class.

Code Indicating ISP Violation and How to Fix Them

Whether working alone or in large groups, it helps to identify problems with the code in advance. Here are some code patterns that can indicate an ISP violation.

Great Interface

In large interfaces, there are too many operations, but most objects do not use these operations. ISP tells us that we need most or all of the methods in an interface, but in a large interface, we often need only a few. When testing a large interface, we need to identify which dependencies should be mocked and which may have a giant test setup.

Unused Dependencies

Another implication of ISP violation is giving a system a value of zero or equivalent. In our example, we can use orderCombo() to place a burger-only order by passing zero as the fries parameter. This client does not need to depend on fries, so we must have a separate interface for ordering fries.

Exception-Throwing Methods

As in our burger example, if we encounter a non-operational exception like NotImplementedException, it may indicate an ISP-related design problem. This could be a good time to redesign these classes.

Should Interfaces Always Have a Single Method?

Applying ISP aggressively can result in a single-method interface, known as an “interface.”

This solution will solve the problem of ISP violation but may also violate the coherence of interfaces, making it difficult to maintain a scattered code base. For example, in Java, the Collection interface has many methods, such as size() and isEmpty(), which are often used together, so it makes sense to have a single interface.

ISP reduces code objects to their smallest execution and removes dependencies that are not required for the object to function properly. The effect of implementing this principle is having many small, centralized interfaces that only define what is needed to implement them.

Is It Worth It?

Sometimes it is worth it. This is the only SOLID principle. By following this principle aggressively, you can get more flexible and changeable code. It is very useful for real-world projects.

Conclusion

ISP is a straightforward principle that is easy to override by gradually adding to existing interfaces that clients do not need. ISP is also closely related to other SOLID principles.

There are many code smells that can help us identify and correct ISP violations. However, we need to keep in mind that over-aggressive implementation of any principle can lead to other problems in the codebase.

LSP taught us why reality cannot be represented as a one-on-one relationship with programmed objects and how subcategories respect their parents. Let us also consider other principles that we already know.

ISP teaches us to respect our clients more than we thought. Respecting their needs makes our code better and makes our lives easier as programmers.

Thanks for reading the article ISP: The Interface Segregation Principle as an essential component in system design and architecture.

Originally published at https://onloadcode.com on April 4, 2021.