実施日時：2019/7/17
対象範囲：第2章～第4章
参加者：mizzsugar(みずき)、yodai、yoridori、くめごん、まぶり、kassyi

2章 Adapter
概要
間に何かを挟んで変換して使えるようにするものであり、すでに提供されているものを必要な形に変換して利用する。
継承を使ったものと移譲を使ったものがある。

JavaScriptにてサーバーサイドでしか動かないモジュールをブラウザで動かすためにラップして使用したことがある。
他社のライブラリやメンテナンスする人がいなくなったモジュールに対して使った事がある。
使用するクラスを如何にして隠すかが大事
この様な場合（いろんな環境で使えない場合）はラップして使う事がセオリー
元々のクラスをそのまま使用出来ない場合などに、使えるようにラップ（変換）して使用する。
既存のテスト済みのクラスを再利用する場合に使用する。
Java以外の言語でも利用できる。

3章 Template Method
概要
雛形を持ったパターン
スーパークラスにテンプレートが定義され、テンプレートとなる抽象メソッドが定義されている。
何をするかは記述されていないが、どの様に呼び出されるかは記述されている。
抽象クラスで抽象メソッドを定義して、サブクラスで具体的な処理を記述する。
抽象クラスとサブクラスで協調して動く様にする

メインクラスにてdisplayメソッドで実際に呼ばれているのは、サブクラスのdisplayメソッドである。
ロジックが共通化できれば、スーパークラスで処理フローを書いて、具体的な処理はサブクラスで記述する
メインで呼び出されたメソッドの動作は、スーパークラスを見ないと分からない。
抽象クラスのメソッドを呼んでいるのに、実際にはサブクラスのメソッドを呼んでいる。
サブクラスの数が多い場合など、実際に使うと難易度が高い。
下手に使うとスパゲティーコードになりかねない。
使いどころとしては、フロー（パターン）が変わらない場合
型にはまって例外的な処理が起こらない場合

どのクラスをサブクラスにするかはどうやって決めているか？
⇒勘でやっていることが多く、明確な基準が言語化できない
　共通化を考えずにインターフェースだけ作って、作成した後に共通化できそうなときに再度考えたことがある。
　クラス図を紙に書いたときに、サブクラスとして切り出せそうな箇所やインタフェースを定義できそうなどがひらめく事がある。
　最初から100点のコードは書けないので、手探りでやるしかない。

第4章　Factory Method
Template Methodと違い、インスタンスの生成をサブクラスに任せる。
NewするのはIDCardFactoryで行っている。
Newで実際のインスタンス生成をメソッド呼び出しで行える。
具体的なクラス名を記述せずにインスタンスを生成できる。
このパターンの使いどころ
⇒インスタンス生成時に色々な処理が必要な場合、クライアントに処理を任せずに、呼ばれる側で処理を実装＆隠す。
　決まった処理をクライアント側にいちいち実装させない様にする。
デザインパターンは抽象的な処理が多くなるので、使用する場合はドキュメント化するべきであり、その場合はデザインパターンの名称と意図を記述する。
スーパークラスには、意図をドキュメント化する。
例えば、IDCardクラスが複数あった場合やNewするのが複雑な場合に、productでのuseを呼び出せば済むようにする。