This is the 16th day of my participation in the August Text Challenge.More challenges in August

The Builder Pattern builds a complex object step by step from multiple simple objects. This type of design pattern is the creation pattern, which provides the best way to create objects.

By separating the building process of a complex object from its representation, the Builder pattern allows the building process to expand freely, reducing the coupling of parts and assembly processes.

Scenarios used by the Builder Pattern

  • Too many corresponding member variables need to be initialized, and the initialization is particularly complex, requiring too many constructor parameters;
  • The same method is called by different classes, producing different results. (Mainly due to different initialized member variables.)
  • Product classes are complex, and multiple member variables can be constructed to correspond to the class and produce different results.

UML diagram of the builder

Through the UML diagram, you can see the role classification in the BuilderPattern.

  • AbstractBuilder: an AbstractBuilder defines the process of building a product, typically a method that requires subclasses to implement.
  • ConcreteBuilder: An abstract builder’s implementation, implemented according to specific requirements.
  • Product: indicates the Product category
  • Director: Unified assembly build process

We know that a mobile phone consists of a screen, buttons, CPU, battery and other components. Let’s take building a mobile phone as an example.

Defining product classes

/** * Define the mobile product category *@author Iflytek_dsw
 *
 */
class PhoneProduct {
	private String screen;
	private String battery;
	private String hardware;
	protected PhoneProduct(a) {}
	public void setScreen(String screen) {
		this.screen = screen;
	}
	public void setBattery(String battery) {
		this.battery = battery;
	}
	public void setHardware(String hardware) {
		this.hardware = hardware; }}Copy the code

Defining the Abstract Builder

/** * Define the abstract Builder class, define the method to construct Product *@author Iflytek_dsw
 *
 */
public abstract class AbstractPhoneBuilder {
	public abstract void buildScreen(String screen);
	public abstract void buildBattery(String battery);
	public abstract void buildHardware(String hardware);
	public abstract PhoneProduct createPhone(a);
}
Copy the code

Define a concrete Builder class

/** * Create an Android phone product *@author Iflytek_dsw
 *
 */
public class AndroidPhoneBuilder extends AbstractPhoneBuilder{

	private PhoneProduct product = new PhoneProduct();

	@Override
	public void buildScreen(String screen) {
		product.setScreen(screen);
	}

	@Override
	public void buildBattery(String battery) {
		product.setBattery(battery);
	}

	@Override
	public void buildHardware(String hardware) {
		product.setHardware(hardware);
	}

	@Override
	public PhoneProduct createPhone(a) {
		returnproduct; }}Copy the code

Define the Director class

public class Director {
	private AbstractPhoneBuilder builder;

	public Director(AbstractPhoneBuilder builder) {
		super(a);this.builder = builder;
	}
	
	public void concreatePhone(String screen,String battery,String hardware){ builder.buildBattery(battery); builder.buildHardware(hardware); builder.buildScreen(screen); }}Copy the code

Defining the client

public class Client {
	public static void main(String args[]){
		AndroidPhoneBuilder androidPhoneBuilder = new AndroidPhoneBuilder();
		Director director = new Director(androidPhoneBuilder);
		director.concreatePhone("Samsung"."Digititan"."Imax6"); PhoneProduct product= androidPhoneBuilder.getPhone(); }}Copy the code

In the example above, the Director class encapsulates the process of building complex objects and then generates concrete instance objects by specifying concrete Builder classes. The Builder and Director classes work together to describe the process of building a complex object with its representation so that the same process can create different instance objects.

From the example above, it might feel complicated to generate an object through the builder mode. Therefore, in practical use, the Director class is generally omitted, forming a simplified version. For the example above, let’s look at the following condensed version:

/** * Define the mobile product category *@author Iflytek_dsw
 *
 */
class PhoneProduct {
	private String screen;
	private String battery;
	private String hardware;
	protected PhoneProduct(a) {}
	public void setScreen(String screen) {
		this.screen = screen;
	}
	public void setBattery(String battery) {
		this.battery = battery;
	}
	public void setHardware(String hardware) {
		this.hardware = hardware;
	}
	
	/** * Encapsulate Builder inner class *@author Iflytek_dsw
	 *
	 */
	public static class Builder{
		private PhoneProduct product = new PhoneProduct();
		
		public Builder setScreen(String screen){
			product.screen = screen;
			return this;
		}
		
		public Builder setBattery(String battery) {
			product.battery = battery;
			return this;
		}
		
		public Builder setHardware(String hardware) {
			product.hardware = hardware;
			return this;
		}
		
		public PhoneProduct buildProduct(a){
			returnproduct; }}}/ / the client
public class Client {
	public static void main(String[]args){
		PhoneProduct.Builder builder = new PhoneProduct.Builder();
		builder.setBattery("Digititan");
		builder.setHardware("Imax6");
		builder.setScreen("The company"); PhoneProduct product = builder.buildProduct(); }}Copy the code

By removing the Director class, the entire class build structure is much cleaner and the code is much more readable. So I recommend you to do it this way.