创建者模式
主要关注点是“怎样创建对象”,它的主要特点是“将对象的创建与使用分离”。
这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。
创建型模式分为:
- 单例模式
- 工厂方法模式
- 抽象工厂模式
- 原型模式
- 建造者模式
文章目录
一、单例模式
单例模式是java中最简单的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式,可以直接访问,不需要实例化该类的对象
单例设计模式分类两种:
- 饿汉式:类加载就会导致该单实例对象被创建
- 懒汉式:类加载不会导致该单实例对象被创建,而是首次使用该对象时才会创建
1、饿汉式:静态成员变量
public class Singleton {
//构造器私有
private Singleton(){}
//在本类中创建本类对象
private static Singleton singleton=new Singleton();
//提供一个公共的方式访问,让外界获取该对象
public static Singleton getInstance(){
return singleton;
}
}
2、饿汉式:静态代码块
public class Singleton {
//构造器私有
private Singleton() {
}
//声明Singleton类型的变量
private static Singleton singleton;
//在静态代码中进行赋值
static {
singleton = new Singleton();
}
//提供一个公共的方式访问,让外界获取该对象
public static Singleton getInstance() {
return singleton;
}
}
饿汉式在成员位置声明Singleton类型的静态变量,而对象的创建是在静态代码块中,也是对着类的加载而创建。饿汉式存在内存浪费问题
3、懒汉式:线程安全
public class Singleton {
//构造器私有
private Singleton() {
}
//声明Singleton类型的变量
private static Singleton singleton;
//提供一个公共的方式访问,让外界获取该对象
public static synchronized Singleton getInstance() {
//判断singleton是否为null,如果为null,说明还没有创建singleton类的对象
//如果没有,创建一个并返回,如果有,直接返回
if (singleton == null) {
singleton = new Singleton();
}
return singleton;
}
}
懒汉式加锁问题,对于getInstance()方法来说,绝大部分的操作都是读操作,读操作是线程安全的,所以没必要让每个线程必须持有锁才能调用该方法,我们需要调整加锁的时机。由此也产生了一种新的实现模式;双重检查锁模式
4、懒汉式:双重检查锁模式
public class Singleton {
//构造器私有
private Singleton() {
}
//声明Singleton类型的变量
private static Singleton singleton;
//提供一个公共的方式访问,让外界获取该对象
public static Singleton getInstance() {
//第一次判断,如果singleton的值不为null,不需要抢占锁,直接返回对象
if (singleton == null) {
synchronized (Singleton.class) {
//第二次判断
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
双重检查锁模式是一种非常好的单例实现模式,解决了单例、性能、线程安全问题,上面的双重检查锁模式看上去完美无缺,其实是存在问题,在多线程的情况下,可能会出现空指针问题,出现问题的原因是jvm在实例化对象的时候会进行优化和指令重排操作。要解决双重检查锁模式带来的空指针异常的问题。只需要使用volatile关键字,volatile关键字可以保证可见性和有序性。
5、懒汉式:volatile
public class Singleton {
//构造器私有
private Singleton() {
}
//声明Singleton类型的变量
private static volatile Singleton singleton;
//提供一个公共的方式访问,让外界获取该对象
public static Singleton getInstance() {
//第一次判断,如果singleton的值不为null,不需要抢占锁,直接返回对象
if (singleton == null) {
synchronized (Singleton.class) {
//第二次判断
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
添加volatile关键字之后的双重检查锁模式是一种比较好的单例实现模式,能够保证在多线程的情况下线程安全也不会有性能问题。
六、懒汉式:静态内部类
静态内部类单例模式中实例由内部类创建,由于jvm在加载外部类的过程中,是不会加载静态内部类的,只有内部类的属性/方法被调用时才会被加载,并初始化其静态属性。静态属性由于被static修饰,保证只被实例化一次,并且严格保证实例化顺序。
public class Singleton {
//构造器私有
private Singleton() {
}
//定义一个静态内部类
private static class SingletonHolder {
//在内部类中声明并初始化外部类的对象
private static final Singleton singleton = new Singleton();
}
//提供公共的访问方式
public static Singleton getInstance() {
return SingletonHolder.singleton;
}
}
静态内部类单例模式是一种优秀的单例模式,是开源项目中比较常用的一种单例模式。在没有任何锁的情况下,保证了多线程下的安全,并且没有任何性能影响和空间的浪费。
七、饿汉式:枚举方式
枚举类实现单例模式是极力推荐的单例实现模式,因为美剧类型是线程安全的,并且只会装载一次,设计者充分的利用了枚举的这个特性来实现单例模式,枚举的写法非常简单,而且枚举类型是所有单例实现中唯一一个不会被破坏的单例实现模式。
public enum Singleton {
INSTANCE;
}
二、工厂模式
需求:设计一个咖啡店点餐系统
设计一个咖啡类Coffee,并定义其两个子类美式咖啡AmericanCoffee和拿铁咖啡LatteCoffee;在设计一个咖啡点类coffeeSore,咖啡店具有咖啡的功能
代码实现
在java中,万物皆对象,这些对象都需要创建,如果创建的时候直接new该对象,就会对该对象耦合严重,加入我们要更换对象,所有new对象的地方都需修改一遍,这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象,我们就只和工厂打交道就可以了,彻底和对象解耦,如果要更换对象,直接在工厂里更换该对象即可,达到了对象解耦的目的;所以说,工厂模式最大的优点就是:解耦
1、简单工厂模式
简单工厂不是一种设计模式,反而比较像是一种编程习惯
简单工厂包含如下角色:
- 抽象产品:定义了产品的规范,描述了产品的主要特性和功能。
- 具体产品:实现或者继承抽象产品的子类
- 具体工厂:提供了创建产品的方法,调用者通过该方法来获取产品
工厂(factory)处理创建对象的细节,一旦有了SimpleCoffeeFactory,CoffeeStory类中的orderCoffee()就变成此对象的客户,后期如果需要Coffee对象直接从工厂中获取即可。这样也就解除了和Coffee实现类的耦合,同时又产生了新的耦合,CoffeeStory对象和SimpleCoffeeFactry工厂对象的耦合,工厂对象和产品对象的耦合。
后期如果再加新品种的咖啡,我们势必要修改SimpleCoffeeFactory的代码,违法了开闭原则。
2、静态工厂
在开发中也有一部分人将工厂类中的创建对象的功能定义为静态的,这个就是静态工厂模式,它也不是23中设计模式中的。
3、工厂方法模式
定义一个用于创建对象的接口,让子类决定实例化哪个产品类对象。工厂方法使一个产品类的实例化延迟到其工厂的子类。
工厂方法模式的主要角色:
- 抽象工厂:提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法来创建产品
- 具体工厂:主要实现抽象工厂中的抽象方法,完成具体产品的创建
- 抽象产品:定义了产品的规范,描述了产品的主要特性和功能
- 具体产品:实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应
从以上的编写的代码可以看到,要增加产品类时也要相应地增加工厂类,不需要修改工厂类的代码了,这样就解决了简单工厂模式的缺点
工厂方法模式是简单工厂模式的进一步抽象,由于使用了多态性,工厂方法模式保持了简单工厂模式的优点,而且克服了它的缺点
优点:只需要知道具体工厂的名称就可以得到所要的产品,无需知道产品的具体创建过程;在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类,无须对原工厂进行任何修改,满足开闭原则
缺点:每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,这增加了系统的复杂度
4、抽象工厂模式
是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构
抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品
抽象工厂模式的主要角色如下:
- 抽象工厂:提供了创建产品的接口,它包含多个创建产品的方法,可以创建多个不同等级的产品
- 具体工厂:主要是实现抽象工厂中的多个抽象方法,完成具体产品的创建
- 抽象产品:定义了产品的规范,描述了产品的主要特征和功能,抽象工厂模式有多个抽象产品
- 具体产品:实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间是多对一关系。
如果添加同一产品族的话,只需要再加一个对应的工厂类即可,不需要修改其他的类
优点:当一个产品族中的多个对象被设计成一起工作时,它能保证客户端始终只使用同一个产品族中的对象
缺点:当产品族中需要增加一个新的产品时,所有的工厂类都需要进行修改
JDK源码解析-Collection.iterator
Collection接口是抽象工厂类,ArrayList是具体的工厂类;Iterator接口时抽象产品类,ArrayList类中的Itr内部类是具体的产品类。
三、原型模式
用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型对象相同的新对象
原型对象包含如下角色:
- 抽象原型类:规定了具体原型对象必须实现的clone()方法。
- 具体原型类:实现抽象原型类的clone()方法,它是可被复制的对象
- 访问类:使用具体原型类的clone()方法来复制新的对象
原型模式的克隆分为浅克隆和深克隆
- 浅克隆:创建一个新对象,新对象的属性和原来对象完全相同,对于非基本类型属性,仍指向原有属性所指向的对象的内存地址。
- 深克隆:创建一个新对象,属性中引用的其他对象也会被克隆,不在指向原有对象地址
java中的Object类中提供了clone()方法来实现浅克隆。Cloneabnle接口是上面类图中的抽象原型类。而实现了Cloneable接口的子实现类就是具体的原型类
案例
在同一学校的"三好学校"奖状除了获奖人姓名不同,其他都相同,可以使用原型模式复制多个“三好学生”奖状出来,然后在修改奖状上的名字即可。
使用场景
- 对象的创建非常复杂,可以使用原型模式快捷的创建对象
- 性能和安全要求比较高
深克隆
说明:
stu对象和stu1对象是同一个对象,就会产生将stu1对象中name属性值改为嘉文,两个Citation对象中显示的都是嘉文。这就是浅克隆的效果,对具体原型类中的引用类型的属性进行引用的复。这种情况需要深克隆,而进行深克隆需要使用对象流
四、建造者模式
概述:
将一个复杂对象的构建与表示分离,使得同样的构建过程可以创建不同的表示
- 分了部件的构造(由Builder来负责)和装配(由Director负责)。从而可以构造出复杂的对象。这个模式适用于:某个对象的构建过程复杂的情况。
- 由于实现了构建和装配的解耦。不同的构建器,相同的装配,也可以做出不同的对象;相同的构建器,不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦,实现了更好的复用。
- 建造者模式可以将部件和其组装过程分开,一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象,而无须知道其内部的具体构造细节
建造者模式包含如下角色:
- 抽象建造者(Builder):这个接口规定要实现复杂对象的那些部分的创建,并不涉及具体的部件对象的创建。
- 具体建造者类(ConcreteBuilder):实现Builder接口,完成复杂产品的各个部件的创建方法。在构造过程完成后,提供产品的实例。
- 产品类(Product):要创建的复杂对象。
- 指挥者类(Director):调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
实例
生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。而车架又有碳纤维,铝合金等材质,车座有橡胶,真皮等材质。对于自行车的生产就可以使用建造者模式。
这里Bike是产品,包含车架,车座等组件;Builder是抽象建造者,MobikeBuilder和ofoBuilder是具体的建造者;Director是指挥者。类图如下:
注意:
上面示例是Builder模式的常规用法,指挥者类Director在建造者模式中具有很重要的作用,它用于指导具体构建者如何构建产品,控制调用先后次序,并向调用者返回完整的产品类,但是有些情况下需要简化系统结构,可以把指挥者类和抽象类进行结合
说明:
这样做确实简化了系统结构,但同时也加重了抽象建造者类的职责,也不是太符合单一职责原则,如果construct()过于复杂,建议还是封装到Director中。
优缺点
优点:
-
建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
-
在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
-
可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程
-
建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。符合开闭原则
缺点
建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性较大,则不适合使用建造者模式,因此其使用范围受到一定的限制
模式扩展
建造者模式除了上面的用途外,在开发中还有一个常用的使用方式,就是当一个类构造器需要传入很多参数时,如果创建这个类的实例,代码可读性会非常差,而且很容易引入错误,此时就可以利用建造者模式进行重构
重构前代码如下:
重构后
@Data
public class Phone {
private String cpu;
private String screenp;
private String memory;
private String mainboad;
//构造器私有
private Phone(Builder builder){
this.cpu=builder.cpu;
this.screenp=builder.screenp;
this.memory=builder.memory;
this.mainboad=builder.mainboad;
}
public static final class Builder{
private String cpu;
private String screenp;
private String memory;
private String mainboad;
public Builder cpu(String cpu){
this.cpu=cpu;
return this;
}
public Builder screenp(String screenp){
this.screenp=screenp;
return this;
}
public Builder memory(String memory){
this.memory=memory;
return this;
}
public Builder mainboad(String mainboad){
this.mainboad=mainboad;
return this;
}
public Phone build(){
return new Phone(this);
}
}
}