Yönetici sınıfları yazmaktan nasıl kaçınırım?

XxxManagerOyun motoru programlamasında stil sınıflarını kullanmak kötü bir fikir gibi görünüyor , ancak kullanımlarından kaçınmaya çalıştığımda bile her zaman tüm aktörleri / varlıkları / oyun dünyası yerlerini tutan ve bunlara göre hareket eden bir şeyle sonuçlanıyorum. bir olmak biter Managerbaşka isimle eğer.

Bu gerçekten takip edilmesi kötü bir model mi? Varsa, alternatifler nelerdir?

"Yönetici" sınıfları can çeşitli nedenlerle sorunlu . İki temel neden şu şekildedir:

• isim belli değil (ne aslında "yönetim" gerektirir ve yönetilen her şey için her zaman aynı mıdır?)
• tek sorumluluk ilkesini ihlal eden işlevsellik kovaları olma eğilimindedirler (yani, bir tür bir şey yapmalıdır)

Genellikle bu nedenlerden biri diğerine neden olur veya ima eder.

Bu konular akılda tutulması gereken iyi şeylerdir, ancak oyununuzu gerçekten yapma yeteneğinizi felce uğratmalarına izin vermeyin . Sonunda kimse derslerinizin ne dendiğini ya da ne yaptığını umursamaz. Oyununu önemsiyorlar.

Çoğu "yöneticiyi" iki parçaya ayırmak genellikle oldukça kolaydır:

• gerçek nesneleri saklayan ve bunlara erişim sağlayan kısım (buna "mağaza," a "veri havuzu," a "veritabanı," a "önbellek" veya başka çeşitli şeyler diyebilirsiniz. nesnelerin ömrü boyunca, yani bir nesne bu tür bir örnekten kaldırıldığında veya artık başka bir şekilde bulunmadığında varlığını sona erdirir.

• parçası işler gerçek nesneler ve onlara benzer işleri yapar. Bu nesneleri güncelleyebilir (daha sonra bir "güncelleyici" veya "simülasyon" olabilir) veya çizebilir (o zaman bir "çekmece" veya "oluşturucu"). Veya onlarla başka bir şey yapabilir; önemli olan onu birincil amacına göre adlandırmaktır. Genellikle bu türden örneklere ilk türün (yalnızca nesnelerin ömrünü işleyen örnek) bir örneğini veya örneklerini verirsiniz.

Birinci türün adının yönetici içerebileceği konusunda makul bir argüman yapılabilir (bazı nesnelerin "ömrünü" yönettiği için). Türünüzü bu şekilde adlandırırsanız dünya sona ermeyecektir, ancak "şeylerin yöneticilerini arama" biçiminin diz sarsıntılı tepkilerine katlanmanız gerekebilir, bu yüzden sadece bunun için kaçınmak isteyebilirsiniz.

Yorumlarda bağlandığınız blog gönderisini okuduğunuzda, "başka bir adla Yönetici olmanın" tam olarak sizin yapmasını istediğiniz şey olduğunu göreceksiniz. Yazılım geliştirmede küresel değişkenlerin kötü olduğu konusunda genel bir fikir birliği vardır ve tek alternatif, herhangi bir verinin diğer veriler tarafından tutulmasıdır.

Adında bir sınıfla ilgili sorun, FoobarManager"Yönetici" sözcüğünün size sınıfın gerçekte ne yaptığını söylememesi . Örneğin:

• Foobarların oyun mekaniğini kontrol ettiğinde, adlandırabilirsiniz FoobarController.
• Foobarları başlatır, ancak daha sonra kontrolü başka bir şeye devrettiğinde, bu bir FoobarFactoryveya FoobarBuilder.
• Foobarları ekrana çektiğinde, a FoobarRenderer.
• Foobarlar tarafından oluşturulan olayları dinlediğinde, FoobarEventHandler .
• Foobarlarda bir şey olmasını beklediğinde, bu bir FoobarObserver.
• Hiç mantığı olmayan bir foobar koleksiyonu için sadece aptal bir veri sahibi olduğunda, sadece adlandırın Foobars.

Bu sınıflardan herhangi birine "Yönetici" adını verebilirsiniz. Ancak daha sonra bu işlevlerden herhangi birini gerçekleştirebilir. Ve daha sonra yukarıdaki işlevlerden birine ihtiyacınız olduğunu fark ettiğinizde, bunu FoobarManager'a da entegre edeceksiniz. Böylece , Endişelerin Ayrılması ilkesini ihlal eden bir Tanrı Nesnesi ile sonuçlanacaksınız (her sınıf tam olarak bir şey yapmalıdır).