Как мне избежать написания менеджера классов?

Я, кажется, продолжаю читать, это плохая идея использовать XxxManagerклассы стилей в программировании игрового движка, но даже когда я пытаюсь избежать их использования, я всегда получаю что-то, что удерживает все местоположения актеров / сущностей / игрового мира и воздействует на них, что в конечном итоге, Managerесли под другим именем.

Это действительно плохой шаблон для подражания? Если так, каковы альтернативы?

«Менеджерские» занятия могут быть проблематичными по разным причинам. Две основные причины:

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

Часто одна из этих причин вызывает или подразумевает другую.

Об этих проблемах стоит помнить, но не позволяйте им парализовать вашу способность реально создавать свою игру . В конце концов, никого не волнует, как называются ваши уроки или что они делают. Они будут заботиться о вашей игре.

Обычно довольно легко разделить большинство «менеджеров» на две части:

• часть, которая хранит фактические объекты и обеспечивает доступ к ним (которые можно назвать «хранилищем», «хранилищем», «базой данных», «кешем» или другими различными вещами). Этот тип обычно отвечает за на время существования объектов, то есть когда объект удаляется или иным образом больше не содержится в экземпляре этого типа, он перестает существовать.

• часть, которая обрабатывает реальные объекты и выполняет с ними некоторую работу. Он может обновлять эти объекты (тогда это «программа обновления» или «симуляция») или может рисовать их (тогда это «ящик» или «средство визуализации»). Или это может сделать что-то еще с ними; важно назвать его в соответствии с его основной целью. Обычно вы бы дали экземплярам этого типа экземпляр или ссылку на экземпляры первого типа (тот, который просто обрабатывает время жизни объектов).

Можно привести разумный аргумент , что имя первого типа может включать в себя менеджер (поскольку он «управляет временем жизни» некоторых объектов). Мир не кончится, если вы так точно назовете свой тип, хотя вам, возможно, придется мириться с реакциями по колено в форме «не называйте вещи менеджерами» довольно часто, поэтому вы можете избежать этого только ради этого.

Когда вы прочитаете сообщение в блоге, на которое вы ссылаетесь в комментариях, вы увидите, что «быть менеджером, если под другим именем» - это именно то, что он хочет, чтобы вы делали. При разработке программного обеспечения существует общее мнение, что глобальные переменные являются злом, и единственной альтернативой является то, что любые данные хранятся в других данных.

Проблема с именем класса FoobarManagerсостоит в том, что слово «менеджер» не говорит вам, что на самом деле делает класс . Например:

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

Вы можете назвать любой из этих классов "Менеджер". Но тогда он может выполнять любую из этих функций. И когда вы позже поймете, что вам нужна другая из перечисленных выше функций, вы также интегрируете ее в FoobarManager. Таким образом, вы получите Объект Бога, который нарушает принцип Разделения Проблем (каждый класс должен делать только одно).