Hay un momento muy específico en cualquier code review en el que alguien pregunta “¿por qué esto es una factory?" y la respuesta es un silencio incómodo, seguido de “porque así estaba en un ejemplo que vi”. Ese momento es la prueba de que los patrones de diseño se están usando al revés. No para resolver un problema. Para hacer parecer que se resuelve un problema.
Después de suficientes años escribiendo código en producción, uno desarrolla un radar para ello. Los patrones de diseño que sobreviven en tu repositorio sin que nadie los cuestione son los que resuelven algo real y recurrente. Los que generan discusiones eternas en el PR, los que necesitan un comentario que explique por qué existen, los que un junior copia sin entender, son casi siempre decoración. Y la decoración en código no es gratis: cuesta la lectura, cuesta el onboarding, cuesta el tiempo del próximo que tiene que tocar esa clase a las once de la noche.
Este artículo no es una lista de patrones de diseño con su definición de libro. Ya existe esa lista, la escribió el Gang of Four hace treinta años y sigue circulando como si fuera dogma. La pregunta que importa en 2026 es cuáles patrones ganan su lugar en el código y cuáles solo están ahí para que el proyecto se vea sofisticado, no cuáles patrones existen.
Strategy: el patrón de diseño que se nota cuando falta
Strategy es de los pocos patrones de diseño que casi nunca sobra. La razón es simple: resuelve un problema que aparece todo el tiempo en sistemas reales: tener múltiples formas de hacer lo mismo y necesitar cambiar entre ellas sin reescribir el que las usa.
Un ejemplo típico: un sistema de pricing que calcula descuentos distintos según el tipo de cliente, la región, o la campaña activa. Sin Strategy, esa lógica termina en un método con quince `if` anidados que crece cada vez que marketing lanza una promo nueva. Con Strategy, cada regla de descuento es su propia clase, implementa la misma interfaz, y el código que las usa no sabe ni le importa cuál está corriendo.
La señal de que Strategy vale la pena es que el comportamiento intercambiable ya existe en el dominio, no en tu cabeza. Si hoy tienes tres formas reales de calcular algo y sabes que habrá una cuarta el mes que viene, Strategy te ahorra un refactor doloroso. Si tienes una sola implementación y la envuelves en una interfaz "por si después hay otra", estás pagando el costo de la abstracción antes de necesitarla. Eso es miedo a decidir, disfrazado de patrón de diseño, no de estrategia.
Observer: para eventos que existen, no para los que imaginas
Observer tiene mala fama porque se usa mal más de lo que se usa bien. La versión correcta: hay un evento genuino en el sistema, algo pasa y varias partes del código necesitan reaccionar sin que la que dispara el evento sepa quién está escuchando. Un pedido se confirma y eso dispara una notificación, la actualización del inventario y el registro en analytics. Ninguna de esas tres cosas necesita saber de las otras. Ese es Observer haciendo su trabajo.
La versión que sobra: alguien mete un `EventEmitter` entre dos clases que en realidad tienen una relación directa y predecible, porque "así es más flexible". La flexibilidad que nadie pidió es la forma más cara de deuda técnica, porque no se ve como deuda. Se ve como buena arquitectura hasta que alguien tiene que rastrear un bug a lo largo de una cadena de eventos que salta entre seis archivos, sin ningún stack trace útil.
Los patrones de diseño basados en eventos multiplican la dificultad de debugging por diseño. Eso es aceptable cuando el desacople que compran justifica ese costo. Es una mala decisión cuando el problema real era una llamada de función directa y alguien la convirtió en una arquitectura orientada a eventos porque en el diagrama se veía mejor.
Factory: solo si la creación de objetos realmente varía
Factory es probablemente el patrón más citado y el más mal aplicado de todos los patrones de diseño clásicos. La idea original es legítima: cuando construir un objeto implica lógica no trivial, decidir entre subtipos, o depender de configuración externa, centralizar esa construcción evita duplicar la decisión en veinte lugares del código.
El problema es que Factory se convirtió en reflejo. Cualquier `new` dentro de una función activa la alarma de "esto necesita una factory" en la cabeza de alguien que leyó el libro pero no miró el contexto. El resultado es un conjunto de bases de código con `UserFactory`, `OrderFactory` y `ConfigFactory` que hacen exactamente una cosa: llamar al constructor con los mismos argumentos que recibieron. Esa capa extra no aporta abstracción real: alguien tiene que atravesarla para entender qué hace el código, sin que devuelva nada a cambio.
La pregunta que separa un Factory útil de uno decorativo es simple: ¿la lógica de construcción varía de verdad, según tipo, entorno o configuración? Si la respuesta es afirmativa, Factory asumirá el costo. Si la respuesta es "no, pero se ve más profesional así", ese código va a sobrevivir en el repositorio durante años, sin que nadie se anime a borrarlo, lo que generará la sensación de complejidad sin ninguno de sus beneficios.
Por qué el libro de patrones de diseño se convirtió en una excusa
El libro original de patrones de diseño resolvía un problema de su época: lenguajes con poco soporte para composición, sin funciones de primera clase, sin las herramientas que hoy son estándar. Muchos de esos patrones eran, básicamente, parches para las limitaciones del lenguaje. Strategy y Command, en buena medida, dejan de ser necesarios cuando el lenguaje te permite pasar funciones directamente. Un objeto Command que encapsula una sola operación es, en la mayoría de los stacks modernos, una función con mayor formalidad.
Pero el libro se volvió canon, y el canon se volvió señal de estatus. En una entrevista técnica, mencionar patrones de diseño suena a experiencia. En un code review, meter un Decorator donde alcanzaba con una función suena a rigor. El problema es que ese rigor es de cartón. No resuelve nada que no estuviera ya resuelto de forma más simple. Solo agrega capas que hay que aprender, mantener y explicar al siguiente que llega.
Un senior de verdad no se mide por cuántos patrones de diseño reconoce en el código de otro. Se mide por saber cuándo un problema no necesita ninguno. Eso es más difícil de demostrar en una entrevista de una hora, pero es lo que realmente separa la experiencia de la memorización.
La sobre-ingeniería no se ve como sobre-ingeniería
Nadie escribe código sobrecomplicado pensando "voy a sobrecomplicar esto". Se convence de que está siendo cuidadoso, previsor, profesional. Los patrones de diseño son el vehículo perfecto para ese autoengaño porque tienen nombre, tienen respaldo bibliográfico, y suenan a buena práctica incluso cuando no resuelven nada concreto.
La prueba real de un patrón de diseño es si, al sacarlo, el código se vuelve más difícil de escribir o de leer, no si aparece en el libro. Si Strategy desaparece y el código sigue igual de claro con un `if`, entonces Strategy sobraba. Si Observer desaparece y ya no hace falta rastrear eventos fantasma, Observer era el problema, no la solución. Si Factory desaparece y nadie extraña la capa intermedia, entonces Factory nunca debió existir.
Los equipos que producen código sostenible a lo largo del tiempo no son los que más patrones de diseño conocen. Son los que resisten la tentación de usarlos cuando no es necesario. Eso requiere más confianza técnica que la de aplicar el patrón, no menos. Cualquiera puede copiar una estructura del libro. Hace falta criterio real para mirar un problema simple y dejarlo simple, incluso sabiendo que existe una forma más "elegante" de complicarlo.
La posición final
Los patrones de diseño no son buenas prácticas por definición. Son herramientas, y como toda herramienta, su valor depende exclusivamente del problema que tienen enfrente. Estrategia cuando hay un comportamiento que de verdad cambia. Observer cuando ocurran eventos que realmente importan para múltiples partes del sistema. Factory cuando construir un objeto de verdad tiene lógica detrás. Fuera de esos casos, son ruido con prestigio.
La próxima vez que alguien proponga meter un patrón de diseño en una PR, la pregunta correcta es: "¿qué pasa si no lo usamos?", no "¿está bien aplicado según el libro?". Si la respuesta es "nada, el código queda igual de claro", ahí está la respuesta. El patrón no se ganó su lugar. Solo se coló.
