Se trata de clases que juegan roles y responsabilidades limitadas dentro del sistema; por lo tanto, su ciclo de vida efectivo es bastante breve. Polstergeist desordena el diseño del software, creando abstracciones innecesarias; son excesivamente complejas, difíciles de comprender y difíciles de mantener.
Este antipatrón es típico en casos donde los diseñadores están familiarizados con el proceso de modelado, pero son nuevos en definición de diseños orientados a objetos y definición de arquitecturas. En este antipatrón, es posible identificar una o más apariciones de clases "fantasmales" que aparecen brevemente para iniciar alguna acción en otra clase más permanente. Akroyd llama a estas clases: "Gypsy wagons". Tipicamente, dichas clases fueron creadas como clases controller que existen sólo para invocar métodos de otras clases, usualmente, en una secuencia predeterminada. Por lo general son evidentes debido a que sus nombres tienen a menudo el sufijo _manager o _controller.
El antipatrón Poltergeistes a menudo intencional por parte de algún arquitecto "nuevo" quien realmente no comprende el concepto de orientación a objetos. Las clases Poltergeist consituyen un mal diseño por tres razones principales:
- Son innecesarias, entonces desperdician recursos cada vez que "aparecen".
- Son ineficientes ya que utilizan varias relaciones redundantes.
- Se interponen en el camino de un diseño orientado a objetos apropiado al confundir innecesariamente el modelo de objeto.
Síntomas y consecuencias
- Relaciones redundantes en la arquitectura.
- Asociaciones transitorias.
- Clases sin estado.
- Clases y objetos temporarios, de corta duración.
- Clases con una sola operación, que existe únicamente para invocar otras clases a través de asociaciones temporarias.
- Clases con nombres de operaciones de tipo "control", tales como Iniciar_Proceso_Alfa.
Causas típicas
Falta de arquitectura orientada a objetos. "Los diseñadores desconocen la orientación a objeto".
Herramienta incorrecta para el trabajo. Contrariamente a la opinión popular, un enfoque orientado a objetos no es la solución correcta para todos los trabajos. "No hay una forma correcta de hacer las cosas mal" (Anónimo). Es decir, si la orientación a objetos no es la forma correcta de hacer una tarea, no hay forma de poder implementarla correctamente.
Desastre específico. tal como en el antipatrón Blob, la gestión algunas veces compromete a la arquitectura durante el análisis de los requerimientos. Esto es inapropiado y a menudo lleva a problemas con el mencionado en este patrón.
Excepciones conocidas
No se conocen excepciones para este antipatrón.
Solución refactorizada
Los "cazafantasmas" resuelven los Poltergeist removiendo las clases de la jerarquía por completo. Luego, se debe reemplazar la funcionalidad que "proporcionaba" el Poltergeist. Esto es un simple reajuste a la arquitectura para corregirla.
La clave es mover las acciones encapsuladas dentro del Poltergeist hacia las clases relacionadas que eran invocadas.
Ejemplo
Para clarificar un poco el concepto de este antipatrón, consideremos el ejemplo de conservas de duraznos que figura a continuación:
- Posee relaciones redundantes a todas las clases en el sistema.
- Todas sus asociaciones son transitorias.
- No posee estado.
- Es una clase temporaria, de corta duración que existe sólo para invocar a otras clases a través de asociaciones temporarias.
En este ejemplo, si removemos la clase Poltergeist, las clases restantes pierden la capacidad de interactuar. No existe ningún proceso ordenado. Así, necesitamos colocar algún tipo de capacidad de interacción en la jerarquía restante. Notemos que ciertas operaciones son agregadas a cada proceso, tales como la interacción individual de clases y el procesar los resultados.
Soluciones relacionadas
El "80% de las soluciones" discutidas en el antipatrón Blob resultan de alguna manera muy similares a Poltergeist. La clase coordinator presentada aun maneja todo o mucho de la funcionalidad del sistema y típicamente exhibe muchas de las características de un poltergeist.
Aplicabilidad a otros puntos de vista y Escalas
Ocurre cuando los desarrolladores están diseñando un sistema como ellos lo implementan aunque ciertamente puede ser el resultado de un diseño inapropieado del sistema. Si este presenta evidencia que Poltergeist es realmente un caso de falla de gestión, queda en manos del lector.
Como con muchos antipatrones de desarrollo, ambos puntos de vista: arquitectónico y administrativo, juegan roles esenciales en la prevención y control contra este. Es a través de un enfoque arquitectónico que un antipatrón es reconocido ni bien comienza a emerger. Y a través de una gestión efectiva que es localizado apropiadamente cuando la prevención falla.
Los administradores deberían tener gran cuidado para asegurar que la arquitectura orientada a objeto sea evaluada por calificados arquitectos orientados a objeto tan pronto como sea posible y luego de manera continua prevenir errores de novatos como este antipatrón.
Se debe pagar el precio de la buena arquitectura por adelantado!
0 comentarios:
Publicar un comentario
Muchas gracias por leer el post y comentarlo.