Anti patrones de diseño

Los antipatrones son “fórmulas literarias que describen soluciones comúnmente dadas a problemas que generan consecuencias negativas irremediablemente” según William J. Brown, coautor del libro “Antipatterns” publicado en 1999.

Los tipos de antipatrones que hay son tres: antipatrones de desarrollo de software, antipatrones de arquitectura de software y antipatrones de gestión de proyectos de software.

El estudio de los antipatrones es muy útil porque sirve para no escoger malos caminos en el desarrollo de sistemas, teniendo para ello una base documental y así evitar usar simplemente la intuición. Además proporciona una denominación común a problemas que facilita la comunicación entre diferentes desarrolladores.

Antipatrones de desarrollo de software

• The Blob

Este antipatrón se da en objetos con muchos atributos o muchas operaciones. Esto rompe las ventajas de la programación OO, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Suele aparecer por un diseño malo o debido a sistemas heredados. El tamaño de estos objetos perjudica su tiempo de carga.

Ejemplo -obtenido de http://www.antipatterns.com/briefing/ -:

 

Los métodos y atributos relacionados deben situarse en sus lugares naturales.

• Lava Flow

Este antipatrón se da cuando se entrega software antes de ser terminado o suficientemente probado que tiene un código no óptimo y al ser expuesto, sus características no pueden ser modificadas – como un flujo de lava cuando se solidifica -.

Al ser utilizado por usuarios o a partir de otros componentes, el margen de posibilidades para realizar modificaciones posteriores a su entrega es muy reducido. Si se encuentran debilidades en el diseño o en la realización, pero que permiten de todas formas su utilización, éstas probablemente no podrán ser corregidas, dado que los usuarios o las aplicaciones que utilizan el software ya se han adaptado a sus características manera de evitar este problema es fijando un alto nivel de calidad o pruebas en el software como paso previo a su distribución.

• Poltergeist

Esta mala práctica se refiere a objetos de un ciclo de vida corto cuya única función suele ser invocar métodos de otros objetos. Esto hace que crezca la dificultad para mantener el sistema. Suelen identificarse por su nombre: “start_”, “manager_”. La solución para evitarlos es eliminarlos y poner su funcionalidad en la clase a la que invocan.

• Golden Hammer

Este antipatrón se refiere al uso de una tecnología, patrón, arquitectura etc.. para cualquier problema o situación incluso cuando es evidente que no va ser útil.

• Spaghetti Code

Este antipatrón se refiere a un código mal estructurado, ausente de estructuras de control etc… Es frecuente cuando usamos GOTOs, programamos a base de interrupciones o excepciones etc. También es frecuentemente denominado “Código canguro” por lo contiguos saltos que hay que hacer en él para seguir el flujo de ejecución.

Cerca del 50% del tiempo de las operaciones de mantenimiento de este tipo de aplicaciones se invierte en descubrir como funcionan. En la programación orientada a objetos, este tipo de código es  tiene clases con muchos métodos sin parámetros, aparecen clases “extrañas”, variables globales etc…

• Magic PushButton

Esta mala práctica se da en el desarrollo de interfaces gráficas. Primero construiremos la interfaz y luego las llamadas a la lógica de negocio se realizan en los huecos de los métodos de acción de los elementos de la interfaz.

Los problemas que acarrea esta práctica son: Código asociado a cada botón crece de manera inmanejable y parte de la lógica de negocio aparece en la capa de la interfaz, crecen las dificultades para realizar cambios en la interfaz de usuario o al agregar una nueva, aumento de la dificultad para realizar pruebas, etc…

La solución a este antipatrón pasa por la creación de una sub-capa dentro de la capa de presentación que sirva “de intermediaria” con la capa de la lógica de negocio.

• Optimization Premature

Este antipatrón sucede cuando un programador permite que las consideraciones de costo en tiempo o espacio afecten el diseño de un componente de software antes de tener un diseño correcto, lo que puede resultar en un diseño más complicado que lo necesario.
Un mejor enfoque es el de diseñar primero, luego codificar el diseño y finalmente tomar en cuenta las consideraciones de costo  para decidir en que partes se debe invertir tiempo para realizar optimizaciones.

• Hard Code

Esta práctica se refiere a incrustar datos directamente en el codigo de una aplicación que deberían ser obtenidos de archivo, de la línea de comandos etc. Esto hace que cualquier cambio implique la modificación del código fuente. El ejemplo más habitual es fijar en el código el path de un fichero, si este cambia el programa no funciona. Lo correcto sería obtener la ruta de un archivo de configuración.

• Zero means null

Esto sucede cuando en una aplicación o BBDD se admite un valor como “ausencia de valor -null-” sin verificar si se va dar.
Lo correcto es usar la representación de valor nulo y de no existir, profundizar en la aplicación y en el dominio para tomar un valor que no pueda darse y tomarlo como nulo. Si no encontramos un valor para asignarlo a nulo deberemos usar otros sistemas, como booleanos, para indicar si el campo esta o no definido.

