消えてなくなれよ >オブジェクト指向 part.3

消えてなくなれよ > ..

2:デフォルトの名無しさん
09/06/01 13:14:10
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

3:デフォルトの名無しさん
09/06/01 13:16:32
でもライブラリはオブジェクト指向で書かれている方が圧倒的に使い易いのは確かかな。

4:デフォルトの名無しさん
09/06/01 15:36:17
ライブラリがどの言語で書かれていようが
オブジェクトファイルなってしまえば関係ないわけだが

5:デフォルトの名無しさん
09/06/01 16:21:52
>>4
>>4
>>4

6:デフォルトの名無しさん
09/06/01 18:53:38
京都大学はどこまで研究熱心なんだよ・・・

7:デフォルトの名無しさん
09/06/01 19:50:55
>>6
京大だけに、狂ったように研究熱心なのさ

8:デフォルトの名無しさん
09/06/01 20:57:39
オブジェクトはすべて非同期に動くべき。

9:デフォルトの名無しさん
09/06/01 20:58:38
ナンデ？

10:デフォルトの名無しさん
09/06/01 21:39:04
>>8
全てがオブジェクトな言語だと
1+1でもスレッドが起動されることになるが…
なんという無駄

11:デフォルトの名無しさん
09/06/01 21:56:11
>>8
ナンデ？

12:デフォルトの名無しさん
09/06/01 22:20:55
>>10
>>8 の肩を持ちたいとは思わんが
非同期 = スレッド
ってのは、ちゃうと思う

つ遅延評価

13:デフォルトの名無しさん
09/06/01 22:26:42
>>12
遅延評価と非同期は全く関係ないが

14:デフォルトの名無しさん
09/06/01 22:28:19
>>13 ハード作るときは、ほぼ等価

15:デフォルトの名無しさん
09/06/01 22:32:03
遅延評価と非同期と…ハード？？

16:デフォルトの名無しさん
09/06/01 22:33:24
オブジェクトって関数より再利用しにくいのではないだろうか
オブジェクトでthisコンテキストにアクセスできるようになったのと引替えに
再利用のために、関数なら引数のことだけ考えれば良かったが
オブジェクト単位で再利用を考えない意図いけないようになった。
そのため、継承・仮想メソッド・インタフェース・デザインパターン・ジェネリック
などのテクニックでその欠点を補っているのではないだろうか。

17:デフォルトの名無しさん
09/06/01 22:36:15
>>14
そんな元レスと話の絡まないレスでは意味がわからん

18:デフォルトの名無しさん
09/06/01 22:36:34
オブジェクトと関数を比べるのはバランスが悪い。
比べるなら、
片やオブジェクト郡、
片や関数郡とそれに渡されるであろうパラメータ郡。

そう考えると、再利用がどうかはさておき、
オブジェクトを中心にすえて考えていくほうが、
少なくとも、「散らかってない」と思う。個人的に。

19:デフォルトの名無しさん
09/06/01 22:37:16
まだオブジェクト指向で再利用とか言ってる奴がいるのか。

20:デフォルトの名無しさん
09/06/01 22:40:58
>>10
すべてオブジェクトにするからおかしくなる。
そんなのは理論屋がやってろ。

21:デフォルトの名無しさん
09/06/01 22:47:27
メッセージ（メソッド）が規格化されてないからいけない。
メッセージに使える単語を制限したらどうか。
オブジェクト指向じゃなくなるか。

22:デフォルトの名無しさん
09/06/01 22:48:33
天才チンパンジー　アイちゃんって２番にしか出てこないのか
さっさと埋めれば良かった

23:デフォルトの名無しさん
09/06/01 23:12:20
python のリストや辞書型くらい整備してくれてりゃ
クライアントとしては使いやすいとは思うけどね。
まあ速度とか気にしだせば結局再利用なんて無理でしょ。

24:デフォルトの名無しさん
09/06/01 23:16:46
再利用が無理と言い切るのもなんだかな
魔法のように何でも再利用できる！みたいなのは違うのは確かだが

25:デフォルトの名無しさん
09/06/02 02:05:24
迷った時は両方!

オブジェクト指向な関数型言語のocaml使えw

26:デフォルトの名無しさん
09/06/02 03:53:36
再利用しないからｗｗｗ

27:デフォルトの名無しさん
09/06/02 08:42:50
>>18
再利用の単位が関数よりも大きいだけと言うことか
オブジェクト指向のメリットって理解のしやすさと言うことだけ？

28:デフォルトの名無しさん
09/06/02 08:43:31
>>23
ホットスポットの解析もせずにライブラリに文句をいう厨房ですか？

29:デフォルトの名無しさん
09/06/02 09:32:05
>>27
理解のしやすさ、というかなんというか。
メリットは色々あるんじゃないかな。

オブジェクトという単位でモジュール化できて、
内部構造としての、変数の表現、メソッドの実装を隠す。
んで、そのオブジェクト郡のインタフェースには関連が見出せたりして、
実行時にはポリモーフィズムで一括して扱える。
あくまで、オブジェクト郡の相互作用で作っていく。

OOPでの再利用云々は、設計の正しさの拠ってると思われる。
再利用しやすい単位で、使用される文脈に想定をおいたりせず、
他のオブジェクトを無闇に知っていたりせず、うまいこと作る。
逆に、そこんとこをきちんとしてないとうまく再利用できないだろうし、
それもってOOPの力不足としてしまうなら、なんか違う気がする。

明白な特性をひとつだけ与えられたクラスは長持ちすると思う。
特性があいまいだったり、コブが着いてたりすると、弱いと思う。

30:デフォルトの名無しさん
09/06/02 09:43:49
無駄が多いですよね

31:デフォルトの名無しさん
09/06/02 12:48:31
100円節約するために1000円掛けるようなところがあるよね

32:デフォルトの名無しさん
09/06/02 13:10:49
業務用プログラムならばそれでいいんだよ。
運用費を100万円削るために開発費1000万円上乗せすればいい。

