結局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に拘ってると醜いよな
３つのオブジェクトを１つにまとめて転置するとか思考にノイズが入る

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は半分ネタなのであまりまともに受け取らないでｗ

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

そういえば電子レンジでゆで卵を作るための補助装置（金網？）とかあったなｗ

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パターンで無いようだが？）
始めから、１つのメソッドに対して異なる機能があると分かっている場合の
オブジェクト指向的なコーディングするのなら、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)な関係になる。
・処理（手続き）---相手から決まった順番で複数回の通信することにより、機能を実現する。
・メッセージ ---相手から１回の通信で、機能を完結する。（メッセージパッシング）

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

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)な関係になる。

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

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

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

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

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

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

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

俺は

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

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

手続きって何だ？

<完結した処理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 の世界では、自分の責任範囲でないデータのアクセスはたとえ１行で済む内容でも責任者を呼び出すし、
呼んだ先で何が実行されているかわからない（わからなくていい）形になる。
全部の流れを一度に把握することに拘っていると、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である糞な例として、」

日本語でおｋ

215 ：デフォルトの名無しさん：2010/04/25(日) 14:22:54

もう、揚げ足取りしか出来ないのなら書き込むなと言いたい。
お前らは俺を玩具にしたいだけなんだろ。

216 ：デフォルトの名無しさん：2010/04/25(日) 14:25:36

>>215
> お前らは俺を玩具にしたいだけなんだろ。
何その萌えキャラｗ

ちなみに俺は>>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自体も並立処理に不十分で、アクターモデルではない。

それに、オブジェクトを使う時に
１．インスタンス作成
２．メソッド実行
３．インスタンス破棄
と、基本的に逐次的に実行しないといけない。
しかし、すくなくともメソッド実行はメッセージパッシングを目指すべきだ。
「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モデルだって言ってんだろ。
なにが、言いたい？お前「主体的」の意味が分かってないのか？
もしかして、「自立的」とか「自律的」と間違っていないか？　お前は「小学４年生」かｗ
お前は、もういいよ。

230 ：デフォルトの名無しさん：2010/04/25(日) 16:28:17

>>227
「弾道計算奴隷」でググってみたが、そんなソースは見当たらないぞ。
仮にその話が本当だとして、奴隷という動力の置き換え先は「電力」だろ。

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

231 ：デフォルトの名無しさん：2010/04/25(日) 16:31:40

もうその話題は終わってる

232 ：デフォルトの名無しさん：2010/04/25(日) 16:33:24

>>222
>>229
これｗｗｗ

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

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

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

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

ＯＯ厨はドヤ顔で語るけど、実のところデザパタはバッドノウハウなんだがな。

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;
②A.Method2;
③A.Method3;
この順番で実行(制御)しなと正しく処理されないとして
下記のように②と③の途中で別のオブジェクトから①が呼ばれた場合処理が不正になる。
S1オブジェクトから-->A.Method1;
S1オブジェクトから-->A.Method2;
M1オブジェクトから-->A.Method1;
S1オブジェクトから-->A.Method3;

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

> 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を理解できない奴の言い訳にしか見えないのが悲しいねｗ

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

問題はあるかもしれないけど、学習パスとしてはデザパタ丸暗記とかでもいいと思う今日この頃。
変なオレオレオブジェクト指向を身に着けてこられるより１００倍マシ。

296 ：デフォルトの名無しさん：2010/04/29(木) 06:07:01

>>294
んっ？　それが理解していくことだと思うけど。

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

297 ：デフォルトの名無しさん：2010/04/29(木) 06:56:04

有名なアルゴリズムや定法は知っているところから話は始まる。

298 ：デフォルトの名無しさん：2010/04/29(木) 10:01:46

理解が進むと解るけど理解してない内は妨げになる、なら
それは理解の妨げになる、と同義のような。

299 ：デフォルトの名無しさん：2010/04/29(木) 10:45:32

“何の”理解の妨げになるのかによるでしょうね。

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

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

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

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っていうのは、プログラムの最後の最高効率の形なの
で。　その形の設計を出来る奴は二種類
１　プログラミングの果てをみている
２　同じようなプログラムを何度も何度も作ってきた
このどちらかでもねーならOOなんて無理なの！！！！！！！！！！！！！
おｋ？？？？？？？？？

死ね

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

325 ：(u＿・y) ◆rT33C51l9k ：2010/04/30(金) 15:06:28

カプセル化とか、ポリモとか、
手段でしかないのに、議論する意味がないｗｗｗｗｗｗｗｗｗｗ
外部から参照させたらまずいものを見えなくするのなんて当たり前だし、
今後、もしかしたら外部から見えたほうがいいかもしれないものは見えるようにするのが当たり前、
関数を使いやすくするためにポリモるのも当たり前
それすら出来ないってどういうこと

ポリモや、クラスが無くて、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

また、関数型くんかｗ
たまには、理由も書けばｗ

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」ってなんだｗ
お前が一般的と言っているのは、浅いお前の知識で思っているオブジェクト指向だろｗ

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
関数は機能ひとつだけだろ。
オブジェクトは機能のセットとして「責務」を持つようにでｋる。

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
ああそりゃすまんかったｗ

個人的な見解だが、一部のクラスベース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はプログラミングパラダイムとしては定義不可、という立場？

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

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
日本語でおｋ

433 ：デフォルトの名無しさん：2010/05/04(火) 02:28:51

ただ、俺はこうも思ってるわけ。
目的語と述語だと、述語の方が重要だと。
それは、述語が目的語と目的語の関係を定義するものだから。
目的語と目的語の関係を定義して、機能が生まれる。
functionは、関係の定義「関数」であり、同時に機能とも訳される。
その思想は大事にしたいんだよね。

434 ：デフォルトの名無しさん：2010/05/04(火) 02:39:38

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼　　　　「その思想は大事にしたいんだよね」
　　　　／　　 ⌒（__人__）⌒ ＼
　　　　|　　　　　|r┬-|　　　　|
　　　　＼　　　　 `ー’´　　／
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一””””~~｀`’ー?､　　　-一”””’ー-､.
　　ヽ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

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
日本語でおｋ

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
おまえ空気嫁てないなｗ
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 って楽しい？ちょっと興味はある
コード書く上で、例えばメイン処理、サブ処理１、１の結果を得て別の結果を返すサブ処理２と
３つのルーチンを考えた時、ベタな実装って具体的にどうなるの？

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

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に戻ってくると
「うわーすんげー楽！変数書き換えられるよ！
シーケンシャルな（書いた順に実行する）コード書けるよ！」
ってなるｗ

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ではないと何度（ｒｙ

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
ウェブプログラマｗならそれでいいとおもうぜｗｗ

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

これは多分デザパタじゃなくてイディオムに近いんじゃね

571 ：デフォルトの名無しさん：2010/08/16(月) 20:05:04

オブジェクト指向の定義はとりあえず
「オブジェクト指向入門」の最初の方に書いてるやつでいいんじゃないの？
明確な定義なんてないんだから

572 ：デフォルトの名無しさん：2010/08/16(月) 23:40:46

すてなよ、そんな不明確な定義はw

573 ：デフォルトの名無しさん：2010/08/19(木) 03:03:42

勝手にオーバーライドしてくれ。

574 ：デフォルトの名無しさん：2010/08/19(木) 06:37:43

OOPの定義は勝手にオーバーライドされ過ぎて困る
誰か偉い人final付けてくれよw

575 ：デフォルトの名無しさん：2010/08/19(木) 10:25:42

const だろ

576 ：デフォルトの名無しさん：2010/08/19(木) 21:51:27

で、定義にこだわってるのはどっち陣営なの？
OOは役に立たない派？OOは役に立つ派？

577 ：デフォルトの名無しさん：2010/08/19(木) 23:48:29

どっちとは言わず、せめて会話にしたい派

578 ：デフォルトの名無しさん：2010/08/20(金) 00:27:55

Smalltalk しようよ!!

579 ：デフォルトの名無しさん：2010/08/21(土) 02:29:31

1+2を
「1と2を足す」と考えるのが非OO
「1に+2というメッセージを送る」と考えるのがOO

580 ：デフォルトの名無しさん：2010/08/21(土) 15:10:48

>>579
ひさびさに実の有るレスを見た。

581 ：デフォルトの名無しさん：2010/08/21(土) 19:46:05

実の有る…か、ちょっとカルチャーショックだ。
当たり前過ぎて「何を今更」と思ってしまった俺はやっぱOOP脳なのかな。

582 ：デフォルトの名無しさん：2010/08/21(土) 19:54:26

>>581
OOPのメリットって一言で言うと何よ？

583 ：デフォルトの名無しさん：2010/08/21(土) 21:10:01

この流れでメリットを言うと
「そんなのOOP以前の手法でも得られる」
と返ってきて定義論争に逆戻り。
逆戻りするほど進んでないけどさ

584 ：デフォルトの名無しさん：2010/08/21(土) 21:14:27

よくできたプログラムの構造を研究した結果がOO。
OOPでよくできたプログラムができるわけではないが、よくできたプログラムはOO的な要素が大きいことが多い。

585 ：デフォルトの名無しさん：2010/08/21(土) 21:28:37

>>582
メリットというか、OOP脳の俺じゃ非OOPLで組むほうが難しいって感じかな。
必須機能が無い、という風に感じてしまう。

586 ：デフォルトの名無しさん：2010/08/22(日) 08:59:59

まずこーぞーかプログラミングすればいいんだヨ！

587 ：デフォルトの名無しさん：2010/08/22(日) 09:39:08

>>579
メッセージは、OOというかOOの一派という感じだな

588 ：デフォルトの名無しさん：2010/08/22(日) 09:46:13

>>585
実際そんなもんだと思う。
GOTOを当たり前に使っていた世代はGOTOがないと使いづらいと感じ、
違和感を感じつつも徐々にGOTOレスな構造化に移行していったりしたもんだけど、
今の世代、構造化は当たり前だからな。
当たり前の世代から見ると、なんでGOTOの有無にこだわっているの？という感じ

OOPも似たようなもので、LL言語はともかく、
FlashやActioinScriptやJavaScriptから入った最近の入門者は意外なほど当たり前にOOPしてる。
C++を触らせると難色を示すが、それはC++流のOOPだから、という話だ。

思うになんでOOPでいきなりクラスを作らせようとするのか？日常生活に喩えようとするのか？
まずは他人の設計した既存のライブラリを使って使って使いまくれよ
OOPで作れなくても、OOPで使えるようになるよ

問題はOOPの議論としてよく上がる「OOPを採用すれば使いやすく、保守性が高くなり、時間も節約できるか？」
という話なんだが、そんなことは構造化プログラミングのころも散々言われてたことで、
プログラマーの勉強や素養次第としか言えない。

589 ：デフォルトの名無しさん：2010/08/22(日) 09:54:10

とＯＯＰに挫折した池沼が申しております

590 ：デフォルトの名無しさん：2010/08/22(日) 11:32:28

>>585
OOP脳とまで自称するんなら答えておくれよ。
めんどくさいならスルーしてくれても結構。

1) メリットは一言で言うと何？
おまいが直感的に選んだ言葉を聴きたい。
一番のメリットである必要はなく、
細かい揚げ足を取ったりするつもりもないので気楽に。

2) OOPでクラスの設計をする時に気をつける点は何？
複数回答化。自分の言葉で、答えてみて欲しい。
～を参照、～を嫁、～でぐぐれの形式なら答えなくて結構。

3) OOPでうまく表現しきれない点はある？あるなら何？
便利な便利なOOP。でもこういうときはちょっと悩ましい、の例を。

OOP脳さん、期待してます。

591 ：デフォルトの名無しさん：2010/08/22(日) 11:58:43

数値が演算メソッドを持ってるというのは少なくとも実生活レベルでは直感的ではないと思うな
oopの都合上、その方が一貫性があるというだけの話

592 ：デフォルトの名無しさん：2010/08/22(日) 17:54:07

本末転倒しまくる奴ばっかだな。

593 ：585：2010/08/22(日) 18:05:10

>>590
1) 一言で言えば「思い通り書ける」なんて頓珍漢な答えになってしまう。
どうしてもOOPLを基準にしてしまうから、そこにメリットと言われても正直困るかな。
だから逆に、非OOPLで感じるデメリットのほうしか挙げられない。
OOP的な書き方をしても、やっぱ継承や多態が絡むと詰まる。
データと処理をきっちり分離して考えるべきなのは解ってるが
全てにそれやると思考時間がいきなり伸びるんだよなあ。

2) 設計とは違う気がするが、クラスは何らかのカテゴリに所属させる。
内部クラス、C++のnamespace、Rubyならmoduleで括る、
JavaやPythonはファイルが1つのカテゴリになるのでファイルの分け方を工夫。
とりあえず小さいうちは全部一個のカテゴリでもいいけど、裸にはしないかな。
そのカテゴリ外とのやりとりは最小限にするか、すっきりと共通化。Javaならインターフェースが便利。
1ページで済むような書き捨てなら別にいいけど。
要は、クラス増殖しちゃっても統制がとれるような形にするってところか。

それだけクラス書き殴ってるということでもあるが。
でも、書き殴ったクラスに「要らなくね？」という疑問を持つことはあんまりない。
むしろ書いた後に「ここ、まだ分離できるな」と思うことのほうが多いかな。

3) 純粋に「手順」を書く必要が出てきたときが悩ましい。
OOPLはだいたい手続き型などの仕組みを内包してるから書けないわけでは無いし
簡単な構造の手順なら日常的に書くのだけど
普段ならトレースも要らんし、ほとんどはオブジェクトに聞けばいいのに
それとは違った読み方／書き方をせざるを得ないのが疲れる。

594 ：590：2010/08/22(日) 18:26:20

みっちり回答してくれて、まずはありがとう！
こういう>>590具体的な質問をぶつけると、
「OOP勉強不足乙」だの「～読め」とか「的外れ」とか、
ビミョーにズラされるのが世の常のなか、どうもありがとう。

折角だから俺自身も答える。

1) メリット
一言で言うと、「さらなる整理」と思ってる。
もしくは、ほかには、単に「カプセル化」と言ってもいいかと。

整理ってのは、非OOPに比べ、継承という軸が出来たことにより、
それを旨く使って整理が出来ると俺は考えてる。
で、下手にやると、さらに散らかってしまってアンチOOPになっちゃう。

