問題タブ [observer-pattern]

PrototypeJS 用に現在存在するこれらのウィンドウはどれも私のニーズに合わないため、独自の「モーダル」ウィンドウを作成しようとしています。

問題は、ビューポートの高さと幅の変更について document.documentElement を観察することです (または、Quirks/Standard モードによっては document.body)。

質問に答えているSOのように、誰かがその質問に答えた場合、通知が表示されます（AJAX経由？）。これをいくらか複製する唯一の方法は、n 秒ごとに更新がある場合に取得するスクリプトにタイムアウトを含めることです。PHP + Javascript (w/jQuery) でオブザーバー パターンを使用してこれを行う方法はありますか?

現在のナビゲーションコントローラーまたはアプリケーションデリゲートメソッドで現在表示されているビューコントローラーを確認する方法はありますか？

必要なタブバーコントローラーを表示できるように、コントローラーがスタックからプッシュおよびポップされるのを監視するオブザーバーをアプリケーションデリゲートに作成したいと思います。基本的に、私のアプリには複数のタブバーコントローラーがあります。

GC 対応言語では、オブザーバーがサブジェクトのイベントをサブスクライブすると、実際にはサブジェクトはオブザーバーの参照を取得します。

したがって、オブザーバーをドロップする前に、まずサブスクライブを解除する必要があります。それ以外の場合は、まだサブジェクトによって参照されているため、ガベージ コレクションされることはありません。

通常、3 つの解決策があります。

1. 手動で購読を解除する
2. 弱参照。

どちらも他の問題を引き起こします。

そのため、通常はオブザーバー パターンを使用するのは好きではありませんが、その代わりになるものはまだ見つかりません。

つまり、このパターンは非常に自然な方法で物事を説明しているため、これ以上のものはほとんど見つかりません。

あなたはそれについてどう思いますか？

次のシナリオで立ち往生しています。私は満足していないコードの匂いがありますが、それに対する解決策は同じように複雑に見えますが、方法が異なるだけです。

ビジネス オブジェクトを表すシーン グラフがあります。ビジネス オブジェクト自体ができるだけシンプルになるように設計しました。それらは実質的に POJO です。

現在、1 つのエンティティが異なるノードによってシーン グラフの複数の領域に表示される場合があります。

エンティティが変更されると、関連するすべてのシーン グラフ ノードが変更されます。

一度に 50000 を超えるエンティティが画面に表示されるため、すべてのエンティティでオブザーバー パターンを使用することをためらっています。

すべての変更はビューから開始されるため、現在、シーン グラフを再帰的に処理し、変更されたエンティティに関連付けられているすべてのノードを強制的に再読み込みしています。でも気分が悪い。

これを改善する方法について何か提案はありますか?

私はC++のリスクに基づいたネットワーク化されたボードゲームを作りたいと思っています。私のアイデアは、ユーザーが接続してゲームを作成/参加できるゲームロビーをホストする中央サーバーを用意することでした。この場合、オブザーバーパターンは魅力的です。サーバー上ですべてのゲームモデル/ロジックをホストでき、クライアントはこれを監視し、ビューを使用して現在のゲームの状態を表示するだけだからです。

私の最初の質問：このアプローチは可能ですか？私が聞いたり考えたりしたことのほとんどは、クライアントが独自のゲームモデルを持っているということです。ただし、計算量が多くないゲームを考えている場合、サーバーによってホストされる単一のモデルには利点があります（同期の問題がない、不正行為を防ぐなど）。

2番目の質問：ネットワーク上でオブザーバーパターンを実装するにはどうすればよいですか？ネットワークを介して直接メソッド呼び出しを行うことはできないため、データを使用してこれをシミュレートするための何らかの簡単な方法が必要になります。「プル」（オブザーバーがゲームデータの更新を要求する）または「プッシュ」（サーバーが新しい更新されたデータをすべてのクライアントにプッシュする）アプローチを使用すると、さらに多くの利点がありますか？

