[ Pobierz całość w formacie PDF ]
pomoc słowa kluczowego GZVGPFU, czyli rozszerzać) sugerować konieczno ć dodania
nowych metod do interfejsu, nie jest to do ko ca prawd . Drugim i do tego wa niej-
szym sposobem, dzi ki któremu mo emy uczynić klas pochodn ró n od bazowej,
jest zmiana zachowania istniej cej ju metody bazowej, okre lana jako jej przesłoni cie
(ang. overriding).
W celu przedefiniowania metody po prostu tworzymy w klasie pochodnej jej now defi-
nicj . Mówimy: Chc tu wykorzystać t sam metod z interfejsu, ale dla nowego typu ma
ona robić co innego .
7KLQNLQJ LQ -DYD (G\FMD SROVND
e%\FLH F]\P s D eE\FLH SRGREQ\P GR F]HJR s
W kwestii dziedziczenia mo e powstać pewna w tpliwo ć: czy nie nale ałoby ograni-
czyć si jedynie do przedefiniowywania metody klasy bazowej (powstrzymuj c si od
dodawania nowych)? Oznaczałoby to, e klasa pochodna jest dokładnie tego samego
typu co bazowa, poniewa ma taki sam interfejs. W rezultacie obiekt klasy potomnej
jest dokładnym substytutem obiektu klasy bazowej mo emy mówić o czystej zast po-
walno ci, a całe to stanowisko jest okre lane mianem zasady zast powalno ci (ang. substi-
tution principle). Jest to w pewnym sensie idealny sposób traktowania dziedziczenia. Zwi -
zek pomi dzy klas bazow a pochodn okre lamy w tym przypadku cz sto jako relacj
bycia czym (ang. is-a relationship), poniewa mo emy powiedzieć okr g jest figur .
Sprawdzian poprawno ci u ycia dziedziczenia polega na zbudowaniu podobnego zdania
dla naszych klas i stwierdzeniu, czy ma ono sens.
W niektórych sytuacjach dodanie w typie pochodnym nowych elementów interfejsu jest
jednak konieczne takie jego rozszerzenie tworzy nowy typ. Mo e on być nadal u ywany
zamiast typu bazowego, jednak e zast powalno ć nie jest ju idealna, poniewa nowe
funkcje nie s dost pne z poziomu bazowego. Ten rodzaj relacji mo emy okre lić jako bycie
podobnym do czego ; nowy typ posiada cały interfejs starego typu, jednak e zawiera tak e
inne metody, przez co nie mo na powiedzieć, e jest taki sam. Rozwa my na przykład
klimatyzacj . Przypu ćmy, e mamy zainstalowany w domu system chłodz cy, a zatem
interfejs pozwalaj cy na kontrol chłodzenia. Wyobra my sobie, e klimatyzacja psuje si
i zast pujemy stary system now pomp ciepln , która pozwala zarówno chłodzić, jak
i ogrzewać. Zasada działania pompy cieplnej jest podobna do działania klimatyzacji, ale
pompa mo e zrobić wi cej od niej. Poniewa system chłodz cy jest zaprojektowany do
kontroli chłodzenia, jest ograniczony do komunikowania si z chłodz c cz ci nowego
obiektu. Interfejs tego obiektu został poszerzony, ale istniej cy system nie zna niczego poza
interfejsem oryginalnym.
Oczywi cie po przestudiowaniu tego projektu staje si jasne, e klasa bazowa 5[UVGO
%J QF\E[ nie jest dostatecznie ogólna i powinna zostać zmieniona na system kontroli
temperatury , aby mogła obsługiwać równie ogrzewanie po czym zasada zast po-
walno ci zacz łaby znowu działać. Diagram ten przedstawia jednak sytuacj , jaka mo e
si zdarzyć w projektowaniu i w wiecie rzeczywistym.
Po zapoznaniu si z zasad zast powalno ci mo na pomy leć, e to rozwi zanie (czysta
zast powalno ć) jest jedynym słusznym, i faktycznie dobrze jest, gdy projekt działa w ten
sposób. Z czasem jednak mog wyst pić sytuacje, w których konieczno ć dodania nowych
funkcji w interfejsie klasy pochodnej jest równie jasna. Po dokładnym zbadaniu rozró nienie
mi dzy tymi przypadkami powinno być oczywiste.
5R]G]LD u :SURZDG]HQLH Z ZLDW RELHNWZ
:\PLHQLDOQR RELHNWZ
] X \FLHP SROLPRUIL]PX
Przy pracy z hierarchiami typów chcemy cz sto traktować dany obiekt nie jako repre-
zentanta typu specjalizowanego, lecz raczej bazowego. Pozwala to na pisanie kodu nie-
zale nego od konkretnego typu. W przykładzie z figurami funkcje manipuluj nimi, nie
zwracaj c uwagi na to, czy maj do czynienia z okr gami, kwadratami, trójk tami czy te
takimi figurami, które nie zostały jeszcze nawet zdefiniowane. Wszystkie one mog być
narysowane, wymazane lub przesuni te, zatem funkcje te przesyłaj po prostu komunikaty
do obiektu typu figura, nie przejmuj si sposobem, w jaki obiekt reaguje na te komunikaty.
Na kod taki nie ma wpływu dodawanie nowych typów, a dodawanie takie jest najpow-
szechniejszym sposobem rozszerzania programu obiektowego w celu obsłu enia nowych
[ Pobierz całość w formacie PDF ]