BT

Design Patterns : Magie ou Mythe ?

Écrit par David Budgen , traduit par Chris Woodrow le 11 févr. 2014 |

Cet article est d'abord paru dans le magazine IEEE Software et vous est proposé par InfoQ et la société IEEE Computer

My name is John Wellington Wells,
I’m a dealer in magic and spells,
In blessings and curses,
And ever-fill’d purses,
In prophecies, witches and knells!
—The Sorcerer, Gilbert et Sullivan, 1877

Un élément important de ce vieil opéra comique de Gilbert et Sullivan était la représentation du sorcier comme un vendeur de biens domestiques plutôt que comme une créature mystérieuse et exotique. Les marchandises étaient exotiques, pas le vendeur.

Malheureusement, c'est ce que beaucoup de managers et développeurs continuent à rechercher - un ensemble de "sorts" qui vont magiquement assurer le succès. Les design patterns peuvent être considérés comme tel - destinés à être utilisés comme un moyen d'assurer que les logiciels fonctionnent et que quelqu'un qui comprend les concepts puisse s'attendre à être capable de maintenir le système efficacement.

Les design patterns de base

Evidement, il y a une base solide derrière cette idée. Il est normal pour un concepteur, quelque soit la discipline, de tirer partie de ses expériences positives passées, adaptant son design de manière appropriée pour remplir ses nouveaux objectifs. La communauté des design patterns logiciels, a tendance à citer Christopher Alexander comme référence1, mais nous pouvons retrouver des concepts similaires dans les automobiles, l'habillement, les systèmes de transports publics, les bibliothèques, et ainsi de suite. Certains usages impliquent des formes statiques alors que d'autres sont des processus, comme ceux que nous pouvons rencontrer dans les logiciels.

Au cours de leurs premiers travaux, Beth Adelson et Elliot Soloway ont observé des concepteurs de logiciels expérimentés et ont relevé leur intention de réutiliser certains éléments de conceptions en leur affectant des noms pour leurs futurs projets de conceptions.2 Françoise Détienne a décrit ce comportement du point de vue cognitif comme l'utilisation de schémas - qui sont des modèles mentaux qui englobent différents aspects de l'expérience du concepteur.3

Il n'est donc pas surprenant que les développeurs aient facilement adopté cette idée quand le Gang of Four (GoF) l'a diffusé à travers son livre, qui cataloguait 23 design patterns.4 Ce livre a rapidement et largement (et probablement incorrectement) été vu comme définitif, bien que la communauté des design patterns ait continué à créer et à cataloguer beaucoup d'autres patterns.

En effet, cet enthousiasme pour la recherche de patterns a eu tendance à dissimuler certaines questions clés qui restent sans réponse telles que :

  • la question du processus de conception : Est-ce que les patterns sont une manière effective d'échanger des connaissances en matière de conception?

et

  • la question de la conception du produit : Est-ce que les patterns nous aident à créer des produits qui sont plus faciles à comprendre et à maintenir?

Aucune de ces deux questions n'a trouvé d'écho particulier chez les enthousiastes aux design patterns. Cependant, comme il arrive souvent dans le domaine de la conception logicielle, quand nous regardons les informations à notre disposition, les réponses à ces deux questions ont tendance à être mélangées. Donc, comme pour The Sorcerer de Gilbert and Sullivan, utiliser la magie ne mène pas toujours au résultat escompté.

Figure 1. L'étude cartographique et les deux enquêtes de suivi. L'étude cartographique initiale a identifié 611 articles sur les design patterns logiciels vers la fin 2009. Les deux enquêtes de suivi ont toutes les deux étendu et aidé à interpréter les résultats de l'étude cartographique.

Un ensemble d'études empiriques

Ce que je décris ici est largement dérivé d'études menées ces dernières années en collaboration avec un de mes étudiants à l'université de Durham. La figure 1 résume les relations entre ces études, qui consistent en une étude cartographique, conduite pour identifier les études empiriques pertinentes,5 et deux enquêtes qui ont suivi.6,7 En menant l'étude cartographique, nous avons identifié 611 articles qui traitaient des design patterns logiciels dans une période qui prenait fin en 2009. A partir de ces articles, nous avons identifié et analysé 11 études expérimentales (les seules qui ont été menées sur plus d'une décennie d'utilisation de patterns) et sept études d'observation qui ont aidé à expliquer et à interpréter nos découvertes. Toutes ces études étaient basées sur les patterns du GoF.

