本文深入探讨了单子（monad）的三条核心定律：左同一律、右同一律和结合律。我们将阐明为何在验证一个对象是否为单子时，必须严格检查这三条定律，因为它们相互独立，不可偏废。文章将通过 java `optional` 类型和自定义 `counter` 类的具体示例，详细解析这些定律在实际编程中可能出现的违例情况，并提供相应的解决方案及注意事项，旨在帮助开发者更深刻地理解单子概念及其在函数式编程中的应用。
单子（Monad）及其三条基本定律
在函数式编程中，单子（Monad）是一种强大的抽象，它提供了一种结构化的方式来处理计算序列和副作用。一个类型要被称为单子，它通常需要满足两个核心操作：unit（或 of，将一个值提升到单子上下文中）和 bind（或 flatMap，将一个单子中的值映射到一个新的单子）。此外，一个有效的单子必须严格遵守三条代数定律，这些定律确保了单子行为的一致性和可预测性。
以下是单子三条定律的 Java 风格表示：
-
左同一律 (Left Identity Law) 这条定律表明，将一个普通值 x 提升到单子上下文中，然后通过 flatMap 应用一个函数 f，其结果应该与直接将 f 应用于 x 的结果相同。它保证了 unit 操作的“中性”：
Monad.of(x).flatMap(y -> f(y)) = f(x)
-
右同一律 (Right Identity Law) 这条定律指出，如果将一个单子 monad 通过 flatMap 操作，并应用一个将值重新提升回单子上下文的函数（即 Monad.of(y)），结果应该与原始单子 monad 保持一致。它保证了 unit 操作在 flatMap 链中的“无害性”：
monad.flatMap(y -> Monad.of(y)) = monad
-
结合律 (Associative Law) 结合律描述了 flatMap 操作的组合行为。它表明，连续应用两个函数 f 和 g 的顺序不应该影响最终结果。无论先将 f 应用到 monad 上，再将 g 应用到结果上，还是先将 f 映射到一个中间单子，然后将 g 应用到该中间单子内部的值上，结果都应一致：
monad.flatMap(x -> f(x)).flatMap(x -> g(x)) = monad.flatMap(x -> f(x).flatMap(y -> g(y)))
（注意：在右侧的 flatMap 内部，f(x) 返回的是一个 Monad，其内部的值 y 再被 g(y) 处理。）
为何必须验证所有单子定律？
单子定律并非相互推导，而是各自独立地约束着单子的行为。这意味着一个类型可能满足其中一条或两条定律，但却不满足第三条。因此，为了确保一个类型真正符合单子的契约，并能提供可靠、可预测的函数式编程体验，开发者必须严格验证所有三条定律。任何一条定律的违背都可能导致意料之外的行为，破坏代码的纯洁性和可组合性。
常见违例解析与示例
理解单子定律的最好方式之一是观察它们被违背的场景。以下是一些常见的违例示例：
违例一：Java Optional 与左同一律的挑战
Java 的 Optional 类型旨在作为 null 值的替代品，以避免空指针异常。它通常被视为一个单子，其中 Optional.of 或 Optional.ofNullable 作为 unit 操作，Optional.flatMap 作为 bind 操作。然而，当 Optional.ofNullable 与 null 值以及特定函数结合使用时，左同一律可能会被打破。
考虑以下场景，我们尝试将 Optional.ofNullable 作为单子的 unit：
// 左同一律: Optional.ofNullable(x).flatMap(f) = f.apply(x)
假设 x 为 null。 左侧表达式的求值过程如下：
Optional.ofNullable(null).flatMap(f)
=> Optional.empty().flatMap(f)
=> Optional.empty() // 当Optional为空时，flatMap什么也不做，直接返回Optional.empty()现在考虑右侧表达式 f.apply(x)。如果 f 是一个专门处理 null 值的函数，例如：
Optional<String> stringify(Object obj) {
if (obj == null) {
return Optional.of("NULL"); // 特殊处理null，返回一个包含"NULL"的Optional
} else {
return Optional.of(obj.toString());
}
}当 f 为 stringify 且 x 为 null 时，f.apply(null) 将返回 Optional.of("NULL")。 显然，Optional.empty() 不等于 Optional.of("NULL")。因此，左同一律被打破。
解决方案： 这个问题的根源在于 Optional.ofNullable 允许 null 值作为输入，并将其转换为 Optional.empty()。如果将 Optional.of 作为单子 unit，则可以避免此问题，因为 Optional.of 不允许 null 值，若传入 null 会直接抛出 NullPointerException，从而强制开发者在提升值时就处理 null。这确保了 Optional 始终包含一个非 null 值，从而维护了单子定律。
违例二：自定义 Counter 类与单子行为的误解
用户提供了一个 Counter 类，其结构如下：
class Counter<T> {
private final T val;
private final int count; // 计数器字段
private Counter(T val, int count) {
this.val = val;
this.count = count;
}
public static <T> Counter<T> of(T val) {
return new Counter<>(val, 1); // of 方法初始化 count 为 1
}
public <R> Counter<R> map(Function<T, R> fn) {
// map 方法每次调用都会增加 count
return new Counter<>(fn.apply(this.val), this.count + 1);
}
public <R> Counter<R> flatMap(Function<T, Counter<R>> fn) {
// flatMap 的原始实现
Counter<R> tmp = fn.apply(this.val);
return new Counter<>(tmp.val, tmp.count);
}
@Override
public boolean equals(Object obj) {
if (this == obj) { return true; }
if (!(obj instanceof Counter<?>)) { return false; }
Counter<?> ctx = (Counter<?>) obj;
return this.val.equals(ctx.val) && this.count == ctx.count; // equals 方法考虑 count
}
}乍一看，Counter 类似乎设计了一个 count 字段来记录某些操作。然而，在单子语境下，我们主要关注 of 和 flatMap 方法。
首先，分析 flatMap 方法。原始实现中：
public <R> Counter<R> flatMap(Function<T, Counter<R>> fn) {
Counter<R> tmp = fn.apply(this.val);
return new Counter<>(tmp.val, tmp.count); // 简单地返回 fn 应用的结果
}这个 flatMap 的行为实际上等同于直接返回 fn.apply(this.val)。如果我们将 count 字段在单子操作中视为不相关（即单子操作不应改变上下文的额外信息，或者说 count 应该被视为 Monad 外部的副作用），那么这个 Counter 类，仅从 val 字段和 of / flatMap 的角度看，实际上是一个恒等单子（Identity Monad）。恒等单子满足所有三条单子定律。因此，这个 Counter 类并非一个打破了右同一律而满足其他定律的例子。
真正的挑战在于 map 方法。 所有单子类型都必须首先是一个函子（Functor），这意味着它们必须有一个 map 方法，并且该 map 方法也要遵守函子定律。函子定律之一是：连续两次 map 一个函数，应该等同于 map 一次组合后的函数。 例如：monad.map(f).map(g) = monad.map(f.andThen(g))。
然而，在 Counter 类中，map 方法每次被调用时都会递增 count 字段：
public <R> Counter<R> map(Function<T, R> fn) {
return new Counter<>(fn.apply(this.val), this.count + 1);
}这意味着： Counter.of("hello").map(String::toUpperCase).map(s -> s + "!") 将会产生一个 count 为 1 + 1 + 1 = 3 的 Counter 对象。 而 Counter.of("hello").map(String::toUpperCase.andThen(s -> s + "!")) 将产生一个 count 为 1 + 1 = 2 的 Counter 对象。 由于 equals 方法考虑了 count 字段，这两个结果将不相等，从而打破了函子定律。
结论： 尽管 Counter 类的 flatMap 行为（当 count 被忽略时）满足单子定律，但其 map 方法却违背了函子定律。由于单子是函子的一种特殊形式，如果一个类型不能满足函子定律，那么它也无法成为一个有效的单子。因此，这个 Counter 类，如果 map 方法被视为其函子契约的一部分，那么它就不是一个合格的单子。这个例子揭示了在设计单子时，不仅要关注 of 和 flatMap，还要确保其作为函子的 map 方法也符合预期。
总结与注意事项
单子定律是函数式编程中构建可组合、可预测计算序列的基石。在设计和实现自定义单子时，务必牢记以下几点：
- 全面验证： 必须严格验证左同一律、右同一律和结合律这三条独立的定律。任何一条定律的违背都可能导致单子行为的不一致性。
- unit 和 bind 的选择： 仔细考虑 unit（如 of 或 ofNullable）和 bind（flatMap）的实现细节，特别是它们如何处理边缘情况（如 null 值或空上下文）。
- 函子契约： 记住所有单子都是函子。确保你的单子实现中的 map 方法也严格遵守函子定律。上下文中的额外状态（如 Counter 中的 count）不应以破坏函子定律的方式被修改。
- 清晰的语义： 单子的行为应该直观且符合预期。如果一个类型因为其内部状态的副作用而导致定律被打破，那么它可能不是一个好的单子设计。
理解并遵守这些定律，是充分利用单子强大抽象能力的关键，能够帮助开发者编写出更健壮、更易于维护的函数式代码。
