IntegrovanΘ prost°edφ rubriky Visual Basic

Autor: Jßn Hanßk

TΘma m∞sφce

OOP a Visual Basic .NET (1. dφl)

╚asovß nßroΦnost

(min):

45

ZaΦßteΦnφk

PokroΦil²

Profesionßl

Pou₧it² operaΦnφ systΘm : Hlavnφ v²vojov² nßstroj :

DalÜφ v²vojov² software :

Jin² software :

Windows 2000 SP4

Visual Basic .NET 2003

Äßdn²

Äßdn²

 

 

Milφ Φtenß°i,

 

rok 2004 odstartujeme sΘrii materißl∙, p°φpadov²ch studiφ a programov²ch ukßzek, kterΘ vßs uvedou do sv∞ta objektov∞ orientovanΘho programovßnφ ve Visual Basicu .NET 2003. V tomto vydßnφ se zam∞°φme spφÜe na teoretick² ·vod do OOP, p°iΦem₧ si p°edstavφme zßklady tΘto programovacφ koncepce a takΘ pojmy t°φda a objekt. P°eji vßm p°φjemnΘ poΦtenφ.

 

Obsah

Objektov∞ orientovanΘ programovßnφ versus strukturßlnφ programovßnφ

Zßkladnφ teze objektov∞ orientovanΘho programovßnφ

Objektov∞ orientovanß koncepce programovßnφ

T°φda a objekt

 

 

Objektov∞ orientovanΘ programovßnφ versus strukturßlnφ programovßnφ

 

AΦkoliv je objektov∞ orientovanß koncepce programovßnφ znßmß programßtor∙m ji₧ hodn∞ dlouh² Φas, je nutnΘ poznamenat, ₧e ne v₧dy se k programovßnφ poΦφtaΦov²ch aplikacφ p°istupovalo v souladu s filozofii OOP. Pokud budeme abstrahovat od samotn²ch poΦßtk∙ v²voje programovßnφ, kdy pojem programovßnφ poΦφtaΦe p°edstavoval peΦlivou manußlnφ prßci vysoce odborn²ch pracovnφk∙ a in₧en²r∙, kte°φ äprogramovaliô poΦφtaΦ p°epφnßnφm kombinacφ jednotliv²ch elektrick²ch souΦßstek a spoj∙, m∙₧eme °φct, ₧e ve skuteΦnosti ub∞hlo mnoho Φasu, k²m se v programovßnφ objevily objekty. V t∞chto dßvn²ch Φasech bylo znaΦn²m ·sp∞chem, kdy se programovßnφ poΦφtaΦe p°eneslo od ruΦnφ manipulace s jednotliv²mi souΦßstkami k poΦφtaΦov²m terminßl∙m.

 

P°itom nesmφme zapomφnat na to, ₧e v padesßt²ch letech dvacßtΘho stoletφ byly poΦφtaΦe daleko v∞tÜφ oproti stavu, v jakΘm je znßmΘ dnes (v²jimkou tehdy nebyly ani poΦφtaΦe, kterΘ zabφraly n∞kolik desφtek metr∙ ΦtvereΦnφch).

 

Programßto°i se sna₧ili vytvo°it prvnφ programovacφ jazyky, pomocφ kter²ch by bylo mo₧nΘ ovlßdat poΦφtaΦe pou₧itφm terminßlu, a to jako lokßlnφho, tak vzdßlenΘho. Byly vytvo°eny jazyky, kterΘ bychom v souΦasnΘ dob∞ nazvaly jazyky nφzkΘ ·rovn∞. Tyto programovacφ jazyky toti₧ p°φmo ovlßdaly hardware poΦφtaΦe. P°φkladem takovΘho nφzko·rov≥ovΘho programovacφ jazyka je jazyk symbolick²ch instrukcφ, ve kterΘm se pou₧φvali pro laiky zcela nepochopitelnΘ sady znak∙ a numerick²ch hodnot, jejich₧ kombinace vytvß°eli p°φkazy pro poΦφtaΦ. S jazykem symbolick²ch instrukcφ se m∙₧ete st°etnout i dneska, a to nap°φklad p°i programovßnφ v jazyku C.

 

 

