来自：http : //www.artima.com/lejava/articles/designprinciples4.html

埃里希·伽玛（Erich Gamma）：即使十年之后，我仍然认为这是真的。继承是改变行为的一种很酷的方法。但是我们知道它很脆弱，因为子类可以轻松地对调用其重写的方法的上下文进行假设。基类和子类之间存在紧密的耦合，因为隐式上下文将在其中调用我插入的子类代码。合成具有更好的属性。通过将一些较小的东西插入较大的对象中，可以减少耦合，而较大的对象仅将较小的对象回调。从API的角度来看，定义可以覆盖的方法比定义可以调用的方法要强。

我不明白他的意思。有人可以解释一下吗？

承诺可以减少您将来的选择。发布方法意味着用户将调用它，因此您必须在不破坏兼容性的情况下删除此方法。如果您保留它private，他们将无法（直接）调用它，并且有一天您可以毫无问题地将其重构。因此，与不发布方法相比，发布方法是更强有力的承诺。发布一个可覆盖的方法是一个更加坚定的承诺。您的用户可以调用它，并且他们可以创建新类，其中该方法无法实现您想像的！

例如，如果发布清理方法，则只要用户记得最后一次调用此方法，就可以确保资源被正确地重新分配。但是，如果该方法是可重写的，则有人可以在子类中重写它，而不是调用super。结果，第三位用户可能会使用该类并导致资源泄漏，即使他们cleanup()在结尾处尽职尽责地调用了它！这意味着您不能再保证代码的语义，这是非常不好的事情。

从本质上讲，您不再可以依赖用户可重写方法中运行的任何代码，因为某些中间人可能会将其覆盖。这意味着您必须完全在private方法中实现清理例程，而无需用户的帮助。因此，通常最好只发布final元素，除非它们明确地被API用户覆盖。

如果发布一个正常函数，则会给出一个单边合同：
如果调用该函数会做什么？

如果发布回调，则还会给出一个单边合同：
何时以及如何调用它？

而且，如果您发布一个可重写的函数，那么它们会同时出现，因此您要提供一个双向合同：
何时调用它，如果调用它必须做什么？

即使您的用户没有滥用您的API（通过破坏他们的合同部分，这可能会花费巨大的检测成本），您也可以轻松地看到后者需要更多的文档，并且您记录的所有内容都是一项承诺，这限制了您的进一步选择。

违背这种双面合同上的一个例子是来自移动show和hide向setVisible(boolean)在java.awt.Component中。

Kilian Foth的答案非常好。我只想添加关于为什么这是一个问题的规范示例。想象一个整数Point类：

class Point2D {
    public int x;
    public int y;

    // constructor
    public Point2D(int theX, int theY) { x = theX; y = theY; }

    public int hashCode() { return x + y; }

    public boolean equals(Object o) {
        if (this == o) { return true; }
        if ( !(o instanceof Point2D) ) { return false; }

        Point2D that = (Point2D) o;

        return (x == that.x) &&
               (y == that.y);
    }
}

现在让我们将其子类化为3D点。

class Point3D extends Point2D {
    public int z;

    // constructor
    public Point3D(int theX, int theY, int theZ) {
        super(x, y); z = theZ;
    }

    public int hashCode() { return super.hashCode() + z; }

    public boolean equals(Object o) {
        if (this == o) { return true; }
        if ( !(o instanceof Point3D) ) { return false; }

        Point3D that = (Point3D) o;

        return super.equals(that) &&
               (z == that.z);
    }
}

超级简单！让我们使用我们的观点：

Point2D p2a = new Point2D(3, 5);
Point2D p2b = new Point2D(3, 5);
Point2D p2c = new Point2D(3, 7);

p2a.equals(p2b); // true
p2b.equals(p2a); // true
p2a.equals(p2c); // false

Point3D p3a = new Point3D(3, 5, 7);
Point3D p3b = new Point3D(3, 5, 7);
Point3D p3c = new Point3D(3, 7, 11);

p3a.equals(p3b); // true
p3b.equals(p3a); // true
p3a.equals(p3c); // false

您可能想知道为什么我要发布这样一个简单的示例。这是要抓住的地方：

