IDZ DO
IDZ DO
PRZYKŁADOWY ROZDZIAŁ
PRZYKŁADOWY ROZDZIAŁ
Efektywne programowanie
SPIS TRE CI
SPIS TRE CI
w języku Java
KATALOG KSIĄŻEK
KATALOG KSIĄŻEK
Autor: Joshua Bloch
Tłumaczenie: Paweł Gonera
KATALOG ONLINE
KATALOG ONLINE
ISBN: 83-7197-989-4
Tytuł oryginału: Effective Java Programming Language
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
Format: B5, stron: 214
Przykłady na ftp: 48 kB
TWÓJ KOSZYK
TWÓJ KOSZYK
Java to wspaniałe narzędzie w rękach programisty. Ale nawet najlepsze narzędzie może
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
zostać le użyte. Istnieje wiele książek, które opisują ten język programowania
skupiając się na przedstawieniu jego składni. Ta książka jest zupełnie inna. Adresowana
jest do osób znających już Javę i przedstawia praktyczne zasady pisania efektywnego,
CENNIK I INFORMACJE
CENNIK I INFORMACJE
poprawnego kodu.
Każda wskazówka omówiona jest w osobnym podrozdziale opisującym dany problem,
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
O NOWO CIACH
O NOWO CIACH
przykłady poprawnego (i błędnego!) kodu, a także historie zaczerpnięte z bogatego
do wiadczenia autora. Ta książka zapozna Cię z idiomami wła ciwymi językowi Java
ZAMÓW CENNIK oraz z istotnymi z praktycznego punktu widzenia wzorcami projektowymi.
ZAMÓW CENNIK
CZYTELNIA
CZYTELNIA
FRAGMENTY KSIĄŻEK ONLINE
FRAGMENTY KSIĄŻEK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Spis treści
Słowo wstępne ..................................................................................7
Przedmowa........................................................................................9
Wprowadzenie .................................................................................11
Rozdział 1. Tworzenie i usuwanie obiektów ........................................................15
Temat 1. Tworzenie statycznych metod factory zamiast konstruktorów..........................15
Temat 2. Wymuszanie właściwości singleton za pomocą prywatnego konstruktora .......18
Temat 3. Wykorzystanie konstruktora prywatnego
w celu uniemożliwienia utworzenia obiektu ..................................................................20
Temat 4. Unikanie powielania obiektów...........................................................................21
Temat 5. Usuwanie niepotrzebnych referencji do obiektów.............................................24
Temat 6. Unikanie finalizatorów.......................................................................................27
Rozdział 2. Metody wspólne dla wszystkich obiektów.........................................31
Temat 7. Zachowanie założeń w trakcie przedefiniowywania metody equals .................31
Temat 8. Przedefiniowywanie metody hashCode wraz z equals ......................................39
Temat 9. Przedefiniowywanie metody toString................................................................44
Temat 10. Rozsądne przedefiniowywanie metody clone..................................................46
Temat 11. Implementacja interfejsu Comparable .............................................................53
Rozdział 3. Klasy i interfejsy..............................................................................59
Temat 12. Ograniczanie dostą pności klas i ich składników..............................................59
Temat 13. Zapewnianie niezmienności obiektu................................................................62
Temat 14. Zastą powanie dziedziczenia kompozycją........................................................69
Temat 15. Projektowanie i dokumentowanie klas przeznaczonych do dziedziczenia......74
Temat 16. Stosowanie interfejsów zamiast klas abstrakcyjnych ......................................78
Temat 17. Wykorzystanie interfejsów jedynie do definiowania typów............................83
Temat 18. Zalety stosowania statycznych klas składowych .............................................84
Rozdział 4. Odpowiedniki konstrukcji języka C ...................................................89
Temat 19. Zastą powanie struktur klasami.........................................................................89
Temat 20. Zamiana unii na hierarchią klas .......................................................................91
Temat 21. Zastą powanie konstrukcji enum za pomocą klas.............................................94
Temat 22. Zastą powanie wskazników do funkcji za pomocą klas i interfejsów...................103
Rozdział 5. Metody..........................................................................................107
Temat 23. Sprawdzanie poprawności parametrów .........................................................107
Temat 24. Defensywne kopiowanie................................................................................109
Temat 25. Projektowanie sygnatur metod.......................................................................112
Temat 26. Rozsądne korzystanie z przeciążania.............................................................114
Temat 27. Zwracanie pustych tablic zamiast wartości null ............................................118
Temat 28. Tworzenie komentarzy dokumentujących
dla wszystkich udostą pnianych elementów API...........................................................120
6 Efektywne programowanie w języku Java
Rozdział 6. Programowanie..............................................................................125
Temat 29. Ograniczanie zasią gu zmiennych lokalnych ..................................................125
Temat 30. Poznanie i wykorzystywanie bibliotek ..........................................................128
Temat 31. Unikanie typów float i double, gdy potrzebne są dokładne wyniki...............131
Temat 32. Unikanie typu String, gdy istnieją bardziej odpowiednie typy......................133
Temat 33. Problemy z wydajnością przy łączeniu ciągów znaków................................135
Temat 34. Odwoływanie sią do obiektów poprzez interfejsy .........................................136
Temat 35. Stosowanie interfejsów zamiast refleksyjności..............................................137
Temat 36. Rozważne wykorzystywanie metod natywnych ............................................140
Temat 37. Unikanie optymalizacji ..................................................................................141
Temat 38. Wykorzystanie ogólnie przyją tych konwencji nazewnictwa .........................144
Rozdział 7. Wyjątki .........................................................................................147
Temat 39. Wykorzystanie wyjątków w sytuacjach nadzwyczajnych .............................147
Temat 40. Stosowanie wyjątków przechwytywalnych i wyjątków czasu wykonania.......149
Temat 41. Unikanie niepotrzebnych wyjątków przechwytywalnych .............................151
Temat 42. Wykorzystanie wyjątków standardowych .....................................................153
Temat 43. Zgłaszanie wyjątków właściwych dla abstrakcji ...........................................155
Temat 44. Dokumentowanie wyjątków zgłaszanych przez metodą ...............................157
Temat 45. Udostą pnianie danych o błą dzie ....................................................................158
Temat 46. Zachowanie atomowości w przypadku błą du ................................................159
Temat 47. Nie ignoruj wyjątków.....................................................................................161
Rozdział 8. Wątki............................................................................................163
Temat 48. Synchronizacja dostą pu do wspólnych modyfikowalnych danych................163
Temat 49. Unikanie nadmiarowej synchronizacji...........................................................168
Temat 50. Nigdy nie wywołuj wait poza pą tlą................................................................172
Temat 51. Unikanie korzystania z systemowego szeregowania wątków........................174
Temat 52. Dokumentowanie bezpieczeństwa dla wątków..............................................177
Temat 53. Unikanie grup wątków...................................................................................180
Rozdział 9. Serializacja....................................................................................181
Temat 54. Implementowanie interfejsu Serializable.......................................................181
Temat 55. Wykorzystanie własnej postaci serializowanej..............................................185
Temat 56. Defensywne tworzenie metody readObject ...................................................191
Temat 57. Tworzenie metody readResolve.....................................................................196
Dodatek A Zasoby..........................................................................................199
Skorowidz......................................................................................203
Rozdział 4.
Odpowiedniki konstrukcji
języka C
Ją zyk programowania Java posiada wiele podobieństw do ją zyka C, ale kilka jego kon-
strukcji zostało pominią tych. W wią kszości przypadków oczywiste jest, dlaczego dana
konstrukcja została pominią ta i w jaki sposób można sobie bez niej radzić. W rozdziale
tym zaproponujemy zamienniki dla kilku pominią tych konstrukcji ją zyka C, których
zastąpienie nie jest tak oczywiste.
Najczą stszym wątkiem, który przewija sią przez cały ten rozdział, jest twierdzenie, że
wszystkie pominią te konstrukcje były zorientowane na dane, a nie zorientowane obiek-
towo. Ją zyk programowania Java zawiera bardzo wydajny system typów i propono-
wane zamienniki w pełni korzystają z tego systemu w celu zapewnienia wyższego
stopnia abstrakcji niż konstrukcje ją zyka C, które są przez nie zastą powane.
Nawet jeżeli zdecydujesz sią na pominią cie tego rozdziału, warto zapoznać sią z tema-
tem 21., poświą conym typowi wyliczeniowemu, który zastą puje konstrukcją , dostą p-
ną w ją zyku C. Wzorzec ten nie był powszechnie znany w czasie pisania tej książki,
a posiada znaczną przewagą nad obecnie stosowanymi rozwiązaniami tego problemu.
Temat 19. Zastępowanie struktur klasami
Konstrukcja ją zyka C została usunią ta z ją zyka Java, ponieważ za pomocą klasy
można zrealizować wszystko to, co potrafi struktura, a nawet wią cej. Struktura jedy-
nie grupuje kilka pól danych w jeden obiekt klasa zawiera operacje wykonywane na
wynikowym obiekcie i pozwala na ukrycie pól danych przed użytkownikiem obiektu.
Inaczej mówiąc, klasa hermetyzuje dane w obiekcie i umożliwia dostą p do nich jedy-
nie za pomocą metod, co pozwala twórcy klasy na swobodną zmianą reprezentacji
danych w pózniejszym czasie (temat 12.).
W czasie pierwszych pokazów ją zyka Java niektórzy programiści korzystający z ją zyka
C uważali, że klasy są zbyt obszerne, aby w pewnych sytuacjach zastąpić struktury.
90 Efektywne programowanie w języku Java
Nie bą dziemy sią zajmowali tym problemem. Zdegenerowane klasy składające sią jedynie
z pól danych są pewnym przybliżeniem struktur z ją zyka C:
Ponieważ takie klasy pozwalają na dostą p do swoich pól, nie pozwalają na skorzysta-
nie z zalet hermetyzacji. Nie można zmienić reprezentacji danych w takiej klasie bez
zmiany API, nie można wymuszać żadnych ograniczeń oraz nie można podejmować
dodatkowych zadań podczas modyfikacji pola. Ortodoksyjni programiści obiektowi
uważają, że takie klasy są zakazane i powinny zawsze być zastą powane klasami z polami
prywatnymi oraz publicznymi metodami je udostą pniającymi:
Oczywiście twierdzenie to jest prawdziwe w odniesieniu do klas publicznych jeżeli
klasa jest dostą pna spoza swojego pakietu, rozważny programista powinien zabezpie-
czyć sobie możliwość zmiany wewną trznej reprezentacji danych. Jeżeli klasa publiczna
udostą pnia swoje pola, nie ma możliwości zmiany reprezentacji danych, ponieważ kod
klientów, korzystający z klasy publicznej, może być już rozesłany po całym świecie.
Jeżeli jednak klasa jest prywatna w ramach pakietu lub jest to prywatna klasa zagnież-
dżona, nie ma nic złego w bezpośrednim udostą pnieniu pól danych zakładając, że
naprawdą opisują abstrakcją definiowaną przez klasą . Podejście to generuje mniej kodu
niż wykorzystanie metod dostą powych, zarówno w definicji klasy, jak i w kodzie klientów
ją wykorzystujących. Ponieważ kod klientów jest ściśle związany z wewną trzną repre-
zentacją klasy, jest on ograniczony do pakietu, w którym klasa ta jest zdefiniowana.
W przypadku, gdy konieczna jest zmiana reprezentacji danych, możliwe jest wpro-
wadzenie zmian bez konieczności zmiany kodu poza pakietem. W przypadku prywat-
nej klasy zagnieżdżonej zasią g zmian jest ograniczony do klasy nadrzą dnej.
Kilka klas w bibliotekach ją zyka Java nie dotrzymuje zalecenia, aby klasy publiczne nie
udostą pniały bezpośrednio swoich pól. Przykładami takich klas są klasy i
z pakietu . Przykłady te nie powinny być naśladowane należałoby raczej
Rozdział 4. f& Odpowiedniki konstrukcji języka C 91
wskazywać je jako przykład negatywny. W temacie 37. opisany został przykład poka-
zujący, jak udostą pnienie pól w klasie spowodowało problemy z wydajno-
ścią. Problemy te nie mogą zostać usunią te bez wpływania na kod klientów.
Temat 2O. Zamiana unii na hierarchię klas
Konstrukcja ją zyka C jest najczą ściej wykorzystywana do definiowania
struktur, umożliwiających przechowywanie wią cej niż jednego typu danych. Struktura
taka zwykle posiada co najmniej dwa pola unią i znacznik. Pole znacznika jest
zwykłym polem, wykorzystywanym do wskazywania aktualnego typu danych, prze-
chowywanego przez unią . Znacznik jest najczą ściej typu wyliczeniowego ( ).
Struktura zawierająca unią i znacznik jest czasami nazywaną unią z dyskryminatorem.
Poniżej przedstawiamy przykład definicji typu , zapisany w ją zyku C. Jest to
unia z dyskryminatorem, reprezentująca prostokąt lub koło. Funkcja na podstawie
wskaznika do struktury zwraca pole figury lub , jeżeli struktura zawiera
nieprawidłowe dane.
92 Efektywne programowanie w języku Java
Projektanci ją zyka Java postanowili nie wprowadzać konstrukcji , ponieważ ist-
nieje dużo lepszy mechanizm definiowania typów umożliwiających reprezentowanie
różnych typów dziedziczenie. Unie z dyskryminatorem są jedynie mało wydajną
imitacją hierarchii klas.
Aby zamienić unią z dyskryminatorem na hierarchią klas, należy zdefiniować klasą
abstrakcyjną zawierającą metody abstrakcyjne dla każdej operacji, której działanie
jest zależne od wartości znacznika. We wcześniejszym przykładzie przedstawiona
była tylko jedna taka operacja . Ta klasa abstrakcyjna staje sią korzeniem hie-
rarchii klas. Jeżeli istnieją inne operacje, niezależne od wartości znacznika, należy
zdefiniować odpowiednie metody w klasie bazowej. Podobnie, jeżeli w unii z dyskrymi-
natorem istnieją pola danych poza znacznikiem i unią, reprezentujące typy danych
wspólne dla wszystkich typów, powinny być one dodane do klasy bazowej. W naszym
przykładzie nie było żadnych składników niezależnych od typów.
Nastą pnie dla każdego typu reprezentowanego w unii z dyskryminatorem definiujemy
klasy, dziedziczące z klasy bazowej. W naszym przykładzie typami tymi są: koło i prosto-
kąt. W każdej z klas podrzą dnych należy umieścić pola danych odpowiednie dla jej typu.
W naszym przykładzie dla koła jest to promień, a dla prostokąta długość i szerokość. Na
koniec definiujemy odpowiednie implementacje metod abstrakcyjnych z klasy bazowej.
Poniżej przedstawiamy hierarchią klas dla naszego przykładu unii z dyskryminatorem:
Hierarchia klas posiada wiele zalet w porównaniu z unią z dyskryminatorem. Najważ-
niejszą z nich jest ta, że hierarchia klas zapewnia kontrolą typów. W naszym przykładzie
każdy obiekt może być jedynie prawidłowym obiektem lub .
Bardzo prosto wygenerować strukturą , która bą dzie całkowicie nieprzydatna,
ponieważ połączenie pomią dzy znacznikiem i unią nie jest wymuszane przez ją zyk
programowania. Jeżeli znacznik wskazuje, że reprezentuje prostokąt, ale unia
Rozdział 4. f& Odpowiedniki konstrukcji języka C 93
została zainicjowana danymi koła, wszystko może sią zdarzyć. Nawet, gdy unia z dys-
kryminatorem zostanie prawidłowo zainicjowana, możliwe jest omyłkowe przekazanie
jej do funkcji nieodpowiedniej dla danej wartości znacznika.
Drugą zaletą hierarchii klas jest łatwość rozszerzania, nawet o wiele niezależnie działa-
jących czą ści. Aby rozszerzyć hierarchią klas, wystarczy dodać nową kasą pochodną.
Jeżeli zapomnisz zdefiniować jednej z metod abstrakcyjnych, natychmiast wskaże Ci
to kompilator. Aby rozbudować unią z dyskryminatorem, należy mieć dostą p do kodu
zródłowego. Musisz dodać nową wartość do typu oraz nową gałąz do instrukcji
w każdej funkcji operującej na unii. Na koniec musisz skompilować kod. Jeżeli
w którejś funkcji zapomnisz dodać nowego przypadku, kompilator nie bą dzie w stanie
tego wykryć. Pozostaje umieszczenie w kodzie kontroli niespodziewanych wartości
znacznika i generowanie w takich sytuacjach komunikatów błą dów.
Czwartą zaletą hierarchii klas jest możliwość odwzorowania naturalnych relacji hierar-
chicznych pomią dzy typami, co pozwala na zwią kszenie elastyczności i lepszej kontroli
typów w czasie kompilacji. Załóżmy, że do naszego oryginalnego przykładu chcemy
dodać obsługą kwadratów. W hierarchii klas możemy odwzorować fakt, że kwadrat
jest specjalnym rodzajem prostokąta (zakładając, że oba są niezmienne):
Przedstawiona hierarchia klas nie jest jedynym rozwiązaniem naszego problemu. Hierar-
chia ta powstała po podją ciu kilku decyzji, o których warto wspomnieć. Klasy w hierar-
chii, poza , udostą pniają swoje pola, nie oferując metod dostą powych. W przy-
padku klas publicznych jest to nie do zaakceptowania, ale nam zależało na zwią złości
kodu (temat 19.). Klasy te są niezmienne. Czasami nie jest to najlepsze, jednak naj-
czą ściej właśnie takie rozwiązanie jest właściwe (temat 13.).
Ponieważ ją zyk Java nie zawiera konstrukcji , można uważać, że nie ma niebez-
pieczeństwa utworzenia unii z dyskryminatorem. Możliwe jest jednak napisanie kodu,
który bą dzie posiadał te same wady. Jeżeli kiedykolwiek bą dziesz chciał napisać klasą
z polem znacznikowym, należy pomyśleć o eliminacji pola znacznikowego przez mo-
dyfikacją hierarchii klas.
Innym zastosowaniem konstrukcji w ją zyku C, całkowicie niezwiązanym z uniami
z dyskryminatorem, jest możliwość oglądania wewną trznej reprezentacji danych poprzez
umyślne omijanie systemu typów. Metoda ta demonstrowana jest przez poniższy fragment
kodu w ją zyku C, który drukuje wewną trzną postać liczby w postaci szesnastkowej:
94 Efektywne programowanie w języku Java
Choć może być to użyteczne, szczególnie dla programistów systemowych, takie nieprze-
nośne zastosowanie nie ma odpowiednika w ją zyku Java. Działanie takie nie może
być dopuszczalne w ją zyku, który gwarantuje bezpieczeństwo typów i nieomal izoluje
programistów od wewną trznej reprezentacji danych.
Pakiet zawiera metody pozwalające przekształcić liczby zmiennoprzecin-
kowe na ich bitową reprezentacją , ale działanie tych metod jest bardzo dokładnie zde-
finiowane w celu zapewnienia ich przenośności. Poniższy fragment kodu jest luznym
odpowiednikiem przedstawionego kodu w ją zyku C, ale gwarantuje uzyskanie iden-
tycznych wyników bez wzglą du na platformą , na której jest uruchomiony:
Temat 21. Zastępowanie konstrukcji enum
za pomocą klas
Konstrukcja również nie została przeniesiona do ją zyka Java. Konstrukcja ta służy
do definiowania typu wyliczeniowego typu, składającego sią ze stałego zbioru
wartości. Niestety, konstrukcja ta nie jest zbyt zaawansowana. Definiuje ona tylko
zbiór nazwanych stałych typu , nie zapewniając żadnego mechanizmu kontroli
typów. W ją zyku C można wykonać nastą pujące wyrażenia:
ale takie jest nieprawidłowe:
Konstrukcja nie zawiera przestrzeni nazw dla tworzących ją stałych. Dlatego poniż-
sza deklaracja, zawierająca użytą już nazwą , pozostaje w konflikcie z deklaracją typu
:
Typy definiowane za pomocą konstrukcji są niepewne. Dodanie stałych do takiego
typu bez ponownej kompilacji klientów powoduje nieprzewidywalne działanie, nie-
zależnie od tego, jak dokładnie są sprawdzane istniejące wartości stałych. Poszcze-
gólne zespoły nie mogą niezależnie dodawać stałych do tych typów, ponieważ nowe
typy wyliczeniowe bardzo czą sto są ze sobą w konflikcie. Konstrukcja nie zapew-
nia żadnego mechanizmu, ułatwiającego zamianą stałych wyliczanych na ciągi znaków
lub przeglądanie stałych w typie.
Rozdział 4. f& Odpowiedniki konstrukcji języka C 95
Niestety, najczą ściej spotykany sposób emulowania typu wyliczeniowego w ją zyku Java
posiada wszystkie wady konstrukcji z ją zyka C:
Możesz sią również spotkać z odmianą tego wzorca, wykorzystującą stałe typu .
Wariant taki nigdy nie powinien być używany. Choć pozwala na bezpośrednie dru-
kowanie nazw stałych, może powodować obniżenie wydajności, ponieważ korzysta
z porównywania ciągów. Dodatkowo niedoświadczeni użytkownicy mogą wbudować
stałe w kod zamiast korzystania z odpowiednich nazw pól. Jeżeli taka stała posiada
błąd (literówką ), to błąd ten nie bą dzie wykryty w czasie kompilacji i bą dzie powodował
powstanie błą dów wykonania.
Na szczą ście ją zyk Java pozwala na utworzenie innej metody emulacji typu , która
nie posiada wszystkich wad użycia poprzedniej metody z wartościami lub ,
a ponadto ma kilka dodatkowych zalet. Jest ona nazywana bezpiecznym typem wyli-
czeniowym. Typ ten nie jest niestety zbyt dobrze znany. Pomysł jest prosty należy
zdefiniować klasą , reprezentującą pojedynczy element typu wyliczeniowego, nie defi-
niując publicznego konstruktora. Zamiast tego należy udostą pnić publiczne pola sta-
tyczne typu , po jednym dla każdej ze stałych typu wyliczeniowego. Wzorzec ten
w najprostszej postaci wygląda nastą pująco:
Ponieważ klienci nie mogą utworzyć obiektów tej klasy ani jej rozszerzać, nie mogą
istnieć inne obiekty tego typu poza udostą pnianymi przez pola statyczne. Choć klasa
nie jest zadeklarowana jako , nie można po niej dziedziczyć konstruktor klasy
pochodnej musi wywołać konstruktor klasy bazowej, a on jest niedostą pny.
Jak można sią domyślić na podstawie nazwy, ten wzorzec pozwala na sprawdzanie
typów w czasie kompilacji. Jeżeli zadeklarujesz metodą z parametrem typu , masz
pewność, że każda referencja różna od bą dzie prawidłowym obiektem, repre-
zentującym jedną ze stałych. Wszystkie próby przekazania obiektu o niewłaściwym
typie zostaną wykryte w czasie kompilacji, podobnie jak próby przypisania wyrażenia
96 Efektywne programowanie w języku Java
jednego typu wyliczeniowego do zmiennej innego typu. Można tworzyć wiele typów
wyliczeniowych z identycznie nazywającymi sią stałymi, ponieważ każda klasa posiada
swoją przestrzeń nazw.
Do takiej reprezentacji typu wyliczeniowego można dodawać kolejne stałe i nie powo-
duje to konieczności rekompilacji klientów, ponieważ publiczne statyczne pola, zawiera-
jące referencje do stałych, izolują klientów od klasy, realizującej typ wyliczeniowy. Same
stałe nie są wkompilowywane w kod klienta, tak jak czą sto zdarza sią to w przypadku
realizacji konstrukcji za pomocą rozwiązania, korzystającego z pól lub .
Ponieważ przedstawiona realizacja typu wyliczeniowego jest zwykłą klasą, może ona
przedefiniować metodą , co pozwoli na zmianą wartości zmiennych na postać
nadającą sią do wydrukowania. Jeżeli jest to potrzebne, można również zwracać komu-
nikaty w odpowiednim ją zyku. Zwróć uwagą , że ciągi znaków są wykorzystywane jedy-
nie przez metodą . Nie są używane do porównywania obiektów, ponieważ
odziedziczona po klasie metoda porównuje referencje do obiektów.
Można również dodać do klasy implementującej typ wyliczeniowy dowolne metody,
jakie mogą być potrzebne. W naszej klasie może przydać sią metoda zwracająca
kolor lub rysunek, skojarzony z odpowiednią stałą. Klasa była początkowo prostą reali-
zacją typu wyliczeniowego i z czasem zaczą ła sią zamieniać w bogatą w funkcją abs-
trakcją opisywanego obiektu.
Ponieważ do klasy implementującej typ wyliczeniowy można dodawać dowolne metody,
może ona implementować interfejsy. Na przykład załóżmy, że chcemy, aby nasza
klasa implementowała interfejs , co pozwoli klasom sortować karty
według koloru. Przedstawimy teraz modyfikacją oryginalnego wzorca, która imple-
mentuje ten interfejs. Zmienna statyczna używana jest do przypisywania
numeru kolejnego dla każdego z tworzonych obiektów. Numery te są używane przez
metodą do porządkowania obiektów.
Rozdział 4. f& Odpowiedniki konstrukcji języka C 97
Ponieważ stałe typu wyliczeniowego są obiektami, można umieszczać je w kolekcjach.
Załóżmy na przykład, że chcemy w klasie udostą pnić niezmienną listą kolorów
w standardowym porządku. Wystarczy dodać do klasy deklaracją dwóch klas pól.
W przeciwieństwie do najprostszej postaci typu wyliczeniowego klasy w wersji korzy-
stającej z numerów kolejnych mogą być serializowane (rozdział 9.) z zachowaniem
szczególnej ostrożności. Nie wystarczy dodać do deklaracji klasy klauzuli
. Wymagane jest również utworzenie metody (temat 57.).
Metoda ta, wywołana automatycznie przez system serializacji, zabezpiecza przed powie-
laniem istniejących stałych, powstałych w procesie deserializacji. Zapewnia ona, że bą dzie
istniał tylko jeden obiekt dla każdej stałej typu wyliczeniowego, co pozwala uniknąć
konieczności przedefiniowywania metody . Bez tej gwarancji metoda
bą dzie zwracała nieprawidłowe wyniki, jeżeli bą dzie porównywała dwie
równe stałe, ale o różnych kolejnych numerach. Zwróć uwagą , że metoda
korzysta z tablicy , wią c musisz zadeklarować tą tablicą , nawet
jeżeli nie chcesz udostą pniać kolekcji . Należy również zwrócić uwagą , że pole
nie jest wykorzystywane przez metodą , wią c jest ono nietrwałe i takie
powinno pozostać.
Wynikowa klasa jest jednak krucha konstruktor dla dowolnej nowej wartości musi
wystą pować po wszystkich istniejących wartościach, dzią ki czemu zapewniamy, że
wszystkie serializowane wcześniej obiekty nie zmienią swoich wartości w trakcie dese-
rializacji. Dzieje sią tak, ponieważ postać serializowana stałych (temat 55.) opiera sią
jedynie na ich kolejnych numerach. Jeżeli stała, bą dąca składnikiem typu wyliczenio-
wego, zmieni swój numer kolejny, stała o tym numerze poddana serializacji zmieni swoją
wartość podczas procesu deserializacji.
Może istnieć jedna lub wią cej operacji skojarzonych z każdą ze stałych, które są wyko-
rzystywane jedynie wewnątrz pakietu, zawierającego klasą realizującą typ wyliczeniowy.
Operacje takie najlepiej implementować jako metody prywatne w ramach pakietu. Każda
stała typu wyliczeniowego zawiera ukrytą kolekcją operacji, pozwalających reagować
odpowiednio dla odpowiednich stałych.
Jeżeli klasa implementująca typ wyliczeniowy posiada metody, których działanie znacznie
sią różni w zależności od wartości stałej, powinieneś skorzystać z osobnych klas pry-
watnych lub anonimowych klas, zagnieżdżonych dla każdej ze stałych. Pozwala to każdej
ze stałych posiadać własną implementacją danej metody i automatycznie wywoływać
odpowiednią implementacją . Alternatywą jest tworzenie wielościeżkowych rozgałą zień,
które wybierają odpowiednią metodą w zależności od stałej, na rzecz której wywołu-
jemy tą metodą . Jest to rozwiązanie niechlujne, podatne na błą dy i czą sto wydajność
tego rozwiązania jest niższa od rozwiązania, korzystającego z automatycznego wybie-
rania metod przez maszyną wirtualną.
98 Efektywne programowanie w języku Java
Obie techniki opisane w poprzednim akapicie są zilustrowane jeszcze jedną klasą, reali-
zującą typ wyliczeniowy. Klasa ta, , reprezentuje działania wykonywane przez
prosty kalkulator czterodziałaniowy. Poza pakietem, w którym zdefiniowana jest ta
klasa, można skorzystać ze stałych klasy do wywołania metod klasy
( , , itd.). Wewnątrz pakietu można dodatkowo wykonywać
operacje matematyczne związane ze stałymi. Przypuszczalnie pakiet może eksportować
obiekt kalkulatora udostą pniający jedną lub wią cej metod, które jako parametrów ocze-
kują stałych klasy . Zwróć uwagą , że sama klasa jest klasą abstrak-
cyjną, zawierającą jedną prywatną w ramach pakietu metodą abstrakcyjną ,
która wykonuje odpowiednią operacją matematyczną. Dla każdej stałej zdefiniowana
jest wewną trzna klasa anonimowa, wią c każda stała może zdefiniować własną wersją
metody .
Przedstawiony typ wyliczeniowy ma wydajność porównywalną do wydajności klasy
korzystającej ze stałych wyliczeniowych typu . Dwa różne obiekty klasy repre-
zentującej typ wyliczeniowy nigdy nie reprezentują tej samej wartości, wią c porówna-
nie referencji, które jest bardzo szybkie, wystarczy do sprawdzenia równości logicznej.
Klienci klasy mogą nawet użyć operatora zamiast metody wynik bą dzie
identyczny, a operator może nawet działać szybciej.
Jeżeli klasa typu wyliczeniowego jest przydatna, może być klasą najwyższego poziomu
jeżeli jest związana z inną klasą najwyższego poziomu, powinna być statyczną
klasą zagnieżdżoną tej klasy (temat 18.). Na przykład klasa
zawiera zbiór stałych wyliczeniowych typu , określających tryby zaokrąglania
Rozdział 4. f& Odpowiedniki konstrukcji języka C 99
czą ści dziesią tnych. Te tryby zaokrąglania stanowią użyteczny model abstrakcji, który
nie jest zasadniczo przywiązany do klasy byłoby lepiej utworzyć osobną
klasą . Udostą pnienie takiej klasy wszystkim programistom
korzystającym z trybów zaokrągleń pozwoliłoby na zwią kszenie spójności mią dzy
różnymi API.
Podstawowa implementacja wzorca bezpiecznego typu wyliczeniowego, zilustrowana
za pomocą dwóch implementacji klasy , jest zamknięta. Użytkownicy nie mogą
dodawać nowych elementów typu wyliczeniowego, ponieważ klasa nie udostą pnia im
konstruktora. Powoduje to, że klasa zachowuje sią tak, jakby została zdefiniowana jako
. Najczą ściej jest to najlepsze rozwiązanie, ale istnieją przypadki, w których
chcemy utworzyć rozszerzalną klasą typu wyliczeniowego. Może być to potrzebne na
przykład do reprezentowania formatów kodowania rysunków, gdy chcesz, aby inni pro-
gramiści mogli umożliwiać obsługą nowych formatów.
Aby umożliwić rozszerzanie typu wyliczeniowego, wystarczy udostą pnić zabezpie-
czony konstruktor. Użytkownicy bą dą mogli dzią ki temu dziedziczyć po istniejącej
klasie, dodając w podklasach własne stałe. Nie musisz sią obawiać, że stałe typu wyli-
czeniowego spowodują konflikt, tak jak było to w przypadku typu wyliczeniowego,
korzystającego ze stałych . Rozszerzalny wariant wzorca bezpiecznego typu wyli-
czeniowego korzysta z przestrzeni nazw pakietu do tworzenia magicznie admini-
strowanych przestrzeni nazw dla rozszerzalnych wyliczeń. Różne zespoły mogą nie-
zależnie rozszerzać wyliczenia i nie pozostaną one nigdy w konflikcie.
Dodanie elementu do rozszerzalnego typu wyliczeniowego nie gwarantuje jeszcze, że
nowe elementy bą dą w pełni obsługiwane. Metody operujące na elementach typu wyli-
czeniowego muszą przewidywać ewentualność przekazania elementu nieznanego pro-
gramiście. Wielokrotne rozgałą zienia są dyskusyjne w przypadku zamknią tego typu
wyliczeniowego, a w przypadku typu rozszerzalnego są nie do przyją cia, ponieważ
nie mogą samoczynnie dodawać nowej gałą zi dla typu, dodanego przez programistą
rozszerzającego klasą .
Jedynym sposobem radzenia sobie z tym problemem jest wyposażenie klasy bezpiecz-
nego typu wyliczeniowego we wszystkie metody niezbą dne do opisania zachowania
sią stałych tej klasy. Metody niezbyt użyteczne dla klientów powinny być zadeklaro-
wane jako w celu ich ukrycia, natomiast klasy pochodne mogą je przedefi-
niować. Jeżeli metoda taka nie ma rozsądnego działania domyślnego, oprócz
powinna być również zadeklarowana jako .
Dla rozszerzalnych klas bezpiecznego typu wyliczeniowego dobrze jest przedefinio-
wać metody i jako metody finalne, wywołujące odpowiednie metody
z klasy . Zapewni to, że żadna podklasa przypadkowo nie przedefiniuje tych metod,
co zagwarantuje, że wszystkie równe obiekty są również identyczne ( tylko
wtedy, gdy ):
100 Efektywne programowanie w języku Java
Trzeba pamią tać, że wariant rozszerzalny nie jest zgodny z wariantem implementują-
cym interfejs jeżeli bą dziesz próbował je ze sobą połączyć, porządko-
wanie elementów w podklasach bą dzie działało w porządku inicjalizacji podklas, co
może sią zmieniać w różnych programach i w różnych wywołaniach.
Rozszerzalny wariant wzorca bezpiecznego typu wyliczeniowego jest zgodny z warian-
tem implementującym interfejs , ale łączenie tych wariantów wymaga
nieco uwagi. Każda podklasa musi przypisywać własne numery kolejne i napisać wła-
sną metodą . Zasadniczo każda klasa jest odpowiedzialna za serializacją
i deserializacją swoich obiektów. Przedstawiamy teraz kolejną wersją klasy ,
która jest rozszerzalna i może być serializowana.
Rozdział 4. f& Odpowiedniki konstrukcji języka C 101
Przedstawimy również podklasą klasy , która dodaje operacje logarytmowa-
nia i podnoszenia do potą gi. Ta klasa pochodna może być zdefiniowana poza pakietem
zawierającym klasą bazową. Powinna być ona publiczna i umożliwiać dziedziczenie.
Możliwe jest utworzenie wielu niezależnych podklas, współistniejących bez żadnych
konfliktów.
Zwróć uwagą , że metoda w przedstawionej klasie nie jest prywatna, a tylko
prywatna w ramach pakietu. Jest to niezbą dne, ponieważ obiekty i
są właściwie obiektami podklas anonimowych, wią c prywatna metoda
nie może zostać zastosowana (temat 57.).
Wzorzec bezpiecznego typu wyliczeniowego posiada jednak nieco wią cej wad w porów-
naniu do typu wyliczeniowego, korzystającego z wartości . Prawdopodobnie jedyną
poważną niedogodnością jest niewygodne łączenie bezpiecznych stałych wyliczeniowych
w zbiory. W przypadku typu wyliczeniowego, korzystającego z wartości , jest to
zwykle realizowane przez nadanie stałym wyliczeniowym wartości bą dących potą gami
dwójki i reprezentowanie zbioru jako bitowej sumy logicznej odpowiednich stałych:
Reprezentowanie w ten sposób zbiorów stałych typu wyliczeniowego jest zwią złe i nie-
zmiernie szybkie. W przypadku zbiorów stałych bezpiecznego typu wyliczeniowego
możesz skorzystać z implementacji zbioru z biblioteki , ale nie jest to tak
zwią złe i szybkie.
102 Efektywne programowanie w języku Java
Choć zbiory stałych prawdopodobnie nie mogą być zrealizowane ani tak zwią zle, ani tak
szybko, jak zbiory stałych wyliczeniowych typu , możliwe jest zmniejszenie tej
różnicy przez utworzenie specjalnej implementacji klasy , która akceptuje jedynie
elementy jednego typu i wewną trznie reprezentuje zbiór jako wektor bitów. Taki zbiór
najlepiej zdefiniować w tym samym pakiecie, co klasa reprezentująca przechowywane
elementy, co umożliwia dostą p do pól lub metod prywatnych w ramach pakietu. Roz-
sądne jest utworzenie publicznych konstruktorów, które jako parametry akceptują krótkie
sekwencje elementów, dzią ki czemu możliwe jest tworzenie nastą pujących wyrażeń:
Mniejszą niedogodnością bezpiecznego typu wyliczeniowego, w porównaniu do typu
korzystającego z typu , jest to, że bezpieczny typ wyliczeniowy nie może być wyko-
rzystany w instrukcji , ponieważ nie są to wartości całkowite. Zamiast tego należy
skorzystać z instrukcji :
Instrukcja może nie wykonywać sią tak szybko jako , ale różnica nie powinna
być zauważalna. Tworzenie wielokrotnych rozgałą zień w przypadku bezpiecznego
typu wyliczeniowego powinno być rzadkie, ponieważ rozgałą zianie kodu należy zastą -
pować automatycznym wyborem metod przez maszyną wirtualną, tak jak w przyto-
czonej klasie .
Kolejny niewielki problem wiąże sią ze spadkiem wydajności, ponieważ potrzeba czasu
i miejsca w pamią ci na załadowanie klasy typu wyliczeniowego i utworzenie obiek-
tów stałych. Problem ten nie powinien być zauważalny w praktyce, poza niektórymi
urządzeniami o ograniczonych zasobach, jak na przykład telefony komórkowe czy tostery.
Podsumujmy. Przewagi bezpiecznego typu wyliczeniowego nad typem korzystającym
z wartości są bezapelacyjne i żadna z wad nie może być przyczyną zaprzestania
korzystania z niego, chyba że jest on głównie używany jako element zbioru lub w środo-
wisku o ograniczonych zasobach. Dlatego bezpieczny typ wyliczeniowy powinien
być jako pierwszy brany pod uwagę, jeśli konieczne jest zastosowania typu wylicze-
niowego. API korzystające z bezpiecznego typu wyliczeniowego jest dużo łatwiejsze
w użyciu dla programistów niż to, które korzysta z typu . Jedynym powodem, dla
którego bezpieczny typ wyliczeniowy nie jest intensywniej wykorzystywany w bibliote-
kach platformy Java, jest fakt, że wzorzec ten nie był jeszcze znany w czasie tworzenia
Rozdział 4. f& Odpowiedniki konstrukcji języka C 103
wią kszości klas tego API. Na koniec należy przypomnieć, że stosowanie typu wyli-
czeniowego powinna być dosyć rzadkie, ponieważ w wią kszości zastosowań tego typu
z powodzeniem można skorzystać z dziedziczenia (temat 20.).
Temat 22. Zastępowanie wskazników
do funkcji za pomocą klas i interfejsów
Ją zyk C pozwala na stosowanie wskazników do funkcji, które umożliwiają zapamią ty-
wanie i przesyłanie odwołań do określonych funkcji. Wskazniki do funkcji są najczą -
ściej wykorzystywane w celu umożliwienia funkcji wywołującej modyfikacji swojego
działania poprzez przekazanie wskaznika do drugiej funkcji, czasami nazywanej funkcją
wywołania zwrotnego. Na przykład, funkcja ze standardowej biblioteki ją zyka C
wymaga jako parametru wskaznika do funkcji, której zadaniem jest porównywanie ele-
mentów. Funkcja porównująca wymaga podania dwóch parametrów wskazników
do elementów. Zwraca ona ujemną liczbą całkowitą, jeżeli element wskazywany przez
pierwszy element jest mniejszy od drugiego, zero, gdy elementy są równe i dodatnią
liczbą całkowitą, jeżeli pierwszy element jest wią kszy od drugiego. Można uzyskać
różny porządek sortowania, przekazując inną funkcją porównującą. Jest to przykład
wzorca Strategy (strategia) [Gamma95, str. 315] funkcja porównująca określa strategią
sortowania elementów.
Wskazniki do funkcji nie znalazły sią w ją zyku Java, ponieważ korzystając z referencji
do obiektów, można uzyskać takie samo działanie. Wywołując metodą obiektu, zwykle
wykonuje sią operacje na tym obiekcie. Można również zdefiniować obiekt, którego
metody wykonują operacje na innym obiekcie, przekazanym jawnie do metody. Obiekt
klasy udostą pniającej tylko jedną taką metodą jest, efektywnie, wskaznikiem do tej
metody. Obiekty takie są zwane obiektami funkcjonalnymi. Przyjrzyjmy sią takiej
właśnie klasie:
Klasa ta udostą pnia jedną metodą , która oczekuje dwóch ciągów znaków jako parame-
trów. Zwraca ona liczbą ujemną w przypadku, gdy pierwszy ciąg jest krótszy od dru-
giego, zero, gdy ciągi są równe i liczbą dodatnią, gdy pierwszy ciąg jest dłuższy od
drugiego. Metoda ta jest komparatorem, porównującym długości ciągów. Referencja
do obiektu służy jako wskaznik do funkcji , umożliwiając
wywołanie metody dla dwóch podanych ciągów.
Bezstanowość klasy jest typowa dla klas strategii klasa ta
nie posiada pól, przez co wszystkie jej obiekty są funkcjonalnie identyczne. Aby
uniknąć tworzenia niepotrzebnych obiektów, możemy utworzyć tą klasą jako klasą
typu singleton (temat 4., temat 2.).
104 Efektywne programowanie w języku Java
Aby przekazać obiekt do metody, potrzebujemy odpowied-
niego typu dla parametrów. Skorzystanie z typu nie bą dzie
odpowiednie, ponieważ klienci nie bą dą mogli przekazywać innych strategii porów-
nywania. Można natomiast zdefiniować interfejs i zmienić klasą
, aby implementowała ten interfejs. Inaczej mówiąc, definiujemy
interfejs strategii, implementowany przez konkretne klasy strategii:
Ta definicja interfejsu znajduje sią w pakiecie , ale równie dobrze
możesz ją utworzyć samemu. W przypadku obiektów innych niż ciągi możliwe jest,
że ich metody bą dą oczekiwały parametrów typu , a nie . Dlatego
w celu prawidłowej implementacji interfejsu przytoczona wcześniej klasa
musi być nieco zmodyfikowana. W celu wywołania metody
parametry typu muszą być rzutowane na .
Klasy strategii są czą sto definiowane jako klasy anonimowe (temat 18.). Poniższe wyra-
żenie powoduje posortowanie tablicy ciągów według ich długości.
Ponieważ interfejsy strategii służą jako typy dla wszystkich obiektów strategii, w celu
udostą pnienia strategii jej klasa nie musi być publiczna. Zamiast tego klasa główna
może udostą pniać publiczne statyczne pole (lub statyczną metodą factory) typu określa-
nego przez interfejs strategii, a klasa strategii może być prywatną klasą składową klasy
głównej. W poniższym przykładzie pokazujemy zastosowanie statycznej klasy zagnież-
dżonej, tworzącej klasą strategii do implementacji drugiego interfejsu, .
Rozdział 4. f& Odpowiedniki konstrukcji języka C 105
Klasa korzysta z tego wzorca do udostą pnienia za pomocą pola
komparatora porównującego długości ciągów.
Podsumujmy. Podstawowym zastosowaniem wskazników do funkcji jest utworzenie
wzorca . W ją zyku Java wzorzec ten można utworzyć, deklarując interfejs
reprezentujący strategią i klasą implementującą interfejs dla konkretnej strategii. Gdy
strategia jest zastosowana tylko raz, jej klasa deklarowana jest najczą ściej jako klasa
anonimowa. Gdy strategia jest udostą pniana, jej klasa jest zwykle prywatną statyczną
klasą zagnieżdżoną i jest udostą pniana poprzez publiczne statyczne pole , którego
typ jest zgodny z interfejsem strategii.
Wyszukiwarka
Podobne podstrony:
Java Programowanie W Jezyku JavaProgramowanie w jezyku JavaProgramowanie współbieżne i rozproszone w języku Java stpiczynskitworzenie aplikacji w jezyku java na platforme android01 Wprowadzenie do programowania w jezyku CProgramowanie w jezyku C Szybki start procssLab Programowanie w jezyku powlokiOMÓWIENIE INTERFEJSÓW I KLAS ABSTRAKCYJNYCH W JĘZYKU JAVAA Poznański Programowanie w języku C dla chętnychOracle?tabaseg Programowanie w jezyku PL SQL or10psWprowadzenie do programowania w języku Cwięcej podobnych podstron