Apakah ide buruk untuk memiliki Game1 statis di XNA?

Apakah ide saya buruk jika Game1kelas saya statis? Seperti pada saat ini di Game1kelas saya, saya memiliki kelas yang disebut TileHandleryang menangani semuanya dengan set ubin saya saat ini, dan AnimalHandleryang menangani semua hewan saya (mengejutkan).

Sekarang jika saya masuk AnimalHandlerdan ingin memeriksa apakah ubin TileHandlerbisa dilalui dari sana yang menyebabkan masalah atau saya harus memasukkan daftar ubin AnimalHandleryang bisa dilalui , yang saya lebih suka tidak melakukannya.

Apa yang lebih mudah adalah membuat Game1statis dan kemudian AnimalHandlerpergi begitu saja Game1._tileHandler.WalkableTile(position).

Sekarang saya tidak bisa melihat ada yang salah dengan ini atau apa pun yang menyebabkan masalah, tetapi saya baru saja mulai menggunakan kelas statis, jadi apakah ada yang lebih berpengetahuan melihat alasan besar mengapa itu ide yang buruk?

Sekarang saya tidak bisa melihat ada yang salah dengan ini atau apa pun yang menyebabkan masalah, tetapi saya baru saja mulai menggunakan kelas statis, jadi apakah ada yang lebih berpengetahuan melihat alasan besar mengapa itu ide yang buruk?

Ketika Anda memiliki palu baru yang mengilap, setiap masalah terlihat seperti paku.

Secara umum tidak ada yang salah dengan kelas dan / atau metode statis, jika digunakan dengan benar (untuk hal-hal yang tidak memiliki atau bergantung pada kondisi per-instance). Namun, dalam kasus Anda, Anda menyalahgunakan mereka untuk menyembunyikan dependensi per-instance, membingungkan ini dengan menghapus dependensi. Tampaknya juga Anda mengekspos detail implementasi Game1kelas, yang juga umumnya buruk.

Inilah inti permasalahan Anda:

... jika saya masuk AnimalHandlerdan ingin memeriksa apakah ubin dapat ditelusuri sejak TileHandlersaat itu yang menyebabkan masalah atau saya harus memasukkan daftar ubin yang bisa walkable AnimalHandler, yang saya lebih suka tidak melakukannya.

Mengabaikan kemungkinan bahwa AnimalHandlermembutuhkan ubin ini sendiri mungkin merupakan desain yang buruk (dengan nama yang Anda pilih sulit untuk menjelaskan detail dari kelas-kelas ini) untuk saat ini ... jika AnimalHandlermembutuhkan daftar ubin yang dapat dilalui, maka perlu daftar ubin walkable. Umumnya lebih baik untuk membuat dependensi lebih eksplisit daripada kurang , karena membuat kode lebih mendokumentasikan diri. Dengan mengirimkan daftar langsung ke AnimalHandler, Anda secara eksplisit memanggil fakta bahwa ia membutuhkan daftar tersebut. Jika Anda sebaliknya menjadikan semuanya statis dan publik sehingga Anda bisa mengakses daftar statis yang ada di tempat lain dalam kode, yang Anda lakukan hanyalah menyembunyikan ketergantungan tanpa benar-benar menyelesaikan atau menghapusnya.

Untuk gim kecil yang tidak perlu meningkatkan skala ini, ini tidak akan menjadi masalah, tapi itu bisa membawa Anda ke jalan kebiasaan buruk sehingga Anda mungkin ingin mempertimbangkan untuk tidak melakukannya. Setidaknya ingatlah ini untuk proyek berikutnya yang Anda kerjakan.

Alasan mengapa memanggil TileHandler dalam konteks statis bukanlah desain terbaik, karena menggabungkan komponen desain Anda yang dapat dipisahkan.

Jika Anda memilih untuk memiliki lebih dari satu TileHandler di masa mendatang, Anda harus melakukan banyak pekerjaan untuk mengakomodasi perubahan ini.

Jika Anda memilih untuk menghapus TileHandler, Anda harus melakukan banyak pekerjaan untuk mengakomodasi perubahan ini.

Misalkan Anda membangun level / zona yang berbeda di masa depan, yang menangani ubin dengan cara yang berbeda dari TileHandler Anda saat ini. Maka Anda harus memiliki cara untuk menentukan metode penanganan ubin yang akan digunakan, atau Anda perlu memanggil penangan yang berbeda.

Jika TileHandler dilewatkan sebagai parameter ke objek yang menggunakannya, maka Anda bisa dengan mudah memberikan yang lain kali, atau mengatur pawang ubin yang berbeda pada objek yang menggunakannya nanti.

Secara pribadi, saya mengakses banyak hal di game XNA saya dari konteks statis, dan berasumsi bahwa saya tidak akan pernah memiliki lebih dari satu.

Jika Anda ingin dapat menggunakan kembali kode mesin gim Anda di gim berikutnya, Anda mungkin harus menulis ulang banyak hal yang saat ini Anda tulis sebagai statis.

Pendeknya:

Agar tidak menggunakan konteks statis:

Melewati objek sebagai parameter sebanyak mungkin memisahkan elemen-elemen permainan, dan memungkinkan Anda untuk memodifikasi / menggunakan kembali mereka untuk proyek saat ini atau masa depan dengan lebih mudah. Ini juga memungkinkan Anda untuk mengelola kompleksitas kode dalam jumlah besar sedikit lebih mudah (bayangkan memiliki ratusan manajer statis di kelas gim Anda, dalam gim besar).

