Patterns .NET idiomatiques

Au-delà des patterns GoF, le code .NET « propre » repose sur quelques réflexes idiomatiques. En voici quatre, expliqués comme SOLID.

Ces idiomes ne sont pas des dogmes : ce sont les réflexes qui rendent un code .NET testable, maintenable et lisible. Pour chacun : une analogie, le code avant/après, et le pourquoi.

Deux réflexes .NET en un schéma

Deux idiomes qui changent la façon d'écrire du C# : à gauche, on reçoit ses dépendances au lieu de les fabriquer ; à droite, on renvoie l'échec comme une valeur au lieu de le lancer.

Injection de dépendances (DI)
AU DÉMARRAGE IRepo RepoSql enregistre interface → implémentation Conteneur DI crée & câble Service Service(IRepo repo) INJECTION PAR CONSTRUCTEUR fournit une instance

Le service dépend de l'interface, pas du concret : on remplace l'implémentation (tests, autre BDD) sans le toucher.

Pattern Result
❌ throw throw new Exception() l'appelant l'oublie ? Flux interrompu remonte la pile d'appels ✅ Result<T> renvoie Result<T> un seul des deux cas Success (valeur) Failure (erreur) L'appelant teste if (result.EstOk) les deux cas sont visibles dans le type le compilateur force à les traiter

L'échec attendu devient une valeur explicite, pas une exception : le compilateur force à traiter les deux cas.

L'injection de dépendances inverse le contrôle : une classe reçoit ses dépendances (via le constructeur) au lieu de les créer — d'où un code testable et configurable. Le pattern Result, lui, modélise l'échec attendu comme une valeur, en gardant les exceptions pour l'imprévu.

🎯 Testez-vous

Pour chaque situation, quel pattern répond le mieux au besoin ?

Retour aux outils