私は言語固有の答えを探しているわけではなく、プラグイン システムを実装するための一般的なモデルだけを探しています (知りたい場合は、Python を使用しています)。私には独自の考えがあります (コールバックを登録するだけです) が、他にも存在することは知っています。通常は何が使用され、他に何が合理的ですか?
プラグインシステムとはどういう意味ですか? 依存性注入と IOC コンテナーは良い解決策のように思えますか?
つまり、基本プログラムを変更せずに機能を挿入する方法です。私が出発したとき、私はそれを定義するつもりはありませんでした。依存性注入は、私がやっていることには特に適していないように見えますが、それらについてはあまり知りません。
シンプルなプラグイン アーキテクチャでは、プラグインが実装する必要があるすべてのメソッドを含むプラグイン インターフェイスを定義できます。プラグインはアプリケーションからのイベントを処理し、アプリケーションの標準コード、モデル オブジェクトなどを使用して処理を実行できます。実装ではなくオーバーライドしていることを除いて、ASP.NET フォームと基本的に同じです。
この部分は誰も教えてくれませんでしたし、私も専門家ではありませんが、次のように感じています。一般に、プラグインはそのアプリケーションよりも安定性が低いため、アプリケーションは常に制御し、プラグインに定期的に動作する機会のみを与える必要があります。プラグインがオブザーバーを登録できる場合は、デリゲートへの呼び出しを試行/キャッチする必要があります。
Software Engineering Radioの非常に良いエピソードがあり、興味があるかもしれません。
今後の参考のために、Kent Beck の Erich Gamma による優れたContributing to Eclipseに記載されている " Rules for Enablers " (別のリンク) をここに再掲します。
- 招待のルール - 可能な限り、他の人があなたの投稿に貢献できるようにします。
- 遅延読み込みルール - 投稿は必要なときにのみ読み込まれます。
- 安全なプラットフォーム ルール - 拡張ポイントのプロバイダーとして、エクステンダー側の不正行為から身を守る必要があります。
- フェア プレイ ルール - すべてのクライアントは、私も含めて同じルールでプレイします。
- 明示的な拡張ルール - プラットフォームを拡張できる場所を明示的に宣言します。
- ダイバーシティ ルール - 拡張ポイントは複数の拡張を受け入れます。
- Good Fences ルール - コードの外に制御を渡すときは、自分自身を保護してください。
- 明示的な API ルール - API を内部から分離します。
- 安定性ルール - 誰かに貢献を依頼したら、ルールを変更しないでください。
- 防御 API ルール - 信頼できる API のみを明らかにしますが、クライアントが要求した場合は、より多くの API を明らかにする準備をしてください。
setuptoolsPython では、およびによって提供されるエントリポイント システムを使用できますpkg_resources。各エントリ ポイントは、プラグインに関する情報を返す関数にする必要があります (名前、作成者、セットアップおよびティアダウン関数など)。
抽象工場はどうですか？基本プログラムは、抽象的な概念が互いにどのように相互作用するかを定義しますが、呼び出し元は実装を提供する必要があります。