Saya mencoba memahami perbedaan antara Open Closed Principle (OCP) dan Dependency Inversion Princible (DIP).
Berdasarkan penelitian yang saya buat di internet sejauh ini, saya sampai pada kesimpulan bahwa 'DIP adalah salah satu opsi yang melaluinya kita dapat mencapai OCP'.
Saya benar tentang ini?
Bisakah Anda memberi saya contoh yang tidak mengikuti DIP tetapi mengikuti OCP?
Saya menulis jawaban sebelumnya pada Prinsip Terbuka-Tertutup (OCP) vs Prinsip Pergantian Liskov (LSP) dan kedua prinsip itu banyak berhubungan satu sama lain, tetapi secara konsep masih berbeda dengan beberapa contoh yang dibuat-buat tentang memiliki satu tetapi tidak yang lain. Karena jawaban ini saya hanya akan menyentuh OCP sebentar dan melihat dua belas lebih dalam DIP dan apa yang membuat centang.
Mari kita coba membahas bagaimana OCP berhubungan dan berbeda dengan Dependency Inversion Principle (DIP) dengan terlebih dahulu menjelaskan prinsip-prinsip yang berbeda terlebih dahulu.
Membaca Prinsip OOD Paman Bob Anda akan menemukan bahwa DIP menyatakan sebagai berikut:
Bergantung pada abstraksi, bukan pada konkret.
Abstraksi di Jawa hanya dicapai dengan interfacedan abstractkata kunci, yang berarti Anda memiliki "kontrak" untuk beberapa entitas perangkat lunak yang harus diikuti oleh kode. Beberapa bahasa pemrograman tidak memiliki fasilitas untuk secara eksplisit mengatur perilaku untuk mengikuti kode sehingga abstraksi harus diikuti dengan cara yang lebih manual daripada memiliki kompiler membantu Anda menegakkan kontrak. Misalnya dalam C ++ Anda memiliki kelas dengan metode virtual, dan bahasa pemrograman dinamis seperti Javascript Anda harus memastikan Anda menggunakan objek dengan cara yang sama (meskipun dalam kasus Javascript ini telah diperluas dalam TypeScript yang menambahkan sistem tipe untuk membantu Anda keluar dengan kontrak tertulis yang diverifikasi oleh kompiler).
Nama ini mencakup istilah "inversi" karena secara tradisional (Anda tahu di zaman kegelapan pemrograman) Anda menulis struktur perangkat lunak yang memiliki modul tingkat lebih tinggi tergantung pada modul tingkat rendah. Misalnya masuk akal untuk memiliki ButtonAtKitcheninput penanganan untuk KitchenLamp1dan KitchenLamp2. Sayangnya itu membuat perangkat lunak jauh lebih spesifik daripada yang seharusnya dan objek grafik akan terlihat seperti ini:
Jadi ketika Anda membuat perangkat lunak lebih umum, dengan menambahkan "kontrak". Perhatikan bagaimana panah dalam grafik objek "membalikkan" arah. Lampu dapur itu sekarang tergantung pada a Button. Dengan kata lain detailnya sekarang tergantung pada abstraksi dan bukan sebaliknya.
Jadi kita memiliki definisi DIP yang lebih umum, juga dirinci dalam artikel asli DIP oleh Paman Bob .
A. Modul tingkat tinggi seharusnya tidak tergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi. B. Abstraksi tidak boleh tergantung pada detail. Rinciannya harus bergantung pada abstraksi.
Lanjutan dari prinsip-prinsip Paman Bob Anda akan menemukan bahwa OCP menyatakan sebagai berikut:
Anda harus dapat memperluas perilaku kelas, tanpa memodifikasinya.
Salah satu contoh untuk mencapai ini adalah dengan menggunakan pola Strategi di mana Contextkelas ditutup untuk modifikasi (yaitu Anda tidak dapat mengubah kode internal sama sekali) tetapi juga terbuka untuk ekstensi melalui dependensi yang berkolaborasi itu (yaitu kelas strategi).
Dalam pengertian yang lebih umum, setiap modul dibangun agar dapat diperluas melalui titik ekstensi.
Tidak , tidak juga.
Meskipun mereka berdua membahas abstraksi, mereka secara konsep berbeda. Kedua prinsip melihat konteks yang berbeda, OCP pada satu modul tertentu dan DIP pada beberapa modul. Anda dapat mencapai keduanya pada saat yang sama dengan sebagian besar pola desain Gang of Four, tetapi Anda masih bisa menjauhkan diri dari jalan setapak.
Dalam contoh DIP yang disebutkan di atas, dengan tombol dan lampu dapur, tidak ada lampu dapur yang dapat diperpanjang (atau saat ini tidak memiliki persyaratan yang menjelaskan apa yang diperlukan). Desain ini melanggar OCP tetapi mengikuti DIP .
Contoh sebaliknya (dan dibikin) akan menjadi lampu dapur dapat diperpanjang (dengan titik ekstensi menjadi seperti LampShade) tetapi tombol masih tergantung pada lampu . Itu melanggar DIP tetapi mengikuti OCP .
Ini sebenarnya sesuatu yang akan Anda lihat sering terjadi dalam kode produksi, yang sebagiannya mungkin melanggar prinsip. Dalam sistem perangkat lunak yang lebih besar (mis. Apa pun yang lebih besar dari contoh di atas), Anda mungkin melanggar satu prinsip tetapi menjaga yang lain biasanya karena Anda perlu menjaga kode sederhana. Ini, dalam pikiran saya, oke untuk modul kecil dan mandiri, karena mereka berada dalam konteks yang terkait dengan Prinsip Tanggung Jawab Tunggal (SRP).
Setelah beberapa modul menjadi rumit meskipun Anda kemungkinan besar perlu melihatnya dengan semua prinsip dalam pikiran dan mendesain ulang atau refactor ke beberapa pola yang terkenal.