オブジェクト指向は馬鹿ご用達

1 ：デフォルトの名無しさん：2011/07/03(日) 00:41:23.02

一つ一つまとめていかないと実装できないアホ
クラスにまとめること自体が目的化している低脳

2 ：デフォルトの名無しさん：2011/07/03(日) 00:43:31.97

神はアセンブラで全てを一括的に書き上げる。

3 ：デフォルトの名無しさん：2011/07/03(日) 00:45:58.24

>>2
直接機械語で書けよ

4 ：デフォルトの名無しさん：2011/07/03(日) 01:00:59.49

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

5 ：ラプラスの天使 ◆daemontaDA ：2011/07/03(日) 03:24:12.10

オブジェクト指向ってさ、ウインドウズ開発とかOS開発向けでしょｗ

それ以外でオブジェクト指向とか、気狂いだからｗ

6 ：デフォルトの名無しさん：2011/07/03(日) 04:21:14.64

必死チェッカーもどき
http://hissi.org/read.php/newsplus/20110619/Mm5oM2lQTDcw.html
ラプラスの天使 ◆daemontaDA
名無しさん＠１２周年

7 ：デフォルトの名無しさん：2011/07/03(日) 05:31:53.12

そもそも何のためにオブジェクト指向があるのかわかってるのかね？

8 ：デフォルトの名無しさん：2011/07/03(日) 08:13:52.11

バカ御用達はOOPLにとって褒め言葉じゃね？

9 ：デフォルトの名無しさん：2011/07/03(日) 08:45:13.09

>>7
信仰の対象がないと困るから。

10 ：デフォルトの名無しさん：2011/07/03(日) 10:58:29.41

理解して利用するのことが難しいのは問題だと思う
企業の新入社員研修でJavaの学習はあってもOOPの学習はない
配属されてから自らOOPを勉強しようなどというモチベーションの高い人間はほとんどいない

11 ：デフォルトの名無しさん：2011/07/03(日) 11:37:34.37

OOP脳は高確率でいきなりOOPから入っている
そして世界は全てOOで成立していると盲信している

12 ：デフォルトの名無しさん：2011/07/03(日) 11:53:59.72

最近の新しい言語でOOP以外ではないものってある？

13 ：デフォルトの名無しさん：2011/07/03(日) 12:00:36.04

×OOP以外ではないもの
○OOPではないもの

14 ：デフォルトの名無しさん：2011/07/03(日) 12:05:14.38

純粋関数型はそうじゃない？

15 ：デフォルトの名無しさん：2011/07/03(日) 12:09:59.93

例えば？

16 ：デフォルトの名無しさん：2011/07/03(日) 12:14:34.24

オブジェクト指向は抽象化が苦手な馬鹿向け

17 ：デフォルトの名無しさん：2011/07/03(日) 12:15:04.32

>>15
Haskellとか？

18 ：デフォルトの名無しさん：2011/07/03(日) 14:01:37.03

>>8
某C++信者が「javaはバカにオブジェクト指向やらせるためにある。
だけどジェネリックの導入でそれができなくなってきた」みたいな
ことを言ってたけど、現場のことをぜんぜん知らないで想像で書いてるな
と思ったね。
バカにオブジェクト指向の強制なんてぜんぜんできてない。

19 ：デフォルトの名無しさん：2011/07/03(日) 14:55:03.41

Haskellなんて全然最近の新しい言語じゃないじゃん・・・

20 ：デフォルトの名無しさん：2011/07/03(日) 16:35:09.66

以外と古いよねHaskell
ただ日の目を見たのが最近ってだけで

21 ：デフォルトの名無しさん：2011/07/03(日) 18:03:19.98

Javaも古い

22 ：デフォルトの名無しさん：2011/07/03(日) 18:04:09.98

ん？　馬鹿でいいんじゃね　何か問題でも？

23 ：デフォルトの名無しさん：2011/07/03(日) 18:08:16.92

>>22
大人数での開発や再利用がしづらいんだが？

24 ：デフォルトの名無しさん：2011/07/03(日) 19:12:27.74

>>1 がオブジェクト指向を理解できない脳味噌の持ち主ということはわかった。

25 ：デフォルトの名無しさん：2011/07/03(日) 19:15:18.57

最近関数型がブームでオブジェクト指向の裸の王様の地位が低下してる。

26 ：デフォルトの名無しさん：2011/07/03(日) 19:32:06.25

staticおじさんスレ

27 ：デフォルトの名無しさん：2011/07/03(日) 19:41:30.28

>>26
そのレスが馬鹿さ加減を呈している

28 ：デフォルトの名無しさん：2011/07/03(日) 19:42:12.84

>>24
> 一つ一つまとめていかないと実装できないアホ
> クラスにまとめること自体が目的化している低脳

29 ：デフォルトの名無しさん：2011/07/03(日) 20:04:36.77

>>28
やっぱり理解していないなｗ
というか「1つ1つまとめていかないと」ってなんだよｗ

30 ：デフォルトの名無しさん：2011/07/03(日) 20:58:42.55

ん？　小さなマイコン以外のファームウェアもCで書くOOPでPCアプリは全てOOPなんだが．．．　何か問題でも？
多人数？　レベル向上にチーム一丸となって勉強する事．．．　大事なのは　ルールの厳守だよ

31 ：デフォルトの名無しさん：2011/07/05(火) 01:17:34.60

じゃあ、今最新の言語って何よ

32 ：デフォルトの名無しさん：2011/07/05(火) 01:21:59.76

>>31
C++がナウいよ

33 ：デフォルトの名無しさん：2011/07/06(水) 06:53:34.12

大所帯バカの寄せ集め環境でコード書かなきゃならない
底辺開発の人って大変やね

34 ：デフォルトの名無しさん：2011/07/06(水) 06:55:09.95

大変なのはプロジェクトマネージャーですが

35 ：忍法帖【Lv=9,xxxP】：2011/07/06(水) 08:38:03.47

>>34
本当にプロジェクトマネージャーの仕事をしてくれるならね。

36 ：デフォルトの名無しさん：2011/07/06(水) 08:40:38.52

お上にすがる底辺

37 ：デフォルトの名無しさん：2011/07/06(水) 09:29:24.19

底辺には底辺の、上には上の仕事がある
当然ながら、上は上の仕事をちゃんとやらないかんだろ

38 ：デフォルトの名無しさん：2011/07/06(水) 23:35:26.80

だから底辺がしくじらないようにJavaなんだろ

39 ：デフォルトの名無しさん：2011/07/07(木) 02:33:57.00

Javaに仕事取られたのかな？

40 ：デフォルトの名無しさん：2011/07/07(木) 07:26:01.17

もうJavaは底辺開発を中心に十分に普及してて、
いまさらJavaに取られる仕事なんて無い
土方仕事はJava最強状態

41 ：デフォルトの名無しさん：2011/07/08(金) 21:49:15.21

似たようなスレがあるだろ
わざわざ立てるなよ

42 ：デフォルトの名無しさん：2011/07/10(日) 08:01:13.37

http://hibari.2ch.net/test/read.cgi/tech/1308499587/l50
このスレの続きはこっちでいいんじゃ？

>>993
オブジェクト指向とリファクタリングは密接な関係がある。
一応wikipediaのリファクタリングの項目は読んでおけ。scalaみたいな
半端な言語ならリファクタリングは開発されるんだろうけど、他では
なくても問題はないわな。

>>999
関数型言語のテストは普通に行なわれているよ。言語によっては
難しいことを抱える場合もあるけど、保守点検が楽だって点からも
テストが楽なことが多いのは想像つかなきゃ。

というより、IDEだけで慣れてしまった人たちにそれ以外の環境について
理解を求めるのも無駄のような気がするな。だからこのスレなんて
続きをやるには丁度いい。

43 ：デフォルトの名無しさん：2011/07/10(日) 08:33:54.57

関数型言語の欠点：馬鹿にはコンパイル通るコードすら書けない

44 ：デフォルトの名無しさん：2011/07/10(日) 09:01:53.35

>>43
関数型言語について何もご存知がないようですね。一度お調べになられた
ほうが脳みそにシワを増やせますよ。:-)

45 ：デフォルトの名無しさん：2011/07/10(日) 09:27:22.99

ライブラリ開発者でもないのにこんなのやっても無駄だよね

46 ：デフォルトの名無しさん：2011/07/10(日) 09:27:35.22

>>44
そうは言うけどさ、例えばどんだけ指摘されても型付けを理解出来ない
アホとか世の中にはいるわけで、そういう想像を絶する低能にも
関数型言語が使えるとは俺には思えん

47 ：デフォルトの名無しさん：2011/07/10(日) 09:38:10.48

フェイズが違うんだよね
業務のプログラムなんて用意されたライブラリの機能使うだけなんだから
こんなご高説はいらないんだよ
多分、コードを切って貼ったほうがいいものできる
ＭＳの自動で吐き出すコードだってそうなってるだろ？

もし、ソフトウェア工学バリバリのことをやりたいならＭＳなんかのライブラリを作る側にまわることだと思う

48 ：デフォルトの名無しさん：2011/07/10(日) 10:10:00.31

業務プログラムなんて工場の単純作業みたいなもん
そもそもプログラミングの範疇に入れて良いものか微妙

49 ：デフォルトの名無しさん：2011/07/10(日) 10:21:44.67

ここのスレの>>1さんが>>10あたりで言ってる言葉が非常に同意できる
http://hibari.2ch.net/test/read.cgi/prog/1234180357/

7 ：仕様書無しさん：2009/02/09(月) 21:07:55
>>3
ﾌﾟﾛｸﾞﾗﾑが好きなのになんでPG辞めるの？

10 ：1：2009/02/09(月) 21:11:02
>>7
プログラムで面白いと思われるクリエイティブな作業とはほど遠いからです。＞職業ＰＧ
googleとかだと違うかもしれないけど。

50 ：デフォルトの名無しさん：2011/07/10(日) 10:47:54.04

オブジェクト指向を否定するのはこれらを読んで最低限理解してからにしてくれ
ここらへんが理解できないのなら文句言わず黙って手続き型書いてろｗ

Javaのオブジェクト指向入門
http://www.kab-studio.biz/Programing/OOPinJava/

疑りぶかいあなたのためのオブジェクト指向再入門
http://kmaebashi.com/programmer/object/index.html

Amazon.co.jp：デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series): アラン・シャロウェイ, ジェームズ・R・トロット, 村上雅章: 本
http://www.amazon.co.jp/dp/4894716844

51 ：デフォルトの名無しさん：2011/07/10(日) 10:50:07.97

>>50
このように>>1の主張を理解できない馬鹿ばっかなのです

52 ：デフォルトの名無しさん：2011/07/10(日) 10:54:16.87

>>50
笑いすぎてお腹痛いwww

53 ：デフォルトの名無しさん：2011/07/10(日) 10:55:50.12

>>51
馬鹿で申し訳ないが、>>1の主張がわからない

>一つ一つまとめていかないと実装できないアホ
>クラスにまとめること自体が目的化している低脳
この発言はオブジェクト指向を理解できていないからこそ出てくる意味不明な発言だと思っていたんだが違うのか

54 ：デフォルトの名無しさん：2011/07/10(日) 11:09:40.27

>>53
もう1年プログラム経験を積もうか

55 ：デフォルトの名無しさん：2011/07/10(日) 11:22:47.14

オブジェクト思考難しすぎて挫折した

56 ：デフォルトの名無しさん：2011/07/10(日) 11:23:28.18

>>54
1年経っても理解できそうにないから具体的な指摘を頼む・・・

57 ：忍法帖【Lv=3,xxxP】：2011/07/10(日) 11:24:19.01

ふむ

58 ：デフォルトの名無しさん：2011/07/10(日) 11:25:16.16

>>56
その前にお前が具体的に指摘しろよ

59 ：デフォルトの名無しさん：2011/07/10(日) 11:35:13.68

ここはオブジェクト指向自体をdisるんじゃなくて
オブジェクト指向を使ってるやつをdisるスレっぽいな

60 ：デフォルトの名無しさん：2011/07/10(日) 11:36:43.98

>>58
オブジェクト指向の目的は1つ1つまとめくることではない
というか1つ1つまとめるってなんだよｗ　クラスのこと？
クラスは実装であり、また加えてインターフェースを用いることにより設計と実装を分けることができる。
クラス、データ、処理が隠蔽されている設計に依存することにより拡張性が高くなる

61 ：デフォルトの名無しさん：2011/07/10(日) 11:42:51.24

個人的にはクロージャと高階関数（with カリー化）の方が
クラスベースOOPの単一メソッドディスパッチより汎用的だし
拡張性も高い気がするが、オブジェクト指向も嫌いじゃないし
どうでもいいや

62 ：デフォルトの名無しさん：2011/07/10(日) 11:44:26.66

>>60
Java厨の癖によくわかってないんだな

63 ：デフォルトの名無しさん：2011/07/10(日) 11:48:03.45

うむ

64 ：デフォルトの名無しさん：2011/07/10(日) 11:49:06.84

>>61
Scala使えばOK

65 ：デフォルトの名無しさん：2011/07/10(日) 11:49:49.30

そもそもオブジェクト指向にクラスは必須じゃないんだよ
なのに実際はクラス設計ばっかりやるハメになる
クラス設計がやりたくてOOPやってるんじゃないのに

66 ：デフォルトの名無しさん：2011/07/10(日) 11:51:05.60

>>65
でたらめ言うなボケカス

67 ：デフォルトの名無しさん：2011/07/10(日) 11:52:50.65

アイちゃん以外書込み禁止

68 ：デフォルトの名無しさん：2011/07/10(日) 12:00:49.33

>>60
なるほどー

69 ：デフォルトの名無しさん：2011/07/10(日) 12:11:48.76

武勇伝

70 ：デフォルトの名無しさん：2011/07/10(日) 12:14:32.32

>>69
それあっちゃん

71 ：デフォルトの名無しさん：2011/07/10(日) 12:15:53.14

>>60
まとめるだけなら、タプル的なものを要素とするコレクションとか、
ツリーでいいもんな。それは複数クラスが必要になるわけじゃなく、
オブジェクトのつながりで表現するからクラス自体は固定的になる。

しかも、オブジェクトによる振る舞いなんてどうでもいいから、
オブジェクト指向とも違う。別にオブジェクトじゃなくてスクリプト言語がよく持つ
コレクション機能でもいい。

72 ：デフォルトの名無しさん：2011/07/10(日) 12:18:51.02

>>70
かっこいー

73 ：デフォルトの名無しさん：2011/07/10(日) 12:19:45.03

>>61
オブジェクトに単一のメソッドもたせりゃラムダじゃん。
ラムダに対しオブジェクトは下位互換をもってる。
アランケイがやたらlispを褒めてたけど、
smalltalkのデザインは結構ラムダの影響をうけてる。

74 ：デフォルトの名無しさん：2011/07/10(日) 12:27:54.26

>>73
本気で言ってる？
クロージャは参照してる変数（環境）を自動でキャプチャしてくれるけど
オブジェクトはしてくれないじゃん

75 ：デフォルトの名無しさん：2011/07/10(日) 12:31:33.12

オブジェクト指向とまったく関係ない方向にいっても誰も止めないからね
関係ない話なのにまた食いついちゃう馬鹿ばっかりだからどうしようもない

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

ガチガチなオブジェクト指向やって破綻したプロジェクトはいくつも見てるけど
真っ向から否定する人はオブジェクト指向が理解できなくて挫折した人なんだろうなと理解してる

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

オブジェクト指向のメリットを否定 = オブジェクト指向が理解できない
こう解釈されるのは何でだろね？
否定派にもやらせればオブジェクト指向プログラムできる人は沢山いるだろうに

78 ：デフォルトの名無しさん：2011/07/10(日) 21:59:58.60

>>74
smalltalkにあるブロックオブジェクトは自動でキャプチャ(?)してくれるよ。
実装から言ってしまえば、大抵のラムダはクラス定義の構文糖。
そもそも、オブジェクトをクラスで定義せにゃならんなんて决まりはオブジェクト指向にはないし。

79 ：デフォルトの名無しさん：2011/07/10(日) 22:04:11.28

そりゃsmalltalkが何でもオブジェクトの言語だから
クロージャもオブジェクトってだけだろ

クロージャがクラス定義の構文糖ってアホか
schemeとかクラスなんて概念ねーぞ

80 ：デフォルトの名無しさん：2011/07/10(日) 22:06:13.98

おれの直感的理解ではOOは
状態機械をオブジェクトと呼んで、メッセージによってお互いの状態を遷移させる
というイメージなんだけどあってる？

81 ：デフォルトの名無しさん：2011/07/10(日) 22:10:33.85

>>74
ついでに言うと、オブジェクト自体はリストの塊でもいいし、
実態要素に対する照合要素でも、メッセージに返事さえ返せれば
なんでもいい。更に言うと、メッセージに対応するメソッドは、メッセージと1対1の
関数形式である必要もない。メッセージを受け取るたびに1つのルーチンを回して
返事しても構わんし、送信と受信の2ルーチンだけって形でも構わん。

82 ：デフォルトの名無しさん：2011/07/10(日) 22:14:12.23

>>79 概念がどうとかそういう問題じゃないでしょ。
あなたは、偉い先生がポインターはメモリの参照渡しに使うものですといったら
それだけを盲信するの？値としての側面には一切触れないの？

83 ：デフォルトの名無しさん：2011/07/10(日) 22:16:33.99

>>80
オブジェクトが変化しなきゃいけないって義務は無いよ。
初期化以降まったく変化しなくても構わないし。

84 ：デフォルトの名無しさん：2011/07/10(日) 22:21:06.07

>>83

85 ：デフォルトの名無しさん：2011/07/10(日) 22:35:58.00

>>82
は？その意味不明の例えは今の話と関係あんの？偉い先生って何？

そもそもポインタは値渡しだから、値渡しとしての側面は切り離せないが、
クロージャはクラス概念とは独立に定義できる
だからクロージャをクラス定義の構文糖とかいうのはアホすぎる

86 ：デフォルトの名無しさん：2011/07/10(日) 22:43:01.12

>>85
みなせるだけで、それが仕様で別となっていようと、誰がどう言っていようと
どうでもいいってのが解んないの？俺や世界が明日からクロージャをクラスだと言えといってる
わけでもないの同列に扱えるといってるだけ。頭固いねぇ。
ポインターの話の芯の部分も解ってないようだし何言っても無駄なだけなんだろうけど。

87 ：デフォルトの名無しさん：2011/07/10(日) 22:50:31.10

>>85　実装面から言えば、C++のラムダやC#のラムダは、クラスとそのオブジェクトそのものなんだけどな。
まぁ、Lispなんかは関数をクラスにぶら下げてるからそういう感覚があるのかもしれんし、
LispのクロージャはCLOSのクラスでできてるわけじゃないから違うと言い張りたいのも解る。
もちろん関数型の上で作られたクラスと、クロージャは違う。それは確かだろう。
だが、バイナリーレベルでは構造が同じなのはCommon LispやHaskelの処理系の実装をみてみても明らかだ。
まぁ、そのへんこの話とはあんまり関係ないし、ここに注目してる限りは間違いなんだけどな。

88 ：デフォルトの名無しさん：2011/07/10(日) 22:57:56.05

>>86
>>87
頭悪すぎ

89 ：デフォルトの名無しさん：2011/07/10(日) 22:59:20.11

>>73
これも

90 ：デフォルトの名無しさん：2011/07/10(日) 22:59:48.07

>>82
これも論外

91 ：デフォルトの名無しさん：2011/07/10(日) 23:00:11.43

>>85
Point1とVector1があったとき、
Point2 = Point1 + Vector1;
を行ったとする。
この時Point1が(0,0)だったとするとVector1はベクトルではなく
Pointのひとつとみなす事ができる。
さらにこれを応用して、Point1を原点とみなすと、Point1に加算した全てのベクトルは、
Point1を原点とする空間においてはPointのひとつとみなすことができる。
つまりPoint ≒ VectorであるためPointをVectorで代用する事もできる。

そういう考え方できねぇだろうなァ。

92 ：デフォルトの名無しさん：2011/07/10(日) 23:00:22.05

>>88
いや、87は多方面に気を使った折衷案的発言な気が

93 ：デフォルトの名無しさん：2011/07/10(日) 23:01:49.64

>>91
で？

94 ：デフォルトの名無しさん：2011/07/10(日) 23:03:17.08

>>88-90 はuyの一種なんじゃね。

95 ：デフォルトの名無しさん：2011/07/10(日) 23:04:12.18

>>94
お前の書き込みアホ過ぎるよ

96 ：デフォルトの名無しさん：2011/07/10(日) 23:08:01.90

> 概念がどうとかそういう問題じゃないでしょ

97 ：デフォルトの名無しさん：2011/07/10(日) 23:10:52.84

>>91
結論は？

98 ：デフォルトの名無しさん：2011/07/10(日) 23:12:56.35

>>93
>オブジェクトに単一のメソッドもたせりゃラムダじゃん。
という意味は大して間違ってないことが解る。

ついでに、ラムダの生成物はオブジェクトのひとつとして見なせるので、
オブジェクト指向で培われたノウハウの大半を転用することができる。

1.例えば、UMLでは、1つの無名メソッドをもったクラスを定義する事でラムダ及び関数を表現できる。

2.オブジェクトに発生する制約はそのままラムダにも発生する。

3.ラムダで可能な事は当然オブジェクトでも可能である。

4.ラムダと単一のメソッドを持ったオブジェクトの違いといえば書き方が面倒かどうかぐらいである。

99 ：デフォルトの名無しさん：2011/07/10(日) 23:17:52.75

あのさ、ただデータと処理のペアが定義できるってだけなら
構造体（レコード）があって関数へのリファレンスが持てるなら
どんな言語でもできるわけ
でもそれをもってクラスがあるとかクロージャがあるとか言わないだろ？

クラスなら継承できたりメソッドがクラススコープ持ってたりする必要があるし、
クロージャなら静的スコープで環境をキャプチャできる必要がある

100 ：98：2011/07/10(日) 23:18:34.07

>ついでに、ラムダの生成物はオブジェクトのひとつとして見なせるので、
>オブジェクト指向で培われたノウハウの大半を転用することができる。
補足するとここって本来は逆なんだけどね。先にできたのはラムダだし。

101 ：デフォルトの名無しさん：2011/07/10(日) 23:19:41.09

>>99 継承もクラスコープも必要ないよ。
C++系言語に毒されすぎ。

102 ：デフォルトの名無しさん：2011/07/10(日) 23:22:17.87

>>99
頂いたメッセージにお返事ができる事がオブジェクト指向の全て。
それ以上の機能はあろうがなかろうがどうでもいい。そこ解ってる？

103 ：デフォルトの名無しさん：2011/07/10(日) 23:23:31.49

>>101
そりゃそういう言語もあるさ
Pythonなんてクラススコープ無いからself必要だしな
でもただの構造体をクラスとは言わないし、
そしてクロージャの場合は環境を持てるのは必要条件だ

104 ：デフォルトの名無しさん：2011/07/10(日) 23:25:01.48

>>99
ベクトルの話はやっぱ理解できなかったか。そこまで実践的な教養もないんだろうから、
オブジェクト指向やらラムダを語るなんてできないわな。
(高校レベルの数学も解らずラムダを語るとか・・・)

105 ：デフォルトの名無しさん：2011/07/10(日) 23:26:43.28

>>102
じゃあ、クロージャでオブジェクトは実装できるけど
オブジェクトでクロージャを実装できるとは限らないね
メッセージをやりとりできるだけじゃ静的スコープをキャプチャなんてできないもんね
そうか、オブジェクトはクロージャの構文糖だったのか

106 ：デフォルトの名無しさん：2011/07/10(日) 23:26:48.71

>>103
なんどもいうけど別に構造体でオブジェクト構成しなきゃいけないとか
関数で実装されなきゃならんて条件はオブジェクトの要件にないの。
>>102が全て。

107 ：デフォルトの名無しさん：2011/07/10(日) 23:27:08.69

>>101=>>102=>>104
まとめて書けアホ

108 ：デフォルトの名無しさん：2011/07/10(日) 23:27:27.65

>>104
ベクトルはおろかヒルベルト空間も理解出来ますが何か？

109 ：デフォルトの名無しさん：2011/07/10(日) 23:28:07.13

>>105
構文糖の意味解って使ってる？

110 ：デフォルトの名無しさん：2011/07/10(日) 23:29:22.39

全く関係ないけど>>91がオナニー過ぎて吹いた
一緒のプロジェクトにいたら迷惑なタイプだな
1社に1人はいるんだよな独自の理念で行動して毎回損害出す協調性のないヤツ

111 ：デフォルトの名無しさん：2011/07/10(日) 23:29:28.02

>>109
もちろん分かってるよ
>>78のアホに合わせて誤用してるんだよ
皮肉くらい分かれ

112 ：デフォルトの名無しさん：2011/07/10(日) 23:32:51.17

>>108 ヒルベルト空間説明できないだろ。「ベクトルはおろかヒルベルト空間」もなんて書いて恥ずかしくないの？
ヒルベルト空間はベクトルしってりゃ名前知らなくてもすぐ思いつく話だぞ。

113 ：デフォルトの名無しさん：2011/07/10(日) 23:35:44.29

>>91
お前が高校レベルの数学すら理解できていないことがわかった
お前はA+AB↑とかやるのか

114 ：デフォルトの名無しさん：2011/07/10(日) 23:36:14.37

>>112
>>91が二次元のベクトル空間を例に挙げたから
無限次元ベクトル空間も理解出来るって仄めかしただけだが？
何か可笑しいか？

それに恥ずかしい恥ずかしくないで言えば>>91には負けるわ
あんな文章恥ずかしくて書けん

115 ：デフォルトの名無しさん：2011/07/10(日) 23:40:31.12

>>111
var x;
object = function(){return x*2;};
x = 5;
method(object);

int x;
object = new Function{public void performed(int x){return x*2;}};
x = 5;
method(object);

これで全く同じ動作をする環境が存在する。
こういうものが構文糖の例だけど。知らんわなぁ。

116 ：デフォルトの名無しさん：2011/07/10(日) 23:44:33.44

>>113
頭かてぇな。
>つまりPoint ≒ VectorであるためPointをVectorで代用する事もできる。
お前のなかでは絶対これが成立しないのか？
そして制約を持たせた上でこれを利用したコードを書いちゃいけないのか？
常にPointとVectorを別で書き続けるのかよ。

応用が効くだろって話をかいてんの。

117 ：デフォルトの名無しさん：2011/07/10(日) 23:44:59.16

そろそろラムダがクラスの構文糖であるというソースを挙げてくれる頃

118 ：デフォルトの名無しさん：2011/07/10(日) 23:45:57.29

>>116
なんで頭悪い人に合わせないといけないの？

119 ：デフォルトの名無しさん：2011/07/10(日) 23:47:18.51

>>116
そのPointとは何を表してんでしょうね
まさか座標なんて言わないよね

120 ：デフォルトの名無しさん：2011/07/10(日) 23:47:37.82

>>114
普通さ。教科書に書いてあることじゃなくて、自分で気づく内容書くだろ。
ベクトルと微積の関係やら、ベクトルの複素数の関係やら。
そういう話をされりゃ納得するって。

121 ：デフォルトの名無しさん：2011/07/10(日) 23:48:34.35

>>120
うーん＾＾；

122 ：デフォルトの名無しさん：2011/07/10(日) 23:49:01.36

>>115
だから特定の言語（Javascript）でクロージャが関数オブジェクトの構文糖だとしても、
それを一般化してクロージャがクラスの構文糖っていうのがアホなの
Javaなんてクラスはあるしオブジェクト指向言語として分類されるがクロージャは無いぞ

123 ：デフォルトの名無しさん：2011/07/10(日) 23:49:38.69

>>117
だから明日からラムダがクラスになるような話は言ってねぇって話書いたろ。

124 ：デフォルトの名無しさん：2011/07/10(日) 23:50:24.98

> ベクトルと微積の関係やら、ベクトルの複素数の関係やら
なんか言い方が怪しいな

125 ：デフォルトの名無しさん：2011/07/10(日) 23:51:17.89

>>78
> ラムダはクラス定義の構文糖

126 ：デフォルトの名無しさん：2011/07/10(日) 23:54:00.79

>>116
かわいそうに自分の頭がおかしい事に気が付かないんだね
お前が仕様にない応用を利かせたせいでプロジェクトが破綻していく様がリアルに見える
≒を勝手に＝と曲解して扱うな
話題にのぼっていないベクトルを突然出してきて語りはじめたあたりから察するに
クラスの中で数学が得意なことを売りにしてる中学生あたりだろうけど
妄想はノートに書いてろ

127 ：デフォルトの名無しさん：2011/07/10(日) 23:55:41.03

>>122
ひとつ言うが、このスレはお前と俺一人がいる訳じゃないからな。

お前は構文糖である事を異常に否定しようとしてるが、
少なくとも、俺はどうでもいい。>>98に書いた通りの事しか言うつもりはないし。

128 ：デフォルトの名無しさん：2011/07/10(日) 23:57:19.87

>>126
応用をきかせろって話をベクトルを例に書いてるのに、
ベクトルにしか頭が行かないの？一人で必死そうだけどやっぱバカだね。

129 ：デフォルトの名無しさん：2011/07/10(日) 23:57:53.48

>>116はcheckValueとかいう関数の中でメンバ変数書き換えちゃうタイプ

130 ：デフォルトの名無しさん：2011/07/10(日) 23:59:09.00

>>128
まともな例を出せずに墓穴を掘る厨を見た

131 ：デフォルトの名無しさん：2011/07/11(月) 00:00:09.97

>>128
お前の挙げた例が適切でない
やり直せ

132 ：デフォルトの名無しさん：2011/07/11(月) 00:01:06.27

>>128
一人じゃないと思うが？

133 ：デフォルトの名無しさん：2011/07/11(月) 00:04:46.87

醤油置いときますね

134 ：デフォルトの名無しさん：2011/07/11(月) 00:04:58.86

>>128
一人だと思ってたんだ
みんな君がおかしいからアンカつけてるのに
君は一人だけ自分と意見が違うのがいると思ってたんだ
幸せだよ君は

135 ：デフォルトの名無しさん：2011/07/11(月) 00:09:36.08

>>133
あ？どこの誤爆だよボケが

136 ：128：2011/07/11(月) 00:11:59.13

俺を>>116と一緒にされても困るがな。
ただ論点がずれてる事に気づいてないバカがいると思って書いたのに。

137 ：デフォルトの名無しさん：2011/07/11(月) 00:12:17.33

>>126
ポイントとベクトルを分けることに、運用上の重要な意味があるのか？

逆に質問したいのだが、じゃぁRGBの色値はポイント？ベクトル？
３DCGのポリゴンの頂点はベクトル？ポイント？
これらがベクトルかポイントかの、明確な根拠を示してください。

126がこれを明確に示せないのであれば、
ベクトルとポイントの別扱いに拘る根拠が、実は何も無かったってことの証明。

よろしくおねがいしますｗ

138 ：デフォルトの名無しさん：2011/07/11(月) 00:14:53.71

>>136
他人のふりなんかしなくてもいいよ

139 ：デフォルトの名無しさん：2011/07/11(月) 00:15:43.69

>>137
>>119

140 ：デフォルトの名無しさん：2011/07/11(月) 00:16:24.49

>>137
もともと分けて書いたのはお前で
それからいきなり同じものだと言い出したんだが？

141 ：デフォルトの名無しさん：2011/07/11(月) 00:17:31.83

>>91のつっこみどころ

・ベクトルと和をとれるのはベクトルのみだが、Pointって何？
・おそらく幾何ベクトル（いわゆる矢印でイメージされるやつ）を考えてるんだろうが、
　それを数の組で表すアイデアを皆が知らない画期的発想のように言っている
（>>120で教科書云々言ってるし）
でも、それって只のベクトル空間ですよね？教科書に載ってますよ？

142 ：デフォルトの名無しさん：2011/07/11(月) 00:19:18.67

>>140
そうだよな
Pointって表現から間違っている

143 ：137：2011/07/11(月) 00:20:26.14

>>139
私はこのスレッドに初めて書き込んだのだが。
137以外は別人だよ。

それより質問に答えてみてよ。
それともベクトルもポイントも同一でOK?

144 ：デフォルトの名無しさん：2011/07/11(月) 00:21:31.53

>>143
別人のふりしなくてもいいよ

145 ：デフォルトの名無しさん：2011/07/11(月) 00:22:39.48

ゆとりは自覚がないから困る
そう教育されてるから仕方ないってのもあるが

146 ：デフォルトの名無しさん：2011/07/11(月) 00:23:12.02

とりあえず流れからすると、

>>98　のやつと >>91 のヤツ >>122のヤツ　>>126のヤツが居るわけだ。

>>98　はクロージャをオブジェクトの一種と見なせると主張する
>>91　はクロージャはクラスの構文糖じゃないと主張する
>>122 はベクトルを例にだして応用を効かせろと主張する
>>126 はベクトルぐらい解るわ!と>>122は人格破綻者と主張する

まぁ、おそらく>>91と>>126は同一人物。
まず、>>98と>>91は主張してる根本が違う。
その時点でアレだ。

で、ある種一番馬鹿なのは、理解力のない>>91に延々と
レスを引きずった>>122。コイツが放置しとけば無駄なやりとりが増えなかった。

147 ：137：2011/07/11(月) 00:25:13.78

ゆとりはどうとか、同一人物とか、そんな話はどうでもいいので、本題に答えてよ。
とくに、ベクトルとポイントを別物だと拘ってた人。

煽りでもなんでもなく、純粋に、その根拠を知りたいだけです。
拘るだけの理由があったってことでしょ？　何がちがうの？　ポイントとベクトルの何が違うの？

148 ：デフォルトの名無しさん：2011/07/11(月) 00:25:51.87

え？>>126は>>91にツッコミ入れてんじゃないの？
別人だと思うが

149 ：デフォルトの名無しさん：2011/07/11(月) 00:26:01.08

>>144
本当に違うのに一人で哀れだな。

>>146
いや、普通高校数学"程度"の話をすれば伝わると思うだろ。
煽ったのは悪かったけどさ。

150 ：デフォルトの名無しさん：2011/07/11(月) 00:27:03.51

>>98=>>91≠>>126

151 ：デフォルトの名無しさん：2011/07/11(月) 00:28:35.96

