2.6 Solid Resumen

S – Single Responsibility Principle (SRP) Una clase debe tener una sola razón de cambio → hacer una sola cosa.
O – Open/Closed Principle (OCP) El código debe estar abierto a extensión pero cerrado a modificación → usar interfaces/herencia.
L – Liskov Substitution Principle (LSP) Una subclase debe poder sustituir a su superclase sin romper el programa.
I – Interface Segregation Principle (ISP) Mejor muchas interfaces específicas que una grande y genérica.
D – Dependency Inversion Principle (DIP) Las clases deben depender de abstracciones, no de implementaciones concretas.

Ejemplo en Java aplicando SOLID#

1
classDiagram
2
    class PaymentProcessor {
3
        <<interface>>
4
        +process(amount: double)
5
    }
6

7
    class PayPalProcessor {
8
        +process(amount: double)
9
    }
10

11
    class CreditCardProcessor {
12
        +process(amount: double)
13
    }
14

15
    class Order {
16
        -total: double
17
        +Order(total: double)
18
        +getTotal(): double
19
    }
20

21
    class CheckoutService {
22
        -processor: PaymentProcessor
23
        +CheckoutService(processor: PaymentProcessor)
24
        +checkout(order: Order)
25
    }
26

27
    PaymentProcessor <|.. PayPalProcessor
28
    PaymentProcessor <|.. CreditCardProcessor
29
    CheckoutService --> PaymentProcessor
30
    CheckoutService --> Order

Supongamos un sistema para procesar pagos:

1
// ISP + DIP → interfaces pequeñas y específicas
2
interface PaymentProcessor {
3
    void process(double amount);
4
}
5

6
// OCP + LSP → podemos extender con nuevos métodos de pago sin modificar lo existente
7
class PayPalProcessor implements PaymentProcessor {
8
    public void process(double amount) {
9
        System.out.println("Procesando pago con PayPal: $" + amount);
10
    }
11
}
12

13
class CreditCardProcessor implements PaymentProcessor {
14
    public void process(double amount) {
15
        System.out.println("Procesando pago con Tarjeta de Crédito: $" + amount);
16
    }
17
}
18

19
// SRP → clase con una única responsabilidad: manejar órdenes
20
class Order {
21
    private double total;
22

23
    public Order(double total) {
24
        this.total = total;
25
    }
26

27
    public double getTotal() {
28
        return total;
29
    }
30
}
31

32
// DIP → depende de la abstracción PaymentProcessor, no de una clase concreta
33
class CheckoutService {
34
    private PaymentProcessor processor;
35

36
    public CheckoutService(PaymentProcessor processor) {
37
        this.processor = processor;
38
    }
39

40
    public void checkout(Order order) {
41
        processor.process(order.getTotal());
42
    }
43
}
44

45
// MAIN
46
public class Main {
47
    public static void main(String[] args) {
48
        Order order = new Order(99.99);
49

50
        // Podemos usar cualquier implementación sin tocar CheckoutService (OCP + LSP + DIP)
51
        CheckoutService checkoutPayPal = new CheckoutService(new PayPalProcessor());
52
        checkoutPayPal.checkout(order);
53

54
        CheckoutService checkoutCard = new CheckoutService(new CreditCardProcessor());
55
        checkoutCard.checkout(order);
56
    }
57
}

Aquí aplicamos:

SRP: Order solo maneja el pedido, CheckoutService solo checkout, PaymentProcessor solo procesar pago.
OCP: si agregamos BitcoinProcessor, no modificamos código viejo.
LSP: todas las subclases (PayPalProcessor, CreditCardProcessor) pueden sustituir a PaymentProcessor.
ISP: interfaz pequeña, solo un método process.
DIP: CheckoutService depende de la abstracción PaymentProcessor, no de clases concretas.