Mengapa pola injeksi ketergantungan tidak termasuk dalam Geng empat?

Mengapa pola injeksi ketergantungan tidak dimasukkan dalam geng empat ? Apakah GOF melakukan pre-date pengujian otomatis luas? Apakah injeksi ketergantungan sekarang dianggap sebagai pola inti?

Saya adalah editor majalah Pengembangan Perangkat Lunak ketika buku Gang of Four keluar dan saya dapat mengatakan dengan penuh keyakinan bahwa pengujian unit bukanlah praktik yang meluas pada tahun 1994, ketika Pola Desain awalnya diterbitkan.

Pada tahun 1994, C ++ adalah bahasa berorientasi objek yang paling umum digunakan, dan kebanyakan orang memprogramnya berasal dari latar belakang C. Salah satu hal "berpikir dalam benda" yang tidak dimiliki orang adalah gagasan ratusan atau ribuan titik masuk ke dalam program Anda. Anda memikirkan tentang main(). Jika Anda bekerja pada proyek besar, Anda mungkin memiliki makefile (biasanya cukup rumit) untuk membuat program berbasis modul. Tapi "unit-testing"? Memulai proses, membangun konteks memori yang diperlukan, menjalankannya, dan menghancurkannya, berdasarkan metode ? Itu sangat radikal.

Java membuat pemrograman multi-entry-point lebih jelas. Pada saat booming Dot-Com asli, pengujian unit adalah teknik yang terkenal, tetapi itu benar-benar JUnit (sekitar tahun 2001?) Yang menyebabkannya terbakar dan menjadi praktik universal.

Meskipun Strategi dan konsep umum pemrograman ke antarmuka adalah bagian dari GoF dan zeitgeist pertengahan 90-an, gagasan injeksi datang cukup terlambat ke pesta (sekitar tahun '03 -'05?). Jujur, rambut uban saya masih cukup meragukan tentang aspek DI ("Lepaskan halaman saya, Anda sialan file konfigurasi!").

Mereka menyebutnya Strategi .

Strategi mereka tampaknya memiliki semua fitur injeksi ketergantungan tanpa nama yang terdengar rumit.

Saya pikir Ketergantungan Injeksi lebih relevan ketika memisahkan implementasi di tingkatan. Area lain di mana kami berpikir tentang injeksi ketergantungan adalah pengujian unit. Dan saran pra-tanggal Anda tampaknya benar. Jika geng itu mengumpulkan dan memisahkan pola pada 2012, pasti injeksi ketergantungan akan ada di sana.

Strategi dapat muncul dalam diskusi tetapi Strategi tidak berbicara tentang suntikan ketergantungan. Tetapi ketika menggunakan pola strategi dalam satu proyek atau dll (semua kelas dan antarmuka tetap dalam satu proyek) tampaknya kita melakukan injeksi dependensi. Sebenarnya kita tidak.

Sekarang, jika kelas dan antarmuka yang disebutkan dalam pola strategi dipisahkan dalam proyek atau tingkatan yang berbeda maka KAMI harus menggunakan teknik injeksi ketergantungan. Kita dapat menggunakan file konfigurasi kesatuan (meskipun tidak ada perubahan runtime yang mungkin terjadi). Tetapi pola Strategi tidak mengatakan bagaimana menyuntikkan ketergantungan.

Jika ada pola yang sangat mirip dengan injeksi Ketergantungan maka itu adalah pola Metode Pabrik Abstrak. Pola ini dapat digunakan di dalam pola strategi untuk menyuntikkan ketergantungan.

jawabannya adalah Strategi 100% benar. Saya memilih itu tetapi bisa berkomentar.

"Strategi memungkinkan algoritma bervariasi secara independen dari klien yang menggunakannya. [1] Strategi adalah salah satu pola yang termasuk dalam buku Pola Desain berpengaruh oleh Gamma et al. Yang mempopulerkan konsep menggunakan pola untuk menggambarkan desain perangkat lunak."

Pola desain tidak tergantung pada penggunaannya. Injeksi Ketergantungan diimplementasikan dengan menggunakan pola Strategi. Jika kita menamai setiap pola berdasarkan use case kita harus mengganti nama banyak pola.

Pola repositori bukan pola baru, itu adalah Pola Templat.

"Dalam metode templat pola desain ini, satu atau beberapa langkah algoritma dapat ditimpa oleh subclass untuk memungkinkan perilaku yang berbeda sambil memastikan bahwa algoritma menyeluruh masih diikuti."

Seringkali polanya adalah beberapa pola yang digabungkan dan dinamai seperti pola MVC.

GOF tidak memiliki antarmuka kelas Abstrak Murni yang digunakan, dan juga memanfaatkan kemampuan C ++ untuk mewarisi dari lebih dari satu kelas.