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

Question

I use GWT and the Place & Activity mechanism.

It's really sad that Place is a class because my custom place can't extend another class.

When I look at the Place code, I see the following :

public abstract class Place {

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

}

Seeing that, the Place can be an interface. Is there a good reason that GWT team has chosen to make Place an abstract class instead of an interface ?

And to generalize : is there a good reason to create really empty abstract class vs interface ?

Answer 1

In general I would not define an empty abstract class

However, when I would expect some members in the future, I may decide to use abstract class instead of interface

"class" means: this IS A

"interface" means: this SUPPORTS

For "Place" I could really see both with a little intuitive preference for class

Answer 2

Is there a good reason that GWT team has chosen to make Place an abstract class instead of an interface ?

I can't think of one. But to be realistic, complaining about it on SO is not going to achieve anything.

And to generalize : is there a good reason to create really empty abstract class vs interface ?

Hypothetically, you might do this to ensure that there is a single common base class for future anticipated requirements ... or for some other reason.

But generally speaking it is a bad idea ... IMO.

(Of course, things like this often happen for historical reasons; eg the abstract class may have had more members in the past that have since been removed.)

Answer 3

I can't really tell for the Place (though I have a few ideas, see below), but it was discussed for the Activity : https://groups.google.com/d/topic/google-web-toolkit-contributors/V8rhZHiXFRk/discussion

As far as we could go in history, Place has always been an abstract class in GWT (and FWIW, the NOWHERE place was added long after ; note that this commit references a Wave –soon to disappear from the internet– where we can see interface Place so it was an interface at some point in time while they designed the API).

Given that the PlaceHistoryGenerator (used when you GWT.create() a PlaceHistoryMapper ) looks at the places hierarchy, having an abstract class cuts down a whole lot of edge cases!
Imagine your PlaceHistoryMapper references a PlaceTokenizers<Foo> and PlaceTokenizer<Bar> and you have a class FooBar implements Foo, Bar { } , which tokenizer should be used? If you don't reference the FooBar class explicitly in your PlaceHistoryMapper , the generator won't see it (or rather won't look at it), so which kind of code should it generate? And keep in mind that we all want determinism, so the generated code should always be the same. Using a class, the generator can order them by their inheritance tree (from the most specific –most derived– to the least specific), and can safely assume that 2 places whose classes have no particular inheritance relationship are totally distinct, so they can be checked ( instanceof in the generated code) in any order and still provide a stable result ⇒ determinism.

Disclaimer: I'm the one who reported the ordering issue and then provided the patch , but Place was already a class.

Answer 4

I can't speak for the GWT team, but the only reason there seems to be for this abstract class is to force a definition of NOWHERE.

As you've found out, using abstract classes in this way forces you in to a class hierarchy that may not be appropriate for your business model. Therefore, in general, if the abstract class were really completely empty, there would be no purpose at all.

This example is especially strange though because an interface is a contract. The GWT Place has no interface and therefore no contract. Their javadoc states:

"Represents a bookmarkable location in an app"

I would have expected some contract defined to deal with this scenario. What methods would a bookmarkable location require? If this is just a marker, like Serializable , I would definitely expect it to be an interface rather than an abstract class.