Image
8.6.2016 0 Comments

Stretnutie s Pascalom II. /3. časť

Späť na úvod >> Späť na programovanie >> Späť na seriál

Dnes sa zameriame na niektoré ďalšie postupy pri tvorbe OOP programov, pripomenieme si a bližšie rozoberieme už skôr spomínané problémy. (Opakovanie je matkou múdrosti!)

Prístup k dátovým položkám objektu

Je všeobecne uznávaným pravidlom, vyplývajúcim z filozofie OOP a hlavne z princípu zapuzdrenia, že prístup k dátovým položkám objektu sa realizuje pomocou špeciálnych metód, a nie priamo. Meniť a čítať hodnoty dátových položiek objektu smú iba metódy tohto objektu. Nerešpektovaním tohto pravidla síce môžeme v určitých prípadoch skrátiť zdrojový text programu, ale pripravíme sa tým o výhodu vyplývajúcu z toho, ako sa v OOP poníma súvislosť dát a kódu. Ak je vďaka zapuzdreniu jednoznačne určené, s ktorými dátami môže ktorá metóda pracovať, znížI sa alebo priamo vylúči nebezpečie, že použijeme nevhodnú procedúru na nevhodné dáta. Táto kontrola bola predtým len a len na programátorovi.

Nešetrite na metódach

Pridaním metód do vášho programu zväčší zdrojový text objem. Inteligentný linker (spojovací program, ktorý je súčasťou prekladača Turbo Pascalu) však vo výslednom kóde vypustí tie metódy, ktoré v programe nie sú nikdy volané. Nemusíte preto váhať nad tým, či každý program použije alebo nepoužije metódu vášho objektu. Nepoužité metódy vás nestoja nič, pokiaľ ide o veľkosť .EXE súboru - ak nie sú použité, tak v ňom jednoducho nie sú! Preto môžeme napísať zdrojový text s väčším počtom metód, čím sa stáva univerzálnejším.

Písanie konštruktorov a deštruktorov

Ako sme si už povedali, konštruktory a deštruktory sú špeciálne metódy, ktorých použitie je potrebné v prípade, že objekt obsahuje virtuálne metódy (a ak hovoríme o deštruktore, tak v prípade, ak inštancia objektu obsahuje dynamicky vzniknuté položky). Pretože konštruktor treba volať pred prvým použitím niektorej z virtuálnych metód, je výhodné vyvolávať ho ako vôbec prvú metódu daného objektu. (Tak sa to napokon rieši automaticky v prípade dynamickej alokácie objektu pomocou rozšírenej syntaxie príkazu New.)
            Logickým pokračovaním je sústrediť do konštruktora všetky akcie súvisiace s inicializáciou objektu, teda nastaviť počiatočné hodnoty všetkých dátových položiek objektu tak, ako je potrebné pre nasledujúcu správnu činnosť programu. Deštruktor by mal byť virtuálny. Vysvetlenie prečo, vyplynie z ďalšieho textu, tu sa obmedzíme na jednoduché konštatovanie.

Objektovo orientované unity a rozšíriteľnosť objektov

Ako vieme, ani jeden väčší program sa nezaobíde bez unitov - knižníc. Mechanizmus samostaných pripojiteľných unitov spolu s OOP dáva možnosť písať kvalitatívne novú obdobu klasických unitov. Týmto spôsobom je vytvorená aj jednotka Turbo Vision, ktorou sa budeme zaoberať onedlho.
            Myslime na to, že píšeme unit nielen pre seba, ale ho možno budú chcieť využívať aj iní programátori. To predsa nie je nič nezvyčajné, ide o tvorivú činnosť v prospech ostatných. (Či to postavíte na komerčnej báze, alebo nie, to už je iná vec!) Ak píšeme taký objektovo orientovaný unit, uvedieme v sekcii INTERFACE definíciu všetkých objektov, ktoré chceme sprístupniť používateľovi unitu. Telá týchto objektov spolu s definíciami objektov, ktoré pred používateľom zostanú neviditeľné, uvedieme v sekcii IMPLEMENTATION.
            Ak potom dodáme používateľovi takto vytvorenú jednotku v preloženom tvare .TPU, chránime tým svoj zdrojový text (a nápad), pokiaľ ho nechceme zverejniť. Na druhej strane však používateľa nepripravujeme o možnosť rozširovať alebo pozmeniť funkciu nami napísaného kódu. To umožňuje jednak mechanizmus dedičnosti, jednak vlastnosť polymorfizmu.

