Odpowiedź.

Kontrola dostępu to fundamentalna zasada OOP, zapewniająca enkapsulację i ochronę wewnętrznych danych klasy.

Historia zagadnienia:

Klasyczny C++ wspiera trzy modyfikatory dostępu: public, protected, private. Idea ta powstała w celu ochrony wewnętrznej implementacji klasy i oddzielenia interfejsu od implementacji.

Problem:

Bez prawidłowej kontroli dostępu użytkownicy klasy mogą niezamierzenie zmienić wewnętrzny stan obiektów lub naruszyć invarianty klasy. Źle zaprojektowany dostęp utrudnia utrzymanie i skalowanie kodu.

Rozwiązanie:

Używać modyfikatorów, aby wyraźnie rozdzielić to, co może używać świat zewnętrzny, od tego, co przeznaczone jest tylko do celów wewnętrznych obiektu.

Przykład kodu:

class Sample {
private:
    int secret;
protected:
    void setSecret(int s) { secret = s; }
public:
    Sample(int s) : secret(s) {}
    int getSecret() const { return secret; }
};

Kluczowe cechy:

Enkapsulacja poprzez rozdzielenie interfejsu i implementacji.
Zapobieganie przypadkowym zmianom stanu obiektu.
Dziedziczący mają dostęp tylko do protected (ale nie do private).

Pytania z pułapką.

Czy funkcja friend lub klasa friend może uzyskać dostęp do prywatnych członów innej klasy?

Tak, słowo kluczowe friend zapewnia pełny dostęp do prywatnych i chronionych członów klasy. Takie podejście należy stosować bardzo ostrożnie, aby nie naruszyć enkapsulacji.

Przykład:

class PrivData {
private:
    int secret;
friend void accessSecret(const PrivData& d);
};
void accessSecret(const PrivData& d) { std::cout << d.secret; }

Czy można uzyskać dostęp do prywatnego członu, jeśli zna się jego nazwę, za pomocą wskaźników lub rzutowania typów?

Tak, za pomocą rzutowania typów lub manipulacji pamięcią (na przykład „sztuczka wskaźnika do członu”), ale to narusza standardy języka i prowadzi do nieokreślonego zachowania. Nie należy tego robić.

Co się dzieje przy dziedziczeniu: czy prywatne człony klasy bazowej stają się dostępne dla potomka?

Nie, prywatne człony nie są bezpośrednio dostępne dla klasy pochodnej, dostęp możliwy jest tylko przez publiczne/protected metody akcesorów klasy bazowej.

Typowe błędy i antywzorce

Nadużywanie członów publicznych i funkcji friend.
Prywatne dane stają się dostępne przez niebezpieczne konstrukcje.
Brak getterów/setterów dla potrzebnych danych.

Przykład z życia

Negatywna sytuacja

W dużym projekcie wszystkie człony klasy zostały zadeklarowane jako publiczne w celu szybkiego prototypowania.

Zalety:

Szybkie napisanie prototypu.

Wady:

Trudność w śledzeniu miejsc, w których zmieniane jest ważne state, nieprzewidywalne zachowanie, brak możliwości refaktoryzacji bez złamania interfejsu.

Pozytywna sytuacja

Wszystko ściśle rozdzielone według poziomów dostępu, funkcje friend są używane tylko do testów jednostkowych.