Dědičnost – C / C++ – Fórum – Programujte.com

Ahoj mám jednu otázku, která mi vrtá hlavou.

Popíšu příklad: 

class A
{
protected:
   virtual void run() = 0;
}

class B : public A
{
   // other methods
}

class C
{
   void run{};
}

void function (B *b)
{
    b->run();
}

int main()
{
   C *c = new B;
   
   function(c);
	
   return 0;
}

jak je možné, že toto zafunguje?

#1 Bobek
Zkus si místo nesmyslů A, B, C vložit nějaká slova ze života. Například A = Zvíře, B = Pes, C = Auto.

Když jsem si to udělal pro sebe, tak mi z toho vylezlo 

Auto *auto = new Pes;

což je skutečně nesmysl a také na to čumím, jak je to možné.

test.cpp:5:1: error: expected ‘;’ after class definition
 }
 ^
test.cpp:10:1: error: expected ‘;’ after class definition
 }
 ^
test.cpp:14:13: error: variable or field ‘run’ declared void
    void run{};
             ^
test.cpp:15:1: error: expected ‘;’ after class definition
 }
 ^
test.cpp: In function ‘void function(B*)’:
test.cpp:4:17: error: ‘virtual void A::run()’ is protected
    virtual void run() = 0;
                 ^
test.cpp:19:12: error: within this context
     b->run();
            ^
test.cpp: In function ‘int main()’:
test.cpp:24:15: error: invalid new-expression of abstract class type ‘B’
    C *c = new B;
               ^
test.cpp:7:7: note:   because the following virtual functions are pure within ‘B’:
 class B : public A
       ^
test.cpp:4:17: note:    virtual void A::run()
    virtual void run() = 0;
                 ^
test.cpp:26:14: error: cannot convert ‘C*’ to ‘B*’ for argument ‘1’ to ‘void function(B*)’
    function(c);
              ^

No moc funkcni zdrojak to ani zdaleka neni

A kdyz se to trochu poupravuje, aby to aspon castecne davalo smysl:

test.cpp: In function ‘int main()’:
test.cpp:27:15: error: cannot convert ‘B*’ to ‘C*’ in initialization
    C *c = new B;
               ^
test.cpp:29:14: error: cannot convert ‘C*’ to ‘B*’ for argument ‘1’ to ‘void function(B*)’
    function(c);

#4 KIIV
Dopadl jsem úplně stejně. Nechápu, jak někomu ten první zápis mohl projít.

#5 Kit
mozna nejaky ultra stary kompilator.. Ale nejsme v indii, aby se to tu delalo treba na TurboC

#2 Kit
Tak zrovna s tím přiřazením Psa do Auta moc problém nevidím. Je to ukazatel na ukazatel. Jen to případně přetypovat, jinak se to kompilátoru moc nelíbí.

#include <iostream>

using namespace std;

class Animal {
public:
	void run() {
		cout << "Hello from Animal" << endl;
	}
};

class Car {
	void run() {
		cout << "Hello from Car" << endl;
	}
};

void function(Animal * x) {
	x->run();
}

int main() {
	Car * c = (Car *)new Animal;

	function((Animal *)c);

	return 0;
}

Co je spíše v úvodním kódu špatně, tak předpoklad, že se virtuální metoda run namapuje na tu ze třídy C. Virtuální metody se ukládají jinak než ty statické a tak při zavolání metody run ve funkci function dojde k nějakýmu nesmyslu.

Dnešní kompilátor tě pak dále ještě sprdne, že třída B je abstraktní (protože nepřepisuješ tu metodu run) a nemůžeš tak ani vytvořit instanci třídy...

#7 PiranhaGreg
Vždycky je nejlepší pojmenovat třídy podle aktuálně řešeného problému, který ovšem v tomto případě neznáme. Už jsem alergický na všechny ty Foo a Bar, které o řešeném problému neříkají vůbec nic a ani se na nich nedá nic vysvětlit. OOP totiž vůbec není o syntaxi, ale o sémantice. Názvy tříd a objektů jsou mnohem důležitější než klíčová slova, která slouží jen jako lepidlo.

Přetypování je jen berličkou pro ty, kteří řešení problému nezvládli. Podobným nesmyslem je například operátor instanceof, který bývá tam, kde programátor nepochopil polymorfismus.

