為什么要使用空的抽象類而不是接口？

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 ，我肯定會期望它是一個接口而不是一個抽象類。