1. schémas récurrents pour construire des programmes orientés objets propres et bien conçus
2. questions sous-jacentes
   1. comment les objets sont en relations les uns avec les autres ?
   2. comment doivent-ils être couplés ?
   3. que devraient-ils connaître les uns des autres ?
   4. comment peut-on "swap out" les parties qui changent fréquemment ?
3. principes sous-jacents
   1. séparer les choses constantes des choses qui changent
      1. causes de changements : nouvelle plateforme, apparition bug, changement cahier des charges...
   2. programmer vers une interface, pas une implémentation
      1. permet de mieux résister aux changements
      2. programmer vers le type le plus général possible
      3. pas nécessairement en implémentant une classe d'interface
   3. préférer la composition à l'héritage
      1. pb héritage : classe mère et filles sont très liées, un chgt dans la mère a des impacts partout...
      2. composition : une classe n'hérite plus, mais est composée de différents d'objets fournissant chacun une fonctionnalité
      3. schéma
   4. déléguer, déléguer, déléguer
4. Template Method Pattern
   1. permet de varier un algorithme
   2. classe abstraite avec méthode squelette (dite aussi "template method")
   3. méthode squelette appelle des méthodes abstraites
      1. c'est la chose qui ne change pas (le squelette de l'algo)
   4. ces méthodes abstraites sont implémentées par les sous-classes concrètes
      1. ce sont les choses qui changent
   5. la méthode squelette n'est pas redéclarée dans les sous classes
   6. hook method : méthode non abstraite dans la classe abstraite
      1. une sous classe peut choisir de la réimplémenter ou pas, dans ce cas elle utilise l'implémentation par défaut de la classe mère
   7. the Template Method pattern is at its best when it is at its leanest—that is, when every abstract method and hook is there for a reason.
   8. ce pattern est réutilisé dans d'autres patterns
5. Strategy Pattern
   1. on définit l'algorithme dans son entier dans un objet ou classe dédiée
   2. on définit ainsi une famille de objets, les stratégies, qui font toutes le même genre de chose
   3. les stratégies partagent une interface commune, définie ou non dans une classe mère abstraite
   4. le contexte désigne l'utilisateur l'objet/classe utilisateur des stratégies
   5. avantages
      1. le contexte peut choisir sa stratégie à l'initialisation, et la changer au cours du runtime
      2. séparation des responsabilités : le contexte n'a plus de connaissance ni de responsabilités de l'implémentation des stratégies
   6. différence avec le Template Method Pattern
      1. With the Template Method pattern, we make our decision when we pick our concrete subclass.
      2. In the Strategy pattern, we make our decision by selecting a strategy class at runtime.
   7. choix pour passer les données du contexte vers la stratégie
      1. en les énumérant au moment de l'appel de la stratégie
         1. bonne séparation du contexte et de la stratégie
         2. lourd si beaucoup de données à passer
      2. en passant entièrement le contexte dans l'appel de la stratégie
         1. simplifie le flux de données à transmettre
         2. mais augmente le couplage entre stratégies et contexte
   8. en Ruby on peut implémenter les stratégies directement sous forme de proc ou code blocs
      1. on peut ainsi passer à sort une stratégie de tri sous forme d'un code bloc
   9. risque de ce pattern : trop coupler le contexte et les stratégies & faire une mauvaise interface entre les deux
6. Observer Pattern
   1. permet d'alerter d'autres objets (les observers) quand un objet change (le subject), en réduisant le couplage et en le rendant générique
   2. en Ruby il suffit de mixer le module Observable (require 'observer')
      1. ensuite dans le update du sujet, on utilise "change; notify_observer(self)"
   3. après l'instaciation d'un sujet, il faut explicitement lier le sujet et les observers
   4. deux choix pour l'implémentation de l'interface entre sujet et observers
      1. pull method
         1. une seule méthode dans l'observer avec pour seul argument le sujet en entier
      2. push method
         1. un ou plusieurs méthodes dans l'observer avec des signatures plus complexes et restreintes que le sujet en entier
   5. quand une erreur a lieu dans un observer, faut-il rollbacker le changement au niveau du sujet ?
      1. décision au cas par cas
7. Composite Pattern
   1. utile pour du code travaillant sur un arbre d'objets sans que le code ait besoin de savoir s'il traite à un moment donné une feuille de l'arbre ou un sous-arbre
   2. 3 parties pour construire le composite pattern
      1. component : interface commune pour tous les objets
      2. leaf classes : le bloc de base indivisible
         1. doit implémenter l'interface du component
      3. composite : construits à partir de plusieurs blocs
         1. doit implémenter l'interface du component
