「増補改訂版Java言語で学ぶデザインパターン入門」読んだ
機能追加するときには スーパクラスは基本機能、サブクラスは追加機能の役割をそれぞれ分担してる。 実相を追加するときには、スーパクラスはインタフェースを規定し、サブクラスはそれを実装している。 うん。
2011-03-30 01:59:25@herbetica ペンは物を書けるけどシャー芯いるかいらんかは分からんからペンには物が書けるって機能だけ持っといてシャー芯を変えたりするのはシャーペンに任せようぜ
2011-03-30 02:01:56なるほど。機能拡張するときはそっちのクラスに修正を加えるだけで、実装クラスは修正する必要がない。ふむ。 で、それらを橋渡しする感じでデザインすればいいじゃん、それがbridgeパターンか。
2011-03-30 02:02:40"Bridgeパターン:冒険者を作る時に、人間の魔法使い、人間の剣士、エルフの魔法使い、エルフの剣士、みたいに作りたくて、どういう継承にしたらいいか分らなくなってきたら、ぶっちゃけ種族とか職業っていう変数を作ったほうが楽だよ" って件のまとめに書いてあるけど ピンとこない
2011-03-30 02:05:11@sugizou humanクラスのサブクラスとして個別にクラス作るくらいだったらパラメータで管理した方が早いだろって言われたら うん・・・って思うけど bridgeパターンの説明としてピンとこなかった。。。
2011-03-30 02:09:04第11章 Compositeパターン。ディレクトリのように、再帰的な構造を作る。 ディレクトリ内にはディレクトリorファイルが入っているはずだけど、これらに共通のスーパクラスを持たせると有利なことがある。名前変更とかは共通機能だしね。
2011-03-30 13:57:12第12章 Decoratorパターン。基本のクラスとトッピングのクラスを作っておくと、トッピングの組み合わせで様々なオブジェクトが作れる。
2011-03-30 14:02:57これだとたぶん説明がたらないな・・・。基本クラスにもトッピングにも、共通のインタフェースを持っていくことで、多重にラッピングできるっつーか機能拡張できる みたいなのがウリなんだと思う。"包まれるものを変更することなく機能追加を行うことが出来る"とある。
2011-03-30 14:04:25第13章 Vistorパターン。 データ構造に要素が複数あってそれを処理するとき、普通データ構造をあらわしてるクラスの中にその処理を記述するけど、 この処理部分を別クラスに切り出すと、今後この処理に修正加わったときデータ構造担当のクラス修正しなくてよくなっていいよね
2011-03-30 14:38:12Visitorクラスがデータを受け取れるよう、データ構造側で適切なデータ公開しなきゃいけない。 ここの、何を渡すか考えて書くのがだるそう。
2011-03-30 15:07:47第14章、Chain of Responsibility パターン。責任のたらいまわし。なんか必要な処理があるけど、処理するのに適切なオブジェクトがどれかわかんないとき、可能性あるオブジェクトをリストしといて、たらい回す。
2011-03-30 15:09:50誰が処理すべきか定かなときは普通に渡したほうがいい。早くなるから。 あとCoRパターン使うと、それぞれの処理役は自分の仕事に集中できるから、わかりやすくはなるかも。
2011-03-30 15:17:01読む。 アルゴリズムを記述した部分を切り替えられるように作ってある、と。いつものようにインタフェースをおいて。 アルゴリズムに修正を加えたいとき、その部分だけ修正すればよくなるし、実行中に動的にアルゴリズムを切り替えることも出来るようになる。
2011-03-30 15:24:22第15章。Fecadeパターン。複雑な処理をしたいとき、それらの手続きをまとめたクラスを作っといて、外部からはそれを呼び出すことにすると、利用しやすい。
2011-03-30 15:29:31ハブになるクラスを作って、ほかのクラスに指示を出したり、調整したりする。 mediatorとは調停者のこと。 子クラスが増えると破綻しそう。
2011-03-30 15:50:14第17章 Observerパターン。 オブジェクトの状態が変わったとき連絡してくれるやつを作るとずっと監視してなくていいよね。 みたいな
2011-03-30 15:53:51