Protegido en interfaces

¿Por qué todos los métodos están interfaceimplícitos en una definición public? ¿Por qué no permite un protectedmétodo?

Porque se supone que una interfaz significa "lo que puedes ver desde fuera de la clase". No tendría sentido agregar métodos no públicos.

Aunque la razón citada a menudo es que "las interfaces definen las API públicas", creo que es una simplificación excesiva. (Y también "huele" a lógica circular).

No tendría sentido tener interfaces que tuvieran una mezcla de modificadores de acceso; por ejemplo, en parte pública y en parte restringida a otras clases en el mismo paquete que la interfaz. De hecho, en algunos casos esto podría ser muy útil, en mi opinión.

En realidad, creo que la parte del razonamiento detrás de hacer que los miembros de una interfaz sean implícitamente públicos es que hace que el lenguaje Java sea más simple :

• Los miembros de la interfaz pública implícitamente son más fáciles de manejar para los programadores. ¿Cuántas veces ha visto código (clases) donde los modificadores de acceso al método se eligieron aparentemente al azar? Muchos programadores "normales" tienen dificultades para comprender la mejor forma de gestionar los límites de abstracción de Java ¹ . Agregar público / protegido / paquete-privado a las interfaces hace que sea aún más difícil para ellos.

• Los miembros de la interfaz pública implícitamente simplifican la especificación del lenguaje ... y, por lo tanto, la tarea para los escritores de compiladores de Java y las personas que implementan las API de Reflection.

La línea de pensamiento de que "las interfaces definen las API públicas" es posiblemente una consecuencia (o característica) de la decisión de simplificar el diseño del lenguaje ... no al revés. Pero en realidad, las dos líneas de pensamiento probablemente se desarrollaron en paralelo en la mente de los diseñadores de Java.

En cualquier caso, la respuesta oficial a la RFE en JDK-8179193 deja en claro que el equipo de diseño de Java decidió ² que permitir las protectedinterfaces agrega complejidad para un beneficio real mínimo. Felicitaciones a @skomisa por encontrar la evidencia .

La evidencia en la RFE resuelve el problema. Esa es la razón oficial por la que no se ha agregado.

^{1 - Por supuesto, los programadores de primera no tienen dificultad con estas cosas y pueden agradecer una paleta más rica de funciones de control de acceso. Pero, ¿qué sucede cuando su código se entrega a otra persona para que lo mantenga?}

^{2 - Puede que no esté de acuerdo con su decisión o con su razonamiento declarado, pero eso es discutible.}

Debo decir que esta pregunta ha sido reabierta por la introducción de métodos predeterminados en Java 8. El proyecto en el que estoy trabajando ahora es, similar a la naturaleza básica de una interfaz, destinado a abstraer la intención de la implementación.

Hay varios casos en los que podría simplificar drásticamente mi código con un método "protegido por defecto". Resulta que eso en realidad no funciona, ya que las interfaces aún se adhieren a la lógica de Java 7. Un método protegido normal no tiene ningún sentido especialmente, por las razones mencionadas anteriormente; pero si un método público predeterminado requiere un recurso de bajo nivel que probablemente no cambiará y puede ser proporcionado por un método protegido, me parece que tener un trabajo "protegido por defecto" no solo mantendría un código más limpio, sino que protegería a los usuarios futuros de abusos accidentales.

(Trágicamente, esto no cambia el hecho de que todavía necesito complicar demasiado mi código con resúmenes innecesarios; pero tengo la intención de poner una solicitud de función en Oracle).

Porque las interfaces definen API públicas. Todo lo que está protegido es un detalle interno que no pertenece a una interfaz.

Puede utilizar clases abstractas con métodos abstractos protegidos, pero las interfaces están restringidas a métodos públicos y campos finales estáticos públicos.

Quizás, porque es una interfaz , es decir, está ahí para decirles a los clientes lo que pueden hacer con las instancias, en lugar de decirles lo que no pueden hacer.

Creo firmemente que las interfaces deberían permitir métodos protegidos; ¿Quién dijo que las interfaces deben ser visibles para todos en todo el mundo? En cuanto a su punto de que podría confundir a los programadores "ordinarios" (léase: incompetentes): gran parte de la programación orientada a objetos se trata de estructurar adecuadamente objetos, clases, paquetes, etc., si un programador tiene dificultades para hacer todo eso correctamente, tiene una un problema mucho mayor. Java fue construido para ese tipo de cosas.

Varias respuestas aquí emplean un razonamiento circular para explicar por qué los métodos de interfaz no se pueden proteger: es porque tienen que ser públicos, ¡así que obviamente no se pueden proteger!

Eso no explica nada, pero afortunadamente alguien planteó una solicitud de mejora para métodos protegidos en interfaces como un error de JDK hace un par de años, lo que arroja algo de luz sobre el problema:

