Builder mode and C ++ implementation

The following is my understanding of the builder model. I have not applied it in development. This is just my understanding of books. Builder Mode

Builder mode: separates the construction of a complex object from its representation, so that different representations can be created during the same build process.This is the standard expression of the builder model, but it seems confusing. What is the separation of Construction and expression? After an object is constructed using a constructor, isn't it fixed? Does it only use its method to change its attributes? How can we make different representations during the same build process? How many constructors are written?

In fact, writing several constructors, setting different properties of Objects Based on Different parameters can also achieve this effect, but this is very troublesome, each time you add a representation, you need to add a constructor. In the future, constructor will not even remember itself, which violates the principle of opening-closing.

Otherwise, only a few set functions can be designed. Each time the attributes are different, I construct an object and then use the set function to change the attributes of the object. This can also achieve the effect. JustCodeIt will be very redundant. Every place where this object is to be used should write several statements. Once the object changes a bit, it has to be changed everywhere, so it is easy to make mistakes, in the future, it is estimated that the logic and code will crash. This also violates the principle of dependency inversion.

As a result, the great gods began to think about it. They could not add many constructor functions, nor directly use a bunch of set functions. Then they found that the construction of some objects was fixed in several steps, just like an assembly line, any product is pieced together through every fixed step. For example, for a mobile phone, put the motherboard first, then the screen, then the battery, then the shell, and paste a film to sell thousands. Every time a new product is launched, a better motherboard will be changed, A larger screen, a large battery, a high-permeability film of super ox B, and a new price.That is to say, these steps have not changed, but they have changed everything.

This is the power of the great gods. We can see the essence through phenomena,Basically changing, changing,An important guiding ideology for object orientation is to encapsulate and isolate the changing ones and leave them unchanged. So they used a builder class to encapsulate each part in the step. The main function of this class is to produce each part, and then abstract and increase the height, so that the dependency is reversed, in this way, only one class needs to be added each time. This class is still the same, but the internal implementation is different. This satisfies the principle of opening-closing. However, there is still a problem. The Builder class is not enough. Although each part of the product has corresponding functions, it is the same as the set function mentioned earlier, A lot of functions are needed, that is, the changed things are encapsulated, but the unchanged things have not been left out yet. In this case, add a director class, which specifically specifies the steps for assembling the product, so that you can tell Director which builder to use to generate different products. For the client, it is very convenient to see a construct function of ctor.

In turn, let's look at the definition of the builder model. building refers to the process of producing a product, indicating the specific implementation of each product part. It encapsulates the implementation of the product part through the Director encapsulation step through builder, then we can isolate and change the two, leaving them unchanged for the client to use.

As shown in the figure, the product must be known and not abstract, but can be combined by different parts. Construct in ctor Ctor is also fixed and is not abstracted. If you want to change the step, you also need to add a function or a diector. Therefore, the builder mode is generally applied to the step without major changes, however, the product may change significantly.

 

Common scenarios

In C #, stringbuilder is an example of a builder. However, it is only a builder and lacks a ctor. It cannot be regarded as a complete builder mode. The builder mode is generally used to build a product.Algorithm.

 

Advantages

1. The construction steps and implementation are isolated, providing flexibility for the specific implementation of the product.

2. encapsulate and abstract the implementation of each step and implement the dependency reversal principle.

3. encapsulates specific steps to reduce code redundancy.

 

Disadvantages

1. The steps (algorithms) for building products must not change dramatically, preferably unchanged, which affects flexibility.

 

C ++ implementation code

Builder. h # ifndef _ builder_h _ # DEFINE _ builder_h _ # include <stdio. h> class product {public: product ();~ Product (); void setparta (int param); void setpartb (int param); void setpartc (int param); void show (); Private: int parta; int partb; int partc;}; Class abstractbuilder {public: abstractbuilder (); Virtual ~ Abstractbuilder (); Virtual void createproduct () = 0; virtual void buildparta (int param) = 0; virtual void buildpartb (int param) = 0; virtual void buildpartc (int param) = 0; Virtual Product * getproduct () = 0 ;}; class builder: Public abstractbuilder {public: Builder ();~ Builder (); void createproduct (); void buildparta (int param); void buildpartb (int param); void buildpartc (int param); product * getproduct (); Private: product * curproduct;}; # endif
 

 

Builder. cpp # include "builder. H" product: product () {} product ::~ Product () {} void product: setparta (int param) {parta = Param;} void product: setpartb (int param) {partb = Param;} void product :: setpartc (int param) {partc = Param;} void product: Show () {fprintf (stderr, "parta = % d partb = % d partc = % d \ n ", parta, partb, partc);} abstractbuilder: abstractbuilder () {} abstractbuilder ::~ Abstractbuilder () {} builder: Builder (): curproduct (null) {} builder ::~ Builder () {} void builder: createproduct () {fprintf (stderr, "Create a Product Shell \ n"); curproduct = new product ();} void builder :: buildparta (int param) {fprintf (stderr, "Part A of the building product \ n"); curproduct-> setparta (PARAM);} void builder: buildpartb (int param) {fprintf (stderr, "section B of the product being built \ n"); curproduct-> setpartb (PARAM);} void builder: buildpartc (INT PARAM) {fprintf (stderr, "building product C section \ n"); curproduct-> setpartc (PARAM);} product * builder: getproduct () {// my understanding is that after the product is handed in, how to release it will not be managed by the builder. Return curproduct ;}

 

Director. h # ifndef _ director_h _ # DEFINE _ director_h _ # include "builder. H" class director {public: Director (abstractbuilder * builder );~ Director (); void construct (); Private: abstractbuilder * curbuilder;}; # endif
 

 

 
Director. cpp # include "director. H" Director: Director (actactbuilder * builder) {curbuilder = builder;} Director ::~ Director () {} void Director: Construct () {If (! Curbuilder) return; curbuilder-> createproduct (); curbuilder-> buildparta (1); curbuilder-> buildpartb (2); curbuilder-> buildpartc (3 );}
 

Client. CPP # include "director. H "int main () {abstractbuilder * builder = new Builder (); Director * Director = new director (builder); Director-> construct (); product * Product = builder-> getproduct (); product-> show (); Return 0 ;}
 

 

 
G ++-O client. cpp builder. cpp director. cpp
 

 

Running result