Solid : Interface Segregation Principle

ISP terdiri dari dua kata utama yaitu Interface dan Segregation, yang mana interface pada ISP disebut sebagai kontrak atau protokol. Sedangkan Segregation berarti memisahkan. Dari dua kata ini bisa diambil kesimpulan bahwa ISP adalah Pemisahan kontrak-kontrak atau protokol-protokol yang terlalu besar menjadi protokol-protokol atau kontrak-kontrak kecil.

Tulisan ini adalah bagian dari SOLID Principles Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.

Berdasarkan history-nya, ISP dikenalkan ketika Robert C. Martin berkonsultasi dengan Xerox yang merupakan brand dari Mesin Printer. Pada saat itu Xerox membuat printer baru yang mana bisa menambah beberapa fitur yang di versi printer lainnya tidak ada. Pada saat itu, Xerox menambah fitur baru seperti kemampuan Stapling (Menstaples kertas) dan Faxing (Menerima dan mengirim Fax) pada printer barunya. Dengan adanya penanambahan fitur tersebut maka pasti akan diperlukan perubahan program yang tentunnya akan berpengaruh pada program yang digunakan oleh device printer versi lainnya. Jika desain dari program bermasalah, maka potensi akan mengakibatkan error pada device printer lainnya akan tinggi ketika program printer di-update. Maka dari itu munculah gagasan baru yang sekarang kita kenal ISP (Interface Segregation Principle).

Ide dari Interface Segregation Principle cukup sederhana, yaitu

“Client should not be forced to depend on methods it does not use”

Yang berarti Client (class/object yg berkorelasi) seharusnya tidak dipaksa untuk meimplementasikan method yang diluar dari tugas spesifik clientnya atau objectnya. Dengan begitu class atau object akan lebih ringkas karena tidak mengimplementasikan banyak method-method yang tidak digunakan ke dalam class tersebut selain itu class atau object akan hanya memiliki tugas yang spesifik (SRP).

Sebagai contoh kasus, kita gunakan contoh kasus sebelumnya tentang Vending Machine.

Asumsi kita memiliki sebuah class NotifyEvent seperti ini

class NotifyEvent {

    private data: Record<string, any> = {}

    setup(data: Record<string, any>) {
        this.data = data
    }

    console() {
       // Code for testing logging
    }

    async send() {
        if (process.env.NODE_ENV === 'testing') {
            return this.console(this.data)
        } else {
            return await this.sendSMS()
        }
    }

    async sendSMS() {}

}

Kegunaan utama dari class tersebut adalah untuk mengirim notifikasi SMS yang ditandai dengan adanya method sendSMS pada class tersebut. Sedangkan pada contoh ini, method console digunakan untuk kebutuhan automated test untuk usecase tersebut. Jika mengikuti class tersebut, bentuk interface kurang lebih akan seperti ini:

interface INotifyEvent {
  setup(data: Record<string, any>): void
  console(): void
  send(): Promise<void>
  sendSMS(): Promise<void>
}

Pada contoh di atas mungkin interface masih terlihat lean karena method digunakan sedikit, tapi ketika method yang dimiliki class tersebut cukup banyak, maka interface akan menjadi besar (bloat). Sehingga perlu dilakukan penyederhanaan interface dengan cara memisahakan interface berdasarkan fungsi utamanya dengan tujuan agar class yang mengimplementasi interface tersebut tidak dipaksa untuk mengimplementasikan method yang tidak diperlukan.

Maka interface akan menjadi kurang lebih seperti ini:

interface INotifyEvent {
    setup(data: Record<string, any>): void
    send(): Promise<void>
}

interface INotifySMSEvent extends INotifyEvent {
    sendSMS(): Promise<void>
}

interface INotifyTestEvent extends INotifyEvent {
  console(): void
}

Dengan memisahkan interface seperti ini, maka class yang mengimplementasikannya tidak akan dipaksa mengimplementasikan method yang tidak diperlukan. Misal jika class akan digunakan untuk keperluan testing, maka class akan mengimplementasi interface INotifyTestEvent yang hanya memerlukan method console. Class yang bersangkutan tidak akan dipaksa mengimplemntasikan method sendSMS karena tidak diperlukan. Sehingga class akan lebih simple dan sesuai kegunaannya.

references:

Interface Segregation Principle ( ISP )

Subscribe to my newsletter

Andriawan

Andriawan