問題タブ [plugin-pattern]

私は Java の初心者です。Martin Fowler のプラグイン パターンを Java で実装する方法を誰かが説明してくれれば幸いです。

前もって感謝します。

私は現在、Webサイトの開発を標準化するために使用されるC＃CMSのようなWebアプリケーションの開発に携わっています。当初から、多くのCMSシステムを苦しめる複雑さとメニュー/オプションの過負荷を回避するために、コアを可能な限りシンプルに保つという考え方がありました。この単純なコアが完成し、非常にうまく機能しています。

システムは、特定のプロジェクトのニーズに合わせてコア機能を拡張するプラグインまたはモジュールを受け入れることができると考えました。これらは、プロジェクト間で再利用することもできます。たとえば、基本的なカタログと買い物かごが必要になる場合があります。このような拡張機能のすべてのコードは、個別のアセンブリに含める必要があります。このライブラリから独自の管理インターフェイスとフロントエンドコードを提供できる必要があります。システムは利用可能なプラグインを検索し、管理者ユーザーに機能を有効/無効にするオプションを提供する必要があります。（これはすべてWordPressプラグインに非常によく似ています）

この問題を正しい方法で攻撃することが重要であるため、私は飛び込む前に可能な限りデューデリジェンスを実行しようとしています。

プラグインパターン（http://msdn.microsoft.com/en-us/library/ms972962.aspx）を認識しており、その使用法に関する記事をいくつか読んだことがあります。それは合理的なようですが、それが必ずしもこの状況に適した/最良の手法であるとは確信していません。アプリケーション（画像/音声操作、数学など）の処理に適しているようです。

この種のUI拡張機能を実現するための他のオプションはありますか？それとも、プラグインパターンは進むべき道ですか？

この目的でプラグインパターンを使用することを説明する記事へのリンクがあれば、私も興味がありますか？

jQueryプラグインの設計パターンがどのように行われ、どのように機能するかを概念化する（そしてできれば理解してもらう）ために、誰かがjavascriptで非常に単純な基本的な例を書き留めてもらえますか?

jQuery のプラグインを作成する方法には興味がありません (したがって、jQuery コードはまったくありません)。プラグインの概念がどのように行われるかを説明するための簡単な説明 (おそらく少しの Javascript コードを使用) に興味があります。

jQueryコードを読みに行くように返信しないでください。試してみましたが、複雑すぎます。そうでなければ、ここに質問を投稿しなかったでしょう。

ありがとう！

プラグイン パターンで実現されると思われるアプリケーションがあります。
プラグインは dll ファイルにあり、コマンド ライン経由でユーザーから指定されたパラメーターに応じて、その場で読み込みます。つまり、ユーザーが plugin1 を使用したい場合、アプリの実行時にコマンドラインでその名前をパラメーターとして入力し、その場でロードすることになっています。
私はプラグイン パターンを使用しているので、すべてのプラグイン クラスが実装するインターフェイスがあります (C++ で動作するため、抽象クラスです)。
私のジレンマは、インターフェイス クラスをどこに配置するかです。dll をビルドするには、すべての dll でインターフェイスを宣言する必要があります。
インターフェイスを変更する必要がある場合に、すべての dll でインターフェイスを変更する必要を避けたいと考えています。
一方、メイン アプリでインターフェイス クラスを宣言すると、DLL はコンパイルおよびビルドされませんか?
インターフェイス クラスを dll から抽出してメイン アプリに配置する方法についての提案はありますか。そのコードを変更したい場合、多数の場所 (つまり、すべての dll) で変更する必要はありません。 ）。

前もって感謝します、

乾杯

オブジェクト指向のJavaScriptコードの記述とjQueryプラグインの開発に関する多くの記事がありますが、これまでのところ、それらがどのように機能するかを理解しており、独自のプラグインを作成できます。

ただし、すべての記事に1つの問題があります（公式のプラグインオーサリングガイド-http://docs.jquery.com/Plugins/Authoringでも） -これらのすべてのパターンは「ライブ」をサポートしていません。

たとえば、このパターンを見てみましょう-http ://www.virgentech.com/blog/2009/10/building-object-Oriented-jquery-plugin.html

jQueryの一致するオブジェクトごとに新しい「MyPlugin」インスタンスが作成されます。

将来追加される要素で機能するように（可能であれば）変更するにはどうすればよいですか？

ありがとう

asp.netmvcを使用して「プラグイン」フレームワークを実装する方法を理解しようとしています。いくつか読んだところ、多くの人がasp.netmvcのプラグインフレームワークにMEFを推奨していることがわかりました。

リンク： http： //blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx

ただし、ViewModels他の基本的なMVCコンポーネントを使用できないという問題が発生しています。私は今、私が少し頭を抱えていることを知っています。チュートリアル、本、実際のプラグインパターンの例を探していますが、何も見つかりません。そして、私が見つけたMEFドキュメントのほとんどは、私の頭（codeplex）を少し超えているか、MEFが.NET4でリリースされる数年前のものです。

どんな方向性/助けも大歓迎です!!! MEF限定の情報は探していません。MEFは実際の.NETFrameworkの一部であるため、私はMEFに焦点を合わせています。それが私が探しているものを処理できるかどうかはわかりません。

このテーマに関する中級レベルのリソースをお勧めしますか？

