Dziedziczenie - wady/zalety

Witam wszystkich jako że jest to mój pierwszy post na forum. Potrzebuję infomracji jakie są zalety i wady dziedziczenia prostego i złożonego. Za wszystkie informację będę wdzięczny.

zdefiniuj: dziedziczenie proste/zlozone.

chodzi Ci o pojedyncze i wielokrotne?

Dokładnie o te. Spotkałem się z pojęciami proste = pojedyńcze i złożone = wielokrotne.

Dziedziczenie wielorakie nie istnieje w OOPie tak naprawdę.

Dobra, nie chodzi o fakt czy istnieje czy nie, ale czy ktoś potrafi zrobić listę by wpisać
+zalety
-wady
dziedziczenia jednokrotnego i wleokrotnego. Z jednokrotnym może nie ma tylu problemów, ale zalet dziedziczenia wielokrotnego nie bardzo mogę się dopatrzyć (oczywiście pomijam zalety, które są takie same jak przy dziedziczeniu jednokrotnym).

w skrocie:

za dziedziczenie wielokrotne poza tym sensu stricte w C++ mozesz uznac np:

• interface'y w Javie
• interface'y w C#
• mixin'y w Ruby
• ...

dziedziczenie to wiele roznych aspektow, ktore niekoniecznie musza byc w danym jezyku/platfomie realizowane, najwazniejsze:

• dziedziczenie interface'u (czegos co mowi jakie rzeczy beda obecne w klasie dla jej uzytkownikow)
• dziedziczenie implementacji (czegos co mowi jak one sa realizowane/wykonywane)

omawiajac jego zalety i wady, musisz rozbic to na dwie kategorie:

• wielokrotne dziedzicz. interface'u (interface w c++ to klasa bazowa pure virtual)

• pozwala klasyfikowac obiekty do roznych grup o wspolnych cechach, nie tylko do jednej, mozna zapytac sie obiektu 'czy spelniasz interface taki-a-taki'
• pozwala zdefiniowac jakie metody musza byc przez obiekt dostarczane, bez wzgledu na to jakiej jest on klasy, aby obiekt ten mogl sie chwalic ze nalezy do danej 'kategorii'
  ...

• wielokrotne dziedz. implementacji: pozwala do implemetnacji obiektu dolaczyc implementacje innego-obiektu. zakladajac, ze nie pogryza sie one (musza byc do tego zaprojektowane specjalnie! troche pracy i doswiadczenia wymagane):

• pozwala to na oszczedzenie sobie pracy (nie trzeba w klasie B pisac metod ktore juz raz napisalismy w klasie A i bylyby tez w sam raz dla B..)

• ratuje z duplikacji kodu (bo zamiast pisac te metody w B na podstawie A pewnie bysmy je przekleili) [dlaczego duplikacja jest mankamentem, patrz gdziesindziej..]

• ratuje przed rozrostem szablonu 'proxy' kodu (bo jesli nie chcemy duplikacji, to napiszemy kod tak, zeby obiekty B zawieraly prywatne podobiekty A ktore beda za nie wykonywac dana prace. metody ktore B by chcialo miec nie robia nic poza wywolaniem 'po kryjomu' odpowiednich, analogicznych metod z ukrytego robotnika A) ['proxy' nie jest mankamentem. czesc znawcow propaguje poglad ze uzywanie proxy jest lepsze niz wielokrotne dziedziczenie implementacji. to sie zgadza - struktura kodu jest bardziej przejrzysta, obiekt B uzywa obiektu A. super. ale gdy ilosc metod z'proxy'owanych siega kilkudziesieciu albo setek - to ja wspolczuje osobie ktora musi to napisac i pilnowac zeby sie nie walnac w czyms. JESLI SRODOWISKO IDE jest przystosowane do automatycznego genrowania kodu proxy, to zycie jest piekne i wielokrotne dziedz. implementacji traci sensbytu - patrz np. Delphi i jego forward implemntacji]

