¿Cómo evito escribir clases de Manager?

Parece que sigo leyendo que es una mala idea usar XxxManagerclases de estilo en la programación del motor del juego, pero incluso cuando trato de evitar su uso, siempre termino con algo que contiene a todos los actores / entidades / ubicaciones del mundo del juego y actúa sobre ellos, lo que termina siendo un Managerif con otro nombre.

¿Es realmente un mal patrón a seguir? Si es así, cuáles son las alternativas?

Las clases "Manager" pueden ser problemáticas por varias razones. Las dos razones clave tienden a ser:

• el nombre no está claro (¿qué implica realmente "gestión", y es siempre el mismo para cada tipo de cosa que se gestiona?)
• tienden a ser cubos de funcionalidad que violan el principio de responsabilidad única (es decir, que un tipo debe hacer una cosa)

A menudo, una de esas razones causa o implica la otra.

Esos temas son buenos para tener en cuenta, pero no dejen paralizar su capacidad de hacer su juego . Al final, a nadie le importará cómo se llaman tus clases o qué hacen. Ellos se preocuparán por tu juego.

Por lo general, es bastante fácil separar la mayoría de los "gerentes" en dos partes:

• la parte que almacena los objetos reales y proporciona acceso a ellos (que puede llamar una "tienda", un "repositorio", una "base de datos", un "caché" u otras cosas. Este es el tipo que generalmente es responsable durante toda la vida útil de los objetos; es decir, cuando un objeto se elimina de una instancia de este tipo o deja de estar contenida, deja de existir.

• la parte que procesa los objetos reales y realiza un trabajo sobre ellos. Puede actualizar esos objetos (luego es un "actualizador" o "simulación") o puede dibujarlos (entonces es un "cajón" o "renderizador"). O podría hacer algo más con ellos; lo importante es nombrarlo de acuerdo con su propósito principal. Generalmente, le daría a las instancias de este tipo una instancia o referencia a instancias del primer tipo (la que solo maneja la vida útil de los objetos).

Se podría argumentar razonablemente que el nombre del primer tipo podría incluir administrador (ya que "administra la vida útil de" algunos objetos). El mundo no terminará si nombra su tipo de esta manera, aunque es posible que tenga que soportar las reacciones instintivas de la forma "no llame a los gerentes de las cosas" con bastante frecuencia, por lo que es posible que desee evitarlo solo por eso.

Cuando leas la publicación de blog a la que te vinculaste en los comentarios, verás que "ser Gerente si con otro nombre" es exactamente lo que quiere que hagas. Es un consenso general en el desarrollo de software que las variables globales son malvadas, y la única alternativa es que cualquier información sea almacenada por otra información.

El problema con una clase llamada FoobarManageres que la palabra "Administrador" no te dice qué hace realmente la clase . Por ejemplo:

• Cuando controla la mecánica del juego de los foobars, puedes nombrarlo FoobarController.
• Cuando crea una instancia de foobars pero luego delega el control a otra cosa, es un FoobarFactoryo FoobarBuilder.
• Cuando dibuja los foobars en la pantalla, es un FoobarRenderer.
• Cuando escucha eventos generados por foobars, es a FoobarEventHandler.
• Cuando espera que suceda algo con los foobars, es un FoobarObserver.
• Cuando es solo un titular de datos tonto para una colección de foobars sin ninguna lógica en absoluto, solo tiene que nombrarlo Foobars.

Puede nombrar cualquiera de estas clases "Gerente". Pero luego podría realizar cualquiera de estas funcionalidades. Y cuando más tarde se dé cuenta de que necesita otra de las funcionalidades anteriores, también la integrará en FoobarManager. Entonces terminarás con un Objeto de Dios que rompe el principio de Separación de Preocupaciones (cada clase debe hacer exactamente una cosa).