¿Pueden las clases de administrador ser un signo de mala arquitectura?

Últimamente he comenzado a pensar que tener muchas clases de gerentes en su diseño es algo malo. La idea no ha madurado lo suficiente como para hacer un argumento convincente, pero aquí hay algunos puntos generales:

• Descubrí que es mucho más difícil para mí comprender los sistemas que dependen en gran medida de los "gerentes". Esto se debe a que, además de los componentes reales del programa, también debe comprender cómo y por qué se utiliza el administrador.

• Los gerentes, muchas veces, parecen ser utilizados para aliviar un problema con el diseño, como cuando el programador no pudo encontrar una manera de hacer que el programa Just Work ^TM y tuviera que confiar en las clases de gerentes para que todo funcionara correctamente.

Por supuesto, los pesebres pueden ser buenos. Un ejemplo obvio es una EventManagerde mis construcciones favoritas de todos los tiempos. : P Mi punto es que los gerentes parecen estar sobreutilizados la mayor parte del tiempo, y por ninguna otra razón que no sea enmascarar un problema con la arquitectura del programa.

¿Son realmente las clases de gerentes un signo de mala arquitectura?

Las clases de administrador pueden ser un signo de una mala arquitectura, por algunas razones:

• Identificadores sin sentido

  El nombre FooManagerno dice nada sobre lo que la clase hace realmente , excepto que de alguna manera involucra Fooinstancias. Dar a la clase un nombre más significativo aclara su verdadero propósito, lo que probablemente conducirá a una refactorización.

• Responsabilidades fraccionarias

  Según el principio de responsabilidad única, cada unidad de código debe cumplir exactamente un propósito. Con un gerente, puede dividir artificialmente esa responsabilidad.

  Considere una ResourceManagerque coordina las vidas de las Resourceinstancias y el acceso a ellas . Una aplicación tiene un único a ResourceManagertravés del cual adquiere Resourceinstancias. En este caso, no hay una razón real por la cual la función de una ResourceManagerinstancia no pueda ser cumplida por métodos estáticos en la Resourceclase.

• Abstracción no estructurada

  A menudo, se introduce un administrador para abstraer los 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 "gerente" no ofrece pistas sobre la estructura de la abstracción que representa. ¿Es realmente una fábrica, o un proxy, o algo más?

Por supuesto, los gerentes pueden usarse para algo más que el mal, por las mismas razones. Un EventManager—que es realmente Dispatcherun— pone en cola los 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 individuo Eventes solo un mensaje sin noción de procedencia o destino.

Escribimos una Dispatcherde las Eventinstancias por esencialmente la misma razón por la que escribimos a GarbageCollectoro a Factory:

Un gerente sabe lo que su carga útil no debería saber.

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

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

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

Y luego alguien necesita implementar una clase que mantenga muchas fábricas y las entregue a varios objetos que las soliciten; y llama a su clase FactoryManagerporque la palabra Industrysimplemente nunca se le ocurrió, o pensó que sería genial porque nunca antes había escuchado algo así en programación. De nuevo, un caso de falta de imaginación.

Tener muchas clases de "administrador" es a menudo 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 transacciones . 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 haya considerado o previsto es el verdadero problema de la OMI.

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 'administradores' cambien el estado del modelo de 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 administrador es lo correcto. Un buen punto de partida para hacerlas bien es seguir el principio de responsabilidad única : si sabe exactamente de qué es responsable cada uno de los gerentes (y qué no), tendrá muchos menos problemas para comprenderlos.

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

Si bien puede ser fácil decir que son inherentemente indicativos de un mal diseño, pueden servir para aportar mucho bien y reducir la complejidad del código y otro código repetitivo en todo el proyecto al abarcar una sola tarea y responsabilidad universalmente.

Si bien la prevalencia de los gerentes puede deberse a un mal juicio sobre el diseño, también pueden ser para manejar las malas decisiones de diseño o los problemas de incompatibilidad con otros componentes en un diseño con componentes o componentes de interfaz de usuario de terceros, o servicios web de terceros con una interfaz extraña como ejemplos

Estos ejemplos demuestran dónde son terriblemente útiles para ciertas situaciones para reducir la complejidad general y promover un acoplamiento flexible entre varios componentes y capas al encapsular el "código feo" en un solo lugar. Sin embargo, un problema sería que a las personas les resulta tentador hacer que los Gerentes sean solteros, aconsejaría en contra de esto y, por supuesto, como otros han sugerido que siempre se debe seguir el Principio de Responsabilidad Única.

¿Pueden las clases de administrador ser un signo de mala arquitectura?

Respondiste tu pregunta: no tienen que ser un signo de un mal diseño.

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

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

Cuando la clase tiene "Administrador" en el nombre, tenga cuidado con el problema de la clase de Dios (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.

Dejando a un lado las malas clases de administrador, el peor nombre que he visto 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.

Las clases de manager, como casi cualquier clase que termina con "-er" , son malas y no tienen nada que ver con OOP. Entonces para mí es un signo de mala arquitectura.

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

Además de eso, típicamente tales 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 de procedimientos. Si te das cuenta de eso, no hay nada malo en las clases de Manager, pero no es OOP entonces.

El pensamiento de objetos implica que los objetos se hacen cosas a sí mismos. Descubre tu dominio , construye redes semánticas , deja que tus objetos sean organismos vivos, humanos inteligentes y responsables.

Tales objetos no necesitan ser controlados. Saben qué hacer y cómo hacerlo. Por lo tanto, las clases Manager rompen los principios OOP dos veces Además de ser una clase "-er", controla otros objetos. Pero depende del gerente sin embargo. Lo controla, es un mal gerente. Si 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 encuentre mientras escribe el software es diferente. ¿Quizás estás en un equipo donde todos saben cómo funcionan internamente las clases de mánagers? Sería 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 detalles exactos.