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

Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component

Fat ComponentにしないためのWebフロントエンド設計 / Web Front-End design to avoid being a Fat Component

https://lapras.connpass.com/event/179777 の登壇資料

サンプルコード
https://github.com/tooppoo/sample-for-vue-with-design-patterns
http://localhost:8080/first-class-collection-pattern/on-memory

参考資料
・オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
ソシオメディア株式会社 (著)、上野 学 (著、監修)、 藤井 幸多 (著)
・MVCとはなにか
 ・tenjuu99
 ・https://speakerdeck.com/tenjuu99/what-mvc-is
 ・https://note.com/tenjuu99/n/n0232ccd1089d
 ・https://note.com/tenjuu99/n/nbbb4b273676d
・MVC
 ・Trygve Reenskaug
 ・http://folk.uio.no/trygver/themes/mvc/mvc-index.html
・未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明
 ・Michael Hiltzik(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳)

関連する過去発表
・WEBフロントエンドにおけるソフトウェア設計の考察
 ・https://speakerdeck.com/tooppoo/consideration-of-software-design-in-web-front-end
・Vue.js + デザインパターンによるコンポーネント実装
 ・https://speakerdeck.com/tooppoo/vue-dot-js-dezainpatan-niyorukonponentoshi-zhuang-v2
・複雑なv-ifに負けないために
 ・https://speakerdeck.com/tooppoo/fu-za-nav-ifnifu-kenaitameni

philomagi

July 31, 2020
Tweet

More Decks by philomagi

Other Decks in Programming

