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

と、上司に皮肉られた私である。
実際に、自作の、または参画しているプロジェクトで作成しているPGにオブジェクト設計、デザインパターン
を使っている天才諸君、どうやったら使えるようになるの?
16 :デフォルトの名無しさん2010/05/04(火) 13:45:44
>>1
>大手の上位層の連中しか使わないのが、オブジェクト設計、デザインパターンなんだろうな。

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

 少なくとも派遣主体でころころ人が変わる所、休憩時間にゲームや漫画とか読むのが好きな
人が多い所で、そういう開発を実践できているところはいないなあ。
2 :デフォルトの名無しさん2010/05/02(日) 22:37:59
設計って意図してやると言うより、自然に出来ている物だと思う。
デザパタとかの知識だけ増やしてもあまり意味無い様な…
3 :デフォルトの名無しさん2010/05/02(日) 22:50:45
情報工系の大学生なら普通に使ってるだろ。
とくにデザインパターンなんて単なる「あるある」のマトメなんだから、
天才とかどうとかじゃなくてプログラム書いてりゃ普通に身に付くし、よく考えたら当たり前のことだろ。
ジャカルタがどういう体制で開発してるかしらんが、ぬわんじゃこりゃってAPIのライブラリも結構ある。ぬわーファクトリふぬーファクトリクラスとかな(笑)馬鹿かテメェって感じだわ。
4 :デフォルトの名無しさん2010/05/02(日) 22:57:52
ま、たしかに言葉遊びのようなもんだけど
騙される方も悪いわな
私怨はマ板で
5 :デフォルトの名無しさん2010/05/02(日) 23:49:42
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所
7 :デフォルトの名無しさん2010/05/03(月) 01:58:49
>>5
頼むから、いちいちアイちゃんの言語訓練に2chを使うなよ。
人の迷惑とか考えないの?
京都大学霊長類研究所って無能の集まりなの?
6 :オブジェ・デザパタ2010/05/03(月) 00:11:16
やはり、大手IT企業の天才様はこのようなスレには書き込んでくれないみたいだ。
寝ることにするわ。
8 :デフォルトの名無しさん2010/05/03(月) 02:01:38
アイちゃんが勝手に立てちゃったんだから
許してやって下さい
11 :デフォルトの名無しさん2010/05/03(月) 08:46:49
>>8
PC使わせるなよ、荒らし報告すんぞ
9 :デフォルトの名無しさん2010/05/03(月) 03:03:49
オブジェクト設計&デザパタをやって、何かよくなると期待するのが間違い。
何をしようがよい設計をする人はよい設計をするし、
ダメな人はダメなんだから、良くも悪くもならないものだと考えておくべき
10 :デフォルトの名無しさん2010/05/03(月) 06:52:41
デザパタなんて基礎中の基礎だろ。
デザパタがわかるからといって、うまい設計ができるわけではない。
もちろんデザパタもわからんカスは設計なんてやるべきじゃない。
14 :デフォルトの名無しさん2010/05/03(月) 11:17:07
ほんとうにデザパタを使いこなしているやつらは2ちゃんには来ない。
17 :デフォルトの名無しさん2010/05/08(土) 00:59:12
オブジェクト設計とかwww
デザパタとかwww
オブジェクト指向なんて不自由な環境にいるから余計なものを有難がってるって早く気づけよwww
18 :デフォルトの名無しさん2010/05/09(日) 22:19:16
>>17
大手のSE,プログラマと接触してみる機会をもったら目から鱗です、よwo.
20 :デフォルトの名無しさん2010/05/10(月) 07:07:08
犬子屋作りにオブジェクト設計、デザパタ適用を行う必要はない、と言われている。
そこそこの建物になったら使うべき。ちなみにデザパタは適用なのね。適用≠使用ではない。
レベルの低すぎる人は勉強しよう。という私も低いんだが。。。。
23 :デフォルトの名無しさん2010/09/05(日) 13:54:24
>>20
それはおかしくね?
デザパタは別に、規模の大小に関わらず、
あるよくある問題に対する 伝統的解決法やテクニック的な解答の識別子 であって、
規模が小さいから使えないとか、大きいから有効とかって物じゃない。


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

あと、やたらと一からオブジェクト指向で設計せねば!みたいな印象をうけるけど、
リファクタリングの際についでに、とか、ひとまず最低限の要求仕様を満たしたから
次のステップの前に。とかでスクラップアンドビルド的にやる方がマトモだと思う。
つか、人間に一から完全を求めるのはいい加減やめるべき。 
24 :デフォルトの名無しさん2010/10/14(木) 02:17:36
デザパタはともかく、MVCをまともに実装してるのを見たこと無い。
25 :デフォルトの名無しさん2010/10/15(金) 14:25:38
>>24
まずは、Smalltalk-80のMVCのどこに問題があるのか、そこから語ってもらおうか。
26 :デフォルトの名無しさん2010/10/16(土) 00:40:52
>>25
Smalltalkはいいけど、JavaのMVCとか糞じゃん。
MVCで作りましたってコードは大抵ModelとControlerが破綻してるし。
29 :デフォルトの名無しさん2011/04/10(日) 17:06:14.60
そもそもMVCは糞
30 :デフォルトの名無しさん2011/04/10(日) 17:18:16.54
>>29
kwsk
31 :デフォルトの名無しさん2011/04/10(日) 17:30:50.94
つうか、MVCなんていう30年も昔のフレームワークをドヤ顔で教えて自己満足してるオッサンが
オブジェクト指向の進歩を妨げているのだが、怖くで誰も言えない罠w
35 :デフォルトの名無しさん2011/05/04(水) 23:19:45.18
MVVMってControlerとModelが理解できず、VBのFormとクラス一体のスタイルから抜け出せない馬鹿向けじゃん。

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

 例えばこのコードなら、TextCopy Controlerは、ViewとModelが変わっても使いまわしし続けられるけど、
MVVMモデルだと組み合わせごとにTextCopyを毎度ViewModelやらに書くわけだろバカバカしい。
37 :デフォルトの名無しさん2011/05/07(土) 17:55:55.82
MVPの質問(相談)ってここでいい?

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

たとえば、View上の数値入力欄が ただのテキストフィールドなのか、スピンコントロールなのか、
はたまた スライダーコントロールなのかを、Presenterは知らなくていいよね?
38 :デフォルトの名無しさん2011/05/13(金) 19:38:05.08
知らなくていいと思います。
ただeventから取れる場合はともかく、selfから取る場合には、
実装(というか処理系というか)により適切なコントロールの具象にキャストしないとダメかも知れません。
39 :デフォルトの名無しさん2011/10/02(日) 20:07:07.00
次スレここか?

リーナスのお言葉(青い部分がリーナスの言葉)
http://tabesugi.net/memo/2009/1a.html#152154
41 :デフォルトの名無しさん2011/10/08(土) 19:20:18.35
オブジェクト指向スレは3スレ目位で話題がなくなるな
前あったOOPスレも3スレで終わったし
42 :デフォルトの名無しさん2011/10/08(土) 23:28:11.32
>>41
ちょうど むだなOOPゴミスレも掃除できたし良かったんだよ。
次はここを消費してOOPが消えればいいかも 爆
43 :デフォルトの名無しさん2011/10/12(水) 20:29:02.44
commandやobserverパターンなど、デザパタのうち幾つかは
クロージャとか関数オブジェクトを採用すると不要になったりしないかね?
46 :デフォルトの名無しさん2011/10/12(水) 23:04:40.99
>>43
名前は忘れ去られるかもしれないが、考え方自体はなくなるのではなく、新たな言語パラダイムが作用して、別のパターンがうみだされるんじゃないかな。
44 :デフォルトの名無しさん2011/10/12(水) 20:33:43.47
方法そのものが無くなるわけじゃないけど、
「forループ」にわざわざパターン名を付けないように、
言語レベルで概念が用意されてれば、その世界では
パターン名は不要だね。
45 :デフォルトの名無しさん2011/10/12(水) 20:34:04.98
functional design patternとかでググったら色々要らなくなったよって記事が出てきたはず(英語)
47 :デフォルトの名無しさん2011/10/13(木) 15:19:06.77
オブジェクト指向設計とデザパタを勉強中の者です。
オブジェクト指向設計とデザパタは大手企業はガンガン使いこんでいるが、
一般的には使われていないのではなかろうか? と最近思い始めています。
使えなくて使わないのか、短納期で設計の時間がなくて使わないのか、
いまいち、その辺の事情がわからんです。
まさか必要がないと判断されているのぉ???

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

必要がないならこんな糞難しいものを勉強するのはやめます。
52 :デフォルトの名無しさん2011/10/13(木) 22:44:15.72
>>47
どんな問題があって、それをどのように解決してるのかだけ、ざっくり頭に入れとくといいよ
じっくり学ぶのは必要になってからでいいじゃん
49 :デフォルトの名無しさん2011/10/13(木) 17:15:07.54
頻出問題に対する一般解答
うまいこと言うね

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

オブジェクト指向設計ってのは「設計方針」なんで広く浅く普及してると思うよ
今時のフレームワーク使ってたら自然と(とはいえ漠然と)身についてると思う
50 :デフォルトの名無しさん2011/10/13(木) 18:54:19.07
シングルトン使う奴はテストを考えていないイケヌマだと思う
51 :デフォルトの名無しさん2011/10/13(木) 22:33:30.95
シングルトンはどうでもいいやw
あれはデザインパターンの練習問題みたいなもの。

シングルトンにしたければフレームワーク側で
制御してくれる。
53 :デフォルトの名無しさん2011/10/13(木) 22:48:33.15
> オブジェクト指向設計とデザパタは大手企業はガンガン使いこんでいるが、
> 一般的には使われていないのではなかろうか? と最近思い始めています。

逆じゃね?w

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

中小のほうがよっぽどデザパタ使ってるだろ
自分の技術力が即会社の存続にかかってくるんだから。
56 :デフォルトの名無しさん2011/10/14(金) 15:12:01.84
>>53
取引相手から金貰うやり方にもよるんだと思うよ。
大企業を相手にソースをリリースしていると「何か変更を加えたときに混入するバグ」を恐れて硬直化する。
修正するのに一々マニュアルまであったりしてオーバーヘッドがすごくなる。

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

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

んなことやってるからリファクタリングなんて夢のまた夢って感じだった。
54 :デフォルトの名無しさん2011/10/13(木) 22:59:57.30
有る程度以上フクザツなもんをスッキリ書こうとしたり、
柔軟さをもっと持たせようとしたら悩むっしょ?
糞設計を山ほど繰り返し、日々悩むっしょ?
そこで手に取るもののひとつがデザパタにすぎない。

設計道の一歩目にすぎない。
55 :デフォルトの名無しさん2011/10/13(木) 23:02:08.95
コールバックを関数ポインタとは言わんからな。
ラムダを自然に使えるようになっても、commandだのobserverだの
名前は使われるんじゃね。
57 :デフォルトの名無しさん2011/10/14(金) 15:32:28.38
俺はコメントの修正前のコードを残すルールのある会社の仕事したことある
コメントアウトされた修正前のコードがどっさり
58 :デフォルトの名無しさん2011/10/15(土) 08:04:33.82
>>57
なにかバージョン管理システムを使えばいいのにね。
59 :デフォルトの名無しさん2011/10/23(日) 22:44:02.16
オブジェクト指向設計をきちんと覚えたい。
実際に設計しながら覚えたいんだけど,良い例題(と模範解答)はないでしょうか。

入門サイトを見ると,「1+2*3」みたいなのを計算するプログラムが挙げられたりするけど,
その程度だったら再起関数で済むと思う。
わざわざ演算子のInterface定義して,Plus型MINUS型のcalc()を実行!
みたいなサンプルを見かけるけど全然参考にならない。
60 :デフォルトの名無しさん2011/10/23(日) 23:21:26.98
>>59
優れた設計を学ぶには優れた設計に触れるしか無いが、何が優れた設計なのかは実は誰もわかってない。
オプソにしても何を見て学べばいいのかわからないし。
61 :デフォルトの名無しさん2011/10/24(月) 00:09:47.57
>>59
ひとまずデザパタ見れ。
関数型の考え方などから見ると古かったり必要のないものもあるけど、未だにオブジェクト指向のエッセンス詰まってると思う。
62 :デフォルトの名無しさん2011/10/24(月) 03:03:55.97
>>59
デザパタとリファクタリングは車の両輪
リファクタリングがうまくなったら自然とうまい設計がわかってくる
63 :デフォルトの名無しさん2011/10/24(月) 12:43:31.08
>>59
実例はフレームワークのソース見るといいよ。手始めには辛いかもだけど、javaのcollection frameworkなんてどう?
64 :デフォルトの名無しさん2011/10/24(月) 13:31:22.98
>>62
同意。OOPの理解を深めようとするのなら、その二つはまさに両輪。

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

どこまで行ってもクソ設計を繰り返すことになるだろう。
それは、個人の設計力、設計センスよりもいつだって、
プログラミングすべき問題のほうがややこしいから。
68 :デフォルトの名無しさん2011/10/24(月) 23:46:51.92
デザパタは基礎知識としては重要だけど、それを通して設計を学ぶ類のものでは無いと思う
より上位の設計があって、その設計を実現させるための手段としてデザパタがあるという印象
で、>>59が求めているのはそういう上位の設計なんじゃないか?
65 :デフォルトの名無しさん2011/10/24(月) 22:10:17.46
そうかなあ。
デザパタなんてコロンブスの卵にしか思えんけど。
恐らく散々言い尽くされたことだと思うけど、デザパタには確かに意義があるが、
それは技術サンプルとしての意義じゃなくて、コミュニケーションツールとしての意義だよ。

「ここは○○パターン的な発送で作ってあるよ」と言う事で、意思疎通のコストを縮減できる、
それがデザパタの意義であって、それ以上でも以下でもない。
66 :デフォルトの名無しさん2011/10/24(月) 22:29:47.86
まぁまぁ。そう視野を狭めちゃ勿体無いよ。
騙されたと思ってパターン指向リファクタリング入門読んでみ?
67 :デフォルトの名無しさん2011/10/24(月) 22:32:34.22
>65
今のご時世、プログラミングを始めたときにはすでにデザパタが常識になってたって奴もいっぱいいて、
実際そいつらは、デザパタを通して設計を学んでるわけで

ていうか「意義」をひとつに決めようとする必要ないし
69 :デフォルトの名無しさん2011/10/25(火) 00:00:49.98
俺の見た限りデザパタのカタログ的用法は疑わしい。
なぜなら、多くの人にとってのパターンの理解度が単に疑わしい。
その定義やメリットについてMLなどでわりと揉めちゃってるのを見る。
例えば、JavaHouseのログを見るといい。Factory Methodパターンなど。

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

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

でなもんで、おとなしく学習のツールとして使うのもどんどん推奨されるべき。
70 :デフォルトの名無しさん2011/10/25(火) 00:02:35.14
誰が何から設計を学ぶかは君の決めることではないと思うが
選択肢を増やす意見ならともかく、出た案を否定することに意味はあるのか?
72 :デフォルトの名無しさん2011/10/25(火) 00:22:48.10
>>70
デザパタを学んだことで設計を学んだと勘違いしてしまうと、むしろ害があると思っているから
否定しておきたかったってのはある。

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

代案を出せればいいんだけど、良い方法を自分も知らないから…。
73 :デフォルトの名無しさん2011/10/25(火) 00:30:01.63
>>72
> 害っていうのは、本来はパターンを使わない方が自然であったり、
> 使うべきでないところに無理やりパターンを当てはめてしまうようなことがあること。

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

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

設計&デザパタ&リファクタでもんどりうちながら学ぶ。
いつでも学ぶ。いつでも臭い設計になっちゃうのでまた学ぶ。
悪い設計を目の前にして、右手にデザパタ本、左手にリファクタ本で学ぶ。
75 :デフォルトの名無しさん2011/10/25(火) 00:40:15.32
自分の経験を一般化しすぎるのはどうかと思うが
「俺は綺麗に実装されたテンプレートパターン見たことあるぞ」と言う奴がいれば根拠崩れるぞ

>>73
自分も同趣旨の事書きかけてたけどそっちの方が文章うまいね
631 :デフォルトの名無しさん2011/12/05(月) 03:02:53.59
>>614は中途半端に知識を持ったために、かえって悪くなる典型みたいなコード
>>72の通りだな
71 :デフォルトの名無しさん2011/10/25(火) 00:08:41.30
interfaceの考え方がピンとこなかった初心者が、デザパタを学んでなるほどと思う
またよろこばしからずや
74 :デフォルトの名無しさん2011/10/25(火) 00:30:51.53
きれいに実装されたテンプレートパターンなんて見たことねーよ。
単純に if 分岐で関数切り出しでもされてた方がよっぽど見やすいわ。

テンプレートパターンがうまくいくのは
「具体的には違う処理だが抽象的には同一の処理」の塊が
長く続いてるコードだと思うんだがそんな都合のいいシチュエーションって
そうそうないだろ。
76 :デフォルトの名無しさん2011/10/25(火) 00:50:30.21
>>74
少なくともif分岐はないわ-
テンプレートパターンは、今は具象インスタンスから可変ポイントになるもののラムダを渡して実行って感じになってるがやってることは一緒。
79 :デフォルトの名無しさん2011/10/25(火) 08:16:12.77
>>74
Template Method(の事だよな?)は、Straregyのように同一インターフェースだが、多くの実装のバリエーションがある場合に、骨格抽象実装(スケルトンクラス)として、よく利用している。
(つづく)
77 :デフォルトの名無しさん2011/10/25(火) 02:53:17.39
そもそもデザパタは局所的に使う物でしょ
「この部分は○○パターンでここのこの部分は…」みたいな
使える所があれば使えばいいし、出番が無いこともある

そういうものなんで、リファクタリングしながら適用するのはいいと思う
81 :デフォルトの名無しさん2011/10/25(火) 09:48:44.85
>>77
>そもそもデザパタは局所的に使う物でしょ

デザパタに出てくるものってソフト全体に絡むと思うぞ。大きいものから小さいものまで。
その意見をとやかくいうのではないけど、そういう捉え方をする人がいる人にビクーリした
78 :デフォルトの名無しさん2011/10/25(火) 07:45:12.50
色々アドバイスありがとう。
デザパタについては,浅く理解していると思う。
ただ,デザパタを実際の設計に結びつけれるほどは理解していない。
結びつけられるようになればレベルアップのような気がして,
まずはデザパタも含めて「良い設計」の実例を見てみたかった。

JavaのCollectionFramework参考にしたいと思う!
他にも何か良い例があれば教えて下さい。
80 :デフォルトの名無しさん2011/10/25(火) 08:18:00.91
例えば、呼び出し元からメソッドの最後で実行して欲しいコールバック関数が渡された場合に、
全ての末端のクラスでnullチェックして、実行って記述すると冗長なので、共通部分をスケルトンクラスに移管させ、
バリエーション記述のためにprotectedなabstractメソッドを用意しておく。
末端のクラスはこの抽象メソッドを実装するといった感じで。

これに限らず、「インターフェース ー スケルトンクラス ー 実クラス」という形は結構でてくるものよ。
82 :デフォルトの名無しさん2011/10/25(火) 09:57:35.71
デザインパターンを構成要素としてより大きなパターンが出来てるだけじゃないの?
アーキテクチャパターンとか聞いたことない?
83 :デフォルトの名無しさん2011/10/25(火) 10:23:46.45
ぶっちゃけ言うとデザパタもアーキテクチャパターンも本質は同じだと思ってる。
両者を明確に区別すべき理由はないでしょ。
84 :デフォルトの名無しさん2011/10/25(火) 10:32:18.95
コードから出てきたのがデザパタ
コード書かずに図を弄ぶのがアキパタ
86 :デフォルトの名無しさん2011/10/25(火) 20:09:48.47
リファクタリングを繰り返して物凄く汎用性高い設計
あまりレベルの高くないプロジェクトメンバーでも長期に渡って保守可能な設計