>>149
他人のふりするなら文体変えろ
お前のは特徴的だから

152 ：デフォルトの名無しさん：2011/07/11(月) 00:30:16.34

>>147
すでに散々指摘受けてるだろ
頭かてぇな

153 ：デフォルトの名無しさん：2011/07/11(月) 00:30:38.63

>>147
> とくに、ベクトルとポイントを別物だと拘ってた人。

それ以前の問題として、ポイントって何だよってツッコミが入ってるだろ>>119 >>141

154 ：137：2011/07/11(月) 00:30:47.97

同一人物とかどうでもいいから、っさっさっと本第二個t外おあおたほあｆ；いおあｊ：じｆ！！！！！！！！！！！！！！！！！

155 ：146 ：2011/07/11(月) 00:30:51.97

すまん。カッコ付けて書いたが、
>>91と>>122逆に書いてしまった。
すまん。もう書かないわ。
とりあえず訂正残しとく。

>>98　のやつと >>91 のヤツ >>122のヤツ　>>126のヤツが居るわけだ。

>>98　はクロージャをオブジェクトの一種と見なせると主張する
>>122　はクロージャはクラスの構文糖じゃないと主張する
>>91 はベクトルを例にだして応用を効かせろと主張する
>>126 はベクトルぐらい解るわ!と>>91は人格破綻者と主張する

まぁ、おそらく>>122と>>126は同一人物。
まず、>>98と>>122は主張してる根本が違う。
その時点でアレだ。

で、ある種一番馬鹿なのは、理解力のない>>122に延々と
レスを引きずった>>91。コイツが放置しとけば無駄なやりとりが増えなかった。

156 ：デフォルトの名無しさん：2011/07/11(月) 00:30:57.30

>>137
>>116には後から自分の解釈だけで資料も読まずに改造設計する臭いを感じたから書いた
>>116はどう見てもベクトル覚えたてで単語を使いたいだけ
>>137にも似た臭いがある。お前煽りたいだけだろ

157 ：デフォルトの名無しさん：2011/07/11(月) 00:33:52.72

>>155
おまえが>>91本人だろ

158 ：デフォルトの名無しさん：2011/07/11(月) 00:36:31.00

>>1の言うように馬鹿ご用達だったというわけさ

159 ：137：2011/07/11(月) 00:38:13.05

>>157
ベクトル覚えたてもなにも、
ベクトルなんて、そんな理解しがたいほどに壮大で複雑怪奇な論理なのか？

あんなのただの大きさもった方向だろ。それだけのことじゃないの？　なんかもっと他に超難しいことでもあるの？

160 ：デフォルトの名無しさん：2011/07/11(月) 00:39:20.69

>>159
つまんね

161 ：137：2011/07/11(月) 00:40:41.71

超難しいこと言ってみろよｗ　ほらっほらっ！！ｗｗｗ

162 ：デフォルトの名無しさん：2011/07/11(月) 00:40:45.20

>>147
同列に扱っていいかとかそういうものは初期設計時に文書化しておくものだよね？
今回のはPoint1とVector1。
まずこれらは一般名詞過ぎて何を指してるか前提を書かないと危険だよね
今の流れから分かると思うけどこんな風に意見の相違が出てくる。
>>116 はそれにも関わらず自分の中の思いつきだけでこれらを同列として
扱いだした。
こういうのを勝手に判断して行動されるとチームの他の人間が困るのは分かりますか
もちろんこれが幾何学分野でのベクトルと座標という前提があれば同列に扱う
事もありうるし演算子をオーバーロードして扱うこともよくある

163 ：デフォルトの名無しさん：2011/07/11(月) 00:42:12.60

大きさ持った方向ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

164 ：デフォルトの名無しさん：2011/07/11(月) 00:47:11.87

>>159
幾何的にはそんなイメージでいいがね
一応、和とスカラー倍が定義されるものをベクトルっていうんだわ

で、和はベクトル同士、積はスカラーとベクトルでしか定義されないのね
>>91はVectorとPointを足してるけど、これってVectorがベクトルだとすると
Pointもベクトル以外有り得ないわけ
でも
> Vector1はベクトルではなくPointのひとつとみなす事ができる
みたいなこと書いてるし、もう意味不明なわけよ

165 ：デフォルトの名無しさん：2011/07/11(月) 00:54:41.88

>>91と>>98は俺だが、なんで自分をわざわざ2人として書く必要があんだよ。

あと>>156。>>141はおかしいからな。
座標点(Point)とベクトルとの加算概念がないという時点で信用できん。

高校数学程度なら点Pというものが同じ概念で登場する。
また、幾何学全般においてPoint1-Point2という式が存在するし、
Point1 + Vector1というものが存在する。幾何分野じゃ点を
示す値がないとユークリッド空間に落とせないからな。

166 ：デフォルトの名無しさん：2011/07/11(月) 00:55:21.32

>>159
辞書読めば？
http://ejje.weblio.jp/content/vector

167 ：デフォルトの名無しさん：2011/07/11(月) 00:55:23.14

>>159
いやそこは本人であることを否定しとけよ

168 ：デフォルトの名無しさん：2011/07/11(月) 01:02:04.81

>>165
だからね、なんで君の頭はpoint:=座標, vector:=大きさ持った方向って
意味しか持ってないの？

単語の意味からはこういう定義のされ方もあるのにPointとVectorは必ず
加算出来ると思って疑わない脳が信じられないんだけど

typedef string Point;
typedef int[3] vector;
Point point1 = "794うぐいす平安京"
Vector vector = {0, 0, 0};
Point point2 = point1 + vector;

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

>>167 ｳｹﾀ

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

>>164
お前の頭の中にはアフィン空間は存在しない事はよく解ったよ。
あと俺が例に出した位置ベクトルの話も教科書通りっていってる以上
それ以上話の進展がないって事も解ったよ。

ま、お前が頭の固い人間？らしいことも解ったし、一例でレスを伸ばすのを
そろそろやめようか。

171 ：デフォルトの名無しさん：2011/07/11(月) 01:15:24.02

>>170 数学できないプログラマなんかいるわけないだろうよ
みんな暇つぶしで>>170みたいな中途半端な知識の中学生煽って遊んでるだけから安心して寝ろ
明日学校あるだろちゃんと登校してるかどうかはわかんねけど

172 ：デフォルトの名無しさん：2011/07/11(月) 01:15:54.21

>>170
ベクトル空間自体がアフィン空間
当然ユークリッド空間も

173 ：137：2011/07/11(月) 01:17:13.20

pointが動作としてベクトルならば
vectorがpointと同じ仕組みを使うことに問題は無いのでは？
ということを91は言ってるんだと思ってたわ。
ちがうのか？

174 ：デフォルトの名無しさん：2011/07/11(月) 01:17:58.09

>>173
お前も忙しいな

175 ：デフォルトの名無しさん：2011/07/11(月) 01:18:34.23

>>173
だから文体変えてやり直せ

176 ：デフォルトの名無しさん：2011/07/11(月) 01:21:21.62

>>172
お前の書き方はおかしいけどな。
アフィン空間とベクトル空間がまるで同一に見える。

177 ：デフォルトの名無しさん：2011/07/11(月) 01:21:24.68

まずPointとVectorの定義書けよ

178 ：デフォルトの名無しさん：2011/07/11(月) 01:23:10.77

話の流れじゃ解らず定義書いてもらわんと解からんのか・・・。

179 ：デフォルトの名無しさん：2011/07/11(月) 01:25:24.35

>>174=>>175
本当にひとりなんだな。

180 ：137：2011/07/11(月) 01:26:50.31

なんとなく９１が批判されてる根拠がわかったわ。

要するに、ポイントとベクトルの関係を、ポイントを親とするか、ベクトルを親とするかで、
９１はポイントを親とすると言ったので、それに対する違和感ってことか？

181 ：デフォルトの名無しさん：2011/07/11(月) 01:29:37.45

>>176
そう思うんならお前が馬鹿なんだろ

182 ：デフォルトの名無しさん：2011/07/11(月) 01:29:38.27

>>178
いいから書けよ

183 ：デフォルトの名無しさん：2011/07/11(月) 01:30:48.14

>>170
>>91
> この時Point1が(0,0)だったとするとVector1はベクトルではなく
> Pointのひとつとみなす事ができる。

アフィン空間なら座標とベクトルを足した結果は(0,0)とか関係なく常に座標だ
お前の書き方だと「足した結果はベクトルだが、座標としても解釈できる」以外に
読めねーだろ

184 ：デフォルトの名無しさん：2011/07/11(月) 01:32:02.75

アフィン空間に原点ってｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

185 ：デフォルトの名無しさん：2011/07/11(月) 01:37:29.46

あげ

186 ：デフォルトの名無しさん：2011/07/11(月) 01:38:06.59

そういや最近>>168みたいな事いうやつ増えたよな。
なんでだろうな、本当に逐一説明しないと理解できないのか、
それとも2chの反骨精神の影響なのか。ゆとりどうのというけど、
ゆとり教育以前にコミュニケーションがおかしいってのが
ゆとり最大の問題だわ。

187 ：デフォルトの名無しさん：2011/07/11(月) 01:38:12.92

設計者に文句いえよ

188 ：137：2011/07/11(月) 01:40:52.11

ベクトルを親と考えて、
ポイントの定義は、0に始点を持った特殊なベクトルと考えてはどうか？

189 ：デフォルトの名無しさん：2011/07/11(月) 01:41:02.56

>>183以外の人は理解できてるらしいから、別に誤解のある書き方だとは思わんよ。

190 ：デフォルトの名無しさん：2011/07/11(月) 01:45:51.42

>>183
>>184

>>91の結果がアフィン空間をベースにしてんだろ何かおかしいか？

191 ：デフォルトの名無しさん：2011/07/11(月) 01:47:07.19

オブジェクト自体はクラスとは関係無し

192 ：デフォルトの名無しさん：2011/07/11(月) 01:47:12.63

別スレ立ててやれ
これ以上このスレ汚すな

193 ：デフォルトの名無しさん：2011/07/11(月) 01:48:05.83

>>191
構造体も禁止します

194 ：デフォルトの名無しさん：2011/07/11(月) 01:59:32.89

>>186
このスレにそんな事書きこむお前も大概だけどな。
ADHDっぽいヤツが増えたのは確かだな。

195 ：デフォルトの名無しさん：2011/07/11(月) 02:01:02.78

もうあきたしねる

196 ：デフォルトの名無しさん：2011/07/11(月) 02:06:46.67

>>192
無駄だよ。>>183からしてみたら、俺もお前も>>91一人にしか見えないらしいから。

しかも、こんな事書いてる時点で職業プログラマーじゃないし。
>お前が仕様にない応用を利かせたせいでプロジェクトが破綻していく様がリアルに見える
(コード自体の仕様ってあまり書かないし、UMLとかで書いた場合その枠から出た時点でレビューで引っかかる)

197 ：デフォルトの名無しさん：2011/07/11(月) 02:09:26.35

>>196
>>192≠>>196=>>91

198 ：196：2011/07/11(月) 02:09:44.08

中途半端にレスしてしまった。

>しかも、こんな事書いてる時点で職業プログラマーじゃないし。
しかも、こんな事書いてる時点で職業プログラマーじゃないし。まともに話は通じそうにない。

199 ：デフォルトの名無しさん：2011/07/11(月) 04:38:30.07

クロージャとオブジェクト指向ってなんか関係あるの？

200 ：デフォルトの名無しさん：2011/07/11(月) 06:18:50.70

さっさとこのスレを消費したらいい。板のスレ掃除のためだよ。
ここが終わったら
http://hibari.2ch.net/test/read.cgi/tech/1293264747/l50
の掃除もよろしく。

201 ：デフォルトの名無しさん：2011/07/11(月) 10:09:38.16

仕様書は普通だろ
UMLじゃないところも多いだろ

202 ：デフォルトの名無しさん：2011/07/11(月) 22:13:31.80

UMLとか作ってる暇あるとことか幸せだな

203 ：デフォルトの名無しさん：2011/07/11(月) 22:41:05.06

オブジェクト指向の一番おいしいところは
マルチプルインスタンスだと思う
STLやLinqみたいな関数型ともうまくあうし

204 ：デフォルトの名無しさん：2011/07/11(月) 22:42:54.43

え？

205 ：デフォルトの名無しさん：2011/07/11(月) 23:06:48.69

なんでオブジェクト指向とクラスやらインスタンスやらがセットで語られているのだ
こんなにプロトタイプベースのjavascriptが流行ってるのに

206 ：デフォルトの名無しさん：2011/07/11(月) 23:08:34.39

プロトタイプベースのjavascriptというけれど
モダンな書き方を見ると、どうもクラスベースっぽく
書くのが流行ってるよねｗ

207 ：デフォルトの名無しさん：2011/07/11(月) 23:14:17.32

ECMAScriptベースのActionScriptはただのJavaと化してる

208 ：デフォルトの名無しさん：2011/07/12(火) 00:41:21.15

結局はなんだかんだで魔術っぽい書き方は排除されてくんだよな・・

209 ：デフォルトの名無しさん：2011/07/12(火) 00:54:02.65

結局「オブジェクト」って一言で言うと何なのでございます？

210 ：デフォルトの名無しさん：2011/07/12(火) 01:08:33.65

名詞

211 ：デフォルトの名無しさん：2011/07/12(火) 01:22:29.89

目的語でしょ

212 ：デフォルトの名無しさん：2011/07/12(火) 01:41:00.44

観測者が認識できるものすべて

213 ：デフォルトの名無しさん：2011/07/12(火) 03:55:17.69

オブジェクト指向っぽくファクトリパターンで
設計してみたら失敗した
カプセル化以外の目的で使用するとすごい手間
がかかって難しいね

214 ：デフォルトの名無しさん：2011/07/12(火) 06:20:54.60

状態

215 ：デフォルトの名無しさん：2011/07/12(火) 08:47:00.38

>>213
すでに出来上がったものに対して再利用するために書き換えるというのがいいよ

216 ：デフォルトの名無しさん：2011/07/12(火) 08:58:35.43

オブジェクト指向は商用がベースだから
ビジネス指向です

217 ：デフォルトの名無しさん：2011/07/12(火) 17:57:19.30

オブジェクト．．．か．．．なんなんだろうね
デザパタオタクが居るとデスマーチの声が聞こえてくる　テク走りはオブジェクトの勘違いじゃねぇの？

オタクはこんなのを読んでオブジェクトの整理ができればなんとかなるかな？
http://www.amazon.com/Object-Models-Strategies-Patterns-Applications/dp/0138401179

218 ：デフォルトの名無しさん：2011/07/12(火) 22:57:21.42

>>209
メッセージを受ける者

219 ：デフォルトの名無しさん：2011/07/12(火) 23:24:45.27

オブジェクトはバズワード

220 ：デフォルトの名無しさん：2011/07/12(火) 23:31:22.44

メモリ領域

221 ：デフォルトの名無しさん：2011/07/12(火) 23:57:30.38

オブジェクトと言う言葉を使わずにOOPを定義して

222 ：デフォルトの名無しさん：2011/07/13(水) 00:21:37.95

>>221
メッセージのやりとりでプログラム構築

つかオブジェクト指向でオブジェクトは全然重要じゃない。
むしろ実装上の都合ぐらいのもんだし。

223 ：デフォルトの名無しさん：2011/07/13(水) 00:30:56.47

>>222
何と何がメッセージのやり取り？

224 ：デフォルトの名無しさん：2011/07/13(水) 00:41:57.48

なんでも構わん。
仮にプロセス(実行プロセスではない)の集合体をグループとして扱えて、
グループの識別名を基準にメッセージを送れる言語があっても構わん。

'groupA groupB'.Message(10);

groupAとgroupBに所属するプロセス全てにメッセージを送信。
昔は負荷がでかすぎて現実的じゃなかったが、
いまはマルチコアの影響とかで、ぼちぼち近いものを見るようになった。
しかも、何故かOOから名前を変えて独立した扱いになってる。

225 ：デフォルトの名無しさん：2011/07/13(水) 00:51:17.22

じゃあオブジェクトの定義は？

226 ：デフォルトの名無しさん：2011/07/13(水) 00:58:16.31

メッセージを受信する事によって振る舞いを行う物の便宜的名称。

227 ：デフォルトの名無しさん：2011/07/13(水) 01:00:28.46

それだとインターネットとオブジェクト指向の違いがわからないと思う。
ネットは文字ベースだがオブジェクト指向は文字ベースではない、
ってことにすればいいだろ。

228 ：デフォルトの名無しさん：2011/07/13(水) 01:05:23.60

>>226
は？その定義だとオブジェクト指向にはオブジェクトが重要になるんだが？
> オブジェクト指向でオブジェクトは全然重要じゃない

229 ：デフォルトの名無しさん：2011/07/13(水) 01:07:55.29

オブジェクトって別に構造体である必要ないからな。
例えばunsigned longで一意に識別される値とそれに紐づいた
ひとつの関数ばっかりで構成されてても構わんし。
メッセージを受け取るときに、オブジェクトが自分で振る舞いを判断
できさえすれば実装はなんでもかまわん。

230 ：デフォルトの名無しさん：2011/07/13(水) 01:09:16.17

>>229
だからオブジェクトが重要なんだが？
> オブジェクト指向でオブジェクトは全然重要じゃない

231 ：デフォルトの名無しさん：2011/07/13(水) 01:14:13.94

>>227
文字かどうかは関係ないんだよ。
別にインターネットをメッセージの送信先にしても構わんし。
実際、TCPで動くMPI(Message Passing Interface)もオブジェクト指向の
考えを汲んでる(どっちかというとこっちが先)

232 ：デフォルトの名無しさん：2011/07/13(水) 01:16:55.87

>>230 重要とはどういう意味で？
オブジェクトという言葉を使わなければメッセージの送受信のつながりを説明できないからか？
それともオブジェクトだけ掘り下げれば話が広がるからか？
後者の意味で言うなら全然重要ではないと思うけれども。

233 ：デフォルトの名無しさん：2011/07/13(水) 01:19:40.89

>>232
自分で言ったこと忘れたの？>>226

234 ：デフォルトの名無しさん：2011/07/13(水) 01:20:24.56

>>231
なんで自分にレスしてるの？

235 ：デフォルトの名無しさん：2011/07/13(水) 01:31:03.88

>>233
ああ、そっちを意図してんのね。
まぁ、便宜的に呼ぶならオブジェクトなんて言わずノードやプロセスの方が直接的でいいんだけどな。
とはいえノードやプロセスは一般的すぎて誤解を呼ぶから現実的じゃなかったりする。

236 ：デフォルトの名無しさん：2011/07/13(水) 01:31:05.23

>>231
SQLのような文字列を
なるべく使わないのがオブジェクト指向だろ。

237 ：デフォルトの名無しさん：2011/07/13(水) 01:37:51.02

>>236
そのレベルならそもそもオブジェクト指向とは関係ない。
JavaやらC#とかプログラミング言語のただの作法の話。

238 ：デフォルトの名無しさん：2011/07/13(水) 01:39:54.59

>>236
Objective-Cやjavascriptなんかはメッセージと文字列が極めて近い
相互変換が言語レベルで可能

239 ：デフォルトの名無しさん：2011/07/13(水) 01:44:55.13

>>236
SQLでも、SQLの受信者が、指定した受信先へメッセージを送ってくれるなら
オブジェクト指向として成立するんだけどな。

240 ：デフォルトの名無しさん：2011/07/13(水) 01:50:02.68

>>236
OOデータベースだって文字列のやりとり多いぞ。

241 ：デフォルトの名無しさん：2011/07/13(水) 01:56:36.50

C#のLINQみたいなやつはオブジェクト指向と言えるのでございます？

242 ：デフォルトの名無しさん：2011/07/13(水) 02:12:28.30

>>233
Window Objectにメッセージを送るっての変だろ。
Windowにメッセージを送るっていうだろ。
Fileポインタを開くとは言わずファイルを開くというだろ。
概念の説明にfoo bar的にオブジェクトいってる理由で、
実際にメッセージを受信する物をオブジェクトって呼ぶのはおかしい。
少なくともオブジェクトという表現は、実際にメッセージを受信する
対象の名前に比べれば重要じゃない。

243 ：デフォルトの名無しさん：2011/07/13(水) 02:14:20.28

>>241
ただの言語機能だろ。
COBOLの埋め込みSQLはオブジェクト指向ですか？って言っているようなもんじゃん。

244 ：デフォルトの名無しさん：2011/07/13(水) 02:24:10.65

>>242
Windowってなんですか？

245 ：デフォルトの名無しさん：2011/07/13(水) 02:28:00.80

>>241
>SQLでも、SQLの受信者が、指定した受信先へメッセージを送ってくれるなら
>オブジェクト指向として成立するんだけどな。
これを誤解したのかもしれないけど、これはSQLにメッセージの受信先を指定してやったら、
selectでNULLが含まれる行が見つかるたびに、DBが受信先にメッセージを送ってくるとか
そういう話。

246 ：デフォルトの名無しさん：2011/07/13(水) 02:29:34.10

>>245
この前ボコボコにされた気分はどう？

247 ：デフォルトの名無しさん：2011/07/13(水) 02:31:55.82

>>244
GUI方式でよく使われるアプリケーション用描画領域の事。

248 ：デフォルトの名無しさん：2011/07/13(水) 02:38:52.95

>>246って別スレで天使とか名乗って絡んできてた痛い人？

249 ：デフォルトの名無しさん：2011/07/13(水) 06:30:45.59

オブジェクトに空虚な程
抽象的な定義を与えようとしてる輩は
アーキテクチャ宇宙飛行士

250 ：デフォルトの名無しさん：2011/07/13(水) 17:15:13.94

メッセージ云々言っている人の主張がよくわからん
それってただの関数コールと何が違うの？

251 ：デフォルトの名無しさん：2011/07/13(水) 17:46:01.79

callerとcalleeは非対称すぎてつらい事がある
でもメッセージの人はどれでも同じだと言いそう

252 ：デフォルトの名無しさん：2011/07/13(水) 18:57:44.30

OOPがメッセージドリブンになるのは解るが　メッセージドリブンがOOPだとは思わんが？
OOPとはシステムの考え方であって　クラス、オブジェクトを物と振る舞いにしっかり区別して考えられる事だと思うが？
デザパタハイになってる奴が今　横に居るが　ｗ

253 ：デフォルトの名無しさん：2011/07/13(水) 19:19:14.96

オブジェクト指向なんてぼやっとしたものなんだからあんまり熱くなるな

254 ：デフォルトの名無しさん：2011/07/13(水) 20:12:41.35

>>250
メッセージは、オブジェクトに所属していない。
メンバー関数やメソッドはオブジェクトに縛られてる。
そこが根本的に異なる。smalltalkなんかではメソッドと
メッセージが分離してるから、一度さわってみればよく解る。

それから、メッセージを強調する理由は2点。
1.メソッド&クラスの話になると、カプセル化とか継承とか
　クラス構造とかピントのズレた話になる。
　そもそも、オブジェクトを中からの視点で見ちゃいけない、
　外部からの振る舞いにこだわらないと本来の再利用性とかの
　メリットが失われる。

2.メッセージの概念を実装できていれば、どういう形であれOOとして成立する。
　例えば、WinAPIのウィンドウは、SendMessageやPostMessageで
　ウィンドウ間の通信が行えるけど、smalltalkとNeXTのOO方式をCで実装してる。
　昔のMSのAPIの説明なんかには、CloseHandleとかを例に上げて
　これがポリモーフィズムです。なんてほざいてたが、ウィンドウ部分に
　関しては割とOOの概念に忠実だった。

255 ：デフォルトの名無しさん：2011/07/13(水) 22:19:15.30

>>254
なんだ、またマルチメソッドの話になるのか
OOPスレにいた人？

256 ：デフォルトの名無しさん：2011/07/13(水) 22:28:24.11

全然違う話だろ

257 ：デフォルトの名無しさん：2011/07/13(水) 22:38:48.22

メッセージは、オブジェクトに所属していない
　↓
オブジェクトに所属してないメソッド
　↓
マルチメソッド

という連想だったんだけど全然違うの？

メッセージが何なのか具体的に説明してくれ

258 ：デフォルトの名無しさん：2011/07/13(水) 23:14:37.47

WinAPIのSendMessageとそこで送られたメッセージが
どう処理に結び付けられてるかを調べてみ。
先に言うがそこでのswitchの分岐一つ一つがメソッドになる。

259 ：デフォルトの名無しさん：2011/07/13(水) 23:31:06.42

＞Smalltalkなんかではメソッドとメッセージが分離してる

Smalltalkerが勤勉な人が多いためか、ブルーブックとかに書かれている内容を
正しく使う人が多いよね
ちゃんとメッセージセレクタとメソッドが別っていう具合に

でも、C++なんかでも結局function-call-expressionでメッセージセレクタを指定してる
といえばそうなのかもしれないと思った

260 ：デフォルトの名無しさん：2011/07/13(水) 23:31:07.45

Windowオブジェクトのメソッドを
SendMessage経由で呼び出してるようにしか見えない

結局のところメッセージって何？

261 ：デフォルトの名無しさん：2011/07/13(水) 23:40:35.67

SendMessageで送ってる内容だよ。

もしかしたら、Javaあたりの言い回しから
あるメソッドを呼び出したら、どのメソッドが
呼ばれるかオブジェクト次第で不定とか思ってる?

前者の"メソッド呼び出し"の部分が元々
メッセージってよばれてる部分なんだけど。

262 ：デフォルトの名無しさん：2011/07/13(水) 23:41:20.36

>>257
254はいろいろとちょこちょこと間違っているような気がする。^^;　あと、
Smalltalkを含めて、現実装からメッセージを解釈しようとすると250みたいになるのはしょうがない。

メッセージって言うのは、しょせんは（主には発案者のアラン・ケイの）気持ちの持ちようの問題。
もともと、多細胞生物における細胞の動的協働をソフトウエアに応用できないかという着想を得て、
現在主流の言語の仕組みでいう動的な関数呼び出しをそう解釈してみようって思考実験程度のもの。
Smalltalk はその世界観の体現の試みではあるけれど、理想にはほど遠い。話を聞いた他の人が
愚直に実装を試みたActorとかSELFとかもあったけど、ケイはどちらも「コレジャナイ」と言っている。

263 ：デフォルトの名無しさん：2011/07/13(水) 23:42:48.98

正しい実装が無い中で、あえてメッセージングという考え方が何者であるかを現実装で喩えようとするなら、
>>262
Smalltalkの#doesNotUnderstand:とかRubyのmethod_missing、Obj-CのdoseNotRecognizeSelector:を
使った俗に黒魔術と称される類のテクニックの方がこの「気持ち」にはいくらか近いと思う。
なので通常とは逆に、これらの処理の特殊なパターンが普通のメソッド呼び出しだと発想を逆転できると、
なんとなく「メッセージング」とやらの目指す方向性がつかめるかも。ってもやっぱわかんないよね。ごめん。

264 ：デフォルトの名無しさん：2011/07/14(木) 00:06:19.07

>>260
いらない子

265 ：デフォルトの名無しさん：2011/07/14(木) 00:07:31.40

>>261
>前者の"メソッド呼び出し"の部分が元々
>メッセージってよばれてる部分なんだけど。

>>250 → >>254 → >>261 → >>250 → ・・・

無限ループって(以下略)

266 ：デフォルトの名無しさん：2011/07/14(木) 00:13:15.83

>>265
ちゃんとJavaやら新参言語がメソッドの一言でごちゃ混ぜにしてる
メッセージとメソッドを分離できるようになれば、そのうち止まるんじゃね？

267 ：デフォルトの名無しさん：2011/07/14(木) 00:28:40.29

分離するメリットがない

268 ：デフォルトの名無しさん：2011/07/14(木) 00:33:14.24

オブジェクト指向か否かなんて考えるのはもう古いんだよ。

○○の機能はあるか？で考えたほうがいい。

269 ：デフォルトの名無しさん：2011/07/14(木) 00:55:13.50

>>268
つまり動的型付けでダックタイピングが良い…と？

270 ：デフォルトの名無しさん：2011/07/14(木) 01:11:34.79

>>267
言語上のインターフェースに囚われてる限りはそうかもね。
そっちはインターフェースのメソッドとか、言い回しを工夫して
どうにかメッセージ的部分とメソッドを言いわけてるし。

ただし、大抵オブジェクトや、メソッド部分にばかり話が広がって
メッセージをいかにデザインするかって話が広がりにくい。
特に話してる人によってメソッドをどの面で捉えてるかバラバラな事が大半。

>>269
smalltalkとか純粋なOOPLは今でいうダックタイピングだし、
ライブラリレベルで実装されたOO環境もダックタイピング多いじゃん。
どっちかってとダックタイピングできない環境の方がイレギュラーじゃね。

271 ：デフォルトの名無しさん：2011/07/14(木) 01:53:30.49

何を持って純粋なOOPLというのかね。

smalltalkが純粋と言われる理由は
初期のOOPLってだけじゃない？

272 ：デフォルトの名無しさん：2011/07/14(木) 01:55:13.19

ダックタイピングがOOPLというのも
単にsmalltalkがそうだっただけの話。

OOPLにダックタイピングが必須だとは思わないし、
逆に初期の未熟なOOPLではダックタイピングでしか
実装できなかったと考えるべきだろう。

273 ：デフォルトの名無しさん：2011/07/14(木) 02:09:02.02

ダックタイピングって
例えれば、変数定義が必要ない構造化言語みたいなもんだと思うけどね。

変数定義があってもなくても変数は使える。

変数定義が必要なければ、いつでもどこでも好きな変数が使える
定義する面倒さがない。

が変数定義があるとバグが起きにくくなる。

ダックタイピングも同じで多態を行うときに
多態定義が必要なければ、いつでもどこでも好きな多態が行える
定義する面倒さがいらないが、多態定義があればバグが起きにくくなる。

274 ：デフォルトの名無しさん：2011/07/14(木) 02:10:44.59

>>271
メッセージとオブジェクトが完全に独立してる事じゃない？
全く同じメッセージを受け取れるのに、インターフェースが違うから
メッセージを受け取れない事がよくあるってのは純粋じゃないでしょ。
副作用を許した関数型と同じじゃん。

275 ：デフォルトの名無しさん：2011/07/14(木) 02:23:20.31

メッセージとオブジェクトが完全に独立していれば
なぜそれが純粋なのか。

> 全く同じメッセージを受け取れるのに、インターフェースが違うから
> メッセージを受け取れない事がよくあるってのは純粋じゃないでしょ。

「全く同じメッセージ」の定義は何か。
たとえば「つまらん」という言葉がある。
「つまらん」と「つまらん」全く同じメッセージにように見えるが、
片方は標準語インターフェースのつまらん。
もう片方は九州弁のつまらん。

インターフェースというのは、一見同じに見えるが違うメッセージを
区別するときに使うもので、本質的には違うメッセージなのだから
分けるべきではないのだろうか？

いわばインターフェースは違うメッセージを区別するためのメタ情報。

276 ：デフォルトの名無しさん：2011/07/14(木) 02:26:59.70

smalltalkはメッセージ名だけでメッセージを区別する。
メッセージ名が同じなら反応する。

でもプロジェクトが大きくなって他の人が作ったものを利用しだすと、
メッセージ名は短すぎてかぶることがあるよね。ってことで
インターフェース名＋メッセージ名で区別する。

単に名前が被らないようにするためだけの違いでしかないのではないか？

277 ：デフォルトの名無しさん：2011/07/14(木) 02:31:21.93

なんだかんだでVB6ってかなりオブジェクト指向だったんだよな。

ダックタイピングもインターフェースも両方使える。

newで生成したオブジェクトをobject型変数に入れて呼び出すと、
ダックタイピングでメソッドが一致したものが呼び出される。

同じオブジェクトをインターフェース型変数に入れて呼び出すと
そのインターフェースのメソッドが呼び出される。

278 ：デフォルトの名無しさん：2011/07/14(木) 07:33:51.67

>>1
継承やらスタティックバインドを一杯作ってOOPプログラマーでござ～い　とか？
馬鹿に　オブジェクト間のカップリングや稠密度の話が理解できるのか？　そもそも馬鹿はOOPなんてできんだろ？

279 ：デフォルトの名無しさん：2011/07/14(木) 08:55:51.30

意味があったらJavaやC++に採用されてる

280 ：デフォルトの名無しさん：2011/07/14(木) 15:52:29.64

何の抽象化もせずクラス作ってそこからさらに派生させているやつは何考えてるの？

281 ：デフォルトの名無しさん：2011/07/14(木) 17:09:44.82

JavaもC++もSmalltalkも同じオブジェクト指向とする共通点は何？
メッセージさん的にはそもそもJavaをオブジェクト指向言語というのはおかしいってこと？

ちなみにJava界でオブジェクト指向大好きな人たちが名著というオブジェクト指向のこころという書籍ではメッセージなんて本質ではないと書いてあったな
書籍内でメッセージという単語は一切出てこない
やっぱり同じオブジェクト指向という言葉を使っていても人によってまったく別の意味として認識しているとしか思えない

282 ：デフォルトの名無しさん：2011/07/14(木) 19:03:05.94

>>280
抽象なんて思考はないんじゃね？　イベントをクリックするとIDEが自動で関数を生成してくれるからそこに処理を書いていくだけという．．．
メインフォームのソースが1万行とか　ｗ

ん？　継承の事か？　継承もOOPの一部だが　それで解決しようなんて　アホ教科書がいまだに山ほどあるからな
20年前のオブジェクト指向を今も継承しているという馬鹿プログラマーが居る事も事実　ｗ
まっ　日々　実務に追われているプログラマーなんてそんなもん　has-a　is-aのTPOが解らんのさ　ｗ

という現状を見れば>>1の指摘も間違いでは無い

>>281
メッセージは本質ではないよ　大事なのはオブジェクト間の結合だよ　そして　物と振る舞いの分離　それと　それらを調停するコーディネーター
メッセージドリブンは絶対的要素ではあるが．．．

283 ：デフォルトの名無しさん：2011/07/14(木) 19:21:06.31

OOPの真髄を堪能するには．．．．
smalltalkのような手取り足取りの世界でOOPを味わった後に　CでOOPを記述してみる事だ　ｗ
今は　CでOOPファームウェアを書くのは苦で無くなったが　Delphiでアプリを書いている頃は　チャレンジの度に心臓パクパクだった　ｗ

