こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
18章応用問題1
BridgeパターンもDecoratorパターンも、元々存在する概念やオブジェクトを構造化するようなデザインパターンになっているので、構造のパターンと言ってよいのではないか？となりました。
ただし、構造のパターンと振る舞いのパターンの違いってそもそもなんだろう？という話になり、特にDecoratorパターンはどのような点で構造のパターンというのか分かりにくいという話がでました。
Decoratorパターンも再帰構造を作っているので、構造を作っているっぽいというのと、例えば前章の例であれば中表紙を新たに増やすみたいな振る舞いを増やす話になると、そのためにDecoratorパターンを使ってしまうのはオーバーエンジニアリングになってしまうことが多いから、そこを分けるために意図的に構造のパターンを新たに定義したのではないかという話をしていきました。(とはいえ細かく分け過ぎでは...?という意見も出ていました)
18章応用問題2
といった例が挙がっていました。また、家に帰ったタイミングで「ただいま」という話も挙がっていましたが、微妙に分かりにくい例えな気もするという話もしていました笑
また、Observerパターンの威力や誤った使い方を痛感するという意味でも、LINEグループのモデルを幾つか作ってみるというのも面白そうだという話が出ていました。
18章応用問題3
相手にメッセージが届いたかどうかで行動を変える必要があったり、無視されたりしたら困るようなプロダクトだと使えなさそうという話が出ました。
具体的には、DMやゆうパックなどは向いていなさそうということでした。
あなたの意見
応用問題1でも議論したので割愛しました。
19章応用問題1
Template Methodは振る舞いを見つけるものであり*1、同一処理の再定義をするという意味を示しているという話が出ていました。
ただ、継承を必ず使うという点からも怪しい匂いがするよねということで、Template Methodを使った際のメリットとデメリットを整理していきました。
メリットとしては、
- DRYにできる
- 新しい機能を追加した際のテスト範囲を小さくできる
という話がありました。一方でデメリットとして、
- コンテキストが閉じておらず、オープンクローズの原則が守れない
- リスコフの置換定義が守られていないと動かなくなる
- 言語の制約を受ける
という点が挙げられました。全体的に、Template Methodが悪というよりは、継承が悪であり、もっと言えば安易な共通化を目的とした共通化が悪だという話も出ていました。
19章応用問題2&19章応用問題3
応用問題1で色々と議論したので、時間が足りず、割愛しました。
全体を通した感想
一旦本を読むことにフォーカスしようと話をしたこともあり、いよいよ終わりが見えてきて達成感も出てきました。
途中で話として出てきた、実際にそのパターンを使うことになるであろう製品や現実世界のものをモデリングしてみるというアイデアは非常に良さそうだなあと思いました。
*1:共通の属性や処理を持った抽象クラスを使っているという点では、構造っぽさもある
