Rendre SOLID simple : un guide JavaScript sur les principes du code propre

Lorsque j'ai commencé à plonger dans le monde du développement logiciel, je me suis souvent retrouvé submergé par tous les mots à la mode et les concepts qui circulaient. L’un des concepts qui semblait particulièrement intimidant était celui des principes SOLID. C'était comme si seuls les développeurs "sérieux" devaient s'inquiéter. Mais au fur et à mesure que je me suis familiarisé avec le codage, j'ai réalisé que ces principes consistent moins à être sophistiqué qu'à écrire du code qui ne vous donne pas envie de vous arracher les cheveux après quelques mois.

Voici donc mon point de vue sur les principes SOLID en JavaScript : un guide pratique et pragmatique que j'aurais aimé avoir quand j'ai commencé.

1. Principe de responsabilité unique (SRP) : un travail bien fait

Qu'est-ce que c'est?

Le principe de responsabilité unique stipule qu'une classe ne devrait avoir qu'une seule raison de changer, ce qui signifie qu'elle ne devrait avoir qu'un seul travail ou responsabilité.

Analogie réelle

Pensez à un barista dans votre café préféré. Leur travail consiste à préparer du café. S’ils doivent soudainement réparer la machine à expresso, servir des pâtisseries et sortir les poubelles, les choses vont devenir chaotiques. Tout comme le barista devrait se concentrer sur la préparation du café, votre classe devrait se concentrer sur une chose bien faite.

Exemple en JavaScript :

Imaginez que vous ayez une classe User qui gère l'authentification des utilisateurs, la validation des données et le stockage de la base de données. ça en fait trop ! En répartissant ces responsabilités en classes distinctes, vous facilitez la gestion et la maintenance de votre code.

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

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

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

2. Principe ouvert/fermé (OCP) : étendre, ne pas modifier

Qu'est-ce que c'est?

Le principe ouvert/fermé stipule que les entités logicielles doivent être ouvertes pour extension mais fermées pour modification. En d'autres termes, vous devriez pouvoir ajouter de nouvelles fonctionnalités sans modifier le code existant.

Analogie réelle :

Imaginez votre console de jeu préférée. Vous pouvez ajouter de nouveaux jeux, contrôleurs et accessoires, mais vous n'avez pas besoin de l'ouvrir et de le recâbler pour ce faire. De même, vous devriez pouvoir ajouter de nouvelles fonctionnalités à votre code sans modifier sa structure de base.

Exemple en JavaScript :

Disons que vous disposez d'une classe Shape avec une méthode pour calculer l'aire. Si vous devez ajouter une nouvelle forme, comme un triangle, vous ne devriez pas avoir à modifier la classe existante. Au lieu de cela, prolongez-le.

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. Principe de substitution de Liskov (LSP) : gardez-le substituable

Qu'est-ce que c'est?

Le principe de substitution de Liskov stipule que les objets d'une superclasse doivent être remplaçables par des objets d'une sous-classe sans affecter l'exactitude du programme.

Analogie réelle :

Imaginez louer une voiture. Que vous achetiez une berline ou un SUV, vous vous attendez à ce qu’il possède les fonctionnalités de base d’une voiture : il doit conduire, diriger et s’arrêter. Si votre voiture de location nécessitait un ensemble de commandes complètement différent, vous auriez des ennuis ! De même, les sous-classes doivent se comporter d'une manière qui ne brise pas les attentes fixées par leur classe parent.

Exemple en JavaScript :

Si vous avez une classe Oiseau et une classe Pingouin qui l'étendent, le Pingouin devrait toujours se comporter comme un Oiseau même s'il ne peut pas voler. Il devrait encore marcher, manger et peut-être même nager.

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. Principe de ségrégation des interfaces (ISP) : interfaces sur mesure

Qu'est-ce que c'est?

Le principe de ségrégation des interfaces suggère que les clients ne devraient pas être obligés d'implémenter des interfaces qu'ils n'utilisent pas. Au lieu d'avoir une grande interface, vous devriez en créer des plus petites et plus spécifiques.

Analogie réelle :

Imaginez un restaurant où le chef doit également être serveur, barman et lave-vaisselle. C’est écrasant et inefficace ! Au lieu de cela, chaque rôle devrait avoir ses tâches spécifiques. De même, vos interfaces doivent être spécialisées et ciblées.

Exemple en JavaScript :

Si vous disposez d'une interface Worker qui inclut des méthodes telles que buildHouse, paintHouse et designHouse, un travailleur qui peint uniquement des maisons ne devrait pas avoir à implémenter toutes les autres méthodes. Décomposez-le en interfaces plus petites.

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

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

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

5. Principe d'inversion de dépendance (DIP) : s'appuyer sur des abstractions

Qu'est-ce que c'est?

Le principe d'inversion des dépendances stipule que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux devraient dépendre d’abstractions.

Real-Life Analogy:

Think about how you plug your phone charger into a wall socket. You don’t need to know the details of the electrical wiring inside the walls—all you need is the interface (the socket) to power your device. Similarly, your code should depend on abstractions (interfaces), not concrete implementations.

Example in JavaScript:

If you have a LightBulb class that directly controls a Switch class, you’re creating a tight coupling. Instead, both should depend on an interface like 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");
  }
}

Conclusion

Mastering the SOLID principles is like learning to cook with a set of proven recipes. Once you understand them, you can whip up code that’s not just functional but elegant and easy to maintain. So next time you find yourself in a coding conundrum, remember: there’s a principle for that!

Happy coding! ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!