Vícenásobná dědičnost – proč ji nezkusit impementovat v Nette, když není v PHP?

Abych pravdu řekl, to mi trochu uniklo, až teď jsem třeba objevil i článek Experiment NetteExtras\ExtensionObjects zde na fóru. Ale po letmém prostudování nejsem přesvědčen, že Traity to opravdu vše řeší. Mě jde o případ: Chci použít hotovou třídu. Třeba od jiného autora, nějak licencovanou, prostě na ní nebudu nic měnit. Zároveň potřebuji podědit funkcionalitu nějaké jiné třídy, která není s výše zmíněnou v nijakém rozporu, jde o zcela nesouvisející záležitost. Pokud nebyla alespoň jedna z těchto tříd předem navrhována jako Trait, mám smůlu. Nebo ne? Nemám teď moc času to studovat, oprav mě, pokud se mýlím. Zatím mám spíš pocit, že by musely takto být navrhovány obě. Ale je fakt, že v Tebou zmíněném článku je uvedena jedna drobnost – PHP nemá explicitní definici pro virtuální metody. K tomu ještě OOP je v php poměrně nová záležitost a mnoho PHP programátorů se s jeho principy dříve nesetkalo. Jsem asi jeden z mála, který na stará kolena „downgradoval“ na PHP odjinud. Takže uvolnit tak mocný nástroj, jakým je vícenásobná dědičnost, by mohlo vést k vytváření hrůzných mutantů. No, až mi trocha času zbyde a pokud to zvládnu, asi si tu dědičnost implementuju jen tak pro sebe, pak sem hodím kód. Napadá mne poměrně rychlé řešení, ovšem výkonově to bude zoufalé a implementačně dost čuňárna.

Editoval Martin (28. 4. 2011 10:14)

Nilp: Souhlas. Ale OOP se zabývám přes 20 let, psal jsem na to i disertaci. I proto jsem se k PHP dostal až teď, kdy začíná dohánět ostatní jazyky. Takže to neberu z hlediska PHP či Nette, ale OOP obecně. Samozřejmě je-li většinový názor, že vícenásobné dědění není to pravé, nebudu to nijak vnucovat.

Dědičnost je strašně nadužívaná, ve většině případů se pro řešení daleko lépe hodí kompozice.

Vícenásobná dědičnost je Kraken, kterého jsme nikdy neměly vypouštět na světlo světa. Její implementace stejně bude glorifikovaná kompozice + delegování.

Největší problém je, že při podědění od jedné třídy si zamezíš dědění od čehokoli jiného, takže je potřeba si to pořádně rozmyslet a zvážit.

Důležitý je také substituční princip Barbary Liskov, který říká, že potomek by měl umět vše, co předek + případně ještě něco navíc. Běžně stačí vnímat význam slova „extends“, tedy že rozšiřuji, nikoli omezuji funkčnost předka.

Dědit jen z toho důvodu, abych měl v $this pohodlně přístupnou hromadu metod, je špatně.

Vícenásobná dědičnost pak zavádí do aplikace další zmatky. Pro mě je dostatečným argumentem proti ní to, že ji Java neimplementuje, ergo nepotřebuje.

Neomezujícím a silnějším nástrojem proti opakování kódu je kompozice, kdy v jednom objektu využívám jiné objekty, injektované přes konstruktor nebo metody.

A pokud jde o extension methods: To je jen syntaktické pozlátko. Sice „rozšiřují“ daný objekt, ale nemají možnost měnit vnitřní stav jinak než přez rozhraní. (Viz C#).

Ovšem, až přijdou traity, to už tu většina z nás nebude :D

Vím, občas používám. Mimochodem je to zajímavě implementované. Jako obvykle je Nette 1 až několik verzí před PHP. I když zrovna toto na javě a podobných jazycích považuji spíše za nešťastnou úlitbu kvůli absenci některých jiných objektových principů (ovšem opravdu mé znalosti o teorii OOP spadají přibližně někam k roku 1988). Jen, pokud jsem si všiml, z extension methods nelze volat protected metody původního objektu, nebo se mýlím? Ale nechme to být, pokud budu klasické vícenásobné dědění někdy opravdu potřebovat, implementuji si to sám a komunita o něco takového zjevně nestojí, jsou tu důležitější věci k řešení.

Tohle mě docela dostalo. Je fakt, že i v Microsoftím C++ jsem v odůvodněném případě (redukce drobné chybičky MFC způsobující zbytečné narůstání alokované paměti aplikace) volal private metodu MFC pomocí hacku ukazatele (tak před osmi lety, ta chyba je dávno opravena, předpokládám, že dnes už by to ani hacknout nešlo). Ale hledat na to přímo funkci, to mě nenapadlo. No, mám se tady ještě hodně co učit.