Znaczenie pojęcia:

hermetyzacja

Pozostałe definicje na literę H.

ang. encapsulation

Zamknięcie pewnego zestawu bytów programistycznych w "kapsułę" o dobrze określonych granicach; oddzielenie abstrakcyjnej specyfikacji tej kapsuły (obiektu, klasy, modułu, etc.) od jej implementacji; ukrycie części informacji zawartej w tej kapsule dla operacji z zewnątrz obiektu. Hermetyzacja jest podstawową techniką abstrakcji, tj. ukrycia wszelkich szczegółów danego przedmiotu lub bytu programistycznego, które na danym etapie rozpatrywania (analizy, projektowania, programowania) nie stanowią jego istotnej charakterystyki. Hermetyzacja jest starą zasadą inżynierii oprogramowania (sformułował ją D. Parnas w 1975 r.) i znalazła swoje odbicie w takich pojęciach programistycznych jak moduł, abstrakcyjny typ danych i obiekt/klasa (co za tym idzie, niektórzy autorzy wyróżniają trzy rodzaje hermetyzacji).W obiektowości dość popularnym stereotypem jest koncepcja ortodoksyjnej hermetyzacji (Smalltalk), w której wszelkie operacje, które można wykonać na obiekcie, są określone przez metody przypisane do obiektu; bezpośredni dostęp do atrybutów obiektu jest niemożliwy. Oznacza to często, że każdy atrybut obiektu musi być wyposażony w dwie metody: CzytajWartość i ZmieńWartość; takie założenie przyjmuje np. standard CORBA. Alternatywą jest hermetyzacja ortogonalna (C++, Eiffel), gdzie dowolny atrybut obiektu (i dowolna metoda) może być prywatny (niedostępny z zewnątrz) lub publiczny. Atrybut publiczny może być obsłużony przez operatory generyczne, takie jak odzyskanie referencji do atrybutu (czyli wiązanie), podstawienie i dereferencja. Zwolennicy ortodoksyjnej hermetyzacji argumentują, że zapewnia ona rzekomo brak możliwości zrobienia na obiektach danej klasy czegokolwiek, co nie zostało przewidziane przez projektanta tej klasy. Tę argumentację łatwo obalić, gdyż udostępnienie atrybutu poprzez metody CzytajWartość i ZmieńWartość jest semantycznie równoważne udostępnieniu danego atrybutu do przetwarzania poprzez w/w operatory generyczne.Ortodoksyjna hermetyzacja jest ponadto semantycznie i koncepcyjnie niespójna, jeżeli założymy, że atrybuty mogą być powtarzalne, czyli mogą być kolekcjami o nieznanym i nieograniczonym rozmiarze; np. atrybut WypożyczoneKsiążki dla obiektów Student. W takich przypadkach zwolennicy ortodoksyjnej hermetyzacji sugerują, że potrzebne są metody takie jak DajPierwszy, DajNastępny, CzyOstatni (zaimplementowane np. w postaci iteratora). W takim przypadku powstaje pytanie, co mają zwrócić metody DajPierwszy i DajNastępny. Odpowiedź na to pytanie jest prosta: muszą one zwrócić referencje do (kolejnych) wartości tego atrybutu. Udostępnienie tych referencji na zewnątrz oznacza wyłom w koncepcji ortodoksyjnej hermetyzacji; np. takie referencje mogą być użyte w operacji podstawienia, przekazane jako call-by-reference parametr do procedury, itd. Dodatkowo, schemat iteracyjny DajPierwszy, DajNastępny, CzyOstatni (lub podobny) ustala określony porządek przetwarzania elementów, co oznacza, że kolekcje takie jak zbiory i wielozbiory stają się fikcją (oraz związane z nimi ewentualne metody optymalizacyjne). Poważnym argumentem na niekorzyść ortodoksyjnej hermetyzacji są języki zapytań, których semantyka bazuje na bezpośrednim wiązaniu nazw występujących w zapytaniu z wartościami atrybutów. Z tego względu C.J.Date uważa, że koncepcja hermetyzacji powinna być w ogóle odrzucona. Date w swoich wnioskach idzie za daleko; wystarczy bowiem zrezygnować z ortodoksyjnej hermetyzacji na rzecz hermetyzacji ortogonalnej, takiej, jak w C++, Eiffel, Modula-2, i innych językach (czyli wrócić do oryginalnego pomysłu D.Parnasa). Hermetyzacja ortogonalna nie prowadzi do jakichkolwiek sprzeczności z językami zapytań. Poniższy rysunek jest ilustracją hermetyzacji ortogonalnej.Wewnętrzna struktura obiektuZewnętrzna struktura obiektu

hermetyzacja,
encapsulation