問題タブ [observer-pattern]

そのため、クロージャやメモリ リークを作成せずにデータを渡すことができるように、イベントを設定する方法が必要です。これは私が持っている限りです：

これにより、次の動作が得られます。

私の目標は、私が発火したものだけでなく、フラッシュの発火イベントから渡されるように渡したいカスタムデータを取得することです。たとえば、ムービークリップを loader.COMPLETE イベントと一緒に渡して、結果のビットマップを配置したい場合はどうすればよいでしょうか?

オブザーバー パターンとデリゲートを理解しようとする助けが必要です。このコードを別の Web サイトで見つけたので、実際に何をしているのかを理解しようとしています。誰か助けてくれませんか。

コードを実行すると、"Server is up and running" と "Server is down, We are working on it it will be back soon" の両方のメッセージが表示されます。Main には server.ServerStatus = true; があるため、両方のメッセージを受け取っていると思います。および server.ServerStatus = false です。ただし、server.ServerStatus = true; をコメントアウトすると、実行すると、「サーバーは稼働中です」というメッセージが表示されますが、「サーバーがダウンしています。まもなく復旧します。」というメッセージしか表示されないと予想していました。誰か説明できますか？スーザン

比較的長時間実行されるスキャン手順をトリガーする「スキャン」メソッドを持つ C++ プログラムを開発しています。手順が完了すると、scan メソッドはオブザーバー パターンを使用して結果をオブザーバーに通知します。

スキャンごとに個別のスレッドを作成したいと思います。このようにして、複数のスキャンを同時に実行できます。各スキャン プロセスが完了すると、スキャン メソッドがリスナーに通知するようにします。

ブースト スレッド ライブラリによると、次のようなことができるようです。

これはおおよそ正しいように見えますか? リスナーへの呼び出しをミューテックスする必要がありますか? 結合をなくしても大丈夫ですか？

私は上級レベルの開発者ですが、正式なトレーニングはあまり受けていません。多くのデザインパターンを使用し、開発者としての数年間にそれらが使用されているのを見てきましたが、誰も言いたくありませんでした。「ああ、これはオブザーバーパターン、またはこれはシングルトンパターンです。」

いくつかのデザインパターンを読んで、オブザーバーパターンに出くわしました。これは、.NETFrameworkイベントの動作と非常によく似ているようです。私はこれについて基本的な何かが欠けていますか？

メッセージタイプの基本クラスをパラメーターとして受け取る「通知」メソッドを持つプロセスがあります。メッセージの派生型に基づいて異なる処理をしたいと思います。これは、「プロセス」と呼ばれるメソッドまたはメッセージ タイプに似たものを追加し、ポリモーフィズムを使用して呼び出す必要があるということですか? 特定のメッセージ タイプごとに「通知」を追加する方がよいでしょうか。

詳細: 言語は C++ です。ここでは通知を使用することをお勧めします。これにより、さまざまなメッセージの種類を通知するメソッドが 1 つだけで済みます。コントローラーは、純粋な viual notify(MsgBaseClass) メソッドを指定するリスナー クラスから継承します。新しいメッセージの種類ごとに通知を追加する必要がないので、私は今でもそのアイデアを気に入っています。しかし、コントローラ コード自体では、動的キャストやメッセージ タイプのメッセージへの追加以外に、メッセージ タイプを区別する方法がわかりません。

編集: 訪問者パターンを使用すると思います。これにより、通知用のメソッドを 1 つだけ保持でき、コード内の switch ステートメントを回避できます。「ビジター」インターフェースは、さまざまな派生メッセージ・タイプを処理するためにリスナーが必要とするさまざまなメソッドを指定します。これには、純粋な仮想 "accept(MyMessageTypeVisitor v)" という 1 つのメッセージのみを Message ベース クラスに追加する必要があります。派生メッセージ クラスは、v.visit(this); を使用してそれを実装します。

これはうまくいくはずだと思います。

時間がない人のために、問題を短いバージョンと長いバージョンに分けました。

短縮版：

プロバイダーとコンシューマーのプラグインを備えたシステムのアーキテクチャが必要です。プロバイダーはインターフェイス IProvider を実装し、コンシューマーは IConsumer を実装する必要があります。実行中のアプリケーションは、IProvider と IConsumer のみを認識する必要があります。コンシューマーの実装は、InterfaceX を実装して List を取得するプロバイダーを (ServiceProcessor を使用して) 実行中のアセンブリに問い合わせることができます。これらの IProvider オブジェクトは、InterfaceX が定義するいくつかのイベントにコンシューマーをフックできるように (コンシューマー内で) InterfaceX にキャストする必要があります。これは、実行中のアセンブリがこの InterfaceX 型を認識していない (キャストが失敗する) ため、失敗します。解決策は、プラグインと実行中のアセンブリの両方が参照するアセンブリに InterfaceX を含めることですが、これは新しいプロバイダー/コンシューマーのペアごとに再コンパイルする必要があり、非常に望ましくありません。

助言がありますか？

長いバージョン:

より高いレベルの再利用性を実現するためにプラグインを使用する、ある種の汎用サービスを開発しています。このサービスは、プロバイダーとコンシューマーを使用したある種のオブザーバー パターン実装で構成されています。プロバイダーとコンシューマーの両方が、メイン アプリケーションのプラグインである必要があります。最初に、ソリューションに含まれているプロジェクトをリストして、サービスがどのように機能するかを説明しましょう。