#8 Kit
Nemůžu než souhlasit  

#7 PiranhaGreg
prirazeni psa do auta neni problem, problem je v tom, ze rikas "tento pes je auto..."

#8 Kit
Pokud se rozebírá určité chování jazyka, je úplně jedno jak se třídy, proměnné a metody nazývají. Nebudu vymýšlet komplexní problém, když pro jednoduchou demonstraci bohatě stačí názvy typu Foo a Bar.

Pokud se chceš zabývat správností návrhu, pak jsou vhodné reálné názvy, v případě, kdy řešíš jazyk samotný ti může být úplně ukradené, jak se co jmenuje, a na čitelnost kódu to nemá absolutně žádný vliv.

#10 KIIV
Vím, vím... Však ono kdykoliv se v C++ objeví nějakej cast, měl by se člověk zamyslet, jestli není něco špatně (někdy není).

#11 ondrej39
"lidsky" srozumitelnější jsou příklady zvíře - pes, auto - náklaďák než A, B nebo Foo. Použití příliš abstraktních pojmů pak často vede k nepochopení byť jednoduchých věcí. Pak je snadné smíchat jabka s hruškama a chtít je koupit v autoservisu, protože si pod abstraktním označením nikdo nedovede představit, že se jedná o objekty představující neslučitelné věci.

hu

#11 ondrej39
KIIV napsal větu "tento pes je auto...", která je evidenním nesmyslem. Pokud by použil původní názvy, napsal by "Instancí třídy B je objekt třídy C", jehož nesmyslnost dokážeme teprve když se rozhlédneme po okolních řádcích, definici tříd nebo komentářích.

Účelem vhodně volených názvů je omezení zkoumání okolí zápisu na minimum tak, aby i samotný zápis byl srozumitelný na první pohled.

Použití názvů tříd A, B, C, Foo nebo Bar považuji za obfuskaci.

#13 hlucheucho
Ono je ovšem úplně jedno, co je nebo není neslučitelné, dokud opravdu neřešíš nějaký reálný problém, což OP neřeší. Zajímá ho funčknost jazyka samotného a jak je možné, že by kód jemu podobný vůbec prošel kompilací (v jeho případě by bohužel neprošel, na tom nezáleží).

#1 Bobek
Možné to není, tvůj kód jednoduše fungovat nebude.

#15 ondrej39
Na to, abych ten problém mohl pochopit, musel jsem provést zmíněnou deobfuskaci. Nemám takovou představivost, abych pochopil, že v daném kódu "B je potomkem A", protože obecně platí, že "B není potomkem A".

#1 Bobek
Dodatek:

Kromě toho, pokud třída B uvede nové metody, které třída A nemá, pak porušuješ princip substituce Barbary Liskovové, který říká:

A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property [6]: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T. (See also [2], [17] for other work in this area.)
 

Z čehož je logické, přidávání metod do zděděných tříd absolutně nemá smysl, protože nikdy nebudou v aplikaci dostupné. Pokud nutně něco takového potřebuješ, měl by ses vydat raději cestou kompozice před dědičností a udělat si dekorátor na třídu A, který bude třídu A přebírat jako závislost.

#17 ondrej39
Trochu to zkonkretizuji (deobfuskuji): Pokud do třídy Pes přidám metodu štěkej(), bude to porušením LSP. Po regulérním přiřazení:

Zvíře *zvíře = new Pes();

není možné regulérně zavolat metodu zvíře->štěkej(), protože zvířata obecně štěkat neumí.

~~ přidávání metod do zděděných tříd absolutně nemá smysl

K čemu by mi byl potomek, který neumí nic navíc oproti předkovi? V takovém případě by (alespoň pro mne) dědičnost ztratila smysl.

hu

#19 hlucheucho
Nekdy se to vyuzit da. Treba trida zvire muze mit ciste virtualni metodu vydavaZvuk(), kterou pak v jednotlivych specializacich implementujes ruzne.

#19 hlucheucho
Viz mé vysvětlení. Nedá se v tom případě využít polymorfismu a aplikace je pak plná operátorů instanceof. Dědičnost je často nadužívána a Barbara Liskov dala pravidla pro situace, kdy je použití dědičnosti rozumné a kdy už ne.

