SOLID sin dogma

Código en:JavaC#PythonJavaScript

En resumen: SOLID son cinco principios para un código que sobrevive a los cambios: una sola razón para cambiar, ampliar sin modificar, subtipos sustituibles, interfaces pequeñas y dependencia de abstracciones.

Problema

El cambio del correo que rompió la contabilidad

La tienda online envía al cliente una factura por correo. Cada noche también entrega a contabilidad un archivo con una línea por pedido. Una sola clase hace las dos cosas:

from dataclasses import dataclass


@dataclass
class Order:
    number: str
    customer: str
    net: float

class InvoiceService:
    def vat(self, order):
        return order.net * 0.20

    # Contabilidad: una línea para el archivo que importa en su programa.
    def export_line(self, order):
        total = order.net + self.vat(order)
        return f"{order.number};{self._money(order.net)};{self._money(self.vat(order))};{self._money(total)}"

    # El cliente: el texto del correo con la factura.
    def email_text(self, order):
        total = order.net + self.vat(order)
        return f"Hola, {order.customer}! Pedido {order.number}: {self._money(total)} €"

    def _money(self, amount):
        return f"{amount:.2f}"

invoices = InvoiceService()
order = Order("2026-0142", "María", 80)
print(invoices.export_line(order))
print(invoices.email_text(order))

Salida

2026-0142;80.00;16.00;96.00
Hola, María! Pedido 2026-0142: 96.00 €

Marketing dice: «En el correo, pon 96 €, no 96,00 €. Se ve más limpio.» Alguien cambia el método auxiliar método _money:

def _money(self, amount):
    if amount == int(amount):
        return str(int(amount))
    return f"{amount:.2f}"

Salida

2026-0142;80;16;96
Hola, María! Pedido 2026-0142: 96 €

El correo queda como querían. A la mañana siguiente el programa de contabilidad rechaza el archivo: espera 80.00 y recibe 80. Nadie tocó la línea de contabilidad. Lo que cambió es el método auxiliar que comparten las dos líneas. La prueba del correo pasa, y no hay prueba del archivo, porque «nadie lo cambió».

La idea

Una sola razón para cambiar

La clase atiende a dos partes que no se conocen. La contable necesita un formato exacto que lee su programa. Marketing quiere un texto agradable para el cliente. Piden cambios en momentos distintos y por razones distintas. Mientras su código viva en una sola clase, un cambio para uno puede romper al otro.

Este es el primero de los cinco principios SOLID (reunidos por Robert Martin; el nombre sale de sus iniciales). El Single Responsibility Principle (SRP): una clase tiene una sola razón para cambiar.

«Razón» significa quién pide el cambio: una persona, un departamento, una ley. No significa «un método», y no significa «una clase pequeña». La pregunta que debes hacerte: «¿Quién vendrá a pedir un cambio aquí?» Si la respuesta es «contabilidad o marketing», son dos clases.

Míralo

Cada uno tiene su propia clase

El IVA y el total son una regla de la ley fiscal, y las dos partes los necesitan. Van al pedido, en un solo lugar:

from dataclasses import dataclass


@dataclass
class Order:
    number: str
    customer: str
    net: float

    def vat(self):
        return self.net * 0.20

    def total(self):
        return self.net + self.vat()

La línea de contabilidad y el texto del correo se convierten en clases separadas. Cada una da formato a los importes a su manera:

class AccountingExport:
    def line(self, order):
        return f"{order.number};{order.net:.2f};{order.vat():.2f};{order.total():.2f}"


class InvoiceEmail:
    def text(self, order):
        return f"Hola, {order.customer}! Pedido {order.number}: {self._money(order.total())} €"

    def _money(self, amount):
        if amount == int(amount):
            return str(int(amount))
        return f"{amount:.2f}"

order = Order("2026-0142", "María", 80)
print(AccountingExport().line(order))
print(InvoiceEmail().text(order))

Salida

2026-0142;80.00;16.00;96.00
Hola, María! Pedido 2026-0142: 96 €

