Apprendre à développer le patron de conception Builder avec Java,
Un tutoriel de Colin Damon
Le 2020-06-15 17:38:49, par Mickael Baron, Rédacteur
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
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
-
aoo06Membre à l'essaiBonjour, 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 articlele 23/06/2020 à 14:33 -
PyramidevExpert éminentBonjour,
Envoyé par Colin Damon
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 :Envoyé par Design patterns: elements of reusable object-oriented software le 24/06/2020 à 1:43 -
Mickael BaronRédacteurBonjour Pyramidev,
Très intéressant comme réponse. Merci
Mickaelle 24/06/2020 à 8:37 -
bouyeRédacteur/Modérateur
Envoyé par Colin Damon
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 : 1
2
3
4
5public class Parameter { Truc truc; Chose chose; Machin machin; }
Code : 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23public 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; } }
Ç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.le 02/07/2020 à 1:22 -
cdamonFutur Membre du ClubBonsoir,
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.le 16/07/2020 à 21:26