Investigación - Antipatrones de Diseño

1. ¿Qué son?
Es un patrón de diseño que invariablemente conduce a una mala solución para un
problema. Al documentarse los antipatrones, además de los patrones de diseño, se dan
argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de
documentación disponible en lugar de simplemente la intuición.
Los antipatrones se consideran una parte importante de una buena práctica de
programación. Es decir, un buen programador procurará evitar los antipatrones siempre que
sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible,
dentro del ciclo de vida del software. El concepto de antipatrón se puede aplicar a
la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se
escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.

2. ¿Cómo documentar un antipatrón?

Al igual que los patrones, los antipatrones se documentan con el fin de asegurarse que
ninguna persona que tenga un problema similar, piense en utilizar la solución propuesta en
el antipatrón. Los elementos para su construcción son los siguientes:

 ¿Por qué la solución es atractiva/necesaria?

 ¿Por qué la solución no es la mejor a largo plazo?
 ¿Qué patrones de diseño pueden ser aplicados que pueden solucionar el problema?

Al documentar un antipatrón nos interesa obtener la siguiente información, según Head

First Design Patterns.

 Nombre: Una forma de identificar el antipatrón y poder hacer referencia a él.

 Problema: Descripción de la situación/problema actual.
 Contexto: En qué escenario se está dando la situación o problema.
 Razones: Por qué resulta atractivo el antipatrón, es decir, la justificación de la
implementación o uso del antipatrón.
 Supuesta Solución: Descripción de la solución deficiente.
 Solución Real: Descripción del proceso correcto para solucionar el problema.
 Ejemplos: Ejemplos de otros proyectos o compañías que implementaron el
antipatrón y no dio los resultados esperados.

En el libro Head First Design Patterns, nos dan un ejemplo de un antipatrón.

 Nombre: Martillo de Oro.

 Problema: Es necesario escoger tecnologías para el equipo de desarrollo y se cree
que debe existir una sola tecnología para toda la arquitectura.
  Contexto: Es necesario crear un nuevo módulo a un sistema actual que no utiliza la
tecnología definida en la arquitectura.
 Razones:
o El equipo de desarrollo solo conoce esa tecnología.
o El equipo se siente cómodo con la tecnología actual.
o Nuevas tecnologías parecen ser muy riesgosas.
o Es más fácil estimar tareas si se utiliza la tecnología actual.
 Supuesta Solución: Usar la tecnología actual, ya que el equipo la ha aplicado en
múltiples ocasiones y es el estándar de la compañía.
 Solución Real: Extender el conocimiento del equipo para adoptar nuevas
tecnologías que permitan el crecimiento profesional del equipo en general.
 Ejemplos: Compañías que utilizan sus propias versiones de manejo de mensajes
cuando existen soluciones como ApacheMQ que ya se encargan de ese tipo de
procesos.

El ejemplo anterior muestra claramente los detalles del antipatrón y nos asegura que
cualquier persona de la compañía pueda entenderlo y evitarlo en los diseños de las
aplicaciones. Existen infinidad de antipatrones, nuestro deber como profesionales de
software es identificarlos, documentarlos y sobretodo evitarlos en nuestros diseños.

3. Tipos de Antipatrones de Diseño.

Antipatrones de gestión de proyectos

 Humo y espejos (smoke and mirrors): Mostrar cómo será una funcionalidad

antes de que esté implementada.
 Mala gestión (bad management): Gestionar un proyecto sin tener suficientes
conocimientos sobre la materia.
 Software inflado (software bloat): Permitir que las sucesivas versiones de un
sistema exijan cada vez más recursos.

Antipatrones generales de diseño de software

 Base de datos como comunicador de procesos (database as an IPC): Usar

una base de datos para comunicar procesos en uno o varios ordenadores, cuando
la comunicación entre procesos directa es más adecuada.
 Blob: Véase Objeto todopoderoso.
 BOMQ (Batch Over MQ): Abuso en el empleo de integración basada en
mensajes en tiempo real para transferencias esporádicas de gran tamaño en
segundo plano.
 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.
 Carrera de obstáculos (race hazard): Incapacidad de prever las consecuencias
de diferentes sucesiones de eventos.
 Entrada chapuza (input kludge): No especificar e implementar el manejo
de entradas inválidas.
 Fábrica de combustible (gas factory): Diseñar de manera innecesariamente
compleja.
 Gran bola de lodo (big ball of mud): Construir un sistema sin estructura
definida.
 Interfaz inflada (interface bloat): Pretender que una interfaz sea tan potente
que resulta extremadamente difícil de implementar.
 Inversión de abstracción (abstraction inversion): No exponer las
funcionalidades implementadas que los usuarios necesitan, forzando a que se
reimplementen a más alto nivel.
 Punto de vista ambiguo (ambiguous viewpoint): Presentar un modelo sin
