¿Pueden las clases del administrador ser un signo de arquitectura defectuosa?

Las clases de administrador pueden ser un signo de una arquitectura incorrecta, por varias razones:

• Identificadores sin significado

  El nombre FooManager no dice nada sobre lo que realmente hace la clase , excepto que de alguna manera involucra Foo instancias. Darle a la clase un nombre más significativo aclara su verdadero propósito, lo que probablemente llevará a una refactorización.

• Responsabilidades fraccionarias

  De acuerdo con el principio de responsabilidad única, cada unidad de código debe cumplir exactamente un propósito. Con un gerente, puede estar dividiendo artificialmente esa responsabilidad.

  Considere un ResourceManager que coordina los tiempos de vida de, y el acceso a, Resource instancias. Una aplicación tiene un solo ResourceManager a través del cual adquiere Resource instancias. En este caso, no hay ninguna razón real por la que la función de una instancia ResourceManager no pueda ser servida por métodos estáticos en la clase Resource .

• Abstracción no estructurada

  A menudo se introduce a un administrador para abstraer problemas subyacentes con los objetos que administra. Esta es la razón por la cual los gerentes se prestan al abuso como curitas para sistemas mal diseñados. La abstracción es una buena manera de simplificar un sistema complejo, pero el nombre "administrador" no ofrece pistas sobre la estructura de la abstracción que representa. ¿Es realmente una fábrica, un proxy o algo más?

Por supuesto, los gerentes pueden ser usados por más que mal, por las mismas razones. Un EventManager , que en realidad es un Dispatcher , obtiene eventos de las fuentes y los envía a los objetivos interesados. En este caso, tiene sentido separar la responsabilidad de recibir y enviar eventos, porque un Event individual es solo un mensaje sin noción de procedencia o destino.

Escribimos un Dispatcher de Event instancias por la misma razón por la que escribimos un GarbageCollector o un Factory :

Un administrador sabe lo que no debe saber su carga útil.

Creo que esa es la mejor justificación que existe para crear una clase de gerente. Cuando tienes algún objeto de "carga útil" que se comporta como un valor, debería ser lo más estúpido posible para que el sistema general permanezca flexible. Para proporcionar significado a las instancias individuales, crea un administrador que coordina esas instancias de manera significativa. En cualquier otra situación, los gerentes son innecesarios.

Los administradores pueden ser un signo de una arquitectura defectuosa, pero la mayoría de las veces no son más que un signo de una incapacidad en nombre del diseñador para encontrar mejores nombres para sus objetos, o simplemente es solo un reflejo del hecho de que el idioma inglés (y cualquier lenguaje humano para esa materia) es adecuado para comunicar conceptos prácticos de todos los días, y no conceptos altamente técnicos ni altamente abstractos.

Un ejemplo simple para ilustrar mi punto: antes de que se nombrara el Patrón de fábrica , la gente lo estaba usando, pero no sabían cómo llamarlo. Entonces, alguien que tuvo que escribir una fábrica para su clase Foo puede haberlo llamado FooAllocationManager . Eso no es mal diseño, es solo falta de imaginación.

Y luego alguien necesita implementar una clase que mantenga muchas fábricas y las distribuya a varios objetos que las soliciten; y él llama a su clase FactoryManager porque la palabra Industry simplemente nunca se le ocurrió, o pensó que sería poco cool porque nunca antes había oído hablar de algo así en la programación. Nuevamente, un caso de falta de imaginación.

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ás volviendo a la programación de procedimientos, eso en sí mismo puede ser bueno o no dependiendo de tu proyecto, pero el hecho de que no se haya considerado o intentado es el problema real.

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 del dominio, de modo que estas operaciones lógicas tienen un efecto observable en el estado del modelo del dominio, en lugar de que los 'administradores' cambien el estado del modelo del dominio desde el exterior.

Respuesta corta: depende .

Hay varias formas distintas de "clases de administrador", algunas de ellas son buenas, otras son malas, y para la mayoría de ellas depende mucho del contexto si la introducción de una clase de gerente es lo correcto. Un buen punto de partida para hacer las cosas bien es seguir el principio de responsabilidad única : si sabe exactamente en qué clase de gerente. es responsable de (y qué no), tendrá muchos menos problemas para entenderlos.

