Object-oriented

Object-oriented: (objektově-orientovaný) - přívlastek, charakterizující celkový přístup ke tvorbě rozsáhlejsích programových celků. Objektově orientovaný přístup je zalozený na myslence, ze 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 mozná 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 vyuzití daného objektu. Cílem objektově orientovaného přístupu je usnadnit tvorbu op 16316u2023q ravdu velkých programů, a dovolit opakované vyuzití jiz jednou vypracovaných objektů, s mozností 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 drzet. Nezbytnost dodrzování určitých zásad, pravidel či celých strategií se přitom stala velmi naléhavou jiz v okamziku, kdy se vytvářené programové celky zvětsily natolik, ze přestalo být v silách jediného člověka, aby se vyznal úplně ve vsem, co se vznikajícího díla týkalo. Zajímavé je, ze to bylo mnohem dříve, nez velikost těchto děl přerostla realizační moznosti jednoho člověka - problém byl v tom, ze člověk-autor mohl jestě zvládat sám vsechno naprogramovat, ale uz se nemusel dostatečně orientovat v tom, co ty které části jeho velkého programu dělají, k čemu slouzí, 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 dotazeno do alespoň nějak fungujícího stádia).

První reakcí na stále se zvysují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í myslenkou zde bylo to, ze při psaní výkonných částí programů (tzv. kódu) je nutné eliminovat vselijaké 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 pozadováno dodrzování takových zásad, které přehlednost zvysují, resp. udrzují ji na přijatelné úrovni, a tím usnadňují nejen samotné programování a ladění, ale i následnou údrzbu jiz existujících programových celků (například pozdějsí doplňování nových funkcí, opravu chyb apod.).

Dodrzování zásad strukturovaného programování výrazně pomohlo k tomu, aby se znatelně zvětsil objem "jestě zvládnutelných" programů. Vývoj se ovsem nedal zastavit, a přínos strukturovaného programování časem přestal postačovat. Formování představ o "správném programování" nastě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ějsí změnou byl mnohem větsí důraz na data - jestlize strukturované programování si vsímalo předevsím kódu, pak nový objektově orientovaný přístup si stejnou měrou vsímá jak kódu, tak i dat. Při určitém zjednodusení si jeho hlavní poselství lze vylozit tak, ze "je třeba zavést vhodný řád nejen do kódu, ale také do dat". Konkrétní podoba tohoto řádu je taková, ze 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 mozná "nejblíze" 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íse 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 řeseny jako zcela "samostatné".

Důlezité je také uvědomit si rozdíl mezi objektovým typem (deklarací objektu) a konkrétní instancí (exemplářem) objektu. Například námi uvazovaný 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 pouzit objektově orientovaný přístup: bez objektově orientovaného přístupu by byla volána "samostatná" procedura, schopná zajistit pozadované akce obecně skterýmkoli souborem - přičemz při jejím volání by jí muselo být explicitně zadáno se kterým souborem se má pozadovaná akce provést (nejspíse prostřednictvím odkazu na exemplář datové struktury reprezentující pozadovaný soubor). Takze například při otevírání souboru by slo o volání typu open(soubor). Naproti tomu při pouzití objektově orientovaného přístupu by kazdý soubor byl reprezentován vlastním exemplářem vhodného objektu, a jeho otevření by potom znamenalo určit příslusný objekt a ten pozádat o otevření souboru (konkrétně zavolat metodu příslusného objektu zajisťující otevření souboru, tj. slo by o volání typu soubor.open).

Důlezitý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 kdyz výstiznějsí by mozná bylo "zabalení" - naznačující ze 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 mozná nejvíce lokalizovat veskerou "slozitost" do jednotlivých objektů, a nesířit ji mimo ně, kde by zbytečně zvysovala komplikovanost a slozitost výsledného programového celku.

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

Dalsím výrazným rysem objektově orientovaného přístupu je snaha vyhnout se opakovanému programování věcí, které jiz byly jednou naprogramovány, neboli snaha o moznost opakovaného vyuzití jiz existujících objektů. Objektově orientovaný přístup se snazí tuto moznost implementovat co mozná nejvýhodnějsím způsobem, tak aby opakované vyuzití 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í myslenka zde je taková, ze se umozní vytvářet nové objekty podle vzoru jiných objektů, ovsem s tím, ze nové objekty nemusí přebírat úplně vsechny vlastnosti a metody svých vzorů, ale mohou si v zásadě kterékoli z nich podle vlastního uvázení pozměnit, upravit, přidat apod. Existuje zde dokonce i jistá podobnost s genetikou (kdy se také některé vlastnosti rodičů přenásí na jejich potomky, a jiné vlastnosti pozměňují). Kvůli tomu se pak moznost vytvářet nové objekty po vzoru jiz existujících označuje jako dědičnost (anglicky: inheritance).

Moznost dědičnosti mezi objekty pak doslova nahrává do ruky takovému postupu řesení určitého problému, který odpovídá jeho postupnému "zjemňování", neboli přechodu od obecnějsího ke konkrétnějsí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ás příklad se soubory - zde by mohl být vytvořen jeden objektový typ pro reprezentaci vsech 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. Kazdý 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 rozlisení, metodu pro spustění spustitelného souboru, údaj o počtu řádků textového souboru apod.