Respetuosamente no estoy de acuerdo con la mayoría de los carteles anteriores (lo siento, modélame si quieres :-))
Primero, la respuesta de "una sola superclase" es coja. Cualquiera que me diera esa respuesta en una entrevista sería contestado rápidamente con "C ++ existía antes de que Java y C ++ tuvieran múltiples súper clases. ¿Por qué crees que James Gosling solo permitió una superclase para Java?"
Comprenda la filosofía detrás de su respuesta; de lo contrario, usted es un brindis (al menos si lo entrevisto).
En segundo lugar, las interfaces tienen múltiples ventajas sobre las clases abstractas, especialmente cuando se diseñan interfaces. El más grande es no tener una estructura de clase particular impuesta a la persona que llama de un método. No hay nada peor que tratar de usar una llamada de método que exija una estructura de clase particular. Es doloroso y embarazoso. Usando una interfaz cualquier cosa puede pasarse al método con un mínimo de expectativas.
Ejemplo:
public void foo(Hashtable bar);
vs.
public void foo(Map bar);
Para el primero, la persona que llama siempre tomará su estructura de datos existente y la incluirá en un nuevo Hashtable.
En tercer lugar, las interfaces permiten que los métodos públicos en los ejecutores de la clase concreta sean "privados". Si el método no se declara en la interfaz, entonces el método no puede ser utilizado (o mal utilizado) por las clases que no tienen ningún negocio que utilice el método. Lo que me lleva al punto 4 ...
En cuarto lugar, las interfaces representan un contrato mínimo entre la clase implementadora y el que llama. Este contrato mínimo especifica exactamente cómo el implementador de hormigón espera ser utilizado y no más. La clase de llamada no puede usar ningún otro método no especificado por el "contrato" de la interfaz. El nombre de la interfaz en uso también saborea la expectativa del desarrollador de cómo deberían usar el objeto. Si un desarrollador se pasa a
public interface FragmentVisitor {
public void visit(Node node);
}
El desarrollador sabe que el único método que pueden llamar es el método de visita. No se distraen con los métodos brillantes y brillantes de la clase concreta con los que no deben meterse.
Por último, las clases abstractas tienen muchos métodos que realmente solo están presentes para las subclases que se utilizarán. Por lo tanto, las clases abstractas tienden a parecer un poco desastrosas para el desarrollador externo, no hay una guía sobre qué métodos están destinados a ser utilizados por código externo.
Sí, por supuesto, algunos de esos métodos se pueden proteger. Sin embargo, lamentablemente los métodos protegidos también son visibles para otras clases en el mismo paquete. Y si el método de una clase abstracta implementa una interfaz, el método debe ser público.
Sin embargo, al utilizar las interfaces, todas estas entrañas que están colgando cuando se mira la clase abstracta o la clase concreta se guardan de forma segura.
Sí, sé que, por supuesto, el desarrollador puede usar algún conocimiento "especial" para enviar un objeto a otra interfaz más amplia o a la propia clase concreta. Pero tal elenco viola el contrato esperado, y el desarrollador debe ser abofeteado con un salmón.