nov. 17 2010

[ASP.NET] Design Patterns et Best Pratices - Partie 1 : Introduction

J'entame par ce billet une nouvelle série sur les Design Patterns et les Best Pratices en ASP.NET. Une série est actuellement en cours sur l'amélioration des performances d'une application Web, mais ça ne fait pas de mal de varier de temps en temps. Je vais d'abord introduire rapidement les Design Patterns, les Enterprise Patterns de Martin Fowler, les principes S.O.L.I.D de Robert Martin (alias Uncle Bob) ainsi que le développement en couche. Puis je présenterais, au fur et à mesure des billets des cas pratiques orientés ASP.NET, avec au passage la présentation du Pattern MVP, pour finir par le très actuel MVC (qui au passage atteint sa version 3).

On me demande souvent pourquoi je blogue sur les Web Forms, et si peu sur MVC. Beaucoup pensent qu'on ne peut faire de bons développements avec les Web Forms. Oui pour utiliser les Web Forms il faut bien maîtriser le cycle de vie d'un page et comprendre les mécanismes du ViewState et d'autres spécificités encore. C'était justement ça l'attrait : le défi technique ! Mais il faut savoir tourner la page et profiter des améliorations et gros changements qu'apportent ASP.NET MVC. Promis, après cette série j'orienterais mes articles uniquement sur MVC :-)

Notre travail en tant que développeurs implique la résolution de problèmes (sans parler de la compréhension des besoins utilisateurs). Ces problèmes, d'autres développeurs ont eu à les résoudre de nombreuses fois avant nous mais sous des formes diverses. Depuis l'arrivée de la POO, un certain nombre de modèles, de principes et de Best Pratices ont été découverts, formalisés et catalogués. Avec la connaissance de ces modèles et d'un vocabulaire commun, nous pouvons résoudre des problèmes complexes et développer des applications d'une manière uniforme avec des solutions éprouvées et fiables.

Design Patterns

Les Design Patterns sont de modèles de solution d'un niveau d'abstraction élevé. Il faut penser à eux comme à des templates de solutions plutôt qu'à des solutions. Vous ne trouverez  jamais un framework ou une librairie que vous pourrez simplement appliquer à votre application. Vous utiliserez plutôt les Design Patterns en pratiquant le refactoring de votre code et en généralisant votre problème. Les Design Patterns ne sont pas juste applicables au développement d'application, ils peuvent être utilisés dans tous les domaines de la vie :de l'ingénierie à l'architecture (pour les bâtiments, pas pour l'informatique).

Christopher Alexander a introduit l'idée de modèles il y a maintenant quarante ans afin de construire un vocabulaire commun pour les discussions de conception. Les propos de cet architecte sont on ne peut plus révélateurs : "Les éléments de cette langue sont des entités appelées modèle. Chaque modèle décrit un problème qui se produit encore et encore dans notre environnement et décrit ensuite le noyau de la solution à ce problème de façon à ce que vous pouvez utiliser cette solution un million de fois, sans jamais procéder de la même façon deux fois". Cette citation est tout aussi applicable à la conception de logiciels comme elle l'est à la conception de bâtiments ou à l'urbanisme.

Les Design Patterns qui sont maintenant très répandues (mais toujours pas assez...) dans l'architecture logicielle sont nés de l'expérience, de la perte de cheveux et des connaissances de développeurs à travers de nombreuses années d'utilisation de la POO. Un ensemble de modèles les plus communs ont été catalogués dans un livre intitulé Design Patterns: Elements of Reusable Object-Oriented Software, plus connu sous le nom de la Bible des Design Patterns. Ce livre a été écrit par Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides, mieux connus sous le nom de Gang of Four.

Ils ont recueilli 23 modèles de conception et les ont organisés en 3 groupes:

  • Les modèles de construction (Creational Patterns) qui définissent comment réaliser l'instanciation et la configuration des classes et des objets.
  • Les modèles structuraux (Structural Patterns) qui définissent comment organiser les classes d'une application dans une structure plus large, sépérant l'interface de l'implémentation.
  • Les modèles comportementaux (Behavioral Patterns) qui définissent comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilités) et expliquent le fonctionnement des algorithmes impliqués.

Chaque Pattern est présenté selon un formalisme précis afin que les lecteurs puissent apprendre à déchiffrer et à appliquer le modèle. Je reviendrais plus loin sur le détail de ce formalisme, mais pour les futurs exemples, j'utiliserais une version simplifiée de celui-ci. Les Design Patterns sont essentiels pour la conception de logiciels et le développement. Ils permettent aussi de s'exprimer à travers un vocabulaire commun lors de la résolution de problèmes mais aussi dans le code. Les Patterns facilitent la conception et le développement d'application POO et sont construits autour de solides principes de conception orientée objet.