Métodos protegidos en interfaces: compartir entre paquetes

Dado que los modificadores son un poco limitados en Java, una forma de compartir métodos entre paquetes está restringida a métodos públicos. A veces es peligroso hacer público un método, pero debe ser debido a la falta de modificadores adecuados. Mi solución supera esta limitación.

La especificación del lenguaje java no permite actualmente el modificador protegido para métodos de interfaz. Podemos aprovechar este hecho y utilizar protegido para métodos de interfaz para esta nueva función.

Si un método de interfaz está marcado como protegido y la interfaz es implementada por una clase en otro paquete, el método no necesitaría ser público, pero también podría ser privado o al menos protegido por paquete. El método es visible, lo que sea que la clase declare que es y además visible en el paquete fuente de la interfaz (¿y subpaquetes?).

De esta manera podríamos compartir ciertos métodos en paquetes bien conocidos.

Y esta es la respuesta a esa solicitud de mejora, que se cerró con estado Won't fix:

Esta propuesta intenta resolver un problema de una manera que agrega complejidad y casos especiales con poca ganancia real. Una forma típica de resolver este problema es tener una clase privada que implemente una interfaz pública. Los métodos de implementación son públicos, pero están dentro de una clase privada, por lo que permanecen privados.

Una alternativa disponible a partir de Java 9 es hacer públicas las clases y los métodos, pero dentro de un módulo que tiene una exportación calificada a módulos "amigos" específicos en lugar de exportarse al público en general.

Entonces, las conclusiones autorizadas de ese informe de error son:

• La situación actual no va a cambiar; Es poco probable que las interfaces admitan protectedmétodos.
• La justificación para no admitir protectedmétodos en interfaces es que " agrega complejidad y casos especiales con poca ganancia real ".
• Desde Java 9, existe un enfoque alternativo para proporcionar acceso a los métodos a nivel de paquete. Utilice Java Platform Module System (JPMS) para " hacer públicos las clases y los métodos, pero dentro de un módulo que tiene una exportación calificada a módulos" amigos "específicos en lugar de exportarse al público en general ".

Dado que una clase de implementación debe implementar TODOS los métodos declarados en su interfaz, ¿qué pasaría si su clase de implementación estuviera en un paquete diferente?

Interfaz Si desea usar algo como lo que describió, continúe con clases abstractas o interfaces anidadas.

Un extracto del estilo de código sobre variables de interfaz, pero aún se aplica a los métodos:

Las variables de interfaz son implícitamente públicas porque las interfaces están destinadas a proporcionar una interfaz de programación de aplicaciones (API) que sea totalmente accesible para que los programadores de Java hagan referencia e implementen en sus propias aplicaciones. Dado que se puede usar una interfaz en paquetes de Java que son diferentes a los suyos, la visibilidad pública asegura que el código del programa pueda acceder a la variable.

Declarar subinterfaces internas es una buena práctica, pero no puede declarar sus métodos internos como protected técnicamente en una interfaz en Java.

Por supuesto, puede crear otra interfaz para uso interno que amplíe la interfaz pública:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

Puede usar la InternalInterfaceinterfaz dentro del paquete, pero debe aceptar cualquier subtipo de PublicInterface(en métodos públicos):

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

Fuera del paquete los usuarios pueden utilizarlo PublicInterfacesin problemas.

Por lo general, los programadores crean clases abstractas en situaciones similares. Sin embargo, en este caso perdemos los beneficios de la herencia múltiple.

El único escenario en el que tendría sentido es cuando desea restringir la visibilidad al mismo paquete. Todos los demás usos de protectedno son aplicables. Específicamente, los protectedmétodos se utilizan a menudo para proporcionar acceso a algunos detalles de implementaciones de nivel inferior para descendientes. Pero declarar eso en una interfaz no tiene sentido, ya que no hay una implementación de nivel inferior para exponer.

E incluso el escenario del paquete no es realmente de lo que se tratan las interfaces.

Para lograr lo que probablemente desee, necesita dos interfaces, una para uso interno y otra que exponga en la API pública. (Con el interno posiblemente, pero no necesariamente extendiendo al público). O, como otros señalaron, una superclase abstracta.

Los métodos protegidos siempre son accesibles por subclase solo si la subclase extiende la clase base.

En el caso de la interfaz, la subclase nunca extiende la interfaz. Implementa la interfaz.

Los métodos protegidos son accesibles a través de extender y no con implemento .

Las interfaces están destinadas a exponer métodos al mundo exterior . Por tanto, estos métodos son públicos por naturaleza. Sin embargo, si desea introducir abstracción dentro de la misma familia de clases , es posible crear otro nivel de abstracción entre su interfaz y la clase de implementación, es decir, una clase abstracta. A continuación se muestra un ejemplo.

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}