2025-04-23 社内勉強会 デザインパターン概論 / Overview of Design Patterns

Transcript

1. 2025/04/23 社内勉強会 デザインパターン概論 1
2. 2 その前に
3. The Best Programmers I Know 3 最高の開発者になるために
4. • 今回、新人さんの参加があると思われる • デザインパターンの話があまりピンと来なかったり、 実務で使うまでに忘れてしまったりするかも • それだともったいないので、最近読んでよかったブログを紹介 • ※発表者による日本語訳 4 What is it?
5. 1. リファレンスを読む 2. ツールを深く理解する 3. エラーメッセージを読む 4. 問題を分解する 5. 手を汚すことを恐れない 6. 常に他者を助ける 7. 書く習慣を持つ 8. 学び続ける 5 The Best Programmers I Know 9. 地位を気にかけない 10. 評判を確立する 11. 忍耐力を持つ 12. コンピューターを責めない 13. 「わからない」と言うことを 恐れない 14. 推測しない 15. シンプルに保つ
6. 1. リファレンスを読む 2. ツールを深く理解する 3. エラーメッセージを読む 4. 問題を分解する 5. 手を汚すことを恐れない 6. 常に他者を助ける 7. 書く習慣を持つ 8. 学び続ける 6 The Best Programmers I Know 9. 地位を気にかけない 10. 評判を確立する 11. 忍耐力を持つ 12. コンピューターを責めない 13. 「わからない」と言うことを 恐れない 14. 推測しない 15. シンプルに保つ この7つを紹介
7. 7 • 理解しなくてもツールは使える（それがツール） • 優れた開発者は、自分が使っている技術を根本的なレベルで理解している • ツールをただ使っているだけでは、手探りで試行錯誤したり、 すぐに混乱したり、間違った考えを持ってしまう • ツールを理解するとは、以下を知ること ◦ 歴史：誰が作ったもの？なぜ作った？どんな課題を解決するため？ ◦ 現状：誰が管理している？その人はどこでどんな仕事をしている？ ◦ 制限：いつ使うべきか、または使わないべきか？どう使うと壊れる？ ◦ エコシステム：どんなライブラリが存在する？誰が使っている？ ツールを深く理解する Know Your Tools Really Well
8. 8 • 大きい問題や複雑な問題は、解決できるまで分解・単純化する • 習得するのが難しいスキルで、大量の経験が必要 • プロの開発者の仕事の大部分は問題の分解 問題を分解する Break Down Problems
9. 9 • 最高の開発者は、多くのコードを読み、実践する • 「自分には向いていない」「自分にできることはない」という前に学び始め ている • 周囲がその努力に気づく前に、その技術について頼りになる存在に なっている 手を汚すことを恐れない Don’t Be Afraid To Get Your Hands Dirty
10. 10 • 優れたエンジニアはいつも忙しいが、常に助けようとする • なぜなら、彼らは好奇心旺盛で、その助けようとする心によって 優れたエンジニアになったから 常に他者を助ける Always Help Others
11. 11 • コンピューターと人間、特に自分自身に対する忍耐が大切 • 学習には時間がかかる ◦ 能力が低いわけではなく、ただ不完全な情報を持っているだけ • 難しい問題を解決したり、プロジェクトを終わらせるためには 努力が必要 • 忍耐力、集中力、献身を持って臨みましょう 忍耐力を持つ Have Patience
12. 12 • コンピューターの動作がどんなに不安定でいたずらに見えても、 常に論理的な理由がある • 最高の開発者は、理由が見つかるまで深掘りする • 理由はすぐには見つからないかもしれないし、結局見つからずに 終わるかもしれない • 見つけられなくても、彼らは外部の状況のせいにしない • この態度によって、彼らは大きく成長し、他の人にはできないことを学ぶ コンピューターを責めない Never Blame the Computer
13. 13 • 推測は楽なので、我々は推測してしまいがち • 推測すると何が起きるか？ ◦ 最良の場合： ▪ あなたは間違っていて、間違った仮定がバグを生む ◦ 最悪の場合： ▪ あなたは正しく、偶然うまくいったことを正解だと思い込んでし まう • 質問したり、リファレンスを読んだり、デバッグしたりして、 答えを得ることが大事 推測しない Don’t Guess
14. 14 気になったら読んでみてね The Best Programmers I Know | Matthias Endler まとめ
15. 15 デザインパターン 閑話休題
16. 16 • オブジェクト指向における重要な概念であるデザインパターン • デザインパターンの概要の説明 • パターンをいくつか紹介 ◦ どんな状況で（When） ◦ どんな問題が発生したら（What） ◦ どのように解決するか（How） What is it?
17. 17 デザインパターンとは
18. 18 ある問題に対して、よく使われる効果的な解決方法を抽象化・定型化 した“設計のひな型”のことを指します。 ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出し た設計ノウハウを蓄積し、名前をつけ、再利用し やすいように特定の規約に従ってカタログ化したものである。 デザインパターンとは？
19. 19 ある問題に対して、よく使われる効果的な解決方法 を抽象化・定型 化した“設計のひな型”のことを指します。 ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出し た設計ノウハウを蓄積し、名前をつけ、再利用しやすいように 特定の 規約に従ってカタログ化したもの である。 デザインパターンとは？
20. 20 ある問題に対して、よく使われる効果的な解決方法 を抽象化・定型 化した“設計のひな型”のことを指します。 ソフトウェア開発におけるデザインパターンまたは設計パターン（英: design pattern）とは、過去のソフトウェア設計者が発見し編み出し た設計ノウハウを蓄積し、名前をつけ、再利用しやすいように 特定の 規約に従ってカタログ化したもの である。 デザインパターンとは？ 名前をつけたことも重要な功績 人間が認識できるようになった
21. 21 デザインパターンの原典 今日「デザインパターン」と言うと 左の書籍で紹介された23種類の パターンを指す 著者4人を敬意を込めて “Gang of Four (GoF)” と呼ぶ 本のことはGoF本と 呼んだりする
22. 22 デザインパターンの原典 1994年出版（30年前！） Java や C# は生まれていない Webアプリケーションはほとんどない 当時よく使われていた言語は C++ 書籍のサンプルコードも C++ GUIアプリケーションに適用する想定
23. 23 日本語の書籍 GoF本の日本語訳（左） 右の書籍が有名、入門書とし ておすすめ 私は読んだことないけど、 みんなそう言ってます
24. 24 1. オブジェクト指向の時代背景 2. 実践的な内容 なぜデザインパターンが普及したのか？
25. 25 GoF本が出版された当時、オブジェクト指向の認知度が高まっており、言語が いくつも登場するなど注目されていた 再利用性が高いと言われていたが、継承を間違って使っていたり、言語を変え ても設計が古いまま、といった状況が発生していた デザインパターンによって「再利用」の真の有用性が発見され、世間のオブ ジェクト指向に対する理解が深まった なぜデザインパターンが普及したのか？ 1. オブジェクト指向の時代背景
26. 26 GoF本が出版された当時、オブジェクト指向の認知度が高まっており、言語が いくつも登場するなど注目されていた 再利用性が高いと言われていたが、継承を間違って使っていたり、言語を変え ても設計が古いまま、といった状況が発生していた デザインパターンによって「再利用」 の真の有用性が発見され、世間のオブ ジェクト指向に対する理解が深まった なぜデザインパターンが普及したのか？ 1. オブジェクト指向の時代背景 オブジェクト指向における 再利用のためのデザインパターン
27. 27 デザインパターンは理論ではなく、実際に現場で何度も利用され 洗練された知恵の集大成 「こうすればうまくいく」ノウハウが詰まっている 言語に依存せず、抽象的すぎないのですぐに実践できる なぜデザインパターンが普及したのか？ 2. 実践的な内容
28. 28 • デザインパターンとは、ソフトウェア設計における問題に対して、よく使わ れる解決方法をまとめたもの • 1994年当時、オブジェクト指向が流行りはじめていたが、 使いこなせていない人が多かった • デザインパターンによって「オブジェクト指向はこうやる」という指針ができ た • その結果、めっちゃ普及した ここまでのまとめ
29. 29 1. 設計の質を高められる 2. 共通言語として利用できる 3. 言語やフレームワークに取り込まれている なぜデザインパターンを学ぶのか？
30. 30 • デザインパターンを活用することで、 保守性、拡張性、再利用性の高い設計をしやすくなる • パターンに従うことで、変更に強いコードを書ける • また、根拠をもって実装できる なぜデザインパターンを学ぶのか？ 1. 設計の質を高める
31. 31 • 「ここは〇〇パターンを使おう」のような会話ができる • 具体的な内容に言及しなくても意思疎通が可能 ◦ これが名前があることのよさ なぜデザインパターンを学ぶのか？ 2. 共通言語として利用できる
32. 32 • 言語自体が機能として提供したり、デザインパターンにしたがって 設計されたフレームワークが増えた ◦ 例えば、Java や C# はデザインパターンにかなり影響を受けている • デザインパターンを使いこなせば、より簡潔に書けたり、 フレームワークの機能を拡張できたりする なぜデザインパターンを学ぶのか？ 3. 言語やフレームワークに取り込まれている
33. 33 デザインパターンのこと、もっ と知りたくなって 来ましたね？
34. 34 デザインパターン・カタログ
35. 35 生成　🐣 • Abstract Factory • Builder • Factory Method • Prototype • Singleton パターン一覧（ 23種） 構造　🏛 • Adopter • Bridge • Composite • Decorator • Facade • Flyweight • Proxy 振る舞い　🕺 • Chain of Responsibility • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template Method • Visitor 投票　進む 参考：Refactoring.Guru
36. 36 生成🐣
37. 37 状況と問題 • たくさんのフィールドをもち、 複雑な初期化が必要なクラス • 状況に応じたサブクラスを 作るのは非現実的 • コンストラクタの呼び出しで 使われないパラメータを大量に渡す必要がある Builder 複雑なオブジェクトを段階的に構築する 一覧 参考：Refactoring.Guru 🐣
38. 38 解決方法 • オブジェクトの構築をBuilderクラスに抽出 • Builderの実装ごとに、各ステップで実施する 内容は異なる • すべてのステップを呼び出す必要はない • 構築中にProductにアクセスすることは 禁止する Builder 複雑なオブジェクトを段階的に構築する 一覧 参考：Refactoring.Guru <<interface>> Builder reset() buildStepA() buildStepB() buildStepZ() ConcreteBuilder result:Product reset() buildStepA() buildStepB() buildStepZ() getResult():Product 実装 🐣
39. 39 状況と問題 • オブジェクトの正確なコピーをしたいとする • 新規オブジェクトを作って、フィールドを一つずつコピーして。。。 ◦ privateなフィールドに対応できない ◦ すべてのフィールドを知っている必要がある 知っている＝密結合なので、よくない設計 Prototype コピーを作成する 参考：Refactoring.Guru 🐣 一覧
40. 40 解決方法 • コピーしたいオブジェクト自身に cloneメソッドを実装する ◦ 自分のprivateフィールドにはアクセスできる • 値のコピーだけでなく、コピー元と紐付けたり 特定の値を上書きしたりできる Prototype コピーを作成する 参考：Refactoring.Guru 🐣 一覧 <<interface>> Prototype clone():Prototype ConcretePrototype field clone():Prototype 実装
41. 41 構造🏛
42. 42 状況と問題 • 2種類のオブジェクト「製品」と「箱」が あるとする • 箱には、製品や、より小さい箱を入れられる • 最終的に、一つの大きな箱に入った製品の 合計金額をどうやって計算する？ Composite ツリー構造を表現する 一覧 参考：Refactoring.Guru 🏛
43. 解決方法 • LeafとCompositeはどちらも 共通のインターフェースを実装する • Leafは自分が何をするべきか 知っている • Compositeはchildrenに処理を 委任する 43 Composite ツリー構造を表現する 一覧 参考：Refactoring.Guru 🏛 <<interface>> Component execute() Composite children:Component[] add(Component) remove(Component) getChildren():Component[] execute() 実装 Leaf execute()
44. 44 状況と問題 • 例えば、システム資源を大量に消費するオブジェクトがある ◦ データベース ◦ 外部のライブラリ • 遅延初期化のようなテクニックを使う場合、あちこちに似たような処理を書 くことになる • 処理の前後でログ出力をする場合なども同様 Proxy オブジェクトへのアクセスの前後に処理を行う 一覧 参考：Refactoring.Guru 🏛
45. 45 解決方法 • 元のオブジェクトと同じ インターフェースを持つProxyクラス • Proxyクラスはリクエストを受けると 必要な処理を行って、元のオブジェクトに 処理を移譲する Proxy オブジェクトへのアクセスの前後に処理を行う 一覧 <<interface>> ServiceInterface operation() Proxy realService operation() 実装 Service operation() 参考：Refactoring.Guru 所有 🏛
46. 46 振る舞い🕺
47. 47 状況と問題 • 配列やコレクションはよく使う • 一つずつ取り出すのは自然な要求 • コレクションの構造は様々 • 「取り出し方」を毎回実装するのはとても手間がかかる • 要素を扱う側にとって、取り出される順番には興味がない Iterator たくさんあるものの中から一つずつ取り出す 一覧 参考：Refactoring.Guru 🕺
48. 48 解決方法 • 「取り出し方」をIteratorクラスに抽出する • 使う側は、コレクションの構造を気にせず インターフェースを通して要素を取得する • ConcreteIteratorを必要に応じて作る ◦ 異なるコレクション ◦ 異なる探索方法 Iterator たくさんあるものの中から一つずつ取り出す 一覧 <<interface>> Iterator getNext() hasMore():bool ConcreteIterator collection getNext() hasMore():bool 実装 参考：Refactoring.Guru 🕺
49. 49 状況と問題 • オブジェクトが状態を持つのは よくあるパターン • ある状態から別の状態に遷移したり 状態によって処理を切り替える • if文で実現しようとすると 容易に複雑化する State 状態によって振る舞いを替える 一覧 参考：Refactoring.Guru 🕺
50. 50 解決方法 • 一つの状態ごとに一つのクラスを作り、 状態固有の振る舞いを抽出する • コンテキストと呼ばれる元々のオブジェクトが、 Stateへの参照を持ち、Stateに状態関連の作業を 委任する • 特定のState同士はお互いの存在を知っている State 状態によって振る舞いを替える 一覧 参考：Refactoring.Guru <<interface>> State render() publish() 実装 Draft document:Document render() publish() Document state:State render() publish() changeState() 所有 🕺
51. 51 • デザインパターンを使ってうまく設計されているソースコードを 読むのがいちばん • 各パターンの解説を読んだ後に、Javaの実装を読んだりすると 理解が深まるかも • 自分で実装してみるとなお良し より深く学ぶには
52. 52 Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson GoF本の出版から15年後の2009年に行われた、著者らへのインタビュー この中で、今デザインパターンを再編するなら、という話題が出た 補足：15年後のデザインパターン
53. 53 （記事から抜粋） • Interpreter と Flyweight は、他のパターンとは全く異なる性質を持つ ため、「その他」という別のカテゴリに移動 • Factory Method は Factory に一般化 • パターンは「コア」「生成」「周辺」「その他」に分類する ◦ 重要なパターンを強調し、あまり使用されないパターンと区別するた め 補足：15年後のデザインパターン
54. 54 継続 • Abstract Factory • Builder • Command • Composite • Decorator • Facade • Flywight • Interpreter 新旧パターン比較 • Iterator • Mediator • Prototype • Proxy • State • Strategy • Template Method • Visitor 新規 • Dependency Injection • Extension Object • Factory※ • Null Object • Type Object 削除 • Adopter • Bridge • Chain of Responsibility • Factory Method※ • Memento • Observer • Singleton ※Factory MethodはFactoryに一般化
55. 55 コア • Command • Composite • Facade • Iterator • Proxy • Strategy • State • Template Method 新パターン一覧（ 21種） 生成 • Builder • Dependency Injection • Factory • Prototype 周辺 • Abstract Factory • Decorator • Extension Object • Mediator • Null Object • Type Object • Visitor その他 • Flyweight • Interpreter
56. • デザインパターンとは、ソフトウェア設計における問題に対して、よく使わ れる解決方法をまとめたもの • デザインパターンは時代背景に内容がマッチして、広く普及した • 現代においても技術的に重要だし、チーム内の意思疎通にも有用 • 状況、問題、解決方法を理解して、適したパターンを選択することが重要 56 まとめ
57. 57 • リファクタリング • 自動テスト リファクタリングのゴールとして、デザインパターンを 適用することを目指す リファクタリングを支える自動テスト 次に学ぶとよいもの
58. 58 参考資料 • Refactoring.Guru（Webサイト） • fukabori.fm #48 #49（ポッドキャスト）