Python

Cinco principios de diseño

SOLID en Python

Cinco principios para que un cambio de requisito toque un solo lugar del código, en vez de media aplicación. Todos los ejemplos son de un sistema de punto de venta para un minimarket.

Avanza con → ← o con los botones de abajo.

La idea antes del código

Un minimarket bien organizado

Cada principio tiene un equivalente en cómo funciona un local. Si el local se organiza así, cambiar algo no obliga a cerrar la tienda.

Responsabilidad únicaSingle Responsibility

El cajero cobra. No hace el inventario ni la contabilidad. Si cambia la forma de hacer inventario, nadie le cambia el trabajo al cajero.

Abierto / cerradoOpen / Closed

Para aceptar un nuevo medio de pago, conectas otra máquina de tarjetas. No desarmas la caja registradora.

Sustitución de LiskovLiskov Substitution

Cualquier cajero de reemplazo puede cubrir el turno siguiendo el mismo procedimiento. Si uno no sabe dar vuelto, no es un reemplazo.

Segregación de interfacesInterface Segregation

Al proveedor de bebidas le llega el pedido de bebidas, no la lista completa de compras del local.

Inversión de dependenciasDependency Inversion

La caja se enchufa a la pared. No está soldada al cableado del edificio, así que puedes cambiarla de lugar.

Robert C. Martin reunió estos principios a partir del año 2000. Michael Feathers propuso el acrónimo SOLID unos años después.

Single Responsibility · Responsabilidad única

Una clase, una razón para cambiar

"Razón para cambiar" significa una persona o área que te puede pedir cambios. Si una clase atiende a varias, un cambio para una arriesga a las demás.

AntesDespués

class Venta:
    def __init__(self, items):
        self.items = items

    def total(self) -> int:                  # Contabilidad
        neto = sum(i.precio * i.cantidad for i in self.items)
        return round(neto * 1.19)

    def guardar(self):                       # TI
        conn = sqlite3.connect("pos.db")
        conn.execute("INSERT INTO ventas ...")

    def imprimir_boleta(self):               # SII
        print(f"BOLETA  Total: ${self.total()}")

    def enviar_email(self, correo: str):     # Marketing
        smtplib.SMTP("smtp.gmail.com").sendmail(...)

class Venta:                 # reglas de negocio
    def total(self) -> int: ...

class RepositorioVentas:     # persistencia
    def guardar(self, venta: Venta) -> int: ...

class Boleta:                # formato del documento
    def generar(self, venta: Venta) -> str: ...

class Notificador:           # avisos al cliente
    def enviar(self, venta: Venta, correo: str) -> None: ...

Antes, Venta calcula, guarda, imprime y envía correos. Cuatro áreas distintas la pueden obligar a cambiar.
Después, cada clase tiene un solo dueño. Un cambio del SII solo abre Boleta.
No se trata de que cada clase tenga un solo método, sino de que todos sus métodos cambien por el mismo motivo.

Open / Closed · Abierto / cerrado

Abierto a extender, cerrado a modificar

Agregar un comportamiento nuevo debería significar escribir código nuevo, no editar una función que ya funciona y ya está probada.

AntesDespués

def procesar_pago(metodo: str, monto: int):
    if metodo == "efectivo":
        abrir_cajon()
    elif metodo == "debito":
        transbank.cobrar(monto)
    elif metodo == "webpay":
        webpay.crear_transaccion(monto)
    else:
        raise ValueError(metodo)

from typing import Protocol

class MedioPago(Protocol):
    def cobrar(self, monto: int) -> bool: ...

class Efectivo:
    def cobrar(self, monto: int) -> bool:
        abrir_cajon()
        return True

class Webpay:
    def cobrar(self, monto: int) -> bool:
        return webpay.crear_transaccion(monto).ok

def procesar_pago(medio: MedioPago, monto: int) -> bool:
    return medio.cobrar(monto)     # no vuelve a cambiar

Antes, cada medio de pago nuevo es otro elif dentro de la misma función, y hay que volver a probar todas las ramas.
Protocol define el contrato: cualquier clase con un método cobrar(monto) sirve, sin heredar de nada.
Después, un medio nuevo es una clase nueva en su propio archivo. procesar_pago queda cerrada.

Liskov Substitution · Sustitución de Liskov

Una subclase debe poder reemplazar a su base

