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 do 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 interface IUnknown ou 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 de sua definição pode mudar.
- Todos os métodos de interface devem retornar um valor HRESULT para que as partes do sistema que manipulam 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 impassíveis. Se você não pode converter um tipo de dados em um tipo remotable, 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.
Observação
A implementação atual do MIDL não lida com sobrecarga de função ou herança múltipla.
Outras considerações sobre 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 parâmetro CHAR * apontar para um buffer de caracteres em vez de 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 pressupõem que todos os ponteiros são inicializados com endereços válidos ou são nulos.
Tenha cuidado ao aliasing ponteiros (permitindo que ponteiros apontem para o mesmo pedaço de memória). Se o aliasing for intencional, esses ponteiros devem ser declarados aliased no arquivo IDL. Os ponteiros declarados como sem aliased nunca devem se aliar 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 atributo alocação ) para não liberar uma estrutura de dados 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.
Finalmente, tenha cuidado ao definir seus valores de retorno HRESULT para que você não crie códigos de erro que entrem em conflito com códigos FACILITY_ITF definidos por COM (valores entre 0x0000 e 0x01FF são reservados) ou que entrem em conflito com outros valores HRESULT com o mesmo valor. Sempre que possível, use os valores de retorno de êxito e falha COM universais e use um parâmetro out, em vez de um HRESULT, para retornar informações específicas para a chamada de função.
Para Mais informações, consulte os seguintes tópicos:
Tópicos relacionados