Le builder pattern fait partie des design patterns, c’est-à-dire des patrons de con­cep­tion qui per­met­tent de résoudre les problèmes de pro­gram­ma­tion dans la pro­gram­ma­tion orientée objet (POO). Ils fa­ci­li­tent la pro­gram­ma­tion pour les dé­ve­lop­peurs : ainsi, vous n’avez pas à repenser la routine de chaque étape ré­cur­rente puisque des pro­prié­tés qui peuvent être modifiées ont déjà été établies. Ces éléments de logiciel remontent au livre « Design patterns. Catalogue des modèles de con­cep­tion réu­ti­li­sables » sorti en 1994 et rédigé par quatre in­for­ma­ti­ciens amé­ri­cains connus sous le nom de Gang of Four (bande des quatre). Notre guide vous présente les aspects es­sen­tiels du builder pattern, ou patron de con­cep­tion monteur, à l’aide d’un exemple pratique.

Qu’est-ce que le builder pattern ?

Le patron builder ap­par­tient au groupe des patrons de création. Il améliore la sécurité lors de la pro­gram­ma­tion ainsi que la li­si­bi­lité du code. L’objectif du patron de con­cep­tion monteur est de créer un objet au moyen d’une classe uti­li­taire, et non avec les cons­truc­teurs connus.

Citation

„Separate the cons­truc­tion of a complex object from its re­pre­sen­ta­tion so that the same cons­truc­tion process can create different re­pre­sen­ta­tions.“

Tra­duc­tion : « Dissocier la cons­truc­tion d’un objet complexe de sa re­pré­sen­ta­tion, afin que le même processus de cons­truc­tion puisse créer des re­pré­sen­ta­tions dif­fé­rentes. » (Tra­duc­tion de IONOS)

– Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (= « Gang of Four »)

Source : Design Patterns: Elements of Reusable Object-Oriented Software (anglais) 1ère édition, éditeur : Addison-Wesley Pro­fes­sio­nal; 1ère édition (10 novembre 1994)

Dans le patron builder, on distingue quatre classes :

  • Directeur : cette classe ne construit pas l’objet complexe di­rec­te­ment, mais utilise plutôt l’interface du monteur pour créer les dif­fé­rentes parties de l’objet et les assembler. Il connaît les séquences de montage du monteur. Avec le directeur, la création d’un objet est dissociée du client.
  • Monteur : fournit une interface per­met­tant de créer les com­po­sants d’un objet (ou d’un produit) complexe.
  • Mon­teur­Con­cret : cette classe construit les dif­fé­rentes parties de l’objet complexe. Il définit et gère également la re­pré­sen­ta­tion du produit qu’il crée.
  • Produit : le résultat de « l’activité » du patron Builder, c’est-à-dire l’objet complexe à cons­truire.

Avec le directeur, l’étape cruciale du patron de con­cep­tion monteur a lieu, la sé­pa­ra­tion de la cons­truc­tion d’un objet/produit du client.

Le builder pattern : re­pré­sen­ta­tion graphique (UML)

Pour la re­pré­sen­ta­tion graphique des séquences de pro­gram­ma­tion, le langage de mo­dé­li­sa­tion unifié, en abrégé UML (Unified Modeling Language), est utilisé. Le diagramme montre que le modèle de cons­truc­tion est constitué de plusieurs objets agissant ensemble.

Avantages et in­con­vé­nients du builder pattern

Avantages du patron de con­cep­tion monteur

La cons­truc­tion (le montage) et la re­pré­sen­ta­tion (la pro­duc­tion) sont intégrées de manière isolée l’une de l’autre. Les re­pré­sen­ta­tions internes des monteurs sont « cachées » au directeur. De nouvelles re­pré­sen­ta­tions peuvent être fa­ci­le­ment insérées grâce à de nouvelles classes de mon­teur­Con­cret. Le processus de cons­truc­tion est contrôlé par le directeur. Si des mo­di­fi­ca­tions doivent être apportées au cours du processus, cela peut se faire sans consulter le client.

In­con­vé­nients du patron de con­cep­tion monteur

Il existe un lien étroit entre le produit, le mon­teur­Con­cret et les classes im­pli­quées dans le processus de cons­truc­tion, de sorte qu’il peut être difficile de modifier le processus de base. La cons­truc­tion d’objets nécessite souvent des con­nais­sances sur leur uti­li­sa­tion et leur en­vi­ron­ne­ment spé­ci­fiques. L’uti­li­sa­tion de modèles familiers, tels que le patron de con­cep­tion monteur, peut amener les pro­gram­meurs à négliger des solutions plus simples et peut-être plus élégantes. Au final, le builder pattern est considéré comme un des patrons de con­cep­tion les moins im­por­tants.

