Discussion :

[Mickael Baron]

Colin Damon, d'Ippon Technologies, vous propose un tutoriel Java pour apprendre à développer le patron de conception Builder.

Le lien de l'article : https://ippon.developpez.com/tutorie...ption-builder/

Profitez de cette discussion pour faire part de vos remarques, commentaires ou d'éventuelles informations ou techniques complémentaires.

L'équipe Java

Retrouver les meilleurs cours et tutoriels pour apprendre l'implémentation de patron de conception avec le langage Java

[aoo06]

Bonjour, tout est dans le titre. N'étant pas un expert java, j'aurai plus facilement compris et appliqué ce design pattern.
Merci en tous cas pour cet article

[Pyramidev]

Bonjour,

Pour ces raisons, j'utilise aujourd'hui beaucoup (trop ?) de Builders dans la construction des produits sur lesquels je travaille et je ne peux que vous inviter à en faire autant ! (Même si c'est un peu verbeux, il faut bien l'admettre).

La technique présentée dans la première partie de l'article est une simulation de la fonctionnalité des paramètres nommés. La mise en place est verbeuse en Java car ce langage n'a pas (encore ?) de sucre syntaxique pour supporter cette fonctionnalité de manière conviviale.

C'est un point sur lequel Python s'en sort bien : https://docs.python.org/3/tutorial/c...ction-examples

En C++, il n'y a pas non plus de support natif des paramètres nommés. La solution de contournement est la même que celle de l'article de Colin Damon, mis à part que la communauté C++ l'appelle le named parameter idiom.

Pour revenir à l'article ajouté à Developpez.com, quand j'avais lu dans le titre patron de conception Builder, j'avais pensé au patron de conception Builder défini dans le célèbre livre Design patterns: elements of reusable object-oriented software (1994). Mais les exemples de l'article de Colin Damon ne sont pas toujours compatibles avec la définition de ce livre. Cela dit, dans son article, Colin Damon n'a pas affirmé suivre le livre à la lettre. Le livre n'a pas été mentionné.

Quelques détails sur le patron de conception Builder défini dans le livre :

L'exemple introductif est celui-ci :



Ici, le patron de conception Builder sert à découpler le parsing d'un fichier RTF du traitement qui est fait derrière. Pour ajouter un nouveau traitement, il faut ajouter une nouvelle classe qui dérive de TextConverter.

Le schéma général donné est celui-ci :



L'explication donnée dans le livre insiste sur la présence d'une interface abstraite par dessus les builders :

It lets you vary a product's internal representation. The Builder object provides the director with an abstract interface for constructing the product. The interface lets the builder hide the representation and internal structure of the product. It also hides how the product gets assembled. Because the product is constructed through an abstract interface, all you have to do to change the product's internal representation is define a new kind of builder.

Un peu plus loin, on a un autre exemple, codé en C++, avec une classe de base MazeBuilder qui a 4 fonctions virtuelles void BuildMaze(), void BuildRoom(int room), void BuildDoor(int roomFrom, int roomTo) et Maze* GetMaze().

[Mickael Baron]

Bonjour Pyramidev,

Très intéressant comme réponse. Merci

Mickael

[bouye]

Pour ces raisons, j'utilise aujourd'hui beaucoup (trop ?) de Builders dans la construction des produits sur lesquels je travaille

A noter que la surutilisation des builders implique une plus grosse taille d'API/lib et peut aussi amener a une trop grosse consommation mémoire au runtime. Ce sont les 2 raisons qui ont mené a leur suppression des version récentes de JavaFX : déprécié dans JavaFX 8 et retrait définitif dans les versions ultérieures. A mon grand regret, puisque l'API fluente était facilement utilisable pour des initialisations inline de champs et variables contenant des contrôles UI.

De mon coté je continue a en utiliser, notamment lorsqu'il s'agit de créer des classes contenant les paramètres de taches. En effet, plutôt de que passer de très nombreux paramètres dans le constructeur de la tache, je passe juste un seul objet dédié qui a été initialisé via un builder (qui reçoit les valeurs que l'utilisateur a choisi dans l'UI).

Par contre je n'aime trop dupliquer les champs de l'objet dans le code du builder. Je me contente plutôt d'avoir dans le builder une instance cachée de l'objet a construire. Et la méthode build se contente d’instancier l'objet résultat et de recopier les champs de l'objet source vers l'objet destination.

Ce qui donne qq chose comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public class Parameter {
   Truc truc;
   Chose chose;
   Machin machin;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class ParameterBuilder {
   private final Parameter delegated = new Parameter(); 

   private ParameterBuilder() {
   }

   public static ParameterBuilder create() {
      return new ParameterBuilder();
   }

   public Parameter build() {
       Parameter result = new Parameter();
       result.truc = delegated.truc;
       result.chose= delegated.chose;
       result.machin= delegated.machin;
       return result;
   }

   public ParameterBuilder machin(Machin value) {
       delegated.machin = value;
       return this;
   }
}

Note : je n'ai pas souhaiter rendre l'objet Cloneable pour rester sur des POJO.

Ça limite le nombre de modifications a apporter au builder lorsqu'on introduit de nouveaux champs dans l'objet a construire (il faut juste rajouter les méthodes idoines pour modifier la valeur et les lignes idoines dans la méthode build() pour construire le résultat). Évidement ça fonctionne ici car mes objets a construire sont très simple et sans effet de bord (ex: on n'ouvre pas de connexion réseau, sur une BD ou un fichier), si c’était le cas alors il serait mieux que le builder conserve directement les champs a recopier dans l'objet comme tu le fais.

Note : dans un mode post-JDK 14, un builder qui sera amené a construire un Record devra alors bien sur conserver lui-même les valeurs.

De plus, j'ai préféré conserver un certain détachement/découplement entre l'objet et son builder en ne liant pas les 2 comme tu le fais toi (inclusion en classe interne et utilisation en paramètre du constructeur de l'objet). En cela je suis le contexte de fonctionnent des builders de JavaFX (avant leur retrait) puisque ce sont ceux-ci qui m'ont introduit au pattern.

[cdamon]

Bonsoir,

merci pour les retours ! En fait, j'ai fais cet article pour venir en support d'un autre : "Des Objets, pas des Data Classes" et, c'est vrai qu'en le voyant seul, comme un tuto, c'est franchement légé (son titre originel est : "Les builders dans tous leurs états" pour faire référence au coté mutable de ces objets).

La version rapide : j'utilise essentiellement cette manière de faire pour la construction des objets du domain. Le fait de laisser la logique de construction dans le constructeur de l'objet a construire me permet de garder les contrôles de cohérence dans ce dernier.