EventBus の使い方はこちらに任せるとして、この投稿では、EventBus の効果的な使い方について考察します。
どのレイヤの結合を分離するか
特に、View の仕組みがフレームワークとして作りこまれているものであれば、View のイベントはリスナーインタフェースを用いれば十分にイベントハンドリングが可能です。Android の場合、View のシステムは Activity のライフサイクルとよく連動して動作するため、ここに EventBus による中間層の挿入をする理由はあまりありません。
多くの場合、アプリ開発者が設計し実装する部分は Controller と Model の相互作用です。そして、Controller と Model の境界面で使われる設計パターンとして、コールバックインタフェースが用いられてきました。
コールバックインタフェースを用いることで、Model から Controller への戻しの処理が共通化され、Controller は実装を強制されます。
しかし、Controller にはライフサイクルがあり、特に Android のような、大きくかつライフサイクルの短い Controller を取り扱う場合には、コールバックインタフェースの参照の持ち方を適切に管理しなければなりません。また、インタフェースによって Model と Controller が密に連動するため、インタフェースの変更のコストはどうしても高くなりがちです。
この問題点を解消するために、EventBus という中間層を介したコミュニケーションを用いることが有用となるのです。
なぜなら、Model と Controller は直接結合することがなくなることで、Controller が実装したコールバックインタフェースの管理をしなくても良くなるからです。
命名規則
もし、すべてのレイヤのすべてのイベントを EventBus を介してやりとりするとどうなるでしょうか。
あらゆるイベントがオブジェクト化され、あらゆるレイヤに多種多様なイベントオブジェクトが溢れかえります。
Otto はアノテーションとイベントオブジェクト名によって、EventBus はイベントオブジェクト名によって適切なハンドラを選択します。いずれにしても、イベントオブジェクトの命名によってハンドラが選択されるため、イベントオブジェクトの命名を間違えると、どのイベントがどのレイヤからやってくるのかが分からなくなってしまいます。これはインタフェースの乱立よりも厄介な問題です。
Controller は Model を直接参照し、Model の状態変化にリアクティブになる
Controller は、View でおこるイベントに応じて適切に Model の操作を行います。この点で、Controller が Model を直接参照することはごく自然な振る舞いです。
問題は、Model の操作のコールバックの管理にあったはずですから、この部分を EventBus に任せ、Model は操作の結果としてイベントを発し続け、Controller はそのイベントにリアクティブに振る舞うようにします。
Controller と Model との境界面を柔軟にする、という点で、このポリシーは有効なのではないでしょうか。