Descripción del anti-patrón

El diseño de aplicaciones procedimentales conlleva a construir un objeto o fichero con la mayor parte de las responsabilidades, mientras que la mayoría de los demás objetos solo contienen datos o ejecutan procesos simples. La solución a este anti-patrón incluye un refactoring del diseño para distribuir las responsabilidades de manera más uniforme y aislar el efecto de los cambios.

• Nombre del Anti-patrón: The God Class
• También conocido como: Winnebago o The Blob.
• Nombre de la Refactorización: Refactoring de Responsabilidad
• Tipo de Solución de Refactoring: Software
• Causas Raices:  Pereza,  Prisas
• Fuerzas desequilibradas: Gestión de la funcionalidad, el rendimiento y la complejidad
• Evidencia: “Esta es la clase que realmente es el corazón de nuestra arquitectura.”

Orígen del God Class

Este anti-patrón además de llamarse God Class , también es conocido c0mo The Blob (“La Masa” en español).

En la película de “La Masa”, cada vez que el monstruo se come una víctima crece. Mientras tanto, los humanos incrédulos entran en pánico e ignoran al único científico loco que sabe lo que está sucediendo. Se comen muchas más personas antes de que recuperen el sentido. Finalmente, “La Masa” consigue crecer tanto que amenaza con destruir todo el planeta.

La película es una buena analogía por que consume arquitecturas enteras orientadas a objetos.

 

 

¿Donde encontramos el anti-patrón?

El anti-patrón God Class se encuentra en diseños donde una clase monopoliza el procesamiento y otras clases simplemente encapsulan información. Este anti-patrón es caracterizado por un diagrama de clases compuesto por una gran clase compleja controladores rodeada de simples clases que encapsulan datos. El principal problema aquí es que la mayoría de las responsabilidad son situadas en esta gran clase.

En general, el anti-patrón suele ocurrir en aplicaciones procedimentales, aunque puede representarse mediante notación de objetos e implementarse en lenguajes orientados a objetos. Un diseño procedimental separa el proceso de los datos, mientras que un diseño orientado a objetos combina procesos y modelos de datos, junto con las particiones.

La God Class contiene la mayoría de los procesos, y el resto de objetos solo contienen datos. Este tipo de arquitectura separan el proceso de la información, de tal manera que emplean un estilo procedimental en una arquitectura orientada a objetos.

Este anti-patrón puede ser el resultado de una asignación de requisitos inapropiada. Por ejemplo, una God Class puede ser un módulo de software al que se le asignan demasiadas responsabilidades que se superponen a la mayoría de las otras partes del sistema para el control del sistema o la administración del sistema.

También es con frecuencia el resultado de un desarrollo iterativo en el que una simple prueba de concepto evoluciona con el tiempo en un prototipo y, finalmente, en un sistema que será productivo. Esto a menudo se ve agravado por el uso de lenguajes de programación centrados principalmente en interfaces de usuario, como Visual Basic, que permiten que una forma simple desarrolle su funcionalidad y, por lo tanto, su propósito, durante el desarrollo incremental o creación de prototipos.

La asignación de responsabilidades no se redistribuye durante la evolución del sistema, por lo que un módulo se vuelve predominante respecto al resto del sistema. La God Class a menudo viene acompañado de un código innecesario, lo que hace difícil diferenciar entre la funcionalidad útil de la clase y el código que ya no se usa

 Síntomas y Consecuencias

• Suele aparecer cuando una sola clase con un gran número de atributos, métodos o ambos. Una clase con 60 o más atributos y operaciones usualmente indica la presencia de este anti-patrón.
• Una colección dispar de atributos y operaciones no relacionados y encapsulados en una sola clase. Una falta general de cohesión de los atributos y operaciones es típica de este anti-patrón.
• Una simple clase controladora con muchas asociaciones.
• Ausencia en el diseño orientado a objetos. Un bucle principal de programa dentro de la God Class asociada con objetos de datos relativamente pasivos. La clase controlador  a menudo encapsula la funcionalidad completa de la aplicación.
• Un diseño legado que no ha sido refactorizado a una arquitectura orientado a objetos.
• Este anti-patrón compromete las ventajas de usar una arquitectura orientada a objetos. Este anti-patrón limita la capacidad de modificación del sistema sin afectar al resto de funcionalidad. Modificar la God Class implica afectar de una manera completa a todo el software.
• La God Class es típicamente muy difícil de reutilizar y probar, además de ser ineficiente y poco reutilizable la funcionalidad.
• La God Class puede ser pesada de cargar en memoria, usando excesivo recursos para operaciones simples.

