Obiektowe języki zapytań

1. Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 03

2. Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja (1)

3. Co to jest obiektowość? • W ostatnich latach termin „obiektowy” (object-oriented) stał się bardzo popularnym określeniem narzędzi i technologii informatycznych. • Wśród nich można wymienić: • języki programowania Smalltalk, C++, Java i Eiffel, • standardy i technologie CORBA, COM/DCOM, EJB, J2EE • standardy ODMG i SQL-99 (SQL3), • notację UML, • systemy zarządzania bazą danych Oracle-9, Oracle-10G, Informix Dynamic Server, Versant, Gemstone, ObjectStore, O2, • pośredników obiektowych zleceń (Object Request Brokers, ORBs) RMI, Orbix, Visibroker, • ... • Równie popularne stały się pojęcia charakteryzujące obiektowość, takie jak: obiekt, tożsamość, klasa, typ, interfejs, metoda, dziedziczenie, hermetyzacja, polimorfizm.

4. Co to jest obiektowość? .... • Obiektowość jest ideologią informatyczną o luźno zarysowanych założeniach, pojęciach i granicach. • Różnych sformułowań obiektowości i jej poszczególnych pojęć są setki. • Prawie każdy język programowania lub system mający w swoim tytule określenie „obiektowy” prezentuje nieco inne spojrzenie na obiektowość. • Niekiedy te różnice są fundamentalne, np. różnice pomiędzy modelem obiektowym notacji UML i modelem obiektowym języka SQL-99. • Mnogość modeli danych określanych jako „obiektowe”, luźne ich założenia i granice, różnorodne ograniczenia powodują, że specyfikacje obiektowych języków zapytań są oparte na intuicyjnym gruncie. • Centralnym motywem obiektowości jest dopasowanie modeli komputerowych do własności ludzkich zmysłów i mózgu – mechanizmów percepcji, wyobrażeń i rozumienia świata. • Świat jest postrzegany przez ludzi jako mnogość obiektów, powiązań pomiędzy obiektami oraz zachowania się obiektów. • Obiekty świata rzeczywistego podlegają klasyfikacji na podstawie ich podobieństwa.

5. Uporządkowanie pojęć • Wobec mnogości poglądów oraz bardzo różnych koncepcji obiektowości nie istnieje możliwość podania takich definicji, które byłyby jednocześnie precyzyjne dla różnych odmian modeli określanych jako „obiektowe”. • Konieczny jest kompromis, który precyzowałby te pojęcia i byłby dobry z punktu widzenia definicji obiektowych języków zapytań. • Zajmiemy się wyjaśnieniem podstawowych pojęć, takich jak: obiekt, atrybut, powiązanie, klasa, abstrakcyjny typ danych, hermetyzacja, komunikat, metoda, polimorfizm i innych. • Uzupełnimy prezentacją pewnych zasad wynikających ze spekulacji myślowych lub estetycznego domknięcia dziedziny, takich jak relatywizm obiektów, zasada wewnętrznej identyfikacji lub ortogonalna trwałość. • Po wyjaśnieniu podstaw koncepcyjnych obiektowości będziemy starali się przedstawić nasze formalne spojrzenie na obiektowość, które umożliwi precyzyjne definiowanie własności obiektowych języków zapytań.

6. Obiekt object • Wielu autorów nie rozróżnia pojęcia obiektu jako pewnej abstrakcji pojęciowej lub informacyjnej, konkretnego obiektu (materialnego) istniejącego w świecie rzeczywistym, oraz struktury danych określanej jako „obiekt” przechowywanej wewnątrz komputera. • Dla języków zapytań tylko ostatni punkt widzenia jest relewantny. • Obiektem będzie więc pewna struktura danych przechowywana w przestrzeni pamięciowej komputera. • Nie wymagamy, aby ta struktura danych miała swój odpowiednik wśród obiektów świata rzeczywistego. • Obiektem może być także dowolna abstrakcja programistyczna, np. moduł, procedura, zmienna, stała środowiskowa, okienko wyświetlane na ekranie, plik tekstowy, itd. • Istotą obiektu jest to, że programista może nim manipulować tak jak pojedynczą zwartą bryłą, np. wyszukiwać, kopiować, tworzyć, usuwać lub przenosić.

