- 1 名前：デフォルトの名無しさん mailto:sage [2005/06/21(火) 19:09:56 ]
- そもそもデザインパターン自体どうなのよ？って話はここでやれ。
- 844 名前：デフォルトの名無しさん mailto:sage [2005/11/27(日) 17:29:00 ]
- まてまて
調べても理解出来なかった というパターンもありうる。
- 845 名前：デフォルトの名無しさん mailto:sage [2005/11/27(日) 17:33:38 ]
- >>844
我々は選ばれた人間なのですね！
- 846 名前：デフォルトの名無しさん mailto:sage [2005/11/27(日) 22:59:43 ]
- 一人で書くなら不要
一人神グラマがいれば、そいつを基準に周りがまねたら良いから不要
一人ではまだ頼りない感じの人達をまとめ上げるために必要なものだ
- 847 名前：838 mailto:sage [2005/11/28(月) 12:18:29 ]
- >>843
> >>838==>>842
残念ながら違いますよ。間抜け。
> ちょっと調べればMVCで実際に設計する方法がわかるのにね
判っているなら、そうしなさい。
- 848 名前：839 mailto:sage [2005/11/30(水) 23:48:07 ]
- >>844 調べてわかったけど釣り発言してみよう というパターンもあり、えない
>>845 ！
>>847 ｵﾄﾅｹﾞﾅｻｽ
- 849 名前：デフォルトの名無しさん mailto:sage [2005/11/30(水) 23:57:52 ]
- /:
∧∧ / :
(,,ﾟДﾟ/ :
＿ / つ/） ＿ :
〜（⌒）__） /| ,, :
￣￣￣￣￣|/,,,
〜〜〜〜〜〜〜〜〜〜〜
- 850 名前：デフォルトの名無しさん [2005/12/01(木) 05:51:30 ]
- M マゾな
V vsialbasic使いは
C CやC♯は使えません。
MVCで
webは何となく分かるけど
javaのクラス設計で考えたら
Vはインターフェイスとして
Mが実装で
Cはインスタンス化＝利用するクラス？
結城先生の本買った方が良いのかな・・・・
高いしな
- 851 名前：デフォルトの名無しさん mailto:sage [2005/12/01(木) 07:53:24 ]
- あのころのおれならＭＬですまーとにかいたんだけどねｗ
- 852 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:08:41 ]
- strategy パターンって単なるコールバックじゃんｗｗｗ
- 853 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:17:04 ]
- そうだが……何か辛いことでもあったのか？ 俺でよければ相談にのるぞ？
- 854 名前：デフォルトの名無しさん [2005/12/04(日) 23:05:16 ]
- 良スレあげ
- 855 名前：デフォルトの名無しさん [2005/12/09(金) 00:50:56 ]
- >>847>>842
> >>837==>>840
も実は違うんだが・・・
ちょっとからかっただけ
オマイってからかうとオモシロイナw
必死に反応してくれてw
- 856 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 10:59:08 ]
- 釣り宣言キタコレ
- 857 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 00:21:15 ]
- まあ 隔離スレなんだから、こんなんばっかだろ。
頭のいい奴は、つられたりしないわけだから
気をつけてればいいのさ
- 858 名前：デフォルトの名無しさん [2005/12/11(日) 17:38:28 ]
- 852>strategy パターンって単なるコールバックじゃんｗｗｗ
同感です。昔、GOF 本を読んでクラスを使って実装した strategy パターンのコードを単純化して言ったら、関数ポインタの設定値の切り替えだけになっちゃいました。
それから GOF 本を真剣に読む気持ちがなくなりました。
- 859 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:58:58 ]
- >>858
デザパタの存在意義が「技術ブレークスルー」だと勘違いしている
馬鹿がまた一人。
- 860 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:59:31 ]
- >>852,858
デザインパターンに過剰な期待をしていないか？
「単なる○○じゃん」「同感」という発言は、
デザインパターンの目的・役割を取り違えてないか？
デザインパターンは、別に
「そこらのエンジニアが考えつかないような素晴らしい夢のパターン集」
でもなんでもないぞ。
誰でもやっている・よく使われる設計手法に名前を付けてカタログ化したものでしかない。
エンジニア間の共通認識化・共通語化するのが目的。
- 861 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 18:14:57 ]
- 指きたす同様デザインパターンって言葉を使いたがる人たちがいるだけだろ
- 862 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 19:33:05 ]
- 例えばJavaDoc に
・・・
このクラスはGoFの○○パターンの××です．
@see □□
@see △△
とか書いて有ればクラス図見なくても設計意図と構造が解る
ってのもデザインパターンとして用語と設計が定義して有るおかげよね．
- 863 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 19:40:58 ]
- >>862
ぶっちゃけ言いたい。
構造が分かっても用途が分からないドキュメントは糞。
- 864 名前：デフォルトの名無しさん [2005/12/11(日) 20:16:20 ]
- ＞とか書いて有ればクラス図見なくても設計意図と構造が解る
￣￣￣￣
＞構造が分かっても用途が分からないドキュメントは糞。
￣￣￣
ここでもエンジニア間の共通認識化・共通語化をする必要がありそうだな
- 865 名前：デフォルトの名無しさん [2005/12/11(日) 20:24:19 ]
- デザインパターンは、単なるカタログです。
共通的に使える設計で出てくるパターンは、
資産化しなさいよーという教えです。
- 866 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:28:27 ]
- 完全にデザインパターンにマッチする方が少ないんじゃない？
適用できるなら適用すればいいだけかと
- 867 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:01:21 ]
- >>863
詭弁のガイドライン
6.一見、関係がありそうで関係のない話を始める
16.全てか無かで途中を認めないか、あえて無視する
17.勝手に極論化して、結論の正当性に疑問を呈する
あたりか
- 868 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:02:12 ]
- >>863
>構造が分かっても用途が分からないドキュメントは糞。
そんな当たり前のことを偉そうになに突っ込んでるんだよｗ
- 869 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:23:54 ]
- >構造が分かっても用途が分からないドキュメントは糞
まんまデザパタのことだな。
- 870 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:27:25 ]
- …………俺、爆弾投下しちゃったっぽいな
- 871 名前：デフォルトの名無しさん mailto:sage [2005/12/26(月) 18:26:38 ]
- で、隔離スレが出来たら本スレがほんとに落ちちゃったわけか･･･
ここのアンチの人ってオブジェクト嗜好だよね。
憂鬱本読んでわかった気になってるパターンか。
- 872 名前：デフォルトの名無しさん [2006/02/21(火) 23:48:17 ]
- ちょっとデザインパターンからはずれてしまうんですが、
内部設計というか、プログラムのインターフェース設計ってどうやってます？
自分の経験では、共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
簡単にいうと、こういうことです。
処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）のように１つのメソッドで処理Ａ〜Ｃを行い、どれを行うかは引数で指定する）。
ただし、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品を作るべきだが、
大元の処理は分けて実装すべきだった。
なんで、こんな失敗するんでしょう？
最初からＡ〜Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ〜Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様どうやって設計してますか？
- 873 名前：デフォルトの名無しさん [2006/02/21(火) 23:49:16 ]
- 872の続き
けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様どうやって設計してますか？
- 874 名前：デフォルトの名無しさん [2006/02/21(火) 23:59:09 ]
- 2行しか読んでないけど
>どれを行うかは引数で指定する
これが間違ってると思う
- 875 名前：大根 [2006/02/22(水) 00:00:29 ]
- >>874
ご回答ありがとうございます。
すいません、新スレ立てさせていただきました。
デザインパターンとは違う話題なので。。。
- 876 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 16:53:47 ]
- そういや、デザパタスレなくなったな。悲しいことだ。
- 877 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 18:31:51 ]
- 昔から俺がやってた手法に勝手に名前つけられただけ
- 878 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 18:48:42 ]
- 未だに>>877みたいな勘違いをしている奴がいるんだな。
名前を付けて普及させ、技術者間の共通認識にするところまでやってはじめて価値が出る。
どんなに優れた設計でも『オレ様パターン』じゃ意味ないんだよ。
- 879 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 19:12:09 ]
- >>878
その点において最大の価値がある。
>>877
全パターンをただ一人で考案した
というのはとても信じられない
- 880 名前：責任転嫁マン mailto:sage [2006/02/24(金) 01:07:28 ]
- じゃあ、このスレで900を取った奴がデザパタスレ建ててくれ。
確か、５スレ目まで言ってたので、「【GoF】Design Pattern 6」とかで。
- 881 名前：デフォルトの名無しさん [2006/02/25(土) 00:39:28 ]
- まだ、こんなスレあんのか？
デザパタなんて使ってる会社無いっていってるだろ。
だいたいGoF本なんてもう絶版だろ？ﾜﾛｽ
オブジェクト指向が理解できない奴ほど食いつくんだよな
いい加減にオブジェクト指向理解しろって
オブジェクト指向言語がメジャーになってから何年経つんだよﾃﾗﾜﾛｽ
- 882 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 00:47:09 ]
- J2EEパターンを知らない奴がまた現れたのか。
JavaでサーバサイドシステムをJ2EEパターンを使わないで作ってる会社なんて無いよｗ
- 883 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 00:54:09 ]
- >>882
はぁ？なにそれ？
- 884 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 01:39:23 ]
- >>883
「？」の後は１つ空白を入れろ 話はそこからだ
ただし」が続く場合はいらないぞ
- 885 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 02:42:03 ]
- >>884
うるせえよ
氏ね
- 886 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:49:04 ]
- >>883
言われたとおりに書いてればおｋなドカタには不要なモノだよ
- 887 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:56:55 ]
- まあれだ、デザパタってのはプログラマに対して、
コンビニのアルバイトみたいに、接客対応マニュアル
を用意してくれたってことでしょ
- 888 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 12:43:07 ]
- デパガがトイレに行く事を棚卸してきますとか言うだろ？
共通の認識がないとこういう符丁は成立しない。デザパタも似た様なもんだｗ
- 889 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 18:16:18 ]
- 一人プロジェクトでメンテも自分以外やらない、つー場合でもメリットある？
あるなら本でも読んでみようという気になるかも
- 890 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 18:35:05 ]
- >>889
こうしてこっちはあーしてこういう風に作ろう が これしよう と単純に考えられる
ライブラリでデザインパターンになってるものがあるから、それを簡単に理解できるようになる
- 891 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:02:37 ]
- 考察段階でつまずいたり時間がかかったりすることは
ほとんどないしなあ。今ひとつ食指が動かない
- 892 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:24:15 ]
- pc8.2ch.net/test/read.cgi/prog/1140795650/2
, -‐−-､ ヽ∧∧∧ // |
. /////_ﾊ ヽ＜ 釣れた！＞ ハ
ﾚ//ｊ け ,fjlﾘ / ∨∨V ヽ h. ﾟl;
ﾊｲｲﾄ､"ヮノﾊ // |::: ｊ ｡
/⌒ヽヾ'ﾘ、 // ヾ､≦ '
. { j｀ｰ' ﾊ // ヽ∧∧∧∧∧∧∨/
ｋ〜'ｌ ﾚﾍ. ,r'ス ＜ 初めてなのに ＞
| ヽ ＼ ト､ ヽ-kヾｿ ＜ 釣れちゃった！＞
. l ＼ ｀ｰ‐ゝ-〈/´ / ∨∨∨∨∨∨ヽ
l `ー-､___ﾉ
ﾊ ´￣｀ 〈/‐-､
- 893 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:42:26 ]
- >>891
考察段階でつまずくんじゃなくて、考察内容自体を短縮するんじゃないか？
- 894 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:53:19 ]
- 例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
んだけど。
- 895 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:56:16 ]
- >例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
>動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
>思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
入るわけない
誰がそんなこと言ったの？
- 896 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:57:45 ]
- だから、それじゃあ学ぶ価値なんかないよ。一人でやってる限りは。
- 897 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:05:59 ]
- デザパタの使い道がわかっていない典型だ
- 898 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:30:33 ]
- だから一人プロジェクトでの効能をｷﾎﾞﾝ
- 899 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:41:49 ]
- 10ステップの命令文を1つの関数にすれば、関数の名前だけで内容が一気に把握できる
そういうことが本当に分からないなら勉強する気も起きないだろうしやんなくていい
釣りかな
- 900 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:51:18 ]
- そんなことは百も承知だけど例えとしてそういうもんなのか？
無限の関数名が出来そうだけど
- 901 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:04:06 ]
- >>898
「こういうときはこうする」というチップス集としても役立つ。
自分で考える手間が減るだろ？
専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
機能として実装するだろ？
そういう部分で「よくやる手法」としてのチップス集にはなる。
あるいは機能の重複をどう効率よく実装するか、とか。
・・・無理矢理かな？
- 902 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:11:07 ]
- なんねぇんじゃん。
変数名をプロジェクトで決まった用語のローマ字方式でつけてて
開発の途中でダサいって理由で英語で付け変えた変数名も、
誰も読めないって理由で結局対応表が必要になった。
これはデザパタにもいえることだけど余計な手間増やしてない？
みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。
アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
その説得力は無いも同然。
デザパタがいいという人間はデザパタを知ってる人間とかしか開発がしたくなくなるとかいう呪い付き。
やっぱり駄目じゃねぇのかな？
- 903 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:16:55 ]
- >>901
＞専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
＞機能として実装するだろ？
この辺がどう効率的になるのかわかんないんだ。現状でもコーディング
の時間以外はコストかからんしライブラリやフレームワークがあればそれ
も軽減できる。
＞「こういうときはこうする」というチップス集としても役立つ。
チップスの数って数えられるほどに押さえられるもんなのか？
そういわれると問題に対して適用する手法はそんなにない
ような気もしてきた。
- 904 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:59:21 ]
- >>900
無限ってことはないでしょ 使われなくなったら消えるし
良く使われる部分にそれがあると楽になるんじゃないか
良く使われる部分でもその名前が知られてなければしょうがないというのは……
まあ自分で考える時に使うということで
gotoよりforループだ ってぐらいのものじゃないと意味がないってことか？
- 905 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:20:01 ]
- >>904
>gotoよりforループだ ってぐらいのものじゃないと意味がないってことか？
そう。
プロジェクトで結構手間がかかるのは
個人個人の認識の仕方を確認し、それを共通認識までもってくことだからな。
その手間をぶっちぎって、「デザインパターン読んでください」なんて突き放してうまくいくわけがない。
中国語と英語を話す国に
「今日から日本語が母国語になります。ええ、決まったことですからしょうがないですね。」
なんてふっかける行為となんら代らない。
- 906 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:21:10 ]
- ＞ ライブラリやフレームワークがあればそれも軽減できる。
それこそがデザパタの適用ｗ
- 907 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:22:01 ]
- ＞無限ってことはないでしょ
これはなんとなく分かるけど
＞使われなくなったら消えるし
＞gotoよりforループだ ってぐらいのものじゃないと意味がないってことか？
スマンが何を言ってるのか不明。
- 908 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:22:12 ]
- たしかに日本語のテキストなんかもたくさん出てるだろうし、
勉強する環境やらお金やらは問題ないかもしれんだけどやるか？やらんだろ？
- 909 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:25:47 ]
- ＞＞ ライブラリやフレームワークがあればそれも軽減できる。
＞それこそがデザパタの適用ｗ
おれデザパタとか意識してないよ。
こういうときはこれ（ライブラリでも手法でも）を使う、ってのは
大概苦労せずに出てくるけど
- 910 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:25:51 ]
- ＞ アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
＞ その説得力は無いも同然。
わかってんじゃん。
＞ みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
＞ そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。
俺の周囲は常識としてあたりまえに知っているけどな。
デザパタを知らないDQNばかりの開発者だらけの現場だとそうなる。
･･･とは言え、分野にもよるのだろう。
J2EEアプリの開発者達は知っていて当たり前。知らなければDQNと言われても仕方ない。
他の分野だとJ2EEアプリほどアプリ全体の作りがパターン化しないと思われるから
デザパタが普及する必要性は低くなるだろう。
- 911 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:31:49 ]
- >>910
J2EEなんて狭い世界にしかいないからそんなんなんだよｗ
- 912 名前：デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:54:14 ]
- データ構造には名前が付いてる。スタックだとかツリーだとかリストだとか？
アルゴリズムにも名前が付いてる。バブルソートだとかクイックソートだとか？
OODにも名前を付けてみた。それがデザインパターン。
>>905
デザパタがあるから不親切なのか？不親切な奴はデザパタの有無とは無
関係に不親切だぞ？
もしデザパタがなかったなら、ソース読めと突き放されるだけだと思うが？
全部暗記しないと話にならない？ありえん。
全てのデータ構造を知ってるか？全てのアルゴリズムを知ってるか？
少なくとも俺が知る限り、そんな奴はいない。
重要なのは、名前は目次になるってこと。
名前を得られれば、その実装なり実装例なりを得られる。ないと困るだろ？
- 913 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:05:34 ]
- >>907
使われなくなったら消えるっていうのはそのままだ
誰も使わないデザインパターンは消え去るでしょ？ 言葉と同じ
gotoとforループは機能と認知度のことで例としてあげた
gotoでforと同じ機能が実現できるけど、forを使う
それは便利で、そして誰でも知ってるからか という話
そんなに分かりにくかったかな……
- 914 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:44:57 ]
- >>912
>ないと困るだろ？
別に困らない。
むしろ、勝手に名前をつけて共通認識にもなってないのに使ってくる奴のがウザイ。
- 915 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:58:36 ]
- 自分の知ってることが全て 俺が知らないことは言うな
ってやつもウザイ。
- 916 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:15:27 ]
- >>915
でも、仕事でそういう状況のときってどうするのが適切なのかな？
例えば、
Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはステートパターン」
Ｂ：「なにそれ？」
Ａ：「デザインパターンという・・・というわけですよ」
Ｂ：「なんかよくわからないけど、そのパターンがどうしてここで使っててそれで間違った組み方じゃないって言えるの？」
Ａ：「だから、デザインパターンの・・・はこういう・・・のときに使うのが・・・なわけですよ。」
Ｂ：「どして？さっぱりわかんね。そもそも、そのステートパターンとかよくわからないし。何がよくてどうしてそのパターンを使いたいの？」
ってなったときね。
ここで本を渡して「はい、自分で勝手に調べてね」っていうとすげーヤナ奴じゃない？
上司でもないのに変な用語使って勝手に仕事増やしてる痛い奴であることに間違いは無いよ。
やっぱり無難にそのパターンの詳細を説明することになると思うけどそれだと別にそのクラスの仕組みを説明すればいいんであって
べつにパターンとかいう必要ねぇし。と思う。
これってデザパタ知ってる奴同士でも同じじゃね？
- 917 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:40:56 ]
- Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはステートパターン」
Ｂ：「なるほどね」
- 完 -
- 918 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:42:02 ]
- >>916
それ、前提が間違ってるわ。
配列で済むとこにリスト使ってたら、そりゃただの馬鹿だろ？
デザパタも同じで、不要なとこで使ってたらただの馬鹿だ。
試しにさ、リストを使う妥当な理由があるという前提の下で
リストを知らない者にリストという単語を使う事なくそのデー
タ構造を説明するというシチュエーションで話作ってみてよ。
- 919 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:42:14 ]
- J2EEってそんなに狭い世界なのか？
- 920 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 04:17:28 ]
- 自分はもっといろいろ知ってるんだぜ！って言いたいんだろｗ
- 921 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 05:09:22 ]
- >>916
クラスの仕組みを説明したときに、それにこういう名前がついてるっていえばいいんじゃないか？
名前の説明が追加されても大差ないし、次があれば楽に説明できる
それとその例だとAさんが説明したのにBさんが分かってないようだが
Aさんの説明が悪いか、Bさんに理解する気がないかのどちらかだ
- 922 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 08:51:14 ]
- >>918
916じゃないけどやってみた
Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはリスト構造」
Ｂ：「なにそれ？」
Ａ：「要素をインデックスじゃなくて、次へのポインタで指すデータ構造です」
Ｂ：「……ああなるほど、これだとデータ挟んだり抜いたり、配列でやりにくいことが楽に出来るんだ」
例えが分かり易すぎて引き合いにはなりませんですた。
デザパタが物議をかもすのは、ひとつの名前に対しての内容が
人によってはアンバランスに感じるほど詰まってるからじゃねーの？
おれはデザパタ知らん人間ね。
- 923 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 08:51:24 ]
- 共通の名前ってーのも一理あると思うが、デザパタって「システム」という大枠を
どのように細分化していくかって話もあるだろう？ （つまり境界線をどこに引くか）
>>894
＞ 例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
＞ 動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
＞ 思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
そういった思考手法そのものが手に入るのではなく、そういった思考手法と他の機能が
どのように連携するのかを考え、適切なクラス分割が行えるようになる。
例えば、将来的に音声認識アルゴリズムを（クラスを追加するだけで）ばっさり他のものと
入れ替えることが簡単に行えるようになるわけ。
＞ こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
＞ んだけど。
ソフトが行っている内容は考察するほどもない簡単なものかもしれんが、
将来どういった仕様変更があるのか（どの部分を入れ替えられるようにするのか）について
は色々考えるべき点が多いぞ。
- 924 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 09:02:06 ]
- >>923
＞入れ替えることが簡単に行えるようになるわけ。
別にデザパタ知らんでも簡単に入れ替えられるんだな。
＞将来どういった仕様変更があるのか
仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。
つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
組み方してるんだろう。
素直に組んでれば改変追加etc、何も問題ないと思うんだけど。
- 925 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 09:20:16 ]
- >>924
＞ 別にデザパタ知らんでも簡単に入れ替えられるんだな。
そういう人にとってはデザパタって「共通の名前」という以外の意味はないんでしょうな。
＞ 仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。
その「面倒くさいなぁ」ってーのはどんな感覚？
Ａという要求がＢという要求に変わった時、クラスの「追加だけ」で対処できる？
Ａの機能を呼び出したりする部分を一切変更することなく、Ｂの機能を実現したクラスの
追加だけで対応できているんであれば、あんたはかなりの実力者だ。
＞ つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
＞ 組み方してるんだろう。
仕様変更が起こった場合、変更とは直接関係のない部分（上記で言うところのＡの機能を
呼び出している部分）まで修正が及ぶため、そこも含めてテストをやり直さなければなら
なくなるのが普通。 これによって工数が無茶苦茶増える。
＞ 素直に組んでれば改変追加etc、何も問題ないと思うんだけど。
客先からの要求ヒアリングでも、「どこに仕様変更が起こりそうか」なんてことは
ほとんど聞けないのが実態。 素直に組むことで問題が解決される例はほとんどない。
- 926 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 11:14:54 ]
- >>925
＞その「面倒くさいなぁ」ってーのはどんな感覚？
単に仕事が増えてゴルア。精神的な問題のみ
＞Ａという要求がＢという要求に変わった時、クラスの「追加だけ」で対処できる？
クラスかどうかはともかく、変更の規模によって
・Aを多少改造（現機能も維持したまま条件判断で追加のケース）
・Aをまるまる残してBを追加。
関係ないけど、どっちのケースもAの動作はとりあえず残しておく。
元に戻したい時ってのは常にあるから。容量が厳しい場合はケースバイケース
＞変更とは直接関係のない部分（Ａの機能を呼び出している部分）まで修正が及ぶ
AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。
変えたところをテストするのはしゃーないじゃん
まったく関係ないところはあたりまえだが変更など皆無。
＞「どこに仕様変更が起こりそうか」予測できない
だから、変更を許容せよ、がおれの組む時の一番頭にあること。
プログラムを仕事にしてから一番学んだのはそれだね。
- 927 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 11:58:16 ]
- ソース管理ツールくらい使ってるだろうし、
戻すなんて手間じゃないだろうに。
…じゃなくて。冷静になろう。
話がデザパタから微妙にずれてきてる。
これはニュアンス的にはリファクタリングのネタだよな。
- 928 名前：925 mailto:sage [2006/02/26(日) 12:11:13 ]
- >>926
＞ AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。
そうとも言えないんじゃない？
AとかBとかの機能と、それを呼び出す部分のインタフェースをうまく設計すると
AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
無くなるわけです。
さらに、Aのインスタンスを生成する部分に工夫を加えておくと、設定ファイルを
いじるだけでAのインスタンスでもBのインスタンスでも生成できるようになるん
ですな。 コードに手を加える（修正する）必要が無くなるんです。
＞ 変えたところをテストするのはしゃーないじゃん
その通り。 だから修正部分が減るとテスト工数が激減することになる。
＞ だから、変更を許容せよ、がおれの組む時の一番頭にあること。
デザパタ（というかオブジェクト指向原則の多く）が言っているのはまさにそこ。
変更を許容する以上、変更点を局所化することこそを考えるべきではないで
しょうか？
- 929 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 12:14:07 ]
- >>927
＞ 話がデザパタから微妙にずれてきてる。
＞ これはニュアンス的にはリファクタリングのネタだよな。
いや、ずれてないと思うぞ。
デザパタを利用することでリファクタリングも楽になるという点で、関連はあるが。
- 930 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 12:22:05 ]
- >>927
スレ違いごめんよ
＞ソース管理ツールくらい使ってるだろうし、
＞戻すなんて手間じゃないだろうに。
単純に戻すとかいう問題じゃなくて、どっちも使いたいとかなる
場合もあるからプログラム的に共存させておくことを念頭におい
て作っている
>>928
＞AがBに変わったとしても、
もちろん外見が同じなら何も変更はしないよ。
ただそうじゃない場合もあるし。（まれと言えばまれ）
まあ、
＞設定ファイル
それをもっと進めている。外見のインターフェースがまったく
変わったとしてもコードのビルドしなおしなんてやんない。
ビルドしなおすのはまったく新しい機能追加と
大好きな最適化やる時だけ
- 931 名前：925 mailto:sage [2006/02/26(日) 12:38:28 ]
- >>930
＞ もちろん外見が同じなら何も変更はしないよ。
＞ ただそうじゃない場合もあるし。（まれと言えばまれ）
外見（つまりインタフェース）を同じになるようにするってーのが、システムを設計する
際の肝であり、GoF本が主張している「インタフェースに対して設計する」ということで
すね。
「そうじゃない場合もあるし」というのは、まだまだ精進する余地があるってことでしょう。
（とはいえ、完璧に予想するなんて、神にしかできないだろうが。w）
そういった観点から見た場合、デザパタは「変化しそうな部分の外見（インタフェース）を
汎用的な形に変形するための設計をカタログ化」したものと言えるんじゃないかな。
デザパタを使うと無意味なクラスが多くできるとか、デザパタを用いて失敗したという
のは、こういった変形を必要以上にシステム内に持ち込んだり、誤った変形をしてしまった
結果に起因するのではないかと言ってみる。
- 932 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 17:15:45 ]
- >>928
>AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
>無くなるわけです。
これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。
- 933 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 19:37:56 ]
- >>932
＞ これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。
ふっ、、、甘いな。
テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう？
- 934 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 21:52:34 ]
- ＞これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。
ひょっとして、ここは笑いどころだったのか？
ソースコードだけの話って、ソースコードいじると色々とたちの悪い問題が出てくるんだが。
- 935 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 22:08:04 ]
- というふうに、デザパタ肯定派でも意見の対立がある（・∀・）
- 936 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 23:47:30 ]
- >>933
>テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう？
そのテストってどうやるの？
何を証明すればキチンとした動作になってると言えるのかわからない。
とりあえず全パターン出して、今回の変更で変わる部分を抜き出さないとテストは終わらない。
そういうふうに人に説明しにくい仕組みしてしまうよりは、ベタで書いたほうが早いと思う。単純に。
- 937 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 01:46:03 ]
- 多分単体テストと結合テスト、外部テストがごっちゃになってるんだと思う。
- 938 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 01:48:05 ]
- テストの種別も組織によって違うしねｗ
- 939 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 02:58:03 ]
- >>937
それを含めて全パターンだしても>>936のいってることは代わらないと思う。
- 940 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 06:41:21 ]
- 自動化できるところとできないところの切り分けができていないのかと。
- 941 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 07:48:49 ]
- >>936
＞ そのテストってどうやるの？
＞ 何を証明すればキチンとした動作になってると言えるのかわからない。
そんなことを聞くあなたは、ひょっとするとテストの際、毎回全てのケースをテストしているのかい？
（まぁ、xUnit 等をうまく使えば、そういったことも可能だし、効率もさほど低下しないだろうから、
毎回全てのケースをテストすることに対して否定はしないが。）
答えは色々あるだろうが、正しいインスタンスが生成されているかどうかを確認したいのならば
クラスBのコンストラクタが起動された際にコンソールメッセージを出すようにするというのは
一つの手じゃないか？ まぁ、この手の方法は組織によって向き不向きがあるんだろうけど。
それよりも >>932 は >>934 の言ってたソースコードを触った時の危険性を認識しなさ過ぎ。
たいていの厄介なバグは、新規機能に作り込んでしまうのではなく、新規機能を追加した時に
既存機能側をいじり壊して作り込んでしまうものです。
- 942 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 08:30:39 ]
- 交通事故と同じ。やるやつは繰り返す
- 943 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 09:12:00 ]
- かもな。
俺は絶対事故らない、、、とみんな思ってる。
- 944 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 10:31:57 ]
- むしろ事故らなかったことはありませんが（プログラムの方だよん。
車の方はやばいと思って運転するのやめた）
- 945 名前：デフォルトの名無しさん mailto:sage [2006/02/28(火) 03:01:40 ]
- >>926の発言をみる限り、プログラミングはうまそうなので、
必要だと思わないのであれば別に無理して覚える必要はないんじゃない？
俺は面白かったから勉強したけど。
俺が得られたメリットは、コードの整理がうまくなったってことかな。
昔、色々コード書いてて、規模が大きくなればなるほど、整理の方法がわからず、
コードが汚くなることが悩みだったが、デザパタ覚えたことで少し改善した感じ。
あと「カタログ化して、みんなの共通の認識とする」っていうのはあんまメリットない気がする。
デザパタしらん人には無意味だし。ただの浮いてる奴としか見られない。
- 946 名前：デフォルトの名無しさん mailto:sage [2006/02/28(火) 20:30:50 ]
- デザパタなくとも、プログラム上手くなればコード整理はできるけど
デザパタないと、共通認識にはできないから俺はそっちの方が重要だと思う
データ構造とアルゴリズム みたいな本がいっぱいあるけど
クラス構造とアルゴリズム になるのがデザパタだろう
どちらも丸暗記する必要はないけどな
- 947 名前：デフォルトの名無しさん mailto:sage [2006/02/28(火) 22:12:30 ]
- 「デザパタしらん人には無意味だし。」ってのが正論としてまかり通るのが問題だ。
- 948 名前：デフォルトの名無しさん mailto:sage [2006/03/01(水) 01:13:50 ]
- >>947
つーかもう本でてないしｗ
流行りも廃れたしｗ
あのぶ厚い本を一冊読むことを強制するってのは流行らないと思うわ。
なんかもうちょっとお手軽なのじゃないとねぇ。
- 949 名前：デフォルトの名無しさん mailto:sage [2006/03/01(水) 01:23:54 ]
- >>948
もう少し本屋にいった方がいいと思う
- 950 名前：デフォルトの名無しさん mailto:sage [2006/03/01(水) 06:29:12 ]
- >>949
オススメは何？
- 951 名前：デフォルトの名無しさん mailto:sage [2006/03/01(水) 14:20:46 ]
- >>947
うーん、無理だろう。
プログラム勉強するようになっていきなりデザインパターン勉強する奴とかいないだろ。
「関数で処理を分けるのは、なぜ必要なんですか」っていうレベルからだろうし。
１００人のプログラマがいても２０人くらいしか知ってる奴は期待できないとおもう。
それを２０人の都合で、８０人に本よめっていうのはわがまますぎだと思う。
所詮たよれるのは自分です。なんつって。
>>948
まあ、とりあえず、デザパタは得て損はないと思うよ。
ただ全部が全部、よいパターン／読んで欲しいパターンだとはいえないんだけど。
- 952 名前：デフォルトの名無しさん mailto:sage [2006/03/01(水) 15:17:11 ]
- 100人中100人が知っている必要はないだろう。
100人いたら半数以上は言われたとおりに部品製造していればいいコーディング担当だろうし。
設計を担当するアーキテクトチームなら常識的に知ってて当然だとは思う。
設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題。
使う・使わない・どこにどう適用するかは別問題として。
- 953 名前：デフォルトの名無しさん mailto:sage [2006/03/01(水) 20:36:03 ]
- >>950
俺は結城さんの読んで覚えた、お勧め
読んではいないが、最近だと変なねーちゃん表紙のやつ評判よかったような
- 954 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 18:13:55 ]
- >>952
>設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題
なんで？
- 955 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 20:08:18 ]
- >>954
アーキテクトにとっては、良し悪し・使うべき/使わないべきまで含めて知ってて当然の知識だからな。
デザパタも知らない、共通の概念のない非常識な人間が寄ってたかって設計したシステムなど、お里が知れるわｗ
- 956 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:34:37 ]
- そうか「当然の知識」か。そして「共通の概念」か。
・・・それは思いこみであって現実の正しい認識であるとは思えないけどね。
- 957 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:39:43 ]
- >>955
具体的な根拠がなにも示されて無いな。
本当に理系の人間なのかどうか疑問
>>956
ね。
なんか思い込み強いよね。
- 958 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 00:19:40 ]
- デザパタのように今や古典とも言える超メジャーな設計上のスキームを
「知りもしない」ってのは、土方コーダーならともかく
アーキテクトとしては激しく問題があると思われ。
知った上で使う・使わないは別問題だがな。
- 959 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 00:43:55 ]
- 知ったつもりになって使ったつもりになる。
形式だけ学んだので不必要に濫用する。
このパターンが少なくない気がする。
デザパタの粒度ってアーキテクトレベルなんかな？
どちらかと言うとプログラミング(詳細設計から下)レベルに思うんだが。
- 960 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:35:25 ]
- >>958
デザパタなんていつ必須事項になったんだか。
オブジェクト指向でもなんでもないし。
すっげどうでもいい部分の寄せ集めじゃん。
>知った上で使う・使わないは別問題だがな
これでデザパタは使えないって結論に至った人間をどうやって説得するのか？
- 961 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:43:31 ]
- >>959
＞ 知ったつもりになって使ったつもりになる。
＞ 形式だけ学んだので不必要に濫用する。
＞ このパターンが少なくない気がする。
ここのところは同意。 しかし、デザパタの真意はアーキテクトレベルにあると思うぞ。
それをコーディングの定石集だと誤解しているﾔｼが多すぎ。
>>960
＞ オブジェクト指向でもなんでもないし。
オブジェクト指向原理主義ですか？
90年代前半の呪縛に捕らわれてますな。
- 962 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 13:23:31 ]
- >>960
＞すっげどうでもいい部分の寄せ集めじゃん。
そうかね？JavaとかC#とかの標準ライブラリ（java.langとかjava.ioとか）は、
デザパタを基準に作られてると思うけど、あれもすっげどうでもいい使えないライブラリかね？
あれらを見たときなかなかいいもんだと感じたもんだが。
まあ、良いか悪いかの感じ方は、人それぞれとは思うけどね。
>>961
俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
あそこまで本の中身がソースコードだらけにはならないと思う。
- 963 名前：962 mailto:sage [2006/03/06(月) 13:28:47 ]
- まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。
- 964 名前：961 mailto:sage [2006/03/06(月) 15:08:20 ]
- >>962
＞ 俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
＞ デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
＞ あそこまで本の中身がソースコードだらけにはならないと思う。
デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
ことを明確にしている点が肝なんだと考えています。
そういった意味では、本の中身をあそこまでソースコードだらけにしてしまう必要はなか
ったんじゃないかな。 （クラス図とせいぜい状態遷移図があれば十分だったはず。）
実は「GoF本の翻訳がイマイチで理解しづらかった」→「みんなソースコードに頼ろうと
する」というだけなのではないかと。
（かの結城氏もJavaで書かれてないから判りにくいんだと誤解していたし。）
そもそもデザパタがプログラミングレベルの概念だったとしたら、もっと色々な言語が
シンタックスシュガーとしてデザパタ構文を採用してるんじゃないか？
＞ まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
＞ アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。
アーキテクトほどいい加減な言葉もそうそうないと思う。
あれってプログラミングが設計工程に属していることを認めたくない連中が、
（彼らの言う）設計工程とプログラミング工程のギャップを埋めるために作り出した
役割なんだと思うな。
- 965 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 18:49:58 ]
- >>964
>デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
>ことを明確にしている点が肝なんだと考えています。
よく考えると切り離す意味が全くわからないな。
- 966 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 19:20:35 ]
- >>965
＞ よく考えると切り離す意味が全くわからないな。
変更に強くするため。
いくらクラスを作って「カプセル化」だと叫んでも、インタフェース部分に変更が
あると、そのクラスを変更した時、山火事のように影響度が飛び火して広がって
いく。
- 967 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:00:30 ]
- >>966
変更に強いかどうかってそんなに重要かぁ？
俺には設計と実装がマッチしてない糞みたいなソースができるような気がするぜ。
つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
一致してることの方が何倍も大事なことのように思えるんだけど。
- 968 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:01:59 ]
- ああ、言いたいことはさ。
変更されたらそれに合わせて変更が必要になってもいいんじゃないの？
ってこと。
てゆうか、設計が変更されたのに実装がそのまんまっておかしいｗ
- 969 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:16:10 ]
- >>967
設計と実装はそんなに離れない 離れたらその設計参考にされてない
変更に強いって言うのは変更箇所が少ない、影響範囲が小さいってこと
釣りなのかマジなのか……
- 970 名前：962 mailto:sage [2006/03/06(月) 20:21:39 ]
- >>967-968
まあ、デザパタを覚えることで利点を感じなければ覚える必要は無いと思うけどね。
あと、「設計変更による変更に強い」というよりは、
設定ファイルや、オプションによる処理の変更には強くできるね。
一行変えるくらいで後々の処理を大きく変えることができるとか。
設計変更されたら実装かえるのは当然だぁね。
- 971 名前：962 mailto:sage [2006/03/06(月) 20:35:48 ]
- >>967
＞つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
＞一致してることの方が何倍も大事なことのように思えるんだけど。
こりゃ同意だな。実装はともかく、設計（インターフェース）は、
万人がイメージしやすい＆理解しやすいことが望ましい、というかそうすべきであると思う。
デザパタのほとんどのパターンは、実装の変更を容易にすることを目的としているかな。
例えば、データを読込＆保存する処理をしたい場合に、保存する手法は何でもよいというとき、
その中身の実装は、普通にファイルで保存したり、ＤＢにしたり、ＸＭＬにしたり、
と後々実装を変えたい、または、コマンドラインオプションや設定ファイルによって変えたいと
思った場合の変更に強くすることができるかと。
- 972 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:44:47 ]
- フト思ったんだが、、、
ひょっとしたらアンチデザパタってﾔｼは、設計時に無茶苦茶にデザパタを
適用した結果、設計結果とみんなのイメージが乖離してしまったという
暗い過去を持っているんｼﾞｬﾏｲｶ？
- 973 名前：デフォルトの名無しさん mailto:ｓage [2006/03/07(火) 00:18:43 ]
- そこで結城先生の登場ですよ。
>デザインパターンの目標の１つは、プログラムを再利用可能にすることです。
>つまり、どうやってプログラムを｢部品」として再利用するかを考えているのです。
>ですから、プログラム例を｢完成品」として見るのではなく、今後「機能を拡張していくもの」
>｢変更を加えていくもの」として見るようにしましょう。
> ・どのような機能が拡張される可能性があるか？
> ・その機能拡張を行うときに修正が必要になるのはどのクラスか？
> ・修正が不要なのはどのクラスか？
>このような観点でデザインパターンを見ると、理解が深まるでしょう。
- 974 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:36:28 ]
- ＞変更に強いかどうかってそんなに重要かぁ？
極めて重要だと思う。特に脱ウォーターフォールを標榜する今後のJavaの開発形態としては特に。
と、いうかJavaの抽象化フレームワークやJunitやEclipseの強力なリファクタリング機能が
何の為に存在するのかといったら、やっぱ「変更しないのが前提」、っていうウォーターフォールの一番駄目駄目な
部分を徹底的に唾を吐き、"いかにソースを良くしていくか"、"｢動いているソースは駄目ソースでも触るな」じゃなく
「ガリガリ直してどんどん洗練されたソースにリファクタリング」していくか"、
"余計なドキュメント製造に掛かるコストをカットする事で生ずるリスクをどこで吸収できるか"
等にあるわけで。
変更に強い、というのは客の仕様を満たすのと同じくらい重要だと思う。
- 975 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:49:56 ]
- 世の中には二種類のアーキテクトが居る。
一方のアーキテクトはアンチパターンを認識・検出・除去することが出来る。
残りのアーキテクトは日々新たなアンチパターンを生産することが出来る。
後者多すぎ。
- 976 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 03:20:30 ]
- >>969
いや、だから、どんな変更に強いってのか謎。
変更したらさ、設計がかわるんだよね？
ここはいいよね？
影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね？
普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
要はメインじゃなくて付加価値みたいなもんでしょ？
それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
プログラムってのはそれだけで気持ち悪いと思うんだ。
おそらく、みて理解のしやすいソースにはなっていない。
- 977 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:30:31 ]
- >>976
＞ いや、だから、どんな変更に強いってのか謎。
「十分予測できるが、現時点では詳細が不明な変更」ですな。
そこを押さえずに何でもかんでも変更可能にしてやろう、あるいはとにかくデザパタを
適用しようという発想がいかんのです。
＞ 変更したらさ、設計がかわるんだよね？
＞ ここはいいよね？
ここはＯＫ。 マクロな視点で見れば必ず設計は変わる。 しかしミクロな視点で
構成要素を一つずつ見ていき、影響が出る構成要素の数を極力減らす努力が
必要。
＞ 影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね？
変更内容が判らないというのであれば、その通り。 しかし裏を返せば、変更の匂いが
するところに対してデザパタを適用できるということ。
伝家の宝刀はここぞという時にしか抜いてはならない（とはいえ意外と多かったりするがなw）。
＞ 普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
それはダウト。 現状の静的なスナップショットを取っているだけのデザイナは、松竹梅で
言えば梅レベル。 そもそも現状のスナップショットをいくら睨んで見ても、そのどの部分が
変わりそうなのかといった情報は読みとれないものだ。 つまり「普通にそれぞれのクラスを
閉じこめるように作っていく」だけでは全然不足というわけだ。
- 978 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:31:26 ]
- （続き）
>>976
＞ 要はメインじゃなくて付加価値みたいなもんでしょ？
システムを作るだけ作ってそのまま逃げるような開発をするのであれば、現状のスナップ
ショットのみを用いて設計してもいいかもしれない。 （開発中に入ってくる要求変更と戦う
必要はあるが。） しかしその後の保守を考えると、変更に対する強度は極めて重要な
ことになるのだ。
＞ それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
＞ プログラムってのはそれだけで気持ち悪いと思うんだ。
＞ おそらく、みて理解のしやすいソースにはなっていない。
おそらく君が過去に接したシステムというのは伝家の宝刀を濫用したものなんだろう。
デザパタを適切に使用した場合のクラス図は、現状のスナップショットがどうなっている
のかという情報だけでなく、今後どういった部分が変化しそうなのかという情報もはっきりと
伝える判りやすいものになるのだ。
- 979 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:33:10 ]
- >>976
＞ 要はメインじゃなくて付加価値みたいなもんでしょ？
＞ それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
＞ プログラムってのはそれだけで気持ち悪いと思うんだ。
＞ おそらく、みて理解のしやすいソースにはなっていない。
俺も最近流行りのDIコンテナを利用した実装とインタフェースを分ける設計をみて
そう感じることがよくある。
IDEのデバッガでも追いづらいし、開発の効率を下げている一面もあるよな。
クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
やりやすい点ぐらいか・・・
オブジェクト指向本来のインタフェースの用途ではなく、
言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
- 980 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:51:27 ]
- >>973
＞ そこで結城先生の登場ですよ。
＞
＞ >デザインパターンの目標の１つは、プログラムを再利用可能にすることです。
＞ >つまり、どうやってプログラムを｢部品」として再利用するかを考えているのです。
注意すべきはここでの「部品」，「再利用」という表現ですな。
A, B, C, D, E, F, Gという7つのクラスで構成されたシステムがあったとする。
普通に「部品」というと、例えばCとかDというクラスを思い浮かべ，「再利用」というと
そういったクラスを他のシステムから利用することを想像してしまいがちになる。
しかし、デザパタのいう「部品」、「再利用」は違う。
デザパタでいう「部品」というのは、「Cというクラスから見た場合はA, B, D, E, F, Gと
いう6つのクラス」であり、Cが変更になった時にこれら6つのクラスに影響を与える
ことなく、「このシステム自体から見て6つのクラスを再利用する」ということだ。
- 981 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 08:01:01 ]
- >>979
＞ クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
＞ やりやすい点ぐらいか・・・
ユニットテスト時にモッククラスと入れ替えることができるということは、将来そのクラスに
対して変更があった場合、保守コストが引き下げられるということを意味しているはず。
＞ オブジェクト指向本来のインタフェースの用途ではなく、
＞ 言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
あなたの考えるオブジェクト指向本来のインタフェースの用途って何でしょう？
実装とインタフェースは無理矢理分けられてるのではなく、本来これらは別々のもので
あるべきなんじゃないかい？
- 982 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:17:18 ]
- >979
DIコンテナ使わないチームと使ったチームで比べられればいいけどね。
俺はもうDIコンテナなしの開発は考えたくないです。
まぁDIスレ(typoしてるが)でやるのが適切な話題だし、
あっち過疎ってるから盛り上げて欲しいってのが本音。
- 983 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 16:36:13 ]
- ＞将来そのクラスに
＞対して変更があった場合、保守コストが引き下げられるということを意味しているはず。
タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
よくあるのかな？
- 984 名前：962 mailto:sage [2006/03/07(火) 18:00:51 ]
- >>982
DIコンテナって使うとソース見やすくなったりとかするの？
DIコンテナって要は実装クラスをnewする部分をファクトリーじゃなくて、設定ファイルに書くみたいなやつだよね？
設定ファイルの情報を反映させたいときは再起動が必要みたいだから、
ファクトリーで書くのとあんま変わってないのであまり利点を感じないのだが…。コンパイルは不要だろうけど。
- 985 名前：981 mailto:sage [2006/03/07(火) 19:20:50 ]
- >>983
＞ タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
＞ よくあるのかな？
意外とよくある。 新規開発の際、客先がちゃんと要求を出せてない部分が
開発途中にガンガン決まっていくんだが、デザパタ使ってると楽に対応でき
るぞ。 その都度リファクタリングしてもいいんだが、新規開発時だとユニット
テストデータもちゃんと揃ってないから、その手があまり使えないんだわ。
どの部分が曖昧なのか、ちゃんと客先ヒアリングして頭使わないとダメだけどね。
- 986 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 19:29:23 ]
- 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
- 987 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 19:55:01 ]
- インタフェース設計レベルから変更を余儀なくされる要求が多いな。
- 988 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 20:10:10 ]
- >>976
極端から極端に走らなくてもいいじゃん
仕様に載ってない機能を搭載し、ファイル以外にDBやgmailやSubversionも保存先として使えるようにして
隠しオプションでどんな仕様にも即対応！ みたいのはそりゃだめだ
デザパタは問題の解決法として書かれていて
その問題があるときは割と的確な粒度の解決だと思うがどうだ？
あれでもまだ余分かな？
- 989 名前：981 mailto:sage [2006/03/07(火) 20:23:57 ]
- >>986
＞ 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
＞ デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
結構大変だけどね。 客先が「XXがYYという風に変わりそうだ」なんて自分から教えて
くれることはほとんどないけど、「ここがこうなるとかいうこと考えられます？」といった
聞き方を続けてると、答え方の雰囲気から変更されそうなところが見えてくる場合が多し。
で、実際に変更が発生すると、「実はそういうこともあろうかと、、、」と徳川機関長モードに
入る。
- 990 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:54:24 ]
- >984
この話題、DIスレにコピペしてもフォローしてくれますか？
(スレタイの意味での)デザパタとは全然関係ないと思うし。
＞ソース見やすくなったりとかするの？
それはないです。
>988
＞的確な粒度の解決だと思うがどうだ？
当方もそういう意識ですね。
そういう意味でもアーキテクトと言うよりは、
プログラミングレベルの話題だと思う。
フレームワーク作成チームが知っておくべきプラクティス。
- 991 名前：962 mailto:sage [2006/03/08(水) 01:21:50 ]
- >>990
＞この話題、DIスレにコピペしてもフォローしてくれますか？
いやいいっすわ。DIスレみてたら同じ疑問を持っている人がいて勉強になりました。
ありがとう。あっ、でもやっぱり聞いてみようかな。
>>986
漏れの理解ではだけど、デザパタは実装の入れ替えが容易というのが売りだと思ってるから、
プログラムのやることが変わったらデザパタで組もうがなんだろうが変更する量はさほど変わらないと思う。
ただプログラムのやることは同じだけど実装を変える。
例えばパフォーマンスアップのために仕様変更するというのであれば、
それは実装の変更であるから、そういう変更には予想してなくとも強くなれると思う。
- 992 名前：デフォルトの名無しさん mailto:sage [2006/03/08(水) 01:40:16 ]
- つーかさ、
ボタンクリックしたら、そのクリックしたメッセージが降りてくるその場所に
その処理が記述してあってほしい。（関数とかクラスとか）
そうでないと他の人間の書いたソースなんて追えない。
降りてきたメッセージをさらにどっかに飛ばす処理なんか入ってるともう駄目。
すげー面倒臭い。どうにかしてくれ。
単純に、ただ単純に書いて欲しい。
それだけ・・・それだけなんだ・・・orz
- 993 名前：986 mailto:sage [2006/03/08(水) 01:43:31 ]
- >>991
たとえ話になるけど 「１００Ｖコンセントがあれば、殆どの電化製品に対応できる」 とか考えて実装してると、
いざ 「実は、この家電アース線がついてるんだけど……」 ってなったときに、コンセント側も改造しなくちゃいけないな、
って話をしてみた。
アース線無い家電製品のみに限定するなら、いくらでも変更は可能。変更に強い。
ただしアース線だとか外国用の特殊形状だとかが変更で出てくると面倒になるってことで、
どこまで変更を予測するか〜って話だ。
ちなみに↑は Strategy を想定してみた。
解決策としては、Adapter が使えれば手っ取り早い。
どうでも良い。次ぎスレたのむ。
- 994 名前：962 mailto:sage [2006/03/08(水) 02:08:21 ]
- >>992
基本的には単純なものは単純に書くよｗｗ 必要になったときにしかデザパタは適用しないよ。
処理をたらいまわしにしている人のソースに悩まされてるの？たまにいるわなぁ。
デザパタだとかいって何でもかんでもたらいまわし処理書く人は。俺も追えない。30秒で諦める自信ある。
必要になった場合に適用すると効果を発揮するというのに、むやみに使うのは毒でしかない。
やるべき処理を素直にコードにすることが一番の解だというのに。
- 995 名前：デフォルトの名無しさん mailto:sage [2006/03/08(水) 02:22:21 ]
- マ板的な話題になってしまうが
とあるベンダが俺様フレームワークを作成して
基本設計の説明に加えて
「ここはあのパターン、ここにはあのパターンを使ってる。」
みたいなことをのたまって
最後にパターン名と適用の有無からなる
2列23行の表を見せて、こんなにたくさん○が付いてますよ
(使った(ことになってる)パターンを○でカウントする。)
みたいな感じで胸を張ってた。
手段が目的にすり替わってしまうと大体ロクな結果を導かんよね。
アンチパターンの表を作るのは意味があるかも知れん。
なんか盛り上がってきたし次スレ欲しいなあ。
- 996 名前：デフォルトの名無しさん mailto:sage [2006/03/08(水) 03:02:51 ]
- 手段のためには目的を選ばない。
- 997 名前：962 mailto:sage [2006/03/09(木) 03:33:36 ]
- では私が建てよう。ひっそりと深夜に。
- 998 名前：962 mailto:sage [2006/03/09(木) 03:39:13 ]
- ＞新このホストでは、しばらくスレッドが立てられません。
＞またの機会にどうぞ。。。
「【GoF】デザインパターン 6」で建てようとしたけど駄目でした orz
建てて誘導したいけど残り２レスしかない・・・。
- 999 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:28:57 ]
- 次すれ
「【GoF】デザインパターン 6
pc8.2ch.net/test/read.cgi/tech/1141846078/
- 1000 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:29:41 ]
- コピペミスで「が残ってたorz
- 1001 名前：１００１ [Over 1000 Thread]
- このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
|
 |