Pokud se blφ₧e podφvßme na architekturu a styl prßce platformy .NET Framework, i zde nachßzφme jistou obdobu jazyku symbolick²ch instrukcφ, ovÜem na programßtorsky a kvalitativn∞ vyÜÜφ ·rovni. Ano, mßm na mysli Microsoft Intermediate Language, mezijazyk, do instrukcφ kterΘho jsou p°eklßdßny vÜechny spoleΦnΘ v²stupy programovacφch jazyk∙ platformy .NET.

 

 

AΦkoliv byl t°eba p∙vodnφ jazyk symbolick²ch instrukcφ pou₧iteln², nebyl ani zdaleka äprogramßtorsky p°φv∞tiv²ô. To mimo jinΘ znamenalo, ₧e i ti programßto°i, kte°φ s tφmto programovacφm jazykem pracovali, museli vynalo₧it velkΘ mno₧stvφ ·silφ a Φasu pro to, aby se dovedli v jazyku alespo≥ jak₧ tak₧ orientovat. Proto vznikla pot°eba pro vytvo°enφ programovacφch jazyk∙ vyÜÜφ ·rovn∞. Tyto programovacφ jazyky by m∞ly poskytovat velice dobr² p°φstup k ovlßdanφ hardwarov²ch mo₧nostφ poΦφtaΦe, ovÜem m∞lo by se s nimi lΘpe a snadn∞ji pracovat. Tak byly vytvo°eny programovacφ jazyky, kterΘ bychom z dneÜnφho pohledu oznaΦili jako jazyky st°ednφ ·rovn∞. Pokud jste tipovali, ₧e do tΘto skupiny pat°φ dnes ji₧ legendßrnφ jazyk C, m∞li jste samoz°ejm∞ pravdu. CΘΦko, jak byl tento programovacφ jazyk zanedlouho familiΘrn∞ p°ezdφvßn, nebylo vytvo°eno tak°φkajφc äna zelenΘ louceô, ale vyvinulo se z jin²ch jazyk∙, p°iΦem₧ znaΦnou charakteristiku tomuto jazyku vtiskl programovacφ jazyk B.

 

Jazyk C byl ve sv∞t∞ programovßnφ velice populßrnφ, a to p°edevÜφm z n∞kolika nßsledujφcφch d∙vod∙:

 

 

Je pochopitelnΘ, ₧e v²hod jazyka C bychom p°i peΦliv∞jÜφ anal²ze naÜli vφce, ovÜem to nenφ naÜφm cφlem. Jazyk C je toti₧ typick²m p°edstavitelem jazyka, ve kterΘm se programßtorskΘ ·koly °eÜily stylem takzvanΘ strukturovanΘ koncepce programovßnφ (n∞kdy se tento styl programovßnφ oznaΦuje rovn∞₧ jako procedurßlnφ programovßnφ). Pokud situaci pon∞kud zjednoduÜφme, m∙₧eme prohlßsit, ₧e ka₧d² poΦφtaΦov² program byl vlastn∞ tvo°en kolekcφ jist²ch programov²ch entit, kter²m se °φkalo funkce. Jedna funkce z mno₧iny vÜech funkcφ programu m∞la v²st°ednφ postavenφ, p°iΦem₧ byla oznaΦovßna jako vstupnφ funkce. Vstupnφ funkce p°edstavovala vstupnφ bod programu, co znamenß, ₧e v₧dy, kdy₧ byl dan² program spuÜt∞n a jeho data naΦtena do pam∞ti poΦφtaΦe, byl realizovßn k≤d vstupnφ funkce. V jazyku C byla touto vstupnφ funkcφ funkce s nßzvem main, kterß mohla takΘ vracet jistou nßvratovou hodnotu funkce (v zßvislosti od toho, zdali byl k≤d v tΘto funkci vykonßn ·sp∞Ün∞ Φi nikoliv). Prßce strukturovanΘho programu tedy vypadala jako rozhovor mezi jednotliv²mi funkcemi: Funkce mohly mezi sebou komunikovat, p°iΦem₧ si navzßjem poskytovali v²sledky svΘ Φinnosti. Ka₧dß funkce obsahovala jeden, nebo i n∞kolik p°φkaz∙, kterΘ byly provedeny zßhy potΘ, co byla tato funkce aktivovßna.

 

