Objektově orientované programování

Při vytváření objektů pro chod programu, které budou odpovídat zmíněným dvěma reálným objektům, je třeba vytvořit dvě různé instance třídy Člověk, pro každý modelovaný reálný objekt jednu instanci (tedy jedna instance já a jedna sousedka). Hodnoty atributů jméno a příjmení se pochopitelně v našem případě budou lišit, nicméně obě instance jsou schopny chodit a mluvit díky tomu, že jsme tyto schopnosti obecně přiřadili třídě Člověk.

Představme si dále, že můj soused je svářeč. Stejně jako moje sousedka má jméno, příjmení a umí chodit, mluvit, navíc ovšem umí svářet. Při modelování můžeme využít toho, že svářeč má všechny vlastnosti třídy Člověk a něco navíc. Vytvořme třídu Svářeč jako potomka třídy Člověk. Třída svářeč tímto dědí všechny atributy i metody třídy Člověk (nemusíme je v kódu znovu psát a budeme je upravovat na jediném místě), navíc bude mít metodu svařit.

Metoda svařit může mít například dva parametry (argumenty), prvníKusKovu a druhýKusKovu, a návratovou hodnotu jedenKusKovu. Vím, že když dám sousedovi svářeči dva kusy kovu a požádám o jejich svaření, dostanu je zpátky jako jeden kus kovu a nemusím se starat o to, jak to dokázal. Stejně to bude fungovat v programu. Objekty si mezi sebou mohou posílat zprávy, v našem případě zpráva znamená, že jeden objekt spustí metodu svařit jiného objektu a využije vrácenou hodnotu (odpověď na zprávu). Tomuto způsobu komunikace mezi objekty, která skrývá konkrétní implementaci a stará se jen o zprávy, se v objektově orientovaném programování říká zapouzdření.

Představme si nyní, že potřebujeme vytvořit komplexnější model světa, ve kterém se já od své sousedky začnu lišit. Já umím programovat a ona umí účtovat. Protože nám zůstaly různé společné vlastnosti, ponechme původní třídu Člověk a vytvořme dvě třídy Programátor a Účetní, obě odděděné od třídy Člověk. Nyní však v modelu světa nebude existovat žádná instance třídy Člověk, budou existovat jen instance potomků třídy Člověk, tedy tříd od Člověka odděděných. Pokud skutečně chceme, aby v našem modelu existovali pouze svářeči, programátoři a účetní, ale žádní obecní lidé, kteří by nespadali ani do jedné z těchto skupin, lze označit třídu Člověk jako abstraktní třídu, tedy takovou, od níž nelze tvořit žádné instance.

Děděním lze nejen rozšiřovat repertoár metod o další, ale i „měnit“ dosavadní zděděné: Například třída Starý_člověk může překrýt (angl. overriding) původní metodu chodit() poděděnou od Člověka svou vlastní implementací a chodit() bude s použitím hole: Sám už tedy jinak než o holi nechodí. Přitom si stále, např. pomocí syntaktické konstrukce zvané tečková konvence, na původní metodu Člověk.chodit() může vzpomenout, má přístup k metodám svých předků.

Jiný způsob, jak upravit nebo rozšířit možnosti (nejen zděděné) je přetěžování metody (angl. method overloading): Například Akrobat je Člověk, který umí nejen normálně chodit() po nohou, ale navíc si doplnil také schopnost volanou chodit(po_rukou). Je na volbě Akrobata, jaký vstup pro svou metodu použije, a podle toho se pak zavolá právě ta jediná odpovídající ze všech přítomných implementací této metody. Rozdíl zde může být buď v počtu předaných parametrů volané metodě, a pak je rozdíl, jestli se vozíme autem jezdit(Vozidlo auto), nebo jestli jedeme autobusem po lince 183 jezdit(Vozidlo autobus, Linka číslo): jde o dvě různé přetížené metody. Anebo zda pro řízení škodovky voláme metodu řídit(škoda) sice se stejným počtem vstupů, ale předáváme různé typy pro metody: řídit(Automobil název) a řídit(Firma název), to jsou dvě různé přetížené metody, obě Člověkovi dostupná zároveň.

Naopak, obě volání jezdit(auto) a jezdit(motorka) použijí stejnou metodu jezdit(Vozidlo vozidlo), nejde o přetížení metody, protože se v obou případech jedná o stejný počet vstupů a i stejný typ vstupu Vozidlo. Ne že by takové ježdění nebyl rozdíl, ale ten už se při takto postavené třídě musí řešit uvnitř metody, rozvětvením běhu programu.

