David's design patterns Study Notes 03: Builder

David's design patterns Study Notes 03: Builder

  I. OverviewThe builder mode separates the construction of a complex object from its representation, so that different representations can be created during the same construction process. Like factory pattern, builder pattern is designed to build objects. Similar to abstract factory, it usually contains multiple factory methods. However, unlike abstract factory, by assembling multiple parts, builder pattern forms an independent product and provides it to upper-layer applications. abstract factory builds multiple independent products. Ii. StructureThe class diagram of the builder mode is as follows: Figure 1: the class diagram of the builder mode includes the following components: Builder (Abstract builder) role: this role is used to standardize the construction of each component of a product object. Generally, this role is independent from the business logic of the application. Concrete builder role: this role is played by closely related classes of applications. They create product instances under the call of the mentor. This role completes product assembly and provides finished functions while implementing the methods provided by the abstract builder role. Director (Instructor) Role: Call a specific builder role to create a product object. The mentor does not have the specific knowledge of the product class. What really possesses the specific knowledge of the product class is the specific builder object. Product role: a complex object to be created. It includes the classes that define components, including the interfaces that assemble these components into products. Iii. ApplicationThe builder mode should be considered in the following situations: 1. When creating complex objects, algorithms should be independent of the components of the objects and their assembly methods. 2. When the constructor must allow different representations of the object to be constructed. I personally think that the builder mode can be regarded as a complicated simple factory (multiple sub-products are created but eventually combined), but the key of the builder mode is that when creating a complex object, the combination process often involves complex processing. At the same time, the separation of duties makes the combination logic of modifying complex objects independent and simple. Iv. Advantages and DisadvantagesSeparation of duties makes the program structure clearer. To provide a new product, you only need to derive a new concretebuilder class from the builder base class to create a new product, if we need a new product or adjust the creation process of a new product, we only need to make a brief modification to the code at the product building place by calling the builder interface, because the building process of each part of the product has been encapsulated in the concretebuilder class. In the factory method mode, the internal appearance of a product is determined by the product itself, while in the builder mode, the product is "Externalized" by the builder. In this way, defining a new builder role can change the internal appearance of the product and comply with the "Open and Close principle ". The buider mode makes it unnecessary for customers to know too many internal details of the product. It encapsulates the creation and representation of complex objects in a specific builder role, and The Director coordinates the builder role to obtain a specific product instance. The builder mode provides more refined control over the creation of complex products. The product composition is completed step by calling a specific builder role by the Director role, therefore, the product construction process is better reflected than other creation modes. 5. ExpansionWhen understanding the builder mode, pay attention to the following points: 1. the builder mode is the same as other creation modes, separating product creation (builder class) from product use (client) build different products by implementing concretebuilder. 2. In addition to the builder class system, the builder mode also has an important role: Director. The Director role is often ignored in the builder mode. However, in my opinion, director plays an important role in our understanding and application of the builder mode. builder and its subclass are responsible for the creation of various components of the product, while director is responsible for product assembly, the two are indispensable (in some cases, we can consider porting the Assembly responsibilities of the director class to the customer code or builder class for implementation, although the role of ctor Ctor is absent, its function still exists, but it loses the scalability of Director ); 3. Because the builder mode separates object Assembly from the object creation class, different concretebuilder can be passed to the director class, to achieve "the same build process can create different representations", that is, the same creation process can create different product effects, which is exactly what the builder Mode means. In addition to extension on the builder class system, we can also expand the builder mode on the director class system to expand to the concretedireclass, each concretedireis responsible for completing a product assembly method, such as concretedirector1 using builder. buildparta + Builder. buildpartb is used to assemble the product, while concretedirector2 uses builder. buildparta + Builder. buildpartc is used to assemble products to implement more complex "product production lines ". Vi. ExampleThe structure of the builder mode is relatively simple, and there is no need to explain it more. The following uses a piece of "Toys" code to demonstrate the implementation method of this mode, in a specific application, getproduct can be used as a member method of the ctor class or a member method of the builder class. In actual application, it can be determined as needed: # include <iostream> # include <algorithm> # include <string> # include <vector> using namespace STD; // to simplify problem, just use string as productpart type. typedef string productpart; struct pcbuilder {virtual void preparemonitor () = 0; virtual void preparecpu () = 0; virtual void prepareharddisk () = 0 ;//... vector <productpart> & getproduct () {return product;} vector <productpart> product ;}; struct cheappcbuilder: Public pcbuilder {void preparemonitor () {product. push_back ("monitor: CRT");} void preparecpu () {product. push_back ("CPU: celeon");} void prepareharddisk () {product. push_back ("harddisk: 40g") ;}}; struct expensivepcbuilder: Public pcbuilder {void preparemonitor () {product. push_back ("monitor: LCD");} void preparecpu () {product. push_back ("CPU: Pentium");} void prepareharddisk () {product. push_back ("harddisk: 200g") ;}}; struct ctor {void construct (pcbuilder * builder) {builder-> preparemonitor (); builder-> preparecpu (); builder-> prepareharddisk ();//...}}; int main () {Director D; pcbuilder * pb = new expensivepcbuilder (); D. construct (PB); vector <productpart> product = Pb-> getproduct (); cout <"We got a PC made up of:" <Endl; copy (product. begin (), product. end (), ostream_iterator <string> (cout, "/N"); Return 0 ;}