Voici quelques raisons plaidant en faveur de l'utilisation du modèle et de l'exemple de code en Java, mais il s'agit d'une implémentation du modèle de générateur couvert par le gang des quatre dans les modèles de conception . Les raisons pour lesquelles vous l'utiliseriez en Java s'appliquent également à d'autres langages de programmation.
Comme l'indique Joshua Bloch dans Effective Java, 2nd Edition :
Le modèle de générateur est un bon choix lors de la conception de classes dont les constructeurs ou les usines statiques auraient plus d'une poignée de paramètres.
Nous avons tous à un moment donné rencontré une classe avec une liste de constructeurs où chaque ajout ajoute un nouveau paramètre d'option:
Pizza(int size) { ... }
Pizza(int size, boolean cheese) { ... }
Pizza(int size, boolean cheese, boolean pepperoni) { ... }
Pizza(int size, boolean cheese, boolean pepperoni, boolean bacon) { ... }
C'est ce qu'on appelle le modèle de constructeur télescopique. Le problème avec ce modèle est qu'une fois que les constructeurs ont 4 ou 5 paramètres, il devient difficile de se souvenir de l' ordre requis des paramètres ainsi que du constructeur particulier que vous pourriez souhaiter dans une situation donnée.
Une alternative que vous avez au modèle de constructeur télescopique est le modèle JavaBean où vous appelez un constructeur avec les paramètres obligatoires, puis appelez tous les paramètres facultatifs après:
Pizza pizza = new Pizza(12);
pizza.setCheese(true);
pizza.setPepperoni(true);
pizza.setBacon(true);
Le problème ici est que, parce que l'objet est créé sur plusieurs appels, il peut être dans un état incohérent au cours de sa construction. Cela nécessite également beaucoup d'efforts supplémentaires pour garantir la sécurité du fil.
La meilleure alternative est d'utiliser le modèle Builder.
public class Pizza {
private int size;
private boolean cheese;
private boolean pepperoni;
private boolean bacon;
public static class Builder {
//required
private final int size;
//optional
private boolean cheese = false;
private boolean pepperoni = false;
private boolean bacon = false;
public Builder(int size) {
this.size = size;
}
public Builder cheese(boolean value) {
cheese = value;
return this;
}
public Builder pepperoni(boolean value) {
pepperoni = value;
return this;
}
public Builder bacon(boolean value) {
bacon = value;
return this;
}
public Pizza build() {
return new Pizza(this);
}
}
private Pizza(Builder builder) {
size = builder.size;
cheese = builder.cheese;
pepperoni = builder.pepperoni;
bacon = builder.bacon;
}
}
Notez que Pizza est immuable et que les valeurs des paramètres sont toutes au même endroit . Étant donné que les méthodes de définition du générateur renvoient l'objet générateur, elles peuvent être chaînées .
Pizza pizza = new Pizza.Builder(12)
.cheese(true)
.pepperoni(true)
.bacon(true)
.build();
Il en résulte un code facile à écrire et très facile à lire et à comprendre. Dans cet exemple, la méthode de génération peut être modifiée pour vérifier les paramètres après qu'ils ont été copiés du générateur vers l'objet Pizza et lever une IllegalStateException si une valeur de paramètre non valide a été fournie. Ce modèle est flexible et il est facile d'y ajouter plus de paramètres à l'avenir. Il n'est vraiment utile que si vous allez avoir plus de 4 ou 5 paramètres pour un constructeur. Cela dit, cela pourrait être utile en premier lieu si vous pensez que vous ajouterez peut-être plus de paramètres à l'avenir.
J'ai emprunté massivement à ce sujet dans le livre Effective Java, 2nd Edition de Joshua Bloch. Pour en savoir plus sur ce modèle et d'autres pratiques Java efficaces, je le recommande vivement.