Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Design Patterns : où, quand, comment et pourquoi ?

Le sujet n’est pas récent mais on se rend compte souvent qu’il reste méconnu, au mieux quelqu’un citera le Singleton mais cela sera tout. A quoi servent les Design Patterns et pourquoi faut-il absolument les connaitre et les appliquer ? Et comment ?

Les Design Patterns

Comme beaucoup d’outils méthodologiques les Design Patterns ont eu leur heure de gloire, ce moment de succès fugace qu’on repère facilement à la machine à café, là où l’actualité brulante est débattue avec emphase par certains et surtout par effet de mode pour les autres. UML aussi a connu cet instant de grâce. Pas une seule proposition de SSII parisienne ne sortait sans un petit laïus sur UML à une époque. Les Design patterns font partie de ces méthodes ou outils méthodologiques qui firent l’actualité. Trois petits tours et puis s’en vont ! Mais autant on peut se passer d’appliquer systématiquement et partout les 13 schémas de UML, autant même une fois la mode passée on ne peut coder sérieusement en ignorant les Design Patterns !

Comment mieux définir les design patterns qu’en disant que ce sont des concentrés d’expérience ré-exploitables à l’infini de façon différente et ce, sans vous laisser sur votre faim… En effet, les design patterns ne sont à proprement parler ni une méthode, ni une technique et ne reposent sur rien d’autre que l’envie de ne pas réinventer la roue.

Si les design patterns peuvent exploiter la notation UML, ce n’est qu’à titre de support de documentation, comme un outil. La mode ou le progrès aurait pu ou pourrait faire qu’il en soit autrement.

Christopher Alexander, un architecte viennois ayant enseigné aux États-Unis, inventeur des design patterns, donnait dans son livre “A Pattern Language”[1] la définition suivante :

« Chaque pattern décrit un problème récurrent dans notre environnement, ainsi que ce qui constitue le noyau de la solution à ce problème, d’une telle façon que vous pouvez utiliser cette solution un million de fois sans jamais le faire deux fois de la même façon »

« Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice »

Cette définition nous vient ainsi du monde de l’architecture et non de celui des théoriciens de l’informatique ou des méthodologistes universitaires, mais bien d’un homme de terrain confronté à des problèmes récurrents dans l’exercice de son métier. Il est important de souligner ce fait, car UML aussi est issu des travaux d’hommes de terrain. Cela doit vous redonner confiance en la vertu de l’expérience et vous inciter à réfléchir encore et encore sur vos pratiques pour les perfectionner.

Dans le livre cité plus haut, Alexander et ses collègues donnaient la description de 253 solutions (ou design patterns) identifiées par un numéro (celui de la page du livre), un titre et une description détaillée du problème et de sa solution générique. C’est cette forme qu’on retrouve aujourd’hui reprise par tous les auteurs. En informatique, l’ouvrage de Erich Gamma[2], ‘Design patterns’, ouvrage faisant référence, est conçu selon le même schéma, selon la même... architecture. En traitant des design patterns en réutilisant le formalisme du livre de Alexander, Gamma a peut-être voulu nous indiquer le 254ème design pattern de cet ouvrage : sa façon de décrire la façon de décrire les design patterns !

Trêve de jubilation récursive, voyons en quoi les design patterns peuvent nous être utiles à nous, informaticiens, qui sommes les architectes non pas de tours ou de parkings, mais de logiciels.

[1] A Pattern Language C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel (New York: Oxford University Press, 1977)
[2] Design Pattern, Elements of Reusable Object-Oriented Software ; Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides; chez Addison-Wesley, octobre 1994.

Le formalisme

Un design pattern est généralement formé de quatre parties essentielles, à savoir :

  • Le nom du pattern, point d’accroche qui permettra de facilement retrouver le problème et sa solution. Ce nom doit donc être choisi avec soin.
  • Le problème lui-même, qui décrit le plus synthétiquement possible le contexte dans lequel s’applique ce design pattern.
  • La solution, qui décrit l’ensemble des éléments en jeu, leurs relations et leurs responsabilités. La solution est exprimée d’une façon générique et ne repose sur aucun cas concret pour être facilement transposable. La solution doit être abstraite pour mieux être concrétisée, un peu comme une classe abstraite permet de créer par héritages des classes concrètes.
  • Les conséquences qu’entraine l’application de la solution. En matière de développement, cela peut concerner la mémoire utilisée, le temps de calcul, les contraintes particulières que le langage choisi pour mettre en œuvre la solution doit pouvoir respecter…

