Składanie aplikacji

Obiekt COM udostępnia aplikacji zbiór interfejsów, którymi może się ona posługiwać. Niektóre z interfejsów muszą być implementowane w każdym obiekcie. Do nich należy IUnknown, który zarządza "czasem życia" komponentu i zawiera funkcję QueryInterface, która obsługuje kolejne interfejsy danego obiektu. Drugim jest IClassFactory oraz IClassFactory2, które pozwalają tworzyć same obiekty (IClassFactory2 zajmuje się także kontrolą licencji).

Powszechnie uznaje się, że model obiektowy COM musi mieć następujące cechy: zapewniać enkapsulację i hermetyzację danych, polimorfizm oraz dziedziczenie. Enkapsulacja oznacza pewnego rodzaju oddzielenie między obiektem a aplikacją korzystającą z obiektu. COM na zewnątrz udostępnia tylko interfejs – szczegóły implementacyjne są ukryte przed wykorzystującym je programistą. Polimorfizm oznacza, że różne obiekty w inny sposób obsługują ten sam interfejs. W obiektach COM jest możliwy dzięki temu, że taki sam interfejs mogą mieć dowolne obiekty. Na przykład, IViewObject::Draw (składnia z C++) może implementować zarówno obiekt rysujący grafikę wektorową, jak i wyświetlający bitmapę.

Z dziedziczeniem sprawa jest bardziej złożona. Specyfikacja COM nie pozwala na dziedziczenie cech i metod innych obiektów. Jednak dziedziczenie służy także do tego, aby nie pisać ponownie wspólnych fragmentów kodu. Programiści tworzyli klasy bazowe, by pewne metody były wspólne dla różnych obiektów. W COM nie ma takiej potrzeby – wystarczy odpowiednio zaplanować interfejsy! Należy pamiętać także, że poszczególne obiekty COM są niezależne, tzn. dopóki ich interfejsy pozostają bez zmian, dopóty możliwe są dowolne zmiany w implementacji.

Tworzenie komponentów COM

Proces tworzenia obiektu COM składa się z dwóch etapów. Pierwszy polega na zdefiniowaniu interfejsu, drugi to implementacja obiektu. Interfejs może być albo zakodowany w samym obiekcie; w tym celu zostały zdefiniowane standardowe interfejsy (np. IClassInfo), pozwalające odczytać postać innego interfejsu, albo w oddzielnym pliku, tzw. typelib, który może być np. udostępniony tylko temu, kto zakupi dany obiekt. Można tworzyć obiekty bez szczegółowej informacji o interfejsie (potocznie nazywa się ją informacją o typach, ponieważ zawiera oprócz nazw - adresów - funkcji także informacje o parametrach i zwracanych wartościach). Jednak w takim przypadku interfejs obiektu musi być znany aplikacji, która go wykorzystuje w kompilacji.

Interfejs zapisuje się w specjalnym pliku ODL/IDL, który jest interpretowany przez specjalny program (podobny do analizatora składniowego C++), generujący zarówno bibliotekę typelib, jak i pliki nagłówkowe do kompilatora C/C++.

Ciekawą właściwością OLE jest automatyzacja. Początkowo oznaczała ona, że dana aplikacja (złożona z obiektów) obsługuje interfejs IDispatch, który pozwalał, by za pośrednictwem nazwy były wywoływane pewne funkcje danej aplikacji. Klasycznym przykładem jest Excel, który może za pośrednictwem interfejsu automatyzacji tworzyć dokumenty w Wordzie. Co ważniejsze - fakt, iż polecenia mogły być przekazywane za pośrednictwem nazw, spowodował powstanie specjalnych języków skryptów (makr), które mógł pisać użytkownik. Skrypty te stawały się bardziej złożone i np. obecnie pojawiły się języki skryptowe, np. VBScript, obsługiwany przez przeglądarkę IE, umożliwiający pisanie aktywnych stron WWW.

Elementy kontrolne

Kolejnym, ważnym elementem OLE/COM są elementy kontrolne. Odpowiadają one w przybliżeniu elementom dialogowym Windows (ale zwykle tworzone są jako okna potomne). Elementy kontrolne upraszczają m.in. tworzenie graficznego interfejsu użytkownika, ale mogą też wspomagać obliczenia, pobierać dane z bazy, tworzyć diagramy itp. Element kontrolny, opracowany zgodnie ze specyfikacją, powinien samodzielnie przedstawić się – tzn. dostarczyć programiście swój interfejs. Cechę tę wykorzystują graficzne narzędzia programistyczne, pozwalające na osadzenie danego obiektu w oknie.

Drugą interesującą własnością obiektów kontrolnych jest to, że mogą mieć wbudowany interfejs graficzny, umożliwiający zmianę ich właściwości. Na przykład w siatce można określić grubość linii oddzielającej kolejne pola, (obserwując to podczas graficznego projektowania okna), a następnie skompilować produkt. Trzecia interesująca cecha obiektów kontrolnych polega na tym, że mogą reagować na zdarzenia systemowe (komunikaty, kliknięcie myszą i in.). Tym samym stało się możliwe przekazanie części zadań programu elementom kontrolnym; ta cecha interfejsu OLE/COM jest wykorzystywana także przy edycji dokumentów osadzonych –część interfejsu aplikacji serwerowej OLE (w której otwarty jest dokument złożony) zmienia się tak, by przypominała interfejs aplikacji, przy użyciu której został utworzony. Nie ma już potrzeby otwierania oddzielnej aplikacji, tak jak w OLE 1.0.


TOP 200