これらは両立しなくてどっちも大事だと思うんだけど,両方上達する方法ない?
87 :デフォルトの名無しさん2011/10/25(火) 20:32:03.03
物凄く汎用性高い設計なんてものを、
まずお目にかかったことが無いw
88 :デフォルトの名無しさん2011/10/25(火) 21:02:02.72
リファクタリングなんて必要なとき必要なだけやれば十分、汎用性なんて気にしなくていい
長期に渡って保守しておいてレベルの低いままのメンバーなんて切ればいい
下手糞が保守できるからいいソースとは限らない

→どっちも大事じゃない
89 :デフォルトの名無しさん2011/10/25(火) 21:08:22.36
>下手糞が保守できるからいいソースとは限らない

ココロに響くお言葉
90 :デフォルトの名無しさん2011/10/26(水) 15:29:24.80
せっかく保守・拡張しやすいように考えて書いたソースでも
それがわかんない人はどういう変更してくるかマジわからんし。

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

俺「そこはサブクラス追加だけで良いですよ、そういう風に変えたら広範囲に悪影響あります、…(しばらく駄目出し)」
先輩「…全然駄目ですか」
俺「駄目駄目です」
91 :デフォルトの名無しさん2011/10/26(水) 15:58:40.97
>>90
それは先輩もあれだが、正しくドキュメントとか残したん?
95 :デフォルトの名無しさん2011/10/26(水) 21:16:31.08
>>91
>92-94が正にそん時の状況を表してるw
一応、設計中に作成したメモ書きよりは上等程度のんは残してたけど。

まさか数キロステップ程度のプログラムで悩まれるとは思わんかったし、
彼もOCPとLSPが分かってたらやっちゃいけない事くらい分かったろうし…。
他にやる事あったのにそこまで面倒見切れんかった。
92 :デフォルトの名無しさん2011/10/26(水) 16:36:25.67
設計思想ってのはドキュメント化しにくい上に工数認めてもらえないこと多くね?
93 :デフォルトの名無しさん2011/10/26(水) 16:54:45.34
コメントで「〇〇〇パターン使ってます」って書いときゃ大体伝わる。

と思ってた時期が以下略 
94 :デフォルトの名無しさん2011/10/26(水) 17:11:32.92
>>93
(ヾノ・∀・`)ムリムリ
96 :デフォルトの名無しさん2011/10/27(木) 00:40:23.24
そういうのは実際にコードを見てみないと何とも言えない
その先輩のようにOOに疎い人は確かに多いんだけど
自信ありげに語ってる側もまた酷いコードを書いてることが多い
98 :デフォルトの名無しさん2011/10/27(木) 05:51:20.24
自信満々でコメントの一切無いソース見せられたことある
しかも変数名や関数名は母音抜き
99 :デフォルトの名無しさん2011/10/27(木) 06:31:09.36
>>98
コメントはちょっと扱いが難しい。コメントが嘘をつくことがあるから。
つまり、コードの改変にコメントが追いつかないことがある。

コメント書かないほうがまし、と思うことが最近多くなってきた。
100 :デフォルトの名無しさん2011/10/27(木) 07:32:32.83
>>90
下に合わせてもキリがないのはすごく分かる。
設計思想を理解してもらう部分にコストが掛かるから難しい。
作り手は工数かけてドキュメント作成しなきゃいけないし,
その後も更新に合わせて整備しないとぐだぐだになる。
かといってドキュメント残さないで設計思想を安定して読み解ける人は
安定供給されないw

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

>>99
それ凄く多い。
あと少し違うかもしれないけど,
顔合わせない派遣さんとかが付けたSVNのコメントも混乱の要因になったりする。
103 :デフォルトの名無しさん2011/10/27(木) 13:31:26.33
>>99
コード直すときにコメントも直すだろ

コードと一緒にコメントも直す習慣が無いやつが書いた
ワードやエクセルのドキュメントなんて信用できるのか?
104 :99 ◆QZaw55cn4c 2011/10/27(木) 20:53:18.37
>>103
根本的解決になっていない。
コメントがコーダに及ぼす影響を考慮すると、コードの内容に即したコメントになっているかどうかをコンパイラがチェックできなければならない。
それができないのならばコメントはいらない。

コード直すときにコメントも直すだろ、という精神論は竹槍でB29を落とし、バケツリレーで焼夷弾を消火せんばかりの旧日本軍的思考となんらかわりない。
105 :デフォルトの名無しさん2011/10/27(木) 21:16:08.44
>>104
心情的に同意したくはあるんだけど、もうちょい穏やかな言い方にならん?

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

…ってオブジェクト指向もデザパタも関係ない話になってきてね?
106 :99 ◆QZaw55cn4c 2011/10/27(木) 21:33:37.10
>>105
失礼しました。ただ >>103 にあわせるとこうなってしまいました。(私の本音は >>99 を参照ください。)
101 :デフォルトの名無しさん2011/10/27(木) 08:57:01.35
シンプルって俺は「同時に憶えておかなければならない範囲が少ないこと」としておくけど、
オブジェクト指向原則ってプログラムをシンプルに保つためのもんだよね。
LSPに沿っていれば、あるインターフェースでオブジェクトを扱う使用側は個々の具象クラスの事に気を使う必要はない、とか。

シングルタスクで記憶容量の少ない、低クロックCPUの俺のような奴にこそオブジェクト指向原則は必要だと思う。
それに沿って作られてるだけで頭に掛かる負担が全然違うし。
102 :デフォルトの名無しさん2011/10/27(木) 08:57:10.40
コメントもなーw

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

↑こーいうw
107 :デフォルトの名無しさん2011/10/27(木) 21:43:40.97
自分の書いたコードを読むのが、コメントなしでもコードの意図を汲み取れる人だけなら
コメントなんて書かなくてもいいんじゃね

レベルの低い奴が修正する可能性があるってわかってるのにコメントを書かないのなら、
設計思想を無視した修正をされても黙ってろってかんじ
108 :デフォルトの名無しさん2011/10/27(木) 21:54:55.95
QZらしからぬ煽り耐性の無さだなw
宿題スレで金儲けはもうやらんの?
131 : ◆QZaw55cn4c 2011/10/30(日) 14:00:52.26
>>108
金儲けじゃありませんモリタポ儲けです(棒)
109 :デフォルトの名無しさん2011/10/27(木) 22:16:28.03
コメント付けただけでレベル低い奴が無茶苦茶すんのを阻止できるとでも?
そもそも設計思想なんてコメントで残すものでもない。
111 :デフォルトの名無しさん2011/10/27(木) 23:24:58.23
リファクタリングしてるとクラス自体が出来たり無くなったり、
結構ダイナミックに変わると思うけど
112 :デフォルトの名無しさん2011/10/28(金) 00:11:54.25
そういう場合は丸ごと消したり付けたりするから嘘を付いてるような状況にはなりにくくないか
114 :デフォルトの名無しさん2011/10/28(金) 00:34:37.01
コメント無いと他人がみても何やってるかわからない様なプログラム書けてこそのプログラマーだろ?
誰でも読める様なソースはプログラムじゃなくて、だだのマクロだよ。
115 :デフォルトの名無しさん2011/10/28(金) 02:30:42.77
釣り針は置いといて、俺はむしろ自分のためにコメントを書くぞ。
そのほうがトータルコストは低くなる。ソースの頭に色々と関連した前提を長々と文章で書いてる。
あとはややこしいところに一目でわかるように意図を書いてる。
117 :デフォルトの名無しさん2011/10/28(金) 07:46:15.80
>>114
職人的発想だね。
商業漫画家の中にアマチュアだけど物凄い技術ある漫画家が混じってくるような感じ。
商業的な観点で保守性考えたときに,果たして最良のコードかどうかをよく考えた方が良いと思う。
考えた上で最良と判断したならそれでいいだろうけど。

>>115
それで上手くいくかは何人でコード書いてるのかによると思う。
「自分のためのコメントだから!」とか言って15人ぐらいがそれぞれ我流のヘッダ付けて
我流のコメント入れてたら嫌だね。
116 :デフォルトの名無しさん2011/10/28(金) 07:45:26.37
トータルのコストで考えないとね
必ず書くとか絶対書かないとか、ただの思考停止
118 :デフォルトの名無しさん2011/10/28(金) 14:56:12.47
15人が一つのソースいじるような案件なら
コーディング規約にコメントルールもある…よな?
119 :デフォルトの名無しさん2011/10/28(金) 16:00:05.09
コメントなんてそこで何やってるかの意図がわかればいいんであって、一目見ればわかるような関数に定形でパラメータが何だ戻り値が何だとか書くのも書かせるのもやめていただきたい。
少人数で開発できて幸せだわ。
軍曹みたいな現場に放り込まれたら一日で切れそうだw
120 :デフォルトの名無しさん2011/10/28(金) 21:39:27.42
前んとこで抽象クラスを介していろんな具象クラス同士が緊密に結合してるプログラム見て発狂しそうになったよ。
どのクラスも単独で使えなくて、CppUnitとか全然入れられないの。
単体も組み合わせも全てIDEでステップ実行のホワイトボックステスト(それしか出来ない)で、
自動化?なにそれ?みたいな感じ。
129 :デフォルトの名無しさん2011/10/30(日) 10:39:33.84
>>120の言ってる自動化は
自動生成のことじゃないだろ
132 :デフォルトの名無しさん2011/10/31(月) 23:12:36.75
>>129
あー、うん。用意した一連の単体試験をガーッと実行させてOK/NG出させるのを自動化って言ってた。

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

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

みたいな試験仕様書を延々とVC++のステップ実行&ウォッチで目視確認してたもんで。
121 :デフォルトの名無しさん2011/10/29(土) 18:52:41.79
テストが自動化できるような部分て、自動生成できるような機械的なコードの部分だから、テストの自動化で大幅に生産性が上がるシステムはそもそもコードの記述が冗長で糞。
122 :デフォルトの名無しさん2011/10/29(土) 23:09:03.35
自動化プログラムの下の世話のが手間かかるんだよな
「あ!止まった!」
とか思ってもだいたい自動化プログラムのエラーだったりねw
123 :デフォルトの名無しさん2011/10/30(日) 08:04:36.83
> テストが自動化できるような部分て、自動生成できるような機械的なコードの部分

へー、ユニットテストっていつ自動生成できるようになったの?
125 :デフォルトの名無しさん2011/10/30(日) 09:45:52.75
>>123
UWSCとかbot御用達の技術
企業だとユニットテストに使われてる
130 :デフォルトの名無しさん2011/10/30(日) 10:56:45.44
>>125
自動生成じゃない
124 :デフォルトの名無しさん2011/10/30(日) 09:36:47.46
単体テストを自動生成するツールは存在するよ
ttp://www.techmatrix.co.jp/quality/ctest/index.htm
ttp://www.aicp.co.jp/products/cantata.shtml
とか。

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

でも、そんなツールをどこの職場でも導入しているかつーと話は別だよね。
前んとこは結構大企業だったが、そんなツール導入はしてなかった。
126 :デフォルトの名無しさん2011/10/30(日) 09:48:44.01
あ、ごめん。lが抜けてた。
ttp://www.techmatrix.co.jp/quality/ctest/index.htm
127 :デフォルトの名無しさん2011/10/30(日) 09:52:04.88
>>126
なんかどこおしてほしいのかわかんない
わざわざh抜く必要もないんじゃない
それかGoogleで先頭に出るキーワード貼ってよ
128 :デフォルトの名無しさん2011/10/30(日) 09:58:02.60
度々すんません。最後の小文字Lが全角になってたようで。
http://www.techmatrix.co.jp/quality/ctest/index.html
でした。

それぞれ
C++test
Cantata++
でググレば出てきます。
133 :デフォルトの名無しさん2011/11/01(火) 22:44:42.89
FORTRANでもできそうな、スレタイと全く関係ない流れだな・・・
134 :デフォルトの名無しさん2011/11/02(水) 08:56:32.89
しまった。スレタイに関係ある話題に引き戻そうとネタ振ったのに…

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

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

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

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

スケジュールに「リファクタリング」の文字が組み込まれ、
そのための打ち合わせが増えた。
135 :デフォルトの名無しさん2011/11/03(木) 01:11:46.70
アホくせ
もう十年以上PGやってるけど業務のソースみるとなにが「いい」のかまったく基準がわからない
俺の個人的な基準だとwin32レベルの知名度のあるライブラリでもないのに
グローバル変数や関数使った時点でアウトだけど
平均レベルただよってるレベルのひっくいPGじゃ俺のいってることさっぱりわかんねーだろーな
141 :デフォルトの名無しさん2011/11/05(土) 08:16:43.72
>>135の言い方だとwin32くらい知名度のある場合は、グローバル変数を使って良いということか?
よくわからん・・・

コンパイラが必要だな
142 :デフォルトの名無しさん2011/11/06(日) 00:51:07.47
>>141
おう、いいぜ
仕様も挙動もみんなが把握している場合に限りなんでもオッケーだと思う
ただし、マイナー・・・特に自分ライブラリなんてそんなもん誰もしらんから自重してほしい
136 :デフォルトの名無しさん2011/11/03(木) 01:52:47.80
コードレビューとか長年やってるだろうに説明下手すぎ
そのレスでわかれっつー方が無理

エスパーしてみるけど、
・135は知名度の低いライブラリの開発に従事している
・そのライブラリはグローバル変数や関数を使っている
でおk?
137 :デフォルトの名無しさん2011/11/03(木) 02:16:14.66
>>136
アホくせ
わからないなら黙ってろよ
わからないんだろ?
138 :デフォルトの名無しさん2011/11/03(木) 10:25:28.48
放っておけ
文章から知性の低さが滲み出てる上に
俺のエスパーによるとオブジェクト指向とは関係ないから
139 :デフォルトの名無しさん2011/11/03(木) 12:41:57.54
オブジェクト指向スレでWin32とか言ってる時点でお里が知れる(´・ω・`)
148 :デフォルトの名無しさん2011/11/06(日) 21:11:38.87
>>139
横レスするが、WinAPIも一応OO標榜してたんだぞ。

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

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

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

SendMessage( button WM_GETTEXT, ・・・略・・・ );
SendMessage( windown, WM_SETTEXT, ・・・略・・・ );
143 :デフォルトの名無しさん2011/11/06(日) 09:20:08.66
クラス図とかシーケンス図とか作成している人、このスレにいますか?
いないような気がするのですが。
149 :デフォルトの名無しさん2011/11/06(日) 21:18:02.54
>>143
打ち合わせに使う。
144 :デフォルトの名無しさん2011/11/06(日) 10:11:17.72
クラス図は、ある程度コードを書いた後にリバースで出力します。
シーケンス図は客から要求されない限り書かないですね。

実装レベルでは、素直にコールグラフをスケッチする方が分かり易いと思ってます。
シーケンス図はその名のとおり呼び出しの時系列を追えるところがよいのだと思いますが、
ごく普通に構造化されたコードなら、ほとんどの場合「シーケンス」は一目瞭然。
図を描かなければ理解しにくいのは、むしろ深い呼び出しの階層構造だと思います。
145 :デフォルトの名無しさん2011/11/06(日) 11:48:19.80
>>144
サンクスです。
クラス図をリバースで出力します、にはクラス図重要視派の私には、ショックです。
147 :デフォルトの名無しさん2011/11/06(日) 16:25:13.86
オブジェクトが動的に増えないプログラム(組込み)なんかだと
クラス図はわりとどうでもいいと感じるようになるね

シーケンス図は真面目にやると大変だけど重要だと思う
150 :デフォルトの名無しさん2011/11/07(月) 01:03:35.48
こういうことってない?

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

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

妙なモッチャリ固まりクラスの使用を、
ライブラリ利用者に強いるのって結局のところ濁らせてるだけ。
151 :デフォルトの名無しさん2011/11/07(月) 02:34:17.79
>>150
高速検索様に、こういうのならあるが。
ま、違うか。

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

row = new Cell();
columnA.add( row );
columnB.add( row );
columnC.add( row );
152 :デフォルトの名無しさん2011/11/07(月) 10:56:11.58
>>150
「a、b、cが常に一塊で無いとマズい」と言うデータ構造を表現するなら前者だな
コードの最適化はデータ構造を破壊しがちだよ
154 :デフォルトの名無しさん2011/11/10(木) 00:59:52.83
(Windowsアプリの)プラグインのフレームワーク作ろうとしたら頭こんがらがってきた
本体アプリから呼ばれる部分のパッケージ(Base)は一番安定している筈。
で、プラグイン固有機能を実装するパッケージ(Derived)はBaseに依存している。
ここまではいい。

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

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

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

別のプラグイン作成でBaseを流用したとき、毎回この関数を修正するのは変な気がするんだけど…。
上手く説明出来てなかったらすんません。
159 :デフォルトの名無しさん2011/11/11(金) 08:21:25.93
>>154
どうでもいいが、フレームワークをどういう意味で使ってる?
ただのオレオレクラスライブラリじゃないのか。
155 :デフォルトの名無しさん2011/11/10(木) 01:21:33.15
そこでなんでDerivedとして継承してるのかしらんが、DerivedはInterfaceのImplementとしてそのImplementしたクラスをリフレクション的に登録、Base的な部分では実際の中身は知らないインジェクトされたinterfaceを使ってCreateすることでDerivedのinstanceを作ればいい。
今の設計はBaseがDerivedを知ってる時点で間違ってる。
156 :デフォルトの名無しさん2011/11/10(木) 01:46:17.45
BaseがDerivedを知ってるのが間違ってるのくらいは良く理解してる…。
上の例で、DerivedPluginとして“やむを得ず”使ってしまってるのが唯一のADP違反部分で、
他の部分にはそういうところはなし。

問題は例のところで生成すべきクラスをどう指定すべきだったのかというところ。
解決法を>155で書いてくれてるんだろうけど、
「リフレクション的に登録」とか「インジェクトされた〜」とかが良く分からん。
157 :デフォルトの名無しさん2011/11/10(木) 12:06:57.02
>>156
new DerivedPluginとしてるところは、DerivedPlugin自体を知ってる必要はなく、IPlugin的なインターフェースを持つ何かだよね?
だとしたらその場で作成するIPluginである何か(DerivedPlugin)についてどこからか登録すればいい。
それは設定ファイルなり、プラグインが登録されている指定されたフォルダを全部舐めることで動的に登録するなりやり方は色々。

登録する・・・がインジェクトと言ってたものであり、リフレクション・・・と言ってたのはフォルダを舐めて・・・の部分。
DependencyInjectionとかでしらべたまい。
158 :デフォルトの名無しさん2011/11/10(木) 12:57:50.68
> new DerivedPluginとしてるところは、DerivedPlugin自体を知ってる必要はなく、
> IPlugin的なインターフェースを持つ何かだよね?
そうです。実際の操作はインターフェースによってのみ行うようにしてる。

> それは設定ファイルなり、〜
ああ、なるほど。
依存性をソースファイル外に追い出すってことか。ありがと!
163 :デフォルトの名無しさん2011/11/12(土) 15:16:36.36
>>158
そもそもエントリーポイントを何でBaseに入れる必要があるんだ?
エントリーポイント用意して毎回吐かせりゃいいじゃねぇの?

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

// DLL毎に記述
void Plug::Export( Register ®ister )
{
       registry.Register( "Alpha", new Plugin() );
}
160 :デフォルトの名無しさん2011/11/11(金) 08:34:17.70
基本、枠組みはそのまま使って必要部分を拡張するやつ
主:フレームワーク、従:拡張部分

作ろうとしている段階なので現状そこまで行ってなくて、
オレオレクラスライブラリであるのは間違いないけど。
機能拡張が一定のやり方で出来ないようなら
それはそれでクラスライブラリとして完成させてもいいし。
162 :デフォルトの名無しさん2011/11/11(金) 11:03:36.00
GOF本にはそう書いてるだけだけどね。
「本にそう書かれてるから正しい」なんて言うような原理主義者でもないけど
異議を唱える程の自己主張も無いし。
164 :デフォルトの名無しさん2011/11/23(水) 12:07:51.02
インターフェースの設計はどういう観点から行うのが有効なのでしょう。

