Definition:

Separating the construction of a complex object from its representation allows the same construction process to create different representations. The generator pattern uses a director object and a concrete builder object to build all the parts one by one to build the complete object.

Four elements:

Builder: Generator interface that defines the actions of the parts needed to create a Product object.

ConcreteBuilder: Concrete generator implementation that implements the creation of parts, assembles the parts of a Product object, and provides a method for the user to retrieve the assembled Product object.

Director: The Director, also known as the guide, is used to build the required Product objects in a unified process using the Builder interface.

Product: A Product that represents a complex object built by a generator and contains multiple parts.

Example:

There is an example of KFC on the web to describe the generator pattern, which is easy to understand. Suppose KFC launches two sets: Orleans Drumstick set and spicy drumstick set.

The Orleans combo includes an Orleans drumstick, a fried chicken wing, and a Sprite.

The chicken drumstick combo includes: a spicy chicken drumstick, an order of French fries, and a coke.

Each set meal is: staple food, non-staple food, beverage. KFC staff should provide set meals according to customers’ requirements. What is fixed and what is changing in this requirement? It’s clear that customers want the same set meal, and they want the same thing. Set meals are staple food, non-staple food, drinks, which is also fixed. As for what the staple food is, what the non-staple food is, what the beverage is, this is changing.

In an actual software development process, sometimes facing the creation of “a complex object, its child objects are usually made of each part of the adoption of a certain combination, due to the change of demand, each part of the complex object or its object often want to change (for example, chicken drumsticks fort package customers don’t like coke, milk tea) you want to change, But their structure is relatively stable (the set meal must be a main course, a side meal and a drink). When encountering such scenarios, the generator pattern is appropriate.

Define a product class:

public class Entity1{... }public class Entity2{... }public class Entity3{... }public class Product{
      Entity1 entity1;
      Entity2 entity2;
      Entity3 entity3;
}Copy the code

The small modules in the product class are different, and they make up the product.

According to the requirements of specific scenarios, n generator classes are defined:

public interface IBuild{      
    public void createEntity1(a);      
    public void createEntity2(a);     
    public void createEntity3(a);      
    public Product composite(a);      
    public Product create(a);    
}
public class BuildProduct implements IBuild{
      Product p = new Product();
      public void createEntity1(a){ 
      //p.entity1 = ...  
      }      
      public Product create(a){ 
         returncomposite(); }... }public class BuildProduct1 implements IBuild{
      Product p = new Product();                       
      public void createEntity1(a){ 
                //p.entity1 = ...  }... }Copy the code

Define a commander class, unified scheduling project:

public class Director{ 
     private IBuild build;
     public Director(IBuild build){ 
            this.build = buid;  
      }     
     public Product build(a){
           build.create();
      }     
     public static void main(a){
         IBuild build = new BuildProduct();
         Director direcotr = newDirector(build); Prodcut p = director.build(); }}Copy the code

Advantages:

1. The generator pattern is used to keep clients from having to know the details of the internal composition of the product.

2. The concrete builder classes are independent of each other, which is very beneficial for system expansion.

3. Since the specific builder is independent, the construction process can be gradually refined without any impact on other modules.

Disadvantages:

The builder mode’s “process” is exposed, making the builder mode more flexible and making the process opaque to the customer. (To be textual research, the author here is not very understanding, welcome to say their own views)

Application Scenarios:

1. You need to generate a product object with a complex internal structure. Each internal component can be an object in itself or a component of an object.

2. The properties of the product objects to be generated depend on each other. The build model can enforce a step-by-step build process.

3. Other objects in the system will be used during object creation, which are not easily obtained during production object creation

Original: https://www.javazhiyin.com/472.html