|
Zavádění objektově orientovaného programování do již existujícího projektu
autor: RNDr. Ilja Kraval, říjen 2010
Object Consulting s.r.o.
Server objektových technologií
Úvod
Již několikrát mi byl na školeních a konzultacích položen dotaz, který bych mohl zformulovat do tohoto znění:
Dotaz klienta:
Pro tvorbu informačního systému používáme určité vývojové prostředí. Z historických důvodů jsme při návrhu nepoužili objektový přístup a objektově orientované programování, ale nasadili jsme klasický dnes již zastaralý strukturovaný přístup.
Nyní však již v tomtéž daném prostředí chceme použít objektově orientované programování. Jak tedy máme postupovat, odkud začít a co dělat, když chceme systém překlopit do této „technologicky vyšší kvality“?
V malé sérii článků se budeme zabývat odpovědí na tuto otázku.
Hlavní otázka je o kompatibilitě nového a předešlého prostředí
Pro posouzení dalšího postupu je velmi důležité, zda prostředí, ve kterém se žádá tvořit IS pomocí objektově orientovaného programování, je kompatibilní s předešlým prostředím, ve kterém se tvořil návrh IS pomocí strukturovaného programování. Samo prostředí se totiž drasticky nezmění, je možné pouze navíc nasadit technologii objektově orientovaného programování.
Může se jednat o dvě základní situace:
1. Buď se jedná o zavedení nové verze daného vývojového prostředí, které do určité doby nepodporovalo objektově orientované programování a od určité chvíle již ano,
2. Anebo se může jednat o situaci, kdy se v softwarové firmě nepreferoval objektově orientovaný přístup (což se nyní považuje za nedostatek) a proto padlo rozhodnutí „začít používat objekty“, protože dané prostředí je tak říkajíc „umí“.
Pro další rozhodnutí o postupu je tedy velmi důležitá vlastnost kompatibility předešlého prostředí na nové objektově orientované prostředí.
Podle toho se dále odvíjí další doporučený efektivní postup překlápění systému do technologie objektově orientovaného programování.
O jednom rozšířeném omylu ohledně OOP
I když jsem velký zastánce použití objektově orientovaného programování v projektech, musím zde zdůraznit jeden důležitý poznatek z praxe:
Objektové programování není samo o sobě samospasitelné!
Viděl jsem spoustu systémů, u kterých se v návrhu technologie použil strukturovaný přístup (tj. nasadily se funkce, statické metody tříd apod.) a přesto bych jim dal z hlediska kvality vývoje lepší známku, než některým jiným systémům, kde se použilo objektově orientované programování. V čem je tedy rozdíl?
Je dobré si uvědomit, že zmíněná volba, zda bude program napsaný pomocí objektově orientovaného programování anebo nikoliv, je v podstatě volba typu technologie. Problém návrhu IS je však v tom, že vývoj informačního systému a jeho následná dokumentace není pouze o návrhu a realizaci samotné technologie, ale také o analytickém návrhu, tedy o jeho správném analytickém modelu.
Důležitá poznámka: Pod pojmem „správný analytický model“ mám na mysli nejenom fakticky správný analytický model IS, tj. bez chyb ve smyslu požadovaných funkcionalit a dobře navržených struktur informace, ale který je také napsán striktně a formálně správně podle pravidel analytického modelování v jazyce UML. Druhý fakt zaručuje, že samotný analytický model je psán při dodržení pravidla tzv. objektového paradigmatu, neboli podléhá objektové filosofii.
Může se pak lehce stát, že program napsaný v technologii strukturovaným způsobem, ale přitom s dobře navrženým a formálně správným analytickým modelem, vykazuje z hlediska další údržby a vývoje vyšší kvalitu, než program napsaný objektově orientovaným způsobem se špatně pojatou analýzou, kde se nedodržela pravidla pro psaní analytických modelů v jazyce UML.
Ideální variantou je samozřejmě kombinace „správně navržený analytický model podle pravidel jazyka UML + nasazení objektové technologie“.
V každém případě, pokud v technologii použijeme objektově orientované programování namísto strukturovaného přístupu, dostáváme pak oproti posledně jmenovanému tyto nesporné výhody:
1. Samotný kód je v technologii OOP čitelnější a má mnohem vyšší stupeň transparence než strukturovaný kód. Je to dáno tím, že dobře napsaný srozumitelný a přesný analytický model, který je také dobře zapsán v jazyce UML, je mnohem snáze a čitelněji mapován do objektů, než do nepřehlednějšího strukturovaného programování. Vyhledávání chyb anebo míst změnového řízení je pak v objektovém programu mnohem snazší.
2. Program napsaný „objektově dobře“ je mnohem stabilnější než strukturovaný program. Z objektového paradigmatu plyne u správně napsaného objektového programu nutnost dodržovat princip anonymity klienta (což je důsledek zapouzdření). To vede v programu k mnohem vyšší „blbovzdornosti“ i u menších částí kódu a to až na úroveň samotných objektů ze tříd. Program se tak skládá z „chytrých součástek“ s přesnou logikou vnitřních stavů a tyto součástky jsou schopny ustát jakékoliv problémy s mezními stavy nastalými z jejich okolí. Výsledkem je o mnoho vyšší stabilita programu než u strukturovaného programu, kde si mohou jiné části kódu bez problému navzájem měnit stavy tak říkajíc „pod rukou“, aniž by o tom druhý kód věděl.
3. Objektový program je díky nasazení polymorfismu mnohem flexibilnější, tj. u dobře navrženého objektového programu „změny až tak nemusí bolet“. Požadavky na případná změnová řízení (například přidání funkcionality, výměna částí programu, výměna interfacu s okolím apod.) jsou mnohem snáze realizovatelné a přehlednější, než u strukturovaného programu. Návod pro správné nasazení polymorfismu a dosažení maximální flexibility naleznete ve vzorech Design Patterns (GOF), viz například zde.
První závěr týkající se zavedení OOP do již existujícího „starého“ projektu je nyní zřejmý:
Nebylo by správné přeceňovat nasazení technologie OOP z hlediska jejího přínosu do „starého projektu“ jako samospasitelné v tom smyslu, že nám vyřeší všechny problémy starého systému.
Na druhé straně je zřejmé (jak vyplývá z výčtu výhod použití objektově orientované technologie v předešlém odstavci), že zavádění objektově orientovaného programování do „starého projektu“ je žádoucí, protože má své nesporné výhody.
V příštím článku si na základě těchto poznatků rozebereme konkrétní návrh, jak postupovat při zavedení objektově orientovaného programování do již existujícího projektu.
Pokračování příště
|