170 :デフォルトの名無しさん2011/11/23(水) 17:53:24.78
>>164
既存のライブラリ群を見て、 「どういう物がインターフェースとして実装されているか」 を考えれば解るんでない?
例えば、C#の IComparable とか。
165 :デフォルトの名無しさん2011/11/23(水) 13:02:47.92
そのインターフェースが表すものが備えてるものを備えてるようにすることかの。
166 :デフォルトの名無しさん2011/11/23(水) 14:17:45.35
>>165
それって、どの本にも書いてあることだの。その先が知りたいのに。ムカッ。
169 :デフォルトの名無しさん2011/11/23(水) 16:51:34.57
>>166
必要に迫られて自分でやらなきゃ分からんよ
伝聞はすぐ忘れる
167 :デフォルトの名無しさん2011/11/23(水) 16:07:10.50
じゃぁプログラム構造の中の空間的分割を行うための変換子として扱えばいいよ。
168 :デフォルトの名無しさん2011/11/23(水) 16:47:11.93
逆に言うと公開しないものはインターフェース以外って事でしょ
外部から実行出来る(依頼とか操作とか)ようにするものは何か? = インターフェースだよね
必要なものだけにしときます

まぁポリモーフするからってインターフェースを考える場合もあるけど
171 :デフォルトの名無しさん2011/11/23(水) 19:13:08.94
使う側で考えて、その結果インターフェースにしたほうが早い。
しょっぱなからインタフェース書くんじゃなくて、例えば、下みたいな
呼び出しコードを書いてみてから、どうすればキレイにできるか考える。

RuleSet rule = new Required( new Number( new Min( 0 ), new Max( 100 ) ) );
rule.validate( textbox, "透明度" );
172 :デフォルトの名無しさん2011/11/24(木) 21:26:20.01
>>171
さっぱり、わからん。
ちなみに、本などに書かれているのだが、「設計段階でインターフェースの抽出を行いましょう。」
っていうのは、>>171と真逆な感じがする。
173 :デフォルトの名無しさん2011/11/24(木) 21:37:46.47
>>171じゃ無いが
最初は、インターフェースとか全く考えずにプロトタイプを作る。

んで、プロトタイプを捨てて再設計する段階で
インターフェース化出来る部分が有るか、ついでに検討する。
175 :デフォルトの名無しさん2011/11/25(金) 14:47:02.03
>>172
プロトタイプを製作してみて、その傾向から設計を引き直してインターフェースを導出するって事なんかね?>>171のはさ。
176 :デフォルトの名無しさん2011/11/25(金) 15:44:52.10
>>175
作成まではしなくてもいいんじゃないかな
「他のクラスからどう呼ばれると自然か?」って方向の
思考実験してみるだけでも良いかと
177 :1712011/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をチェックしてる。
174 :デフォルトの名無しさん2011/11/25(金) 02:25:57.56
まぁ両方からだね。
最初から個々はインターフェースにナイスにまとめられるよねって分かる部分と、作ってるうちにここをインターフェースにまとめたらナイスにまとまるんじゃね?ってのと。
だんだん前者が多くなってくると思われ。
178 :デフォルトの名無しさん2011/11/25(金) 23:24:14.50
textboxをチェックといわれても曖昧だな。
結局、使う側がいっぱい学習しないといけなさそうなインタフェースだよなそれ。
179 :デフォルトの名無しさん2011/11/25(金) 23:44:40.37
実際はtextboxじゃなくString型のモノをそのまま渡すんだけどね。
TextBoxの入力チェックの方が解りやすいかと思ってtextboxとは書いたけど。
180 :デフォルトの名無しさん2011/11/25(金) 23:49:24.00
理解するのに15分も掛からなそうだが・・・。そんなに学習がひつようか?
181 :デフォルトの名無しさん2011/11/26(土) 01:10:33.19
リファクタリングもデザパタもsmalltalkerなんだよな。おめーら
smalltalkerに足を向けて寝るんじゃねーぞ。
183 :デフォルトの名無しさん2011/11/26(土) 09:33:08.95
っていうか、このスレに出現している椰子はオブジェクト指向設計を
やったことがない者ばかりじゃないだろうか?
インターフェースは、設計の段階でほぼきっちりと把握できる。
リファクタリングは、納期に迫られて設計不十分で見切り発車したプログラムを
あとから見直す場合に行うと考えたほうがよい。

ああ、やはり大手IT企業の中央部署の人しかオブジェクト指向設計をやっていないことがわかった。
っで、このスレに来る椰子は末端のプログラマだけだね。まあ、テクニックだけは高い人もいるようだが。
184 :デフォルトの名無しさん2011/11/26(土) 09:36:50.63
>>183
末端のプログラマがオブジェクト設計しなきゃいけないプロジェクトはその時点で終わってる。
188 :デフォルトの名無しさん2011/11/26(土) 09:49:05.51
>>183
っ[ アジャイル ]
っ[ スパイラルモデル ]
っ[ プロトタイピング ]
っ[ TDD ]
190 :デフォルトの名無しさん2011/11/26(土) 12:14:21.53
>>183
オブジェクト指向設計やったことある?

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

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

ドメインモデルはなんか設計がガチガチで柔軟性がないか
柔軟性を保つために何度も再設計をすることになりそう。
191 :デフォルトの名無しさん2011/11/26(土) 12:23:08.40
>>190
クラス図設計とシーケンス図設計のみ。
ドメインモデルとトランザクションスクリプト。ふん、なんか言葉では見たか、聞いたかかもしれないが
あまり気にしてない。
クラス図を作成するのが大変だった。特に、インターフェースを抽出するのがね。

192 :デフォルトの名無しさん2011/11/26(土) 12:27:00.57
>>191
話にならんな。

シーケンス図はオブジェクト指向と全く関係ないし、
クラス図はUMLの中で一番使えないものとされてる。
クラス図はコードのクラス定義そのものだからね。
193 :デフォルトの名無しさん2011/11/26(土) 12:31:05.13
>>192
言い過ぎだろう。
196 :デフォルトの名無しさん2011/11/26(土) 12:59:53.64
>>193
横レスであれだが、決して言い過ぎじゃないと思うぜ…
186 :デフォルトの名無しさん2011/11/26(土) 09:41:13.32
一昔前(2000年初頭)の苦い経験から、末端側がそれほどオブジェクト設計を意識しなくていいような、フレームワークという概念が台頭してきたんだよ。
187 :デフォルトの名無しさん2011/11/26(土) 09:45:08.44
Sunは設計不十分で見切り発車で作ってたから
Javaなんてdeprecatedなメソッドが盛り沢山。
194 :デフォルトの名無しさん2011/11/26(土) 12:38:39.14
クラス図なんか、コードを書きながら設計すれば良い。
これは手抜きではなく、試行錯誤だ。

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

メソッドを親クラスに移動したり、反対に子クラスに移動したり、
コードをまとめたりといった作業のコストは低い。(言語と開発環境によるが)
195 :デフォルトの名無しさん2011/11/26(土) 12:44:09.05
クラス図のなにが悪いかって書くのが面倒な上に、
ソースコードから生成できるから意味が無いってこと。
マウスでポチポチやって図を書くよりもコードを書くほうがはるかに楽。

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

ソースコードからクラス図を生成するようにしておけば
クラス図とソースコードに違いが出ることもない。
205 :デフォルトの名無しさん2011/11/26(土) 14:51:32.15
>>195
オブジェクト図で叩き台作って、クラス図を作ってチームで打ち合わせしとくと、
コード書き始めるより遥かに出戻りが少なくなるぞ。
208 :デフォルトの名無しさん2011/11/26(土) 15:04:41.92
>>192
> クラス図はUMLの中で一番使えないものとされてる。
されてないし、されてる訳がない。通常、最も多く使われるのがクラス図。
いったいどこの誰がこんな馬鹿げたことを言っているのか…

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

ていうかドメインモデルとトランザクションスクリプトを持ち出すならせめて
DDDくらいは読んでおけよ。いろいろと酷過ぎる。
235 :デフォルトの名無しさん2011/11/26(土) 21:04:56.20
インターフェースを理解できないやつはJava The Good Partsの型システムの章を読め
少ないページでどう利用するのかがすぐにイメージできる

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

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

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

あとオブジェクト指向語るならリファクタリング本も必須
198 :デフォルトの名無しさん2011/11/26(土) 13:31:29.13
そもそもクラス図を作ったところで使う機会が無いというのが最大の問題点じゃないか
クラス図の役割って殆どIDEでカバー出来ると思う
199 :デフォルトの名無しさん2011/11/26(土) 13:42:57.53
プログラミングを単なる実装と思ってしまうから、
実装の前に設計が必要だと思ってしまうんだよ。

メソッドの中身までは書かなくてもいいが、
設計をコードでクラス定義として書くほうが
柔軟で書きやすい。
200 :デフォルトの名無しさん2011/11/26(土) 14:26:18.01
やり方は色々だろうけど。

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

だから俯瞰する能力が高くてシーケンス図なんざ書かなくても
協調が把握できる人なら、クラス図は要らない、というか
まぁそもそもそんな仕事で良ければアーキ設計書もUMLも要らないという話だが、
世の中の開発者はそんなスーパーマンばかりではない。
201 :デフォルトの名無しさん2011/11/26(土) 14:33:11.22
>>200
誰も、シーケンス図が無駄とは言ってない。
シーケンス図はオブジェクト指向と無関係だということ。

あと、シーケンス図はクラス図と関連はない。
206 :デフォルトの名無しさん2011/11/26(土) 14:52:42.47
>>201は、いろいろと知らなさすぎる。
何をかじっているのだろう。
202 :デフォルトの名無しさん2011/11/26(土) 14:43:11.21
他人のプログラム読む場合
シーケンス図があるとないとで全然違う
203 :デフォルトの名無しさん2011/11/26(土) 14:44:44.04
シーケンス図が必要なほど呼び出し順が入り組んでるものはいやだ。
207 :デフォルトの名無しさん2011/11/26(土) 14:59:08.67
ユースケース毎にシーケンス図があると間違いが起きにくいよ
209 :デフォルトの名無しさん2011/11/26(土) 15:05:39.39
ユースケースは使わない。ユースケースは無理やり考えられた代物に思われる。
213 :デフォルトの名無しさん2011/11/26(土) 15:27:05.16
フローチャートとシーケンス図はまったく必要ないと思うけど
クラス図は結構好きだけどな

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

まあ、詳しい処理の話になったらクラス図の出番はないけどねw
214 :デフォルトの名無しさん2011/11/26(土) 15:29:08.27
厳密に書くと役に立たない(線が多すぎて解読不能)
あくまで説明用に対象のクラスがざっと書いてあるレベルで役に立つ
215 :デフォルトの名無しさん2011/11/26(土) 15:37:29.40
図の上の方に他への依存性が低いクラスを書き、
図の下に行くに連れて他への依存性の高いクラスを書くとか
お前等はしないのか?
キレイに上下依存関係が別れないクラスは、インターフェースに分割したり、
機能的に類似性が高いクラスはインターフェースを統一したりとか、
打ち合わせで図を見ながら考える事はあるだろうに。
やっぱ派遣だとそんな打ち合わせする暇はないのかね。
216 :デフォルトの名無しさん2011/11/26(土) 15:49:27.47
ないな
そもそも仕様書に出てくる用語以外のクラスを作成しちまうとやたら詳しく説明を求められるから
そういう変なクラス作らないし
218 :デフォルトの名無しさん2011/11/26(土) 15:50:18.34
>>216
仕様書が完璧ならそれでいいんだけどねw
220 :デフォルトの名無しさん2011/11/26(土) 15:51:54.16
>>218
その場合は仕様変更だからちゃんと工数もらえるから時間とっていいんだ
そこを吸収してやるようには作らなくていい
217 :デフォルトの名無しさん2011/11/26(土) 15:49:44.26
ウォーターフローモデルでの開発では
必須というだけの話。

アジャイルなら変化しながら開発が進む
219 :デフォルトの名無しさん2011/11/26(土) 15:51:05.71
いや、下位工程に回す前に、上位工程では完璧に作るのは常識でしょ。
じゃないと、下位工程でバグが見つかって上位工程に戻すと工数がかかり過ぎる。
221 :デフォルトの名無しさん2011/11/26(土) 15:52:23.77
やっぱ自社で1システム受注できないところは、OO開発は向かないのな。
そりゃUML使えないと言ってても仕方ないか。
222 :デフォルトの名無しさん2011/11/26(土) 15:58:40.69
お前等、基本設計から納品まで出来る企業に転職したら?
自社でライブラリすら持ってなくて、スクラップアンドビルド
ばっかしてる仕事は、穴埋め囚人みたいで辛いだろ。
223 :デフォルトの名無しさん2011/11/26(土) 16:01:48.46
てか、大手も実装工程は作り直しても大して時間とらない(=金かからない)ってことに気がついてるから
わざわざ開発手法にまで手を入れてこない

仕様決めとかそっちのが時間かかるからなぁ
224 :デフォルトの名無しさん2011/11/26(土) 16:13:30.36
大手は、そもそも案件を下請けに投げるだけだろ?
営業から納品までやってんのは大概中小企業じゃね?
225 :デフォルトの名無しさん2011/11/26(土) 16:14:41.71
そうなると基本設計から納品までなんて会社はないんじゃないか?
226 :デフォルトの名無しさん2011/11/26(土) 16:18:42.92
ウチの会社はやってるし、ライバル会社もやってるから、結構いる筈。
自社パッケージ持ってるのが、一括受注できる原因だろうけどね。
228 :デフォルトの名無しさん2011/11/26(土) 16:21:20.04
>>226
大手からすると無駄が多いって考えだろうな
基本的に設計やる人間と実装やる人間の単価が違うってとこまでコストカットしてないと
設計と実装の人間を変えることないべ?

だから自社パッケなんてのは無駄ばかりだから成り立つもんなんだよ
そのうち開発メンバーが年取ってくれば給料とかコストが増えるから自社パッケはなくなるだろうな
230 :デフォルトの名無しさん2011/11/26(土) 16:30:38.30
>>228
開発者が歳をとろうと自社パッケージをなくすことは無理だよ。少なくともウチでは。
こんな不況下でも黒字をたたき出す。受注に比べほっといても売れるから
圧倒的に採算がいいらしい。ただ、それでも情報収集が必要だからって理由で
受注開発はしてる。
233 :デフォルトの名無しさん2011/11/26(土) 18:46:35.67
>>230
したらどうして大手は自社で開発をもたないの?
って疑問はお前の理論じゃ成り立たないべ?
234 :デフォルトの名無しさん2011/11/26(土) 19:51:02.29
>>233
230じゃないが。

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

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

言ってもソコソコ売れてるパッケージは金になるよ。
作ってしまえばあとは保守にゃあんまり金掛からないのに、
サポートで金取れるし、機能追加で金取れるし。
そんかわり軌道に乗るまでは赤字吹きまくる。
239 :デフォルトの名無しさん2011/11/26(土) 21:46:06.84
>>233
いや、単にウチの事情を書いただけだし。
理論は成り立たないと言われてもねぇ。
227 :デフォルトの名無しさん2011/11/26(土) 16:20:40.47
つか、納品する仕事なんてやりたくない。

せっかく作ったシステムの権利をあげたら自分になにも残らないだろ。
229 :デフォルトの名無しさん2011/11/26(土) 16:24:46.68
ん?成果物は全部自社管理すんだから、
作ったソースやドキュメントは自社のもんじゃん。
ライブラリなんてシステム見積もるときにライセンス買わせてるし。
232 :デフォルトの名無しさん2011/11/26(土) 16:38:56.44
詳細設計書はともかく、基本設計書もない環境なんて無いだろ。
236 :デフォルトの名無しさん2011/11/26(土) 21:09:09.26
開発系エンジニアのスキルロードマップ Part 1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
http://blogs.msdn.com/b/nakama/archive/2011/11/25/skill-roadmap-part-1.aspx
237 :デフォルトの名無しさん2011/11/26(土) 21:12:26.72
やっぱりオブジェクト指向って言ったら
Javaの独壇場か。
240 :デフォルトの名無しさん2011/11/26(土) 21:57:28.40
>>237
いや、純粋なOOで言えばCOMやCORBA、COCOAの方がマシなぐらいだが。
242 :デフォルトの名無しさん2011/11/26(土) 22:08:45.64
>>237-238
オブジェクト指向の基礎を学ぶならJavaは適してると思う
アクセス修飾子、静的型、抽象クラス、抽象メソッド、インターフェース、継承をしっかりと機能が用意されているので学びやすい

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

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

っということでとりあえずはやっぱりJava
OOの重鎮達が推奨するsmalltalkも1度学びたいとは思ってるが知らない
238 :デフォルトの名無しさん2011/11/26(土) 21:18:17.95
Javaが一番アカデミックだよね。
ちゃんと熟考して作るという開発ができる。

他の言語、特に動的型付け言語なんか、適当に考えて
問題出たらパッチ当てる感覚で修正するから、
その時はすぐに問題を解決できても、すぐにボロが出てしまう。
264 :デフォルトの名無しさん2011/11/27(日) 00:49:48.12
>>238
ポカーン とした意見だった。
241 :デフォルトの名無しさん2011/11/26(土) 22:06:23.44
bean機構なんて導入したのが、どうしようもなく退化してるしな
243 :デフォルトの名無しさん2011/11/26(土) 22:18:18.50
C++もOOの基礎を理解したら
スタック、ヒープや
参照渡し、ポインタ渡し、値渡し、Javaの参照渡しなど
メモリ関連を理解するためには1度学んでもいいかもしれない
244 :デフォルトの名無しさん2011/11/26(土) 22:23:33.89
beanもアレだけどJavaは戻り値を多用して、ダウンキャストが多いのがナンセンス。
smalltalkやC++の用に引数で受け取ったオブジェクトに再度メッセージを送るほうが、
OOとしては理に叶ってるのにな。
248 :デフォルトの名無しさん2011/11/26(土) 23:08:34.62
引数で受け取ったオブジェクトに再度メッセージを送りたいなら
送ればいいだけだと思うけど、俺も>>244がなにを言いたいのかわからんな。
245 :デフォルトの名無しさん2011/11/26(土) 23:01:24.72
> smalltalkやC++の用に引数で受け取ったオブジェクトに再度メッセージを送るほうが、

意味不明
246 :デフォルトの名無しさん2011/11/26(土) 23:04:55.40
メッセージについて勉強しなおしてこい
247 :デフォルトの名無しさん2011/11/26(土) 23:06:34.41
>>246
勉強してきた。それで?
250 :デフォルトの名無しさん2011/11/26(土) 23:18:02.50
>>247
じゃメッセージフォワーディングのメリットぐらい解るだろ。
252 :デフォルトの名無しさん2011/11/26(土) 23:21:45.55
>>250
したいならすればいいんじゃないですかぁ?
249 :デフォルトの名無しさん2011/11/26(土) 23:14:00.13
これだけの話なんだけどな。

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

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

// Java以外だとよく見る素直な実装
RootBean bean = new RootBean();
decoder.readTo( bean );
251 :デフォルトの名無しさん2011/11/26(土) 23:20:12.14
ちゃんとコードの解説をしろ
253 :デフォルトの名無しさん2011/11/26(土) 23:26:13.93
>>251
ダウンキャストの使用頻度が高くて、OOPLとしてはデザインが汚いですよね。
他の言語のほうがマシに見えるぐらい。
おわり。
254 :デフォルトの名無しさん2011/11/26(土) 23:32:55.08
>RootBean bean = new RootBean();
>decoder.readTo( bean );

確かにこれができると便利だけどね
こういう風に読み込み前にオブジェクト弄れるし
decoder.readTo(new Adapter(bean, param));
255 :デフォルトの名無しさん2011/11/26(土) 23:40:13.91
わざわざ参照多用するような構造を肯定するのは
グローバル変数便利だよ引数省略できるし並みに痛い気がするんだが
257 :デフォルトの名無しさん2011/11/26(土) 23:43:02.89
>>255
オブジェクトトポロジーを理解してないお前のほうが痛い
256 :デフォルトの名無しさん2011/11/26(土) 23:41:56.25
それはJavaに洗脳されてるからじゃないの?
戻り値多用するOOPLは少数派だべ
259 :デフォルトの名無しさん2011/11/26(土) 23:49:43.70
ダウンキャストと参照どっちを取れといわれれば、まだ参照だわ。
261 :デフォルトの名無しさん2011/11/27(日) 00:08:51.20
Javaの問題ではなく、ライブラリの設計の問題じゃねーか。
262 :デフォルトの名無しさん2011/11/27(日) 00:33:35.14
decoderみたいの設計するとき
どんなふうにするのがいいんですかね

