1001コメント356KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001オブジェ・デザパタ

2010/05/02(日) 22:28:28

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

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

0002デフォルトの名無しさん

2010/05/02(日) 22:37:59

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

0003デフォルトの名無しさん

2010/05/02(日) 22:50:45

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

0004デフォルトの名無しさん

2010/05/02(日) 22:57:52

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

0005デフォルトの名無しさん

2010/05/02(日) 23:49:42

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

0006オブジェ・デザパタ

2010/05/03(月) 00:11:16

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

0007デフォルトの名無しさん

2010/05/03(月) 01:58:49

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

0008デフォルトの名無しさん

2010/05/03(月) 02:01:38

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

0009デフォルトの名無しさん

2010/05/03(月) 03:03:49

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

0010デフォルトの名無しさん

2010/05/03(月) 06:52:41

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

0011デフォルトの名無しさん

2010/05/03(月) 08:46:49

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

0012デフォルトの名無しさん

2010/05/03(月) 10:38:40

知ったかぶり多いな。

0013デフォルトの名無しさん

2010/05/03(月) 11:09:00

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

0014デフォルトの名無しさん

2010/05/03(月) 11:17:07

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

0015デフォルトの名無しさん

2010/05/03(月) 11:21:23

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

0016デフォルトの名無しさん

2010/05/04(火) 13:45:44

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

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

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

0017デフォルトの名無しさん

2010/05/08(土) 00:59:12

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

0018デフォルトの名無しさん

2010/05/09(日) 22:19:16

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

0019デフォルトの名無しさん

2010/05/09(日) 23:14:34

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

0020デフォルトの名無しさん

2010/05/10(月) 07:07:08

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

0021デフォルトの名無しさん

2010/05/10(月) 16:47:03

Strutsが悪い！

0022デフォルトの名無しさん

2010/08/29(日) 17:50:48

scheduled age
heigh ass hole ! happy?

0023デフォルトの名無しさん

2010/09/05(日) 13:54:24

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

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

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

0024デフォルトの名無しさん

2010/10/14(木) 02:17:36

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

0025デフォルトの名無しさん

2010/10/15(金) 14:25:38

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

0026デフォルトの名無しさん

2010/10/16(土) 00:40:52

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

0027デフォルトの名無しさん

2010/10/16(土) 06:25:38

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

0028デフォルトの名無しさん

2010/10/21(木) 22:39:16

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

0029デフォルトの名無しさん

2011/04/10(日) 17:06:14.60

そもそもMVCは糞

0030デフォルトの名無しさん

2011/04/10(日) 17:18:16.54

>>29
ｋｗｓｋ

0031デフォルトの名無しさん

2011/04/10(日) 17:30:50.94

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

0032デフォルトの名無しさん

2011/04/10(日) 17:35:59.38

最新の代替案をkwsk

0033デフォルトの名無しさん

2011/04/10(日) 17:59:23.45

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

0034デフォルトの名無しさん

2011/04/10(日) 19:01:33.83

AbstractionModel - DiscourseModel - InteractionModel

0035デフォルトの名無しさん

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やらに書くわけだろバカバカしい。

0036デフォルトの名無しさん

2011/05/05(木) 00:09:12.85

香ばしすぎるｗｗｗ

0037デフォルトの名無しさん

2011/05/07(土) 17:55:55.82

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

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

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

0038デフォルトの名無しさん

2011/05/13(金) 19:38:05.08

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

0039デフォルトの名無しさん

2011/10/02(日) 20:07:07.00

次スレここか？

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

0040デフォルトの名無しさん

2011/10/05(水) 04:08:26.73

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

0041デフォルトの名無しさん

2011/10/08(土) 19:20:18.35

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

0042デフォルトの名無しさん

2011/10/08(土) 23:28:11.32

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

0043デフォルトの名無しさん

2011/10/12(水) 20:29:02.44

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

0044デフォルトの名無しさん

2011/10/12(水) 20:33:43.47

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

0045デフォルトの名無しさん

2011/10/12(水) 20:34:04.98

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

0046デフォルトの名無しさん

2011/10/12(水) 23:04:40.99

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

0047デフォルトの名無しさん

2011/10/13(木) 15:19:06.77

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

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

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

0048デフォルトの名無しさん

2011/10/13(木) 16:12:04.51

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

0049デフォルトの名無しさん

2011/10/13(木) 17:15:07.54

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

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

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

0050デフォルトの名無しさん

2011/10/13(木) 18:54:19.07

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

0051デフォルトの名無しさん

2011/10/13(木) 22:33:30.95

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

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

0052デフォルトの名無しさん

2011/10/13(木) 22:44:15.72

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

0053デフォルトの名無しさん

2011/10/13(木) 22:48:33.15

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

逆じゃね？ｗ

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

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

0054デフォルトの名無しさん

2011/10/13(木) 22:59:57.30

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

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

0055デフォルトの名無しさん

2011/10/13(木) 23:02:08.95

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

0056デフォルトの名無しさん

2011/10/14(金) 15:12:01.84

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

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

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

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

0057デフォルトの名無しさん

2011/10/14(金) 15:32:28.38

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

0058デフォルトの名無しさん

2011/10/15(土) 08:04:33.82

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

0059デフォルトの名無しさん

2011/10/23(日) 22:44:02.16

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

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

0060デフォルトの名無しさん

2011/10/23(日) 23:21:26.98

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

0061デフォルトの名無しさん

2011/10/24(月) 00:09:47.57

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

0062デフォルトの名無しさん

2011/10/24(月) 03:03:55.97

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

0063デフォルトの名無しさん

2011/10/24(月) 12:43:31.08

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

0064デフォルトの名無しさん

2011/10/24(月) 13:31:22.98

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

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

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

0065デフォルトの名無しさん

2011/10/24(月) 22:10:17.46

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

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

0066デフォルトの名無しさん

2011/10/24(月) 22:29:47.86

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

0067デフォルトの名無しさん

2011/10/24(月) 22:32:34.22

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

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

0068デフォルトの名無しさん

2011/10/24(月) 23:46:51.92

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

0069デフォルトの名無しさん

2011/10/25(火) 00:00:49.98

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

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

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

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

0070デフォルトの名無しさん

2011/10/25(火) 00:02:35.14

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

0071デフォルトの名無しさん

2011/10/25(火) 00:08:41.30

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

0072デフォルトの名無しさん

2011/10/25(火) 00:22:48.10

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

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

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

0073デフォルトの名無しさん

2011/10/25(火) 00:30:01.63

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

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

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

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

0074デフォルトの名無しさん

2011/10/25(火) 00:30:51.53

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

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

0075デフォルトの名無しさん

2011/10/25(火) 00:40:15.32

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

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

0076デフォルトの名無しさん

2011/10/25(火) 00:50:30.21

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

0077デフォルトの名無しさん

2011/10/25(火) 02:53:17.39

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

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

0078デフォルトの名無しさん

2011/10/25(火) 07:45:12.50

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

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

0079デフォルトの名無しさん

2011/10/25(火) 08:16:12.77

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

0080デフォルトの名無しさん

2011/10/25(火) 08:18:00.91

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

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

0081デフォルトの名無しさん

2011/10/25(火) 09:48:44.85

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

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

0082デフォルトの名無しさん

2011/10/25(火) 09:57:35.71

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

0083デフォルトの名無しさん

2011/10/25(火) 10:23:46.45

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

0084デフォルトの名無しさん

2011/10/25(火) 10:32:18.95

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

0085デフォルトの名無しさん

2011/10/25(火) 11:26:09.36

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

0086デフォルトの名無しさん

2011/10/25(火) 20:09:48.47

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

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

0087デフォルトの名無しさん

2011/10/25(火) 20:32:03.03

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

0088デフォルトの名無しさん

2011/10/25(火) 21:02:02.72

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

→どっちも大事じゃない

0089デフォルトの名無しさん

2011/10/25(火) 21:08:22.36

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

ココロに響くお言葉

0090デフォルトの名無しさん

2011/10/26(水) 15:29:24.80

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

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

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

0091デフォルトの名無しさん

2011/10/26(水) 15:58:40.97

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

0092デフォルトの名無しさん

2011/10/26(水) 16:36:25.67

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

0093デフォルトの名無しさん

2011/10/26(水) 16:54:45.34

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

と思ってた時期が以下略　

0094デフォルトの名無しさん

2011/10/26(水) 17:11:32.92

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

0095デフォルトの名無しさん

2011/10/26(水) 21:16:31.08

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

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

0096デフォルトの名無しさん

2011/10/27(木) 00:40:23.24

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

0097デフォルトの名無しさん

2011/10/27(木) 01:20:27.66

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

0098デフォルトの名無しさん

2011/10/27(木) 05:51:20.24

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

0099デフォルトの名無しさん

2011/10/27(木) 06:31:09.36

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

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

0100デフォルトの名無しさん

2011/10/27(木) 07:32:32.83

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

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

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

0101デフォルトの名無しさん

2011/10/27(木) 08:57:01.35

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

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

0102デフォルトの名無しさん

2011/10/27(木) 08:57:10.40

コメントもなーｗ

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

↑こーいうｗ

0103デフォルトの名無しさん

2011/10/27(木) 13:31:26.33

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

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

010499 ◆QZaw55cn4c

2011/10/27(木) 20:53:18.37

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

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

0105デフォルトの名無しさん

2011/10/27(木) 21:16:08.44

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

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

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

010699 ◆QZaw55cn4c

2011/10/27(木) 21:33:37.10

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

0107デフォルトの名無しさん

2011/10/27(木) 21:43:40.97

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

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

0108デフォルトの名無しさん

2011/10/27(木) 21:54:55.95

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

0109デフォルトの名無しさん

2011/10/27(木) 22:16:28.03

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

0110デフォルトの名無しさん

2011/10/27(木) 23:21:45.71

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

0111デフォルトの名無しさん

2011/10/27(木) 23:24:58.23

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

0112デフォルトの名無しさん

2011/10/28(金) 00:11:54.25

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

0113デフォルトの名無しさん

2011/10/28(金) 00:24:18.81

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

0114デフォルトの名無しさん

2011/10/28(金) 00:34:37.01

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

0115デフォルトの名無しさん

2011/10/28(金) 02:30:42.77

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

0116デフォルトの名無しさん

2011/10/28(金) 07:45:26.37

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

0117デフォルトの名無しさん

2011/10/28(金) 07:46:15.80

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

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

0118デフォルトの名無しさん

2011/10/28(金) 14:56:12.47

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

0119デフォルトの名無しさん

2011/10/28(金) 16:00:05.09

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

0120デフォルトの名無しさん

2011/10/28(金) 21:39:27.42

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

0121デフォルトの名無しさん

2011/10/29(土) 18:52:41.79

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

0122デフォルトの名無しさん

2011/10/29(土) 23:09:03.35

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

0123デフォルトの名無しさん

2011/10/30(日) 08:04:36.83

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

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

0124デフォルトの名無しさん

2011/10/30(日) 09:36:47.46

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

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

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

0125デフォルトの名無しさん

2011/10/30(日) 09:45:52.75

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

0126デフォルトの名無しさん

2011/10/30(日) 09:48:44.01

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

0127デフォルトの名無しさん

2011/10/30(日) 09:52:04.88

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

0128デフォルトの名無しさん

2011/10/30(日) 09:58:02.60

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

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

0129デフォルトの名無しさん

2011/10/30(日) 10:39:33.84

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

0130デフォルトの名無しさん

2011/10/30(日) 10:56:45.44

>>125
自動生成じゃない

0131 ◆QZaw55cn4c

2011/10/30(日) 14:00:52.26

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

0132デフォルトの名無しさん

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++のステップ実行＆ウォッチで目視確認してたもんで。

0133デフォルトの名無しさん

2011/11/01(火) 22:44:42.89

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

0134デフォルトの名無しさん

2011/11/02(水) 08:56:32.89

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

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

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

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

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

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

0135デフォルトの名無しさん

2011/11/03(木) 01:11:46.70

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

0136デフォルトの名無しさん

2011/11/03(木) 01:52:47.80

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

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

0137デフォルトの名無しさん

2011/11/03(木) 02:16:14.66

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

0138デフォルトの名無しさん

2011/11/03(木) 10:25:28.48

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

0139デフォルトの名無しさん

2011/11/03(木) 12:41:57.54

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

0140デフォルトの名無しさん

2011/11/03(木) 12:44:01.64

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

0141デフォルトの名無しさん

2011/11/05(土) 08:16:43.72

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

コンパイラが必要だな

0142デフォルトの名無しさん

2011/11/06(日) 00:51:07.47

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

0143デフォルトの名無しさん

2011/11/06(日) 09:20:08.66

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

0144デフォルトの名無しさん

2011/11/06(日) 10:11:17.72

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

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

0145デフォルトの名無しさん

2011/11/06(日) 11:48:19.80

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

0146デフォルトの名無しさん

2011/11/06(日) 13:29:11.56

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

0147デフォルトの名無しさん

2011/11/06(日) 16:25:13.86

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

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

0148デフォルトの名無しさん

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, ・・・略・・・ );

0149デフォルトの名無しさん

2011/11/06(日) 21:18:02.54

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

0150デフォルトの名無しさん

2011/11/07(月) 01:03:35.48

こういうことってない？

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

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

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

0151デフォルトの名無しさん

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 );

0152デフォルトの名無しさん

2011/11/07(月) 10:56:11.58

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

0153デフォルトの名無しさん

2011/11/09(水) 12:56:53.49

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

0154デフォルトの名無しさん

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を流用したとき、毎回この関数を修正するのは変な気がするんだけど…。
上手く説明出来てなかったらすんません。

0155デフォルトの名無しさん

2011/11/10(木) 01:21:33.15

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

0156デフォルトの名無しさん

2011/11/10(木) 01:46:17.45

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

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

0157デフォルトの名無しさん

2011/11/10(木) 12:06:57.02

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

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

0158デフォルトの名無しさん

2011/11/10(木) 12:57:50.68

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

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

0159デフォルトの名無しさん

2011/11/11(金) 08:21:25.93

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

0160デフォルトの名無しさん

2011/11/11(金) 08:34:17.70

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

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

0161デフォルトの名無しさん

2011/11/11(金) 09:47:51.43

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

0162デフォルトの名無しさん

2011/11/11(金) 11:03:36.00

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

0163デフォルトの名無しさん

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() );
}

0164デフォルトの名無しさん

2011/11/23(水) 12:07:51.02

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

0165デフォルトの名無しさん

2011/11/23(水) 13:02:47.92

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

0166デフォルトの名無しさん

2011/11/23(水) 14:17:45.35

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

0167デフォルトの名無しさん

2011/11/23(水) 16:07:10.50

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

0168デフォルトの名無しさん

2011/11/23(水) 16:47:11.93

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

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

0169デフォルトの名無しさん

2011/11/23(水) 16:51:34.57

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

0170デフォルトの名無しさん

2011/11/23(水) 17:53:24.78

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

0171デフォルトの名無しさん

2011/11/23(水) 19:13:08.94

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

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

0172デフォルトの名無しさん

2011/11/24(木) 21:26:20.01

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

0173デフォルトの名無しさん

2011/11/24(木) 21:37:46.47

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

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

0174デフォルトの名無しさん

2011/11/25(金) 02:25:57.56

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

0175デフォルトの名無しさん

2011/11/25(金) 14:47:02.03

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

0176デフォルトの名無しさん

2011/11/25(金) 15:44:52.10

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

0177171

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をチェックしてる。

0178デフォルトの名無しさん

2011/11/25(金) 23:24:14.50

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

0179デフォルトの名無しさん

2011/11/25(金) 23:44:40.37

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

0180デフォルトの名無しさん

2011/11/25(金) 23:49:24.00

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

0181デフォルトの名無しさん

2011/11/26(土) 01:10:33.19

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

0182デフォルトの名無しさん

2011/11/26(土) 01:24:04.85

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

0183デフォルトの名無しさん

2011/11/26(土) 09:33:08.95

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

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

0184デフォルトの名無しさん

2011/11/26(土) 09:36:50.63

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

0185デフォルトの名無しさん

2011/11/26(土) 09:39:54.86

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

0186デフォルトの名無しさん

2011/11/26(土) 09:41:13.32

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

0187デフォルトの名無しさん

2011/11/26(土) 09:45:08.44

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

0188デフォルトの名無しさん

2011/11/26(土) 09:49:05.51

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

0189デフォルトの名無しさん

2011/11/26(土) 11:57:02.80

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

0190デフォルトの名無しさん

2011/11/26(土) 12:14:21.53

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

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

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

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

0191デフォルトの名無しさん

2011/11/26(土) 12:23:08.40

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

0192デフォルトの名無しさん

2011/11/26(土) 12:27:00.57

>>191
話にならんな。

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

0193デフォルトの名無しさん

2011/11/26(土) 12:31:05.13

>>192
言い過ぎだろう。

0194デフォルトの名無しさん

2011/11/26(土) 12:38:39.14

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

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

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

0195デフォルトの名無しさん

2011/11/26(土) 12:44:09.05

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

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

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

0196デフォルトの名無しさん

2011/11/26(土) 12:59:53.64

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

0197デフォルトの名無しさん

2011/11/26(土) 13:06:45.29

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

0198デフォルトの名無しさん

2011/11/26(土) 13:31:29.13

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

0199デフォルトの名無しさん

2011/11/26(土) 13:42:57.53

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

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

0200デフォルトの名無しさん

2011/11/26(土) 14:26:18.01

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

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

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

0201デフォルトの名無しさん

2011/11/26(土) 14:33:11.22

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

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

0202デフォルトの名無しさん

2011/11/26(土) 14:43:11.21

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

0203デフォルトの名無しさん

2011/11/26(土) 14:44:44.04

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

0204デフォルトの名無しさん

2011/11/26(土) 14:49:42.51

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

0205デフォルトの名無しさん

2011/11/26(土) 14:51:32.15

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

0206デフォルトの名無しさん

2011/11/26(土) 14:52:42.47

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

0207デフォルトの名無しさん

2011/11/26(土) 14:59:08.67

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

0208デフォルトの名無しさん

2011/11/26(土) 15:04:41.92

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

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

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

0209デフォルトの名無しさん

2011/11/26(土) 15:05:39.39

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

0210デフォルトの名無しさん

2011/11/26(土) 15:10:08.44

馬鹿ばっかりｗ

0211デフォルトの名無しさん

2011/11/26(土) 15:10:45.24

馬鹿が一人ｗ

0212デフォルトの名無しさん

2011/11/26(土) 15:19:41.95

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

0213デフォルトの名無しさん

2011/11/26(土) 15:27:05.16

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

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

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

0214デフォルトの名無しさん

2011/11/26(土) 15:29:08.27

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

0215デフォルトの名無しさん

2011/11/26(土) 15:37:29.40

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

0216デフォルトの名無しさん

2011/11/26(土) 15:49:27.47

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

0217デフォルトの名無しさん

2011/11/26(土) 15:49:44.26

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

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

0218デフォルトの名無しさん

2011/11/26(土) 15:50:18.34

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

0219デフォルトの名無しさん

2011/11/26(土) 15:51:05.71

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

0220デフォルトの名無しさん

2011/11/26(土) 15:51:54.16

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

0221デフォルトの名無しさん

2011/11/26(土) 15:52:23.77

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

0222デフォルトの名無しさん

2011/11/26(土) 15:58:40.69

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

0223デフォルトの名無しさん

2011/11/26(土) 16:01:48.46

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

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

0224デフォルトの名無しさん

2011/11/26(土) 16:13:30.36

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

0225デフォルトの名無しさん

2011/11/26(土) 16:14:41.71

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

0226デフォルトの名無しさん

2011/11/26(土) 16:18:42.92

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

0227デフォルトの名無しさん

2011/11/26(土) 16:20:40.47

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

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

0228デフォルトの名無しさん

2011/11/26(土) 16:21:20.04

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

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

0229デフォルトの名無しさん

2011/11/26(土) 16:24:46.68

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

0230デフォルトの名無しさん

2011/11/26(土) 16:30:38.30

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

0231デフォルトの名無しさん

2011/11/26(土) 16:37:30.50

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

0232デフォルトの名無しさん

2011/11/26(土) 16:38:56.44

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

0233デフォルトの名無しさん

2011/11/26(土) 18:46:35.67

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

0234デフォルトの名無しさん

2011/11/26(土) 19:51:02.29

>>233
230じゃないが。

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

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

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

0235デフォルトの名無しさん

2011/11/26(土) 21:04:56.20

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

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

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

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

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

0236デフォルトの名無しさん

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

0237デフォルトの名無しさん

2011/11/26(土) 21:12:26.72

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

0238デフォルトの名無しさん

2011/11/26(土) 21:18:17.95

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

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

0239デフォルトの名無しさん

2011/11/26(土) 21:46:06.84

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

0240デフォルトの名無しさん

2011/11/26(土) 21:57:28.40

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

0241デフォルトの名無しさん

2011/11/26(土) 22:06:23.44

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

0242デフォルトの名無しさん

2011/11/26(土) 22:08:45.64

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

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

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

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

0243デフォルトの名無しさん

2011/11/26(土) 22:18:18.50

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

0244デフォルトの名無しさん

2011/11/26(土) 22:23:33.89

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

0245デフォルトの名無しさん

2011/11/26(土) 23:01:24.72

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

意味不明

0246デフォルトの名無しさん

2011/11/26(土) 23:04:55.40

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

0247デフォルトの名無しさん

2011/11/26(土) 23:06:34.41

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

0248デフォルトの名無しさん

2011/11/26(土) 23:08:34.62

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

0249デフォルトの名無しさん

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 );

0250デフォルトの名無しさん

2011/11/26(土) 23:18:02.50

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

0251デフォルトの名無しさん

2011/11/26(土) 23:20:12.14

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

0252デフォルトの名無しさん

2011/11/26(土) 23:21:45.55

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

0253デフォルトの名無しさん

2011/11/26(土) 23:26:13.93

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

0254デフォルトの名無しさん

2011/11/26(土) 23:32:55.08

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

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

0255デフォルトの名無しさん

2011/11/26(土) 23:40:13.91

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

0256デフォルトの名無しさん

2011/11/26(土) 23:41:56.25

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

0257デフォルトの名無しさん

2011/11/26(土) 23:43:02.89

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

0258デフォルトの名無しさん

2011/11/26(土) 23:44:53.48

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

0259デフォルトの名無しさん

2011/11/26(土) 23:49:43.70

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

0260デフォルトの名無しさん

2011/11/26(土) 23:57:14.80

どっちもいらんからね

0261デフォルトの名無しさん

2011/11/27(日) 00:08:51.20

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

0262デフォルトの名無しさん

2011/11/27(日) 00:33:35.14

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

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

0263デフォルトの名無しさん

2011/11/27(日) 00:45:15.16

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

0264デフォルトの名無しさん

2011/11/27(日) 00:49:48.12

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

0265デフォルトの名無しさん

2011/11/27(日) 00:52:55.29

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

0266デフォルトの名無しさん

2011/11/27(日) 00:55:37.75

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

0267デフォルトの名無しさん

2011/11/27(日) 00:59:42.03

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

0268デフォルトの名無しさん

2011/11/27(日) 01:06:11.38

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

0269デフォルトの名無しさん

2011/11/27(日) 01:26:32.33

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

0270デフォルトの名無しさん

2011/11/27(日) 01:29:10.66

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

0271デフォルトの名無しさん

2011/11/27(日) 03:46:33.17

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

0272デフォルトの名無しさん

2011/11/27(日) 03:48:59.06

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

0273デフォルトの名無しさん

2011/11/27(日) 05:16:59.81

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

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

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

0274デフォルトの名無しさん

