Apakah game ritel menggunakan "inversi kontrol" dan "injeksi ketergantungan"?

Banyak pengembang perangkat lunak yang lebih rajin yang saya tahu bergerak ke inversi kontrol dan injeksi ketergantungan untuk menangani referensi ke objek. Berasal dari perspektif Flash games, saya tidak tahu semua seluk beluk studio AAA, jadi: apakah ini digunakan di dunia game ritel?

Anda menyebutnya 'pengembangan perangkat lunak yang rajin', saya menyebutnya 'overengineering yang menyakitkan'. Itu bukan untuk mengatakan bahwa inversi kontrol buruk - pada kenyataannya, definisi dasar itu baik - tetapi proliferasi seluruh kerangka kerja dan metode kerja untuk mencapai semua ini sedikit gila, terutama dikombinasikan dengan cara orang menghancurkan antarmuka yang sangat baik dan bersih untuk dapat menyuntikkan komponen yang dapat dipertukarkan yang 99% dari waktu Anda tidak akan pernah bisa dipertukarkan. Ini semacam hal yang hanya bisa berasal dari lingkungan perusahaan Java dan saya senang itu tidak memiliki banyak pijakan di tempat lain.

Seringkali argumennya adalah bahwa meskipun Anda tidak menukar komponen, Anda ingin dapat mengujinya secara terpisah dengan benda tiruan dan sejenisnya. Namun, saya khawatir saya tidak akan pernah membeli argumen bahwa itu layak membengkak dan menyulitkan antarmuka agar lebih dapat mengujinya. Pengujian hanya membuktikan satu hal - bahwa tes Anda berfungsi. Antarmuka yang bersih dan minimal membuktikan bahwa kode Anda berfungsi.

Jadi, jawaban singkatnya: ya, tapi tidak dengan cara Anda berpikir. Terkadang, ketika Anda membutuhkan perilaku yang dapat dipertukarkan, Anda akan meneruskan sebuah objek ke konstruktor yang menentukan bagian dari perilaku objek baru. Itu saja.

Pola Strategi , Komposisi , Injeksi Ketergantungan , semuanya sangat terkait erat.

Karena Pola Strategi adalah bentuk Injeksi Ketergantungan, jika Anda melihat mesin seperti Unity misalnya, mereka sepenuhnya didasarkan pada prinsip ini. Penggunaan Komponen (Pola Strategi) mereka sangat tertanam dalam seluruh mesin mereka.

Salah satu manfaat utama selain menggunakan kembali komponen adalah untuk menghindari hierarki kelas yang dalam yang ditakuti.

Berikut adalah artikel oleh Mick West yang berbicara tentang bagaimana ia memperkenalkan sistem jenis ini ke dalam seri permainan Tony Hawk oleh Neversoft.

Berevolusi Hirarki Anda

Hingga tahun-tahun belakangan ini, programmer game secara konsisten menggunakan hierarki kelas yang dalam untuk mewakili entitas game. Air pasang mulai bergeser dari penggunaan hierarki yang dalam ini ke berbagai metode yang menyusun objek entitas gim sebagai agregasi komponen ...

Tampaknya ada banyak kebingungan tentang pola Inversion of Control (IoC). Sejumlah orang telah menyamakannya dengan Pola Strategi atau Model Komponen, tetapi perbandingan ini tidak benar-benar menangkap tentang apa itu IoC. IOC benar-benar tentang bagaimana ketergantungan diperoleh. Biarkan saya memberi Anda sebuah contoh:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

Di atas jelas bahwa Sprite.Loadmemiliki ketergantungan pada a FileReader. Saat Anda ingin menguji metode ini, Anda memerlukan yang berikut ini:

1. Sistem file di tempat
2. File uji untuk memuat dari sistem file
3. Kemampuan untuk memicu kesalahan sistem file yang umum

Dua yang pertama sudah jelas, tetapi jika Anda ingin memastikan bahwa penanganan kesalahan Anda berfungsi seperti yang diharapkan, Anda benar-benar membutuhkan # 3 juga. Dalam kedua kasus Anda berpotensi memperlambat tes Anda sedikit karena mereka sekarang harus pergi ke disk dan Anda cenderung membuat lingkungan pengujian Anda lebih rumit.

Tujuan dari IoC adalah untuk memisahkan penggunaan perilaku dari konstruksinya. Perhatikan bagaimana ini berbeda dari pola Strategi. Dengan pola Strategi, tujuannya adalah untuk merangkum sejumlah perilaku yang dapat digunakan kembali sehingga Anda dapat dengan mudah memperluasnya di masa depan; tidak ada yang bisa dikatakan tentang bagaimana strategi dibangun.

