若手の会での発表資料

1. ブラック企業から学ぶMVCモデル
第47回 情報科学若手の会 2014/09/15

2. who??
2
NAME
廣戸 裕大
TWITTER
@about_hiroppy
SITE
about-hiroppy.com

3. 注意1
!
!
今回はwebアプリケーションではない前提の
MVCモデルの話をします
プラガブルMVCの話はしません
あくまで例として自分のイメージでのブラック企業等なので
イメージと違ったらすいません＞＜
3

4. 注意2
!
!
所属団体とか全く関係ないです
!
4

5. 流れ
5
!
!
- MVCとはなんなのか
- ブラック企業とはなんなのか
- ブラック企業を例えにMVCのいい書き方を考察する
- まとめ

6. MVCとは？
!
!
Model View Controllerの略称
1979年
Smalltalkという言語のGUI設計で用いられた概念
6

7. Smalltalk
!
!
ゼロックスのパロアルト研究所で作られた
オブジェクト指向プログラミング言語
現在はシンコムからVisualWorksという名前で
販売されている
7

8. MVCの背景にある考え方
8

9. !
!
- Multitier Architecture
- PresentationDomainSeparation
9

10. Multitier Architecture
10
ユーザインタフェース層
アプリケーション層
ドメイン層
インフラストラクチャ層
上位層
ユーザに情報を表示しユーザの入力を解釈する
ドメイン層のオブジェクトを協調させて
アプリケーションの問題解決を行う
ビジネスに関する知識を持たず作業を調整するだけ
ビジネスロジックを表現する部分
上位のレイヤを支える一般的な技術的機能を提供する
下位層
下の層は上の層のことを知っていてはいけない！

11. PresentationDomainSeparation
!
!
Martin Fowler氏が提唱した
プレゼンテーションロジックとドメイン(ビジネス)ロジックが
分かれていると理解しやすいから分けよう！
11

12. 各要素の定理

13. Model
!
!
システム中でのビジネスロジックを担当する
問題対象としてのデータとそのデータに対する操作する
データの整合性*においての責任を持つ
データの整合性: データの変更が中途半端でつじつまが合わなくなってしまっている状況13

14. View
!
!
プレゼンテーションロジックでModelがもつ
情報の表示や更新を担当
ユーザ入力の取得の管理もする
14

15. Controller
!
!
プレゼンテーションロジックでの
ユーザー操作のインプットを担当する
ModelとViewに対して命令を出す
15

16. 16
ユーザインタフェース層
アプリケーション層
ドメイン層
View
Controller
Model
プレゼンテーションロジック
ビジネスロジック

17. Controller
View Model
17
1. 入力を通知2.処理を命令する
3.変更されたことを通知
4.表示する情報を取得

18. 18
Controller
1. 入力を通知2.処理を命令する
3.変更されたことを通知
View Model
4.表示する情報を取得
ModelがViewに通知する仕組み

19. Observerパターン
!
!
最初の初期化時,Modelに対して変更があったときに
情報を受け取りたいViewを登録する
変更されたら登録されたすべてのViewに対して通知を行う
19

20. MVCモデルとは？
!
!
Model View Controllerの略称
1979年
Smalltalkという言語のGUI設計で用いられた概念
20

21. ではwebアプリケーションでは…
21

22. ＿人人人人人＿
＞ Model2 ＜
‾ＹＹＹＹＹ‾
22

23. Model 2
!
!
MVC Model2,MVC2とも呼ばれる
1998年
JSP仕様のドラフトで提唱された
MVCをWebサービスに適応させたもの
23

24. WebBrowser
1. クライアントからのリクエスト(URL)
Controller
View Model
24
3. 結果を返す2. リクエストを通知
4. 結果を反映させる
5. レスポンス
M → V間での関係性を持たない！

25. MVCとModel 2の違い
!
!
サーバー側からいきなりModelの状態変更が
通知されることはHTTPがステートレスなのでできない
よってControllerを経由しないといけないので
ModelからViewへの通知ができない
25

26. MVCを使うことによるメリット
!
!
- 機能別に分かれているのでテストがしやすい
- ViewとModelでの並行開発が可能となる
- ほかの部分の変更による影響を受けにくい
- 相互参照の回避が容易
- 再利用性が高い
26

27. 本題
ブラック企業から学ぶ
MVCモデル
27

28. ブラック企業 …
28
!
!
ブラック企業（ブラックきぎょう）またはブラック会社（ブラックが
いしゃ）とは、広義としては暴力団などの反社会的団体との繋がりを
持つなど違法行為を常態化させた会社を指し、狭義には新興産業にお
いて若者(わかもの)を大量に採用し、過重労働・違法労働によって使
いつぶし、次々と離職に追い込む成長大企業を指す
!
cf. wikipedia ブラック企業

29. 29
⚠ あくまで個人的なイメージです

30. ブラック企業大賞2014
30
ノミネート要努力賞
株式会社 大庄(居酒屋チェーン「日本海庄や」)
JＲ西日本
株式会社 ヤマダ電機
株式会社 A-1 Pictures
タマホーム株式会社
東京都議会
株式会社リコー
株式会社 秋田書店
学校法人智香寺学園 正智深谷高等学校・ 株式会社 イスト
実行委員会は９月に入って、緊急ノミネートとしてさらに以下の２企業が緊急に追加された。
!
株式会社 不二ビューティ（たかの友梨ビューティクリニック）
株式会社ゼンショー（すき家）
株式会社ゼンショー（すき家）
大賞
株式会社 ヤマダ電機