Ensuite, nous avons organisé une enquête auprès des 877 auteurs des articles de l'étude cartographique afin d'en savoir plus sur leurs visions des patterns du GoF. Bien sûr, les adresses de certains auteurs n'étaient plus valides, ce qui nous laissait 681 auteurs. Mais nous avons augmenté ce nombre en demandant aux auteurs qui avaient répondu de transmettre notre invitation à leurs confrères appropriés ainsi qu'en l'envoyant à une maling-list sur les design patterns. Ceci a finalement produit 206 réponses exploitables (plus que ce que nous avions imaginé, ce qui nous a permis de créer un profil "d'utilité" des patterns. Enfin, nous avons conduit une seconde étude sur ces 206 personnes pour voir si nous pouvions mieux comprendre les trois patterns qui avaient entraîné les réactions les plus diverses. Parmi les 46 qui nous ont répondu, 27 nous ont fournis des commentaires et des retours d'expériences.

Une question légitime est quelle est la valeur de cette étude? L'étude cartographique a impliqué une recherche complète d'étude fondamentale, nous pouvons donc en conclure que les résultats sont clairement complets et impartiaux, même si les données empiriques ne sont pas très vastes. Les réponses aux enquêtes nous ont permis d’échantillonner trois groupes, bien que notre analyse ait montré que l'ensemble avait des profils d’éducation et d'expérience professionnelle similaires. En plus, parce que le groupe le plus large incluait des membres qui avaient écrit à propos des design patterns, nous pouvons les considérer comme non-seulement bien informés à propos des design patterns mais aussi plus enclins à favoriser le concept. Ce qui devrait pondérer toutes réserves qu'ils ont exprimé.

Qu'avons nous appris?

Les études expérimentales que nous avons analysé pour l'étude cartographique étaient diverses à plusieurs égards, bien que deux d’entres elles se revendiquaient comme des répliques d'autres études. En particulier, seuls trois patterns étaient étudiés dans plus de la moitié des expériences que nous avons étudié - Composite, Observer et Visitor. Les différentes études se basaient sur un mélange de participants, incluant des étudiants avancés, des diplômés et des développeurs - tous disposant d'un niveau propre d'expérience avec les patterns, bien que l'étendue de cette expérience soit difficile à calibrer. Lors de l'interprétation, avec l'aide de l'étude expérimentale nous avons conclu ceci :

  • L'utilisation du pattern Composite semble créer quelques problèmes et nous avons noté que les utilisateurs devaient comprendre la récursion.
  • De la même manière, l'utilisation d'Observer semblait créer quelques problèmes, à commencer par le risque de créer des conceptions trop compliquées.
  • Par contraste, les retours des études sur l'utilisation de Visitor étaient plus ambivalents. D'un côté, sa complexité était perçue comme un frein à une utilisation efficace. D'un autre côté, quand il est utilisé correctement, Visitor peut en fait aider à la maintenance du système.

