プラグインベースのソフトウェア設計
私はソフトウェア開発者であり、ソフトウェア設計のスキルを向上させたいと思っています。ソフトウェアは機能するだけでなく、再利用可能で後の目的に拡張できるように、しっかりしたエレガントなデザインにする必要があると思います。
現在、私は特定の問題の良い実践を理解する助けを探しています。実際、私はプラグインを介して拡張可能なソフトウェアを設計する方法を見つけようとしています。
私の質問は次のとおりです。
- プラグインはお互いの機能にアクセスできますか？これは私が推測する依存関係をもたらすでしょう。
- ビデオと音楽を再生するが、後でビデオのステータスを読み取ることができると言うプラグインを介して機能を追加できるマルチメディアソフトウェアを開発したい場合、メインアプリケーションがプラグインに何を提供する必要がありますか（時間、bps、...）を表示します。これは、プレーヤー自体がメインプログラムの一部であり、そのような情報を取得するためにプラグインにサービスを提供する必要があるか、またはプレーヤーをプラグインとして開発する方法もある方法で可能性を提供する必要があることを意味しますか相互作用する他のプラグインに？
ご覧のとおり、私のソフトウェア開発スキルの向上に努めているため、私の質問は主に学習を目的としています。
私はここで助けを見つけて、私の質問に何か問題があれば謝罪したいと思います。
密接にリンクまたは調整されていない複数の寄稿者によって、時間の経過とともに拡張されることを「望んでいる」ほとんどすべてのソフトウェアは、ある種の plug-in アーキテクチャの恩恵を受けることができます。一般的な例は、オペレーティングシステム、CADおよびGISツール、描画および画像操作ツール、テキストエディターおよびワードプロセッサー、IDE、Webブラウザー、Webコンテンツ管理システム、プログラミング言語およびフレームワークです。プラグインは拡張可能なシステムの主力。
プラグインアーキテクチャでは通常、 ダックタイピング を使用します。アーキテクトは、メソッドの一般的なセット（open、close、play、stop、seekなど）を定義します。次に、各プラグインが実装されます（全体または一部）。一部のメソッドは必須ですが、その他はオプションである場合や、特定の場合にのみ役立つ場合があります。
メインプログラムが最初に実行されると、1つ以上の「プラグイン領域」（既知の./pluginsディレクトリなど）でプラグインの存在を確認します。見つかったものはプログラムにロードされます。
多くの場合、メインプログラムの実行時にプラグインが存在している必要があります。 UnixカーネルとApache Webサーバーは通常、この方法で動作します。新しいプラグインを「確認」して使用するには、再起動する必要があります。ただし、プラグインはより動的な場合があります。ここで、メインプログラムは定期的に新しく追加または変更されたプラグインを再チェックします（たとえば、格納されているplugins-last-loadedタイムスタンプをプラグインディレクトリの「最終変更」タイムスタンプと比較します）。その後、メインプログラムはプラグインを（再）ロードします。プラグインはすべて、単純/単純な場合、またはより洗練されている場合は、新しい/変更された場合のみです。
多くの場合、「登録」要件があり、各プラグインはコードであるだけでなく、プラグインが全体に統合される方法を伝えるいくつかの metadata も含まれます。たとえば、音楽プレーヤープラグインは、再生できるファイルの種類、実行できるプロセッサアーキテクチャ、必要なリソース（割り当てられるメモリの量など）を示すために必要になる場合があります。 、およびメインプログラムがどのプラグインを使用してどのファイルを再生するかを決定するために必要なその他の属性。
プラグインの登録、ロード、およびメインプログラムとの対話のメカニズムは、言語およびフレームワークに固有です。多くの「オーケストレーション」が進行中であり、一部の機能はメインプログラムによって処理され、一部はそのプラグインによって処理されます（その一部はかなりの数になる可能性があります）。拡張性のためにプログラムを設定するには、注意と考慮、およびアーキテクチャビューが必要です。 「単一のコード」ではなく「システム」としてのプログラムの。
ほとんどの大規模プロジェクトでは、プラグインフレームワークがすでに選択されているか、独自に設計されています。プログラムを拡張可能なシステムにするのを簡単にするために設計された多くの一般的なプラグインフレームワークもあります。
（質問1の回答）プラグインはお互いの機能を使用できますが、通常、アーキテクトが定義した事前定義されたメソッド/ APIを介して使用しますでる。このような「ダックタイピング」を使用すると、相互依存関係を回避でき、特定の機能が「コア」コードとプラグインのどちらで提供されているかが必ずしも明確ではありません。実際、プラグイン戦略を採用しているため、多くの開発者は「コア」機能さえプラグインとして実装しています。メインプログラムに同梱されているものだけです。プラグインのスパゲッティのもつれを持つことは理想的ではありませんが、他のプラグインの存在を必要とする一部のプラグインを目にすることは珍しくありません。
（質問2の回答）アーキテクトとして、プラグインを提供する主なものはアーキテクチャです。それらをセットアップ、登録、および呼び出すための一連のメソッド、およびプラグインが動作するための設計と一連の要件。メインプログラムは、実行中に、通常、すべてではないにしても多くの内部データ構造とメソッドをプラグインに公開します。これは明らかにセキュリティ上の問題です。いくつかの sandboxing テクニックを使用できます（そしてますます使用されています）が、プラグインは「信頼できる」コードであり、メインプログラムの一部であるかのように動作します。
さらに読むために：
- Wikipediaのプラグインページ は学ぶ価値があります。
- エディターを拡張可能にする方法の良いウォークスルー Yapsyプラグインフレームワークを使用します。
- Pythonの必要最小限のプラグインシステムの説明