Používateľ totiž môže definovať svoj objekt, ktorý je potomkom niektorého objektu definovaného v našom unite, a to aj vtedy, keď nemá jeho zdrojový text. Pre takto definovaný objekt bude platiť všetko, čo sme dosiaľ povedali o mechanizme dedičnosti. Ak je určitá metóda definovaná v objekte skrytom niekde v .TPU súbore ako virtuálna a používateľ ju vo svojom potomkovi predefinuje, "skrytý" predok o tom dostane informáciu a každé prípadné volanie tejto metódy v iných svojich metódach vykoná korektne, teda zavolá tú správnu, novú verziu metódy. Z toho vyplýva, že ak je kód objektov v unite vhodne napísaný, používateľ môže bez zásahu do zdrojového textu meniť unitu funkciu týchto objektov a prispôsobovať ju svojim požiadavkám. Je to veľký krok smerom k čo najväčšej využiteľnosti hotových programových modulov a veľký pokrok v porovnaní s klasicky chápanými knižnicami funkcií.

Statické versus virtuálne metódy

Ak uvážime to, čo sme uviedli v predchádzajúcom odseku, je zrejmé, že treba starostlivo uvážiť, či urobíme tú-ktorú metódu virtuálnou, alebo nie.
            Ak nadefinujeme niektorú metódu ako statickú, teda bez použitia kľúčového slova virtual, dosiahneme tým väčšiu rýchlosť jej vykonania. Táto metóda sa totiž vykoná priamo, bez predchádzajúcich pomocných akcií, lebo pri preklade sa do cieľového kódu na miesto volania takejto funkcie zapíše priamo jej adresa. Táto rýchlosť je však zaplatená tým, že sme používateľa pripravili o akúkoľvek možnosť prispôsobiť funkciu metódy svojím potrebám (o ktorých nemožno vylúčiť, že budú aspoň nepatrne odlišné od toho, čo sme predpokladali v čase písania metódy).
            Ak robíme, naopak, niektorú z našich metód virtuálnou, bude situácia presne opačná. Používateľ má síce možnosť v niektorom potomkovi funkciu metódy zmeniť, aby pritom nenarušil fungovanie ostatných metód, ale vyvolanie takejto metódy bude pomalšie. Dochádza k nemu v podstate v dvoch fázach: najpv sa pomocou odkazu siahne do tabuľky virtuálnych metód pre skutočnú adresu virtuálnej metódy, a až potom sa prevedie vlastný skok na kód tejto metódy.
            Ako sa teda pri tej-ktorej konkrétnej metóde rozhodnúť? Jedna z odporúčaných taktík spočíva v tom, že väčšinu metód nadefinujeme virtuálne. Statické metódy zavádzame, len keď je potrebná časová optimalizácia programu, a to tam, kde sme si istí, že používateľ nepocíti potrebu modifikovať nami navrhnutú funkciu metódy.
            Na tomto mieste je potrebné vrátiť sa ku skoršej poznámke o tom, že deštruktory by mali byť definované ako virtuálne. Je to preto, že spravidla nemôžeme vylúčiť, či používateľ nepridá v niektorom potomkovi nášho objektu ďalšiu dynamicky alokovanú položku. A pretože deštruktor je najprirodzenejšie miesto, kde tieto dynamické položky môžu byť uvoľnené, mali by sme používateľovi dať možnosť zmeniť funkciu deštruktora tak, aby uvoľňoval aj jeho nové položky. Preto by deštruktor mal byť virtuálny, aj keď nevyhnutné to, samozrejme, nie je.

Vzájomná priraditeľnosť objektov

Ak máme dve premenné typu objekt, pričom jedna je inštanciou predka, druhá je inštanciou potomka, môžeme vykonať nasledujúce priradenie:

