!#dezapatan
@polistesとかとやってるデザインパターン勉強会。
実はその真の目的は、「デザインパターンを擬人化する」事である。

ということで、その方針についてここにまとめてみようかな？

!デザインパターンの分類と擬人化
注意：以降のコンテンツはデザインパターンの説明ではありません

-デザインパターンの分類をそのままキャラの個性にしてしまえばキャラかぶりがなくなる！
--http://d.hatena.ne.jp/ActionScript/20091127/gof_23_design_pattern

えーっと
-目的
--振る舞い
---（これは簡単にマッピングできそうだ、人の振る舞いという言葉が直感的だし）
--生成
---（これは… 人の生成？ うーん 生産 とかかな？ 何かをくれる人？ 何かを売る人？）
--構造
---（これは…？ 人の構造？ 人間である以上構造による個性は斜め上というか、無理矢理感のあるものになりかねない、危険だ。 人間関係のことかな？）

-範囲 （この分類をどうマッピングするかまだ不明瞭 とりあえずの見解を書いてみる）
--クラス
---静的な関係
---簡単には動かせないというイメージかな？
---数が少ないので、うまく「静的」をキャラとマッピング出来ればここは簡単になりそう
--オブジェクト
---動的な関係
---ほとんどがこれなので、特に意識して動的としなくてもよさそう

!指針
なるべく統一的なルールをもって擬人化しないと、途中でおかしな矛盾が出てくる気がする。

!!案 １オブジェクト（クラス）をひとりの人間として擬人化する
賛否両論あるが、これはとても考えやすい。勉強していくうちにオブジェクト指向というのは人間関係にマッピングしたほうがすんなり行くのではないかと思えてくる場面があった。
しかし、〇〇パターンで何人も人がいるとかいうのも破綻が目に見えている。 特徴的なオブジェクトをとりあげて擬人化できないだろうか。
うまく擬人化することで、その人をとりまく状況があたかもデザインパターンで言うところの〇〇パターンとなるようにできないだろうか

!!案 継承と実装の扱い
そうなると、クラス図のあるオブジェクトを人として、それを継承したり、実装したりすることを人間の行動に置き換える必要がある

継承はまぁある種パワーアップ的なものとして捉えられるのではないだろうか？
実装は取り付けも取り外しも自由な道具的なものとして扱えないだろうか

!!案 イロモノ
そうは行ってもGoFのパターンは多い。23もある。時には擬人化の難しい物が出てくるだろう。
23もあるとよっぽどそれぞれが違ってないとだんだんネタが尽きてくると考えられる。そこで擬人化の難しい物はいっそむちゃくちゃ変な設定にしてしまうというのはどうだろうか

行動をプログラムとしておでこのCDドライブに挿入するロボットとか

いつもかぶりものをしていて素顔は謎とか

そういうのが許されるんじゃなかろうか？ 23もいるし

!一覧とひとこと擬人化メモ
!!クラス-生成
!!!ファクトリメソッド
同じ形をしたものを生産してくれる口を用意してくれるやつだった

これによって具体的なクラスにかかわらずクライアントを書くことができるので差し替えたりするのが安易になる

アレ頂戴っていうとでてくるんだよね、いわゆるファクトリ？それってドラえもん？（本当は同じ形のものしか出てこないんだけど）

!!クラス-構造
!!!アダプター（クラス）
アダプターはクラスとオブジェクトの両方にある。
既存のクラスに変更を加えることなく、特定のインターフェースから操作できるようにする

腹話術師のカードをここで切るべきかどうか…
着ぐるみのひともここだっけ？

!!クラス-振る舞い
!!!インタープリタ
まだ
!!!テンプレートメソッド
予め処理の大まかな流れが決まっていて、その流れに沿って処理を行うようなものをうまくまとめて扱うことができる。

うっかりするとすぐイロモノになりそう
流れだけを管理してて、実際の処理は小クラスの実装に任せてるから、指揮者というか仕切り屋みたいな擬人化はありかもしれん

!!オブジェクト-生成
!!!アブストラクトファクトリ
「一式」を揃えてくれる工場を定義することで、クライアントはその一式のインターフェースを知っておくことで、様々な場合のコードをうまくまとめることができるようになる

一式揃えてくれる、んー 僕のイメージだと武器屋 ほらゴルゴ31とかで出てくるあのなんか爺さんがやってるやつみたいなノリ。 言ったら何でも用意してくれる。

!!!ビルダー
オブジェクトの生成の部分をオブジェクトから分離し別のオブジェクトで生成処理を行う

暫定おにぎりつくってくれる人になってるんだっけ 何を投げてもおにぎりにする強者。

!!!プロトタイプ
まだ
!!!シングルトン
常に同じインスタンスを返すファクトリ（1個とは限らないようだが）

あー 生成系だけどこれは、「全部私がやります！」みたいなそういうキャラにしようとか言ってたな。

!!オブジェクト-構造
!!!アダプター（オブジェクト）
あれ？クラスとの違いはなんだっけ？

!!!ブリッジ
エルフ魔法使い とかの話だったやつ

継承での拡張と実装での拡張

弁慶みたいな 武術に長けててかつ武器を持ってるキャラ というひらめきがあった

!!!デコレータ
ラーメンのやつ InputStreamとかもこれ
どんどん処理を被せていくパイプのようなイメージ？

まだ考えが至っていない

!!!コンポジット
階層構造を表すのに便利

これもイロモノになりそうだ

!!!ファサード
入り口を担当するオブジェクトを用意し、裏では複数のクラスがいろいろやってるが、それをクライアントコードから切り離して依存関係を減らす。
内部の実装をクライアントコードの変更なしに実現できる

受付的な そして裏側ではなにかとんでもないことが行われているのだ…（見えない）
お金持ちの家の子で、なにかやってというと黒い服でサングラスな人たちに何かをつたえ遂行させるとか そういうイメージ

!!!フライウェイト
まだ
!!!プロキシー
まだ

!!オブジェクト-振る舞い
!!!チェーンオブレスポンシビリティ
まだ

!!!コマンド
まだ

!!!イテレータ
繰り返しの構造を抽象化するもの。 コレクションの中身に順次アクセスするための統一的な手段を提供する。

コレクションの中の要素を指すポインタのような物をイテレータと呼ぶ。

ループという構造をどうやって擬人化するんだろう。閃かないと無理そう

!!!メディエータ
まだ

!!!メメント
まだ Undoと関係があったはず

!!!オブザーバー
オブジェクトを監視する、目的で使用するが、実際は対象となる対象（Subject）が観測者（Observer）に通知を送るという構造になっている

どっちを擬人化するかな。 
Subject「ねぇ！ ねぇ！ 私のステータス変わったよ！！！」
Observer「なにかあったら声をかけてよ、いちいち見てられないから」

!!!ステート
まだ

!!!ストラテジー
まだ（いろいろなシワがここによっている予感）

!!!ビジター
まだ（構文解析の時に見た気がする）