Wzorce w tworzeniu aplikacji



Pobieranie 144,79 Kb.
Strona1/2
Data23.10.2017
Rozmiar144,79 Kb.
  1   2

Adam Lejman, Altkom Akademia, Warszawa 2001

Wzorce w tworzeniu aplikacji


Tworzenie systemów informatycznych wyróżniających się poprawną architekturą wewnętrzną wymaga od wykonawców dużego doświadczenia, które można nabyć uczestnicząc w projektach. Budowa każdego kolejnego rozwiązania opiera się na dobrych pomysłach i praktykach wykorzystanych poprzednio. Unika się konstrukcji, które okazywały się w poprzednich projektach niezręczne, mało wydajne lub trudne w rozwijaniu.

Cóż jednak mają zrobić ci, którzy tego doświadczenia mają mało i nie chcą popełniać podstawowych błędów? Od jakiegoś czasu w dziedzinie budowania systemów informatycznych można zauważyć swoistą wręcz modę na stosowanie i publikowanie wzorców (patterns), dobrych praktyk i konstrukcji obiektowych. Również ostatnio pojawiają się publikację najczęściej popełnianych błędów, czyli antywzorce (antipatterns). Dzięki temu znacznie łatwiej jest rozpoznać i zaradzić niefortunnych konstrukcjom.

Popularność stosowania wzorców zaczęła się od kultowej pozycji Gangu Czterech (Gang of Four) [1]. Autorzy wyłuskali i skatalogowali najczęściej pojawiające się konstrukcje obiektowe w różnego rodzaju aplikacjach, uogólnili je i przedstawili jako gotowe pomysły do wykorzystania w realizacji systemów obiektowych. Od tego czasu o wzorcach zaczęto mówić coraz powszechniej, zaczęto tworzyć strony internetowe przedstawiające kolejne odkrywane wzorce [2]. Projektanci zauważyli, że korzystanie z wzorców rzeczywiście znacznie ułatwia budowanie nowych rozwiązań, polepsza wymianę pomysłów w zespole projektowym, podczas której wystarczy posługiwać się nazwami wzorców zamiast przekazywać swoje myśli w sposób graficzny.

Istota modelowania podczas tworzenia aplikacji


Nie ulega wątpliwości, że budowanie aplikacji powinno być poprzedzone etapem analizy i projektowania obiektowego. O ile analizę można porównać do śledztwa, w którym zbierane są materiały dowodowe, czyli jak aplikacja ma się zachowywać i wyglądać, to kolejny etap – projektowanie, jest budowaniem rozwiązania dostosowanego do wyników analizy. Po zakończeniu projektowania, z gotowym modelem obiektowym, pozostaje wypełnienie wszystkiego kodem i przetestowanie.

Oczywiście, w rzeczywistości kolejne etapy budowania aplikacji nie są tak kategorycznie odseparowane. Nie dość, że zachodzą na siebie, to normalną sprawą są nawroty do poprzednich kroków, głównie ze względu na zmieniające się wymagania użytkownika lub przeoczenia na wcześniejszym etapie.

Utrzymywanie przejrzystego i aktualnego modelu aplikacji jest, zatem sprawą niezwykle ułatwiającą budowanie nietrywialnych aplikacji. Stosowanie wzorców zwiększa szansę uniknięcia błędów projektowych, które wcześniej czy później zostałyby dostrzeżone. Często jednak zbyt późno, kiedy trud ich usunięcia jest zbyt duży.

Wzorce w analizie


Wzorce stosowane są już na etapie analizy. Tutaj zazwyczaj poza zebraniem i wyartykułowaniem w sposób formalny wymagań użytkownika powstaje też model obiektowy problemu obrazujący logikę systemu.

Model analityczny abstrahuje od języka programowania i wszelakich aspektów technicznych. Taki model przedstawia relacje pomiędzy obiektami, spotykanymi w modelowanej dziedzinie. Często mówi się o takich obiektach – obiekty biznesowe.

Wzorce wykorzystywane na tym etapie są zazwyczaj przypisane do konkretnych sytuacji biznesowych i ich zakres zastosowań jest może nieco mniejszy niż przy wzorcach z etapu projektowania. Ale i tutaj można doszukać się kilku znanych, uniwersalnych konstrukcji.

Najbardziej klasycznym przykładem wzorca analitycznego jest, być może zbyt szumnie nazwany jako wzorzec, bo dotyczy tylko jednej klasy, wzorzec modelowania wartości z jednostkami [3].

Krótkowzrocznym podejściem jest przedstawianie takich wartości jako danych liczbowych, do których panuje umowa, co do jednostek. I tak na przykład budując dane o sportowcach, przechowuje się ich wagę w kilogramach. Jest to tak oczywiste, że nie zadajemy sobie trudu zapisania jednostek w modelu analitycznym.

W przyszłości system może zostać wystawiony w internecie i użytkownik systemu zza oceanu w sposób naturalny posługuje się wartościami wagi wyrażonymi w funtach. I powstaje problem. Należy zacząć uwzględniać nowe jednostki, dokonywać przeliczeń, co czasem może się wiązać z utratą precyzji. O ile prościej byłoby gdyby nasz model analityczny był uniezależniony od jednostek.



Z pomocą przychodzi wzorzec zwany Quantity. W tym wzorcu wszelakie dane liczbowe przechowywane są jako obiekt, który przechowuje osobno wielkość i jednostkę. Taki obiekt może mieć zaszyte algorytmy konwersji jednej jednostki na drugą (o ile taka konwersja ma sens) i jej algorytm jest znany programiście.

Wzorzec Quantity możemy zastosować do liczenia pieniędzy w różnych walutach, przetwarzania wartości fizycznych, w każdej sytuacji gdzie z wartością skojarzona jest jednostka, w jakiej ta wartość została wyrażona.



Jako przykład można zbudować w oparciu o omawiany wzorzec klasy reprezentujące pieniądze, klasę bazową Money i dwie przykładowe klasy specjalizowane Dollar i Pound.

Metoda add() pozwala dokonywać operacji dodawania obiektów typu Money. W czasie implementacji konkretnych klas należy zdefiniować jak taką konwersję należy przeprowadzić. Czasem okazuję się, że zamiast natychmiastowego przeliczania wartości lepiej jest budować historię tego, co ma być wykonane i dopiero w momencie skorzystania z aktualnej wartości, jaką obiekt przechowuje, operacja dodawania wartości powinna być przeprowadzona.

Na przykład przy opracowywaniu cennika produktów importowanych na rynek krajowy można przyjąć, że cena pudełka zapałek składa się z sumy cen samych zapałek wyrażonej w dolarach 0.05 oraz ceny samego pudełka wyrażonej w funtach 0.02. Cena w złotówkach jest oczywiście zależna od kursu obu walut i powinna w sobie kryć zapis w postaci sumy cen jednostkowych, która jest zamieniana na złotówki wówczas, gdy istnieje potrzeba poznania dzisiejszej ceny pudełka zapałek.

Można zarzucić, że wzorzec jest trywialny. To prawda, ale uświadomienie sobie konsekwencji jego niezastosowania jest chyba bardziej istotne od samego wzorca. Wzorce to dobre praktyki zaczerpnięte z wielu projektów tak, więc dla doświadczonych projektantów są rzeczą oczywistą.




  1   2


©operacji.org 2017
wyślij wiadomość

    Strona główna