Les deux points centraux (description du problème traité et solution apportée) justifient en général l’utilisation de UML pour illustrer le propos et le rendre plus universel.

Les diagrammes les plus souvent utilisés en la matière sont les cas d’utilisation, les diagrammes de classes, les diagrammes de séquences et de collaboration ainsi que les diagrammes d’états-transitions.

Refactoring Cérébral

L’intérêt des design patterns est de fédérer un savoir-faire, une expérience, et de capturer l’essentiel, la substantifique moelle de la solution. Ainsi peut-on facilement retrouver cette solution (l’identifier et en sortir la fiche, en quelque sorte) et surtout l’appliquer facilement à une situation concrète. Un design pattern est une sorte de moule à solutions. On apporte son problème, on le passe dans le moule, il en ressort une solution adaptée au cas particulier sur lequel on travaille.

Les design patterns sont l’anti-thèse de la réinvention de la roue. Et comme finalement le monde est partout le même, et que les problèmes, inexorablement, proviennent de causes similaires, de situations « classiques », de « cas d’école », il est raisonnable de vouloir réutiliser les solutions qui ont fait leurs preuves face à des problèmes finalement identiques ou proches dans leur nature.

C’est ce que permettent de faire les design patterns. Lorsqu’ils sont appliqués au développement, ils permettent à la fois de gagner du temps et de s’assurer qu’on utilise une « bonne » solution qui ne causera pas ultérieurement plus de problèmes qu’elle n’en réglait.

Le développement avec C#, dont la richesse en fait un outil générique, est l’occasion de croiser mille difficultés. Les plus habiles s’en sortent toujours mieux, mais la ruse n’est pas forcément la meilleure alliée… pressé par les délais à respecter, le plus malin des développeurs ne pourra prendre le temps de formaliser correctement son intuition, de se documenter en profondeur, et plus il sera rusé, plus la solution qu’il trouvera sera alambiquée et difficile à comprendre six mois plus tard. Un développeur vraiment malin consultera un guide de design patterns et codera la solution efficacement en ajoutant en commentaire « design pattern xxx » ; ainsi, même dans deux ans, tout le monde pourra comprendre, relire, corriger ou modifier son code (certains détestent les commentaires, moi j’aime bien ceux qui facilitent la relecture du code plus tard).

La POO a introduit la notion de réutilisation du code en créant des acteurs autonomes que sont les objets, les design patterns inventent la réutilisation des idées. Après avoir résolu un problème original on peut généraliser cette solution en créant un design pattern. En quelque sorte les design patterns ne sont qu’un refactoring cérébral…

Catalogue de design patterns

Classification

Si l’architecture possède ses règles et sa propre classification des design patterns les informaticiens ne sont pas en reste. Parmi les plus connues, la classification du Gang of Four[1] (GOF) est celle qui reste la plus citée.

Trois grandes classes de design patterns sont ainsi définies par le GOF :

  • Les creational patterns sont ceux qui touchent à la création des instances. Il n’y a pas de bonne traduction courte en français à ma connaissance (“patrons créationnels” pourrait aller mais personne ne saurait de quoi je parle donc autant garder le terme américain !).
  • Les structural patterns, patrons structurelles, sont ceux qui abordent la structure des objets.
  • Les behavioral patterns, patrons comportementales, sont ceux qui s’intéressent au comportement des objets.

Cette classification, même si elle fait autorité, n’est pas la seule possible. C’est toutefois celle que nous reprendrons ici car il est évident que c’est celle que vous risquez de rencontrer le plus souvent dans la littérature spécialisée.

[1] Les auteurs du livre évoqué plus haut dans cet article. Le Gang of Four, le gang des 4, est une allusion aux gang des 4 de la « révolution culturelle » en Chine (Jiang Qing – 4ème femme de Mao Zedong – Zhang Chunqiao, Yao Wenyuan et Wang Hongwen).

Le Catalogue

Il techniquement impossible de traiter ici de tous les design patterns et de montrer un exemple complet de chacun. C’est dommage car plus on en parle, plus on les pratique, et plus on les trouve beaux et attachants…

Je vais donc ici lister les design patterns du catalogue du GOF pour que vous puissiez vous faire une idée de l’étendue des sujets abordés.

Certains patterns vous sont forcément connus, d’autres beaucoup moins… Trouver l’implémentation d’un DP n’est pas compliqué surtout avec Internet. Le plus difficile c’est de connaitre cette liste par cœur et de savoir quand utiliser quel pattern !

Creational Patterns