V programßtorskΘ hant²rce se pro aktivaci funkce za₧il ekvivalentnφ termφn volßnφ funkce.

á

StrukturovanΘ programovßnφ bylo zcela jist∞ ·sp∞Ünou programßtorskou koncepcφ. P°ipome≥me, ₧e na tΘto koncepci stav∞ly i dalÜφ programovacφ jazyky, nap°φklad Basic a Pascal. AΦkoliv strukturovanΘ programovßnφ bylo ·sp∞ÜnΘ, m∞lo n∞kolik negativnφch znak∙, kterΘ se objevily zejmΘna p°i programovßnφ rozsßhlejÜφch aplikacφ (ti, kte°φ programovali v jazyku Basic na 8bitov²ch poΦφtaΦφch mi dajφ zcela jist∞ za pravdu). Pokud se zeptßte programßtory na otßzku, co jich napadne jako prvnφ p°i zmφnce o strukturovanΘm programovßnφ, dostanete r∙znΘ odpov∞di. Jedni vßm °eknou, ₧e strukturovanΘ programovßnφ se vlastn∞ äjaksiô kryje s programovacφm jazykem C, zatφmco jinφ budou hovo°it o funkcφch a jejich prototypech. Mo₧nß, ₧e najdete i takovΘ programßtory, kte°φ vßm strukturovanou koncepci programovßnφ charakterizujφ jako tu äne objektov∞ orientovanouô.

 

Bohu₧el, nemßme dostatek prostoru a pota₧mo ani Φasu, abychom teorii strukturovanΘho programovßnφ zkoumali p°φliÜ do hloubky. Je vÜak tak°ka definitivnφ pravdou, ₧e strukturovanΘmu programovßnφ chyb∞l prßv∞ ten objektov² pohled na sv∞t.

 

 

Zßkladnφ teze objektov∞ orientovanΘho programovßnφ

 

Vychßzejme ze zßkladnφ teze, podle kterΘ m∞ly poΦφtaΦe simulovat reßln² ₧ivot, to znamenß pracovat s p°edm∞ty, neboli objekty a simulovat procesy, kterΘ lze s t∞mito objekty realizovat. AΦkoliv dodnes vlastn∞ nevφme, jak nßÜ skuteΦn² sv∞t vznikl, nem∙₧eme pop°φt existenci doslova miliard objekt∙, kter²mi jsme denn∞ obklopeni. Tyto objekty m∙₧eme t°φdit podle mnoha kritΘriφ, nap°φklad podle jejich hnutelnΘ povahy na hnutelnΘ (auto, poΦφtaΦ, televize) a nehnutelnΘ (budovy, domy, stavby), p°φpadn∞ ₧ivotnosti (objekty ₧ivΘ a ne₧ivΘ). Zkoumßnφm objekt∙, kterΘ se ve sv∞te nachßzejφ a zßkonitostφ, kter²m tyto objekty podlΘhajφ, se zab²vajφ p°φrodnφ v∞dy, zejmΘna matematika, fyzika, chemie, biologie a dalÜφ.

 

Podle objektov∞ orientovanΘ koncepce by poΦφtaΦ m∞l simulovat objekty a jejich vzßjemnΘ vztahy ve svΘm vlastnφm, zcela virtußlnφm sv∞t∞. Abychom mohli uskuteΦnit proces äkonverzeô objekt∙ reßlnΘho sv∞ta do jejich virtußlnφch prot∞jÜk∙, musφme se podφvat na terminologii objektov∞ orientovanΘ koncepce programovßnφ, jako₧to i na dalÜφ znaky, kterΘ jsou pro tuto koncepci charakteristickΘ.

 

 

Objektov∞ orientovanß koncepce programovßnφ

 