El correo tiene importes enteros, y el archivo sigue con dos decimales. Mañana contabilidad cambiará el formato, y tocarás solo AccountingExport. El código del correo ni siquiera está delante de ti.

Las dos formas de escribir un importe ya no se comparten. Eso no es duplicación: hoy se parecen, pero son dos reglas que cambian por razones distintas.

Cuándo duele. El otro extremo es una clase para cada acción: VatCalculator, TotalCalculator, NumberFormatter, GreetingBuilder, tres líneas cada una. Siempre cambian juntas, porque las pide la misma persona, y abres cuatro archivos para leer una regla. Una clase de 200 líneas que atiende a una persona es mejor que cinco clases que siempre abres juntas. Lo que cambia junto se queda junto.

Más precisamente, para curiosos

• El propio Robert Martin escribe que «una responsabilidad» suele leerse como «hace una sola cosa». Su aclaración posterior es que un módulo responde ante un actor: un grupo de personas que piden cambios. «Hace una sola cosa» es una regla para funciones, no para clases.
• «Don't repeat yourself» (DRY) trata del conocimiento, no del texto. Dos trozos de código que se parecen pero cambian por razones distintas no son duplicación. Si los fundes en un método auxiliar, atas a dos personas con un mismo nudo. Eso es justo lo que pasó en el problema.

Pruébalo

Quién pide el cambio

1. ¿Qué pregunta te dice si una clase tiene una sola razón para cambiar?

¿Cuántas personas, departamentos o reglas distintas pedirían un cambio en ella?¿Tiene menos de 100 líneas?¿Tiene un solo método público?

2. ShippingLabel calcula el precio del envío (lo pide ventas), dibuja la etiqueta (el formato es de la empresa de mensajería) y escribe la línea del almacén (la pide el almacén). ¿Cómo lo organizas?

Una clase por cada método y por cada método auxiliarTres clases, una por cada parte que pide cambiosLo dejo así: todo trata del envío

Comprobar

Míralo

Un envío nuevo sin tocar el total

El segundo principio es abierto/cerrado (Open/Closed Principle, OCP): el código está abierto a la ampliación y cerrado a la modificación. Una variante nueva llega como código nuevo, y el código que ya funciona y está probado no se toca.

Lo viste en la lección Strategy: la cadena de if para el método de pago se convirtió en una tabla nombre → estrategia. Con los envíos pasa igual. Cada envío conoce su precio:

def to_address(amount):
    return 0 if amount >= 100 else 5.90


def to_office(amount):
    return 3.90

El total no sabe qué envíos existen:

def order_total(amount, delivery):
    return amount + delivery(amount)

La tienda añade el envío a un casillero de paquetes. Es una función nueva:

def to_locker(amount):
    return 2.90

order_total, el envío a un domicilio y a una oficina no se tocan. Falta poner el envío nuevo en la tabla de la que elige el cliente. Esa es la siguiente tarjeta.

Cuándo duele. No puedes cerrar el código contra todo, y no deberías. Cada punto de extensión es una función y una fila en una tabla que alguien tiene que leer. Cierras donde los cambios llegan de verdad: cada temporada llegan envíos nuevos. La regla práctica: la primera vez, escribe un if. Cuando llegue la tercera variante, haz la tabla (Replace Conditional with Polymorphism, de la lección sobre refactorización).

Pruébalo

Una fila nueva en la tabla

La tabla de la lección Strategy enumera los envíos entre los que elige el cliente. Añade el casillero.

¿Qué va en el hueco?

DELIVERIES = {
    "domicilio": to_address,
    "oficina": to_office,
    "casillero": ,
}

for choice, delivery in DELIVERIES.items():
    print(f"{choice}: {order_total(80, delivery):.2f} €")

Comprobar

Problema

La cancelación que se detuvo a medias

Una clienta paga un pedido de tres formas: 60 € con tarjeta, un cupón de 20 € y 16 € en puntos. Después lo cancela. Cada tipo de pago sabe cómo devolver su dinero:

from abc import ABC, abstractmethod
from dataclasses import dataclass


class Payment(ABC):
    @abstractmethod
    def refund(self):
        """Devuelve el dinero al cliente por el mismo medio con el que pagó."""


