iOSアプリの設計ってどうやるの？

ViewControllerに処理を詰め込みすぎて保守が大変になるのはあるあるネタですよね。
じゃあ、ViewControllerでやることってなんだろうって問われると、まあ、こんなんだろうなってフワッとしてる。
文字に書くことで境界線を引いてみたい。

ViewControllerって何するの？

• Viewの更新
• Modelに何かしらの処理を依頼
• Modelの処理した結果を受け取る
• Viewに関するイベントを受け取る
• ハードウェア的なイベントを受け取る

Modelの処理はViewControllerに書くとやばそう

と、いうのは情弱な私でも身にしみてる。

上のスライドで言うところのログインなどの認証周りの処理をViewControllerにベタっと書くと、他の画面でその同じ処理したいときにコードをコピペするか元ViewControllerのメソッドを呼んじゃう！みたいな危険な依存を生むナニカができそうですよね。

なのでModelは
* 独自のクラスに処理を集約する
* UIに関する処理は一切混ぜない

って感じでしょうか。

『集約するのが良いから！』と言って何でもかんでも１つのModelに詰め込むと、それはそれでヤバいので機能や関心ごとにクラスを分割してやると良さそうですよね。

UIに関する処理とModelな処理が混在してると、１つのメソッド内で完結できて良かったのに。。同期的な処理ならともかく、APIを叩くみたいな非同期な処理の場合とか、分けちゃったらどうやってUI更新したらいいんだ。

delegateかNotificationを使うんですかね。
ここの使い分けがイマイチ分かってないですが、いずれかを使えばModelの更新メッセージをViewControllerで受け取ることができます。

APIを叩いて結果を受け取ったらdelegate○○に結果のオブジェクトを渡してコールする。
みたいな。

１つの画面で複数のAPIを叩くような場合はどうすんだろ

大量のdelegateがViewControllerを覆い尽くすことは容易に想像できますよね。。
ViewControllerが調整役とは言えどもなんかアレな気がします。
こういう場合は、各関心ごとにコンポーネント的な子ViewControllerを作って、その中で完結させる感じすかねー。

子ViewController側でModelを叩いた結果が、親ViewControllerにも影響ある場合

子ViewControllerからメッセージを受けるか、ModelからNotificationを飛ばしてもらう感じなんかな。謎。

delegateの問題点？

ViewやModel、端末からのイベントを検知を検知する→何かしら更新する
これがViewControllerの役割。
なので、１つのViewControllerで取り扱うイベントの種類が増えたらその分リスナーは増える。

複数のTextViewを１枚のViewControllerで扱うとする。
delegateを使えば１つのリスナーに「○○（←ある任意のTextView）のテキストが更新されたよ」という情報が返ってくる。
リスナーの中にTextViewがAだった場合はこの処理で、TextViewがBだった場合はそっちの処理で、、、って書くことになる。

なんかヤバそうだよね。。

ViewController側は『switchで分岐』まではやるけど、その先の各TextViewの更新は別のクラスに委譲するのがいいのだろうか。

BlocksKitは?

delegateで起こる↑のような分岐処理の煩雑さを解消してくれそう。
ただ、各TextViewに対してクロージャ的なナニカをくっ付けるので、無邪気にやってるとViewControllerが肥大化しそう。

認識

雑多な処理は子ViewControllerに集約(ここの中でBlocksKitを使うのはアリな気がする)して、子ViewController間をまたぐような処理は親ViewControllerが取り持ってやるのが良さそう？