poo - ¿Deberían declararse los métodos en una interfaz Java con o sin un modificador de acceso público?
modificadores de acceso poo (11)
A pesar del hecho de que esta pregunta se ha formulado hace mucho tiempo, pero creo que una descripción completa aclararía por qué no hay necesidad de usar un resumen público antes de los métodos y la final estática pública antes de las constantes de una interfaz.
En primer lugar, las interfaces se utilizan para especificar métodos comunes para un conjunto de clases no relacionadas para las que cada clase tendrá una implementación única. Por lo tanto, no es posible especificar el modificador de acceso como privado, ya que otras clases no pueden acceder a él para ser anulado.
En segundo lugar, aunque se pueden iniciar objetos de un tipo de interfaz, las clases implementan una interfaz y no la heredan. Y dado que una interfaz puede ser implementada (realizada) por diferentes clases no relacionadas que no están en el mismo paquete, el modificador de acceso protegido tampoco es válido. Así que para el modificador de acceso solo nos queda la opción pública.
En tercer lugar, una interfaz no tiene ninguna implementación de datos, incluidas las variables y los métodos de la instancia. Si hay una razón lógica para insertar métodos implementados o variables de instancia en una interfaz, entonces debe ser una superclase en una jerarquía de herencia y no una interfaz. Teniendo en cuenta este hecho, dado que no se puede implementar ningún método en una interfaz, todos los métodos en la interfaz deben ser abstractos.
Cuarto, la interfaz solo puede incluir constantes como sus miembros de datos, lo que significa que deben ser finales y, por supuesto, las constantes finales se declaran como estáticas para mantener solo una instancia de ellas. Por lo tanto, la final estática también es una necesidad para las constantes de interfaz.
Entonces, en conclusión, aunque el uso de resúmenes públicos antes de los métodos y la estática final pública antes de las constantes de una interfaz es válido, pero dado que no hay otras opciones, se considera redundante y no se utiliza.
¿Deberían declararse los métodos en una interfaz Java con o sin el modificador de acceso public ?
Técnicamente no importa, por supuesto. Un método de clase que implementa una interface siempre es public . Pero, ¿qué es una convención mejor?
Java en sí no es consistente en esto. Ver, por ejemplo, Collection vs. Comparable , o Future vs. ScriptEngine .
Con la introducción de modificadores private , static y default para los métodos de interfaz en Java 8/9, las cosas se complican y tiendo a pensar que las declaraciones completas son más legibles (necesita Java 9 para compilar):
public interface MyInterface {
//minimal
int CONST00 = 0;
void method00();
static void method01() {}
default void method02() {}
private static void method03() {}
private void method04() {}
//full
public static final int CONST10 = 0;
public abstract void method10();
public static void method11() {}
public default void method12() {}
private static void method13() {}
private void method14() {}
}
El JLS deja esto claro:
Se permite, pero se desaconseja por cuestión de estilo, especificar de manera redundante el modificador
publicy / oabstractpara un método declarado en una interfaz.
El modificador público debe omitirse en las interfaces de Java (en mi opinión).
Dado que no agrega ninguna información adicional, simplemente desvía la atención de las cosas importantes.
La mayoría de las guías de estilo recomendarán que lo dejes fuera, pero, por supuesto, lo más importante es ser coherente en tu base de código, y especialmente en cada interfaz. El siguiente ejemplo podría confundir fácilmente a alguien que no es 100% fluido en Java:
public interface Foo{
public void MakeFoo();
void PerformBar();
}
Es totalmente subjetivo. Omito el modificador public redundante, ya que parece un desorden. Como lo mencionaron otros, la consistencia es la clave de esta decisión.
Es interesante observar que los diseñadores de lenguaje C # decidieron imponer esto. Declarar un método de interfaz como público en C # es en realidad un error de compilación. Sin embargo, la coherencia probablemente no sea importante en todos los idiomas, así que supongo que esto no es directamente relevante para Java.
La razón de que los métodos en las interfaces sean públicos y abstractos por defecto me parece bastante lógica y obvia.
Un método en una interfaz es, por defecto, abstracto para forzar a la clase implementadora a proporcionar una implementación y es público por defecto, de modo que la clase implementadora tenga acceso para hacerlo.
Agregar esos modificadores en su código es redundante e inútil y solo puede llevar a la conclusión de que carece de conocimiento y / o comprensión de los fundamentos de Java.
Las personas aprenderán su interfaz a partir de la finalización del código en su IDE o en Javadoc, no de leer la fuente. Así que no tiene sentido poner "público" en la fuente, nadie está leyendo la fuente.
Prefiero omitirlo, leo en alguna parte que las interfaces son predeterminadas, public y abstract .
Para mi sorpresa, el libro - Head First Design Patterns , está usando public con declaración de interfaz y métodos de interfaz ... que me hicieron repensar una vez más y llegué a esta publicación.
De todos modos, creo que la información redundante debería ser ignorada.
Siempre escribo lo que usaría si no hubiera una interfaz y escribiera una implementación directa, es decir, usaría public .
Utilicé declarar métodos con el modificador public , porque hace que el código sea más legible, especialmente con el resaltado de sintaxis. Sin embargo, en nuestro último proyecto, usamos Checkstyle, que muestra una advertencia con la configuración predeterminada para public modificadores public en los métodos de interfaz, así que cambié a omitirlos.
Así que no estoy realmente seguro de qué es lo mejor, pero una cosa que realmente no me gusta es usar public abstract en los métodos de interfaz. Eclipse hace esto a veces al refactorizar con "Extraer interfaz".
Yo evitaría poner modificadores que se apliquen por defecto. Como se señaló, puede llevar a inconsistencias y confusión.
Lo peor que vi es una interfaz con métodos declarados abstract ...