Patrones de diseño y arquitectura de software

📐 Fundamento

S — Single Responsibility Principle (SRP)

Una clase debe tener una sola razón para cambiar. Dicho de otro modo: una clase hace una sola cosa bien.

Violación: Una clase Pedido que además de representar el pedido también lo imprime, lo guarda en la BD y calcula el IVA.

Corrección: Pedido solo representa el pedido. PedidoRepository lo persiste. ImpresionService lo imprime. CalculadoraFiscal calcula el IVA.

O — Open/Closed Principle (OCP)

Las clases deben estar abiertas para extensión, cerradas para modificación. Se agrega funcionalidad sin modificar el código existente (usando herencia, interfaces o inyección de dependencias).

Violación: Un if/elif gigante para cada tipo de descuento. Agregar un descuento nuevo requiere modificar la función.

Corrección: Interfaz Descuento con método calcular(). Cada tipo de descuento implementa la interfaz. Para agregar uno nuevo, solo creás una nueva clase.

L — Liskov Substitution Principle (LSP)

Los objetos de una subclase deben poder reemplazar objetos de la superclase sin romper el programa. Si Pato hereda de Ave, y Ave tiene un método volar(), pero el PatoDeGoma no puede volar → violación del LSP.

I — Interface Segregation Principle (ISP)

Es mejor tener muchas interfaces específicas que una interfaz grande y genérica. Los clientes no deben depender de métodos que no usan.

Violación: Interfaz Trabajador con métodos trabajar(), comer(), dormir(). Los robots trabajadores deberían implementar solo trabajar() pero la interfaz los obliga a implementar los tres.

D — Dependency Inversion Principle (DIP)

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones (interfaces).

Violación: PedidoService crea instancias de MySQLRepository directamente → imposible hacer pruebas sin una BD real.

Corrección: PedidoService depende de IPedidoRepository. MySQLRepository implementa esa interfaz. Se puede inyectar un MockRepository en las pruebas.

📐 Fundamento

Patrones creacionales:

1. Factory Method

Problema: La clase A necesita crear objetos de tipo B, pero no sabe qué subtipo exacto de B crear.

Solución: Delegar la creación a un método fábrica que las subclases pueden sobreescribir.

class PlatilloFactory:
    @staticmethod
    def crear(tipo: str) -> Platillo:
        if tipo == "pupusa":
            return Pupusa()
        elif tipo == "ensalada":
            return Ensalada()
        raise ValueError(f"Tipo desconocido: {tipo}")

2. Singleton

Problema: Solo debe existir una instancia de una clase (ej: conexión a la BD, configuración global).

Solución: La clase controla su propia instanciación.

class ConfiguracionApp:
    _instancia = None

    @classmethod
    def get_instancia(cls):
        if cls._instancia is None:
            cls._instancia = cls()
        return cls._instancia

Patrones estructurales:

3. Adapter

Convierte la interfaz de una clase en otra que el cliente espera. Es el "adaptador de enchufes" del software.

4. Decorator

Agrega funcionalidad a un objeto dinámicamente, sin modificar su clase. Alternativa flexible a la herencia.

class PedidoPrioridad:
    def __init__(self, pedido: Pedido):
        self._pedido = pedido

    def calcular_total(self):
        return self._pedido.calcular_total() + 5.00  # Cargo extra por prioridad

Patrones de comportamiento:

5. Observer (Publicador-Suscriptor)

Cuando un objeto cambia de estado, notifica automáticamente a todos los objetos que dependen de él.

class Pedido:  # Publisher
    def __init__(self):
        self._observers = []

    def suscribir(self, obs): self._observers.append(obs)

    def cambiar_estado(self, nuevo_estado):
        self.estado = nuevo_estado
        for obs in self._observers:
            obs.actualizar(self)

class PantallaCocinoa:  # Subscriber
    def actualizar(self, pedido):
        print(f"Pedido #{pedido.id} ahora: {pedido.estado}")

6. Strategy

Define una familia de algoritmos, encapsula cada uno y los hace intercambiables.

class CalculadoraDescuento:
    def calcular(self, subtotal): ...

class DescuentoFestivo(CalculadoraDescuento):
    def calcular(self, subtotal): return subtotal * 0.85  # 15% off

class SinDescuento(CalculadoraDescuento):
    def calcular(self, subtotal): return subtotal

class Pedido:
    def __init__(self, estrategia: CalculadoraDescuento):
        self.estrategia = estrategia

    def total_con_descuento(self, subtotal):
        return self.estrategia.calcular(subtotal)

7. Template Method

Define el esqueleto de un algoritmo en una superclase, dejando que las subclases sobreescriban pasos específicos.

📐 Fundamento

Arquitectura en capas (N-Tier):

La más clásica y enseñada:

┌──────────────────────────────────┐
│   Capa de Presentación           │  (UI: HTML, React, Android, etc.)
├──────────────────────────────────┤
│   Capa de Lógica de Negocio      │  (Services, Use Cases)
├──────────────────────────────────┤
│   Capa de Acceso a Datos         │  (Repositories, DAO)
├──────────────────────────────────┤
│   Base de Datos                  │  (MySQL, PostgreSQL, MongoDB)
└──────────────────────────────────┘

Regla: cada capa solo habla con la capa inmediatamente adyacente. La capa de presentación nunca habla directamente con la base de datos.

MVC — Model View Controller:

El patrón más usado en frameworks web (Django, Rails, Laravel, Spring MVC):

• Model: Los datos y la lógica de negocio (Pedido, Platillo, repositorios).
• View: La presentación al usuario (HTML, JSON).
• Controller: Recibe la solicitud del usuario, coordina el Model y devuelve la View.

Flujo: User → Controller → Model → Controller → View → User

Variantes:

• MVP (Model-View-Presenter): El Presenter hace todo el trabajo; la View es "tonta". Común en Android (pasado).
• MVVM (Model-View-ViewModel): El ViewModel expone datos como observables. La View se "auto-actualiza". Común en aplicaciones modernas (Vue.js, SwiftUI, Jetpack Compose).

Microservicios:

En lugar de un monolito único, el sistema se divide en servicios pequeños e independientes, cada uno con su propia base de datos y desplegable por separado.

Ventajas: escalabilidad independiente, tecnología heterogénea, despliegues independientes. Desventajas: complejidad operacional, comunicación de red (latencia, fallos), distributed tracing.

Para sistemas universitarios (ADS415): Empezad con monolito en capas. Microservicios son para organizaciones con cientos de desarrolladores. No es el problema de La Esquina.