1、builder模式
场景
构造一个复杂的对象,很多属性的时候,有些属性构造的时需要做一些校验或者格式转换
1-1、不使用构造器模式
public class WithoutBuilderPatternDemo {
public static void main(String[] args) {
//构造这个复杂的product对象
Product product = new Product();
//设置 field1属性
System.out.println("在设置field1之前进行复杂的校验逻辑");
product.setField1("值1");
//设置 field2属性
System.out.println("在设置field2之前进行复杂的校验逻辑");
product.setField2("值2");
//设置 field2属性
System.out.println("在设置field3之前进行复杂的校验逻辑");
product.setField2("值3");
/**
* 上面是简化的一个逻辑,实际上对于一些有几十个字段,甚至是上百个字段的复杂对象的构建
* 上面那段代码极度膨胀,非常复杂
* 一个是说,大量的代码堆积在一起,维护性非常差,可读性非常差,一坨代码,跟翔一样,读不懂,没法改
* 另外一个是说,这段逻辑,如果在多个地方都有使用的话,一旦这段逻辑出现了一些变化,那么可能就需要
* 在多个地方修改这一大坨跟屎一样的代码
* 把不同的构造的步骤,抽取成某一个方法
*/
}
public static class Product{
private String field1;
private String field2;
private String field3;
// get and set ...
}
}
1-2、使用构造器模式
public class OptimizeBuilderPatternDemo {
public static void main(String[] args) {
Product product = new ConcreteBuilder()
.filed1("值1")
.filed2("值2")
.filed3("值3")
.create();
System.out.println(product);
//现在基本上流行的一些开源框架,构造器模式的运用,一般都是上面这种变种模式
}
public static class Product {
private String field1;
private String field2;
private String field3;
// get and set....
}
public interface Builder{
Builder filed1(String value);
Builder filed2(String value);
Builder filed3(String value);
Product create();
}
public static class ConcreteBuilder implements Builder{
private Product product;
@Override
public Builder filed1(String value) {
System.out.println("在设置field1之前进行复杂的校验逻辑");
product.setField1(value);
return this;
}
@Override
public Builder filed2(String value) {
System.out.println("在设置field2之前进行复杂的数据格式转化逻辑");
product.setField2(value);
return this;
}
@Override
public Builder filed3(String value) {
System.out.println("在设置field3之前进行复杂的数据处理逻辑,跟其他对象的数据进行关联");
product.setField3(value);
return this;
}
@Override
public Product create() {
return product;
}
}
}
总结
构造器是一种非常棒,非常实用,非常常用的设计模式,很有必要运用到日常编码中,同时阅读开源项目源码的时候,这种模式太常见了。