2011/11/27(日) 05:20:16.36

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

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

0275デフォルトの名無しさん

2011/11/27(日) 08:00:36.71

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

0276デフォルトの名無しさん

2011/11/27(日) 09:11:09.43

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

0277デフォルトの名無しさん

2011/11/27(日) 09:41:11.46

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

0278デフォルトの名無しさん

2011/11/27(日) 09:58:49.67

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

0279デフォルトの名無しさん

2011/11/27(日) 10:19:24.55

↑この人です

0280デフォルトの名無しさん

2011/11/27(日) 10:33:22.10

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

0281デフォルトの名無しさん

2011/11/27(日) 11:04:59.50

カタカタｗ

0282デフォルトの名無しさん

2011/11/27(日) 12:37:48.04

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

0283デフォルトの名無しさん

2011/11/27(日) 12:45:41.55

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

0284デフォルトの名無しさん

2011/11/27(日) 13:02:03.39

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

0285デフォルトの名無しさん

2011/11/27(日) 13:13:46.63

>>284
Scala

0286デフォルトの名無しさん

2011/11/27(日) 14:11:32.97

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

0287デフォルトの名無しさん

2011/11/27(日) 14:30:22.90

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

0288デフォルトの名無しさん

2011/11/27(日) 14:47:25.62

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

0289デフォルトの名無しさん

2011/11/27(日) 14:51:29.49

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

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

0290デフォルトの名無しさん

2011/11/27(日) 14:52:15.54

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

0291デフォルトの名無しさん

2011/11/27(日) 14:53:03.56

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

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

0292デフォルトの名無しさん

2011/11/27(日) 14:53:44.69

ソースは２ちゃんねる。

0293デフォルトの名無しさん

2011/11/27(日) 14:55:47.39

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

0294デフォルトの名無しさん

2011/11/27(日) 15:07:44.66

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

0295デフォルトの名無しさん

2011/11/27(日) 15:15:51.69

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

0296デフォルトの名無しさん

2011/11/27(日) 15:17:25.50

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

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

0297デフォルトの名無しさん

2011/11/27(日) 15:21:31.48

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

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

0298デフォルトの名無しさん

2011/11/27(日) 15:22:40.87

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

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

0299デフォルトの名無しさん

2011/11/27(日) 15:23:59.79

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

0300デフォルトの名無しさん

2011/11/27(日) 15:25:55.78

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

0301デフォルトの名無しさん

2011/11/27(日) 16:34:21.06

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

0302デフォルトの名無しさん

2011/11/27(日) 16:57:26.01

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

0303デフォルトの名無しさん

2011/11/27(日) 17:08:18.65

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

0304デフォルトの名無しさん

2011/11/27(日) 17:28:50.13

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

0305デフォルトの名無しさん

2011/11/27(日) 17:36:58.12

愚痴はツイッターでやれ

0306デフォルトの名無しさん

2011/11/27(日) 17:43:52.36

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

0307デフォルトの名無しさん

2011/11/27(日) 17:45:29.32

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

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

0308デフォルトの名無しさん

2011/11/27(日) 17:47:51.66

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

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

後半は、まぁ愚痴だねw

0309デフォルトの名無しさん

2011/11/27(日) 17:51:42.97

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

0310デフォルトの名無しさん

2011/11/27(日) 18:08:53.44

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

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

0311デフォルトの名無しさん

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/

0312デフォルトの名無しさん

2011/11/27(日) 18:21:25.85

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

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

0313デフォルトの名無しさん

2011/11/27(日) 18:26:48.65

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

0314デフォルトの名無しさん

2011/11/27(日) 18:37:15.01

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

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

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

0315デフォルトの名無しさん

2011/11/27(日) 18:39:06.55

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

0316デフォルトの名無しさん

2011/11/27(日) 18:47:04.72

誰かつられてやれよｗ

0317デフォルトの名無しさん

2011/11/27(日) 18:55:50.33

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

0318デフォルトの名無しさん

2011/11/27(日) 19:54:28.55

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

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

0319デフォルトの名無しさん

2011/11/27(日) 20:12:06.56

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

0320デフォルトの名無しさん

2011/11/27(日) 20:50:27.40

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

0321デフォルトの名無しさん

2011/11/27(日) 20:53:37.13

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

0322デフォルトの名無しさん

2011/11/27(日) 21:04:48.74

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

0323デフォルトの名無しさん

2011/11/27(日) 21:06:25.53

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

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

0324デフォルトの名無しさん

2011/11/27(日) 21:09:00.94

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

0325デフォルトの名無しさん

2011/11/27(日) 21:09:41.49

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

0326デフォルトの名無しさん

2011/11/27(日) 21:10:04.37

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

0327デフォルトの名無しさん

2011/11/27(日) 21:10:25.52

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

0328デフォルトの名無しさん

2011/11/27(日) 21:13:26.74

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

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

0329デフォルトの名無しさん

2011/11/27(日) 21:17:24.20

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

0330デフォルトの名無しさん

2011/11/27(日) 21:26:25.10

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

0331デフォルトの名無しさん

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が異なる値にはならないけど、何か？

0332デフォルトの名無しさん

2011/11/27(日) 21:31:16.39

>>331
違うな。

>>321が正しい

0333デフォルトの名無しさん

2011/11/27(日) 21:32:16.55

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

0334デフォルトの名無しさん

2011/11/27(日) 21:34:34.27

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

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

0335デフォルトの名無しさん

2011/11/27(日) 21:35:34.03

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

0336デフォルトの名無しさん

2011/11/27(日) 21:38:48.80

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

0337デフォルトの名無しさん

2011/11/27(日) 21:39:22.92

これももう10年近く前の話か
ttp://www.ibm.com/developerworks/jp/java/library/j-dcl/

0338デフォルトの名無しさん

2011/11/27(日) 21:42:00.86

>>336
そう思えるのは、あんたが命令型のショボい型推論しか知らないからｗｗ
井の中の蛙だねえｗｗｗ

0339デフォルトの名無しさん

2011/11/27(日) 21:48:03.43

どう見ても>>321が正しいですな。

0340デフォルトの名無しさん

2011/11/27(日) 21:50:12.91

>>321が言うとおり、
納豆を指して「これは大豆だから」と言った人に
「これは大豆じゃないよ、納豆だよ」と言い出してるのが
型推論は型検査じゃない派のドカチン君ですねｗｗｗ

0341デフォルトの名無しさん

2011/11/27(日) 21:51:36.73

>>340
まさにその通り！

0342デフォルトの名無しさん

2011/11/27(日) 22:03:39.73

たまに居るね
自分の設計思想を信じ相手は馬鹿であると見下し
よくわからないしょぼいものしかつくれない

0343デフォルトの名無しさん

2011/11/27(日) 22:12:23.86

こういうことじゃないかと思う

・型推論は型検査じゃない派 --> 目的と結果を分けて考えよう
・型推論は型検査じゃない派 --> 目的と結果をを混同してもええやないけ

ここで、
・型推論の目的：型の整合性の検証(型が無矛盾であることの証明), >>318から引用
・型推論の結果：型検査および型宣言の省略化

自分は型推論は型検査じゃない派だな

0344デフォルトの名無しさん

2011/11/27(日) 22:16:23.06

>>343
型推論の目的>>318は微妙だなあ。その目的を満たすなら型推論しないほうが合目的的だし。

0345デフォルトの名無しさん

2011/11/27(日) 22:30:10.98

>>343
型推論の目的は、型検査をするための記述を少なくすることですよ。

0346デフォルトの名無しさん

2011/11/27(日) 22:35:34.92

>>343
型推論は型検査じゃない派しかいないぞw

0347デフォルトの名無しさん

2011/11/27(日) 22:36:30.25

型検査じゃない！派
型検査じゃない？派

0348デフォルトの名無しさん

2011/11/27(日) 22:46:14.77

>>346
おっと、ミスッたぜ。>>343を以下のように訂正する。

>・型推論は型検査じゃない派 --> 目的と結果を分けて考えよう
>・型推論は型検査だ派 --> 目的と結果をを混同してもええやないけ

0349デフォルトの名無しさん

2011/11/27(日) 22:48:56.56

型推論が型検査と一緒もしくは一緒じゃないことがわかることでどういう嬉しさがあるの？

0350デフォルトの名無しさん

2011/11/27(日) 22:53:00.61

>>349
型検査だけできるってことが理解できる。

0351デフォルトの名無しさん

2011/11/27(日) 23:06:51.07

>>350
ならJavaとかは型検査してるけど型推論しないから初めから結論でてるんじゃないの

0352デフォルトの名無しさん

2011/11/27(日) 23:07:56.39

>>344
その目的に前提を含めて書けば、

・暗黙の(=省略された)型宣言があっても検証(=証明)できること

になるね

これを実現するために推論が必要になった、という話だと思う

0353デフォルトの名無しさん

2011/11/27(日) 23:13:13.31

>>349
言語を利用する立場であれば、会話の中で両者を一緒にしても推定できるから、
たぶん支障は無いと思う。多くがこのケースだから、一般的には一緒でかまわない。

ただし、言語を実装する立場であれば、両者を明確に区別して定義/理解できないと
苦労するはめになる(過去の自分)

0354デフォルトの名無しさん

2011/11/27(日) 23:58:55.68

>>284
C++でも出来るぞ
オーバーロードが曖昧な場合はキャストが居る。

0355デフォルトの名無しさん

2011/11/28(月) 00:01:22.46

>>349
>>288みたいな馬鹿をぷげら出来る

0356デフォルトの名無しさん

2011/11/28(月) 00:04:59.69

ExampleType x = Function( 1, 2 );
が
auto x = Function( 1, 2 );
って書けるだけだろ。
何下らないことでひきずってんの？

0357デフォルトの名無しさん

2011/11/28(月) 05:44:12.34

どう考えても別物だろ
Javaは型検査してるけど、型推論できない
完全に使い分けできるじゃん

0358デフォルトの名無しさん

2011/11/28(月) 11:18:59.45

ここは設計とデザパタのスレだ

0359デフォルトの名無しさん

2011/11/28(月) 11:19:43.56

どっか他所のスレでやってくれ

0360デフォルトの名無しさん

2011/11/28(月) 18:25:31.70

>>355
いや、客観的に言って、バカはおまえ

0361デフォルトの名無しさん

2011/11/28(月) 18:33:01.05

全ての型検査は必ず型推論を伴う。
例えば、
double x = "abc";
は型エラーだが、これはxの型について
- double xという宣言からxはdouble型である
- x = "abc"からxはString型である
の２つの推論結果をunifyできないことからエラーを検出する。

全ての型推論は必ず型検査を伴う。
これは、表現式の型を１つ１つ確定していくプロセスにおいて
必ず矛盾がないかを検証するから。

全ての型検査は型推論を伴い、全ての型推論は型検査を伴うのであれば、
型検査と型推論は同じものの別名にすぎない。Q.E.D.

0362デフォルトの名無しさん

2011/11/28(月) 18:42:27.69

そのネタはどうでもいいから帰れ

0363デフォルトの名無しさん

2011/11/28(月) 19:09:56.75

このスレは実装技術についていけずに
設計と称して四角形と直線をひくしか脳がない
底辺SEの巣だからなｗ

0364デフォルトの名無しさん

2011/11/28(月) 19:12:06.15

>>361
多分お前が言ってる型推論と皆が考えている型推論は別のものだと思うよ？
其れすらわからないで俺スゲー垂れ流してるのがあわれすぐるｗｗｗ

0365デフォルトの名無しさん

2011/11/28(月) 19:13:58.94

自分の世界に生きてるヤツはほっとけよ。
こっちに引き戻そうとしたって無駄なだけだろ。

0366デフォルトの名無しさん

2011/11/28(月) 19:17:57.90

>>364
少なくとも２０年前には既に型推論と型検査は同一技術だというのが
関数型言語界隈での常識だったが？

自分の無知を自慢するのって、楽しい？

0367デフォルトの名無しさん

2011/11/28(月) 19:36:54.88

>>366
わかったからJAVAで型検査と型推論の分離ができている訳を教えてくれ

0368デフォルトの名無しさん

2011/11/28(月) 19:38:32.56

型システム自体がショボいから。

0369デフォルトの名無しさん

2011/11/28(月) 19:39:46.32

しかし、Javaしかわからない（というかJavaすらマトモにわかってない）馬鹿は
言うことがメチャクチャで笑えるｗ

0370デフォルトの名無しさん

2011/11/28(月) 19:58:16.81

度々このスレユースケース図の話題でるけど、
UML自体はOOサポートしてるだけで、OOを志向してる訳じゃないから
オブジェクト指向型システム設計とはあんまり関係ないよな。
UML全体としてみれば飽くまでラショナルプロセスを支えるツール。

0371デフォルトの名無しさん

2011/11/28(月) 20:13:20.15

話題に出てるのはユースケース図じゃなくてユースケースね

0372デフォルトの名無しさん

2011/11/28(月) 21:18:22.77

ユースケースサンタマリア

0373デフォルトの名無しさん

2011/11/28(月) 21:25:26.89

オブジェクト指向のオススメの書籍教えて

0374デフォルトの名無しさん

2011/11/28(月) 21:37:57.47

Bluebook

0375デフォルトの名無しさん

2011/11/28(月) 22:05:22.48

試験答案帳。表紙が青いことからこの名前がついています。主として作文形式の試験に使われます。

0376デフォルトの名無しさん

2011/11/28(月) 22:05:56.66

Blue Book
読み方：ブルーブック
Blue Bookとは、CD-EXTRAの仕様書のことである。
ソニーとオランダのPhilips社によって開発されたものである。

マルチセッションでデータを記録できるようになっており、
第一セッションには、音声データが、第二セッションには、
パソコン用のデータが保存される。このCD-Extraの仕様書の
表紙が青かったことから、Blue Bookという名称が付いた。

0377デフォルトの名無しさん

2011/11/28(月) 22:21:28.91

>>373
ないんだな、それが

0378デフォルトの名無しさん

2011/11/28(月) 22:58:23.56

PSの青本のことかと思ってしまう。
赤青緑

0379デフォルトの名無しさん

2011/11/29(火) 04:53:37.90

本当はブルーブックがいいけど、今ならパープルブックで我慢だな

0380デフォルトの名無しさん

2011/11/29(火) 06:03:09.37

オブジェクト指向入門のこと？

0381デフォルトの名無しさん

2011/11/29(火) 19:00:57.60

今はブラックブックだろ？

0382デフォルトの名無しさん

2011/11/29(火) 23:04:23.52

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

0383デフォルトの名無しさん

2011/11/30(水) 22:01:58.18

デザパタなんてだれも仕事では使ってないよな？
本気で使ってる奴いる？

0384デフォルトの名無しさん

2011/11/30(水) 22:08:43.06

やってみようとしたがVisitorがムズくてやめたｗ

0385デフォルトの名無しさん

2011/11/30(水) 22:42:09.75

そういうアプローチの仕方するもんじゃないような

0386デフォルトの名無しさん

2011/12/01(木) 01:50:25.19

煽りじゃなくこのスレレベル低いのな
ちょっとがっかりしたんだぜ

0387デフォルトの名無しさん

2011/12/01(木) 07:03:36.97

デザパタ使わずに仕事してる奴なんているのか？
Strategyすら使わないとなると逆に難しいだろ

0388デフォルトの名無しさん

2011/12/01(木) 08:32:49.79

デザパタの何使ってる？

0389デフォルトの名無しさん

2011/12/01(木) 09:18:36.19

AbstractFactory, Composite, Facade, Strategyあたりが多いかな。

0390デフォルトの名無しさん

2011/12/01(木) 09:55:31.05

ほー，Composite, Iterater, Visitor, Builderじゃないの？

0391デフォルトの名無しさん

2011/12/01(木) 10:05:18.94

じゃないからそう言ってるんだろ(´・ω・｀)

0392デフォルトの名無しさん

2011/12/01(木) 10:18:33.66

Singleton、Iterator、Observer は意図しなくても自然に使ってると思うんだが。

0393デフォルトの名無しさん

2011/12/01(木) 10:28:43.88

デザパタを使ったクラスライブラリ等を使うのと、
クラスライブラリ等を作るためにデザパタを使うのと、どっち？
後者のことだけ話題にしてると思ったが？

0394デフォルトの名無しさん

2011/12/01(木) 10:42:12.22

みんな後者だと思うよ。というか、デザパタって意図的に使おうとしなくても、
オブジェクト指向言語を使って普通に開発を進めてれば、
自然に当てはまる構造がコードのあっちこっちに見つかるようになると思うんだけど。

0395デフォルトの名無しさん

2011/12/01(木) 11:37:58.89

インターフェース的なもので抽象化するものは結構デザパタのどれかに当てはまるだろ。
むしろデザパタのほとんどがインターフェース的なもので抽象化されたものだとも言えるが。

0396デフォルトの名無しさん

2011/12/01(木) 19:41:14.73

Javaなんかコアクラス使ってるだけでデザパタべったりになるんじゃない?

0397デフォルトの名無しさん

2011/12/01(木) 21:10:45.59

MVVMはデザパタに入れても良いんだろうか
入れても良いなら毎回必ずと言っていいほど使ってる

0398デフォルトの名無しさん

2011/12/01(木) 21:46:07.84

MVCと同じで、原子的パターンじゃないから却下。
デザパタを組み合わせた、分子的なパターンを含め始めたらきりがない。

0399デフォルトの名無しさん

2011/12/01(木) 23:03:02.81

>>392
> Singleton
役に立ったためしがない
つか、どんなときに使ってるんだよ

0400デフォルトの名無しさん

2011/12/01(木) 23:11:55.37

百害あって一利無しだよな＞Singleton

0401デフォルトの名無しさん

2011/12/01(木) 23:24:29.89

動的型付け言語にはデザインパターンは不要。

デザインパターンは静的型付け言語が不便だからできた
バッドノウハウ。

0402デフォルトの名無しさん

2011/12/01(木) 23:49:15.39

IteratorとかObserverとかどう考えても型付け関係無いパターン多いだろ

0403デフォルトの名無しさん

2011/12/02(金) 00:12:49.58

>>401
まったくその通りだと思う
少なくともGoF本の著者陣はそれを認識しているし、たとえそうであっても
それらをパターンとして命名しカタログ化した点にGoF本の意義があると述べている
ところが、なぜか「デザインパターンに沿ってなければOOPにあらず」という
不思議な風潮を(特にジャバラから)よく耳にするのが笑えるところ

0404デフォルトの名無しさん

2011/12/02(金) 00:14:20.66

やった。馬鹿が釣れたｗ

デザインパターンってSmalltalkの世界から生まれたものなんだけどｗｗｗｗ

0405デフォルトの名無しさん

2011/12/02(金) 06:14:14.39

動的型付けにも部分的には使えるだろうけど、別に動的型付け用のデザインパターンを作った方がいいな

0406デフォルトの名無しさん

2011/12/02(金) 06:21:25.41

>>399
Cライブラリをラッパーしたユーティリティクラスみたいなもの
イミュータブルで値を保持させておきたいクラス

どちらも複数生成する必要がないしどこから参照されても問題ないからSingletonにしたんだけど何か問題あるかな？

Singletonは使いどころが難しい…

0407デフォルトの名無しさん

2011/12/02(金) 06:28:54.25

>>404
Smalltalkではパターンとして整理しなくても普通に使えていたイディオムを
Javaではいちいち形を決めて名前を付けて整理しないとうまく使えない、
ってことでしょｗ

0408デフォルトの名無しさん

2011/12/02(金) 08:42:14.90

だからその名前をつけたのが
Smalltalk時代なんだってばｗ

0409デフォルトの名無しさん

2011/12/02(金) 10:55:35.75

>>401
>動的型付け言語にはデザインパターンは不要。
これってどういうこと？デザパタと型付けは関係無いと思うが．
>バッドノウハウ
これは同意だが．

0410デフォルトの名無しさん

2011/12/02(金) 11:00:04.80

まったく不要かはともかく、ちまたによくあるJava前提のデザインパターンは動的型付けの言語じゃ不要なものは多い。

0411デフォルトの名無しさん

2011/12/02(金) 12:34:06.30

いやいや使ってるならまだ救えるが、デザパタ得意って奴は他で使えん
のが多い気がする

0412デフォルトの名無しさん

2011/12/02(金) 13:06:29.55

デザパタ得意って何か怖いｗ
得意かどうかという、ステータス的捉え方が恐ろしい。

0413デフォルトの名無しさん

2011/12/02(金) 13:27:32.20

得意って比較的よく知ってて肯定的くらいのことだろ。

0414デフォルトの名無しさん

2011/12/02(金) 17:46:47.54

手段と目的を取り違えてるニオイがするってことさ

0415デフォルトの名無しさん

2011/12/02(金) 17:52:39.69

>>409
例えばStrategyなんかは共通のインターフェースを用意することにより、戦略を使い回すけど動的型付け言語ならそもそもインターフェースを用意する必要なく使い回せるということじゃないかな

0416デフォルトの名無しさん

2011/12/02(金) 17:57:55.36

デザインパターンは適したところに採用すれば素晴らしく便利なもの
しかし適材適所というのは別にデザインパターンに限らない一般的な話

だから変な使い方をする奴がいるからといってデザインパターンを否定するのは間違い

あとデザインパターンはオブジェクト指向の感覚を掴むきっかけとしては良いものだと思う

0417デフォルトの名無しさん

2011/12/02(金) 18:52:47.96

ぶっちゃけ、先人の作ったコードの中から似た物抽出して
それらしい名前つけただけの、なんちゃって技術だろ？

縛られ過ぎる方がおかしいw

0418デフォルトの名無しさん

2011/12/02(金) 20:06:28.43

>>415
動的型付けは、インターフェースを書かなくて済むだけで、
最低限のインターフェースを持ってないとどのみちエラーになるだろ。(nullや転送できるものを除く)
デザパタと動的型付けかどうかは関係ない。

0419デフォルトの名無しさん

2011/12/02(金) 20:13:26.76

>>406
そういう使い方をするものをシングルトンとはいわんだろ。
シングルトンってのは、デバイスの書き込み制御を独占管理したり、
アプリケーションに送られてくるメッセージを独占管理する時に使うもん。

あと、C++系固有の話だが、グローバル変数と違い、
初期化順序を制御できるという点がある。

0420デフォルトの名無しさん

2011/12/02(金) 21:08:27.72

このスレにふさわしい人たちが現れ始めたような気がする。

0421デフォルトの名無しさん

2011/12/02(金) 21:17:30.86

>>414
そもそもオブジェクト指向＆デザパタ自身がそのニオイがするのだが

0422デフォルトの名無しさん

2011/12/02(金) 21:22:15.53

オブジェクト指向＝縦割り
デザパタ＝輪切り
こんな感じかえ？

0423デフォルトの名無しさん

2011/12/02(金) 21:30:37.66

>>416
あなたはオブジェクト指向とは何か、デザインパターンのそれぞれが
何であるかをきちんと言えますか？感覚ではなく。

0424デフォルトの名無しさん

2011/12/02(金) 21:35:31.42

>>423
デザインパターン = 書籍『オブジェクト指向における再利用のためのデザインパターン』で紹介されたパターンの事

0425デフォルトの名無しさん

2011/12/02(金) 22:08:04.54

某言語は何でメソッドがオブジェクトじゃないんだろうな。
double Function( double ) function = Math.abs;
function( 100 );
実際にメモリにオブジェクトとしての実体は持たなくてもいいから、
参照に引き渡されたら自動的にオブジェクトを生成してくれりゃ良かったんだけど。

FunctionDoubleDouble function = MathLibrary.abs;
function.call( 100 );
まぁ、現状でも同等のものを作れないわけじゃ無いんだけれども。

