1. Preface
Today we discuss the Builder pattern. This Builder is actually very similar to the Template pattern, but there are differences. That is, in the Template pattern, the parent class operates on the implementations in the subclasses and handles a task within the parent class. However, in the Builder pattern, neither the parent class nor the subclasses care about how to handle it; instead, another class is used to complete the organic combination of these methods. The responsibility of this class is:supervisor, which specifies exactly how to organically combine these methods. In the supervisor class (Director), the parent class is composed in, and then the parent class's operations are called to abstractly accomplish a task. This is the beauty of interface-oriented (abstract) programming. Of course, this Builder can be an interface or an abstract class; here we use an abstract class.

2. Builder Pattern Code
Builder abstract class:
Builder.java
HtmlBuilder implementation class:
HtmlBuilder.java
TextBuilder implementation class:
TextBuilder.java
Director supervisor class:
Director.java
Main class:
Director.java
Running Results


Or:

3. Summary
Regarding the Builder pattern, we must clearly distinguish it from the Template method pattern. In fact, it comes down to who takes on the responsibility of the "supervisor". In the Template method pattern, the parent class assumes this responsibility, while in Builder, there is another dedicated class to complete such operations. The benefit of this is class isolation. For example, in Main, the user has no idea that the Builder abstract class exists; similarly, the Director (supervisor) does not care at all which implementation class it is, because any one of them will be converted to the parent class and then processed (the idea of abstract-oriented programming). Thus isolation is well achieved. Similarly, this design benefits reuse: the better the isolation, the more convenient the reuse. We can fully imagine that if there is another supervisor that uses a different construct method to assemble these complex events, then we do not need to make any modifications to the original code; we only need to add such a supervisor class, define the corresponding methods, and then use it in Main. This kind of idea allows us to avoid modifying source code, making reuse (Builder and its subclasses) very convenient. Similarly, if we want to add a new subclass of Builder, we just fill in according to the methods of the parent class and add our own methods, without modifying the code at all. This is also a form of reuse. Therefore, this idea of reuse (components) can be seen everywhere in design patterns. Its essence is high cohesion and low coupling, component development, trying not to modify the original code, and having extensibility. Once we understand this, let's look at the Template method again: the responsibility is all placed in the parent class. If the responsibility needs to change, the responsibility method in the parent class must be modified; this modifies the original code and is not conducive to reuse. This is also the essential difference between the two.
Original address: https://www.cnblogs.com/zyrblog/p/9230630.html