33:デフォルトの名無しさん
09/06/02 13:36:31
>20
そういや、Javaで基本型がオブジェクトじゃないのは、現在の視点で見ても、
良い判断だったんだろうか？

34:デフォルトの名無しさん
09/06/02 14:12:39
こんなモノ作るのになんで1年もかかるんだよと思うことは多々ある。
俺なら1週間で作れるモノを。

35:デフォルトの名無しさん
09/06/02 14:14:38
最初一週間でできるよって思ってたのが、一年たっても終わらないのはよくあること。

36:デフォルトの名無しさん
09/06/02 14:18:41
それは要はやる気が持続するかどうか　だけなんじゃねーの

37:デフォルトの名無しさん
09/06/02 15:13:59
コロンブスの卵だな
誰にでも出来るのに誰もやる気を出さない

38:デフォルトの名無しさん
09/06/02 15:34:41
その点東大生は優秀だよな。
つまらない受験勉強を継続的にこなしてきたんだから。
途中で飽きて投げ出すようなやつがＦランに行くんだよな。

継続性ある性格が成功を生み出すんだよ。

39:デフォルトの名無しさん
09/06/02 15:37:18
と・・こんなことを書くと、「俺は1ヶ月勉強しただけで東大受かりましたがなにか」とか言ってくる奴がでてくるんだよな・・
別にイレギュラーを探してるわけじゃないので＾＾；

40:デフォルトの名無しさん
09/06/02 16:10:37
>>37
コロンブスの卵は、そんな話じゃないだろwww

41:デフォルトの名無しさん
09/06/02 19:03:09
随分と安っぽい卵だなぁ

42:デフォルトの名無しさん
09/06/02 19:27:36
HaskellやOCaml、Erlangなどには対話環境があるけど
OOだと対話環境って無いし、あってもほとんど意味ないよな
関数型なら一行でかける関数作りまくればいいだけだし、無名関数も書きやすいから
エディタすら無しでいろいろできるわ。
間違いなくこれらは学習のコストと効率とモチベーションに大きく影響するね。

43:デフォルトの名無しさん
09/06/02 19:29:38
つ　Smalltalk

44:デフォルトの名無しさん
09/06/02 19:30:20
pythonてOO系の言語じゃないの？

45:デフォルトの名無しさん
09/06/02 19:36:04
スクリプトとOOPの良いトコ取り

46:デフォルトの名無しさん
09/06/02 19:49:08
>>44
そうだな

>>45
スクリプトとOOPは直交する概念

47:デフォルトの名無しさん
09/06/02 19:59:59
>>42
その場でがしがし付け足していけるのは楽そうだなと思うけど、
そういうコーディングしてても、保守は大丈夫なの？
関数型言語使ったこと無いから感覚がわからんけど。

48:デフォルトの名無しさん
09/06/02 20:10:23
>>42
python, ruby (irb), CINTなど色々あるのを知らないのか？

関数型言語でもToplevelをそのまま使うなんて面倒なことはしないで
Emacsのmajor-modeを使ったりするのが普通だと思うが。

49:デフォルトの名無しさん
09/06/02 20:41:31
対話型環境のメリットって関数の仕様を調べたい時とかにちょこっと実験する程度じゃないの？
rubyのirbとか普通に使えるよ。
OOP言語だと役に立たないって意味分からんね。
まさかOOPの概念を対話型環境で勉強したいって言ってんのかな

50:デフォルトの名無しさん
09/06/02 20:45:05
要は、IDEのデバッグ環境に対抗して
対話環境を関数型パラダイムで理論武装したいんだと思う

51:デフォルトの名無しさん
09/06/02 21:24:14
関数型言語が好きでML(SML, OCaml)を日頃使ってるが、ことさらOOを貶めるのも
どうかと思う。特にC++などの手続き型言語においては、OOを使わない場合と比べて
メンテナンス性が向上するのは明らかだし。

52:デフォルトの名無しさん
09/06/02 22:08:45
静的型のコンパイル言語であるScalaやってますが、ちょっとした確認なら対話型環境でやってますよ。

言語と実行環境って、分けて議論するべきものじゃないのかな？

53:デフォルトの名無しさん
09/06/02 23:22:04
そりゃOOとOOAとOOPと手続き型が一緒に語られるこんなスレじゃ、ポイズン

54:a36 ◆K0BqlCB3.k
09/06/02 23:28:05
>>53
区別するほどのものでもないだろう

55:デフォルトの名無しさん
09/06/02 23:29:46
>>53
なんで区別したいの？
話聞いてやるから詳しく話してみろ

56:デフォルトの名無しさん
09/06/03 00:08:37
>>53
OOとOOAとOOPと手続き型を全部厳密に定義してみろよ

57:デフォルトの名無しさん
09/06/03 00:27:53
お前が先に定義しろよカス

58:デフォルトの名無しさん
09/06/03 00:31:29
>>57
俺等は違いなんてどうだっていいもんｗ
全部同じぃ～で問題ないよｗ

59:デフォルトの名無しさん
09/06/03 00:33:50
はぁ？厳密に区別する必要は無いと思っているから定義する必要も無し。
一緒に語られたくなかったら定義しろよってことだ。その程度も分からんか？

60:a36 ◆K0BqlCB3.k
09/06/03 00:36:08
オブジェクト指向には厳密な定義は無いんじゃないかな。

61:デフォルトの名無しさん
09/06/03 00:37:39
>>59
いや、だから俺等はOO,OOA,OOPに違いはないよ組でいいんだろ？

62:59
09/06/03 00:40:06
>>61
そうだよ

63:デフォルトの名無しさん
09/06/03 00:51:41
威勢のいい>>57は逃亡しますた

64:デフォルトの名無しさん
09/06/03 02:17:57
ひどい自演を見た

65:デフォルトの名無しさん
09/06/03 02:26:47
どれが自演なんだ？

66:デフォルトの名無しさん
09/06/03 10:58:26
　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>53
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

67:デフォルトの名無しさん
09/06/03 21:03:39
雑魚ばかりだなこのスレ
俺の話についてこれる奴がいない