@dataclass
class CardPayment(Payment):
    amount: float

    def refund(self):
        print(f"Tarjeta: devueltos {self.amount:.2f} €")


@dataclass
class VoucherPayment(Payment):
    amount: float

    def refund(self):
        raise NotImplementedError("un cupón no se puede devolver")


@dataclass
class PointsPayment(Payment):
    amount: float

    def refund(self):
        print(f"Puntos: devueltos {self.amount:.2f} €")

El pedido recorre sus pagos y llama a refund() en cada uno:

class Order:
    def __init__(self, payments):
        self.payments = payments
        self.status = "pagado"

    def cancel(self):
        for payment in self.payments:
            payment.refund()
        self.status = "cancelado"

order = Order([
    CardPayment(60),
    VoucherPayment(20),
    PointsPayment(16),
])
try:
    order.cancel()
except NotImplementedError as e:
    print(f"Error: {e}")
print(f"Estado: {order.status}")

Salida

Tarjeta: devueltos 60.00 €
Error: un cupón no se puede devolver
Estado: pagado

La tarjeta está devuelta, los puntos no, y el pedido sigue «pagado». El almacén ve «pagado» y envía el paquete. El código de cancel() es correcto. El fallo está en el cupón: es un Payment, pero no hace lo que Payment promete.

Míralo

El subtipo que rompe la promesa

def cancel(self):
    for payment in self.payments:
        payment.refund()
    self.status = "cancelado"

order = Order([
    CardPayment(60),
    VoucherPayment(20),
    PointsPayment(16),
])
try:
    order.cancel()
except NotImplementedError as e:
    print(f"Error: {e}")
print(f"Estado: {order.status}")

Paso a paso, en palabras

1. El pedido se pagó de tres formas: 60.00 € con tarjeta, un cupón de 20.00 € y 16.00 € en puntos. Los tres son Payment.
2. La clienta cancela. cancel() recorre los pagos y llama a refund() en cada uno.
3. La tarjeta devuelve 60.00 €. Hace exactamente lo que promete Payment.
4. El cupón también es un Payment, pero su refund() lanza NotImplementedError. La promesa está rota.
5. La excepción sale del bucle y de cancel(). Los puntos (16.00 €) no se devuelven, y la línea que pone status en «cancelado» nunca se ejecuta.
6. El except en el programa la atrapa y imprime el error. El programa sigue.
7. El estado sigue siendo «pagado». El almacén envía el pedido, y 60.00 € ya están de vuelta en la tarjeta.

Este es el tercer principio, el principio de sustitución de Barbara Liskov (Liskov Substitution Principle, LSP): donde el código trabaja con un tipo, cualquier subtipo puede ocupar su lugar, y el código no lo nota. El subtipo puede hacer el trabajo a su manera, pero cumple la promesa del tipo.

Payment promete «devuelvo el dinero al cliente». ¿Qué significa eso para un cupón en una tienda de verdad? Un cupón nuevo por el mismo importe:

@dataclass
class VoucherPayment(Payment):
    amount: float

    def refund(self):
        print(f"Cupón: nuevo cupón por {self.amount:.2f} €")

order = Order([
    CardPayment(60),
    VoucherPayment(20),
    PointsPayment(16),
])
try:
    order.cancel()
except NotImplementedError as e:
    print(f"Error: {e}")
print(f"Estado: {order.status}")

Salida

Tarjeta: devueltos 60.00 €
Cupón: nuevo cupón por 20.00 €
Puntos: devueltos 16.00 €
Estado: cancelado

cancel() no cambió. Ahora el subtipo encaja donde se espera el tipo.

Reconoces una violación por tres señales:

• el subtipo lanza «no soportado» (NotImplementedError) en un método que el tipo promete;
• el subtipo devuelve algo que el tipo no promete (-1, None, una cadena vacía), o le exige más a quien llama;
• el código comprueba con isinstance antes de llamar al método. Es un rodeo alrededor de un subtipo que no encaja.

El lenguaje no ve ninguna de las tres, y sin una interfaz en Python la promesa vive solo en el nombre del método y en el comentario. Por eso hay que escribirla y comprobarla con una prueba.