0426デフォルトの名無しさん

2011/12/02(金) 22:11:20.08

>>410
> まったく不要かはともかく、ちまたによくあるJava前提のデザインパターンは動的型付けの言語じゃ不要なものは多い。

いや、全くわかってないｗ

デザインパターンは実装ではなくて考え方。

Java前提のデザインパターンとか
動的型付け言語で不要とか言うのは、
デザインパターンの本質をわかってない。

お前が言ってるのは実装が不要ってだけの話だろ。

いや、全くわかってないｗ

0427デフォルトの名無しさん

2011/12/02(金) 22:27:56.33

>>426
>デザインパターンは実装ではなくて考え方。
各デザインパターンの”考え方””本質”をきちんと言ってみてくれるかい？

0428デフォルトの名無しさん

2011/12/02(金) 22:30:18.12

>>427
クラスを変更せず、オブジェクト構造により拡張していく疎結合主義だろ。

0429デフォルトの名無しさん

2011/12/02(金) 22:44:58.89

>>419
Singletonって使い方限定されているものなの？
クラスのインスタンスを1つしか生成できないようなものをSingletonというのかと思っていたけど

0430デフォルトの名無しさん

2011/12/02(金) 22:47:20.18

>>427
結城本から

デザインパターンはクラスライブラリそのものではない

デザインパターンはクラスライブラリよりも一般的な概念です。

具体的なプログラム例を読むことも理解の助けにはなりますが、その特定の
プログラムだけがAbstract Factoryパターンなのではありません。肝心なのは
どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるか、なのです。

0431デフォルトの名無しさん

2011/12/02(金) 22:51:15.85

>>429
状態が1つでいいなら、モノステートでいいだろ。
実体が一つである理由を考えてみ。

0432デフォルトの名無しさん

2011/12/02(金) 22:52:40.25

「Rubyには○○パターンは不要！」

「え？じゃあRubyだとどうするの？」

「こうするだけで実装できる！」

「なにが実装できるの？」

「○○パターンだけど」

「そうだね、それがRubyにおける○○パターンの実装だよ」

将来>426が経験することになる実話ｗ

0433デフォルトの名無しさん

2011/12/02(金) 22:52:59.96

>>426じゃなくて>>410の間違い。

0434デフォルトの名無しさん

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も引数として同列に扱う
ここが大きな違い

0435デフォルトの名無しさん

2011/12/02(金) 23:04:04.45

>>431
状態が1つならSingletonにせずにstaticクラスにしてしまえばいい
状態を複数許して実体を1つにしたいときにSingletonを使うということであってる？
何故実体を1つにしたいかは、複数から操作されてしまうと困るから？
いまいちわかってないや

0436デフォルトの名無しさん

2011/12/02(金) 23:04:26.21

>>429
状態が連続していることを期待した使い方をするとグローバル変数と同じハメになる。
例えば、メソッド間の値の受け渡しに使えば、無限ループが発生することもある。
分岐の予想も困難になる。
まず、そういう用途に使っちゃいけないという点で限定される。
基本的に、どこからどう操作しようと他に影響が無いものじゃないといけない。
それから、シングルトンは、オブジェクトとしての実体をもっている事が一番重要。
CharDevice.Instance().Write(""); のような直接メソッドを呼ぶ用途じゃなく、
Device device = CharDevice.Instance(); のようにインスタンスを突っ込む用途に使用する。

0437デフォルトの名無しさん

2011/12/02(金) 23:19:53.04

昔は順次、分岐、繰り返しの3つのデザインパターンしかなかったよな
などとつぶやいてみる

0438デフォルトの名無しさん

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ドルを円に換算

クラスだけじゃなく、オブジェクトとして考えることが重要ね。

0439デフォルトの名無しさん

2011/12/02(金) 23:23:40.67

デザインパターンを明確に、正確に理解している　＝　オブジェクト指向を明確に、正確に理解している

0440デフォルトの名無しさん

2011/12/02(金) 23:27:53.72

>>424
答えてくれてありがとう。
でもそれが答えになっていないことはあなた自身が分かっていますよね。
>>434
まじめに答えてくれてありがとう。
そうですね。最初はそういう説明をしたりされたりするね。
”オブジェクト指向”を”対象中心”と言い換えてくれたんですね。
では”対象中心”とは何かと聞きたくなりますが。
例がついているのはありがたいですね。ＳＶＯのＯっていうのはほんとですか？
Ｓは中心にはならないのですね？

0441デフォルトの名無しさん

2011/12/02(金) 23:29:51.28

>>424や>>434のようなデタラメをもっともらしく言うのは頼むからやめてくれよ
冗談のつもりなのかもしれないが、>>420のように騙される人も出てくるからさ

0442デフォルトの名無しさん

2011/12/02(金) 23:31:56.69

デザインパターンはドカタの方がよく知ってるなｗ

0443デフォルトの名無しさん

2011/12/02(金) 23:32:20.33

>>441
具体的な正しい説明を頼む

0444デフォルトの名無しさん

2011/12/02(金) 23:32:25.98

俺はドカタじゃないから、デザインパターンなんて知らなくていいんだよ。とか
本気で言ってそうｗｗｗ

0445デフォルトの名無しさん

2011/12/02(金) 23:32:57.44

動的型付け言語にはデザインパターンはないとかいうような
バカどもですからねｗｗｗ

0446デフォルトの名無しさん

2011/12/02(金) 23:34:23.72

Object = 目的語

これを言い出す人多いよね。自動詞的メソッドをどう説明するんだろうか？
Thread#runなど。

0447デフォルトの名無しさん

2011/12/02(金) 23:34:56.79

>>439
だとすれば益々>>427に答えないといかん

0448デフォルトの名無しさん

2011/12/02(金) 23:35:20.78

0449デフォルトの名無しさん

2011/12/02(金) 23:38:17.45

>>440
SVOのOはObject
OOPのOもObject
smalltalkのメッセージ送信の対象という意味でも合致していると思ってる

0450デフォルトの名無しさん

2011/12/02(金) 23:39:34.46

>>424 以上の答えは無いだろうけどな。

0451デフォルトの名無しさん

2011/12/02(金) 23:41:30.04

>>449
( Message object object object object )
これどうすんの？

0452デフォルトの名無しさん

2011/12/02(金) 23:42:53.98

>>446
Threadクラスに対してrunというメッセージを送信する

I send run message to Thread
これの目的語というのが正しい気がする

0453デフォルトの名無しさん

2011/12/02(金) 23:44:28.14

>>448
結局結城本では、
デザインパターンとは，どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるかであると言っているのですね。
各デザインパターンについてそういう形の説明ができますか？

0454デフォルトの名無しさん

2011/12/02(金) 23:44:31.26

>>451
それはどういう意味？

0455デフォルトの名無しさん

2011/12/02(金) 23:45:25.58

>>454
マルチメソッド

0456デフォルトの名無しさん

2011/12/02(金) 23:45:46.24

>>431
横レスだがモノステートは調べて今知った。でもこれだと、派生クラスに適用したい場合はどうしたらいい？
あと、GoF 本は Singleton の目的を「インスタンス数を１つだけに制限して、それにアクセスするグローバルな方法を提供する」
って書いてるだけだから、俺は >>429 で合ってると思うんだが。出来たら、もうちょっと詳しく説明してくれないか？俺の頭では分からんので。

0457デフォルトの名無しさん

2011/12/02(金) 23:50:14.90

>>453
はい、この場合のクラスやインターフェースというのは
Java用語ではなく一般的な意味です。
それは、「その特定のプログラムだけがAbstract Factoryパターンなのではありません」と
書いてあることからも明らかです。

0458デフォルトの名無しさん

2011/12/02(金) 23:51:06.79

>>453
もしかしてデザインパターンを知らないの？

自分が、if文を教えて下さいと
言っているのと同じだって分かってるかな？

0459デフォルトの名無しさん

2011/12/02(金) 23:52:42.03

>>456
何を見た？ぐぐって先頭のページにでてくるモノステートは間違ってるからな。

class Mono
{
       static int value1;
       static int value2;
public:
       int Method()
       {
              return value1;
       }
}:
Mono mono;

モノステートはこういうヤツ。当然親も子も継承できる。

0460デフォルトの名無しさん

2011/12/02(金) 23:54:24.79

やっぱり、デザインパターンとかオブジェクト指向に関しては
Javaプログラマがかなり先を言ってるね。

0461456

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個にしたい場合はどうしたら良い？

0462デフォルトの名無しさん

2011/12/03(土) 00:00:40.83

>>460
デザインパターンの市販本のほとんどが、Javaを使って説明しているからね。

0463デフォルトの名無しさん

2011/12/03(土) 00:01:49.43

>460
実はそのデザパタとかＯＯが遅れているということもあり得る

0464デフォルトの名無しさん

2011/12/03(土) 00:02:02.55

マーティンファウラーとケントベックがオブジェクト指向の先端という感じがする
この２人はJavaというよりsmalltalk

というかオブジェクト指向の発祥ってどこなの？

0465デフォルトの名無しさん

2011/12/03(土) 00:02:12.81

>>462
Java以外にもたくさんあるぞ。
Amazonで「○言語デザインパターンで」調べてみ。

0466デフォルトの名無しさん

2011/12/03(土) 00:04:11.21

>>461
モノステートは状態を1つに保つだけ。
インスタンスの数は制限しない。
インスタンスの数を制限したいならシングルトン。

>状態が1つでいいなら、モノステートでいいだろ。
前にこう書いたろ。

0467456

2011/12/03(土) 00:06:52.86

>>466
んじゃ、>>461 のケースだとモノステートは使えんのね。ありがと。

0468デフォルトの名無しさん

2011/12/03(土) 00:07:00.38

プログラムが綺麗にバグなくかければ、オブジェクト指向だろうが、関数型だろうがデザパタだろうが何でもいいです(´・ω・｀)
実際はその辺のハイブリッドだしな。

0469デフォルトの名無しさん

2011/12/03(土) 00:08:47.71

軽くぐぐったらSimulaからsmalltalkで普及みたいだな

メッセージ送信を唄っているsmalltalkのオブジェクト指向に合致しないのものは、また別のオブジェクト指向と捕らえるのが正しいのかね

クラス、型システムをオブジェクト指向として捉えて広めたのがまた別に誰かいた気がする

0470デフォルトの名無しさん

2011/12/03(土) 00:10:36.03

>>468
バグの問題じゃないだろ。
OOのメリットは、既存のコードを変更しないで済むことなんだから。

0471デフォルトの名無しさん

2011/12/03(土) 00:15:40.66

質問。
デザインパターンについて、３０歳のＳＥに聞きました。
「あなたは、一パターンでもよいから、デザインパターンを適用したことがありますか？」
はい、と答える人は何人いると思う。

0472デフォルトの名無しさん

2011/12/03(土) 00:16:36.97

>>471です。
１００人に聞きました、が抜けていた。スマン。

0473デフォルトの名無しさん

2011/12/03(土) 00:16:57.44

>>467
そもそも何でインスタンスを一つにしたいんだ？

map[ SINGLETON_A ].Method();
map[ SINGLETON_B ].Method();

とかしたいわけじゃないんだろ？

0474デフォルトの名無しさん

2011/12/03(土) 00:18:47.52

>>471
ドカタなら日常茶飯事に使ってるだろｗ

0475デフォルトの名無しさん

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

0476456

2011/12/03(土) 00:26:25.89

>>473
インスタンスを一個に絞りたいことはよくあると思うんだけど？
例えばクラスのメタ情報とか、コードで定数を定義するときとか。
基底クラスで既定値を定義しておいて、派生クラスで変更分だけ上書きして使えば、コードの見通しが良いでしょ？

0477デフォルトの名無しさん

2011/12/03(土) 00:32:07.06

>>476
それはインスタンスじゃなくて状態を一つに絞りたいだけじゃないか？
あと、シングルトンは、親クラスを持つことはできるけど、子クラスを持つことは不可能だからね。

ちなみに、英語圏だとファクトリー用途が多いらしい(ファクトリーのメモリー消費節約のため)。

0478デフォルトの名無しさん

2011/12/03(土) 00:47:12.84

シングルトンの問題は、モックでの差し替えが困難なために、テストしづらくなる事。

レガシー本の例では、DBコネクションをシングルトンにした場合の呼び出し側のテストの書き方について書かれてる。

0479デフォルトの名無しさん

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);

0480デフォルトの名無しさん

2011/12/03(土) 00:52:50.02

>>478
だよね。

だから最近はDIコンテナ側の設定で
シングルトンにするかどうかを決めるようになってきてるよね。

動的型付け言語の世界にも
早く普及してくれるといいんだけど。

0481456

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); }

0482デフォルトの名無しさん

2011/12/03(土) 00:56:41.93

>>479
Postの戻り値がなんなのかさっぱりわからんけど、

もしそれがResultがインターフェース（抽象クラス）であるのなら
それはファクタリーだよ。

デザインパターンの本質
それは、実装ではなくて考え方なんだから
見た目（実装）は関係ない。

それがファクトリーの考え方による設計で、
実際にファクトリーの動作をしているのなら
それはファクトリーパターン

0483デフォルトの名無しさん

2011/12/03(土) 01:03:18.66

>>481
だから >>459のモノステートで十分じゃね？

0484456

2011/12/03(土) 01:14:14.58

>>483
そかな？
モノステートだと。基底クラスもモノステートじゃなきゃ new するたびにメモリ確保が走っちゃうし、インスタンス毎に値が書き換えられちゃうし。
Singleton の方が安心して使えると思うんだけど。

0485デフォルトの名無しさん

2011/12/03(土) 01:22:43.11

>>484
ああ、子の状態を一つにしたいのか。
それならシングルトンの方が向いてるかもね。
題材がシングルトンに向いてるかは別だけど。

0486デフォルトの名無しさん

2011/12/03(土) 01:23:24.32

明らかにインスタンスを１つに絞りたいのが目的の割にはどっからでもアクセスできすぎる
しかもインスタンスの生成場所まで変化するのはやりすぎ
あきらかに不具合

0487デフォルトの名無しさん

2011/12/03(土) 01:25:25.67

なんでメソッドの引数から渡すのを嫌ってグローバルアクセスにまわしたの？
ここの納得できる強力な理由がほしい

0488デフォルトの名無しさん

2011/12/03(土) 01:30:19.88

>>486 privateなコンストラクター書いてないし単にミスじゃね？

0489デフォルトの名無しさん

2011/12/03(土) 01:30:36.29

別に引数から渡していいんだよ。

0490デフォルトの名無しさん

2011/12/03(土) 01:35:32.55

>>487
多分意図がちがうと思う。列挙型の要素みたいな感じなんだろ。
変化するもんじゃなさそうだ。
まぁ、だったらコンストラクターprivateにして、オブジェクト側は、
public const static MetaData PERSON_META_DATA = new PersonMetaData()でいいと思うけど。

0491456

2011/12/03(土) 01:45:55.35

>>485
ごめんね、頭の中が多態で使う～でいっぱいになっててソースが不適切だった。
最初のソースでちゃんと説明していれば、頭の方で終わってた話だった。ごめん。

>>490
そうそう、Singleton の話だから private コンストラクタは書かなくても伝わるだろうと端折っちゃった。
const は書き忘れた。

0492490

2011/12/03(土) 01:49:14.38

よくよく考えたら全然良くないわ。そもそも>>476の話からすると、
クラスごとのメタ情報を持ちたいだけ。
だったら、そのメタ情報を付与するクラスにpublic MetaData MetaData();ってメソッドもたせて、
そのクラスの中に、private static MetaDate metaData = new MetaData( "Person" );とか持たせておけばいい。
まぁ、この方法だと既存のクラスには使えないけどね。まぁ、そういう場合はトレイトだ。

0493456

2011/12/03(土) 01:56:54.84

>>492
あくまで例だから、あんまり突っ込まんといて。
メタ情報を付加させる場合も実際はインナークラスとして定義したり、ジェネリックを使ったりと色々だから。

0494デフォルトの名無しさん

2011/12/03(土) 01:59:32.30

>>470
コードの再利用の目的の一つにバグの低減があるとは思わないのかね？

0495デフォルトの名無しさん

2011/12/03(土) 02:00:19.19

コードを再利用したら一つのバグが
何百個のバグになるだろ。

0496デフォルトの名無しさん

2011/12/03(土) 02:09:25.34

何百ヶ所のバグを修正するよりは、一ヵ所のバグを修正する方がマシだろ。

0497デフォルトの名無しさん

2011/12/03(土) 08:00:27.07

>>480
動的型付けならシングルトンでもモックに差し替えるの簡単だから
普及しないと思うよ。必要無いもの。

0498デフォルトの名無しさん

2011/12/03(土) 09:47:42.48

>>468
その通り

0499デフォルトの名無しさん

2011/12/03(土) 09:51:28.65

漏れは２年間ほど掛かったが、オブジェクト指向設計をマスタしました。
２，３のデザパタも習得しました。
これから残りのデザパタを習得するつもりです。
そこで教えてもらいたいのですが、どのデザパタが現場では使われますか。
全部なら全部でもよいのですが、よく使われるものは何か知りたいのです。
列挙していただけたら非常に助かります。

0500デフォルトの名無しさん

2011/12/03(土) 09:53:43.85

>>470
>OOのメリットは、既存のコードを変更しないで済むことなんだから。
この俗説ほんとか？スパゲッティもまたそうやってできたのだが

0501デフォルトの名無しさん

2011/12/03(土) 10:25:36.25

>>500
既存のコードを修正しないで新たな機能を追加することができる
その機能を実装する（使う）ときは当然コードの修正は必要
しかしその使うという意志を表明している部分を変更するだけで済む

機能の追加と実装を分けて行えるのがメリットだと思う

0502デフォルトの名無しさん

2011/12/03(土) 10:29:36.06

>>499
>>388 から同じ話題が出てる。ただ、現場で頻出するパターンを抽出して名前を付けたのがデザパタなので、
全部の名前と目的ぐらいは知っておいて損はないよ。一度 GoF 本を通して読んでおくといい。

0503デフォルトの名無しさん

2011/12/03(土) 11:38:25.79

>>501
OOでそれが出来る事に異論は無いが、OO以外では出来ないと思った理由は？

0504デフォルトの名無しさん

2011/12/03(土) 12:03:56.73

>>502
さんくす。
やはり全部ですかね。

0505デフォルトの名無しさん

2011/12/03(土) 12:19:28.84

>>503
ポリモーフィズムが実現できればOK
C言語ではできない

0506デフォルトの名無しさん

2011/12/03(土) 12:37:23.48

Cでも関数ポインタとか使えばできるだろ

0507デフォルトの名無しさん

2011/12/03(土) 12:46:08.43

組込みだとOOA、OODで開発進めて
実装はANSI Cという世界だったりするよ

0508デフォルトの名無しさん

2011/12/03(土) 13:20:03.35

確かこんな感じにできるな

【第4回】多態性（2/3）：CodeZine
http://codezine.jp/article/detail/3709?p=2

>>503に解答すると
オブジェクト指向"言語"以外でもできない　というわけではない
手続き型言語だとしても　"オブジェクト指向"　を採用することにはなる
しかしその場合オブジェクト指向"言語"ほどオブジェクト指向を容易に実現することができない

よってOOという思想を使わないと実現できない

ってことになるんじゃないのかな

0509デフォルトの名無しさん

2011/12/03(土) 13:21:05.82

カプセル化もC言語で実現できるし継承も無理矢理実現できる
極端な話他の言語の多くはC言語で作られているのだからできないわけがない
じゃあC言語は、オブジェクト指向言語や関数型言語なのか？というとそんなことはない

0510デフォルトの名無しさん

2011/12/03(土) 13:37:07.72

>>508
ポリモーフィズムひとつとっても、OOPのそれは
subtype polymorphismというポリモーフィズムの一種にすぎない。
OOという思想を使わないと実現できないってことは無いよ。

0511デフォルトの名無しさん

2011/12/03(土) 13:38:12.39

>>432
> 「Rubyには○○パターンは不要！」
>
> 「え？じゃあRubyだとどうするの？」
>
> 「こうするだけで実装できる！」
>
> 「なにが実装できるの？」
>
> 「○○パターンだけど」
>
> 「そうだね、それがRubyにおける○○パターンの実装だよ」
>
>
> 将来>426が経験することになる実話ｗ

>>426じゃなくて>>410の間違い。

↑はすでに>>410に書いてある通りじゃん。

0512デフォルトの名無しさん

2011/12/03(土) 13:56:24.05

>>510
ポリモーフィズムの実現にOOという思想を使わないと実現できない
ということは言ってないよ

>>470,>>500,>>501,>>503の流れとして、OOのメリットの1つはポリモーフィズムだよ
と言っているだけ

0513デフォルトの名無しさん

2011/12/03(土) 14:56:48.69

>>501
>既存のコードを修正しないで新たな機能を追加することができる
そのカラクリは要するになんだっけ？

0514デフォルトの名無しさん

2011/12/03(土) 17:45:07.71

>>513
ポリモーフィズム
それはOOの1つのメリット

これに何か問題ある？

0515デフォルトの名無しさん

2011/12/03(土) 17:53:30.03

>>514
俺には難しい説明だな。
それにポリモーフィズムってマイナーな特徴という認識なのだが

0516デフォルトの名無しさん

2011/12/03(土) 17:56:49.38

>>514
OO以外でも実現できるポリモーフィズムを
OOのメリットと呼ぶのに違和感がある

0517デフォルトの名無しさん

2011/12/03(土) 18:05:01.93

>>514 >>515 >516
ＯＯが何であるかがはっきりしていないんだからあまり意味のない
コメントだな

0518デフォルトの名無しさん

2011/12/03(土) 18:17:36.32

最低限このへんは読んでから書き込むべき
ttp://lucacardelli.name/Papers/OnUnderstanding.A4.pdf

0519デフォルトの名無しさん

2011/12/03(土) 18:23:07.26

>>516
まずOOのメリットはポリモーフィズムだけではなく、一般的にはカプセル化、継承もそれに加わる

あとOO以外で実現というのがそもそもおかしい

OO以外ではなく、オブジェクト指向”言語”以外でも実現できるというのは同意
手続き型言語でもオブジェクト指向の思想は反映できるということ

だと思ってる

0520デフォルトの名無しさん

2011/12/03(土) 18:32:31.54

>>518
だれに言ってるのかどこを読めと言ってるのか知らんがそういうのは
踏まえたうえでの議論だと思うが

0521デフォルトの名無しさん

2011/12/03(土) 18:41:58.66

>>518
ML polymorphism がｱﾋｬってのはわかった

0522デフォルトの名無しさん

2011/12/03(土) 18:48:15.75

>>520
1.3章あたりに polymorphism のざっくりとしたレビューが書いてあるから、そこじゃね？
OOP の polymorphism にも触れてる

0523デフォルトの名無しさん

2011/12/03(土) 18:59:14.45

>>519
ポリモーフィズムもカプセル化もオブジェクト指向に固有のコンセプトじゃない
関数型言語にだってある

0524デフォルトの名無しさん

2011/12/03(土) 19:03:54.05

継承はユニーク

0525デフォルトの名無しさん

2011/12/03(土) 19:19:33.46

アグリゲーション・コンポジション辺りは？

0526デフォルトの名無しさん

2011/12/03(土) 19:22:25.60

>>523
それはマルチパラダイムということじゃなくて？
関数型言語の定義要素の1つとしてポリモーフィズムもカプセル化もあるの？

0527デフォルトの名無しさん

2011/12/03(土) 19:34:37.47

>519
オブジェクト指向の思想って？
与太話になりそうで好かん

0528デフォルトの名無しさん