68:デフォルトの名無しさん
09/06/03 23:21:24
よし何か話せ

69:デフォルトの名無しさん
09/06/03 23:32:48
>>67に期待

70:デフォルトの名無しさん
09/06/04 01:21:01
簡単なエディタなら機械語で書けるぜ

71:デフォルトの名無しさん
09/06/04 01:23:43
>簡単なエディタで機械語が書けるぜ
は？

72:デフォルトの名無しさん
09/06/04 01:35:27
え？

73:デフォルトの名無しさん
09/06/04 02:31:27
　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>67
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

74:デフォルトの名無しさん
09/06/04 03:08:51
そのオブジェクト必要？みたいな

75:デフォルトの名無しさん
09/06/04 06:55:09
オブジェクト指向と直接関係ないけどマルチスレッドが扱い易い言語が欲しい。

76:デフォルトの名無しさん
09/06/04 07:04:20
C#

77:デフォルトの名無しさん
09/06/04 07:28:52
最近、でかいこと言い放つ割に逃亡する奴が多いな

78:デフォルトの名無しさん
09/06/04 07:37:39
昔からだろ

79:デフォルトの名無しさん
09/06/04 10:25:31
顔が真っ赤な人がいますね

80:デフォルトの名無しさん
09/06/04 18:49:01
ＣＷニコルさんですね

81:デフォルトの名無しさん
09/06/04 20:13:58
いまならへび、かめの卵と幼稚園の防止は俺のもの

82:デフォルトの名無しさん
09/06/04 20:15:15
>>73
　　　　　|┃三　　　　　　　／￣＼
　　　　　|┃ 　　　　　　　　|　　　　|
　　　　　|┃　　　　　　　　＼＿／
　ｶﾞﾗｯ.　|┃　　　　　　　　　|
　　　　　|┃　ﾉ//　　　.／￣￣￣＼
　　　　　|┃三　　　　／　 ::＼:::／::::　＼
　　　　　|┃ 　　　／　 <●>::::::<●>　　＼
　　　　　|┃　　　 |　　　　（__人__）　　　　|
　　　　　|┃三　　＼　　　｀ ⌒´　　　　／
　　　　　|┃三　　／￣￣￣￣￣￣￣＼

83:デフォルトの名無しさん
09/06/04 23:46:03
ある言語がチューリング完全であれば、その言語でオブジェクト指向は可能である。

84:デフォルトの名無しさん
09/06/05 00:06:11
programming "into" a language

85:デフォルトの名無しさん
09/06/05 00:41:56
>>75
文を並べると、逐次で実行してね、と
言わない限り全部並列に実行されてしまう
言語が主流になれば、並列度も上がる
だろうなあ。

86:デフォルトの名無しさん
09/06/05 01:41:09
スーパーハッカーな俺にはオブジェクト指向なんて要らんわ

87:デフォルトの名無しさん
09/06/05 01:51:31
>>86
どんなパラダイムがおすすめですか？

88:デフォルトの名無しさん
09/06/05 01:53:58
>>86
好きなプログラミング言語はなんですか。
よく利用するプログラミング言語はなんですか。
趣味で使うプログラミング言語はなんですか。

やっぱりシンプルなC言語ですか。

89:デフォルトの名無しさん
09/06/05 02:01:26
好きな言語はCだ。趣味ではlispをよく使うな。
お前らも努力すればハッカーになれるから頑張れ。

90:a36 ◆K0BqlCB3.k
09/06/05 02:21:42
ノイマン型コンピュータを扱っているなら、たとえ関数型言語を使っていたとしても最終的には手続き的な考え方をせざるを得ない。
ノイマン型コンピュータの仕組み自体が手続き的なのだから。

91:デフォルトの名無しさん
09/06/05 05:44:21
この辺で纏めてgc

92:デフォルトの名無しさん
09/06/05 08:31:50
>>89
こいつはとんだインチキハッカーだな。
どこかでハッカーは、 Cとlispを使うとでも洗脳されたのだろうか。
自分の利用する言語の正式名称も言えないなんてハッカーの資格無しだ。
lispってなんだよ。あのMITのトイレで生まれたというevalとatomとlistのことか。
どれだけ方言があると思っているんだよ。

93:デフォルトの名無しさん
09/06/05 10:33:43
そもそもコンピュータ自体が質的に有限なので
オブジェクト指向とかは作法の違いにすぎず、
本質的な違いはない。

94:デフォルトの名無しさん
09/06/05 10:58:05
～なので～にすぎず～はない。論理の飛躍。無根拠。
～とかは。焦点があいまい。

95:デフォルトの名無しさん
09/06/05 13:40:50
ジャンケンプログラムで、審判オブジェクトが必要とか未だにようわからん

96:デフォルトの名無しさん
09/06/05 13:54:25
グーチョキパーが互いに知り合って、
それぞれが勝ち負けを判断するような密な結合より、
グーチョキパーの関係性を記述するために特化したMediatorオブジェクトを用意し、
グーチョキパー事態は互いを知らなくていい、
ポーとかペーとかが発生した場合に修正を個々にしなくていい、
という緩い結合にしておくことに、そこにメリットを見出すため。

97:デフォルトの名無しさん
09/06/05 13:54:52
後だしする奴とかいるから、ちゃんとジャッジしてくれる人がいたほうがよくね？

98:デフォルトの名無しさん
09/06/05 14:04:30
>>96
単に独立した判定役がいればいいわけで,
object とか class じゃなくてもええんちゃう

CLOS 的には審判 object(審判 class)は作らんな, たぶん

99:デフォルトの名無しさん
09/06/05 14:19:00
>>93
有限/無限は量概念なのに、「質的に有限」ってw

100:デフォルトの名無しさん
09/06/05 14:31:33
>>95
審判作りたくないのなら、
プレイヤー同士で判定して、合意の下に
勝負を付ける仕組みでいいんじゃないか？

101:デフォルトの名無しさん
09/06/05 14:35:58
>>98
じゃんけん大会の内容に応じて取り替えられればいいだけなんで、
別にobjectでもええんちゃう