7. Tożsamość obiektu, identyfikator obiektu object identity • W odróżnieniu od modelu relacyjnego obiektowość nie zakłada konieczności określenia takiego atrybutu obiektu (lub kombinacji atrybutów), który identyfikuje go w sposób unikalny, czyli tzw. „klucza głównego” (primary key). • Obiekt posiada swoją tożsamość (identity), tj. istnieje niezależnie od innych obiektów i od swojego aktualnego stanu. • W praktyce tożsamość oznacza ona, że obiekt posiada unikalny wewnętrzny identyfikator (object identifier, OID), który odróżnia go od innych obiektów. • Taki identyfikator jest nadawany przez system automatycznie, niezależnie od woli projektanta lub programisty. • Wewnętrzny identyfikator jest nieczytelny, nie przenosi informacji biznesowej. • Wewnętrzny identyfikator umożliwia budowanie referencji do obiektu, w szczególności tworzenie powiązań pointerowych.

8. Trwałość identyfikatora obiektu • Identyfikator obiektu może być trwały (persistent), tj. niezmienny podczas całego życia danego obiektu. • Jest to założenie rozsądne dla obiektów przechowywanych w bazie danych, gdzie zmiana identyfikatora obiektu może pociągać za sobą kłopotliwą zmianę wszystkich referencji/pointerów prowadzących do tego obiektu. • Dla innych kategorii obiektów takie założenie może być jednak trudne do spełnienia, gdyż możne oznaczać konieczność zwiększenia długości identyfikatora, implikować dodatkowe zapotrzebowanie na pamięć, lub powodować zwiększenie czasów dostępu. • Dla celów definicji i implementacji języków zapytań założenie o trwałości identyfikatora obiektu jest istotne tylko w pewnym zakresie, mianowicie, identyfikator obiektu tak długo powinien być trwały, jak długo istnieją rezultaty zapytań, w ramach których występuje ten identyfikator.

9. Nazwa obiektu • Każdy obiekt posiada nazwę, poprzez którą programista lub użytkownik może identyfikować obiekt w tekście programu lub zapytania. • Nazwa obiektu z reguły posiada nieformalne konotacje, np. nazwy takie jak Student, Osoba, Faktura, Wykład przenoszą pewną informację o znaczeniu odpowiedniej struktury danych w świecie rzeczywistym. • Obiekt może posiadać więcej niż jedną nazwę. Z reguły różne nazwy obiektu implikują różne spojrzenie na semantykę obiektów w świecie rzeczywistym. • W odróżnieniu od identyfikatora, nazwa obiektu nie musi być unikalna - może być wiele obiektów posiadających tę samą nazwę. Np. można utworzyć dowolnie dużo obiektów o nazwie Student. • Obiekt może być identyfikowany przez nazwy inne niż jego własna nazwa. Np. obiekt Student może być także identyfikowany przez nazwę Osoba. Jest to konsekwencja zasady zamienialności (substitutability).

10. Stan obiektu, atrybuty obiektu object state • Obiekt posiada stan, określany jako kombinacja wartości wszystkich składowych obiektu, przede wszystkim wartości wszystkich jego atrybutów oraz powiązań z innymi obiektami. • Stan obiektu może zmieniać się w czasie. • Istnieje wiele rodzajów atrybutów obiektów i ich kombinacji: • Atrybut prosty lub atomowy taki jak np. NAZWISKO dla obiektu PRACOWNIK. Przechowuje dokładnie jedną wartość; np. ”Kowalski”. • Atrybut złożony, taki jak np. ADRES. Przechowuje wiele wartości. Ma strukturę hierarchiczną. • Atrybut pointerowy: zawiera jako wartość identyfikator obiektu. • Atrybut powtarzalny: przechowuje pewien zestaw wartości o nieokreślonej i zmiennej w czasie liczbie elementów. • Atrybut opcyjny, multimedialny, wyliczalny, domyślny, ...

