- 1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ]
- 前すれ
〔隔離〕デザインパターンは本当に必要か？〔スレ〕
pc8.2ch.net/test/read.cgi/tech/1119348596/
- 131 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 03:49:00 ]
- 『状態がセット』 というより、『状態を判断するタイミング』 って言ったほうが良いかな。
タイミングってのは、コード上の箇所も含むよ。
先に状態を判断しておいて、後からその状態に従った動作を行わせるってのも State パターンで行えるし。
- 132 名前：123 mailto:sage [2006/06/04(日) 03:56:15 ]
- うーん、いまいちよくわからないですね。
朝.showMessage();
昼.showMessage();
夜.showMessage();
の３つのメソッドを作って状態みてどれかのメソッドを呼び出す。
このやり方とサイトの説明の差は>>129さんの
『状態がセット』 されるタイミングと 『 実際に showMessage 』 されるタイミングを離すことが出来る
しかないように思えます。
今日はもう寝ます。明日また考えたいと思います。
みなさんありがとうございました。
- 133 名前：123 mailto:sage [2006/06/04(日) 03:58:09 ]
- >>130さんのがなんとなくわかるかも…
明日その辺も考えてみます。
- 134 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 04:13:05 ]
- >>132
ちなみに、こういうメリットもある。
State パターンってのは、『状態』 と 『その状態のときに行う動作』 を ”１つに” まとめておくから、 (>>126)
currentState.showMessage() するときには、currentState に何がセットされてて、どういう動作を行うのか考える必要はないんよ。
ただ showMessage() すれば、その状態に合った動作が行えるってことは保障されてる。
だから、勝手に MyState のサブクラスを自作して、それを currentState にセットしても動くかもね。
- 135 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:30:10 ]
- たとえば後からStateに夕方を追加したくなったとすると
Stateを使わない方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．showMessageの中のifやswitchに夕方の場合を追加
showMessage以外にも似たメソッドがあったらそれら全ての中のswitch文を更新しなきゃならん。
つまり２の作業があちこちに散らばっていて見落としが起こりがちだし
ちょっと間違えると既存の朝昼夜の動作にもに影響が出かねない。
Stateクラスとしてまとまっている方法では
１．currentStateに状態をセットする箇所に夕方の場合を追加
２．夕方クラスを追加
クラスを増やすぶん、追加すべきコード量自体はむしろStateを使わない場合より多くなりそうだが
２の作業については変更箇所が新規クラスの追加という形で一箇所にまとまっているため
既存の朝昼夜は基本的に触らなくてすむ。
- 136 名前：135 mailto:sage [2006/06/04(日) 21:22:31 ]
- 補足。
状態ではなくメソッドのほうを増やしたくなったとき
Stateを使う場合では朝、昼、夜クラスのメソッドをそれぞれ追加する必要がある。
状態の種別のほうが追加や変更を受けることが多そうならStateを使うといい。
- 137 名前：123 [2006/06/05(月) 11:43:58 ]
- いろいろと説明ありがとうございます。
・朝、昼、夜の状態で行いたい処理が複数ある場合はStateパターンを使う意味がある。
朝、昼、夜クラスとそれらを使うクラスの４つ
夕方が増えた場合の変更箇所 夕方クラス追加。使うクラスの分岐追加の２箇所。
・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
（状態が増える可能性はあるが処理が増える可能性はない。）
朝、昼、夜のshowMessage()メソッド３つ。
スイッチで各showMessage()をよびだす。
夕方が増えた場合の変更箇所 夕方メソッドの追加、スイッチの分岐追加の２箇所。
とゆう認識でよろしいでしょうか？
でもまだ疑問が。
いろいろサイトをみてまわったんだけど、ほとんどの所でStateパターンはifは使わないと書いてます。
でも今までのやり方だと状態を変える時結局ifが必要で、
ただのポリモルフィズムの説明に思えるんですが…
- 138 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 12:01:57 ]
- >>137
＞・処理がshowMessage()のみの場合（処理がひとつの場合）Stateパターンを使う意味があまりない。
割とそうではない場合も。このあたりはケースバイケース。
＞でも今までのやり方だと状態を変える時結局ifが必要で、
>>124
＞ただのポリモルフィズムの説明に思えるんですが…
認識としては全く正しい。多態を使用して、”オブジェクトで状態を表す”のが State パターン
- 139 名前：デフォルトの名無しさん mailto:sage [2006/06/05(月) 13:04:39 ]
- >>137
１．状態を変えるための判断としてのif
２．（今現在の）状態を判断するためのif
がごっちゃになってない？
Stateパターンだとifは使わないというのはおそらく後者のほうかと
前者はどうしようもないよね。
- 140 名前：123 mailto:sage [2006/06/05(月) 13:35:35 ]
- りょうかいです。
すっきりすることができました。これでやっと次に進めます。
ありがとうございました。
- 141 名前：デフォルトの名無しさん [2006/06/06(火) 00:53:15 ]
- >>135
コード量では後者の方がむしろ追加分量が増えるという所が何とも吐き気がするんだが…ｗ
- 142 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 22:10:57 ]
- インデントとか改行みたいなもんだよ
コードの見通しを良くするために使う。
また、見通しが良くならないのであれば使うべきではない。
- 143 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 22:18:34 ]
- 一番大事なことは
状態のような概念をオブジェクトとして扱うという考え方
なんじゃないかと思う
- 144 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 10:04:36 ]
- 一昔前はオブジェクト＝モノ。
モノに操作を与える＝クラス。
だったすからねえ。
ていうかオブジェクト指向のオブジェクトって言葉が
もう時代にそぐわない気すらするですよ。
- 145 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 10:30:27 ]
- エンティティのほうがまだまし？DBのほうで既成の用語なんで使いづらいけど
- 146 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 20:36:15 ]
- この調子で幸せになれる議論をお願いします
- 147 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 21:52:49 ]
- しかしやっぱ、そんなに議論する内容ってないよねこのスレ。
- 148 名前：デフォルトの名無しさん [2006/07/07(金) 23:17:05 ]
- commandパターンとstateパターンの違いがよく分からん。
commandパターンは、命令をクラス化して、その派生クラス
のexecute()を呼んで処理させる。
stateパターンは、状態をクラス化して、その派生クラスの
hogehoge()とか、fugafuga()を呼んで処理させる。
結局、名前が違うだけで考え方は一緒のような気がするんだ
が・・・という俺の愚痴。
- 149 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 23:37:55 ]
- >>148
Strategy と State と Command は、どれも多態で処理を切り替えてるから、
おそらく知らない人が見れば同じに見えると思う。
ただ、意味的な物は随分異なる。重点はそこかと。
- 150 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 23:44:15 ]
- そうかそうか。よーくわかったぞ。
- 151 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 00:42:23 ]
- 考え方は一緒だけど、使う箇所が違うってだけで分けられたパターンって結構あるよね。
前々スレあたりでGoFも一部の似たようなパターンは無くすとかいってなかったっけ？
- 152 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 01:22:41 ]
- >>141
テストケースのコード量も加味して考えるといいのでは。
- 153 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 02:29:05 ]
- StateとStrategyは構造は同じだけど、意味の区別がやや不明瞭。
Commandは意味も構造も違う。
GoFの原典を読むとそんな感じだな。
- 154 名前：デフォルトの名無しさん [2006/07/08(土) 02:58:41 ]
- そんな事いったらChainOfResponsibilityだってたんなるtree構造じゃん
- 155 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 03:20:10 ]
- そうか。なるほど。うん。お前の言いたい事はよくわかったぞ。
- 156 名前：デフォルトの名無しさん [2006/07/08(土) 04:29:30 ]
- 何がtree構造だ？馬鹿。
- 157 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 19:50:03 ]
- どうやるとこのスレ盛り上がるのかな。
- 158 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 22:03:22 ]
- なるほど。GoF信奉者は馬鹿ばっかりだという事がよくわかったぞ。
- 159 名前：デフォルトの名無しさん [2006/07/08(土) 22:04:42 ]
- ごめん。
オレが。
フェブってた。
- 160 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:17:09 ]
- フェブってたという言葉がググレません。
トミーフェブラリーのことかー！
- 161 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:24:07 ]
- ファブってたのtypoじゃないか
- 162 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:30:05 ]
- ファブリーズのことかー！
それは言うならファビョるじゃないかな、たしか。
- 163 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 23:31:22 ]
- >>162
残念、そこは落とすところだ
- 164 名前：デフォルトの名無しさん mailto:sage [2006/10/21(土) 01:39:05 ]
- 現在ゲームをつくっていてどういうパターンを使えばいいか悩んでいます
アドバイスをお願いします。
空で変な生き物（まある種の鳥）が動き回るという部分を作っているのですが、
ここで鳥Aと鳥Bはお互いに相手の位置を参照して動きを決めます。
そのため、
空Skyのオブジェクトが鳥A,鳥Bへのオブジェクト参照していて、
同時に鳥Aと鳥BもSkyオブジェクトを参照するというデータ構造にしています。
このようなものを実装するのに適したデザインパターンを教えてください。
- 165 名前：デフォルトの名無しさん [2006/10/21(土) 01:40:01 ]
- age
- 166 名前：デフォルトの名無しさん mailto:sage [2006/10/21(土) 03:09:11 ]
- >>164
あえて言うなら Mediator
- 167 名前：デフォルトの名無しさん mailto:sage [2006/11/01(水) 21:48:53 ]
- >>164
表示という親クラスを作って
空、鳥Ａ、鳥Ｂをそのメンバにする。
鳥Ａと鳥Ｂの相互作用が絶対に必要なら
Birdsという鳥全体の動きを仕切るクラスを作って、
そこに鳥Ａと鳥Ｂを入れる。
- 168 名前：デフォルトの名無しさん mailto:sage [2006/11/03(金) 19:06:17 ]
- >>164
Observer
はどうでしょう。
鳥Aは鳥Bの位置を監視し、その値がかわったら、自分（鳥A）の座標をupdateする。
鳥Bも同様。
- 169 名前：デフォルトの名無しさん mailto:sage [2006/11/03(金) 19:11:56 ]
- >>168
無限ループに突入しないようにしないとな
- 170 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 12:34:28 ]
- まだ結城本読了＆自分のプログラムにいくつか採り入れる
っていうレベルで、まだGoFのカタログ読んでないです。
結城本のBridgeの「関連しているパターン」に
AbstractFactoryが載ってるんですけど
引用：
Bridgeパターンに登場するConcreteImplementor役を
環境にあわせて適切に構築するために、
AbstractFactoryパターンが用いられる場合があります
Implementorが「抽象的な工場」、ConcreteImplementorが「具体的な工場」
なのか
ConcreteImplementorが「抽象的な工場」で、それを継承して「具体的な工場」
なのか
状況次第なんですかね？
そろそろGoF読まなきゃと思いつつ、なかなかとっつきにくい
- 171 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 23:07:26 ]
- そもそも
>Bridgeパターンに登場するConcreteImplementor役を
>環境にあわせて適切に構築するために、
構築されるものが ConcreteImplementor なんじゃないの？
- 172 名前：デフォルトの名無しさん mailto:sage [2006/11/21(火) 10:07:44 ]
- >>171
BridgeパターンのConcreteImplementorが
AbstractFactoryの「抽象的な工場(AbstractFactgory)」を構築するのか
「具体的な工場(ConcreteFactory)」を構築するのか
ということがわからんのです(；´Д`)
- 173 名前：デフォルトの名無しさん mailto:sage [2006/11/21(火) 21:52:55 ]
- >>172
AbstractFactory パターンを使って、ConcreteImplementor を作る、
だと思うよ。クラス図を書けばすっきりする予感。
- 174 名前：デフォルトの名無しさん mailto:sage [2006/11/22(水) 01:34:32 ]
- >>173
なるほど、そういうことだったんですか。。。
やっと頭の中でクラス図がぼんやりできてきました。
デザパタを教条的に使うだけじゃ、いかんですな。＜自分
ありがとうございます
- 175 名前：デフォルトの名無しさん mailto:sage [2006/11/24(金) 16:24:47 ]
- www.01-tec.com/document/cpp_design_pattern.html#Adapter
これってふつうに
class Apple
{
public:
void NamePuts()
{
puts( "りんご" ) ;
}
void ColorPuts()()
{
puts( "赤" ) ;
}
} ;
class Banana
{
public:
void NamePuts()
{
puts( "バナナ" ) ;
}
void ColorPuts()()
{
puts( "黄" ) ;
}
} ;
って書き換えればいいのでは？
- 176 名前：デフォルトの名無しさん mailto:sage [2006/11/24(金) 16:39:37 ]
- >>175
書き換えられなかったらどうするのか、って話だ。
- 177 名前：デフォルトの名無しさん mailto:sage [2006/11/27(月) 16:52:58 ]
- >>175の天才ぶりにびびった。
- 178 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 00:49:44 ]
- void ColorPuts()()
- 179 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 10:45:59 ]
- >>175
あなた程の天才がなぜこんなスレを見てるのですか
- 180 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 11:56:28 ]
- Adaptor - 貴方は委譲しますか？継承しますか？
漏れは原則委譲派
- 181 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 20:42:59 ]
- >>180
case by case だけど、俺は継承だな……
- 182 名前：デフォルトの名無しさん mailto:sage [2006/11/28(火) 23:47:27 ]
- 委譲(包含+転送)しか使ったことないです。
継承の方が優れてるケースってどんな時でしょうか。
基本的に adapter is a adaptee な状態にはならんので
継承使おうと言う気が起きないです。
- 183 名前：181 mailto:sage [2006/11/29(水) 01:17:07 ]
- あ、ごめん。普通に勘違いした。委譲だ委譲。
よく考えなくとも Adapter クラスを継承することは大前提なんだよな。
すまね orz
- 184 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 04:55:44 ]
- 結局継承によるアダプターは誰も実践してない罠。
でもアダプターパターンの解説見てると
継承による方法が先の場合が多いのはなぜなんだぜ。
- 185 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 09:15:54 ]
- 委譲よりも継承の方が、初心者にはOOっぽく見えるんだぜ？
- 186 名前：デフォルトの名無しさん mailto:sage [2006/12/11(月) 23:52:47 ]
- 継承による場合は override によって処理を上書きすることで
完全にコントロール出来ることが利点だと説明するサイトがあったが
コントロールしちゃったらアダプタでもなんでもないと思った。
- 187 名前：デフォルトの名無しさん [2006/12/28(木) 20:59:47 ]
- 質問なんですが、ファクトリパターンってインスタンスが一つあればいいってのはわかるんですが、
メソッドをstaticじゃなくて、シングルトンパターンにする必要があるのですか？
どうせなら、インスタンス作らないで、staticメソッドにしてアクセスした方がいい気がするのですが
インスタンスを生成するかstaticにアクセスするかどちらの方がいいのですか？
- 188 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:06:43 ]
- 一概には言えまい
staticにしてしまうとファクトリ事態を抽象化することが出来んからな
- 189 名前：デフォルトの名無しさん [2006/12/29(金) 00:46:41 ]
- >>188
なるほど
- 190 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:52:45 ]
- >>182
adapter has a adaptee？
- 191 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 00:58:56 ]
- client → Target
△
|
Adapter→Adaptee
TargetはClientに対するInterfaceだからAdapterがTargetを継承するのは当然なのでは？
AdapterはAdapteeに委譲するのは当然だし
- 192 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 06:29:05 ]
- >>191
当然だと思う。
でも世のデザパタ解説サイトだと
「継承」「委譲」の2種類を例として出してる場合、
「継承」ではTargetはクラス、Adapterはそれを継承する形になってて
「委譲」ではTargetはインターフェース、Adapterはそれを実装する形になってる。
本質を考えれば継承の場合でもTargetはインターフェースだろ？と思うんだけど。
(というか継承はいらねえと思われ。)
オリジナルのGoF本を読んでないので分からんけど。
- 193 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:14:40 ]
- >>192
クラスでもいいのでは？
Targetとしての振る舞いに共通なものがあるのだとしたら
抽象クラスとする事もアリだと思うけど
Client → Target
△
;
AbstractTarget
△
|
Adaptar → Adaptee
- 194 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 08:29:13 ]
- まあ、↑みたいにするAdapterパターンの説明としては複雑になるから
省略してTargetをクラスにしてるんだと思うけど
- 195 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:00:04 ]
- クラスが悪いとかクラスじゃできないとか言ってるんじゃなくて。
Client からは統一的に扱える、同じように見えるって側面を強調するなら
インターフェースでいいじゃねえかと。
委譲のパターンでもTargetはインターフェースで説明できるのに
そっちの方がより無駄のない本質的な説明になるのに、
なんでクラスなの？と。
(>>192では委譲・継承とクラス・インターフェースの組み合わせが逆だった。)
↓これが一般例で、他はもう特殊例でしょ？
<<interface>>
client → Target <|・・・・・Adapter ・・・・・|> Adaptee
implements uses
ひどいところでは
継承使うパターンがデフォですよ、
単一継承でいかんともしがたい時には
委譲使うパターンで回避ですよ、
に近い説明すら行ってる。
なんかもうコードが共有されるなら継承が最高の解なんだよ、みたいな。
それは15年前に通ってきた道だろう、と。
- 196 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:07:58 ]
- それをいったらデザインパターン自体が出てからだいぶ時間がたってるから
当時の説明をそのまま鵜呑みにしてもしょうがないでしょ。
もし初心者がそれ見て今の時代にアンマッチな知識をインプットしてしまう
事に懸念を感じるなら、自分で「こう解釈するのがいいですよ」って説明する
サイトでも立ち上げてみればいいｗ
- 197 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 09:14:16 ]
- >>195
＞↓これが一般例で、他はもう特殊例でしょ？
それは少し乱暴だと思うが・・・・・
そう熱くなるなよｗ
- 198 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 16:58:29 ]
- >>195
っていうか、「委譲」って言葉の使い方間違ってね？
- 199 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 21:21:49 ]
- Effective C++ みたいに、時代に合わせて新しくなるデザパタ本があればいいのにな。
- 200 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 22:04:55 ]
- GoFのデザインパターンは、モデリングの世界の"Hello World"
見たいな物になってしまったンだと思うね
- 201 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 19:42:57 ]
- ほす
- 202 名前：デフォルトの名無しさん mailto:sage [2007/01/02(火) 20:07:12 ]
- 「それはパターンから外れているから駄目だ」とかは全然駄目なセリフの例ですね
- 203 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:41:05 ]
- ほす
- 204 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 13:53:11 ]
- いまさらデザインパターンを語ることはあるまい
- 205 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:24:09 ]
- デザインパターンってもう語りつくされたん？
- 206 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 15:36:31 ]
- 語れるほど言葉を持たないというのが正確なところかｗ
- 207 名前：デフォルトの名無しさん mailto:sage [2007/01/18(木) 18:06:31 ]
- これはよく使うパターンって何？
- 208 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 03:12:29 ]
- Iterator
- 209 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 07:26:27 ]
- Singleton、Factory、Template あたりかなぁ。
- 210 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:45:02 ]
- こんぽじっと
- 211 名前：デフォルトの名無しさん mailto:sage [2007/01/19(金) 23:47:05 ]
- こーるばっく、こまんど、
- 212 名前：デフォルトの名無しさん mailto:sage [2007/01/20(土) 01:28:34 ]
- 微細主義，機能分割，集団無能化・・・
- 213 名前：デフォルトの名無しさん [2007/02/10(土) 20:34:33 ]
- 結城さんのMLってどうやって送信先メールアドレスを変えるんだ？
進級２つ登録したから古い方だけ購読解除できればいいんだが
まぁ４月になればアドレスが使えなくなるから放置でもいいんだけど
- 214 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 22:10:48 ]
- >>213
それって面白い？
- 215 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 01:12:50 ]
- NullObjectのような、GoFの23には含まれていないパターンについて勉強したいのですが、
みなさんはどのように勉強されましたか？
個人的には本で勉強したいので、参考になる書籍などを示してほしいです。
- 216 名前：デフォルトの名無しさん [2007/02/12(月) 19:33:51 ]
- age
- 217 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 19:38:25 ]
- boostのコードを読むと、すごい勉強になった
- 218 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:29:48 ]
- >>217
kwsk
- 219 名前：デフォルトの名無しさん [2007/02/12(月) 20:55:12 ]
- デザインパターンを勉強すると、
自分が頭良くなってスゴイSEなったってカン違いするヤツ、
多いよな・・・
- 220 名前：デフォルトの名無しさん mailto:sage [2007/02/12(月) 20:59:00 ]
- 一人前のSEって感じでしょ
- 221 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 11:29:01 ]
- GOFデザインパターンはマイクロアーキテクチャーの一種に分類され、
その対象領域は一般にプログラムと呼ばれている、いわゆる動作単位であるから、
どの様に考えてもプログラマの職域に属する事項であるかと
- 222 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:23:41 ]
- >>221
「マイクロアーキテクチャー」って一体何の事だか、
分かっている？
- 223 名前：デフォルトの名無しさん mailto:sage [2007/02/13(火) 23:58:25 ]
- SEではないな
- 224 名前：デフォルトの名無しさん mailto:sage [2007/02/14(水) 08:14:40 ]
- 半導体設計が思い浮かんだ。
- 225 名前：デフォルトの名無しさん [2007/02/19(月) 23:50:05 ]
- >>219
結局デザインパターンって、フレームワーク作る時にしかあんまし使わないかなあ
- 226 名前：デフォルトの名無しさん mailto:sage [2007/02/19(月) 23:54:41 ]
- 勉強が足らんな
- 227 名前：デフォルトの名無しさん [2007/02/20(火) 00:13:46 ]
- >>226
kwsk
- 228 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:24:41 ]
- フレームワーク使う側でも使う。
java.lan.io.* なんてデコレータパターンの塊だし
コレクションフレームワークはそのままイテレータパターンの実装だし。
フレームワークが面倒見てくれない粒度の細かいオブジェクトの組み立てには
それはもうファクトリやらテンプレートやらのオンパレードさ。
- 229 名前：デフォルトの名無しさん [2007/02/20(火) 00:33:57 ]
- >>228
ｉｏ自身がデコレータでしょ
使ってる側は意識しないはず
イテレータは素人でも使うよ
- 230 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 00:43:25 ]
- イテこまし…いやなんでもない
- 231 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 05:36:30 ]
- つーか、あるものを利用するだけで自分では使わないんだｗ
|
 |
