Quel est l'objet COM de javascript

L'objet COM fait référence à « Component Object Model Object », qui est un composant logiciel réutilisable qui utilise les spécifications COM ; l'utilisation des spécifications COM peut garantir que les objets COM fonctionnent bien et peuvent être facilement intégrés dans votre application. Les objets COM sont généralement implémentés à l'aide de bibliothèques de liens dynamiques (DLL) ; comme les DLL ordinaires, les objets COM exposent certaines méthodes que l'application de l'utilisateur peut appeler pour effectuer toutes les opérations prises en charge.

L'environnement d'exploitation de ce tutoriel : système Windows 7, JavaScript version 1.8.5, ordinateur Dell G3.

Qu'est-ce qu'un objet COM ?

Un objet Component Object Model (COM) est un composant logiciel réutilisable qui utilise les spécifications COM. L'utilisation de la spécification COM garantit que les objets COM fonctionnent correctement et s'intègrent facilement dans vos applications. En fait, COM est fondamentalement équivalent à une boîte noire, qui peut faire beaucoup de travail pour votre application.

Les objets COM sont généralement implémentés à l'aide de bibliothèques de liens dynamiques (DLL). Comme les DLL ordinaires, les objets COM exposent des méthodes que votre application peut appeler pour effectuer toute opération prise en charge. L'interaction entre les applications et les objets COM ressemble un peu à l'interaction entre les applications et les objets C++, mais il existe des différences significatives entre eux.

• Les objets COM implémentent une encapsulation précise. Vous ne pouvez pas simplement créer un objet et appeler arbitrairement ses méthodes publiques. Les méthodes publiques d'un objet COM sont réparties dans un ou plusieurs groupes d'interfaces. Pour utiliser les méthodes, vous devez créer un objet COM et obtenir une interface appropriée pour l'objet COM à partir de l'objet COM. Par exemple : L'interface IDirect3DCubeTexture8 contient une méthode qui vous permet de gérer les ressources du cadre de cube. Toutes les méthodes n'appartenant pas à cette interface sont inaccessibles.

• La création d'objets COM est différente de la création d'objets C++. Il existe plusieurs façons de créer des objets COM, mais toutes impliquent des technologies spécifiques à COM. L'interface de programmation d'application (API) DirectX de Microsoft contient une variété de fonctions et de méthodes d'assistance pour créer la plupart des objets DirectX.

• Vous devez utiliser la technologie spécifique à COM_pour contrôler la durée de vie des objets COM.

• Les objets COM n'ont pas besoin d'être chargés explicitement. Les objets COM sont contenus dans une DLL. Cependant, lorsque vous utilisez cet objet COM, il n'est pas nécessaire de charger explicitement la DLL ou de charger explicitement la bibliothèque statique. Chaque objet COM a un identifiant d'enregistrement unique utilisé pour créer l'objet. COM chargera automatiquement la DLL correcte

• COM est une spécification binaire. Les objets COM peuvent être écrits et accessibles à partir de divers langages. Vous n'avez pas besoin de connaître quoi que ce soit sur le code source de l'objet COM. Par exemple : les applications Microsoft Visual Bisice sont écrites quotidiennement en C++ à l'aide d'objets COM.

Objets et interfaces

Il est important de comprendre la différence entre les objets et les interfaces. Parfois, le nom d'un objet est parfois référencé comme nom de l'interface principale. Mais à proprement parler, ces deux conditions ne sont pas interchangeables.

• ▲Un objet COM peut exposer n'importe quel nombre d'interfaces. Par exemple : tous les objets COM doivent exposer l’interface IUnknown, et ils exposent généralement au moins une interface supplémentaire, et éventuellement plus. Pour utiliser ces méthodes spéciales, vous devez non seulement créer l’objet COM, mais également obtenir le bon pointeur d’interface.

• ▲De nombreux objets peuvent exposer la même interface. Une interface est un ensemble de méthodes qui effectuent des opérations spécifiées. La définition d'une interface précise la syntaxe des méthodes et leurs fonctionnalités. Tout objet COM prenant en charge les opérations spéciales expose une interface appropriée. Certaines interfaces sont hautement spécialisées et ne sont exposées que par un seul objet. La plupart des autres cas sont exposés par plusieurs objets. Un cas très particulier est que l'interface IUnknown doit être exposée par chaque objet COM.

Remarque : Si un objet expose une interface, il doit définir chaque méthode prise en charge dans l'interface. En d’autres termes, toute méthode que vous pouvez appeler doit être sûre qu’elle existe. Cependant, les détails d’implémentation de la méthode peuvent changer d’un objet à l’autre. Par exemple : différents objets peuvent utiliser différents algorithmes pour obtenir les résultats finaux. Parfois, un objet expose une ancienne interface et n’a besoin de prendre en charge qu’un sous-ensemble de méthodes. Vous pouvez toujours appeler les méthodes restantes avec succès, mais elles renverront E_NOTIMPL.

La norme COM exige qu'une fois qu'une interface est publiée, sa définition ne puisse pas être modifiée. Vous ne pouvez pas ajouter de nouvelles méthodes à cette interface existante. Vous devez recréer une nouvelle interface. Une pratique courante consiste à inclure toutes les méthodes de l’ancienne interface dans l’interface de nouvelle génération avant d’ajouter de nouvelles méthodes.

Il est très courant qu'une interface ait plusieurs générations. Souvent, leur contenu est le même, mais leurs détails sont différents. Généralement, un objet peut exposer chaque génération d'interfaces. Cela permet aux anciens programmes de continuer à utiliser l'ancienne interface de l'objet et aux programmes plus récents de profiter des fonctionnalités de la nouvelle interface. Généralement, les familles d'interfaces portent le même nom, suivi d'un entier indiquant la génération. Par exemple : si l'interface d'origine est nommée IMyInterface, les deux générations d'interfaces suivantes sont nommées IMyInterface2 et IMyInterface3. Les entiers utilisent généralement le numéro de version de DirectX.

GUIDS

Les identifiants globalement uniques (GUIDS) sont un élément clé du modèle de programme COM. Dans ses principes les plus fondamentaux, GUIDS est une structure de 128 bits. Cependant, les GUIDS sont créés de manière à garantir qu’il n’y a pas deux GUIDS identiques. COM utilise largement les GUIDS à deux fins principales :

1. Pour identifier de manière unique un objet COM spécifique.
2. Pour marquer de manière unique une interface COM spécifique.

Valeur de retour (HRESULT)

Toutes les méthodes COM renvoient une valeur 32 bits appelée HRESULT. Pour la plupart des méthodes, le HRESULT est en fait une structure contenant deux informations.

1. Que cette méthode réussisse ou échoue.
2. Affichez des informations détaillées sur les opérations prises en charge par la méthode.

La valeur HRESULT renvoyée par certaines méthodes est définie dans Winerror.h. La valeur HRESULT renvoyée par la méthode peut également être des informations spécifiques à l'utilisateur. Ces valeurs sont généralement vérifiées dans la page de référence de la méthode.

Le fait que les appels de méthode sur les objets COM puissent renvoyer une variété de codes indiquant le succès ou l'échec de l'appel signifie que vous devez être très prudent pour tester sa valeur de retour. Par exemple : si la valeur de retour d'un appel de méthode est
S_OK, cela indique que l'appel de méthode a réussi. Si la valeur de retour est S_FAIL, cela indique que l'appel de méthode a échoué. Bien entendu, l'appel de méthode peut également renvoyer d'autres codes indiquant. le succès ou l'échec de l'appel. L'extrait de code suivant illustre qu'il n'est pas sûr d'effectuer un test aussi simple sur le code. La valeur de hr dans le code est la valeur de retour de l'appel de méthode :

    if( hr == E_FAIL )
     {
        //Handle the failure
     }
     else
     {
        //Handle the success
     }

