IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Design Patterns Discussion :

Tutoriel pour apprendre à développer le patron de conception Builder


Sujet :

Design Patterns

  1. #1
    Rédacteur

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    Juillet 2005
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : Juillet 2005
    Messages : 14 974
    Points : 72 948
    Points
    72 948
    Par défaut Tutoriel pour apprendre à développer le patron de conception Builder
    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

  2. #2
    Membre à l'essai
    Homme Profil pro
    Solution Architect
    Inscrit en
    Décembre 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Solution Architect
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2012
    Messages : 3
    Points : 16
    Points
    16
    Par défaut Super mais avec un exemple d'appel du Builder ce serait excellent
    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

  3. #3
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Tech Lead
    Inscrit en
    Avril 2016
    Messages
    1 491
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Tech Lead

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 491
    Points : 6 196
    Points
    6 196
    Par défaut
    Bonjour,

    Citation Envoyé par Colin Damon
    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 :

    Nom : exemple.png
Affichages : 2705
Taille : 83,6 Ko

    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 :

    Nom : schema_general.png
Affichages : 2560
Taille : 21,4 Ko

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

    Citation Envoyé par Design patterns: elements of reusable object-oriented software
    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().

  4. #4
    Rédacteur

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    Juillet 2005
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : Juillet 2005
    Messages : 14 974
    Points : 72 948
    Points
    72 948
    Par défaut
    Bonjour Pyramidev,

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

    Mickael

  5. #5
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro
    Information Technologies Specialist (Scientific Computing)
    Inscrit en
    Août 2005
    Messages
    6 867
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Information Technologies Specialist (Scientific Computing)
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Août 2005
    Messages : 6 867
    Points : 22 921
    Points
    22 921
    Billets dans le blog
    52
    Par défaut
    Citation Envoyé par Colin Damon
    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.

  6. #6
    Futur Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    Juillet 2020
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juillet 2020
    Messages : 3
    Points : 6
    Points
    6
    Par défaut
    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.

Discussions similaires

  1. Réponses: 3
    Dernier message: 15/11/2018, 20h30
  2. Réponses: 2
    Dernier message: 20/06/2018, 13h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo