Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
Similar to Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性 (7)
Strategy パターンと開放/閉鎖原則に見るデザインパターンの有用性
- 2. 講師からの本日のお願い
- 7. お願い 今日のルール!
- 10. お願い 本題に入ります
- 11. デザインパターンとは?
- 12. デザインパターンとは? ● 書籍『オブジェクト指向における再利用のためのデ ザインパターン』において、GoF (Gang of Four; 四 人組) と呼ばれる4人の共著者は、デザインパターン という用語を初めてソフトウェア開発に導入した。 GoFは、エーリヒ・ガンマ、リチャード・ヘルム、 ラルフ・ジョンソン、ジョン・ブリシディースの4 人である。彼らは、その書籍の中で23種類のパター ンを取り上げた。 – Wikipedia より
- 15. デザインパターンとは? ● 書籍「オブジェクト指向における再利用のため のデザインパターン」の「再利用のための」と いうのが大事だと思う ● 再利用って何? – 過去の資産(書いたプログラム)を使いまわせるとい うこと! – 再利用が可能ならば生産性があがる!
- 16. デザインパターンとは? ● よく使う処理を関数化すれば再利用できるん じゃないの? – そうもいかないことがたくさん ● デザインパターンは再利用化の助けになる手法 の一つ
- 17. 今日やること ● 本日はデザインパターンの形のお話はあまりし ません – 形は大事ではないので... ● デザインパターンを適切に使った時のメリット についてお話しします
- 21. とある開発会社の日常
- 22. ● とある開発会社は様々なツールを開発している ● 本日例で挙げるツールはすべてディレクトリの 中身を再帰的に表示する機能がある – 分かりやすくするために、本日はこの機能だけの部 分でお話しします
- 23. 序章
- 31. 第一章 共通ライブラリ化
- 32. 共通ライブラリ化 /** * 指定されたパスのファイル・ディレクトリの一覧を再帰的に表示します。 * @param nodePath {String} 探索する最初のファイルまたはディレクトリ。 */ function displayRecursive(nodePath) { console.log(nodePath); // ディレクトリかファイルかを調べる var stat = fs.statSync(nodePath); if (stat.isDirectory()) { // ディレクトリの場合は配下のディレクトリ・ファイル一覧を取得して // 再帰呼び出しをして子を表示する var children = fs.readdirSync(nodePath); children.forEach(function (child) { displayRecursive(path.join(nodePath, child)); }); } } ● 共通ライブラリとして抽出した関数がこちら – 定番の再帰呼出し
- 33. 共通ライブラリ化 displayRecursive(process.argv[2]); ● ツールAの呼び出し部分はこんなの – 引数にパスを渡してる ● 実行結果はこんなの $ node a.js ./ ./ ./a.js ./hoge ./hoge/hoge.txt ./hoge/README.md
- 36. 第二章 ツールBの開発
- 40. ツールBの開発 /** * 指定されたパスのファイル・ディレクトリの一覧を再帰的に表示します。 * @param nodePath {String} 探索する最初のファイルまたはディレクトリ。 * @param options {Object} オプション。 */ function displayRecursive(nodePath, options) { var line = ''; if (options && options.lineNumber) { // オプションに合わせて行番号を先頭に表示 line += options.lineNumber + ': '; options.lineNumber++; } line += nodePath; console.log(line); // ディレクトリかファイルかを調べる var stat = fs.statSync(nodePath); if (stat.isDirectory()) { // ディレクトリの場合は配下のディレクトリ・ファイル一覧を取得して // 再帰呼び出しをして子を表示する var children = fs.readdirSync(nodePath); children.forEach(function (child) { displayRecursive(path.join(nodePath, child), options); }); } } ● こんな感じ
- 41. ツールBの開発 displayRecursive(process.argv[2], { lineNumber: 1 }); ● ツールBの呼び出し部分はこんなの – 引数にパスを渡してる ● 実行結果はこんなの $ node a.js ./ 1: ./ 2: ./a.js 3: ./hoge 4: ./hoge/hoge.txt 5: ./hoge/README.md
- 44. 第三章 ツールCの開発
- 46. ツールCの開発 BOCCO君「できました!」 担当者C「あ、ごめんファイルサイズは 行頭じゃなくて行末に出して!」 担当者C「悪いんだけど、急いでくれない?」 BOCCO君「急いでやります!」
- 54. ツールCの開発 担当者B「お客さんに報告してくるんで」 担当者B「理由を教えて」 BOCCO君「かくかくしかじか...」 担当者B「お客さんに説明してくるね」 BOCCO君「ごめんなさい...」
- 60. ツールCの開発 担当者A「多分だと困るなあ...」 BOCCO君「あ、担当者Bさんと同じように、 修正内容に承認をもらうのは どうでしょうか?」 担当者A「あ、それだと助かるね!以後よろしく!」
- 61. 第四章 要求は増えていき...
- 63. 要求は増えていき... ● 要求例として... – ファイルサイズだけでなく、ブロックサイズも表示 して! – 行番号に0を付けて桁を揃えて欲しい – パーミッションを表示したい
- 66. 要求は増えていき... 担当者E「担当者Aさん帰ってきたよね?まだ?」 BOCCO君「今度は担当者Cさんがだめだって...」 担当者E「えー、説明の仕方が悪いんじゃない?」 BOCCO君「はい...」
- 70. 終章 さらなる試練が...
- 79. デザインパターンのある世界
- 80. デザインパターンのある世界 ● 共通ライブラリって作るの難しいんです – 適当にやると今回の例みたいになります – 共通ライブラリに機能追加を拒否されると、ツール 側はすごく困るのでなんとしてでも押しこもうとし ます – 既存のツールは修正が入るのを嫌がるので、機能追 加を拒否しようとします – その駆け引きでスケジュールがズレまくります
- 81. デザインパターンのある世界 ● 最悪なパターンとして... – 共通ライブラリのせいでツールの品質が上がらない ● 共通ライブラリに必要な機能がないからできません! – 政治的なやりとりが増え、コードを書く時間が取れ ない – ますます、共通ライブラリを修正しない方向で逃げ ようとする – ますます、ツールの品質が上がらない悪循環
- 86. ストラテジーパターンの導入
- 89. ストラテジーパターンの導入 /** * 指定されたパスのファイル・ディレクトリの一覧を再帰的に表示します。 * @param nodePath {String} 探索する最初のファイルまたはディレクトリ。 * @param optDisplay {Function} ファイル・ディレクトリを表示する関数。 */ function displayRecursive(nodePath, optDisplay) { var display = optDisplay || function (line) { console.log(line); }; display(nodePath); // ディレクトリかファイルかを調べる var stat = fs.statSync(nodePath); if (stat.isDirectory()) { // ディレクトリの場合は配下のディレクトリ・ファイル一覧を取得して // 再帰呼び出しをして子を表示する var children = fs.readdirSync(nodePath); children.forEach(function (child) { displayRecursive(path.join(nodePath, child), display); }); } } ● こんな感じで出力用関数を引数に渡す
- 90. ストラテジーパターンの導入 /** * 行番号込みで表示する関数を生成するファクトリ */ function makeLineNumber () { var lineNumber = 1; return function (nodePath) { console.log(lineNumber + ': ' + nodePath); lineNumber++; }; }; displayRecursive(makeLineNumber()); ● ツールBでは行番号付きで出力する関数を作る – 分かりにくいかもしれないので、質問してね!
- 98. 開放/閉鎖原則
- 100. 開放/閉鎖原則 ● 開放/閉鎖原則(Open-Closed Principle) – 拡張に対して開いていなければならず(Open) – 修正に対して閉じていなければならない(Close)
- 101. 開放/閉鎖原則 ● とある会社の例だと... ● 行番号の追加でコードを修正する必要があった – 修正の必要がある → 修正に対して閉じていない – 修正しないとできない → 拡張に対して開いていな い ● まったく逆...
- 102. 開放/閉鎖原則 ● ストラテジーパターン導入の例だと... – 行番号の追加でコードを修正する必要がなかった ● 修正の必要がない → 修正に対して閉じている ● 修正しなくてもできる → 拡張に対して開いている
- 103. 開放/閉鎖原則 ?????
- 104. 開放/閉鎖原則 ● 修正に対して閉じていると何がいいのか – 共通ライブラリを修正すると、それを使っている ツールはすべて再テストになる – 修正に対して閉じているということは修正しなくて もいいので、ツールの再テストが避けられる ● 拡張に対して開いていると何がいいのか – 共通ライブラリを修正しなくてよい! – その分すぐに作れる
- 105. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 ここが修正されると! 全部再テスト!全部再テスト!全部再テスト!全部再テスト! つまり 共通ライブラリは 修正したくないんです
- 106. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D 共通ライブラリ側に 各ツールの関心事 どのように出力するか?が含まれていると...
- 107. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D どのように出力したいか?が変わると...
- 108. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D 実は共通ライブラリ側に手を入れる必要がある
- 109. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D 変更発生! 全部再テスト!全部再テスト!全部再テスト!全部再テスト!
- 113. 開放/閉鎖原則 でも実は...
- 116. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D どう出力するかの関心事が各ツールの方にあると...
- 117. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D どう出力するかの変更があっても
- 118. 開放/閉鎖原則 共通ライブラリ ツールA ツールB ツールC ツールD 依存 関心事A 関心事B 関心事C 関心事D どのように出力したいか?が変わる と... 変更発生! 他のツールは再テスト必要ない
- 119. 開放/閉鎖原則 ● まとめ – 開放/閉鎖原則大事! – 再利用を考えているところはこれに従う – 共通ライブラリの関心事か利用する側の関心事かの 判断は大事 – ストラテジーパターンは開放/閉鎖原則のための手 法の一つ
- 120. デザインパターン質疑応答
- 121. どうやって勉強すればいいです か?
- 122. どうやって勉強すればいいですか? ● 適用後・適用前が比較できる書籍を読んでくだ さい ● 有名なフレームワークも参考になります – 複雑だと思ってたものが、実はデザインパターンが 使われてて、拡張性のためにそうなっているってい うものも
- 129. どうやって勉強すればいいですか? ● 結城さんごめんなさい! – 結城さんはいい書籍たくさん書いています! ● おすすめしない理由... – 適用前のコード → 問題点の説明 → 適用してどうな るかのサイクルがちょっと分かりにくい – ある程度理解してから読むと、メリットをきちんと まとめてあるので結構役に立ちます
- 130. いつデザインパターンを使えばいいですか?
- 131. いつデザインパターンを使えばいいですか? ● 難しい... ● 各デザインパターンのメリットを理解して適切 に使わないといけない ● 必要のないところに使うと可読性が低下する
- 132. いつデザインパターンを使えばいいですか? ● 使った方がいいと自信を持って言えるところは 使った方がいい ● 悩むところは使わない – ただし、後々の修正で必要になったらリファクタリ ングしてデザインパターンを導入する
- 133. いつデザインパターンを使えばいいですか? ● とある会社の例だと、共通ライブラリを作った段 階ではデザインパターンを導入していなくても問 題ない ● ツールBで共通ライブラリに手を入れる必要が出 たときに、将来も似たような変更の可能性が高い なら、導入する ● 導入するなら早い方がいい – 導入を遅らせると利用者が増えるので、リスクが増え て、リファクタリングを躊躇する傾向がある
- 135. いつデザインパターンを使えばいいですか? ● 大事な事は... – 非デザインパターンなコードにデザインパターンを 導入する能力 – デザインパターンを後から導入しやすいコードを書 く能力
- 138. 全部覚える必要ある?
- 139. 全部覚える必要ある? ないです!
- 140. 全部覚える必要ある? ● 言語に取り込まれていたり ● 形が似てるので覚えやすかったり ● 使い道があまりないのとか... ● そもそもデザインパターンに含めるべきものか どうか怪しいものも...
- 141. まとめ
- 142. まとめ ● デザインパターンを適切に使うと再利用性が高まる – 再利用のためじゃないものもあるけどね... ● 再利用性が高いと開発が楽になる ● 開放/閉鎖原則、大事 – 拡張性が高くなる – 拡張性が高ければ共通ライブラリを修正しないですむ ● 書籍や既存のフレームワーク使って勉強しましょう! – 適用前・適用後・メリットを考えながら
- 143. まとめ ● プログラムの原則は馬鹿にできないよ – 開放/閉鎖原則 – 単一責任の原則 – 依存関係逆転の原則 – 他にも...
- 145. ご清聴ありがとうございました!