13
Design Patterns
Filed under: | Tags: | juillet 13th, 2010
J’ai beaucoup apprécié la lecture du livre : « Les design patterns en Java – Les 23 modèles de conception fondamentaux » de Steven John Metsker et William C. Wake. Je ne peux que vous le recommander.
Introduction
L’introduction pose les bases de la conception, en passant par une description des inspirations du monde de l’architecture et de l’urbanisation. L’ouvrage est organisé en 5 catégories de patterns : interfaces, responsabilité, construction, opérations et extensions.
Définition
Je vous paraphrase brièvement la définition du manuel : « Issus de l’expérience de la conception de système informatique basé sur la POO (Programmation Orientée Objet) et des bonnes pratiques dans ce domaine, les design patterns interviennent à un niveau qui est au-dessus du code et ils indiquent comment atteindre un but en n’utilisant que quelques classes. Autrement dit, c’est une description d’une solution classique à un problème récurent. Un pattern représente une idée et non une implémentation particulière. »
Mais un pattern n’est pas :
- une brique : car il dépend de son environnement
- une règle : car il ne peut pas s’appliquer mécaniquement
- une méthode : car il ne guide pas une prise de décision; un pattern est la décision prise
Les patterns interfaces sont au nombre de 4 :
ADAPTER :
But : Adapter l’interface d’une classe pour qu’elle corresponde à l’interface attendue par un client
Définition : Création d’une nouvelle classe qui implémente l’interface (attendue par le client) et étend la classe existante. Cette approche produit un adaptateur de classe qui traduit les appels du client en appel des méthodes de la classe existante. Lorsque qu’il n’y a pas d’interface il est tout de même possible de créer une classe qui utilise un instance de la classe existante, c’est un adaptateur d’objet.
Exemple d’application : Adaptation de données pour un widget JTable de Swing via la création d’un adaptateur pour que les données du tableau soit conforme au TableModel.
FACADE :
But : Fournir une interface simple pour un ensemble de classes
Définition : Une façade est une classe configurable est réutilisable, avec une interface de plus au niveau qui simplifie l’emploi du sous-système. Le sous-système devant être le plus factorisé possible pour que chaque classe ait un objectif spécifique bien défini, pour une meilleure lecture et une maintenance facilité.
Exemple d’application : JOptionPane réalise l’objectif du pattern FACADE en fournissant une interface simple qui facilite l’emploi d’une classe JDialog (Swing)
COMPOSITE :
But : Définir une interface qui s’applique à la fois à des objets individuels et à des groupes d’objets
Définition : comprend 2 concepts puissants associés :
- Un objet peut contenir des éléments individuels mais aussi d’autres groupes
- Ces éléments individuels et composites partagent une interface commune
Ce qui conduit à une définition récursive des méthodes sur les nœuds composites. Il est nécessaire de gérer les cycle lorsqu’il y en a et qu’il sont prévus (possibilité d’utiliser la structure de donnée Set, qui ne peut contenir de doublon), et de s’assurer qu’il n’y en a pas dans un graphe d’objet naturellement non cyclique (risque de boucle infini).
BRIDGE :
But : Découpler une abstraction de son implémentation de sorte que les deux puissent varier indépendamment
Définitions : Séparation d’une classe abstraite de l’implémentation de ses méthodes abstraites. Il n’est pas toujours évident de savoir s’il faut privilégier l’abstraction ou la spécification, mais il est important de prendre des décisions mûrement réfléchies ! ;)
Exemple d’application : les drivers, et particulièrement JDBC, L’éditeur de la BDD fournit son propre driver qui étend l’abstraction JDBC.
Les patterns responsabilité sont au nombre de 6 :
SINGLETON :
But : Avoir une seule instance de la classe.
Définitions : Le code qui supporte ce pattern s’assure qu’une classe ne possède qu’une instance et fournit un point d’accès global à l’instance.
Exemple d’application : Une factory d’objet, un PrinterManager, etc… dans un environnement multi-threader, il faut gérer les locks sur les méthodes du singleton.
à suivre…
OBSERVER :
But :
Définitions :
Exemple d’application :
MEDIATOR :
But :
Définitions :
Exemple d’application :
PROXY :
But :
Définitions :
Exemple d’application :
CHAIN OF RESPONSABILITY :
But :
Définitions :
Exemple d’application :
FLYWEIGHT :
But :
Définitions :
Exemple d’application
:
Les patterns construction sont au nombre de 5 :
BUILDER :
But :
Définitions :
Exemple d’application :
FACTORY METHOD :
But :
Définitions :
Exemple d’application :
ABSTRACT FACTORY :
But :
Définitions :
Exemple d’application :
PROTOTYPE :
But :
Définitions :
Exemple d’application :
MEMENTO :
But :
Définitions :
Exemple d’application :
Les patterns opérations sont au nombre de 5 :
TEMPLATE METHOD :
But :
Définitions :
Exemple d’application :
STATE :
But :
Définitions :
Exemple d’application :
STRATEGY :
But :
Définitions :
Exemple d’application :
COMMAND :
But :
Définitions :
Exemple d’application :
INTERPRETER :
But :
Définitions :
Exemple d’application
:
Finalement, les patterns extensions sont au nombre de 3 :
DECORATOR :
But :
Définitions :
Exemple d’application :
ITERATE :
But :
Définitions :
Exemple d’application :
VISITOR :
But :
Définitions :
Exemple d’application :