Builder: Séparez la construction d'un objet complexe de sa représentation, afin que le même processus de construction puisse créer différentes représentations.
Utilisez des scénarios:
Diagramme de classe générale:
Par exemple: de nombreux appareils de nos vies existent sous forme d'assemblage, comme les ordinateurs de bureau. Certains fabricants lanceront certains hôtes d'ordinateur assemblés avec des configurations par défaut (le mode de méthode du modèle peut être utilisé ici). Les clients peuvent acheter des produits avec des configurations par défaut, ou ils peuvent demander aux fabricants de réassembler un hôte avec différentes configurations et méthodes d'assemblage. À ce stade, nous pouvons utiliser le modèle Builder pour répondre aux exigences des clients spéciaux.
Notez que dans cet exemple, le fabricant remonte à un hôte, c'est-à-dire que l'accent est mis sur chaque composant de l'hôte, qui est conforme au scénario d'utilisation donné par le mode Builder ci-dessus.
L'implémentation du code simple est la suivante:
// Classe de produits abstraite, en utilisant le mode Méthode de modèle, différents produits ont différents "Partie composante" Classe abstraite AbstractProduct {Abstract Void Part01 () protégée; Résumé protégé void part02 (); Abstract protégé void part03 (); // La méthode du modèle donne la méthode d'assemblage par défaut, générant le produit par défaut public final abstractProduct defaultProduct () {part01 (); partie02 (); partie03 (); Renvoie ceci; // renvoie l'objet actuel, c'est-à-dire le produit avec la méthode d'assemblage par défaut}} // Produits spécifiques a et b, différents produits implémentent différents "partie composante" de classe ConcreteProducta étend AbstractProduct {Protected void Part01 (); } protégée void part02 () {System.out.println ("Product a: part02 () ..."); } protégée void part03 () {System.out.println ("Product a: part03 () ..."); }} classe ConcreteProductB étend AbstractProduct {Protected void part01 () {System.out.println ("Product b: part01 () ..."); } protégée void part02 () {System.out.println ("Product b: part02 () ..."); } protégée void part03 () {System.out.println ("Produit b: part03 () ..."); }} // Résumé Builder, formule la méthode de combinaison selon laquelle chaque produit doit implémenter BuildPart () et la norme pour la production de buildProduct () Résumé Class AbstractBuilder {public abstract void buildPart (); abstrait abstraitProduct buildProduct (); } / * * Si le constructeur spécifique n'est pas satisfait du produit par défaut (c'est-à-dire lorsque la méthode defaultProduct () dans le produit abstraite est appelée), * vous ne pouvez pas l'appeler pour obtenir le produit, mais utiliser le constructeur spécifique pour modifier la méthode de production et d'assemblage du produit pour obtenir des produits différents * / Class Concretebuildera étend abstrait {privaty abstractproduct product product public void buildPart () {this.producta.part03 (); this.producta.part02 (); this.producta.part01 (); } public abstractProduct buildProduct () {return this.producta; }} classe ConcreteBuilderB étend AbstractBuilder {private abstractProduct productB = new ConcreteProductB (); public void buildPart () {this.productB.part02 (); this.productb.part01 (); // Un composant du produit B est omis, par exemple, les fonctions de cette partie ne sont pas nécessaires par les clients // this.productb.part03 (); } public abstractProduct buildProduct () {return this.productB; }} // Classe de directrice, le constructeur qui pré-tire chaque produit, fournit différentes méthodes d'assemblage pour les utilisateurs qui ont besoin de produits différents de la classe de produit par défaut {private abstractBuilder builda = new ConcreteBuildera (); AbstractBuilder privé BuildB = new ConcreteBuilderB (); public abstractProduct getProducta () {this.buildera.buildPart (); Renvoyez ce.buildera.buildProduct (); } public abstractProduct getProductB () {this.builderb.buildPart (); Renvoie ce.builderb.buildProduct (); }} // CLASSE DE TEST CLASSE PUBLIC Client {public static void main (String [] args) {System.out.println ("Utiliser le mode Méthode du modèle pour obtenir le produit par défaut a"); AbstractProduct defaultProducta = new ConcreteProducta (). DefaultProduct (); System.out.println ("/ NUSE Director Class pour obtenir le produit A avec différentes méthodes d'assemblage"); Directeur directeur = nouveau directeur (); Director.getProducta (); System.out.println ("/ NUSE Director Class pour obtenir le produit B avec différentes méthodes d'assemblage"); Director.getProductB (); }} Résultats des tests:
Utilisez le mode de méthode du modèle pour obtenir le produit par défaut A
Produit A: Part01 () ...
Produit A: Part02 () ...
Produit A: Part03 () ...
Utiliser une classe de directeur pour obtenir des produits avec différentes méthodes d'assemblage A
Produit A: Part03 () ...
Produit A: Part02 () ...
Produit A: Part01 () ...
Utiliser la classe de directeur pour obtenir le produit B avec différentes méthodes d'assemblage
Produit B: Part02 () ...
Produit B: Part01 () ...
En fait, dans cet exemple, la catégorie de produit utilise le mode de méthode du modèle mentionné dans l'article précédent, c'est-à-dire que DefaultProduct () fournit une méthode pour assembler un composant par défaut du produit.
Mais j'ai une question ici. La méthode d'assemblage dite par défaut fournie dans la classe AbstractProduct basée sur le modèle de méthode de modèle est simplement d'imprimer quelques phrases de test, et elle ne renvoie pas vraiment un produit spécifique. Cependant, je ne sais pas si la méthode de traitement pour renvoyer un objet actuel (renvoyez ceci;) dans l'exemple ci-dessus est raisonnable?
De plus, après avoir écrit ces articles sur la mise en œuvre de modèles de conception avec Java Code, j'ai constaté que ce modèle de constructeur de constructeurs semble combiner un modèle de méthode d'usine et un modèle de modèle. Le paragraphe ci-dessus a déjà mentionné mes doutes. En ce qui concerne le modèle d'usine abstrait, je pense personnellement que la classe de directeur dans l'exemple de code ci-dessus est très similaire à la classe d'usine spécifique de l'usine abstraite, mais la classe de directeur doit également créer la méthode d'assemblage de produits avant de retourner un produit. C'est peut-être cette "construction" qui fait que le modèle du constructeur se concentre sur l'assemblage de différentes parties du produit, tandis que le modèle d'usine abstrait ne se concentre que sur la génération d'un produit final.
J'ai déjà lu une phrase et j'ai dit qu'il était à peu près dit: si un problème informatique est difficile à résoudre, il peut être géré en ajoutant une couche intermédiaire. Maintenant que j'y pense, il semble que l'usine abstraite et le mode constructeur utilisent ce "principe" pour réaliser l'effet souhaité. Par exemple, il existe une classe d'usine abstraite dans Abstract Factory, et il y a une classe de réalisateur dans Builder. En dernière analyse, il s'agit d'encapsuler et de masquer certains détails et de les découpler de la mise en œuvre et de l'utilisation.
Je pense que vous devez d'abord comprendre les préoccupations et les scénarios applicables de chaque modèle avant de mieux les saisir.
Peut-être que ces modes sont tous des modes créatifs et que je n'ai aucune expérience pratique, ce qui me rend un peu confus à ce sujet ... Je n'ai pas peur, en pensant un peu en train de les mettre en œuvre, et les appliquer lentement à la réalité devrait progressivement comprendre.
Ce qui précède est tout sur cet article, et j'espère que cela vous inspirera à apprendre.