78

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

おすすめは何ですか？このテーマについて論じている本はありますか？
短くて要領を得たものを好みます。少しの理論とたくさんの具体例。

私は特定の言語をターゲットにしているわけではありません。どの言語でも実装できるように、核となるアイデアを理解したいと思っています。

同じ理由で、私は他の誰かが構築したフレームワークを使用してそれを行うことを好みません (フレームワークが非常に高レベルではない場合、つまり、あまり隠していない場合を除きます)。現時点では、それを実装するためのさまざまな方法を検討し、実験してください。さらに、フレームワークは通常、主題に関するユーザーの知識を前提としています。

アップデート

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

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

4

13 に答える 13

15

OSGIは、目的を実現するための技術フレームワークの実用的な例です。

理論はここにあります。

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

拡張性とプラグインを作成する機能は、サービスのライフサイクルに対処する必要があります

  • その場でサービス/プラグインを追加/削除
  • サービス間の依存関係の管理
  • サービスの状態の管理 (宣言、インストール、開始、停止など)

OSGI とは何ですか?

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

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

エキス：

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

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

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

于 2008-11-27T08:24:04.403 に答える
6

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

1. 単一責任の原則:クラスは単一の責任のみを持つべきです (つまり、ソフトウェアの仕様の潜在的な変更がクラスの仕様に影響を与える可能性があるのは 1 つだけであるべきです)。

2. オープン/クローズの原則:ソフトウェア エンティティは、拡張に対してはオープンである必要がありますが、変更に対してはクローズされている必要があります。

3. Liskov 置換の原則:プログラム内のオブジェクトは、そのプログラムの正確性を変更することなく、サブタイプのインスタンスで置換可能であるべきです。

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

5. 依存性逆転の原則: 抽象化に依存する必要があります。コンクリートに頼らない

スタックオーバーフローの質問:

単一責任原則の例

オープン/クローズの原則は良い考えですか?

リスコフの置換原理とは何ですか?

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

依存性逆転の原則とは何ですか? なぜ重要なのですか?

于 2016-02-13T13:17:31.630 に答える
4

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

  1. ソフトウェアのコンポーネントは、再利用できるように、それ自体の多くを公開する必要があります
  2. ソフトウェアのコンポーネントは、再利用できるように、それ自体をほとんど公開する必要はありません。

説明: コードの再利用を促進するには、既存のクラスを拡張してそれらのメソッドを呼び出せるようにする必要があります。これは、メソッドが「プライベート」と宣言され、クラスが「最終」である (そして拡張できない) 場合には不可能です。したがって、この目標を達成するには、すべてが公開され、アクセス可能でなければなりません。プライベートなデータやメソッドはありません。

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

例: SWT StyledText 内のカーソル (キャレット) の位置を観察したいと考えました。キャレットは拡張するためのものではありません。実行すると、コードに「このクラスはパッケージ org.eclipse.swt にありますか」などのチェックが含まれており、多くのメソッドがプライベートで最終的なものであることがわかります。すべてがロックダウンされているため、この機能を実装するためだけに、SWT から約 28 個のクラスをプロジェクトにコピーする必要がありました。

SWT は、使用するのに優れたフレームワークですが、拡張するのは地獄です。

于 2008-11-27T09:27:33.247 に答える
3

もちろん、有名な Open Closed Principle があります - http://en.wikipedia.org/wiki/Open/closed_principle

于 2008-11-27T08:52:05.173 に答える
2

まあそれは言語に依存します。

  • C/C++ では、実行時にライブラリを開き、エクスポートされた関数を呼び出すことができる loadlibrary 関数があると確信しています。これは通常、C/C++ で行われる方法です。
  • .NET には、loadlibrary に似た (しかしより広い) 機能を提供する Reflection があります。Managed Extension Framework や Mono.Addins など、Reflection 上に構築された完全なライブラリもあり、これらはすでにほとんどの面倒な作業を行ってくれます。
  • Java にはリフレクションもあります。そして、Eclipse IIRC などで使用される JPF (Java Plugin Framework) があります。

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

于 2010-01-25T21:15:39.117 に答える
1

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

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

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

于 2009-05-14T04:21:24.077 に答える
1

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

IDE のコアとプラグインの実装の間の接着層として機能するために、XML 構成が少し使用されます。すぐに使用できるプラグインの検索、ロード、およびバージョン管理を処理します。新しいプラグインを展開するには、新しい xml 構成ファイルと必要なアセンブリ (DLL) をコピーして、アプリケーションを再起動するだけです。詳細については、元の著者 (アプリケーションの Christian Holm、Mike Krüger、Bernhard Spuida) による本「csharp アプリケーションの分析」を参照してください。その本はそのサイトでは入手できないようですが、まだここにあるかもしれないコピーを見つけました

関連する質問hereも見つかりました

于 2016-06-15T23:41:45.673 に答える
1

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

于 2010-01-25T21:10:02.590 に答える
0

チェックアウト "CAB" - Microsoft のComposition Application Building blocks Framework。それの「Web版」もあると思いますが…

于 2008-11-27T08:41:53.337 に答える
0

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

Microsoft のSystem.AddIn名前空間を使用します。非常に有望に見えますが、最終的なソリューションには少し複雑かもしれません。

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

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

于 2008-11-27T08:43:26.017 に答える
0

.Net を使用する場合、私たちの調査では、スクリプティングとコンポジションという 2 つのアプローチが得られました。

スクリプティング

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

検討する価値があるとわかったいくつかのオプション:

構成

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

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

Managed Add-in Frameworkもよく読んでください。

于 2013-02-26T13:11:39.703 に答える
-7

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

于 2008-11-27T08:38:34.297 に答える