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 doit se concentrer sur la préparation du café, votre classe doit se concentrer sur une seule 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 principale.

Exemple en JavaScript :

Disons que vous disposez d'une classe Shape avec une méthode pour calculer la surface. Si vous devez ajouter une nouvelle forme, comme un triangle, vous ne devriez pas avoir à modifier la classe existante. Au lieu de cela, étendez-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 toujours 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 de dépendance stipule que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux devraient dépendre d’abstractions.

Analogie réelle :

Pensez à la façon dont vous branchez votre chargeur de téléphone sur une prise murale. Vous n’avez pas besoin de connaître les détails du câblage électrique à l’intérieur des murs : tout ce dont vous avez besoin est l’interface (la prise) pour alimenter votre appareil. De même, votre code doit dépendre d'abstractions (interfaces) et non d'implémentations concrètes.

Exemple en JavaScript :

Si vous disposez d’une classe LightBulb qui contrôle directement une classe Switch, vous créez un couplage étroit. Au lieu de cela, les deux devraient dépendre d'une interface comme 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

Maîtriser les principes SOLID, c'est comme apprendre à cuisiner avec un ensemble de recettes éprouvées. Une fois que vous les avez compris, vous pouvez créer un code non seulement fonctionnel, mais élégant et facile à maintenir. Alors la prochaine fois que vous vous retrouverez face à une énigme de codage, rappelez-vous : il y a un principe pour cela !

Bon codage ! ?