Role komponent v tvorbě softwaru

Objektově orientované programování vystoupilo na denní světlo na počátku 90. let. Dnes už je notoricky známou vývoj...


Objektově orientované programování vystoupilo na denní světlo na počátku 90.
let. Dnes už je notoricky známou vývojářskou technikou prakticky všechny
aplikace jsou dnes tvořeny právě jejím prostřednictvím. Díky intenzivnímu
využívání existují značné tlaky na další vývoj objektově orientovaných
technologií. A právě jemu se věnujeme v následujícím textu.
Objektová technologie definuje objekt jako účelovou množinu atributů a metod.
Objektové technologie a jednotlivé vývojové prostředky začaly tradiční
vlastnosti objektů různými způsoby rozšiřovat. Všechna tato rozšíření si kladou
za cíl zkvalitnit abstrakci určitého výseku reality, kterou objekty poskytují.
Je také důležité si v této souvislosti uvědomit, že objektově orientované
programování obecně nerozšiřuje možnosti programovacích jazyků jen si klade za
cíl lépe provázat tvorbu programového kódu s reálnými procesy, se kterými se
aplikace integruje. Nejčastěji používaným rozšířením je obohacení objektů o
tzv. "vlastnosti" (properties). Ty mají svojí logikou a použitím poměrně blízko
k atributům. Z pohledu uživatele se vlastnosti jeví jako běžné atributy,
jejichž hodnoty můžeme normálním způsobem číst i modifikovat. Ve skutečnosti
však čtení a modifikace tohoto "virtuálního atributu" vyvolává dvě metody,
které korektním způsobem zapouzdřují čtení a modifikaci hodnoty atributu. Tento
způsob psaní programového kódu je vesměs přehlednější a přímočařejší a
prohlubuje princip zapouzdřenosti objektově orientovaného programování.
Poměrně žádanými jsou z pohledu vývojářů služby zpracování událostí tedy
distribuce jednoduché informace všem objektům určitého typu (v daném pořadí).
Každý objekt má následně možnost na událost nějakým způsobem zareagovat.
Technika šíření událostí se typicky používá v situaci, kdy jeden objekt se buď
snaží navázat komunikaci s jiným neznámým objektem, nebo potřebuje určitou
informaci předat většímu množství neznámých objektů.
Poslední často žádanou objektovou službou jsou transakce. Základním (a
nejviditelnějším) požadavkem na transakce s objekty je stejně jako u databází
tzv. "atomicita" od transakce tedy požadujeme, aby se korektně provedla celá,
nebo aby se neprovedla vůbec. U databází je tento požadavek snáze
realizovatelný, neboť datová entita obsahuje pouze vlastní data. Objekt může
kromě atributů (které nesou data) procházet mnoha stavy a navíc může ještě
interagovat s dalšími objekty. Pro realizaci transakcí s objekty je proto při
tvorbě objektů nutné dodržet určitá pravidla (určitá omezení) a je vyžadovaná
určitá podpora od hostujícího prostředí. Na úspěších objektových technologií se
rozvíjejí komponentové technologie, které rozšiřují možnosti objektů a řeší
některé další problémy. Přinášejí zejména nezávislost na vývojovém nástroji a
snazší tvorbu distribuovaných aplikací.

Komponentové technologie
Základní problém objektů spočívá v tom, že je jejich využití více méně vázáno
na vývojový nástroj, ve kterém byly vytvořeny. Přenos objektů do jiných
vývojových nástrojů je sice v určité omezené míře možný, ale vždy je spojen s
problémy. Většinou je k tomu také zapotřebí předat uživateli zdrojový kód
příslušného objektu.
Komponenty jsou jakési binární objekty, které mají přesně definované
(standardizované) rozhraní, takže jsou snadno využitelné aplikacemi, které jsou
vytvořeny v jiných vývojových nástrojích. Vývojáři za to ale zaplatí určitou
cenu vyvolávání metod je daleko obtížnější a pomalejší. Komponentové
technologie proto nabízejí určité prostředky, které vyvolávání metod komponent
zjednodušují na stejnou úroveň, jako by šlo o vyvolávání metod běžného objektu.
Komponentové technologie vesměs nepodporují přímo atributy (tak jako objekty) a
nutí tak uživatele k důslednému zapouzdřování. Komponentové technologie také
vesměs nepodporují dědičnost.

