QueryInterface: nawigowanie w obiekcie

Po uzyskaniu początkowego wskaźnika do interfejsu na obiekcie, COM ma bardzo prosty mechanizm, aby sprawdzić, czy obiekt obsługuje inny konkretny interfejs i, jeśli tak, uzyskać do niego wskaźnik. (Aby uzyskać informacje na temat uzyskania początkowego wskaźnika do interfejsu obiektu, zobacz Getting a Pointer to an Object.) Ten mechanizm to metoda QueryInterface interfejsu IUnknown. Jeśli obiekt obsługuje żądany interfejs, metoda musi zwrócić wskaźnik do tego interfejsu. Dzięki temu obiekt może swobodnie przechodzić przez interfejsy obsługiwane przez obiekt. QueryInterface oddziela żądanie "Czy obsługujesz daną umowę?" od korzystania z tej umowy o wysokiej wydajności po pomyślnym zakończeniu negocjacji.

Gdy klient początkowo uzyska dostęp do obiektu, klient otrzyma co najmniej wskaźnik interfejsu IUnknown (najbardziej podstawowy interfejs), za pomocą którego może kontrolować okres istnienia obiektu — mówiąc obiektowi, gdy jest on wykonywany przy użyciu obiektu — i wywoła QueryInterface. Klient jest zaprogramowany, aby poprosić każdy obiekt, którym zarządza, o wykonanie pewnych operacji, ale interfejs IUnknown nie ma żadnych funkcji dla tych operacji. Zamiast tego te operacje są wyrażane za pośrednictwem innych interfejsów. Klient jest zatem zaprogramowany do negocjowania z obiektami dla tych interfejsów. W szczególności klient wywoła QueryInterface, aby poprosić o obiekt interfejsu, za pomocą którego klient może wywołać żądane operacje.

Ponieważ obiekt implementuje QueryInterface, ma możliwość akceptowania lub odrzucania żądania. Jeśli obiekt akceptuje żądanie klienta, QueryInterface zwraca nowy wskaźnik do żądanego interfejsu do klienta. Za pomocą tego wskaźnika interfejsu klient ma dostęp do metod tego interfejsu. Jeśli z drugiej strony obiekt odrzuca żądanie klienta, QueryInterface zwraca wskaźnik o wartości null — błąd — a klient nie ma wskaźnika, za pomocą którego można wywołać żądane funkcje. W takim przypadku klient musi umiejętnie radzić sobie z tą możliwością. Załóżmy na przykład, że klient ma wskaźnik do interfejsu A w obiekcie i prosi o interfejsy B i C. Załóżmy również, że obiekt obsługuje interfejs B, ale nie obsługuje interfejsu C. Wynikiem jest to, że obiekt zwraca wskaźnik do B i zgłasza, że C nie jest obsługiwany.

Kluczowym punktem jest to, że gdy obiekt odrzuca wywołanie QueryInterface, nie można poprosić klienta o wykonanie operacji wyrażonych za pośrednictwem żądanego interfejsu. Klient musi mieć wskaźnik interfejsu do wywoływania metod w tym interfejsie. Jeśli obiekt odmawia podania żądanego wskaźnika, klient musi być przygotowany na obejście się bez niego, albo rezygnując z zamiaru użycia tego obiektu, albo próbując skorzystać z innego, być może mniej zaawansowanego interfejsu. Ta funkcja funkcji COM działa dobrze w porównaniu z innymi systemami obiektowymi, w których nie można wiedzieć, czy funkcja będzie działać do momentu wywołania tej funkcji, a nawet wtedy obsługa awarii jest niepewna. QueryInterface zapewnia niezawodny i spójny sposób na sprawdzenie, czy obiekt obsługuje interfejs przed próbą wywołania jego metod.

Metoda QueryInterface zapewnia również solidny i niezawodny sposób, aby obiekt mógł wskazać, że nie obsługuje danego kontraktu. Oznacza to, że jeśli w wywołaniu QueryInterface zapytasz "stary" obiekt, czy obsługuje "nowy" interfejs (na przykład taki, który został wynaleziony po wysłaniu starego obiektu), stary obiekt niezawodnie, bez spowodowania awarii, odpowie "nie". Technologią, która to umożliwia, jest algorytm przydzielania identyfikatorów IID. Chociaż może to wydawać się małym punktem, jest to niezwykle ważne dla ogólnej architektury systemu, a możliwość zapytań o starsze elementy o nowych funkcjach jest zaskakująco funkcją, która nie jest obecna w większości innych architektur obiektów.

Tematy pokrewne

Używanie i Implementowanie IUnknown