Règles de conception d’interface
Cette section fournit un bref résumé des règles et des instructions de conception d’interface. Certaines de ces règles sont spécifiques à l’architecture COM, tandis que d’autres sont des restrictions imposées par le langage de conception d’interface, MIDL. Pour plus d’informations sur la conception de l’interface COM, consultez Anatomie d’un fichier IDL.
Par définition, un objet n’est pas un objet COM, sauf s’il implémente l’interface IUnknown ou une interface dérivée de IUnknown. En outre, les règles suivantes s’appliquent à toutes les interfaces implémentées sur un objet COM :
- Ils doivent avoir un identificateur d’interface unique (IID).
- Ils doivent être immuables. Une fois qu’ils sont créés et publiés, aucune partie de leur définition ne peut changer.
- Toutes les méthodes d’interface doivent retourner une valeur HRESULT afin que les parties du système qui gèrent le traitement à distance puissent signaler des erreurs RPC.
- Tous les paramètres de chaîne dans les méthodes d’interface doivent être Unicode.
- Vos types de données doivent être accessibles à distance. Si vous ne pouvez pas convertir un type de données en type accessible à distance, vous devez créer vos propres routines de marshaling et de démarshalation. En outre, LPVOID, ou void *, n’a aucune signification sur un ordinateur distant. Utilisez un pointeur vers IUnknown, si nécessaire.
Notes
L’implémentation actuelle de MIDL ne gère pas la surcharge des fonctions ou l’héritage multiple.
Autres considérations relatives à la conception d’interface
Utilisez des pointeurs vers des données très soigneusement. Pour recréer les données dans l’espace d’adressage du processus appelé, le temps d’exécution RPC doit connaître la taille exacte des données. Si, par exemple, un paramètre CHAR * pointe vers une mémoire tampon de caractères plutôt que vers un caractère unique, les données ne peuvent pas être correctement recréés. Utilisez la syntaxe disponible avec MIDL pour décrire avec précision les structures de données représentées par vos définitions de type.
L’initialisation est essentielle pour les pointeurs incorporés dans des tableaux et des structures et passés au-delà des limites de processus. Les pointeurs non initialisés peuvent fonctionner lorsqu’ils sont transmis à un programme dans le même espace de processus, mais les proxys et les stubs supposent que tous les pointeurs sont initialisés avec des adresses valides ou ont la valeur Null.
Soyez prudent lors de l’aliasing de pointeurs (permettant aux pointeurs de pointer vers le même élément de mémoire). Si l’aliasing est intentionnel, ces pointeurs doivent être déclarés alias dans le fichier IDL. Les pointeurs déclarés comme non associés ne doivent jamais s’alias mutuellement.
Faites attention à la façon dont vous allouez et libérez de la mémoire. N’oubliez pas que, sauf si vous indiquez explicitement à un objet COM (à l’aide de l’attribut d’allocation ) de ne pas libérer une structure de données qui a été créée lors d’un appel hors processus, cette structure sera détruite à la fin de l’appel. Considérez également la surcharge potentiellement destructrice créée par l’allocation inefficace des structures de données qui doivent maintenant être marshalées et non délimitées.
Enfin, soyez prudent lors de la définition de vos valeurs de retour HRESULT afin de ne pas créer de codes d’erreur qui entrent en conflit avec les codes de FACILITY_ITF définis par COM (les valeurs entre 0x0000 et 0x01FF sont réservées) ou qui entrent en conflit avec d’autres valeurs HRESULT avec la même valeur. Dans la mesure du possible, utilisez les valeurs de retour de réussite et d’échec COM universelles, et utilisez un paramètre out , plutôt qu’un HRESULT, pour retourner des informations spécifiques à l’appel de fonction.
Pour plus d'informations, voir les rubriques suivantes :
Rubriques connexes