Chapitre 1 : Les patrons du GoF

Introduction
Les patrons de conception décrivent des solutions prouvées et standards (abstraites) pour
répondre à des problèmes récurrents de conception de logiciels.
Ouvrage : Design Patterns : Elements of Reusable Object-Oriented Software - Gang of Four (GoF)
1995

Catégories de patrons présentées

1. Patrons de création : Décrivent comment régler des problèmes d'instanciation de classe
(création) et de configuration d'objets.
Exemple : patron Singleton
2. Patrons de structure : Décrivent comment structurer les classes avec un minimum de
dépendance entre l'implémentation et l'utilisation dans différents cas.
Exemple : Patron Composite
3. Patrons de comportement : décrivent comment structurer les classes pour assurer le
comportement de l'application
Exemple : Patron Observer

Remarque : Les patrons de Gang of Four sont destinés à résoudre des problèmes de conception
dans le paradigme orienté objet.

Avantages de l'utilisation des PDC

● Les PDC constituent un langage de communication entre les concepteurs.
● Ils permettent de répondre à un problème grâce à une solution prouvée.
● Ils permettent de gagner en temps (coûts) et en qualité.
● Ils peuvent être adaptés à différentes situations.
● Ils sont indépendants des langages l'implémentation.

Inconvénients de l'utilisation des PDC

● Les PDC nécessitent d'être adaptés à chaque situation.
● Un patron nécessite d'être connu et maîtrisé pour pouvoir être utilisé.
● L'utilisation des patrons risque d'augmenter la complexité d'une solution simple.

Remarque : L'utilisation d'un patron dans une solution ne fait pas forcément d'elle une solution de
qualité (le patron doit convenir au contexte et doit être correctement adapté).

1. Patrons de création : Patron Singleton

Son but est de restreindre l'instanciation d'une classe à une seule
instance.

2. Patrons de structure : Patron Composite :

C'est un patron de structure qui permet de concevoir une hiérarchie d'éléments (arbre) tout en
permettant de manipuler différents objets simples et composites ayant un dénominateur commun
comme un seul objet.
Ce patron rend uniforme la manipulation des différents éléments de la structure.
● La classe Element : C'est une abstraction pour tous les éléments qu'ils soient simples ou
composites. Ainsi, Element offre une interface pour le comportement commun des tous les
éléments.
● La classe Feuille : Représente l'élément simple (qui n'a pas de sous éléments) et implémente
le comportement commun.
● La classe Composite : C'est l'élément ayant des sous-éléments.
● La classe Client : Manipule tous les objets de façon identique à travers la classe Element.

3. Patrons de comportement :
3.1. Patron Observateur
Ce patron de comportement permet d'observer un objet pour aviser d'autres objets de son
changement et leur permettre ainsi de lancer un traitement adéquat avec le changement constaté.
Ce patron permet de lier les observateurs et le sujet tout en réduisant les dépendances.
Eléments du patrons :
1. Subject :
● Il garde une trace de ses observateurs ;
● Il propose une interface pour ajouter, supprimer et modifier ses observateurs.
2. Observer :
● Définit une interface pour lancer la mise à jour.
3. Concrete Subject:
● Enregistre son état intéressant ;
● Notifie ses observateurs lors du changement d'état.
4. Concrete Observer :
● Il connaît son sujet ;
● Lit l'état du sujet ;
● Implémente l'interface de mise à jour.

Exemple d'utilisation du PDC Observateur :

Soit l'application suivante qui affiche un ensemble de données variables (modèles) sous 3
interfaces différentes (vues).
Pour dire qu'un objet est un sujet, il faut qu'il procède une information importante qui intéresse
d'autres objets et que cette information change d'état.
Pour dire qu'un objet est Observateur, il faut qu'il s'intéresse à des informations gouvernées par un
autre objet et qu'il soit capable de changer son état selon le changement de ces dernières.

3.2. Patron Stratégie :

Ce patron de type comportement permet de séparer un objet de ses comportements et de rendre
ces derniers interchangeables et "sélectionnables" au moment de l'exécution. Ainsi, ce patron
encapsule les comportements d'un objet dans des classes, et si on veut ajouter ou supprimer un
comportement on crée ou on supprime une classe.

Remarques :
Classe Stratégie : utilisée par le contexte pour exécuter un comportement et c'est une interface
commune de tous les comportements (les différentes stratégies).
Classe St1, St2,..Stn : utilisent l'interface commune pour implémenter un comportement particulier.
Classe Contexte : maintient une référence vers un objet Stratégie et la stratégie à lancer sera
choisie au moment de l'exécution.

Chapitre 2 : le patron MVC (Model-View-Controller)

Introduction :
MVC est un patron d'architecture qui remonte aux années 70. Donc le but est de structurer des
applications interactives avec les utilisateurs.
L'idée est de bien séparer les données et les traitements métiers, la présentation et les traitements
de contrôle.
Le patron MVC représente la conception d'un système logiciel en 3 modules ce qui donne une
meilleure maintenabilité à ce système.
1. Model : représente la logique métier de l'application et la gestion des données.
2. View : représente l'interface graphique du système.
 3. Controller : gère les événements issues des l'interface pour ensuite les répercuter sur le
modèle.

Relations entre les différentes parties du patron :

- Vue - Contrôleur : Patron Stratégie ;
- Contrôleur - Modèle : Invocation de méthodes pour modifier les données ;
- Vue - Modèle : Patron observateur

Chapitre 3 : Développement par composant

Introduction :
Ce développement repose par les mêmes principes que le développement des composants
électroniques (Interfaces et Fonctionnalités).
Un système logiciel peut également être conçu et développé comme un assemblage de
composants logiciels (chaque composant peut être remplacé par un autre possédant les mêmes
interfaces et la même fonctionnalité).
On distingue 2 activités de développement :
- Le développement pour la réutilisation (For reuse)
- Le développement par la réutilisation (By reuse)

Comparaison entre le développement orienté objet (OO) et le développement orienté

composant (OO) :
● L'OO est plus répandu vu que les développeurs sont plus familiarisés avec ;
● L'OO est supporté par plus d'outils et plus de méthodologies ;
● Certains projets ont une certaine réticence envers l'OC vu qu'ils ne connaissent pas
l'implémentation de ce dernier ;
● Le bénéfice de l'OC ne peut se voir qu'à long terme (après plusieurs réutilisations) ;
 ● Un énorme travail d'analyse est nécessaire pour favoriser un logiciel en composants ;
● La rédaction des interfaces des composants nécessite un effort supplémentaire pour éviter
toute modification de ces dernières : Toute mise à jour sur l'interface, à la différence des
autres parties du composants, rend le composant inutilisable dans son environnement ;
● La phase de conception dans l'OC prendra un rôle beaucoup plus important ;
● L'OC favorise la productivité par le gain de temps et de qualité qu'il offre ;
● Les composants peuvent être développés dans des langages différents ce qui permet de
profiter de la puissance d'un langage dans un domaine donné ;
● La facilité de mettre à jour un composant (à part l'interface) puisque ça ne nécessite pas la
recompilation du projet complet, et même après livraison au client, il n'y aura que le
composant mis à jour qui sera relivré ;
● L'orienté composant favorise la sous-traitance, l'externalisation et la répartition du travail sur
les équipes.

Définitions :
1. Composant : appelé COTS (component on the shell) ou "composant ramené du marché".
Peut être vu comme morceau de logiciel assez petit pour que l'on puisse le créer et le
maintenir, et assez grand pour que l'on puisse l'installer et assurer son support. Il existe des
composants de natures différentes, mais ils ont tous la propriété : autonome, réutilisable,
composable et configurable.