Як я уникаю писати класи менеджерів?

Я, здається, читаю, що це погана ідея використовувати XxxManagerкласи стилів у програмуванні ігрових механізмів, але навіть коли я намагаюся уникати їх використання, я завжди стикаюся з тим, що містить усі актори / сутності / світові локації та діє на них, що в кінцевому підсумку є Managerif якщо іншою назвою.

Це насправді погана модель? Якщо так, то які альтернативи?

Заняття «менеджер» можуть бути проблематичними з різних причин. Дві основні причини, як правило, такі:

• назва незрозуміла (що насправді означає "управління", і чи завжди вона однакова для кожного типу речей, якими керується?)
• вони прагнуть бути відрами функціональності, які порушують принцип єдиної відповідальності (тобто тип повинен виконувати одне)

Часто одна з цих причин викликає або має на увазі іншу.

Ці питання - це добре, що слід пам’ятати, але не дозволяйте їм паралізувати вашу здатність насправді робити вашу гру . Зрештою, ніхто не піде на те, як називаються ваші заняття чи що вони роблять. Вони будуть піклуватися про вашу гру.

Зазвичай досить просто розділити більшість "менеджерів" на дві частини:

• частина, яка зберігає фактичні об’єкти та забезпечує доступ до них (яку можна назвати "магазином", "сховищем", "базою даних", "кешем" або різними іншими речами. Зазвичай цей тип відповідає протягом терміну експлуатації об'єктів; тобто коли об'єкт видалено з іншого примірника такого типу або його більше не міститься, він припиняє своє існування.

• та частина, яка обробляє фактичні об’єкти та виконує над ними певну роботу. Він може оновлювати ці об'єкти (тоді це "оновлення" або "моделювання") або може малювати їх (тоді це "ящик" або "рендерінг"). Або це може зробити з ними щось інше; важливо - назвати його відповідно до його основного призначення. Ви, як правило, даєте екземплярам цього типу примірник або посилання на екземпляри першого типу (той, який просто обробляє термін експлуатації об'єктів).

Розумний аргумент може бути зроблено , що ім'я першого типу може включати в себе менеджер (як це «управляє життям» деякими об'єкти). Світ не закінчиться, якщо ви таким чином назвете свій тип, хоча вам може знадобитися миритися з колінними реакціями форми "не називайте менеджерів речей" досить часто, тож ви можете уникнути цього лише для цього.

Коли ви прочитаєте допис у блозі, на який ви посилаєтесь у коментарях, ви побачите, що "бути менеджером, якщо за іншим ім'ям" - це саме те, що ви хочете, щоб ви робили. Загальна думка в розробці програмного забезпечення полягає в тому, що глобальні змінні є злими, і єдиною альтернативою є те, що будь-які дані зберігаються за іншими даними.

Проблема класу з назвою FoobarManagerполягає в тому, що слово "Менеджер" не говорить вам про те, що клас робить насправді . Наприклад:

• Коли він керує механікою гри foobars, ви можете назвати її FoobarController.
• Коли він створює foobars, але потім делегує контроль над чимось іншим, це FoobarFactoryабо FoobarBuilder.
• Коли він малює фобар на екран, це a FoobarRenderer.
• Коли він слухає події, породжені фоабрами, це a FoobarEventHandler.
• Коли він чекає, що щось станеться з фоабами, це FoobarObserver.
• Коли це просто німий власник даних для колекції фобар без будь-якої логіки, ви просто назвете його Foobars.

Ви можете назвати будь-який із цих класів "Менеджером". Але тоді він міг би виконувати будь-яку з цих функцій. А пізніше, коли ви зрозумієте, що вам потрібен інший з перерахованих вище функцій, ви також інтегруєте це у FoobarManager. Таким чином, ви закінчитеся з об'єктом Бога, який порушує принцип розділення турбот (кожен клас повинен робити саме одне).