Odpowiedź.

Historia pytania:

Enkapsulacja to jeden z kluczowych zasad OOP, które pojawiły się w C++ od jego powstania. Idea polega na ograniczeniu dostępu do wewnętrznego stanu obiektu, oferując tylko przemyślane interfejsy do pracy z nim. W C++ enkapsulacja jest formalizowana przez obszary widoczności członków klasy: public, protected, private.

Problem:

Jeśli nie używać enkapsulacji, wewnętrzny stan obiektów może być modyfikowany z dowolnego miejsca w programie, co prowadzi do błędów, trudnych do zidentyfikowania bugów i ogólnego obniżenia niezawodności. Zbytnia ukrycie może natomiast utrudnić konserwację i użycie klas.

Rozwiązanie:

Należy wyraźnie oddzielić interfejs klasy (sekcja publiczna) od implementacji (private/protected). Do dostępu do ważnych danych należy używać specjalnych metod (getterów/setterów). W przypadku złożonej logiki, warto rozdzielać mechanizm poprzez dodatkowe klasy lub szablony. Należy używać metod const, aby zapewnić niezmienność stanu.

Przykład kodu:

class Counter {
private:
    int value;
public:
    Counter() : value(0) {}
    void increment() { ++value; }
    int get() const { return value; }
};

Kluczowe cechy:

Trzy obszary widoczności: public, protected, private.
Możliwość wdrożenia tylko niezbędnych metod do interakcji z obiektem.
Ograniczenie dostępu do wewnętrznych danych i metod.

Pytania z podstępem.

Czy można uzyskać dostęp do prywatnego członu innego obiektu tej samej klasy bezpośrednio wewnątrz metody?

Tak, wewnątrz metod klasy można odwoływać się do prywatnych członów innych obiektów tej samej klasy.

class Example {
    int val;
public:
    void copyVal(const Example& other) { val = other.val; } // Nie ma błędu!
};

Czy funkcja przyjacielska może uzyskać dostęp do prywatnych członów klasy?

Tak, funkcja friend ma pełny dostęp do członów private/protected klasy.

Czy można zrobić konstruktor prywatnym? Po co to potrzebne?

Tak, prywatne konstruktory często są wykorzystywane w singletonach i metodach fabrycznych do kontrolowania tworzenia instancji klasy.

Typowe błędy i antywzorce

Wszystkie człony klasy są oznaczone jako public
Gettery/settery stają się formalną otoczką bez rzeczywistego ograniczenia
Naruszenie SRP: Open-Access Class

Przykład z życia

Negatywny przypadek

Klasa BankAccount zawiera publiczną zmienną balance. Każdy kod zewnętrzny może zmienić saldo bezpośrednio, co prowadzi do błędów, które są prawie niemożliwe do zbadania.

Zalety:

Łatwe w użyciu

Wady:

Brak kontroli nad zmianami, niemożliwość dodania ograniczeń lub audytu

Pozytywny przypadek

Zmienna balance jest ukryta, są tylko chronione metody zmiany salda. Kontrole są wdrażane wewnątrz klasy.