Mendukung konteks statis:

Mendeklarasikan dan mengakses objek dari konteks statis membuatnya lebih mudah untuk menulis game kecil yang tidak memerlukan ratusan manajer statis. Menyederhanakan banyak metode dan konstruktor dengan tidak memerlukan satu atau lebih parameter tambahan yang diakses secara statis.

Saya tidak berpikir itu ide yang sangat buruk untuk permainan sederhana, tetapi Anda juga bisa melihat di http://www.nuclex.org/articles/4-architecture/6-game-components-and-game-services untuk ide yang lebih baik tentang cara membangun komponen game yang berkomunikasi

Hal-hal seperti TileHandler dan AnimalHandler saya akan menempatkan tingkat yang lebih tinggi ke layar permainan. Apakah layar judul Anda memerlukan akses ke TileHandler dan apakah ini diinisialisasi saat gim pertama kali dimuat? Mungkin tidak.

Lihat sampel Manajemen XNA State . Ada banyak kode di sana, tetapi pada dasarnya base game hanya menginisialisasi setumpuk status permainan (atau layar). Setiap layar cukup independen dari yang lain dan berjalan sebagai versi sederhana dari Game itu sendiri. PlayScreen Anda dapat memiliki anggota statis sehingga mereka dapat diakses oleh komponen PlayScreen.

Dalam permainan dasar, saya menggunakan beberapa statika, tetapi mereka hal-hal tingkat yang sangat rendah seperti InputHelper, Log, atau pembaca Config. Mereka cukup standar di semua game sehingga mesin dasar dapat dengan cepat dan mudah dipindahkan. Layar adalah tempat terjadinya logika permainan yang sebenarnya. Pendeknya jawaban singkat - tidak, saya tidak berpikir itu ide yang buruk dalam teori, hanya berhati-hati apa yang Anda lakukan menjadi statis. Setelah Anda maju dan membuat sesuatu yang statis, itu adalah pekerjaan yang luar biasa jika Anda berubah pikiran.

Poin yang diangkat di sini semuanya baik. Dalam pengalaman saya (yang diakui lebih mengarah pada aplikasi bisnis daripada game), ada banyak kegunaan untuk kelas dan anggota statis dan saya telah menggunakannya berkali-kali. Saya telah menemukan, bahwa ketika persyaratan dan kompleksitas tumbuh, saya akhirnya mendaur ulang kelas-kelas statis dan mengubahnya menjadi kelas contoh dan mulai membagikannya.

Poin yang ingin saya sampaikan adalah, jika menggunakan kelas statis membantu Anda mengeluarkan game ini , lakukan saja, tetapi tetap lakukan hal yang benar: terapkan antarmuka atau kelas dasar sehingga lebih mudah untuk merobeknya dan mengkonversi ke kelas instance nanti.

Satu ons pencegahan bernilai satu pon penyembuhan, jadi pastikan kelas statis Anda tidak mengikat Anda sehingga membuatnya sulit untuk berubah. Sangat mudah untuk memperbaiki metode menggunakan kelas statis yang mengimplementasikan antarmuka sehingga menerima parameter antarmuka baru dan menggunakan antarmuka itu alih-alih referensi kelas statis.

Ya, itu umumnya selalu merupakan ide yang buruk.

Mengubah objek yang berisi data yang berubah (yaitu apa pun kecuali konstanta baca-saja dan tabel pencarian) menjadi kelas statis adalah tempat di mana desain yang baik membutuhkan penyelaman.

1. Ini mempromosikan dependensi serampangan yang membunuh modularitas dan menghalangi penggunaan kembali kode. Asumsikan Anda ingin menulis editor untuk permainan Anda - tiba-tiba ada banyak kelas yang meminta Game1Anda tidak dapat dengan mudah pindah ke perpustakaan bersama.

2. Kode Anda menjadi tidak dapat diuji. Pengujian unit bekerja dengan mengisolasi kelas individu dari yang lain dengan mengejek atau mensimulasikan ketergantungan mereka (yang harus dijaga seminimal mungkin). Setiap kelas statis adalah suatu kewajiban karena dapat diakses kapan saja, membawa status melalui beberapa tes atau perlu diinisialisasi sebelum tes dapat berhasil.

3. Itu menyembunyikan ketergantungan. Sama seperti anti-pola penyedia layanan (juga dipekerjakan oleh XNA, Game.Services), kelas Anda dapat memilih dependensi yang tidak Anda lihat di luar.

Pendekatan ini menjadi sangat beracun jika seseorang menggabungkan kelas statis dengan panggilan kereta barang (semacam Game.Instance.ActorManager.Enemies.FindInRange(10)- yang disebut karena simbol kereta seperti mobil kereta), di mana komponen tiba-tiba tidak hanya membutuhkan Gamekelas, tetapi satu dengan Instanceproperti statis yang mengembalikan sesuatu dengan sebuah ActorManagerproperti yang memiliki Enemiesproperti yang mengembalikan sebuah objek dengan FindInRange()metode.

Satu-satunya alasan yang akan saya terima untuk menulis kelas statis yang bisa berubah adalah yang masih belajar dan tidak memiliki kemampuan untuk secara konsisten menerapkan desain yang baik dan mata yang terlatih untuk menemukan pilihan yang buruk.