前言

函数式编程是一种历久弥新的编程范式，比起命令式编程，它更加关注程序的执行结果而不是执行过程。Guava 做了一些很棒的工作，搭建了在 Java 中模拟函数式编程的基础设施，让我们不用多费手脚就能享受部分函数式编程带来的便利。

Java 始终是一个面向对象（命令式）的语言，在我们使用函数式编程这种黑魔法之前，需要确认：同样的功能，使用函数式编程来实现，能否在健壮性和可维护性上，超过使用面向对象（命令式）编程的实现？

Predicate

Predicate 接口是我们第二个介绍的 Guava 函数式编程基础设施。

下面这段代码是去掉注释之后的 Predicate 接口。

@GwtCompatible
public interface Predicate<T> {
  boolean apply(@Nullable T input);
  @Override
  boolean equals(@Nullable Object object);
}

它看起来就是一个简化版本的 Function，除了指定返回值的类型为 boolean 之外，没有其他的差别了。

下面我们定义一个简单的谓词函数，判断一个字符串的长度是否小于10。

Predicate<String> lengthLessThen10 = new Predicate<String>() {
    public boolean apply(String input) {
        return input.length() < 10;
    }
};
lengthLessThen10.apply("lessThen10");//false

这里我们实例化了一个谓词仿函数，能且只能判断一个字符串的长度是否小于 10。假如我们希望得到更加通用的代码，能够根据不同的参数得到判断字符串长度小于不同长度的谓词，我们就需要用到函数式编程中一种称为“柯里化”的技术。

Function<Integer, Predicate<String>> lengthLessThen = new Function<Integer, Predicate<String>>() {
    public Predicate<String> apply(final Integer input) {
        return new Predicate<String>() {
            public boolean apply(String str) {
                return str.length() < input;
            }
        };
    }
};
lengthLessThen.apply(10).apply("lessThen10");//false

首先，我们定义了一个 Function，接受 Integer 类型的参数，返回 Predicate 实例；在实例化 Predicate 的时候，我们访问了匿名类外部的变量，也即 Function 实例的 apply 方法的参数，由于 Java 语言的限制，匿名类内部用到的外部变量必须声明为 final。

Predicates

Predicates 是 Guava 中与 Predicate 接口配套使用的工具类，提供了一些非常有用的工具类，比如使用 and 和 or 组合多个谓词，还有 not 将谓词的条件取反。和 Functions 比较类似的是，Predicates 提供了一个 compose 方法，用于组合 Function 和 Predicate。

Predicates 是一个方法工厂，返回各种各样的 Predicate 实例。

Predicates#alwaysTrue 返回一个永真谓词，Predicates#alwaysFalse 返回一个永假谓词。

Predicates#isNull 返回的谓词在参数为 null 时为真，Predicates#notNull 则返回与之相反的谓词。

Predicates#equalTo 返回一个谓词，当谓词参数与 Predicates#equalTo 的参数在逻辑上等价时为真。

Predicates#instanceOf 返回一个谓词，当谓词参数是 Predicates#instanceOf 的参数的实例时为真。

Predicates#assignableFrom 返回一个谓词，当谓词参数表示的类和 Predicates#assignableFrom 的参数表示的类，有着相同或者超类、接口关系的时候为真。

Predicates#in 返回一个谓词，当谓词参数在 Predicates#in 的参数表示的集合中时为真。

Predicates#contains 返回一个谓词，当谓词参数表示的字符串中包含 Predicates#contains 的参数所表示的正则模式时为真。Predicates#containsPattern 的功能与之类似。

我们可以看到，除了最先介绍的 4 个工厂函数，其余工厂函数返回的谓词，都和工厂函数的参数有着紧密的绑定关系，类似于我们在介绍 Predicate 时提到的闭包。然而 Guava 在实现中为了给用户更好的体验，没有直接使用闭包，而是使用了许多的内部类来支撑这些工厂函数，具体细节我们在源码分析部分展开。

接下来是谓词之间的与或非运算，还有和函数组合称为新的谓词。

Predicates#not 返回一个取反之后的谓词，Predicates#and 返回两个或多个谓词做与运算之后的谓词，Predicates#or 返回两个或多个谓词做或运算之后的谓词，Predicates#compose 将参数中的 Function 的返回值作为另一个参数谓词的参数，返回新的谓词。

源码分析

我们先看看支撑了 Predicates#alwaysTrue 等 4 个谓词工厂函数的内部类，ObjectPredicate。

