Fundamentos SOLID: Los 5 Principios Clave para un Diseño de Software Robusto

Los Principios SOLID: Fundamentos Esenciales del Diseño Orientado a Objetos

SOLID es un acrónimo que representa cinco principios fundamentales de diseño de software orientados a objetos. Su aplicación ayuda a crear sistemas más mantenibles, flexibles y escalables.

1. Principio de Responsabilidad Única (SRP - Single Responsibility Principle)

Este principio establece que una clase debe tener una única responsabilidad y, por ende, una única razón para cambiar. En otras palabras, una clase debe tener un solo motivo para ser modificada.

Ejemplo Práctico del SRP

Supongamos que tenemos una clase llamada Empleado que se encarga tanto de almacenar los datos personales de un empleado como de calcular su salario. Aplicando el SRP, podemos separar las responsabilidades en dos clases:

• Empleado: Encargada de gestionar los datos personales.
• CalculadoraSalario: Encargada de calcular el salario.

2. Principio de Abierto/Cerrado (OCP - Open/Closed Principle)

Este principio establece que una entidad de software debe estar abierta para su extensión, pero cerrada para su modificación. Esto significa que, en lugar de modificar el código existente, se debe poder extender su funcionalidad mediante la adición de nuevas clases o métodos.

Ejemplo Práctico del OCP

Tenemos una clase abstracta Forma con métodos para calcular el área y el perímetro. Si queremos agregar una nueva forma, como un triángulo, podemos crear una nueva clase Triangulo que extienda de Forma y sobrescribir los métodos necesarios sin modificar la implementación existente de la clase base.

3. Principio de Sustitución de Liskov (LSP - Liskov Substitution Principle)

Este principio establece que los objetos de una clase derivada deben poder ser sustituidos por objetos de su clase base sin alterar el correcto funcionamiento del programa. Es crucial que las clases derivadas cumplan con el contrato establecido por la clase base.

Ejemplo Práctico del LSP

Tenemos una clase base Vehículo con un método acelerar(). Si creamos una clase derivada Coche que hereda de Vehículo, el método acelerar() en Coche debe comportarse de manera consistente con la definición en Vehículo. No debe introducir comportamientos inesperados o violar las precondiciones y postcondiciones establecidas.

4. Principio de Segregación de Interfaces (ISP - Interface Segregation Principle)

Este principio establece que los clientes no deben depender de interfaces que no utilizan. La recomendación es favorecer interfaces específicas y especializadas en lugar de una única interfaz grande y genérica.

Ejemplo Práctico del ISP

Consideremos una interfaz ImpresoraMultifuncional con métodos como imprimirDocumento(), escanearDocumento() y enviarFax(). Si un cliente solo necesita la función de impresión, no debería estar obligado a implementar los métodos de escaneo y fax. La solución es crear interfaces más pequeñas y específicas (por ejemplo, IImpresora y IEscaneadora) para que los clientes implementen solo las funcionalidades que realmente necesiten.

5. Principio de Inversión de Dependencia (DIP - Dependency Inversion Principle)

Este principio establece dos puntos clave:

1. Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
2. Las abstracciones no deben depender de los detalles; los detalles deben depender de las abstracciones.

Ejemplo Práctico del DIP

Tenemos una clase Motor y una clase Coche. Sin aplicar DIP, Coche estaría fuertemente acoplada a la implementación concreta de Motor. Al aplicar DIP, introducimos una abstracción (una interfaz IMotor) que Motor implementa. La clase Coche dependerá entonces de la interfaz IMotor, lo que permite cambiar la implementación del motor sin afectar a la clase Coche.