MVVM・MVP・Fluxの基礎知識

# 勉強しようと思ったきっかけ
少し前に新人研修で作ったアプリのソースコードを見ていて、

**「何が書いてあるか、わからない！」**

となったので、先輩の勧めでアーキテクチャの勉強をしてみました！
今回は、MVVM・MVP・Fluxの３つを勉強しました。

# そもそもアーキテクチャって何?
- 建築学、構成、構造の意味
- コンピュータやソフトウェア、システムの設計方法、設計思想、及び設計思想に基づいて構築された構造

# アーキテクチャを導入するメリット

**「アーキテクチャ勉強しなくてもアプリ開発できるからいらなくね?何が良いの?」**

みたいな疑問を持つ人もいるかもしれません。
そんな人のために、アーキテクチャ導入前と導入後を比べてここが良くなった！と思うところを書いてみました。

## 導入前の状態
- ソースコードが読みにくい
- 変更に弱い
- テストがしにくい / できない

導入前は、データを取得してそのデータをUIに反映などの処理を一つのクラスにまとめて書いていて、神クラスになっていました。その結果、ソースコードも読みにくく、変更するにもそれぞれの処理が密接に繋がっているので、一つ変更すると他の箇所も変更を余儀なくされていました。

## 導入後の状態
- ソースコードが読みやすい！
- 変更に強い！
- テストしやすい！

導入後は、**データを取得する部分、取得したデータや状態を保存する部分、UIを表示する部分など**役割を分離できたため、ソースコードも読みやすく、UIの変更も最小限の変更だけで済むようになりました。

# MVVM

MVVMは、Model・View・ViewModelから構成される**UIを分離することを目的**としたアーキテクチャです。
単一方向の依存関係という特徴があり、ViewはViewModelを知っていて、ViewModelはModelを知っていますが、その逆はありません。もし、ViewModelがViewのを知っていると、Viewに変更を加えた時に、ViewModelも同時に変更をしなければなりません。

## 概念図
<img width="645" alt="スクリーンショット 2019-07-18 15.23.15.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/434603/dd4260eb-000f-4331-55fa-67d30e5a831b.png">

## Model
- アプリケーションが扱う領域のデータとその手続き（API通信など）を行う

## View
- UIの表示する
- ユーザからの入力を受け取って、ViewModelに伝達する

## ViewModel
- Viewを描画するための状態の保持する
- Modelから受け取ったデータをViewが使いやすい形に変換する
- Viewから受け取ったユーザからの入力をModelに伝達する

# MVP

MVPは、Model・View・Presenterから構成される**UIの複雑さを解決することを目的**としたアーキテクチャです。
Model・View・Presenterの間のデータフローに規則性をもたせることで役割を明確にしています。

## 概念図
<img width="747" alt="スクリーンショット 2019-07-18 15.24.19.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/434603/cf9068f9-d2f0-08b3-991e-33924f18f212.png">


## Model
- UIに関わるデータを定義し、データ構造を提供する

## View
- Modelで定義したデータを表示
- ユーザからの入力をPresenterに伝達する

## Presenter
- ModelとViewを操作する
- Modelからデータを受け取り、Viewにデータを反映する

# Flux

Fluxは、Action・Dispatcher・Store・Viewから構成されるもので、**データフローを単一方向にすることを目的**としたアーキテクチャです。状態管理をStoreと呼ばれるものに一任し、UIから状態管理などの処理を分離できます。

## 概念図
<img width="918" alt="スクリーンショット 2019-07-18 15.26.00.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/434603/3cdeaf8b-374e-3ed3-bc08-37c5d9b24e09.png">


## Action
- ユーザからの入力を処理し、その結果をStoreに伝達

## dispatcher
- Storeに対して、Actionによる更新指示を行う

## Store
- 受信したActionに応じて、自身の状態を変更し、保持する

## View
- Storeの状態に応じて結果などを画面に表示する

# 終わりに
今回は、MVVM・MVP・Fluxの基礎知識をまとめていきました。
それぞれの特徴・メリットは以下のようです。

- MVVM
    - データバインディングの力を借りることでUIとビジネスロジックを分離し、ビジネスロジックの中からViewに関するグルーコードをなくすことができる
- MVP
    - ViewとPresenterが通信するためのインターフェースを定義することで、Viewがない状態でのモック化が容易になり、単体テストがしやすくなる
- Flux
    - ActionをDispatcherが受け取るのでデータフローが単一になる
    - UIに関わる状態管理をStoreに一任することで、Viewから状態管理のコードを除去できる

私もそれぞれのアーキテクチャを実際に使ってみて、どのアーキテクチャが自分のプロジェクトに最適か判断できるようになりたいと思います。

# 参考サイト・資料(メモ)
- [Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する](https://employment.en-japan.com/engineerhub/entry/2018/01/17/110000)
- [Androidアプリ設計パターン入門](https://peaks.cc/books/architecture_patterns)
- [Model View ViewModel - Wikipedia](https://ja.wikipedia.org/wiki/Model_View_ViewModel)
- [MVVMって何？　というか…MV○丸ごと、何？](https://sssslide.com/speakerdeck.com/takasek/mvvmtutehe-toiuka-dot-dot-dot-mv-wan-goto-he)
- [Android-Architecture MVVMサンプル](https://github.com/googlesamples/android-architecture/tree/todo-mvvm-databinding/todoapp)
- [Android-Architecture MVPサンプル](https://github.com/googlesamples/android-architecture/tree/todo-mvp-kotlin/todoapp)
- [Architecture-Patterns-Samples Fluxサンプル](https://github.com/TechBooster/Architecture-Patterns-Samples/tree/master/06-flux-architecture/flux-normal)