¿Consejos / sugerencias sobre cómo reducir el uso de las clases de "gerente"?

Puede que haya dos razones por las que este es un olor de código. Una razón es que puede significar que no tiene objetos de dominio, sino que tiene objetos de valor que solo almacenan datos para su manipulación por controlador o clases de administrador. En realidad, esto es bastante común y equivale a la programación de procedimientos en un lenguaje OO. Los "muchos administradores" pueden ser un indicio de que necesita integrar la lógica de estado, la validación y otras inquietudes directas en los objetos del dominio para que realmente encapsulen algo. Por supuesto, hay pistas más importantes, como el hecho de que no tiene ningún otro método que no sea el de getter / set.

La otra razón por la que el olor de un código es que puede significar que los objetos de su dominio no se relacionan entre sí muy bien. Por ejemplo, si tiene una clase de cuenta que realmente no sabe nada sobre la clase Transacción, excepto que se llama Transacción y puede haber más de una, entonces nuevamente no tiene una implementación de dominio empresarial muy dinámica. Por ejemplo, SavingsAccount debería saber que no puede aceptar un DebitTransaction si el estado de cuenta está cerrado. Muchas implementaciones dejarían esto en manos del gerente.

Tener muchas clases de "administradores" es a menudo un síntoma de un modelo de dominio anémico , donde se alza la lógica del dominio fuera del modelo de dominio y, en su lugar, colocado en clases de administrador, que más o menos equivalen a scripts de transacción . El peligro aquí es que básicamente está volviendo a la programación de procedimientos, lo que en sí mismo puede ser bueno o no dependiendo de su proyecto, pero el hecho de que no se haya considerado o intentado es la imo del "olor de código". / p>

Siguiendo el principio de "experto en información" , una operación lógica debe residir tan cerca a los datos que requiera como sea posible. Esto significaría volver a mover la lógica del dominio al modelo de dominio, de modo que estas operaciones lógicas tienen un efecto observable en el estado del modelo de dominio, en lugar de que los scripts de transacción cambien el estado del modelo de dominio desde el exterior.

El mayor problema con las Clases de Gerente es que solo representan esta vaga idea de lo que se supone que hace la clase. Si llama a un administrador, puede hacer cualquier cosa y todo lo posible en relación con lo que esté administrando. Supongo que en algunos contextos eso podría estar bien, pero diría que en casi todos los casos eso no es lo que quieres. Quiere que alguien pueda ver el nombre de la clase y no solo tener una buena idea de lo que hace la clase sino también lo que no.

Otro problema con las clases de administrador es que hace que sea muy difícil decidir dónde debe ir la funcionalidad. Cuando hay muchas clases de administrador, a menudo hay mucha superposición en la funcionalidad entre las clases de administrador. Luego, tiene que averiguar qué clase debería implementar esa funcionalidad superpuesta y, por supuesto, alguien más habría elegido de manera diferente. Entonces, cuando buscan la funcionalidad y no la ven donde esperan, entonces siguen adelante y la vuelven a implementar donde creen que pertenece porque no están conscientes de la existencia de la otra implementación. En otras palabras, las clases de administrador llevan a diseños difíciles de entender y frecuentemente complicados.