カプセル化、は、結局これをメリットに上げて十分だと思う。
非OOPでも～とか、OOPの本質とは無関係で～とか言われがちだけど。
ポリモ、デザパタうんたら言う前に、ホントはこれだけでも十分ありがたい。

3) OOPに向かないこと
なんかあったと思うけど、今すぐ思い出せない。

595 ：585：2010/08/22(日) 21:05:11

>>594
でも非OOPLやった時に継承／多態で詰まることはあっても
カプセル化で詰まることってあんまり無いんだよな～。
「この関数でのアクセスを徹底する」だけで済んじゃう話だったりするから。
継承や多態絡みの場合は根本的に考え方を変えないと上手くいかない。

596 ：デフォルトの名無しさん：2010/08/22(日) 21:17:57

多態はCなら関数ポインタ使えば実装できるな。
継承もしかりだけど。

まあ、構文支援がないとまあめんどくさくてな。

で、この関数でのアクセス専門ってのを破る
人が居るからさ、制御が必要なわけだよね。

簡単には徹底できるのかね・・・。

継承、多態は割とすぐ理解してもらえる動作かと思う。

問題はそれを行った場合のさまざまな動作を把握していない場合かね。
特定言語でわかりやすい例はC++のデストラクタとか。

597 ：デフォルトの名無しさん：2010/08/22(日) 21:26:19

Cだとポインタ演算でにじり寄ってくるからねｗ

598 ：デフォルトの名無しさん：2010/08/22(日) 21:33:47

でも多態が実用できるようになってからがOOPLの真骨頂だと思う。

599 ：デフォルトの名無しさん：2010/08/22(日) 22:37:34

久々にレスが増えてると思ったら議論のレベルがまた下がってる件。

600 ：デフォルトの名無しさん：2010/08/22(日) 22:44:42

>>599のお力でハイレベルに引き上げてくれ！

601 ：デフォルトの名無しさん：2010/08/23(月) 00:28:41

多態はほとんどの場合がオナニー

602 ：デフォルトの名無しさん：2010/08/23(月) 11:10:36

多態使えなかったらインターフェースはどうすんの？

603 ：デフォルトの名無しさん：2010/08/23(月) 12:16:17

C#あたりだとデリゲート／イベント／クロージャあるし
インタフェースと継承のJava風ポリモとの使い分けという感じかね

C++は関数ポインタも勿論使えるがテンプレート絡みでさらに色々あるな

604 ：デフォルトの名無しさん：2010/08/23(月) 12:44:18

C++はデリゲートもどきとイベントは自前でじっそうできるね。
クロージャはそうしよっかってかんじだけど。

ファイバもC++だと自前実装だからめんどくさい。

605 ：デフォルトの名無しさん：2010/08/23(月) 22:43:08

>>598
そうか？関数を簡単に渡せる方がとっても重要
静的型検査なんて、もっと賢くなれるじゃん
だめだめなのは OOPL の構文

ついでに言うと、型さえあってれば、誰にでも渡せるはずの関数が
渡せない OOPL の方が異常

まぁ、C++ の無駄な努力は認めるけどな

606 ：デフォルトの名無しさん：2010/08/23(月) 23:14:56

メソッドが呼ばれば呼ばれるでいいんじゃないの？
インターフェス構文みたいなのいらなくなるし、型チェック気にしなくてよくなる。
代わりにメソッドがあるかチェックすればいいし

607 ：デフォルトの名無しさん：2010/08/23(月) 23:31:09

>>606
ダッグタイピングのことか？

608 ：デフォルトの名無しさん：2010/08/24(火) 00:01:52

大規模プログラミングではダックタイピングは通用しない。

609 ：デフォルトの名無しさん：2010/08/24(火) 00:22:49

おまえらろくなもの作れないだろ

610 ：デフォルトの名無しさん：2010/08/24(火) 00:36:39

>>608
Pythonは？

611 ：デフォルトの名無しさん：2010/08/24(火) 00:56:04

大規模ってどのくらいなんだろ？
TwitterとかCookpadは大規模なうちなのかな

612 ：デフォルトの名無しさん：2010/08/24(火) 01:05:18

mixi最近重すぎる
PHPで書き直せ

613 ：デフォルトの名無しさん：2010/08/24(火) 01:06:23

>>612
そのネタは、Perlスレで。

614 ：デフォルトの名無しさん：2010/08/24(火) 07:34:20

>>605
あほなのはC++だ

615 ：デフォルトの名無しさん：2010/08/24(火) 09:08:50

>>611
人数が大規模な開発って意味じゃないか。
Twitterとかはインフラは大規模だが、開発は少数精鋭だろうし。

616 ：デフォルトの名無しさん：2010/08/24(火) 11:47:11

>>605
関数の扱いはOOPLによって様々だから、叩きどころとしては微妙すぎるぞ…
それに多態と関数渡しは別物で、それぞれが重要なものだと思うが

>>606
インターフェースはそのメソッドがあるかのチェックを簡単に出来るのが売りだと思う。
個人的にはPythonやRubyにもインターフェースが欲しいぐらい。
ダックタイピングに反するとは確かに思うんだけどね。

617 ：デフォルトの名無しさん：2010/08/24(火) 16:04:49

>>605
関数がファーストオブジェクトで、クロージャーを
実装していないOOPLはだめってことかいな？

あれば確かにかなり便利だけどな。

618 ：デフォルトの名無しさん：2010/08/24(火) 19:44:13

OOPに関数はありません全てメソッドです

619 ：デフォルトの名無しさん：2010/08/24(火) 19:58:56

>>618
それも言語次第。

620 ：デフォルトの名無しさん：2010/08/25(水) 00:21:10

まぁ、メソッドがクラスに属さない言語もあることだし

621 ：デフォルトの名無しさん：2010/08/25(水) 05:56:21

静的メソッドは、関数と同じ。

622 ：デフォルトの名無しさん：2010/08/25(水) 09:34:43

oop厨は素の関数なんか断じて認めないってことだろ

623 ：デフォルトの名無しさん：2010/08/25(水) 10:27:15

>>616
> インターフェースはそのメソッドがあるかのチェックを簡単に出来るのが売りだと思う。
なるほどね

Rubyでもmoduleがincludeされているか、とかそういう感じか

Ruby(に限らないが)はmethod_missingで定義してないメソッド処理できるせいで、
メソッドが有るか無いかのメソッド拡張したり、Railsのソースとか見てるとかなり必死ｗ

624 ：デフォルトの名無しさん：2010/08/25(水) 15:09:33

>>623
なるほどじゃねえだろ。
LLのOOPLしかつかったことねえのかよｗ

625 ：デフォルトの名無しさん：2010/08/25(水) 22:16:57

ポリモが最大のメリットだと思っていた時期が俺にもありました。
デザパタで最大に輝けると思っていた時期が俺にもありました。

下手な継承は、一発でゴミにする。
そのクラスや、それを使うクラスを巻き込んでクソにする。

使いにくいもん作っても、地獄に落ちていくだけ。

626 ：デフォルトの名無しさん：2010/08/25(水) 23:08:17

インターフェースの話してるだけで、継承をお勧めしているわけではないでしょ。

627 ：デフォルトの名無しさん：2010/08/25(水) 23:13:04

役に立たないか？
デザパタやらポリモやらフルに使ってるが？
ハード込みの特殊業界だが、ハードのターゲットをオブジェクトとして取り扱い
制御ソフトとして完成させるにはＯＯＰなしではもはや無理　ｗ
ハードからアプリまでやるので最近お疲れ気味だが　面白いよ
ＯＯＰは研究テーマとしてもライフワークに最適と思うが

628 ：デフォルトの名無しさん：2010/08/25(水) 23:16:57

>>627 と、状態方程式の一つもたてられない奴に言われてもなぁw

629 ：デフォルトの名無しさん：2010/08/25(水) 23:18:47

>>628
稼げるかがキーワードだと思うが

630 ：デフォルトの名無しさん：2010/08/25(水) 23:38:59

> デザパタやらポリモやらフルに使ってるが？

疑わしいｗ　(２ちゃんねら)>>627という型で話してるから気にするな。

デザパタなんて正しく使えてるやつら見たことないｗ
その問題にパターンが相応しいかどうか、ではなくて、
それ以前、パターンを正しく把握しているかすら怪しい。

とくに、AbstractFactoryパターンを正しく理解してるやつは少ない。
Builderパターンも。

631 ：デフォルトの名無しさん：2010/08/25(水) 23:45:58

>>630
やれやれ．．．．

632 ：デフォルトの名無しさん：2010/08/26(木) 00:35:44

また無能同士の煽り合いか

633 ：デフォルトの名無しさん：2010/08/26(木) 01:59:48

日本の情報リテラシーは低すぎるからな
プログラマでさえ不勉強な香具師ばかり
愚痴りたくなるのも分かるよ

634 ：デフォルトの名無しさん：2010/08/26(木) 02:02:39

愚痴ってる奴もわかってないという現実

635 ：デフォルトの名無しさん：2010/08/26(木) 11:00:15

ttp://d.hatena.ne.jp/kawango/20090612/1244802392
他人を説得するとき、ぼくが必要だと思うのは、相手の言葉、相手の理屈をつかって話せないとだめだということだ。
自分の理屈は自分と同じ知識をもっているひとにしか通用しない。

相手が理解できない理屈をふりかざす人間が多すぎる。相手の知識、常識をつかって理屈をくみたてないと意味がない

636 ：デフォルトの名無しさん：2010/08/26(木) 14:02:18

なんかしらのインスタンスを作って返すクラスを、
ビルダークラスとのたまうやつがおる。
せいぜいファクトリクラスだろうて。

で、さらにわるいのは、それらをもってして、
Builderパターン、FactoryMethodパターンであると誤解してしまうことだ。

637 ：デフォルトの名無しさん：2010/08/26(木) 19:09:24

ビルダーって組み立てるのにちょっと手が込んだ仕込みが必要なやつをまとめておくやすじゃなかったっけ？

638 ：デフォルトの名無しさん：2010/08/26(木) 19:19:05

デザパタそのものは知らなくても使えるモノだが
知らない奴が独自用語を振りまくとウザいわな
独りじゃないなら知ってたほうが良いのは間違いない

639 ：デフォルトの名無しさん：2010/08/27(金) 00:02:39

>>635
文章で説明すると、誤解が入るので数式渡すんだけどさぁ

こう作ってね、とゆって、数式渡したら全然別のものができてきたりするのは
数式渡す方が悪いって話だよねw

640 ：デフォルトの名無しさん：2010/08/27(金) 00:39:03

「こう作ってね」
つ「out = in / 2」

「できたよ」
つ「out = 0;　in = 0;」

641 ：デフォルトの名無しさん：2010/08/27(金) 21:54:52

批判の矛先が「OOp使ってる人」、「OOPL」、「デザインパターン」に向かってる
OO自体を批判できるやつはいないのか？

642 ：デフォルトの名無しさん：2010/08/27(金) 22:05:39

>641
私がやりましょう。
では、OOを定義してください。

643 ：デフォルトの名無しさん：2010/08/27(金) 22:25:31

基本的にはカプセル化、継承、多態性でいいよ。

「OO」の批判をよろしく。

644 ：デフォルトの名無しさん：2010/08/27(金) 22:32:28

>>643
継承は必須じゃない

645 ：デフォルトの名無しさん：2010/08/27(金) 22:51:42

それがOOへの批判ですか？

646 ：デフォルトの名無しさん：2010/08/27(金) 22:56:33

>>643
それは定義ではありません。
「OOとは～である」
の「～」を埋めてください。

647 ：デフォルトの名無しさん：2010/08/27(金) 22:58:54

>>645
批判のわけないだろ。

648 ：デフォルトの名無しさん：2010/08/27(金) 23:15:25

じゃ、教科書これにしよう。みんなで買って議論しようぜ。
http://www.amazon.co.jp/dp/4798111112

649 ：デフォルトの名無しさん：2010/08/27(金) 23:37:22

>>646
定義にそんなにこだわりはないからオブジェクト指向とはで検索して
最初に出てくるやつ位の認識でいいよ。

こだわりのある人は自分の定義を書いてね

650 ：デフォルトの名無しさん：2010/08/27(金) 23:48:16

現場での経験からOOpの議論がしたいんだけどあまり学術的な議論知らないんだよね。
押さえておくべき本・論文てなにがありますか？

651 ：デフォルトの名無しさん：2010/08/28(土) 00:43:10

http://d.hatena.ne.jp/asakichy/
この人のまとめをポインタに色々探してみるといいんじゃない。

652 ：デフォルトの名無しさん：2010/08/28(土) 02:24:10

http://d.hatena.ne.jp/sumim/20040525/

653 ：デフォルトの名無しさん：2010/08/28(土) 03:22:43

urlしか張らない奴は逃亡とみなします

654 ：デフォルトの名無しさん：2010/08/28(土) 06:04:00

はてなとかアホしかいねぇだろ・・

655 ：デフォルトの名無しさん：2010/08/28(土) 06:38:23

>>642
一休さんと屏風の虎ｷﾀｺﾚｗｗ

656 ：デフォルトの名無しさん：2010/08/28(土) 06:44:05

というか一休さんを絡めて >>642 のネタをマジレスしている時点で >>642 の思うつぼ杉だろ

OOPの議論している奴らや言語作っている奴ら自体がみんなバラバラの個々のOOを話しているからな。
Smalltalkですら、OOのメッセージ送信とはSmalltalkの目指しているようなOOではないというような議論に巻き込まれるｗ

657 ：デフォルトの名無しさん：2010/08/28(土) 08:16:43

>OOPの議論している奴らや言語作っている奴ら自体がみんなバラバラの個々のOOを話している
どのOOでもいいんだけどね
スレタイのとおり「役に立たないのはなぜ」を聞きたいだけで

658 ：デフォルトの名無しさん：2010/08/28(土) 09:16:53

理解できないから使えないので役立たない。

659 ：デフォルトの名無しさん：2010/08/28(土) 09:34:08

FAきたー

660 ：デフォルトの名無しさん：2010/08/28(土) 10:18:41

定番の入門書がつくられない技術って一般化しないよね。

661 ：デフォルトの名無しさん：2010/08/28(土) 11:54:26

>>660
>>648

662 ：デフォルトの名無しさん：2010/08/28(土) 14:49:32