Cuándo duele. Aquí el dogma va en la otra dirección: meter algo a la fuerza en la jerarquía porque «también es un pago». Si algo de verdad no puede devolver dinero (un regalo de la tienda, por ejemplo), no es un Payment con refund. Dale su propio tipo en lugar de escribir un método que lanza.

Más precisamente, para curiosos

Python es cuidadoso aquí. Las listas y las tuplas no son subtipos una de otra, y el módulo collections.abc divide el contrato en dos: Sequence (lee) y MutableSequence (también cambia). Una tupla es solo la primera:

from collections.abc import MutableSequence, Sequence

items = ("café", "taza")
print(isinstance(items, Sequence), isinstance(items, MutableSequence))

Salida

True False

Por eso el código que solo necesita leer pide una Sequence, y una tupla encaja sin mentir. Ese es también el siguiente principio: contratos pequeños.

Formalmente, según Liskov: un subtipo no pide más que el tipo (no endurece las condiciones de entrada), no da menos (no debilita la promesa sobre el resultado) y conserva lo que siempre es cierto para el tipo.

Pruébalo

La violación silenciosa

El envío a un casillero devuelve -1 cuando el casillero está lleno. El total lo suma, como siempre. ¿Qué imprime el programa?

def to_locker(full):
    def cost(amount):
        if full:
            return -1  # -1 significa «no hay sitio»
        return 2.90
    return cost


print(f"{order_total(80, to_locker(True)):.2f} €")

Respuesta

82.90 €

79.00 €

Error: no hay sitio

Comprobar

Problema

El SMS que nunca salió

La tienda envía avisos a los clientes. Alguien describió en un solo lugar todo lo que se puede enviar:

from abc import ABC, abstractmethod


class Notifier(ABC):
    @abstractmethod
    def email(self, to, text):
        pass

    @abstractmethod
    def sms(self, phone, text):
        pass

El proveedor de correo solo envía correos, pero la clase abstracta pide también sms. Sin él, MailProvider() se detiene con un TypeError, así que alguien lo escribió.

Pruébalo

Encuentra el error

El cliente recibe un correo de que el paquete salió. El SMS del mensajero nunca llega:

notifier = MailProvider()
notifier.email("maria@example.com", "El pedido 2026-0142 ha sido enviado.")
notifier.sms("0888 123 456", "El mensajero llega hoy entre las 14 y las 16 h.")

Salida

Correo a maria@example.com: El pedido 2026-0142 ha sido enviado.

¿En qué línea está el error?

Elige la línea con el error.

1class MailProvider(Notifier):2 def email(self, to, text):3 print(f"Correo a {to}: {text}")45 def sms(self, phone, text):6 pass

Comprobar

Míralo

Interfaces pequeñas

El cuarto principio: segregación de interfaces (Interface Segregation Principle, ISP). Nadie debe depender de métodos que no usa. El contrato se escribe desde el lado de quien lo usa, y es tan grande como lo necesita.

En Python un contrato pequeño se escribe con typing.Protocol: «algo con un método sms». Los proveedores no heredan nada. Encaja cualquier objeto que tenga el método:

from typing import Protocol


class EmailSender(Protocol):
    def email(self, to: str, text: str) -> None: ...


class SmsSender(Protocol):
    def sms(self, phone: str, text: str) -> None: ...

Cada proveedor hace solo lo que sabe, y el aviso del mensajero pide solo SMS:

class MailProvider:
    def email(self, to, text):
        print(f"Correo a {to}: {text}")


class SmsGateway:
    def sms(self, phone, text):
        print(f"SMS a {phone}: {text}")


class ShippingNotice:
    def __init__(self, sender: SmsSender):
        self.sender = sender

    def courier_today(self, phone):
        self.sender.sms(phone, "El mensajero llega hoy entre las 14 y las 16 h.")

email = MailProvider()
email.email("maria@example.com", "El pedido 2026-0142 ha sido enviado.")
ShippingNotice(SmsGateway()).courier_today("0888 123 456")

Salida