284 ：デフォルトの名無しさん：2011/07/14(木) 20:32:44.82

>>281
そもそも、JavaやC++が得意とするオブジェクト指向と、Smalltalkで目指したオブジェクト指向は
いくつかの言語要素と「オブジェクト指向」という名前が共通するだけで、本質的には別物だから
ごっちゃにしないほうがいいよ。

前者は抽象データ型をクラスで実現する手法で、後者はメッセージングを介在させてできるだけ多くの事を
疎結合に保とうとする試み。前者は型安全であることが重要で、後者はできるだけ動的であることが大事。

JavaやC++でメソッド呼び出しをメッセージと解釈することもできるけれど、そもそも抽象データ型のＯＯと
メッセージングのＯＯとでは出自も目指すところも違うから、あまり幸せになれないと思う。逆もまたしかり。

285 ：デフォルトの名無しさん：2011/07/14(木) 20:40:00.33

クラスもオブジェクトもクロージャも遅延評価も大好物の俺に死角はなかった。

はずだったが、底辺環境のプログラマは手続き型で書くのがやっと。
たまにクラス書かせると、それはもうひどいものが出来上がってきてしまう。

教育って大事だ。
底辺だからと諦めて欲しくないが、中途半端な知識でオブジェクトは使い物にならないっていうのは、さらに酷いという自覚をも持って欲しい。
できる人間は手続きもオブジェクトも関数型も上手に乗りこなす。

286 ：デフォルトの名無しさん：2011/07/14(木) 20:55:01.86

>>285
底辺はJavaだろ
C/C++なんて仕事少ないから底辺は駆逐される

287 ：デフォルトの名無しさん：2011/07/14(木) 21:00:22.31

うわ～　OOPの化け物共がぞろぞろ出てきた　ｗ　OOPの真髄　疎結合が出たら　他は何も無い
コーディネーターもイニシェーターもそのルールに従うだけ

288 ：デフォルトの名無しさん：2011/07/14(木) 21:20:27.03

>>286
Javaを使えばオブジェクト指向
そんなふうに考えていた時代がオレにもありました…

289 ：デフォルトの名無しさん：2011/07/14(木) 21:49:04.63

>>275
>>276
object.connect("http://example.com/");
object.connect("jdbc:oracle:oci8:@oracle.techscore");.//危険だ～
こういう事か？これをインターフェースなら綺麗にやれるというなら、
そもそも開発方針が間違ってるよ。あと、こういう安全面は、
オブジェクト指向というより型安全の世界の話でしょ。

290 ：デフォルトの名無しさん：2011/07/14(木) 22:02:48.49

そういや Scheme はもともとアクターモデルの検証のために
実験的に作られ、そこで関数呼び出しとメッセージ送信を
それぞれ実装（lambdaとalpha）してみたら
まったく同じ実装になった、とかいう話があったような

291 ：デフォルトの名無しさん：2011/07/14(木) 22:03:52.70

あ、lambdaとalphaは呼び出し側じゃなくて
定義する側の構文ね、分かると思うけど

292 ：デフォルトの名無しさん：2011/07/14(木) 22:45:47.81

インターフェース&クラス型の言語は不親切だ。
オブジェクト指向を支援してくれるというのは解るが、
殆ど構造体の発展形にしか見えず、Smalltalkなんかを
使った事の無いプログラマーには何も教えてくれない。
getPoint().getX();みたいなのが平気でまかり通ってる。

あと、こんな感じの定義はよく見る。
void parse(Map<Key,String> params)
このメソッドはparams.get()しか呼ばないとする。
parseは、インタフェースによって使いもしない他のメンバーを
実装することを強いてる。仮に同じparseのget()だけが必要という
要求に答えられるオブジェクトをユーザーが知っていてもparseに
渡すことはできない。そういうコードに慣れたユーザーはどんどん不必要な
メソッドを要求するメソッドを書くことに違和感が無くなっていく。

型安全と速度の引換に依存性の分離から、メッセージの独立性で生まれる
本来の意味での再利用性とカプセル化の意義をユーザーに見失わせてる。

293 ：デフォルトの名無しさん：2011/07/14(木) 22:54:40.62

そもそも、1のクラスが10個や20個も他のオブジェクトの正体を知ってるのはナンセンスだよね。
10種類もオブジェクトを生成するなとは言わないけど、せめてフィールドには、正体が解ってる
オブジェクトを置くのは避けるべきだ。

※正体を知ってる・・・どのクラスが生成したか知っている

294 ：デフォルトの名無しさん：2011/07/14(木) 23:09:59.32

Smalltalk ｗ

295 ：デフォルトの名無しさん：2011/07/14(木) 23:25:36.81

>>292
> void parse(Map<Key,String> params)
> このメソッドはparams.get()しか呼ばないとする。
> parseは、インタフェースによって使いもしない他のメンバーを
> 実装することを強いてる。

えとさ、継承って知ってる？
その場合、Map<Key,String>を継承してgetを
オーバーライドすればいいだけだよ。

296 ：デフォルトの名無しさん：2011/07/14(木) 23:28:26.14

それから、
> void parse(Map<Key,String> params)
> このメソッドはparams.get()しか呼ばないとする。

この考えはダメ。

parseがparams.getしか呼ばないということを、
「君は知っている」つまり
中の実装を気にしているってことだ。

関数同士の依存関係を薄く保つには
関数の中にコードに依存したコードを書いてはいけない。
parseが中で何をしているかを意識してはいけない。
ブラックボックスとして扱うべきだ。

297 ：デフォルトの名無しさん：2011/07/14(木) 23:34:05.10

もう一つ。

parseがparams.getしか呼ばないということが
仕様で決まっているというのなら
引数はそもそもgetだけをもったインターフェース型にするべきだ。

そうすればparseはgetしか呼ばない。と言葉で書くのではなく、
関数のシグネチャとして、getしか呼ばないことが保証される。

つまり間違った設計を自分でしておいて、
自分で間違っていると指摘しているに過ぎない。

さらに引数をgetだけを持ったインターフェース型にしておけば
もしあとでparseの実装が変わってget以外も使うことになったとき、
parseの引数の型によってオーバーロードできるから
互換性を保ったまま、新たなparseをつくることも可能になるし、
またインターフェースそのものを変えてしまえば、影響があるコードは
コンパイルエラーを起こすので、柔整箇所の把握も楽になる。

298 ：デフォルトの名無しさん：2011/07/14(木) 23:37:55.11

>>295
言いたいことは解る。
でもね、他の言語だとオーバーライドすらしなくて済むんだよ。
メッセージはインターフェースやクラスに縛られてないから。

>>296
それを言えばインターフェースは既に外に漏らしてるって事だよね。
要求とブラックボックスは別領域。
引数に対し要求を求めることはブラックボックス化が崩れる事にはならない。
なぜだか解るかい？

299 ：デフォルトの名無しさん：2011/07/14(木) 23:38:36.72

なぜだか解るかい？ｗ

300 ：デフォルトの名無しさん：2011/07/14(木) 23:39:15.73

>>297 これが型ベース言語で育った弊害だよな・・・。

301 ：デフォルトの名無しさん：2011/07/14(木) 23:40:04.43

> それを言えばインターフェースは既に外に漏らしてるって事だよね。

インターフェースってのは、何かと何かをつなぐための決まりのことだ。
漏らすのはインターフェースの本質だ。

隠すもの（内部実装）は隠して、
漏らすもの（インターフェース）をはっきりさせよう。

はっきりさせるとは、コード読めやコメントを書くことではない。
コード自身にそれが含まれているということ。

302 ：デフォルトの名無しさん：2011/07/14(木) 23:40:59.59

>>300

303 ：デフォルトの名無しさん：2011/07/14(木) 23:41:12.85

テスト駆動。

型を最初に書くというのは
このテスト駆動に近いものがあるよね。

あとから（実行時）に動くかどうか考えるのではなく、
最初にきっちりとテスト（型）を書いておくことで
後が楽になる。

304 ：デフォルトの名無しさん：2011/07/14(木) 23:43:00.55

>>298
オーバーライドすることで、もしparseがget以外を使うと
仕様が変わっても対応できる。

オーバーライドという手間が必要になるが、
それは先にテストを書くのと同じこと。

急がば回れというだろう。

305 ：デフォルトの名無しさん：2011/07/14(木) 23:47:15.87

型を書くということの発想を変えて、

インターフェースとは、
この関数（parse）はgetしか使わない。という決まりを
表した物だと考えれば、これに反論する人はいないだろう。

関数の最初に「もし引数のオブジェクトが、getを持っているならば」という
チェックコードをを書くのといっしょだよ。
このチェックコードに文句をつける理由があるかい？

306 ：デフォルトの名無しさん：2011/07/14(木) 23:49:18.26

>>304
そもそも要求仕様を変えちゃいけない。
修正においてもオブジェクトは閉じてないといけない。

307 ：デフォルトの名無しさん：2011/07/14(木) 23:49:38.69

> そもそも要求仕様を変えちゃいけない。
仕様は変わる物。

308 ：デフォルトの名無しさん：2011/07/14(木) 23:52:24.60

>>304
例えば.net上で公開されたインターフェースにMSが勝手にメソッドを追加することが許されると思う？

309 ：デフォルトの名無しさん：2011/07/14(木) 23:52:25.06

Javaのインターフェイスとかは、動的言語のダックタイピングみたいな自由を
型安全に実現するために考え出されたものだから、使い方を間違わなければ
（型安全に拘るか否かのトレードオフはあるけれど）できることは基本、同じ。

310 ：デフォルトの名無しさん：2011/07/14(木) 23:55:30.10

>>309
1インターフェースに付き1メッソッドでならやや近い部分はあるね。
あと他のライブラリのクラスを移譲なしでインターフェースに入れられるかってのも大事だね。

まぁ、その辺の理想的なところはGoogleがGoで実験してたりする。

311 ：デフォルトの名無しさん：2011/07/14(木) 23:55:36.46

>>308
それはユーザーが沢山いるライブラリにおいての話。
ユーザーが沢山いて、そのユーザーが誰かわからない。

お前は.netのライブラリと同じぐらいユーザーがたくさんいる
ライブラリを作ってるのか？

大部分の人はライブラリを使う側だ。

お前の話は対象範囲が的外れで参考にならない。

312 ：デフォルトの名無しさん：2011/07/14(木) 23:58:35.68

型なんてただのチェックにすぎん。
型テストコードを書いているのと一緒

型が嫌いなやつは、テストコードを書くことも嫌いなんだろうな。
なんで型を書かないの？の答えが面倒だからだもんなｗ

313 ：デフォルトの名無しさん：2011/07/15(金) 00:01:58.26

>>301
コンパイル時にシグニチャのチェックが入るだけ。
OOのブラックボックスとは、まるで関係ない。

314 ：デフォルトの名無しさん：2011/07/15(金) 00:04:54.32

>>311
大抵OOPLはクラスライブラリとの連携を主体にしてる。
そもそも、smalltalkなんかはオブジェクトを利用するのが主で、
クラスを書くことがプログラミングの中心ではない。

315 ：デフォルトの名無しさん：2011/07/15(金) 00:06:14.41

Smalltalkとか終わった言語じゃん

316 ：３１４：2011/07/15(金) 00:08:23.48

もうひとついうと、プラガブルMVCなんかがいい例。
コードは積極的に書かず、必要な分だけライブラリで用意された
オブジェクトに差し込んでやる。いい例はSqueakToysだよ。
コードをほとんど書かなくても、ある程度のものは作れちゃう。

317 ：デフォルトの名無しさん：2011/07/15(金) 00:11:00.31

コンパイル時のチェックって意味なら、インターフェースはいらないと思う。
C++のテンプレートでダックタイピングしてて、
実装されてない関数なりメソッドをコールしてる箇所があったら、
それはコンパイルエラーになるでしょ。
やっぱ型の本分はメモリ上のレイアウトの解決だと思う。
C++では、型に色んなものを担わせて、クラスがどうとかこうとか言い出したからおかしくなっちゃったんだろう。

ただ、C++でのダックタイピングってオーバーロードの活用だから静的に解決しなきゃならないんだよな。
オーバーロードが動的になれば全てが一気に解決する。

318 ：デフォルトの名無しさん：2011/07/15(金) 00:12:32.20

頭悪い文章だ

319 ：デフォルトの名無しさん：2011/07/15(金) 00:12:42.88

>>311
土方おつ。
自社ライブラリ持ってる企業だったら、
インターフェースを変更せずに保守していく方法を
多かれ少なかれしってるよ。

320 ：デフォルトの名無しさん：2011/07/15(金) 00:14:21.54

頭悪い奴ほどOOPや関数型を語りたがる

321 ：デフォルトの名無しさん：2011/07/15(金) 00:14:25.44

// このparseはparamsのgetメソッドしか使用しません
void parse(params) {
}

インターフェースってのはこれをコンパイラが
理解できる形で書いたにすぎない。

あとは本当にgetメソッドしか使用していないか
引数のオブジェクトは必ずgetメソッドを実装しているかを
手動でテストするか、コンパイラで自動テストするかの違いだよ。

小さいプログラムなら、手動でテストできるレベルだから最初に準備しなくて良い分楽だろう
プログラムが大きくなってきたら、手動でテストをするのは現実的ではない。

手間を最初に持ってくるかあとに持ってくるかの違いであって、
それ以外の柔軟性とかそういうのは全く関係ない話。

322 ：デフォルトの名無しさん：2011/07/15(金) 00:17:03.72

>>319
本当にインターフェースが変更されてないって
どうやって確認するの？

例えばparseのコードがすごく長くて、
もし引数paramsのget以外のメソッドを使ってるコードが紛れ込んだ時、
それを10秒以内にチェックする方法を教えてくれ。

型っていうのは、インターフェースを変更せずの保守していることを
確認する手段でもあるんだよ。

323 ：デフォルトの名無しさん：2011/07/15(金) 00:18:34.77

だいたい、正の数しかとらないintの変数に負の数入れられたとき、
どうすんだって話と同じだしな。

324 ：デフォルトの名無しさん：2011/07/15(金) 00:19:09.93

だから、コンパイルすりゃエラーになるだろ。
実装していない関数をコールしてるんだからな。

325 ：デフォルトの名無しさん：2011/07/15(金) 00:19:20.19

>>323
それなら、正の数しか取らない型を作ればいいのでは？

326 ：デフォルトの名無しさん：2011/07/15(金) 00:22:07.73

型＝テストコード

引数の値をチェックするコードを書いているのなら、
そこを型にするだけで、引数のチェックが必要なくなる。

327 ：デフォルトの名無しさん：2011/07/15(金) 00:23:21.62

>>322
既存のparseを使ったテストコードでエラーになるからそのparseはアウト。
そもそも言えば、parseは既に他のプロジェクトで使用されてる可能性があるので、
インターフェースを崩す動作は変えられない。

328 ：デフォルトの名無しさん：2011/07/15(金) 00:24:28.60

>>325
正の数しかとらない型に負の値を入れられたらどうするの？

329 ：デフォルトの名無しさん：2011/07/15(金) 00:24:29.18

> 既存のparseを使ったテストコードでエラーになるから。

それは、テストコードが正しい場合の話。

じゃあ、テストコードが正しいかどうやってテストするのか？
テストコードのテストを書くの？ｗ

330 ：デフォルトの名無しさん：2011/07/15(金) 00:26:10.83

>>329
既存のテストコードなんだから正しいもクソもないがな。
インターフェースを書いたソースコードが正しいかどうか解からんっていってんのと同じだぞ。

331 ：デフォルトの名無しさん：2011/07/15(金) 00:26:30.58

型がテストコード？頭悪すぎる。元々型はコンパイラがメモリのレイアウトを決定するのに使われるものだ。
そんなものにテストコードまで担わせてどうするの？
テストコードはテストコードで別でやれよ。代用するなよ。乱用悪用の類。

332 ：デフォルトの名無しさん：2011/07/15(金) 00:26:51.11

>>328
使うところではなく、入れるところでエラーが起きるから
不具合の箇所がどこか把握しやすくなる。

知りたいのは、負の値が入っていました事実ではなく、
どこで負の値を入れたかだからね。

333 ：デフォルトの名無しさん：2011/07/15(金) 00:28:05.58

>>330
> インターフェースを書いたソースコードが正しいかどうか解からんっていってんのと同じだぞ。

ぜんぜん違う。

テストは書かなくても動く。
インターフェースは書かないと動かない。

強制的にテスト駆動開発をさせられているようなもんだ。
あとはそれが嫌かどうかの話。

334 ：デフォルトの名無しさん：2011/07/15(金) 00:29:36.44

>>331
お前は頭が固すぎ。
型がメモリのレイアウトを決定するだけなら、
RTTIなんてものはつくられていない。

335 ：デフォルトの名無しさん：2011/07/15(金) 00:32:06.85

>>334
だから、RTTI作った奴はバカなんでしょ。
このスレはタイトルからして、そういうスタンスでしょ。
作るべきは、動的オーバーロード呼び出し機能であって、RTTIでは無かったんだ。

336 ：デフォルトの名無しさん：2011/07/15(金) 00:33:32.98

テストコードはバグがあることを見つけるのは可能だけど
極端に言えば、何も書かなかったらバグは見つけられない。

既存のテストコードに足りないところがあれば、
テストは正しく動くが、バグはあることになる。
テストコードを過信してはいけないよ。
所詮人間がチェックしてるんだからね。

337 ：デフォルトの名無しさん：2011/07/15(金) 00:33:39.17

ずっと自演しているけどなんで？

338 ：デフォルトの名無しさん：2011/07/15(金) 00:34:26.83

>>333 それで満足ならそれでいいんじゃね？
うちみたいな、社内に試験用の部署持ってるとこからすると
型で既にチェックされてるなんて些細だと考えてるんで、
テストで保証されてることが、最低レベルの保証になるし。

339 ：デフォルトの名無しさん：2011/07/15(金) 00:36:05.22

>>338
なんか満足のレベルを勘違いしているみたいだけど

静的チェック＋テストコード＞テストコードのみ

この公式が揺らぐことはないよ。

340 ：デフォルトの名無しさん：2011/07/15(金) 00:38:19.52

>>336 テストでインターフェースが保証されるってところが解る？
ユーザーは、テストケースで渡されてないものを入れちゃいけないの。
テスト外のものを渡して動作がおかしくなったら、ユーザー側が直さなきゃいけないの。

341 ：デフォルトの名無しさん：2011/07/15(金) 00:40:11.03

試験用の部署ってのがなぁｗ

型だとコンパイルエラーになるんで、
試験用の部署の持っていくまでもない。

いちいちテスト用の部署に持って行って、些細な型エラー
（つまり想定外のメソッドを使っていた）で戻ってくると
行ったり来たりさせる無駄はあほらしい。

大企業病とかいうやつですかね。
自分でテストはしないでいいと考えてるでしょｗ

342 ：デフォルトの名無しさん：2011/07/15(金) 00:41:19.03

>>340
> テストでインターフェースが保証されるってところが解る？

そのテストが正しいと保証されている場合はね。

テストのテスト、ちゃんとやってるか？ｗ

343 ：デフォルトの名無しさん：2011/07/15(金) 00:42:48.80

インターフェースでガチガチにするほうがどう考えても大企業病なのに、へんなことを言うよな。
全部がずれてる。

344 ：デフォルトの名無しさん：2011/07/15(金) 00:43:01.61

>>341 別に部署があるから開発部門でいい加減なテストはできないんだよ。

345 ：デフォルトの名無しさん：2011/07/15(金) 00:44:07.45

>>343
根拠が示されてない以上。
俺がそう思っているから、そうなんだといってるだけだなｗ

346 ：デフォルトの名無しさん：2011/07/15(金) 00:45:59.24

いい加減なテストをしない俺は

静的テスト＋動的テストの
二段階を行っている。

ダブルチェックという言葉知ってるか？

347 ：デフォルトの名無しさん：2011/07/15(金) 00:46:46.84

>>342
テストコードの内容から、保証をしてんのに何いってんの？
このコードは通りました、このコードと同じ使い方なら、
問題は有りませんって事なのに。

348 ：デフォルトの名無しさん：2011/07/15(金) 00:47:17.79

静的テストには、たとえば
未定義の変数を使わない。
なども含まれている。

変数の定義をしなくてもいいと思うのだろうが、
こうすることで動的テストをするまでに
些細なエラーを修正できるので
時間を効率よく使用できる。

349 ：デフォルトの名無しさん：2011/07/15(金) 00:48:43.35

>>347
だから、その保証が足りない場合はどうするのさ。

想定外の使われ方をしました。
想定外なのでテストコードを書くなんてできません。

350 ：デフォルトの名無しさん：2011/07/15(金) 00:51:00.07

だいたい人間が頑張るという考え方が
土方的なんだよ。

せっかくコンピュータがあるのだから
人間が頑張るよりも前に
コンピュータに頑張らせるを事考えないといかん。

テストコードを書かなくてもテストできることがあるのなら
それらは全部コンピュータにさせるべきだ。

人間が楽をするためにコードを書くべき。
楽をするというのは手抜きするということじゃない。

351 ：デフォルトの名無しさん：2011/07/15(金) 00:51:46.75

>>349
想定外の使い方をした方が直すに決まってんだろ。

352 ：デフォルトの名無しさん：2011/07/15(金) 00:54:17.95

>>349
簡単じゃん。お前の言ってる
「想定外のメソッドを使っていた」
の場合、ビルドが通らないんだから、
それ以上のことは必要ないだろ。

あとは仕様書に従って、間違ってる方が直すだけ。

353 ：デフォルトの名無しさん：2011/07/15(金) 00:54:38.55

てか、型安全を語りたいヤツは他所でやれ。
OOPLじゃなくても型付け言語は存在するし、
オブジェクト指向自体とは関係ない。

354 ：デフォルトの名無しさん：2011/07/15(金) 00:58:02.29

>>352
え？ビルド？
ビルドは静的言語の特権だけど。

355 ：デフォルトの名無しさん：2011/07/15(金) 00:59:10.17

>>351
話ズレてるよ。

想定外の使われ方をされた場合
テストコードもないわけで、
「テストが不足」している状態になる。

このようにテストコードは不足していることがあり得るのだから
テストがあれば完璧などということにはならない。

356 ：デフォルトの名無しさん：2011/07/15(金) 01:02:12.04

>>353
だよね。

俺は最初から、テスト駆動と一緒で
最初に型書いていて静的チェックできるようにするか
動的テストをあとから書くかの違いだって言ってるだけなのに。

面倒くさいところを最初にやるか、
あとでやるか（やらないやつもいるけどｗ）
それだけの違いで柔軟性とかそんなのには関係ない
どっちも同じことができると言ってるだけ。

でもどうも静的チェックがなんか悪い物だって考えているやつがいるようだ。

357 ：デフォルトの名無しさん：2011/07/15(金) 01:03:06.30

インターフェースがあれば
仕様をコードに組み込める。

それは手間がかかるが便利なこと

358 ：デフォルトの名無しさん：2011/07/15(金) 01:11:09.77

>>354
だから、たとえインターフェースで保障されてなくても、
実装されてない無い関数呼んでたんじゃ、どうせ、ビルドできないだろって言ってる。
「そんな関数ありません」ってコンパイラに言われる。
だから、コンパイラの静的型チェックとインターフェースは関係ない。
インターフェースはポリモのためにある。
インターフェースを使わなくても、型チェックはガチガチに働くわけで。
普通の人がインターフェースと聞くと、ポリモの話かと考える。
なのにお前は型チェックのことを言い出すから、アホかと思われる。

359 ：デフォルトの名無しさん：2011/07/15(金) 01:14:09.94

>>352
権力が強い企業が担当していた箇所が仕様と違ってた場合、
仕様と合致していても弱い企業が泥臭いコードで直して吸収しなければならない
社会の常識

360 ：デフォルトの名無しさん：2011/07/15(金) 01:16:12.57

>>359
インターフェースの仕様変更が飛んでくるのとなんら変わらない。

361 ：デフォルトの名無しさん：2011/07/15(金) 01:26:23.06

　話を戻そう。理想上オブジェクトは他のオブジェクトの事は、
知らないなら、知らないほど良い。但し粒度は細くしすぎずに。
(整数型一個とかまで小さくしないって事ね)

362 ：デフォルトの名無しさん：2011/07/15(金) 01:52:42.87

>>361
賛成。その話題が本筋だわな。

だけどその理想のオブジェクトとやらを考えたとき、
自分のことだけを考えるってことだから、
メソッドがセッターとゲッターだけになっちゃわない？

また、他のオブジェクトの事を知らないで、どうやって他のオブジェクトと連携していくの？
あるいは、ダックタイピングなら、他のことをまったく知らなくても他と連携できるけど、
ほとんどの静的型言語で、動的なダックタイピングは認められていないよね。

基底クラスやインターフェースって本当に必要？
規約にはなるけど、その分結合度が上がって可搬性が落ちるよ。
そこはトレードオフなんだろうけど、C++やJavaでは動的なダックタイピングが出来ないから、
初めから選択権が無かったりするけど、それってどうなの。

363 ：デフォルトの名無しさん：2011/07/15(金) 05:28:30.88

FWみたいな一方的に上から下に押し付けるタイプのものには向いてると思う
横同士がうまく連携できるかどうかはクラスどうこう以前の話だと思う

364 ：デフォルトの名無しさん：2011/07/15(金) 06:00:13.05

>>362
クラスの実装は知らなくても良いように、インターフェースを使うんだろ

自分のことしか考えないからこそgetter,setterは減る
他のクラスからgetしてsetしてる時点で自分のフィールドに対する一連の処理を呼び出しもとのクラスに任せちゃってる
そうじゃなくてその一連の処理を自分のメソッドとして実装すればいい
こうするとこにより呼び出しもとのクラスはgetしていた内部のフィールドを意識する必要はなくなる
次にそのメソッドをインターフェースとして公開することにより、メソッドの実装も知る必要がなくなる。更に言うとどのクラスであるかさえ意識する必要がなくなる（生成はまた別に必要）

君はAPIを使うとき関連するすべてのクラスの実装を確認してるの？

オブジェクト指向の原則というかインターフェースの使い方を知らない人がちらほらいるな

365 ：デフォルトの名無しさん：2011/07/15(金) 06:03:26.80

>>362
まあ、後から出来たもんだからねｗ
継承やインターフェースなんて言い出してオブジェクト指向に入れちゃった人はなに考えてたんだろうね？
こういうよく考えると「あれ？」っての多いんだよ＞オブジェクト指向

366 ：デフォルトの名無しさん：2011/07/15(金) 06:05:35.61

setter getterは馬鹿が使う実装
オブジェクト同士でなんのイベントもないのにデータの受け渡しが行われることはありえない
なのにsetter getterで穴をあけている

367 ：デフォルトの名無しさん：2011/07/15(金) 06:13:15.89

>>362
知る知らないの視点が違う
重要なのはそのインターフェースを利用する人がクラスの内部実装などを知る必要がないことであって、基底クラスから派生するクラスを実装している人は、規約としてインターフェースを実装すると決めておくことは必要
派生クラス同士に結合関係はないのだから結合度が上がるなんてことはない

368 ：デフォルトの名無しさん：2011/07/15(金) 06:16:44.61

意味ねぇよなぁ・・・＞インターフェース
だって大抵全部ひっくるめて修正しなきゃいけないのに使う側って・・・自分なんですけお！ｗ

369 ：デフォルトの名無しさん：2011/07/15(金) 06:29:37.71

>>368
それが他人か自分かなんて関係ない
新たに派生クラスが増えたときに基底クラスやインターフェースがあることにより、呼び出し元の変更がなくなる（生成の変更だけで済む）
呼び出してるクラス全部変更なんてやりたくない

インターフェースがそもそも変わるっていうのは、基底クラスがあるないとか関係なく設計が悪い

370 ：デフォルトの名無しさん：2011/07/15(金) 06:31:29.79

>>369
なくなるなんてことねぇよ
そっちのがなにかおかしいんだよ

371 ：デフォルトの名無しさん：2011/07/15(金) 06:38:18.60

勝手にインターフェースの仕様変更がない限りとか自分で妄想してんだろ
でもまわりのオブジェクトの都合でそんなもんいくらだって起きるんだよね

372 ：デフォルトの名無しさん：2011/07/15(金) 06:46:04.10

だからインターフェースの変更がある場合は、基底クラスやインターフェースを使ってもその問題は解決できないと認めてるだろw
そこに変更がないなら便利ですよという話
そのことにメリットを感じられないならしょうがない

373 ：デフォルトの名無しさん：2011/07/15(金) 07:13:51.33

>>339
それは終わった公式
新しい公式は部分型をチェックする
つまり継承関係を宣言できないと不利になるぞ

374 ：デフォルトの名無しさん：2011/07/15(金) 07:48:52.70

>>372
だからやくたたないのは確定してんだから妙な条件つけて頑張らなくていいんだよ
馬鹿は頭が固いな

375 ：デフォルトの名無しさん：2011/07/15(金) 12:24:10.56

インターフェースを否定している人はJavaみたいなオブジェクト指向言語に否定的な人？

376 ：デフォルトの名無しさん：2011/07/15(金) 12:28:57.75

インターフェースってプラグイン御用達のやつ？　ビルドアップスタイルアプリケーションでは使うかも・・・

377 ：デフォルトの名無しさん：2011/07/15(金) 16:46:57.97

理解できてないからか具体的にどこが使えないかの意見が一切ないな
困ったら人格否定

378 ：デフォルトの名無しさん：2011/07/15(金) 17:59:57.55

>>377
引数の増減とオブジェクト指向に一体どんな関係があってこんな縛りが役のたつと思っているのか知りたい

379 ：デフォルトの名無しさん：2011/07/15(金) 18:02:39.81

そんなこと言ってるとIDEさんが来るぞ、いでさんが

380 ：デフォルトの名無しさん：2011/07/15(金) 18:05:06.63

あるメソッドが正しく呼び出せるためには、
呼び出されると想定されるオブジェクト側のメソッド名や引数などが、
正しく合致しないといけない

それがどのように合致しているかを、プログラム中に明示しなくてはいけないのが、
Javaのインターフェイス宣言で、
自動的に型推論してコンパイル時に合致しているかをチェックしてくれるOcamlのような言語もあるし、
実行時に呼び出しを解決するPythonのようなスクリプト言語もある

それぞれ、バグの見つけやすさやデバッグ方法や記述の簡単さなどの点で一長一短あって、
どれがいいという確実な答えはない

381 ：デフォルトの名無しさん：2011/07/15(金) 18:35:51.23

IDEの発動

382 ：デフォルトの名無しさん：2011/07/15(金) 21:07:03.69

こんなインターフェースなんて作った奴間違いなく馬鹿なのにさ
誰か入れる前に精査して止める奴いねーの？

383 ：デフォルトの名無しさん：2011/07/15(金) 21:08:04.53

動的言語の欠点は
インターフェースの変更に弱い所だな。

アジャイルな開発では
インターフェースが変わることはよくあること。

ウォーターフローのように最初に設計がバッチリできて
もう変わりませんよというならば動的言語でもいいが。

384 ：デフォルトの名無しさん：2011/07/15(金) 21:16:59.93

>>383
ていうかインターフェースなんて誰も管理する気ねーからわざわざワンクッションおくなよ
面倒くせーな
変えたら呼び出し元で堂々とエラーだせ
そのときに大音量で「かーわーりーまーしーたーよー！」ってＰＣから超でかい音でも鳴らしとけ

385 ：デフォルトの名無しさん：2011/07/15(金) 21:18:15.08

このように、大音量で鳴らす必要がないのが
インターフェースのいいところ。

386 ：デフォルトの名無しさん：2011/07/15(金) 21:22:06.80

仕様変更で機能を追加したくなって
関数/メソッドに引数を追加するとき、
いわゆるJavaのようなインターフェースがあるよりも、
キーワード引数とデフォルト引数がある方が便利に感じる

387 ：デフォルトの名無しさん：2011/07/15(金) 21:22:30.31

>>385
はぁ？てかそれが利点だと思ってる時点でレベル低い
あんたの呼び出してたunko()はもうお前の知ってるunko()じゃないんだよ
って変わったなら変わったことを伝えるのがたしなみだろ
なんで気がつかないようにするんだよ
堂々と大本営発表しろよ
はじめて実行するときはメッセージボックス出して「ＯＫ」を５連発しないと先へ進めないようにしてもいいぐらいだ

388 ：デフォルトの名無しさん：2011/07/15(金) 21:24:23.26

インターフェースが変わったとき
プログラムを修正しないといけないと思ってるだろ？

動的言語ならプログラムを修正しなくても良い。
あまり使われない機能は後回しにすることができる。

使われない機能が一度も実行されないのであれば
なおす時間の無駄だ。
バグは表面化してから対応すれば良い。

389 ：デフォルトの名無しさん：2011/07/15(金) 21:26:41.64

>>387
変わったことを伝えるというのなら
インターフェースのほうがいいだろ。

100%伝えることができる。

もし伝える相手が休みだったら、
離席していたら、聞こえていなかったら、
どうする？

390 ：デフォルトの名無しさん：2011/07/15(金) 21:56:10.09

>>383 >>384 >>385 >>387 >>388 >>389

これらの書き込みと文体から漂う土方臭がすげぇ
これってJava土方の自作自演だろ
さしずめタイトルは「動的言語厨はアホばかり」か？

391 ：デフォルトの名無しさん：2011/07/15(金) 22:03:03.34

COMしかりJavaしかり .netしかりインターフェースの変更は禁忌だと思うが、
インターフェースを変更してるやつは、どういう具体的ケースで変更してるんだろ。
普通に考えて、一度プログラム内で動作しはじめたインターフェースを変更する事は無いと思うけど。

392 ：デフォルトの名無しさん：2011/07/15(金) 22:04:29.77

経験ないやつは無敵だな

393 ：デフォルトの名無しさん：2011/07/15(金) 22:25:32.00

>>390
お前は人をばかにすることしかできんのだな
人間のクズだ。

394 ：デフォルトの名無しさん：2011/07/15(金) 22:27:56.56

デザイナーがちゃんと設計してくれないから

395 ：デフォルトの名無しさん：2011/07/15(金) 22:29:31.19

修正しないのなら、
保守性も拡張性もいらないはずだよね。

396 ：デフォルトの名無しさん：2011/07/15(金) 22:32:45.79