Abstract factory

Ce DP permet de créer des instances pour des groupes, des familles de classes différents sans que le code qui les utilise n’ait à se soucier de ces groupes ou familles.

Builder

Ce DP décrit comment séparer la construction d’un objet complexe de sa représentation.

Factory method

Cet DP ressemble à l’abstract factory en permettant à une méthode de créer des instances dérivées d’une classe mère. Par exemple on peut supposer une gestion de document de différents types, des CV, des articles, des news, etc, chacun ayant sa structure interne propre. La factory method de la classe « document » permettra à l’application de gérer tout type de document et sera capable de créer les instances des parties différentes du document en fonction de son type (un CV comportera les parties identité, diplômes et expérience, un article comportera les parties titre, introduction, texte et conclusion, ainsi de suite…).

Prototype

Le prototype est une instance correctement initialisée servant de modèle à la création d’un clone. Cet DP permet par exemple d’implémenter une collection d’objets décrivant des formes géométriques qui, au lieu d’être utilisées directement pour créer des dessins seront d’abord dupliqués comme on pioche dans un stock d’outils.

Singleton

Ce DP est la star, celui qui vient en premier si on demande de citer un DP. Il permet de s’assurer qu’une seule instance d’une classe ne peut exister à un moment donné et fournit un point d’accès vers cette instance. Par exemple, une application gérant une machine outil voudra s’assurer qu’il ne peut pas y avoir au même moment deux instances de la classe permettant de commander la machine afin d’éviter que les ordres envoyés par plusieurs instances ne se mélangent. De façon générale dès qu’un objet interagit avec une ressource unique qu’il se réserve il est classique de le voir implémenter cette DP.

Structural patterns

Adapter

L’adapter (adaptateur) est un procédé permettant d’habiller en quelque sorte une classe en la faisant ressembler, du point de vue de son interface, à une autre. Par exemple on peut supposer une application qui travaille sur des objets de classe A exposant les méthodes M1 et M2. L’évolution du produit fait que la classe A est abandonnée au profit d’une classe B qui fait ce que faisait A mais différemment. Pour ne pas perturber l’ancienne application et dans l’attente de la reprogrammer on concevra un adaptateur se présentera comme étant de classe A avec les méthodes M1 et M2 et qui en réalité instanciera un objet de classe B avec d’autres méthodes qui feront le travail “sous le manteau”. L’appel de la méthode M1 par l’application sera traduite par l’adaptateur en l’appel des méthodes X1, X2 et X3 du nouvel objet. De fait, l’application aura toujours l’impression de travailler sur la classe A alors que la librairie sous-jacente sera totalement différente. Les nouvelles applications utiliseront elles directement la nouvelle classe.

Bridge

Ce DP créé un pont entre une classe et l’implémentation de tout ou partie de son code. On l’utilise par exemple lorsqu’on sait que l’implémentation d’une classe risque de changer dans le futur alors qu’on ne désire pas modifier l’application utilisatrice. On fige l’interface, utilisée par le client, et on délègue l’implémentation à d’autres classes. La classe d’interface étant liée à l’exécution à une classe d’implémentation contenant le code utile.

Composite

Le composite est un DP permettant de créer des structures arborescentes d’objets ayant une relation tout/partie tout en autorisant les clients de traiter les objets individuels et les compositions de façon uniforme.

Decorator

Avec ce pattern on dispose d’un moyen efficace pour accrocher de nouvelles fonctions à un objet dynamiquement lors de l’exécution. Cela ressemble à la fois un peu aux interfaces et à l’héritage mais c’est une troisième voie offrant des avantages différents. Les nouvelles fonctionnalités sont contenues dans des objets, l’objet parent étant dynamiquement mis en relation avec ces derniers pour en utiliser les capacités.

Façade

Il s’agit ici de proposer une .. façade masquant la complexité de tout un système. Par exemple une classe GestionDesStocks permettra de manipuler depuis d’autres endroits dans une chaîne de gestion commerciale l’ensemble des modules afférents à la gestion des stocks. Bien implémentée cette DP permet une incroyable modularité et la réutilisation simplifiée du code dans des applications complexes. L’implémentation “moderne” doit pour être fortement découplée souvent passer par une conteneur IoC par exemple mais ce n’est pas une obligation du pattern.

Flyweight

Cette DP autorise le partage de très nombreux objets de petite granularité de façon efficace.

Proxy

