#Paradigmes & patterns
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”.
#Deux styles qui se complètent
En impératif/objet, on encapsule l’état et le comportement. C’est naturel pour des domaines riches en entités et invariants. 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 effets deviennent explicites, la concurrence se simplifie, la preuve aussi. Les transformations (map/filter/reduce) rendent le flot de données clair. Mesurez toutefois les allocations; parfois, une structure mutable locale, encadrée, est plus performante.
#Quelques motifs qui valent la peine
- Création: Factory/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).
#Mini‑atelier
Choisissez une fonctionnalité simple (upload de fichier, calcul de prix). Comparez deux conceptions: orientée objet (interfaces, stratégies) et fonctionnelle (pipeline de transformations, données immuables). Dites en trois phrases laquelle vous préférez et pourquoi.
#À retenir
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).