Numéros de version de l'interface

De RAD Studio
Aller à : navigation, rechercher

Remonter à Accès aux services de l'API Tools


Si vous regardez attentivement la déclaration de certaines interfaces, comme IOTAMessageServices, vous constaterez qu'elle hérite d'une autre interface de nom similaire, comme IOTAMessageServices50, qui hérite à son tour de IOTAMessageServices40. Cette utilisation des numéros de version isole votre code des changements entre les versions de Delphi.

L'API Tools utilise le même principe de base que COM, à savoir qu'une interface et son GUID ne changent jamais. Si une nouvelle version ajoute des caractéristiques à une interface, l'API Tools déclare une nouvelle interface qui hérite de l'ancienne. Le GUID ne change pas et reste attaché à l'ancienne interface qui n'est pas modifiée. La nouvelle interface obtient un nouveau GUID. Les anciens experts qui utilisent les anciens GUID continuent à fonctionner.

L'API Tools modifie également le nom des interfaces afin de préserver la compatibilité du code source. Pour comprendre comment cela fonctionne, il est important de faire la distinction entre les deux types d'interfaces de l'API Tools : implémentées par Borland ou implémentées par l'utilisateur. Si l'EDI implémente l'interface, le nom reste attaché à la version la plus récente de l'interface. La nouvelle fonctionnalité n'affecte pas le code existant. L'ancien numéro de version est alors ajouté au nom des anciennes interfaces.

Par contre, dans le cas d'une interface implémentée par l'utilisateur, les nouvelles fonctions membre de l'interface de base nécessitent de nouvelles fonctions dans votre code. Dans ce cas, le nom reste attaché à l'ancienne interface, et le numéro de version est ajouté à la fin du nom de la nouvelle version.

Soit, par exemple, les services de message. Delphi 6 introduit une nouvelle caractéristique : les groupes de messages. De ce fait, l'interface de base des messages a besoin de nouvelles fonctions membre. Ces fonctions sont déclarées dans une nouvelle classe d'interface, qui conserve le nom IOTAMessageServices. L'ancienne interface des services de message est renommée en IOTAMessageServices50 (pour la version 5). Le GUID de l'ancienne interface IOTAMessageServices est le même que le GUID de la nouvelle interface IOTAMessageServices50 car les fonctions membre sont les mêmes.

Prenons IOTAIDENotifier comme exemple d'une interface implémentée par l'utilisateur. Delphi 5 ajoute de nouvelles fonctions : AfterCompile et BeforeCompile. Le code existant qui utilisait IOTAIDENotifier n'a pas à être modifié, mais le nouveau code utilisant les nouvelles fonctionnalités doit être modifié pour redéfinir les nouvelles fonctions héritées de IOTAIDENotifier50. La version 6 n'a pas ajouté de nouvelles fonctions, la version en cours à utiliser est donc IOTAIDENotifier50.

Le principe de base consiste à utiliser la classe la plus dérivée lors de l'écriture de nouveau code. Ne changez rien au code si vous recompilez simplement un expert existant avec une nouvelle version de Delphi.

Voir aussi