Design patterns : l'introduction

La programmation avec design patterns

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
Pendant plusieurs années de développements des applications, des programmeurs étaient confrontés à des problèmes récurrents. Comment créer et utiliser une seule instance d'un objet ? Comment encapsuler la création d'un objet ? Ce ne sont que 2 questions parmi tant d'autres qu'ils devaient se poser à travers des années. Une seule réponse à elles existe et s'appelle design patterns.

Qu'est-ce que c'est design patterns ?
Les design patterns (patron de conception) ne sont rien d'autre qu'un modèle de réponse à des problèmes de développement logiciel récurrents. Ils permettent d'accélérer le temps de développement et de faciliter la maintenance de l'application. En appliquant ces patrons de conception, le développeur évite les erreurs qui ont déjà été commises par d'autres développeurs avant lui. En plus, la bonne utilisation des design patterns facilite la comprehénsion du code. A sa lecture, on peut déduire très rapidement que pour un tel patron de conception, un objet va se comporter de cette manière et non pas d'une autre.

Trois familles des design patterns existent :


  1. Créationnelle
    Comme son nom indique, cette famille est responsable de la création des objets. Si l'on voudrait rapporter cette définition dans le monde réel, on pourrait dire que c'est une sorte d'usine qui produit des objets. Parfois, un seul produit suffit, autre fois des produits différents doivent être fabriqués, en fonction du bon de commande.


  2. Structurelle
    L'organisation des objets est également un point important. Dans cette famille on trouvera tous les éléments nécessaires pour la composition de nouveaux objets à partir des objets déjà existant. Elle se charge aussi de définir les liens entre des objets. Grâce à ces modèles on peut garantir qu'une modification d'un bout de système n'aura pas de mauvaise influence sur le reste de l'application. Le monde réel nous amène l'image de cette famille avec une voiture. La voiture est une composition complexe. Mais malgré cela, on l'utilise sans se poser de questions sur tout ce qui est à son intérieur.


  3. Comportementale
    Les modèles représentés par cette famille sont chargées de coordonner le travail entre les objets. Dans le monde réel on peut les comparer à un chef d'orcestre qui veille à ce que la flûte ne chante pas avant la guitare. Cela ressemble un peu au modèle structurel, sauf qu'il s'agit ici des interactions entre les objets et non pas de la structure de ces objets.



Qu'est-ce que sont anti-patterns
En évoquant les design patterns, il ne faut pas oublier les anti-patterns. Vu que les design patterns sont les choses à faire, on peut déduire que les anti-patterns sont les choses qu'il faut éviter dans le développement des applications. Ils représentent donc de mauvaises pratiques qui sont contre-productives.

Parmi les anti-patterns on retrouve aussi la mauvaise implémentation des patrons de conception. Parfois on essaie de placer ces derniers partout dans le système, ce qui au final peut amener plus du mal que du bien. Certains endroits sont alors complexifiés à tel point que leur maintenance provoque à chaque fois l'appropriation du code par le développeur.

Un autre antipattern est l'erreur du copié-collé que l'on fait sans se demander pourquoi. Dans ces mauvaises pratiques on retrouve aussi :
- la maintenance du code mort (celui qui ne fait rien)
- l'implémentation du code dont on n'a pas besoin dans l'immédiat (mais qui sera "certainement" utile dans l'avenir, connu aussi sous l'acronyme AYGNI)
- le code spaghetti (le code dont les modifications rapides et sécurisées sont quasiment impossibles à cause de sa composition tragique)
- l'objet divin qui représente un objet qui assure trop de fonctions essentielles du système

Cet article devait être une bonne introduction aux patrons de conception précis qui seront présentés plus loin sur le site. On a bien vu que la divinité n'est pas bien aperçue dans tous les cas et que le spaghetti peut avoir parfois un goût amer. Pour éviter ces mauvaises surprises, on peut très bien emboucher un chef d'orchestre qui roulera dans une voiture fraîchement sortie d'une usine.
Bartosz KONIECZNY 08-09-2013 17:30 design patterns
Moi

Développeur d'applications Internet et journaliste passionné par l'adjectif français. Un aigle polonais orienté vers la progression, volant très haut et écoutant du zouk après les matches du foot français.

Vous appréciez mon travail ?

Pour contribuer au développement de ce site, ou pour remercier pour des articles rédigés, vous pouvez faire un don.

Un conseil Symfony1

Comment passer une variable depuis l'action vers le layout ?

Pour ce faire on peut utiliser les slots en appelant dans notre fichier d'action la méthode setSlot() :

$this->getResponse()->setSlot("titre_du_slot", array("12345"));

On le récupère dans le layout par la méthode get_slot() :
get_slot("titre_du_slot") ;