Update 2015-11-10-Visual-Question-Answering-2.adoc

= Visual Question Answering 2
:hp-tags: VQA, DNN, RNN, CNN, Python, Keras, Theano

Prepare for VQA in Ubuntu 14.04 x64. +
In this Post, I want to install and test Keras. +

[quote, Keras Documentation, ]
____
Keras is a minimalist, highly modular neural network library in the spirit of Torch, written in Python, that uses Theano under the hood for optimized tensor manipulation on GPU and CPU. It was developed with a focus on enabling fast experimentation.
____

{empty} +

Keras uses the following dependencies: +

. *numpy*
. *scipy*
. *pyyaml*
. *Theano*
. *HDF5* and *h5py* (optional, required if you use model saving/loading functions)
. Optional but recommended if you use CNNs: *cuDNN*

=== Install miniconda

[source,role="console"]
----
$ wget https://repo.continuum.io/miniconda/Miniconda-latest-Linux-`uname -p`.sh
$ bash Miniconda-latest-Linux-`uname -p`.sh
$ source ~/.bashrc
----
See also link:http://conda.pydata.org/docs/install/quick.html[the install guide].

=== Install Theano

[source,role="console"]
----
$ sudo apt-get install git
$ pip install git+git://github.com/Theano/Theano.git
----

=== Install h5py

[source,role="console"]
----
$ conda install -y h5py
----

=== Install Keras

[source,role="console"]
----
$ pip install keras
----

=== Install g++ (optional)

[source,role="console"]
----
$ sudo apt-get install g++
----

Without g++, you will get this message when run Keras and Keras will be very slow.

[source,role="console"]
----
WARNING (theano.configdefaults): g++ not detected ! Theano will be unable to execute optimized C-implementations (for both CPU and GPU) and will default to Python implementations. Performance will be severely degraded. To remove this warning, set Theano flags cxx to an empty string.
----

=== Test Keras

[source,role="console"]
----
$ curl -sSL https://github.com/fchollet/keras/raw/master/examples/mnist_mlp.py | python
----

The result here.

[source,role="console"]
----
60000 train samples
10000 test samples
Train on 60000 samples, validate on 10000 samples
Epoch 1/20
8s - loss: 0.4356 - acc: 0.8716 - val_loss: 0.1863 - val_acc: 0.9421
Epoch 2/20
7s - loss: 0.1961 - acc: 0.9414 - val_loss: 0.1274 - val_acc: 0.9601
Epoch 3/20
7s - loss: 0.1451 - acc: 0.9564 - val_loss: 0.1010 - val_acc: 0.9691
Epoch 4/20
8s - loss: 0.1189 - acc: 0.9642 - val_loss: 0.0847 - val_acc: 0.9752
Epoch 5/20
8s - loss: 0.1019 - acc: 0.9691 - val_loss: 0.0850 - val_acc: 0.9735
Epoch 6/20
8s - loss: 0.0903 - acc: 0.9721 - val_loss: 0.0749 - val_acc: 0.9777
Epoch 7/20
8s - loss: 0.0822 - acc: 0.9745 - val_loss: 0.0753 - val_acc: 0.9762
Epoch 8/20
7s - loss: 0.0758 - acc: 0.9762 - val_loss: 0.0743 - val_acc: 0.9796
Epoch 9/20
7s - loss: 0.0705 - acc: 0.9780 - val_loss: 0.0720 - val_acc: 0.9784
Epoch 10/20
8s - loss: 0.0648 - acc: 0.9790 - val_loss: 0.0688 - val_acc: 0.9793
Epoch 11/20
8s - loss: 0.0592 - acc: 0.9819 - val_loss: 0.0663 - val_acc: 0.9797
Epoch 12/20
8s - loss: 0.0567 - acc: 0.9824 - val_loss: 0.0677 - val_acc: 0.9815
Epoch 13/20
8s - loss: 0.0536 - acc: 0.9833 - val_loss: 0.0711 - val_acc: 0.9796
Epoch 14/20
8s - loss: 0.0520 - acc: 0.9834 - val_loss: 0.0684 - val_acc: 0.9806
Epoch 15/20
9s - loss: 0.0500 - acc: 0.9837 - val_loss: 0.0664 - val_acc: 0.9807
Epoch 16/20
7s - loss: 0.0471 - acc: 0.9850 - val_loss: 0.0683 - val_acc: 0.9809
Epoch 17/20
7s - loss: 0.0449 - acc: 0.9856 - val_loss: 0.0682 - val_acc: 0.9812
Epoch 18/20
8s - loss: 0.0433 - acc: 0.9860 - val_loss: 0.0675 - val_acc: 0.9813
Epoch 19/20
7s - loss: 0.0401 - acc: 0.9869 - val_loss: 0.0683 - val_acc: 0.9819
Epoch 20/20
8s - loss: 0.0383 - acc: 0.9874 - val_loss: 0.0705 - val_acc: 0.9820
Test score: 0.0704572771238
Test accuracy: 0.982
----

