Jaka jest różnica między „ukrywaniem danych” a „enkapsulacją”?

Czytam „Współbieżność Java w praktyce” i powiedziano: „Na szczęście te same techniki obiektowe, które pomagają pisać dobrze zorganizowane, możliwe do utrzymania klasy - takie jak enkapsulacja i ukrywanie danych - mogą również pomóc w tworzeniu bezpiecznych wątków klasy ”.

Problem nr 1 - Nigdy nie słyszałem o ukrywaniu danych i nie wiem, co to jest.

Problem nr 2 - Zawsze myślałem, że enkapsulacja korzysta z prywatnego vs. publicznego i faktycznie ukrywa dane.

Czy możesz wyjaśnić, czym jest ukrywanie danych i czym różni się od enkapsulacji?

Ukrywanie danych i informacji to szersze pojęcia, które można znaleźć w informatyce i inżynierii oprogramowania. Odnosi się do faktu, że ta część programu komputerowego, która może ulec zmianie, nie może być dostępna z innych modułów / od klientów.

Hermetyzacja jest terminem występującym w paradygmacie obiektowym i odnosi się do przechowywania danych w polach prywatnych i modyfikowania ich tylko metodami.

A zatem enkapsulacja może być postrzegana jako sposób na osiągnięcie ukrywania danych w systemach obiektowych .

Hermetyzacja i ukrywanie danych to powiązane terminy. Ważne jest, aby zrozumieć, że powstają one w związku z abstrakcją . Booch i in. glin. w obiektowej analizie i projektowaniu za pomocą aplikacji wyjaśnia,

Abstrakcja i enkapsulacja są koncepcjami komplementarnymi: abstrakcja koncentruje się na obserwowalnym zachowaniu obiektu, podczas gdy enkapsulacja koncentruje się na implementacji, która powoduje takie zachowanie. Hermetyzację najczęściej osiąga się poprzez ukrywanie informacji (nie tylko ukrywanie danych), czyli proces ukrywania wszystkich tajemnic obiektu, które nie przyczyniają się do jego zasadniczych cech; zazwyczaj struktura obiektu jest ukryta, podobnie jak implementacja jego metod.

Tworzenie klasy obejmuje pojęcie enkapsulacji. Kiedy tworzysz klasę, umieszczasz w niej dane i zachowania, a klasa staje się jedną jednostką, którą nazywamy obiektem. Ukrywanie danych jest więc częścią enkapsulacji.

Z Wikipedii :

W języku programowania enkapsulacja jest używana w odniesieniu do jednego z dwóch powiązanych, ale odrębnych pojęć, a czasem do ich kombinacji:

• Mechanizm językowy do ograniczania dostępu do niektórych składników obiektu.
• Konstrukcja językowa, która ułatwia wiązanie danych z metodami (lub innymi funkcjami) działającymi na tych danych.

Niektórzy badacze i naukowcy zajmujący się językiem programowania wykorzystują pierwsze znaczenie samodzielnie lub w połączeniu z drugim jako cechę wyróżniającą programowanie obiektowe, podczas gdy inne języki programowania, które zapewniają zamknięcie leksykalne, opisują enkapsulację jako cechę języka ortogonalnego do orientacji obiektowej.

Druga definicja jest motywowana faktem, że w wielu językach OOP ukrywanie komponentów nie jest automatyczne lub może zostać zastąpione; dlatego ukrywanie informacji jest definiowane jako osobne pojęcie przez tych, którzy preferują drugą definicję.

Często są one stosowane zamiennie w dyskusji i często myślę, że współpracują ze sobą, aby osiągnąć ten sam cel, i chociaż poniższe elementy mogą nie być całkowicie dokładne, może zapewnić pewne znaczące rozróżnienie, jeśli trzeba wprowadzić rozróżnienie:

Mówiąc o enkapsulacji, często jest ona implementowana jako mechanizm proceduralny / funkcjonalny. Istnieje pewien rodzaj ochrony dla stanu bazowego, a dostęp przez tę ochronę wymaga przestrzegania pewnych protokołów, aby uzyskać dostęp (odczyt lub zmiana pożądanego stanu). Hermetyzacja oferuje również możliwość wystąpienia efektów ubocznych z powodu dostępu (takich jak zmiana stanu kaskadowego lub powiadomienie / wywołanie zdarzenia / wydanie sygnału, gdy interesująca rzecz zostanie odczytana lub zmieniona), dzięki czemu można zainicjować działania następcze. Ponownie często myślę o enkapsulacji jako koncepcji, która jest realizowana jako procedura.

Widzę, że koncepcja ukrywania danych ma podobny cel do enkapsulacji; mechanizm ten ma jednak charakter strukturalny i działa na innym poziomie. W praktyce, zamiast zapewniać mechanizm ochronny i efekt uboczny poprzez procedurę, stan jest chroniony i wpływa na to mechanizmy strukturalne języka i środowiska wykonawczego. Tego rodzaju osłony byłyby klauzulami widoczności, definicjami typów, dziedziczeniem i tym podobnymi. Efekty uboczne, które można wykorzystać z obiektów chronionych strukturalnie, są znowu czymś zależnym od języka i środowiska wykonawczego: być może aktywacja obiektu, liczba referencji lub coś podobnego.

Często są, może zwykle, używane zamiennie. Ale zauważ, że powyższy cytat Boocha mówi: „Hermetyzację najczęściej osiąga się poprzez ukrywanie informacji…”, tj. Najczęściej, ale nie zawsze w każdym przypadku.

Zauważ, że Python pozwala na zwijanie danych w klasach, ale nie zezwala na zmienne prywatne. Można więc powiedzieć, że Python zapewnia enkapsulację bez ukrywania danych.

Możesz zrobić to samo w Javie, wykonując wszystkie zmienne składowe public, ale oprócz zadawania każdemu zawału serca stracisz korzyść z ukrywania danych ... tj. Zachowując semantykę obiektu poprzez ograniczenie dostępu do jego stanu.

W OO enkapsulacja to miejsce, w którym informacja jest przechowywana w obiekcie. Na przykład, a Personma nameklientów i Osoba (tj. Ty) wie, że Osoba ma imię, albo za pośrednictwem pól publicznych, albo metod dostępu. I miejmy nadzieję, że nie trzeba również przechowywać nazw w globalnej tablicy nazw itp. Jest to więc duży krok, aby uniknąć niemożliwego do zarządzania kodu spaghetti. Ale klient nadal musi wiedzieć coś o tym, jak Osoba obsługuje nazwy: np. Spacja lub przecinek?

Ukrywanie danych to miejsce, w którym Personznajduje się pole nazwy, ale przynajmniej w teorii nikt nie wie . Pole jest prywatne bez publicznych metod dostępu. Klienci mogą przekazać nazwę z rekordu bazy danych, XML, HTTP POST, cokolwiek, ale wewnętrzne działanie tego, jak Osoba obsługuje nazwę, to „czarna skrzynka”. Przyszłe implementacje Person mogą zmieniać, na przykład przejść na posiadanie a firstNamei a lastName.

W idealnym świecie ukrywanie danych jest lepsze niż enkapsulacja, ale nie wszystkie światy są idealne. :-)