QueryInterface: Navigera i ett objekt

När du har en inledande pekare till ett gränssnitt på ett objekt har COM en mycket enkel mekanism för att ta reda på om objektet stöder ett annat specifikt gränssnitt och i så fall för att få en pekare till det. (Information om hur du hämtar en första pekare till ett gränssnitt på ett objekt finns i Hämta en pekare till ett objekt.) Den här mekanismen är metoden QueryInterface i gränssnittet IUnknown. Om objektet stöder det begärda gränssnittet måste metoden returnera en pekare till gränssnittet. Detta gör att ett objekt kan navigera fritt genom de gränssnitt som ett objekt stöder. QueryInterface separerar begäran "Stöder du ett visst kontrakt?" från den högpresterande användningen av det kontraktet när förhandlingarna har slutförts.

När en klient först får åtkomst till ett objekt får klienten minst en IUnknown- gränssnittspekare (det mest grundläggande gränssnittet) genom vilket den kan styra objektets livslängd genom att tala om för objektet när det är klart med hjälp av objektet – och anropa QueryInterface-. Klienten är programmerad att be varje objekt som den hanterar att utföra vissa åtgärder, men IUnknown--gränssnittet har inga funktioner för dessa åtgärder. I stället uttrycks dessa åtgärder via andra gränssnitt. Klienten är därför programmerad att förhandla med objekt för dessa gränssnitt. Mer specifikt anropar klienten QueryInterface- för att be ett objekt om ett gränssnitt genom vilket klienten kan anropa önskade åtgärder.

Eftersom objektet implementerar QueryInterfacekan det acceptera eller avvisa begäran. Om objektet godkänner klientens begäran returnerar QueryInterface en ny pekare till det begärda gränssnittet till klienten. Via den gränssnittspekaren har klienten åtkomst till metoderna i gränssnittet. Om objektet å andra sidan avvisar klientens begäran QueryInterface- returnerar en nullpekare – ett fel – och klienten inte har någon pekare att anropa önskade funktioner genom. I det här fallet måste klienten hantera den möjligheten på ett korrekt sätt. Anta till exempel att en klient har en pekare för gränssnitt A på ett objekt och ber om gränssnitt B och C. Anta också att objektet stöder gränssnitt B men inte stöder gränssnitt C. Resultatet är att objektet returnerar en pekare till B och rapporterar att C inte stöds.

En viktig punkt är att när ett objekt avvisar ett anrop till QueryInterfaceär det omöjligt för klienten att be objektet att utföra de åtgärder som uttrycks via det begärda gränssnittet. En klient måste ha en gränssnittspekare för att anropa metoder i gränssnittet. Om objektet vägrar att tillhandahålla den begärda pekaren måste klienten vara beredd att klara sig utan, antingen genom att inte göra vad den hade tänkt att göra med det objektet eller genom att försöka falla tillbaka på ett annat, kanske mindre kraftfullt, gränssnitt. Den här funktionen med COM-funktioner fungerar bra i jämförelse med andra objektorienterade system där du inte vet om en funktion fungerar förrän du anropar den funktionen, och även då är det osäkert att hantera fel. QueryInterface ger ett tillförlitligt och konsekvent sätt att veta om ett objekt stöder ett gränssnitt innan det försöker anropa dess metoder.

Metoden QueryInterface ger också ett robust och tillförlitligt sätt för ett objekt att indikera att det inte stöder ett visst kontrakt. Det vill säga om man i ett anrop till QueryInterface frågar ett "gammalt" objekt om det stöder ett "nytt" gränssnitt (ett, till exempel det som uppfanns efter att det gamla objektet hade levererats), kommer det gamla objektet på ett tillförlitligt sätt, utan att orsaka en krasch, svara "nej". Tekniken som stöder detta är algoritmen som IID:er allokeras med. Även om detta kan verka som en liten punkt är det mycket viktigt för systemets övergripande arkitektur, och möjligheten att fråga efter äldre element om nya funktioner är förvånansvärt nog en funktion som inte finns i de flesta andra objektarkitekturer.

Relaterade ämnen

Använda och implementera IUnknown