谈谈Java常用类库中的设计模式

背景

最近一口气看完了Joshua Bloch大神的Effective Java（下文简称EJ）。书中以tips的形式罗列了Java开发中的最佳实践，每个tip都将其意图和要点压缩在了标题里，这种做法我很喜欢：一来比较亲切，比起难啃的系统书，EJ就像是一本Java的《俚语指南》；二来记忆起来十分方便，整本书过一遍就能望标题生义。

在通读这本书时，我发现作者多次列举现有类库中的实现的设计模式，我有意将其收集起来，这些实现相当经典，我觉得有必要落成一篇文章。随着以后对类库的理解越来越深，我也会持续追加上自己发现的Pattern。

概述

由于篇幅限制，本主题会做成一个系列，每个系列介绍3-4个模式。

本文介绍的设计模式（可跳转）：

建造者

 工厂方法

 享元

 桥接

Here We Go

建造者（Builder）

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

场景：创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式时；对象内部结构复杂；对象内部属性相互依赖。

类型：创建型

建造者模式在Java中最广泛的用途就是复杂对象创建。比起类构造器或Getter/Setter，它同时保证了创建过程的可读性（和属性名一致的设参方法）和安全性（未创建完毕的对象不会逸出），同时它还有：参数可选、可在类继承层次中复用、对集合类字段更加友好等等优点。对于复杂的对象都可使用建造者模式，代价是一定的性能开销与编写工作量，好在后者可以用Lombok这样的代码生成插件来解决。

借助Lombok生成类的建造者：

import lombok.*;

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor(access = AccessLevel.PRIVATE)

public class Foo {

    private String name;

    private Integer height;

    private Integer length;

     public static void main(String[] args) {

        Foo f = Foo.builder().name("SQUARE").height(10),length(10).build();

    }

}

除了使用建造者创建普通Java Bean之外，许多类库中配置类对象也照葫芦画瓢。比如SpringBoot中对Swagger2的简单配置，使其在生产环境下关闭。

@Configuration

public class SwaggerConfig {

    @Value("${spring.profiles.active}")

    private String prop;

    @Bean

    public Docket api() {

        return new Docket(DocumentationType.SWAGGER_2)

                .enable(!prop.contains("prod"))

                .select()

                .apis(RequestHandlerSelectors.any()).build();

    }

}

工厂方法（Factory Method）

定义：定义一个创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

场景：明确计划不同条件下创建不同实例时。

类型：创建型

若要找工厂方法在JAVA原生类库中最贴切的对照物，非 Supplier 莫属。这个来自JAVA 8 Function包的函数式接口，将工厂方法模式的编写成本降到极低。

package java.util.function;

/**

 * Represents a supplier of results.

 *

 * <p>There is no requirement that a new or distinct result be returned each

 * time the supplier is invoked.

 *

 * <p>This is a <a href="package-summary.html">functional interface</a>

 * whose functional method is {@link #get()}.

 *

 * @param <T> the type of results supplied by this supplier

 *

 * @since 1.8

 */

@FunctionalInterface

public interface Supplier<T> {

    /**

     * Gets a result.

     *

     * @return a result

     */

    T get();

}

如果将工厂类作为方法入参，将保证对象会在最迫切的时机才会创建：

public class StreamTest {

    public static void main(String[] args) {

        Stream.generate(()->{

            System.out.println("creating a new object.");

            return new Object();

        }).limit(3);

    }

}

==============================

输出:

Stream.generate(Supplier<T> s)创建了一个流，并声明了这个流的元素来源：一个由Lambda表达式编写的工厂。编译器将其推导为一个Supplier实例。在对象创建时将打印日志，然而结果表明没有任何对象创建成功。因为在未声明终结函数时，赋予Stream的任何中间函数都不会执行。

使用工厂方法，生产数据的时机将由消费者把握，这是一种懒汉思想。

再回到 Supplier<T> 的定义，它是一个泛型，按照EJ的建议，当使用泛型作为方法入参和返回值时，最好遵循 PECS 规则。

Producer-Extends Consumer-Super

