Ch.17 KICK THE OBSERVER
【目標】
Observerパターンを使って、メンバーの活動休止とグループの活動休止をリンクさせよう
【クラス図】
【実装】
＜IGroupインターフェース：Observer＞
＜IMemberインターフェース＞
≪Memberクラス：ConcreteSubject≫
≪Groupクラス：ConcreteObserver≫
［Mainクラス］
【出力結果】
【メモ】
・Observerって名前が悪すぎると思う。状態を伝えられるばっかりのReceiverじゃねぇか。
・KICKを絡ませたネタとしては割ときれいにまとまった気がする
Ch.16 KICK THE MEDIATOR
【目標】
Mediatorパターンを使ってTORIIIIIICO!のマイクパスをやってみよう
【クラス図】
【実装】
＜IMicrophonePassインターフェース：Mediator＞
＜MC抽象クラス：Colleague＞
≪Krevaクラス：ConcreteColleague≫
≪Mcuクラス：ConcreteColleague≫
～略～
≪Littleクラス：ConcreteColleague≫
～略～
≪Cuezeroクラス：ConcreteColleague≫
～略～
≪Channelクラス：ConcreteColleague≫
～略～
≪Sohjinクラス：ConcreteColleague≫
～略～
≪Hookクラス：ConcreteColleague≫
≪Toriiiiiicoクラス：ConcreteMediator≫
［Mainクラス］
【出力結果】
【メモ】
・１番だけにしとかないとJ/A/S/R/A/Cに怒られそう
・イメージしやすいけど、厳密には正しい例ではない。まぁ今までのに比べればよろしい。
・Facadeパターンとの違いは命令主が外部か内部かという違いだと認識しているけど、間違ってるかもしれない。
Ch.15 KICK THE FACADE
【目標】
Facadeパターンを使ってワーナーミュージックさんにKICK THE CAN CREWの新曲を作ってくれるようお願いしよう
【クラス図】
【実装】
≪WarnerMusicクラス：Facade≫
≪Krevaクラス：Class≫
≪Mcuクラス：Class≫
≪Littleクラス：Class≫
≪Kumaiクラス：Class≫
［Mainクラス：Client］
【出力結果】
【メモ】
・割と無意識にやってることのような気はするけど、まだまだ徹底できそうなパターン
・ワーナーさんよろしくお願いします。
Ch.14 KICK THE CHAIN OF RESPONSIBILITY
【目標】
Chain of Responsibilityクラスを使ってメンバーにソロ仕事を割り振ろう
【クラス図】
【実装】
＜AbstractMember抽象クラス：Handler＞
≪Memberクラス：ConcreteHandler≫
［Mainクラス：Client］
【出力結果】
【メモ】
・little.JudgeOffer()だけ見ると、何をやっているのかしごくわかりにくい。先頭にダミーメンバーを置いてもいいか
・MCUに失礼。歌えるし。
Ch.13 KICK THE VISITOR
【目標】
Ch.11でやった「KICK THE CAN CREWをHTMLでリスト表示しよう」をVisitorパターンで書き換えてみよう
【クラス図】
【実装】
＜AbstractHtmlVisitor抽象クラス：Visitor＞
＜HtmlFactor抽象クラス：Element＞
≪TextValueクラス：ConcreteElement≫
≪Tagクラス：ConcreteElement≫
≪HtmlVisitorクラス：ConcreteVisitor≫
［Mainクラス：ObjectStructure］
【出力結果】
【メモ】
Main→<body>「Visitor受け入れろ」
<body>→Visitor「OK、来いよ」
Visitor「bodyの情報書くで。
あれ、中に<ul>タグあるやん。」
Visitor→<ul>「俺を受け入れてよ」
<ul>→Visitor「OK、来いよ」
Visitor「<ul>の情報書くで。
あれ、中に<li>タグあるやん。」
Visitor→<li>「俺を受け入れてよ」
<li>→Visitor「OK、来いよ」
Visitor「<li>の情報書くで。
あれ、中にKREVAおるやん。」
Visitor→KREVA「俺を受け入れてよ」
KREVA→Visitor「OK、来いよ」
Visitor「KREVAの情報書くで。
KREVAにもう用はないな」
Visitor「<li>にもう用はないな」
Visitor「あれ、まだ<li>タグあるやん」
Visitor→<li>「俺を受け入れてよ」
<li>→Visitor「OK、来いよ」
Visitor「<li>の情報書くで。
あれ、中にMCUおるやん。」
Visitor→MCU「俺を受け入れてよ」
MCU→Visitor「OK、来いよ」
Visitor「MCUの情報書くで。
MCUにもう用はないな」
Visitor「<li>にもう用はないな」
Visitor「あれ、まだ<li>タグあるやん」
Visitor→<li>「俺を受け入れてよ」
<li>→Visitor「OK、来いよ」
Visitor「<li>の情報書くで。
あれ、中にLITTLEおるやん。」
Visitor→LITTLE「俺を受け入れてよ」
LITTLE→Visitor「OK、来いよ」
Visitor「LITTLEの情報書くで。
LITTLEにもう用はないな」
Visitor「<li>にもう用はないな」
Visitor「<ul>にもう用はないな」
Visitor「<body>にもう用はないな」
いや、わからんわ。
・具体的な処理(WriteLine)をVisitorクラスにすべて書いているところがポイントらしい
Ch.12 KICK THE DECORATOR
【目標】
DECORATORパターンを使って、MCUが作曲や俳優の仕事ができるようにしよう。
【クラス図】
【実装】
＜McuComponent抽象クラス：Component＞
≪Mcuクラス：ConcreteComponent≫
＜Ability抽象クラス：Decorator＞
≪Composableクラス：ConcreteDecorator≫
≪Actableクラス：ConcreteDecorator≫
［Mainクラス］
【出力結果】
【メモ】
・MCUに失礼
・Component（本体）側とDecorator側を同じクラスから派生させるのに違和感がある
・実際にメソッドが呼び出される順番を意識する必要がありそう
・それぞれのDecoratorが独立でないと具合が悪そうで、具体的にどういう場面で使えるのかイマイチつかみきれてない
・MCUに失礼
Ch.11 KICK THE COMPOSITE
【目標】
KICK THE CAN CREWをHTMLでリスト表示しよう
【クラス図】
【実装】
＜HtmlFactor抽象クラス：Component＞
≪TextValueクラス：Leaf≫
≪Tagクラス：Composite≫
［Mainクラス：Client］
【出力結果】
【メモ】
・お題としては悪くないがもはやKICK関係ない
