8331764261

Uogólnienie

W perspektywie IP najczęstszą interpretacją uogólnienia jest dziedziczenie — Klient instytucjonalny jest klasą pochodną klasy Klient. W najważniejszych językach obiektowych klasa pochodna dziedziczy wszystkie własności klasy podstawowej i może przedefiniować dowolną metodę tej klasy.

Inną techniką realizacji uogólnienia jest np. wykorzystanie interfejsów, które pozwalają utworzyć relację uogólnienia/uszczególowienia pomiędzy typami (dziedziczenie interfejsu) lub klasą i interfejsem (implementacja interfejsu).

19

Uogólnienie jest przedmiotem różnych interpretacji na różnych poziomach modelowania. W modelu pojęciowym można powiedzieć, że Klient instytucjonalny jest typem pochodnym Klienta, jeżeli wszystkie instancje Klienta instytucjonalnego są z definicji, również instancjami Klienta. Klient instytucjonalny jest wówczas specyficznym typem Klienta. Jest ważne, że wszystko, co możemy powiedzieć o Kliencie — asocjacje, atrybuty, operacje — jest również prawdziwe w stosunku do Klienta instytucjonalnego.

Jeszcze inny sposób myślenia jest oparty na zasadzie podstawiania. Powinna być możliwa zamiana klienta na klienta instytucjonalnego w każdym fragmencie kodu, który wymaga klienta, i wszystko powinno dalej działać bez problemu. W istocie znaczy to tylko tyle, że jeśli koduje się dla klienta, to można potem dowolnie stosować jakikolwiek jego typ pochodny, klient instytucjonalny może reagować na niektóre polecenia inaczej niż inny klient (w wyniku zastosowania polimorfizmu), ale obiekt wywołujący nie powinien się kłopotać tą różnicą. Chociaż dziedziczenie jest mechanizmem o bardzo dużych możliwościach, to dodaje ono dużo dodatkowego obciążenia, które nie zawsze jest konieczne do uzyskania podstawiania. Dobrym przykładem jest sytuacja, która miała miejsce na początku istnienia Javy, kiedy to wielu użytkownikom nie podobała się implementacja wbudowanej klasy Vector i oczekiwali, że zostanie ona zastąpiona czymś nieco mniej skomplikowanym. Jedynym sposobem, na który mogli utworzyć klasę zastępczą dla wektora było utworzenie klasy pochodnej, a to oznaczało dziedziczenie wielu niechcianych danych i metod.

Do uzyskania klasy zastępczej można użyć innych mechanizmów, które nie pociągają za sobą dużego obciążenia (Więcej informacji w [5], patrz wykład 1, slajd 4). Wiele osób lubi stosować rozróżnienie między tworzeniem podtypu, czyli dziedziczeniem interfejsu, a tworzeniem podklasy, czyli dziedziczeniem implementacji. Klasa jest podtypem, jeśli może zastąpić swój typ nadrzędny, niezależnie od tego, czy stosuje dziedziczenie, czy nie. Tworzenie podklasy jest synonimem zwykłego dziedziczenia.

19