依存性を剥がした先に見えるもの

Dagger2を使って依存性剥がしてみたらって話。古いブログから移設してきた記事なんで、参考程度にどうぞ。

Dagger2を使って依存性を剥がし始めたらなんだか楽しくなってきた。依存性を剥がすということは、コードの中からnew SomeClass()を取り除くことと言い換えて把握するようにしている。

依存性を剥がすのが楽しくなってきたというのは、コードが見やすくなってきたからだ。他のクラスに依存しないコードにすることで、クラスの責務を小さく出来る。

例えば今作っているアプリだと、GoogleApiClientを使った通信を行う部分がある。Android Wearとスマホ間で通信を行うために必要なのだ。

で、これをあるActivityで使う場合にActivity implements GoogleApiClient.ConnectionCallbacks, GoogleApiClient.OnConnectionFailedListener {...}という感じで実装してやると、Activityが見づらくなる。Activityのライフサイクルに加えて、GoogleApiClientのライフサイクルまで管理するようになるからだ。

ライフサイクルというか、onCreateでGoogleApiClientのインスタンスを作って、接続を行って、でも非同期でやるからコールバックを受け取って、接続完了したらMessageApiのリスナを登録して・・・みたいな感じで、とにかくやることが増える。

これの何が嫌かって言うと、初期化の処理があっちこっちに散ってしまうのが嫌なのだ。初期化の処理を確認するのに、Activityが生成されたときと、GoogleApiClientの接続が完了した時と2段階初期化になってしまう。

今まではサンプルがそうなってたから、そのまま私も同じようにやっていたのだけども、結局これって通信可能状態になったGoogleApiClientが欲しいだけなので、別にActivityでやらなくてもいい話なのだ。

で、今までの私ならシングルトンなクラスでも導入して、GoogleApiClientの接続を行うクラスを用意してやっていたのだけども、今回はDagger2を使ってやってみた。まあ非同期のコールバックを受け取るのにRxJavaを使っているので、一概にDagger2のおかげというわけではないのだけど。

私のDagger2についての認識は、今のところ「シングルトンにしなくてもインスタンスをシングルトンとして扱える便利ツール」になっている。なんかよく分からんけど、動いているからいいやレベルで止まっている。

止まってはいるのだけど、とりあえずクラスの責務を小さくすることの楽しさが分かってきたのはよい兆しではないかと思うことにする。

で、そうやって依存性を剥がしてクラスの責務を小さくしていくと、ああこれがMVPとかMVCにつながっていくのかなとふと気づいた。うまく説明できないので、話が飛躍してるように感じるかもしれない（だからポエムなんだけど）。

MVCとかMVPの話を聞いても、いまいちピンと来なかった。ただ今回、ActivityからGoogleApiClientの処理を剥がした時に、こういう感じでActivityからロジック切り離して行くことが、Activityを単なるViewとして扱うことにつながってくるのかなと感じたのだ。

今までどう分類するかの観点でしか見てなくて、そんなん別にどうだっていいじゃないかと思ってたのだけど、こうやって依存性を剥がしていったことで、なんとなくMVPとのつながりを感じられたのが面白いと思う。

今はまだActivityで各クラスの連携を行っているのだけど、この各クラスの連携もActivityから切り離したら、Activityは単なるViewになるし、連携を行うクラスがPresenterになるのかなっていうことを思った。

まあ相変わらずMVPはよく分からんけど、とりあえず依存性剥がすのが楽しいのは分かった。Activityがシンプルになっていくのは気持ちいい。