Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Androidアプリにおけるソフトウェア設計の考え方

 Androidアプリにおけるソフトウェア設計の考え方

2018/3/12 Bonfire Android #3
https://yj-meetup.connpass.com/event/79749/

0875646c456281936f571c676da7aee0?s=128

Yohei Murayama

March 12, 2018
Tweet

Transcript

  1. Androidアプリにおけるソフトウェア設計の考え⽅ 2018/3/12 @yomuraya Bonfire Android #3

  2. ⾃⼰紹介 • 村⼭ 庸平(むらやま ようへい) • ヤフー株式会社 • しんそつ2004(14年⽬) •

    2011年ごろからAndroid • Yahoo! JAPANウィジェット • Yahoo! JAPANアプリ • Yahoo!カーナビ • Yahoo! MAP • 最近Arduinoをはじめました
  3. はじめに • 設計のお話中⼼のため、実装の話は出てきません • あくまで考え⽅なので、お困りごとは解決出来ないかもしれません • OOD、DDDにピンと来る⽅は知ってる内容かもしれません • 時間の関係で説明しきれない箇所が出るかもしれません •

    詳しくは懇談会のときにでも
  4. アジェンダ • アーキテクチャのおさらい • アプリにおける設計の考え⽅ • 簡単な設計例

  5. よく使われるアーキテクチャ

  6. Model-View-Controller Model View Controller

  7. Model-View-Controller • 古くからあるアーキテクチャ • ユーザーの⼊⼒はControllerからModelに通知される • データの変更はModelからViewに通知される • GUIに適応するとViewとControllerが密結合になりやすい

  8. Model-View-ViewModel View ViewModel Model

  9. Model-View-ViewModel • Microsoft Silverlightで採⽤されたアーキテクチャ • ViewとModelをViewModelでつなぐシンプルなしくみ • ユーザーの⼊出⼒はViewに集約されるため考えやすい • データバインディングと相性がよい

    • Modelを細分化するとViewModelが肥⼤化する
  10. The Clean Architecture https://github.com/android10/Android-CleanArchitecture

  11. The Clean Architecture • “ボブおじさん”ことロバート・C・マーチン⽒提唱 • UIやフレームワーク、DBなどが密結合にならないように層を分離する • より内部に⾏くほど他から影響を受けない実装になる •

    外側に⾏くほど、よりシステムやUIに特化した実装になる
  12. アプリ設計の考え⽅

  13. それぞれのアーキテクチャの共通点 • View(UI)とModelを分離したい • Model=ビジネスロジック • モデル≠データストア • Web時代とViewの定義が異なってきている •

    Web:主に表⽰のみ。⼊⼒はURLで別に来る • App:⼊⼒も出⼒も担当
  14. アプリにおけるビジネスロジック • ビジネスロジック=
 全ロジック ー (UIに依存したロジック + プラットフォームに依存したロジッ ク) •

    ⾔い換えれば、UIにもプラットフォームにも依存しないロジック • プラットフォームはビジネスを実現する⼿段であってやりたいことではない • ライフサイクルが異なるロジックを混ぜるべきではない
  15. ロジックのライフサイクル • UIに依存するロジック • ⾒た⽬の変更は何よりライフサイクルが早い • ユーザーが使いにくいとわかればすぐに変更される • プラットフォームに依存するロジック •

    Androidの場合、年に1〜2回新しいAPI Levelが追加される • iOSの場合、年に1回ごっそりプラットフォームが変わる
  16. ここまでの設計 UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ

  17. ここまでの設計 • UIとプラットフォームを分けたが、ビジネスロジックが整理されていない • アーキテクチャを導⼊しただけでは、複雑なソフトウェアになりがち • ビジネスロジックをどう分けるかをしっかり議論しないと、アプリの設計 とはいえない

  18. ビジネスロジックを整理する⽅法 • オブジェクト指向分析設計(OOAD) • ドメイン駆動設計(DDD)

  19. オブジェクト指向分析設計(OOAD) • 作りたいアプリの中にあるすべての情報を概念モデルに落 とし込み、クラスとインタフェースで表現する • 設計時にはUMLが使われる事が多い(クラス図、シーケン ス図など) • クラス、インタフェースを設計するときはSOLID原則に従 う

  20. (参考)SOLID原則 • 単⼀責任の原則(SRP) • 開放/閉鎖の原則(OCP) • リスコフの置換原則(LSP) • インタフェース分離の原則(ISP) •

    依存性逆転の原則(DIP)
  21. ドメイン駆動設計(DDD) • アプリで⾏いたいことを「ドメイン」と呼び、それをモデ ル化していく • チーム内で話されている⾔葉を共通⾔語(ユビキタス⾔ 語)として、それを設計に取り込む • アプリに出てくる「名詞」や「動詞」がそれぞれクラスや メソッドに対応するようになる

    • 極論を⾔えば、設計書を⾒ればアプリの実装がわかるよう になる
  22. 具体的なビジネスロジックの整理

  23. お題:ボタンを押したら画像を表⽰する Button Activity OkHttp ImageView ΫϦοΫΠϕϯτ URL byte[] Bitmap

  24. 関⼼の分離 • ActivityはUIを管理するクラスであるので、ビジネスロジックを書くには 不適切 • ActivityはImageViewに渡すBitmapが欲しいのであって、byte[]が必要な のではない • URLもActivityが知っている必要はない •

    関⼼を分けることで境界を作る
  25. 画像取得クラスを作成 ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ

    Bitmap
  26. 仕様変更:⼀度取った画像はローカルに保存しておいて • Activityはローカルストレージがどんな仕組みなのか知るべきではない • 画像取得クラスは画像の取得が責務なので、ローカルストレージは関⼼事 から外れる • 単⼀責任の原則:変更の理由は⼀つでなければならない • ローカルストレージはプラットフォームの⼀部である

    • ライフサイクルが異なるロジックは分ける
  27. 画像保存クラスを作成(1) ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ

    Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ※ActivityʹϏδωεϩδοΫ͕࢒ͬͯ͠·͍ͬͯΔ
  28. 画像保存クラスを作成(2) ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ

    Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
  29. 仕様変更その2:プライバシーに配慮してストレージは暗号化して • ソフトウェア開発において、仕様変更は⽇常 • 適切に設計ができていれば、影響範囲は最⼩にできる

  30. 暗号ストレージへの変更 ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ

    Bitmap ը૾อଘ ҉߸ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap Өڹൣғ͸͚ͩ͜͜
  31. エンジニアの平穏は保たれた

  32. まとめ • 名のあるアーキテクチャを採⽤するだけでは設計したとはいえない • UIとビジネスロジックを分けるのはもちろん、プラットフォームも分ける • オブジェクト指向はちゃんと理解しよう • クラスの関⼼・責務を考えよう •

    ドメイン駆動ができると幸せになれるかも?