拡張可能なソフトウェア（プラグインアーキテクチャ）の設計方法[閉まっている]

StackOverflow https://stackoverflow.com/questions/323202

質問

拡張性のあるソフトウェアの設計方法を説明するリソースが必要です。つまり、他の人が機能を追加するアドオン/プラグインを作成できるようにするためです。

何をお勧めしますか？主題について議論している本はありますか？
私は、短くて要点のあるものを好むでしょう。少しの理論と具体例の束。

特定の言語をターゲットにしているわけではありません。コアとなるアイデアを理解して、あらゆる言語で実装できるようにしたいと考えています。

そして同じ理由で、私は他の誰かが構築したフレームワークを使用しないことを好みます（フレームワークがそれほど高度ではない、つまり too をあまり隠さない限り）そのテーマについて自分自身を教育し、それを実装するためのさまざまな方法で実験したいだけです。さらに、フレームワークは通常、主題に関するユーザーの知識を前提としています。

更新

OOPについて尋ねたり、クラスの継承を許可したりしません。私は、システムにデプロイされるアプリケーションを設計することについて話しているので、デプロイ後にサードパーティのアドオンによって拡張することができます。

たとえば、Notepad ++にはプラグインアーキテクチャがあり、プラグインフォルダーに.dllファイルを配置できます。また、カラーピッキングやスニペット挿入など、存在しないアプリケーションに機能を追加します。他の多くのもの（幅広い機能）。

他のヒント

OSGI は、あなたがやりたいことを行える技術的なフレームワークの実用的な例です。

理論はこちら。

（無料！）本があります。

拡張性とプラグインを記述する機能は、サービスライフサイクル

に対処する必要があります
  • その場でのサービス/プラグインの追加/削除
  • サービス間の依存関係の管理
  • サービスの状態の管理（宣言、インストール、開始、停止など）

OSGIとは

  

モジュールの主な機能の1つは、デプロイメントの単位です。アプリケーションの機能を拡張するために、ビルドまたはダウンロードしてインストールできるものです。

優れた紹介がここにあります、 サービス の中心的な概念（質問に関連し、拡張性の重要なコンポーネントであるサービスに関するいくつかの問題を説明します）。

抽出：

  

サービスなしで非常に多くのアプリケーションを構築できる場合、なぜサービスが重要なのでしょうか？さて、サービスは、ソフトウェアコンポーネントを相互に分離する最もよく知られた方法です。

     

サービスの最も重要な側面の1つは、クラス名ではなくオブジェクトのインスタンスで機能するため、クラス読み込みの問題を大幅に最小限に抑えることです。コンシューマではなく、プロバイダーによって作成されたインスタンス。複雑さの軽減は驚くべきことです

     

サービスは構成を最小限に抑えるだけでなく、共有パッケージの数を大幅に削減します。

競合する2つの目標を達成しようとしています：

  1. ソフトウェアのコンポーネントは、多くのコンポーネントを公開する必要があるため、再利用できます
  2. ソフトウェアのコンポーネントは、ごくわずか自身を公開する必要があるため、再利用できます

説明：コードの再利用を促進するには、既存のクラスを拡張し、それらのメソッドを呼び出すことができる必要があります。メソッドが＆quot; private＆quot;と宣言されている場合、これは不可能です。クラスは「最終」です（そして、拡張することはできません）。したがって、この目標を達成するためには、すべてが公開され、アクセス可能である必要があります。個人データやメソッドはありません。

ソフトウェアの2番目のバージョンをリリースすると、バージョン1のアイデアの多くが明らかに間違っていることがわかります。多くのインターフェイスまたはコード、メソッド名の変更、メソッドの削除、APIの破壊が必要です。これを行うと、多くの人が背を向けます。したがって、ソフトウェアを進化させるために、コンポーネントはコードの再利用を犠牲にして、絶対に必要ではないものを公開してはなりません。

例：SWT StyledTextのカーソル（キャレット）の位置を確認したかった。キャレットは拡張されることを意図していません。これを行うと、コードには「パッケージ内のこのクラスはorg.eclipse.swt」のようなチェックが含まれていることがわかります。そして、多くのメソッドはプライベートで最終的なものであり、その他のものです。すべてがロックされているため、この機能を実装するためにSWTから約28のクラスをプロジェクトにコピーする必要がありました。

SWTは使用するのに最適なフレームワークであり、拡張するには地獄です。

アプリケーションの SOLID 原則を実装します。

1。単一責任の原則： クラスは単一の責任のみを持つ必要があります（つまり、ソフトウェアの仕様の1つの潜在的な変更のみがクラスの仕様に影響を与えることができるはずです

2。オープン/クローズの原則： ソフトウェアエンティティ…は、拡張用にオープン、修正用にクローズ

である必要があります。

