8331764256

Implementacja atrybutów (4)

Jeśli atrybut jest wielowartościowy, to dane przez niego reprezentowane są kolekcją. A zatem klasa Zamówienie (patrz slajd 8) byłaby kolekcją obiektów Pozycja zamówienia. Ponieważ krotność ta jest uporządkowana, to i kolekcja Zamówienie musi być zbiorem uporządkowanym. Wielowartościowe cechy wymagają innego typu interfejsu niż cechy jednowartościowe (np. w Javie): class Zamówienie {

privatc Zbiór pozycjeZamowienia = new ZbiorUporzadkowanyO; public Zbiór pobierzPozycjeZamowienia() {

return Kolekcje.ZbiorNiemodyfikowalny(pozycjeZamowienia); } public void dodaj PozycjeZamowienia (PozycjaZamowienia arg) { pozycjeZamowienia.dodaj (arg);} public void usunPozycjeZamowienia (PozycjaZamowienia arg) { pozycjeZamowienia.usun(arg);}

Projektowanie systemów informatycznych, wykład 2    14

W większości wypadków cechom wielowartościowym nie nadaje się wartości za pomocą operatora przypisania, lecz używa się w tym celu metod dodających i usuwających wartości. Kontrola nad cechą pozycjeZamowienia wymaga, aby w zamówieniu można było sprawdzić przynależność do tej kolekcji. W efekcie nie powinno być możliwe uzyskiwanie bezpośredniego dostępu do samej kolekcji. W tym wypadku użyto zabezpieczenia tej kolekcji w postaci zewnętrznego interfejsu tylko do odczytu. Można też utworzyć nie aktualizowany iterator lub utworzyć kopię. Można zezwolić klientom na modyfikowanie obiektów składowych, ale nie powinni oni móc bezpośrednio zmieniać samej kolekcji.

Jeśli w kolekcji nie ma ustalonego porządku, to aby zachować ścisłość, nie powinna ona mieć znaczącej kolejności i powinna być zaimplementowana jako zwykły zbiór. Jednak zwykle implementuje się nieuporządkowane atrybuty jako listy. Jeżeli potrafimy określić liczbę elementów kolekcji wtedy warto użyć tablicy o stałym rozmiarze (zwykle działają szybciej niż struktury danych o zmiennym rozmiarze).

Ponieważ wielowartościowe atrybuty implikują stosowanie kolekcji, zwykle nie umieszcza się klas kolekcji na diagramie klas. Przedstawia się je jedynie na diagramach implementacji bardzo niskiego poziomu.

Przykłady te uwydatniają fakt, że nie ma jednoznacznej zależności między UML-em a kodem, chociaż istnieje pewne podobieństwo. Jednak konwencje przyjęte przez zespół projektantów pomogą zbliżyć się do uzyskania takiej zależności.

Niezależnie od tego, czy cecha jest zaimplementowana jako pole, czy jako wartość obliczana, reprezentuje ona coś, co obiekt może zawsze podać. Nie należy używać cechy do modelowania przechodniej relacji, takiej jak przekazanie obiektu jako parametr podczas wykonania metody, używanego tylko w obrębie tej interakcji.

14