Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Androidアプリにおけるソフトウェア設計の考え方
Search
Yohei Murayama
March 12, 2018
Technology
6
1.7k
Androidアプリにおけるソフトウェア設計の考え方
2018/3/12 Bonfire Android #3
https://yj-meetup.connpass.com/event/79749/
Yohei Murayama
March 12, 2018
Tweet
Share
More Decks by Yohei Murayama
See All by Yohei Murayama
Kotlinで作るAndroidアプリ開発入門
yomuraya
1
1.1k
Other Decks in Technology
See All in Technology
JEP 480: Structured Concurrency
aya_ebata
0
130
OCI で始める!! Red Hat OpenShift / Get Started OpenShift on OCI
oracle4engineer
PRO
1
200
【株式会社ELYZA】|GENIAC成果報告会 自社開発モデルプレゼンテーション
elyza
1
420
『GRANBLUE FANTASY: Relink』専任エンジニアチームで回す大規模開発QAサイクル
cygames
0
110
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
3
390
『GRANBLUE FANTASY Relink』キャラクターの魅力を支えるリグ・シミュレーション制作事例
cygames
0
170
Technical Writing Meetup vol.35
soracom
PRO
2
130
LLVM/ASMを使った有限体の高速実装
herumi
0
120
どこよりも遅めなWinActor Ver.7.5.0 新機能紹介
tamai_63
0
210
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
1
180
AIで変わるテスト自動化:最新ツールの多様なアプローチ/ 20240910 Takahiro Kaneyama
shift_evolve
0
250
2024年のナビゲーション・フォーカス対応:Composeでキーボード・ナビゲーションをサポートしよう
tahia910
0
110
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
96
11k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
Designing for Performance
lara
604
68k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
BBQ
matthewcrist
83
9.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Faster Mobile Websites
deanohume
304
30k
Typedesign – Prime Four
hannesfritz
39
2.3k
Infographics Made Easy
chrislema
239
18k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
From Idea to $5000 a Month in 5 Months
shpigford
379
46k
Raft: Consensus for Rubyists
vanstee
136
6.5k
Transcript
Androidアプリにおけるソフトウェア設計の考え⽅ 2018/3/12 @yomuraya Bonfire Android #3
⾃⼰紹介 • 村⼭ 庸平(むらやま ようへい) • ヤフー株式会社 • しんそつ2004(14年⽬) •
2011年ごろからAndroid • Yahoo! JAPANウィジェット • Yahoo! JAPANアプリ • Yahoo!カーナビ • Yahoo! MAP • 最近Arduinoをはじめました
はじめに • 設計のお話中⼼のため、実装の話は出てきません • あくまで考え⽅なので、お困りごとは解決出来ないかもしれません • OOD、DDDにピンと来る⽅は知ってる内容かもしれません • 時間の関係で説明しきれない箇所が出るかもしれません •
詳しくは懇談会のときにでも
アジェンダ • アーキテクチャのおさらい • アプリにおける設計の考え⽅ • 簡単な設計例
よく使われるアーキテクチャ
Model-View-Controller Model View Controller
Model-View-Controller • 古くからあるアーキテクチャ • ユーザーの⼊⼒はControllerからModelに通知される • データの変更はModelからViewに通知される • GUIに適応するとViewとControllerが密結合になりやすい
Model-View-ViewModel View ViewModel Model
Model-View-ViewModel • Microsoft Silverlightで採⽤されたアーキテクチャ • ViewとModelをViewModelでつなぐシンプルなしくみ • ユーザーの⼊出⼒はViewに集約されるため考えやすい • データバインディングと相性がよい
• Modelを細分化するとViewModelが肥⼤化する
The Clean Architecture https://github.com/android10/Android-CleanArchitecture
The Clean Architecture • “ボブおじさん”ことロバート・C・マーチン⽒提唱 • UIやフレームワーク、DBなどが密結合にならないように層を分離する • より内部に⾏くほど他から影響を受けない実装になる •
外側に⾏くほど、よりシステムやUIに特化した実装になる
アプリ設計の考え⽅
それぞれのアーキテクチャの共通点 • View(UI)とModelを分離したい • Model=ビジネスロジック • モデル≠データストア • Web時代とViewの定義が異なってきている •
Web:主に表⽰のみ。⼊⼒はURLで別に来る • App:⼊⼒も出⼒も担当
アプリにおけるビジネスロジック • ビジネスロジック= 全ロジック ー (UIに依存したロジック + プラットフォームに依存したロジッ ク) •
⾔い換えれば、UIにもプラットフォームにも依存しないロジック • プラットフォームはビジネスを実現する⼿段であってやりたいことではない • ライフサイクルが異なるロジックを混ぜるべきではない
ロジックのライフサイクル • UIに依存するロジック • ⾒た⽬の変更は何よりライフサイクルが早い • ユーザーが使いにくいとわかればすぐに変更される • プラットフォームに依存するロジック •
Androidの場合、年に1〜2回新しいAPI Levelが追加される • iOSの場合、年に1回ごっそりプラットフォームが変わる
ここまでの設計 UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
ここまでの設計 • UIとプラットフォームを分けたが、ビジネスロジックが整理されていない • アーキテクチャを導⼊しただけでは、複雑なソフトウェアになりがち • ビジネスロジックをどう分けるかをしっかり議論しないと、アプリの設計 とはいえない
ビジネスロジックを整理する⽅法 • オブジェクト指向分析設計(OOAD) • ドメイン駆動設計(DDD)
オブジェクト指向分析設計(OOAD) • 作りたいアプリの中にあるすべての情報を概念モデルに落 とし込み、クラスとインタフェースで表現する • 設計時にはUMLが使われる事が多い(クラス図、シーケン ス図など) • クラス、インタフェースを設計するときはSOLID原則に従 う
(参考)SOLID原則 • 単⼀責任の原則(SRP) • 開放/閉鎖の原則(OCP) • リスコフの置換原則(LSP) • インタフェース分離の原則(ISP) •
依存性逆転の原則(DIP)
ドメイン駆動設計(DDD) • アプリで⾏いたいことを「ドメイン」と呼び、それをモデ ル化していく • チーム内で話されている⾔葉を共通⾔語(ユビキタス⾔ 語)として、それを設計に取り込む • アプリに出てくる「名詞」や「動詞」がそれぞれクラスや メソッドに対応するようになる
• 極論を⾔えば、設計書を⾒ればアプリの実装がわかるよう になる
具体的なビジネスロジックの整理
お題:ボタンを押したら画像を表⽰する Button Activity OkHttp ImageView ΫϦοΫΠϕϯτ URL byte[] Bitmap
関⼼の分離 • ActivityはUIを管理するクラスであるので、ビジネスロジックを書くには 不適切 • ActivityはImageViewに渡すBitmapが欲しいのであって、byte[]が必要な のではない • URLもActivityが知っている必要はない •
関⼼を分けることで境界を作る
画像取得クラスを作成 ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ
Bitmap
仕様変更:⼀度取った画像はローカルに保存しておいて • Activityはローカルストレージがどんな仕組みなのか知るべきではない • 画像取得クラスは画像の取得が責務なので、ローカルストレージは関⼼事 から外れる • 単⼀責任の原則:変更の理由は⼀つでなければならない • ローカルストレージはプラットフォームの⼀部である
• ライフサイクルが異なるロジックは分ける
画像保存クラスを作成(1) ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ
Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ※ActivityʹϏδωεϩδοΫ͕ͬͯ͠·͍ͬͯΔ
画像保存クラスを作成(2) ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ
Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
仕様変更その2:プライバシーに配慮してストレージは暗号化して • ソフトウェア開発において、仕様変更は⽇常 • 適切に設計ができていれば、影響範囲は最⼩にできる
暗号ストレージへの変更 ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ
Bitmap ը૾อଘ ҉߸ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap Өڹൣғ͚ͩ͜͜
エンジニアの平穏は保たれた
まとめ • 名のあるアーキテクチャを採⽤するだけでは設計したとはいえない • UIとビジネスロジックを分けるのはもちろん、プラットフォームも分ける • オブジェクト指向はちゃんと理解しよう • クラスの関⼼・責務を考えよう •
ドメイン駆動ができると幸せになれるかも?