O para responder a su pregunta directamente: no es el número de clases de gerentes que indican una arquitectura defectuosa, sino que tienen demasiadas de ellas con responsabilidades poco claras o que tienen demasiadas preocupaciones.

Aunque podría ser fácil decir que son inherentemente indicativos de un mal diseño, pueden servir para aportar un montón de cosas buenas y reducir la complejidad del código y otros códigos repetitivos en todo el proyecto al abarcar una sola tarea y responsabilidad universalmente.

Si bien la prevalencia de los gerentes puede deberse a un juicio deficiente sobre el diseño, también puede ser el manejo de las decisiones de diseño deficientes o los problemas de incompatibilidad con otros componentes en un diseño con componentes o componentes de UI de terceros, o servicios web de terceros con una interfaz extraña como ejemplos.

Estos ejemplos demuestran que son terriblemente útiles para ciertas situaciones para reducir la complejidad general y promover el acoplamiento suelto entre varios componentes y capas al encapsular el "código feo" en un solo lugar. Sin embargo, se podría decir que a las personas les resulta tentador hacer Managers como singletes, recomendaría esto y, por supuesto, como otros han sugerido, siempre se debe seguir el Principio de Responsabilidad Única.

  

¿Las clases de administrador pueden ser un signo de mala arquitectura?

Usted respondió a su pregunta: no tienen que ser signos de un mal diseño.

Excepto por el ejemplo en su pregunta con el EventManager, hay otro ejemplo: en MVC patrón de diseño, el presentador puede ser visto como un administrador para las clases de modelo / vista.

Sin embargo, si hace un mal uso de un concepto, entonces es un signo de un mal diseño y posiblemente de una arquitectura.

Cuando la clase tenga "Manager" en el nombre, ten cuidado con god clase (uno con demasiadas responsabilidades). Si es difícil describir de qué es responsable una clase con su nombre, es una señal de advertencia de diseño.

Aparte de las clases de administrador incorrecto, el peor nombre que he visto en mi vida fue "DataContainerAdapter"

"Datos" debería ser otra de esas subcadenas prohibidas en los nombres; todos son datos, "datos" no te dicen mucho en la mayoría de los dominios.

Clases de administrador: como casi cualquier clase que termine con "-er" - son malvados y no tienen nada que ver con OOP. Así que para mí es un signo de mala arquitectura.

¿Por qué? El nombre "-er" implica que un diseñador de código realizó alguna acción y lo convirtió a clase. Como resultado tenemos una entidad artificial que no refleja ningún concepto tangible, sino algo de acción. Esto suena muy procedimental.

Además de eso, normalmente estas clases toman algunos datos y operan sobre ellos. Esta es una filosofía de datos pasivos y procedimientos activos y encontró su lugar en la programación procesal. Si te das cuenta de eso, no hay nada malo en las clases de Manager, pero no es OOP en ese momento.

El pensamiento de objetos implica que los objetos se hacen cosas por sí mismos. Descubra su dominio , genere redes semánticas , deje que sus objetos sean organismos vivos, seres humanos inteligentes y responsables.

Tales objetos no necesitan ser controlados. Ellos saben qué hacer y cómo hacerlo. Así que las clases de Manager rompen los principios OOP dos veces. Además de ser una clase "-er", controla otros objetos. Pero depende del gerente aunque. Él lo controla, es un mal gerente. Si él coordina, es un buen gerente. Es por eso que una letra "C" en MVC debe escribirse como "Coordinador" .

La respuesta correcta a esta pregunta es:

1. Depende.

Cada situación que encontrarás al escribir el software es diferente. ¿Tal vez estás en un equipo donde todos saben cómo funcionan internamente las clases de gerentes? Sería completamente una locura no usar ese diseño. O si está tratando de impulsar el diseño del gerente a otras personas, en cuyo caso podría ser una mala idea. Pero depende de los detalles exactos.