11. Metody związane z obiektem • Identyfikacja stanu obiektu (np. odczytanie wartości jego atrybutów) oraz zmiany stanu obiektu są możliwe dzięki pewnym procedurom, funkcjom lub operacjom związanym z danym obiektem. • W idealistycznym przypadku, nie powinna istnieć możliwość dostępu do obiektu (lub zmiany jego stanu) bez pośrednictwa metod zdefiniowanych przez projektanta (i/lub programistę). • Koncepcja taka pokrywa się z założeniami pojęcia określanego jako abstrakcyjny typ danych (abstract data type, ADT). • W założeniu ma to przeciwdziałać nieodpowiedzialnym modyfikacjom obiektu (np. naruszeniom prywatności lub spójności przechowywanych w nim danych). • W praktyce jednak to założenie okazało się zbyt mocne i w wielu przypadkach zbyt ograniczające i wewnętrznie sprzeczne. • Istnieje szereg argumentów przeciwko takiemu podejściu; wyjaśnimy je przy okazji omawiania pojęcia hermetyzacji.

12. Przykład obiektu Porównaj Sprawdź podpis stan Nalicz Zlikwiduj procent konto Zmień upoważnienie • Czy oprócz wymienionych metod można będzie dostać się do stanu obiektu poprzez nazwy atrybutów ? • Tak. Kwestia zostanie rozpatrzona dalej. Wypłać Wpłać KONTO Numer123-4321 WłaścicielJan Kowalski UpoważnionyEwa Kowalska SaldoZł34567 .... Upoważnij

13. Obiekt złożony complex object • Obiekt może być złożony, tj. składać się z pewnej liczby komponentów, które także mogą być złożone. • W zależności od języka lub systemu komponenty mogą być traktowane jako obiekty lub mogą być uważane za kategorię różną od obiektów. • Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów składających się na obiekt, rodzajów komponentów, lub liczby poziomów hierarchii komponentów. • Obiekt złożony reprezentujący byt świata rzeczywistego powinien zawierać wszelkie informacje, które odnoszą się do tego bytu. • Niezależnie od stopnia złożoności obiektu i jego wielkości projektant lub programista może rozpatrywać go i wykonywać na nim operacje jak na pojedynczym elemencie. • Podane wyżej założenia stwarzają nową sytuację w stosunku do modelu relacyjnego, gdzie informacje o obiekcie wyróżnialnym w rzeczywistości modelowanej przez dane są rozproszone w krotkach wielu tabel.

14. Zasada relatywizmu obiektów object relativism • Zgodnie z zasadą relatywizmu obiektów, każdy obiekt złożony jest zestawem podobiektów, które mogą być złożone lub atomowe. Każdy podobiekt jest traktowany jako samodzielny obiekt. Ogólne własności dotyczące obiektów i podobiektów są identyczne. • Od tej zasady nie ma wyjątków, w szczególności atomowy atrybut obiektu (np. atrybut ZAROBEK obiektu PRACOWNIK) jest obiektem. • Powiązanie do innego obiektu jest też obiektem. • Konsekwencją relatywizmu jest istnienie obiektów, które nie posiadają atrybutów (czyli obiektów atomowych), jak również obiektów, dla których nie jest istotne definiowanie klas, ponieważ są one obsługiwane wyłącznie przez metody generyczne. • Konsekwencją relatywizmu obiektów jest również fakt, że każdy podobiekt (atrybut) musi posiadać swój unikalny identyfikator. • Np. obiekt PRACOWNIK ma pewien zestaw przypisanych mu metod, ale jego atrybut ZDJĘCIE jest innym obiektem posiadającym własne metody. • Niektóre obiekty są obsługiwane wyłącznie przez wbudowane metody generyczne, takie jak +, -, <, =. Dla nich nie jest istotne definiowanie klas.

15. Znaczenie relatywizmu obiektów • Relatywizm obiektów znacznie upraszcza ich model formalny. • Dzięki relatywizmowi środki dostarczane do dyspozycji programistów mogą być zredukowane do minimum, gdyż nie zachodzi np. potrzeba różnicowania środków dostępu do obiektów i do atrybutów. • Relatywizm pozwala traktować moduły lub całe bazy danych jako pojedyncze obiekty definiowane, dostępne i manipulowalne przy pomocy standardowych środków. • Minimalizacja ilości cech, które muszą być rozpatrywane przy definiowaniu i manipulowaniu obiektami ma konsekwencje dla prostoty całości interfejsu programistycznego, szybkości jego nauczania, rozmiaru dokumentacji, rozmiaru i regularności języków, złożoności modeli formalnych oraz łatwości i ogólności metod implementacyjnych. • Jak dotąd, relatywizm obiektów nie jest popularny. Brak świadomości co do znaczenia relatywizmu obiektów można uważać za przejaw niedojrzałości wielu koncepcji w zakresie obiektowości.

