Dela via

Designregler för gränssnitt

  • Artikel

Det här avsnittet innehåller en kort sammanfattning av regler och riktlinjer för gränssnittsdesign. Vissa av dessa regler är specifika för COM-arkitekturen, medan andra är begränsningar som införts av gränssnittsdesignspråket MIDL. Mer information om COM-gränssnittsdesign finns i Anatomy of an IDL File.

Per definition är ett objekt inte ett COM-objekt om det inte implementerar antingen IUnknown--gränssnittet eller ett gränssnitt som härleds från IUnknown. Dessutom gäller följande regler för alla gränssnitt som implementeras på ett COM-objekt:

  • De måste ha en unik gränssnittsidentifierare (IID).
  • De måste vara oföränderliga. När de har skapats och publicerats kan ingen del av definitionen ändras.
  • Alla gränssnittsmetoder måste returnera ett HRESULT- värde så att de delar av systemet som hanterar fjärrbearbetning kan rapportera RPC-fel.
  • Alla strängparametrar i gränssnittsmetoder måste vara Unicode.
  • Dina datatyper måste vara fjärrkommunikationsbara. Om du inte kan konvertera en datatyp till en fjärranslutningsbar typ måste du skapa dina egna rutiner för marskalkering och omarshaling. Dessutom har LPVOID, eller void *, ingen betydelse på en fjärrdator. Använd en pekare för att IUnknown, om det behövs.

Not

Den aktuella implementeringen av MIDL hanterar inte funktionsöverlagring eller flera arv.

 

Andra gränssnittsdesignöverväganden

Använd pekare till data mycket noggrant. Om du vill återskapa data i adressutrymmet för den process som anropas måste RPC-körningstiden känna till den exakta storleken på data. Om till exempel en CHAR * parameter pekar på en buffert med tecken i stället för ett enda tecken, kan inte data återskapas korrekt. Använd syntaxen som är tillgänglig med MIDL för att korrekt beskriva de datastrukturer som representeras av dina typdefinitioner.

Initiering är viktigt för pekare som är inbäddade i matriser och strukturer och som skickas över processgränser. Uninitialiserade pekare kan fungera när de skickas till ett program i samma processutrymme, men proxyservrar och stubs förutsätter att alla pekare initieras med giltiga adresser eller är null.

Var försiktig när du använder aliaspekare (så att pekare pekare pekar på samma minnesbit). Om aliaseringen är avsiktlig bör dessa pekare deklareras som alias i IDL-filen. Pekare som deklareras som nonaliased får aldrig alias varandra.

Var uppmärksam på hur du allokerar och frigör minne. Kom ihåg att om du inte uttryckligen säger till ett COM-objekt (med hjälp av allokera attribut) att inte frigöra en datastruktur som skapades under ett out-of-process-anrop, kommer den strukturen att förstöras när anropet slutförs. Tänk också på de potentiellt destruktiva omkostnader som skapas av ineffektiv allokering av datastrukturer som nu måste konverteras och omarshaleras.

Var slutligen försiktig när du definierar dina HRESULT- returnera värden så att du inte skapar felkoder som står i konflikt med COM-definierade FACILITY_ITF-koder (värden mellan 0x0000 och 0x01FF är reserverade) eller som står i konflikt med andra HRESULT- värden med samma värde. När det är möjligt använder du de universella värdena för com-framgång och felretur och använder en ut parameter i stället för en HRESULT-för att returnera information som är specifik för funktionsanropet.

Mer information finns i följande avsnitt:

gränssnittsdefinitioner och typbibliotek