A comprehensive analysis of the builder model in the design pattern and the implementation of _c language in related C + +

There are many examples of builders in life who feel that college life is the best experience of a builder's model:
To complete a college education, the process of university education is generally divided into 4 semesters, so no learning can be considered as a part of the construction process of building a complete university education, and each person has the final result of the 4-year (4-phase) build process, Because it's possible to introduce a lot of parameters into the four-stage build (everyone's chances and opportunities are not exactly the same).

The builders ' model has to solve this problem: when the objects we want to create are complex (usually by a combination of many other objects), we want to separate the creation process of the complex object from the representation (presentation) of the object, the benefit of which is to build the complex object step-by-step, Because parameters can be introduced during the construction of each step, the display of the resulting objects is different from the same steps.

Construction of Object Nature

In some cases, an object will have some important properties that cannot be used as a complete product until they have the proper value. For example, an e-mail message has a sender's address, a recipient's address, a subject, content, an appendix, and so on, which cannot be sent until the minimum recipient address has been assigned.

In some cases, it makes sense that some of the properties of an object must be assigned in a certain order. Another property cannot be assigned until a property is assigned a value. These circumstances allow the construction of nature itself to involve complex business logic.

At this time, this object is equivalent to a product to be built, and the object of these properties is equivalent to the product parts, the process of building a product is the process of assembling parts. Because the process of assembling parts is complex, the combination process of these "parts" is often "externalized" to an object called a builder, which is returned to the client by a product object in which all parts have been built.

The naming considerations

The reason for using "builder" instead of "generator" is that it is more appropriate to "build" and "create" or "build" than to produce a product from a part.
The typical structure of the builder pattern is:

The key to the builder pattern is that the Director object does not return the object directly, but instead creates the object step by step (BUILDPARTA,BUILDPARTB,BUILDPARTC). Of course, here Director can provide a default interface for returning objects (that is, the creation of a generic, complex object that does not specify or uniquely specify the parameters in the Buildpart).
the implementation of the builder model

Complete code example: the implementation of the builder model is very simple, here for the convenience of beginners to learn and reference, will give a complete implementation code (all code in C + + implementation, and under the VC 6.0 test run).

Code Snippets 1:product.h

Product.h
#ifndef _product_h_
#define _PRODUCT_H_
class product{public
  :
  PRODUCT ();
  ~product ();
  void Producepart ();
  Protected:
  private:
};
Class productpart{public
  :
  Productpart ();
  ~productpart ();
  productpart* Buildpart ();
  Protected:
  private:
};
#endif//~_product_h_

Code Snippets 2:product.cpp

Product.cpp
#include "Product.h"
#include <iostream>
using namespace std;
Product::P roduct () {
  producepart ();
  cout<< "return a Product" <<endl;
}
Product::~product () {
}
void Product::P roducepart () {
  cout<< "build part of product ..." <<endl;
}
Productpart::P Roductpart () {
  //cout<< "build Productpart ..." <<endl;
}
Productpart::~productpart () {
}
productpart* Productpart::buildpart () {return
  new Productpart;
}

Code Snippets 3:builder.h

Builder.h
#ifndef _builder_h_
#define _builder_h_
#include <string>
using namespace std;
Class Product;
Class builder{public
  :
  virtual ~builder ();
  virtual void Buildparta (const string& Buildpara) = 0;
  virtual void BUILDPARTB (const string& Buildpara) = 0;
  virtual void BUILDPARTC (const string& Buildpara) = 0;
  Virtual product* getproduct () = 0;
  Protected:
  Builder ();
  Private:
};

Class Concretebuilder:public builder{public
  :
  ConcreteBuilder ();
  ~concretebuilder ();
  void Buildparta (const string& Buildpara);
  void Buildpartb (const string& Buildpara);
  void Buildpartc (const string& Buildpara);
  product* getproduct ();
  Protected:
  private:
};
#endif//~_builder_h_

Code Snippets 4:builder.cpp

Builder.cpp
#include "Builder.h"
#include "Product.h"
#include <iostream>
using namespace STD;
Builder::builder () {} builder::~builder () {}
concretebuilder::concretebuilder (
) {} Concretebuilder::~concretebuilder () {
}
void Concretebuilder::buildparta (const string& Buildpara) {
  cout<< "Step1:build parta ..." <<buildPara<<endl;
}
void Concretebuilder::buildpartb (const string& Buildpara) {
  cout<< step1:build partb ... "<< buildpara<<endl;
}
void Concretebuilder::buildpartc (const string& Buildpara) {
  cout<< step1:build partc ... "<< buildpara<<endl;
}
product* concretebuilder::getproduct () {
  Buildparta ("pre-defined");
  BUILDPARTB ("pre-defined");
  BUILDPARTC ("pre-defined");
  return new Product ();
}

Code Snippets 5:director.h

Director.h
#ifndef _director_h_
#define _director_h_
class Builder;
Class director{public
  :
  Director (builder* bld);
  ~director ();
  void construct ();
  Protected:
  private:
  builder* _bld;

#endif//~_director_h_

Code Snippets 6:director.cpp

Director.cpp
#include "director.h"
#include "Builder.h"
Director::D irector (builder* bld) {
  _ BLD = bld;
}
Director::~director () {
}
void Director::construct () {
  _bld->buildparta ("user-defined");
  _BLD->BUILDPARTB ("user-defined");
  _BLD->BUILDPARTC ("user-defined");
}

Code Snippets 7:main.cpp

Main.cpp
#include "Builder.h"
#include "Product.h"
#include "Director.h"
#include <iostream >
using namespace std;
int main (int argc,char* argv[]) {
  director* d = new Director (new ConcreteBuilder ());
  D->construct ();
  return 0;
}

Code Description: In the example code of the builder pattern, the Buildpart parameter is passed through the client programmer, here to simply illustrate the problem, using "user-defined" instead, the actual possibility is to pass the 3 parameters in the construct method. This allows for a complex object with different nuances.

The builder pattern should be used in the following situations:

1, need to generate the Product object has a complex internal structure.
2. The attributes of the product objects that need to be generated depend on each other, and the builder pattern can be forced to generate order.
3. Some of the other objects in the system are used during object creation, which are not readily available during the creation of the Product object.

The use of builder mode mainly has the following effects:

1. The use of construction mode makes the internal appearance of the product can be changed independently. The use of Builder mode allows the client to not know the details of the internal composition of the product.
2, each builder is relatively independent, and with other builder independent.
3. The final product constructed by the model is more easily controlled.