ludzie mowiacy o poprzez 'braku wielokrotnego dziedziczenia' w Javie, C# itp maja na mysli brak wielokrotnego dziedziczenia implementacji. daj boze, zeby wszyscy mieli tego swiadomosc.. (btw. dzieki temu, automatycznie, skazuja sie na tony kodu proxy'ujacego, i dlatego tez ich IDE bardzo czesto maja rozwiniete generatory od tego). nie oznacza to ze sa one automatycznie wolne od problemow dziedziczenia wielokrotnego --- maja multidziedziczenie interface'ow, np: Java ma problem z zasmieceniem przestrzeni nazw metod - 3 interface'y, w kazdym metoda getMyName, kazda spodziewajaca sie czegos innego, i okazuje sie ze ten obiekt nie jest w stanie podawac tym interfaceom roznych wartosci bo metody sa zwirtualizowane na chama.. np: C# ten sam przypadek, ten sam problem, ale rozwiazanie jest, bo nie ma wymuszonej wirtualnosci. da sie to osiagnac poprzez tzw. 'explicit interface implemnetation'.. ktory jak sie przyjrzec jest tak samo brzydki jak to co by trzebabylo w javie zrobic..

No dobrze, czyli wypisując na plus/minus wady i zalety różnego rodzaju dziedziczenia mam:

Dziedziczenie proste (jednokrotne):
+ponowne wykorzystanie raz napisanego kodu
+rozszerzenie i dostosowanie do własnych potrzeb klas niżej w hierarchii
+modularność (możliwość łatwego wprowadzenia nowych funkcji)
+możliwość stosowania funkcji wirtualnych

• wolniejsze wykonanie niż kodu strukturalnego
  -złożoność języka

Dziedziczenie złożone (wielokrotne):
+pozwala klasyfikować obiekty do różnych grup o wspólnych cechach
+pozwala do implementacji jednego obiektu dołączyć implementację drugiego

-możliwość powstania niejednoznaczności
-wysoki stopień komplikacji kodu

Thufir napisał(a)

• wolniejsze wykonanie niż kodu strukturalnego
  No ja bym polemizował. Sumą Sumarów wyjdzie szybciej.

Thufir napisał(a)

-złożoność języka
yyy :| co ?

Thufir napisał(a)

+możliwość stosowania funkcji wirtualnych
tu warto nazwać - polimorfizm. Można to trochę rozwinąć, np. na Wikipedii jest takie fajne zdanie

Wikipedia napisał(a)

Polimorfizm ... to możliwość wyabstrahowania wyrażeń od konkretnych typów

Do wad dziedziczenia wielokrotnego można dodać niemożność przetłumaczenia kodu na inne popularne języki.

Do zalet dziedziczenia można coś napisać o wzorcach projektowych, UML.

Ze złożonością języka chodziło mnie o to że robi się coraz bardziej zawile..., to gdzieś wyczytałem. Tak samo jak to o tym wolniejszym wykonaniu. Daję tutaj, żeby zweryfikować te twierdzenia.

Hmm zawiłe ? Powiedziałbym właśnie odwrotnie. Ułatwia usystematyzować kod, jego logikę.

Wolniejsze działanie?? Jeśli metoda nie jest wirtualna, to this jest przekazywany przez stos jakby to był zwykły argument. I cały "narzut" metod niewirtualnych przestaje istnieć. Przy wirtualnych są dodatkowo dwie dereferencje + korekcja o deltę (przy dziedziczeniu wielorakim). A jest to chyba najszybsze możliwe rozwiązanie.

-możliwość powstania niejednoznaczności

bzdura.. kompilator nie pozwoli na zadna niejednoznacznosc symboli czy odwolan. program z czyms takim sie nie skompiluje. ona jest takim samym bledem jak napisanie sobie dwoch zmiennych o tej samej nazwie w tym samym scope - ot, po prostu blad programisty.
to co moze wystapic, to co najwyzej niezrozumienie przez programiste tego co napisal, przez co program bedzie zachowywal sie inaczej niz on by sadzil:) trzeba po porstu pamietac, ze klasy bazowe nie sa rownorzedne i jedne z nich sa wazniejsze..

Do wad dziedziczenia wielokrotnego można dodać niemożność przetłumaczenia kodu na inne popularne języki.

na wiekszosc jezykow da sie przetlumaczyc dzieki interfejsom, forwardom metod i agregacji zamiast dziedziczenia (zamiast X :A, B to X : IA, IB)