Prinsip Ketergantungan Inversi: Bagaimana mendefinisikan "kebijakan tingkat tinggi" dan "detail tingkat rendah" untuk orang lain?

Saya mencoba menjelaskan prinsip inversi ketergantungan kepada kolega saya (kebanyakan junior). Bagaimana kita dapat mendefinisikan mana yang merupakan "kebijakan tingkat tinggi" dan mana yang merupakan "detail tingkat rendah" dalam suatu perangkat lunak? Misalnya, jika perangkat lunak kami mengotomatiskan alur kerja beberapa aplikasi bisnis, mengapa kami mengatakan bahwa otomatisasi alur kerja adalah kebijakan tingkat tinggi dan rincian aplikasi bisnisnya?

Catatan: ini telah sepenuhnya ditulis ulang dari contoh saya sebelumnya

Pikirkan tentang soket daya. Di negara mana pun, kebijakan tingkat tinggi adalah bahwa soket daya selalu sama. Tidak masalah dari mana Anda mendapatkan listrik (batubara, gas, nuklir), soket di dinding harus selalu mengeluarkan jumlah daya yang sama, melalui set konektor yang sama.

Sekarang Anda dapat menyambungkan perangkat apa pun ke soket itu, karena semuanya memiliki antarmuka umum, "colokan". Kebijakan tingkat tinggi tidak pernah harus mendikte bagian mana pun dari detail implementasi itu. Cukup tancapkan sesuatu dan itu berjalan.

Sekarang jika Anda memiliki perangkat yang tidak menginginkan daya AC - mungkin beroperasi pada sirkuit DC 7V - Anda masih dapat menggunakan kebijakan tingkat tinggi itu, Anda hanya perlu semacam adaptor antara catu daya dan perangkat. Dan, karena setiap orang memiliki kebijakan tingkat tinggi yang sama, pabrikan dapat memasukkannya ke dalam implementasi, tanpa mengubah kebijakan tingkat tinggi. Orang yang menghubungkan implementasi ke kebijakan (Anda, memasukkan laptop Anda) tidak benar-benar perlu memahami juga.

Lebih jauh, jika pabrikan ingin menjual perangkat yang sama di negara lain, yang harus mereka lakukan adalah mengembangkan adaptor yang berbeda. Jadi implementasi yang sama dapat bekerja dengan beberapa kebijakan, sementara kebijakan yang sama dapat menjalankan beberapa implementasi.

Ini adalah contoh sempurna dari inversi ketergantungan.

Tapi inilah bagian yang menarik: Kembalilah ke apa yang pertama kali saya katakan. "Tidak masalah dari mana kamu mendapatkan listrik." Ini juga merupakan detail implementasi. Kebijakan tingkat tinggi adalah bahwa semua soket daya memiliki bentuk yang sama dan memancarkan jenis daya yang sama. Detail implementasi tingkat rendah adalah dari mana listrik berasal dan dari mana ia beroperasi.

Dalam istilah pemrograman, itu berarti kebijakan tingkat tinggi adalah antarmuka (Di mana bahasa mendukungnya. Bentuk lain dari DI adalah mengetik-bebek.) Yang disediakan oleh API dan dikonsumsi oleh aplikasi, dan detail implementasi tingkat rendah keduanya adalah aplikasi memakannya dan API itu sendiri, yang keduanya tidak perlu saling memahami.

Adaptor dapat digunakan untuk menyesuaikan implementasi yang sama ke dalam kebijakan yang berbeda.

Pendekatan klasik dalam penggunaan ulang perangkat lunak adalah membangun komponen yang tidak bergantung pada apa pun (itulah yang membuatnya rendah), dan kemudian membangun komponen tingkat tinggi yang bergantung pada komponen tingkat rendah. "tingkat tinggi" dan "tingkat rendah" ditentukan secara spesifik oleh arah ketergantungan, yang tidak melekat pada fungsi komponen, tetapi seringkali hanya keputusan arsitektur.

Jadi, ketika aplikasi bisnis tunggal dibangun tanpa ketergantungan pada otomatisasi alur kerja, tetapi pengontrol alur kerja Anda memiliki ketergantungan langsung ke aplikasi bisnis, maka harus jelas bahwa otomatisasi alur kerja adalah "kebijakan tingkat tinggi" dan aplikasi bisnis adalah komponen "tingkat rendah". Perhatikan bahwa struktur ini tidak wajib - jika komponen otomasi alur kerja Anda adalah kerangka umum, yang tidak digabungkan dengan aplikasi bisnis khusus Anda, tetapi dapat dikonfigurasi untuk melayani aplikasi yang berbeda, maka Anda sudah mulai menerapkan DIP. Dalam situasi ini, pemisahan "tingkat tinggi" / "tingkat rendah" mungkin tidak masuk akal di antara kedua hal itu lagi.

Jadi, nama "dependensi inversi" agak menyesatkan - karena dependensi tidak "terbalik", tetapi dihapus sepenuhnya (atau lebih tepatnya: diubah dari menjadi dependensi waktu kompilasi menjadi dependensi run time).

Saya menggunakan gambar sederhana untuk menjelaskan DIP. Pandangan klasik pengembangan perangkat lunak adalah sebagai proses konstruksi dengan setiap lapisan berada di atas lapisan bawah yang mendukungnya. Menggunakan Prinsip inversi Ketergantungan lebih seperti membangun ponsel.

Alih-alih lapisan yang lebih tinggi berada di lapisan bawah, lapisan yang lebih tinggi di antarmuka seluler dengan lapisan bawah melalui string yang menghubungkannya. Di satu sisi, lapisan bawah tergantung pada antarmuka untuk dukungan (tanpa tali mereka akan jatuh). Singkatnya, DIP.