Pourquoi la directive ami manque en Java?

Question

Je me demandais pourquoi Java a été conçu sans frienddirective qui est disponible en C ++ pour permettre un contrôle plus précis sur les méthodes et les variables d'instance sont disponibles à l'extérieur du paquet dans lequel a été défini une classe.

Je ne vois aucune raison pratique ni aucun inconvénient spécifique, il semble juste un problème de conception, mais quelque chose qui ne crée aucun problème si on les ajoute à la langue.

Answer 1

Voici quelques raisons du haut de ma tête:

• ami n'est pas nécessaire. Il est pratique, mais pas obligatoire
• ami soutient une mauvaise conception. Si une classe a besoin d'accéder à un autre ami, vous le faites mal. (Voir ci-dessus, pratique, pas obligatoire).
• pauses ami encapsulation. Au fond, tous mes soldats appartiennent à moi, et ce gars là-bas (mon ami).

Answer 2

En général, je pense que c'est à cause de la complexité cognitive ajoutée et faible nombre de cas où il crée une amélioration.

Je dirais que le nombre extrêmement énorme de lignes de java dans la production à ce moment peut attester que le mot-clé friend est pas vraiment une grosse perte.)

S'il vous plaît voir @ La réponse de DWB pour des raisons plus spécifiques.

Answer 3

Seul un programmeur très naïf et inexpérimenté préconiserait contre des amis. Bien sûr, il peut être utilisé à mauvais escient, mais ne peut donc des données publiques, mais cette capacité est fournie.

Contrairement à l'opinion populaire, voici bien des cas, en particulier pour les capacités d'infrastructure, où conduit d'accès ami à la conception mieux, pas pire conception. Encapsulation est souvent violé lorsqu'une méthode est FORCÉ être rendu public quand il ne devrait vraiment pas être, mais il nous reste pas d'autre choix parce que Java ne supporte pas d'amis.

Answer 4

En plus de la visibilité de l'emballage mentionné ci-dessus, Java offre également des classes internes et anonymes qui ne sont pas seulement des amis par défaut, mais aussi automatiquement une référence à la classe contenant. Depuis la création de ces classes d'aide est probablement la seule façon raisonnable de friend utilisation en C ++, Java n'a pas besoin car il a un autre mécanisme pour cela. Itérateurs sont un très bon exemple.

Answer 5

Pourquoi ne pas penser simplement que Java nécessite des classes d'ami pour être placé à proximité? La visibilité du paquet-privé permet à chacun du même paquet pour accéder à ces membres. Donc, vous n'êtes pas seulement limité à des amis explicitement déclarés, mais vous autorisez tout (existant ou futur) ami de modifier certains membres qui sont spécialement conçus à cet effet (mais pas vos affaires privées). Vous êtes toujours en mesure de compter entièrement sur l'encapsulation.

Answer 6

Juste pour ajouter aux autres réponses:

Il y a la valeur par défaut la visibilité du paquet en Java. Donc, vous peut appeler toutes les classes dans les mêmes voisins de l'emballage. Dans ce cas, vous avez le contrôle explicite de ce que vous montrez aux voisins -. Membres seulement avec la visibilité du paquet

Alors, ce n'est pas vraiment un ami, mais peut être similaire. Et oui, cela conduit aussi à une mauvaise conception ...

Answer 7

A mon avis une sorte de fonction ami (pas forcément très similaire à l 'C ++) serait très utile dans certaines situations en Java. À l'heure actuelle, nous avons empaqueter hacks accès privé / par défaut pour permettre la collaboration entre les classes couplées étroitement dans le même emballage (String et StringBuffer par exemple), mais cela ouvre l'interface de mise en œuvre privée jusqu'à l'ensemble du paquet. Entre paquets que nous avons hacks de réflexion du mal qui provoque une foule de problèmes.

Il y a un peu d'une complication supplémentaire dans le fait en Java. C ++ ne tient pas compte des restrictions d'accès tout en résolvant les surcharges de fonction (et similaire) - si un programme compile #define private public ne doit pas faire quoi que ce soit. Java (la plupart du temps) défausse membres non accessibles. Si les besoins d'amitié à prendre en compte, puis la résolution est plus compliquée et moins évidente.

Answer 8

Entièrement d'accord avec la déclaration de spaceghost sa réponse

  

Contrairement à l'opinion populaire, voici bien des cas, en particulier pour les capacités d'infrastructure, où conduit d'accès ami à la conception mieux, pas pire conception.

Mon exemple est simple - si une classe A doit fournir une interface spéciale « ami » à la classe B en java nous devons les placer dans le même paquet. Aucune exception. Dans ce cas, si A est un ami de B et B est un ami de C, A doit être un ami de C qui est pas toujours vrai. Cette « amitié transitivité » casse encapsulation plus de tous les problèmes que l'amitié C pourrait conduire à.