5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

結局OOpが役に立たないのはなぜ?

1 :デフォルトの名無しさん:2010/04/14(水) 01:14:08
オォオォ言ってる奴等がアホな抱けちゃうの?



2 :デフォルトの名無しさん:2010/04/14(水) 01:15:41
猫に小判
豚に真珠
京大霊長類研究所

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

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

                  京都大学霊長類研究所

4 :デフォルトの名無しさん:2010/04/14(水) 07:09:52
VIPでやれ

5 :デフォルトの名無しさん:2010/04/14(水) 08:58:40
OOp <でっていうwww

6 :デフォルトの名無しさん:2010/04/14(水) 17:58:48
実際アホなんだろうと思うよ。
むしろアンチOOPの方がOOPを使いこなせたりしてな。
暗部を知っててそこを避けるから。

7 :デフォルトの名無しさん:2010/04/14(水) 20:56:38
>むしろアンチOOPの方がOOPを使いこなせたりしてな。
>暗部を知っててそこを避けるから。
と、アイちゃんが言いました。賢いねアイちゃんは
次は何を言うのかなアイちゃんは?


8 :デフォルトの名無しさん:2010/04/14(水) 21:52:14
>>結局OOpが役に立たないのはなぜ?
それはね、元から役に立たないからだよ、ぼうや
あんな理論もクソもない思いつきが21世紀で通用すると思うな

9 :デフォルトの名無しさん:2010/04/14(水) 23:39:12
>>1が役立たずだから。

10 :デフォルトの名無しさん:2010/04/15(木) 23:10:11
役立たないわけでもないが
空間押し込めたのはいいんでない。


11 :デフォルトの名無しさん:2010/04/16(金) 00:34:46
でも構造体は使えるんだろ

12 :デフォルトの名無しさん:2010/04/16(金) 00:38:58
自称ソフト屋が数式を理解できないからにきまってんじゃんw


13 :デフォルトの名無しさん:2010/04/17(土) 01:33:04
>>1
>オォオォ言ってる奴等がアホな抱けちゃうの?
気になっていたんだが、オォオォじゃなくウーウーだろう。

14 :デフォルトの名無しさん:2010/04/17(土) 15:32:35
関数をどのオブジェクトに入れるか悩むくらいなら関数のままでいい

15 :デフォルトの名無しさん:2010/04/17(土) 17:58:49
それが正解。
悩むのは、それが、どのオブジェクトにも入れるべきでない処理だから。
communicate( obj1, obj2 );
command( obj1, obj2 );
procedure( obj1, obj2 );
function( obj1, obj2 );
これがプログラミングの基本。全てはここから。
今は情報系の大学でも、CやPascalやる前に、いきなりJavaをやらせるらしい。
右も左も分からない学生に変な見本を教えて潰す。
日本のIT産業終わったな。

ポリモポリモ言う人も居る。
だったら、function( obj1, obj2 )で、
obj1とobj2の正しい型に基づいて動的にfunctionが呼ばれるべき。
つまり、動的オーバーロード(ライドじゃないよ)が本当のポリモ。
Javaなんぞに見られる、単体の型のみに結びついたポリモはもとよりウソ物。
相手にする必要なし。

16 :デフォルトの名無しさん:2010/04/17(土) 18:08:58
ダブルディスパッチというのはよく聞くけど、
トリプル以上のディスパッチは聞いた記憶がないな…


17 :デフォルトの名無しさん:2010/04/17(土) 21:02:25
今日も元気だな。そんなにOOが広まると困るのか。

18 :デフォルトの名無しさん:2010/04/17(土) 22:36:09
困るつーよりなんでもかんでも無理やりOOってのが問題だな
必要なとこだけでいい

19 :デフォルトの名無しさん:2010/04/17(土) 22:39:42
そもそもOOって「無理やり」「使う」ものなのか?

20 :デフォルトの名無しさん:2010/04/17(土) 22:45:04
無理やり使わされる、だな。

21 :デフォルトの名無しさん:2010/04/17(土) 23:19:47
俺はオブジェクト指向をやめ、構造体+関数でプログラムを作るようになってから、悩むことが減ったよ

必要ならその後にオブジェクトにまとめ上げる

こうすると無駄がなく頑健なオブジェクトが作れる気がしてる

22 :デフォルトの名無しさん:2010/04/17(土) 23:20:02
意味が分からん。

23 :デフォルトの名無しさん:2010/04/17(土) 23:25:19
>>21
悩まなくて済むじゃなくて、何も考えてないの間違いじゃなくて?

24 :デフォルトの名無しさん:2010/04/18(日) 00:04:34
>>15
つまりCLOSかその派生をやれってことですね

25 :デフォルトの名無しさん:2010/04/18(日) 01:04:59
>>23
わざと複雑に考える必要は無いんだよ。
プログラムの構造を素直に表現できればそれでよい。

>>24
JavaやC++よりは真っ当だと思う。
単一のクラスやオブジェクトに制御を紐づける発想は無理があるし、
思考の妨げになる。
第一引数だけを特別扱いする意味がもう分からないし、
第一引数に処理が紐づいてる意味も分からない。
引数ってのは第一だろうが第二だろうが等価の扱いであるべきだろ。
ポリモしたいなら、引数全部に基づいて決定すべきだし、
しないなら、Cみたく、一律にしないでいいじゃないか。
JavaやC++は中途半端。

26 :デフォルトの名無しさん:2010/04/18(日) 01:16:31
そしてこの書き方。
object1.method( object2 );
第一引数だけ前に持ってくるのはなんでだ?
第一引数だけ特別扱いなことを誤魔化したいのか?
たしかに、
func( object1, object2 );
で、「第一引数のobject1に基づいてのみfuncはポリモします」、では
皆「アレ?何かおかしい」と感づくわな。
もし、JavaやC++が全ての引数に基づいてポリモする仕様だったなら、
普通にfunc( object1, object2 );という文法だったんだろうな。哀れなり。

27 :デフォルトの名無しさん:2010/04/18(日) 02:06:24
アイちゃんはそんなに難しいことを考えなくてもいいんだよ^^

28 :デフォルトの名無しさん:2010/04/18(日) 08:21:10
>>25
もともと、Java, C++ はCにOOを導入した似非OO言語なのに、それを中途半端と指摘するのは無意味

29 :デフォルトの名無しさん:2010/04/18(日) 10:45:13
>>26
ポリモの例としてふさわしくない例を出されてもな。
そこは別に関数でいいんだよ。

30 :デフォルトの名無しさん:2010/04/18(日) 11:05:40
>>26
仮想関数テーブル
中身を知らず、使ったことしかないヤツだな。

31 :デフォルトの名無しさん:2010/04/18(日) 11:53:47
そのvtableがクラスごとに設置されてるのがクソの元凶なんだ。
そこで終わってる。なんでクラスやオブジェクトにそんなものぶら下げるんだ。

32 :デフォルトの名無しさん:2010/04/18(日) 11:59:56
com

33 :デフォルトの名無しさん:2010/04/18(日) 12:01:59
>>31
その方が、人間が管理しやすいから。

34 :デフォルトの名無しさん:2010/04/18(日) 12:05:19
ちげーよ。実行時のオーバーヘッドを少なくする為だよ、馬鹿やろう。

35 :デフォルトの名無しさん:2010/04/18(日) 12:05:35
>>31
エセOOだけども、速度が速い。

