example - my icon java

¿Por qué Java 8 no permite métodos predeterminados no públicos?

Question

Tomemos un ejemplo:

public interface Testerface {
default public String example() {
return "Hello";
}
}
public class Tester implements Testerface {
@Override
public String example() {
return Testerface.super.example() + " world!";
}
}
public class Internet {
public static void main(String[] args) {
System.out.println(new Tester().example());
}
}

Simplemente suficiente, esto imprimiría Hello world! . Pero digamos que estaba haciendo otra cosa con el valor de Testerface#example de Testerface#example , por ejemplo, inicializar un archivo de datos y devolver un valor interno sensible que no debería abandonar la clase implementadora. ¿Por qué Java no permite modificadores de acceso en los métodos de interfaz predeterminados? ¿Por qué no pueden ser protegidos / privados y potencialmente elevados por una subclase (similar a cómo una clase que extiende una clase padre puede usar un modificador más visible para un método anulado)?

Una solución común es pasar a una clase abstracta, sin embargo, en mi caso específico, tengo una interfaz para enumeraciones, por lo que no se aplica aquí. Me imagino que se pasó por alto o porque la idea original detrás de las interfaces es que son un "contrato" de los métodos disponibles, pero supongo que quiero información sobre lo que está sucediendo con esto.

He leído " ¿Por qué no se permite" final "en los métodos de interfaz de Java 8? ", Que dice:

La idea básica de un método predeterminado es: es un método de interfaz con una implementación predeterminada, y una clase derivada puede proporcionar una implementación más específica

Y me parece que la visibilidad no rompería ese aspecto en absoluto.

Al igual que con la pregunta vinculada, ya que parece que tenía problemas para cerrarse, se agradecería una respuesta autorizada en este asunto , en lugar de las basadas en opiniones.

Answer 1

Como vimos en ¿Cuál es la razón por la que la "sincronización" no está permitida en los métodos de interfaz de Java 8? y ¿Por qué no se permite "final" en los métodos de interfaz de Java 8? , extender las interfaces para definir el comportamiento es más sutil de lo que parece. Resulta que cada uno de los posibles modificadores tiene su propia historia; No es simplemente una cuestión de copiar ciegamente de cómo funcionan las clases. (Esto es al menos obvio en retrospectiva, ya que las herramientas para el modelado OO que funcionan para la herencia única no funcionan automáticamente para la herencia múltiple).

Comencemos con la respuesta obvia: las interfaces siempre se han restringido a tener solo miembros públicos, y si bien agregamos métodos predeterminados y métodos estáticos a las interfaces en Java 8, eso no significa que tengamos que cambiar todo solo para ser "más como" clases

A diferencia de la synchronized y la final , que habrían sido errores graves de compatibilidad con los métodos predeterminados, las accesibilidades más débiles, especialmente las privadas, son características razonables a considerar. Los métodos de interfaz privada, ya sean estáticos o de instancia (tenga en cuenta que estos no serían valores predeterminados, ya que no participan en la herencia) son una herramienta perfectamente sensata (aunque pueden ser fácilmente simulados por clases de ayudantes no públicas).

Realmente consideramos hacer métodos de interfaz privada en Java 8; esto fue principalmente algo que simplemente cayó al final de la lista debido a limitaciones de recursos y tiempo. Es muy posible que esta función pueda volver a aparecer en la lista de tareas pendientes algún día.

El paquete y los métodos protegidos, sin embargo, son más complicados de lo que parecen; la complejidad de la herencia múltiple y la complejidad del verdadero significado de protected interactuarían de muchas maneras no tan divertidas. Así que no aguanto la respiración por eso.

Entonces, la respuesta corta es que los métodos de interfaz privada es algo que podríamos haber hecho en 8, pero no pudimos hacer todo lo que se pudo haber hecho y aún enviar, por lo que se cortó, pero se pudo regresar.