23 design modes [3]-Generator (builder)

Objective

Generator, aka Builder mode, belongs to the Create mode. It is described in the book design mode-Reusable object-oriented software as "separating the construction of a complex object from his presentation so that the same build process can create different representations".

Unlike factory methods and abstract factories , the factory approach focuses on deferring the instantiation of a class to a subclass, which determines the creation of a factory, thereby obtaining a product, a large factory with multiple factory methods, and a focus on the creation of a series of products. Instead, the builder focuses more on the creation logic of the product while creating the product. Because of their different focus, factory methods are suitable for creating complex products, and generators are suitable for creating more complex products.

A simple example. Abstract factory represents a production of a variety of products in the foundry, the factory method represents a product of the production workshop, the generator represents a product line.

Structure

In the builder, you need support for several roles such as:

• Ibuilder (Generator interface): Used to define the various functions required to create a product instance;

• ConcreteBuilder (Generator interface Implementation): Implement the various functions required to create a product instance;

• Directors (Director): Use generators to create products that encapsulate the instantiation logic of the product;
• Product (Product): Object created by the Director;

Realize

The so-called "separation of the construction of a complex object from its representation" refers to the processing of the instantiation logic of the product by the director rather than the generator. Each of the different generators implements the functions required to create a product instance, creating different representations of the same build process.

For example, in a key mouse suit contains a keyboard and a mouse, different mouse sets have different brands, models of keyboard and mouse. A complete set of key mice can be obtained by different combinations.

Public interface imouse{string Getbrand ();}    public class logitechmouse:imouse{public string Getbrand () {return "Logitech-logitech G903";    }}public class razemouse:imouse{public string Getbrand () {return "Thunder Snake-raze Viper"; }}public interface ikeyboard{string Getbrand ();}    public class logitechkeyboard:ikeyboard{public string Getbrand () {return "Logitech-logitech G910 RGB";    }}public class razekeyboard:ikeyboard{public string Getbrand () {return "Thunder Snake-raze Sanno tarantula";    }}public class kit{public imouse Mouse {set; get;} = null; Public Ikeyboard Keyboard {set; get;} = NULL;}    public interface ikitbuilder{void Buildmouse ();    void Buildkeyboard (); Kit Getkit ();}    public class logitechkitbuilder:ikitbuilder{Private Kit _kit = null;    Public Logitechkitbuilder () {This._kit = new kit (); } public void Buildmouse () {This._kit.    Mouse = new Logitechmouse (); } public void BuildkeyboarD () {This._kit.    Keyboard = new Logitechkeyboard ();    } public Kit Getkit () {return this._kit;    }}public class razekitbuilder:ikitbuilder{private Kit _kit = null;    Public Razekitbuilder () {This._kit = new kit (); } public void Buildmouse () {This._kit.    Mouse = new Razemouse (); } public void Buildkeyboard () {This._kit.    Keyboard = new Razekeyboard ();    } public Kit Getkit () {return this._kit;            }}public class kitdirector{public Kit Constructkit (Ikitbuilder builder) {if (builder = = null) {        return null; } builder.        Buildmouse (); Builder.        Buildkeyboard (); Return builder.    Getkit (); }}class program{static void Main (string[] args) {//create builder Ikitbuilder builder = new Logitechkitbuilde        R ();        Ikitbuilder builder = new Razekitbuilder ();        Create director Kitdirector = new Kitdirector (); The guide creates a production by injecting the generatorProduct Entity Kit KIT = Director.        Constructkit (builder); Console.WriteLine ($ "The mouse in the current package is: {kit.        Mouse.getbrand ()} "); Console.WriteLine ($ "The keyboard in the current package is: {kit.        Keyboard.getbrand ()} ");    Console.readkey (); }}

In the code above, we get different kit entities by injecting different generator (Ikitbuilder) entities into the same director (Kitdirector) to achieve the purpose of creating different representations for the same build process. In the Portal program class, it is not known how the kit was created, its creation logic is encapsulated in the director Kitdirector, and its representation and internal structure are encapsulated in the various implementation classes of the generator Ikitbuilder. This way to improve the modularity of the product, convenient for our later maintenance and expansion.

If you need to add a new representation (the mouse kit) just add a new generator interface implementation.

If you need to make changes to the product (such as adding mouse pads to the mouse set), you need to modify the generator and the director in addition to modifying the product itself.

It can be seen that the amount of changes to modify the product is very large. To reduce the resulting changes, you can define Ikitbuilder as an abstract class and define all its functions as virtual functions as default functions for all subclasses. The advantage of this is that when we modify the product, we do not have to modify each generator (not every mouse-button kit contains the PAD), only need to modify the specific generator. While this approach can reduce some of the changes, it also creates some limitations on our later extensions (each class can inherit only one parent). So, the way to define the generator depends on the actual demand, and this is not described here.

Summarize

Generator, which can separate the creation logic of a complex object from its representation, decouple the object from the creation logic of the object, and facilitates the maintenance and extension of the program. The creation of objects can be more granular control of the object's creation logic, making this creation process clearer, and the individual generators are relatively independent, through different generators to obtain different object entities, in line with the open and closed principle.

The number of generators increases with an increase in the number of objects represented (that is, the more representations of objects, the more corresponding generators), and the larger the number of objects represented, the more bloated the program becomes. Therefore, it is not appropriate to use this mode when the representation of an object is more or each representation is significantly different.

The above is my understanding of the generator (builder mode) and I hope to help you. There is something wrong, but also look at treatise.

Sample Source: Https://gitee.com/wxingChen/DesignPatternsPractice

23 design modes [3]-Generator (builder)