こんな感じとかかしら
RootBean bean = decoder.readTo( RootBean.class );
263 :デフォルトの名無しさん2011/11/27(日) 00:45:15.16
auto hoge = reader.read<Hoge>();
265 :デフォルトの名無しさん2011/11/27(日) 00:52:55.29
>>262
>>263と同じ見かけが変わっただけじゃん
269 :デフォルトの名無しさん2011/11/27(日) 01:26:32.33
>>263
型推論使うんなら型指定そのものも無くなってほしいけど
C++とかだとそこまでは無理なんだっけ
276 :デフォルトの名無しさん2011/11/27(日) 09:11:09.43
>>269
型推論は型宣言を省略するための仕組みじゃないよ
284 :デフォルトの名無しさん2011/11/27(日) 13:02:03.39
>>269
返り値の型しか違わないオーバーロードが可能な言語って、どんな変態文法だよ
285 :デフォルトの名無しさん2011/11/27(日) 13:13:46.63
>>284
Scala
286 :デフォルトの名無しさん2011/11/27(日) 14:11:32.97
>>285
へえ、Scalaだと
hoge(read())
で、hoge(x:Int)かhoge(x:String)かどちらが呼ばれるかわかるの。へえ
354 :デフォルトの名無しさん2011/11/27(日) 23:58:55.68
>>284
C++でも出来るぞ
オーバーロードが曖昧な場合はキャストが居る。
266 :デフォルトの名無しさん2011/11/27(日) 00:55:37.75
Javaは土方で、アカデミックとは真逆の位置にいるもんな
267 :デフォルトの名無しさん2011/11/27(日) 00:59:42.03
>>266
お前にとってのアカデミックって
ドカタだろw
271 :デフォルトの名無しさん2011/11/27(日) 03:46:33.17
Javaでアルゴリズムを教えようとすると、大変だと思うよ。
アルゴリズム以外の要素が邪魔すぎて。アルゴリズムなんて
どうでもよくて、ただ、ライブラリを持ってきて並べるだけの仕事
ならばJavaは向いてると思うが。。。
272 :デフォルトの名無しさん2011/11/27(日) 03:48:59.06
オブジェクト指向の有名な教科書ってエッフェルだったよな?
オブジェクト指向言語の代表選手として、Javaを扱ってるのもある。
デザパタの出処はsmalltalkみたいだし。
273 :デフォルトの名無しさん2011/11/27(日) 05:16:59.81
昔勉強した頃はエッフェルという名前も聞いたけど
言語の研究分野でしか聞いたことがないなぁ

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

市井のプログラマとしてはJavaでウェブっていう案件は多い
VB.net、VC++より多いんじゃないかな
274 :デフォルトの名無しさん2011/11/27(日) 05:20:16.36
実装言語の話はさておいて

ユースケース記述とシーケンス図がしっかりしてるのは
設計先行のいいプロジェクトの傾向だと思う
275 :デフォルトの名無しさん2011/11/27(日) 08:00:36.71
シーケンス図がしっりしてるのはバッドスメルだろ。コスト配分に問題ありそう
278 :デフォルトの名無しさん2011/11/27(日) 09:58:49.67
ほおー、型推論は型指定を省略するためのものなのか?www
馬鹿丸出しw
282 :デフォルトの名無しさん2011/11/27(日) 12:37:48.04
>>278
え、ちがうの?
参考までにご高説を賜りたく( ^ω^)・・・
288 :デフォルトの名無しさん2011/11/27(日) 14:47:25.62
>>282
型推論は型検査をするためのものだろwwwww
293 :デフォルトの名無しさん2011/11/27(日) 14:55:47.39
>>288
「型検査 型推論 違い」でぐぐってみ。
この2つは明らかに別もの。
294 :デフォルトの名無しさん2011/11/27(日) 15:07:44.66
>>288
静的型検査を型を記述しなくても可能にするためのものだろ。
バカすぐるwwwww
295 :デフォルトの名無しさん2011/11/27(日) 15:15:51.69
>>294
いや、逐一型指定しても型推論(型単一化)は行われるよ。
キミさ、型推論の仕組みがわかった上で言ってるの?
型推論を実装したことある?
296 :デフォルトの名無しさん2011/11/27(日) 15:17:25.50
>>295
実装したことがあるから言ってる。
似てるだけで概念的には別物。

あんたは実装した奴が陥る罠に落ちいてるだけだよ。
実装が似ているものを同じだと思ってしまう。
概念は別物。
300 :デフォルトの名無しさん2011/11/27(日) 15:25:55.78
>>295
型検査するけど型推論実装してない言語がある以上、別物だろ。
306 :デフォルトの名無しさん2011/11/27(日) 17:43:52.36
>>300
しかし型検査ぬきの型推論は原理上ありえない
317 :デフォルトの名無しさん2011/11/27(日) 18:55:50.33
>>306
だれも型検査抜きの型推論のことは話してないと思うが。
上であがってるのは
・型推論!=型検査
・型推論は静的型検査を行う言語で型の記述を省く仕組み
かどうかの話だろ。
型推論をする時にコンパイラが型を認識してるのは当たり前で、それは型検査じゃないよ?
319 :デフォルトの名無しさん2011/11/27(日) 20:12:06.56
>>317
>・型推論!=型検査
を主張してる奴らは、その是非が
>・型推論は静的型検査を行う言語で型の記述を省く仕組み
かどうかに帰結するわけじゃないことに
気づいてなさそうな話の展開のさせ方してるよな。
ほんと謎の思考だ
355 :デフォルトの名無しさん2011/11/28(月) 00:01:22.46
>>349
>>288みたいな馬鹿をぷげら出来る
360 :デフォルトの名無しさん2011/11/28(月) 18:25:31.70
>>355
いや、客観的に言って、バカはおまえ
283 :デフォルトの名無しさん2011/11/27(日) 12:45:41.55
型推論は、〜略 超高度な推論機能によって 略 〜 その結果、型指定が省略できるのです。
287 :デフォルトの名無しさん2011/11/27(日) 14:30:22.90
型がない言語だと関数内部で、引数の型を調べて
処理を分岐させるコードを書かないといけないから面倒臭い。
289 :デフォルトの名無しさん2011/11/27(日) 14:51:29.49
http://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96

型推論(かたすいろん)とはプログラミング言語の機能の1つで、
静的な型付けを持つ言語において、変数や関数の型を宣言しなくても
それを導くのに使われた関数の型シグネチャなどから自動的に型を決定する機構のこと。
291 :デフォルトの名無しさん2011/11/27(日) 14:53:03.56
> 型推論を持つ言語としてはHaskell、ML、Vala、C#、Scala、Objective Caml、D言語、Concurrent Cleanなどがある。
> JavaやC++0xでも導入が検討されている。静的型付け関数型言語のほとんどが型推論の機能を持っている。

Rubyには型推論搭載されんの?
301 :デフォルトの名無しさん2011/11/27(日) 16:34:21.06
>>291
Rubyは動的型付け
実行するまで型は関係なし
型推論は静的型付けで型を省略すること
だけどちゃんと型は認識されてる
297 :デフォルトの名無しさん2011/11/27(日) 15:21:31.48
本物のパラメトリック多相型のある言語の型検査には型推論は必須。
そして型推論での単一化は型検査にほかならない。

ということを承知の上で別物だとか言うわけ?
298 :デフォルトの名無しさん2011/11/27(日) 15:22:40.87
> 型検査には型推論は必須。

この2つを区別して書いてることから、
お前も別物として扱ってるだろ。
299 :デフォルトの名無しさん2011/11/27(日) 15:23:59.79
× 本物のパラメトリック多相型のある言語の型検査には型推論は必須。
○ 特定の条件の言語の、型検査には型推論は必須。 そうでない言語では必須ではない。

304 :デフォルトの名無しさん2011/11/27(日) 17:28:50.13
まあ、型について議論が始まったことは良いこと。
オブジェクト指向は型(インターフェース)でプログラミングしておくっていうことで
俺なんかは満足している。いかにメインのプログラムを型(インターフェース)でプロ
グラミングできるかが重要だといつも思っている。
これを実現するためには何度も何度もクラス図を書いて、適切な型(インターフェース)
を取り出す。この辺がなかなか時間がかかりPMに「何をやっているんだ。仕事が遅い」
と怒鳴られる。泣きてえーーー。
308 :デフォルトの名無しさん2011/11/27(日) 17:47:51.66
>>304
>いかにメインのプログラムを型(インターフェース)でプロ
>グラミングできるかが重要だといつも思っている。

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

後半は、まぁ愚痴だねw
307 :デフォルトの名無しさん2011/11/27(日) 17:45:29.32
スレにあってそうなテーマをここでひとつ。

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

309 :デフォルトの名無しさん2011/11/27(日) 17:51:42.97
>>307
非機能要件で全然変わってくるから、ベストって無いんじゃないの?
314 :デフォルトの名無しさん2011/11/27(日) 18:37:15.01
>>307
業種や何やらの条件で色々違うだろうね

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

実装前にこれくらい設計できればなぁ…
デザインパターンの適応もコーディング前の段階で検討できるし
コーディングは楽になると思う
310 :デフォルトの名無しさん2011/11/27(日) 18:08:53.44
動的型付け言語は出来損ないのオブジェクト指向だからねぇ。

出来損ないをアセンブラでカバーしてください。
アセンブラ使えばなんでもできますから。
311 :デフォルトの名無しさん2011/11/27(日) 18:20:23.56
312 :デフォルトの名無しさん2011/11/27(日) 18:21:25.85
>>311
嫉妬心丸出しで見ていて恥ずかしくなったw

そうか、そんなにJavaに嫉妬してるのか
315 :デフォルトの名無しさん2011/11/27(日) 18:39:06.55
静的型付けオブジェクト指向なんて、貧乏人向けのオブジェクト指向だろ。
補助輪付きの自転車みたいなものだw
318 :デフォルトの名無しさん2011/11/27(日) 19:54:28.55
型を認識するだけでなく、型の整合性を検証しているんだよ。単一化によって。

型推論を実装したのにわからないなんて、おかしいなあw
320 :デフォルトの名無しさん2011/11/27(日) 20:50:27.40
>>318
整合性の検証は型検査でしょ
これは型推論が実装されているいないに関わらず静的片付けなら実装されてる
だから・型推論!=型検査
ということじゃないの?
343 :デフォルトの名無しさん2011/11/27(日) 22:12:23.86
こういうことじゃないかと思う

・型推論は型検査じゃない派 --> 目的と結果を分けて考えよう
・型推論は型検査じゃない派 --> 目的と結果をを混同してもええやないけ

ここで、
・型推論の目的:型の整合性の検証(型が無矛盾であることの証明), >>318から引用
・型推論の結果:型検査および型宣言の省略化

自分は型推論は型検査じゃない派だな
344 :デフォルトの名無しさん2011/11/27(日) 22:16:23.06
>>343
型推論の目的>>318は微妙だなあ。その目的を満たすなら型推論しないほうが合目的的だし。
345 :デフォルトの名無しさん2011/11/27(日) 22:30:10.98
>>343
型推論の目的は、型検査をするための記述を少なくすることですよ。
346 :デフォルトの名無しさん2011/11/27(日) 22:35:34.92
>>343
型推論は型検査じゃない派しかいないぞw
348 :デフォルトの名無しさん2011/11/27(日) 22:46:14.77
>>346
おっと、ミスッたぜ。>>343を以下のように訂正する。

>・型推論は型検査じゃない派 --> 目的と結果を分けて考えよう
>・型推論は型検査だ派 --> 目的と結果をを混同してもええやないけ
352 :デフォルトの名無しさん2011/11/27(日) 23:07:56.39
>>344
その目的に前提を含めて書けば、

・暗黙の(=省略された)型宣言があっても検証(=証明)できること

になるね

これを実現するために推論が必要になった、という話だと思う
321 :デフォルトの名無しさん2011/11/27(日) 20:53:37.13
納豆は大豆を腐らせて作るものだが、
納豆と大豆とは別物として扱われているのと同じだ。
331 :デフォルトの名無しさん2011/11/27(日) 21:29:47.21
>>321
違うな。

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

型推論は型検査だ派の論旨
・1+2と3は表現が異なるだけで、どちらも3という値であり、同じことだ
・4-1も3だね。で、だからといって、1+2と3が異なる値にはならないけど、何か?
332 :デフォルトの名無しさん2011/11/27(日) 21:31:16.39
>>331
違うな。

>>321が正しい
334 :デフォルトの名無しさん2011/11/27(日) 21:34:34.27
かわいそうに、命令型のショボい型推論しか知らないと
>>321みたいに間違った理解をしてしまうんだね。

オブジェクト指向やってる人は視野が狭くて、
関数型のちゃんとした型推論を知らないんだ。
336 :デフォルトの名無しさん2011/11/27(日) 21:38:48.80
>>334
いやいや、>>321が正しいって言ってるだけ。お前は間違ってる。
338 :デフォルトの名無しさん2011/11/27(日) 21:42:00.86
>>336
そう思えるのは、あんたが命令型のショボい型推論しか知らないからww
井の中の蛙だねえwww
339 :デフォルトの名無しさん2011/11/27(日) 21:48:03.43
どう見ても>>321が正しいですな。
340 :デフォルトの名無しさん2011/11/27(日) 21:50:12.91
>>321が言うとおり、
納豆を指して「これは大豆だから」と言った人に
「これは大豆じゃないよ、納豆だよ」と言い出してるのが
型推論は型検査じゃない派のドカチン君ですねwww
341 :デフォルトの名無しさん2011/11/27(日) 21:51:36.73
>>340
まさにその通り!
322 :デフォルトの名無しさん2011/11/27(日) 21:04:48.74
設計やってないコーダーが多いことが分かって俺は悲しい orz
323 :デフォルトの名無しさん2011/11/27(日) 21:06:25.53
Javaプログラマぐらいだよね。
コーディングの話題に設計の話が出てくるのは。

デザパタとかDIとかドメインモデルとか
そういう用語が他言語ででることは極端に少ない。
324 :デフォルトの名無しさん2011/11/27(日) 21:09:00.94
DIはわざわざ話題に出さなくとも、習慣的にやってるからなあ
326 :デフォルトの名無しさん2011/11/27(日) 21:10:04.37
>>324
それってその場ののりでなにも考えずにやってるだけでしょ?
それはDIじゃなくて、ただのパッチ
325 :デフォルトの名無しさん2011/11/27(日) 21:09:41.49
出来損ないの言語仕様の埋め合わせを
設計でやってるから
327 :デフォルトの名無しさん2011/11/27(日) 21:10:25.52
JavaでSingleton作る時にDouble-Checked Lockingが駄目なのって、まだ解消されてないんだっけ?
329 :デフォルトの名無しさん2011/11/27(日) 21:17:24.20
>>327
volatileで解決できるようになってたと思うけど
330 :デフォルトの名無しさん2011/11/27(日) 21:26:25.10
>>329
え?そうだっけ??
ダブル…の延長線上ではどうあがいで駄目だったような
328 :デフォルトの名無しさん2011/11/27(日) 21:13:26.74
今はSingletonはDIの設定に任せるからあまり関係ないね。

システムではSingletonでも、テスト時には多数作りたいことがあったりで
コードで書くのは良くないパターンとされている。
333 :デフォルトの名無しさん2011/11/27(日) 21:32:16.55
設計とコーディングを別々の作業だと思ってるSIドカタ・・・かわいそw
335 :デフォルトの名無しさん2011/11/27(日) 21:35:34.03
そもそも中身がstaticになるようなものを
盲目的に使って動くものができると思えんが
342 :デフォルトの名無しさん2011/11/27(日) 22:03:39.73
たまに居るね
自分の設計思想を信じ相手は馬鹿であると見下し
よくわからないしょぼいものしかつくれない
349 :デフォルトの名無しさん2011/11/27(日) 22:48:56.56
型推論が型検査と一緒もしくは一緒じゃないことがわかることでどういう嬉しさがあるの?
350 :デフォルトの名無しさん2011/11/27(日) 22:53:00.61
>>349
型検査だけできるってことが理解できる。
351 :デフォルトの名無しさん2011/11/27(日) 23:06:51.07
>>350
ならJavaとかは型検査してるけど型推論しないから初めから結論でてるんじゃないの
353 :デフォルトの名無しさん2011/11/27(日) 23:13:13.31
>>349
言語を利用する立場であれば、会話の中で両者を一緒にしても推定できるから、
たぶん支障は無いと思う。多くがこのケースだから、一般的には一緒でかまわない。

ただし、言語を実装する立場であれば、両者を明確に区別して定義/理解できないと
苦労するはめになる(過去の自分)
356 :デフォルトの名無しさん2011/11/28(月) 00:04:59.69
ExampleType x = Function( 1, 2 );

auto x = Function( 1, 2 );
って書けるだけだろ。
何下らないことでひきずってんの?
357 :デフォルトの名無しさん2011/11/28(月) 05:44:12.34
どう考えても別物だろ
Javaは型検査してるけど、型推論できない
完全に使い分けできるじゃん
361 :デフォルトの名無しさん2011/11/28(月) 18:33:01.05
全ての型検査は必ず型推論を伴う。
例えば、
double x = "abc";
は型エラーだが、これはxの型について
- double xという宣言からxはdouble型である
- x = "abc"からxはString型である
の2つの推論結果をunifyできないことからエラーを検出する。

全ての型推論は必ず型検査を伴う。
これは、表現式の型を1つ1つ確定していくプロセスにおいて
必ず矛盾がないかを検証するから。

全ての型検査は型推論を伴い、全ての型推論は型検査を伴うのであれば、
型検査と型推論は同じものの別名にすぎない。Q.E.D.
364 :デフォルトの名無しさん2011/11/28(月) 19:12:06.15
>>361
多分お前が言ってる型推論と皆が考えている型推論は別のものだと思うよ?
其れすらわからないで俺スゲー垂れ流してるのがあわれすぐるwww
366 :デフォルトの名無しさん2011/11/28(月) 19:17:57.90
>>364
少なくとも20年前には既に型推論と型検査は同一技術だというのが
関数型言語界隈での常識だったが?

自分の無知を自慢するのって、楽しい?
367 :デフォルトの名無しさん2011/11/28(月) 19:36:54.88
>>366
わかったからJAVAで型検査と型推論の分離ができている訳を教えてくれ
363 :デフォルトの名無しさん2011/11/28(月) 19:09:56.75
このスレは実装技術についていけずに
設計と称して四角形と直線をひくしか脳がない
底辺SEの巣だからなw
365 :デフォルトの名無しさん2011/11/28(月) 19:13:58.94
自分の世界に生きてるヤツはほっとけよ。
こっちに引き戻そうとしたって無駄なだけだろ。
369 :デフォルトの名無しさん2011/11/28(月) 19:39:46.32
しかし、Javaしかわからない(というかJavaすらマトモにわかってない)馬鹿は
言うことがメチャクチャで笑えるw
370 :デフォルトの名無しさん2011/11/28(月) 19:58:16.81
度々このスレユースケース図の話題でるけど、
UML自体はOOサポートしてるだけで、OOを志向してる訳じゃないから
オブジェクト指向型システム設計とはあんまり関係ないよな。
UML全体としてみれば飽くまでラショナルプロセスを支えるツール。
373 :デフォルトの名無しさん2011/11/28(月) 21:25:26.89
オブジェクト指向のオススメの書籍教えて
377 :デフォルトの名無しさん2011/11/28(月) 22:21:28.91
>>373
ないんだな、それが
375 :デフォルトの名無しさん2011/11/28(月) 22:05:22.48
試験答案帳。表紙が青いことからこの名前がついています。主として作文形式の試験に使われます。
376 :デフォルトの名無しさん2011/11/28(月) 22:05:56.66
Blue Book
読み方:ブルーブック
Blue Bookとは、CD-EXTRAの仕様書のことである。
ソニーとオランダのPhilips社によって開発されたものである。