{empty} +
{empty} +

=== Error
[NOTE]
===============================

When I installed Theano from miniconda,

[source,role="console"]
----
$ conda install -y theano
----

* keras-0.2.0
* theano-0.7.0

got this error during th test.

[source,role="console"]
----
AttributeError: 'module' object has no attribute 'relu'
----

I solved the error by re-installing with pip from github. +

[source,role="console"]
----
$ conda uninstall theano
$ sudo apt-get install git
$ pip install git+git://github.com/Theano/Theano.git
----

===============================

{empty} +
{empty} +

''''

=== References

* http://ermaker.github.io/blog/2015/09/08/get-started-with-keras-for-beginners.html
* http://keras.io/
* http://conda.pydata.org/docs/install/quick.html

''''

= Visual Question Answering 2
:hp-tags: VQA, DNN, RNN, CNN, Python, Keras, Theano

Prepare for VQA in Ubuntu 14.04 x64. +
In this Post, I want to install and test Keras. +

[quote, Keras Documentation, ]
____
Keras is a minimalist, highly modular neural network library in the spirit of Torch, written in Python, that uses Theano under the hood for optimized tensor manipulation on GPU and CPU. It was developed with a focus on enabling fast experimentation.
____

{empty} +

Keras uses the following dependencies: +

. *numpy*
. *scipy*
. *pyyaml*
. *Theano*
. *HDF5* and *h5py* (optional, required if you use model saving/loading functions)
. Optional but recommended if you use CNNs: *cuDNN*

=== Install miniconda

[source,role="console"]
----
$ wget https://repo.continuum.io/miniconda/Miniconda-latest-Linux-`uname -p`.sh
$ bash Miniconda-latest-Linux-`uname -p`.sh
$ source ~/.bashrc
----
See also link:http://conda.pydata.org/docs/install/quick.html[the install guide].

=== Install Theano

[source,role="console"]
----
$ sudo apt-get install git
$ pip install git+git://github.com/Theano/Theano.git
----

=== Install h5py

[source,role="console"]
----
$ conda install -y h5py
----

=== Install Keras

[source,role="console"]
----
$ pip install keras
----

=== Install g++ (optional)

[source,role="console"]
----
$ sudo apt-get install g++
----

Without g++, you will get this message when run Keras and Keras will be very slow.

[source,role="console"]
----
WARNING (theano.configdefaults): g++ not detected ! Theano will be unable to execute optimized C-implementations (for both CPU and GPU) and will default to Python implementations. Performance will be severely degraded. To remove this warning, set Theano flags cxx to an empty string.
----

=== Test Keras

[source,role="console"]
----
$ curl -sSL https://github.com/fchollet/keras/raw/master/examples/mnist_mlp.py | python
----

The result here.