• Singleton

Muchos desarrolladores piensan que el patrón “Singleton” de GOF es en realidad un antipatrón, las razones que esgrimen son su naturaleza estática y su disponibilidad pública que permite la escritura de componentes que referencian a otros de manera poco clara. En definitiva podemos resumir:

a) Los singleton hacen que tengamos que movernos por el código para estudiar las dependencias en lugar poder saberlas viendo los interfaces de nuestras clases.
b)Los singleton permiten controlar las instancias de nuestras clases, esto no está bien porque una clase solo debe tener responsabilidades de negocio. Para controlar la creación de clases deberemos usar un patrón Factoría sobre las clases de negocio.
c)Dificulta las pruebas de código ya que promueve un alto acoplamiento.

• Dredge

Este patrón se da en los accesos a datos. Consiste en realizar una “query” muy cara -muy grande- en lugar de varias sucesivas más ligeras. Se debe realizar un estudio de complejidad temporal y espacial de la búsqueda y sus alternativas para quedarnos con la opción más óptima. -La que menos recursos consuma o la más rápida en función de nuestras necesidades o limitaciones-.

Antipatrones de arquitectura de software

• Stovepipe enterprise

Este mal se da cuando disponemos de varios sistemas aislados entre si – lo que se llama islas de automatización – y que no pueden colaborar entre si para desarrollar otros sistemas más grandes y útiles para la organización. Sucede cuando no se dispone de una planificación de los sistemas y no se ha tenido en cuenta la interoperatibilidad.
En los últimos tiempos han aparecido multitud de arquitecturas que pueden ayudar a solucionar este antipatrón como son los servicios web,E.D.A, etc…

• Stovepipe system

Este antipatrón se refiere a 2 posibles circunstancias:

a) Un sistema que no puede interoperar con el resto de los sistemas de una organización.
b) Un sistema heredado que un ensamblaje de pequeños sistemas que están tan unidos entre si que no es posible diferenciar cada uno de ellos, imposibilitando su actualización, refactorización etc… También serán de este tipo de sistemas aquellos donde no este disponible hardware de sustitución o donde se haya perdido el código original. Al final será preciso la construcción de un nuevo sistema que sustituya a este.

• Vendor Lock-In

El antipatrón “Vendor Lock-in” sucede cuando dependemos de una arquitectura, plataforma o tecnología. Esta dependencia puede tener unas consecuencias muy negativas puesto que nuestros desarrollos pueden ser dependientes de características proporcionadas por terceros, pueden verse “rotos” por el cambio de las características de estas tecnologías, etc…

Este antipatrón esta muy relacionado con el de “lava flow” porque los sucesivos cambios en plataformas hacen que tengamos porciones de código cuya única finalidad sea soportar versiones determinadas y que muchas veces no sea óptimo.

La solución para evitar estos problemas es colocar una capa de aislamiento entre nuestras aplicaciones y la plataforma de desarrollo.

 

• Big Ball of Mud

Relacionado con Spaghetti Code, nos encontramos esta mala práctica que se refiere a arquitecturas de software que son indistingibles. Suele aparecer el proyectos desarrollados como piezas independientes o desarrollados por personas sin formación en Ingeniería de Software.

• Gas Factory

En Ingeniería de Software esta mala práctica se refiere a diseños o implementaciones demasido complejos para los riquisitos de los que parten.

Antipatrones de gestión de proyectos de software

• Analysis Paralysis

Parálisis del Análisis (en inglés analysis paralysis) sucede cuando se pretende descubrir y modelar todos y cada uno de los detalles de un sistema informático en una fase inicial, invirtiendo un tiempo excesivo con la intención de no regresar a la etapa de análisis. Las dos creencias que provocan este fallo son la creencia de que se ha de codificar solo cuando se ha terminado el análisis y que una vez que hemos comenzado a codificar no se debe volver al análisis.
Frecuentemente se desarrollan proyectos no lleguen a implementar prototipos porque se ven inmersos en una constante fase de análisis.

• Corncob

Es habitual que en el desarrollo de un proyecto de un proyecto de software, ciertas personas dificulten su desarrollo. Se ha calculado que al menos la mitad del tiempo en un proceso de desarrollo de software se invierte en la comunicación entre personas. Las dificultades de comunicación son debidos al stress, a la personalidad, a la falta de preparación, negativa a recibir formación etc…

Las soluciones que se han encontrado para estas situaciones son muy variadas; desde una reducción del stress a fiestas de reconciliación, pasando por entrevistas o el clásico que apela a la responsabilidad: “el problema lo has creado tú así que es tu problema”.

• Reinvent the wheel

Este es un antipatrón obvio; en muchas ocasiones por falta de un estudio de las tecnologías, diseños o posibilidades existentes se pierde mucho dinero y tiempo desarrollando cosas que ya estaban en el mercado o que ya se encontraban disponibles.