Umíme to s Delphi: 164. díl – komponentní technologie, výhody komponent

V dnešním článku se zevrubně podíváme na to, jaké výhody nám komponentní vývoj může přinést. Přesněji řečeno, jaké výhody nám komponentní vývoj slibuje přinést. Realita totiž může být mírně odlišná a jak si ukážeme, ani komponentní vývoj není všemocným lékem na všechny potíže, které nás při vývoji aplikací mohou potkat.

Vítejte u dalšího pokračování našeho seriálu o programování v Delphi. Po týdenní odmlce se znovu scházíme u článku na téma Komponentní technologie. Připomeňme, čím jsme se zabývali v minulém článku.

Nejprve jsme si vysvětlili, co jsou to komponentové technologie a proč se o nich vlastně bavíme. Víme už tedy, že komponentní technologie představují jeden z možných způsobů, jak se vyrovnat s rostoucí komplexností softwarových aplikací, s rostoucími požadavky zákazníků a také s dynamikou neustále se měnícího okolního světa, který staví softwarové vývojáře před nelehký úkol - udržovat aplikace stejně flexibilní jako vše ostatní, co se nám mění dnes a denně před očima.

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.

Lidsky řečeno: pokud se rozhodneme skládat software z předpřipravených součástek (nazvaných softwarové komponenty), brzy zjistíme že to není taková procházka růžovým sadem, jak by se mohlo na první pohled zdát (a v okamžiku, kdy se pustíme do ukázkových implementací, tu spatříme dvojnásob :-)). Softwarové komponenty spolu potřebují aktivně a velmi intenzivně komunikovat. Tato komunikace musí být navíc založena na jednoznačných, striktních a široce uznávaných standardech, protože v opačném případě se hned na začátku zřekneme většiny výhod, kterých jsme právě chtěli dosáhnout.

Objevují se proto technologie, které tyto standardy definují. Souhrnně jim říkáme komponentní technologie.

V minulém článku jsme také stručně zabrousili do historie a podívali jsme se na to, jaké přístupy k programování se postupně objevovali. Společně jsme tedy zavzpomínali na:

  • monolitické programování,
  • strukturované programování,
  • objektové programování,
  • dynamicky linkované knihovny (DLL),
  • a nakonec na komponentní technologie.

Výhody komponentního vývoje

Tolik tedy k tomu, co už o komponentách víme. Nyní se můžeme směle zaměřit na téma, které jsme dosud explicitně neotevřeli, avšak které už mnohé čtenáře napadlo, přesněji řečeno, o němž už mnozí nepochybně přemýšleli. Pokusíme se totiž shrnout hlavní výhody, které s sebou komponentní vývoj nese. Pokud by totiž komponentní technologie nepředstavovaly hned několik významných výhod, nemělo by smysl se jimi vůbec nějak hlouběji zabývat.

V důsledku toho, co jsme si o komponentovém softwaru dosud prozradili a s ohledem na principy komponentních technologií asi nikoho nepřekvapí, že pokud se rozhodnete realizovat komponentový vývoj, budete se moci těšit zejména na bonusy uvedené níže.

Nutno podotknout, že následující výhody jsou tak říkajíc knižní. Dalo by se to říct taky tak, že komponentní technologie by mohly teoreticky přinášet následující výhody.

Praxe však není až tak růžová. Ač nejsem na komponenty zrovna expertem z nejpovolanějších, pochopil jsem za dobu, kdy jsem se jimi zabýval, jednu věc: teorie komponent zní krásně a slibně, praxe však bezproblémově funguje jen v několika, ne příliš mnoha oblastech. Ukazuje se, že některé výhody komponent se v praxi mohou stát i překážkami. Pokud si budete sami pro sebe vyvíjet rozsáhlé, sofistikované a povšechně našláplé aplikace, mohou vám komponenty značně usnadnit život. Avšak představa, že si budete od nějaké třetí strany pravidelně kupovat komponenty a stavět z nich běžné aplikace pro své zákazníky, a dokonce že vám bude ona třetí strana ochotně poskytovat podporu a modifikovat komponenty podle vašich představ a požadavků, se v praxi zdá být tak trochu nereálná.

Nějak jsem se zapovídal. Nic z toho, co jsem uvedl, však neznamená, že by komponentní technologie nebyly skvělým přístupem k programování. Jen bych rád, abyste na ně od samého počátku, tedy při čtení jejich deklarovaných výhod, pohlíželi kriticky a uvědomili si, že v praxi není všechno zlato, co se v knize třpytí.

Výhoda první – vývoj aplikace nekončí jejím přeložením

Aplikace se mohou zdokonalovat a vyvíjet v průběhu času, jak se mění a zdokonalují komponenty, z nichž je postavena. Pokud výrobce uvolní komponentu, nic mu nebrání dál pracovat na jejím vývoji a zdokonalování: následně uvolní novou verzi, s níž mohou pracovat stávající klienti bez nutnosti své rekompilace.

Realita: to je pravda a obecně skutečně platí, že dodat zdokonalenou verzi aplikace je s použitím komponent jednodušší než kdy předtím. Jediný problém tak spočívá v tom, že výrobce komponenty zas tak moc „pracovat na jejím vývoji a zdokonalování“ nebude, a někdy se tak můžete dostat do slepé uličky: chcete dodat svým zákazníkům lepší verzi aplikace, ale výrobce komponent, z nichž jste ji postavili, vám sdělí, že nové verze komponent už prostě nebudou, protože se mu to nevyplatí. V tom okamžiku je vaše aplikace prakticky neupgradovatelná.

