Les principes SOLID expliqués avec TypeScript (sans jargon)

Tout développeur a déjà hoché la tête devant une explication de SOLID pleine d'AbstractShapeFactory sans rien retenir. J'utilise ces principes chaque jour en TypeScript de production — apps Next.js, APIs Node — alors les voici avec des exemples tirés du code qu'on écrit vraiment, plus la partie que la plupart des articles zappent : quand les appliquer est une erreur.

SOLID, ce sont cinq heuristiques pour un seul objectif : du code qu'on peut changer sans peur. Appliquez-les là où le changement est probable ; ignorez-les là où il ne l'est pas.

S — Responsabilité unique : une seule raison de changer

La violation classique n'est pas une classe géante — en TypeScript moderne, c'est le composant React de 400 lignes qui fetch les données, les transforme, gère le formulaire ET rend l'UI. Quand l'API change, vous éditez le même fichier que quand le design change. Découpez par raison de changer : un hook pour les données (useOrders), une fonction pure pour les transformations, un composant pour le rendu.

O — Ouvert/Fermé : étendre sans éditer

Chaque fois que vous ajoutez un else if (type === "nouveauCas") à une chaîne qui grossit, vous éditez du code testé pour ajouter un comportement. La solution native TypeScript : un registre de handlers, const handlers: Record<PaymentType, Handler> — ajouter un moyen de paiement devient ajouter une entrée, pas éditer une fonction. Les unions discriminées + un switch exhaustif donnent la même sécurité avec l'aide du compilateur.

L — Substitution de Liskov : pas de surprise dans les sous-types

Si votre CachedUserRepo lance une exception là où UserRepo renvoyait null, chaque appelant doit maintenant savoir lequel il a reçu — l'abstraction est cassée. En TypeScript, c'est moins une affaire de classes que de respecter le contrat de l'interface : mêmes entrées, mêmes modes d'échec, pas d'effet de bord surprise.

I — Ségrégation des interfaces : des contrats petits

Une fonction qui prend user: User mais ne lit que user.email ment sur ses besoins. Prenez { email }: Pick<User, "email"> — les appelants arrêtent de fabriquer de faux objets géants dans les tests, et les refactors arrêtent de se propager. Le typage structurel de TypeScript rend ça presque gratuit.

D — Inversion de dépendance : dépendre d'interfaces, pas de modules

La version pratique : votre logique métier ne devrait pas importer prisma directement partout. Passez une interface de repository, et votre logique devient testable sans base de données. C'est le principe SOLID qui se rembourse dès le premier test écrit.

Quand NE PAS appliquer SOLID

Un MVP de trois écrans n'a pas besoin d'inversion de dépendance — il a besoin d'être livré. Les abstractions coûtent de l'indirection, et l'indirection coûte du temps d'onboarding. Ma règle après des années de code en production : appliquez SOLID au moment du deuxième changement, pas de la première écriture. La première fois qu'un code change pour une nouvelle raison, c'est votre signal — refactorez vers le principe à ce moment-là, avec un vrai exemple en main plutôt qu'une supposition.

Le résumé honnête

SOLID ne fera pas de vous un senior. Savoir quand le remède est pire que le mal, si. Si vous voulez ce pragmatisme appliqué à votre base de code — TypeScript, React, Node — c'est exactement ce jugement que je vends : mes projets · contact.