Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

凡人の凡人による凡人のためのデザインパターン第一幕 Public

1,629 views

Published on

2016/06/25 でがらし会

Published in: Software
  • Be the first to comment

凡人の凡人による凡人のためのデザインパターン第一幕 Public

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

×