Como evito escrever aulas do Manager?

Parece que continuo lendo que é uma má ideia usar XxxManagerclasses de estilo na programação de mecanismos de jogos, mas mesmo quando tento evitar o uso delas, sempre acabo com algo que mantém todos os atores / entidades / locais do mundo dos jogos e age sobre eles, o que acaba sendo um Managerif por outro nome.

Esse é realmente um padrão ruim a seguir? Se sim, quais são as alternativas?

As classes "Manager" podem ser problemáticas por vários motivos. Os dois principais motivos tendem a ser:

• o nome não é claro (o que realmente significa "gerenciamento" e é sempre o mesmo para todo tipo de coisa sendo gerenciada?)
• eles tendem a ser grupos de funcionalidades que violam o princípio da responsabilidade única (ou seja, que um tipo deve fazer uma coisa)

Muitas vezes, uma dessas razões causa ou implica a outra.

Essas questões são boas coisas a serem lembradas, mas elas não paralisam sua capacidade de realmente fazer o seu jogo . No final, ninguém vai se importar com o que suas aulas são chamadas ou o que elas fazem. Eles vão se importar com o seu jogo.

Geralmente, é muito fácil separar a maioria dos "gerentes" em duas partes:

• a parte que armazena os objetos reais e fornece acesso a eles (que você pode chamar de "armazenamento", "repositório", "banco de dados", "cache" ou várias outras coisas. Esse é o tipo geralmente responsável pelo tempo de vida dos objetos, ou seja, quando um objeto é removido ou não está mais contido por uma instância desse tipo, ele deixa de existir.

• a parte que processa os objetos reais e realiza algum trabalho neles. Ele pode atualizar esses objetos (então é um "atualizador" ou "simulação") ou pode desenhá-los (então é uma "gaveta" ou "renderizador"). Ou pode fazer outra coisa com eles; o importante é nomeá-lo de acordo com seu objetivo principal. Você geralmente atribui a instâncias desse tipo uma instância ou referência a instâncias do primeiro tipo (aquela que apenas lida com a vida útil dos objetos).

Pode-se argumentar razoavelmente que o nome do primeiro tipo pode incluir gerente (pois "gerencia a vida útil de" alguns objetos). O mundo não terminará se você nomear seu tipo dessa maneira, embora seja necessário aguentar as reações instintivas da forma "não chame as coisas de gerentes" com bastante frequência; portanto, você pode evitá-lo apenas por isso.

Ao ler a postagem do blog ao qual você vinculou nos comentários, você verá que "ser um gerente com outro nome" é exatamente o que ele deseja que você faça. É consenso geral no desenvolvimento de software que variáveis ​​globais são más, e a única alternativa é que quaisquer dados sejam mantidos por outros dados.

O problema com uma classe nomeada FoobarManageré que a palavra "Gerente" não informa o que a classe realmente faz. Por exemplo:

• Quando ele controla a mecânica do jogo dos foobars, você pode nomear FoobarController.
• Quando instancia foobars, mas depois delega o controle para outra coisa, é um FoobarFactoryou FoobarBuilder.
• Quando atrai os foobars para a tela, é a FoobarRenderer.
• Quando ouve eventos gerados por foobars, é um FoobarEventHandler.
• Quando espera que algo aconteça com os foobars, é um FoobarObserver.
• Quando é apenas um detentor de dados estúpido para uma coleção de foobars sem nenhuma lógica, basta nomear Foobars.

Você pode nomear qualquer uma dessas classes "Gerente". Mas então ele poderia executar qualquer uma dessas funcionalidades. E quando você perceber mais tarde que precisa de outras funcionalidades acima, você também integrará isso ao FoobarManager. Então você terminará com um Objeto Divino que quebra o princípio da Separação de Preocupações (toda classe deve fazer exatamente uma coisa).