マルチセッションでデータを記録できるようになっており、
第一セッションには、音声データが、第二セッションには、
パソコン用のデータが保存される。このCD-Extraの仕様書の
表紙が青かったことから、Blue Bookという名称が付いた。
379 :デフォルトの名無しさん2011/11/29(火) 04:53:37.90
本当はブルーブックがいいけど、今ならパープルブックで我慢だな
383 :デフォルトの名無しさん2011/11/30(水) 22:01:58.18
デザパタなんてだれも仕事では使ってないよな?
本気で使ってる奴いる?
386 :デフォルトの名無しさん2011/12/01(木) 01:50:25.19
煽りじゃなくこのスレレベル低いのな
ちょっとがっかりしたんだぜ
387 :デフォルトの名無しさん2011/12/01(木) 07:03:36.97
デザパタ使わずに仕事してる奴なんているのか?
Strategyすら使わないとなると逆に難しいだろ
388 :デフォルトの名無しさん2011/12/01(木) 08:32:49.79
デザパタの何使ってる?
502 :デフォルトの名無しさん2011/12/03(土) 10:29:36.06
>>499
>>388 から同じ話題が出てる。ただ、現場で頻出するパターンを抽出して名前を付けたのがデザパタなので、
全部の名前と目的ぐらいは知っておいて損はないよ。一度 GoF 本を通して読んでおくといい。
504 :デフォルトの名無しさん2011/12/03(土) 12:03:56.73
>>502
さんくす。
やはり全部ですかね。
392 :デフォルトの名無しさん2011/12/01(木) 10:18:33.66
Singleton、Iterator、Observer は意図しなくても自然に使ってると思うんだが。
399 :デフォルトの名無しさん2011/12/01(木) 23:03:02.81
>>392
> Singleton
役に立ったためしがない
つか、どんなときに使ってるんだよ

406 :デフォルトの名無しさん2011/12/02(金) 06:21:25.41
>>399
Cライブラリをラッパーしたユーティリティクラスみたいなもの
イミュータブルで値を保持させておきたいクラス

どちらも複数生成する必要がないしどこから参照されても問題ないからSingletonにしたんだけど何か問題あるかな?

Singletonは使いどころが難しい…
419 :デフォルトの名無しさん2011/12/02(金) 20:13:26.76
>>406
そういう使い方をするものをシングルトンとはいわんだろ。
シングルトンってのは、デバイスの書き込み制御を独占管理したり、
アプリケーションに送られてくるメッセージを独占管理する時に使うもん。

あと、C++系固有の話だが、グローバル変数と違い、
初期化順序を制御できるという点がある。
429 :デフォルトの名無しさん2011/12/02(金) 22:44:58.89
>>419
Singletonって使い方限定されているものなの?
クラスのインスタンスを1つしか生成できないようなものをSingletonというのかと思っていたけど
431 :デフォルトの名無しさん2011/12/02(金) 22:51:15.85
>>429
状態が1つでいいなら、モノステートでいいだろ。
実体が一つである理由を考えてみ。
435 :デフォルトの名無しさん2011/12/02(金) 23:04:04.45
>>431
状態が1つならSingletonにせずにstaticクラスにしてしまえばいい
状態を複数許して実体を1つにしたいときにSingletonを使うということであってる?
何故実体を1つにしたいかは、複数から操作されてしまうと困るから?
いまいちわかってないや
436 :デフォルトの名無しさん2011/12/02(金) 23:04:26.21
>>429
状態が連続していることを期待した使い方をするとグローバル変数と同じハメになる。
例えば、メソッド間の値の受け渡しに使えば、無限ループが発生することもある。
分岐の予想も困難になる。
まず、そういう用途に使っちゃいけないという点で限定される。
基本的に、どこからどう操作しようと他に影響が無いものじゃないといけない。
それから、シングルトンは、オブジェクトとしての実体をもっている事が一番重要。
CharDevice.Instance().Write(""); のような直接メソッドを呼ぶ用途じゃなく、
Device device = CharDevice.Instance(); のようにインスタンスを突っ込む用途に使用する。
456 :デフォルトの名無しさん2011/12/02(金) 23:45:46.24
>>431
横レスだがモノステートは調べて今知った。でもこれだと、派生クラスに適用したい場合はどうしたらいい?
あと、GoF 本は Singleton の目的を「インスタンス数を1つだけに制限して、それにアクセスするグローバルな方法を提供する」
って書いてるだけだから、俺は >>429 で合ってると思うんだが。出来たら、もうちょっと詳しく説明してくれないか?俺の頭では分からんので。
459 :デフォルトの名無しさん2011/12/02(金) 23:52:42.03
>>456
何を見た?ぐぐって先頭のページにでてくるモノステートは間違ってるからな。

class Mono
{
       static int value1;
       static int value2;
public:
       int Method()
       {
              return value1;
       }
}:
Mono mono;

モノステートはこういうヤツ。当然親も子も継承できる。
461 :4562011/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個にしたい場合はどうしたら良い?
466 :デフォルトの名無しさん2011/12/03(土) 00:04:11.21
>>461
モノステートは状態を1つに保つだけ。
インスタンスの数は制限しない。
インスタンスの数を制限したいならシングルトン。

>状態が1つでいいなら、モノステートでいいだろ。
前にこう書いたろ。
467 :4562011/12/03(土) 00:06:52.86
>>466
んじゃ、>>461 のケースだとモノステートは使えんのね。ありがと。
473 :デフォルトの名無しさん2011/12/03(土) 00:16:57.44
>>467
そもそも何でインスタンスを一つにしたいんだ?

map[ SINGLETON_A ].Method();
map[ SINGLETON_B ].Method();

とかしたいわけじゃないんだろ?
476 :4562011/12/03(土) 00:26:25.89
>>473
インスタンスを一個に絞りたいことはよくあると思うんだけど?
例えばクラスのメタ情報とか、コードで定数を定義するときとか。
基底クラスで既定値を定義しておいて、派生クラスで変更分だけ上書きして使えば、コードの見通しが良いでしょ?
477 :デフォルトの名無しさん2011/12/03(土) 00:32:07.06
>>476
それはインスタンスじゃなくて状態を一つに絞りたいだけじゃないか?
あと、シングルトンは、親クラスを持つことはできるけど、子クラスを持つことは不可能だからね。

ちなみに、英語圏だとファクトリー用途が多いらしい(ファクトリーのメモリー消費節約のため)。
481 :4562011/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); }
483 :デフォルトの名無しさん2011/12/03(土) 01:03:18.66
>>481
だから >>459のモノステートで十分じゃね?
484 :4562011/12/03(土) 01:14:14.58
>>483
そかな?
モノステートだと。基底クラスもモノステートじゃなきゃ new するたびにメモリ確保が走っちゃうし、インスタンス毎に値が書き換えられちゃうし。
Singleton の方が安心して使えると思うんだけど。
485 :デフォルトの名無しさん2011/12/03(土) 01:22:43.11
>>484
ああ、子の状態を一つにしたいのか。
それならシングルトンの方が向いてるかもね。
題材がシングルトンに向いてるかは別だけど。
492 :4902011/12/03(土) 01:49:14.38
よくよく考えたら全然良くないわ。そもそも>>476の話からすると、
クラスごとのメタ情報を持ちたいだけ。
だったら、そのメタ情報を付与するクラスにpublic MetaData MetaData();ってメソッドもたせて、
そのクラスの中に、private static MetaDate metaData = new MetaData( "Person" );とか持たせておけばいい。
まぁ、この方法だと既存のクラスには使えないけどね。まぁ、そういう場合はトレイトだ。
493 :4562011/12/03(土) 01:56:54.84
>>492
あくまで例だから、あんまり突っ込まんといて。
メタ情報を付加させる場合も実際はインナークラスとして定義したり、ジェネリックを使ったりと色々だから。
393 :デフォルトの名無しさん2011/12/01(木) 10:28:43.88
デザパタを使ったクラスライブラリ等を使うのと、
クラスライブラリ等を作るためにデザパタを使うのと、どっち?
後者のことだけ話題にしてると思ったが?
394 :デフォルトの名無しさん2011/12/01(木) 10:42:12.22
みんな後者だと思うよ。というか、デザパタって意図的に使おうとしなくても、
オブジェクト指向言語を使って普通に開発を進めてれば、
自然に当てはまる構造がコードのあっちこっちに見つかるようになると思うんだけど。
395 :デフォルトの名無しさん2011/12/01(木) 11:37:58.89
インターフェース的なもので抽象化するものは結構デザパタのどれかに当てはまるだろ。
むしろデザパタのほとんどがインターフェース的なもので抽象化されたものだとも言えるが。
396 :デフォルトの名無しさん2011/12/01(木) 19:41:14.73
Javaなんかコアクラス使ってるだけでデザパタべったりになるんじゃない?
397 :デフォルトの名無しさん2011/12/01(木) 21:10:45.59
MVVMはデザパタに入れても良いんだろうか
入れても良いなら毎回必ずと言っていいほど使ってる
398 :デフォルトの名無しさん2011/12/01(木) 21:46:07.84
MVCと同じで、原子的パターンじゃないから却下。
デザパタを組み合わせた、分子的なパターンを含め始めたらきりがない。
401 :デフォルトの名無しさん2011/12/01(木) 23:24:29.89
動的型付け言語にはデザインパターンは不要。

デザインパターンは静的型付け言語が不便だからできた
バッドノウハウ。
403 :デフォルトの名無しさん2011/12/02(金) 00:12:49.58
>>401
まったくその通りだと思う
少なくともGoF本の著者陣はそれを認識しているし、たとえそうであっても
それらをパターンとして命名しカタログ化した点にGoF本の意義があると述べている
ところが、なぜか「デザインパターンに沿ってなければOOPにあらず」という
不思議な風潮を(特にジャバラから)よく耳にするのが笑えるところ
409 :デフォルトの名無しさん2011/12/02(金) 10:55:35.75
>>401
>動的型付け言語にはデザインパターンは不要。
これってどういうこと?デザパタと型付けは関係無いと思うが.
>バッドノウハウ
これは同意だが.
415 :デフォルトの名無しさん2011/12/02(金) 17:52:39.69
>>409
例えばStrategyなんかは共通のインターフェースを用意することにより、戦略を使い回すけど動的型付け言語ならそもそもインターフェースを用意する必要なく使い回せるということじゃないかな
418 :デフォルトの名無しさん2011/12/02(金) 20:06:28.43
>>415
動的型付けは、インターフェースを書かなくて済むだけで、
最低限のインターフェースを持ってないとどのみちエラーになるだろ。(nullや転送できるものを除く)
デザパタと動的型付けかどうかは関係ない。
402 :デフォルトの名無しさん2011/12/01(木) 23:49:15.39
IteratorとかObserverとかどう考えても型付け関係無いパターン多いだろ
404 :デフォルトの名無しさん2011/12/02(金) 00:14:20.66
やった。馬鹿が釣れたw

デザインパターンってSmalltalkの世界から生まれたものなんだけどwwww
407 :デフォルトの名無しさん2011/12/02(金) 06:28:54.25
>>404
Smalltalkではパターンとして整理しなくても普通に使えていたイディオムを
Javaではいちいち形を決めて名前を付けて整理しないとうまく使えない、
ってことでしょw
405 :デフォルトの名無しさん2011/12/02(金) 06:14:14.39
動的型付けにも部分的には使えるだろうけど、別に動的型付け用のデザインパターンを作った方がいいな
408 :デフォルトの名無しさん2011/12/02(金) 08:42:14.90
だからその名前をつけたのが
Smalltalk時代なんだってばw
604 :デフォルトの名無しさん2011/12/04(日) 19:39:35.17
>>408
シッタカはやめとけw
例えばsingletonなんて、Smalltalkで使われていた頃はsingletonとは呼ばれていなかったぞw
410 :デフォルトの名無しさん2011/12/02(金) 11:00:04.80
まったく不要かはともかく、ちまたによくあるJava前提のデザインパターンは動的型付けの言語じゃ不要なものは多い。
426 :デフォルトの名無しさん2011/12/02(金) 22:11:20.08
>>410
> まったく不要かはともかく、ちまたによくあるJava前提のデザインパターンは動的型付けの言語じゃ不要なものは多い。

いや、全くわかってないw

デザインパターンは実装ではなくて考え方。

Java前提のデザインパターンとか
動的型付け言語で不要とか言うのは、
デザインパターンの本質をわかってない。

お前が言ってるのは実装が不要ってだけの話だろ。

いや、全くわかってないw
427 :デフォルトの名無しさん2011/12/02(金) 22:27:56.33
>>426
>デザインパターンは実装ではなくて考え方。
各デザインパターンの”考え方””本質”をきちんと言ってみてくれるかい?
428 :デフォルトの名無しさん2011/12/02(金) 22:30:18.12
>>427
クラスを変更せず、オブジェクト構造により拡張していく疎結合主義だろ。
430 :デフォルトの名無しさん2011/12/02(金) 22:47:20.18
>>427
結城本から

デザインパターンはクラスライブラリそのものではない

デザインパターンはクラスライブラリよりも一般的な概念です。

具体的なプログラム例を読むことも理解の助けにはなりますが、その特定の
プログラムだけがAbstract Factoryパターンなのではありません。肝心なのは
どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるか、なのです。
433 :デフォルトの名無しさん2011/12/02(金) 22:52:59.96
>>426じゃなくて>>410の間違い。
447 :デフォルトの名無しさん2011/12/02(金) 23:34:56.79
>>439
だとすれば益々>>427に答えないといかん
448 :デフォルトの名無しさん2011/12/02(金) 23:35:20.78
>>427
結城本から

デザインパターンはクラスライブラリそのものではない

デザインパターンはクラスライブラリよりも一般的な概念です。

具体的なプログラム例を読むことも理解の助けにはなりますが、その特定の
プログラムだけがAbstract Factoryパターンなのではありません。肝心なのは
どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるか、なのです。
453 :デフォルトの名無しさん2011/12/02(金) 23:44:28.14
>>448
結局結城本では、
デザインパターンとは,どういう種類のクラスやインターフェースが出てきて、、それらが
お互いにどういう関係にあるかであると言っているのですね。
各デザインパターンについてそういう形の説明ができますか?
457 :デフォルトの名無しさん2011/12/02(金) 23:50:14.90
>>453
はい、この場合のクラスやインターフェースというのは
Java用語ではなく一般的な意味です。
それは、「その特定の プログラムだけがAbstract Factoryパターンなのではありません」と
書いてあることからも明らかです。
458 :デフォルトの名無しさん2011/12/02(金) 23:51:06.79
>>453
もしかしてデザインパターンを知らないの?

自分が、if文を教えて下さいと
言っているのと同じだって分かってるかな?
511 :デフォルトの名無しさん2011/12/03(土) 13:38:12.39
>>432
> 「Rubyには○○パターンは不要!」
>
> 「え?じゃあRubyだとどうするの?」
>
> 「こうするだけで実装できる!」
>
> 「なにが実装できるの?」
>
> 「○○パターンだけど」
>
> 「そうだね、それがRubyにおける○○パターンの実装だよ」
>
>
> 将来>426が経験することになる実話w

>>426じゃなくて>>410の間違い。

↑はすでに>>410に書いてある通りじゃん。
411 :デフォルトの名無しさん2011/12/02(金) 12:34:06.30
いやいや使ってるならまだ救えるが、デザパタ得意って奴は他で使えん
のが多い気がする
412 :デフォルトの名無しさん2011/12/02(金) 13:06:29.55
デザパタ得意って何か怖いw
得意かどうかという、ステータス的捉え方が恐ろしい。
414 :デフォルトの名無しさん2011/12/02(金) 17:46:47.54
手段と目的を取り違えてるニオイがするってことさ
421 :デフォルトの名無しさん2011/12/02(金) 21:17:30.86
>>414
そもそもオブジェクト指向&デザパタ自身がそのニオイがするのだが
416 :デフォルトの名無しさん2011/12/02(金) 17:57:55.36
デザインパターンは適したところに採用すれば素晴らしく便利なもの
しかし適材適所というのは別にデザインパターンに限らない一般的な話

だから変な使い方をする奴がいるからといってデザインパターンを否定するのは間違い

あと デザインパターンはオブジェクト指向の感覚を掴むきっかけとしては良いものだと思う
423 :デフォルトの名無しさん2011/12/02(金) 21:30:37.66
>>416
あなたはオブジェクト指向とは何か、デザインパターンのそれぞれが
何であるかをきちんと言えますか?感覚ではなく。
424 :デフォルトの名無しさん2011/12/02(金) 21:35:31.42
>>423
デザインパターン = 書籍『オブジェクト指向における再利用のためのデザインパターン』で紹介されたパターンの事
434 :デフォルトの名無しさん2011/12/02(金) 22:55:50.34
>>423
デザパタは>>424の通り
オブジェクト指向プログラミングは、対象物を中心に置いたプログラミング
100円を両替するをプログラムで表すと、Moneyクラスのexchangeメソッドを引数100を与えて実行する、money.exchange(100) つまりI exchange money 100
SVOのOでObject目的語つまり対象を意味する
これを中心に置いている

OOPではないC言語はで同じことをするとexchange(money,100)moneyも100も引数として同列に扱う
ここが大きな違い
438 :デフォルトの名無しさん2011/12/02(金) 23:21:11.41
>>434
あんまりOOらしくないな。あと、Cで書くとじゃなく手続きで書くとじゃね。
金銭の例で言うと、レートのほうが解りやすい。

const Rate jp_yen_to_us_dollar( 75 );
const Rate us_dollar_to_jp_yen = jp_yen_to_us_dollar.Inverse();

jp_yen_to_us_dollar.Conversion( 100 ); // 100円をドルに換算
jus_dollar_to_jp_yen.Conversion( 100 ); // 100ドルを円に換算

クラスだけじゃなく、オブジェクトとして考えることが重要ね。
440 :デフォルトの名無しさん2011/12/02(金) 23:27:53.72
>>424
答えてくれてありがとう。
でもそれが答えになっていないことはあなた自身が分かっていますよね。
>>434
まじめに答えてくれてありがとう。
そうですね。最初はそういう説明をしたりされたりするね。
”オブジェクト指向”を”対象中心”と言い換えてくれたんですね。
では”対象中心”とは何かと聞きたくなりますが。
例がついているのはありがたいですね。SVOのOっていうのはほんとですか?
Sは中心にはならないのですね?
449 :デフォルトの名無しさん2011/12/02(金) 23:38:17.45
>>440
SVOのOはObject
OOPのOもObject
smalltalkのメッセージ送信の対象という意味でも合致していると思ってる
450 :デフォルトの名無しさん2011/12/02(金) 23:39:34.46
>>424 以上の答えは無いだろうけどな。
451 :デフォルトの名無しさん2011/12/02(金) 23:41:30.04
>>449
( Message object object object object )
これどうすんの?
454 :デフォルトの名無しさん2011/12/02(金) 23:44:31.26
>>451
それはどういう意味?
455 :デフォルトの名無しさん2011/12/02(金) 23:45:25.58
>>454
マルチメソッド
417 :デフォルトの名無しさん2011/12/02(金) 18:52:47.96
ぶっちゃけ、先人の作ったコードの中から似た物抽出して
それらしい名前つけただけの、なんちゃって技術だろ?

縛られ過ぎる方がおかしいw
420 :デフォルトの名無しさん2011/12/02(金) 21:08:27.72
このスレにふさわしい人たちが現れ始めたような気がする。
441 :デフォルトの名無しさん2011/12/02(金) 23:29:51.28
>>424や>>434のようなデタラメをもっともらしく言うのは頼むからやめてくれよ
冗談のつもりなのかもしれないが、>>420のように騙される人も出てくるからさ
443 :デフォルトの名無しさん2011/12/02(金) 23:32:20.33
>>441
具体的な正しい説明を頼む
422 :デフォルトの名無しさん2011/12/02(金) 21:22:15.53
オブジェクト指向=縦割り
デザパタ=輪切り
こんな感じかえ?
425 :デフォルトの名無しさん2011/12/02(金) 22:08:04.54
某言語は何でメソッドがオブジェクトじゃないんだろうな。
double Function( double ) function = Math.abs;
function( 100 );
実際にメモリにオブジェクトとしての実体は持たなくてもいいから、
参照に引き渡されたら自動的にオブジェクトを生成してくれりゃ良かったんだけど。