[source,role="console"]
----
60000 train samples
10000 test samples
Train on 60000 samples, validate on 10000 samples
Epoch 1/20
8s - loss: 0.4356 - acc: 0.8716 - val_loss: 0.1863 - val_acc: 0.9421
Epoch 2/20
7s - loss: 0.1961 - acc: 0.9414 - val_loss: 0.1274 - val_acc: 0.9601
Epoch 3/20
7s - loss: 0.1451 - acc: 0.9564 - val_loss: 0.1010 - val_acc: 0.9691
Epoch 4/20
8s - loss: 0.1189 - acc: 0.9642 - val_loss: 0.0847 - val_acc: 0.9752
Epoch 5/20
8s - loss: 0.1019 - acc: 0.9691 - val_loss: 0.0850 - val_acc: 0.9735
Epoch 6/20
8s - loss: 0.0903 - acc: 0.9721 - val_loss: 0.0749 - val_acc: 0.9777
Epoch 7/20
8s - loss: 0.0822 - acc: 0.9745 - val_loss: 0.0753 - val_acc: 0.9762
Epoch 8/20
7s - loss: 0.0758 - acc: 0.9762 - val_loss: 0.0743 - val_acc: 0.9796
Epoch 9/20
7s - loss: 0.0705 - acc: 0.9780 - val_loss: 0.0720 - val_acc: 0.9784
Epoch 10/20
8s - loss: 0.0648 - acc: 0.9790 - val_loss: 0.0688 - val_acc: 0.9793
Epoch 11/20
8s - loss: 0.0592 - acc: 0.9819 - val_loss: 0.0663 - val_acc: 0.9797
Epoch 12/20
8s - loss: 0.0567 - acc: 0.9824 - val_loss: 0.0677 - val_acc: 0.9815
Epoch 13/20
8s - loss: 0.0536 - acc: 0.9833 - val_loss: 0.0711 - val_acc: 0.9796
Epoch 14/20
8s - loss: 0.0520 - acc: 0.9834 - val_loss: 0.0684 - val_acc: 0.9806
Epoch 15/20
9s - loss: 0.0500 - acc: 0.9837 - val_loss: 0.0664 - val_acc: 0.9807
Epoch 16/20
7s - loss: 0.0471 - acc: 0.9850 - val_loss: 0.0683 - val_acc: 0.9809
Epoch 17/20
7s - loss: 0.0449 - acc: 0.9856 - val_loss: 0.0682 - val_acc: 0.9812
Epoch 18/20
8s - loss: 0.0433 - acc: 0.9860 - val_loss: 0.0675 - val_acc: 0.9813
Epoch 19/20
7s - loss: 0.0401 - acc: 0.9869 - val_loss: 0.0683 - val_acc: 0.9819
Epoch 20/20
8s - loss: 0.0383 - acc: 0.9874 - val_loss: 0.0705 - val_acc: 0.9820
Test score: 0.0704572771238
Test accuracy: 0.982
----

{empty} +
{empty} +

=== Error
[NOTE]
===============================

When I installed Theano from miniconda,

[source,role="console"]
----
$ conda install -y theano
----

* keras-0.2.0
* theano-0.7.0

got this error during th test.

[source,role="console"]
----
AttributeError: 'module' object has no attribute 'relu'
----

I solved the error by re-installing with pip from github. +

[source,role="console"]
----
$ conda uninstall theano
$ sudo apt-get install git
$ pip install git+git://github.com/Theano/Theano.git
----

===============================

''''

=== References

* http://ermaker.github.io/blog/2015/09/08/get-started-with-keras-for-beginners.html
* http://keras.io/
* http://conda.pydata.org/docs/install/quick.html

''''


Update 2016-04-23-Puppet-Common-Anti-Patterns.adoc

= Puppet - Common Anti-Patterns
:hp-tags: Puppet, Automation, Configuration Management, Devops

Over my years in the tech industry I've gained a lot of experience with Configuration Managemnt tools such as Puppet, Chef and Ansible. In this post I'd like to share with you my experience opinions and advice on using Puppet as a Configuration Management tool. Hopefully this helps some of you out there to beat Puppet into submission.

== Everything in Manifests

In many beginners tutorials you get taught to put all your code in manifests such as `site.pp` or `nodes.pp`. For example:

```
node 'puppetclient1.mydomain.net' {
  include httpd_class
}

node 'puppetclient2.mydomain.net' {
  include nginx_class
  file {'/opt/deployment_script':
    ensure => 'file',
    owner  => 'deploy',
    group  => 'deploy',
    mode   => '0750'
  }
}

node default {
  package { 'perl':
    ensure => present
  }
}
```

This is great when you're just starting out with a few servers managed you think you get it. Then you add a few more servers, you start adding more node specific config and before you know it you've got 10'000 lines of hand-crafted artisanal Puppet code. Much of which is probably duplicated. This was common in the early deys af Puppet. It was how I started back with Puppet 0.24.

Although, it's not the best idea to manage your infrastructure in this way it's actually a reasonably good way to very easily and simply bootstrap cloud instances. with separate manifests based on server type (`web.pp`, `app.pp`, `lb.pp` etc). These can than be applied using https://cloudinit.readthedocs.io/en/latest/[cloudinit] to create an immutable bootstrapped node.