16. Zasada wewnętrznej identyfikacji internal identification • Jest konsekwencją zasady relatywizmu obiektów. • Zgodnie z zasadą wewnętrznej identyfikacji każdy byt programistyczny, który może być niezależnie od innych wyszukiwany, wiązany, aktualizowany, wstawiany, usuwany, indeksowany, zabezpieczany, blokowany, itp. musi mieć unikalny wewnętrzny identyfikator. • Tej zasadzie będą podlegać dowolne identyfikowalne byty zasobów komputera lub danej aplikacji, m.in. procedury zgromadzone w bibliotekach, klasy, metody, perspektywy, ograniczenia, wyzwalacze, moduły, itd. • Nie jest istotne w jaki sposób identyfikator ma być konstruowany. Np. może to być fizyczny adres, <OID+nazwa atrybutu>, <OID+offset>, itd. • <OID+nazwa atrybutu> nie jest dobrą identyfikacją atrybutu, jeżeli jest on wielowartościowy. Każda wartość takiego atrybutu musi mieć unikalną identyfikację. <OID+offset> jest również niedobry, gdyż jest powiązany z fizyczną reprezentacją i stałym formatem obiektu. • Identyfikator bytu programistycznego nie może być związany ze stanem tego bytu, o ile ten stan może ulegać zmianom. Czyli klucz główny (primary key), znany z modelu relacyjnego, też nie zawsze jest dobrą identyfikacją.

17. Znaczenie zasady wewnętrznej identyfikacji • Istnienie unikalnego wewnętrznego identyfikatora obiektu i jego dowolnych podobiektów umożliwia budowanie jednoznacznych referencji (references) do tego obiektu. • Brak możliwości budowy referencji powoduje trudności z definicją semantyki wielu funkcjonalności, takich jak np. operatora podstawienia, operatora usuwania wartości atrybutu powtarzalnego, zapewnienie prywatności dostępu do atrybutu, itd. • Zasadzie wewnętrznej identyfikacji muszą także podlegać powiązania pomiędzy obiektami. Powiązanie może podlegać aktualizacji, blokowaniu lub ochronie, wobec czego konieczna jest jego jednoznaczna wewnętrzna identyfikacja by umożliwić spójną implementację tych cech. • Zasadzie wewnętrznej identyfikacji powinny podlegać również elementy proceduralne, takie jak procedury, funkcje i metody. • Zasada wewnętrznej identyfikacji jest ignorowana w modelu relacyjnym. Wynikają stąd liczne anomalie i niejasna semantyka wielu cech systemów i języków, np. semantyka klauzuli update w SQL. • Podobnie z XML i systemami opartymi na XML.

18. Powiązania pomiędzy obiektami PRACOWNIK PRACOWNIK PRACOWNIK Nazwisko Kowal Nazwisko Nowak Nazwisko Babel Zarobek 1500 Zarobek 2500 Zarobek 2000 PracujeW PracujeW PracujeW Zatrudnia Zatrudnia Zatrudnia Nazwa Syntex Szef NrFirmy 102030 FIRMA pointer links, relationships • Dzięki istnieniu unikalnych identyfikatorów obiektów w obiektowych językach programowania i bazach danych możliwe jest tworzenie bezpośrednich powiązań pointerowych między obiektami. • Dość często każdy pointer ma "bliźniaka"; spójność par pointerów jest wspomagana systemowo (ODMG).

19. Znaczenie powiązań między obiektami • Powiązania pointerowe były krytykowane przez propagatorów modelu relacyjnego jako prowadzące do utraty niezależności danych. • W modelu relacyjnym powiązania są realizowane poprzez umieszczanie identycznych wartości w różnych miejscach relacyjnej struktury danych, zwykle wartości klucza głównego i tzw. klucza obcego. • Obiektowość wraca do powiązań pointerowych, odrzucając przy tym stare kontr-argumenty jako demagogiczną, pseudo-techniczną retorykę. • Zaletą powiązań pointerowych jest naturalne odwzorowanie semantycznych związków między obiektami. • Zaletą jest konceptualizacja programów, dzięki wyrażeniom ścieżkowym (pathexpressions) skracającym kod i zwiększającym jego czytelność. • Powiązania pointerowe umożliwiają zwiększenie szybkości działania, gdyż nawigacja (przejście) wzdłuż pointera, np. od obiektu PRACOWNIK do obiektu FIRMA, jest z reguły bardzo szybka. • W systemach relacyjnych tego rodzaju przejście wymaga wykonania kosztownej operacji złączenia (join); optymalizacja nie zawsze działa.

