Чому об’єкти одного класу мають доступ до приватних даних один одного?

Чому об’єкти одного класу мають доступ до приватних даних один одного?

class TrivialClass {
public: 
  TrivialClass(const std::string& data) :
    mData(data) {};

  const std::string& getData(const TrivialClass& rhs) const {
    return rhs.mData;
  };

private:
  std::string mData;
};

int main() {
  TrivialClass a("fish");
  TrivialClass b("heads");

  std::cout << "b via a = " << a.getData(b) << std::endl;
  return 0;
}

Цей код працює. Об'єкту a цілком можливо отримати доступ до приватних даних з об'єкта b та повернути його. Чому так має бути? Я думаю, що приватні дані є приватними. (Я почав, намагаючись зрозуміти конструктори копій у ідіомі pimpl, але потім я виявив, що навіть не розумію цієї простої ситуації.)

Тому що це працює в C ++. У C ++ контроль доступу працює на основі класу , а не на основі об'єкта.

Контроль доступу в C ++ реалізується як статична функція часу компіляції. Я думаю, що досить очевидно, що реально реалізувати будь-який змістовний контроль доступу до об'єктів під час компіляції. Таким чином можна реалізувати лише контроль за класом.

Деякі підказки управління об'єктом містяться в специфікаціях захищеного доступу , тому він навіть має власну спеціальну главу стандарту (11.5). Але все ж будь-які характеристики об'єкта, описані там, є досить рудиментарними. Знову ж таки, контроль доступу в C ++ повинен працювати на основі класу.

"Приватний" насправді не є механізмом контролю доступу в сенсі "я зробив свої фотографії у facebook приватними, тому ви їх не можете бачити".

У C ++ "приватний" просто говорить, що це частини класу, які ви (кодер класу) можете змінити у майбутніх версіях тощо. Ви не хочете, щоб інші кодери, що використовують ваш клас, покладалися на їх існування чи функціональність .

Якщо ви хочете справжнього контролю доступу, вам слід застосувати справжні методи захисту даних.

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

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

По-друге, для контролю доступу в класі є власний випадок використання, наприклад конструктор копій або оператор =. Їх було б важко реалізувати, якщо контроль доступу є, наприклад,.

Крім того, контроль доступу в основному з точки зору програмування / мови, як модулювати / контролювати доступ до коду / члена, а не даних.

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

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

Розглянемо наступний випадок. Ви реалізуєте пов'язаний список ОО. Список пов'язаних має вкладений клас вузлів для управління вказівниками. Ви можете реалізувати цей клас вузлів таким чином, що він керує самими вказівниками (а не мати покажчики загальнодоступними та керувати їх списком). У такому випадку у вас будуть об'єкти вузлів, які хочуть змінити покажчики інших об'єктів вузла в інших місцях, що є типовим конструктором копіювання та оператором призначення.

Хитрість полягає в тому, щоб пам'ятати про те , що дані privateв класі , а НЕ примірника класу. Будь-який метод у вашому класі може отримати доступ до приватних даних будь-якого екземпляра цього класу; не існує способу збереження приватних даних у межах екземпляра, якщо ви не забороняєте методи, які явно отримують доступ до приватних даних членів інших інстанцій.

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

Приватні дані залишаються приватними, поки хтось, хто має доступ до них, не відкриє їх іншим.

Ця концепція застосовується і до інших ситуацій, таких як:

class cMyClass
{
public:
   // ...
   // omitted for clarity
   // ...

   void Withdraw(int iAmount)
   {
      iTheSecretVault -= iAmount;
   }

private:
   int iTheSecretVault;
};

Як хто-небудь міг зняти гроші? :)