iOSDC 2017 前夜祭で「節子、それViewControllerやない…、FatViewControllerや…。」というタイトルで登壇しました！ #iosdc

はじめに

おばんです、今年のiOSDCは去年とは打って変わって緊張がハンパない田中です。お腹が痛い...、ｳｯ...！

2017/09/15 - 17で開催される iOSDC 2017 というカンファレンスで登壇させていただきました！このエントリは当日喋った内容を、登壇者ノートを添えて、抜粋して紹介します！

登壇後すぐアップしていますので、質問がある方などが参照しやすいようになれば幸いです。

トゥギャっていただきました。

まとめ・感想

解説が長いのでまとめを先に記述します。

だいぶ抽象的に喋りました。きっと無限のマサカリが飛んでくるかとは思いますが、スライドや発表を補填する議論は大歓迎なので、なにかありましたらTwitter(@ktanaka117)にメンション飛ばしてください！

貴重な発表の機会をいただき、ありがとうございました！

発表内容

以下解説。

---

例えばこれ。ライフサイクルの中にベタ書きされた通信処理。どうやってテストするのだろうか…？

節子、これViewControllerちゃうやろ、FatViewControllerや！

先ほどのものと近いですが、ほかにはこんなものもあります。

闇です。ライフサイクルに組み込まれた条件分岐がベタでだらだらと書かれている。それはビジネスロジックではないのか？？？テストはどう書くんだ？

節子、これViewControllerちゃうやろ、FatViewControllerや！

先ほどの例で言えば、ビジネスロジックがVCに入り込んできてしまっていたり、ライフサイクルに複雑に関与していることが当てはまります。

先ほどからFatViewControllerがどういうものかを見ていく中で、テストしやすさ、メンテナンスのしやすさという言葉を使っていました。 それがどういうことなのかについて見ていきます。

少し詳しくテストと設計について説明します。


例えば機能の発火の起点となるものがライフサイクルに完全に組み込まれた状態であったり、ユーザー入力からのみとなってしまったりなどである。 入力とビジネスロジックが依存関係にあるといえます。

テストテストと言っているが、
仮にテストを書いていなかったとしても、過度の依存や重責を減らせていれば問題箇所の特定が早くなり、デバッグがしやすくなります。

テストによって既存のプログラムが壊れないことを担保することができ、素早く、バグが起こっても原因究明が早急にされる、無駄のないコードを書ける。

ViewControllerを綺麗にしてくれる設計について多くの議論が重ねられ、注目のマトになっているのは様々な責務をもともとのフレームワークの設計として負っているためでした。


ここでViewと言っているのはViewControllerと読みかえていただいて構いません。
ViewControllerが直接モデル(ビジネスロジック)に関与するのではなく、Presenterを介してデータのやり取り、描画指示が行われる設計です。

Protocolとして切り出すことでクラスそのものに依存することを防ぐことができます。 Presenterから受ける描画指示を宣言します。

ここで大事なのはVCがデータモデルを持たないこと。 データモデルを持ってしまうと、それをどう扱うかとか加工の処理をVCで行わなければいけません。それはPresenterにやらせましょう。

presenterに対してinputが行われます。

ViewControllerはPresenterの指示を元にしてUIの更新を行うのみという作りになっています。

実際に通信を行ってくれるクラスのインスタンスを保持します。

実際の通信処理はビジネスロジックなので、また別の役割(ここではDataStoreという役割)が担っています。それを呼び出します。

ビジネスロジックの通信処理などのコールバックを元に、 さっきVCに書いていたProtocolを呼び出します。

ここまでがMVPの説明。

アプリ開発はいろんなパラメータがある。納期、アプリの成長度合い、予算、チームの習熟度、etc…。なのでナマモノ

ただ、感覚としてPresenterを切り出して、その延長にあるビジネスロジックを切り出すことまでは必ずと言っていいほどやって良いと思う。

責務わけに関わる話として、この記事なんかが最近読んだ中でおもしろかったです 話は継承と委譲に関するものなのですが、オブジェクト指向の復習的な内容で、Swiftに当てはめた時にプロトコル指向の世界も入ってくるので合わせて考えると楽しそう。

MVVM, Flux, VIPER, CleanArchitecture いろいろあります

責務を分けることが正義なのかという話でも取り上げましたが、ただ分ければ良いというわけではありません。設計に答えは無い