骨架实现与普通抽象类有何不同？答案

【问题标题】：How is a skeletal implementation different from an ordinary abstract class?骨架实现与普通抽象类有何不同？
【发布时间】：2012-06-24 21:52:32
【问题描述】：

在Effective Java 中，Joshua Bloch 更喜欢接口而不是抽象类。然而，他指出，每个接口都应该有一个框架实现。

我觉得骨架实现与抽象类几乎相同。这两个概念有何不同？

【问题讨论】：

【解决方案1】：

^{在重新阅读上述Effective Java中的部分后编辑}

According to this section of the book 一个骨架实现是一个抽象类。他推荐这种方法，因为在框架实现到位后，实现接口和选择性地覆盖方法变得微不足道，即使使用匿名类（正如他在书中所做的那样）。

^{上一个答案，为了连续性略有编辑}

从理论上讲，骨架实现可以是完整的实现，因此是具体的。然后它可以与composition 一起使用，因为它可以被实例化。而抽象类需要继承。

【讨论】：

【解决方案2】：

他的意思是你应该提供一个接口，以及一个实现该接口部分的抽象类：

public interface Foo {
    void bar();
    void baz();
}

private abstract class AbstractFoo implements Foo {
    ...
}

如果可以提供基本的、完整的实现，AbstractFoo 类甚至可能不是抽象的。但是，如果您需要一个 Foo 类，但不能扩展 AbstractFoo，则仍然可以使用接口。抽象类不提供此功能，因为您只能扩展一个类。

顺便说一句，这是在集合框架（由 Josh Bloch 创建）中完成的：Set 接口由AbstractSet 实现，List 接口由AbstractList 实现，等等。

【讨论】：

【解决方案3】：

接口/抽象类是 API 的一部分。

骨架实现是一个有效的具体class，但是一个有限/幼稚/糟糕的实现；对于（一个非常人为的）示例，Sorter 接口的骨架实现可能会实现 bubble sort - 您不想在生产应用程序中使用它，但它说明了如何实现接口

【讨论】：

【解决方案4】：

我觉得骨架实现几乎与抽象类。这两个概念有何不同？

对我来说，他们的意图不同。当我看到某个方法需要传入一个接口时，我知道实现取决于我。如果返回一个类，我不再确定。使用一个类不存在的接口只是一个含义。

此外，当我们想要传入的类已经是子类时，接受类作为参数的方法会引发冲突； Java 不支持多重继承。接口没有这个问题。

【讨论】：

【解决方案5】：

“骨架实现”是一个具体的类：您可以编译和测试它。

抽象类不是，你也不能；)

【讨论】：