Transcript

  1. Fat Componentにしないための
    Webフロントエンド設計
    1
    @Philomagi
    2020/07/[email protected] #2
    #remote_vue

    View full-size slide

  2. 発表者
    @Philomagi
    ● WEB系プログラマ
    ● 自称フロントエンド寄り
    ○ 最近のマイブームは SelfとSmalltalk
    ○ vanila jsも久しぶりにちょっと触りたい
    ● 設計の話とかが好きです
    ○ DDDとかクリーンアーキテクチャとか
    ○ 最近のSOLID原則の推しはI
    2

    View full-size slide

  3. 今回のテーマ
    3

    View full-size slide

  4. Fat Componentにしないための
    Webフロントエンド設計
    4

    View full-size slide


  5. 以降、特に断りが無い場合は
    「フロントエンド = Webフロントエンド」
    の意味で使います
    5

    View full-size slide


  6. 理由
    ● 題材のベースがVue.jsである
    ● 発表者自身、Webフロントエンド以外のフロントエ
    ンド(デスクトップクライアント、iOS、Android)に
    詳しくない
    6

    View full-size slide

  7. Fat Component
    7

    View full-size slide

  8. 8
    ほんとうにあったVueコンポーネント

    View full-size slide

  9. 10
    ←全体のおよそ1/5

    View full-size slide

  10. 11
    約20行<br/>

    View full-size slide

  11. 12
    約20行<br/><template> 約200行<br/>

    View full-size slide

  12. 13
    約20行<br/><template> 約200行<br/><script> 約2200行<br/>

    View full-size slide

  13. 15
    全体で
    約2500行

    View full-size slide

  14. どうすれば防げたか
    or
    どうすれば改善できるか
    16

    View full-size slide

  15. 主張
    17
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するためのルール・制約・知識は、コンポーネントから
    は独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する

    View full-size slide

  16. 主張
    18
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するためのルール・制約・知識は、コンポーネントから
    は独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する

    View full-size slide

  17. 主張
    19
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する

    View full-size slide

  18. 主張
    20
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する

    View full-size slide

  19. 主張
    21
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する

    View full-size slide

  20. コンポーネントを
    もっと細かく分割する?
    22

    View full-size slide

  21. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>23<br/>

    View full-size slide

  22. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>24<br/>

    View full-size slide

  23. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>25<br/>

    View full-size slide

  24. コンポーネント分割の効果と限界
    ● やの肥大化に対しては効果的<br/>○ 複雑なHTMLやCSS定義を分割することで、肥大化を抑制 /改善できる<br/>○ スコープが限定されることで、実装自体も単純化しやすい<br/>● <script>の肥大化に対しては限界がある<br/>○ HTML・CSSが別コンポーネントに分離されても、処理自体は親コンポーネントに残ることが多い<br/>■ v-if による表示分けのための計算など<br/>○ <script>の内容もコンポーネント毎に分離すると、「デザインだけ切り替え」が困難<br/>■ 振る舞いが子コンポーネントに依存するため<br/>■ 「デザインは変わるが振る舞いは変わらない」が困難になる<br/>肥大化の全ての要因をコンポーネント分割のみで解決するのは困難<br/>26<br/>

    View full-size slide

  25. 28
    実装サンプル
    https://github.com/tooppoo/sample-for-vue-with-design-patterns

    View full-size slide

  26. 29
    実装サンプル

    View full-size slide

  27. 実装サンプル
    カート内には
    複数の商品が存在する
    30

    View full-size slide

  28. 実装サンプル
    31
    ・買う個数を変更
    ・カートから削除
    ・削除せず後で買う
    といった操作が可能

    View full-size slide

  29. 実装サンプル
    32
    カート内の
    ・購入する商品数
    ・購入時の合計金額
    を表示
    ただし、後で買う商品は除外

    View full-size slide

  30. まずどこに注目するか
    33

    View full-size slide

  31. まずどこに注目するか
    34
    ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い
    (≠データ)に注目する
    ○ 「何がどのように見えるか」より先に、
    見せるべき知識・情報は何か、それらはどのよう
    な構造・関連を取るか、に注目する

    View full-size slide

  32. まずどこに注目するか
    35
    ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い
    (≠データ)に注目する
    ○ 「何がどのように見えるか」より先に、
    見せるべき知識・情報は何か、それらはどのよう
    な構造・関連を取るか、に注目する
    ● ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特
    定のカート内商品を「後で買う」「削除する」という操作を行うことができる

    View full-size slide

  33. まずどこに注目するか
    36
    ● UIパーツ・レイアウト・外観ではなく、ユーザーに提供する知識・情報・振る舞い
    (≠データ)に注目する
    ○ 「何がどのように見えるか」より先に、
    見せるべき知識・情報は何か、それらはどのよう
    な構造・関連を取るか、に注目する
    ● ユーザーは「カート内商品」の集まりである「カート内商品の一覧」に対して、特
    定のカート内商品を「後で買う」「削除する」という操作を行うことができる
    ● ユーザーは「カート内商品の一覧」に基づいて、合計数や合計金額を知ることが
    できる

    View full-size slide

  34. 商品カートの構造
    37

    View full-size slide

  35. 商品カートの構造
    ユーザーへ情報・振る舞いを
    提示するためのUIパーツ構造
    38

    View full-size slide

  36. 商品カートの構造
    UIを通じてユーザーが得る
    情報・振る舞い
    39

    View full-size slide

  37. 商品カートの構造
    40

    View full-size slide

  38. 商品カートの構造
    41

    View full-size slide

  39. 商品カートの構造
    UIとユーザーの間で発生する
    やり取り・相互作用
    42

    View full-size slide

  40. 実際のコード
    43

    View full-size slide

  41. 主張(再掲)
    44
    ● 何でもかんでもコンポーネントに書かない
    ● 表示・操作を実現するための知識・情報・振る舞いは、コンポーネントか
    らは独立したものとして別途定義する
    ● 全ての実装の詳細を、コンポーネントに直接記述する必然性は無い
    ● コンポーネントには具体的な表示様式と、バインディング・ハンドリングの
    みを記述する

    View full-size slide

  42. 45
    Vueコンポーネント

    View full-size slide

  43. 46
    Vueコンポーネント

    View full-size slide

  44. 47
    Vueコンポーネント

    View full-size slide

  45. 48
    Vueコンポーネント

    View full-size slide

  46. 49
    Vueコンポーネント
    コンポーネントのに書く内容は<br/>・htmlとオブジェクトプロパティ<br/>・イベントとオブジェクト操作<br/>のマッピングでほとんど終わる<br/>

    View full-size slide

  47. 50
    Vueコンポーネント
    複雑な処理や計算は
    コンポーネントから切り出した
    個々のオブジェクトに任せる

    View full-size slide

  48. 51
    Vueコンポーネント
    Vueコンポーネントは
    如何に知識を構成・表示・表現するか
    に注力する

    View full-size slide

  49. 52
    Vueコンポーネント
    UIは詳細な処理・計算よりも
    ユーザーに何を伝え、何を示すか
    に注力する

    View full-size slide

  50. コンポーネント以外のコード
    53

    View full-size slide

  51. コンポーネント以外のコード
    54
    要するに
    普通のjavascriptのコード

    View full-size slide

  52. コンポーネント以外のコード
    55
    普通のjavascriptのコードなので
    テストに必要な準備も最低限

    View full-size slide

  53. コンポーネント以外のコード
    56
    普通のjavascriptのコードなので
    オブジェクト指向でも関数型でも
    既存の方法論を活用可能

    View full-size slide

  54. ユーザーの関心事に注目する
    58
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    (=知識・振る舞い)に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の
    相互作用(= interaction)も、「オブジェクト(目当て、対象)」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい

    View full-size slide

  55. ユーザーの関心事に注目する
    59
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    (=知識・振る舞い)に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の
    相互作用(= interaction)も、「オブジェクト = 注目すべき事柄」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい

    View full-size slide

  56. ユーザーの関心事に注目する
    60
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    (=知識・振る舞い)に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ 「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の相互
    作用(= interaction)も、「オブジェクト = 注目すべき事柄」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい

    View full-size slide

  57. ユーザーの関心事に注目する
    61
    ● ユーザーがアプリケーションを通じて実現しようとしている、関心を持っている事柄
    (=知識・振る舞い)に注目する
    ○ 「知識 ≠ データ」「振る舞い ≠ CRUD操作」
    ○ ユーザーが「しよう」と思ったことを、その通りに「した」と思えるようにする
    ■ FYI 「未来を作った人々」
    ● 注目すべき事柄をオブジェクトとして定義し、可視化する
    ○ ここの「オブジェクト」は、計算処理の対象に限定されない。個々の UIパーツやユーザー-UI間の
    相互作用(= interaction)も、「オブジェクト = 注目すべき事柄」に含まれる
    ● 個々のオブジェクトの責務、オブジェクト間の関連を踏まえつつ、全体像を整理してい

    View full-size slide

  58. FW・ライブラリとどう付き合うか
    62
    ● 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利
    用する」か?
    ● FW・ライブラリは、自分たちが直面している課題を解決するための道具の一つでは
    あっても、特効薬そのものにはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか?
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    (実際、Vueは知識・振る舞いを構造化する方法は提供しない)

    View full-size slide

  59. FW・ライブラリとどう付き合うか
    63
    ● 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利
    用する」か?
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか?
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    (実際、Vueは知識・振る舞いを構造化する方法は提供しない)

    View full-size slide

  60. FW・ライブラリとどう付き合うか
    64
    ● 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利
    用する」か?
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか?
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    (実際、Vueは知識・振る舞いを構造化する方法は提供しない)

    View full-size slide

  61. FW・ライブラリとどう付き合うか
    65
    ● 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利
    用する」か?
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか?
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    (実際、Vueは知識・振る舞いを構造化する方法は提供しない)

    View full-size slide

  62. FW・ライブラリとどう付き合うか
    66
    ● 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利
    用する」か?
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか?
    ○ この発表では、知識・振る舞いと画面のバインディングを簡易かつ狭い範囲で
    行うため、と位置付けている
    ○ バインディングでは積極的にVueに頼るが、それ以外は自分たちで組み立てる
    (実際、Vueは知識・振る舞いを構造化する方法は提供しない)

    View full-size slide

  63. FW・ライブラリとどう付き合うか
    67
    ● 「FW・ライブラリを使いこなす」=「細かな機能をアプリケーション全体で全面的に利
    用する」か?
    ● FW・ライブラリは、自分たちが直面している課題を解決する道具ではあっても、特効
    薬にはなり得ない
    ● どこまでをFW・ライブラリに頼っても良く、どこからは自分達で守らなくてはならないの
    かを考える
    ● 何のために(Vue|FW|ライブラリ)を使うのか?
    ○ 個人的には、Vue(のSFC)の html/css/js がそれぞれ自身の世界観を維持し
    ている形が好き
    ○ Reactのような全てをjsの世界に引き込むのは、シンプルでプログラミングフレン
    ドリーなのだろうけれど、あまり好きではない

    View full-size slide

  64. ● 「サーバーの「データ」をプリントするだけなんだから、フロントでやること
    は何も無い」
    ○ 振る舞いはどこにいった?
    ● サーバーで提供・管理できる情報には限界が有る
    ○ 画面側の一時的・揮発的な情報は、サーバーでは管理しようが無い
    ○ 画面内部の動的な状態遷移も、サーバーでは管理・定義のしようが無い
    ■ ex. ユーザー操作に伴うUIパーツ表示のON/OFF
    ● 知識ではなく、データに強く注目・依存する考え方?
    「JSON色付け係」
    68

    View full-size slide

  65. ● Smart UI アンチパターンが戒めているのは何もかもが区別無く一箇所に混在し
    た状態で、「画面に何らかのロジックが存在すること」ではない
    ○ 「何もかもが区別無く一箇所に混在」 → 全部入りのVueコンポーネント
    ● 画面の状態や操作に関する「ロジック」を、画面以外の誰が管理するのか
    ○ 動的な表示変更も、一切のユーザー操作も提供しない
    LPなら、「ロジック」は無いと
    言って良いかもしれない
    ○ しかし、LPを基準として語れるほど、現代のフロントエンドソフトウェアは単純ではいら
    れなくなっている
    ● 「ロジック = ビジネスロジック」ではない
    ○ ビジネスロジック ∈ ロジック
    Smart UI アンチパターン
    69

    View full-size slide

  66. 私たちの生活は今、コンピューターテクノロジーに囲まれており、仕事や遊び
    の場はますますソフトウェアの中へと移動しています。私たちはもはや物質や
    距離を意識せずに情報へアクセスし、コミュニケーションができます。私たち
    は1日の多くの時間をソフトウェアの世界で過ごしているのです。私たちがソフ
    トウェアを利用する際に接するユーザーインターフェース(UserInterface:UI)
    は、もはやバーチャルな比喩的存在ではなく、リアルな目当て[オブジェクト]そ
    のものなのです。
    オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 「はじめに」
    ([ ] 内は発表者による)
    71

    View full-size slide

  67. 私たちの生活は今、コンピューターテクノロジーに囲まれており、仕事や遊び
    の場はますますソフトウェアの中へと移動しています。私たちはもはや物質や
    距離を意識せずに情報へアクセスし、コミュニケーションができます。私たち
    は1日の多くの時間をソフトウェアの世界で過ごしているのです。私たちがソフ
    トウェアを利用する際に接するユーザーインターフェース(UserInterface:UI)
    は、もはやバーチャルな比喩的存在ではなく、リアルな目当て[オブジェクト]そ
    のものなのです。
    オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 「はじめに」
    ([ ] 内は発表者による)
    72

    View full-size slide

  68. まとめ
    ● 「Vueを使っているから」とVueコンポーネントに何でもかんでも詰め込む
    と、程なくFat Componentに到達する
    ● どこまでをVueに頼り、どこからは自分たちの領域として守りたいのかを
    考える
    ● UIパーツだけでなく、その奥に潜む知識・情報・振る舞いにも注目し、構
    造化し、洗練させていく
    ● 知識・情報・振る舞いの精査を通じて、自分たちが実現しようとしている
    ものを深く理解し、ソフトウェアに反映していく
    73

    View full-size slide

  69. 雑感
    74
    ● 古典的なMVCへ回帰する可能性
    ○ 実装のための「MVCパターン」というよりは、ソフトウェアの役割を規
    程するものとしてのMVC
    ○ Trygve Reenskaug
    ● OOUIとの接続
    ○ この発表では、デザインよりプログラムに寄った視点から「オブジェ
    クト指向」+「UI」に注目している、とも言えるかも
    ○ 行き着くところは似通いそう

    View full-size slide

  70. 参考資料
    75
    ● オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
    ○ ソシオメディア株式会社 (著)、上野 学 (著、監修)、 藤井 幸多 (著)
    ● MVCとはなにか
    ○ tenjuu99
    ○ https://speakerdeck.com/tenjuu99/what-mvc-is
    ○ https://note.com/tenjuu99/n/n0232ccd1089d
    ○ https://note.com/tenjuu99/n/nbbb4b273676d
    ● MVC
    ○ Trygve Reenskaug
    ○ http://folk.uio.no/trygver/themes/mvc/mvc-index.html
    ● 未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明
    ○ Michael Hiltzik(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳)

    View full-size slide

  71. ご清聴ありがとうございました
    76

    View full-size slide