　　　オブジェクト設計＆デザパタ　　　　　

1 ：オブジェ・デザパタ：2010/05/02(日) 22:28:28

結局、オブジェクト設計、デザインパターンを使えるのは、ジャカルタ・プロジェクトみたいな
優秀な集団だけなんだよね。
オブジェクト設計がどうした？　デザインパターンがどうした？　とアホ面してStrutsなど使って
たやつって何なのさ。StrutsのActionにスパゲッティソース書いていたので、Strutsが泣いていたよ。
大手の上位層の連中しか使わないのが、オブジェクト設計、デザインパターンなんだろうな。

と、上司に皮肉られた私である。
実際に、自作の、または参画しているプロジェクトで作成しているPGにオブジェクト設計、デザインパターン
を使っている天才諸君、どうやったら使えるようになるの？

2 ：デフォルトの名無しさん：2010/05/02(日) 22:37:59

設計って意図してやると言うより、自然に出来ている物だと思う。
デザパタとかの知識だけ増やしてもあまり意味無い様な…

3 ：デフォルトの名無しさん：2010/05/02(日) 22:50:45

情報工系の大学生なら普通に使ってるだろ。
とくにデザインパターンなんて単なる「あるある」のマトメなんだから、
天才とかどうとかじゃなくてプログラム書いてりゃ普通に身に付くし、よく考えたら当たり前のことだろ。
ジャカルタがどういう体制で開発してるかしらんが、ぬわんじゃこりゃってAPIのライブラリも結構ある。ぬわーファクトリふぬーファクトリクラスとかな（笑）馬鹿かテメェって感じだわ。

4 ：デフォルトの名無しさん：2010/05/02(日) 22:57:52

ま、たしかに言葉遊びのようなもんだけど
騙される方も悪いわな
私怨はマ板で

5 ：デフォルトの名無しさん：2010/05/02(日) 23:49:42

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

6 ：オブジェ・デザパタ：2010/05/03(月) 00:11:16

やはり、大手ＩＴ企業の天才様はこのようなスレには書き込んでくれないみたいだ。
寝ることにするわ。

7 ：デフォルトの名無しさん：2010/05/03(月) 01:58:49

>>5
頼むから、いちいちアイちゃんの言語訓練に2chを使うなよ。
人の迷惑とか考えないの？
京都大学霊長類研究所って無能の集まりなの？

8 ：デフォルトの名無しさん：2010/05/03(月) 02:01:38

アイちゃんが勝手に立てちゃったんだから
許してやって下さい

9 ：デフォルトの名無しさん：2010/05/03(月) 03:03:49

オブジェクト設計＆デザパタをやって、何かよくなると期待するのが間違い。
何をしようがよい設計をする人はよい設計をするし、
ダメな人はダメなんだから、良くも悪くもならないものだと考えておくべき

10 ：デフォルトの名無しさん：2010/05/03(月) 06:52:41

デザパタなんて基礎中の基礎だろ。
デザパタがわかるからといって、うまい設計ができるわけではない。
もちろんデザパタもわからんカスは設計なんてやるべきじゃない。

11 ：デフォルトの名無しさん：2010/05/03(月) 08:46:49

>>8
PC使わせるなよ、荒らし報告すんぞ

12 ：デフォルトの名無しさん：2010/05/03(月) 10:38:40

知ったかぶり多いな。

13 ：デフォルトの名無しさん：2010/05/03(月) 11:09:00

デザパタの話は大抵そうなる。

14 ：デフォルトの名無しさん：2010/05/03(月) 11:17:07

ほんとうにデザパタを使いこなしているやつらは２ちゃんには来ない。

15 ：デフォルトの名無しさん：2010/05/03(月) 11:21:23

使いこなすというほど大したもんじゃない。

16 ：デフォルトの名無しさん：2010/05/04(火) 13:45:44

>>1
>大手の上位層の連中しか使わないのが、オブジェクト設計、デザインパターンなんだろうな。

　たしかに上司の言う通り。いろんな会社にいったけど、まともなフレームワークを作れるは大
手のR＆D部署ぐらい（製品開発をやっている所ではない）だったな。そういう所は、勉強す
るの好きだったり、経費でコンサルを雇っていたりする。

　少なくとも派遣主体でころころ人が変わる所、休憩時間にゲームや漫画とか読むのが好きな
人が多い所で、そういう開発を実践できているところはいないなあ。

17 ：デフォルトの名無しさん：2010/05/08(土) 00:59:12

オブジェクト設計とかwww
デザパタとかwww
オブジェクト指向なんて不自由な環境にいるから余計なものを有難がってるって早く気づけよwww

18 ：デフォルトの名無しさん：2010/05/09(日) 22:19:16

>>17
大手のＳＥ，プログラマと接触してみる機会をもったら目から鱗です、よwo.

19 ：デフォルトの名無しさん：2010/05/09(日) 23:14:34

犬小屋作りからスカイツリーまで十把一絡げにする人がいる

20 ：デフォルトの名無しさん：2010/05/10(月) 07:07:08

犬子屋作りにオブジェクト設計、デザパタ適用を行う必要はない、と言われている。
そこそこの建物になったら使うべき。ちなみにデザパタは適用なのね。適用≠使用ではない。
レベルの低すぎる人は勉強しよう。という私も低いんだが。。。。

21 ：デフォルトの名無しさん：2010/05/10(月) 16:47:03

Strutsが悪い！

22 ：デフォルトの名無しさん：2010/08/29(日) 17:50:48

scheduled age
heigh ass hole ! happy?

23 ：デフォルトの名無しさん：2010/09/05(日) 13:54:24

>>20
それはおかしくね？
デザパタは別に、規模の大小に関わらず、
あるよくある問題に対する　伝統的解決法やテクニック的な解答の識別子　であって、
規模が小さいから使えないとか、大きいから有効とかって物じゃない。

オブジェクト指向についてなら、まぁ分からなくもないけど、
小さいからこそ、しっかりオブジェクト指向で設計しとくと
他への流動性が上がりやすいんだけどな。

あと、やたらと一からオブジェクト指向で設計せねば！みたいな印象をうけるけど、
リファクタリングの際についでに、とか、ひとまず最低限の要求仕様を満たしたから
次のステップの前に。とかでスクラップアンドビルド的にやる方がマトモだと思う。
つか、人間に一から完全を求めるのはいい加減やめるべき。　

24 ：デフォルトの名無しさん：2010/10/14(木) 02:17:36

デザパタはともかく、MVCをまともに実装してるのを見たこと無い。

25 ：デフォルトの名無しさん：2010/10/15(金) 14:25:38

>>24
まずは、Smalltalk-80のMVCのどこに問題があるのか、そこから語ってもらおうか。

26 ：デフォルトの名無しさん：2010/10/16(土) 00:40:52

>>25
Smalltalkはいいけど、JavaのMVCとか糞じゃん。
MVCで作りましたってコードは大抵ModelとControlerが破綻してるし。

27 ：デフォルトの名無しさん：2010/10/16(土) 06:25:38

MVCどうこう言うより、generics以前のJavaのフレームワークは糞。

28 ：デフォルトの名無しさん：2010/10/21(木) 22:39:16

Javaより、Cocoaのフレームワークの方が綺麗だな。

29 ：デフォルトの名無しさん：2011/04/10(日) 17:06:14.60

そもそもMVCは糞

30 ：デフォルトの名無しさん：2011/04/10(日) 17:18:16.54

>>29
ｋｗｓｋ

31 ：デフォルトの名無しさん：2011/04/10(日) 17:30:50.94

つうか、MVCなんていう30年も昔のフレームワークをドヤ顔で教えて自己満足してるオッサンが
オブジェクト指向の進歩を妨げているのだが、怖くで誰も言えない罠w

32 ：デフォルトの名無しさん：2011/04/10(日) 17:35:59.38

最新の代替案をkwsk

33 ：デフォルトの名無しさん：2011/04/10(日) 17:59:23.45

MVCよりはMVVMのほうが理にかなってると思われ。

34 ：デフォルトの名無しさん：2011/04/10(日) 19:01:33.83

AbstractionModel - DiscourseModel - InteractionModel

35 ：デフォルトの名無しさん：2011/05/04(水) 23:19:45.18

MVVMってControlerとModelが理解できず、VBのFormとクラス一体のスタイルから抜け出せない馬鹿向けじゃん。

TextModel text = new TextModel();
Menu copyMenu = new Menu();
TextArea textView = new TextArea();
copyMenu.addAction(new TextCopy(textModel,textView));

　例えばこのコードなら、TextCopy Controlerは、ViewとModelが変わっても使いまわしし続けられるけど、
MVVMモデルだと組み合わせごとにTextCopyを毎度ViewModelやらに書くわけだろバカバカしい。

36 ：デフォルトの名無しさん：2011/05/05(木) 00:09:12.85

香ばしすぎるｗｗｗ

37 ：デフォルトの名無しさん：2011/05/07(土) 17:55:55.82

MVPの質問(相談)ってここでいい？

Presenterって、Viewを構成するコントロールの具体的(物理的)な種類に
依存すべきでないでない認識だけど、あってる？

たとえば、View上の数値入力欄がただのテキストフィールドなのか、スピンコントロールなのか、
はたまたスライダーコントロールなのかを、Presenterは知らなくていいよね？

38 ：デフォルトの名無しさん：2011/05/13(金) 19:38:05.08

知らなくていいと思います。
ただeventから取れる場合はともかく、selfから取る場合には、
実装(というか処理系というか)により適切なコントロールの具象にキャストしないとダメかも知れません。

39 ：デフォルトの名無しさん：2011/10/02(日) 20:07:07.00

次スレここか？

リーナスのお言葉（青い部分がリーナスの言葉）
http://tabesugi.net/memo/2009/1a.html#152154

40 ：デフォルトの名無しさん：2011/10/05(水) 04:08:26.73

オブジェクト指向のこころ読み始めたけどよくわかんねえ

41 ：デフォルトの名無しさん：2011/10/08(土) 19:20:18.35

オブジェクト指向スレは3スレ目位で話題がなくなるな
前あったOOPスレも3スレで終わったし

42 ：デフォルトの名無しさん：2011/10/08(土) 23:28:11.32

>>41
ちょうどむだなOOPゴミスレも掃除できたし良かったんだよ。
次はここを消費してOOPが消えればいいかも爆

43 ：デフォルトの名無しさん：2011/10/12(水) 20:29:02.44

commandやobserverパターンなど、デザパタのうち幾つかは
クロージャとか関数オブジェクトを採用すると不要になったりしないかね？

44 ：デフォルトの名無しさん：2011/10/12(水) 20:33:43.47

方法そのものが無くなるわけじゃないけど、
「forループ」にわざわざパターン名を付けないように、
言語レベルで概念が用意されてれば、その世界では
パターン名は不要だね。

45 ：デフォルトの名無しさん：2011/10/12(水) 20:34:04.98

functional design patternとかでググったら色々要らなくなったよって記事が出てきたはず(英語)

46 ：デフォルトの名無しさん：2011/10/12(水) 23:04:40.99

>>43
名前は忘れ去られるかもしれないが、考え方自体はなくなるのではなく、新たな言語パラダイムが作用して、別のパターンがうみだされるんじゃないかな。

47 ：デフォルトの名無しさん：2011/10/13(木) 15:19:06.77

オブジェクト指向設計とデザパタを勉強中の者です。
オブジェクト指向設計とデザパタは大手企業はガンガン使いこんでいるが、
一般的には使われていないのではなかろうか？　と最近思い始めています。
使えなくて使わないのか、短納期で設計の時間がなくて使わないのか、
いまいち、その辺の事情がわからんです。
まさか必要がないと判断されているのぉ？？？

情報通の方、この点について教えてください。

必要がないならこんな糞難しいものを勉強するのはやめます。

48 ：デフォルトの名無しさん：2011/10/13(木) 16:12:04.51

頻出問題に対する一般解答だと思ってくれればいいよ。

49 ：デフォルトの名無しさん：2011/10/13(木) 17:15:07.54

頻出問題に対する一般解答
うまいこと言うね

デザパタは特定の頻出問題についての上手な実装方法だから
局所的に使われる傾向がある（シングルトンにする必要があれば使うし、なければ使わない）

オブジェクト指向設計ってのは「設計方針」なんで広く浅く普及してると思うよ
今時のフレームワーク使ってたら自然と（とはいえ漠然と）身についてると思う

50 ：デフォルトの名無しさん：2011/10/13(木) 18:54:19.07

シングルトン使う奴はテストを考えていないイケヌマだと思う

51 ：デフォルトの名無しさん：2011/10/13(木) 22:33:30.95

シングルトンはどうでもいいやｗ
あれはデザインパターンの練習問題みたいなもの。

シングルトンにしたければフレームワーク側で
制御してくれる。

52 ：デフォルトの名無しさん：2011/10/13(木) 22:44:15.72

>>47
どんな問題があって、それをどのように解決してるのかだけ、ざっくり頭に入れとくといいよ
じっくり学ぶのは必要になってからでいいじゃん

53 ：デフォルトの名無しさん：2011/10/13(木) 22:48:33.15

> オブジェクト指向設計とデザパタは大手企業はガンガン使いこんでいるが、
> 一般的には使われていないのではなかろうか？　と最近思い始めています。

逆じゃね？ｗ

大手ほど安い外注に出し、安い外注は安いだけが売り物。
技術は低い。大手だからそんなんでもやっていける。

中小のほうがよっぽどデザパタ使ってるだろ
自分の技術力が即会社の存続にかかってくるんだから。

54 ：デフォルトの名無しさん：2011/10/13(木) 22:59:57.30

有る程度以上フクザツなもんをスッキリ書こうとしたり、
柔軟さをもっと持たせようとしたら悩むっしょ？
糞設計を山ほど繰り返し、日々悩むっしょ？
そこで手に取るもののひとつがデザパタにすぎない。

設計道の一歩目にすぎない。

55 ：デフォルトの名無しさん：2011/10/13(木) 23:02:08.95

コールバックを関数ポインタとは言わんからな。
ラムダを自然に使えるようになっても、commandだのobserverだの
名前は使われるんじゃね。

56 ：デフォルトの名無しさん：2011/10/14(金) 15:12:01.84

>>53
取引相手から金貰うやり方にもよるんだと思うよ。
大企業を相手にソースをリリースしていると「何か変更を加えたときに混入するバグ」を恐れて硬直化する。
修正するのに一々マニュアルまであったりしてオーバーヘッドがすごくなる。

俺が前居た会社だと、一案件変更しようとする毎に
・見積もり書
・外部仕様書
・内部仕様書
・単体試験仕様書
・組み合わせ試験仕様書

をかっちり書かされて大変だった。更に各ドキュメントのページ数やらも管理する。
そのドキュメントでも金貰えてたんだけど。

んなことやってるからリファクタリングなんて夢のまた夢って感じだった。

57 ：デフォルトの名無しさん：2011/10/14(金) 15:32:28.38

俺はコメントの修正前のコードを残すルールのある会社の仕事したことある
コメントアウトされた修正前のコードがどっさり

58 ：デフォルトの名無しさん：2011/10/15(土) 08:04:33.82

>>57
なにかバージョン管理システムを使えばいいのにね。

59 ：デフォルトの名無しさん：2011/10/23(日) 22:44:02.16

オブジェクト指向設計をきちんと覚えたい。
実際に設計しながら覚えたいんだけど，良い例題（と模範解答）はないでしょうか。

入門サイトを見ると，「1+2*3」みたいなのを計算するプログラムが挙げられたりするけど，
その程度だったら再起関数で済むと思う。
わざわざ演算子のInterface定義して，Plus型MINUS型のcalc()を実行！
みたいなサンプルを見かけるけど全然参考にならない。

60 ：デフォルトの名無しさん：2011/10/23(日) 23:21:26.98

>>59
優れた設計を学ぶには優れた設計に触れるしか無いが、何が優れた設計なのかは実は誰もわかってない。
オプソにしても何を見て学べばいいのかわからないし。

61 ：デフォルトの名無しさん：2011/10/24(月) 00:09:47.57

>>59
ひとまずデザパタ見れ。
関数型の考え方などから見ると古かったり必要のないものもあるけど、未だにオブジェクト指向のエッセンス詰まってると思う。

62 ：デフォルトの名無しさん：2011/10/24(月) 03:03:55.97

>>59
デザパタとリファクタリングは車の両輪
リファクタリングがうまくなったら自然とうまい設計がわかってくる

63 ：デフォルトの名無しさん：2011/10/24(月) 12:43:31.08

>>59
実例はフレームワークのソース見るといいよ。手始めには辛いかもだけど、javaのcollection frameworkなんてどう？

64 ：デフォルトの名無しさん：2011/10/24(月) 13:31:22.98

>>62
同意。OOPの理解を深めようとするのなら、その二つはまさに両輪。

ただ、悲しいかな、それをつきつめた先に設計の極意があるか、
自分の設計力を高みに持っていけるかというとそれはまた別。

どこまで行ってもクソ設計を繰り返すことになるだろう。
それは、個人の設計力、設計センスよりもいつだって、
プログラミングすべき問題のほうがややこしいから。

65 ：デフォルトの名無しさん：2011/10/24(月) 22:10:17.46

そうかなあ。
デザパタなんてコロンブスの卵にしか思えんけど。
恐らく散々言い尽くされたことだと思うけど、デザパタには確かに意義があるが、
それは技術サンプルとしての意義じゃなくて、コミュニケーションツールとしての意義だよ。

「ここは○○パターン的な発送で作ってあるよ」と言う事で、意思疎通のコストを縮減できる、
それがデザパタの意義であって、それ以上でも以下でもない。

66 ：デフォルトの名無しさん：2011/10/24(月) 22:29:47.86

まぁまぁ。そう視野を狭めちゃ勿体無いよ。
騙されたと思ってパターン指向リファクタリング入門読んでみ？

67 ：デフォルトの名無しさん：2011/10/24(月) 22:32:34.22

>65
今のご時世、プログラミングを始めたときにはすでにデザパタが常識になってたって奴もいっぱいいて、
実際そいつらは、デザパタを通して設計を学んでるわけで

ていうか「意義」をひとつに決めようとする必要ないし

68 ：デフォルトの名無しさん：2011/10/24(月) 23:46:51.92

デザパタは基礎知識としては重要だけど、それを通して設計を学ぶ類のものでは無いと思う
より上位の設計があって、その設計を実現させるための手段としてデザパタがあるという印象
で、>>59が求めているのはそういう上位の設計なんじゃないか？

69 ：デフォルトの名無しさん：2011/10/25(火) 00:00:49.98

俺の見た限りデザパタのカタログ的用法は疑わしい。
なぜなら、多くの人にとってのパターンの理解度が単に疑わしい。
その定義やメリットについてMLなどでわりと揉めちゃってるのを見る。
例えば、JavaHouseのログを見るといい。Factory Methodパターンなど。

ほかにも、実際２ちゃんでもAbstruct Factoryパターンを、
単なるファクトリメソッドのオーバーライドとして理解している人を見た。

これらは、カタログとしてデザパタが失敗しているというよりは、
やっぱデザパタそのものの理解が難しい、
さらにやっぱり、そもそもスカッとした設計自体が難しいってことと思う。

でなもんで、おとなしく学習のツールとして使うのもどんどん推奨されるべき。

70 ：デフォルトの名無しさん：2011/10/25(火) 00:02:35.14

誰が何から設計を学ぶかは君の決めることではないと思うが
選択肢を増やす意見ならともかく、出た案を否定することに意味はあるのか？

71 ：デフォルトの名無しさん：2011/10/25(火) 00:08:41.30

interfaceの考え方がピンとこなかった初心者が、デザパタを学んでなるほどと思う
またよろこばしからずや

72 ：デフォルトの名無しさん：2011/10/25(火) 00:22:48.10

>>70
デザパタを学んだことで設計を学んだと勘違いしてしまうと、むしろ害があると思っているから
否定しておきたかったってのはある。

害っていうのは、本来はパターンを使わない方が自然であったり、使うべきでないところに無理やり
パターンを当てはめてしまうようなことがあること。
たぶんデザパタを学んだ多くの人は経験していると思うんだけど。
それを踏まえた上で勉強する分には構わないと思う。

代案を出せればいいんだけど、良い方法を自分も知らないから…。

73 ：デフォルトの名無しさん：2011/10/25(火) 00:30:01.63

>>72
> 害っていうのは、本来はパターンを使わない方が自然であったり、
> 使うべきでないところに無理やりパターンを当てはめてしまうようなことがあること。

結局ね、実害がない限りそういうのもドンドンやってみるべきなんだよ。
そんでもって、学ぶ。どうまずいのか、どう不自由になっていったのか学ぶ。

そもそも、デザパタ単体で学ぼうとして挫折したやつ多く見た。
小さいサンプル書いてみたところで何が学べようか。
個々のデザパタが何をそれぞれ解決してくれるのかを学ぶには、
デザパタ適応以前の苦痛をしっておきたいところ。納得度が違う。

設計＆デザパタ＆リファクタでもんどりうちながら学ぶ。
いつでも学ぶ。いつでも臭い設計になっちゃうのでまた学ぶ。
悪い設計を目の前にして、右手にデザパタ本、左手にリファクタ本で学ぶ。

74 ：デフォルトの名無しさん：2011/10/25(火) 00:30:51.53

きれいに実装されたテンプレートパターンなんて見たことねーよ。
単純に if 分岐で関数切り出しでもされてた方がよっぽど見やすいわ。

テンプレートパターンがうまくいくのは
「具体的には違う処理だが抽象的には同一の処理」の塊が
長く続いてるコードだと思うんだがそんな都合のいいシチュエーションって
そうそうないだろ。

75 ：デフォルトの名無しさん：2011/10/25(火) 00:40:15.32

自分の経験を一般化しすぎるのはどうかと思うが
「俺は綺麗に実装されたテンプレートパターン見たことあるぞ」と言う奴がいれば根拠崩れるぞ

>>73
自分も同趣旨の事書きかけてたけどそっちの方が文章うまいね

76 ：デフォルトの名無しさん：2011/10/25(火) 00:50:30.21

>>74
少なくともif分岐はないわ-
テンプレートパターンは、今は具象インスタンスから可変ポイントになるもののラムダを渡して実行って感じになってるがやってることは一緒。

77 ：デフォルトの名無しさん：2011/10/25(火) 02:53:17.39

そもそもデザパタは局所的に使う物でしょ
「この部分は○○パターンでここのこの部分は…」みたいな
使える所があれば使えばいいし、出番が無いこともある

そういうものなんで、リファクタリングしながら適用するのはいいと思う

78 ：デフォルトの名無しさん：2011/10/25(火) 07:45:12.50

色々アドバイスありがとう。
デザパタについては，浅く理解していると思う。
ただ，デザパタを実際の設計に結びつけれるほどは理解していない。
結びつけられるようになればレベルアップのような気がして，
まずはデザパタも含めて「良い設計」の実例を見てみたかった。

JavaのCollectionFramework参考にしたいと思う！
他にも何か良い例があれば教えて下さい。

79 ：デフォルトの名無しさん：2011/10/25(火) 08:16:12.77

>>74
Template Method(の事だよな？)は、Straregyのように同一インターフェースだが、多くの実装のバリエーションがある場合に、骨格抽象実装(スケルトンクラス)として、よく利用している。
(つづく)

80 ：デフォルトの名無しさん：2011/10/25(火) 08:18:00.91

例えば、呼び出し元からメソッドの最後で実行して欲しいコールバック関数が渡された場合に、
全ての末端のクラスでnullチェックして、実行って記述すると冗長なので、共通部分をスケルトンクラスに移管させ、
バリエーション記述のためにprotectedなabstractメソッドを用意しておく。
末端のクラスはこの抽象メソッドを実装するといった感じで。

これに限らず、「インターフェースースケルトンクラスー実クラス」という形は結構でてくるものよ。

81 ：デフォルトの名無しさん：2011/10/25(火) 09:48:44.85

>>77
＞そもそもデザパタは局所的に使う物でしょ

デザパタに出てくるものってソフト全体に絡むと思うぞ。大きいものから小さいものまで。
その意見をとやかくいうのではないけど、そういう捉え方をする人がいる人にビクーリした

82 ：デフォルトの名無しさん：2011/10/25(火) 09:57:35.71

デザインパターンを構成要素としてより大きなパターンが出来てるだけじゃないの？
アーキテクチャパターンとか聞いたことない？

83 ：デフォルトの名無しさん：2011/10/25(火) 10:23:46.45

ぶっちゃけ言うとデザパタもアーキテクチャパターンも本質は同じだと思ってる。
両者を明確に区別すべき理由はないでしょ。

84 ：デフォルトの名無しさん：2011/10/25(火) 10:32:18.95

コードから出てきたのがデザパタ
コード書かずに図を弄ぶのがアキパタ

85 ：デフォルトの名無しさん：2011/10/25(火) 11:26:09.36

デザパタの
拡大解釈
やな予感

86 ：デフォルトの名無しさん：2011/10/25(火) 20:09:48.47

リファクタリングを繰り返して物凄く汎用性高い設計
あまりレベルの高くないプロジェクトメンバーでも長期に渡って保守可能な設計

これらは両立しなくてどっちも大事だと思うんだけど，両方上達する方法ない？

87 ：デフォルトの名無しさん：2011/10/25(火) 20:32:03.03

物凄く汎用性高い設計なんてものを、
まずお目にかかったことが無いｗ

88 ：デフォルトの名無しさん：2011/10/25(火) 21:02:02.72

リファクタリングなんて必要なとき必要なだけやれば十分、汎用性なんて気にしなくていい
長期に渡って保守しておいてレベルの低いままのメンバーなんて切ればいい
下手糞が保守できるからいいソースとは限らない

→どっちも大事じゃない

89 ：デフォルトの名無しさん：2011/10/25(火) 21:08:22.36

>下手糞が保守できるからいいソースとは限らない

ココロに響くお言葉

90 ：デフォルトの名無しさん：2011/10/26(水) 15:29:24.80

せっかく保守・拡張しやすいように考えて書いたソースでも
それがわかんない人はどういう変更してくるかマジわからんし。

前の会社で、俺が設計・コーディングして、手を離れたやつに機能追加しようとした先輩がいてさ。
うまくいかないってソース持ってこられて（！）見てみたらコレが酷いのなんの。

俺「そこはサブクラス追加だけで良いですよ、そういう風に変えたら広範囲に悪影響あります、…（しばらく駄目出し）」
先輩「…全然駄目ですか」
俺「駄目駄目です」

91 ：デフォルトの名無しさん：2011/10/26(水) 15:58:40.97

>>90
それは先輩もあれだが、正しくドキュメントとか残したん？

92 ：デフォルトの名無しさん：2011/10/26(水) 16:36:25.67

設計思想ってのはドキュメント化しにくい上に工数認めてもらえないこと多くね？

93 ：デフォルトの名無しさん：2011/10/26(水) 16:54:45.34

コメントで「〇〇〇パターン使ってます」って書いときゃ大体伝わる。

と思ってた時期が以下略　

94 ：デフォルトの名無しさん：2011/10/26(水) 17:11:32.92

