[ Pobierz całość w formacie PDF ]
.Czasami nazywa się Rozdział 5." TW�J PIERWSZY PROGRAM OBIEKTOWY W C# 171to zależnością całość / część.Zaimplementowaliśmy ten związek w listingu 5.1 przezzadeklarowanie zmiennej instancji typu Elevator wewnątrz klasy Building(wiersz 51.):51: private static Elevator elevatorA;Dzięki temu Building może zawierać obiekt Elevator i wywoływać jego metodypublic.Klasa może mieć wiele różnych zmiennych instancji zawierających wieleobiektów różnych klas.Moglibyśmy np.również wyposażyć Building w zmienneinstancji reprezentujące liczbę obiektów Floor.Ta idea konstruowania klasy (Bu-ilding) za pomocą innych klas (Elevator lub Floor albo obu i wielu innych)nazywa się ogólnie agregacją, a towarzyszące jej zależności to związki agregacyjne.Jeżeli związek agregacyjny (jak w przypadku związku Building-Elevator) odzwier-ciedla sytuację, gdzie jedna klasa jest integralną częścią innej, możemy nazwać tęagregację kompozycją.(Zaraz zobaczymy, dlaczego związek Elevator-Person jestagregacją, ale nie jest kompozycją.) Związek kompozycyjny można zilustrować zapomocą schematu klasy zunifikowanego języka modelowania (Unified ModelingLanguage UML), pokazanego na rysunku 5.3.Dwie prostokątne ramki symbolizująklasy, a łącząca je linia z czarnym rombem (wskazującym na całą klasę) ilustruje zwią-zek kompozycyjny między klasami.Obie klasy są oznaczone liczbą 1, aby wskazać,że jeden Building (budynek) ma jedną Elevator (windę).RYSUNEK 5.3.Diagram UMLsymbolizującykompozycjęZunifikowany język modelowania (UML) Lingua Franca modelowania obiektowegoPseudokod jest przydatną pomocą w wyrażaniu algorytmów, które są imple-mentowane w pojedynczych metodach, ponieważ czyta się je od góry do dołu,tak jak środowisko uruchomieniowe wykonuje program i dlatego, że abstrahujeon od sztywnego rygoru języka komputerowego (średniki, nawiasy itd.).Jednakklasy mogą składać się z wielu metod, a większe programy składają się z wieluklas.Pseudokod nie jest odpowiednim narzędziem do ilustrowania modeli po-wiązań klas programu, ponieważ klasy zrywają z sekwencyjnym, proceduralnymsposobem myślenia (każda klasa może potencjalnie mieć związek z inną klasązdefiniowaną w programie) i dlatego, że format pseudokodu jest zbyt szczegółowy,aby zapewnić przegląd dużego programu obiektowego. 172 JZYK C#.SZKOAA PROGRAMOWANIAAby skutecznie zaprezentować związki klas i całą architekturę programu obiek-towego, potrzebujemy języka, który umożliwia abstrahowanie od wewnętrznychszczegółów metod, a zamiast tego zapewnia środki do wyrażania związków klasi pojęć obiektowych na odpowiednim poziomie szczegółowości.W tym celu więk-szość programistów obiektowych, bez względu na swój język programowania, stosujeobecnie język przedstawiania graficznego o nazwie zunifikowany język modelowania(Unified Modeling Language UML).UML to język o wielu cechach i potrzebnajest cała książka, aby go wystarczająco zaprezentować; tu przedstawiono tylkomały podzestaw UML.Szczegółowe informacje o UML można uzyskać w niedochodowej organizacji ObjectManagement Group (OMG) (www.omg.org) na stronie www.omg.org/uml.Napisanowiele dobrych książek o UML, m.in.The Unified Modeling Language User Guide,którą napisali twórcy UML, Grady Booch, James Rumbaugh i Ivar Jacobson.Związek Elevator-PersonPrzycisk jest integralną częścią windy, ale pasażer już nie.(Winda jest czynna bezpasażera, ale nie bez przycisków).Więc gdybyśmy nawet w naszej implementacji(z powodów abstrakcyjnych) uczynili pasażera permanentną częścią Elevator(obiekt Person pozostaje wewnątrz Elevator przez całą symulację), nie jest tozwiązek kompozycyjny, a jedynie agregacja.Związek ten ilustruje UML na rysun-ku 5.4.Proszę zwrócić uwagę, że biały romb, w przeciwieństwie do czarnego rombuna rysunku 5.3, symbolizuje agregację.RYSUNEK 5.4.Diagram UMLsymbolizującyagregacjęCały schemat klasy UML dla programu z listingu 5.1 został pokazany na rysunku 5.5.UML umożliwia, tak jak to pokazano, podzielenie prostokąta reprezentującego klasęna trzy przedziały górny przedział zawiera nazwę klasy, w środkowym mieszcząsię zmienne instancji (lub atrybuty), a w dolnym metody (zachowanie) należącedo klasy.AsocjacjeStałe związki między klasami, takie jak związki agregacyjne i kompozycyjne, omó-wione w poprzednich rozdziałach, są ogólnie nazywane związkami strukturalnymi lub,bardziej oficjalnie, asocjacjami.Istnieją jednak inne typy asocjacji, które nie są agre-gacjami (a więc nie są również kompozycjami).Aby dać przykład takiej asocjacji,rozważmy następujący scenariusz.Chcemy uczynić naszą symulację windy bardziejrealistyczną, zatem zmieniamy pokazaną wcześniej początkową listę abstrakcji, Rozdział 5." TW�J PIERWSZY PROGRAM OBIEKTOWY W C# 173RYSUNEK 5.5.Diagram UML klasz listingu 5.1umożliwiając wielu obiektom Person wchodzenie, podróżowanie i wychodzeniez obiektu Elevator, zamiast tylko jednego obiektu Person pozostającego na stałew windzie.Teraz już o żadnym obiekcie Person nie można powiedzieć, że jest stałączęścią obiektu Elevator.Możemy po prostu powiedzieć, że klasa Elevator jestskojarzona z klasą Person.Asocjacja jest pokazana za pomocą zwykłej linii, tak jakna rysunku 5.6.RYSUNEK 5.6.Asocjacja klasElevator/PersonInne przykłady asocjacji, które nie są agregacjami:�% Pracownik pracuje w Firmie,�% KlientBanku współpracuje z KasjeremBanku. 174 JZYK C#.SZKOAA PROGRAMOWANIAUwaga!Asocjacje, które precyzyjnie łączą dwie klasy, nazywają się asocjacjami binar-nymi; jest to najpopularniejszy rodzaj asocjacji.PodsumowanieTen rozdział składa się z dwóch głównych części.Pierwsza dotyczy leksykalnejstruktury programu zródłowego C#
[ Pobierz całość w formacie PDF ]