FunctionDoubleDouble function = MathLibrary.abs;
function.call( 100 );
まぁ、現状でも同等のものを作れないわけじゃ無いんだけれども。
432 :デフォルトの名無しさん2011/12/02(金) 22:52:40.25
「Rubyには○○パターンは不要!」

「え?じゃあRubyだとどうするの?」

「こうするだけで実装できる!」

「なにが実装できるの?」

「○○パターンだけど」

「そうだね、それがRubyにおける○○パターンの実装だよ」


将来>426が経験することになる実話w
437 :デフォルトの名無しさん2011/12/02(金) 23:19:53.04
昔は順次、分岐、繰り返しの3つのデザインパターンしかなかったよな
などとつぶやいてみる
439 :デフォルトの名無しさん2011/12/02(金) 23:23:40.67
デザインパターンを明確に、正確に理解している = オブジェクト指向を明確に、正確に理解している
444 :デフォルトの名無しさん2011/12/02(金) 23:32:25.98
俺はドカタじゃないから、デザインパターンなんて知らなくていいんだよ。とか
本気で言ってそうwww
445 :デフォルトの名無しさん2011/12/02(金) 23:32:57.44
動的型付け言語にはデザインパターンはないとかいうような
バカどもですからねwww
446 :デフォルトの名無しさん2011/12/02(金) 23:34:23.72
Object = 目的語

これを言い出す人多いよね。自動詞的メソッドをどう説明するんだろうか?
Thread#runなど。
452 :デフォルトの名無しさん2011/12/02(金) 23:42:53.98
>>446
Threadクラスに対してrunというメッセージを送信する

I send run message to Thread
これの目的語というのが正しい気がする
460 :デフォルトの名無しさん2011/12/02(金) 23:54:24.79
やっぱり、デザインパターンとかオブジェクト指向に関しては
Javaプログラマがかなり先を言ってるね。
462 :デフォルトの名無しさん2011/12/03(土) 00:00:40.83
>>460
デザインパターンの市販本のほとんどが、Javaを使って説明しているからね。
465 :デフォルトの名無しさん2011/12/03(土) 00:02:12.81
>>462
Java以外にもたくさんあるぞ。
Amazonで「○言語 デザインパターンで」調べてみ。
463 :デフォルトの名無しさん2011/12/03(土) 00:01:49.43
>460
実はそのデザパタとかOOが遅れているということもあり得る
464 :デフォルトの名無しさん2011/12/03(土) 00:02:02.55
マーティンファウラーとケントベックがオブジェクト指向の先端という感じがする
この2人はJavaというよりsmalltalk

