Odpowiedź.

Enkapsulacja to jedna z kluczowych zasad programowania obiektowego (OOP), która pojawiła się z potrzeby grupowania danych z funkcjami, które te dane przetwarzają, oraz ukrywania szczegółów implementacji przed użytkownikiem.

Historia zagadnienia

Od czasów powstania OOP, enkapsulacja była ukierunkowana na zwiększenie niezawodności programów, zmniejszenie błędów i poprawę łatwości utrzymania kodu. W C++ jest realizowana za pomocą mechanizmów ukrywania danych oraz zapewniania interfejsu do interakcji z obiektem.

Problem

Bez enkapsulacji wewnętrzne dane i szczegóły implementacji klasy są dostępne do zmiany z dowolnej części programu. To prowadzi do błędów, trudności w wprowadzaniu zmian i złej zarządzalności kodem.

Rozwiązanie

Enkapsulacja w C++ osiągana jest za pomocą modyfikatorów dostępu (private, protected, public) w klasach. Wewnętrzne dane klasy są deklarowane jako private lub protected, a dostęp do nich odbywa się przez otwarte metody (gettery i settery).

Przykład kodu:

class Account {
private:
    double balance;
public:
    Account(double initial) : balance(initial) {}
    double getBalance() const { return balance; }
    void deposit(double amount) {
        if (amount > 0) balance += amount;
    }
};

Kluczowe cechy:

Umożliwia rozdzielenie interfejsu i implementacji
Chroni obiekt przed niekontrolowanym dostępem i modyfikacją
Ułatwia wsparcie i rozwój kodu

Podchwytliwe pytania.

Czy człon protected może być dostępny z dowolnego miejsca programu, gdzie jest obiekt klasy?

Nie, człony protected są dostępne tylko z metod samej klasy, przyjaciół i klas pochodnych, ale nie z innych klas i nie przez obiekt zewnętrzny.

Czy publiczny człon klasy może być "enkapsulowany"?

Nie, człony publiczne nie są enkapsulowane, ich zadanie polega na zapewnieniu zewnętrznego interfejsu. Czasami zbyt otwarte człony publiczne naruszają zasadę enkapsulacji.

Czy modyfikator private zwiększa bezpieczeństwo kodu w czasie wykonywania?

Nie, modyfikatory dostępu działają tylko na poziomie kompilatora i nie zapobiegają dostępowi do danych w pliku wykonywalnym — ale ograniczają błędy projektowe.

Typowe błędy i antywzorca

Deklarowanie wszystkich członów klasy jako publiczne
Nadmiar przyjaciół (friend)
Gettery zwracające odniesienie do ukrytego członu bez const/qref
Brak walidacji w zewnętrznych setterach

Przykład z życia

Negatywny przypadek

Programista uczynił wszystkie zmienne klasy publiczne dla "prostoty logiki biznesowej".

Zalety:

Łatwo pracować na początkowych etapach
Mniej kodu do dostępu do danych

Wady:

Każdy inny programista/moduł może w dowolnym momencie zmienić stan klasy
Utrudnia to debugowanie i utrzymanie
Wzrost liczby błędów

Pozytywny przypadek

Dane zadeklarowane jako private, interakcja przez gettery/settery z obowiązkową walidacją.