Scénarios d’ap­pli­ca­tion du builder pattern ?

Afin d’illustrer le patron de con­cep­tion monteur, prenons l’image d’un res­tau­rant où un client commande un menu. Les dif­fé­rents acteurs du res­tau­rant agissent dès réception de la commande pour la réaliser. L’ensemble du processus menant à la réception du menu commandé se déroule « en coulisses ». Le client ne voit pas, par exemple, ce qui se passe dans la cuisine pour honorer sa commande : on lui sert le résultat à sa table (en langage de pro­gram­ma­tion : imprimé = print).

Les parties du code qui suivent pré­sen­tent toutes les classes du builder pattern sé­pa­ré­ment.

L’objet, le menu complet, est ini­tia­le­ment vide ; il se remplit lorsque la commande arrive.

public class Menu {
	private String starter = "Pas d’entrée";
	private String maincourse = "Pas de plat principal";
	private String dessert = "Pas de dessert";
	private String drink = "Pas de boisson";
	public void setEntree(String starter) {
		this.starter = starter;
	}
	public void setPlatPrincipal(String maincourse) {
		this.maincourse = maincourse;
	}
	public void setDessert(String dessert) {
		this.dessert = dessert;
	}
	public void setBoisson(String drink) {
		this.drink = drink;
	}
	public void print() {
		System.out.println(
			"Le menu est prêt ! " + "\n" +
			" – Entrée: " + starter +
			" – Plat principal: " + maincourse +
			" – Dessert: " + dessert +
			" – Boisson: " + drink);
	}
}

Le directeur fournit un « en­vi­ron­ne­ment » dans lequel un menu peut être produit (monté) pour l’invité. Cet en­vi­ron­ne­ment est ac­ces­sible à tous les invités. L’invité com­mu­nique ex­clu­si­ve­ment avec le directeur, de sorte que la pro­duc­tion pro­pre­ment dite lui reste cachée :

public class MattsRestaurant {
	private MenuBuilder menuBuilder;
	public void setBuilder(MenuBuilder menuBuilder) {
		this.menuBuilder = menuBuilder;
	}
	public Menu buildMenu(){
		menuBuilder.buildStarter();
		menuBuilder.buildMainCourse();
		menuBuilder.buildDessert();
		menuBuilder.buildDrink();
		return menuBuilder.build();
	}
}

Ensuite, le monteur passe à l’action. Dans l’exemple choisi, il s’agirait d’un chef cuisinier :

public abstract class MenuBuilder {
	Menu menu = new Menu();
	abstract void buildStarter();
	abstract void buildMainCourse();
	abstract void buildDessert();
	abstract void buildDrink();
	Menu build()
{
		return menu;
	}
}

Le mon­teur­Con­cret, dans ce cas le cuisinier, monte (construit/cuit) les dif­fé­rents éléments du menu commandé. Pour ce faire, il redéfinie (override) les éléments de menu « abstraits » existants :

public class MenuOfTheDayBuilder extends MenuBuilder {
	@Override
	public void buildStarter() {
		burger.setStarter("Soupe de potiron");
	}
	@Override
	public void buildMainCourse() {
		burger.setMainCourse("Steak frites");
	}
	@Override
	public void buildDessert() {
		burger.setDessert("Glace à la vanille");
	}
	@Override
	public void buildDrink() {
		burger.setDrink("Vin rouge");
	}
}

Enfin, les points in­di­vi­duels sont exécutés de façon sommaire et livrés à l’invité, c’est-à-dire « imprimés » dans le langage de pro­gram­ma­tion :

public class Main {
	public static void main(String[] args) {
		MattsRestaurant mattsRestaurant = new MattsRestaurant();
		menuRestaurant.setBuilder(new MenuOfTheDayBuilderBuilder());
		buildMenu(menuRestaurant);
		menuRestaurant.setBuilder(new SpecialMenuBuilder());
		buildMenu(menuRestaurant);
	}
	private static void buildMenu(MattsRestaurant mattsRestaurant) {
		MenuOfTheDay menu = mattsRestaurant.buildMenu();
		menu.print();
	}
}
Note

L’exemple choisi est basé sur les codes de Daniel Høyer Jacobsen, qui présente plusieurs il­lus­tra­tions de patrons de con­cep­tion en Java sur son site Web.

Aller au menu principal