转载

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

背景

最近一口气看完了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 的定义，它是一个泛型，按照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个实例，并在静态工厂中使用。在面试中经常碰见的数值包装类“==”问题，考点就在这里。