- 恥ずかしいデザインパターン勉強会 #3 - connpass を開催しました
- 会場から綺麗な東京タワーが見えました
「知らない」といえる勉強会 #hazukac
— treby@C86 3日目西き-33b (@treby006) 2014, 8月 6
デザパタ本第2部「サブクラスにまかせる」から
- TemplateMethodパターンとFactoryMethodパターンを勉強しました
- ライブコーディングのログです↓
TemplateMethodパターン
- 特定の共通した順序やアルゴリズムで実行される具体的な処理が複数ある場合
- 共通した順序やアルゴリズム部分をそれぞれの具体的なクラスに書くのは面倒
- 共通した部分の変更が発生した場合に変更範囲が大きくなってしまう
ポイント
- 抽象化できる「共通した順序」や「共通したアルゴリズム」をスーパークラスで定義する
- その中で呼ばれる具体的な処理は、継承したサブクラスで定義するよう制約*1する
- そのスーパークラスを継承したサブクラスでは
- 具体処理を定義しなければならない
- 具体処理を定義しさえすれば「共通した順序」「共通したアルゴリズム」で実行される保証がされる
例
複数のキャンペーンサイトをクローリングしなければならない。HTTPリクエストを送る処理は共通だが、ページコンテンツから欲しい情報を取得する部分だけは、キャンペーンサイトごとにHTMLが違うので、独特にできない。
→ HTTPリクエストを送ってコンテンツをパースすることだけを定義したスーパークラスabstract Crawlerを定義し、パース部分のみサブクラスにまかせる。
など
FactoryMethodパターン
- 上記のTemplateMethod的なユースケースで、とりわけ
- インスタンス生成処理に抽象的な共通が認められる場合に有効
ポイント
- インスタンス生成にTemplateMethodを用いると、これFactoryMethod
- (ぶっちゃけ釈然としなかった)
- (次回08/20にAbstractFactoryパターンをやるので、それも合わせて理解したい)
- (雑だな...w)
TemplateとFactoryパターンは継承を使わないと使えないって事でいいのかな? #hazukac
— mizutaki (@mizutaki_S) 2014, 8月 6
@mizutaki_S はい。Template Methodは継承が必要で、Factory MethodはTemplate Methodの応用なので、やはり、継承が必要です。 #hazukac
— shidaken (@shidaken) 2014, 8月 7
@shidaken ありがとうございます‼︎
そこがモヤモヤしてたのでスッキリしました。 #hazukac
— mizutaki (@mizutaki_S) 2014, 8月 7
雑感
- 今までは「たぶんこれで良い感じの書き方になってるはずだよなぁ〜」と思いながら書いてた
- デザインパターンを勉強しはじめて良かったのは、「今までよりも良いコードが書けるようになった」
- ではなく、むしろ
- 書くコードに対して「これで良いっぽい、結城も言ってた!」という自信が持てるようになったことだと感じました
DRY
*1:abstractがある言語ならこれを使うけど、無いならオーバーライトされる前提でミニマムに書いておくのもよいかも