Interface Segregation Principle

Interface Segregation Principle (ISP)

In this tutorial, we will discuss Interface Segregation Principle (ISP) in SOLID Principles. This principle is the first principle that applies to Interfaces instead of classes in SOLID, and it is similar to the single responsibility principle.

The Interface Segregation principle is one of the SOLID principles of object-oriented software design. The philosophy of the Interface Segregation principle is – larger interfaces should be split into smaller ones.

interface segragation

Interface Segregation Principle (ISP) states that “do not force any client to implement an interface which is irrelevant to them. “ Here your main goal is to focus on avoiding fat interface (The fat interface is an anti-pattern that applies to modules/classes with a large interface with too many exposed functions/methods) and give preference to many small client-specific interfaces. You should prefer many client interfaces rather than one general interface, and each interface should have a specific responsibility.

Suppose you enter a restaurant and you are a pure vegetarian. The waiter in that restaurant gave you the menu card, including vegetarian items, non-vegetarian items, drinks, and sweets. As a customer, you should have a menu card that includes only vegetarian items, not everything you don’t eat in your food. Here the menu should be different for different types of customers. The common or general menu card for everyone can be divided into multiple cards instead of just one. Using this principle helps in reducing the side effects and frequency of required changes.

Let’s stop theory and see an example. For example, let’s say you have an interface called UPIPayment like below.

package com.ashok.solid.principles.isp;

/**
 * 
 * @author ashok.mariyala
 *
 */
public interface UPIPayments {

	public void payMoney();

	public void getScratchCard();

	public void getCashBackAsCreditBalance();
}

Now let’s talk about a few implementations for UPIPayments like Google Pay and Paytm.

Google Pay supports these features. So we can directly implement these UPIPayments, but Paytm doesn’t support the getCashBackAsCreditBalance() feature. So here, we shouldn’t force client Paytm to override this method by implementing UPIPayments.

we need to segregate interfaces based on client needs, so to support this Interface Segregation Principle (ISP), we can design something like below

package com.ashok.solid.principles.isp;

/**
 * 
 * @author ashok.mariyala
 *
 */
public interface UPIPayments {

	public void payMoney();

	public void getScratchCard();
}
package com.ashok.solid.principles.isp;

/**
 * 
 * @author ashok.mariyala
 *
 */
public interface CashbackManager {
	public void getCashBackAsCreditBalance();
}
package com.ashok.solid.principles.isp;

/**
 * 
 * @author ashok.mariyala
 *
 */
public class GooglePay implements UPIPayments, CashbackManager {

	public void payMoney() {
           // logic
        }

	public void getScratchCard() {
           // logic 
        }

	public void getCashBackAsCreditBalance() {
           // logic
        }
}
package com.ashok.solid.principles.isp;

/**
 * 
 * @author ashok.mariyala
 *
 */
public class Paytm implements UPIPayments {

	public void payMoney() {
           // logic
        }

	public void getScratchCard() {
           // logic 
        }
}

Based on client needs, we segregate the interface. Let’s say Paytm now implements from UPIPayments then as a client. We are not forcing him anything to use that follows Interface Segregation Principle (ISP).

Interface Segregation Principle
Scroll to top