20. Przykład wykorzystania powiązań pointerowych • Podaj nazwisko szefa Nowaka: • SQL: • SBQL: • Występujący w zapytaniu SQL warunek p.NrFirmy = f.NrFirmyjest koncepcyjnie równoważny przejściu wzdłuż pointera PracujeW w modelu obiektowym. • W zapytaniu SBQL taki warunek się nie pojawia, gdyż jest on „wszyty” w strukturę danych w postaci powiązania pointerowego. select s.Nazwisko from PRACOWNIK p, FIRMA f, PRACOWNIK s where p.NrFirmy = f.NrFirmy and f.Szef = s.NrPracownika and p.Nazwisko = "Nowak" (PRACOWNIK where Nazwisko = "Nowak"). PracujeW.FIRMA.Szef.PRACOWNIK.Nazwisko

21. Powiązania binarne i n-arne • Model oparty na pointerach uwzględnia wyłącznie powiązania binarne. • W modelu tym nie można również uwzględnić atrybutów powiązań i ewentualnie metod przypisanych do powiązań. • Istnieją kontrowersje co do tego, czy są to istotne ograniczenia modelowania pojęciowego. • Potrzeba wprowadzenia powiązań n-arnych i/lub z atrybutami pojawia się w modelowaniu pojęciowym rzadziej i można je zastąpić powiązaniami binarnymi bez atrybutów poprzez wprowadzenie nowej klasy obiektów. • Model, w którym mogą istnieć powiązania n-arne (n  3) oraz posiadające atrybuty powoduje znaczny rozrost środków programistycznych niezbędnych dla jego obsługi (patrz CORBA Relationship Service). • Jeżeli istnieją atrybuty powiązań, to mogą okazać się konieczne metody dla obsługi tych atrybutów. W tej sytuacji powiązanie musiałoby być związane z własną klasą, co implikuje, że powiązanie jest także obiektem. Wracamy więc do punktu wyjścia.

22. Zamiana powiązań n-arnych na binarne OSOBA Bober OSOBA Kowalska OSOBA Bober OSOBA Kowalska Sprzedający Sprzedający Kupujący Kupujący TRANSAKCJA Plac 1995.08.16 40000 Transakcja Plac 1995.08.16 40000 Pośrednik Pośrednik OSOBA Nowak OSOBA Nowak Pośrednik Pośrednik Transakcja Samochód 1998.05.15 20000 TRANSAKCJA Samochód 1998.05.15 20000 Sprzedający Sprzedający Kupujący Kupujący OSOBA Maciąg OSOBA Bielicka OSOBA Maciąg OSOBA Bielicka

23. Aktualizacja powiązań • Języki proponowane przez różnych autorów dość często nie uwzględniają faktu, że powiązania pomiędzy obiektami muszą być aktualizowane. • Np. w języku OQL standardu ODMG nie można zbudować referencji do powiązania, co powoduje, że aktualizacja powiązania poprzez wyrażenie OQL staje się niestandardowa lub niemożliwa. • Aktualizacja powiązania oznacza operację podstawienia, która wymaga odzyskania (po lewej stronie podstawienia) referencji do powiązania, tj. identyfikatora danej przechowującej pointer. • Jeżeli pointer jest związany ze swoim bliźniaczym pointerem odwrotnym, wówczas aktualizacja dowolnego z nich pociąga za sobą odpowiednią aktualizację dwóch bliźniaczych pointerów (znajdujących się w starym i nowym obiekcie, do których prowadził/prowadzi aktualizowany pointer). • Takie rozwiązanie jest cechą standardu ODMG (wiązanie do C++). • Usunięcie obiektu pociąga za sobą usunięcie powiązań tego obiektu z innymi obiektami. „Bliźniacze” pary pointerów i ich synchroniczna aktualizacja umożliwiają uniknięcie "zwisających pointerów ".