2011/12/03(土) 19:37:32.78

>>526
SMLにはポリモーフィズムもカプセル化（モジュールの）もあるけど
オブジェクト指向言語という人はいないと思う

0529デフォルトの名無しさん

2011/12/03(土) 21:31:40.86

>>528
ということはオブジェクト指向とそうじゃないものわ分けるには、ポリモーフィズム、カプセル化とは別の基準があると思ってるということだと思うけどそれはなんなの？

それともオブジェクト指向というものをそもそも認めないということ？

0530デフォルトの名無しさん

2011/12/04(日) 01:45:35.22

>>529
528じゃないが、原理の面から言って、オブジェクト指向かどうかは、
オブジェクトに指向してるかどうかが基準であって、
OOPLかどうかは、OOPをすることを目的として
言語が設計されてるかどうかの問題。

ある言語を使ってOOP出来るかどうかによって
その言語がOOPLかどうか決まるわけじゃない。

SMLは、オブジェクトの連携によって駆動するプログラムを
作るために設計された言語なの？

ちなみに俺は多態やらカプセル化やらは、OOのメリットだとは思ってない。
OOである方法論の単なる構成要素のうちの1つだと思ってる。

0531デフォルトの名無しさん

2011/12/04(日) 08:36:14.33

>>530
＞ある言語を使ってOOP出来るかどうかによって
＞その言語がOOPLかどうか決まるわけじゃない。
ここは>>519の通り同意見。

ではそのOOP出来るというのはどういうことを指すのかを知りたい
ポリモーフィズム、カプセル化、継承できることを指すのかと思っていたけど、
確かにこの3つは、何かを目指した手段と言われれば納得

その目指す先は「オブジェクトの連携によって駆動するプログラム」？
オブジェクトの連携によって駆動するプログラム　とは具体的にどういうこと？

0532デフォルトの名無しさん

2011/12/04(日) 09:38:50.28

破壊的操作（副作用）に対するスタンスがOOPと関数型言語では違う気がする

関数型では破壊的な操作を必要最小限にする方向を目指すけど、
オブジェクト指向ではそんなこと無くて、その代りに
レースコンディションの解消はオブジェクトが各自の責任で行う

0533デフォルトの名無しさん

2011/12/04(日) 09:55:58.55

>>530
>オブジェクトに指向してるかどうかが基準であって
だからそのあなたが大事にしている「オブジェクトに指向してる」って
いうのはどういうことなの？

0534デフォルトの名無しさん

2011/12/04(日) 10:11:45.44

昨日、コンポジット、プロキシパターンを勉強した。
コンポジットには感激した。これは使える。

0535デフォルトの名無しさん

2011/12/04(日) 10:28:38.10

>>534
>コンポジットには感激した
その大部分は再帰に感激したのかな？それとも

0536デフォルトの名無しさん

2011/12/04(日) 10:35:11.95

>>526
型クラス(typeclass)とか？
これは、どっちかというと、オーバーロードのニュアンスが強いから、ちょっと違うか
日本語訳も多相が使われるし

0537デフォルトの名無しさん

2011/12/04(日) 10:52:24.17

>>532
それは関数型言語とそれ以外の言語の比較であって、オブジェクト指向の特徴とは言えないような…

0538デフォルトの名無しさん

2011/12/04(日) 11:07:06.06

>>535
再帰はもちろんだが、単独者と部下持ちの区別をパターンでやってしまうところがよい。

0539デフォルトの名無しさん

2011/12/04(日) 11:22:16.90

>>535
区別？むしろ同一視するんじゃなかったっけ
細かくてスマン

0540デフォルトの名無しさん

2011/12/04(日) 11:35:19.65

>>539
＞＞538です。細かいことはSEとしてはよいことです。
区分という表現は曖昧でした。エレメントがあるかないかを見て分別しているでした。

0541デフォルトの名無しさん

2011/12/04(日) 14:31:35.80

>>519
継承も多態性もカプセル化もメリットなんかじゃないだろ。
「ウチの車のメリットはV10エンジンを積んでることです」なんていうのかよ。
「リッター80kmで、1秒で100Kmまで出ることです」ってのがメリットだろ。

0542デフォルトの名無しさん

2011/12/04(日) 14:37:11.89

リッター80kmで、1秒で100Kmまで出る
エンジンを積んでるのはメリットだけど？

もしかして継承や多態性やカプセル化で
何が出来るか知らないってこと？
そこから説明しないといかんの？

0543デフォルトの名無しさん

2011/12/04(日) 14:47:25.08

>>542
「V10エンジン」を積んでることは別にメリットじゃない。
同じ性能出るエンジンなら別のエンジンでも構わない。

同じことが出来るのであれば、別に継承である必要でもないし、
カプセル化である必要もないし、多態性である必要もない。

0544デフォルトの名無しさん

2011/12/04(日) 14:52:53.90

継承だって、サブクラス化や、転送とか環境により別の実現方法があるし、
カプセル化だってOO的な手法じゃなくクロージャで実現する方法もある。
多体性というならドライバ関連でOO以前からありふれてた
OOのメリットとは言わん。

0545デフォルトの名無しさん

2011/12/04(日) 14:54:41.81

ということで極論すれば
アセンブラでOKと言いたいわけかｗ

0546デフォルトの名無しさん

2011/12/04(日) 14:55:47.66

>>540
曖昧なんじゃない、不適切だ

0547デフォルトの名無しさん

2011/12/04(日) 14:55:53.00

クロージャーじゃなくても
ジャンブで実装できるしな。

0548デフォルトの名無しさん

2011/12/04(日) 14:59:25.39

>>544
クロージャでカプセル化するとき、OO的な思考が入ってるはず。クラス的な手法じゃなく、ならともかく。
どちらもOOの実現方法にすぎんでしょ。

0549デフォルトの名無しさん

2011/12/04(日) 15:03:56.54

>>482
PostがResul返すかどうかはFactoryかどうかに本質的に関係ないだろ
そもそもResult以外返せばコンパイルエラーだ

俺の感覚では>>479はファクトリとは言わん。サブクラス切り替えて生成するインスタンスを変えてるんじゃないっしょ

0550デフォルトの名無しさん

2011/12/04(日) 15:04:35.72

>>548
クラスがあるから、C++は、C#の思想が入ってるといってるのと同じ。
視点がおかしい。

0551デフォルトの名無しさん

2011/12/04(日) 15:10:00.83

>>550
んーそうかー？
クロージャでカプセル化するんなら、何かを隠蔽して、それを何かで公開してるんだよな？
それをOO的な思考で実装しないことが出来るとでも？っ・・・ってできるかorz

まーでも、普通そーいう雑な設計はしないっしょ。何がしたくてカプセル化なのか謎すぎだから。

0552デフォルトの名無しさん

2011/12/04(日) 15:11:48.84

>>534
その二つなら寧ろProxyに感激してほしいなあ

0553デフォルトの名無しさん

2011/12/04(日) 15:12:28.43

>>531 >>533
OOPの基礎的な部分は属性と操作を持ったものをオブジェクトとして
それらが相互に操作しあって自分の属性を更新することで
プログラムが動作すること。
その基礎をもとに発展させた方法論のうちで代表的なものが
クラスベースの方法なんで、狭義なそれを暗黙にOOPと呼ぶ人も居る。

0554デフォルトの名無しさん

2011/12/04(日) 15:24:32.10

>>468
拡張に対して開きつつ修正に対して閉じてないと失格ですよ

0555デフォルトの名無しさん

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 );

0556デフォルトの名無しさん

2011/12/04(日) 15:31:58.08

>>551
肝心なトコが抜けてる。日本語的な意味でおかしいと言ってんの。
OOがクロージャを、クロージャがOOを含んでるんじゃなく、
カプセル化を、OOとクロージャが含んでんの。だから視点がおかしいといってる。

0557555

2011/12/04(日) 15:33:55.87

あ。alphaがαになっとる。

0558デフォルトの名無しさん

2011/12/04(日) 15:36:27.06

紛らわしいこと書いたな。

>ArgumentとOptionAlphaとかの親となる、Optionを書き換える必要は金輪際無い。
訂正： OptionAlphaとかの親となるOptionと、Argumentを書き換える必要は金輪際無い。

0559デフォルトの名無しさん

2011/12/04(日) 15:37:25.58

>>553
＞自分の属性を更新

ここの出典をプリーズ

0560デフォルトの名無しさん

2011/12/04(日) 15:39:49.19

>>556
興味深いので拘ってみたいんだけど

＞カプセル化を、OOとクロージャが含んでんの。

は同意だけど(個人的には含んでるってよりインプリしてるの方がしっくりくるけど)
単独の関係を検証してるならそれでいいけど、先の話はそれとは別でしょ。
先の話題は、クロージャでカプセル化を実現、した時の話だから、
それをOO視点無しでする設計って現実にあるの？ってこと。

0561デフォルトの名無しさん

2011/12/04(日) 15:42:35.00

Adapterパターンって元々のクラス設計者の設計間違いを利用者が尻拭いしてるだけみたいに見えるんだけど
これがはじめから有効な場合ってどういう場面なんだろう

もしくはDuckTypeで動く言語ならかなりの場合不要なような気がする

0562デフォルトの名無しさん

2011/12/04(日) 15:44:31.52

>>560
逆に、クロージャ的視点なしでオブジェクト設計する事があるの？と言える。
そもそも、クロージャは3番目にできた言語であるLispで実装されたもの。
どちらかと言えば、クロージャの設計思想をOOがうけてるって言ったほうが正しい。
smalltalkのブロックだって、無名関数がベースだしな。

0563デフォルトの名無しさん

2011/12/04(日) 15:45:55.99

>>561
イベントドリブン。
転送機構の代用品になる。

0564デフォルトの名無しさん

2011/12/04(日) 15:46:31.68

>>561
尻拭いの感覚でだあたいあってる。
新インタフェースをAdapteeに旧インタフェースAdapterに使うのがデフォだから。
設計間違いと言えるかはケースバイケース。仕様変更だつ

0565デフォルトの名無しさん

2011/12/04(日) 15:49:07.26

仕様変更だったり、要件定義漏れだったりもするし
最初から使うのは、既存ライブラリをこちらの自持ちAPI都合で都合よく再利用する場合とか

0566デフォルトの名無しさん

2011/12/04(日) 15:51:11.15

>>561
ダックタイプじゃ代用にはならんよ。
異なるオブジェクトから同じイベントで1つの名前のメソッドを呼ばれたら、
どのみち、イベント元を区別できないし。

0567デフォルトの名無しさん

2011/12/04(日) 15:53:59.14

>>562
あると思うけど、どうかな？
クロージャ言ったらレキシカルスコーブっしょ。プロトタイプベースのOOでない、クラスベースのOOにその視点は登場しないと思われる。
そもOOなJavaにはクロージャないし。

0568デフォルトの名無しさん

2011/12/04(日) 15:54:38.78

>>564
キーを2つ取るマップとキーを1つ取るマップの橋渡しとか、
独立性と柔軟性を上げてる訳で、別に尻拭いがメインじゃないだろ。

0569デフォルトの名無しさん

2011/12/04(日) 15:54:59.70

>>559
ごめん。勢い余った。
そこは取り下げるからスルーお願いします。

0570デフォルトの名無しさん

2011/12/04(日) 15:56:59.84

>>567
まず、smalltalkなんかは、メソッド自体が一つのクロージャ。
それから、OOで言えば、オブジェクト自体がある種のクロージャであり、
オブジェクトのメソッドが、コンストラクターと、実行メソッドだけであれば、
無名関数と同様の動作になる。

0571デフォルトの名無しさん

2011/12/04(日) 16:00:47.94

>>566
完全な代用にはならないけどかなり多くの場合ダックタイプで救えない？

あるいは言い換えると、ダックタイピングのような機能を持っていない言語は
仕様変更や要件定義漏れに弱いために、デザインパターンという
いわゆる逃げを使わなきゃいけない、といえるのかも

0572デフォルトの名無しさん

2011/12/04(日) 16:02:55.05

>>570
んー
クロージャの定義をどのあたりにしてるか教えて貰えるかい？
ちょっと広義にしすぎてて、実はそのクロージャと呼んでるのクロージャでない別の何かだったりしないかな？

個人的には、クロージャではコンテキストって概念が鍵になると思ってるから、OOなオブジェクトってだけでは、背後にクロージャという概念が隠れてるとは感じられないんだけど

0573デフォルトの名無しさん

2011/12/04(日) 16:06:02.72

無名関数は語弊があった、高階関数ね。

>>572
多数の言語でクロージャと言われてるものの最大公約数。
基本的には、Lispのラムダ、Smalltalkのブロック、BCBで使えた__closure。

0574デフォルトの名無しさん

2011/12/04(日) 16:09:13.35

>>570
smalltalk は知らないけれど、クロージャはそこでのコンテキストに束縛されるところがキモでは。
まあ、OO でもオブジェクトが使う全てを環境としてコンストラクタに渡す、
というような仕掛けで模倣することはもちろん可能だと思うが。

とはいえ、それを明示的にやったら最早クロージャとは言わないと思われ。
# lambda lifting を手でやってるだけ

0575デフォルトの名無しさん

2011/12/04(日) 16:11:19.45

Smalltalkのブロック式はSchemeのクロージャと同様
レキシカルな文脈で環境を補足するよ

0576デフォルトの名無しさん

2011/12/04(日) 16:13:30.92

>>575
ブロック式がオブジェクトなの？

0577デフォルトの名無しさん

2011/12/04(日) 16:17:07.42

>>566
異なるオブジェクトからあるオブジェクトの同じメソッドを呼び出して、
そのメソッド内で呼び出し元を区別したいっていうの？
それ、ObserverパターンかVisitorパターンと混乱してない？

0578デフォルトの名無しさん

2011/12/04(日) 16:17:11.94

>>563 >>566
がわからんのだが、Adapterとイベントドリブンって何か関係あったっけ？

0579デフォルトの名無しさん

2011/12/04(日) 16:20:19.54

>>568
良い指摘㌧

0580デフォルトの名無しさん

2011/12/04(日) 16:20:21.52

>>576
BlockContextクラスのインスタンス

0581デフォルトの名無しさん

2011/12/04(日) 16:24:40.88

>>580
他のクラスはインスタンス化のタイミングで環境を補足しないの？
BlockContextクラスだけ特別扱いになっている？
しっくりこない。

0582デフォルトの名無しさん

2011/12/04(日) 16:31:04.75

環境捕捉はインスタンス化のタイミングってより関数定義のタイミングなんじゃないかな？
まー、Smalltalkerでない俺は話題についてけてないんだけど

0583デフォルトの名無しさん

2011/12/04(日) 16:32:11.30

デザパタ・オブジェ厨はすぐに孤立するな。優秀なんだが。

0584デフォルトの名無しさん

2011/12/04(日) 16:34:50.29

よくわからんけど、スタックフレームへのポインタをフィールドに持っている、
みたいな感じ？うーむ・・・
これはオブジェクト指向とは関係なく、Smalltalk でクロージャを実現するための言語機能とみるべきじゃないの？

0585デフォルトの名無しさん

2011/12/04(日) 16:35:58.87

かなり話が広がってきたけど >>501のメリットというのは、オブジェクト指向のメリットではなくポリモーフィズムのメリットということであってる？

それでオブジェクト指向とは何？
という話は >>553
でそのメリットはなんなんだろう？

0586デフォルトの名無しさん

2011/12/04(日) 16:36:46.13

>>571
Adapterパターンって元のメソッドのシグニチャを変えたいって話だと思うから、
ダックタイプがそもそも結びつかない気がするんだけど

0587デフォルトの名無しさん

2011/12/04(日) 16:41:59.71

>>585
>>501は実装と使用という全く別概念を同義に使ってしまうあたり
言葉の使い分けが微妙なので
引用して議論すると混乱の種になるぞ

0588デフォルトの名無しさん

2011/12/04(日) 16:42:02.27

>>585
オブジェクト指向とは、
クラスや継承やポリモーフィズムを総称した呼び方。

ポリモーフィズムのメリット＝オブジェクト指向のメリット

0589デフォルトの名無しさん

2011/12/04(日) 16:45:50.80

オブジェクト指向のメリット
＝カプセル化のメリット
＋インヘリタンスのメリット
＋ポリモーフィズムのメリット
＋ダイナミックバインディングのメリット

一つ一つは他のパラダイムでも実現できるけど
これらをバランスよく実現して普及したパラダイムがオブジェクト指向だった。

では駄目なの？

0590デフォルトの名無しさん

2011/12/04(日) 16:49:17.98

レイトバインディングやポリモフィックな言語機構ってOOなら必ず持つんだっけ？

0591デフォルトの名無しさん

2011/12/04(日) 16:53:51.43

言語設計者がこれはOOPLだって言ったらOOPL

0592デフォルトの名無しさん

2011/12/04(日) 16:54:45.33

オブジェクト指向のこんな理解の仕方があったり

http://kmaebashi.com/programmer/object/intro.html

0593デフォルトの名無しさん

2011/12/04(日) 16:58:08.49

int a = 1;
int b = 2;

マルチプルインスタンス！

0594デフォルトの名無しさん

2011/12/04(日) 17:06:47.18

>>591
つまり規範的な概念ではなく記述的な概念ってことか
ファウラー風に言えば

0595デフォルトの名無しさん

2011/12/04(日) 17:23:11.21

>>586
ダックタイピングが利用できると、そのシグネチャを変えなくても
あとから利用側が同じシグネチャに合わせることができる場面が多いっていう
意味じゃない？

0596デフォルトの名無しさん

2011/12/04(日) 17:27:51.25

Adapteeのシグニチャが既に固定なんだから、ダックタイプじゃ切り抜けられないっしょ。
ガーと鳴かない状況でガーいわせるんだから。そこでガー言わせるIFミスマッチ埋めがAdapterなんだから。

0597デフォルトの名無しさん

2011/12/04(日) 17:36:57.77

>>588
総称はないな。そもそもクラスベースじゃないOOもあるし。

0598デフォルトの名無しさん

2011/12/04(日) 17:41:55.48

その程度の反論には、
クラスベースまたはプロトタイプベースって
言い換えるだけだよ。

0599デフォルトの名無しさん

2011/12/04(日) 17:42:26.07

「OOっぽいもの」と「よりOOっぽいもの」があるだけで定義付けは不毛

0600デフォルトの名無しさん

2011/12/04(日) 17:44:35.24

総称と呼ぶのが不適切だ、という点が肝要なんだが

0601デフォルトの名無しさん

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);
}
}

0602デフォルトの名無しさん

2011/12/04(日) 19:26:20.03

自分が作成しているクラスのインターフェースが変更不可って場合はダックタイプでも救えないってわけね。

0603デフォルトの名無しさん

2011/12/04(日) 19:30:53.02

継承がなくて委譲だけをひたすら使う場合でもオブジェクト指向って言うんじゃねえ？
とすると

オブジェクト指向 = (クラス | プロトタイプ) and (継承 | 委譲) ans 多態性の総称

すっげぇ定義しづらい・・・

0604デフォルトの名無しさん

2011/12/04(日) 19:39:35.17

>>408
シッタカはやめとけｗ
例えばsingletonなんて、Smalltalkで使われていた頃はsingletonとは呼ばれていなかったぞｗ

0605デフォルトの名無しさん

2011/12/04(日) 19:40:35.31

なんてよばれてたの？

0606デフォルトの名無しさん

2011/12/04(日) 19:49:38.03

sole instance

0607デフォルトの名無しさん

2011/12/04(日) 20:09:33.66

sole insntanceはあるクラスのインスタンスが
一つしか存在しないということを指す言葉。
たとえばTrueクラスのインスタンスはtrueのみ。

Singletonはあるクラスのインスタンスを
一つに制限するときに使うパターン（コード・設計）。

あるクラスをsole insntanceにするときに使うのが
Singletonパターン。こういう使い方をする。

Singletonとsole insntanceは別物

0608デフォルトの名無しさん

2011/12/04(日) 21:16:28.61

>>601
> っていう話だよね
違う
ソースが提供されているかどうかは全く関係ない

0609デフォルトの名無しさん

2011/12/04(日) 21:27:36.46

>>608
ソースが提供されていたら、自分のインターフェースに合わせて変更してしまえばいいんじゃないか
と思っちゃうんだけど違うのかな

提供されているクラスは充分にテストされているから、変更せずにそのまま利用したい
ということ？

0610デフォルトの名無しさん

2011/12/04(日) 21:29:12.84

動的型付け言語使いなんだろ？
インターフェースが変わるとコードもテストも
大量に修正が必要になる。
だから変えようと思っても変えられない。

リファクタリング機能が充実している
Javaでは信じられない発想。

0611デフォルトの名無しさん

2011/12/04(日) 22:15:38.03

例えばGUIアプリケーションのプレゼンテーションモデルとドメインモデルとの関係を
考えると分かりやすいと思う。
ドメインモデルを直接変更してしまうと、表示画面に特化した再利用性の低い
ものになってしまうので、アダプターパターンを適用する。

プレゼンテーションモデルというのはJavaのJComboBoxにおけるComboBoxModel
などのことで、アダプターパターンを用いることで、どんな形のクラスであってもソースの
修正なしにコンボボックスという形で表示することができる。

0612デフォルトの名無しさん

2011/12/04(日) 22:16:40.16

>>611は>>609宛です

0613デフォルトの名無しさん

2011/12/04(日) 22:40:21.43

>>610
Java使ってるのにソースの互換性を考えたことないのね

0614デフォルトの名無しさん

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);

0615デフォルトの名無しさん

2011/12/04(日) 22:48:05.84

間違った、こうね。
function StartAdapter( delegateTarget ) { return function( event ){ delegateTarget.start() } }
function StopAdapter( delegateTarget ) { return function( event ){ delegateTarget.stop() } }

0616デフォルトの名無しさん

2011/12/04(日) 23:17:54.07

>>589
仕組みで言っても仕方ないって。
OOPLってのは、OOの目的を達成を支援する事を標榜してるだけで、
目的のためなら、手段は色々なんだから。実装継承の無いOOPLもあるし、
javascriptみたいにカプセル化を持たない言語もある。多態性に関しては、
コアなんで、流石にサポートしない言語は無いけど。

OOは、そもそもSimulaのシミュレーションから着想を得て発展させたもの。

水分子や、酸素分子はそれぞれ別の振る舞いをする。
酸素の溶けた水中は、グラフ構造で表現するのが自然だが、
グラフのノードたる、水分子、酸素分子は別々の振る舞いをしてしまう。
これを上手く、自然に再現するには、既存の手法や言語ではどうしても不細工だった。
それをキレイに表現しようと発展したのがSimula。
更にこのノードをオブジェクトとして定義し、分子などをコンピュータ上のリソースに応用しようと
考えたのが、SmalltalkとC++であり、その考えがオブジェクト指向となっている。

なので、OO概念 = 異なるリソースのグラフ構造表現だ。
ノード単位での並列化を加えたものがアクターモデルと呼ばれていることからも、
概念は、はっきりしている。

OOPLとは、あくまでこの「異なるリソースのグラフ構造表現」をどれだけ楽に実装できるかを
目指した言語であるだけで、別にどの機能を持っているからOOPLという話ではない。

0617デフォルトの名無しさん

2011/12/04(日) 23:20:54.93

>>616
読むのだるいんで、下らない喩え話を省いて。

0618デフォルトの名無しさん

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つの名前のメソッドじゃないから、違ってる気がする。

0619デフォルトの名無しさん

2011/12/04(日) 23:47:09.77

>>614は俺も分からんな

0620デフォルトの名無しさん

2011/12/04(日) 23:47:18.66