>>93
(ヾﾉ･∀･`)ﾑﾘﾑﾘ

95 ：デフォルトの名無しさん：2011/10/26(水) 21:16:31.08

>>91
>92-94が正にそん時の状況を表してるw
一応、設計中に作成したメモ書きよりは上等程度のんは残してたけど。

まさか数キロステップ程度のプログラムで悩まれるとは思わんかったし、
彼もOCPとLSPが分かってたらやっちゃいけない事くらい分かったろうし…。
他にやる事あったのにそこまで面倒見切れんかった。

96 ：デフォルトの名無しさん：2011/10/27(木) 00:40:23.24

そういうのは実際にコードを見てみないと何とも言えない
その先輩のようにOOに疎い人は確かに多いんだけど
自信ありげに語ってる側もまた酷いコードを書いてることが多い

97 ：デフォルトの名無しさん：2011/10/27(木) 01:20:27.66

あるある。かなり、あるある。

98 ：デフォルトの名無しさん：2011/10/27(木) 05:51:20.24

自信満々でコメントの一切無いソース見せられたことある
しかも変数名や関数名は母音抜き

99 ：デフォルトの名無しさん：2011/10/27(木) 06:31:09.36

>>98
コメントはちょっと扱いが難しい。コメントが嘘をつくことがあるから。
つまり、コードの改変にコメントが追いつかないことがある。

コメント書かないほうがまし、と思うことが最近多くなってきた。

100 ：デフォルトの名無しさん：2011/10/27(木) 07:32:32.83

>>90
下に合わせてもキリがないのはすごく分かる。
設計思想を理解してもらう部分にコストが掛かるから難しい。
作り手は工数かけてドキュメント作成しなきゃいけないし，
その後も更新に合わせて整備しないとぐだぐだになる。
かといってドキュメント残さないで設計思想を安定して読み解ける人は
安定供給されないｗ

シンプルに作った時の問題点が多くなかったり別の解決が出来るならシンプルに
作った方が良い時もあると思う。シンプルってなんだ？っていうのは置いといて。
例えば，使われる側のクラス設計的に問題があって，使う側に少し制約が付くとしても
変に複雑にクラス設計するよりシンプルにつくって何らかの台帳で制約を共有するとかね。

>>99
それ凄く多い。
あと少し違うかもしれないけど，
顔合わせない派遣さんとかが付けたSVNのコメントも混乱の要因になったりする。

101 ：デフォルトの名無しさん：2011/10/27(木) 08:57:01.35

シンプルって俺は「同時に憶えておかなければならない範囲が少ないこと」としておくけど、
オブジェクト指向原則ってプログラムをシンプルに保つためのもんだよね。
LSPに沿っていれば、あるインターフェースでオブジェクトを扱う使用側は個々の具象クラスの事に気を使う必要はない、とか。

シングルタスクで記憶容量の少ない、低クロックCPUの俺のような奴にこそオブジェクト指向原則は必要だと思う。
それに沿って作られてるだけで頭に掛かる負担が全然違うし。

102 ：デフォルトの名無しさん：2011/10/27(木) 08:57:10.40

コメントもなーｗ

// メインループ
// テンポラリ変数
// イテレータ
// 文字列をコピー

↑こーいうｗ

103 ：デフォルトの名無しさん：2011/10/27(木) 13:31:26.33

>>99
コード直すときにコメントも直すだろ

コードと一緒にコメントも直す習慣が無いやつが書いた
ワードやエクセルのドキュメントなんて信用できるのか？

104 ：99 ◆QZaw55cn4c ：2011/10/27(木) 20:53:18.37

>>103
根本的解決になっていない。
コメントがコーダに及ぼす影響を考慮すると、コードの内容に即したコメントになっているかどうかをコンパイラがチェックできなければならない。
それができないのならばコメントはいらない。

コード直すときにコメントも直すだろ、という精神論は竹槍でB29を落とし、バケツリレーで焼夷弾を消火せんばかりの旧日本軍的思考となんらかわりない。

105 ：デフォルトの名無しさん：2011/10/27(木) 21:16:08.44

>>104
心情的に同意したくはあるんだけど、もうちょい穏やかな言い方にならん？

プログラム書いてるときとドキュメント書いてるときって脳の使うとこが違うよね
「なんかの作業してて調子が出てくるのに2時間くらいかかる」ってどっかで聞いたことある（気がする）けど、
それでいくとプログラム・ドキュメント並行作業ってあまり良くない気がする。
と言って、交互にすると抜けはどうしても出てくるだろうし。

…ってオブジェクト指向もデザパタも関係ない話になってきてね？

106 ：99 ◆QZaw55cn4c ：2011/10/27(木) 21:33:37.10

>>105
失礼しました。ただ >>103 にあわせるとこうなってしまいました。（私の本音は >>99 を参照ください。）

107 ：デフォルトの名無しさん：2011/10/27(木) 21:43:40.97

自分の書いたコードを読むのが、コメントなしでもコードの意図を汲み取れる人だけなら
コメントなんて書かなくてもいいんじゃね

レベルの低い奴が修正する可能性があるってわかってるのにコメントを書かないのなら、
設計思想を無視した修正をされても黙ってろってかんじ

108 ：デフォルトの名無しさん：2011/10/27(木) 21:54:55.95

QZらしからぬ煽り耐性の無さだなｗ
宿題スレで金儲けはもうやらんの？

109 ：デフォルトの名無しさん：2011/10/27(木) 22:16:28.03

コメント付けただけでレベル低い奴が無茶苦茶すんのを阻止できるとでも？
そもそも設計思想なんてコメントで残すものでもない。

110 ：デフォルトの名無しさん：2011/10/27(木) 23:21:45.71

そんなにコメントって頻繁に直す必要が出てくるか？

111 ：デフォルトの名無しさん：2011/10/27(木) 23:24:58.23

リファクタリングしてるとクラス自体が出来たり無くなったり、
結構ダイナミックに変わると思うけど

112 ：デフォルトの名無しさん：2011/10/28(金) 00:11:54.25

そういう場合は丸ごと消したり付けたりするから嘘を付いてるような状況にはなりにくくないか

113 ：デフォルトの名無しさん：2011/10/28(金) 00:24:18.81

i--; // iをインクリメント
i += 3; // iに5を足す

114 ：デフォルトの名無しさん：2011/10/28(金) 00:34:37.01

コメント無いと他人がみても何やってるかわからない様なプログラム書けてこそのプログラマーだろ？
誰でも読める様なソースはプログラムじゃなくて、だだのマクロだよ。

115 ：デフォルトの名無しさん：2011/10/28(金) 02:30:42.77

釣り針は置いといて、俺はむしろ自分のためにコメントを書くぞ。
そのほうがトータルコストは低くなる。ソースの頭に色々と関連した前提を長々と文章で書いてる。
あとはややこしいところに一目でわかるように意図を書いてる。

116 ：デフォルトの名無しさん：2011/10/28(金) 07:45:26.37

トータルのコストで考えないとね
必ず書くとか絶対書かないとか、ただの思考停止

117 ：デフォルトの名無しさん：2011/10/28(金) 07:46:15.80

>>114
職人的発想だね。
商業漫画家の中にアマチュアだけど物凄い技術ある漫画家が混じってくるような感じ。
商業的な観点で保守性考えたときに，果たして最良のコードかどうかをよく考えた方が良いと思う。
考えた上で最良と判断したならそれでいいだろうけど。

>>115
それで上手くいくかは何人でコード書いてるのかによると思う。
「自分のためのコメントだから！」とか言って15人ぐらいがそれぞれ我流のヘッダ付けて
我流のコメント入れてたら嫌だね。

118 ：デフォルトの名無しさん：2011/10/28(金) 14:56:12.47

15人が一つのソースいじるような案件なら
コーディング規約にコメントルールもある…よな？

119 ：デフォルトの名無しさん：2011/10/28(金) 16:00:05.09

コメントなんてそこで何やってるかの意図がわかればいいんであって、一目見ればわかるような関数に定形でパラメータが何だ戻り値が何だとか書くのも書かせるのもやめていただきたい。
少人数で開発できて幸せだわ。
軍曹みたいな現場に放り込まれたら一日で切れそうだｗ

120 ：デフォルトの名無しさん：2011/10/28(金) 21:39:27.42

前んとこで抽象クラスを介していろんな具象クラス同士が緊密に結合してるプログラム見て発狂しそうになったよ。
どのクラスも単独で使えなくて、CppUnitとか全然入れられないの。
単体も組み合わせも全てIDEでステップ実行のホワイトボックステスト（それしか出来ない）で、
自動化？なにそれ？みたいな感じ。

121 ：デフォルトの名無しさん：2011/10/29(土) 18:52:41.79

テストが自動化できるような部分て、自動生成できるような機械的なコードの部分だから、テストの自動化で大幅に生産性が上がるシステムはそもそもコードの記述が冗長で糞。

122 ：デフォルトの名無しさん：2011/10/29(土) 23:09:03.35

自動化プログラムの下の世話のが手間かかるんだよな
「あ！止まった！」
とか思ってもだいたい自動化プログラムのエラーだったりねｗ

123 ：デフォルトの名無しさん：2011/10/30(日) 08:04:36.83

> テストが自動化できるような部分て、自動生成できるような機械的なコードの部分

へー、ユニットテストっていつ自動生成できるようになったの？

124 ：デフォルトの名無しさん：2011/10/30(日) 09:36:47.46

単体テストを自動生成するツールは存在するよ
ttp://www.techmatrix.co.jp/quality/ctest/index.htm
ttp://www.aicp.co.jp/products/cantata.shtml
とか。

使った事ないから適当言うけど、まぁソースから生成するんだろうから
生成されたテストケースが要件に沿っているかから検証し直さんといかんのだろうけど。

でも、そんなツールをどこの職場でも導入しているかつーと話は別だよね。
前んとこは結構大企業だったが、そんなツール導入はしてなかった。

125 ：デフォルトの名無しさん：2011/10/30(日) 09:45:52.75

>>123
UWSCとかbot御用達の技術
企業だとユニットテストに使われてる

126 ：デフォルトの名無しさん：2011/10/30(日) 09:48:44.01

あ、ごめん。lが抜けてた。
ttp://www.techmatrix.co.jp/quality/ctest/index.htmｌ

127 ：デフォルトの名無しさん：2011/10/30(日) 09:52:04.88

>>126
なんかどこおしてほしいのかわかんない
わざわざh抜く必要もないんじゃない
それかGoogleで先頭に出るキーワード貼ってよ

128 ：デフォルトの名無しさん：2011/10/30(日) 09:58:02.60

度々すんません。最後の小文字Ｌが全角になってたようで。
http://www.techmatrix.co.jp/quality/ctest/index.html
でした。

それぞれ
C++test
Cantata++
でググレば出てきます。

129 ：デフォルトの名無しさん：2011/10/30(日) 10:39:33.84

>>120の言ってる自動化は
自動生成のことじゃないだろ

130 ：デフォルトの名無しさん：2011/10/30(日) 10:56:45.44

>>125
自動生成じゃない

131 ： ◆QZaw55cn4c ：2011/10/30(日) 14:00:52.26

>>108
金儲けじゃありませんモリタポ儲けです（棒）

132 ：デフォルトの名無しさん：2011/10/31(月) 23:12:36.75

>>129
あー、うん。用意した一連の単体試験をガーッと実行させてOK/NG出させるのを自動化って言ってた。

ソースコードの1ステップずつの動作を日本語で書き直した、

関数XXXX
期待動作　　　　　　　　　　　　　　　確認結果
aaa = getXXX();　を実行する　　　　OK
aaaがNのとき
　o->setInfo(aaa); を実行する　　　OK
aaaがそれ以外のとき
　retが0であることを確認する　　　　OK
　：
　：

みたいな試験仕様書を延々とVC++のステップ実行＆ウォッチで目視確認してたもんで。

133 ：デフォルトの名無しさん：2011/11/01(火) 22:44:42.89

FORTRANでもできそうな、スレタイと全く関係ない流れだな・・・

134 ：デフォルトの名無しさん：2011/11/02(水) 08:56:32.89

しまった。スレタイに関係ある話題に引き戻そうとネタ振ったのに…

テストを自動化するときって元プログラムの方にもある程度の良設計求められるし、
テストしやすくするためには多少詳細を弄らなければならなくなることもあるでしょ。
ところが元プログラム弄るのは仕様追加・変更・修正などの案件があるときのみ、
みたいな縛りがあって、それもままならなかった。

　リ　フ　ァ　ク　タ　リ　ン　グ　、　さ　せ　て　く　れ

と思ってたら、そのうち冗談みたいな一大プロジェクトが出てきた。

　リファクタリングしましょう！

スケジュールに「リファクタリング」の文字が組み込まれ、
そのための打ち合わせが増えた。

135 ：デフォルトの名無しさん：2011/11/03(木) 01:11:46.70

アホくせ
もう十年以上ＰＧやってるけど業務のソースみるとなにが「いい」のかまったく基準がわからない
俺の個人的な基準だとwin32レベルの知名度のあるライブラリでもないのに
グローバル変数や関数使った時点でアウトだけど
平均レベルただよってるレベルのひっくいＰＧじゃ俺のいってることさっぱりわかんねーだろーな

136 ：デフォルトの名無しさん：2011/11/03(木) 01:52:47.80

コードレビューとか長年やってるだろうに説明下手すぎ
そのレスでわかれっつー方が無理

エスパーしてみるけど、
・135は知名度の低いライブラリの開発に従事している
・そのライブラリはグローバル変数や関数を使っている
でおｋ？

137 ：デフォルトの名無しさん：2011/11/03(木) 02:16:14.66

>>136
アホくせ
わからないなら黙ってろよ
わからないんだろ？

138 ：デフォルトの名無しさん：2011/11/03(木) 10:25:28.48

放っておけ
文章から知性の低さが滲み出てる上に
俺のエスパーによるとオブジェクト指向とは関係ないから

139 ：デフォルトの名無しさん：2011/11/03(木) 12:41:57.54

オブジェクト指向スレでWin32とか言ってる時点でお里が知れる(´・ω・｀)

140 ：デフォルトの名無しさん：2011/11/03(木) 12:44:01.64

しかもWin32はライブラリではなくてAPIだよね。

141 ：デフォルトの名無しさん：2011/11/05(土) 08:16:43.72

>>135の言い方だとwin32くらい知名度のある場合は、グローバル変数を使って良いということか？
よくわからん・・・

コンパイラが必要だな

142 ：デフォルトの名無しさん：2011/11/06(日) 00:51:07.47

>>141
おう、いいぜ
仕様も挙動もみんなが把握している場合に限りなんでもオッケーだと思う
ただし、マイナー・・・特に自分ライブラリなんてそんなもん誰もしらんから自重してほしい

143 ：デフォルトの名無しさん：2011/11/06(日) 09:20:08.66

クラス図とかシーケンス図とか作成している人、このスレにいますか？
いないような気がするのですが。

144 ：デフォルトの名無しさん：2011/11/06(日) 10:11:17.72

クラス図は、ある程度コードを書いた後にリバースで出力します。
シーケンス図は客から要求されない限り書かないですね。

実装レベルでは、素直にコールグラフをスケッチする方が分かり易いと思ってます。
シーケンス図はその名のとおり呼び出しの時系列を追えるところがよいのだと思いますが、
ごく普通に構造化されたコードなら、ほとんどの場合「シーケンス」は一目瞭然。
図を描かなければ理解しにくいのは、むしろ深い呼び出しの階層構造だと思います。

145 ：デフォルトの名無しさん：2011/11/06(日) 11:48:19.80

>>144
サンクスです。
クラス図をリバースで出力します、にはクラス図重要視派の私には、ショックです。

146 ：デフォルトの名無しさん：2011/11/06(日) 13:29:11.56

バイト先でシーケンス図書いてます

147 ：デフォルトの名無しさん：2011/11/06(日) 16:25:13.86

オブジェクトが動的に増えないプログラム（組込み）なんかだと
クラス図はわりとどうでもいいと感じるようになるね

シーケンス図は真面目にやると大変だけど重要だと思う

148 ：デフォルトの名無しさん：2011/11/06(日) 21:11:38.87

>>139
横レスするが、WinAPIも一応OO標榜してたんだぞ。

HWND
window = CreateWindowEx(・・・略・・・),
button = CreateWindowEx(・・・略・・・):

SendMessage( window, WM_GETTEXT, ・・・略・・・ );
SendMessage( window, WM_SETTEXT, ・・・略・・・ );

SendMessage( button, WM_GETTEXT, ・・・略・・・ );
SendMessage( button, WM_SETTEXT, ・・・略・・・ );

SendMessage( button WM_GETTEXT, ・・・略・・・ );
SendMessage( windown, WM_SETTEXT, ・・・略・・・ );

149 ：デフォルトの名無しさん：2011/11/06(日) 21:18:02.54

>>143
打ち合わせに使う。

150 ：デフォルトの名無しさん：2011/11/07(月) 01:03:35.48

こういうことってない？

Cell { int a; float b; char c; }でCell[][] table;とするか、
int[][] atable; float[][] btable; char[][] ctableとするか。

後者の方が変数が複数になってしまっているが、
実際は簡潔な分類を施した結果であり、
より変数の再利用性が高まってると思う。

妙なモッチャリ固まりクラスの使用を、
ライブラリ利用者に強いるのって結局のところ濁らせてるだけ。

151 ：デフォルトの名無しさん：2011/11/07(月) 02:34:17.79

>>150
高速検索様に、こういうのならあるが。
ま、違うか。

List<Cell>
     columnA = new LinkedList<Cell>(),
     columnB = new LinkedList<Cell>(),
     columnC = new LinkedList<Cell>();
Cell
     row;
row = new Cell();
columnA.add( row );
columnB.add( row );
columnC.add( row );

row = new Cell();
columnA.add( row );
columnB.add( row );
columnC.add( row );

152 ：デフォルトの名無しさん：2011/11/07(月) 10:56:11.58

>>150
「a、b、cが常に一塊で無いとマズい」と言うデータ構造を表現するなら前者だな
コードの最適化はデータ構造を破壊しがちだよ

153 ：デフォルトの名無しさん：2011/11/09(水) 12:56:53.49

インデックスのキャッシュを二次的に作成

154 ：デフォルトの名無しさん：2011/11/10(木) 00:59:52.83

(Windowsアプリの)プラグインのフレームワーク作ろうとしたら頭こんがらがってきた
本体アプリから呼ばれる部分のパッケージ(Base)は一番安定している筈。
で、プラグイン固有機能を実装するパッケージ(Derived)はBaseに依存している。
ここまではいい。

困ってるのは、
「Base内にあるDLLのエントリポイントでDerivedに属するクラスを生成するのはADP違反じゃないの？」
という点。（ADPってパッケージの依存関係を循環させんなってやつね）

Base内のEntryPoint.cpp（仮名）でonLoadが最初に呼ばれるとして、擬似コードがこんな感じ。

BOOL __cdecl onLoad( char *path )
{
gPlugin = new DerivedPlugin( path );
return gPlugin->onLoad();
}

別のプラグイン作成でBaseを流用したとき、毎回この関数を修正するのは変な気がするんだけど…。
上手く説明出来てなかったらすんません。

155 ：デフォルトの名無しさん：2011/11/10(木) 01:21:33.15

そこでなんでDerivedとして継承してるのかしらんが、DerivedはInterfaceのImplementとしてそのImplementしたクラスをリフレクション的に登録、Base的な部分では実際の中身は知らないインジェクトされたinterfaceを使ってCreateすることでDerivedのinstanceを作ればいい。
今の設計はBaseがDerivedを知ってる時点で間違ってる。

156 ：デフォルトの名無しさん：2011/11/10(木) 01:46:17.45

BaseがDerivedを知ってるのが間違ってるのくらいは良く理解してる…。
上の例で、DerivedPluginとして“やむを得ず”使ってしまってるのが唯一のADP違反部分で、
他の部分にはそういうところはなし。

問題は例のところで生成すべきクラスをどう指定すべきだったのかというところ。
解決法を>155で書いてくれてるんだろうけど、
「リフレクション的に登録」とか「インジェクトされた～」とかが良く分からん。

157 ：デフォルトの名無しさん：2011/11/10(木) 12:06:57.02

>>156
new DerivedPluginとしてるところは、DerivedPlugin自体を知ってる必要はなく、IPlugin的なインターフェースを持つ何かだよね？
だとしたらその場で作成するIPluginである何か（DerivedPlugin)についてどこからか登録すればいい。
それは設定ファイルなり、プラグインが登録されている指定されたフォルダを全部舐めることで動的に登録するなりやり方は色々。

登録する・・・がインジェクトと言ってたものであり、リフレクション・・・と言ってたのはフォルダを舐めて・・・の部分。
DependencyInjectionとかでしらべたまい。

158 ：デフォルトの名無しさん：2011/11/10(木) 12:57:50.68

> new DerivedPluginとしてるところは、DerivedPlugin自体を知ってる必要はなく、
> IPlugin的なインターフェースを持つ何かだよね？
そうです。実際の操作はインターフェースによってのみ行うようにしてる。

> それは設定ファイルなり、～
ああ、なるほど。
依存性をソースファイル外に追い出すってことか。ありがと！

159 ：デフォルトの名無しさん：2011/11/11(金) 08:21:25.93

>>154
どうでもいいが、フレームワークをどういう意味で使ってる?
ただのオレオレクラスライブラリじゃないのか。

160 ：デフォルトの名無しさん：2011/11/11(金) 08:34:17.70

基本、枠組みはそのまま使って必要部分を拡張するやつ
主：フレームワーク、従：拡張部分

作ろうとしている段階なので現状そこまで行ってなくて、
オレオレクラスライブラリであるのは間違いないけど。
機能拡張が一定のやり方で出来ないようなら
それはそれでクラスライブラリとして完成させてもいいし。

161 ：デフォルトの名無しさん：2011/11/11(金) 09:47:51.43

まぁべつにそこを明確にする意味ってないよね

162 ：デフォルトの名無しさん：2011/11/11(金) 11:03:36.00

GOF本にはそう書いてるだけだけどね。
「本にそう書かれてるから正しい」なんて言うような原理主義者でもないけど
異議を唱える程の自己主張も無いし。

163 ：デフォルトの名無しさん：2011/11/12(土) 15:16:36.36

>>158
そもそもエントリーポイントを何でBaseに入れる必要があるんだ？
エントリーポイント用意して毎回吐かせりゃいいじゃねぇの？

//ヘッダに固定
namespace Plug
{
void Export( Registry &);
}
//DLLにリンクするライブラリに固定
extern"C" __declspec(export) void RealEntry( Registry& registry ) { Plug::Export(registry);}

// DLL毎に記述
void Plug::Export( Register ®ister )
{
registry.Register( "Alpha", new Plugin() );
}

164 ：デフォルトの名無しさん：2011/11/23(水) 12:07:51.02

インターフェースの設計はどういう観点から行うのが有効なのでしょう。

165 ：デフォルトの名無しさん：2011/11/23(水) 13:02:47.92

そのインターフェースが表すものが備えてるものを備えてるようにすることかの。

166 ：デフォルトの名無しさん：2011/11/23(水) 14:17:45.35

>>165
それって、どの本にも書いてあることだの。その先が知りたいのに。ムカッ。

167 ：デフォルトの名無しさん：2011/11/23(水) 16:07:10.50

じゃぁプログラム構造の中の空間的分割を行うための変換子として扱えばいいよ。

168 ：デフォルトの名無しさん：2011/11/23(水) 16:47:11.93

逆に言うと公開しないものはインターフェース以外って事でしょ
外部から実行出来る(依頼とか操作とか)ようにするものは何か？ = インターフェースだよね
必要なものだけにしときます

まぁポリモーフするからってインターフェースを考える場合もあるけど

169 ：デフォルトの名無しさん：2011/11/23(水) 16:51:34.57

>>166
必要に迫られて自分でやらなきゃ分からんよ
伝聞はすぐ忘れる

170 ：デフォルトの名無しさん：2011/11/23(水) 17:53:24.78

>>164
既存のライブラリ群を見て、　「どういう物がインターフェースとして実装されているか」　を考えれば解るんでない？
例えば、C#の　IComparable　とか。

171 ：デフォルトの名無しさん：2011/11/23(水) 19:13:08.94

使う側で考えて、その結果インターフェースにしたほうが早い。
しょっぱなからインタフェース書くんじゃなくて、例えば、下みたいな
呼び出しコードを書いてみてから、どうすればキレイにできるか考える。

RuleSet rule = new Required( new Number( new Min( 0 ), new Max( 100 ) ) );
rule.validate( textbox, "透明度" );

172 ：デフォルトの名無しさん：2011/11/24(木) 21:26:20.01

>>171
さっぱり、わからん。
ちなみに、本などに書かれているのだが、「設計段階でインターフェースの抽出を行いましょう。」
っていうのは、>>171と真逆な感じがする。

173 ：デフォルトの名無しさん：2011/11/24(木) 21:37:46.47

>>171じゃ無いが
最初は、インターフェースとか全く考えずにプロトタイプを作る。

んで、プロトタイプを捨てて再設計する段階で
インターフェース化出来る部分が有るか、ついでに検討する。

174 ：デフォルトの名無しさん：2011/11/25(金) 02:25:57.56

まぁ両方からだね。
最初から個々はインターフェースにナイスにまとめられるよねって分かる部分と、作ってるうちにここをインターフェースにまとめたらナイスにまとまるんじゃね？ってのと。
だんだん前者が多くなってくると思われ。

175 ：デフォルトの名無しさん：2011/11/25(金) 14:47:02.03

>>172
プロトタイプを製作してみて、その傾向から設計を引き直してインターフェースを導出するって事なんかね？>>171のはさ。

176 ：デフォルトの名無しさん：2011/11/25(金) 15:44:52.10

>>175
作成まではしなくてもいいんじゃないかな
「他のクラスからどう呼ばれると自然か？」って方向の
思考実験してみるだけでも良いかと

177 ：171：2011/11/25(金) 23:13:05.29

呼び出しコードを書いてからとは書いたけど、
強調したいのはコードそのものじゃなくて、
呼び出し方、使い方を最初に考える事だよ。
コードを書くと言ったのは、大雑把でもコードに落として考えると
イメージしやすいというだけ。

例えば、>>171を見ると
RuleSet rule = (RuleSet)new Required( (Rule)(RuleSet)new Number( (NumericRule)new Min( 0 ), (NumericRule)new Max( 100 ) ) );
rule.validate( textbox, "透明度" );
みたいな感じで、必要なインターフェースが浮かぶ。図とかだけで思い浮かべるのはややメンドイ。
ちなみにコード自体意味が解からない人がいるかもしれないから補足すると、
このコードは[必須である[数値である[0以上である, 100以下である]]]という検査条件をオブジェクトで表現し、
textboxをチェックしてる。

178 ：デフォルトの名無しさん：2011/11/25(金) 23:24:14.50

textboxをチェックといわれても曖昧だな。
結局、使う側がいっぱい学習しないといけなさそうなインタフェースだよなそれ。

179 ：デフォルトの名無しさん：2011/11/25(金) 23:44:40.37

実際はtextboxじゃなくString型のモノをそのまま渡すんだけどね。
TextBoxの入力チェックの方が解りやすいかと思ってtextboxとは書いたけど。

180 ：デフォルトの名無しさん：2011/11/25(金) 23:49:24.00

理解するのに15分も掛からなそうだが・・・。そんなに学習がひつようか？

181 ：デフォルトの名無しさん：2011/11/26(土) 01:10:33.19

リファクタリングもデザパタもsmalltalkerなんだよな。おめーら
smalltalkerに足を向けて寝るんじゃねーぞ。

182 ：デフォルトの名無しさん：2011/11/26(土) 01:24:04.85

フォン・ノイマンに足を向けて寝るんじゃねーぞ。

183 ：デフォルトの名無しさん：2011/11/26(土) 09:33:08.95

っていうか、このスレに出現している椰子はオブジェクト指向設計を
やったことがない者ばかりじゃないだろうか？
インターフェースは、設計の段階でほぼきっちりと把握できる。
リファクタリングは、納期に迫られて設計不十分で見切り発車したプログラムを
あとから見直す場合に行うと考えたほうがよい。

ああ、やはり大手ＩＴ企業の中央部署の人しかオブジェクト指向設計をやっていないことがわかった。
っで、このスレに来る椰子は末端のプログラマだけだね。まあ、テクニックだけは高い人もいるようだが。

184 ：デフォルトの名無しさん：2011/11/26(土) 09:36:50.63

>>183
末端のプログラマがオブジェクト設計しなきゃいけないプロジェクトはその時点で終わってる。

185 ：デフォルトの名無しさん：2011/11/26(土) 09:39:54.86

前段、なにをいまさら得意げに言い直してるのかｗ

186 ：デフォルトの名無しさん：2011/11/26(土) 09:41:13.32

一昔前(2000年初頭)の苦い経験から、末端側がそれほどオブジェクト設計を意識しなくていいような、フレームワークという概念が台頭してきたんだよ。

187 ：デフォルトの名無しさん：2011/11/26(土) 09:45:08.44

Sunは設計不十分で見切り発車で作ってたから
Javaなんてdeprecatedなメソッドが盛り沢山。

188 ：デフォルトの名無しさん：2011/11/26(土) 09:49:05.51

>>183
っ[ アジャイル ]
っ[ スパイラルモデル ]
っ[ プロトタイピング ]
っ[ TDD ]

189 ：デフォルトの名無しさん：2011/11/26(土) 11:57:02.80

はいはい。ハイハイして去ります。私がアホでした。

190 ：デフォルトの名無しさん：2011/11/26(土) 12:14:21.53

>>183
オブジェクト指向設計やったことある？

ドメインモデルとトランザクションスクリプト
どちらの設計を使ってる？

トランザクションスクリプトはオブジェクト指向設計風ではないけれど
よく使われてるよね。俺も完全なオブジェクト指向設計よりも
トランザクションスクリプトの方が開発しやすいと思うんだけど。

ドメインモデルはなんか設計がガチガチで柔軟性がないか
柔軟性を保つために何度も再設計をすることになりそう。

191 ：デフォルトの名無しさん：2011/11/26(土) 12:23:08.40

>>190
クラス図設計とシーケンス図設計のみ。
ドメインモデルとトランザクションスクリプト。ふん、なんか言葉では見たか、聞いたかかもしれないが
あまり気にしてない。
クラス図を作成するのが大変だった。特に、インターフェースを抽出するのがね。

192 ：デフォルトの名無しさん：2011/11/26(土) 12:27:00.57

>>191
話にならんな。

シーケンス図はオブジェクト指向と全く関係ないし、
クラス図はUMLの中で一番使えないものとされてる。
クラス図はコードのクラス定義そのものだからね。

193 ：デフォルトの名無しさん：2011/11/26(土) 12:31:05.13

>>192
言い過ぎだろう。

194 ：デフォルトの名無しさん：2011/11/26(土) 12:38:39.14

クラス図なんか、コードを書きながら設計すれば良い。
これは手抜きではなく、試行錯誤だ。

適切な言語を選べば、インターフェースを抽出するなんて
ほんの少しコマンドを実行すれば終わる。

メソッドを親クラスに移動したり、反対に子クラスに移動したり、
コードをまとめたりといった作業のコストは低い。（言語と開発環境によるが）

195 ：デフォルトの名無しさん：2011/11/26(土) 12:44:09.05

クラス図のなにが悪いかって書くのが面倒な上に、
ソースコードから生成できるから意味が無いってこと。
マウスでポチポチやって図を書くよりもコードを書くほうがはるかに楽。

一時期はクラス図からソースコードを生成するってのが流行ったが、
逆にソースコードを書いてそこからクラス図を生成したほうが良い。
どうせクラス図は完璧には書かないんだから。（最初にすべてのメソッドかけますか？）

ソースコードからクラス図を生成するようにしておけば
クラス図とソースコードに違いが出ることもない。

196 ：デフォルトの名無しさん：2011/11/26(土) 12:59:53.64

>>193
横レスであれだが、決して言い過ぎじゃないと思うぜ…

197 ：デフォルトの名無しさん：2011/11/26(土) 13:06:45.29

プログラマ版ではこのスレのお題は重すぎる。

198 ：デフォルトの名無しさん：2011/11/26(土) 13:31:29.13

そもそもクラス図を作ったところで使う機会が無いというのが最大の問題点じゃないか
クラス図の役割って殆どIDEでカバー出来ると思う

199 ：デフォルトの名無しさん：2011/11/26(土) 13:42:57.53

プログラミングを単なる実装と思ってしまうから、
実装の前に設計が必要だと思ってしまうんだよ。

メソッドの中身までは書かなくてもいいが、
設計をコードでクラス定義として書くほうが
柔軟で書きやすい。

200 ：デフォルトの名無しさん：2011/11/26(土) 14:26:18.01

やり方は色々だろうけど。

クラス図に中身空っぽのクラス並べて構造を俯瞰できるようにして、
シーケンス図書きながらクラス図にpublicなメソッドを足してく訳だよ。

だから俯瞰する能力が高くてシーケンス図なんざ書かなくても
協調が把握できる人なら、クラス図は要らない、というか
まぁそもそもそんな仕事で良ければアーキ設計書もUMLも要らないという話だが、
世の中の開発者はそんなスーパーマンばかりではない。

201 ：デフォルトの名無しさん：2011/11/26(土) 14:33:11.22

>>200
誰も、シーケンス図が無駄とは言ってない。
シーケンス図はオブジェクト指向と無関係だということ。

あと、シーケンス図はクラス図と関連はない。

202 ：デフォルトの名無しさん：2011/11/26(土) 14:43:11.21

他人のプログラム読む場合
シーケンス図があるとないとで全然違う

203 ：デフォルトの名無しさん：2011/11/26(土) 14:44:44.04

シーケンス図が必要なほど呼び出し順が入り組んでるものはいやだ。

204 ：デフォルトの名無しさん：2011/11/26(土) 14:49:42.51

まさか全ての処理にシーケンス図描いてるのか

205 ：デフォルトの名無しさん：2011/11/26(土) 14:51:32.15

>>195
オブジェクト図で叩き台作って、クラス図を作ってチームで打ち合わせしとくと、
コード書き始めるより遥かに出戻りが少なくなるぞ。

206 ：デフォルトの名無しさん：2011/11/26(土) 14:52:42.47

>>201は、いろいろと知らなさすぎる。
何をかじっているのだろう。

207 ：デフォルトの名無しさん：2011/11/26(土) 14:59:08.67

ユースケース毎にシーケンス図があると間違いが起きにくいよ

208 ：デフォルトの名無しさん：2011/11/26(土) 15:04:41.92

>>192
> クラス図はUMLの中で一番使えないものとされてる。
されてないし、されてる訳がない。通常、最も多く使われるのがクラス図。
いったいどこの誰がこんな馬鹿げたことを言っているのか…

>>195
根本的に間違えてる。
設計段階のクラス図は、自分の考えを整理したり他人とのコミュニケションの
道具として使うために、紙とペンを使って素早く書くもの。
（もちろんホワイトボードでもいいし、ツールを使った方が早ければそれでも）
ソースコードから生成するのは、主に最終的なドキュメントとして必要な場合。

ていうかドメインモデルとトランザクションスクリプトを持ち出すならせめて
DDDくらいは読んでおけよ。いろいろと酷過ぎる。

209 ：デフォルトの名無しさん：2011/11/26(土) 15:05:39.39

ユースケースは使わない。ユースケースは無理やり考えられた代物に思われる。

210 ：デフォルトの名無しさん：2011/11/26(土) 15:10:08.44

馬鹿ばっかりｗ

211 ：デフォルトの名無しさん：2011/11/26(土) 15:10:45.24

馬鹿が一人ｗ

212 ：デフォルトの名無しさん：2011/11/26(土) 15:19:41.95

つまりクラス図はフローチャートくらいには必要

213 ：デフォルトの名無しさん：2011/11/26(土) 15:27:05.16

フローチャートとシーケンス図はまったく必要ないと思うけど
クラス図は結構好きだけどな

ってかＰＧのレベルが低くてまったく関連のない処理を
他のクラスにぶち込もうとしてる奴に歯止めをかけることができる

まあ、詳しい処理の話になったらクラス図の出番はないけどねｗ

214 ：デフォルトの名無しさん：2011/11/26(土) 15:29:08.27

厳密に書くと役に立たない（線が多すぎて解読不能）
あくまで説明用に対象のクラスがざっと書いてあるレベルで役に立つ

215 ：デフォルトの名無しさん：2011/11/26(土) 15:37:29.40

図の上の方に他への依存性が低いクラスを書き、
図の下に行くに連れて他への依存性の高いクラスを書くとか
お前等はしないのか？
キレイに上下依存関係が別れないクラスは、インターフェースに分割したり、
機能的に類似性が高いクラスはインターフェースを統一したりとか、
打ち合わせで図を見ながら考える事はあるだろうに。
やっぱ派遣だとそんな打ち合わせする暇はないのかね。

216 ：デフォルトの名無しさん：2011/11/26(土) 15:49:27.47

ないな
そもそも仕様書に出てくる用語以外のクラスを作成しちまうとやたら詳しく説明を求められるから
そういう変なクラス作らないし

217 ：デフォルトの名無しさん：2011/11/26(土) 15:49:44.26

ウォーターフローモデルでの開発では
必須というだけの話。

アジャイルなら変化しながら開発が進む

218 ：デフォルトの名無しさん：2011/11/26(土) 15:50:18.34

>>216
仕様書が完璧ならそれでいいんだけどねｗ

219 ：デフォルトの名無しさん：2011/11/26(土) 15:51:05.71

いや、下位工程に回す前に、上位工程では完璧に作るのは常識でしょ。
じゃないと、下位工程でバグが見つかって上位工程に戻すと工数がかかり過ぎる。

220 ：デフォルトの名無しさん：2011/11/26(土) 15:51:54.16

>>218
その場合は仕様変更だからちゃんと工数もらえるから時間とっていいんだ
そこを吸収してやるようには作らなくていい

221 ：デフォルトの名無しさん：2011/11/26(土) 15:52:23.77

やっぱ自社で1システム受注できないところは、OO開発は向かないのな。
そりゃUML使えないと言ってても仕方ないか。

222 ：デフォルトの名無しさん：2011/11/26(土) 15:58:40.69

お前等、基本設計から納品まで出来る企業に転職したら？
自社でライブラリすら持ってなくて、スクラップアンドビルド
ばっかしてる仕事は、穴埋め囚人みたいで辛いだろ。

223 ：デフォルトの名無しさん：2011/11/26(土) 16:01:48.46

てか、大手も実装工程は作り直しても大して時間とらない（＝金かからない）ってことに気がついてるから
わざわざ開発手法にまで手を入れてこない

仕様決めとかそっちのが時間かかるからなぁ

224 ：デフォルトの名無しさん：2011/11/26(土) 16:13:30.36

大手は、そもそも案件を下請けに投げるだけだろ？
営業から納品までやってんのは大概中小企業じゃね？

225 ：デフォルトの名無しさん：2011/11/26(土) 16:14:41.71

そうなると基本設計から納品までなんて会社はないんじゃないか？

226 ：デフォルトの名無しさん：2011/11/26(土) 16:18:42.92

ウチの会社はやってるし、ライバル会社もやってるから、結構いる筈。
自社パッケージ持ってるのが、一括受注できる原因だろうけどね。

227 ：デフォルトの名無しさん：2011/11/26(土) 16:20:40.47

つか、納品する仕事なんてやりたくない。

せっかく作ったシステムの権利をあげたら自分になにも残らないだろ。

228 ：デフォルトの名無しさん：2011/11/26(土) 16:21:20.04

>>226
大手からすると無駄が多いって考えだろうな
基本的に設計やる人間と実装やる人間の単価が違うってとこまでコストカットしてないと
設計と実装の人間を変えることないべ？

だから自社パッケなんてのは無駄ばかりだから成り立つもんなんだよ
そのうち開発メンバーが年取ってくれば給料とかコストが増えるから自社パッケはなくなるだろうな

229 ：デフォルトの名無しさん：2011/11/26(土) 16:24:46.68

ん？成果物は全部自社管理すんだから、
作ったソースやドキュメントは自社のもんじゃん。
ライブラリなんてシステム見積もるときにライセンス買わせてるし。

230 ：デフォルトの名無しさん：2011/11/26(土) 16:30:38.30

>>228
開発者が歳をとろうと自社パッケージをなくすことは無理だよ。少なくともウチでは。
こんな不況下でも黒字をたたき出す。受注に比べほっといても売れるから
圧倒的に採算がいいらしい。ただ、それでも情報収集が必要だからって理由で
受注開発はしてる。

231 ：デフォルトの名無しさん：2011/11/26(土) 16:37:30.50

儲かる仕事を繰り返すためにも設計書は必須だ。

232 ：デフォルトの名無しさん：2011/11/26(土) 16:38:56.44

詳細設計書はともかく、基本設計書もない環境なんて無いだろ。

233 ：デフォルトの名無しさん：2011/11/26(土) 18:46:35.67

>>230
したらどうして大手は自社で開発をもたないの？
って疑問はお前の理論じゃ成り立たないべ？

234 ：デフォルトの名無しさん：2011/11/26(土) 19:51:02.29

>>233
230じゃないが。

車輪の再発明するより枯れた他社パッケージを買う方が利ザヤがデカいからだろ。
大手の方が販路デカいし、売ることが出来る会社ならパッケージ作ってソフトを売るより
パッケージ買ってソリューションを売る方が金になる。

まぁ一般論であって、その大手って具体的にどこなのか分からないから、
そういう話でも無いのかも知れないけど、どこの会社のこと？

言ってもソコソコ売れてるパッケージは金になるよ。
作ってしまえばあとは保守にゃあんまり金掛からないのに、
サポートで金取れるし、機能追加で金取れるし。
そんかわり軌道に乗るまでは赤字吹きまくる。

235 ：デフォルトの名無しさん：2011/11/26(土) 21:04:56.20

インターフェースを理解できないやつはJava The Good Partsの型システムの章を読め
少ないページでどう利用するのかがすぐにイメージできる

クラス図議論は>>208に同意
理解できないやつはUMLモデリングのエッセンスを読め
1～5,9章読めばOK　他は余裕があれば読めばいい

シーケンス図も抽象的な物は設計段階で書いておくと自分の考えを整理しやすい
これは実際のコードに対応していちいち修正する必要はない
自分の考えがまとまらないなら修正して考えれてみればいい

クラス図からのコード生成はMDAというものがあるし実際やったことあるけど糞
結局脳内でコーディングして、それを無理矢理図に落として(ここに無駄にく苦労する)、コードが自動生成されるだけ
メリットとして、設計図とコードが一貫性を保てるという話があるけど、そもそもそこまで設計図に拘る意味がわからん
もしドキュメントが後々必要ならそのとき初めて作成すればいいだけ　今流行の遅延評価ｗ

あとオブジェクト指向語るならリファクタリング本も必須

236 ：デフォルトの名無しさん：2011/11/26(土) 21:09:09.26

開発系エンジニアのスキルロードマップ Part 1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
http://blogs.msdn.com/b/nakama/archive/2011/11/25/skill-roadmap-part-1.aspx

237 ：デフォルトの名無しさん：2011/11/26(土) 21:12:26.72

やっぱりオブジェクト指向って言ったら
Javaの独壇場か。

238 ：デフォルトの名無しさん：2011/11/26(土) 21:18:17.95

Javaが一番アカデミックだよね。
ちゃんと熟考して作るという開発ができる。

他の言語、特に動的型付け言語なんか、適当に考えて
問題出たらパッチ当てる感覚で修正するから、
その時はすぐに問題を解決できても、すぐにボロが出てしまう。

239 ：デフォルトの名無しさん：2011/11/26(土) 21:46:06.84

>>233
いや、単にウチの事情を書いただけだし。
理論は成り立たないと言われてもねぇ。

240 ：デフォルトの名無しさん：2011/11/26(土) 21:57:28.40

>>237
いや、純粋なOOで言えばCOMやCORBA、COCOAの方がマシなぐらいだが。

241 ：デフォルトの名無しさん：2011/11/26(土) 22:06:23.44

bean機構なんて導入したのが、どうしようもなく退化してるしな

242 ：デフォルトの名無しさん：2011/11/26(土) 22:08:45.64

>>237-238
オブジェクト指向の基礎を学ぶならJavaは適してると思う
アクセス修飾子、静的型、抽象クラス、抽象メソッド、インターフェース、継承をしっかりと機能が用意されているので学びやすい

C++は継承を学ぶために余計なことを色々意識しないといけないし、型推論ついたし微妙

最近のブームだと
Rubyは動的型付けだけど上に書いた項目を理解していないと、そのメリットすら意識できない
Scalaの型推論も同様　あとはJava＋関数型言語のようなものなので、Javaを学んだ後＋αとして関数型を学ぶときに使えばいい

っということでとりあえずはやっぱりJava
OOの重鎮達が推奨するsmalltalkも1度学びたいとは思ってるが知らない

243 ：デフォルトの名無しさん：2011/11/26(土) 22:18:18.50

C++もOOの基礎を理解したら
スタック、ヒープや
参照渡し、ポインタ渡し、値渡し、Javaの参照渡しなど
メモリ関連を理解するためには1度学んでもいいかもしれない

244 ：デフォルトの名無しさん：2011/11/26(土) 22:23:33.89

beanもアレだけどJavaは戻り値を多用して、ダウンキャストが多いのがナンセンス。
smalltalkやC++の用に引数で受け取ったオブジェクトに再度メッセージを送るほうが、
OOとしては理に叶ってるのにな。

245 ：デフォルトの名無しさん：2011/11/26(土) 23:01:24.72

> smalltalkやC++の用に引数で受け取ったオブジェクトに再度メッセージを送るほうが、

意味不明

246 ：デフォルトの名無しさん：2011/11/26(土) 23:04:55.40

メッセージについて勉強しなおしてこい

247 ：デフォルトの名無しさん：2011/11/26(土) 23:06:34.41

>>246
勉強してきた。それで？

248 ：デフォルトの名無しさん：2011/11/26(土) 23:08:34.62

引数で受け取ったオブジェクトに再度メッセージを送りたいなら
送ればいいだけだと思うけど、俺も>>244がなにを言いたいのかわからんな。

249 ：デフォルトの名無しさん：2011/11/26(土) 23:14:00.13

これだけの話なんだけどな。

java.beans.XMLDecoder decoder = new java.beans.XMLDecoder( new java.io.FileInputStream( "Test.xml" ) );

// ダウンキャストが必要な今の実装
RootBean bean = (RootBean)decoder.readObject();

// Java以外だとよく見る素直な実装
RootBean bean = new RootBean();
decoder.readTo( bean );

250 ：デフォルトの名無しさん：2011/11/26(土) 23:18:02.50

>>247
じゃメッセージフォワーディングのメリットぐらい解るだろ。

251 ：デフォルトの名無しさん：2011/11/26(土) 23:20:12.14

ちゃんとコードの解説をしろ

252 ：デフォルトの名無しさん：2011/11/26(土) 23:21:45.55

>>250
したいならすればいいんじゃないですかぁ？

253 ：デフォルトの名無しさん：2011/11/26(土) 23:26:13.93

>>251
ダウンキャストの使用頻度が高くて、OOPLとしてはデザインが汚いですよね。
他の言語のほうがマシに見えるぐらい。
おわり。

254 ：デフォルトの名無しさん：2011/11/26(土) 23:32:55.08

>RootBean bean = new RootBean();
>decoder.readTo( bean );

確かにこれができると便利だけどね
こういう風に読み込み前にオブジェクト弄れるし
decoder.readTo(new Adapter(bean, param));

255 ：デフォルトの名無しさん：2011/11/26(土) 23:40:13.91

わざわざ参照多用するような構造を肯定するのは
グローバル変数便利だよ引数省略できるし並みに痛い気がするんだが

256 ：デフォルトの名無しさん：2011/11/26(土) 23:41:56.25

それはJavaに洗脳されてるからじゃないの？
戻り値多用するOOPLは少数派だべ

257 ：デフォルトの名無しさん：2011/11/26(土) 23:43:02.89

>>255
オブジェクトトポロジーを理解してないお前のほうが痛い

258 ：デフォルトの名無しさん：2011/11/26(土) 23:44:53.48

デザパタ本も参照(ポインタ)使いまくってるしなぁ

259 ：デフォルトの名無しさん：2011/11/26(土) 23:49:43.70

ダウンキャストと参照どっちを取れといわれれば、まだ参照だわ。

260 ：デフォルトの名無しさん：2011/11/26(土) 23:57:14.80

どっちもいらんからね

261 ：デフォルトの名無しさん：2011/11/27(日) 00:08:51.20

Javaの問題ではなく、ライブラリの設計の問題じゃねーか。

262 ：デフォルトの名無しさん：2011/11/27(日) 00:33:35.14

decoderみたいの設計するとき
どんなふうにするのがいいんですかね

こんな感じとかかしら
RootBean bean = decoder.readTo( RootBean.class );

263 ：デフォルトの名無しさん：2011/11/27(日) 00:45:15.16

auto hoge = reader.read<Hoge>();
で

264 ：デフォルトの名無しさん：2011/11/27(日) 00:49:48.12

>>238
ポカーンとした意見だった。

265 ：デフォルトの名無しさん：2011/11/27(日) 00:52:55.29

>>262
>>263と同じ見かけが変わっただけじゃん

266 ：デフォルトの名無しさん：2011/11/27(日) 00:55:37.75

Javaは土方で、アカデミックとは真逆の位置にいるもんな

267 ：デフォルトの名無しさん：2011/11/27(日) 00:59:42.03

>>266
お前にとってのアカデミックって
ドカタだろｗ

268 ：デフォルトの名無しさん：2011/11/27(日) 01:06:11.38

全てがオブジェクトの言語に触れてからほざけよ土方

269 ：デフォルトの名無しさん：2011/11/27(日) 01:26:32.33

>>263
型推論使うんなら型指定そのものも無くなってほしいけど
C++とかだとそこまでは無理なんだっけ

270 ：デフォルトの名無しさん：2011/11/27(日) 01:29:10.66

C++じゃ無くてもOCamlだろうと無理です

271 ：デフォルトの名無しさん：2011/11/27(日) 03:46:33.17

Javaでアルゴリズムを教えようとすると、大変だと思うよ。
アルゴリズム以外の要素が邪魔すぎて。アルゴリズムなんて
どうでもよくて、ただ、ライブラリを持ってきて並べるだけの仕事
ならばJavaは向いてると思うが。。。

272 ：デフォルトの名無しさん：2011/11/27(日) 03:48:59.06

オブジェクト指向の有名な教科書ってエッフェルだったよな？
オブジェクト指向言語の代表選手として、Javaを扱ってるのもある。
デザパタの出処はsmalltalkみたいだし。

273 ：デフォルトの名無しさん：2011/11/27(日) 05:16:59.81

昔勉強した頃はエッフェルという名前も聞いたけど
言語の研究分野でしか聞いたことがないなぁ

Smalltalkは啓蒙してる人が濃ゆいけどw新参ではお金にならん
非商用版なら無料だから眺めたい人はご自由に

市井のプログラマとしてはJavaでウェブっていう案件は多い
VB.net、VC++より多いんじゃないかな

274 ：デフォルトの名無しさん：2011/11/27(日) 05:20:16.36

実装言語の話はさておいて

ユースケース記述とシーケンス図がしっかりしてるのは
設計先行のいいプロジェクトの傾向だと思う

275 ：デフォルトの名無しさん：2011/11/27(日) 08:00:36.71

シーケンス図がしっりしてるのはバッドスメルだろ。コスト配分に問題ありそう

276 ：デフォルトの名無しさん：2011/11/27(日) 09:11:09.43

>>269
型推論は型宣言を省略するための仕組みじゃないよ

277 ：デフォルトの名無しさん：2011/11/27(日) 09:41:11.46

型指定を型宣言といいかえて否定するとはこれいかに

278 ：デフォルトの名無しさん：2011/11/27(日) 09:58:49.67

ほおー、型推論は型指定を省略するためのものなのか？ｗｗｗ
馬鹿丸出しｗ

279 ：デフォルトの名無しさん：2011/11/27(日) 10:19:24.55

↑この人です

280 ：デフォルトの名無しさん：2011/11/27(日) 10:33:22.10

またものすごい珍説が飛び出したものだ

281 ：デフォルトの名無しさん：2011/11/27(日) 11:04:59.50

カタカタｗ

282 ：デフォルトの名無しさん：2011/11/27(日) 12:37:48.04

>>278
え、ちがうの？
参考までにご高説を賜りたく（　＾ω＾）・・・

283 ：デフォルトの名無しさん：2011/11/27(日) 12:45:41.55

型推論は、～略超高度な推論機能によって略～その結果、型指定が省略できるのです。

284 ：デフォルトの名無しさん：2011/11/27(日) 13:02:03.39

>>269
返り値の型しか違わないオーバーロードが可能な言語って、どんな変態文法だよ

285 ：デフォルトの名無しさん：2011/11/27(日) 13:13:46.63

>>284
Scala

286 ：デフォルトの名無しさん：2011/11/27(日) 14:11:32.97

>>285
へえ、Scalaだと
hoge(read())
で、hoge(x:Int)かhoge(x:String)かどちらが呼ばれるかわかるの。へえ

287 ：デフォルトの名無しさん：2011/11/27(日) 14:30:22.90

型がない言語だと関数内部で、引数の型を調べて
処理を分岐させるコードを書かないといけないから面倒臭い。

288 ：デフォルトの名無しさん：2011/11/27(日) 14:47:25.62

>>282
型推論は型検査をするためのものだろｗｗｗｗｗ

289 ：デフォルトの名無しさん：2011/11/27(日) 14:51:29.49

http://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96

型推論（かたすいろん）とはプログラミング言語の機能の1つで、
静的な型付けを持つ言語において、変数や関数の型を宣言しなくても
それを導くのに使われた関数の型シグネチャなどから自動的に型を決定する機構のこと。

290 ：デフォルトの名無しさん：2011/11/27(日) 14:52:15.54

ソースはウィキペｗｗｗ腹イテｗｗｗｗ　

291 ：デフォルトの名無しさん：2011/11/27(日) 14:53:03.56

> 型推論を持つ言語としてはHaskell、ML、Vala、C#、Scala、Objective Caml、D言語、Concurrent Cleanなどがある。
> JavaやC++0xでも導入が検討されている。静的型付け関数型言語のほとんどが型推論の機能を持っている。

Rubyには型推論搭載されんの？

292 ：デフォルトの名無しさん：2011/11/27(日) 14:53:44.69

ソースは２ちゃんねる。

293 ：デフォルトの名無しさん：2011/11/27(日) 14:55:47.39

>>288
「型検査型推論違い」でぐぐってみ。
この2つは明らかに別もの。

294 ：デフォルトの名無しさん：2011/11/27(日) 15:07:44.66

>>288
静的型検査を型を記述しなくても可能にするためのものだろ。
バカすぐるｗｗｗｗｗ

295 ：デフォルトの名無しさん：2011/11/27(日) 15:15:51.69

>>294
いや、逐一型指定しても型推論（型単一化）は行われるよ。
キミさ、型推論の仕組みがわかった上で言ってるの？
型推論を実装したことある？

296 ：デフォルトの名無しさん：2011/11/27(日) 15:17:25.50

>>295
実装したことがあるから言ってる。
似てるだけで概念的には別物。

あんたは実装した奴が陥る罠に落ちいてるだけだよ。
実装が似ているものを同じだと思ってしまう。
概念は別物。

297 ：デフォルトの名無しさん：2011/11/27(日) 15:21:31.48

本物のパラメトリック多相型のある言語の型検査には型推論は必須。
そして型推論での単一化は型検査にほかならない。

ということを承知の上で別物だとか言うわけ？

298 ：デフォルトの名無しさん：2011/11/27(日) 15:22:40.87

> 型検査には型推論は必須。

この2つを区別して書いてることから、
お前も別物として扱ってるだろ。

299 ：デフォルトの名無しさん：2011/11/27(日) 15:23:59.79

× 本物のパラメトリック多相型のある言語の型検査には型推論は必須。
○ 特定の条件の言語の、型検査には型推論は必須。そうでない言語では必須ではない。

300 ：デフォルトの名無しさん：2011/11/27(日) 15:25:55.78

>>295
型検査するけど型推論実装してない言語がある以上、別物だろ。

301 ：デフォルトの名無しさん：2011/11/27(日) 16:34:21.06

>>291
Rubyは動的型付け
実行するまで型は関係なし
型推論は静的型付けで型を省略すること
だけどちゃんと型は認識されてる

302 ：デフォルトの名無しさん：2011/11/27(日) 16:57:26.01

言語仕様に付いてやってる連中、スレチもたいがいにしろ

303 ：デフォルトの名無しさん：2011/11/27(日) 17:08:18.65

うゆが書いてんのかと思ってたぜ

304 ：デフォルトの名無しさん：2011/11/27(日) 17:28:50.13

まあ、型について議論が始まったことは良いこと。
オブジェクト指向は型(インターフェース)でプログラミングしておくっていうことで
俺なんかは満足している。いかにメインのプログラムを型(インターフェース)でプロ
グラミングできるかが重要だといつも思っている。
これを実現するためには何度も何度もクラス図を書いて、適切な型(インターフェース)
を取り出す。この辺がなかなか時間がかかりＰＭに「何をやっているんだ。仕事が遅い」
と怒鳴られる。泣きてえーーー。

305 ：デフォルトの名無しさん：2011/11/27(日) 17:36:58.12

愚痴はツイッターでやれ

306 ：デフォルトの名無しさん：2011/11/27(日) 17:43:52.36

>>300
しかし型検査ぬきの型推論は原理上ありえない

307 ：デフォルトの名無しさん：2011/11/27(日) 17:45:29.32

スレにあってそうなテーマをここでひとつ。

コーディング前の紙の上（設計書）での設計はどのくらいやっておくのがベストプラクティスなの？

308 ：デフォルトの名無しさん：2011/11/27(日) 17:47:51.66

>>304
>いかにメインのプログラムを型(インターフェース)でプロ
>グラミングできるかが重要だといつも思っている。

自分もそう考えている
極論を言えば、「オブジェクト指向設計とは型定義である」と

後半は、まぁ愚痴だねw

309 ：デフォルトの名無しさん：2011/11/27(日) 17:51:42.97

>>307
非機能要件で全然変わってくるから、ベストって無いんじゃないの？

310 ：デフォルトの名無しさん：2011/11/27(日) 18:08:53.44

動的型付け言語は出来損ないのオブジェクト指向だからねぇ。

出来損ないをアセンブラでカバーしてください。
アセンブラ使えばなんでもできますから。

311 ：デフォルトの名無しさん：2011/11/27(日) 18:20:23.56

出来損ないのオブジェクト指向

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
http://d.hatena.ne.jp/kazu-yamamoto/20080722/1216734420/

312 ：デフォルトの名無しさん：2011/11/27(日) 18:21:25.85

>>311
嫉妬心丸出しで見ていて恥ずかしくなったｗ

そうか、そんなにJavaに嫉妬してるのか

313 ：デフォルトの名無しさん：2011/11/27(日) 18:26:48.65

俺、JavaよりはC#の方が…

314 ：デフォルトの名無しさん：2011/11/27(日) 18:37:15.01

>>307
業種や何やらの条件で色々違うだろうね

・ユースケース記述が出尽くす
・概念レベルでクラス分けができる
・メソッドを適したクラスに割り当てられる
・ユースケース記述にそってシーケンス図が描ける

実装前にこれくらい設計できればなぁ…
デザインパターンの適応もコーディング前の段階で検討できるし
コーディングは楽になると思う

315 ：デフォルトの名無しさん：2011/11/27(日) 18:39:06.55

静的型付けオブジェクト指向なんて、貧乏人向けのオブジェクト指向だろ。
補助輪付きの自転車みたいなものだｗ

316 ：デフォルトの名無しさん：2011/11/27(日) 18:47:04.72

誰かつられてやれよｗ

317 ：デフォルトの名無しさん：2011/11/27(日) 18:55:50.33

>>306
だれも型検査抜きの型推論のことは話してないと思うが。
上であがってるのは
・型推論!=型検査
・型推論は静的型検査を行う言語で型の記述を省く仕組み
かどうかの話だろ。
型推論をする時にコンパイラが型を認識してるのは当たり前で、それは型検査じゃないよ？

318 ：デフォルトの名無しさん：2011/11/27(日) 19:54:28.55

型を認識するだけでなく、型の整合性を検証しているんだよ。単一化によって。

型推論を実装したのにわからないなんて、おかしいなあｗ

319 ：デフォルトの名無しさん：2011/11/27(日) 20:12:06.56

>>317
＞・型推論!=型検査
を主張してる奴らは、その是非が
＞・型推論は静的型検査を行う言語で型の記述を省く仕組み
かどうかに帰結するわけじゃないことに
気づいてなさそうな話の展開のさせ方してるよな。
ほんと謎の思考だ

320 ：デフォルトの名無しさん：2011/11/27(日) 20:50:27.40

>>318
整合性の検証は型検査でしょ
これは型推論が実装されているいないに関わらず静的片付けなら実装されてる
だから・型推論!=型検査
ということじゃないの？

321 ：デフォルトの名無しさん：2011/11/27(日) 20:53:37.13

納豆は大豆を腐らせて作るものだが、
納豆と大豆とは別物として扱われているのと同じだ。

322 ：デフォルトの名無しさん：2011/11/27(日) 21:04:48.74

設計やってないコーダーが多いことが分かって俺は悲しい orz

323 ：デフォルトの名無しさん：2011/11/27(日) 21:06:25.53

Javaプログラマぐらいだよね。
コーディングの話題に設計の話が出てくるのは。

デザパタとかDIとかドメインモデルとか
そういう用語が他言語ででることは極端に少ない。

324 ：デフォルトの名無しさん：2011/11/27(日) 21:09:00.94

DIはわざわざ話題に出さなくとも、習慣的にやってるからなあ

325 ：デフォルトの名無しさん：2011/11/27(日) 21:09:41.49

出来損ないの言語仕様の埋め合わせを
設計でやってるから

326 ：デフォルトの名無しさん：2011/11/27(日) 21:10:04.37

>>324
それってその場ののりでなにも考えずにやってるだけでしょ？
それはDIじゃなくて、ただのパッチ

327 ：デフォルトの名無しさん：2011/11/27(日) 21:10:25.52

JavaでSingleton作る時にDouble-Checked Lockingが駄目なのって、まだ解消されてないんだっけ？

328 ：デフォルトの名無しさん：2011/11/27(日) 21:13:26.74

今はSingletonはDIの設定に任せるからあまり関係ないね。

システムではSingletonでも、テスト時には多数作りたいことがあったりで
コードで書くのは良くないパターンとされている。

329 ：デフォルトの名無しさん：2011/11/27(日) 21:17:24.20

>>327
volatileで解決できるようになってたと思うけど

330 ：デフォルトの名無しさん：2011/11/27(日) 21:26:25.10

>>329
え？そうだっけ？？
ダブル…の延長線上ではどうあがいで駄目だったような

331 ：デフォルトの名無しさん：2011/11/27(日) 21:29:47.21

>>321
違うな。

型推論は型検査じゃない派の論旨
・1+2と3は表現式として違うから1+2は3じゃない。
・3だからといって、1+2から求まったとは限らない。4-1かもしれないじゃないか。

型推論は型検査だ派の論旨
・1+2と3は表現が異なるだけで、どちらも3という値であり、同じことだ
・4-1も3だね。で、だからといって、1+2と3が異なる値にはならないけど、何か？

332 ：デフォルトの名無しさん：2011/11/27(日) 21:31:16.39

>>331
違うな。

>>321が正しい

333 ：デフォルトの名無しさん：2011/11/27(日) 21:32:16.55

設計とコーディングを別々の作業だと思ってるSIドカタ・・・かわいそｗ

334 ：デフォルトの名無しさん：2011/11/27(日) 21:34:34.27

かわいそうに、命令型のショボい型推論しか知らないと
>>321みたいに間違った理解をしてしまうんだね。

オブジェクト指向やってる人は視野が狭くて、
関数型のちゃんとした型推論を知らないんだ。

335 ：デフォルトの名無しさん：2011/11/27(日) 21:35:34.03

そもそも中身がstaticになるようなものを
盲目的に使って動くものができると思えんが

336 ：デフォルトの名無しさん：2011/11/27(日) 21:38:48.80

>>334
いやいや、>>321が正しいって言ってるだけ。お前は間違ってる。

337 ：デフォルトの名無しさん：2011/11/27(日) 21:39:22.92

これももう10年近く前の話か
ttp://www.ibm.com/developerworks/jp/java/library/j-dcl/

338 ：デフォルトの名無しさん：2011/11/27(日) 21:42:00.86

>>336
そう思えるのは、あんたが命令型のショボい型推論しか知らないからｗｗ
井の中の蛙だねえｗｗｗ

339 ：デフォルトの名無しさん：2011/11/27(日) 21:48:03.43

どう見ても>>321が正しいですな。

340 ：デフォルトの名無しさん：2011/11/27(日) 21:50:12.91

>>321が言うとおり、
納豆を指して「これは大豆だから」と言った人に
「これは大豆じゃないよ、納豆だよ」と言い出してるのが
型推論は型検査じゃない派のドカチン君ですねｗｗｗ

341 ：デフォルトの名無しさん：2011/11/27(日) 21:51:36.73

>>340
まさにその通り！

342 ：デフォルトの名無しさん：2011/11/27(日) 22:03:39.73

たまに居るね
自分の設計思想を信じ相手は馬鹿であると見下し
よくわからないしょぼいものしかつくれない

343 ：デフォルトの名無しさん：2011/11/27(日) 22:12:23.86

こういうことじゃないかと思う

・型推論は型検査じゃない派 --> 目的と結果を分けて考えよう
・型推論は型検査じゃない派 --> 目的と結果をを混同してもええやないけ

ここで、
・型推論の目的：型の整合性の検証(型が無矛盾であることの証明), >>318から引用
・型推論の結果：型検査および型宣言の省略化

自分は型推論は型検査じゃない派だな

344 ：デフォルトの名無しさん：2011/11/27(日) 22:16:23.06

>>343
型推論の目的>>318は微妙だなあ。その目的を満たすなら型推論しないほうが合目的的だし。

345 ：デフォルトの名無しさん：2011/11/27(日) 22:30:10.98

>>343
型推論の目的は、型検査をするための記述を少なくすることですよ。

346 ：デフォルトの名無しさん：2011/11/27(日) 22:35:34.92

>>343
型推論は型検査じゃない派しかいないぞw

347 ：デフォルトの名無しさん：2011/11/27(日) 22:36:30.25

型検査じゃない！派
型検査じゃない？派

348 ：デフォルトの名無しさん：2011/11/27(日) 22:46:14.77

>>346
おっと、ミスッたぜ。>>343を以下のように訂正する。

>・型推論は型検査じゃない派 --> 目的と結果を分けて考えよう
>・型推論は型検査だ派 --> 目的と結果をを混同してもええやないけ

349 ：デフォルトの名無しさん：2011/11/27(日) 22:48:56.56

型推論が型検査と一緒もしくは一緒じゃないことがわかることでどういう嬉しさがあるの？

350 ：デフォルトの名無しさん：2011/11/27(日) 22:53:00.61

>>349
型検査だけできるってことが理解できる。

351 ：デフォルトの名無しさん：2011/11/27(日) 23:06:51.07

>>350
ならJavaとかは型検査してるけど型推論しないから初めから結論でてるんじゃないの

352 ：デフォルトの名無しさん：2011/11/27(日) 23:07:56.39

>>344
その目的に前提を含めて書けば、

・暗黙の(=省略された)型宣言があっても検証(=証明)できること

になるね

これを実現するために推論が必要になった、という話だと思う

353 ：デフォルトの名無しさん：2011/11/27(日) 23:13:13.31

>>349
言語を利用する立場であれば、会話の中で両者を一緒にしても推定できるから、
たぶん支障は無いと思う。多くがこのケースだから、一般的には一緒でかまわない。

ただし、言語を実装する立場であれば、両者を明確に区別して定義/理解できないと
苦労するはめになる(過去の自分)

354 ：デフォルトの名無しさん：2011/11/27(日) 23:58:55.68

>>284
C++でも出来るぞ
オーバーロードが曖昧な場合はキャストが居る。

355 ：デフォルトの名無しさん：2011/11/28(月) 00:01:22.46

>>349
>>288みたいな馬鹿をぷげら出来る

356 ：デフォルトの名無しさん：2011/11/28(月) 00:04:59.69

ExampleType x = Function( 1, 2 );
が
auto x = Function( 1, 2 );
って書けるだけだろ。
何下らないことでひきずってんの？

357 ：デフォルトの名無しさん：2011/11/28(月) 05:44:12.34

どう考えても別物だろ
Javaは型検査してるけど、型推論できない
完全に使い分けできるじゃん

358 ：デフォルトの名無しさん：2011/11/28(月) 11:18:59.45

ここは設計とデザパタのスレだ

359 ：デフォルトの名無しさん：2011/11/28(月) 11:19:43.56

どっか他所のスレでやってくれ

360 ：デフォルトの名無しさん：2011/11/28(月) 18:25:31.70

>>355
いや、客観的に言って、バカはおまえ

361 ：デフォルトの名無しさん：2011/11/28(月) 18:33:01.05

全ての型検査は必ず型推論を伴う。
例えば、
double x = "abc";
は型エラーだが、これはxの型について
- double xという宣言からxはdouble型である
- x = "abc"からxはString型である
の２つの推論結果をunifyできないことからエラーを検出する。

全ての型推論は必ず型検査を伴う。
これは、表現式の型を１つ１つ確定していくプロセスにおいて
必ず矛盾がないかを検証するから。

全ての型検査は型推論を伴い、全ての型推論は型検査を伴うのであれば、
型検査と型推論は同じものの別名にすぎない。Q.E.D.

362 ：デフォルトの名無しさん：2011/11/28(月) 18:42:27.69

そのネタはどうでもいいから帰れ

363 ：デフォルトの名無しさん：2011/11/28(月) 19:09:56.75

このスレは実装技術についていけずに
設計と称して四角形と直線をひくしか脳がない
底辺SEの巣だからなｗ

364 ：デフォルトの名無しさん：2011/11/28(月) 19:12:06.15

>>361
多分お前が言ってる型推論と皆が考えている型推論は別のものだと思うよ？
其れすらわからないで俺スゲー垂れ流してるのがあわれすぐるｗｗｗ

365 ：デフォルトの名無しさん：2011/11/28(月) 19:13:58.94

自分の世界に生きてるヤツはほっとけよ。
こっちに引き戻そうとしたって無駄なだけだろ。

366 ：デフォルトの名無しさん：2011/11/28(月) 19:17:57.90

>>364
少なくとも２０年前には既に型推論と型検査は同一技術だというのが
関数型言語界隈での常識だったが？

自分の無知を自慢するのって、楽しい？

367 ：デフォルトの名無しさん：2011/11/28(月) 19:36:54.88

>>366
わかったからJAVAで型検査と型推論の分離ができている訳を教えてくれ

368 ：デフォルトの名無しさん：2011/11/28(月) 19:38:32.56

型システム自体がショボいから。

369 ：デフォルトの名無しさん：2011/11/28(月) 19:39:46.32

しかし、Javaしかわからない（というかJavaすらマトモにわかってない）馬鹿は
言うことがメチャクチャで笑えるｗ

370 ：デフォルトの名無しさん：2011/11/28(月) 19:58:16.81

度々このスレユースケース図の話題でるけど、
UML自体はOOサポートしてるだけで、OOを志向してる訳じゃないから
オブジェクト指向型システム設計とはあんまり関係ないよな。
UML全体としてみれば飽くまでラショナルプロセスを支えるツール。

371 ：デフォルトの名無しさん：2011/11/28(月) 20:13:20.15

話題に出てるのはユースケース図じゃなくてユースケースね

372 ：デフォルトの名無しさん：2011/11/28(月) 21:18:22.77

ユースケースサンタマリア

373 ：デフォルトの名無しさん：2011/11/28(月) 21:25:26.89

オブジェクト指向のオススメの書籍教えて

374 ：デフォルトの名無しさん：2011/11/28(月) 21:37:57.47

Bluebook

375 ：デフォルトの名無しさん：2011/11/28(月) 22:05:22.48

試験答案帳。表紙が青いことからこの名前がついています。主として作文形式の試験に使われます。

376 ：デフォルトの名無しさん：2011/11/28(月) 22:05:56.66

Blue Book
読み方：ブルーブック
Blue Bookとは、CD-EXTRAの仕様書のことである。
ソニーとオランダのPhilips社によって開発されたものである。

マルチセッションでデータを記録できるようになっており、
第一セッションには、音声データが、第二セッションには、
パソコン用のデータが保存される。このCD-Extraの仕様書の
表紙が青かったことから、Blue Bookという名称が付いた。

377 ：デフォルトの名無しさん：2011/11/28(月) 22:21:28.91

>>373
ないんだな、それが

378 ：デフォルトの名無しさん：2011/11/28(月) 22:58:23.56

PSの青本のことかと思ってしまう。
赤青緑

379 ：デフォルトの名無しさん：2011/11/29(火) 04:53:37.90

本当はブルーブックがいいけど、今ならパープルブックで我慢だな

380 ：デフォルトの名無しさん：2011/11/29(火) 06:03:09.37

オブジェクト指向入門のこと？

381 ：デフォルトの名無しさん：2011/11/29(火) 19:00:57.60

今はブラックブックだろ？

382 ：デフォルトの名無しさん：2011/11/29(火) 23:04:23.52

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

383 ：デフォルトの名無しさん：2011/11/30(水) 22:01:58.18

デザパタなんてだれも仕事では使ってないよな？
本気で使ってる奴いる？

384 ：デフォルトの名無しさん：2011/11/30(水) 22:08:43.06

やってみようとしたがVisitorがムズくてやめたｗ

385 ：デフォルトの名無しさん：2011/11/30(水) 22:42:09.75

そういうアプローチの仕方するもんじゃないような

386 ：デフォルトの名無しさん：2011/12/01(木) 01:50:25.19

煽りじゃなくこのスレレベル低いのな
ちょっとがっかりしたんだぜ

387 ：デフォルトの名無しさん：2011/12/01(木) 07:03:36.97

デザパタ使わずに仕事してる奴なんているのか？
Strategyすら使わないとなると逆に難しいだろ

388 ：デフォルトの名無しさん：2011/12/01(木) 08:32:49.79

デザパタの何使ってる？

389 ：デフォルトの名無しさん：2011/12/01(木) 09:18:36.19

AbstractFactory, Composite, Facade, Strategyあたりが多いかな。

390 ：デフォルトの名無しさん：2011/12/01(木) 09:55:31.05

ほー，Composite, Iterater, Visitor, Builderじゃないの？

391 ：デフォルトの名無しさん：2011/12/01(木) 10:05:18.94

じゃないからそう言ってるんだろ(´・ω・｀)

392 ：デフォルトの名無しさん：2011/12/01(木) 10:18:33.66

Singleton、Iterator、Observer は意図しなくても自然に使ってると思うんだが。

393 ：デフォルトの名無しさん：2011/12/01(木) 10:28:43.88

デザパタを使ったクラスライブラリ等を使うのと、
クラスライブラリ等を作るためにデザパタを使うのと、どっち？
後者のことだけ話題にしてると思ったが？

394 ：デフォルトの名無しさん：2011/12/01(木) 10:42:12.22

みんな後者だと思うよ。というか、デザパタって意図的に使おうとしなくても、
オブジェクト指向言語を使って普通に開発を進めてれば、
自然に当てはまる構造がコードのあっちこっちに見つかるようになると思うんだけど。

395 ：デフォルトの名無しさん：2011/12/01(木) 11:37:58.89

インターフェース的なもので抽象化するものは結構デザパタのどれかに当てはまるだろ。
むしろデザパタのほとんどがインターフェース的なもので抽象化されたものだとも言えるが。

396 ：デフォルトの名無しさん：2011/12/01(木) 19:41:14.73

Javaなんかコアクラス使ってるだけでデザパタべったりになるんじゃない?

397 ：デフォルトの名無しさん：2011/12/01(木) 21:10:45.59

MVVMはデザパタに入れても良いんだろうか
入れても良いなら毎回必ずと言っていいほど使ってる

398 ：デフォルトの名無しさん：2011/12/01(木) 21:46:07.84

MVCと同じで、原子的パターンじゃないから却下。
デザパタを組み合わせた、分子的なパターンを含め始めたらきりがない。

399 ：デフォルトの名無しさん：2011/12/01(木) 23:03:02.81

>>392
> Singleton
役に立ったためしがない
つか、どんなときに使ってるんだよ

400 ：デフォルトの名無しさん：2011/12/01(木) 23:11:55.37

百害あって一利無しだよな＞Singleton

401 ：デフォルトの名無しさん：2011/12/01(木) 23:24:29.89

動的型付け言語にはデザインパターンは不要。

デザインパターンは静的型付け言語が不便だからできた
バッドノウハウ。

402 ：デフォルトの名無しさん：2011/12/01(木) 23:49:15.39

IteratorとかObserverとかどう考えても型付け関係無いパターン多いだろ

403 ：デフォルトの名無しさん：2011/12/02(金) 00:12:49.58

>>401
まったくその通りだと思う
少なくともGoF本の著者陣はそれを認識しているし、たとえそうであっても
それらをパターンとして命名しカタログ化した点にGoF本の意義があると述べている
ところが、なぜか「デザインパターンに沿ってなければOOPにあらず」という
不思議な風潮を(特にジャバラから)よく耳にするのが笑えるところ

404 ：デフォルトの名無しさん：2011/12/02(金) 00:14:20.66

やった。馬鹿が釣れたｗ

デザインパターンってSmalltalkの世界から生まれたものなんだけどｗｗｗｗ

405 ：デフォルトの名無しさん：2011/12/02(金) 06:14:14.39

動的型付けにも部分的には使えるだろうけど、別に動的型付け用のデザインパターンを作った方がいいな

406 ：デフォルトの名無しさん：2011/12/02(金) 06:21:25.41

>>399
Cライブラリをラッパーしたユーティリティクラスみたいなもの
イミュータブルで値を保持させておきたいクラス

どちらも複数生成する必要がないしどこから参照されても問題ないからSingletonにしたんだけど何か問題あるかな？

Singletonは使いどころが難しい…

407 ：デフォルトの名無しさん：2011/12/02(金) 06:28:54.25

>>404
Smalltalkではパターンとして整理しなくても普通に使えていたイディオムを
Javaではいちいち形を決めて名前を付けて整理しないとうまく使えない、
ってことでしょｗ

408 ：デフォルトの名無しさん：2011/12/02(金) 08:42:14.90

だからその名前をつけたのが
Smalltalk時代なんだってばｗ

409 ：デフォルトの名無しさん：2011/12/02(金) 10:55:35.75

>>401
>動的型付け言語にはデザインパターンは不要。
これってどういうこと？デザパタと型付けは関係無いと思うが．
>バッドノウハウ
これは同意だが．

410 ：デフォルトの名無しさん：2011/12/02(金) 11:00:04.80

まったく不要かはともかく、ちまたによくあるJava前提のデザインパターンは動的型付けの言語じゃ不要なものは多い。

411 ：デフォルトの名無しさん：2011/12/02(金) 12:34:06.30

いやいや使ってるならまだ救えるが、デザパタ得意って奴は他で使えん
のが多い気がする

412 ：デフォルトの名無しさん：2011/12/02(金) 13:06:29.55

デザパタ得意って何か怖いｗ
得意かどうかという、ステータス的捉え方が恐ろしい。

413 ：デフォルトの名無しさん：2011/12/02(金) 13:27:32.20

得意って比較的よく知ってて肯定的くらいのことだろ。

414 ：デフォルトの名無しさん：2011/12/02(金) 17:46:47.54

手段と目的を取り違えてるニオイがするってことさ

415 ：デフォルトの名無しさん：2011/12/02(金) 17:52:39.69

>>409
例えばStrategyなんかは共通のインターフェースを用意することにより、戦略を使い回すけど動的型付け言語ならそもそもインターフェースを用意する必要なく使い回せるということじゃないかな

416 ：デフォルトの名無しさん：2011/12/02(金) 17:57:55.36

デザインパターンは適したところに採用すれば素晴らしく便利なもの
しかし適材適所というのは別にデザインパターンに限らない一般的な話

だから変な使い方をする奴がいるからといってデザインパターンを否定するのは間違い

あとデザインパターンはオブジェクト指向の感覚を掴むきっかけとしては良いものだと思う

417 ：デフォルトの名無しさん：2011/12/02(金) 18:52:47.96

ぶっちゃけ、先人の作ったコードの中から似た物抽出して
それらしい名前つけただけの、なんちゃって技術だろ？

縛られ過ぎる方がおかしいw

418 ：デフォルトの名無しさん：2011/12/02(金) 20:06:28.43

>>415
動的型付けは、インターフェースを書かなくて済むだけで、
最低限のインターフェースを持ってないとどのみちエラーになるだろ。(nullや転送できるものを除く)
デザパタと動的型付けかどうかは関係ない。

419 ：デフォルトの名無しさん：2011/12/02(金) 20:13:26.76

>>406
そういう使い方をするものをシングルトンとはいわんだろ。
シングルトンってのは、デバイスの書き込み制御を独占管理したり、
アプリケーションに送られてくるメッセージを独占管理する時に使うもん。

あと、C++系固有の話だが、グローバル変数と違い、
初期化順序を制御できるという点がある。

420 ：デフォルトの名無しさん：2011/12/02(金) 21:08:27.72

このスレにふさわしい人たちが現れ始めたような気がする。

421 ：デフォルトの名無しさん：2011/12/02(金) 21:17:30.86

>>414
そもそもオブジェクト指向＆デザパタ自身がそのニオイがするのだが

422 ：デフォルトの名無しさん：2011/12/02(金) 21:22:15.53

オブジェクト指向＝縦割り
デザパタ＝輪切り
こんな感じかえ？

423 ：デフォルトの名無しさん：2011/12/02(金) 21:30:37.66

>>416
あなたはオブジェクト指向とは何か、デザインパターンのそれぞれが
何であるかをきちんと言えますか？感覚ではなく。

424 ：デフォルトの名無しさん：2011/12/02(金) 21:35:31.42

>>423
デザインパターン = 書籍『オブジェクト指向における再利用のためのデザインパターン』で紹介されたパターンの事

425 ：デフォルトの名無しさん：2011/12/02(金) 22:08:04.54

某言語は何でメソッドがオブジェクトじゃないんだろうな。
double Function( double ) function = Math.abs;
function( 100 );
実際にメモリにオブジェクトとしての実体は持たなくてもいいから、
参照に引き渡されたら自動的にオブジェクトを生成してくれりゃ良かったんだけど。

FunctionDoubleDouble function = MathLibrary.abs;
function.call( 100 );
まぁ、現状でも同等のものを作れないわけじゃ無いんだけれども。

426 ：デフォルトの名無しさん：2011/12/02(金) 22:11:20.08

>>410
> まったく不要かはともかく、ちまたによくあるJava前提のデザインパターンは動的型付けの言語じゃ不要なものは多い。

いや、全くわかってないｗ

デザインパターンは実装ではなくて考え方。

Java前提のデザインパターンとか
動的型付け言語で不要とか言うのは、
デザインパターンの本質をわかってない。

お前が言ってるのは実装が不要ってだけの話だろ。

いや、全くわかってないｗ

427 ：デフォルトの名無しさん：2011/12/02(金) 22:27:56.33

>>426
>デザインパターンは実装ではなくて考え方。
各デザインパターンの”考え方””本質”をきちんと言ってみてくれるかい？

428 ：デフォルトの名無しさん：2011/12/02(金) 22:30:18.12

>>427
クラスを変更せず、オブジェクト構造により拡張していく疎結合主義だろ。

429 ：デフォルトの名無しさん：2011/12/02(金) 22:44:58.89

>>419
Singletonって使い方限定されているものなの？
クラスのインスタンスを1つしか生成できないようなものをSingletonというのかと思っていたけど

430 ：デフォルトの名無しさん：2011/12/02(金) 22:47:20.18

>>427
結城本から

デザインパターンはクラスライブラリそのものではない

デザインパターンはクラスライブラリよりも一般的な概念です。

具体的なプログラム例を読むことも理解の助けにはなりますが、その特定の
プログラムだけがAbstract Factoryパターンなのではありません。肝心なのは
どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるか、なのです。

431 ：デフォルトの名無しさん：2011/12/02(金) 22:51:15.85

>>429
状態が1つでいいなら、モノステートでいいだろ。
実体が一つである理由を考えてみ。

432 ：デフォルトの名無しさん：2011/12/02(金) 22:52:40.25

「Rubyには○○パターンは不要！」

「え？じゃあRubyだとどうするの？」

「こうするだけで実装できる！」

「なにが実装できるの？」

「○○パターンだけど」

「そうだね、それがRubyにおける○○パターンの実装だよ」

将来>426が経験することになる実話ｗ

433 ：デフォルトの名無しさん：2011/12/02(金) 22:52:59.96

>>426じゃなくて>>410の間違い。

434 ：デフォルトの名無しさん：2011/12/02(金) 22:55:50.34

>>423
デザパタは>>424の通り
オブジェクト指向プログラミングは、対象物を中心に置いたプログラミング
100円を両替するをプログラムで表すと、Moneyクラスのexchangeメソッドを引数100を与えて実行する、money.exchange(100) つまりI exchange money 100
SVOのOでObject目的語つまり対象を意味する
これを中心に置いている

OOPではないC言語はで同じことをするとexchange(money,100)moneyも100も引数として同列に扱う
ここが大きな違い

435 ：デフォルトの名無しさん：2011/12/02(金) 23:04:04.45

>>431
状態が1つならSingletonにせずにstaticクラスにしてしまえばいい
状態を複数許して実体を1つにしたいときにSingletonを使うということであってる？
何故実体を1つにしたいかは、複数から操作されてしまうと困るから？
いまいちわかってないや

436 ：デフォルトの名無しさん：2011/12/02(金) 23:04:26.21

>>429
状態が連続していることを期待した使い方をするとグローバル変数と同じハメになる。
例えば、メソッド間の値の受け渡しに使えば、無限ループが発生することもある。
分岐の予想も困難になる。
まず、そういう用途に使っちゃいけないという点で限定される。
基本的に、どこからどう操作しようと他に影響が無いものじゃないといけない。
それから、シングルトンは、オブジェクトとしての実体をもっている事が一番重要。
CharDevice.Instance().Write(""); のような直接メソッドを呼ぶ用途じゃなく、
Device device = CharDevice.Instance(); のようにインスタンスを突っ込む用途に使用する。

437 ：デフォルトの名無しさん：2011/12/02(金) 23:19:53.04

昔は順次、分岐、繰り返しの3つのデザインパターンしかなかったよな
などとつぶやいてみる

438 ：デフォルトの名無しさん：2011/12/02(金) 23:21:11.41

>>434
あんまりOOらしくないな。あと、Cで書くとじゃなく手続きで書くとじゃね。
金銭の例で言うと、レートのほうが解りやすい。

const Rate jp_yen_to_us_dollar( 75 );
const Rate us_dollar_to_jp_yen = jp_yen_to_us_dollar.Inverse();

jp_yen_to_us_dollar.Conversion( 100 ); // 100円をドルに換算
jus_dollar_to_jp_yen.Conversion( 100 ); // 100ドルを円に換算

クラスだけじゃなく、オブジェクトとして考えることが重要ね。

439 ：デフォルトの名無しさん：2011/12/02(金) 23:23:40.67

デザインパターンを明確に、正確に理解している　＝　オブジェクト指向を明確に、正確に理解している

440 ：デフォルトの名無しさん：2011/12/02(金) 23:27:53.72

>>424
答えてくれてありがとう。
でもそれが答えになっていないことはあなた自身が分かっていますよね。
>>434
まじめに答えてくれてありがとう。
そうですね。最初はそういう説明をしたりされたりするね。
”オブジェクト指向”を”対象中心”と言い換えてくれたんですね。
では”対象中心”とは何かと聞きたくなりますが。
例がついているのはありがたいですね。ＳＶＯのＯっていうのはほんとですか？
Ｓは中心にはならないのですね？

441 ：デフォルトの名無しさん：2011/12/02(金) 23:29:51.28

>>424や>>434のようなデタラメをもっともらしく言うのは頼むからやめてくれよ
冗談のつもりなのかもしれないが、>>420のように騙される人も出てくるからさ

442 ：デフォルトの名無しさん：2011/12/02(金) 23:31:56.69

デザインパターンはドカタの方がよく知ってるなｗ

443 ：デフォルトの名無しさん：2011/12/02(金) 23:32:20.33

>>441
具体的な正しい説明を頼む

444 ：デフォルトの名無しさん：2011/12/02(金) 23:32:25.98

俺はドカタじゃないから、デザインパターンなんて知らなくていいんだよ。とか
本気で言ってそうｗｗｗ

445 ：デフォルトの名無しさん：2011/12/02(金) 23:32:57.44

動的型付け言語にはデザインパターンはないとかいうような
バカどもですからねｗｗｗ

446 ：デフォルトの名無しさん：2011/12/02(金) 23:34:23.72

Object = 目的語

これを言い出す人多いよね。自動詞的メソッドをどう説明するんだろうか？
Thread#runなど。

447 ：デフォルトの名無しさん：2011/12/02(金) 23:34:56.79

>>439
だとすれば益々>>427に答えないといかん

448 ：デフォルトの名無しさん：2011/12/02(金) 23:35:20.78

449 ：デフォルトの名無しさん：2011/12/02(金) 23:38:17.45

>>440
SVOのOはObject
OOPのOもObject
smalltalkのメッセージ送信の対象という意味でも合致していると思ってる

450 ：デフォルトの名無しさん：2011/12/02(金) 23:39:34.46

>>424 以上の答えは無いだろうけどな。

451 ：デフォルトの名無しさん：2011/12/02(金) 23:41:30.04

>>449
( Message object object object object )
これどうすんの？

452 ：デフォルトの名無しさん：2011/12/02(金) 23:42:53.98

>>446
Threadクラスに対してrunというメッセージを送信する

I send run message to Thread
これの目的語というのが正しい気がする

453 ：デフォルトの名無しさん：2011/12/02(金) 23:44:28.14

>>448
結局結城本では、
デザインパターンとは，どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるかであると言っているのですね。
各デザインパターンについてそういう形の説明ができますか？

454 ：デフォルトの名無しさん：2011/12/02(金) 23:44:31.26

>>451
それはどういう意味？

455 ：デフォルトの名無しさん：2011/12/02(金) 23:45:25.58

>>454
マルチメソッド

456 ：デフォルトの名無しさん：2011/12/02(金) 23:45:46.24

>>431
横レスだがモノステートは調べて今知った。でもこれだと、派生クラスに適用したい場合はどうしたらいい？
あと、GoF 本は Singleton の目的を「インスタンス数を１つだけに制限して、それにアクセスするグローバルな方法を提供する」
って書いてるだけだから、俺は >>429 で合ってると思うんだが。出来たら、もうちょっと詳しく説明してくれないか？俺の頭では分からんので。

457 ：デフォルトの名無しさん：2011/12/02(金) 23:50:14.90

>>453
はい、この場合のクラスやインターフェースというのは
Java用語ではなく一般的な意味です。
それは、「その特定のプログラムだけがAbstract Factoryパターンなのではありません」と
書いてあることからも明らかです。

458 ：デフォルトの名無しさん：2011/12/02(金) 23:51:06.79

>>453
もしかしてデザインパターンを知らないの？

自分が、if文を教えて下さいと
言っているのと同じだって分かってるかな？

459 ：デフォルトの名無しさん：2011/12/02(金) 23:52:42.03

>>456
何を見た？ぐぐって先頭のページにでてくるモノステートは間違ってるからな。

class Mono
{
       static int value1;
       static int value2;
public:
       int Method()
       {
              return value1;
       }
}:
Mono mono;

モノステートはこういうヤツ。当然親も子も継承できる。

460 ：デフォルトの名無しさん：2011/12/02(金) 23:54:24.79

やっぱり、デザインパターンとかオブジェクト指向に関しては
Javaプログラマがかなり先を言ってるね。

461 ：456：2011/12/03(土) 00:00:08.87

>>459
いや、既に親クラスがあって、その派生クラスのインスタンス数を制限したい場合。
class Base { public virtual int Hoge { return 0; } }
class Sub : Base { public override int Hoge { return 1; } }

この場合で、Sub のインスタンスを1個にしたい場合はどうしたら良い？

462 ：デフォルトの名無しさん：2011/12/03(土) 00:00:40.83

>>460
デザインパターンの市販本のほとんどが、Javaを使って説明しているからね。

463 ：デフォルトの名無しさん：2011/12/03(土) 00:01:49.43

>460
実はそのデザパタとかＯＯが遅れているということもあり得る

464 ：デフォルトの名無しさん：2011/12/03(土) 00:02:02.55

マーティンファウラーとケントベックがオブジェクト指向の先端という感じがする
この２人はJavaというよりsmalltalk

というかオブジェクト指向の発祥ってどこなの？

465 ：デフォルトの名無しさん：2011/12/03(土) 00:02:12.81

>>462
Java以外にもたくさんあるぞ。
Amazonで「○言語デザインパターンで」調べてみ。

466 ：デフォルトの名無しさん：2011/12/03(土) 00:04:11.21

>>461
モノステートは状態を1つに保つだけ。
インスタンスの数は制限しない。
インスタンスの数を制限したいならシングルトン。

>状態が1つでいいなら、モノステートでいいだろ。
前にこう書いたろ。

467 ：456：2011/12/03(土) 00:06:52.86

>>466
んじゃ、>>461 のケースだとモノステートは使えんのね。ありがと。

468 ：デフォルトの名無しさん：2011/12/03(土) 00:07:00.38

プログラムが綺麗にバグなくかければ、オブジェクト指向だろうが、関数型だろうがデザパタだろうが何でもいいです(´・ω・｀)
実際はその辺のハイブリッドだしな。

469 ：デフォルトの名無しさん：2011/12/03(土) 00:08:47.71

軽くぐぐったらSimulaからsmalltalkで普及みたいだな

メッセージ送信を唄っているsmalltalkのオブジェクト指向に合致しないのものは、また別のオブジェクト指向と捕らえるのが正しいのかね

クラス、型システムをオブジェクト指向として捉えて広めたのがまた別に誰かいた気がする

470 ：デフォルトの名無しさん：2011/12/03(土) 00:10:36.03

>>468
バグの問題じゃないだろ。
OOのメリットは、既存のコードを変更しないで済むことなんだから。

471 ：デフォルトの名無しさん：2011/12/03(土) 00:15:40.66

質問。
デザインパターンについて、３０歳のＳＥに聞きました。
「あなたは、一パターンでもよいから、デザインパターンを適用したことがありますか？」
はい、と答える人は何人いると思う。

472 ：デフォルトの名無しさん：2011/12/03(土) 00:16:36.97

>>471です。
１００人に聞きました、が抜けていた。スマン。

473 ：デフォルトの名無しさん：2011/12/03(土) 00:16:57.44

>>467
そもそも何でインスタンスを一つにしたいんだ？

map[ SINGLETON_A ].Method();
map[ SINGLETON_B ].Method();

とかしたいわけじゃないんだろ？

474 ：デフォルトの名無しさん：2011/12/03(土) 00:18:47.52

>>471
ドカタなら日常茶飯事に使ってるだろｗ

475 ：デフォルトの名無しさん：2011/12/03(土) 00:20:19.77

オブジェクト指向とは - はてなキーワード http://d.hatena.ne.jp/keywordtouch/%A5%AA%A5%D6%A5%B8%A5%A7%A5%AF%A5%C8%BB%D8%B8%FE

476 ：456：2011/12/03(土) 00:26:25.89

>>473
インスタンスを一個に絞りたいことはよくあると思うんだけど？
例えばクラスのメタ情報とか、コードで定数を定義するときとか。
基底クラスで既定値を定義しておいて、派生クラスで変更分だけ上書きして使えば、コードの見通しが良いでしょ？

477 ：デフォルトの名無しさん：2011/12/03(土) 00:32:07.06

>>476
それはインスタンスじゃなくて状態を一つに絞りたいだけじゃないか？
あと、シングルトンは、親クラスを持つことはできるけど、子クラスを持つことは不可能だからね。

ちなみに、英語圏だとファクトリー用途が多いらしい(ファクトリーのメモリー消費節約のため)。

478 ：デフォルトの名無しさん：2011/12/03(土) 00:47:12.84

シングルトンの問題は、モックでの差し替えが困難なために、テストしづらくなる事。

レガシー本の例では、DBコネクションをシングルトンにした場合の呼び出し側のテストの書き方について書かれてる。

479 ：デフォルトの名無しさん：2011/12/03(土) 00:50:26.49

ファクトリークラスって、何処までが範疇なのかね？

RequiredRuleFactory factory(param);
Rule *rule = factory.Create(arg);
こういうのが一般的だろうけど、

見た目さえ変えりゃ、これもファクトリーみたいなもんじゃん。
Query query("select %1 from table");
Result *result = query.Post(&db);

480 ：デフォルトの名無しさん：2011/12/03(土) 00:52:50.02

>>478
だよね。

だから最近はDIコンテナ側の設定で
シングルトンにするかどうかを決めるようになってきてるよね。

動的型付け言語の世界にも
早く普及してくれるといいんだけど。

481 ：456：2011/12/03(土) 00:54:40.73

>>477
確かに状態を一つにしたいんだけど、その状態がインスタンスでないと多態が使えなくて困るので……。例えばこんな感じ。
class MetaData { public virtual string GetCode() { return "Unknown"; }
class PersonMetaData : MetaData {
public static MetaData Instance = new PersonMetaData();
public override string GetCode { return "Person"; }
}

main() { PrintMetaData(PersonMetaData.Instance); }
PrintMetaData(MetaData data) { print(data.GetCode); }

482 ：デフォルトの名無しさん：2011/12/03(土) 00:56:41.93

>>479
Postの戻り値がなんなのかさっぱりわからんけど、

もしそれがResultがインターフェース（抽象クラス）であるのなら
それはファクタリーだよ。

デザインパターンの本質
それは、実装ではなくて考え方なんだから
見た目（実装）は関係ない。

それがファクトリーの考え方による設計で、
実際にファクトリーの動作をしているのなら
それはファクトリーパターン

483 ：デフォルトの名無しさん：2011/12/03(土) 01:03:18.66

>>481
だから >>459のモノステートで十分じゃね？

484 ：456：2011/12/03(土) 01:14:14.58

>>483
そかな？
モノステートだと。基底クラスもモノステートじゃなきゃ new するたびにメモリ確保が走っちゃうし、インスタンス毎に値が書き換えられちゃうし。
Singleton の方が安心して使えると思うんだけど。

485 ：デフォルトの名無しさん：2011/12/03(土) 01:22:43.11

>>484
ああ、子の状態を一つにしたいのか。
それならシングルトンの方が向いてるかもね。
題材がシングルトンに向いてるかは別だけど。

486 ：デフォルトの名無しさん：2011/12/03(土) 01:23:24.32

明らかにインスタンスを１つに絞りたいのが目的の割にはどっからでもアクセスできすぎる
しかもインスタンスの生成場所まで変化するのはやりすぎ
あきらかに不具合

487 ：デフォルトの名無しさん：2011/12/03(土) 01:25:25.67

なんでメソッドの引数から渡すのを嫌ってグローバルアクセスにまわしたの？
ここの納得できる強力な理由がほしい

488 ：デフォルトの名無しさん：2011/12/03(土) 01:30:19.88

>>486 privateなコンストラクター書いてないし単にミスじゃね？

489 ：デフォルトの名無しさん：2011/12/03(土) 01:30:36.29

別に引数から渡していいんだよ。

490 ：デフォルトの名無しさん：2011/12/03(土) 01:35:32.55

>>487
多分意図がちがうと思う。列挙型の要素みたいな感じなんだろ。
変化するもんじゃなさそうだ。
まぁ、だったらコンストラクターprivateにして、オブジェクト側は、
public const static MetaData PERSON_META_DATA = new PersonMetaData()でいいと思うけど。

491 ：456：2011/12/03(土) 01:45:55.35

>>485
ごめんね、頭の中が多態で使う～でいっぱいになっててソースが不適切だった。
最初のソースでちゃんと説明していれば、頭の方で終わってた話だった。ごめん。

>>490
そうそう、Singleton の話だから private コンストラクタは書かなくても伝わるだろうと端折っちゃった。
const は書き忘れた。

492 ：490：2011/12/03(土) 01:49:14.38

よくよく考えたら全然良くないわ。そもそも>>476の話からすると、
クラスごとのメタ情報を持ちたいだけ。
だったら、そのメタ情報を付与するクラスにpublic MetaData MetaData();ってメソッドもたせて、
そのクラスの中に、private static MetaDate metaData = new MetaData( "Person" );とか持たせておけばいい。
まぁ、この方法だと既存のクラスには使えないけどね。まぁ、そういう場合はトレイトだ。

493 ：456：2011/12/03(土) 01:56:54.84

>>492
あくまで例だから、あんまり突っ込まんといて。
メタ情報を付加させる場合も実際はインナークラスとして定義したり、ジェネリックを使ったりと色々だから。

494 ：デフォルトの名無しさん：2011/12/03(土) 01:59:32.30

>>470
コードの再利用の目的の一つにバグの低減があるとは思わないのかね？

495 ：デフォルトの名無しさん：2011/12/03(土) 02:00:19.19

コードを再利用したら一つのバグが
何百個のバグになるだろ。

496 ：デフォルトの名無しさん：2011/12/03(土) 02:09:25.34

何百ヶ所のバグを修正するよりは、一ヵ所のバグを修正する方がマシだろ。

497 ：デフォルトの名無しさん：2011/12/03(土) 08:00:27.07

>>480
動的型付けならシングルトンでもモックに差し替えるの簡単だから
普及しないと思うよ。必要無いもの。

498 ：デフォルトの名無しさん：2011/12/03(土) 09:47:42.48

>>468
その通り

499 ：デフォルトの名無しさん：2011/12/03(土) 09:51:28.65

漏れは２年間ほど掛かったが、オブジェクト指向設計をマスタしました。
２，３のデザパタも習得しました。
これから残りのデザパタを習得するつもりです。
そこで教えてもらいたいのですが、どのデザパタが現場では使われますか。
全部なら全部でもよいのですが、よく使われるものは何か知りたいのです。
列挙していただけたら非常に助かります。

500 ：デフォルトの名無しさん：2011/12/03(土) 09:53:43.85

>>470
>OOのメリットは、既存のコードを変更しないで済むことなんだから。
この俗説ほんとか？スパゲッティもまたそうやってできたのだが

501 ：デフォルトの名無しさん：2011/12/03(土) 10:25:36.25

>>500
既存のコードを修正しないで新たな機能を追加することができる
その機能を実装する（使う）ときは当然コードの修正は必要
しかしその使うという意志を表明している部分を変更するだけで済む

機能の追加と実装を分けて行えるのがメリットだと思う

502 ：デフォルトの名無しさん：2011/12/03(土) 10:29:36.06

>>499
>>388 から同じ話題が出てる。ただ、現場で頻出するパターンを抽出して名前を付けたのがデザパタなので、
全部の名前と目的ぐらいは知っておいて損はないよ。一度 GoF 本を通して読んでおくといい。

503 ：デフォルトの名無しさん：2011/12/03(土) 11:38:25.79

>>501
OOでそれが出来る事に異論は無いが、OO以外では出来ないと思った理由は？

504 ：デフォルトの名無しさん：2011/12/03(土) 12:03:56.73

>>502
さんくす。
やはり全部ですかね。

505 ：デフォルトの名無しさん：2011/12/03(土) 12:19:28.84

>>503
ポリモーフィズムが実現できればOK
C言語ではできない

506 ：デフォルトの名無しさん：2011/12/03(土) 12:37:23.48

Cでも関数ポインタとか使えばできるだろ

507 ：デフォルトの名無しさん：2011/12/03(土) 12:46:08.43

組込みだとOOA、OODで開発進めて
実装はANSI Cという世界だったりするよ

508 ：デフォルトの名無しさん：2011/12/03(土) 13:20:03.35

確かこんな感じにできるな

【第4回】多態性（2/3）：CodeZine
http://codezine.jp/article/detail/3709?p=2

>>503に解答すると
オブジェクト指向"言語"以外でもできない　というわけではない
手続き型言語だとしても　"オブジェクト指向"　を採用することにはなる
しかしその場合オブジェクト指向"言語"ほどオブジェクト指向を容易に実現することができない

よってOOという思想を使わないと実現できない

ってことになるんじゃないのかな

509 ：デフォルトの名無しさん：2011/12/03(土) 13:21:05.82

カプセル化もC言語で実現できるし継承も無理矢理実現できる
極端な話他の言語の多くはC言語で作られているのだからできないわけがない
じゃあC言語は、オブジェクト指向言語や関数型言語なのか？というとそんなことはない

510 ：デフォルトの名無しさん：2011/12/03(土) 13:37:07.72

>>508
ポリモーフィズムひとつとっても、OOPのそれは
subtype polymorphismというポリモーフィズムの一種にすぎない。
OOという思想を使わないと実現できないってことは無いよ。

511 ：デフォルトの名無しさん：2011/12/03(土) 13:38:12.39

>>432
> 「Rubyには○○パターンは不要！」
>
> 「え？じゃあRubyだとどうするの？」
>
> 「こうするだけで実装できる！」
>
> 「なにが実装できるの？」
>
> 「○○パターンだけど」
>
> 「そうだね、それがRubyにおける○○パターンの実装だよ」
>
>
> 将来>426が経験することになる実話ｗ

>>426じゃなくて>>410の間違い。

↑はすでに>>410に書いてある通りじゃん。

512 ：デフォルトの名無しさん：2011/12/03(土) 13:56:24.05

>>510
ポリモーフィズムの実現にOOという思想を使わないと実現できない
ということは言ってないよ

>>470,>>500,>>501,>>503の流れとして、OOのメリットの1つはポリモーフィズムだよ
と言っているだけ

513 ：デフォルトの名無しさん：2011/12/03(土) 14:56:48.69

>>501
>既存のコードを修正しないで新たな機能を追加することができる
そのカラクリは要するになんだっけ？

514 ：デフォルトの名無しさん：2011/12/03(土) 17:45:07.71

>>513
ポリモーフィズム
それはOOの1つのメリット

これに何か問題ある？

515 ：デフォルトの名無しさん：2011/12/03(土) 17:53:30.03

>>514
俺には難しい説明だな。
それにポリモーフィズムってマイナーな特徴という認識なのだが

516 ：デフォルトの名無しさん：2011/12/03(土) 17:56:49.38

>>514
OO以外でも実現できるポリモーフィズムを
OOのメリットと呼ぶのに違和感がある

517 ：デフォルトの名無しさん：2011/12/03(土) 18:05:01.93

>>514 >>515 >516
ＯＯが何であるかがはっきりしていないんだからあまり意味のない
コメントだな

518 ：デフォルトの名無しさん：2011/12/03(土) 18:17:36.32

最低限このへんは読んでから書き込むべき
ttp://lucacardelli.name/Papers/OnUnderstanding.A4.pdf

519 ：デフォルトの名無しさん：2011/12/03(土) 18:23:07.26

>>516
まずOOのメリットはポリモーフィズムだけではなく、一般的にはカプセル化、継承もそれに加わる

あとOO以外で実現というのがそもそもおかしい

OO以外ではなく、オブジェクト指向”言語”以外でも実現できるというのは同意
手続き型言語でもオブジェクト指向の思想は反映できるということ

だと思ってる

520 ：デフォルトの名無しさん：2011/12/03(土) 18:32:31.54

>>518
だれに言ってるのかどこを読めと言ってるのか知らんがそういうのは
踏まえたうえでの議論だと思うが

521 ：デフォルトの名無しさん：2011/12/03(土) 18:41:58.66

>>518
ML polymorphism がｱﾋｬってのはわかった

522 ：デフォルトの名無しさん：2011/12/03(土) 18:48:15.75

>>520
1.3章あたりに polymorphism のざっくりとしたレビューが書いてあるから、そこじゃね？
OOP の polymorphism にも触れてる

523 ：デフォルトの名無しさん：2011/12/03(土) 18:59:14.45

>>519
ポリモーフィズムもカプセル化もオブジェクト指向に固有のコンセプトじゃない
関数型言語にだってある

524 ：デフォルトの名無しさん：2011/12/03(土) 19:03:54.05

継承はユニーク

525 ：デフォルトの名無しさん：2011/12/03(土) 19:19:33.46

アグリゲーション・コンポジション辺りは？

526 ：デフォルトの名無しさん：2011/12/03(土) 19:22:25.60

>>523
それはマルチパラダイムということじゃなくて？
関数型言語の定義要素の1つとしてポリモーフィズムもカプセル化もあるの？

527 ：デフォルトの名無しさん：2011/12/03(土) 19:34:37.47

>519
オブジェクト指向の思想って？
与太話になりそうで好かん

528 ：デフォルトの名無しさん：2011/12/03(土) 19:37:32.78

>>526
SMLにはポリモーフィズムもカプセル化（モジュールの）もあるけど
オブジェクト指向言語という人はいないと思う

529 ：デフォルトの名無しさん：2011/12/03(土) 21:31:40.86

>>528
ということはオブジェクト指向とそうじゃないものわ分けるには、ポリモーフィズム、カプセル化とは別の基準があると思ってるということだと思うけどそれはなんなの？

それともオブジェクト指向というものをそもそも認めないということ？

530 ：デフォルトの名無しさん：2011/12/04(日) 01:45:35.22

>>529
528じゃないが、原理の面から言って、オブジェクト指向かどうかは、
オブジェクトに指向してるかどうかが基準であって、
OOPLかどうかは、OOPをすることを目的として
言語が設計されてるかどうかの問題。

ある言語を使ってOOP出来るかどうかによって
その言語がOOPLかどうか決まるわけじゃない。

SMLは、オブジェクトの連携によって駆動するプログラムを
作るために設計された言語なの？

ちなみに俺は多態やらカプセル化やらは、OOのメリットだとは思ってない。
OOである方法論の単なる構成要素のうちの1つだと思ってる。

531 ：デフォルトの名無しさん：2011/12/04(日) 08:36:14.33

>>530
＞ある言語を使ってOOP出来るかどうかによって
＞その言語がOOPLかどうか決まるわけじゃない。
ここは>>519の通り同意見。

ではそのOOP出来るというのはどういうことを指すのかを知りたい
ポリモーフィズム、カプセル化、継承できることを指すのかと思っていたけど、
確かにこの3つは、何かを目指した手段と言われれば納得

その目指す先は「オブジェクトの連携によって駆動するプログラム」？
オブジェクトの連携によって駆動するプログラム　とは具体的にどういうこと？

532 ：デフォルトの名無しさん：2011/12/04(日) 09:38:50.28

破壊的操作（副作用）に対するスタンスがOOPと関数型言語では違う気がする

関数型では破壊的な操作を必要最小限にする方向を目指すけど、
オブジェクト指向ではそんなこと無くて、その代りに
レースコンディションの解消はオブジェクトが各自の責任で行う

533 ：デフォルトの名無しさん：2011/12/04(日) 09:55:58.55

>>530
>オブジェクトに指向してるかどうかが基準であって
だからそのあなたが大事にしている「オブジェクトに指向してる」って
いうのはどういうことなの？

534 ：デフォルトの名無しさん：2011/12/04(日) 10:11:45.44

昨日、コンポジット、プロキシパターンを勉強した。
コンポジットには感激した。これは使える。

535 ：デフォルトの名無しさん：2011/12/04(日) 10:28:38.10

>>534
>コンポジットには感激した
その大部分は再帰に感激したのかな？それとも

536 ：デフォルトの名無しさん：2011/12/04(日) 10:35:11.95

>>526
型クラス(typeclass)とか？
これは、どっちかというと、オーバーロードのニュアンスが強いから、ちょっと違うか
日本語訳も多相が使われるし

537 ：デフォルトの名無しさん：2011/12/04(日) 10:52:24.17

>>532
それは関数型言語とそれ以外の言語の比較であって、オブジェクト指向の特徴とは言えないような…

538 ：デフォルトの名無しさん：2011/12/04(日) 11:07:06.06

>>535
再帰はもちろんだが、単独者と部下持ちの区別をパターンでやってしまうところがよい。

539 ：デフォルトの名無しさん：2011/12/04(日) 11:22:16.90

>>535
区別？むしろ同一視するんじゃなかったっけ
細かくてスマン

540 ：デフォルトの名無しさん：2011/12/04(日) 11:35:19.65

>>539
＞＞538です。細かいことはSEとしてはよいことです。
区分という表現は曖昧でした。エレメントがあるかないかを見て分別しているでした。

541 ：デフォルトの名無しさん：2011/12/04(日) 14:31:35.80

>>519
継承も多態性もカプセル化もメリットなんかじゃないだろ。
「ウチの車のメリットはV10エンジンを積んでることです」なんていうのかよ。
「リッター80kmで、1秒で100Kmまで出ることです」ってのがメリットだろ。

542 ：デフォルトの名無しさん：2011/12/04(日) 14:37:11.89

リッター80kmで、1秒で100Kmまで出る
エンジンを積んでるのはメリットだけど？

もしかして継承や多態性やカプセル化で
何が出来るか知らないってこと？
そこから説明しないといかんの？

543 ：デフォルトの名無しさん：2011/12/04(日) 14:47:25.08

>>542
「V10エンジン」を積んでることは別にメリットじゃない。
同じ性能出るエンジンなら別のエンジンでも構わない。

同じことが出来るのであれば、別に継承である必要でもないし、
カプセル化である必要もないし、多態性である必要もない。

544 ：デフォルトの名無しさん：2011/12/04(日) 14:52:53.90

継承だって、サブクラス化や、転送とか環境により別の実現方法があるし、
カプセル化だってOO的な手法じゃなくクロージャで実現する方法もある。
多体性というならドライバ関連でOO以前からありふれてた
OOのメリットとは言わん。

545 ：デフォルトの名無しさん：2011/12/04(日) 14:54:41.81

ということで極論すれば
アセンブラでOKと言いたいわけかｗ

546 ：デフォルトの名無しさん：2011/12/04(日) 14:55:47.66

>>540
曖昧なんじゃない、不適切だ

547 ：デフォルトの名無しさん：2011/12/04(日) 14:55:53.00

クロージャーじゃなくても
ジャンブで実装できるしな。

548 ：デフォルトの名無しさん：2011/12/04(日) 14:59:25.39

>>544
クロージャでカプセル化するとき、OO的な思考が入ってるはず。クラス的な手法じゃなく、ならともかく。
どちらもOOの実現方法にすぎんでしょ。

549 ：デフォルトの名無しさん：2011/12/04(日) 15:03:56.54

>>482
PostがResul返すかどうかはFactoryかどうかに本質的に関係ないだろ
そもそもResult以外返せばコンパイルエラーだ

俺の感覚では>>479はファクトリとは言わん。サブクラス切り替えて生成するインスタンスを変えてるんじゃないっしょ

550 ：デフォルトの名無しさん：2011/12/04(日) 15:04:35.72

>>548
クラスがあるから、C++は、C#の思想が入ってるといってるのと同じ。
視点がおかしい。

551 ：デフォルトの名無しさん：2011/12/04(日) 15:10:00.83

>>550
んーそうかー？
クロージャでカプセル化するんなら、何かを隠蔽して、それを何かで公開してるんだよな？
それをOO的な思考で実装しないことが出来るとでも？っ・・・ってできるかorz

まーでも、普通そーいう雑な設計はしないっしょ。何がしたくてカプセル化なのか謎すぎだから。

552 ：デフォルトの名無しさん：2011/12/04(日) 15:11:48.84

>>534
その二つなら寧ろProxyに感激してほしいなあ

553 ：デフォルトの名無しさん：2011/12/04(日) 15:12:28.43

>>531 >>533
OOPの基礎的な部分は属性と操作を持ったものをオブジェクトとして
それらが相互に操作しあって自分の属性を更新することで
プログラムが動作すること。
その基礎をもとに発展させた方法論のうちで代表的なものが
クラスベースの方法なんで、狭義なそれを暗黙にOOPと呼ぶ人も居る。

554 ：デフォルトの名無しさん：2011/12/04(日) 15:24:32.10

>>468
拡張に対して開きつつ修正に対して閉じてないと失格ですよ

555 ：デフォルトの名無しさん：2011/12/04(日) 15:28:25.33

>>500
例えば、下の実行引数解析コードだと、ArgumentとOptionAlphaとかの親となる、
Optionを書き換える必要は金輪際無い。あたらしい、オプションが必要になったら、
Optionクラスの子クラスを増やすだけ。引数解析の仕組みを増やしたければ、
Argumentの子クラスを増やすだけ。既存のOptionの子を書き換えたり、
Argumentの子を書き換えることはない。書き換えるとしたらバグがあったときくらい。

// クラス定義
OptionAlpha alpha;
OptionBeta beta;
public:
ExampleType( const Argument &arg )
{
       OptionMap options;
       options["a"] = α //GArgumentの場合は-aに対応
       options["alpha"] = α //GArgumentの場合は-alphaに対応
       options["b"] = β //GArgumentの場合は-betaに対応
       arg.Anarize( MapAdapter( options ) );
}

// 呼び出し
GArgument argument( argc, argv );
ExampleType example( argument );

556 ：デフォルトの名無しさん：2011/12/04(日) 15:31:58.08

>>551
肝心なトコが抜けてる。日本語的な意味でおかしいと言ってんの。
OOがクロージャを、クロージャがOOを含んでるんじゃなく、
カプセル化を、OOとクロージャが含んでんの。だから視点がおかしいといってる。

557 ：555：2011/12/04(日) 15:33:55.87

あ。alphaがαになっとる。

558 ：デフォルトの名無しさん：2011/12/04(日) 15:36:27.06

紛らわしいこと書いたな。

>ArgumentとOptionAlphaとかの親となる、Optionを書き換える必要は金輪際無い。
訂正： OptionAlphaとかの親となるOptionと、Argumentを書き換える必要は金輪際無い。

559 ：デフォルトの名無しさん：2011/12/04(日) 15:37:25.58

>>553
＞自分の属性を更新

ここの出典をプリーズ

560 ：デフォルトの名無しさん：2011/12/04(日) 15:39:49.19

>>556
興味深いので拘ってみたいんだけど

＞カプセル化を、OOとクロージャが含んでんの。

は同意だけど(個人的には含んでるってよりインプリしてるの方がしっくりくるけど)
単独の関係を検証してるならそれでいいけど、先の話はそれとは別でしょ。
先の話題は、クロージャでカプセル化を実現、した時の話だから、
それをOO視点無しでする設計って現実にあるの？ってこと。

561 ：デフォルトの名無しさん：2011/12/04(日) 15:42:35.00

Adapterパターンって元々のクラス設計者の設計間違いを利用者が尻拭いしてるだけみたいに見えるんだけど
これがはじめから有効な場合ってどういう場面なんだろう

もしくはDuckTypeで動く言語ならかなりの場合不要なような気がする

562 ：デフォルトの名無しさん：2011/12/04(日) 15:44:31.52

>>560
逆に、クロージャ的視点なしでオブジェクト設計する事があるの？と言える。
そもそも、クロージャは3番目にできた言語であるLispで実装されたもの。
どちらかと言えば、クロージャの設計思想をOOがうけてるって言ったほうが正しい。
smalltalkのブロックだって、無名関数がベースだしな。

563 ：デフォルトの名無しさん：2011/12/04(日) 15:45:55.99

>>561
イベントドリブン。
転送機構の代用品になる。

564 ：デフォルトの名無しさん：2011/12/04(日) 15:46:31.68

>>561
尻拭いの感覚でだあたいあってる。
新インタフェースをAdapteeに旧インタフェースAdapterに使うのがデフォだから。
設計間違いと言えるかはケースバイケース。仕様変更だつ

565 ：デフォルトの名無しさん：2011/12/04(日) 15:49:07.26

仕様変更だったり、要件定義漏れだったりもするし
最初から使うのは、既存ライブラリをこちらの自持ちAPI都合で都合よく再利用する場合とか

566 ：デフォルトの名無しさん：2011/12/04(日) 15:51:11.15

>>561
ダックタイプじゃ代用にはならんよ。
異なるオブジェクトから同じイベントで1つの名前のメソッドを呼ばれたら、
どのみち、イベント元を区別できないし。

567 ：デフォルトの名無しさん：2011/12/04(日) 15:53:59.14

>>562
あると思うけど、どうかな？
クロージャ言ったらレキシカルスコーブっしょ。プロトタイプベースのOOでない、クラスベースのOOにその視点は登場しないと思われる。
そもOOなJavaにはクロージャないし。

568 ：デフォルトの名無しさん：2011/12/04(日) 15:54:38.78

>>564
キーを2つ取るマップとキーを1つ取るマップの橋渡しとか、
独立性と柔軟性を上げてる訳で、別に尻拭いがメインじゃないだろ。

569 ：デフォルトの名無しさん：2011/12/04(日) 15:54:59.70

>>559
ごめん。勢い余った。
そこは取り下げるからスルーお願いします。

570 ：デフォルトの名無しさん：2011/12/04(日) 15:56:59.84

>>567
まず、smalltalkなんかは、メソッド自体が一つのクロージャ。
それから、OOで言えば、オブジェクト自体がある種のクロージャであり、
オブジェクトのメソッドが、コンストラクターと、実行メソッドだけであれば、
無名関数と同様の動作になる。

571 ：デフォルトの名無しさん：2011/12/04(日) 16:00:47.94

>>566
完全な代用にはならないけどかなり多くの場合ダックタイプで救えない？

あるいは言い換えると、ダックタイピングのような機能を持っていない言語は
仕様変更や要件定義漏れに弱いために、デザインパターンという
いわゆる逃げを使わなきゃいけない、といえるのかも

572 ：デフォルトの名無しさん：2011/12/04(日) 16:02:55.05

>>570
んー
クロージャの定義をどのあたりにしてるか教えて貰えるかい？
ちょっと広義にしすぎてて、実はそのクロージャと呼んでるのクロージャでない別の何かだったりしないかな？

個人的には、クロージャではコンテキストって概念が鍵になると思ってるから、OOなオブジェクトってだけでは、背後にクロージャという概念が隠れてるとは感じられないんだけど

573 ：デフォルトの名無しさん：2011/12/04(日) 16:06:02.72

無名関数は語弊があった、高階関数ね。

>>572
多数の言語でクロージャと言われてるものの最大公約数。
基本的には、Lispのラムダ、Smalltalkのブロック、BCBで使えた__closure。

574 ：デフォルトの名無しさん：2011/12/04(日) 16:09:13.35

>>570
smalltalk は知らないけれど、クロージャはそこでのコンテキストに束縛されるところがキモでは。
まあ、OO でもオブジェクトが使う全てを環境としてコンストラクタに渡す、
というような仕掛けで模倣することはもちろん可能だと思うが。

とはいえ、それを明示的にやったら最早クロージャとは言わないと思われ。
# lambda lifting を手でやってるだけ

575 ：デフォルトの名無しさん：2011/12/04(日) 16:11:19.45

Smalltalkのブロック式はSchemeのクロージャと同様
レキシカルな文脈で環境を補足するよ

576 ：デフォルトの名無しさん：2011/12/04(日) 16:13:30.92

>>575
ブロック式がオブジェクトなの？

577 ：デフォルトの名無しさん：2011/12/04(日) 16:17:07.42

>>566
異なるオブジェクトからあるオブジェクトの同じメソッドを呼び出して、
そのメソッド内で呼び出し元を区別したいっていうの？
それ、ObserverパターンかVisitorパターンと混乱してない？

578 ：デフォルトの名無しさん：2011/12/04(日) 16:17:11.94

>>563 >>566
がわからんのだが、Adapterとイベントドリブンって何か関係あったっけ？

579 ：デフォルトの名無しさん：2011/12/04(日) 16:20:19.54

>>568
良い指摘㌧

580 ：デフォルトの名無しさん：2011/12/04(日) 16:20:21.52

>>576
BlockContextクラスのインスタンス

581 ：デフォルトの名無しさん：2011/12/04(日) 16:24:40.88

>>580
他のクラスはインスタンス化のタイミングで環境を補足しないの？
BlockContextクラスだけ特別扱いになっている？
しっくりこない。

582 ：デフォルトの名無しさん：2011/12/04(日) 16:31:04.75

環境捕捉はインスタンス化のタイミングってより関数定義のタイミングなんじゃないかな？
まー、Smalltalkerでない俺は話題についてけてないんだけど

583 ：デフォルトの名無しさん：2011/12/04(日) 16:32:11.30

デザパタ・オブジェ厨はすぐに孤立するな。優秀なんだが。

584 ：デフォルトの名無しさん：2011/12/04(日) 16:34:50.29

よくわからんけど、スタックフレームへのポインタをフィールドに持っている、
みたいな感じ？うーむ・・・
これはオブジェクト指向とは関係なく、Smalltalk でクロージャを実現するための言語機能とみるべきじゃないの？

585 ：デフォルトの名無しさん：2011/12/04(日) 16:35:58.87

かなり話が広がってきたけど >>501のメリットというのは、オブジェクト指向のメリットではなくポリモーフィズムのメリットということであってる？

それでオブジェクト指向とは何？
という話は >>553
でそのメリットはなんなんだろう？

586 ：デフォルトの名無しさん：2011/12/04(日) 16:36:46.13

>>571
Adapterパターンって元のメソッドのシグニチャを変えたいって話だと思うから、
ダックタイプがそもそも結びつかない気がするんだけど

587 ：デフォルトの名無しさん：2011/12/04(日) 16:41:59.71

>>585
>>501は実装と使用という全く別概念を同義に使ってしまうあたり
言葉の使い分けが微妙なので
引用して議論すると混乱の種になるぞ

588 ：デフォルトの名無しさん：2011/12/04(日) 16:42:02.27

>>585
オブジェクト指向とは、
クラスや継承やポリモーフィズムを総称した呼び方。

ポリモーフィズムのメリット＝オブジェクト指向のメリット

589 ：デフォルトの名無しさん：2011/12/04(日) 16:45:50.80

オブジェクト指向のメリット
＝カプセル化のメリット
＋インヘリタンスのメリット
＋ポリモーフィズムのメリット
＋ダイナミックバインディングのメリット

一つ一つは他のパラダイムでも実現できるけど
これらをバランスよく実現して普及したパラダイムがオブジェクト指向だった。

では駄目なの？

590 ：デフォルトの名無しさん：2011/12/04(日) 16:49:17.98

レイトバインディングやポリモフィックな言語機構ってOOなら必ず持つんだっけ？

591 ：デフォルトの名無しさん：2011/12/04(日) 16:53:51.43

言語設計者がこれはOOPLだって言ったらOOPL

592 ：デフォルトの名無しさん：2011/12/04(日) 16:54:45.33

オブジェクト指向のこんな理解の仕方があったり

http://kmaebashi.com/programmer/object/intro.html

593 ：デフォルトの名無しさん：2011/12/04(日) 16:58:08.49

int a = 1;
int b = 2;

マルチプルインスタンス！

594 ：デフォルトの名無しさん：2011/12/04(日) 17:06:47.18

>>591
つまり規範的な概念ではなく記述的な概念ってことか
ファウラー風に言えば

595 ：デフォルトの名無しさん：2011/12/04(日) 17:23:11.21

>>586
ダックタイピングが利用できると、そのシグネチャを変えなくても
あとから利用側が同じシグネチャに合わせることができる場面が多いっていう
意味じゃない？

596 ：デフォルトの名無しさん：2011/12/04(日) 17:27:51.25

Adapteeのシグニチャが既に固定なんだから、ダックタイプじゃ切り抜けられないっしょ。
ガーと鳴かない状況でガーいわせるんだから。そこでガー言わせるIFミスマッチ埋めがAdapterなんだから。

597 ：デフォルトの名無しさん：2011/12/04(日) 17:36:57.77

>>588
総称はないな。そもそもクラスベースじゃないOOもあるし。

598 ：デフォルトの名無しさん：2011/12/04(日) 17:41:55.48

その程度の反論には、
クラスベースまたはプロトタイプベースって
言い換えるだけだよ。

599 ：デフォルトの名無しさん：2011/12/04(日) 17:42:26.07

「OOっぽいもの」と「よりOOっぽいもの」があるだけで定義付けは不毛

600 ：デフォルトの名無しさん：2011/12/04(日) 17:44:35.24

総称と呼ぶのが不適切だ、という点が肝要なんだが

601 ：デフォルトの名無しさん：2011/12/04(日) 17:49:31.36

AdapterはJavaでいうとclassファイルがjarで提供されているけど、srcファイルは提供されていない
その機能を現在作成中のプログラムの中で、使いたいんだけどインターフェースがあっていない
だからAdapaterを作成してインターフェースを合わせましょう
っていう話だよね

以下委譲を利用したAdapter

提供されているクラス変更不可
class Adaptee{
int test(int a, double b){
return a + b;
}
}

自分が作成しているクラス　インターフェースは変更不可

Interface Test{
void test(double b, int a);
}

class Adapter implements Test{
private Adaptee adaptee = new Adaptee();
void test(double b, int a){
adaptee.test(a,b);
}
}

602 ：デフォルトの名無しさん：2011/12/04(日) 19:26:20.03

自分が作成しているクラスのインターフェースが変更不可って場合はダックタイプでも救えないってわけね。

603 ：デフォルトの名無しさん：2011/12/04(日) 19:30:53.02

継承がなくて委譲だけをひたすら使う場合でもオブジェクト指向って言うんじゃねえ？
とすると

オブジェクト指向 = (クラス | プロトタイプ) and (継承 | 委譲) ans 多態性の総称

すっげぇ定義しづらい・・・

604 ：デフォルトの名無しさん：2011/12/04(日) 19:39:35.17

>>408
シッタカはやめとけｗ
例えばsingletonなんて、Smalltalkで使われていた頃はsingletonとは呼ばれていなかったぞｗ

605 ：デフォルトの名無しさん：2011/12/04(日) 19:40:35.31

なんてよばれてたの？

606 ：デフォルトの名無しさん：2011/12/04(日) 19:49:38.03

sole instance

607 ：デフォルトの名無しさん：2011/12/04(日) 20:09:33.66

sole insntanceはあるクラスのインスタンスが
一つしか存在しないということを指す言葉。
たとえばTrueクラスのインスタンスはtrueのみ。

Singletonはあるクラスのインスタンスを
一つに制限するときに使うパターン（コード・設計）。

あるクラスをsole insntanceにするときに使うのが
Singletonパターン。こういう使い方をする。

Singletonとsole insntanceは別物

608 ：デフォルトの名無しさん：2011/12/04(日) 21:16:28.61

>>601
> っていう話だよね
違う
ソースが提供されているかどうかは全く関係ない

609 ：デフォルトの名無しさん：2011/12/04(日) 21:27:36.46

>>608
ソースが提供されていたら、自分のインターフェースに合わせて変更してしまえばいいんじゃないか
と思っちゃうんだけど違うのかな

提供されているクラスは充分にテストされているから、変更せずにそのまま利用したい
ということ？

610 ：デフォルトの名無しさん：2011/12/04(日) 21:29:12.84

動的型付け言語使いなんだろ？
インターフェースが変わるとコードもテストも
大量に修正が必要になる。
だから変えようと思っても変えられない。

リファクタリング機能が充実している
Javaでは信じられない発想。

611 ：デフォルトの名無しさん：2011/12/04(日) 22:15:38.03

例えばGUIアプリケーションのプレゼンテーションモデルとドメインモデルとの関係を
考えると分かりやすいと思う。
ドメインモデルを直接変更してしまうと、表示画面に特化した再利用性の低い
ものになってしまうので、アダプターパターンを適用する。

プレゼンテーションモデルというのはJavaのJComboBoxにおけるComboBoxModel
などのことで、アダプターパターンを用いることで、どんな形のクラスであってもソースの
修正なしにコンボボックスという形で表示することができる。

612 ：デフォルトの名無しさん：2011/12/04(日) 22:16:40.16

>>611は>>609宛です

613 ：デフォルトの名無しさん：2011/12/04(日) 22:40:21.43

>>610
Java使ってるのにソースの互換性を考えたことないのね

614 ：デフォルトの名無しさん：2011/12/04(日) 22:46:48.06

>>577
javascriptで書くけど、Observer、Visitorってのは、ここまでの範囲じゃん。
button.addEventListener("click", function( event ){ alert( "I'm visitor." ); }, false);

Adapterでイベントを区別するってのは、こういうこと。
function StartAdapter( delegateTarget ) { function( event ){ delegateTarget.start() } }
function StopAdapter( delegateTarget ) { function( event ){ delegateTarget.stop() } }

var mainLogic = new MainLogic();
buttonA.addEventListener("click", StartAdapter( mainLogic ), false);
buttonB.addEventListener("click", StopAdapter( mainLogic ), false);

615 ：デフォルトの名無しさん：2011/12/04(日) 22:48:05.84

間違った、こうね。
function StartAdapter( delegateTarget ) { return function( event ){ delegateTarget.start() } }
function StopAdapter( delegateTarget ) { return function( event ){ delegateTarget.stop() } }

616 ：デフォルトの名無しさん：2011/12/04(日) 23:17:54.07

>>589
仕組みで言っても仕方ないって。
OOPLってのは、OOの目的を達成を支援する事を標榜してるだけで、
目的のためなら、手段は色々なんだから。実装継承の無いOOPLもあるし、
javascriptみたいにカプセル化を持たない言語もある。多態性に関しては、
コアなんで、流石にサポートしない言語は無いけど。

OOは、そもそもSimulaのシミュレーションから着想を得て発展させたもの。

水分子や、酸素分子はそれぞれ別の振る舞いをする。
酸素の溶けた水中は、グラフ構造で表現するのが自然だが、
グラフのノードたる、水分子、酸素分子は別々の振る舞いをしてしまう。
これを上手く、自然に再現するには、既存の手法や言語ではどうしても不細工だった。
それをキレイに表現しようと発展したのがSimula。
更にこのノードをオブジェクトとして定義し、分子などをコンピュータ上のリソースに応用しようと
考えたのが、SmalltalkとC++であり、その考えがオブジェクト指向となっている。

なので、OO概念 = 異なるリソースのグラフ構造表現だ。
ノード単位での並列化を加えたものがアクターモデルと呼ばれていることからも、
概念は、はっきりしている。

OOPLとは、あくまでこの「異なるリソースのグラフ構造表現」をどれだけ楽に実装できるかを
目指した言語であるだけで、別にどの機能を持っているからOOPLという話ではない。

617 ：デフォルトの名無しさん：2011/12/04(日) 23:20:54.93

>>616
読むのだるいんで、下らない喩え話を省いて。

618 ：デフォルトの名無しさん：2011/12/04(日) 23:36:58.80

>>614
ええと、かなりわからん・・・ごめん。
それはAdapteeは
mainLogic.start()、mainLogic.stop()でいいの？
で、
buttonA.addEventListener("click", mainLogic.start, false);
で済ますことができないシチュエーションがあるってことでいい？

そして
「異なるオブジェクトから同じイベントで1つの名前のメソッドを呼ばれたら、」
っていう文言を翻訳すると、

異なるオブジェクト : buttonA および buttonB
同じイベント : addEventListener("click")
1つの名前のメソッド : *Adapter(mainLogic) ???

ってことかな？最後のは別に1つの名前のメソッドじゃないから、違ってる気がする。

619 ：デフォルトの名無しさん：2011/12/04(日) 23:47:09.77

>>614は俺も分からんな

620 ：デフォルトの名無しさん：2011/12/04(日) 23:47:18.66

>>617
OOPLとは、あくまでこの「異なるリソースのグラフ構造表現」をどれだけ楽に実装できるかを
目指した言語であるだけで、別にどの機能を持っているからOOPLという話ではない。

621 ：デフォルトの名無しさん：2011/12/04(日) 23:48:50.87

>>618
>buttonA.addEventListener("click", mainLogic.start, false);
これができる言語なんて無いでしょ。デリゲートなり無名関数をアダプターとして挟まない限り無理。

622 ：デフォルトの名無しさん：2011/12/05(月) 00:06:02.44

>>618

function method( event ) { alert( "多分、buttonAかbuttonBのどっちかから呼ばれたと思う" ) }
buttonA.addEventListener("click", method, false);
buttonB.addEventListener("click", method, false);

クラスを省いてるんで、また誤解があるかもしれないが、
一つのメソッドが呼ばれると、何処からよばれたか解からんというのは、こういう状態。

勿論、methodが、buttanAと、buttonBを参照してれば、eventオブジェクトで区別は付けられる。
その代わり、buttonAとbuttonBからmethodを切り離せなくなるんで、現実的じゃない。

623 ：デフォルトの名無しさん：2011/12/05(月) 00:21:57.04

>>620
2ch の長文はオレオレ理論なのか根拠のある話なのか判別が付きにくいから
原典へのリンクも張って。

624 ：デフォルトの名無しさん：2011/12/05(月) 01:41:33.35

Simula and Smalltalk: A Social and Political History
http://www.cebollita.org/dugan/history.html

アランケイへのオブジェクト指向とはなんぞやというインタビュー
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

「異なるリソース(複数のコンピューターとか)のグラフ構造表現」とまではっきり書いてないが、
要約すると、そういう事を書いてある。基礎概念が、コンピューターネットワークが
細胞間のメッセージングと同じように考えられるとか、ニューロンネットワークとか、
通信網のシミュレーションは、アルゴルのような従来の言語ではやりづらかったとかね。

625 ：デフォルトの名無しさん：2011/12/05(月) 01:57:24.77

>>615
StartAdapterとその中身の無名関数とで冗長
あと大文字で始めるのやめれ、見づらい

626 ：デフォルトの名無しさん：2011/12/05(月) 02:18:25.48

>>625
別に冗長ではないだろ
これは、あくまで例だが実際には、
mainLogic以外のオブジェクトも渡す理由だから
無名関数だったら毎回function(event){・・・.start()}って
かかないといけないじゃん

627 ：デフォルトの名無しさん：2011/12/05(月) 02:39:22.01

buttonA.addEventListener("click", function(){ mainLogic.start() });

でいーじゃん

628 ：デフォルトの名無しさん：2011/12/05(月) 02:44:49.51

コミュ症かー

629 ：デフォルトの名無しさん：2011/12/05(月) 02:49:05.79

レキシカルスコープなのに、わざわざ関数作って冗長にする意味ないっしょ
分かりやすさがダンチ

630 ：デフォルトの名無しさん：2011/12/05(月) 02:57:21.85

>>626
startじゃなくinitの方が適切な名前だったなーとか、併せて初期サイズを引数で渡した方がいいねーとかなったら

function InitAdapter( delegateTarget, initialSize ) { return function( event ){ delegateTarget.init(initialSize) } }
に変えて
buttonA.addEventListener("click", InitAdapter( mainLogic, initialSize ), false);
にするの？

buttonA.addEventListener("click", function(){ mainLogic.init(initialSize) });

ってだけで済むところを。どんなメリット求めてパターン使ってるの？っていう

631 ：デフォルトの名無しさん：2011/12/05(月) 03:02:53.59

>>614は中途半端に知識を持ったために、かえって悪くなる典型みたいなコード
>>72の通りだな

632 ：デフォルトの名無しさん：2011/12/05(月) 03:06:18.84

イベントハンドラが実はアダプタ使ってるって指摘は面白かったと思う

633 ：デフォルトの名無しさん：2011/12/05(月) 03:18:52.18

>>614はJavaScriptじゃなくJavaで書けば良かったのに

634 ：デフォルトの名無しさん：2011/12/05(月) 03:24:26.32

>>616
数学は天文学だとか言うのと同じ程度に眉唾なんだが
発展経緯を知ることは意味があるけど、それがイコール定義ではないでしょ

635 ：デフォルトの名無しさん：2011/12/05(月) 03:38:19.77

>>630
startが変化しなけりゃ引数増やす必要ないだろ。
そもそもstartがイベントを受け取る事を前提にしてるなら、
引数が増えたりすることがおかしい。あくまでイベントを別のメソッドで
受け取るためにアダプター噛ましてるだけなんだから。

それはともかくとして、関数に名前付けてんのは、
無名関数を作れない環境でも同じだという事を強調した。
無名関数単品でも他のオブジェクトのメソッド呼ぶだけならアダプターではある。

それはともかく、ダックタイピングが使える環境だろうと、無名関数を作れない
環境だろうと、アダプターをイベントで使うというのがわかればいい。
Javascriptでどれだけキレイに書けるか、Javascriptのセオリーに
従うならどうかなんては問題にしてない。

636 ：デフォルトの名無しさん：2011/12/05(月) 04:02:54.16

>>635
引数が増えたりするのは少しもおかしくない
Textで設定値を指定するとか、普通にある

そもそもTargetインターフェースが固定なんだから、Adapteeは可変が前提でしょ。そこ否定してどーすんのさ

おまけ。
問題にしてないと言うなら、主題に沿わないコード断片を書き散らすのやめれ
フォーカスがブレたのなら、それは焦点を絞らなかった書き手の問題だよ。

637 ：デフォルトの名無しさん：2011/12/05(月) 06:12:22.51

>>607
違うよ。
つーか、クラスをsole instanceにするとか、用法がメチャクチャだぞｗ

１つのクラスのインスタンスが１つしかない状況を仮定して、
そのインスタンスを指す言葉がsole instanceで、
そのクラスを指す言葉がsingletonだ。

Smalltalkではinstanceに注目してsole instanceと呼んでいたが、
GoFではよりクラス寄りになったJava等にあわせてsingletonと呼ぶことにした。

638 ：デフォルトの名無しさん：2011/12/05(月) 06:16:12.50

>>614がよくわからないんだけど、誰かJavaで頼む
StartAdapterって何するメソッドなの？

639 ：デフォルトの名無しさん：2011/12/05(月) 06:22:41.87

>>616
構造が目的なのではなくて、相互作用が目的じゃないのか？
グラフ構造というよりも、異なる単位間の相互作用、のほうがしっくりくる。

で、流派的には
ケイが動的で柔軟な相互作用を追求し、
ストラウストラップは効率的な相互作用を指向して、
メイヤーは各単位の拡張性/整合性に注目した。

640 ：デフォルトの名無しさん：2011/12/05(月) 07:07:44.20

>>634
>>624以上のソースを出せと言われたら
もう、ISO/IEC 2382-15しか無いんだがな。
知りたいなら高い金だして買ってくれ。

641 ：デフォルトの名無しさん：2011/12/05(月) 07:17:19.29

>>636
無いな
C#使ってて、イベントを受け取るために使った場合の
Delegateは、イベントが発行する以上の引数を持たせる事はできないし
テストのために、追加の引数を渡せるように
Delegateオブジェクトを拡張したなんて聞いたことがない

642 ：デフォルトの名無しさん：2011/12/05(月) 07:30:45.00

>>638
Swingが解るなら、StartAdapterってのは、他のインターフェースのメソッドを
一つ呼ぶだけのListenerオブジェクトだよ。

JButton button1 = new JButton()
JButton button2 = new JButton()

StopWatch mainLogic = new StopWatch();
button1.addMouseListener(new StartAdapter(mainLogic));
button2.addMouseListener(new StopAdapter(mainLogic));

Javaで書くとこんな感じか。

643 ：デフォルトの名無しさん：2011/12/05(月) 07:43:33.94

>>634
じゃあ訊くけどさ、数学の定義を示してくれたまえ。
その上で、その定義とやらが義務教育を受けた一般人にとって
どれだけ眉唾なものか議論しようじゃないか。

644 ：デフォルトの名無しさん：2011/12/05(月) 07:51:47.10

関数がファーストクラスのオブジェクトじゃない、
ラムダすら無いうんこな言語で使うパターンですね

645 ：デフォルトの名無しさん：2011/12/05(月) 08:01:44.78

Javaでデザパタ学んだ奴って他言語でも
冗長なコード書くよな
まさにデザパタの弊害って感じ

646 ：デフォルトの名無しさん：2011/12/05(月) 08:15:32.26

ボタンを押された時に実行する処理が、特定のロジックを起動するだけという場合でも、
イベントリスナとして登録するためには、イベントを受け取る関数の形に合わせる必要がある。

これは、ロジック側のインタフェースをイベントリスナとして要求されるインタフェースに
変換しているという見方もできて、その見方をするならば、
そこで作成されるイベントリスナオブジェクトはアダプタパターンを使っているとも言える。

という理解でいいのかな？
確かにそういう考え方をしたことはなかった。>>632 同意。

647 ：デフォルトの名無しさん：2011/12/05(月) 08:22:39.04

>>642
ありがとうよくわかった
ListenerはAdapterパターンが使われているよという主張なのか

648 ：デフォルトの名無しさん：2011/12/05(月) 08:36:01.22

そんな当たり前なことで大絶賛とはｗ

649 ：デフォルトの名無しさん：2011/12/05(月) 09:15:31.67

ついでに質問なんだけど、Listenerってどの単位でクラス分割すればいいの？

ボタンごとに完全にクラス分けるのか、ある程度は画面ごとにListenerをまとめて押されたボタンを取得してif文で処理分けるのか

理想を言えば前者がいいんだろうけど、クラスすごく増えるんだよね

650 ：デフォルトの名無しさん：2011/12/05(月) 09:24:05.72

>>641
Adaterが話題になってるのに、またズレたレスをしたもんだな

651 ：デフォルトの名無しさん：2011/12/05(月) 09:24:19.17

>>648
誰も大絶賛してないと思うけど
そもそもそれがAdapterと納得している人はいない気がする

652 ：デフォルトの名無しさん：2011/12/05(月) 09:26:43.89

>>645
おまえやおまえの周りがそうだからといって
勝手に一般化するなよ
世界はお前が認識してるより広いんだ

653 ：デフォルトの名無しさん：2011/12/05(月) 09:30:03.43

>>643
脱線は一人でやってくれたまへ
コンピュータサイエンスの目的は軍事だという話題もあるぞ

654 ：デフォルトの名無しさん：2011/12/05(月) 10:42:44.42

逃げたｗ

655 ：デフォルトの名無しさん：2011/12/05(月) 13:08:57.91

>>635
こういうのもAdapterパターンと呼ぶってこと？
まあ別に良いけど

map(lambda x: x + 1, range(1,10))

656 ：デフォルトの名無しさん：2011/12/05(月) 19:18:51.32

おまえ、「おまえ頭おかしいな」とよく言われないか？

657 ：デフォルトの名無しさん：2011/12/05(月) 19:39:14.35

>>655
lambdaにより、処理を差し替えれる事から、Strategyになるんじゃない？

もしくは、double-dispatchなしの簡易版Visitor (イディオムとして名前がついていたような記憶があるが思い出せない)

658 ：デフォルトの名無しさん：2011/12/05(月) 19:43:05.44

ドカタSEじゃその程度かｗ

659 ：デフォルトの名無しさん：2011/12/05(月) 19:46:24.81

芝生やした単文野郎はなんなんだ

660 ：デフォルトの名無しさん：2011/12/05(月) 20:06:23.40

>>647
解ってるかもしれないけど、
Listener = Adapterじゃないからね。
Listenerの中で、複数のオブジェクトや
制御構文を並べて複雑な処理をしてたら、
もはやAdapter(適応)パターンじゃない。

あくまでも、イベントを他のオブジェクトに渡すだけの
最低限の実装で有るべき。Adapterの中で、文字列から
数値型に変えて引き渡したり、ファイル型に変えて
引き渡すぐらいはいいけどね。

661 ：デフォルトの名無しさん：2011/12/05(月) 20:13:46.38

やっぱり無名関数を使わず、Targetインターフェースに名前が付いてる場合だけを
Adapterと呼ぶんじゃないか？

662 ：デフォルトの名無しさん：2011/12/05(月) 20:22:27.57

コード書けないドカタSEが言葉を弄んでいるだけ

663 ：デフォルトの名無しさん：2011/12/05(月) 20:25:20.75

>>657
lambdaの中で+（__add__メソッド）を呼ぶだけだから、>>635の定義
> 無名関数単品でも他のオブジェクトのメソッド呼ぶだけならアダプターではある。
ならアダプタパターンってことになるな

まあ、>>662の言う通りだと思うわ。言葉遊びっつーか馬鹿みたい

664 ：デフォルトの名無しさん：2011/12/05(月) 20:39:49.98

今はAdapterパターンばかり槍玉に上がってるけど、
StrategyやらCommandやらVisitorやら、他にもインターフェースを駆使して動的な性質を取り入れようとしているパターンには
動的型付けとかクロージャとかミックスインで代替できるものがいっぱいあると思うよ
モダンな言語はデザパタに頼らずに、よりスマートでソースコードの見通しがいい方法で解決すべき。

665 ：デフォルトの名無しさん：2011/12/05(月) 20:46:38.00

さて>>561に戻るか。
Adapterパターンは、結局ダックタイピングできる言語だろうと、
高階関数つかえる言語だろうと、無意識かもしれんが、使う人は使ってる。
尻拭い以外に使ってることも多いんだよ。

666 ：デフォルトの名無しさん：2011/12/05(月) 21:11:06.69

>>664
転送と高階関数で、見かけは存在しないように見せかけられる。
本質的にゃ変わりゃしない。

667 ：デフォルトの名無しさん：2011/12/05(月) 21:13:08.65

高級言語はその見かけが大事なんじゃねーか

668 ：デフォルトの名無しさん：2011/12/05(月) 21:16:09.15

Adapter=Listenerは間違い
委譲を利用するAdapterだと違和感が少ないけど、継承を利用するAdapterだと気持ち悪さがよくわかる

提供されているクラス変更不可
class AdapteeModel{
　int test(int a, double b){
　　return a + b;
　}
}

インターフェース変更不可

Interface Test{
　void test(double b, int a);
}

自分が作成しているクラス　変更可能
class AdapterListener extends AdapteeModel implements Test{
　void ActionListener(double b, int a){
　　this.test(a,b);
　}
}

ListenerがModelを継承するっていうのは明らかにおかしい
いわゆるis a 関係にかすってもいない
AdapteeとAdapterは同じ目的のクラスであるべきだけど、ListenerとModelはまったく目的が違う

言葉遊びとかそういうレベルじゃない
今回の勘違いは、委譲とAdapterを同一視してる発言

669 ：デフォルトの名無しさん：2011/12/05(月) 21:26:17.89

>>668
なんでAdapterなのに継承してんの？
Adapterが別のクラスにくっついてちゃいかんだろ。
>>660にも書いたが、あくまでAdapterは、
別のオブジェクトのメソッドに受け渡すだけ。

Listener = Adapterでは無いが、Listenerに
Adapterを使うこと自体は問題ない。

670 ：デフォルトの名無しさん：2011/12/05(月) 21:30:05.97

>>668
Listenerは、別にAdapterじゃなくてもいい
ただListenerとしてAdapterが使えるってだけの話だろ

671 ：デフォルトの名無しさん：2011/12/05(月) 21:32:49.04

>>668
なんでモデルでもないのにAdapteeModel?

672 ：デフォルトの名無しさん：2011/12/05(月) 21:37:20.54

>>669
Adapter パターン - Wikipedia
http://ja.wikipedia.org/wiki/Adapter_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

>>670
どういうことかよくわからないから
ListenerとしてAdapterが使えるって具体的にコードで書いてみてよ

>>671
古典的なMVCでは、Listenerから呼び出すメソッドはModelのメソッド
AdapteeModelクラスの中身はなんでもいい

673 ：デフォルトの名無しさん：2011/12/05(月) 21:40:11.63

>>672
ほれ
http://en.wikipedia.org/wiki/Adapter_pattern

674 ：デフォルトの名無しさん：2011/12/05(月) 21:41:45.98

>>672
モデルつってんのに、メンバーもなけりゃ
ブロードキャスト機構が付いてないから、
アレなのかなとおもってさ

675 ：デフォルトの名無しさん：2011/12/05(月) 21:45:45.04

>>672
日本語版じゃさも、委譲型が特別形態の様に書かれてるけど、
GoF本や、海外の資料だと、委譲してるのがデフォ。
継承型の方が特殊なんだけど。

676 ：デフォルトの名無しさん：2011/12/05(月) 21:50:22.93

日本語版Wikipediaなんて技術関連はいい加減だからなぁ
殆どアニオタの巣窟なんだっけ

677 ：デフォルトの名無しさん：2011/12/05(月) 21:51:38.59

いい加減と思った人が書きなおさないから悪いのでは？
自分の責任だと思いなよ。

678 ：デフォルトの名無しさん：2011/12/05(月) 21:52:37.27

>>672
http://www.oodesign.com/
こういうちゃんとしたサイトで勉強したら？

679 ：デフォルトの名無しさん：2011/12/05(月) 21:54:37.96

>>677
なんで情弱御用達Wikipediaの面倒なんか見なきゃならんのよ。

680 ：デフォルトの名無しさん：2011/12/05(月) 21:57:10.17

>>674
そこはスルーして貰えると思って省略した
Modelらしくするなら以下を追加けどやっぱり今回の話とは関係ないので省略
List<Observers> observers = new ArrayList<Observers>();
private int a = 0;
public void addObserver(Observer ob){
observers.add(ob);
}
public void changeA(int aa){
a = aa;
this.notifyObservers();
}
public int getState(){
return state;
}
private void notifyObservers(){
　for(Observer ob:observers){
　　ob.update(this);
　}
}

681 ：デフォルトの名無しさん：2011/12/05(月) 21:58:14.68

ム板で日本語版Wikipediaからしかソース持ってこれないってのもなあ

682 ：デフォルトの名無しさん：2011/12/05(月) 22:01:48.87

>>675
自分もAdapterでどちらを使うかと言われれば委譲の方を使うよ

ただし同じAdapterパターンなんだから委譲も継承も目的は同じはず

en　wiki
＞translates one interface for a class into a compatible interface
>>678のサイト
>Convert the interface of a class into another interface clients expect.
>Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

と書いてあるとおりインターフェースを合わせるためのもの
プログラムとか考えずアダプターと言ったらまさしくインターフェースを合わせるためのもの
Listenerでmodelを呼び出すのは、インターフェースを合わせるためではないよね

>>681
ソースなんてGoF読んでくれとしか言えないｗ

683 ：デフォルトの名無しさん：2011/12/05(月) 22:01:58.84

>>680
Javaで、しかもgetXxxxx使ってんだから
せめてjava.beans.PropertyChangeSupportと
java.beans.PropertyChangeListenerぐらいは使おうよ。

684 ：デフォルトの名無しさん：2011/12/05(月) 22:06:58.62

>>682
ListenerをAdapterで実装したとき、
Model自体をAdapterが使用する必要ないでしょ。

class Model implements Runnable{}
new RunAdapter( (Runnable)new Model() );
例としては変だけど、Adapterとしての用途なら別にこれでいいわけじゃん。

685 ：デフォルトの名無しさん：2011/12/05(月) 22:13:52.92

Example instance = new Example();
Adapter DelegateAdapter = new Adapter(instance.Method);
DelegateAdapter( 10 );

.net環境は楽だなぁ

686 ：デフォルトの名無しさん：2011/12/05(月) 22:22:10.60

>>683
そうですね

>>684
もちろんそれみたいなListener=Clientの状況なら問題ない
Listener=Adapterはおかしいと主張してる

687 ：デフォルトの名無しさん：2011/12/05(月) 22:25:31.47

Listener=Adapterじゃないのは同意してるって。
Listener = { Adapter pattern, Other pattern, ... }
にできるっていう意味で書いてんじゃん。
なんで引きずってんの？

688 ：デフォルトの名無しさん：2011/12/05(月) 22:30:02.26

別にリスナーをコントローラーで実装しようが、アダプターで実装しようがどうでもいいじゃん

689 ：デフォルトの名無しさん：2011/12/05(月) 22:34:03.85

>>667
これにつきるな。ソースコードは設計書であるべきだから本質的でないものが混ざるとストレスたまる。
デザパタはその見通しを悪くするものが多いから、本当に必要なとき以外は極力排除したい。

TemplateMethodみたいに見通しよくするものもあるけど。

690 ：デフォルトの名無しさん：2011/12/05(月) 22:39:08.17

>Listener = { Adapter pattern, Other pattern, ... }
俺はこれを否定してるつもりなんだけど
ListenerのどこにどうAdapterパターンを使うんだ
Observerパターンは使ってるけど

>>688
どうしてコントローラーとアダプターパターンが同列なんだ
どうやってリスナーをアダプターで実装するんだ

もう俺だけ理解してない気がしてきた
誰か教えてくれ

691 ：デフォルトの名無しさん：2011/12/05(月) 22:39:39.69

>>689
TemplateMethodの見通しが良いかは分からないけど、上二行に関しては同意

ていうか頼むから>>614や>>642のようなアホコードは書かないで欲しいもんだね

692 ：デフォルトの名無しさん：2011/12/05(月) 22:39:48.63

デザパタは構造。見た目は別。
C#でもできるし、GObjectを使ったCでもできるし、Lispでもできる。
アルゴリズムが言語に依存しないのとおんなじ。

693 ：デフォルトの名無しさん：2011/12/05(月) 22:40:09.16

デザパタは見通しを悪くするというのは、
単にお前が、設計の基礎知識を知らんだけではないのか？

設計図を読めない人は、設計図をみたらよくわからんと言うだろう。
それと同じだ。

694 ：デフォルトの名無しさん：2011/12/05(月) 22:43:20.02

>>690
リスナーはオブザーバーパターンから見た立場
アダプターは、委譲される側から見た立場
直交できる関係であって排他的なもんじゃないでしょ

695 ：デフォルトの名無しさん：2011/12/05(月) 22:45:21.24

>>693
本当に必要なときに使うのは誰も否定してないんじゃないの？

696 ：デフォルトの名無しさん：2011/12/05(月) 22:45:44.95

>>691
例としてわざとそう書いてるのに空気読めないねぇ。

697 ：デフォルトの名無しさん：2011/12/05(月) 22:46:01.69

printfは書式が複雑で見通しが悪いと言っているようなもんだよな。

なぜそうなっているのかその理由と目的を聞いて、
じゃあお前はこの目的をどうやって達成する？と聞いたら
一番いい方法がデザパタと同じコードにになるだろう。

698 ：デフォルトの名無しさん：2011/12/05(月) 22:46:40.31

>>695
あんたは、見た目とデザパタを同一視してるだろ。
そこが解ってないと言われてんの。

699 ：デフォルトの名無しさん：2011/12/05(月) 22:46:43.34

>>695
だから、本当に必要なときを前提にして
話をしてるんでしょｗ

700 ：デフォルトの名無しさん：2011/12/05(月) 22:47:06.50

>>696
例として不適切なのが相変わらず理解できないのね

701 ：デフォルトの名無しさん：2011/12/05(月) 22:47:48.59

>>700
なぜ例として不適切なのか？

いちいちストーリを作らないといかんのか？

702 ：デフォルトの名無しさん：2011/12/05(月) 22:47:53.41

>>699
必要もないのに使っている悪例がでてるじゃん

703 ：デフォルトの名無しさん：2011/12/05(月) 22:49:08.26

コード見たら、あぁこういう時に必要になるねって
分かるようなコードでも、実勢経験が少ない人には
なんでそんなものが必要になるのかわからないんだよ。

704 ：デフォルトの名無しさん：2011/12/05(月) 22:49:35.43

>>702
だから、これは必要なときという前提の話。

705 ：デフォルトの名無しさん：2011/12/05(月) 22:51:11.05

>>704
自分で何を言ってるのか分かってる？

706 ：デフォルトの名無しさん：2011/12/05(月) 22:51:54.71

>>703
むしろ実務経験の少ない人ほど無駄なパターンを多用する傾向があるかと

707 ：デフォルトの名無しさん：2011/12/05(月) 22:53:04.34

>>703
それはよくある話だね。

サーバーの話だけど俺は昔リバースプロキシがよくわからなかった。
そのまま繋げばいいのに、なんでそんなものを入れて複雑にするのか？と思った。
今では理由はわかるけど、経験少ないとわからんものだよ。

なんかの本に書いてあったけど、密結合な設計は悪い。
結合を疎にするには間にクッションを入れるみたいなこと。

デザパタもそうなってるんだよね。結合度を下げるために
間にクラスを入れてる。

その理由がわからない人は経験が足りないだけ。

708 ：デフォルトの名無しさん：2011/12/05(月) 22:54:09.44

日本語版WikipediaのAdapterパターンのサンプルプログラムを
動的型付け言語で実装すると委譲も継承も必要無いけど、
これも見た目が違うだけでAdapterパターンのはず

class Product:
def __init__(self, cost=0): self.cost = cost
def get_cost(self): return self.cost

Product.get_price = Product.get_cost

709 ：デフォルトの名無しさん：2011/12/05(月) 22:54:57.25

>>707
そうだね
"本当に必要なときは"使った方がいいね

710 ：デフォルトの名無しさん：2011/12/05(月) 22:55:41.76

>>705
よく分かってるけど？

ここに書いている短い例ではいろいろ省略している
めんどうだからね。

本当は○○～というストーリーがあるんだけど、それを省略している。
このストーリーをちゃんと書けばデザインパターンはそういう目的の
ためにあるんだってわかるはず。

ただ、めんどくさいから書かないよ。経験あればこの程度のストーリーなんて
心当たりがあるはず。ない人がわからんと文句を言ってるだけ。

711 ：デフォルトの名無しさん：2011/12/05(月) 22:56:45.40

>>708
デザインパターンの本質は、実装ではなくて考え方なので、
その考え方さえ満たしていれば、いろんな実装がありえます。

712 ：デフォルトの名無しさん：2011/12/05(月) 22:57:55.09

button addEventListener("click", function(){ instance.Method(); } );
button.addMouseListener( new ActionListener(){ void actionPerformed(ActionEvent e){ instance.Method(); } } ):
button.Click += new EventHandler( instance.Method );

言語が違おうが、パターンとしては同じって事が解らない人は辛いね

713 ：デフォルトの名無しさん：2011/12/05(月) 22:59:09.42

>>710
もういいよ
聞く耳を持たない人には無いを言っても無駄だからね

714 ：デフォルトの名無しさん：2011/12/05(月) 22:59:51.04

>>713
それで？

715 ：デフォルトの名無しさん：2011/12/05(月) 23:00:29.45

>>712
いわゆる一昔前の頑固親父だよな

716 ：デフォルトの名無しさん：2011/12/05(月) 23:02:32.96

>>714
もういいよって言ってるのにその返しは無くない？

717 ：デフォルトの名無しさん：2011/12/05(月) 23:03:18.27

言語とアルゴリズムとかの概念を切り離せない人って
どういう仕事してんだろ？接客とかはしたことなさそうだけど

718 ：デフォルトの名無しさん：2011/12/05(月) 23:04:31.98

>>716
そもそも「もういいよ」って返しがありえないだろｗ

ありえないものには、
ありえないもので返すしかありません。

719 ：デフォルトの名無しさん：2011/12/05(月) 23:06:10.53

>>718
お前ってものすごい自分ルールを持ってるね

普通はありえない返しだと思ったらありえないって言うだろｗ

720 ：デフォルトの名無しさん：2011/12/05(月) 23:06:34.62

>>719
それは、お前の自分ルールだ。

721 ：デフォルトの名無しさん：2011/12/05(月) 23:07:09.18

>>720
お互いここらで終わりにしようか？

722 ：デフォルトの名無しさん：2011/12/05(月) 23:08:17.19

>>721
どうぞ勝手に。俺も勝手にする。

723 ：デフォルトの名無しさん：2011/12/05(月) 23:08:41.41

今なんとなく解った気がする。
ヤツがいってるのはアレか、JavascriptじゃわざわざAdapterなんか使わずに、
面倒だから無名関数の中に直接処理を埋め込めといってたのか。多分・・・

724 ：デフォルトの名無しさん：2011/12/05(月) 23:09:47.05

無名関数かどうかは関係ないよ

725 ：デフォルトの名無しさん：2011/12/05(月) 23:10:45.70

function(){ instance.Method() }
じゃなく、
function(){ 処理ベタ書き }

こんな感じか

726 ：デフォルトの名無しさん：2011/12/05(月) 23:10:46.42

関係あるのは、直接処理を埋め込むってところだろｗ

727 ：デフォルトの名無しさん：2011/12/05(月) 23:13:37.29

>>725
確かに、それならAdapterパターンつかってないわな。
デザパタ減らしてる。

728 ：デフォルトの名無しさん：2011/12/05(月) 23:14:56.86

> function(){ instance.Method() }

引数無しなら instance.Method だけで良いんと違うん？

729 ：デフォルトの名無しさん：2011/12/05(月) 23:19:10.80

>>728 javascriptだとMethodの中のfunctionオブジェクトだけ代入する事になるのよ。
instanceとのヒモ付がなくなっちゃう。

730 ：デフォルトの名無しさん：2011/12/05(月) 23:21:56.94

>>728
instanceB.Method = instanceA.Method;
instanceB.Method();

これ動かしたら、instanceBとinstanceAどっちが参照されると思う?

731 ：728：2011/12/05(月) 23:27:09.79

>>729-730
Javascriptってそんな言語だったんだ。知らなかった。

732 ：デフォルトの名無しさん：2011/12/05(月) 23:32:13.69

javascriptでメソッド名大文字で始めるなよ気になるから
上のほうでも誰か指摘してただろ

733 ：デフォルトの名無しさん：2011/12/05(月) 23:34:36.71

デザパタの目的は結構だが、その実装のためだけに
新たにクラスやインターフェースを作るのは気に入らない
ソースコードの見通しが悪くなるから
（つーても、使う言語でそれ以外に実装方法が無いなら仕方ないが）

見た目は大事

734 ：デフォルトの名無しさん：2011/12/05(月) 23:36:40.15

クラス作るのも関数作るのも大差ないだろ。

735 ：デフォルトの名無しさん：2011/12/05(月) 23:36:58.70

みなさんスルーでおねがいします

736 ：デフォルトの名無しさん：2011/12/05(月) 23:39:24.59

>>734
往年の派遣土方は、テスト工数じゃなくて、
ステップ数で見積もらなきゃいけないから、
そういうとこが厳しいんだってさ。

オブジェクトで振る舞いの表現ってのも元請けが
理解できないから、なかなかさせてもらえないみたい。

737 ：デフォルトの名無しさん：2011/12/05(月) 23:46:08.52

一行のlambdaで済むところを
インターフェース + クラスで10行に膨らませて
大規模（笑）開発にしてるとこあるな
行数で評価されるからこれで良いんだってww
まさにドカタの発想w

738 ：デフォルトの名無しさん：2011/12/05(月) 23:47:22.85

デザインパターンに関してはひがやすをさんが次のように書いているが、これを読んでとても納得した
まさにこれ

http://d.hatena.ne.jp/higayasuo/20101126/1290766099
> きれいなソースコードをかけるようになるためにデザインパターンも知ってたほうがいいんじゃないのという人もいると思いますが、
> デザインパターンはきちんと学んだ上で、いったん軽く忘れたほうがいい。
>
> 軽く忘れるというのは、コードを書いているときに、そういえば、このパターンはデザインパターンのあれに似てるなぁと思い出せる
> くらいに忘れるということです。思い出せたらそれは使うようにしましょう。
>
> デザインパターンが常に頭に常駐している状態でコード書くと、無駄に複雑になっちゃうんだよね。
>
> デザインパターンは、ある程度複雑な問題をきれいに解くために考えれたものですが、もともと簡単なものに適用すると無駄に
> 複雑になってしまうためです。

739 ：デフォルトの名無しさん：2011/12/05(月) 23:47:49.09

>>736
派遣はそれに加えライブラリを作れないからな
常にスクラップビルドだから今度最利用するっていう発想はない

740 ：デフォルトの名無しさん：2011/12/05(月) 23:50:47.45

>>737
1つ名前付きの高階関数用意しときゃいいのに、
10回も20回もおんなじlambda書くんだもんな

741 ：デフォルトの名無しさん：2011/12/05(月) 23:54:05.95

>>740
さすがにそれは無理があるわ

742 ：デフォルトの名無しさん：2011/12/05(月) 23:54:23.47

>>740
高階関数の意味分かってる？

743 ：デフォルトの名無しさん：2011/12/06(火) 00:01:25.17

>>733 >>738
だからお前は言語機能とデザインパターンをいい加減切り離せ

744 ：デフォルトの名無しさん：2011/12/06(火) 00:10:03.14

>>743
何を言っているのか分からない
738は自分が読んで納得した意見を紹介しただけなんだけど
あと733は別人ですよ

745 ：デフォルトの名無しさん：2011/12/06(火) 00:14:10.14

>>743
切り離してるから、実装方法が選べるなら
簡潔な方を選択しろと言っているんだろ
>>614のようなアホコードを書かないためにもな

746 ：デフォルトの名無しさん：2011/12/06(火) 00:14:25.11

>>737
一行で済む内容を手書きで一行書くのも IDE に十行生成させるのも
手間はそれほど変わらない。別にどっちでもいいと思うようにならないか？

フィールドを 3, 4 個定義して getter/setter の生成をポチっとやった瞬間に
JavaDoc コメントも入れれば 100 行超える。Java での開発ってそういうもんだろ。

747 ：デフォルトの名無しさん：2011/12/06(火) 00:21:24.46

614が優れたコードだと思ってる人って614本人以外に一人でもいるの？

748 ：デフォルトの名無しさん：2011/12/06(火) 00:21:35.68

>デザインパターンは、ある程度複雑な問題をきれいに解くために考えれたものですが、もともと簡単なものに適用すると無駄に
>複雑になってしまうためです。

これは「デザインパターン」を「オブジェクト指向」に置き換えても成立すると思う。

749 ：デフォルトの名無しさん：2011/12/06(火) 00:23:57.38

>>747
説明としてはまともだと思うが？

750 ：デフォルトの名無しさん：2011/12/06(火) 00:26:19.32

>>745
無名関数が存在するか、無名クラスが存在するか、
Delegateの様なデザインパターンを予めサポートした機能が存在するか、
そんなもん全部言語による。このスレで言語依存の話をギャーギャー続けるな。

751 ：デフォルトの名無しさん：2011/12/06(火) 00:27:46.63

>>747
優れてるか知らないけど俺はまだ解りやすいとは思った

752 ：デフォルトの名無しさん：2011/12/06(火) 00:29:25.26

>>747
相変わらず言語機能に拘るのな

753 ：デフォルトの名無しさん：2011/12/06(火) 00:29:47.02

>>749
説明としては…

>>751
まだ分かりやすい…

煮え切らない回答だな

754 ：デフォルトの名無しさん：2011/12/06(火) 00:30:33.85

>>752
あなたはお呼びじゃないです

755 ：デフォルトの名無しさん：2011/12/06(火) 00:31:50.77

無名関数とメソッド呼び出しだけ書かれたら
何してんのかよく解からんがな

756 ：デフォルトの名無しさん：2011/12/06(火) 00:32:34.74

>>614 と >>627 のどちらが良いコードかなんて議論を始める人と仕事はしたくないな。
相手の言いたいことの本筋を掴めず、どうでもいい枝葉末節に拘って時間を無駄にするタイプだろ。

757 ：デフォルトの名無しさん：2011/12/06(火) 00:35:10.73

しょうもないアダプターだけで200レスぐらい食ってるもんな。
余計な事言わなきゃ15レスぐらいで終わりそうなのに。

758 ：デフォルトの名無しさん：2011/12/06(火) 00:35:41.88

>>614がその本筋を非常に掴みづらい、分かりづらいコードなのが問題なんだよな…
そういう時間を無駄にしないためにこそ、こんなコードは書いちゃいけない

759 ：デフォルトの名無しさん：2011/12/06(火) 00:37:43.92

馬鹿にはわからんというだけの話さ

760 ：デフォルトの名無しさん：2011/12/06(火) 00:38:00.69

>>758
え？掴みづらかったか？俺は分かり易いと思ったが。

delegateTarget.start() を EventListener の要求するインタフェースに適合させるという意味で
function( event ){ delegateTarget.start() } が Adapter だと言えるという話だろう。

どこが分かりにくいのか疑問。

761 ：デフォルトの名無しさん：2011/12/06(火) 00:42:10.34

>>758
お前だけおかしいんだから、そろそろ空気読んでうせろよ

762 ：デフォルトの名無しさん：2011/12/06(火) 00:47:46.89

StartAdapter 関数を定義するのが冗長かどうかなんて論点が出てきておかしくなったんだよ。

「どうでもいい枝葉末節に拘って時間を無駄にする」という実例。
>>614 は日曜だろ。現に 2 日も無駄にしてる。2 日無駄にしてまだ終わらない。

763 ：デフォルトの名無しさん：2011/12/06(火) 00:51:27.76

>>760
そうやって意図を説明をしないと分からない
実際、自分以外の何人かも分からないとコメントしてる

>>627は見たままで誰でもすぐに理解できる
念のため、無名関数かどうかは問題にしてないよ

>>761
残念だけど俺だけじゃないんだな
そっちはどうか分からないけど

764 ：デフォルトの名無しさん：2011/12/06(火) 00:51:29.96

そりゃシンプルにかけばObserver、Visitorパターンしか残らんような例を出せば
ツッコミも入るわい
まあ、いいかげん引っぱりすぎだが

765 ：デフォルトの名無しさん：2011/12/06(火) 00:51:39.09

2日たって一周してるしな(>>758)
ホント無駄

766 ：デフォルトの名無しさん：2011/12/06(火) 00:53:28.99

>>764
2日同じ議論やって、要点だけ抜けて末節だけになっとる。スゲェ・・・。

767 ：デフォルトの名無しさん：2011/12/06(火) 00:53:47.15

では>>614はアホコードということで終わりで

768 ：デフォルトの名無しさん：2011/12/06(火) 00:54:04.94

>>764　どうでもいいわ帰れ

769 ：デフォルトの名無しさん：2011/12/06(火) 00:55:32.48

>>767
お前いたら、他の人に解りやすい説明もできなくなる。
失せろ。

770 ：デフォルトの名無しさん：2011/12/06(火) 00:55:38.90

どうでもいいなおまえが帰れよｗ

771 ：デフォルトの名無しさん：2011/12/06(火) 00:57:09.06

>>769
お前が関わると誤った知識が広まるから、お前こそ失せろよ
こういう奴が一番有害だな

772 ：デフォルトの名無しさん：2011/12/06(火) 00:57:40.73

みなさんスルーの方向で

773 ：デフォルトの名無しさん：2011/12/06(火) 00:57:44.02

>>763
> >>627は見たままで誰でもすぐに理解できる
> 念のため、無名関数かどうかは問題にしてないよ

そうかな？俺と感覚が違うなあ。
「Listener のこういう使い方は Adapter パターンの適用と見ることができる」
という説明のための例だろ？

これは駄目だと思うんだ。
> function(){ mainLogic.start() }

function(event) { mainLogic.start() }

と書いてほしい。引数の event を抜いたら、
むしろ本来説明したいことは伝わりにくくなると思う。

774 ：デフォルトの名無しさん：2011/12/06(火) 00:59:27.61

>>773
そこは見てなかった
けど、それこそ枝葉の問題だ

775 ：デフォルトの名無しさん：2011/12/06(火) 01:00:12.93

AdapterをObserverかVisitorと混同してないか？
と>>566が>>577にツッコまれて、苦し紛れに出した例が>>614だからな
無理矢理Adapterをねじ込んだから不要/冗長なコードになってる

776 ：デフォルトの名無しさん：2011/12/06(火) 01:02:10.38

Listener の話題で event 引数を省略することが枝葉だと判断するところが、
感覚の違いだということで。

ああ、こういう話（枝葉か本筋か）に正解はないよ。君と俺との感覚の違い。
どっちが普通でどっちがオカシイかという議論は 2ch でやっても無駄だからやめよう。

777 ：デフォルトの名無しさん：2011/12/06(火) 01:03:56.40

やけになって粘着してるからもうほっといた方がいい
この手の輩は勝利宣言で終わらなかったら延々と貼りつく

778 ：デフォルトの名無しさん：2011/12/06(火) 01:04:10.56

まぁ614の（説明のための）例が良いか悪いかは別として
実際の開発ではこういった書き方はしない方が良いという意味ではみんな同意するんじゃないかな？

779 ：デフォルトの名無しさん：2011/12/06(火) 01:05:19.52

では 778 の勝利宣言で終わろう

780 ：デフォルトの名無しさん：2011/12/06(火) 01:07:12.34

むしろ無難に収めようかと思ったのに
なんでこれが勝利宣言になるの？

781 ：デフォルトの名無しさん：2011/12/06(火) 01:07:54.22

どうでもいいけど、無名関数の中でメソッド呼んだだけで
アダプターパターン使ったとか現実世界で言うなよ
話通じないしアホだと思われるぞ

782 ：デフォルトの名無しさん：2011/12/06(火) 01:08:50.55

さすがに614もそこまではしないだろう

783 ：デフォルトの名無しさん：2011/12/06(火) 01:09:53.67

>>775
button と listener の関係が Observer で
listener と delegateTarget の関係が Adapter だね
着目する場所の違い。Visitor はどこを混同するとそうなるのかわからん。

784 ：デフォルトの名無しさん：2011/12/06(火) 01:14:20.80

delegation すりゃなんでも adapter なのか？

785 ：デフォルトの名無しさん：2011/12/06(火) 01:15:43.96

委譲とか考えてない設計に処理を差し込みたいからAdapterパターンを使うのであって
最初から委譲するように作ってあるものに対してAdapterパターンという言葉を使うのはちょっと違うような

786 ：デフォルトの名無しさん：2011/12/06(火) 01:36:10.07

>>649
UIごとじゃなく機能単位で分けられるんじゃない？
例えば、画像編集ソフトで画像を保存する事を考える。
この時、保存は、ツールバーでする人もいれば、ショートカットキーでするひとも居る。

(ActionListener)new SaveControl( (FileModel)fileModel, (ByteModel)imageModel );
みたいな使い方が出来る保存用リスナー作ってツールバーとショートカット(メニュー)に
割り当ててあげれば、ツールバーとショートカットキー用に別々のクラスを書かなくて済むでしょ。

あと、(ByteModel)imageModel みたいな感じで、インターフェースで受け
取れるようにしてれば(ByteModel)soundModel みたいに
他のデータにも使えて、もう少しコードを書く量は減らせると思う。

787 ：デフォルトの名無しさん：2011/12/06(火) 01:39:22.62

>>784
デリゲートパターンてのはデザパタに無いからね。

788 ：デフォルトの名無しさん：2011/12/06(火) 01:42:54.58

>>782
デザパタは置いとても、無名関数をアダプターとして使ってるぐらい言うんじゃないか？

789 ：デフォルトの名無しさん：2011/12/06(火) 01:46:06.56

>>788
>>778=>>781=>>782 なんだから触れるなよ

790 ：デフォルトの名無しさん：2011/12/06(火) 06:15:46.76

>>694
違う

ViewとListenerあわせてObserverパターン
立場とか一切関係ない

ModelにAdapterを適用したいことはあるかもしれないから排他ではないがListenerとは関係ない

791 ：デフォルトの名無しさん：2011/12/06(火) 06:25:31.34

>>785
この発言でおかしいことがはっきりした

あなたの理論で言うと、委譲とか考えないで、後から処理を差し込むためにAdapterパターン使うはずなのに、結局委譲使ってるんだなw

そもそも後から処理を差し込むためにAdapterパターン使う訳じゃない

Adapterの意味は適合
非互換のインターフェースを適合するために用いるのがAdapterパターン

他の方法でも実装できるんだから、Adapterパターンの本質には委譲は関係ない
委譲はAdapterパターンの実装方法の1つに過ぎない

792 ：デフォルトの名無しさん：2011/12/06(火) 07:20:42.51

>>790
MVCで、ObserverにCommandを組み合わせる事はよくあるが、
デザインパターンというものは排他的か？

793 ：デフォルトの名無しさん：2011/12/06(火) 07:21:47.32

こんだけ引っ張れる話題提供できた614は満足だろうな
ところで静的型付けを持つ言語でクロージャを持つ言語って、そのクロージャの型はどう定義するものなんだろうな
引数の型や数によってそれぞれ別のシグネチャを持つようにデザインされてたら
変に縛りが強すぎて、再びデザパタの生まれ変わりみたようなものを導入することになりそう

794 ：デフォルトの名無しさん：2011/12/06(火) 07:45:20.30

？？？？？メソッドのシグネチャと同じだろ。何を気にしてるのか全然わからん

795 ：デフォルトの名無しさん：2011/12/06(火) 08:01:18.52

>>792
排他じゃないと書いてるだろ
何を読んでそのレスをしたんだ

796 ：デフォルトの名無しさん：2011/12/06(火) 08:05:55.14

下記の例において、Timerクラスは既存のクラスであり修正できないものとする。
ここで、Timerクラスを利用したい開発者がいて、その開発者はactionPerformedというメソッドでTimerをstartしたいとする。
この場合、TimerAdapterというAdapterを作成することで、既存クラス(Timer)クラスを修正することなく、異なるインタフェースを持たせることができる。
このように、既存クラスを修正することなく、異なるインタフェースを持たせるということが、Adapterパターンの役割である。

class Timer {
　public void start();
}

class TimerAdapter extends Timer implements ActionListener {
　public void actionPerformed(ActionEvent e) {
　　super.start();
　}
}

イベントリスナにTimerAdapterという名前を付けることに違和感を感じるだろ？
その違和感こそイベントリスナがAdapterではない証拠。
イベントリスナを使うときに「意図」しているものはAdapterではない。

Timer#start()をActionListener#actionPerformed(ActionEvent e)という名前で使いたいから
リスナを作っているのか？明らかに違うだろ。

デザインパターンは、目的をもって使うもの。
クラス図が偶然に同じ形をしていたからといって、そのパターンを使っているとはいわない。

797 ：デフォルトの名無しさん：2011/12/06(火) 08:13:39.85

>>787
GOFパターンにはないけど、他のパターン本でみた気がする。ただの委譲にパターンとか大げさすぎる気もするけど。

798 ：デフォルトの名無しさん：2011/12/06(火) 08:21:21.56

>>796
同じ主張の人が現れて嬉しい
他にこれと同意見の人いないの？

799 ：デフォルトの名無しさん：2011/12/06(火) 10:21:50.96

いやｗ　俺は何度読んでも目が滑る。
>>796の意見は不思議と入ってこない。
反論か同意かしたかったが、どちらもできなかった。

800 ：デフォルトの名無しさん：2011/12/06(火) 13:16:05.39

同じ機能だけどシグニチャが違うメソッド間の
ギャップを埋めるのがAdapter
Timer#start と ActionListener#actionPerformed は同じ機能かって話ですよ

801 ：デフォルトの名無しさん：2011/12/06(火) 17:42:59.78

>>799
この主張に対しては妙にレスないんだよな
変な煽り合いにはいっぱいレスつくのに

802 ：デフォルトの名無しさん：2011/12/06(火) 19:46:27.48

>>796,800
これは結城本の例でいうと、直流12ボルトの電源をアダプタに繋いで交流100ボルトに
変換したとしても飽くまでも電源であるべきで、大まかな機能や目的は変わらないはず。
それに対して>>796の例では、タイマーをアダプタに繋いでもタイマーであるべきだが、
出来上がったクラスのインターフェースを見てみると、タイマーであるとはとても考えられない。

ということかな？
確かにこの例だと出来上がったクラスはイベントリスナであることが主であって、タイマー
としての機能はオプションで交換可能なものとして設計されているように見える。
これをアダプタと考えるのは難しいな。

803 ：デフォルトの名無しさん：2011/12/06(火) 21:22:34.62

なんでわざわざ継承に書き換えたんだよ。
そもそも視点がおかしい。
C#に書き換えてみれば解りやすい話。

startButton.Click += clock.Start;
stopButton.Click += clock.Stop;

本来のリスナーは、clock.Startとclock.Stop。
アダプター自体じゃない。アダプターは、リスナーオブジェクトから、
リスナーメソッドにインターフェースを変換してやる手伝いをしてるだけ。

804 ：デフォルトの名無しさん：2011/12/06(火) 21:53:39.31

>>796
> デザインパターン
先人が作ってくれた設計パターンにそれらしい名前をつけただけのもの
問題領域を抽象化する上で、もっとい良い物があればそれを使うべきだ

# 問題領域をうまく抽象化出来ないやつが多いからOOは遅いとか
# 蔑みの目でみられる

805 ：デフォルトの名無しさん：2011/12/06(火) 22:30:02.96

>>796の例を見れば見るほど設計ミスやら仕様変更の尻拭いに思える
actionPerformed()で受けるのをやめるか、
もっと言えばActionListener#actionPerformed(ActionEvent e)なんてパターンをやめて
クロージャやらデリゲートやらブロックやらを直接受け取るようにすればいいのに

806 ：デフォルトの名無しさん：2011/12/06(火) 22:33:20.13

>>803
C#の機能でごまかしてるようにしか見えないんだけど
そのコードをJavaで書くとどうなるの？

あと796は委譲の方が良いだろうけど、そこは問題じゃないだろ

807 ：デフォルトの名無しさん：2011/12/06(火) 22:40:22.76

>>806

startButton.Click += clock.Start;
startButton.addMouseListener( new StartAdapter( clock ) );
stopButton.Click += clock.Stop;
startButton.addMouseListener( new StopAdapter( clock ) );

重要なのは、本来のリスナーがclockのメソッド側にあること。
>>796は、リスナーを前提としてないオブジェクトとの結合に視点が固まりすぎてる。

808 ：デフォルトの名無しさん：2011/12/06(火) 22:48:05.85

>>807
結局「new StartAdapter( clock )」これだろ？
803では何を言いたかったのか？何のためにC#に書き換えたのか分からない

> 重要なのは、本来のリスナーがclockのメソッド側にあること。
> >>796は、リスナーを前提としてないオブジェクトとの結合に視点が固まりすぎてる。
これも何をいいたいのか全く分からない
もうちょっと伝わる書き方をして欲しい

809 ：デフォルトの名無しさん：2011/12/06(火) 23:02:06.55

>>808
startButton.Click += clock.Start;
リスナー本体は、clock.Start()。

>>796は、clock.Start()がリスナーだと思ってない。
だから、アダプター自体がリスナーだと思って違和感を感じるといってる。

810 ：デフォルトの名無しさん：2011/12/06(火) 23:04:38.64

>>808
C#に書き換えたのは、アダプターがキャスト(変換)機構に過ぎない事を強調してんの。

811 ：デフォルトの名無しさん：2011/12/06(火) 23:07:59.90

startButton.addMouseListener( clock.Start );

そもそもJavaでこう書けてりゃ今回のパターンでアダプターは書く必要ないんだよな

812 ：デフォルトの名無しさん：2011/12/06(火) 23:19:02.42

>>809
なんか噛み合ってないな

> >>796は、clock.Start()がリスナーだと思ってない。
思っていないというか、むしろclock.Start()がリスナーで無いことが前提の話なんだが

自分は>>796の言わんとしていることが分かっているつもりなので、おそらくは809の
方が勘違い・読み違いをしていると思う

というか796にもフォローして欲しいところだな

813 ：デフォルトの名無しさん：2011/12/06(火) 23:20:22.69

startButton.Click += clock.Start;

こういう書き方って結局できたか？
delegateの型を一致させないと+=なんてできなくね？

つまり、そこが違ってるからこそアダプタ云々の話になってるわけで、
C#だからといってそこを誤魔化してはだめじゃね？

814 ：デフォルトの名無しさん：2011/12/06(火) 23:23:02.03

そりゃ省いただけだが、結局シグニチャを一致させても同じ話だろ。
結局>>811ができないから、やってるだけ。

815 ：デフォルトの名無しさん：2011/12/06(火) 23:31:34.51

>>812
そもそも>>796はAdapterとしておかしいんだよ

816 ：デフォルトの名無しさん：2011/12/06(火) 23:36:40.51

もう寝る

817 ：デフォルトの名無しさん：2011/12/06(火) 23:47:35.30

もうAdapterは懲りたろ。

話は変わるが、MVCで入れ子になったビューの
コントローラーは、どう扱うのが理想なんだろか。
例えば、YesとNoのボタンを持ったViewがあるとする。
YesNoObserverでも作って、親のViewに管理させ、
どちらが押されたか通知ってのは基本として、
それ以外の動作(Yesボタンが右クリックされた)とかは、
どういう風に通知するのが理想だろ？
親のViewにYesとNoの全てのイベントを委譲
管理させるのは扱いづらい・・・。

818 ：デフォルトの名無しさん：2011/12/07(水) 00:02:47.63

>>812
ListenerにAdapter噛ませてListener機能の無いもん喰わせたら
おかしいと思うのは当たり前。>>802の話にそえば、
Adapter噛ませてもListenerに渡すものはListener機能を
持ってるもんじゃないとおかしい

819 ：デフォルトの名無しさん：2011/12/07(水) 00:21:12.68

リスナってのはイベントに対する単なるオブザーバ。イベント通知の構造。
アダプタってのはメソッド呼び出し。呼び出すための実装。

820 ：デフォルトの名無しさん：2011/12/07(水) 01:34:57.23

OOP初めて３日目ぐらいの幼稚な議論ですねｗ

821 ：デフォルトの名無しさん：2011/12/07(水) 07:23:18.42

>>817
うーん・・・
画面を右クリックした段階では、まだ画面との対話中で、モデルやらビジネスロジックには影響を与えないよね。
俺だったらビューのロジックにそのまま書いちゃうなあ。

バリデーションみたいにモデルかどこかと共通化したいなら別途ヘルパー群を作るとか。

822 ：デフォルトの名無しさん：2011/12/07(水) 07:32:26.99

(・∀・)ｼﾞｻｸｼﾞｴｰﾝ

823 ：デフォルトの名無しさん：2011/12/07(水) 08:12:46.02

もうAdapterパターンはいいよ
一人だけ理解してないということがわかった

824 ：デフォルトの名無しさん：2011/12/07(水) 12:56:27.73

>>819
リスナー　≠　オブザーバー

825 ：デフォルトの名無しさん：2011/12/07(水) 13:01:17.68

オブザーバはデザパタだけどリスナは
AwtやSwingでのイベントハンドラの呼び名だもんな

826 ：デフォルトの名無しさん：2011/12/07(水) 17:35:41.82

=ではないけど、リスナーはオブザーバーパターンで実装されている

827 ：デフォルトの名無しさん：2011/12/07(水) 21:36:12.12

たまたま、Observer Patternを使ってる部分があるだけで、
Observer Patternにしようとして作ってるわけじゃないけどな。
ListenerからListenerを呼び出す場合もある。
基本はdelegation event model。

この辺りが面白い。
http://javafaq.jp/S065.html

あとAWT, SwingじゃXxxxxAdapterってクラスがあるけど、
デザパタのAdapterとは違う。そもそもデザパタ本より先にモデルが
作られてるから仕方ない話だが。

828 ：デフォルトの名無しさん：2011/12/07(水) 22:48:35.04

GoF本は1995年
JDK 1.0は1996年
JDK 1.1(AWTにjava.awt.EventListenerが導入された)は1997年

829 ：デフォルトの名無しさん：2011/12/07(水) 23:01:40.99

delegation event model を導入したMFCが作られたのは1992年

830 ：デフォルトの名無しさん：2011/12/08(木) 11:12:24.08

JDKって0.98時代が長かったような
あと、MFCの元になったThinkCのライブラリは…いつ頃だっけ？

831 ：デフォルトの名無しさん：2011/12/08(木) 11:59:21.21

ttp://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html
In 1991, a small group of Sun engineers called the "Green Team" believed that the next wave in computing
was the union of digital consumer devices and computers. Led by James Gosling, the team worked
around the clock and created the programming language that would revolutionize our world -- Java.

832 ：デフォルトの名無しさん：2011/12/08(木) 17:48:41.34

MVCのSmalltalk-80が開発されたのは…とか言い出す奴が来るからヤメレ

833 ：デフォルトの名無しさん：2011/12/12(月) 10:49:49.15

デザパタが提唱されたのは90年代。
これは間違いないから大丈夫。

834 ：デフォルトの名無しさん：2012/01/16(月) 19:29:18.57

ファクトリパターンはサブシステムなどにプロダクトを登録するところまでやっていいんですか？
それとも生成以外のことには関与しないほうが良い設計でしょうか？
class IGameUnitFactory {
public:
virtual ~IGameUnitFactory(void) {}
virtual SharedPtr<GameUnit> Create(void) const = 0;
};
class GameUnitXXXFactory : public IGameUnitFactory {
private:
WeakPtr<GameState> game;
InitParam param;
public:
GameUnitFactory(SharedPtr<GameState> game, InitParam param) : game(game) , param(param) {}
SharedPtr<GameUnit> Create(void) const {
SharedPtr<GameState> g(game.Lock());
if(g) {
SharedPtr<GameUnitXXX> unit(new GameUnitXXX(param));
g->Register(unit);
return unit;
}
else { reutnr SharedPtr<GameUnit>() ; }
}
};

835 ：デフォルトの名無しさん：2012/01/16(月) 22:18:36.19

書籍デザインパターンには、Factoryパターンってのは無い。
それを踏まえた上で、一般的な意味でFactoryというなら
登録までしていいんじゃないか。

ちなみにデザパタ本の話を持ち出すと、
加工したオブジェクトを返すパターンはBuilderパターンと言われ、
切り替え可能な仮想コンストラクターのセットをAbstractFactoryという。
また、単一のコンストラクターを仮想化したものをFactoryMethodという。
まぁ、呼び方なんかどうでもいいし、どれか1つに合わせて
ガッチリ作らなきゃならんわけでもない。

836 ：835：2012/01/19(木) 00:44:41.91

FactoryMethodについていい加減な事書いてたんで、一応補足。
FactoryMethodは、クラスAがあったとき、クラスAの内部や、Aの関係各所でつかう
他のクラスのコンストラクターをAに直接使わせないようにする方法。
やり方は、他のクラスのコンストラクターの代わりに、Aに他のクラスを
戻り値とする仮想関数を定義する。で、Aの子クラスBで仮想関数に具体的な
コンストラクターを実装してやるってパターンね。

837 ：デフォルトの名無しさん：2012/01/19(木) 06:25:39.58

FactoryはGoFのと、EffectiveJavaに書いてあるのがあってややこしい

838 ：デフォルトの名無しさん：2012/01/19(木) 08:49:36.74

http://digital.asahi.com/articles/TKY201201160436.html

【簡単なまとめ】

★日本人の知らないうちに、欧州を中心に、世界中で日本文化ブームが起きて凄いことになっていた
　(実質第2次ジャポニズムブーム)
↓
★現地にいる人間からの情報で、日本人がやっと気づいた
↓
★日本文化の紹介を何もしてこなかった政府が批判され国会議員が動いた
↓
★政府やNHKが「クールジャパン」という言葉を作り、やっと広報活動を始めた
↓
★しかしすでに欧米では、ブームを通り越して生活の一部として定着してたw　すでに日常風景ww　広報の意味なし
↓
★韓国が日本のようにチヤホヤされたくて捏造韓流ブームを煽ったが、全く人気が出ず、世界的にバレたｱｲｺﾞｰ＜;#｀Д´＞
↓
★韓国が頭に来て、全世界での日本文化ブームもウソということにするﾆﾀﾞﾟ
↓
★在日朝鮮人の村上隆くん頼むﾆﾀﾞ
↓
★村上隆　「日本文化ブームはウソ」というと、さすがにバレるので、「クールジャパンはウソ」でごまかして発信
↓
★確かに、「クール・ジャパン」という人は外国ではほとんどいないのは事実だが
「ジャパン　イズ　クール」とか「ジャパニーズ○○　イズ　クール」という人は普通にいる
あとはwonderful amazing ,,,とかね。まぁどの言葉も似たような意味だから
「クール・ジャパン」と思っている人が多いのは間違いではない
↓
★村上隆が巧妙なのは、「クール・ジャパン」という言い方はしていないということを
　「日本文化が実は人気がない」という風に思わせるように発言していること
↓
★村上隆の印象操作工作発言にダマされたバカが続出中　←今ココ　( ´ω`)