36 :デフォルトの名無しさん:2010/04/18(日) 12:10:54
>>34
いや、それだと「グローバルに置いて実行時に静的に束縛しろ(キリッ」とか言いそうだったから。

37 :デフォルトの名無しさん:2010/04/18(日) 12:11:39
実行時→コンパイル時

38 :デフォルトの名無しさん:2010/04/18(日) 12:13:11
>>36
そんなこと言うやつは、OOPしたことない。

39 :デフォルトの名無しさん:2010/04/18(日) 12:14:33
>>35
コンパイラががんばれば良いと思う。
関数呼び出しの文法は func( object1, object2, ... ); で統一しといて、

ポリモしない場合→普通の関数呼び出し
一つの引数に基づいてポリモする場合→vtableを使う
複数の引数に基づいてポリモする場合→動的関数検索(ハッシュか何かでやるのかな)

Cの関数呼び出しのスタイルと統一されるから、Cとの見た目の親和性も高いし、
動的オーバーロードでポリモするから、オーバーロードとの親和性も高い。

40 :デフォルトの名無しさん:2010/04/18(日) 12:18:09
>>38
ほら。 >>39

41 :デフォルトの名無しさん:2010/04/18(日) 12:32:09
それはお前の日本語力の問題だろ。

42 :デフォルトの名無しさん:2010/04/18(日) 12:34:27
Python の self っていいよね

43 :デフォルトの名無しさん:2010/04/18(日) 18:19:57
前置記法でないと発狂する人がいるスレがあると聞いて。

(* (+ 1 2) (+ 3 4))

44 :デフォルトの名無しさん:2010/04/18(日) 19:00:33
>>42
OOの実装むき出し

45 :デフォルトの名無しさん:2010/04/18(日) 19:05:12
後置記法でもいいよ。
( obj1, obj2 ).func;
でも、引数が常に二つと決まっているわけでもないのに中置記法はねぇだろ。
obj1.method( obj2, obj3 );
なんだいこれ。
なんで関数の引数が左右に分かれて記述されてんだよ。

46 :デフォルトの名無しさん:2010/04/18(日) 19:19:32
LISP風に書くと、
( 1 + 2 3 )
こんな文法は変だろ。
( + 1 2 3 )
こうか
( 1 2 3 + )
こうだろ。

47 :デフォルトの名無しさん:2010/04/18(日) 21:06:34
だからそこは素直に関数にすればいいだろ

48 :デフォルトの名無しさん:2010/04/18(日) 21:11:33
>>45-46
一度、代数学の証明過程とか勉強してみるといいと思うよ。
(+ 1 (+ 2 3))
あれ、こっちだっけ
(+ (+ 1 2) 3)

中置記法でも後置記法でも話は同じな。

49 :デフォルトの名無しさん:2010/04/18(日) 21:18:26
何にせよ、「俺の直感に反するから禁止(キリッ」じゃ議論にならんよ。

50 :デフォルトの名無しさん:2010/04/18(日) 21:22:55
Pythonに毒されて、OOPを理解できなくなってるな。

51 :デフォルトの名無しさん:2010/04/18(日) 21:23:49
つれますか

52 :デフォルトの名無しさん:2010/04/18(日) 21:50:11
>>51
お前か?

53 :デフォルトの名無しさん:2010/04/18(日) 22:05:08
まぁ、釣れてるよな、スレ的にはw


54 :デフォルトの名無しさん:2010/04/18(日) 22:47:33
みんなが考えるオブジェクトとは
1. 構造体+操作関数である
2. 責務である
3. アクターである
4. 抽象概念である
のどれ?

55 :デフォルトの名無しさん:2010/04/18(日) 23:35:49
>>48
だから、中置記法だと引数が二つしか取れねーだろーがよ、馬鹿かよ。

56 :デフォルトの名無しさん:2010/04/18(日) 23:49:07
たとえば、積和演算を行うmad演算子を作るとする。
前置記法だと、mad a b c
後置記法だと、a b c mad
で、中値記法でどう書くつもりだ?
a mad b c ?
a b mad c ?
おかしいよね。
だから引数の数が3つ以上になりうる関数の呼び出しの文法は、
前値記法か後置記法しかありえねぇんだよ。
中値記法が通用するのは、+や-みたいに高々2つの引数しか取らないことが分かってる場合のみ。
だから、obj1.method( obj2, obj3 )はアホなんだ。

57 :デフォルトの名無しさん:2010/04/18(日) 23:52:42
>>55
いいから>>48の式を中置記法に直してみるんだ。
そもそも、(+ 1 2 3)は(+ 1 (+ 2 3))の糖衣構文なわけだがね(結合則が逆かも)。

そもそも、>>47の言う通り、そういう引数の取り方が自然な時はそうすればいい。
そして、その書き方は二項演算の組み合わせによる表現とは全く等価で矛盾しない。

58 :デフォルトの名無しさん:2010/04/19(月) 00:01:49
まだ分からない奴が居るな。
C言語の標準関数
char *fgets(char *s, int n, FILE *fp);
を中値記法で書いてみろ。

59 :デフォルトの名無しさん:2010/04/19(月) 00:04:58
>>58
まず、その問題系の演算規則を定義してください。

60 :デフォルトの名無しさん:2010/04/19(月) 00:07:42
元から関数呼び出しの話をしてるんだ。

61 :デフォルトの名無しさん:2010/04/19(月) 00:12:54
まさか、意味も分かってないのに前置記法とか言ってたの?

62 :デフォルトの名無しさん:2010/04/19(月) 00:18:43
だったら、演算規則を定義してやるよ。
fgetsはsもnもfpも同時に使う。結合の順序なし。
早く中値記法で書いてください。

63 :デフォルトの名無しさん:2010/04/19(月) 00:29:19
例えば、sとnとfpの加算規則がどうやって定義されてるのか大変興味があるな。

64 :デフォルトの名無しさん:2010/04/19(月) 00:32:09
一応、最大限にエスパーを発揮して「fp.fgets(n).copyTo(s)」とは書いておこう。
これに突っ込まれても困るけどな。
そもそも>>58が、どんな前提条件において何を想定してるのかが分からないわけで。

65 :デフォルトの名無しさん:2010/04/19(月) 00:44:32
>>63
副作用が出るわけだから無意味だわな。
それから、関数呼び出しを中置記法ですることについて今話していることぐらいは分かってるよな。

>>64
意外にきれいに書けたね。
でも、こう書ける場合ばかりじゃない。
copyTo(s)でもう一度nが必要な場面もあるからな。

66 :デフォルトの名無しさん:2010/04/19(月) 00:47:30
中置記法だと、3つ以上のオペランドを扱えない。
がんばって2つのオペランドになるように分解しても、
こんどはオペランドを同時に扱えない。
関数呼び出しには不適切ということ。

67 :デフォルトの名無しさん:2010/04/19(月) 07:52:25
1 + 2 は、int.Add(1, 2) あるいは、1.Add(2)

68 :デフォルトの名無しさん:2010/04/19(月) 08:02:51
分かってないみたいだからはっきり言うけど、
「関数呼び出しを中置記法でする」とかいう発言そのものがナンセンスなんだってば。

「オブジェクトが3つ以上ある場合を記述できないOO哀れ」とか言い出すから、
代表的な演算である四則演算の記法(「それ、二項に分割できるよ」)を反例として出したのだよ。

つうか、別に三項以上でも、委譲を使えば多くの場合は困らんけどな。
Object1 obj1 = new Object1Impl();
Object2 obj2 = new Object2Impl();
Object3 obj3 = new Object3Impl();

obj1.method(obj2, obj3); // { obj2.method(); obj3.method(); }

あと、C++やJavaが多重ディスパッチに言語サポートがないのは、
これらが静的型言語だからであってOOの問題ではない。

仮に「C++やJavaは使えない」と主張したいのだとしても、
まずは、プログラムを記述する上で多重ディスパッチが使えないことで
生産性が致命的に低下する、ということを証明してからにしてくれ。

69 :デフォルトの名無しさん:2010/04/19(月) 11:25:12
>>64
fp.fgets(n).copyTo(s) のcopyToはsを書き換えるので、sのメソッドにして
s.copyFrom(fp.fgest(n)) とも書けると思います。

オブジェクト指向だと、こういった複数のクラスにまたがる処理を
どちらのクラスに入れるべきかで悩むことがありませんか?

(copyToの方はデメテルの法則や、ThoughtWorksの
「オブジェクト指向エクササイズ」に違反していますね)

また、処理をあるクラスのメソッドとして入れた場合、
同じ処理を他のクラスで再利用するのが難しいと思います。
(多重継承やMixinで解決している言語もありますね)

関数の場合には fgets(s, n, fp) で済むのでシンプルですし
他の関数からの再利用も簡単です。

70 :デフォルトの名無しさん:2010/04/19(月) 13:32:27
s = fp.fgets(n)
だろう常考

71 :デフォルトの名無しさん:2010/04/19(月) 14:42:25
最悪でもcopyFrom()というネーミングは無いわー

72 :デフォルトの名無しさん:2010/04/19(月) 16:40:40
例えば
x1, x2,... -> (x1, x2, ...)
のような演算を考えると、単純に2項演算に分割できないよね

単純に2項に分割して逐次適用すると
(((x1, x2), x3), x4...)
のようになってしまう

73 :デフォルトの名無しさん:2010/04/19(月) 18:31:45
それで、それによって具体的にどういう弊害があるの?
あと、仮に弊害があるとして、それはどの程度のインパクトなの?

74 :デフォルトの名無しさん:2010/04/19(月) 18:32:39
>>73
弊害って、見てわかんないの?
フラットなリストと入れ子のリストは別もんでしょ

75 :デフォルトの名無しさん:2010/04/19(月) 18:43:44
そもそも>>72で何を言わんとしてるのか全く分からないから適当に言うけどさ、
LISPは見たことがないの?

76 :デフォルトの名無しさん:2010/04/19(月) 18:47:57
>>75
ああなるほど
Lispのlist関数だと思えば、consで実現できる

タプルのような、consの組み合わせで表現されない構造を作りたいのだと
思ってくれ
俺が本当に念頭に置いていたのはzipやzipWithの類だけど

77 :デフォルトの名無しさん:2010/04/19(月) 18:55:59
zipやzipWithは>>72とは違うのだが

OOなら典型的には
foo.zipWith(other)
のように、2つのリストをペアリングするインタフェースになる
これは
zip(L1, L2, L3...)
より劣る

そして残念ながら、zipWithを数回繰り返して同じ結果を得ることはできない

78 :デフォルトの名無しさん:2010/04/19(月) 19:50:22
ふむ、その場合はそれでいいんじゃない。

で?

79 :デフォルトの名無しさん:2010/04/19(月) 19:52:31
いや、そんだけだけど

80 :デフォルトの名無しさん:2010/04/19(月) 19:54:47
まあそれだけだとあんまりなので

強いていえば、上の例で分かるように
OO的な記述が向いている時と向いていないときがあるので、
OO至上主義的な、ピュアOOみたいなのは俺は苦手
マルチパラダイムになっていると嬉しい

81 :デフォルトの名無しさん:2010/04/19(月) 19:57:46
誰も、全て二項演算で表現することがOO的であることの必須条件だとは言ってないしなぁ。

82 :デフォルトの名無しさん:2010/04/19(月) 19:59:35
それはそうかもしれないが、
「N項演算において、先頭の1個をとりあえずレシーバとする」みたいなやり方は
バイナリ演算よりも、さらに不自然さが際立つだけだろう
数学的には対等なオペランドでしかないんだから、概念を的確に
モデル化しているとは到底いえない

83 :デフォルトの名無しさん:2010/04/19(月) 20:07:02
ダブル/マルチディスパッチの例として、例えばcoercionをサポートした
演算を考える
intやdoubleの加算のようなものだ

演算が可換な場合は、関数的に記述すればオペランドを交換できるので、
ずっと実装がシンプルで済む
OOスタイルでは、こういうことは不可能だな

84 :デフォルトの名無しさん:2010/04/19(月) 20:13:56
俺が言いたかったのは、多くの場合において表現能力は同等なんだから、
「N項演算を表現できないOOは破綻している!」とか言われても意味が分からん、という話。

あと、仮に二項演算で実装するにしろ、ユーザに見せるAPIはラップして提供すりゃいいわけだしな。
(もちろん、N項演算として実装してそれを見せたっていい。どちらが最適かは状況による)

さらに言えば、N項形式で表現した方が(ユーザが)分かりやすい場合があるのはいいとして、
それがOOのコンセプトを全面的に棄却する必要があるほど一般的かつクリティカルかどうか。

85 :デフォルトの名無しさん:2010/04/19(月) 20:14:41
>>84
俺のレスが読めないの?
「全面的に棄却しろ」とは一言も言っていないんだが
>>80読めよ

86 :デフォルトの名無しさん:2010/04/19(月) 20:16:39
>>83
だから、そこで言ってる「OOスタイル」って何のこと? ちゃんと定義して。

87 :デフォルトの名無しさん:2010/04/19(月) 20:17:40
>>86
ああ、あんまり厳密な議論ではないけど
1.add(2.0)
みたいなものだと思ってくれて構わない
どっちかのオペランドをレシーバにする

88 :デフォルトの名無しさん:2010/04/19(月) 20:20:24
>>85
俺は、そういうことを言ってた奴向けに反論を書いてたんだよ。
適切な記述を実現できるなら、マルチパラダイムが悪いとは全く思わない。

89 :デフォルトの名無しさん:2010/04/19(月) 20:21:27
>>88
なるほど、なら俺らは別にケンカする必要は無いね

stackやqueue、GUIみたいなものに非常にOOが向いているのは俺も同意するし

90 :デフォルトの名無しさん:2010/04/19(月) 20:27:27
>>87
>>84でも書いたが、レシーバを特定しない形で記述するのが自然ならそうすればいいと思うよ。
Singletonパターンにしても、「推奨されない」けどパターンの一つなわけだしね。

>>89
同意感謝。

91 :デフォルトの名無しさん:2010/04/19(月) 20:36:39
んー、ちょっとカリカリしすぎてたな、すまん。

92 :デフォルトの名無しさん:2010/04/19(月) 21:53:57
>>68
> つうか、別に三項以上でも、委譲を使えば(中置記法で書くのに)多くの場合は困らんけどな。
> Object1 obj1 = new Object1Impl();
> Object2 obj2 = new Object2Impl();
> Object3 obj3 = new Object3Impl();

> obj1.method(obj2, obj3); // { obj2.method(); obj3.method(); }

え?

obj1.method(obj2, obj3);

え??

つまり、三項以上の中値記法は、obj1 operator obj2 obj3 ...
と書けと?それがきもいから、前置記法か後置記法のが良いでしょといってるのに。
operator obj1 obj2 obj3 ... のほうが良いでしょ。

93 :デフォルトの名無しさん:2010/04/19(月) 21:55:58
>>92
お前はまず人の話をちゃんと聞くところから始めろ。

94 :デフォルトの名無しさん:2010/04/19(月) 22:12:13
>あと、C++やJavaが多重ディスパッチに言語サポートがないのは、
>これらが静的型言語だからであってOOの問題ではない。

静的型言語であることと、多重ディスパッチをサポートしないことにはなんら関係はないだろ。
サポートしない理由は単に、手抜き&実行時のコスト&分割コンパイル云々 ってだけだ。

>>93
まずもって、「obj1.method(obj2, obj3);」が三項の中置記法で、
obj1 operator obj2 obj3 の並びになってる。
この並びを許すのなら、前置記法と中置記法は等価だし、何も問題ない。
でも、中置って普通二項だろ。三項以上とる演算に中置記法使うのがキモイと散々言ってるわけで。
むりに二項に分解すると、オペランドを同時に参照できなくなるし、
素直に前置記法か後置記法でいいだろ。そうすれば何の問題も出ないわけで。
あえて中置記法つかう意味はあるか?ないだろ。素直に考えろよ。
JavaやC++は間違ったんだよ。でも間違いは誰にでもあることだ。

95 :デフォルトの名無しさん:2010/04/19(月) 22:21:24
1+2 と 1.Add(2) と int.Add(1,2) は、等価ではないぞ。

96 :デフォルトの名無しさん:2010/04/19(月) 22:35:31
たとえば遠い将来、JavaやC++が多重ディスパッチを実装したとして、
object1.method( object2, object3 );
という文法を維持したまま、どう拡張しえるんだ?

普通に考えれば、多重ディスパッチは動的オーバーロードなわけで、
JavaやC++にはすでに静的オーバーロードがあることを考えれば、
動的オーバーロードをサポートする形で多重ディスパッチをサポートすることになるわな。
てことは、func( object1 );でポリモするし、
従来の仮想関数の記法は、ただのキモい古傷になるわな。
object1.method( object2, object3 );
あー何度見てもキモい。第一引数のみ特別扱い。ドットと括弧の対象性も悪い。
func( object1, object2, object3 );
きれいだなー。

97 :デフォルトの名無しさん:2010/04/19(月) 22:38:47
>>96
OO何もわかっていないな。

98 :デフォルトの名無しさん:2010/04/19(月) 23:01:42
常に単一ディスパッチになるように正規化された設計をすることは悪いとは思わんよ。
ただ、
メソッド呼び出しの文法は、func( obj1, obj2, ... );のスタイルで統一しときゃよかったのに。
後の祭りだな。
なんつーか、はしゃいじゃったんだろうな。
パラダイムシフトだーとか言って、第一引数だけ前に出して、
「ほら、オブジェクト主体だー」とか、何かそういう主張がしてみたい時期だったのだろうか。
今までとは違うってことをアピールしたかったのだろうか。よーわからん。
何処まで行っても手続き型プログラムの主体が、
その名のとおり、「手続き」であることは変わりようが無いのにな。

99 :デフォルトの名無しさん:2010/04/19(月) 23:07:33
何度も言われてるように、ほとんどのOOPLはOOP以外のパラダイムも使えるんだってば。
適材適所で使えば良いだけだろ。

100 :デフォルトの名無しさん:2010/04/19(月) 23:23:36
そして、C++はなんでわざわざ関数呼び出しの文法をCから変えたんだろうな。
この辺は頭悪かったな。あえて変える必要は無かったわな。
せっかくオーバーロードはCのスタイルを維持したのにな。

>>99
いわゆる今あるC++のOOPは、構造体のセッターとゲッターを定義する特殊な構文として、
OOPとは切り離して、なにか別のものとしてしまった方が良かったのかもしれない。
カプセル化機構とか適当な名前つけてさ。

別で動的オーバーロード(マルチメソッド)をサポートして、
そっちをポリモ機能(OOP機能)と称すれば良かったのではないかな。

要は、ポリモ機能とカプセル化機能を其々独立する。
俺が言語設計するなら、そうするな。

101 :デフォルトの名無しさん:2010/04/19(月) 23:35:00
func( obj1, obj2 ) //←ポリモ機能(動的オーバーロード)
{
  obj1.set_value(0); //←カプセル化機能
}

あーすっきりした。

つまるところは、カプセル化機能のついでに、同じところにポリモ機能も押し込めちゃってたから、
無理が出てたんだな。

これからはこれで行こう。

102 :デフォルトの名無しさん:2010/04/20(火) 00:03:31
今までだと、ポリモとカプセル化の構文が同じで、何の目的なのか曖昧なところがあった。
しかも、ポリモと言ったとき、カプセル化の意も含んでる場合もあるし、逆もまたある。
そういった状況だから、オブジェクト指向という抽象的な言葉で曖昧に表現してきたわけだ。
オブジェクトの振る舞いを定義して〜とかの変な話にもなった。

ポリモという言葉は曖昧だから、動的オーバーロードと表現するとする。
カプセル化という言葉も曖昧だから、アトミック操作と表現するとする。
動的オーバーロードとアトミック操作を明確に区別して、別々の構文を用意する。
すると、オブジェクト指向という言葉はもう要らないわな。

なんせ、
動的オーバーロードがしたい場合は、それ用の構文を使う、
アトミック操作がしたい場合は、それ用の構文を使う、
ただそれだけのことだからな。

消えてなくなったねオブジェクト指向、万歳。
すばらしい整理力だね、今日は気持ちよく眠れる。

103 :デフォルトの名無しさん:2010/04/20(火) 01:07:36
第一引数の話って、それなんてMLのモジュール?

104 :デフォルトの名無しさん:2010/04/20(火) 01:14:28
>>103
モジュールより型クラスだろjk
オーバーロードなんだから

105 :93:2010/04/20(火) 07:59:55
>>102
オーケー、オーケー。
そこまで言うなら、もう、新しくそういう言語処理系を作ってコンセプトを実証してくれよ。
名前は"No More Object"でNoMO言語とかでどうだ?

向こう見ずな信念がイノベーションを起こす可能性も無いとは言えないしな。
俺は応援してるぞ。うん。

というわけで、百の言葉より一のコードだ。早速取り掛かっておくれよ。

106 :デフォルトの名無しさん:2010/04/20(火) 08:08:35
>>105
>102の話はHaskellの型クラスの話だと思われ
有用性は既に実証されている

107 :デフォルトの名無しさん:2010/04/20(火) 08:09:59
>>106
解説して。

108 :デフォルトの名無しさん:2010/04/20(火) 08:15:22
あと、その型クラスというコンセプトが「(OOが適用可能な)あらゆる場面で」OOより有用であることの証明も。
ある局面において有用、というのはもちろんそうだろうけど、アンチOO君が言ってるのはそういうことじゃないしな。

109 :デフォルトの名無しさん:2010/04/20(火) 12:18:21
(map (lambda (x y z) (+ x y z)) '(1 2 3) '(4 5 6) '(7 8 9))
map(lambda x,y,z:x+y+z,[1,2,3],[4,5,6],[7,8,9])

[[1,2,3],[4,5,6],[7,8,9]].transpose.map{|x,y,z| x+y+z}
たしかに無理にOOに拘ってると醜いよな
3つのオブジェクトを1つにまとめて転置するとか思考にノイズが入る

110 :デフォルトの名無しさん:2010/04/20(火) 18:48:14
例えば、電子レンジで卵を爆裂させて、

「電磁波で加熱するなんて方式は自然の摂理に反している。キモい。」
「流行に踊らされるな。火を使った加熱調理が最も自然な方法なのだ。」

とか言いながら焚き火を始める奴はまぁいないわけだが。

111 :デフォルトの名無しさん:2010/04/20(火) 19:06:12
Haskellの流行に踊らされるな。責務ベースのオブジェクトを使ったプログラム作成が最も自然な方法なのだ。

112 :デフォルトの名無しさん:2010/04/20(火) 19:56:23
「電子レンジで卵を調理する奴が悪い」。それだけの話。
電子レンジで卵が調理できないことと、
電子レンジというコンセプトそのものの是非は何の関係もない。


ところで、Haskellはダメだなんて主張してる奴はいたか?

113 :デフォルトの名無しさん:2010/04/20(火) 20:48:43
OOPって、プログラムを単純化する手法であって、複雑化する手法ではないのだが...


114 :デフォルトの名無しさん:2010/04/20(火) 21:01:20
多重ディスパッチとかマルチメソッドという既存の言葉があるのになんで動的オーバーロードなんて自分用語使ってるんだろう

115 :デフォルトの名無しさん:2010/04/20(火) 21:07:35
MATLABのメソッド呼び出しは
method(obj1, arguments... )
の形式だな
最近
obj1.method(arguments ...)
の書き方もできるようになったみたいだけど

116 :デフォルトの名無しさん:2010/04/20(火) 21:47:57
>>110
電磁波っていうか遠赤外線は大事
結局電磁波だけど

117 :デフォルトの名無しさん:2010/04/20(火) 23:32:49
オーバーロードを、オブジェクト指向の多態性だと言っている奴は馬鹿なの?
どんな勉強したら、そんなアホな考えになるんだ?

オブジェクト指向が良い悪いと言う前に
もう一度、イチからオブジェクト指向を勉強した方がいいぞ。

118 :デフォルトの名無しさん:2010/04/20(火) 23:42:53
オブジェクト指向の話ってすぐに「言葉の意味」の議論に落ちて、肝心の話が進展しないよね
いつもそう
まぁ、所詮定義も糞もない文系脳の生み出した経験論だからしょうがないか

119 :デフォルトの名無しさん:2010/04/20(火) 23:50:50
お前みたいに論理的に話せない奴が理系代表みたいに思われるのは心外だからやめてくれ。

120 :デフォルトの名無しさん:2010/04/21(水) 01:27:39
OOPの定義は複数あるんじゃない?

・メッセージング
・カプセル化 / 継承 / ポリモーフィズム

あと何かあった気がするが、とりあえず…
メッセージングとカプセル化は、結構別物だと思う。

どの階層で纏め上げるかによるけど、「抽象化」が大事なんじゃないかなー。
例えば、ファイルなら、ファイルという抽象化オブジェクト。
後は、ファイルの操作をオブジェクトにつければよい。

内部処理は、さらに下位層での話しになる。


121 :デフォルトの名無しさん:2010/04/21(水) 08:16:48
>>120
http://d.hatena.ne.jp/sumim/20040525/p1
http://d.hatena.ne.jp/sumim/20080415/p1

122 :デフォルトの名無しさん:2010/04/21(水) 08:36:42
カプセル化してメッセージ送って動作すると聞いて
それぞれのインスタンスのメソッドの中のループが
全部独立して動作すると思ってた漏れが通りますよ

っつーか実際のところ
擬似マルチスレッドなのか
本当にマルチスレッドなのか
良くわかりません

123 :デフォルトの名無しさん:2010/04/21(水) 08:39:13
>>121

通りすがりの2chネラ 2008/05/20 14:47
  今回元ネタふったのは私なんで, 謝罪に参りました。ご迷惑をお掛けしたようで申し訳ございませんでした。
根がハード屋なもんで, 個人的には「自分がなにすりゃいいか分かってるもの」にコマンドなりメッセージ送りつけて
勝手に動いてくれればオブジェクトなんですけどねぇ。なんで, みんな流儀にこだわるんでしょうか?

124 :デフォルトの名無しさん:2010/04/21(水) 09:37:13
>>122
それなんてErlang?

125 :デフォルトの名無しさん:2010/04/21(水) 09:41:06
>>123
自分がどこまでやるか?
どこから別のオブジェクトに任せるか?
の切り分けが難しいです

126 :デフォルトの名無しさん:2010/04/21(水) 10:24:48
>>122
それアクターモデルとかπ計算とかだよね
でも「メッセージパッシング」といわれて、そういうものを想定するのは
結構自然な発想のような気はする

127 :デフォルトの名無しさん:2010/04/21(水) 11:07:52
obj.method(arg)
が流行ったのは、IDEとの相性がいいからだと思う
obj.までタイプしたら補完が効く
classがプチ名前空間になっていて、名前を絞り込むのに都合がいい

理論的側面や美しさみたいな観点から見ると結構どうでもいいが
実務用言語としては、こういうものが重要になる

func(obj, arg)
だと、名前を絞り込みようがないし
何らかのモジュール機構を持たない言語の場合、funcの
名前を衝突しないようにかなり長くする必要がある
(実際CやEmacs Lispなどはそうだ)

モジュールがある場合は
module.func(obj, arg)
でいいし、これならIDEとの相性もいいのだが、タイプ量が
obj.method(arg)
より多い
もっとも、大抵は名前をimportすることで
module名を省略することができることがほとんどだが

128 :デフォルトの名無しさん:2010/04/21(水) 12:18:11
>>127
ううん。なるほどねぇ。と考えると、現状がやっぱり最適なのかね。
obj.method(arg)の形がキモイっていうのはちょっとだけ思ったけど、代替案とかないかなぁ。

(obj,arg)->Add
(obj,arg)->Sub
(obj,arg)->Multiply
こんな感じで、引数を先に書いておいて、関数を書いてみるとか。
IDEは、引数から関数を絞り込んでおくとかね。

129 :デフォルトの名無しさん:2010/04/21(水) 12:51:18
>>128
それなんてFORTH?

130 :デフォルトの名無しさん:2010/04/21(水) 13:43:54
ここよりはマトモな会話になっててヨカタ
http://pc12.2ch.net/test/read.cgi/tech/1271086841/

131 :デフォルトの名無しさん:2010/04/21(水) 14:06:12
>>128
F#のパイプライン演算子とかそれに近いかもね

132 :デフォルトの名無しさん:2010/04/21(水) 14:24:50
>>127は半分ネタなのであまりまともに受け取らないでw

>>127のような側面も確かにあると思ってるけど、
「C++の流儀で仮想関数を使ったポリモーフィズムでは」
objやmethodが常に静的に決定されるわけではなく
methodはobjのスロットになるので、
obj.method(arg)という記述が自然で、本質的だったのだと思う

静的な場合はただの Class::method(obj, arg) の構文糖と言えるけど
動的な場合は obj.vtbl.method(obj, arg) だから

133 :デフォルトの名無しさん:2010/04/21(水) 14:52:21
>>112
やり方が悪いから爆発させているのであって、だからと言って電子レンジで卵を調理できないと
結論付けるのはいかがなものか。

134 :デフォルトの名無しさん:2010/04/21(水) 15:29:16
そういえば電子レンジでゆで卵を作るための補助装置(金網?)とかあったなw

135 :デフォルトの名無しさん:2010/04/21(水) 19:06:29
>>133-134
「素人にはおすすめできない」くらいでどうだ。

136 :デフォルトの名無しさん:2010/04/21(水) 19:40:30
>>135
いいね。

137 :デフォルトの名無しさん:2010/04/21(水) 20:58:25
>>127
>func(obj, arg)
>だと、名前を絞り込みようがないし
えっ
funcという名前と引数の型と戻り値の型で判定すればいいんじゃね?

138 :デフォルトの名無しさん:2010/04/21(水) 21:06:25
あー
いつもの人だけど、
C++に動的オーバーロード(マルチメソッド)付けて、
かわりに、メソッドを全て非virtualにすれば、結構きれいなんじゃないかな。

そもそも、現状だとポリモしようと思うと、ポリモする型の基底にそれを意識した
インターフェースが必要になったりするけど、それもよくよく考えりゃ変な話だ。
だって、ポリモするのは呼び出し側の都合だろ。
適切なインターフェースを型の定義時に決定してしまわなきゃいけないのは面倒だよ、
だって、その型がどういう風に使われるのか、まだ良く分からないのに。
だから型の定義には、フィールドとアクセサだけを含めるのが筋だと思う。
で、ポリモしたいなら使う側で、動的オーバーロードでアダプタ関数を書いたほうが。

たとえば、デストラクタをポリモさせる必要が出てきたら、そうなってから
void destructor( typename &obj ){ obj.~typename(); }
こんな感じのアダプタ関数をサクッと作ってさ。
わざわざインターフェースクラス作らなくても、同名の関数さえ作ればポリモできる利点が生きてる。
基底クラスに〜をもってなきゃどうのこうの、という煩わしさからも開放される。
なんつーか、本来、ポリモって、呼び出し側の仕事でしょ。それを型に含めるのもなぁ。

139 :デフォルトの名無しさん:2010/04/21(水) 21:12:46
あと、IDEの補完関係の話だけど、
メソッド名じゃなくて、引数を補完すればよいと思う。
func(
まで書くと、取りうる型でかつ参照可能なインスタンスを列挙する。
関数名は一つなのに対し、引数は複数取りうるわけだから、そっちを補完したほうが便利じゃね?
あと、関数名はマニュアルに載ってて決まりきってるけど、
変数名は皆バラバラに付けるし、マニュアルにも載ってないから、
そっち補完したほうがいいのでは。

140 :デフォルトの名無しさん:2010/04/21(水) 21:35:47
同じような機能を持った型があってポリモしたい。
でも、型の提供元が違ってたら、当然基底型も違うだろうし、
そうなるとポリモできない。
仕方ないから、ポリモするためだけのアダプタ型を作ったりする。(むなしいね)

だったらもう、動的オーバーロードでポリモしたほうが素直だろう。
そうは思わんかね。

現状、型の定義に多くを求めすぎだよ。

141 :デフォルトの名無しさん:2010/04/21(水) 21:54:45
>>123
元々色々な出自があったにせよ、少なくとも今は、

『柔軟性やメンテナンス性の高い、高凝集度・疎結合なシステムの実現を目的として、
責務と状態を最小化した「オブジェクト」の集合でシステムを構成するという考え方』

がオブジェクト指向、ということでいいんじゃないかな。
で、それを実現する「手段」については色々と提唱されていると。

で、個々の要素技術の是非はまだまだ議論は収束しないだろうけど、
少なくとも、「高凝集度・疎結合なシステム」に貢献するか否かという軸で評価されるべきだろう。

例えば、obj1.method(...)という記法にしても、「責務を持つ主体を明確化する」というのが
一つの目的なのは確か。これが万能かは別として、多くの問題領域の整理に役立つことは、
既に各方面で実証されている。


ま、どうしても電子レンジで卵をチンしたいなら勝手にすればいいけどさ。

142 :デフォルトの名無しさん:2010/04/21(水) 22:00:25
風呂釜でゆで卵を数個だけゆでるような仰々しさを感じる
もっとも、最終目標は何千個ものゆで卵だろうから風呂釜より大きな鍋が必要になるかもしれない
とりあえず新しい理論の下では誰がその恩恵を受けることになるのだろう

143 :デフォルトの名無しさん:2010/04/21(水) 22:03:12
昔ながらのCスタイルでかつ、C++やJavaよりも強力なポリモ。
構造体内のデータの整合性を守るためのアクセサも完備。(アトミック機能となずけたい)
多くの人は満足すると思うがなぁ。

アトミック機能:
 構造体をなるたけintやcharなどの基本型と同一に扱えるように頑張る機能。
 コンストラクタやデストラクタも含まれる。

動的オーバーロード機能:
 引数に応じて処理を切り替える機能。
 全ての引数に応じて判断する。

これだけありゃマジ十分じゃね?

>>141
オブジェクトが処理の責務を持つ。結構なことですね。
でもどうして其処にポリモ機能まで押し込みますかね。
ポリモは型の責任ですかね。さーどうした。

144 :デフォルトの名無しさん:2010/04/21(水) 22:09:10
まーもっとも、動的オーバーロードを使う機会は、そんなに無いと思ってる。
まずは、型の定義から仮想関数を無くす。それが第一目標。
型の持つべき機能は、データの保持と、そのデータの整合性を取ること。
インターフェース整えてポリモするのは別でやれ。
C++でやるんなら、オーバーロードを動的に拡張するのが手っ取り早い。それだけ。

145 :デフォルトの名無しさん:2010/04/21(水) 22:14:26
仮にインターフェースを整えてポリモできるようにするのが型の責任だったとして、
果たしてその責任は取れるんですかね。
同じような機能の型なのに、インターフェースが違う、基底型が違う、こんなのザラ。
取れもしない責任を押し付けても無意味なんだぜ?
型は自フィールドの整合性を取る、それが精一杯の責任範囲。
だろ?

146 :デフォルトの名無しさん:2010/04/21(水) 22:15:09
>>142
君の言うとおり、真価を発揮するのはまさに何千個ものゆで卵を相手にする時。
(ゆで卵数個でもある程度の恩恵は受けられるけどね。人間はそんなに優秀じゃない)

人間の理解能力の限界を余裕で超える構築物を相手に、
それをいかに人間が理解できるレベルに落とし込むか、という話をしている時に、

「俺のゆで卵は電子レンジで解決できない!」

なんてスコープも目的も違う話を喚かれてもなぁ、という。

147 :デフォルトの名無しさん:2010/04/21(水) 22:20:10
>>144-145
ダックタイピングしたいの?

148 :デフォルトの名無しさん:2010/04/21(水) 22:34:57
>>147
少なくともメソッド名が同じじゃなきゃタッグタイピングは出来ない。
同じ機能は同じメソッドでなきゃならないなんて制約は、まず通用しないだろうね。
そういうのをやりたくないんだよね。どうせ出来ないから。

だから、使う側が動的オーバーロード使ってアダプタ関数作ってインターフェースを整える。
あくまで使う側の都合でポリモしたいわけだから、使う側がインターフェースを整える。
型でインターフェースを整えない。
これは現実問題仕方の無いことだと思う。

実は、おれ自身は動的オーバーロードに消極的で、
どうしてもポリモしたい時のための逃げ道ぐらいに考えてる。
とにかく型の定義から仮想関数や共通に扱うためのインターフェースを排除したい。
これを型に含めるのはおかしい。というか、出来やしない。
これが出来るのは、演算子や文字列への変換など、決まりきってる基本的なことだけ。
出来もしないことは、やらない。やる、とも言わない、言ってほしくもない。

149 :デフォルトの名無しさん:2010/04/21(水) 22:38:07
>>145
> 型は自フィールドの整合性を取る、それが精一杯の責任範囲。
> だろ?

君の能力の限界はそうなのかもしれないが、仮にそうだとして、
何千個ものゆで卵に対して、火打石と薪でチャレンジするドンキホーテと一緒に仕事はしたくないな。

150 :デフォルトの名無しさん:2010/04/21(水) 22:43:27
俺の問題ではない。
多様なライブラリを使うから、ライブラリ間でインターフェースが整わない。
整ってない現状がすでにある。
インターフェースを整える責任はすでに放棄されているに等しい。

151 :デフォルトの名無しさん:2010/04/21(水) 22:43:46
>>148
んで、君はいったいソフトウェア開発における何の課題を解決しようとしているの?

152 :デフォルトの名無しさん:2010/04/21(水) 22:45:34
>>150
> 多様なライブラリを使うから、ライブラリ間でインターフェースが整わない。

そんな壮大で荒唐無稽な話をしてたんだっけか?

153 :デフォルトの名無しさん:2010/04/21(水) 22:46:41
>>151
きれいに整理したい。
とりあえず、型の定義から、インターフェースを整える仕事を排除したい。
それで第一歩かな。
どうせ、整いやしないわけで。別でやったほうがいい。

154 :デフォルトの名無しさん:2010/04/21(水) 22:48:23
>>152
ライブラリ使ったら「壮大」ってのは、それこそ、火打石と薪じゃねーか。
ライブラリぐらい普通に使うだろ、どう考えても。勘弁してくれ。

155 :デフォルトの名無しさん:2010/04/21(水) 22:50:06
>>153
> きれいに整理したい。

> とりあえず、型の定義から、インターフェースを整える仕事を排除したい。

???

>>154
> ライブラリ間でインターフェースが整わない

156 :デフォルトの名無しさん:2010/04/21(水) 22:54:13
部長権限でやるべきことを、平社員が賄ってる現状を何とかしたいんだよ。
ポリモは呼び出し元の仕事。型の定義に含めるべきではない。

157 :デフォルトの名無しさん:2010/04/21(水) 22:58:13
>>156
よく分からんが、それは、君のところの開発体制がダメダメなだけじゃ?

158 :デフォルトの名無しさん:2010/04/21(水) 23:02:18
型は自分のことだけ考えてりゃいいんだよ。
あとは偉い人、制御、処理、プロシージャ、関数が何とかする。
型が自分以外のことをするのは越権行為だ。物事をややこしくする。
インターフェースを整えたり、他のオブジェクトの内容を書き換えたりはしなくていい。
型はアトミックであればそれで良い。その安全さが型の価値だ。

>>156
おれはソフト屋じゃねーから知らん。
部長→関数
平社員→型
の比喩表現だ。

159 :デフォルトの名無しさん:2010/04/21(水) 23:07:33
>>158
> 型が自分以外のことをするのは越権行為だ。物事をややこしくする。

それが、抽象型ベースなオブジェクト指向の考え方なんじゃないの。
インタフェースを整えるのは、自分のすべきこと、すべきでないことを明確にするため。

> おれはソフト屋じゃねーから知らん。

ソフト書かないのにオブジェクト指向スレで暴れるとはまた奇特なお人だな。

160 :デフォルトの名無しさん:2010/04/21(水) 23:13:25
まぁ、自分の美意識を持つことが間違っているとは言わんし、
今でもC言語オンリーで立派な成果を出しているプロジェクトは確かにある。

一方で、いくら「○○であるべき」と言い募っても、オブジェクト指向的な考え方に基づいた
開発で成功しているプロジェクトも既にたくさんある。
前も紹介したけど、一度、オープンソース・プロジェクトのソースコードを読んでみるといい。

161 :デフォルトの名無しさん:2010/04/21(水) 23:18:13
>インタフェースを整えるのは、自分のすべきこと、すべきでないことを明確にするため。

自分のすべきことを明確にするために、インターフェイスを整える必要は無い。
整って無くても何でもいいからメソッドが有ればそれでいい。
無いメソッドは呼べない。有るメソッドは機能するとみなす。
インターフェースを整えるのは、呼び出し元のポリモを意識している。
そんなことはしてもらわなくて結構。おせっかいが過ぎる。
出来もしないおせっかい。後でアダになる。

162 :デフォルトの名無しさん:2010/04/21(水) 23:28:19
>>161
今更だが、「呼び出し元のポリモ」って何? 意識するって具体的には?

163 :デフォルトの名無しさん:2010/04/21(水) 23:30:57
>>162
C++で言えば、共通の基底クラスを持つことだ。

164 :デフォルトの名無しさん:2010/04/21(水) 23:35:44
>>163
さっきのライブラリ間でインタフェース共通化とかいう話もそうだが、
共通って、どれくらいのクラス数を意識した話なんだ?
「継承で共通化で再利用で差分プログラミング!」って、最近はむしろあまり推奨されないだろ。

165 :デフォルトの名無しさん:2010/04/21(水) 23:39:51
同じ継承でも、差分プログラミングとポリモは用途が全然別だろうに。
あー頭痛くなってきた。
正しいこと書けば書くほどバカしか釣れなくなってくる。
もう出涸らしだな、このスレ。今日はこの辺が引き際か。

166 :デフォルトの名無しさん:2010/04/21(水) 23:42:28
君、反論できなくなると必ず勝利宣言してごまかすよね。

167 :デフォルトの名無しさん:2010/04/22(木) 00:27:08
詭弁のガイドライン
13.反論できなくなると必ず勝利宣言

168 :デフォルトの名無しさん:2010/04/22(木) 00:32:23
>>158
勉強したいので、もう少し説明をお願いします

ある型は必要最小限の操作のみを持ち、それ以外は使う時に呼び出し側で変換関数を準備する、ということですか?

たとえばRubyでeachさえ実装すればEnumerableをMixinしてmap等が使えるようになる、というイメージはおっしゃっていることに近いですか?

169 :デフォルトの名無しさん:2010/04/22(木) 01:24:29
>>168
型が操作持つ必要性とかってあるのか?
clos みたく, ある特定の操作が, 型を知ってればええんちゃうの?


170 :デフォルトの名無しさん:2010/04/22(木) 08:09:28
>>168
彼は「オブジェクト=データ型=構造体」という図式を大前提に、
『オブジェクト指向プログラミングの各要素技術は関数と構造体のみで実現できる!』
という主張を繰り返しているだけなので、真面目に話を聞くだけ無駄だと思うよ。
そりゃ、実現自体はできるかもしれないけどな。

>>141でも書いた通り、「高凝集度・疎結合なシステム」という目的に貢献しない
要素技術の話をいくらしても、オブジェクト指向開発の議論とはあまり関係がない。

171 :デフォルトの名無しさん:2010/04/22(木) 08:17:54
>>169
カプセル化はどう実現するんだ?

172 :デフォルトの名無しさん:2010/04/22(木) 17:17:57
>>138
実行時に、全引数の実行時型に基づいてグローバルに関数検索することで
多態を実現するんだよな?
それは分かるしいいとして、型自体は静的型なのか動的型なのか、
どういう言語を想定してるのか、ちょっとよくわかんなかった

型が静的に決定されるケースだと、そもそも多態にはならんし
実行時検索は要らんよね?

動的型のようなものを考えているのか
継承・クラスベース&参照型なのか

173 :デフォルトの名無しさん:2010/04/23(金) 03:50:51
>>138
便乗質問です。
「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。
同じメソッドや関数を呼び出しても、対象や引数の型によって異なる動作をするのがポリモだと思うのですが、
呼び出し側の都合で動作を変えられるべきだということですか?

174 :デフォルトの名無しさん:2010/04/23(金) 08:34:46
どうでもいいからお前らコード書けよ
道具に机上で妄想や俺ルールで文句垂れるより実例示せ


175 :デフォルトの名無しさん:2010/04/23(金) 13:02:58
>>173
138じゃないが、オーバーロードはオブジェクト指向の多態性では無い。
オブジェクト指向の多態性は、呼び出し側は、どの機能が実行されるか意識する必要はない。
オブジェクト自身が、どの機能を実行するかを判断する。

オブジェクト指向基本は、書いて字のごとくオブジェクトを指向する、つまりオブジェクトを主体に考えるパラダイム・シフト。

138は、オーバーロードじゃなくアダプタ関数を勧めていたが(Adapterパターンで無いようだが?)
始めから、1つのメソッドに対して異なる機能があると分かっている場合の
オブジェクト指向的なコーディングするのなら、Strategyパターンで機能を「オブジェクト」として実装する。

176 :デフォルトの名無しさん:2010/04/23(金) 21:30:27
>型が静的に決定されるケースだと、そもそも多態にはならんし
>実行時検索は要らんよね?

あるインスタンスの型が静的に決定されていたとしても、
参照やポインタの指すインスタンスの型は動的に判断されることが望まれる。
C++でやるなら、void *p の指す型を正しく判別できる必要があるね。

>「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。

ポリモは何のためにある?
呼び出し側のコードを一元化するためだろ?

>オーバーロードはオブジェクト指向の多態性では無い。

脱OOPの為に色々策を講じてるわけだから、俺からすりゃそりゃ本望だ。

>オブジェクト指向基本は、書いて字のごとくオブジェクトを指向する、
>つまりオブジェクトを主体に考えるパラダイム・シフト。

手続き型言語の主体はオブジェクトではなくて処理だと言ってるわけで。
それは、プログラムの機能が「処理でオブジェクト間の関係を定義する」ことで成り立ってるから。
オブジェクト間の関係の定義が、そのオブジェクト自体に含まれるのは都合が悪い。思考の妨げになる。
上手くいくのはアクセサぐらい。なぜならアクセサは自己完結だから。

177 :デフォルトの名無しさん:2010/04/23(金) 21:48:14
OOPやるにはアクセサが一番思考の妨げになるけどな

178 :デフォルトの名無しさん:2010/04/23(金) 21:49:24
適当な関数が見つからないという
一般的な静的型言語ではありえない状況がごく頻繁に起こりそうだけど
それに関してはどうすんの
実行時エラー?

179 :175:2010/04/24(土) 00:51:08
>>176
>手続き型言語の主体はオブジェクトではなくて処理だと言ってるわけで。
>それは、プログラムの機能が「処理でオブジェクト間の関係を定義する」ことで成り立ってるから。
「処理でオブジェクト間の関係を定義する」は間違い、「メッセージでオブジェクト間の関係を定義する」が正しい。
なぜ、オブジェクト指向はメッセージと言う言葉を使うのか理解出来ない奴は、オブジェクト指向を理解していない。

上でも書いたが、オブジェクトが主体的に動くもので、そのオブジェクト間のメッセージは非手続き(4GL)な関係になる。
・処理(手続き)---相手から決まった順番で複数回の通信することにより、機能を実現する。
・メッセージ ---相手から1回の通信で、機能を完結する。(メッセージパッシング)

>オブジェクト間の関係の定義が、そのオブジェクト自体に含まれるのは都合が悪い。思考の妨げになる。
>上手くいくのはアクセサぐらい。なぜならアクセサは自己完結だから。
意味がよく分からんが、オブジェクト間の関係など意識する必要はない、逆に意識が必要なら
それは、オブジェクト間が手続きになっている証拠。

180 :デフォルトの名無しさん:2010/04/24(土) 01:27:05
>>176
> >オーバーロードはオブジェクト指向の多態性では無い。
>
> 脱OOPの為に色々策を講じてるわけだから、俺からすりゃそりゃ本望だ。

それで、君のオレオレオーバーロードは「高凝集度・疎結合」という目的の実現に対して
具体的にどういうメリットがあるの?

181 :デフォルトの名無しさん:2010/04/24(土) 01:29:40
もうオブジェクト指向は捨てて関数型言語になればいいのに

182 :デフォルトの名無しさん:2010/04/24(土) 01:35:39
オブジェクト指向+関数型なScalaの時代が来るので無問題。

183 :デフォルトの名無しさん:2010/04/24(土) 01:42:17
>>182
最初は注目されてたけど。どっちも中途半端。

184 :デフォルトの名無しさん:2010/04/24(土) 01:43:52
別に尖ってりゃいいってもんでもないしなぁ。

185 :デフォルトの名無しさん:2010/04/24(土) 01:53:28
CommonLispの出番だな

186 :デフォルトの名無しさん:2010/04/24(土) 13:05:59
関数型言語にはラムダ計算という数学的な理論がベースにあるらしいのですが
オブジェクト指向にも何か理論があるのですか?

187 :デフォルトの名無しさん:2010/04/24(土) 14:21:15
文系は思想を学ぶ
理系は理論を学ぶ

文系出身者は思想ばかりで理論を伴わない故に説得力に欠ける
理系出身者は理論ばかりで思想を伴わない故に協調性に欠ける

188 :デフォルトの名無しさん:2010/04/24(土) 14:51:12
>>187
良いこと言う

あと、実地や経験を伴わない哲学は中二病に似たりとも言う


189 :デフォルトの名無しさん:2010/04/24(土) 14:58:21
>>187
協調性に欠けていても、出力が有用なら価値がある。
協調性があっても、出力が(ry

190 :デフォルトの名無しさん:2010/04/24(土) 16:38:44
>>176
回答いただきありがとうございます。

>>「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。
>ポリモは何のためにある?
>呼び出し側のコードを一元化するためだろ?

ポリモは同じ操作が適用できるものを統一的に扱うためにある
と考えていました。
確かに呼び出し側のコードが一元化されます。

そう考えると、呼び出し側でどの操作セットが必要かが変わるため、
型でインターフェースを整える必要はない(>>158)という意見も
理解できてきた気がします。


191 :デフォルトの名無しさん:2010/04/24(土) 16:41:35
たとえば呼び出し側でequalsメソッドのみが必要な場合、
通常は次のようにクラス定義でComparableインターフェイス
のようなものを実装すると思います。

interface Comparable {
 boolean equals(Object o);
}

class MyClass implements Comparable {
 boolean equals(Object o) {
 //
 }
}

しかし、呼び出し側で必要な操作セットはプログラムによって異なるため、
このようなインターフェイスをクラスの作成時に網羅して準備するのは不可能です。

ならばMyClassはimplementsのないシンプルなものにしておいた方が良いというのも理解できます。
その場合に、もしequalsを実装しているクラスの集合を「呼び出し側で」定義でき、
それを使ってポリモで呼び出せるならば、その方がシンプルで良さそうな気がします。

implements Comparable { MyClass, SomeClass, ... } // 構文は適当です
Comparable c[2];
c[0] = new MyClass;
c[1] = new SomeClass;
// この後、ポリモで使う
if (c[n].equals(something)) { // }

192 :デフォルトの名無しさん:2010/04/24(土) 18:09:29
AOPとは違うもの?

193 :デフォルトの名無しさん:2010/04/24(土) 18:24:26
> 「処理でオブジェクト間の関係を定義する」は間違い、「メッセージでオブジェクト間の関係を定義する」が正しい。
> なぜ、オブジェクト指向はメッセージと言う言葉を使うのか理解出来ない奴は、オブジェクト指向を理解していない。

だから、そのオブジェクト指向とやらが嫌だと言ってるんだが。
手続き型言語だったら、素直に手続きで定義すりゃいいだろ。

> 上でも書いたが、オブジェクトが主体的に動くもので、そのオブジェクト間のメッセージは非手続き(4GL)な関係になる。

あー染まってるな。
オブジェクトが主体的に動く?きめぇ。
主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。

> ・処理(手続き)---相手から決まった順番で複数回の通信することにより、機能を実現する。
> ・メッセージ ---相手から1回の通信で、機能を完結する。(メッセージパッシング)

↑これどうする?かなりアホな発言に見えるのだが。

こういい直すことも出来る。

・関数の中身 --- 決まった順で処理を逐次実行することにより、機能を実現する。
・関数の呼び出し --- 一回の呼び出しで、その関数の機能は完結する。

ちょっとは考えてから発言すれば?

194 :デフォルトの名無しさん:2010/04/24(土) 18:29:36
俺は

> ・処理(手続き)---相手から決まった順番で複数回の通信することにより、機能を実現する。
> ・メッセージ ---相手から1回の通信で、機能を完結する。(メッセージパッシング)

が気に入ったからもっと弄ってやろうと思う。

手続きって何だ?

<完結した処理1>;
<完結した処理2>;
<完結した処理3>;

こういうことだよね。

この、一つ一つの<完結した処理#>をメッセージとリネームすることは勝手だけど、
<メッセージパッシング1>;
<メッセージパッシング2>;
<メッセージパッシング3>;
こうなるだけで、結局は同じことだよね。

195 :デフォルトの名無しさん:2010/04/24(土) 18:31:03
>>193
>主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。

その発想が非OOP脳なんだろうな。

196 :デフォルトの名無しさん:2010/04/24(土) 20:03:00
>>193
>だから、そのオブジェクト指向とやらが嫌だと言ってるんだが。
>手続き型言語だったら、素直に手続きで定義すりゃいいだろ。
だったら「関数」を使え、「オブジェクト間」とか使うなアホっほいぞ。

>あー染まってるな。
>オブジェクトが主体的に動く?きめぇ。
>主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。
管理するとか、本当にバカだな、管理すると言う事は主従関係だぞ。

>・関数の中身 --- 決まった順で処理を逐次実行することにより、機能を実現する。
>・関数の呼び出し --- 一回の呼び出しで、その関数の機能は完結する。
何を言っている? バカか? 「関数の中身」と「関数の呼び出し」って、大丈夫か?

>>194
>手続きって何だ?
俺に聞くな、そんな事も分からないのか? 本当にバカ? 大丈夫か?

><完結した処理1>;
><完結した処理2>;
><完結した処理3>;
>こういうことだよね。
ぜんぜん違う。 なにも分かってないのか?

おまえ、駄目だ。

197 :デフォルトの名無しさん:2010/04/24(土) 20:07:41
「主体的に動くオブジェクト間のメッセージパッシング」って
アクターモデルだろう

一般にOOPってそういうものを言ってるのか?
Smalltalkですら違うと思うんだが

198 :デフォルトの名無しさん:2010/04/24(土) 20:44:38
>>191
それなんて構造的部分型?

199 :デフォルトの名無しさん:2010/04/24(土) 22:49:25
>主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。

OO が嫌いな人は、全部の流れを一度に把握することにこだわっているんじゃないかな。
OO は、全体の設計をする時には部分の仕様を気にしないでいいようにするためのものだよね。

200 :デフォルトの名無しさん:2010/04/24(土) 23:15:25
>>199
あと、部分を実装する時に、他の部分の実装を気にしなくても済むのもメリットだね。
「オブジェクト同士の依存関係で破綻する」という反論が来るかもしれないが、
実装の前に、オブジェクト間でそういう依存関係を持たないように設計するのは大前提。
そもそも、「全部の流れを一度に把握する」などというのは、大規模になるほど不可能になる。

201 :デフォルトの名無しさん:2010/04/25(日) 03:25:04
構造化の普及期は、関数の呼び出し関係という点では、すっきり単純になることが志向されたけど、
OO の世界では、自分の責任範囲でないデータのアクセスはたとえ1行で済む内容でも責任者を呼び出すし、
呼んだ先で何が実行されているかわからない(わからなくていい)形になる。
全部の流れを一度に把握することに拘っていると、OO は嫌いになるだろうな。


202 :デフォルトの名無しさん:2010/04/25(日) 03:32:28
だからとんでもなく遅くなるんだね

203 :デフォルトの名無しさん:2010/04/25(日) 09:53:50
>だからとんでもなく遅くなるんだね
"とんでもなく"までは、遅くならないが
構造化より遅いのは確か。
でも、その構造化も非構造化より遅い。

速さを追求したいなら、GOTO文を多用すればいい。

204 :デフォルトの名無しさん:2010/04/25(日) 11:11:58
>>202は、数十万行のスパゲッティコードを苦も無くメンテできる天才プログラマなんだよ。

205 :デフォルトの名無しさん:2010/04/25(日) 12:42:41
>>197
お前分かってるね。
>>179 = >>196 は、OOPすらよく分かっていない。
その癖声だけ大きい。こういうのがOOPの評価を無駄に落としている。
だから俺はOOPを嫌いになったし、距離を置きたくなった。

それからActorモデル、こういうのは、
カーネルからのアプリのエントリーポイントのキックなど、
呼び出し元のコードが一切触れない、変更できない、再コンパイル出来ない、
制限の元で「仕方なく」使われるもので、
好き好んで使う奴は居ないと言うこと。

> 管理するとか、本当にバカだな、管理すると言う事は主従関係だぞ。

この発言も面白かったな。
ソフトウェアエンジニアと、プログラムの関係が主従関係なのは当たり前だろ。
彼の中ではプログラムと人間が対等だったりするのだろうか。オー怖い怖い。
だいたい、コンピュータってのは、奴隷の代わりに発明されたものでだな。

206 :デフォルトの名無しさん:2010/04/25(日) 13:06:33
>>201
それはカプセル化であって、OOPではないわな。
そんで次はこういう方向へ話が行く。「だったらOOPって一体何よ」ってね。
そんで、カプセル化とポリモを合わせ技にして、「オブジェクトの振る舞いを定義して〜」って話になる。
このようにOOPの用語は極めて曖昧で、そもそも議論が成り立たない。

なぜこんなことになるかというと、それは、ポリモとカプセル化の構文が同じだから。
カプセル化のついでに、同じところにポリモも押し込んだから。
なんだかよく分からない状態だから、OOPとか言って抽象的にしてお茶を濁す。
挙句の果てにパラダイムシフトとか適当なことを言い出す始末。

事態を改善するためには、機能ごとに構文を分ければよい。

俺はこう分けた。

カプセル化 → 構造体へのアクセサ。C++での非仮想メソッド。
           ポリモはしない。構造体なりをアトミックに扱うための機能。
ポリモ → 関数の動的オーバーロード。ポリモ目的。

目的と手段の対応が明確なので、OOPとかいった変な言葉も、パラダイムシフトも必要ない。
(パラダイムシフト(笑) この場合ズレてるってことだよな )
C言語の正統な拡張、本来あるべきはずだったC++の姿と言えるね。

207 :デフォルトの名無しさん:2010/04/25(日) 13:47:21
>>205-206
構文をどう呼称するとかどうでもいいから、
君が提唱するそれが、開発の容易性にどう貢献するのか論証してくれ。

208 :デフォルトの名無しさん:2010/04/25(日) 13:57:19
>>205
> だいたい、コンピュータってのは、奴隷の代わりに発明されたものでだな。

それは何の話?
計算尺?そろばん? 階差機関? チューリングマシン? ABC? ENIAC?
それとも、どこか別の並行宇宙での歴史の話をしてるのかな。


まぁ、そろばんを「奴隷」と呼ばわる趣味があるのなら止めないけどね。

209 :デフォルトの名無しさん:2010/04/25(日) 14:06:26
時々OOPである糞な例として、
独立して存在する各オブジェクト同士が、互いにメッセージ投げ合って、互いに協調して、動くという、
いわゆる、アクターモデルがある。
プログラムがまるで何かのシミュレーターみたくなってる奴な。
しかし、オブジェクト同士の化学反応の結果が、目的の機能になってなきゃならないってのは、
シミュレーション自体が目的の場合を除き、誰がどう考えても遠回り。
こういうのはOOPすら良く分かってないし、思考回路が壊れてるから精神科に行ったほうが良い。

> 「オブジェクトが主体的に動くもので」

こう言うこと言い出す奴には、なるべく近づかない事だ。火傷するぜ?
追い詰めるとファビョり出すからな。放っておくしか仕方ない。
そのうち自分で気づくさ。何が大切なのか。

210 :デフォルトの名無しさん:2010/04/25(日) 14:12:20
>>208
そろばんは逐次実行できないよね。
いわゆるコンピュータには、なぜプログラムカウンタがあるのかを考えてみよう。

211 :デフォルトの名無しさん:2010/04/25(日) 14:12:27
> しかし、オブジェクト同士の化学反応の結果が、目的の機能になってなきゃならないってのは、
> シミュレーション自体が目的の場合を除き、誰がどう考えても遠回り。

そんな風に考えるのは君だけなので、勝手に他の人間を巻き込まないように。
論理的に考えられない奴ほど、「みんなが言ってるから正しいに決まってる」とか言いたがるよな。

> そのうち自分で気づくさ。何が大切なのか。

言ってることが、どっかのスピリチュアル(笑)な宗教の教祖と変わらんな。
プログラマなら、主張は具体的かつ論理的に書いてくれ。

212 :デフォルトの名無しさん:2010/04/25(日) 14:17:00
>>210
「逐次実行」の定義は?

213 :デフォルトの名無しさん:2010/04/25(日) 14:20:13
「時々OOPである糞な例として、」
と事前に稀な事例であることを断ってるだろ。
でも、そういう落ちこぼれを生んでしまう危険性がOOPにはあると思う。
たぶん、「オブジェクトの振る舞いを定義して〜」ってのがマズいんだろうな。
この、お茶を濁した大人の発言を、本音と建前の分からない奴が、
変な風に都合よく解釈しちゃうのだろう。OOPに罪があるわけじゃないんだけどね。

214 :デフォルトの名無しさん:2010/04/25(日) 14:22:34
>>213
> 「時々OOPである糞な例として、」

日本語でおk

215 :デフォルトの名無しさん:2010/04/25(日) 14:22:54
もう、揚げ足取りしか出来ないのなら書き込むなと言いたい。
お前らは俺を玩具にしたいだけなんだろ。

216 :デフォルトの名無しさん:2010/04/25(日) 14:25:36
>>215
> お前らは俺を玩具にしたいだけなんだろ。
何その萌えキャラw

ちなみに俺は>>197だが、レスあんがと
>>178にもレスくれると嬉しい



217 :デフォルトの名無しさん:2010/04/25(日) 14:34:52
>>215
君の発言がことごとく論理的でなくて解釈に困るから、いちいち確認を取らざるをえないだけ。

「逐次実行」発言にしたって、「記憶されたプログラムを解釈して」逐次的に演算を行う、という意味なら、
「プログラムを記憶する」の部分はコンピュータの利便性を高めるために提案されたものであって、
計算機という存在の本質ではない(例えば、最初期の真空管コンピュータはストアード・プログラム方式ではなかった)。

218 :デフォルトの名無しさん:2010/04/25(日) 15:00:01
結局、君が何を言っても突っ込みどころ満載なのは、端的に無教養だからだよ。

自分が拠って立つモノが、根本的にどんな原理に基づいているのかに無頓着だし、
だから、それがどういう由来(歴史)で形成されてきたについても全く無関心。
その上、自分の狭く偏った視野に固執し、新たな概念に学ぼうともしない。

これなら、君が嫌いであろう単なる新しモノ好きの方が、技術屋としてはよっぽど「使える」。

219 :196:2010/04/25(日) 15:37:12
>>197
>「主体的に動くオブジェクト間のメッセージパッシング」って
>アクターモデルだろう
アクターモデルもメッセージパッシングを使うが
メッセージパッシング=アクターモデルではない。
http://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%83%91%E3%83%83%E3%82%B7%E3%83%B3%E3%82%B0#.E3.83.A1.E3.83.83.E3.82.BB.E3.83.BC.E3.82.B8.E3.83.91.E3.83.83.E3.82.B7.E3.83.B3.E3.82.B0

>一般にOOPってそういうものを言ってるのか?
>Smalltalkですら違うと思うんだが
一般的なオブジェクト指向言語は処理の並立性は保証していないし
ターゲットのマシン・OS自体も並立処理に不十分で、アクターモデルではない。

それに、オブジェクトを使う時に
1.インスタンス作成
2.メソッド実行
3.インスタンス破棄
と、基本的に逐次的に実行しないといけない。
しかし、すくなくともメソッド実行はメッセージパッシングを目指すべきだ。
「Smalltalkですら違う」それは、プログラマーの問題で、言語の問題ではない。
それに最初のオブジェクト指向言語Simulaは、メッセージパッシングだ。

220 :デフォルトの名無しさん:2010/04/25(日) 15:40:32
カプセル化=アクセサみたいに言ってるのがもうダメだわ

221 :デフォルトの名無しさん:2010/04/25(日) 15:45:07
プログラムのスレで単にコンピュータって言えば、
逐次実行可能な(プログラミング可能な)物を指していると言うことぐらいは分かるだろうよ。
プログラムのスレでプログラミング不可なコンピュータ、まして、ソロバンの話をするわけ無いだろう。

>>216
実行時エラーでいいと思う。もしくは何もしないか。

222 :デフォルトの名無しさん:2010/04/25(日) 15:49:13
>>219
なに言ってんだこいつ。
>>197は、メッセージパッシングについてではなくて、
「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
メッセージパッシングなんぞ、どうてもよい。

223 :デフォルトの名無しさん:2010/04/25(日) 15:59:59
>>221
レスあんがと

どうもポリモーフィズムに関する事柄は完全に動的型言語っぽい形になるようだね
それはそれでアリだが
そういう方向だと、C++やJavaが使われている領域で代用するのは厳しいんじゃないの
っていうかぶっちゃけCLOS?

俺個人の考えを言うと、静的型の言語では、
型安全でコンパイル時に確定可能な静的ポリモーフィズムで十分な部分は
静的ポリモーフィズムを用いるべきだし
動的な部分は、TypeErasureみたいなテクニックを言語のレベルで綺麗に
取り込んで、型安全なダックタイピングが実現できればいいなと思う
そうなってれば、伝統的なISA継承によるポリモーフィズムは要らない

224 :デフォルトの名無しさん:2010/04/25(日) 16:07:27
このスレ自体が役に立っていないなwww

225 :デフォルトの名無しさん:2010/04/25(日) 16:08:24
>>221
どちらにしろ、いわゆるフォン=ノイマン・アーキテクチャ登場以前の
アナログ・コンピュータを含めたコンピュータの歴史のどこをどう切っても、
「コンピュータは奴隷の代わりに発明された」なんて話は出てこないけどな。

226 :デフォルトの名無しさん:2010/04/25(日) 16:12:56
>>209
> こういうのはOOPすら良く分かってないし、思考回路が壊れてるから精神科に行ったほうが良い。

ダン・インガルスもアラン・ケイも重症患者にされそうな勢いだな。(もちろん反語的に)

- Smalltalkの底を流れる設計思想
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24

- 「ソフトウェア工学」は矛盾語法か?
http://metatoys.org/oxymoron/oxymoron.html

227 :デフォルトの名無しさん:2010/04/25(日) 16:13:42
ん?
コンピュータは当時の戦争で弾道計算に利用されていた
手回し式計算機を置き換えるものとして開発されたんだが?
それをまわしてたのは奴隷だぜ?

228 :デフォルトの名無しさん:2010/04/25(日) 16:15:00
>>210
CPUの本質はプログラムカウンタじゃないからw

229 :219:2010/04/25(日) 16:26:00
>>222
>「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
なにが、言いたい?お前「主体的」の意味が分かってないのか?
もしかして、「自立的」とか「自律的」と間違っていないか? お前は「小学4年生」かw
お前は、もういいよ。

230 :デフォルトの名無しさん:2010/04/25(日) 16:28:17
>>227
「弾道計算 奴隷」でググってみたが、そんなソースは見当たらないぞ。
仮にその話が本当だとして、奴隷という動力の置き換え先は「電力」だろ。

どの道、道具を奴隷呼ばわりするタイプの人とはあまりお付き合いしたくないが。

231 :デフォルトの名無しさん:2010/04/25(日) 16:31:40
もうその話題は終わってる

232 :デフォルトの名無しさん:2010/04/25(日) 16:33:24
>>222
>>229
これwww

233 :デフォルトの名無しさん:2010/04/25(日) 16:40:20
>>223
個人的にはダックタイピングもメソッド名をそろえなきゃいけない制約がうざいかなぁと思ってる。
似た機能のメソッドが同じ名前でなきゃ駄目ってのもなぁ。
TypeErasureであれなんであれ、結局アダプタクラス作るわけで、なんかスッキリしない。

しかし、動的オーバーロードの型安全性か。たしかに課題だなぁ。
実は静的に型安全性を保障できないと言うわけでもないんだけど、(リンク時にエラーとすることは可能)
マルチメソッドは組合せ爆発が起こるから、
実際には利用されない引数の組み合わせなんかも有ったりして、その辺がネックだなぁ。

234 :デフォルトの名無しさん:2010/04/25(日) 16:55:00
>>229
なんでだよ。アクターモデルのアクターは自律しては動かないだろ。
勝手な妄想はよしてくれ。

> 「主体的に動くオブジェクト間のメッセージパッシング」って
> アクターモデルだろう

元の文はこれだろ?
お前は何でこれの「メッセージパッシング」だけを拾ってきて、

> アクターモデルもメッセージパッシングを使うが
> メッセージパッシング=アクターモデルではない。

とか言ってんだよ。そりゃメッセージパッシング!=アクターモデルなのは自明だろ。

235 :デフォルトの名無しさん:2010/04/25(日) 17:05:22
日本語力に問題がある奴と話をするとほんと疲れるな。。

236 :デフォルトの名無しさん:2010/04/25(日) 18:00:21
>>226
http://metatoys.org/oxymoron/oxymoron.html
今ここ読んできたけど、マジだな。
はぁー、こういうのに感化されるわけか。大変だな。

まー俺なんかは素直なもんだから、
手続き型言語と対立するのはLISPなどの関数型言語やSQLなどの宣言型言語だと思うし、
対抗馬にOOPを持ってこようとは思わないがなぁ。

インターネットがどうとか言ってるが、
インターネットが、ほんの僅かの単純な機能を成り立たせるために、
一体どれだけ複雑なシステムになってしまっていることか。
そこには粒度の問題があって、はたしてこれは言語レベルでサポートする必要はあるのかね。
小さな粒度では無駄に複雑になるだけだし、大きな粒度ならCで書いても十分だし。

237 :デフォルトの名無しさん:2010/04/25(日) 18:12:13
>>236
> インターネットが、ほんの僅かの単純な機能を成り立たせるために、
> 一体どれだけ複雑なシステムになってしまっていることか。

目の前の問題を短絡的に解決するだけの技術だったら、
ここまで色々な使い方を容れられるインフラにはならなかったよ。
人が構築物を作り上げるのに「神」の視点をもってすることの愚かさを知るべき。

> しかしまたこれらの発明者たちも、これらの問題を直接ゴリ押しでは(「神」のようにという
> 言い方も出来る)解決出来ないと感じる程度に賢明だった。その代わり、このような問題
> に対する巧妙な手口を見つけ出したのだ。兵術の前に策略を用い、失敗を回避せずに
> 受け止める事だった。

238 :デフォルトの名無しさん:2010/04/25(日) 18:24:09
>>187ナイス

アランケイのその文章ってSqueakの文系的宣伝だよね?
SunがJavaに関して吹きまくっていたハイプとそっくりだわ

239 :219:2010/04/25(日) 18:24:39
>>234
自分で書いたことも忘れたのか?
>>222
>「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
見苦しい、いくら言い分けしても、お前が「主体的に動くオブジェクト」を
アクターモデルと考えたことに変わりない。

>>235
>日本語力に問題がある奴と話をするとほんと疲れるな。。
日本語が得意なお前に質問だ。 日本語が得意なお前なら分かるよな。

>「主体的に動くオブジェクト間のメッセージパッシング」って
>アクターモデルだろう
この場合の述語「アクターモデルだろう」が指している主語はどれだ?

@「主体的に動くオブジェクト間のメッセージパッシング」は、アクターモデル。
A「主体的に動くオブジェクト」は、アクターモデル。
B「オブジェクト」は、アクターモデル。
C「オブジェクト間のメッセージパッシング」は、アクターモデル。
D「メッセージパッシング」は、アクターモデル。
お前は、書いた”本人”じゃないのに、D「メッセージパッシング」は間違いで
A「主体的に動くオブジェクト」と決め付けた、なぜそれだと思った?
詳しく説明してくれ。


240 :デフォルトの名無しさん:2010/04/25(日) 18:45:22
>>237
人間は分業したからこそ、ここまでの技術力を持ったんだよなあ。

241 :デフォルトの名無しさん:2010/04/25(日) 18:49:02
まるでOOでなければ分業できないとでもいうような言い草だな

242 :デフォルトの名無しさん:2010/04/25(日) 18:55:09
>>241
少なくとも、問題領域を分割して分業するための優れた方法ではある。
唯一の方法だとは誰も言っていない。

243 :デフォルトの名無しさん:2010/04/25(日) 19:35:45
>>242
そりゃすまんかった
もう少し、具体的に例でも出して問題意識とか得意不得意を挙げていかないと
建設的な話に転がっていかない気がするよ

哲学だけじゃ腹の足しにはなりゃしねえ
ttp://www.sampou.org/haskell/article/whyfp.html
これはただの宣伝文じゃなくて、少なくとも具体的だ

244 :デフォルトの名無しさん:2010/04/25(日) 19:40:56
>>243
> 具体的に例

デザインパターン。

245 :デフォルトの名無しさん:2010/04/25(日) 19:53:11
いやデザパタはあくまでOOの上の問題解決法だから、こういうスレで
デザパタから始めるのは視野が狭い
たとえば関数型なら、状態を扱うデザパタの多くは問題外だろう

246 :デフォルトの名無しさん:2010/04/25(日) 22:10:59
OO厨はドヤ顔で語るけど、実のところデザパタはバッドノウハウなんだがな。

247 :デフォルトの名無しさん:2010/04/25(日) 22:24:47
>>246
kwsk

248 :デフォルトの名無しさん:2010/04/25(日) 22:49:24
デザパタはバッドノウハウ(キリッ

249 :デフォルトの名無しさん:2010/04/26(月) 11:08:43
>>246
正確には「デザインパターンの大部分はバッドノウハウである」じゃないでしょうか。

>>247
関数型言語なら状態を扱うデザパタは不要です。
動的型言語なら静的型言語の制約を緩めるデザパタは不要です。
GoFデザインパターンの大部分はC++やJavaが手続き型で静的型だから
必要なのであって他の言語であればそもそも不要だから
C++やJavaに固有のバッドノウハウです。

250 :デフォルトの名無しさん:2010/04/26(月) 18:23:10
>>239
> >日本語力に問題がある奴と話をするとほんと疲れるな。。
> 日本語が得意なお前に質問だ。 日本語が得意なお前なら分かるよな。

あーごめん、それ書いたの俺じゃないんだ。
お前普通に痛い子だから、多分あちこちに敵が居るぞ。
いいかげん、お前の面倒見るの大変だから、さっさとお仲間さんのところへ行ったら?

>>237
いや、そうなんだけど、なんて言うかな。
インターネットってすげぇ壮大な仕組みだけど、
最終的な機能だけに着目すれば、データのコピーが出来るだけ。
C言語で言えばmemcpy相当。
インターネットの猿真似すりゃ、memcpyですら、あんな壮大になってしまうわけで、
よほどの制限が無い限りは真似すべきじゃないよね、って話。
インターネットは色々な制約の元、ああいう形態になってるわけだけど、
それらの制約は今の自分たちには、課せられてないかもしれない。
だから、インターネットを持ち出してOOPの有用性を語るのはナンセンスかなぁと。

251 :デフォルトの名無しさん:2010/04/26(月) 18:31:44
>>249
静的型言語はアレはアレで有用なんだけど、
C++やJavaで、中途半端に仮想関数なんぞ取り入れたのがマズかったんだろうな。
失敗作ってことで。

252 :デフォルトの名無しさん:2010/04/26(月) 18:38:18
>>251
実用性を全く考えないアカの人ですか?

253 :デフォルトの名無しさん:2010/04/26(月) 20:07:34
静的型言語には静的型なりの確固としたメリットがあるわけで、バッドノウハウとはまた違うだろう。

それに、GoF本の一章に書かれているような話(「インタフェースに対してプログラミングせよ」、
「継承よりコンポジション」等)の具体例がデザパタなのであって、要素技術だけ取り出して論じるのは無意味。

254 :デフォルトの名無しさん:2010/04/26(月) 20:22:11
>>250
大昔に小規模なコードを書いてる限りにおいては、それでも良かったかもしれない。
一命令単位で削るチューニングや、ワンライナー的な小手先の職人芸がもてはやされた時代だな。

しかし、変化のスピードが早まった昨今において、要求の変化に対して耐性がないコードには
もはや価値はない。昨今、動的型言語の柔軟さに対するニーズが高まっている理由はそこにある。

話が逆なんだよ。今、まさにそういったものが求められているのであって、特定のコンテキストに
依存した「単純さ」に未来はない。

255 :デフォルトの名無しさん:2010/04/26(月) 20:36:20
> 特定のコンテキストに
> 依存した「単純さ」に未来はない。

俺は適材適所だと思うぞ。予算と納期の制限もあるし。
Cで書いたプログラムをシェルで組み合わせて使うという昔ながらのスタイルも未だに有用だし、
DBならSQLだし。
上から下まで同じ言語でってのには無理があると思う。

俺は素直だから、こう考えるよ。
異なった制約を持ってるなら、言語の仕様も異なっててかまわない、と。

256 :デフォルトの名無しさん:2010/04/26(月) 20:44:16
だから、アラン・ケイ には申し訳ないんだけど、
単一メモリ空間で動くプログラムを書くときに、インターネットの成り立ちをお手本にしようとは思わないし、
大きなシステムを組むときでさえ、自然の生態系をお手本にしようとも思わない。
http://metatoys.org/oxymoron/oxymoron.html

257 :デフォルトの名無しさん:2010/04/26(月) 20:54:55
>>255
> 上から下まで同じ言語でってのには無理があると思う。

それは当然。>>254は「特定の言語以外はダメだ」なんて話は全くしていない。

重要なのは、「変化に対する柔軟性を持った設計・コードであるか」ということ。
俺はずっと静的型言語でやってきたが、そこに柔軟さを持ち込むベストプラクティスが、
(具体例としての)デザインパターンだし、動的型言語の需要も同じところから発している。

再利用性と柔軟性に対する配慮を欠いた「単純さ」は、それがいかに最短ルートに見えても、
いずれ必ず行き詰まり、高い代償を払うハメになる。

付け加えるなら、俺は「コードは複雑で遅くてもいい」とも思わない。
柔軟性を確保しつつ、高速に動作するコードを書ける人間は、今後ますます重要になる。
しかし、そうした高速化が実現されるのは、アルゴリズムやアーキテクチャのレイヤにおいて。
ここでも、やはり小手先の「単純さ」や「早さ」はお呼びでない。

258 :デフォルトの名無しさん:2010/04/26(月) 21:03:16
>>256
もう、80486なスタンドアロン・コンピュータでコードを動かす時代じゃないんだよ。
組み込み機器でさえ、高性能ハードウェアにAndroidのような汎用OSを積んで、
ブラウジングやWebアプリ連携が大前提の時代に移行しつつあるのに。

259 :デフォルトの名無しさん:2010/04/26(月) 21:12:46
>>256
windows bitmap はbitmapを表現するとてもシンプルな言語で、拡張性は皆無だが、
それを利用したからといって、行き詰るとも高い代償を払う羽目になるとも思わないね。

俺から見りゃお前は、「このままだと地球が駄目になります!」よろしく適当煽ってるだけに見える。

>>258
お前もまたそういう風に煽るだけ煽るよな。
そこにどういう制約が発生しているのか見極めて、同じような制約を持ってる他のものからヒントをもらえばよい。
単に漠然とインターネットの成り立ちがどうのこうの、自然の生態系がどうのこうの、じゃ話にならん。
組もうとしているシステムと自然の生態系の持ってる制約が、
同一であることは殆どないだろうし、単に真似しても上手くいかないだろう。
それぞれに固有の制約や問題があるし、適材適所だね。

260 :デフォルトの名無しさん:2010/04/26(月) 21:24:53
あーアンカーミスしちゃったな。自分にレスしちゃった。失礼。

261 :デフォルトの名無しさん:2010/04/26(月) 22:15:11
>>250
>お前普通に痛い子だから、多分あちこちに敵が居るぞ。
>いいかげん、お前の面倒見るの大変だから、さっさとお仲間さんのところへ行ったら?
まったく、知識・技術がない人間、決まって最後は
相手の人間性や性格の悪口を書く。

知識がない人間は、書き込まなければいいのに。

262 :デフォルトの名無しさん:2010/04/27(火) 05:42:27
>>259
> windows bitmap はbitmapを表現するとてもシンプルな言語で、拡張性は皆無だが、
> それを利用したからといって、行き詰るとも高い代償を払う羽目になるとも思わないね。

そりゃ、画像ファイル・フォーマットは基盤技術だからね。そもそも人間が読み書きする言語でもないが。
>>257はそんなことは書いてない。
あえて言うなら、画像を利用するコードがBitmapの仕様べったりなケースでは柔軟性を欠く場合はあるだろう。

> それぞれに固有の制約や問題があるし、適材適所だね。

当前。だが、要求に合わせた「進化」や、他のシステムとの連携を前提としないソフトウェアの出番が、
相対的に低下しているのは事実。
インターネットや「生態系」のメタファは、そういう風に解釈しておけば良いんじゃない。

263 :デフォルトの名無しさん:2010/04/27(火) 05:55:15
つうか、総論に対して特殊な反例を持ってきても、それは全く反論になってないよ。

264 :デフォルトの名無しさん:2010/04/27(火) 11:51:50
プログラムで必要な動作をオブジェクトの相互作用に分解するのは
・理解が難しくなる
・無駄が多くなる
・修正しにくくなる
というデメリットが出てくる場合があると思います。

オブジェクトに自律的に動作させるのではなく、オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法はいかがでしょうか。

たとえばRubyのNet:HTTPResponseからセミコロン区切りでクッキーを取り出すコードは次のように書けます。
response['Set-Cookie'].split(/path=\/, */).map { |item|
 (item =~ /^([^;]+;)/) ? $1 : '' }.join
左から右へオブジェクトを加工しながら流すスタイルです。
メソッドはオブジェクトが持ち、その組み合わせを外部で制御しています。

265 :デフォルトの名無しさん:2010/04/27(火) 12:11:01
オブジェクト指向派の人に質問なのですが、>>264の処理はメソッドとしてresponseオブジェクトに持たせるべきでしょうか?

266 :デフォルトの名無しさん:2010/04/27(火) 12:58:11
多様性の出番がないもの持ち出されても

267 :デフォルトの名無しさん:2010/04/27(火) 20:22:26
そもそもメソッドチェインってオブジェクト指向的に何か問題だったか?

268 :デフォルトの名無しさん:2010/04/27(火) 20:25:03
Javaってメソッドチェーン出来ない糞オブジェクトばかりだから嫌い

269 :デフォルトの名無しさん:2010/04/27(火) 20:28:59
>>268
commons使え。

270 :デフォルトの名無しさん:2010/04/27(火) 21:35:14
>>264
> オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法

むしろ、普通にオブジェクト指向的な発想だと思うが。

> response['Set-Cookie'].split(/path=\/, */).map { |item| (item =~ /^([^;]+;)/) ? $1 : '' }.join

流れの中で出てくる各オブジェクトの責務がきちんと最小化されているなら全く問題ない。
同様の処理が複数箇所で何回も出てくるなら、もう一つ上のレイヤでラップすることを
検討するべきかもしれないが。

271 :デフォルトの名無しさん:2010/04/27(火) 22:31:16
オブジェクトのメッセージパッシングによる相互作用どうのこうのに拘ってるのは、
例のメッセージパッシング君だけだから放っておいていいよ。

メソッドに書くべき処理は、そのオブジェクト内に関する処理だけ。
対象とするオブジェクト以外には、副作用しないほうが良い。
void object.method( const type *object ){}
こんな感じで、引数にポインタ取る場合は、constであることが望ましい。

複数のオブジェクトに副作用する処理は、普通に関数で書け。
void func( type1 *object1, type2 *object2 ){}

大体こんな感じでまとまってきているような。

272 :デフォルトの名無しさん:2010/04/27(火) 23:07:49
委譲でもいいけどな。

273 :デフォルトの名無しさん:2010/04/27(火) 23:21:54
>>264が何にこだわってるのかイマイチ見えないな

今オブジェクト指向言語と言われてるものの多くがifだのforだのといった
手続き的な構文を持っていて、xにeqメッセージを渡して得られた
booleanオブジェクトにifメッセージを渡したりするわけではない

ピュアな意味でのオブジェクト指向なんてほぼ現存しないものと
思っていいんじゃないの


274 :デフォルトの名無しさん:2010/04/27(火) 23:25:09
Rubyみたいな「構文要素は全てオブジェクトです」みたいのだったら可能かもな。

275 :デフォルトの名無しさん:2010/04/28(水) 00:16:13
Smalltalkは死んだ事になってるんだな
生きてると言うつもりは無いけどさ

276 :デフォルトの名無しさん:2010/04/28(水) 00:19:52
誰もその路線を継がなければ、路線としては死んだと同じだ

277 :デフォルトの名無しさん:2010/04/28(水) 00:36:09
いきてるお!
http://smalltalk.cincom.jp/
http://squeak.org/ http://scratch.mit.edu/ http://www.opencroquet.org/index.php/Main_Page
http://smalltalk.gnu.org/
http://www.object-arts.com/content/navigation/home.html
http://www.exept.de/en/products/smalltalk-x/stx-overview
http://www.instantiations.com/VAST/prod/vast.html
http://seaside.gemstone.com/ http://ruby.gemstone.com/

278 :デフォルトの名無しさん:2010/04/28(水) 00:39:15
Smalltalkの底を流れる設計思想 http://bit.ly/dCQIfo

279 :デフォルトの名無しさん:2010/04/28(水) 03:32:40
>>264
>オブジェクトに自律的に動作させるのではなく、オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法はいかがでしょうか。
なぜ、オブジェクト指向がメッセージパッシングじゃないと駄目なのかは、例えば
@A.Method1;
AA.Method2;
BA.Method3;
この順番で実行(制御)しなと正しく処理されないとして
下記のようにAとBの途中で別のオブジェクトから@が呼ばれた場合処理が不正になる。
S1オブジェクトから-->A.Method1;
S1オブジェクトから-->A.Method2;
M1オブジェクトから-->A.Method1;
S1オブジェクトから-->A.Method3;

使う方は、このルールを知らないといけない。単純な1つのメソッドからの呼び出しなら大丈夫かもしれないが
複数のメソッドや1つのメソッドでも処理が離れている場合など複雑になる。
処理手順を覚えないと使えないオブジェクトは、「>理解が難しくなる」と思わないか?

> response['Set-Cookie'].split(/path=\/, */).map { |item|
> (item =~ /^([^;]+;)/) ? $1 : '' }.join
Rubyはよくわからないけど、これは相手のフィールドは変更されないでしょう?
取得したクッキーの編集の話しだから、外部からの制御じゃなく内部で処理していると思うけど、よくわからん。


280 :デフォルトの名無しさん:2010/04/28(水) 07:39:35
結局、Rubyのそのコードの例でOOのどんな「問題点」を指摘したいのかよく分からん。

281 :デフォルトの名無しさん:2010/04/28(水) 08:24:10
OOPと正規表現は無関係だと言ったかったのではあるまいか

282 :デフォルトの名無しさん:2010/04/28(水) 11:38:12
皆様ありがとうございます。

自分としては、>>264は純粋なオブジェクト指向ではなく、以下の関数型の特徴(?)を入れたハイブリッドな書き方を提案したつもりでした。
・オブジェクトの状態を変更せず、戻り値で新しいオブジェクトを返す
・オブジェクトを次々に関数(外部から与える高階関数)に渡して処理をする
・引数を使う。変数は使わないか、使う場合は再代入を避ける

メソッドチェーンに関しては、以下のものに違反しているので、純粋なオブジェクト指向の世界では良くない(お行儀の悪い)コードになっているのではと思います。
・デメテルの法則(http://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87
・ドット1つルール(http://d.hatena.ne.jp/asakichy/20090616/1245112830

283 :デフォルトの名無しさん:2010/04/28(水) 11:38:28
>>271
引数で渡されたオブジェクトの状態を変更しない方がいい、ということに同意します。

>>279
おっしゃる通り、副作用がある場合、メソッドを順番通りに呼ばないといけないとしたら理解が難しくなると思います。
>>264は副作用がない場合(新しいオブジェクトを連鎖的に返していく)の話でした。
副作用がある場合、順番通りに呼ぶ必要がメソッドは、まとめて1つのメソッドにすべきだと思います。

284 :デフォルトの名無しさん:2010/04/28(水) 12:31:43
>>282
OOそんなに詳しくないけど
RubyのブロックみたいなのってSmalltalkが元ネタだよね?
デメテルの法則とか言ってたら、Smalltalkじゃコードなんて書けないんじゃないの?
逆にその意味で「お上品」に書けるコードってのは
「純粋なオブジェクト指向言語」じゃない気がするんだが


285 :デフォルトの名無しさん:2010/04/28(水) 12:40:35
下2行意味不明だった
あなたの言う意味でお上品な書き方してる場合、OO的なガワの部分を
お上品に書いてるだけで、
実際には中身は手続き的または関数的に書いてんじゃないのかってことね
これはただの直観だけど

ピュアリズムみたいなのにこだわる意味が見出せない、という総論的な意味では同意
何でもかんでもオブジェクトとメッセージで考えるより
式と評価(ラムダ計算)、文と実行(チューリングモデル)で捕らえたほうが
現実的で便利で分かりやすいケースが多いから、ピュアリズムは
流行らないんだと思うし

286 :デフォルトの名無しさん:2010/04/28(水) 14:41:49
OOPを理解できない奴の言い訳にしか見えないのが悲しいねw

287 :デフォルトの名無しさん:2010/04/28(水) 20:16:59
imifu

288 :デフォルトの名無しさん:2010/04/28(水) 21:49:54
>>271
>複数のオブジェクトに副作用する処理は、普通に関数で書け。
>void func( type1 *object1, type2 *object2 ){}
それはオブジェクト指向じゃないから、君は勉強が足りないよ。


289 :デフォルトの名無しさん:2010/04/28(水) 21:59:16
オブジェクト同士がメッセージをやり取りする
みたいな表現はoopの理解を
ものすごくさまたげているとおもう


290 :デフォルトの名無しさん:2010/04/28(水) 22:00:01
オブジェクト指向が分かって人間が、アンチ・オブジェクト指向と言っても説得力がない。
>>271
この人が一番駄目だよな。

291 :デフォルトの名無しさん:2010/04/28(水) 22:08:44
たしかに、>>271はいままでの書き込みを見ると
オブジェクト指向が理解できていない。

292 :デフォルトの名無しさん:2010/04/28(水) 22:21:44
>>289
エセOOはやってないね。エセOOをOOの言葉でやるから。

293 :デフォルトの名無しさん:2010/04/28(水) 22:50:31
>>289
オブジェクト指向の勉強をはじめたころは
同じように感じたこともあったけど
理解が進むとわかってくるよ。

294 :デフォルトの名無しさん:2010/04/29(木) 00:07:33
理解が進むと解るけど理解してない内は妨げになる、なら
それは理解の妨げになる、と同義のような。

295 :デフォルトの名無しさん:2010/04/29(木) 01:23:01
問題はあるかもしれないけど、学習パスとしてはデザパタ丸暗記とかでもいいと思う今日この頃。
変なオレオレオブジェクト指向を身に着けてこられるより100倍マシ。

296 :デフォルトの名無しさん:2010/04/29(木) 06:07:01
>>294
んっ? それが理解していくことだと思うけど。

>>295
>変なオレオレオブジェクト指向を身に着けてこられるより100倍マシ。
たしかに、オレオレオブジェクト指向でアンチされてもこまるからね。

297 :デフォルトの名無しさん:2010/04/29(木) 06:56:04
有名なアルゴリズムや定法は知っているところから話は始まる。

298 :デフォルトの名無しさん:2010/04/29(木) 10:01:46
理解が進むと解るけど理解してない内は妨げになる、なら
それは理解の妨げになる、と同義のような。

299 :デフォルトの名無しさん:2010/04/29(木) 10:45:32
“何の”理解の妨げになるのかによるでしょうね。

同じ“オブジェクト指向”にも、ストラウストラップ/メイヤー/リスコフらの「抽象データ型のOO」と
ケイの「メッセージングのOO」があります。

世の多くの“OO”の解説は、これら本来なら区別すべき異質の考え方をよいとこ取りした勝手定義で、
前者の「カプセル化、継承、多態性」の話をしつつ後者の「オブジェクトにメッセージを〜」なんて関係ない話を
平気で持ち出してきたりします。こういう「メッセージ―」の出し方は明らかに前者の理解を妨げます。

一方で、最初から後者や後者から派生的に生じたOOADを学ぶなら必ずしもメッセージングの話は
妨げにはならない(というか、軸となる考え方なのでむしろ欠かせない)、と。

300 :デフォルトの名無しさん:2010/04/29(木) 13:47:59
>>295
>問題はあるかもしれないけど、学習パスとしてはデザパタ丸暗記とかでもいいと思う今日この頃。
丸暗記は別にして、GoFぐらいは理解してほしい。
オブジェクト指向で作れなくてもいいけど、こっちが作ったソースぐらいは読めると嬉しい。

「○○パターン」と書いているソースを、「このソース意味が分かりません」と言われても
こっちは、「GoFを勉強して」と言うしかない。いちいち教えていられない。


301 :デフォルトの名無しさん:2010/04/29(木) 15:15:16
デザパタの肝は、共通語彙のカタログだからな。


302 :デフォルトの名無しさん:2010/04/29(木) 19:38:37
理解するまで、とか、理解が進む、とか、理解してない内とか、とか、とか、
お前ら本当に大変だな。
理解が大変、理解が得られない、そういったものは元々から間違っている可能性すらもある。
まーOOPの定義すら無いわけで、理解しようもないのだが。

303 :デフォルトの名無しさん:2010/04/29(木) 20:11:26
一般相対性理論は理解が大変だから間違ってると言いたいんですね、分かります。

304 :デフォルトの名無しさん:2010/04/29(木) 20:19:34
目指すものについては大体共通理解はあるだろ。
早い話が開放/閉鎖原則とか単一責任原則とか。

ただ、個別具体の方法論の部分で同じ名前を名乗る複数の流派があるのが問題ではある。
あと、俗流OOの類が大量にあるのも問題を助長しているな。

305 :デフォルトの名無しさん:2010/04/29(木) 20:36:06
>早い話が開放/閉鎖原則とか単一責任原則とか。

それカプセル化の話だよね。それがOOPの本質なの?
違う人に聞けば、本質はポリモだって言うかもしれないし、
メッセージパッシング君に聞けば、本質はメッセージパッシングだって言うだろうし。

カプセル化が好きな人と、ポリモが好きな人と、継承の差分プログラミングが好きな人と、
メッセージパッシングな人が、一堂に会してOOPの議論しはじめたら、
さぞ大変なことになるんだろうな。

で、まとまらないから、最大公約数的に、
「オブジェクトの振る舞いを定義して〜」っていつもの。

306 :デフォルトの名無しさん:2010/04/29(木) 21:09:58
カプセル化はOOPとは独立した概念だろ
SICPでは「Data Abstruction」と呼んでいるが
そこで用いられるのは関数型言語のSchemeだ

307 :デフォルトの名無しさん:2010/04/29(木) 21:12:23
>>305
俺はオブジェクト指向分析・設計については詳しくないから断言はできないが、
おそらく開放/閉鎖原則みたいなのは設計レイヤの話と言っていいんじゃないかな。

君が挙げているのは、あくまで実装手法やその理論でしょ。

308 :デフォルトの名無しさん:2010/04/29(木) 21:13:50
開放/閉鎖原則にしたって、メイヤーの言っていた意味のそれなんて
誰も守ってないだろ

309 :デフォルトの名無しさん:2010/04/29(木) 21:14:24
じゃ、OOPと独立できない概念って何よ。

310 :デフォルトの名無しさん:2010/04/29(木) 21:24:47
多様性
これを実現するために、いろろな機能が誘導されてくるんじゃないか

311 :デフォルトの名無しさん:2010/04/29(木) 21:30:14
>>310
正解

312 :デフォルトの名無しさん:2010/04/29(木) 21:53:17
だから、動的オーバーロードでいいんだろ?


313 :デフォルトの名無しさん:2010/04/29(木) 21:59:40
動的オーバーロードって多重ディスパッチの事だろ?

314 :デフォルトの名無しさん:2010/04/29(木) 22:00:26
それは要素技術でしょ。

315 :デフォルトの名無しさん:2010/04/29(木) 23:24:35
>>305
オブジェクト指向を理解していない人の典型だとおもう。
ここまで駄目駄目だと...

316 :デフォルトの名無しさん:2010/04/29(木) 23:31:16
>>312
>だから、動的オーバーロードでいいんだろ?
なにがいいの? 動的オーバーロードがオブジェクト指向だと思う理由は?

317 :デフォルトの名無しさん:2010/04/29(木) 23:34:45
理解理解って、一体何を理解しろと言うのだ。

318 :デフォルトの名無しさん:2010/04/29(木) 23:47:42
クラス分けの仕方

319 :デフォルトの名無しさん:2010/04/29(木) 23:49:52
また斜め上の回答きたこれ

320 :デフォルトの名無しさん:2010/04/30(金) 00:00:50
世の中クラス指向のOOPLだけじゃねーから

321 :デフォルトの名無しさん:2010/04/30(金) 01:01:54
クラスの仕分けとダックタイピング

322 :デフォルトの名無しさん:2010/04/30(金) 09:24:27
>>305
>>早い話が開放/閉鎖原則とか単一責任原則とか。
>それカプセル化の話だよね。それがOOPの本質なの?
カプセル化? なぜ開放/閉鎖原則や単一責任原則がカプセル化の話だと思う?
君はバカのひとつ覚えで、なんでもカプセル化だね。

>メッセージパッシング君に聞けば、本質はメッセージパッシングだって言うだろうし。
本当にオブジェクト指向が理解出来ていないね。
開放/閉鎖原則や単一責任原則とメッセージパッシングは、矛盾した概念じゃない。
内部的観点と外部的観点の違いだけ。

>で、まとまらないから、最大公約数的に、
>「オブジェクトの振る舞いを定義して〜」っていつもの。
まとまっているから、理解出来ていないのは君だけ。
もういいよ、ひとりレベルが違いすぎるから、話の質が落ちる。
イチから勉強してから、またおいで。

323 :デフォルトの名無しさん:2010/04/30(金) 14:50:48
心を開いて!
君は洗脳されているんだよ!

324 :(u_・y) ◆rT33C51l9k :2010/04/30(金) 15:03:08
OOっていうのは、プログラムの最後の最高効率の形なの
で。 その形の設計を出来る奴は二種類
1 プログラミングの果てをみている
2 同じようなプログラムを何度も何度も作ってきた
このどちらかでもねーならOOなんて無理なの!!!!!!!!!!!!!
おk?????????

死ね

それでもわからないっていうなら、同じようなプログラムを5回くらいゼロから設計しなおして
一切のソースを流用しないで作ると良いよ
完全に最適化された辿り着く形はOOか、関数型どっちかしかねーんだから。
関数型は一般的じゃない。 だからゴミみたいな奴が身に付けられるのはOOのみ。

325 :(u_・y) ◆rT33C51l9k :2010/04/30(金) 15:06:28
カプセル化とか、ポリモとか、
手段でしかないのに、議論する意味がないwwwwwwwwww
外部から参照させたらまずいものを見えなくするのなんて当たり前だし、
今後、もしかしたら外部から見えたほうがいいかもしれないものは見えるようにするのが当たり前、
関数を使いやすくするためにポリモるのも当たり前
それすら出来ないってどういうこと

ポリモや、クラスが無くて、C言語が主流だった時代に、
現在のOOのようなソースが世界中のどこにも無かったとかおもってるわけ
無かったらなかったらで、 他の表現でOOすればいいだけ

326 :デフォルトの名無しさん:2010/04/30(金) 15:07:04
なるほど、OO信者の成れの果ては糞コテなのだな。

327 :デフォルトの名無しさん:2010/04/30(金) 15:11:38
大事なのは、プログラムの断片をつなぎ合わせる為の機構であって、OOPではない。
テンプレートと型推論と動的オーバーロードが有ればそれで良い。
オブジェクト「指向」する必要は無い。

328 :デフォルトの名無しさん:2010/04/30(金) 15:54:24
>>327
テンプレートと型推論と動的オーバーロードで、ソフトウェア開発のどういう課題が解決できるの?

329 :デフォルトの名無しさん:2010/04/30(金) 21:17:27
>>324
話の流れが良く見えてない状況で茶々をいれてみる

再帰下降パーサが必要になる局面なんてのはよくあるパターンなんだが
OO の人たちって書けない人の上が多いでしょ?


330 :デフォルトの名無しさん:2010/04/30(金) 21:24:56
>>329
そんな初歩的なことは普通にできるだろ。

331 :デフォルトの名無しさん:2010/04/30(金) 21:29:09
>>329
パーサのアルゴリズムとオブジェクト指向の間に何の関係があるの?

332 :デフォルトの名無しさん:2010/04/30(金) 22:52:41
映画マトリックスの世界はOOPに違いない。

俺たちはいずれOOPの中で生きることになる。

333 :デフォルトの名無しさん:2010/04/30(金) 23:23:31
適用範囲

334 :デフォルトの名無しさん:2010/05/01(土) 00:56:03
オブジェクト指向を取得には実践が大事。

例えば、絵画の書籍を何十冊よんでも絵画は描けない。
本人は描けるつもりでも、実際描こうとすると思うように描けない。
これは、本人の知識が不足しているから、細かいテクニックや本質は
実践で取得する。

オブジェクト指向の場合、規模が大きいときに長所が発揮される。
つまり大規模開発を行なわないと、オブジェクト指向の長所が体感として取得出来ない。
最低でも数十万ステップの開発をオブジェクト指向で行なうと、
オブジェクト指向の長所・短所が分かってくる。

と、文章で説明してみる。

335 :デフォルトの名無しさん:2010/05/01(土) 01:26:10
「変更に対する柔軟性」と言っても、そんなん本じゃ説明できないもんな。

336 :デフォルトの名無しさん:2010/05/01(土) 04:01:51
>>334
OO な設計ってこまわり効かなくね?
つか, 副作用前提で考えるか否かの問題なんだろうけどさ
問題領域によっては OO 思考されるとすごくじゃまなことがある


337 :デフォルトの名無しさん:2010/05/01(土) 04:10:29
思考じゃなくて指向な。

338 :デフォルトの名無しさん:2010/05/01(土) 04:14:54
あえて 「思考」 と書いてるわけだが


339 :デフォルトの名無しさん:2010/05/01(土) 05:21:15
嗜好だろ

340 :デフォルトの名無しさん:2010/05/01(土) 09:45:38
無知は恥ずかしいことじゃないよ。

341 :デフォルトの名無しさん:2010/05/01(土) 11:08:18
思考・・・考えること。経験や知識をもとにあれこれと頭を働かせること。
指向・・・ある方向・目的に向かうこと。また、方向や目的を指示してその方に向かわせること。志向。
嗜好・・・ある物を特に好み、それに親しむこと。好み。主に飲食物についていう。

342 :デフォルトの名無しさん:2010/05/01(土) 11:20:02
言葉遊びしか出来ない人達。

343 :デフォルトの名無しさん:2010/05/01(土) 11:21:41
>>336
小回りといっても状況とプロジェクトの目的によるな。具体例を。
あと、単に設計者がタコなだけな場合も多い。

344 :デフォルトの名無しさん:2010/05/01(土) 11:54:27
>>343
大規模な信号処理系とかだと, あちこちで状態を持たれると困る事が多いんだが,
Object に必要もない状態を持たせるやつが結構いる

この手の処理だと OO な言語をつかわなければ OO 的な思考ができなくなって
無駄な状態を持とうとか考えなくなるみたいで, かえってすっきりしたものが
できたりすることもある

まあ, 単に設計者がタコなだけなんだが


345 :デフォルトの名無しさん:2010/05/01(土) 11:56:06
>>337
元の文章は「OO思考」と書いてあるよ。
オブジェクトオリエンテッド思考な。
おまえの意見だとオブジェクトオリエンテッドオリエンテッドになるけどそれでいいのか?

346 :デフォルトの名無しさん:2010/05/01(土) 12:53:33
>>344
信号処理系はよく分からないが、状態を集中管理した方が見通しがよくなる場合は
そうした方がいい場合もあるかもな。
小回りの効く単位で責務を切り出せる問題領域なら、OOで小回りが効かない
ということはないしむしろ逆。なんか禅問答チックだが。

347 :デフォルトの名無しさん:2010/05/01(土) 16:22:33
>>344
一般にバッチ処理や制御系など、情報を保持しないシステムは、
オブジェクト指向向きでは無いと言われている。

しかし、最近のマルチCPU化に伴い並立処理の必要性が
バッチ処理や制御系でも注目されている。

その場合タスク間のタイミングの為に、情報の保持が必要となった。
それに伴いバッチ処理や制御系でも、オブジェクト指向が注目されている。

348 :デフォルトの名無しさん:2010/05/01(土) 17:50:50
>>347
λ計算やπ計算が注目ってんなら分かるが
その文脈で「オブジェクト指向が注目」って思いっきり意味不明だわ
そういう理由でOOを選ぶ奴は完全に見る目が無い
「状態の保持」は並列化の敵だ

349 :デフォルトの名無しさん:2010/05/01(土) 18:07:59
また、関数型くんかw
たまには、理由も書けばw

350 :デフォルトの名無しさん:2010/05/01(土) 18:27:25
>>349
んなもん常識だろ
状態があれば排他や状態のレプリケーションのコストが発生する
副作用の無い関数は本質的にパラレルに実行可能だ

最近関数型やErlangが注目されている理由も知らないのか
本気で無知だな

351 :デフォルトの名無しさん:2010/05/01(土) 19:45:39
>>350
Erlangは状態をもつアクターモデルで
遠隔オブジェクトとの通信にはメッセージパッシングを使うよ

>副作用の無い関数は本質的にパラレルに実行可能だ
>最近関数型やErlangが注目されている理由も知らないのか
>本気で無知だな

無知はどちらかなフフフ

352 :デフォルトの名無しさん:2010/05/01(土) 19:57:54
>>531
Erlangは通常「状態」を副作用(=再代入)の形では扱わず
参照透明な形で状態遷移を扱う
データを内部に保持したがるOOとは違う

アクターモデルは「メッセージパッシング」を用いはするが
少なくとも一般的な意味でのOOとは別もんだろ


353 :デフォルトの名無しさん:2010/05/01(土) 20:17:15
>>349,351
もう関数型は、無視したらどうだ。
ここまでくると、「荒し」だ。

354 :デフォルトの名無しさん:2010/05/01(土) 20:19:06
>>353
ん?
>>357の意見が面白すぎたから突っ込んだだけだぜ
>>351
Erlangのアの字も知らずにメッセージパッシングというだけで
OOだとでも思ったのか知らないが、面白い奴だな

355 :デフォルトの名無しさん:2010/05/01(土) 20:19:57
>>352
> データを内部に保持したがるOOとは違う

オブジェクトが状態を持つようにするのは、手続き型のパラダイムがそうだからであって、
オブジェクト指向の性質として、オブジェクトがデータを持ちたがっているからではないお。

356 :デフォルトの名無しさん:2010/05/01(土) 20:22:00
>>355
OOのベースに手続きパラダイムが使われていることが多い、という事情は
その通りだが、それだけではないだろ

OOにおいては、「責任」という考え方があって、
その「もの」が責務を負うべきデータは本質的に中に持ちたがり、
それが良い設計とされる


357 :デフォルトの名無しさん:2010/05/01(土) 20:40:25
つーか、「データを中に持たない」のなら、「オブジェクト」自体が要らない
関数だけでいいだろ

358 :デフォルトの名無しさん:2010/05/01(土) 20:45:14
>>356
オブジェクトが持つべきものは「責務」であって「状態」ではないからな。
だから、immutableなオブジェクトというのも当然アリ。

359 :デフォルトの名無しさん:2010/05/01(土) 20:46:43
>>352
>少なくとも一般的な意味でのOOとは別もんだろ
なんだ、この逃げ方は、なにが「一般的な意味でのOO」ってなんだw
お前が一般的と言っているのは、浅いお前の知識で思っているオブジェクト指向だろw


360 :デフォルトの名無しさん:2010/05/01(土) 20:47:38
ちなみに、ここでは「状態」と「データ」は区別して言ってるのでよろしく。
immutableなオブジェクトでも、初期パラメータとしての「データ」はもちろんある。

361 :デフォルトの名無しさん:2010/05/01(土) 20:55:50
だから、関数型と言っている奴は
荒しだから、無視でいいだろう。
こいつのおかげで、スレが荒れている。

しかし、なんで荒しをやるんだ?
実生活でも、会社や周りから嫌われているんだろうな。

362 :デフォルトの名無しさん:2010/05/01(土) 20:58:25
>>361
本当にそうだよ、別のところでやればいいのに。

363 :デフォルトの名無しさん:2010/05/01(土) 21:06:52
>>358
それはその通りだね
immutableなオブジェクトしかないような「オブジェクト指向言語」は
俺は知らないが

>>361
まともな反論ができなければ荒らし認定か
つまらん奴だな

364 :デフォルトの名無しさん:2010/05/01(土) 21:10:42
>>359
いやお前、あの文脈でErlangがアクターモデルだからどうたらとか言われても
何の反論にもなってないんだが
その先の主張は何よ
ErlangはOOだとでもいいたいのか?

俺は定義の曖昧な基盤の上での不毛な論争は避けたいから、「一般的な意味での」
と断っただけだ
「一般的な意味では」Erlangは「並列計算指向の」「関数型言語」であり
「オブジェクト指向言語」ではないし
「一般的な意味では」オブジェクト指向言語はデータを中に持ちたがるし
副作用を多用する

365 :デフォルトの名無しさん:2010/05/01(土) 21:16:07
Erlanがこんなに人気あるとは思わなかったぞ

366 :デフォルトの名無しさん:2010/05/01(土) 21:19:08
Erlang 宣伝してるのは同一人物だろ

367 :デフォルトの名無しさん:2010/05/01(土) 21:21:27
別に宣伝してるわけじゃないんだけどね
>>351がアホなツッコミを入れたから話が伸びただけで
もっと言うなら>>347の面白主張がなければ話そのものが始まらなかった

368 :デフォルトの名無しさん:2010/05/01(土) 22:02:50
>>357
関数は機能ひとつだけだろ。
オブジェクトは機能のセットとして「責務」を持つようにでkる。

369 :デフォルトの名無しさん:2010/05/01(土) 22:07:42
>>368
もっと素直になれ、データを持ちたいからオブジェクトにしたいんだろうよ
単に関数をどこかにひとまとめにしたいだけなら、モジュールでいい

370 :デフォルトの名無しさん:2010/05/01(土) 22:10:09
>>363
> immutableなオブジェクトしかないような「オブジェクト指向言語」

Scalaは、言語仕様としてimmutableなオブジェクトをサポートしている。
副作用があるものも当然書けるがね。

371 :デフォルトの名無しさん:2010/05/01(土) 22:15:52
>>370
俺は「しかない」と言ってるんだから、反論になってないのは分かってるんだろうし、
そのつもりもないんだろうね

Scalaははねえ

下層のJava部分が言うまでもなく全部手続き型で副作用だらけ
勿論自分も副作用は普通にサポート
Javaの参照型オブジェクトには全てnullを突っ込めるし
nominal subtypingによる実行時ポリモーフィズムのお陰で
型安全性がJava同様中途半端で、型推論も半端

見方によっては何でも出来て超強力だが、見方によっては実に半端な
妥協的・折衷的言語だな

372 :デフォルトの名無しさん:2010/05/01(土) 22:17:14
>>369
素直になれって言われても、データを持ちたいからという「だけ」じゃないだろ。
関数「だけ」でいいだろ、って言い出したのはそっちだよな?
まあもともとオブジェクト指向なんて鵺のようなものなんだし、どっちでもいいけど。

373 :デフォルトの名無しさん:2010/05/01(土) 22:18:19
>>371
純粋なものがすなわち使いやすいわけではないからねぇ。
言語仕様のみでサポートできることにも限界はあるし。

374 :デフォルトの名無しさん:2010/05/01(土) 22:18:44
>>372
ああそりゃすまんかったw

個人的な見解だが、一部のクラスベースOO言語でクラスをただのnamespaceや
moduleとして利用している場合があるが、あれは馬鹿げた「乱用」だと思ってる
なぜそうまでしてクラスに書かせるのか

375 :デフォルトの名無しさん:2010/05/01(土) 22:22:08
>>374
それ「だけ」のためにクラスを利用してる言語だったら確かに意味がないけど、
そういうふう「にも」使えるというだけなら、別に実用上の問題はないんじゃないの。

376 :デフォルトの名無しさん:2010/05/01(土) 22:25:01
>>375
まあ、そう言ってしまえばそうなんだが、気分としては気持ち悪いし、
美しいとも思えないね

JavaやC#ではそういう用法はclassの第一級の使い方ではないから
本来不要なclassを記述した上で、それぞれの関数にはいちいちstaticと
書かなければならないし

377 :デフォルトの名無しさん:2010/05/01(土) 22:34:04
とはいえ、単純に名前空間やモジュールといっても、
コードのパッケージングの仕組みと深く関わってる場合も多いわけだし、
そう簡単にそうだとは言い切れない部分もあるんでないかな。

378 :デフォルトの名無しさん:2010/05/01(土) 22:34:42
確かにオブジェクト指向なんて鵺のようなものだよな。

379 :デフォルトの名無しさん:2010/05/01(土) 22:36:21
しかし、ここまで関数型くんが無知だと笑ってしまう。

>>350
>状態があれば排他や状態のレプリケーションのコストが発生する
フィールドが並立処理の為に導入されたのもだが知らんのか?
レプリケーションのコストは、発生しない。データを冗長に持たないのがオブジェクト指向だ。

>>352
>アクターモデルは「メッセージパッシング」を用いはするが
>少なくとも一般的な意味でのOOとは別もんだろ
アクターモデルの概念は、オブジェクト指向言語に影響されているのも知らんのか?
もともとオブジェクト指向言語は、並立処理言語だったと知っているか?

380 :デフォルトの名無しさん:2010/05/01(土) 22:39:16
>>377
ん?
パッケージングの仕組みがそうだから言語デザインが汚くても従容と
受け入れてねってこと? 良く分からん

同じCLI言語のVBにはmoduleあるじゃん
C#にはないけど
別にmoduleは、内部的には全てのメソッドがstaticなclassの構文糖でも
構わないんだよ
実際にVBのmoduleはそうだし

381 :デフォルトの名無しさん:2010/05/01(土) 22:44:39
>>379
> レプリケーションのコストは、発生しない。
> データを冗長に持たないのがオブジェクト指向だ。
あれは確かに書き方が悪かったかもしらんが
どっちも常に発生するって意味じゃないんだよ
状態を複製しないのなら、単一オブジェクトの状態を排他しつつ利用することに
なるから、並列計算においてはかなりのボトルネックになることが普通に想定
されるね
フィールド別れてたって、単にロックの粒度を細かくできるだけで
排他が必要なのは変わらん
wait free lockのような詳細はここでは問題にしないけど

> アクターモデルの概念は、オブジェクト指向言語に影響されているのも知らんのか?
勿論知っている、メッセージパッシング自体がそうだしね
ただし、出来上がっているErlangは少なくとも一般的な意味でのOO言語とは別物だし
OO言語とは呼ばれないね

382 :デフォルトの名無しさん:2010/05/01(土) 22:48:34
あんたのたわごとで、極めつけで意味がわからんかったのが、これね
>Erlangは状態をもつアクターモデルで

そりゃ、アクターの実行状態を「Erlang VMは」管理しているだろうね
それで?
プログラミング言語の文脈では、参照透明な、副作用の無い関数を「状態を持つ」
とは言わないよ
「普通は」ね


383 :デフォルトの名無しさん:2010/05/01(土) 23:02:22
顔はサル、胴体はタヌキ、トラの手足を持ち、尾はヘビで、「ヒョーヒョー」という、大変に気味の悪い声で鳴くのが鵺(ぬえ)。

責務の割り当が難しいことがあるんだよ。そういう場合はそれが問題の中心になってしまう。
Photoshopとかの画像編集ソフト使ったことある?
色彩やコントラストのコントロールなど機能が満載でいろんなことが出来る。
 オブジェクト->色を変換
 オブジェクト->明るさ(トーンカーブ)を調整
みたいな感じにね。
でも写真に写ってるモデルの髪の色を明るくしようとしたら、髪の毛だけを
選択範囲(オブジェクト )として抽出しなければならないんだ。
そんなのどうやってやる?
下手にやると背景から浮いてしまって不自然なフォトレタッチになってしまうから
範囲選択それ自体がひとつのテクニックとして問題になってくる。

責務の抽出と割り当が難しい問題領域があるんだよ。

384 :デフォルトの名無しさん:2010/05/01(土) 23:21:18
そりゃあるよね。


おわり。

385 :デフォルトの名無しさん:2010/05/01(土) 23:25:22
ただ、その例だと何かやりようがあるような気もするけどね。
それが最適解かは、そのソフトが目指すところによると思うけど。

386 :デフォルトの名無しさん:2010/05/01(土) 23:36:44
>>383
適当だけど
登場人物は
ImageOp、ImageSelection、Image
こんな感じでないの
イメージエディタの編集操作って基本的にイメージのセレクションに対して
作用するでしょ

セレクションを扱うこと自体はGUIでの基本的な問題だと思うけど
テキストエディタだってそうだし

387 :デフォルトの名無しさん:2010/05/01(土) 23:40:42
まあPhotoshopの例はあくまで喩えだけど、
イメージのセレクションそれ自体はユーザに任されていて、エディタの機能は
「セレクト後」のオブジェクトに作用するだけだよね。


388 :デフォルトの名無しさん:2010/05/01(土) 23:44:55
>>381
>状態を複製しないのなら、単一オブジェクトの状態を排他しつつ利用することに
>なるから、並列計算においてはかなりのボトルネックになることが普通に想定
>されるね
また関数型くんは、わけの分からないことを書いている。
何の排他が必要なんだ? 排他をしないでいいようにメッセージパッシングで作るんだろう。
それとも、メッセージ・キューの排他を言っているのか?
メッセージ・キューはOSやハードの問題で言語の問題じゃない。
いいかオブジェクト指向言語は、並行処理のために
昔からコルーチンやマルチスレッドが実装されている。
オブジェクト指向言語だからといってボトルネックになることはない。

389 :デフォルトの名無しさん:2010/05/01(土) 23:56:56
>>388
> 何の排他が必要なんだ? 排他をしないでいいように
> メッセージパッシングで作るんだろう。
あのな
「メッセージパッシング」でゴマカすなよ
コードが参照透明で、副作用を持つか持たないかだけが問題だ
副作用を持つコードや可変な状態に、複数のスレッドからアクセスしたければ
必ず排他が必要だ
純粋に参照透明な純粋なオブジェクト指向言語なんて俺は知らないんだが、
知ってるんなら、教えてくれないか?

> いいかオブジェクト指向言語は、並行処理のために
> 昔からコルーチンやマルチスレッドが実装されている。
は?
マルチスレッドに対応しているからといって排他が不要だということにはならない
むしろその逆で、手続き的言語のマルチスレッドプログラミングにおいてこそ排他が
多用されるんだろうが
一方、コルーチンだけでスレッドやプロセスを用いないなら、排他は不要だが、
元の問題である、マルチコアの並列計算とは特に関係の無い問題になるんだが

390 :デフォルトの名無しさん:2010/05/01(土) 23:58:51
なんか本気で分かってないくせに
高みにいるつもりで人を「関数型くん」呼ばわりで馬鹿にした気になってんだな…
ご苦労なこった

391 :デフォルトの名無しさん:2010/05/02(日) 00:15:46
>>389
>作用を持つコードや可変な状態に、複数のスレッドからアクセスしたければ
>必ず排他が必要だ
単一のスレッドのスレッドからしかアクセスしなければ排他は必要ありません。

> 何の排他が必要なんだ? 排他をしないでいいように
> メッセージパッシングで作るんだろう。
単一のスレッドのスレッドからしかアクセスしないための具体的な方法がこれです。
各スレッドが直接アクセスするかわりに単一のアクセス担当スレッドと
メッセージをやりとりすれば各スレッドに排他処理をばらまく必要はありません。

392 :デフォルトの名無しさん:2010/05/02(日) 00:20:22
>>391
ああすまん、いいたいことは分かった
比喩的な(形骸化した)「メッセージパッシング」じゃなくて
メールスロットを用いたメッセージパッシングのことだったのね
確かにそこでキューイングされているなら、排他は要らないし
全てのメッセージパッシングをそうやって実装しているOO言語であれば、
確かに排他処理をばらまく必要は無いね
すまんかった

393 :デフォルトの名無しさん:2010/05/02(日) 00:32:30
ただなあ
メッセージパッシングでやりとりしてるとしても、オブジェクト自身が
状態持ってると、最悪の場合、Webアプリケーションで言うDBサーバのような
状態になる
容易に多重化できず、レプリケーションするとしてもコストがかかり、
クリティカルかつボトルネックってことだ
一方で、重要な状態を持たないサーバまたはアプリケーションは、多重化しやすい
それは、プログラムでも同じことだ

まあ、最低限タイムクリティカルなコードが全部状態フリーで容易に
並列化可能なコードであれば実用上問題はないわけだけどな

394 :デフォルトの名無しさん:2010/05/02(日) 10:59:48
こういうスレって実績伴わずに脳内世界で自由に羽ばたいてるだけの人が
よって来やすいよね。ただの手を動かさないニートとか
決められた事を守れない他人不在の自己中とか


395 :デフォルトの名無しさん:2010/05/02(日) 11:46:09
自己紹介乙

396 :デフォルトの名無しさん:2010/05/02(日) 15:06:13
>>392
ちゃんと文章読む癖をつけた方がいいと思う。

397 :デフォルトの名無しさん:2010/05/02(日) 17:20:37
俺は「オブジェクト指向とは何か」を知りたい(自分の中で納得したい)ので、このスレはすごく勉強になっています

398 :デフォルトの名無しさん:2010/05/02(日) 21:05:51
オブジェクト指向とは何か、について一致する見解はないね。
そもそも対立概念(ライバル)が何かすらわからん。

399 :デフォルトの名無しさん:2010/05/02(日) 21:45:03
オブジェクト指向とは責任と権限である。

400 :デフォルトの名無しさん:2010/05/02(日) 22:45:41
つまり、再利用

401 :デフォルトの名無しさん:2010/05/03(月) 13:38:28
>>398
そこなんだよね、オブジェクト指向の定義自体が曖昧。
しいえて言うならば、

> 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
> オブジェクト指向は「述語(機能)よりもその対象を中心に据える」というニュアンスをもつ用語である。

どういった印象を受けますかね。
どことなく左なニュアンスで、俺はこれが嫌いなんだよね。

402 :デフォルトの名無しさん:2010/05/03(月) 18:33:05
一言で言うなら、「対象(=責務)を中心に機能を整理するコンセプト」というあたりでいいと思うけどね。
ところで「左」って?

403 :デフォルトの名無しさん:2010/05/03(月) 18:40:32
>>398
そもそも大半のパラダイムに「対立概念」なんて無いハズなんだけどな。
よく対比される手続き型と関数型だって、じゃあ論理型は?ってなるし。

404 :デフォルトの名無しさん:2010/05/03(月) 18:42:51
責務君は本当に頭おかしいよ。
対象って言ってんだから、対象だろうよ。
お前みたいなのが居るからOOPは嫌になる。

405 :デフォルトの名無しさん:2010/05/03(月) 18:47:13
>>403
手続き型と関数型は、副作用の有無で明確に色分けされてる。
では、OOPとそうでないものは、何を基準に色分けすればよい?

406 :デフォルトの名無しさん:2010/05/03(月) 19:23:20
副作用がない手続き型ってのもあると思うけど?

407 :デフォルトの名無しさん:2010/05/03(月) 19:29:40
副作用がなくとも関数がファーストクラスでなければ関数型とは言えないだろうな
もっとも副作用のない手続き型言語なんて俺は見たことがないが

408 :デフォルトの名無しさん:2010/05/03(月) 20:28:08
>>404
「述語(機能)よりもその対象を中心に据える」
⇔「対象がどういう機能を提供するかを中心に整理する」と考えるなら、
⇔「対象の責務から持つべき機能を逆算する」でいいと思うんだが。

昔はともかく、今の考え方でいえばオブジェクト指向において「責務」はキーワードだろう。

409 :デフォルトの名無しさん:2010/05/03(月) 20:35:18
デザイン手法の説明としてならまだしも
言語パラダイムの説明としては非具体的過ぎて全然しっくり来ない


410 :デフォルトの名無しさん:2010/05/03(月) 20:50:28
>>409
言語パラダイムとしては、それこそ色々なアプローチが百家争鳴なわけで、
そこで定義するのは無理じゃないかな、正直な話。
それよか、デザイン手法の理解から入って、
その実装に役立つ手法を考えていく方が生産的だと思うな。

411 :デフォルトの名無しさん:2010/05/03(月) 20:56:46
その上で、あえて言語パラダイム的な観点から言えば、
「委譲より継承」「インタフェース」あたりがキーワードだろうな。

例えば、俺がさっき本屋で買った「インターフェイス指向設計」って本なんかは、
ぱらぱらとめくってみた感じ、その辺のエッセンスがまとまってそうな感じだった。
わりと「分かってる人向け」に書かれてるらしいのでお勧めできるかは微妙だが。

412 :411:2010/05/03(月) 20:59:02
すまん、逆だ。

× 「委譲より継承」
○ 「継承より委譲」

413 :デフォルトの名無しさん:2010/05/03(月) 21:06:57
>>411
それでは狭すぎる
非クラスベース、ダックタイピング、structual subtypingなOOが
ずっぽり抜けてるだろ

414 :デフォルトの名無しさん:2010/05/03(月) 21:10:54
単純に
データと、データの操作をひとまとめにした『オブジェクト』を中心に据えた言語
では駄目なのか

415 :デフォルトの名無しさん:2010/05/03(月) 21:21:42
>>413
という話が出てくるから、結局「オブジェクト指向の定義」として語るには微妙だよね、と。
なら、デザインレベルの話を中心にして、言語処理系ごとのテクニックを共有するに留めた方がよかないか。

>>414
それだと、例えば抽象データ型(もっと言えばインタフェース)が説明できない。

416 :デフォルトの名無しさん:2010/05/03(月) 21:26:51
>>415
> それだと、例えば抽象データ型(もっと言えばインタフェース)が説明できない。

具象のないインタフェース「だけ」で成立するオブジェクト指向言語は存在しないし
インタフェースのないオブジェクト指向言語なら沢山ある
つまり、それは本質ではないのでは?
インタフェースの背後にはかならず具体的なオブジェクトが存在するわけだろ

オブジェクトとオブジェクトが語り合う上で「インタフェースを経由する」
「メッセージパッシングを行う」といった手法は、重要ではあるにせよ
言語毎の詳細に過ぎないと思うが

417 :デフォルトの名無しさん:2010/05/03(月) 21:48:07
>>416
君の言うとおり、「オブジェクト指向」を名乗る言語処理系は色々あるし、
インタフェース的な要素をサポートしてない言語はたくさんあるわけだが、
少なくとも、GoF本に代表される最近主流の解釈でいけば、
「インタフェース」の概念は重要だろう。具象より抽象。

で、なぜ抽象中心で考えるべきか、という話には色々な事情があるわけだが、
分かりやすいところで言えば、アジャイル開発とかテスト駆動開発なんかとの
絡みが大きいんだと思う。単体テストのしやすさ、とかね。

418 :デフォルトの名無しさん:2010/05/03(月) 21:52:38
オブジェクト指向というのは言語を分類する概念ではないのかもね。
コードとデータを「まとめる」だけなら、CでもアセンブリでもMLでも可能なんだし
(「まとめる」の定義次第ではあるが)

419 :デフォルトの名無しさん:2010/05/03(月) 21:54:56
「オブジェクト指向入門 第2版 原則・コンセプト」(バートランド・メイヤー、2007年)
http://www.amazon.co.jp/dp/4798111112

本当は、議論の前にこういう原典的な本を読んだ方がいいんだろうけどな。
ただ、今日本屋で手に取ってみたが、ここまで分厚い(約1000ページ)と威圧感が凄いし、何より値段が。。
んで、手ごろな本というとなかなか無いのが悩ましい。

420 :デフォルトの名無しさん:2010/05/03(月) 21:55:40
オブジェクト指向のうま味だけを取り入れようとしたマルチパラダイムな言語が主流になってるから
オブジェクト指向があやふやになるのも仕方がないわな

421 :デフォルトの名無しさん:2010/05/03(月) 21:56:16
>>417
いやだから、GoF本の「インタフェースと実装の分離」は
C++とその一族みたいなクラス/継承ベースの静的型言語特有の問題だろ

それに、そうした言語においても、
インタフェースの背後には「必ず」具象オブジェクトがある「必ず」だ
あくまでその特有の言語において、具象を抽象化するプロトコルに過ぎん

アジャイル云々はそれこそどうでもいいだろ
OOの定義/共通項を抽象化しようとしてるんだから、反論するのなら
>>414に沿わない言語の例でも上げてみたらどうなんだ
インタフェースは何の反例にもなっていない、それらの言語にも
具体的なオブジェクトが「必ず」存在するんだから


422 :デフォルトの名無しさん:2010/05/03(月) 21:59:28
>>418
「オブジェクト指向でコードを書きやすい言語」というくらいかもね。
特に近年提唱されている実践とか開発手法を考慮すると、言語処理系だけで話は完結しないし。

423 :デフォルトの名無しさん:2010/05/03(月) 22:02:14
>>418
「まとめる」のは、単にオブジェクト指向的な設計手法
それをサポートする具体的な何か(たとえばクラス)を備えている言語が
オブジェクト指向言語、だろ



424 :デフォルトの名無しさん:2010/05/03(月) 22:09:28
>>421
例えば、DIコンテナを使って具象にMockを差し込むことで単体テストを容易にする、
みたいなことをやるのは、あくまでそのオブジェクトが果たす「責務」をテストしたいわけで、
具象自体は責務をエミュレートするMockと常に入れ替え可能なわけだ、この場合。

>>414も一面では正解だが、近年の実践を踏まえると誤解を招く可能性が高いと思う。

425 :デフォルトの名無しさん:2010/05/03(月) 22:19:46
>>424
言っている意味は分かるよ
書いている気分や設計としては、インタフェースを相手にしているのであって
具象、ましてやデータのことは考えていないと言いたい訳だろ

が、俺の考えでは、それはOOの「上の」設計の話だな
その例でも、結局(実行時に)仕事をするのは全て具象オブジェクトとその間の
やりとりなわけで、それがOOの共通項であり本質だと思うが

具象オブジェクトを隠蔽すべし、みたいなのは、あくまでOOの「上」での
良き設計の方法論に過ぎんと思う
例えて言えば、あんたのは「手続き型言語」と「構造化手法」をごっちゃに語っている
ようなものだ

426 :デフォルトの名無しさん:2010/05/03(月) 22:32:55
>>425
そっちの言いたいことも分かるが、そういう「下」の話を含めだすと、
議論の共通前提を作るという意味では、あまりメリットがない気がするんだよな。

アセンブラの時代ならともかく、今は人間の良き設計を良きコードに落とせてこそ
良き道具(=言語処理系)だと思うし、「データと操作を一括りにできること」という
わりとアバウトな分類で色んな言語を括ることにどんなメリットがあるのかな、と。

427 :デフォルトの名無しさん:2010/05/03(月) 22:37:49
>>426
いやだから、インタフェースが全く「共通項」にはならないことは示したよね?
それどころか、手続き型言語における「構造化手法」より重要度が低く、弱いよ

JavaScript, Ruby, Pythonのような言語にはインタフェースはないし、
必要ですらないんだから

428 :デフォルトの名無しさん:2010/05/03(月) 22:50:00
>>427
それはイエス。

そもそも「データと操作を一括りにできること」という定義の提唱に対する反論であって、
それ自体に反対してるわけではないよ。俺の立場は、さっきも言ったように、
「オブジェクト指向は設計レベルを中心に論じるべき」という立場だからね。

429 :デフォルトの名無しさん:2010/05/03(月) 22:54:10
>>428
なるほど、OOはプログラミングパラダイムとしては定義不可、という立場?

最終的にその結論でも別にいいけど、俺にはインタフェースは反論の根拠としては
失礼ながら薄弱なように思えたので、もっと強烈なのがないのかと
こうして粘っているわけだw

430 :デフォルトの名無しさん:2010/05/03(月) 23:00:09
>>429
立場というか、お察しの通り動的型方面には弱いので正直分からんというか。
ただ、OOP or OOPLとして一貫性のある「オブジェクト指向」の説得的な定義は
今のところ見たことがないね。

「メッセージ指向か抽象データ型指向か」という話は言語談義としては面白いけど、
あんまし本質的だと思えない。

431 :デフォルトの名無しさん:2010/05/04(火) 02:15:56
だからさ、Wikipediaにこう書いてあるじゃん。

> 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
> オブジェクト指向は「述語(機能)よりもその対象を中心に据える」というニュアンスをもつ用語である。

このニュアンスに従うと、
述語(対象1, 対象2, 対象3); //func(obj1, obj2, obj3);
こういう処理があったとして、
非OOPでは、述語(つまり関数)を中心に据えて指向し、
OOPでは、対象(つまり引数)を中心に据えて指向する、
ってことだろ。
ただ、単一ディスパッチのOOPの場合、
中心に据えるべき対象が定まらなくて困る場合があるよ、と。

432 :デフォルトの名無しさん:2010/05/04(火) 02:26:36
>>431
日本語でおk

433 :デフォルトの名無しさん:2010/05/04(火) 02:28:51
ただ、俺はこうも思ってるわけ。
目的語と述語だと、述語の方が重要だと。
それは、述語が目的語と目的語の関係を定義するものだから。
目的語と目的語の関係を定義して、機能が生まれる。
functionは、関係の定義「関数」であり、同時に機能とも訳される。
その思想は大事にしたいんだよね。

434 :デフォルトの名無しさん:2010/05/04(火) 02:39:38
          ____
       / \  /\ キリッ
.     / (ー)  (ー)\    「その思想は大事にしたいんだよね」
    /   ⌒(__人__)⌒ \
    |      |r┬-|    |
     \     `ー’´   /
    ノ            \
  /´               ヽ
 |    l              \
 ヽ    -一””””~~``’ー?、   -一”””’ー-、.
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

435 :デフォルトの名無しさん:2010/05/04(火) 12:11:10
>>431
Wikipedia を盲信してるんだな。

436 :デフォルトの名無しさん:2010/05/04(火) 12:15:21
英語版Wikipediaには

Object-oriented programming (OOP) is a programming paradigm that uses "objects" -- data structures consisting of datafields and methods together with their interactions -- to design applications and computer programs.

とはっきり書いてある
日本語版は駄目駄目だな

437 :デフォルトの名無しさん:2010/05/04(火) 12:51:52
OOとOOPが別れているのは何でなんだろうな
英語版は別れてないのに

438 :デフォルトの名無しさん:2010/05/04(火) 13:05:11
「OOP + OOAD」を全部ひっくるめてOOPと呼んでるだけじゃね。

439 :デフォルトの名無しさん:2010/05/05(水) 14:50:19
OO持ち上げてる連中の中に「OOしてなくちゃソフトじゃねぇ」的なノリがあるんだよなぁ
# 「でも、おまえ、制御系書けないだろ」って奴に限って、そのノリが強いのが痛い


440 :デフォルトの名無しさん:2010/05/05(水) 15:30:43
被害妄想乙

441 :デフォルトの名無しさん:2010/05/05(水) 16:47:02
老害乙

442 :デフォルトの名無しさん:2010/05/05(水) 16:55:09
オブジェクト指向の再利用は、本当に有効か?

新規にコーディングする場合、開放/閉鎖原則や単一責任原則など、
将来の再利用を考えてコーディングする。
もちろん、構造化で作るよりコストがかかるが、再利用が有効に働くなら、
初回にコストを掛けるのも悪くない。

しかし、改造でデータ・フィールドの持ち方の構造が(リストからツリーとか)
変るような変更なら、再利用を有効に機能しない。
そもそも、改造自体がない場合も多い。

技術者は預言者や占い師じゃない。将来どんな改造があるかなんて
予想出来ない。そんな不確定な再利用にコストを掛けるんじゃなく、
新規の仕様や改造の仕様を、その都度構造化でやったほうが
トータル的に見てもコストは低いんじゃないのか?

443 :デフォルトの名無しさん:2010/05/05(水) 17:00:12
フレームワークはOOの成功例だと思う
MFCは失敗例っつーかなんというかゴミ

444 :デフォルトの名無しさん:2010/05/05(水) 17:01:19
まぁ末端のドカタはクラスを利用するだけで自分で作ることはないからな
ドカタはOOpの勉強なんかせんでええよ

445 :デフォルトの名無しさん:2010/05/05(水) 17:07:10
OOにしたから再利用しやすいなんてのは幻想だろ

デザパタでは再利用性を向上するために短期的視点では面倒なことをやるわけだが
それも「クラス・継承ベースの多態・静的型のOOPL」という限定付の
世界での話に過ぎん

デザパタが対象としているタイプのOOPLの始祖とも言えるC++だが、STL以後の
標準ライブラリやboostのようなライブラリにおいて、
むしろテンプレートによるコンパイル時多態/ダックタイピングや
関数型に近い手法を多用するスタイルが主流になっていることに注意しよう
そのほうがずっと強力で汎用性が高いことをSTLが証明してしまった
からだ

ま、言語としてのC++自体を褒めはしないが、マルチパラダイムで組める
言語のほうが何にせよ気楽だね

446 :デフォルトの名無しさん:2010/05/05(水) 17:21:18
いまどきOOで再利用性の方を強調してる奴なんかいないだろ?
そういうメリットもある、という程度。

447 :デフォルトの名無しさん:2010/05/05(水) 17:28:08
>>446
OOの一番のメリットってなに?

448 :デフォルトの名無しさん:2010/05/05(水) 17:31:05
>>443
20年近く前の、テンプレートもないC++の草創期に作られたライブラリを今さらとりあげてゴミっていわれてもな。

449 :デフォルトの名無しさん:2010/05/05(水) 17:40:04
>>447
高凝集かつ疎結合なシステムを構築しやすい。

450 :デフォルトの名無しさん:2010/05/05(水) 17:41:41
>>445
C++のテンプレートは、C++言語の大きな欠点とされているだろ。

451 :デフォルトの名無しさん:2010/05/05(水) 17:49:01
メタプログラミングはオブジェクト指向と対立する概念ではないんじゃ。

452 :デフォルトの名無しさん:2010/05/05(水) 17:54:46
>>449
それはOOだけじゃない。

453 :デフォルトの名無しさん:2010/05/05(水) 17:56:34
>>452
別にOOだけのウリだとは一言も言っていない。

454 :デフォルトの名無しさん:2010/05/05(水) 18:15:15
>>453
それだと、OOの一番のメリットっと言わないだろう。 普通は。

455 :デフォルトの名無しさん:2010/05/05(水) 18:20:24
>>450
別にC++のテンプレートを褒める気は無い
重要なのは、あの醜悪な道具を使ったSTL並の道具を
C++の伝統的なOOの手法では作れなかったということ

Stroustrup自身が、自分にはSTLのようなものは作れなかったし、その発想が
無かったと認めている
STLの作者自身はOO嫌いらしいね

456 :デフォルトの名無しさん:2010/05/05(水) 18:27:36
>>454
日本語でおk

457 :デフォルトの名無しさん:2010/05/05(水) 18:34:31
>>449
構造化言語でも出来る。

458 :デフォルトの名無しさん:2010/05/05(水) 18:37:40
>>454
ほっとけ、相手はOOを知らないアホだから。

459 :デフォルトの名無しさん:2010/05/05(水) 18:50:08
>>457
可能か不可能かで言えば可能かもしれないな。

460 :デフォルトの名無しさん:2010/05/05(水) 18:59:42
>>455
C++(というかStroustrup)にとってのOOは、最近の責務ベースのOOとは全然違うからな。

461 :デフォルトの名無しさん:2010/05/05(水) 19:38:00
>>444
http://www.youtube.com/watch?v=CFZiil0DfMc

462 :デフォルトの名無しさん:2010/05/05(水) 20:12:58
>>460
STLの例は、責務ベースだとか責務ベースでないとかは、関係ないよ

STLを知っている人には通じると思うが
STLの根底にあるアイデアは、コンテナとアルゴリズムを分離し、
良く定義されたプロトコル(iterator)を糊として使うというもので、発想は
非OO的

分離することで、コンテナ×アルゴリズムという乗算量になってしまう実装の手間が
コンテナ+アルゴリズムという加算量の手間で済み
テンプレートの提供するダックタイピングの能力とあわせて、
継承階層と無関係に、組み込み型の配列やポインタでも同様に利用できる

463 :デフォルトの名無しさん:2010/05/05(水) 20:13:56
>>448
ほぼ同じ時期(むしろMFC以前)に出来ていたTurboC++のOWLなんかはまともなフレームワークだったよ

464 :デフォルトの名無しさん:2010/05/05(水) 20:53:50
>>462
それがOOと何の関係があるの?

465 :デフォルトの名無しさん:2010/05/05(水) 22:02:45
>>461
http://www.youtube.com/watch?v=i6-1934HZG0

466 :デフォルトの名無しさん:2010/05/05(水) 22:04:00
>>464
おまえ空気嫁てないなw
STLはOOと関係ないっていう話をしてるんだよw

467 :デフォルトの名無しさん:2010/05/05(水) 22:06:44
>>466
そりゃそうだ。

468 :デフォルトの名無しさん:2010/05/06(木) 02:41:11
テンプレートは便利なんだよ。
ただ、型推論をもうちょっと強力にして、
template<>とかいちいち宣言しなくていいようにしてほしい。

auto add( auto &a, auto &b )
{
  return a+b;
}

こんなかんじで。

あと、型推論にunionもほしいんだよな。

auto a;
B b; C c;
a = b;
a = c;
//aはBとCのunionになる。

で、このunionなaで、関数の呼び出しが動的オーバーロードされりゃポリモも出来るな。

469 :デフォルトの名無しさん:2010/05/06(木) 05:26:34
自分で作ったら

470 :デフォルトの名無しさん:2010/05/06(木) 12:50:49
>>468
その辺を突き詰めると、Haskellの言語仕様に近くなるような気がする。

471 :デフォルトの名無しさん:2010/05/08(土) 02:14:38
OO、OO言ってるやつらは、
MLのモジュールとかHaskellの型クラスとか分かってんのかな?
色々な構造化の手法を知って、その共通点とか相異点を実感して、
初めてOOの特徴が分かるってもんだろ
日本語しか知らないのに、日本語の特徴は...って語ってるのと同じだぞ

472 :デフォルトの名無しさん:2010/05/08(土) 02:17:40
日本語の特徴は主語が無いことです

473 :デフォルトの名無しさん:2010/05/08(土) 02:22:59
シーザーを理解するためにシーザーである必要はない。

474 :デフォルトの名無しさん:2010/05/08(土) 02:52:55
>>473
よく分からないww

どこぞやの生き残りブログでもそうだけど、
OOの話になるとC言語と比べた話くらいしか出てこないのがとても残念
モジュールやファンクターの世界を知れば、
OOではクラスがそのまま型になっている事が便利な理由であり制約でもあると気づけるのに
型クラスの世界を知れば、
OOではIdentityが前提だからインスタンスを指定する必要があったんだと気づけるのに
井の中にしか興味ないなら仕方ないけどさ

475 :デフォルトの名無しさん:2010/05/08(土) 02:55:22
ローマに行ったときはローマ人のように振舞いなさい

476 :デフォルトの名無しさん:2010/05/08(土) 02:57:27
>>474
もっと具体的に。

477 :デフォルトの名無しさん:2010/05/08(土) 03:11:46
>>476
いや、もう十分具体的じゃんww
まずはバリアントとレコードとモジュールとファンクターとシグネチャーを勉強してくれ
OOとは別の世界があるから

それから、Identityとpurely functionalの意味をHaskellを触りながらでも実感してくれ
OOがどれだけ副作用と切り離せないか分かるから

478 :デフォルトの名無しさん:2010/05/08(土) 04:11:36
関数言語厨うぜ

479 :デフォルトの名無しさん:2010/05/08(土) 07:10:17
>>477
実際 Haskell って楽しい?ちょっと興味はある
コード書く上で、例えばメイン処理、サブ処理1、1の結果を得て別の結果を返すサブ処理2と
3つのルーチンを考えた時、ベタな実装って具体的にどうなるの?


480 :デフォルトの名無しさん:2010/05/08(土) 07:40:50
>>479
それくらい、ぐぐろうよ
ttp://www.sampou.org/haskell/tutorial-j/functions.html

頑張って型クラスまで辿り着いてねー

481 :デフォルトの名無しさん:2010/05/08(土) 07:47:33
>>480
ググろうじゃなくて実際に書いてる人としてお前の感想聞きたいんだけど


482 :デフォルトの名無しさん:2010/05/08(土) 08:00:40
>>481
こりゃ失礼
もちろん楽しいです
λ計算や圏論や型理論が基礎にあって、地に足が付いている感が好きです

483 :デフォルトの名無しさん:2010/05/08(土) 08:51:21
なんだ
いつものひとかw

484 :デフォルトの名無しさん:2010/05/08(土) 09:16:19
>>483
えっww
OCamlのスレには書き込むけど、このスレは>>471が初めてなんだがww

485 :デフォルトの名無しさん:2010/05/08(土) 10:04:08
>>479
Haskellの人じゃないけど
メインとサブの処理にするなら、そのまま関数にすればいいと思う
サブ1の結果を使うサブ2があるなら、サブ2の引数にサブ1の結果を渡すだけ

486 :デフォルトの名無しさん:2010/05/08(土) 10:10:19
このスレで学びながら考えて、オブジェクト指向はいままでのプログラム作成法の集大成なんじゃないかな、と思った。

487 :デフォルトの名無しさん:2010/05/08(土) 10:33:28
>>486
OOPは、よくできたプログラムの構造を研究した結果でてきたもの。

488 :デフォルトの名無しさん:2010/05/09(日) 12:07:43
何を学んだんだと小一時間(ry

489 :デフォルトの名無しさん:2010/05/10(月) 11:57:56
このスレで学んだこと:
>>324-325が意外と的を射ているのかも
・Erlangって面白そう

490 :デフォルトの名無しさん:2010/05/11(火) 20:48:45
自分の頭がOOになっていないため、オブジェクトは最低限にして、残りは関数にした方が素早くプログラムできます。

関数といっても副作用のあるC言語的な関数です。

491 :デフォルトの名無しさん:2010/05/11(火) 21:25:32
ok

492 :デフォルトの名無しさん:2010/05/11(火) 21:39:20
>>489
>このスレで学んだこと:
>・>>324-325が意外と的を射ているのかも
それは一番駄目な奴のとろだから。


493 :デフォルトの名無しさん:2010/05/11(火) 22:52:42
上とろ
中とろ
下とろ

494 :デフォルトの名無しさん:2010/05/12(水) 17:41:10
>>492
324,325=489
ほっといてやれ。

495 :デフォルトの名無しさん:2010/05/14(金) 16:37:31
OOって役に立ってる?
確かに既存ライブラリを使うときにはOOで整備されていると楽だけど
自分で作る部分は、それほどOOにする必要がない場合が多いんだよね。

496 :デフォルトの名無しさん:2010/05/14(金) 16:41:58
>>495
あれは複数人で開発(意思の疎通、統合が不自由)したり、
全体像が把握できないほどコード量が膨大になったりしたときに
役に立つんだと思うよ。

497 :デフォルトの名無しさん:2010/05/14(金) 17:20:12
おまえらどれだけ小さいプログラムしか書かないんだ。フラグの山から解放される快適さを知れ。

498 :デフォルトの名無しさん:2010/05/14(金) 17:36:11
そんなのオブジェクト嗜好でなくとも解放されるわい。
それをしてオブジェクト施行というならオブジェクト思考でないプログラミングなんてありえない。

499 :デフォルトの名無しさん:2010/05/14(金) 18:29:43
アセンブリしか見えないw

500 :デフォルトの名無しさん:2010/05/14(金) 18:41:17
随分とシコウを色んな単語に変換してくれるIMEだなw
まあ、フラグの山は流石に例えがおかしいが。

501 :デフォルトの名無しさん:2010/05/15(土) 00:21:51
一人で開発する場合でもポリモとか役立つよ

502 :デフォルトの名無しさん:2010/05/15(土) 00:33:10
ポリモしたい部分だけクロージャで渡せば
オブジェクトなんて必要ないのに

503 :デフォルトの名無しさん:2010/05/15(土) 01:50:46
俺がポリモだった頃、女房はクロージャで息子はオブジェクトだった
わかるかな?

504 :デフォルトの名無しさん:2010/05/15(土) 05:27:51
>>502
オブジェクトの種類によって決まってる処理なら、オブジェクトだけ渡せば済むほうが気楽だなあ

505 :デフォルトの名無しさん:2010/05/15(土) 05:44:26
>>502
手動でOOPしている。

506 :デフォルトの名無しさん:2010/05/15(土) 13:06:00
どうしてなの

507 :デフォルトの名無しさん:2010/05/16(日) 12:04:07
>>506
OOPを使うやつらに役に立たない連中が多いからじゃね?


508 :デフォルトの名無しさん:2010/05/18(火) 11:25:27
>>507
十把一絡げでレッテル貼りぱねぇっす‥ て、一瞬言おうと思ったが‥
深いかもしれない。言葉通りじゃなく、なんか深い


509 :デフォルトの名無しさん:2010/05/20(木) 00:46:21
必要以上に異常にOOPにこだわるおじさんいますよね……

510 :デフォルトの名無しさん:2010/05/20(木) 00:50:12
アランケイ信者か

511 :デフォルトの名無しさん:2010/05/23(日) 18:36:02
むしろこだわってるのは若者ですよね

512 :デフォルトの名無しさん:2010/05/23(日) 20:51:08
安蘭けい信者?


513 :デフォルトの名無しさん:2010/05/23(日) 22:36:38
これ見ると下手な食事療法とかダイエットよりも効果あったよ。
http://www.petatv.com/tvpopup/video.asp?video=agri_long&Player=wm&speed=_med

514 :デフォルトの名無しさん:2010/05/28(金) 11:31:16
しばらくHaskellを使ってからC#やVB.NETに戻ってきてプログラムを作ると
以前よりも無駄のないすっきりとしたプログラムを作れているという実感があります。

これは、処理の分割(抽象化)の能力が上がるからのような気がします。

関数型をかじりながらオブジェクト指向でプログラムを作ると良いのかもしれません。

515 :デフォルトの名無しさん:2010/05/28(金) 13:14:59
でもなー
Haskell
とかって仕事では使わないしなー

516 :デフォルトの名無しさん:2010/05/28(金) 19:57:16
うむぅ。じゃあC#とかに、Hakell使った人みたいになることを助けるような、
抽象化能力をあげるような機構とかってつくれないかな。と思ってみたり

517 :デフォルトの名無しさん:2010/05/29(土) 12:23:52
日本語でおk

518 :デフォルトの名無しさん:2010/06/10(木) 18:50:30
昔のえらい人も言ってたじゃないか。
実用するかどうかは置いといてとりあえずLISP学んどけって

519 :デフォルトの名無しさん:2010/06/12(土) 00:59:21
HaskellやってからLispに戻ってくると
「うわーすんげー楽!変数書き換えられるよ!
シーケンシャルな(書いた順に実行する)コード書けるよ!」
ってなるw

520 :デフォルトの名無しさん:2010/06/12(土) 11:29:07
手続き型脳乙

521 :デフォルトの名無しさん:2010/06/13(日) 20:59:04
いや、俺は解らんでもないな
全部手続きで書きたいワケじゃなくて、基本関数的に書いてても
局所的には手続き的にやりたい時はある
そういう時に純粋関数型だとちょっと面倒くさい、やれなくは無いんだがね

522 :デフォルトの名無しさん:2010/06/21(月) 12:33:30
そこでPythonですよ

523 :デフォルトの名無しさん:2010/06/21(月) 13:21:50
Clojure(JVMで動くLisp派生言語)はJavaのオブジェクトが使えます。
たとえばStringのtoUpperCaseメソッドはどう呼び出すかというと

( .toUpperCase "hello" )

こんな感じです。
このスレ的に、ちょっと面白い位置付けですね。

524 :デフォルトの名無しさん:2010/07/02(金) 23:44:26
OO信者が組み込み(ハード制御含む)やると、とたんに役に立たなくなるのはなぜですか?


525 :デフォルトの名無しさん:2010/07/02(金) 23:50:30
組み込みの方ってOOできるんですか?

526 :デフォルトの名無しさん:2010/07/03(土) 00:00:26
今時フツーにOOしてるが…
でも、仕様がそこらのOO屋さんの言ってるOOにはそぐわないらしいw
つか、OO分析してくれた結果が役に立たないのはなぜ?
さらに、OO言語使わないとOO出来ないのはなぜ?


527 :デフォルトの名無しさん:2010/07/04(日) 23:04:19
組込みソフトウェア開発のためのオブジェクト指向モデリング
http://www.amazon.co.jp/dp/4798111767

リアルタイムUML―オブジェクト指向による組込みシステム開発入門
http://www.amazon.co.jp/dp/4881359797

528 :デフォルトの名無しさん:2010/07/12(月) 02:33:43
>>526
世間のOOな開発手法は言語のサポートがある前提だからでしょ。
だから、そうでない場合、実装へのギャップが大きすぎるか
言語仕様に縛られて、OOとしては半端で意味のない設計になる。

他にはOO的手法は、非機能要件への対策には弱い印象がある。
極端にリソースがチープだったり、リアルタイム性が求められる時、
手法としては対処出来ない。
属人的なノウハウはあるだろうけど。

まぁ526は世間で言われるところの「OO」はしてないんじゃね?
原理主義的な(悪い意味でなく)OOであるのかも知れない。

529 :デフォルトの名無しさん:2010/07/12(月) 22:26:39
そうか?
*BSD とか OpenSolaris の kernel 読んでると十分 OO してるけどな
まぁ、言語の制約もあって cast しまくりだがw



530 :デフォルトの名無しさん:2010/07/13(火) 08:07:38
どの辺り?
OOD?P?

socketまわりぐらいしか見る機会無かったけど、
あんまりOOって感じじゃなかったような。

ちょっと興味はある。
これまで見た中でCでOOを頑張ってるのは
gtkしか知らない。
知らんだけであるとは思う。

531 :デフォルトの名無しさん:2010/07/13(火) 10:26:36
ファイルディスクリプタなんてポリモーフィズムの最たるものだと思う 。

532 :デフォルトの名無しさん:2010/07/13(火) 23:09:20
流れ的に、kernelのfdまわりの実装の話だよな?

533 :デフォルトの名無しさん:2010/07/15(木) 21:17:47
多態性=OOではないと何度(ry

534 :デフォルトの名無しさん:2010/07/15(木) 21:46:36
誰がイコールだと言っている?


535 :デフォルトの名無しさん:2010/07/15(木) 22:27:34
自分は必要条件ではなく十分条件だと思っている。

536 :デフォルトの名無しさん:2010/07/16(金) 00:27:46
>>535
a

537 :デフォルトの名無しさん:2010/07/16(金) 00:28:48
>>535
十分条件だとすると、関数型言語もOOになるがいいのか?

538 :デフォルトの名無しさん:2010/07/16(金) 03:28:11
OOは言語レベルの話じゃないだろ。

539 :デフォルトの名無しさん:2010/07/16(金) 09:48:55
1. OOには多態が必要
2. 多態さえあればOO

の2択であれば、1の方が正解に近そうだ


540 :デフォルトの名無しさん:2010/07/17(土) 20:31:36
結局いつもオブジェクトとはなんぞやって話になって、
派閥がいっぱいあって、一般論にならず、まとまらない。

もうオブジェクト指向とか語るだけ無駄だろ。
OOは皆の心の中にある。

541 :デフォルトの名無しさん:2010/07/17(土) 21:08:44
広義では情報とそれを操作する手続きを一緒の入れ物に押し込んだものをオブジェクトと呼ぶ。
その上で継承、多態、通信の方法などの個別の拡張で派閥争いがある。

542 :デフォルトの名無しさん:2010/07/17(土) 21:49:40
OO言語という道具を使って何を目指すか、次第だと思うけどな。
つまり、OOA/OODのレイヤーから逆算して議論しないとまとまるわけがない。

543 :デフォルトの名無しさん:2010/07/18(日) 00:36:22
>>541
> 広義では情報とそれを操作する手続きを一緒の入れ物に押し込んだものをオブジェクトと呼ぶ。
これだと、モジュールやファイルもオブジェクトになるな。
それどころか、static変数を持った関数も。

544 :デフォルトの名無しさん:2010/07/18(日) 00:39:54
ところがだ。
歴史上では出て来た順番が逆なもんで、
OOPは独立したもので、OODありきで考えるのは
本質的でないと言う人も居たり。

545 :デフォルトの名無しさん:2010/07/18(日) 03:13:40
歴史的にはそうかもしれないが、長年の研究によって考察が深まったのも確かなわけで、
(例えば、オブジェクト指向=「継承」「現実世界のモノを計算機に写像する方法論」という
考え方は、近年では否定される傾向にある)研究が進んだ結果再整理された、ってことで
いいんじゃないのかな。他のサイエンスでもそういうことはよくある。

546 :デフォルトの名無しさん:2010/07/18(日) 05:28:53
微分からネイピア数を定義するようなものか

547 :デフォルトの名無しさん:2010/07/18(日) 12:09:00
>>545
現在ではOOPは単なるOO開発手法のサブセットだ、
と言ってる、という理解であってる?

548 :デフォルトの名無しさん:2010/07/18(日) 20:00:30
>>547 主旨はそうんなんだろうけどな
OO開発手法が役に立たない局面は山ほどある
# 所詮、数式化出来ない屑が使う手法 > OO開発


549 :デフォルトの名無しさん:2010/07/18(日) 20:17:48
Javaで書いてるとOOPしたくなるけど
Dで書いてると「OOPなんていらんかったんや」って気分になる

なんでなんだろうな

550 :デフォルトの名無しさん:2010/07/18(日) 21:18:20
慢心・環境の違い

551 :デフォルトの名無しさん:2010/07/18(日) 22:52:54
>>548
所詮手法なんだから使えない局面があって当然で、
OOな手法もいくつかある。(RUPとICONIXぐらいしか知らんが)

OOでないのも含め、結局のところ、
いかにシステムの定義をするか、モジュールを分けるかで、
大して良し悪しはないんじゃないかなぁ。
要件によって、向き不向きはある。

552 :デフォルトの名無しさん:2010/07/19(月) 09:20:46
このさきRubyはどうなるんだろう。

553 :デフォルトの名無しさん:2010/07/19(月) 12:52:38
>>548
人間が一度に見通せる量には限界があるのだよ。
あと、天才一人だけが理解できるシステムも同様の理由で意味がない。
他の人がメンテできないからな。

554 :デフォルトの名無しさん:2010/07/19(月) 19:15:00
>>552
本来の勢いに戻るだけじゃね?

555 :デフォルトの名無しさん:2010/07/19(月) 19:34:50
Rubyって勢いなくなってるん?

556 :デフォルトの名無しさん:2010/07/19(月) 19:40:23
一時期のRailsがもてはやされた頃に比べればな
あの頃がむしろ異常だった

557 :デフォルトの名無しさん:2010/07/19(月) 19:46:52
なるほどね。
おれの主観なんだけど、RubyつかうならJavaScript使いたいとおもってしまうぜ。

プラットフォーム間のAPIが整合性をとってくれたり、
サーバーサイドでメジャーなAPサーバがでてくれたりすればなぁ・・・。

558 :デフォルトの名無しさん:2010/07/19(月) 22:29:47
>>557
ウェブプログラマwならそれでいいとおもうぜww

559 :デフォルトの名無しさん:2010/07/19(月) 22:36:35
ttp://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
昔はC#と並んで成長してたPythonはもう横ばいで、C#に完全に水をあけられたな。
C#はとうとうVisualBasicを抜いた。ジリ貧のRubyはとうとう2%割っちゃった。
次は、Objective-CがPythonを抜くのが先か、VBがPython以下まで落ちるのが先か。

560 :デフォルトの名無しさん:2010/07/20(火) 22:32:25
>>559
1%とか誤差じゃね・・・?

561 :デフォルトの名無しさん:2010/07/22(木) 22:09:20
OOのここが使えない!!OOはこれだからだめなんだ!!
とかいってないで
やくに立つ部分だけ使えよ。

562 :デフォルトの名無しさん:2010/07/23(金) 11:27:26
>>561だよね。

563 :デフォルトの名無しさん:2010/07/23(金) 20:40:37
>>561

> OOのここが使えない!!OOはこれだからだめなんだ!!

そういう具体的な指摘がでれば話は進むし、OO言語の改良にもつながると思うが、
今はそもそもOOとは何かでもめて停滞している。

もし,「OOのここが使えない!!OOはこれだからだめ」と感じるところが
あれば書いていってください。



564 :デフォルトの名無しさん:2010/07/24(土) 02:58:52
OOPの定義はともかく、OOの方法論はすでに概ね固まってるでしょ。
単に、不勉強な奴が大昔の定義を振り回す奴がいるから議論が混乱してるだけ。
OOは使えないとか言ってる奴は、メイヤーの「オブジェクト指向入門」くらいは当然読んでるよね?

565 :デフォルトの名無しさん:2010/07/24(土) 04:32:28
メイヤーの「オブジェクト指向入門」を(まともに)読んだ香具師なら
OOは使えないとか言いださないだろうから

OOは使えないとか言ってる奴は、メイヤーの「オブジェクト指向入門」は当然読んでないと思われ


566 :デフォルトの名無しさん:2010/07/31(土) 09:07:30
>>565
読んでる。
が…
声高にOOって喧伝してる奴等に使えない奴が多いから、OOは使えないと言われるんだよ


567 :デフォルトの名無しさん:2010/07/31(土) 09:48:08
見やすくてちゃんと動けばoopじゃなくてもいいよ

568 :デフォルトの名無しさん:2010/07/31(土) 09:50:27
>>566 おまえが使えない奴だということだけはよくわかった。

569 :デフォルトの名無しさん:2010/07/31(土) 18:29:28
またいつものパターンか
この流れもデザパタで定義してくれ

570 :デフォルトの名無しさん:2010/07/31(土) 21:03:03
これは多分デザパタじゃなくてイディオムに近いんじゃね

173 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)