Apakah injeksi ketergantungan dengan tangan merupakan alternatif yang lebih baik untuk komposisi dan polimorfisme?

Pertama, saya seorang programmer tingkat pemula; Bahkan, saya menyelesaikan gelar AS dengan proyek batu penjuru akhir selama musim panas. Dalam pekerjaan baru saya, ketika tidak ada proyek yang harus saya kerjakan (mereka sedang menunggu untuk mengisi tim dengan lebih banyak karyawan baru), saya telah diberikan buku untuk dibaca dan dipelajari dari saat saya menunggu - beberapa buku teks, yang lain tidak begitu banyak (seperti Code Complete). Setelah membaca buku-buku ini, saya beralih ke internet untuk belajar sebanyak mungkin, dan mulai belajar tentang SOLID dan DI (kami berbicara beberapa tentang prinsip substitusi Liskov, tetapi tidak banyak lagi ide SOLID). Jadi seperti yang telah saya pelajari, saya duduk untuk belajar lebih baik, dan mulai menulis beberapa kode untuk memanfaatkan DI dengan tangan (tidak ada kerangka kerja DI pada pengembangan komputer).

Masalahnya adalah, ketika saya melakukannya, saya perhatikan rasanya akrab ... dan sepertinya itu sangat mirip dengan pekerjaan yang saya lakukan di masa lalu menggunakan komposisi kelas abstrak menggunakan polimorfisme. Apakah saya melewatkan gambar yang lebih besar di sini? Apakah ada sesuatu tentang DI (setidaknya dengan tangan) yang melampaui itu? Saya memahami kemungkinan memiliki konfigurasi bukan dalam kode beberapa kerangka kerja DI yang memiliki manfaat besar sejauh mengubah hal-hal tanpa harus mengkompilasi ulang, tetapi ketika melakukannya dengan tangan, saya tidak yakin apakah itu berbeda dari yang disebutkan di atas ... Beberapa wawasan tentang ini akan sangat membantu!

Ide mendasar dalam DI adalah hanya untuk mendorong dependensi ke objek, daripada membiarkannya menarik dependensi dari luar. Ini juga disebut "inversi kontrol" sebelumnya. Ini memungkinkan seseorang untuk mengontrol dependensi jauh lebih baik, dan - terakhir tapi tidak kalah penting - untuk menulis kode yang mudah untuk unit test.

Kerangka kerja DI hanya membangun di atas ide ini, dan (sebagian) mengotomatiskan bagian yang sering membosankan dari ketergantungan objek kabel bersama-sama. Ini mungkin memerlukan sejumlah besar kode dalam proyek yang lebih besar bila dilakukan dengan tangan.

Untuk mendefinisikan dependensi, selain dari file konfigurasi eksternal, dimungkinkan juga untuk menggunakan anotasi kode saat ini, misalnya dalam bahasa seperti Java dan C #. Ini mungkin membawa yang terbaik dari kedua dunia: ketergantungan kabel dalam gaya deklaratif, tetapi tepat di dalam kode itu sendiri, di mana ia secara logis milik. Bagi saya, kemungkinan mengubah dependensi tanpa harus mengkompilasi ulang tidak begitu berharga, karena jarang dilakukan dalam kehidupan nyata (terlepas dari beberapa kasus khusus), tetapi memperkenalkan pemisahan dependensi yang sering secara artifis dari kelas dan objek yang didefinisikan dalam kode. .

Untuk kembali ke pertanyaan judul Anda, DI bukan merupakan alternatif untuk komposisi atau polimorfisme; setelah semua, ini dimungkinkan oleh keduanya.

Artikel terbaik yang pernah saya baca tentang topik ini adalah artikel James Shore . Saya telah melakukan " DI dengan Tangan " selama berabad-abad, sebagai bagian dari abstraksi dan polimorfisme. Jadi setelah saya masuk ke dunia profesional dan saya terus mendengar istilah itu dilontarkan, saya memiliki keterputusan yang besar antara apa yang saya pikir arti kata itu dan apa arti sebenarnya:

"Injeksi Ketergantungan" adalah istilah 25 dolar untuk konsep 5 sen.

Itu dari pos Shore, yang membereskan semuanya untukku. Sebagai contoh:

Diberikan

class Engine {public abstract void start()}
class V8 extends Engine {...}
class V6 extends Engine {...}

Alih-alih menulis:

class Car
{
    private Engine engine;
    public Car()
    {
        this.engine = new V6();
    }

    public void start()
    {
        this.engine.start();
    }
}

Anda menulis sesuatu seperti ini:

class Car
{
    private Engine engine;
    public Car(Engine a)
    {
        this.engine = a;
    }

    public void start()
    {
        this.engine.start();
    }
}

...

Car F = new Car(new V8());

Dan ini mencegah Carinstance dari harus menangani Enginedetail spesifik . Mobil hanya membutuhkan mesin, tidak peduli yang mana asalkan menerapkan fungsionalitas Mesin dasar. Artinya, Carkelas Anda tidak terikat dengan ketergantungan implementasi spesifik; itu "disuntikkan" di tempat lain, berpotensi saat runtime.

Contoh Mobil khusus ini menggunakan sub-jenis DI yang disebut "Injeksi Konstruktor", yang berarti bahwa ketergantungan diserahkan sebagai argumen konstruktor. Anda juga dapat menggunakan setEngine(Engine a)metode untuk "Setter Injection", dan sebagainya, tetapi sub-tipe ini sepertinya terlalu bagus untuk saya.

Namun, sedikit lebih jauh, banyak kerangka kerja DI menyediakan pelat untuk menghubungkan banyak hal yang lebih dirujuk secara abstrak satu sama lain.

Itu dia.

Saya bukan ahli karena saya baru mulai menggunakan DI dalam beberapa tahun terakhir, tetapi beberapa tema / fungsi berguna dari wadah DI yang saya perhatikan adalah (yang saya tidak menganggapnya sebagai produk komposisi / polimorfisme (tapi saya mungkin akan dikoreksi atas hal itu):

• pusat penciptaan objek
• menyediakan lajang berdasarkan per utas
• teknik berorientasi aspek seperti intersepsi

Terlepas dari DI, ada konfigurasi komposisi kelas di aplikasi root (bukannya mengkonfigurasi menggunakan xml). Tidak perlu untuk kerangka DI atau IoC, meskipun mereka dapat merapikan konfigurasi komposisi kelas, terutama untuk proyek-proyek besar. Ini karena kerangka kerja DI biasanya datang dengan wadah yang menerapkan fitur tambahan, seperti pengkabelan otomatis, yang membantu mengonfigurasi komposisi kelas. Anda dapat membaca entri blog saya untuk mengekstrak pemahaman saya tentang topik ini.