Nous avons mené nos enquêtes comme un moyen d'indiquer plus clairement quels patterns étaient considérés comme utiles dans quelles circonstances (quelque chose de difficile à identifier avec une unique expérience). Nous avons demandé aux sondés d'évaluer l'utilité de l'ensemble des 23 patterns du GoF (avec la possibilité de déclarer qu'un pattern ne leur était pas assez familier). Nous leur avons ensuite demandé d'identifier jusqu'à trois patterns qui leurs semblaient très utiles et, au contraire, jusqu'à trois patterns qui leurs semblaient inutiles

Avec quelques réserves, les patterns Observer et Composite sont arrivés au top des deux choix dans ce classement, ce qui a renforcé les résultats de l'étude cartographique. Aussi, comme nous l'avions fait lors de l'étude cartographique, les résultats relatifs au pattern Visitor étaient plus nuancés. Il y avait aussi un groupe de patterns considérés comme apportant une valeur ajoutée faible : Flyweight, Interpreter, Prototype et Memento, ce dernier n'ayant reçu aucun vote positif. Quelques patterns, tels que Chain of Responsabilcity, ont été identifiés comme étant utiles uniquement à des fins très spécifiques.

Tout comme pour le pattern Visitor, les votes pour les patterns Façade et Singleton étaient ambivalents. Aucun pattern n'a été étudié autrement que comme l'une des entrées de l'étude cartographique. Nous avons mené une seconde enquête pour clarifier quelles étaient les caractéristiques de ces trois patterns qui provoquaient des points de vues si divergents. Les raisons se sont révélées relativement différentes pour chaque pattern :

  • Visitor a été considéré comme utile seulement dans des cas limités, et il y avait des inquiétudes sur le fait qu'il pouvait faicilement mener à des contraintes et des problèmes d'implémentation.
  • Le pattern Singleton était aussi considéré comme ayant des buts très spécifiques - mais les inquiétudes exprimées avaient plus tendance à être portées sur son rôle alternatif qui consiste à stocker des variables globales dans les systèmes orientés objets. Certains sondés le voient comme un outil très pratique ; d'autres ont la sensation (profonde) qu'il est en conflit avec le modèle orienté objet.
  • Façade s'est révélé beaucoup moins controversé que les deux autres, mais certains sondés ont évoqué des inquiétudes sur les contraintes qu'il pourrait engendrer sur la maintenance du système.

Donc, bien que la plupart des sondés aient validé ces trois patterns, nous avions le sentiment que cette approbation était soumise à certaines conditions.

Donc, jusqu'où la "magie" opère-t-elle?

Peut-être inévitablement, les témoignages dont nous disposons sur l'utilisation des design patterns, montrent qu'ils sont une partie de la magie avec un bon renforcement du mythe. La table 1 recense les sept patterns pour lesquels l'une ou l'autre des études empiriques ont fourni une contribution utile à cette preuve.

Avec des mises en garde, cette table montre que les patterns Observer et Composite sont généralement soutenus par les données expérimentales et l'expérience. De la même manière, elle suggère que le pattern Visitor est soutenu dans le cas où il est utilisé avec précaution. Au delà de ça, les preuves expérimentales sont faibles, bien que les données expérimentales de l'enquête montrent un soutient généralement bon pour les patterns Abstract Factory, Façade, Factory Method et Iterator. Les résultats ont suggéré d'agir avec beaucoup plus de prudence avec les patterns Flyweight, Interpreter, Memento et Prototype. Par ailleurs (et en évitant le problème du Singleton), nous avons trop peu de données systémiques.

Donc, comment pouvons-nous répondre aux deux questions générales que nous nous sommes posées plus tôt à propos de l'efficacité des designs patterns?

  • En terme d'échanges de connaissances sur la conception, les patterns sont probablement efficaces entre les mains d'utilisateurs expérimentés, mais nos études combinées suggèrent que la courbe d'apprentissage implique des risques potentiels (pour une illustration de ce point, voyez le rapport de Peter Wendorff8).
  • En terme d'aide pour créer des produits dont le design est plus simple à comprendre et à maintenir, la question demeure sans réponse compte tenu des données qui étaient à notre disposition. La plupart des études expérimentales analysées lors de notre étude cartographique comprenait des participants qui effectuaient des tâches de maintenance, mais ils nous ont fourni trop peu d'informations sur les bénéfices liés à l’utilisation de patterns.

Beaucoup d'utilisateurs croient à l'efficacité des patterns et proposent des exemples pour appuyer leur point de vue. Toutefois, comme pour la magie du sorcier, l'utilisation des design patterns peut engendrer des effets indésirables, particulièrement lors de la période d'apprentissage du concepteur (un problème particulier identifié par Peter Wendorff8), et clairement, l'utilisation efficace des design patterns requiert bien plus qu'un catalogue, aussi bon soit-il.


* Les cases de la table sur fond vert indiquent le manque de données qui ont pu être rassemblées
**11 études expérimentales et sept rapports d'expérience
† Nombre total de votes pour : 389 ; Nombre total de votes contre : 113

Remerciements

Une grande partie de ce travail a été réalisée en collaboration avec Cheng Zhang au cours de sa thèse. Je suis aussi reconnaissant envers la School of Engineering and Computing Sciences, Durham University, pour le soutien apporté pour cette troisième étude d'affilé de même que Sarah Drummond pour son aide au niveau des analyses qualitatives.

Références

1C Alexander et al., A Pattern Language, Oxford Univ. Press, 1977.

2B. Adelson and E. Soloway, “The Role of Domain Experience in Software Design,” IEEE Trans. Software Eng., vol. 11, no. 11, 1985, pp. 1351–1360.

3F. Détienne, Software Design—Cognitive Aspects, Springer, 2002.

4E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

5C. Zhang and D. Budgen, “What Do We Know about the Effectiveness of Software Design Patterns?” IEEE Trans. Software Eng., vol. 38, no. 5, 2012, pp. 1213–1231.

6C. Zhang and D. Budgen, “A Survey of Experienced User Perceptions about Software Design Patterns” Information & Software Technology, 2012, in press.

7C. Zhang, D. Budgen, and S. Drummond, “Using a Follow-on Survey to Investigate Why Use of the Visitor, Singleton, and Façade Patterns Is Controversial,” Proc. 6th Int’l Symp. Empirical Software Eng. and Measurement (ESEM 12), ACM, 2012, pp. 79–88.

8P. Wendorff, “Assessment of Design Patterns during Software Reengineering: Lessons Learned from a Large Commercial Project,”Proc. 5th European Conf. Software Maintenance and Reengineering (CSMR 01), IEEE CS, 2001, pp. 77–84.

A propos de l'auteur

David Budgen est chef du département d'ingénierie logicielle à la Durhan University's School of Engineering and Computing. Ses sujets de recherches incluent la conception logicielle et l'evidence-based software engineering. David Dudgen détient un doctorat de physique théorique de l'Université de Durham. Vous pouvez le contacter ici.

Cet article a été publié pour la première fois dans le magazine IEEE Software. La mission de IEEE Software est de créer une communauté qui regroupe les acteurs actuels et futurs du développement logiciel. Le magazine propose des informations fiables, utiles et à la pointe du développement afin de maintenir les ingénieurs et les managers au courant malgré les rapides changements technologiques.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT