为什么要使用空的抽象类而不是接口？

Question

我使用GWT和Place＆Activity机制。

Place是一个类真的很难过，因为我的自定义位置不能扩展另一个类。

当我查看Place代码时，我看到以下内容：

public abstract class Place {

  /**
   * The null place.
   */
  public static final Place NOWHERE = new Place() {
  };

}

看到这个，Place可以是一个界面。 有没有一个很好的理由让GWT团队选择将Place放置为抽象类而不是接口？

并概括：是否有充分的理由创建真正空的抽象类vs接口？

Answer 1

一般来说，我不会定义一个空的抽象类

但是，当我希望将来有些成员时，我可能决定使用抽象类而不是接口

“阶级”是指：这是一个

“界面”的意思是：这个支持

对于“地方”，我真的可以看到两者都有一点点直观的偏好

Answer 2

有没有一个很好的理由让GWT团队选择将Place放置为抽象类而不是接口？

我想不出一个。 但实际上，在SO上抱怨它并不会有任何成就。

并概括：是否有充分的理由创建真正空的抽象类vs接口？

假设您可以这样做以确保存在单个公共基类以用于未来预期的需求......或者出于某种其他原因。

但总的来说这是一个坏主意...... IMO。

（当然，这样的事情经常因历史原因而发生;例如， abstract类过去可能有更多的成员被删除了。）

Answer 3

我无法真正说出这个Place （虽然我有一些想法，见下文），但是对于Activity进行了讨论： https ： //groups.google.com/d/topic/google-web-toolkit-contributors / V8rhZHiXFRk /讨论

就历史而言， Place 一直是 GWT中的一个抽象类（而FWIW， NOWHERE地方很久就被添加了;注意这个提交引用了一个Wave -soon从互联网上消失 - 我们可以看到interface Place所以它是在某个时间点的接口，而他们设计的API）。

鉴于PlaceHistoryGenerator （当您使用PlaceHistoryGenerator （ GWT.create() PlaceHistoryMapper ）查看位置层次结构，具有抽象类会减少大量边缘情况！
想象一下你的PlaceHistoryMapper引用了PlaceTokenizers<Foo>和PlaceTokenizer<Bar> ，你有一个class FooBar implements Foo, Bar { } ，应该使用哪个tokenizer？ 如果不引用FooBar类直接在您的PlaceHistoryMapper ，发电机不会看到它（或者更确切地说，不会看的话），所以这类型的代码应该是产生？ 请记住，我们都需要确定性，因此生成的代码应该始终相同。 使用类，生成器可以通过它们的继承树（从最特定的派生到最不具体）对它们进行排序，并且可以安全地假设其中没有特定继承关系的2个地方是完全不同的，所以它们可以是以任何顺序检查（生成的代码中的instanceof ）并仍然提供稳定的结果⇒确定性。

免责声明：我是报告订购问题然后提供补丁的人 ，但Place已经是一个类。

Answer 4

我不能代表GWT团队，但这个抽象类似乎唯一的原因是强制定义NOWHERE。

正如您所知，以这种方式使用抽象类会强制您进入可能不适合您的业务模型的类层次结构。 因此，一般来说，如果抽象类真的完全是空的，那么就没有任何目的。

这个例子特别奇怪，因为接口是契约。 GWT Place没有接口，因此没有合同。 他们的javadoc说：

“代表应用中的可收藏位置”

我本来期望定义一些合同来处理这种情况。 可收藏的位置需要哪些方法？ 如果这只是一个标记，比如Serializable ，我肯定会期望它是一个接口而不是一个抽象类。