Supplier通常是放在方法入参的生产者，所以应该这么声明：

public void generate(Supplier<T extends Shape> supplier) {}

这样Shape的所有子类工厂都能传入到此方法中，增强其拓展性。对应了工厂方法定义当中 让子类决定实例化哪一个类 的部分。

享元 (Flyweight)

定义：运用共享技术有效地支持大量细粒度的对象。

场景：应用使用大量对象，造成庞大的存储开销；对象中的大多数状态可以移至外部，剩下的部分可以共享。

类型：结构型

JDK类库中使用了大量的静态工厂（泛指创建对象的静态类/静态方法），这些静态工厂有一个重要的作用：为重复的调用返回相同的对象。使类成为实例受控的类（instance-controlled），这实际上就是享元的思想。

举个例子，下面是 Boolean.valueOf(boolean b) 的代码片段。

    /**

     * The {@code Boolean} object corresponding to the primitive

     * value {@code true}.

     */

    public static final Boolean TRUE = new Boolean(true);

    /**

     * The {@code Boolean} object corresponding to the primitive

     * value {@code false}.

     */

    public static final Boolean FALSE = new Boolean(false);

    public static Boolean valueOf(boolean b) {

        return (b ? TRUE : FALSE);

    }

Boolean 作为布尔类型的包装类，进行了实例控制。因为布尔类型的值只有 True 和 False ，除此之外没有其他状态字段，所以类库设计者选择在类加载时初始化两个不可变实例，在静态工厂中不创建对象。

这也表明 Boolean.valueOf 返回的实例在执行==和equals时结果一致。

其他包装类型如Byte，Short，Integer也有类似的设计：使用名为XCache（X表示类型名）的私有内部类中存储值在 -128 ~ 127 之间共256个实例，并在静态工厂中使用。在面试中经常碰见的数值包装类“==”问题，考点就在这里。

桥接（Bridge）

定义：将抽象部分与他的实现部分分离，使它们都可以独立地变化。

场景：实现系统可能有多个角度分类，每一种角度都可能变化；在构件的抽象化和具体化之间增加更多的灵活性，避免两个层次之间的静态继承关系；控制系统中继承层次过多过深。

类型：结构型

首先了解一个概念：服务提供者框架（Service Provider Framework）（下文简称SPF）。

服务提供者框架指这样一个系统：多个服务提供者实现一个服务，系统为服务提供者的客户端提供多个实现，并把它们从多个实现中解耦出来。

它由4种组件组成：

服务接口：需被实现的接口或抽象类

提供者注册API：实现类用来注册自己到SPF中的

服务访问API：客户端用来获取实现的

服务提供者接口：实现类的工厂对象，用来创建实现类的实例，是可选的

SPF模式的应用是如此广泛，其实现的变体也有很多。如Java 6提供的标准实现ServiceLoader，还有Spring、Guice这样的依赖注入框架。但我选择举一个大家更为熟悉的例子：JDBC。

使用JDBC与数据库交互是每个Java程序员的必经之路，而它的设计实际上也是SPF模式：

服务接口 -> Connection

提供者注册API：DriverManager.registerDriver

服务访问API：DriverManager.getConnection

服务提供者接口：Driver

想要使用不同的数据库连接实现，只需通过服务访问API切换即可。这体现了桥接中将抽象与实现分离的精神。

（实际上如果加载多个数据库驱动，DriverManager会逐个尝试连接，并返回连接成功的实例。并不能人为选择提供者，但可以通过更改提供者注册代码来实现。）

Druid、Hikari等现代连接池的实现往往比JDBC定义的服务接口更加丰富，如监控、插件链、SQL日志等等，这体现了桥接当中的独立变化。

参考：

[1] Play With Java ServiceLoader And Forget About Dependency Injection Frameworks - (2016/10/02)

https://dzone.com/articles/play-with-java-serviceloader-forget-about-dependen

[2] Effective Java - 机械工业出版社 - Joshua Bloch (2017/11)

[3] 《大话设计模式》 - 清华大学出版社 - 陈杰 (2007/12)