Si el código funciona con Producto, tiene que seguir funcionando con cualquier subclase de Producto, sin revisar de qué tipo es.

AntesDespués

class Producto:
    def descontar_stock(self, cantidad: float):
        self.stock -= cantidad

class ProductoPesable(Producto):        # respeta el contrato
    unidad = "kg"

class RecargaCelular(Producto):         # lo rompe
    def descontar_stock(self, cantidad: float):
        raise NotImplementedError("una recarga no tiene stock")

for item in carrito:
    item.producto.descontar_stock(item.cantidad)

class Vendible(Protocol):
    precio: int
    def al_vender(self, cantidad: float) -> None: ...

class Producto:
    def al_vender(self, cantidad: float) -> None:
        self.stock -= cantidad

class RecargaCelular:
    def al_vender(self, cantidad: float) -> None:
        operador.recargar(self.numero, self.precio)

for item in carrito:
    item.producto.al_vender(item.cantidad)   # todos cumplen

Antes, RecargaCelular hereda una promesa que no puede cumplir. El bucle explota a mitad de la venta.
La señal típica es una subclase que lanza NotImplementedError o un if isinstance(...) para esquivarla.
Después, el contrato es "al vender, haz lo que corresponda". Cada tipo lo cumple a su manera.

Interface Segregation · Segregación de interfaces

Nadie debería implementar lo que no usa

Una interfaz grande obliga a cada clase a escribir métodos falsos. Varias interfaces pequeñas, una por rol, dejan que cada clase implemente solo lo que hace.

AntesDespués

class DispositivoCaja(ABC):
    @abstractmethod
    def imprimir(self, texto: str): ...
    @abstractmethod
    def escanear(self) -> str: ...
    @abstractmethod
    def pesar(self) -> float: ...
    @abstractmethod
    def abrir_cajon(self): ...

class Balanza(DispositivoCaja):
    def pesar(self) -> float: return self._leer_gramos() / 1000
    def imprimir(self, texto): raise NotImplementedError
    def escanear(self): raise NotImplementedError
    def abrir_cajon(self): raise NotImplementedError

class Impresora(Protocol):
    def imprimir(self, texto: str) -> None: ...

class Cajon(Protocol):
    def abrir_cajon(self) -> None: ...

class Balanza(Protocol):
    def pesar(self) -> float: ...

class ImpresoraTermica:      # cumple Impresora y Cajon
    def imprimir(self, texto: str) -> None: ...
    def abrir_cajon(self) -> None: ...   # pulso por el puerto RJ11

class BalanzaDigital:        # cumple solo Balanza
    def pesar(self) -> float: ...

Antes, la balanza tiene que "saber imprimir". Si alguien llama a ese método, falla en producción y no al escribir el código.
Después, cada función pide solo el rol que necesita: def cobrar(cajon: Cajon).
Una clase puede cumplir varios roles. La impresora térmica abre el cajón de dinero, así que implementa los dos.

Dependency Inversion · Inversión de dependencias

Depende de abstracciones, no de detalles

La lógica de negocio no debería crear su propia base de datos. Debería recibir "algo que guarde ventas" y no saber si es SQLite, PostgreSQL o una lista en memoria.

AntesDespués

class ServicioVentas:
    def __init__(self):
        self.repo = RepoSQLite("pos.db")   # atado a SQLite

    def registrar(self, venta: Venta) -> int:
        return self.repo.guardar(venta)

class RepositorioVentas(Protocol):
    def guardar(self, venta: Venta) -> int: ...

class ServicioVentas:
    def __init__(self, repo: RepositorioVentas):
        self.repo = repo                   # recibe la abstracción

    def registrar(self, venta: Venta) -> int:
        return self.repo.guardar(venta)

# quien arma la aplicación decide la implementación
servicio = ServicioVentas(RepoPostgres(DATABASE_URL))
servicio_test = ServicioVentas(RepoEnMemoria())

Antes, para cambiar de base de datos o para testear sin base de datos hay que editar ServicioVentas.
"Inversión" significa que la flecha se da vuelta: las implementaciones dependen del contrato, y no la lógica de las implementaciones.
Pasar la dependencia por el constructor se llama inyección de dependencias. Es la forma más simple de aplicar este principio.

Pruébalo

Simulador: ¿qué se toca cuando cambia el negocio?

El mismo punto de venta escrito de dos formas. Marca los pedidos que llegan y mira qué archivos hay que abrir y cuántos tests existentes vuelves a poner en riesgo.

