Regras de design de interface

Esta seção fornece um breve resumo das regras e diretrizes de design de interface. Algumas dessas regras são específicas para a arquitetura COM, enquanto outras são restrições impostas pela linguagem de design de 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 identificador de interface exclusivo (IID).
• Devem ser imutáveis. Uma vez criados e publicados, nenhuma parte da sua definição pode ser alterada.
• Todos os métodos de interface devem retornar um valor de HRESULT para que as partes do sistema que lidam com o processamento remoto possam relatar erros RPC.
• Todos os parâmetros de cadeia de caracteres em métodos de interface devem ser Unicode.
• Seus tipos de dados devem ser remotas. Se não for possível converter um tipo de dados em um tipo remota, você terá que criar suas próprias rotinas de marshaling e unmarshaling. Além disso, LPVOID, ou void *, não tem significado em um computador remoto. Use um ponteiro para IUnknown, se necessário.

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 RPC deve saber o tamanho exato dos dados. Se, por exemplo, um parâmetro CHAR * 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 por suas definições de tipo.

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

Tenha cuidado ao atribuir o aliasing de ponteiros (permitindo que os ponteiros apontem para o mesmo pedaço de memória). Se o aliasing for intencional, esses ponteiros devem ser declarados aliased no arquivo IDL. Ponteiros declarados como sem aliased nunca devem se aliar.

Preste atenção em como você alocar e liberar memória. Lembre-se de que, a menos que você diga explicitamente a um objeto COM (usando o atributo allocate) 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 empacotadas e desempacotadas.

Por fim, tenha cuidado ao definir seus HRESULT valores de retorno 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 valores de HRESULT com o mesmo valor. Sempre que possível, use os valores universais de retorno de sucesso e falha 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:

• Projetando interfaces remotas
• Usando uma interface COM

Tópicos relacionados

Definições de Interface e Bibliotecas de Tipos