predok:=predok
potomok:=potomok
predok:=potomok

Naopak, nesprávne je priradenie:

potomok:=predok

Ak sa vrátime k nášmu príkladu, sú správne tieto priradenia:

var pc1, pc2 : pocitac;
    at1, at2 : atecko ;
 
begin
   pc1:=pc2;
   at1:=at2;
   pc1:=at2;
end.


            Vysvetlenie takéhoto poňatia kompatibility typov spočíva v mechanizme dedičnosti. Tento mechanizmus zabezpečuje, že každý potomok má všetky dátové položky svojho predka a môže mať niektoré navyše. Nimi sa definícia objektu potomka rozširuje. Je teda jasné, že pri priradení potomka predkovi môžeme bez problémov naplniť všetky položky predka.
            Pri opačnom priradení nemôžeme vylúčiť, že v potomkovi zostanú niektoré položky nedefinované, preto priradenie potomok:=predok nie je dovolené.
            Rovnaké pravidlá platia aj pre vzájomné priraďovanie hodnôt ukazovateľov na objekty. Ukazovateľ na určitý objekt môže vždy ukazovať aj na potomkovský objekt. Táto vlastnosť je veľmi výhodná, umožňuje nám napríklad vytvárať všeobecné fronty objektov. Ak je formálnym parametrom procedúry či funkcie objekt, môže byť skutočným parametrom aj ľubovoľný jeho potomok.

Kľúčové slová Private, Public a Protected

Počínajúc verziou 7.0 Turbo Pascalu a produktom Delphi, Pascal obsahuje nové kľúčové slová Private, Public (TP 7.0) a Protected (Delphi). V predchádzajúcich verziách totiž nebolo vôbec možné nejakým spôsobom obmedziť viditeľnosť vlastností definovaného objektu. Teraz môžeme pomocou týchto špeciálnych slov rozdeliť položky objektu do troch skupín:
verejné – public : bežne dostupné z ktoréhokoľvek miesta programu
chránené – protected : dostupné iba pre tzv. spriatelené objekty, teda objekty z určitej definovanej skupiny,
osobné – private : dostupné iba z objektu, v ktorom sú definované.

Možno si teraz poviete, na čo je to dobré. Samozrejme, pri programovaní v Turbo Vision by sme sa bez toho zaobišli. Ale v Delphi sú tieto slová "vždy a všade", preto je dobré, aby sme ich poznali. O tom, ako pracujú, si povieme neskôr.
Teraz máte pocit, že som vás napchával teóriou o ničom a všetkom bez praktického využitia. Je to normálne, aj šoférovať ste sa učili najprv teoreticky, až po zvládnutí pravidiel ste išli na praktickú jazdu. Ale aby sme si ukázali praktické využitie teoretických znalostí, napíšeme si nabudúce nejaký objektovo orientovaný programík.

 


Nechajte si posielať prehľad najdôležitejších správ emailom

Mohlo by Vás zaujímať

Ako na to

Ako zbaviť fotky hmly

08.12.2016 11:59

Hmla alebo dym sú často veľmi kreatívne nástroje. No všetkého veľa škodí. Fotka potom stráca kontrast a v podstate na nej nič nevidieť. Hmlu môžete neraz následnými úpravami odstrániť alebo zredukovať ...

Ako na to

Užitočné SW nástroje

08.12.2016 11:53

AllDup v4.0.3 Určenie: program na vyhľadávanie a odstraňovanie duplicitných súborov Vlastnosti: duplicitné súbory sa vyhľadávajú len na zvolených diskových jednotkách alebo len v rámci vybraných ...

Ako na to

Fotografovanie s bleskom

08.12.2016 11:47

Ak máte moderný fotoaparát so vstavaným alebo externým bleskom, zdá sa vám téma článku triviálna. Jednoducho nastavíte vhodný režim, vyberiete najlepšiu kompozíciu záberu, exponujete a o zvyšok sa už ...

Žiadne komentáre

Vyhľadávanie

Kyocera - prve-zariadenia-formatu-a4-s-vykonom-a3

Najnovšie videá