Perché gli oggetti della stessa classe hanno accesso ai dati privati ​​degli altri?

Perché gli oggetti della stessa classe hanno accesso ai dati privati ​​degli altri?

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

Questo codice funziona. È perfettamente possibile per l'oggetto a accedere a dati privati ​​dall'oggetto be restituirli. Perché dovrebbe essere così? Penso che i dati privati ​​siano privati. (Ho iniziato cercando di capire i costruttori di copie nell'idioma pimpl, ma poi ho scoperto che non avevo nemmeno capito questa semplice situazione.)

Perché è così che funziona in C ++. In C ++ il controllo degli accessi funziona per classe , non per oggetto.

Il controllo dell'accesso in C ++ è implementato come funzionalità statica in fase di compilazione. Penso che sia piuttosto ovvio che non sia realmente possibile implementare alcun controllo di accesso significativo per oggetto in fase di compilazione. Solo il controllo per classe può essere implementato in questo modo.

Alcuni accenni al controllo per oggetto sono presenti nella specifica di accesso protetto , motivo per cui ha anche un proprio capitolo dedicato nello standard (11.5). Tuttavia, tutte le caratteristiche per oggetto descritte sono piuttosto rudimentali. Ancora una volta, il controllo degli accessi in C ++ è pensato per funzionare su base per classe.

"Privato" non è realmente un meccanismo di controllo degli accessi nel senso di "Ho reso private le mie foto su Facebook in modo che tu non possa vederle".

In C ++, "private" dice semplicemente che queste sono parti di una classe che tu (il programmatore della classe) potresti cambiare nelle versioni future, ecc., E non vuoi che altri programmatori che usano la tua classe si affidino alla loro esistenza o funzionalità .

Se si desidera un vero controllo degli accessi, è necessario implementare tecniche di protezione dei dati autentiche.

Questa è una buona domanda e mi sono imbattuto in questa domanda di recente. Ho avuto alcune discussioni con i miei colleghi ed ecco il riassunto della nostra discussione: Questo è di progettazione. Ciò non significa che questo design sia totalmente ragionevole per tutti i casi, ma ci devono essere alcune considerazioni sul motivo per cui viene scelto il privato per classe. Le possibili ragioni a cui potremmo pensare includono:

Prima di tutto, il costo del controllo dell'accesso per istanza potrebbe essere molto alto. Questo è stato discusso da altri in questo thread. In teoria, questo può essere fatto tramite questo controllo del puntatore. Tuttavia, questa operazione non può essere eseguita in fase di compilazione e può essere eseguita solo in fase di esecuzione. Quindi devi identificare il controllo di accesso di ogni membro in fase di esecuzione, e quando viene violato probabilmente verranno sollevate solo eccezioni. Il costo è alto.

In secondo luogo, il controllo dell'accesso per classe ha il suo caso d'uso, come il costruttore di copie o l'operatore =. Sarebbe difficile implementarli se il controllo dell'accesso è per istanza.

Inoltre, il controllo dell'accesso è principalmente dal punto di vista della programmazione / linguaggio, per come modulare / controllare l'accesso al codice / membro, non ai dati.

È in qualche modo una decisione arbitraria di progettazione del linguaggio. In Ruby , ad esempio, privatesignifica veramente privato, come in "solo l'istanza può accedere ai propri membri di dati privati". Tuttavia, questo è un po 'restrittivo.

Come indicato nei commenti, i costruttori di copia e gli operatori di assegnazione sono luoghi comuni in cui si accede direttamente ai membri dei dati privati ​​di un'altra istanza. Ci sono ragioni meno ovvie per cui.

Considera il seguente caso. Stai implementando un elenco collegato OO. L'elenco collegato ha una classe di nodi nidificati per la gestione dei puntatori. È possibile implementare questa classe di nodi in modo tale che gestisca i puntatori da sé (invece di avere i puntatori pubblici e gestiti dalla lista). In tal caso, gli oggetti nodo vorranno modificare i puntatori di altri oggetti nodo in altri punti rispetto al tipico costruttore di copia e operatore di assegnazione.

Il trucco sta nel ricordare che i dati sono privateper la classe , non per l' istanza della classe. Qualsiasi metodo all'interno della tua classe può accedere ai dati privati ​​di qualsiasi istanza di quella classe; non c'è un modo per mantenere i dati privati ​​all'interno di un'istanza a meno che non si vietino metodi che accedono esplicitamente ai membri dei dati privati ​​di altre istanze.

Oltre a tutte le risposte precedenti, considera i costruttori di copia personalizzati, gli operatori di assegnazione e tutte le altre funzioni che scriveresti per una classe che opera su altre istanze . Avresti bisogno di funzioni di accesso per tutti quei membri di dati.

I dati privati ​​rimangono privati ​​fino a quando qualcuno che vi ha accesso non li rivela ad altri.

Questo concetto si applica anche ad altre situazioni, come ad esempio:

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

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

private:
   int iTheSecretVault;
};

Come potrebbe qualcuno ritirare i soldi? :)