enum ObjectPredicate implements Predicate<Object> {
  /** @see Predicates#alwaysTrue() */
  ALWAYS_TRUE {
    @Override public boolean apply(@Nullable Object o) { return true; }
    @Override public String toString() { return "Predicates.alwaysTrue()"; }
  },
  /** @see Predicates#alwaysFalse() */
  ALWAYS_FALSE {
    @Override public boolean apply(@Nullable Object o) { return false; }
    @Override public String toString() { return "Predicates.alwaysFalse()"; }
  },
  /** @see Predicates#isNull() */
  IS_NULL {
    @Override public boolean apply(@Nullable Object o) { return o == null; }
    @Override public String toString() { return "Predicates.isNull()"; }
  },
  /** @see Predicates#notNull() */
  NOT_NULL {
    @Override public boolean apply(@Nullable Object o) { return o != null; }
    @Override public String toString() { return "Predicates.notNull()"; }
  };

  @SuppressWarnings("unchecked") // safe contravariant cast
  <T> Predicate<T> withNarrowedType() { return (Predicate<T>) this; }
}

这些谓词的构造过程无需来自工厂函数的参数，因此全都用枚举类构造成了单例，类似的手法在 Functions 类中也使用过。

这里比较有意思的代码是 withNarrowedType 函数。结合 Predicates#alwaysTrue 我们就容易明白这段代码的用途。

public static <T> Predicate<T> alwaysTrue() {
  return ObjectPredicate.ALWAYS_TRUE.withNarrowedType();
}

工厂函数返回的 Predicate 支持泛型，然而 ObjectPredicate 内部的单例却是 Predicate 接口的 Object 类型实现。这段代码其实就是把泛型参数为 Object 的 ObjectPredicate 实例，强制转换为用户指定的泛型参数的谓词。

下面我们以支撑 Predicates#or 功能的内部类 OrPredicate 为例，分析类似功能的实现。

private static class OrPredicate<T> implements Predicate<T>, Serializable {
  private final List<? extends Predicate<? super T>> components;

  private OrPredicate(List<? extends Predicate<? super T>> components) {
    this.components = components;
  }
  @Override
  public boolean apply(@Nullable T t) {
    // Avoid using the Iterator to avoid generating garbage (issue 820).
    for (int i = 0; i < components.size(); i++) {
      if (components.get(i).apply(t)) {
        return true;
      }
    }
    return false;
  }
  @Override public int hashCode() {
    // add a random number to avoid collisions with AndPredicate
    return components.hashCode() + 0x053c91cf;
  }
  @Override public boolean equals(@Nullable Object obj) {
    if (obj instanceof OrPredicate) {
      OrPredicate<?> that = (OrPredicate<?>) obj;
      return components.equals(that.components);
    }
    return false;
  }
  @Override public String toString() {
    return "Predicates.or(" + COMMA_JOINER.join(components) + ")";
  }
  private static final long serialVersionUID = 0;
}

将多个 Predicate 做或操作，无非就是遍历集合，只要有一个谓词为真，则整体为真。

OrPredicate 的实现中，值得关注的地方，都加上了注释。第一个是 apply 函数。这段注释说的是，遍历集合的过程中，为了减少垃圾对象的产生，不使用迭代器，而是直接遍历下标。

使用迭代器的好处是，无论目标集合是什么数据结构，总能保证获取下一个元素的时间复杂度是 $O (1)$ ，然而根据下标获取元素则没有这个保证，假如用于初始化 OrPredicate 的 List 其实是一个链表，那么用下标遍历集合的时间复杂度就是 $O (N^{2})$ 。

Guava 的设计者肯定不会允许一个平方复杂度的遍历存在，我们接下来看一看究竟是 Guava 是如何保证遍历谓词集合的复杂度不会退化为 $O (N^{2})$ 的。

public static <T> Predicate<T> or(
    Iterable<? extends Predicate<? super T>> components) {
  return new OrPredicate<T>(defensiveCopy(components));
}
static <T> List<T> defensiveCopy(Iterable<T> iterable) {
  ArrayList<T> list = new ArrayList<T>();
  for (T element : iterable) {
    list.add(checkNotNull(element));
  }
  return list;
}

从工厂函数的实现来看，在用一个谓词集合构造 OrPredicate 之前，这个集合首先被做了一份拷贝，这种操作被称为“防御性拷贝”。如此构造出来的谓词，即使当初用于构建谓词的集合发生了变化，谓词的行为不会随之而变。正是这个防御性拷贝，使得构造出来的谓词不依赖于外部的变量，是一个可重入的函数。同时，防御性拷贝得到的 List 是一个 ArrayList，即使根据下标来遍历列表，复杂度也是 $O (N)$ 。