Si ce code renvoie uniquement E_FAIL, cet extrait de code peut bien fonctionner. Cependant, ce n'est pas le cas. Cet appel de méthode peut également renvoyer d'autres valeurs, telles que : E_NOTIMPL, E_INVALIDARG Si le code renvoie ces valeurs, ce segment de code ne les traite pas, et par défaut il indiquera que le programme est en cours d'exécution. normalement, mais le programme réel ne se trompe pas.

Si vous souhaitez connaître des informations plus détaillées sur les appels de méthode, vous devez tester chaque valeur de retour pertinente. Cependant, vous souhaiterez peut-être simplement savoir si l’appel de méthode a réussi. Un bon moyen de tester si un appel de méthode réussit consiste à transmettre la valeur de retour de la méthode aux deux macros suivantes, définies dans le fichier winerror.h.

1. La macro SUCCEEDED renvoie TRUE pour indiquer que l'appel a réussi, et renvoie FALSE pour indiquer que l'appel a échoué.
2. La macro FAILED renvoie TRUE pour indiquer que l'appel a échoué, et renvoie FALSE pour indiquer que l'appel a réussi.

Vous pouvez utiliser la macro FAILED pour modifier l'extrait de code précédent.

    if( FAILED(hr) )
    { 
       //Handle the failure.
    }
    else
    {
       //Handle the success.
    }

L'extrait de code ci-dessus gère les erreurs E_NOTIMPL et E_INVALIDARG.

Bien que la valeur de retour HRESULT de la plupart des méthodes soit une valeur de structure, il existe quelques méthodes où la valeur de retour HRESULT est une simple valeur entière. Cela implique que les méthodes qui renvoient des valeurs entières peuvent toujours être appelées avec succès. Si vous transmettez une valeur de retour de ce type à la macro SUCCESS, la macro renverra toujours TRUE. Un exemple courant est la méthode IUnkoown::Release. La fonction de cette méthode est de libérer (décrémenter) le nombre d'utilisations d'un objet et de renvoyer le nombre d'utilisations actuel de l'objet. Le nombre d'utilisations est utilisé pour identifier la durée de vie d'un objet.

Adresse du pointeur

Si vous avez vu des pages de référence de méthodes COM, vous avez peut-être rencontré des situations comme celles-ci :

   HRESULT CreateDevice(
      . 
      .
      .
      IDirect3DDevice8 **ppReturnedDeviceInterface
      )

Habituellement, tout développeur c ou c++ Pour ceux qui sont familiers avec les pointeurs, COM généralement utilise une norme d'indirection supplémentaire. La norme est la suivante : deux astérisques (**) suivis d'une spécification de type et du nom de la variable avec le préfixe typique "pp". Dans l'exemple précédent, le paramètre ppReturnedDeviceInterface est l'adresse d'un pointeur vers l'interface IDirect3DDevice8.

Contrairement au C++, vous ne pouvez pas accéder directement aux méthodes d'un objet COM, vous devez plutôt obtenir un pointeur vers une interface qui expose les méthodes. La syntaxe d'appel des méthodes d'une interface objet est la même que la syntaxe d'appel des méthodes C++ à l'aide de pointeurs. Par exemple : pour appeler la méthode IMyTnterface::DoSomething, il vous suffit d'utiliser la syntaxe suivante.

   IMyInterfance *pMyTface;
   .
   .
   .
   pMyIface->DoSomething(...) ;

Pour les pointeurs vers les interfaces d'objets COM, vous ne pouvez pas créer directement un pointeur vers l'interface. Vous devez appeler une ou plusieurs autres méthodes pour obtenir ce pointeur. Par exemple : la méthode CreateDevice mentionnée précédemment.

Pour obtenir le pointeur d'interface via cette méthode, vous devez déclarer une variable pour pointer vers l'interface que vous avez demandée. Passez l'adresse de cette variable à la méthode CreateDevice. Autrement dit, vous devez transmettre l'adresse d'une variable à cette méthode. Lorsque cette méthode reviendra, cette variable pointera vers l'interface que vous avez demandée, et vous pourrez accéder aux méthodes de cette interface via ce pointeur.

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéos de programmation ! !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!