Mvcのすすめ

今回の目的

• バグを減らしたい
• テストがしたい
• テストの仕方がわからない
• テストしやすい構造で作る

アクティビティ

レイアウト

画面

ありがちのこと
• レイアウトを作る
• とりあえずアクティビティに実装する
• さらにアクティビティに実装する
• できたバンザイ
• MVCなにそれ！？

テストできない
• 操作→情報処理→状態変化→表示

テストできる
• 情報処理
• 情報処理→状態変化

←テストできる
モデル


レイアウト

画面

MVC

• Model-View-Controllerの略

• モデルからプレゼンテーションの分離
• ビューとコントローラーの分離

モデルからプレゼンテーションの分離

テストしやすい部分
と
テストしにくい部分

テストしやすい部分

• 単純な変換 (文字列処理とか)
• DBアクセス
• 状態変化

テストしにくい部分

• 見た目
• ボタンを押す
• 画面遷移
• 機種依存

ビューとコントローラーの分離

見た目
と
操作

見た目

• ボタン
• 画像
• テキスト
• その他いろいろ

操作

• テキストを入力→文字列処理
• ボタンを押す→状態が変わる
• セーブボタン→DBアクセス

テストしやすい

テストしにくい

操作見た目

Model

プレゼンテーション

Controller View

Model

操作状態参照通知


Controller 変更 View

入力・操作表示

ユーザー

今回は
ViewとControllerの分離を
がんばらない

分離しても
テストしやすくならないし

Model

操作状態参照


入力・操作表示

ユーザー

モデル


レイアウト

画面

今まで

インテントインテント
アクティビティアクティビティアクティビティ

レイアウトレイアウトレイアウト

DB 一時保存



DB 一時保存

テストできる
↑
↓ アクティビティアクティビティ

テストできない


DB 一時保存

モデルモデルモデル



Model
• DBアクセス
• 状態を持つ
• 情報処理

• CUIでもGUIでも同じものを使えるようにしようと書いてあるけど，
テストしやすければよい


• 操作
• →モデルに通知
• →必要に応じて遷移
• →モデルに状態に応じて再描画

まとめ

• アクティビティにすべてを書かない
• テストしやすい構造を意識する
• できたらViewとControllerを分けて考え
る

Recommended