Zpo-10-wyk-Slajd38: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 1: Linia 1:
==State/Strategy: struktura==
==Replace Nested Conditionals with Guard Clauses==


[[Image:zpo-10-wyk-Slajd38.PNG|State/Strategy: struktura]]
[[Image:zpo-10-wyk-Slajd38.PNG|Replace Nested Conditionals with Guard Clauses]]




W przypadku wzorca State centralnym obiektem jest Context. Jego metody wywoływane przez klientów delegują żądania do skojarzonego z nim relacją kompozycji obiektu typu State, reprezentującego jego stan. Metody obiektu State są polimorficzne, czyli wraz ze zmianą tego obiektu zmienia się też ich funkcjonalność. W ten sposób, gdy zachodzi zmiana skojarzonego z obiektem Context obiektu State, zmieniają się też zachowanie metod kontekstu. Pozornie zatem obiekt Context zmienia klasę, do której należy.
Zagnieżdżone wyrażenia warunkowe w znacznym stopniu komplikują strukturę kodu oraz zmniejszają jego czytelność. Szczególnie przyczynia się do tego strukturalny sposób zapisu, w którym metoda może posiadać tylko jeden punkt wyjścia. Konieczne jest wówczas stosowanie złożonych warunków, które weryfikują poprawność poszczególnych ścieżek sterowania.


Wzorzec Strategy stosuje podobne rozwiązanie, tylko na nieco większą skalę. Obiekt Context realizuje pewien algorytm, którego poszczególne kroki mogą zmieniać się w zależności od wyboru konkretnego algorytmu. Z obiektem tym skojarzony jest (także za pomocą kompozycji) obiekt algorytmu, którego metody implementują zmieniające się kroki. Zmiana obiektu algorytmu powoduje zmianę zachowania obiektu Context.
Celem tego przekształcenia jest przesunięcie warunków związanych z błędnymi ścieżkami na początek metody, tak aby można było je odciąć na początku jej wykonywania.


W obu przypadkach najważniejszą zaletą jest możliwość zmiany skojarzonego obiektu (stanu lub algorytmu) w trakcie działania programu, bez potrzeby jego rekompilacji.
Przekształcenie w zasadzie składa się z jednego kroku: przesunięcia wyrażeń warunkowych weryfikujących np. poprawność parametrów na początek metody, i w przypadku stwierdzenia błędu spowodowania opuszczenia metody (instrukcja ''return'' ) lub bieżącego fragmentu kodu (instrukcje ''break'' lub ''continue'' ).
 
Należy jednak pamiętać, że przekształcenie dotyczy jedynie takich warunków, których spełnienie faktycznie odcina dalsze przetwarzanie, tzn. wartości zmiennych ustalone w tym kroku nie ulegają zmianie do końca metody.




[[zpo-10-wyk-Slajd37 | << Poprzedni slajd]] | [[zpo-10-wyk-toc|Spis treści ]] | [[zpo-10-wyk-Slajd39 | Następny slajd >>]]
[[zpo-10-wyk-Slajd37 | << Poprzedni slajd]] | [[zpo-10-wyk-toc|Spis treści ]] | [[zpo-10-wyk-Slajd39 | Następny slajd >>]]

Aktualna wersja na dzień 17:53, 4 lis 2006

Replace Nested Conditionals with Guard Clauses

Replace Nested Conditionals with Guard Clauses


Zagnieżdżone wyrażenia warunkowe w znacznym stopniu komplikują strukturę kodu oraz zmniejszają jego czytelność. Szczególnie przyczynia się do tego strukturalny sposób zapisu, w którym metoda może posiadać tylko jeden punkt wyjścia. Konieczne jest wówczas stosowanie złożonych warunków, które weryfikują poprawność poszczególnych ścieżek sterowania.

Celem tego przekształcenia jest przesunięcie warunków związanych z błędnymi ścieżkami na początek metody, tak aby można było je odciąć na początku jej wykonywania.

Przekształcenie w zasadzie składa się z jednego kroku: przesunięcia wyrażeń warunkowych weryfikujących np. poprawność parametrów na początek metody, i w przypadku stwierdzenia błędu spowodowania opuszczenia metody (instrukcja return ) lub bieżącego fragmentu kodu (instrukcje break lub continue ).

Należy jednak pamiętać, że przekształcenie dotyczy jedynie takich warunków, których spełnienie faktycznie odcina dalsze przetwarzanie, tzn. wartości zmiennych ustalone w tym kroku nie ulegają zmianie do końca metody.


<< Poprzedni slajd | Spis treści | Następny slajd >>