¿Deben declararse los métodos en una interfaz Java con o sin un modificador de acceso público?

¿Deben 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 mejor convención?

Java en sí no es consistente en esto. Ver, por ejemplo, Collection vs. Comparable , o Future vs. ScriptEngine .

El JLS lo aclara:

Está permitido, pero desaconsejado como una cuestión de estilo, especificar redundantemente el modificador public y / o abstract para un método declarado en una interfaz.

El modificador público debe omitirse en las interfaces Java (en mi opinión).

Como 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 le recomendarán que lo deje de lado, pero, por supuesto, lo más importante es ser coherente en toda su base de código, y especialmente para 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(); } 

A pesar de que esta pregunta se ha formulado hace mucho tiempo, creo que una descripción exhaustiva aclararía por qué no es necesario utilizar el resumen público antes de los métodos y el final estático público antes de las constantes de una interfaz.

En primer lugar, las interfaces se usan para especificar métodos comunes para un conjunto de clases no relacionadas para las cuales cada clase tendrá una implementación única. Por lo tanto, no es posible especificar el modificador de acceso como privado ya que no se puede acceder por otras clases para que se anule.

En segundo lugar, aunque uno puede iniciar objetos de un tipo de interfaz, las clases que lo implementan y no heredan realizan una interfaz. 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. Entonces, para el modificador de acceso solo nos queda una opción pública.

En tercer lugar, una interfaz no tiene ninguna implementación de datos que incluya las variables y métodos de 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.

En cuarto lugar, la interfaz solo puede incluir constante 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 estática final también es imprescindible para las constantes de interfaz.

Por lo tanto, en conclusión, aunque se utiliza el resumen público antes de los métodos y el final estático público antes de que las constantes de una interfaz sean válidas, dado que no hay otras opciones, se considera redundante y no se utiliza.

Evitaría poner modificadores que se aplican por defecto. Como se señaló, puede provocar incoherencia y confusión.

Lo peor que vi es una interfaz con métodos declarados abstract

Usé declarar métodos con el modificador public , porque hace que el código sea más legible, especialmente con el resaltado de syntax. Sin embargo, en nuestro último proyecto, utilizamos 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 seguro de qué es lo mejor, pero una cosa que realmente no me gusta es utilizar public abstract sobre métodos de interfaz. Eclipse hace esto a veces cuando se refactoriza con “Extract Interface”.

Siempre escribo lo que usaría si no hubiera interfaz y estuviera escribiendo una implementación directa, es decir, usaría public .

El motivo de que los métodos en las interfaces sean por defecto públicos y abstractos parece bastante lógico y obvio para mí.

Un método en una interfaz es por abstracción por defecto para forzar a la clase implementadora a proporcionar una implementación y es público por defecto para 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 usted carece de conocimiento y / o comprensión de los fundamentos de Java.

Prefiero omitirlo, leo en alguna parte que las interfaces son por defecto, public y abstract .

Para mi sorpresa, el libro Head First Design Patterns usa public con statement de interfaz y métodos de interfaz … eso me hizo reconsiderar una vez más y me encontré en esta publicación.

De todos modos, creo que la información redundante debe ser ignorada.

Con la introducción de modificadores private , static y default para los métodos de interfaz en Java 8/9, las cosas se vuelven más complicadas y tiendo a pensar que las declaraciones completas son más legibles (necesita Java 9 para comstackrse):

 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() {} } 

Es totalmente subjetivo. Omito el modificador public redundante, ya que parece desorden. Como lo mencionaron otros, la consistencia es la clave de esta decisión.

Es interesante observar que los diseñadores del lenguaje C # decidieron hacer cumplir esto. Declarar un método de interfaz como público en C # es en realidad un error de comstackción. Sin embargo, la consistencia probablemente no es importante en todos los idiomas, así que supongo que esto no es realmente relevante para Java.

La gente aprenderá su interfaz desde la finalización del código en su IDE o en Javadoc, no desde la lectura de la fuente. Entonces no tiene sentido poner “público” en la fuente, nadie está leyendo la fuente.