Understanding SOLID Principles: Interface Segregation
16 september 2020
Have you ever seen a class method in your project, the core of which would be one line only: throw new NotImplementedException()?
Is this the right solution? Could such a code cause an issue?
Not Implemented Exception
Amongst all the rules SOLID ISP is the easiest one. However, even that rule is often being infringed. The above method helps to create good interfaces. This means – interfaces which define the contract to so many coherent functions that there is no chance the class occurs, which implements only part of the contract. Let’s take a look at a simple example of the interface for geometric figures.
Does the Circle need to have the HowManySides method?NoImplementedException?
Such a solution is always incorrect. The above exception should only suggest that there is still a method to be implemented. It is not to indicate that a specific object doesn’t have the functionality described by the interface. In this simple example the setup of the interfaces is presented in the picture below:
When creating the interfaces we should always consider them to be a certain definition of functionality, which will be provided by the implementing classes. This functionality (the only one), according to SRP, can be divided into several public methods. However, they should define one fixed indivisible combination. ICollection<T> from the .NET environment is a good example here, it has ‘111’ methods. It classifies the object as a collection providing it fulfills certain rules:
- Inserting the element
- Removing the element
- Voiding the collection
- Verification of the element in the collection
- Summary of the elements in the collection
- Verification whether the collection is read-only
It is difficult to think of a collection, that doesn’t have one of the above functions. It is much easier to imagine a figure that has a surface area, perimeter, but doesn’t have a specified number of sides.
How many methods?
As the software developers we are straightforward people, therefore we need the precise guidelines regarding how many methods a good interface should have? 1?2? 4?8?16? Or many more? In most cases it would be around 2 to the 2nd power. It is worth mentioning that the most relevant interfaces, for instance in the .NET environment such as:
Consist of one method only. Their value is very high though, due to the high volume of functionality of the classes they are provided by.
Architecture and ISP
The incorrectly programmed interfaces, especially in the distributed systems, may cause a lot of issues. When they use other rules, the SOLID code which we implement, will depend only on the abstraction, therefore the incorrectly defined interfaces may cause a serious damage. There will be libraries created, which, according to the contract, should provide specific functionalities. In fact, they will only discard the exceptions.
While creating every single interface, it is worth asking yourself whether it is not too large. It might be worth splitting it into smaller parts. Is there a risk of creating the object that will not be able to fulfill the whole contract? It is good to remember that the class may depend on many interfaces and it may consist of one method only whilst still being a correct interface.