839 ：デフォルトの名無しさん：2012/01/19(木) 09:58:58.08

日本がクールとか白痴だろ
東電や政府、オリンパスを始めとした糞企業のせいで日本のイメージは今や韓国と並んでワースト２だよ

840 ：デフォルトの名無しさん：2012/01/19(木) 18:29:34.95

ネトウヨが言う日本＝とっくに消滅した大日本帝國

841 ：デフォルトの名無しさん：2012/01/21(土) 18:31:34.71

大日本帝国も日露戦争くらいまでは良かったけど、その後はなあ。

842 ：デフォルトの名無しさん：2012/01/22(日) 20:02:15.73

東電や政府が糞なのは同意していいが
ここはオブジェクト設計スレだからなあ。
リスコフの置換原則の観点で意見を述べるなら
韓国と同一視できるか否かが鍵だな。答えはもちろんNOだ

843 ：デフォルトの名無しさん：2012/01/29(日) 12:46:29.39

>>840

健在だが？

http://lapizlazuri.net/041225kokuji2.jpg

844 ：デフォルトの名無しさん：2012/01/29(日) 23:01:47.23

オブジェクト指向の正しさに確信がもてないんで教えてほしい。
実際にコードを書いて、便利さを説明してるサイトや本ってないかな。
オブジェクト指向だとこういう実装になるけど、従来の手続き型で書くとこうなる、みたいな。

