#Ressources — Paradigmes & patternsCopier le lien

Pourquoi ces références : comparer objectivement les styles, reconnaître les patterns au bon moment et démanteler les anti-patterns avant qu'ils ne coûtent cher. Comment s'en servir : lire un chapitre, identifier le problème dans votre propre code, appliquer, puis mesurer (complexité, testabilité, temps de débogage).

#GuidesCopier le lien

• Gamma, Helm, Johnson, Vlissides, Design Patterns (le GoF) : la catalogue historique ; à lire avec un œil moderne (composition plutôt qu'héritage).
• Martin, Clean Code et Agile Software Development : principes SOLID, démarcation calcul/effets, injection de dépendances.
• Fowler, Refactoring : recettes de transformation de code (extraire une fonction, introduire un paramètre) qui servent aussi pour changer de style.
• Résumés vivants : refactoring.guru pour les patterns illustrés et leurs contre-indications.

#Principes et heuristiquesCopier le lien

• SOLID (SRP, OCP, LSP, ISP, DIP) : cinq garde-fous de conception orientée objet.
• Law of Demeter : ne parler qu'à ses collaborateurs directs.
• YAGNI et KISS : ne pas construire la flexibilité qu'aucun besoin actuel ne justifie.

#Anti-patternsCopier le lien

• Singleton abusif : état global déguisé ; les tests deviennent ordre-dépendants. Remède : injecter la dépendance.
• God object : une classe qui centralise tout ; remède : extraire des collaborateurs par responsabilité.
• Sur-abstraction : interfaces à une seule implémentation « au cas où » ; remède : supprimer jusqu'à ce qu'une deuxième implémentation réelle apparaisse.
• Anaemic domain model : objets réducteurs à des sacs de données, toute la logique ailleurs ; remède : rapprocher données et invariants.

#Exercices conseillésCopier le lien

• Refaire les trois styles du même calcul (total panier, normalisation de textes) et comparer les tests : lesquels s'écrivent sans préparation d'état ?
• Écrire un décorateur de retry sans toucher à la fonction décorée, puis en retirer le logging sans dupliquer quoi que ce soit.
• Prendre un singleton de votre projet, l'injecter par paramètre, et mesurer combien de tests deviennent parallélisables.

#OutilsCopier le lien

• Linters et analyse statique (ruff, pylint, mypy) pour détecter les odeurs de code et les effets non voulus.
• Tests : pytest avec fixtures pour matérialiser les frontières calcul/effets ; hypothesis pour tester la pureté (même entrée, même sortie, sur des entrées générées).
• Profiling (cProfile, py-spy) avant tout choix « performance » entre styles : mesurer, pas deviner.