3。リスコフ置換の原則： プログラム内のオブジェクトは、そのプログラムの正確性を変更することなく、サブタイプのインスタンスに置き換えられる必要があります

4。インターフェイス分離の原則： 多くのクライアント固有のインターフェイスは、1つの汎用インターフェイスよりも優れています

5。依存関係の反転の原則： 抽象化に依存する必要がある。コンクリートに依存しないでください

Stackoverflowの質問：

単一責任原則の例

オープン/クローズドプリンシパルは良いアイデアですか？

リスコフ置換の原則とは

インターフェース分離の原理-インターフェースへのプログラム

依存性反転の原理とはなぜ重要なのですか？

もちろん、有名なOpen Closed Principleがあります- 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プラグインフレームワーク）があります。

使用する言語に応じて、いくつかのチュートリアル/書籍をお勧めします。これがお役に立てば幸いです。

記事プラグインベースのアプリケーションの作成は、非常に単純な例を使用して、アーキテクチャのさまざまな部分の責任。ソースコードが提供されます（VB.Net）。基本的な概念を理解するのに非常に役立ちました。

チェックアウト＆quot; CAB＆quot; -Microsoftの Composition Application Building blocks Framework 。彼らは「ウェブ版」を持っていると思う。それも...

スマートクライアントアプリケーションの開発を始めました。これらは、私が検討している2つのオプションです。

Microsoftの System.AddIn 名前空間を使用する。非常に有望に見えますが、最終的なソリューションでは少し複雑になる可能性があります。

またはスマートクライアント-Microsoftの複合UIアプリケーションブロック

最近、Composite UI Application BlockとSystem.AddIn名前空間の両方のコンポーネントを使用して独自のコンポーネントを作成することを検討しました。 CABにはソースコードが用意されているため、簡単に拡張できます。最終的な解決策は、を使用して、CABの軽量バージョンになると思いますUnityアプリケーションブロック

プラグインアーキテクチャは、その拡張性と柔軟性のために非常に人気が高まっています。

c ++の場合、Apache httpdサーバーは実際にはプラグインベースですが、モジュールの概念が代わりに使用されます。 Apacheの機能のほとんどは、キャッシュ、書き換え、負荷分散、スレッドモデルなどのモジュールとして実装されます。これは私が見た非常にモジュール式のソフトウェアです。

そしてJavaの場合、Eclipseは間違いなくプラグインベースです。 Eclipseの中核は、プラグインのもう1つの概念であるバンドルを管理するOSGIモジュールシステムです。バンドルは、より少ない労力でモジュールを構築できる拡張ポイントを提供できます。 OSGIで最も複雑なのはその動的な特性です。つまり、実行時にバンドルをインストールまたはアンインストールできます。ストップ・ザ・ワールド症候群はもうありません！

.Netを使用している場合、私たちの調査ではスクリプト作成と合成の2つのアプローチが得られました。

スクリプティング

スクリプトを使用してクラスを調整することにより、クラスが実行できる機能を拡張します。これは、お気に入りの.Net言語でコンパイルされたものを動的言語で公開することを意味します。

調査する価値のあるいくつかのオプション：

構成

.Net 4以上でプロジェクトを開始する場合、Managed Extensibility Framework（MEF）をよく見る必要があります。プラグイン方式でアプリの機能を拡張できます。

  

Managed Extensibility Framework（MEF）は、   の柔軟性、保守性、テスト容易性を向上させる.NET   大規模なアプリケーション。 MEFはサードパーティのプラグインに使用できます   拡張性、または疎結合の利点をもたらすことができます   通常のアプリケーションへのプラグインのようなアーキテクチャ。

マネージアドインフレームワークも良い読み物です。

コメントを残すのに十分な担当者ポイントがないため、これを回答として投稿しています。 SharpDevelopは、C＃/ VB.NET / Booでアプリケーションを開発するためのIDEです。新しいメニュー項目からまったく新しい言語の開発サポートまで、さまざまな方法で拡張できる非常に印象的なアーキテクチャを備えています。

IDEのコアとプラグイン実装の間の接着層として機能するために、XML構成を少し使用します。プラグインの検索、ロード、バージョン管理をすぐに実行できます。新しいプラグインをデプロイするには、新しいxml構成ファイルと必要なアセンブリ（DLL）をコピーして、アプリケーションを再起動するだけです。これについては、「csharpアプリケーションの分析」という本で詳しく読むことができます。オリジナル作成者-こちら。本はそのサイトでは入手できないようですが、まだこちらにあるコピーを見つけました

関連する質問こちら

も見つかりました

車輪を再発明するのではなく、手元のフレームワークを使用してください。 EclipseとNetbeansはどちらもプラグインベースの拡張機能をサポートしています。ただし、Javaで作業する必要があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top