¡Desentrañando el Misterio de SOLID!

¿Alguna vez te has sentido como si estuvieras tratando de descifrar un código secreto cuando escuchas sobre los Principios SOLID en programación? ¡No te preocupes, no estás solo! Hoy vamos a desmitificar este misterioso conjunto de reglas de forma simple, para que cuando te pregunten en una entrevista no se te quede cara estar multiplicando dieciséis por catorce.
Lo primero que debes saber es que SOLID es un acrónimo (sorry por el palabro) que hace referencia a 5 principios, uno por letra. No te asustes eh! que ahora te lo explico.
S -> Single responsibility principle
O -> Open close principle
L -> Liskov substitution principle
I -> Interface segregation principle
D -> Dependency inversion principle

1. S de Responsabilidad Única (Single Responsibility Principle)

El primer principio SOLID es como el gurú de la programación diciendo: «Oye, amigo, no te emociones demasiado». Nos pide que cada clase debería tener solo una razón para cambiar. Esto es como decirle a tu perro que solo debe tener una razón para volverse loco: «¡O juegas o duermes, no ambas al mismo tiempo!»

Imagina que estás construyendo una clase Cocinero. Bueno, un cocinero cocina, ¿no? Pero si también le das la responsabilidad de hacer la contabilidad del restaurante, eso es como pedirle a tu abuela que maneje un Ferrari. ¿Puede hacerlo? Sí, pero puede que tengas que sacarla de la cárcel.

// Incorrecto
class Cocinero {
    void cocinar() {
        // lógica de cocina
    }

    void calcularGastos() {
        // lógica de contabilidad
    }
}

// Correcto
class Cocinero {
    void cocinar() {
        // lógica de cocina
    }
}

class Contador {
    void calcularGastos() {
        // lógica de contabilidad
    }
}

2. O de Abierto/Cerrado (Open/Closed Principle)

Este principio nos dice que una clase debería estar abierta para la extensión pero cerrada para la modificación. ¿Confuso? Piensa en ello como si tuvieras una caja de herramientas: siempre puedes agregar nuevas herramientas, pero no deberías tener que cortar y pegar las existentes cada vez que necesitas algo nuevo.

Digamos que tienes una clase Calculadora:

// Incorrecto
class Calculadora {
    int sumar(int a, int b) {
        return a + b;
    }
}

Ahora, si quieres añadir una operación de multiplicación, ¿tienes que abrir la calculadora y pegar el código? ¡No! ¡SOLID al rescate!

// Correcto
interface Operacion {
    int ejecutar(int a, int b);
}

class Suma implements Operacion {
    @Override
    public int ejecutar(int a, int b) {
        return a + b;
    }
}

class Calculadora {
    int calcular(Operacion operacion, int a, int b) {
        return operacion.ejecutar(a, b);
    }
}

¡Ahora puedes agregar nuevas operaciones sin tocar la clase Calculadora! Menos cirugía, más diversión.

Calculadora calculadora = new Calculadora();
Suma suma = new Suma();
int suma = calculadora.calcular(suma, a, b);

3. L de Sustitución de Liskov (Liskov Substitution Principle)

Este principio nos dice que si tienes una clase base y una clase derivada, deberías poder usar la clase derivada en lugar de la clase base sin cambiar el comportamiento del programa. ¿Suena complicado? Vamos a simplificarlo.

Supongamos que tienes una clase Pajaro:

// Incorrecto
class Pajaro {
    void volar() {
        // lógica de vuelo
    }
}

class Pinguino extends Pajaro {
    // ¡Un pingüino no puede volar!
}

¡Ups! No todos los pájaros vuelan. Mejoremos eso.

// Correcto
interface Volador {
    void volar();
}

class Pajaro implements Volador {
    @Override
    public void volar() {
        // lógica de vuelo
    }
}

class Pinguino implements Volador {
    @Override
    public void volar() {
        // ¡No hago nada porque no puedo volar!
    }
}

Ahora, puedes tratar a todos los pájaros como voladores, incluso si algunos solo saben nadar.

4. I de Segregación de la interfaz (Interface Segregation Principle)

Este principio nos dice que una clase no debería verse obligada a implementar interfaces que no usa. Imagina que te ofrecen un menú con 20 platillos, pero solo quieres una ensalada. ¿Por qué pagar por cosas que no necesitas? ¡Lo mismo ocurre con las interfaces!

// Incorrecto
interface Trabajador {
    void trabajar();

    void descansar();
}

class Programador implements Trabajador {
    @Override
    public void trabajar() {
        // lógica de programación
    }

    @Override
    public void descansar() {
        // lógica de descanso
    }
}

¿Qué pasa si solo quieres la función trabajar y no estás interesado en descansar?

// Correcto
interface Trabajador {
    void trabajar();
}

interface Descansador {
    void descansar();
}

class Programador implements Trabajador {
    @Override
    public void trabajar() {
        // lógica de programación
    }
}

¡Ahora solo pagas por lo que consumes!

5. D de Inversión de Dependencias (Dependency Inversion Principle)

Este último principio nos dice que los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones. ¿Suena confuso? Vamos a ponerlo simple.

Imagina que tienes una clase Motor:

// Incorrecto
class Coche {
    Motor motor;

    Coche() {
        this.motor = new Motor();
    }
}

¿Qué pasa si decides cambiar a un motor eléctrico? ¡Necesitas reescribir todo!

// Correcto
interface Motor {
    void arrancar();
}

class MotorGasolina implements Motor {
    @Override
    public void arrancar() {
        // lógica de arranque
    }
}

class MotorElectrico implements Motor {
    @Override
    public void arrancar() {
        // lógica de arranque eléctrico
    }
}

class Coche {
    Motor motor;

    Coche(Motor motor) {
        this.motor = motor;
    }
}

Ahora, puedes cambiar de motor sin tener que reescribir toda la clase Coche. ¡Inversión de dependencias en acción!

Así que ahí lo tienes, ¡una inmersión rápida en el fascinante mundo de los Principios SOLID en Java! Recuerda, la programación no tiene por qué ser un enigma, ¡es solo un juego de reglas divertido y, a veces, un poco estrafalario! ¡Happy coding! 🚀