【iOS】VIPERとは？
初学者が、Clean Architectureの派生として、よく聞くVIPERについて調べていく。
Clean Architectureとは？
よく見る絵がこちらです。
上の図でいうと、円の外側（変化しやすいモノ・コト）は、円の内側（変化しづらいモノ・コト）を依存しないようにしよう。ということが主に定義されていることである。
Entity・UseCase・インターフェイスアダプタ・フレームワークとドライバ
が主な構成要素である。
もっと詳しい説明に関しては、
こちらの記事がわかりやすいです。
こちらの記事を参考にいたしました。
動画解説＋記事での説明があり、とても丁寧でわかりやすかったです。
こちらの本も並行して読みながら、学習を進めた。
VIPERを用いる目的
結論から伝えると、
- 責務を切り離して検証することができる
- 外部の変更に対して、コードの修正量が少なくて済む
- テスタブルなソースコードが実現できる
これらを実現するためには、主に重要なキーワードが２つ出てくる。
・単一責任の原則
・依存性の分離
である。
SOLID原則の構成要素の中に含まれる２つであり、
-
S: 単一責任の原則（Single responsibility principle）
クラス（型）を変更する理由は、２つ以上存在してはならない。 -
D: 依存性逆転の原則（Dependency inversion principle）
上位レベルのモジュールは下位レベルのモジュールに依存すべきではない。両方とも抽象に依存すべきである。
抽象は詳細に依存してはならない。詳細が抽象に依存すべきである。
簡単に説明すると、
- クラス・構造体ごとに、行うべきことをファイル、フォルダ毎に分けて（単一責任の原則）、
- 外部の変化しやすいモノ・コトに対して、依存しないような実装（依存性逆転の原則）を心がけよう！
といったところだと、筆者は解釈している。
逆をいうと、
- 一つのクラス・構造体で、なんでも可能にすると、各モジュールごとに検証しづらい（単一責任の原則）
- ローカルデータ保存をRealmからCoreDataに変えたり、UIをUIKitからSwiftUIに変更したいときに、全ての部分でコードを修正する必要があるよ。(依存性逆転の原則)
ということだと解釈している。
VIPER概要
Clean Architectureに、画面遷移のためにRouterを足したものである。
その他の構成要素としては、
・View
画面更新・UIイベント受信
・Interactor
データ操作とユースケース。
・Presenter
アーキテクチャ上のメディエータ （仲介役みたなもの）。
・Entity
単純な構造のモデル。Interactorによってのみ使われる。
・Router
画面遷移と新しい画面のセットアップ。
以上のような構成要素で、定義されている。
全体像は、この図がとてもわかり易いです。
Presenterが旗振り役として振る舞います。
例１
Viewから、「〇〇がタップされたよ」という知らせに対して、
- Presenterは、Router に「画面遷移してください（Presenterはどんな風に画面遷移するかを知らない。）」と指示したり、
- Presenterは、Interactorに「データください（Presenterはどのような方法でデータを取得しているかを知らない。）」と指示したりする。
など
Presenterは詳細を知らないが、指示を送るイメージで良いと思います。
例２
Interactorから、「データ持ってきたよ！！」or「データなかったから、エラーで！！」と、Presenterに知らせた際に、
- PresenterからViewに対して、「〇〇というエラーが来たから、エラーに対する表示よろしくっ！」と伝える
- PresenterからViewに対して、「データ届いたから、データ表示よろしく！」と伝える
- PresenterからRouterに対して、「エラー届いたから、違う画面に遷移してください！」と伝える
など
例１同様に、Presenterは詳細を知らないが、指示を送るイメージです。
上記のイメージで、私は解釈しています。
できるだけわかりやすくするために、擬人化して表現してみました。
間違えていれば、申し訳ございません。
次回の記事は、サンプルコードを用いて、実装していこうと思います。
他にも良い方法があれば、コメントいただけると大変うれしいです。
良かったと思ったら、いいねやTwitterのフォローよろしくお願いいたします！
個人でアプリを作成しているので、良かったら覗いてみてください！
Discussion