102:デフォルトの名無しさん
09/06/05 14:47:27
「構造化しないで上から下に書いていけばいいんちゃう？」
と言うのと同じな気がしてきました。

103:デフォルトの名無しさん
09/06/05 19:01:47
>>95
変化とか量産とかが無いとオブジェクト指向で書くメリットはあんまりないよ
グーチョキパーの勝ち負けのルールが変わるとか
非同期で同時に100個のジャンケン判定しないといけないとか
そういうのが無いと

104:デフォルトの名無しさん
09/06/05 19:33:20
ここで話すオブジェクト指向て実装面だけか？

設計だけオブジェクト指向でやって実装はオブジェクト指向にしないって現場もあるが。ゲーム開発とか。

105:デフォルトの名無しさん
09/06/05 20:19:04
>>104
設計と実装を分けて論じてはいけないスレです。

106:デフォルトの名無しさん
09/06/05 20:27:05
もし設計と実装が無関係なら、なんのために設計するんだ？

107:デフォルトの名無しさん
09/06/05 20:36:30
抽象レベルが違うのだから、いっしょくたに論じるほうがよほど問題だろ

108:デフォルトの名無しさん
09/06/05 20:43:23
多様性が必要無いならオブジェクト指向ってのは意味が無いどころかマイナスだ

109:デフォルトの名無しさん
09/06/05 21:30:19
要するに、異なる抽象レベルが互いに影響し合うシステムが
同じソースコードにいっしょくたに書かれてるんで
ソースコードから特定の抽象レベルだけを抽出したものを論じるなり何なりすればいい

110:デフォルトの名無しさん
09/06/05 21:38:41
それ「要するに」してない
それ以前に日本語してない

111:デフォルトの名無しさん
09/06/05 23:20:25
>>104
常識的に考えたら、設計がオブジェクト指向なら実装もオブジェクト指向じゃないの？
オブジェクト指向言語（機能）を使わない、オブジェクト指向実装じゃないの？

112:デフォルトの名無しさん
09/06/05 23:31:40
>>104
実際にオブジェクト指向の設計をどう非オブジェクト指向な実装に落とすのか
具体例を出してもらえる？

113:a36 ◆K0BqlCB3.k
09/06/05 23:33:55
>>112
つ　コンパイラ

114:デフォルトの名無しさん
09/06/05 23:42:30
>>113
それはレイヤーが違う。
設計->ある言語による実装と、ある言語での実装->バイナリを混同するな。

115:デフォルトの名無しさん
09/06/06 00:35:06
メッセージングはインターネットのような広い空間の緩い結合には適してる。
でも、プログラムの世界はもっと情報同士が密結合で信頼性も高い。
そういう世界でオブジェクトみたいな殻を作ると、無駄な伝言と依存性の不透明さが増して、
弊害が大きいと思うんだよね。
特にすべてがオブジェクトとか言われると。
# それはおまえの設計が悪いとか言わないでね。
# 不都合な事は全部設計が悪くてOOのせいじゃないというセリフは聞き飽きた。

116:デフォルトの名無しさん
09/06/06 00:43:53
少々プログラムの効率性犠牲にしてでもコード中に秩序を作り上げた方が生産性が高まることは多々あるわけで。
すべてがオブジェクトというやり方も、それが常にベストな解では無いと思うが、
LLなどではそういうやり方もありだろう。

117:デフォルトの名無しさん
09/06/06 00:47:37
>>116
いや、私が言いたいのは効率の話じゃなくて。
メッセージングやオブジェクトという仕組みでは、プログラムの秩序がより乱されてる
だけだと思う訳です。

118:デフォルトの名無しさん
09/06/06 00:56:28
すべてがオブジェクト、とかで作ると、でしょ？
それぞれに適した書き方すればいいんじゃないの
汚い部分を一手に引き受けるクラスとかがあっても問題ないでしょ
デザインパターンのfacadeみたいな

119:デフォルトの名無しさん
09/06/06 01:02:11
>>115
メッセージングはいいけど、たとえばJavaやSmalltalkでのオブジェクト間のメッセージングはただの関数呼び出しだよね？
たくさんのオブジェクトが存在する中で、実行中なのが常に一つっていうのはちょっと変じゃないのって話。
それって実世界の間隔とはかけ離れているよね。

120:デフォルトの名無しさん
09/06/06 01:03:30
×間隔
○感覚

121:デフォルトの名無しさん
09/06/06 01:09:48
オブジェクト云々の話は置いとくとしても、結合度は下げた方がいいと思うんだが。
「なんでも自由にお触りください」というものを使ってきれいに仕上げるのには
強い心が必要になるけど、あらかじめ「可能な操作はこれだけです」と決めておけば
心の支えにはなるでしょ。

122:デフォルトの名無しさん
09/06/06 02:25:26
>>115
前半はいまいち理解できない(普段そのように感じてはいない)けど、後半は納得。

>　特にすべてがオブジェクトとか言われると。
特にこういう部分がOO(の教祖、信者)のダメなところだと思う。

以前会社の後輩が設計、実装したプログラム(C++)では、
普通の数学的な意味の関数を作るだけですむような計算処理を、
あえてクラスとして実装していた。
このため、計算処理を行うためには、そのクラスのインスタンスを生成し、
そのインスタンスのメソッドを呼ばなくてはならなかった。
(そのメソッドを呼んだあとはインスタンスは用済みなのでインスタンスの破棄まで
しなければならない。)

123:デフォルトの名無しさん
09/06/06 03:28:02
いや、仮にOOPの信者でもそういうのは普通に関数にしたり
ユーティリティクラスにしたりすると思うんだが。
問題は後輩がOOPの信者だったことではなくて、単に経験が
足りなかったことなのではないかと。

124:デフォルトの名無しさん
09/06/06 03:48:11
>>122
普通そういうのはnamespaceに閉じ込めた関数にするか、OO信者でどうしても
クラスにしたかったとしてもstaticメソッドにするはず。
C++をあまり知らないから何でもインスタンスメソッドにしたがるんだろう。