オブザーバー デザイン パターンでは、サブジェクトupdate()は各オブザーバーの操作を呼び出して、すべてのオブザーバーに通知します。これを行う1つの方法は

ただし、ここでの問題は、各オブザーバーが順番に更新され、オブザーバーの更新操作が、更新される前にすべてのオブザーバーまで呼び出されない可能性があることです。更新のための無限ループを持つオブザーバーがある場合、それ以降のすべてのオブザーバーには通知されません。

質問：

1. この問題を回避する方法はありますか?
2. もしそうなら、良い例は何ですか？

Python で実装された GoF Observer の例はありますか? 現在、キークラスを介してデバッグコードのビットが含まれているビットコードがあります（現在、魔法のenvが設定されている場合、stderrにメッセージを生成しています）。さらに、このクラスには、後処理のために結果を (メモリに) 格納するだけでなく、結果を段階的に返すためのインターフェイスがあります。(クラス自体は、ssh を介してリモート マシンでコマンドを同時に実行するためのジョブ マネージャーです)。

現在、クラスの使用法は次のようになります。

別の使用モデルは次のとおりです。

これはすべて、現在のユーティリティでは正常に機能します。ただし、柔軟性に欠けます。たとえば、私は現在、簡単な出力形式または進行状況バーを増分結果としてサポートしています。関数の簡単で完全な「マージされたメッセージ」出力もサポートしていpost_process()ます。

ただし、複数の結果/出力ストリーム (ターミナルへの進行状況バー、ログ ファイルへのデバッグと警告、1 つのファイル/ディレクトリへの成功したジョブの出力、失敗したジョブからのエラー メッセージおよびその他の結果) をサポートしたいと考えています。など）。

これは、Observer を必要とする状況のように聞こえます...クラスのインスタンスを他のオブジェクトからの登録を受け入れ、発生時に特定のタイプのイベントでそれらをコールバックします。

SO関連の質問でそれへの言及をいくつか見たので、私はPyPubSubを見ています。ユーティリティに外部依存関係を追加する準備ができているかどうかはわかりませんが、他の人が使いやすくなるのであれば、自分のインターフェースをモデルとして使用する価値があると思います。(プロジェクトは、スタンドアロンのコマンド ライン ユーティリティと、他のスクリプト/ユーティリティを作成するためのクラスの両方として意図されています)。

要するに、私は自分がやりたいことをする方法を知っています...しかし、それを達成する方法はたくさんあります。長期的には、コードの他のユーザーにとって何が最も効果的かについての提案が必要です。

コード自体はclasshにあります。

アプリケーション全体で Boost/shared_ptr ポインターを使用しています。オブジェクトへの最後の参照が解放されると、shared_ptr がオブジェクトを削除します。アプリケーション内のオブジェクトは、オブザーバー/サブスクライバー パターンと同様に、アプリケーションの中央の場所でイベントをサブスクライブします。

オブジェクト デストラクタでは、オブジェクトはサブスクリプションのリストから自身をサブスクライブ解除します。サブスクリプションのリストは基本的に単なるlist<weak_ptr<MyObject> >. 私がやりたいことは、これに似たものです：

ここでの問題は、デストラクタで shared_from_this を呼び出すことができないため、上記のコードで例外がスローされることです。

私の古い実装では、サブスクリプション リストは単なるポインターのリストでしたが、それは機能していました。しかし、代わりにweak_ptr参照を使用して、手動のメモリ管理によってメモリを台無しにするリスクを減らしたいと考えています。

オブジェクトの削除は shared_ptr に依存しているため、Unsubscribe を論理的に呼び出すことができる場所がコード内に 1 か所もありません。

この状況で何をすべきかについてのアイデアはありますか？

オブザーバーパターンを実装するクラスにラップするよりも、Javaコレクションにリスナーを配置するより良い方法はありますか?