OOPはSmalltalkerが出てこないと話にならない。

663 ：デフォルトの名無しさん：2010/08/28(土) 15:05:29

いまだにSmalltalkから離れられないやつはいらん。

664 ：デフォルトの名無しさん：2010/08/28(土) 17:29:23

>>661
そんな入門書職場の何割が読んでると思ってるの？
さらに共通の理解してるやつはどのくらい？

665 ：デフォルトの名無しさん：2010/08/28(土) 20:55:29

いあ、OOp てのは、単に勘違いの産物だと思うんだが
少し、数式とか分かる連中だと、「矛盾だらけじゃん」
って言うと思うよ

666 ：デフォルトの名無しさん：2010/08/28(土) 21:01:48

矛盾の一つでも指摘してから言おうぜ

667 ：デフォルトの名無しさん：2010/08/28(土) 21:09:42

「こうするといいらしい」だけで何の根拠もない
物理寄り

668 ：デフォルトの名無しさん：2010/08/28(土) 22:33:56

そういうのは数式で記述してくれ

669 ：デフォルトの名無しさん：2010/08/28(土) 23:01:35

>>664
理解してないのに職業プログラマを名乗るのがそもそもの間違い。

>>667
人文系の学問に完璧な統一理論が登場すればそれも可能かもしれないけどねぇ。

670 ：デフォルトの名無しさん：2010/08/28(土) 23:22:18

なにをもって理解したというのか定義してくれ

671 ：デフォルトの名無しさん：2010/08/28(土) 23:33:36

とりあえず、OOの話をしてるのに、単一責任原則も開放閉鎖原則もリスコフ則も出さずに
継承とか多態性の話ばっかしてる時点で何も理解してないだろ。

672 ：デフォルトの名無しさん：2010/08/28(土) 23:42:37

つーかお前らまともなもの開発してないだろ

673 ：デフォルトの名無しさん：2010/08/29(日) 01:35:50

>>671
よし、それらの説明全部頼んだ

674 ：デフォルトの名無しさん：2010/08/29(日) 02:35:40

OOpには開発の効率化や品質向上を期待するんだけど
なんか効果が怪しいどころか逆効果になってるシーンばかり見る

675 ：デフォルトの名無しさん：2010/08/29(日) 02:38:27

お前には無理

676 ：デフォルトの名無しさん：2010/08/29(日) 02:51:03

>>674
> OOpには開発の効率化や品質向上を期待するんだけど

この一文からして、色々と頭を抱えたくなった。

677 ：デフォルトの名無しさん：2010/08/29(日) 09:52:02

> 単一責任原則も開放閉鎖原則もリスコフ則も出さずに

羅列ｗ　次は引用の朗読か？
こういう手合い相手で話がかみ合った覚えがない。

678 ：デフォルトの名無しさん：2010/08/29(日) 10:39:51

>>675
誰なら可能なの？

679 ：デフォルトの名無しさん：2010/08/29(日) 12:02:00

うちのセンドーがやる

680 ：デフォルトの名無しさん：2010/08/29(日) 12:30:06

誰も俺についてこれないから使えないって馬鹿じゃねーの？

681 ：デフォルトの名無しさん：2010/08/29(日) 12:39:29

ネタスレにしても今時OOP不要論をマジで言ってそうな奴がいるのは情けないな。

でも、オブジェクト指向ってバズワード化してるのもまあ確かだな。
「オブジェクト指向」と言う時、何がその本質なのかを意識して言ってる人は
非常に少ないと思う。

個人的にはオブジェクト指向の本質は「空即是色」的な考え方であって、
継承だの多態だのデザインパターンだのは、オブジェクト指向を前提としているにしても
本来はオブジェクト指向の本質とは無関係だと思う。

682 ：デフォルトの名無しさん：2010/08/29(日) 12:41:02

>>681
> 個人的にはオブジェクト指向の本質は「空即是色」的な考え方であって、

本質とか考え方、とかオカルトかよｗ
単に設計、実装上の技術で十分だろ。

683 ：デフォルトの名無しさん：2010/08/29(日) 12:46:22

>>682
全然関係ないけど、非工学部系のプログラマって「技術」って言葉を軽々しく
使うのは前から気になってた。

また個人的なことを言うけど、こんな程度のものを「技術」とか言っちゃうのは
非常に不遜でおこがましく感じる。というか、技術技術いう奴って自己陶酔型の人間
なんだろうなと思う。

684 ：デフォルトの名無しさん：2010/08/29(日) 12:50:40

理学系のプログラマが「技術」って言葉を軽々しく使うことなんて聞いたことがないな

685 ：デフォルトの名無しさん：2010/08/29(日) 12:57:05

>>684
少なくとも日本じゃ絶対数少ないし。

これまた関係ないけど、物理屋や数学屋が、「量子論の本質」とか「関数論の本質」
って言ったらオカルトなのかねw

686 ：デフォルトの名無しさん：2010/08/29(日) 13:07:42

最近オカルトって聞くと麻雀用語に見えてしまう

687 ：デフォルトの名無しさん：2010/08/29(日) 13:24:12

>>683
一生思ってろｗ

688 ：デフォルトの名無しさん：2010/08/29(日) 13:50:45

まぁ、さっさとデザインパターンの勉強でもしてこいってことだ。
継承や多態性なんて最初の一時間で理解すべき最低限の概念だ。
足し算と引き算ができるようになりました、程度の意味しかない。

689 ：デフォルトの名無しさん：2010/08/29(日) 13:53:26

> 継承や多態性なんて

どーだかなぁー。
下手な継承、山ほどみるどー。

むしろ、OOPへの不満は、下手な継承から始まってるとすら思う。

690 ：デフォルトの名無しさん：2010/08/29(日) 14:01:08

>>689
そこで、足し算と引き算の上手な使い方を学習できるテンプレが「デザインパターン」だろ。
デザパタが提唱するパターンがどういう原理に基づいているかを考えれば、
継承や多態性なんて、単なる設計の道具、螺子や釘に過ぎないことが分かるはずだ。

それを理解できて、ようやく入門卒業ってとこじゃないか。

691 ：デフォルトの名無しさん：2010/08/29(日) 14:11:13

>>690
おーけーおーけー。
言ってる意味は分かった。同意したい。

継承やポリモをいかにして使うかなんて、
上手に教えてくれる教材がないもんな。
いや、ないかどうかは言い切れないが、
デザパタは十分役に立つと思う。

さらに、少なくともデザパタを経由するくらいの状態にないと、
OOPのメリットなんざ少ないと思うんだろうなとも思う。
よくわかってねー状態で、「ポリモなんざ複雑なだけ」
「カプセル化って面倒だなぁ」とか思ってる状態では。

692 ：デフォルトの名無しさん：2010/08/29(日) 14:36:14

>>663
Smalltalkをそんなふうに馬鹿にするものでもないよ。ある程度突っ込んで使ってみれば、OOPを含めて
いろんな概念がゲシュタルト崩壊おこすことうけあい。案外、理解できてなかったんだなーってけっこう笑える。

デザパタやGUIみたいに古いものだけでなく、TraitsやClassboxみたいに新しいものも生み出して、現在進行形で
多くの言語や環境に影響を与え続ける存在って他にはない希有なものだと思うし。SqueakとかVisualWorksとかで
実装がどうなっているのかちょっと調べて納得できる程度の軽いスキルは身につけておいて損はないと思う。

693 ：デフォルトの名無しさん：2010/08/29(日) 14:36:28

なんか、会社ってところはどこもそうなのかも知れないけどさ
良い人から辞めちゃうよね
んでもって、腹黒い人とか、他人を動とも思わない人とか、
図々しい人とか、・・・そんなのばかりがテコでも動かないぜって
感じで居座り続ける・・・
会社って、こうやってダメになっていくんだと思う
それはそのまんま居座り族・牛耳り族が社会をダメにしていくって
ことなんだ。。。

694 ：デフォルトの名無しさん：2010/08/29(日) 14:41:16

誤爆け？ｗ

695 ：デフォルトの名無しさん：2010/08/29(日) 15:00:38

あと、デザパタを「丸暗記」でなく「理解」しようとした経験があるなら、
開放閉鎖原則、みたいなキーワードには当然辿り着いているはずだ。

>>671は、つまり、そういうことだ。

さらに言えば、それらの原則を精査すれば、その目的が「開発の効率化（笑」などではなく、
コードの柔軟性や保守性に焦点を置いていることにも気づくはずなんだけどな。
（オブジェクト指向とアジャイル開発がしばしばセットで語られる理由もそこにある）

696 ：デフォルトの名無しさん：2010/08/29(日) 15:36:24

つまりテンプレート最強ですね
わかります

697 ：デフォルトの名無しさん：2010/08/29(日) 16:07:58

>>695
コードの柔軟性や保守性は開発の効率化につながるんじゃないの？

698 ：デフォルトの名無しさん：2010/08/29(日) 16:09:56

> つまり、そういうことだ。

どういう（；＾ω＾）？

699 ：デフォルトの名無しさん：2010/08/29(日) 16:36:37

テンプレートとかジェネリクスとか見てると
ポリモーフィズムなんていらないって思えるよね

700 ：デフォルトの名無しさん：2010/08/29(日) 16:54:22

>>699
型を強く意識するようなOOPだとそれはないわｗ
もちろん多態やギェネリクスは便利だけどね。

701 ：デフォルトの名無しさん：2010/08/29(日) 17:24:24

ダッグタイピングがOOPでないとでも思ってるのかな。

702 ：デフォルトの名無しさん：2010/08/29(日) 17:41:19

ＯＯｐが役に立たないのは　本人の能力の問題かと？

703 ：デフォルトの名無しさん：2010/08/29(日) 17:44:49

>>697
結果としてね。けど、それは「ソフトウェアは常に変化が要求される」という前提があってこそ。
一次開発しか考えてないなら恩恵は少ない。むしろ効率が下がる場合だってあるだろう。

704 ：デフォルトの名無しさん：2010/08/29(日) 17:48:56

なんかいつもの流れだな。口ばっか。

705 ：デフォルトの名無しさん：2010/08/29(日) 17:50:22

>>695
これはひどいなｗ

706 ：デフォルトの名無しさん：2010/08/29(日) 18:12:40

>>705
どこがひどいのか具体的に批判して。

707 ：デフォルトの名無しさん：2010/08/29(日) 18:20:17

開発の効率化とコードの柔軟性や保守性を対立項目と考えてるところ

708 ：デフォルトの名無しさん：2010/08/29(日) 18:26:55

ALGOL由来の構造化は確実に開発効率(ここでは保守性も含む)を向上させたけど
C++やJavaが開発効率を更に上げたのだろうか。

709 ：デフォルトの名無しさん：2010/08/29(日) 18:27:54

>>707
Ａ．君の誤読。そんなことは一言も言ってない。

710 ：デフォルトの名無しさん：2010/08/29(日) 18:31:58

>>709
＞その目的が「開発の効率化（笑」などではなく、
＞コードの柔軟性や保守性に焦点を置いていることにも気づくはずなんだけどな。

711 ：デフォルトの名無しさん：2010/08/29(日) 18:33:24

オレだけが唯一無二の最強の存在であり他はカス

こうですね

712 ：デフォルトの名無しさん：2010/08/29(日) 18:43:43

ひとりで開発できればいいんだけどな。
少なくとも他人のコードをコントロールすべがないと話にならないね。
お前らアホだからだめなんだよじゃプロジェクトは終わらない。

713 ：デフォルトの名無しさん：2010/08/29(日) 19:14:39

>>710
>>703

714 ：デフォルトの名無しさん：2010/08/29(日) 19:18:32

>>713
いやその見識が浅いって言ってるんだが

715 ：デフォルトの名無しさん：2010/08/29(日) 19:18:36

>>712
とりあえず、勉強する気が全くない奴をプログラマ扱いしてる現状は何とかすべき。
バズワードに飛びついてる奴の方が、「○○はバズワード（笑」とか言って冷笑してる奴より１００倍マシ。

716 ：デフォルトの名無しさん：2010/08/29(日) 19:19:42

OOPの定義がアヤフヤなんだよな。
メリット以前に。

717 ：デフォルトの名無しさん：2010/08/29(日) 19:21:40

>>714
ソフトのメンテナンスを考慮しないという前提なら、設計とか抽象化とか考えずに
スパゲッティーを垂れ流した方が「開発効率」は高い場合もあるだろ。その程度の話だよ。

718 ：デフォルトの名無しさん：2010/08/29(日) 19:21:50

>>715
お前に何とかできないのだけはわかった

719 ：デフォルトの名無しさん：2010/08/29(日) 19:23:24

その程度ｗ

720 ：デフォルトの名無しさん：2010/08/29(日) 19:26:38

Rubyってさ
Railsかぶせて
元のRubyと似ても似つかない言語にしておいて
Rubyが普及したって喜んでるんだぜ？
他に無いだろこんなOO言語

721 ：デフォルトの名無しさん：2010/08/29(日) 19:30:14

rubyってすごい書くとき書きやすくて、
スイスイ、ストレス無くいけるんだけど、
あとから読むとソースが読みにくい。

一方、Javaはやや冗長だけど、
後から読むとき、テラ読みやすい。
何年たってもすぐ思い出す。
やっぱ結局、型が旨いんだろうな。

722 ：デフォルトの名無しさん：2010/08/29(日) 19:32:50

>>719
不満があるなら具体的に反論してくれ。

723 ：デフォルトの名無しさん：2010/08/29(日) 19:35:41

1.4系からのRubyistとしては「あんな黒魔術普及しないだろ、てかして欲しくない」って思ってたよ

>>710
俺はそこ、対立項目でなく「並立するけど焦点ではない」と読んだのだが。

>>698
その上2行ってことじゃね。

724 ：デフォルトの名無しさん：2010/08/29(日) 19:40:20

お前の興味ない話はその程度ってスタンスがすでに話にならないんだよ。
＞「開発効率」は高い場合もある
は無視できる理由にならないだろ。実際アジャイルなんて口にしている以上
リファクタリングが開発に影響しないというスタンスは矛盾に近い。

>>723
対立ではなく排他に近いかな。軽視。

725 ：デフォルトの名無しさん：2010/08/29(日) 19:40:51