== Monolithic `modules` Directory

Quite often I see repos where either people have `puppet module install`'d straight into the `modules` directory or they've downloaded a module and extracted it there. They then commit the whole repo including their own modules mixed in with upstream modules into source control. This pattern has a few problems, you don't know what is a locally developed module and what is an upstream module and there's no way of easily seeing what versions of modules are deployed. It also adds a lot of extra code to your Puppet repository.

Although this way works and you know that your module versions are pinned, there's tools out there that make it much easier to manage your Puppet modules such as http://librarian-puppet.com/[librarian-puppet] and https://github.com/puppetlabs/r10k[r10k].

== Configuration Data in Code

When writing Puppet code it's sometimes tempting to hard-code things like IP addresses or node specific things. For example:
```
class profile::base::dns{
  $dns_servers = ['192.168.1.1', '192.168.1.2']
  file { '/etc/resolv.conf':
    ensure  => present,
    owner   => 'root',
    group   => 'root',
    mode    => '0444',
    content => template('etc/resolv.conf.erb')
  }
}
```

This works but the code isn't re-usable. If you deploy to a different network or DC are your DNS servers still the same? To improve reusablility, change the variable to be a class parameter:

```
class profile::base::dns (
  $dns_servers = ['8.8.8.8', '8.8.4.4']
){
  file { '/etc/resolv.conf':
    ensure  => present,
    owner   => 'root',
    group   => 'root',
    mode    => '0444',
    content => template('etc/resolv.conf.erb')
  }
}
```
Then you can specify environment (network, node, DC) specific things in Hiera:

192.168.1.0.yaml:
```
---
profile::base::dns:
  dns_servers:
    - '192.168.1.1'
    - '192.168.1.2'
```
10.10.0.0.yaml:
```
---
profile::base::dns:
  dns_servers:
    - '10.10.0.1'
    - '10.10.1.1'
```

== Everything in Separate Repos

== Misuse of Puppet Environments

== Manually Deploying Puppet Code

= Puppet - Common Anti-Patterns
:hp-tags: Puppet, Automation, Configuration Management, Devops

Over my years in the tech industry I've gained a lot of experience with Configuration Managemnt tools such as Puppet, Chef and Ansible. In this post I'd like to share with you my experience opinions and advice on using Puppet as a Configuration Management tool. Hopefully this helps some of you out there to beat Puppet into submission.

== Everything in Manifests

In many beginners tutorials you get taught to put all your code in manifests such as `site.pp` or `nodes.pp`. For example:

```
node 'puppetclient1.mydomain.net' {
  include httpd_class
}

node 'puppetclient2.mydomain.net' {
  include nginx_class
  file {'/opt/deployment_script':
    ensure => 'file',
    owner  => 'deploy',
    group  => 'deploy',
    mode   => '0750'
  }
}

node default {
  package { 'perl':
    ensure => present
  }
}
```

This is great when you're just starting out with a few servers managed you think you get it. Then you add a few more servers, you start adding more node specific config and before you know it you've got 10'000 lines of hand-crafted artisanal Puppet code. Much of which is probably duplicated. This was common in the early deys af Puppet. It was how I started back with Puppet 0.24.

Although, it's not the best idea to manage your infrastructure in this way it's actually a reasonably good way to very easily and simply bootstrap cloud instances. with separate manifests based on server type (`web.pp`, `app.pp`, `lb.pp` etc). These can than be applied using https://cloudinit.readthedocs.io/en/latest/[cloudinit] to create an immutable bootstrapped node.

== Monolithic `modules` Directory

Quite often I see repos where either people have `puppet module install`'d straight into the `modules` directory or they've downloaded a module and extracted it there. They then commit the whole repo including their own modules mixed in with upstream modules into source control. This pattern has a few problems, you don't know what is a locally developed module and what is an upstream module and there's no way of easily seeing what versions of modules are deployed. It also adds a lot of extra code to your Puppet repository.

Although this way works and you know that your module versions are pinned, there's tools out there that make it much easier to manage your Puppet modules such as http://librarian-puppet.com/[librarian-puppet] and https://github.com/puppetlabs/r10k[r10k].

== Configuration Data in Code

== Everything in Separate Repos

== Misuse of Puppet Environments

== Manually Deploying Puppet Code