125:デフォルトの名無しさん
09/06/06 07:28:12
シナリオ書いてクラス図やインタラクション図を起こして、
一旦OODで機能とデータを洗い出してから、
機能毎にモジュールを切り直してCで実装、
ってのは結構ありがちなパターンだったりする。

126:デフォルトの名無しさん
09/06/06 09:02:38
staticメソッドの無い言語って多分無いからな
つまりはそういうことだ

Needless Complexityは避けろって普通は言われる

127:デフォルトの名無しさん
09/06/06 09:29:30
まあ、普通の関数ですむと思ってるのは自分だけで
文字列操作のように、関数にするよりもクラスにして操作するほうが自然な物だったりしてな

128:デフォルトの名無しさん
09/06/06 10:16:19
プログラム内のある意味のある塊をどうまとめるか。
オブジェクトというまとめ方しか知らない・出来ないのは不幸だ。

129:デフォルトの名無しさん
09/06/06 10:18:03
日本人は「自分だけ」に弱い。

130:デフォルトの名無しさん
09/06/06 11:35:10
「俺の周りは」なんて言ってる奴には、永遠に理解できないもの
それが、オブジェクト指向

131:デフォルトの名無しさん
09/06/06 12:23:50
Eiffelｻｲｺｰ!!!!!!!!!!!!!

132:デフォルトの名無しさん
09/06/06 12:41:53
「実はただの関数呼び出しだよね？」と聞くと、
「関数呼び出しにたとえるのはダメ」と言われることがある。
関数呼び出しを使わないOOPの実装もありえると言いたいんだろう。

でも、一般論の前にまず特定の実装を知るべきだよな。
一般論だけを語りたがる風潮にも問題があると思う。

133:デフォルトの名無しさん
09/06/06 13:57:18
関数を動的に探索して、適切な関数を呼びだす、
ということを実行時におこなうのが普通の「関数呼び出し」だと主張するのなら、
OOPLでのメッセージ送信の多くの実装は関数呼び出しと言えるかもしれないけどね。

実際には普通の「関数呼び出し」では呼び出される関数はコンパイル時に確定しているから、
OOPLでのメッセージ送信の多くの実装は単なる関数呼び出し以外のこともやっているよね。

134:デフォルトの名無しさん
09/06/06 14:02:00
>>133
>>119

135:デフォルトの名無しさん
09/06/06 14:05:04
はあ？
>>133は>>119への反論だと思うが？

136:デフォルトの名無しさん
09/06/06 14:09:41
自分で処理系を書いたことがない人は>>119みたいな発想になるんだろうな。

137:デフォルトの名無しさん
09/06/06 14:13:58
>>130
永遠に理解できないなんて、なんてえらそうな技術。
それがオブジェクト指向という宗教。サイエンスのかけらもない。

138:デフォルトの名無しさん
09/06/06 15:09:22
>>136
処理系はバリバリ書いてきた方が、
それはともかくとしてなんで処理系を書いたことがないと>>119みたいな発想になると思うのか、
その論理のつながりが解らん。

139:デフォルトの名無しさん
09/06/06 15:15:13
お前らの頭悪そうなレス見てると優越感に浸れる
ありがとう

140:デフォルトの名無しさん
09/06/06 15:15:36
つーかメッセージングか関数呼び出しかについては前スレで終わったんじゃないの？
前スレで出ていないような新規の主張をするならいいが、そうとは思えないぞ。

141:デフォルトの名無しさん
09/06/06 16:53:14
>>138
実際には処理系を書いたことがないから、わからないんじゃないかなあw

142:デフォルトの名無しさん
09/06/06 17:11:59
>>141
俺にはお前が口先だけの奴に見える

143:デフォルトの名無しさん
09/06/06 17:18:25
>>142
では、インターフェース型の変数がメッセージレシーバになっている場合の
メッセージ送信をおこなうために必要な処理をCで書いてみなさい。
同様に、簡易版でいいからC風の言語のコンパイラも書いてみなさい。
この2つの実装がまるで別物だということがよく理解できるから。

144:デフォルトの名無しさん
09/06/06 17:19:03
>>143
できるが、お前の態度が気に入らない

145:デフォルトの名無しさん
09/06/06 17:20:50
技術への攻撃が続かなくなったから、
今度は人格攻撃ですか。なるほど。

146:デフォルトの名無しさん
09/06/06 17:22:47
誰が見ても>>143の態度は気に入らないだろうな。
それ以前に言ってることが意味不明だし。

147:デフォルトの名無しさん
09/06/06 17:25:25
>>143
もったいぶらずに違いを教えてくれよ（*´∀｀*）
さあさあ。

148:デフォルトの名無しさん
09/06/06 17:26:37
確かにもったいぶり過ぎだな
本当にこいつは自分が言ってることが解って言っているのかと疑問に思えてくる

149:デフォルトの名無しさん
09/06/06 17:28:14
こんなクソスレでコンパイラ書けなんて言われて書く奴がいるかっつーの。
こういう非現実的なことを押し付けようとする奴って何様なんだろうかね。

150:デフォルトの名無しさん
09/06/06 17:28:47
>>143読んでわからないようなら能力がないからこの業界から足を洗ったほうがいい。
本人も周りもそのほうが幸せになれる。

151:デフォルトの名無しさん
09/06/06 17:29:12
コンパイラ作成系の本読んだところで
それっぽいこと語りたいガキだろ

152:デフォルトの名無しさん
09/06/06 17:29:29
erlangとかのメッセージ送信を見ればオブジェクト指向のメッセージングのモデルがいかに不自然かわかるだろ。
そもそもオブジェクト指向はメッセージングじゃない。
ただの関数呼び出しだ。

153:デフォルトの名無しさん
09/06/06 17:29:47
Cardelli厨の再来か？

154:デフォルトの名無しさん
09/06/06 17:30:48
>>150
早く「俺はまだまだ未熟でした、ごめんなさい」と言えよｗ
潔く負けを認めないかぎり、お前のスキルは一歩も前に進めないんだぞ。

