拡張可能なソフトウェア（プラグインアーキテクチャ）の設計方法
ソフトウェアを拡張可能に設計する方法、つまり他の人が機能を追加するアドオン/プラグインを作成できるようにする方法について説明するリソースが必要です。
おすすめは何ですか？主題について説明している本はありますか？
私は、短くて要点のあるものを好むでしょう。少しの理論と具体例の束。
特定の言語をターゲットにしているわけではありません。コアとなるアイデアを理解して、どの言語でも実装できるようにしたいと思っています。
そして、同じ理由で、私は他の誰かが構築したフレームワークを使用しないことを好みます（フレームワークが非常に高レベルではない、つまりtooずっと）、現時点では、そのテーマについて自分自身を教育し、それを実装するためのさまざまな方法で実験したいだけです。さらに、フレームワークは通常、主題に関するユーザーの知識を前提としています。
[〜＃〜] update [〜＃〜]
OOPを要求したり、クラスの継承を許可したりしません。サードパーティによって拡張できるように、システムにデプロイされるアプリケーションの設計について話している展開後のアドオン。
たとえば、Notepad ++には、プラグインフォルダーに.dllファイルを配置できるプラグインアーキテクチャがあり、カラーピッキングやスニペット挿入など、存在しないアプリケーションに機能を追加します。 （幅広い機能）。
.NETの場合は、CodeProjectで VBScriptを使用した.NETアプリケーションのスクリプト作成 を試してください。そこには具体的な例がたくさんあります。
以下は、さまざまなアプリケーション拡張技術を実装しているサイトです
[〜＃〜] osgi [〜＃〜] は、あなたがやりたいことを行えるようにする技術的なフレームワークの良い実用的な例です。
理論はこちら です。
拡張性とプラグインを記述する機能は、サービスライフサイクルに対応する必要があります
- その場でサービス/プラグインを追加/削除
- サービス間の依存関係の管理
- サービスの状態の管理（宣言、インストール、開始、停止など）
モジュールの主な機能の1つは、デプロイメントの単位としてです。アプリケーションの機能を拡張するために、ビルドまたはダウンロードしてインストールできるものです。
ここで 良い紹介を見つけます 、service（これはあなたの質問に関連し、サービスに関するいくつかの問題を説明します） 、拡張性の重要なコンポーネント）。
エキス：
サービスなしで非常に多くのアプリケーションを構築できるのに、なぜサービスがそれほど重要なのでしょうか？さて、サービスは、ソフトウェアコンポーネントを相互に分離する最もよく知られた方法です。
サービスの最も重要な側面の1つは、クラス名ではなくオブジェクトのインスタンスで機能するため、クラスの読み込みの問題を大幅に最小限に抑えることです。コンシューマではなく、プロバイダーによって作成されたインスタンス。複雑さの軽減は非常に驚くべきことです
サービスは構成を最小限に抑えるだけでなく、共有パッケージの数を大幅に削減します。
[〜＃〜] solid [〜＃〜] 原則をアプリケーションに実装します。
1。単一の責任の原則：クラスは単一の責任のみを持つ必要があります（つまり、ソフトウェア仕様の1つの潜在的な変更のみがクラスの仕様に影響を与えることができます）
2.オープン/クローズド原則：ソフトウェアエンティティ…は拡張のために開きますが、変更のために閉じます
3。リスコフ置換の原則：プログラム内のオブジェクトは、そのプログラムの正確性を変更することなく、サブタイプのインスタンスに置き換えられる必要があります
4。インターフェイス分離の原則：多くのクライアント固有のインターフェイスは、1つの汎用インターフェイスよりも優れています
5。依存関係の反転の原則：1つはAbstractionsに依存する必要があります。結石に依存しないでください
Stackoverflowの質問：
2つの競合する目標を達成しようとしています。
- ソフトウェアのコンポーネントはalotを公開する必要があるため、再利用できます
- ソフトウェアのコンポーネントは、再利用できるように、ごくわずかを公開する必要があります
説明：コードの再利用を促進するには、既存のクラスを拡張し、それらのメソッドを呼び出すことができる必要があります。これは、メソッドが「プライベート」であり、クラスが「最終」であると宣言されている場合（および拡張できない場合）は不可能です。したがって、この目標を達成するには、すべてのものが公開され、アクセス可能である必要があります。個人データやメソッドはありません。
ソフトウェアの2番目のバージョンをリリースすると、バージョン1のアイデアの多くが明らかに間違っていることがわかります。多くのインターフェイスまたはコード、メソッド名を変更し、メソッドを削除し、APIを壊す必要があります。これを行うと、多くの人が背を向けます。したがって、ソフトウェアを進化させるために、コンポーネントは絶対に必要ではないものを公開してはなりません-コードの再利用を犠牲にして。
例：SWT StyledTextのカーソル（キャレット）の位置を観察したかった。キャレットは拡張されることを意図していません。実行すると、コードには「パッケージorg.Eclipse.swtにこのクラスがある」などのチェックが含まれ、多くのメソッドがprivateおよびfinalなどであることがわかります。すべてがロックされているため、この機能を実装するためにSWTから約28のクラスをプロジェクトにコピーする必要がありました。
SWTは、使用するのに最適なフレームワークであり、拡張するのに非常に役立ちます。
もちろん、有名なオープンクローズド原則があります- http://en.wikipedia.org/wiki/Open/closed_principle
まあ、それは言語に依存します。
- C/C++には、実行時にライブラリを開き、エクスポートされた関数を呼び出すことができるloadlibrary関数があると確信しています。これは通常、C/C++で行われる方法です。
- .NETには、Reflectionがあります。これは、loadlibraryに似た（ただし、より広い）オファーを提供します。また、Managed Extension FrameworkやMono.AddinsのようなReflection上に構築されたライブラリ全体があります。
- Javaには、リフレクションもあります。そして、Eclipse IIRCのようなもので使用されるJPF（Javaプラグインフレームワーク）があります。
使用する言語に応じて、いくつかのチュートリアル/書籍をお勧めします。これがお役に立てば幸いです。
記事 Writing Plugin-Based Applications は、非常に簡単な例を使用して、アーキテクチャのさまざまな部分の責任を明確に説明しています。ソースコードが提供されます（VB.Net）。基本的な概念を理解するのに非常に役立ちました。
コメントを残すのに十分な担当者ポイントがないので、これを回答として投稿しています。 SharpDevelopは、C＃/ VB.NET/Booでアプリケーションを開発するためのIDEです。新しいメニュー項目から開発まで、さまざまな方法で拡張できる非常に印象的なアーキテクチャを備えています。まったく新しい言語のサポート。
少しのXML構成を使用して、IDEのコアとプラグインの実装の間の接着層として機能します。プラグインの検索、ロード、およびバージョン管理をすぐに処理します。新しいプラグインのデプロイこれは、新しいxml構成ファイルと必要なアセンブリ（DLL）をコピーしてアプリケーションを再起動するだけの問題です。詳細については、元の著者-Christian Holm、Mikeの書籍「Disshating a csharp application」を参照してください。 here からのアプリケーションのKrüger、Bernhard Spuida。本はそのサイトで利用可能ではないようですが、私はまだ周りにあるかもしれないコピーを見つけました here
関連する質問も見つかりました here
.Netを使用する場合、私たちの調査では、スクリプト作成と構成という2つのアプローチが得られました。
スクリプティング
スクリプトを使用してクラスを調整することにより、クラスで実行できる機能を拡張します。これは、お気に入りの.Net言語でコンパイルされたものを動的言語で公開することを意味します。
調査する価値のあるいくつかのオプション：
- IronPython
- IronRuby
- JavaScript： Jint 、 Jurassic 、および JavaScript .Net は出発点として適しています。
- Script.Net ->これは私たちの注意を呼ぶ最初のものでした。
組成
.Net 4以降でプロジェクトを開始する場合、Managed Extensibility Framework（MEF）をよく見る必要があります。プラグイン方式でアプリの機能を拡張できます。
Managed Extensibility Framework（MEF）は、大規模アプリケーションの柔軟性、保守性、およびテスト容易性を向上させる.NETの構成レイヤーです。 MEFは、サードパーティのプラグインの拡張性に使用できます。または、疎結合プラグインのようなアーキテクチャの利点を通常のアプリケーションにもたらすことができます。
マネージアドインフレームワーク もお読みください。
プラグインアーキテクチャは、その拡張性と柔軟性のために非常に人気が高まっています。
C++の場合、Apache httpdサーバーは実際にはプラグインベースですが、代わりにモジュールの概念が使用されます。ほとんどのApache機能は、キャッシュ、書き換え、負荷分散、スレッドモデルなどのモジュールとして実装されます。それは私が今まで見た非常にモジュール式のソフトウェアです。
Javaの場合、Eclipseは間違いなくプラグインベースです。 Eclipseのコアは、プラグインのもう1つの概念であるバンドルを管理するOSGIモジュールシステムです。バンドルは、より少ない労力でモジュールを構築できる拡張ポイントを提供できます。 OSGIで最も複雑なのは動的特性です。つまり、実行時にバンドルをインストールまたはアンインストールできます。もう世界を止める症候群はありません！
チェックアウト "CAB"-MicrosoftのComposition Application Building blocks Framework。彼らはそれの「ウェブ版」も持っていると思う...
スマートクライアントアプリケーションの開発を始めました。これらは、私が検討している2つのオプションです。
Microsoftの System.AddIn 名前空間を使用します。非常に有望に見えますが、最終的なソリューションでは少し複雑になる可能性があります。
またはスマートクライアント- Composite UI Application Block Microsoftから
最近、Composite UI Application BlockとSystem.AddIn名前空間の両方のコンポーネントを使用して独自のコンポーネントを作成することを検討しました。 CABにはソースコードが用意されているため、簡単に拡張できます。最終的なソリューションは、CABの軽量バージョンであり、間違いなく nity Application Block