Bagaimana Inversi Kontrol terkait dengan Ketergantungan Inversi

Dalam banyak artikel di seluruh web, istilah Inversi Kontrol dan Ketergantungan Prinsip Inversi tampaknya digabungkan dan digunakan sebagai sinonim (kebingungan lebih lanjut ditegakkan oleh alat yang disebut "DI-Containers" dan "IoC-Containers"). Artikel Wikipedia melakukan pekerjaan yang bagus untuk menjelaskan bahwa IoC tidak sama dengan DI:

inversion of control (IoC) menjelaskan desain di mana bagian-bagian program komputer yang ditulis khusus menerima aliran kontrol dari pustaka generik yang dapat digunakan kembali

Jadi DIP adalah tentang memiliki modul Anda bergantung pada abstraksi daripada implementasi konkret.

Dan IoC adalah tentang memberikan kontrol atas aliran program Anda ke modul terpisah. Dan salah satu hal yang dapat Anda lakukan dengan modul ini adalah menyelesaikan dependensi saat runtime.

Perbedaan ini memang tampak adil, tetapi saya belum pernah melihat orang yang menyebutkan aplikasi lain dari prinsip IoC selain penyelesaian ketergantungan. Definisi Wikipedia cukup luas, dan sepertinya Anda dapat melakukan lebih banyak hal dengan modul yang dapat membuat panggilan ke kode kustom Anda berdasarkan konfigurasi dan beberapa logika internal.

Jadi, inilah beberapa pertanyaan yang belum bisa saya pahami:

Apa hubungan aktual antara IoC dan DIP? Apakah IoC selalu berfungsi sebagai sarana untuk mengimplementasikan DIP?
Mengapa alat untuk penyelesaian ketergantungan disebut kontainer DI- dan IoC? Ini menyiratkan bahwa DI dan IoC adalah hal yang sama.

Catatan : Pertanyaan ini bukan duplikat dari Apa perbedaan antara DI dan IoC , karena yang terakhir menanyakan tentang Dependency Injection, bukan Dependency Inversion.

design-patterns inversion-of-control dependency-inversion

— Andre Borges
sumber

Kemungkinan duplikat Apa perbedaan antara DI dan IoC?

— nyamuk

@gnat, tidak bukan, silakan lihat hasil edit saya

— Andre Borges

setuju, saya melewatkan maaf itu

— nyamuk

IMO, jawaban sederhananya adalah "mereka sama". IoC adalah nama lain untuk inversi dependensi dan keduanya adalah cara untuk mencapai injeksi dependensi. Saya melihat "inversi ketergantungan" sebagai istilah yang sangat tidak membantu karena terlalu mudah dikacaukan dengan injeksi. Jadi ada DI (injeksi) dan IoC adalah cara untuk mencapai inversi dependensi / kontrol melalui injeksi.

— David Arno

Ada artikel bagus di situs Martin Fowler yang memiliki bab khusus tentang perbedaan antara DIP, DI dan IoC . Intinya (sebagaimana disalin dari situs itu) adalah

DI adalah tentang bagaimana satu objek memperoleh ketergantungan. Ketika ketergantungan diberikan secara eksternal, maka sistem menggunakan DI. IoC adalah tentang siapa yang memulai panggilan. Jika kode Anda memulai panggilan, itu bukan IoC, jika wadah / sistem / perpustakaan memanggil kembali ke kode yang Anda berikan, apakah itu IoC.

DIP, di sisi lain, adalah tentang tingkat abstraksi dalam pesan yang dikirim dari kode Anda ke hal yang dipanggil. Yang pasti, menggunakan DI atau IoC dengan DIP cenderung lebih ekspresif, kuat dan selaras domain, tetapi mereka tentang dimensi yang berbeda, atau kekuatan, dalam masalah keseluruhan. DI adalah tentang kabel, IoC adalah tentang arah, dan DIP adalah tentang bentuk.

— JDT
sumber

IoC adalah tentang siapa yang memulai panggilan - siapa yang melakukan panggilan untuk apa? Jika saya menulis ISomeInterface object = container.Resolve<ISomeInterface>()apakah itu IOC atau tidak?

— Andre Borges

Apa yang Anda tulis adalah implementasi dalam pola locater layanan. Ini juga IOC. Bukan IoC adalah ISomeInterface objek = MyClass baru (). Jadi panggilan yang dimaksud adalah "panggilan untuk instantiation" (atau yang menyebut 'baru').

— Sjoerd222888

"DIP, di sisi lain, adalah tentang tingkat abstraksi dalam pesan yang dikirim dari kode Anda ke hal yang dipanggil." Kedengarannya seperti omong kosong bagi saya. Di mana inversi itu? Dia menggambarkan abstraksi ketergantungan, bukan inversi.

— David Arno

@ Davidvid, apakah Anda mengatakan kami tidak bisa mempercayai situs web Martin Fowler?

— holdenmcgrohen

@ holdenmcgrohen, ini pendapatnya tentang banyak hal. Hanya karena itu Martin Fowler, tidak menjadikannya fakta. Kadang-kadang dia salah IMO, misalnya tentang "model data anemia". Di lain waktu, dia sangat berwawasan luas. Pada kesempatan ini saya pikir dia salah juga karena itu tidak masuk akal.

— David Arno