Prinsip SOLID Dalam Konsep Object Oriented Design

SOLID adalah sebuah prinsip yang menurut aku sangat penting jika diterapkan dalam pemrograman berorientasi objek, prinsip ini akan memberikan manfaat yang dahsyat, kode program yang dibuat akan mudah dirawat dan dikembangkan lebih lanjut lagi. Kita tahu kalau melakukan refactoring kode haruslah mudah dan menyenangkan, ga mau kan sobat niatnya refactoring kode dengan niat merapikan kode malah jadinya kode yang dibuat semakin membingungkan dan berantakan. SOLID akan membantu sobat sekalian melakukan penulisan kode dengan lebih baik, baik dari sudut pandang apa kah ini? yuk mari kita bahas sob.

SOLID terdiri dari lima prinsip/sudut pandang, yaitu:

  • S – Single responsiblity principle
  • O – Open-closed principle
  • L – Liskov substitution principle
  • I – Interface segregation principle
  • D – Dependency inversion principle

 

Single Responsibility Principle

A class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).

Artinya adalah sebuah Class harus dan hanya boleh mempunyai satu tugas saja. Sebagai contoh kita memiliki beberapa bangun datar dua dimensi berupa persegi dan segitiga sama sisi, selanjutnya kita mau menjumlahkan luas semua bangun datar tersebut. Kita bisa representasikan melalui kode berikut.

Pertama-tama kita buat dulu class-nya sob seperti yang terlihat di atas, selanjutnya kita buat class AreaCalculator dan memasukkan logika perhitungan jumlah seluruh luas bangun.

Untuk menggunakan class AreaCalculator kita bisa melakukan instantiate class tersebut dan memasukkan array class bangun datar yang telah kita buat sebelumnya ke dalamnya.

Ga sampai di situ saja sob, walaupun tujuan akhir sudah tercapai. Sayangnya pada class AreaCalculator terdapat logika untuk mengeluarkan output data, hal ini tidak baik karena tidak fleksibel jika user menginginkan output dengan format yang berbeda, maka hal ini akan menjadi masalah. Class AreaCalculator seharusnya hanya menangani logika penjumlahan saja dan tidak perlu tahu user pengen output dalam bentuk JSON kah, HTML kah atau bentuk yang lainnya kah.

Oke untuk memperbaikinya kita butuh class baru lagi sob untuk manangani logika output tersebut.

Jadi sudah terlihat jelas kan sob peranan masing-masing class nya, ingat suatu class tercipta hanya untuk satu tujuan saja.

 

Open Closed Principle

Software entities should be open for extension, but closed for modification.

Artinya adalah class tersebut harus mudah untuk dikembangkan (extendable) tanpa merubah class tersebut, coba kita lihat pada method sum class AreaCalculator.

Kita perhatikan kode diatas, jika sobat ingin menambahkan bangun datar yang lainnya, maka sobat bisa saja menambahkan if/else, tapi bukan ini yang kita inginkan karena hal ini tidak sesuai dengan Open Close Principle. Singkatnya kita gak boleh lagi mengotak-atik method ini jika ada penambahan bangun datar, misalnya kita mau menambahkan lingkaran dalam daftar luas bangun datar yang mau dihitung, begitu sob.

Langkah yang diizinkan adalah memindahkan logika masing perhitungan luas ke class bangun datar yang telah kita buat sebelumnya.

Kini perhitungan jumlah menjadi lebih gampang, bisa sobat lihat seperti di bawah ini.

Tapi masih ada tapi nya sob haha, muncul masalah yang lain nih, woh masalah apa lagi ini? pada class AreaCalculator bagaimana kita bisa memastikan bahwa object yang di masukkan adalah benar dan memiliki method area?

Kita bisa mengimplementasikan interface, sebagai berikut.

Selanjutnya pada method sum class AreaCalculator kita bisa melakukan pengecekan apakah object luas berupa instance  dari interface ShapeInterface atau bukan, simple kan 😀

 

Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Artinya adalah bahwa setiap subclass/turunan harus dapat digantikan oleh kelas induknya. Coba lihat contoh di bawah ini sob, biar lebih jelas.

Bisa dilihat pada contoh di atas, bahwa kita membuat class baru yaitu class VolumeCalculator yang meng-extend class AreaCalculator. coba kita lihat pada class SumCalculatorOutput di bawah ini.

Kemudian coba jalankan perintah kodenya.

 

Interface Segregation Principle

Many client-specific interfaces are better than one general-purpose interface.

Jadi interface yang lebih spesifik akan lebih bagus daripada interface yang bersifat general/umum, masih menggunakan contoh yang sebelumnya sob, kita coba buat interface baru ShapeInterface.

Untuk setiap class bangun yang akan dibuat harus mengimplementasi volume method, padahal sobat tahu persegi adalah bangun datar dan dia tidak ada unsur keruangannya sama sekali, tentunya ShapeInterface akan memaksa class Square untuk mengimplementasi method volume padahal kenyataannya itu tidak dibutuhkan.

Sesuai prinsip yang telah dijelaskan di atas, pembuatan interface yang bersifat general adalah tidak diperbolehkan, untuk itu sobat bisa membuat interface yang lebih spesifik, misal dengan nama SolidShapeInterface dengan maksud membuat interface untuk bangun ruang sehingga method volume bisa di letakkan di sana.

Untuk selanjutnya sobat bisa membuat satu interface lagi, misal ManageShapeInterface dan di implementasikan ke masing-masing class bangun datar maupun bangun ruang.

 

Dependency Inversion Principle

One should depend upon abstractions, [not] concretions.

Gampangnya sih kita membuat class yang mudah untuk di decouple atau dengan kata lain class yang tidak tergantung dengan class yang lainnya. Contoh di bawah ini akan memberikan penjelasan yang lebih konkrit sob.

Pada baris kode di atas sobat bisa amati bahwa MySQLConnection adalah low level module sedangkan PasswordChecker adalah high level module. Class PasswordChecker dipaksa untuk tergantung pada class MySQLConnection padahal hal ini menyalahi prinsip Dependency Inversion. Selai itu kode tersebut akan berpotensi menyalahi prinsip Open-Close, misal suatu saat nanti jika ada perubahan penggunaan database engine katakanlah dari MySQL ke PostgreSQL, perubahan kode mau tidak mau harus dilakukan, lantas apa yang bisa kita lakukan untuk memperbaiki dari kode di atas?

Seharusnya class PasswordChecker tidak perlu memperhatikan database apa yang sobat pakai, selanjutnya kita perbaiki strukturnya dengan menggunakan interface, karena high level module dan low level module harus bergantung pada abstraksi.

Kini sobat dapat melihat bahwa high level module dan low level module bergantung pada abstraksi.

 

Kesimpulan

Dengan memahami dan mengimplementasikan SOLID diharapkan kode-kode yang sobat tulis akan mudah untuk dirawat, dikembangkan dan dites. Jika dijadikan acuan dalam melakukan penulisan kode sehari-hari sobat akan merasakan kebaikannya.

Artikel ini disadur dari berbagai macam sumber. Jika sobat ada pertanyaan, sobat bisa tuliskan komentar di bawah ini, semoga tulisan ini dapat bermanfaat.

 

Happy Coding

 

Comments

Leave a Reply