8. Iterator Pattern
   1. fournit à un objet agrégrant une façon d'accéder à ses éléments séquentiellement sans exposer sa représentation interne
   2. deux types d'itérateurs
      1. itérateur externe : l'itérator est un objet distinct de l'objet aggrégeant
         1. on contrôle le rythme de l'itération, on peut la susprendre ou l'interrompre (moins souple avec itérateur interne)
         2. on peut les partager
      2. itérateur interne : l'itération est effectuée par l'objet agrégeant lui-même
         1. on passe à l'objet aggrégeant le code à appliquer à chacun de ses éléments
         2. exemple : each
         3. simples et code plus clair
         4. en Ruby on peut facilement ajouter un itérateur interne à un objet aggrégeant en mixant Enumerable
9. Command Patern
   1. Command pattern command is an instruction to do something, something specific
   2. a Command pattern command can be filled—or executed—right now, or later, or when something specific happens.
   3. command : object that does nothing but wait to be executed and, when executed, goes out and performs an application-specific task.
      1. en ruby facilement implémentable sous forme de code block / Proc
   4. on sépare ce qui change (la commande) de ce qui ne change pas (dans ex GUI, la classe générique Bouton)
   5. command pattern: ensemble de classes qui partagent une même interface
      1. exemple d'interface
         1. initialize: pour stocker les infos nécessiares à l'exécution de la commande
         2. execute: réalise la commande
         3. describe : décrit la commande
         4. unexecute : annule le résultat de la commande
   6. conseils
      1. n'utiliser que si vraiement où a besoin de faire plus tard une commande et de savoir comment la faire
      2. s'assurer que les circonstances au moment où la commande est exécutée satisfont ses pré requis
         1. par exemple pour une commande annulant une exécution
   7. exemple : les migrations Rails
   8. proche du pattern observer
      1. command et observer sont appelés à partir d'un autre participant du pattern
         1. command n'est pas à priori intéressé par l'objet l'appelant
         2. l'observer si
10. “one object stands in for another” patterns
    1. Proxy Pattern
       1. un objet (le proxy) prend la place d'un autre
       2. il délègue au vrai objet (@subject) une partie des tâches et en réalise d'autres
       3. par exemple un proxy peut impplémenter du contrôle d'accès sur une classe initiale qui en est dépourvue
          1. cela permet de séparer deux problèmatiques dans 2 classes
             1. l'initiale pour le domaine métier
             2. le proxy pour le contrôle d'accès
       4. intérêts
          1. meilleure séparation des responsabilités
          2. changements plus faciles
       5. en Ruby un proxy est très facilement implémentable avec method_missing et send
    2. Decorator Pattern
       1. straightforward technique that you can use to assemble exactly the functionality that you need at runtime
          1. It offers an alternative to creating a monolithic “kitchen sink” object that supports every possible feature or a whole forest of classes and subclasses to cover every possible combination of features
       2. enables you to easily add an enhancement to an existing object
       3. also allows you to layer features atop one another so that you can construct objects that have exactly the right set of capabilities that you need for any given situation
       4. The ConcreteComponent is the “real” object, the object that implements the basic component functionality
       5. Decorator class
          1. has a reference to a Component—the next Component in the decorator chain
          2. it implements all of the methods of the Component type
          3. layers its own special magic onto the workings of the base component, adding its own talent to at least one of the methods
          4. can also add new methods—that is, operations that are not defined in the Component interface—although this behavior is optional
       6. en Ruby
          1. on peut rapidement implémenter l'interface du Component dans la classe Decorator avec le module Forwardable
          2. on peut changer les classes Decorator en module et les ajouter dynamiquement a un concretecomponent avec extend
             1. mais difficule ensuite de retirer le décorateur
       7. limites
          1. One thing to keep in mind when implementing the Decorator pattern is that you need to keep the component interface simple. You want to avoid making the component interface overly complex, because a complex interface will make it that much harder to get each decorator right.
          2. facilite le travail du codeur implémenteur, mais peut être difficile à utiliser pour le codeur utilisateur
          3. performance overhead si longues chaînes de décorateurs
          4. peut-être plus difficile à débugger
    3. Adaptater Pattern
       1. objet qui fait le lien entre une interface que l'on a et une interface dont on a besoin
       2. dans le graph, on (le client) veut communiquer avec Adaptee, mais son interface ne convient pas
       3. donc en fait on communique avec Target, qui est en fait un adaptateur offrant une meilleure interface que Adaptee
       4. en Ruby on peut facilement modifier l'inteface d'un objet (ou d'une classe) existant plutôt que de créer un adaptateur