Přínosy komponent
Komponenty se také staly základním nástrojem pro distribuované zpracování.
Většina komponentových technologií zajišťuje ve vlastní režii poměrně složité
vyvolávání metod. Odtud je již jen malý krok k tomu, aby komponentové
technologie odstiňovaly uživatele od fyzického umístění instance komponenty.
Uživatel tedy má možnost stejným způsobem vyvolávat metody komponenty, která
běží lokálně na stejném systému jako klientská aplikace, i komponenty, která
běží na vzdáleném počítači.
Doposud jsme na komponentové technologie pohlíželi z perspektivy objektů.
Komponentové technologie ale také slouží jako obecný integrační prostředek pro
integraci částí obchodní logiky (případně uživatelského rozhraní). Komponenty,
díky otevřeně definovanému rozhraní, umožňují snadné propojení více aplikací
mezi sebou. Některé aplikace dokonce přímo předpokládají, že budou rozšiřovány
o různé doplňky, se kterými budou integrovány pomocí komponentové technologie.
Komponenty jsou také jedním z prostředků, který podporuje týmový vývoj
aplikací. Po skončení analytické části, kdy se definují jednotlivé komponenty a
jejich rozhraní, může paralelně několik vývojářů vyvíjet různé komponenty. O
to, aby komponenty "zapadly" do sebe, se částečně stará komponentová
technologie. Díky nezávislému rozhraní je dokonce možné, aby každý člen týmu
používal pro vývoj jiný vývojový nástroj.
Takováto modulární architektura aplikací umožňuje také snazší aktualizaci a
inovaci aplikací stačí pouze aktualizovat příslušné komponenty.
Komponenty přinášejí do světa softwaru principy, které se ve světě elektroniky
používají již dávno. Tedy vytváření univerzálně použitelných bloků, ze kterých
je možné stavět konkrétní řešení. Jednotlivé technologie
Patrně nejpoužívanější komponentovou technologií je dnes COM (myšleno souhrnně
COM, DCOM a COM+). Tuto technologii vyvinul Microsoft a zahrnul ji do všech
32bitových verzí operačního systému Windows. Tato technologie má také masivní
podporu na straně vývojových nástrojů podporují ji prakticky všechny vývojové
nástroje na této platformě. Tato technologie však stojí a padá s platformou
Windows ačkoliv existují pokusy o rozšíření technologie COM i na jiné (unixové)
platformy, nejsou zde realizované implementace příliš zdařilé a mají mnohá
nepříjemná omezení. Tato technologie má také poněkud horší podporu pro
distribuované zpracování, ale naopak je velice efektivní pro tvorbu malých,
efektivně pracujících komponent pro vrstvu uživatelského rozhraní. Trochu škoda
je také to, že tato technologie byla částečně nevhodně upravena pro potřeby
Visual Basicu.
Jinou komponentovou technologií je architektura CORBA. Tato technologie je
vyvinuta nezávislým sdružením OMG, které sdružuje mnoho velkých výrobců
softwaru. CORBA, jakožto produkt OMG, je ale pouze specifikace. Existuje
několik implementací (prakticky na všech platformách), bohužel však nejsou 100%
kompatibilní. Architektura CORBA vznikala primárně na podporu distribuovaného
zpracování a zapouzdření obchodní logiky, takže tyto oblasti jsou propracované
do detailu. CORBA je ale poměrně těžkopádná pro tvorbu malých komponent, takže
je těžko použitelná jako technologie pro tvorbu rozhraní mezi více aplikacemi.
Programování malých komponent (např. pro uživatelské rozhraní) je prakticky
nemožné.
Zajímavou komponentovou technologií je Enterprise JavaBeans. Je určena pro
tvorbu komponent v Javě. Stejně jako Java obecně je nezávislá na platformě, ale
je naopak pevně svázaná s programovacím jazykem Java. Tato technologie je dosti
specifická, neboť platforma Javy do značné míry zajišťuje to, co jinak musí
zajišťovat komponentové technologie. Technologie Enterprise JavaBeans jde však
ještě o kus dál obsahuje poměrně sofistikovanou podporu pro sdílení komponent
nebo pro transakce.

