節子、それViewControllerやない...、FatViewControllerや...。 | iOSDC 2017 前夜祭

UIViewController(以下UIVC, VC)クラスにおいてよく起こりがちな問題があります。iOS開発者であれば一度は耳にしたことがあるでしょう、「VCの肥大化問題」です。VCの肥大化の原因は、UIVCクラスの責務過多にあります。 このトークでは、UIVCクラスの責務を見つめ直し、「VCの肥大化問題」に対して、設計の観点からどのように解消できるかを紹介します。

扱う内容(仮) ・UIVCの責務を振り返る ・よくある解決策: MVP ・責務分けにチャレンジ!

スピーカーの方の登壇についての記事・スライド

dev.classmethod.jp

節子、それViewControllerやない…、FatViewControllerや…。

f:id:niwatako:20170915190802j:plain

f:id:niwatako:20170915190822j:plain

akibaの方から来ました。最近はNode.js書いたりしています。ダンボールのアカウントです。

概要

f:id:niwatako:20170915190857j:plain

責務を分けると→どんないいことがあるか 責務を分けるためにMVPを紹介

f:id:niwatako:20170915190922j:plain

f:id:niwatako:20170915190932j:plain

ViewControllerが重要なので、その近くにロジックがあると便利??

f:id:niwatako:20170915190951j:plain

f:id:niwatako:20170915191004j:plain

f:id:niwatako:20170915191023j:plain

f:id:niwatako:20170915191031j:plain

f:id:niwatako:20170915191040j:plain

ライフサイクルイベントに組み込まれた通信処理や、複雑な条件分岐。

どうやってテストを書けばいいんだろう

f:id:niwatako:20170915191108j:plain

Fatとは、行数が多いことが問題なのではありません。責務が多くなっている状態のことです。

f:id:niwatako:20170915191140j:plain

Fatだと。。。デグレやバグを発生させる、発見を難しくするetc

f:id:niwatako:20170915191206j:plain

テスト・メンテナンスしやすいとは?

f:id:niwatako:20170915191227j:plain

f:id:niwatako:20170915191236j:plain

責務が適切に分割、依存関係が少ない、副作用が少ないなどが良い状態

無駄な実装重複がない、バグが起きない、発見が早くなる

f:id:niwatako:20170915191310j:plain

ロジックの発火がライフサイクルやユーザーイベントからのみ発生すると

f:id:niwatako:20170915191350j:plain

f:id:niwatako:20170915191355j:plain

テストを書かなかったとしてもバグを見つけやすく・起きにくく出来る

f:id:niwatako:20170915191401j:plain

足場づくりが大事

f:id:niwatako:20170915191425j:plain

f:id:niwatako:20170915191434j:plain

ViewControllerの話しに戻ります

f:id:niwatako:20170915191452j:plain

VCがFatになるのはフレームワークとして重要な役割を担っているゆえ

f:id:niwatako:20170915191529j:plain

そこできょうはMVPで解決します

f:id:niwatako:20170915191538j:plain

f:id:niwatako:20170915191555j:plain

Pの役割は、ビジネスロジックとビューの処理を疎結合化する。

冒頭の例、白枠を切り出します

f:id:niwatako:20170915191622j:plain

f:id:niwatako:20170915191648j:plain

3つの役割の説明をコードをみてします

f:id:niwatako:20170915191701j:plain

f:id:niwatako:20170915191729j:plain

↑ViewController側でDatamodelを持たないことにしているのが大事

DataModelをViewControllerが持つと、扱いや加工をViewControllerがしなければならなくなる。

f:id:niwatako:20170915191809j:plain

↑Presenterの指示でUIを更新する処理

f:id:niwatako:20170915191828j:plain

プレゼンターから受け付けるインターフェースを定義

f:id:niwatako:20170915191844j:plain

プレゼンターは実際に通信して取ってくる処理を持つ

f:id:niwatako:20170915191911j:plain

プロトコルに定義した処理を呼び出す

f:id:niwatako:20170915191930j:plain

f:id:niwatako:20170915191937j:plain

MVPで責務を切り分けることができました。でもしれが必ずしも正義でしょうか。

f:id:niwatako:20170915191957j:plain

Viper、クリーンアーキテクチャなどもあります。やりすぎると開発コストになります。アプリの開発は色んなパラメータがあります。納期、成長度合い、予算、習熟度など。ナマモノです。設計は使い分けなければならないものだと思っています。

プレゼンターを切り出すところまでは、そんなに重くなく出来ると思っています。

f:id:niwatako:20170915192113j:plain

責務分けについて最近読んだものではこの記事が面白かったです。

オブジェクト指向の復習や、そこにプロトコルが入ってきたらどうするかなどが面白いと思います。

まとめです。

f:id:niwatako:20170915192149j:plain

責務を分けることが正義なのかという話でも取り上げましたが分ければいいという問題ではない。アプリやチームの状況に合わせて適切に使い分けを。それが、設計に答えはないと言われるところかと思います。

明日以降、の設計関係のセッションです。

f:id:niwatako:20170915192256j:plain

他にもありますか?? ぜひ見てみて下さい。

参考です

f:id:niwatako:20170915192326j:plain

ありがとうございました。

f:id:niwatako:20170915192336j:plain

QA

  • MVPってアプリを組む時によく使われるライブラリなどでおすすめのものはありますか?
    • MVPはアーキテクチャなので、どのライブラリということはそんなに無くて、作っていく中で構造を変えるという感じです。使うライブラリは普段のものと変わらずにできると思います。
  • どうも節子です。プレゼンターを切り出す時にどのようにしているか参考にお伺いしたい。ビジネスロジックをViewControllerにいれてしまって、あとで切り出すのか、最初にプロトコルをきちんと決めるのが良いのか
    • 最初大きなVCがあるとしたら、そこから切り分けるのでも良い。なれてくると最初から分けて考えても良いと思う。プレゼンター川に切り出すといった時に、できるだけViewControllerにごちゃごちゃ書かないというポリシーでやっていて、ロジックを書かないし、データを持ちたくなったら、持たずにプレゼンターに問い合わせるというようにしています。データをAPIから取ってくるというのは、ビジネスロジックとしてわかりやすいので、そういったところから抜き出したりすると良いと思います。