设计模式（1）— 建造者模式

设计模式

  设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

  根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 中所提到的，总共有 23 种设计模式。

  根据模式是用来完成什么工作来划分，这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）

  1. 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
  2. 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
  3. 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。

案例代码：https://github.com/Kaiyko/DesignPattern

1. 创建者模式

创建者模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。

这样可以降低系统的耦合度，使用者不需要关注对象的创建细节。

创建者模式分为：

  • 单例模式

  • 工厂方法模式

  • 抽象工程模式

  • 原型模式

  • 建造者模式

1.1 单例设计模式

单例模式是Java中最简单的设计模式之一。这种类型的设计模式属于创建者模式，它提供了一种创建对象的最佳方式。

这种模式设计到一个单一的累，该类负责创建自己的对象，同时确保只有耽搁对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

1. 单例模式的结构

单例模式主要有以下角色：

  • 单例类。只能创建一个实例的类
  • 访问类。使用单例类

2. 单例模式的实现

单例设计模式分两种：

  • 饿汉式：类加载就会导致该单例实例对象被创建

  • 懒汉式：类加载不会导致该单例实例对象被创建，而是首次使用该对象时才会被创建

  1. 饿汉式 — 静态变量方式
/**
 * 饿汉式 — 静态成员变量
 */
public class Singleton {

    //  1.私有构造方法
    private Singleton() { }

    //  2.在本类中创建本类对象
    private static Singleton instance = new Singleton();

    //  3.提供一个公共的访问方式，让外界获取该对象
    public static Singleton  getInstance() {
        return instance;
    }
}

说明：

  该方式在成员位置声明Singleton类型的静态变量，并创建Singleton类的对象instance。instance对象时随着类的加载而创建的。如果该对象内存足够大的话，而一直没有使用就会造成内存的浪费。

  1. 饿汉式 — 静态代码块
/**
 * 饿汉式 — 静态代码块
 */
public class Singleton {

    private Singleton() {}

    private static Singleton instance;

  	//	静态代码块，在类加载的时候就会进行实例化
    static {
        instance = new Singleton();
    }

    public static Singleton getInstance() {
        return instance;
    }
}

说明：

  该方式在成员位置声明Singleton类型的静态变量，而对象的创建是在静态代码块中，也是随着类的加载而创建。该方式也存在内存浪费问题。

  1. 懒汉式 — 线程不安全
/**
 * 懒汉式 — 线程不安全
 */
public class Singleton {

    //  私有构造方法
    private Singleton() { }
    
    //  声明Singleton类型的变量instance
    private static Singleton instance;

