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

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/讨论

\n\n

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

\n\n

鉴于（当您aPlaceHistoryGenerator时使用）查看位置层次结构，拥有一个抽象类可以减少很多边缘情况！\n想象一下您的引用 a和您有一个，应该使用哪个标记器？如果您没有在 中显式引用该类，则生成器将看不到它（或者更确切地说不会查看它），那么它应该生成哪种类型的代码？请记住，我们都想要确定性，因此生成的代码应该始终相同。使用类，生成器可以按继承树对它们进行排序（从最具体的 \xe2\x80\x93 最派生的 \xe2\x80\x93 到最不具体的），并且可以安全地假设 2 个位置的类没有特定的继承关系是完全不同的，因此可以以任何顺序检查它们（在生成的代码中），并且仍然提供稳定的结果 \xe2\x87\x92 确定性。GWT.create()PlaceHistoryMapper
PlaceHistoryMapperPlaceTokenizers<Foo>PlaceTokenizer<Bar>class FooBar implements Foo, Bar { }FooBarPlaceHistoryMapperinstanceof

\n\n

免责声明：我是报告订购问题并提供补丁的人，但Place已经是一堂课了。

\n