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 layer, y 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.