Pertama, saya ingin memisahkan pendekatan desain dari konsep kerangka kerja. Injeksi ketergantungan pada level paling sederhana dan paling mendasar hanyalah:
Objek induk menyediakan semua dependensi yang diperlukan untuk objek anak.
Itu dia. Perhatikan, bahwa tidak ada yang memerlukan antarmuka, kerangka kerja, gaya injeksi apa pun, dll. Agar adil, saya pertama kali mempelajari tentang pola ini 20 tahun yang lalu. Itu bukan hal baru.
Karena lebih dari 2 orang memiliki kebingungan atas istilah orang tua dan anak, dalam konteks injeksi ketergantungan:
- The orangtua adalah objek yang instantiates dan mengkonfigurasi objek anak menggunakan
- The anak adalah komponen yang dirancang untuk secara pasif dipakai. Yaitu itu dirancang untuk menggunakan dependensi apa pun yang disediakan oleh orang tua, dan tidak instantiate dependensi itu sendiri.
Ketergantungan injeksi adalah pola untuk komposisi objek .
Mengapa antarmuka?
Antarmuka adalah kontrak. Mereka ada untuk membatasi seberapa erat dua objek dapat digabungkan. Tidak setiap ketergantungan memerlukan antarmuka, tetapi mereka membantu dengan menulis kode modular.
Saat Anda menambahkan dalam konsep pengujian unit, Anda mungkin memiliki dua implementasi konseptual untuk antarmuka tertentu: objek nyata yang ingin Anda gunakan dalam aplikasi Anda, dan objek tiruan atau stubbed yang Anda gunakan untuk menguji kode yang bergantung pada objek. Itu saja bisa menjadi pembenaran yang cukup untuk antarmuka.
Mengapa kerangka kerja
Inisialisasi menginisialisasi dan menyediakan dependensi ke objek anak dapat menakutkan ketika ada banyak dari mereka. Kerangka memberikan manfaat berikut:
- Ketergantungan otomatis untuk komponen
- Mengkonfigurasi komponen dengan pengaturan
- Mengotomatiskan kode pelat ketel agar Anda tidak harus melihatnya ditulis di beberapa lokasi.
Mereka juga memiliki kelemahan berikut:
- Objek induk adalah "wadah", dan bukan apa pun dalam kode Anda
- Itu membuat pengujian lebih rumit jika Anda tidak dapat memberikan dependensi secara langsung dalam kode pengujian Anda
- Ini dapat memperlambat inisialisasi karena menyelesaikan semua dependensi menggunakan refleksi dan banyak trik lainnya
- Debugging Runtime bisa lebih sulit, terutama jika wadah menyuntikkan proxy antara antarmuka dan komponen aktual yang mengimplementasikan antarmuka (pemrograman berorientasi aspek yang dibangun ke Spring muncul dalam pikiran). Kontainer adalah kotak hitam, dan mereka tidak selalu dibangun dengan konsep apa pun yang memfasilitasi proses debugging.
Semua yang mengatakan, ada trade-off. Untuk proyek kecil di mana tidak ada banyak bagian yang bergerak, dan ada sedikit alasan untuk menggunakan kerangka kerja DI. Namun, untuk proyek yang lebih rumit di mana ada komponen tertentu yang sudah dibuat untuk Anda, kerangka kerjanya dapat dibenarkan.
Bagaimana dengan [artikel acak di Internet]?
Bagaimana dengan itu? Sering kali orang bisa terlalu bersemangat dan menambahkan banyak batasan dan mencaci maki Anda jika Anda tidak melakukan hal-hal dengan "satu cara yang benar". Tidak ada satu cara yang benar. Lihat apakah Anda dapat mengekstraksi sesuatu yang bermanfaat dari artikel dan mengabaikan hal-hal yang tidak Anda setujui.
Singkatnya, pikirkan sendiri dan cobalah.
Bekerja dengan "kepala lama"
Belajar sebanyak mungkin. Apa yang akan Anda temukan dengan banyak pengembang yang memasuki usia 70-an adalah bahwa mereka telah belajar untuk tidak bersikap dogmatis tentang banyak hal. Mereka memiliki metode yang telah mereka gunakan selama beberapa dekade yang menghasilkan hasil yang benar.
Saya memiliki hak istimewa untuk bekerja dengan beberapa di antaranya, dan mereka dapat memberikan umpan balik yang sangat jujur dan masuk akal. Dan di mana mereka melihat nilai, mereka menambahkan alat-alat itu ke daftar lagu mereka.