実施日時：2019/8/21
対象範囲：第12章～第13章
参加者：yodai、yoridori、くめごん、まぶり、kassyi

12章　Decorator
概要
デコレーションを施していく様に、中心となるオブジェクトに機能を一つ一つ重ねて目的に合ったオブジェクトに仕上げるデザインパターンをDecoratorパターンという。
サンプル
Displayクラスは複数行からなる文字列を表示するための抽象クラス
StringDisplayクラスは1行の文字列を表示するクラスであり、DisplayのサブクラスなのでDisplayの抽象メソッドを実装する必要が有る。
Borderクラスは飾り枠を表示するクラスであり、Displayを継承した抽象クラスとなる。
このため、BorderがDisplayと同じメソッドを持つことになり、API的に見れば飾り枠と中身を同一視できる。
SideBorderクラスとFullBorderクラスは、Borderクラスを継承した具象クラス
ヒント
Borderクラス(飾り枠)がDisplayクラス(中身)のサブクラスとなっていることで、BorderクラスやDisplayクラスのメソッドが他のクラスから見る事ができる。
これをAPIが「透過的」であるという
共通のAPIを持っているが、新たに包んで機能を追加できるため、包まれるもの（Displayクラス）を変更することなく機能の追加が出来る
欠点
良く似ている小さなクラスが沢山作られてしまう。
議論
ConcreteComponetとComponentとメソッドの区別が付かない。
何をスポンジにして、何をクリームにするのかを気を付けないとコードを書く時辛いかも。
実際に使う時は、コメントを残すことを考える。

13章　Visitor
概要
データ構造と処理を分離する
Visitorパターンは相互干渉しているので分かり辛い
Directoryクラス
acceptメソッドはvisitメソッドを呼び出しており、訪問したのはDirectoryのインスタンスだと教えている
ListVisitorクラス
visit(Directory)メソッドは、Directoryクラスのインスタンスに対して行う処理が書かれている。
visitメソッドとacceptメソッドがお互いに相手を呼び出している。
議論
データ構造と処理を分離する必要が有る時は、Visitorパターンが有ると言う事を覚えておくと良い。
これを使うと、他の人もVisitorパターンの理解を深めないと理解できなくなる。
このパターンを現場で使えそうな状況が分からない。
伝わり易いコードを書くのが最近の傾向なので、このパターンは導入し辛い。
ダブルディスパッチは使うがVisitorパターンは使わない。
compositパターンで代用できるのでは？
依存関係を一方通行にするべきであり、相互依存は望ましくないと思う。
Visitorパターンの意義
処理をデータ構造と分離し、FileクラスやDirectoryクラスの部品としての独立性を高める。
拡張に付いては開かれており、修正については閉じられている様なクラスを作成するべき。
拡張するときも既存のクラスを変更することないようにする