Berapa Banyak Prinsip dalam Desain Pola
Categories:
Awalnya, hanya ada 5 prinsip desain pola yang dirangkum, yaitu SOLID:
Prinsip Tanggung Jawab Tunggal (Single Responsibility Principle, SRP): Sebuah kelas seharusnya hanya memiliki satu alasan untuk berubah, artinya sebuah kelas hanya boleh memiliki satu tanggung jawab.Prinsip Buka/Tutup (Open/Closed Principle, OCP): Entitas perangkat lunak (kelas, modul, fungsi, dll) harus terbuka terhadap ekstensi namun tertutup terhadap modifikasi. Artinya, perubahan harus dicapai melalui ekstensi, bukan dengan memodifikasi kode yang sudah ada.Prinsip Substitusi Liskov (Liskov Substitution Principle, LSP): Subtipe harus mampu menggantikan tipe dasarnya. Artinya, kelas turunan harus mampu menggantikan kelas induknya tanpa memengaruhi kebenaran program.Prinsip Pemisahan Antarmuka (Interface Segregation Principle, ISP): Klien tidak boleh dipaksa bergantung pada antarmuka yang tidak mereka gunakan. Antarmuka besar harus dipecah menjadi antarmuka yang lebih kecil dan lebih spesifik, sehingga klien hanya perlu mengetahui metode yang mereka butuhkan.Prinsip Inversi Ketergantungan (Dependency Inversion Principle, DIP): Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah; keduanya harus bergantung pada abstraksi. Abstraksi tidak boleh bergantung pada detail implementasi, tetapi detail implementasi harus bergantung pada abstraksi.
Kemudian, dua aturan ditambahkan. Aturan tambahan ini lebih konkret dan lebih terarah dibandingkan yang sebelumnya. Dari penjelasan prinsip, kita dapat melihat bahwa SOLID menggambarkan “apa yang harus dilakukan”, sedangkan aturan tambahan menggambarkan “apa yang sebaiknya dilakukan”.
Prinsip Pemanfaatan Ulang Komposisi/Aggregasi (Composition/Aggregation Reuse Principle, CARP): Sebaiknya memprioritaskan penggunaan komposisi objek dan agregasi daripada pewarisan untuk mencapai tujuan pemanfaatan ulang kode.Hukum Demeter (Law of Demeter, LoD): Sebuah objek harus memiliki pengetahuan sesedikit mungkin tentang objek lain, artinya sebuah objek seharusnya mengetahui struktur internal dan detail implementasi objek lain sekecil mungkin.
Selain prinsip desain yang disebutkan di atas, ada beberapa prinsip desain lainnya yang meskipun tidak sepopuler yang disebutkan sebelumnya, tetap memberikan panduan penting bagi desain dan arsitektur perangkat lunak. Aturan-aturan yang diusulkan belakangan ini agak seperti menggambar ular lalu menambahkan kaki; setidaknya menurut saya, mereka tidak kontra-intuitif dan tidak memerlukan pemikiran mendalam.
Prinsip Pengetahuan Minimal (Principle of Least Knowledge, PoLK): Juga dikenal sebagai perluasan dari Hukum Demeter, menyatakan bahwa sebuah objek seharusnya mengetahui informasi tentang objek lain sesedikit mungkin. Prinsip ini berasal dari “Hukum Komunikasi Minimal” yang diajukan oleh Patricia Lago dan Koos Visser pada tahun 1987.Prinsip Ketergantungan Stabil (Stable Dependencies Principle, SDP): Prinsip ini menyatakan bahwa desain perangkat lunak harus memastikan bahwa komponen stabil tidak bergantung pada komponen tidak stabil, artinya komponen dengan stabilitas tinggi seharusnya lebih sedikit bergantung pada komponen dengan stabilitas rendah. Pemikiran prinsip ini berasal dari penelitian mendalam mengenai hubungan antar komponen dalam sistem perangkat lunak.Prinsip Abstraksi Stabil (Stable Abstraction Principle, SAP): Sejalan dengan Prinsip Ketergantungan Stabil, prinsip ini memandu keselarasan antara abstraksi dan stabilitas, yaitu komponen stabil harus bersifat abstrak, sedangkan komponen tidak stabil harus bersifat konkret. Prinsip ini membantu memastikan stabilitas dan fleksibilitas sistem perangkat lunak.