2009-06-08 20 views
3

は、だから私の現在のプロジェクトのために、基本的に3つの主要なJavaクラスがあります。メディエータパターンはこのような状況で機能しますか?

  1. GUI
  2. インスタントメッセージング
  3. 計算

は、基本的には、完全なコミュニケーションが必要であるので、我々は」 GUIがプロジェクト全体を実行するのではなく、メディエータのアプローチを使用することに決めました。

基本的に、メディエータは通信をカプセル化します。私たちが遭遇した問題は、何か完了したときにいつでも呼び出すメディエーターのための大量のメソッドを構築せずにGUIコンポーネントを更新する方法です。

Ex。 GUIがユーザにログインしたいとし、メディエータを経由してスレッドを作成してログインしますが、メディエータは成功/失敗をGUIに戻してステータスメッセージを更新する必要があります。

その他の問題は、GUIを更新する必要がありますが、モデレータは必要ありません。 GUIがそのクラスのインスタンスを作成して実行できるようにするか、すべてがメディエータを通過するかどうかは実際的ですか?

私たちオリジナルのデザインではGUIがすべて管理されていましたが、実際には再利用性がなくなりました。この場合、より良い設計方法がありますか?

答えて

3

オーバーヘッドが多すぎるためにObserverが見つかった場合は、メディエータが最適な方法です。私は間違いなくあなたがGUIをショーを走らせるべきではないと思う。 Mediatorパターンを使用する場合は、メディエータ自体が担当する必要があります。あなたが考えるかもしれないものは、コマンドパターンの変形です。 Rubyを使用している場合は、関数コールバックを渡すことをお勧めします。しかし、それはJavaであるため、コマンドパターンスタイルでアクションをカプセル化するいくつかの形式が役に立ちます。

0

メディエータがコールバック/通知をトリガしないようにするには、コールバックをログイン関数に注入し、ログインが完了したらログインするようにします。

私はJavaでコールバックを注入する方法についてはわかりませんが、関数がファースト・クラスの市民である言語では、関数を渡すことができますが、Javaを使用しているので、kmorrisのようにコマンド・パターンを使用する必要があります。

0

メディエータに戻り値の取得や、必要な値(コマンドパターンのバージョン)を設定するコールバックオブジェクトをGUIに持たせることもできます。 GUIからメディエータに1コールにつき1つのコールがあります。

メディエータが呼び出すメソッドを意味的に関連するチャンクにグループ化することも考えられます。

gui.a() 
    gui.b() 
    gui.c() 

あなたはすべての3つの呼び出しの結果を処理する単一のメソッドを作成することができます。特に、メディエータは、それは行のいくつかのGUIメソッドを呼び出すする傾向があるセクションを持っている場合。意味的にグループ化されたメソッド(すなわち、setFileInformationsetFileMenusetTabなど)の利点は、GUIを変更する必要がある場合、メソッドの内容が変更される可能性がありますが、メディエータの呼び出しが変更される可能性があります。

関連する問題