reklama

Umíme to s Delphi: 165. díl – komponentní technologie, požadavky na komponenty

Dnešní článek se opět týká komponentových technologií. Dnes se podrobně zaměříme na požadavky na komponenty – jinak řečeno, ukážeme si, co od komponent očekáváme a proč.

Vítejte u dalšího pokračování našeho seriálu o programování v Delphi. Znovu se potkáváme u článku na téma Komponentní technologie. Stručně připomeňme, čím jsme se zabývali dosud.

Před 14 dny jsme si pověděli, co jsou to komponentové technologie a proč se o nich vlastně bavíme. Víme už tedy, že rozhodneme-li se zvolit pro vývoj své aplikace komponentní technologii, velmi zjednodušeně řečeno vlastně „vyskládáme“ svou aplikaci ze vzájemně nezávislých komponent. Co to ony komponenty jsou? Softwarová komponenta je definována jako softwarový element, který odpovídá komponentovému modelu, může být nezávisle šířen a může se skládat s ostatními komponentami podle definovaného kompozičního standardu bez jakýchkoliv změn.

Komponentový model pak definuje specifické interakce mezi komponentami a kompoziční standardy. Implementace komponentového modelu je specializovaná množina spustitelných softwarových elementů vyžadovaná k podpoře spouštění komponent odpovídajících tomuto modelu.

V dílu minulém jsme se pak zabývali výhodami komponentních technologií. Pověděli jsme si o pěti bodech, jež bývají uváděny jako největší bonusy, které může práce s komponentními technologiemi nabídnout. Realisticky jsme se však zastavili u každého z nich, abychom pochopili, že nemusí být všechno zlato, co se třpytí. Nicméně, zmínili jsme následující výhodné atributy komponentního vývoje:

  • vývoj aplikace nekončí jejím přeložením,
  • aplikace jsou přizpůsobitelnější,
  • existence knihoven komponent,
  • distribuované komponenty,
  • jazyková nezávislost komponent.

Tolik k dosavadní náplni našeho seriálu. Pojďme se nyní podívat na to, co nás čeká dnes. A dnes nás čeká povídání o tom, jaké máme na komponenty požadavky.

Požadavky na komponenty

Výhody komponent, které jsme podrobně popsali a rozebrali v předchozí kapitole, přímo plynou e schopnosti komponent dynamicky se stát součástí aplikace a dynamicky se z aplikace zase odpojit. K dosažení této schopnosti musí být splněny základní dva požadavky: dynamické připojování a skrývání detailů o své implementaci.

Dynamické připojování (linkování)

Aby mohl uživatel nahradit jednu komponentu za jinou při běhu aplikace, je nutné, aby se k sobě aplikace připojovaly dynamicky. V opačném případě by bylo nutné po každé změně provést opětovný překlad aplikace. Tento požadavek je v komponentních modelech obecně zajištěn.

Skrývání detailů o své implementaci (zapouzdření)

Podrobnosti o tom, jak jsou komponenty (avšak i klienti) implementováni, nesmí ovlivnit způsob jejich vzájemného spojení. Proto komponentní modely přinášejí nějaký mechanismus rozhraní, pomocí kterého se k sobě komponenty a klienti připojují. Tato rozhraní se obecně nemění, čímž je zajištěno, že změna implementace komponenty nebo klienta neovlivní druhou stranu komunikace. Čím lépe je rozhraní odstíněno od implementace, tím méně bude ovlivněno změnou implementace klienta nebo komponenty.

Pokud chceme zachovat toto odstínění klienta od komponenty prostřednictvím rozhraní, je nutné vznést několik omezení, která je nutné na komponenty aplikovat:

  • Komponenta skrývá jazyk, v němž je implementována. V ideálním případě bychom se neměli zajímat o implementační jazyk komponenty: kterýkoliv klient by měl být obecně schopen připojit se ke kterékoliv komponentě. Odhalení jazyka může vést k novým závislostem mezi komponentou a klientem.
  • Komponenty jsou distribuovány v binární formě. Mají-li komponenty být schopny skrýt svou implementaci, musí být distribuovány již přeložené, slinkované a připravené k použití.
  • Komponenty jsou „upgradable“ se zachováním zpětné kompatibility. Klient používající starší komponentu nesmí mít problémy při příchodu nové verze. Klient nesmí být závislý na konkrétní verzi používané komponenty.
  • Komponenty musí být transparentně přemístitelné po síti. Klient a komponenty musí být schopny běhu jak v tomtéž procesu, tak i v různých procesech nebo dokonce na různých počítačích.

Kromě těchto základních požadavků na komponenty, které v podstatě pokrývají drtivou většinu toho, co se s komponentami a s jejich vzájemnou spoluprací a interakcí děje, můžeme identifikovat i několik dalších, které se v praxi ukazují jako velice cenné a také prakticky nepostradatelné.

Například, potřebujeme zajistit možnost vícenásobného použití. Co to znamená? Požadavek na vícenásobné použití zaručuje možnost vytvoření více instancí (konkrétních kopií) jedné a téže komponenty v rámci téže aplikace. Abychom mohli tohoto požadavku docílit, je nutné zajistit jednu věc: jednoznačně komponenty identifikovat. O tom, jak se jednoznačná identifikace v praxi a v jednotlivých komponentových modelech realizuje, si budeme později povídat podrobně. Každopádně, možná stojí za to požadavek na jednoznačnou identifikaci zmínit samostatně, neboť je také velmi, velmi klíčový.