Update 2017-03-21-Pattern-Decorator-en-Java-8.adoc

= Pattern Decorator en Java 8
:published_at: 2017-03-21
:source-highlighter: highlightjs

== 1) Introduction

L'objectif de cette article est de parler d'un des pattern du GOF (gang of four) assez connu, qui est le decorator.
Ce patron de conception correspond à un design pattern de type comportement (behavioural pattern).

En gros l'idée de ce pattern est d'ajouter du comportement à du code au runtime (c'est à dire à l'execution du 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 interface par décorator, assez qu'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.

L'article se décompose en 2 partie consistant à montrer le code et la conception du decorator avant et après Java 8. En Java 8 nous montrerons différentes techniques.

L'exemple choisi pour illustrer ce pattern, est le calcul du bénéfice d'une entreprise. Chaque nouveau decorator permettra d'ajouter un calcul au runtime à la formule générale.

== 2) Decorator en Java 7

Premièrement une interface définissant le contrat doit être créée, nous allons l'appeler ProfitCalculator (calculateur de bénéfice). Voici le code de cette interface :

[source,java]
----
public interface ProfitCalculator {

  double calculate(double turnover);
}
----

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]
----
public abstract class AbstractProfitDecorator implements ProfitCalculator {

  private final ProfitCalculator profitCalculator;

  public AbstractProfitDecorator(ProfitCalculator profitCalculator) {
    this.profitCalculator = profitCalculator;
  }

  protected abstract double applyExpense(double turnover);

  @Override
  public double calculate(double turnover) {
    double profit = profitCalculator.calculate(turnover);
    return applyExpense(profit);
  }
}
----

Cette classe implémente l'interface précédente et doit donc proposer l'implémentation de la méthode "calculate(double turnover)".
Chaque décorator va appliquer une dépense en proposant l'implémentation de la méthode "applyExpense(double turnover)".

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]
----
public class DefaultProfitCalculator implements ProfitCalculator {

  @Override
  public double calculate(double turnover) {
    return Expenses.getTransportExpenses(turnover);
  }
}
----

Nous allons ensuite montrer le code des différents decorators :

Charges d'exploitation => OperatingExpensesDecorator :
[source,java]
----
public class OperatingExpensesDecorator extends AbstractProfitDecorator {

  public OperatingExpensesDecorator(ProfitCalculator profitCalculator) {
    super(profitCalculator);
  }

  @Override
  protected double applyExpense(double turnover) {
    return Expenses.getOperatingExpenses(turnover);
  }
}
----

Rémunération => RemunerationDecorator :
[source,java]
----
public class RemunerationDecorator extends AbstractProfitDecorator {

  public RemunerationDecorator(ProfitCalculator profitCalculator) {
    super(profitCalculator);
  }

  @Override
  protected double applyExpense(double turnover) {
    return Expenses.getRemuneration(turnover);
  }
}
----

Dépenses exceptionnelles => ExceptionalExpensesDecorator :
[source,java]
----
public class ExceptionalExpensesDecorator extends AbstractProfitDecorator {

  public ExceptionalExpensesDecorator(ProfitCalculator profitCalculator) {
    super(profitCalculator);
  }

  @Override
  protected double applyExpense(double turnover) {
    return Expenses.getExceptionalExpenses(turnover);
  }
}
----

Taxes déductible => DeductibleTaxesDecorator :
[source,java]
----
public class DeductibleTaxesDecorator extends AbstractProfitDecorator {

  public DeductibleTaxesDecorator(ProfitCalculator profitCalculator) {
    super(profitCalculator);
  }

  @Override
  protected double applyExpense(double turnover) {
    return Expenses.getDeductibleTaxes(turnover);
  }
}
----

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.

Nous allons désormais passer aux tests d'intégration et à l'appel des décorators.

Le premier test permet de composer tous les décorators :

[source,java]
----
@Test
  public void givenTurnover_whenComposingAllDecorators_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit =
        new ExceptionalExpensesDecorator(new RemunerationDecorator(new DeductibleTaxesDecorator(new OperatingExpensesDecorator(new DefaultProfitCalculator())))).calculate(turnover);

    // Then.
    assertThat(profit).isNotNull().isEqualTo(32600);
  }
