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

14章 Chain of Responsibility
概要
複数のオブジェクトを鎖のようにつないで順次オブジェクトを渡り歩き、目的のオブジェクトを決定する
Supportクラスは抽象クラスであり、resolveメソッドを呼んで、falseが返ったら次のクラスにたらい回しする
Nosupportクラスは、Supportクラスのサブクラスで常にfalseを返して何も処理をしない
SpecialSupportクラスは指定した番号のみを処理する
Mainクラスでは、番号を上げて行って、次々にクラスに処理を任せる。
最初はBobが処理をしていたが、次にDianaになりどんどん次のクラスに処理を任せている
P218 のクラス図では、Handlerはリクエストを受けてConcreateクラスを呼び出しながら処理を継続している
中央集権的に処理を命令するのでなく、Concreateクラスが緩やかに結び付けられているので、Concreateクラスが適切な処理者によって処理される
要求とその処理者が固定的に書かれていたら、動的に処理者を変更するのが難しくなる。
本パターンのたらい回しを使うと処理は遅くなるが、柔軟に処理の移譲ができる。

15章 Facade
概要
多くのクラスが有る場合に、そのクラス達の窓口となるものを持たせる。
その窓口に対して処理を依頼する。
内側のごちゃごちゃしたインタフェースをまとめて、外側にシンプルなインタフェースを設ける。
サンプル
MainがPageMakerを呼び出して、PageMakerがそれぞれHtemlとDatabaseクラスを呼んでいる
DatabaseクラスはFileを呼び出してデータの読み書きをする
Htmlwriterクラスは簡単なHtmlを作成する
登場人物
Facade役はシステムを構成しているクラス類のシンプルな窓口であり、APIを外部に提供する
その他大勢のクラスはFacade役を意識しない
ヒント
Facade役の役割は、複雑なAPIを単純にするものであり、APIが少ないということは外部との結合が疎であること
議論
どこまでをPublicにするか、その基準とは？
⇒そのAPIをだれが使うのかを考える。
　例えば、ClassAとClassBがDやCから使われないとしたらPublicにしない
　パッケージからは何も書かない、継承はProtected、
　その他外部から使われるならPublic