Poprawnie – hermetyzacja (encapsulation) w programowaniu obiektowym polega właśnie na ukrywaniu szczegółów implementacji klasy i ograniczaniu dostępu do pól oraz metod, które nie powinny być widoczne na zewnątrz. W praktyce oznacza to stosowanie modyfikatorów dostępu takich jak private i protected do elementów, które są wykorzystywane tylko wewnątrz danej klasy lub hierarchii dziedziczenia. Kod zewnętrzny widzi wtedy tylko to, co jest wystawione jako public, czyli oficjalny interfejs klasy. Z mojego doświadczenia to jest jedna z kluczowych rzeczy, która odróżnia „klepanie kodu” od pisania rozsądnie zaprojektowanego oprogramowania. Dzięki hermetyzacji można bezpiecznie zmieniać wnętrze klasy (np. sposób przechowywania danych, algorytmy) bez psucia kodu, który z tej klasy korzysta. Przykład: w klasie KontoBankowe pola takie jak saldo, numer konta czy historia operacji powinny być private, a dostęp do nich powinien odbywać się przez metody typu wplac(), wyplac(), pobierzSaldo(). Użytkownik klasy nie ma prawa bezpośrednio ustawiać salda, bo mógłby ominąć logikę biznesową, np. sprawdzanie limitu czy blokady konta. W językach takich jak Java, C++, C#, ale też w nowoczesnym TypeScript czy w podejściu obiektowym w PHP i JavaScript, dobre praktyki mówią jasno: pola klasy domyślnie robimy prywatne, a udostępniamy tylko to, co naprawdę musi być publiczne. Moim zdaniem to jedna z najważniejszych zasad SOLID (dokładniej – silnie się z nimi łączy), bo wymusza tworzenie małych, spójnych i bezpiecznych interfejsów. W większych projektach webowych, np. w aplikacjach backendowych w PHP lub JS/TS, brak hermetyzacji szybko kończy się „makaronem zależności”, gdzie jedna zmiana w polu klasy rozwala pół systemu. Dlatego branżowo uznaje się hermetyzację za absolutny standard projektowania obiektowego, a łamanie jej za klasyczny „code smell”.
Hermetyzacja to pojęcie, które dość często miesza się z innymi zasadami programowania obiektowego, takimi jak dziedziczenie, polimorfizm czy współdzielenie funkcjonalności między klasami. W efekcie powstaje takie wrażenie, że chodzi po prostu o „współpracę obiektów” albo „możliwość rozszerzania klas”, co jest tylko częścią obrazu, ale nie definicją hermetyzacji. Sedno hermetyzacji polega na ukrywaniu stanu obiektu i szczegółów implementacyjnych za dobrze zdefiniowanym interfejsem. Klasa ma swoje pola i metody pomocnicze, ale kod na zewnątrz widzi tylko to, co programista świadomie wystawi jako public. Pozostałe odpowiedzi dotykają innych cech obiektowości. Współdzielenie funkcjonalności między klasami to bardziej temat dziedziczenia, kompozycji albo używania wspólnych modułów czy interfejsów. To, że dwie klasy mogą mieć podobne metody i wykorzystywać wspólny kod, nie ma bezpośrednio nic wspólnego z hermetyzacją. Można mieć świetnie współdzieloną logikę, a kompletnie zignorować ukrywanie szczegółów implementacji i bezpieczeństwo stanu obiektów. Z kolei pomysł, że typy pól w klasach mogą się dynamicznie zmieniać w zależności od danych, dotyczy raczej systemu typów i języków dynamicznych, jak JavaScript czy PHP w trybie bez ścisłego typowania. To jest kwestia dynamicznego typowania, a nie hermetyzacji. Można mieć język statycznie typowany (np. Java, C#) i świetną hermetyzację, i można mieć język dynamicznie typowany, w którym hermetyzacja jest słaba lub w ogóle nieprzestrzegana. Natomiast metody wirtualne, nadpisywanie ich w klasach pochodnych, późne wiązanie wywołań – to klasyczny polimorfizm, nie hermetyzacja. Owszem, te koncepcje często występują razem w jednym projekcie, przez co łatwo się mylą, ale ich cele są inne. Polimorfizm pozwala różnym klasom reagować inaczej na to samo wywołanie metody, hermetyzacja zaś skupia się na tym, żeby ukryć wnętrze obiektu i wystawić tylko kontrolowany interfejs. Typowym błędem myślowym jest utożsamianie „obiektowości jako całości” z pojedynczymi jej elementami. Ktoś widzi dziedziczenie albo metody wirtualne i zakłada, że to już automatycznie „hermetyzacja”. W praktyce dobra hermetyzacja to przede wszystkim rozsądne używanie private/protected, unikanie publicznych pól, a także pilnowanie, żeby stan obiektu był spójny i nie dało się go przypadkiem popsuć z zewnątrz. To właśnie ta ochrona wnętrza klasy, a nie możliwość dziedziczenia czy dynamicznego typowania, jest tutaj kluczowa.