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
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
430
MapLibreとAmazon Location Service
dayjournal
1
170
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
14
35k
Google Cloud Next '24でブログを10本書いた方法と勉強会を沸かせた方法
yasumuusan
0
320
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
900
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
690
今日からできる!簡単 .NET 高速化 Tips -2024 edition-
xin9le
7
3.4k
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
2
590
LayerXにおけるLLMプロダクト開発の今までとこれから
layerx
PRO
3
590
アクセス制御にまつわる改善 / Improving access control
itkq
0
580
Grafana x PagerDuty Better Together
jacopen
1
240
VSCodeの拡張機能を作っている話
ebarakazuhiro
1
750
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
228
130k
Automating Front-end Workflow
addyosmani
1357
200k
GitHub's CSS Performance
jonrohan
1025
450k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
46k
Producing Creativity
orderedlist
PRO
338
39k
Faster Mobile Websites
deanohume
300
30k
The MySQL Ecosystem @ GitHub 2015
samlambert
244
12k
Ruby is Unlike a Banana
tanoku
96
10k
How GitHub (no longer) Works
holman
305
140k
The Cult of Friendly URLs
andyhume
74
5.7k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
From Idea to $5000 a Month in 5 Months
shpigford
378
45k
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とビジネスロジックを分けるのはもちろん、プラットフォームも分ける • オブジェクト指向はちゃんと理解しよう • クラスの関⼼・責務を考えよう •
ドメイン駆動ができると幸せになれるかも?