----

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.
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
  public void givenTurnover_whenNotComposingAllDecorators_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = new RemunerationDecorator(new DeductibleTaxesDecorator(new OperatingExpensesDecorator(new DefaultProfitCalculator()))).calculate(turnover);

    // Then.
    assertThat(profit).isNotNull().isEqualTo(34600);
  }
----

Au niveau du client de l'API, nous avons la confirmation que le pattern est interéssant à utiliser de part sa souplesse et du fait qu'il est possible d'ajouter un nouveau calcul (ou dans un autre cas une nouvelle règle) juste en créant un nouveau décorator et sans casser tous la conception mise en place.

Cependant nous constatons que la mise en place de ce patron de conception, est très verbeuse. Beaucoup de classes et de lignes de codes doivent être écrites pour mettre en place ce type de design de code.
De plus, le fait qu'il soit orienté héritage peut rendre sa compréhénsion compliquée. Tous ces éléments peuvent dissuader le développeur à mettre en place ce type de conception.

Un des exemples de l'utilisation de ce pattern dans le JDK est la classe .....

Nous allons voir dans la deuxième partie comment refaire le pattern decorator en Java 8 avec des lambdas et des fonctions; et de montrer que l'écriture est beaucoup plus simple et beaucoup moins verbeuse.

== 2) Decorator en Java 8

Nous allons commencer par montrer les méthodes statiques proposées par la garbage classe Expenses :

[source,java]
----
public class Expenses {

  public static double getTransportExpenses(final double turnover) {
    return turnover - 2400;
  }

  public static double getOperatingExpenses(final double turnover) {
    return turnover - 15000;
  }

  public static double getDeductibleTaxes(final double turnover) {
    return turnover - 3000;
  }

  public static double getRemuneration(final double turnover) {
    return turnover - 45000;
  }

  public static double getExceptionalExpenses(final double turnover) {
    return turnover - 2000;
  }
}
----

Chaque méthode statique effectue le calcul souhaité en prenant un double en paramètre et en retournant en sortie.

Nous allons ensuite montrer différente façons d'implémenter ce pattern en Java 8.

== a) Decorator en Java 8 avec de la composition de fonctions

Comme pour la partie Java 7, nous allons écrire une classe contenant le calcul par défaut :

[source,java]
----
public class DefaultProfitCalculator implements DoubleUnaryOperator {

  @Override
  public double applyAsDouble(final double operand) {
    return Expenses.getTransportExpenses(operand);
  }
}
----

Cette classe implémente une interface fonctionnelle proposée par défaut dans le JDK 8 DoubleUnaryOperator. Cette fonction prend un double en entrée et retourne un double en sortie, ce qui correspond à la signature des calculs présents dans la classe Expenses. L'implémentation de la méthode applyAsDouble est effectué avec un calcul par défaut.

Et c'est tout... Nous allons pouvoir pouvoir désormais écrire notre decorator en Java 8, via un test :

[source,java]
----
@Test
  public void givenTurnover_whenComposingAllDecoratorsWithAndThen_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = new DefaultProfitCalculator()
                             .andThen(Expenses::getOperatingExpenses)
                             .andThen(Expenses::getDeductibleTaxes)
                             .andThen(Expenses::getRemuneration)
                             .andThen(Expenses::getExceptionalExpenses).applyAsDouble(turnover);

    // Then.
    assertThat(profit).isNotNull().isEqualTo(32600);
  }
----
s
N'est-ce pas grandiose ? nous avons pu réecrire le pattern décorator avec très peu de ligne de code.
Le JDK 8 donne la possibilité de composer plusieurs fonctions entre elles via la "default" méthode "andThen". Cette méthode est proposées dans les fonctions par défaut poposée par le JDK et le DoubleUnaryOperator en fait partie.
On démarre à partir de la classe DefaultProfitCalculator, et via andThen on la compose avec une autre fonction. Dans cet exemple des appels par référence de méthode ont été provilégié afin d'avoir un code plus concis et plus expressif "Expenses::getOperatingExpenses", mais des lambdas expression auraient également fait l'affaire "e -> Expenses.getOperatingExpenses(e)".

Ainsi il devient très simple d'ajouter ou de supprimer des decorators, dans l'exemple ci dessous nous supprimons le decorator qui représente les dépenses exceptionnelles :

