Hermetyzacja to zasada programowania obiektowego mówiąca o tym, że

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”.