「【GoF】デザインパターン 6

1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ] 前すれ 〔隔離〕デザインパターンは本当に必要か？〔スレ〕 pc8.2ch.net/test/read.cgi/tech/1119348596/ 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 ] つーか、あるものを利用するだけで自分では使わないんだｗ 232 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 15:50:13 ] プログラマなんてみんなあるものを利用するだけでしょ アセンブラでもマシン語でも。 233 名前：デフォルトの名無しさん mailto:sage [2007/02/20(火) 23:18:29 ] いんや 234 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:22:45 ] ｺﾞﾌ！ 235 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:07:48 ] ちょっと皆さんに助言願いたい事があります。 例えば、ゲームプログラムなんですが、 あるキャラクタークラスYがあったとしてキャラクタークラスは内部に AI処理を担当するクラスZをコンポジションでもっていたとします。 で、AIのタイプにはいくつかあって（タイプA/B/C）、それぞれの タイプにも、細かく引数によってパラメータの指定ができるとします。 AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジションで 持っていてもまぁなんでもいいのですが、 他のクラス（ゲーム進行管理クラスなど）からそのキャラクターのAIの動作を 変更するために、例えばAI処理をタイプBに変更、そしてB特有のパラメータを設定できるとします。 こういう事を実現するために、現在はクラスZを持っているキャラクタークラスにも、 タイプA,B,Cいずれの処理に切り替えるメンバ関数、あるいはそれぞれのタイプ別にパラメータを 設定する独立したメンバ関数を設定しています。 でもこういう事をすると、AIのタイプを増やすたびにキャラクタークラスにもそれに応じた メンバ関数を追加する手間が必要になってしまいます。 もっとスマートなやり方は無いものでしょうか？ 236 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:14:56 ] 他のクラス　──→　AIクラス 　　　　　　　　　　　　　　△ 　　　　　　　　┌───┼───┐ 　　　　　　　　│　　　　 │　　　 　│ 　　　　　　　　タイプA　　タイプB　　タイプC だろ普通 237 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:17:20 ] >>235 ＞キャラクタークラスは内部にAI処理を担当するクラスZをコンポジションでもっていたとします これ、Composition とは言わないだろう…… ＞AI担当クラスZはA/B/Cの抽象クラスか、あるいはA/B/Cをコンポジション だから、Composition じゃなくて Strategy ＞からそのキャラクターのAIの動作を変更するために 今度は State？ ＞にもそれに応じたメンバ関数を どういうメンバ関数？　それほど増えるとも思えないが。 ＞もっとスマートなやり方は無いものでしょうか？ 無い。これが上限であり下限。 割りきりが必要。極端に変な動作はさせないほうが吉。 238 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:00 ] ｴｴェェェ・・・？ 239 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:40:37 ] >>235 他のクラスオブジェクトへの参照を持つ事をコンポジションというのではないのですか？ ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 いっそZへの参照を利用側に渡してしまおうかと思ったのですが、内部のオブジェクトの参照を 外部に渡してしまうのは好ましくないようなので、どうしようかと思ったのです。 Zのメンバ関数のいくつかは、キャラクタクラス以外のクラスから呼んで欲しくないものがあるので・・・。 240 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:48:58 ] 書き間違えました。 誤：ZにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 正：キャラクタークラスにA,B,C,それぞれに特有のパラメータを設定するためのメンバ関数を追加するのがいやなので、 です。 241 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:35:06 ] >>240 ABCがAIだろうがキャラクターだろうが同じじゃハゲ 242 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:44:26 ] 　　　　　　　　　┌─→AIクラス 　　　　　　　　　│　　　　　◇ 他のクラス　─┤　　　　　│　　　　　　　　　　　　 　 　　　　　　　　　│　　　　　↓　　　　　　　　　　　　 　 ┌→キャラクターA 　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB 　　　　　　　　　│　　　　　　　　　　　　　　　　　 　 　 └→キャラクたーC 　　　　　　　　　│　　　　　　　　　　　　　 　 　　 　 　 ┌→キャラクターA用のセッター 　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB 　　　　　　　　　　　 　　　　　　　　　　　　 　 　　 　 　 └→キャラクターA用のセッター 243 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:45:17 ] まちがいたｗ　　　　　　 　　　　　　　　　┌─→AIクラス 　　　　　　　　　│　　　　　◇ 他のクラス　─┤　　　　　│　　　　　　　　　　　　 　 　　　　　　　　　│　　　　　↓　　　　　　　　　　　　 　 ┌→キャラクターA 　　　　　　　　　├─→キャラクター　＜|─────┼→キャラクターB 　　　　　　　　　│　　　　　　　　　　　　　　　　　 　 　 └→キャラクたーC 　　　　　　　　　│　　　　　　　　　　　　　 　 　　 　 　 ┌→キャラクターA用のセッター 　　　　　　　　　└─→プロパティセッター＜|───┼→キャラクターB用のセッター 　　　　　　　　　　　 　　　　　　　　　　　　 　 　　 　 　 └→キャラクターC用のセッター 244 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:49:25 ] Javaで書くとこんな感じ 　　　AICharactor iaChar = ai.getCharactor(); 　　　PropertySetter setter =　PropertySetterFacotory.getSetter(aiChar); 　　　setter.set(iaChar,otherObject); 245 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 23:53:52 ] プロパティじゃなくてパラメータだなｗ 246 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 03:01:46 ] >>235 そういうときこそ継承使えばいいじゃない 247 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 11:37:58 ] 全 AI が必要とするパラメータを一つの巨大なクラスに集めて、それを渡すことにするとか。 各 AI はそのオブジェクトを一つ受け取って、自分に関係するメンバだけ触ることにすれば、インターフェイスは共通化できる。 AI が増えても、そのクラスにメンバを増やすだけで、他は一切書き換えずに済む。 再コンパイルは必要だろうけど。 248 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 15:49:22 ] みなさん、ありがとうございます。 >>247 その方法も考えていました。なんかオブジェクト指向的に完璧な解決策じゃない 気がしていたんですが、それが一番手っ取り早いのかもしれませんね。 249 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 16:03:31 ] ・・・・・・・・ 250 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 18:16:05 ] パラメータをいじる権利のある人がAIを生成して もしも途中でパラメータを変更する必要があるならそのままそいつが参照を持ちつづけ キャラクタは自分が生成されるときにAIへの参照を貰い受けるような形のほうがいいと思う パラメータを設定できないtickするだけのインターフェイスで貰えるならなお結構 251 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:45:05 ] >>235 なんかよくわからんけど、直感的にBridgeパターンが頭に浮かんだ。違うかな。 252 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 23:59:31 ] オブジェクト指向ってホントウに垣根が高いんだな・・・・ 253 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:18:21 ] たぶんずれると思うけど。 ・ゲーム進行はキャラとAiBuilderを知ってる。キャラへAiをセットする ・キャラはAIだけ知ってる ・AiとABCTypeはAiBuilderによって生成される ゲーム進行 ----> AiBuilder------- ↓ ↓ | キャラクタ ----> <Interface>Ai | △ | | ↓ AType BType CType 254 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 01:20:08 ] ずれすぎてだめだった。 ABCはAiのサブクラスね。 255 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:15:43 ] 全角スペースを使い玉へ 半角スペースは続けて使うと一つにまとめられちゃうのだ 256 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 10:19:21 ] テスト      あああ 257 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:41:28 ] interaface Param{ } interface Ai{ 　doHoge(Param param); doFuga(Param param); } interface AITarget{ 　setAi(Ai ai); Param createParam(); } class Character implements AITarget{ } 258 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 00:52:10 ] >>256 これは専ブラが半角スペースをユニコードに変換するタイプなんでおｋなんだよ 259 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 09:53:49 ] キャラクターなんていうデカイ括りがなんで必要なのかわからん まずキャラクターありきでデザインするのよそうよ 260 名前：デフォルトの名無しさん [2007/03/02(金) 21:48:08 ] 今回初めて Visitor パターンを使ってみようと思ったんだけど、 Visitor パターンって巡回順(次のaccept) は、Element に書いた方が、巡回順が再利用できていいと思うんだよね。 でもそうすると、巡回終了処理用のメソッドが欲しくなる。 結城さんの本しか見たことがないんだけど、 この実装方法は、正攻法？　邪道？ ex) public void accept(Visitor vis) { 　　vis.visit(this); 　　Iterator it = contents.iterator(); 　　while(it.hasNext()){ 　　　　((Element)it.next()).accept(vis); 　　} 　　vis.visitEnd(this); //← これのこと } 261 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 23:54:31 ] 最近はaspectあるからVisitor要らなくね？ 262 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:40:04 ] なわけないだろ。 aspectとかＤＩって害虫だろ。 そんな迷走してるより、 とっととクロージャ取り入れて、正常進化して欲しい。 263 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:47:05 ] なわけないだろ。aspectとDIは本流だろ。 264 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 03:17:43 ] AOP&DIの文脈でクロージャの話が出る理由が分からん。 265 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 07:14:09 ] それが正常進化とも思えん 266 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:17:01 ] クロージャはＤにもあるし、Javaにもいずれ実装されるからだろ。 267 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 15:14:26 ] Javasist 系は、VM が後方互換のないバージョンアップをしたとき、 手の打ちようがないよな。 Aspect がうまい具合に言語仕様に入るなんてこともなさそうだしな。 268 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 15:52:16 ] ランタイムでウィービングすりゃいいじゃん。 269 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 21:49:37 ] 　　　　　　　　　　　２ちゃんで煽りながらデザパタ学習した池沼が 　　　　　　　　　　　古い話題を壊れたレコードのように繰り返すスレ 270 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:07:11 ] ま 敢えて言うほどの事でもないがの 271 名前：269 mailto:sage [2007/03/14(水) 22:13:31 ] こんなスレ未だに見てる奴が居る事実に感動 元お豆のｓずきさんかな 272 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 02:19:28 ] たかひろくんのデザパタ幼稚園 273 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 10:43:46 ] >>33の発言は間違い。 274 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 09:22:19 ] ごふっ 275 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:59:37 ] 質問です。 テンプレートメソッドパターンを適用しようとして気になったのですが、 ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう？ （内容が同じになるものが複数組あります） 内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、 このままでは冗長です。 ぱっと思いつくのは、組ごとに共通のクラスを作っておいて 各コンクリートクラスは共通クラスのただのラッパーになる、という設計ですがおかしいでしょうか？ 使っているのはPHP5なので多重継承はできません。 276 名前：デフォルトの名無しさん [2007/03/26(月) 18:21:23 ] age! 277 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:05:42 ] ConcreteClassのユーザーから見て、 その「処理が同一だけど異なるクラス」とやらは 「全く同じクラス」にしてはいけないものなの？ 278 名前：275 [2007/03/26(月) 19:18:30 ] 微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。 例えば、 www.techscore.com/tech/DesignPattern/TemplateMethod.html ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に public class TanakasWoodCutPrint extends WoodCutPrint{} と public class SuzukisWoodCutPrint extends WoodCutPrint{} の二つが同じ内容になってしまう、という場合にどうすれば良いのか？という事です。 279 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:00:25 ] 木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？ 280 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:44:58 ] 差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。 もう一階層挟んだら綺麗にまとまったりしないかとか。 281 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:44:55 ] メモリが必要になったときに一度だけ生成されて、それ以降の記述では 必ず最初に確保されたメモリが使われるようなパターンは何というの？ C++風に描けば if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る aを使った処理… 全部グローバル変数にすればいいんだろうけど、使わない領域は 確保したくないって時にやる（a が不要になったときは回収してもOK） 282 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:46:53 ] >>281 しんぐるとんだろ？ 283 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:49:00 ] >281 Singleton 284 名前：275 mailto:sage [2007/03/27(火) 12:17:40 ] >>279 >>275で書いた共通クラスというのはそういうイメージなのですが、 タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？ >>280 symfonyでモデルクラスをＤＢスキーマから自動生成後、 各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。 285 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 22:52:26 ] っていうか、そのモデルは何を表してるモデルなのよ？ DBから生成されたものに後付で持たせたい機能って言う意味がわからん モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな 286 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 23:18:27 ] なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。 287 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 07:29:58 ] >>280 まず、モデルの定義を明確にしろ。 ・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、 ・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。 後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。 次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。 版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、 cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。 具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。 ここで、テンプレートパターンを使う。 　　ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass 　　ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass となるようにする。 もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、 同じConcreteStrategyクラスを生成して呼び出せば良い。 違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。 それだけの話ではないか 288 名前：２８７ mailto:sage [2007/03/28(水) 07:36:24 ] >>280ではなく>>275 289 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:14:53 ] symfonyってのをちらっと眺めた感じだと ＞・DBエンティティをそのまま表したクラス(状態) どうもこっちみたいだから、 そもそも適用するレイヤを間違ってる説が有力。 290 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:51:39 ] ODBMS屋乙。 > そもそも適用するレイヤを間違ってる説が有力。 それは前提を勝手に仮定した偏った意見に見える。 >>275の話が 　・どのようなアプリケーション・アーキテクチャ〜レイヤ構成を前提としているか 　・一つのレイヤ限定の話なのか 　・複数のレイヤにまたがった話なのか によって、いくらでも回答の仕方があるだろう。 例えば、 下のレイヤで、オブジェクトの静的状態をDBMSに格納し、 上のレイヤで、オブジェクトの振る舞いをどう扱うか という問題を仮定した場合にも、 ・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法 ・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態 　を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法 の二通りが考えられる。 >>287は、後者の立場から説明した。 291 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:58:15 ] 補足： 前者の立場でも 　　DBMSエンティティ＝静的状態＝ドメインオブジェクト　 と呼ぶことがあるが、 オブジェクト指向本来のドメインオブジェクトは、後者。 292 名前：275 mailto:sage [2007/03/28(水) 12:42:19 ] symfonyは一つのテーブルから二つのクラスを生成する。 テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる） 問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。 なのでそのクラスにそのデータを使うメソッドを書こうかと。 今、>>287の方法でやっていますがこれで良さそうです。 ありがとうございました。 293 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:31:09 ] エンティティとデータアクセスオブジェクトが自動生成ってことか データアクセスはデータアクセスに特化させる方がいいだろねー クラスの「役割」のくくりを大きくすれば、計算からデータの編集、保存まで一緒くたに するって考え方もアルンかもしレンガ、普通はもっと細分化するもんだ。 public　WoodCutPrintContext{ 　　　public void doWoodCutPrint(){ 　　　　　　Coodinator coodinator = getCoodinator(); 　　　　　　Hanzai hanzai = coodinator.getHanzai(); 　　　　　　DrawProcessor drawProcessor = coodinator.getCutProcessor(); 　　　　　　hanzai = drawProcessor.draw(hanzai); 　　　　　　CutProcessor cutProcessor = coodinator.getCutProcessor(); 　　　　　　hanzai = cutProcessor.cut(hanzai); 　　　　　　PrintProcessor printProcessor = coodinator.getPrintProcessor(); 　　　　　　printProcessor.print(hanzai); 　　　} } public 田中君 implements Coodinator { 　・・・ } public 鈴木君 implements Coodinator { 　・・・ } 294 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:34:25 ] ×；DrawProcessor drawProcessor = coodinator.getCutProcessor(); ○：DrawProcessor drawProcessor = coodinator.getDrawProcessor(); w 295 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 12:59:19 ] >>293-294 > 　　　public void doWoodCutPrint(){ 身元バレバレっすよ兄貴ぃ 閑話休題 他の言語、他のフレームワークを使っている人間に 余計なコメントをつけても混乱するだけだ。 もしアドバイスをつけたいなら、Javaではなく PHP5+symfonyの例に即したアドバイスをしろ。 例えば、 ・ データクラスの生成(検索、保存) ・ データクラスの処理(計算、処理) はべき乗パターンに則って別クラスにすべきだ、などという説は そのような冗長な設計が「PHP5＋symfony」に適しているかどうか、 という観点で議論すべきである。 だが、俺はそこまで突っ込むつもりはない。 そんな事をいちいち調べるつもりはないし、 質問者も困惑するだけだからだ。 296 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 13:11:21 ] >>293 つか、今気付いた。 おまいは TemplateMethod Patternを共用したい という質問に対して、全然別の回答をつけている。 特に、クラスの命名がデタラメだ。 ×× public　WoodCutPrintContext{ ... } ×　　public class WoodCutPrintContext{ ... } ○　　public class WoodCutPrintProcess { ... } 297 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 14:58:49 ] ---------------------------------------------------------------------------- デザインパターンにおける Contextの用例 1. Interpreterパターン 　 www.hellohiro.com/pattern/interpreter.htm 　 言語に対して、文法表現(Expressionクラス)と、 　 文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。 　 (注： Inerpreterクラスは付帯的に、言語の束縛〜副作用を表す評価環境(Context)を持つ) 2. Stateパターン 　 www.hellohiro.com/pattern/state.htm 　 オブジェクトの内部状態が変化したときに 　 オブジェクトの処理内容を変えられるようにする。 　 (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) ---------------------------------------------------------------------------- >>293のクラス名 WoodCutPrintContext は、 クラスの役割を表現しておらず不適切な命名と言える。 298 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 15:32:52 ] ---------------------------------------------------------------------------- デザインパターンにおける Contextの用例 【追加と訂正】 2. Stateパターン 【訂正】 　 × (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) 　 ○ (注： ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。　←【訂正】 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) 3. Strategyパターン 【追加】 　 www.hellohiro.com/pattern/strategy.htm 　 Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。 　 それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。 　 (注： ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。 　　　　 個々のアルゴリズムは、個別のConcreteStrategyクラス (〜A, 〜B, 〜C)に記述する。 　　　　 個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。) ---------------------------------------------------------------------------- もしかして >>293は、 　　鈴木、田中 ＝＝ StrategyパターンのConcreteStrategyクラス、 　　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス) と言いたかったのか？ だが、それでは 　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 　・鈴木が田中の手を借りて版画を彫る が全く同じ表現になってしまう。これは不適切だ。 299 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 16:59:49 ] ↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。 「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。 300 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:43:29 ] ■>>293の表現　「鈴木が田中の手を借りて版画を彫る」 /* >>293のコード　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 { // ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君はコンテキストを使って版画を彫る。 　　// 注：　鈴木君のコンテキストには手配師へのコネがあり、 　　//　　　　手配師は、仕事の各工程をメンバーに適当に割り振る。 　　WoodCutPrintContext context 　　　= WoodCutPrintContext.getinstance(); 　　// 鈴木君は、寄せ集めメンバーがバラバラに各工程を担当した 　　//　ツギハギ細工を、自分の成果として公開する。 　　return context.doWoodCutPrint(); 　} } 　　　　　　　↓ /* 「手配師が田中君しか集められなかった場合」の * 　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 田中君を拉致る 　　田中君 agent = 田中君.getInstance(); 　　// 田中君に強制労働させ、成果を横取りして提出する。 　　return agent.createWoodCutPrint(); 　} } 301 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:44:38 ] ■正しい表現 「鈴木と田中が全く同じやり方で版画を彫る」 public class 鈴木君 { 　// 鈴木君には版画を彫るスキルがある。 　public WoodCutPrintStrategy getWoodCutPrintStrategy() { 　　// 鈴木君のスキルは、一般にAと呼ばれるスキルである。 　　return WoodCutPrintConcreteStrategyA.getInstance(); 　} 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君は自分のスキルで版画を彫り、成果を提出する。 　　return getWoodCutPrintStrategy().doWoodCutPrint(); 　} } 302 名前：デフォルトの名無しさん [2007/03/29(木) 18:00:19 ] >>300 バグを発見しますた。 鈴木君の一人プロジェクトが無限ループを起していて いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ /* 「手配師が鈴木君本人しか集められなかった場合」の * 　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君が自分を拉致る 　　鈴木君 agent = 鈴木君.getInstance(); 　　// 鈴木君はいつものようにメンバーに強制労働をさせて、 　　// 成果だけ横取りするつもりだったが、 　　// 結局自分一人では何もできずに 　　// 貯え(VMスタック)を消費しつくして終了 　　return agent.createWoodCutPrint(); // 無限ループで　throw RuntimeException("スタックオーバフロー") 　} } 303 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 18:38:56 ] エロゲで使われているパターン Singleton 他なんかある？ 304 名前：300 mailto:sage [2007/03/29(木) 18:52:15 ] >>302 バグｽﾏｿ( ; -_-) >>294版鈴木君の等価コードはこうだ。 public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　/* 以下、手配師付き変形TemplateMethod(ｺﾝﾃｷｽト)内の等価ｺｰﾄﾞ */ //{ 　　　// 鈴木君は手配師を呼ぶ。(メンバー一人の場合、自分が手配師になる) 　　　Coordinator slave = this; 　　　// 手配師に各工程担当者を集めさせて、 　　　// 版材を準備し、版材処理を実行する。 　　　Hanzai hanzai 　　　　= slave.getCutProcessor().cut( 　　　　　　slave.getDrawProcessor().draw( 　　　　　　　slave.getHanzai())); 　　　// 版材を刷る。 　　　slave.getPrintProcessor().print(hanzai); 　　//} 　　return hanzai; 　} 　public Hanzai getHanzai() { reuturn new Hanzai(); } 　public 切り方 getCutProcessor()　 { return 切れ方_0893D.getInstance(); } 　public 書き方 getDrawProcessor() { return 書き方_1919Z.getInstance(); } 　public 刷り方 getPrintProcessor()　{ return 刷り方_0212A.getInstance(); } } // Functorパターン public class 切り方_0893D extends 切り方 { public Hanzai cut(Hanzai hanzai) { /* 何もしない */ } } public class 書き方_1919Z extends 書き方 { public Hanzai draw(Hanzai hanzai) { /* 何もしない */ } } public class 刷り方_0212A extends 刷り方 { public Hanzai print(Hanzai hanzai) { /* 何もしない */ } } 305 名前：デフォルトの名無しさん [2007/03/29(木) 19:46:45 ] まとめると、 >>275＝>>284の質問(>>292で解決済) 　テンプレートメソッドで、処理が同じものがある場合に、 　(注： 同じなのは、TemplateMethod単位か、個々のメソッド単位か不明) 　どのようなクラス設計をしたら良いか？ >>279-280、>>285-290の回答 　TemplateMethod単位で同じものがあったら、 　それをStrategyパターンで外出しして共用すれば良い。 ※ここまではOK >>293の回答 　TemplateMethodの個々のメソッド単位で同じものがあったら、 　それをStrategyパターンで外出しして共用すれば良い。 ※>>293の実装コードは 　　ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割 　　Coordinatorインタフェースを割り付けている点がおかしい。 　　鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。 306 名前：305 [2007/03/29(木) 19:47:36 ] >>293の実装コードの問題点 分析/設計で得たモデルの特性として、 「手順を構成する複数の工程について、 　各工程の処理方法にバリエーションがあり、 　なおかつ、各処理方法は互いに交換可能」 な事が明らかならば、>>293の実装もありえる。 しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、 不吉な匂いがする。・・・数100人月のシステムで、 このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。 どのような場合にこの実装/設計が破綻するかと言うと、 設計/初期実装に見落としがあって、 Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合 である。この場合、Hanzaiインタフェースのバリエーションに関して、 各処理方法は互いに交換可能でなくなる。 正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ〜 307 名前：デフォルトの名無しさん [2007/03/29(木) 20:14:36 ] デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。 プロトタイプ作成時は、「版画」は１種類だけ考えれば済むから、 その版画作成に使う版材も、処理手順も、詳細処理方法も１種類ずつで済む。 ・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、 　　開発もバッチグーね？とお気楽モード。 ところが開発展開になってから、 「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、 「異なる版画には、異なるサイズや材質の版材が必要」な事とか 「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」 ってな事にも、おそまきながら気付く。 　　　　　　　　　　　　　　　　　　　　　　　　アーキテクチャ設計ﾊﾀｰﾝｗｗｗｗ ・・・いや、気付いてても気付かないフリしたんだろう、 　　アーキテクチャ設計のボンクラ共は。 じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・ 幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。 その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったｗｗｗ 共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。 それでは、正しい解決方法はどこにあるのか それを私は知っているが、このレスにはもう余白がないので書けないｗ 308 名前：鈴木 [2007/03/29(木) 22:31:38 ] おまいら、俺の名前を気安く使うな、不愉快だぞ 続きは「佐藤クン」で 309 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:37:17 ] 上がダメなら、下の名前ならおｋ？ 例えばひろゆきとかゆきひろとかたかゆきとかあと 310 名前：デフォルトの名無しさん [2007/03/29(木) 22:49:30 ] 問題はドメイン・モデリングの欠落だなｗ 311 名前：デフォルトの名無しさん [2007/03/29(木) 22:55:01 ] 問題領域が「版画作成」なら、最終目的は「版画」だけど、 問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ〜よなｗ つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話 312 名前：デフォルトの名無しさん [2007/03/29(木) 22:57:26 ] 「業務処理」の目的は、DB更新と電文(w。 313 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:58:09 ] >>312 それはありえん 314 名前：鈴木 [2007/03/29(木) 22:59:24 ] >>309 それもダメだ、かすってる 鈴木の続きは「都築」でどうだ 315 名前：デフォルトの名無しさん [2007/03/29(木) 23:03:13 ] >>314 じゃニックネームで手を打とうぜ。 例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ 316 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:05:28 ] >>309、>>315 　見事なまでのプロダクトラインだなｗ 317 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:07:17 ] 閑話休題 318 名前：デフォルトの名無しさん [2007/03/29(木) 23:10:48 ] >>312 ある種の基幹系業務システムは、 構築難易度を下げて抽象化すると、 結局、マスタメンテ型アプリに帰着する。 すると、最終目的がマスタ更新ってのも そんなにずれていない。 するとオブジェクト指向で書く必要ないんだな、これが。 （終了） 319 名前：デフォルトの名無しさん [2007/03/29(木) 23:13:24 ] )再開( 320 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:17:09 ] GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ 321 名前：デフォルトの名無しさん [2007/03/29(木) 23:17:18 ] ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。 322 名前：デフォルトの名無しさん [2007/03/29(木) 23:22:56 ] >>321 M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。 CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、 所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ） ちょっと後悔（ｳﾂｳﾂｳﾂｳﾂｼｸｳﾂｳﾂｼｸｼｸｳﾂｳﾂｳﾂｳﾂｳﾂｼｸｼｸｼｸｼｸｳﾂｳﾂｳﾂ そんな事じゃいかん。俺はCMU/SEIはともかくとして、 日本のCMMI連中とは全然話が合わないんだったｗ なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆 323 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:29:25 ] >>322 特に無い。 324 名前：デフォルトの名無しさん [2007/03/29(木) 23:38:44 ] >>320 確かに飽きてきたのも事実 だが使いこなせてる奴が意外と少ないのも事実 325 名前：デフォルトの名無しさん [2007/03/29(木) 23:45:29 ] だが使いこなせてる奴は１０年前から退屈してるのも事実 326 名前：デフォルトの名無しさん [2007/03/29(木) 23:49:47 ] 2PLoP (2ch Pattern Language of Programming)報告： Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、 まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。 彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。 トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、 Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。 　　　　　pc11.2ch.net/test/read.cgi/tech/1172431242/ 327 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:56:05 ] 糞コード放置してった >>293は 今どこで野垂れ死んでいることやら 328 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:05:24 ] >>326 Pythonというか、いわゆる軽量言語にデザパタはいらんのじゃないかなぁ。 大規模開発にはそもそも向いてないでしょ。 もしかしたら、オブジェクト指向すらいらないかもしれないし。 馬鹿にして言ってるのではなくて、住み分けがあるだろうと。 大規模開発は javaなり c++ なりでデザパタを使って書けばいいし、 身近なユーティリティーを書くなら、軽量言語というか perlででも書いた方がいいし。 大規模開発に向かん言語で、デザパタっていっても そもそも意味がないと思うんだな。 329 名前：デフォルトの名無しさん [2007/03/30(金) 00:14:09 ] >>328 常識的な意見ってツマンナイよ rubyからrailが生まれたし、javascriptからAJAXが生まれた そんなご時世なのだ 330 名前：デフォルトの名無しさん [2007/03/30(金) 00:18:07 ] >>328 マジレスするぞ。 Pythonは関数言語的機能のほかに、 metaclassシステムやら、動的言語の性質をあちこち持ってるから、 C++やJavaよりよっぽどSmalltalk寄り。 そこにあろうことかJava版GoFを移植したってのが笑い所。 あと、後半部「ボトムアップでパターン抽出」 これは別に間違ってないだろ。 むしろ、将来Javaに取り入れるべき言語機能やパターンを 発見できるかもしれない(もう金脈は小さいと思うけどな)。 文句ばっか言って他をけなしてないで、 学ぶところは学びなさいってこったｗ 331 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:24:32 ] 関連ないが、Perlのプロトタイプ系OO拡張、あれは結構糞だ。 OOの面倒くさい所と、Perlのいい加減な所がダブルで来る。 でも、Javaと同様なクラスライブラリ書き始めると、 あっちの方がよっぽど融通利いて手早く完成する。 さすが90年代のLispと呼ばれただけの事はあるな。 関連ないが、Javascriptのプロトタイプ系OO機能、あれは最高だ。 あれ一つでずいぶんJavascriptのコードが書きやすくなる。 問題はjavascriptエンジンのバグやエラー報告の不充分さ。 あれ使って10年程前にAJAX風アプリ書いてた時は、 試行運用中に山のように実行時エラーがでて閉口した。 今の連中は幸せだよなぁ。あれで、Netscapeがまだ生き残ってたら 万々歳なんだが。 パターン関係ないチラ裏ｽﾏｿ 332 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:26:57 ] >C++やJavaよりよっぽどSmalltalk寄り。 て言われても、Smalltalk てそんなにいいのか？ 動的言語と言われた時点で、うーみとなりそうだけどなぁ。 型は、事前に論理的誤りを検出するためにあるんだぜ？ それを最初に省いたら、あとから泣きみるだろ。 それでデザパタが必要とされるような大規模開発に 向いてるといえるのだろうか？ 333 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:27:09 ] > OOは大規模開発向け だなんて地に足のついてない発言してる人が まだ国内に居ると知って、ﾜﾛﾀ 済まないが、実績作ってから言ってくれ おまいらの作ってるのはOOじゃねぇだろ 単にOO系言語でOOP風の事をしました（でも中身はCOBOLそっくり） だろ 334 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:28:45 ] >>232 あぁーあ。今度はCS系関数言語厨房か。 マイクロソフトリサーチの人が なんとかしてくれるだろ。 335 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:29:28 ] > デザパタが必要とされるような大規模開発 どっから出てきた妄想ですか？ 336 名前：デフォルトの名無しさん [2007/03/30(金) 00:31:22 ] すげぇずうずうしさだなコイツ >>306-307, >>310-312, >>318で 大規模(自称)OO開発の失敗例 ケーススタディしたばっかだっつうのに、 解決策も出さずに「大規模OO開発」かよ。 337 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:32:59 ] なんだよ、Py厨だけじゃないのかよ。 てか、py厨が引っ掻き回してるのか？ ただな、デザパタなんてなくてもやれるし、あったらあったで 便利だし、ぐらいのところでいいだろ。 実際、それ以上でもそれ以下でもないし。 338 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:33:59 ] > 型は、事前に論理的誤りを検出するためにあるんだぜ？ そんなキミには、汎用純関数型言語Haskellを使って、 monadic programmingを駆使した通信ミドルウェア開発が オヌヌメ。使用検証技術も必須だよ？jfitsの人がやってるような奴 339 名前：デフォルトの名無しさん [2007/03/30(金) 00:36:05 ] 大規模(自称)OO開発の失敗例 ケーススタディ　　>>306-307, >>310-312, >>318 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ に解決策提案するまで、 大規模OO開発へのデザインパターン適用の話題自粛で お願いします。 340 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:36:10 ] 何この盛り上がりようｗ 341 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:37:31 ] たかびー祭＋ﾋﾟﾁｮﾝﾊﾟﾀｰﾝ祭　合同イベント 342 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:40:04 ] おいおまいら騒ぐな > 大規模OOにデザパタ必須 って言ってる人の大規模は、 せいぜい数千行〜数万行ぽっちの事だぞ、きっと 343 名前：333=336 mailto:sage [2007/03/30(金) 00:42:56 ] >>328 どうぞご自由に個人〜数人の範囲で 大規模開発しててくださいです。 いや、それくらいの規模が一番いいと思うよ。 がんばれー 火ぃ噴くのは、プログラムもろくにできないのが 数十人単位で集まっちゃうような地獄の話だからｗ 344 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:44:49 ] なんなんだよ、この盛り上がり。 そんなにヒマがあるなら、その、なんだ、Pythonのその膨大な過去の 素敵なコードの資産から、スマートなパターンを抽出して、 俺らをあっと言わせてくれよ。 もう、ずいぶん作業は進んでるんだろ？ ここで威張ってるぐらいなんだから。 345 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:46:34 ] >>344 /~ytakagi/ に直接言え。 もっとも連絡先も書いてねぇけどｗ 346 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:48:29 ] 盛り上がってもいいけど、もっと具体的な話してくれ。 抽象論は聞き飽きた。 347 名前：293 mailto:sage [2007/03/30(金) 00:50:44 ] 物凄いレス着いたｗ >>295 PHP５＋symfonyなんてしらね >>296-297 で座ﾊﾟﾀなんてクソ喰らえｗ >>298 ＞　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス) ＞と言いたかったのか？ その意味も含んでるけど ＞だが、それでは ＞　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 ＞　・鈴木が田中の手を借りて版画を彫る ＞が全く同じ表現になってしまう。これは不適切だ。 が意味不明。 どこをどうすれば鈴木君と田中君の接点が見えてくるのか？ >>300 勝手に解釈して話を進めないようにｗ >>301- 目が疲れたから読めん っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、 ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ 348 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:50:51 ] 一体何を聞きたいんだ？ ・ソフトウェア・プロダクトラインのための資産管理 ・大規模開発へのOOおよびデザパタ適用の是非 ・そのほか 349 名前：デフォルトの名無しさん [2007/03/30(金) 00:54:30 ] とりあえず、>>293は ・話の発端(PHP5+symfony)も見えてないし ・クラス命名のセンスもないし ・クラス設計のセンスもないし ・等価コードの意味も理解できないし ・目が悪くて人の話も聞かない 奴である事だけはかろうじて理解できた でなんか用かよタコ 350 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:59:16 ] > ＞だが、それでは > ＞　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 > ＞　・鈴木が田中の手を借りて版画を彫る > ＞が全く同じ表現になってしまう。これは不適切だ。 > が意味不明。 > どこをどうすれば鈴木君と田中君の接点が見えてくるのか？ お前はシャレも解せぬ不粋な人間だと理解した 351 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:00:00 ] >　っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、 >　ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ はいはい釣れた釣れた 352 名前：293 mailto:sage [2007/03/30(金) 01:09:32 ] 終わりか？ ＞・クラス命名のセンスもないし ＞・クラス設計のセンスもないし それは否定できんなｗ ほいじゃーね 353 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:09:50 ] 思い切り東陽町スタイルだな。あの糞コード 354 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:11:19 ] > public　WoodCutPrintContext{ 単にソースコード保守するだけの 運用チームじゃないかな、彼は 355 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 15:41:55 ] >>293の元設計の問題点 1. 詳細設計〜実装の主眼を「コード再利用率の向上」に置いたのが誤り。 　 小手先のテクに走らず、分析〜設計段階で一貫したドメインモデルを用い、 　 それを素直にコード化して、保守性・拡張性を高める事こそ重要である。 2. 継承や委譲を駆使した「差分コードプログラミング」は煩雑過ぎて人間の手に余る。 　 もし本気で「差分コード」を扱いたいなら、アスペクト指向開発方法論(AOSD)を取り入れ、 　 差分定義の組み込みはAOP言語のweaving機能に任せろ。人間の手でやるな。 　 ・・・だが残念な事に、アスペクト指向言語はまだ底辺現場で使える段階にはない。 つづく 356 名前：293 mailto:sage [2007/03/31(土) 00:03:16 ] >>293から50レス以上あって くだらない能書きは大量に吐き出されたが もっと良い解決方法を提示するコードが出てこないとはｗ 所詮は口だけ、本を読んだだけの頭でっかちで現場で使えん奴らばかりだなｗ コリャデスマがなくならないわけだ 357 名前：デフォルトの名無しさん [2007/03/31(土) 02:06:50 ] お前のコードの問題点は示しただろ？すずき 358 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:55:10 ] >>356 一応いっておくが、おまいに絡んでるのはキチガイ一人だけだ。 359 名前：デフォルトの名無しさん [2007/03/31(土) 11:48:32 ] >>358 議論しているのをキチガイ呼ばわりする奴って どこにでもわくのな 360 名前：デフォルトの名無しさん [2007/03/31(土) 11:52:26 ] 【ひろたかと２ちゃんの不思議な関係】 ・ひろたかがかつて在籍していた会社は全て、ひろたかが去った直後に 　２ちゃんでしつこく攻撃される。 ・ひろたかの元仕事相手、脳内ライバル、 　その他ひろたかが自分にとって脅威だと感じる対象は、 　２ちゃんのあちこちのスレに中傷文が書かれる。 ・ひろたかが出没するスレには 　常に「キチガイ」「発狂」を連発する荒しが発生する。 ・２ちゃんに居る頭も性格も悪い粘着に　　　　　　　　　　　　　　　← いまココ 　噛んで含めるように高度な概念を教えてやると、 　いつの間にかたかひろ本人も同じ意見を主張するようになるｗ ・ひろたかは論破されていても、それに気付かないフリをして勝利宣言をする。 ・ひろたかは論破されると、他のスレで暴れる。 ・ひろたかは成りすまし/匿名発言をよくするが、それが見破られると 　「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。 さ〜て、また荒しが発生するのかなｗ 361 名前：293 mailto:sage [2007/03/31(土) 12:56:20 ] >>358 そういわれるとちょっと寂しい気も・・・ｗ >>357,359 議論になってな（ｒｙ >>360 「いまココ」ってところで、「ひろたか」が「たかひろ」になってるってことか・・・ｗ 362 名前：デフォルトの名無しさん [2007/03/31(土) 13:15:59 ] >>361 議論になっていないと考える低脳はお前だけだ 363 名前：293 mailto:sage [2007/03/31(土) 13:27:20 ] だってボク低脳ですから 364 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:39:50 ] >>293の元設計の問題点 (つづき) 2-1. Bridgeパターン・スパゲティ (クラスの過剰分割によるOOモデルの崩壊) 　>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1) 　　※1.createWoodCutPrint() の //{ ... //} 内は､下記の等価コード｡ 　　　　WoodCutPrintContext.getInstance().doWoodCutPrint() 　>>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、 　｢Coordinatorパターン｣とでも呼ぶべき｢変形Bridgeパターン｣を導入し、 　Coordinatorで処理詳細の選択できるようにした。 　　(注:蛇足だがこの種のカスタマイズには、 　　　　古くから使われている DI (Dependency Injection)パターンの方が適している。 　　　　更に蛇足だが、カスタマイズ内容はコード中に直接記述したりはせずに、 　　　　外部ファイル(XML形式)に分離記述して後から変更可能にするのがマナーである。 　このコード(>>293, >>304)は､その字面の単純さにもかかわらず､ 　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い) 365 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:55:01 ] くだらねえことをいつまでもグダグダ書いてるが、>>275の問題の本質は 「テーブルとクラスをどうやってマッピングするか」ってところにあることに気づけや。 マッピング後のクラス設計以前の問題。 んでhibrenateとか見る限り、今のところ碌なやり方は存在しない。 366 名前：デフォルトの名無しさん [2007/03/31(土) 13:59:48 ] うっせぇぞ低脳。 お前はさっさとODBMS営業逝ってこいや 負け犬が 367 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:03:10 ] ODBMS（ｗ ぷぷぷ もう10年前にたかひろの子分に 「(製造業など一部の特殊分野を除いては) 　仮想記憶方式のODBMSなんてもう売れねぇよ」 って伝えたはずだけど。まだ悪あがきしてたんか。おめでてぇなｗ 368 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:10:47 ] そん時に提示した代替手段が、 ・ ORマッピングによるRDBMSとの共存 ・ Stonebreaker氏のORDBMSの発展 だったな。 369 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:41:39 ] >>293の元設計の問題点(つづき２) (2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊)) 　>>293のコード(及び>>304の補足コード)は､その字面の単純さにもかかわらず､ 　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い) 　(1)挙動を読み取りにくくなる原因： 　　原因(1-1) データと処理の分離記述による、カプセル化の破壊。 　(2)保守性が悪い原因： 　　原因(2-1) カスタマイズ内容のハードコーディング。 　　　　 クラス選択の変更や、クラスの新規追加の度に、コード修正が必要になる。 　(2)前提条件の変化に対し柔軟性が低くなる原因： 　　原因(3-1) モデルの過剰な単純化により、現実世界の複雑な問題に適応できなくなる。 　以下では、その原因を探る。 　原因(1-1)データと処理の再分離による､カプセル化の破壊 　　　　オブジェクト指向では､データとその処理をカプセル化し、クラスを導入する事で 　　　　(1)データ操作の局所性 　　　　(2)外部操作インタフェースの限定、 　　　　(3)型システムによる安全性/信頼性の向上 　　　　が可能になり、それを利用してプログラムの信頼性/可読性/保守性の向上を図れる。 　　　　しかし>>293,>>304のコードでは、 　　　　データ(Hanzai及びﾊﾞﾘｴｰｼｮﾝ)と処理方法(〜Processor)を別々のクラスに分離記述した後、 　　　　関連するデータクラスと処理クラスを適切な方法で再カプセル化しなかったため、 　　　　オブジェクト指向のメリットが得られなくなっている。(非ＯＯ的コード) 370 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:59:40 ] >>355、>>364、>>369 その問題点を直したスケルトンコードを頼む 371 名前：293 mailto:sage [2007/03/31(土) 15:13:25 ] >>365が僕の考えからは少し極端な意見だがいいこと言った。 まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに とらわれないコードを書いたんだがね。 自分のレスの後だったんでよっぽど悔しかったんだろうｗ。 だが少しだけ付き合ってあげようｗ ＞　>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1) なりません。 ＞　>>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、 ・・・・ ＞　このコード(>>293, >>304)は､その字面の単純さにもかかわらず､ ＞　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い) カプセル化を否定しているように聞こえるが？ そもそも鈴木君や田中君をドメインとして（まぁドメイン領域内のある部分ではあるが）時点で設計が 崩壊してるんだけどｗ >>278の要件を分析してみると、 １．このケースの主処理は木版が作成プロセスである。 ２．鈴木君や田中君は木版画作成プロセスのバリエーションである。 この2点から、木版画作成プロセスを中心に考えて、どのように違いを吸収していくかを考えないと遺憾のとちゃうの？ で、 ３．木版画作成プロセスから見た場合、鈴木君や田中君（、山田君、佐藤君・・・・）の役割は、 　　木を塗ったり切ったり印刷したりの方法論を持っているオブジェクト。 ４．鈴木君や（略）画持っている方法論は、皆違う場合もあれば同じ場合もあるから、鈴木君や田中君（ry)と独立するべき。 　　（そもそもの>>275の要件） となるのが自然な設計だと思うけど？ 372 名前：365 mailto:sage [2007/03/31(土) 15:25:41 ] >>371 キチガイにかまわないであげてください。 373 名前：293 mailto:sage [2007/03/31(土) 15:34:06 ] >>372 むむ・・・ スレが荒れてしまいますな・・・ まぁ彼が言うクラス粒度が細かくなりすぎると見通しが悪くなるのは事実だけどね その辺の加減が難しい・・・ 374 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 15:51:23 ] 　-- 引き続き、元質問者(>>275) の挙げた例題(>>278) を題材に､ -- 　-- デスマ現場で発生した問題 (>>306-307) を論じる｡　　　　　　　-- 375 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 15:53:01 ] >>293の元設計の問題点(つづき２) (2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊)) 　原因(3-1)モデルや型の過度な単純化による、複雑な問題への適応能力低下。 　　　　現実の問題は、>>293のような単純な構造は持っていない。 　　　　まず、データにはバリエーションがある。 　　　　例えばデスマ事例(>>306-307)で指摘されているように、 　　　　操作対象となるオブジェクト/データ(Hanzai)は一種類ではなく、 　　　　実際には何種類ものバリエーションが存在する。(分析モデル) 　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版 　　　　　　　　　　 │　　　　　　　　 │　　　 └ 硬い木版 　　　　　　　　　　 │　　　　　　　　 ├ ゴム版 　　　　　　　　　　 │　　　　　　　　 ├ 芋版 　　　　　　　　　　 │　　　　　　　　 └ 銅版 　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai 　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai 　　　　　　　　　　 └ 完成した版画版 　　　　　※ ここでHanzaiのサブクラスは、 　　　　　　工程進行に伴う状態変化 (原料→下絵中→切除中→完成) と見なせる。 　　　　　　ただし、後工程になるほどデータの内部構造は複雑になっていく。 　　　　 　　　　次に、データはしばしば単純なモノシリック構造ではなく、 　　　　複数のデータを内部構造として持つComposite構造を持つ。 　　　　　完成した 　　　　　　版画版 ◇┬ 背景部 ◇─(略) 　　　　　(人物画)　　└人物部 ◇┬ 頭髪 　　　　　　　　　　　　　　　　　　　　├ 顔　 ◇┬ 目 　　　　　　　　　　　　　　　　　　　　│　　　　　├ 鼻 　　　　　　　　　　　　　　　　　　　　│　　　　　└ 口 　　　　　　　　　　　　　　　　　　　　├ 上着 376 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 15:59:12 ] 　　　　当然のように、処理もこのComposite構造の対応している必要がある。 　　　　　人物画のゴム版画の為の 　　　　　切除処理 ◇┬ 背景部 ◇─(略) 　　　　　　　　　　　　　└人物部 ◇┬ 頭髪パターン切除 　　　　　　　　　　　　　　　　　　　　　├ 顔　 ◇┬ 目をリアリスティックに表現する切除 　　　　　　　　　　　　　　　　　　　　　│　　　　　├ 鼻の膨らみを表現する切除 　　　　　　　　　　　　　　　　　　　　　│　　　　　└ 口の生々しさを表現する切除 　　　　　　　　　　　　　　　　　　　　　├ 毛皮パターン切除 　　　　それでは、切除工程の操作は、作成対象データ(人物画)と同じComposite構造を持ち、 　　　　素材×Compositeの要素数分必要になるのか？ 　　　　そんな事はない。 　　　　例えば、頭髪パターン切除と、毛皮パターン切除には同じ切除テクニックが使える。 　　　　これが現実世界の共用だ。 377 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:11:43 ] 御託はいらん 読む気も無い 378 名前：デフォルトの名無しさん [2007/03/31(土) 16:12:41 ] 【そして、現実の世界へ・・・】 それではここで、精神性疾患患者たかひろの設計でデスマ化した デスマ事例(>>306-307)に戻ろう。 途中から読んでいる方には何の事やらサッパリ判らないだろうから 説明を加えると。 >>293のコードは、精神性疾患患者たかひろが、その劣悪なる知能で設計し その結果デスマを巻き起こしたコードと極めて類似している。 したがって、>>293の詳細な分析は、デスマ事例コードへの解決策を与えるのである。 379 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:39:53 ] いまごろ解決しても、お前の頭がおかしくなったのはもとには戻らん。 あきらめろ。 380 名前：ﾜﾛｽ [2007/03/31(土) 16:46:39 ] ｢版画の世界｣から、｢デスマ・システム｣への概念マッピング（・∀・） ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　　　　　　　 　【版画作成アプリ】　　　　　　　【マスタメンテ型基幹システム】 [主要ドメイン] 版画作成プロセス　　　　　　　マスタ更新プロセス [主要データ]　下絵、原料版材　　　　　　　　 入力 (画面入力,電文入力) 　　　　　　　　　完成した版画版　　　　　　　　出力 (ＤＢ更新,電文出力,) 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 (付帯的な画面出力) [主要プロセス]版材取得　　　　　　　　　　　　入力取得 　　　　　　　　　下絵作成　　　　　　　　　　　　入力取得 　　　　　　　　　版材の品質チェック　　　　　　入力チェック 　　　　　　　　　下絵と切除テクのマッチング　業務チェック 　　　　　　　　　切除処理　　　　　　　　　　　　ＤＢ参照、演算処理、ＤＢ更新 　　　　　　　　　印刷処理　　　　　　　　　　　　出力処理 (画面出力,電文出力) 381 名前：デフォルトの名無しさん [2007/03/31(土) 16:49:08 ] 【たかひろと２ちゃんの不思議な関係】 ・たかひろがかつて在籍していた会社は全て、たかひろが去った直後に 　２ちゃんでしつこく攻撃される。 ・たかひろの元仕事相手、脳内ライバル、 　その他たかひろが自分にとって脅威だと感じる対象は、 　２ちゃんのあちこちのスレに中傷文が書かれる。 ・たかひろが出没するスレには 　　　　　　　　　　　　　　　　← いまココ （・∀・）>>358, >>371, >>379 　常に「キチガイ」「発狂」を連発する荒しが発生する。 ・２ちゃんに居る頭も性格も悪い粘着に　　　　　　　　　　　　　　　 　噛んで含めるように高度な概念を教えてやると、 　いつの間にかたかひろ本人も同じ意見を主張するようになるｗ ・たかひろは論破されていても、それに気付かないフリをして勝利宣言をする。 ・たかひろは論破されると、他のスレで暴れる。 ・たかひろは成りすまし/匿名発言をよくするが、それが見破られると 　「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。 さ〜て、まだ荒しを続けるつもりかな？ 382 名前：デフォルトの名無しさん [2007/03/31(土) 16:51:04 ] またたかひろが暴れてるな 　 　そう。お前自身の信仰は誰も問題にしていない。 　例え神の存在を否定する信仰だろうと、 　ここ日本では誰もメクジラなど立てない。 　 　お前が問題なのは、 　お前がお前自身の信仰を大切にしているのと同様に、 　他人も自身の信念や大切なものを抱えながら生きている 　という事を理解せずに、 　・他人の信念を批判しまくったり、 　・自分勝手で不合理な自己主張をおしつけたり、はたまた　 　　　匿名で　他人の名前を挙げて 　　　執拗な人格批判/いやがらせを繰り返している 　という事実にある。 　お前と正式に顔を合わせて以来もう数年経つが 　ある日突然ﾈｯﾄ上で名前を挙げて非難が開始され俺はとまどった。 　俺は匿名で非難を浴びるような生き方は、これまで一切していない。 　なのに、お前に会ってしばらくしてから突然攻撃が始まった。 　最初はお前の周辺に異常者が居て、俺を攻撃してるのかと思った。 　・・・でも結局お前がその異常者本人だと気付いた。 　お前しか知りえない情報、お前しか感じ得ない感情で 　キチガイじみた様相で攻撃してくる奴は、お前しかいないって。 　悔い改めよ。そしてお前が迷惑をかけた人、一人一人に許しを乞え。 383 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:00:02 ] 荒しはスルーするとして。 >>380 その概念マッピングは、>>375-376 と多少ズレている。 マスタメンテ型システムってのは、 システム開発の都合で業務処理を極端なまでに単純化して、 　　　　業務処理アプリ＝DBテーブル編集アプリ と見なすもんだ。 すると主要ドメインはあくまで業務処理プロセスであって、 マスタ更新プロセスではない。 384 名前：デフォルトの名無しさん [2007/03/31(土) 17:08:41 ] >>379 たかひろ、お前が壊れているのは最初から知っている。 お前が壊れた設計をしていたのにも、１週間と待たずに気付いた。 当然の事ながら、問題の解決策もすぐに判った。 ただ、お前がお前自身の精神状態の異常さに気がつかずに、 多くの人々に多大な迷惑をかけ続けた経緯には、 さすがの俺も心が痛んだ。 だから、あえてお前の古傷を持ち出し、 お前の行動を是正しようとしているんだ。 謙虚になれ、たかひろ。 お前はお前が思っているのの１/１００も有能ではない。 単なる空っぽの本棚だ。お前の頭は 385 名前：375 mailto:sage [2007/03/31(土) 17:16:39 ] >>375の分析モデルがズレたので、再投稿 ------------------------------------------------------------ 　　　【版材の分析モデル】 　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版 　　　　　　　　　　　　 │　　　　　　　　　　　 │　　　 └ 硬い木版 　　　　　　　　　　　　 │　　　　　　　　　　　 ├ ゴム版 　　　　　　　　　　　　 │　　　　　　　　　　　 ├ 芋版 　　　　　　　　　　　　 │　　　　　　　　　　　 └ 銅版 　　　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai 　　　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai 　　　　　　　　　　　　 └ 完成した版画版 ------------------------------------------------------------ 386 名前：375 mailto:sage [2007/03/31(土) 17:17:57 ] あれ？まだずれてる。 >>375の分析モデル図差し替え ------------------------------------------------------------ 　　　【版材の分析モデル】 　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版 　　　　　　　　　　　　 │　　　　　　　　　　　 │　　　　　　└ 硬い木版 　　　　　　　　　　　　 │　　　　　　　　　　　 ├ ゴム版 　　　　　　　　　　　　 │　　　　　　　　　　　 ├ 芋版 　　　　　　　　　　　　 │　　　　　　　　　　　 └ 銅版 　　　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai 　　　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai 　　　　　　　　　　　　 └ 完成した版画版 ------------------------------------------------------------ 387 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:53:08 ] >>383 「マスタメンテ型アプリ」設計が導入されたのは、 今回ではなく、何世代も前の電算機導入の頃の話だろう。 それ以来業務処理は「マスタメンテ型アプリ」に合わせて変形し成長した。 だから今さら「マスタメンテ型アプリ」抜きの業務処理プロセスなど 存在しない。 　　業務処理プロセス(の一部)　∝ マスタメンテ型アプリのプロセス としても大きな咀嚼はないだろう。 もし、新システム提案の初期に業務分析の専門家が入り、 提案を新しい業務プロセス設計の形で詳細に残していたら・・・ そこから正確なドメイン・モデルを作成できるのかもしれない。 だが今時の新システム構築なんて、大抵中身はマイグレーション。 COBOLプログラマがプログラムの動きを日本語で説明して「設計書でござい」 なんて言い出すおバカな世界だからなぁ・・・ 388 名前：デフォルトの名無しさん [2007/03/31(土) 17:54:57 ] >>365 さて、そろそろORマッピングスレを爆撃に行くかｗ 389 名前：369 [2007/03/31(土) 19:59:13 ] バカの相手をするのはつもりは一切ないが、 バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので 簡単に>>371 の間違いを指摘をしておく。 なおここで>>371とは、元レス>>369に対するバカの妄想であり、 ここでは引用符> を先頭に付けて示してある。 Ａ．> >>365が僕の考えからは少し極端な意見だがいいこと言った。 　　ＯＲマッピングの話は、>>275の前提条件のスコープ外。 　　議論に直接関係ない話を持ち込んで、議論を撹乱するのは 　　詐欺師の常套手段なので、みなさん気を付けるように。 　　また、もしＯＲマッピングに興味を持った人が居たら、 　　まずはデータベース板の該当スレを参照すると良い。 Ｂ．> ＞　>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1) 　　> なりません。 　　これは自分で補足コードを書いて見れば簡単に確認できる。 　　結果は>>304 のようなコードになるはずだ。 　　 (但し>>364に説明してあるように、等価コード部 //{〜}// 内は >>364※1と読み替える) 　　確認作業はコーディング能力のある人にしか実行できないが、 　　それは致し方ない所だろう。 390 名前：369 (>>389つづき) [2007/03/31(土) 19:59:56 ] バカの相手をするのはつもりは一切ないが、 バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので 簡単に>>371 の間違いを指摘をしておく。 なおここで>>371とは、元レス>>369に対するバカの妄想であり、 ここでは引用符> を先頭に付けて示してある。 Ｃ．> ＞　このコード(>>293, >>304)は､その字面の単純さにもかかわらず､ 　　> ＞　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い) 　　> カプセル化を否定しているように聞こえるが？ 　　はい、みなさん注目！！！ 　　これが典型的な詐欺師の手口です。騙されないように。 　　元レス>>369は >>293-294のカプセル化破綻問題を指摘している。 　　自分の問題点を指摘された >>293は、逆上して事実と反対の事を言い出している。 １．システムの全体像が見えていない以上、 　　処理の動作主体をモデル化しておく必要がある。 　　ここで動作主体とは、「鈴木君」や「田中君」である。 ２．動作主体が「鈴木君」や「田中君」であり、 　　プロセスは >>293の最初のクラス＝WoodCutPrintProcessクラスである。 391 名前：369 (>>389つづき) [2007/03/31(土) 20:05:01 ] バカの相手をするのはつもりは一切ないが、 バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので 簡単に>>371 の間違いを指摘をしておく。 なおここで>>371とは、元レス>>369に対するバカの妄想であり、 ここでは引用符> を先頭に付けて示してある。 １．> このケースの主処理は木版が作成プロセスである。 　　このケースでは、システムの全体像が見えていない以上、 　　処理の動作主体をモデル化しておく必要がある。 　　ここで動作主体とは、「鈴木君」や「田中君」である。 ２．> 鈴木君や田中君は木版画作成プロセスのバリエーションである。 　　前述のように、動作主体が「鈴木君」や「田中君」であり、 　　プロセスは >>293の最初のクラス＝WoodCutPrintContextクラスである。 　　(なおこのクラスの名称 "WoodCutPrintContext"は、内容を適切に表していない。 　　 正しくは、"WoodCutPrintProcess"と命名するべきである。根拠は>>297 参照) 392 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:06:02 ] たかひろがバカなのは判ったから とにかく sageを覚えろ 393 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:18:05 ] あらあら、よく見たらアイツ またまた敗走宣言してるやん >>379 ﾜﾛｽ 394 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:19:51 ] >>380 GJ！ 「版画作成プロセス」と「マスタメンテ・プロセス」は所詮は別物、 もともと厳密に１対１に対応するものではない。 そこで>>380の齟齬の悪そうな部分を若干修正してみた。 大きな変更点は｢版画作成プロセス｣でなく｢版画版作成プロセス｣とした点。 ---------------------------------------------------------------------- ｢版画の世界｣から、｢デスマ・システム｣への概念マッピング part2 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　　　　　　　 　【版画版作成アプリ】　　　　　　【マスタメンテ型基幹システム】 [主要ドメイン]　　版画版作成プロセス　　　　　　　マスタメンテ・プロセス [主要データ]　　　版材原料　　　　　　　　　　　　入力 (画面入力データ) 　　　　　　　　　下絵　　　　　　　　　　　　　　ＤＢ参照データ 　　　　　　　　　加工中の版画版 　 　　　　　　　　　完成状態の版画版　　　　　　　　出力 (ＤＢ更新データ) 　　　　　　　　　刷り上がった版画　　　　　　　　表示 (画面表示データ) [主要プロセス]　　版材原料取得　　　　　　　　　　入力取得 　　　　　　　　　版材作成　　　　　　　　　　　　入力チェック 　　　　　　　　　下絵取得＆下絵処理　　　　　　　業務チェック, ＤＢ参照 　　　　　　　　　切除処理　　　　　　　　　　　　演算処理, ＤＢ更新 　　　　　　　　　印刷処理　　　　　　　　　　　　画面表示 ---------------------------------------------------------------------- 修正結果を見ると、両者の対応関係はそんなには悪くない。 むしろ、別物にしてはずいぶん良い対応関係を持っている、と言える。 395 名前：394 AAズレ修正 mailto:sage [2007/03/31(土) 20:35:49 ] ---------------------------------------------------------------------- ｢版画の世界｣から、｢デスマ・システム｣への概念マッピング ver.2 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　　　　　　　 　【版画版作成アプリ】　　　　　　　【マスタメンテ型基幹システム】 [主要ドメイン] 版画版作成プロセス　　　　　　 マスタメンテ・プロセス [主要データ]　 版材原料　　　　　　　　　　　　　入力 (画面入力データ) 　　　　　　　　　下絵　　　　　　　　　　　　　　　　ＤＢ参照データ 　　　　　　　　　加工中の版画版 　 　　　　　　　　　完成状態の版画版　　　　　　　出力 (ＤＢ更新データ) 　　　　　　　　　刷り上がった版画　　　　　　　　表示 (画面表示データ) [主要プロセス]版材原料取得　　　　　　　　　　入力取得 　　　　　　　　　版材作成　　　　　　　　　　　　　入力チェック 　　　　　　　　　下絵取得＆下絵処理　　　　　　業務チェック, ＤＢ参照 　　　　　　　　　切除処理　　　　　　　　　　　　　演算処理, ＤＢ更新 　　　　　　　　　印刷処理　　　　　　　　　　　　　画面表示 ---------------------------------------------------------------------- 396 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 02:18:44 ] ある意味すごいなｗ 未だにコードが出てこないし解釈間違ってるけど、このエネルギーはスゴイ。 便所の１００ｗと比喩してはいけないｗ 397 名前：396 mailto:sage [2007/04/01(日) 05:00:48 ] スマソ　誤爆した 398 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 07:01:05 ] まあまあ 元々の質問はもうとっくにクローズしてるし、 >>293はjavaとよく似た擬似コードで記述されたクラス設計に過ぎんから、 代替コードを示す必要もない。 現在議論されているのは、>>293の背景にある設計理念の問題、 そして、それに類する設計を現実に適用した時のギャップね解決方法だろ。 理解できないなら結論が出るまで静観するがよろし 399 名前：デフォルトの名無しさん [2007/04/01(日) 08:41:27 ] このスレ、爆発力はあるな 問題は火のつけ方 400 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 09:44:28 ] >>397 ﾅﾆｺﾚｗｗ 勝手に誤爆にするなよｗｗｗ >>397-398 おまいウザイから別にスレ立て手やれよ 401 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 09:52:28 ] あとそんなに自分の主張に自信があるなら コテつけてレスしろ 402 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 10:38:41 ] >>400-401 またスレ荒しか 403 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 10:40:13 ] おまぃはバカなんだから黙っとけ 404 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:38:31 ] いやさ、例の「精神性疾患の俗称連呼」の人、 別スレで暴れまくっててえらい騒ぎになってるわ。 どうも東京都在住の４４歳の人物らしい。 ４４歳にもなって２ちゃん三昧とは幼いね。 405 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:50:51 ] リアルワールドが悲惨なんだよ、きっと 406 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 17:02:21 ] よしよし 407 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:05:17 ] NGワード推奨：キチガイ 408 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 19:09:37 ] 某スレで、コーディング能力も設計能力も疑わしい４４歳の人が 「擬似コードを元にした議論はよくねぇ〜」とか叫んでて笑えた。 「print文入れて動作を見ればいい」ってそれなんて名前のBASIC言語？ｗ 409 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 20:54:04 ] なんと言う春休み。 思わず読み飛ばしてしまった。 このスレはしばらく伸びる。 410 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 21:05:50 ] >>409 荒しに来たのなら、帰ってくれ。 411 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 02:42:25 ] こっちが平和になったと思ったら 今度はあっちで暴れてたんだな pc11.2ch.net/test/read.cgi/tech/1172431242/ 412 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 14:16:56 ] >>407 自分がそれだから、そうやって相手を封じたい訳ね。 ま、相手なんてお前の脳内にしか居ないんだけど（藁 413 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 14:25:05 ] 誤爆？ 414 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 14:50:04 ] >>412 おまえが自己の行動に無自覚な精神障害者である事はよくわかった。 415 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 14:56:12 ] ここのスレ主はそろそろ鉄格子付き個室病棟の中か。 頭も性格も悪いスレ主に意見すると ひたすら泥沼に引きずり込もうとあがくから 始末が悪い。 416 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 15:56:32 ] スレ主は、ＯＯやデザパタに対して、狂信的な宗教感情を持っている。 その信仰はあまりにも愚かで盲目的であり、 自身の独自解釈とは異なる意見を持つ者に対して 狂信的信者の狂ったな正義感を持って攻撃と排除を試みる。 しかし、世の中に広く受け入れられる技術ノウハウというものは、 そのようなカルト的宗教活動とは一切無縁のものである。 417 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 16:08:13 ] 個人的な技術ノウハウの蓄積は、 　・日々の実践と経験を通じた、メンタルモデルの形成 　・合理的思考による、メンタルモデルの検討と洗練 　・明確な目的意識に基づく、合目的なノウハウの抽出と洗練 を通じて行われる。 そして世の中に広く受け入れられる技術ノウハウというものは、 個々人のノウハウを、他の専門家を交えた健全な議論に晒し、 目的と手段の合理性を詳細に検討し、 その過程で多くの人々が同意し共感する事を通じて、 初めて成立するものである。 418 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 16:28:04 ] 注： 誤解のないように注記しておく。 ここでスレ主とは、今回のスレを立てた人物の事ではなく 関連スレのど真ん中に居座り、罵詈雑言を撒き散らしては議論妨害を繰り返す、 牢名主のような人物の事である。 419 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 19:28:31 ] GoFってなんて呼べばいいの？ 個人的にはゴフって読んでるんだけど、公の場で使ったら笑われたりする？ 420 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 19:37:48 ] >>419 情報処理用語の読み方を確認するスレ pc8.2ch.net/test/read.cgi/tech/1056173956/670 　670 ：デフォルトの名無しさん ：2005/05/16(月) 20:02:16 　　GOFはともかくGoFはゴフと読んでる。 421 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 20:33:32 ] ｺﾞﾌｺﾞﾌ 422 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 22:39:06 ] 護符としての効能はあるんだろうか？ 423 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:00:50 ] 　　　　　　__ 　 　 i＜´ 　 }＼ 　 ,　- 、 　　　ヽ.._＼./　 .ﾝく　r-兮、 ＿_ 　　　 ∠｀ヽ.!　/ 　 ヾﾆEｦぐ　,ゝ-＞ 　　　　さすがGoFだ。 　　　/＿｀ｼ'Ｋ-───‐-､l∠ イ 　　　 　 ﾃﾞｽﾏくらっても 　　　l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤ 　　　　　何ともないぜ。 .　 　 l'___|⌒ヾ''ｰ＝=､ｰr='ｲ　ｉ二| 　　　　　 　　　/　.｣　　 i　　 /./7r‐く　 lー! .　　 ｆ.　　ヽ‐ｉ人.∠'＜ 　 ＿i. l,.-ゝ. 　 　 ﾄiﾍﾍ｢ﾄ〈　　　 　 ｀X　　ﾄﾚi7__| 　　　〉ﾄ:ﾄﾊj｀! i.　　　 /　 ﾄｰ┤lﾙj,ﾘ 　　/‐+----+‐l　 　 iｰ--i---ヾ'〃 .　 ｌ＿i＿＿__i__|　　 |＿__i,＿＿i_| 424 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:57:18 ] 荒らしは帰ってくれ 425 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 20:59:35 ] あっちの隔離スレ、すげぇ荒れようだな。 こっちであんまﾍﾀﾚな擬似コード出してくるから ちょっとからかってやったらすぐキレ出して、 改めて問題点を７レス分ほど指摘しただけで 延々と一週間もこの騒ぎだ。 狂信者って本当に怖いね。 426 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 00:52:40 ] ｲﾀｲ････ 427 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 00:56:10 ] pc11.2ch.net/test/read.cgi/tech/1175959706/ 428 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 09:39:44 ] State パターンで相談です。各 State クラス間でコンテキストを共有したい 場合に、相互の依存度を下げるにはどういったイディオムが使えますか? 例えば、ウィザード形式のインストーラの画面を State と見なすと、 A 画面で設定した内容を次の B 画面でも使いたいとか、最終的には、 全ての画面で設定した内容をもとに処理を行いたい、など。 Context を各 State のコンストラクタに渡してあげれば目的は達成できる のですが、各 State が興味があるのは Context の限られた一部分であり、 Context 全体を渡すのは不釣り合いな気がしています。 もう一つの悩みは、Context が受動的な「共有データクラス」の役割を 演じることになるというものです。どうもこの構造がしっくりこない というか、オブジェクト指向っぽくないと思うのです。 あるいは、こういう場合にはそもそも State パターンは使わないとか、 そういった指摘でもかまいませんので、よろしくお願いします。 429 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 09:47:55 ] その前にStateパターンのクラスズをよく見て依存関係を シッカリ把握しなさい 430 名前：428 mailto:sage [2007/04/21(土) 10:02:23 ] >>429 問題にしているのは以下のような依存関係です。 Controller has a State Controller has a Context StateA is a State StateB is a State 431 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:13:33 ] >>430 私が問題にしているのは ＞各 State が興味があるのは Context の限られた一部分であり です。 StateはContextに興味はありません。 432 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:26:13 ] ハッタリ業務コンサルのデザインパターン解釈はダメダメだな 433 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:42:32 ] まー独自解釈して苦しんでしまう事は初心者にはよくあることだから気にする必要は無いｗ 434 名前：428 mailto:sage [2007/04/21(土) 10:44:02 ] >>431 Context という言葉を使ったのがまずかったですね。ごめんなさい。 GoF では Context が State に処理を移譲することになっていたかと 思いますが、ここでは「共有データ」の意味で Context を使ってます。 つまり、Controller が State に処理を移譲していて、各 State は Context を参照・更新するという構造です。 State が Controller に無関心だと言う点についてはもちろん同意です。 今回の悩みどころは、各 State の「成果物」を共有する時のうまい手段は ないものか、というものです。 GoF に従うなら、 Context has a State Context has a SharedData StateA is a State StateB is a State で、StateA や StateB が SharedData を参照更新する、という感じです。 435 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:48:50 ] ContextがMediatorになるんじゃないの? 436 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 10:52:17 ] WebApplicationやStrutsと同じジャマイカ 437 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:07:11 ] 扱うデータの型や処理の型を問題にせずSharedDataでひとくくりにするから 概要設計レベルではContextで解決したつもりになっていても 詳細設計レベルで一気に破綻するんだろ。 ハッタリコンサル(初心者)の典型だな 438 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:12:12 ] >>435 Mediatorで相互依存性を弱めるというのは正しい方向だが それをContextと呼び続けるのは病気だ。 今ならDIだろ。 439 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:15:19 ] いまどき概要設計/詳細設計かよ 440 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:17:17 ] ハッタリコンサルはメーカ毎の工程名の相違に鈍感 OMGの工程名対応表でも見とけクズ 441 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:22:56 ] いまどき工程かよｗ 442 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:27:07 ] ハッタリが話題ずらしに必死だな 上空レベル、海面レベルとでも読み替えておけクズ 443 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:28:25 ] >>435 > ContextがMediatorになるんじゃないの? ContextではなくMediatorだろうな、 古臭いデザパタ厨房の妄想に合わせてやれば 444 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:29:48 ] >>442 そりゃユースケースの話だろｗバーカｗ 445 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:31:11 ] ハッタリ必死すぎるぞ カプサイシン摂取過多でそろそろ拳銃乱射事件かｗ 446 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:33:12 ] ハッタリコンサルの仕事： 奴隷コーダに一画面分のコードを書かせ、 それが複数画面で使いまわせると信じ込んで 詳細設計の雛形にする 447 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:35:53 ] ハッタリコンサルの仕事２：概要設計 一画面分のコードで、データ類がContextにまとめられているのを見て、 Contextというクラスを作れば複数画面にも対応できるとはずだ という妄想設計をすること。 448 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:37:09 ] >>446 お、宗旨替えか？ そうだよSE/コンサルはコーダ以下なんだよｗやっと気づいたか 449 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:44:03 ] >>448 はぁ？ お前がダメ人間だからといって、 他もダメ扱いすんな。 中小企業のダメコンサルに比べたら 大企業のSEには中にはまともなのが居るよ。 例えば俺。 コーディングもできるし(あたりまえ)、 科学技術にも口出しできるし、 ダメコンサルを叩いて再起不能にする事もできる。 お前を今叩いているようにな 450 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:45:54 ] ここで叩かれてボロボロになってるハッタリコンサルって、誰なの？ 451 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:50:20 ] ＞コーディングもできるし(あたりまえ) コンプまるだしｗ 452 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:53:19 ] ＞例えば俺。 日中カキコしまくりのヒキコモリが大企業のSE？ｗ 453 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:54:03 ] >>450 各種情報を総合すると、こいつが本人らしい。 megalodon.jp/?url=http://pc11.2ch.net/test/read.cgi/tech/1172431242/626&date=20070410182152 454 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 11:56:16 ] >>453 みっともねぇ〜ないい歳こいた親父が ２ちゃんごときで必死になっちゃってｗ 仕事場でオナニー三昧２ちゃん三昧って それなんていう引き篭もり部屋？ 455 名前：428 mailto:sage [2007/04/21(土) 12:00:16 ] うーん。Mediator だとクラスの数が増えてしまうので、ちょっとおおげさ かなという気がします。コストとメリットがバランスしないというか。 問題をうまく処理できることはもちろん大切なんですが、「やり過ぎ」も 避けたいなと。 データ共有型 State パターンは割とありがちなことかと思ったのですが、 検索してもあんまりピンとくるものがないんですよね。まあ、探し方が 悪い気もしますが、どちらかと言うと状態遷移の問題に着目したものが 多かった気がします。 C++ だし参照渡しでお茶を濁そうかなと思ったり。 456 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 12:06:18 ] >>454 おめえは気の利いたこといってるつもりなんだと思うけど、 とにかくセンスが無さすぎる 457 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 12:06:31 ] 妄想に基づく独自解釈をGoogleで探しても、適切な例が出てくるわけない。 StateパターンにおけるContextクラスの役割は約一ヶ月前に書いた通り。 お前の負けだ。観念しろ 458 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 12:08:07 ] >>456 キチガイのセンスに合わせるのは難しいな 四流大学出はそういう会話が得意なんだろうけど。 459 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:21:07 ] >>446 手足として使った奴隷コーダに強烈な恨みを買っているのが ハッタリコンサルのダメダメな所。 「勝手に引き抜いて、変な仕事ばかり回してきて 　あのバカは一体何様のつもりだ？」 って泣いてたぜ、奴隷コーダちゃん 460 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:24:16 ] >>459 そうそうｗ そういえばあのコーダも使えなかったよなｗ Javaのクラスはオブジェクトじゃない！とかわけのわからないこといってたしｗ 461 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:25:40 ] >>460 そういえばあいつ、頭おかしくなって会社やめちゃったってなｗ ヒキって２ｃｈばっかやってるらしい。 版画とかよばれてるしｗ 462 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:33:03 ] >>461 ああ、あのゴミか ほんと死ねばいいのにな 463 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:34:23 ] >>462 同意ｗ おれがあいつならとっくに吊ってるｗ 464 名前：デフォルトの名無しさん [2007/04/21(土) 13:34:37 ] >>460 バカが発振し始めたな デブのことだよハッタリ高弘ちゃん 465 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:36:25 ] >>464 版画ﾊｹｰﾝ（版画風ｒｙ うわきもｗ 466 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:36:31 ] 早速スレに晒しときましたｗ 467 名前：デフォルトの名無しさん [2007/04/21(土) 13:39:24 ] おいおまいら、アドレナリンは俺専用のオモチャだ 勝手にアドレナリンをいじるな 暇つぶしに適当な書き込みをするとすぐ怒り出すのでとても面白い 468 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:42:11 ] >>467 強がりいってらｗあったまわりいｗ 469 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:42:51 ] >>467 カプサイシンの間違いじゃねぇの 半島人臭いし 470 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:43:53 ] ﾑｯｷｰ、ﾌｧﾋﾞｮｰﾝ(笑 471 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:45:29 ] おいハッタリをあんま構うな あまり追い詰めると 出身校(四流大)で拳銃乱射事件起こすぞきっと 472 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:46:34 ] >>469 そうそうｗ 版画もちょっと煽るとすぐファビョるしなｗ 半島に帰れよｗ 473 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:47:38 ] ハッタリ高弘の好物 キムチ餃子 474 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:48:59 ] さぁーってと 昼休みのハッタリいじめはそろそろ飽きたし 四月の休日を満喫してくるか（←満喫に行くって意味じゃないよｗ 475 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:52:03 ] 版画版画ってバカにすんな！！ Javaのクラスなんかオブジェクトのわけないだろ！ たしかにハッタリたかひろも俺も鮮人だが、それがどうした！ 低脳どもが！ 476 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:53:51 ] ハッタリの成りすましはクオリティが低くて萎える 477 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:54:42 ] GoF本って独習C++を一通りやった程度の知識で理解できますか？ 478 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:54:51 ] メモ：ハッタリは半島人 479 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 13:56:31 ] >>478 半島人には関わらない方がよい。 480 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 21:03:15 ] >>477 基本的に経験則のまとめ本だから、必要な状況にならないと理解しにくいのが多い。 まあ理解出来る出来ないに関わらず一冊持っとくのは良いと思うよ。 481 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 21:15:36 ] こういうのには盛り上がるんだなｗ 482 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 21:18:22 ] ほら、宗教の人だから自作自演で信者獲得したフリしないと気が済まないんだろ 483 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 11:52:06 ] GoF本を今時会社の机にこれ見よがしに置いてあるの見ると笑える 484 名前：デフォルトの名無しさん mailto:sage [2007/04/27(金) 14:49:27 ] キチガイって飽きないの？ 485 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:50:15 ] >>484 自問自答は黙って答出せ 486 名前：デフォルトの名無しさん mailto:sage [2007/05/18(金) 15:28:15 ] ここのObserverﾊﾟﾀｰﾝはわかりやすかった。 ttp://goodjob.boy.jp/chirashinoura/id/135.html 487 名前：デフォルトの名無しさん mailto:sage [2007/06/18(月) 21:21:41 ] アーキテクチャパターンの質問で悪いんだけど、 MVCパターンにおいて、 ｢押されたボタンに応じて新しいサブWindowをオープンする作業｣のような、 Window遷移を管理する人(実現する人)って誰になるの? Model? View? Window遷移もアプリケーションの中核処理になるから、 Modelの責務の範囲内なのかなとも思うんだけど、、実際どうなの? 488 名前：デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:59:02 ] どーでもねーよ 489 名前：デフォルトの名無しさん mailto:sage [2007/07/09(月) 11:31:18 ] >>487 画面の制御なんてモロにViewだと思うんだけど。 490 名前：デフォルトの名無しさん mailto:sage [2007/07/09(月) 22:41:24 ] ＵＩモデルだな 491 名前：3年前 mailto:sage [2007/07/11(水) 11:24:49 ] Domain-Driven Design pc11.2ch.net/test/read.cgi/prog/1080149913/ 1 名前： 仕様書無しさん 投稿日： 04/03/25 02:38 　ドメイン駆動型デザインとは何か？ 　Download draft of book from 　www.domaindrivendesign.org/book/DDD_2003-04-15.pdf 　www.domaindrivendesign.org/ 492 名前：そして現在 mailto:sage [2007/07/11(水) 11:26:36 ] Domain-Driven Designのエッセンス 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。 しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関す る解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無か ったと言ってもいいでしょう。 Eric Evansの『Domain-Driven Design』（以降DDD）は、「ソフト ウェアの真の複雑さに挑戦する」という副題からも分かるように、ドメインモデリングに正面 から取り組んだ待望の書籍です。 DDDは、海外では非常に評判の高い書籍です。本書の出版前からMartin Fowler氏により 「期待できる内容だ」と推薦されていたり、GoFの1人であるRalph Johnson氏は自身のブロ グで本書を「4、5回は読み直した」と賛辞を送っています。Spring Frameworkの開発者Rod Johnson氏も、最近のプレゼンテーションでDDDを紹介しながら、「Java EE開発者がこれ から進むべき道はリッチなドメインモデルだ」と発表しています。また、MDAツールSculptor のように、DDDを積極的に採用したツールやフレームワークも登場しつつあります。 しかし、日本では翻訳書がいまだに出版されていないこともあり、本書の出版から3年近く 経った今でも、まだまだ一部の通の人たちにしか広まっていないように筆者には思われます。 また、原書を読まれた方の中からも「本が分厚すぎて読みきれない・・・」という嘆きの声も 聞かれます（DDD難民という言葉もあるそうです）。 そこで本連載では、全3回に分けて、DDDの全貌を簡潔に紹介してみたいと思います。 DDDはタイトルからは一見分かりにくいのですが、いわゆるパターン本の1つです。 しかし、DDDは全体が読み物の体裁で編まれているため、パターンカタログが読み物から 独立しているもの（『デザインパターン』『J2EEパターン』『エンタープライズアプリケーション アーキテクチャパターン』など）に比べ、パターンの閲覧性は良くありません。本連載では、 すでに一度読破された方にも有用な資料となるように、パターンカタログとしてDDDを再構成 してみます。 493 名前：デフォルトの名無しさん mailto:sage [2007/07/11(水) 19:11:44 ] へー 494 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 17:41:42 ] ここって何も知らん人でも書いていいんだろうか・・・ 一つのパターンを適用、っつーか使うっていうのなら何とかできるんだけど、複数のパターンを組み合わせるとなるといきなり手が止まる・・・ デザインパターンはいいコードを書いていれば自然に適用されている物、っていうことなの・・・？ 495 名前：デフォルトの名無しさん mailto:sage [2007/10/08(月) 18:57:21 ] 一つ使うも複数使うも難易度に差はないだろ 理解しないでサンプルコード改変してるレベルと見える 496 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 23:46:07 ] デザインパターンって、「組み合わせて」使うような例ってほとんどないんじゃないかな。 一つのモジュールの別々の箇所で複数のデザインパターンを併用することはよくあるけどねー。 Java のクラスライブラリがいい例。 497 名前：デフォルトの名無しさん [2007/10/31(水) 00:50:37 ] 難しいことはいいからデザパタって ホントに役に立つのかどうか教えろよ 498 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:51:49 ] >>497 OOPを一から自分で設計するのは骨が折れるぞ バグも紛れ込むし 499 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:55:39 ] お前に使いこなせねえよバーカ 500 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 00:55:43 ] >>497 仕事なら役に立つよ 一単語だけで意図が伝わる 501 名前：デフォルトの名無しさん [2007/10/31(水) 00:58:01 ] >>499 うるせーハナクソ 502 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 01:16:18 ] >>497 自分のそれまでの経験とセンスだけで、 後々のメンテとかになるべく困らないような 設計するのは難しいから、頭のいい先人たちが 編み出した有用なパターンを知っておいた方が楽。 ていうか知らないとかなり大変。 503 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 01:23:01 ] >>498 かなりできる人間が過半数超えてれば使えるし、 超えて無いとロスの方がでかい。 504 名前：デフォルトの名無しさん mailto:sage [2007/11/08(木) 11:28:46 ] C++でのcrtpとか言語毎に形成されたイディオム的なパターンは実用性も高いし、初心者にも分かりやすいと思う 結局言語の所まで落とさないと使えないしね というかC++だとそういうidiom使わないとたちどころに言語になるし GoFで紹介されてる各パターンは役に立たないけど そこで使われる考え方っていうのは言語ローカルなイディオムを理解するのに役立つかなぁと思ったけど、 もう少し勉強が進んだらまた違う感想になる気がする 505 名前：デフォルトの名無しさん [2007/11/14(水) 02:08:15 ] デザインパターンを使わずにスマートに書く方法とかって どんな感じなんになるんでしょうね？ たとえば、うどんをそばを作る場合なんかはほとんど 工程は一緒なのでテンプレートメソッドに使うんだろうけど みなさんならどうやって書きますか？ ふと考えるといろいろあるけどどれもいまいちな気が。 1どんぶり用意 2うどんかそばを入れる 3だしをそそぐ 506 名前：デフォルトの名無しさん mailto:sage [2007/11/14(水) 03:04:16 ] GoFが役に立たないとか、デザインパターンを使わずにスマートに書くとか・・・学生さんかね？ 507 名前：デフォルトの名無しさん [2007/11/14(水) 08:14:51 ] >>506 なんだか継承になれすぎて使わないパターンがあまりおもいつかなかったもので使わなかったらどうだろうかと思ったんですけど。 508 名前：デフォルトの名無しさん mailto:sage [2007/11/14(水) 12:22:47 ] >>505 昔は仕様書を元に上から下へ逐次式に書いたものだよ。 仕様書がすべて、はじめに機能をすべて洗い出せることこそ能力。 これに慣れたままSEになり３０代を迎えると、もう補正が効かない。 あと、現場でやっている人は、GOFどうこうを意識している人はあまりいないとおもう。 509 名前：デフォルトの名無しさん [2007/11/15(木) 02:57:13 ] >>508 >これに慣れたままSEになり３０代を迎えると、もう補正が効かない。 そういう人を一般的に才能がないという。 勉強する意欲がない人はいくら若くてもダメ。 転職するならお早めに。 510 名前：デフォルトの名無しさん [2007/11/15(木) 03:47:08 ] >>508 ちょっと前にやったプロジェクトで、GOFに死ぬほど拘ってる プロジェクトリーダーが居て困ったことがあるな。 最近、GOFを勉強したらしく、なんか頭がすごく良くなったカン違い してるみたいで、設計がGOFのどれかのパターンになってないと、 全部NGにされて、直すのに苦労したよ・・・ 511 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 03:50:05 ] >>508 GoFすら意識してなくて機能をイメージできるものか？出来てるつもりじゃないか？ 512 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 09:22:08 ] 設計なんて茨の道さ。 もんどりうってじたばたして、 痛い思いしながらGoFにしがみついたり、 手放したり、またGoF読み直したり、 もんどりうったり、じたばたしたり、 GoF読み直してピンときてみたり、 こなかったり、もんどりうって、ピンときたり。 513 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 13:56:27 ] 全ての設計要素は何らかの秩序の上に存在すべき だが設計要素や立脚する秩序をすべて表現する必要はないってこった 達人の書いたオプソのコード読んでも、凄さが伝わりくい理由がそこにある気がする 514 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 14:39:57 ] >>512 オッパイ揉んでピンときたり が抜けてね？ 515 名前：デフォルトの名無しさん mailto:sage [2007/12/28(金) 16:51:17 ] ソースコードの見た目がかっこ良くなるので使ってます 516 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 21:48:54 ] 開発環境のバージョンによって、含まれるライブラリが違うため、 どちらのバージョンでも動くように、実装を切り替えるということがしたいのです。 XMLのラッパーライブラリのエンジンの実装を切り替える、というようなことです。 Strategyパターンを使うのがよいのでしょうか？ 最初は、Decoratorパターンと区別がつかなかったのですが、 GOF本のDecoratorのところにあるように、 ・中身を取り換えるのが、Strategyで、 ・外側を取り換えるのが、Decorator ということで、 中のエンジンを取り換えるのは、Strategyパターンということでしょうか？ 517 名前：デフォルトの名無しさん mailto:sage [2008/01/07(月) 22:43:21 ] >516 あんまりパターンの名前にとらわれずにしたほうがいいと思われ。 518 名前：デフォルトの名無しさん mailto:sage [2008/01/08(火) 00:19:40 ] うむ。 とりあえず作りたいように作って、似たパターンがあったらそれに合わせていく方向で。 519 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 03:33:32 ] >>517-518 ありがとう 過去レスででてたけど、作ってみてリファクタリングの時に考える方法やってみる 520 名前：デフォルトの名無しさん mailto:sage [2008/02/06(水) 20:05:11 ] // Hoge.h #ifndef HOGE_H #define HOGE_H class Hoge { public: static Hoge* New(); virtual void Foo() = 0; virtual ~Hoge() { } }; #endif // Hoge.cpp #include "Hoge.h" #include <iostream> class Hoge_ : public Hoge { public: virtual void Foo() { std::cout << "Hoge::Foo" << std::endl; } }; Hoge* Hoge::New() { return new Hoge_(); } // main.cpp #include "Hoge.h" #include <boost/scoped_ptr.hpp> int main() { boost::scoped_ptr<Hoge> hoge(Hoge::New()); hoge->Foo(); } こうやって実装を pimpl より隠蔽してるソースを見たんだけど、 このデザパタの名前って何？ 521 名前：デフォルトの名無しさん mailto:sage [2008/02/06(水) 23:46:55 ] これっしょ？よく見る普通のインターフェイスじゃないか。 boost.cppll.jp/HEAD/libs/smart_ptr/sp_techniques.html#abstract 522 名前：デフォルトの名無しさん mailto:sage [2008/02/07(木) 00:21:09 ] 「〜パターン」 とかの名前がついてるわけではないのね。 523 名前：デフォルトの名無しさん mailto:sage [2008/02/07(木) 03:10:32 ] strategyじゃね 524 名前：デフォルトの名無しさん mailto:sage [2008/02/07(木) 07:40:40 ] 派生クラスを１つしか作らないこと前提で目的も違うから strategy じゃないな。 525 名前：デフォルトの名無しさん mailto:age [2008/02/14(木) 22:04:23 ] 質問させてください Compositeパターンで作られたクラスに インターフェースの拡張を施した新しいクラスを作りたいときは Bridgeパターンを使いますか？ 526 名前：デフォルトの名無しさん mailto:sage [2008/02/15(金) 20:35:57 ] 自己解決しました 527 名前：デフォルトの名無しさん mailto:sage [2008/02/16(土) 03:47:22 ] 自己解決したらできれば、解決法を書いていきましょう 後で見た人の参考になりますよ 528 名前：デフォルトの名無しさん [2008/02/27(水) 09:21:02 ] フラグを１ビットではなくカウンターで持っておき、ＯＮ扱いを１より大きい 値（仮にＡ）とします。ＯＮしたい状況ではいきなりＡを代入するのではなく １ずつ足していき、ＯＦＦしたい状況ではすぐにゼロを代入します。 こういう、ＯＮにするときだけショックアブソーバー付きな動作をする フラグはデザパタではどういう名前が付けられてますか？ 529 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 13:24:07 ] 自家発電しました 530 名前：デフォルトの名無しさん mailto:sage [2008/02/27(水) 19:14:49 ] >>525-526 自己解決パターン 531 名前：デフォルトの名無しさん mailto:sage [2008/02/28(木) 01:50:40 ] アンチパターンだな 532 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 18:10:25 ] 最近デザインパターンを勉強しだしたんですが GoFの23個のうち2〜3個組み合わせて何か簡単なものを作るとしたら どんなものが思い浮かびますか？ 533 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 18:27:07 ] STL 534 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 18:29:26 ] Template Method との組み合わせは結構考えられるかと。 535 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:56:35 ] コマンドパターンとなんかで、 GUIツールのアンドゥの練習 536 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 22:56:57 ] やっぱり、アンドゥ、リドゥの練習にしといて 537 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 23:13:23 ] Memento パターンと Command パターンの複合か。 538 名前：デフォルトの名無しさん mailto:sage [2008/03/03(月) 01:22:59 ] わかりました やってみます 539 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 18:26:09 ] ｃ++です DecoratorパターンでConcrete ComponentとDecoratorを区別して Concrete Componentの型を知る方法はdynamic_castを使うしかないですか？ 540 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 18:53:21 ] >>539 型を知って何をするかによって方法が変わる気が。 RTTI(dynamic_castもその１つ)を使うか、Concrete Componentのメンバに型を示すIDのようなものを用意しておくか。 そもそもスレ違い。 541 名前：デフォルトの名無しさん [2008/05/09(金) 11:50:43 ] 鈴木高弘スレｗ 542 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 05:10:51 ] ゲーム作ろうと思い、デザインパターンの勉強をしてるんですが Singletonをどんな風に使うのか今一ピントきません。 Singletonじゃないと困る場合。 Singletonだと助かる場合。 出来たら例を示して貰えないでしょうか。 543 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 07:57:27 ] >>542 ぜひ、こちらへどうぞ ゲームにおけるデータ構造・クラス設計・パターン pc11.2ch.net/test/read.cgi/gamedev/1155209226/ 544 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 16:39:33 ] あちらで聞いてみます 545 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 17:47:41 ] やる夫がデザインパターンをやるようです mojalog.com/2008/02/post_160.html 546 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 18:06:29 ] >>545 やる夫ｗｗｗｗめちゃめちゃ笑った 547 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 18:15:14 ] >>545 デザインパターンの考え方が分かりやすくて助かりました。 548 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 19:23:44 ] AA入ってるのって、一見とっつきやすそうだが…、 読みにくくもあったり…しかし微笑ましいのだけは確か。 549 名前：デフォルトの名無しさん mailto:sage [2008/05/11(日) 21:11:22 ] 例自体は具体的で読みやすいんじゃないか？ デザパタ本て(全部とは言わないが)ほとんどが 説明のための説明みたいな本になってるし。 550 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 02:47:40 ] シンプルファクトリーって始めて知った ファクトリメソッドとアブストラクトファクトリしか知らなかった デザインパターン的には常識なの？ 551 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 02:56:07 ] この手のものは先に名付けたもん勝ちだから あまり仔細にこだわろうとするな。 > ファクトリメソッドとアブストラクトファクトリしか知らなかった 知ったかどうかよりも理解できたかどうかが大事なんだが。 552 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 16:39:49 ] marupeke296.com/DP_main.html 個人的にここのデザインパターンの解説がゲームプログラミングを例にしているせいか わかりやすいんだが、スレ住人的にはどう？ 553 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 16:59:44 ] >>552 わかりやすいし、筆者の理解度は高いと思う。 自分の言葉で言いなおしてるところで、 的が外れていないので高感度アップ。 Abstract Factory 一塊のオブジェクト群を沢山の種類用意する は、恥ずかしながら今までみたどの解説よりスッとくる一文だった。 554 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 22:57:03 ] 例というなら、GoFの元ネタはウィジェットや言語の実装で現われたパターンだから、 自分でウィジェットや言語を書けば何を言ってるのかすぐわかる 555 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 23:10:08 ] うじぇー奴 556 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 00:53:16 ] >>552 FlyWeightってこのページで書かれているような感じなの？ 557 名前：デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:31:42 ] zsh line editorのwidgetでも使えますか！？ 558 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 11:28:21 ] 実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 www.amazon.co.jp/dp/4894716828 この本とかどうだろうね？まだ自分は読み始めだけど。 559 名前：デフォルトの名無しさん mailto:sage [2008/06/14(土) 19:02:26 ] だったら読み終わったときに評価書いてくれ 560 名前：デフォルトの名無しさん [2008/06/18(水) 18:46:30 ] MVCモデルについて質問です。 javaであればModelでは描画するメソッドを一切実装せず、描画メソッドについてはすべてViewで実装するという事ですか？ 例えば、Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思いますが、 そういう時もViewまで先送りにした方がいいですか？ 561 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 00:31:36 ] 描画はモデルじゃね？ 562 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:05:46 ] >Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思います 例えばどんな時？ デザパタの本にありがちな、 Shape インタフェースに draw メソッドがあって Circle でも Triangle でも draw 呼べば片付きますよ、 的な話って、いかにも説明のための説明って気がしてならん。 563 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 02:20:03 ] ここまで一切コントローラの話題が無い件 564 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 07:30:42 ] >>562 まさにそういう時。 アルゴリズムでdraw可能なオブジェクトをいくつかはじきだす。 その時にそいつにdrawメソッドを持たせておいた方が都合がいいのでそうしているが、 癒着してるようで気がかり。 565 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 19:37:43 ] ほれ、答えだ www.fujigoko.tv/rev/prof/doc4/index.html 566 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 20:07:01 ] 長い；； 567 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 23:52:54 ] >>565 当たり前すぎるくらいに当たり前のこと書いてるな。 でも、この当たり前が理解できてないやつが殆どだ。 モデル自体が保存メソッド持ってるフレームワーク見せられて 「なんでこんな設計なの？」「便利だから」 意味不明の回答で泣きそうになった。 次の会社でも探すか。 568 名前：デフォルトの名無しさん [2008/06/21(土) 00:25:48 ] データモデルと永続化は別か，そうかそうか 569 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 00:50:45 ] >>567 あたり前田のクラッカーってどうなったんだろう？ 570 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 09:28:30 ] > モデル自体が保存メソッド持ってるフレームワーク見せられて 普通じゃん。 571 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 09:42:35 ] >>567 むしろ保存とか読み込んで再構築とかいう手間を見せ付けてはいけない 572 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 13:33:10 ] シリアライズ機能くらい普通じゃん 573 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:01:39 ] シリアライズを提供することと保存の主体であることは別じゃね？ 574 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:06:23 ] Save(IOutputStream* stream) Load(IInputStream* stream) みたいに外部に保存主体があるわけじゃなくて、 まさか内部に保存主体があるのか？ 575 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:12:35 ] dbの話じゃないの？ 576 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 16:23:23 ] >>574 保存主体ってなんですか＞＜；； # Save(IOutputStream* stream) これだと「何を」みたいな目的語が全く存在しない 577 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 18:08:59 ] .NET Frameworkだと、シリアライザクラスに分けてあるね。 578 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 18:15:05 ] クラスを分けるのは便利な面もあるけど、 保存すべき情報は外部に見せることのできる情報ばかりではないからね。 両方できるようにしてどっちにするか選択できるのが一番良い。 579 名前：デフォルトの名無しさん mailto:sage [2008/06/22(日) 09:05:38 ] Save(PersistContext pContext)とかになってPersistContextの実装しだいでDBにもXMLにも保存できるのが吉かと。 580 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 21:05:45 ] >>552のAbstract Factoryの頁を読んでみたんだけど、 とても違和感を感じる、というよりはっきり言って全く間違っているように思うのだが これは俺の方が間違ってる？ 俺がおかしいなと思った点は、 (1) void Create( AbstractWeapons *AbsWep)みたいな"具体的な"値を引数で 　　取るメソッドのどこが"Abstract"（抽象）なのか？ 　　思うに、この著者は"Abstract"の意味を取り違えているのではないか？ 　　確かに「武器」はAbstractWeapons という型に抽象化されてはいるが、 　　Abstract Factoryの"Abstract"ってそういう抽象化のことを指しているんじゃないのでは？ (2) 1とも関係するが、著者は自分で『オブジェクト内部で作ってもらった方が、 　　外部の人は渡すべき武器について知らなくて良いので楽になる』と（もっともな）事を言っているのに 　　できたコードは全然そうなってない。 581 名前：デフォルトの名無しさん mailto:sage [2008/07/31(木) 22:20:23 ] >>580 そういう疑問を持ったときは実際にプログラミングするのが早い 582 名前：デフォルトの名無しさん mailto:sage [2008/08/04(月) 17:36:15 ] >>580 (1)AbstractなのはMacheneでもWeaponでも無くFactory、 void Machine::CreateはConcreteなWeaponもConcreteなFactoryも知らない (2)Machineの内部でAbstractなFactoryがWeaponを生成している 実際に生成されているWeaponsを知っているのはConcreteなFactoryのみいう言う状態 と捉えれば別にその2点は間違ってないと思うけど… #LispとかMLでサンプルを書いたOOP系の本が見たい 583 名前：デフォルトの名無しさん mailto:sage [2008/08/07(木) 00:49:16 ] まぁWeaponをインタフェース名にしろと思ったな。 AbstractWeaponsImpl みたいな感じで なんらかの共通処理を持った実装クラス名にすることはあるんだが インタフェース名にAbstractcなんやらーってあんまりしないなあ。 宗教だけど。 584 名前：デフォルトの名無しさん [2008/09/08(月) 11:09:58 ] あげ 585 名前：デフォルトの名無しさん mailto:sage [2008/09/08(月) 14:08:20 ] 読み始めたけど、道のりなげぇぇぇぇ。 586 名前：デフォルトの名無しさん [2008/09/08(月) 20:11:30 ] 或曰: お仕事 www.issei.org/blog/archives/000225.html こちらのサンプルにあるような、 依存部分だけをインターフェスのContextとして取り出し、 実行時に引数にContextを渡して依存を解決するような場合の パターン名は何かありますでしょうか？ もし、ない場合適当なパターン名としてどんなものがありますでしょうか？ 587 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 01:27:27 ] Context と Context のユーザーが 互いにインスタンス参照をもちあう作りが ものすごく不吉な感じするんだけど そのあたりどうなんだろう。 588 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 09:44:23 ] Head Firstの本ってどう？ 589 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 19:11:26 ] abstract Factoryパターンと、Factory Methodパターンの違いについて述べよ。 また、ファクトリパターンがどういう場合に有効なのか知るところを述べよ。 生成メソッド（例えばファイル読み込みなど）を生成すべきメソッドに持たせるとどのような不都合が起こるのかを述べよ。 590 名前：デフォルトの名無しさん mailto:sage [2008/09/09(火) 20:23:18 ] >>588 俺持ってるけど良いよ ホントに重要なパターンだけを優先順位を付けて展開してる、 最初は秘術的なobserverパターンから初めてるのも好感できる observerはstrutsやMVC関連で良く使われるパターンだよね 591 名前：デフォルトの名無しさん [2008/09/10(水) 00:47:57 ] >>590 でもピザパターンとかが無いからなぁ・・・ 入門としては良書だけど、見通しが利かないってとこがちょっと。 592 名前：デフォルトの名無しさん mailto:sage [2008/09/10(水) 17:36:05 ] Head Firstで基礎を勉強したあとの補強にいいのはGoF本？ 593 名前：デフォルトの名無しさん [2008/09/10(水) 20:58:10 ] Amazon.co.jp： Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: 本 www.amazon.co.jp/dp/4873112494 images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg これですか？ 高すぎるんですがｗｗｗ 594 名前：デフォルトの名無しさん mailto:sage [2008/09/10(水) 21:00:44 ] >>593 貧乏自慢すんなよ 595 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 16:16:55 ] 「デザインパターンによるJava実践プログラミング」っていう本がぱっと見GoF本に似てる感じがしたんだけど、 これを読めばGoF本読まなくっていいかな？ 596 名前：デフォルトの名無しさん mailto:sage [2008/09/13(土) 23:48:47 ] どれ読んでも難解だよな ゲームで説明しているページが一番分かりやすい。 1個だけ間違ってるのあるけど 597 名前：デフォルトの名無しさん mailto:sage [2008/09/14(日) 04:40:51 ] GoFをまるぺけのところと照らし合せながら読むのがいいと思う 598 名前：デフォルトの名無しさん mailto:sage [2008/09/14(日) 10:29:03 ] Head Firstシリーズのデザパタ本を読んだ後に同じシリーズのオブジェクト指向設計の本 をちょっと立ち読みしてみたら内容がかぶってる気がしたんだけど、 前者を読んだ後に後者を読む価値はあるかな？ 両方読んだ人いたら教えて。 599 名前：デフォルトの名無しさん [2008/09/21(日) 15:39:38 ] stateとstrategyの違いを教えてください。 600 名前：デフォルトの名無しさん mailto:sage [2008/09/21(日) 17:17:42 ] 実装クラスで表現されたモノによって呼び方が変わるだけで、構造上の違いはないよ。 601 名前：デフォルトの名無しさん mailto:sage [2008/09/22(月) 06:22:50 ] Gofって所謂カタログ本だと思ってた。 >>598 ある 602 名前：デフォルトの名無しさん [2008/09/28(日) 10:00:51 ] 過疎どすな 603 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 23:50:39 ] デザパタてはやり過ぎない不思議 604 名前：デフォルトの名無しさん [2008/10/02(木) 15:47:16 ] 渇祖 605 名前：デフォルトの名無しさん [2008/10/05(日) 14:25:10 ] >>599 「目的が違う」ってことでいいのかな？ stateはアルゴリズムを動的に切り替えられることに意義があり、 strategyはアルゴリズムを分離することに意義がある とか。 606 名前：デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:08:42 ] stateの方、それ違くね？ 607 名前：デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:29:00 ] The differences between Strategy pattern and State pattern Five ’s Weblog powerdream5.wordpress.com/2007/10/05/the-differences-between-strategy-pattern-and-state-pattern/ The difference between the two GOF patterns "Strategy" and "State" www.c-sharpcorner.com/UploadFile/rmcochran/strategy_state01172007114905AM/strategy_state.aspx 散々議論されてきた歴史があるのでそれを参考にしたらいいと思うよ 608 名前：デフォルトの名無しさん mailto:sage [2008/10/08(水) 23:54:54 ] Compositeってやつのみっつのくらすをひとつのクラスにすることは出来るの？ 609 名前：デフォルトの名無しさん [2008/10/09(木) 12:31:35 ] っていうか、「何でお前が勝手にルール決めてんの？つか誰？」って感じしない？ 610 名前：デフォルトの名無しさん mailto:sage [2008/10/09(木) 16:31:30 ] >>608 XMLとか 611 名前：デフォルトの名無しさん mailto:sage [2008/10/13(月) 23:36:50 ] >>609 OOPのノウハウを共有するために呼び名を決めたほうが良いね、ってのが デザインパターンの意義なのにルールも糞もあるもんか。 おまいが好きなノウハウに好きな名前を付けたけりゃ、そうすればいい。 それを共有しようとする奴は誰もいないだろうがなぁ。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef