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

Question

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;
   }
}

S'il vous plaît, oubliez le design. Je sais que la POO spécifie que les objets privés sont privés à 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 que les champs privés ne soient pas accessibles au niveau de la classe ? pas d'accès au niveau des objets ?

Answer 1

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

La réponse la plus satisfaisante que j'ai trouvée est celle d'Artemix dans un autre message ici (je renomme la classe AClass en classe Person) : Pourquoi avoir des modificateurs d'accès au niveau de la classe plutôt qu'au niveau de l'objet ?

Le modificateur private applique le principe d'encapsulation.

L'idée est que le "monde extérieur" ne doit pas modifier les processus internes de la personne, car la mise en œuvre de la personne peut changer au fil du temps (et il faudrait modifier l'ensemble du 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 données 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 à la Personne est modifiée, il suffit de changer le code de la Personne.

EDIT : S'il vous plaît vote Réponse d'Artemix. Je ne fais que la copier-coller.

Answer 2

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

Mais en fait, c'est l'inverse. Prenons un exemple. Supposons que vous vouliez copier profondément un objet dans un constructeur, si vous ne pouvez pas accéder aux membres privés de cet objet. La seule solution possible est alors d'ajouter des accesseurs publics à tous les membres privés. Cela rendra vos objets nu à toutes les autres parties du système.

Donc l'encapsulation ne signifie pas être fermé à tout le reste du monde. Cela signifie être sélectif quant aux personnes auxquelles vous voulez être ouvert.

Answer 3

Voir le Spécification du langage Java, section 6.6.1. Détermination de l'accessibilité

Elle stipule

Sinon, si le membre ou le constructeur est déclaré private alors l'accès est autorisé si et seulement s'il a lieu dans le corps de la classe de premier niveau (§7.6) qui contient la déclaration du membre o. classe de premier niveau (§7.6) qui contient la déclaration du membre ou du constructeur. constructeur.

Cliquez sur le lien ci-dessus pour plus de détails. La réponse est donc : Parce que James Gosling et les autres auteurs de Java ont décidé qu'il en serait ainsi.

Answer 4

Parce que "privé" signifie restreint à cette classe, pas restreint à cet objet.

Answer 5

Cela fonctionne parce que vous êtes dans le class Person - une classe est autorisée à poke à l'intérieur de son propre type de classe. Ceci est très utile lorsque vous voulez é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+ y operator- pour notre classe de grands nombres.