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 Slide

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

    View Slide

  3. 今回のテーマ
    3

    View Slide

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

    View Slide


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

    View Slide


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

    View Slide

  7. Fat Component
    7

    View Slide

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

    View Slide

  9. 9

    View Slide

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

    View Slide

  11. 11
    約20行<br/>

    View Slide

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

    View Slide

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

    View Slide

  14. 14
    全体で

    View Slide

  15. 15
    全体で
    約2500行

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  27. 実装例
    27

    View Slide

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

    View Slide

  29. 29
    実装サンプル

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. 商品カートの構造
    37

    View Slide

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

    View Slide

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

    View Slide

  40. 商品カートの構造
    40

    View Slide

  41. 商品カートの構造
    41

    View Slide

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

    View Slide

  43. 実際のコード
    43

    View Slide

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

    View Slide

  45. 45
    Vueコンポーネント

    View Slide

  46. 46
    Vueコンポーネント

    View Slide

  47. 47
    Vueコンポーネント

    View Slide

  48. 48
    Vueコンポーネント

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  57. 考え方
    57

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  70. 70

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  75. 参考資料
    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 Slide

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

    View Slide