[ Pobierz całość w formacie PDF ]
opisane dalej w tym rozdziale. Przeprowadzę tam krótkie porównanie klas abstrakcyj-
nych i interfejsów oraz przypadków wskazanych do ich zastosowania. Jedyną z zalet nie-
dostępnych w interfejsach, którą ma mechanizm klas abstrakcyjnych, jest możliwość
uczynienia abstrakcyjnymi niektórych klas mających wcześniej pełnoprawną funk-
cjonalność. Można tego dokonać, pokrywając w klasie pochodnej jedną lub więcej
metod metodami abstrakcyjnymi, czyli bez implementacji. Dzięki temu możemy
usunąć standardową implementację metod, wymuszając ich przyszłą, właściwszą
dla danej klasy implementację.
2.2. Obiekty
Jak kilkukrotnie zwracałem już uwagę, klasy są tylko definicją i określeniem sposobu
działania bądz przechowywania informacji. Aby klasa mogła być użyta, musimy
utworzyć jej egzemplarz, którym jest obiekt. Istnieją dwa podstawowe sposoby two-
rzenia obiektów zdefiniowanych typów tak aby były jawnie dostępne oraz w sposób
niejawny. Poniżej przedstawię różnice między nimi. Ponadto spróbuję zwrócić uwagę na
wszystkie ważne zagadnienia związane z tworzeniem i egzystowaniem obiektów w Javie.
W dalszej części tego rozdziału pokażę również sposób tworzenia obiektów z użyciem
refleksji (typy tych obiektów nie muszą być znane w czasie tworzenia programu).
2.2.1. Rozważania o adresie
Przed przystąpieniem do praktycznych przykładów tworzenia obiektów powinieneś,
zwłaszcza jeśli znasz inne języki programowania, dowiedzieć się, co wiąże się z po-
wstaniem pojedynczego egzemplarza klasy. W C++ czy Object Pascalu utworzenie
egzemplarza zmiennej typu obiektowego wiązało się z przydzieleniem jej pewnego
56 Java. Programowanie obiektowe
obszaru pamięci (jawnie bądz nie, ręcznie bądz automatycznie). Zmienna typu obiekto-
wego przechowywała wyłącznie wskazanie na obszar, w którym znajdował się obiekt,
bądz na miejsce, gdzie znajdował się opis obiektu i dalsze adresy pól oraz metod.
W Javie, wbrew obiegowym opiniom, jest dokładnie tak samo. Zmienna reprezen-
tująca obiekt to rzeczywiście wskazanie (albo według innego nazewnictwa adres) na
blok rozpoznawany przez maszynę wirtualną Javy jako zbiór wszystkich potrzebnych
informacji do jednoznacznego zidentyfikowania obiektu i poprawnego używania go.
Na tym jednak kończy się podobieństwo między wskazaniem na obiekt w Javie a w in-
nych językach. W Javie nie da się wykonać kilku podstawowych operacji dostęp-
nych w C++ czy Object Pascalu. Nie da się utworzyć samoistnego obszaru pamięci
i wymusić potraktowanie go przez kompilator bądz interpreter jako obiekt. Nie da się
dodać do wskaznika liczby będącej wielokrotnością długości słowa maszynowego,
aby odwołać się bezpośrednio do pola, metody bądz następnego obiektu w pamięci.
Najwięcej trudności sprawia natomiast przyzwyczajenie się do tego, że obiekt, który
nie jest już przez nas używany, nie może być zwolniony na nasze żądanie, tylko mu-
simy zdać się przy tym na łaskę JVM. Jednak te trzy ograniczenia sprawiają, że Java
jest językiem, który wynosi bezpieczeństwo kilka kroków naprzód, przed inne języki.
Dostajemy zalety pracy na wskaznikach i pozbawieni jesteśmy możliwości świado-
mego (bądz nie) zniszczenia sobie działającego programu. W dalszej części książki
będę używał zamiennie nazwy obiekt, egzemplarz, adres bądz wskazanie. Nie powinno
Cię to jednak zwieść. Będę cały czas mówił o tym samym o symbolicznej repre-
zentacji pojedynczego egzemplarza klasy.
Zanim przejdziemy do praktycznego stosowania obiektów, chciałbym przypomnieć,
że w Javie udostępniony jest mechanizm kompatybilności typów obiektowych wyni-
kających z dziedziczenia klas. To znaczy możemy zadeklarować obiekt jako egzem-
plarz klasy dokładnie tego samego typu, jaki tworzymy, albo jako egzemplarz dowol-
nej klasy nadrzędnej tego obiektu, czyli takiej, która znajdowała się w łańcuchu jego
dziedziczenia. W skrajnym przypadku możemy więc deklarować w Javie wszystkie
obiekty jako egzemplarze klasy Object, po której dziedziczą wszystkie klasy w Javie.
Takie podejście, jakkolwiek formalnie słuszne i niezmniejszające (dzięki mechanizmowi
polimorfizmu) funkcjonalności programu, w praktyce jest bardzo uciążliwe. Wymaga
bowiem od programisty ciągłego umieszczania referencji typu obiektu w momencie
[ Pobierz całość w formacie PDF ]