>>617
OOPLとは、あくまでこの「異なるリソースのグラフ構造表現」をどれだけ楽に実装できるかを
目指した言語であるだけで、別にどの機能を持っているからOOPLという話ではない。

0621デフォルトの名無しさん

2011/12/04(日) 23:48:50.87

>>618
>buttonA.addEventListener("click", mainLogic.start, false);
これができる言語なんて無いでしょ。デリゲートなり無名関数をアダプターとして挟まない限り無理。

0622デフォルトの名無しさん

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を切り離せなくなるんで、現実的じゃない。

0623デフォルトの名無しさん

2011/12/05(月) 00:21:57.04

>>620
2ch の長文はオレオレ理論なのか根拠のある話なのか判別が付きにくいから
原典へのリンクも張って。

0624デフォルトの名無しさん

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

「異なるリソース(複数のコンピューターとか)のグラフ構造表現」とまではっきり書いてないが、
要約すると、そういう事を書いてある。基礎概念が、コンピューターネットワークが
細胞間のメッセージングと同じように考えられるとか、ニューロンネットワークとか、
通信網のシミュレーションは、アルゴルのような従来の言語ではやりづらかったとかね。

0625デフォルトの名無しさん

2011/12/05(月) 01:57:24.77

>>615
StartAdapterとその中身の無名関数とで冗長
あと大文字で始めるのやめれ、見づらい

0626デフォルトの名無しさん

2011/12/05(月) 02:18:25.48

>>625
別に冗長ではないだろ
これは、あくまで例だが実際には、
mainLogic以外のオブジェクトも渡す理由だから
無名関数だったら毎回function(event){・・・.start()}って
かかないといけないじゃん

0627デフォルトの名無しさん

2011/12/05(月) 02:39:22.01

buttonA.addEventListener("click", function(){ mainLogic.start() });

でいーじゃん

0628デフォルトの名無しさん

2011/12/05(月) 02:44:49.51

コミュ症かー

0629デフォルトの名無しさん

2011/12/05(月) 02:49:05.79

レキシカルスコープなのに、わざわざ関数作って冗長にする意味ないっしょ
分かりやすさがダンチ

0630デフォルトの名無しさん

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) });

ってだけで済むところを。どんなメリット求めてパターン使ってるの？っていう

0631デフォルトの名無しさん

2011/12/05(月) 03:02:53.59

>>614は中途半端に知識を持ったために、かえって悪くなる典型みたいなコード
>>72の通りだな

0632デフォルトの名無しさん

2011/12/05(月) 03:06:18.84

イベントハンドラが実はアダプタ使ってるって指摘は面白かったと思う

0633デフォルトの名無しさん

2011/12/05(月) 03:18:52.18

>>614はJavaScriptじゃなくJavaで書けば良かったのに

0634デフォルトの名無しさん

2011/12/05(月) 03:24:26.32

>>616
数学は天文学だとか言うのと同じ程度に眉唾なんだが
発展経緯を知ることは意味があるけど、それがイコール定義ではないでしょ

0635デフォルトの名無しさん

2011/12/05(月) 03:38:19.77

>>630
startが変化しなけりゃ引数増やす必要ないだろ。
そもそもstartがイベントを受け取る事を前提にしてるなら、
引数が増えたりすることがおかしい。あくまでイベントを別のメソッドで
受け取るためにアダプター噛ましてるだけなんだから。

それはともかくとして、関数に名前付けてんのは、
無名関数を作れない環境でも同じだという事を強調した。
無名関数単品でも他のオブジェクトのメソッド呼ぶだけならアダプターではある。

それはともかく、ダックタイピングが使える環境だろうと、無名関数を作れない
環境だろうと、アダプターをイベントで使うというのがわかればいい。
Javascriptでどれだけキレイに書けるか、Javascriptのセオリーに
従うならどうかなんては問題にしてない。

0636デフォルトの名無しさん

2011/12/05(月) 04:02:54.16

>>635
引数が増えたりするのは少しもおかしくない
Textで設定値を指定するとか、普通にある

そもそもTargetインターフェースが固定なんだから、Adapteeは可変が前提でしょ。そこ否定してどーすんのさ

おまけ。
問題にしてないと言うなら、主題に沿わないコード断片を書き散らすのやめれ
フォーカスがブレたのなら、それは焦点を絞らなかった書き手の問題だよ。

0637デフォルトの名無しさん

2011/12/05(月) 06:12:22.51

>>607
違うよ。
つーか、クラスをsole instanceにするとか、用法がメチャクチャだぞｗ

１つのクラスのインスタンスが１つしかない状況を仮定して、
そのインスタンスを指す言葉がsole instanceで、
そのクラスを指す言葉がsingletonだ。

Smalltalkではinstanceに注目してsole instanceと呼んでいたが、
GoFではよりクラス寄りになったJava等にあわせてsingletonと呼ぶことにした。

0638デフォルトの名無しさん

2011/12/05(月) 06:16:12.50

>>614がよくわからないんだけど、誰かJavaで頼む
StartAdapterって何するメソッドなの？

0639デフォルトの名無しさん

2011/12/05(月) 06:22:41.87

>>616
構造が目的なのではなくて、相互作用が目的じゃないのか？
グラフ構造というよりも、異なる単位間の相互作用、のほうがしっくりくる。

で、流派的には
ケイが動的で柔軟な相互作用を追求し、
ストラウストラップは効率的な相互作用を指向して、
メイヤーは各単位の拡張性/整合性に注目した。

0640デフォルトの名無しさん

2011/12/05(月) 07:07:44.20

>>634
>>624以上のソースを出せと言われたら
もう、ISO/IEC 2382-15しか無いんだがな。
知りたいなら高い金だして買ってくれ。

0641デフォルトの名無しさん

2011/12/05(月) 07:17:19.29

>>636
無いな
C#使ってて、イベントを受け取るために使った場合の
Delegateは、イベントが発行する以上の引数を持たせる事はできないし
テストのために、追加の引数を渡せるように
Delegateオブジェクトを拡張したなんて聞いたことがない

0642デフォルトの名無しさん

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で書くとこんな感じか。

0643デフォルトの名無しさん

2011/12/05(月) 07:43:33.94

>>634
じゃあ訊くけどさ、数学の定義を示してくれたまえ。
その上で、その定義とやらが義務教育を受けた一般人にとって
どれだけ眉唾なものか議論しようじゃないか。

0644デフォルトの名無しさん

2011/12/05(月) 07:51:47.10

関数がファーストクラスのオブジェクトじゃない、
ラムダすら無いうんこな言語で使うパターンですね

0645デフォルトの名無しさん

2011/12/05(月) 08:01:44.78

Javaでデザパタ学んだ奴って他言語でも
冗長なコード書くよな
まさにデザパタの弊害って感じ

0646デフォルトの名無しさん

2011/12/05(月) 08:15:32.26

ボタンを押された時に実行する処理が、特定のロジックを起動するだけという場合でも、
イベントリスナとして登録するためには、イベントを受け取る関数の形に合わせる必要がある。

これは、ロジック側のインタフェースをイベントリスナとして要求されるインタフェースに
変換しているという見方もできて、その見方をするならば、
そこで作成されるイベントリスナオブジェクトはアダプタパターンを使っているとも言える。

という理解でいいのかな？
確かにそういう考え方をしたことはなかった。>>632 同意。

0647デフォルトの名無しさん

2011/12/05(月) 08:22:39.04

>>642
ありがとうよくわかった
ListenerはAdapterパターンが使われているよという主張なのか

0648デフォルトの名無しさん

2011/12/05(月) 08:36:01.22

そんな当たり前なことで大絶賛とはｗ

0649デフォルトの名無しさん

2011/12/05(月) 09:15:31.67

ついでに質問なんだけど、Listenerってどの単位でクラス分割すればいいの？

ボタンごとに完全にクラス分けるのか、ある程度は画面ごとにListenerをまとめて押されたボタンを取得してif文で処理分けるのか

理想を言えば前者がいいんだろうけど、クラスすごく増えるんだよね

0650デフォルトの名無しさん

2011/12/05(月) 09:24:05.72

>>641
Adaterが話題になってるのに、またズレたレスをしたもんだな

0651デフォルトの名無しさん

2011/12/05(月) 09:24:19.17

>>648
誰も大絶賛してないと思うけど
そもそもそれがAdapterと納得している人はいない気がする

0652デフォルトの名無しさん

2011/12/05(月) 09:26:43.89

>>645
おまえやおまえの周りがそうだからといって
勝手に一般化するなよ
世界はお前が認識してるより広いんだ

0653デフォルトの名無しさん

2011/12/05(月) 09:30:03.43

>>643
脱線は一人でやってくれたまへ
コンピュータサイエンスの目的は軍事だという話題もあるぞ

0654デフォルトの名無しさん

2011/12/05(月) 10:42:44.42

逃げたｗ

0655デフォルトの名無しさん

2011/12/05(月) 13:08:57.91

>>635
こういうのもAdapterパターンと呼ぶってこと？
まあ別に良いけど

map(lambda x: x + 1, range(1,10))

0656デフォルトの名無しさん

2011/12/05(月) 19:18:51.32

おまえ、「おまえ頭おかしいな」とよく言われないか？

0657デフォルトの名無しさん

2011/12/05(月) 19:39:14.35

>>655
lambdaにより、処理を差し替えれる事から、Strategyになるんじゃない？

もしくは、double-dispatchなしの簡易版Visitor (イディオムとして名前がついていたような記憶があるが思い出せない)

0658デフォルトの名無しさん

2011/12/05(月) 19:43:05.44

ドカタSEじゃその程度かｗ

0659デフォルトの名無しさん

2011/12/05(月) 19:46:24.81

芝生やした単文野郎はなんなんだ

0660デフォルトの名無しさん

2011/12/05(月) 20:06:23.40

>>647
解ってるかもしれないけど、
Listener = Adapterじゃないからね。
Listenerの中で、複数のオブジェクトや
制御構文を並べて複雑な処理をしてたら、
もはやAdapter(適応)パターンじゃない。

あくまでも、イベントを他のオブジェクトに渡すだけの
最低限の実装で有るべき。Adapterの中で、文字列から
数値型に変えて引き渡したり、ファイル型に変えて
引き渡すぐらいはいいけどね。

0661デフォルトの名無しさん

2011/12/05(月) 20:13:46.38

やっぱり無名関数を使わず、Targetインターフェースに名前が付いてる場合だけを
Adapterと呼ぶんじゃないか？

0662デフォルトの名無しさん

2011/12/05(月) 20:22:27.57

コード書けないドカタSEが言葉を弄んでいるだけ

0663デフォルトの名無しさん

2011/12/05(月) 20:25:20.75

>>657
lambdaの中で+（__add__メソッド）を呼ぶだけだから、>>635の定義
> 無名関数単品でも他のオブジェクトのメソッド呼ぶだけならアダプターではある。
ならアダプタパターンってことになるな

まあ、>>662の言う通りだと思うわ。言葉遊びっつーか馬鹿みたい

0664デフォルトの名無しさん

2011/12/05(月) 20:39:49.98

今はAdapterパターンばかり槍玉に上がってるけど、
StrategyやらCommandやらVisitorやら、他にもインターフェースを駆使して動的な性質を取り入れようとしているパターンには
動的型付けとかクロージャとかミックスインで代替できるものがいっぱいあると思うよ
モダンな言語はデザパタに頼らずに、よりスマートでソースコードの見通しがいい方法で解決すべき。

0665デフォルトの名無しさん

2011/12/05(月) 20:46:38.00

さて>>561に戻るか。
Adapterパターンは、結局ダックタイピングできる言語だろうと、
高階関数つかえる言語だろうと、無意識かもしれんが、使う人は使ってる。
尻拭い以外に使ってることも多いんだよ。

0666デフォルトの名無しさん

2011/12/05(月) 21:11:06.69

>>664
転送と高階関数で、見かけは存在しないように見せかけられる。
本質的にゃ変わりゃしない。

0667デフォルトの名無しさん

2011/12/05(月) 21:13:08.65

高級言語はその見かけが大事なんじゃねーか

0668デフォルトの名無しさん

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を同一視してる発言

0669デフォルトの名無しさん

2011/12/05(月) 21:26:17.89

>>668
なんでAdapterなのに継承してんの？
Adapterが別のクラスにくっついてちゃいかんだろ。
>>660にも書いたが、あくまでAdapterは、
別のオブジェクトのメソッドに受け渡すだけ。

Listener = Adapterでは無いが、Listenerに
Adapterを使うこと自体は問題ない。

0670デフォルトの名無しさん

2011/12/05(月) 21:30:05.97

>>668
Listenerは、別にAdapterじゃなくてもいい
ただListenerとしてAdapterが使えるってだけの話だろ

0671デフォルトの名無しさん

2011/12/05(月) 21:32:49.04

>>668
なんでモデルでもないのにAdapteeModel?

0672デフォルトの名無しさん

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クラスの中身はなんでもいい

0673デフォルトの名無しさん

2011/12/05(月) 21:40:11.63

>>672
ほれ
http://en.wikipedia.org/wiki/Adapter_pattern

0674デフォルトの名無しさん

2011/12/05(月) 21:41:45.98

>>672
モデルつってんのに、メンバーもなけりゃ
ブロードキャスト機構が付いてないから、
アレなのかなとおもってさ

0675デフォルトの名無しさん

2011/12/05(月) 21:45:45.04

>>672
日本語版じゃさも、委譲型が特別形態の様に書かれてるけど、
GoF本や、海外の資料だと、委譲してるのがデフォ。
継承型の方が特殊なんだけど。

0676デフォルトの名無しさん

2011/12/05(月) 21:50:22.93

日本語版Wikipediaなんて技術関連はいい加減だからなぁ
殆どアニオタの巣窟なんだっけ

0677デフォルトの名無しさん

2011/12/05(月) 21:51:38.59

いい加減と思った人が書きなおさないから悪いのでは？
自分の責任だと思いなよ。

0678デフォルトの名無しさん

2011/12/05(月) 21:52:37.27

>>672
http://www.oodesign.com/
こういうちゃんとしたサイトで勉強したら？

0679デフォルトの名無しさん

2011/12/05(月) 21:54:37.96

>>677
なんで情弱御用達Wikipediaの面倒なんか見なきゃならんのよ。

0680デフォルトの名無しさん

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);
　}
}

0681デフォルトの名無しさん

2011/12/05(月) 21:58:14.68

ム板で日本語版Wikipediaからしかソース持ってこれないってのもなあ

0682デフォルトの名無しさん

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読んでくれとしか言えないｗ

0683デフォルトの名無しさん

2011/12/05(月) 22:01:58.84

>>680
Javaで、しかもgetXxxxx使ってんだから
せめてjava.beans.PropertyChangeSupportと
java.beans.PropertyChangeListenerぐらいは使おうよ。

0684デフォルトの名無しさん

2011/12/05(月) 22:06:58.62

>>682
ListenerをAdapterで実装したとき、
Model自体をAdapterが使用する必要ないでしょ。

class Model implements Runnable{}
new RunAdapter( (Runnable)new Model() );
例としては変だけど、Adapterとしての用途なら別にこれでいいわけじゃん。

0685デフォルトの名無しさん

2011/12/05(月) 22:13:52.92

Example instance = new Example();
Adapter DelegateAdapter = new Adapter(instance.Method);
DelegateAdapter( 10 );

.net環境は楽だなぁ

0686デフォルトの名無しさん

2011/12/05(月) 22:22:10.60

>>683
そうですね

>>684
もちろんそれみたいなListener=Clientの状況なら問題ない
Listener=Adapterはおかしいと主張してる

0687デフォルトの名無しさん

2011/12/05(月) 22:25:31.47

Listener=Adapterじゃないのは同意してるって。
Listener = { Adapter pattern, Other pattern, ... }
にできるっていう意味で書いてんじゃん。
なんで引きずってんの？

0688デフォルトの名無しさん

2011/12/05(月) 22:30:02.26

別にリスナーをコントローラーで実装しようが、アダプターで実装しようがどうでもいいじゃん

0689デフォルトの名無しさん

2011/12/05(月) 22:34:03.85

>>667
これにつきるな。ソースコードは設計書であるべきだから本質的でないものが混ざるとストレスたまる。
デザパタはその見通しを悪くするものが多いから、本当に必要なとき以外は極力排除したい。

TemplateMethodみたいに見通しよくするものもあるけど。

0690デフォルトの名無しさん

2011/12/05(月) 22:39:08.17

>Listener = { Adapter pattern, Other pattern, ... }
俺はこれを否定してるつもりなんだけど
ListenerのどこにどうAdapterパターンを使うんだ
Observerパターンは使ってるけど

>>688
どうしてコントローラーとアダプターパターンが同列なんだ
どうやってリスナーをアダプターで実装するんだ

もう俺だけ理解してない気がしてきた
誰か教えてくれ

0691デフォルトの名無しさん

2011/12/05(月) 22:39:39.69

>>689
TemplateMethodの見通しが良いかは分からないけど、上二行に関しては同意

ていうか頼むから>>614や>>642のようなアホコードは書かないで欲しいもんだね

0692デフォルトの名無しさん

2011/12/05(月) 22:39:48.63

デザパタは構造。見た目は別。
C#でもできるし、GObjectを使ったCでもできるし、Lispでもできる。
アルゴリズムが言語に依存しないのとおんなじ。

0693デフォルトの名無しさん

2011/12/05(月) 22:40:09.16

デザパタは見通しを悪くするというのは、
単にお前が、設計の基礎知識を知らんだけではないのか？

設計図を読めない人は、設計図をみたらよくわからんと言うだろう。
それと同じだ。

0694デフォルトの名無しさん

2011/12/05(月) 22:43:20.02

>>690
リスナーはオブザーバーパターンから見た立場
アダプターは、委譲される側から見た立場
直交できる関係であって排他的なもんじゃないでしょ

0695デフォルトの名無しさん

2011/12/05(月) 22:45:21.24

>>693
本当に必要なときに使うのは誰も否定してないんじゃないの？

0696デフォルトの名無しさん

2011/12/05(月) 22:45:44.95

>>691
例としてわざとそう書いてるのに空気読めないねぇ。

0697デフォルトの名無しさん

2011/12/05(月) 22:46:01.69

printfは書式が複雑で見通しが悪いと言っているようなもんだよな。

なぜそうなっているのかその理由と目的を聞いて、
じゃあお前はこの目的をどうやって達成する？と聞いたら
一番いい方法がデザパタと同じコードにになるだろう。

0698デフォルトの名無しさん

2011/12/05(月) 22:46:40.31

>>695
あんたは、見た目とデザパタを同一視してるだろ。
そこが解ってないと言われてんの。

0699デフォルトの名無しさん

2011/12/05(月) 22:46:43.34

>>695
だから、本当に必要なときを前提にして
話をしてるんでしょｗ

0700デフォルトの名無しさん

2011/12/05(月) 22:47:06.50

>>696
例として不適切なのが相変わらず理解できないのね

0701デフォルトの名無しさん

2011/12/05(月) 22:47:48.59

>>700
なぜ例として不適切なのか？

いちいちストーリを作らないといかんのか？

0702デフォルトの名無しさん

2011/12/05(月) 22:47:53.41

>>699
必要もないのに使っている悪例がでてるじゃん

0703デフォルトの名無しさん

2011/12/05(月) 22:49:08.26

コード見たら、あぁこういう時に必要になるねって
分かるようなコードでも、実勢経験が少ない人には
なんでそんなものが必要になるのかわからないんだよ。

0704デフォルトの名無しさん

2011/12/05(月) 22:49:35.43

>>702
だから、これは必要なときという前提の話。

0705デフォルトの名無しさん

2011/12/05(月) 22:51:11.05

>>704
自分で何を言ってるのか分かってる？

0706デフォルトの名無しさん

2011/12/05(月) 22:51:54.71

>>703
むしろ実務経験の少ない人ほど無駄なパターンを多用する傾向があるかと

0707デフォルトの名無しさん

2011/12/05(月) 22:53:04.34

>>703
それはよくある話だね。

サーバーの話だけど俺は昔リバースプロキシがよくわからなかった。
そのまま繋げばいいのに、なんでそんなものを入れて複雑にするのか？と思った。
今では理由はわかるけど、経験少ないとわからんものだよ。

なんかの本に書いてあったけど、密結合な設計は悪い。
結合を疎にするには間にクッションを入れるみたいなこと。

デザパタもそうなってるんだよね。結合度を下げるために
間にクラスを入れてる。

その理由がわからない人は経験が足りないだけ。

0708デフォルトの名無しさん

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

0709デフォルトの名無しさん

2011/12/05(月) 22:54:57.25

>>707
そうだね
"本当に必要なときは"使った方がいいね

0710デフォルトの名無しさん

2011/12/05(月) 22:55:41.76

>>705
よく分かってるけど？

ここに書いている短い例ではいろいろ省略している
めんどうだからね。

本当は○○～というストーリーがあるんだけど、それを省略している。
このストーリーをちゃんと書けばデザインパターンはそういう目的の
ためにあるんだってわかるはず。

ただ、めんどくさいから書かないよ。経験あればこの程度のストーリーなんて
心当たりがあるはず。ない人がわからんと文句を言ってるだけ。

0711デフォルトの名無しさん

2011/12/05(月) 22:56:45.40

>>708
デザインパターンの本質は、実装ではなくて考え方なので、
その考え方さえ満たしていれば、いろんな実装がありえます。

0712デフォルトの名無しさん

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 );

言語が違おうが、パターンとしては同じって事が解らない人は辛いね

0713デフォルトの名無しさん

2011/12/05(月) 22:59:09.42

>>710
もういいよ
聞く耳を持たない人には無いを言っても無駄だからね

0714デフォルトの名無しさん

2011/12/05(月) 22:59:51.04

>>713
それで？

0715デフォルトの名無しさん

2011/12/05(月) 23:00:29.45

>>712
いわゆる一昔前の頑固親父だよな

0716デフォルトの名無しさん

2011/12/05(月) 23:02:32.96

>>714
もういいよって言ってるのにその返しは無くない？

0717デフォルトの名無しさん

2011/12/05(月) 23:03:18.27

言語とアルゴリズムとかの概念を切り離せない人って
どういう仕事してんだろ？接客とかはしたことなさそうだけど

0718デフォルトの名無しさん

2011/12/05(月) 23:04:31.98

>>716
そもそも「もういいよ」って返しがありえないだろｗ

ありえないものには、
ありえないもので返すしかありません。

0719デフォルトの名無しさん

2011/12/05(月) 23:06:10.53

>>718
お前ってものすごい自分ルールを持ってるね

普通はありえない返しだと思ったらありえないって言うだろｗ

0720デフォルトの名無しさん

2011/12/05(月) 23:06:34.62

>>719
それは、お前の自分ルールだ。

0721デフォルトの名無しさん

2011/12/05(月) 23:07:09.18

>>720
お互いここらで終わりにしようか？

0722デフォルトの名無しさん

2011/12/05(月) 23:08:17.19

>>721
どうぞ勝手に。俺も勝手にする。

0723デフォルトの名無しさん

2011/12/05(月) 23:08:41.41

今なんとなく解った気がする。
ヤツがいってるのはアレか、JavascriptじゃわざわざAdapterなんか使わずに、
面倒だから無名関数の中に直接処理を埋め込めといってたのか。多分・・・

0724デフォルトの名無しさん

2011/12/05(月) 23:09:47.05

無名関数かどうかは関係ないよ

0725デフォルトの名無しさん

2011/12/05(月) 23:10:45.70

function(){ instance.Method() }
じゃなく、
function(){ 処理ベタ書き }

こんな感じか

0726デフォルトの名無しさん

2011/12/05(月) 23:10:46.42

