Antipatrones

Un antipatrón es una mala solución de diseño, que termina llevando a una mala solución.

Para entendernos, estamos hablando de escoger una solución incorrecta para un problema, empujados por esa acuciante necesidad (que cada vez veo más a menudo) de recurrir con premura a soluciones ya implementadas porque nos encontramos con un problema ‘parecido’ a otro que en su día resolvimos de esa forma.

De momento, os dejo un pequeño extracto de los que podéis encontrar en la Wikipedia.

De Gestión:

  • Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la calidad de vida de sus empleados[…]
  • Negociador de jaula de acero (cage match negotiator): Se aplica cuando un coordinador, gestor o responsable aplica una filosofía de «éxito a cualquier precio».
  • Estrellas nacientes (rising upstart): Se aplica a quienes, teniendo potencial, no son capaces de respetar la progresión profesional establecida, y pretenden sortear los plazos y requisitos de aprendizaje y madurez.
  • Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad antes de que esté implementada.

De Diseño Software:

  • Blob: Véase Objeto todopoderoso.
  • Sistema de cañerías de calefacción (stovepipe system): Construir un sistema difícilmente mantenible, ensamblando componentes poco relacionados.
  • Acoplamiento secuencial (sequential coupling): Construir una clase que necesita que sus métodos se invoquen en un orden determinado.
  • Problema del yoyó (yo-yo problem): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación.
  • Singletonitis: Abuso de la utilización del patrón singleton.
  • YAFL (yet another layery otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

De Programación:

  • Doble comprobación de bloqueo (double-checked locking): Comprobar, antes de modificar un objeto, si es necesario hacer esa modificación, pero sin bloquear para comprobarlo, de manera que dicha comprobación puede fallar.
  • Lava seca (lava flow): 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.
  • Programación por excepción (coding by exception): Añadir trozos de código para tratar casos especiales a medida que se identifican.

Metodológicos:

  • Martillo de oro (golden hammer): Asumir que nuestra solución favorita es universalmente aplicable, haciendo bueno el refrán a un martillo, todo son clavos.
  • Reinventar la rueda (reinventing the wheel): Enfrentarse a las situaciones buscando soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar los mismos problemas.
  • Reinventar la rueda cuadrada (reinventing the square wheel): Crear una solución pobre cuando ya existe una buena.

 

Y muchos más que podéis revisar en la entrada de la Wikipedia.

Obviamente nadie está a salvo de cometer errores y acabar cayendo en alguno de los muchos que se enumeran.

Yo mismo he caído en más de uno en alguna ocasión, pero solo conociéndolos y siendo conscientes de nuestros errores podemos ponerle remedio y evitarlos en el futuro.

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.