最近の話から始めましょう。 COMテクノロジー（およびその他、ただし本質は同じ）により、コンポーネント開発者はインターフェイスを実装から簡単に分離できました。 これは、アプリケーション開発者にとって、たとえば、コンポーネントを更新するときに古いインターフェースが引き続き機能することを意味していました。 もちろん理論的には。 しかし、実際には、常に「現在の」バージョンを保持する「動的ライブラリの地獄」よりも格好良く見えました。
メカニズムは何ですか？ 彼はとてもシンプルです。
プログラマーインターフェイスコンポーネントが発表
[uuid(a03d1421-b1ec-11d0-8c3a-00c04fc31d2f)] interface ICoolPrinting { void Print(const string fileName); }
次に、プログラマーはこのインターフェースを実装します。 コンパイルされたプログラムは、ユーザーのデバイスにインストールされます。一部のレジストリでは、実行可能モジュールが指定されたUUIDにマップされます。 たとえば、Program Files \ CoolPrinting1_0 \ cool.exeにあります。
このインターフェイスを使用するサードパーティアプリケーションプログラムでは、インターフェイスはUUIDによって同じ「レジストリ」から要求され、必要な機能が呼び出されます。
ICoolPrinting printing = GetInterface(...); printing.Print("c:\myfile.pdf");
コンポーネント開発者が機能を変更するとどうなりますか？
シンプルなバージョンでは、インターフェースが拡張されます。 これは、開発者がボランティアであることを意味します（この素晴らしい言葉の組み合わせを感じてください）：
- 新しいUUIDで新しいICoolPrinting2インターフェイスを作成します。以前のインターフェイスから継承する可能性があります。
- 古い実装を壊さずに実装します。
[uuid(d26d1421-g1ec-12d0-8c3a-12c84ef31d2f)] interface ICoolPrinting2 : ICoolPrinting { bool SetupPrinter(); }
古いバージョンの代わりにインストールされても、新しいバージョンは以前と同じように機能し続けます。 コンポーネントを使用するアプリケーションプログラマは、何もやり直す必要はありません。 つまり、何もありません。 かっこいい？
より複雑なバージョンでは、開発者は古いインターフェイスをサポートしない新しいバージョンをリリースします。 しかし同時に、彼は再び、Program Files \ CoolPrinting2_0のどこかに、古いバージョンの隣に新しいバージョンを同時にインストールする可能性を自発的に提供する必要があります。
この場合、アプリケーションプログラマは何もやり直す必要もありません。
ただし、上記のことは、プログラマーが自分が作成するものを少なくとも大まかに想像している世界でのみ発生します。 そして、彼らの店員は彼らが管理しているビジネスを知っています。 これも起こります。
多くの場合、逆のことが起こります。
最も人道的なバージョンでは、プログラマは新しいインターフェイスを作成せず、古いインターフェイスを単に修正し、同時にそのUUIDを変更します。 UUIDを変更する必要があります。変更しないと、新しいインターフェイスと古いインターフェイスを区別できなくなります。 古いバージョンの代わりに新しいバージョンがインストールされます。
コンポーネントを使用するプログラムはすぐに動作を停止します。 リンクは依然としてUUIDであるため、無効になります。 しかし、インターフェースは以下のことができるため、この問題を回避することは非常に簡単です。
- UUIDではなく、名前による要求。
- 動的関数呼び出しを使用します（実行段階で）。
OleVariant printing = GetInterface("ICoolPrinting"); printing.Print("c:\myfile.pdf");
このような「トリッキーな」テクニックは、コンポーネントプログラマーが古いメソッドとインターフェースを削除するまで機能します。 次に、アプリケーションプログラムの機能を使用しようとすると、エラーが発生します。
状況は、同じデバイスにコンポーネントの2つのバージョンをインストールすることがしばしば不可能であるという事実によって悪化します。 開発者がインターフェイスレベルで互換性を確保できなかった場合、コンポーネントのさまざまなバージョンの競合のない動作を保証するための十分な頭脳を持たないためです。
パックはアプリケーションプログラマーに渡されます。 フォーラムのささやき：「パターンアダプター」。 そして「戦略」ですら。 なぜ驚くのか？ いわゆるデザインパターンの主な目的は、松葉杖と小道具を作成することです。
そして、ここにシンプルで明確な2行のアプリケーションプログラムがあります。コンポーネントへの参照を取得してメソッドを呼び出すと、コンポーネントのバージョン数に応じて、数百行の「テンプレート」コードといくつかのクラスになります。 もちろん、私は彼らをここに連れてきません。
例？ お願いします。 バージョン0.xから現在の2.xまで開発しているPdfCreatorコンポーネントは、この方法で開発されました。 最初に、UUIDを置き換えて古いインターフェイスを編集し、次に古いインターフェイスと互換性はないが既に削除された新しいインターフェイスを作成します。 2つの異なるバージョンを同じコンピューターにインストールすることはできません。
PdfCreatorは無料のオープンソースユーティリティであると主張するかもしれません。 しかし、それは何を変えますか？ 開発者の過失は、「彼らは口の中で贈り物の馬を探してはいけない」ということわざによって補うことができるのでしょうか？ バージョン間の互換性を提供しない完全に商用のコンポーネントの他の例があります。
道徳。 「ここで発明されていない」というルールには正当な理由があります。 少なくとも、手元にソースコードがあると便利です。