DP : design patterns et bonnes pratiques

Préambule

Développer objet, composants, services c’est bien, développer avec des design patterns c’est mieux.

Sans entrer dans un tutoriel de design patterns¹, je voulais énumérer quelques patterns que j’ai pour habitude d’utiliser car cela permet de résoudre simplement des problématiques courantes.

Pour une définition, se référer à Wikipédia

En génie logiciel, un patron de conception (design pattern en anglais) est un concept destiné à résoudre les problèmes récurrents suivant le paradigme objet.

Après quelques années, on commence à avoir du recul sur son expérience de développement. A force d’écrire du code (ou à le refactorer), on cherche constamment à écrire du mieux possible telle partie ou tel module, pour une unique raison à mon sens : comment rendre le plus maintenable possible un système sur le long terme ?

Maintenable = modulable, souple, facilement évolutif, et ce, par tout ingénieur susceptible de toucher au code… vaste mission qui s’offre à nous.

Un mot que j’aime bien : entropie, que l’on peut transposer à une plateforme d’applications si on n’y fait pas attention : le degré d’instabilité d’un système augmente au fil du temps, et ce constat est corrélé au nombre de lignes de code qui augmente.

Aussi, autant prévenir que guérir² avant que le système s’écroule (c’est une image…) : bonnes pratiques, refactoring, design patterns, etc…sont autant de moyens afin de rendre le système le plus stable et évolutif possible.

Lesquels

Dans notre architecture, nous nous basons sur la plateforme .NET pour développer les projets. Sur celle-ci, les projets sont développés sous forme d’une architecture n-tiers, non pas MVC (bien qu’il existe des implémentations³ MVC dans le monde ASP.NET), mais une variante du paradigme⁴ PAC (et une petite dose de SOA avec les services Web), où l’on trouve la couche présentation (ASP.NET), une couche d’abstraction (contrôleur, entités) qui fait la liaison entre la présentation et la couche métier ci-après, et une couche d’implémentation pour les traitements (métier, DAL). Cela a l’avantage d’être souple tout en bénéficiant du modèle ASP.NET⁵ (ce que ne permet pas MVC pour l’instant)

Factory / Singleton

Dans ce type d’architecture, les implémentations sont instanciées dynamiquement (ie : lors de l’utilisation du contrôleur), pour se faire, nous avons besoin d’une Factory (typiquement contenu dans une classe Helper avec une méthode statique) voire d’une Abstract Factory.

Si l’on souhaite que notre instance ne soit pas créée à chaque fois par la Factory (pour économiser la mémoire, l’initialisation qui pourrait être longue, ...), on utilisera le pattern Singleton. En gros, l’objet est gardé en mémoire (par une variable statique). Dans ce cas, on fera bien attention à ce que l’instanciation de cet objet soit thread safe (ou sur IBM), dans un environnement multi-threading comme ASP.NET, cela peut générer des conflits.

Strategy

J’aime bien ce modèle car cela permet d’encapsuler et de déléguer à d’autres classes des actions à déclencher dans un contexte précis.

Strategy, cela utilise notamment le principe de l’injection de dépendance (très lié à l’IoC lorsque l’on parle de conteneurs tels que Spring ou Windsor).

Par exemple, comment à partir de mêmes données, générer un document PDF, Word, HTML, le pattern Strategy pourrait résoudre cette problématique proprement (sans faire un excès d’utilisation de l’héritage⁶) en délégant à des classes (PDF, Word, HTML) le soin de le faire.

Template Method

Ce pattern applique le principe d’Hollywood : “ne nous appelez pas, nous vous appellerons”. Autrement dit, on délègue la responsabilité de tout ou partie d’un traitement ou d’actions aux sous-classes qui dérivent de la classe mère qui définit le squelette des traitements à effectuer.

Cela peut s’avérer très utile dans un développement avec une approche plugins (ou de tâches), où la classe mère doit exécuter des sous services, elle ne fera qu’appeler une méthode qui devra être implémentée par les classes sous-jacentes qui dérivent de cette dernière.

Un exemple concret

Adapter

L’Adapter peut permettre lorsqu’on a un existant de faire évoluer le système sans tout casser, en se basant sur les interfaces existantes tout en les faisant évoluer.

Les candidats

J’aimerais pouvoir utiliser les DP suivants, même si le ou les contextes d’utilisation se sont déjà présentés :

• State pour gérer des états de façon évolutive et sûre, ou bien
• Memento, ou comment garder en mémoire (archivage) les différentes actions précédemment menées
• ...tout autre DP qui permettrait de résoudre un problème proprement

Conclusion

Le développement logiciel, et plus précisément le Web s’avère être un métier passionnant qui fait intervenir énormément de compétences et différentes facettes pour remplir à bien les missions.

J’aime particulièrement les bonnes pratiques, ancrées dans des principes souvent simples mais qu’il faut tenter d’appliquer à chaque nouveau projet ou module développé.

Ressources

On pourra citer pêle-mêle :

• les design patterns de Wikipédia, le site DoFactory, les design patterns du GOF en C# – avec les classes pour le cas d’école, et dans un cas concret pour illustrer
• DRY
• KISS
• Refactoring, ou sur Wikipédia, Refactoring
• plus largement, les principes de conception objets de Wikipédia
• POO, quelques rappels sur les grands principes de la conception objet, couramment utilisés dans les design patterns (responsabilité unique, ouvert-fermé, inversion de dépendance, principe de substitution Liskov, ...), l’héritage n’est pas une fin en soi.
• l’enfer de l’héritage

...toutes les bonnes pratiques et astuces d’optimisation du code axé sur le développement Web :

• ASP.NET performance,
• RSS & Web optimisations,
• un peu d’ASP.NET asynchrone
• Tips & tricks ASP.NET
• quelques règles simples pour optimiser l’accès à une page Web à l’aide de YSlow ou d’outil en ligne d’analyse
• C# Tips : un peu loin du sujet, mais quelques articles sur des aspects en profondeur de C#

Livres:

• Design Patterns: Elements of Reusable Object-Oriented Software
• Tête la première Design Patterns

¹ voir les ressources ci-après

² si l’entropie est trop forte alors le système s’écroule : il devient inmaintenable, et il n’est plus possible de le faire évoluer

³ ProMesh, MonoRail et bien sûr ASP.NET MVC

⁴ je ferai prochainement un billet sur ce modèle d’architecture

⁵ Evénements (cycle page/contrôles), ViewState, Postback, gestion fine des contrôles, ...

⁶ on privilégiera la composition à la place de l’héritage à multi-niveaux (ie : en ajoutant sans cesse des couches de classes), catastrophique pour une bonne évolution du système.