Pakiet programów do zdalnego nauczania Programowania Orientowanego Obiektowo
Dzisiaj jest
Środa, 18 Lipiec 2018
Zarejestrowanych użytkowników: 4
Dostępnych pytań testowych: 102
HOME
Strona tytułowa pracy dyplomowej
NAUKA
Materiały dydaktyczne związane z OOP
TESTY
Sprawdzenie poziomu zdobytej wiedzy
ZASOBY
Literatura i zasoby sieciowe o OOP
ŹRÓDŁA
Zbiór projektów dydaktycznych z OOP
KONTO
Możliwość śledzenia własnych postępów
INFO



Odpowiedzialność za zmianę stanu

W przypadku implementacji rozwiązania za pomocą wzorca projektowego Stan należy zdecydować kto odpowiada za zmianę obiektów stanów.

W poprzednim przykładzie klasą odpowiedzialną za zmianę stanów była klasy stanów konkretnych. Zalety takiego rozwiązania to przede wszystkim: znaczące uproszczenie klasy kontekstu, spójność kodu dla każdego stanu (działania i zmiany stanów są umieszczone wewnątrz implementacji klasy StanKonkretny) oraz łatwość modyfikacji. Podstawową wadą jest natomiast większa zależność między klasami stanów, które muszą znać się nawzajem (StanKonkretny musi znać definicję innej klasy StanKonkretny przy zmianie stanu). Z uwagi na to ponownie wykorzystanie kodu tak napisanych systemów może być utrudnione. Drugą wadą jest konieczność deklaracji przyjaźni w klasie kontekstu (Silnik) do klasy stanu. Jest to wymagane, ponieważ obiekty stanów zmieniając stan bieżący kontekstu muszą odwoływać się do jego składników lub metod niepublicznych.

Zmiana stanów może być również przeprowadzana przez klasę kontekstu. Taka decyzja ma silne konsekwencje. Klasy stanów odpowiadają wyłącznie za działanie – mogą być one więc bardzo uproszczone. Gdyby takie rozwiązanie przyjęto w przedstawionym przykładzie udało by się nawet – w związku z podobieństwem obiektów stanów – zredukować liczbę klas stanów do jednej. Po drugie klasy stanów (w przypadku, gdyby było ich więcej) nie są od siebie zależne, co sprawia że mogą być z łatwością przygotowane do ponownego użycia. Wadą takiego rozwiązania jest w dalszym ciągu mała spójność kodu – fragmenty odpowiedzialne za zmianę stanu są umiejscowione wewnątrz klasy kontekstu, natomiast implementacja sposobu reakcji na żądania metod - wewnątrz klas stanów. Sprawia to trudności w ewentualnej modyfikacji projektu, jednak jest zalecane w przypadku gdy możliwy zbiór obiektów stanów jest znany i prawdopodobieństwo modyfikacji takiego systemu jest znikome. Kolejną, drobną wadą jest zwykle konieczność przechowywania wszystkich stanów w klasie kontekstu. Jak zostało wspomniane wcześniej – służy to łatwemu rozpoznawaniu bieżącego stanu.

Adamik Łukasz, Politechnika Śląska w Gliwicach (AEiI) - 2010/11