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 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 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 desmarización. Además, LPVOID o void *, no tiene ningún significado en un equipo remoto. Use un puntero a 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 parámetro CHAR * 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 no inicializados pueden funcionar cuando se pasan a un programa en el mismo espacio de proceso, pero los servidores proxy y 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 (lo que permite que los punteros apunten a la misma parte de memoria). Si el alias es intencional, estos punteros deben declararse como alias en el archivo IDL. Los punteros declarados como sin contorno nunca se deben establecer alias entre sí.
Preste atención a cómo asignar y liberar memoria. Recuerde que, a menos que indique explícitamente a un objeto COM (mediante el atributo allocate ) que no libere una estructura de datos que se creó durante una llamada fuera de 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 los valores devueltos HRESULT 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 entran en conflicto con otros valores HRESULT con el mismo valor. Siempre que sea posible, use los valores devueltos universales correctos y incorrectos de COM y use un parámetro out , en lugar de hrESULT, para devolver información específica de la llamada de función.
Para obtener más información, vea los temas siguientes:
Temas relacionados