関係あるのは、直接処理を埋め込むってところだろｗ

0727デフォルトの名無しさん

2011/12/05(月) 23:13:37.29

>>725
確かに、それならAdapterパターンつかってないわな。
デザパタ減らしてる。

0728デフォルトの名無しさん

2011/12/05(月) 23:14:56.86

> function(){ instance.Method() }

引数無しなら instance.Method だけで良いんと違うん？

0729デフォルトの名無しさん

2011/12/05(月) 23:19:10.80

>>728 javascriptだとMethodの中のfunctionオブジェクトだけ代入する事になるのよ。
instanceとのヒモ付がなくなっちゃう。

0730デフォルトの名無しさん

2011/12/05(月) 23:21:56.94

>>728
instanceB.Method = instanceA.Method;
instanceB.Method();

これ動かしたら、instanceBとinstanceAどっちが参照されると思う?

0731728

2011/12/05(月) 23:27:09.79

>>729-730
Javascriptってそんな言語だったんだ。知らなかった。

0732デフォルトの名無しさん

2011/12/05(月) 23:32:13.69

javascriptでメソッド名大文字で始めるなよ気になるから
上のほうでも誰か指摘してただろ

0733デフォルトの名無しさん

2011/12/05(月) 23:34:36.71

デザパタの目的は結構だが、その実装のためだけに
新たにクラスやインターフェースを作るのは気に入らない
ソースコードの見通しが悪くなるから
（つーても、使う言語でそれ以外に実装方法が無いなら仕方ないが）

見た目は大事

0734デフォルトの名無しさん

2011/12/05(月) 23:36:40.15

クラス作るのも関数作るのも大差ないだろ。

0735デフォルトの名無しさん

2011/12/05(月) 23:36:58.70

みなさんスルーでおねがいします

0736デフォルトの名無しさん

2011/12/05(月) 23:39:24.59

>>734
往年の派遣土方は、テスト工数じゃなくて、
ステップ数で見積もらなきゃいけないから、
そういうとこが厳しいんだってさ。

オブジェクトで振る舞いの表現ってのも元請けが
理解できないから、なかなかさせてもらえないみたい。

0737デフォルトの名無しさん

2011/12/05(月) 23:46:08.52

一行のlambdaで済むところを
インターフェース + クラスで10行に膨らませて
大規模（笑）開発にしてるとこあるな
行数で評価されるからこれで良いんだってww
まさにドカタの発想w

0738デフォルトの名無しさん

2011/12/05(月) 23:47:22.85

デザインパターンに関してはひがやすをさんが次のように書いているが、これを読んでとても納得した
まさにこれ

http://d.hatena.ne.jp/higayasuo/20101126/1290766099
> きれいなソースコードをかけるようになるためにデザインパターンも知ってたほうがいいんじゃないのという人もいると思いますが、
> デザインパターンはきちんと学んだ上で、いったん軽く忘れたほうがいい。
>
> 軽く忘れるというのは、コードを書いているときに、そういえば、このパターンはデザインパターンのあれに似てるなぁと思い出せる
> くらいに忘れるということです。思い出せたらそれは使うようにしましょう。
>
> デザインパターンが常に頭に常駐している状態でコード書くと、無駄に複雑になっちゃうんだよね。
>
> デザインパターンは、ある程度複雑な問題をきれいに解くために考えれたものですが、もともと簡単なものに適用すると無駄に
> 複雑になってしまうためです。

0739デフォルトの名無しさん

2011/12/05(月) 23:47:49.09

>>736
派遣はそれに加えライブラリを作れないからな
常にスクラップビルドだから今度最利用するっていう発想はない

0740デフォルトの名無しさん

2011/12/05(月) 23:50:47.45

>>737
1つ名前付きの高階関数用意しときゃいいのに、
10回も20回もおんなじlambda書くんだもんな

0741デフォルトの名無しさん

2011/12/05(月) 23:54:05.95

>>740
さすがにそれは無理があるわ

0742デフォルトの名無しさん

2011/12/05(月) 23:54:23.47

>>740
高階関数の意味分かってる？

0743デフォルトの名無しさん

2011/12/06(火) 00:01:25.17

>>733 >>738
だからお前は言語機能とデザインパターンをいい加減切り離せ

0744デフォルトの名無しさん

2011/12/06(火) 00:10:03.14

>>743
何を言っているのか分からない
738は自分が読んで納得した意見を紹介しただけなんだけど
あと733は別人ですよ

0745デフォルトの名無しさん

2011/12/06(火) 00:14:10.14

>>743
切り離してるから、実装方法が選べるなら
簡潔な方を選択しろと言っているんだろ
>>614のようなアホコードを書かないためにもな

0746デフォルトの名無しさん

2011/12/06(火) 00:14:25.11

>>737
一行で済む内容を手書きで一行書くのも IDE に十行生成させるのも
手間はそれほど変わらない。別にどっちでもいいと思うようにならないか？

フィールドを 3, 4 個定義して getter/setter の生成をポチっとやった瞬間に
JavaDoc コメントも入れれば 100 行超える。Java での開発ってそういうもんだろ。

0747デフォルトの名無しさん

2011/12/06(火) 00:21:24.46

614が優れたコードだと思ってる人って614本人以外に一人でもいるの？

0748デフォルトの名無しさん

2011/12/06(火) 00:21:35.68

>デザインパターンは、ある程度複雑な問題をきれいに解くために考えれたものですが、もともと簡単なものに適用すると無駄に
>複雑になってしまうためです。

これは「デザインパターン」を「オブジェクト指向」に置き換えても成立すると思う。

0749デフォルトの名無しさん

2011/12/06(火) 00:23:57.38

>>747
説明としてはまともだと思うが？

0750デフォルトの名無しさん

2011/12/06(火) 00:26:19.32

>>745
無名関数が存在するか、無名クラスが存在するか、
Delegateの様なデザインパターンを予めサポートした機能が存在するか、
そんなもん全部言語による。このスレで言語依存の話をギャーギャー続けるな。

0751デフォルトの名無しさん

2011/12/06(火) 00:27:46.63

>>747
優れてるか知らないけど俺はまだ解りやすいとは思った

0752デフォルトの名無しさん

2011/12/06(火) 00:29:25.26

>>747
相変わらず言語機能に拘るのな

0753デフォルトの名無しさん

2011/12/06(火) 00:29:47.02

>>749
説明としては…

>>751
まだ分かりやすい…

煮え切らない回答だな

0754デフォルトの名無しさん

2011/12/06(火) 00:30:33.85

>>752
あなたはお呼びじゃないです

0755デフォルトの名無しさん

2011/12/06(火) 00:31:50.77

無名関数とメソッド呼び出しだけ書かれたら
何してんのかよく解からんがな

0756デフォルトの名無しさん

2011/12/06(火) 00:32:34.74

>>614 と >>627 のどちらが良いコードかなんて議論を始める人と仕事はしたくないな。
相手の言いたいことの本筋を掴めず、どうでもいい枝葉末節に拘って時間を無駄にするタイプだろ。

0757デフォルトの名無しさん

2011/12/06(火) 00:35:10.73

しょうもないアダプターだけで200レスぐらい食ってるもんな。
余計な事言わなきゃ15レスぐらいで終わりそうなのに。

0758デフォルトの名無しさん

2011/12/06(火) 00:35:41.88

>>614がその本筋を非常に掴みづらい、分かりづらいコードなのが問題なんだよな…
そういう時間を無駄にしないためにこそ、こんなコードは書いちゃいけない

0759デフォルトの名無しさん

2011/12/06(火) 00:37:43.92

馬鹿にはわからんというだけの話さ

0760デフォルトの名無しさん

2011/12/06(火) 00:38:00.69

>>758
え？掴みづらかったか？俺は分かり易いと思ったが。

delegateTarget.start() を EventListener の要求するインタフェースに適合させるという意味で
function( event ){ delegateTarget.start() } が Adapter だと言えるという話だろう。

どこが分かりにくいのか疑問。

0761デフォルトの名無しさん

2011/12/06(火) 00:42:10.34

>>758
お前だけおかしいんだから、そろそろ空気読んでうせろよ

0762デフォルトの名無しさん

2011/12/06(火) 00:47:46.89

StartAdapter 関数を定義するのが冗長かどうかなんて論点が出てきておかしくなったんだよ。

「どうでもいい枝葉末節に拘って時間を無駄にする」という実例。
>>614 は日曜だろ。現に 2 日も無駄にしてる。2 日無駄にしてまだ終わらない。

0763デフォルトの名無しさん

2011/12/06(火) 00:51:27.76

>>760
そうやって意図を説明をしないと分からない
実際、自分以外の何人かも分からないとコメントしてる

>>627は見たままで誰でもすぐに理解できる
念のため、無名関数かどうかは問題にしてないよ

>>761
残念だけど俺だけじゃないんだな
そっちはどうか分からないけど

0764デフォルトの名無しさん

2011/12/06(火) 00:51:29.96

そりゃシンプルにかけばObserver、Visitorパターンしか残らんような例を出せば
ツッコミも入るわい
まあ、いいかげん引っぱりすぎだが

0765デフォルトの名無しさん

2011/12/06(火) 00:51:39.09

2日たって一周してるしな(>>758)
ホント無駄

0766デフォルトの名無しさん

2011/12/06(火) 00:53:28.99

>>764
2日同じ議論やって、要点だけ抜けて末節だけになっとる。スゲェ・・・。

0767デフォルトの名無しさん

2011/12/06(火) 00:53:47.15

では>>614はアホコードということで終わりで

0768デフォルトの名無しさん

2011/12/06(火) 00:54:04.94

>>764　どうでもいいわ帰れ

0769デフォルトの名無しさん

2011/12/06(火) 00:55:32.48

>>767
お前いたら、他の人に解りやすい説明もできなくなる。
失せろ。

0770デフォルトの名無しさん

2011/12/06(火) 00:55:38.90

どうでもいいなおまえが帰れよｗ

0771デフォルトの名無しさん

2011/12/06(火) 00:57:09.06

>>769
お前が関わると誤った知識が広まるから、お前こそ失せろよ
こういう奴が一番有害だな

0772デフォルトの名無しさん

2011/12/06(火) 00:57:40.73

みなさんスルーの方向で

0773デフォルトの名無しさん

2011/12/06(火) 00:57:44.02

>>763
> >>627は見たままで誰でもすぐに理解できる
> 念のため、無名関数かどうかは問題にしてないよ

そうかな？俺と感覚が違うなあ。
「Listener のこういう使い方は Adapter パターンの適用と見ることができる」
という説明のための例だろ？

これは駄目だと思うんだ。
> function(){ mainLogic.start() }

function(event) { mainLogic.start() }

と書いてほしい。引数の event を抜いたら、
むしろ本来説明したいことは伝わりにくくなると思う。

0774デフォルトの名無しさん

2011/12/06(火) 00:59:27.61

>>773
そこは見てなかった
けど、それこそ枝葉の問題だ

0775デフォルトの名無しさん

2011/12/06(火) 01:00:12.93

AdapterをObserverかVisitorと混同してないか？
と>>566が>>577にツッコまれて、苦し紛れに出した例が>>614だからな
無理矢理Adapterをねじ込んだから不要/冗長なコードになってる

0776デフォルトの名無しさん

2011/12/06(火) 01:02:10.38

Listener の話題で event 引数を省略することが枝葉だと判断するところが、
感覚の違いだということで。

ああ、こういう話（枝葉か本筋か）に正解はないよ。君と俺との感覚の違い。
どっちが普通でどっちがオカシイかという議論は 2ch でやっても無駄だからやめよう。

0777デフォルトの名無しさん

2011/12/06(火) 01:03:56.40

やけになって粘着してるからもうほっといた方がいい
この手の輩は勝利宣言で終わらなかったら延々と貼りつく

0778デフォルトの名無しさん

2011/12/06(火) 01:04:10.56

まぁ614の（説明のための）例が良いか悪いかは別として
実際の開発ではこういった書き方はしない方が良いという意味ではみんな同意するんじゃないかな？

0779デフォルトの名無しさん

2011/12/06(火) 01:05:19.52

では 778 の勝利宣言で終わろう

0780デフォルトの名無しさん

2011/12/06(火) 01:07:12.34

むしろ無難に収めようかと思ったのに
なんでこれが勝利宣言になるの？

0781デフォルトの名無しさん

2011/12/06(火) 01:07:54.22

どうでもいいけど、無名関数の中でメソッド呼んだだけで
アダプターパターン使ったとか現実世界で言うなよ
話通じないしアホだと思われるぞ

0782デフォルトの名無しさん

2011/12/06(火) 01:08:50.55

さすがに614もそこまではしないだろう

0783デフォルトの名無しさん

2011/12/06(火) 01:09:53.67

>>775
button と listener の関係が Observer で
listener と delegateTarget の関係が Adapter だね
着目する場所の違い。Visitor はどこを混同するとそうなるのかわからん。

0784デフォルトの名無しさん

2011/12/06(火) 01:14:20.80

delegation すりゃなんでも adapter なのか？

0785デフォルトの名無しさん

2011/12/06(火) 01:15:43.96

委譲とか考えてない設計に処理を差し込みたいからAdapterパターンを使うのであって
最初から委譲するように作ってあるものに対してAdapterパターンという言葉を使うのはちょっと違うような

0786デフォルトの名無しさん

2011/12/06(火) 01:36:10.07

>>649
UIごとじゃなく機能単位で分けられるんじゃない？
例えば、画像編集ソフトで画像を保存する事を考える。
この時、保存は、ツールバーでする人もいれば、ショートカットキーでするひとも居る。

(ActionListener)new SaveControl( (FileModel)fileModel, (ByteModel)imageModel );
みたいな使い方が出来る保存用リスナー作ってツールバーとショートカット(メニュー)に
割り当ててあげれば、ツールバーとショートカットキー用に別々のクラスを書かなくて済むでしょ。

あと、(ByteModel)imageModel みたいな感じで、インターフェースで受け
取れるようにしてれば(ByteModel)soundModel みたいに
他のデータにも使えて、もう少しコードを書く量は減らせると思う。

0787デフォルトの名無しさん

2011/12/06(火) 01:39:22.62

>>784
デリゲートパターンてのはデザパタに無いからね。

0788デフォルトの名無しさん

2011/12/06(火) 01:42:54.58

>>782
デザパタは置いとても、無名関数をアダプターとして使ってるぐらい言うんじゃないか？

0789デフォルトの名無しさん

2011/12/06(火) 01:46:06.56

>>788
>>778=>>781=>>782 なんだから触れるなよ

0790デフォルトの名無しさん

2011/12/06(火) 06:15:46.76

>>694
違う

ViewとListenerあわせてObserverパターン
立場とか一切関係ない

ModelにAdapterを適用したいことはあるかもしれないから排他ではないがListenerとは関係ない

0791デフォルトの名無しさん

2011/12/06(火) 06:25:31.34

>>785
この発言でおかしいことがはっきりした

あなたの理論で言うと、委譲とか考えないで、後から処理を差し込むためにAdapterパターン使うはずなのに、結局委譲使ってるんだなw

そもそも後から処理を差し込むためにAdapterパターン使う訳じゃない

Adapterの意味は適合
非互換のインターフェースを適合するために用いるのがAdapterパターン

他の方法でも実装できるんだから、Adapterパターンの本質には委譲は関係ない
委譲はAdapterパターンの実装方法の1つに過ぎない

0792デフォルトの名無しさん

2011/12/06(火) 07:20:42.51

>>790
MVCで、ObserverにCommandを組み合わせる事はよくあるが、
デザインパターンというものは排他的か？

0793デフォルトの名無しさん

2011/12/06(火) 07:21:47.32

こんだけ引っ張れる話題提供できた614は満足だろうな
ところで静的型付けを持つ言語でクロージャを持つ言語って、そのクロージャの型はどう定義するものなんだろうな
引数の型や数によってそれぞれ別のシグネチャを持つようにデザインされてたら
変に縛りが強すぎて、再びデザパタの生まれ変わりみたようなものを導入することになりそう

0794デフォルトの名無しさん

2011/12/06(火) 07:45:20.30

？？？？？メソッドのシグネチャと同じだろ。何を気にしてるのか全然わからん

0795デフォルトの名無しさん

2011/12/06(火) 08:01:18.52

>>792
排他じゃないと書いてるだろ
何を読んでそのレスをしたんだ

0796デフォルトの名無しさん

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)という名前で使いたいから
リスナを作っているのか？明らかに違うだろ。

デザインパターンは、目的をもって使うもの。
クラス図が偶然に同じ形をしていたからといって、そのパターンを使っているとはいわない。

0797デフォルトの名無しさん

2011/12/06(火) 08:13:39.85

>>787
GOFパターンにはないけど、他のパターン本でみた気がする。ただの委譲にパターンとか大げさすぎる気もするけど。

0798デフォルトの名無しさん

2011/12/06(火) 08:21:21.56

>>796
同じ主張の人が現れて嬉しい
他にこれと同意見の人いないの？

0799デフォルトの名無しさん

2011/12/06(火) 10:21:50.96

いやｗ　俺は何度読んでも目が滑る。
>>796の意見は不思議と入ってこない。
反論か同意かしたかったが、どちらもできなかった。

0800デフォルトの名無しさん

2011/12/06(火) 13:16:05.39

同じ機能だけどシグニチャが違うメソッド間の
ギャップを埋めるのがAdapter
Timer#start と ActionListener#actionPerformed は同じ機能かって話ですよ

0801デフォルトの名無しさん

2011/12/06(火) 17:42:59.78

>>799
この主張に対しては妙にレスないんだよな
変な煽り合いにはいっぱいレスつくのに

0802デフォルトの名無しさん

2011/12/06(火) 19:46:27.48

>>796,800
これは結城本の例でいうと、直流12ボルトの電源をアダプタに繋いで交流100ボルトに
変換したとしても飽くまでも電源であるべきで、大まかな機能や目的は変わらないはず。
それに対して>>796の例では、タイマーをアダプタに繋いでもタイマーであるべきだが、
出来上がったクラスのインターフェースを見てみると、タイマーであるとはとても考えられない。

ということかな？
確かにこの例だと出来上がったクラスはイベントリスナであることが主であって、タイマー
としての機能はオプションで交換可能なものとして設計されているように見える。
これをアダプタと考えるのは難しいな。

0803デフォルトの名無しさん

2011/12/06(火) 21:22:34.62

なんでわざわざ継承に書き換えたんだよ。
そもそも視点がおかしい。
C#に書き換えてみれば解りやすい話。

startButton.Click += clock.Start;
stopButton.Click += clock.Stop;

本来のリスナーは、clock.Startとclock.Stop。
アダプター自体じゃない。アダプターは、リスナーオブジェクトから、
リスナーメソッドにインターフェースを変換してやる手伝いをしてるだけ。

0804デフォルトの名無しさん

2011/12/06(火) 21:53:39.31

>>796
> デザインパターン
先人が作ってくれた設計パターンにそれらしい名前をつけただけのもの
問題領域を抽象化する上で、もっとい良い物があればそれを使うべきだ

# 問題領域をうまく抽象化出来ないやつが多いからOOは遅いとか
# 蔑みの目でみられる

0805デフォルトの名無しさん

2011/12/06(火) 22:30:02.96

>>796の例を見れば見るほど設計ミスやら仕様変更の尻拭いに思える
actionPerformed()で受けるのをやめるか、
もっと言えばActionListener#actionPerformed(ActionEvent e)なんてパターンをやめて
クロージャやらデリゲートやらブロックやらを直接受け取るようにすればいいのに

0806デフォルトの名無しさん

2011/12/06(火) 22:33:20.13

>>803
C#の機能でごまかしてるようにしか見えないんだけど
そのコードをJavaで書くとどうなるの？

あと796は委譲の方が良いだろうけど、そこは問題じゃないだろ

0807デフォルトの名無しさん

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は、リスナーを前提としてないオブジェクトとの結合に視点が固まりすぎてる。

0808デフォルトの名無しさん

2011/12/06(火) 22:48:05.85

>>807
結局「new StartAdapter( clock )」これだろ？
803では何を言いたかったのか？何のためにC#に書き換えたのか分からない

> 重要なのは、本来のリスナーがclockのメソッド側にあること。
> >>796は、リスナーを前提としてないオブジェクトとの結合に視点が固まりすぎてる。
これも何をいいたいのか全く分からない
もうちょっと伝わる書き方をして欲しい

0809デフォルトの名無しさん

2011/12/06(火) 23:02:06.55

>>808
startButton.Click += clock.Start;
リスナー本体は、clock.Start()。

>>796は、clock.Start()がリスナーだと思ってない。
だから、アダプター自体がリスナーだと思って違和感を感じるといってる。

0810デフォルトの名無しさん

2011/12/06(火) 23:04:38.64

>>808
C#に書き換えたのは、アダプターがキャスト(変換)機構に過ぎない事を強調してんの。

0811デフォルトの名無しさん

2011/12/06(火) 23:07:59.90

startButton.addMouseListener( clock.Start );

そもそもJavaでこう書けてりゃ今回のパターンでアダプターは書く必要ないんだよな

0812デフォルトの名無しさん

2011/12/06(火) 23:19:02.42

>>809
なんか噛み合ってないな

> >>796は、clock.Start()がリスナーだと思ってない。
思っていないというか、むしろclock.Start()がリスナーで無いことが前提の話なんだが

自分は>>796の言わんとしていることが分かっているつもりなので、おそらくは809の
方が勘違い・読み違いをしていると思う

というか796にもフォローして欲しいところだな

0813デフォルトの名無しさん

2011/12/06(火) 23:20:22.69

startButton.Click += clock.Start;

こういう書き方って結局できたか？
delegateの型を一致させないと+=なんてできなくね？

つまり、そこが違ってるからこそアダプタ云々の話になってるわけで、
C#だからといってそこを誤魔化してはだめじゃね？

0814デフォルトの名無しさん

2011/12/06(火) 23:23:02.03

そりゃ省いただけだが、結局シグニチャを一致させても同じ話だろ。
結局>>811ができないから、やってるだけ。

0815デフォルトの名無しさん

2011/12/06(火) 23:31:34.51

>>812
そもそも>>796はAdapterとしておかしいんだよ

0816デフォルトの名無しさん

2011/12/06(火) 23:36:40.51

もう寝る

0817デフォルトの名無しさん

2011/12/06(火) 23:47:35.30

もうAdapterは懲りたろ。

話は変わるが、MVCで入れ子になったビューの
コントローラーは、どう扱うのが理想なんだろか。
例えば、YesとNoのボタンを持ったViewがあるとする。
YesNoObserverでも作って、親のViewに管理させ、
どちらが押されたか通知ってのは基本として、
それ以外の動作(Yesボタンが右クリックされた)とかは、
どういう風に通知するのが理想だろ？
親のViewにYesとNoの全てのイベントを委譲
管理させるのは扱いづらい・・・。

0818デフォルトの名無しさん

2011/12/07(水) 00:02:47.63

>>812
ListenerにAdapter噛ませてListener機能の無いもん喰わせたら
おかしいと思うのは当たり前。>>802の話にそえば、
Adapter噛ませてもListenerに渡すものはListener機能を
持ってるもんじゃないとおかしい

0819デフォルトの名無しさん

2011/12/07(水) 00:21:12.68

リスナってのはイベントに対する単なるオブザーバ。イベント通知の構造。
アダプタってのはメソッド呼び出し。呼び出すための実装。

0820デフォルトの名無しさん

2011/12/07(水) 01:34:57.23

OOP初めて３日目ぐらいの幼稚な議論ですねｗ

0821デフォルトの名無しさん

2011/12/07(水) 07:23:18.42