Cela n’a rien à voir avec les « proxy » du Web même si dans l’esprit il y a un fond commun. En réalité ce DP définit comment un objet permet d’en contrôler un autre. On l’utilise très fréquemment pour manipuler localement la représentation d’un objet distant (Remoting/WCF, services web, etc.).

Behavioral patterns

Chain of responsability

Ce DP définit une structure permettant de découpler un objet émettant des requêtes des objets chargés de les traiter. Dans une chaîne de responsabilité la requête est transmise d’objet en objet jusqu’à ce que l’un d’entre eux la traite.

Command

Lorsqu’un système doit gérer de nombreuses commandes qui peuvent être mises en attente et être éventuellement annulée il est intéressant de transformer chaque commande en un objet placé dans une liste. Un exemple très simple peut être celui d’un programme de type calculatrice permettant un niveau quelconque de undo. Chaque élément du calcul est un objet placé dans une liste. Le module de calcule traite la liste, la touche undo efface le dernier objet de la liste.

Interpreter

Ce DP propose une structure de classes permettant, à partir d’un langage et d’une représentation de sa grammaire, de pouvoir interpréter des phrases écrites dans ce langage.

Iterator

Ce DP propose un moyen d’accéder à tous les objets d’une liste séquentiellement sans avoir besoin d’exposer la structure interne qui maintient cette liste.

Mediator

Cet DP définit le fonctionnement d’un objet qui gère les interactions entre d’autres objets. C’est un médiateur. Les objets considérés ont ainsi un couplage très faible entre eux ce qui coïncide avec les guidelines les plus récentes. Par exemple un objet ChatRoom permet la communication entre des objets clients, chaque client peut communiquer avec d’autres clients mais aucun n’a accès directement aux autres clients. Tous communiquent en utilisant les services du médiateur.

Memento

Ce DP met en place un mécanisme permettant de capturer l’état interne d’un objet pour le stocker et restaurer ultérieurement l’objet dans le même état. Le DP memento peut être étendue en réalité à tout système de sérialisation. Les langages .NET comme C# exploitent les mécanismes de sérialisation offert par le framework ou des librairies tierces (Json.Net par exemple), ces mécanismes n’existaient pas “out of the box” à la création du catalogue du Gang Of Four. Avec les langages plate-formes modernes comme C# et .NET le DP memento perd de son intérêt mais il existe tout de même des cas où il peut encore jouer un rôle.

Observer

Lorsque plusieurs objets doivent être averti d’une notification il faut trouver un moyen pour distribuer le message. C’est ce que propose la DP observer (l’observateur). Ici aussi on peut reconnaitre des éléments des langages modernes. C# sait par exemple gérer les évènements à diffusion multiple (multicast events) qui ne sont autres qu’une façon d’implémenter le DP observer…

State

Ce DP décrit comment un objet peut modifier son comportement quand son état change. Par exemple un objet compte bancaire peut gérer différemment les retraits, le paiement d’intérêts et les frais de fonctionnement selon le solde que présente le compte. L’état interne peut être représenté par un objet qui applique les nouvelles règles. L’objet compte s’occupant de s’accrocher un objet état approprié selon sa balance.

Strategy

Pourvoir modifier un algorithme de façon transparente peut être très utile. On peut supposer une application permettant de trier des éléments selon des méthodes différentes. Ce DP explique comment mettre en œuvre le mécanisme rendant le choix de l’algorithme transparent pour l’objet l’utilisant.

Template method

Ce DP définit comment mettre en place un algorithme dont les étapes sont figées mais dont la réalisation de ces dernières peut être déléguée à d’autres objets offrant des variations de traitement. La DP template method créé en quelque sorte la trame immuable d’un traitement tout en laissant la liberté de réalisation de chaque étape à d’autres intervenants du système. Par exemple on peut définir dans un objet conteneur de données une méthode ExportData permettant d’exporter des données sous un format quelconque mais segmentant l’opération en étapes précises : OuvrirDestination, EcrireEntête, EcrireCorps, EcrirePied, FermerDestination. Toute exportation sera toujours faite de ces cinq étapes. Ensuite on peut implémenter des objets d’exportation implémentant ces cinq méthodes (exportation vers XML, CSV, etc.). La technique de la template method est extrêmement souple et s’adapte à de nombreux cas de figure.

Visitor

