Partager via

Règles de conception d’interface

  • Article

Cette section fournit un bref résumé des règles et 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 d’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 remotable, 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 pour IUnknown, si nécessaire.

Note

L’implémentation actuelle de MIDL ne gère pas la surcharge de fonction 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é, l’heure d’exécution RPC doit connaître la taille exacte des données. Si, par exemple, un CHAR * paramètre pointe vers une mémoire tampon de caractères plutôt qu’à un seul caractère, 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 transmis au-delà des limites de processus. Les pointeurs non initialisés peuvent fonctionner lorsqu’ils sont passés à 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 sont null.

Soyez prudent lors de l’alias de pointeurs (ce qui permet aux pointeurs de pointer vers le même morceau de mémoire). Si l’alias est intentionnel, ces pointeurs doivent être déclarés alias dans le fichier IDL. Les pointeurs déclarés comme nonaliased ne doivent jamais être alias les uns les autres.

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 du allouez attribut) de ne pas libérer une structure de données créée pendant un appel hors processus, cette structure sera détruite une fois l’appel terminé. Considérez également la surcharge potentiellement destructrice créée par l’allocation inefficace de structures de données qui doivent maintenant être marshalées et non délimitées.

Enfin, veillez à définir 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, plutôt qu’un HRESULT, pour renvoyer des informations spécifiques à l’appel de fonction.

Pour plus d’informations, consultez les rubriques suivantes :

définitions d’interface et bibliothèques de types