设计模式2——创建者模式
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是“将对象的创建与使用分离”。
这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。
创建型模式分为:
- 单例模式;
- 工厂方法模式;
- 抽象工程模式;
- 原型模式;
- 建造者模式。
4.1、单例设计模式
单例模式(Singleton pattern)是Java中最简单的设计模式之一,这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建。这个类提供了一种访问其唯一对象的方式,可以直接访问,不需要实例化该类的对象。
4.1.1、单例模式的结构
单例模式的主要有以下角色:
- 单例类:只能创建一个实例的类;
- 访问类:使用单例类。
4.1.2、单例模式的实现
单例设计模式分类有两种:
- 饿汉式:类加载就会导致该单实例对象被创建;
- 懒汉式:类加载不会导致该单实例对象被创建,而是首次使用该对象时才会创建。
1、饿汉式——方式1(静态变量方式)
2、饿汉式——方式2(静态代码块)
3、懒汉式——方式1(线程不安全)
从上面代码我们可以看出该方式在成员位置声明Singleton类型的静态变量,并没有进行对象的赋值操作,那么什么时候赋值的呢?当调用getInstance()方法获取Singleton类的对象的时候才创建Singleton类的对象,这样就实现了懒加载的效果,但是,如果是多线程环境,会出现线程安全问题。
4、懒汉式——方式2(线程安全)
5、懒汉式——方式3(双重检查锁)
再来讨论一下懒汉模式中加锁的问题,对于getInstance()方法来说,绝大部分的操作都是读操作,读操作是线程安全的,所以我们没必要让每个线程必需持有锁才能调用该方法,我们需要调整枷锁的时机。由此也产生了一种新的实现模式:双重检查锁模式。
双重检查锁模式是一种非常好的单例实现模式,解决了单例、性能、线程安全问题,上面的双重检查锁看上去完美无缺,其实是存在问题,在多线程的情况下,可能会出现空指针问题,出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。要解决双重检查锁模式带来空指针异常的问题,只需要使用volatile关键字,volatile关键字可以保证可见性和有序性。
6、懒汉式——方式4(静态内部类方式)
静态内部类单例模式中实例由内部类创建,由于JVM在加载外部类的过程中,是不会加载静态内部类的,只有内部类的属性/方法被调用时才会被加载,并初始化其静态属性。静态属性由于被static修饰,保证只被实例化一次,并且严格保证实例化顺序。
说明:第一次加载Singleton类时不会去初始化INSTANCE,只有第一次调用getInstance(),虚拟机加载SingletonHolder并初始化INSTANCE,这样不仅能确保线程安全,也能保证Singleton类的唯一性。
静态内部类单例模式是一种优秀的单例模式,是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下,保证了多线程下的安全,并且没有任何性能影响和空间的浪费。
7、枚举方式
枚举类实现单例模式是极力推荐的单例实现模式,因为枚举类型是线程安全的,并且只会装载一次,设计者充分地利用了枚举的这个特性来实现单例模式,枚举的写法非常简单,而且枚举类型是所有单例实现中唯一一种不会被破坏的单例实现模式。
注意:枚举方式属于饿汉式方式。
4.1.3、存在的问题——破坏单例模式
1、问题演示
破坏单例模式:使上面定义的单例类(Singleton)可以创建多个对象,枚举方式除外。有两种方式,分别是序列化和反射。
(1)、序列化和反序列化
(2)、反射破坏单例模式
2、问题的解决
(1)、序列化、反序列化方式破坏单例模式的解决方法
在Singleton类中添加readResolve()方法,在反序列化时被反射调用,如果定义了这个方法,就返回这个方法的值,如果没有定义,则返回新new出来的对象。
(2)、反射方式破解单例模式的解决方法
4.2、工厂方法模式
4.2.1、概述
需求:设计一个咖啡店点餐系统。
设计一个咖啡类(Coffee),并定义其两个子类(美式咖啡(AmericanCoffee)和拿铁咖啡(LatteCoffee)),再设计一个咖啡店类(CoffeeStore),咖啡店具有点咖啡的功能。
在Java中,万物皆对象,这些对象需要创建,如果创建的时候直接new对象,就会对该对象耦合严重,假如我们要更换对象,所有new对象的地方都需要修改一遍,这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象,我们就只和工厂打交道就可以了,彻底和对象解耦,如果要更换对象,直接在工厂里更换该对象即可,达到了与对象解耦的目的;所以说,工厂模式最大的优点就是:解耦。
4.2.2、简单工厂模式
简单工厂模式不是一种设计模式,反而比较像是一种编程习惯。
1、结构
简单工厂包含如下角色:
- 抽象产品:定义了产品的规范,描述了产品的主要特性和功能。
- 具体产品:实现或者继承抽象产品的子类。
- 具体工厂:提供了创建产品的方法,调用者通过该方法来创建产品。
2、实现
工厂(Factory)处理创建对象的细节,一旦有了SimpleCoffeeFactory,CoffeeStore类中的orderCoffee()就变成此对象的客户,后期如果需要Coffee对象直接从工厂中获取即可,这样也就解除了Coffee实现类的耦合,同时又产生了新的耦合,CoffeeStore对象和SimpleCoffeeFactory工厂对象的耦合,工厂对象和商品对象的耦合。
后期如果再添加新种类的咖啡,我们势必要修改SimpleCoffeeFactory的代码,违反了开闭原则。工厂类的客户端可能有很多,比如创建美团外卖等,这样只需要修改工厂类的代码,省去其他的修改操作。
3、优缺点
优点:封装了创建对象的过程,可以通过参数直接获取对象。把对象的创建和业务逻辑层分开,这样以后就避免了修改客户代码,如果要实现新产品直接修改工厂类,而不需要在原代码中修改,这样就降低了客户代码修改的可能性,更加容易扩展。
缺点:增加新产品时还是要修改工厂类的代码,违背了“开闭原则”。
4、扩展
静态工厂:在开发中也有一部分人将工厂类中的创建对象的功能定义为静态的,这个就是静态工厂模式,它也不是23种设计模式中的。代码如下:
4.2.3、工厂方法模式
针对上例中的缺点,使用工厂方法模式就可以完美地解决,完全遵循开闭原则。
1、概念
定义一个用于创建对象的接口,让子类决定实例化哪个产品类对象,工厂方法使一个产品类的实例化延迟到其工厂的子类。
2、结构
工厂方法模式的主要角色:
- 抽象工厂(Abstract Factory):提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法来创建产品;
- 具体工厂(ConcreteFactory):主要是实现抽象工厂中的抽象方法,完成具体产品的创建;
- 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能。
- 具体产品(ConcretProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应。
3、实现
4、优缺点
- 优点:用户只需要知道具体工厂的名称就可得到新产品,无需知道产品的具体创建过程;在系统增加新的产品时只需要添加具体产品类和具体工厂类,无需对原工厂进行任何修改,满足开闭原则。
- 缺点:每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,这增加了系统的复杂度。
4.2.4、抽象工厂模式
前面介绍的工厂方法模式中考虑的是一类产品的生产,如:畜牧场只养动物,电视机厂只生产电视机等。
这些工厂只生产同种类产品,同种类产品成为同等级产品,也就是说:工厂方法模式只考虑生产同等级的产品,但是在现实生活中许多工厂是综合型的工厂,能生产多等级(种类)的产品,如电器厂既生产电视机又生产洗衣机或空调,大学既有软件专业又有生物专业等。
1、概念
是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无需指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。
2、结构
抽象工厂模式的主要角色如下:
- 抽象工厂(Abstract Factory):提供了创建产品的接口,它包含多个创建产品的方法,可以创建多个不同等级的产品;
- 具体工厂(Concrete Factory):主要是实现抽象工厂的多个抽象方法,完成具体产品的创建;
- 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能,抽象工厂模式有多个抽象产品;
- 具体产品(Concrete Product):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间是多对一的关系。
3、实现
如果要加同一个产品族的话,只需要再加一个对应的工厂类即可,不需要修改其他的类。
4、优缺点
优点:当一个产品族中的多个对象被设计在一起工作时,它能保证客户端始终同一个产品族中的对象;
缺点:当产品族中需要增加一个新的产品时,所有的工厂类都需要进行修改。
5、使用场景
- 当需要创建的对象是一系列相互关联或相互依赖的产品族时,如电器工厂中的电视机、洗衣机、空调等;
- 系统中有多个产品族,但每次只使用其中的某一族产品。如有人只喜欢某一个品牌的衣服和鞋;
- 系统中提供了产品的类库,且所有产品的接口相同,客户端不依赖产品实例的创建细节和内部结构。
如:输入法换皮肤,一整套一起换。生成不同操作系统的程序。
4.2.5、模式扩展
简单工厂 + 配置文件解除耦合。
可以通过工厂模式 + 配置文件的方式解除工厂对象和产品对象的耦合。在工厂类中加载配置文件的全类名,并创建对象进行存储,客户端如果需要对象,直接进行获取即可。
步骤:
- 定义配置文件:
- 改进工厂类:
4.2.6、JDK源码解析-Collection.iterator()方法
上面的代码使用迭代器遍历集合,获取集合中的元素。而单列集合获取迭代器的方法就使用到了工厂方法模式。类图结构如下:
Colletction接口是抽象工厂类,ArrayList是具体的工厂类;Iterator接口是抽象商品类,ArrayList类中的Iter内部类是具体的商品类,在具体的工厂中iterator()方法创建具体的商品类的对象。
另:
- DateFormat类中的getInstance()方法使用的是工厂模式;
- Calendar类中的getInstance()方法使用的是工厂模式。
4.3、原型模式
4.3.1、概述
用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型对象相同的新对象。
4.3.2、结构
原型模式包含如下角色:
- 抽象原型类:规定了具体原型对象必须实现的clone()方法;
- 具体原型类:实现抽象原型类的clone()方法,它是可被复制的对象;
- 访问类:使用具体原型类中的clone()方法来复制新的对象。
接口类图如下:
4.3.3、实现
原型模式的克隆分为浅克隆和深克隆。
- 浅克隆:创建一个新对象,新对象的属性和原来的对象完全相同,对于非基本类型属性,仍指向原有属性所指向的对象的内存地址。
- 深克隆:创建一个新对象,属性中引用的其他对象也会被克隆,不再指向原有对象地址。
Java中的Object类中提供了clone()方法来实现浅克隆,Cloneable接口是上面的类图中的抽象原型类,而实现了Cloneable接口的子实现类就是具体的原型类。代码如下:
// 具体的原型类
class Realizetype implements Cloneable {
public Realizetype() {
System.out.println("具体的原型对象创建完成!");
}
@Override
protected Realizetype clone() throws CloneNotSupportedException {
System.out.println("具体原型复制成功!");
return (Realizetype) super.clone();
}
}
// 测试访问类
public class Test1 {
public static void main(String[] args) throws CloneNotSupportedException {
// 创建一个原型类对象
Realizetype r1 = new Realizetype();
// 调用Realizetype类中的clone()方法进行对象的克隆
Realizetype r2 = r1.clone();
System.out.println("原型对象和克隆出来的是否是同一个对象?" + (r1 == r2));
}
}
// 结果
具体的原型对象创建完成!
具体原型复制成功!
原型对象和克隆出来的是否是同一个对象?false
4.3.4、案例
用原型模式生成“三好学生”奖状。
同一学校的“三好学生”奖状除了获奖人姓名不同,其他都相同,可以使用原型模式复制多个“三好学生”奖状出来,然后再修改奖状上的名字即可。
类图如下:
代码如下:
// 奖状类
class Citation implements Cloneable {
private String name; // 注意,String为不可变类
public void setName(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
public void show() {
System.out.println(name + "同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!");
}
@Override
protected Citation clone() throws CloneNotSupportedException {
return (Citation) super.clone();
}
}
public class Test2 {
public static void main(String[] args) throws CloneNotSupportedException {
// 1、创建原型对象
Citation c1 = new Citation();
// 2、克隆奖状对象
Citation c2 = c1.clone();
c1.setName("张三");
c2.setName("李四");
c1.show();
c2.show();
}
}
结果;
张三同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!
李四同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!
4.3.5、使用场景
对象的创建非常复杂,可以使用原型模式快捷地创建对象。
性能和安全要求比较高。
4.3.6、扩展(深克隆)
将上面的“三好学生”奖状的案例中Citation类的name属性修改为Student类型的属性,代码如下:
// 学生类
class Student {
private String name; // 学生姓名
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@Override
public String toString() {
return "Student{" +
"name='" + name + '\'' +
'}';
}
}
// 奖状类
class Citation implements Cloneable {
private Student stu;
public void setStu(Student stu) {
this.stu = stu;
}
public Student getStu() {
return stu;
}
public void show() {
System.out.println(stu.getName() + "同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!");
}
@Override
protected Citation clone() throws CloneNotSupportedException {
return (Citation) super.clone();
}
}
public class Test2 {
public static void main(String[] args) throws CloneNotSupportedException {
// 1、创建原型对象
Citation c1 = new Citation();
Student stu = new Student(); stu.setName("张三");
c1.setStu(stu);
// 2、克隆奖状对象
Citation c2 = c1.clone();
c2.getStu().setName("李四");
c1.show();
c2.show();
}
}
结果:
李四同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!
李四同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!
说明:c1的stu对象和c2的stu对象是同一个对象,就会产生将c2.stu对象中name属性值改为“李四”,两个Citation(奖状)对象中显示的都是李四的现象。这就是浅克隆的效果,对具体原型类(Citation)中的引用类型的属性进行引用的复制。这种情况需要使用深克隆,而进行深克隆需要使用对象流。代码如下:
// 学生类(对象序列化要求实现序列化接口Serializable接口)
class Student implements Serializable {
private String name; // 学生姓名
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@Override
public String toString() {
return "Student{" +
"name='" + name + '\'' +
'}';
}
}
// 奖状类(对象序列化要求实现序列化接口Serializable接口)
class Citation implements Cloneable, Serializable {
private Student stu;
public void setStu(Student stu) {
this.stu = stu;
}
public Student getStu() {
return stu;
}
public void show() {
System.out.println(stu.getName() + "同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!");
}
@Override
protected Citation clone() throws CloneNotSupportedException {
return (Citation) super.clone();
}
}
public class Test2 {
public static void main(String[] args) throws CloneNotSupportedException, IOException, ClassNotFoundException {
// 1、创建原型对象
Citation c1 = new Citation();
Student stu1 = new Student(); stu1.setName("张三");
c1.setStu(stu1);
// 创建对象输出流对象
ObjectOutputStream ooStream = new ObjectOutputStream(new FileOutputStream("C:\\Users\\Administrator\\Desktop\\a.txt"));
// 将c1对象写到文件中
ooStream.writeObject(c1);
ooStream.close();
// 创建对象输入流对象
ObjectInputStream oiStream = new ObjectInputStream(new FileInputStream("C:\\Users\\Administrator\\Desktop\\a.txt"));
// 读取对象
Citation c2 = (Citation) oiStream.readObject();
oiStream.close();
// 获取c2奖状所属学生对象
Student stu2 = c2.getStu(); stu2.setName("李四");
c1.show();
c2.show();
}
}
结果:
张三同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!
李四同学,在2020学年第一学期中表现优秀,被评为三好学生,特发此状!
4.4、建造者模式
4.4.1、概述
- 将一个复杂对象的构件与表示分离,使得同样的构件过程可以创建不同的表示。
- 分离了部件的构造(由Builder来负责)和装配(由Director负责)。从而可以构造出复杂的对象。这个模式适用于:某个对象的构件过程复杂的情况。
- 由于实现了构建和装配的解耦。不同的构建器,相同的装配,也可以做出不同的对象;相同的构建器,不同的装配顺序可以做出不同的对象。也就是实现了构建算法、装配算法的解耦,实现了更好的复用。
- 建造者模式可以将部件和其组装过程分开,一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象,而无需知道其内部的具体构造细节。
4.4.2、结构
建造者(Builer)模式包含如下角色:
- 抽象建造者类(Builder):这个接口规定要实现复杂对象的那部分的创建,并不涉及具体的对象部件的创建。
- 具体建造者类(ConcreteBuilder):实现Builder接口,完成复杂产品的各个部件的具体创建方法。在构造过程完成后,提供产品的实例。
- 产品类(Product):要创建的复杂对象。
- 指挥者类(Director):调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
类图如下:
4.4.3、案例
创建共享单车。
生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。而车架又有碳纤维,铝合金等材质的,车座有橡胶,真皮等材质。对于自行车的生产就可以使用建造者模式。
这里Bike是产品,包含车架,车座等组件;Builder是抽象建造者,MobikeBuilder和OfoBuilder是具体的建造者;Director是指挥者,类图如下:
具体的代码如下:
// 产品对象:自行车
class Bike {
private String frame; // 车架
private String seat; // 车座
public String getFrame() {
return frame;
}
public void setFrame(String frame) {
this.frame = frame;
}
public String getSeat() {
return seat;
}
public void setSeat(String seat) {
this.seat = seat;
}
}
// 抽象的构建者
abstract class Builder {
// 声明Bike类型的变量并赋值
protected Bike bike = new Bike();
public abstract void buildFrame();
public abstract void buildSeat();
// 构建自行车的方法
public abstract Bike createBike();
}
// 具体的构建者,用来构建摩拜单车对象
class MobikeBuilder extends Builder {
@Override
public void buildFrame() {
bike.setFrame("碳纤维车架");
}
@Override
public void buildSeat() {
bike.setSeat("真皮车座");
}
@Override
public Bike createBike() {
return bike;
}
}
// 具体的构建者,用来构建Ofo单车对象
class OfoBuilder extends Builder {
@Override
public void buildFrame() {
bike.setFrame("铝合金车架");
}
@Override
public void buildSeat() {
bike.setSeat("橡胶车座");
}
@Override
public Bike createBike() {
return bike;
}
}
// 指挥者类
class Director {
// 声明Builder类型的变量
private Builder builder;
public Director(Builder builder) {
this.builder = builder;
}
// 组装自行车的功能
public Bike construct() {
builder.buildFrame();
builder.buildSeat();
return builder.createBike();
}
}
public class Client {
public static void main(String[] args) {
// 创建指挥者对象
Director director = new Director(new MobikeBuilder());
// 指挥者指挥组装自行车
Bike bike = director.construct();
System.out.println(bike.getFrame());
System.out.println(bike.getSeat());
}
}
结果:
碳纤维车架
真皮车座
注意:上面示例是Builder模式的常规用法,指挥者类Director在建造者模式中具有很重要的作用,它用于指导具体构造者如何构建产品,控制调用先后次序,并向调用者返回完整的产品类,但是有些情况需要简化系统结构,可以把指挥者类和抽象建造者进行结合:
// 抽象的构建者
abstract class Builder {
// 声明Bike类型的变量并赋值
protected Bike bike = new Bike();
public abstract void buildFrame();
public abstract void buildSeat();
// 构建自行车的方法
public abstract Bike createBike();
public Bike construct() {
this.buildFrame();
this.buildSeat();
return this.createBike();
}
}
说明:这样做确实简化了系统结构,但同时也加重了抽象建造者类的职责,也不是太符合单一职责原则,如果construct()过于复杂,建议还是封装到Director中。
4.4.4、优缺点
优点:
- 建造者模式的封装性很好,使用建造者模式可以有效地封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性;
- 在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象;
- 可以更加精细地控制产品的创建过程,将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也方便使用程序来控制创建过程。
- 建造者模式很容易进行扩展,如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险,符合开闭原则。
缺点:
- 建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
4.4.5、使用场景
建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用:
创建的对象较复杂,由多个部件构成,各部件面临巨大的变化,但构件间的构造顺序是稳定的;
创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的。
4.4.6、模式扩展
建造者模式除了上面的用途外,在开发中还有一个常用的使用方式,就是当一个类构造器需要传入很多参数时,如果创建这个类的实例,代码可读性会非常差,而且很容易引入错误,此时就可以利用建造者模式进行重构。
重构前代码如下:
// 重构前
class Phone {
private String cpu;
private String screen;
private String memory;
private String mainBoard;
public Phone(String cpu, String screen, String memory, String mainBoard) {
this.cpu = cpu;
this.screen = screen;
this.memory = memory;
this.mainBoard = mainBoard;
}
public String getCpu() {
return cpu;
}
public void setCpu(String cpu) {
this.cpu = cpu;
}
public String getScreen() {
return screen;
}
public void setScreen(String screen) {
this.screen = screen;
}
public String getMemory() {
return memory;
}
public void setMemory(String memory) {
this.memory = memory;
}
public String getMainBoard() {
return mainBoard;
}
public void setMainBoard(String mainBoard) {
this.mainBoard = mainBoard;
}
@Override
public String toString() {
return "Phone{" +
"cpu='" + cpu + '\'' +
", screen='" + screen + '\'' +
", memory='" + memory + '\'' +
", mainBoard='" + mainBoard + '\'' +
'}';
}
}
public class Test3 {
public static void main(String[] args) {
// 创建 Phone 对象
Phone phone = new Phone("intel", "三星屏幕", "金士顿", "华硕");
}
}
使用建造者模式重构后:
// 重构后
class Phone {
private String cpu;
private String screen;
private String memory;
private String mainBoard;
// 私有构造方法
private Phone(Builder builder) {
this.cpu = builder.cpu;
this.screen = builder.screen;
this.memory = builder.memory;
this.mainBoard = builder.mainBoard;
}
@Override
public String toString() {
return "Phone{" +
"cpu='" + cpu + '\'' +
", screen='" + screen + '\'' +
", memory='" + memory + '\'' +
", mainBoard='" + mainBoard + '\'' +
'}';
}
public static final class Builder {
private String cpu;
private String screen;
private String memory;
private String mainBoard;
public Builder cpu(String cpu) {
this.cpu = cpu;
return this;
}
public Builder screen(String screen) {
this.screen = screen;
return this;
}
public Builder memory(String memory) {
this.memory = memory;
return this;
}
public Builder mainBoard(String mainBoard) {
this.mainBoard = mainBoard;
return this;
}
// 使用构建者创建phone对象
public Phone build() {
return new Phone(this);
}
}
}
public class Test3 {
public static void main(String[] args) {
// 创建 Phone 对象
Phone phone = new Phone.Builder()
.cpu("intel").screen("三星屏幕").memory("金士顿内存条").mainBoard("华硕")
.build();
System.out.println(phone);
}
}
结果:
Phone{cpu='intel', screen='三星屏幕', memory='金士顿内存条', mainBoard='华硕'}
4.5、创建者模式对比
4.5.1、工厂方法模式 vs 建造者模式
工厂方法模式注重的是整体对象的创建方式;而建造者模式注重的是部件构建的过程,意在通过一步一步地精确构造创建出一个复杂的对象。
比如说,如果要制造一个超人,如果使用工厂方法模式,直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人;而如果使用建造者模式,则需要组装手、头、脚、躯干等部分,然后再把内裤外穿,于是一个超人就诞生了。
4.5.2、抽象工厂模式 vs 建造者模式
抽象工厂模式实现对产品家族的创建,一个产品家族是这样的一系列产品:具有不同分类维度的产品组合,采用抽象工厂模式则是不需要关心构建过程,只关心什么产品由什么工厂生产即可。
建造者模式则是要求按照指定的蓝图建造产品,它的主要目的是通过组装零配件而产生一个新产品。
如果将抽象工厂模式看成汽车配件生产工厂,生产一个产品族的产品,那么建造者模式就是一个汽车组装工厂,通过对部件的组装可以返回一辆完整的汽车。