[source,java]
----
@Test
  public void givenTurnover_whenNotComposingAllDecoratorsWithAndThen_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = new DefaultProfitCalculator()
                             .andThen(Expenses::getOperatingExpenses)
                             .andThen(Expenses::getDeductibleTaxes)
                             .andThen(Expenses::getRemuneration)
                             .applyAsDouble(turnover);

    // Then.
    assertThat(profit).isNotNull().isEqualTo(34600);
  }
----

Dans les parties suivantes, nous allons voir d'autres façons d'implémenter le pattern decorator en Java 8.

== b) Decorator en Java 8 avec l'API Stream

Dans cette partie, nous allons voir qu'il est possible implémenter le pattern decorator avec l'API Stream.
Nous allons créé une classe appelé StreamDecorator correspondant à une enum singleton (instance unique). Cette classe contient une méthode appelé calculateProfit qui sera exposée au client de l'API :

[source,java]
----
public enum StreamDecorator {

  // Single instance.
  INSTANCE;

  public double calculateProfit(final double turnover, final DoubleUnaryOperator... operators) {
    return Stream.of(operators).reduce(DoubleUnaryOperator.identity(), DoubleUnaryOperator::andThen)
                               .applyAsDouble(turnover);
  }
}
----

Le principe içi est de passer une suite de fonction representée par des DoubleUnaryOperator (équivalent à un tableau de fonction). La méthode prend également en paramètre le CA.
L'API stream propose une factory method permettant d'initialiser une Stream à partir d'un tableau. Nous utilisons ensuite la méthode "reduce" qui permet de réduire les éléments du flux à une seule valeur.

En programation fonctionnelle le reduce correspond à du "fold". Le principe est de passer 2 fonctions, une initiale (et valeur par défaut) et l'autre permettant d'accumuler des éléments. Il devient, par exemple, très simple avec ce type d'opérateur de calculer la somme des élements d'une liste.
Par exemple :

[source,java]
----
reduce(0, (a, b) -> a + b)
----

On considère dans cet exemple que a et b sont des entiers.
La fonction intiale est la valeur 0. La somme des éléments de la liste vont commencer par défaut et l'accumulateur "(a, b) -> a + b" va permettre de sommer chaque élements de la liste au fur et à mesure (somme le résultat de l'itération précédente avec le résultat de l'itération en cours). Si la structure est vide la valeur initiale est retournée, c'est à dire 0. La fonction initiale est également la valeur par défaut si la structure est vide.

Notre exemple suit le même principe, la fonction initiale est "DoubleUnaryOperator.identity()" et l'accumulateur est "DoubleUnaryOperator::andThen" ou "(ope1, ope2) -> ope1.andThen(ope2)". Comme vu précédemment à chaque itération "andThen" va permettre de composer la fonction précédente avec la fonction en cours. Si la structure est vide "DoubleUnaryOperator.identity()" sera retourné (dans ce cas un fonction vide).

Voici le code du test utilisant un exemple avec tous les decorator :

[source,java]
----
@Test
  public void givenTurnover_whenComposingAllDecoratorsWithStream_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = StreamDecorator.INSTANCE.calculateProfit(turnover,
        new DefaultProfitCalculator(), Expenses::getOperatingExpenses, Expenses::getDeductibleTaxes,
        Expenses::getRemuneration, Expenses::getExceptionalExpenses);

    // Then.
    assertThat(profit).isNotNull().isEqualTo(32600);
  }
----

La méthode "calculateProfit" est appelée avec la CA et la liste des fonctions decorator séparée une virgule. Ceci a été via la paramètre de méthode suivant : "DoubleUnaryOperator... operators".
De nouveau le client de l'API dispose d'un traitement très souple, facilement modifiable et évolutif.

Un exemple sans le decorator "ExceptionalExpenses" :

[source,java]
----
@Test
  public void givenTurnover_whenNotComposingAllDecoratorsWithStream_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = StreamDecorator.INSTANCE.calculateProfit(turnover,
        new DefaultProfitCalculator(), Expenses::getOperatingExpenses, Expenses::getDeductibleTaxes,
        Expenses::getRemuneration);

    // Then.
    assertThat(profit).isNotNull().isEqualTo(34600);
  }
----

== b) Decorator en Java 8 avec une API fluent

Dans cette dernière partie, nous allons voir qu'il est possible d'implémenter le decorator via une API fluent et permettant d'indiquer clairement au client de l'API les traitement effectués.
L'objectif va être de créer une classe Wrapper de type builder afin de composer nos fonctions de façon fluide.

