ZSBD-2st-1.2-lab9.tresc-1.3-Slajd8

From Studia Informatyczne

Typy i metody abstrakcyjne

Typy i metody abstrakcyjne


W przykładzie przedstawionym na poprzednich slajdach, metoda POLE w typie FIGURA posiada bezużyteczną implementację. Ponieważ nie było wiadomo jak policzyć pole figury, której kształt jest nie znany, zaimplementowano tą metodę tak, aby zawsze zwracała zero. Z drugiej strony i tak wiadomo, że z metody tej nie będziemy korzystać, bo metoda, która nic nie liczy nie jest w żaden sposób przydatna. Można zatem w ogóle zrezygnować z implementacji tej metody i pozostawić jedynie jej deklarację w typie FIGURA. Metody, których deklaracja stanowi jedynie zapowiedź, że w którymś z podtypów pojawi się ich implementacja, nazywa się metodami abstrakcyjnymi. Typy obiektowe, w których zadeklarowano metody abstrakcyjne, nazywa się typami abstrakcyjnymi. Typy abstrakcyjne z oczywistych względów nie mogą posiadać instancji, a zatem nie jest możliwe tworzenie obiektów typów abstrakcyjnych. Polecenie (1) tworzy abstrakcyjny typ FIGURA, z abstrakcyjną metodą POLE. Zacznijmy od analizy deklaracji metody. Słowo kluczowe MEMBER rozpoczynające poprzednio deklarację metody poprzedzono słowami kluczowymi NOT INSTANTIABLE, które oznaczają, że metoda ta nie będzie implementowana. Podobną funkcjonalność ma np. słowo kluczowe abstract w języku JAVA. Ponieważ typ FIGURA zawiera abstrakcyjną metodę, to musi być zdefiniowany jako typ abstrakcyjny. Jest to wykonywane poprzez umieszczenie słów kluczowych NOT INSTANTIABLE na końcu polecenia tworzącego typ. Przesłanianie metod abstrakcyjnych odbywa się w taki sam sposób jak zwykłych metod posiadających implementację. W związku z tym, polecenia (2) i (3) z poprzednich dwóch slajdów tworzące typy KWADRAT i KOLO, oraz polecenia tworzące ciała tych typów są poprawne również, jeżeli typ FIGURA jest utworzony za pomocą polecenia pokazanego na tym slajdzie.

Warto tutaj wspomnieć jeszcze o jednej rzeczy. Otóż teoretycznie możliwe jest zadeklarowanie typu, który byłby abstrakcyjny (NOT INSTANTIABLE) i równocześnie nie byłoby możliwe tworzenie jego podtypów (FINAL). Typy takie nie posiadają jednak żadnego praktycznego znaczenia i próba utworzenia takiego typu kończy się błędem.


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