31. 31 http://doda.jp/lab/black/

32. 32

33. 目的
!
!
Fat Controllerを避ける
33

34. 34
Controller
主人公
社員(家電量販店)

35. Model
効率化ツール
管理ツール
35

36. 36
View
上司

37. ブラック企業系社員
!
!
社員(Controller)が一番頑張るパターン
また、効率ツール(Model)が貧弱であるパターン
37

38. 38
365日24時間働け！

39. 社員(Controller)
2.
在庫の存在確認,
在庫を取得して
在庫の数を減らす
在庫状況の更新 etc …
上司(View) ツール(Model)
39
1. 仕事を通知
3. 仕事が終わったことを通知
4. データの取得

40. ブラック企業系社員
40
大量の仕事(ユーザからの入力)
仕事の処理をして
更新をする
仕事が終わったことを知らせる

41. 41
問題点 1
ControllerがModelの値を操作する処理をするため
カプセル化ができていない

42. 42
顧客情報を盗む
転売
⚠ ブラック企業とは関係ありません

43. 43
問題点 2
全体の処理は単一ではないのでControllerに書くと
肥大化してしまう

44. 44
在庫管理
生産
生産

45. 45
問題点 3
手続きがControllerに書かれることでModelの再利用の
メリットが減ってしまう

46. 46
処理
A,B,C …
処理
A,B

47. 47
処理
A,B,C …

48. 働き過ぎ！！
48

49. 49
ではどうすればControllerの仕事量を軽減させるか

50. 当たり前ですが…
Modelにビジネスロジックを書く
50
つまり…
ブラック企業はもっとツールを自動化するべき(?)

51. 一般企業系社員
!
!
社員(Controller)は通知だけをする
51

52. 社員(Controller)
1. 仕事を通知2. 仕事が来たことを通知
上司(View) ツール(Model)
52
3. 仕事が終わったことを通知
4. データの取得

53. 一般企業系社員
53
仕事(ユーザからの入力)
仕事の処理をして
更新をする
仕事が終わったことを知らせる
仕事の処理を依頼する

54. これまだ社員(Controller)の仕事
減らせるよね？
54

55. 一般企業系社員
55
仕事(ユーザからの入力)
仕事の処理を依頼する
仕事が終わったことを知らせる
Controllerがする
必要性はない

56. ホワイト企業系社員
!
!
社員(Controller)は通知だけをするが
仕事(処理)の通知をするだけで終了の通知はしない
56

57. 社員(Controller)
1. 仕事を通知2. 仕事が来たことを通知
上司(View) ツール(Model)
57
3. 仕事が終わったことを通知
4. データの取得

58. ホワイト企業系社員
58
仕事(ユーザからの入力)
仕事が終わったことを 仕事の処理を依頼する
知らせる

59. 社員(Controller)
1. 仕事を通知2. 仕事が来たことを通知
上司(View) ツール(Model)
59
3. 仕事が終わったことを通知
4. データの取得
ModelがViewに通知する仕組み

60. Observerパターン
!
!
最初の初期化時,Modelに対して変更があったときに
情報を受け取りたいViewを登録する
変更されたら登録されたすべてのViewに対して通知を行う
60

61. Observerパターン
61
観察者通知者
View Model
事前に登録しておく
自分自身にchangeのメッセージを送る
登録されたViewに対して
updateのメッセージを送る
dependency

62. 62
もしかして社員(Controller)いらなくないですか？

63. 63
仕事(ユーザからの入力)
仕事の処理を依頼する
仕事が終わったことを通知

64. 64
問題点
!
!
1. 互いに相手の機能を呼び合っている点
2. Modelは相手のことを知ってはいけない

65. 問題点1
65
!
!
互いに相手の機能を呼び合っている点
!
密結合の状態の場合
一方の変更が他方に影響を及ぼす可能性がある

66. 問題点2
66
!
!
Modelは相手のことを知ってはいけない
!
ViewやControllerを参照できるような設計はいけない
ModelがViewと一対一での対応をしない可能性があるから

67. 必要！
67

68. 68
まとめ

69. MVCの本質
!
!
疎結合
!
ViewかModelで変更が生じても
Controllerを置くことにより問題を吸収できる
“デザイン”と”ロジック”における分業化
69

70. Controllerの肥大化を防ぐ
70
!
!
- Modelの役割を理解する
決してデータの入れ物ではなく入れ物にいれる役割もある
- Controllerの処理範囲
Viewの都合に引っ張られる部分を処理する
!

71. 71
最後に…

72. !
!
人それぞれMVCに対しての捉え方が違うと思いま
すのでこれが必ず正しいとは限りません！
!
72

73. 参考文献
73
!
!
- Separating User Interface Code
http://martinfowler.com/ieeeSoftware/separation.pdf
- The Model-View-Controller (MVC)
http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf
- Model-View-Controller
http://www.cue.im.dendai.ac.jp/~masuda/mvc/

74. !
!
ご清聴ありがとうございます！
74