Bagaimana cara meningkatkan ketergantungan injeksi?


32

Pada halaman Wikipedia tentang injeksi ketergantungan, bagian kerugian memberitahu kita ini:

Ketergantungan injeksi meningkatkan kopling dengan mengharuskan pengguna subsistem untuk menyediakan kebutuhan subsistem itu.

dengan tautan ke artikel yang menentang injeksi ketergantungan .

Ketergantungan injeksi membuat kelas menggunakan antarmuka bukan implementasi konkret. Itu akan menghasilkan penurunan kopling , bukan?

Apa yang saya lewatkan? Bagaimana peningkatan ketergantungan injeksi kopling antar kelas?


2
Saya tidak yakin siapa yang menulis daftar kerugian itu, tetapi saya akan mengambilnya dengan sebutir garam. Sebagai contoh, saya telah melihat DI mengurangi ukuran basis kode sebanyak 2/3 dengan menghilangkan satu ton kode pengaturan yang berlebihan.
Rob

@RobY Saya kebanyakan menggunakan pabrik untuk menyuntikkan dependensi, dan pengalaman saya adalah meningkatkan ukuran kode, tetapi menyederhanakan pengujian.
BЈовић

Coba gunakan alternatif seperti Registry atau Context Passing;) Atau kode lain yang hanya instantiate objek dan kemudian tarik propertinya dari konfigurasi. Terutama, saya berbicara tentang perbedaan antara sekarang dan 15 tahun yang lalu.
Rob

Terkait: stackoverflow.com/a/9503612/264697 . Jawaban Mark Seemann menjelaskan bagaimana kopling keseluruhan dikurangi menggunakan Dependency Injection.
Steven

Jawaban:


42

Jadi, apa yang saya lewatkan?

Dependency Injection mengurangi sambungan antara kelas dan ketergantungannya. Tapi itu meningkatkan sambungan antara kelas dan penggunanya (karena konsumen membutuhkan lebih banyak info untuk membuatnya) dan ketergantungan dan penggunannya (karena konsumen perlu mengetahui ketergantungan untuk digunakan).

Sangat sering, ini merupakan trade off yang baik. Kelas seharusnya tidak mengetahui detail tentang dependensinya di luar antarmuka, dan itu harus menjadi tanggung jawab aplikasi untuk mengikat bit kode tertentu bersama-sama.


Benar, kopling menurun satu arah dan meningkat lagi.
Paul Draper

Tetapi konsumen tidak menciptakannya; itu intinya.
Casey

@emodendroket - Eh? Inversion of Control memungkinkan konsumen untuk tidak membuatnya. Ketergantungan Injeksi adalah ortogonal untuk itu.
Telastyn

Ya, Anda membuat perbedaan yang tidak saya kenal, karena biasanya istilah tersebut digunakan secara bergantian.
Casey

22

Misalkan Anda memiliki subsistem Syang bergantung pada koneksi basis data D. Tanpa injeksi ketergantungan, ada sambungan yang relatif ketat antara Sdan D, karena Sperlu tahu cara menggunakan Ddan cara membuatnya. Sisa dari sistem, bagaimanapun, bisa sangat tidak menyadari ketergantungan antara Sdan D.

Dengan injeksi ketergantungan, kopling antara Sdan Dmenjadi lebih longgar, karena Anda menghapus dari Spengetahuan cara membuat D. Shanya perlu tahu cara menggunakannya. Peningkatan keseluruhan kopling berasal dari kenyataan bahwa bagian lain dari sistem sekarang perlu tahu tentang Ddan mungkin cara membuatnya. Tingkat kenaikan kopling ini tergantung pada bagaimana ketergantungan pada Ddisuntikkan ke S:

  • Dengan injeksi konstruktor pencipta Skebutuhan bergantung pada Ddan mungkin pengetahuan cara membuatnya.
  • Dengan injeksi tingkat metode , setiap pemanggil metode Syang Dakan disuntikkan memerlukan ketergantungan Ddan mungkin pengetahuan cara membuatnya.

Dalam kedua kasus, jumlah kelas yang tergantung pada Dpeningkatan dan pengetahuan cara membuat Dmasih perlu hadir di suatu tempat dalam sistem. Ini menciptakan peningkatan kopling secara keseluruhan.


Ok, masuk akal untuk konstruktor dan injeksi setter. Tetapi jika seseorang menggunakan pola pabrik atau strategi, ciptaan dipindahkan ke sana, dan kelas hanya menggunakan objek yang disuntikkan. Atau, bukankah itu injeksi ketergantungan (hanya inversi kontrol)?
BЈовић

Bahkan dengan injeksi pabrik, pembuat Skebutuhan untuk memasok pabrik D, yang berarti perlu mengetahui Spenggunaan itu D(atau setidaknya beberapa antarmuka itu).
Idan Arye

7

Saya sangat tidak setuju bahwa itu meningkatkan kopling.

Tanpa injeksi ketergantungan Anda memiliki kopling ketat antara sub sistem dan implementasi dependensi yang konkret.

Dengan injeksi dependensi Anda telah memisahkan sub sistem dari implementasi dependensi.

Membuat argumen bahwa itu meningkatkan kopling antara konsumen dan sub sistem ini SANGAT dipertanyakan karena menyiratkan bahwa konsumen sekarang sangat erat dengan ketergantungan yang diperlukan oleh sub sistem. Maksudnya adalah Anda menulis kode yang dipasangkan dengan ketat yang menyatukan konsumen Anda dengan ketergantungan. Idealnya SEMUA kode Anda dipisahkan.

Injeksi Konstruktor:

Resolusi ketergantungan ditangani oleh wadah injeksi ketergantungan atau pabrik. Konsumen bisa mendapatkan implementasi nyata dari sistem sub dari wadah injeksi ketergantungan atau pabrik.

Konsumen tidak perlu tahu seperti apa konstruktor dari sub sistem itu. Tidak ada sambungan ke ketergantungan sub sistem.

Metode Injeksi:

Sama seperti injeksi konstruktor kecuali bahwa sekarang konsumen perlu mendapatkan contoh nyata ketergantungan dari wadah atau pabrik (atau bahkan menyuntikkan metode / konstruktor) dan menyuntikkannya ke dalam metode. Sekali lagi, konsumen tidak digabungkan dengan implementasi konkret dari ketergantungan.

TL; DR Kasus terburuk untuk injeksi ketergantungan dalam sub sistem adalah bahwa kopling dialihkan ke kode konsumen. TIDAK ADA PENINGKATAN SECARA KESELURUHAN DALAM COUPLING.

Kasus terbaik adalah bahwa semua sistem sekarang longgar digabungkan dan injeksi ketergantungan dikontrol melalui wadah atau pabrik injeksi ketergantungan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.