SOLID — From Zero To Potato 4

About Interface Segregation Principle (ISP)

Today i will explain about Interface Segregation Principle (ISP), this principle is very similar with LSP, so don’t be confuse with LSP, so i will explain about what is different between this two principle.

LSP governs relationships between parent and child classes (i.e. hierarchical relationships). It tells you how to implement. The ISP governs relationships between parent and client classes (i.e. producer/consumer relationships). It tells you when to implement.

So let move what is Interface Segregation Principle (ISP), ISP states that we should design interfaces that are specific to the needs of a particular client or set of clients, rather than creating large, monolithic interfaces that may be unnecessary for some clients.

Interface Segregation Principle (ISP): A client should not be forced to depend on interfaces it does not use.

Let move to the implementation, we have an interface called StudentActivities that defines various methods related to student activities:

interface StudentActivities {
    fun joinClub(club: String)
    fun joinSportsTeam(sportsTeam: String)
    fun attendEvent(event: String)
    fun volunteerForEvent(event: String)
    fun joinStudyGroup(subject: String)
}

we also have a Student class that implements this interface as below :

class Student : StudentActivities {
    override fun joinClub(club: String) {
        // join the specified club
    }

    override fun joinSportsTeam(sportsTeam: String) {
        // join the specified sports team
    }

    override fun attendEvent(event: String) {
        // attend the specified event
    }

    override fun volunteerForEvent(event: String) {
        // volunteer for the specified event
    }

    override fun joinStudyGroup(subject: String) {
        // join the specified study group
    }
}

In this example, you will notice the Student class is forced to implement all the methods of the StudentActivities interface, even if the student may not be interested in all the activities defined in the interface. This violates the Interface Segregation Principle because the interface is too broad and not cohesive.

Let refactor to the correct above example now, we can break the StudentActivities interface into smaller, more focused interfaces that are easier for clients to consume:

interface ClubActivities {
    fun joinClub(club: String)
}

interface SportsActivities {
    fun joinSportsTeam(sportsTeam: String)
}

interface EventActivities {
    fun attendEvent(event: String)
    fun volunteerForEvent(event: String)
}

interface StudyGroupActivities {
    fun joinStudyGroup(subject: String)
}

class Student : ClubActivities, SportsActivities, EventActivities, StudyGroupActivities {
    override fun joinClub(club: String) {
        // join the specified club
    }

    override fun joinSportsTeam(sportsTeam: String) {
        // join the specified sports team
    }

    override fun attendEvent(event: String) {
        // attend the specified event
    }

    override fun volunteerForEvent(event: String) {
        // volunteer for the specified event
    }

    override fun joinStudyGroup(subject: String) {
        // join the specified study group
    }
}

In this refactored version, we split down the StudentActivities interface into four smaller, more focused interfaces: ClubActivities, SportsActivities, EventActivities, and StudyGroupActivities. The Student class now implements only the interfaces that are relevant to its behavior.

This adheres to the Interface Segregation Principle because clients that need only a specific subset of the activities defined in the interfaces can now depend only on the corresponding smaller interface, rather than having to depend on a larger, less cohesive interface that contains methods they don’t need.

Thank you for taking the time to read this article. I hope that my writing has been informative and thought-provoking.I will explain about Dependency Inversion Principle (DIP) in next article. Happy Coding to all of you.

Previous Article about SOLID :

Single Responsibility Principle (SRP) : https://medium.com/arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

Open/Closed Principle (OCP): https://medium.com/arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

Liskov Substitution Principle (LSP): https://medium.com/arpalar-tech/solid-from-zero-to-potato-3-94d6f63dbbfe