Principes SOLID en TypeScript : théorie et pratique de A à Z

Principes SOLID en TypeScript : théorie et pratique de A à Z

SOLID est l'acronyme de cinq principes fondamentaux de la programmation orientée objet, formulés par Robert Martin (Oncle Bob). Ces principes aident à créer un code flexible, maintenable et évolutif. Dans cet article, nous détaillerons chaque principe SOLID avec des exemples en TypeScript, des définitions simples aux scénarios d'utilisation réels.

1. Single Responsibility Principle (SRP) — Principe de responsabilité unique

Définition : Chaque classe doit avoir une seule raison de changer. Autrement dit, une classe doit être responsable d'une tâche clairement définie.

Problème : Lorsqu'une classe assume plusieurs responsabilités, elle devient difficile à tester, à étendre et à maintenir. La modification d'une fonction peut en casser une autre.

Exemple de violation du SRP :

// ❌ Violation du SRP : la classe gère le stockage, le formatage et l'envoi\nclass UserService {\n    saveUser(user: User): void {\n        // Sauvegarde en base de données\n        console.log('User saved');\n    }\n\n    formatUserData(user: User): string {\n        return `Name: ${user.name}, Email: ${user.email}`;\n    }\n\n    sendWelcomeEmail(user: User): void {\n        // Envoi d'email\n        console.log('Email sent');\n    }\n}

Solution avec SRP :

// ✅ Chaque classe est responsable de sa propre tâche\nclass UserRepository {\n    save(user: User): void {\n        console.log('User saved');\n    }\n}\n\nclass UserFormatter {\n    format(user: User): string {\n        return `Name: ${user.name}, Email: ${user.email}`;\n    }\n}\n\nclass EmailService {\n    sendWelcome(user: User): void {\n        console.log('Email sent');\n    }\n}

2. Open-Closed Principle (OCP) — Principe d'ouverture/fermeture

Définition : Les classes doivent être ouvertes à l'extension, mais fermées à la modification. Cela signifie que vous devez pouvoir ajouter de nouvelles fonctionnalités sans modifier le code existant.

Exemple de violation du OCP :

// ❌ Lors de l'ajout d'un nouveau type de forme, il faut modifier la méthode calculateArea\nclass AreaCalculator {\n    calculateArea(shape: any): number {\n        if (shape.type === 'circle') {\n            return Math.PI * shape.radius ** 2;\n        } else if (shape.type === 'rectangle') {\n            return shape.width * shape.height;\n        }\n        throw new Error('Unknown shape');\n    }\n}

Solution avec OCP (utilisation du polymorphisme) :

// ✅ Utilisation d'une interface et de l'héritage\ninterface Shape {\n    area(): number;\n}\n\nclass Circle implements Shape {\n    constructor(private radius: number) {}\n    area(): number {\n        return Math.PI * this.radius ** 2;\n    }\n}\n\nclass Rectangle implements Shape {\n    constructor(private width: number, private height: number) {}\n    area(): number {\n        return this.width * this.height;\n    }\n}\n\nclass AreaCalculator {\n    calculateArea(shape: Shape): number {\n        return shape.area(); // Ne nécessite aucune modification lors de l'ajout de nouvelles formes\n    }\n}

3. Liskov Substitution Principle (LSP) — Principe de substitution de Barbara Liskov

Définition : Les objets d'un programme doivent être remplaçables par des instances de leurs sous-types sans altérer le bon fonctionnement du programme. Une classe fille ne doit pas violer le contrat de la classe parente.

Exemple de violation du LSP :

// ❌ Violation : la sous-classe modifie le comportement de la classe parente\nclass Bird {\n    fly(): void {\n        console.log('Flying');\n    }\n}\n\nclass Penguin extends Bird {\n    fly(): void {\n        throw new Error('Penguins cannot fly!'); // Violation du contrat\n    }\n}

Solution avec LSP :

// ✅ Séparation