Típicas Causas

• Falta de una arquitectura orientada a objetos.  Probablemente quien diseño la arquitectura no tiene los adecuados conocimientos para entender los principios de una arquitectura orientada a objetos. Alternativamente el equipo puede tener debilidad en habilidades de abstracción.
• Falta de arquitectura. La ausencia de definición de los componentes del sistema, sus interacciones y el uso especifico de herramientas o lenguajes de programación. Esto permite
• Falta de seguimiento. A veces, este anti-patrón aparece accidentalmente, incluso después de que se planificó una arquitectura razonable. Esto puede ser el resultado de una revisión arquitectónica inadecuada a medida que evoluciona el desarrollo. Esto es especialmente frecuente en equipos de desarrollo sin experiencia en orientación a objetos.
• En proyectos iterativos, los desarrolladores tienden a agregar pequeñas piezas de funcionalidad a las clases existentes, en lugar de agregar nuevas clases, o revisar y refactorizar la jerarquía de clases para una asignación de responsabilidades más efectiva.
• Desastre ya especificado. A veces, el anti-patrón resulta de la forma en que se especifican los requisitos. Si los requisitos dictan una solución de tipo procedimental, entonces se pueden hacer compromisos arquitectónicos durante el análisis de requisitos que son difíciles de cambiar. Definir la arquitectura del sistema como parte del análisis de requisitos suele ser inapropiado.

Excepciones Conocidas

Este anti-patrón puede ser aceptable cuando sirve de wrapper en sistemas legacy. No se requiere una partición del software solo una clase controladora que orqueste el sistema.

Solución Refactorizada

Como con la mayoría de los anti-patrones, la solución implica una forma de refactorización. La clave es separar el comportamiento del God Class. Puede ser apropiado reasignar el comportamiento y la responsabilidad a algunos de los objetos de datos encapsulados de forma que estos objetos sean más independiente y la God Class menos compleja.

Variaciones

A veces, en un sistema compuesto por God Classes y sus objetos de datos de soporte, se ha invertido demasiado trabajo para permitirse una refactorización total de la arquitectura. Un enfoque alternativo puede estar disponible que proporciona una solución “80%”.

En lugar de una refactorización bottom-up de toda la jerarquía de clases, es posible reducir la clase God Class de un controlador a una clase de coordinador. La God Class original administra la funcionalidad del sistema; las clases de datos se extienden con parte de su propio procesamiento.

Las clases de datos operan en la dirección de la clase coordinadora modificada. Este proceso puede permitir la retención de la jerarquía de clases original, a excepción de las migraciones de la funcionalidad de procesamiento de la God Class a algunas de las clases de datos encapsulados.

Se identifican dos formas principales del patrón. Él llama a estas dos formas: Forma de comportamiento y forma de datos

La Forma de Comportamiento es un objeto que contiene un proceso centralizado que interactúa con la mayoría de las otras partes del sistema. El formulario de datos es un objeto que contiene datos compartidos utilizados por la mayoría de los otros objetos en el sistema.

Aplicabilidad

Evitar el anti patrón puede requerir una vigilancia continua de la arquitectura para asegurar una distribución adecuada de las responsabilidades. Todos los puntos de vista dentro de la organización son importantes para la prevención inicial del anti patrón.

Es a desde un punto de vista arquitectónico donde se puede detectar este anti-patrón. Con un proceso maduro de análisis y diseño orientado a objetos, los desarrolladores pueden evitar el surgimiento de este anti-patrón.

El factor más importante es que, en la mayoría de los casos, es mucho menos costoso crear un diseño apropiado que volver a diseñar después de la implementación. La inversión inicial en buena arquitectura y educación del equipo puede garantizar un proyecto contra  la mayoría de los anti-patrones.

Este artículo trata de ser una traducción del siguiente artículo relacionado con los anti-patrones de desarrollo software: https://sourcemaking.com/antipatterns/the-blob