24. Hermetyzacja i ukrywanie informacji encapsulation information hiding • Hermetyzacja jest grupowaniem elementów składowych w obrębie jednej bryły i następnie, manipulowanie tą bryłą jako całością. • Hermetyzację wiąże się z ukrywaniem części informacji dotyczącej struktury i implementacji wnętrza tej bryły. • Hermetyzacja jest generalną zasadą inżynierii oprogramowania sformułowaną przez D. Parnasa w 1972 w związku z pojęciem modułu. • Moduł, klasa, abstrakcyjny typ danych (ADT) - przykłady hermetyzacji. • Programista ma tyle wiedzieć o tworze programistycznym (procedurze, module, obiekcie, klasie), ile mu trzeba, aby go efektywnie używać. • Wszystko, co może być przed programistą ukryte, powinno być ukryte. • Jest to pożądane zarówno ze względu na potrzebę nie przeciążania modelu pojęciowego programisty niepotrzebnymi elementami, jak i ze względu na konieczność zredukowania potencjalnych błędów w oprogramowaniu. • Specyfikacja jest oddzielona od implementacji. Możliwa jest zmiana implementacji bez zmiany specyfikacji. Programistę interesuje wyłącznie specyfikacja - nie ma potrzeby ani możliwości wglądu w implementację.

25. Różne spojrzenia na hermetyzację • Hermetyzacja ortodoksyjna (znana z języka Smalltalk i ADT). Na zewnątrz klasy lub obiektu widoczne są tylko niektóre metody (operacje); natomiast pozostałe cechy obiektu (jego stan), w tym wszystkie jego atrybuty, są ukryte. • Hermetyzacja ortogonalna w stosunku do rodzaju własności klasy, obiektu lub modułu (Modula-2, C++, Eiffel, Java). Dowolna własność obiektu (atrybut, metoda, itp.) może być prywatna (ukryta) lub publiczna. • Modula-2 i Eiffel wprowadzają pojęcie listy eksportowej, ustalającej cechy „eksportowane” na zewnątrz do użytku publicznego. • C++ wprowadza podobny środek w inny sposób, jak również dodatkowe możliwości w postaci cech chronionych (protected) oraz klas „przyjacielskich” (friend class). • Java wprowadza pojęcie interfejsu grupującego cechy publiczne klasy; koncepcyjnie odpowiada on pojęciu "listy eksportowej".

26. Ortodoksyjna hermetyzacja jest sprzeczna • Ortodoksyjna hermetyzacja należy do retoryki niektórych zwolenników obiektowości. • Zakłada, że deklaracja dowolnego publicznego atrybutu A oznacza dwie metody: getA (podaj wartość A) i setA (ustaw wartość A). Patrz np. opis standardu CORBA lub EJB. • Sprzeczności ortodoksyjnej hermetyzacji: • Niespójność z zasadą ortogonalności typów masowych. Np. załóżmy, że atrybutem atr pracownika jest zbiór jego stanowisk. W tym przypadku nie wystarczą nam metody czytaj_atr i zmień_atr, ponieważ będą one działać na pełnych kolekcjach, natomiast programista może sobie życzyć odczytania pojedynczych elementów tych kolekcji, wstawiania nowych elementów i usuwania elementów. • Jeżeli atrybut jest kolekcją, to musi istnieć metoda podstawiająca na dowolną wartość z tej kolekcji. Taka metoda musi opierać się o iterator, czyli mechanizm, który zwraca referencje do wartości atrybutów. • Uniknięcie zwracania referencji do atrybutu jest motywem tej koncepcji, a tu okazuje się, że tak czy inaczej musimy zwracać referencje.

27. Sprzeczności ortodoksyjnej hermetyzacji, cd. • Niespójność z zasadą relatywizmu obiektów. Zasada ta mówi, że atrybuty wewnątrz obiektu są również obiektami. • Przyjmując konsekwentne stosowanie ortodoksyjnej hermetyzacji, wszelka obsługa tych atrybutów powinna być również dokonywana przez metody. Tymczasem obiekty atomowe muszą być obsługiwane przez wszyte w dany język metody generyczne (np. operator podstawienia). • Niespójność z wartościami zerowymi i/lub wariantami. Jeżeli atrybut atr może przyjmować wartości zerowe lub może być obecny lub nieobecny w danym wariancie, wówczas podane wyżej dwie metody są niewystarczające. • Niespójność z koncepcją języków zapytań. Języki zapytań wymagają wiązania (czyli bezpośredniego dostępu) zarówno do obiektów, jak i ich atrybutów. • Niespójność z koncepcją schematu bazy danych. Programista programując aplikację z bazą danych musi widzieć i używać jej struktury w postaci obiektów, atrybutów i powiązań. • Trudności z generycznością, np. zakomunikowaniu atrybutu jako parametru call-by-reference do procedury lub metody.

