Description et comparaison

Les modèles de conception sont des solutions réutilisables aux problèmes qui surviennent fréquemment dans la conception de logiciels. Ce ne sont pas des morceaux de code finis que vous collez – ce sont des plans, des modèles pour résoudre une classe de problèmes. Un modèle décrit le problème, explique pourquoi les solutions naïves échouent et vous donne une structure éprouvée qui fonctionne. Les modèles ont émergé du travail d'architecture de Christopher Alexander et ont été introduits dans les logiciels par le "Gang of Four" (Gamma, Helm, Johnson, Vlissides) dans leur livre de 1994 "Design Patterns: Elements of Realistic Object-Oriented Software".

Un modèle n'est pas un algorithme. Un algorithme définit une séquence exacte d'étapes. Un modèle est une description de haut niveau d'une solution : le même modèle peut être implémenté différemment dans différents langages et contextes.

Pourquoi les modèles sont importants

Les trois catégories

Le Gang of Four a classé les 23 modèles en trois catégories en fonction de leur objectif. Les modèles de création gèrent la création d'objets. Les modèles structurels gèrent la façon dont les objets sont composés en structures plus grandes. Les modèles comportementaux gèrent la communication et la responsabilité entre les objets. Comprendre à quelle catégorie appartient un modèle vous indique immédiatement à quel problème il résout.

Modèles de création en un coup d'œil

Créationnel — Création d'objets

Les modèles créationnels font abstraction du processus d’instanciation. Ils contribuent à rendre un système indépendant de la manière dont ses objets sont créés, composés et représentés. Au lieu d'appeler directement les constructeurs, vous passez par une interface : une méthode de fabrique, un objet de fabrique, un constructeur, un clone ou un accesseur statique. Cela vous donne la flexibilité de modifier ce qui est créé, comment il est créé et quand il est créé, sans toucher au code client. À mesure que les systèmes se développent, la création d'objets devient une préoccupation non triviale : vous devrez peut-être regrouper des objets, garantir leur unicité, prendre en charge plusieurs représentations ou différer une construction coûteuse. Les modèles créationnels répondent à tous ces éléments.

Méthode d'usine

Usine abstraite

Constructeur

Prototype

Singleton

Modèles structurels en un coup d'œil

Structurel – Composition d'objets

Les modèles structurels concernent la manière dont les classes et les objets sont composés pour former des structures plus grandes. Les modèles structurels basés sur les classes utilisent l'héritage pour composer des interfaces. Les modèles structurels basés sur les objets décrivent les manières de composer des objets pour réaliser de nouvelles fonctionnalités. L’idée clé est que les conceptions flexibles naissent souvent non pas de hiérarchies d’héritage, mais de la manière dont les objets se référencent et se délèguent les uns aux autres. Les modèles structurels vous permettent d'assembler des objets dans de nouvelles structures sans réécrire les classes impliquées. Ils sont particulièrement utiles lors de l'intégration de bibliothèques tierces, de la création d'architectures en couches ou de l'optimisation de la mémoire pour les graphiques d'objets volumineux.

Adaptateur

Pont

Composite

Décorateur

Façade

Poids mouche

Procuration

Aperçu des modèles comportementaux

Comportemental – Communication d’objets

Les modèles comportementaux caractérisent la manière dont les classes ou les objets interagissent et répartissent les responsabilités. Ils déplacent votre attention de la structure vers la communication : qui envoie des messages à qui, dans quel ordre et qui gère quoi. Beaucoup de ces modèles dissocient les expéditeurs des destinataires : l’expéditeur ne sait pas qui traitera une demande, ni même si quelqu’un le fera. D'autres encapsulent les algorithmes afin qu'ils puissent être échangés au moment de l'exécution, ou enregistrer et restaurer l'état des objets. Les modèles comportementaux sont le lieu où se produisent la plupart des décisions de conception quotidiennes : comment les événements circulent dans le système, comment les requêtes sont distribuées, comment les machines à états sont modélisées et comment la fonctionnalité d'annulation est implémentée.

Chaîne de responsabilité

Commande

Itérateur

Médiateur

Mémento

Observateur

État

Stratégie

Méthode de modèle

Visiteur

Les 23 modèles : la chronologie complète

Comparer des modèles souvent confus

