接口骨架实现中的抽象方法

Question

我正在重读《Effective Java》（第二版）第 18 项，更喜欢接口而不是抽象类。 在该项目中，Josh Bloch 提供了 Map.Entry接口的骨架实现示例：

// Skeletal Implementation
public abstract class AbstractMapEntry<K,V>
        implements Map.Entry<K,V> {
    // Primitive operations
    public abstract K getKey();
    public abstract V getValue();

 // ... remainder omitted
}

此示例产生了两个问题：

1. 为什么 getKey 和 getValue 在此显式声明为抽象方法？ 它们是 Map.Entry 的一部分 接口，所以我看不出抽象类中有多余声明的原因。

2. 为什么使用将这些原始方法（正如 Bloch 先生所说）保留为抽象的习惯用法？ 为什么不这样做：

   // 骨架实现 公共抽象类 AbstractMapEntry 实现 Map.Entry { 私人K密钥； 私有V值；

    // 原始操作 
         公共 K getKey() {返回键;} 
         public V getValue() {返回值;} 
   
      // ... 省略余数 
     

   }

做的好处是每个子类不必定义自己的字段集，并且仍然可以通过其访问器访问键和值。 如果子类确实需要为访问器定义自己的行为，则可以直接实现 Map.Entry 接口。 另一个缺点是，在骨架实现提供的 equals 方法中，调用了抽象访问器：

// Implements the general contract of Map.Entry.equals
@Override public boolean equals(Object o) {
    if (o == this)
        return true;
    if (! (o instanceof Map.Entry))
        return false;
    Map.Entry<?,?> arg = (Map.Entry) o;
    return equals(getKey(),   arg.getKey()) &&
           equals(getValue(), arg.getValue());
}

Bloch 警告不要从为继承设计的类中调用可重写方法（第 17 项），因为这会使超类容易受到子类所做更改的影响。 也许这是一个观点问题，但我希望确定这个故事是否还有更多内容，因为布洛赫在书中并没有真正详细说明这一点。

Answer 1

1. 我想说它有助于强调具体类要处理的内容，而不是仅仅让编译器告诉您（或者您必须比较两者以查看缺少什么）。 一种自记录代码。 但这当然没有必要，据我所知，这更多的是一种风格。
2. 返回这些值有比简单的获取和设置更重要的逻辑。 我在标准 JDK(1.5) 中抽查的每个类都在至少一个方法上做了一些不简单的事情，所以我猜他认为这样的实现太天真了，这会鼓励子类使用它而不是仔细思考自己的问题。

关于 equals 的问题，如果抽象类实现了它们，则不会有任何改变，因为该问题是可重写的。 在这种情况下，我想说 equals 正在尝试仔细实现以预测实现。 由于协方差问题（超类会认为它等于子类，但子类不会认为它等于超类），通常不应实现 equals 在其自身与其子类之间返回 true（尽管有很多这样做） ，所以无论你做什么，这种类型的 equals 实现都是棘手的。

Answer 2

布洛赫警告不要致电
可重写的方法（第 17 项）来自
为继承而设计的类
让超类容易受到
子类所做的更改

他警告在构造函数中调用可重写的方法，而不是在其他方法中。

Answer 3

AbstractMapEntry#getKey 和 getValue 是抽象的（即未实现）的原因之一是 Map.Entry 是 Map< 的内部接口/代码>。 使用嵌套类/接口是 Java 实现组合的方式。 组合的想法是，组合的部分不是一流的概念。 相反，组成部分只有包含在整体中才有意义。 在本例中，组合部分是 Map.Entry，组合的根对象是 Map。 显然，表达的概念是一个Map有许多Map.Entry。

因此，AbstractMapEntry#getKey 和 getValue 的语义本质上取决于我们正在讨论的 Map 的实现。 您编写的普通旧 getter 实现对于 HashMap 来说效果很好。 它不适用于像 ConcurrentHashMap 这样需要线程安全的东西。 ConcurrentHashMap 的 getKey 和 getValue 实现很可能会创建防御性副本。 （建议自己查看源代码）。

不实现 getKey 和 getValue 的另一个原因是，实现 Map 的字符与那些本来不应该属于的字符（即 < code>Property）到完全不同的宇宙，从Map的直观实现（例如Provider、TabularDataSupport）。

总之，由于 API 设计的黄金法则，不实现 AbstractMapEntry#getKey 和 getValue：

如有疑问，请忽略它（请参阅此处）

Answer 4

1. 我没有看到任何原因

2. 允许实现定义如何存储键和值。