Odpowiedź.

Enkapsulacja to zasada projektowania obiektowego, która polega na ukrywaniu wewnętrznej budowy obiektu i udostępnianiu tylko niezbędnego publicznego interfejsu.

Historia pytania: Od samego początku OOP jednym z kluczowych zadań była ochrona wewnętrznego stanu obiektów przed niewłaściwą zmianą z zewnątrz oraz zapewnienie ścisłej kontroli nad logiką.

Problem: Bez enkapsulacji wszystkie dane i metody stają się dostępne dla kodu zewnętrznego, co prowadzi do utraty kontroli nad stanem obiektów i pojawiania się trudnych do uchwycenia błędów.

Rozwiązanie: W C++ używa się trzech specyfikatorów dostępu: private, protected, public. private zabrania dostępu do członków z zewnątrz klasy, protected daje dostęp tylko dziedziczącym, a public czyni członków częścią interfejsu.

Przykład kodu:

class Stack {
private:
    int *data;
    int top;
public:
    Stack();
    void push(int val);
    int pop();
};

Kluczowe cechy:

• Kontrola dostępu do członków klasy
• Wyraźne rozdzielenie interfejsu i implementacji
• Umożliwia zmianę wewnętrznej struktury bez wpływu na użytkowników

Pytania z podstępem.

Czy prawdą jest, że członkom private nie można w żaden sposób zmienić dostępu z zewnątrz klasy?

Nieprawda. Można użyć funkcji friends, klas friends lub niebezpiecznych technik (na przykład przez rzutowanie wskaźników lub przez undefined behavior).

W jakiej kolejności stosowane są specyfikatory przy dziedziczeniu (private, protected, public)?

Jeśli dziedziczenie zadeklarowane jest jako private, wszyscy public i protected członkowie klasy bazowej stają się członkami typu private klasy pochodnej.

Czym różnią się dziedziczenie protected i private?

W przypadku dziedziczenia protected wszyscy public i protected członkowie klasy bazowej stają się protected członkami klasy pochodnej; w przypadku private — wszyscy stają się private.

Typowe błędy i antywzorce

• Otwieranie całej struktury (wszystko public)
• Przechowywanie wskaźników i udostępnienie ich dostępu na zewnątrz (naruszenie enkapsulacji)
• Ukrywanie interfejsu razem z implementacją (zbyt sztywne ograniczenia)

Przykład z życia

Negatywny przypadek

Wszystkie członkowie klasy są zadeklarowane jako public, wszelki zewnętrzny kod może zmieniać strukturę i naruszać inwarianty obiektu.

Zalety:

• Szybkie prototypowanie

Wady:

• Brak zapewnienia poprawności; wiele błędów w dużych projektach

Pozytywny przypadek

Używane są tylko niezbędne metody publiczne, a pozostałe dane są zamknięte (private), stan jest chroniony.

Zalety:

• Łatwość w utrzymywaniu kodu
• Minimalizacja błędów

Wady:

• Czasami trzeba pisać wrappery (getter/setter), które mogą być nadmiarowe dla celów wewnętrznych