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.