I— (Interface Segregation) From SOLID principles 4/5

Hello Folks,

I hope you are righting solid code 😉 because you guys are amazing. This article is going to be very interesting because this principle is one of the most violated principles by amazing developers. Oh! so before we start this article in detail I would like you to check my previous article part1, part2, and part3 on the series of amazing SOLID principles.

So what Interface segregation principle is?
Let’s start with the Bookish definition

Clients should not be forced to depend upon interfaces that they do not use

If you open your recent project you will see some interfaces implementation is not fully used and some methods are left alone or not required at some clients. If this is the case with your interfaces then you are violating this principle. So the question arises, how this principle helps us in designing good code.

Hold your horses!! I’ll explain this in detail with an example of both bad and good code

interface Shape {
    fun area(): Float
    fun volume(): Float
}

class Square : Shape {
    var side: Float = 0f
    override fun area() = side * side

    override fun volume(): Float {
        //Does not apply for Square so returning zero
        return 0f
    }
}

class Cube : Shape {
    var side: Float = 0f
    override fun area(): Float {
        //Does not apply for Cube so returning zero
        return 0f
    }

    override fun volume() = side * side * side
}

In the above example, we are designing Geometry based software, and we’ve decided that will make an interface containing some mostly used methods in Geometry classes. We ended up writing Shap interface with two methods area and volume. Cool, now let’s begin with implementing some shapes. Starting with Square we implemented a shape interface and it forced me to implement both volume and area methods.

Q: What ? You ever heard a square having volume ?
ANS: Nope!! because it’s a two-dimensional shape.

You can smell a bad code because we are forcefully asking our shapes to implement methods that they don’t use or own.

Now look into Cube class, the problem is the same here a cube won’t have an area feature.

So you will be thinking about how this forceful implementation going to affect my code in the future. Let me explain this, this principle is close to the single responsibility principle but in a different manner. We are talking about interfaces with very clear responsibilities. It doesn’t mean that an interface should only have one method to implement but it’s more towards having clear/mandatory responsibilities. There should be clarity.

If there are methods that a class is not implementing it may lead to unwanted changes, may cause crashes or unwanted results which are confusing for client developers that is why this method is implemented which is another downside of it. Let’s say we made some changes in the volume method in the interface because we want to return Int instead of Float so this change is unnecessary for Square shape because they are not using this method but we’ll be forcefully asked to make changes/refactoring in Square as well.

I hope it’s clear why we should avoid the forceful implementation of unwanted methods. So let’s jump into a good code following ISP.

interface TwoDShape {
    fun area(): Float
}

interface ThreeDShape {
    fun volume(): Float
}


class Square : TwoDShape {
    var side: Float = 0f
    override fun area() = side * side
}

class Cube : ThreeDShape {
    var side: Float = 0f
    
    override fun volume() = side * side * side
}

You can compare differences in both examples. This example is following ISP with every interface having clear job to do and every class is implementing required methods only. Yay!! we fixed the problem :).

I hope you enjoyed this article. If you haven’t read my previous articles on SOLID go checkout part1, part2, and part3 on the series of amazing SOLID principles.

See you next week with the next article on SOLID 🙂

Bye-bye