Interface Segregation Principle Using Python

Introduction

 

In OOP (Object Oriented Programming) languages the solid principle plays a desired design role to make a class flexible and easy to understand. Today we will see the Interface segregation principle.

 

Why ISP?

 

When we design/develop a class, that class should not implement any such function which not required by the customer even it those related class that we are designing or developing.

 

Let us see with an example, Develop calculator for School, Shops and for Programmers.

 

When we say calculator many things will come into mind i.e. add, sub, div, multiplication, Trigonometry functions, Calculus, etc.

 

Below is the code which full fill requirement all 3 kind of users mentioned above i.e. School, Shops and for Programmers 

import math

class Calculator():
    def add(self, *nums):
        return sum(nums)

    def substract(self, a, b):
        return a - b if a > b else b - a

    def multplicaton(self, nums):
        return math.prod(nums)

    def division(self, a, b):
        return a - b if a / b else b / a

    def sin_of(self, x):
        return math.sin(x)

    def cos_of(self, x):
        return math.cos(x)

    def tan_of(self, x):
        return math.tan(x)

    def convert_hex_to_binary(self, input):
        return f"Add logic to Convert to Binary for hex input : {input}"

    def convert_binary_to_hex(self, input):
        return f"Add logic to Convert to hex for Binary input : {input}"

But if we observe the above code we can understand that we are giving some extra features which users may not interested in (as the user won’t use it).

 

For example, a shop holder needs only common functions like add, sub, mult, div. this user doesn’t need Trigonometry functions and HexToBinary and Vice versa function.

 

And school students need Common functions + Trigonometry functions + may need or may not need HexToBinary and Vice versa function. 

 

But as we designed and developed class including all together we don’t have an option for segregation here. We need to deliver all features to the end-user.

 

At this stage we ISP will play a key role. We can split the Calculator class into below Abstract classes (Contracts).

from abc import ABC, abstractmethod

class ICommonCalci(ABC):
    @abstractmethod
    def add(self, *nums):
        pass

    @abstractmethod
    def substract(self, a, b):
        pass

    @abstractmethod
    def multplicaton(self, nums):
        pass

    @abstractmethod
    def division(self, a, b):
        pass

from abc import ABC, abstractmethod

class IProgrammerCalci(ABC):

    @abstractmethod
    def convert_hex_to_binary(self, input):
        pass

    @abstractmethod
    def convert_binary_to_hex(self, input):
        pass

from abc import ABC, abstractmethod

class ITrigonometryCalci(ABC):

    @abstractmethod
    def sin_of(self, x):
        pass

    @abstractmethod
    def cos_of(self, x):
        pass

    @abstractmethod
    def tan_of(self, x):
        pass

And below are the 3 new classes of calculators. And if we observe them closely we implemented multilevel inheritance over here, based on user need we can deliver the particular calculator to the user. 

class Common_calculator(ICommonCalci):
    def add(self, *nums):
        return sum(nums)

    def substract(self, a, b):
        return a - b if a > b else b - a

    def multplicaton(self, nums):
        return math.prod(nums)

    def division(self, a, b):
        return a - b if a / b else b / a

class School_calculator(Common_calculator, ITrigonometryCalci):
    def sin_of(self, x):
        return math.sin(x)

    def cos_of(self, x):
        return math.cos(x)

    def tan_of(self, x):
        return math.tan(x)

class Programmer_calculator(School_calculator, IProgrammerCalci):
    def convert_hex_to_binary(self, input):
        return f"Add logic to Convert to Binary for hex input : {input}"

    def convert_binary_to_hex(self, input):
        return f"Add logic to Convert to hex for Binary input : {input}"

As per the above code, we can see that,

• For Shop holders we can provide Common_calculator which implements ICommonCalci
• For Students, we can provide School_calculator which inherits the Common_calculator, and implements ITrigonometryCalci
• For Programmers, we can provide Programmer_calculator which inherits School_calculator, and implements IProgrammerCalci 

This way we fulfilled all user requirements. And still this class feasible to extend with new contracts for new kinds of users and for new kinds of requirements.

 

Summary

 

In this article, we learned about the interface segregation principle. I attached the source code for this article. Download and extend it for better understanding.