Reglas de diseño de interfaz
En esta sección se proporciona un breve resumen de las reglas y directrices de diseño de interfaz. Algunas de estas reglas son específicas de la arquitectura COM, mientras que otras son restricciones impuestas por el lenguaje de diseño de interfaz, MIDL. Para obtener más información sobre el diseño de la interfaz COM, consulte anatomía de anatomía de un archivo IDL.
Por definición, un objeto no es un objeto COM a menos que implemente la interfaz IUnknown o una interfaz derivada de IUnknown. Además, las siguientes reglas se aplican a todas las interfaces implementadas en un objeto COM:
- Deben tener un identificador de interfaz único (IID).
- Deben ser inmutables. Una vez creados y publicados, ninguna parte de su definición puede cambiar.
- Todos los métodos de interfaz deben devolver un valor de HRESULT para que las partes del sistema que controlan el procesamiento remoto puedan notificar errores rpc.
- Todos los parámetros de cadena de los métodos de interfaz deben ser Unicode.
- Los tipos de datos deben ser remotos. Si no puede convertir un tipo de datos en un tipo remotable, tendrá que crear sus propias rutinas de serialización y desenshazamiento. Además, LPVOID o void *, no tiene ningún significado en un equipo remoto. Use un puntero para IUnknown, si es necesario.
Nota
La implementación actual de MIDL no controla la sobrecarga de funciones ni la herencia múltiple.
Otras consideraciones de diseño de interfaz
Use punteros a los datos con mucho cuidado. Para volver a crear los datos en el espacio de direcciones del proceso al que se llama, el tiempo de ejecución de RPC debe conocer el tamaño exacto de los datos. Si, por ejemplo, un CHAR * parámetro apunta a un búfer de caracteres en lugar de a un solo carácter, los datos no se pueden volver a crear correctamente. Use la sintaxis disponible con MIDL para describir con precisión las estructuras de datos representadas por las definiciones de tipo.
La inicialización es esencial para los punteros incrustados en matrices y estructuras y que se pasan a través de los límites del proceso. Los punteros sin inicializar pueden funcionar cuando se pasan a un programa en el mismo espacio de proceso, pero los servidores proxy y los códigos auxiliares asumen que todos los punteros se inicializan con direcciones válidas o son NULL.
Tenga cuidado al aplicar alias a los punteros (permitir que los punteros apunten a la misma parte de memoria). Si el alias es intencionado, estos punteros deben declararse con alias en el archivo IDL. Los punteros declarados como sinalias nunca deben establecer un alias entre sí.
Preste atención a cómo asignar y liberar memoria. Recuerde que, a menos que indique explícitamente un objeto COM (mediante el asignar atributo) no libere una estructura de datos que se creó durante una llamada fuera del proceso, esa estructura se destruirá cuando se complete la llamada. Además, tenga en cuenta la sobrecarga potencialmente destructiva creada por la asignación ineficaz de estructuras de datos que ahora deben serializarse y desmarizarse.
Por último, tenga cuidado al definir el HRESULT valores devueltos para que no cree códigos de error que entren en conflicto con códigos de FACILITY_ITF definidos por COM (los valores entre 0x0000 y 0x01FF están reservados) o que entren en conflicto con otros valores HRESULT con el mismo valor. Siempre que sea posible, use los valores devueltos universales correctos y erróneos de COM y use un parámetro, en lugar de un HRESULT, para devolver información específica de la llamada de función.
Para obtener más información, consulte los temas siguientes:
Temas relacionados