Perbarui (rekap)
Karena saya telah menulis jawaban yang agak bertele-tele, inilah yang akhirnya menjadi:
- Ruang nama itu baik, gunakan kapan pun itu masuk akal
- Penggunaan
inGameIOdan playerIOkelas kemungkinan merupakan pelanggaran SRP. Kemungkinan itu berarti Anda menggabungkan cara Anda menangani IO dengan logika aplikasi.
- Memiliki beberapa kelas IO generik, yang digunakan (atau terkadang dibagi) oleh kelas handler. Kelas-kelas handler ini kemudian akan menerjemahkan input mentah ke dalam format yang dapat dimengerti oleh logika aplikasi Anda.
- Hal yang sama berlaku untuk output: ini dapat dilakukan oleh kelas yang cukup umum, tetapi melewati keadaan permainan melalui objek handler / mapper yang menerjemahkan keadaan permainan internal menjadi sesuatu yang bisa ditangani oleh kelas IO generik.
Saya pikir Anda melihat ini dengan cara yang salah. Anda memisahkan fungsi IO dalam komponen aplikasi, sedangkan - untuk lebih masuk akal untuk memiliki kelas IO terpisah berdasarkan sumber, dan "jenis" IO.
Memiliki beberapa KeyboardIOkelas dasar / generik MouseIOuntuk memulai, dan kemudian berdasarkan kapan dan di mana Anda membutuhkannya, memiliki subkelas yang menangani kata IO secara berbeda.
Misalnya, input teks adalah sesuatu yang mungkin ingin Anda tangani secara berbeda untuk kontrol dalam game. Anda akan menemukan diri Anda ingin memetakan kunci tertentu secara berbeda tergantung pada setiap kasus penggunaan, tetapi pemetaan itu bukan bagian dari IO itu sendiri, melainkan bagaimana Anda menangani IO.
Berpegang teguh pada SRP, saya akan memiliki beberapa kelas yang dapat saya gunakan untuk keyboard IO. Bergantung pada situasinya, saya mungkin ingin berinteraksi dengan kelas-kelas ini secara berbeda, tetapi satu-satunya tugas mereka adalah memberi tahu saya apa yang dilakukan pengguna.
Saya kemudian akan menyuntikkan objek-objek ini ke objek handler yang akan memetakan IO mentah ke sesuatu yang logika aplikasi saya dapat bekerja dengan (misalnya: pengguna menekan "w" , handler memetakan itu ke MOVE_FORWARD).
Penangan ini, pada gilirannya digunakan untuk membuat karakter bergerak, dan menggambar layar sesuai. Penyederhanaan yang terlalu berlebihan, tetapi intinya adalah struktur seperti ini:
[ IO.Keyboard.InGame ] // generic, if SoC and SRP are strongly adhered to, changing this component should be fairly easy to do
||
==> [ Controls.Keyboard.InGameMapper ]
[ Game.Engine ] <- Controls.Keyboard.InGameMapper
<- IO.Screen
<- ... all sorts of stuff here
InGameMapper.move() //returns MOVE_FORWARD or something
||
==> 1. Game.updateStuff();//do all the things you need to do to move the character in the given direction
2. Game.Screen.SetState(GameState); //translate the game state (inverse handler)
3. IO.Screen.draw();//generate actual output
Apa yang kita miliki sekarang adalah kelas yang bertanggung jawab atas IO keyboard dalam bentuk mentahnya. Kelas lain yang menerjemahkan data ini menjadi sesuatu yang benar-benar masuk akal oleh mesin permainan, data ini kemudian digunakan untuk memperbarui status semua komponen yang terlibat, dan akhirnya, kelas yang terpisah akan menangani output ke layar.
Setiap kelas memiliki satu pekerjaan: menangani input keyboard dilakukan oleh kelas yang tidak tahu / peduli / harus tahu apa arti input yang diprosesnya. Yang perlu dilakukan adalah mengetahui cara mendapatkan input (buffered, unbuffered, ...).
Pawang menerjemahkan ini ke dalam representasi internal untuk sisa aplikasi untuk memahami info ini.
Mesin permainan mengambil data yang telah diterjemahkan, dan menggunakannya untuk memberi tahu semua komponen yang relevan bahwa sesuatu sedang terjadi. Masing-masing komponen melakukan hanya satu hal, apakah itu pemeriksaan tabrakan, atau perubahan karakter animasi, tidak masalah, itu tergantung pada masing-masing objek.
Objek-objek ini kemudian menyampaikan keadaannya kembali, dan data ini diteruskan ke Game.Screen, yang pada dasarnya adalah penangan IO terbalik. Ini memetakan representasi internal ke sesuatu yang IO.Screendapat digunakan komponen untuk menghasilkan output yang sebenarnya.