¡Los principios SOLID: una aventura con Johnny Bravo! 😎

#webdev #beginners #programming #tutorial

¡Agarra tu teclado, ponte tus gafas de sol y prepárate para conquistar el mundo de la programación con el estilo único de Johnny Bravo!

¿Recuerdas a Johnny Bravo, el chico musculoso con gafas de sol y un peinado Elvis? 🧴 ¿Sabías que su vida está llena de lecciones sobre los principios SOLID de programación? ¡Sí, lo has leído bien! Vamos a desglosar estos principios con la ayuda de nuestro querido Johnny.

Sí, suena extraño, pero te aseguro que esta analogía te ayudará a entender a la perfección los principios SOLID, claves para escribir código limpio, mantenible y escalable.

Principio de Responsabilidad Única (SRP): Johnny, el especialista en conquistas 👙

Este principio establece que una clase debe tener solo una razón para cambiar. Al igual que Johnny, que tiene una única misión en la vida: impresionar a las chicas. No importa cuantas veces fracase, siempre se levanta y lo intenta de nuevo, manteniendo su única responsabilidad.

S - Single Responsibility Principle 😍 Como Johnny, que siempre se enfoca en una sola cosa: impresionar a las chicas. Una clase debe tener una sola razón para cambiar, igual que Johnny tiene una sola razón para peinarse: ¡verse bien!
Java

// Antes: Johnny intenta hacer de todo, un desastre total.
class JohnnyTodo {
    void impresionarChicas() { ... }
    void peinarse() { ... }
    void vestirse() { ... }
}
// Después: Johnny se enfoca en lo que mejor sabe hacer.
class JohnnyImpresionador {
    void impresionarChicas() { ... }
}

Johnny no es bueno para todo. Es un experto en conquistar chicas, pero no sabe cocinar ni arreglar un auto. En programación, el SRP dice que cada clase o módulo debe tener una única responsabilidad bien definida.

Ejemplo:

Bien: Una clase Calculadora que solo realiza operaciones aritméticas básicas (+, -, *, /).
Mal: Una clase Calculadora que también guarda el historial de operaciones y envía notificaciones por email al usuario.

Principio Abierto/Cerrado (OCP): Johnny, el rey de las adaptaciones 👱 Según este principio, las entidades de software deben estar abiertas para la extensión, pero cerradas para la modificación. Johnny siempre está abierto a nuevas tácticas para impresionar a las chicas, pero nunca cambia su objetivo principal. Es flexible en su enfoque, pero firme en su objetivo.

O - Open/Closed Principle 👖 Johnny está abierto a nuevos estilos de ropa pero cerrado a cambiar su peinado. Las clases deben estar abiertas para extensión, pero cerradas para modificación.
Java

// Johnny puede cambiar su camisa, pero su peinado es intocable.
class JohnnyEstilo {
    void cambiarCamisa() { ... }
    final void peinadoJohnny() { ... }
}

Johnny es adaptable. Puede usar diferentes atuendos y peinados para conquistar a cada chica. En programación, el OCP dice que las clases deben estar abiertas para su extensión, pero cerradas para su modificación.

Ejemplo:

Bien: Una clase abstracta FiguraGeometrica con métodos para calcular su área y perímetro. Se pueden crear clases herederas como Cuadrado, Circulo y Triangulo, que implementan los métodos específicos para cada figura.
Mal: Modificar la clase FiguraGeometrica para agregar el cálculo de volumen, lo que afectaría a todas las clases herederas.

Principio de Sustitución de Liskov (LSP): Johnny, el imitador fallido 👕 Este principio dice que las clases derivadas deben poder sustituir a sus clases base sin causar errores. En el mundo de Johnny, cada chica que conoce puede ser sustituida por otra sin cambiar su comportamiento general. Siempre intentará impresionarlas, sin importar quiénes sean.

L - Liskov Substitution Principle 🏃🏼 Si Johnny puede levantar una pesa, cualquier versión de él (como su primo flaco) también debería poder, sin romper el programa.
Java

// Si Johnny puede hacerlo, su primo también.
interface Levantador {
    void levantarPesa();
}
class JohnnyMusculoso implements Levantador {
    void levantarPesa() { ... }
}
class PrimoFlaco implements Levantador {
    void levantarPesa() { ... }
}