155:デフォルトの名無しさん
09/06/06 17:36:17
最終的には「リンク先読め」「本読め」だの言ってお茶濁すやつ多いなｗ
自分の言葉で簡潔に表現できないｗ

あと、文章を引用してきて朗読するだけとかｗ

156:デフォルトの名無しさん
09/06/06 17:39:24
>>152
> そもそもオブジェクト指向はメッセージングじゃない。
> ただの関数呼び出しだ。

それを言うのなら、
「そもそも現在のOO実装は関数呼び出しがベースになっているから、
メッセージングによる本来のオブジェクト指向じゃない」
だろう。

157:デフォルトの名無しさん
09/06/06 17:43:22
そもそもメッセージングを厳密に実装してなんか良いことあんの？

158:デフォルトの名無しさん
09/06/06 17:43:54
必要なものはただの関数呼び出し。
だから、本来のオブジェクト指向は必要ないんだな。

>>127
関数が外部の変数に依存しないときは関数を作る。
関数の外側の変数を使いたいときはクラスを作る。
これで間違いない。

159:デフォルトの名無しさん
09/06/06 17:45:26
メッセージ送信という抽象モデルと、
メソッド探索＋関数呼び出しという実装を、
ごちゃごちゃにするから混乱してるんじゃね？

160:デフォルトの名無しさん
09/06/06 17:46:27
>>158
たぶんお前が一番レベル低い。

161:デフォルトの名無しさん
09/06/06 17:48:21
>>159
そういうことだな

162:デフォルトの名無しさん
09/06/06 17:48:24
>>158
> 関数が外部の変数に依存しないときは関数を作る。
> 関数の外側の変数を使いたいときはクラスを作る。

キミ、どこの土方よ？

163:デフォルトの名無しさん
09/06/06 17:50:17
オブジェクトAとオブジェクトBがそれぞれ別スレッドで動作してるとき、
AからBに(関数呼び出しによる)メッセージを送ったばあい、Bのメソッドを実行する実体は
Aのスレッドだったりして、そういうのが気持ち悪いと思うことはある。

164:デフォルトの名無しさん
09/06/06 17:53:09
非同期管理はまた全然別の話だろう

165:デフォルトの名無しさん
09/06/06 17:54:05
ちょくちょくスレッド間の同期を混ぜるやつが居るなｗこのスレにはｗ

166:デフォルトの名無しさん
09/06/06 17:55:44
>>162
レッテルを貼るだけでは何の意味もないだろ

167:デフォルトの名無しさん
09/06/06 17:55:59
この中でerlangをさわったことがある人、もしくはpi-calculusを勉強したことがある人はいるの？

168:デフォルトの名無しさん
09/06/06 17:59:02
>>167
俺は、無い！（´；ω；｀）　一番処理系に近づいたのはRHGを読書した時ｗ

169:デフォルトの名無しさん
09/06/06 18:09:27
>>159
実装と無関係な抽象モデルを作っても無駄じゃないの
関数呼び出し前提でモデル作ればいいじゃん

170:デフォルトの名無しさん
09/06/06 18:16:50
>>143
コンパイラ書けとか言うなら、せめてお前さんがASTに落とすまでのフロントエンドと
中間形式に変換した以降のアセンブリコードを吐くまでのバックエンドを自分で
書いて用意したらどうだ？これらの部分はお前さんの主張を「理解させる」上で
本質的ではないからな。
人にやれと言うくらいだから、この程度は簡単に書けるだろ？

171:デフォルトの名無しさん
09/06/06 18:27:12
>>169
実装ありきでモデルを作るんじゃなくて
まずモデルがあってそれを実現するために実装があるんだぞ

172:デフォルトの名無しさん
09/06/06 18:42:40
>>171
デスマを防ぐためにモデルを作るっていう発想はないんだな
絶望した

173:デフォルトの名無しさん
09/06/06 18:42:55
erlangって変数を設定したら２度と値を変えられないんだよね。
頭が硬くてプログラムを作れなくて使うのをあきらめますた。

174:デフォルトの名無しさん
09/06/06 18:43:08
？？？

175:デフォルトの名無しさん
09/06/06 18:53:40
>>172
そうじゃなくてモデルを作る時は
実装時に変な足かせになったりしないように抽象的な書き方をするのが基本だろ
論点ずらしもいいとところだぞ

176:デフォルトの名無しさん
09/06/06 18:59:59
>>175
関数呼び出しを前提にすることが、変な足かせになるの？

177:デフォルトの名無しさん
09/06/06 19:37:18
erlangは知らんが、ScalaのActorみたいなのがオブジェクト指向の
メッセージパッシングの理想型だったりするのか？

オブジェクトがそれぞれ別のスレッド（もどき）で動いてて、それぞれの
メールボックスに入ってるメッセージを順次読み出して実行・返信みたいな。

178:デフォルトの名無しさん
09/06/06 21:23:35
あーまだやってたのか

結局 OO なんてのは「明確な定義もないただの幻想」
ってのが、前スレの結論じゃなかったのか？

179:デフォルトの名無しさん
09/06/06 21:30:10
「前スレの結論」っていうのは大抵、
前スレで一番最後に目立っていた香ばしい強弁のことだよね。

180:デフォルトの名無しさん
09/06/06 21:31:13
「前スレで俺が言ったこと」だろ

181:デフォルトの名無しさん
09/06/06 21:43:08
じゃ、誰か OO の明確な定義をしてみてくれよwW

182:デフォルトの名無しさん
09/06/06 21:45:00
関数がない言語は少ないが、クラスがない言語はたくさんある。
クラスが役に立たないわけじゃないが、
クラスに似た方言がたくさんあって統一できてない感じがする。

183:デフォルトの名無しさん
09/06/06 21:53:49
大学出てる奴いないだろｗ
お前らは市販の参考書でお勉強した程度のレベルだ

184:デフォルトの名無しさん
09/06/06 21:55:37
> 大学出てる奴いないだろｗ
それは暴言だろ?
Fランだって大学は大学だろうに…

