-
-
- SMART IT
-
{{getUserDetails().email | limitToDots : 25}}
W rozdziale Modyfikatory dostępu i niedostępowe
tłumaczyliśmy czym są modyfikatory dostępu i jaki mają wpływ na widoczność poszczególnych elementów kodu. Teraz czas pójść krok dalej i wyjaśnić
pojęcie enkapsulacji, która jest silnie związana z modyfikatorami dostępu. Wbrew pozorom - mimo swojej zagmatwanej nazwy - enkapsulacja wcale nie jest skomplikowanym zagadnieniem
i można się jej nauczyć bardzo szybko.
Enkapsulacja (inaczej hermetyzacja) to ukrywanie widoczności pól danej klasy dla innych klas, co w ten sposób chroni dane przechowywane w tych polach przed niepowołanym, lub co najmniej nieuzasadnionym dostępem.
Można zapytać - co nam w takim razie po polach, które nie są widoczne? Czy w ogóle ktoś może uzyskać do nich dostęp? Odpowiedź jest prosta. Można się do nich dostać, ale tylko za pozwoleniem klasy, w której te pola się znajdują. Tak więc musi ona udostępniać publiczne metody, które umożliwią wykonanie operacji na jej polach.
Podsumujmy zatem - aby enkapsulacja była spełniona, muszą wystąpić dwa warunki:
W przykładzie widzimy, że pole name w klasie DocumentItem jest zadeklarowane
z modyfikatorem private, a równocześnie metody ustawiające i pobierające wartość z tego pola
posiadają modyfikator public. To znaczy, że klasa spełnia reguły enkapsulacji.
Klasa DocumentFactory, której zadaniem jest wyprodukowanie obiektu klasy DocumentItem może ustawić wartość pola name tylko poprzez użycie metody setName. Nie uzyskamy bezpośredniego dostępu do pola. Co więcej taka próba zakończy się błędem kompilacji:
Zobaczmy jeszcze jak to będzie wyglądało w finalnym programie. Po stworzeniu obiektu klasy DocumentItem
pobieramy wartość z pola name za pomocą metody getName. Tylko w ten sposób
możemy dostać się do przechowywanych w polu danych.
Na koniec pozostało nam jeszcze doprecyzować dlaczego w ogóle ograniczamy dostęp do danych:
Enkapsulacja (inaczej hermetyzacja) to ukrywanie widoczności pól danej klasy dla innych klas, co w ten sposób chroni dane przechowywane w tych polach przed niepowołanym, lub co najmniej nieuzasadnionym dostępem.
Można zapytać - co nam w takim razie po polach, które nie są widoczne? Czy w ogóle ktoś może uzyskać do nich dostęp? Odpowiedź jest prosta. Można się do nich dostać, ale tylko za pozwoleniem klasy, w której te pola się znajdują. Tak więc musi ona udostępniać publiczne metody, które umożliwią wykonanie operacji na jej polach.
Podsumujmy zatem - aby enkapsulacja była spełniona, muszą wystąpić dwa warunki:
- Pola klasy muszą być poprzedzone modyfikatorem private (wtedy są niewidoczne dla innych klas).
- W klasie muszą istnieć metody z modyfikatorem public, które umożliwią zmianę oraz odczyt wartości w polach (wtedy inne klasy mogą wykorzystać te metody).
Enkapsulacja na przykładzie
Załóżmy, że tworzymy aplikację do zarządzania dokumentami. Programując taki system nie chcemy udostępniać pól klasy DocumentItem innym klasom w projekcie, ale chcemy umożliwić zmianę tych pól przez te klasy. W tym celu wprowdzimy enkapsulację:
public class DocumentItem {
private String name;
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
public class DocumentFactory {
public DocumentItem create() {
DocumentItem documentItem = new DocumentItem();
documentItem.setName("Faktura za komputer");
return documentItem;
}
}
Klasa DocumentFactory, której zadaniem jest wyprodukowanie obiektu klasy DocumentItem może ustawić wartość pola name tylko poprzez użycie metody setName. Nie uzyskamy bezpośredniego dostępu do pola. Co więcej taka próba zakończy się błędem kompilacji:
public class DocumentFactory {
public DocumentItem create() {
DocumentItem documentItem = new DocumentItem();
documentItem.name = "Faktura za komputer"; // błąd kompilacji, pole name jest niewidoczne
return documentItem;
}
}
public class Start {
public static void main(String[] args) {
DocumentFactory documentFactory = new DocumentFactory();
DocumentItem documentItem = documentFactory.create();
System.out.println(documentItem.getName());
}
}
- Mamy większą kontrolę nad polami i metodami.
- Jeśli chcemy wprowadzić nową logikę dotyczącą danego pola lub zmienić starą, wówczas zmieniamy ją tylko w ramach jednej klasy. Zmieniamy kod metod operujących na tych polach, a wszystkie miejsca w projekcie używające tych metod pozostają bez zmian.
- Klasy można łatwo zaimplementować jako read-only (tylko do odczytu) - jeśli posiadają jedynie metodę odczytującą, lub write-only (tylko do zapisu) - jeśli posiadają jedynie metodę zapisującą.
- Podnosimy bezpieczeństwo danych.
Autor: Jarek Klimas
Data: 03 stycznia 2024
Labele: Backend, Podstawowy, Java
Czy informacje, które otrzymałeś, były pomocne?
Jeśli tak, zapraszam Cię do podarowania mi kawy.
Masz pytanie dotyczące tego rozdziału? Zadaj je nam!
Masz pytanie dotyczące prezentowanego materiału?
Coś jest dla Ciebie niejasne i Twoje wątpliwości przeszkadzają Ci w pełnym zrozumieniu treści?
Napisz do nas maila, a my chętnie znajdziemy odpowiednie rozwiązanie.
Najciekawsze pytania wraz z odpowiedziami będziemy publikować pod rozdziałem.
Nie czekaj. Naucz się programować jeszcze lepiej.
Coś jest dla Ciebie niejasne i Twoje wątpliwości przeszkadzają Ci w pełnym zrozumieniu treści?
Napisz do nas maila, a my chętnie znajdziemy odpowiednie rozwiązanie.
Najciekawsze pytania wraz z odpowiedziami będziemy publikować pod rozdziałem.
Nie czekaj. Naucz się programować jeszcze lepiej.
kursjava@javappa.com
Polub nas na
Facebooku:
Kliknij O nas .
Pozycjonowanie stron: Grupa TENSE