Principios SOLID

Los principios SOLID son un conjunto de cinco directrices fundamentales que buscan mejorar la calidad y el mantenimiento del software, promoviendo un diseño más claro y comprensible. La adopción de estos principios ayuda a los desarrolladores a crear sistemas que son más fáciles de entender, modificar y expandir con el tiempo. Los principios incluyen:

S - Principio de Responsabilidad Única (SRP): Una clase debe tener una sola razón para cambiar. Esto significa que cada clase debe ser responsable de una única parte de la funcionalidad del software. Al seguir este principio, se garantiza que los cambios en un aspecto específico del sistema no afecten a otras partes, facilitando el mantenimiento y la evolución del código.
O - Principio de Abierto/Cerrado (OCP): Las entidades de software, como clases y módulos, deben estar abiertas para su extensión, pero cerradas para su modificación. Esto implica que se debe poder agregar nuevos comportamientos al sistema sin alterar el código existente. Esto se puede lograr mediante estrategias como el uso de interfaces y herencia, permitiendo que se añadan nuevas funcionalidades de forma segura y organizada.
L - Principio de Sustitución de Liskov (LSP): Los objetos de una clase derivada deben poder sustituir a los objetos de la clase base sin alterar el comportamiento esperado del sistema. Esto significa que, al usar una clase derivada, el sistema debe continuar operando correctamente como si estuviera usando la clase base. Para respetar este principio, es importante diseñar jerarquías de clases de manera que las subclases mantengan la funcionalidad y los contratos definidos por la clase base.
I - Principio de Segregación de la Interfaz (ISP): Una clase no debe ser forzada a implementar interfaces que no utiliza. Esto sugiere que es mejor tener varias interfaces específicas en lugar de una única interfaz general. Con esto, las clases pueden implementar solo las interfaces que realmente necesitan, evitando la implementación de métodos innecesarios y promoviendo un diseño más cohesivo y menos acoplado.
D - Principio de Inversión de Dependencia (DIP): Este principio establece que las clases deben depender de abstracciones, y no de clases concretas. Esto promueve la flexibilidad y la capacidad de prueba del código, ya que las implementaciones específicas pueden ser cambiadas o sustituidas sin afectar al resto del sistema. La inyección de dependencias es una técnica común para facilitar la aplicación de este principio, permitiendo que los componentes de software sean desacoplados y gestionados de manera más eficaz.

Aplicación de los Principios SOLID en Spring Boot

1. Principio de Responsabilidad Única (SRP)

Definición: Una clase debe tener una sola razón para cambiar. Esto significa que una clase debe tener una única responsabilidad o función.

Ejemplo:

// Clase de Servicio de Pedido - Responsable solo de la lógica de pedidos
@Service
public class OrderService {
    @Autowired
    private OrderRepository orderRepository;

    public void placeOrder(Order order) {
        // lógica de negocio para realizar un pedido
        orderRepository.save(order);
    }
}

// Clase de Servicio de Notificación - Responsable solo de la lógica de notificación
@Service
public class NotificationService {
    public void sendOrderConfirmation(Order order) {
        // lógica para enviar confirmación de pedido
        System.out.println("Confirmación de pedido enviada a: " + order.getCustomer().getEmail());
    }
}

2. Principio de Abierto/Cerrado (OCP)

Definición: Las entidades de software deben estar abiertas para su extensión, pero cerradas para su modificación. Esto se puede lograr mediante interfaces y herencia.

Ejemplo:

// Interfaz de Pago
public interface PaymentMethod {
    void pay(double amount);
}

// Implementación de Pago con Tarjeta
@Component
public class CreditCardPayment implements PaymentMethod {
    @Override
    public void pay(double amount) {
        System.out.println("Pagando " + amount + " con tarjeta de crédito.");
    }
}

// Implementación de Pago con PayPal
@Component
public class PayPalPayment implements PaymentMethod {
    @Override
    public void pay(double amount) {
        System.out.println("Pagando " + amount + " con PayPal.");
    }
}

// Clase de Servicio de Pago
@Service
public class PaymentService {
    @Autowired
    private List<PaymentMethod> paymentMethods; // Inyección de todas las implementaciones

    public void processPayment(PaymentMethod paymentMethod, double amount) {
        paymentMethod.pay(amount); // Llama al método apropiado
    }
}

3. Principio de Sustitución de Liskov (LSP)

Definición: Los objetos de una clase derivada deben poder sustituir a los objetos de la clase base sin alterar el comportamiento deseado.

Ejemplo:

// Clase Base de Notificación
public abstract class Notification {
    public abstract void notifyUser(Order order);
}

// Notificación por Email
@Component
public class EmailNotification extends Notification {
    @Override
    public void notifyUser(Order order) {
        System.out.println("Enviando correo a: " + order.getCustomer().getEmail());
    }
}

// Notificación por SMS
@Component
public class SMSNotification extends Notification {
    @Override
    public void notifyUser(Order order) {
        System.out.println("Enviando SMS a: " + order.getCustomer().getPhoneNumber());
    }
}

// Servicio de Notificación
@Service
public class NotificationService {
    @Autowired
    private List<Notification> notifications;

    public void notifyAll(Order order) {
        for (Notification notification : notifications) {
            notification.notifyUser(order);
        }
    }
}

4. Principio de Segregación de la Interfaz (ISP)

Definición: Una clase no debe ser forzada a implementar interfaces que no usa. Esto significa que es mejor tener varias interfaces específicas en vez de una interfaz única y grande.

Ejemplo:

// Interfaz de Notificación
public interface Notifiable {
    void notifyUser(Order order);
}

// Interfaz de Pago
public interface Payable {
    void pay(double amount);
}

// Implementación de Notificación
@Component
public class EmailNotification implements Notifiable {
    @Override
    public void notifyUser(Order order) {
        System.out.println("Enviando correo a: " + order.getCustomer().getEmail());
    }
}

// Implementación de Pago
@Component
public class CreditCardPayment implements Payable {
    @Override
    public void pay(double amount) {
        System.out.println("Pagando " + amount + " con tarjeta de crédito.");
    }
}

5. Principio de Inversión de Dependencia (DIP)

Definición: Dependa de abstracciones, no de clases concretas. Esto significa que las clases de alto nivel no deben depender de clases de bajo nivel, sino de abstracciones.

Ejemplo:

// Interfaz de Repositorio
public interface OrderRepository {
    void save(Order order);
}

// Implementación de Repositorio en Memoria
@Repository
public class InMemoryOrderRepository implements OrderRepository {
    private List<Order> orders = new ArrayList<>();

    @Override
    public void save(Order order) {
        orders.add(order);
        System.out.println("Pedido guardado en memoria: " + order);
    }
}

// Implementación del Servicio
@Service
public class OrderService {
    private final OrderRepository orderRepository;

    // Inyección de Dependencias a través del constructor
    @Autowired
    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void placeOrder(Order order) {
        orderRepository.save(order);
    }
}