TD 2 : Les design patterns GRASP

Maintenant que vos bases sont consolidées nous allons pouvoir attaquer de nouvelles choses, des nouveaux concepts qui pourront vous servir pendant la phase de conception : les patterns !

Qu’est-ce qu’un pattern ?
Un pattern est un ensemble de règles qui permettent de répondre à un problème récurrent.
Autrement dit, un pattern est une solution générique qui permet de répondre à un problème donné que l’on peut rencontrer très souvent dans la phase de développement. Ces patterns sont, pour la plupart, directement issus du bon sens du concepteur, et leur représentation est tout aussi intuitive.

Un pattern doit donc répondre à certains aspects essentiels :

  • Un pattern a un nom évocateur, qui représente bien l'essence même de son existence.
  • Un pattern fourni une solution à un problème récurrent donné
Il en existe énormément qu’on peut appliquer pendant la phase de conception mais nous allons nous attarder sur les GRASP patterns.

Tout d'abord que signifie GRASP ? Il s'agit de l'acronyme de General Responsability Assignement Software Patterns, ou patterns généraux d'affectation des responsabilités. Il s'agit de patterns fondamentaux qu'il est nécessaire d'appliquer pour une bonne conception.

Voyons donc certains de ces patterns.

Les objectifs de ce TD :

  • Présenter un nouveau concept : les patterns
  • Présenter une première famille de design patterns "simples"
  • Vous permettre d'appliquer ces nouveaux éléments sur des exemples concrets


Conclusion


Ce second TD vous a permis de vous familiariser avec un nouvel outil, les patterns (patrons) qui permettent de faciliter le travail du développeur lors de la conception d’un système.

Au cours des prochains TDs nous verrons d’autres patterns qui pourront s’appliquer aussi pendant la phase de conception mais qui auront davantage d’impact pendant la phase de programmation que ceux vus dans ce TD.

Conseils / Les erreurs à ne pas commettre


Etant nous mêmes étudiants nous avons eu l'occasion d'utiliser ces patterns mais pas toujours de la bonne façon... Voici donc quelques conseils, remarques personnelles pour vous aider lors de l'application de ces patterns :
  • Pour le pattern Créateur il est très important de se poser la question "Quelle classe est la plus à même d'utiliser l'instance que je vais créer ?" car c'est avec cette question que vous trouverez plus facilement la bonne classe qui n'est pas forcement la classe la plus "cohérente"
  • Ne pas confondre le faible couplage et la forte cohésion ! Le couplage définit le nombre de relation d'une classe tandis que la cohésion mesure la cohérence d'une classe
  • Pour le pattern Contrôleur il faut bien comprendre que c'est le contrôleur qui fait le lien entre l'interface graphique et les fonctionnalités et donc qu'il s'occupe de l'interprétation que ce soit dans un sens ou dans l'autre
  • Ne pas abuser du polymorphisme ! En effet ce n'est pas parce qu'une classe veut posséder une méthode d'une autre qu'il faut forcement faire un héritage. On peut très bien utiliser des interfaces comme nous le verrons dans les TDs suivants. Il ne faut utiliser l'héritage qu'en cas de relation "est un"

Auto-évaluation


Chaque pattern possède un exemple d'entrainement que vous pouvez appliquer. Pour conclure ce second TD nous allons vous proposer un QCM dans lequel des questions sur tous les patterns présentés vous seront proposé.

-- Scripts -->