Доступ до приватного поля іншого об’єкта в тому ж класі

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

Будь ласка, забудьте про дизайн. Я знаю, що ООП визначає, що приватні об'єкти є приватними для класу. Моє питання полягає в тому, чому OOP був розроблений таким чином, щоб приватні поля мали доступ на рівні класу, а не на рівні об’єкта ?

Мені також трохи цікаво відповісти.

Найзадовільніша відповідь, яку я знайшов, - це від Artemix в іншому дописі тут (я перейменовую AClass у клас Person): Чому модифікатори доступу на рівні класу замість рівня об’єкта?

Приватний модифікатор застосовує принцип інкапсуляції.

Ідея полягає в тому, що "зовнішній світ" не повинен вносити зміни до внутрішніх процесів Person, оскільки впровадження Person може змінюватися з часом (і вам доведеться змінити весь зовнішній світ, щоб виправити відмінності у впровадженні - що майже неможливо).

Коли екземпляр Person отримує доступ до внутрішніх елементів іншого екземпляра Person - ви можете бути впевнені, що обидва екземпляри завжди знають деталі реалізації Person. Якщо логіка внутрішніх процесів до Person змінена - все, що вам потрібно зробити, це змінити код Person.

EDIT: Будь ласка, проголосуйте відповідь Artemix. Я просто копіюю його.

Див. Специфікацію мови Java, розділ 6.6.1. Визначення доступності

У ньому зазначено

В іншому випадку, якщо член або конструктор оголошено private, тоді доступ дозволений тоді і лише тоді, коли він відбувається в тілі класу верхнього рівня (§7.6), що включає декларацію члена або конструктора.

Клацніть на посилання вище, щоб отримати докладнішу інформацію. Тож відповідь така: Оскільки Джеймс Гослінг та інші автори Java вирішили, що це має бути саме так.

Хороше питання. Здається, модифікатор доступу на рівні об’єкта ще більше запровадить принцип інкапсуляції.

Але насправді все навпаки. Візьмемо приклад. Припустимо, ви хочете глибоко скопіювати об’єкт у конструкторі, якщо ви не можете отримати доступ до приватних членів цього об’єкта. Тоді єдино можливим способом є додавання деяких публічних доступу до всіх приватних членів. Це зробить ваші предмети оголеними до всіх інших частин системи.

Отже, інкапсуляція не означає бути закритою для всього іншого світу. Це означає бути виборчим щодо того, до кого ви хочете бути відкритим.

Це працює, оскільки ви перебуваєте в class Personкласі - класу дозволено тикати всередину власного типу класу. Це дійсно допомагає, коли ви хочете написати конструктор копій, наприклад:

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

Або якщо ми хочемо писати operator+і operator-для нашого класу великих чисел.

Лише мої 2 центи на питання, чому семантика приватної видимості в Java є рівнем класу, а не об’єктом.

Я б сказав, що тут, здається, зручність . Насправді, приватна видимість на рівні об'єкта змусила б піддавати методи іншим класам (наприклад, у тому самому пакеті) у сценарії, проілюстрованому OP.

По правді кажучи, я не зміг ні придумати, ні знайти приклад, що показує, що видимість на рівні класу-приватності (як, наприклад, пропонується Java) створює будь-які проблеми, якщо порівнювати з видимістю на рівні об'єкт-приват.

Тим не менш, мови програмування з більш докладною системою політик видимості можуть забезпечити видимість об'єкта як на рівні об'єкта, так і на рівні класу.

Наприклад, Ейфель пропонує вибірковий експорт: ви можете експортувати будь-яку функцію класу до будь-якого класу на ваш вибір, від {NONE} (об'єктно-приватний) до {ANY} (еквівалент загальнодоступного, а також за замовчуванням), до {PERSON} (клас-приват, див. приклад OP), для певних груп класів {PERSON, BANK}.

Цікаво також зауважити, що в Ейфелі не потрібно робити атрибут приватним і писати геттер, щоб запобігти присвоєнню йому інших класів. Загальнодоступні атрибути в Ейфелі за замовчуванням доступні в режимі лише для читання, тому вам не потрібен геттер, щоб повернути їх значення.

Звичайно, вам все ще потрібен сеттер, щоб встановити атрибут, але ви можете приховати його, визначивши його як "призначувач" для цього атрибута. Це дозволяє вам, якщо ви хочете, використовувати більш зручний оператор присвоєння замість виклику сетера.

Оскільки private модифікатор доступу робить його видимим лише в межах класу . Цей метод все ще в класі .

privateполе є в класі / об'єкт , в якому оголошено поле. Він є приватним для інших класів / об’єктів, крім того, в якому він знаходиться.

Перше, що ми повинні зрозуміти, це все, що нам потрібно зробити, це дотримуватися принципів упсу, тому інкапсуляція означає, що обертаємо дані всередині пакета (тобто класу), а потім представляємо всі дані як об’єкт і прості у доступі. так що якщо ми зробимо поле неприватним, то до нього можна отримати індивідуальний доступ. і це призводить до поганої паратики.

За допомогою концепції відображення в Java можливо змінювати поля та методи приватних осіб

Модифікація методів y campos privados con Refleccion en Java