concretar ciertos aspectos, postergando así decisiones conflictivas.
 Re-dependencia (re-coupling): Introducir dependencias innecesarias entre
objetos.
 Sistema de cañerías de calefacción (stovepipe system): Construir un sistema
difícilmente mantenible, ensamblando componentes poco relacionados.
 Seguridad por ofuscación: Generar sistemas que ocultan o hacen contra
intuitivos los funcionamiento de los componentes en la entrada, en la respuesta
o en los errores. Convirtiendo las herramientas o servicios de desarrollo en cajas
mágicas.
 Integración dependiente continua: Realizar procesos de control para cada
paso del desarrollo que dependan de la validación de terceros generando una
dependencia constante entre todos los grupos de desarrollo implicados.

Antipatrones de diseño orientado a objetos

 Acoplamiento secuencial (sequential coupling): Construir una clase que

necesita que sus métodos se invoquen en un orden determinado.
 BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en
ella.
 Fallo de clase vacía (empty subclass failure): 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.
 Llamar a super (callsuper): Obligar a las subclases a llamar a un método de la
superclase que ha sido sobrescrito.
 Modelo de dominio anémico (anemic domain model): Usar un modelo del
dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a
 objetos porque cada objeto debería tener tanto propiedades como
comportamiento asociado.
 Objeto sumidero (object cesspool): Reutilizar objetos no adecuados realmente
para el fin que se persigue.
 Objeto todopoderoso (god object): Concentrar demasiada funcionalidad en una
única parte del diseño (clase).
 Poltergeist (informática): Emplear objetos cuyo único propósito es pasar la
información a terceros objetos.
 Problema del círculo-elipse (circle-ellipse problem):
Crear variables de tipo pensando en los valores de posibles subtipos.
 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 fucking layer, y otra maldita capa más) o 'Código
Lasagna': 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.

Antipatrones de programación

 Nomenclatura heroica (heroic naming): Identificar los miembros de un

programa (interfaces, clases, propiedades, métodos...) con nombres que
provocan que el conjunto aparente estandarización con la ingeniería del
software pero que en realidad oculta una implementación anárquica.
 Acción a distancia (action at a distance): Provocar la interacción no prevista
de componentes muy distantes de un sistema.
 Acumular y disparar (accumulate and fire): Establecer una colección de
variables globales para ser usadas por un conjunto de subrutinas.
 Ancla del barco (boat anchor): Retener partes del sistema que ya no tienen
utilidad.
 Bucle activo (busy spin): Utilizar espera activa cuando existen alternativas.
 Código duro (hard code): Hacer supuestos sobre el entorno del sistema en
demasiados lugares de la implementación.
 Complejidad no indispensable (accidental complexity): Dotar de complejidad
innecesaria a una solución.
 Código espagueti (spaghetti code): Construir sistemas cuya estructura es
difícilmente comprensible, especialmente debido a la escasa utilización
de estructuras de programación.
 Código ravioli (ravioli code): Construir sistemas con multitud de objetos muy
débilmente conectados.
 Comprobación de tipos en lugar de interfaz (checking type instead of
interface): Comprobar que un objeto es de un tipo concreto cuando lo único que
se necesita es verificar si cumple un contrato determinado.
 Confianza ciega (blind faith): Descuidar la comprobación de los resultados que
produce una subrutina, o bien de la efectividad de un parche o solución a un
problema.
 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.
 Fallo de caché (caching failure): Olvidar restablecer una marca de error
cuando este ya ha sido tratado.
 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.
 Lógica super-booleana (superboolean logic): Emplear comparaciones o
abstracciones de la lógica booleana innecesarias.
 Manejo de excepciones (exception handling): Emplear el mecanismo de
manejo de excepciones del lenguaje para implementar la lógica general del
programa.
 Manejo de excepciones inútil (useless exception handling): Introducir
condiciones para evitar que se produzcan excepciones en tiempo de ejecución,
pero lanzar manualmente una excepción si dicha condición falla.
 Momento del código (code momentum): Establecer demasiadas restricciones
sobre una parte del sistema debido a la asunción de muchas de sus propiedades
desde otros lugares del propio sistema.
 Números mágicos (magic numbers): Incluir en los algoritmos números
concretos sin explicación aparente.
 Ocultación de errores (error hiding): Capturar un error antes de que se
muestre al usuario, y reemplazarlo por un mensaje sin importancia o ningún
mensaje en absoluto.
 Packratting: Consumir memoria en exceso debido a no liberar objetos
reservados dinámicamente una vez ya han dejado de ser necesarios.
 Programación por excepción (coding by exception): Añadir trozos
