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

14

A veces escucho que tener demasiadas clases de "administradores" en el diseño de tu programa es olor a código y agrega una capa de complejidad innecesaria. 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 manager tanto como sea posible? Además, ¿qué artículos / documentos debo leer sobre cómo implementar una solución alternativa para los casos generales / comunes donde estos gerentes pueden ser eliminados?

    
pregunta Chris C 04.10.2011 - 22:28

3 respuestas

13

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.

    
respondido por el Jeremy 04.10.2011 - 23:05
4

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.

    
respondido por el MattDavey 05.10.2011 - 12:35
3

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.

    
respondido por el Dunk 05.10.2011 - 00:03

Lea otras preguntas en las etiquetas