Describe more patterns (observer, ...)

content/technologeek/books/2024-02-25-head-first-design-patterns/index.md

@@ -24,6 +24,8 @@ Pour rappel, la Programmation Orientée Objets se base sur les principes suivant
 
 ## Creational
 
+Les patterns ci-dessous sont orientés sur la nécessité de découpler des composants entre eux.
+
 ### Factory & Abstract Factory
 
 
@@ -32,6 +34,8 @@ Pour rappel, la Programmation Orientée Objets se base sur les principes suivant
 
 ## Behavioral
 
+Les patterns liés au comportement permettent de simplifier (ou mieux structurer) les intercations entre plusieurs composants.
+
 
 ### Command
 
@@ -136,6 +140,15 @@ Chaque état implémente une interface commune, et chaque méthode de cette inte
 
 ### Observer
 
+L'idée de ce pattern est de partir d'un ensemble d'observateurs, qui veulent pouvoir s'abonner ou se désabonner d'informations qu'un sujet pourrait leur communiquer.
+La modélisation en exemple reprend une station de météo, qui envoie régulièrement des données actualisées.
+Les observateurs reçoivent ces données pour les afficher différemment (= _Display_), suivant le type d'observation (Conditions météorologiques actuelles, statistiques, prévisions, ...).
+
+![](observer.png)
+
+Comme améliorations, des propriétés du sujet peuvent être rendues publiques, afin que les observateurs puissent "choisir" spécifiquement les informations qu'ils pourraient vouloir afficher.
+
+
 
 ### Strategy
 
@@ -157,6 +170,8 @@ De la même manière, nous pouvons implémenter des personnes d'un jeu de rôles
 
 ## Structural
 
+Les patterns de type structure sont orientés sur la modélisation de larges structures (arborescences, simplification de l'accès à certaines ressources, simplification d'interface, limitation de paramètres pour les intercations avec certains composants, ...).
+
 ### Composite
 
 L'intérêt des composite est de représenter des éléments contenant d'autres éléments d'un même type.
@@ -176,6 +191,14 @@ Attention qu'en termes de performances, ce pattern doit généralement être cou
 
 ### Façade
 
+Une **façade** consiste à encapsuler un ensemble de composants, en les référençant depuis un autre, afin d'en simplifier la chronologie d'appels.
+
+![](facade.png)
+
+Il s'agit d'une application du principe de ***Least Knowledge*** - aussi lié au principe de Ségrégation des interfaces) : si une instance doit appeler une deuxième instance, afin de récupérer à partir d'une troisième, nous aurons tout aussi bien fait d'encapsuler cette troisième dans la deuxième, afin que la première n'ait connaisse pas l'existance et n'ait pas à s'en soucier :
+
+![](facade-2.png)
+
 
 ### Proxy
 
@@ -191,3 +214,13 @@ Si vous recherchez de la sécurité ou du lazy loading, c'est ceci qu'il vous fa
 
 
 ### Compound
+
+Les patterns sont souvent utilisés en composition les uns avec les autres, afin de résoudre des problèmes connus.
+L'exemple repris dans le livre travaille sur la modélisation d'une "Quack Meeting" - la conférence des canards à bec et en plastique :
+
+* Nous proposons d'abord une interface `Quackable`, qui propose une méthode `Quack()`,
+* Si nous devons modéliser une oie (ça cancanne aussi, une oie), nous lui mettrons un **adapter** afin qu'elle puisse se fondre dans le cancan des canards,
+* Pour compter le nombre de quacks, nous utiliserons un **décorateur**,
+* Pour créer nos différents canards, nous utiliserons une **factory**,
+* Pour parcourir les différents canards, un **itérateur**,
+* ... et nous placerons un **observer** pour intercepter les coins-coins (l'interface `Quackable` devant alors s'étendre à une autre interface, `QuackObservable`).