Plusieurs modèles partagent des similitudes au niveau de la surface – ils enveloppent tous deux des objets ou définissent des interfaces – mais résolvent des problèmes fondamentalement différents. Les comparaisons suivantes clarifient l’intention derrière chaque paire ou groupe.

Méthode d'usine vs usine abstraite vs constructeur

Adaptateur vs décorateur vs proxy

Stratégie vs état vs méthode modèle

Observateur vs Médiateur vs Chaîne de Responsabilité

Composite vs Décorateur

Principes de conception derrière les modèles

Les modèles de principes s'appliquent

Les modèles ne sont pas inventés arbitrairement : chacun est une application directe d’un ou plusieurs principes fondamentaux de conception. Comprendre le principe derrière un modèle vous aide à reconnaître quand l’appliquer et quand une solution plus simple est préférable. Le Gang of Four a identifié deux principes clés qui sous-tendent presque tous les 23 modèles : « Programmer vers une interface, pas une implémentation » – qui permet toute la flexibilité polymorphe – et « Favoriser la composition des objets plutôt que l'héritage de classe » – qui évite le problème fragile de la classe de base et permet une flexibilité d'exécution. De ces deux principes, plus SOLID (notamment OCP et DIP), l'ensemble du catalogue de modèles découle naturellement.

Programme aux interfaces

Favoriser la composition

Principe ouvert/fermé

Inversion de dépendance

Responsabilité unique

Remplacement Liskov

Ne vous répétez pas

Quand NE PAS utiliser de modèles

Modèles dans les frameworks Java modernes

Où vous voyez des modèles chaque jour

Les modèles de conception ne sont pas des exercices académiques : ils constituent l'échafaudage invisible de chaque framework et bibliothèque Java majeurs que vous utilisez. Spring Framework est une vitrine de modèles : son conteneur IoC est Dependency Injection (une variante de Strategy + Factory), @Transactional utilise un proxy dynamique, @Async utilise Proxy, ApplicationEvent utilise Observer, RestTemplate utilise la méthode Template et DispatcherServlet de Spring MVC utilise Chain of Responsibility pour le mappage des gestionnaires. Hibernate utilise le proxy pour les entités chargées paresseusement, la carte d'identité (de type Flyweight) pour le cache de session et le référentiel (Facade) pour l'accès à la base de données. Le package java.io est entièrement construit sur Decorator (wrappers InputStream). JDBC utilise un pont entre l'API standard et les implémentations des fournisseurs. JavaFX et Swing utilisent Composite pour l'arborescence des composants et Observer pour les écouteurs d'événements. Connaître les modèles, c'est savoir comment fonctionnent les frameworks, pas seulement comment appeler leurs API.

Printemps IoC

@Procuration transactionnelle

ApplicationEvent

Proxy de mise en veille prolongée

Décorateur java.io

Pont JDBC

Balançoire composite

Cliquez sur les lignes en surbrillance pour repérer le motif dans Spring + Java SE

java

// ── Observer ─────────────────────────────────────────────────────

@EventListener

▼

public void onOrderPlaced(OrderPlacedEvent event) { ... }

// ── Proxy (@Transactional) ───────────────────────────────────────

@Transactional

▼

public void transferFunds(Account from, Account to, BigDecimal amount) { ... }

// ── Template Method ──────────────────────────────────────────────

JdbcTemplate.query(sql, rowMapper);

▼

// ── Decorator (java.io) ──────────────────────────────────────────

new BufferedReader(new InputStreamReader(socket.getInputStream()));

▼

// ── Strategy ─────────────────────────────────────────────────────

list.sort(Comparator.comparing(Person::getName));

▼

À retenir : les modèles de conception sont un langage, un vocabulaire pour les décisions de conception. Les maîtriser ne signifie pas mémoriser 23 diagrammes de classes. Cela signifie comprendre les problèmes qu'ils résolvent, reconnaître ces problèmes dans votre propre code et savoir quand les avantages du modèle dépassent ses coûts.

Et ensuite : les chapitres suivants couvrent chaque modèle en profondeur, avec des diagrammes interactifs, des exemples de code complets et des références réelles à la bibliothèque Java. Commencez par les modèles de création, puis passez aux modèles structurels, puis comportementaux. Chaque leçon s'appuie sur le vocabulaire introduit ici.