¿Por qué usar una clase abstracta vacía en lugar de una interfaz?

Uso GWT y el lugar & Mecanismo de actividad.¿Por qué usar una clase abstracta vacía en lugar de una interfaz?

Es realmente triste que Place sea una clase porque mi lugar personalizado no puede extender otra clase.

Cuando miro el código de lugar, ver lo siguiente:

public abstract class Place { 

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

}

Al ver esto, el lugar puede ser una interfaz. ¿Hay alguna buena razón por la que el equipo de GWT haya decidido que Place sea una clase abstracta en lugar de una interfaz?

Y para generalizar: ¿hay alguna buena razón para crear una clase abstracta realmente vacía frente a la interfaz?

Fuente

2012-04-12 Jerome Cance

Las interfaces también pueden tener constantes, por lo que la constante 'NOWHERE' no afecta la decisión de si debe ser una interfaz o una clase abstracta. –

¿Por qué el voto a favor? –

@Christopher: tienes razón. Edito mi publicación. Para el invitado que votó negativamente: por favor dame una pista para mejorar mi pregunta, no entiendo por qué me has votado negativamente. –

No puedo realmente decir para el Place (aunque tengo algunas ideas, véase más adelante), pero fue discutido por el Activity: https://groups.google.com/d/topic/google-web-toolkit-contributors/V8rhZHiXFRk/discussion

Por lo que podríamos ir en la historia, Place tiene always been una clase abstracta en GWT (y FWIW, el lugar NOWHERE se agregó long after; tenga en cuenta que este compromiso hace referencia a una onda -una vez para desaparecer de Internet- donde podemos ver interface Place por lo que era una interfaz en algún momento mientras diseñaron el API).

Dado que el PlaceHistoryGenerator (utilizado cuando GWT.create() a PlaceHistoryMapper) mira la jerarquía de lugares, tener una clase abstracta reduce un montón de casos extremos.
Imagine que su PlaceHistoryMapper hace referencias a PlaceTokenizers<Foo> y PlaceTokenizer<Bar> y tiene un class FooBar implements Foo, Bar { }, ¿qué tokenizador se debe usar? Si no hace referencia explícitamente a la clase FooBar en su PlaceHistoryMapper, el generador no lo verá (o más bien no lo verá), entonces, ¿qué tipo de código debería generar? Y tenga en cuenta que todos queremos el determinismo, por lo que el código generado siempre debe ser el mismo. Usando una clase, el generador puede ordenarlos por su árbol de herencia (del más específico -más derivado- al menos específico), y puede asumir con seguridad que 2 lugares cuyas clases no tienen una relación de herencia particular son totalmente distintas, por lo que pueden ser comprobado (instanceof en el código generado) en cualquier orden y todavía proporciona un resultado estable ⇒ determinismo.

responsabilidad: yo soy el que reported la emisión de pedidos y luego provided the patch, pero Place ya era una clase.

Fuente

2012-04-12 16:36:49

gracias por su respuesta, esta es la más clara y razonada. Lo valido –

En general no me definir una clase abstracta vacío

Sin embargo, cuando yo esperaría que algunos miembros en el futuro, puede decidir utilizar clase abstracta en lugar de la interfaz

"clase" significa: este ES uN

"interfaz" significa: esto apoya

por "Lugar" realmente podría ver tanto con un poco de preferencia intuitiva para la clase

Fuente

2012-04-12 12:03:22

¿quiere decir "esperar algunos objetos" cuando dice "esperar algunos miembros"? –

@Aditya Naidu No, me refiero a los métodos de miembros o campos de miembros –

¿Hay alguna buena razón por la que el equipo de GWT haya decidido que Place sea una clase abstracta en lugar de una interfaz?

No puedo pensar en una. Pero para ser realista, quejarse de eso en SO no va a lograr nada.

Y para generalizar: ¿hay alguna buena razón para crear una clase abstracta realmente vacía frente a la interfaz?

Hipotéticamente, puede hacer esto para asegurarse de que existe una única clase de base común para futuros requisitos anticipados ... o por algún otro motivo.

Pero, en general, es una mala idea ... IMO.

(Por supuesto, este tipo de cosas suceden a menudo por razones históricas;. Por ejemplo, la clase abstract puede haber tenido más miembros en el pasado que han sido retirados)

Fuente

2012-04-12 12:07:06

Gracias por responder, no me quejaba, solo intentaba entender porque creo que el equipo de GWT generalmente elige un buen diseño y este me molesta. –

Nadie es perfecto. No te preocupes por eso –

+1 por las razones históricas ... es fácil criticar un diseño cuando no se comprende el historial (y las compensaciones que se hicieron para cumplir varios requisitos). – David

No puedo hablar por el equipo de GWT, pero la única razón que parece haber para esta clase abstracta es forzar una definición de NADA.

Como ha descubierto, el uso de clases abstractas de esta manera lo lleva a una jerarquía de clases que puede no ser apropiada para su modelo de negocio. Por lo tanto, en general, si la clase abstracta estuviera realmente completamente vacía, no tendría ningún propósito.

Este ejemplo es especialmente extraño porque una interfaz es un contrato. El GWT Place no tiene interfaz y, por lo tanto, no tiene contrato.Sus estados javadoc:

"representa una ubicación bookmarkable en una aplicación"

lo que habría esperado alguna contrato definido para hacer frente a este escenario. ¿Qué métodos requeriría una ubicación marcada? Si esto es solo un marcador, como Serializable, definitivamente esperaría que fuera una interfaz en lugar de una clase abstracta.

Fuente

2012-04-12 12:25:15

¿Por qué usar una clase abstracta vacía en lugar de una interfaz?

Respuesta

Cuestiones relacionadas