Correo a maria@example.com: El pedido 2026-0142 ha sido enviado.
SMS a 0888 123 456: El mensajero llega hoy entre las 14 y las 16 h.

Si alguien pasa el proveedor de correo donde hace falta un SMS, el programa se detiene en la primera llamada en lugar de quedarse callado:

try:
    ShippingNotice(MailProvider()).courier_today("0888 123 456")
except AttributeError as e:
    print(f"AttributeError: {e}")

Salida

AttributeError: 'MailProvider' object has no attribute 'sms'

Python mismo no comprueba un Protocol en tiempo de ejecución. Un verificador de tipos como mypy ve el error antes de ejecutar: MailProvider no tiene sms, y el parámetro quiere un SmsSender.

Las interfaces pequeñas también ayudan a las pruebas: el doble del aviso implementa un método, no todo lo que la tienda puede enviar.

Cuándo duele. Una interfaz por cada método «por ISP» es el otro extremo: Readable, Writable, Deletable, Countable delante de un repositorio que se usa en un solo sitio y siempre entero. Si todos los que usan el contrato lo usan todo, es un solo contrato.

Problema

La prueba que envía un correo de verdad

La factura sale por correo. El servicio crea su propio mailer:

class SmtpMailer:
    def send(self, to, text):
        print(f"SMTP a {to}: {text}")


class InvoiceService:
    def __init__(self):
        self.mailer = SmtpMailer()

    def issue(self, order, email):
        total = order.total()
        text = f"Factura {order.number}: {total:.2f} €"
        self.mailer.send(email, text)

order = Order("2026-0142", "María", 80)
InvoiceService().issue(order, "maria@example.com")

Salida

SMTP a maria@example.com: Factura 2026-0142: 96.00 €

Funciona, pero:

• la prueba de la factura envía un correo de verdad, y en una máquina sin servidor SMTP falla;
• la tienda pasa de SMTP a un servicio con API, y editas la clase con las reglas de la factura para cambiar el mailer.

La regla (qué va en la factura) depende del detalle (cómo sale el correo).

Míralo

La abstracción pertenece a la regla

El quinto principio: inversión de dependencias (Dependency Inversion Principle, DIP). El código con las reglas no depende de los detalles. Ambos dependen de una abstracción, y ella pertenece a las reglas: dice qué necesitan («envía este texto a esta dirección»), no cómo lo hace SMTP.

from abc import ABC, abstractmethod


class InvoiceSender(ABC):
    @abstractmethod
    def send(self, to, text):
        pass


class InvoiceService:
    def __init__(self, sender: InvoiceSender):
        self.sender = sender

    def issue(self, order, email):
        total = order.total()
        text = f"Factura {order.number}: {total:.2f} €"
        self.sender.send(email, text)

Los detalles van aparte. El mailer y el doble de prueba heredan la abstracción del servicio:

class SmtpSender(InvoiceSender):
    def send(self, to, text):
        print(f"SMTP a {to}: {text}")


class FakeSender(InvoiceSender):
    def __init__(self):
        self.sent = []

    def send(self, to, text):
        self.sent.append(f"{to} | {text}")

order = Order("2026-0142", "María", 80)
smtp = InvoiceService(SmtpSender())
smtp.issue(order, "maria@example.com")

fake = FakeSender()
service = InvoiceService(fake)
service.issue(order, "maria@example.com")
print(f"La prueba vio: {fake.sent[0]}")

Salida

SMTP a maria@example.com: Factura 2026-0142: 96.00 €
La prueba vio: maria@example.com | Factura 2026-0142: 96.00 €

class InvoiceSender(ABC):
    @abstractmethod
    def send(self, to, text):
        pass


class InvoiceService:
    def __init__(self, sender: InvoiceSender):
        self.sender = sender

    def issue(self, order, email):
        total = order.total()
        text = f"Factura {order.number}: {total:.2f} €"
        self.sender.send(email, text)


class SmtpSender(InvoiceSender):
    def send(self, to, text):
        print(f"SMTP a {to}: {text}")


order = Order("2026-0142", "María", 80)
smtp = InvoiceService(SmtpSender())
smtp.issue(order, "maria@example.com")

fake = FakeSender()
service = InvoiceService(fake)
service.issue(order, "maria@example.com")
print(f"La prueba vio: {fake.sent[0]}")

Paso a paso, en palabras

1. Antes las facturas apuntaban hacia abajo, a SmtpMailer. Ahora el servicio anota lo que necesita: InvoiceSender, junto a sí mismo.
2. InvoiceService recibe el envío en el constructor y solo conoce InvoiceSender. De SMTP no sabe nada.
3. SmtpSender implementa el InvoiceSender del servicio. La flecha del código apunta hacia arriba: el detalle depende de la regla. Esa es la inversión.
4. En ejecución la llamada sigue yendo hacia abajo: del servicio a SMTP. Lo que se invierte es la dependencia en el código, no la dirección de la llamada.
5. En la prueba el mismo servicio recibe FakeSender: un segundo detalle que apunta a la misma abstracción. No sale ningún correo: el doble anota en sent lo que recibió.
6. La prueba ve exactamente el texto de la factura, sin servidor de correo.

La «inversión» es la de la flecha en el código. Antes, las facturas conocían SMTP. Ahora SMTP conoce InvoiceSender, que está junto a las facturas. En ejecución, la llamada sigue yendo de las facturas a SMTP.

DIP y DI. En la lección Singleton e inyección de dependencias viste pasar desde fuera: el objeto recibe su dependencia en el constructor. Ese es el mecanismo. DIP dice de qué depender: de una abstracción que es tuya. Puedes tener una sin la otra:

• pasar sin DIP: el servicio recibe el mailer desde fuera, pero su archivo sigue importando from mail import SmtpMailer y llama a algo que solo tiene SMTP;
• DIP sin una biblioteca de DI: en el programa, InvoiceService recibe SmtpSender, y ese es todo el cableado. Hay un solo lugar donde el programa junta los objetos.

Cuándo duele. Una interfaz delante de cada clase «por DIP» es el dogma más común. Una abstracción vale la pena delante de un detalle lento, externo o que va a cambiar: correo, pago, base de datos, reloj, red. Delante de Order o delante del formato de un importe es código que leer sin beneficio.

Más precisamente, para curiosos

Con ABC, el mailer hereda InvoiceSender y lo importa: la flecha hacia la abstracción se ve. Con typing.Protocol, SmtpSender no sabe nada del contrato, y la dependencia del detalle hacia la abstracción desaparece. El verificador de tipos (mypy) comprueba la forma antes de ejecutar.

Pruébalo

Pon la prueba en orden

La prueba comprueba la factura sin un mailer real. El order ya existe. Pon las líneas en orden:

1. service = InvoiceService(fake)↑↓
2. fake = FakeSender()↑↓
3. print(f"La prueba vio: {fake.sent[0]}")↑↓
4. service.issue(order, "maria@example.com")↑↓

Comprobar

En resumen

Cuando SOLID duele

Aquí está el IVA, escrito «según todas las reglas»:

from abc import ABC, abstractmethod


class TaxPolicy(ABC):
    @abstractmethod
    def vat(self, net):
        pass


class StandardVat(TaxPolicy):
    def vat(self, net):
        return net * 0.20


def create_tax_policy():
    return StandardVat()

print(f"IVA: {create_tax_policy().vat(80):.2f} €")

Salida

IVA: 16.00 €

Y lo mismo sin dogma:

VAT_RATE = 0.20

print(f"IVA: {80 * VAT_RATE:.2f} €")

Salida

IVA: 16.00 €

La salida es la misma. Lo primero es una clase y una fábrica para un número que cambia una vez cada diez años, y de todos modos en un solo lugar. Ese es el smell llamado generalidad especulativa (speculative generality): código para cambios que nadie ha pedido. Cuando llegue un segundo tipo (9 % para alimentos), ese es el momento de una tabla.

Los principios son preguntas, no reglas. Hazlas cuando el código duela:

	La pregunta	El dogma que debes evitar
