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

A veces escucho que tener demasiadas clases de "administrador" en el diseño de su programa es un olor a código y agrega una capa innecesaria de complejidad. Para mí, tiene sentido que las personas quieran usar clases de administrador para manipular y controlar objetos desde un contexto que tenga sentido para ellos, pero descubrir cómo hacer que una solución funcione sin ellos puede ser confuso.

¿Debería uno realmente evitar las clases de gerente tanto como sea posible? Además, ¿qué artículos / documentos debería leer sobre cómo implementar una solución alternativa para casos generales / comunes en los que estos gerentes pueden ser eliminados?

Quizás hay dos razones por las que este es un olor a 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 las clases de controlador o 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 una pista de que necesita integrar la lógica de estado, la validación y otras preocupaciones directas en los objetos de dominio para que realmente encapsulen algo. Por supuesto, hay pistas más importantes, como el hecho de que no tiene otros métodos que no sean getter / setters.

La otra razón por la que huele a código es que puede significar que los objetos de tu dominio en realidad no se relacionan entre sí muy bien. Por ejemplo, si tiene una clase de Cuenta que realmente no sabe nada acerca de 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 comercial muy vibrante. Por ejemplo, SavingsAccount debería saber que no puede aceptar una transacción de débito si el estado de la cuenta está cerrado. Muchas implementaciones dejarían esto en manos del gerente.

Tener muchas clases de "administrador" a menudo es un síntoma de un modelo de dominio anémico , donde la lógica de dominio se saca del modelo de dominio y, en su lugar, se coloca en clases de administrador, que más o menos equivalen a secuencias de comandos de transacción . El peligro aquí es que básicamente está volviendo a la programación de procedimientos, que en sí misma puede o no ser algo bueno dependiendo de su proyecto, pero el hecho de que no se consideró o pretendió es el "olor a código".

Siguiendo el principio del "experto en información" , una operación lógica debe residir lo más cerca posible de los datos que requiere. Esto significaría volver a mover la lógica de dominio al modelo de dominio, de modo que sean estas operaciones lógicas las que tengan 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 Manager es que solo representan esta vaga idea de lo que se supone que debe hacer la clase. Si llama a algo Gerente, puede hacer cualquier cosa y todo lo relacionado con lo que sea 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. Desea 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 de lo que no hace.

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 gerentes, a menudo hay mucha superposición en la funcionalidad entre las clases de gerentes. Luego debe averiguar qué clase debe 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, continúan y la vuelven a implementar donde creen que pertenece porque no son conscientes de la existencia de la otra implementación. En otras palabras, las clases de gerentes conducen a diseños difíciles de entender y con frecuencia complicados.