anchor.diff:  }
   ----
   
  -Le principe de chaque dcorator est le même, chacun doit proposer une implémentation de la méthide "applyExpense". Il est noter que les cas choisis ne reflètent pas forcemment la réalité, mais servent juste d'exemple.
  -Une "garbage class" appelée Expenses contient des méthodes statiques permettant de calculer chaque cas. Nous monterons cette classe un peu plus tard.
  +Le principe de chaque decorator est le même, chacun doit proposer une implémentation de la méthode "applyExpense". Il est à noter que les cas choisis dans cet article pour représenter le bénéfice d'une entreprise ne reflètent pas forcemment la réalité, mais servent juste d'exemple.
  +Une "garbage class" appelée "Expenses" contient des méthodes "static" permettant de calculer chaque cas. Nous montrerons cette classe un peu plus tard.
   
   Nous allons désormais passer aux tests d'intégration et à l'appel des décorators. 
   
  
positive.code: 
  Un calculateur de profit dispose d'une méthode abstraite "calculate", qui va appliquer un nouveau calcul au CA passé en paramètre.
  
  Ensuite il faut créer une classe abstraite que l'on va appeler AbstractProfitDecorator : 
  
  [source,java]
  ----
  
negative.code: Une subtilité est à constater içi, la classe prend également en paramètre l'interface "ProfitCalculator". 
  En effet, chaque decorator va appliquer le calcul du decorator qui le précède et va ensuite y ajouter son calcul à lui. C'est ce comportement qui permet d'ajouter des traitements au runtime.
  
  Nous allons commencer par une classe proposant un calcul par défaut, appelé "DefaultProfitCalculator". Il est, en effet, utile de commencer par une classe de type "profitCalculator" qui ne dépend de rien lors de son instantiation. Ceci correspond au calcul initial des decorators : 
  
  [source,java]
  ----
  