06/03/07 08:01:01
>>979
＞ クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
＞ やりやすい点ぐらいか・・・
ユニットテスト時にモッククラスと入れ替えることができるということは、将来そのクラスに
対して変更があった場合、保守コストが引き下げられるということを意味しているはず。
＞ オブジェクト指向本来のインタフェースの用途ではなく、
＞ 言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
あなたの考えるオブジェクト指向本来のインタフェースの用途って何でしょう？
実装とインタフェースは無理矢理分けられてるのではなく、本来これらは別々のもので
あるべきなんじゃないかい？
982:デフォルトの名無しさん
06/03/07 12:17:18
>979
DIコンテナ使わないチームと使ったチームで比べられればいいけどね。
俺はもうDIコンテナなしの開発は考えたくないです。
まぁDIスレ(typoしてるが)でやるのが適切な話題だし、
あっち過疎ってるから盛り上げて欲しいってのが本音。
983:デフォルトの名無しさん
06/03/07 16:36:13
＞将来そのクラスに
＞対して変更があった場合、保守コストが引き下げられるということを意味しているはず。
タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
よくあるのかな？
984:962
06/03/07 18:00:51
>>982
DIコンテナって使うとソース見やすくなったりとかするの？
DIコンテナって要は実装クラスをnewする部分をファクトリーじゃなくて、設定ファイルに書くみたいなやつだよね？
設定ファイルの情報を反映させたいときは再起動が必要みたいだから、
ファクトリーで書くのとあんま変わってないのであまり利点を感じないのだが…。コンパイルは不要だろうけど。
985:981
06/03/07 19:20:50
>>983
＞ タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
＞ よくあるのかな？
意外とよくある。 新規開発の際、客先がちゃんと要求を出せてない部分が
開発途中にガンガン決まっていくんだが、デザパタ使ってると楽に対応でき
るぞ。 その都度リファクタリングしてもいいんだが、新規開発時だとユニット
テストデータもちゃんと揃ってないから、その手があまり使えないんだわ。
どの部分が曖昧なのか、ちゃんと客先ヒアリングして頭使わないとダメだけどね。
986:デフォルトの名無しさん
06/03/07 19:29:23
変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
987:デフォルトの名無しさん
06/03/07 19:55:01
インタフェース設計レベルから変更を余儀なくされる要求が多いな。
988:デフォルトの名無しさん
06/03/07 20:10:10
>>976
極端から極端に走らなくてもいいじゃん
仕様に載ってない機能を搭載し、ファイル以外にDBやgmailやSubversionも保存先として使えるようにして
隠しオプションでどんな仕様にも即対応！ みたいのはそりゃだめだ
デザパタは問題の解決法として書かれていて
その問題があるときは割と的確な粒度の解決だと思うがどうだ？
あれでもまだ余分かな？
989:981
06/03/07 20:23:57
>>986
＞ 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
＞ デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
結構大変だけどね。 客先が「XXがYYという風に変わりそうだ」なんて自分から教えて
くれることはほとんどないけど、「ここがこうなるとかいうこと考えられます？」といった
聞き方を続けてると、答え方の雰囲気から変更されそうなところが見えてくる場合が多し。
で、実際に変更が発生すると、「実はそういうこともあろうかと、、、」と徳川機関長モードに
入る。
990:デフォルトの名無しさん
06/03/07 23:54:24
>984
この話題、DIスレにコピペしてもフォローしてくれますか？
(スレタイの意味での)デザパタとは全然関係ないと思うし。
＞ソース見やすくなったりとかするの？
それはないです。
>988
＞的確な粒度の解決だと思うがどうだ？
当方もそういう意識ですね。
そういう意味でもアーキテクトと言うよりは、
プログラミングレベルの話題だと思う。
フレームワーク作成チームが知っておくべきプラクティス。
991:962
06/03/08 01:21:50
>>990
＞この話題、DIスレにコピペしてもフォローしてくれますか？
いやいいっすわ。DIスレみてたら同じ疑問を持っている人がいて勉強になりました。
ありがとう。あっ、でもやっぱり聞いてみようかな。
>>986
漏れの理解ではだけど、デザパタは実装の入れ替えが容易というのが売りだと思ってるから、
プログラムのやることが変わったらデザパタで組もうがなんだろうが変更する量はさほど変わらないと思う。
ただプログラムのやることは同じだけど実装を変える。
例えばパフォーマンスアップのために仕様変更するというのであれば、
それは実装の変更であるから、そういう変更には予想してなくとも強くなれると思う。
992:デフォルトの名無しさん
06/03/08 01:40:16
つーかさ、
ボタンクリックしたら、そのクリックしたメッセージが降りてくるその場所に
その処理が記述してあってほしい。（関数とかクラスとか）
そうでないと他の人間の書いたソースなんて追えない。
降りてきたメッセージをさらにどっかに飛ばす処理なんか入ってるともう駄目。
すげー面倒臭い。どうにかしてくれ。
単純に、ただ単純に書いて欲しい。
それだけ・・・それだけなんだ・・・orz
993:986
06/03/08 01:43:31
>>991
たとえ話になるけど 「１００Ｖコンセントがあれば、殆どの電化製品に対応できる」 とか考えて実装してると、
いざ 「実は、この家電アース線がついてるんだけど……」 ってなったときに、コンセント側も改造しなくちゃいけないな、
って話をしてみた。
アース線無い家電製品のみに限定するなら、いくらでも変更は可能。変更に強い。
ただしアース線だとか外国用の特殊形状だとかが変更で出てくると面倒になるってことで、
どこまで変更を予測するか～って話だ。
ちなみに↑は Strategy を想定してみた。
解決策としては、Adapter が使えれば手っ取り早い。
どうでも良い。次ぎスレたのむ。
994:962
06/03/08 02:08:21
>>992
基本的には単純なものは単純に書くよｗｗ 必要になったときにしかデザパタは適用しないよ。
処理をたらいまわしにしている人のソースに悩まされてるの？たまにいるわなぁ。
デザパタだとかいって何でもかんでもたらいまわし処理書く人は。俺も追えない。30秒で諦める自信ある。
必要になった場合に適用すると効果を発揮するというのに、むやみに使うのは毒でしかない。
やるべき処理を素直にコードにすることが一番の解だというのに。
995:デフォルトの名無しさん
06/03/08 02:22:21
マ板的な話題になってしまうが
とあるベンダが俺様フレームワークを作成して
基本設計の説明に加えて
「ここはあのパターン、ここにはあのパターンを使ってる。」
みたいなことをのたまって
最後にパターン名と適用の有無からなる
2列23行の表を見せて、こんなにたくさん○が付いてますよ
(使った(ことになってる)パターンを○でカウントする。)
みたいな感じで胸を張ってた。
手段が目的にすり替わってしまうと大体ロクな結果を導かんよね。
アンチパターンの表を作るのは意味があるかも知れん。
なんか盛り上がってきたし次スレ欲しいなあ。
996:デフォルトの名無しさん
06/03/08 03:02:51
手段のためには目的を選ばない。
997:962
06/03/09 03:33:36
では私が建てよう。ひっそりと深夜に。
998:962
06/03/09 03:39:13
＞新このホストでは、しばらくスレッドが立てられません。
＞またの機会にどうぞ。。。
「【GoF】デザインパターン 6」で建てようとしたけど駄目でした orz
建てて誘導したいけど残り２レスしかない・・・。
999:デフォルトの名無しさん
06/03/09 04:28:57
次すれ
「【GoF】デザインパターン 6
ｽﾚﾘﾝｸ(tech板)
1000:デフォルトの名無しさん
06/03/09 04:29:41
コピペミスで「が残ってたorz
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。