umeda.apk に参加してきました。
shibuya.apk の関西出張版ということで、面白そうだなぁと見ていたらお誘いをいただけたので行ってみることに。 今回のテーマは Google I/O の報告ということでしたが、自分は行ってすらないので、設計にまつわるトークをしてきました。
Bento や Burrito のメタファーは、Twitter のエンジニアであるIsrael Ferrer氏の過去の発表やポッドキャストで取り上げられています。 ちょっとまえに Qiita で Bento や Burrito に見る設計といったような、ポエミーな記事も書いたのですが、今回はもう少しまじめに、こう言う設計にするといいよという話です。
MVP とか MVC とか MVVM とか、大きな単位でのパターンはいっぱいあるんですが、往々にしてモデルはでっかく一括りで"モデル"と呼ばれてしまい、放っておくとコントローラのように太っていきがちです。 そこでこのトークでは、オブジェクト指向の原則のうちのひとつの単一責務の原則と、最近話題の Clean Architecture を取り上げ、いかに弁当のようにきれいに仕切られたモデルを作るかというところにフォーカスを置きました。
Clean Architecture で注目すべきは、いわゆるモデルと呼ばれる部分が2層に分かれている点です。厳密には、画面にも状態はあるので、その状態をもっておくプレゼンテーションのレイヤもモデルと言えばモデルですが、データをやりとりしたり、与えられたデータをもとにビジネスロジックを動かす部分は2層あります。
ひとつはリポジトリやデータレイヤと呼ばれるような部分で、非同期処理でくるんで使う部分のおおくがここに入ります。REST を叩いてデータを取り出す・変更する・作成する・削除する部分や、データベースの操作など、一番データソースに近い部分がこのデータレイヤで、作り方のパターンとしてはリポジトリパターンを使うと良いようです。 REST、データベース、メモリキャッシュなどはこのリポジトリでまとめて取り扱いますが、クラス自体は分かれます。そのため、画面に近いレイヤからみた時に扱いやすいよう、分離されたクラスをひとまとめに扱うインタフェースを用意します。最近は Rx が主流になりつつあるので、Observable を返すようなインタフェースを用意すれば便利でしょう。
リポジトリができたら、そのリポジトリとプレゼンテーションをつなぐドメインの部分を作ります。このドメインの部分がないと、リポジトリが散らかるか、プレゼンテーションが太るかになってしまう為、ドメインの部分を必ず用意します。
リポジトリはアプリケーションでシングルトン、ドメインはドメインごとにシングルトンであれば良いと思います。
そういうわけで、金曜日は大阪で一泊、土曜日は半日大阪を観光して帰ってきました。また機会があれば行ってみたいですね！