Prvním stupněm řešení je například do objektu zavést dědění: Prohlásit Vozidlo za abstraktní třídu, její metodu jezdit() také za abstraktní, a do odděděných metod jezdit() potomků Automobil a Motocykl přenést jen příslušné větve kódu: Jednou z výhod dědění je právě eliminace složitých podmínek pro větvení.

Jiná možnost je opravdu přetížení metody, kdy se původní obecná metoda jezdit(Vozidlo vozidlo) Člověku ponechá, navíc ale lze dopisovat specifičtější metody jezdit(Autem auto) a jezdit(Na_motorce motorka). Jestli jsou všechny tyto tři metody přítomny už přímo ve třídě Člověk, nebo přibudou další až v odděděné třídě je jedno: řidič je vidí všechny, z jeho pohledu je metoda přetížená, tedy si může vybírat.

Někdy se rodičovská metoda, třeba chodit(), nejen přetěžuje, ale navíc ještě zcela úmyslně překrývá: Třeba zmiňovaný Akrobat se naučil chodit po laně, proto je pro něj žádoucí při volání metody chodit() nejdříve zkusit svou novou schopnost, a až pak použít obecnější chodit() od předka. Nejdříve se ověří, zda Akrobat je_na_laně, podle této podmínky se buď interně zavolá chodit(po_laně), nebo se výslovně zavolá ona zděděná ale právě zakrývaná metoda parent.chodit() od předka.

Akrobat nemusí být odděděn od Člověka ale třeba od Atléta a ten teprve od Člověka. Potom když Akrobat volá metodu předka parent.chodit() nemusí to znamenat chodit po zemi jako u Člověka, ale třeba chodit po kladině: Metody předků se volají po jednom zpětně ve sledu dědění, například Akrobat.chodit() po laně, ak neplatí že je_na_laně zavolá Atlét.chodit() po žíněnce. Ak je_na_žíněnce na volání samotné Člověk.chodit() po zemi se nedostane, protože byla splněna jedna z podmínek v překrytých metodách ve sledu dědění.

Obecně se při překrývání může ověřovat nějaká zadaná podmínka, zde prostředí, nebo před zavoláním metody předka zařídit inicializaci, vrácení prostředků systému apod. Podobná konstrukce je podstatná pro destruktor, někdy se používá i s konstruktory.

Zjistíme, že programátor umí psát na počítači a účetní také. Intuitivně cítíme, že nebudou mít mnoho dalších společných schopností a navíc tuto dovednost může mít napříč povoláními leckdo, proto nemá smysl tvořit třídu na způsob ČlovekPracujícíSPočítačem a od ní dědit Programátora a Účetní, ale je výhodnější například vytvořit rozhraní SchopenPsátNaPočítači s požadavkem na metodu napišNaPočítači() a upravit třídy Programátor a Účetní tak, aby toto rozhraní implementovaly, tedy předepsanou metodu, a to každý po svém. V definici rozhraní nemůže být obsažen kód (implementace) dané metody, ale všechny třídy, které toto rozhraní implementují, musí být schopny se s příkazem napišNaPočítači() nějak vypořádat.

Obdobně i již zmiňovaná abstraktní třída může předepisovat doimplementování metod, pro které ona sama nemá vlastní kód, ale jen předpis abstraktní metody.

Další důležitou vlastností objektů je polymorfismus. Stejná zpráva může být poslána od různých nebo různým objektům. Lze rozlišit, zda jde o polymorfismus

• nad dvěma různými objekty stejné třídy,
• nad dvěma různými stavy téhož objektu,
• anebo zda zprávu posílají různé objekty různých tříd.

Zapouzdření v objektech znamená, že k obsahu objektu se nedostane nikdo jiný, než sám vlastník. Navenek se objekt projeví jen svým rozhraním (operacemi, metodami) a komunikačním protokolem.

Představte si sekretářku a ředitele jako dva objekty. Sekretářka umí rozhraní SchopenPsátNaPočítači, kde je např. operace napsatDopis, ale ředitel ho nemá (není to jeho starost). Ale může mít operaci napsatDopis, protože může požadavek předat jinému objektu – sekretářce. Udržování odkazů na jiné objekty se říká skládání objektů a využívání jejich služeb delegování.

Skládání objektů je jednou z nejdůležitějších vlastností objektového datového modelu. Je o dost důležitější než dědičnost. I dědičnost lze v OOP realizovat pomocí skládání objektů.

A konečně zodpovědnost objektu je to, co objekt umí, o co se stará. Objekt by neměl umět sám příliš mnoho a nemusí to dělat sám (viz skládání objektů). Znakem kvalitního návrhu softwaru je to, že třídy v projektu obsahují pokud možno atomické metody, které řeší pouze jeden konkrétní problém.