Pedidos del negocio

Tests existentes que vuelves a ejecutar, sumando cada cambio por separado

Practica

¿Qué principio se está rompiendo?

Cinco fragmentos de código real. Elige la letra y revisa la explicación.

El otro extremo

Cuatro formas de pasarse con SOLID

SOLID resuelve problemas de cambio. Aplicado donde no hay cambios a la vista, solo agrega archivos y saltos al leer.

1. Una interfaz para cada clase

class IUsuarioService(ABC): ...
class UsuarioService(IUsuarioService): ...   # la única implementación

Si hay una sola implementación y ningún test la reemplaza, la abstracción es ruido. Créala cuando aparezca la segunda.

2. Fragmentar hasta el absurdo

class SumadorDeNetos: ...
class AplicadorDeIVA: ...
class RedondeadorDeTotales: ...

Las tres cambian por el mismo motivo: cómo se calcula el total. Según SRP, van juntas en Venta.total().

3. Heredar para reutilizar código

class Cliente(ConexionBD): ...    # un cliente no "es" una conexión
class Cliente:
    def __init__(self, repo: RepoClientes): ...   # composición

Heredar solo para reutilizar métodos crea jerarquías que rompen LSP. Prefiere recibir el objeto que necesitas.

4. Abstraer "por si algún día"

# script de 80 líneas que corre una vez al mes
class FabricaDeExportadores(ABC): ...

Si no hay una segunda variante a la vista, escribe lo simple. Refactorizar cuando llegue el segundo caso cuesta poco.

En un backend real

SOLID en FastAPI

from typing import Protocol
from fastapi import APIRouter, Depends

class RepositorioVentas(Protocol):
    def guardar(self, venta: Venta) -> int: ...

def get_repo(session: Session = Depends(get_session)) -> RepositorioVentas:
    return RepoPostgres(session)

router = APIRouter(prefix="/ventas")       # un router por dominio

@router.post("/")
def crear_venta(datos: VentaIn,
                repo: RepositorioVentas = Depends(get_repo)):
    venta = Venta.desde(datos)             # reglas de negocio
    return {"id": repo.guardar(venta)}

# en los tests
app.dependency_overrides[get_repo] = lambda: RepoEnMemoria()

S: un APIRouter por dominio (ventas, productos, clientes) y esquemas de Pydantic separados de los modelos de la base de datos.
O: agregar un endpoint o un medio de pago es agregar un archivo, sin tocar los que ya existen.
D: Depends es inyección de dependencias. El endpoint pide un RepositorioVentas y FastAPI decide cuál entregar.
D en tests: con app.dependency_overrides reemplazas la base real por una en memoria sin editar el endpoint.
Protocol o ABC: Protocol valida la forma (tipado estructural, lo revisa mypy). ABC obliga a heredar y falla al instanciar si falta un método.

Diagnóstico rápido

¿Qué síntoma tienes?

Síntoma en tu código	Principio	Qué hacer
Cambiar el formato de la boleta rompió el cálculo del total	S	Separa la clase según quién pide los cambios.
Cada variante nueva agrega otro `elif` en la misma función	O	Define un `Protocol` y crea una clase por variante.
Hay subclases que lanzan `NotImplementedError` o código con `isinstance` para esquivarlas	L	Revisa qué promete la clase base. Muchas veces conviene composición en vez de herencia.
Clases que implementan métodos vacíos solo para cumplir la interfaz	I	Divide la interfaz en roles pequeños.
No puedes testear sin levantar la base de datos o una API externa	D	Recibe la dependencia por constructor o con `Depends`.
Un script corto que hace una sola tarea y nadie más va a tocar	—	Mantenlo simple. SOLID no aplica si no hay cambios a la vista.

Para llevarte

Resumen

SOLID no busca escribir más clases. Busca que un cambio del negocio toque un solo lugar del código.

Una razón para cambiar por clase.

Lo nuevo se agrega en código nuevo.

Las subclases cumplen lo que promete la base.

Interfaces pequeñas, una por rol.

La lógica recibe abstracciones, no las crea.

Ejercicio sugerido: toma un endpoint de un proyecto tuyo que valide datos, guarde en la base y envíe un aviso en la misma función. Sepáralo en tres clases, inyecta el repositorio con Depends y escribe un test que use un repositorio en memoria.