RobotLegsの例では、メディエーターは、これらの子を含むカスタムコンポーネントではなく、すべてのボタン/textAreaで使用されているように見えます。これは非常に時間がかかりますね。
JoelHooksInsideRiaの例から
依存性注入は、明確なクラスでより適切に機能します。これが意味するのは、TextAreaを新しいMessageViewクラスに拡張することにより、依存性注入が作用する特定のビューコンポーネントを作成しているということです。これは、アプリケーションにさまざまな目的に役立つ複数のTextAreaがある場合に重要です。このようにクラスを分割することで、クラスの意図を明確に定義し、依存性注入ツールが効果的に仕事を行えるようにします。
いいえ、すべての子コンポーネントを仲介しないでください。コンポーネントは、関連するアクションを実行するグループに編成する必要があります。例のコンポーネントは非常に単純で、実際のアプリケーションがどのように見えるかを反映していません。
私が使用する経験則の 1 つは、そのコンポーネントがアプリケーションの残りの部分と通信する必要があるかどうか、または全体の一部にすぎないかどうかを考えることです。メディエーターは、ビューとアプリの間のブリッジとして機能することのみを目的としていることを覚えておいてください。
たとえば、フォーム (ログイン フォームを想定) を含むビューがある場合、すべての子コンポーネント (テキスト フィールド、ボタンなど) を仲介するわけではありません。実行時のオブジェクト。私が考えるフォームを実行すると、ビューはそれ自体で何をしますか? そして、アプリの他の部分はそれをどうするべきですか? ユーザーがフォームに入力してボタンをクリックすると、ビューはイベント (この場合は LoginRequestEvent) をディスパッチし、メディエーターはそのイベントを再ディスパッチして、メディエーターを非常に無駄のないものにする必要があります。
しかし、フレームワークを実践することで、何を仲介すべきかという感覚にたどり着くでしょう。たとえば、あるアプリではリストのすべてのアイテム レンダラーを仲介し、別のアプリでは 2 つまたは 3 つのナビゲーション コンテンツを含むビュー スタックを仲介します。
それが役に立てば幸い