SRP	¿Quién pedirá un cambio aquí? ¿Una parte o dos?	Una clase por cada método
OCP	¿Qué llega de verdad nuevo cada mes?	Puntos de extensión por todas partes
LSP	¿Puede cada subtipo estar aquí sin un if?	Una jerarquía por la palabra «es»
ISP	¿Este cliente usa todo lo que pide?	Una interfaz por cada método
DIP	¿El detalle es lento, externo o reemplazable?	Una interfaz delante de cada clase

Ejercicio

Una tarjeta regalo sin tocar la cancelación

Resuelve la tarea en tu editor.

Tarjeta regalo. La tienda también acepta tarjetas regalo. Al cancelar, el dinero vuelve a la tarjeta. Añade un GiftCardPayment que cumpla la promesa de Payment, y cancela un pedido pagado con 40 € con tarjeta y 25 € con tarjeta regalo. cancel() y los otros pagos no se tocan.

Salida

Tarjeta: devueltos 40.00 €
Tarjeta regalo: 25.00 € de vuelta en la tarjeta
Estado: cancelado

Más tareas

• El informe mensual. Una clase calcula los ingresos del mes, escribe un CSV para contabilidad y un texto para la gerente, y envía el correo ella misma. Divídela según quién pide los cambios. ¿Qué queda compartido?
• Notificación push. Añade en la aplicación móvil un aviso cuando el paquete ha salido. ¿Qué contrato pequeño necesitas, y qué clases no tocas?
• Quitar una abstracción. Busca en tu propio proyecto una clase o función envuelta «por si acaso» sin ningún detalle lento o externo detrás. Quita la envoltura y ejecuta las pruebas.

Test

Ponte a prueba

1. Marketing pide un cambio en el texto del correo, y después se rompe el archivo de contabilidad. ¿Qué principio se ha roto?

Abierto/cerrado: la clase no estaba cerradaSustitución de Liskov: el correo es un subtipo del archivoUna sola razón para cambiar: dos partes que quieren cosas distintas comparten una clase y un método auxiliar

2. La tienda añade el envío a un casillero de paquetes. ¿Qué significa «cerrado a la modificación»?

Las funciones se congelan para que no puedan cambiarNo cambia ni una sola línea del programaNo se toca la función que calcula el total ni los otros envíos; se añaden una función nueva y una fila nueva en la tabla

3. VoucherPayment es un Payment, pero refund lanza un error «no se puede devolver». ¿Qué pasa con el código que llama a refund en cada pago?

Nada, el error se atrapaSe detiene a medias: algunos pagos se devuelven y el pedido se queda en su estado anteriorEl lenguaje no permite una clase así

4. El proveedor de correo tiene un método sms vacío, porque el código llama a sms en todo el que envía avisos. ¿Qué te dice eso?

Nada: el método vacío es inofensivoQue el cliente pide más de lo que necesita: el aviso del mensajero debería pedir algo con sms, y la confirmación, algo con emailQue el proveedor está incompleto y debe aprender SMS

5. InvoiceService hace self.mailer = SmtpMailer() (this.mailer = new SmtpMailer()) en su constructor. ¿Qué rompe?

Solo el estilo: el constructor debería estar vacíoDIP: la regla de la factura depende del detalle; el mailer debería venir de fuera y ser cualquier objeto con send(to, text)Nada: así es más corto

6. ¿Cuándo vale la pena una interfaz con una sola implementación?

Cuando detrás hay un detalle lento o externo (correo, pago, base de datos, reloj) y la prueba quiere su propio dobleNunca: es generalidad especulativaSiempre: SOLID lo exige

Comprobar

Empezar la lección de nuevo

Lecciones relacionadas

• Se basa en: Singleton e inyección de dependencias · Funciones: una tarea, pocos parámetros, sin efectos secundarios ocultos · Code smells: método largo, clase grande, duplicación, primitivos en vez de tipos, cadenas largas de if · Refactorización en pasos pequeños
• Continúa en: Ejercicio: una clase desordenada, limpiada paso a paso · Capas · Arquitectura hexagonal y clean architecture · Monolito, monolito modular, servicios
• Ejercicios sobre el tema: Código limpio y refactorización