UIViewController(以下UIVC, VC)クラスにおいてよく起こりがちな問題があります。iOS開発者であれば一度は耳にしたことがあるでしょう、「VCの肥大化問題」です。VCの肥大化の原因は、UIVCクラスの責務過多にあります。 このトークでは、UIVCクラスの責務を見つめ直し、「VCの肥大化問題」に対して、設計の観点からどのように解消できるかを紹介します。
扱う内容(仮) ・UIVCの責務を振り返る ・よくある解決策: MVP ・責務分けにチャレンジ！
スピーカーの方の登壇についての記事・スライド
節子、それViewControllerやない…、FatViewControllerや…。
akibaの方から来ました。最近はNode.js書いたりしています。ダンボールのアカウントです。
概要
責務を分けると→どんないいことがあるか 責務を分けるためにMVPを紹介
ViewControllerが重要なので、その近くにロジックがあると便利？？
ライフサイクルイベントに組み込まれた通信処理や、複雑な条件分岐。
どうやってテストを書けばいいんだろう
Fatとは、行数が多いことが問題なのではありません。責務が多くなっている状態のことです。
Fatだと。。。デグレやバグを発生させる、発見を難しくするetc
テスト・メンテナンスしやすいとは？
責務が適切に分割、依存関係が少ない、副作用が少ないなどが良い状態
無駄な実装重複がない、バグが起きない、発見が早くなる
ロジックの発火がライフサイクルやユーザーイベントからのみ発生すると
テストを書かなかったとしてもバグを見つけやすく・起きにくく出来る
足場づくりが大事
ViewControllerの話しに戻ります
VCがFatになるのはフレームワークとして重要な役割を担っているゆえ
そこできょうはMVPで解決します
冒頭の例、白枠を切り出します
3つの役割の説明をコードをみてします
↑ViewController側でDatamodelを持たないことにしているのが大事
DataModelをViewControllerが持つと、扱いや加工をViewControllerがしなければならなくなる。
↑Presenterの指示でUIを更新する処理
プレゼンターから受け付けるインターフェースを定義
プレゼンターは実際に通信して取ってくる処理を持つ
プロトコルに定義した処理を呼び出す
MVPで責務を切り分けることができました。でもしれが必ずしも正義でしょうか。
Viper、クリーンアーキテクチャなどもあります。やりすぎると開発コストになります。アプリの開発は色んなパラメータがあります。納期、成長度合い、予算、習熟度など。ナマモノです。設計は使い分けなければならないものだと思っています。
プレゼンターを切り出すところまでは、そんなに重くなく出来ると思っています。
責務分けについて最近読んだものではこの記事が面白かったです。
オブジェクト指向の復習や、そこにプロトコルが入ってきたらどうするかなどが面白いと思います。
まとめです。
責務を分けることが正義なのかという話でも取り上げましたが分ければいいという問題ではない。アプリやチームの状況に合わせて適切に使い分けを。それが、設計に答えはないと言われるところかと思います。
明日以降、の設計関係のセッションです。
他にもありますか？？ ぜひ見てみて下さい。
参考です
ありがとうございました。
