Perché utilizzare una classe astratta vuota anziché un'interfaccia?

Question

Uso GWT e il meccanismo di attività Place &.

È davvero triste che Place sia una classe perché il mio posto personalizzato non può estendere un'altra classe.

Quando guardo il codice posto, compaiono i seguenti:

public abstract class Place { 

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

} 

Vedendo questo, il posto può essere un interfaccia. C'è una buona ragione per cui il team di GWT ha scelto di rendere Place una classe astratta invece di un'interfaccia?

E per generalizzare: c'è una buona ragione per creare un'interfaccia vs class astratta davvero vuota?

Answer 1

Non posso davvero dire per il Place (anche se ho un paio di idee, vedi sotto), ma se ne è parlato per la Activity: https://groups.google.com/d/topic/google-web-toolkit-contributors/V8rhZHiXFRk/discussion

Per quanto potremmo andare nella storia, ha Placealways been una classe astratta in GWT (e FWIW, è stata aggiunta la posizione NOWHERElong after; notare che questo commit fa riferimento a un suono di Wave che scompare da Internet, dove è possibile vedere interface Place quindi è stata un'interfaccia ad un certo punto nel tempo mentre hanno progettato il API).

Dato che lo PlaceHistoryGenerator (utilizzato quando si GWT.create() a PlaceHistoryMapper) esamina la gerarchia dei luoghi, con una classe astratta riduce un sacco di casi limite!
Immaginate i vostri riferimenti PlaceHistoryMapper a PlaceTokenizers<Foo> e PlaceTokenizer<Bar> e avete uno class FooBar implements Foo, Bar { }, quale tokenizzatore dovrebbe essere usato? Se non si fa riferimento esplicitamente alla classe FooBar nel proprio PlaceHistoryMapper, il generatore non la vedrà (o piuttosto non la guarderà), quindi quale tipo di codice dovrebbe generare? E ricorda che tutti noi vogliamo il determinismo, quindi il codice generato dovrebbe essere sempre lo stesso. Usando una classe, il generatore può ordinarli per il loro albero di ereditarietà (dal più specifico al più specifico al meno specifico) e può tranquillamente presumere che 2 luoghi le cui classi non abbiano particolari relazioni ereditarie siano totalmente distinti, quindi possono essere controllato (instanceof nel codice generato) in qualsiasi ordine e ancora fornire un risultato stabile ⇒ determinismo.

Disclaimer: io sono colui che reported la questione ordinazione e poi provided the patch, ma Place era già una classe.

Answer 2

In generale non mi definirei una classe astratta vuoto

Tuttavia, quando mi sarei aspettato alcuni membri in futuro, potrei decidere di utilizzare classe astratta anziché un'interfaccia

"classe": questo E 'uN

"interfaccia" significa: questo sostiene

per "Place" ho potuto davvero vedere sia con un po' di preferenza intuitiva per la classe

Answer 3

C'è una buona ragione per cui il team di GWT ha scelto di creare una classe astratta anziché un'interfaccia?

Non riesco a pensare a uno. Ma per essere realistici, lamentarsi su SO non significa ottenere nulla.

E per generalizzare: c'è una buona ragione per creare un'interfaccia vs class astratta veramente vuota?

Ipoteticamente, si potrebbe fare questo per garantire che ci sia una singola classe di base comune per i requisiti previsti in futuro ... o per qualche altro motivo.

Ma in generale è una cattiva idea ... IMO.

(Naturalmente, le cose come questo accada spesso per ragioni storiche,. Ad esempio la classe abstract possa aver avuto più membri in passato che da allora sono stati rimossi)

Answer 4

non posso parlare per la squadra GWT, ma l'unica ragione per cui sembra che ci sia questa classe astratta è forzare una definizione di NOWHERE.

Come hai scoperto, l'uso di classi astratte in questo modo ti costringe a una gerarchia di classi che potrebbe non essere appropriata per il tuo modello di business. Quindi, in generale, se la classe astratta fosse veramente completamente vuota, non ci sarebbe assolutamente alcuno scopo.

Questo esempio è particolarmente strano anche perché un'interfaccia è un contratto. Il GWT Place non ha interfaccia e quindi nessun contratto.I loro stati Javadoc:

"rappresenta una posizione segnalibro in un app"

mi sarei aspettato un po 'contratto definito a che fare con questo scenario. Quali metodi richiederebbe una posizione segnalibro? Se questo è solo un marker, come Serializable, mi aspetterei sicuramente che fosse un'interfaccia piuttosto che una classe astratta.