Avec une bonne connaissance des Patterns, vous pouvez communiquer rapidement et facilement avec d'autres membres d'une équipe sans avoir à vous préoccuper des détails d'implémentation de bas niveau. La raison simple est qu'ils ne dépendent pas d'un langage particuler et, par conséquent, ils sont transférables sur d'autres langages orientés objet. Les connaissances acquises grâce à eux seront utiles dans n'importe langage que vous utiliserez pour la POO (mais en C# c'est mieux !).

Utilité (et réutilisabilité)

La plus grande utilité des Design Patterns réside dans le fait qu'ils sont des solutions éprouvées, ce qui donne confiance en leur efficacité. Si vous êtes un développeur expérimenté et utilisez un langage orienté objet (C# bien sûr...) depuis un certain nombre d'années, vous pourriez découvrir que vous utilisez déjà quelques-uns des modèles de conception mentionnés dans le livre du Gang of Four, pour ne pas dire La Bible. Toutefois, en étant en mesure d'identifier les modèles que vous utilisez, vous pouvez communiquer beaucoup plus efficacement avec d'autres développeurs qui, avec une compréhension des Patterns, seront capables de comprendre la structure de votre solution.

Le maître mot des Patterns est la réutilisabilité. Tous les problèmes ne sont pas égaux, bien sûr, mais si vous pouvez décomposer un problème et trouver des similitudes avec d'autres problèmes qui ont été résolus avant, vous pouvez ensuite appliquer ces solutions. Mine de rien, la POO n'est plus toute  jeune vu qu'elle date des années 70. Après tout ce temps, la plupart des problèmes que vous rencontrerez auront déjà été résolus un nombre incalculable de fois. Même si vous pensez que votre problème est unique, en le décomposant vous devriez être capable de généraliser suffisamment pour trouver une solution appropriée.

A noter tout de même, à propos du vocabulaire commun, qu'il est nécessaire de connaître le nom de ces Design Patterns. J'ai déjà vu plusieurs développeurs capables de m'expliquer en détail le fonctionnement d'un modèle, mais sans pouvoir mettre le nom dessus. Avouez que dans ce cas précis, ça ne fait qu'embrouiller la discussion :-)

 

Ce qu'ils ne sont pas

Les Design Patterns c'est bien, mais ça demande un niveau minimum de compréhension et de réflexion. Vous devez bien comprendre votre problème, le généraliser, puis utiliser un Pattern qui lui soit applicable. Toutefois, tous les problèmes ne nécessitent pas l'utilisation d'un Design Pattern. Il est vrai que les Patterns peuvent aider à rendre simple des problèmes complexes, mais ils peuvent aussi rendre complexes des problèmes simples !

Le piège est classique, et j'avoue être moi aussi tombé dedans plusieurs fois, une fois les Patterns compris de nombreux développeurs essayent d'appliquer des modèles pour tout ce qu'ils font. Ils réalisent ainsi tout à fait le contraire de ce qu'ont pour but les Design Patterns : rendre les choses simples. La meilleure façon d'appliquer ces modèles est de détecter le problème fondamental que vous essayez de résoudre. C'est pourquoi il est plus que recommandé de voir plusieurs exemples ou cas pratiques pour s'entraîner à l'identification d'un problème, avant de les utiliser à tort et à travers dans toutes les parties de votre code.


Ceci clore l'introduction de cette série. Dans le prochain billet, avant d'aborder en détail comment utiliser les Patterns pour le développement ASP.NET (que ce soit ASP.NET 2.0, 3.5, 4.0 ou encore ASP.NET MVC), nous verrons les principes fondamentaux comme les principes S.O.L.I.D ainsi que le développement en couche.

Tags: , , , ,

Commentaires

1.
pingback topsy.com says:

Pingback from topsy.com

Twitter Trackbacks for
        
        [ASP.NET] Design Patterns et Best Pratices - Partie 1 : Introduction
        [nicolasesprit.com]
        on Topsy.com

2.
trackback Nicolas Esprit says:

[ASP.NET] Design Patterns et Best Pratices - Partie 2 : Principes de conception et principes SOLID

[ASP.NET] Design Patterns et Best Pratices - Partie 2 : Principes de conception et principes SOLID

3.
trackback ASP.NET Français Blogs says:

[ASP.NET] Introduction MVC 4 - Part 3 : MVC c'est quoi ? Quels avantages ?

Le patron de conception Modèle-Vue-Contrôleur est un patron de conception architectural

Les commentaires sont clos