    //  对外提供访问方式
    public static Singleton getInstance() {
        //  如果从未被创建则实例化一个
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

说明：

  从上面代码我们可以看出该方式在成员变量位置声明Singleton类型的静态变量，并没有进行对象的赋值操作，当调用getInstance( )方法获取SIngleton类的对象时才会创建。这样就实现了懒加载的效果，但是在多线程环境下，会出现线程安全问题

  1. 懒汉式 — synchronized关键字（线程安全，效率低下）
/**
 * 懒汉式 — 线程安全
 */
public class Singleton {

    //  私有构造方法
    private Singleton() { }

    //  声明Singleton类型的变量instance
    private static Singleton instance;

    //  对外提供访问方式，添加synchronized关键字确保线程安全
    public static synchronized Singleton getInstance() {
        //  如果从未被创建则实例化一个
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

说明：

  该方式也实现了懒加载效果，同时又解决了线程安全问题。但是在getInstance( )方法上添加了synchronized关键字，导致该方法的执行效率特别低。这种方式只有在初始化instance的时候才会出现线程安全问题，因此可以从中入手优化

  1. 懒汉式 — 双重检查锁（线程安全，效率提升）

  对于getInstance( )方法来说，绝大部分操作都是读操作，读操作是线程安全的，所以没必要让每个线程必须持有锁才能调用该方法，我们需要调整加锁的世纪。由此也产生了一种新的实现方式：双重检查锁模式

/**
 * 懒汉式 — 双重检查锁（线程安全）
 */
public class Singleton {

    //  私有构造方法
    private Singleton() { }

    //  声明Singleton类型的变量instance
    private static volatile Singleton instance;

    //  对外提供访问方式，添加synchronized关键字确保线程安全
    public static Singleton getInstance() {
        //  如果从未被创建则实例化一个
        if (instance == null) {
            // 对象锁
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

说明：

  双重检查锁模式是一种非常好的单例实现模式，解决了单里、性能、线程安全问题，在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。要解决这个问题可以使用volatile关键字，保证实例化对象的可见性和有序性。

  1. 懒汉式 — 静态内部类方式

  静态内部类单例模式中由内部类创建，由于JVM在加载外部类的过程中，是不会加载静态内部类的，只有内部类的属性/方法被调用时才会被加载，并初始化其静态属性。静态属性由于被static修饰，保证只被实例化一次，并且严格保证实例化顺序

/**
 * 懒汉式 — 静态内部类方式
 */
public class Singleton {
    
    //  私有构造方法
    private Singleton() { }
    
    //  静态内部类
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    //  对外提供静态方法获取该对象
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

说明：

  第一次加载Singleton类时不会去初始化INSTANCE，只有第一次调用getInstance( )，虚拟机加载SingletonHolder并初始化INSTANCE，这样不仅能确保线程安全，也能保证Singleton类的唯一性。

  静态内部类单例模式时一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有任何加锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费

  1. 枚举方式

  枚举类实现单例模式是极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特征来实现单例模式，枚举的写法非常简单，而且枚举类型是所有单例实现中唯一一种不会被破坏的单例实现模式。

/**
 * 枚举方式（饿汉式）
 */
public enum Singleton {
    INSTANCE;
}

3. 存在的问题

破坏单例模式：

上述的创建单例模式方式，除枚举方式外，都有可能被创建多个对象，即破坏单例模式，破坏的方式分别是序列化和反射。

4. 问题的解决

  • 序列化、反序列化破坏单例模式的解决方法

    在SIngleton类中添加readResolve( )方法，在反序列化时被反射调用，如果定义了这个方法，就返回这个方法的值，如果没有定义，则返回新的对象。

import java.io.Serializable;

/**
 * 懒汉式 — 静态内部类方式
 * 处理序列化造成的破坏单例
 */
public class Singleton implements Serializable {

    //  私有构造方法
    private Singleton() { }

    //  静态内部类
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    //  对外提供静态方法获取该对象
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }

    //  当进行反序列化时，会自动调用该方法，将该方法的返回值直接返回
    public Object readResolve() {
        return SingletonHolder.INSTANCE;
    }
}

  • 反射方式破环单例的解决方法

    直接从反射的原理入手，反射会调用无参构造方法完成实例化对象，只需要在无参构造加加以判断。

 /**
 * 懒汉式 — 静态内部类方式
 * 解决反射破坏单例模式
 */
public class Singleton {

    private static boolean flag = false;

    //  私有构造方法
    private Singleton() {
        //  确保线程安全
        synchronized (Singleton.class) {
            //  从反射的原理入手，反射会调用无参构造方法完成实例化对象
            if (flag) {
                throw new RuntimeException("该对象已实例化，请不要使用反射再次实例化该对象");
            }
            flag = true;
        }
    }

    //  静态内部类
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    //  对外提供静态方法获取该对象
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

1.2 工厂模式

1. 概述

  在Java中，万物皆对象，这些对象都需要创建，如果创建的时候直接new该对象，就会对该对象耦合严重，假如我们要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象，我么就只和工厂打交道就可以了，彻底和对象解耦，如果需要更换独享，直接在工厂里更换该对象即可，达到了与对象解藕的目的；因此，工厂模式最大的优点就是解藕

以下介绍三种工厂模式的使用

  • 简单工厂模式（不属于GOF的23中经典设计模式）

  • 工厂方法模式

  • 抽象工厂模式

2. 简单工厂模式

简单工厂模式不是一种设计模式，反而比较像是一种编程习惯

1. 结构

简单工厂包含如下角色：

  • 抽象产品：定义了产品的规范，描述了产品的主要特性和功能
  • 具体产品：实现或者继承了抽象产品的子类
  • 具体工厂：提供了创建产品的方法，调用者通过该方法来获取产品对象
2. 实现

省略

3. 优缺点

优点：

  封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户端，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了客户代码修改的可能性，更加容易扩展。

缺点：

  增加新产品时还是需要修改工厂类的代码，违背了“开闭原则”。

4. 扩展

静态工厂

  在开发中也有一部分人将工厂类中的创建对象的功能定义为静态的，这个就是静态工厂模式，它也不是23种设计模式种的。

3. 工厂方法模式

针对上例中的缺点，使用工厂方法模式就可以完美的解决，完全遵循开闭原则。

1. 概念

  定义一个用于创建对象的接口，让子类决定实例化哪个产品类对象。工厂发发使一个产品类的实例化延迟到其工厂的子类。

2. 结构

工厂方法模式的主要角色：

  • 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。
  • 具体工厂（Concrete Factory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
  • 抽象产品（Abstract Product）：定义了产品的规范，描述了产品的主要特性和功能。
  • 具体产品（Concrete Product）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。
3. 实现

略

4. 优缺点

优点：

  • 用户只需要知道具体工厂的名称就可得到所想要的产品，无需知道产品的具体创建过程；
  • 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无需对原工厂进行任何修改，满足开闭原则；

缺点：

  • 每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，者增加了系统的复杂度；

4. 抽象工厂模式

  前面介绍的工厂方法模式中考虑的是一类产品的生产，如畜牧场只养动物、电视机厂只生产电视机等。

  这些工厂只生产同种类产品，同种类产品称为同等级产品，也就是说：工厂方法模式只考虑生产同等级的产品，但是在现实生活中许多工厂是综合型的工厂，能生产多等级（种类）的产品，如电器厂既生产电视机又生产洗衣机或空调，大学既有软件专业又有生物专业。

  以下要介绍的抽象工厂模式将考虑多等级产品的生产，将同一个具体工厂所生产的位于不同等级的一组产品称为一个产品族。

1. 概念

  抽象工厂模式是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无需指定所要产品的具体类就能够得到同族的不同等级的产品的模式结构。

  抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品

2. 结构

抽象工厂模式的主要角色如下：

  • 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法，可以创建多个不同等级的产品。
  • 具体工厂（Concrete Factory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
  • 抽象产品（Abstract Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。
  • 具体产品（Concrete Product）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间是多对一关系。
3. 实现

略

说明：

  如果要加一个产品族的话，只需要再加一个对应的工厂类即可，不需要修改其他的类。

4. 优缺点

优点：

  当一个产品族中的多个对象被设计成一起工作时，它能保证客户端只使用一个产品族中的对象

缺点：

  当产品族中需要添加一个新的产品时，所有的工厂类都需要进行修改。

5. 使用场景

  • 当需要创建的对象是一系列相互关联或相互依赖的产品族时，如电器工厂中的电视机、咖啡机、空调等。

  • 系统中有多个产品族，但每次只使用其中的某一族产品。如有人只喜欢穿某一个瓶拍的衣服和鞋。

  • 系统中提供了产品的类库，且所有产品的接口相同，客户端不依赖产品实例的创建细节和内部结构

5. 模式扩展

简单工厂+配置文件解除耦合

可以通过工厂模式+配置文件的方式解除工厂对象和产品对象的耦合。在工厂类中加载配置文件中的全类名，并创建对象进行存储，客户端如果需要对象，直接进行获取即可。

1.3 原型模式

1. 概述

  用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型对象相同的新对象

2. 结构

原型模式包含如下角色：

  • 抽象原型类：规定了具体原型对象必须实现的clone( )方法。
  • 具体原型类：实现抽象原型类的clone( )方法，它是可被复制的对象。
  • 访问类：使用具体原型类中的clone( )方法来复制新的对象

3. 实现

原型模式的克隆分为浅克隆和深克隆

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。

深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

Java中Object类中提供了clone( )方法来实现浅克隆。Cloneable接口即为抽象原型类，而实现了Cloneable接口的子实现类就是具体的原型类

public class RealizeType implements Cloneable {

    public RealizeType() {
        System.out.println("构造方法运行");
    }

    @Override
    public RealizeType clone() throws CloneNotSupportedException {
        System.out.println("具体原型复制成功");
        return (RealizeType) super.clone();
    }
}

4. 案例

略

5. 使用场景

  • 对象的创建非常复杂，可以使用原型模式快捷的创建对象。
  • 性能和安全要求比较高

6. 扩展（深克隆）

使用对象流

1.4 建造者模式

1. 概述

将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示

  • 分离了部件的构造（由Builder来负责）和装配（由Director负责）。从而构造出复杂的对象。这个模式适用于：某个对象的构造过程复杂的情况。
  • 由于实现了构建和装配的解藕。不同的构建器，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构造算法装配算法的解藕，实现了更好的复用。
  • 建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定对象的类型就可以得到该对象，而无需知道其内部的具体构造细节。

2. 结构

建造者（Builder）模式包含如下角色：

  • 抽象建造者类（Builder）：这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的对象部件的创建。
  • 具体建造者类（ConcreteBuilder）：实现Builder接口，完成复杂产品的各个部件的具体创建方法。在构造过程完成后，提供产品的实例。
  • 产品类（Product）：要创建的复杂对象。
  • 指挥者类（Director）：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

3. 实现

略

4. 优缺点

优点：

  • 建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
  • 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身鱼产品的创建过程解藕，使得相同的创建过程可以创建不同的产品对象。
  • 可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
  • 建造者模式很容易惊醒扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则

缺点：

  建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

5. 使用场景

  建造者模式创建的是复杂对象，其产品的各个部分经常面临着剧烈的变化，但将它们组合在一起的算法却相对稳定，所以它通常在以下场合使用：

  • 创建的对象比较复杂，由多个部件构成，各部件面临着复杂的变化，但构件间的建造顺序是稳定的。
  • 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式，即产品的构建过程和最终的表示是独立的。

6. 模式扩展

  建造者模式除了上面的用途外，在开发中还有一个常用的使用方式，就是当一个类构造器需要传入很多参数时，如果创建这个类的实例，代码可读性会非常差，而且容易引入错误，此时就可以利用建造者模式进行重构。

/**
 * 手机类
 */
public 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;
    }

    public static final class Builder {
        private String cpu;
        private String screen;
        private String memory;
        private String mainBoard;

        // 使用构建者创建Phone对象
        public Phone build() {
            return new Phone(this);
        }

        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;
        }
    }

    @Override
    public String toString() {
        return "Phone{" +
                "cpu='" + cpu + '\'' +
                ", screen='" + screen + '\'' +
                ", memory='" + memory + '\'' +
                ", mainBoard='" + mainBoard + '\'' +
                '}';
    }
}

/**
 * 测试类
 */
public class TestClient {
    public static void main(String[] args) {
        //  创建手机对象 通过构建者对象获取手机对象
        Phone phone = new Phone.Builder()
                .cpu("intel")
                .screen("三星屏幕")
                .memory("金士顿内存条")
                .mainBoard("华硕主板")
                .build();

        System.out.println(phone);
    }

}

某种程度上也可以提高开发效率。从软件设计上，对程序员的要求比较高。

1.5 创建者模式对比

1. 工厂方法模式 vs 建造者模式

  工厂方法模式注重的是整体对象的创建方式；而建造者模式注重的是部件构建的过程，意在一步一步地精确构造创建出一个对象。

  例如：如果要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够内裤外穿的超人；而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。

2. 抽象工厂模式 vs 建造者模式

  抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品具有不同分维度的产品组合，采用抽象工厂模式则是不需要关心构建过程，只关心什么产品由什么工厂生产即可。

  建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品。

  如果将抽象工厂模式堪称汽车配件生产工厂，生产一个产品族的产品，那么建造者模式局势一个启程组装工厂，通过部件的组装可以返回一辆完整的汽车。

  二者可以搭配使用。

posted @ 2021-07-05 17:21  Kaiyko  阅读(137)  评论(0)    收藏  举报