Le visiteur peut être vu comme l’opération complémentaire à l’itérateur. Le visiteur est une classe définissant une opération sur une autre classe. L’objet visité autorise l’appel d’un visiteur en publiant généralement une méthode prenant en paramètre une instance de visiteur. Comme il est ensuite possible de créer des dérivées de la classe visiteuse, on peut créer autant d’opérations différentes pouvant être appliquée à la classe visitée sans avoir à en modifier le code. Bien utilisée ce DP est très efficace pour laisser ouverte la définition de nouveaux traitements pouvant s’appliquer sur des collections d’objets (liste de clients, de salariés, articles…). La liste expose une méthode de type TraiterAvec(TypeVisiteur leVisitieur) dont le rôle est de balayer chaque élément en lui appliquant le visiteur. On peut ainsi, pour une liste de clients, créer un visiteur « promotion » qui créditera de points cadeaux les clients répondant à certains critères, un autre jour on pourra créer un autre visiteur envoyant un mail aux clients répondant à d’autres critères, etc. C’est un véritable jeu qui vitalise les idées !

Les DP dans le Framework .NET

Dans un article de juillet 2008 (oui ça fait loin !) je vous parlais d’un excellent petit bouquin écrit par des développeurs de l’équipe qui a écrit le Framework .NET. “Framework Design Guidelines” est vraiment toujours un super livre de référence surtout pour ceux qui doivent écrire des librairies un peu grosses pour les besoin de plusieurs applications. Vous pouvez jeter un œil à l’article de l’époque et voir si on trouve encore ce livre en vente, si c’est le cas, n’hésitez pas à l’acheter !

Ce livre évoque certains DP utilisés dans le Framework lui-même et c’est une première source qui m’a donné envie de faire une petite liste. Je n’ai jamais eu le temps de terminer ce jeu de piste (il faut dire que le code du Framework est un peu gros !) mais on peut toujours s’amuser à compléter la liste ci-dessous (et il y a matière à faire !) :

Creational patterns

Abstract Factory

On la retrouve dans DbProviderFactory de System.Data.Common, tous les membres de la classe sont des factory methods.

Builder

Toute l’infrastructure de construction des canaux de WCF. Mais plus simplement les builders de chaînes de connexion (comme SqlConnectionStringBuilder et équivalents). On trouve aussi UriBuilder qui implémente le même DP.

Factory method

IDbConnection.BeginTransaction() dans System.Data. Le type de la transaction créée dépend de l’implémentation de IDbConnection qui est instanciée. WebRequest.Create() dans un autre domaine du Framework retourne un type concret qui dépend de l’URL (son type). L’implémentation de la classe Convert peut aussi être vue comme une application de ce DP.

Prototype

Utilisé pour gérer la sérialisation / désérialisation.

Singleton

On ne trouve partout, la difficulté étant de savoir s’ils sont implémentés réellement comme des singleton ou s’il ne s’agit que de propriétés initialisées une fois. Les Settings d’une application WPF par exemple peuvent être considérés comme un singleton du point de vue de l’utilisation qui en est faite. Ce n’est pas forcément comme tel que cela est implémenté dans le code du Framework.

Structural patterns

Adapter

Les providers de ADO.NET comme par exemple SqlConnection (System.Data.SqlClient), OleDbConnection (System.Data.OleDb). Chaque provider est un adaptateur pour la base de données cible considérée. Les wrappers pour appeler du code COM (tlbimp.exe) depuis du code managé .NET est un autre exemple de mise en pratique de l’adaptateur.

Composite

Il y en a beaucoup, le plus évident étant System.Windows.Forms.Control et ses classes dérivées. Le même principe se retrouve dans System.Web.UI.Control et ses classes dérivées ou dans System.Xml.XmlNode et les classes qui en descendent.

Decorator

Sous WPF on trouve directement System.Windows.Controls.Decorator. Certaines implémentations de la classe Stream sont des décorateurs autour d’un flux interne (par exemple GZipSteam, CryptoStream, MemoryStream, BufferedStream, FileStream, IsolatedStorageStream, PipeStream,…).

Façade

Le XmlSerializer dans System.Xml.Serialization a pour but de cacher un processus plus complexe (qui inclut la génération à la volée d’assemblages) derrière une classe très simple à utiliser.

Proxy

Les proxies de Web services générés par svcutil.exe dérivant de System.ServiceModel.Clientbase<TChannel>.

Behavioral patterns

Chain of Responsability

OnBubbleEvent() dans System.Web.UI.Control et RaiseBubbleEvent().

Command

Les commandes de WPF et le ICommand très utilisé aujourd’hui pour respecter MVVM !

Interpreter

System.Linq.Expressions.Expression et toutes les classes qui tournent autour de ces expressions (représentation mémoire, interprétation, exécution).

Iterator