オブジェクト指向の保守性拡張性は、
既存のコードを書き換えない事で成り立ってると思うけど？
DirectXなんかがいい例じゃん。

397 ：デフォルトの名無しさん：2011/07/15(金) 22:33:26.73

>>395
何言ってんだこいつ？

398 ：デフォルトの名無しさん：2011/07/15(金) 22:35:53.43

>>391
そんなわけねぇじゃん
変更しまくりだよ
だから邪魔だっての＞インターフェース
だいたいなんで作ったの？アフォなの？死ぬの？誰にどう使わせたいの？
ってインターフェースばっかり量産してんじゃん

ライブラリ開発者でもないのにこんなのいらねぇよ
分をわきまえろよ
お前等雑魚がこんなもんこさえる必要はこれっぽっちもないからｗ

399 ：デフォルトの名無しさん：2011/07/15(金) 22:36:03.25

ほら、IDEさんが来ちゃった

400 ：デフォルトの名無しさん：2011/07/15(金) 22:37:55.17

>>399
なんだ？ＩＤＥさんって
そうやって特定のだれかだと決め付けるお前の精神疾患に付き合ってる暇はないんだけどな

401 ：デフォルトの名無しさん：2011/07/15(金) 22:41:30.11

一度議論に負けた相手を執拗に覚えておくこの板の住人特有の病気らしいよ
やねうらおとその配下にいる奴等の戦いがおもしろかったらしい

402 ：デフォルトの名無しさん：2011/07/15(金) 22:42:19.10

>>398
だから具体例を教えてよ。
まさか下駄と雪駄だらけのクソインターフェースじゃないよね。

403 ：デフォルトの名無しさん：2011/07/15(金) 22:43:48.67

>>400
IDEさんとは、IDEでインターフェースを修正することが
プログラミングにおいて主要な位置を占めると考えるプログラマの総称である。
典型的には Java + Eclipse ユーザであり、
日々どこからも呼ばれない無用なモジュールを
リファクタリングし続ける仕事をこなす。
土方のなかの土方、土方エリートである。

404 ：デフォルトの名無しさん：2011/07/15(金) 22:51:23.12

土方にそんな仕事あるのか

405 ：デフォルトの名無しさん：2011/07/15(金) 23:07:07.03

>日々どこからも呼ばれない無用なモジュールをリファクタリングし続ける
俺もそういう仕事がしたい

406 ：デフォルトの名無しさん：2011/07/15(金) 23:22:42.02

まだインターフェース変更の具体例がでてこないなぁ～。

言語機能のインターフェースを書き換えていい場合って、
帰納型抽出の場合だけだよね。
※帰納ってのは専門語じゃなくて一般的な帰納の意味ね。

407 ：デフォルトの名無しさん：2011/07/15(金) 23:24:26.35

汚い言葉使ってるやつはわかりやすいな

408 ：406：2011/07/15(金) 23:25:25.07

まあ、Objective-Cみたいなダックタイプの効く言語なら
帰納抽出なんて必要ないんだけどね。

409 ：デフォルトの名無しさん：2011/07/15(金) 23:34:36.92

動的言語ｗ

410 ：デフォルトの名無しさん：2011/07/15(金) 23:36:39.39

>>409
型安全語りたいならよそでやれよ。

411 ：デフォルトの名無しさん：2011/07/15(金) 23:40:48.33

言語上のインターフェースはともかく、
OOPの意味でのインターフェースって全然
型安全とか関係ないよなぁ。
純粋なインターフェース(メッセージング)について
話をしてる時に型安全じゃないとか話を振出すやつは何なんだろうね。

412 ：デフォルトの名無しさん：2011/07/15(金) 23:43:55.12

OOPLはC++でブレイクしたのであって

413 ：デフォルトの名無しさん：2011/07/15(金) 23:51:12.75

>>412
　当時の大半のプログラマーは、便利なC程度の認識しかなかっただろうけどね。
マジメにOOやってたOpen Window Libraryが負けて、MFCというクソライブラリが
普及したのが何よりの証拠。

414 ：413：2011/07/15(金) 23:57:24.05

ボケて書き間違えた Open Window LibraryじゃなくてObject Window Libraryな。

415 ：デフォルトの名無しさん：2011/07/16(土) 00:21:32.77

>>411
ほんとそうだよな
理解しているならインターフェースから型安全の話は出てこないはずなんだが

416 ：デフォルトの名無しさん：2011/07/16(土) 00:40:28.06

その後出てきたのもJavaなんだが

417 ：デフォルトの名無しさん：2011/07/16(土) 00:52:38.22

バベル案内(http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm)には

> ゴスリングでさえ、何年か前、すべて始めからやり直すとしたら、
> インタフェースは使わないだろうと言っていた。

って書いてあるけど、ホント？

418 ：デフォルトの名無しさん：2011/07/16(土) 00:57:32.90

>>416
Javaは一度死んだろ。当時、JavaがOOPLである事にメリットを感じているヤツは居なかった。
今もJava使ってるヤツの大半はそうだ。ライブラリとVM環境の支援が欲しいだけ。
客先のシステム覗いたら哲学もストラテジーも微塵も感じないコードがゴロゴロしてる。

419 ：デフォルトの名無しさん：2011/07/16(土) 01:00:28.21

>>417
やるとしたらGoのinterfaceやGCCのsignature形式を
とるだろうよ。interfaceを直接型に結びつけるなんて馬鹿げてる。

420 ：デフォルトの名無しさん：2011/07/16(土) 01:18:32.53

そういや上の方でプログラマーに実装が解ることが悪いことだ見たいな事が
書いてあったが、アレっておかしいよな。
実装を隠すのは人間に対してじゃなく、オブジェクトに対して隠せっていってるのに
履き違えている。オブジェクトは他のオブジェクトの実装はメッセージの仕様以外
知っててはいけない。なぜなら、オブジェクト同士が切り離せなくなるからだ。
だから、プログラミング言語はその法則を維持するためにアクセス指定子を
持っていたりするわけだ。決して人から見た理解のためじゃない。

そもそも、オブジェクト指向でプログラムすれば現実に近くて分かりやすいって
考え方してんのもおかしい。

421 ：デフォルトの名無しさん：2011/07/16(土) 01:25:25.43

>>418
おまえは何でも曲解するんだな

422 ：デフォルトの名無しさん：2011/07/16(土) 07:14:43.76

>>420
いや、でもやっぱり使い手が実装みないといけないのはおかしいよ

423 ：デフォルトの名無しさん：2011/07/16(土) 08:05:25.24

>>398
> そんなわけねぇじゃん
> 変更しまくりだよ
> だから邪魔だっての＞インターフェース

一度決めたインターフェースは
変更するものではない。

それは言語機能として
インターフェースがなかったとしても同じこと。

424 ：デフォルトの名無しさん：2011/07/16(土) 08:25:46.07

>>423
データが必要になったらどーすんだよ？
てめぇの脳内にある前提がまったくわからないから話にならないな
説明しようともしないし

425 ：デフォルトの名無しさん：2011/07/16(土) 09:09:42.36

>>424
新しいバージョンとして作るんだよ

426 ：デフォルトの名無しさん：2011/07/16(土) 09:14:15.43

>>425
ただの変更とかわんねぇじゃん

427 ：デフォルトの名無しさん：2011/07/16(土) 09:37:42.75

変更しまくりなら、尚更インターフェースがあったほうがいいよな。

動的言語みたいに、一部だけ変えられるものは、
結局変更漏れができてしまう。

インターフェースがあれば、一箇所定義を変えると
変更すべき箇所を教えてくれるから、変更漏れがない。

428 ：デフォルトの名無しさん：2011/07/16(土) 09:40:01.13

XPとか通ってきてないんだろうな

429 ：デフォルトの名無しさん：2011/07/16(土) 09:40:58.92

他の部分でバグが発生したとしても、とりあえず今やってるとこだけは変更できる。→変更しやすい
変更するならバグがないように、全部変えないといけない→変更しにくい

こういう発想なんだろうな・・・

430 ：デフォルトの名無しさん：2011/07/16(土) 09:42:08.41

テストして必要箇所全部修正するのなら、どっちみち面倒なわけで、
インターフェース使っても特に面倒さが増えるってことには
ならないと思うが、

431 ：デフォルトの名無しさん：2011/07/16(土) 09:54:35.29

このレベルか・・・

432 ：デフォルトの名無しさん：2011/07/16(土) 12:17:37.31

さっきから文句言ってるやつはインターフェースでどうやってコーディングするのかわかってるのか不安だ

433 ：デフォルトの名無しさん：2011/07/16(土) 14:51:01.96

>>424
こういうバージョン別の拡張じゃだめなんだろ。
具体的に。
namespace Version1
{
struct Interface;
}
namespace Version2
{
struct Interface;
}

434 ：デフォルトの名無しさん：2011/07/16(土) 17:15:48.38

インターフェースってCOMから出てたんじゃないっけ？　まっ　現在では意味合いが広くなり過ぎたけど
アダプターやデコレーターがあるぐらいだから　OOPはベースを改変しないのが基本なんだが．．．

435 ：デフォルトの名無しさん：2011/07/16(土) 18:08:16.42

>>434
やっぱり、そのレベルだったかｗ

こんなやつがインターフェースに文句言ってるんだろうな。

436 ：デフォルトの名無しさん：2011/07/16(土) 18:17:58.98

変数を定義してから使うとバグが減る。
インターフェースも定義してから使うとバグが減る。

変数もインターフェースも
必要に応じて変えても良い。

437 ：デフォルトの名無しさん：2011/07/16(土) 20:03:17.57

言語レベルインターフェース野郎は帰れよ。
OOレベルのインターフェースの話をしててもお前等のせいで、
型安全とか程度の低い話になる。

438 ：デフォルトの名無しさん：2011/07/16(土) 20:23:32.56

Windowクラスが、他のButtonとか複数持ってる作りって、あるいみ変だよな。
WindowとButtonの関係って親と子ではあるけど、オブジェクトレベルでは単なるトポロジーの一部じゃん。
WindowはButtonの事を一切知ってる必要もないし、Buttonは、1つのWindowに
所属しておかなきゃならない義理もない。だからと言って複数のWindowに所属させる用途も
あんまり無いんだけどね。ただ、Windowから他のWindowに画像領域を移動させたりするときは
障害が如実になるよね。

439 ：デフォルトの名無しさん：2011/07/16(土) 21:16:57.52

>>437
具体的にOOレベルのインターフェースって何？

440 ：デフォルトの名無しさん：2011/07/16(土) 21:22:16.58

>>439
メッセージに指定するオブジェクトの要件の事。
言語レベルで用意されているinterfaceやprotocol、signatureに囚われない話。

441 ：デフォルトの名無しさん：2011/07/16(土) 21:30:56.85

>>440
なるほど
どこらへんでその話してるの？

442 ：デフォルトの名無しさん：2011/07/16(土) 21:45:59.53

OOレベルのインターフェースなんてあるわけ無いだろ。
インターフェースは所詮実装上の決まり。

変数の定義と同じでOOの思考実験において
インターフェースは存在しない。

443 ：デフォルトの名無しさん：2011/07/16(土) 21:49:41.28

>>441
メッセージの話がでてるあたり。
そこからインターフェースを言語レベルでしか語れないヤツらが出てきて
更に型安全厨が登場し、下らない話になってる。

444 ：デフォルトの名無しさん：2011/07/16(土) 21:51:03.22

>>442
言語とかコンピューターの世界じゃなく、純粋な意味でのインターフェースを考えてみろよ。

445 ：デフォルトの名無しさん：2011/07/16(土) 21:53:08.74

実装もまたオブジェクト指向だよ。
オブジェクト指向をどうやって実装するか。

システムが大きくなればなるほど、
それを制御する技術も必要。

型安全、いや安全プログラミングを
考えないやつは、所詮机上の空論で終わってる。

空論を技術に転用するのも重要な話。

446 ：デフォルトの名無しさん：2011/07/16(土) 21:54:19.27

>>444
ないよそんなもん。

理論としてのオブジェクトはどんなメッセージも受け付けるんだから。
あとはそのメッセージに反応するかしないかでしかない。

447 ：デフォルトの名無しさん：2011/07/16(土) 21:54:42.54

>>442
OOにインターフェースが定義されてる訳じゃなくて、
演繹的に見てインターフェースと呼べる部分があり、
そこの事をメッセージと言っている皆はインターフェースと読んでるだけ。
瓶の口といっても、瓶に物を食べる口はないだろ、口に見えるから口と
いってるだけそれと同じ。

448 ：デフォルトの名無しさん：2011/07/16(土) 21:55:41.86

>>445
じゃあどっかの言語スレでやれよ。
話の程度が低くなる。

449 ：デフォルトの名無しさん：2011/07/16(土) 21:57:42.33

>>445
そういう話をしだすと、そっちに話が流れて
トポロジー的な側面の話やメッセージの話ができなくなるんだよ。
勘弁してくれ。

450 ：デフォルトの名無しさん：2011/07/16(土) 21:58:18.54

> 瓶の口といっても、瓶に物を食べる口はないだろ、口に見えるから口と
> いってるだけそれと同じ。
え？なに？言葉遊びを始めたいの？
物や人の出入りする所を口というんだけど。

451 ：デフォルトの名無しさん：2011/07/16(土) 21:59:25.71

>>447
じゃあインターフェースではないものはなんというんだよ。

452 ：デフォルトの名無しさん：2011/07/16(土) 21:59:51.19

>>450
揚げ足取りでレスを伸ばすなよ。
気に入らないなら無視しろ。

453 ：デフォルトの名無しさん：2011/07/16(土) 22:01:12.51

>>451 話がつながってなくて何が言いたいのか解からん。

454 ：デフォルトの名無しさん：2011/07/16(土) 22:04:32.74

>>446
"どんなメッセージも"って事は、メッセージに種類があるんだろ。
OOにインターフェースがあります。って書いてなくても、
メッセージの種類が存在してるってのは書いてあることじゃん。
種類がそんざいして情報のやりとりがあるってことは、
インターフェースそのものじゃん。

455 ：デフォルトの名無しさん：2011/07/16(土) 22:10:16.00

つーかオブジェクト指向の話をすれば、
オブジェクトとメッセージしか残らないわけで
もういまさら話すことは何も無いと思うけどね。

ダックタイピングとかMIX-INとかそういうのも
オブジェクトを構築するための実装の話でしかないし。

456 ：デフォルトの名無しさん：2011/07/16(土) 22:12:44.46

>>454
> "どんなメッセージも"って事は、メッセージに種類があるんだろ。

種類？メッセージはメッセージだよ。
Aというメッセージ、Bというメッセージ、Cというメッセージ。
メッセージはそれぞれ個別であり対等のものだ

実装の段階においては、それじゃ区別付けにくいので
グループ分けするけど、これは実装の話。

457 ：デフォルトの名無しさん：2011/07/16(土) 22:19:09.22

>>456
ちょっと面白い話だな。メッセージを受け取っても何もしないという振る舞いができる。
だから、受け取れないメッセージはないし、ある種のメッセージを受け取れるという定義は存在しないって事か。
でも、メッセージ毎に構造はあるでしょ。それもひとつに統合できちゃうの？

458 ：デフォルトの名無しさん：2011/07/16(土) 22:26:39.79

インターフェースってスタックモデルでアブストラクトクラスってヒープモデルでなかったっけ？

459 ：デフォルトの名無しさん：2011/07/16(土) 22:27:55.45

>>456
なんか造詣がありそうなんで聞いてみよう。
オブジェクト同士のメッセージのやりとりを上から俯瞰すると
一種のトポロジーが見えてるじゃん。数学面じゃなく
ネットワーク方面で言ってみると、バス型やハブ型、リング型等々。
現実他人が書いてるコード見るとトポロジーの構造が偏ってると思わない？
適切じゃない部分でも同じ構造ばっかり使ってるとか。

460 ：デフォルトの名無しさん：2011/07/16(土) 22:30:12.76

>>457
> でも、メッセージ毎に構造はあるでしょ。それもひとつに統合できちゃうの？
だからそれは実装の話。

461 ：デフォルトの名無しさん：2011/07/16(土) 22:31:53.36

>>459
> 現実他人が書いてるコード見るとトポロジーの構造が偏ってると思わない？

うん、だから実装の話ね。

実装の話は、

　　　　　　ﾊ,,ﾊ
　　　　　（ﾟωﾟ )　　お断りします
　　　　／　　　＼
　 ((⊂ 　）　ﾉ＼つ))
　　　　　（＿⌒ヽ
　　　　　　ヽ　ﾍ　}
　ε≡Ξ　ﾉノ｀J

462 ：デフォルトの名無しさん：2011/07/16(土) 22:32:16.93

OOって現実を映しだすっていうより、ネットワーク構造を反映しやすいって言ったほうが向いてるよな。
まぁ、由来もその辺だし。

463 ：デフォルトの名無しさん：2011/07/16(土) 22:33:16.73

>>461
そこまで概念を抽象化すると話のネタが無くなるだろ。

464 ：デフォルトの名無しさん：2011/07/16(土) 22:35:46.52

実装の話をしないならば、
カプセル化の話もできない。（実装を隠す物）
継承も結局はオブジェクトを構築するための手段にすぎない。つまり実装。

オブジェクトを構築するやり方が色いろあるってだけだからな。
実行前に構築してしまうやり方、実行時に構築するやり方、
他のオブジェクトを取り入れて構築するやり方。
どれも実装の話になっちゃう。

クラス、インスタンス、プロトタイプベース。
これらもオブジェクトを何をもとに生成するかって話に過ぎないし。

さて一体なんの話をすればいいのやら。

465 ：デフォルトの名無しさん：2011/07/16(土) 22:36:00.85

>>461
処理や言語の話が出てないんだから実装の話ではないだろ。

466 ：デフォルトの名無しさん：2011/07/16(土) 22:37:08.50

>>464
メッセージネットワーク。
もともとオブジェクト指向の命題だし。

467 ：デフォルトの名無しさん：2011/07/16(土) 22:38:21.46

>>464
本当にその辺の話はどうでもいいよ。
そんなん言語スレとか初心者おいでませ系のスレで語ってりゃいいし。

468 ：デフォルトの名無しさん：2011/07/16(土) 22:38:57.52

>>466
"メッセージネットワーク"でぐぐったけど、

・・・メッセージ、ネットワーク・・・

みたいなのしか引っかからないよｗ

469 ：デフォルトの名無しさん：2011/07/16(土) 22:41:26.68

オブジェクト指向のメッセージを
メソッド呼び出し以外で実装した言語は
何かありますか？

470 ：デフォルトの名無しさん：2011/07/16(土) 22:44:54.20

>>468
固有名詞じゃないよ。
[smalltalk メッセージネットワーク]
とか
[オブジェクト指向メッセージ　ネットワーク]
でぐぐればそこそこ出てくるだろ。
まぁぐぐれってもどうのとか言うだったら話にならんかもしれないけど。

471 ：デフォルトの名無しさん：2011/07/16(土) 23:05:30.07

>>468
ある程度調べれば、オブジェクト指向の基礎は群体の相互作用だって話が見つかるでしょ。
群体の相互関係をネットワークだのトポロジーだと言ってるだけ。

472 ：デフォルトの名無しさん：2011/07/16(土) 23:11:25.66

>>471
それで？

473 ：デフォルトの名無しさん：2011/07/16(土) 23:16:14.59

>>472
反応の仕方がおかしい。

474 ：デフォルトの名無しさん：2011/07/16(土) 23:19:43.77

>>473
だからオブジェクト指向はネットワークだ！でそれでなんなのさ。

475 ：デフォルトの名無しさん：2011/07/16(土) 23:27:39.12

>>474
ある種の問題に対してどういうネットワーク構造の組み合わせやデザインが汎用的で、
独立性が高くなるだのあるだろ。
まぁ、それを言い出すとOO設計の話になるからスレ違いか。

476 ：デフォルトの名無しさん：2011/07/16(土) 23:32:08.33

>>474
単に煽るだけなら、OOは入れ子構造の発展だの、
getter,setterがどうのいってる連中は的がズレてるって事だけど。

477 ：デフォルトの名無しさん：2011/07/16(土) 23:35:29.49

>>476
で、ネットワークだで話が終わりでしょ。

だからこのスレはお前の言う違う話に
焦点がうつってしまうわけなんだが。

478 ：デフォルトの名無しさん：2011/07/16(土) 23:40:04.61

そうだな。てかこのスレタイで話引っ張ってもそっちにいくだけだもんな。
このスレに書いてるだけ無駄か。

479 ：デフォルトの名無しさん：2011/07/17(日) 00:12:43.16

オブジェクト指向には、OOP,OOD,OOAがあるんだから実装の話をしたって問題ないと思うけど
概念的な話もしてくれてもいいと思うけど、結局はどう実装や設計にその概念が反映されているかが重要だと思うから、実装しかわからない人間のためにそこまで説明して欲しい

480 ：デフォルトの名無しさん：2011/07/17(日) 00:15:42.29

>>475
元々OOを実装した言語の話をするなって言ってたんだから
別に設計はよくね。

481 ：デフォルトの名無しさん：2011/07/17(日) 00:16:30.66

概念自体は単純で語るほどのものはない。
だからこの手のスレは、それはOOPであってOOではない。
という話に終始する。OOではないというだけで
じゃあOOという話は？となると何も出てこない。

何も出てこないとOOPの話になる。
そしたらまたOOではないと言いに来る。
この繰り返し。

実際のところOOP以外のOOはあまり役に立たない。

482 ：デフォルトの名無しさん：2011/07/17(日) 00:19:17.09

>>479
例えばあれか、コンストラクターで生成されたオブジェクトが
そのオブジェクトを持ってるオブジェクトの寿命まで固定されてんのは、
設計としてあんまり良くないとかか。

483 ：デフォルトの名無しさん：2011/07/17(日) 00:20:22.74

>>480
設計ってどの言語で実装するかによって変わると思うけど

>>481
その通りだな
ネットワークくんもそれ以上の話をしてくれないし

484 ：デフォルトの名無しさん：2011/07/17(日) 00:22:42.22

>>482
それって単にOOPの話してるだけじゃないの
その話の中でOOの本質的な概念とはどこ？

485 ：デフォルトの名無しさん：2011/07/17(日) 00:24:36.46

>>483
BASICじゃクイックソートはできないとかか？
アルゴリズムとおんなじで言語には依存しないだろ。
それじゃUMLも書けんだろ。

486 ：デフォルトの名無しさん：2011/07/17(日) 00:25:51.66

>>484
じゃ命題のトポロジーの話でもするか。
OOに同適用するとか。(メッセージでどう繋ぐとか)

487 ：デフォルトの名無しさん：2011/07/17(日) 00:27:01.32

>>486
どうぞ。さっそく話してくれ。

488 ：デフォルトの名無しさん：2011/07/17(日) 00:28:11.36

>>484
群体の話でもしたらいいんじゃない？
数学とか物理とか社会学とかプログラムから離れられるぞ。

489 ：デフォルトの名無しさん：2011/07/17(日) 00:29:30.94

群体の話ではなく、OOの話をしてくれ。

490 ：デフォルトの名無しさん：2011/07/17(日) 00:31:17.75

>>489
いやOO自体群体ベースなんだから群体でも構わんだろ。
群体の話なくなったらOO自体なくなるだろ。

491 ：デフォルトの名無しさん：2011/07/17(日) 00:33:56.75

>>490
そういう決めつけだけではなくて具体的にそれがどういうことかを説明してくれよ
OOPの話を否定するならそこまでしっかりしてくれ

492 ：デフォルトの名無しさん：2011/07/17(日) 00:36:04.08

>>486
当たり前だけどトポロジーというのはオブジェクト指向に限った話ではないよね
オブジェクト指向のトポロジーというのはどういうことを指すの？

493 ：デフォルトの名無しさん：2011/07/17(日) 00:43:50.86

結局オブジェクト指向って何を解決させるものかさっぱりわからないや
仕様が減るわけじゃないもんね

494 ：デフォルトの名無しさん：2011/07/17(日) 00:44:04.50

>>492
オブジェクトの繋がりにトポロジーを適応できるという話でしょ。
現実問題オブジェクトの中にオブジェクトが滞留してるってのはよくある。
できるだけオブジェクトの中にオブジェクトが滞留するのは避けるべきだ。
基本的に、他のメッセージを送った結果としてオブジェクトを得られないのであれば
設計を見なおしたほうがいいかもしれん。

495 ：デフォルトの名無しさん：2011/07/17(日) 00:46:40.13

×他のメッセージ
○他のオブジェクト

496 ：デフォルトの名無しさん：2011/07/17(日) 00:47:20.14

さっさとOOの話しろよ。

497 ：494：2011/07/17(日) 00:47:52.04

また間違えた、
他のオブジェクトにメッセージを送った結果だった。

498 ：デフォルトの名無しさん：2011/07/17(日) 00:49:32.58

>>496
してんじゃん。

499 ：デフォルトの名無しさん：2011/07/17(日) 00:50:33.65

> できるだけオブジェクトの中にオブジェクトが滞留するのは避けるべきだ。

それはなぜか、

その理由は語られないのであった。

500 ：デフォルトの名無しさん：2011/07/17(日) 00:53:16.46

>>494
滞留ってどういうこと？
オブジェクトにメッセージを送ってオブジェクトを得るっていうのは、実装レベルでいうとメソッド実行して返り値としてオブジェクトを得るということ？

501 ：デフォルトの名無しさん：2011/07/17(日) 00:55:55.18

実際問題、オブジェクトの中にオブジェクトが滞留ってありえるのかねぇ
どうせオブジェクトなんて、メソッド持ったデータなんだから
メソッド呼び出しと共に、他のオブジェクトにデータが渡るだろ。

502 ：デフォルトの名無しさん：2011/07/17(日) 00:57:02.80

OOが群体とか、頭おかしいだろ。他の、例えばC言語だって群体といや群体だろ。なんとでもいえるw

そうじゃない。
オブジェクト指向ってのは、オブジェクトに指向しろってことだ。
プログラムには色々な要素があるけど、それらのうちのオブジェクトに指向するのがオブジェクト指向だ。
C言語では、関数の引数が関数に対するオブジェクトで、それは大概が構造体だったから、
構造体に指向するってことになって、C++では構造体がクラスになった。

OOの最大の問題は、本当にオブジェクトに指向して良かったのかどうか。
OOではもはや関数はオブジェクトの一部で、オブジェクトにぶら下がる。
プログラムの動作や性質は、オブジェクト次第となる。
そんなのは本当に正しいのかねぇ。

503 ：デフォルトの名無しさん：2011/07/17(日) 01:02:52.28

>>499
簡単じゃん。
固定されてるって事は、固定しているオブジェクトを知っていると同義。
固定されてるオブジェクトはネットワークの構成要素として本来メッセージで得られるもの。

504 ：デフォルトの名無しさん：2011/07/17(日) 01:03:31.79

>>503
固定ってどういうこと？

505 ：デフォルトの名無しさん：2011/07/17(日) 01:03:55.53

>>502
えっ？Cのどこが？

506 ：デフォルトの名無しさん：2011/07/17(日) 01:05:32.77

これほど中身のない煽り合いも珍しい

507 ：デフォルトの名無しさん：2011/07/17(日) 01:05:54.05

>>504
説明のために実装を引っ張り出すと一つのフィールドを一つのオブジェクトがずっと占拠してること。
メソッドの中で生成されたオブジェクトは固定されてるとは言わない。

508 ：デフォルトの名無しさん：2011/07/17(日) 01:09:54.92

>>502
現実世界で考えると、オブジェクトによって動作が違うのは当たり前だから考えやすいけどね
もし別のオブジェクトに共通の動作を定義したいならその動作をオブジェクトとすればいいし

509 ：デフォルトの名無しさん：2011/07/17(日) 01:10:24.22

>>502
群体ってのが解ってないでしょ。
位相幾何学に出てくる頂点の集合体みたいなもんよ。

510 ：デフォルトの名無しさん：2011/07/17(日) 01:10:29.78

つかおまえらOOっていうときどの辺の本や論文下敷きにしてるの？

511 ：デフォルトの名無しさん：2011/07/17(日) 01:10:45.21

> 一つのフィールドを一つのオブジェクトがずっと占拠してること。

ようするに定数ってことね。

定数を使うなって何のために？
そんなもん使うときに使うし、使わないときは使わない。

当たり前にやっていることだけど、
そんなに難しく言うことか？

512 ：デフォルトの名無しさん：2011/07/17(日) 01:11:55.46

>>510
おれは「オブジェクト指向でなぜつくるのか」

513 ：デフォルトの名無しさん：2011/07/17(日) 01:13:22.98

なんか、オブジェクト指向はこういうモノなんだから
このルールに従わないと駄目だ。といっているだけに聞こえる。

なんのためのルールなのか、その根拠が示されていない。

514 ：デフォルトの名無しさん：2011/07/17(日) 01:16:29.72

>>511
定数とは限らないって。
メッセージ送って状態が変異するオブジェクトも含まれる。

515 ：デフォルトの名無しさん：2011/07/17(日) 01:17:25.63

いいたいことがさっぱり見つからないスレ

516 ：デフォルトの名無しさん：2011/07/17(日) 01:18:56.37

>>514
定数とは限らないというのを聞きたいのではなく、
定数以外のものを聞きたい。

お前はOOPであってOOではないと言ってるのと
同じことを今やってるぞｗ

517 ：デフォルトの名無しさん：2011/07/17(日) 01:19:49.86

>>514
オブジェクトも定数にできるんだが・・・

518 ：デフォルトの名無しさん：2011/07/17(日) 01:20:23.30