28. Hermetyzacja ortogonalna • Oznacza, ze dowolna cecha obiektu może być prywatna lub publiczna. • Jeżeli atrybut jest publiczny, to oznacza, że istnieje generyczna metoda (wspólna dla całego modelu), która zwraca referencję do tego atrybutu. • Tą metodą jest (niejawna) operacja wiązania (binding), której argumentem jest nazwa (m.in. atrybutu), zaś wynikiem jest referencja lub zbiór referencji. Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu PRACOWNIK PRACOWNIK NAZWISKO Nowak ROK_UR 1951 NAZWISKO Nowak ZAROBEK 2500 DZIAŁ Zabawki DZIAŁ Zabawki ZarobekNetto() {...}; Podatek(){...}; ZarobekNetto() ZmieńZarobek(...) {...}; ZmieńZarobek(...) Wiek(){ return RokBież - ROK_UR }; Wiek()

29. Komunikat message • Komunikat jest tym samym, co wołanie procedury. • Różnice dotyczą wyłącznie składni, miejsca ulokowania procedury (metody są wewnątrz klasy) oraz sposobu komunikowania parametrów do procedury: • Wołanie procedury: • Komunikat: • Różnica dotyczy także polimorfizmu, tj. mechanizmu dynamicznego wyboru metody po wysłaniu komunikatu do obiektu. • Polimorfizm wymaga dynamicznego wiązania. Bez dynamicznego wiązania pojęcie komunikatu jest równoważne wołaniu procedury (z dokładnością do składni). Polimorfizm jest ważną cechą, i dlatego warto odróżniać komunikaty i wołania procedur. • Języki zapytań mogą implikować inny kontekst i składnię komunikatów: Wypłać( KontoKowalskiego, 1000 ); KontoKowalskiego . Wypłać( 1000 ); (PRACOWNIK where Wiek > 45) . Nazwisko komunikat

30. Przesyłanie komunikatów a asynchroniczne przetwarzanie • Dość popularne wyjaśnienia podają, że „obiekty porozumiewają się między sobą przy pomocy mechanizmu komunikatów”. • Jest to nieuzasadniony, powierzchowny, bzdurny antropomorfizm. • Komunikaty nie mogą być interpretowane poprzez zastosowanie powierzchownej analogii do porozumiewania się miedzy ludźmi. • Niektórzy autorzy uważają paradygmat przesyłania komunikatów za postulat równoległego, „asynchronicznego” działania; • Taką naiwność interpretacyjną wprowadzili twórcy języka Smalltalk. • Obiektowość jednak nic takiego nie zakłada. Przetwarzanie równoległe lub asynchroniczne jest ważnym i trudnym problemem, całkowicie ortogonalnym w stosunku do obiektowości. • Obiektowość do tego problemu nic nie wnosi. • Komunikat należy rozumieć wyłącznie jako obiektowy odpowiednik wołania procedury.

31. Komunikat a zdarzenie • Częstym nieporozumieniem jest utożsamianie pojęcia komunikatu z pojęciem zdarzenia. Pojęcia te są różne i wzajemnie ortogonalne. • Zdarzenie ma całkowicie inną semantykę niż komunikat. Jest to pewien fakt zarejestrowany w środowisku wewnętrznym lub zewnętrznym programu, występujący losowo w stosunku do sterowania programu i nie uwzględniany w tym sterowaniu explicite. • Takim faktem może być naciśnięcie przez użytkownika klawisza Esc. • Tego rodzaju sytuacje są obsługiwane przez specjalne konstrukcje języków programowania, zwane mechanizmem wyjątków. • Zdarzenie (wyjątek) przerywa nitkę sterowania i przekazuje sterowanie do specjalnego fragmentu kodu przeznaczonego do jego obsługi. • Mechanizm takich zdarzeń i odpowiadających im fragmentów kodu służących do ich obsługi jest częścią zupełnie innego paradygmatu programowania, zwanym programowaniem zdarzeniowym. • Programowanie zdarzeniowe jest niezależne od obiektowości i mechanizmu przesyłania komunikatów.