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

10章　Strategy
概要
アルゴリズムをごっそり切り替える

ジャンケンの手で余剰(％)を使っているのは、パー（２）の後グー（０）になって欲しいから
Strategyインターフェースは、戦略のための抽象メソッドを集めたもの
WinningStrategyとProbStrategyは具体的な戦略を記述したもの
Playerクラスは、ジャンケンを実際に行う人を表現したもの
PlayerクラスのnextHandメソッドは、自分の処理をStrategyに移譲している
Strategyパターンを使う利点として、移譲を使って緩やかな結びつきとなっているので、アルゴリズムを簡単に切り替えられる
例えば、将棋のゲームでユーザによって思考レベルを容易に切り替えられる
内部のロジックをごっそり切り替えるこのStrategyパターンをnode.jsで使っている
データをDBに保存する処理を簡単に変えられる
例えば、nosqlとmysqlへの保存先を簡単に変更できる
どっちかと言うと、やる事は変わらないが内容をゴッソリ変えるもので使う
処理の煩雑さを無くしたり、同じ事を書くべきでないとの思想から生まれたものだと思われる

11章　Composite
異なるものを同じ様にごっちゃにして、再帰的な構造を作って処理するもの

EntryクラスのgetNameとgetSizeは抽象メソッドのみ用意して実装はサブクラスに任せる
printListはオーバーロードを行っている

Directoryクラスでentry.getSize()処理を行っているが、FileのインスタンスかDirectoryのインスタンスを分けていない
「容器と中身を同じものとみなす」ことで、同じgetSizeで処理をすることができる

再帰的構造は色々な場面で使用できる
　コマンドをまとめたマクロコマンドを作成する
　文章の箇条書きと箇条書きのまとめを同時に処理する

addメソッドの置き方、実装の仕方は色々考えらえる
Entryで宣言、DirectoryとFileで実装、Directoryのみで実装などなど
作るものによって色々変更する必要がある
場合４はいちいちキャストする必要が有る
場合１はエラーハンドリングの難しさや失敗時の問題が考えられる

エラー処理について
エラー設計は議論が必要、動けばよいとのプロジェクトでは軽視されがち
どういう時にエラーが出るのかとかは書くが、細かくは書かない
エラーメッセージは残すべき
FileCloseでIOExceptionはログだして、エラー処理せずにするのは仕方ない
エラー処理は、ログを出すのか画面表示するのかなどは規約を設計段階で決めるべき