U mého zvířete štěkání řeším následovně: 

Zvíře *zvíře = new Pes();zvíře->notify("Přišel cizinec");

Pes má v metodě notify() zapsáno, že má na cizince štěkat, Husa kejhat a Kočka zdrhnout.

Když pak dáš všechna zvířata do kolekce Dvorek, můžeš jim observerem rozeslat oznámení, co se stalo. Každé zvíře pak ví, co má dělat.

Detailista (lidově rejpal): vydavaZvuk() je možné jen u některých zvířat. Představ si třeba kapra.

hu

#22 hlucheucho
To je jednoduché: U kapra naimplementuješ ticho nebo šplouchnutí, ale ta metoda vydavaZvuk() tam být musí - třeba prázdná.

Rejpal^2: i ticho je zvuk :D

#24 KIIV

Taky máš tinitus?

hu

#25 hlucheucho
U strategií je obvyklé, že když klikneš na nějakou jednotku, tak se ti nějakým způsobem zahlásí. Bojový kapr by v takovém případě asi plácnul ploutví či ocasem, což jsou regulérní zvuky.

#19 hlucheucho
To nevadí, dědičnost (v případě, kdy rodičovská třída obsahuje i něco jiného než samé pure virtual metody a není tedy pouhým placeholderem pro interface) obecně je zbytečně přeceňovaná a špatně používaná.

#17 ondrej39

Z čehož je logické, přidávání metod do zděděných tříd absolutně nemá smysl, protože nikdy nebudou v aplikaci dostupné.

Takže tím že je v C# všechno potomek třídy Object je vlastně celej C# špatně?  

#28 PiranhaGreg
Myslel jsem si, že s tím někdo přijde, protože i mně to proběhlo hlavou.

Jde o to, že při správném používání dědičnosti současně využíváš polymorfismus: 

Rodič objekt = new Potomek(...);

Jako rodičovská třída má být taková, která je co nejblíž třídě Object, ale aby splňovala požadované rozhraní. Už mnohokrát jsem na levé straně použil třídu Object, protože jsem nic speciálnějšího nepotřeboval - stačilo mi překrýt některé standardní metody třídy Object a bylo to.

Stejně dobře může být na levé straně místo třídy nějaké rozhraní. Můžeš pak využívat nejen standardní metody třídy Object, ale i metody definované v tom rozhraní.

Proč to všechno? Abys mohl s takovými objekty pracovat jednotně. Je jedno, které třídy je potomkem, každý objekt má například metodu ToString(), která ti velmi dobře poslouží při prezentaci objektu. Klidně můžeš napsat příkaz 

Console.WriteLine(objekt);

a víš, že se ti nějakým způsobem vypíše. Pokud se ti výpis nelíbí, stačí jen napsat metodu ToString() do třídy, podle které byl vytvořen ten objekt tak, aby se ti výpis líbil.

Je toho na celý článek, co všechno se s tím dá dělat.

#29 Kit
No to jsi ale moc nereagoval na výrok

Z čehož je logické, přidávání metod do zděděných tříd absolutně nemá smysl, protože nikdy nebudou v aplikaci dostupné.

kterej mi prostě přijde nesmyslnej. Jinak principy OOP a k čemu je to dobrý znám moc dobře. Nedávno jsem dělal na projektu ve SmallTalku, tak bych mohl vyprávět  .

#30 PiranhaGreg
Tak už to tolik nerozebírej a zkus to nějak rozdýchat. Nemusíme přece slovíčkařit.

#28 PiranhaGreg
Pokud by cílem .NET frameworku bylo naprogramovat dle LSP, pak ano. Nicméně je vždy třeba myslet na to, že LSP a SOLID principy, do nichž LSP také spadá, které je stejně jako všechno možné brát jako pomůcku návrhu softwaru, ale nemusíš se jimi zcela striktně řídit. Jsou různé ideologie jak software tvořit.

Tak jako tak, LSP by se měl vztahovat převážně na objekty modelované tebou samým, nepředpokládám, že budeš vyvíjet samostatný .NET framework. Pokud se zabýváš vlastním vývojem a chceš ho dělat dle SOLID principů, pak je třeba brát v ohled i LSP.