Técnica de diseño de de software que ayudan a desarrollar código limpio, modular y mantenible.

Los principios SOLID son los siguientes:

• Principio de Responsabilidad Única (SRP - Single Responsibility Principle)
• Principio de Abierto/Cerrado (OCP - Open/Closed Principle)
• Principio de Sustitución de Liskov (LSP - Liskov Substitution Principle)
• Principio de Segregación de Interfaces (ISP - Interface Segregation Principle)
• Principio de Inversión de Dependencia (DIP - Dependency Inversion Principle)

Estos principios SOLID no son reglas estrictas sino más bien pautas que se deben seguir para escribir un código flexible, mantenible y escalable. La aplicación de estos principios promueve la modularidad, la reusabilidad y facilita la evolución del software a largo plazo.

Una clase debe tener una única razón para cambiar y debe tener una única responsabilidad.

Por ejemplo, supongamos que tenemos la siguiente clase:

class UserManager {
    public function registerUser($userData) {
        // Lógica para registrar un usuario en la base de datos
    }
 
    public function sendWelcomeEmail($userEmail) {
        // Lógica para enviar un correo de bienvenida al usuario
    }
}

En el ejemplo anterior, la clase UserManager tiene dos responsabilidades diferentes:

• Registrar un usuario en la base de datos
• Enviar un correo de bienvenida.

Esto viola el principio de Responsabilidad Única. Para cumplir con el principio SRP, se puede dividir estas responsabilidades en diferentes clases:

class UserRepository {
    public function registerUser($userData) {
        // Lógica para registrar un usuario en la base de datos
    }
}

class EmailService {
    public function sendWelcomeEmail($userEmail) {
        // Lógica para enviar un correo de bienvenida al usuario
    }
}

Ahora, la clase UserRepository se encarga específicamente del registro de usuarios en la base de datos, mientras que la clase EmailService se encarga únicamente de enviar correos de bienvenida.

De esta manera, cada clase tiene una responsabilidad única y específica, lo que facilita la comprensión, el mantenimiento y la extensibilidad del código en el futuro.

El código debe estar abierto para su extensión pero cerrado para modificaciones. Debe ser posible agregar nuevas funcionalidades sin modificar el código existente.

Los objetos deben ser reemplazables por instancias de sus subclases sin alterar el correcto funcionamiento del sistema.

Los clientes no deben depender de interfaces que no utilizan. Una clase no debe verse obligada a implementar métodos que no necesita.

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Además, los detalles deben depender de las abstracciones y no al revés.