Johnny puede imitar a otros, pero no siempre con éxito. En programación, el LSP dice que las subclases deben ser sustituibles por sus clases base sin alterar el comportamiento del programa.

Ejemplo:

Bien: Una clase base Animal con un método comer(). Una clase Perro que hereda de Animal y reimplementa el método comer() para ladrar mientras come.
Mal: Una clase Pez que hereda de Animal pero no puede reimplementar el método comer(), ya que los peces no comen de la misma manera que los perros.

Principio de Segregación de Interfaz (ISP): Johnny, el especialista en fiestas 🕶️ Este principio sostiene que ninguna clase debería depender de métodos que no usemos. Johnny, por ejemplo, no necesita saber cómo cocinar o limpiar para lograr su objetivo. Se centra solo en las habilidades que necesita: levantar pesas, peinarse y practicar sus frases para ligar.

- Interface Segregation Principle🔥 Johnny no quiere estar atado a rutinas que no usa. Las interfaces deben ser específicas para no obligar a las clases a implementar lo que no usan.
Java

// Johnny solo hace lo que necesita.
interface Impresionador {
    void impresionar();
}
class JohnnyBravo implements Impresionador {
    void impresionar() { ... }
}

Johnny no va a cualquier fiesta. Prefiere las fiestas con chicas guapas y música moderna. En programación, el ISP dice que las interfaces no deben ser demasiado grandes, sino que deben dividirse en interfaces más pequeñas y específicas.

Ejemplo:

Bien: Una interfaz FiguraGeometrica2D con métodos para calcular área y perímetro, y una interfaz FiguraGeometrica3D con métodos para calcular volumen. Las clases Cuadrado, Circulo y Triangulo implementan solo FiguraGeometrica2D, mientras que Cubo y Esfera implementan ambas interfaces.
Mal: Una única interfaz FiguraGeometrica con métodos para calcular área, perímetro y volumen. Todas las clases, incluso las que no son 3D, tendrían que implementar todos los métodos.

Principio de Inversión de Dependencias (DIP): Johnny, el conquistador sin ataduras ☀️ Este principio establece que las clases de alto nivel no deben depender de las clases de bajo nivel. Ambas deben depender de abstracciones. Johnny no depende de ninguna chica en particular para ser feliz. En su lugar, su felicidad depende de la abstracción de "impresionar a las chicas".

D - Dependency Inversion Principle💥 Johnny no depende directamente de las chicas para impresionarlas; usa su encanto. Las clases de alto nivel no deben depender de las de bajo nivel, ambos deben depender de abstracciones.
Java

// Johnny usa su encanto, no depende directamente de las chicas.
interface Encanto {
    void impresionar();
}
class EncantoJohnny implements Encanto {
    void impresionar() { ... }
}
class Johnny {
    private Encanto encanto;
    Johnny(Encanto encanto) {
        this.encanto = encanto;
    }
}

Johnny no necesita atarse a una chica. Prefiere la libertad de coquetear con todas. En programación, el DIP dice que las clases de alto nivel no deben depender de clases de bajo nivel; ambas deben depender de abstracciones.

Ejemplo:

Bien: Una clase Calculadora que utiliza una interfaz IOperacion para realizar operaciones aritméticas. La clase Calculadora no depende de una implementación específica de IOperacion, como Suma, Resta, Multiplicacion o Division.
Mal: Una clase Calculadora que depende directamente de la clase Suma para realizar la suma. Si se necesita realizar otra operación, como la resta, habría que modificar la clase Calculadora.

Conclusión 💨
Johnny Bravo, a pesar de sus excentricidades, nos enseña valiosas lecciones sobre la programación. Siguiendo los principios SOLID, podemos escribir código más limpio, mantenible, escalable y fácil de modificar, convirtiéndonos en verdaderos maestros del desarrollo de software.

🚀 ¿Te ha gustado? Comparte tu opinión.
Artículo completo, visita: https://lnkd.in/ewtCN2Mn
https://lnkd.in/eAjM_Smy 👩‍💻 https://lnkd.in/eKvu-BHe
https://dev.to/orlidev ¡No te lo pierdas!

Referencias:
Imágenes creadas con: Copilot (microsoft.com)