Zrozumieć dziedziczenie

Question

Cześć. Uczę się programowania obiektowego i natrafiłem na temat dziedziczenia, jednak nie mogę go za bardzo pojąć Próbowałem przełożyć to na swój kod: klasa Soul jako klasa bazowa, klasy Player i Enemy jako klasy pochodne. No i z tego co zrozumiałem to klasy pochodne odziedziczą zmienne i metody z klasy bazowej, ale będą miały te same wartości w tych odziedziczonych zmiennych i tu właśnie się zastanawiam jaki jest sens dziedziczenia w takim razie.. Teoretycznie chodzi o to, żeby nie pisać dwa razy tego samego kodu, ale nie potrafię tego zrozumieć.

 

Przykładowo: wspólną cechą, którą posiadają klasy Player i Enemy może być zmienna

float healthPoints;

która byłaby zadeklarowana w klasie bazowej Soul. Oddzielne punkty życia powinien mieć gracz i przeciwnicy, ale jeśli skorzystam tutaj z dziedziczenia to obie klasy będą miały wspólne życie. Nie wiem czy dobrze to rozumiem, ale mam szczerą nadzieję, że nie i ktoś mądry będzie w stanie przystępnie mi to wytłumaczyć

Answer 1

Nie, dziedziczone niestatyczne składowe nie są wspólne dla wszystkich instancji klas pochodnych, każdy obiekt posiada swoje własne kopie tych pól. Dziedziczenie to po prostu wyabstrahowanie wspólnego kodu różnych klas poza nimi w innej klasie, aby go zbędnie nie powtarzać. Mógłbyś równie dobrze dopisać do każdej klasy tę zmienną zdrowia i rezultat byłby podobny, czyli każdy obiekt miałby własne zdrowie.

Oczywiście dziedziczenie i ogólnie obiektowość to rozbudowane tematy, więc odsyłam do zewnętrznych źródeł, które na pewno wyczerpująco przedstawią ci wszystkie tajniki tych pojęć.

Answer 2

Masz klase "Rodzic"
Masz klase "Dziecko"

Dziecko dziedziczy po rodzicu
Rodzic może chodzić, więc dziecko też - pod warunkiem, że metoda chodzenie() jest u rodzica publiczna lub chroniona

Przykład z życia
Komunikacja klient-serwer (testy end to end)
(ja tak to zbudowałem u siebie)
ServerConnection - połączenie z serwerem, posiada instancje klasy do łączenia się z ustalonym z góry serwerem
Po niej dziedziczą klasy z metodami, powszechnie używanymi - typu "stwórz użytkownika o tych danych", "dodaj post o tych danych"
Po nich dziedziczą klasy z metodami - testami, które wykorzystują metod powszechnie używanych, jak i komunikacji z serwerem

Równie dobrze mógłbym w każdej z klas testów tworzyć osobną instancję klasy z konfiguracją, z której bym korzystał i którą bym przekazywał do klas z metodami pomocniczymi - których instancje też musiałbym tworzyć
Poco, skoro mogę zrobić sobie "drzewko", gdzie raz tworze komunikacje z serwerem i podpinam się pod nią różnymi gałęziami (dziedziczenie po tej klasie).
A po klasach dziedziczących - klasach które posiadają powtarzalne metody, dziedziczą metody z testami, które używają tych metod.

Zauważ że zarówno klasy z metodami jak i klasy testów, wymagają połączenia z serwerem, tworząc osobne instancje musiałbym robić mase obiektów a tak to mam tylko rodzic - dziecko - dziecko dziecka (wzorzec singleton tak w ogóle)

Albo inny przykład - MVC
Gdzie system musi wiedzieć że kontroler jest kontrolerem - więc każdy z kontrolerów dziedziczy po klasie kontroler

+zalecam dziedziczenie jednostopniowe, ewentualnie (w specyficznych przypadkach jak mój) dwustopniowe
chodzi o to, żeby się nie pogubić
masz klase D która dziedziczy po klasach C B i A
masz do wykorzystania masę metod które odziedziczyłeś (wgl wpadł mi też inny pomysł na wytłumaczenie dziedziczenia - możesz użyć metody którą posiada rodzic) i... łatwo się w tym wszystkim pogubić
Jak dziedziczysz po jednej klasie jest estetycznie i przejrzyście, dwie klasy to już max

Comments

jak czegoś nie rozumiesz to pisz

Answer 3

Nie do końca po to aby nie pisać 2 raz tego samego kodu w polach klasy. Robi się to także aby łatwiej korzystać z klas i nie musieć sprawdzać dodatkowych warunków. Np. załóżmy że masz różnych wrogów w grze jest to powiedzmy 10 klas. Masz także jakąś pętlę główną która co 20ms dla każdego wroga wykonuje metodę RuszSie. Wyobraź sobie jak by to wyglądało bez dziedziczenia i metod abstrakcyjnych. Musiałbyś sprawdzić w 10 możliwości jakiego typu jest dany wróg, przekonwertować go na odpowiedni typ i wywołać tą metodę. Miałby pewnie jeszcze jakieś inne metody które byś wywoływał w innych miejscach i tak samo musiałbyś wszystko sprawdzać. Teraz np. postanawiasz dodać jeszcze jednego wroga - co się dzieje? Musisz w wszystkich miejscach dopisać sprawdzenie kolejnego warunku, łatwo narazić się także na błąd pomijając jakieś miejsce. Dzięki dziedziczeniu i metodom abstrakcyjnym takiego problemu się nie ma i pisze się dużo szybciej i przejrzyściej. Mam nadzieję że zrozumiałeś. Ale i tak tylko dzięki praktyce można to w pełni zrozumieć.