anchor.diff:    }
   ----
   
  -Le calcul commence de droite à gauche, on commence par le DefaultProfitCalculator, enuite cette classe est passée en paramètre du décorator OperatingExpensesDecorator et ainsi de suite.
  +Le calcul commence de droite à gauche, le point de départ est le DefaultProfitCalculator, ensuite cette classe est passée en paramètre du décorator OperatingExpensesDecorator et ainsi de suite.
   OperatingExpensesDecorator applique le calcul de DefaultProfitCalculator plus le sien.
   
   Voici un second test qui n'applique pas tous les décorator, et montre qu'il est très simple d'ajouter ou de supprimer un decorator au runtime. Le code peut ainsi être évolutif : 
   
   [source,java]
   ----
  -@Test
  +  @Test
     public void givenTurnover_whenNotComposingAllDecorators_thenCorrectResult() {
   
       // Given.
  
positive.code: 
  [source,java]
  ----
  @Test
    public void givenTurnover_whenComposingAllDecorators_thenCorrectResult() {
  
      // Given.
  
negative.code: Ce pattern présente de nombreux avantages car lorsque la conception a été mise en place, il devient très simple d'ajouter du comportement au code existant, ce qui le rend très evolutif.
  
  Avant Java 8, malgré l'aspect interessant évoqué précédement, ce pattern n'était pas beaucoup utilisé car le code nécessaire à sa mise en place était très verbeux.
  En effet le design de code était basé sur l'héritage, ce qui obligeait le développeur à écrire une classe par décorator, ainsi qu'une interface + une classe abstraite. La verbosité induite par ce type de dévéloppement pouvait décourager pas mal de développeurs.
  
  En Java 8 avec l'apport des lambdas, nous allons montrer que le decorator est beaucoup plus simple à implémenter, moins verbeux, fonctionnel et plus lisible pour le client de l'API.
  
  