En Java efectiva, Joshua Bloch favorece las interfaces en lugar de las clases abstractas. Sin embargo, señala que una implementación esquelética debería venir con cada interfaz.¿En qué se diferencia una implementación esquelética de una clase abstracta ordinaria?
Creo que una implementación de esqueleto es casi lo mismo que una clase abstracta. ¿Cómo difieren estos dos conceptos?
Editado después de volver a leer la sección mencionada en Effective Java
According to this section of the book una implementación esquelética es un resumen clase. Él recomienda este enfoque porque, después de una implementación esquemática, resulta trivial implementar la interfaz y anular selectivamente los métodos, incluso con una clase anónima (como hace en su libro).
respuesta anterior, ligeramente editado para la continuidad
Una implementación del esqueleto podría ser teóricamente una implementación completa y por lo tanto el hormigón. Luego podría usarse con composition, ya que se puede crear una instancia. Mientras que las clases abstractas requieren herencia.
Una "implementación del esqueleto" es una clase concreta: puede compilarla y probarla.
Una clase abstracta no es, y no se puede;)
-1 Puede compilar todas las clases formadas correctamente. La implementación esquelética es una clase abstracta. –
Dude, una "implementación esquelética" NO es necesariamente una clase abstracta. – paulsm4
Bajé tu respuesta principalmente por "puedes compilar". Es una clase abstracta en el libro referido. A eso me refería. –
La clase de interfaz/resumen es parte de la API.
La implementación del esqueleto es un hormigón válido class, pero una implementación limitada/ingenua/deficiente; para un ejemplo (muy artificial), una implementación esquemática de una interfaz Sorter podría implementar bubble sort - no querría usarla en una aplicación de producción, pero ilustra cómo se podría implementar la interfaz
Lo que quiere decir es que usted debe proporcionar una interfaz y una clase abstracta aplicar partes de esta interfaz:
public interface Foo {
void bar();
void baz();
}
private abstract class AbstractFoo implements Foo {
...
}
La clase AbstractFoo pueden incluso no ser abstracta si es posible proporcionar una implementación básica, completa. Pero si necesita una clase que sea Foo, pero no puede extender AbstractFoo, aún es posible con una interfaz. Una clase abstracta no proporciona esta capacidad, ya que solo puede extender una clase.
Por cierto, esto es lo que se hace en el marco de las colecciones (que Josh Bloch creado): la interfaz Set es implementado por AbstractSet, la interfaz List es implementado por AbstractList, etc.
Siento que una la implementación esquelética es casi la misma que la clase abstracta . ¿Cómo difieren estos dos conceptos?
Para mí, difieren en intento.Cuando veo que algún método espera que se transfiera una interfaz, sé que la implementación depende de mí. Si se devuelve una clase, ya no estoy seguro. Simplemente hay un que significa para el uso de una interfaz que no existe para una clase.
Además, los métodos que aceptan clases para argumentos invitan a conflictos cuando la clase que queremos pasar es ya una subclase; Java no es compatible con herencia múltiple. Las interfaces no tienen este problema.
Para _every_ interface? ¿Podría dar una referencia de página de esta declaración? – Puce