Bagaimana cara saya menghindari menulis kelas Manajer?

Sepertinya saya terus membaca itu adalah ide yang buruk untuk menggunakan XxxManagerkelas gaya dalam pemrograman mesin game, namun bahkan ketika saya mencoba untuk menghindari penggunaannya, saya selalu berakhir dengan sesuatu yang memegang semua aktor / entitas / lokasi dunia game dan menindakinya, yang akhirnya menjadi Managerjika dengan nama lain.

Apakah ini benar-benar pola yang buruk untuk diikuti? Jika demikian, apa alternatifnya?

Kelas "Manajer" dapat bermasalah karena berbagai alasan. Dua alasan utama cenderung menjadi:

• namanya tidak jelas (apa sebenarnya yang dimaksud dengan "manajemen", dan apakah selalu sama untuk setiap jenis hal yang dikelola?)
• mereka cenderung menjadi ember fungsionalitas yang melanggar prinsip tanggung jawab tunggal (yaitu, bahwa suatu tipe harus melakukan satu hal)

Seringkali salah satu alasan itu menyebabkan atau menyiratkan yang lain.

Masalah-masalah itu adalah hal yang baik untuk diingat, tetapi jangan biarkan mereka melumpuhkan kemampuan Anda untuk benar - benar membuat permainan Anda . Pada akhirnya tidak ada yang akan peduli apa yang disebut kelas Anda atau apa yang mereka lakukan. Mereka akan peduli dengan game Anda.

Biasanya cukup mudah untuk memisahkan sebagian besar "manajer" menjadi dua bagian:

• bagian yang menyimpan objek aktual dan menyediakan akses ke objek tersebut (yang dapat Anda sebut "store," a "repository," a "database," a "cache," atau berbagai hal lainnya. Ini adalah jenis yang biasanya bertanggung jawab untuk seumur hidup dari objek, yaitu, ketika suatu objek dihapus dari atau tidak lagi terkandung oleh turunan dari jenis ini ia tidak ada lagi.

• bagian yang memproses objek aktual dan melakukan beberapa pekerjaan padanya. Mungkin memperbarui objek-objek itu (maka itu adalah "pembaru" atau "simulasi") atau mungkin menggambar mereka (maka itu adalah "laci" atau "penyaji"). Atau mungkin melakukan hal lain dengan mereka; yang penting adalah menamainya sesuai dengan tujuan utamanya. Anda biasanya akan memberikan contoh dari jenis ini contoh atau referensi ke contoh dari jenis pertama (yang hanya menangani seumur hidup dari objek).

Argumen yang masuk akal dapat dibuat bahwa nama tipe pertama dapat mencakup manajer (karena "mengatur masa pakai" beberapa objek). Dunia tidak akan berakhir jika Anda menyebutkan tipe Anda dengan demikian, meskipun Anda mungkin perlu memasang reaksi spontan dari bentuk "jangan panggil manajer hal" lebih sering, jadi Anda mungkin ingin menghindarinya hanya untuk itu.

Ketika Anda membaca posting blog yang Anda tautkan di komentar, maka Anda akan melihat bahwa "menjadi seorang Manajer jika dengan nama lain" persis seperti yang Anda inginkan. Ini adalah konsensus umum dalam pengembangan perangkat lunak bahwa variabel global adalah jahat, dan satu-satunya alternatif adalah bahwa setiap data dipegang oleh data lain.

Masalah dengan kelas bernama FoobarManageradalah bahwa kata "Manajer" tidak memberi tahu Anda apa yang sebenarnya dilakukan kelas . Sebagai contoh:

• Saat ia mengontrol mekanisme gim foobar, Anda bisa menamainya FoobarController.
• Ketika instantiates foobars tetapi kemudian delegasi mengontrol sesuatu yang lain, itu adalah FoobarFactoryatau FoobarBuilder.
• Ketika itu menarik foobars ke layar, itu a FoobarRenderer.
• Saat mendengarkan acara yang dihasilkan oleh foobars, itu a FoobarEventHandler.
• Ketika menunggu sesuatu terjadi dengan foobars, itu a FoobarObserver.
• Ketika itu hanya pemegang data bodoh untuk koleksi foobars tanpa logika sama sekali, Anda cukup menyebutkannya Foobars.

Anda bisa memberi nama salah satu dari kelas ini "Manajer". Tapi kemudian bisa melakukan fungsi-fungsi ini. Dan ketika Anda kemudian menyadari bahwa Anda membutuhkan fungsi lain di atas, Anda juga akan mengintegrasikannya ke dalam Manajer Foobar. Jadi Anda akan berakhir dengan Obyek Tuhan yang melanggar prinsip Pemisahan Kekhawatiran (setiap kelas harus melakukan tepat satu hal).