論拠は俺！(キリッ
低学歴にもほどがある・・・

519 ：デフォルトの名無しさん：2011/07/17(日) 01:21:35.33

>>507
それを一概に悪いとは言えないと思うけど、オブジェクトが属性を持つなら必要でしょ
上にあるようなそれぞれ違うオブジェクトに共通の動作があるときとか
ただデータが必要だからフィールドに持つというのは良くないと思うけど

520 ：デフォルトの名無しさん：2011/07/17(日) 01:24:15.63

>>516->>517
別の言い方をしよう。
private継承してんのと同じようなオブジェクトの事だ。

521 ：デフォルトの名無しさん：2011/07/17(日) 01:24:46.18

学説や理論がどのように作られてるか知らないんだろうなぁ

522 ：デフォルトの名無しさん：2011/07/17(日) 01:28:37.43

>>521
それを言えて、満足したなら消えてくれ。

523 ：デフォルトの名無しさん：2011/07/17(日) 01:29:19.29

詐欺師と作業員のスレ
研究者や開発者はいない

524 ：デフォルトの名無しさん：2011/07/17(日) 01:29:55.89

>>520
private継承は必要なときは使うし
必要ないときは使わない。

それだけだろ？難しく考えるなｗ

525 ：デフォルトの名無しさん：2011/07/17(日) 01:30:37.24

もっと概念的に言えば、データーフローダイアグラムの途中のシステム要素の中に
オブジェクトが滞留してるということ。

526 ：デフォルトの名無しさん：2011/07/17(日) 01:31:12.76

>>508
現実世界で言うと、動作は複数のオブジェクトの組み合わせで決定することが多い。
つまり、マルチメソッドってことになる。だけどほとんどのまともな言語でマルチメソッドは実装されてない。
しかもマルチメソッドだと、メソッドが単一のオブジェクト(クラス)に紐づいている訳ではないから、
オブジェクト指向かどうかも怪しい。どっちかって言うと、動的なオーバーロードみたくなる。
メソッドの定義もクラスの定義の外に書くことになるしね。

C++のテンプレートなんかはかなり理想的なプログラミング環境だね。
ダックタイピングできて、オーバーロードてポリモしてっていう。
ただしあれは静的なんだよねぇ。
C++のテンプレートはOOが嫌いな人が作ったとかなんとか。

527 ：デフォルトの名無しさん：2011/07/17(日) 01:31:29.20

>>524
だからprivate継承で十分だろそんな要素。

528 ：デフォルトの名無しさん：2011/07/17(日) 01:31:43.65

滞留させるべきものは滞留させるし
そうでないものは滞留させない。

自然に考えればいいだけ。

529 ：デフォルトの名無しさん：2011/07/17(日) 01:34:12.94

決して引用元は示さない
さすがです

530 ：デフォルトの名無しさん：2011/07/17(日) 01:35:02.99

>>527
private継承で十分ならそうするし、
publicにするべきならそうする。

開発経験ないのか？

なんか気分は俺が農業やっていて、そこに学者さんがきて、
○○なときはこうすれば言ってるのを聞いて
「んなもん、あたりまえだぁ。爺ちゃんの代からずーっとそうしてきたべさ」
といっているようなそんな感じだよｗ

531 ：デフォルトの名無しさん：2011/07/17(日) 01:35:19.48

>>528
本当に必要ならね。
滞留しているオブジェクトは振る舞いをやや変えづらい。
例えば賃貸の部屋に30年前の冷蔵庫が固定されていて動かせないのと同じだ。

532 ：デフォルトの名無しさん：2011/07/17(日) 01:37:15.04

> 滞留しているオブジェクトは振る舞いをやや変えづらい。

んなもん、あたりまえだぁ。

振る舞いを変える必要がないから、
滞留させてるんだべさｗ

533 ：デフォルトの名無しさん：2011/07/17(日) 01:37:22.37

>>530
べつにそういう話はしてない。
実装は、概念上の話をしても通じないから引っ張り出しただけだし。
あとpublicかprivateとかは関係ないよ。

534 ：デフォルトの名無しさん：2011/07/17(日) 01:38:16.06

>>532
だから、できるだけっていってんべ。

535 ：デフォルトの名無しさん：2011/07/17(日) 01:40:24.18

>>525
DFDとオブジェクトって設計でいうとまったく別の概念だと思うけど
データの流れを書いただけの物の中に、設計したうえでのオブジェクトが登場するとは限らない
もちろんDFDに現れないオブジェクトもいっぱいある

>>526
複数の動作をフィールドとして持って、組み合わせればいいんじゃないの？
動作の組み合わせとC++のテンプレートって関係あるのかな

536 ：デフォルトの名無しさん：2011/07/17(日) 01:44:48.30

>>529
引用元？総括でコピペじゃないからそんなもん無いよ。
根拠を見たいならここの論文みていきな。
http://scholar.google.co.jp/scholar?q=object+oriented+topology&hl=ja&as_sdt=0&as_vis=1&oi=scholart

537 ：デフォルトの名無しさん：2011/07/17(日) 01:46:24.76

滞留ってのがもう意味不明だけど、要はコンポジションするしないの話でしょ。
コンポジションした方がカプセル化できるし、オブジェクトの生存期間や所有権も明確で分かりやすい。
しかし、他のオブジェクトと共有しなきゃならない場合も有ったりして、
その場合は逐一に引数で渡したり、ポインタ握らせたりする。
だけどそんなもん、C言語でも同じことだよ。OOまったく関係なし。

オブジェクト指向は「オブジェクトに指向する」こと。
関数よりも引数に着目して、処理対象を中心に考えること。
それが本当に正しいかどうかが問題の焦点。

538 ：デフォルトの名無しさん：2011/07/17(日) 01:47:13.96

>>536
つまり引用できないんですねｗ

539 ：デフォルトの名無しさん：2011/07/17(日) 01:48:08.73

>>535
データの流れを表してんのがDFD。
オブジェクトだろうが、APLの行列だろうが関係ない。
DFDはデータの状態を説明すんのに使っただけ

540 ：デフォルトの名無しさん：2011/07/17(日) 01:48:12.86

リファレンスを示せずに議論するって学あるものなら恥ずかしくてできないよね

541 ：デフォルトの名無しさん：2011/07/17(日) 01:56:43.78

>>535
C++関数のオーバーロードは、全ての引数の型の組み合わせで決定される。
いわば静的なマルチメソッド。関数が単一のオブジェクトに属している必要も無い。
一方で、基底クラス使ったポリモは単一ディスパッチしかできない。
メソッドは単一のオブジェクトに属している必要がある。
そんで、その、単一のオブジェクトにメソッドが属するって所から、
基底クラスがどうとかやらインターフェースがどうとかといった
OO独特のドロドロした話が派生している。
マルチメソッドにすれば、何もかも関係なくなる。
別の問題も出てくるけどね。

542 ：デフォルトの名無しさん：2011/07/17(日) 01:58:18.92

>>537
その言い方ならそうね。コンポジションせず集約にしろって言ったほうが直接的か。
>オブジェクト指向は「オブジェクトに指向する」こと。
こっちのほうが意味が解からん。

543 ：デフォルトの名無しさん：2011/07/17(日) 02:00:17.41

マルチメソッドか。くだらんな。

ようは、名前が同じだけど、引数の型で反応が違うってだけだろ？

foo(型、引数）
こうやって型みて、ifで処理を分岐させればいいだけじゃないか。

さらに発展して、型_foo(引数）とすればいいだけじゃないか。

名前が同じことに何の意味がある？

544 ：デフォルトの名無しさん：2011/07/17(日) 02:01:43.60

マルチメソッドと言ってる人は、
メソッドが、クラスやオブジェクトに所属するものだというオブジェクト指向を否定しているの？
それとも、特定のメソッドが、複数クラスやオブジェクトで割り当てされるマルチメソッドというのがオブジェクト指向だと主張してるの？

545 ：デフォルトの名無しさん：2011/07/17(日) 02:01:53.72

>関数よりも引数に着目して、処理対象を中心に考えること
違うでしょ
OOパラダイムは構造化パラダイムへのアンチテーゼ

機能をツリー状に構造化して作るというのに対して

データにメソッドをくっつけたものを中心に作って
機能はそれらを適当に呼べばいいっていうのがOOパラダイム

546 ：デフォルトの名無しさん：2011/07/17(日) 02:02:08.06

>>537
＞滞留ってのがもう意味不明だけど、要はコンポジションするしないの話でしょ。
結局なんだかんだいっても実装レベルで話ができるレベルのことだよね
滞留くんはわざわざ分かり難く言って自己満足してるとしか思えない

＞だけどそんなもん、C言語でも同じことだよ。OOまったく関係なし。
OOがまったく関係ないかと言われると違うんじゃないかな
どちらかというとC言語でもOOは可能というのが正しい気がする
ただC言語には、OOが実装しやすくする機能がOOPとして実装されていないということであって、
コンポジションがOOの一要素であるのは間違ってないと思う

547 ：デフォルトの名無しさん：2011/07/17(日) 02:07:35.24

>>542
まーオブジェクトに着目するってことだよ。
オブジェクト指向って言うんだから、オブジェクトを中心に考える。
オブジェクトって対象って意味で、何の対象かといえば、関数の対象。
つまりオブジェクト=関数の引数。
だから、オブジェクト指向では、関数よりもその引数を中心に考えるってことになる。
だから、func(obj)ではなくobj.func()と書く。
引数が前に出た訳だ。まさにパラダイムシフト。
で、問題は、この逆転現象が正しいのかどうか。

548 ：デフォルトの名無しさん：2011/07/17(日) 02:08:00.45

>>543
if連続で書きたければ書いてれば？
むしろオブジェクトの多態もifで書いたいいんじゃない？
君にとっちゃ両方くだらんだろ。

549 ：デフォルトの名無しさん：2011/07/17(日) 02:10:10.88

＞オブジェクトって対象って意味で、何の対象かといえば、関数の対象。
いやいや、
オブジェクト＝対象ではなく
オブジェクト＝モノでしょ

550 ：デフォルトの名無しさん：2011/07/17(日) 02:12:56.92

>>543
名前が同じじゃなきゃダックタイピングできないだろー。
C++やJavaでは基底クラスまで揃えなきゃならないってのに、名前ぐらいは諦めろよ。

551 ：デフォルトの名無しさん：2011/07/17(日) 02:13:31.08

>>544
マルチメソッドは全然オブジェクト指向の否定してないぞ。
オブジェクト指向は、オブジェクトにメッセージさえ送って振る舞わせればいいだけだし。

552 ：デフォルトの名無しさん：2011/07/17(日) 02:15:14.74

11.1 結局「オブジェクト指向」ってなに？ : Javaのオブジェクト指向入門
http://www.kab-studio.biz/Programing/OOPinJava/11/01.html

こういう意見もあるね

　まず、意味が分かりづらい「指向」という言葉について見てみましょう。
　「オブジェクト指向」は、英語で「object-oriented」と書きます。
　「orient」は、「Encarta World English Dictionary」によると「～へと親しませるようにする」「～の方を向かせる」といった意味があります。「～の方へと肩を押す」といった感じでしょう。
　また「object-oriented」と間にハイフンが付いているため、これは「主語述語（過去形）」の関係ではなく、「名詞-過去分詞」の形容詞的な意味になります。
　つまり「Object-oriented」は「オブジェクトへと向けられた」という形容詞ということになります。

　となると、「オブジェクト指向」という言葉だけだとちょっと変です。
　本来なら、「オブジェクト指向の○○」のように、何か掛かる言葉があるはずです。
　そういう意味では「オブジェクト指向」という言葉だけ一人歩きしてしまった日本語訳はちょっと状況がおかしいとも言えます。

確かに外国のwikipediaではObject-orientedというページは存在せず、「Object-oriented programiming」「Object-oriented analysis and design」「Object (computer science)」は存在する

553 ：デフォルトの名無しさん：2011/07/17(日) 02:16:05.30

>>548
だから名前を変えれば済む話だって。

>>550
ダックタイピングしたいところは同じにすればいいだけ。

554 ：デフォルトの名無しさん：2011/07/17(日) 02:16:36.96

>>547
まだ君にはオブジェクト指向は早いわぁ。
多分大体の人は初心者の時に通った道だよ。
上の方でメッセージの議論してるでしょ、
なんで皆メッセージっていってるか考えてみ。

555 ：デフォルトの名無しさん：2011/07/17(日) 02:17:47.51

>>549
モノ指向だとより一層意味不明なんだけど。モノ指向てw。

だいたい、モノがポテンとその辺に転がってても何の意味も無いだろ。
メソッドを呼ぶなりなんなりしなきゃさ。で、メソッドの「対象」なんだろ。

556 ：デフォルトの名無しさん：2011/07/17(日) 02:18:01.45

初心者の上から目線ｗ

557 ：デフォルトの名無しさん：2011/07/17(日) 02:18:18.45

>>552
元々何を目的としてたか書いてない不毛な記事だね。

558 ：デフォルトの名無しさん：2011/07/17(日) 02:19:30.40

不毛な記事だねｗ

559 ：デフォルトの名無しさん：2011/07/17(日) 02:24:14.46

＞モノ指向だとより一層意味不明なんだけど。モノ指向てw。
「機能」指向に対しての「モノ」指向

560 ：デフォルトの名無しさん：2011/07/17(日) 02:27:00.65

> なんで皆メッセージっていってるか考えてみ。

OOの話をするときメッセージって言えば
なんか玄人っぽくてかっこいいからｗ

つーか、メッセージをメソッド以外で
実装している言語はないんだから
メッセージ＝メソッドでいい。
メソッドといえ。

561 ：デフォルトの名無しさん：2011/07/17(日) 02:28:59.37

>>551
オブジェクト指向は、オブジェクトにメッセージさえ送って振る舞わせればいいのだから、
特定のメソッドが、特定のクラスやオブジェクトに結びつけられるのは不便だといいたいんだね。

その考え方は、メソッド(関数)が多相型であるかという問題で、特にオブジェクト指向に限った話題ではないと思うのだけれど。

562 ：デフォルトの名無しさん：2011/07/17(日) 02:30:55.13

バカはすぐなんでも出来れば優れていると考える。

なんでも出来るものは、間違ったこともできるということで
不便なだけなのだ。

たとえば変数を定義しなくても、使える言語は
どんな名前の変数でもすぐ使えるが、
それは間違いも増やすわけで、便利ではない。

563 ：デフォルトの名無しさん：2011/07/17(日) 02:34:22.01

>>551
＞オブジェクト指向は、オブジェクトにメッセージさえ送って振る舞わせればいいのだから
その定義はあなた独自の定義だ。OOと言わずOO_551とか言ったらいいと思う

564 ：デフォルトの名無しさん：2011/07/17(日) 02:35:04.81

>>555
その物に動作があるだろ
それがメソッドだ

>>560
同じくメッセージなんて言葉に深い意味はないと思ってる
ただOOPのメソッド実行をそれっぽく読んでる異常の意味はない

565 ：デフォルトの名無しさん：2011/07/17(日) 02:36:31.96

>>559
だから、機能の対象=オブジェクトだろ？
機能ってのは英語でfunctionなんだから、関数だろ？
そのアンチテーゼなんだから、関数の対象=引数のことだろ。

566 ：デフォルトの名無しさん：2011/07/17(日) 02:39:42.16

>>254にメッセージについてのレスがあるけど
＞メッセージは、オブジェクトに所属していない。
＞メンバー関数やメソッドはオブジェクトに縛られてる。
C言語の関数はどうなるんだ　オブジェクトに縛られていないし、そういう意味ではメッセージになる
>>551こんな定義だとどんな言語、どんな書き方でもOOPになる

567 ：デフォルトの名無しさん：2011/07/17(日) 02:40:41.52

>機能ってのは英語でfunctionなんだから、関数だろ？
これはおかしい。
英語ではどちらもfunctionという単語を使うけれど、
機能と関数はどちらも意味が異なる。

568 ：デフォルトの名無しさん：2011/07/17(日) 02:40:44.23

Aというオブジェクトと
Bというオブジェクトを
合わせるとき、
Aにaddというメソッドをつけるのはおかしいよね。

Aという木とBという木をくっつけるのは
ボンドというオブジェクトだもの。
他にも接着剤というオブジェクトでくっつけることも可能。

569 ：デフォルトの名無しさん：2011/07/17(日) 02:42:50.46

>>>551こんな定義だとどんな言語、どんな書き方でもOOPになる
どんな書き方でもOOPになるのかどうかは知らないけど、
マルチメソッドといっている人は、LISPのCLOSのようなものを考えているんじゃないかという気がする。

570 ：デフォルトの名無しさん：2011/07/17(日) 02:43:04.09

機能はオブジェクトに付いているものだと考えている人がいるけど
関数もオブジェクトという言語があるように、
機能もまたオブジェクトの一種なんだよ。

571 ：デフォルトの名無しさん：2011/07/17(日) 02:43:04.58

>>564
>その物に動作があるだろ
その動作の対象がオブジェクトだろ？
メッセージを送るんだろ？送り先が要るだろ？
メッセージを送る対象がオブジェクトだろ？
メッセージを送る対象によって多態するからオブジェクト指向なんだろ？

572 ：デフォルトの名無しさん：2011/07/17(日) 02:43:27.16

>>565
オブジェクト=引数と言いたいの？
意味不明過ぎるｗ
↓これの対象はvoid？ｗ

void hello(void){
printf("Hello");
}

573 ：デフォルトの名無しさん：2011/07/17(日) 02:44:06.82

>>565
＞関数の対象=引数のことだろ
その言い方をするなら「特別な第一引数」＝「暗黙のthis」のことだ
obj.method(param)
のparamのことではなく、objのこと

それをわかった上で
>関数よりも引数に着目して、処理対象を中心に考えること
と発言していたのであれば日本語をもっと勉強した方がいい

574 ：デフォルトの名無しさん：2011/07/17(日) 02:44:37.92

メッセージ（機能）もオブジェクトだよ。

だからオブジェクト指向でメッセージというものを
オブジェクトと区別して語る必要はない。

オブジェクトにオブジェクトを送るのが
真のオブジェクト指向さｗ

575 ：デフォルトの名無しさん：2011/07/17(日) 02:47:37.69

>>570
C言語でも関数はデータに過ぎない。
だけど、通常、関数をデータとは言わないんだよ。

576 ：デフォルトの名無しさん：2011/07/17(日) 02:51:28.33

>>575
Smalltalkとかだと、割と何でもオブジェクトだけれど。

577 ：デフォルトの名無しさん：2011/07/17(日) 02:52:28.70

>>566
だからお前はその程度の認識なんだろ。
メッセージと関数はそもそも違う。
メッセージをおくると対応するメソッドが呼び出される。
そもそもメソッドとメッセージは別に存在するものだ。
objective-Cやsmalltalkはメッセージだけ変数に格納して
好きなときにオブジェクトに送りつけることもできるんだぞ。

578 ：デフォルトの名無しさん：2011/07/17(日) 02:52:34.54

Smalltalk風のOOとか興味ない

579 ：デフォルトの名無しさん：2011/07/17(日) 02:53:21.71

つメンバ関数ポインタ

580 ：デフォルトの名無しさん：2011/07/17(日) 02:54:48.60

>>572
その場合は関数helloの対象は無いんだよ。
対象が無くても関数は呼べる。関数の方が偉いからね。引数の数を選べるのさ。

>>573
それはお前が勝手にシングルディスパッチだと決め付けているからだろ。
多重ディスパッチの場合、特別な第一引数なんて存在しないし、
引数としか言うほかないぞ。しいて言えばレシーバか。

581 ：デフォルトの名無しさん：2011/07/17(日) 02:54:58.19

>>579
メンバー関数ポインタはクラスに属してるだろ。

582 ：デフォルトの名無しさん：2011/07/17(日) 02:57:27.82

>>581
複数もてばいい話

583 ：デフォルトの名無しさん：2011/07/17(日) 02:58:09.19

>>577
C++で言えば
メッセージ＝メソッドのシグネチャとその引数
メソッド＝メソッド自体の実装
なわけでほとんどどんな言語でもメソッドとメッセージの概念は分離している

していないのはN88-BASICとかくらいじゃない？

584 ：デフォルトの名無しさん：2011/07/17(日) 02:58:18.67

>>579
関数ポインタじゃ引数も束縛できないでしょ。

585 ：デフォルトの名無しさん：2011/07/17(日) 02:58:25.11

メッセージ解釈基底クラスを継承すればいい話だな

586 ：デフォルトの名無しさん：2011/07/17(日) 02:59:06.24

>>584
動的か静的かの話がしたいの？

587 ：デフォルトの名無しさん：2011/07/17(日) 03:01:14.59

>>583
ちょっと違う。メッセージは本来ダックタイプ。

588 ：デフォルトの名無しさん：2011/07/17(日) 03:03:09.37

>>586
マルチディスパッチはメッセージの要件を満たしてると言いたいの。

589 ：デフォルトの名無しさん：2011/07/17(日) 03:08:00.81

>>588
でも実際には関数の動的オーバーロードにしか見えないっていう。
プログラミングスタイルもC言語の時代に先祖がえりするしね。
まさか (obj1, obj2).method(obj3)　なんて書かないでしょ。
func( obj1, obj2, obj3 )でいいよね。

590 ：デフォルトの名無しさん：2011/07/17(日) 03:09:02.46

静的じゃない言語仕様には無理がある。
ダッグタイピングをC上で実装してみれば分かる。
OOPの話じゃないというならなおさらだ。

591 ：デフォルトの名無しさん：2011/07/17(日) 03:09:10.91

＞ちょっと違う。メッセージは本来ダックタイプ。
本来じゃなくSmalltalkやobjective-Cではってことでしょ？
メッセージという概念は当然C++でもJavaでも存在してそれが
メソッドのシグネチャと引数として実装されているんだから

「本来」＝「Smalltalk原理主義」
という主張でしょうか?

592 ：デフォルトの名無しさん：2011/07/17(日) 03:10:51.66

Smalltalkなんて現実には亜流なのにね

593 ：デフォルトの名無しさん：2011/07/17(日) 03:14:25.46

>>591
本来=アランケイがオブジェクト指向として発表した内容。
具体的にはbyteだったかなんだったかに掲載されたインタビューと
smalltalkのリファレンスにのってたメッセージベースの章。

594 ：デフォルトの名無しさん：2011/07/17(日) 03:15:15.98

結局OO=Smalltalkキチガイとは話ができない

595 ：デフォルトの名無しさん：2011/07/17(日) 03:16:29.37

>>590
Cに実装してどうするよ。コンパイラに実装するんだよ。
ダックタイピング+マルチメソッドを実行効率落とさずに実装しようと思うと、
コンパイラレベルでのサポートは必須だね。

かなり面倒だから誰もやらないけど、そろそろ誰かがやった方が良い頃合だろうね。
皆気づき始めてるから。

596 ：デフォルトの名無しさん：2011/07/17(日) 03:17:37.84

>>571
その対象が物なんでしょ
プログラミングの世界でいう一般的なオブジェクトを対象と訳す？
それともオブジェクト指向のオブジェクトという文字列と、プログラミングの世界でいうオブジェクトはまったく別物ということ？

597 ：デフォルトの名無しさん：2011/07/17(日) 03:19:12.65

>>594
じゃあ君は何が正しいと言いたい？
オブジェクト指向と言い出したのはアラン・ケイだし、
それ以上の定義があるのかい？

598 ：デフォルトの名無しさん：2011/07/17(日) 03:21:45.67

>>596
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

599 ：デフォルトの名無しさん：2011/07/17(日) 03:22:16.96

>>597
今普及しているOOPはSIMULA由来のC++/Javaだよ。
その視点がない時点でキチガイ。

600 ：デフォルトの名無しさん：2011/07/17(日) 03:24:08.27

>>596

>なおオブジェクトという用語は時に「もの」という直訳語で認識される場合があるが、
>英語のobjectには「目的語」、または「目的となる対象物」という意味がある。
>従ってオブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。

601 ：デフォルトの名無しさん：2011/07/17(日) 03:27:10.53

>>600
その部分を読んで
Object＝対象と思ったのならもう少し日本語を勉強しよう

そして
対象＝引数と思ったのであればもう少し冷静に考えてみよう

602 ：デフォルトの名無しさん：2011/07/17(日) 03:28:11.36

>>599
普及してりゃ概念が変わる訳じゃねえだろ、
winAPIのメッセージ機構やOSXのメッセージベースAPIも
OOだって名のってんのに全否定じゃねえか。

603 ：デフォルトの名無しさん：2011/07/17(日) 03:29:28.38

>>602
なぜ主流と亜流が存在するか考察したことないんだね

604 ：デフォルトの名無しさん：2011/07/17(日) 03:32:02.26

>>602
＞winAPIのメッセージ機構やOSXのメッセージベースAPIも
メッセージの実装方法にはいろいろあり、Smalltalk風もC++風もwinAPI風
もすべてメッセージを実装している

＞OOだって名のってんのに全否定じゃねえか
だから全肯定。
Smalltalk原理主義だとSmalltalk風以外を全否定するが

605 ：デフォルトの名無しさん：2011/07/17(日) 03:32:03.54

でも、
>述語（機能）よりもその対象を中心に据える
って書いてあるし。
述語(機能)って関数や命令やメッセージやメソッドの事でしょ。
その対象だから、OOP以外の言語で言うところの引数やオペランドってことになると思うけど。
ただ、OOでは引数のことをレシーバーとかオブジェクトって言うけど、呼び方の問題でしかないよね。

606 ：デフォルトの名無しさん：2011/07/17(日) 03:34:36.90

>>605
>述語（機能）よりもその対象（となるモノ）を中心に据える
と言葉を補えば
機能指向→モノ指向
というのがはっきりするんじゃない？

607 ：デフォルトの名無しさん：2011/07/17(日) 03:37:05.38

何でお前が勝手に補うんだよ。
俺も勝手に補うぜ。
>述語（機能）よりもその対象（である引数）を中心に据える

608 ：デフォルトの名無しさん：2011/07/17(日) 03:41:00.44

大体Wikipediaにご丁寧に、「モノと直訳する人が居ますが本来は～」って親切な人が書いてくれてるのに、
何で間違いを認められないんだろうね。
>>600　を100回読み直せよなー。
ここまでストレートに指摘されてるのにね。

609 ：デフォルトの名無しさん：2011/07/17(日) 03:46:43.33

>>608
＞～というニュアンスをもつ用語である
と書いてあるじゃん
つまり直訳で「モノ」だと完全に感じが伝わらなく、
「操作の対象」という意味のニュアンスもあるよってこと

>>600　を100回読み直せよなー。
つ鏡

610 ：デフォルトの名無しさん：2011/07/17(日) 03:48:36.92

>>603
定義がっていってんの。
>>604
が言うように実装方法は色々あるし、現実的なパフォーマンス上の
問題で妥協している言語は色々ある。

そもそもマルチディスパッチがOOの原義に反さない
というところの話しだったと思うがかなりずれたな。

611 ：デフォルトの名無しさん：2011/07/17(日) 03:50:23.61

＞モノと直訳する人が居ますが本来は～
微妙な捏造はやめよう

＞モノと直訳語で認識される場合があるが、Objectには他の意味があり…
と書いてあるだけだ
「本来は」などとは書いていない

612 ：デフォルトの名無しさん：2011/07/17(日) 03:55:23.49

SmalltalkのOOの定義がそもそも亜流なんだが

613 ：デフォルトの名無しさん：2011/07/17(日) 04:06:28.31

>>609
ねぇ、何で間違いを認められないの？これ以上まだ恥かきたいの？

>>600
>～「時に」ものという直訳語で認識される「場合」があるが、
>～「本来」～その対象を中心に据えるというニュアンスをもつ用語である。

時に～場合があるけど、本来は～というニュアンス～
って書いてあるよ？

614 ：デフォルトの名無しさん：2011/07/17(日) 04:09:23.53

>>611

書いてあるじゃん、「本来」って。マーカー引かなきゃ分からない？

http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

>なおオブジェクトという用語は時に「もの」という直訳語で認識される場合があるが、
>英語のobjectには「目的語」、または「目的となる対象物」という意味がある。
>従ってオブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。

615 ：デフォルトの名無しさん：2011/07/17(日) 04:12:34.31

>>613
＞本来は～というニュアンス
そうだよ、単に「もの」ではなく「対象」っていうニュアンスもある
って書いてある

「もの」ではなく「対象」である
なんて書いてないよ

616 ：デフォルトの名無しさん：2011/07/17(日) 04:24:35.75

>>615
ニュアンス「もある」、じゃなくて、本来～ニュアンス「を持つ」、って書いてあるが。

>>「もの」ではなく「対象」であるなんて書いてないよ

>時に「もの」という直訳語で認識される場合があるが

「もの」と訳すのはマイナーらしいよ。だって、時に～場合があるって書いてあるからね。

それに元々オブジェクトを対象と訳した俺に噛み付いてきたのはお前なんだが。
お前は「モノ指向」だって言ってて、俺はオブジェクトをモノと直訳することも知ってたけど、
だけどモノと訳すと意味が分からないだろうと言ってただけだよね。

617 ：デフォルトの名無しさん：2011/07/17(日) 04:34:40.82

「対象」はニュアンスなんだからさぁ
あえて言えば「もの」８０％、「対象」２０％

＞「もの」と訳すのはマイナーらしいよ
訳すのがマイナーなんて書いてない
「もの」１００％と認識するのは本来のニュアンスが伝わっていない
と書いてある

＞それに元々オブジェクトを対象と訳した俺に噛み付いてきたのはお前なんだが。
>>545 >>573　を読み直してみなよ
>関数よりも引数に着目して、処理対象を中心に考えること
におかしいって言っただけだよ。特に「引数」にね

618 ：デフォルトの名無しさん：2011/07/17(日) 04:34:41.66

>>612
メッセージとメソッドが一体化してる言語なんて
C++/Java/.net系言語/Simula/Delphi/Eiffel
ぐらいじゃん。他のオブジェクト指向を標榜してる言語や
ライブラリはメッセージをオブジェクトから独立させられるぞ。

619 ：デフォルトの名無しさん：2011/07/17(日) 04:42:25.12

>>618
＞メッセージをオブジェクトから独立させられるぞ
メッセージとオブジェクトの分離ならポリモさえあればどのOOだってできるだろ

＞C++/Java/.net系言語/Simula/Delphi/Eiffel
そもそもこれ以外のOO言語ってなに？
最初の3つでシェア90％くらいあるんじゃない？

620 ：デフォルトの名無しさん：2011/07/17(日) 04:49:48.06

>「対象」はニュアンスなんだからさぁ
>あえて言えば「もの」８０％、「対象」２０％

ねぇまだがんばるの？何でそんなわけの分からないパーセンテージが捏造できるの？

>なおオブジェクトという用語は時に「もの」という直訳語で認識される場合があるが、
>英語のobjectには「目的語」、または「目的となる対象物」という意味がある。
>従ってオブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。

これ読んでどうやったらそういう理解になるの？
「時に～場合がある」とか「本来」の意味分かってるの？
大体本当に、「もの」８０％、「対象」２０％なんだったら、こんな説明がわざわざWikipediaに載ると思うか？

>>関数よりも引数に着目して、処理対象を中心に考えること
>におかしいって言っただけだよ。特に「引数」にね
では、一体何を中心に考えると？まさかオブジェクト？オブジェクト指向の説明するのにオブジェクトって用語を使うの？

621 ：デフォルトの名無しさん：2011/07/17(日) 05:02:37.56

＞大体本当に、「もの」８０％、「対象」２０％なんだったら、こんな説明がわざわざWikipediaに載ると思うか？
「もの」１００％だと思う人がときどきいるが、
本来は「もの」８０％、「対象」２０％というニュアンスをもった言葉だ

ということを説明したいんでしょ。

＞では、一体何を中心に考えると？まさかオブジェクト？
そうだよモノだよ。対象だってobjectなんだからこの疑問はそっくりそのまま
お返ししますよ

622 ：デフォルトの名無しさん：2011/07/17(日) 05:11:20.12

>>621
では、「時に～場合がある」はどう考えるの？ものと認識されるのは「時に」でしかないようだけど。

>そうだよモノだよ。対象だってobjectなんだからこの疑問はそっくりそのまま
>お返ししますよ

俺はオブジェクトは関数に対する引数だって言ってるんだが。
引数って言葉に引っかかってたんじゃなかったの？
で、Wikipediaによると、オブジェクトは対象物らしいけど、
一体何の対象物なの？操作？処理？

623 ：デフォルトの名無しさん：2011/07/17(日) 05:29:03.30

>>619
他の言語やライブラリにどれだけ影響与えてるかじゃなく、エンドユーザーのシェアの問題かよ・・・。

624 ：デフォルトの名無しさん：2011/07/17(日) 07:14:27.68

＞では、「時に～場合がある」はどう考えるの
「もの」１００％だと思う人が「時に」はいるが
という意味だよ

＞で、Wikipediaによると、オブジェクトは対象物らしいけど、
＞一体何の対象物なの？操作？処理？
操作の対象だよ
Wikiの引用でいえば
「述語（機能）」の対象

625 ：デフォルトの名無しさん：2011/07/17(日) 07:20:42.68

>>623
主流か亜流かの話（>>612）に反論してたんじゃないの？

学術的な影響云々っていうならOOPLなんてとっくに終わってるだろ

626 ：デフォルトの名無しさん：2011/07/17(日) 08:26:26.67

>>618
むちゃくちゃワロタｗ

627 ：デフォルトの名無しさん：2011/07/17(日) 10:11:05.38

オブジェクト指向プログラミング(OOP)　オブジェクトを対象物と訳す場合
オブジェクトというのは、対象物という意味であり、指向は重要視するとかそんな意味
対象物を重視するプログラミング

手続き型プログラミングとの違いを考慮して具体的に言うと、
手続き型時代のC言語の書き方では、どの対象物が関数コールするのかということは意識されていなかった。
hello(); ←どの対象物がHelloするのか？　そんなの気にしないのが手続き型
それに対して、OOPでは明確に対象を指定して関数をコールするようにすることによって○○というメリットがある。
hello(対象);　←C言語でOOP
そしてそれをもっと明示的に対象物を強調した実装になっているのが、現在のOOP言語であるC++やJava
対象.hello(); ←OOP言語でOOP

これにはどんなメリットがあるの？

628 ：デフォルトの名無しさん：2011/07/17(日) 10:23:15.61

オブジェクト指向プログラミング(OOP)　オブジェクトを物と訳す場合
オブジェクトというのは、物という意味であり、指向は重要視するとかそんな意味
物を重視するプログラミング

手続き型プログラミングとの違いを考慮して具体的に言うと、
手続き型時代のC言語の書き方では、物が定義されていなかったため、
どの物について記述しているかがわからず、すべてのファイルを意識してコーディングする必要があった。
修正時には、すべてのファイルをチェックする必要がある。
それに対して、OOPでは物が明確に定義することにより、その物の責務を明確になり、
スコープを限定し、修正の影響範囲を限定できるようになった。

微妙・・・
もっとまともな説明求む

629 ：デフォルトの名無しさん：2011/07/17(日) 10:35:57.02

手続き型とオブジェクト指向は排他じゃないんだが

630 ：デフォルトの名無しさん：2011/07/17(日) 11:18:36.62

排他ではないけど、オブジェクト指向プログラミングの書き方は、手続き型プログラミングの書き方にないものじゃないのかな
そして手続き型の言語でオブジェクト指向プログラミングはできる

631 ：デフォルトの名無しさん：2011/07/17(日) 11:30:37.26

オブジェクト指向によくある誤解。これらを双方が乗り越えられないと永遠に平行線。

×オブジェクトはオブジェクト指向のため作られた。
○オブジェクト指向は、クラスやオブジェクトの後に作られた考え方。
だから、オブジェクト指向の説明にクラスやオブジェクトを使うのは構わない。
前後するが後述の各OOPの違いは、クラスやオブジェクトをどんな目的で使うか、という点。

×オブジェクト指向と呼べるのは「メッセージング」だけ。
○OOPだけでも抽象データ型のOOP、メッセージングのOOP、プロトタイプベースのOOPがあり
部分的に衝突する方向性に折り合いをつけられれば併用も可能な、しかし異なる考え方の総称。

632 ：デフォルトの名無しさん：2011/07/17(日) 11:35:44.28

ストロヴストルップの「プログラミング言語C++」では
OOの文脈上で「メッセージ」はでてこない

633 ：デフォルトの名無しさん：2011/07/17(日) 12:09:37.72

・抽象データ型のOOP
ストラウスストラップが提唱。メイヤーやリスコフなどもこれに準じる。
クラスを抽象データ型として用いるアイデア。俗に「カプセル化、継承、多態性」。
抽象データ型というのは簡単にはユーザー定義型のこと。

・メッセージングのOOP
アラン・ケイが提唱。ヒューイットのアクターはここから派生。
オブジェクトをメッセージのレシーバーとして使うアイデア。
クラスは型ではなく、委譲先の特殊なオブジェクトの一つととらえる。
システム全体を可能なかぎり動的に保つことで、長期・永続的な運用を目的とする。
俗に「オブジェクトにメッセージを送る」。

・プロトタイプベースのOOP
SELFの作者達の考え方をベースにNewtonScriptとJavaScriptの作者らが洗練させた。
オブジェクトに知識フレームのフレームとスロットの役割を担わせ、不在のスロットへの
アクセスは、特殊スロットに指定された委譲先に委譲する考え方。
フレーム、スロット、関数（メソッド）、委譲というシンプルな要素と概念で多くのものを
表現可能である（最たるものでは、クラスベースのシミュレーションとか）ところが売り。

634 ：デフォルトの名無しさん：2011/07/17(日) 12:32:03.28

> システム全体を可能なかぎり動的に保つことで、長期・永続的な運用を目的とする。

これってさ、システム全体＝「OS+アプリ」を想定してるだろ？
smalltalk初期時代はOSなんてものはなかったから、
システム全体（≒OS+アプリ）をつくらないといけなかった。

今はシステム全体は作られ、動的に保たれている。
その上でアプリが動き、そのアプリはカプセル化され単体で動く。
アプリをOOで作ろうが作るまいが、システム全体から見れば
OOとして機能しているのが、今の状態。

この考えならWindowsはオブジェクト指向OSと言われてるのも説明がつく

635 ：デフォルトの名無しさん：2011/07/17(日) 12:32:03.86

ちなみに、クラスとオブジェクトというのは、ダールと二ガードが発明した言語機能で
サブルーチンに寿命を持たせることで擬似並列処理を実現するための枠組みとして作られた。

各オブジェクト指向（と、リスコフの抽象データ型）は、このクラスとオブジェクトの
それぞれ目先を変えた応用例としてとらえると収まりがいい。

636 ：デフォルトの名無しさん：2011/07/17(日) 13:01:00.47

>>634
たしかに、.NET とかスジがいいってアラン・ケイも褒めてたこともありましたが、
http://itpro.nikkeibp.co.jp/members/ITPro/ITARTICLE/20030605/1/
いち利用者の実感としては、暫定実装に過ぎないSmalltalkに比べても「まだまだ」って
かんじはしてしまいますけれどもね。ここらへんは、ケイ自ら、Smalltalkでの試みの
総括みたいな文章を書いているので、こちらを参考にしながら今のWindowsでどこまで
実現できているかと対比させながら考察を加えていただければと。

「ソフトウェア工学」は矛盾語法か？
http://metatoys.org/oxymoron/oxymoron.html

637 ：デフォルトの名無しさん：2011/07/17(日) 13:49:05.94

OOPとかではないオブジェクト指向は
OSとそのアプリでなりたつアプリ間の連携や
複数のサブシステム（アプリ）の連携で動く
大きなシステムを構築するときの方法論

オブジェクト指向設計のおけるメッセージは
メソッド呼び出しではなく、COMであったりOLEであったり
SOAPであったり、プロセス間通信のことである。

言語やライブラリによって、これらはメソッド呼び出しのように
行えるかもしれないが直接の関係はない。

オブジェクト＝プロセス。
メッセージ＝プロセス間通信。

こう置き換えると分かりやすい。

638 ：デフォルトの名無しさん：2011/07/17(日) 14:04:01.74

で？

639 ：デフォルトの名無しさん：2011/07/17(日) 14:06:43.71

これからはプロセス間の連携の話をしましょうということ。

640 ：デフォルトの名無しさん：2011/07/17(日) 14:07:34.65

>>1からしてOOPの話なのにメッセージ・プロセス間の話にする目的は何？

641 ：デフォルトの名無しさん：2011/07/17(日) 14:11:17.64

OOPではなくOOの話がしたいから。

642 ：デフォルトの名無しさん：2011/07/17(日) 14:12:08.98

却下。まったく具体性がない。

643 ：デフォルトの名無しさん：2011/07/17(日) 14:12:09.38

>>637
＞オブジェクト指向設計のおけるメッセージは
＞メソッド呼び出しではなく、COMであったりOLEであったり
＞SOAPであったり、プロセス間通信のことである。
どうしてそういうことになったんだよｗ

644 ：デフォルトの名無しさん：2011/07/17(日) 14:13:36.40

じゃあOOPでないOOの話をする理由は何？
案がないならせめてリファレンスくらい出せ。
昨日からメッセージかメソッドかなんてまったく面白くない。

645 ：デフォルトの名無しさん：2011/07/17(日) 14:21:35.51

俺が一生懸命理解しようとしたOOと違うって言いたいだけだろ。

646 ：デフォルトの名無しさん：2011/07/17(日) 14:24:11.13

リファレンスは一度も出たことないよなｗ

自称OO通は、俺が理解したらOOを語ってるだけで、
OO通というより、OO痛ｗ

647 ：デフォルトの名無しさん：2011/07/17(日) 14:50:09.49

そもそもOOなんてないんだよ
OOP、OOD、OOAこれがすべて

648 ：デフォルトの名無しさん：2011/07/17(日) 15:09:21.87

ぴたっと止まっててワロタ

649 ：デフォルトの名無しさん：2011/07/17(日) 16:08:13.21

オブジェクト＝もの
英語＝日本語

650 ：デフォルトの名無しさん：2011/07/17(日) 17:44:57.85

で　抽象うんちくをのたまう尊師殿は何か作ってるの？
アブストラクトの世界で跋扈しているようだからシステム構築が専門とお見受けしたが．．．　何か実績は？
OOだけではつまんないんじゃね　？　普通！　下働きのPが無いと？　何も具現しない世界では　ｗ

651 ：デフォルトの名無しさん：2011/07/17(日) 18:09:55.14

静かになったんで　ｗ

俺的にOOPでよかった事は　ヒューマンI/Fがフレンドリーになったという事かな？
uITRONやFreeRTOSで書いていた操作系機器をOOPに書き直し　仕様も超変わって使い勝手の評判は良くなった
どうも　構造化前提のRTOSは　頭が固くなってかなわん．．．　そもそも　気楽にUMLを書けん！
メンテ性や機能追加も楽になった．．．　ただ　それは俺だけの事で，，，　ｗ　
Cでの記述上　複雑なんで理解できるパートナーがいなくなったのは痛い！
チームプロジェクトではデザパタやら統一ルールだけやっても　最後は個人の力量！

652 ：デフォルトの名無しさん：2011/07/17(日) 19:26:38.12

>>651
今は過渡期だと思うぜ。
組み込みでも、ディスパッチャをゼロから構築が当たり前だった頃から比べると、オブジェクト指向の考え方が役に立つ案件が増えて来てる。
OOPを含む各種の計算モデルの基礎を学習するなら、CTMCPあたりがお薦め。

653 ：デフォルトの名無しさん：2011/07/17(日) 20:37:43.69

プロセス通信がオブジェクト指向と言っている人は、それがOOP言語にどう実装されてるのか教えて欲しい
SOAPがなくたってJavaはOOP言語だよね

654 ：デフォルトの名無しさん：2011/07/17(日) 20:42:42.99

せっかく終わったんだから釣らないでくれ

655 ：デフォルトの名無しさん：2011/07/17(日) 20:58:31.78

SOAPなんて無くてもRMIがあるのでJavaはOOPLなのです

656 ：デフォルトの名無しさん：2011/07/17(日) 21:27:55.90

OOPとOOPL以外のOOは、オブジェクト指向と
呼ぶべきではないものである。

オブジェクト指向における設計とは
デザインパターンやそれに類する物のことであり
OOAやOODは眉唾ものだから、そんな話を
してくるやつは聞き流したほうがいい。

657 ：デフォルトの名無しさん：2011/07/17(日) 22:52:30.85

うーん、デザインパターンってOODの中で繰り返し現れる定石を抽出したものだと思ってた
というと、OOAは眉唾だけどアナリシスパターンはOOってことになるの？

658 ：デフォルトの名無しさん：2011/07/17(日) 23:52:10.31

デザインパターンはOOPの中で繰り返し現れる定石を
抽出したものだよ。

659 ：デフォルトの名無しさん：2011/07/18(月) 00:16:42.03

デザパタは適用の仕方が謎なんだよね
オブジェクト指向は設計からオブジェクト指向するのに
デザパタって実装抜きに語れないじゃん
なんかデザパタ書いた人ってそもそもオブジェクト指向わかってない気がする

660 ：デフォルトの名無しさん：2011/07/18(月) 00:23:24.09

え？

661 ：デフォルトの名無しさん：2011/07/18(月) 00:31:18.89

>>660
だってコード抜きでデザパタって語れるの？
こんなもんが入ってくるフェイズがあること自体不思議じゃない？

662 ：デフォルトの名無しさん：2011/07/18(月) 01:01:36.38

再利用を考えるフェイズがあって
その時点ですでに実装済みの部品がたくさんある

663 ：デフォルトの名無しさん：2011/07/18(月) 01:08:15.38

>>662
いきなりなに話と全く無関係なこと言い出してるの？

664 ：デフォルトの名無しさん：2011/07/18(月) 01:10:18.03

え？

665 ：デフォルトの名無しさん：2011/07/18(月) 01:18:47.97

OOPっていうとおっぱい想像して辛い

666 ：デフォルトの名無しさん：2011/07/18(月) 05:47:29.10

クラス図も実装ですか?

667 ：デフォルトの名無しさん：2011/07/18(月) 10:02:27.42

クラス図は実装じゃないよな
実装は、メソッドの中身の具体的な処理でしょ

>>659はGoFに対してよくもそんなことが言えるもんだな
どれだけ偉いのかｗｗｗ

668 ：デフォルトの名無しさん：2011/07/18(月) 10:21:54.45

> クラス図は実装じゃないよな

ほぼ実装だよ。

クラス図に、型とかprivateメソッド・変数とか
書き出したら、完全にこれは実装。

669 ：デフォルトの名無しさん：2011/07/18(月) 10:38:09.75

これは実装、それも実装って言ってる人は何の話がしたいの？
ファウラーのアナリシスパターンとか？

670 ：デフォルトの名無しさん：2011/07/18(月) 11:30:20.85

アホなことを言うやつは決して自分の意見を言わない

あくまで他人のアホな意見をまねしているだけで自分は馬鹿ではないという立場

671 ：デフォルトの名無しさん：2011/07/18(月) 20:38:46.35

>>661
単にコード抜くだけなら、社会システムをUMLで書けるだろ。
public methodとしてシステムを外部から見た機能を並べていき、
private fieldをそのシステムが活動するのに使用しているリソースを並べていけばいい。

------------------------
小売店
------------------------
-在庫商品:商品[]
-資本金:金額
------------------------
+口座加入(銀行);
+販売(商品名,財布):商品;
+仕入(商品名,仕入元):商品;
------------------------

そうすると、構造が重複するものが現れるので、
組織の切り出しや、問題構造を切り出すことができる。
まあ、コレって新しいことをしてるわけじゃなく、
帰納型ロジックツリーをUML書式で拡張し書いてるだけなんだけど。

672 ：671：2011/07/18(月) 20:41:37.77

補足すると、OOが世の中を表す物って事ではなくて、
Simulaの物理シミュレーション機能が元になってるから、
ロジックツリーと相性がいいというはなし。

673 ：671：2011/07/18(月) 20:52:22.71

口座加入は変だったな、口座変更の方が正しかったか。
揚げ足にしかならないんで細かいとこは気にしないでくれ。

674 ：デフォルトの名無しさん：2011/07/18(月) 22:13:22.43

>>662
なにそれ？
まったく関係ないことしゃべってない？

675 ：デフォルトの名無しさん：2011/07/18(月) 22:16:38.04

クラス図は、設計じゃなくて
コードそのもの。
コードの内容を図解したただけ。

676 ：デフォルトの名無しさん：2011/07/18(月) 22:29:34.96

>>675
コードと言えばコードかもしれないけど、コードそのものの実装というのは処理も含めて言う物だと思う
クラス図というのは設計図、実際の詳細な処理に依存しない
クラス図通りなら、メソッド内はどう実装しようと外見は同じような物ができあがらなければいけない

もしある2つのクラスが繋がっていて、入力と出力はクラス図の規程通りだが、
実装の処理によって全体の挙動に影響を及ぼすようなことはあってはならない

677 ：デフォルトの名無しさん：2011/07/19(火) 00:27:46.28

フローチャートはコードそのものだから無意味だって意見はよく聞くけど、
いくらなんでもクラス図がコードそのものって意見（愚見？w）は初めて聞いた。

コードそのものというのなら、じゃあ「絶対解読できなない暗号化を行うクラス」
のクラス図か書ければ（たぶんどんなアホでも書ける）即コーディング可能なのか？

ありえない。

678 ：デフォルトの名無しさん：2011/07/19(火) 00:34:21.13

メソッドを呼ぶ側のコードが「外」で呼ばれる側のコードが「中」なので
外でも中でもコーディングは必須ですよ

679 ：デフォルトの名無しさん：2011/07/19(火) 01:25:01.83

だから何度も言うように今ここで話し合われているような話はC言語でも成り立つ。
いわばプログラミングにおける普遍的なテーマみたいなもので、OOに限定した話ではない。
OOPと構造化言語はXORでないって誰かも言ってたが、その通り。
オブジェクト指向はオブジェクトに指向すること。
func( param1 )
のparam1に指向するのがオブジェクト指向。
一方でfuncに指向すれば(制御の)構造化によるC言語的アプローチとなる。
ただそれだけのこと。何処に着目するか、何処に指向するかってだけの話。
考える視点が違うだけで、実際に出来上がるプログラムの構造はほぼ同じだったりする。
だから設計の話をしても意味が無い。ほぼ記述性の違いでしかないから。

問題はほとんどのOOPLがシングルディスパッチであること。
これがOOPLを使うものの頭を日々悪くしている。ある種の洗脳。
馬鹿ご用達ってのはそういうことだろう。

680 ：デフォルトの名無しさん：2011/07/19(火) 01:52:54.86

例えば、OOでの「1+2」を考える。
「1」に「+2」というメッセージを送っている、と説明する人が居るが、
こういった人たちは、昔ながらの「物」中心の考え方をする人か、もしくはOOPに洗脳されてしまった人たちだ。
オブジェクト指向のオブジェクトを物と訳すのも同上だろう。
彼らに共通している過ちは、OOPはシングルディスパッチだと決め付けてしまっていること。

普通の人はこう考える。
「1」と「2」に「+」というメッセージを送り、決定された処理をコンピュータが実行する。
しかし、「1」と「2」にメッセージを送る、とはどういうことなのか。
「1」と「2」それぞれに送るのか。はたまた多段的に送るのか、または、「1」と「2」の結合体に送るのか。
そこで、すぐに無理があることに気づいて考え方を改める。
「+」に「1」と「2」というメッセージを送ると考えた方がより素直だから。
メッセージを受け取った「+」が実際にどういった処理を実行するかは「+」次第と言う訳だ。
述語は一つなのに対して、対象は複数取りうるから、(例 func( a, b, c ) )
一つしかないと分かりきってる述語に指向するわけだ。軸は一つの方が良いからね。
これが正常な脳みそ。

681 ：デフォルトの名無しさん：2011/07/19(火) 02:13:22.30

>>680
1に対して+2というメッセージを送る？
1がもっている+という機能に対して2を送るって考えるんじゃね、オブジェクト指向の人は

682 ：デフォルトの名無しさん：2011/07/19(火) 05:03:33.84

>>>679
上はプログラミング普遍的なテーマではないような、C言語がOOPLではないというだけでOOPは可能ということだと思ってたんだけど

あとどうしてシングルディスパッチであることが問題なのかわからないからもう少し説明して

683 ：忍法帖【Lv=32,xxxPT】：2011/07/19(火) 07:01:01.19

てす

684 ：デフォルトの名無しさん：2011/07/19(火) 10:25:31.18

>>659
だってデザパタはよく使われる実装に名前を付けただけなんだもん
アセンブリしか無かった時代に、特定の条件付きジャンプのパターンに「ループ」って名付けたりしてたようなもの

685 ：デフォルトの名無しさん：2011/07/19(火) 10:44:48.48

GOFのパターンなんて20年前のプログラミングスタイルから抽出されたものなんだから
今それが役立つなんてことがあればそれは20年前の超時代遅れなプログラミングスタイルをとってるプロジェクトということにならぬか

686 ：デフォルトの名無しさん：2011/07/19(火) 11:10:46.08

>>685
GoFに変わる現代のプログラミングスタイル教えて

687 ：デフォルトの名無しさん：2011/07/19(火) 11:11:54.83

>>681
> 1に対して+2というメッセージを送る？
> 1がもっている+という機能に対して2を送るって考えるんじゃね、オブジェクト指向の人は

いえ、>>680 の後半の主張はツッコミどころ満載ですが、この部分は問題ありません。
実際、アラン・ケイの着想は 1 に + 2 というメッセージを送るというところから始まっています。

くわしくは、The Early History of Smalltalk
http://c2.com/cgi/wiki?EarlyHistoryOfSmalltalk
の IV. 1972-76--The first real Smalltalk (-72), its birth, applications, and improvements
あたりを参照してください。

688 ：デフォルトの名無しさん：2011/07/19(火) 11:49:38.07

>>687
そうだな少なくともデリゲートやGenericsは今日では当たり前のように使われてるけど
GOF執筆の時点では一般的なOOP言語のfeaturesとして含まれてなかったよね

689 ：デフォルトの名無しさん：2011/07/19(火) 11:51:48.38

>>688は>>686宛で

690 ：デフォルトの名無しさん：2011/07/19(火) 16:33:08.39

>>688
それがデザインパターンに変わるもの？
ただの言語機仕様だと思うんだけど

691 ：デフォルトの名無しさん：2011/07/19(火) 17:46:24.87

それらの新しいものを想定したパターンはＧＯＦ執筆時には考慮されてなかったよねって話

692 ：デフォルトの名無しさん：2011/07/19(火) 17:49:50.60

>>691
それらが増えたことによりデザインパターンの変わりとなる何か新しいものはできたの？

693 ：デフォルトの名無しさん：2011/07/19(火) 18:28:23.72

新しいパラダイムに適応できない低能PGとそうじゃないPGのカーストができたよ

694 ：デフォルトの名無しさん：2011/07/19(火) 18:28:54.03

例えばデリゲートパターンはＧＯＦの時点では存在してなかった筈

695 ：デフォルトの名無しさん：2011/07/19(火) 18:40:15.99

>>694
>>685からの文脈を辿ってくれると嬉しい
GoFのデザインパターンは古くさい → じゃあGoFに変わる物は何？
っていう流れ
それらはGoFに変わる物じゃなくてGoF＋αだよね
GoFが古くさいという所以を知りたい

696 ：デフォルトの名無しさん：2011/07/19(火) 19:47:46.17

定理のようなデサパタが出来たら､時代遅れとは言わせない｡

697 ：デフォルトの名無しさん：2011/07/19(火) 23:39:51.43

デザインパターンをそのまま書くのが面倒だから
言語側で、デザインパターンを実装しやすくしましょう。

あくまで実装するのはデザインパターン・・・。

698 ：デフォルトの名無しさん：2011/07/20(水) 00:44:16.74

デザパタはオブジェクト指向と違うと思うんだよね
仕様書にあるものそのままクラスにすればいいと思うんだけど
デザパタってなんか余計な汎用性を混入してない？
んでプロジェクトが長く続いたときにそれが適切な適用じゃなかったときに
最悪なコードになってる場合が多いと思うんだけど・・・

699 ：デフォルトの名無しさん：2011/07/20(水) 02:14:04.52

>>698
プログラマーじゃないやつは
およびじゃないよ。

700 ：デフォルトの名無しさん：2011/07/20(水) 04:52:38.47

>>698
どんなものでも適切に使わなかったら良くならないだろ
仕様書にあるものそのままクラスにする　ってどういうこと？

701 ：デフォルトの名無しさん：2011/07/20(水) 07:00:06.30

ジェネリクスやデリゲートは昔から動的型付け言語で出来てた事を静的型付けで出来るようにしたもんだろ
多分それら使ったパターンはSmalltalkとかで昔からあったものに名前を付けたものもなるだろう

702 ：デフォルトの名無しさん：2011/07/20(水) 08:19:18.58

genericsはC++のtemplateが直系の元ネタになるんだろうけどtemplateの元ネタって何にあたるんだろう

703 ：デフォルトの名無しさん：2011/07/20(水) 12:06:38.47

Cで型パラメータを取る型といえば配列と関数とポインタ。
OOPは関数とポインタをうやむやにしたが配列はスルーできなかった。
ちなみに固定長配列はdependent typeの元ネタにもなるが今は無視する。

704 ：デフォルトの名無しさん：2011/07/20(水) 13:02:17.50

GoF本の他にない重要な価値って２つあって、
ひとつは、主にSmalltalkの玉石混淆オブジェクトスープの中から主要なパターンを抽出して分類・命名したこと。
もうひとつは、それらを抽象データ型ＯＯ向きの言語（C++）で実装・再利用可能であることを示したこと。

705 ：デフォルトの名無しさん：2011/07/20(水) 15:10:10.45

http://c2.com/cgi/wiki?DesignPatternsInDynamicProgramming

> 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp
> (for example, because of the power of higher order functions)

706 ：デフォルトの名無しさん：2011/07/20(水) 16:14:31.09

型がないなら関数型、型があるならオブジェクト指向ってことだろ
Haskellはデザインパターンよりも酷い

707 ：デフォルトの名無しさん：2011/07/20(水) 16:30:11.63

斬新な意見だ

708 ：デフォルトの名無しさん：2011/07/20(水) 17:21:30.47

デザパタはOOPの目的ではないがデザパタを知らんとOOPの極意に近づけんのでは？
OOだけを語れば　ふるまいの抽象化とメッセージふるいになるんじゃね？　・・・と哲学を語ってみた

709 ：デフォルトの名無しさん：2011/07/20(水) 17:28:03.43

まっ　いずれにしろ　OO．．．OOPを現場で使ってこその哲学談義の世界
まず　何かを創ること！
まだまだ　オブジェクトモデルの構築が現場に生かされていない日本だ　純粋OOの尊師よ　がんばれ！

710 ：デフォルトの名無しさん：2011/07/20(水) 17:32:10.04

>>706
どこをどう読んだら>>705からその結論になるのか

711 ：デフォルトの名無しさん：2011/07/20(水) 18:01:01.68

>>702
C++のtemplateの元ネタはC言語のマクロだ。
#define swap( type, a, b ) { type tmp; tmp=a; a=b; b=tmp; }
とかな。

712 ：デフォルトの名無しさん：2011/07/20(水) 22:15:08.51

>>700
だから仕様書に使われてる概念や図をそのままプログラムに反映すりゃいいんだよ
そのためのクラスだろ？
一旦Gofにある構造に組み替える必要が俺にはわかんね

713 ：デフォルトの名無しさん：2011/07/20(水) 22:22:09.15

>>702
genericsの元ネタはMLや型付きラムダ計算だろう。

714 ：デフォルトの名無しさん：2011/07/20(水) 22:25:09.97

ラムダとどこに関係が？

715 ：デフォルトの名無しさん：2011/07/20(水) 22:26:34.39

そこは"型付き"のほうに反応しろよ

716 ：デフォルトの名無しさん：2011/07/20(水) 22:34:27.60

>>708
デザパタは戦闘術の型であって戦略じゃないからな。
いくら知ってたところで、オブジェクトDB、オブジェクト辞書、
IOデバイスを1つのプログラム内に構築する時のような
設計の戦略方針にはならないんだよな。

あと、デザパタはC++ベース故か型安全を趣向してる感がある。
型安全を意識せず、単に汎用的な部品を作って高速に
コーディングって方面とはちょっと反する感じがする。

717 ：デフォルトの名無しさん：2011/07/20(水) 23:04:26.89

>>712
そのままってなんだｗ
その概念や図は、現実世界に対してどの程度抽象化されたものなの？

＞一旦Gofにある構造に組み替える必要が俺にはわかんね
それはそれぞれのパターンのメリットを理解した上で言っているの？
それともメリットが理解できないと言っているの？
それとも理解しようとしていないの？

718 ：デフォルトの名無しさん：2011/07/20(水) 23:09:59.61

>>716
ガンヲタうざい

719 ：デフォルトの名無しさん：2011/07/20(水) 23:11:43.19

>>718
ガンダム？になんの関係が？

720 ：デフォルトの名無しさん：2011/07/21(木) 00:33:27.40

>>717
いや、だからGofに構造があるように
仕様書に書いてある対象の業務にも構造があるじゃん？
それを一旦Gofに置き換える意味がわかんね
っていうの

そのまま仕様書に書いてある業務（たとえば集荷システムならその概念の説明とかついてるだろ？）を
そのままクラスでその構造を再現すりゃいいんじゃねぇのか？
ファクトリーとか無駄なクラスいらんで

721 ：デフォルトの名無しさん：2011/07/21(木) 01:29:52.07

>>720
お前の作るシステムはコボルみたいな
同じようなコードを大量コピペしたものになりそうだなｗ

たとえば集荷システムなら、仕様書には対応すべき配送会社
すべて書いてあるだろう。仕様書の段階ではこれでいい。

だが実際のコードでは、各配送会社を抽象化し
メインのシステムと連携するアーキテクチャが必要になる。
でないと拡張性がなくなり、行き当たりばったりのコードで
人海戦術による開発になる。

効率の良い開発をするための設計。そのサンプルがデザインパターンで、
これは仕様書レベルで書かれることはまずない。
仕様書のクラスをそのままコードにしてはいけないのだよ。

だからクラス図はプログラミングの一部であり
デザインパターンのまたプログラミングの一部なのだよ。

722 ：デフォルトの名無しさん：2011/07/21(木) 05:04:39.19

>>720
それはもうGoFのデザインパターンを勉強しろとしか言えない

723 ：デフォルトの名無しさん：2011/07/21(木) 06:03:13.76

>>721
いや、俺はみやすさのために仕様書とわざわざ一致させる
こうすれば誰がみても仕様書と一致してるんだからわかりやすいでしょ？
わかりやすくするためにわざわざ仕様書と一致させてるの

それをお前等は勝手に違うクラス生成して
仕様にない汎用性を追加して
本当に意味不明なことをするから「なんで？」って聞いてるの

724 ：デフォルトの名無しさん：2011/07/21(木) 06:30:08.45

仮に仕様書のままでは本当に組めないんだとしたら
仕様書レベルで修正するべきだと思うよ
お前が主張する拡張性云々もそこで追加したらいいと思う
仕様書とソースが不一致な状況のがまずいと思う

頑張るフェイズがズレてる

725 ：デフォルトの名無しさん：2011/07/21(木) 07:07:32.71

ああ、プログラムを和訳した物を仕様書と呼んでいたのか

726 ：デフォルトの名無しさん：2011/07/21(木) 07:15:16.42

>>721, >>723
どちらもお互いに虚勢を張って、口から出任せを言い合ってるようにしか見えない。
（「おれは凄いんだ」と虚勢を貼るのが主目的になってるように見える。その証拠に、具体的なコード例が1行もでてこない！ｗ）

もっと具体的なコード例を出して議論しないと無意味。
（おそらく具体的なコード例を用いて反論すると、お互いに、自分がヘボいことがバレてしまうため、具体的なコード例を避けてるように見える）

727 ：デフォルトの名無しさん：2011/07/21(木) 07:16:57.11

仕様書が完璧ならそのままでいいが、
完璧な仕様書は日本語とは思えないほど複雑な構造になる
というパターン

728 ：デフォルトの名無しさん：2011/07/21(木) 08:30:10.12

汎用性を求めたらクラスがぽこぽこ生成されちゃうのは
C++やJavaのような言語特有の問題(>>705)
つまり使ってる言語が悪い

729 ：デフォルトの名無しさん：2011/07/21(木) 09:34:00.44

>>727
だからデザパタって話はおかしいよね

730 ：デフォルトの名無しさん：2011/07/21(木) 09:39:13.66

>>728
型安全のためということにすればクラスを多めに作っても正当化できるが、
動的言語ではそのような言い訳ができない。
だからJavaが強い。

動的言語やるならオブジェクト指向と全然関係ない方向に進むのが得策だ。

731 ：デフォルトの名無しさん：2011/07/21(木) 17:06:34.39

>>730
Javaのような言語ではクラスを作らなくては難しい事も、
クラス作らずに簡単に出来る言語はある

例えばDecoratorパターンなんて本来クラス作る必要は無い
(Javaの例：http://ja.wikipedia.org/wiki/Decorator_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3#.E5.88.A9.E7.94.A8.E4.BE.8B)

import new
class Price(object):
    def __init__(self, value):
        self.value = value
    def getValue(self):
        return self.value

p = Price(120)
p.getValue = new.instancemethod(lambda _, f=p.getValue: f() * 2, p, Price)
p.getValue = new.instancemethod(lambda _, f=p.getValue: f() + 80, p, Price)
print p.getValue() # 320

732 ：デフォルトの名無しさん：2011/07/21(木) 17:37:13.33

>>731
classを減らそうと思えば0個にもできるのに
Pythonは何がしたいんだ？
PerlにもJavaにもなりたくないなら何になりたいの？

733 ：デフォルトの名無しさん：2011/07/21(木) 17:43:14.56

別に Python そのものはどうでもいい
ただ汎用性を求めるのにクラス作る必要は必ずしも無いってだけ

734 ：デフォルトの名無しさん：2011/07/21(木) 20:27:15.75

>>732
大抵の言語はPerlにもJavaにもなりたくないだろ

735 ：デフォルトの名無しさん：2011/07/21(木) 21:19:50.03

このスレを省略するとオ馬鹿スレだな。

736 ：デフォルトの名無しさん：2011/07/21(木) 21:53:37.40

オブジェクト指向に馬鹿とか土方とかの
マイナスイメージを植え付けたJavaの罪は重いな

737 ：デフォルトの名無しさん：2011/07/21(木) 22:08:21.36

>>723
> それをお前等は勝手に違うクラス生成して
> 仕様にない汎用性を追加して
> 本当に意味不明なことをするから「なんで？」って聞いてるの

private関数やローカル変数を作るのと一緒。
その方が作り易くてバグも少なくなるから。

それともお前はそこまでちゃんと書くのか？
書かないだろう？

コーディングしやすいという観点で設計書を書いているか？
書いていないだろう？
もし書いているとしたらデザパタもそこに含まれているはずだ。
（デザパタをかけないならそれは技術不足）

738 ：デフォルトの名無しさん：2011/07/21(木) 22:15:25.16

>>737
デザパタを使う理由が拡張性がどうとか言ってたよね？
その時点でもう仕様書変更せずにプログラム組んじゃうのはなんか違うよね？
拡張性を反映した仕様書にしないとダメだよね？
当然工数も違ってくる（増えるんか減るんか知らんけど）

739 ：デフォルトの名無しさん：2011/07/21(木) 22:15:46.41

>>736
お前の罪じゃね？ｗ
そうやってマイナスイメージを植えつけてるでしょ。

740 ：デフォルトの名無しさん：2011/07/21(木) 22:15:52.24

>>731
確かにクラスは少ないけど
この手法がわかりやすいかと言うとそうでもない気がする

741 ：デフォルトの名無しさん：2011/07/21(木) 22:29:13.52

>>738
> 工数も違ってくる
工数自体は別のレイヤーの話だよ。それはコミュニケーションで解決すればいいだけの話。
仕様書を変更する必要があるというのも別レイヤーの話。変更する手続きをとって解決すればいいだけの話。

どっちもデザインパターンを使う理由を否定することにはならないんだよ
技術不足な人が間違って使うのは論外として、デザインパターンを使うのは、
作りやすく修正しやすく拡張しやすく他人と技術を共有しやすく、するためのもの。

もちろんそれで工数がかかるかもしれないよ。
なら、工数を調べた上でどっちにメリットがあるか判断すればいいだけの話。
デザインパターン自体をに否定するものじゃない。
君はデザインパターンを否定しているのではなく「勝手にやるな」といっているだけ。

それよりも実装者が入れた（少なくとも実装者はメリットがあると考えている）デザインパターンを
なぜ最初の段階で仕様に入れることができなかったのかその理由を考えてみたら。
もっと言えば、君はデザインパターンを仕様に入れるだけの技術力があるかを考えてみたら。

俺が書いてないんだから書くな。俺が知らないんだから使うな。それは正当な理由じゃないからね。
デザインパターンを否定するのなら、少なくともそのパターンを使わない理由を言えないとだめ。

まあ開発のやり方としては「俺は上流工程やってるのだからデザインパターンを考える立場じゃない」という
考えもありだろう。なら実装者がやるしかないよね。

742 ：デフォルトの名無しさん：2011/07/21(木) 22:41:42.21

これさ、どういっていいのか分からないんだけど、
クイックソートとかのアルゴリズムとデザインパターンって何が違うの？
どちらも技法なんだから、アルゴリズムOKならデザパタもOKだとおもう。
だけど、逆に言うと、デザインパターンとかっていう呼び名は要らなかったんじゃ。
そういう意味じゃアホっぽいよな。パズワードって言うんだっけ？
アルゴリズムって言えばいいのにデザパタっていうから変なことになるんだろう。
OOPってそういうのが多い気がする。

743 ：デフォルトの名無しさん：2011/07/21(木) 22:50:09.51

アルゴリズムは関数
デザパタはオブジェクトデザイン

744 ：デフォルトの名無しさん：2011/07/21(木) 22:53:27.53

ほら、アホっぽいでしょ。だから嫌われるんだよ、デザパタ。
一方でアルゴリズムって言葉に嫌悪感を示す人は居ないんだから、
少なからず嗅ぎ分けてる奴も居るってことだよ。

745 ：デフォルトの名無しさん：2011/07/21(木) 22:57:03.91

そういう曖昧で掴みどころの無いものを適当にでっちあげて
それに途方も無い価値があるように見せかける
セミナー屋のやり方だよね
ファウラーはこの手法で大儲けできたね

746 ：デフォルトの名無しさん：2011/07/21(木) 22:59:53.06

それは自己紹介乙だよ。
オブジェクト指向こそ、それそのものじゃん。
だって、誰も定義すらよく分からないのにさ。

747 ：デフォルトの名無しさん：2011/07/21(木) 23:00:02.42

>>742
デザパタは再利用技法。アルゴリズムは問題解決策。
デザパタ無視してもプログラムは動くが、アルゴリズム無しじゃプログラムは動かん。
アルゴリズムを如何に改良しようと、再利用性には影響ないがデザパタを無視すると再利用性が無くなる。

748 ：デフォルトの名無しさん：2011/07/21(木) 23:04:05.05

そうか？デザパタの中には、
アルゴリズムと言っても差し支えの無いようなのも多いが。

749 ：デフォルトの名無しさん：2011/07/21(木) 23:06:02.66

あれは別にアルゴリズムじゃない。
再利用性無視して依存関係バリバリのコードでも同じ事が書ける。

750 ：デフォルトの名無しさん：2011/07/21(木) 23:08:11.74

>>748
デザパタにアルゴリズムが存在するとしたら、
非デザパタ適用コードじゃ同じ問題は今まで解決出来なかったて事になるぞ。

751 ：全部wikipediaから：2011/07/21(木) 23:08:56.52

デザインパターン
過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し
名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したもの

アルゴリズム
数学、コンピューティング、言語学、あるいは関連する分野において
問題を解くための効率的手順を定式化した形で表現したものを意味する。

オブジェクト指向
オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方

オブジェクト
関連するデータを束ね、代入、演算、手続き（関数やメソッドなど）を介した受け渡しといった
操作の対象にでき、またメッセージの受け手になれる実体

バズワード
一見、専門用語のようにみえるが、明確な合意や定義のない用語

「広義の」とつけると何でもバズワードになるよね

752 ：デフォルトの名無しさん：2011/07/21(木) 23:10:12.78

アルゴリズムにしろデザパタにしろよく使われるものに名前付けて、議論する際に扱いやすくしただけだろ
でもこの名前を付けるというのが大事ともいう

753 ：デフォルトの名無しさん：2011/07/21(木) 23:11:56.29

デザパタは状態を前提とするが
アルゴリズムは副作用がない

754 ：デフォルトの名無しさん：2011/07/21(木) 23:13:18.74

>オブジェクト指向
>オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方

考え方ってのが凄いね。思想みたくなってる。
これが技術用語ってんだから、ソフトウェア界は緩いよなぁ。

755 ：デフォルトの名無しさん：2011/07/21(木) 23:16:05.29

アルゴリズムは別に名前がなくてもアルゴリズムだけどな。
あくまで解法の実体を形容した言葉だから。

756 ：デフォルトの名無しさん：2011/07/21(木) 23:19:43.02

>>750
あんだけどんどん特許見たく名前付けられたら、非デザパタ適用コードなんてかけないでしょ。
知らずに使ってたってのは有るだろうが、探せばどれかに当てはまるでしょ。

シングルトン－インスタンスを一つに固定する「アルゴリズム」。
とかでも別に良い気が。
単に新しい用語作って本と名前を売りたかっただけじゃね＞デザパタ

757 ：デフォルトの名無しさん：2011/07/21(木) 23:21:23.78

集合論とか述語論理とか代数等の数学の世界の言葉でオブジェクトとかその周辺用語を定義して
それを使ってOOPの各種原則を議論した試みは無いのか
OOP界隈に漂うゆるふわを取っ払った真面目なOOPを知りたい

758 ：デフォルトの名無しさん：2011/07/21(木) 23:27:49.70

状態を分割するのがオブジェクト志向
それまでは機能での分割しか意識されなかった

759 ：デフォルトの名無しさん：2011/07/21(木) 23:30:50.62

>>756
だから、それはアルゴリズムじゃ無いってば。
アルゴリズムは結果を出さなきゃならない。

D ←　F( S )

アルゴリズムを単純化するれば、この関数Fになる。
このFをどう再利用できるようにするかは、アルゴリズムの範疇じゃない。

760 ：デフォルトの名無しさん：2011/07/21(木) 23:32:09.44

>>757
いやだからそれはね、
オブジェクト指向－object-oriented　で、英語って文型がきっちりしてるでしょ。
SVCとかSVOとか。この「O」がまさにobjectの「O」。
これに着目しなさいってのがオブジェクト指向。
色んな人が色んな事を言うけど、「オブジェクト指向」っていうからには、
ここだけは覆せない。

でも英語の文型ですら、SVOOとかあるわけでさ。
この場合どっちの「O」に着目すれば良いんだろうね。
V(O1,O2)をO1.V()O2とするかO2.V(O1)とするかって悩みは永久について回る。

マルチメソッドにすれば良いんだけど、
そうすると「V」が多態用の分岐テーブル持つことになるから、
あんまオブジェクト指向っぽくないっていう。

761 ：デフォルトの名無しさん：2011/07/21(木) 23:33:05.17

>>758
状態の分割じゃなくあくまで再利用性の問題。
デザパタをよく見てみろよ。まぁ、Wikipediaに載ってるヤツは
アホなこと結構書いてるけどな。ダブルディスパッチの例とか最悪だし。

762 ：デフォルトの名無しさん：2011/07/21(木) 23:34:24.48

>>761
理解してないことが分かった
状態の分割と再利用性は排他じゃない

763 ：デフォルトの名無しさん：2011/07/21(木) 23:35:21.60

>>760
OOの発案者は全くマルチディスパッチを批判してないけどな。

あとオブジェクトが状態を持つ必要はない。結果だけ持ってても十分。

764 ：デフォルトの名無しさん：2011/07/21(木) 23:37:03.72

>>762
排他な存在だとは思ってないが、状態の分割とやらは全く関係ないと思ってる。
じゃ君の言う状態の分割って何だい？

765 ：デフォルトの名無しさん：2011/07/21(木) 23:40:28.40

>>763
だけど、メッセージとか言い出すと途端に困るだろ？
method( o1, o2, o3 );でマルチメソッドした場合、
メッセージの扱いはどうなるんだ？
どれが受け取るの？全部が受け取るの？誰が処理するの？

実際には処理はオブジェクトではなくコンピュータがする訳で、
その辺の行き違いがあるわな。
分かりやすく例え話をしようとして、微妙な差異から余計分からなくなった
ってのと似ていると思う。

766 ：デフォルトの名無しさん：2011/07/21(木) 23:40:30.52

グローバル変数はだれがどこから変更するか分からないから問題がある。
これを認めた場合、
rand();
はsrand()がどこで呼ばれるか分からないのでrand()の再現性が保証できない。
この不透明さを回避するために
r new = CRand(0);
r.GetRand();
とする。

767 ：デフォルトの名無しさん：2011/07/21(木) 23:42:59.03

状態云々はあくまで、結果だけだと実装上コピーコストが発生するから
であってOO事態とは別問題だよ。副作用の無い言語だとOOを実装できないことになる。
でも副作用のない言語でもメッセージの概念を反映できるから、堂々とOO可能だと名乗ってる。

768 ：デフォルトの名無しさん：2011/07/21(木) 23:46:30.77

>>767
実際に関数型(Haskell)で書いてみ
状態なしにはかけないから
それを彼らはモナドと呼ぶけど

769 ：デフォルトの名無しさん：2011/07/21(木) 23:47:47.27

>>765
OOは別にオブジェクトが本体じゃないから。
メッセージが与えられて、変化が起きればいいだけの話。
メッセージがOOのコアで、オブジェクトは二の次。

770 ：デフォルトの名無しさん：2011/07/21(木) 23:48:16.19

また俺OOかｗ

771 ：デフォルトの名無しさん：2011/07/21(木) 23:50:14.81

>>769
だから、>>765の場合、メッセージが誰に与えられるんだ？って聞いてるんだが。

772 ：デフォルトの名無しさん：2011/07/21(木) 23:53:11.49

>>768
別にHaskellにこだわる必要も無いだろうに。
引数にオブジェクトを受け取って戻り値で変更を加えたオブジェクトを返せばいいだけじゃん。

773 ：デフォルトの名無しさん：2011/07/21(木) 23:54:43.39

>>771
誰かはいらないんだって。

774 ：デフォルトの名無しさん：2011/07/21(木) 23:55:15.11

引数のオブジェクトは状態じゃないのかｗ

775 ：デフォルトの名無しさん：2011/07/21(木) 23:55:59.66

相対性理論は間違ってる！ばりのキチガイ

776 ：デフォルトの名無しさん：2011/07/22(金) 00:00:08.82

>>773
言ってることが次第にしどろもどろなんですけど。
>メッセージが与えられて、変化が起きればいいだけの話。

「与えられて」って発言しといて、誰に与えられるの？って聞くと、誰かはいらない、と。
う～ん、悟りですね。

777 ：デフォルトの名無しさん：2011/07/22(金) 00:07:50.29

これは「デザインパターンで学ぶオブジェクトのこころ」とかいう本からヒントを得たアイデアなんだけど
最終的に満たすべき条件(P)っていうのがあるよね、まぁ仕様ともいうけど
その一部を満たすコード辺が沢山あると仮定して、それらが満たす条件を適当に組み合わせてPが満たされるとしたときに
Pを適当な単位に分割する事ができると考えられるよね
その分割した単位をオブジェクトと呼ぶのはどうだろうか？

778 ：デフォルトの名無しさん：2011/07/22(金) 00:11:13.42

いみふなので却下

779 ：デフォルトの名無しさん：2011/07/22(金) 00:11:20.04

結局、デザパタを利用する理由を挙げさせるとそれは仕様書に書けよって話になる
拡張性？再利用？
やれば？
ただし、仕様書に明記した上でな

780 ：デフォルトの名無しさん：2011/07/22(金) 00:14:27.86

>>776
状態にメッセージを送ってるとでも言えば満足かい？
それが解ったところで何も変わらないけど。

781 ：デフォルトの名無しさん：2011/07/22(金) 00:15:56.77

>>780
自慢げに敗北宣言ｗ

782 ：デフォルトの名無しさん：2011/07/22(金) 00:16:32.63

>>779
実装に癒着した設計書って・・・。
詳細設計書でもそんなこと書かんぞ。
DB使うのにいちいちクエリの構文について書いてるぐらい馬鹿げてる。

783 ：デフォルトの名無しさん：2011/07/22(金) 00:17:59.41

>>781
これで君は何かを得られたらしい。
おめでとう。

784 ：デフォルトの名無しさん：2011/07/22(金) 00:18:44.86

なにもない奴の虚勢ってみっともない

785 ：デフォルトの名無しさん：2011/07/22(金) 00:23:07.97

>>782
はぁ？
拡張性と汎用性のための構造が入ってんだろ？
これが明記されなくてなにを書くの？

明らかにこれを入れるために生成されたクラスがあるんだよね？

786 ：デフォルトの名無しさん：2011/07/22(金) 00:27:22.88

>>780
なんか凄くあおられてるけど、あおってるのは俺(>>776)じゃない。
俺とお前の考え方は似てると思うよ。
ただ、それだったら、俺はオブジェクト指向ではなく、述語指向って言えって思うけど。
オブジェクト二の次で、メッセージ主体なんでしょ？述語指向だよね。

787 ：デフォルトの名無しさん：2011/07/22(金) 00:54:54.88

>>786
別にそう言ってもいいんじゃない？
もともと、OOなんてアランケイと禿が別の観点で言い出してて、
その時点でズレてるわけだし。

788 ：デフォルトの名無しさん：2011/07/22(金) 00:59:02.30

>>785
詳細設計書なんてプログラムの外から見た内容しか書かんだろ。
どのタイミングで実際にファイルを移動するとか、
どういうプロトコルを用意するとか。
出力データの基盤となるアルゴリズムは何を使うとか。
並列で動かすとか。

789 ：デフォルトの名無しさん：2011/07/22(金) 01:07:08.65

「オブジェクト指向」はアランケイが作った言葉なんだが

790 ：デフォルトの名無しさん：2011/07/22(金) 01:09:29.01

>>785
普通そこまで具体的な内容は、ソースのコメントか、
プログラマー同士のメモじゃね？
メモって言っても、正式な文章じゃないってだけで
ある程度体裁がまとまってるけど。

791 ：デフォルトの名無しさん：2011/07/22(金) 06:07:43.41

>>786
述語指向っていわゆる手続き型とは違うの？
述語を関数名にすれば完成だよね

それに対象物というものが加わったのがオブジェクト指向プログラミングでしょ

792 ：デフォルトの名無しさん：2011/07/22(金) 06:20:22.15

>>785
クラス図に書いてあるけど、それでは満足できないの？
あとは仕様書にクラスの説明が書いてあれば問題ないでしょ
何を求めているのかがまったくわからん

変更されるであろうところをカプセル化して、汎用部品にすることに納得できてないの？
理解してないならそこまでは勉強しろ
理解しているなら具体的にその構造のどこに納得いかないのか教えてくれ

793 ：デフォルトの名無しさん：2011/07/22(金) 08:29:03.48

>>791
ちがう

794 ：デフォルトの名無しさん：2011/07/22(金) 08:42:59.74

もともと関数とメッセージの違いは

・関数：副作用無し、戻り値有り
・メッセージ：副作用有り、戻り値無し

だったんだけど、関数概念が拡張されて（副作用を許したり）
メッセージも表現出来るようになっちゃった

795 ：デフォルトの名無しさん：2011/07/22(金) 08:48:54.94

>>793

796 ：デフォルトの名無しさん：2011/07/22(金) 08:55:50.38

計算モデルと言語仕様との混同を避けたいなら、最低限でもCTMCPぐらいは読むべし。

797 ：デフォルトの名無しさん：2011/07/22(金) 08:59:49.43

たとえばどのレスが計算モデルと言語仕様との混同してるの？

798 ：デフォルトの名無しさん：2011/07/22(金) 09:05:36.01

ActorやIoとかと違ってSmalltalkではメッセージはファーストクラスではないけれど、
これ↓なんか、Smalltalkにおいてメッセージというものの介在を実感できる良い例だと思う。

ぼくがSqueakかじって結構衝撃的だったのは、「メソッドの定義なんかあとで書けばいい」
「呼んだ瞬間デバッガが怒るからそのときに実装をにょろにょろ書く」
「ていうかコーディングはデバッガの中でするもの」ってスタイルだった。
http://twitter.com/naru0ga/status/93859324388057089

799 ：デフォルトの名無しさん：2011/07/22(金) 09:10:27.11

手続き型でも関数型でもインタプリタ処理系なら
「関数の定義なんて後で書けばいい、関数呼び出しした瞬間デバッガが怒るから」
って言えるじゃん

800 ：デフォルトの名無しさん：2011/07/22(金) 09:16:33.04

>>798
確かにSmalltalkは画期的だね。
妥当な処理構造が最初はサッパリ判らない未解決問題に対しては特に強力。

801 ：デフォルトの名無しさん：2011/07/22(金) 09:23:56.76

気づいたときにSmalltalk使ってたってだけじゃん

802 ：デフォルトの名無しさん：2011/07/22(金) 09:33:12.88

>>799
デバッガが役に立つ、という意味ではそのとおり。
但し、処理構造の実績が無い種の問題の場合は、曖昧な構築を許容してくれる言語がありがたい。

803 ：デフォルトの名無しさん：2011/07/22(金) 09:36:07.55

なんだLisp最強って話か

804 ：デフォルトの名無しさん：2011/07/22(金) 09:36:26.52

コンパイル時にやればいい話

805 ：デフォルトの名無しさん：2011/07/22(金) 11:05:50.34

>>798
関数定義がぬるぽである事がなぜ衝撃的なのかというと
変数と関数をまったく別のものとして扱っているから。
変数なら、たとえ中身がnullでもメッセージ云々という話にはならない。

806 ：デフォルトの名無しさん：2011/07/22(金) 11:33:18.09

>>805
> 変数なら、たとえ中身がnullでもメッセージ云々という話にはならない。

そうだろうか。IoやJavaScriptの始祖であるSELFは変数へのアクセスも
メッセージング（メッセージが嫌いなら動的結合）でやっていたし。
余談だけど、それだと効率が悪いっていうんで、JITとかの最適化などで高速化した成果が
その後、Javaの高速化（HotSpot VM）にも大きく貢献したという。

807 ：デフォルトの名無しさん：2011/07/22(金) 11:36:50.76

>>799
> 手続き型でも関数型でもインタプリタ処理系なら

ほう。Smalltalk ばりにデバッガ駆動開発ができる処理系があったとは驚きだな。
具体的には何？
ちなみに念のため、Smalltalk は Java がそうと言える程度にはコンパイル型だけどな。

808 ：デフォルトの名無しさん：2011/07/22(金) 11:52:28.71

Smalltalk処理系のデバッグ環境がリッチなのは
「呼んだらデバッガが怒るから」なんて理由じゃないってことだろ
そんなことくらい分かれよ低能

809 ：デフォルトの名無しさん：2011/07/22(金) 12:14:33.51

厳密には、メッセージに応答できない（メソッドが見つからない）ときにコールされる
#doesNotUnderstand: というメソッドのデフォルトの振る舞いが例外をあげることであって
この時点ではまだデバッガは起動していないし、まして怒っているわけでもないんだけどね。ｗ

810 ：デフォルトの名無しさん：2011/07/22(金) 12:59:48.20

動的言語なんてスクリプトくらいしか使いどころ無いのに
Smalltalk はそういう用途に使い辛いんだよね。
箱庭で遊ぶだけのおもちゃだからね。だから廃れたんじゃない？
あと開発中にウィンドウ開きすぎｗマウス触らせすぎｗうぜえｗｗｗ

811 ：デフォルトの名無しさん：2011/07/22(金) 13:33:46.54

disる前にもうちょっと勉強しとこうね。

812 ：デフォルトの名無しさん：2011/07/22(金) 21:12:19.54

訳のわからん用語が作られてるな。

デバッガ駆動開発って
BASICみたいなもんか？ｗ

それともIDEのことか？

813 ：デフォルトの名無しさん：2011/07/22(金) 21:13:15.61

C#のデバッグ途中で書き換えおｋみたいな環境のことか?

814 ：デフォルトの名無しさん：2011/07/22(金) 22:04:43.42

その程度の機能は少なくともVC++6.0には既にあった > デバッグ途中で書き換えおｋ
>>807みたいな大口叩く程だからもっと凄い機能のはず

815 ：デフォルトの名無しさん：2011/07/23(土) 00:18:05.39

>>812
コンパイルしてエラーが見つかるより
実行して見つかった方が良いという宗教だよ

816 ：デフォルトの名無しさん：2011/07/23(土) 00:50:02.29

>>813
もちろん、ご指摘の既存のコードの変更や続行は当然として、
例えば Program というクラスも start() という staticメソッドも何も定義されていない状態で
おもむろに Program.start() という式を評価実行してデバッガーを起動、そのままその流れで
必要であると指摘されたクラスやメソッドを都度、適宜新規に定義して続行、という操作を
繰り返してゆくと、組みたいプログラムが組めているとかそんな感じです。

817 ：デフォルトの名無しさん：2011/07/23(土) 00:54:17.87

そのうち必要な操作忘れて未実装のままになるわけですね

818 ：デフォルトの名無しさん：2011/07/23(土) 00:56:27.30

>>815
関数型信者の全く逆方向だな

819 ：デフォルトの名無しさん：2011/07/23(土) 01:09:08.06

>>817
まあ、デバッガ駆動開発とかSmalltalkの動的性の例ってだけで半分はネタだから。
なじみのイデオムやパターンだけで組めそうなときは、たまに流れでやっちゃうけどね。

820 ：デフォルトの名無しさん：2011/07/23(土) 01:15:20.01

>>816
例えば Program というクラスも start() という staticメソッドも何も定義されていない状態で
おもむろに Program.start() という式をバッググラウンドコンパイルして、
エディタ上にでている関数未定義のエラーの箇所のコードを書いていくのと何が違うの？

821 ：デフォルトの名無しさん：2011/07/23(土) 01:38:23.59

続行機能を使うことでコールスタックが実行時のまま維持されるから、
コール時の環境を再現（というかそのものだけど）できる。
そのため、たとえば静的に解決可能なシグニチャの不整合だけじゃなく、
副作用による想定外の事象もシミュレート（てかそのものry）できるとかが違うかな。

822 ：デフォルトの名無しさん：2011/07/23(土) 01:45:54.50

とはいっても、本当に戻したいものはたいてい
ファイルやデータベースなどへの書き込みなので
そればかりはコール時の環境を再現したところで
意味ないんだけどな。

それ以外は再実行すればいいだけの話だし。

823 ：デフォルトの名無しさん：2011/07/23(土) 05:47:38.73

>>815
ヒューリスティックではあるが宗教ではないぞ
型を使う方法も、型エラー以外のエラーは見つけられない一種の近似アルゴリズムだし
それを近似ではないと思い込む人がいると逆に面倒臭い

824 ：デフォルトの名無しさん：2011/07/23(土) 09:07:46.03

>>821
たしかにコンパイル通るまでデバッグモードに入れないけど、
コンパイル通らないレベルじゃコールスタックとか見る必要無い

825 ：デフォルトの名無しさん：2011/07/23(土) 09:56:05.49

>>823
一番痛いのは、完璧ではないから無駄だと考える人だろう。

人間に時間が無限にあれば別だが、そんなことはありえないので
いろんな技法・コンピュータを使い、エラーを人間ではなく
コンピュータに見つけてもらうように、様々な対策をする。

そうやっても完璧にはならないと、全部人間がやるというふうに
極端な結論を出すやつが一番痛い。人間がやったって完璧にはならんだろうにな。

0にならなくとも、人間の手間は減らしたほうが楽。

826 ：デフォルトの名無しさん：2011/07/23(土) 09:57:32.89

いきなりどうしだ

827 ：デフォルトの名無しさん：2011/07/23(土) 10:50:24.15

>>825
結論は出さないで様子見すればいいんだが
結論は早いほうが良いなんて誰が言った？

828 ：825：2011/07/23(土) 11:24:50.68

> 結論は早いほうが良いなんて誰が言った？
少なくとも俺は言ってないが、
本当に誰が言ったんだ？ｗ

829 ：デフォルトの名無しさん：2011/07/23(土) 12:59:20.68

>>824
そこはちょっとSmalltalk、というかメッセージングの（メッセージのメタファが嫌いなら
徹底した動的結合の―）パラダイムは特殊で、コンパイルといってもリンクは実行時の
ぎりぎりまでする気がないので、メソッド単位で本当の意味でインクリメンタルなコンパイルが
通るようになっています。だから次にコールするメソッドがまだなくても、コールするまでは
普通に実行できるわけです。このデバッガー駆動開発を、メッセージと普通の関数コールとで
何が違うかの端的な例として出したときの意図はそれでした。

830 ：デフォルトの名無しさん：2011/07/23(土) 13:33:29.63

メソッドがない状態で、実行して何が嬉しいのかわからない。

そもそも実装がないのなら、その関数の呼び出しを
コメントアウトでもしていれば済む話だろう。

831 ：デフォルトの名無しさん：2011/07/23(土) 13:41:30.87

例えば、それこそ、デバッグ時にコードを変更してそのまま続行できるって機能を
ものすごくシンプルに実装できるとか、は嬉しいうちには入らないですかね。

832 ：デフォルトの名無しさん：2011/07/23(土) 13:46:47.83

通常はそのまま実行する → あ、間違えた → 最初から再実行となる。

間違った処理を途中まで動かしておいて、
その処理を途中で変更したのに、続きから
再開できることは殆ど無い。

どうせユニットテストのためのコードを書くので
何度でも簡単に最初から再実行可能なものができあがる。

だから嬉しくない。

833 ：デフォルトの名無しさん：2011/07/23(土) 13:49:42.79

http://hibari.2ch.net/test/read.cgi/tech/1293264747/
次スレですよ。おっさんども！

834 ：デフォルトの名無しさん：2011/07/23(土) 13:58:26.86

>>832
ホットデプロイとか興味ないん？

835 ：デフォルトの名無しさん：2011/07/23(土) 14:25:50.90

>>834
ホットデプロイは遅くて面倒。

あれはデバッグ時に最終的な手段として使うもので、
通常の開発時はウェブサーバーしなくていい方法で
個々のパーツで開発作成テストしていく物。

状態が不確定のところから実行してもテストにはならん。
なんども最初の状態（どういう状態であるか分かっている所）から
やり直せることが重要。

836 ：デフォルトの名無しさん：2011/07/23(土) 14:39:31.63

なるほどねぇ…。
なんか自分のTDDに対する違和感の出どころがちょっとわかったようなきがした。

837 ：デフォルトの名無しさん：2011/07/23(土) 15:13:13.15

ソフトウェアの開発ではトップダウンなやり方と
ボトムアップなやり方を組み合わせて開発する

トップダウン的なやり方を使うときはアプリ全体の構造、
どういうパーツをどう組み合わせてなどの設計の部分。

この段階では、各パーツは完成していないので動かないし動かす必要もない。
だから関数呼び出しなんてただの日本語コメントで十分。

その後でボトムアップで各パーツを作る。各パーツはテストしやすいように
単体で動くように作る。テストコードからパーツを呼び出しテストをする。

そして関数は完成。そしたら、それをコメントの部分に組み込んで統合する。
この時の統合用のコードは最小限になるようにする。

このやり方が一番早く安全に作れるし、そしてこのやり方をする限り
「動かしながら書く」というやり方にはメリットを感じられなくなる。

ブラウザ（ウェブアプリの場合）や、GUIを人間が操作しながらテストをするやり方は、
人間が操作する時間の分遅いし、また最初からやり直すためにスタート地点から
同じ操作を何回も繰り返すはめるなる。普通のプログラマならストレスを感じるはずだ。

838 ：デフォルトの名無しさん：2011/07/23(土) 16:12:32.27

どうせ最初から繰り返さないといけないんだから小さなサイクルにした方が賢い、ってことなんだろうね。

ただアラン・ケイ的にはちょっと違ってて、どうせ完成なんかしない＆設計なんて後から変わるんだから、
動かしながらやれるようにしようよ、って。そんな風に作られているのが（暫定ダイナブックOSとしての）Smalltalk。
おそらく、それが活きてくるシステムの規模とか運用スパンとか、そもそも問題領域が違うのだろうなとも。

839 ：デフォルトの名無しさん：2011/07/23(土) 16:31:19.96

「動かしながら」の意味が違ってる。

アラン・ケイの時代はOSというものがまだ確立されてない時代で、
smalltalk一つでOS含めた環境全体をつくろうとしていた。
アプリはシステム全体のプラグイン的な扱いだった。

その時の感覚の「動かしながら」というのは、
今で言うならOSを動かしながらアプリを作るということ。
OSを再起動しないで新たにアプリを作って起動しようという意味。

840 ：デフォルトの名無しさん：2011/07/23(土) 16:43:09.49

そう、完全にくいちがっているな。

今でいうなら、OSを動かしながらそのOSを作り続けるということ。
OSを再起動しないで新たな設計で一部、あるいは必要なら根幹をも組み直してなお
動作を続けられるという意味。

「ソフトウェア工学」は矛盾語法か？
http://metatoys.org/oxymoron/oxymoron.html

841 ：デフォルトの名無しさん：2011/07/23(土) 17:13:00.46

目的無しでプログラム製作開始なんてできるの　smalltalkに限らず　そんなアプローチで何が作れるというのか？

842 ：デフォルトの名無しさん：2011/07/23(土) 17:31:43.12

目的無しってことはないと思うけどな。どうしてどこからそう思ったのだろう。

作り始めるときは、その時点で適切だと考える設計とか仕組みとかがあるはず。
ただ、ケイが指摘するのは多くの場合、特にシステムの規模が大きく、製作や運用が
長期に及ぶ場合、当初の考え方の通りにはいかないことがあるってこと。
そんなときに、間違えたじゃあ最初からやり直しって訳にはいかない局面もあるって話。

843 ：デフォルトの名無しさん：2011/07/23(土) 17:38:18.88

ケイのは時間、システムの規模ともにスケールがでかすぎるのでピンと来にくいけれど
shiroさんが最近書いてたこんなのならどうだろうか。

動的型のメリットは「決断の遅延」かもしれない
http://blog.practical-scheme.net/shiro/20110719-dynamic-typing

844 ：デフォルトの名無しさん：2011/07/23(土) 17:44:41.65

そこに書いてあることは動的言語のメリットじゃないと思う。
プログラムは完成してなくてもβ版やバージョンアップって普通にあるし。
静的でビルドアップ的な開発ができないかというとそうではないし。

845 ：デフォルトの名無しさん：2011/07/23(土) 18:09:40.64

>>842
そん時は時間があるのなら、
新しい設計のものに作り替えればいいだけでしょ？
時間とか金額とかそういう話はあるが、
技術的に言えばそれができないものは無いはずなんだが。

846 ：デフォルトの名無しさん：2011/07/23(土) 18:11:14.14

だけでしょといえば強くなれる気がした１５の夜

847 ：デフォルトの名無しさん：2011/07/23(土) 18:18:08.18

なんだかんだこのスレは色んな話題があって面白いなｗ

848 ：デフォルトの名無しさん：2011/07/23(土) 18:40:58.94

>>846
満足した？

849 ：デフォルトの名無しさん：2011/07/23(土) 18:43:14.66

設計がまずかったとき、それを作り直すために
アプリを動かしながらアクロバット的に
コードを変えていく。

なんてことする必要あるのか？

まあ修正するときに絶対バグを入れないと
自信があるのなら、動かしながらやってもいいが、
普通は一時的にサービス停止して入れ替えるでしょ。

850 ：デフォルトの名無しさん：2011/07/23(土) 18:48:03.75

設計がまずかったときは止めるだろうけど
機能拡張するときにとめずにできるんならやりたいでしょ。
Erlangはそういうの売りにしてた気が。

851 ：デフォルトの名無しさん：2011/07/23(土) 19:10:16.07

> 機能拡張するときにとめずにできるんならやりたいでしょ。

いや、そういう場合は別で作っておいて、
完成してリリースするときに切り替えればいいだけだから・・・。

852 ：デフォルトの名無しさん：2011/07/23(土) 19:15:49.91

それがアクロバット的でない世界があってもいいでしょ的な話は通じにくい
クラスタですか？もし、そういう事がごく普通にできる処理系があったとして
どんなメリットがありそうか、とか。もっともそれがシステムとしてのSmalltalkが
かつて目指したところなわけだけれども。

853 ：デフォルトの名無しさん：2011/07/23(土) 19:24:09.95

構想ばかりでかくなって、実は誰も求めていない
（他の方法で代用できる）っていい例だな。

854 ：デフォルトの名無しさん：2011/07/23(土) 19:34:25.95

まあ確かに、世のパソコンは結局Smalltalkではなく、肝心な本質以外の副産物の切り売りで出来ているしな。
WINPなGUIしかり、MVCとかのAPIのOO設計しかり、コピペとか右クリックとかの操作体系しかり。

855 ：デフォルトの名無しさん：2011/07/23(土) 19:38:29.14

そりゃなｗ

ソフトウェアというのは人間を楽にするために
人間が作っているということを忘れてはいけない。

そう考えるとむしろそっちが本質かもしれんな。

856 ：デフォルトの名無しさん：2011/07/23(土) 19:47:42.31

より楽する為により苦労する

857 ：デフォルトの名無しさん：2011/07/23(土) 20:42:48.90

“真理がやって来て扉を叩くと、「あっちへ行け、私は真理を求めているのだ」と人は言う。
だから真理は立ち去ってしまう。不思議なことだ。” - 禅とオートバイ修理技術

858 ：デフォルトの名無しさん：2011/07/23(土) 20:50:09.56

ポエマーきもっ

859 ：デフォルトの名無しさん：2011/07/23(土) 21:10:56.75

愛・おぼえていますか

860 ：デフォルトの名無しさん：2011/07/23(土) 21:21:17.29

有償サービスをとめりゃいいでしょって

861 ：デフォルトの名無しさん：2011/07/23(土) 21:22:37.74

誰が止めるって言ったんだ？

新旧二つ起動して
切り替えればいいって話だったと思うが？

862 ：デフォルトの名無しさん：2011/07/23(土) 22:11:45.19

いつのまにか静的型 vs. 動的型になっとるw
お前等本当にこのネタ好きだなwww

まあメッセージが云々みたいなオブジェクト指向ポエムより面白いのは認める

863 ：デフォルトの名無しさん：2011/07/23(土) 22:13:50.51

それホットスワップ

864 ：デフォルトの名無しさん：2011/07/23(土) 23:57:22.39

>>843
これねー。読んでると鵜呑みしそうになるんだけど、ちょっと違うと思う。
要は、システムってのはインターネットみたいなもので、メッセージを投げ合って
協調動作する生態系のようなものだ、って書いてある。
だけどそれはハードウェアの仕様からそうなったってのもあるだろ。

コンピュータは直接他のコンピュータの中を覗くことは出来なんだから、
特定のプロトコルでメッセージを投げ合ってコミュニケートする他ない。
だからどうやっても神の視点は持てない。

一方でCPUに目をやると、例えば足し算するにしても、
足される二つのオペランドが両方レジスタに乗ってる丸見えの状態でないと
計算できない。
だからどうやっても神の視点「しか」持てない。

インターネットのサーバのプログラムは、古典的なC言語で書かれたりするわけでさー。

865 ：デフォルトの名無しさん：2011/07/24(日) 00:08:09.85

だから、複数のコンピュータがつながってシステムを成していたり、
マルチプロセスで協調動作しているようなシステムは、
まさにオブジェクト指向的だし、生態系的なんだけど、
その中のプログラムにまでそのモデルを適応するってのは違うと思う。
CPUは神の視点でしか計算できないし、オブジェクト指向のようなものでもないから。
一辺倒なモデルでは対応できない。
どのレイヤーで切り替えるのかって問題が付いて回る。

典型的なUNIXのシステムだと、プロセスは構造化的にC言語で書いて、
それ以上のレイヤーのプロセスとプロセスのコミュニケートには、
ソケット使ったりするよね。

866 ：デフォルトの名無しさん：2011/07/24(日) 00:23:10.26

OpenCLではメモリが共有できなくなるモデルに回帰してる

867 ：デフォルトの名無しさん：2011/07/24(日) 00:26:56.29

>>865
神の視点の話があるから>>840？

>その中のプログラムにまでそのモデルを適応するってのは違うと

まあ「全てのアイデアの為のモデルとモデリング」でケイ自身も「極端なアイデア」だと
のっけからことわっているからねぇ。でも、あえてこうした極端アイデアの適用があったからこそ、
古くはGUIやデザパタ、最近ではTraitsやClassboxesが培われたのがSmalltalkでありえたわけで。
全部がそうあるべきではないにせよ、そういう極端なシステムもあっていいじゃないかと。

868 ：デフォルトの名無しさん：2011/07/24(日) 05:37:13.29

プログラムの場合はオブジェクト指向でも中身を知らないとメッセージ送れないけどそれは何か問題になるの？

869 ：デフォルトの名無しさん：2011/07/24(日) 09:16:32.98

え？

870 ：デフォルトの名無しさん：2011/07/24(日) 09:22:44.91

そこは考え方ひとつで、例えばSmalltalkのオブジェクトには隠し事はない事になっていて
知りたいと伝えれば誰でもその中身を教えてもらうことができます。したがって、
送るメッセージが分からないといった状況は（神の視点による特殊な細工さえ無ければ）
想定しなくてよいわけです。

「直接覗き見するのは神の視点、メッセージを介して同意を得ればOK」というスタンス
ですね（ブートストラップ問題はこの際無視します）。

871 ：デフォルトの名無しさん：2011/07/24(日) 09:55:19.82

>>870
C++とかJavaでオブジェクト指向を使ってる人はSmalltalkについて誤解しやすいと思う。
Message-Passing Concurrencyが肝。

872 ：デフォルトの名無しさん：2011/07/24(日) 10:11:01.02

Smalltalkで使われているメッセージは
ウインドウメッセージのことと考えればいい。
もしくはRESTとかね。

873 ：デフォルトの名無しさん：2011/07/24(日) 10:31:10.50

気持ちとしてはそうですね。

ただまあ「Concurrency」とまで言ってしまうと実装が追いついてなくて（あくまで暫定実装ゆえに）
かえって混乱を招きそうなので、（というのも、C++はともかくJavaとは使っている仕組みはほぼ変わらないわけなので）
そこは設計者も利用者（プログラマ）も、アクセス演算子など（つまり神の視点）は介在させず、すべてを
例外なくメッセージで行なう「縛り」があると思いなせぇ的世界観を楽しむある種のなりきりプレイだと
考えるのが良いでしょう。この種の縛りを設けることのメリットは>>840などでケイがまとめています。
コードもライブラリの設計も、すべてこの縛りでやってみようよという試み。それがSmalltalkというわけです。

身近な例として、Smalltalkには抽象データ型ＯＯ向けの言語にあるクラスはないことになっています。
それはクラスのように振る舞うよう仕立て上げられたオブジェクトにすぎない、と考えるわけです。
（で、実際その感覚に近くなるように実装されています。）

874 ：デフォルトの名無しさん：2011/07/24(日) 11:06:21.80

もちろんこの「プレイ」はC++やJavaなど、抽象データ型ＯＯ向けの言語でも可能です。
ただSmalltalkと違い、言語やライブラリ設計者までを巻き込んでいるわけではないので、
あくまでユーザーサイド限定の遊びになり、おのずと（Smalltalkに比べれば）制約も多く、
徹底も難しいものとなります。

当然、同じようなことはSmalltalkのようなメッセージングＯＯ向けの言語で、あえて抽象データ型のＯＯを
実践しようとした場合にも言えます。C++やJavaでできることに比べれば、意識してそのための仕組み
（例えば private などのアクセス制限や静的型チェックなど）を設けない限り、かなり限定的に
なってしまうのは必然です。

こうしたパラダイムの違いを踏まえておかないと、すぐに言語間宗教戦争が始まってしまいます。

875 ：デフォルトの名無しさん：2011/07/24(日) 12:45:55.65

神の視点ってグローバル変数だよね
ローカル変数はレジスタにアドレスを置いて間接参照するよね

アドレスって、なにかをどこかに送る宛先のことだよね

876 ：デフォルトの名無しさん：2011/07/24(日) 12:49:18.53

プログラムの本質的には
グローバル変数でも何ら問題はない。

人間のためにプライベート変数というものができた。

877 ：デフォルトの名無しさん：2011/07/24(日) 13:26:35.81

メッセージング（OOP）の特徴と動的型付けの特徴が混じっとる

878 ：デフォルトの名無しさん：2011/07/24(日) 13:49:35.44

部分型を認めると動的型が混じる。
部分型が完璧でないからといってそれが無駄だとは限らない。

879 ：デフォルトの名無しさん：2011/07/24(日) 14:51:32.24

クラスと型は違うものって本当？クラスって型じゃないの？

880 ：デフォルトの名無しさん：2011/07/24(日) 16:11:27.53

>>879
そんなもん考え方次第だろ
明確な定義があるわけじゃないんだから悩むだけ無駄

881 ：デフォルトの名無しさん：2011/07/24(日) 17:25:56.16

>>875
違うと思う。
func( obj1, obj2 );
のとき、funcはobj1とobj2を対等に扱う。これが神の視点。神の視点=制御構造視点。
obj1.method( obj2 );
のとき、obj1がmethodを実行する。オブジェクトが処理を実行するから神の視点は存在しない。

882 ：デフォルトの名無しさん：2011/07/24(日) 18:25:16.85

何言ってんだ？
お前の中ではcallerは神なのか？

883 ：デフォルトの名無しさん：2011/07/24(日) 18:52:20.73

>>879
C++やJavaなどが得意とする抽象データ型のＯＯではクラスは型です。
そもそも、抽象データ型のＯＯではクラスを使って型を定義すればいいじゃん、
というアイデアがもとになっています。ただクラスを型にするといろいろと問題がおこることが
'80年代の終わり頃に指摘され、Javaのインターフェイスのような代替機能が考え出されました。

一方で、Smalltalkなどが得意とするメッセージングのＯＯでは、クラスは型とは考えません。
そもそもこのパラダイムではデータ型というものをあまり意識しません。すべてがオブジェクトですね。
クラスのような働きをするオブジェクトも存在しますが、1)インスタンスの生成器、2)メッセージの移譲先
という二つの役割を主に担います。

884 ：デフォルトの名無しさん：2011/07/24(日) 20:03:50.98

すべてがオブジェクトですね。
↓
すべてが型ですね。

こう言い換えるとすっきりくる。

885 ：デフォルトの名無しさん：2011/07/24(日) 21:09:28.61

Smalltalkは大抵のものはオブジェクト（クラスやコードブロックすら）だが
残念ながら型はファーストクラスのオブジェクトじゃない

886 ：デフォルトの名無しさん：2011/07/24(日) 21:18:55.99

Gallinaのことかー！！

887 ：デフォルトの名無しさん：2011/07/24(日) 21:33:36.47

>>885
でも他の処理系と違って型（インターフェイス）を勝手実装して導入することは簡単。

http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-5_1.html

888 ：デフォルトの名無しさん：2011/07/24(日) 21:43:18.74

Smalltalk信者は気持ち悪い

889 ：デフォルトの名無しさん：2011/07/24(日) 22:58:33.19

アランケイみたいな馬の骨の言うことに耳を傾けちゃうような連中ですから

890 ：デフォルトの名無しさん：2011/07/25(月) 00:37:13.57

馬の骨を超えるもんを作れない人が殆どだけどな。

891 ：デフォルトの名無しさん：2011/07/25(月) 03:14:02.28

Smalltalk教の人には、ものすごい理屈っぽい人が多いけど、
そうでもしないとやってけないんだろう。
現実主義者とは対極の何かなんだろう。

892 ：デフォルトの名無しさん：2011/07/25(月) 05:54:04.22

記憶力に限界を感じて理屈を使うようになる人と、
現実は記憶しなくてもそこにあるから何も記憶しない人に分かれる

893 ：デフォルトの名無しさん：2011/07/25(月) 05:54:53.85

現実主義者は人間ってことを重視しているからね。

人間は間違える。だから間違えが起こりにくい仕組みを作る
人間は覚えられない。だから各部分をモジュール化する。

こういうのはオブジェクト指向にとっては必須ではないが、
人間重視だと必須なんだよ。

894 ：デフォルトの名無しさん：2011/07/25(月) 06:06:31.19

でもオブジェクト指向言語的な纏め方をみてしまうと
それもない気がするな

すごく複雑に１箇所にまとまってるよりは
単純に１００箇所コピペで貼ってあったほうが修正しやすいよ

作業見積もりも定量的だから簡単だしね

俺らはマイクロソフトの技術者（ライブラリ開発者的意味で）じゃないんだ
適切な開発手法を間違えちゃいけない

895 ：デフォルトの名無しさん：2011/07/25(月) 06:23:02.81

>>894
単純に100箇所ではなくて複雑に100箇所修正することになるから問題なんだろ

896 ：デフォルトの名無しさん：2011/07/25(月) 09:03:16.16

お前らこの程度で理屈っぽいなんて
Scala信者とかやってきたらいったいどうするつもりだ？ｗｗｗｗ

897 ：デフォルトの名無しさん：2011/07/25(月) 09:05:34.58

やつらプログラマじゃないし

898 ：デフォルトの名無しさん：2011/07/25(月) 09:21:16.31

Smalltalkは別にいいんだ。ただの言語のひとつにすぎない。
やっかいなのはSqueakを薦める信者。これはいただけない。
あんなの両生類のクソを集めただけの価値しかないから。

899 ：デフォルトの名無しさん：2011/07/25(月) 11:24:04.62

>>895
そんなのなるわけないだろ
コピペできないじゃん

900 ：デフォルトの名無しさん：2011/07/25(月) 11:28:38.07

アーキテクチャ宇宙飛行士 vs デジタル土方

901 ：デフォルトの名無しさん：2011/07/25(月) 12:49:19.87

>>896
Scala信者ってどう痛いの？俺は奴等の恐ろしさを知らない

902 ：デフォルトの名無しさん：2011/07/25(月) 13:35:16.41

>>901
みずなんとかさんのことだろう。

TLでScalaをdisったpost 見かけたんだけど、死者を出さないために何回も言ってるんだが、
Scalaな人怒らせると理屈でねじ伏せてくるから気をつけなよホント。複雑って言ったら、
FUDだってキレて鎮圧のためにMatzまで出てきたし…マジでScalaには手を出さない方がいいぞ…

903 ：デフォルトの名無しさん：2011/07/25(月) 13:41:56.35

>>902
おれあれで scalaに興味を持ってたけど覚めちゃった。それでhaskellのほう
やっとります。

904 ：デフォルトの名無しさん：2011/07/25(月) 15:18:02.21

>>902
togetterまとめないの？

905 ：デフォルトの名無しさん：2011/07/25(月) 15:23:42.89

>>898
Pharoもやっぱりクソ？

http://www.smalltalk-users.jp/Home/gao-zhi/dai32kaismalltalkbenkyoukai

906 ：デフォルトの名無しさん：2011/07/25(月) 18:02:30.57

ちょっと前にも騒ぎがあったみたいね。
http://togetter.com/li/164700
どんなのかしらんが

907 ：デフォルトの名無しさん：2011/07/25(月) 18:23:46.37

ちょっと興味本位でWiki見てきたが、

>1.汎用言語はスケーラブルでなくてはならない。
>同じ概念で、小さいプログラムも大きなプログラムも記述できるべきである。

あー俺これダメだわ。性に合わない。
プログラムの構造はハードウェアの構成の影響をモロに受けるから、
スケーラブルなんて意識するだけ無駄だと思う。
というか、現実世界にスケールしろよって思う。
メモリに載り切らないのなら、メモリマップ使うだろうし、
RDB使うのなら、それ相応の制限も受けるし、
そんなの現実世界にスケールしてはじめて決まること。

908 ：デフォルトの名無しさん：2011/07/25(月) 18:31:20.11

メモリにだけ注目しても、
レジスタ→キャッシュ→プロセス空間固有の仮想メモリ→物理メモリ→ハードディスク→ネットワーク
こんなだぜ？
>同じ概念で、小さいプログラムも大きなプログラムも記述できるべきである。
なんて言われてもなぁ。
受ける制限が粒度粒度で異なるのに、同じ概念で記述「するべき」である、とか、ねぇ。
「した方が良い」、ならまだかわいげもあるが。
教授様はこれだから困る。

909 ：デフォルトの名無しさん：2011/07/25(月) 18:48:54.02

だから、変なサンプルプログラムをドヤ顔で見せられても、まったくスケール感が無いんだよね。
まるでガンダムのプラモデルを見せられているよう。
確かにあのスケールならプラスチックの材質で自重を支えられるだろうが、
実スケールだと無理だろう。構造や材質を変える必要がある。
プラモデルですら、スケーラビリティーなんて無いんだよ。
軽トラをそのまま拡大しても10トン車にはならない。
周りの環境までひっくるめて拡大される訳ではないからね。
重力加速度とかは大きかろうが小さかろうが一定な訳で、
スケール変えるとその辺の係数がずれてくる。
プログラムも同じで、プログラムのモジュールが拡大縮小出来ても、
環境まで、つまり、ハードウェアまで拡大縮小する訳ではないからね。
まーそこが飯の種でもあるわけで。

910 ：デフォルトの名無しさん：2011/07/25(月) 19:09:42.49

>>909
scalaスレがあるからあっちでかいてみ～。>>902の意味が実感できるかも

911 ：デフォルトの名無しさん：2011/07/25(月) 19:32:27.29

それはwktk！　忙しいなら代わりにコピペしておいてやろうか？ >>909

http://hibari.2ch.net/test/read.cgi/tech/1307416864/

912 ：デフォルトの名無しさん：2011/07/25(月) 19:40:09.21

ちらっと覗いてみたら「ただでは帰さんぞ」とか言ってワロタｗ

913 ：デフォルトの名無しさん：2011/07/25(月) 20:24:51.32

俺もそのフレーズにスゲー笑ったwww
>>902は真実だった

914 ：デフォルトの名無しさん：2011/07/25(月) 21:00:36.74

彼らをこちらに引きこむって方法もあるかもよ～

915 ：デフォルトの名無しさん：2011/07/25(月) 21:16:16.07

http://twitter.com/#!/search/scala%20%E6%80%96%E3%81%84

916 ：デフォルトの名無しさん：2011/07/25(月) 21:44:10.56

>>909
> 構造や材質を変える必要がある。

プログラミング言語でその「構造や材質」に相当するのは何？

917 ：デフォルトの名無しさん：2011/07/25(月) 23:03:38.96

アルゴリズムとデータ構造でしょ。

918 ：デフォルトの名無しさん：2011/07/25(月) 23:17:49.29

データがでかすぎるから一気には読み込めないなぁとか、
必要なものがネットワークの向こうに有るから、直接は読めないなぁとか、
まともな時間で応答できないから前処理が必要だなぁとか、
こういった問題は、現実世界にスケールを合わせて、初めて浮上してくる。
だから、
>同じ概念で、小さいプログラムも大きなプログラムも記述できるべきである。
「べきである」なんてことは無い。
せいぜい「そうだといいなぁ」程度の話。
でも、そうならないから、飯の種になってる。
ソフトウェア業界だけじゃなく、全ての業界でそう。
現実とのすりあわせで皆飯食ってる。

919 ：デフォルトの名無しさん：2011/07/26(火) 06:32:53.81

>>918
そのべきとかそうだといいなぁっていうのは原文かわからないとなんともいえないかと
訳のニュアンスによる

920 ：デフォルトの名無しさん：2011/07/26(火) 08:37:34.04

アルゴリズムとデータ構造を変更する必要があるだけなら
言語ごと換える必要無いがな
そりゃ、言語の記述力が低くて上手くアルゴリズム/データ構造を
定義できないなら換える必要あるかもしれんが、
Scalaが他言語と比べて殊更disられる必要があるほど低いのかい？
少なくともJava辺りと比べりゃマシなんじゃないの？後発言語なんだし

921 ：デフォルトの名無しさん：2011/07/26(火) 18:29:15.01

すごいな　ここ　馬鹿スレじゃねぇじゃねぇか　ｗ
ところで　学校でOOPって授業で教えるの？

922 ：デフォルトの名無しさん：2011/07/26(火) 20:24:12.82

>>921
うちはJavaは習ったけどOOPとして習ったという感じはない
ただJava文法を習ったという感じ
大半が手続き型と変わらないようなソースを書いて卒業する

923 ：デフォルトの名無しさん：2011/07/26(火) 21:10:30.45

>>884
> すべてがオブジェクトですね。
> ↓
> すべてが型ですね。
>
> こう言い換えるとすっきりくる。

型ってのは値の集合だから、
君の言い換えを実行に移すと
「全ての集合を要素とする集合」
ってのを定義しなきゃならないのだが、

そいつは定義しちゃいけないんだぜ。

924 ：デフォルトの名無しさん：2011/07/26(火) 21:22:47.55

rank nの型の型はrank (n+1)みたいなものを導入した後
nを隠すとラッセルさんがおとなしくなります

925 ：デフォルトの名無しさん：2011/07/26(火) 21:31:24.18

集合はスケーラブルでなくてはならない。
同じ概念で、有限集合も無限集合も記述できるべきである。

926 ：デフォルトの名無しさん：2011/07/26(火) 21:43:20.90

ただでは帰さんぞ

927 ：デフォルトの名無しさん：2011/07/26(火) 22:17:56.83

通行料とるの？

928 ：デフォルトの名無しさん：2011/07/27(水) 10:16:23.66

この手のOOPスレでは抽象データ型OOPよりも
メッセージング型OOPの方が優れているという論調になりがちだけど
本当にそうだとしたら、何故普及しないんだろう？

929 ：デフォルトの名無しさん：2011/07/27(水) 12:37:29.79

>>928
適応的なものが普及するとは限らないから、
qwertyキーボードがよく例としてあげられているけど、
あれは、決して打ちやすい配列ではなくて、タイプらインターの
チャタリング防止から作られた配列。それが今まで生き残っている。
それと同じ事なんだろうな。JavaやC++が中心となってしまったわけだからね。

930 ：デフォルトの名無しさん：2011/07/27(水) 12:45:21.81

普及していないのだから優れてなどいないのだ。と言いたい？

931 ：デフォルトの名無しさん：2011/07/27(水) 13:24:13.99

複数のプログラミング言語を駆使してる者なんて、世界人口の１％もいないのに、その中でのシェア争い。

932 ：デフォルトの名無しさん：2011/07/27(水) 13:37:51.06

>>928
暫定実装（つまりコスト高でちゃんとは作れない）でありつづけるSmalltalkの存在からも自明だけど
メッセージングの（あるいは、徹底した動的性を目指す）OOは、いろいろな意味でコスト高だから
百歩譲って良い物だと分かっていても簡単には普及しえないはず。たまたまそうしたコストを
度外視できる恵まれたシチュエーションにおいてだけ成果をあげられていて、偶然それを目にする
機会を得た人が褒めそやしたりするから「あれはいいものだ」的な雰囲気を醸すとかそんな感じかと。

他方で、さほどコストをかけずに導入できる部分は、抽象データ型OOのメリットを損なわない、
あるいは、いくらかは損なったとしても最小限にとどめるかたちに変換されて、
それと気付かないだけでそれなりに普及している、あるいは普及しつつあるのではない？
古くはデザパタ、OO設計のGUIやAPIだとか、最近ではアジャイルな手法だとか。

933 ：デフォルトの名無しさん：2011/07/27(水) 14:01:48.07

>>928
メッセージング型はマルチパラダイム化しやすいことに意味があるから
純粋なメッセージング型などといったものは普及しない

934 ：デフォルトの名無しさん：2011/07/27(水) 16:32:49.73

>>932
メッセージ型のはどういうところが動的で、抽象型はどういうところが静的なの？
smalltalkを一切知らない俺に教えて

935 ：デフォルトの名無しさん：2011/07/27(水) 18:20:42.79

>>928
速度と型安全神話じゃね。
Objective-Cなんかはその折衷案を上手いことやってる。
メッセージだらけにすると、コンパイル時に決定できる事を
実行時にやるんでどうしてもRubyみたいに遅くなる。

936 ：デフォルトの名無しさん：2011/07/27(水) 18:58:36.57

>>934
発案者であるアラン・ケイが書いたこの文書は読まれましたか？
メッセージングのOOの成果と、特にその動的性やメタ性について
よくまとめられています。

「ソフトウェア工学」は矛盾語法か？
http://metatoys.org/oxymoron/oxymoron.html

もしSmalltalk（Squeak）を引き合いにした例でイメージしにくいところや
抽象データ型のOOPL（文書中では早期結合なシステム）との対比で
わかりにくいところがあったら言ってください。

あと、抽象データ型OOとの違いについて、とくに抽象データ型の考え方とは
一線を画している点（しかし、型システムに反対するわけではないなど）
については、こちらに言及がありますので参考にされるとよいと思います。

Dr. Alan Kay on the Meaning of “Object-Oriented Programming”
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

937 ：デフォルトの名無しさん：2011/07/27(水) 19:19:24.74

そういえば、アラン系って宝塚にもいたな。

938 ：デフォルトの名無しさん：2011/07/27(水) 19:48:44.26

>>935
> メッセージだらけにすると、Rubyみたいに遅くなる。

こらこら。Rubyが遅いのは
今の実装にたまたま問題が多いからなだけで、
動的だからといって通常ならあんなには遅くはならない。

事実、Rubyよりはるかに動的なJavaScriptとかでも
普通にRubyからすれば爆速な実装は存在する。
（例えばV8であれば、Cと同じか数倍程度。処理によってはCより速い）

939 ：デフォルトの名無しさん：2011/07/27(水) 19:53:45.16

まあIMP使った方が速い（関数呼び出しはもっと速い）のは事実だな

940 ：デフォルトの名無しさん：2011/07/27(水) 20:05:47.20

そりゃまあね。
ただ「動的だから遅い」の例に
無駄に遅いRubyを持ち出すのはやめたほうがいい。

941 ：デフォルトの名無しさん：2011/07/27(水) 21:03:04.72

動的＝遅いというのは思い込みだからね。Common Lispのような
動的言語は速くできる。

942 ：デフォルトの名無しさん：2011/07/27(水) 21:24:32.88

でた！Cより速いｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
はｗｗｗｗｗｗｗｗｗやｗｗｗｗｗｗｗｗいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

943 ：デフォルトの名無しさん：2011/07/27(水) 22:11:19.52

最近のＰＣより俺の筆算のが速い
なんでどのアプリもあんなに起動がもっさりになったの？

944 ：デフォルトの名無しさん：2011/07/27(水) 22:21:34.66

Cより速いってどういう理屈？

945 ：デフォルトの名無しさん：2011/07/27(水) 22:44:29.37

>>944
例えばifやswitchといった分岐で実質進路が固定されてる物とかじゃね？
function call(x)
{
    for(;;)
    {
        if(x){・・・・}
    }
}
こういうコードだとforの実行中はifが必要なくなる。
どっちかっつうとOOよりJITの話になるとは思うけど。

946 ：デフォルトの名無しさん：2011/07/27(水) 22:51:07.86

>>942 変な奴に絡まれたな。

947 ：デフォルトの名無しさん：2011/07/27(水) 22:52:50.64

>>944
ベンチマークサイトを見ると、
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc

この中で唯一 JavaScript V8 が C Gnu gcc に勝ってるのは
regex-dna で、これは正規表現の性能を計ってる
多分 V8 の正規表現エンジン（C++）の実装が良いんじゃね？

# ちなみにCの方はTclの正規表現エンジンを使ってる
# Tclは正規表現は速いからなw

948 ：デフォルトの名無しさん：2011/07/27(水) 23:02:36.35

>>944
strlenは遅いとかqsortは遅いという理屈がある
つまり標準ライブラリと、必死に最適化した別のライブラリを比較するんだ

949 ：デフォルトの名無しさん：2011/07/27(水) 23:04:42.68

gccなんかと比べる時点でだめだろ。浮動小数点だとvcの数倍遅い

950 ：デフォルトの名無しさん：2011/07/27(水) 23:07:00.67

時々チートくさい速さを見せるiccさんもいるぜ

951 ：デフォルトの名無しさん：2011/07/27(水) 23:14:46.46

Cで負ける要素ってJITでのクリティカルな効果とポインタのエイリアスくらいしか知らない

952 ：デフォルトの名無しさん：2011/07/28(木) 03:01:12.93

どこにカキコしようかと思ったけど、
オブジェクト指向の場合の話題ですってことを強調したいので
ここに書きます。

たとえばあるオブジェクト($object)があったとして

$object->load()というメソッドは
$objectとは別の新たな$objectを生成すべきでしょうか？
それとも$object自身を変更すべきでしょうか？

同様に、$object->save()を実行したら
$objectの中身を保存すべきでしょうか？
それとも$object->save(値)という使い方をし
値を保存すべきでしょうか？
それとも引数があれば引数の値を保存し、
なければ$objectを保存するようにすべきでしょうか？

953 ：デフォルトの名無しさん：2011/07/28(木) 03:11:10.97

場違いなのが迷い込んできたな、ここは馬鹿じゃないと書き込んじゃいけないからwww

954 ：デフォルトの名無しさん：2011/07/28(木) 05:36:00.28

>>952
天才進入禁止

955 ：デフォルトの名無しさん：2011/07/28(木) 06:02:22.93

Scheme系のStalinはCより速いと作者がいってる。

956 ：デフォルトの名無しさん：2011/07/28(木) 06:20:37.39

>>952
場合による。
loadやsaveしたいのは、そのobject自身のデータなのか、
それとも他のobjectなのかで決めればいいこと。

別の言い方をすれば、loadやsaveの仕方を知っているべきなのは、それを担当する専用オブジェクトなのか、自分自身なのかという違い。

一つの見方として、loadやsaveの処理が必要としている内部情報の多いほうのオブジェクトが、そのメソッドを持つべき。

957 ：デフォルトの名無しさん：2011/07/28(木) 08:30:39.59

>>955
Stalinって中間コードとしてCのコードを生成するんじゃなかったか？

958 ：デフォルトの名無しさん：2011/07/28(木) 12:52:05.50

>>957
んだ。たぶん人の書いたCコードより速いって意味なんだろう。使ったこと無いけど、読めないコードらしいし。

959 ：デフォルトの名無しさん：2011/07/28(木) 12:52:42.79

でも、パフォ比較見てると、そうでもないのかな？というのがあって作者がいってると書いてる。

960 ：デフォルトの名無しさん：2011/07/28(木) 14:07:02.07

aは自己複製メソッドbを持つ
cはaから派生。cは要素としてaを持つ
すなわちc' = c.b であり c'.a = c.a.bであるから
c.a = c', c'.a = cとした場合、c.bは循環する

>>952
save,loadの詳細による

961 ：デフォルトの名無しさん：2011/07/28(木) 14:19:03.38

>>958
http://www.ibm.com/developerworks/jp/opensource/library/itm-progevo4/index.html?ca=drs-
> Stalinは、標準関数もひっくるめたプログラム全体の依存性解析と型推論を行い、徹底的に最適化されたコードを出力する

962 ：デフォルトの名無しさん：2011/07/28(木) 16:13:07.02

速度とかはまあ、処理系が頑張れば改善するとして
やっぱり普及のネックは型検査かな
動的型アレルギー疾患者は結構多いぜ

963 ：デフォルトの名無しさん：2011/07/28(木) 16:43:05.97

その内、starlinの改良版maoとかGuevaraとか出てくるんでないかい？

964 ：デフォルトの名無しさん：2011/07/29(金) 11:33:09.83

Java7が出たよ！
Javaのどこが良いのか分からんけど朗報だね！

965 ：デフォルトの名無しさん：2011/07/29(金) 18:44:06.43

>>962
なら推論で良いんじゃね？

966 ：デフォルトの名無しさん：2011/07/29(金) 21:19:48.41

型ねぇ。おれは突き詰めれば静的型しか有り得ないと思うけどな。
だいたい動的型言語だと、
オブジェクトが～のメソッドを持ってるときは呼んで、
持ってなきゃ例外投げる、みたいなノリだけど、
これってそもそもシングルディスパッチのときしか通用しないんだよね。
動的型でマルチメソッドしようとすると、
「コレとコレを引数に取る場合はこの関数」って指定しようにも、
そもそも型に名前が付いてないから、指定のしようも無い。
型に名前が無いから実物のオブジェクトを持ってくるしかないんだけど、
ちょっとそれは上手くいきそうに無いよね。

967 ：デフォルトの名無しさん：2011/07/29(金) 21:58:49.78

マルチディスパッチの場合も、全ての引数とマッチングして
全部合致するメソッドがある場合だけ呼び出して
それ以外は例外投げりゃ良いじゃん

968 ：デフォルトの名無しさん：2011/07/29(金) 22:12:09.06

オブジェクトにどうやってメソッドを指定するの？
シングルディスパッチの場合だと、
obj.method = hoge;
とかで良いけど。

969 ：デフォルトの名無しさん：2011/07/29(金) 22:14:21.73

foo(x, y) でいいじゃん

970 ：デフォルトの名無しさん：2011/07/29(金) 22:19:22.64

それは呼び出すときだろ？
x,yを引数にfooを呼んだとき、foo_x_yが呼ばれるように指定するにはどうしたらよいんだ？

971 ：デフォルトの名無しさん：2011/07/29(金) 22:24:33.92

@multimethod(list,list)
def foo(x, y):
print "List"

@multimethod(str,str)
def foo(x, y):
print "String"

foo([],[]) # "List"
foo("","") # "String"

こんな感じで

972 ：デフォルトの名無しさん：2011/07/29(金) 22:30:13.00

listとかstrとかは型じゃんかよ。

973 ：デフォルトの名無しさん：2011/07/29(金) 22:35:55.72

ん？マルチメソッドの話じゃないの？
何が言いたいのか分からんぞ

974 ：デフォルトの名無しさん：2011/07/29(金) 22:37:22.20

ちなみに>>971はPythonのコードね
分かると思うけど

975 ：デフォルトの名無しさん：2011/07/29(金) 22:38:29.48

型名なしで、どうやってディスパッチ先を指定するんだって話。
シングルディスパッチだと、
obj.method = method1;
とか出来るから、型名要らないけど、
それはシングルディスパッチ限定の話だよねって。

976 ：デフォルトの名無しさん：2011/07/29(金) 22:41:50.78

>>966
どの動的言語を想定した意見なの？動的のオブジェクト指向なんて
CLOSからRubyみたいなのまであるから、何を想定して何を勝手に
disってるのかよくわからん。

977 ：デフォルトの名無しさん：2011/07/29(金) 22:48:51.03

型名の無い言語。
まぁその上で動く型システムを導入するのは勝手だけど、
それって、静的型をエミュレーションしているだけだし。
やっぱり型名欲しいやってことでしょ。

978 ：デフォルトの名無しさん：2011/07/29(金) 22:48:51.98

>>975
えーと、まず>>971のように振る舞うのがマルチメソッドってのはいいな？
あれはxとyの実行時の型によって foo(list,list) と foo(str, str) の
どちらを呼ぶかを切り替えてる

で、例えば次のような関数があれば切り替えられるが、
こんなのを人間が毎回定義するのは馬鹿馬鹿しいよね？

def foo_dispatch(x, y):
    if (isinstance(x, list) and isinstance(y, list)):
        foo_list_list(x, y)
    else if (isinstance(x, str) and isinstance(y, str)):
        foo_str_str(x, y)

そこで上の@multimethodというデコレータは関数を内的なレジストリに格納して、
foo_dispatchがやってるような切り替えを自動的にやってくれる

979 ：デフォルトの名無しさん：2011/07/29(金) 22:49:55.84

>>977
えっと、動的型って意味じゃなくて、本当に型の無い言語の話か？

980 ：デフォルトの名無しさん：2011/07/29(金) 22:55:25.10

あーそっか。ごめんごめん。
動的型って実行時に型チェックすることか。
型無し言語と勘違いしてた。

981 ：デフォルトの名無しさん：2011/07/29(金) 22:58:38.12

そりゃTclさんとかですな
あれで大規模書ける奴は神

982 ：デフォルトの名無しさん：2011/07/29(金) 23:03:58.61

つーか、JavaScriptって型名無し言語じゃなかったっけ？

983 ：デフォルトの名無しさん：2011/07/29(金) 23:12:31.90

つぎスレ：
http://hibari.2ch.net/test/read.cgi/tech/1293264747/101-200

984 ：デフォルトの名無しさん：2011/07/29(金) 23:58:48.30

動的言語だって、○○というメソッドを持った型を
前提にコードを書くわけで、じゃあそのことを
コード上に書いて静的にチェックできるようにしたらいいよね。
という結論になる。

985 ：デフォルトの名無しさん：2011/07/30(土) 00:17:02.79

そんでダックタイピング出来なくなると。

986 ：デフォルトの名無しさん：2011/07/30(土) 00:31:31.87

そんでインクリメンタルコンパイル出来なくなると。

987 ：デフォルトの名無しさん：2011/07/30(土) 02:12:51.67

ダックタイピングって結局
型がほしいってことじゃないのか？

アヒルという型がほしいんだろ？

988 ：デフォルトの名無しさん：2011/07/30(土) 02:56:37.21

ちがう
アヒルとして扱っても問題がないことが重要なのであって
欲しいのは型であることじゃない

989 ：デフォルトの名無しさん：2011/07/30(土) 08:13:53.75

アヒルという型クラス

990 ：デフォルトの名無しさん：2011/07/30(土) 09:34:04.11

>>988
アヒルとして扱っても問題がないってことは、
扱う場所には、アヒルとして扱うコードが書かれてるんだろ？

じゃあ、そのコード、オブジェクトをアヒル型変数に代入して
扱っても問題ないよな？

アヒル型変数に代入できるってことは
そのオブジェクトは、アヒル型インターフェースを
持ってるってことだ。

991 ：デフォルトの名無しさん：2011/07/30(土) 10:08:06.45

こういう質問する人って、「たらい回し」はたらいを回す事だと思ってんだろうなあ。

992 ：デフォルトの名無しさん：2011/07/30(土) 10:25:23.96

tarai関数

993 ：デフォルトの名無しさん：2011/07/30(土) 10:42:54.75

つか、「アヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」っていうのはさ、
それが、アヒル歩きメソッドとアヒル鳴きメソッドを持っているってことだろ？

アヒル歩きインターフェースと、アヒル鳴きインターフェースを持っているのと何が違うのさ？

994 ：デフォルトの名無しさん：2011/07/30(土) 10:51:41.03

外延性から集合を構成するのと同じだな

995 ：デフォルトの名無しさん：2011/07/30(土) 10:58:28.03

>>990
わっかんない奴だな。
「アヒルなら問題ない扱い」は部分集合だから、アヒル型であったり
そのインターフェイスを全て満足している必要はないんだよ。
処理のたびにそういう部分型をアドホックに定義する手法もあるけれど
どの型の部分型なのかを推論して暗黙のうちに合成・定義してくれる
型システムは一般にはまだ知られてないし、結局いちいち手で書くとなると
それはかなりコスト高になる。

996 ：デフォルトの名無しさん：2011/07/30(土) 11:05:46.40

型には反対しないが、複雑さに悩まされない型システムを見たことはない。
動的型付けはまだマシだ。 -- アラン・ケイ

http://d.hatena.ne.jp/katzchang/20080807/p2

997 ：デフォルトの名無しさん：2011/07/30(土) 11:32:20.25

duck-typingはcallerとcalleeを分離する
型があったとしても、それを知ってなきゃいけないのはcalleeだけで
callerは一切知る必要はない
そうやってオブジェクト間の疎結合を実現するのさ

998 ：デフォルトの名無しさん：2011/07/30(土) 11:40:29.74

>>995
> そのインターフェイスを全て満足している必要はないんだよ。

理想と現実ってかんじだなｗ

現実には、そのインターフェースをすべて満足していることを期待してるんだよ。
アヒルなら、アヒルのように歩いて鳴くことを期待している。

そこにアヒルのように歩くけど、鳴かないものを持ってこられても困るだけ。

アヒルのように歩くだけで十分なら、それだけでインターフェースにすれば良い。
アヒル歩きインターフェースを作ればいいだけ。これがお前の言う部分型だし、
アヒル完全型は、アヒル歩きとアヒル鳴きインターフェースの両方を継承した
インターフェースにすればいい。

999 ：デフォルトの名無しさん：2011/07/30(土) 11:43:38.40

どうも動的型じゃないといけないと思い込んでいる人がは、
ある型が同時に別の型としても扱えるってことをわかってないんじゃないのか？

静的言語でも、つくろうと思えばアヒルでありカバでもあるオブジェクトも作れるんだが。

callerはアヒルだと思っているが、caller側ではアヒルカバである。
ということも可能なわけで、
こうやってオブジェクト間の疎結合を実現しているのさｗ

1000 ：デフォルトの名無しさん：2011/07/30(土) 11:44:21.52

×caller側ではアヒルカバである。
○callee側ではアヒルカバである。

反論求むｗ

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。