p2a.equals(p3a); // true
p3a.equals(p2a); // FALSE!

当我们将2D点与等效的3D点进行比较时，我们得到了true，但是当我们逆转比较时，我们得到了false（因为p2a失败instanceof Point3D）。

结论

1. 通常可以以与超类期望它的工作方式不再兼容的方式在子类中实现方法。

2. 通常，不可能以与其父类兼容的方式在明显不同的子类上实现equals（）。

当您编写要允许人们继承的类时，对于每个方法的行为写一个契约是一个非常好的主意。更好的是，人们可以对覆盖方法的实现进行一系列的单元测试，以证明他们没有违反合同。几乎没有人这样做，因为它工作太多。但是，如果您在乎，那就是要做的事情。

精心阐述了合同的一个很好的例子比较。.equals()出于上述原因，只需忽略它所说的内容即可。下面是的比较如何能做到的事情为例.equals()不了。

笔记

1. Josh Bloch的“ Effective Java”项目8是此示例的来源，但Bloch使用ColorPoint而不是第三轴添加颜色，并使用double代替int。Odersky / Spoon / Venners基本上复制了Bloch的Java示例，并将其示例在线提供。

2. 有几个人反对此示例，因为如果您让父类知道有关子类的信息，则可以解决此问题。如果子类的数量足够少，并且父级知道所有子类，则为真。但是最初的问题是关于制作其他人将为其编写子类的API。在这种情况下，通常无法将父实现更新为与子类兼容。

奖金

比较器也很有趣，因为它可以解决正确实现equals（）的问题。更好的是，它遵循一种用于解决此类继承问题的模式：策略设计模式。Haskell和Scala让人兴奋的Typeclass也是Strategy模式。继承不是坏事，也不是错误的，只是棘手的事情。进一步阅读，请查阅Philip Wadler的论文：如何减少即席多态性

继承削弱封装

当发布允许继承的接口时，将大大增加接口的大小。每个可重写方法都可以替换，因此应将其视为提供给构造函数的回调。您的类提供的实现仅仅是回调的默认值。因此，应提供某种合同以表明对该方法的期望。很少发生这种情况，这是为什么将面向对象的代码称为易碎的主要原因。

下面是来自Java集合框架的真实（简化）示例，由Peter Norvig（http://norvig.com/java-iaq.html）提供。

Public Class HashTable{
    ...
    Public Object put(K key, V value){
        try{
            //add object to table;
        }catch(TableFullException e){
            increaseTableSize();
            put(key,value);
        }
    }
}

那么，如果我们将其子类化怎么办？

/** A version of Hashtable that lets you do
 * table.put("dog", "canine");, and then have
 * table.get("dogs") return "canine". **/

public class HashtableWithPlurals extends Hashtable {

    /** Make the table map both key and key + "s" to value. **/
    public Object put(Object key, Object value) {
        super.put(key + "s", value);
        return super.put(key, value);
    }
}

我们有一个错误：有时我们添加“ dog”，哈希表会获得“ dogss”的条目。原因是有人提供了实现Hashtable类的人员所期望的put的实现。

继承破坏可扩展性

如果允许您的类被子类化，那么您承诺不向您的类添加任何方法。否则，可以完成此操作而不会破坏任何内容。

当您向接口添加新方法时，从您的类继承的任何人都将需要实现这些方法。

如果要调用某个方法，则只需确保该方法正确运行即可。而已。做完了

如果要重写某个方法，则还必须仔细考虑该方法的范围：如果范围太大，子类通常将需要包含父方法的复制粘贴代码；如果它太小，则需要重写许多方法才能具有所需的新功能-这会增加复杂性和不必要的行数。

因此，父方法的创建者需要对将来如何重写该类及其方法进行假设。

但是，作者在引用的文本中讨论的是另一个问题：

但是我们知道它很脆弱，因为子类可以轻松地对调用其重写的方法的上下文进行假设。

考虑a通常从method调用的method b，但在某些罕见和非显而易见的情况下，可以从method 调用c。如果重写方法的作者忽略了该c方法及其对的期望a，则很明显事情会出错。

因此，更重要的是，a要明确，明确地定义并且有据可查，“做一件事情并做得很好” —比仅设计为被调用的方法要重要得多。