[解決済み] 柔軟なプラグイン・アーキテクチャを実現するには？

質問

私の開発現場では、社内プラグインアーキテクチャの利用や構築が繰り返しテーマとなっています。 設定ファイル（XML、.confなど）、継承フレームワーク、データベース情報、ライブラリなど、さまざまな方法でアプローチしてきました。 私の経験では

• データベースは、特にデータと混在している設定情報を保存する場所としては適していません。
• 継承階層でこれを試みるには、コード化されるプラグインに関する知識が必要であり、プラグインアーキテクチャはそれほど動的ではないことを意味します。
• 設定ファイルは、単純な情報を提供するには有効ですが、より複雑な動作を扱うことはできません。
• ライブラリはうまく機能するようだが、一方向の依存関係は慎重に作成する必要がある。

私は、これまで取り組んできたさまざまなアーキテクチャから学ぶと同時に、コミュニティからの提案も求めています。 SOLIDプラグインアーキテクチャをどのように実装しましたか？ 最悪の失敗（または、あなたが見た中で最悪の失敗）は何でしたか？ 新しいプラグインアーキテクチャを実装するとしたら、どうしますか？ あなたが携わったSDKやオープンソースプロジェクトで、良いアーキテクチャの最良の例となるものは何ですか？

自分で見つけた事例をいくつか。

• Perlの モジュール::プラグイン と IOC Perl の依存性注入用
• Springの各種フレームワーク (Java、.NET、Python)を使用して依存性注入を行うことができます。
• An SO質問 Java用のリスト付き（含む サービスプロバイダインタフェース )
• An SO質問 を指すC++用の Dr.ドブスの記事
• An SO質問 ASP.NET MVCの特定のプラグインのアイデアについて

これらの例は、さまざまな言語の強みを活かしているように見えます。 良いプラグインアーキテクチャは、必ずしも言語に縛られているのでしょうか？ プラグインアーキテクチャを作成するためにツールを使用するのが最善なのか、それとも以下のような独自のモデルで行うのが最善なのか？

どのように解決するのか？

これは 回答 というより、有用と思われるコメントや例をたくさん挙げています。

• アプリケーションを拡張可能にする効果的な方法の1つは、その内部をスクリプト言語として公開し、トップレベルのものをすべてその言語で記述することです。これによって、アプリケーションは非常に変更しやすくなり、（プリミティブの選択と実装がうまくいけば）実質的に将来の保証が得られるようになります。この種のものの成功例はEmacsです。私はeclipseのようなプラグインシステムよりこちらの方が好きです。なぜなら、機能を拡張したい場合、APIを学び、別のプラグインを書いたりコンパイルしたりする必要がないからです。カレントバッファに3行のスニペットを書いて、それを評価し、使うことができるのです。非常にスムーズな学習曲線と、非常に満足のいく結果です。

• 私が少し拡張したアプリケーションのひとつが Trac . コンポーネントアーキテクチャを採用しており、この場合、タスクは拡張ポイントをアドバタイズするモジュールに委ねられることになります。そして、これらのポイントに適合する他のコンポーネントを実装し、フローを変更することができます。上のKalkieの提案と少し似ていますね。

• もうひとつ、いいのが py.test . これは "best API is no API" という哲学に従っており、純粋に各レベルで呼び出されるフックに依存しています。これらのフックを規約に従って命名されたファイル/関数で上書きし、動作を変更することができます。このサイトのプラグイン一覧で、どれだけ早く/簡単に実装できるかを見ることができます。

一般的なポイントをいくつか。

• 拡張不可・ユーザー変更不可のコアは、できるだけ小さくするようにしましょう。できることはすべて上位のレイヤーに委譲し、拡張性を高めるようにします。そうすれば、間違った選択をしたときにコアで修正するものが少なくなります。
• 上記のポイントに関連して、プロジェクトの方向性について最初からあまり多くのことを決めるべきではない、ということです。必要最小限のサブセットを実装し、それからプラグインを書き始めましょう。
• スクリプト言語を埋め込む場合は、おもちゃの言語ではなく、一般的なプログラムを書くことができる完全な言語であることを確認すること。 ちょうど を使用します。
• 定型文はできるだけ少なくする。サブクラス化、複雑なAPI、プラグイン登録など、面倒なことはやめましょう。シンプルにすることを心がけ、それが 簡単 というだけでなく 可能 を拡張する必要があります。これによって、プラグインAPIがもっと使われるようになり、エンドユーザーがプラグインを書くようになる。プラグイン開発者だけでなく、py.testはこれをよくやっています。私の知る限りでは、Eclipseもそうです。 ではありません。 .