Compartilhar via

Regras de design de interface

  • Artigo

Esta seção fornece um breve resumo das regras e diretrizes de design da interface. Algumas dessas regras são específicas para a arquitetura COM, enquanto outras são restrições impostas pela linguagem de design da interface, MIDL. Para obter detalhes sobre o design da interface COM, consulte Anatomia de um arquivo IDL.

Por definição, um objeto não é um objeto COM, a menos que implemente a interfaceIUnknownou uma interface derivada de IUnknown. Além disso, as seguintes regras se aplicam a todas as interfaces implementadas em um objeto COM:

  • Eles devem ter um IID (identificador de interface) exclusivo.
  • Eles devem ser imutáveis. Depois que eles são criados e publicados, nenhuma parte de sua definição pode mudar.
  • Todos os métodos de interface devem retornar um valor HRESULT para que as partes do sistema que lidam com o processamento remoto possam relatar erros de RPC.
  • Todos os parâmetros de cadeia de caracteres em métodos de interface devem ser Unicode.
  • Seus tipos de dados devem ser remotamente remotamente. Se você não puder converter um tipo de dados em um tipo remoto, precisará criar suas próprias rotinas de marshaling e desmarsalação. Além disso, LPVOID, ou void *, não tem nenhum significado em um computador remoto. Use um ponteiro para IUnknown, se necessário.

Nota

A implementação atual de MIDL não manipula sobrecarga de função ou herança múltipla.

 

Outras considerações de design de interface

Use ponteiros para dados com muito cuidado. Para recriar os dados no espaço de endereço do processo chamado, o tempo de execução do RPC deve saber o tamanho exato dos dados. Se, por exemplo, um CHAR * parâmetro apontar para um buffer de caracteres em vez de para um único caractere, os dados não poderão ser recriados corretamente. Use a sintaxe disponível com MIDL para descrever com precisão as estruturas de dados representadas pelas definições de tipo.

A inicialização é essencial para ponteiros inseridos em matrizes e estruturas e passados entre limites de processo. Ponteiros não inicializados podem funcionar quando passados para um programa no mesmo espaço de processo, mas proxies e stubs pressupõem que todos os ponteiros são inicializados com endereços válidos ou são nulos.

Tenha cuidado ao aliasar ponteiros (permitindo que ponteiros apontem para o mesmo pedaço de memória). Se o aliasing for intencional, esses ponteiros deverão ser declarados alias no arquivo IDL. Ponteiros declarados como não alias nunca devem ser alias uns aos outros.

Preste atenção em como você aloca e libera memória. Lembre-se de que, a menos que você diga explicitamente a um objeto COM (usando o alocar atributo) para não liberar uma estrutura de dados que foi criada durante uma chamada fora do processo, essa estrutura será destruída quando a chamada for concluída. Além disso, considere a sobrecarga potencialmente destrutiva criada pela alocação ineficiente de estruturas de dados que agora precisam ser marshaladas e não marcadas.

Por fim, tenha cuidado ao definir seus HRESULT valores retornados para que você não crie códigos de erro que entrem em conflito com códigos de FACILITY_ITF definidos por COM (valores entre 0x0000 e 0x01FF são reservados) ou que entrem em conflito com outros HRESULT valores com o mesmo valor. Sempre que possível, use os valores universais de retorno de êxito e falha do COM e use um parâmetro , em vez de um HRESULT, para retornar informações específicas para a chamada de função.

Para obter mais informações, consulte os seguintes tópicos:

definições de interface de e bibliotecas de tipos