ANTIPATRONES DE DISEÑOSaúl Leonardo Celis Valbuena y Camila Alejandra Cardona Otálora

Ing. Julio Barón

Universidad Distrital Francisco José de CaldasBogotá, Colombia. 2012

Resumen Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. Son una extensión natural a los patrones de diseño. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores más comunes relacionados con la industria del software.

Abstract The antipatterns are negative solutions that present more problems than they solve. They are a natural extension to design patterns. To understand antipatterns provides the knowledge to try to avoid them or recover from them. The study of anti-patterns allows knowing the most common errors related to the software industry.

I. INTRODUCCIÓN

Es importante tener conocimiento de los antipatrones ya que así se podrá evitar el uso de estos al momento de diseñar el software. Un claro ejemplo de lo anteriormente expuesto es el proyecto final, ya que éste tenía evidenciados varios antipatrones pero finalmente fueron eliminados y a su vez modificados para así tener un mejor y mayor elaborado producto final.

Son varios los antipatrones de diseño, estos serán mencionados y explicados, después se mencionara el uso de los antipatrones en el proyecto final y como se resolvió el problema para mostrar la comprensión y practica de lo aprendido con respecto a los antipatrones.

II. MARCO TEÓRICO

Primero que todo es importante mostrar la comparación entre patrones y antipatrones a través de la Fig. 1.

Fig. 1.

Los antipatrones de diseño son los siguientes:

Problema del yoyoConsiste en construir estructuras demasiado largas por lo tanto difíciles de entender lo que provoca que el programador tenga que estar cambiando entre el uso de clases. Este anti-problema toma este nombre debido a que el programador requiere estar moviéndose de arriba abajo a través de todo el código como lo hace un juguete yo-yo.

PoltergeistConsiste en usar objetos cuya única funcionalidad es pasar la información a terceros objetos o también emplear métodos simplemente para llamar a otro método esto implica que el código sea más difícil de leer y que exista código innecesario.

Objeto todo poderoso (God Object)También conocido como The Blob (clases gigantes), consiste en asignar muchas funcionalidades en una única clase. Un programa estructurado suele estar dividido en varias partes. En el caso de objeto todo poderoso el asignarle todo una clase no permite tener las funcionalidades del programa dividido en varias clases.

Lava Flow (Lava Seca)Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante. Esto es análogo a un flujo de lava en el que se van endureciendo pedazos de roca. La solución incluye un proceso de gestión de la configuración que elimina el código muerto y permite evolucionar o rehacer el diseño para acrecentar la calidad.

Golden HammerEl martillo es cualquier tecnología o herramienta que según sus programadores es capaz de resolver muchos tipos de problemas y también es capaz de resolver algunos para los cuales no fueron programados, es decir asumir que la mejor solución es universalmente aplicable, haciendo bueno el refrán para un martillo, todo son clavos.

Spaghetti codeEste anti patrón consiste en la dificultad de hacer cambios o extensiones por haber perdido claridad y comprensión el código, incluso para el mismo programador.

Copy and Paste ProgrammingEste anti patrón se basa en la idea de que es más fácil coger un código que ya está hecho y funciona, que empezar con un código desde cero. Suele presentar un código con trozos de código muy parecido que suelen ser cogidos de otros programadores ms experimentados.

Navaja suizaIntentar crear un producto que solucione varios problemas poco relacionados entre sí.

Caminar por un campo de minasTrabajar con un componente pobremente probado (usualmente inestable), y por tanto poco confiable.

Fallo de clase vacía  Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que no añade modificación alguna.

Clase Gorda Dotar a una clase con demasiados atributos y/o métodos, haciéndola responsable de la mayoría de la lógica de negocio.

Botón mágico (magic pushbutton)Tender, desarrollando interfaces, a programar la lógica de negocio en los métodos de interacción, implementando los resultados de las acciones del usuario en términos no suficientemente abstractos.

A pesar de que son aun más antipatrones, se podría decir que estos son los principales.Uno de los antipatrones evidenciados en el proyecto final es el Spaghetti Code, ya que al tener muchas opciones (comboBox) fue necesario el uso de muchos if. Es muy posible que para una persona ajena al desarrollo del código le sea complicado entenderlo o encontrarle un orden, pero es necesario tenerlo de esa manera para obtener lo deseado.Otro anti patrón es el Copy and Paste Programming, ya que al tener varias subclases con comportamientos que diferían en cosas mínimas era mucho más sencillo y rápido copiar y pegarlas en todas las necesarias.El anti patrón Poltergeist también fue usado en el proyecto final, pero este se da mucho al implementar los patrones y la combinación entre ellos, ya que a veces se usan objetos cuya única funcionalidad es pasar la información a terceros objetos o también emplear métodos simplemente para llamar a otro método; en efecto el código es bastante difícil de leer para una persona que no tenga conocimiento de los patrones.El siguiente anti patrón que se usó pero se eliminó fue Lava Seca (código Muerto), en las herencias de clases abstractas se estaba declarando atributos y métodos que eran comunes a todos, y se solucionó con la herencia de una clase abstracta que generalizara eso.

III. CONCLUSIONES

Los patrones y antipatrones exponen conocimiento sobre la construcción de software que ha sido fruto de muchos expertos durante muchos años.

Al reconocer la existencia de los anti patrones y obtener una solución a ellos, se logra agilizar el desarrollo y construir software de calidad y muy flexible.

Al eliminar y/o modificar los antipatrones para obtener una solución que genere una mejora en el proyecto final, se consiguió un software mucho más elaborado.

REFERENCIAS

[1] Bouzada, Pablo. “Antipatrones de desarrollo de software”. http://www.slideshare.net/pbousan/antipatrones-de-desarrollo-de-software. [Fecha de consulta: Julio 11 de 2012]

[2] Ibarra, Horacio; Montano, Jorge. “Antipatrones de diseño”. http://www.slideshare.net/horak96/puntos-extra-antipatrones-de-diseo. [Fecha de consulta: Julio 11 de 2012]

[3] Martínez, Francisco Javier. “Guía de construcción de software con patrones de diseño”. http://es.scribd.com/doc/58703186/22/ANTIPATRONES. [Fecha de consulta: Julio 11 de 2012]

[4] Mudarra, Antonio; Lilao, Jorge; Durá, Rubén; Escrivà, Carles. “Patrones de diseño, Refactorización y Antipatrones”. http://es.scribd.com/doc/86397595/Tema-Complementario-III-AESMcooking. [Fecha de consulta: Julio 11 de 2012]

[5] Welicki, León. “Patrones y Antipatrones”. http://msdn.microsoft.com/es-es/library/bb972251.aspx. [Fecha de consulta: Julio 11 de 2012]