SOLID Prinsip Melalui Contoh: 5. Dependency Inversion Principle (DIP)

Jika Anda belum melakukannya, lihat artikel saya sebelumnya tentang Prinsip Segregasi Antarmuka

Prinsip inversi ketergantungan mempromosikan dua tujuan,

1. Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi.
2. Abstraksi seharusnya tidak bergantung pada detail. Detail harus bergantung pada abstraksi

Mari kita pahami pernyataan pertama melalui sebuah contoh:

Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi.

Ambil contoh contoh sistem pemrosesan pembayaran.

Ada startup baru yang saat ini mendukung pembayaran untuk produknya hanya melalui kartu debit jenis VISA, nah persyaratan ini dapat dipenuhi dengan kode di bawah ini,

tetapi ini melanggar DIP karena DebitCardPaymentProcessor kelas tingkat tinggi Anda secara langsung bergantung pada kelas rendah VisaDebitCardPaymentService untuk menggunakan metode pay() . Saat ini, sistem hanya mendukung pembayaran kartu debit VISA sehingga kode berfungsi dengan baik, tetapi

Bagaimana jika Anda ingin mendukung pembayaran kartu debit MASTER ke depannya?

Anda akan memerlukan perubahan dalam kelas DebitCardPaymentProcessor dengan beberapa pernyataan if-else atau switch , sehingga tidak terbuka untuk ekstensi.

Dan selangkah lebih maju Anda juga ingin mendukung pembayaran kartu kredit dan UPI?

Sekarang Anda juga memerlukan perubahan di kelas yang menggunakan DebitCardPaymentProcessor.

Ini jelas melanggar DIP dan Open Closed Principle (OCP).

Mari kita lihat solusinya,

Gunakan abstraksi untuk modul tingkat tinggi dan modul tingkat rendah dan biarkan interaksi terjadi melalui polimorfisme dinamis.

Sekarang, salah satu PaymentService dapat disuntikkan secara dinamis ke dalam PaymentProcessor, yaitu kebalikan dari ketergantungan. Itu dapat dicapai baik melalui injeksi dependensi konstruktor atau setter.

Sekarang mari kita lihat pernyataan kedua,

Abstraksi seharusnya tidak bergantung pada detail. Detail harus bergantung pada abstraksi.

Di sini, PaymentProcessor abstraksi tidak bergantung pada detail seperti CreditCardPaymentProcessor , melainkan CreditCardPaymentProcessor bergantung pada PaymentProcessor untuk mengetahui metode mana yang diterapkan sehingga detail bergantung pada abstraksi dan BUKAN sebaliknya.

Begitu sedikit poin yang perlu dipertimbangkan,

1. Tidak ada variabel yang boleh menyimpan penunjuk atau referensi ke kelas konkret.
2. Tidak ada kelas yang harus diturunkan dari kelas konkret.
3. Tidak ada metode yang boleh mengesampingkan metode yang diimplementasikan dari salah satu kelas dasarnya.

Itu menyimpulkan artikel prinsip SOLID. Periksa orang lain jika Anda belum melakukannya.

Terima kasih.