>>718
１．底辺プログラマを全員クビにする。自称プログラマの採用を禁止する
２．単価が上がる
３．優秀な奴がプログラマへの道を志すようになる
４．プロジェクトメンバーの質が上がる
５．ヘブン状態

726 ：デフォルトの名無しさん：2010/08/29(日) 19:41:54

１．底辺プログラマを全員クビにする。
２．残った連中でデスマ
３．ヘブン状態

727 ：デフォルトの名無しさん：2010/08/29(日) 19:43:06

>>725
あなたに企画書には実現性が感じられない

728 ：デフォルトの名無しさん：2010/08/29(日) 19:43:32

>>724
開発効率が高い方が良い、なんてのは大前提じゃないの。
それを軽視するエンジニアが存在するとは思えん。

俺が言いたいのは、「OOの目的は開発効率の向上です」なる言明は、
目的と手段とその結果を履き違えてるってこと。別に開発効率を軽視したりはしていない。

729 ：デフォルトの名無しさん：2010/08/29(日) 19:44:25

>>728
は？大前提は目的外なの？意味不明。

730 ：デフォルトの名無しさん：2010/08/29(日) 19:48:00

お前らが煮えきらんから俺が言ってやる。

「OOの目的は開発効率の向上です」と、断言できないことこそが問題。
OOPか、お前の力量か、どっちかが問題。

731 ：デフォルトの名無しさん：2010/08/29(日) 19:49:48

>>729
俺のは「OOを採用したらむしろ開発効率が下がった、期待はずれだ！」的なありがちな意見への反論だからな。
確かに目の前の一次開発しか見てないなら「開発効率」は下がるだろうけど、OOのような手法の主眼はそこじゃねぇだろう、と。

732 ：デフォルトの名無しさん：2010/08/29(日) 19:50:03

>>730
誰に何言ってるのかやっぱり意味不明。

733 ：デフォルトの名無しさん：2010/08/29(日) 19:51:22

>>731
最初からなぜそういえないのかね。
では保守性とやらは現場で本当に上がっているか？
それはOOpのどんな技術によるものと考えているか？

734 ：デフォルトの名無しさん：2010/08/29(日) 19:53:54

一時開発でさえ基本部分はOOでちゃんと設計して、
あとは適当な実装を手本としてコピペ実装してもらわんと効率悪いぞ。

735 ：デフォルトの名無しさん：2010/08/29(日) 19:56:21

>>734
しかし>>731で言われているように開発効率が下がっていることが多々ある現実

736 ：デフォルトの名無しさん：2010/08/29(日) 19:59:41

>>735
下手にやれば下がる。保守性も下がる。
普通にやっても下がる。
上手くやれば下がらない。

737 ：デフォルトの名無しさん：2010/08/29(日) 19:59:44

>>735
それは多分世にあふれている型ベースのOOをあまり理解してないからかねえ。
深く継承しすぎて変更時のコストが大変なことになってるとか。

738 ：デフォルトの名無しさん：2010/08/29(日) 20:00:40

で俺以外バカ理論に戻ると

739 ：デフォルトの名無しさん：2010/08/29(日) 20:01:26

>>733
最初から言って・・・まぁ伝わったからいいや。
まぁ、教科書的な言い方をすれば、
「責務ベースで設計して各モジュールを最小化することにより、役割が明確になり保守性が高まる」
か。あと、OOpはそれを実現するための道具に過ぎない。

740 ：デフォルトの名無しさん：2010/08/29(日) 20:01:50

結局構造化プログラミングに比べてOOpは特効薬じゃないってこと

741 ：デフォルトの名無しさん：2010/08/29(日) 20:03:04

>>739
OOpでモジュール化を促進している技術要素はなんですか？

742 ：デフォルトの名無しさん：2010/08/29(日) 20:03:34

>>737
「継承(IS A)より委譲(HAS A)」は、
まともにデザパタを勉強してれば当然身についてるはずなんだけどねぇ。

743 ：デフォルトの名無しさん：2010/08/29(日) 20:04:33

～なはず
お前の読みが甘いってことだろ

744 ：デフォルトの名無しさん：2010/08/29(日) 20:05:03

実装の継承を大いに推奨して、
得意満面ピックアップしたC++およびハゲが全部悪い。

745 ：デフォルトの名無しさん：2010/08/29(日) 20:11:11

>>741
どれも重要だが、特に重要なものを一つ上げるなら、静的型言語ならインタフェース。
動的型は詳しくないが、やはりmix-inになるのか。

746 ：デフォルトの名無しさん：2010/08/29(日) 20:14:01

>>726
っ『人月の神話』

747 ：デフォルトの名無しさん：2010/08/29(日) 20:14:49

>>745
＞どれも重要だが
これがOOpの問題のひとつ。
あらゆる技術を俺の理解にあわせてくれってチームで言っても実現しない。

748 ：デフォルトの名無しさん：2010/08/29(日) 20:15:29

>>747
だな。

749 ：デフォルトの名無しさん：2010/08/29(日) 20:18:14

>>747
意味がよく分からなかったのでもっと具体的に。

750 ：デフォルトの名無しさん：2010/08/29(日) 20:18:47

>>749
お前が望むオブジェクト指向とやらはチーム全員で共有されていますか？

751 ：デフォルトの名無しさん：2010/08/29(日) 20:21:37

>>750
共有されてるも何も、まともな関連書は腐るほど出版されてるんだから、
各人がきちんと勉強すればいいだけじゃないの？

752 ：デフォルトの名無しさん：2010/08/29(日) 20:22:01

>>747
例えばC++でプロジェクト進めてても設計は多種多様。
基本設計がフォーマット化されてなく
一子相伝のようにできるやつベースのシステムのときにはじめてある程度機能する。
これも従順なスタッフのときのみで俺OOpばかりだとすごいことになる。
これは確立された技術なんだろうか。

753 ：デフォルトの名無しさん：2010/08/29(日) 20:23:16

>>751
その回答でどのくらい納得されるんだろうね。
このスレで散々OOpを定義しろってレスが出てきてるのに
勉強しろで君と理解共有できる人間がどのくらいいると思うの？

754 ：デフォルトの名無しさん：2010/08/29(日) 20:25:19

構造化プログラミングを定義しろって議論はないよな。
これはどういう違いなんだろう。

755 ：デフォルトの名無しさん：2010/08/29(日) 21:02:47

>>753
いいからGoF本読んどけって。

756 ：デフォルトの名無しさん：2010/08/29(日) 21:06:51

>>754
構造化プログラミングの定義で議論が起こらない理由：
１．エドガー・ダイクストラ提唱のものしかない
２．定義は一度聞いただけで暗記できるほどシンプル
３．構造化プログラミング言語は初心者にも定義通りのコードを強制する

オブジェクト指向プログラミングの原則で議論が起こる理由：
１．複数の流派が存在する
２．さまざまな原則が積み上げられてきた
３．オブジェクト指向言語には初心者に原則通りのコードを強制する力がない

757 ：デフォルトの名無しさん：2010/08/29(日) 21:07:52

>>755
そういう返しは意味ないから。
みんなにGoF読んどけっていっとけばプロジェクトうまくいくんなら
世の中のソフト開発どこも問題起きない。

758 ：デフォルトの名無しさん：2010/08/29(日) 21:11:28

>>756
とくに
＞３．オブジェクト指向言語には初心者に原則通りのコードを強制する力がない
がなぜできないのか研究されてないのかな
JavaもすべてにstaticつければCのようにかけるもんな。

759 ：デフォルトの名無しさん：2010/08/29(日) 21:14:27

>>758
IDEとか静的解析ツールを併用すればいいんじゃない。

760 ：デフォルトの名無しさん：2010/08/29(日) 21:18:41

また中身があるようでないことをｗ。
具体的にどのツールでなにすれば何が強制出来てどんな効果があるんだよ。

761 ：デフォルトの名無しさん：2010/08/29(日) 21:24:22

>>760
各種リファクタリングツールとかcheckstyleとか、色々あるだろ。

まぁ、限界があるのはそうかもな。
構造化はコーディングスタイルの強制でまともになる部分が大きいけど、
OOは基本的に設計手法なわけで、OO「P」の部分で強制するのは難しい。

だから、よくあるパターンとしては、上級者がフレームワークを作って、
初心者にはフレームワークを使ってコードを書かせるとかあるよね。

762 ：デフォルトの名無しさん：2010/08/29(日) 21:29:53

>>761
結局難しいじゃんｗ。
フレームワークは俺もそう思うけど結局フレームワークは各人によってまちまち。
これはOOpって技法の優位性とは違うと思う。

763 ：デフォルトの名無しさん：2010/08/29(日) 21:40:01

>>757
「俗流」でないオブジェクト指向を理解する一番の早道はやっぱりGoF本を読んで
研究することだと思うが。「丸暗記」じゃなくてね。

764 ：デフォルトの名無しさん：2010/08/29(日) 21:42:25

>>763
いやそんな開発現場構築できてるんならその方法本にすればベストセラーになりますよ。ってこと。
オタク知識開陳なら意味ないよ。

765 ：デフォルトの名無しさん：2010/08/29(日) 21:43:03

お前はGoFのパターンしかねえのかよｗ

766 ：デフォルトの名無しさん：2010/08/29(日) 21:44:33

GoF読めばみんな幸せ

767 ：デフォルトの名無しさん：2010/08/29(日) 21:46:21

>>762
作ったフレームワークの設計を強制できるのはOOP言語の利点とは言えるんじゃない。

というか、決まった手順を踏めば誰でも良いオブジェクト指向フレームワークが書ける、
というものを期待しているのだとしたら、それはお門違いじゃないか？

教科書的な部分で提供できるのは、共通の語彙とベスト・プラクティスの提供まで。
（デザパタも、効用の一つは「パターンについての共通語彙の提供だ」というのはよく言われる）
それ以上は、それこそ「勉強しろ」「経験を積め」としか言いようがない。

768 ：デフォルトの名無しさん：2010/08/29(日) 21:47:55

>>767
結局どこかにある天国を見つけられないのはお前のせいってことだね。
詐欺商法と何が違うんだろうね。

769 ：デフォルトの名無しさん：2010/08/29(日) 21:48:31

>>767がいいこと書いた！

770 ：デフォルトの名無しさん：2010/08/29(日) 21:49:39

>>767
今のOOp言語は強制力ないね。
いくらでも逸脱可能。

771 ：デフォルトの名無しさん：2010/08/29(日) 21:50:18

>>767に同意だな

772 ：デフォルトの名無しさん：2010/08/29(日) 21:50:25

結局体系化されてない概念なんだよね。

773 ：デフォルトの名無しさん：2010/08/29(日) 21:51:36

>>770
お前はプログラム組まずにアプリ使っとけよ。

774 ：デフォルトの名無しさん：2010/08/29(日) 21:52:11

>>773
そして開発室から誰もいなくなった。

775 ：デフォルトの名無しさん：2010/08/29(日) 21:53:29

>>768
エンジニアなのに天国とか探しちゃう男の人って・・・。

776 ：デフォルトの名無しさん：2010/08/29(日) 21:55:40

>>768
自分に言い訳してるみたいだなｗ、○○がないから使えないとか。

777 ：デフォルトの名無しさん：2010/08/29(日) 22:00:48

７７７

778 ：デフォルトの名無しさん：2010/08/29(日) 22:01:48

>>776
そうじゃない。現場で実効性があるのかってこと。
妄信している奴のほうが信用できない・

779 ：デフォルトの名無しさん：2010/08/29(日) 22:06:50

>>778
少なくとも、オープンソース・ソフトウェアとかを見る限り、大半のプロジェクトで
OOやデザパタの語彙が採用されているのは確か。
いわゆる「システム開発」の現場で導入が進まなかったり失敗したりしてるのは、
オブジェクト指向という理念自身の問題ではないと思うよ。

780 ：デフォルトの名無しさん：2010/08/29(日) 22:17:25

大半のプロジェクト？どのくらいコード読んでるのか疑問だが。
オープンソースはそれそのものに競争原理が効いているから
リーダーの能力の高いものは成功しやすいよね。
採用例が多いというのはメリットがあるからだというのはそりゃそうなんだろう。

＞いわゆる「システム開発」の現場で導入が進まなかったり失敗したりしてるのは、
＞オブジェクト指向という理念自身の問題ではないと思うよ。
ということも可能だが

オブジェクト指向を導入することにより「システム開発」の現場が改善できるわけではない。
ともいえるよね。

OOpの適用範囲を過大評価してることが多いからすごい気になる。
デメリットになってることも良くあるし。

781 ：デフォルトの名無しさん：2010/08/29(日) 22:25:50

>>780
それは「××」という新しい方法論（××にはOOでもアジャイルでもTDDでも好きなものを）を
うまく取り入れられない組織運営とかプロジェクトマネジメントの問題だよね、はっきり言って。
オブジェクト指向のメリット・デメリットとはあまり関係がないな。というより、全く別の話。

782 ：デフォルトの名無しさん：2010/08/29(日) 22:28:25

>>781
オブジェクト指向のコンセプトが理解しづらい面があるからじゃないか？
C言語導入しました、Java導入しましたレベルじゃないと難しい。
しかも誰がウィザードかっていうのが非常に判断しにくい。

783 ：デフォルトの名無しさん：2010/08/29(日) 22:40:27

>>745
いや童貞言語の場合はmixinよりダックタイピングのが重要かと
と言うか、インターフェースに相当する部分をダックタイピングでやってる
でも動的言語でもインターフェースは有効だと思うんだがな
巷の動的言語ったインターフェース無いんだよなあ

784 ：デフォルトの名無しさん：2010/08/29(日) 22:48:56

>>782
否定はしない。けど、ある程度の勉強はやっぱり必要なんじゃないかね。

785 ：デフォルトの名無しさん：2010/08/29(日) 22:50:45

>>721 >>723
Railsのすごさは「Rubyってメタプログラミングが当たり前の言語だったんだ！！」とか
「Rubyって以下略が当たり前の以下略」と思わせるところだな

先日からのカンファレンスRubykaigiでも
Railsの前と後でのRuby界隈の変化を語ったセッションがあってタイミング的にくそわろた

これね
動画：How to survive in after Rails' time., How to survive in after Rails' time. rubykaigi on USTREAM. 会議
http://www.ustream.tv/recorded/9223155
プレゼン資料：How to survive in post Rails' world.
http://www.slideshare.net/hsbt/how-to-survive-in-post-rails-world