>>817
うーん・・・
画面を右クリックした段階では、まだ画面との対話中で、モデルやらビジネスロジックには影響を与えないよね。
俺だったらビューのロジックにそのまま書いちゃうなあ。

バリデーションみたいにモデルかどこかと共通化したいなら別途ヘルパー群を作るとか。

0822デフォルトの名無しさん

2011/12/07(水) 07:32:26.99

(・∀・)ｼﾞｻｸｼﾞｴｰﾝ

0823デフォルトの名無しさん

2011/12/07(水) 08:12:46.02

もうAdapterパターンはいいよ
一人だけ理解してないということがわかった

0824デフォルトの名無しさん

2011/12/07(水) 12:56:27.73

>>819
リスナー　≠　オブザーバー

0825デフォルトの名無しさん

2011/12/07(水) 13:01:17.68

オブザーバはデザパタだけどリスナは
AwtやSwingでのイベントハンドラの呼び名だもんな

0826デフォルトの名無しさん

2011/12/07(水) 17:35:41.82

=ではないけど、リスナーはオブザーバーパターンで実装されている

0827デフォルトの名無しさん

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とは違う。そもそもデザパタ本より先にモデルが
作られてるから仕方ない話だが。

0828デフォルトの名無しさん

2011/12/07(水) 22:48:35.04

GoF本は1995年
JDK 1.0は1996年
JDK 1.1(AWTにjava.awt.EventListenerが導入された)は1997年

0829デフォルトの名無しさん

2011/12/07(水) 23:01:40.99

delegation event model を導入したMFCが作られたのは1992年

0830デフォルトの名無しさん

2011/12/08(木) 11:12:24.08

JDKって0.98時代が長かったような
あと、MFCの元になったThinkCのライブラリは…いつ頃だっけ？

0831デフォルトの名無しさん

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.

0832デフォルトの名無しさん

2011/12/08(木) 17:48:41.34

MVCのSmalltalk-80が開発されたのは…とか言い出す奴が来るからヤメレ

0833デフォルトの名無しさん

2011/12/12(月) 10:49:49.15

デザパタが提唱されたのは90年代。
これは間違いないから大丈夫。

0834デフォルトの名無しさん

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>() ; }
}
};

0835デフォルトの名無しさん

2012/01/16(月) 22:18:36.19

書籍デザインパターンには、Factoryパターンってのは無い。
それを踏まえた上で、一般的な意味でFactoryというなら
登録までしていいんじゃないか。

ちなみにデザパタ本の話を持ち出すと、
加工したオブジェクトを返すパターンはBuilderパターンと言われ、
切り替え可能な仮想コンストラクターのセットをAbstractFactoryという。
また、単一のコンストラクターを仮想化したものをFactoryMethodという。
まぁ、呼び方なんかどうでもいいし、どれか1つに合わせて
ガッチリ作らなきゃならんわけでもない。

0836835

2012/01/19(木) 00:44:41.91

FactoryMethodについていい加減な事書いてたんで、一応補足。
FactoryMethodは、クラスAがあったとき、クラスAの内部や、Aの関係各所でつかう
他のクラスのコンストラクターをAに直接使わせないようにする方法。
やり方は、他のクラスのコンストラクターの代わりに、Aに他のクラスを
戻り値とする仮想関数を定義する。で、Aの子クラスBで仮想関数に具体的な
コンストラクターを実装してやるってパターンね。

0837デフォルトの名無しさん

2012/01/19(木) 06:25:39.58

FactoryはGoFのと、EffectiveJavaに書いてあるのがあってややこしい

0838デフォルトの名無しさん

2012/01/19(木) 08:49:36.74

http://digital.asahi.com/articles/TKY201201160436.html

【簡単なまとめ】