下一个注释出现在 hashCode 函数中，解释了为作为参数的谓词集合的哈希值加上一个固定随机值的原因：为了不和 AndPredicate 产生碰撞。考虑这样一个场景，用户用一组谓词，分别通过 Predicates#and 和 Predicates#or 生成两个组合谓词。如果仅仅是使用这组谓词的哈希值作为组合谓词的哈希值，那么这两个不同的组合谓词就会产生哈希碰撞，然后哈希表退化为链表。

最后我们看一看用于判定字符串是否包含正则模式的谓词，Predicates#contains 的实现。这段代码比较长，而且包含了 Guava 开发者对 Java 官方代码的吐槽，比较有趣。

private static class ContainsPatternPredicate
    implements Predicate<CharSequence>, Serializable {
  final Pattern pattern;

  ContainsPatternPredicate(Pattern pattern) {
    this.pattern = checkNotNull(pattern);
  }
  @Override
  public boolean apply(CharSequence t) {
    return pattern.matcher(t).find();
  }
  @Override public int hashCode() {
    // Pattern uses Object.hashCode, so we have to reach
    // inside to build a hashCode consistent with equals.
    return Objects.hashCode(pattern.pattern(), pattern.flags());
  }
  @Override public boolean equals(@Nullable Object obj) {
    if (obj instanceof ContainsPatternPredicate) {
      ContainsPatternPredicate that = (ContainsPatternPredicate) obj;
      // Pattern uses Object (identity) equality, so we have to reach
      // inside to compare individual fields.
      return Objects.equal(pattern.pattern(), that.pattern.pattern())
          && Objects.equal(pattern.flags(), that.pattern.flags());
    }
    return false;
  }
  @Override public String toString() {
    String patternString = Objects.toStringHelper(pattern)
        .add("pattern", pattern.pattern())
        .add("pattern.flags", pattern.flags())
        .toString();
    return "Predicates.contains(" + patternString + ")";
  }
  private static final long serialVersionUID = 0;
}

我们关注 hashCode 和 equals 函数。一般来说，这两个函数一旦覆盖就必须同时覆盖，如果只覆盖其中一个就有可能产生极其难以发现的 bug。我们假设逻辑相等的对象有着相同的哈希值，在覆盖这两个方法的时候也需要小心的确保这个假设成立。

我们看看 Guava 开发者吐槽了什么。这两段注释说的差不多是同一个意思，埋怨 Pattern 类的 hashCode 和 equals 都直接使用继承自 Object 的实现，导致他们不得不深入 Pattern 内部，以获取能用来实现这两个函数的东西。

因为我们永远不知道自己设计的类会被使用者用在什么地方，所以有这么一个最佳实践是为所有的类覆盖实现 hashCode 和 equals 函数。接下来我们看看为什么继承自 Object 的实现被 Guava 开发者视为不可用的实现。

我们先说 equals 函数。

public boolean equals(Object obj) {
    return (this == obj);
}

equals 函数判断两个对象是否逻辑相等，当且仅当两个对象其实指向同一个对象。这种比较未免太简单粗暴了，完全不是逻辑相等，而是绝对相等。

然后我们看看 hashCode 函数。

public native int hashCode();

Object 对象的 hashCode 函数是一个 native 方法，返回的哈希值依赖于对象的内存地址。

所以说，Object 的 hashCode 和 equals 对于那些需要逻辑相等的对象来说都太严格了，判断两个正则模式是否相等，需要一种较为宽松的比较方式。为什么 Guava 开发者选择了 Pattern#flags 和 Pattern#pattern 作为判断两个 Pattern 相等的依据？

考察 Pattern 的构造函数，我们发现它的构造函数最多能够接收两个参数，一个字符串格式的正则表达式，还有一个整型的标志位。

public static Pattern compile(String regex, int flags) {
    return new Pattern(regex, flags);
}
private Pattern(String p, int f) {
    pattern = p;
    flags = f;
    //other codes
}

看到这里我们就知道了，只要 Pattern#pattern 和 Pattern#flags 一致，那么两个 Pattern 对象就是一致的。

Guava 是个风火轮之函数式编程(2)

前言

Predicate

Predicates

源码分析

热门文章

最新文章

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

Guava 是个风火轮之函数式编程(2)

前言

Predicate

Predicates

源码分析

热门文章

最新文章

相关电子书