Présentation

Les Design Pattern sont aussi nommés en Français des Patrons de Conception. Ils sont une référence pour le résolution de problèmes informatiques connus, fréquemment rencontrés.

Ce qui a donné lieu à une schématisation d’un ensemble d’objets qui décrivent des classes, des relations entre celles-ci. C’est un ensemble d’actions et de rôles.

Ces Design patterns répondent à des problèmes de conception logicielles en programmation Orientée Objets. Ils proposent des solutions à des problèmes connus. Ces solutions ont été éprouvés par un ensemble de développeurs au fil des années.

Les Design Patterns sont surtout un ensemble de bonnes pratiques dans le domaines de la POO (Programmation Orientée Objets). Il n’existe pas vraiment de théorie sur les différents DP (Design Patterns) comme on pourrait le retrouver sur des Algorithmes.

Historique

Les Design Patterns sont pour la première fois rassemblés, formalisés par l’équipe GoF (Gang Of Four). GoF tout simplement parce qu’ils sont au nombre de quatre :

  • Erich Gamma ;
  • Richard Helm ;
  • Ralph Johnson ;
  • John Vissides.

Formalisé en 1995, dans un livre qui s’intitule Design Patterns – Elements of Reusable Object-Oriented Software. Ce Livre est devenu une référence incontournable dans le domaine des Design Patterns.

Ce qu’il faut savoir c’est qu’ils ne sont pas à l’origine même de l’identification de ces cas d’usage. Les Design Patterns tirent leur origine des travaux de Christopher Alexander dans les années 70. Qui les décrits dans un ouvrage qui se nomme : A Pattern Language : Towns, Buildings, Construction. Je vous laisse découvrir par vous même cet Architecte Autrichien.

Les type de Patterns

Il existe différents types de Design Patterns, dans notre cas nous allons aborder les patrons de conception du GoF qui sont les plus couramment utilisés en programmation et architecture logicielle.

Un autre type de Design Patterns, sont les GRASP. Les GRASP, General Responsability Assignment Software Patterns. Ce sont des Patterns créés par Graig Larman pour l’attribution des responsabilités des classes et objet en POO. On parlera de modèles et principes, comme par exemple : le contrôleur, le créateur, etc…

On retrouve aussi des Design Patterns dans le monde Clouds

On les retrouve aussi en architecture, on parle alors de Design Patterns d’Architecture, comme par exemple : Client-Serveur Pattern, Maître-Esclave Pattern, etc…

Les Anti-Patterns

Il existe une liste dites d’Anti-Patterns qui sont à l’inverse des Design Patterns, les mauvaises utilisations, mise en place des DP ou absences de DP. Cela entraine des lenteurs, des sur-cours dans la maintenances et la réalisation. Ces Anti-Patterns apparaissent dès la phase de conception du logiciel.

Exemple

L’anti-pattern “Ancre de bateau” : c’est le faite de laisser un ou plusieurs composants inutilisés dans le code pour des raisons stratégiques, politiques tout en sachant qu’ils ne serviront jamais.

L’anti-pattern “L’objet Divin” : C’est un composant du logiciel assurant trop, beaucoup trop de fonctions essentielles.

Les Grey Patterns

C’est un ensemble de patterns dont on ne sait pas vraiment si ils apportent des avantages ou des inconvénients quant à leur utilisation dans la conception du logiciel.

Description

Pour ma part, pour formaliser les différents Patterns j’utiliserai :

  • un langage de modélisation, en l’occurrence l’ UML ;
  • un langage de développement, en l’occurrence le C# pour la mise en pratique des DP.

Pour décrire chaque Pattern, voici les différentes sections :

  • Nom du Pattern ;
  • Description ;
  • La présentation de sa forme générique à l’aide de diagrammes UML ;
  • Les participants et leur fonction au sein du Pattern ;
  • Exemple(s) de code mettant en pratique le Pattern ;
  • Exemple(s) de domaine d’application du Pattern.