786 ：デフォルトの名無しさん：2010/08/29(日) 22:58:01

hsbtさん就職したんだ、へー。

787 ：デフォルトの名無しさん：2010/08/29(日) 23:00:29

>>761
後半同意。Rubyの話がちょうどでてたからいうけど、
RailsはOOPとか知らなくてもクソみたいなアプリいくらでも作れる。

デザインパターンとかなにそれなにな人でもつくれる。
フレームワークがいろいろ代わりにやってくれてるからね。
OOPやデザパタをライブラリ経由で使っていても意識しない。
自称OOP言語のRubyの標準ライブラリを使うのにOOな使い方が必須だとしてもそんなに意識しなくても使い始められるのと同様。

ただし、一歩踏み出して、
共通部分を使いやすいようにRailsプラグインをつくろう！なんて思うと途端にRuby流のOOP、
モジュールの使い方、メタプログラミング、上でも出ていたAfter RailsなRubyの使い方などの理解が必要になる。

この壁はぶち当たった人はわかると思うが、けっこう高い。既存のRubyユーザでも

788 ：デフォルトの名無しさん：2010/08/29(日) 23:00:43

>>738
おれもプロトタイプベースのOOPLにインターフェースがあってほしとおもってる。

789 ：デフォルトの名無しさん：2010/08/29(日) 23:05:52

みんなSmalltalkやればいいんだよ
あれはオブジェクト指向養成ギプスだから

790 ：デフォルトの名無しさん：2010/08/29(日) 23:11:13

>>785
キチガイｗｗｗ

791 ：デフォルトの名無しさん：2010/09/02(木) 13:39:09

オブジェクト指向スレって軒並み落ちてここぐらいしか残ってないのかな

調べてみたらselfにはクラスが無かった
プロトタイプベースのOOは、どういう風に用語を使っているんだろう
インスタンス化、とかそんな用語はあるのだろうか？
詳しい人いたら教えてくれ

792 ：デフォルトの名無しさん：2010/09/02(木) 13:47:55

JavaScriptなんかは関数がファーストオブジェクトになっていて、
その内部に存在する変数は環境として、実行後にも値は破棄されない。

コンストラクタはないけど、同様な働きをするものは作成できる。

Selfは知らないけど似たようなことで実現してるとかあるかもね。

793 ：デフォルトの名無しさん：2010/09/02(木) 14:37:50

javascriptの仕様書には用語としてコンストラクタはあるよ
その説明はOOっていうよりもscheme由来の環境の話だし
それにファーストオブジェクトじゃなくてファーストクラスオブジェクトだろう

javascriptにはクラスって言葉がオブジェクト指向の意味で出てこないから
Object instanceなんて使い方をしてあったりする
だからプロトタイプベースのオリジナルはどうなのかなって思ってね

794 ：デフォルトの名無しさん：2010/09/03(金) 00:06:16

C++が複雑怪奇な仕様じゃなければね・・・

795 ：デフォルトの名無しさん：2010/09/03(金) 01:35:07

C++はヘッダとそれに起因する参照順序問題さえなければ良いのにな。

796 ：デフォルトの名無しさん：2010/09/03(金) 03:51:28

ん？

797 ：デフォルトの名無しさん：2010/09/03(金) 04:50:06

本筋以外で手間かけさせんなよって事でね。

798 ：デフォルトの名無しさん：2010/09/03(金) 08:53:37

それは正直どうでもいい。

799 ：デフォルトの名無しさん：2010/09/03(金) 12:34:25

よくわからんけど、ライブラリを参照する順番？
それとOOが関係あるかは知らんが・・・

そういやObject PascalというかDelphiは2つのファイルをCでいうヘッダー部で相互参照できなくて
クラス同士の相互参照もしにくくなかなか腐ってたな

例えば、class Aがclass Bのインスタンスを保持している、class BがAに保持されているとしてclass Aを返すことができない
相互に参照できないだけなので、どっちかのメソッドや変数の型をスーパクラスにして
使うときはキャストすればいいんだが面倒

クソ言語だったが、C++もそういうクソ言語なのか？

800 ：デフォルトの名無しさん：2010/09/03(金) 13:44:21

プリプロセッサがない言語はゴミ

801 ：デフォルトの名無しさん：2010/09/03(金) 17:39:36

ヘッダの依存関係がうざい
オブジェクトが増えてくると

802 ：デフォルトの名無しさん：2010/09/03(金) 19:07:32

ここ10年くらいC++に触れてもいないけど、
プリプロセッサが無くて困ったことは一度たりともないな。

803 ：デフォルトの名無しさん：2010/09/03(金) 22:41:11

ここ10年くらいlispにしか触れていないけど、
プリプロセッサが無くて困ったことは一度たりともないな。

804 ：デフォルトの名無しさん：2010/09/04(土) 00:29:40

プリプロセッサがなんだかわかってないだろ

805 ：デフォルトの名無しさん：2010/09/04(土) 01:14:41

>>802
携帯のJavaのリソース不足はプリプロセッサを言語仕様に入れなかった開発者を絞め殺したくなる
むろん、Javaのせいではないはずだが

806 ：デフォルトの名無しさん：2010/09/04(土) 01:45:51

言語仕様に入れなくてもgcc -Eもで使えばいいのでは？

807 ：デフォルトの名無しさん：2010/09/04(土) 09:06:33

>>805
Javaでプリプロセッサなんて何に使うんだ？

808 ：デフォルトの名無しさん：2010/09/04(土) 10:41:40

うちは携帯アプリ作ってるけど
俺の作ったプリプロセッサかましてるよ
そこで携帯キャリアごとの差分や
端末バージョン毎の差分を吸収してる
まぁわざわざ作らんでもgccやcl使えばよす

809 ：デフォルトの名無しさん：2010/09/04(土) 15:36:03

俺はプリプロセッサ無し派を支持するな
>>808みたいにすればいいわけだし

もしもCにプリプロセッサが無かったら
開発支援ツールがもっと便利になっていたのは間違いない

810 ：デフォルトの名無しさん：2010/09/04(土) 16:40:28

言語仕様にないとIDEとの連動がめんどうじゃね？

811 ：デフォルトの名無しさん：2010/09/04(土) 19:19:25

言語自体がプリプロセッサともいえるLispには昔から強力なIDEが腐るほどありますが...

812 ：デフォルトの名無しさん：2010/09/04(土) 19:43:58

>>811
言語自体が死んでる

813 ：デフォルトの名無しさん：2010/09/04(土) 19:58:59

>>812
日常的に使ってる会社もあったりするんだな
java より開発効率いいし…

814 ：デフォルトの名無しさん：2010/09/05(日) 00:10:18

ここまで依存性注入の話題無し。

815 ：デフォルトの名無しさん：2010/09/05(日) 03:39:55

自分で語れない人はお帰りください

816 ：デフォルトの名無しさん：2010/09/05(日) 18:26:55

>>802
ソースファイルが500MBくらいの巨大な一個のファイルに収まってるんですね

817 ：デフォルトの名無しさん：2010/09/05(日) 18:57:23

>>816
？

818 ：デフォルトの名無しさん：2010/09/05(日) 19:27:19

.hの中に暮らす本体まで書く香具師ってなんなの？

819 ：デフォルトの名無しさん：2010/09/05(日) 19:47:39

めんどくさがりやさんなんだろ

820 ：デフォルトの名無しさん：2010/09/05(日) 20:05:46

最近は.hに本体を書くのが主流なんじゃねーの。

821 ：デフォルトの名無しさん：2010/09/05(日) 20:10:15

C++/CLIはそうなってる

822 ：デフォルトの名無しさん：2010/09/05(日) 20:33:41

ヘッダに色々かいたら参照関係ぐちゃぐちゃになんね

823 ：デフォルトの名無しさん：2010/09/05(日) 21:04:15

> ヘッダに色々かいたら参照関係ぐちゃぐちゃに
じゃないことに気が付けよ
最近の言語には package とか namespase とか…

824 ：デフォルトの名無しさん：2010/09/05(日) 21:11:34

いや最近の言語で良いんならそれでいいだろ

825 ：デフォルトの名無しさん：2010/09/05(日) 21:20:15

#include <main.c>
みたいなのもありだな

826 ：デフォルトの名無しさん：2010/09/05(日) 21:40:06

JavaやC#に慣れてたら、ヘッダに本体書くのが自然だと思うだろう。

827 ：デフォルトの名無しさん：2010/09/05(日) 21:49:37

.みいかのはアセンブリレベルで公開非公開とか決まるから
ヘッダで丸見えとかどうでもいいんだよ。

828 ：デフォルトの名無しさん：2010/09/05(日) 23:17:48

>>826
意味不明。
コンパイラがファイルを跨いでシンボルを検索しないCの仕様が糞だとは思うように
なるかもしれないが、そんな風に思わない。

そもそも「ヘッダファイル」なんて意味不明な呼び名になってるから今の話の流れみたいな訳の分からん
勘違いをする奴が出てくるんだろうな。

実態はただのアセンブラの「インクルード(included)ファイル」まんまなんだから
素直にそう呼ぶべきだったんだと思う。

829 ：デフォルトの名無しさん：2010/09/05(日) 23:37:54

ヘッダに定義を書いてたらコンパイル時間がどんどん増えていく
その言語にはその言語のマナーがあるわけで
他の言語での自然さとかは関係ないでしょ
C++での例外は、templateを書くケース

830 ：デフォルトの名無しさん：2010/09/06(月) 04:05:20

JavaやC#ってヘッダーは特にないような気がするが・・・

831 ：デフォルトの名無しさん：2010/09/06(月) 06:27:52

>>828,830
おまえら、ほんとにJavaとC++の両方使えるのか？

832 ：デフォルトの名無しさん：2010/09/06(月) 06:46:57

import *;
とかしてそう

833 ：デフォルトの名無しさん：2010/09/06(月) 19:12:53

ヘッダの話とかどうでもよくない？OOPに関係あるわけ？
プリプロセスなんぞ、各個人/プロジェクトで好きにすりゃいいじゃん。

で、俺は思うんだけど、「オブジェクト指向」って、なんで、オブジェクトを指向するの？
その手の、「物/対象」を指向する戦略は、プログラミング以外の分野でことごとく失敗してきてるんだけど。
ちゃんと歴史学んだ？世の中見てるの？
他所で失敗した考え方を、なぜまたプログラミングの分野に適応して、まーた失敗を繰り返したいの？
社会学ではどうだった？
「人」(⇔社会)を中心とした考え方って言ったら、共産主義やら左翼やら民主党のばら撒き政策やら、
目先の利益だけを見た短絡的な個人主義の考え方で、こんなの上手くいくわけねーって分かりきってるだろ。
歴史が散々証明してきたことだろ。
今21世紀だよ。本当にこんな赤い考え方で上手くいくと思ってるわけ？どっちの船に乗る？