Jika kita menulis ulang Sprite.Loadmetode di atas, kita mungkin akan berakhir dengan:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

Sekarang, kami telah memisahkan konstruksi pembaca dari penggunaannya. Oleh karena itu, mungkin untuk menukar pembaca tes selama pengujian. Ini berarti bahwa lingkungan pengujian Anda tidak lagi membutuhkan sistem file, menguji file, dan dapat dengan mudah mensimulasikan peristiwa kesalahan.

Perhatikan bahwa saya melakukan dua hal dalam penulisan ulang. Saya membuat antarmuka IReaderyang merangkum beberapa perilaku - yaitu menerapkan pola Strategi. Selain itu, saya memindahkan tanggung jawab untuk menciptakan pembaca yang tepat ke kelas lain.

Mungkin kita tidak perlu nama pola baru untuk menggambarkan hal di atas. Itu menurut saya sebagai campuran dari Strategi dan pola Pabrik (untuk wadah IOC). Karena itu, saya tidak yakin dengan alasan apa orang keberatan dengan pola ini karena jelas bahwa itu memecahkan masalah nyata, dan, tentu saja, tidak jelas bagi saya apa hubungannya dengan Jawa.

Saya akan mengatakan bahwa itu adalah salah satu alat di antara banyak, dan digunakan pada kesempatan. Seperti yang dikatakan tenpn, metode apa pun yang memperkenalkan vtables (dan umumnya tipuan tambahan apa pun) dapat memiliki penalti kinerja, tetapi ini adalah sesuatu yang hanya perlu kita khawatirkan untuk kode tingkat rendah. Untuk kode struktural tingkat tinggi yang sebenarnya bukan masalah, dan IoC dapat memiliki manfaat positif. Apa pun untuk mengurangi ketergantungan antar kelas dan membuat kode Anda lebih fleksibel.

Harus setuju dengan Kylotan yang satu ini. "Dependency injection" adalah solusi Java yang jelek untuk cacat konseptual Java yang jelek, dan satu-satunya alasan mengapa orang melihatnya dalam bahasa lain adalah karena Java menjadi bahasa pertama bagi banyak orang, padahal sebenarnya tidak.

Inversi kontrol, di sisi lain, adalah ide yang berguna yang sudah ada sejak lama, dan sangat membantu ketika dilakukan dengan benar. (Bukan cara Java / Dependency Injection.) Faktanya, Anda mungkin melakukannya sepanjang waktu jika Anda bekerja dalam bahasa pemrograman yang waras. Ketika saya pertama kali membaca tentang semua hal "IOC" yang didengungkan oleh semua orang, saya benar-benar underwhelmed. Inversion of Control tidak lebih dari melewatkan penunjuk fungsi (atau penunjuk metode) ke rutin atau objek untuk membantu menyesuaikan perilakunya.

Ini adalah ide yang sudah ada sejak 1950-an. Ada di pustaka standar C (qsort terlintas di benak) dan semuanya ada di Delphi dan .NET (event handler / delegates). Ini memungkinkan kode lama untuk memanggil kode baru tanpa perlu mengkompilasi ulang kode lama, dan digunakan sepanjang waktu di mesin permainan.

Tidak dalam pengalaman saya. Yang memalukan, karena kode gim harus sangat mudah beradaptasi, dan pendekatan ini pasti akan membantu.

Namun harus dikatakan bahwa kedua metode bisa, dalam C ++, memperkenalkan tabel virtual di mana tidak ada sebelumnya, membawa serta mereka hit kinerja yang sesuai.

Saya bukan pengembang permainan profesional, dan hanya mencoba menerapkan IoC di C ++ sekali, jadi ini hanya berspekulasi.

Namun, saya menduga para pengembang game akan curiga tentang IoC karena itu berarti:

1 / mendesain banyak antarmuka dan banyak kelas kecil

2 / memiliki hampir semua panggilan fungsi sedang terikat

Sekarang, itu mungkin kebetulan, tetapi keduanya cenderung sedikit lebih rumit dan / atau bermasalah untuk kinerja di C ++ (yang banyak digunakan dalam game, bukan?) Daripada di Jawa, di mana IoC menjadi luas (Mungkin karena itu relatif mudah dilakukan, membantu orang mendesain hierarki objek yang lebih waras, dan karena beberapa percaya itu bisa mengubah penulisan aplikasi di Jawa menjadi menulis aplikasi dalam XML, tapi itu debat lain: P)

Saya tertarik pada komentar jika itu tidak masuk akal sama sekali;)