というかオブジェクト指向の発祥ってどこなの?
468 :デフォルトの名無しさん2011/12/03(土) 00:07:00.38
プログラムが綺麗にバグなくかければ、オブジェクト指向だろうが、関数型だろうがデザパタだろうが何でもいいです(´・ω・`)
実際はその辺のハイブリッドだしな。
470 :デフォルトの名無しさん2011/12/03(土) 00:10:36.03
>>468
バグの問題じゃないだろ。
OOのメリットは、既存のコードを変更しないで済むことなんだから。
494 :デフォルトの名無しさん2011/12/03(土) 01:59:32.30
>>470
コードの再利用の目的の一つにバグの低減があるとは思わないのかね?
498 :デフォルトの名無しさん2011/12/03(土) 09:47:42.48
>>468
その通り
500 :デフォルトの名無しさん2011/12/03(土) 09:53:43.85
>>470
>OOのメリットは、既存のコードを変更しないで済むことなんだから。
この俗説ほんとか?スパゲッティもまたそうやってできたのだが
501 :デフォルトの名無しさん2011/12/03(土) 10:25:36.25
>>500
既存のコードを修正しないで新たな機能を追加することができる
その機能を実装する(使う)ときは当然コードの修正は必要
しかしその使うという意志を表明している部分を変更するだけで済む

機能の追加と実装を分けて行えるのがメリットだと思う
503 :デフォルトの名無しさん2011/12/03(土) 11:38:25.79
>>501
OOでそれが出来る事に異論は無いが、OO以外では出来ないと思った理由は?
505 :デフォルトの名無しさん2011/12/03(土) 12:19:28.84
>>503
ポリモーフィズムが実現できればOK
C言語ではできない
508 :デフォルトの名無しさん2011/12/03(土) 13:20:03.35
確かこんな感じにできるな

【第4回】多態性(2/3):CodeZine
http://codezine.jp/article/detail/3709?p=2

>>503に解答すると
オブジェクト指向"言語"以外でもできない というわけではない
手続き型言語だとしても "オブジェクト指向" を採用することにはなる
しかしその場合オブジェクト指向"言語"ほどオブジェクト指向を容易に実現することができない

よってOOという思想を使わないと実現できない

ってことになるんじゃないのかな
510 :デフォルトの名無しさん2011/12/03(土) 13:37:07.72
>>508
ポリモーフィズムひとつとっても、OOPのそれは
subtype polymorphismというポリモーフィズムの一種にすぎない。
OOという思想を使わないと実現できないってことは無いよ。
512 :デフォルトの名無しさん2011/12/03(土) 13:56:24.05
>>510
ポリモーフィズムの実現にOOという思想を使わないと実現できない
ということは言ってないよ

>>470,>>500,>>501,>>503の流れとして、OOのメリットの1つはポリモーフィズムだよ
と言っているだけ
513 :デフォルトの名無しさん2011/12/03(土) 14:56:48.69
>>501
>既存のコードを修正しないで新たな機能を追加することができる
そのカラクリは要するになんだっけ?
514 :デフォルトの名無しさん2011/12/03(土) 17:45:07.71
>>513
ポリモーフィズム
それはOOの1つのメリット

これに何か問題ある?
515 :デフォルトの名無しさん2011/12/03(土) 17:53:30.03
>>514
俺には難しい説明だな。
それにポリモーフィズムってマイナーな特徴という認識なのだが
516 :デフォルトの名無しさん2011/12/03(土) 17:56:49.38
>>514
OO以外でも実現できるポリモーフィズムを
OOのメリットと呼ぶのに違和感がある
517 :デフォルトの名無しさん2011/12/03(土) 18:05:01.93
>>514 >>515 >516
OOが何であるかがはっきりしていないんだからあまり意味のない
コメントだな
519 :デフォルトの名無しさん2011/12/03(土) 18:23:07.26
>>516
まずOOのメリットはポリモーフィズムだけではなく、一般的にはカプセル化、継承もそれに加わる

あとOO以外で実現というのがそもそもおかしい

OO以外ではなく、オブジェクト指向”言語”以外でも実現できるというのは同意
手続き型言語でもオブジェクト指向の思想は反映できるということ

だと思ってる
523 :デフォルトの名無しさん2011/12/03(土) 18:59:14.45
>>519
ポリモーフィズムもカプセル化もオブジェクト指向に固有のコンセプトじゃない
関数型言語にだってある
526 :デフォルトの名無しさん2011/12/03(土) 19:22:25.60
>>523
それはマルチパラダイムということじゃなくて?
関数型言語の定義要素の1つとしてポリモーフィズムもカプセル化もあるの?
528 :デフォルトの名無しさん2011/12/03(土) 19:37:32.78
>>526
SMLにはポリモーフィズムもカプセル化(モジュールの)もあるけど
オブジェクト指向言語という人はいないと思う
529 :デフォルトの名無しさん2011/12/03(土) 21:31:40.86
>>528
ということはオブジェクト指向とそうじゃないものわ分けるには、ポリモーフィズム、カプセル化とは別の基準があると思ってるということだと思うけどそれはなんなの?

それともオブジェクト指向というものをそもそも認めないということ?
530 :デフォルトの名無しさん2011/12/04(日) 01:45:35.22
>>529
528じゃないが、原理の面から言って、オブジェクト指向かどうかは、
オブジェクトに指向してるかどうかが基準であって、
OOPLかどうかは、OOPをすることを目的として
言語が設計されてるかどうかの問題。

ある言語を使ってOOP出来るかどうかによって
その言語がOOPLかどうか決まるわけじゃない。

SMLは、オブジェクトの連携によって駆動するプログラムを
作るために設計された言語なの?


ちなみに俺は多態やらカプセル化やらは、OOのメリットだとは思ってない。
OOである方法論の単なる構成要素のうちの1つだと思ってる。
531 :デフォルトの名無しさん2011/12/04(日) 08:36:14.33
>>530
>ある言語を使ってOOP出来るかどうかによって
>その言語がOOPLかどうか決まるわけじゃない。
ここは>>519の通り同意見。

ではそのOOP出来るというのはどういうことを指すのかを知りたい
ポリモーフィズム、カプセル化、継承できることを指すのかと思っていたけど、
確かにこの3つは、何かを目指した手段と言われれば納得

その目指す先は「オブジェクトの連携によって駆動するプログラム」?
オブジェクトの連携によって駆動するプログラム とは具体的にどういうこと?
533 :デフォルトの名無しさん2011/12/04(日) 09:55:58.55
>>530
>オブジェクトに指向してるかどうかが基準であって
だからそのあなたが大事にしている「オブジェクトに指向してる」って
いうのはどういうことなの?
536 :デフォルトの名無しさん2011/12/04(日) 10:35:11.95
>>526
型クラス(typeclass)とか?
これは、どっちかというと、オーバーロードのニュアンスが強いから、ちょっと違うか
日本語訳も多相が使われるし
541 :デフォルトの名無しさん2011/12/04(日) 14:31:35.80
>>519
継承も多態性もカプセル化もメリットなんかじゃないだろ。
「ウチの車のメリットはV10エンジンを積んでることです」なんていうのかよ。
「リッター80kmで、1秒で100Kmまで出ることです」ってのがメリットだろ。
553 :デフォルトの名無しさん2011/12/04(日) 15:12:28.43
>>531>>533
OOPの基礎的な部分は属性と操作を持ったものをオブジェクトとして
それらが相互に操作しあって自分の属性を更新することで
プログラムが動作すること。
その基礎をもとに発展させた方法論のうちで代表的なものが
クラスベースの方法なんで、狭義なそれを暗黙にOOPと呼ぶ人も居る。
554 :デフォルトの名無しさん2011/12/04(日) 15:24:32.10
>>468
拡張に対して開きつつ修正に対して閉じてないと失格ですよ
555 :デフォルトの名無しさん2011/12/04(日) 15:28:25.33
>>500
例えば、下の実行引数解析コードだと、ArgumentとOptionAlphaとかの親となる、
Optionを書き換える必要は金輪際無い。あたらしい、オプションが必要になったら、
Optionクラスの子クラスを増やすだけ。引数解析の仕組みを増やしたければ、
Argumentの子クラスを増やすだけ。既存のOptionの子を書き換えたり、
Argumentの子を書き換えることはない。書き換えるとしたらバグがあったときくらい。

// クラス定義
OptionAlpha alpha;
OptionBeta beta;
public:
ExampleType( const Argument &arg )
{
       OptionMap options;
       options["a"] = α //GArgumentの場合は-aに対応
       options["alpha"] = α //GArgumentの場合は-alphaに対応
       options["b"] = β //GArgumentの場合は-betaに対応
       arg.Anarize( MapAdapter( options ) );
}

// 呼び出し
GArgument argument( argc, argv );
ExampleType example( argument );
559 :デフォルトの名無しさん2011/12/04(日) 15:37:25.58
>>553
>自分の属性を更新

ここの出典をプリーズ
569 :デフォルトの名無しさん2011/12/04(日) 15:54:59.70
>>559
ごめん。勢い余った。
そこは取り下げるからスルーお願いします。
585 :デフォルトの名無しさん2011/12/04(日) 16:35:58.87
かなり話が広がってきたけど >>501のメリットというのは、オブジェクト指向のメリットではなくポリモーフィズムのメリットということであってる?

それでオブジェクト指向とは何?
という話は >>553
でそのメリットはなんなんだろう?
587 :デフォルトの名無しさん2011/12/04(日) 16:41:59.71
>>585
>>501は実装と使用という全く別概念を同義に使ってしまうあたり
言葉の使い分けが微妙なので
引用して議論すると混乱の種になるぞ
588 :デフォルトの名無しさん2011/12/04(日) 16:42:02.27
>>585
オブジェクト指向とは、
クラスや継承やポリモーフィズムを総称した呼び方。

ポリモーフィズムのメリット=オブジェクト指向のメリット
597 :デフォルトの名無しさん2011/12/04(日) 17:36:57.77
>>588
総称はないな。そもそもクラスベースじゃないOOもあるし。
469 :デフォルトの名無しさん2011/12/03(土) 00:08:47.71
軽くぐぐったらSimulaからsmalltalkで普及みたいだな

メッセージ送信を唄っているsmalltalkのオブジェクト指向に合致しないのものは、また別のオブジェクト指向と捕らえるのが正しいのかね

クラス、型システムをオブジェクト指向として捉えて広めたのがまた別に誰かいた気がする
471 :デフォルトの名無しさん2011/12/03(土) 00:15:40.66
質問。
デザインパターンについて、30歳のSEに聞きました。
「あなたは、一パターンでもよいから、デザインパターンを適用したことがありますか?」
はい、と答える人は何人いると思う。
472 :デフォルトの名無しさん2011/12/03(土) 00:16:36.97
>>471です。
100人に聞きました、が抜けていた。スマン。
474 :デフォルトの名無しさん2011/12/03(土) 00:18:47.52
>>471
ドカタなら日常茶飯事に使ってるだろw
478 :デフォルトの名無しさん2011/12/03(土) 00:47:12.84
シングルトンの問題は、モックでの差し替えが困難なために、テストしづらくなる事。

レガシー本の例では、DBコネクションをシングルトンにした場合の呼び出し側のテストの書き方について書かれてる。
480 :デフォルトの名無しさん2011/12/03(土) 00:52:50.02
>>478
だよね。

だから最近はDIコンテナ側の設定で
シングルトンにするかどうかを決めるようになってきてるよね。

動的型付け言語の世界にも
早く普及してくれるといいんだけど。
497 :デフォルトの名無しさん2011/12/03(土) 08:00:27.07
>>480
動的型付けならシングルトンでもモックに差し替えるの簡単だから
普及しないと思うよ。必要無いもの。
479 :デフォルトの名無しさん2011/12/03(土) 00:50:26.49
ファクトリークラスって、何処までが範疇なのかね?

RequiredRuleFactory factory(param);
Rule *rule = factory.Create(arg);
こういうのが一般的だろうけど、

見た目さえ変えりゃ、これもファクトリーみたいなもんじゃん。
Query query("select %1 from table");
Result *result = query.Post(&db);
482 :デフォルトの名無しさん2011/12/03(土) 00:56:41.93
>>479
Postの戻り値がなんなのかさっぱりわからんけど、

もしそれがResultがインターフェース(抽象クラス)であるのなら
それはファクタリーだよ。

デザインパターンの本質
それは、実装ではなくて考え方なんだから
見た目(実装)は関係ない。

それがファクトリーの考え方による設計で、
実際にファクトリーの動作をしているのなら
それはファクトリーパターン
549 :デフォルトの名無しさん2011/12/04(日) 15:03:56.54
>>482
PostがResul返すかどうかはFactoryかどうかに本質的に関係ないだろ
そもそもResult以外返せばコンパイルエラーだ

俺の感覚では>>479はファクトリとは言わん。サブクラス切り替えて生成するインスタンスを変えてるんじゃないっしょ
486 :デフォルトの名無しさん2011/12/03(土) 01:23:24.32
明らかにインスタンスを1つに絞りたいのが目的の割にはどっからでもアクセスできすぎる
しかもインスタンスの生成場所まで変化するのはやりすぎ
あきらかに不具合
488 :デフォルトの名無しさん2011/12/03(土) 01:30:19.88
>>486 privateなコンストラクター書いてないし単にミスじゃね?
487 :デフォルトの名無しさん2011/12/03(土) 01:25:25.67
なんでメソッドの引数から渡すのを嫌ってグローバルアクセスにまわしたの?
ここの納得できる強力な理由がほしい
490 :デフォルトの名無しさん2011/12/03(土) 01:35:32.55
>>487
多分意図がちがうと思う。列挙型の要素みたいな感じなんだろ。
変化するもんじゃなさそうだ。
まぁ、だったらコンストラクターprivateにして、オブジェクト側は、
public const static MetaData PERSON_META_DATA = new PersonMetaData()でいいと思うけど。
491 :4562011/12/03(土) 01:45:55.35
>>485
ごめんね、頭の中が多態で使う〜でいっぱいになっててソースが不適切だった。
最初のソースでちゃんと説明していれば、頭の方で終わってた話だった。ごめん。

>>490
そうそう、Singleton の話だから private コンストラクタは書かなくても伝わるだろうと端折っちゃった。
const は書き忘れた。
495 :デフォルトの名無しさん2011/12/03(土) 02:00:19.19
コードを再利用したら一つのバグが
何百個のバグになるだろ。
496 :デフォルトの名無しさん2011/12/03(土) 02:09:25.34
何百ヶ所のバグを修正するよりは、一ヵ所のバグを修正する方がマシだろ。
499 :デフォルトの名無しさん2011/12/03(土) 09:51:28.65
漏れは2年間ほど掛かったが、オブジェクト指向設計をマスタしました。
2,3のデザパタも習得しました。
これから残りのデザパタを習得するつもりです。
そこで教えてもらいたいのですが、どのデザパタが現場では使われますか。
全部なら全部でもよいのですが、よく使われるものは何か知りたいのです。
列挙していただけたら非常に助かります。
507 :デフォルトの名無しさん2011/12/03(土) 12:46:08.43
組込みだとOOA、OODで開発進めて
実装はANSI Cという世界だったりするよ
509 :デフォルトの名無しさん2011/12/03(土) 13:21:05.82
カプセル化もC言語で実現できるし継承も無理矢理実現できる
極端な話他の言語の多くはC言語で作られているのだからできないわけがない
じゃあC言語は、オブジェクト指向言語や関数型言語なのか?というとそんなことはない
518 :デフォルトの名無しさん2011/12/03(土) 18:17:36.32
最低限このへんは読んでから書き込むべき
ttp://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
520 :デフォルトの名無しさん2011/12/03(土) 18:32:31.54
>>518
だれに言ってるのかどこを読めと言ってるのか知らんがそういうのは
踏まえたうえでの議論だと思うが
521 :デフォルトの名無しさん2011/12/03(土) 18:41:58.66
>>518
ML polymorphism がアヒャってのはわかった
522 :デフォルトの名無しさん2011/12/03(土) 18:48:15.75
>>520
1.3章あたりに polymorphism のざっくりとしたレビューが書いてあるから、そこじゃね?
OOP の polymorphism にも触れてる
527 :デフォルトの名無しさん2011/12/03(土) 19:34:37.47
>519
オブジェクト指向の思想って?
与太話になりそうで好かん
532 :デフォルトの名無しさん2011/12/04(日) 09:38:50.28
破壊的操作(副作用)に対するスタンスがOOPと関数型言語では違う気がする

関数型では破壊的な操作を必要最小限にする方向を目指すけど、
オブジェクト指向ではそんなこと無くて、その代りに
レースコンディションの解消はオブジェクトが各自の責任で行う
537 :デフォルトの名無しさん2011/12/04(日) 10:52:24.17
>>532
それは関数型言語とそれ以外の言語の比較であって、オブジェクト指向の特徴とは言えないような…
534 :デフォルトの名無しさん2011/12/04(日) 10:11:45.44
昨日、コンポジット、プロキシパターンを勉強した。
コンポジットには感激した。これは使える。
535 :デフォルトの名無しさん2011/12/04(日) 10:28:38.10
>>534
>コンポジットには感激した
その大部分は再帰に感激したのかな?それとも
538 :デフォルトの名無しさん2011/12/04(日) 11:07:06.06
>>535
再帰はもちろんだが、単独者と部下持ちの区別をパターンでやってしまうところがよい。
539 :デフォルトの名無しさん2011/12/04(日) 11:22:16.90
>>535
区別?むしろ同一視するんじゃなかったっけ
細かくてスマン
540 :デフォルトの名無しさん2011/12/04(日) 11:35:19.65
>>539
>>538です。細かいことはSEとしてはよいことです。
区分という表現は曖昧でした。エレメントがあるかないかを見て分別しているでした。
546 :デフォルトの名無しさん2011/12/04(日) 14:55:47.66
>>540
曖昧なんじゃない、不適切だ
552 :デフォルトの名無しさん2011/12/04(日) 15:11:48.84
>>534
その二つなら寧ろProxyに感激してほしいなあ
542 :デフォルトの名無しさん2011/12/04(日) 14:37:11.89
リッター80kmで、1秒で100Kmまで出る
エンジンを積んでるのはメリットだけど?

もしかして継承や多態性やカプセル化で
何が出来るか知らないってこと?
そこから説明しないといかんの?
543 :デフォルトの名無しさん2011/12/04(日) 14:47:25.08
>>542
「V10エンジン」を積んでることは別にメリットじゃない。
同じ性能出るエンジンなら別のエンジンでも構わない。

同じことが出来るのであれば、別に継承である必要でもないし、
カプセル化である必要もないし、多態性である必要もない。
544 :デフォルトの名無しさん2011/12/04(日) 14:52:53.90
継承だって、サブクラス化や、転送とか環境により別の実現方法があるし、
カプセル化だってOO的な手法じゃなくクロージャで実現する方法もある。
多体性というならドライバ関連でOO以前からありふれてた
OOのメリットとは言わん。
548 :デフォルトの名無しさん2011/12/04(日) 14:59:25.39
>>544
クロージャでカプセル化するとき、OO的な思考が入ってるはず。クラス的な手法じゃなく、ならともかく。
どちらもOOの実現方法にすぎんでしょ。
550 :デフォルトの名無しさん2011/12/04(日) 15:04:35.72
>>548
クラスがあるから、C++は、C#の思想が入ってるといってるのと同じ。
視点がおかしい。
551 :デフォルトの名無しさん2011/12/04(日) 15:10:00.83
>>550
んーそうかー?
クロージャでカプセル化するんなら、何かを隠蔽して、それを何かで公開してるんだよな?
それをOO的な思考で実装しないことが出来るとでも?っ・・・ってできるかorz

まーでも、普通そーいう雑な設計はしないっしょ。何がしたくてカプセル化なのか謎すぎだから。
556 :デフォルトの名無しさん2011/12/04(日) 15:31:58.08
>>551
肝心なトコが抜けてる。日本語的な意味でおかしいと言ってんの。
OOがクロージャを、クロージャがOOを含んでるんじゃなく、
カプセル化を、OOとクロージャが含んでんの。だから視点がおかしいといってる。
560 :デフォルトの名無しさん2011/12/04(日) 15:39:49.19
>>556
興味深いので拘ってみたいんだけど

>カプセル化を、OOとクロージャが含んでんの。

は同意だけど(個人的には含んでるってよりインプリしてるの方がしっくりくるけど)
単独の関係を検証してるならそれでいいけど、先の話はそれとは別でしょ。
先の話題は、クロージャでカプセル化を実現、した時の話だから、
それをOO視点無しでする設計って現実にあるの?ってこと。
562 :デフォルトの名無しさん2011/12/04(日) 15:44:31.52
>>560
逆に、クロージャ的視点なしでオブジェクト設計する事があるの?と言える。
そもそも、クロージャは3番目にできた言語であるLispで実装されたもの。
どちらかと言えば、クロージャの設計思想をOOがうけてるって言ったほうが正しい。
smalltalkのブロックだって、無名関数がベースだしな。
567 :デフォルトの名無しさん2011/12/04(日) 15:53:59.14
>>562
あると思うけど、どうかな?
クロージャ言ったらレキシカルスコーブっしょ。プロトタイプベースのOOでない、クラスベースのOOにその視点は登場しないと思われる。
そもOOなJavaにはクロージャないし。
570 :デフォルトの名無しさん2011/12/04(日) 15:56:59.84
>>567
まず、smalltalkなんかは、メソッド自体が一つのクロージャ。
それから、OOで言えば、オブジェクト自体がある種のクロージャであり、
オブジェクトのメソッドが、コンストラクターと、実行メソッドだけであれば、
無名関数と同様の動作になる。
572 :デフォルトの名無しさん2011/12/04(日) 16:02:55.05
>>570
んー
クロージャの定義をどのあたりにしてるか教えて貰えるかい?
ちょっと広義にしすぎてて、実はそのクロージャと呼んでるのクロージャでない別の何かだったりしないかな?

個人的には、クロージャではコンテキストって概念が鍵になると思ってるから、OOなオブジェクトってだけでは、背後にクロージャという概念が隠れてるとは感じられないんだけど
573 :デフォルトの名無しさん2011/12/04(日) 16:06:02.72
無名関数は語弊があった、高階関数ね。

>>572
多数の言語でクロージャと言われてるものの最大公約数。
基本的には、Lispのラムダ、Smalltalkのブロック、BCBで使えた__closure。
574 :デフォルトの名無しさん2011/12/04(日) 16:09:13.35
>>570
smalltalk は知らないけれど、クロージャはそこでのコンテキストに束縛されるところがキモでは。
まあ、OO でもオブジェクトが使う全てを環境としてコンストラクタに渡す、
というような仕掛けで模倣することはもちろん可能だと思うが。

とはいえ、それを明示的にやったら最早クロージャとは言わないと思われ。
# lambda lifting を手でやってるだけ
545 :デフォルトの名無しさん2011/12/04(日) 14:54:41.81
ということで極論すれば
アセンブラでOKと言いたいわけかw
547 :デフォルトの名無しさん2011/12/04(日) 14:55:53.00
クロージャーじゃなくても
ジャンブで実装できるしな。
558 :デフォルトの名無しさん2011/12/04(日) 15:36:27.06
紛らわしいこと書いたな。

>ArgumentとOptionAlphaとかの親となる、Optionを書き換える必要は金輪際無い。
訂正: OptionAlphaとかの親となるOptionと、Argumentを書き換える必要は金輪際無い。
561 :デフォルトの名無しさん2011/12/04(日) 15:42:35.00
Adapterパターンって元々のクラス設計者の設計間違いを利用者が尻拭いしてるだけみたいに見えるんだけど
これがはじめから有効な場合ってどういう場面なんだろう

もしくはDuckTypeで動く言語ならかなりの場合不要なような気がする
563 :デフォルトの名無しさん2011/12/04(日) 15:45:55.99
>>561
イベントドリブン。
転送機構の代用品になる。
564 :デフォルトの名無しさん2011/12/04(日) 15:46:31.68
>>561
尻拭いの感覚でだあたいあってる。
新インタフェースをAdapteeに旧インタフェースAdapterに使うのがデフォだから。
設計間違いと言えるかはケースバイケース。仕様変更だつ
566 :デフォルトの名無しさん2011/12/04(日) 15:51:11.15
>>561
ダックタイプじゃ代用にはならんよ。
異なるオブジェクトから同じイベントで1つの名前のメソッドを呼ばれたら、
どのみち、イベント元を区別できないし。
568 :デフォルトの名無しさん2011/12/04(日) 15:54:38.78
>>564
キーを2つ取るマップとキーを1つ取るマップの橋渡しとか、
独立性と柔軟性を上げてる訳で、別に尻拭いがメインじゃないだろ。
571 :デフォルトの名無しさん2011/12/04(日) 16:00:47.94
>>566
完全な代用にはならないけどかなり多くの場合ダックタイプで救えない?

あるいは言い換えると、ダックタイピングのような機能を持っていない言語は
仕様変更や要件定義漏れに弱いために、デザインパターンという
いわゆる逃げを使わなきゃいけない、といえるのかも
577 :デフォルトの名無しさん2011/12/04(日) 16:17:07.42
>>566
異なるオブジェクトからあるオブジェクトの同じメソッドを呼び出して、
そのメソッド内で呼び出し元を区別したいっていうの?
それ、ObserverパターンかVisitorパターンと混乱してない?
578 :デフォルトの名無しさん2011/12/04(日) 16:17:11.94
>>563>>566
がわからんのだが、Adapterとイベントドリブンって何か関係あったっけ?
579 :デフォルトの名無しさん2011/12/04(日) 16:20:19.54
>>568
良い指摘?
586 :デフォルトの名無しさん2011/12/04(日) 16:36:46.13
>>571
Adapterパターンって元のメソッドのシグニチャを変えたいって話だと思うから、
ダックタイプがそもそも結びつかない気がするんだけど
595 :デフォルトの名無しさん2011/12/04(日) 17:23:11.21
>>586
ダックタイピングが利用できると、そのシグネチャを変えなくても
あとから利用側が同じシグネチャに合わせることができる場面が多いっていう
意味じゃない?
614 :デフォルトの名無しさん2011/12/04(日) 22:46:48.06
>>577
javascriptで書くけど、Observer、Visitorってのは、ここまでの範囲じゃん。
button.addEventListener("click", function( event ){ alert( "I'm visitor." ); }, false);

Adapterでイベントを区別するってのは、こういうこと。
function StartAdapter( delegateTarget ) { function( event ){ delegateTarget.start() } }
function StopAdapter( delegateTarget ) { function( event ){ delegateTarget.stop() } }

var mainLogic = new MainLogic();
buttonA.addEventListener("click", StartAdapter( mainLogic ), false);
buttonB.addEventListener("click", StopAdapter( mainLogic ), false);
618 :デフォルトの名無しさん2011/12/04(日) 23:36:58.80
>>614
ええと、かなりわからん・・・ごめん。
それはAdapteeは
mainLogic.start()、mainLogic.stop()でいいの?
で、
buttonA.addEventListener("click", mainLogic.start, false);
で済ますことができないシチュエーションがあるってことでいい?

そして
「異なるオブジェクトから同じイベントで1つの名前のメソッドを呼ばれたら、」
っていう文言を翻訳すると、

異なるオブジェクト : buttonA および buttonB
同じイベント : addEventListener("click")
1つの名前のメソッド : *Adapter(mainLogic) ???

ってことかな?最後のは別に1つの名前のメソッドじゃないから、違ってる気がする。
619 :デフォルトの名無しさん2011/12/04(日) 23:47:09.77
>>614は俺も分からんな
621 :デフォルトの名無しさん2011/12/04(日) 23:48:50.87
>>618
>buttonA.addEventListener("click", mainLogic.start, false);
これができる言語なんて無いでしょ。デリゲートなり無名関数をアダプターとして挟まない限り無理。
622 :デフォルトの名無しさん2011/12/05(月) 00:06:02.44
>>618

function method( event ) { alert( "多分、buttonAかbuttonBのどっちかから呼ばれたと思う" ) }
buttonA.addEventListener("click", method, false);
buttonB.addEventListener("click", method, false);

クラスを省いてるんで、また誤解があるかもしれないが、
一つのメソッドが呼ばれると、何処からよばれたか解からんというのは、こういう状態。

勿論、methodが、buttanAと、buttonBを参照してれば、eventオブジェクトで区別は付けられる。
その代わり、buttonAとbuttonBからmethodを切り離せなくなるんで、現実的じゃない。
633 :デフォルトの名無しさん2011/12/05(月) 03:18:52.18
>>614はJavaScriptじゃなくJavaで書けば良かったのに
638 :デフォルトの名無しさん2011/12/05(月) 06:16:12.50
>>614がよくわからないんだけど、誰かJavaで頼む
StartAdapterって何するメソッドなの?
642 :デフォルトの名無しさん2011/12/05(月) 07:30:45.00
>>638
Swingが解るなら、StartAdapterってのは、他のインターフェースのメソッドを
一つ呼ぶだけのListenerオブジェクトだよ。

JButton button1 = new JButton()
JButton button2 = new JButton()

StopWatch mainLogic = new StopWatch();
button1.addMouseListener(new StartAdapter(mainLogic));
button2.addMouseListener(new StopAdapter(mainLogic));

Javaで書くとこんな感じか。
647 :デフォルトの名無しさん2011/12/05(月) 08:22:39.04
>>642
ありがとうよくわかった
ListenerはAdapterパターンが使われているよという主張なのか
660 :デフォルトの名無しさん2011/12/05(月) 20:06:23.40
>>647
解ってるかもしれないけど、
Listener = Adapterじゃないからね。
Listenerの中で、複数のオブジェクトや
制御構文を並べて複雑な処理をしてたら、
もはやAdapter(適応)パターンじゃない。

あくまでも、イベントを他のオブジェクトに渡すだけの
最低限の実装で有るべき。Adapterの中で、文字列から
数値型に変えて引き渡したり、ファイル型に変えて
引き渡すぐらいはいいけどね。
665 :デフォルトの名無しさん2011/12/05(月) 20:46:38.00
さて>>561に戻るか。
Adapterパターンは、結局ダックタイピングできる言語だろうと、
高階関数つかえる言語だろうと、無意識かもしれんが、使う人は使ってる。
尻拭い以外に使ってることも多いんだよ。
669 :デフォルトの名無しさん2011/12/05(月) 21:26:17.89
>>668
なんでAdapterなのに継承してんの?
Adapterが別のクラスにくっついてちゃいかんだろ。
>>660にも書いたが、あくまでAdapterは、
別のオブジェクトのメソッドに受け渡すだけ。

Listener = Adapterでは無いが、Listenerに
Adapterを使うこと自体は問題ない。
691 :デフォルトの名無しさん2011/12/05(月) 22:39:39.69
>>689
TemplateMethodの見通しが良いかは分からないけど、上二行に関しては同意

ていうか頼むから>>614や>>642のようなアホコードは書かないで欲しいもんだね
696 :デフォルトの名無しさん2011/12/05(月) 22:45:44.95
>>691
例としてわざとそう書いてるのに空気読めないねぇ。
700 :デフォルトの名無しさん2011/12/05(月) 22:47:06.50
>>696
例として不適切なのが相変わらず理解できないのね
565 :デフォルトの名無しさん2011/12/04(日) 15:49:07.26
仕様変更だったり、要件定義漏れだったりもするし
最初から使うのは、既存ライブラリをこちらの自持ちAPI都合で都合よく再利用する場合とか
575 :デフォルトの名無しさん2011/12/04(日) 16:11:19.45
Smalltalkのブロック式はSchemeのクロージャと同様
レキシカルな文脈で環境を補足するよ
576 :デフォルトの名無しさん2011/12/04(日) 16:13:30.92
>>575
ブロック式がオブジェクトなの?
580 :デフォルトの名無しさん2011/12/04(日) 16:20:21.52
>>576
BlockContextクラスのインスタンス
581 :デフォルトの名無しさん2011/12/04(日) 16:24:40.88
>>580
他のクラスはインスタンス化のタイミングで環境を補足しないの?
BlockContextクラスだけ特別扱いになっている?
しっくりこない。
582 :デフォルトの名無しさん2011/12/04(日) 16:31:04.75
環境捕捉はインスタンス化のタイミングってより関数定義のタイミングなんじゃないかな?
まー、Smalltalkerでない俺は話題についてけてないんだけど
583 :デフォルトの名無しさん2011/12/04(日) 16:32:11.30
デザパタ・オブジェ厨はすぐに孤立するな。優秀なんだが。
584 :デフォルトの名無しさん2011/12/04(日) 16:34:50.29
よくわからんけど、スタックフレームへのポインタをフィールドに持っている、
みたいな感じ?うーむ・・・
これはオブジェクト指向とは関係なく、Smalltalk でクロージャを実現するための言語機能とみるべきじゃないの?

589 :デフォルトの名無しさん2011/12/04(日) 16:45:50.80
オブジェクト指向のメリット
=カプセル化のメリット
+インヘリタンスのメリット
+ポリモーフィズムのメリット
+ダイナミックバインディングのメリット

一つ一つは他のパラダイムでも実現できるけど
これらをバランスよく実現して普及したパラダイムがオブジェクト指向だった。

では駄目なの?
616 :デフォルトの名無しさん2011/12/04(日) 23:17:54.07
>>589
仕組みで言っても仕方ないって。
OOPLってのは、OOの目的を達成を支援する事を標榜してるだけで、
目的のためなら、手段は色々なんだから。実装継承の無いOOPLもあるし、
javascriptみたいにカプセル化を持たない言語もある。多態性に関しては、
コアなんで、流石にサポートしない言語は無いけど。

OOは、そもそもSimulaのシミュレーションから着想を得て発展させたもの。

水分子や、酸素分子はそれぞれ別の振る舞いをする。
酸素の溶けた水中は、グラフ構造で表現するのが自然だが、
グラフのノードたる、水分子、酸素分子は別々の振る舞いをしてしまう。
これを上手く、自然に再現するには、既存の手法や言語ではどうしても不細工だった。
それをキレイに表現しようと発展したのがSimula。
更にこのノードをオブジェクトとして定義し、分子などをコンピュータ上のリソースに応用しようと
考えたのが、SmalltalkとC++であり、その考えがオブジェクト指向となっている。

なので、OO概念 = 異なるリソースのグラフ構造表現 だ。
ノード単位での並列化を加えたものがアクターモデルと呼ばれていることからも、
概念は、はっきりしている。

OOPLとは、あくまでこの「異なるリソースのグラフ構造表現」をどれだけ楽に実装できるかを
目指した言語であるだけで、別にどの機能を持っているからOOPLという話ではない。
617 :デフォルトの名無しさん2011/12/04(日) 23:20:54.93
>>616
読むのだるいんで、下らない喩え話を省いて。
620 :デフォルトの名無しさん2011/12/04(日) 23:47:18.66
>>617
OOPLとは、あくまでこの「異なるリソースのグラフ構造表現」をどれだけ楽に実装できるかを
目指した言語であるだけで、別にどの機能を持っているからOOPLという話ではない。
623 :デフォルトの名無しさん2011/12/05(月) 00:21:57.04
>>620
2ch の長文はオレオレ理論なのか根拠のある話なのか判別が付きにくいから
原典へのリンクも張って。
634 :デフォルトの名無しさん2011/12/05(月) 03:24:26.32
>>616
数学は天文学だとか言うのと同じ程度に眉唾なんだが
発展経緯を知ることは意味があるけど、それがイコール定義ではないでしょ
639 :デフォルトの名無しさん2011/12/05(月) 06:22:41.87
>>616
構造が目的なのではなくて、相互作用が目的じゃないのか?
グラフ構造というよりも、異なる単位間の相互作用、のほうがしっくりくる。

で、流派的には
ケイが動的で柔軟な相互作用を追求し、
ストラウストラップは効率的な相互作用を指向して、
メイヤーは各単位の拡張性/整合性に注目した。
643 :デフォルトの名無しさん2011/12/05(月) 07:43:33.94
>>634
じゃあ訊くけどさ、数学の定義を示してくれたまえ。
その上で、その定義とやらが義務教育を受けた一般人にとって
どれだけ眉唾なものか議論しようじゃないか。
653 :デフォルトの名無しさん2011/12/05(月) 09:30:03.43
>>643
脱線は一人でやってくれたまへ
コンピュータサイエンスの目的は軍事だという話題もあるぞ
590 :デフォルトの名無しさん2011/12/04(日) 16:49:17.98
レイトバインディングやポリモフィックな言語機構ってOOなら必ず持つんだっけ?
591 :デフォルトの名無しさん2011/12/04(日) 16:53:51.43
言語設計者がこれはOOPLだって言ったらOOPL
594 :デフォルトの名無しさん2011/12/04(日) 17:06:47.18
>>591
つまり規範的な概念ではなく記述的な概念ってことか
ファウラー風に言えば
596 :デフォルトの名無しさん2011/12/04(日) 17:27:51.25
Adapteeのシグニチャが既に固定なんだから、ダックタイプじゃ切り抜けられないっしょ。
ガーと鳴かない状況でガーいわせるんだから。そこでガー言わせるIFミスマッチ埋めがAdapterなんだから。
598 :デフォルトの名無しさん2011/12/04(日) 17:41:55.48
その程度の反論には、
クラスベース または プロトタイプベースって
言い換えるだけだよ。
599 :デフォルトの名無しさん2011/12/04(日) 17:42:26.07
「OOっぽいもの」と「よりOOっぽいもの」があるだけで定義付けは不毛
601 :デフォルトの名無しさん2011/12/04(日) 17:49:31.36
AdapterはJavaでいうとclassファイルがjarで提供されているけど、srcファイルは提供されていない
その機能を現在作成中のプログラムの中で、使いたいんだけどインターフェースがあっていない
だからAdapaterを作成してインターフェースを合わせましょう
っていう話だよね

以下委譲を利用したAdapter

提供されているクラス 変更不可
class Adaptee{
int test(int a, double b){
return a + b;
}
}

自分が作成しているクラス インターフェースは変更不可

Interface Test{
void test(double b, int a);
}

class Adapter implements Test{
private Adaptee adaptee = new Adaptee();
void test(double b, int a){
adaptee.test(a,b);
}
}
608 :デフォルトの名無しさん2011/12/04(日) 21:16:28.61
>>601
> っていう話だよね
違う
ソースが提供されているかどうかは全く関係ない
609 :デフォルトの名無しさん2011/12/04(日) 21:27:36.46
>>608
ソースが提供されていたら、自分のインターフェースに合わせて変更してしまえばいいんじゃないか
と思っちゃうんだけど違うのかな

提供されているクラスは充分にテストされているから、変更せずにそのまま利用したい
ということ?
612 :デフォルトの名無しさん2011/12/04(日) 22:16:40.16
>>611は>>609宛です
602 :デフォルトの名無しさん2011/12/04(日) 19:26:20.03
自分が作成しているクラスのインターフェースが変更不可って場合はダックタイプでも救えないってわけね。
603 :デフォルトの名無しさん2011/12/04(日) 19:30:53.02
継承がなくて委譲だけをひたすら使う場合でもオブジェクト指向って言うんじゃねえ?
とすると

オブジェクト指向 = (クラス | プロトタイプ) and (継承 | 委譲) ans 多態性 の総称

すっげぇ定義しづらい・・・
607 :デフォルトの名無しさん2011/12/04(日) 20:09:33.66
sole insntanceはあるクラスのインスタンスが
一つしか存在しないということを指す言葉。
たとえばTrueクラスのインスタンスはtrueのみ。

Singletonはあるクラスのインスタンスを
一つに制限するときに使うパターン(コード・設計)。

あるクラスをsole insntanceにするときに使うのが
Singletonパターン。こういう使い方をする。

Singletonとsole insntanceは別物
637 :デフォルトの名無しさん2011/12/05(月) 06:12:22.51
>>607
違うよ。
つーか、クラスをsole instanceにするとか、用法がメチャクチャだぞw

1つのクラスのインスタンスが1つしかない状況を仮定して、
そのインスタンスを指す言葉がsole instanceで、
そのクラスを指す言葉がsingletonだ。

Smalltalkではinstanceに注目してsole instanceと呼んでいたが、
GoFではよりクラス寄りになったJava等にあわせてsingletonと呼ぶことにした。
610 :デフォルトの名無しさん2011/12/04(日) 21:29:12.84
動的型付け言語使いなんだろ?
インターフェースが変わるとコードもテストも
大量に修正が必要になる。
だから変えようと思っても変えられない。

リファクタリング機能が充実している
Javaでは信じられない発想。
613 :デフォルトの名無しさん2011/12/04(日) 22:40:21.43
>>610
Java使ってるのにソースの互換性を考えたことないのね
611 :デフォルトの名無しさん2011/12/04(日) 22:15:38.03
例えばGUIアプリケーションのプレゼンテーションモデルとドメインモデルとの関係を
考えると分かりやすいと思う。
ドメインモデルを直接変更してしまうと、表示画面に特化した再利用性の低い
ものになってしまうので、アダプターパターンを適用する。

プレゼンテーションモデルというのはJavaのJComboBoxにおけるComboBoxModel
などのことで、アダプターパターンを用いることで、どんな形のクラスであってもソースの
修正なしにコンボボックスという形で表示することができる。
615 :デフォルトの名無しさん2011/12/04(日) 22:48:05.84
間違った、こうね。
function StartAdapter( delegateTarget ) { return function( event ){ delegateTarget.start() } }
function StopAdapter( delegateTarget ) { return function( event ){ delegateTarget.stop() } }
625 :デフォルトの名無しさん2011/12/05(月) 01:57:24.77
>>615
StartAdapterとその中身の無名関数とで冗長
あと大文字で始めるのやめれ、見づらい
626 :デフォルトの名無しさん2011/12/05(月) 02:18:25.48
>>625
別に冗長ではないだろ
これは、あくまで例だが実際には、
mainLogic以外のオブジェクトも渡す理由だから
無名関数だったら毎回function(event){・・・.start()}って
かかないといけないじゃん
630 :デフォルトの名無しさん2011/12/05(月) 02:57:21.85
>>626
startじゃなくinitの方が適切な名前だったなーとか、併せて初期サイズを引数で渡した方がいいねーとかなったら

function InitAdapter( delegateTarget, initialSize ) { return function( event ){ delegateTarget.init(initialSize) } }
に変えて
buttonA.addEventListener("click", InitAdapter( mainLogic, initialSize ), false);
にするの?

buttonA.addEventListener("click", function(){ mainLogic.init(initialSize) });

ってだけで済むところを。どんなメリット求めてパターン使ってるの?っていう

635 :デフォルトの名無しさん2011/12/05(月) 03:38:19.77
>>630
startが変化しなけりゃ引数増やす必要ないだろ。
そもそもstartがイベントを受け取る事を前提にしてるなら、
引数が増えたりすることがおかしい。あくまでイベントを別のメソッドで
受け取るためにアダプター噛ましてるだけなんだから。

それはともかくとして、関数に名前付けてんのは、
無名関数を作れない環境でも同じだという事を強調した。
無名関数単品でも他のオブジェクトのメソッド呼ぶだけならアダプターではある。

それはともかく、ダックタイピングが使える環境だろうと、無名関数を作れない
環境だろうと、アダプターをイベントで使うというのがわかればいい。
Javascriptでどれだけキレイに書けるか、Javascriptのセオリーに
従うならどうかなんては問題にしてない。
636 :デフォルトの名無しさん2011/12/05(月) 04:02:54.16
>>635
引数が増えたりするのは少しもおかしくない
Textで設定値を指定するとか、普通にある

そもそもTargetインターフェースが固定なんだから、Adapteeは可変が前提でしょ。そこ否定してどーすんのさ

おまけ。
問題にしてないと言うなら、主題に沿わないコード断片を書き散らすのやめれ
フォーカスがブレたのなら、それは焦点を絞らなかった書き手の問題だよ。
641 :デフォルトの名無しさん2011/12/05(月) 07:17:19.29
>>636
無いな
C#使ってて、イベントを受け取るために使った場合の
Delegateは、イベントが発行する以上の引数を持たせる事はできないし
テストのために、追加の引数を渡せるように
Delegateオブジェクトを拡張したなんて聞いたことがない
650 :デフォルトの名無しさん2011/12/05(月) 09:24:05.72
>>641
Adaterが話題になってるのに、またズレたレスをしたもんだな
655 :デフォルトの名無しさん2011/12/05(月) 13:08:57.91
>>635
こういうのもAdapterパターンと呼ぶってこと?
まあ別に良いけど

map(lambda x: x + 1, range(1,10))
657 :デフォルトの名無しさん2011/12/05(月) 19:39:14.35
>>655
lambdaにより、処理を差し替えれる事から、Strategyになるんじゃない?

もしくは、double-dispatchなしの簡易版Visitor (イディオムとして名前がついていたような記憶があるが思い出せない)
624 :デフォルトの名無しさん2011/12/05(月) 01:41:33.35
Simula and Smalltalk: A Social and Political History
http://www.cebollita.org/dugan/history.html

アランケイへのオブジェクト指向とはなんぞやというインタビュー
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

「異なるリソース(複数のコンピューターとか)のグラフ構造表現」とまではっきり書いてないが、
要約すると、そういう事を書いてある。基礎概念が、コンピューターネットワークが
細胞間のメッセージングと同じように考えられるとか、ニューロンネットワークとか、
通信網のシミュレーションは、アルゴルのような従来の言語ではやりづらかったとかね。

640 :デフォルトの名無しさん2011/12/05(月) 07:07:44.20
>>634
>>624以上のソースを出せと言われたら
もう、ISO/IEC 2382-15しか無いんだがな。
知りたいなら高い金だして買ってくれ。
629 :デフォルトの名無しさん2011/12/05(月) 02:49:05.79
レキシカルスコープなのに、わざわざ関数作って冗長にする意味ないっしょ
分かりやすさがダンチ
632 :デフォルトの名無しさん2011/12/05(月) 03:06:18.84
イベントハンドラが実はアダプタ使ってるって指摘は面白かったと思う
646 :デフォルトの名無しさん2011/12/05(月) 08:15:32.26
ボタンを押された時に実行する処理が、特定のロジックを起動するだけという場合でも、
イベントリスナとして登録するためには、イベントを受け取る関数の形に合わせる必要がある。

これは、ロジック側のインタフェースをイベントリスナとして要求されるインタフェースに
変換しているという見方もできて、その見方をするならば、
そこで作成されるイベントリスナオブジェクトはアダプタパターンを使っているとも言える。

という理解でいいのかな?
確かにそういう考え方をしたことはなかった。>>632 同意。
644 :デフォルトの名無しさん2011/12/05(月) 07:51:47.10
関数がファーストクラスのオブジェクトじゃない、
ラムダすら無いうんこな言語で使うパターンですね
645 :デフォルトの名無しさん2011/12/05(月) 08:01:44.78
Javaでデザパタ学んだ奴って他言語でも
冗長なコード書くよな
まさにデザパタの弊害って感じ
652 :デフォルトの名無しさん2011/12/05(月) 09:26:43.89
>>645
おまえやおまえの周りがそうだからといって
勝手に一般化するなよ
世界はお前が認識してるより広いんだ
648 :デフォルトの名無しさん2011/12/05(月) 08:36:01.22
そんな当たり前なことで大絶賛とはw
651 :デフォルトの名無しさん2011/12/05(月) 09:24:19.17
>>648
誰も大絶賛してないと思うけど
そもそもそれがAdapterと納得している人はいない気がする
649 :デフォルトの名無しさん2011/12/05(月) 09:15:31.67
ついでに質問なんだけど、Listenerってどの単位でクラス分割すればいいの?

ボタンごとに完全にクラス分けるのか、ある程度は画面ごとにListenerをまとめて押されたボタンを取得してif文で処理分けるのか

理想を言えば前者がいいんだろうけど、クラスすごく増えるんだよね
661 :デフォルトの名無しさん2011/12/05(月) 20:13:46.38
やっぱり無名関数を使わず、Targetインターフェースに名前が付いてる場合だけを
Adapterと呼ぶんじゃないか?
662 :デフォルトの名無しさん2011/12/05(月) 20:22:27.57
コード書けないドカタSEが言葉を弄んでいるだけ
663 :デフォルトの名無しさん2011/12/05(月) 20:25:20.75
>>657
lambdaの中で+(__add__メソッド)を呼ぶだけだから、>>635の定義
> 無名関数単品でも他のオブジェクトのメソッド呼ぶだけならアダプターではある。 
ならアダプタパターンってことになるな

まあ、>>662の言う通りだと思うわ。言葉遊びっつーか馬鹿みたい
664 :デフォルトの名無しさん2011/12/05(月) 20:39:49.98
今はAdapterパターンばかり槍玉に上がってるけど、
StrategyやらCommandやらVisitorやら、他にもインターフェースを駆使して動的な性質を取り入れようとしているパターンには
動的型付けとかクロージャとかミックスインで代替できるものがいっぱいあると思うよ
モダンな言語はデザパタに頼らずに、よりスマートでソースコードの見通しがいい方法で解決すべき。
666 :デフォルトの名無しさん2011/12/05(月) 21:11:06.69
>>664
転送と高階関数で、見かけは存在しないように見せかけられる。
本質的にゃ変わりゃしない。
667 :デフォルトの名無しさん2011/12/05(月) 21:13:08.65
高級言語はその見かけが大事なんじゃねーか
689 :デフォルトの名無しさん2011/12/05(月) 22:34:03.85
>>667
これにつきるな。ソースコードは設計書であるべきだから本質的でないものが混ざるとストレスたまる。
デザパタはその見通しを悪くするものが多いから、本当に必要なとき以外は極力排除したい。

TemplateMethodみたいに見通しよくするものもあるけど。
668 :デフォルトの名無しさん2011/12/05(月) 21:16:09.15
Adapter=Listenerは間違い
委譲を利用するAdapterだと違和感が少ないけど、継承を利用するAdapterだと気持ち悪さがよくわかる

提供されているクラス 変更不可
class AdapteeModel{
 int test(int a, double b){
  return a + b;
 }
}

インターフェース変更不可

Interface Test{
 void test(double b, int a);
}

自分が作成しているクラス 変更可能
class AdapterListener extends AdapteeModel implements Test{
 void ActionListener(double b, int a){
  this.test(a,b);
 }
}

ListenerがModelを継承するっていうのは明らかにおかしい
いわゆるis a 関係にかすってもいない
AdapteeとAdapterは同じ目的のクラスであるべきだけど、ListenerとModelはまったく目的が違う

言葉遊びとかそういうレベルじゃない
今回の勘違いは、委譲とAdapterを同一視してる発言
670 :デフォルトの名無しさん2011/12/05(月) 21:30:05.97
>>668
Listenerは、別にAdapterじゃなくてもいい
ただListenerとしてAdapterが使えるってだけの話だろ
671 :デフォルトの名無しさん2011/12/05(月) 21:32:49.04
>>668
なんでモデルでもないのにAdapteeModel?
672 :デフォルトの名無しさん2011/12/05(月) 21:37:20.54
>>669
Adapter パターン - Wikipedia
http://ja.wikipedia.org/wiki/Adapter_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

>>670
どういうことかよくわからないから
ListenerとしてAdapterが使えるって具体的にコードで書いてみてよ

>>671
古典的なMVCでは、Listenerから呼び出すメソッドはModelのメソッド
AdapteeModelクラスの中身はなんでもいい
673 :デフォルトの名無しさん2011/12/05(月) 21:40:11.63
674 :デフォルトの名無しさん2011/12/05(月) 21:41:45.98
>>672
モデルつってんのに、メンバーもなけりゃ
ブロードキャスト機構が付いてないから、
アレなのかなとおもってさ
675 :デフォルトの名無しさん2011/12/05(月) 21:45:45.04
>>672
日本語版じゃさも、委譲型が特別形態の様に書かれてるけど、
GoF本や、海外の資料だと、委譲してるのがデフォ。
継承型の方が特殊なんだけど。
678 :デフォルトの名無しさん2011/12/05(月) 21:52:37.27
>>672
http://www.oodesign.com/
こういうちゃんとしたサイトで勉強したら?
680 :デフォルトの名無しさん2011/12/05(月) 21:57:10.17
>>674
そこはスルーして貰えると思って省略した
Modelらしくするなら以下を追加 けどやっぱり今回の話とは関係ないので省略
List<Observers> observers = new ArrayList<Observers>();
private int a = 0;
public void addObserver(Observer ob){
observers.add(ob);
}
public void changeA(int aa){
a = aa;
this.notifyObservers();
}
public int getState(){
return state;
}
private void notifyObservers(){
 for(Observer ob:observers){
  ob.update(this);
 }
}
683 :デフォルトの名無しさん2011/12/05(月) 22:01:58.84
>>680
Javaで、しかもgetXxxxx使ってんだから
せめてjava.beans.PropertyChangeSupportと
java.beans.PropertyChangeListenerぐらいは使おうよ。
676 :デフォルトの名無しさん2011/12/05(月) 21:50:22.93
日本語版Wikipediaなんて技術関連はいい加減だからなぁ
殆どアニオタの巣窟なんだっけ
677 :デフォルトの名無しさん2011/12/05(月) 21:51:38.59
いい加減と思った人が書きなおさないから悪いのでは?
自分の責任だと思いなよ。
679 :デフォルトの名無しさん2011/12/05(月) 21:54:37.96
>>677
なんで情弱御用達Wikipediaの面倒なんか見なきゃならんのよ。
681 :デフォルトの名無しさん2011/12/05(月) 21:58:14.68
ム板で日本語版Wikipediaからしかソース持ってこれないってのもなあ
682 :デフォルトの名無しさん2011/12/05(月) 22:01:48.87
>>675
自分もAdapterでどちらを使うかと言われれば委譲の方を使うよ

ただし同じAdapterパターンなんだから委譲も継承も目的は同じはず

en wiki
>translates one interface for a class into a compatible interface
>>678のサイト
>Convert the interface of a class into another interface clients expect.
>Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

と書いてあるとおりインターフェースを合わせるためのもの
プログラムとか考えずアダプターと言ったらまさしくインターフェースを合わせるためのもの
Listenerでmodelを呼び出すのは、インターフェースを合わせるためではないよね

>>681
ソースなんてGoF読んでくれとしか言えないw
684 :デフォルトの名無しさん2011/12/05(月) 22:06:58.62
>>682
ListenerをAdapterで実装したとき、
Model自体をAdapterが使用する必要ないでしょ。

class Model implements Runnable{}
new RunAdapter( (Runnable)new Model() );
例としては変だけど、Adapterとしての用途なら別にこれでいいわけじゃん。
686 :デフォルトの名無しさん2011/12/05(月) 22:22:10.60
>>683
そうですね

>>684
もちろんそれみたいなListener=Clientの状況なら問題ない
Listener=Adapterはおかしいと主張してる
687 :デフォルトの名無しさん2011/12/05(月) 22:25:31.47
Listener=Adapterじゃないのは同意してるって。
Listener = { Adapter pattern, Other pattern, ... }
にできるっていう意味で書いてんじゃん。
なんで引きずってんの?
688 :デフォルトの名無しさん2011/12/05(月) 22:30:02.26
別にリスナーをコントローラーで実装しようが、アダプターで実装しようがどうでもいいじゃん
690 :デフォルトの名無しさん2011/12/05(月) 22:39:08.17
>Listener = { Adapter pattern, Other pattern, ... }
俺はこれを否定してるつもりなんだけど
ListenerのどこにどうAdapterパターンを使うんだ
Observerパターンは使ってるけど

>>688
どうしてコントローラーとアダプターパターンが同列なんだ
どうやってリスナーをアダプターで実装するんだ


もう俺だけ理解してない気がしてきた
誰か教えてくれ
694 :デフォルトの名無しさん2011/12/05(月) 22:43:20.02
>>690
リスナーはオブザーバーパターンから見た立場
アダプターは、委譲される側から見た立場
直交できる関係であって排他的なもんじゃないでしょ
692 :デフォルトの名無しさん2011/12/05(月) 22:39:48.63
デザパタは構造。見た目は別。
C#でもできるし、GObjectを使ったCでもできるし、Lispでもできる。
アルゴリズムが言語に依存しないのとおんなじ。
693 :デフォルトの名無しさん2011/12/05(月) 22:40:09.16
デザパタは見通しを悪くするというのは、
単にお前が、設計の基礎知識を知らんだけではないのか?

設計図を読めない人は、設計図をみたらよくわからんと言うだろう。
それと同じだ。
695 :デフォルトの名無しさん2011/12/05(月) 22:45:21.24
>>693
本当に必要なときに使うのは誰も否定してないんじゃないの?
698 :デフォルトの名無しさん2011/12/05(月) 22:46:40.31
>>695
あんたは、見た目とデザパタを同一視してるだろ。
そこが解ってないと言われてんの。
699 :デフォルトの名無しさん2011/12/05(月) 22:46:43.34
>>695
だから、本当に必要なときを前提にして
話をしてるんでしょw
697 :デフォルトの名無しさん2011/12/05(月) 22:46:01.69
printfは書式が複雑で見通しが悪いと言っているようなもんだよな。

なぜそうなっているのかその理由と目的を聞いて、
じゃあお前はこの目的をどうやって達成する?と聞いたら
一番いい方法がデザパタと同じコードにになるだろう。

マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006
マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006