4. Obiekt złożony

Obiekt może być złożony, tj. składać się z pewnej liczby komponentów (atrybutów), które także mogą być złożone. W zależności od języka lub systemu komponenty złożone mogą być traktowane jako obiekty (podobiekty) lub mogą być uważane za kategorię różną od obiektów. Niektóre języki lub systemy wprowadzają dalsze ograniczenia w zakresie możliwości tworzenia złożonych obiektów, z reguły podyktowane pewnymi względami implementacyjnymi.

Z estetycznego punktu widzenia 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 pewien byt świata rzeczywistego powinien zawierać wewnątrz siebie wszelkie informacje, które odnoszą się do tego bytu. Ustalenia, które informacje odnoszą się do danego obiektu, a które do innego, zależą wyłącznie od projektanta lub programisty (czyli od jego modelu pojęciowego) i nie podlegają ograniczeniom ze strony bazy realizacyjnej. Przykładowo, projektant może uznać, że dzieci pracownika są albo komponentami obiektu PRACOWNIK (i dokładnie tak to zaimplementować), albo całkowicie niezależnymi obiektami (pozostającymi w pewnym związku z obiektem PRACOWNIK). 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 (np. wyszukiwać, tworzyć, przesuwać, kopiować, zmieniać, usuwać) jak na pojedynczym elemencie bez wnikania w jego wewnętrzną budowę.

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ą często rozproszone w krotkach wielu tablic, zaś manipulacja tym zestawem jako całością jest w ogóle niemożliwa lub silnie ograniczona. Przykładowo, gdybyśmy przyjęli, że pracownik może posiadać wiele stanowisk, wówczas informacje o stanowiskach Kowalskiego byłyby trzymane w jednej tablicy, zaś podstawowe informacje o Kowalskim w innej. Pewne środki systemowe, np. więzy referencyjne (referential integrity) lub tzw. kaskadowe usuwanie, wzmacniają możliwości systemowego odwzorowania semantyki złożonych obiektów w systemie relacyjnym. Są to jednak środki ad hoc, niekompletne i nieco przypadkowe. Podkreślimy tu fakt, że w stosunku do modelu relacyjnego pojęcie złożonego obiektu stanowi kolejny krok uwalniający analityka, projektanta i programistę od myślenia o reprezentacji obiektów na etapie budowy modelu pojęciowego i programowania.

Wielu autorów implicite lub explicite zakłada pewne dynamiczne własności obiektów. Przykładowo, obiekt PRACOWNIK może składać się z komponentów WYPOSAŻENIE, których stan i ilość mogą ulegać dynamicznym zmianom. Koncepcja złożonych obiektów odchodzi więc od stałych formatów zapisów.