Výhoda druhá – aplikace jsou přizpůsobitelnější

Aplikace mohou být snáze přizpůsobovány konkrétním požadavkům zákazníků a uživatelů. Toto přizpůsobení se provádí „pouhou“ záměnou komponenty „A“ za jinou komponentu.

Realita:Nutno ovšem podotknout, že uvozovky u slova „pouhou“ jsou na místě: jeden ze zásadních (nejtěžších a nejdražších) úkolů při správě komponentového systému je právě reintegrace a rekompozice, tedy donucení požadovaných komponent, aby spolu rozumně spolupracovaly a poskytovaly očekávané výsledky.

Výhoda třetí – knihovny komponent

Mohou vznikat knihovny komponent. Filozofie komponentního softwaru přímo vybízí ke vzniku nejrůznějších knihoven, v nichž si budou uživatelé a zákazníci jednoduše vyhledávat komponenty podle svých požadavků – komponenty poskytující funkčnost pro daný úkol.

Příklad: při vývoji informačního systému bankovního ústavu jednoduše vyhledáme komponenty „bankomat“, „pobočka“ apod. (případně komponenty na nižší úrovni – „výběr z účtu“, „vklad na účet“, „platební transakce“ apod.) a celý IS snadno poskládáme.

Realita:ukazuje se však (důkazem je množství vědeckých a výzkumných prací zabývajících se touto otázkou), že kromě ohromného problému souvisejícího s integrací takových komponent do funkčního celku se objevuje ještě jedna potíž: jak vyhledat komponenty nejvhodnější pro daný účel. Podle čeho vyhledávat? Jak poznat, že komponenta dělá to, co po ní chceme? Vznikají nejrůznější snahy klasifikovat komponenty podle řady hledisek, případně je popisovat nějakým formálním jazykem, nicméně tato otázka dosud není přijatelně zodpovězena.

Výhoda čtvrtá – distribuované komponenty

Komponenty mohou být umístěny na různých strojích. Tato výhoda komponent je konečně bez otazníků: současné síťové technologie umožňují relativně bez problémů používat komponenty umístěné v geograficky odlišných lokacích. Klient se snadno připojí ke vzdálené komponentě.

Tento úkol je obvykle vyřešen již na úrovni komponentového modelu, který lépe či hůře podporuje síťovou komunikaci a předávání požadavků vzdáleným komponentám. V modelu COM je tato otázka řešena vzdáleným voláním procedur (RPC, Remote Procedure Calling): speciální překladač automaticky vygeneruje kódy pro tzv. skeleton a stub, které následně umožní odstínit uživatele komponenty od síťové komunikace. Uživatel jednoduše zavolá funkci poskytovanou vzdálenou komponentou „A“ stejně, jako by komponenta „A“ byla lokálně dostupná. Pokud není komponenta „A“ lokální, zajistí příslušná dvojice skeleton – stub zavolání požadované funkce vzdálené komponenty „A“, předání parametrů, spuštění funkce a předání návratové hodnoty. Aplikace (klient) se vůbec nestará o to, kde je komponenta fyzicky umístěna.

Výhoda pátá – jazyková nezávislost komponent

Další výhoda je také neoddiskutovatelná, protože značně zvyšuje efektivitu programátorské práce. Při volbě komponentních technologií totiž odpadá nutnost, aby byla celá aplikace vyvíjena v tomtéž programovacím jazyku – každá komponenta může být napsána v takovém vývojovém prostředku, který se pro její vývoj z nějakého důvodu hodí nejlépe. Tento fakt se pak teoreticky nijak neprojeví na celkovém výsledku – komponenty napsané ve Visual Basicu, v Delphi a v C++ spolu mohou bez problémů spolupracovat (pokud budou všechny dodržovat tentýž komponentový model).

Závěrem

Dnes jsme se podívali na to, jaké výhody mohou komponentní technologie obecně přinášet a na to, jak to s jejich využitím vypadá v praxi. Zjistili jsme, že jakkoliv jsou komponentní technologie skvělou myšlenkou, v praxi může být jejich použití trochu obtížnější, než by se mohlo na první pohled zdát. Tak tomu ale je v podstatě u všech technologií, na které si jenom vzpomeneme, nepřičítal bych to tedy komponentám na vrub. Na druhou stranu, jistě stojí za to vědět, že není všechno zlato, co se třpytí a že ani komponenty nejsou všemocným řešením na všechny trable, které na nás při vývoji aplikací číhají.

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

Nejnovější komentáře

Přidat příspěvek
Určitě si přečtěte

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ý | 129

Sbíječky vyměnili za klávesnice. Nový projekt má za cíl přeučit horníky na programátory

Sbíječky vyměnili za klávesnice. Nový projekt má za cíl přeučit horníky na programátory

** Programátorů je málo a horníků bez práce po uzavření dolu Paskov bude moc ** Problém řeší unikátní projekt ** Pilotní kurz dává naději, že by z horníků mohli být použitelní kodéři

28.  11.  2016 | David Polesný | 79