Implementing SOLID Principles with Dart Code for the Flutter (part 5/6)

Interface Segregation Principle

The “Interface Segregation Principle” or ISP, which is the fourth principle of SOLID, states that “Clients should not be forced to depend upon interfaces that they do not use.” In simpler terms, interfaces should be designed in such a way that when a class uses them, it is not required to implement or override methods that it does not use.

In short and in a brief sentence, “Don’t be dependent on things you don’t need.”

To better understand the concept through a complete practical example, we will implement it in two correct and incorrect ways.

1-The following example violates ISP :

Let’s assume that there is a travel agency that includes several methods for booking airplane tickets. For example, it has online, telephone, and in-person customers.

Also, in order to handle their payments, it has an online portal for (online customers) and accepts payments via POS terminal for (in-person and telephone customers).

To begin, we create an interface or abstract class called TravelAgencyInterface.

abstract class TravelAgencyInterface {

  void acceptWalkInReserveTicket();

  void acceptOnlineReserveTicket ();

  void acceptTelephoneReserveTicket();

  void payOnline();

  void payByPOS();
}

As you can see, we have three methods for our customers: in-person, phone, and online. In-person and phone customers will pay for their ticket using the POS device, while online customers will pay using the online payment gateway.

Let’s start by implementing the TravelAgencyInterface for online customers. We consider the class name to be OnlineCustomerImpl.

class OnlineCustomerImpl implements TravelAgencyInterface {

    @override
  void acceptWalkInReserveTicket() {
        // Not Applicable
    throw Exception();
  }

  @override
  void acceptOnlineReserveTicket() {
    // Logic for online customer
  }

  @override
  void acceptTelephoneReserveTicket() {
    // Not Applicable
    throw Exception();
  }

    void payOnline(){
      // Logic for online payment
    }

  void payByPOS(){
    // Not Applicable
    throw Exception(); 
  }
}

As the OnlineCustomerImpl is for online customers, we need to throw an exception for methods that are not applicable for online customers. This is where we can see a clear violation of the Interface Segregation Principle, which also undermines the Single Responsibility Principle.

Now let’s fix the issues of the above program while observing the principle of separating interfaces.

2-The following example adheres to ISP :

To solve the problem, we take the action of reducing the size of the OnlineCustomerImpl interface and divide it into two interfaces: OrderInterface and PaymentInterface.

abstract class OrderInterface  {
  void reserveOrder();
}

abstract class PaymentInterface {
  void payForOrder();
}

Now, we will implement new interfaces for all three types of customers.

class OnlineCustomerImpl implements OrderInterface, PaymentInterface {

  @override
  void reserveOrder() {
    // logic for online reserve
  }

  @override
  void payForOrder() {
    // logic to do online payment
  }
}

class WalkInCustomerImpl implements OrderInterface, PaymentInterface {
  @override
  void reserveOrder() {
    // logic for in-person reserve
  }

  @override
  void payForOrder() {
    // logic to do pos payment
  }
}

class TelephoneCustomerImpl implements OrderInterface, PaymentInterface {
  @override
  void reserveOrder() {
    // logic for telephonic reserve
  }

  @override
  void payForOrder() {
    // logic to do pos payment
  }
}

One of the advantages that the principle of interface segregation provides us with includes the following:

1- Increased code readability .

2- Easier implementation .

3- Easier maintenance .

4- Better organization of code .

5- No need to use unnecessary throw exceptions .

The final point is that both the principle of interface segregation and the single responsibility principle have almost the same goal: ensuring small, focused, and highly cohesive software components.

And the difference between them is that the principle of single responsibility pertains to classes, while the principle of interface segregation pertains to interfaces.

In the following articles, we will review the implementation details of each section together with Dart codes.

Introduction to SOLID
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle