Objektovo orientované programovanie a evolúcia vývoja softvéru

Objektovo orientované programovanie (ďalej len OOP) nevzniklo náhodou, ale je dôsledkom vývoja, ktorý k nemu smeroval. Jedná sa o moderné metodiku vývoja softvéru, ktorú podporuje väčšina programovacích jazykov. Častou chybou je, že sa ľudia domnievajú, že OOP sa využíva iba pri písaní určitého druhu programov a inak je na škodu. Opak je pravdou - OOP je filozofia, je to nový pohľad na funkciu programu a komunikáciu medzi jeho jednotlivými časťami. Malo by sa používať vždy, či už robíme malú utilitku alebo zložitý databázový systém. OOP nie je len technika alebo nejaká odporúčaná štruktúra programu, je to hlavne nový spôsob myslenia, nový náhľad na problémy a nová éra vo vývoji softvéru. Najskôr sa pozrieme do histórie, ako sa programovalo skôr a ktoré konkrétne problémy OOP rieši. Je to totiž dôležité na to, aby sme pochopili, prečo OOP vzniklo.

Tento článok sa zameriava priamo na metódy písania kódu a objektovo orientované programovanie, nie na metodiky vývoja softvéru všeobecne.

Evolúcia metodík

Medzi tým, ako sa programovalo pred 40tich rokmi a ako sa programuje dnes, je veľký rozdiel. Prvé počítače neboli zariadené veľkým výkonom a aj ich softvér nebol nijako zložitý. Vývoj hardvéru je však natoľko rýchly, že sa počet tranzistorov v mikroprocesoroch každý rok zdvojnásobí (Moorov zákon). Bohužiaľ, ľudia sa nedokážu rozvíjať tak rýchlo, ako sa rozvíja hardvér. Stále rýchlejšie počítače vyžadujú stále zložitejšie a zložitejšie softvér. Keď sa v jednej chvíli zistilo, že okolo 90% softvéru je vytvorené s oneskorením, s dodatočnými nákladmi alebo zlyhalo úplne, hľadali sa nové cesty, ako programy písať. Vystriedalo sa tak niekoľko metód, ktoré si tu popíšeme.

1. Imperatívne metóda

Táto metóda má blízko strojovému kódu a jediná možnosť, ako urobiť niečo viackrát, je príkaz GOTO. Ten "skáče" na uvedené miesto v programe (náznak cyklu). Tejto metóde sa prezýva "spaghetti code" pre jej neprehľadnosť a čoskoro prestala postačovať pre vývoj zložitejších programov.

Uvedomme si, že obrovské rozšírenie počítačov za posledných niekoľko dekád má na svedomí rast dopytu po softvéru a logicky tiež rast dopytu po programátoroch. Iste existujú ľudia, ktorí dokážu bez chyby písať programy v ASM alebo iných nízkych jazykoch, ale koľko ich je? A koľko si asi za takú nadľudskú prácu účtujú? Je potreba písať programy tak, aby aj menej skúsení programátori dokázali písať kvalitné programy a nepotrebovali k tvorbe jednoduchej utilitky 5 rokov praxe.

2. Modulárny programovanie

Myšlienka tejto metódy spočíva v rozdeľovaní veľkých problémov na viac menších. K tomu sa používajú tzv. Subrutiny (podprogramy), ktoré si pamätajú, odkiaľ boli zavolaný a vráti sa späť.

Štruktúrované programovanie

Štruktúrované programovanie je prvá metodika, ktorá sa udržala dlhší čas a naozaj chvíľu postačovala pre vývoj nových programov. Program tu postupuje zhora nadol a je využitá tzv. Funkcionálne dekompozícia. Problém sa rozloží na niekoľko podproblémů a každý Podproblém potom rieši určitá funkcie s parametrami. Nevýhodou je, že funkcia vie len jednu činnosť, keď chceme niečo iné, musíme napísať novú. Neexistuje totiž spôsob, ako vziať starý kód a len trochu ho modifikovať, musíme písať znovu a znovu - vznikajú zbytočné náklady a chyby. Túto nevýhodu možno čiastočne obísť pomocou parametrizácie funkcií (počet parametrov potom ale rýchlo narastá) alebo použitím globálnych premenných. S globálnymi dátami vzniká však nové nebezpečenstvo - funkcie majú prístup k dátam ostatných. To je začiatok konca, nikdy totiž neustrážime, aby niekde nedošlo k prepísaniu glob. dát medzi funkciami a začne dochádzať k nekontrolovateľným problémom. Celý program sa potom skladá z nezapouzdřených blokov kódu a zle sa udržiava. Každá úprava programu zvyšuje zložitosť, program potom nutne dôjde do stavu, kedy náklady na pridávanie nových funkcií vzrastú na toľko, že sa program už neoplatí rozširovať. Zástupcovia tohto prístupu sú napríklad jazyky C a Pascal.

Ako už som sa zmienil na začiatku článku, niekedy sa uvádza, že sa jednoduché programy majú písať neobjektové, teda štruktúrovane. Nie je to však pravda, keď vynecháme fakt, že porušujeme filozofiu OOP ako takú, nikdy nemôžeme vedieť, či sa tento program neuchytia az malej utilitky sa nestane niečo vážnejšieho. Potom opäť nutne dospejeme do stavu, kedy program nebude možné ďalej rozširovať a budeme ho buď musieť zahodiť alebo celý prepísať s pomocou OOP.

Objektovo orientovaný prístup

Jedná sa o filozofiu a spôsob myslenia, dizajnu a implementácia, kde kladieme dôraz na znovupoužitel­nost. Metodika nachádza inšpiráciu v priemyselnej revolúcii - vynález základných komponentov, ktoré budeme ďalej využívať (napr. Keď staviame dom, nebudeme si páliť tehly a sústružiť skrutky, proste je už máme hotové).

Poskladanie programu z komponentov je výhodnejšie a lacnejšie, môžeme mu veriť, je otestovaný (o komponentoch sa vie, že fungujú, sú otestované a udržiavané). Ak je niekde chyba, stačí ju opraviť na jednom mieste. Sme motivovaní k písania kódu prehľadne a dobre, pretože ho po nás používajú druhí alebo my sami v ďalších projektoch (priznajme si, že človek je od prírody lenivý a keby nevedel, že sa jeho kód bude znovu využívať, nesnažil by sa ho písať kvalitne ).

Ako OOP funguje

Snažíme sa nasimulovať realitu tak, ako ju sme zvyknutí vnímať. Môžeme teda povedať, že sa odpútavame od toho, ako program vidí počítač (stroj) a píšeme program skôr z pohľadu programátora (človeka). Ide teda o určitú úroveň abstrakcie nad programom. To má značné výhody už len v tom, že je to pre nás prirodzenejšie a prehľadnejšie.

Základnou jednotkou je objekt, ktorý zodpovedá nejakému objektu z reálneho sveta (napr. Objekt človek). Objekt má svoje atribúty, čím sú myslené vlastnosti čiže dáta, ktoré uchováva (napr. U človeka meno a vek). Ďalej má metódy, ktoré sú schopnosťami, ktoré vedia vykonávať (u človeka napr. Jdi_do_prace, pozdrav, mrkni).
Už teda vieme, že:

objekt = náhrada objektu z reality
atribút = vlastnosť
metóda = schopnosť

Trieda

Trieda je vzor, podľa ktorého sa objekty vytvára. Definuje ich vlastnosti a schopnosti.

Objekt, ktorý sa vytvorí podľa triedy, sa nazýva inštancia. Instance majú rovnaké rozhranie ako trieda, podľa ktorej sa vytvára, ale navzájom sa líšia svojimi dátami (atribúty). Majme napríklad triedu človek a od nej si vytvorme inštancie Karel a Josef. Obe inštancie majú iste tie isté metódy a atribúty, ako trieda (napr. Meno a vek) a metódy (jdi_do_prace, pozdrav), ale hodnoty v nich sa líši (prvá inštancia má atribút meno Karel a vek 22, druhá Jozef a 45).

Komunikácia medzi objektmi prebieha pomocou odovzdávania správ, vďaka čomu je syntaxe prehľadná. Správa zvyčajne vyzerá takto: příjemce.jméno_me­tody (parametre). Napr. karel.pozdrav (susedka) by mohol spôsobiť, že inštancia karel pozdraví inštanciu susedka.

OOP stojí na základných troch pilieroch:

1. Zapuzdrenie

Zapuzdrenie umožňuje skryť niektoré metódy funkcie, aby zostali použiteľné len pre triedu zvnútra. Objekt si môžeme predstaviť ako čiernu skrinku, ktorá má určité rozhranie (interface), cez ktoré jej odovzdávame inštrukcie / dáta a ona je vykonáva.

