Qu’est-ce qu’un design pattern ?
Lors de l’élaboration d’un logiciel, il est inévitable de rencontrer des difficultés de conception. Certaines de ces difficultés sont redondantes ou récurrentes, à quelques spécificités près. Afin d’éviter de résoudre le problème en repartant de zéro à chaque fois qu’il se présente, on élabore un “design pattern”. Celui-ci est donc en substance une solution pré-établie à un problème fréquent dans le domaine de l’édition de logiciel. Ce pattern peut être adapté pour faire face à la singularité de chaque situation, mais sa structure globale reste la même. C’est une solution standardisée et reconnue fonctionnelle. Ce faisant, le design pattern permet de réaliser des gains de temps, d’énergie et d’argent au sein d’un projet.
Les différents types de patterns.
Les patterns peuvent prendre des formes diverses et variées, mais il est néanmoins possible de les catégoriser en 3 groupes majeurs:
- Les “creational patterns” sont relatifs aux instances de classe ou la création d’objet. Ils peuvent par conséquent être sous-catégorisés en patterns de création de classe ou d’objet. Les “creational patterns” les plus reconnus sont les suivants : Factory Method, Abstract Factory, Builder, Singleton, Object Pool, and Prototype.
- Les “structural patterns” permettent quant à eux de créer des relations entre les différentes entités (classes ou objets) créées. Comme leur nom l’indique, ils permettent de créer une structure à partir des éléments déjà créés. Les plus reconnus sont : Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, and Proxy.
- Les “behavioral patterns” se concentrent sur le comportement des objets ainsi que leurs responsabilités. Ils permettent de déterminer comment ces objets vont communiquer entre eux, souvent via des flux complexes et difficiles à suivre lors de l’exécution du logiciel. Les plus reconnus sont :Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template method, Visitor
Les différents patterns cités en exemple ci dessus sont appelés le gang des 23 “Four Design Patterns”. Si de nombreux patterns existent, ces 23 sont considérés comme la base de tous les autres.
Refléxion sur les design patterns
Les design patterns sont à mon sens primordial dans l’élaboration d’un logiciel car ils permettent de gagner en temps mais aussi en sécurité, étant donné que ce sont des solutions connues et reconnues comme fonctionnelles. Elles permettent de faire de l’élaboration de logiciel un travail collaboratif, réutilisant les solutions déjà établies pour ne pas avoir à tout reconstruire de zéro à chaque fois qu’un problème se présente. Par ailleurs, les trois types de design patterns existant sont extrêmement complémentaires puisqu’ils permettent de créer des objets et des classes, de les organiser en une structure cohérente et de déterminer comment les éléments de cette structure communiqueront entre eux. Toutefois, le risque que j’identifierais serait de considérer le design pattern comme une solution toute faîte, en oubliant les spécificités de chaque situation. Si certains problèmes peuvent présenter de fortes similitudes, chacun n’en demeure pas moins unique et propre à son contexte, et doit donc être traité en conséquence. Les design patterns apparaissent donc comme un outil puissant mais à magner avec précaution.