Androidアプリにおけるソフトウェア設計の考え方
by
Yohei Murayama
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Androidアプリにおけるソフトウェア設計の考え⽅ 2018/3/12 @yomuraya Bonfire Android #3
Slide 2
Slide 2 text
⾃⼰紹介 ● 村⼭ 庸平(むらやま ようへい) ● ヤフー株式会社 ● しんそつ2004(14年⽬) ● 2011年ごろからAndroid ● Yahoo! JAPANウィジェット ● Yahoo! JAPANアプリ ● Yahoo!カーナビ ● Yahoo! MAP ● 最近Arduinoをはじめました
Slide 3
Slide 3 text
はじめに ● 設計のお話中⼼のため、実装の話は出てきません ● あくまで考え⽅なので、お困りごとは解決出来ないかもしれません ● OOD、DDDにピンと来る⽅は知ってる内容かもしれません ● 時間の関係で説明しきれない箇所が出るかもしれません ● 詳しくは懇談会のときにでも
Slide 4
Slide 4 text
アジェンダ ● アーキテクチャのおさらい ● アプリにおける設計の考え⽅ ● 簡単な設計例
Slide 5
Slide 5 text
よく使われるアーキテクチャ
Slide 6
Slide 6 text
Model-View-Controller Model View Controller
Slide 7
Slide 7 text
Model-View-Controller ● 古くからあるアーキテクチャ ● ユーザーの⼊⼒はControllerからModelに通知される ● データの変更はModelからViewに通知される ● GUIに適応するとViewとControllerが密結合になりやすい
Slide 8
Slide 8 text
Model-View-ViewModel View ViewModel Model
Slide 9
Slide 9 text
Model-View-ViewModel ● Microsoft Silverlightで採⽤されたアーキテクチャ ● ViewとModelをViewModelでつなぐシンプルなしくみ ● ユーザーの⼊出⼒はViewに集約されるため考えやすい ● データバインディングと相性がよい ● Modelを細分化するとViewModelが肥⼤化する
Slide 10
Slide 10 text
The Clean Architecture https://github.com/android10/Android-CleanArchitecture
Slide 11
Slide 11 text
The Clean Architecture ● “ボブおじさん”ことロバート・C・マーチン⽒提唱 ● UIやフレームワーク、DBなどが密結合にならないように層を分離する ● より内部に⾏くほど他から影響を受けない実装になる ● 外側に⾏くほど、よりシステムやUIに特化した実装になる
Slide 12
Slide 12 text
アプリ設計の考え⽅
Slide 13
Slide 13 text
それぞれのアーキテクチャの共通点 ● View(UI)とModelを分離したい ● Model=ビジネスロジック ● モデル≠データストア ● Web時代とViewの定義が異なってきている ● Web:主に表⽰のみ。⼊⼒はURLで別に来る ● App:⼊⼒も出⼒も担当
Slide 14
Slide 14 text
アプリにおけるビジネスロジック ● ビジネスロジック= 全ロジック ー (UIに依存したロジック + プラットフォームに依存したロジッ ク) ● ⾔い換えれば、UIにもプラットフォームにも依存しないロジック ● プラットフォームはビジネスを実現する⼿段であってやりたいことではない ● ライフサイクルが異なるロジックを混ぜるべきではない
Slide 15
Slide 15 text
ロジックのライフサイクル ● UIに依存するロジック ● ⾒た⽬の変更は何よりライフサイクルが早い ● ユーザーが使いにくいとわかればすぐに変更される ● プラットフォームに依存するロジック ● Androidの場合、年に1〜2回新しいAPI Levelが追加される ● iOSの場合、年に1回ごっそりプラットフォームが変わる
Slide 16
Slide 16 text
ここまでの設計 UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
Slide 17
Slide 17 text
ここまでの設計 ● UIとプラットフォームを分けたが、ビジネスロジックが整理されていない ● アーキテクチャを導⼊しただけでは、複雑なソフトウェアになりがち ● ビジネスロジックをどう分けるかをしっかり議論しないと、アプリの設計 とはいえない
Slide 18
Slide 18 text
ビジネスロジックを整理する⽅法 ● オブジェクト指向分析設計(OOAD) ● ドメイン駆動設計(DDD)
Slide 19
Slide 19 text
オブジェクト指向分析設計(OOAD) ● 作りたいアプリの中にあるすべての情報を概念モデルに落 とし込み、クラスとインタフェースで表現する ● 設計時にはUMLが使われる事が多い(クラス図、シーケン ス図など) ● クラス、インタフェースを設計するときはSOLID原則に従 う
Slide 20
Slide 20 text
(参考)SOLID原則 ● 単⼀責任の原則(SRP) ● 開放/閉鎖の原則(OCP) ● リスコフの置換原則(LSP) ● インタフェース分離の原則(ISP) ● 依存性逆転の原則(DIP)
Slide 21
Slide 21 text
ドメイン駆動設計(DDD) ● アプリで⾏いたいことを「ドメイン」と呼び、それをモデ ル化していく ● チーム内で話されている⾔葉を共通⾔語(ユビキタス⾔ 語)として、それを設計に取り込む ● アプリに出てくる「名詞」や「動詞」がそれぞれクラスや メソッドに対応するようになる ● 極論を⾔えば、設計書を⾒ればアプリの実装がわかるよう になる
Slide 22
Slide 22 text
具体的なビジネスロジックの整理
Slide 23
Slide 23 text
お題:ボタンを押したら画像を表⽰する Button Activity OkHttp ImageView ΫϦοΫΠϕϯτ URL byte[] Bitmap
Slide 24
Slide 24 text
関⼼の分離 ● ActivityはUIを管理するクラスであるので、ビジネスロジックを書くには 不適切 ● ActivityはImageViewに渡すBitmapが欲しいのであって、byte[]が必要な のではない ● URLもActivityが知っている必要はない ● 関⼼を分けることで境界を作る
Slide 25
Slide 25 text
画像取得クラスを作成 ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap
Slide 26
Slide 26 text
仕様変更:⼀度取った画像はローカルに保存しておいて ● Activityはローカルストレージがどんな仕組みなのか知るべきではない ● 画像取得クラスは画像の取得が責務なので、ローカルストレージは関⼼事 から外れる ● 単⼀責任の原則:変更の理由は⼀つでなければならない ● ローカルストレージはプラットフォームの⼀部である ● ライフサイクルが異なるロジックは分ける
Slide 27
Slide 27 text
画像保存クラスを作成(1) ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ※ActivityʹϏδωεϩδοΫ͕ͬͯ͠·͍ͬͯΔ
Slide 28
Slide 28 text
画像保存クラスを作成(2) ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
Slide 29
Slide 29 text
仕様変更その2:プライバシーに配慮してストレージは暗号化して ● ソフトウェア開発において、仕様変更は⽇常 ● 適切に設計ができていれば、影響範囲は最⼩にできる
Slide 30
Slide 30 text
暗号ストレージへの変更 ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap ը૾อଘ ҉߸ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap Өڹൣғ͚ͩ͜͜
Slide 31
Slide 31 text
エンジニアの平穏は保たれた
Slide 32
Slide 32 text
まとめ ● 名のあるアーキテクチャを採⽤するだけでは設計したとはいえない ● UIとビジネスロジックを分けるのはもちろん、プラットフォームも分ける ● オブジェクト指向はちゃんと理解しよう ● クラスの関⼼・責務を考えよう ● ドメイン駆動ができると幸せになれるかも?