Takže, dostali jsme se k požadavku na jednoznačnou identifikaci komponenty. Co je však velmi důležité: nebavíme se teď o „druzích komponent“ (komponenta Overeni_opravneneho_pristupu, komponenta Zmena_hesla), ale o konkrétních instancích komponent. Každá jednotlivá instance komponenty, která se v aplikaci vyskytne, musí být plně identifikovatelná, a to nejen svou funkčností. I dvě stejně se chovající instance komponenty, které třeba zvenčí vypadají úplně totožně, musíme mít možnost nějak odlišit. Jinak řečeno, jednoznačný systém pojmenování komponent musí existovat nejen na úrovni modelu, ale zejména na úrovni běžící aplikace: musí existovat způsob, jak po vytvoření komponenty uvnitř běžící aplikace přiřadit této komponentě jednoznačné jméno, které bude používat kdokoliv, kdo bude chtít s komponentou pracovat.

O dalším bodě jsme se už zmínili výše, pojďme tedy jen shrnout: aby mohly komponenty fungovat tak, jak to potřebujeme a abychom z nich mohli „dostat“ co možná nejvíc, musí existovat mechanismu tzv. rozhraní. Jak jsme si řekli, každá komponenta splňuje vlastnost zapouzdření, ale pořád po ní chceme, aby dokázala plně komunikovat se svým okolím. K tomuto propojení komponenty a okolí tedy musí existovat jakási rozhraní (komponenta jich může mít obecně mnoho). Rozhraní jsou vně komponenty: klienti, kteří chtějí komponenty využívat, s ní zásadně komunikují prostřednictvím těchto rozhraní. Přes tato rozhraní posíláme komponentě své požadavky, komponenta přes rozhraní na tyto podněty reaguje. Vlastní implementace komponenty tak může krásně zůstat skrytá.

Každá komponenta může mít více rozhraních. Toho se také obvykle využívá: přece jen je mnohem lepší mít více rozhraní odpovídajících jednotlivým vlastnostem a službám poskytovaným komponentou. Při vytváření rozhraní je třeba mít na paměti jednu věc: čím lépe rozhraní dodržují určité standardy a definované vlastnosti, tím lépe a jednodušeji se s komponentou bude klientům komunikovat – a tedy tím snáze ji budou její uživatelé moci používat.

Další věc, kterou bychom mohli zmínit, je anonymita klienta. Při vytváření komponent musíme mít na paměti, že nemáme absolutně žádné povědomí o jejích budoucích uživatelích – nevíme nic o tom, jací klienti budou komponentu volat. Komponentu nezajímá, kdo ji používá, stejně tak klientovi je úplně jedno, jak přesně komponenta funguje. Nezabýváme se nijak tím, co chce uživatel komponenty, pouze poskytneme přesně zdokumentovaná rozhraní, jejichž prostřednictvím si každý bude komponentu volat.

Pojďme plnou parou k závěru. Poslední vlastností, kterou zmíníme, bude rekurzivní skládání komponent. Ne že by tento požadavek neplynul z toho, co jsme si dosud o komponentách uvedli, na druhou stranu jistě neuškodí malé shrnutí: důležitou vlastností každé komponentní technologie je možnost složit komponentu z jiných komponent. Pravděpodobně alespoň trochu znáte principy objektově orientovaného programování: v objektově orientovaném světě bychom zřejmě hovořili o dědičnosti, pomocí které bychom tento požadavek elegantně vyřešili. U komponent je situace trochu obtížnější: kvůli požadavku na neměnnost rozhraní a kvůli zapouzdření komponent si musíme pomoci trochu oklikou. Problém se řeší tak, že nově vytvářený objekt (objekt, který bude uvnitř sebe obsahovat jiné – vnitřní – komponenty) poskytne všem svým klientům rozhraní svých vnitřních objektů (tedy objektů, z nichž je složen).

Toto jsou základní, obecné požadavky a omezení na komponenty. Je nutné podotknout, že všechny současné komponentové technologie tyto požadavky lépe či hůře podporují a naplňují.

Závěrem

Tolik pro dnešek k obecnému popisu komponent, a toho, co od nich očekáváme. Příští díl našeho seriálu už bude o poznání konkrétnější, začneme se totiž bez váhání zabývat jedním z nejznámějších komponentových modelů – začneme totiž podrobně popisovat komponentový model společnosti Microsoft – COM.

Témata článku: Software, Programování

1 komentář

Nejnovější komentáře

  • gully, gully 5. 10. 2005 0:11:42
    http://umime-to-s-delphi.wz.cz
reklama
Určitě si přečtěte

UPC překopli páteřní kabel. V Brně i druhý den nejede internet ani kabelovka

UPC překopli páteřní kabel. V Brně i druhý den nejede internet ani kabelovka

** V Brně byl velký výpadek služeb UPC ** Důvodem je překopnutý páteřní kabel ** V některých lokalitách služby stále nefungují

5.  12.  2016 | Jakub Čížek | 100

17 expertek Microsoftu předpovědělo rok 2027. Splní se alespoň něco?

17 expertek Microsoftu předpovědělo rok 2027. Splní se alespoň něco?

** Zmizí klasické vyhledávače ** Budeme programovat buňky ** Kvantové počítače překonají šifry

6.  12.  2016 | Jakub Čížek | 34

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

** Novinka od Asusu míří přímo proti MacBooku od Applu ** Nabídne daleko více výkonu za stejné peníze

2.  12.  2016 | David Polesný | 145

11 tipů na dobrý stolní počítač: od základu po herní mašiny

11 tipů na dobrý stolní počítač: od základu po herní mašiny

** Postavte si stolní počítač! Máme pro vás 11 vzorových sestav s rozpisem komponent ** Většina tipů cílí na hráče, věnujeme se ale i základnímu PC a počítačům na střih videa ** Nadělte si nový počítač třeba pod stromeček

5.  12.  2016 | Adam Kahánek | 73


reklama