「増補改訂版Java言語で学ぶデザインパターン入門」読んだ

自分用。  これ読んだ。 増補改訂版Java言語で学ぶデザインパターン入門 [単行本] < http://www.amazon.co.jp/dp/4797327030 > 続きを読む
1
べちか @bechica

クラス階層の意義について説明されてる。 ?????

2011-03-30 01:58:05
べちか @bechica

機能追加するときには スーパクラスは基本機能、サブクラスは追加機能の役割をそれぞれ分担してる。 実相を追加するときには、スーパクラスはインタフェースを規定し、サブクラスはそれを実装している。 うん。

2011-03-30 01:59:25
べちか @bechica

ああ、サブクラスに複数意味があって混在すると困るから、切り分けようと言っている?

2011-03-30 02:00:13
nozıɓns @sugizou

@herbetica ペンは物を書けるけどシャー芯いるかいらんかは分からんからペンには物が書けるって機能だけ持っといてシャー芯を変えたりするのはシャーペンに任せようぜ

2011-03-30 02:01:56
べちか @bechica

なるほど。機能拡張するときはそっちのクラスに修正を加えるだけで、実装クラスは修正する必要がない。ふむ。 で、それらを橋渡しする感じでデザインすればいいじゃん、それがbridgeパターンか。

2011-03-30 02:02:40
べちか @bechica

@sugizou モノが書ける というのが機能で シャー芯操作が実装なわけね。なるほど。

2011-03-30 02:03:21
べちか @bechica

"Bridgeパターン:冒険者を作る時に、人間の魔法使い、人間の剣士、エルフの魔法使い、エルフの剣士、みたいに作りたくて、どういう継承にしたらいいか分らなくなってきたら、ぶっちゃけ種族とか職業っていう変数を作ったほうが楽だよ" って件のまとめに書いてあるけど ピンとこない

2011-03-30 02:05:11
べちか @bechica

@sugizou humanクラスのサブクラスとして個別にクラス作るくらいだったらパラメータで管理した方が早いだろって言われたら うん・・・って思うけど bridgeパターンの説明としてピンとこなかった。。。

2011-03-30 02:09:04
べちか @bechica

とにかくサブクラスの意味合いが混在しないよう、用途にわけて意識的にアレしたら?みたいな話なのかなって思った

2011-03-30 02:10:43
べちか @bechica

第11章 Compositeパターン。ディレクトリのように、再帰的な構造を作る。 ディレクトリ内にはディレクトリorファイルが入っているはずだけど、これらに共通のスーパクラスを持たせると有利なことがある。名前変更とかは共通機能だしね。

2011-03-30 13:57:12
べちか @bechica

第12章 Decoratorパターン。基本のクラスとトッピングのクラスを作っておくと、トッピングの組み合わせで様々なオブジェクトが作れる。

2011-03-30 14:02:57
べちか @bechica

これだとたぶん説明がたらないな・・・。基本クラスにもトッピングにも、共通のインタフェースを持っていくことで、多重にラッピングできるっつーか機能拡張できる みたいなのがウリなんだと思う。"包まれるものを変更することなく機能追加を行うことが出来る"とある。

2011-03-30 14:04:25
べちか @bechica

第13章 Vistorパターン。 データ構造に要素が複数あってそれを処理するとき、普通データ構造をあらわしてるクラスの中にその処理を記述するけど、 この処理部分を別クラスに切り出すと、今後この処理に修正加わったときデータ構造担当のクラス修正しなくてよくなっていいよね

2011-03-30 14:38:12
べちか @bechica

Visitorパターン書いてる

2011-03-30 14:53:35
べちか @bechica

Visitorクラスがデータを受け取れるよう、データ構造側で適切なデータ公開しなきゃいけない。 ここの、何を渡すか考えて書くのがだるそう。

2011-03-30 15:07:47
べちか @bechica

第14章、Chain of Responsibility パターン。責任のたらいまわし。なんか必要な処理があるけど、処理するのに適切なオブジェクトがどれかわかんないとき、可能性あるオブジェクトをリストしといて、たらい回す。

2011-03-30 15:09:50
べちか @bechica

誰が処理すべきか定かなときは普通に渡したほうがいい。早くなるから。 あとCoRパターン使うと、それぞれの処理役は自分の仕事に集中できるから、わかりやすくはなるかも。

2011-03-30 15:17:01
べちか @bechica

ん?なんかおかしいと思ったら10章 Strategyパターンを抜かしてる。

2011-03-30 15:21:17
べちか @bechica

読む。 アルゴリズムを記述した部分を切り替えられるように作ってある、と。いつものようにインタフェースをおいて。 アルゴリズムに修正を加えたいとき、その部分だけ修正すればよくなるし、実行中に動的にアルゴリズムを切り替えることも出来るようになる。

2011-03-30 15:24:22
べちか @bechica

第15章。Fecadeパターン。複雑な処理をしたいとき、それらの手続きをまとめたクラスを作っといて、外部からはそれを呼び出すことにすると、利用しやすい。

2011-03-30 15:29:31
べちか @bechica

第16章 Mediator パターン。 ハイパーメディアクリエータ髣髴とさせる。

2011-03-30 15:45:48
べちか @bechica

ハブになるクラスを作って、ほかのクラスに指示を出したり、調整したりする。 mediatorとは調停者のこと。 子クラスが増えると破綻しそう。

2011-03-30 15:50:14
べちか @bechica

子クラスは再利用しやすいけど、mediatorは再利用性が下がるって書いてある。 うん。

2011-03-30 15:50:52
べちか @bechica

第17章 Observerパターン。 オブジェクトの状態が変わったとき連絡してくれるやつを作るとずっと監視してなくていいよね。 みたいな

2011-03-30 15:53:51