Cuando comencé a sumergirme en el mundo del desarrollo de software, a menudo me sentía abrumado por todas las palabras y conceptos de moda que circulaban por ahí. Uno de los conceptos que parecía particularmente desalentador fueron los principios SÓLIDOS. Parecía algo de lo que sólo los desarrolladores "serios" debían preocuparse. Pero a medida que me sentí más cómodo con la programación, me di cuenta de que estos principios tienen menos que ver con ser sofisticados y más con escribir código que no te dé ganas de tirarte de los pelos después de unos meses.

Esta es mi opinión sobre los principios SOLID en JavaScript: una guía práctica y sensata que desearía tener cuando comencé.

1. Principio de responsabilidad única (SRP): un trabajo, bien hecho

¿Qué es?

El Principio de Responsabilidad Única establece que una clase debe tener solo una razón para cambiar, lo que significa que debe tener solo un trabajo o responsabilidad.

Analogía de la vida real

Piensa en un barista de tu cafetería favorita. Su trabajo es hacer café. Si de repente tienen que empezar a arreglar la máquina de café expreso, a servir pasteles y a sacar la basura, las cosas se van a poner caóticas. Así como el barista debe concentrarse en preparar café, su clase debe concentrarse en hacer una cosa bien.

Ejemplo en JavaScript:

Imagine que tiene una clase de Usuario que maneja la autenticación de usuarios, la validación de datos y el almacenamiento de bases de datos. ¡Está haciendo demasiado! Al dividir estas responsabilidades en clases separadas, hace que su código sea más fácil de administrar y mantener.

class UserAuthenticator {
  login(user) {
    // handle login
  }
}

class UserDataValidator {
  validate(user) {
    // validate user data
  }
}

class UserDatabase {
  save(user) {
    // save user to the database
  }
}

2. Principio abierto/cerrado (OCP): ampliar, no modificar

¿Qué es?

El principio abierto/cerrado establece que las entidades de software deben estar abiertas a la extensión pero cerradas a la modificación. En otras palabras, debería poder agregar nuevas funciones sin cambiar el código existente.

Analogía de la vida real:

Imagina tu consola de juegos favorita. Puedes agregar nuevos juegos, controladores y accesorios, pero no es necesario abrirlo y volver a cablearlo para hacerlo. De manera similar, deberías poder agregar nuevas características a tu código sin cambiar su estructura central.

Ejemplo en JavaScript:

Digamos que tienes una clase Forma con un método para calcular el área. Si necesita agregar una nueva forma, como un triángulo, no debería tener que modificar la clase existente. En su lugar, extiéndalo.

class Shape {
  area() {
    throw "Area method not implemented";
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  area() {
    return this.width * this.height;
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  area() {
    return Math.PI * this.radius * this.radius;
  }
}

3. Principio de sustitución de Liskov (LSP): manténgalo sustituible

¿Qué es?

El principio de sustitución de Liskov establece que los objetos de una superclase deben ser reemplazables por objetos de una subclase sin afectar la corrección del programa.

Analogía de la vida real:

Imagínese alquilar un coche. Ya sea que compre un sedán o un SUV, espera que tenga las funcionalidades básicas de un automóvil: debe conducir, girar y detenerse. Si su coche de alquiler requiriera un conjunto de controles completamente diferente, ¡estaría en problemas! De manera similar, las subclases deben comportarse de una manera que no rompa las expectativas establecidas por su clase principal.

Ejemplo en JavaScript:

Si tienes una clase Pájaro y una clase Pingüino que la amplía, el Pingüino debería seguir comportándose como un Pájaro incluso si no puede volar. Aún debería caminar, comer y tal vez incluso nadar.

class Bird {
  move() {
    console.log("Flies in the sky");
  }
}

class Penguin extends Bird {
  move() {
    console.log("Swims in the water");
  }
}

const myBird = new Bird();
const myPenguin = new Penguin();

myBird.move(); // Flies in the sky
myPenguin.move(); // Swims in the water

4. Principio de segregación de interfaces (ISP): interfaces hechas a medida

¿Qué es?

El principio de segregación de interfaces sugiere que no se debe obligar a los clientes a implementar interfaces que no utilizan. En lugar de tener una interfaz grande, deberías crear otras más pequeñas y específicas.

Analogía de la vida real:

Imagínese un restaurante donde el chef también tiene que ser camarero, barman y lavaplatos. ¡Es abrumador e ineficiente! Más bien, cada rol debería tener sus tareas específicas. De manera similar, tus interfaces deben ser especializadas y enfocadas.

Ejemplo en JavaScript:

Si tiene una interfaz de trabajador que incluye métodos como buildHouse, paintHouse y designHouse, un trabajador que solo pinta casas no debería tener que implementar todos los demás métodos. Divídalo en interfaces más pequeñas.

class Builder {
  build() {
    console.log("Building house...");
  }
}

class Painter {
  paint() {
    console.log("Painting house...");
  }
}

class Designer {
  design() {
    console.log("Designing house...");
  }
}

5. Principio de inversión de dependencia (DIP): confiar en abstracciones

¿Qué es?

El principio de inversión de dependencia establece que los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones.

Analogía de la vida real:

Piensa en cómo conectas el cargador de tu teléfono a un enchufe de pared. No necesita conocer los detalles del cableado eléctrico dentro de las paredes; todo lo que necesita es la interfaz (el enchufe) para alimentar su dispositivo. De manera similar, su código debe depender de abstracciones (interfaces), no de implementaciones concretas.

Ejemplo en JavaScript:

Si tienes una clase LightBulb que controla directamente una clase Switch, estás creando un acoplamiento estrecho. En cambio, ambos deberían depender de una interfaz como PowerSource.

class LightBulb {
  turnOn(powerSource) {
    powerSource.provideElectricity();
    console.log("Light is on");
  }
}

class Switch {
  constructor(powerSource) {
    this.powerSource = powerSource;
  }

  operate() {
    this.powerSource.togglePower();
  }
}

class PowerSource {
  provideElectricity() {
    console.log("Providing electricity");
  }

  togglePower() {
    console.log("Toggling power");
  }
}

Conclusión

Dominar los principios SOLID es como aprender a cocinar con un conjunto de recetas probadas. Una vez que los comprenda, podrá crear un código que no sólo sea funcional sino también elegante y fácil de mantener. Así que la próxima vez que te encuentres en un enigma de codificación, recuerda: ¡hay un principio para eso!

¡Feliz codificación! ?