Antipatrones de diseño

Antipatrones de diseño

¿Qué es un patrón de diseño?

Antes de comenzar este artículo tenemos que hacer una mención a los patrones de diseño. Estos son soluciones recurrentes a problemas conocidos, definidos mediante 3 partes

  • Contexto: Representa el cuándo se produce el problema
  • Problema: Representa el qué, es decir, el problema que soluciona
  • Solución: Representa el cómo solucionar nuestro problema

Los patrones de diseño se clasifican en distintos grupos. Tenemos patrones de arquitectura, de diseño y de dialecto, dependiendo el tipo de problema que queremos resolver

Estos patrones obtuvieron gran popularidad a partir de la publicación del libro Design Patterns escrito por el grupo Gang of Four y bien utilizados aportan mucha calidad a nuestros productos.

Como no es objetivo de este artículo profundizar mucho en el tema, os recomendamos si teneis curiosidad en consultar el siguiente documento
http://msdn.microsoft.com/es-es/library/bb972242.aspx#XSLTsection124121120120

¿Y un antripatrón de diseño?

Tenemos que tener claro que LOS PATRONES DE DISEÑO NO SON PERFECTOS. Aunque realmente el problema está en la gente que los usa, pues a veces tendemos a tratarlos como verdades universales.

El uso indiscriminado de los patrones de Software, aún cuando el uso de ellos no aporta ningún valor a su desarrollo, se conoce como Pattern Happy, que define a programadores que aprenden un patrón y rápidamente encuentran un lugar donde abusar de él.

¿Has aprendido alguna vez algún patrón de software y quisiste usarlo en ese mismo momento, porque te gustó? ¿Mucho? Entonces eres un amante de los patrones. Los patrones no son siempre la solución adecuada o mejor para un problema.

Los antipatrones son soluciones negativas que presentan más problemas que beneficios. Es importante comprender bien estos antipatrones para conseguir identificarlos y evitarlos cuanto antes.

Los antipatrones de diseño suelen tener nombres graciosos y son detallados con mucho cinismo, lo cual es bueno porque los hace fácil de recordar.

Los antipatrones de diseño se clasifican en tres grandes grupos

  • Desarrollo de Software
  • Arquitectura de Software
  • Gestión de Proyectos de Software

A continuación mostramos una relación de sus nombres originales

Desarrollo de software Arquitectura Gestión
  • The Blob
  • Lava Flow
  • Functional Decomposition
  • Poltergeists
  • Golden Hammer
  • Spaghetti Code
  • Cut and Paste Programming
  • Continuous Obsolescence
  • Ambiguous Viewpoint
  • Boat Anchor
  • Dead End
  • Input Kludge
  • Walking through a Minefield
  • Mushroom Management
  • Stovepipe Enterprise
  • Vendor Lock-in
  • Architecture by Implication
  • Design by Committee
  • Reinvent the Wheel
  • Autogenerated Stovepipe
  • Jumble
  • Cover your Assets
  • Wolf Ticket
  • Warm Bodies
  • Swiss Army Knife
  • The Grand Old Duke of York
  • Analysis Paralysis
  • Death by Planning
  • Corncob
  • Irrational Management
  • Project Missmanagement
  • Blowhard Jamboree
  • Viewgraph Engineering
  • Fear of Success
  • Intellectual Violence
  • Smoke and Mirrors
  • Throw it over the wall
  • Fire Drill
  • The Feud
  • E-Mail is Dangerous

Caso concreto. The BLOB. El terror no tiene forma

Este antipatrón de diseño hace referencia a un objeto todopoderoso que tiene un exceso de responsabilidad y crece de manera descontrolada. Si nos basamos en el principio de única responsabilidad este objeto tiene el problema de que se encarga de muchas tareas distintas y el sistema depende completamente de él.

Los problemas que aporta este objeto son

  • El objeto es dificil de testear
  • El objeto no es reusable
  • El objeto no es fácil de hacer cambios
  • No es un enfoque orientado a objeto, sino un falso enfoque prodedimental.

Los objetos BLOG (también conocidos a veces GOD Object u objetos todopoderosos) se identifican cuando tienes objetos con muchos atributos y operaciones o cuando existen atributos que no tienen una conexión lógica o falta de cohesión.

La solución para eliminar estos objetos de nuestro sistema es la Refactorización localizando grupos de atributos y responsabilidades y agrupándolos en objetos distintos, estableciendo de forma correcta la relación entre clases.

Referencia

Comentarios

Sin comentarios
Ha habido un error en el envío
Comentario enviado. Será revisado por la moderación antes de ser publicado.

Deja tu comentario

Tu nombre:
Tu email:
Tu comentario:
Nuestra página web utiliza cookies propias y de terceros, para realizar el análisis de la navegación de los usuarios y así poder mejorar nuestros servicios. Si continúas navegando, consideramos que aceptas su uso. Puedes cambiar la configuración u obtener más información aquí