Accéder au champ privé d'un autre objet de la même classe

class Person 
{
   private BankAccount account;

   Person(BankAccount account)
   {
      this.account = account;
   }

   public Person someMethod(Person person)
   {
     //Why accessing private field is possible?

     BankAccount a = person.account;
   }
}

Veuillez oublier le design. Je sais que la POO spécifie que les objets privés sont privés pour la classe. Ma question est la suivante: pourquoi la POO a-t-elle été conçue de telle sorte que les champs privés aient un accès au niveau de la classe et non un accès au niveau de l'objet ?

Je suis également un peu curieux de connaître la réponse.

La réponse la plus satisfaisante que je trouve vient d'Artemix dans un autre article ici (je renomme l'AClass avec la classe Person): Pourquoi avoir des modificateurs d'accès au niveau de la classe au lieu du niveau de l'objet?

Le modificateur privé applique le principe d'encapsulation.

L'idée est que le `` monde extérieur '' ne devrait pas apporter de modifications aux processus internes de la personne car la mise en œuvre de la personne peut changer avec le temps (et vous devrez changer tout le monde extérieur pour corriger les différences de mise en œuvre - ce qui est presque impossible).

Lorsque l'instance de Person accède aux composants internes d'une autre instance de Person, vous pouvez être sûr que les deux instances connaissent toujours les détails de l'implémentation de Person. Si la logique des processus internes à Person est modifiée, tout ce que vous avez à faire est de changer le code de Person.

EDIT: Veuillez voter pour la réponse d'Artemix. Je fais juste un copier-coller.

Voir la spécification du langage Java, section 6.6.1. Déterminer l'accessibilité

Il est dit

Sinon, si le membre ou le constructeur est déclaré private, alors l'accès est autorisé si et seulement s'il se produit dans le corps de la classe de niveau supérieur (§7.6) qui renferme la déclaration du membre ou du constructeur.

Cliquez sur le lien ci-dessus pour plus de détails. Donc, la réponse est: parce que James Gosling et les autres auteurs de Java ont décidé qu'il en était ainsi.

Bonne question. Il semble que le modificateur d'accès au niveau de l'objet appliquerait encore plus le principe d'encapsulation.

Mais en fait, c'est l'inverse. Prenons un exemple. Supposons que vous souhaitiez copier en profondeur un objet dans un constructeur, si vous ne pouvez pas accéder aux membres privés de cet objet. Ensuite, le seul moyen possible est d'ajouter des accesseurs publics à tous les membres privés. Cela rendra vos objets nus à toutes les autres parties du système.

L'encapsulation ne signifie donc pas être fermé à tout le reste du monde. Cela signifie être sélectif à propos de qui vous voulez être ouvert.

Cela fonctionne parce que vous êtes dans class Person- une classe est autorisée à pénétrer dans son propre type de classe. Cela aide vraiment lorsque vous souhaitez écrire un constructeur de copie, par exemple:

class A
{
   private:
      int x;
      int y;
   public:
      A(int a, int b) x(a), y(b) {}
      A(A a) { x = a.x; y = y.x; }
};

Ou si nous voulons écrire operator+et operator-pour notre grande classe de nombres.

Juste mes 2 cents sur la question de savoir pourquoi la sémantique de la visibilité privée en Java est au niveau de la classe plutôt qu'au niveau de l'objet.

Je dirais que la commodité semble être la clé ici. En fait, une visibilité privée au niveau objet aurait obligé à exposer des méthodes à d'autres classes (par exemple dans le même package) dans le scénario illustré par l'OP.

En vérité, je n'ai pas été en mesure de concocter ni de trouver un exemple montrant que la visibilité au niveau de la classe privée (comme celle offerte par Java) crée des problèmes par rapport à la visibilité au niveau de l'objet privé.

Cela dit, les langages de programmation avec un système plus fin de politiques de visibilité peuvent offrir à la fois une visibilité des objets au niveau de l'objet et au niveau de la classe.

Par exemple Eiffel , propose une exportation sélective: vous pouvez exporter n'importe quelle caractéristique de classe vers n'importe quelle classe de votre choix, de {NONE} (object-private) à {ANY} (l'équivalent de public, et aussi la valeur par défaut), vers {PERSON} (class-private, voir l'exemple de l'OP), à des groupes spécifiques de classes {PERSON, BANK}.

Il est également intéressant de remarquer que dans Eiffel, vous n'avez pas besoin de rendre un attribut privé et d'écrire un getter pour empêcher d'autres classes de lui attribuer. Les attributs publics dans Eiffel sont par défaut accessibles en mode lecture seule, vous n'avez donc pas besoin d'un getter juste pour renvoyer leur valeur.

Bien sûr, vous avez toujours besoin d'un setter pour définir un attribut, mais vous pouvez le masquer en le définissant comme "assigner" pour cet attribut. Cela vous permet, si vous le souhaitez, d'utiliser l'opérateur d'affectation le plus pratique au lieu de l'invocation du setter.

Parce que le private modificateur d'accès le rend visible uniquement dans la classe . Cette méthode est toujours dans la classe .

le privatechamp est accessible dans la classe / l'objet dans lequel le champ est déclaré. Il est privé pour les autres classes / objets en dehors de celui dans lequel il se trouve.

Avec le concept de réflexion en Java, il est possible de modifier les champs et les méthodes privés

Modificando metodos y campos privados con Refleccion en Java

La première chose que nous devons comprendre ici est que tout ce que nous avons à faire est de suivre les principes oops donc l'encapsulation consiste à dire que les données enveloppent le package (c'est-à-dire la classe) et que toutes les données soient représentées sous forme d'objet et faciles d'accès. donc si nous rendons le champ non privé, il y accède individuellement. et il en résulte une mauvaise paratice.