设计模式之创建型模式:将对象的创建与使用分离
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是“将对象的创建与使用分离”。
这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。
创建型模式分为:
- 单例模式
- 工厂方法模式
- 抽象工厂模式
- 原型模式
- 建造者模式
单例模式
概念
单例模式(Singleton Pattern)是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式,可以直接访问,不需要实例化该类的对象。
结构
单例模式的主要有以下角色:
- 单例类:只能创建一个实例的类
- 访问类:使用单例类
饿汉式:类加载就会导致该单实例对象被创建
懒汉式:类加载不会导致该单实例对象被创建,而是首次使用该对象时才会创建
实现
饿汉式
类加载就会导致该单实例对象被创建
饿汉式 实现方式:静态变量创建类的对象
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17/**
* 静态变量创建类的对象
* @author Ether
*/
public class EagerlyInitializedSingleton {
// 私有构造方法
private EagerlyInitializedSingleton(){}
// 在本类中创建本类对象
private static EagerlyInitializedSingleton instance = new EagerlyInitializedSingleton();
// 提供一个公共访问方式,让外界获取该对象
public static EagerlyInitializedSingleton getInstance(){
return instance;
}
}饿汉式 实现方式:枚举类
1
2
3
4
5
6
7
8/**
* 饿汉式
* 枚举类 线程安全(极力推荐)
* @author Ether
*/
public enum EnumSingleton {
INSTANCE;
}
懒汉式
类加载不会导致该单实例对象被创建,而是首次使用该对象时才会创建
方式一:线程不安全
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24/**
* 懒汉式
* 线程不安全
* @author Ether
*/
public class LazilyInitializedSingleton {
// 私有构造方法
private LazilyInitializedSingleton(){}
// 声明本类对象
private static LazilyInitializedSingleton instance;
// 提供静态方法获取并创建对象
//
public static LazilyInitializedSingleton getInstance(){
// 判断instance是否为空,为空则说明还没有创建该类的对象
if(instance == null){
// 若线程1进来后等待,CPU执行权给线程2,则线程2也会进入并创建不同的对象实例
instance = new LazilyInitializedSingleton();
}
return instance;
}
}方式二:线程安全
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21/**
* 懒汉式
* 线程安全
* @author Ether
*/
public class ThreadSafeLazyLoadedSingleton {
// 私有构造方法
private ThreadSafeLazyLoadedSingleton(){}
// 声明本类对象
private static ThreadSafeLazyLoadedSingleton instance;
public static synchronized ThreadSafeLazyLoadedSingleton getInstance(){
// 判断instance是否为空,为空则说明还没有创建该类的对象
if(instance == null){
instance = new ThreadSafeLazyLoadedSingleton();
}
return instance;
}
}方式三:双重检查锁
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26/**
* 双重检查锁
* 线程安全 多线程情况下可能会出现空指针问题,需要使用volatile
* @author Ether
*/
public class ThreadSafeDoubleCheckLockSingleton {
//私有构造方法
private ThreadSafeDoubleCheckLockSingleton(){}
// 声明当前类的变量
private static ThreadSafeDoubleCheckLockSingleton instance;
// 对外提供公共访问方式
public static ThreadSafeDoubleCheckLockSingleton getInstance(){
//
if (instance == null){
synchronized (ThreadSafeDoubleCheckLockSingleton.class){
if (instance == null) {
instance = new ThreadSafeDoubleCheckLockSingleton();
}
}
}
return instance;
}
}优点:在实例变量加上了volatile关键词修饰,保证可见性与有序性;双重判断加锁
静态内部类
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20/**
* 懒汉式
* 静态内部类 线程安全
* @author Ether
*/
public class InitializingOnDemandHolderIdiom {
//私有构造方法
private InitializingOnDemandHolderIdiom(){}
// 定义静态内部类
private static class SingletonHolder {
//保证被实例化一次
private static final InitializingOnDemandHolderIdiom INSTANCE = new InitializingOnDemandHolderIdiom();
}
// 提供外部访问方法
public static InitializingOnDemandHolderIdiom getInstance(){
return SingletonHolder.INSTANCE;
}
}静态内部类——解决反序列化破坏单例模式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24import java.io.Serializable;
/**
* 解决反序列化破坏单例模式
* @author Ether
*/
public class SolveDeserializableSingleton implements Serializable {
//私有构造
private SolveDeserializableSingleton(){}
// 静态内部类
private static class SingletonHolder{
private static final SolveDeserializableSingleton INSTANCE = new SolveDeserializableSingleton();
}
public static SolveDeserializableSingleton getInstance(){
return SingletonHolder.INSTANCE;
}
// 当进行反序列化时,会自动调用该方法,将该方法返回值直接返回
public Object readResolve(){
return SingletonHolder.INSTANCE;
}
}静态内部类——解决反射破坏单例模式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29/**
* 解决反射破坏单例模式
* @author Ether
*/
public class SolveReflectSingleton {
private static boolean flag = false;
// 私有构造方法
private SolveReflectSingleton(){
//多线程环境
synchronized (SolveReflectSingleton.class) {
// 判断flag值是否是true,为true则说明非第一次访问,为false则为第一次访问
if (flag) {
throw new RuntimeException("不能创建多个对象");
}
flag = true;
}
}
private static class SingletonHolder{
private static final SolveReflectSingleton INSTANCE = new SolveReflectSingleton();
}
public static SolveReflectSingleton getInstance(){
return SolveReflectSingleton.SingletonHolder.INSTANCE;
}
}
使用场景
java.lang.Runtime#getRuntime()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19public class Runtime {
private static Runtime currentRuntime = new Runtime();
/**
* Returns the runtime object associated with the current Java application.
* Most of the methods of class <code>Runtime</code> are instance
* methods and must be invoked with respect to the current runtime object.
*
* @return the <code>Runtime</code> object associated with the current
* Java application.
*/
public static Runtime getRuntime() {
return currentRuntime;
}
/** Don't let anyone else instantiate this class */
private Runtime() {}
...
}
工厂方法模式
概念
为创建一个对象定义一个接口,让子类决定实例化哪个类。
工厂方法允许类将实例化延迟到子类。
结构
工厂方法模式的主要角色:
- 抽象工厂(Abstract Factory):提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法来创建产品。
- 具体工厂(ConcreteFactory):主要是实现抽象工厂中的抽象方法,完成具体产品的创建。
- 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能。
- 具体产品(ConcreteProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应。
实现
抽象工厂
1 | /** |
具体工厂
1 | /** |
1 | /** |
抽象产品
1 | /** |
具体产品
1 | /** |
1 | /** |
测试类
1 | /** |
若需再添加产品种类,只需要添加一个新的咖啡工厂的子实现类和产品实体即可(符合开闭原则,对扩展开放,对修改关闭)
优缺点
优点
- 用户只需要知道具体工厂的名称就可得到所要的产品,无须知道产品的具体创建过程;
- 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类,无须对原工厂进行任何修改,满足开闭原则;
缺点
- 每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,这增加了系统的复杂度。
使用场景
Collection.iterator方法
Collection接口是抽象工厂类,ArrayList是具体的工厂类;Iterator接口是抽象商品类,ArrayList类中的Iter内部类是具体的商品类。在具体的工厂类中iterator()方法创建具体的商品类的对象。
抽象工厂模式
概念
是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。
抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品。
结构
抽象工厂模式的主要角色如下:
- 抽象工厂(Abstract Factory):提供了创建产品的接口,它包含多个创建产品的方法,可以创建多个不同等级的产品。
- 具体工厂(Concrete Factory):主要是实现抽象工厂中的多个抽象方法,完成具体产品的创建。
- 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能,抽象工厂模式有多个抽象产品。
- 具体产品(ConcreteProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它 同具体工厂之间是多对一的关系。
实现
抽象工厂
1 | /** |
具体工厂
1 | /** |
1 | /** |
抽象产品
1 | /** |
1 | /** |
具体产品
1 | /** |
1 | /** |
如果要加同一个产品族的话,只需要再加一个对应的工厂类即可,不需要修改其他的类。
优缺点
优点
当一个产品族中的多个对象被设计成一起工作时,它能保证客户端始终只使用同一个产品族中的对象。
缺点
当产品族中需要增加一个新的产品时,所有的工厂类都需要进行修改。
使用场景
当需要创建的对象是一系列相互关联或相互依赖的产品族时,如电器工厂中的电视机、洗衣机、空调等。
系统中有多个产品族,但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。
系统中提供了产品的类库,且所有产品的接口相同,客户端不依赖产品实例的创建细节和内部结构。
如:输入法换皮肤,一整套一起换。生成不同操作系统的程序。
原型模式
概念
用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型对象相同的新对象。
结构
原型模式包含如下角色:
- 抽象原型类:规定了具体原型对象必须实现的的 clone() 方法。
- 具体原型类:实现抽象原型类的 clone() 方法,它是可被复制的对象。
- 访问类:使用具体原型类中的 clone() 方法来复制新的对象。
浅拷贝实现
浅拷贝:创建一个新对象,新对象的属性和原来对象完全相同,对于非基本类型属性,仍指向原有属性所指向的对象的内存地址。
用原型模式生成“三好学生”奖状
同一学校的“三好学生”奖状除了获奖人姓名不同,其他都相同,可以使用原型模式复制多个“三好学生”奖状出来,然后在修改奖状上的名字即可。
原型实体类
1 | /** |
测试
1 | /** |
原型实体类
1 | /** |
测试
1 | /** |
深拷贝实现
深拷贝:创建一个新对象,属性中引用的其他对象也会被克隆,不再指向原有对象地址。
原型实体类
1 | import java.io.*; |
学生类
1 | import java.io.Serializable; |
测试
1 | /** |
使用场景
- 对象的创建非常复杂,可以使用原型模式快捷的创建对象。
- 性能和安全要求比较高。
建造者模式
概念
将一个复杂对象的构建与表示分离,使得同样的构建过程可以创建不同的表示。
- 分离了部件的构造(由Builder来负责)和装配(由Director负责)。 从而可以构造出复杂的对象。这个模式适用于:某个对象的构建过程复杂的情况。
- 由于实现了构建和装配的解耦。不同的构建器,相同的装配,也可以做出不同的对象;相同的构建器,不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦,实现了更好的复用。
- 建造者模式可以将部件和其组装过程分开,一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象,而无须知道其内部的具体构造细节。
结构
建造者(Builder)模式包含如下角色:
抽象建造者类(Builder):这个接口规定要实现复杂对象的那些部分的创建,并不涉及具体的部件对象的创建。
具体建造者类(ConcreteBuilder):实现 Builder 接口,完成复杂产品的各个部件的具体创建方法。在构造过程完成后,提供产品的实例。
产品类(Product):要创建的复杂对象。
指挥者类(Director):调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
类图如下:
实现
生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。而车架又有碳纤维,铝合金等材质的,车座有橡胶,真皮等材质。对于自行车的生产就可以使用建造者模式。
这里Bike是产品,包含车架,车座等组件;Builder是抽象建造者,MobikeBuilder和OfoBuilder是具体的建造者;Director是指挥者。类图如下:
抽象构建者
1 | /** |
具体构建者
1 | /** |
1 | /** |
产品类
1 | import lombok.Data; |
指挥者类
1 | /** |
测试
1 | /** |
优缺点
优点
- 建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
- 在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
- 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
- 建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。符合开闭原则。
缺点
建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
使用场景
建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用。
- 创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的建造顺序是稳定的。
- 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的。
模式拓展(常用)
建造者模式除了上面的用途外,在开发中还有一个常用的使用方式,就是当一个类构造器需要传入很多参数时,如果创建这个类的实例,代码可读性会非常差,而且很容易引入错误,此时就可以利用建造者模式进行重构。
1 | /** |
实现链式调用,使用起来更方便
测试
1 | /** |
创建者模式对比
工厂方法模式VS建造者模式
工厂方法模式注重的是整体对象的创建方式;而建造者模式注重的是部件构建的过程,意在通过一步一步地精确构造创建出一个复杂的对象。
我们举个简单例子来说明两者的差异,如要制造一个超人,如果使用工厂方法模式,直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人;而如果使用建造者模式,则需要组装手、头、脚、躯干等部分,然后再把内裤外穿,于是一个超人就诞生了。
抽象工厂模式VS建造者模式
抽象工厂模式实现对产品家族的创建,一个产品家族是这样的一系列产品:具有不同分类维度的产品组合,采用抽象工厂模式则是不需要关心构建过程,只关心什么产品由什么工厂生产即可。
建造者模式则是要求按照指定的蓝图建造产品,它的主要目的是通过组装零配件而产生一个新产品。
如果将抽象工厂模式看成汽车配件生产工厂,生产一个产品族的产品,那么建造者模式就是一个汽车组装工厂,通过对部件的组装可以返回一辆完整的汽车。
- 感谢你赐予我前进的力量