Describe the Strategy pattern

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

@@ -0,0 +1,74 @@
+---
+title: Head First Design Patterns
+writers: [Eric Freeman, Elisabeth Robson]
+---
+
+La structure-même du livre est assez inhabituelle, et force le travail, la répétition et la compréhension (ce qui est plutôt bien).
+Ceci dit, cette même structure va parfois trop loin dans la dérision et dans une présentation un peu surfaite des personnages.
+J'aimais assez bien la découpe et la chronologie, ainsi que les exemples donnés, mais le fait qu'il soit un peu fouilli me dérangeait un peu.
+
+Tous les patrons de conception (= _design patterns_, mais rassurez-vous, j'utiliserai uniquement ce terme par la suite) ne sont pas représentés, mais on y trouve les principaux - dont certains que vous utilisez sans doute déjà sans savoir qu'ils portent un petit nom bien à eux.
+En plus de représenter des solutions reconnues à des problèmes connus, les _design patterns_ correspondent aussi à un vocabulaire commun.
+
+Ces _design patterns_ peuvent être regroupés selon plusieurs catégories :
+
+* [Creational](https://refactoring.guru/design-patterns/creational-patterns), orientés sur le découplage et l'instanciation de composants,
+* [Behavioral](https://refactoring.guru/design-patterns/behavioral-patterns) pour aider aux interactions entre composants,
+* [Structural](https://refactoring.guru/design-patterns/structural-patterns), pour les structures plus larges.
+
+Pour rappel, la Programmation Orientée Objets se base sur les principes suivants :
+
+1. Encapsuler ce qui varie,
+2. Favoriser la composition sur l'héritage,
+3. Programmer envers des interfaces, pas des classes concrètes.
+
+## Creational
+
+### Factory & Abstract Factory
+
+### Singleton
+
+
+## Behavioral
+
+### Command
+
+### Iterator
+
+### Template
+
+### State
+
+### Observer
+
+### Strategy
+
+> Plutôt que d'implémenter une forme d'héritage dès qu'on en a l'occasion, l'idée est de différencier l'élément de son comportement.
+
+L'exemple abordé est sans doute le plus "drôle", puisque l'auteur propose de représenter certaines classes de canard (héritant tous d'une même classe `Duck`), jusqu'à arriver à modéliser un canard en plastique, qui ne pourra donc pas voler.
+On en arrive à comprendre la nécessité de dissocier l'implémentation du comportement par l'absurde[^1].
+
+On en arrive ainsi à représenter une classe dont le comportement (`FlyingBehaviour` et `QuackBehaviour` sont totalement déléguées à d'autres classes).
+Les avantages sont nombreux, puisque cette modélisation respecte le _Single Responsibility Principle_ tout en permettant une réutilisabilité très élevée.
+De cette manière, il suffit de déclarer une nouvelle classe, puis de lui injecter le comportement que nous attendons d'elle.
+
+Une autre conclusion est qu'il est parfois mieux d'implémenter un `has-a` (= composition, délégation, ...) qu'un `is-a` (= héritage).
+De la même manière, nous pouvons implémenter des personnes d'un jeu de rôles et "réutiliser" leurs armes en définissant un `WeaponBehaviour` :
+
+![](strategy.drawio.png)
+
+[^1]: en mode, "_Si vous faites de l'héritage sans réfléchir, vous allez vous planter_".
+
+## Structural
+
+### Composite
+
+### Decorator
+
+### Adapter
+
+### Façade
+
+### Proxy
+
+### Compound

content/technologeek/books/_index.md

@@ -1,5 +1,5 @@
 +++
-title = "Lectures informati{ves|ques}"
+title = "Lectures informatiques"
 sort_by = "date"
 transparent = true
 +++