Magazine

DP : design patterns et bonnes pratiques

Publié le 04 février 2008 par Olivier Duval

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 patterns1, 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érir2 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émentations3 MVC dans le monde ASP.NET), mais une variante du paradigme4 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.NET5 (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éritage6) 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 :

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

Livres:

1 voir les ressources ci-après

2 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

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

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

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

6 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.


Vous pourriez être intéressé par :

Retour à La Une de Logo Paperblog

Ces articles peuvent vous intéresser :

  • Techdays 2010, jour 2

    2è jour des techdays. J'assisterai à la plénière à distance, du bureau, grâce à la rediffusion en directe, pour rejoindre ensuite le palais des congrès pour... Lire la suite

    Par  Olivier Duval
    A CLASSER
  • Top des billets d'août 2009

    Top des billets consultés pour ce mois d'août, tout le monde n'était pas en vacances à ce que je vois : jQuery, autocomplete, JSON NHibernate : HQL et Criteria... Lire la suite

    Par  Olivier Duval
    A CLASSER
  • jTemplates, jQuery et Piwik : I'm watching U !

    jTemplates, jQuery Piwik watching

    Genèse Acte 1 : aux techdays 2009, j'ai assisté à une session sur les nouveautés ASP.NET 4.0, dont MS Ajax Pure Client Model qui propose des contrôles côté... Lire la suite

    Par  Olivier Duval
    A CLASSER
  • Techdays 2009 : jour 1

    Les techdays 2009 c'est 16 000 inscrits pour les 3 jours, et le plus grand évènement européen, organisé par Microsoft et ses partenaires. Lire la suite

    Par  Olivier Duval
    A CLASSER
  • WCF, premiers pas

    Préambule J'ai une grande passion dans la vie : que les systèmes interagissent entre eux, l'interopérabilité, l'échange de données, ce petit côté magique qui... Lire la suite

    Par  Olivier Duval
    A CLASSER
  • Links #11 : jQuery

    Quelques conseils sur l'utilisation de jQuery une aide en ligne très bien réalisée avec exemples de code a l'appui jQuery et ASP.NET après une introduction sur... Lire la suite

    Par  Olivier Duval
    A CLASSER
  • Retour au Jeu des Dictionnaires

    Retour Dictionnaires

    Quelle bonne idée que cette rediffusion sur la Trois de certaines émissions du « Jeu des Dictionnaires » dans sa version télévisée. Il y aura beaucoup à en... Lire la suite

    Par  Jacquesmercier
    CULTURE, MÉDIAS

A propos de l’auteur


Olivier Duval 4 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte

Dossier Paperblog