L’exemple peut-être le plus évident étant IEnumerable dans System.Collections et sa version générique IEnumérable<T>. Le IDataReader fonctionne aussi sur le principe de ce DP. Foreeach est bien entendu un élément du langage entièrement dédié à ce DP, le mot clé yield aussi.

Memento

La sérialisation .NET est une application du principe de ce DP.

Observer

Toute la logique des events de .NET.

Strategy

La méthode Sort dans ArrayList est un bon exemple.

Template Method

La méthode Render des Custom Controls.

Visitor

ExpressionVisitor dans System.Linq.Expressions qui est utilisé par Linq en interne.

Exemples d’implémentation

Il est bien entendu impossible de donner un exemple de chaque pattern sans transformer ce long article en un livre complet !

J’aurai bien commencé par le Singleton, mais il s’avère que très dernièrement (fin janvier) j’ai consacré tout un article à ce DP “Singleton qui es-tu ?”, je renvoie donc le lecteur vers cet article pour éviter des redites. Le pattern Observer aurait pu suivre le Singleton par son importance, mais là c’est le Framework qui me coupe l’herbe sous le pied puisque la gestion des évènements muticast y est implémentée de base (mot clé “event”).

Certains patterns sont particulièrement intéressants mais faire un choix est cruel et pour être parlants les exemples peuvent devenir longs.

Le plus sage est de laisser ces exemples pour plus tard et de traiter ponctuellement en profondeur un DP comme je l’ai fait fin janvier avec le Singleton.

Littérature

Quelques livres sont des classiques sur ce sujet, vous devez au moins posséder et connaitre le premier :

  • Design patterns, E.Gamma R.Helm R.Johnson J.Vlissides, chez Vuibert.
    C’est “la” référence.
  • UML et les design patterns, C.Larman, chez Campus Press.
    La notation UML au service des DP, un très bon livre mais qu’on ne trouve plus que d’occasion si on a de la chance.
  • Design pattern par la pratique, A.Shalloway et J.Trott, chez Eyrolles.
    Très bon mais comme le précédent ne se trouve plus que d’occasion. Si vous l’avez chez vous vous êtes riche ! Sur Amazon deux boutiques proposent le livre, l’un à 328,99€ et l’autre à 1360€ !!! Plaisanteries, arnaques ? Réelle valeur pour un collectionneur ? J’ai du mal à y croire. A ce prix là n’achetez pas, mais vendez !
  • Design Pattern pour C# de Laurent Debrauwer.
    En français, plus récent avec exemples C# et un prix “normal” !

En vous baladant sur Amazon vous en trouverez certainement bien d’autres, mais tous ne se valent pas !

Il existe aussi un produit de “dofactory” s’appelant “Pro .NET Design Pattern Framework 4.5” à 229€ tout de même. Il s’agit à la fois d’applications exemples pour chaque pattern, d’explications en PDF et d’une application “shell” pouvant servir de point de départ pour construire des applications. Les exemples sont bien faits et les docs fournies forment un ensemble cohérent.

La version “non pro” existe pour C# ou VB et coute déjà moins cher (79€) et couvre tous les patterns du GoF plus les bonnes pratiques pour REST, WPF, Entity Framework, Asp.Net MVC, MVVM etc. L’investissement est déjà plus rentable. Maintenu à jour mais sans être une référence absolue reconnue par la profession le code et les explications forment un catalogue vivant et facilement accessible.

Reste Bing ou Google et prendre un peu de temps pour chercher … On trouve des tas de choses, à trier sérieusement en revanche car le niveau est plutôt inégal !

Conclusion

Les design patterns, en tant qu’outil de l’esprit permettant de collecter et synthétiser le savoir-faire, offrent à ceux qui savent les utiliser une efficacité redoutable puisant sa force dans l’expérience éprouvée d’autres informaticiens.

Les design patterns ne sont pas une émanation de quelque sombre laboratoire où des chercheurs cloitrés auraient décidé sur le papier de ce qui est bon ou mauvais. À l’instar de UML les design patterns sont des purs produits de la science active et appliquée, créés par des hommes de terrain pour des hommes et des femmes de terrain.

Nous disposons aujourd’hui d’outils modernes de développement, puissants et couvrant de très nombreux domaines. Sans méthode ils ne sont que des usines à code spaghetti, en les utilisant avec des principes et méthodes SOLID (le jeu de mot était facile) comme les Design Patterns ils deviennent des leviers à votre propre talent pour en décupler l’étendue.

Stay Tuned !

blog comments powered by Disqus