{"id":30781,"date":"2020-09-30T12:58:04","date_gmt":"2020-09-30T10:58:04","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/od-kaczek-do-delegacji-czyli-problemy-z-dziedziczeniem-w-javie\/"},"modified":"2024-11-07T13:39:42","modified_gmt":"2024-11-07T12:39:42","slug":"od-kaczek-do-delegacji-czyli-problemy-z-dziedziczeniem-w-javie","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/od-kaczek-do-delegacji-czyli-problemy-z-dziedziczeniem-w-javie\/","title":{"rendered":"Od kaczek do delegacji, czyli problemy z dziedziczeniem w Javie"},"content":{"rendered":"\n
\n

Przejd\u017a do:<\/p>\n

    \n
  1. 1. Wst\u0119p<\/a><\/li>\n
  2. 2. Regu\u0142y pani Barbary Liskov<\/a><\/li>\n
  3. 3. Czysta abstrakcja<\/a><\/li>\n
  4. 4. Wada tego podej\u015bcia<\/a><\/li>\n
  5. 5. Kompozytor wyje\u017cd\u017ca w delegacj\u0119<\/a><\/li>\n
  6. 6. Wady kompozycji<\/a><\/li>\n
  7. 7. Kaczki, a kacze typowanie<\/a><\/li>\n
  8. 8. Lombok na ratunek<\/a><\/li>\n
  9. 9. Czas na podsumowanie<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n

    Wst\u0119p<\/h2>\n\n\n\n

    Programuj\u0105c w Javie (a w\u0142a\u015bciwie w ka\u017cdym j\u0119zyku zorientowanym obiektowo), co chwil\u0119 korzystamy z dobrodziejstw tego, co oferuje nam programowanie obiektowe: klasy, interfejsy, polimor\ufb01zm, dziedziczenie.<\/strong> I mo\u017cna by tak jeszcze d\u0142ugo wymienia\u0107. Szczeg\u00f3lnie ta ostatnia opcja (dziedziczenie) pozwala nam w \u0142atwy spos\u00f3b opisa\u0107 wiele podobnych do siebie byt\u00f3w w prosty spos\u00f3b \u2013 t\u0119 cz\u0119\u015b\u0107, kt\u00f3ra jest dla nich wsp\u00f3lna, deklarujemy tylko raz w klasie nadrz\u0119dnej; natomiast cz\u0119\u015b\u0107 zmienn\u0105 umieszczamy w kodzie klas podrz\u0119dnych po niej dziedzicz\u0105cych.<\/p>\n\n\n\n

    Okazuje si\u0119 jednak, i\u017c zar\u00f3wno w \u017cyciu codziennym (spadek z d\u0142ugami po dalekim krewnym, o kt\u00f3rym nawet nie mieli\u015bmy poj\u0119cia!), jak i w programowaniu, dziedziczenie mo\u017ce nam przysporzy\u0107 wielu niespodziewanych trudno\u015bci. Na czym polega problem?<\/strong> Aby to wyja\u015bni\u0107, pos\u0142u\u017cymy si\u0119 na pocz\u0105tek rysunkiem odnosz\u0105cym si\u0119 do zasady, o kt\u00f3rej b\u0119dziemy m\u00f3wi\u0107 w dalszej cz\u0119\u015bci artyku\u0142u. Nast\u0119pnie zmienimy rysunek w prost\u0105 aplikacj\u0119 z\u0142o\u017con\u0105 z kilku klas. Sp\u00f3jrzmy na dwa poni\u017csze rodzaje kaczek:<\/p>\n\n\n\n

    <\/div>\n\n\n
    \n
    \"
    Rysunek 1: Z\u0142e u\u017cycie dziedziczenia na przyk\u0142adzie kaczek<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n
    <\/div>\n\n\n\n

    A teraz spr\u00f3bujmy zapisa\u0107 powy\u017cszy obrazek za pomoc\u0105 klas Javy. Teoretycznie powinny nam do tego wystarczy\u0107 dwie klasy \u2013 jedna reprezentuj\u0105ca \u017cyw\u0105 kaczk\u0119, a druga kaczk\u0119 elektryczn\u0105. \u017bywa kaczka potrafi p\u0142ywa\u0107 i kwaka\u0107:<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \"
    Listing 1: Klasa Duck<\/em><\/figcaption><\/figure>\n\n\n\n
    <\/div>\n\n\n\n

    Natomiast kaczka elektryczna zachowuje si\u0119 tak jak \u017cywa (i dlatego po niej dziedziczy)… O ile oczywi\u015bcie kto\u015b pami\u0119ta\u0142 i w\u0142o\u017cy\u0142 do niej baterie! W przeciwnym razie reaguje niespodziewanymi wyj\u0105tkami.<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \"
    Listing 2: Klasa ElectricDuck<\/em><\/figcaption><\/figure>\n\n\n\n
    <\/div>\n\n\n\n

    Teraz (poniewa\u017c jeste\u015bmy w XXI wieku) zamiast tworzy\u0107 klas\u0119 z metod\u0105 main, napiszmy test, kt\u00f3ry sprawdzi poprawno\u015b\u0107 dzia\u0142ania klasy Duck:<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \"
    Listing 3: Klasa DuckTest<\/figcaption><\/figure>\n\n\n\n
    <\/div>\n\n\n\n

    Stworzony test celowo sparametryzowali\u015bmy tak, aby da\u0142o si\u0119 przekaza\u0107 do niego r\u00f3\u017cne obiekty klasy Duck. Skoro bowiem przyj\u0119li\u015bmy, i\u017c klasa Electric Duck dziedziczy po klasie Duck, to przekazanie do testu obiektu tej klasy nie powinno niczego zepsu\u0107. Tymczasem czeka nas bardzo nieprzyjemna niespodzianka:<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \"
    Listing 4: Wyniki test\u00f3w klasy Duck<\/em><\/figcaption><\/figure>\n\n\n\n
    <\/div>\n\n\n\n

    Wygl\u0105da na to, \u017ce obiekt klasy ElectricDuck zachowuje si\u0119 niestety inaczej ni\u017c obiekt klasy Duck. To bardzo niedobrze, gdy\u017c w innej cz\u0119\u015bci systemu mo\u017cemy mie\u0107 metody, kt\u00f3re przyjmuj\u0105 obiekt kaczki i je\u017celi przeka\u017cemy w takim miejscu kaczk\u0119 elektryczn\u0105 (a mo\u017cemy to zrobi\u0107, gdy\u017c kaczka elektryczna dziedziczy po \u017cywej), to system zachowa si\u0119 w spos\u00f3b nieprzewidziany! W takiej sytuacji pierwsze rozwi\u0105zanie, jakie przychodzi nam do g\u0142owy, to sprawdzenie, jaki typ kaczki otrzymali\u015bmy w rzeczywisto\u015bci:<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \"
    Listing 5: Naiwny spos\u00f3b kontroli typu kaczki<\/em><\/figcaption><\/figure>\n\n\n\n
    <\/div>\n\n\n\n

    Jednak\u017ce takie podej\u015bcie:<\/p>\n\n\n\n