Pokud mßme hovo°it o objektov∞ orientovanΘ koncepci programovßnφ, m∙₧eme se v zßsad∞ vybrat dv∞ma sm∞ry:

 

  1. Prv² sm∞r je spφÜe teoretick², proto₧e p°edstavuje takzvanou vÜeobecnφ koncepci OOP. Podle vÜeobecnφ koncepce objektov∞ orientovanΘ programovßnφ nenφ nutnΘ, aby byl vznik objektu podlo₧en existencφ jistΘ entity, kterß urΦuje charakteristickΘ vlastnosti danΘho typu objektu.

 

  1. Druh² sm∞r bychom mohli nazvat jako äten praktiΦt∞jÜφô, proto₧e p°edstavuje koncepci OOP tak, jak ji chßpou souΦasnΘ programovacφ jazyky, zam∞°enΘ na objektov∞ orientovanΘ programovßnφ. V t∞chto jazycφch je zapot°ebφ v₧dy p°ed tvorbou objekt∙ jistΘho typu vytvo°it entitu, kterß bude tyto objekty generovat. TΘto entit∞ se °φkß t°φda.

 

AΦkoliv je vÜeobecnφ koncepce objektov∞ orientovanΘho programovßnφ opravdu zajφmavß, nebude se s nφ na tomto mφst∞ zab²vat. D∙vodem je zejmΘna mφsty a₧ p°φliÜnß teoretiΦnost, a takΘ pon∞kud nφzkß mφra pou₧itφ tΘto koncepce v praktickΘm programovßnφ pomocφ souΦasn²ch programovacφch nßstroj∙. Zam∞°φme se proto na druh² pohled na OOP koncepci, kter² vßm p°edstavφ objektov∞ orientovanΘ programovßnφ tak, jak jej znßme v dneÜnφch Φasech. áá

 

 

T°φda a objekt

 

T°φda je zßkladnφ jednotkou, na kterΘ je postavena celß koncepce OOP. T°φdu si m∙₧ete p°edstavit jako ätovßrnu na objektyô. T°φda p°esn∞ popisuje, jakß bude vn∞jÜφ i vnit°nφ struktura objektu a rovn∞₧ objektu na°izuje aspekty jeho chovßnφ v jist²ch situacφch. ZjednoduÜen∞ bychom mohli t°φdu p°irovnat ke konstrukΦnφm plßn∙m automobilu, kterΘ precizn∞ definujφ a charakterizujφ vÜechny souΦßstky, z nich₧ se bude automobil sklßdat. Definice vlastnostφ souΦßstek vychßzφ z po₧adavk∙ interakce automobilu s vn∞jÜφm prost°edφm. D∙raz je kladen zejmΘna na kompletnφ zastoupenφ vÜech pot°ebn²ch element∙, kterΘ vytvß°ejφ jednotn² celek û objekt. PodobnΘ po₧adavky, jakΘ jsou vy₧adovßny v automobilovΘm pr∙myslu, musejφ b²t spln∞ny i v pr∙myslu poΦφtaΦovΘm.

Je d∙le₧itΘ, abyste si zapamatovali, ₧e t°φda je v OOP tφm pomysln²m zßkladnφm kamenem, na n∞m₧ spoΦφvajφ dalÜφ aspekty objektov∞ orientovanΘho programovßnφ. Pokud mßme p°ipravenou t°φdu, m∙₧eme ji pou₧φt na tvorbu objekt∙ danΘ t°φdy. Objekt, neboli instance t°φdy, je zt∞lesn∞nφm t°φdy ve virtußlnφm sv∞te poΦφtaΦe û zajφmß tedy podobnou roli jako prototyp auta, kter² byl vyroben podle jist²ch konstrukΦnφch plßn∙. Objekt po svΘm zrozenφ p∙sobφ jako samostatnß entita, co₧ znamenß, ₧e m∙₧e provßd∞t mnohΘ programovΘ operace, vytvß°et dalÜφ objekty, nebo navazovat komunikaci se vzdßlen²mi objekty.

 

