Udostępnij za pośrednictwem

Reguły projektowania interfejsu

  • Artykuł

Ta sekcja zawiera krótkie podsumowanie reguł i wytycznych dotyczących projektowania interfejsu. Niektóre z tych reguł są specyficzne dla architektury MODELU COM, podczas gdy inne są ograniczeniami narzuconymi przez język projektowania interfejsu MIDL. Aby uzyskać szczegółowe informacje na temat projektowania interfejsu COM, zobacz Anatomia pliku IDL.

Z definicji obiekt nie jest obiektem COM, chyba że implementuje interfejs IUnknown lub interfejs pochodzący z IUnknown. Ponadto następujące reguły mają zastosowanie do wszystkich interfejsów zaimplementowanych w obiekcie COM:

  • Muszą mieć unikatowy identyfikator interfejsu (IID).
  • Muszą być niezmienne. Po ich utworzeniu i opublikowaniu żadna część definicji nie może ulec zmianie.
  • Wszystkie metody interfejsu muszą zwrócić wartość HRESULT, aby części systemu obsługującego przetwarzanie zdalne mogły zgłaszać błędy RPC.
  • Wszystkie parametry ciągu w metodach interfejsu muszą być Unicode.
  • Typy danych muszą być remotable. Jeśli nie możesz przekonwertować typu danych na typ tabeli remotable, musisz utworzyć własne procedury marshalingowe i bez szwarzenia. Ponadto LPVOID lub void *nie ma znaczenia na komputerze zdalnym. W razie potrzeby użyj wskaźnika, aby IUnknown.

Nuta

Bieżąca implementacja midL nie obsługuje przeciążenia funkcji ani wielu dziedziczenia.

 

Inne zagadnienia dotyczące projektowania interfejsu

Bardzo ostrożnie używaj wskaźników do danych. Aby ponownie utworzyć dane w przestrzeni adresowej wywoływanego procesu, czas wykonywania RPC musi znać dokładny rozmiar danych. Jeśli na przykład CHAR * parametr wskazuje bufor znaków, a nie pojedynczy znak, nie można poprawnie utworzyć danych. Użyj składni dostępnej w języku MIDL, aby dokładnie opisać struktury danych reprezentowane przez definicje typów.

Inicjowanie jest niezbędne w przypadku wskaźników osadzonych w tablicach i strukturach oraz przekazywanych przez granice procesu. Niezainicjowane wskaźniki mogą działać po przekazaniu do programu w tej samej przestrzeni procesu, ale serwery proxy i wycinki zakładają, że wszystkie wskaźniki są inicjowane z prawidłowymi adresami lub mają wartość null.

Należy zachować ostrożność podczas tworzenia aliasów wskaźników (dzięki czemu wskaźniki mogą wskazywać ten sam fragment pamięci). Jeśli aliasowanie jest zamierzone, te wskaźniki powinny być deklarowane aliasami w pliku IDL. Wskaźniki zadeklarowane jako nieprzyzwoiszone nigdy nie powinny aliasować się nawzajem.

Zwróć uwagę na sposób przydzielania i zwalniania pamięci. Należy pamiętać, że o ile nie jawnie poinformujesz obiektu COM (przy użyciu przydzielić atrybutu), aby nie zwolnić struktury danych utworzonej podczas wywołania poza procesem, ta struktura zostanie zniszczona po zakończeniu wywołania. Należy również wziąć pod uwagę potencjalnie destrukcyjne obciążenie utworzone przez nieefektywną alokację struktur danych, które muszą być teraz marshalowane i niemarshalowane.

Na koniec należy zachować ostrożność podczas definiowania wartości zwracanych HRESULT, aby nie tworzyć kodów błędów powodujących konflikt z kodami FACILITY_ITF zdefiniowanymi przez com (wartości między 0x0000 i 0x01FF są zarezerwowane) lub że powodują konflikt z innymi wartościami HRESULT o tej samej wartości. Jeśli to możliwe, użyj uniwersalnych wartości zwracanych powodzenia i niepowodzenia COM i użyj parametru, a nie HRESULT, aby zwrócić informacje specyficzne dla wywołania funkcji.

Aby uzyskać więcej informacji, zobacz następujące tematy:

definicje interfejsu i biblioteki typów