[ Pobierz całość w formacie PDF ]
posiadające określoną hierarchię łańcuchy wywołań. Metody niższego poziomu wywoływane
są przez metody wyższego poziomu, które to z kolei są używane przez jeszcze inną warstwę
aplikacji itd. Struktura ta pozwala łączyć pojedyncze, w miarę proste operacje w czynności
bardziej złożone, co ostatecznie doprowadzi nas do kompletnych procesów biznesowych
i przypadków użycia, stanowiących podstawowe zadania aplikacji4.
%7ładna z przedstawionych dotychczas zasad nie dotyczy jednak bezpośrednio zagadnienia
obsługi wyjątków. Jaki jest związek tego tematu z dziedziną projektowania aplikacji?
3
Próba zdefiniowania pożądanych cech, które spełniać powinien dobrze zaprojektowany system
obiektowy spowodowała powstanie zbioru zasad. W rezultacie temat ten jest wyczerpująco opisany,
a duża część tej dokumentacji znajduje się w sieci. Polecam następujące adresy: http://c2.com./cgi/
wiki?PrinciplesOfObjectOrientedDesign (Wiki Web) oraz http://ootips.org/ood-principles.html
(OOTips).
4
W programowaniu strukturalnym proces dzielenia złożonej funkcjonalności na mniejsze operacje
nazywany jest dekompozycją funkcjonalną. Podobnie jest w programowaniu obiektowym, ale tutaj
odpowiedzialność za poszczególne operacje przypisywana jest klasom, co prowadzi do powstania
modułów bardziej elastycznych i gotowych do ponownego użycia.
100 Część II Plan0wanie 0bsługi wyjątków
W realnych warunkach są z tym niemałe problemy. Wiele zespołów programistycznych (a tak-
że, niestety, metodyk przez nie stosowanych) do obsługi błędów podchodzi w sposób nie dość
poważny. O konieczności obsługi błędów myślimy dopiero w momencie, gdy zaczynają nam
one rzeczywiście przeszkadzać, a dzieje się tak podczas końcowych etapów realizacji przedsię-
wzięcia. Struktura systemu jest już wtedy ustabilizowana i niełatwo wprowadzić do niej zmiany
lub rozszerzenia. Większość członków zespołu odczuwa w tym okresie niemałe zmęczenie,
które potęgowane jest przez wyjątkowo szybko mnożące się problemy związane z pojawiają-
cymi się w wielu miejscach aplikacji błędami. Jak w takiej sytuacji należy się zachować? Mogę
zaproponować trzy możliwe rozwiązania polegające na próbie dołączenia obsługi błędów
do aplikacji w końcowej fazie jej powstawania:
1. Przechwytywanie i lokalna obsługa wyjątków w tych metodach, w których się one
pojawią. Rozwiązanie to nie wpływa na istniejącą już, dotychczasową strukturę
aplikacji. Często jednak pociąga za sobą pewien nieład, brak konsekwencji
i kojarzy się z cichą obsługą wyjątków, którą porównałem do zamiatania śmieci
pod dywan. Inne części aplikacji nie zostaną przez to poinformowane o poważnych
zagrożeniach, których zasięg nie musi mieć zawsze jedynie lokalnego charakteru.
2. Zmiana projektu dokonana w ograniczonym zakresie, uwzględniająca modyfikacje
konieczne do tego, by zarządzanie problemami przenieść na poziom komponentu.
To rodzaj kompromisu, który zwykle nie burzy nam dotychczasowej, ogólnej
struktury aplikacji. Podejście to jednak ma dwie wady. Po pierwsze, istnieje
niebezpieczeństwo, że zbyt wiele modyfikacji na poziomie komponentu może odbić
się niekorzystnie na jego jakości. Po drugie, ciągle istnieje ryzyko, że wyjątki
obsługiwane na poziomie pojedynczego komponentu nie poinformują o ważnym
zdarzeniu pozostałych elementów całej aplikacji.
3. Reorganizacja całej aplikacji. Decyzja taka pociąga za sobą tak wiele koniecznych
zmian, że tak naprawdę cofamy się do jednego z pierwszych etapów powstawania
aplikacji. Co więcej, istnieje ryzyko, że nigdy fazy tej nie ukończymy, jeśli zmiana
projektu uwzględniać ma pojawiające się na bieżąco błędy.
Nietrudno dojść do wniosku, że żaden z przedstawionych powyżej wariantów nie jest zachę-
cający. Fakt ten stanowi najlepszy dowód na to, że zagadnień związanych z obsługą błędów
[ Pobierz całość w formacie PDF ]