Object-oriented

Object-oriented: (objektově-orientovaný) - přívlastek, charakterizující celkový přístup ke tvorbě rozsáhlejších programových celků. Objektově orientovaný přístup je založený na myšlence, že věci které spolu logicky souvisí (zejména data i operace nad nimi) by měly tvořit jediný celek (tzv. objekt), a měly by být co možná nejvíce uzavřeny do sebe - tak aby maximum logických vztahů, souvislostí i jakýchkoli detailů mohlo být lokalizováno uvnitř objektu, a vně objektu byly viditelné pouze takové vlastnosti a operace, které jsou nezbytně nutné pro využití daného objektu. Cílem objektově orientovaného přístupu je usnadnit tvorbu opravdu velkých programů, a dovolit opakované využití již jednou vypracovaných objektů, s možností jejich přizpůsobení, upřesnění či jiného dopracování.

Po celou dobu, kdy se lidé zabývají programováním, si také formují své představy o tom, jak by vlastně programování mělo vypadat, jakými principy by se mělo řídit a jakých zásad by se mělo držet. Nezbytnost dodržování určitých zásad, pravidel či celých strategií se přitom stala velmi naléhavou již v okamžiku, kdy se vytvářené programové celky zvětšily natolik, že přestalo být v silách jediného člověka, aby se vyznal úplně ve všem, co se vznikajícího díla týkalo. Zajímavé je, že to bylo mnohem dříve, než velikost těchto děl přerostla realizační možnosti jednoho člověka - problém byl v tom, že člověk-autor mohl ještě zvládat sám všechno naprogramovat, ale už se nemusel dostatečně orientovat v tom, co ty které části jeho velkého programu dělají, k čemu slouží, jaké mají vazby na ostatní části apod. Důsledky "ztráty celkového přehledu" pak byly často katastrofální, a projevovaly se zejména v nízké kvalitě výsledného díla (pokud bylo vůbec někdy dotaženo do alespoň nějak fungujícího stádia).

První reakcí na stále se zvyšující náročnost vznikajících programových celků bylo formulování zásad, známých jako "zásady strukturovaného programování". Hlavní myšlenkou zde bylo to, že při psaní výkonných částí programů (tzv. kódu) je nutné eliminovat všelijaké ad-hoc přístupy (například skoky Goto odkudkoli kamkoliv), které mají velmi destruktivní vliv na celkovou přehlednost a srozumitelnost zdrojového kódu. Místo těchto ad-hoc přístupů bylo naopak požadováno dodržování takových zásad, které přehlednost zvyšují, resp. udržují ji na přijatelné úrovni, a tím usnadňují nejen samotné programování a ladění, ale i následnou údržbu již existujících programových celků (například pozdější doplňování nových funkcí, opravu chyb apod.).

Dodržování zásad strukturovaného programování výrazně pomohlo k tomu, aby se znatelně zvětšil objem "ještě zvládnutelných" programů. Vývoj se ovšem nedal zastavit, a přínos strukturovaného programování časem přestal postačovat. Formování představ o "správném programování" naštěstí pokračovalo dál, a časem dalo vzniknout celé nové filosofii programování, která je dodnes označovaná jako "objektově orientovaný přístup".

Zřejmě nejvýznamnější změnou byl mnohem větší důraz na data - jestliže strukturované programování si všímalo především kódu, pak nový objektově orientovaný přístup si stejnou měrou všímá jak kódu, tak i dat. Při určitém zjednodušení si jeho hlavní poselství lze vyložit tak, že "je třeba zavést vhodný řád nejen do kódu, ale také do dat". Konkrétní podoba tohoto řádu je taková, že data se uspořádají podle toho, čeho se týkají, resp. co reprezentují, a ty části kódu, které se těchto dat týkají, se umístí co možná "nejblíže" těmto datům, a výsledek se "zabalí" do jedné společné "obálky". Výsledkem je situace, kdy data a související programy tvoří logický celek, kterému se začalo říkat objekt (anglicky: object).

Upřesněme si to na konkrétním příkladu: představme si program, který při své činnosti nějakým způsobem manipuluje se soubory. Takovýto program by si nejspíše zavedl takový druh objektu, který by reprezentoval soubor, a obsahoval by jak "datové" části (tzv. atributy) odpovídající vlastnostem souborů (například jeho jméno, příponu, velikost, vlastníka apod.), tak i procedurální prvky (tzv. metody), například rutiny pro otevření souboru, pro čtení ze souboru, pro přejmenování souboru. Naproti tomu bez objektově orientovaného přístupu by se zavedl datový typ reprezentující pouze datové atributy souborů, zatímco procedury pro manipulaci se soubory by byly řešeny jako zcela "samostatné".

Důležité je také uvědomit si rozdíl mezi objektovým typem (deklarací objektu) a konkrétní instancí (exemplářem) objektu. Například námi uvažovaný příklad by si jednou zavedl objektový typ reprezentující soubor, a pak si podle tohoto vzoru (typu) vytvořil několik instancí (exemplářů), reprezentujících konkrétní soubory se kterými program potřebuje manipulovat.

Zajímavý je i "filosofický" rozdíl v konkrétní manipulaci stěmito soubory oproti situaci, kdy by nebyl použit objektově orientovaný přístup: bez objektově orientovaného přístupu by byla volána "samostatná" procedura, schopná zajistit požadované akce obecně skterýmkoli souborem - přičemž při jejím volání by jí muselo být explicitně zadáno se kterým souborem se má požadovaná akce provést (nejspíše prostřednictvím odkazu na exemplář datové struktury reprezentující požadovaný soubor). Takže například při otevírání souboru by šlo o volání typu open(soubor). Naproti tomu při použití objektově orientovaného přístupu by každý soubor byl reprezentován vlastním exemplářem vhodného objektu, a jeho otevření by potom znamenalo určit příslušný objekt a ten požádat o otevření souboru (konkrétně zavolat metodu příslušného objektu zajišťující otevření souboru, tj. šlo by o volání typu soubor.open).

Důležitým momentem, hodným opakovaného zdůraznění, je vzájemné spojení ("zabalení") datových atributů i procedur (metod) do jednoho celku - objektu. Tento jev se obvykle označuje jako tzv. zapouzdření (encapsulation), i když výstižnější by možná bylo "zabalení" - naznačující že některé věci uvnitř objektu zcela záměrně nejsou mimo objekt viditelné. Tento fakt souvisí se snahou koncipovat jednotlivé objekty tak, aby maximum detailů, funkcí i logických souvislostí mohlo být soustředěno uvnitř objektu, a pokud to není nezbytně nutné, nemusely být "zviditelňovány" vně objektu. Smyslem těchto snah je co možná nejvíce lokalizovat veškerou "složitost" do jednotlivých objektů, a nešířit ji mimo ně, kde by zbytečně zvyšovala komplikovanost a složitost výsledného programového celku.

Vrátíme-li se zpět knašemu příkladu se soubory a objekty které tyto soubory reprezentují, pak například veškeré konkrétní a často dosti specifické akce spojené sotevíráním souboru mohou zůstat skryty vrámci příslušného objektu, a navenek může být "viditelná" pouze existence samotné metody pro otevření souboru (tj. tuto metodu je možné volat z vně objektu, ale její konkrétní implementace není z vně objektu patrná).

Dalším výrazným rysem objektově orientovaného přístupu je snaha vyhnout se opakovanému programování věcí, které již byly jednou naprogramovány, neboli snaha o možnost opakovaného využití již existujících objektů. Objektově orientovaný přístup se snaží tuto možnost implementovat co možná nejvýhodnějším způsobem, tak aby opakované využití nemuselo být jen mechanickým převzetím bez jakýchkoli změn, ale mohlo být spojeno i s případnými aktualizace, změnami, dopracováním či jinými úpravami. Základní myšlenka zde je taková, že se umožní vytvářet nové objekty podle vzoru jiných objektů, ovšem s tím, že nové objekty nemusí přebírat úplně všechny vlastnosti a metody svých vzorů, ale mohou si v zásadě kterékoli z nich podle vlastního uvážení pozměnit, upravit, přidat apod. Existuje zde dokonce i jistá podobnost s genetikou (kdy se také některé vlastnosti rodičů přenáší na jejich potomky, a jiné vlastnosti pozměňují). Kvůli tomu se pak možnost vytvářet nové objekty po vzoru již existujících označuje jako dědičnost (anglicky: inheritance).

Možnost dědičnosti mezi objekty pak doslova nahrává do ruky takovému postupu řešení určitého problému, který odpovídá jeho postupnému "zjemňování", neboli přechodu od obecnějšího ke konkrétnějšímu. Dobře vyhovuje například i tomu, aby jeden autor vypracoval určitý objektový typ, a jiný autor pak na jeho práci navázal, a podle zmíněného objektového typu vytvářel dceřinné objektové typy (podtypy) měnící některé vlastnosti a metody.

Představme si opět náš příklad se soubory - zde by mohl být vytvořen jeden objektový typ pro reprezentaci všech souborů jako takových, a prostřednictvím dědičnosti pak vytvořeny jeho "dceřinné" objektové typy reprezentující po řadě textové soubory, spustitelné binární soubory, soubory s rastrovými obrázky apod. Každý z těchto dceřinných typů by přebíral takové atributy a metody svého rodičovského typu, které by nepotřeboval měnit (například atributy vyjadřující jméno a příponu souboru, metodu pro přejmenování souboru apod.), a přidával by či měnil by pouze to, co je specifické pro daný typ souboru - například metodu pro vykreslení grafického obrázku v určitém rozlišení, metodu pro spuštění spustitelného souboru, údaj o počtu řádků textového souboru apod.

Jiří Peterka