嘘だと思ってる？回り見渡してみろよ。OOPに取り付かれてしまって屍と化した奴の名前を自分の中で挙げてみ。
どうだ？アランケイとかRubyの中の人とかεπιστημηとか、頭逝っちゃってる率高すぎだろ。
C言語のそれと比べてどう思う？
は　・　や　・　く　・　き　・　づ　・　け
手遅れになっても知らんぞ(べジータAA ry

834 ：デフォルトの名無しさん：2010/09/06(月) 19:17:53

俺はヤムチャだまで読んだ。

835 ：デフォルトの名無しさん：2010/09/06(月) 19:22:03

ヤムチャなら仕方ない

836 ：デフォルトの名無しさん：2010/09/06(月) 20:13:45

>>833
なんか君って痛い人みたいね
頭逝っちゃってるのはお前さんだろってw

ちなみに、「オブジェクト指向」的な発想で設計されているものは世の中にたくさんある。
君が気がついてないだけw

837 ：デフォルトの名無しさん：2010/09/06(月) 21:04:57

クリストファー・アレグザンダーとか有名だね

838 ：デフォルトの名無しさん：2010/09/06(月) 21:19:41

そもそも宇宙がオブジェクト指向なんだが

839 ：デフォルトの名無しさん：2010/09/06(月) 21:23:00

>>833
君が「オブジェクト指向」をどう定義しているかわからんので、
その点についてはノーコメントだが、
共産主義を個人主義の考え方とみなしているところだけ見ても
社会学も歴史学もたいして学んでいないことがわかる。

あれほど全体主義的な考え方はないことは、
これまでの共産主義国家をみれば明らか。
マルクスからして「類的存在」としての人間しか考慮しておらず、
それが共産主義の間違いの大本の原因になっている。

840 ：デフォルトの名無しさん：2010/09/06(月) 21:24:07

OOPをうまく使えなかった者が、
OOPを恨みだしたように見える。

841 ：デフォルトの名無しさん：2010/09/07(火) 00:11:50

OOPだろうがなんだろうが、最終的には依存関係整理して機能をうまく制限して区切っていかないと処理が絡みあって崩壊する
いまんとこそれにある程度成功してるのがOOPってだけ

842 ：デフォルトの名無しさん：2010/09/07(火) 00:14:32

機能を制限するって考え方は大事だな。

843 ：デフォルトの名無しさん：2010/09/07(火) 01:04:18

言いたいことは分からんでもないが、ちょっとずれてる。

機能を制限してどうするの。
そんな考え方は概論としても間違ってる。

メンバを隠蔽するのは、別に機能を制限するためじゃなくて「操作する必用がない機能」
をマスクすることで「操作する必用がある機能」を明確にし、複雑性を縮減するため。

外食屋のシステム（客は直接厨房に細かい注文を出したりしない）を「機能の制限」
と考える奴は普通はいない。

だって、厨房の中の誰にどんな指示を出せばいいか知らなくても飯が食えるようにするために、
注文取りのお姉さんとだけコミュニケーションすればいいシステムにしてるんだから。

844 ：デフォルトの名無しさん：2010/09/07(火) 06:28:03

>>843
言葉遊びして何か楽しいの？
相手の意図を汲まずにくだらない上げ足しかとれないようならレスなんて書くなと

845 ：デフォルトの名無しさん：2010/09/07(火) 06:58:56

クラスにまとめるってのが、機能の制限って事でしょ。
外食屋のシステムで動物園やろうと考える奴はいない。（動物を飼う機能はいらない）

そして「何でも」クラスは設計崩壊の元、機能を制限しろ、一つの仕事に集中させろ。

846 ：デフォルトの名無しさん：2010/09/07(火) 07:05:05

寿司屋で水族館やったりはするが

847 ：デフォルトの名無しさん：2010/09/07(火) 07:18:36

その場合、寿司屋クラスと水族館クラスを合成して新たに「寿司屋で水族館」クラスにすべきであって
寿司屋クラスを継承して魚飼えるようにして「機能の制限」を無かったことにするのがダメって事じゃね

848 ：デフォルトの名無しさん：2010/09/07(火) 08:01:20

というより、水族館の仕事は水族館に任せる（委譲）すべき。
継承より委譲。

849 ：デフォルトの名無しさん：2010/09/07(火) 08:20:12

あと、オブジェクトをリアルの物体や役割に当てはめる例え方がよくない理由の一つでもあるな。
リアルなら「あれもこれも」はアリだが、プログラムの世界としては、あるオブジェクトの役割は
常に一つであるべき。単一責任原則。

850 ：デフォルトの名無しさん：2010/09/07(火) 17:50:29

>>643
気になってたことが解決した
ありがとう

851 ：デフォルトの名無しさん：2010/09/07(火) 19:46:59

Animalクラスでbarkメソッドがあって
派生クラスのDogとCatがbarkでワンとニャーと表示する。
なんか、そういう説明がダメってよく聞くけど
これってどこがダメなの？

852 ：デフォルトの名無しさん：2010/09/07(火) 19:48:04

>>844
言葉遊びでも揚げ足取りでもない。
そもそも隠蔽はOOPの概念じゃないがまあそれはいいとして、
プログラミングの世界の「隠蔽」を機能の制限という捉え方は普通はしない。

853 ：デフォルトの名無しさん：2010/09/07(火) 19:56:23

元の発言のどこにも隠蔽の話は出てきてないように思うが

854 ：デフォルトの名無しさん：2010/09/07(火) 20:01:09

じゃあ何が機能の制限か言ってみろよ。
馬鹿じゃないのか

855 ：デフォルトの名無しさん：2010/09/07(火) 20:11:17

>>851
それクラスベースOOで多態の説明だろ。
てかOO一機能の多態しか説明していない。

この説明がダメではなく、これがOOだとおもってるやつがダメ。

856 ：デフォルトの名無しさん：2010/09/07(火) 20:42:48

>>851
http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/

857 ：デフォルトの名無しさん：2010/09/07(火) 20:46:24

>>855 なるほど、納得しました。
is-a関係/has-a関係だとかにも同じ指摘が成り立つのに
そういうのはとんと聞かないのが不思議です

858 ：デフォルトの名無しさん：2010/09/07(火) 20:51:25

>>852
実装クラスからインタフェースを切り出して、必要な機能だけを公開するのは、
APIを提供する側から見れば、
あるいは、あるインタフェースとしてAPIから提供されているオブジェクトが、
実際にはより多くの機能を持っている実装クラスであることを知っている
ユーザ側から見れば、「（本来あった）機能の制限」と見ることもできるでしょ。

別に>>843で言ってることも間違ってるわけじゃない。同じことを別の側面から見てるだけ。

859 ：デフォルトの名無しさん：2010/09/07(火) 20:56:20

　　　　　　　　　　　　　　　　　　　 ..',||i　}i |　;,〃,,　　　　
　　　　　　　　　　　　　　　　　　　 .}.||||　| ! l-'~、ミ　　　
　　　　　　　　　　　　　　　　　　. ／　　　　　　　　　＼
　　　　　　　　　　　　　　　　　　/　　　　　　　Z-666　.|
　　　　　　　　　　　　　　　　 ../　　　　　　　　　　　　　|　　　　　　　　、__人_从_人__/し、_人＿入
　　　　　　　　　　　　　　　　　|　　 .)　 (　　　　　　　 .|　　　　　　　　、_）
　　　　　　　　　　　　　　　　　.|.-=・‐.　 ‐=・=-　　　/⌒i 　　　　　　　　_）　日本人は消毒だ～っ！！
　　　　　　　　　　　　　　　　　.| 'ー .ノ　　'ー-‐'　　　　）.| 　　　　　　　、_）
　　　　　　　　　　　　　　　　　|　　ノ(、_,、_)＼　　　　　ノ　　　　　　　　 '´⌒V＾'^Y⌒V^V⌒W^Y⌒
　　　　　　　　　　　　　　　　　|.　　＿＿_ 　＼　　　　|_
　　　　　　　　　　　　　　　　　.|　　くェェュュゝ　　　　　/|:＿
　　　　　　　　　　　　　　　　　ヽ　　ー--‐ 　　　／/::=三＝-;;;;;;;;;'' :::::::::::

860 ：デフォルトの名無しさん：2010/09/07(火) 21:06:32

コピペ王に、俺はなる！まで読んだ

861 ：デフォルトの名無しさん：2010/09/07(火) 21:27:31

また機能を制限とかわけわからんことを。
お前らどうでもいいことばっかし話し合ってないで、
どうして、「オブジェクト」を「指向」する必要があるのか考えろって。
オブジェクト指向ってのは、宗教の流派みたいなもんで、いろんな人がいろんな適当なことを言うのな。
（色んな人が自分流の適当なこと吹きまわることが可能となってしまう「土壌」の、
　その「土壌」そのものの、そんな土壌の原因を追求することも大事なんだが、
　話が難しいのでとりあえず置いとく）
でも、どんな流派だろうと、オブジェクト指向と言うからには、
「オブジェクト」を「指向」する、これだけは揺ぎ無いんだろ。
なんで「オブジェクト」を「指向」する必要があるんだ？

862 ：デフォルトの名無しさん：2010/09/07(火) 21:30:36

誰かおちこぼれのボクに構ってまで読んだ

863 ：デフォルトの名無しさん：2010/09/07(火) 21:37:50

>>861
別にない
よく考えるとそっからして意味不明な設計手法といわざるをえない

まあ、百歩譲って考えやすいからってのと
一番はじめはシミュレーションのためのもんだったからオブジェクト単位にうまく
動作が記述できる言語がほしかったんじゃないかと・・・

864 ：デフォルトの名無しさん：2010/09/07(火) 21:43:48

>>861
object-orientedは、過去分詞の形容詞的用法で主語を修飾するものだ。
あとは分かるな。。

865 ：864：2010/09/07(火) 21:55:59

分かってないのは俺だった。
修飾するのは名詞だろうが。。畜生…！

866 ：デフォルトの名無しさん：2010/09/07(火) 22:05:10

http://www.youtube.com/watch?v=fUsdOFlG7Rg

867 ：デフォルトの名無しさん：2010/09/07(火) 22:13:17

oriented[形]（…に）関心を向けた, （…を）志向する((toward, to ...)) family- oriented peopleマイホーム主義の人びと.

どういうこっちゃ。
object oriented　→　オブジェクトに関心を向けた、オブジェクトを指向する。
object oriented people →　オブジェクト主義の人々。

どっちにしろ、オブジェクトをどうにかこうにか発想ってことだろう。

でも、どう考えたって、プログラムで一番大事なのは、制御なのに。
制御が、関数が、データ同士の関係を定義して、それで、機能がもたらされるのに。
だからわざわざfunctionって名前になってるのによー。関数はデータ同士の関係を定義したもので、同時に機能でもあるんだよ。

俺も百歩譲って、「機能オブジェクト指向」って名前だったらまだ納得するかなー。
なんでオブジェクトをどうにかこうにかって話になるんだろう。
物事逆から考えてるよ。こんなのリバースだよ。
逆立ち人間の、ルサンチマンの、奴隷根性の、逆恨みだよ。変だよ。

868 ：デフォルトの名無しさん：2010/09/07(火) 22:18:55

定義の問題で、辞書とか一般的な英語での意味とかを調べるのは無意味だと思う

869 ：デフォルトの名無しさん：2010/09/07(火) 22:30:04

文法的には「動詞＋目的語」よりも「目的語＋動詞」の方が分かりやすいよね。日本語的に。

870 ：デフォルトの名無しさん：2010/09/07(火) 22:36:53

>一番はじめはシミュレーションのためのもんだったから

これ重要だよな。
俺らは大概別に何かをシミュレーションしたいわけじゃねーんだよ。お目当ての機能が実装したいだけなんだよ。
なんで、シミュレーションの結果が目的の機能になるように、各オブジェクトの具合を調節するような、
遠回りで無駄な設計手法を取らなきゃなんねーんだよ。
わざと仕事増やしたいのか？まーそれはあるわな。

871 ：デフォルトの名無しさん：2010/09/07(火) 22:54:25

俺が機能の制限つったのは、モノリシックなクラス作るなって意味であって
単に大規模化しても複雑なバグを生みにくくする仕組みとしてOOPが使えるということだ

872 ：デフォルトの名無しさん：2010/09/07(火) 23:00:59

>>870
オブジェクト指向の実現が必ずしもソフト開発にとっていいってわけではないよね
この初っ端のところが実はボケてるんだよね
誰もこれが結びついていそうでいないことがわかってない

873 ：デフォルトの名無しさん：2010/09/07(火) 23:25:02

相変わらずなんかマジっぽい馬鹿多いな。
とりあえずシュミレーション云々は関係ないから。

とりあえずクラスベースのオブジェクト指向の有り難味を知りたいなら、
複素数とかベクトルとか分数みたいなデータ構造とその操作を

(1) 構造体 + 関数
(2) クラス

で書いてみればいい。
逆に言えばオブジェクト指向なんて本質的にはそんな程度のもので、別に難しくもなんともない。

ここでシミュレーションがどうのとか無駄だの遠回りだとか訳のわかんないこと言ってる奴は
その程度のコードも書けないのは間違いない。

そりゃOOPが糞なんじゃなくて、お前さんの脳が糞なの悪いけど。

874 ：デフォルトの名無しさん：2010/09/07(火) 23:27:08

問題はstatic変数

875 ：デフォルトの名無しさん：2010/09/07(火) 23:28:45

いっちゃてるな

876 ：デフォルトの名無しさん：2010/09/07(火) 23:35:51

>>873
http://ja.wikipedia.org/wiki/Simula

なんかお前出だしから嘘っ八だし信用できないわ

877 ：デフォルトの名無しさん：2010/09/07(火) 23:47:07

>>876
馬鹿か。
OOPの出自がシミュレーションであろうが無かろうが、
別にOOPはシミュレーションとだけ親和性が高いわけじゃないの。
だから>>870みたいなのはナンセンス。

それとも何か、電算機の歴史は確か砲弾の弾道計算から始まってるはずだが、
「コンピュータは弾道計算にしか使えねー」とか言うのかねお前さんは。
まあむしろ言いそうな勢いだw
本物の白痴だな

878 ：デフォルトの名無しさん：2010/09/07(火) 23:48:42

>それとも何か、電算機の歴史は確か砲弾の弾道計算から始まってるはずだが、

これ都市伝説だろ

879 ：デフォルトの名無しさん：2010/09/07(火) 23:48:50

ちなみに、OOPはもともとシミュレーション用に～とかいう俗説って間違いなんだよね。
どこかにそのあたり詳しく説明してるとこが合ったんだが、ブックマークに残ってないな。

880 ：デフォルトの名無しさん：2010/09/07(火) 23:52:46

別にシミュレーション出身でもなんでもいいよ
現状OOPより依存関係の整理しやすい物がない

881 ：デフォルトの名無しさん：2010/09/07(火) 23:57:25

OOPはウィンドウシステムと相性が良かったのを
シミュレーションと勘違いしたんじゃね？

882 ：デフォルトの名無しさん：2010/09/08(水) 00:00:50

>>879
間違いじゃねーし

883 ：デフォルトの名無しさん：2010/09/08(水) 00:03:23

>>877
何が言いたいのかサッパリわからない
作った目的がシミュの実現だったのに何を言ってるのかと

884 ：デフォルトの名無しさん：2010/09/08(水) 00:04:50

否定は得意だけど整理や構築はできません

885 ：デフォルトの名無しさん：2010/09/08(水) 00:05:19

>>841=>>871ですよね？
ひとつのクラスの機能を制限するという点に注目して機能の制限と書いたのでしょうけど
機能の分割と書けば意図する所を第三者に誤解されなかったと思います。
>>841は複雑な物は単純な物に分割するという分割統治の話ですね。

>>870
その方がより大規模なソフトウェアを作れるからです。
人間は複雑過ぎる物は階層化して単純な物の組み合わせにしないと扱えません。

原理的にはgoto文プログラミングでどんなソフトウェアも作れます。
しかしコード行数が増えると処理フローが複雑になりすぎます。
構造化プログラミングならgoto文レベルの処理フローを書く必要はありません。
処理フローは階層化されて容易に理解できるようになります。
その結果、goto文プログラミングより大規模なソフトウェアを作れます。

非オブジェクト指向では複数の関数から参照するデータは関数とは独立して構築します。
しかしデータが大規模になるとデータ構造が複雑になりすぎます。
オブジェクト指向ならデータを処理と分離してデータだけでまとめる必要はありません。
オブジェクト内にデータ構造が隠蔽されて容易に操作できます。
その結果、非オブジェクト指向より大規模なソフトウェアを作れます。

886 ：デフォルトの名無しさん：2010/09/08(水) 00:07:47

>>885
本当に>>870につけたレスなのかと
お前がいってる複雑なものを単純に云々は構造化手法の話じゃないか

887 ：デフォルトの名無しさん：2010/09/08(水) 00:08:40

そういう意識付けのことをオブジェクト指向って呼ぶが
「オブジェクト指向なら」っていうのに違和感を感じる。

888 ：デフォルトの名無しさん：2010/09/08(水) 00:16:48

>>885はなんかおかしいのでスルーで

889 ：デフォルトの名無しさん：2010/09/08(水) 00:18:14

人は理解できないとき相手がおかしいと考えます

890 ：デフォルトの名無しさん：2010/09/08(水) 00:22:47

だって構造化手法をオブジェクト指向だって言ってるよ

891 ：デフォルトの名無しさん：2010/09/08(水) 00:23:46

じゃあお前はまず日本語を勉強しよう

892 ：デフォルトの名無しさん：2010/09/08(水) 00:29:49

>>886
3番目の段落は構造化プログラミングの話ですが、
4番目の段落はオブジェクト指向の話ですよ。
構造化プログラミングが以前より大規模なソフトウェア作成のためであるように
オブジェクト指向もさらに大規模なソフトウェア作成のためだという事です。

>870
>なんで、シミュレーションの結果が目的の機能になるように、各オブジェクトの具合を調節するような、
>遠回りで無駄な設計手法を取らなきゃなんねーんだよ。
これに対して機能を実現する関数だけを実装するのではなく
関数とデータを組み合わせたオブジェクトを設計する理由を説明しました。

893 ：デフォルトの名無しさん：2010/09/08(水) 00:32:21

機能分割　構造化パラダイム。オブジェクト指向に限らない
隠蔽　モジュール化のパラダイム。オブジェクト指向に限らない
動的束縛　オブジェクト指向と関係してるが、静的束縛のほうが型安全で実行速度も速い
継承　クラスベースに固有の概念。プロトタイプベース涙目。LSPが満たせないのは明らか。後はダイヤモンド継承問題
多態性クラスベースに固有の概念(とwikiにあるが本当か？)。プロトタイプベース涙目
メッセージパッシングプロトタイプベースに固有の概念。クラスベース涙目
デザパタ Lispでは23個のうち16個が空気。元々、こういう個別技術は研究対象にすらならなかった
「もの中心」といえばデータ指向

894 ：デフォルトの名無しさん：2010/09/08(水) 00:40:58

C#なんかプロトタイプベースな考え方も導入されとるし
完全にOOPってのはこれから消えてくんじゃないかな
やっぱラムダ式とか便利だしもはや必須になりつつある

895 ：デフォルトの名無しさん：2010/09/08(水) 00:43:42

プロトタイプベースがメリットとはぜんぜん思えない

896 ：デフォルトの名無しさん：2010/09/08(水) 00:44:23

>その結果、非オブジェクト指向より大規模なソフトウェアを作れます。

問題は、その「大規模なソフトウェア」とやらが、目的の機能、顧客の要求に答えられるものになったかどうか、だ。
もちろん、がんばれば、どうにかなるよ。
でもしんどくね？

オブジェクト指向っていったらアレだろ？
複数のオブジェクトがメッセージという池の中で相互作用しあってどうのこうの。
で、その相互作用の結果が目的の機能/要求を満たしてなきゃならんという遠回り。

俺はね、メッセージの池、それをね、機能って呼んでるの。
機能の池の中にオブジェクトやらデータやらが浮かんでて、
「機能がオブジェクトの性質を決める」
オブジェクトが自分自身の性質を決めるのではなく、
機能が、周りとの関係が、関数というある種のフィルタが、その物の性質を決める。
だってそうだろ、100円を100円たらしめてるのは、100円に100円の機能を持たせているのは、
100円自身ではなく、市場経済の「機能」だろ。100円単体では、それはただの金属の円盤にすぎん。
市場経済の機能が有って初めて100円は100円の意味が出る。
100円というオブジェクトを指向しても何の意味もない。

で、機能ってのは、英語でfunction、つまり関数だっていってるの。関数は何かと何かの関係を定義したもの。
オブジェクトに着眼しちゃいかん。オブジェクトを指向しちゃいかん。
大事なのは、オブジェクトとオブジェクトの間にある見えない何か。
OOな人はそれを「メッセージ」というが、それはおかしい。正しくは「機能/関係」と言うべきだ。
物事はメッセージで動いていない。機能で動いているんだ。

897 ：デフォルトの名無しさん：2010/09/08(水) 00:46:16

オブジェクト指向言語を感じるのはコンストラクタとアクセス修飾子だな

898 ：デフォルトの名無しさん：2010/09/08(水) 00:49:53

>>895 俺も今のところそう思ってる。それ系の言語のプロフェッショナルに熱く語って欲しい

899 ：デフォルトの名無しさん：2010/09/08(水) 00:56:37

だからね、俺はね、常々ね、オブジェクト指向で出来ることは、セッターとゲッター、そいうったアクセサぐらいだといっとるのよ。
それ以上のこと、オブジェクト同士のかかわりやら何やらには、めっぽう無力。
でもね、大事なのは何時でも「機能/他者との関係」なわけ。これはOOPでは解決しない。
そこに注力しなきゃならないのに、OOPに拘ってる意味はもう無くて、
それこそ、継承とか言い出したらもうドツボなんよ。

900 ：デフォルトの名無しさん：2010/09/08(水) 00:57:41

自演うぜえー

901 ：デフォルトの名無しさん：2010/09/08(水) 00:59:59

>>899
やばい、俺が考えてたこととかなり同じだ
いや、自演じゃなくてマジで

俺はセッターゲッターすらも認めないけどな

902 ：デフォルトの名無しさん：2010/09/08(水) 01:00:21

オブジェクトを生成した瞬間から正しい状態になっているというお約束はすごいと思う。

903 ：デフォルトの名無しさん：2010/09/08(水) 01:12:23

>>896
説明しているオブジェクト指向が80年代(日本では90年代半ばまで)の
古いオブジェクト指向に見えます。古いオブジェクト指向設計は確かに
現実世界で名前があるものをオブジェクト候補にする迂遠な物でした。
でも現代のオブジェクト指向設計では最初にユースケースを考えてから
それに必要なオブジェクトを割り出すので目的の実現に関係ない
オブジェクトは最初から出てきません。

ユースケース
http://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9

904 ：デフォルトの名無しさん：2010/09/08(水) 01:15:48

また馬鹿がきた

905 ：デフォルトの名無しさん：2010/09/08(水) 01:27:23

>それに必要なオブジェクトを割り出すので目的の実現に関係ない
>オブジェクトは最初から出てきません。

「目的の実現に関係ないオブジェクトが出てくる」なんて、俺一言も書いてねーよ。

906 ：デフォルトの名無しさん：2010/09/08(水) 02:27:42

>>899
オブジェクト指向にすると問題が発生するのではなく
オブジェクト指向で解決できない問題があるという話ですよね。
非オブジェクト指向でなければならない理由にはならないのでは？
実装継承がコードを理解しにくくする場合があるのは確かですが、
大変有用な情報隠蔽まで一緒に否定する必要はないでしょう。

>>905
ではオブジェクト指向設計でも非オブジェクト指向設計と同じく
必要な関数(メソッド)とデータ(フィールド)しか含まない
ソフトウェアを作成できると考えているんですね。
オブジェクト思考プログラミングの記述が遠回りだという事だけが
オブジェクト指向に否定的な理由なんですね。

あなたはグローバル変数よりローカル変数の方が理解も保守もしやすい
という事はおそらく納得しているはずです。
裸の関数とデータ構造より抽象データ型の方が理解も保守もしやすい
という事をなぜ無視するのでしょうか？

907 ：デフォルトの名無しさん：2010/09/08(水) 03:13:29

>オブジェクト指向にすると問題が発生するのではなく
>オブジェクト指向で解決できない問題があるという話ですよね。
>非オブジェクト指向でなければならない理由にはならないのでは？

オブジェクト指向で解決できない問題をなぜオブジェクト指向で解決しようとするのかい

908 ：デフォルトの名無しさん：2010/09/08(水) 06:25:42

わけの判らない抽象化でさらにわけが判らなくなるのは納得しているはずです。
サブクラス化が進んでいくと見通しが悪くなるだけなのも納得しているはずです。
結局必要なのはテンプレートだけでオブジェクト指向なんて糞の役にも立たないことをなぜ無視するのでしょうか？

909 ：デフォルトの名無しさん：2010/09/08(水) 06:34:57

わけがわからないという意味ではテンプレートはもっとひどい。

910 ：デフォルトの名無しさん：2010/09/08(水) 06:51:38

C++のバージョンアップによってOOの役立たずはとうの昔に証明されてしまってる
新しいC++は(OOも一応申し訳程度に使える)テンプレートな言語になった
OOは状況を悪化させるだけの存在として忌避されている

911 ：デフォルトの名無しさん：2010/09/08(水) 06:52:14

確かにOOPは実用的な設計ができるようになるにはかなり経験を要するし
＞わけの判らない抽象化でさらにわけが判らなくなる
なんてのはある程度誰しもが通る道ではあるよな

低レベルの抽象を集めて、より大きな低レベルの抽象を作ってはならないってのは基本だ

912 ：デフォルトの名無しさん：2010/09/08(水) 07:01:38

糞みたいな設計でも、デバッグの苦痛に耐え抜けばそれなりに動いちゃうのがOOPの印象を悪くしてるよな
「こんな辛いことしなきゃいけないなんてOOPはおかしい」と考えちゃう要因

913 ：デフォルトの名無しさん：2010/09/08(水) 07:07:10

>>907
オブジェクト指向で解決しようとしてません。
構造化プログラミングは「機能/他者との関係」という問題を解決しませんが、
それは構造化プログラミングを使わない理由にならないというのと同じ話です。

>>908
サブクラス化については確かに多段継承は見通しが悪くなると思います。
しかしオブジェクト指向なんて糞の役にも立たないには同意できません。
１個の関数からだけ見えるローカル変数と同じように
数個の関数からだけ見えるフィールドは理解も保守もしやすいです。
オブジェクト指向のアイデアにはダメな物もあるが
素晴らしい物もあるから全否定すべきでないと考えています。

914 ：デフォルトの名無しさん：2010/09/08(水) 07:09:56

>>913
だからそれ構造化手法じゃん

小分けにはするだろ？
でもわざわざオブジェクト単位にまとめることになんの意味があるの？
それだとどうしていいの？
ってのが問題であって、小分けにすること自体は議論してないだろ

915 ：デフォルトの名無しさん：2010/09/08(水) 07:09:57

おーおー言ってれば相手にされた10数年前と今とでは見方が全く違うんだけど
昔の印象しか持てない人がいるわけだ
使う言語によってはOOPでもうまくいってるように見える場合もあるし

916 ：デフォルトの名無しさん：2010/09/08(水) 07:12:19

当たり前のものになったからな

917 ：デフォルトの名無しさん：2010/09/08(水) 07:15:32

言葉だけはえらい流行したよな
実態は爆笑もんだが

918 ：デフォルトの名無しさん：2010/09/08(水) 07:18:21

OOPつっても、普通に機能単位でオブジェクト切り分けていくけど
名前に翻弄されて「これはオブジェクトだからクラスにしないと・・・」とか思ってると破綻する

919 ：デフォルトの名無しさん：2010/09/08(水) 07:35:36

一時期から登場したデザパタが混乱に拍車を掛けたのは記憶に新しい
昔からあるノウハウを無理にOOに当てはめて広めようとしたので、
わけの判らない新技術として世間に認知された
しかしおーおーにデザパタを加えても何も起きなかった

920 ：デフォルトの名無しさん：2010/09/08(水) 08:09:22

OOpが役に立たないって　N88BASICでも使ってるのか？

921 ：デフォルトの名無しさん：2010/09/08(水) 08:17:31

長いこと同じ業界にいると視野が狭くなるんだよな

922 ：デフォルトの名無しさん：2010/09/08(水) 09:29:27

>>878
ENIAC のことを指してるなら都市伝説ではないが。

923 ：デフォルトの名無しさん：2010/09/08(水) 20:22:28

オブジェクト指向の欠点
・オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。
・将来拡張するか分からないのに、作成時から拡張性を意識した作りにしないといけない。（作成時では必要のない機能を実装している）
・構造が複雑なので、理解しにくいソースになる。本来ブラックボックスとして使うべきだが仕様書の不備や
Chain of Responsibility/Compositeパターンなどオブジェクト同士の関係性が強いオブジェクト群を修正するときにソースの理解が必要になる。

924 ：デフォルトの名無しさん：2010/09/08(水) 20:42:05

>オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。
ポインタ全否定派ですか？

925 ：デフォルトの名無しさん：2010/09/08(水) 20:45:12

OOPかどうかの基準ははっきりしない。
・オブジェクト指向型言語を使ったらOOPというわけではない。
・クラスを使ったらOOPというわけではない。

だけど、人がみるとなんとなくOOPかどうか見分けがつく。
不思議だ。

926 ：デフォルトの名無しさん：2010/09/08(水) 20:51:03

>>923
タイトルを

構造化手法の欠点

にしてもなんら違和感を感じない

927 ：デフォルトの名無しさん：2010/09/08(水) 20:59:46

お前の中ではそうなんだろうな。

928 ：デフォルトの名無しさん：2010/09/08(水) 21:18:52

>>924
>ポインタ全否定派ですか？
意味が分からない。

>>926
>構造化手法の欠点
>にしてもなんら違和感を感じない
なぜ、インスタンスが構造化手法なんだ？
もしかして、インスタンスの意味が分かってない？

929 ：デフォルトの名無しさん：2010/09/08(水) 21:36:17

>>928
インスタンスがスタックに置かれると思ってんの？

930 ：デフォルトの名無しさん：2010/09/08(水) 21:51:02

インスタンスが存在するものしか使用できないのは、手続き型言語一般の問題で、OOP特有の問題じゃないって言いたいんでしょ。
たしかにそりゃそうだ。

931 ：デフォルトの名無しさん：2010/09/08(水) 21:51:56

日本は、領土はとられまくり。ガスも抜かれまくり。
国内の政治は韓国人に支配されちゃったし、
国民の金はパチンコ屋経由で朝鮮半島に抜かれまくりだし、
国民が信じる新興宗教は韓国資本だし、
国民が熱狂するアイドルは韓国人。
いや～、もはや形無しですなあ。

932 ：デフォルトの名無しさん：2010/09/08(水) 22:07:43

尖閣諸島問題で中国大使館に抗議するｵﾌ
http://yuzuru.2ch.net/test/read.cgi/offmatrix/1283926084/
1: 2010/09/08 15:08:04 21BrBr5lsd
日時は9月12日､日曜日予定
場所は中国大使館前

933 ：デフォルトの名無しさん：2010/09/08(水) 22:16:47

>>929
>インスタンスがスタックに置かれると思ってんの？
インスタンスをスタックに置くことも可能だ、お前は本当に分かってない。

>>930
>インスタンスが存在するものしか使用できないのは、手続き型言語一般の問題
お前インスタンスが何か理解出来てない。
構造化で、関数が存在するかチェックするか？関数は静的に存在する。

お前らインスタンスぐらい勉強しろ。オブジェクト指向では常識だぞ。
http://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9

934 ：デフォルトの名無しさん：2010/09/08(水) 22:26:33

しかし、関数には引数渡すわけだろ？
引数が無いと関数呼べないわな。だから、引数に渡すべきものが存在している関数しか呼べないわな。

え、引数なしの関数？
それはOOPではスタティックなクラスメソッドになるから、OOPでもインスタンスの有無関係なく呼べるわな。

お前アホだろ。OOP否定派の俺から見てもアホだ。

935 ：デフォルトの名無しさん：2010/09/08(水) 22:27:57

めんどくせー奴だな
構造化でも参照型は使うだろが

Null参照でエラー出したことないのか？

936 ：デフォルトの名無しさん：2010/09/08(水) 22:29:32

アホはほっとけ。無駄にスレが流れるだけだ。

937 ：デフォルトの名無しさん：2010/09/08(水) 22:33:48

もうすぐ堕ちるな

938 ：デフォルトの名無しさん：2010/09/08(水) 22:36:51

クラスって単に小さなプログラム単位でしか無いのに
なんでOOP目の敵にする奴がたまにいるのか謎だな

939 ：デフォルトの名無しさん：2010/09/08(水) 22:36:52

ぬるりでいいだろ

940 ：デフォルトの名無しさん：2010/09/08(水) 22:39:30

>>983
害悪でしかないから～

941 ：デフォルトの名無しさん：2010/09/08(水) 22:45:00

>>938
それはね、継承やらポリモやら言い出した奴が居るから。
OOPから継承とポリモ取ったら、ちょうどいい感じ。
ただ、それだったらCで良いやって話も。

オーバーロードとテンプレートの相性は抜群で強力だから、
継承やらポリモやらは捨て去って、そっち方面で煮詰めたほうが良いだろうな。

あれだな。
C言語 + マルチメソッド + 型推論
で、手続き型言語はFAじゃね。

ただ、関数型言語のアイデアも取り入れたいしなぁ。
誰か綺麗に纏め上げてくれんかなぁ。

942 ：デフォルトの名無しさん：2010/09/08(水) 22:51:35

>>941
マルチメソッドも型推論も多態性を実現するためのものだと思うんだが。
多態以外で有効な使い道があるなら教えて(煽りじゃなく純粋な疑問)

943 ：デフォルトの名無しさん：2010/09/08(水) 22:52:59

仮想関数は重いからダメ

944 ：デフォルトの名無しさん：2010/09/08(水) 22:54:58

C#でFAだろ

945 ：デフォルトの名無しさん：2010/09/08(水) 23:04:59

>>942
ポリモ目的なんだけど、
クラスベースのそれと違う点は、
基底クラスに共通のインターフェースを持たなくても良い。
あと、型推論はポリモ以外にも使える。テンプレートの代替と思ってもらえれば。

void func( type_a *p ){ }
void func( type_b *p ){ }
auto add( auto &op1, auto &op2 ){ return op1+op2; }
int main()
{
　　type_a a; type_b b;
　　auto *p;
　　*p = &a;
　　*p = &b;
　　func( p ); // void func( type_b * ) が呼ばれる。まぁポリモだな。
　　add( 1, 2 ); //3が返る。テンプレートの代替だわな。
　　return 0;
}

こんなノリで。

946 ：デフォルトの名無しさん：2010/09/08(水) 23:06:36

あ、ごめん訂正。

void func( type_a *p ){ }
void func( type_b *p ){ }
auto add( auto &op1, auto &op2 ){ return op1+op2; }
int main()
{
　　type_a a; type_b b;
　　auto *p;
　　p = &a;
　　p = &b;
　　func( p ); // void func( type_b * ) が呼ばれる。まぁポリモだな。
　　add( 1, 2 ); //3が返る。テンプレートの代替だわな。
　　return 0;
}

947 ：デフォルトの名無しさん：2010/09/08(水) 23:09:08

型推論があればタイプ量が減る。これは大切なこと

948 ：デフォルトの名無しさん：2010/09/08(水) 23:09:30

auto *p;
*p = &a;
*p = &b; // ここでエラーになるのが普通じゃないの

949 ：デフォルトの名無しさん：2010/09/08(水) 23:16:06

>>948
基底型無しでポリモするには、どうしても、何でもありの自動型無しポインタが必要なんだよ。
auto *p; としたとき、pはどんな型のポインタも取りえるとしないと、ポリモが絶対に出来ない。
void *p;　と違う点は、auto *p;　は、今自分自身が指してる対象の型を動的に判断できる点。
それに基づいて、マルチメソッドするのな。

やりすぎ感はあるから、やっぱポリモはいらないかもな。
型推論とオーバーロードだけでも十分強力だしな。それに静的で安全だし。
マルチメソッドは実行コストがえらいことになるしな。

950 ：デフォルトの名無しさん：2010/09/08(水) 23:27:22

定数でないならならない

951 ：デフォルトの名無しさん：2010/09/08(水) 23:35:31

タイプ量とか一番どうでもいい

952 ：デフォルトの名無しさん：2010/09/08(水) 23:40:06

c++って唯一メモリー管理可能なOOP言語だけど
なぜあんなに地雷埋めるんだろうね、。

953 ：デフォルトの名無しさん：2010/09/08(水) 23:49:51

禿だからさ

954 ：デフォルトの名無しさん：2010/09/09(木) 00:02:28

DだってObj-Cだってメモリ管理可能だぞ

955 ：デフォルトの名無しさん：2010/09/09(木) 00:07:50

Objective-Cでどうやってメモリ管理するの？

956 ：デフォルトの名無しさん：2010/09/09(木) 00:10:48

malloc

957 ：デフォルトの名無しさん：2010/09/09(木) 00:12:23

それじゃCじゃん

958 ：デフォルトの名無しさん：2010/09/09(木) 00:23:55

まあ、継承より任意の関数ぶち込めるプロトタイプベースなクラスの方がモダンだよなあ

959 ：デフォルトの名無しさん：2010/09/09(木) 00:24:19

え？

960 ：デフォルトの名無しさん：2010/09/09(木) 00:27:19

javascriptの亜種って出てこないのかな
goとかみたいな

961 ：デフォルトの名無しさん：2010/09/09(木) 00:39:41

タイプ量とかほざいてんのは間違いなく低脳ruby厨だろうな

962 ：デフォルトの名無しさん：2010/09/09(木) 01:08:29

上のポリモーフィズムの議論とかは型システムがあれば出来るわけで
型推論の有無は関係ない
templateにはメリットがあるかもしれんが、
そういうのはtemplate内でやってくれる。現行C++でも関数テンプレートは既に一部推論する
だから、基本的にはタイプ量が減るぐらいのもん

StreamBufferedReader = new StreamBufferdReader();
こんなコードを書くのはアホみたい

963 ：デフォルトの名無しさん：2010/09/09(木) 04:43:28

C++コンパイラ作ろうとすればはっきり判ると思うけど、
式単位では局所的な型推論は入ってるんだよね

964 ：デフォルトの名無しさん：2010/09/09(木) 12:23:31

>>961
C#のvarとか便利だよ。
右辺でわかってることを左辺に書くのとかめんどいよ。

965 ：デフォルトの名無しさん：2010/09/09(木) 14:31:05

構造化プログラミング
オブジェクト指向

次はなんだろう

966 ：デフォルトの名無しさん：2010/09/09(木) 14:45:30

オレオレ至高プログラミングだな。

967 ：デフォルトの名無しさん：2010/09/09(木) 19:27:19

アスベスト志向

968 ：デフォルトの名無しさん：2010/09/09(木) 19:28:30

アスベスト志向

969 ：デフォルトの名無しさん：2010/09/09(木) 21:13:05

アスベスト施工

970 ：デフォルトの名無しさん：2010/09/09(木) 21:35:31

>>960
Rhinoがあるじゃないか

971 ：デフォルトの名無しさん：2010/09/09(木) 22:30:15

次は0xだろ

972 ：デフォルトの名無しさん：2010/09/09(木) 23:10:53

>>934
>お前アホだろ。OOP否定派の俺から見てもアホだ。
だろうな、お前はまったくオブジェクト指向が理解出来ていない。

>>935
>構造化でも参照型は使うだろが
>Null参照でエラー出したことないのか？
インスタンスと言っているだろう、本当にオブジェクト指向が分かってないな。
お前の構造化は全て参照型で関数呼び出すのか？
お前は、構造化も分かってないだろう。

973 ：デフォルトの名無しさん：2010/09/09(木) 23:13:05

OO知らんアホに熱くなるなよｗｗｗ

974 ：デフォルトの名無しさん：2010/09/09(木) 23:15:10

いや、構造化も怪しいぞｗ
とにかく、バカには近寄るなｗｗｗ

975 ：デフォルトの名無しさん：2010/09/09(木) 23:23:58

まるでわかってるような口ぶり

976 ：デフォルトの名無しさん：2010/09/10(金) 01:01:28

>>972
通りすがりだけど
お前のOOPは全てクラス型でメソッド呼び出すのか？
お前は、自分が何を言ってるかも分かってないだろう。

OOPではプリミティブ型の引数を取るメソッドは禁止とか初耳。
JAVA超涙目

977 ：デフォルトの名無しさん：2010/09/10(金) 01:21:03

>>972
>>935は>>923の
>オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。

に対する反論だよ

あとインスタンス＝関数だと思ってない？
一連のレス読んでるとそんな感じがするんだけど

978 ：デフォルトの名無しさん：2010/09/10(金) 01:53:29

昔の人はオブジェクト指向なんてなくてもちゃんとしたプログラムを作れた

オブジェクト指向を知らなかった優秀な人が作ったプログラム>>>>>>>>>>>>>>>>オブジェクト指向をちゃんと勉強したことのある無能が作ったプログラム

オブジェクト指向はあると便利だがなかったからといって困るものじゃない

979 ：デフォルトの名無しさん：2010/09/10(金) 05:45:53

>>987
構造化手法以前もちゃんとしたプログラムは作れました
以下略

980 ：デフォルトの名無しさん：2010/09/10(金) 06:37:44

電鋸あるんだから使えよ

981 ：デフォルトの名無しさん：2010/09/10(金) 06:39:18

BTTB
すなわちBASICの時代に戻るのだ・・・

982 ：デフォルトの名無しさん：2010/09/10(金) 06:40:22

>>976
>お前のOOPは全てクラス型でメソッド呼び出すのか？
だから、「オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。」
と書いているだろう。関数と違ってオブジェクトを使う場合は存在チェックが必要だと書いている。

>>977
>あとインスタンス＝関数だと思ってない？
思ってないが、何を読めばそう思えるんだ？
関数は静的造られるし、オブジェクトは動的に造られる。
このオブジェクトの実体をインスタンスと言うんだ。

この「オブジェクトを使うにはインスタンスの存在確認が必要」は
マーチンやケントなど、オブジェクト指向の巨匠たちも頭を痛めた問題だ。
こんな一般的な欠点も理解出来ないとは。

983 ：デフォルトの名無しさん：2010/09/10(金) 06:41:15

プログラマが言語に合わせるのではなく
言語がプログラマに合わせるのだ

984 ：デフォルトの名無しさん：2010/09/10(金) 06:49:31

>>982
ポインタと動的確保について調べてから書き込むように
それでもわかんないんなら
どっかのC++スレで>>923と同じ主張をしてきなさい
みんなが親切におしえてくれるから

985 ：デフォルトの名無しさん：2010/09/10(金) 07:05:44

つーか、ポリモが特に必要ないのに継承するからコードがぐちゃぐちゃになるんだろ
設計できないのをOOPのせいにしてはいけないよ

986 ：デフォルトの名無しさん：2010/09/10(金) 07:56:39

>>982
> 関数は静的造られるし、オブジェクトは動的に造られる。

first-class objectとしての関数は無視ですかそうですか。

あと、君って相変わらず
　機能 = 手続き型の関数（≒サブルーチン） = 数学の関数（≒純粋関数型の関数）
だと思ってない？

987 ：デフォルトの名無しさん：2010/09/10(金) 08:07:27

> この「オブジェクトを使うにはインスタンスの存在確認が必要」は

Option型とパターンマッチング。

そもそも、データの中身やオブジェクトの状態が正しいかどうかをチェックするのは、
プログラミングの基本的な作法だ。君はそういうのを軽視する人なのかもしれないが。

988 ：デフォルトの名無しさん：2010/09/10(金) 08:18:01

>>982
言語にもよるが、インスタンスに依存しないなら、
staticでも付けとけよ。

989 ：デフォルトの名無しさん：2010/09/10(金) 10:05:13

人が火を使うとき、わりと慎重になる。
原子力を使うとき、もっと慎重になる。

OOPはもっと慎重に扱うべきだったのかもしれない。
ホビーユーザが犬猫動物で覚えて使って火傷、
中級ユーザが中規模プロジェクトに使って焼死。

990 ：デフォルトの名無しさん：2010/09/10(金) 10:35:18

クラスや継承がなかったときはどうしてたんだろう

ほとんど同じだけど、微妙に違う構造体
みたいなのがいくつかあったら継承便利だと思うんだが。

991 ：デフォルトの名無しさん：2010/09/10(金) 10:41:39

>>990

struct base {
int a, b, c;
char d, e, f;
long g, h, i;
};

struct d1 {
struct base base;
double dvalue;
};

struct d2 {
struct base base;
float fvalue;
};

struct d1;
struct d2;
struct base *p = (struct base *)&d1;
struct base *q = (struct base *)&d2;

992 ：デフォルトの名無しさん：2010/09/10(金) 10:48:34

unionも便利だったけど
逆にclass使うとunion使わなくなるんだよな
なんでだろ

993 ：デフォルトの名無しさん：2010/09/10(金) 10:59:13

そりゃunionよりもクラスの方がswitch文不要で便利だからだろう

994 ：デフォルトの名無しさん：2010/09/10(金) 11:37:43

それは継承とポリモフィズムのことか？
テンプレ/GENERICSじゃなくて？

995 ：デフォルトの名無しさん：2010/09/10(金) 12:20:03

だから！遅すぎたと言っているんだ！

996 ：デフォルトの名無しさん：2010/09/10(金) 12:21:46

押尾学指向

997 ：デフォルトの名無しさん：2010/09/10(金) 12:46:45

http://yamagata-np.jp/news/201009/09/kj_2010090900546.php
http://www.yomiuri.co.jp/national/news/20100910-OYT1T00031.htm