845 ：99：2012/01/30(月) 01:43:26.89

>>844
もうそれは結城本とかで自力でいろいろ試してみるとか。

846 ：デフォルトの名無しさん：2012/01/30(月) 07:03:16.45

オブジェクト指向の原則とかデザインパターンでインターフェースを利用した拡張性や保守性を上げるテクニックはいくつもあるけど、オブジェクト指向プログラミング最初の一歩はカプセル化のデータ隠蔽ができているドメインモデル貧血症になっていないコードだと思う

847 ：デフォルトの名無しさん：2012/01/30(月) 08:47:37.86

詳細の隠蔽と拡張のしやすさだな
でも拡張のしやすさについては間違った方法でやるとスパゲティ量産になるから単純に利点と言い切れないかな

848 ：デフォルトの名無しさん：2012/01/30(月) 15:27:35.62

いまや実装の継承は暗黒面と考えてもよいとおもってる(笑
まあ節度ある使い方してればそれほどでもないけどさ。

849 ：デフォルトの名無しさん：2012/01/30(月) 15:44:59.14

インターフェースを階層化して、実装はほぼ集約だけだな

850 ：デフォルトの名無しさん：2012/01/30(月) 18:13:36.43

全部委譲って現実的にどうなんだろう
極端な例だけどJFrameとかは委譲しないよね（これは型の問題もあるけど

ただ単に委譲するメソッドの割合が多いと実装継承使いたくなる
差分が1つのメソッドとか

851 ：デフォルトの名無しさん：2012/01/30(月) 18:48:59.22

おれは継承を包含に変換するプリプロセスプログラム作ったわ。

ネームスペースで問題(同じ名前で同じ型の同じ数の引数のあるメソッドとか)は、
コンパイル時にエラーとしてわざと検出してもらえるようにしてある。

問題のある箇所は自力で解決している。

852 ：デフォルトの名無しさん：2012/01/30(月) 21:29:31.68

>>850
JFrameを継承しなきゃならん時なんてまずないだろ。
コンポーネントがコンポーネントを直に持つクラスってよく見るが、
アレは無駄だ。
コンポーネントの外でデコレートしてやりゃ十分。

853 ：デフォルトの名無しさん：2012/01/31(火) 02:47:14.10

>>852
ここらへんは粒度とかコード量に依存してる気がする
外からデコレートで煩雑になると考えたら、
そのコンポーネントで囲っちゃうな

854 ：デフォルトの名無しさん：2012/01/31(火) 07:16:25.37

>>852
継承委譲の話からはそれちゃうけど、JFrameを継承した独自のクラスを作るのは無駄ってことか
確かにそうかも

JFrameを継承しているクラスに専用のメソッド用意したら、それこそ変な実装継承になっちゃうか

855 ：デフォルトの名無しさん：2012/01/31(火) 07:22:16.55

Swingの優れたオープンソースのコードって何かある？

MVCでModelとViewの関係をObserverパターンで関連付けるというメリットも書き方もわかるけど、現実的にどう適用してるのかを見てみたい

EclipseはSWTだし、大きくてどこ読めばいいかさっぱりだった

856 ：デフォルトの名無しさん：2012/01/31(火) 08:17:09.90

>>855
swingでまともなMVCは難しいよ。
VCなスタイルになる。何故かコントローラーの
Actionがモデルが持つべき機能を持ってるしね。

857 ：デフォルトの名無しさん：2012/01/31(火) 09:49:31.21

本でそういうことしてるパターンを見たことないんだけど、Observerパターンで通知関数を目的別に増やすことって普通？
連想型のコンテナをラップしたサブジェクトクラスを監視してるオブザーバークラスがあってそのオブザーバーはサブジェクトの更新時にコンテナの増分を知りたいという状況なんだけど
コンテナのコピーをとって毎回差分を計算してたら遅すぎるから増分を直接通知する通知関数をつくろうかと思ったんだけど
オブザーバーパターンの本来の利点の一つであるサブジェクトの設計がオブザーバーの設計に影響されないっていうのに反してる気がして悩んでる
言い直すと、オブザーバーがどんな情報を要求しているかサブジェクトが知らなければならない、というのが良くないんじゃないかなと感じるんだけど、どう思う？

858 ：デフォルトの名無しさん：2012/01/31(火) 12:28:22.32

>>856
ActionListenerを実装した専用のクラスを作ってそれをviewにaddActionListenerさせればVとC別れるってことにはならないのかな

Viewが持っているControllerのactionが持つべき機能って何？

859 ：デフォルトの名無しさん：2012/01/31(火) 12:35:26.97

>>857
現実的にはこういうときMVCに限界を感じる
だからMVCがダメという訳ではなく状況に応じてMVCから脱線することも必要だと思う

通知関数を増やさない方法としては、Modelがupdateするときにどの情報が更新されたかを知らせるプラグを渡すという方法もあるけど、フラグ管理は格好悪い

この2つ以外に方法あるのかな

860 ：デフォルトの名無しさん：2012/01/31(火) 13:04:04.64

>>857
1つ増加する度に通知すればいいだけだと思うけどそれじゃだめなんけ。
あと、監視側は別に監視対象に依存してもいいでしょ。
イベント情報から監視対象を参照しなければいいだけ。
監視対象が監視側に依存するのは論外だけど。

861 ：デフォルトの名無しさん：2012/01/31(火) 13:05:45.06

>>858
ごめん。VCって書いたのはMが消えるって意味。
VとCが癒着するって事じゃないよ。

862 ：デフォルトの名無しさん：2012/01/31(火) 15:27:36.82

>>860
「ひとつ増加するたびにその差分を通知してほしい」という欲求はオブザーバー側から来るものでしょ
これに応えるてしまうとサブジェクトのオブザーバーへの依存が切り捨てられないことになる
しかし依存は切れなくなるがパフォーマンスは改善する
というジレンマの話をしているの

863 ：デフォルトの名無しさん：2012/01/31(火) 17:50:24.81

>>861
Mが消えるということはないような
どういう状況を言ってる？

Mの処理をCに書いちゃうということかな

864 ：デフォルトの名無しさん：2012/01/31(火) 21:58:35.69

>>863
CがMを兼ねるってとこかな。
クラス的に同一というだけだから、
Actionクラスの子をモデルの生贄にして、
他のリスナーからActionを弄るという方法で
オブジェクト的に分離できるっちゃ出来るけど。

865 ：デフォルトの名無しさん：2012/01/31(火) 21:59:06.75

>>863
>>861は、MのロジックがCに集められて、Mがドメインモデル貧血症をおこし、ただのCのValue objectになっていると言いたいのかなと思った。

866 ：デフォルトの名無しさん：2012/01/31(火) 22:10:55.34

>>857
Subjectからは、変更があった事だけを通知してもらい、observerから、値をpullするってのは？

subjectにそんなプロパティをもたせると、依存関係ができてしまうのて、別途専用のインターフェースを用意し、それを介するようにする。

このインターフェースの実体 = subjectとするか、subjectを参照する何かにするかは自由。

867 ：デフォルトの名無しさん：2012/01/31(火) 22:24:59.22

ここまで書いて、差分の通知の事忘れてた。

コピーを取るという事は、subject自体どれが変更されたか認識していなくて、変更前後を確認する必要があるということ？

868 ：デフォルトの名無しさん：2012/02/01(水) 01:20:19.21

Observer側で今までの持ってて変更内容Subjectから貰えればどうとでもなるんじゃないの？
よーわからん。

869 ：デフォルトの名無しさん：2012/02/01(水) 06:22:32.02

>>864
その分離がMVCかと思ってたんだけどSwing（Java?）以外ではどうやってOとCの分離を実現するの？

870 ：デフォルトの名無しさん：2012/02/01(水) 06:25:36.70

>>865
それかと思ったけど、ドメインモデル貧血症はSwingに依存する話ではないから、また別の何かあるのかと思った
それとも他のに比べてSwingはドメインモデル貧血症を起こしやすい仕組みなのかな

871 ：デフォルトの名無しさん：2012/02/01(水) 08:26:04.04

>>869
＞OとCの分離を実現するの？
MとCのタイポ？
と仮定して、

分離せずModel-Viewになる。古くは、MicrosoftのMFCとか
ロジックをちゃんとMに置けば、この形式でも問題ないと思う。

ただ、表示のためにMのデータを整形する際、処理がVに入り込んでしまう。
Vの処理はイベントデリゲートを受けて、Mに丸投げしたいので、あまり嬉しくない。

妥当な妥協案は、変換(整形)用のみのクラスを間にはさむのがいいんじゃないかと考えてる。

例えば、Presentation ModelとかView Modelとかいわれるやつを組み込む。

872 ：デフォルトの名無しさん：2012/02/01(水) 08:38:54.14

ドメインモデル貧血症のなにがわるい？
オブジェクト指向じゃないってことか？

オブジェクト指向ってのはあくまで手段
手段が目的になってないか？

873 ：デフォルトの名無しさん：2012/02/01(水) 12:38:00.73

>>871
たいぽです
最初の話に戻るけどMFCとかは分離せずにMとVがくっつくというのはわかるけど、それならむしろSwingの方がMVCを実現しやすいような

分離するのがMVCなのかと思ってる

874 ：デフォルトの名無しさん：2012/02/01(水) 12:40:47.28

>>872
setter,getter作ってそれで操作されたらフィールドの値好きに書き換えられちゃうのが嫌だ

自分の作ったクラスは一定のルールの元使って欲しい
そうじゃないとバグがあったとき、どのような操作でバグが引き起こされたのか把握しづらい
データ隠蔽は必要

875 ：デフォルトの名無しさん：2012/02/01(水) 12:43:52.17

クラスに使われ方を想定し、ましてやそれを使う側に強いるなど…。
インタフェースだけで完結している単位が使いやすい。

876 ：デフォルトの名無しさん：2012/02/01(水) 13:14:18.71

>>869
QtやActionScriptなら、適当に作ったモデルをViewに
紐付けできる仕組みがある。

Swingには同じ一貫した仕組みは無い。
document modelとかあるけど一部のviewにしか使えない。

877 ：デフォルトの名無しさん：2012/02/01(水) 18:06:28.17

>>875
データ隠蔽とインターフェースは反する関係じゃないでしょ

データ隠蔽しない、更にクラスの使い方を強制しないってことは、Listインターフェースを継承したクラスでは配列へのアクセッサー用意してもらって、addメソッドやremoveメソッド無くせば満足なの？

878 ：デフォルトの名無しさん：2012/02/01(水) 18:22:11.97

>>876
バインディングというやつかな
VからMの依存関係は別のファイルに書くんだっけ

あとわからないことがあるんだけどMVCで新しいViewを表示したい場合はCがnewしていいの？
CはM以外に依存してはいけないという理解なんだけど他に適当なところが見当たらない

879 ：デフォルトの名無しさん：2012/02/01(水) 18:24:17.10

まあクラスにステートが存在する以上、イレギュラーな事態は起こりうるよね。
A→B→Cの順でメソッド呼んでね？的なのを防ぐには、状態別にオブジェクトを作るとかしないと無理ぽ。

880 ：デフォルトの名無しさん：2012/02/01(水) 19:32:02.72

>>878
バインドは一つのコード内にかけるよ。
QtならQObject::connectつてな関数で紐付するだけ。

881 ：デフォルトの名無しさん：2012/02/01(水) 19:34:51.87

>>878
viewとmodelでやるのは、本来の目的を
考えりゃあり得ないからね。
ちなみに本来の目的ってのは、ビジネスロジックの
隔離とかじゃないよ。

882 ：デフォルトの名無しさん：2012/02/01(水) 20:00:15.53

>>881
関連付けをVやMでやるのはおかしいということですか？
現在はVやMを作るメインメソッド的なところで関連付けてます

ただこれだと新しく途中でViewをnewするときに困る

あらかじめ表示されるViewをすべてnewしておいて表示したいときに表示命令を出すようにすれば解決するけど、メモリが激しく無駄…

883 ：882：2012/02/01(水) 20:13:02.03

>>881のレスは後半のnewの話だったかな

CからPMとかVMとか呼ばれる物に指示するのが正しい気がしてきた

PMはCからViewを表示しろという指示を受ける PMはそれをViewに通知

884 ：デフォルトの名無しさん：2012/02/01(水) 20:27:07.42

http://www.sra.co.jp/people/nisinaka/Jun4Java/MVC/mvc.gif

この図が本来の目的。この図を
考えればMとVとCを
どう分けるべきか大体わかると思う。

885 ：デフォルトの名無しさん：2012/02/01(水) 20:31:33.59

>>882
MVCを集約管理するクラスへの弱参照をVやCが持ってそれに新しいV作ったから適切にBindしてちょって頼めばいいんじゃね？

886 ：デフォルトの名無しさん：2012/02/01(水) 20:36:41.64

MVCを厳密に守る必要なんて必ずしもないんだし
頭固すぎだろ

887 ：デフォルトの名無しさん：2012/02/01(水) 20:40:04.00

>>878
CがVに依存して困る理由もないじゃん。
Vの実装に対する依存がいやなら、
CはVを抽象化して操作すりゃいい。

888 ：デフォルトの名無しさん：2012/02/01(水) 20:45:34.69

>>884
それはもうみんな理解した上での議論

889 ：デフォルトの名無しさん：2012/02/01(水) 21:00:17.49

>>884
それだけでそう分けるべきかわかってたら
MVCとかMVVMとかMPVとか乱立しねーよ(´・ω・｀)

MとVVMとかVCは分離されてしかるべきだけどV-VM、V-Cは依存しててもそんな問題ないよね

890 ：デフォルトの名無しさん：2012/02/01(水) 21:09:38.20

>>872
悪くないよ。もはやMVCと呼べるものではないだけ。

891 ：デフォルトの名無しさん：2012/02/01(水) 21:20:10.42

>>882
ロジックが読みづらくなるかもだけど、遅延生成にしてみるとか？

Viewを直接インスタンス化するのではなくて、ViewのFactoryをインスタンス化して、初めて必要になった時にViewを作らせる。

892 ：デフォルトの名無しさん：2012/02/01(水) 21:22:09.66

>>882
メモリもそうだけど動的にVIewの個数が変わるときも困るから
最初に全部用意ってのは選択肢としてないでしょ

893 ：デフォルトの名無しさん：2012/02/01(水) 21:25:07.52

Viewをキャッシュするという方法もある。
Androidの画面遷移みたいに、最新のn個を残しておいて、残りは適宜削除。
また必要になったら再生成。

894 ：デフォルトの名無しさん：2012/02/01(水) 21:26:51.32

>>892
個数が変わる時は、なんらかの対策が必要だけど、依存性を最初に解決できるメリットはあると思うよ。

895 ：デフォルトの名無しさん：2012/02/01(水) 21:31:21.97

>>890は、少し言葉足らずだったかな？

Mがドメインモデル貧血症になると、それはただのValue objectとなり、CがMの役割となり、結果Model-View になるだけかなと、思ってる。

896 ：デフォルトの名無しさん：2012/02/01(水) 21:39:56.01

>>886-887
その通りだけど、単純に思いつく方法より良い方法はないのかという話

897 ：デフォルトの名無しさん：2012/02/01(水) 21:54:17.64

View生成用のクラスを別途作るという意見が多そうですね
そのViewに関連して必要になるControllerも一緒に作る
この生成クラスにViewが監視すべきModelを渡す方法は少し考える必要がある

というのは1つの方法かな

このView生成クラスに、依存性の情報を管理させると考えると責務としてもしっくりくる
このViewとModelの依存関係というのは、アプリの1度の実行に依存するものだから、わざわざViewごとに生成クラスを分ける必要もない

ControllerがこのView生成クラスに直接依存するのが嫌だったら、何かインターフェースを用意してそれに依存すればいいのかな
インターフェースにはViewの生成機会単位のメソッドを用意

898 ：デフォルトの名無しさん：2012/02/01(水) 21:54:30.60

>>896
そもそもviewをどの単位で言っているのか謎。
サムネイルリストのサムネイル一個一個をモデルに基づき
生成するのはViewの役目だし、サムネイルリスト画面を
生成するのはControlerの役割じゃん。
どっちよ。

899 ：デフォルトの名無しさん：2012/02/01(水) 22:02:25.08

>>898
後者
気にしてなかったけど、前者は何も考えずViewでやってた

厳密にやるなら、サムネイル1個1個もControllerで作って、サムネイルリストの画面に引数で渡して上げたりした方がいいのかな
そうなるとボタンは・・・とか切りないな

900 ：デフォルトの名無しさん：2012/02/01(水) 22:09:30.09

>>899
Model更新に基づく部分にControlerが介入しちゃいかんよ。
せいぜいサムネイルを生成するFactoryの交換ぐらい。

901 ：デフォルトの名無しさん：2012/02/01(水) 23:05:56.64

MVVMってControllerに当たる処理の再利用出来ないけど、何がいいの？
IDEの支援は置いといてロジックとして何がMVCよりいいの？

902 ：デフォルトの名無しさん：2012/02/01(水) 23:09:50.98

>>897
以前使った方法は、画面の状態遷移を管理するためのクラスを用意し、全てのControllerに持たせる(1ウインドウで中のページを切り替えてたので、Singletonだったかも)。

次の画面に関する識別子をこいつに渡して、次画面を取り出すようにしてた。
併せてナビゲーション管理も行わせて、前画面に戻るための仕掛けを用意してた(むしろこの機能がメイン)

903 ：デフォルトの名無しさん：2012/02/01(水) 23:22:00.55

MVPパターンにならってViewがインターフェースを通して抽象化されてたら
大抵の画面はコントローラーが頑張り過ぎる実装で十分だと思うぞ。
きちんとしたMVCは実装コストが高くつくし再利用できて画面にガシガシ
更新が反映されるモデルが見つかったなって思ったタイミングではじめて
実装をはじめればOK。

904 ：デフォルトの名無しさん：2012/02/01(水) 23:26:01.43

>>902
こんな感じか？

//viewのシーケンス管理
Context context = new Context();

okeyButtonA.addActionListener(new NextControl(context, 1));
okeyButtonB.addActionListener(new NextControl(context, 2));
okeyButtonC.addActionListener(new NextControl(context, 3));

905 ：デフォルトの名無しさん：2012/02/01(水) 23:30:48.12

>>903
基本的なモデルは1度作ったら延々と再利用出来るじゃん。
複雑なモデルはともかく、ただのテキストとか、
整数はMVCガンガン使った方が楽でしょ。

906 ：デフォルトの名無しさん：2012/02/01(水) 23:49:13.97

>>901
MVVMはWPF(Windows Presentation Framework)を適用する際に、対象を分離することによるテスタビリティを良くするためものと思ってます。
再利用はあまり意識してなさそう。

MはUIと完全に切り離されてるので、xUnitで自動化しやすくなる。

Vは表示のみに特化されてるので、値が正しくバインドされるかどうかをテストするだけでよくなる(VMをMockにすれば自動化も容易？)

テストしづらい厄介なところをVMに集めてる。
ただVMはMVCのCの側面+PMの側面をもっているので、
C側面についてはハンドルしてるイベント処理から適切にMのメソッドが呼ばれるかどうかの確認。
PM側面は仕様どおりデータを整形してるかどうか確認。
共にMをモックにすれば、自動化できるかな？

907 ：デフォルトの名無しさん：2012/02/01(水) 23:54:09.57

>>905
むしろ、モデルは一度作ったら変更しにくいから
しっかりと作らないといけないだけだろ

それでも、後で変更したくなる

908 ：デフォルトの名無しさん：2012/02/01(水) 23:57:47.49

>>906
回答ありがと。
MVVMはQtやSmalltalkのようにIDE上でドラッグアンドドロップだけで、
M/V/Cに当たるものを繋ぎ合わせられたりする？

909 ：デフォルトの名無しさん：2012/02/01(水) 23:57:50.69

>>904
もう少し泥臭く、Controllerにcontextだけ渡しておき、Controllerでイベントをハンドリングする処理の中で必要に応じてcontextに問い合わせ。

状態管理をもつService Locatorみたいなところかな

910 ：デフォルトの名無しさん：2012/02/02(木) 00:03:11.33

>>907
stringモデルとか、intモデルとか、
代入と、読み出し、
リスナー登録ぐらいしか必要無いしそんな拘る所も無くね？

911 ：910：2012/02/02(木) 00:11:04.43

そういやmodelがviewに見せるのは、
読み出しインターフェイスだけ。
だからなおさらモデル設計が緩くてもそんなにこまんないよ。

912 ：デフォルトの名無しさん：2012/02/02(木) 00:13:16.17

オブジェクト指向とは的なことはマニアに任せて
現実ではオブジェクトは二種類にわかれると思う。

一つは処理がメインの構造オブジェクト
もう一つは値として使う値オブジェクト

フレームワーク部分は構造だろう。こいつは
他から値をもらうけど、中で長期間保持したりしない。
いわばシングルトンオブジェクトでいいもの。

それに対して日付オブジェクトとかは、数値型と同じく値が主。
処理も持っているけど、基本は値。値の拡張版
データとして保存しシリアライズするかもしれないようなもの。

913 ：デフォルトの名無しさん：2012/02/02(木) 00:15:24.69

>>910
部品単位と画面単位の話を分けて考えたほうがいいんじゃないのか。
単一の整数や文字列のモデルって単純な部品単位のモデルであって
画面単位の話じゃないよね。

914 ：デフォルトの名無しさん：2012/02/02(木) 00:16:50.05

>>901
Controlerってそんなに再利用できる？
というか再利用してもそんなに幸せにならない気がする。

915 ：デフォルトの名無しさん：2012/02/02(木) 00:18:03.22

>>908
IDE(Visual Studio)単体にはなかった気が

VにVMのプロパティを指定するところは、Expression Blendという、V構築ツールを使えば可能
IDEと統合されてたかどうかは不明。

VMの自動生成もなし。各々のフレームワーク作者が、用意しているっぽい

Mとのリンクもあったかな？

Visual Studioの世界では、まだまだ発展途上な感じ。

916 ：デフォルトの名無しさん：2012/02/02(木) 00:46:08.81

>>914
>>904ぐらいの粒度にしとけばね

917 ：デフォルトの名無しさん：2012/02/02(木) 01:11:44.47

>>913
画面単位は、部品のモデル差し直すぐらいしか
やる事ないから、あんまり重要視してないけど何かある？
個人的にはMVCは部品単位が一番効果を発揮すると思ってるけど。
3Dモデルを角度毎複数のviewに表示したり、
プログレスバーとラベルに同じ進捗表示したりさ。

918 ：デフォルトの名無しさん：2012/02/02(木) 06:18:46.82

Controllerの再利用のユースケースとしては、最初はこのボタンのControllerだったけど、他のボタンに変えよう、という状況？

このときこのControllerがMとVに依存しているのは問題なさそう
ボタンが変わったとしても依存しているViewとModelの操作をするという責務は変わってない

919 ：デフォルトの名無しさん：2012/02/02(木) 06:39:59.79

MVVMのVMは、MVCではどこが処理すればいいか定義されていないViewの見た目を変更するロジックとMVCのControllerの役割を担うのか

n番目のView
ModelからのViewへの変更通知に毎回VM(n)が挟まれる
ViewからのクリックはVM (n+1) が受け取りModelを操作するということかな

これって基本的にはMVPと同じ？

920 ：デフォルトの名無しさん：2012/02/02(木) 08:01:13.75

>>918
戻ると進むとか、保存とか、ウィンドウを
全て閉じたら終了とか一般的なものは
大概再利用可能じゃないか

921 ：デフォルトの名無しさん：2012/02/02(木) 08:42:30.65

>>920
その辺はそういった処理するのを関数とか小さいクラスのレベルで再利用するけれど、コントローラーはそれらを集約して使うだけでコントローラー自体の再利用とはちとちがくね？

922 ：デフォルトの名無しさん：2012/02/02(木) 12:59:12.44

Controllerで集約とかあんまりしなくないか？
戻る、進むControllerなんて、コンストラクタで捕縛した、
Modelの戻るメソッド呼ぶだけだし。
戻るメソッドに合わせて多少のイベント変換はするけど
大した事はしないよ。

923 ：デフォルトの名無しさん：2012/02/02(木) 17:52:09.10

MVCのパッケージ分けがわからん
どの単位で分ければいいの？
Modelは完全に独立して普通にパッケージを分ける

ControllerAクラスがViewAクラスを新たに表示するために依存しているとする
その1
a.controllerにControllerAクラス
a.ViewにViewAクラス
Bクラスも同様
その2
controller.aにControllerAクラス
view.aにViewAクラス
Bクラスも同様
その3
AクラスもBクラスもまとめて
controllerパッケージとviewパッケージに突っ込む
その4
ControllerクラスもViewクラスもまとめてaパッケージとbパッケージに突っ込む

924 ：デフォルトの名無しさん：2012/02/02(木) 18:55:07.83

何のためにパッケージ分けすんの？
そこが問題じゃね？

925 ：デフォルトの名無しさん：2012/02/02(木) 19:36:08.92

>>924
そもそも俺がそれを理解できてない

パッケージ設計の原則 - Strategic Choice
http://d.hatena.ne.jp/asakichy/20090130/1233317812

この原則見るとリリース単位と言われるけど、個人開発の場合リリースすることないしな
単純なグループ分けもしくは、パッケージプライベートを利用して公開するインターフェースを切るためとか？

パッケージプライベートを意識するなら>>923のその1が正しい気がする
Viewとかは全部パッケージプライベートにしておく
Viewに対するaddActionListenerメソッドだけはpublic
そしてこのaddActionListenerを利用して他のパッケージのControllerを登録する

926 ：デフォルトの名無しさん：2012/02/02(木) 20:58:21.34

パッケージつうか名前空間ってのは
衝突回避のためだけに
長い名前を書かなくて済むようにするためのもんだからね。
名前が重複せず関連性の強いもんに分けるだけでいいでしょ。
Socketならudpパッケージとtcpパッケージにそれぞれ作るとか。

927 ：デフォルトの名無しさん：2012/02/02(木) 20:59:09.75

>>923
モジュール単位で分けるのが好きなので、その4、をよく採用するかな？

928 ：デフォルトの名無しさん：2012/02/02(木) 22:42:14.52

Text::Model;
Text::View;
Number::Model;
Number::View;

一般的な名称を下位に置き、固有に近い名称を
上位に置く分け方が重複しづらく短縮もしやすくて合理的。
ただ名前空間の別名付けられないJavaだと使いづらい。

929 ：デフォルトの名無しさん：2012/02/08(水) 18:51:16.05

・一つのオブジェクトをいくつかのコンテナ（管理クラス）に異なるインターフェースで登録する
・コンテナを一箇所にまとめて共有し、能力照会でインターフェースを取得する

どっちがいいとおもう？
どっちでやってもごちゃごちゃするんだけど

930 ：デフォルトの名無しさん：2012/02/08(水) 20:17:13.71

よくわからない

931 ：デフォルトの名無しさん：2012/02/08(水) 20:33:27.90

既に分かりにくい。

932 ：デフォルトの名無しさん：2012/02/08(水) 20:49:08.03

外国の方がエキサイト翻訳を通して質問しているのだ
英語で答えて差し上げなさい

933 ：デフォルトの名無しさん：2012/02/08(水) 21:08:07.89

エキサイト翻訳って海外にもあるんだね
はじめて知った

934 ：デフォルトの名無しさん：2012/02/08(水) 22:41:27.19

RPGのキャラを管理するのに、
1. スキルごとにコンテナを用意。魔法戦士なんかは魔法使いコンテナと戦士コンテナの両方に登録。
2. コンテナはひとつだけ用意。スキルを指定してキャラ集合を取得するインタフェースを用意。

のどっちがいいか？　ってことじゃないか。

935 ：デフォルトの名無しさん：2012/02/08(水) 22:49:59.65

>>929
Service Locator作りたいってことかえ？

後者が良くわからんが、一つのコンテナに全部詰め込むって意味なら、型安全な前者を選ぶ。
そうではなく、前者のコンテナにを束ねたファサードなら、依存性を一箇所で管理できるので、後者の方がいいんじゃないの？

936 ：デフォルトの名無しさん：2012/02/09(木) 06:18:50.24

>>929
もう少し具体的な状況を説明してくれないとわからない
前者が良い場合も後者が良い場合もあると思う