インターフェースのバージョン番号

提供: RAD Studio
移動先: 案内検索

Tools API を使用した IDE の拡張 への移動

IOTAMessageServices など、一部のインターフェイスの宣言に注目すると、似た名前の別のインターフェイスから継承していることが分かります。たとえば、IOTAMessageServices50 は、IOTAMessageServices40 から継承しています。このようにバージョン番号を利用すると、Delphi のリリース間で発生する変更から、コードを分離することができます。

Tools API は、COM の基本原則に従っているため、インターフェイスとその GUID が変更されることはありません。新しいリリースでインターフェイスに機能をすると、Tools API は、その古いインターフェイスから継承した新しいインターフェイスを宣言します。古い変更のないインターフェイスについては、今までと同じ GUID が維持されます。そして新しいインターフェイスは、まったく新しい GUID を取得します。このため、古い GUID を使用する古いウィザードも、引き続き動作します。

Tools API はまた、インターフェイス名を変更して、ソースコードの互換性の維持に努めます。これがどのように作用するかを確認するには、Tools API における 2 種類のインターフェイス(Embarcadero 実装とユーザー実装)を区別することが大切です。IDE がインターフェイスを実装している場合、その名前はインターフェイスの最新バージョンを維持し続けます。新しい機能は、既存のコードに影響を与えません。古いインターフェイスには、古いバージョン番号が付いています。

しかし、ユーザー実装のインターフェイスの場合、基底インターフェイス内にメンバー関数を追加すると、ユーザーのコードにおいても新しい関数を必要とします。このため、名前は古いインターフェイスに維持され、新しいインターフェイスではバージョン番号を後ろにつける傾向があります。

たとえば、メッセージ サービスを考えてみましょう。Delphi 6 では、新しい機能「メッセージ グループ」が導入されています。このため、基本メッセージ サービス インターフェイスには、新しいメッセージ関数が必要でした。これらの関数は、IOTAMessageServices という名前を保持している、新しいインターフェイス クラスで宣言されています。古いメッセージ サービス インターフェイスは、IOTAMessageServices50(バージョン 5 として)という名前に変更されます。古い IOTAMessageServices の GUID が、新しい IOTAMessageServices50 の GUID と同一になります。これらのメンバー関数が同一のためです。

IOTAIDENotifier を、ユーザー実装インターフェイスの例として考えてみましょう。Delphi 5 では、新しいオーバーロード関数、AfterCompileBeforeCompile が追加されました。IOTAIDENotifier を使用する既存のコードを変更する必要はありませんが、新しい機能を必要とする新しいコードでは、IOTAIDENotifier50 から継承した機能を新たにオーバーライドするために変更しなけれなりません。バージョン 6 では機能を追加していませんので、使用している現行バージョンは、IOTAIDENotifier50 です。

概して、新しいコードを記述する際には、最下層の継承クラスを使用します。Delphi の新リリースにおいて、単に既存のウィザードを再コンパイルする場合には、ソース コードはそのままにしておきます。

関連項目