Ka₧d² objekt je charakteristick² sv²mi vlastnosti a metodami. Vlastnosti objektu definujφ charakteristiky objektu a lze je ve v∞tÜin∞ p°φpad∙ kvantifikovat. Na druhou stranu, metody p°edstavujφ akce, kterß je objekt schopen realizovat. Abychom si vysv∞tlili pojmy vlastnosti a metody v praxi, uva₧ujme t°eba o automobilu. Automobil je objekt, u kterΘho m∙₧eme nalΘzt nep°ebernΘ mno₧stvφ vlastnostφ, jak²mi jsou nap°φklad v²kon, objem motoru, spot°eba na sto kilometr∙, poΦet dve°φ a dalÜφ. VÜimn∞te si, ₧e vÜechny uvedenΘ vlastnosti m∙₧eme kvantifikovat, ovÜem lze identifikovat i takovΘ vlastnosti, kvantifikace kter²ch je pon∞kud t∞₧Üφ (nap°φklad chemickΘ slo₧enφ karoserie). Automobil sv∙j nßzev dostal podle toho, ₧e je schopn² automatickΘho pohybu v okam₧iku, kdy vodiΦ seÜlßpne plynov² pedßl. V tΘto chvφli automobil uskuteΦnφ akci û pohne se kup°edu. Takovßto akce se v OOP naz²vß metoda. Samoz°ejm∞, ₧e automobil umφ provßd∞t i jinΘ metody, resp. akce, t°eba couvßnφ, zm∞nu sm∞ru na zßklad∞ polohy volantu a dalÜφ.

 

Pro programßtory, kte°φ teprve zaΦφnajφ studovat koncepci objektov∞ orientovanΘho programovßnφ, b²vß zvyΦejn∞ nejt∞₧Üφ rozeznat objekt a t°φdu. Pokud se i vy dostanete do situace, kdy budete p°em²Ület nad urΦitou entitou a v duchu se rozhodovat, zdali jde o t°φdu nebo jejφ instanci (objekt), zkuste nalΘzt vlastnosti zkoumanΘ entity. Pokud se vßm poda°φ nalΘzt jakoukoliv vlastnost, s nejv∞tÜφ pravd∞podobnostφ se pohrßvßte s objektem, proto₧e t°φda jako takovß vlastnostmi nedisponuje.

 

Ka₧d² objekt disponuje jist²m ₧ivotnφm cyklem, kter² je ohraniΦen vytvo°enφm objektu a jeho likvidacφ. V rßmci svΘho ₧ivotnΘho cyklu existuje objekt v pam∞ti poΦφtaΦe, je tedy aktivnφ a m∙₧e zcela flexibiln∞ reagovat na podn∞ty, kterΘ vznikajφ v poΦφtaΦovΘm programu. Je nutnΘ poznamenat, ₧e v²vojem programovacφch jazyk∙ se znaΦn∞ odliÜoval charakter sprßvy vznikl²ch objekt∙. TradiΦnφ programovacφ jazyky, jako nap°φklad jazyk C++ umo₧≥ovaly jednoznaΦn∞ explicitnφ vytvß°enφ a odstra≥ovßnφ objekt∙ z poΦφtaΦovΘ pam∞ti (pou₧φvaly se zde specißlnφ operßtory: new pro vytvo°enφ objektu a delete pro likvidaci objektu). Tφmto pßdem byla sprßva ₧ivotnφho cyklu objektu zcela v rukou programßtora. DneÜnφ programovacφ nßstroje, kterΘ pracujφ na bßze platform∞ .NET Framework pracujφ s automatickou sprßvou objekt∙ v pam∞ti (softwarovß slu₧ba, kterß sleduje vÜechny objekty a likviduje ty nepot°ebnΘ, se naz²vß Garbage Collection).

 

 

Prßv∞ jste doΦetli TΘma m∞sφce.á

 

Jestli₧e se chcete dozv∞d∞t vφce informacφ o programovßnφ ve Visual Basicu .NET, nevßhejte a navÜtivte takΘ dalÜφ sekce rubriky Visual Basic. A jakß₧e je dneÜnφ nabφdka?

Serißl ZaΦφnßme s VB .NET

Charakteristika logick²ch operßtor∙ AndAlso a OrElse.

Programßtorskß laborato°

Generovßnφ chybov²ch v²jimek

Vytvß°enφ formulß°∙ libovoln²ch tvar∙

Ovlßdacφ prvek ProgressBar