Nevieme, ako to vo vnútri funguje, ale vieme, čo to robí. Nemôžeme teda spôsobiť nejakú chybu, pretože využívame a vidíme len to, čo je sprístupnené. Napríklad keď budeme potrebovať zistiť, či je objekt auto schopný jazdy, nebudeme napr. Kontrolovať stav benzínu v nádrži, pretože sa môže stať, že auto bude elektromobil a nádrž mať nebude - došlo by k chybe. Zavoláme metódu je_pojizdne (), ktorá nám vráti stav auta a nezaujíma nás ako to urobí, pretože vieme, že to urobí dobre. Je totiž napísaná samotným tvorcom triedy Auto a ten najlepšie vie, ako kontrolu jazde s vykonať.

Zapuzdrenie teda donúti programátorov používať modul len tým správnym spôsobom. Rozhranie (interface) rozdelí na verejne prístupné (public) a vnútornú štruktúru (private).

2. Dedičnosť

Dedičnosť je jedna zo základných vlastností OOP a slúži k tvoreniu nových dátových štruktúr na základe starých. Pokúsim sa to vysvetliť na jednoduchom príklade:

Budeme chcieť vytvoriť objekty programátor a grafik, kde grafik bude vedieť kresliť a programátor programovať. Bolo by určite zbytočné a neprehľadné, keby sme si museli definovať obe triedy úplne celé, pretože mnoho vlastností týchto 2 objektov je spoločných. Programátor aj grafik budú mať určite meno a vek a budú vedieť ísť do práce a ísť spať. Vytvorím teda triedu človek, kde definujú atribúty spevokol a meno a metódy jdi_do_prace a jdi_spat.

Teraz vytvorím triedu programátor, ktorá bude dediť z triedy človek. Bude mať teda automaticky tie isté metódy a atribúty, ako človek + k nej listom metódu programujte. Podobne to bude s grafikom, ktorý opäť dedí z človeka, ale má navyše metódu kresli.

Takto nemusíme opisovať oboma triedam tie isté atribúty, ale stačí dopísať to, v čom sa líšia, a zvyšok zdediť. Prínos je obrovský, môžeme rozširovať komponenty o nové metódy a tým je znovu využívať. Nemusíme písať hŕbu redundantného (duplikovaného) kódu. A hlavne - keď zmeníme jediný atribút v materskej triede, automaticky sa táto zmena všade zdedí. Nedôjde teda k tomu, že by sme to museli meniť ručne u 20tich tried a niekde na to zabudli a spôsobili chybu. Sme ľudia a chybovať budeme vždy, musíme teda používať také programátorské postupy, aby sme mali možnosť chybovať čo najmenej.

O materskej triede sa niekedy hovorí ako o nadtřídě ao triede, ktorá z nej dedí, ako o podtriede. Podtrieda môže pridávať nové metódy alebo si prispôsobovať metódy z materskej triedy (viď ďalej).

Niekedy sa dokonca stáva, že si niektorú triedu vytvoríme len za účelom, aby z nej dedili ostatné triedy (napr. Triedu človek si vytvoríme len za účelom dedenia do tried grafik a programátor, ale samotný človek v programe nemá žiadnu inštanciu). Takýmto triedam sa hovorí abstraktné.

Jazyky, ktoré dedičnosť podporujú, buď vie dedičnosť jednoduchú (trieda dedí len z jednej triedy) alebo viacnásobnú (trieda dedí hneď z niekoľkých tried naraz, tu podporujú len niektoré jazyky)

3. Polymorfizmus

Polymorfizmus umožňuje používať jednotné rozhranie pre prácu s rôznymi typmi objektov. Majme napríklad veľa objektov, ktoré reprezentujú nejaké geometrické útvary (kruh, štvorec, trojuholník). Bolo by určite prínosné a prehľadné, keby sme s nimi mohli komunikovať jednotne, hoci sa líšia. Keby sme mohli mať triedu GeometrickyUtvar, ktorá by obsahovala atribút farba a metódu vykresli. Všetky geometrické tvary by potom dedili z tejto triedy jej interface (rozhranie). Ale objekty kruh a štvorec sa iste kreslí inak. Polymorfizmus nám umožňuje prepísať si metódy vykresli pri každej inštancie tak, aby robili, čo chceme, ale rozhranie zostalo zachované a my nemuseli premýšľať, ako sa to u onoho objekte volá.

Polymorfizmus býva často vysvetľovaný na obrázku so zvieratami, ktoré majú všetky v rozhraní metódu speak, ale každé si ju vykonáva po svojom.

Na záver si ukážme, ako môže vyzerať definícia triedy v prog. jazyku (Tu C ++)

Dedičnosť

class Person {
  String first, mi, last;
  String getName() {
     return first + mi + last;
  }
}

class Doctor: Person {

String getName () {
    return "Dr." + Person::getName();
  }
}