Objektový přístup k datům
Uplatnění objektových technologií se rozrůstá i v oblastech, kde si dlouho
vývojáři od jejich využití mnoho neslibovali. Jednou z takovýchto oblastí je
přístup k datům z aplikací. Donedávna se pro tyto účely používal prakticky
výhradně jazyk SQL. To bylo způsobeno jeho poměrně dobrou standardizací, ale
také tím, že databázové operace jsou mimořádně diverzifikované a jsou proto
relativně obtížně podchytitelné jednoduchým a srozumitelným objektovým modelem.
Poměrně velký zlom v této oblasti nastal s příchodem velmi jednoduchých
vývojových nástrojů jako jsou Delphi nebo Visual Basic, jež otevřely vývoj
aplikací i pro mnoho méně kvalifikovaných vývojářů, kteří často SQL neznali. Ti
se dožadovali nějakých jednodušších cest, jak databáze obsluhovat pomocí
objektového modelu. Abychom nemluvili pouze všeobecně, příkladem objektového
přístupu k datům může být knihovna ADO (ActiveX Data Objects), která se používá
ve vývojových nástrojích Microsoftu nebo knihovna VCL (Visual Components
Library), která se používá v nástrojích Borlandu.
Ačkoliv se objektového přístupu k databázím zhostilo několik firem, je zajímavé
zjištění, že všechny došly k velmi podobným výsledkům. Ve všech objektových
modelech se na konceptuální úrovni rýsují 4 třídy, které se pro přístup k datům
používají. První třída zapouzdřuje datový zdroj jako celek (resp. databázové
připojení), druhý zapouzdřuje jeden konkrétní databázový příkaz (ať už dotaz
nebo obecný SQL příkaz), třetí zapouzdřuje výsledek příkazu a čtvrtý
zapouzdřuje operace s jednou položkou jednoho databázového záznamu.
Konkrétní implementace mají samozřejmě mnohá specifika a mnohá rozšíření.
Obvykle zde ještě existují samostatné třídy pro správy chyb. Některé objektové
modely obsahují poměrně šikovnou třídu, která zapouzdřuje "databázovou
session". Pomocí takové třídy je možné izolovat několik transakcí v rámci
jednoho klienta. A když už narážíme na transakce i ty bývají často zapouzdřeny
do jednoduché třídy. Některé objektové modely (např. VCL) též slučují vlastní
databázový příkaz a jeho výsledek do jediné třídy. Knihovna VCL ale zase naopak
obsahuje zvláštní třídy pro přístup k tabulce, dotazu, pohledu a uložené
proceduře. Toto rozdělení do samostatných tříd zjednodušuje práci s
jednoduchými (málo parametrizovatelnými) objekty (např. tabulkou), ale naopak
do jisté míry objektový model znepřehledňuje. Všechny tyto databázové objekty
jsou přístupné skrze dotazy.
Jaká je aktuální situace? Přístup k datům je skutečně možné realizovat
objektově. Objekty zapouzdřují přístup k datovému zdroji, databázový příkaz,
procházení výsledku, ale SQL zůstává nadále ve hře více či méně skryté pod
povrchem. Zřetelný posun kupředu je zde viditelný a zpříjemnění práce je patrné
zejména v případě konfigurace přístupu k datovému zdroji a v případě procházení
výsledu dotazů v tabulární podobě. Pro konstrukci složitějších databázových
příkazů (zejména dotazů) se ale vývojáři bez znalosti SQL neobejdou.

.NET objekty
Architektura .NET (Dot Net) je jednou z nových iniciativ Microsoftu. Reaguje na
postupně se měnící trh s informačními systémy, kde se více než kdy předtím
požaduje otevřenost architektury a možnost integrace. Trh s informacemi se také
přeorientovává z "licencí na použití" na "poplatky za služby".
Microsoft do jisté míry musí otevřenost a integraci s jinými technologiemi
podporovat, ale na druhou stranu si zase pečlivě hlídá, aby mu někdo příliš
"nelezl do zelí". Proto lze při podrobnější analýze některých skutečností
vyčíst silnou touhu po udržení své exkluzivní tržní pozice.
K vizi Microsoftu (kterou zde nemá smysl celou rozebírat) povede ještě dlouhá
cesta a nelze dnes s jistotou říci, že vše půjde dle současných představ firmy.
Současným ztělesněním vize je tzv. .NET Framework, který přináší do vývoje
aplikací na platformě Windows mnohé novinky.
Z pohledu objektových technologií je důležitou zprávou to, že .NET Framework
přichází s novou generací objektů, které se mají stát náhradou COM komponent.
Tyto objekty jsou (podobně jako komponenty) nezávislé na použitém nástroji,
takže budou přenositelné mezi různými nástroji případně i od různých výrobců.
Tyto objekty však jsou (na rozdíl od komponent) pro jednotlivé programovací
jazyky "nativní" a budou tudíž přímo využitelné.
Objekty (jako ostatně veškerý kód aplikací) jsou překládány do podoby jakéhosi
mezikódu (Microsoft Intermediate Language), který je následně v provozním
prostředí přeložen do nativního kódu toho kterého prostředí. Zcela odlišně se
také přistupuje k dynamickému alokování paměti runtime prostředí je obohaceno o
"Garbage Collector", který se automaticky stará o odstranění nevyužitých
objektů.
.NET Framework pokrývá i další záležitosti do jisté míry unifikuje tvorbu
uživatelského rozhranní pro aplikace Windows i pro HTML aplikace, obsahuje
knihovny (objekty) pro manipulaci s XML, SQL, sítí apod.
1 0462 / pen










Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.