Introduction
In OOP (Object Oriented Programming) languages the solid principle plays a desired design role to make a class flexible and easy to understand. In that, we will see today the Interface segregation principle.
Why ISP?
When we design/develop a class, that class should not implement any such interfaces which are not required by the customer even if it is related to that class which we are designing or developing.
Let us see with an example, in which we'll sevelop a 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 fulfills the requirement all 3 kinds of users mentioned above i.e. School, Shops and for Programmers
But if we observe the above code we can understand that we are giving some extra features which users may not be interested in (as the user won’t use it). For example, a shop holder needs only common functions like add, subtract, multiply, divide. this user doesn’t need Trigonometry functions and HexToBinary and Vice versa functions.
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 the option for segregation here. We need to deliver all features to end-user.
At this stage we ISP will play a key role. We can split the Calculator class into the below interface (Contracts).
- namespace Solid.Principle.ISP.Demo.Contract
- {
-
-
-
- public interface ICommonCalci
- {
- int Add(params int[] nums);
- int SubStract(int a, int b);
- int Multplicaton(params int[] nums);
- int Division(int a, int b);
- }
- }
- namespace Solid.Principle.ISP.Demo.Contract
- {
-
-
-
- public interface ITrigonometryCalci
- {
- double SinOf(double x);
- double CosOf(double x);
- double TanOf(double x);
- }
- }
- namespace Solid.Principle.ISP.Demo.Contract
- {
-
-
-
- public interface IProgrammerCalci
- {
- string ConvertHexToBinary(string input);
- string ConvertBinaryToHex(string input);
- }
- }
And below is the newly designed calculator class by inheriting all 3 interfaces. Based on user needs we can deliver the particular interface(s) to the user.
As per the above code, we can see that
- For Shop holders we can provide an interface ICommonCalci
- For Programmers we can provide ICommonCalci + IProgrammerCalci.
- For Students we can provide ICommonCalci + ITrigonometryCalci + IProgrammerCalci (Based on Requirement)
This way we fulfilled all user requirements. And still this class is feasible to extend with new interfaces 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.