¿Por qué Directiva amigo no se encuentra en Java?

Question

Me preguntaba por qué Java ha sido diseñado sin la frienddirective que está disponible en C ++ para permitir un control más preciso sobre el cual los métodos y variables de instancia están disponibles desde fuera del paquete en el que una clase se ha definido.

No veo ninguna razón práctica ni ningún inconveniente específica, parece sólo una cuestión de diseño, pero algo que no crearía ningún problema si se añade a la lengua.

Answer 1

Estas son algunas de las razones de la parte superior de mi cabeza:

No se requiere
• amigo. Es conveniente, pero no es obligatorio
• amigo soporta mal diseño. Si una clase requiere acceso a otro amigo, lo estás haciendo mal. (Véase más arriba, conveniente, no es obligatorio).
• amigo se rompe la encapsulación. Básicamente, todos mis soldados son pertenecen a mí, y que tipo de allí (mi amigo).

Answer 2

En general creo que fue debido a la complejidad cognitiva añadido y bajo número de casos en los que se produce una mejora.

Yo diría que la muy gran número de líneas de java en la producción en este momento puede dar fe de que la palabra clave friend no es realmente una gran pérdida:.)

Por favor, vea @ respuesta de dwb por algunas razones más específicas.

Answer 3

Sólo un programador muy ingenuo e inexperto estaría a favor contra amigos. Por supuesto que puede ser mal utilizada, pero también puede hacerlo datos públicos, sin embargo, se proporciona esa capacidad.

Contrariamente a la opinión popular, aquí hay muchos casos, en particular para las capacidades de infraestructura, donde el acceso amigo conduce a diseño mejor, no peor de diseño. La encapsulación es a menudo violado cuando se fuerza un método que se hagan públicos cuando en realidad no debería ser, pero que no les queda otra opción porque Java no soporta amigos.

Answer 4

Además de la visibilidad de paquete antes mencionado, Java también ofrece clases internas anónimas y que no son sólo amigos por defecto, sino que también tienen automáticamente una referencia a la clase que contiene. Desde la creación de este tipo de clases de ayuda es probablemente la única forma razonable de uso friend en C ++, Java no es necesario, ya que tiene otro mecanismo para eso. Los iteradores son un muy buen ejemplo de esto.

Answer 5

¿Por qué no simplemente pensar que Java requiere clases de amistad a ser colocado? La visibilidad de paquete-privada permite a todos, desde el mismo paquete para acceder a esos miembros. Así que no sólo está limitado a los amigos declarados explícitamente, pero permite que cualquier amigo (actual o futuro) para alterar algunos miembros que están diseñados específicamente para este propósito (pero no su contenido privado). Todavía es capaz de confiar plenamente en la encapsulación.

Answer 6

Sólo para añadir a las otras respuestas:

No es el valor predeterminado visibilidad de paquete en Java. Por lo tanto, podría llamar a todas las clases en los mismos vecinos del paquete. En ese caso, usted tiene el control explícito de lo que muestran a los vecinos -. Miembros sólo con visibilidad de paquete

Por lo tanto, en realidad no es un amigo, pero puede ser similar. Y sí, esto también conduce a un mal diseño ...

Answer 7

En mi opinión algún tipo de función amigo (no necesariamente muy similar a C ++ 's) sería muy útil en algunas situaciones en Java. Actualmente tenemos envasar cortes de acceso / default privados para permitir la colaboración entre las clases fuertemente acoplados en el mismo paquete (String y StringBuffer por ejemplo), pero esto abre la interfaz de la aplicación privada a todo el paquete. Entre los paquetes que tenemos hacks reflexión del mal que provoca toda una serie de problemas.

Hay un poco de una complicación adicional en lo hace en Java. C ++ ignora las restricciones de acceso, mientras que la resolución de sobrecargas de función (y similares) - si un programa compila #define private public no debe hacer nada. Java (en su mayoría) descarta miembros no accesibles. Si las necesidades de amistad que deben tenerse en cuenta entonces la resolución es más complicado y menos evidente.

Answer 8

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 amigo conduce a diseño mejor, no peor de diseño.

Mi ejemplo es simple - si una clase A tiene que proporcionar una interfaz especial "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, que no siempre es cierto. Esto rompe la amistad "transitividad" encapsulación más de los problemas que la amistad C ++ podría conducir a.