1

CIでは、共有ライブラリに次のインターフェイスを実装させることでプラグインを作成できます。

extern "C" int initialize(SomeArgument * state);
extern "C" int shutdown(SomeArgument * state);

明らかに、これは非常に高レベルのインターフェースですが、私はそれが重要な意味を持っていると思います。リフレクションの良い使い方はプラグインを書くことだと聞きましたが、なぜそれが私がここに持っているものよりも優れているのでしょうか？このようなインターフェースを使用すると、次の利点があります。

  • より高速（メソッドの検索と間接的な呼び出しの両方で、リフレクションは高速ではありません）
  • メモリ（リフレクションにはメモリオーバーヘッドがあります）
  • 簡単です（プラグインの入口/出口ポイントは直感的にわかります）

私は何かが足りないのですか？

4

5 に答える 5

0

1つの意見は、プラグインは、リストした「C」インターフェイスとは異なり、EclipseやVisualStudio.NETなどのIDEにうまく統合されて機能するというものです。たとえば、IDE内では、ツールはパラメータを含むすべてのパブリック/公開関数を一覧表示できます。最近のオブジェクト指向プログラミングでは、インターフェースはより複雑になっています。プラグインがIDEでうまく機能する場合、インターフェースははるかに明確に理解されます。

一部のプラグインはGUIベースであり、イベント/リスナーを公開します。これは「C」インターフェースよりも複雑です。それはすべて理にかなっていますか？

于 2012-05-14T22:15:49.990 に答える
0

インターフェイスを介してリフレクションを使用する必要がある明確な理由はなく、リフレクションを介してインターフェイスを使用する理由はたくさんあると思います。はっきりしていると思います。

回答を提供してくださった皆様、ありがとうございました！

于 2012-05-15T16:47:38.873 に答える
0
  1. リフレクションを使用して、クラス静的変数を読み取り、クラス静的メソッドを呼び出すことができます。クラス静的変数の読み取りを使用すると、最初にインスタンスを作成しなくても、プラグインに関する情報（バージョン番号など）を取得できます。クラス静的メソッドを呼び出すことで、プラグインをシングルトンとして実装できます。
  2. プラグインがシングルトンでない場合は、リフレクションを使用して引数を受け入れるコンストラクターを呼び出すことができますが、リフレクションを使用しない場合は、引数なしのコンストラクターのみを呼び出すことができます。
于 2012-05-15T07:15:31.873 に答える
0

私が考えることができる主な利点はplugins、実行時に動的に（リフレクションを介して）ロードされるプロパティファイルを使用できることです。

または、特定のディレクトリでプラグインをスキャンし、リフレクションを介してプラグインを自動的にロード/インスタンス化することもできます。

もちろん、これらのプラグインが特定のインターフェースを実装するべきではないという意味ではありません。

于 2012-05-14T21:38:05.203 に答える
0

この便利なプラグインインターフェースを検討してください。

public interface EntityAuditor {

    <T> void auditEntity(Class<T> clazz, T entity);

}

Tは法的に注釈が付けられたJPA@Entityでなければならないという制約がある場合、実行時例外がスローされます。プラグインに監査させたいシステム内のすべてのエンティティが従わなければならないある種のインターフェースを作成することは実際には実用的ではありません。プラグインが必要とする情報を返すある種の「監査可能なエンティティ」インターフェイスを使用することもできますが、監査の方法と内容について、エンティティ内に実装と結合があります。プラグインの要点は、それを抽象化し、エンティティに変更を加えることなく、監査の方法/内容を変更できるようにすることです。

于 2012-05-14T22:04:53.177 に答える