扩展 Guava 集合

Question

我想扩展 LinkedHashMultimap (Guava 16.0.1)，主要是为了添加返回常用预填充地图的方法。

public class MyMap extends LinkedHashMultimap<String, Object> {
}

但是，据我所知，大多数 Guava 集合都是最终的，而那些不是最终的，不会公开公共构造函数。这个设计决定的可能原因是什么？实现我的目标的最佳方法是什么？我能想到的最好的方法是在我的类中包装 Multimap 方法，但这远非理想。

编辑：

一些用户指出了不允许继承的正当理由。为了稍微扩展问题，我想指出几点。

1. 如果公共API不推荐继承，Java自己的集合类怎么不是final的？

2. 假设我广泛使用以下类：

LinkedHashMultimap，BiConsumer>

现在，这是一口。如果可以的话：

public class ConsumerMap extends LinkedHashMultimap<Class<? extends BaseEntity>, BiConsumer<? extends BaseEntity, ? extends Object>> {
}

然后我可以在我的代码中使用 ConsumerMap 来代替那个怪物。我相信仅可读性就足以证明继承是合理的。

Answer 1

机会是：

1. 在 Java 8 中为接口添加默认方法（您不能这样做，因为集合类型是由 Guava 库定义的），
2. 扩展实施（同样你不能这样做，因为实施大多是最终的）
3. 为外部帮助类提供您想要的方法

Answer 2

这些类设计为不可扩展。因为继承本质上破坏了封装，所以当类无法扩展时，它使 API 更干净。 （相关话题：Good reasons to prohibit inheritance in Java?）

您通常可以通过使用合成来解决此问题。

回答您的后续问题：

关于 Java 集合 API，我认为有两种选择：要么像 ArrayList 或 HashMap 这样的类被设计为扩展，要么这只是一个 API 设计缺陷。我怀疑后者；但在 API 发布后，不可能恢复这种设计选择。或许只有 AbstractList 这样的抽象类才应该被声明为非最终类？

可能 Guava 团队认为像您展示的用例非常罕见，以至于不值得努力添加对继承 (YAGNI) 的支持。

This talk 由 Josh Bloch 撰写——他参与了 Java API 和 Guava 的设计——是关于该主题的精彩演讲。

Answer 3

正如其他人指出的那样，您应该更喜欢委托而不是继承。

你想要实现你想要的类是扩展ForwardingSetMultimap，使用LinkedHashMultimap作为委托。这是一个外观示例：

public final class MyMap extends ForwardingSetMultimap<String, Object> {
  private final SetMultimap<String, Object> delegate =
      LinkedHashMultimap.create();

  @Override public SetMultimap<String, Object> delegate() {
    return delegate;
  }

  // add your methods here
}

Aside：你问“如果在公共 API 中不推荐继承，为什么 Java 自己的集合类不是 final 的？”

我认为答案基本上是不创建 Java 自己的集合类 final 是一个错误（注意：其中一些，特别是较新的，实际上是 final）。正如@Mick Mnemonic 所说，Josh Bloch（设计原始集合 API）参与了 Guava 集合 API 的设计：Guava API 中的设计决策反映了从原始集合 API 中吸取的经验教训。