Jak uniknąć pisania klas menedżerskich?

Wydaje mi się, że wciąż czytam, że używanie XxxManagerklas stylów w programowaniu silnika gry jest kiepskim pomysłem , ale nawet gdy staram się ich unikać, zawsze mam coś, co utrzymuje wszystkie lokalizacje aktorów / bytów / świata gry i działa na nie, co kończy się tym, Managerże pod innym imieniem.

Czy to naprawdę zły wzór do naśladowania? Jeśli tak, jakie są alternatywy?

Klasy menedżerskie mogą być problematyczne z różnych powodów. Dwa główne powody to:

• nazwa jest niejasna (co właściwie oznacza „zarządzanie” i czy zawsze jest taka sama dla każdego rodzaju zarządzanych rzeczy?)
• mają tendencję do bycia segmentami funkcji, które naruszają zasadę pojedynczej odpowiedzialności (to znaczy, że typ powinien zrobić jedną rzecz)

Często jeden z tych powodów powoduje lub implikuje drugi.

Te kwestie to dobra rzecz, o której należy pamiętać, ale nie pozwól, by sparaliżowały twoją grę . W końcu nikt nie będzie dbał o to, jak nazywają się twoje zajęcia ani co robią. Będą dbać o twoją grę.

Zazwyczaj dość łatwo jest podzielić większość „menedżerów” na dwie części:

• część, która przechowuje rzeczywiste obiekty i zapewnia do nich dostęp (którą można nazwać „sklepem”, „repozytorium”, „bazą danych”, „pamięcią podręczną” lub innymi innymi rzeczami. Jest to typ, który zazwyczaj jest odpowiedzialny na czas życia obiektów, to znaczy, gdy obiekt zostanie usunięty z instancji tego typu lub w inny sposób nie będzie go już zawierał, przestaje istnieć.

• część, która przetwarza rzeczywiste obiekty i wykonuje na nich pewne prace. Może aktualizować te obiekty (wtedy jest to „aktualizator” lub „symulacja”) lub może je narysować (wtedy jest to „szuflada” lub „renderer”). Lub może zrobić z nimi coś innego; ważne jest, aby nazwać go zgodnie z jego głównym celem. Generalnie nadasz instancjom tego typu instancję lub odniesienie do instancji pierwszego typu (tej, która po prostu obsługuje czas życia obiektów).

Rozsądna argumentacja mogłaby być wykonana, że nazwa pierwszego typu mogą obejmować menedżera (jak to „zarządza żywotność” niektórych obiektów). Świat nie skończy się, jeśli nazwiesz w ten sposób swój typ, chociaż być może będziesz musiał znosić reakcje typu „nie zadzwoń do menedżerów rzeczy” dość często, więc możesz chcieć tego uniknąć.

Po przeczytaniu posta na blogu, do którego linkujesz w komentarzach, zobaczysz, że „bycie Menedżerem, jeśli pod inną nazwą” jest dokładnie tym, czego chce. Podczas opracowywania oprogramowania panuje ogólna zgoda co do tego, że zmienne globalne są złe, a jedyną alternatywą jest to, że wszelkie dane są przechowywane przez inne dane.

Problem z klasą o nazwie FoobarManagerpolega na tym, że słowo „Manager” nie mówi ci, co faktycznie robi klasa . Na przykład:

• Kiedy kontroluje mechanikę gry foobarów, możesz ją nazwać FoobarController.
• Kiedy tworzy instancje foobarów, a następnie przekazuje kontrolę nad czymś innym, jest to FoobarFactorylub FoobarBuilder.
• Kiedy rysuje foobary na ekranie, jest to FoobarRenderer.
• Gdy nasłuchuje zdarzeń generowanych przez foobary, jest to FoobarEventHandler.
• Kiedy czeka, aż coś się stanie z foobarami, jest to FoobarObserver.
• Gdy jest to tylko głupi posiadacz danych dla zbioru foobarów bez żadnej logiki, wystarczy go nazwać Foobars.

Możesz nazwać każdą z tych klas „Menedżerem”. Ale wtedy może wykonać dowolną z tych funkcji. A kiedy później uświadomisz sobie, że potrzebujesz innej z powyższych funkcji, zintegrujesz ją również z FoobarManager. Skończysz z Boskim Obiektem, który łamie zasadę Separacji Obawy (każda klasa powinna zrobić dokładnie jedną rzecz).