Konsep SOLID Principle: Open / Closed Principle
Setelah kita membahas tentang Single Responsibility Principle, sekarang kita beranjak ke bab baru yang membahas tentang Open/Closed Principle.
software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
— Bertrand Mayer
Bingung? Jadi begini, semisal kita punya suatu projek yang sudah berjalan, dengan menerapkan OCP dengan benar, kita bisa saja menambah fitur baru tanpa harus menyenggol code lama yang sudah ada sebelumnya (extending the existing system, but not changing them). Kuncinya ada di abstraksi, jika kita terbiasa membangun sebuah software dengan abstraksi yang bagus, maka hal ini bisa dilakukan.
Kalau masih belum punya gambaran konkrit, kita bisa langsung ke contoh permasalahan, dan tentu saja disertai dengan contoh kodenya.
Contoh kasus
Misalkan dalam sebuah aplikasi ada salah satu kebutuhan yang berbunyi seperti ini
- Ketua jurusan bisa mendelegasikan tugas untuk melakukan persetujuan proposal skripsi kepada sekretaris jurusan saja.
Si developer bisa saja menuliskan kode seperti ini
Jika ada perubahan kebutuhan yang berbunyi seperti ini
- Ketua jurusan bisa mendelegasikan tugas untuk melakukan persetujuan proposal skripsi kepada sekretaris jurusan atau ketua prodi.
Dengan abstraksi yang buruk, atau developer belum paham OOP yang benar, si developer bisa saja menuliskan kode seperti ini
Nah, ketika ada perubahan kebutuhan seperti diatas, class HeadOfDepartment ikut berubah gara-gara si kepala prodi bisa ditugasi untuk melakukan persetuan proposal skripsi. Ini jelas melanggar konsep Open/Closed Principle, yang mana tidak boleh ada modifikasi suatu entitas software, baik class, function, modul, atau lainnya. Selain itu pula, class HeadOfDepartment juga memiliki coupling yang tinggi terhadap class lain, sehingga ketika kita akan melakukan unit test, kita akan kesulitan untuk membongkar pasang dependencynya, dalam hal ini si delegate yang bisa saja sebagai sekretaris jurusan maupun ketua prodi.
Cara penyelesaiannya?
Karena si sekretaris jurusan dan ketua prodi sama-sama bisa melakukan persetujuan proposal skripsi, berarti ia sama saja menaati kontrak yang sama, yaitu melakukan persetujuan proposal skripsi. Oleh karena itu, kita bisa menuliskan kontrak tersebut seperti ini.
Ketika kontrak telah dibuat, kita bisa melakukan refactor kode sebelumnya menjadi seperti ini
Kalau misalnya ada perubahan kebutuhan lagi, si kepala jurusan bisa mendelegasikan tugas kepada staf akademik untuk melakukan persetujuan proposal skripsi, maka selama si staf akademik menyepakati kontrak sebagai ThesisApprovalOfficer , maka class HeadOfDepartment tidak perlu diubah-ubah lagi, karena dependencynya sudah diabstraksi.
Unit test jadi mudah
Karena dependency si HeadOfDepartment , yaitu ThesisApprovalOfficer sudah abstrak, maka ketika kita akan melakukan unit test, kita bisa meng-inject dependency dengan mock dependency dengan mudah, tanpa bergantung dengan class lain.
Kesimpulan
Open/Closed Principle bisa dicapai dengan mengabstraksikan dependency-dependencynya. Karena sebenarnya, si client tidak perlu tahu detail implementasinya seperti apa, ia hanya perlu tahu si objek itu bisa apa. Dengan abstraksi yang bagus, akan membuat code kita menjadi less coupled serta memiliki adaptivitas yang bagus terhadap perubahan.
Sekian penjelasan singkat mengenai konsep Open/Closed Principle. Jika ada koreksi maupun pertanyaan bisa kita diskusikan bersama 😉.
