Why use an empty abstract class instead of an interface?

Question

I use GWT and the Place and Activity mechanism.

It’s very sad that Place is a class, because my custom place cannot 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 this, a place can be an interface. Is there a good reason the GWT team chose a place for an abstract class instead of an interface?

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

Answer 1

I can’t say for Place (although I have a few ideas, see below), but it was discussed for 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, NOWHERE place was added long after , note that this commit refers to Wave-mess to disappear from the Internet, where we can see the interface Place . so it was an interface at some point in time when they were designing the API).

Given that a PlaceHistoryGenerator (used when you GWT.create() a PlaceHistoryMapper ) looks at a hierarchy of places, having an abstract class reduces the mass of edge cases!
Imagine that your PlaceHistoryMapper links are PlaceTokenizers<Foo> and PlaceTokenizer<Bar> and you have the class FooBar implements Foo, Bar { } , which tokenizer should be used? Unless you reference the FooBar class explicitly in your PlaceHistoryMapper , the generator will not see it (or, rather, will not look at it), and what 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 arrange them according to the inheritance tree (from the most specific - from the highest to the least specific) and can safely assume that the 2 places whose classes do not have a special inheritance relationship are completely different, so they can be ( instanceof in the generated code) in any order and yet provide a stable result ⇒ determinism.

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

Answer 2

In general, I would not define an empty abstract class

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

"class" means: this is IS A

"interface" means: it is SUPPORT

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

Answer 3

Is there a good reason the GWT team chose a place for an abstract class instead of an interface?

I can’t think of one thing. But to be realistic, complaining about it, SO will not achieve anything.

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

Hypothetically, you can do this to make sure that there is one common base class for future expected requirements ... or for some other reason.

But, generally speaking, this is a bad idea ... IMO.

(Of course, such things often happen for historical reasons, for example, the abstract class may have had more members in the past that were removed.)

Answer 4

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

As you have learned, using abstract classes this way leads you to a class hierarchy that might not be suitable for your business model. Therefore, generally speaking, if the abstract class was really completely empty, there would be no purpose.

This example is particularly strange, although the interface is a contract. GWT Place has no interface and therefore no contract. Their javadoc states:

"Represents a place for bookmarks in the application"

I was expecting some kind of contract to be defined to solve this scenario. What methods would be required for bookmarking? If this is just a marker, like Serializable , I would definitely expect it to be an interface rather than an abstract class.