185:デフォルトの名無しさん
09/06/06 22:16:28
λ計算、オートマトン、関係代数、述語論理、π計算、グラフ理論など
まともな議論が出来る土台がソフトウェア技術を大幅に進歩させている中、
OOに関する議論はメッセージだのオブジェクトだのカプセル化だの、相変わらず不明確で不毛な論争が続くのみ。
これはOOが属人的なノウハウの域を脱していない証拠。
さて、ではOOをまともな議論の土台に載せるにはどうすればいいのでしょう？
やっぱりσ計算？

186:デフォルトの名無しさん
09/06/06 22:17:29
σ計算＝型理論＋操作的意味論

187:デフォルトの名無しさん
09/06/06 22:18:03
そもそも大学でオブジェクト指向とか教えてるのか？

188:デフォルトの名無しさん
09/06/06 22:34:31
>>186
操作的意味論があるなら、そこからクラス設計の優劣が定量的に計れたりしないだろうか？
総合的なものじゃなくても、特定の側面（結合度とか）だけでもいいので。
そういう論文が読みたい。

189:デフォルトの名無しさん
09/06/06 22:56:09
凝集度ならcohesion metricsで検索すればそれらしいものがでてくる

190:デフォルトの名無しさん
09/06/06 23:11:13
>>189
ありがとう。こんなに親切な御仁がいるとは思わなかった。
実はσ計算についても殆ど何も知らないので、OOの特徴(例えばMLのモジュールとの違い）を
σ計算の言葉で言い直すことができる事を期待して勉強してみます。
五十嵐先生まんせー。

191:デフォルトの名無しさん
09/06/06 23:18:41
σ計算について詳しい本なんてこれぐらいしか知らない

Amazon.com: A Theory of Objects (Monographs in Computer Science): Martin Abadi, Luca Cardelli: Books
URLﾘﾝｸ(www.amazon.com)

簡単に概要を知るだけならLuca CardelliのサイトのPaperの
Objectカテゴリにある論文を見ればいいんだけど

192:デフォルトの名無しさん
09/06/06 23:26:44
>>185
> さて、ではOOをまともな議論の土台に載せるにはどうすればいいのでしょう？
> やっぱりσ計算？

それ以前に OO の明確な定義付が必要だってば
何見てもオレオレ定義じゃん

193:デフォルトの名無しさん
09/06/06 23:32:13
URLﾘﾝｸ(lucacardelli.name)
ベースはFω<:かぁ。ふむふむ。

194:デフォルトの名無しさん
09/06/06 23:38:57
>>192
まともに議論できる土台であるσ計算の言葉でOO（に似たなにか）を言い替えてみる。
↓
これをOOの定義にしよう！（というコンセンサスが広がる）
↓
うまー

195:デフォルトの名無しさん
09/06/06 23:51:27
ちなみに、さっきから教えて君している私は学生でも院生でもなく、
職業プログラマなので、学生乙は禁止。

196:デフォルトの名無しさん
09/06/07 01:50:45
Software Engineering != Computer Science
URLﾘﾝｸ(www.ddj.com)

この人は学者じゃないが、まあ言ってることは大体正しいな。

197:デフォルトの名無しさん
09/06/07 02:11:53
懐かしい、DDJじゃないか。
日本でも雑誌出してたよな。

198:デフォルトの名無しさん
09/06/07 05:35:37
オブジェクト指向ってのはスパゲッティ指向をカッコヨク表現したものなんだよ

199:デフォルトの名無しさん
09/06/07 08:07:29
DDJの記事についてスラドで話題になってるな。
いきなりCを関数型言語だとか言う奴がいたり、それに食ってかかる奴等がいたり
このスレに似てるな。

URLﾘﾝｸ(tech.slashdot.org)

200:デフォルトの名無しさん
09/06/07 08:11:23
>>126
VBScript(否.NET)なめんな

201:デフォルトの名無しさん
09/06/07 11:53:58
>>198
スパゲティ指向ってのは言いえて妙かもしれない

202:デフォルトの名無しさん
09/06/07 12:33:10
茹でる前のスパゲティが理想なのに、気が付けば茹で上がったスパゲティって事か?

203:デフォルトの名無しさん
09/06/07 12:54:04
だとしても生麺なんて食いたくないね

204:デフォルトの名無しさん
09/06/07 12:58:05
OOはOOPだけにして、柔軟性と抽象化のためのテクとして受け取ればよかった。

分析と実装がどうの、現実世界＝オブジェクト、メッセージがうんたら、
これをばっさり捨てたらよかったのにね。

205:デフォルトの名無しさん
09/06/07 13:00:33
それがDbC
ユーザ定義の抽象型上の動的多態と拡張されたホーア論理を使ったよる制約プログラミング

206:デフォルトの名無しさん
09/06/07 13:16:43
お歳暮に渡すソーメンを買ってきたのに
何故か、そのソーメンで昼飯を作っちゃうみたいなwwww

207:デフォルトの名無しさん
09/06/07 14:53:38
>>204
> 分析と実装がどうの
この人たち OO を出せば客が尊敬してくれると思ってる連中だと思うよ

一昨年かな、急遽、長年付き合いのある映像関連のシステム作ってる
会社の手伝いをする羽目になった。

内容としては「既にあるシステムの出力フォーマットをMP4でラップしたい」だった

最初に頼んだところは、「いまから OO 分析してどーたらこーたら」と言うばかりで
実質的には何もしなかったそうだW

208:デフォルトの名無しさん
09/06/07 15:47:00
オブジェクト指向とそれ以外の違いなんて
instance.method()とmethod(instance)の違いくらいしかないんじゃないの？

209:デフォルトの名無しさん
09/06/07 15:53:55
CLOS では (method instance) なわけだが

210:デフォルトの名無しさん
09/06/07 15:58:20
>>208
そういう不用心な事を言うと、マルチプルディスパッチこそがOOの肝だろうが、
って言われちゃうぞ。

211:デフォルトの名無しさん
09/06/07 16:41:26
・カプセル化
・継承
・ポリモーフィズム

212:デフォルトの名無しさん
09/06/07 17:20:38
いまだにカプセル化とか言うアホがそんざいするんだ

213:デフォルトの名無しさん
09/06/07 17:33:44
>>212
カプセル化とか言うアホとは？

214:カプセル化
09/06/07 17:34:49
俺俺、俺のこと

215:デフォルトの名無しさん
09/06/07 17:40:19
　　　　　　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！出てこい>>212
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

216:デフォルトの名無しさん
09/06/07 17:47:52
カプセル化機能のないOO言語って山ほどあるのに…

クラス定義でアクセス属性決定する意味あるのか?

217:デフォルトの名無しさん
09/06/07 18:13:30
アクセス属性が必要ないのに、アクセス属性が付いてるって?
ご冗談をwww

218:デフォルトの名無しさん
09/06/07 18:15:29
private/publicとかの存在意義に疑問を投げかけてるのか・・・？

219:デフォルトの名無しさん
09/06/07 18:18:42
>>215
　　　　　|┃三　　　　　　　／￣＼
　　　　　|┃ 　　　　　　　　|　　　　|
　　　　　|┃　　　　　　　　＼＿／
　ｶﾞﾗｯ.　|┃　　　　　　　　　|
　　　　　|┃　ﾉ//　　　.／￣￣￣＼
　　　　　|┃三　　　　／　 ::＼:::／::::　＼
　　　　　|┃ 　　　／　 <●>::::::<●>　　＼
　　　　　|┃　　　 |　　　　（__人__）　　　　|
　　　　　|┃三　　＼　　　｀ ⌒´　　　　／
　　　　　|┃三　　／￣￣￣￣￣￣￣＼

220:デフォルトの名無しさん
09/06/07 19:07:16
お前らの話のどこがおもしろいのか解らん。
議論してる奴らもUMLとC/C++とJavaぐらいしか知らない奴ばっかりっぽいから、
知識不足で底が浅い議論になってるように見える。

221:デフォルトの名無しさん
09/06/07 19:08:12
話に面白さを感じるには、一定の知能が必要だな。

222:デフォルトの名無しさん
09/06/07 19:59:43
その一定の知識ってハードルがすごく低いんだと思うよｗ

223:デフォルトの名無しさん
09/06/07 20:05:52
どうせ2chじゃまともな議論にならないしな。
他でやれば結構面白い議論に発展するかもしれんが。

224:デフォルトの名無しさん
09/06/07 20:25:53
こんなところで議論とかｗ

225:デフォルトの名無しさん
09/06/07 21:57:07
ぶぴぶぴ
最高だこの力・・・

226:デフォルトの名無しさん
09/06/07 22:06:55
中を見えなくするとか隠蔽とか言われても中知りたくなる件ｗ

227:デフォルトの名無しさん
09/06/07 22:19:27
好きな子のパンツはやっぱり見たいよな

228:デフォルトの名無しさん
09/06/07 22:39:06
・カプセル化したければinterfaceを使い、classは全部公開
・継承はinterfaceのみ可
・ポリモーフィズムは↑に反しない限り自由

229:デフォルトの名無しさん
09/06/07 23:00:04
>>228
それはww構造的www部分www型ww

230:デフォルトの名無しさん
09/06/07 23:14:46
お前らOOPの影響で不況になったの解ってる？
OOPが原因でアウトソーシングなんて発生したんだよ？

231:デフォルトの名無しさん
09/06/07 23:33:59
こら！
なんでもかんでもオブジェクト指向のせいにするなアホ
OOを使う人間が無能だっただけでOOが悪いわけじゃないということにいい加減きづけよな

232:デフォルトの名無しさん
09/06/07 23:46:22
>>231
実際経営者というか管理の上流は
OOすることにより、製造業の部品が簡単に作れると勘違い
するようになった。もう複雑なOSなんて知らなくてもいいし
OOするだけで製造コストが劇的に下がると妄想を抱くようになった。

もし構造化のみだったらそんなこと無かったよ
コンサルなんて意味のない職業が台頭することもなかったし
管理のみの上流工程とか意味のない職種も誕生しなかった
全てがC++やJavaなどに代表されるOOがもたらした弊害でしょ

ジョエルもJavaスクール（笑）の影響でITがおかしくなったと言ってるぞ
金融破たんだって、JavaなんかのOOで簡単かつ乱雑にマネーゲームを
しかけることができるのが原因の１つだし

OOが無ければこれだけ異常な下請けや不況は起きなかった

233:デフォルトの名無しさん
09/06/07 23:52:41
多重下請け構造とアウトソージングは別物のような…
日本の業界だと一緒くたにされがちだけど

234:デフォルトの名無しさん
09/06/07 23:57:32
弊害といえば弊害だけど
最後の方はさすがに飛躍し過ぎ

235:デフォルトの名無しさん
09/06/07 23:58:28
経営者はooとかしらないよw
なぜかというと、彼らは

236:デフォルトの名無しさん
09/06/08 00:04:23
>>231
>OOを使う人間が無能だっただけでOOが悪いわけじゃない
もう聞き飽きたよ、そのセリフは...。
はいはい、私は無能です。

237:デフォルトの名無しさん
09/06/08 00:09:18
それに見てみろ
Javaなんかはバージョン上がる度にがどんどん複雑になるが生産性が
Java1.3や1.4の頃とかわらない

Rubyなんて10年前からあるけど脚光浴びてるだけで
なんら普通の生産能力しかない。むしろ無い部品が多いから
キャッキャとエテコウのようにオナプロ実装しているに過ぎない
そしてC++はいまだに0xの仕様を最終局面まで詰めれないし
このまま永遠に仕様策定ごっこして終わり

つまりだ、OOはその仕組みを作ることからして莫大で無駄な時間を浪費
する悪魔でしかないのだよ。技術の技術として仕上げていくことに対して
OOは無駄なことが多い単なる技術屋が金を長期間搾取できるための悪材料
でしかないんだよ

次ページ