プラグインベースのソフトウェア設計

私はソフトウェア開発者で、ソフトウェア設計のスキルを向上させたいと思っています。ソフトウェアは機能するだけでなく、再利用可能で後の目的に拡張できるようにしっかりしたエレガントなデザインにする必要があると思います。

今、私は特定の問題の良い実践を理解する助けを探しています。実際、私はプラグインを介して拡張可能なソフトウェアを設計する方法を見つけようとしています。

私が持っている質問は次のとおりです。

• プラグインはお互いの機能にアクセスできますか？これは私が推測する依存関係をもたらすでしょう。
• ビデオと音楽を再生するが、後でビデオのステータスを読み取ることができると言うプラグインを介して機能を追加できるマルチメディアソフトウェアを開発したい場合、メインアプリケーションがプラグインに何を提供する必要がありますか（時間、bps、...）そしてそれを表示します。これは、プレーヤー自体がメインプログラムの一部であり、そのような情報を取得するためにプラグインにサービスを提供する必要があるか、またはプレーヤーをプラグインとして開発する方法もある方法で可能性を提供する必要があることを意味しますかそれと対話するために他のプラグインに？

ご覧のとおり、私のソフトウェア開発スキルの向上に努めているため、私の質問は主に学習を目的としています。

ここで助けを見つけて、私の質問に何か問題があれば謝罪したいと思います。

密接にリンクまたは調整されていない複数の寄稿者によって、時間の経過とともに「拡張」したいほとんどすべてのソフトウェアは、何らかのプラグインアーキテクチャの恩恵を受けることができます。一般的な例は、オペレーティングシステム、CADおよびGISツール、描画および画像操作ツール、テキストエディターおよびワードプロセッサー、IDE、Webブラウザー、Webコンテンツ管理システム、プログラミング言語およびフレームワークです。プラグインは拡張可能なシステムの中心です。

プラグインアーキテクチャは通常、ダックタイピングを使用します。建築家は、メソッドの共通セット（例えば、定義されopen、close、play、stop、seek各次に器具を（いずれかの完全または部分的に）プラグイン、など）。一部のメソッドは必須ですが、その他はオプションである場合や、特定の場合にのみ役立つ場合があります。

メインプログラムが最初に実行されると、1つまたは複数の「プラグイン領域」（既知の./pluginsディレクトリなど）にプラグインが存在するかどうかがチェックされます。見つかったものはプログラムにロードされます。

多くの場合、メインプログラムの実行時にプラグインが存在している必要があります。UnixカーネルとApache Webサーバーは通常、この方法で動作します。新しいプラグインを「確認」して使用するには、再起動する必要があります。ただし、プラグインはより動的な場合があります。ここで、メインプログラムは定期的に新しく追加または変更されたプラグインを再チェックします（たとえば、保存されているplugins-last-loadedタイムスタンプをプラグインディレクトリの「最後に変更された」タイムスタンプと比較します）。次に、メインプログラムはプラグインを（再）ロードします。プラグインはすべて、単純/単純な場合、またはより洗練されている場合は、新しい/変更された場合のみです。

多くの場合、「登録」要件があり、各プラグインはコードであるだけでなく、プラグインが全体にどのように統合されるかを伝えるメタデータも含まれています。たとえば、音楽プレーヤープラグインは、再生できるファイルの種類、実行できるプロセッサアーキテクチャ、必要なリソース（割り当てられるメモリの量など）を示すために必要になる場合があります。 、およびメインプログラムがどのプラグインを使用してどのファイルを再生するかを決定するために必要なその他の属性。

プラグインの登録、ロード、およびメインプログラムとの対話のメカニズムは、言語およびフレームワークに固有です。多くの "オーケストレーション"が進行しており、一部の機能はメインプログラムによって処理され、一部はそのプラグインによって処理されます（その一部はかなりの数になる可能性があります）。 「単一のコード」ではなく「システム」としてのプログラムの。

ほとんどの大規模プロジェクトでは、プラグインフレームワークがすでに選択されているか、独自に設計されています。また、プログラムを拡張可能なシステムにするのを簡単にするために設計された多くの汎用プラグインフレームワークもあります。

（質問1への回答）プラグインはお互いの機能を使用できますが、通常、アーキテクトがレイアウトした事前定義のメソッド/ APIを介して使用します。このような「ダックタイピング」を使用すると、相互依存関係を回避でき、特定の機能が「コア」コードとプラグインのどちらによって提供されているかが必ずしも明確ではありません。実際、プラグイン戦略を採用しているため、多くの開発者は「コア」機能さえプラグインとして実装しています。メインプログラムに同梱されているものだけです。プラグインのスパゲッティのもつれを持つことは理想的ではありませんが、他のプラグインの存在を必要とする一部のプラグインを目にすることは珍しくありません。

（質問2への回答）アーキテクトとしてプラグインを提供する主なものは、アーキテクチャです。たとえば、プラグインをセットアップ、登録、呼び出しするための一連のメソッドと、プラグインが動作するための設計と要件のセットです。 。メインプログラムは、実行中に、通常、すべてではないにしても多くの内部データ構造とメソッドをプラグインに公開します。これは明らかにセキュリティ上の問題です。いくつかのサンドボックス化手法を使用できます（現在、ますます使用されています）が、ほとんどの場合、プラグインは「信頼できる」コードであり、メインプログラムの一部であるかのように動作します。

さらに読むために：

• Wikipediaのプラグインページは検討する価値があります。
• Yapsyプラグインフレームワークを使用してエディターを拡張可能にする方法の良いチュートリアル。
• Pythonの必要最小限のプラグインシステムの説明