#Paradigmes & patternsCopier le lien

Les paradigmes sont des styles de pensée ; les patterns, des raccourcis de conception. Ce cours cherche moins à lister qu'à vous aider à choisir et à justifier vos choix : pourquoi du fonctionnel ici, pourquoi un décorateur là, et quand il vaut mieux ne rien « patronner ».

Prérequis : bases de Python (fonctions, classes, dictionnaires), notions de test unitaire. Aucune expérience d'un autre langage exigée : les transformations sont montrées en Python, dont la souplesse accepte les trois styles dans un même fichier.

Objectifs d'apprentissage :

• Reconnaître le style impératif, fonctionnel et objet dans un code existant, et raisonner sur ses effets (état, immutabilité, couplage).
• Transformer un même traitement d'un style à l'autre sans changer son comportement observable.
• Appliquer l'encapsulation, l'injection de dépendances et la composition là où ils rapportent.
• Choisir un pattern GoF (stratégie, observateur, fabrique, décorateur, adaptateur) en citant le problème qu'il résout et son coût.
• Détecter les anti-patterns courants (singleton abusif, god object, sur-abstraction) et savoir les démonter.

#Trois styles qui se complètentCopier le lien

En impératif, le programme est une suite d'ordres qui transforment un état : variables, boucles, affectations. C'est le style le plus proche de la machine, efficace et direct, mais chaque compartiment d'état partagé est une opportunité de bug.

En impératif/objet, on encapsule l'état et le comportement dans des entités qui garantissent leurs invariants. C'est naturel pour des domaines riches en entités (comptes, commandes, documents). L'expérience montre qu'on gagne en souplesse en favorisant la composition sur l'héritage : on assemble de petits objets plutôt que d'étendre une hiérarchie rigide.

En fonctionnel, on privilégie des fonctions pures et l'immutabilité : les mêmes entrées donnent toujours les mêmes sorties, sans effet de bord. Les effets deviennent explicites, la concurrence se simplifie, les tests aussi. Les transformations (map/filter/reduce) rendent le flot de données clair. Mesurez toutefois les allocations : parfois, une structure mutable locale, encadrée dans une fonction pure, est plus performante.

Aucun style ne domine : un programme réaliste mélange les trois. La compétence visée est de savoir justifier la part de chacun, et de migrer un bout de code d'un style à l'autre quand le contexte change (testabilité, performance, lisibilité).

#Quelques motifs qui valent la peineCopier le lien

• Création : Factory et Builder masquent la complexité de construction et standardisent l'initialisation. Méfiance avec Singleton : pratique mais source de couplage global et d'artefacts de test.
• Structure : Adapter rend compatibles deux interfaces ; Decorator ajoute un comportement sans toucher à l'existant ; Composite manipule uniformément feuilles et nœuds.
• Comportement : Strategy choisit un algorithme interchangeable ; Observer diffuse des événements ; Command encapsule une action (utile pour annulation et audit).

Un pattern n'est jamais une fin : il a un coût en indirection. La règle de décision : l'appliquer quand la variation qu'il isole existe déjà dans vos besoins (plusieurs stratégies réellement échangées, plusieurs observateurs réellement distincts), pas parce qu'un diagramme en UML l'a rendu célèbre.

#Mini-atelierCopier le lien

Choisissez une fonctionnalité simple (calcul de prix panier avec remises, upload de fichier). Implémentez-la trois fois :

1. en impératif pur (boucle, accumulateur mutable) ;
2. en objet (classe avec invariant et méthodes) ;
3. en pipeline fonctionnel (fonctions pures composées).

Comparez les trois versions sur quatre critères : lignes de code, testabilité (facilité à écrire un cas de test), coût en allocations, et lisibilité pour un relecteur qui découvre le projet. Rédigez trois phrases : laquelle vous préférez, pourquoi, et dans quel contexte vous changeriez d'avis.

#À retenirCopier le lien

Choisissez un style pour simplifier le problème, pas pour coller à une mode. Composez des petites pièces, rendez les effets visibles, et gardez vos abstractions honnêtes (pas plus compliquées qu'il ne faut). Un pattern bien appliqué raccourcit le code conceptuel ; un pattern mal appliqué ne raccourcit que votre patience.