プロジェクト A: すべてのプラグインと基本機能をホストする Windows サービス プロジェクト。デバッグを容易にするために、TestGUI Windows Forms プロジェクトが使用されます。プロジェクト B の ServiceProcessor クラスのインスタンスは、プラグイン関連の作業を行っています。このプロジェクトのサブフォルダー "Consumers" と "Providers" にはサブフォルダーが含まれており、各サブフォルダーにはそれぞれコンシューマーまたはプロバイダーのプラグイン アセンブリが含まれています。

プロジェクト B: ServiceProcessor クラス (すべてのプラグインのロードとプラグイン間のディスパッチなどを行う)、IConsumer および IProvider を保持するクラス ライブラリ。

プロジェクト C: プロジェクト B にリンクされたクラス ライブラリで、TestConsumer (IConsumer を実装) と TestProvider (IProvider を実装) で構成されます。追加のインターフェイス (ITest、それ自体は IProvider から派生) は、TestProvider によって実装されます。

ここでの目標は、Consumer プラグインが ServiceProcessor に (少なくとも IProvider を実装する) プロバイダーを問い合わせることができるようにすることです。返された IProvider オブジェクトは、コンシューマーがイベント ハンドラーを ITest イベントにフックできるように、IConsumer 実装で実装する他のインターフェイス (ITest) にキャストする必要があります。

プロジェクト A が開始されると、コンシューマー プラグインとプロバイダー プラグインを含むサブフォルダーが読み込まれます。以下は、これまでに遭遇し、解決しようとしたいくつかの問題です。

これは、TestProvider と TestConsumer が認識しているメソッドとイベントにのみ適用されるため、プロジェクト C に常駐していたインターフェイス ITest です。一般的な考え方は、プロジェクト A をシンプルに保ち、プラグインが互いに何をするかを意識しないことです。

プロジェクト C の ITest と、IProvider を ITest にキャストする TestConsumer の Initialize メソッドのコード (ITest を実装するオブジェクトが IConsumer オブジェクトとして知られている場合、単一のクラス ライブラリ自体で失敗することはありません) を使用すると、無効なキャスト エラーが発生します。 . このエラーは、プロジェクト A からも参照されるプロジェクト B に ITest インターフェイスを配置することで解決できます。ただし、新しいインターフェイスをビルドするときにプロジェクト A を再コンパイルする必要があるため、これは非常に望ましくありません。

プロバイダーとコンシューマーのみがこのインターフェイスを認識する必要があるため、プロジェクト C のみによって参照される単一のクラス ライブラリに ITest を配置しようとしましたが、成功しませんでした。プラグインをロードすると、CLR は参照されたプロジェクトが見つからないと述べています。これは、現在の AppDomain の AssemblyResolve イベントにフックすることで解決できますが、どういうわけかこれも望ましくないようです。ITest は再びプロジェクト B に戻りました。

プロジェクト C をコンシューマーとプロバイダー用の別のプロジェクトに分割しようとしましたが、どちらもそれ自体がうまく機能するアセンブリを読み込んでいます。両方のアセンブリは、Assemblies コレクションまたは現在の AppDomain に常駐しています。 、Version=1.0.0.0、Culture=neutral、PublicKeyToken=2813de212e2efcd3 アセンブリが見つかりました: Datamex.Projects.Polaris.Testing.Consumers、Version=1.0.0.0、Culture=neutral、PublicKeyToken=ea5901de8cdcb258

コンシューマーはプロバイダーを使用するため、コンシューマーからプロバイダーへの参照が行われました。ここで、AssemblyResolve イベントが再び発生し、次のファイルが必要であることが示されました。

私の質問: これはなぜですか? このファイルはすでにロードされていますよね？IProvider から、実装がわかっているインターフェイスへのキャストが不可能なのはなぜですか? これはおそらく実行中のプログラム自身がこのインターフェースを知らないためだと思いますが、これを動的にロードすることはできないのでしょうか?

私の最終的な目標: コンシューマー プラグインは、Interface x を実装しているプロバイダーを ServiceProcessor に問い合わせます。プロバイダーは、インターフェイス x を認識してアセンブリを実行せずに、このインターフェイス x にキャストできます。

助けてくれる人？

前もってありがとう、エリック

Railsには優れたフィルターのセット（before_validation、before_create、after_saveなど）とオブザーバーのサポートがありますが、フィルターまたはオブザーバーに依存することは計算コストが非常に高いという状況に直面しています。別の方法が必要です。

問題：Webサーバーのヒットを多数のページに記録しています。必要なのは、特定のページがX回以上表示されたときにアクション（たとえば、電子メールを送信する）を実行するトリガーです。ページとヒットの数が非常に多いため、フィルターまたはオブザーバーを使用すると、99％の時間、テストする条件が偽になるため、多くの無駄な時間が発生します。電子メールをすぐに送信する必要はありません（つまり、5〜10分の遅延が許容されます）。

代わりに私が検討しているのは、データベースを5分ごとにスイープし、どのページがX回以上ヒットしたかを確認し、その状態を新しいDBテーブルに記録してから、対応する電子メールを送信する、ある種のプロセスを実装することです。正確にはエレガントではありませんが、機能します。

他の誰かがより良いアイデアを持っていますか？

Property Change オブザーバー パターンをサポートする Bean を作成する人がいることに気付きました。

ただし、Web アプリケーションのステートレスな性質のため、オブザーバー パターンは Web ベースの MVC パターンでは一般的に使用されていないことを読んだことを覚えています。

Web アプリケーションのJava Beanで上記のパターンに従うのは良い方法ですか?