numeros - ¿Por qué falta la directiva de amigos en Java?
numeros amigos (8)
Me preguntaba por qué Java ha sido diseñado sin la directiva friend que está disponible en C ++ para permitir un control más preciso sobre qué métodos y variables de instancia están disponibles fuera del paquete en el que se ha definido una clase.
No veo ninguna razón práctica ni ningún inconveniente específico, parece solo un problema de diseño pero algo que no crearía ningún problema si se añadiera al lenguaje.
¿Por qué no pensar simplemente que Java requiere que las clases de amigos se coloquen? La visibilidad privada del paquete permite que todos los miembros del mismo paquete puedan acceder a esos miembros. Por lo tanto, no solo está limitado a amigos declarados explícitamente, sino que también permite que cualquier amigo (existente o futuro) altere algunos miembros que están diseñados específicamente para este propósito (pero no sus elementos privados). Todavía puedes confiar completamente en la encapsulación.
Además de la visibilidad del paquete mencionado anteriormente, Java también ofrece clases internas y anónimas que no solo son amigos por defecto, sino que también tienen automáticamente una referencia a la clase que lo contiene. Dado que la creación de tales clases de ayuda es probablemente la única forma razonable de usar un friend en C ++, Java no lo necesita, ya que tiene otro mecanismo para eso. Los iteradores son un muy buen ejemplo de esto.
Aquí hay algunas razones fuera de mi cabeza:
- No se requiere amigo. Es conveniente, pero no es obligatorio.
- amigo soporta mal diseño. Si una clase requiere acceso de amigos a otra, lo estás haciendo mal. (ver arriba, conveniente, no requerido).
- amigo rompe la encapsulación. Básicamente, todos mis secretos pertenecen a mí, y ese tipo allí (mi amigo).
Completamente de acuerdo con la declaración de spaceghost en su respuesta.
Contrariamente a la opinión popular, aquí hay muchos casos, en particular para las capacidades de infraestructura, donde el acceso de amigos conduce a un diseño MEJOR, no a un diseño peor.
Mi ejemplo es simple: si una clase A tiene que proporcionar una interfaz especial de "amigo" a la clase B en Java, tenemos que colocarlos en el mismo paquete. Sin excepciones. En ese caso, si A es un amigo de B y B es un amigo de C, A tiene que ser un amigo de C, lo que no siempre es cierto. Esta "transitividad de la amistad" rompe la encapsulación más que cualquier problema al que la amistad de C ++ pueda conducir.
En general, creo que se debió a la complejidad cognitiva agregada y al bajo número de casos en los que crea una mejora.
Yo diría que la enorme cantidad de líneas de Java en producción en este momento puede dar fe de que la palabra clave de friend no es realmente una gran pérdida :).
Por favor vea la respuesta de @dwb por algunas razones más específicas.
En mi opinión, algún tipo de función de amigo (no necesariamente muy similar a la de C ++) sería muy útil en algunas situaciones en Java. Actualmente tenemos paquetes de acceso privado / predeterminado para permitir la colaboración entre clases estrechamente acopladas en el mismo paquete ( String y StringBuffer por ejemplo), pero esto abre la interfaz de implementación privada hasta el paquete completo. Entre los paquetes tenemos hacks de reflexión malvados que causan una gran cantidad de problemas.
Hay un poco de una complicación adicional en esto en Java. C ++ ignora las restricciones de acceso al resolver sobrecargas de funciones (y similares): si un programa compila #define private public no debería hacer nada. Java (en su mayoría) descarta los miembros no accesibles. Si es necesario tener en cuenta la amistad, entonces la resolución es más complicada y menos obvia.
Sólo un programador muy ingenuo e inexperto abogaría contra los amigos. Por supuesto, se puede utilizar incorrectamente, pero también los datos públicos, pero se proporciona esa capacidad.
Contrariamente a la opinión popular, aquí hay muchos casos, en particular para las capacidades de infraestructura, donde el acceso de amigos conduce a un diseño MEJOR, no a un diseño peor. La encapsulación a menudo se viola cuando un método se FORCE que se haga público cuando realmente no debería, pero no nos queda otra opción porque Java no es compatible con amigos.
Solo para agregar a las otras respuestas:
Existe la visibilidad del paquete predeterminado en Java. Por lo tanto, puede llamar a todas las clases en el mismo paquete vecinos. En ese caso, tiene un control explícito de lo que muestra a los vecinos, solo miembros con visibilidad de paquetes.
Entonces, no es realmente un amigo pero puede ser similar. Y sí, esto también conduce a un mal diseño ...