Patrones de diseño

Catálogo de patrones de diseño orientado a objetos con ejemplos en C#, ilustraciones y tradeoffs honestos.

Los patrones de diseño son soluciones probadas a problemas recurrentes en el diseño orientado a objetos. No son código que copies y pegues: son recetas estructurales que adaptás a tu dominio, a tu lenguaje y a tu equipo.

Acuñados por el Gang of Four en 1994, los 23 patrones originales siguen siendo el vocabulario común para hablar de diseño de software. Saberlos no te hace un mejor programador automáticamente, pero te da un lenguaje para discutir decisiones sin dibujar diagramas en una servilleta.

#El problema

Sin patrones, cada problema recurrente se resuelve a mano y de forma distinta en cada archivo. Las clases se acoplan a quienes las crean, los if/else crecen de a poco hasta que nadie quiere tocarlos, y los nombres dejan de comunicar intención: dos desarrolladores miran el mismo código y ven dos cosas diferentes. El resultado es fricción permanente para cambios que deberían ser triviales.

#La solución

Los patrones de diseño dan estructura y nombre a las decisiones. En vez de inventar una solución para cada caso, te apoyás en una receta probada que tu equipo ya entiende. Decir "esto es un Strategy" o "acá usamos Observer" reemplaza una explicación de 30 líneas y deja claro qué se puede tocar y qué no sin romper el contrato.

#Cuándo te van a servir

  • Cuando notes que estás resolviendo el mismo problema dos o tres veces, con código apenas distinto.
  • Cuando una clase empieza a saber demasiado sobre quién la crea o quién la consume.
  • Cuando necesitás dar nombre a una decisión: "esto es un Strategy" comunica más que 30 líneas de explicación.

#Cuándo NO los uses

  • Para sentirte inteligente. Un if/else claro vence a un Visitor prematuro.
  • En código de un solo uso: scripts, prototipos, spikes.
  • Cuando el patrón te obliga a inventar abstracciones que no existen en el dominio.

#Cómo está organizado este capítulo

Los 23 clásicos están agrupados según el GoF por intención:

  • Creacionales — cómo se construyen los objetos (Singleton, Factory Method, Builder…).
  • Estructurales — cómo se ensamblan en estructuras mayores (Adapter, Decorator, Composite…).
  • Comportamiento — cómo se reparten responsabilidades y conversan (Strategy, Observer, State…).

Cuando un patrón tiene más de una forma idiomática (por ejemplo, Singleton clásico vs Singleton thread-safe), vas a encontrarlas dentro de /variants en su misma página.

#Cómo leer cada patrón

Todas las páginas siguen el mismo guion:

  1. Contexto y problema — qué situación lo motiva.
  2. Solución — la estructura de clases / colaboraciones.
  3. Ejemplo en C# — código idiomático, no académico.
  4. Cuándo NO aplicarlo — porque ningún patrón es gratis.
  5. Tradeoffs — qué ganás y qué pagás.

#Lecturas relacionadas

  • Creacionales — Cómo se crean los objetos, ocultando la lógica de instanciación.
  • Estructurales — Cómo se componen clases y objetos en estructuras más grandes y flexibles.
  • Comportamiento — Cómo interactúan los objetos y cómo se reparten responsabilidades.