読者です 読者をやめる 読者になる 読者になる

DRYな備忘録

Don't Repeat Yourself.

恥ずかしいデザインパターン勉強会第3回の報告【TemplateMethod】【FactoryMethod】 #hazukac

designpattern

デザパタ本第2部「サブクラスにまかせる」から

TemplateMethodパターン

ユースケース

  • 特定の共通した順序やアルゴリズムで実行される具体的な処理が複数ある場合
  • 共通した順序やアルゴリズム部分をそれぞれの具体的なクラスに書くのは面倒
  • 共通した部分の変更が発生した場合に変更範囲が大きくなってしまう

ポイント

  • 抽象化できる「共通した順序」や「共通したアルゴリズム」をスーパークラスで定義する
  • その中で呼ばれる具体的な処理は、継承したサブクラスで定義するよう制約*1する
  • そのスーパークラスを継承したサブクラスでは
    • 具体処理を定義しなければならない
    • 具体処理を定義しさえすれば「共通した順序」「共通したアルゴリズム」で実行される保証がされる

複数のキャンペーンサイトをクローリングしなければならない。HTTPリクエストを送る処理は共通だが、ページコンテンツから欲しい情報を取得する部分だけは、キャンペーンサイトごとにHTMLが違うので、独特にできない。

→ HTTPリクエストを送ってコンテンツをパースすることだけを定義したスーパークラスabstract Crawlerを定義し、パース部分のみサブクラスにまかせる。

など

FactoryMethodパターン

ユースケース

ポイント

雑感

  • 今までは「たぶんこれで良い感じの書き方になってるはずだよなぁ〜」と思いながら書いてた
  • デザインパターンを勉強しはじめて良かったのは、「今までよりも良いコードが書けるようになった」
  • ではなく、むしろ
  • 書くコードに対して「これで良いっぽい、結城も言ってた!」という自信が持てるようになったことだと感じました

f:id:otiai10:20090109144340j:plain

DRY

*1:abstractがある言語ならこれを使うけど、無いならオーバーライトされる前提でミニマムに書いておくのもよいかも