de código para tratar casos especiales a medida que se identifican.
 Secuencia de bucle por casos (Loop-switch sequence): Programar un conjunto
de pasos secuenciales usando un bucle en combinación con una estructura de
control por casos.
 Cadenas mágicas (magic strings): Incluir cadenas de caracteres determinadas
en el código fuente para hacer comparaciones, como tipos de eventos, etc.
 Código ñoqui (gnocchi code): Incluir código que realmente no hacen nada ni
aportan al sistema. El nombre hace referencia a una festividad argentina
llamada Día del Ñoqui día o periodo (fin de mes) en el cuál, los empleados que
no hacen nada (usualmente estatales) van a cobrar.
Antipatrones metodológicos

 Bala de plata (silver bullet): Asumir que nuestra solución técnica favorita

puede resolver un problema mucho mayor.
 Desarrollo conducido por las pruebas (tester driven development): Permitir
que un proyecto software avance a base de extraer sus nuevos requisitos de los
informes de errores.
 Desfactorización (de-factoring): Eliminar funcionalidad y reemplazarla con
documentación.
 Factor de improbabilidad (improbability factor): Asumir que es improbable
que un error conocido cause verdaderos problemas.
 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.
 Optimización prematura (premature optimization): Realizar optimizaciones
sin disponer de la información suficiente para hacerlo con garantías,
sacrificando decisiones de diseño.
 Programación de copiar y pegar (copy and paste programming): Programar
copiando y modificando código existente en lugar de crear soluciones genéricas.
 Programación por permutación (programming by permutation): Tratar de
aproximarse a una solución modificando el código una y otra vez para ver si
acaba por funcionar.
 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.

Antipatrones de gestión de la configuración

 Conflicto de extensiones (extension conflict): Problemas con diferentes

extensiones que tratan de gestionar las mismas partes del sistema (específico
de Mac OS).
 Infierno de dependencias (dependency hell): Escenario de problemas
producidos por las versiones de otros productos que se necesitan para hacer
funcionar un tercero.
o Infierno DLL (DLL hell): Problemas con las versiones,
disponibilidad o proliferación de DLLs (específico de Microsoft
Windows)
o Infierno JAR (JAR hell): Problemas con diferentes versiones o
ubicaciones de ficheros JAR (Java), típicamente causados por la
falta de comprensión del modelo de carga de clases.
Antipatrones Organizacionales:

 Alcance incremental (scope creep): Permitir que el alcance de un proyecto

crezca sin el control adecuado.
 Dependencia de proveedor (vendor lock-in): Construir un sistema que
dependa en exceso de un componente proporcionado por un tercero.
 Diseño en comité (design by committee): Contar con muchas opiniones sobre
un diseño, pero adolecer de falta de una visión unificada.
 Escalada de compromiso (escalation of commitment): No ser capaz de
revocar una decisión a la vista de que no ha sido acertada.
 Funcionalitis creciente (creeping featuritis): Añadir nuevas funcionalidades al
sistema en detrimento de su calidad.
 Gestión basada en números (management by numbers): Prestar demasiada
atención a criterios de gestión cuantitativos, cuando no son esenciales o difíciles
de cumplir.
 Gestión de champiñones (mushroom management): Tratar a los empleados
sin miramientos, sin informarles de las decisiones que les afectan
(manteniéndolos cubiertos y en la oscuridad, como los champiñones).
 Gestión porque lo digo yo (management by perkele): Aplicar una gestión
autoritaria con tolerancia nula ante las disensiones.
 Migración de costes (cost migration): Trasladar los gastos de un proyecto a un
departamento o socio de negocio vulnerable.
 Obsolescencia continua (continuous obsolescence): Destinar
desproporcionados esfuerzos a adaptar un sistema a nuevos entornos.
 Organización de cuerda de violín (violin string organization): Mantener una
organización afinada y en buen estado, pero sin ninguna flexibilidad.
 Parálisis por análisis (analysis paralysis): Dedicar esfuerzos
desproporcionados a la fase de análisis de un proyecto, eternizando el proceso
de diseño iterando sobre la búsqueda de mejores soluciones o variantes.
 Peligro moral (moral hazard): Aislar a quien ha tomado una decisión a raíz de
las consecuencias de la misma.
 Sistema de cañerías (stovepipe): Tener una organización estructurada de
manera que favorece el flujo de información vertical, pero inhibe la
comunicación horizontal.
 Te lo dije (I told you so): Permitir que la atención se centre en que la desoída
advertencia de un experto se ha demostrado justificada.
 Gallina de los huevos de oro (cash cow): Pecar de autocomplacencia frente a
nuevos productos por disponer de un producto legacy muy lucrativo.

Fuentes Bibliográficas:
Antipatrón de diseño - Wikipedia, la enciclopedia libre

Antipatrones - Runnable Patterns