設計パターン
設計パターンについて初めて調べたので記録のために残しておきます🐒
🦄what
一言で言うと、**「どういうパターンでシンプルにするか」**の設計のこと。
アプリ開発に慣れてくると、機能も多くなりコードを１つのファイル等に書きまくってFatViewControllerになってしまうことがあると思います。そんな時に設計パターンを意識することでみやすいコード、プロジェクトにすることができるのです。
設計パターンは別名アーキテクチャとも言います。今回はiosでの設計パターンを書きますが、他の言語においても概念としては同じことが言えます！
🦄Specific pattern
ここからは具体的なパターンを紹介していきます。
##① MVC (iosでは cocoaMVC ともいう)
###特長：Viewとmodelを分けるパターン
**Model：**UIに関係しない純粋なビジネスロジックを書く
**View：**UIに関するロジックを書く
**Controller：**ModelとViewを参照する。仲介人。
##② MVP
**Model：**UIに関係しない純粋なビジネスロジックを書く (MVCの時と同じ)
**View：**ユーザーの操作を受けて、画面表示についてのみ書く
**Presenter：**ModelとViewを参照する。仲介人。
〜MVCとの違い〜
MVCではViewControllerにまとめられていた部分を、「描画処理」と「プレゼンテーション」に分けている。
描画処理：label.text = name やtableView.reloadData()など普通の描画
プレゼンテーション：ビュー更新や画面遷移
##③ MVVM
**Model：**UIに関係しない純粋なビジネスロジックを書く (MVCの時と同じ)
**View：**UIイベントを受け付けてViewModelに伝える。ViewModelを監視し、その状態更新を受けて描画処理を行う。
ViewModelViewからの指示を受け、Modelの処理を呼び出す。Modelからの状態更新を受け取り、自身の状態を更新。Viewに表示するためのデータを保持する。
〜MVVMを理解するのに必要な知識〜
データバインディング：ViewModelを監視して、その状態を受けて描画処理を行う
##④ Flux
###特長：Fluxでは常に単一方向でデータフローが生成される
→そのため、ため、アプリケーションの複雑化を防ぐことができます。また、チーム開発などでもフローを追いやすく、保守性の高いコードが書ける。
Action：：実行する処理を特定するためのtypeと、それに関連するdataがセットになったもの。
**Dispatcher：**Actionを受け取り、その値をStoreに伝える役割。
Store：:Dispatcherから伝わってきたActionを受けて、自身の状態を更新して通知。
**View：**Storeの状態を監視し、その状態更新を受けて画面を更新。
#🦄まとめ
他にも種類はありますが、今回は４つだけ選んでまとめてみました。開発するアプリの特長や、開発メンバーなども考慮した上でその時にあった設計パターンを使うと良いと言うことがわかりました！
設計パターンについて調べる中で、知らなかった言葉に出会ったりと、いろんな面で理解が深まった気がします。これからは綺麗なコードを意識してエンジニアとしてワンランクアップできるように頑張ります🐣
##参考にした記事
iOSのいろいろなアーキテクチャパターンを試してみる
手を動かしてMVPパターンを体験する