3 Obiekt a klasa 3.1 Wstęp Wykład zawiera wprowadzenie do obiektowego modelu danych poprzez omówienie jego dwóch podstawowych pojęć: obiekt i klasa. Zrozumienie tych pojęć oraz związku pomiędzy nimi jest pierwszym krokiem na drodze do zrozumienia i prawidłowego zastosowania podejścia obiektowego. W wykładzie zostaną omówione takŝe inne waŝne elementy obiektowości powiązane z obiektami i klasami, np. atrybut, metoda, hermetyzacja, komunikat, polimorfizm itd. 3.2 Obiekt Obiekt jest to struktura danych stanowiąca w implementacji komputerowej odwzorowanie bytu, który posiada dobrze określone granice i własności, wyróŝnialnego w analizowanym fragmencie dziedziny problemowej. Z koncepcją obiektu ściśle związane są następujące pojęcia: ToŜsamość obiektu, która odróŝnia go od innych obiektów i jest niezaleŝna od wartości jego atrybutów (patrz podrozdział 3.2.8), powiązań z innymi obiektami (patrz podrozdział 3.2.3), od lokalizacji (odwzorowywanego przez obiekt) bytu w świecie rzeczywistym oraz od lokalizacji obiektu w przestrzeni adresowej komputera. Stan obiektu, który jest określony przez aktualne wartości jego atrybutów i powiązań z innymi obiektami. Stan obiektu moŝe zmieniać się w czasie; nie pociąga to jednak za sobą zmiany jego toŝsamości. Zachowanie przypisane do obiektu, tj. zestaw operacji (patrz podrozdział 3.2.9), które moŝna na nim wykonać. Typ przypisany do obiektu, tj. wyraŝenie językowe, które poprzez specyfikację atrybutów określa jego budowę oraz ogranicza kontekst, w którym moŝna odwoływać się do obiektu. Wszystkie atrybuty, powiązania, operacje itd. obiektu nazywane są jego własnościami. Rys. 1 przedstawia obrazowo przykładowy obiekt pracownik, który odwzorowuje pewnego pracownika z dziedziny problemowej. Obiekt ten posiada atrybuty, m.in. imię i nazwisko; na obiekcie moŝna wykonać operacje, m.in. zmień pensję i oblicz staŝ. dismiss calculate employee experience employee Id. = 5789 name = Jerzy = Maltański empl. date = 1.02.02 position = księgowy salary = 3500 change salary change position Rys. 1. Przykładowy obiekt pracownik 3.2.1 ToŜsamość obiektu a jego identyfikator Byt, odwzorowywany w obiekt w implementacji komputerowej, jest wyróŝnialny w dziedzinie problemowej przez sam fakt swojego istnienia, a nie poprzez jakąkolwiek fizyczną cechę, która odróŝniałaby go od innych bytów. MoŜe się zdarzyć, Ŝe pewne byty są nieodróŝnialne (na przykład mrówki), niemniej jednak obserwator jest świadomy faktu, Ŝe postrzega róŝne byty (róŝne mrówki). W podejściu obiektowym powyŝsza własność określana jest wprowadzonym uprzednio terminem toŝsamości obiektu. ToŜsamość jest zazwyczaj implementowana jako wewnętrzny unikalny i niewidoczny dla uŝytkownika identyfikator
obiektu, który jest automatycznie generowany przez system w momencie powołania obiektu do Ŝycia. Mechanizm identyfikatorów pozwala m.in. na rozróŝnianie obiektów i tworzenie powiązań między nimi. Identyfikator jest traktowany jak wewnętrzny atrybut obiektu, który nie ma Ŝadnego znaczenia w dziedzinie problemowej i do którego uŝytkownik nigdy nie odwołuje się w sposób jawny. 3.2.2 Relatywizm obiektów Obiekt, stanowiący odwzorowanie pewnego bytu ze świata rzeczywistego, powinien przechowywać wszelkie informacje, które odnoszą się do tego bytu. Obiekt przenosi te informacje między innymi poprzez mechanizm atrybutów. Atrybuty obiektu same mogą być obiektami, zwanymi w takiej sytuacji podobiektami; obiekt zawierający atrybuty-podobiekty nazywany jest obiektem złoŝonym. Przyjmuje się, Ŝe nie naleŝy ograniczać ani liczby/rozmiaru atrybutów opisujących obiekt, ani liczby poziomów hierarchii podobiektów, co w efekcie powinno skutkować brakiem ograniczeń na rozmiar obiektu. Ustalenie, które informacje odnoszą się do danego obiektu, a które do innego (np. podobiektu), powinno zaleŝeć wyłącznie od modelu pojęciowego tworzonego przez analityka i nie powinno podlegać Ŝadnym ograniczeniom ze strony środowiska implementacji. Rys. 2 pokazuje przykład obiektu złoŝonego studenci. Obiekt ten składa się z atrybutów-podobiektów student, które z kolei same zawierają własne atrybuty-podobiekty itd. students student name passed courses course course student name nr indeksu nr indeksu passed courses index No. course course course Rys. 2. Obiekt złoŝony studenci 3.2.3 Powiązania pomiędzy obiektami Relacja między obiektami, odwzorowująca fizyczny lub pojęciowy związek istniejący między bytami w analizowanej dziedzinie problemowej, nazywana jest powiązaniem. Obiektowość pozwala na tworzenie bezpośrednich powiązań prowadzących od jednego obiektu do innego. Tak jak obiekty stanowią odwzorowanie bytów istniejących w dziedzinie problemowej, powiązania odwzorowują związki występujące między bytami. Na poziomie implementacyjnym powiązanie jest daną będącą identyfikatorem pewnego obiektu. Unika się tu uŝywanych w obiektowych językach programowania pojęć wskaźnik czy referencja na rzecz bardziej abstrakcyjnego terminu powiązanie. Rys. 3 przedstawia przykładowe powiązania między obiektami, m.in. powiązanie o nazwie zatrudnia prowadzące od obiektu firma do obiektu pracownik. Powiązania są poŝytecznym mechanizmem, który z jednej strony ułatwia naturalne odwzorowywanie semantycznych związków istniejących między analizowanymi bytami, zaś z drugiej znacznie zwiększa szybkość działania programu. Do wad powiązań zalicza się przede wszystkim: usztywnienie struktury danych, moŝliwość utraty spójności ze względu na potencjalne powiązania prowadzące do nieistniejących obiektów oraz moŝliwość naruszenia reguł hermetyzacji, o której jest mowa w następnym punkcie.
employee company name = Relax Ltd. employs employs boss employee = Nowak salary = 1500 works in employee Rys. 3. Przykład powiązań między obiektami firma i pracownik 3.2.4 Hermetyzacja a ukrywanie informacji Pojęcie hermetyzacja (inaczej: enkapsulacja) oznacza zgromadzenie w postaci jednej manipulowalnej bryły zarówno elementów struktury obiektu, jak i operacji, które moŝna na tym obiekcie wykonać. Dwa podstawowe rodzaje hermetyzacji: hermetyzacja ortodoksyjna: i hermetyzacja ortogonalna, są przedstawione w Tab. 1. Hermetyzacja ortodoksyjna (np. Smalltalk) Własności: Na zewnątrz obiektu widoczne są wyłącznie te operacje, które moŝna na nim wykonać. Atrybuty obiektu są ukryte. Hermetyzacja ortogonalna (np. C++, Modula 2, Java) Własności: Dowolna własność obiektu (atrybut, operacja itd.) moŝe być prywatna (ukryta) lub publiczna ( udostępniona do publicznego uŝytku). Efekt: Dostęp do atrybutów obiektu wymaga zdefiniowania specjalnych operacji, z których jedna odczytuje wartość atrybutu, a druga ją zmienia. Tab. 1. Hermetyzacja ortodoksyjna a hermetyzacja ortogonalna Efekt: Potrzebne są specjalne środki do specyfikowania własności prywatnych i publicznych. Według innej definicji, hermetyzacja to oddzielenie specyfikacji obiektu od jego implementacji, co pośrednio prowadzi do ukrycia jego struktury i implementacji operacji; tę własność określa się takŝe terminem ukrywanie informacji. Generalnie, hermetyzacja i ukrywanie informacji są pojęciami róŝnymi, choć mocno powiązanymi. Hermetyzacja i ukrywanie informacji stanowią podstawę dla wprowadzenia innych pojęć z zakresu modelowania pojęciowego, takich jak: moduł, klasa i abstrakcyjny typ danych. 3.2.5 Klasa Klasa, podobnie jak obiekt, naleŝy do podstawowych pojęć obiektowości. W literaturze poświęconej obiektowości funkcjonuje kilka róŝnych definicji tego pojęcia, z których dwie najbardziej popularne przytaczamy poniŝej: 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach: semantyce, atrybutach, zachowaniu, związkach z innymi obiektami itd. 2. Klasa jest nazwanym opisem grupy obiektów o podobnych własnościach. Zgodnie z tą definicją, klasa nie jest zbiorem obiektów, lecz jest wykorzystywana do deklarowania obiektów. W niniejszym wykładzie będziemy posługiwać się drugą z powyŝszych definicji. NajwaŜniejszymi własnościami klasy, zwanymi inwariantami klas, są:
nazwa, czyli językowy identyfikator klasy obiektu; typ, czyli struktura (budowa) obiektu specyfikowana z wykorzystaniem mechanizmu atrybutów; metody, czyli implementacje operacji, które moŝna wykonać na obiekcie. Do innych rodzajów inwariantów zalicza się m.in.: obsługę zdarzeń i wyjątków, które mogą zachodzić w trakcie wykonywania operacji na obiekcie; listę eksportową, czyli listę własności obiektu, które są dostępne z zewnątrz; ograniczenia, którym moŝe podlegać obiekt klasy. Nazwa klasy Głównym zadaniem nazwy klasy jest opisanie obiektów, które ona grupuje. Bardzo często przyjmuje się, Ŝe nazwa klasy powinna określać pojedynczy obiekt tej klasy, w związku z czym zazwyczaj nazwą klasy jest rzeczownik w liczbie pojedynczej, np. Osoba 1 (a nie Osoby), Rachunek (a nie Rachunki), KsiąŜka (a nie KsiąŜki). JeŜeli jednak obiekt odpowiada grupie bytów, np. grupie osób, to do nazwania klasy powinno się uŝyć rzeczownika w liczbie mnogiej (Osoby) albo specjalnej frazy rzeczownikowej, która jest w liczbie pojedynczej (w tym przypadku np. Grupa osób). NaleŜy zwrócić uwagę na sytuację, gdy dany rzeczownik nie posiada liczby pojedynczej, np. Drzwi, Zawody itd. wówczas nazwa klasy jest rzeczownikiem w liczbie mnogiej. Jak moŝna zaobserwować na przykładzie nazwy Grupa osób, znakiem dozwolonym w nazwie klasy (a takŝe nazwie atrybutu, metody itd.) na etapie analizy jest spacja. Nazwy, których składnia nie jest dozwolona w środowisku implementacji, zostaną odpowiednio zmienione w fazie projektowania, w trakcie wykonywania czynności określanych mianem eliminacji ograniczeń środowiska implementacji. Notacja W języku UML na diagramie klas definicja klasy przedstawiana jest w postaci prostokąta składającego się zazwyczaj z trzech pól: pola nazwy klasy, pola atrybutów, pola metod. Elementy pól, czyli nazwa, atrybuty i metody, posiadają następujące specyfikacje: nazwa klasy: stereotyp dostępność nazwa_ klasy lista_wart_etykiet atrybut: stereotyp dostępność nazwa_atrybutu : typ = wart_początkowa lista_wart_etykiet metoda: stereotyp dostępność nazwa_metody (lista_arg) : typ_wart_zwracanej lista_wart_etykiet gdzie: stereotyp i lista_wart_etykiet oznaczają odpowiednio stereotyp i listę wartości etykietowanych (więcej informacji na ten temat znajduje się w wykładzie omawiającym mechanizmy rozszerzalności); dostępność określa widoczność danego elementu. WyróŜnia się trzy podstawowe rodzaje dostępności, oznaczane w następujący sposób: + : element publiczny jest widoczny z zewnątrz klasy; : element prywatny jest widoczny tylko wewnątrz klasy; # : element chroniony jest widoczny w klasie i jej podklasach (więcej informacji na ten temat znajduje się w wykładzie omawiającym generalizację-specjalizację). lista_arg: definiuje listę parametrów formalnych metody; składnia opisu pojedynczego parametru jest następująca: rodzaj nazwa_arg : typ = wartość_początkowa, gdzie rodzaj określa sposób, w jaki metoda korzysta z danego argumentu: in: metoda moŝe czytać wartość parametru, ale nie moŝe jej zmieniać; out: metoda moŝe zmieniać wartość parametru, ale nie moŝe jej czytać; inout: metoda moŝe zarówno czytać, jak i zmieniać wartość parametru. KaŜdy z elementów specyfikacji klasy, za wyjątkiem nazwy, jest opcjonalny; w szczególności bardzo często na etapie analizy, lub przynajmniej na jej początku, nie określa się dostępności ani typów atrybutów. 1 Nazwy klas, dla odróŝnienia od nazw obiektów, atrybutów itd., będziemy pisać duŝą literą.
Definicję klasy moŝna przedstawić w sposób mniej lub bardziej szczegółowy, co ilustruje Rys. 4. W razie potrzeby definicja klasy moŝe zostać rozszerzona o dodatkowe pole opisujące inne własności klasy. Student Student index No. grades Student index No. grades Student index No.: integer : string grades : string calculate avg () calculate avg (): real Rys. 4. RóŜne poziomy szczegółowości w przedstawianiu definicji klasy Dla zwiększenia czytelności diagramów zaleca się, aby dla nazwy klasy stosować większą czcionkę niŝ dla innych elementów definicji klasy. Ponadto, nazwa klasy powinna być umieszczona pośrodku pola, natomiast pozostałe elementy wyrównane do lewej strony. 3.2.6 Wystąpienie klasy Pojęcie wystąpienie klasy (inaczej: instancja klasy) oznacza obiekt, który jest podłączony do danej klasy, jest jej członkiem. W zaleŝności od wymaganego poziomu szczegółowości moŝliwe są róŝne oznaczenia wystąpienia klasy, patrz Rys. 5. Do obiektu moŝna przypisać nazwę (Rys. 5 (a) i (c)), ale nie jest to konieczne (Rys. 5 (b) i (d)). (a) object name : class name (b) : class name attribute name = attribute value... attribute name = attribute value... (c) object name : class name (d) : class name Rys. 5. Notacja na oznaczenie instancji klasy Zagadnienie wystąpienia klasy jest bardziej złoŝone w sytuacji, gdy klasa uczestniczy w związku generalizacjispecjalizacji. Problem ten jest omówiony w wykładzie poświęconym generalizacji-specjalizacji. 3.2.7 Ekstensja klasy Ekstensja klasy jest to aktualny (zmienny w czasie) zestaw wszystkich wystąpień tej klasy. Ekstensja jest implementowana w postaci specjalnej struktury danych (konkretnego bytu programistycznego dołączonego do klasy), która przechowuje wszystkie obiekty będące członkami klasy. Rys. 6 przedstawia przykładową ekstensję klasy Student. Przerywana linia zakończona grotem oznacza związek zaleŝności pomiędzy elementami modelu w tym przypadku pomiędzy obiektami a ich klasą.
Student name index No. grades age () grades s avg () : Student : Student name = Wanda name = Zenon = Niemiec = Nowak index No. = 43789 index No. = 44564 grades = 4, 5, 5, 3 grades = 3.5, 4, 4 extent of the Student class : Student name = Barbara = Wyka index No. = 44333 grades = 5, 4.5, 5, 3.5 Rys. 6. Klasa Student i jej przykładowa ekstensja Zagadnienie ekstensji jest bardziej złoŝone w sytuacji, gdy klasa uczestniczy w związku generalizacji-specjalizacji. Problem ten jest omówiony w wykładzie poświęconym generalizacji-specjalizacji. 3.2.8 Atrybuty Atrybut obiektu jest nazwaną wartością; wartość atrybutu moŝe być literałem lub obiektem (który w takiej sytuacji jest podobiektem). Podstawowa róŝnica pomiędzy atrybutem-literałem a atrybutem-podobiektem polega na tym, Ŝe atrybutliterał nie posiada toŝsamości, w związku z czym nie moŝna tworzyć prowadzących do niego powiązań. Definicje atrybutów, będąc inwariantami obiektów, są przechowywane w klasie (Rys. 7 (a)), natomiast wartości atrybutów nie naleŝą do inwariantów i są przechowywane nie w klasach, ale w obiektach (Rys. 7 (b) i (c)). Person : string age : integer :Person = Nowak age = 53 :Person = Stycz age = 24 Rys. 7. Definicje i przykładowe wartości atrybutów (a) (b) (c) Ilustrację moŝliwych rodzajów atrybutów na przykładzie hipotetycznej klasy Pracownik przedstawia Rys. 8: proste przechowują pojedyncze atomowe, niepodzielne wartości, np.: imię, nazwisko, nazwisko panieńskie, wiek, płeć; złoŝone przechowują wartości, które potencjalnie mogą nie być atomowe, np.: data urodzenia, adres zamieszkania, lista poprzednich miejsc pracy, adres firmy; opcjonalne nie kaŝdy obiekt danej klasy posiada wartość dla tego atrybutu, np.: nazwisko panieńskie, lista poprzednich miejsc pracy; na diagramie opcjonalność atrybutu jest oznaczana poprzez umieszczenie [0..1] po jego nazwie; powtarzalne potencjalnie mogą przechowywać wiele wartości tego samego typu, np.: lista poprzednich miejsc pracy; na diagramie powtarzalność atrybutu jest oznaczana poprzez umieszczenie [0..*] po jego nazwie; pochodne 2 są wypadkową innych wartości, np. wiek; nazwy atrybutów pochodnych są poprzedzane ukośnikiem ( / ); 2 Specyfikowanie atrybutów pochodnych w sytuacji, gdy ze względu na czytelność diagramu zalecane jest usuwanie z niego wszelkich elementów nadmiarowych, wydaje się być irracjonalne. Tak jednak być nie musi, gdyŝ analityk wprowadzając do diagramu atrybut pochodny moŝe sugerować, Ŝe warto przechowywać wartości obliczone przez metody (metody omówione są w dalszej części wykładu) skojarzone z tym atrybutem. Taka sytuacja moŝe mieć miejsce wówczas, gdy wartość atrybutu rzadko ulega zmianie, jest często wykorzystywana, a jej obliczenie jest kosztowne.
klasowe ich wartości są identyczne dla wszystkich obiektów w danej ekstensji, np. adres firmy 3 ; na diagramie nazwy atrybutów klasowych są podkreślane; atrybut będący obiektem, np. zdjęcie. Rys. 8. Przykład klasy i jej atrybutów Employee name maiden name [0..1] birth date /age address gender list of previous jobs [0..*] company address photo Rys. 9 przedstawia klasę Pracownik, której atrybut foto przechowuje wartość będącą wystąpieniem klasy JPEG, modelującej pliki graficzne w formacie JPEG. Jak juŝ wspomnieliśmy w podrozdziale 3.2.2, obiekt, którego przynajmniej jeden atrybut jest instancją pewnej klasy, jest obiektem złoŝonym. Zgodnie z zasadą relatywizmu obiektów nie są nakładane Ŝadne ograniczenia ani na liczbę, ani na rozmiar/strukturę atrybutów obiektu. Atrybuty mogą być przedstawiane na diagramach na róŝnych poziomach szczegółowości wszystkie elementy wchodzące w skład specyfikacji atrybutu, oprócz jego nazwy, (czyli m.in. stereotyp, dostępność, typ) mogą być opuszczone. Reguły nazewnictwa dla atrybutów są podobne do reguł nazewnictwa dla klas, tzn. nazwa powinna odzwierciedlać semantykę atrybutu i powinna być moŝliwie krótka. Ponadto, na etapie analizy nazwa moŝe zawierać znaki, które nie są dozwolone w środowisku implementacji (np. spacje). Rys. 9. Przykład atrybutu będącego obiektem Klucz Employee salary : real department : string photo : JPEG PoniewaŜ jedną z podstawowych własności obiektu jest jego toŝsamość, nie zachodzi potrzeba definiowania na etapie analizy klucza, czyli specjalnego atrybutu (atrybutów) unikalnie identyfikującego (identyfikujących) obiekt. Problem zilustrowany jest na Rys. 10, gdzie zdefiniowano atrybut id osoby. Gdyby atrybut ten miał słuŝyć wyłącznie do identyfikacji obiektu, czyli spełniać rolę podobną do roli pełnionej przez klucz główny w modelu relacyjnym, to jego wprowadzenie naleŝałoby uznać za błąd. JeŜeli jednak ten atrybut nie pełniłby takiej roli, ale miałby znaczenie w dziedzinie problemowej, np. odpowiadałby numerowi PESEL, to umieszczenie go wśród inwariantów klasy jest oczywiście jak najbardziej poprawne. Rys. 10. Przykład klucza implementującego toŝsamość 3.2.9 Operacje a metody Person person id : integer pesel : string : string age : integer Wszystkie obiekty, będące członkami danej klasy, podlegają tym samym operacjom. Operację naleŝy traktować jak swego rodzaju byt wirtualny, którego istnienie oznacza, Ŝe dla kaŝdego obiektu, członka danej klasy, musi być udostępnione zachowanie specyfikowane przez operację. Na przykład, zgodnie z Rys. 1 na kaŝdym obiekcie będącym 3 Oczywiście pod warunkiem, Ŝe wszyscy pracownicy pracują w tej samej firmie.
członkiem klasy Pracownik moŝna wykonać jedną z operacji: oblicz staŝ, przenieś na inne stanowisko itd. Operacja moŝe posiadać argumenty (np. operacja zmień pensję, dla której atrybutem byłaby wysokość nowej pensji) i/lub moŝe zwracać wartość (np. operacja oblicz staŝ zwracająca liczbę przepracowanych lat). Dana operacja moŝe być stosowana do obiektów róŝnych klas. Przykładem jest operacja drukuj występująca w klasach modelujących róŝne rodzaje plików na Rys. 11. Jej istnienie oznacza, Ŝe dla kaŝdego z przedstawionych na rysunku rodzajów pliku powinno być udostępnione zachowanie umoŝliwiające wydrukowanie jego zawartości, niezaleŝnie od jej formatu. Bardziej złoŝony przypadek, gdy operacja moŝe być zastosowana do obiektów klas uczestniczących w związku generalizacji-specjalizacji, jest omówiony w wykładzie poświęconym generalizacji-specjalizacji. Z pojęciem operacji ściśle związane jest pojęcie metody, która jest implementacją operacji w klasie; w pewnym uproszczeniu oznacza to, Ŝe operacja określa co naleŝy zrobić, a metoda specyfikuje jak to naleŝy zrobić. Jedna operacja moŝe posiadać wiele implementacji. W przykładzie z Rys. 11 istnieje jedna operacja drukuj i trzy metody drukuj implementujące operację drukowania dla róŝnych rodzajów plików. Zazwyczaj wszystkie metody implementujące daną operację mają taką samą sygnaturę (czyli taką samą nazwę, taką samą liczbę i typy argumentów oraz taki sam typ zwracanego wyniku), nie jest to jednak wymagane. ASCII file print Postscript file print Image file print Rys. 11. Ilustracja pojęć operacja i metoda Metody, podobnie jak atrybuty, mogą być przedstawiane na diagramach na róŝnych poziomach szczegółowości (Rys. 12); dotyczy to głównie argumentów i wartości zwracanej. Brak specyfikacji argumentów metody na etapie analizy moŝe oznaczać zarówno to, Ŝe metoda ich nie posiada, jak i to, Ŝe w danym momencie nie są one istotne. To samo dotyczy wartości zwracanej oraz typów argumentów. Reguły nazewnictwa dla metod są podobne do reguł nazewnictwa dla atrybutów. Person age change job change address Geometric object color position move (delta : Vector) is inside (p : Point) : Boolean rotate (angle) Rys. 12. RóŜne poziomy szczegółowości w przedstawianiu metod Rodzaje metod MoŜna wyróŝnić następujące rodzaje metod: metoda obiektu operuje na atrybutach, powiązaniach itd. jednego obiektu; argumentem domyślnym metody obiektu jest obiekt, dla którego została ona wywołana. metoda klasowa operuje na ekstensji klasy, czyli posiada dostęp do atrybutów, powiązań itd. wszystkich obiektów danej klasy; argumentem domyślnym metody klasowej jest ekstensja klasy. Szczególnym przypadkiem metody klasowej są konstruktory, czyli metody odpowiedzialne za tworzenie nowych obiektów. Metody klasowe są oznaczane na diagramie klas UML przez podkreślenie sygnatury. Metoda, niezaleŝnie od tego, czy jest wykonywana w kontekście obiektu czy ekstensji klasy, moŝe być metodą abstrakcyjną. Metoda abstrakcyjna posiada sygnaturę, ale nie moŝe posiadać implementacji. Metody abstrakcyjne mogą być definiowane jedynie w klasach abstrakcyjnych (patrz wykład poświęcony generalizacji-specjalizacji). Z perspektywy pojęciowej głównym zadaniem tego rodzaju metod jest definiowanie zbioru zachowań dla hierarchii klas, co z perspektywy projektowej moŝna określić jako specyfikowanie interfejsów (patrz wykład poświęcony powiązaniom i asocjacjom). Metody abstrakcyjne są omawiane takŝe w wykładzie poświęconym generalizacji-specjalizacji. Jako przykład rozwaŝmy metody klasy Pracownik z Rys. 13: Klasa nie posiada metod abstrakcyjnych, gdyŝ jako jedyna klasa na diagramie musi być klasą konkretną (patrz patrz wykład poświęcony generalizacji-specjalizacji). Klasa posiada metody obiektu, np.: policz wiek (), czy pracował w (nazwa firmy). Klasa posiada metody klasowe, np.: policz wiek (imię, nazwisko), znajdź najstarszego ().
Zwróćmy uwagę na metody o nazwie policz wiek, które są róŝnymi implementacjami operacji obliczającej wiek pracownika: Metoda policz wiek (imię, nazwisko) jest niepoprawną implementacją, gdyŝ będąc metodą obiektu jest niepotrzebnie sparametryzowana wartościami jego atrybutów wiek i nazwisko. Metoda policz wiek () jest poprawną implementacją, gdyŝ wszystkie informacje potrzebne do obliczenia wieku są przechowywane w obiekcie, który jest domyślnym argumentem metody; w związku z tym metoda nie musi być sparametryzowana. Metoda policz wiek (imię, nazwisko) jest poprawną implementacją, gdyŝ będąc metodą klasową musi ona otrzymać informację, dla którego pracownika ma obliczyć wiek. Nie jest to jednak rozwiązanie optymalne, poniewaŝ niepotrzebnie operuje na ekstensji w sytuacji, gdy wystarczy odwołać się bezpośrednio do obiektu (tak jak w rozwiązaniu powyŝej). Zwróćmy uwagę na to, Ŝe metody policz wiek () i policz wiek (imię, nazwisko) mimo róŝnych sygnatur implementują tę samą operację. Rys. 13. Przykładowa klasa Pracownik 3.2.10 Wiązanie statyczne i dynamiczne Employee name birth date /age address gender list of previous jobs [0..*] company address calculate age (name, ) calculate age () calculate age (name, ) has worked in (company name) find the oldest employee () Wiązanie jest to mechanizm zamiany identyfikatora symbolicznego (nazwy) bytu programistycznego (stałej, zmiennej, procedury itd.) występującego w programie na wartość, adres lub wewnętrzny identyfikator tego bytu. WyróŜnia się dwa rodzaje wiązań: wiązanie wczesne (statyczne) jest wykonywane przed uruchomieniem programu, czyli podczas kompilacji i konsolidacji: Zalety: większa szybkość działania programu oraz moŝliwość pełnej statycznej kontroli typów. Wady: brak moŝliwości rozbudowy aplikacji podczas jej działania. wiązanie późne (dynamiczne) jest wykonywane w czasie działania programu: Zalety: moŝliwość przesłaniania w trakcie działania aplikacji oraz moŝliwość komponowania programu w trakcie jego działania, co umoŝliwia szybkie wprowadzenie zmiany do oprogramowania. Wady: wolniejsze działanie programu, utrudniona kontrola typów. Późne wiązanie jest nieodzowne dla: implementacji komunikatów (patrz następny podrozdział), dynamicznie tworzonych perspektyw, dynamicznie tworzonych procedur bazy danych, języków zapytań, migracji obiektów, ewolucji schematu bazy danych.
3.2.11 Komunikat Komunikat oznacza wywołanie operacji, która ma zostać wykonana na obiekcie. Komunikat specyfikuje zarówno obiekt będący jego adresatem, jak i operację (z listą argumentów), która ma być wykonana; nie określa jednak, która z metod implementujących daną operację ma zostać wywołana. Decyzja o wyborze metody zostaje podjęta na podstawie przynaleŝności obiektu do klasy w trakcie działania programu: wybierana jest metoda z tej klasy, która znajduje się najbliŝej klasy obiektu będącego adresatem komunikatu w sensie hierarchii dziedziczenia (patrz wykład poświęcony generalizacji-specjalizacji). NaleŜy zwrócić uwagę na róŝnicę pomiędzy wołaniem funkcji a wysłaniem komunikatu. W przypadku wołania funkcji obiekt jest jednym z jej argumentów: funkcja (obiekt, arg1, arg2,...) Natomiast w przypadku komunikatu specyfikacja obiektu występuje przed specyfikacją sygnatury operacji (a nie na liście jej argumentów): obiekt.operacja (arg1, arg2,...) W implementacji obiekt będzie domyślnym argumentem dla metody implementującej operację. RóŜnica w obu sposobach wykonywania operacji na obiekcie nie jest róŝnicą wyłącznie syntaktyczną znacznie waŝniejsze konsekwencje takiego podejścia omawia Tab. 2. Wołanie funkcji X = dochody (emeryt) Y = dochody (pracownik) X = emeryt.dochody () Wysłanie komunikatu Y = pracownik.dochody () Efekt: Przełączanie, czyli wybór do wykonania fragmentu kodu odpowiedniego dla danego rodzaju obiektu, jest wykonywane w ciele funkcji dochody. Funkcję pisze zwykle jeden programista, stosownie do wymagań określonych w danym momencie. KaŜda zmiana związana z nowym rodzajem obiektów skutkuje zmodyfikowaniem istniejącej (jednej) funkcji dochody, co potencjalnie moŝe stanowić źródło błędów. Stosowane jest wiązanie statyczne. Tab. 2. Główne róŝnice pomiędzy wołaniem funkcji a wysłaniem komunikatu 3.2.12 Polimorfizm Efekt: Istnieje tyle metod implementujących operację dochody, ile jest klas, które ją definiują. W ciele Ŝadnej z metod nie ma przełączania; za kaŝdym razem, w zaleŝności od rodzaju obiektu będącego adresatem komunikatu, wywoływana jest inna metoda dochody implementująca operację dochody. Metody (i ich twórcy) nie muszą o sobie nic wiedzieć. KaŜda zmiana związana z nową klasą wymaga zaimplementowania nowej metody; Ŝadna z istniejących juŝ metod nie musi być modyfikowana. Stosowane jest wiązanie dynamiczne. Termin polimorfizm oznacza wiele form (postaci) jednego bytu. Słowo polimorfizm teŝ jest polimorficzne, poniewaŝ istnieje kilka rodzajów polimorfizmu: Polimorfizm metod: jedna operacja (byt wirtualny) moŝe posiadać wiele form (metod implementujących). Innymi słowy, operacja wywoływana za pośrednictwem komunikatu moŝe być róŝnie wykonana, w zaleŝności od rodzaju obiektu, do którego ten komunikat został wysłany. Polimorfizm typów: oznacza istnienie funkcji, które mogą zarówno przyjmować wartości róŝnych typów jako swoje argumenty, jak teŝ i zwracać wartości róŝnych typów. Polimorfizm typów uwaŝany jest za podstawę programowania ogólnego (generycznego) w polimorficznych językach programowania. Przykładowo, funkcja zwróć pierwszy element listy (lista) zwraca pierwszy element dowolnej listy, niezaleŝnie od tego, czy jest to lista liczb całkowitych, lista liczb rzeczywistych czy teŝ przechowuje wartości innego typu. Polimorfizm parametryczny: rodzaj polimorfizmu typów, który oznacza, Ŝe typ bytu programistycznego moŝe być parametryzowany innym typem, np. klasa Wektor(int) czy Wektor(char).
3.2.13 Klasa parametryzowana Klasa parametryzowana jest specjalnym rodzajem klasy, z którą związany jest pewien parametr (lub ich lista). Klasy parametryzowane są uŝyteczne z dwóch zasadniczych powodów: podnoszą poziom abstrakcji oraz zwiększają potencjał ponownego uŝycia. Klasa parametryzowana moŝe być przedstawiana na diagramach na dwa sposoby, co ilustruje Rys. 14. Podstawowe zastosowanie klas parametryzowanych polega na wykorzystaniu ich do definiowania zbiorów (szerzej: kolekcji). W naszym przykładzie kaŝdy obiekt klasy Kolekcja <Płyta>, lub równowaŝnie Kolekcja płyt, jest zbiorem obiektów będących członkami klasy Płyta. Zwróćmy uwagę na stereotyp «bind» przy strzałce oznaczającej zaleŝność, którego parametr Płyta jest uŝyty do sparametryzowania klasy Kolekcja w celu zdefiniowania klasy Kolekcja płyt. (a) Collection <CD> Collection T current parameterization parameter (b) add (T) delete (T) «bind» (CD) CD collection Rys. 14. Klasa parametryzowana 3.3 Podsumowanie Koncepcja obiektowości zawiera duŝą liczbę pojęć, z których dwa najwaŝniejsze to obiekt i klasa. Wraz z nimi w wykładzie omówiono równieŝ takie pojęcia jak atrybut, metoda, hermetyzacja, komunikat oraz polimorfizm. JuŜ te kilka koncepcji sprawia, Ŝe w porównaniu do innych podejść, w tym do podejścia relacyjnego, obiektowość znacznie lepiej pozwala opisać dziedzinę problemową. Siła wyrazu obiektowości jest wzmacniana poprzez pojęcia przedstawiane w kolejnych wykładach. 3.4 Przykładowe pytania i problemy do rozwiązania 1. Jak jest definiowane pojęcie obiektu? Podaj przykłady obiektów występujących w dziedzinie problemowej szkoła wyŝsza. 2. Krótko omów najwaŝniejsze pojęcia związane z koncepcją obiektu. 3. Na czym polega relatywizm obiektów? 4. Jaka jest róŝnica pomiędzy obiektem a klasą? 5. Jaki aspekt dziedziny problemowej moŝna modelować za pomocą metod? 6. W oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę wypoŝyczalni płyt DVD (wykład 2, podrozdział 2.12), wykonaj następujące zadania: Zidentyfikuj obiekty. Zdefiniuj klasy wraz z ich atrybutami i metodami.