問題:
ファイルを受け取り、翻訳し、実行するフレームワークを構築しています。フレームワークはあらゆる種類のファイルを処理できる必要があります。この目的のために、ファイルを変換および実行するためのクラスとメソッドを含む DLL をアップロードする方法を提供しました。私が探しているのは、プラグイン インターフェイスを定義する最良の方法です

解決策 A:
公開されているインターフェイスのセットを定義します。プラグインはこれらのインターフェースを実装する必要があります。

解決策 B:
公開されているいくつかの抽象クラスを定義します。プラグインは、これらのクラスの抽象メソッドを継承およびオーバーライドする必要があります。

ソリューション C: rcravens
コード内でインターフェイスを渡し、プラグインの拡張性を可能にするために公開されている抽象クラスを作成します。選択
このソリューションは、基本的な実装 (この場合は便利) を可能にするという理由だけで、インターフェースよりも先に選択されました。コード内でのモックを可能にするという理由だけで、抽象クラスの前に選択されました。コンポジション フレームワークは優れていますが、制限された拡張性のみが必要なこのアプリケーションのような軽量のものには少し過剰です。

ソリューション D: JayとChris Shain
構成フレームワーク ( Managed Extensibility Framework(MEF)など) を実装し、それを中心に構築する

新しい解決策があれば、このリストに追加します。答えは、解決策を最も正当化できる人物に与えられます(利点と制限がある可能性があります)。

事前に感謝します、
Tech Test Dude

jQueryプラグインに取り組んでいますが、jQueryのベストプラクティスのデフォルトとオプション、データと名前空間の手法を組み合わせたデザインパターンに問題があります。これが私のコードの抽象化されたバージョンです：

そのコードを最新バージョンのjQueryで実行すると、initとmethodname関数の両方を呼び出し、それぞれにsettingsとdataオブジェクトを記録していることがわかります。呼び出しでは、とのmethodname両方にアクセスできますsettingsがdata、init呼び出し自体では、dataオブジェクトは未定義を返します。21行目のスクリプトにブレークポイントを設定すると、コンソールでdataオブジェクトをコールバックできます。$this.data('pluginname')誰かが私がここで間違っていることを見ますか？data.key3init、functionの中に書くことができるはずですよね？

他の場所で見たものに適合しないプラグインパターンを実装する必要があり、それを間違った方法で見ているのか、他の誰かが同じ問題に遭遇した可能性があるのか​​疑問に思っています。解決策があります。

基本的に、コアアセンブリと、それに接続する多数のモジュールで構成されるシステムがあります。一部のモジュールは他のモジュールに依存していますが、これらの依存関係の一部を時々削除または置換する必要が生じているため、可能な限り再コンパイルを避けたいと思います。

システムは特注のCMSであり、モジュールはCMS内の機能を提供するプラグインです。たとえば、コメントモジュールと、コメント機能を含めることができるニュースモジュール、ブログモジュールなどのいくつかのコンテンツモジュールがあります。私の問題は、一部の顧客がコメントモジュールを購入しない可能性があることです。そのため、依存モジュールがコメントモジュールの存在に依存しないようにする方法を見つける必要があり、場合によっては、の変更バージョンに対応する必要があります。コメントモジュール。

実行時にモジュールをロードしています。現在、モジュール間の相互依存を回避するために、コアCMSアセンブリに保持されているインターフェイスを使用してこれを処理しています。私の懸念は、依存関係が存在する可能性のある新しいモジュールを作成するたびにコアCMSアセンブリを変更する必要がないようにするために、インターフェイスやそれらのインターフェイスの実装よりもはるかに緩いものを使用する必要があることです。

私は次のことを考えています：

• コアアセンブリには、共有入出力メッセージの登録と登録解除を可能にするオブジェクトが含まれています（たとえば、「Comments.AddComment」または「Comments.ListComments」）。
• モジュールが読み込まれると、必要なサービスと提供するサービスがアドバタイズされます（たとえば、ニュースモジュールには「Comments.AddComment」メッセージが必要であり、コメントモジュールのバリアントには「Comments.AddComment」メッセージが表示されます）。
• これらのメッセージに渡されるオブジェクトまたはデータは、非常に緩い基本クラスから継承するか、コアアセンブリ内に含まれるタイプIDictionaryのプロパティを公開するインターフェイスを実装します。または、メッセージのコントラクトにはオブジェクト型のパラメーターのみが必要であり、プロバイダー/コンシューマーから匿名オブジェクトを渡します。

欠点は明らかに強い型付けを失うことですが、プラスは、厳密なインターフェイスの実装に依存しないこと、または実行時に存在しない可能性のあるモジュールを含める必要がないことです。

プラグインはReflectionを介してロードされ、参照されるアセンブリをチェックし、特定のインターフェイスを実装するクラスを探します。.NET 3.5に制限されているため、MEFと動的型はオプションではありません。

誰かがこの問題についてもっと良いこと、またはおそらく別の考え方を提案できますか？

Android アプリケーションにプラグイン パターンを実装します。

今私は作成しました：

外部プラグインには、たとえば

PluginReceiverクラスには、などのいくつかのメソッドも含まれてgetIconいgetNameます。

SmsPluginReceiverAndroidManifest.xml指定されたインテント フィルター アクションを持つレシーバーとして登録されます。

メインアプリケーションでは、利用可能なすべてのプラグインを次のように検索していますPackageManager:

そして私は1つのResolveInfoオブジェクトを手に入れました。

どうすればいいのかまったくわかりません-SmsPluginReceiverデータ（アイコン、名前など）にアクセスする方法は？