java - interfaces - porque usar lambda aws
Protegido en Interfaces (13)
¿Por qué todos los métodos en una definición de interface implícitamente public ? ¿Por qué no permite un método protected ?
Aunque la razón citada a menudo es que "las interfaces definen API públicas", creo que es una simplificación excesiva. (Y también "huele" a lógica circular).
Una interfaz anidada puede protegerse o ser privada, y si ese es el caso, no define una interfaz pública en absoluto.
No tendría sentido tener interfaces que tengan una mezcla de modificadores de acceso; por ejemplo, parcialmente público y parcialmente restringido a otras clases en el mismo paquete que la interfaz. De hecho, en algunos casos esto podría ser útil, IMO.
En realidad, creo que la parte del razonamiento para hacer que los miembros de una interfaz sean implícitamente públicos es que hace que Java sea más simple :
Los miembros de la interfaz implícitamente públicos son más fáciles de tratar para los programadores. ¿Cuántas veces has visto código (clases) donde los modificadores de acceso al método fueron elegidos aparentemente al azar? Muchos programadores "ordinarios" tienen dificultades para entender la mejor forma de gestionar los límites de abstracción de Java 1 . Agregar public / protected / package a interfaces lo hace aún más difícil para ellos.
Los miembros de la interfaz implícitamente públicos simplifican la especificación del lenguaje ... y de ahí la tarea para los escritores del compilador de Java y las personas que implementan las API de Reflection.
Esta línea de pensamiento hace que las "interfaces definen API públicas" una consecuencia (o característica) del diseño del lenguaje ... y no al revés. En realidad, las dos líneas de pensamiento probablemente se desarrollaron en paralelo en las mentes de los diseñadores de Java.
1 - Por supuesto, los programadores top-gun no tienen dificultad con estas cosas, y pueden dar la bienvenida a una paleta más rica de funciones de control de acceso. Pero, ¿qué sucede cuando su código se entrega a otra persona para mantener?
Creo firmemente que las interfaces deben 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 OOP se trata de estructurar adecuadamente los objetos, clases, paquetes, etc., si un programador tiene dificultades para hacer todo eso correctamente, tiene un problema mucho más grande. Java fue creado para ese tipo de cosas.
Dado que una clase implementadora debe implementar TODOS los métodos declarados en su interfaz, ¿qué pasaría si su clase implementadora estuviera en un paquete diferente?
Declarar subinterfaces internas es una buena práctica, pero no se pueden declarar técnicamente sus métodos internos como protected en una interfaz en Java.
Por supuesto, puede crear otra interfaz para uso interno que amplíe la interfaz pública:
public interface YourPublicInterface {
public void doThing1();
public void doThing2();
public void doThing3();
interface Internal extends YourPublicInterface {
void doAnyInternalThing1();
void doAnyInternalThing2();
}
}
Puede usar la interfaz Internal dentro del paquete, pero debe aceptar cualquier subtipo de YourPublicInterface (en métodos públicos):
public class AClassInYourPackage {
public void someMethod(YourPublicInterface param) {
if (param instanceof YourPublicInterface.Internal) {
// run the optimized code
} else {
// run the general code
}
}
}
Fuera del paquete, los usuarios pueden usar YourPublicInterface sin problemas.
En la práctica 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 otros usos de protected no son aplicables. Específicamente, protected métodos protected se usan a menudo para proporcionar acceso a algunos detalles de implementaciones de nivel inferior para descendientes. Pero declarar que 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 qué se tratan las interfaces.
Para lograr lo que probablemente desee, necesita dos interfaces, una para uso interno y otra que expone en la API pública. (Con el interno posiblemente, pero no necesariamente extendiendo el público). O, como otros señalaron, una superclase abstracta.
Interfaz Si desea utilizar algo como lo descrito, continúe con las clases abstractas o las interfaces anidadas.
Un resumen del estilo de código sobre las variables de interfaz, pero que 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) a la que los programadores de Java pueden acceder para hacer referencia e implementar en sus propias aplicaciones. Dado que una interfaz se puede usar en paquetes Java que son diferentes de los suyos, la visibilidad pública asegura que el código del programa pueda acceder a la variable.
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 implementar .
Los miembros de la interfaz siempre se modifican / implementan fuera de sí mismo (en una clase o estructura), por lo tanto, son implícitamente públicos y no se permiten modificadores de acceso con él. Incluso los miembros de la interfaz se implementan públicamente. Sin embargo, si desea que un miembro sea privado en una clase que proporciona su implementación, entonces debe implementar la interfaz de manera explícita.
interface IMyIF {
int MyMeth(int x);
}
//then it is legal to implement IMyIF as shown here:
class MyClass : IMyIF {
int IMyIF.MyMeth(int x) {
return x / 3;
}
}
una implementación explícita le brinda una manera de implementar un método de interfaz para que no sea un miembro público de la clase que proporciona la implementación.
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 públicos estáticos.
Porque se supone que una interfaz significa "lo que se puede ver desde fuera de la clase". No tendría sentido agregar métodos no públicos.
Tal vez, porque es una interfaz , es decir, está ahí para decirles a los clientes qué pueden hacer con las instancias, en lugar de decirles lo que no pueden hacer.
Tengo que decir que esta pregunta ha sido reabierta con la introducción de métodos predeterminados en Java 8. El proyecto en el que estoy trabajando ahora es similar al de la interfaz de una interfaz, con la intención de 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 "predeterminado protegido". Resulta que eso realmente 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, por las razones mencionadas anteriormente; pero si un método público predeterminado requiere un recurso de bajo nivel que probablemente no cambie y que pueda ser provisto por un método protegido, me parece que tener un trabajo "protegido por defecto" no solo mantendría un código más limpio, protegería a los futuros usuarios abusos accidentales.
(Esto, trágicamente, no cambia el hecho de que todavía necesito complicar demasiado mi código con resúmenes que de otro modo serían innecesarios, pero tengo la intención de poner una solicitud de función en Oracle).
Una interfaz está destinada a ser utilizada como un "contrato" para el mundo exterior. Si desea utilizar métodos protegidos, probablemente sea mejor utilizar una clase abstracta (si está disponible en Java, por supuesto). Wiki
Además, esta publicación probablemente también tenga algunas respuestas excelentes: ¿por qué no puedo tener miembros protegidos de la interfaz?