★日本人の知らないうちに、欧州を中心に、世界中で日本文化ブームが起きて凄いことになっていた
　(実質第2次ジャポニズムブーム)
↓
★現地にいる人間からの情報で、日本人がやっと気づいた
↓
★日本文化の紹介を何もしてこなかった政府が批判され国会議員が動いた
↓
★政府やNHKが「クールジャパン」という言葉を作り、やっと広報活動を始めた
↓
★しかしすでに欧米では、ブームを通り越して生活の一部として定着してたw　すでに日常風景ww　広報の意味なし
↓
★韓国が日本のようにチヤホヤされたくて捏造韓流ブームを煽ったが、全く人気が出ず、世界的にバレたｱｲｺﾞｰ＜;#｀Д´＞
↓
★韓国が頭に来て、全世界での日本文化ブームもウソということにするﾆﾀﾞﾟ
↓
★在日朝鮮人の村上隆くん頼むﾆﾀﾞ
↓
★村上隆　「日本文化ブームはウソ」というと、さすがにバレるので、「クールジャパンはウソ」でごまかして発信
↓
★確かに、「クール・ジャパン」という人は外国ではほとんどいないのは事実だが
「ジャパン　イズ　クール」とか「ジャパニーズ○○　イズ　クール」という人は普通にいる
あとはwonderful amazing ,,,とかね。まぁどの言葉も似たような意味だから
「クール・ジャパン」と思っている人が多いのは間違いではない
↓
★村上隆が巧妙なのは、「クール・ジャパン」という言い方はしていないということを
　「日本文化が実は人気がない」という風に思わせるように発言していること
↓
★村上隆の印象操作工作発言にダマされたバカが続出中　←今ココ　( ´ω`)

0839デフォルトの名無しさん

2012/01/19(木) 09:58:58.08

日本がクールとか白痴だろ
東電や政府、オリンパスを始めとした糞企業のせいで日本のイメージは今や韓国と並んでワースト２だよ

0840デフォルトの名無しさん

2012/01/19(木) 18:29:34.95

ネトウヨが言う日本＝とっくに消滅した大日本帝國

0841デフォルトの名無しさん

2012/01/21(土) 18:31:34.71

大日本帝国も日露戦争くらいまでは良かったけど、その後はなあ。

0842デフォルトの名無しさん

2012/01/22(日) 20:02:15.73

東電や政府が糞なのは同意していいが
ここはオブジェクト設計スレだからなあ。
リスコフの置換原則の観点で意見を述べるなら
韓国と同一視できるか否かが鍵だな。答えはもちろんNOだ

0843デフォルトの名無しさん

2012/01/29(日) 12:46:29.39

>>840

健在だが？

http://lapizlazuri.net/041225kokuji2.jpg

0844デフォルトの名無しさん

2012/01/29(日) 23:01:47.23

オブジェクト指向の正しさに確信がもてないんで教えてほしい。
実際にコードを書いて、便利さを説明してるサイトや本ってないかな。
オブジェクト指向だとこういう実装になるけど、従来の手続き型で書くとこうなる、みたいな。

084599

2012/01/30(月) 01:43:26.89

>>844
もうそれは結城本とかで自力でいろいろ試してみるとか。

0846デフォルトの名無しさん

2012/01/30(月) 07:03:16.45

オブジェクト指向の原則とかデザインパターンでインターフェースを利用した拡張性や保守性を上げるテクニックはいくつもあるけど、オブジェクト指向プログラミング最初の一歩はカプセル化のデータ隠蔽ができているドメインモデル貧血症になっていないコードだと思う

0847デフォルトの名無しさん

2012/01/30(月) 08:47:37.86

詳細の隠蔽と拡張のしやすさだな
でも拡張のしやすさについては間違った方法でやるとスパゲティ量産になるから単純に利点と言い切れないかな

0848デフォルトの名無しさん

2012/01/30(月) 15:27:35.62

いまや実装の継承は暗黒面と考えてもよいとおもってる(笑
まあ節度ある使い方してればそれほどでもないけどさ。

0849デフォルトの名無しさん

2012/01/30(月) 15:44:59.14

インターフェースを階層化して、実装はほぼ集約だけだな

0850デフォルトの名無しさん

2012/01/30(月) 18:13:36.43

全部委譲って現実的にどうなんだろう
極端な例だけどJFrameとかは委譲しないよね（これは型の問題もあるけど

ただ単に委譲するメソッドの割合が多いと実装継承使いたくなる
差分が1つのメソッドとか

0851デフォルトの名無しさん

2012/01/30(月) 18:48:59.22

おれは継承を包含に変換するプリプロセスプログラム作ったわ。

ネームスペースで問題(同じ名前で同じ型の同じ数の引数のあるメソッドとか)は、
コンパイル時にエラーとしてわざと検出してもらえるようにしてある。

問題のある箇所は自力で解決している。

0852デフォルトの名無しさん

2012/01/30(月) 21:29:31.68

>>850
JFrameを継承しなきゃならん時なんてまずないだろ。
コンポーネントがコンポーネントを直に持つクラスってよく見るが、
アレは無駄だ。
コンポーネントの外でデコレートしてやりゃ十分。

0853デフォルトの名無しさん

2012/01/31(火) 02:47:14.10

>>852
ここらへんは粒度とかコード量に依存してる気がする
外からデコレートで煩雑になると考えたら、
そのコンポーネントで囲っちゃうな

0854デフォルトの名無しさん

2012/01/31(火) 07:16:25.37

>>852
継承委譲の話からはそれちゃうけど、JFrameを継承した独自のクラスを作るのは無駄ってことか
確かにそうかも

JFrameを継承しているクラスに専用のメソッド用意したら、それこそ変な実装継承になっちゃうか

0855デフォルトの名無しさん

2012/01/31(火) 07:22:16.55

Swingの優れたオープンソースのコードって何かある？

MVCでModelとViewの関係をObserverパターンで関連付けるというメリットも書き方もわかるけど、現実的にどう適用してるのかを見てみたい

EclipseはSWTだし、大きくてどこ読めばいいかさっぱりだった

0856デフォルトの名無しさん

2012/01/31(火) 08:17:09.90

>>855
swingでまともなMVCは難しいよ。
VCなスタイルになる。何故かコントローラーの
Actionがモデルが持つべき機能を持ってるしね。

0857デフォルトの名無しさん

2012/01/31(火) 09:49:31.21

本でそういうことしてるパターンを見たことないんだけど、Observerパターンで通知関数を目的別に増やすことって普通？
連想型のコンテナをラップしたサブジェクトクラスを監視してるオブザーバークラスがあってそのオブザーバーはサブジェクトの更新時にコンテナの増分を知りたいという状況なんだけど
コンテナのコピーをとって毎回差分を計算してたら遅すぎるから増分を直接通知する通知関数をつくろうかと思ったんだけど
オブザーバーパターンの本来の利点の一つであるサブジェクトの設計がオブザーバーの設計に影響されないっていうのに反してる気がして悩んでる
言い直すと、オブザーバーがどんな情報を要求しているかサブジェクトが知らなければならない、というのが良くないんじゃないかなと感じるんだけど、どう思う？

0858デフォルトの名無しさん

2012/01/31(火) 12:28:22.32

>>856
ActionListenerを実装した専用のクラスを作ってそれをviewにaddActionListenerさせればVとC別れるってことにはならないのかな

Viewが持っているControllerのactionが持つべき機能って何？

0859デフォルトの名無しさん

2012/01/31(火) 12:35:26.97

>>857
現実的にはこういうときMVCに限界を感じる
だからMVCがダメという訳ではなく状況に応じてMVCから脱線することも必要だと思う

通知関数を増やさない方法としては、Modelがupdateするときにどの情報が更新されたかを知らせるプラグを渡すという方法もあるけど、フラグ管理は格好悪い

この2つ以外に方法あるのかな

0860デフォルトの名無しさん

2012/01/31(火) 13:04:04.64

>>857
1つ増加する度に通知すればいいだけだと思うけどそれじゃだめなんけ。
あと、監視側は別に監視対象に依存してもいいでしょ。
イベント情報から監視対象を参照しなければいいだけ。
監視対象が監視側に依存するのは論外だけど。

0861デフォルトの名無しさん

2012/01/31(火) 13:05:45.06

>>858
ごめん。VCって書いたのはMが消えるって意味。
VとCが癒着するって事じゃないよ。

0862デフォルトの名無しさん

2012/01/31(火) 15:27:36.82

>>860
「ひとつ増加するたびにその差分を通知してほしい」という欲求はオブザーバー側から来るものでしょ
これに応えるてしまうとサブジェクトのオブザーバーへの依存が切り捨てられないことになる
しかし依存は切れなくなるがパフォーマンスは改善する
というジレンマの話をしているの

0863デフォルトの名無しさん

2012/01/31(火) 17:50:24.81

>>861
Mが消えるということはないような
どういう状況を言ってる？

Mの処理をCに書いちゃうということかな

0864デフォルトの名無しさん

2012/01/31(火) 21:58:35.69

>>863
CがMを兼ねるってとこかな。
クラス的に同一というだけだから、
Actionクラスの子をモデルの生贄にして、
他のリスナーからActionを弄るという方法で
オブジェクト的に分離できるっちゃ出来るけど。

0865デフォルトの名無しさん

2012/01/31(火) 21:59:06.75

>>863
>>861は、MのロジックがCに集められて、Mがドメインモデル貧血症をおこし、ただのCのValue objectになっていると言いたいのかなと思った。

0866デフォルトの名無しさん

2012/01/31(火) 22:10:55.34

>>857
Subjectからは、変更があった事だけを通知してもらい、observerから、値をpullするってのは？

subjectにそんなプロパティをもたせると、依存関係ができてしまうのて、別途専用のインターフェースを用意し、それを介するようにする。

このインターフェースの実体 = subjectとするか、subjectを参照する何かにするかは自由。

0867デフォルトの名無しさん

2012/01/31(火) 22:24:59.22

ここまで書いて、差分の通知の事忘れてた。

コピーを取るという事は、subject自体どれが変更されたか認識していなくて、変更前後を確認する必要があるということ？

0868デフォルトの名無しさん

2012/02/01(水) 01:20:19.21

Observer側で今までの持ってて変更内容Subjectから貰えればどうとでもなるんじゃないの？
よーわからん。

0869デフォルトの名無しさん

2012/02/01(水) 06:22:32.02

>>864
その分離がMVCかと思ってたんだけどSwing（Java?）以外ではどうやってOとCの分離を実現するの？

0870デフォルトの名無しさん

2012/02/01(水) 06:25:36.70

>>865
それかと思ったけど、ドメインモデル貧血症はSwingに依存する話ではないから、また別の何かあるのかと思った
それとも他のに比べてSwingはドメインモデル貧血症を起こしやすい仕組みなのかな

0871デフォルトの名無しさん

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とかいわれるやつを組み込む。

0872デフォルトの名無しさん

2012/02/01(水) 08:38:54.14

ドメインモデル貧血症のなにがわるい？
オブジェクト指向じゃないってことか？

オブジェクト指向ってのはあくまで手段
手段が目的になってないか？

0873デフォルトの名無しさん

2012/02/01(水) 12:38:00.73

>>871
たいぽです
最初の話に戻るけどMFCとかは分離せずにMとVがくっつくというのはわかるけど、それならむしろSwingの方がMVCを実現しやすいような

分離するのがMVCなのかと思ってる

0874デフォルトの名無しさん

2012/02/01(水) 12:40:47.28

>>872
setter,getter作ってそれで操作されたらフィールドの値好きに書き換えられちゃうのが嫌だ

自分の作ったクラスは一定のルールの元使って欲しい
そうじゃないとバグがあったとき、どのような操作でバグが引き起こされたのか把握しづらい
データ隠蔽は必要

0875デフォルトの名無しさん

2012/02/01(水) 12:43:52.17

クラスに使われ方を想定し、ましてやそれを使う側に強いるなど…。
インタフェースだけで完結している単位が使いやすい。

0876デフォルトの名無しさん

2012/02/01(水) 13:14:18.71

>>869
QtやActionScriptなら、適当に作ったモデルをViewに
紐付けできる仕組みがある。

Swingには同じ一貫した仕組みは無い。
document modelとかあるけど一部のviewにしか使えない。

0877デフォルトの名無しさん

2012/02/01(水) 18:06:28.17

>>875
データ隠蔽とインターフェースは反する関係じゃないでしょ

データ隠蔽しない、更にクラスの使い方を強制しないってことは、Listインターフェースを継承したクラスでは配列へのアクセッサー用意してもらって、addメソッドやremoveメソッド無くせば満足なの？

0878デフォルトの名無しさん

2012/02/01(水) 18:22:11.97

>>876
バインディングというやつかな
VからMの依存関係は別のファイルに書くんだっけ

あとわからないことがあるんだけどMVCで新しいViewを表示したい場合はCがnewしていいの？
CはM以外に依存してはいけないという理解なんだけど他に適当なところが見当たらない

0879デフォルトの名無しさん

2012/02/01(水) 18:24:17.10

まあクラスにステートが存在する以上、イレギュラーな事態は起こりうるよね。
A→B→Cの順でメソッド呼んでね？的なのを防ぐには、状態別にオブジェクトを作るとかしないと無理ぽ。

0880デフォルトの名無しさん

2012/02/01(水) 19:32:02.72

>>878
バインドは一つのコード内にかけるよ。
QtならQObject::connectつてな関数で紐付するだけ。

0881デフォルトの名無しさん

2012/02/01(水) 19:34:51.87

>>878
viewとmodelでやるのは、本来の目的を
考えりゃあり得ないからね。
ちなみに本来の目的ってのは、ビジネスロジックの
隔離とかじゃないよ。

0882デフォルトの名無しさん

2012/02/01(水) 20:00:15.53

>>881
関連付けをVやMでやるのはおかしいということですか？
現在はVやMを作るメインメソッド的なところで関連付けてます

ただこれだと新しく途中でViewをnewするときに困る

あらかじめ表示されるViewをすべてnewしておいて表示したいときに表示命令を出すようにすれば解決するけど、メモリが激しく無駄…

0883882

2012/02/01(水) 20:13:02.03

>>881のレスは後半のnewの話だったかな

CからPMとかVMとか呼ばれる物に指示するのが正しい気がしてきた

PMはCからViewを表示しろという指示を受ける PMはそれをViewに通知

0884デフォルトの名無しさん

2012/02/01(水) 20:27:07.42

http://www.sra.co.jp/people/nisinaka/Jun4Java/MVC/mvc.gif

この図が本来の目的。この図を
考えればMとVとCを
どう分けるべきか大体わかると思う。

0885デフォルトの名無しさん

2012/02/01(水) 20:31:33.59

>>882
MVCを集約管理するクラスへの弱参照をVやCが持ってそれに新しいV作ったから適切にBindしてちょって頼めばいいんじゃね？

0886デフォルトの名無しさん

2012/02/01(水) 20:36:41.64

MVCを厳密に守る必要なんて必ずしもないんだし
頭固すぎだろ

0887デフォルトの名無しさん

2012/02/01(水) 20:40:04.00

>>878
CがVに依存して困る理由もないじゃん。
Vの実装に対する依存がいやなら、
CはVを抽象化して操作すりゃいい。

0888デフォルトの名無しさん

2012/02/01(水) 20:45:34.69

>>884
それはもうみんな理解した上での議論

0889デフォルトの名無しさん

2012/02/01(水) 21:00:17.49

>>884
それだけでそう分けるべきかわかってたら
MVCとかMVVMとかMPVとか乱立しねーよ(´・ω・｀)

MとVVMとかVCは分離されてしかるべきだけどV-VM、V-Cは依存しててもそんな問題ないよね

0890デフォルトの名無しさん

2012/02/01(水) 21:09:38.20

>>872
悪くないよ。もはやMVCと呼べるものではないだけ。

0891デフォルトの名無しさん

2012/02/01(水) 21:20:10.42

>>882
ロジックが読みづらくなるかもだけど、遅延生成にしてみるとか？

Viewを直接インスタンス化するのではなくて、ViewのFactoryをインスタンス化して、初めて必要になった時にViewを作らせる。

0892デフォルトの名無しさん

2012/02/01(水) 21:22:09.66

>>882
メモリもそうだけど動的にVIewの個数が変わるときも困るから
最初に全部用意ってのは選択肢としてないでしょ

0893デフォルトの名無しさん

2012/02/01(水) 21:25:07.52

Viewをキャッシュするという方法もある。
Androidの画面遷移みたいに、最新のn個を残しておいて、残りは適宜削除。
また必要になったら再生成。

0894デフォルトの名無しさん

2012/02/01(水) 21:26:51.32

>>892
個数が変わる時は、なんらかの対策が必要だけど、依存性を最初に解決できるメリットはあると思うよ。

0895デフォルトの名無しさん

2012/02/01(水) 21:31:21.97

>>890は、少し言葉足らずだったかな？

Mがドメインモデル貧血症になると、それはただのValue objectとなり、CがMの役割となり、結果Model-View になるだけかなと、思ってる。

0896デフォルトの名無しさん

2012/02/01(水) 21:39:56.01

>>886-887
その通りだけど、単純に思いつく方法より良い方法はないのかという話

0897デフォルトの名無しさん

2012/02/01(水) 21:54:17.64

View生成用のクラスを別途作るという意見が多そうですね
そのViewに関連して必要になるControllerも一緒に作る
この生成クラスにViewが監視すべきModelを渡す方法は少し考える必要がある

というのは1つの方法かな

このView生成クラスに、依存性の情報を管理させると考えると責務としてもしっくりくる
このViewとModelの依存関係というのは、アプリの1度の実行に依存するものだから、わざわざViewごとに生成クラスを分ける必要もない

ControllerがこのView生成クラスに直接依存するのが嫌だったら、何かインターフェースを用意してそれに依存すればいいのかな
インターフェースにはViewの生成機会単位のメソッドを用意

0898デフォルトの名無しさん

2012/02/01(水) 21:54:30.60

>>896
そもそもviewをどの単位で言っているのか謎。
サムネイルリストのサムネイル一個一個をモデルに基づき
生成するのはViewの役目だし、サムネイルリスト画面を
生成するのはControlerの役割じゃん。
どっちよ。

0899デフォルトの名無しさん

2012/02/01(水) 22:02:25.08

>>898
後者
気にしてなかったけど、前者は何も考えずViewでやってた

厳密にやるなら、サムネイル1個1個もControllerで作って、サムネイルリストの画面に引数で渡して上げたりした方がいいのかな
そうなるとボタンは・・・とか切りないな

0900デフォルトの名無しさん

2012/02/01(水) 22:09:30.09

>>899
Model更新に基づく部分にControlerが介入しちゃいかんよ。
せいぜいサムネイルを生成するFactoryの交換ぐらい。

0901デフォルトの名無しさん

2012/02/01(水) 23:05:56.64

MVVMってControllerに当たる処理の再利用出来ないけど、何がいいの？
IDEの支援は置いといてロジックとして何がMVCよりいいの？

0902デフォルトの名無しさん

2012/02/01(水) 23:09:50.98

>>897
以前使った方法は、画面の状態遷移を管理するためのクラスを用意し、全てのControllerに持たせる(1ウインドウで中のページを切り替えてたので、Singletonだったかも)。

次の画面に関する識別子をこいつに渡して、次画面を取り出すようにしてた。
併せてナビゲーション管理も行わせて、前画面に戻るための仕掛けを用意してた(むしろこの機能がメイン)

0903デフォルトの名無しさん

2012/02/01(水) 23:22:00.55

MVPパターンにならってViewがインターフェースを通して抽象化されてたら
大抵の画面はコントローラーが頑張り過ぎる実装で十分だと思うぞ。
きちんとしたMVCは実装コストが高くつくし再利用できて画面にガシガシ
更新が反映されるモデルが見つかったなって思ったタイミングではじめて
実装をはじめればOK。

0904デフォルトの名無しさん

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));

0905デフォルトの名無しさん

2012/02/01(水) 23:30:48.12

>>903
基本的なモデルは1度作ったら延々と再利用出来るじゃん。
複雑なモデルはともかく、ただのテキストとか、
整数はMVCガンガン使った方が楽でしょ。

0906デフォルトの名無しさん

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をモックにすれば、自動化できるかな？

0907デフォルトの名無しさん

2012/02/01(水) 23:54:09.57

>>905
むしろ、モデルは一度作ったら変更しにくいから
しっかりと作らないといけないだけだろ

それでも、後で変更したくなる

0908デフォルトの名無しさん

2012/02/01(水) 23:57:47.49

>>906
回答ありがと。
MVVMはQtやSmalltalkのようにIDE上でドラッグアンドドロップだけで、
M/V/Cに当たるものを繋ぎ合わせられたりする？

0909デフォルトの名無しさん

2012/02/01(水) 23:57:50.69

>>904
もう少し泥臭く、Controllerにcontextだけ渡しておき、Controllerでイベントをハンドリングする処理の中で必要に応じてcontextに問い合わせ。

状態管理をもつService Locatorみたいなところかな

0910デフォルトの名無しさん

2012/02/02(木) 00:03:11.33

>>907
stringモデルとか、intモデルとか、
代入と、読み出し、
リスナー登録ぐらいしか必要無いしそんな拘る所も無くね？

0911910

2012/02/02(木) 00:11:04.43

そういやmodelがviewに見せるのは、
読み出しインターフェイスだけ。
だからなおさらモデル設計が緩くてもそんなにこまんないよ。

0912デフォルトの名無しさん

2012/02/02(木) 00:13:16.17

オブジェクト指向とは的なことはマニアに任せて
現実ではオブジェクトは二種類にわかれると思う。

一つは処理がメインの構造オブジェクト
もう一つは値として使う値オブジェクト

フレームワーク部分は構造だろう。こいつは
他から値をもらうけど、中で長期間保持したりしない。
いわばシングルトンオブジェクトでいいもの。

それに対して日付オブジェクトとかは、数値型と同じく値が主。
処理も持っているけど、基本は値。値の拡張版
データとして保存しシリアライズするかもしれないようなもの。

0913デフォルトの名無しさん

2012/02/02(木) 00:15:24.69

>>910
部品単位と画面単位の話を分けて考えたほうがいいんじゃないのか。
単一の整数や文字列のモデルって単純な部品単位のモデルであって
画面単位の話じゃないよね。

0914デフォルトの名無しさん

2012/02/02(木) 00:16:50.05

>>901
Controlerってそんなに再利用できる？
というか再利用してもそんなに幸せにならない気がする。

0915デフォルトの名無しさん

2012/02/02(木) 00:18:03.22

>>908
IDE(Visual Studio)単体にはなかった気が

VにVMのプロパティを指定するところは、Expression Blendという、V構築ツールを使えば可能
IDEと統合されてたかどうかは不明。

VMの自動生成もなし。各々のフレームワーク作者が、用意しているっぽい

Mとのリンクもあったかな？

Visual Studioの世界では、まだまだ発展途上な感じ。

0916デフォルトの名無しさん

2012/02/02(木) 00:46:08.81

>>914
>>904ぐらいの粒度にしとけばね

0917デフォルトの名無しさん

2012/02/02(木) 01:11:44.47

>>913
画面単位は、部品のモデル差し直すぐらいしか
やる事ないから、あんまり重要視してないけど何かある？
個人的にはMVCは部品単位が一番効果を発揮すると思ってるけど。
3Dモデルを角度毎複数のviewに表示したり、
プログレスバーとラベルに同じ進捗表示したりさ。

0918デフォルトの名無しさん

2012/02/02(木) 06:18:46.82

Controllerの再利用のユースケースとしては、最初はこのボタンのControllerだったけど、他のボタンに変えよう、という状況？

このときこのControllerがMとVに依存しているのは問題なさそう
ボタンが変わったとしても依存しているViewとModelの操作をするという責務は変わってない

0919デフォルトの名無しさん

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と同じ？

0920デフォルトの名無しさん

2012/02/02(木) 08:01:13.75

>>918
戻ると進むとか、保存とか、ウィンドウを
全て閉じたら終了とか一般的なものは
大概再利用可能じゃないか

0921デフォルトの名無しさん

2012/02/02(木) 08:42:30.65

>>920
その辺はそういった処理するのを関数とか小さいクラスのレベルで再利用するけれど、コントローラーはそれらを集約して使うだけでコントローラー自体の再利用とはちとちがくね？

0922デフォルトの名無しさん

2012/02/02(木) 12:59:12.44

Controllerで集約とかあんまりしなくないか？
戻る、進むControllerなんて、コンストラクタで捕縛した、
Modelの戻るメソッド呼ぶだけだし。
戻るメソッドに合わせて多少のイベント変換はするけど
大した事はしないよ。

0923デフォルトの名無しさん

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パッケージに突っ込む

0924デフォルトの名無しさん

2012/02/02(木) 18:55:07.83

何のためにパッケージ分けすんの？
そこが問題じゃね？

0925デフォルトの名無しさん

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を登録する

0926デフォルトの名無しさん

2012/02/02(木) 20:58:21.34

パッケージつうか名前空間ってのは
衝突回避のためだけに
長い名前を書かなくて済むようにするためのもんだからね。
名前が重複せず関連性の強いもんに分けるだけでいいでしょ。
Socketならudpパッケージとtcpパッケージにそれぞれ作るとか。

0927デフォルトの名無しさん

2012/02/02(木) 20:59:09.75

>>923
モジュール単位で分けるのが好きなので、その4、をよく採用するかな？

0928デフォルトの名無しさん

2012/02/02(木) 22:42:14.52

Text::Model;
Text::View;
Number::Model;
Number::View;

一般的な名称を下位に置き、固有に近い名称を
上位に置く分け方が重複しづらく短縮もしやすくて合理的。
ただ名前空間の別名付けられないJavaだと使いづらい。

0929デフォルトの名無しさん

2012/02/08(水) 18:51:16.05

・一つのオブジェクトをいくつかのコンテナ（管理クラス）に異なるインターフェースで登録する
・コンテナを一箇所にまとめて共有し、能力照会でインターフェースを取得する

どっちがいいとおもう？
どっちでやってもごちゃごちゃするんだけど

0930デフォルトの名無しさん

2012/02/08(水) 20:17:13.71

よくわからない

0931デフォルトの名無しさん

2012/02/08(水) 20:33:27.90

既に分かりにくい。

0932デフォルトの名無しさん

2012/02/08(水) 20:49:08.03

外国の方がエキサイト翻訳を通して質問しているのだ
英語で答えて差し上げなさい

0933デフォルトの名無しさん

2012/02/08(水) 21:08:07.89

エキサイト翻訳って海外にもあるんだね
はじめて知った

0934デフォルトの名無しさん

2012/02/08(水) 22:41:27.19

RPGのキャラを管理するのに、
1. スキルごとにコンテナを用意。魔法戦士なんかは魔法使いコンテナと戦士コンテナの両方に登録。
2. コンテナはひとつだけ用意。スキルを指定してキャラ集合を取得するインタフェースを用意。

のどっちがいいか？　ってことじゃないか。

0935デフォルトの名無しさん

2012/02/08(水) 22:49:59.65

>>929
Service Locator作りたいってことかえ？

後者が良くわからんが、一つのコンテナに全部詰め込むって意味なら、型安全な前者を選ぶ。
そうではなく、前者のコンテナにを束ねたファサードなら、依存性を一箇所で管理できるので、後者の方がいいんじゃないの？

0936デフォルトの名無しさん

2012/02/09(木) 06:18:50.24

>>929
もう少し具体的な状況を説明してくれないとわからない
前者が良い場合も後者が良い場合もあると思う

0937デフォルトの名無しさん

2012/02/11(土) 16:50:41.42

コマンドパターンを理解した。
アブストラクトファクトリも１年掛かったが正確に理解した。
デザパタって、すぐにわかったような気にはなるのだが、いざとなると混乱する。
アブストラクトファクトリは相性が悪かった。
何度もわかった、と思うのだが、どうしても適用でない。

0938デフォルトの名無しさん

2012/02/11(土) 17:08:16.51

デザパタなんか名前つけて一生懸命覚える新参にはうんざり
あんなん普通にプログラムかいてれば自分で覚えるだろ
・あとあと楽なように
・とりあえずこの場を切り抜けたい
・移植したい
・速くしたい
・読みやすくしたい
みたいなさいろんな条件で書いた経験があればさ

言語によっても書きやすいパターン違うしさ。
・・・ファクトリとかうざいから

>>929
後者がいいに決まってんだろ。使う人の立場を考えようぜ
使う人は何がしたいかって言ったら、インターフェースを指定してその機能をもったオブジェクトのリストが取得したいんだろ？
中でどうやって実装してもいいけどさ

0939デフォルトの名無しさん

2012/02/11(土) 17:10:21.24

使う人の立場(多くの場合は自分だけど)を考えてた
プログラミングで大事なのは思いやりな。まあお前らみたいな冷たい心の持ち主には何年かかっても分からないだろうけどな

0940デフォルトの名無しさん

2012/02/11(土) 19:55:41.36

>>938
えらそーなわりに、設計センスねーのな

責務過多になってるだけだろ。>>929は質問者が用意した選択肢の中にまどな答えがない、が答えだわ

0941929

2012/02/11(土) 21:10:52.36

すいません説明が足りなかったみたいですね
自分がやりたかったことは「要素の集合から特定の型（インターフェース）を持つ要素をリストアップ」したいってことです
例えば「ゲームワールドから衝突可能インターフェースを継承したものをリストアップ」したい、といった感じで

0942デフォルトの名無しさん

2012/02/11(土) 21:32:11.53

>>941
ケースバイケースなんだな。ゲームみたいにパフォーマンスが必要な場合、かつ衝突可能かどうかっていうのはメインな要素じゃん
それなら拡張性無視でやるんだよ
ゲームでそういうやり方やっちゃうのは、最近の言語から入ったザコどもな
アセンブラレベルでどのくらいの処理になるのか分かっちゃいない

もう少し高度なアプリケーションの場合はそういうのもありだな
htmlのタグに関して、クリック可能だの、・・・可能だのそういう奴とかな。よく知らないけど

0943デフォルトの名無しさん

2012/02/11(土) 21:34:32.00

>>940
いやさ、趣味プログラマで独りでしか開発したことないからさ
エラくないのよ。最近バイトでそういうのやるんだけどさ、内心びびってるのよ
こいつらどのくらい凄いだろうって。

実際書けないやつもいるんけどさ、俺と同じで小学校からみたいな奴も居てさ
ガクブルよ

0944デフォルトの名無しさん

2012/02/11(土) 21:43:51.21

>>938
>・・・ファクトリとかうざいから
同感ｗｗｗｗ
プログラミング暦３０年の俺の経験上
ファクトリが必要と感じるのはイニシャライザのオーバーライドを前提とする場合だけ。

0945デフォルトの名無しさん

2012/02/11(土) 21:52:15.87

まてよパッケージプライベートのクラスを生成する場合にも有用だよな。
とにかく必須でない趣味のファクトリはうざい。

0946デフォルトの名無しさん

2012/02/11(土) 21:58:17.19

俺の仕事もファクトリしてください

0947デフォルトの名無しさん

2012/02/11(土) 22:04:32.13

>>944
無駄な30年でしたね。。

0948デフォルトの名無しさん

2012/02/11(土) 22:08:26.11

最初に触った言語がdelphiなんだけどさ、javaで・・・factoryって来たときはカルチャーショックな

アブストラクトファクトリー今調べたけど名前負けする概念だな

俺の経験から
・コード量を減らす
・将来的なコードを変更量を減らす
このふたつを目指せばまあまあいいコードが書けるんじゃないかなって。自然と・・・ファクトリーみたいなことも思いつくはず

0949デフォルトの名無しさん

2012/02/11(土) 22:09:20.12

俺が書くときは、これプラス実用上十分な速度が出るか
っていうのをしか考えて無いな

0950デフォルトの名無しさん

2012/02/11(土) 22:14:53.46

オーバーヘッド増やして喜んでいるだけのファクトリ書く奴が多すぎてウザイ。
まあ他人の趣味に口を挟むのも野暮かもしれないが。

0951デフォルトの名無しさん

2012/02/11(土) 22:16:06.41

ファクトリの主な目的はコンパイル防壁とマッピングによるswitchの削減だね

0952デフォルトの名無しさん

2012/02/11(土) 22:20:02.76

自演わきすぎワロス
秋田から別の話題にれっつごー

0953デフォルトの名無しさん

2012/02/11(土) 22:23:26.04

そういえば、なんでdelphiっていうとみんな微妙な顔するの？

0954デフォルトの名無しさん

2012/02/11(土) 22:26:33.80

>>953
borlandがすでに終了してるからだろ。

0955デフォルトの名無しさん

2012/02/11(土) 22:26:55.69

>>953
廃れていく技術だから。

0956デフォルトの名無しさん

2012/02/11(土) 22:31:09.21

ﾃﾞﾙﾌｫｲ!

0957デフォルトの名無しさん

2012/02/11(土) 22:33:08.40

露骨に空気が変わるんだよ＞＜
C++って書きづらいじゃん。書きやすくてネイティブってDelphiしか無いんだよ

そういえば、C++って全部ヘッダーファイルに書くのが今風だよな？
いちいちソースとヘッダー行き来する面倒だし

0958デフォルトの名無しさん

2012/02/11(土) 22:36:58.54

>>953
約２０年前に使った事あるよ。ビジュアル開発環境として当時は画期的だった。これをＭ＄がパクッタのがVisualBasicやVisualC++
開発の順序は
Delphi→C++Builder→JBuilder
でborlandは滅びてJBuilderも今はeclipseベースになってしまった。

0959デフォルトの名無しさん

2012/02/11(土) 22:38:58.79

>>957
スレタイ読まないdelphi話はじめるような空気の嫁なさが空気を変えてるだけだ

0960デフォルトの名無しさん

2012/02/11(土) 22:45:03.99

>>958
俺が生まれたらへんじゃねえかＹＯ
delphi作った人がmicrosoftに行っちゃってC#作ったっていううわさだよな

>>959
そうだったな。じゃあ

俺流のデザパタ
・コード量を減らす
・将来的なコード変更量を減らす
について語ろうぜ

0961デフォルトの名無しさん

2012/02/11(土) 22:50:50.53

>>960
後者の問題に気づかないようだと
話し相手として不足感が

0962デフォルトの名無しさん

2012/02/11(土) 22:52:35.68

>>960
そもそも、デザパタの出自とか勉強不足すぎだな
その自己流＜デザパタ＞とやらは
デザインパターンを名乗る資格を全く満たしてない

0963デフォルトの名無しさん

2012/02/11(土) 22:53:30.25

・コード量を減らす
デザインパターンの効果としてこれは低いだろ。
全体の整合性が良くなって結果的に減る事はあっても
十分に整理されたプログラムならデザインパターンを用いなくても同等。

0964デフォルトの名無しさん

2012/02/11(土) 23:02:43.83

>>963
メタ的にさ、デザインパターンを使うか使わないかって判断しないといけないときあるじゃん
上ででてたファクトリーを使うかどうかみたいな

そういうときにどっちのほうがコード量が減るか。とか
将来的にどういう変更が予想されるかそれぞれコード変更量はどの程度なのか
っていうのを考えると判断しやすいような気がしたんだよ

>>962
デザインパターンって調べたけど、プログラマ同士の共通語を用意してみたけどどうかな？
って程度のものなのな。みんな騒ぎすぎなんだな

0965デフォルトの名無しさん

2012/02/11(土) 23:25:19.32

>>933
http://www.excite.com/　ってのはマジであるようだが…。

0966デフォルトの名無しさん

2012/02/11(土) 23:38:25.16

話し変わるけど、
このまま落とすのももったいないので、次スレ行きたいので、
テンプレ候補を選び出してもらえますか？

0967デフォルトの名無しさん

2012/02/11(土) 23:41:08.96

>>89

0968デフォルトの名無しさん

2012/02/11(土) 23:45:02.22

FactoryはTemplateのインスタンス生成に応用したようなもんだけど実際使いどころない
AbstractFactoryはStrategyなどのポリモーフィズムを利用した拡張可能部分に関連性があるときは使いやすい

0969デフォルトの名無しさん

2012/02/11(土) 23:47:43.19

StrategyでAbstractFactoryとかないわ

0970デフォルトの名無しさん

2012/02/12(日) 00:17:58.55

デザパタのおかげで、
Strategyというだけで話が通じる
いい時代になったな。

0971デフォルトの名無しさん

2012/02/12(日) 00:23:27.93

GoFはちょっと古すぎるからなぁ
ライブラリで使ってるのはいいけど
無理に入れたがるやつはマジ簡便

0972デフォルトの名無しさん

2012/02/12(日) 00:30:58.59

デザパタの多くは間にレイヤーを入れて差異を吸収するものってことでまとめられるよね(´・ω・｀)

0973デフォルトの名無しさん

2012/02/12(日) 00:32:10.06

仕様書にないクラスをいきなり作る奴はビジネスの場においてゴミ

0974デフォルトの名無しさん

2012/02/12(日) 00:39:01.31

>>973
そういうのはマ板でやってくれ

0975デフォルトの名無しさん

2012/02/12(日) 00:46:55.04

>>973
仕様書にそこまで書く奴がアホ

0976デフォルトの名無しさん

2012/02/12(日) 00:49:37.36

なんのためのクラスなのか？って考えたことねぇだろうな
元は仕様書にある概念をそのままソースに落とすために
わかりやすいまとまりになんらかの名前が必要だから作ったものだというのに
自分のオナニーの実現のためにクラスを作ってしまっている

仕様書に書いてあるとおりに作ろうとしない
無駄な仕事ばかり増やしてちっとも金にならない
それがデザパタ信者のやる仕事

0977デフォルトの名無しさん

2012/02/12(日) 00:51:45.99

>>976
設計が下手くそだから駄目だしして貰ったんだろ
成長しないタイプだろお前

0978デフォルトの名無しさん

2012/02/12(日) 00:53:57.96

>>977
お前みたいな道具の使い方もわからないオナニー野郎にうける説教なんてないね
バーカ
一生オナニーしてろ

0979デフォルトの名無しさん

2012/02/12(日) 00:54:19.43

>>976
まぁそんな仕様書書いたりそれに基づいて作る仕事でなくてほんとよかったわ(´・ω・｀)

0980デフォルトの名無しさん

2012/02/12(日) 00:55:37.11

>>979
お前の作るもんは仕様書にないような構造が入ってて
仕様書にはないような機能がついてんだろ？
給料泥棒君ｗ

0981デフォルトの名無しさん

2012/02/12(日) 00:56:11.30

>>978
無駄な作業ご苦労さん。下手くそは設計まがいとか背伸びやめたらいいよ
俺の職場はそんな無駄もんは首切られてさよなら～される

0982デフォルトの名無しさん

2012/02/12(日) 00:58:39.52

俺の書くプログラムのクラスは必ず仕様書に出てくる構造と一致してるからな
わかんねーだろてめーみたいな未熟な腕じゃよ

本当のプロは無駄なクラスは一切作らない

0983デフォルトの名無しさん

2012/02/12(日) 01:00:13.99

>>982
プログラムと一体一で対応する仕様書を書く大いなる無駄に気づけないレベルでかわいそう

0984デフォルトの名無しさん

2012/02/12(日) 01:02:24.95

つくる必要のない無駄な仕様書を作り
下手な設計をダメ出しされるのが
本当のプロなんだろ
察してやれよ

0985デフォルトの名無しさん

2012/02/12(日) 01:08:09.31

もうちょっと教えてやろう
俺等の仕事はてめーが思ってるほどクリエイティブな仕事ではない

汎用性云々はさほど重要ではなく仕様書とソースコードが一致していることのほうが１００倍大事だ

まずな
実装技術ってのはそれほど価値がない
それは実装にかかる工数が設計や仕様の決定にかかる時間よりもはるかに短いからだ
つまり口では急げ急げというものの実際は全体の工程からすればクソみたいなもんなんだよ

そんなところにそんな崇高な概念なんて必要なわけねーだろｗ

お前はまず世の中の仕組みが見えていないだから本当に重点をおかなければならないことが見えてないんだ
開発だってただ上から投げられる仕事をこなしてるだけだろ？
だからデザパタなんかにハマっちゃうんだ

0986デフォルトの名無しさん

2012/02/12(日) 01:11:48.94

>>985
> 汎用性云々はさほど重要ではなく仕様書とソースコードが一致していることのほうが１００倍大事だ

この発想に問題を感じ取れな時点で程度が知れる
場違いだから巣にお帰り

0987デフォルトの名無しさん

2012/02/12(日) 01:14:58.97

>>985みたいな化石この時代もまだ生息してたのか
狭い世界に篭ってないで世界観広げた方がいーんでねーの

0988デフォルトの名無しさん

2012/02/12(日) 01:15:37.92

規模と人数によるわな

0989デフォルトの名無しさん

2012/02/12(日) 01:16:06.25

>>941
ダッセーけど型の種類をレコードに持たせて判別するのが一番だと思うよ
データ操作専用のクラスを作ってそういうダッセー部分を外側から隠蔽するのも忘れるなよ

0990デフォルトの名無しさん

2012/02/12(日) 01:27:35.48

>>986
それは汎用性を上げるコードをいれちゃった時点でもう
元の仕様とは一致してないよね？
単にお前の都合で仕様変更に対応できるソースにしたいってだけで

お前問題のすりかえを勝手に脳みそでしちゃうこと多くない？

0991デフォルトの名無しさん

2012/02/12(日) 01:27:45.89

>>989
iteratorやな。だっせーwww

0992デフォルトの名無しさん

2012/02/12(日) 01:29:19.76

確かに内部でどんなに勝手にクラス作ってもいいけど、外に見える部分は仕様どおりじゃないと
大人数でやったときにすりあわないよな

次スレないと不完全燃焼やで

0993デフォルトの名無しさん

2012/02/12(日) 01:31:18.63

>>990
上の方で無駄な作業うんたら言われてただろ
何指摘されてるか1から10まで言われない理解できない程頭こちんこんちんなのな

0994デフォルトの名無しさん

2012/02/12(日) 01:51:20.39

>>990
俺は上の立場だけど、
ちゃんと仕様にデザインパターン含めるよ。
拡張する予定あるのに、拡張性を持たせないわけ無いだろう。
何か問題でもあるの？

0995デフォルトの名無しさん

2012/02/12(日) 01:54:14.57

>>994
マ版な話題はマ版でやってもらうとして
ム版な観点で問題なくはないな
YAGNIに反するだろ？その時になってやればいい

0996デフォルトの名無しさん

2012/02/12(日) 01:56:19.36

>>995
お前、YAGNIを拡大解釈してない？
YAGNIは必要ないものを実装しないってことで、
設計をしないということじゃないんだよ。

機能そのものは設計しないかもしれないけれど、
その機能を追加できるような設計はしておくのが普通。
その上で必要になるまで実装しないのがYAGNIだ

0997デフォルトの名無しさん

2012/02/12(日) 01:58:24.87

>>996
その拡張の予定、というのが結局は未定に過ぎないってことが本質だから
拡張が決まってからで問題ない

0998デフォルトの名無しさん

2012/02/12(日) 01:58:37.87

じすれ
http://toro.2ch.net/test/read.cgi/tech/1328979487/

0999デフォルトの名無しさん

2012/02/12(日) 01:58:49.89

アーキテクチャ先行定義の原則って言葉もあるよね。

1000デフォルトの名無しさん

2012/02/12(日) 01:59:28.13

ランチなんたらってやつか
全てに対して有効な戦略はないっていう

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。