Voici le code complet de la classe appelée FluentDecorator :

[source,java]
----
public final class FluentDecorator<T> {

  private final T value;
  private final Function<T, T> function;

  private FluentDecorator(final T value, Function<T, T> function) {
    this.value = value;
    this.function = function;
  }

  public static <T> FluentDecorator<T> from(final T value) {
    Objects.requireNonNull(value);
    return new FluentDecorator<>(value, Function.identity());
  }

  public FluentDecorator<T> with(final Function<T, T> otherFunction) {
    return new FluentDecorator<T>(this.value, function.andThen(otherFunction));
  }

  public T calculate() {
    return this.function.apply(value);
  }
}
----

Le fluent decorator se base sur une valeur de type T (n'importe quel type via les Generics en Java) et enveloppe une Function<T,T>, c'est à dire une fonction prenant un élément de type T en entré en retournant un élement de même type (comme le DoubleUnaryOperator).

[source,java]
----
  private final T value;
  private final Function<T, T> function;
----

Un constructeur privé permet prend en paramètre les 2 éléments expliqués précédemment (l'aspect privé permet d'empecher l'instantiation en dehors de la classe) :

[source,java]
----
private FluentDecorator(final T value, Function<T, T> function) {
    this.value = value;
    this.function = function;
}
----

Une static factory method est exposé au client de l'API pour initialiser la classe avec un nom parlant. Cette méthode s'appelle "from" et se base sur la valeur qui servira de base de calcul, dans notre cas le CA;
Un contrôle est effectué sur la valeur afin de renvoyer une runtime exception si la valeur est nulle. Le constructeur de la classe est appelé avec cette valeur et une fonction initiale vide (ainsi le paramètre global "function" de la classe ne sera pas nul et on évitera des nullPointerException).

[source,java]
----
public static <T> FluentDecorator<T> from(final T value) {
    Objects.requireNonNull(value);
    return new FluentDecorator<>(value, Function.identity());
}
----

La composition des decorator se fait via la méthode "with" qui prend en paramètre la fonction à ajouter à la composition générale. Le but est de rappeler de nouveau le constructeur de la classe mais cette fois ci de la façon suivante :

[source,java]
----
new FluentDecorator<T>(this.value, function.andThen(otherFunction))
----

La "value" global à la classe est repassée en paramètre et la fonction globale est composé avec "otherFunction" (via andThen). Le résultat de cette composition est repassé en paramètre de la classe FluentDecorator.
Voici le code la méthode :

[source,java]
----
public FluentDecorator<T> with(final Function<T, T> otherFunction) {
    return new FluentDecorator<T>(this.value, function.andThen(otherFunction));
}
----

Lors de l'appel à la méthode "with", le traitelent est lazy car, à ce moment la fonction n'est pas executée.

Une méthode finale permet d'executer la fonction globale à la classe avec la valeur globale, "function.apply(value)". AInsi le résultat de la fonction est récupéré, dans notre cas le calcul du bénéfice :

[source,java]
----
public T calculate() {
    return this.function.apply(value);
}
----

Voici le code du test avec tous les decorators :

[source,java]
----
  @Test
  public void givenTurnover_whenComposingAllDecoratorsWithFluentStyle_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = FluentDecorator
                            .from(turnover)
                            .with(Expenses::getTransportExpenses)
                            .with(Expenses::getOperatingExpenses)
                            .with(Expenses::getDeductibleTaxes)
                            .with(Expenses::getRemuneration)
                            .with(Expenses::getExceptionalExpenses)
                            .calculate();

    // Then.
    assertThat(profit).isNotNull().isEqualTo(32600);
  }
----

Et le code sans le decorator "ExceptionalExpenses" :

[source,java]
----
@Test
  public void givenTurnover_whenNotComposingAllDecoratorsWithFluentStyle_thenCorrectResult() {

    // Given.
    final double turnover = 100000;

    // When.
    final double profit = FluentDecorator
                            .from(turnover)
                            .with(Expenses::getTransportExpenses)
                            .with(Expenses::getOperatingExpenses)
                            .with(Expenses::getDeductibleTaxes)
                            .with(Expenses::getRemuneration).calculate();

    // Then.
    assertThat(profit).isNotNull().isEqualTo(34600);
  }
----