Today let’s take a look at the “Builder pattern” of design patterns!
Builder model
Introduction to the
The Builder pattern, also known as the generator pattern, is one of the creation patterns.
2. Its design concept is to abstract away the creation process of objects, thus separating the creation and representation of objects. 3. The Builder pattern is to take a large, complex object and break it down in several small steps. 4. It allows the client to create an object simply by specifying its category and content, without the user needing to know the specifics of the internal build.
Four characters in the Builder model:
Product role: a specific product object.
Abstract Builder: Defines ways to create parts of a product object, regardless of the creation details. 3. Concrete Builder: Implement abstract builder and implement its abstract method. 4. Conductor: Build an object that uses the abstract builder. The commander is primarily used to create a complex object. It has two main functions: one is to isolate the generation process of clients and objects; The second is responsible for controlling the production process of product objects.
Code demo
Simply through the text description, maybe you understand the builder model is not very clear. Let’s take a look at a small example of creating a mobile phone to reinforce this pattern.
Mobile phone => Product role
public class MobilePhone {
/ / the mainboard
private String motherboard;
/ / battery
private String battery;
/ / shell
private String shell;
/ /... The get () and set ()
}
Copy the code
Mobile phone build abstract class => corresponding to the abstract builder
public abstract class MobilePhoneBuilder {
protected MobilePhone mobilePhone = new MobilePhone();
// Create a motherboard
public abstract void buildMotherboard(a);
// Create a battery
public abstract void buildBattery(a);
// Create a shell
public abstract void buildShell(a);
// Get the phone
public MobilePhone getMobilePhone(a) {
System.out.println("Get a phone!");
returnmobilePhone; }}Copy the code
Smart phone => Specific builder
public class IntelligentMobilePhone extends MobilePhoneBuilder {
@Override
public void buildMotherboard(a) {
System.out.println("Make smartphone motherboards!");
}
@Override
public void buildBattery(a) {
System.out.println("Make smartphone batteries!");
}
@Override
public void buildShell(a) {
System.out.println("Make smartphone covers!"); }}Copy the code
Mobile phone construction director => Corresponding director
public class MobilePhoneDirector {
private MobilePhoneBuilder mobilePhoneBuilder = null;
// Set up MobilePhoneBuilder through the constructor
public MobilePhoneDirector(MobilePhoneBuilder mobilePhoneBuilder) {
this.mobilePhoneBuilder = mobilePhoneBuilder;
}
// Set MobilePhoneBuilder using the set method
public void setMobilePhoneBuilder(MobilePhoneBuilder mobilePhoneBuilder) {
this.mobilePhoneBuilder = mobilePhoneBuilder;
}
/** * Assemble the phone */
public MobilePhone assemblingMobilePhone(a) {
this.mobilePhoneBuilder.buildMotherboard();
this.mobilePhoneBuilder.buildBattery();
this.mobilePhoneBuilder.buildShell();
return this.mobilePhoneBuilder.getMobilePhone(); }}Copy the code
The test class:
public class Test {
public static void main(String[] args) {
// Create mobile phone build director
MobilePhoneDirector mobilePhoneDirector = new MobilePhoneDirector(new IntelligentMobilePhone());
// Assemble the phonemobilePhoneDirector.assemblingMobilePhone(); }}Copy the code
conclusion
1. The advantage of the Builder pattern is that when creating large complex objects, the client does not have to know the composition details of the product, decoupling the product from the product creation process, and using the same creation process can result in different products.
2. Users can get different products by using different builders. Because each concrete builder is relatively independent, this makes it easy for the program to replace and add concrete builders. And when new products do not need to modify the original code (in accordance with the open and closed principle).
3. Through the builder mode, relatively complex product class creation steps can be decomposed into different methods, making the creation process more clear and more conducive to control the creation process of products.
4. Use it when product classes have more in common, their components are similar, and the creation process is relatively complex.
5. This pattern is not suitable if there are large differences between products.
6. If complex changes within the product result in the need to define multiple concrete build classes to accommodate these changes, you should carefully consider using the Builder pattern.
This is the end of today’s sharing. If you feel that the article written by “newbie” is still good, rememberLike and followYo! Your support is what keeps me going. Article where to write problems also hope that you can point out, I will be modestly taught.