Downloaded 24 times
凡人の凡人による凡人のためのデザインパターン第一幕 Public
- 1.
- 2.
- 3.
- 4. 失敗例 • 「どう使っていいのかわからない」 • 「そんなものなくても動く」 •「無駄じゃね？」 • 「パターン適用したコードが読みづらい」
- 5. 狙い • デザインパターンの意義を知る • GoFデザインパターンの分類を知る •Factory Methodパターンを知る • AbstractFactoryパターンを知る • デザインパターンの注意点を知る
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. Gang of Four •ある４人が基本的なデザインパターンを２３種類にまとめた • エーリッヒ・ガンマ • リチャード・ヘルム • ラルフ・ジョンソン • ジョン・ブリシディーズ • そのため、GoF(４人組)のデザインパターンと呼ばれる • 日本的に言えば「四天王」みたいなニュアンスか？
- 14.
- 15.
- 16. 目的と範囲 • GoFは、目的と範囲で分類される • 目的とは、パターンが何をするかを示す •範囲とは、主に適用されるのが何かを規定する
- 17. 目的による分類 • 目的には、生成、構造、振る舞いがある • 生成は、オブジェクト生成のプロセスを扱う •構造はクラスまたはオブジェクトの構成を扱う • 振る舞いは、クラスあるいはオブジェクト間の 通信方法を特徴付る
- 18. 範囲による分類 • 範囲にはクラスまたはオブジェクトがある • クラスパターンはクラスとサブクラス間の関連 •オブジェクトパターンは、オブジェクト間の関 連を扱う
- 19.
- 20.
- 21. 目的による分類 • デザインパターンの目的は、もちろん３つだけ ではない。 • 並行処理のパターン •分散プログラミングのパターン • ドメイン依存のパターン
- 22. GoFの目的は • GoFが分類しているのは、「生成」「構造」「 振る舞い」の三つ • これらは、オブジェクト指向プログラミングを する上で、必ず考えなければならない。 •よってGoFは、最もよく使う、基本的なパター ンがまとめられているということ
- 23. 「生成」 • オブジェクトは、必ず「生成」される • 設計上において、必ず考えなければならない責 務の一つ •「どうやってオブジェクトを生成するか？」と いう問題に対するパターン
- 24. 「構造」 • オブジェクトは、必ず他のオブジェクトと組み 合わせて利用される。 • オブジェクト指向プログラミングで、一つのオ ブジェクトだけで完結するアプリケーションは ほぼありえない。 •「どうやって組み合わせるか？」という問題に 対するパターン
- 25. 「振る舞い」 • オブジェクトは、必ず他のオブジェクトとやりとり をする • オブジェクト指向プログラミングにおいて、「振る 舞い」が存在しないアプリケーションはありえない 。（メソッドが一つも存在しないアプリケーション はありえない） •「どうやってオブジェクトに振る舞いをさせるか？ 」という問題に対するパターン
- 26.
- 27.
- 28. 「オブジェクト」の範囲 • 問題を解決するために、「オブジェクト」を利用 する • つまり、あるオブジェクトの問題を解決するため に、他のオブジェクトを利用することになる •オブジェクト指向の「メッセージ」を利用するこ とになる（平たく言うとメソッドなど） • 動的と言える
- 29.
- 30.
- 31. Creator FactoryMethod() OnOperation() Concrete Creator FactoryMethod() Product Concrete Product 生成 生成 継承実装 OnOperationがFactoryMethodを利用
- 32.
- 33. Abstract Factory Abstract Product Client ConcreteFactory Concrete Product 実装 実装 利用 生成生成
- 34.
- 35. Factory Method • FactoryMethodは、Productを生成したオブジェ クトがそのままProductを利用する。 • つまり、Factory Methodを持つオブジェクトは 、Factory Methodのクライアントでもある。 • よって、「クラス範囲」に分類されるパターン
- 36. AbstractFactory • Abstract Factoryは、生成したProductを利用する クライアントが、別のオブジェクトとして存在 する。 •つまり、Abstract Factoryとは別のオブジェクト が存在する。 • よって、「オブジェクト範囲」のパターン
- 37. Factory Methodの利点 • 以下の場合に有効 •Creatorが、生成しなければならないオブジェ クトを事前に知ることができない場合 • サブクラスに責任を集中させたい場合
- 38. Abstract Factoryの利点 • 以下の場合に有効 •部品の集合が複数存在し、かつ、組み合わせを 選ぶ場合 • インターフェースは公開しておきたいが、実装 は非公開にしたい場合 • システムを、「部品の生成ルール」や「組み合 わせのルール」などから独立させたい場合
- 39.
- 40.
- 41.
- 42. オブジェクト生成の複雑さ • 例えば、「車」というオブジェクトを生成する のは複雑とする。 • 「車」は、「エンジン」「タイヤ」「エアバッ ク」など’、様々な部品から成り立つ。 •「車」というオブジェクトを生成するとき、「 これらをどう組み合わせるか？」と問題になる
- 43.
- 44.
- 45.
- 46. 開発の流れ • まずは、要求仕様を明確にする • その後、モデル化する •モデルを忠実に設計する • 実装を考慮した設計を加える • コーディング
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. デザインパターンの再利 用 • デザインパターンは、再利用する部品を「オブジェ クト指向」として提供する。 • オブジェクト指向でないのであれば、デザインパタ ーンでの再利用がそもそも不可。 •つまり、デザインパターンを適用した素晴らしいコ ードも、「オブジェクト」という概念を共有するこ とができず、「なんだこの変なコードは」と言われ て終わる。
- 53.
- 54. 注意点 • むやみやたらにデザインパターンを適用すべき ではない • 全てのオブジェクト生成にFactoryMethod等を 適用すると大変なことになる（経験談 • 「複雑なこと」を、ちょっとマシにするために 、「まだマシと言える複雑なこと」をするのが 、デザインパターン
- 55.
- 56. まとめ • デザインパターンの分類 • FactoryMethodとAbstract Factory • デザインパターンとオブジェクト指向 • 「コードにこだわり()のある人」として言われて も負けない強い心
- 57.