1001コメント366KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2010/04/14(水) 01:14:08

オォオォ言ってる奴等がアホな抱けちゃうの?

0002デフォルトの名無しさん

2010/04/14(水) 01:15:41

猫に小判
豚に真珠
京大霊長類研究所

0003デフォルトの名無しさん

2010/04/14(水) 01:18:01

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

0004デフォルトの名無しさん

2010/04/14(水) 07:09:52

VIPでやれ

0005デフォルトの名無しさん

2010/04/14(水) 08:58:40

OOp <でっていうwww

0006デフォルトの名無しさん

2010/04/14(水) 17:58:48

実際アホなんだろうと思うよ。
むしろアンチOOPの方がOOPを使いこなせたりしてな。
暗部を知っててそこを避けるから。

0007デフォルトの名無しさん

2010/04/14(水) 20:56:38

>むしろアンチOOPの方がOOPを使いこなせたりしてな。
>暗部を知っててそこを避けるから。
と、アイちゃんが言いました。賢いねアイちゃんは
次は何を言うのかなアイちゃんは？

0008デフォルトの名無しさん

2010/04/14(水) 21:52:14

>>結局OOpが役に立たないのはなぜ?
それはね、元から役に立たないからだよ、ぼうや
あんな理論もクソもない思いつきが21世紀で通用すると思うな

0009デフォルトの名無しさん

2010/04/14(水) 23:39:12

>>1が役立たずだから。

0010デフォルトの名無しさん

2010/04/15(木) 23:10:11

役立たないわけでもないが
空間押し込めたのはいいんでない。

0011デフォルトの名無しさん

2010/04/16(金) 00:34:46

でも構造体は使えるんだろ

0012デフォルトの名無しさん

2010/04/16(金) 00:38:58

自称ソフト屋が数式を理解できないからにきまってんじゃんw

0013デフォルトの名無しさん

2010/04/17(土) 01:33:04

>>1
>オォオォ言ってる奴等がアホな抱けちゃうの?
気になっていたんだが、オォオォじゃなくウーウーだろう。

0014デフォルトの名無しさん

2010/04/17(土) 15:32:35

関数をどのオブジェクトに入れるか悩むくらいなら関数のままでいい

0015デフォルトの名無しさん

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なんぞに見られる、単体の型のみに結びついたポリモはもとよりウソ物。
相手にする必要なし。

0016デフォルトの名無しさん

2010/04/17(土) 18:08:58

ダブルディスパッチというのはよく聞くけど、
トリプル以上のディスパッチは聞いた記憶がないな…

0017デフォルトの名無しさん

2010/04/17(土) 21:02:25

今日も元気だな。そんなにOOが広まると困るのか。

0018デフォルトの名無しさん

2010/04/17(土) 22:36:09

困るつーよりなんでもかんでも無理やりOOってのが問題だな
必要なとこだけでいい

0019デフォルトの名無しさん

2010/04/17(土) 22:39:42

そもそもOOって「無理やり」「使う」ものなのか？

0020デフォルトの名無しさん

2010/04/17(土) 22:45:04

無理やり使わされる、だな。

0021デフォルトの名無しさん

2010/04/17(土) 23:19:47

俺はオブジェクト指向をやめ、構造体＋関数でプログラムを作るようになってから、悩むことが減ったよ

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

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

0022デフォルトの名無しさん

2010/04/17(土) 23:20:02

意味が分からん。

0023デフォルトの名無しさん

2010/04/17(土) 23:25:19

>>21
悩まなくて済むじゃなくて、何も考えてないの間違いじゃなくて？

0024デフォルトの名無しさん

2010/04/18(日) 00:04:34

>>15
つまりCLOSかその派生をやれってことですね

0025デフォルトの名無しさん

2010/04/18(日) 01:04:59

>>23
わざと複雑に考える必要は無いんだよ。
プログラムの構造を素直に表現できればそれでよい。

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

0026デフォルトの名無しさん

2010/04/18(日) 01:16:31

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

0027デフォルトの名無しさん

2010/04/18(日) 02:06:24

アイちゃんはそんなに難しいことを考えなくてもいいんだよ＾＾

0028デフォルトの名無しさん

2010/04/18(日) 08:21:10

>>25
もともと、Java, C++ はCにOOを導入した似非OO言語なのに、それを中途半端と指摘するのは無意味

0029デフォルトの名無しさん

2010/04/18(日) 10:45:13

>>26
ポリモの例としてふさわしくない例を出されてもな。
そこは別に関数でいいんだよ。

0030デフォルトの名無しさん

2010/04/18(日) 11:05:40

>>26
仮想関数テーブル
中身を知らず、使ったことしかないヤツだな。

0031デフォルトの名無しさん

2010/04/18(日) 11:53:47

そのvtableがクラスごとに設置されてるのがクソの元凶なんだ。
そこで終わってる。なんでクラスやオブジェクトにそんなものぶら下げるんだ。

0032デフォルトの名無しさん

2010/04/18(日) 11:59:56

com

0033デフォルトの名無しさん

2010/04/18(日) 12:01:59

>>31
その方が、人間が管理しやすいから。

0034デフォルトの名無しさん

2010/04/18(日) 12:05:19

ちげーよ。実行時のオーバーヘッドを少なくする為だよ、馬鹿やろう。

0035デフォルトの名無しさん

2010/04/18(日) 12:05:35

>>31
エセOOだけども、速度が速い。

0036デフォルトの名無しさん

2010/04/18(日) 12:10:54

>>34
いや、それだと「グローバルに置いて実行時に静的に束縛しろ（ｷﾘｯ」とか言いそうだったから。

0037デフォルトの名無しさん

2010/04/18(日) 12:11:39

実行時→コンパイル時

0038デフォルトの名無しさん

2010/04/18(日) 12:13:11

>>36
そんなこと言うやつは、OOPしたことない。

0039デフォルトの名無しさん

2010/04/18(日) 12:14:33

>>35
コンパイラががんばれば良いと思う。
関数呼び出しの文法は func( object1, object2, ... ); で統一しといて、

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

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

0040デフォルトの名無しさん

2010/04/18(日) 12:18:09

>>38
ほら。 >>39

0041デフォルトの名無しさん

2010/04/18(日) 12:32:09

それはお前の日本語力の問題だろ。

0042デフォルトの名無しさん

2010/04/18(日) 12:34:27

Python の self っていいよね

0043デフォルトの名無しさん

2010/04/18(日) 18:19:57

前置記法でないと発狂する人がいるスレがあると聞いて。

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

0044デフォルトの名無しさん

2010/04/18(日) 19:00:33

>>42
OOの実装むき出し

0045デフォルトの名無しさん

2010/04/18(日) 19:05:12

後置記法でもいいよ。
( obj1, obj2 ).func;
でも、引数が常に二つと決まっているわけでもないのに中置記法はねぇだろ。
obj1.method( obj2, obj3 );
なんだいこれ。
なんで関数の引数が左右に分かれて記述されてんだよ。

0046デフォルトの名無しさん

2010/04/18(日) 19:19:32

LISP風に書くと、
( 1 + 2 3 )
こんな文法は変だろ。
( + 1 2 3 )
こうか
( 1 2 3 + )
こうだろ。

0047デフォルトの名無しさん

2010/04/18(日) 21:06:34

だからそこは素直に関数にすればいいだろ

0048デフォルトの名無しさん

2010/04/18(日) 21:11:33

>>45-46
一度、代数学の証明過程とか勉強してみるといいと思うよ。
(+ 1 (+ 2 3))
あれ、こっちだっけ
(+ (+ 1 2) 3)

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

0049デフォルトの名無しさん

2010/04/18(日) 21:18:26

何にせよ、「俺の直感に反するから禁止（ｷﾘｯ」じゃ議論にならんよ。

0050デフォルトの名無しさん

2010/04/18(日) 21:22:55

Pythonに毒されて、OOPを理解できなくなってるな。

0051デフォルトの名無しさん

2010/04/18(日) 21:23:49

つれますか

0052デフォルトの名無しさん

2010/04/18(日) 21:50:11

>>51
お前か？

0053デフォルトの名無しさん

2010/04/18(日) 22:05:08

まぁ、釣れてるよな、スレ的にはw

0054デフォルトの名無しさん

2010/04/18(日) 22:47:33

みんなが考えるオブジェクトとは
1. 構造体＋操作関数である
2. 責務である
3. アクターである
4. 抽象概念である
のどれ？

0055デフォルトの名無しさん

2010/04/18(日) 23:35:49

>>48
だから、中置記法だと引数が二つしか取れねーだろーがよ、馬鹿かよ。

0056デフォルトの名無しさん

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 )はアホなんだ。

0057デフォルトの名無しさん

2010/04/18(日) 23:52:42

>>55
いいから>>48の式を中置記法に直してみるんだ。
そもそも、(+ 1 2 3)は(+ 1 (+ 2 3))の糖衣構文なわけだがね（結合則が逆かも）。

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

0058デフォルトの名無しさん

2010/04/19(月) 00:01:49

まだ分からない奴が居るな。
C言語の標準関数
char *fgets(char *s, int n, FILE *fp);
を中値記法で書いてみろ。

0059デフォルトの名無しさん

2010/04/19(月) 00:04:58

>>58
まず、その問題系の演算規則を定義してください。

0060デフォルトの名無しさん

2010/04/19(月) 00:07:42

元から関数呼び出しの話をしてるんだ。

0061デフォルトの名無しさん

2010/04/19(月) 00:12:54

まさか、意味も分かってないのに前置記法とか言ってたの？

0062デフォルトの名無しさん

2010/04/19(月) 00:18:43

だったら、演算規則を定義してやるよ。
fgetsはsもnもfpも同時に使う。結合の順序なし。
早く中値記法で書いてください。

0063デフォルトの名無しさん

2010/04/19(月) 00:29:19

例えば、sとnとfpの加算規則がどうやって定義されてるのか大変興味があるな。

0064デフォルトの名無しさん

2010/04/19(月) 00:32:09

一応、最大限にエスパーを発揮して「fp.fgets(n).copyTo(s)」とは書いておこう。
これに突っ込まれても困るけどな。
そもそも>>58が、どんな前提条件において何を想定してるのかが分からないわけで。

0065デフォルトの名無しさん

2010/04/19(月) 00:44:32

>>63
副作用が出るわけだから無意味だわな。
それから、関数呼び出しを中置記法ですることについて今話していることぐらいは分かってるよな。

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

0066デフォルトの名無しさん

2010/04/19(月) 00:47:30

中置記法だと、3つ以上のオペランドを扱えない。
がんばって2つのオペランドになるように分解しても、
こんどはオペランドを同時に扱えない。
関数呼び出しには不適切ということ。

0067デフォルトの名無しさん

2010/04/19(月) 07:52:25

1 + 2 は、int.Add(1, 2) あるいは、1.Add(2)

0068デフォルトの名無しさん

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

0069デフォルトの名無しさん

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) で済むのでシンプルですし
他の関数からの再利用も簡単です。

0070デフォルトの名無しさん

2010/04/19(月) 13:32:27

s = fp.fgets(n)
だろう常考

0071デフォルトの名無しさん

2010/04/19(月) 14:42:25

最悪でもcopyFrom()というネーミングは無いわー

0072デフォルトの名無しさん

2010/04/19(月) 16:40:40

例えば
x1, x2,... -> (x1, x2, ...)
のような演算を考えると、単純に2項演算に分割できないよね

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

0073デフォルトの名無しさん

2010/04/19(月) 18:31:45

それで、それによって具体的にどういう弊害があるの？
あと、仮に弊害があるとして、それはどの程度のインパクトなの？

0074デフォルトの名無しさん

2010/04/19(月) 18:32:39

>>73
弊害って、見てわかんないの？
フラットなリストと入れ子のリストは別もんでしょ

0075デフォルトの名無しさん

2010/04/19(月) 18:43:44

そもそも>>72で何を言わんとしてるのか全く分からないから適当に言うけどさ、
LISPは見たことがないの？

0076デフォルトの名無しさん

2010/04/19(月) 18:47:57

>>75
ああなるほど
Lispのlist関数だと思えば、consで実現できる

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

0077デフォルトの名無しさん

2010/04/19(月) 18:55:59

zipやzipWithは>>72とは違うのだが

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

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

0078デフォルトの名無しさん

2010/04/19(月) 19:50:22

ふむ、その場合はそれでいいんじゃない。

で？

0079デフォルトの名無しさん

2010/04/19(月) 19:52:31

いや、そんだけだけど

0080デフォルトの名無しさん

2010/04/19(月) 19:54:47

まあそれだけだとあんまりなので

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

0081デフォルトの名無しさん

2010/04/19(月) 19:57:46

誰も、全て二項演算で表現することがOO的であることの必須条件だとは言ってないしなぁ。

0082デフォルトの名無しさん

2010/04/19(月) 19:59:35

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

0083デフォルトの名無しさん

2010/04/19(月) 20:07:02

ダブル／マルチディスパッチの例として、例えばcoercionをサポートした
演算を考える
intやdoubleの加算のようなものだ

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

0084デフォルトの名無しさん

2010/04/19(月) 20:13:56

俺が言いたかったのは、多くの場合において表現能力は同等なんだから、
「N項演算を表現できないOOは破綻している！」とか言われても意味が分からん、という話。

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

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

0085デフォルトの名無しさん

2010/04/19(月) 20:14:41

>>84
俺のレスが読めないの？
「全面的に棄却しろ」とは一言も言っていないんだが
>>80読めよ

0086デフォルトの名無しさん

2010/04/19(月) 20:16:39

>>83
だから、そこで言ってる「OOスタイル」って何のこと？ちゃんと定義して。

0087デフォルトの名無しさん

2010/04/19(月) 20:17:40

>>86
ああ、あんまり厳密な議論ではないけど
1.add(2.0)
みたいなものだと思ってくれて構わない
どっちかのオペランドをレシーバにする

0088デフォルトの名無しさん

2010/04/19(月) 20:20:24

>>85
俺は、そういうことを言ってた奴向けに反論を書いてたんだよ。
適切な記述を実現できるなら、マルチパラダイムが悪いとは全く思わない。

0089デフォルトの名無しさん

2010/04/19(月) 20:21:27

>>88
なるほど、なら俺らは別にケンカする必要は無いね

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

0090デフォルトの名無しさん

2010/04/19(月) 20:27:27

>>87
>>84でも書いたが、レシーバを特定しない形で記述するのが自然ならそうすればいいと思うよ。
Singletonパターンにしても、「推奨されない」けどパターンの一つなわけだしね。

>>89
同意感謝。

0091デフォルトの名無しさん

2010/04/19(月) 20:36:39

んー、ちょっとカリカリしすぎてたな、すまん。

0092デフォルトの名無しさん

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 ...　のほうが良いでしょ。

0093デフォルトの名無しさん

2010/04/19(月) 21:55:58

>>92
お前はまず人の話をちゃんと聞くところから始めろ。

0094デフォルトの名無しさん

2010/04/19(月) 22:12:13

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

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

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

0095デフォルトの名無しさん

2010/04/19(月) 22:21:24

1+2 と 1.Add(2) と int.Add(1,2) は、等価ではないぞ。

0096デフォルトの名無しさん

2010/04/19(月) 22:35:31

たとえば遠い将来、JavaやC++が多重ディスパッチを実装したとして、
object1.method( object2, object3 );
という文法を維持したまま、どう拡張しえるんだ？

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

0097デフォルトの名無しさん

2010/04/19(月) 22:38:47

>>96
OO何もわかっていないな。

0098デフォルトの名無しさん

2010/04/19(月) 23:01:42

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

0099デフォルトの名無しさん

2010/04/19(月) 23:07:33

何度も言われてるように、ほとんどのOOPLはOOP以外のパラダイムも使えるんだってば。
適材適所で使えば良いだけだろ。

0100デフォルトの名無しさん

2010/04/19(月) 23:23:36

そして、C++はなんでわざわざ関数呼び出しの文法をCから変えたんだろうな。
この辺は頭悪かったな。あえて変える必要は無かったわな。
せっかくオーバーロードはCのスタイルを維持したのにな。

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

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

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

0101デフォルトの名無しさん

2010/04/19(月) 23:35:00

func( obj1, obj2 ) //←ポリモ機能(動的オーバーロード)
{
　　obj1.set_value(0); //←カプセル化機能
}

あーすっきりした。

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

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

0102デフォルトの名無しさん

2010/04/20(火) 00:03:31

今までだと、ポリモとカプセル化の構文が同じで、何の目的なのか曖昧なところがあった。
しかも、ポリモと言ったとき、カプセル化の意も含んでる場合もあるし、逆もまたある。
そういった状況だから、オブジェクト指向という抽象的な言葉で曖昧に表現してきたわけだ。
オブジェクトの振る舞いを定義して～とかの変な話にもなった。

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

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

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

0103デフォルトの名無しさん

2010/04/20(火) 01:07:36

第一引数の話って、それなんてMLのモジュール？

0104デフォルトの名無しさん

2010/04/20(火) 01:14:28

>>103
モジュールより型クラスだろjk
オーバーロードなんだから

010593

2010/04/20(火) 07:59:55

>>102
オーケー、オーケー。
そこまで言うなら、もう、新しくそういう言語処理系を作ってコンセプトを実証してくれよ。
名前は"No More Object"でNoMO言語とかでどうだ？

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

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

0106デフォルトの名無しさん

2010/04/20(火) 08:08:35

>>105
>102の話はHaskellの型クラスの話だと思われ
有用性は既に実証されている

0107デフォルトの名無しさん

2010/04/20(火) 08:09:59

>>106
解説して。

0108デフォルトの名無しさん

2010/04/20(火) 08:15:22

あと、その型クラスというコンセプトが「（OOが適用可能な）あらゆる場面で」OOより有用であることの証明も。
ある局面において有用、というのはもちろんそうだろうけど、アンチOO君が言ってるのはそういうことじゃないしな。

0109デフォルトの名無しさん

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

0110デフォルトの名無しさん

2010/04/20(火) 18:48:14

例えば、電子レンジで卵を爆裂させて、

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

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

0111デフォルトの名無しさん

2010/04/20(火) 19:06:12

Haskellの流行に踊らされるな。責務ベースのオブジェクトを使ったプログラム作成が最も自然な方法なのだ。

0112デフォルトの名無しさん

2010/04/20(火) 19:56:23

「電子レンジで卵を調理する奴が悪い」。それだけの話。
電子レンジで卵が調理できないことと、
電子レンジというコンセプトそのものの是非は何の関係もない。

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

0113デフォルトの名無しさん

2010/04/20(火) 20:48:43

OOPって、プログラムを単純化する手法であって、複雑化する手法ではないのだが...

0114デフォルトの名無しさん

2010/04/20(火) 21:01:20

多重ディスパッチとかマルチメソッドという既存の言葉があるのになんで動的オーバーロードなんて自分用語使ってるんだろう

0115デフォルトの名無しさん

2010/04/20(火) 21:07:35

MATLABのメソッド呼び出しは
method(obj1, arguments... )
の形式だな
最近
obj1.method(arguments ...)
の書き方もできるようになったみたいだけど

0116デフォルトの名無しさん

2010/04/20(火) 21:47:57

>>110
電磁波っていうか遠赤外線は大事
結局電磁波だけど

0117デフォルトの名無しさん

2010/04/20(火) 23:32:49

オーバーロードを、オブジェクト指向の多態性だと言っている奴は馬鹿なの？
どんな勉強したら、そんなアホな考えになるんだ？

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

0118デフォルトの名無しさん

2010/04/20(火) 23:42:53

オブジェクト指向の話ってすぐに「言葉の意味」の議論に落ちて、肝心の話が進展しないよね
いつもそう
まぁ、所詮定義も糞もない文系脳の生み出した経験論だからしょうがないか

0119デフォルトの名無しさん

2010/04/20(火) 23:50:50

お前みたいに論理的に話せない奴が理系代表みたいに思われるのは心外だからやめてくれ。

0120デフォルトの名無しさん

2010/04/21(水) 01:27:39

OOPの定義は複数あるんじゃない？

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

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

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

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

0121デフォルトの名無しさん

2010/04/21(水) 08:16:48

>>120
http://d.hatena.ne.jp/sumim/20040525/p1
http://d.hatena.ne.jp/sumim/20080415/p1

0122デフォルトの名無しさん

2010/04/21(水) 08:36:42

カプセル化してメッセージ送って動作すると聞いて
それぞれのインスタンスのメソッドの中のループが
全部独立して動作すると思ってた漏れが通りますよ

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

0123デフォルトの名無しさん

2010/04/21(水) 08:39:13

>>121

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

0124デフォルトの名無しさん

2010/04/21(水) 09:37:13

>>122
それなんてErlang？

0125デフォルトの名無しさん

2010/04/21(水) 09:41:06

>>123
自分がどこまでやるか？
どこから別のオブジェクトに任せるか？
の切り分けが難しいです

0126デフォルトの名無しさん

2010/04/21(水) 10:24:48

>>122
それアクターモデルとかπ計算とかだよね
でも「メッセージパッシング」といわれて、そういうものを想定するのは
結構自然な発想のような気はする

0127デフォルトの名無しさん

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名を省略することができることがほとんどだが

0128デフォルトの名無しさん

2010/04/21(水) 12:18:11

>>127
ううん。なるほどねぇ。と考えると、現状がやっぱり最適なのかね。
obj.method(arg)の形がキモイっていうのはちょっとだけ思ったけど、代替案とかないかなぁ。

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

0129デフォルトの名無しさん

2010/04/21(水) 12:51:18

>>128
それなんてFORTH？

0130デフォルトの名無しさん

2010/04/21(水) 13:43:54

ここよりはマトモな会話になっててヨカタ
http://pc12.2ch.net/test/read.cgi/tech/1271086841/

0131デフォルトの名無しさん

2010/04/21(水) 14:06:12

>>128
F#のパイプライン演算子とかそれに近いかもね

0132デフォルトの名無しさん

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) だから

0133デフォルトの名無しさん

2010/04/21(水) 14:52:21

>>112
やり方が悪いから爆発させているのであって、だからと言って電子レンジで卵を調理できないと
結論付けるのはいかがなものか。

0134デフォルトの名無しさん

2010/04/21(水) 15:29:16

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

0135デフォルトの名無しさん

2010/04/21(水) 19:06:29

>>133-134
「素人にはおすすめできない」くらいでどうだ。

0136デフォルトの名無しさん

2010/04/21(水) 19:40:30

>>135
いいね。

0137デフォルトの名無しさん

2010/04/21(水) 20:58:25

>>127
>func(obj, arg)
>だと、名前を絞り込みようがないし
えっ
funcという名前と引数の型と戻り値の型で判定すればいいんじゃね？

0138デフォルトの名無しさん

2010/04/21(水) 21:06:25

あー
いつもの人だけど、
C++に動的オーバーロード(マルチメソッド)付けて、
かわりに、メソッドを全て非virtualにすれば、結構きれいなんじゃないかな。

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

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

0139デフォルトの名無しさん

2010/04/21(水) 21:12:46

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

0140デフォルトの名無しさん

2010/04/21(水) 21:35:47

同じような機能を持った型があってポリモしたい。
でも、型の提供元が違ってたら、当然基底型も違うだろうし、
そうなるとポリモできない。
仕方ないから、ポリモするためだけのアダプタ型を作ったりする。(むなしいね)

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

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

0141デフォルトの名無しさん

2010/04/21(水) 21:54:45

>>123
元々色々な出自があったにせよ、少なくとも今は、

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

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

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

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

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

0142デフォルトの名無しさん

2010/04/21(水) 22:00:25

風呂釜でゆで卵を数個だけゆでるような仰々しさを感じる
もっとも、最終目標は何千個ものゆで卵だろうから風呂釜より大きな鍋が必要になるかもしれない
とりあえず新しい理論の下では誰がその恩恵を受けることになるのだろう

0143デフォルトの名無しさん

2010/04/21(水) 22:03:12

昔ながらのCスタイルでかつ、C++やJavaよりも強力なポリモ。
構造体内のデータの整合性を守るためのアクセサも完備。(アトミック機能となずけたい)
多くの人は満足すると思うがなぁ。

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

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

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

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

0144デフォルトの名無しさん

2010/04/21(水) 22:09:10

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

0145デフォルトの名無しさん

2010/04/21(水) 22:14:26

仮にインターフェースを整えてポリモできるようにするのが型の責任だったとして、
果たしてその責任は取れるんですかね。
同じような機能の型なのに、インターフェースが違う、基底型が違う、こんなのザラ。
取れもしない責任を押し付けても無意味なんだぜ？
型は自フィールドの整合性を取る、それが精一杯の責任範囲。
だろ？

0146デフォルトの名無しさん

2010/04/21(水) 22:15:09

>>142
君の言うとおり、真価を発揮するのはまさに何千個ものゆで卵を相手にする時。
（ゆで卵数個でもある程度の恩恵は受けられるけどね。人間はそんなに優秀じゃない）

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

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

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

0147デフォルトの名無しさん

2010/04/21(水) 22:20:10

>>144-145
ダックタイピングしたいの？

0148デフォルトの名無しさん

2010/04/21(水) 22:34:57

>>147
少なくともメソッド名が同じじゃなきゃタッグタイピングは出来ない。
同じ機能は同じメソッドでなきゃならないなんて制約は、まず通用しないだろうね。
そういうのをやりたくないんだよね。どうせ出来ないから。

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

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

0149デフォルトの名無しさん

2010/04/21(水) 22:38:07

>>145
> 型は自フィールドの整合性を取る、それが精一杯の責任範囲。
> だろ？

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

0150デフォルトの名無しさん

2010/04/21(水) 22:43:27

俺の問題ではない。
多様なライブラリを使うから、ライブラリ間でインターフェースが整わない。
整ってない現状がすでにある。
インターフェースを整える責任はすでに放棄されているに等しい。

0151デフォルトの名無しさん

2010/04/21(水) 22:43:46

>>148
んで、君はいったいソフトウェア開発における何の課題を解決しようとしているの？

0152デフォルトの名無しさん

2010/04/21(水) 22:45:34

>>150
> 多様なライブラリを使うから、ライブラリ間でインターフェースが整わない。

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

0153デフォルトの名無しさん

2010/04/21(水) 22:46:41

>>151
きれいに整理したい。
とりあえず、型の定義から、インターフェースを整える仕事を排除したい。
それで第一歩かな。
どうせ、整いやしないわけで。別でやったほうがいい。

0154デフォルトの名無しさん

2010/04/21(水) 22:48:23

>>152
ライブラリ使ったら「壮大」ってのは、それこそ、火打石と薪じゃねーか。
ライブラリぐらい普通に使うだろ、どう考えても。勘弁してくれ。

0155デフォルトの名無しさん

2010/04/21(水) 22:50:06

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

？？？

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

0156デフォルトの名無しさん

2010/04/21(水) 22:54:13

部長権限でやるべきことを、平社員が賄ってる現状を何とかしたいんだよ。
ポリモは呼び出し元の仕事。型の定義に含めるべきではない。

0157デフォルトの名無しさん

2010/04/21(水) 22:58:13

>>156
よく分からんが、それは、君のところの開発体制がダメダメなだけじゃ？

0158デフォルトの名無しさん

2010/04/21(水) 23:02:18

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

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

0159デフォルトの名無しさん

2010/04/21(水) 23:07:33

>>158
> 型が自分以外のことをするのは越権行為だ。物事をややこしくする。

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

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

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

0160デフォルトの名無しさん

2010/04/21(水) 23:13:25

まぁ、自分の美意識を持つことが間違っているとは言わんし、
今でもC言語オンリーで立派な成果を出しているプロジェクトは確かにある。

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

0161デフォルトの名無しさん

2010/04/21(水) 23:18:13

>インタフェースを整えるのは、自分のすべきこと、すべきでないことを明確にするため。

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

0162デフォルトの名無しさん

2010/04/21(水) 23:28:19

>>161
今更だが、「呼び出し元のポリモ」って何？意識するって具体的には？

0163デフォルトの名無しさん

2010/04/21(水) 23:30:57

>>162
C++で言えば、共通の基底クラスを持つことだ。

0164デフォルトの名無しさん

2010/04/21(水) 23:35:44

>>163
さっきのライブラリ間でインタフェース共通化とかいう話もそうだが、
共通って、どれくらいのクラス数を意識した話なんだ？
「継承で共通化で再利用で差分プログラミング！」って、最近はむしろあまり推奨されないだろ。

0165デフォルトの名無しさん

2010/04/21(水) 23:39:51

同じ継承でも、差分プログラミングとポリモは用途が全然別だろうに。
あー頭痛くなってきた。
正しいこと書けば書くほどバカしか釣れなくなってくる。
もう出涸らしだな、このスレ。今日はこの辺が引き際か。

0166デフォルトの名無しさん

2010/04/21(水) 23:42:28

君、反論できなくなると必ず勝利宣言してごまかすよね。

0167デフォルトの名無しさん

2010/04/22(木) 00:27:08

詭弁のガイドライン
13.反論できなくなると必ず勝利宣言

0168デフォルトの名無しさん

2010/04/22(木) 00:32:23

>>158
勉強したいので、もう少し説明をお願いします

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

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

0169デフォルトの名無しさん

2010/04/22(木) 01:24:29

>>168
型が操作持つ必要性とかってあるのか?
clos みたく, ある特定の操作が, 型を知ってればええんちゃうの?

0170デフォルトの名無しさん

2010/04/22(木) 08:09:28

>>168
彼は「オブジェクト＝データ型＝構造体」という図式を大前提に、
『オブジェクト指向プログラミングの各要素技術は関数と構造体のみで実現できる！』
という主張を繰り返しているだけなので、真面目に話を聞くだけ無駄だと思うよ。
そりゃ、実現自体はできるかもしれないけどな。

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

0171デフォルトの名無しさん

2010/04/22(木) 08:17:54

>>169
カプセル化はどう実現するんだ？

0172デフォルトの名無しさん

2010/04/22(木) 17:17:57

>>138
実行時に、全引数の実行時型に基づいてグローバルに関数検索することで
多態を実現するんだよな？
それは分かるしいいとして、型自体は静的型なのか動的型なのか、
どういう言語を想定してるのか、ちょっとよくわかんなかった

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

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

0173デフォルトの名無しさん

2010/04/23(金) 03:50:51

>>138
便乗質問です。
「ポリモするのは呼び出し側の都合」の意味をもう少し教えてください。
同じメソッドや関数を呼び出しても、対象や引数の型によって異なる動作をするのがポリモだと思うのですが、
呼び出し側の都合で動作を変えられるべきだということですか？

0174デフォルトの名無しさん

2010/04/23(金) 08:34:46

どうでもいいからお前らコード書けよ
道具に机上で妄想や俺ルールで文句垂れるより実例示せ

0175デフォルトの名無しさん

2010/04/23(金) 13:02:58

>>173
138じゃないが、オーバーロードはオブジェクト指向の多態性では無い。
オブジェクト指向の多態性は、呼び出し側は、どの機能が実行されるか意識する必要はない。
オブジェクト自身が、どの機能を実行するかを判断する。

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

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

0176デフォルトの名無しさん

2010/04/23(金) 21:30:27

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

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

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

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

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

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

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

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

0177デフォルトの名無しさん

2010/04/23(金) 21:48:14

OOPやるにはアクセサが一番思考の妨げになるけどな

0178デフォルトの名無しさん

2010/04/23(金) 21:49:24

適当な関数が見つからないという
一般的な静的型言語ではありえない状況がごく頻繁に起こりそうだけど
それに関してはどうすんの
実行時エラー？

0179175

2010/04/24(土) 00:51:08

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

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

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

0180デフォルトの名無しさん

2010/04/24(土) 01:27:05

>>176
> >オーバーロードはオブジェクト指向の多態性では無い。
>
> 脱OOPの為に色々策を講じてるわけだから、俺からすりゃそりゃ本望だ。

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

0181デフォルトの名無しさん

2010/04/24(土) 01:29:40

もうオブジェクト指向は捨てて関数型言語になればいいのに

0182デフォルトの名無しさん

2010/04/24(土) 01:35:39

オブジェクト指向＋関数型なScalaの時代が来るので無問題。

0183デフォルトの名無しさん

2010/04/24(土) 01:42:17

>>182
最初は注目されてたけど。どっちも中途半端。

0184デフォルトの名無しさん

2010/04/24(土) 01:43:52

別に尖ってりゃいいってもんでもないしなぁ。

0185デフォルトの名無しさん

2010/04/24(土) 01:53:28

CommonLispの出番だな

0186デフォルトの名無しさん

2010/04/24(土) 13:05:59

関数型言語にはラムダ計算という数学的な理論がベースにあるらしいのですが
オブジェクト指向にも何か理論があるのですか？

0187デフォルトの名無しさん

2010/04/24(土) 14:21:15

文系は思想を学ぶ
理系は理論を学ぶ

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

0188デフォルトの名無しさん

2010/04/24(土) 14:51:12

>>187
良いこと言う

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

0189デフォルトの名無しさん

2010/04/24(土) 14:58:21

>>187
協調性に欠けていても、出力が有用なら価値がある。
協調性があっても、出力が(ry

0190デフォルトの名無しさん

2010/04/24(土) 16:38:44

>>176
回答いただきありがとうございます。

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

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

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

0191デフォルトの名無しさん

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)) { // }

0192デフォルトの名無しさん

2010/04/24(土) 18:09:29

AOPとは違うもの？

0193デフォルトの名無しさん

2010/04/24(土) 18:24:26

> 「処理でオブジェクト間の関係を定義する」は間違い、「メッセージでオブジェクト間の関係を定義する」が正しい。
> なぜ、オブジェクト指向はメッセージと言う言葉を使うのか理解出来ない奴は、オブジェクト指向を理解していない。

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

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

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

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

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

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

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

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

0194デフォルトの名無しさん

2010/04/24(土) 18:29:36

俺は

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

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

手続きって何だ？

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

こういうことだよね。

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

0195デフォルトの名無しさん

2010/04/24(土) 18:31:03

>>193
>主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。

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

0196デフォルトの名無しさん

2010/04/24(土) 20:03:00

>>193
>だから、そのオブジェクト指向とやらが嫌だと言ってるんだが。
>手続き型言語だったら、素直に手続きで定義すりゃいいだろ。
だったら「関数」を使え、「オブジェクト間」とか使うなアホっほいぞ。

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

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

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

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

おまえ、駄目だ。

0197デフォルトの名無しさん

2010/04/24(土) 20:07:41

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

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

0198デフォルトの名無しさん

2010/04/24(土) 20:44:38

>>191
それなんて構造的部分型？

0199デフォルトの名無しさん

2010/04/24(土) 22:49:25

＞主体的に動き回るオブジェクトやらを管理するのは骨が折れそうですね。

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

0200デフォルトの名無しさん

2010/04/24(土) 23:15:25

>>199
あと、部分を実装する時に、他の部分の実装を気にしなくても済むのもメリットだね。
「オブジェクト同士の依存関係で破綻する」という反論が来るかもしれないが、
実装の前に、オブジェクト間でそういう依存関係を持たないように設計するのは大前提。
そもそも、「全部の流れを一度に把握する」などというのは、大規模になるほど不可能になる。

0201デフォルトの名無しさん

2010/04/25(日) 03:25:04

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

0202デフォルトの名無しさん

2010/04/25(日) 03:32:28

だからとんでもなく遅くなるんだね

0203デフォルトの名無しさん

2010/04/25(日) 09:53:50

>だからとんでもなく遅くなるんだね
"とんでもなく"までは、遅くならないが
構造化より遅いのは確か。
でも、その構造化も非構造化より遅い。

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

0204デフォルトの名無しさん

2010/04/25(日) 11:11:58

>>202は、数十万行のスパゲッティコードを苦も無くメンテできる天才プログラマなんだよ。

0205デフォルトの名無しさん

2010/04/25(日) 12:42:41

>>197
お前分かってるね。
>>179　=　>>196　は、OOPすらよく分かっていない。
その癖声だけ大きい。こういうのがOOPの評価を無駄に落としている。
だから俺はOOPを嫌いになったし、距離を置きたくなった。

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

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

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

0206デフォルトの名無しさん

2010/04/25(日) 13:06:33

>>201
それはカプセル化であって、OOPではないわな。
そんで次はこういう方向へ話が行く。「だったらOOPって一体何よ」ってね。
そんで、カプセル化とポリモを合わせ技にして、「オブジェクトの振る舞いを定義して～」って話になる。
このようにOOPの用語は極めて曖昧で、そもそも議論が成り立たない。

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

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

俺はこう分けた。

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

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

0207デフォルトの名無しさん

2010/04/25(日) 13:47:21

>>205-206
構文をどう呼称するとかどうでもいいから、
君が提唱するそれが、開発の容易性にどう貢献するのか論証してくれ。

0208デフォルトの名無しさん

2010/04/25(日) 13:57:19

>>205
> だいたい、コンピュータってのは、奴隷の代わりに発明されたものでだな。

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

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

0209デフォルトの名無しさん

2010/04/25(日) 14:06:26

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

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

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

0210デフォルトの名無しさん

2010/04/25(日) 14:12:20

>>208
そろばんは逐次実行できないよね。
いわゆるコンピュータには、なぜプログラムカウンタがあるのかを考えてみよう。

0211デフォルトの名無しさん

2010/04/25(日) 14:12:27

> しかし、オブジェクト同士の化学反応の結果が、目的の機能になってなきゃならないってのは、
> シミュレーション自体が目的の場合を除き、誰がどう考えても遠回り。

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

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

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

0212デフォルトの名無しさん

2010/04/25(日) 14:17:00

>>210
「逐次実行」の定義は？

0213デフォルトの名無しさん

2010/04/25(日) 14:20:13

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

0214デフォルトの名無しさん

2010/04/25(日) 14:22:34

>>213
> 「時々OOPである糞な例として、」

日本語でおｋ

0215デフォルトの名無しさん

2010/04/25(日) 14:22:54

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

0216デフォルトの名無しさん

2010/04/25(日) 14:25:36

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

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

0217デフォルトの名無しさん

2010/04/25(日) 14:34:52

>>215
君の発言がことごとく論理的でなくて解釈に困るから、いちいち確認を取らざるをえないだけ。

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

0218デフォルトの名無しさん

2010/04/25(日) 15:00:01

結局、君が何を言っても突っ込みどころ満載なのは、端的に無教養だからだよ。

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

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

0219196

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は、メッセージパッシングだ。

0220デフォルトの名無しさん

2010/04/25(日) 15:40:32

カプセル化＝アクセサみたいに言ってるのがもうダメだわ

0221デフォルトの名無しさん

2010/04/25(日) 15:45:07

プログラムのスレで単にコンピュータって言えば、
逐次実行可能な(プログラミング可能な)物を指していると言うことぐらいは分かるだろうよ。
プログラムのスレでプログラミング不可なコンピュータ、まして、ソロバンの話をするわけ無いだろう。

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

0222デフォルトの名無しさん

2010/04/25(日) 15:49:13

>>219
なに言ってんだこいつ。
>>197は、メッセージパッシングについてではなくて、
「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
メッセージパッシングなんぞ、どうてもよい。

0223デフォルトの名無しさん

2010/04/25(日) 15:59:59

>>221
レスあんがと

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

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

0224デフォルトの名無しさん

2010/04/25(日) 16:07:27

このスレ自体が役に立っていないなwww

0225デフォルトの名無しさん

2010/04/25(日) 16:08:24

>>221
どちらにしろ、いわゆるフォン＝ノイマン・アーキテクチャ登場以前の
アナログ・コンピュータを含めたコンピュータの歴史のどこをどう切っても、
「コンピュータは奴隷の代わりに発明された」なんて話は出てこないけどな。

0226デフォルトの名無しさん

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

0227デフォルトの名無しさん

2010/04/25(日) 16:13:42

ん？
コンピュータは当時の戦争で弾道計算に利用されていた
手回し式計算機を置き換えるものとして開発されたんだが？
それをまわしてたのは奴隷だぜ？

0228デフォルトの名無しさん

2010/04/25(日) 16:15:00

>>210
CPUの本質はプログラムカウンタじゃないからw

0229219

2010/04/25(日) 16:26:00

>>222
>「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
なにが、言いたい？お前「主体的」の意味が分かってないのか？
もしかして、「自立的」とか「自律的」と間違っていないか？　お前は「小学４年生」かｗ
お前は、もういいよ。

0230デフォルトの名無しさん

2010/04/25(日) 16:28:17

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

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

0231デフォルトの名無しさん

2010/04/25(日) 16:31:40

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

0232デフォルトの名無しさん

2010/04/25(日) 16:33:24

>>222
>>229
これｗｗｗ

0233デフォルトの名無しさん

2010/04/25(日) 16:40:20

>>223
個人的にはダックタイピングもメソッド名をそろえなきゃいけない制約がうざいかなぁと思ってる。
似た機能のメソッドが同じ名前でなきゃ駄目ってのもなぁ。
TypeErasureであれなんであれ、結局アダプタクラス作るわけで、なんかスッキリしない。

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

0234デフォルトの名無しさん

2010/04/25(日) 16:55:00

>>229
なんでだよ。アクターモデルのアクターは自律しては動かないだろ。
勝手な妄想はよしてくれ。

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

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

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

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

0235デフォルトの名無しさん

2010/04/25(日) 17:05:22

日本語力に問題がある奴と話をするとほんと疲れるな。。

0236デフォルトの名無しさん

2010/04/25(日) 18:00:21

>>226
http://metatoys.org/oxymoron/oxymoron.html
今ここ読んできたけど、マジだな。
はぁー、こういうのに感化されるわけか。大変だな。

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

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

0237デフォルトの名無しさん

2010/04/25(日) 18:12:13

>>236
> インターネットが、ほんの僅かの単純な機能を成り立たせるために、
> 一体どれだけ複雑なシステムになってしまっていることか。

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

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

0238デフォルトの名無しさん

2010/04/25(日) 18:24:09

>>187ナイス

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

0239219

2010/04/25(日) 18:24:39

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

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

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

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

0240デフォルトの名無しさん

2010/04/25(日) 18:45:22

>>237
人間は分業したからこそ、ここまでの技術力を持ったんだよなあ。

0241デフォルトの名無しさん

2010/04/25(日) 18:49:02

まるでOOでなければ分業できないとでもいうような言い草だな

0242デフォルトの名無しさん

2010/04/25(日) 18:55:09

>>241
少なくとも、問題領域を分割して分業するための優れた方法ではある。
唯一の方法だとは誰も言っていない。

0243デフォルトの名無しさん

2010/04/25(日) 19:35:45

>>242
そりゃすまんかった
もう少し、具体的に例でも出して問題意識とか得意不得意を挙げていかないと
建設的な話に転がっていかない気がするよ

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

0244デフォルトの名無しさん

2010/04/25(日) 19:40:56

>>243
> 具体的に例

デザインパターン。

0245デフォルトの名無しさん

2010/04/25(日) 19:53:11

いやデザパタはあくまでOOの上の問題解決法だから、こういうスレで
デザパタから始めるのは視野が狭い
たとえば関数型なら、状態を扱うデザパタの多くは問題外だろう

0246デフォルトの名無しさん

2010/04/25(日) 22:10:59

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

0247デフォルトの名無しさん

2010/04/25(日) 22:24:47

>>246
kwsk

0248デフォルトの名無しさん

2010/04/25(日) 22:49:24

デザパタはバッドノウハウ（ｷﾘｯ

0249デフォルトの名無しさん

2010/04/26(月) 11:08:43

>>246
正確には「デザインパターンの大部分はバッドノウハウである」じゃないでしょうか。

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

0250デフォルトの名無しさん

2010/04/26(月) 18:23:10

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

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

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

0251デフォルトの名無しさん

2010/04/26(月) 18:31:44

>>249
静的型言語はアレはアレで有用なんだけど、
C++やJavaで、中途半端に仮想関数なんぞ取り入れたのがマズかったんだろうな。
失敗作ってことで。

0252デフォルトの名無しさん

2010/04/26(月) 18:38:18

>>251
実用性を全く考えないアカの人ですか？

0253デフォルトの名無しさん

2010/04/26(月) 20:07:34

静的型言語には静的型なりの確固としたメリットがあるわけで、バッドノウハウとはまた違うだろう。

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

0254デフォルトの名無しさん

2010/04/26(月) 20:22:11

>>250
大昔に小規模なコードを書いてる限りにおいては、それでも良かったかもしれない。
一命令単位で削るチューニングや、ワンライナー的な小手先の職人芸がもてはやされた時代だな。

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

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

0255デフォルトの名無しさん

2010/04/26(月) 20:36:20

>　特定のコンテキストに
>　依存した「単純さ」に未来はない。

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

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

0256デフォルトの名無しさん

2010/04/26(月) 20:44:16

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

0257デフォルトの名無しさん

2010/04/26(月) 20:54:55

>>255
> 上から下まで同じ言語でってのには無理があると思う。

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

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

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

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

0258デフォルトの名無しさん

2010/04/26(月) 21:03:16

>>256
もう、80486なスタンドアロン・コンピュータでコードを動かす時代じゃないんだよ。
組み込み機器でさえ、高性能ハードウェアにAndroidのような汎用OSを積んで、
ブラウジングやWebアプリ連携が大前提の時代に移行しつつあるのに。

0259デフォルトの名無しさん

2010/04/26(月) 21:12:46

>>256
windows bitmap はbitmapを表現するとてもシンプルな言語で、拡張性は皆無だが、
それを利用したからといって、行き詰るとも高い代償を払う羽目になるとも思わないね。

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

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

0260デフォルトの名無しさん

2010/04/26(月) 21:24:53

あーアンカーミスしちゃったな。自分にレスしちゃった。失礼。

0261デフォルトの名無しさん

2010/04/26(月) 22:15:11

>>250
>お前普通に痛い子だから、多分あちこちに敵が居るぞ。
>いいかげん、お前の面倒見るの大変だから、さっさとお仲間さんのところへ行ったら？
まったく、知識・技術がない人間、決まって最後は
相手の人間性や性格の悪口を書く。

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

0262デフォルトの名無しさん

2010/04/27(火) 05:42:27

>>259
> windows bitmap はbitmapを表現するとてもシンプルな言語で、拡張性は皆無だが、
> それを利用したからといって、行き詰るとも高い代償を払う羽目になるとも思わないね。

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

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

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

0263デフォルトの名無しさん

2010/04/27(火) 05:55:15

つうか、総論に対して特殊な反例を持ってきても、それは全く反論になってないよ。

0264デフォルトの名無しさん

2010/04/27(火) 11:51:50

プログラムで必要な動作をオブジェクトの相互作用に分解するのは
・理解が難しくなる
・無駄が多くなる
・修正しにくくなる
というデメリットが出てくる場合があると思います。

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

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

0265デフォルトの名無しさん

2010/04/27(火) 12:11:01

オブジェクト指向派の人に質問なのですが、>>264の処理はメソッドとしてresponseオブジェクトに持たせるべきでしょうか？

0266デフォルトの名無しさん

2010/04/27(火) 12:58:11

多様性の出番がないもの持ち出されても

0267デフォルトの名無しさん

2010/04/27(火) 20:22:26

そもそもメソッドチェインってオブジェクト指向的に何か問題だったか？

0268デフォルトの名無しさん

2010/04/27(火) 20:25:03

Javaってメソッドチェーン出来ない糞オブジェクトばかりだから嫌い

0269デフォルトの名無しさん

2010/04/27(火) 20:28:59

>>268
commons使え。

0270デフォルトの名無しさん

2010/04/27(火) 21:35:14

>>264
> オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法

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

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

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

0271デフォルトの名無しさん

2010/04/27(火) 22:31:16

オブジェクトのメッセージパッシングによる相互作用どうのこうのに拘ってるのは、
例のメッセージパッシング君だけだから放っておいていいよ。

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

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

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

0272デフォルトの名無しさん

2010/04/27(火) 23:07:49

委譲でもいいけどな。

0273デフォルトの名無しさん

2010/04/27(火) 23:21:54

>>264が何にこだわってるのかイマイチ見えないな

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

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

0274デフォルトの名無しさん

2010/04/27(火) 23:25:09

Rubyみたいな「構文要素は全てオブジェクトです」みたいのだったら可能かもな。

0275デフォルトの名無しさん

2010/04/28(水) 00:16:13

Smalltalkは死んだ事になってるんだな
生きてると言うつもりは無いけどさ

0276デフォルトの名無しさん

2010/04/28(水) 00:19:52

誰もその路線を継がなければ、路線としては死んだと同じだ

0277デフォルトの名無しさん

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/

0278デフォルトの名無しさん

2010/04/28(水) 00:39:15

Smalltalkの底を流れる設計思想 http://bit.ly/dCQIfo

0279デフォルトの名無しさん

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はよくわからないけど、これは相手のフィールドは変更されないでしょう？
取得したクッキーの編集の話しだから、外部からの制御じゃなく内部で処理していると思うけど、よくわからん。

0280デフォルトの名無しさん

2010/04/28(水) 07:39:35

結局、Rubyのそのコードの例でOOのどんな「問題点」を指摘したいのかよく分からん。

0281デフォルトの名無しさん

2010/04/28(水) 08:24:10

OOPと正規表現は無関係だと言ったかったのではあるまいか

0282デフォルトの名無しさん

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）

0283デフォルトの名無しさん

2010/04/28(水) 11:38:28

>>271
引数で渡されたオブジェクトの状態を変更しない方がいい、ということに同意します。

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

0284デフォルトの名無しさん

2010/04/28(水) 12:31:43

>>282
OOそんなに詳しくないけど
RubyのブロックみたいなのってSmalltalkが元ネタだよね？
デメテルの法則とか言ってたら、Smalltalkじゃコードなんて書けないんじゃないの？
逆にその意味で「お上品」に書けるコードってのは
「純粋なオブジェクト指向言語」じゃない気がするんだが

0285デフォルトの名無しさん

2010/04/28(水) 12:40:35

下2行意味不明だった
あなたの言う意味でお上品な書き方してる場合、OO的なガワの部分を
お上品に書いてるだけで、
実際には中身は手続き的または関数的に書いてんじゃないのかってことね
これはただの直観だけど

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

0286デフォルトの名無しさん

2010/04/28(水) 14:41:49

OOPを理解できない奴の言い訳にしか見えないのが悲しいねｗ

0287デフォルトの名無しさん

2010/04/28(水) 20:16:59

imifu

0288デフォルトの名無しさん

2010/04/28(水) 21:49:54

>>271
>複数のオブジェクトに副作用する処理は、普通に関数で書け。
>void func( type1 *object1, type2 *object2 ){}
それはオブジェクト指向じゃないから、君は勉強が足りないよ。

0289デフォルトの名無しさん

2010/04/28(水) 21:59:16

オブジェクト同士がメッセージをやり取りする
みたいな表現はoopの理解を
ものすごくさまたげているとおもう

0290デフォルトの名無しさん

2010/04/28(水) 22:00:01

オブジェクト指向が分かって人間が、アンチ・オブジェクト指向と言っても説得力がない。
>>271
この人が一番駄目だよな。

0291デフォルトの名無しさん

2010/04/28(水) 22:08:44

たしかに、>>271はいままでの書き込みを見ると
オブジェクト指向が理解できていない。

0292デフォルトの名無しさん

2010/04/28(水) 22:21:44

>>289
エセOOはやってないね。エセOOをOOの言葉でやるから。

0293デフォルトの名無しさん

2010/04/28(水) 22:50:31

>>289
オブジェクト指向の勉強をはじめたころは
同じように感じたこともあったけど
理解が進むとわかってくるよ。

0294デフォルトの名無しさん

2010/04/29(木) 00:07:33

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

0295デフォルトの名無しさん

2010/04/29(木) 01:23:01

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

0296デフォルトの名無しさん

2010/04/29(木) 06:07:01

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

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

0297デフォルトの名無しさん

2010/04/29(木) 06:56:04

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

0298デフォルトの名無しさん

2010/04/29(木) 10:01:46

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

0299デフォルトの名無しさん

2010/04/29(木) 10:45:32

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

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

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

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

0300デフォルトの名無しさん

2010/04/29(木) 13:47:59

>>295
>問題はあるかもしれないけど、学習パスとしてはデザパタ丸暗記とかでもいいと思う今日この頃。
丸暗記は別にして、GoFぐらいは理解してほしい。
オブジェクト指向で作れなくてもいいけど、こっちが作ったソースぐらいは読めると嬉しい。

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

0301デフォルトの名無しさん

2010/04/29(木) 15:15:16

デザパタの肝は、共通語彙のカタログだからな。

0302デフォルトの名無しさん

2010/04/29(木) 19:38:37

理解するまで、とか、理解が進む、とか、理解してない内とか、とか、とか、
お前ら本当に大変だな。
理解が大変、理解が得られない、そういったものは元々から間違っている可能性すらもある。
まーOOPの定義すら無いわけで、理解しようもないのだが。

0303デフォルトの名無しさん

2010/04/29(木) 20:11:26

一般相対性理論は理解が大変だから間違ってると言いたいんですね、分かります。

0304デフォルトの名無しさん

2010/04/29(木) 20:19:34

目指すものについては大体共通理解はあるだろ。
早い話が開放/閉鎖原則とか単一責任原則とか。

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

0305デフォルトの名無しさん

2010/04/29(木) 20:36:06

>早い話が開放/閉鎖原則とか単一責任原則とか。

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

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

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

0306デフォルトの名無しさん

2010/04/29(木) 21:09:58

カプセル化はOOPとは独立した概念だろ
SICPでは「Data Abstruction」と呼んでいるが
そこで用いられるのは関数型言語のSchemeだ

0307デフォルトの名無しさん

2010/04/29(木) 21:12:23

>>305
俺はオブジェクト指向分析・設計については詳しくないから断言はできないが、
おそらく開放/閉鎖原則みたいなのは設計レイヤの話と言っていいんじゃないかな。

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

0308デフォルトの名無しさん

2010/04/29(木) 21:13:50

開放／閉鎖原則にしたって、メイヤーの言っていた意味のそれなんて
誰も守ってないだろ

0309デフォルトの名無しさん

2010/04/29(木) 21:14:24

じゃ、OOPと独立できない概念って何よ。

0310デフォルトの名無しさん

2010/04/29(木) 21:24:47

多様性
これを実現するために、いろろな機能が誘導されてくるんじゃないか

0311デフォルトの名無しさん

2010/04/29(木) 21:30:14

>>310
正解

0312デフォルトの名無しさん

2010/04/29(木) 21:53:17

だから、動的オーバーロードでいいんだろ？

0313デフォルトの名無しさん

2010/04/29(木) 21:59:40

動的オーバーロードって多重ディスパッチの事だろ？

0314デフォルトの名無しさん

2010/04/29(木) 22:00:26

それは要素技術でしょ。

0315デフォルトの名無しさん

2010/04/29(木) 23:24:35

>>305
オブジェクト指向を理解していない人の典型だとおもう。
ここまで駄目駄目だと．．．

0316デフォルトの名無しさん

2010/04/29(木) 23:31:16

>>312
>だから、動的オーバーロードでいいんだろ？
なにがいいの？　動的オーバーロードがオブジェクト指向だと思う理由は？

0317デフォルトの名無しさん

2010/04/29(木) 23:34:45

理解理解って、一体何を理解しろと言うのだ。

0318デフォルトの名無しさん

2010/04/29(木) 23:47:42

クラス分けの仕方

0319デフォルトの名無しさん

2010/04/29(木) 23:49:52

また斜め上の回答きたこれ

0320デフォルトの名無しさん

2010/04/30(金) 00:00:50

世の中クラス指向のOOPLだけじゃねーから

0321デフォルトの名無しさん

2010/04/30(金) 01:01:54

クラスの仕分けとダックタイピング

0322デフォルトの名無しさん

2010/04/30(金) 09:24:27

>>305
>>早い話が開放/閉鎖原則とか単一責任原則とか。
>それカプセル化の話だよね。それがOOPの本質なの？
カプセル化？　なぜ開放/閉鎖原則や単一責任原則がカプセル化の話だと思う？
君はバカのひとつ覚えで、なんでもカプセル化だね。

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

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

0323デフォルトの名無しさん

2010/04/30(金) 14:50:48

心を開いて！
君は洗脳されているんだよ！

0324(u＿・y) ◆rT33C51l9k

2010/04/30(金) 15:03:08

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

死ね

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

0325(u＿・y) ◆rT33C51l9k

2010/04/30(金) 15:06:28

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

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

0326デフォルトの名無しさん

2010/04/30(金) 15:07:04

なるほど、OO信者の成れの果ては糞コテなのだな。

0327デフォルトの名無しさん

2010/04/30(金) 15:11:38

大事なのは、プログラムの断片をつなぎ合わせる為の機構であって、OOPではない。
テンプレートと型推論と動的オーバーロードが有ればそれで良い。
オブジェクト「指向」する必要は無い。

0328デフォルトの名無しさん

2010/04/30(金) 15:54:24

>>327
テンプレートと型推論と動的オーバーロードで、ソフトウェア開発のどういう課題が解決できるの？

0329デフォルトの名無しさん

2010/04/30(金) 21:17:27

>>324
話の流れが良く見えてない状況で茶々をいれてみる

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

0330デフォルトの名無しさん

2010/04/30(金) 21:24:56

>>329
そんな初歩的なことは普通にできるだろ。

0331デフォルトの名無しさん

2010/04/30(金) 21:29:09

>>329
パーサのアルゴリズムとオブジェクト指向の間に何の関係があるの？

0332デフォルトの名無しさん

2010/04/30(金) 22:52:41

映画マトリックスの世界はOOPに違いない。

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

0333デフォルトの名無しさん

2010/04/30(金) 23:23:31

適用範囲

0334デフォルトの名無しさん

2010/05/01(土) 00:56:03

オブジェクト指向を取得には実践が大事。

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

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

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

0335デフォルトの名無しさん

2010/05/01(土) 01:26:10

「変更に対する柔軟性」と言っても、そんなん本じゃ説明できないもんな。

0336デフォルトの名無しさん

2010/05/01(土) 04:01:51

>>334
OO な設計ってこまわり効かなくね?
つか, 副作用前提で考えるか否かの問題なんだろうけどさ
問題領域によっては OO 思考されるとすごくじゃまなことがある

0337デフォルトの名無しさん

2010/05/01(土) 04:10:29

思考じゃなくて指向な。

0338デフォルトの名無しさん

2010/05/01(土) 04:14:54

あえて「思考」と書いてるわけだが

0339デフォルトの名無しさん

2010/05/01(土) 05:21:15

嗜好だろ

0340デフォルトの名無しさん

2010/05/01(土) 09:45:38

無知は恥ずかしいことじゃないよ。

0341デフォルトの名無しさん

2010/05/01(土) 11:08:18

思考・・・考えること。経験や知識をもとにあれこれと頭を働かせること。
指向・・・ある方向・目的に向かうこと。また、方向や目的を指示してその方に向かわせること。志向。
嗜好・・・ある物を特に好み、それに親しむこと。好み。主に飲食物についていう。

0342デフォルトの名無しさん

2010/05/01(土) 11:20:02

言葉遊びしか出来ない人達。

0343デフォルトの名無しさん

2010/05/01(土) 11:21:41

>>336
小回りといっても状況とプロジェクトの目的によるな。具体例を。
あと、単に設計者がタコなだけな場合も多い。

0344デフォルトの名無しさん

2010/05/01(土) 11:54:27

>>343
大規模な信号処理系とかだと, あちこちで状態を持たれると困る事が多いんだが,
Object に必要もない状態を持たせるやつが結構いる

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

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

0345デフォルトの名無しさん

2010/05/01(土) 11:56:06

>>337
元の文章は「OO思考」と書いてあるよ。
オブジェクトオリエンテッド思考な。
おまえの意見だとオブジェクトオリエンテッドオリエンテッドになるけどそれでいいのか？

0346デフォルトの名無しさん

2010/05/01(土) 12:53:33

>>344
信号処理系はよく分からないが、状態を集中管理した方が見通しがよくなる場合は
そうした方がいい場合もあるかもな。
小回りの効く単位で責務を切り出せる問題領域なら、OOで小回りが効かない
ということはないしむしろ逆。なんか禅問答チックだが。

0347デフォルトの名無しさん

2010/05/01(土) 16:22:33

>>344
一般にバッチ処理や制御系など、情報を保持しないシステムは、
オブジェクト指向向きでは無いと言われている。

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

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

0348デフォルトの名無しさん

2010/05/01(土) 17:50:50

>>347
λ計算やπ計算が注目ってんなら分かるが
その文脈で「オブジェクト指向が注目」って思いっきり意味不明だわ
そういう理由でOOを選ぶ奴は完全に見る目が無い
「状態の保持」は並列化の敵だ

0349デフォルトの名無しさん

2010/05/01(土) 18:07:59

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

0350デフォルトの名無しさん

2010/05/01(土) 18:27:25

>>349
んなもん常識だろ
状態があれば排他や状態のレプリケーションのコストが発生する
副作用の無い関数は本質的にパラレルに実行可能だ

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

0351デフォルトの名無しさん

2010/05/01(土) 19:45:39

>>350
Erlangは状態をもつアクターモデルで
遠隔オブジェクトとの通信にはメッセージパッシングを使うよ

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

無知はどちらかなフフフ

0352デフォルトの名無しさん

2010/05/01(土) 19:57:54

>>531
Erlangは通常「状態」を副作用（＝再代入）の形では扱わず
参照透明な形で状態遷移を扱う
データを内部に保持したがるOOとは違う

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

0353デフォルトの名無しさん

2010/05/01(土) 20:17:15

>>349,351
もう関数型は、無視したらどうだ。
ここまでくると、「荒し」だ。

0354デフォルトの名無しさん

2010/05/01(土) 20:19:06

>>353
ん？
>>357の意見が面白すぎたから突っ込んだだけだぜ
>>351も
Erlangのアの字も知らずにメッセージパッシングというだけで
OOだとでも思ったのか知らないが、面白い奴だな

0355デフォルトの名無しさん

2010/05/01(土) 20:19:57

>>352
> データを内部に保持したがるOOとは違う

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

0356デフォルトの名無しさん

2010/05/01(土) 20:22:00

>>355
OOのベースに手続きパラダイムが使われていることが多い、という事情は
その通りだが、それだけではないだろ

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

0357デフォルトの名無しさん

2010/05/01(土) 20:40:25

つーか、「データを中に持たない」のなら、「オブジェクト」自体が要らない
関数だけでいいだろ

0358デフォルトの名無しさん

2010/05/01(土) 20:45:14

>>356
オブジェクトが持つべきものは「責務」であって「状態」ではないからな。
だから、immutableなオブジェクトというのも当然アリ。

0359デフォルトの名無しさん

2010/05/01(土) 20:46:43

>>352
>少なくとも一般的な意味でのOOとは別もんだろ
なんだ、この逃げ方は、なにが「一般的な意味でのOO」ってなんだｗ
お前が一般的と言っているのは、浅いお前の知識で思っているオブジェクト指向だろｗ

0360デフォルトの名無しさん

2010/05/01(土) 20:47:38

ちなみに、ここでは「状態」と「データ」は区別して言ってるのでよろしく。
immutableなオブジェクトでも、初期パラメータとしての「データ」はもちろんある。

0361デフォルトの名無しさん

2010/05/01(土) 20:55:50

だから、関数型と言っている奴は
荒しだから、無視でいいだろう。
こいつのおかげで、スレが荒れている。

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

0362デフォルトの名無しさん

2010/05/01(土) 20:58:25

>>361
本当にそうだよ、別のところでやればいいのに。

0363デフォルトの名無しさん

2010/05/01(土) 21:06:52

>>358
それはその通りだね
immutableなオブジェクトしかないような「オブジェクト指向言語」は
俺は知らないが

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

0364デフォルトの名無しさん

2010/05/01(土) 21:10:42

>>359
いやお前、あの文脈でErlangがアクターモデルだからどうたらとか言われても
何の反論にもなってないんだが
その先の主張は何よ
ErlangはOOだとでもいいたいのか？

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

0365デフォルトの名無しさん

2010/05/01(土) 21:16:07

Erlanがこんなに人気あるとは思わなかったぞ

0366デフォルトの名無しさん

2010/05/01(土) 21:19:08

Erlang 宣伝してるのは同一人物だろ

0367デフォルトの名無しさん

2010/05/01(土) 21:21:27

別に宣伝してるわけじゃないんだけどね
>>351がアホなツッコミを入れたから話が伸びただけで
もっと言うなら>>347の面白主張がなければ話そのものが始まらなかった

0368デフォルトの名無しさん

2010/05/01(土) 22:02:50

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

0369デフォルトの名無しさん

2010/05/01(土) 22:07:42

>>368
もっと素直になれ、データを持ちたいからオブジェクトにしたいんだろうよ
単に関数をどこかにひとまとめにしたいだけなら、モジュールでいい

0370デフォルトの名無しさん

2010/05/01(土) 22:10:09

>>363
> immutableなオブジェクトしかないような「オブジェクト指向言語」

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

0371デフォルトの名無しさん

2010/05/01(土) 22:15:52

>>370
俺は「しかない」と言ってるんだから、反論になってないのは分かってるんだろうし、
そのつもりもないんだろうね

Scalaははねえ

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

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

0372デフォルトの名無しさん

2010/05/01(土) 22:17:14

>>369
素直になれって言われても、データを持ちたいからという「だけ」じゃないだろ。
関数「だけ」でいいだろ、って言い出したのはそっちだよな？
まあもともとオブジェクト指向なんて鵺のようなものなんだし、どっちでもいいけど。

0373デフォルトの名無しさん

2010/05/01(土) 22:18:19

>>371
純粋なものがすなわち使いやすいわけではないからねぇ。
言語仕様のみでサポートできることにも限界はあるし。

0374デフォルトの名無しさん

2010/05/01(土) 22:18:44

>>372
ああそりゃすまんかったｗ

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

0375デフォルトの名無しさん

2010/05/01(土) 22:22:08

>>374
それ「だけ」のためにクラスを利用してる言語だったら確かに意味がないけど、
そういうふう「にも」使えるというだけなら、別に実用上の問題はないんじゃないの。

0376デフォルトの名無しさん

2010/05/01(土) 22:25:01

>>375
まあ、そう言ってしまえばそうなんだが、気分としては気持ち悪いし、
美しいとも思えないね

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

0377デフォルトの名無しさん

2010/05/01(土) 22:34:04

とはいえ、単純に名前空間やモジュールといっても、
コードのパッケージングの仕組みと深く関わってる場合も多いわけだし、
そう簡単にそうだとは言い切れない部分もあるんでないかな。

0378デフォルトの名無しさん

2010/05/01(土) 22:34:42

確かにオブジェクト指向なんて鵺のようなものだよな。

0379デフォルトの名無しさん

2010/05/01(土) 22:36:21

しかし、ここまで関数型くんが無知だと笑ってしまう。

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

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

0380デフォルトの名無しさん

2010/05/01(土) 22:39:16

>>377
ん？
パッケージングの仕組みがそうだから言語デザインが汚くても従容と
受け入れてねってこと？　良く分からん

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

0381デフォルトの名無しさん

2010/05/01(土) 22:44:39

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

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

0382デフォルトの名無しさん

2010/05/01(土) 22:48:34

あんたのたわごとで、極めつけで意味がわからんかったのが、これね
＞Erlangは状態をもつアクターモデルで

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

0383デフォルトの名無しさん

2010/05/01(土) 23:02:22

顔はサル、胴体はタヌキ、トラの手足を持ち、尾はヘビで、「ヒョーヒョー」という、大変に気味の悪い声で鳴くのが鵺（ぬえ）。

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

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

0384デフォルトの名無しさん

2010/05/01(土) 23:21:18

そりゃあるよね。

おわり。

0385デフォルトの名無しさん

2010/05/01(土) 23:25:22

ただ、その例だと何かやりようがあるような気もするけどね。
それが最適解かは、そのソフトが目指すところによると思うけど。

0386デフォルトの名無しさん

2010/05/01(土) 23:36:44

>>383
適当だけど
登場人物は
ImageOp、ImageSelection、Image
こんな感じでないの
イメージエディタの編集操作って基本的にイメージのセレクションに対して
作用するでしょ

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

0387デフォルトの名無しさん

2010/05/01(土) 23:40:42

まあPhotoshopの例はあくまで喩えだけど、
イメージのセレクションそれ自体はユーザに任されていて、エディタの機能は
「セレクト後」のオブジェクトに作用するだけだよね。

0388デフォルトの名無しさん

2010/05/01(土) 23:44:55

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

0389デフォルトの名無しさん

2010/05/01(土) 23:56:56

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

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

0390デフォルトの名無しさん

2010/05/01(土) 23:58:51

なんか本気で分かってないくせに
高みにいるつもりで人を「関数型くん」呼ばわりで馬鹿にした気になってんだな…
ご苦労なこった

0391デフォルトの名無しさん

2010/05/02(日) 00:15:46

>>389
>作用を持つコードや可変な状態に、複数のスレッドからアクセスしたければ
>必ず排他が必要だ
単一のスレッドのスレッドからしかアクセスしなければ排他は必要ありません。

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

0392デフォルトの名無しさん

2010/05/02(日) 00:20:22

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

0393デフォルトの名無しさん

2010/05/02(日) 00:32:30

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

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

0394デフォルトの名無しさん

2010/05/02(日) 10:59:48

こういうスレって実績伴わずに脳内世界で自由に羽ばたいてるだけの人が
よって来やすいよね。ただの手を動かさないニートとか
決められた事を守れない他人不在の自己中とか

0395デフォルトの名無しさん

2010/05/02(日) 11:46:09

自己紹介乙

0396デフォルトの名無しさん

2010/05/02(日) 15:06:13

>>392
ちゃんと文章読む癖をつけた方がいいと思う。

0397デフォルトの名無しさん

2010/05/02(日) 17:20:37

俺は「オブジェクト指向とは何か」を知りたい（自分の中で納得したい）ので、このスレはすごく勉強になっています

0398デフォルトの名無しさん

2010/05/02(日) 21:05:51

オブジェクト指向とは何か、について一致する見解はないね。
そもそも対立概念（ライバル）が何かすらわからん。

0399デフォルトの名無しさん

2010/05/02(日) 21:45:03

オブジェクト指向とは責任と権限である。

0400デフォルトの名無しさん

2010/05/02(日) 22:45:41

つまり、再利用

0401デフォルトの名無しさん

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

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

0402デフォルトの名無しさん

2010/05/03(月) 18:33:05

一言で言うなら、「対象（＝責務）を中心に機能を整理するコンセプト」というあたりでいいと思うけどね。
ところで「左」って？

0403デフォルトの名無しさん

2010/05/03(月) 18:40:32

>>398
そもそも大半のパラダイムに「対立概念」なんて無いハズなんだけどな。
よく対比される手続き型と関数型だって、じゃあ論理型は？ってなるし。

0404デフォルトの名無しさん

2010/05/03(月) 18:42:51

責務君は本当に頭おかしいよ。
対象って言ってんだから、対象だろうよ。
お前みたいなのが居るからOOPは嫌になる。

0405デフォルトの名無しさん

2010/05/03(月) 18:47:13

>>403
手続き型と関数型は、副作用の有無で明確に色分けされてる。
では、OOPとそうでないものは、何を基準に色分けすればよい？

0406デフォルトの名無しさん

2010/05/03(月) 19:23:20

副作用がない手続き型ってのもあると思うけど？

0407デフォルトの名無しさん

2010/05/03(月) 19:29:40

副作用がなくとも関数がファーストクラスでなければ関数型とは言えないだろうな
もっとも副作用のない手続き型言語なんて俺は見たことがないが

0408デフォルトの名無しさん

2010/05/03(月) 20:28:08

>>404
「述語（機能）よりもその対象を中心に据える」
⇔「対象がどういう機能を提供するかを中心に整理する」と考えるなら、
⇔「対象の責務から持つべき機能を逆算する」でいいと思うんだが。

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

0409デフォルトの名無しさん

2010/05/03(月) 20:35:18

デザイン手法の説明としてならまだしも
言語パラダイムの説明としては非具体的過ぎて全然しっくり来ない

0410デフォルトの名無しさん

2010/05/03(月) 20:50:28

>>409
言語パラダイムとしては、それこそ色々なアプローチが百家争鳴なわけで、
そこで定義するのは無理じゃないかな、正直な話。
それよか、デザイン手法の理解から入って、
その実装に役立つ手法を考えていく方が生産的だと思うな。

0411デフォルトの名無しさん

2010/05/03(月) 20:56:46

その上で、あえて言語パラダイム的な観点から言えば、
「委譲より継承」「インタフェース」あたりがキーワードだろうな。

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

0412411

2010/05/03(月) 20:59:02

すまん、逆だ。

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

0413デフォルトの名無しさん

2010/05/03(月) 21:06:57

>>411
それでは狭すぎる
非クラスベース、ダックタイピング、structual subtypingなOOが
ずっぽり抜けてるだろ

0414デフォルトの名無しさん

2010/05/03(月) 21:10:54

単純に
データと、データの操作をひとまとめにした『オブジェクト』を中心に据えた言語
では駄目なのか

0415デフォルトの名無しさん

2010/05/03(月) 21:21:42

>>413
という話が出てくるから、結局「オブジェクト指向の定義」として語るには微妙だよね、と。
なら、デザインレベルの話を中心にして、言語処理系ごとのテクニックを共有するに留めた方がよかないか。

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

0416デフォルトの名無しさん

2010/05/03(月) 21:26:51

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

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

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

0417デフォルトの名無しさん

2010/05/03(月) 21:48:07

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

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

0418デフォルトの名無しさん

2010/05/03(月) 21:52:38

オブジェクト指向というのは言語を分類する概念ではないのかもね。
コードとデータを「まとめる」だけなら、CでもアセンブリでもMLでも可能なんだし
（「まとめる」の定義次第ではあるが）

0419デフォルトの名無しさん

2010/05/03(月) 21:54:56

「オブジェクト指向入門第2版原則・コンセプト」（バートランド・メイヤー、2007年）
http://www.amazon.co.jp/dp/4798111112

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

0420デフォルトの名無しさん

2010/05/03(月) 21:55:40

オブジェクト指向のうま味だけを取り入れようとしたマルチパラダイムな言語が主流になってるから
オブジェクト指向があやふやになるのも仕方がないわな

0421デフォルトの名無しさん

2010/05/03(月) 21:56:16

>>417
いやだから、GoF本の「インタフェースと実装の分離」は
C++とその一族みたいなクラス／継承ベースの静的型言語特有の問題だろ

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

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

0422デフォルトの名無しさん

2010/05/03(月) 21:59:28

>>418
「オブジェクト指向でコードを書きやすい言語」というくらいかもね。
特に近年提唱されている実践とか開発手法を考慮すると、言語処理系だけで話は完結しないし。

0423デフォルトの名無しさん

2010/05/03(月) 22:02:14

>>418
「まとめる」のは、単にオブジェクト指向的な設計手法
それをサポートする具体的な何か（たとえばクラス）を備えている言語が
オブジェクト指向言語、だろ

0424デフォルトの名無しさん

2010/05/03(月) 22:09:28

>>421
例えば、DIコンテナを使って具象にMockを差し込むことで単体テストを容易にする、
みたいなことをやるのは、あくまでそのオブジェクトが果たす「責務」をテストしたいわけで、
具象自体は責務をエミュレートするMockと常に入れ替え可能なわけだ、この場合。

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

0425デフォルトの名無しさん

2010/05/03(月) 22:19:46

>>424
言っている意味は分かるよ
書いている気分や設計としては、インタフェースを相手にしているのであって
具象、ましてやデータのことは考えていないと言いたい訳だろ

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

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

0426デフォルトの名無しさん

2010/05/03(月) 22:32:55

>>425
そっちの言いたいことも分かるが、そういう「下」の話を含めだすと、
議論の共通前提を作るという意味では、あまりメリットがない気がするんだよな。

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

0427デフォルトの名無しさん

2010/05/03(月) 22:37:49

>>426
いやだから、インタフェースが全く「共通項」にはならないことは示したよね？
それどころか、手続き型言語における「構造化手法」より重要度が低く、弱いよ

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

0428デフォルトの名無しさん

2010/05/03(月) 22:50:00

>>427
それはイエス。

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

0429デフォルトの名無しさん

2010/05/03(月) 22:54:10

>>428
なるほど、OOはプログラミングパラダイムとしては定義不可、という立場？

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

0430デフォルトの名無しさん

2010/05/03(月) 23:00:09

>>429
立場というか、お察しの通り動的型方面には弱いので正直分からんというか。
ただ、OOP or OOPLとして一貫性のある「オブジェクト指向」の説得的な定義は
今のところ見たことがないね。

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

0431デフォルトの名無しさん

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の場合、
中心に据えるべき対象が定まらなくて困る場合があるよ、と。

0432デフォルトの名無しさん

2010/05/04(火) 02:26:36

>>431
日本語でおｋ

0433デフォルトの名無しさん

2010/05/04(火) 02:28:51

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

0434デフォルトの名無しさん

2010/05/04(火) 02:39:38

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

0435デフォルトの名無しさん

2010/05/04(火) 12:11:10

>>431
Wikipedia を盲信してるんだな。

0436デフォルトの名無しさん

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.

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

0437デフォルトの名無しさん

2010/05/04(火) 12:51:52

OOとOOPが別れているのは何でなんだろうな
英語版は別れてないのに

0438デフォルトの名無しさん

2010/05/04(火) 13:05:11

「OOP + OOAD」を全部ひっくるめてOOPと呼んでるだけじゃね。

0439デフォルトの名無しさん

2010/05/05(水) 14:50:19

OO持ち上げてる連中の中に「OOしてなくちゃソフトじゃねぇ」的なノリがあるんだよなぁ
# 「でも、おまえ、制御系書けないだろ」って奴に限って、そのノリが強いのが痛い

0440デフォルトの名無しさん

2010/05/05(水) 15:30:43

被害妄想乙

0441デフォルトの名無しさん

2010/05/05(水) 16:47:02

老害乙

0442デフォルトの名無しさん

2010/05/05(水) 16:55:09

オブジェクト指向の再利用は、本当に有効か？

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

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

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

0443デフォルトの名無しさん

2010/05/05(水) 17:00:12

フレームワークはOOの成功例だと思う
MFCは失敗例っつーかなんというかゴミ

0444デフォルトの名無しさん

2010/05/05(水) 17:01:19

まぁ末端のドカタはクラスを利用するだけで自分で作ることはないからな
ドカタはOOpの勉強なんかせんでええよ

0445デフォルトの名無しさん

2010/05/05(水) 17:07:10

OOにしたから再利用しやすいなんてのは幻想だろ

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

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

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

0446デフォルトの名無しさん

2010/05/05(水) 17:21:18

いまどきOOで再利用性の方を強調してる奴なんかいないだろ？
そういうメリットもある、という程度。

0447デフォルトの名無しさん

2010/05/05(水) 17:28:08

>>446
OOの一番のメリットってなに？

0448デフォルトの名無しさん

2010/05/05(水) 17:31:05

>>443
20年近く前の、テンプレートもないC++の草創期に作られたライブラリを今さらとりあげてゴミっていわれてもな。

0449デフォルトの名無しさん

2010/05/05(水) 17:40:04

>>447
高凝集かつ疎結合なシステムを構築しやすい。

0450デフォルトの名無しさん

2010/05/05(水) 17:41:41

>>445
C++のテンプレートは、C++言語の大きな欠点とされているだろ。

0451デフォルトの名無しさん

2010/05/05(水) 17:49:01

メタプログラミングはオブジェクト指向と対立する概念ではないんじゃ。

0452デフォルトの名無しさん

2010/05/05(水) 17:54:46

>>449
それはOOだけじゃない。

0453デフォルトの名無しさん

2010/05/05(水) 17:56:34

>>452
別にOOだけのウリだとは一言も言っていない。

0454デフォルトの名無しさん

2010/05/05(水) 18:15:15

>>453
それだと、OOの一番のメリットっと言わないだろう。　普通は。

0455デフォルトの名無しさん

2010/05/05(水) 18:20:24

>>450
別にC++のテンプレートを褒める気は無い
重要なのは、あの醜悪な道具を使ったSTL並の道具を
C++の伝統的なOOの手法では作れなかったということ

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

0456デフォルトの名無しさん

2010/05/05(水) 18:27:36

>>454
日本語でおｋ

0457デフォルトの名無しさん

2010/05/05(水) 18:34:31

>>449
構造化言語でも出来る。

0458デフォルトの名無しさん

2010/05/05(水) 18:37:40

>>454
ほっとけ、相手はOOを知らないアホだから。

0459デフォルトの名無しさん

2010/05/05(水) 18:50:08

>>457
可能か不可能かで言えば可能かもしれないな。

0460デフォルトの名無しさん

2010/05/05(水) 18:59:42

>>455
C++（というかStroustrup）にとってのOOは、最近の責務ベースのOOとは全然違うからな。

0461デフォルトの名無しさん

2010/05/05(水) 19:38:00

>>444
http://www.youtube.com/watch?v=CFZiil0DfMc

0462デフォルトの名無しさん

2010/05/05(水) 20:12:58

>>460
STLの例は、責務ベースだとか責務ベースでないとかは、関係ないよ

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

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

0463デフォルトの名無しさん

2010/05/05(水) 20:13:56

>>448
ほぼ同じ時期(むしろMFC以前)に出来ていたTurboC++のOWLなんかはまともなフレームワークだったよ

0464デフォルトの名無しさん

2010/05/05(水) 20:53:50

>>462
それがOOと何の関係があるの？

0465デフォルトの名無しさん

2010/05/05(水) 22:02:45

>>461
http://www.youtube.com/watch?v=i6-1934HZG0

0466デフォルトの名無しさん

2010/05/05(水) 22:04:00

>>464
おまえ空気嫁てないなｗ
STLはOOと関係ないっていう話をしてるんだよw

0467デフォルトの名無しさん

2010/05/05(水) 22:06:44

>>466
そりゃそうだ。

0468デフォルトの名無しさん

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で、関数の呼び出しが動的オーバーロードされりゃポリモも出来るな。

0469デフォルトの名無しさん

2010/05/06(木) 05:26:34

自分で作ったら

0470デフォルトの名無しさん

2010/05/06(木) 12:50:49

>>468
その辺を突き詰めると、Haskellの言語仕様に近くなるような気がする。

0471デフォルトの名無しさん

2010/05/08(土) 02:14:38

OO、OO言ってるやつらは、
MLのモジュールとかHaskellの型クラスとか分かってんのかな？
色々な構造化の手法を知って、その共通点とか相異点を実感して、
初めてOOの特徴が分かるってもんだろ
日本語しか知らないのに、日本語の特徴は...って語ってるのと同じだぞ

0472デフォルトの名無しさん

2010/05/08(土) 02:17:40

日本語の特徴は主語が無いことです

0473デフォルトの名無しさん

2010/05/08(土) 02:22:59

シーザーを理解するためにシーザーである必要はない。

0474デフォルトの名無しさん

2010/05/08(土) 02:52:55

>>473
よく分からないww

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

0475デフォルトの名無しさん

2010/05/08(土) 02:55:22

ローマに行ったときはローマ人のように振舞いなさい

0476デフォルトの名無しさん

2010/05/08(土) 02:57:27

>>474
もっと具体的に。

0477デフォルトの名無しさん

2010/05/08(土) 03:11:46

>>476
いや、もう十分具体的じゃんww
まずはバリアントとレコードとモジュールとファンクターとシグネチャーを勉強してくれ
OOとは別の世界があるから

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

0478デフォルトの名無しさん

2010/05/08(土) 04:11:36

関数言語厨うぜ

0479デフォルトの名無しさん

2010/05/08(土) 07:10:17

>>477
実際 Haskell って楽しい？ちょっと興味はある
コード書く上で、例えばメイン処理、サブ処理１、１の結果を得て別の結果を返すサブ処理２と
３つのルーチンを考えた時、ベタな実装って具体的にどうなるの？

0480デフォルトの名無しさん

2010/05/08(土) 07:40:50

>>479
それくらい、ぐぐろうよ
ttp://www.sampou.org/haskell/tutorial-j/functions.html

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

0481デフォルトの名無しさん

2010/05/08(土) 07:47:33

>>480
ググろうじゃなくて実際に書いてる人としてお前の感想聞きたいんだけど

0482デフォルトの名無しさん

2010/05/08(土) 08:00:40

>>481
こりゃ失礼
もちろん楽しいです
λ計算や圏論や型理論が基礎にあって、地に足が付いている感が好きです

0483デフォルトの名無しさん

2010/05/08(土) 08:51:21

なんだ
いつものひとかw

0484デフォルトの名無しさん

2010/05/08(土) 09:16:19

>>483
えっww
OCamlのスレには書き込むけど、このスレは>>471が初めてなんだがww

0485デフォルトの名無しさん

2010/05/08(土) 10:04:08

>>479
Haskellの人じゃないけど
メインとサブの処理にするなら、そのまま関数にすればいいと思う
サブ1の結果を使うサブ2があるなら、サブ2の引数にサブ1の結果を渡すだけ

0486デフォルトの名無しさん

2010/05/08(土) 10:10:19

このスレで学びながら考えて、オブジェクト指向はいままでのプログラム作成法の集大成なんじゃないかな、と思った。

0487デフォルトの名無しさん

2010/05/08(土) 10:33:28

>>486
OOPは、よくできたプログラムの構造を研究した結果でてきたもの。

0488デフォルトの名無しさん

2010/05/09(日) 12:07:43

何を学んだんだと小一時間(ry

0489デフォルトの名無しさん

2010/05/10(月) 11:57:56

このスレで学んだこと：
・>>324-325が意外と的を射ているのかも
・Erlangって面白そう

0490デフォルトの名無しさん

2010/05/11(火) 20:48:45

自分の頭がOOになっていないため、オブジェクトは最低限にして、残りは関数にした方が素早くプログラムできます。

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

0491デフォルトの名無しさん

2010/05/11(火) 21:25:32

0492デフォルトの名無しさん

2010/05/11(火) 21:39:20

>>489
>このスレで学んだこと：
>・>>324-325が意外と的を射ているのかも
それは一番駄目な奴のとろだから。

0493デフォルトの名無しさん

2010/05/11(火) 22:52:42

上とろ
中とろ
下とろ

0494デフォルトの名無しさん

2010/05/12(水) 17:41:10

>>492
324,325=489
ほっといてやれ。

0495デフォルトの名無しさん

2010/05/14(金) 16:37:31

OOって役に立ってる？
確かに既存ライブラリを使うときにはOOで整備されていると楽だけど
自分で作る部分は、それほどOOにする必要がない場合が多いんだよね。

0496デフォルトの名無しさん

2010/05/14(金) 16:41:58

>>495
あれは複数人で開発（意思の疎通、統合が不自由）したり、
全体像が把握できないほどコード量が膨大になったりしたときに
役に立つんだと思うよ。

0497デフォルトの名無しさん

2010/05/14(金) 17:20:12

おまえらどれだけ小さいプログラムしか書かないんだ。フラグの山から解放される快適さを知れ。

0498デフォルトの名無しさん

2010/05/14(金) 17:36:11

そんなのオブジェクト嗜好でなくとも解放されるわい。
それをしてオブジェクト施行というならオブジェクト思考でないプログラミングなんてありえない。

0499デフォルトの名無しさん

2010/05/14(金) 18:29:43

アセンブリしか見えないw

0500デフォルトの名無しさん

2010/05/14(金) 18:41:17

随分とシコウを色んな単語に変換してくれるIMEだなw
まあ、フラグの山は流石に例えがおかしいが。

0501デフォルトの名無しさん

2010/05/15(土) 00:21:51

一人で開発する場合でもポリモとか役立つよ

0502デフォルトの名無しさん

2010/05/15(土) 00:33:10

ポリモしたい部分だけクロージャで渡せば
オブジェクトなんて必要ないのに

0503デフォルトの名無しさん

2010/05/15(土) 01:50:46

俺がポリモだった頃、女房はクロージャで息子はオブジェクトだった
わかるかな？

0504デフォルトの名無しさん

2010/05/15(土) 05:27:51

>>502
オブジェクトの種類によって決まってる処理なら、オブジェクトだけ渡せば済むほうが気楽だなあ

0505デフォルトの名無しさん

2010/05/15(土) 05:44:26

>>502
手動でOOPしている。

0506デフォルトの名無しさん

2010/05/15(土) 13:06:00

どうしてなの

0507デフォルトの名無しさん

2010/05/16(日) 12:04:07

>>506
OOPを使うやつらに役に立たない連中が多いからじゃね?

0508デフォルトの名無しさん

2010/05/18(火) 11:25:27

>>507
十把一絡げでレッテル貼りぱねぇっす‥ て、一瞬言おうと思ったが‥
深いかもしれない。言葉通りじゃなく、なんか深い

0509デフォルトの名無しさん

2010/05/20(木) 00:46:21

必要以上に異常にOOPにこだわるおじさんいますよね……

0510デフォルトの名無しさん

2010/05/20(木) 00:50:12

アランケイ信者か

0511デフォルトの名無しさん

2010/05/23(日) 18:36:02

むしろこだわってるのは若者ですよね

0512デフォルトの名無しさん

2010/05/23(日) 20:51:08

安蘭けい信者?

0513デフォルトの名無しさん

2010/05/23(日) 22:36:38

これ見ると下手な食事療法とかダイエットよりも効果あったよ。
http://www.petatv.com/tvpopup/video.asp?video=agri_long&Player=wm&speed=_med

0514デフォルトの名無しさん

2010/05/28(金) 11:31:16

しばらくHaskellを使ってからC#やVB.NETに戻ってきてプログラムを作ると
以前よりも無駄のないすっきりとしたプログラムを作れているという実感があります。

これは、処理の分割（抽象化）の能力が上がるからのような気がします。

関数型をかじりながらオブジェクト指向でプログラムを作ると良いのかもしれません。

0515デフォルトの名無しさん

2010/05/28(金) 13:14:59

でもなー
Haskell
とかって仕事では使わないしなー

0516デフォルトの名無しさん

2010/05/28(金) 19:57:16

うむぅ。じゃあC#とかに、Hakell使った人みたいになることを助けるような、
抽象化能力をあげるような機構とかってつくれないかな。と思ってみたり

0517デフォルトの名無しさん

2010/05/29(土) 12:23:52

日本語でおk

0518デフォルトの名無しさん

2010/06/10(木) 18:50:30

昔のえらい人も言ってたじゃないか。
実用するかどうかは置いといてとりあえずLISP学んどけって

0519デフォルトの名無しさん

2010/06/12(土) 00:59:21

HaskellやってからLispに戻ってくると
「うわーすんげー楽！変数書き換えられるよ！
シーケンシャルな（書いた順に実行する）コード書けるよ！」
ってなるｗ

0520デフォルトの名無しさん

2010/06/12(土) 11:29:07

手続き型脳乙

0521デフォルトの名無しさん

2010/06/13(日) 20:59:04

いや、俺は解らんでもないな
全部手続きで書きたいワケじゃなくて、基本関数的に書いてても
局所的には手続き的にやりたい時はある
そういう時に純粋関数型だとちょっと面倒くさい、やれなくは無いんだがね

0522デフォルトの名無しさん

2010/06/21(月) 12:33:30

そこでPythonですよ

0523デフォルトの名無しさん

2010/06/21(月) 13:21:50

Clojure（JVMで動くLisp派生言語）はJavaのオブジェクトが使えます。
たとえばStringのtoUpperCaseメソッドはどう呼び出すかというと

( .toUpperCase "hello" )

こんな感じです。
このスレ的に、ちょっと面白い位置付けですね。

0524デフォルトの名無しさん

2010/07/02(金) 23:44:26

OO信者が組み込み（ハード制御含む）やると、とたんに役に立たなくなるのはなぜですか？

0525デフォルトの名無しさん

2010/07/02(金) 23:50:30

組み込みの方ってOOできるんですか？

0526デフォルトの名無しさん

2010/07/03(土) 00:00:26

今時フツーにOOしてるが…
でも、仕様がそこらのOO屋さんの言ってるOOにはそぐわないらしいw
つか、OO分析してくれた結果が役に立たないのはなぜ？
さらに、OO言語使わないとOO出来ないのはなぜ？

0527デフォルトの名無しさん

2010/07/04(日) 23:04:19

組込みソフトウェア開発のためのオブジェクト指向モデリング
http://www.amazon.co.jp/dp/4798111767

リアルタイムUML―オブジェクト指向による組込みシステム開発入門
http://www.amazon.co.jp/dp/4881359797

0528デフォルトの名無しさん

2010/07/12(月) 02:33:43

>>526
世間のOOな開発手法は言語のサポートがある前提だからでしょ。
だから、そうでない場合、実装へのギャップが大きすぎるか
言語仕様に縛られて、OOとしては半端で意味のない設計になる。

他にはOO的手法は、非機能要件への対策には弱い印象がある。
極端にリソースがチープだったり、リアルタイム性が求められる時、
手法としては対処出来ない。
属人的なノウハウはあるだろうけど。

まぁ526は世間で言われるところの「OO」はしてないんじゃね？
原理主義的な(悪い意味でなく)OOであるのかも知れない。

0529デフォルトの名無しさん

2010/07/12(月) 22:26:39

そうか?
*BSD とか OpenSolaris の kernel 読んでると十分 OO してるけどな
まぁ、言語の制約もあって cast しまくりだがw

0530デフォルトの名無しさん

2010/07/13(火) 08:07:38

どの辺り？
OOD？P？

socketまわりぐらいしか見る機会無かったけど、
あんまりOOって感じじゃなかったような。

ちょっと興味はある。
これまで見た中でCでOOを頑張ってるのは
gtkしか知らない。
知らんだけであるとは思う。

0531デフォルトの名無しさん

2010/07/13(火) 10:26:36

ファイルディスクリプタなんてポリモーフィズムの最たるものだと思う。

0532デフォルトの名無しさん

2010/07/13(火) 23:09:20

流れ的に、kernelのfdまわりの実装の話だよな？

0533デフォルトの名無しさん

2010/07/15(木) 21:17:47

多態性＝OOではないと何度（ｒｙ

0534デフォルトの名無しさん

2010/07/15(木) 21:46:36

誰がイコールだと言っている?

0535デフォルトの名無しさん

2010/07/15(木) 22:27:34

自分は必要条件ではなく十分条件だと思っている。

0536デフォルトの名無しさん

2010/07/16(金) 00:27:46

>>535
a

0537デフォルトの名無しさん

2010/07/16(金) 00:28:48

>>535
十分条件だとすると、関数型言語もOOになるがいいのか？

0538デフォルトの名無しさん

2010/07/16(金) 03:28:11

OOは言語レベルの話じゃないだろ。

0539デフォルトの名無しさん

2010/07/16(金) 09:48:55

1. OOには多態が必要
2. 多態さえあればOO

の2択であれば、1の方が正解に近そうだ

0540デフォルトの名無しさん

2010/07/17(土) 20:31:36

結局いつもオブジェクトとはなんぞやって話になって、
派閥がいっぱいあって、一般論にならず、まとまらない。

もうオブジェクト指向とか語るだけ無駄だろ。
OOは皆の心の中にある。

0541デフォルトの名無しさん

2010/07/17(土) 21:08:44

広義では情報とそれを操作する手続きを一緒の入れ物に押し込んだものをオブジェクトと呼ぶ。
その上で継承、多態、通信の方法などの個別の拡張で派閥争いがある。

0542デフォルトの名無しさん

2010/07/17(土) 21:49:40

OO言語という道具を使って何を目指すか、次第だと思うけどな。
つまり、OOA/OODのレイヤーから逆算して議論しないとまとまるわけがない。

0543デフォルトの名無しさん

2010/07/18(日) 00:36:22

>>541
> 広義では情報とそれを操作する手続きを一緒の入れ物に押し込んだものをオブジェクトと呼ぶ。
これだと、モジュールやファイルもオブジェクトになるな。
それどころか、static変数を持った関数も。

0544デフォルトの名無しさん

2010/07/18(日) 00:39:54

ところがだ。
歴史上では出て来た順番が逆なもんで、
OOPは独立したもので、OODありきで考えるのは
本質的でないと言う人も居たり。

0545デフォルトの名無しさん

2010/07/18(日) 03:13:40

歴史的にはそうかもしれないが、長年の研究によって考察が深まったのも確かなわけで、
（例えば、オブジェクト指向＝「継承」「現実世界のモノを計算機に写像する方法論」という
考え方は、近年では否定される傾向にある）研究が進んだ結果再整理された、ってことで
いいんじゃないのかな。他のサイエンスでもそういうことはよくある。

0546デフォルトの名無しさん

2010/07/18(日) 05:28:53

微分からネイピア数を定義するようなものか

0547デフォルトの名無しさん

2010/07/18(日) 12:09:00

>>545
現在ではOOPは単なるOO開発手法のサブセットだ、
と言ってる、という理解であってる？

0548デフォルトの名無しさん

2010/07/18(日) 20:00:30

>>547 主旨はそうんなんだろうけどな
OO開発手法が役に立たない局面は山ほどある
# 所詮、数式化出来ない屑が使う手法 > OO開発

0549デフォルトの名無しさん

2010/07/18(日) 20:17:48

Javaで書いてるとOOPしたくなるけど
Dで書いてると「OOPなんていらんかったんや」って気分になる

なんでなんだろうな

0550デフォルトの名無しさん

2010/07/18(日) 21:18:20

慢心・環境の違い

0551デフォルトの名無しさん

2010/07/18(日) 22:52:54

>>548
所詮手法なんだから使えない局面があって当然で、
OOな手法もいくつかある。(RUPとICONIXぐらいしか知らんが)

OOでないのも含め、結局のところ、
いかにシステムの定義をするか、モジュールを分けるかで、
大して良し悪しはないんじゃないかなぁ。
要件によって、向き不向きはある。

0552デフォルトの名無しさん

2010/07/19(月) 09:20:46

このさきRubyはどうなるんだろう。

0553デフォルトの名無しさん

2010/07/19(月) 12:52:38

>>548
人間が一度に見通せる量には限界があるのだよ。
あと、天才一人だけが理解できるシステムも同様の理由で意味がない。
他の人がメンテできないからな。

0554デフォルトの名無しさん

2010/07/19(月) 19:15:00

>>552
本来の勢いに戻るだけじゃね？

0555デフォルトの名無しさん

2010/07/19(月) 19:34:50

Rubyって勢いなくなってるん？

0556デフォルトの名無しさん

2010/07/19(月) 19:40:23

一時期のRailsがもてはやされた頃に比べればな
あの頃がむしろ異常だった

0557デフォルトの名無しさん

2010/07/19(月) 19:46:52

なるほどね。
おれの主観なんだけど、RubyつかうならJavaScript使いたいとおもってしまうぜ。

プラットフォーム間のAPIが整合性をとってくれたり、
サーバーサイドでメジャーなAPサーバがでてくれたりすればなぁ・・・。

0558デフォルトの名無しさん

2010/07/19(月) 22:29:47

>>557
ウェブプログラマｗならそれでいいとおもうぜｗｗ

0559デフォルトの名無しさん

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以下まで落ちるのが先か。

0560デフォルトの名無しさん

2010/07/20(火) 22:32:25

>>559
1%とか誤差じゃね・・・？

0561デフォルトの名無しさん

2010/07/22(木) 22:09:20

OOのここが使えない!!OOはこれだからだめなんだ!!
とかいってないで
やくに立つ部分だけ使えよ。

0562デフォルトの名無しさん

2010/07/23(金) 11:27:26

>>561だよね。

0563デフォルトの名無しさん

2010/07/23(金) 20:40:37

>>561

> OOのここが使えない!!OOはこれだからだめなんだ!!

そういう具体的な指摘がでれば話は進むし、OO言語の改良にもつながると思うが、
今はそもそもOOとは何かでもめて停滞している。

もし，「OOのここが使えない!!OOはこれだからだめ」と感じるところが
あれば書いていってください。

0564デフォルトの名無しさん

2010/07/24(土) 02:58:52

OOPの定義はともかく、OOの方法論はすでに概ね固まってるでしょ。
単に、不勉強な奴が大昔の定義を振り回す奴がいるから議論が混乱してるだけ。
OOは使えないとか言ってる奴は、メイヤーの「オブジェクト指向入門」くらいは当然読んでるよね？

0565デフォルトの名無しさん

2010/07/24(土) 04:32:28

メイヤーの「オブジェクト指向入門」を(まともに)読んだ香具師なら
OOは使えないとか言いださないだろうから

OOは使えないとか言ってる奴は、メイヤーの「オブジェクト指向入門」は当然読んでないと思われ

0566デフォルトの名無しさん

2010/07/31(土) 09:07:30

>>565
読んでる。
が…
声高にOOって喧伝してる奴等に使えない奴が多いから、OOは使えないと言われるんだよ

0567デフォルトの名無しさん

2010/07/31(土) 09:48:08

見やすくてちゃんと動けばoopじゃなくてもいいよ

0568デフォルトの名無しさん

2010/07/31(土) 09:50:27

>>566 おまえが使えない奴だということだけはよくわかった。

0569デフォルトの名無しさん

2010/07/31(土) 18:29:28

またいつものパターンか
この流れもデザパタで定義してくれ

0570デフォルトの名無しさん

2010/07/31(土) 21:03:03

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

0571デフォルトの名無しさん

2010/08/16(月) 20:05:04

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

0572デフォルトの名無しさん

2010/08/16(月) 23:40:46

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

0573デフォルトの名無しさん

2010/08/19(木) 03:03:42

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

0574デフォルトの名無しさん

2010/08/19(木) 06:37:43

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

0575デフォルトの名無しさん

2010/08/19(木) 10:25:42

const だろ

0576デフォルトの名無しさん

2010/08/19(木) 21:51:27

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

0577デフォルトの名無しさん

2010/08/19(木) 23:48:29

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

0578デフォルトの名無しさん

2010/08/20(金) 00:27:55

Smalltalk しようよ!!

0579デフォルトの名無しさん

2010/08/21(土) 02:29:31

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

0580デフォルトの名無しさん

2010/08/21(土) 15:10:48

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

0581デフォルトの名無しさん

2010/08/21(土) 19:46:05

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

0582デフォルトの名無しさん

2010/08/21(土) 19:54:26

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

0583デフォルトの名無しさん

2010/08/21(土) 21:10:01

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

0584デフォルトの名無しさん

2010/08/21(土) 21:14:27

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

0585デフォルトの名無しさん

2010/08/21(土) 21:28:37

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

0586デフォルトの名無しさん

2010/08/22(日) 08:59:59

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

0587デフォルトの名無しさん

2010/08/22(日) 09:39:08

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

0588デフォルトの名無しさん

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

0589デフォルトの名無しさん

2010/08/22(日) 09:54:10

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

0590デフォルトの名無しさん

2010/08/22(日) 11:32:28

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

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

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

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

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

0591デフォルトの名無しさん

2010/08/22(日) 11:58:43

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

0592デフォルトの名無しさん

2010/08/22(日) 17:54:07

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

0593585

2010/08/22(日) 18:05:10

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

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

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

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

0594590

2010/08/22(日) 18:26:20

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

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

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

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

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

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

0595585

2010/08/22(日) 21:05:11

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

0596デフォルトの名無しさん

2010/08/22(日) 21:17:57

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

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

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

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

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

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

0597デフォルトの名無しさん

2010/08/22(日) 21:26:19

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

0598デフォルトの名無しさん

2010/08/22(日) 21:33:47

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

0599デフォルトの名無しさん

2010/08/22(日) 22:37:34

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

0600デフォルトの名無しさん

2010/08/22(日) 22:44:42

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

0601デフォルトの名無しさん

2010/08/23(月) 00:28:41

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

0602デフォルトの名無しさん

2010/08/23(月) 11:10:36

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

0603デフォルトの名無しさん

2010/08/23(月) 12:16:17

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

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

0604デフォルトの名無しさん

2010/08/23(月) 12:44:18

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

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

0605デフォルトの名無しさん

2010/08/23(月) 22:43:08

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

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

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

0606デフォルトの名無しさん

2010/08/23(月) 23:14:56

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

0607デフォルトの名無しさん

2010/08/23(月) 23:31:09

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

0608デフォルトの名無しさん

2010/08/24(火) 00:01:52

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

0609デフォルトの名無しさん

2010/08/24(火) 00:22:49

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

0610デフォルトの名無しさん

2010/08/24(火) 00:36:39

>>608
Pythonは？

0611デフォルトの名無しさん

2010/08/24(火) 00:56:04

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

0612デフォルトの名無しさん

2010/08/24(火) 01:05:18

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

0613デフォルトの名無しさん

2010/08/24(火) 01:06:23

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

0614デフォルトの名無しさん

2010/08/24(火) 07:34:20

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

0615デフォルトの名無しさん

2010/08/24(火) 09:08:50

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

0616デフォルトの名無しさん

2010/08/24(火) 11:47:11

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

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

0617デフォルトの名無しさん

2010/08/24(火) 16:04:49

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

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

0618デフォルトの名無しさん

2010/08/24(火) 19:44:13

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

0619デフォルトの名無しさん

2010/08/24(火) 19:58:56

>>618
それも言語次第。

0620デフォルトの名無しさん

2010/08/25(水) 00:21:10

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

0621デフォルトの名無しさん

2010/08/25(水) 05:56:21

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

0622デフォルトの名無しさん

2010/08/25(水) 09:34:43

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

0623デフォルトの名無しさん

2010/08/25(水) 10:27:15

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

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

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

0624デフォルトの名無しさん

2010/08/25(水) 15:09:33

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

0625デフォルトの名無しさん

2010/08/25(水) 22:16:57

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

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

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

0626デフォルトの名無しさん

2010/08/25(水) 23:08:17

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

0627デフォルトの名無しさん

2010/08/25(水) 23:13:04

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

0628デフォルトの名無しさん

2010/08/25(水) 23:16:57

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

0629デフォルトの名無しさん

2010/08/25(水) 23:18:47

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

0630デフォルトの名無しさん

2010/08/25(水) 23:38:59

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

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

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

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

0631デフォルトの名無しさん

2010/08/25(水) 23:45:58

>>630
やれやれ．．．．

0632デフォルトの名無しさん

2010/08/26(木) 00:35:44

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

0633デフォルトの名無しさん

2010/08/26(木) 01:59:48

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

0634デフォルトの名無しさん

2010/08/26(木) 02:02:39

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

0635デフォルトの名無しさん

2010/08/26(木) 11:00:15

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

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

0636デフォルトの名無しさん

2010/08/26(木) 14:02:18

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

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

0637デフォルトの名無しさん

2010/08/26(木) 19:09:24

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

0638デフォルトの名無しさん

2010/08/26(木) 19:19:05

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

0639デフォルトの名無しさん

2010/08/27(金) 00:02:39

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

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

0640デフォルトの名無しさん

2010/08/27(金) 00:39:03

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

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

0641デフォルトの名無しさん

2010/08/27(金) 21:54:52

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

0642デフォルトの名無しさん

2010/08/27(金) 22:05:39

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

0643デフォルトの名無しさん

2010/08/27(金) 22:25:31

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

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

0644デフォルトの名無しさん

2010/08/27(金) 22:32:28

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

0645デフォルトの名無しさん

2010/08/27(金) 22:51:42

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

0646デフォルトの名無しさん

2010/08/27(金) 22:56:33

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

0647デフォルトの名無しさん

2010/08/27(金) 22:58:54

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

0648デフォルトの名無しさん

2010/08/27(金) 23:15:25

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

0649デフォルトの名無しさん

2010/08/27(金) 23:37:22

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

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

0650デフォルトの名無しさん

2010/08/27(金) 23:48:16

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

0651デフォルトの名無しさん

2010/08/28(土) 00:43:10

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

0652デフォルトの名無しさん

2010/08/28(土) 02:24:10

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

0653デフォルトの名無しさん

2010/08/28(土) 03:22:43

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

0654デフォルトの名無しさん

2010/08/28(土) 06:04:00

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

0655デフォルトの名無しさん

2010/08/28(土) 06:38:23

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

0656デフォルトの名無しさん

2010/08/28(土) 06:44:05

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

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

0657デフォルトの名無しさん

2010/08/28(土) 08:16:43

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

0658デフォルトの名無しさん

2010/08/28(土) 09:16:53

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

0659デフォルトの名無しさん

2010/08/28(土) 09:34:08

FAきたー

0660デフォルトの名無しさん

2010/08/28(土) 10:18:41

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

0661デフォルトの名無しさん

2010/08/28(土) 11:54:26

>>660
>>648

0662デフォルトの名無しさん

2010/08/28(土) 14:49:32

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

0663デフォルトの名無しさん

2010/08/28(土) 15:05:29

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

0664デフォルトの名無しさん

2010/08/28(土) 17:29:23

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

0665デフォルトの名無しさん

2010/08/28(土) 20:55:29

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

0666デフォルトの名無しさん

2010/08/28(土) 21:01:48

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

0667デフォルトの名無しさん

2010/08/28(土) 21:09:42

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

0668デフォルトの名無しさん

2010/08/28(土) 22:33:56

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

0669デフォルトの名無しさん

2010/08/28(土) 23:01:35

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

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

0670デフォルトの名無しさん

2010/08/28(土) 23:22:18

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

0671デフォルトの名無しさん

2010/08/28(土) 23:33:36

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

0672デフォルトの名無しさん

2010/08/28(土) 23:42:37

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

0673デフォルトの名無しさん

2010/08/29(日) 01:35:50

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

0674デフォルトの名無しさん

2010/08/29(日) 02:35:40

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

0675デフォルトの名無しさん

2010/08/29(日) 02:38:27

お前には無理

0676デフォルトの名無しさん

2010/08/29(日) 02:51:03

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

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

0677デフォルトの名無しさん

2010/08/29(日) 09:52:02

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

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

0678デフォルトの名無しさん

2010/08/29(日) 10:39:51

>>675
誰なら可能なの？

0679デフォルトの名無しさん

2010/08/29(日) 12:02:00

うちのセンドーがやる

0680デフォルトの名無しさん

2010/08/29(日) 12:30:06

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

0681デフォルトの名無しさん

2010/08/29(日) 12:39:29

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

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

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

0682デフォルトの名無しさん

2010/08/29(日) 12:41:02

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

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

0683デフォルトの名無しさん

2010/08/29(日) 12:46:22

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

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

0684デフォルトの名無しさん

2010/08/29(日) 12:50:40

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

0685デフォルトの名無しさん

2010/08/29(日) 12:57:05

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

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

0686デフォルトの名無しさん

2010/08/29(日) 13:07:42

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

0687デフォルトの名無しさん

2010/08/29(日) 13:24:12

>>683
一生思ってろｗ

0688デフォルトの名無しさん

2010/08/29(日) 13:50:45

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

0689デフォルトの名無しさん

2010/08/29(日) 13:53:26

> 継承や多態性なんて

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

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

0690デフォルトの名無しさん

2010/08/29(日) 14:01:08

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

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

0691デフォルトの名無しさん

2010/08/29(日) 14:11:13

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

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

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

0692デフォルトの名無しさん

2010/08/29(日) 14:36:14

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

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

0693デフォルトの名無しさん

2010/08/29(日) 14:36:28

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

0694デフォルトの名無しさん

2010/08/29(日) 14:41:16

誤爆け？ｗ

0695デフォルトの名無しさん

2010/08/29(日) 15:00:38

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

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

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

0696デフォルトの名無しさん

2010/08/29(日) 15:36:24

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

0697デフォルトの名無しさん

2010/08/29(日) 16:07:58

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

0698デフォルトの名無しさん

2010/08/29(日) 16:09:56

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

どういう（；＾ω＾）？

0699デフォルトの名無しさん

2010/08/29(日) 16:36:37

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

0700デフォルトの名無しさん

2010/08/29(日) 16:54:22

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

0701デフォルトの名無しさん

2010/08/29(日) 17:24:24

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

0702デフォルトの名無しさん

2010/08/29(日) 17:41:19

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

0703デフォルトの名無しさん

2010/08/29(日) 17:44:49

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

0704デフォルトの名無しさん

2010/08/29(日) 17:48:56

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

0705デフォルトの名無しさん

2010/08/29(日) 17:50:22

>>695
これはひどいなｗ

0706デフォルトの名無しさん

2010/08/29(日) 18:12:40

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

0707デフォルトの名無しさん

2010/08/29(日) 18:20:17

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

0708デフォルトの名無しさん

2010/08/29(日) 18:26:55

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

0709デフォルトの名無しさん

2010/08/29(日) 18:27:54

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

0710デフォルトの名無しさん

2010/08/29(日) 18:31:58

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

0711デフォルトの名無しさん

2010/08/29(日) 18:33:24

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

こうですね

0712デフォルトの名無しさん

2010/08/29(日) 18:43:43

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

0713デフォルトの名無しさん

2010/08/29(日) 19:14:39

>>710
>>703

0714デフォルトの名無しさん

2010/08/29(日) 19:18:32

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

0715デフォルトの名無しさん

2010/08/29(日) 19:18:36

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

0716デフォルトの名無しさん

2010/08/29(日) 19:19:42

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

0717デフォルトの名無しさん

2010/08/29(日) 19:21:40

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

0718デフォルトの名無しさん

2010/08/29(日) 19:21:50

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

0719デフォルトの名無しさん

2010/08/29(日) 19:23:24

その程度ｗ

0720デフォルトの名無しさん

2010/08/29(日) 19:26:38

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

0721デフォルトの名無しさん

2010/08/29(日) 19:30:14

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

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

0722デフォルトの名無しさん

2010/08/29(日) 19:32:50

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

0723デフォルトの名無しさん

2010/08/29(日) 19:35:41

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

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

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

0724デフォルトの名無しさん

2010/08/29(日) 19:40:20

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

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

0725デフォルトの名無しさん

2010/08/29(日) 19:40:51

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

0726デフォルトの名無しさん

2010/08/29(日) 19:41:54

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

0727デフォルトの名無しさん

2010/08/29(日) 19:43:06

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

0728デフォルトの名無しさん

2010/08/29(日) 19:43:32

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

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

0729デフォルトの名無しさん

2010/08/29(日) 19:44:25

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

0730デフォルトの名無しさん

2010/08/29(日) 19:48:00

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

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

0731デフォルトの名無しさん

2010/08/29(日) 19:49:48

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

0732デフォルトの名無しさん

2010/08/29(日) 19:50:03

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

0733デフォルトの名無しさん

2010/08/29(日) 19:51:22

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

0734デフォルトの名無しさん

2010/08/29(日) 19:53:54

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

0735デフォルトの名無しさん

2010/08/29(日) 19:56:21

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

0736デフォルトの名無しさん

2010/08/29(日) 19:59:41

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

0737デフォルトの名無しさん

2010/08/29(日) 19:59:44

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

0738デフォルトの名無しさん

2010/08/29(日) 20:00:40

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

0739デフォルトの名無しさん

2010/08/29(日) 20:01:26

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

0740デフォルトの名無しさん

2010/08/29(日) 20:01:50

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

0741デフォルトの名無しさん

2010/08/29(日) 20:03:04

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

0742デフォルトの名無しさん

2010/08/29(日) 20:03:34

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

0743デフォルトの名無しさん

2010/08/29(日) 20:04:33

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

0744デフォルトの名無しさん

2010/08/29(日) 20:05:03

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

0745デフォルトの名無しさん

2010/08/29(日) 20:11:11

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

0746デフォルトの名無しさん

2010/08/29(日) 20:14:01

>>726
っ『人月の神話』

0747デフォルトの名無しさん

2010/08/29(日) 20:14:49

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

0748デフォルトの名無しさん

2010/08/29(日) 20:15:29

>>747
だな。

0749デフォルトの名無しさん

2010/08/29(日) 20:18:14

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

0750デフォルトの名無しさん

2010/08/29(日) 20:18:47

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

0751デフォルトの名無しさん

2010/08/29(日) 20:21:37

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

0752デフォルトの名無しさん

2010/08/29(日) 20:22:01

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

0753デフォルトの名無しさん

2010/08/29(日) 20:23:16

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

0754デフォルトの名無しさん

2010/08/29(日) 20:25:19

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

0755デフォルトの名無しさん

2010/08/29(日) 21:02:47

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

0756デフォルトの名無しさん

2010/08/29(日) 21:06:51

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

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

0757デフォルトの名無しさん

2010/08/29(日) 21:07:52

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

0758デフォルトの名無しさん

2010/08/29(日) 21:11:28

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

0759デフォルトの名無しさん

2010/08/29(日) 21:14:27

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

0760デフォルトの名無しさん

2010/08/29(日) 21:18:41

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

0761デフォルトの名無しさん

2010/08/29(日) 21:24:22

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

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

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

0762デフォルトの名無しさん

2010/08/29(日) 21:29:53

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

0763デフォルトの名無しさん

2010/08/29(日) 21:40:01

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

0764デフォルトの名無しさん

2010/08/29(日) 21:42:25

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

0765デフォルトの名無しさん

2010/08/29(日) 21:43:03

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

0766デフォルトの名無しさん

2010/08/29(日) 21:44:33

GoF読めばみんな幸せ

0767デフォルトの名無しさん

2010/08/29(日) 21:46:21

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

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

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

0768デフォルトの名無しさん

2010/08/29(日) 21:47:55

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

0769デフォルトの名無しさん

2010/08/29(日) 21:48:31

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

0770デフォルトの名無しさん

2010/08/29(日) 21:49:39

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

0771デフォルトの名無しさん

2010/08/29(日) 21:50:18

>>767に同意だな

0772デフォルトの名無しさん

2010/08/29(日) 21:50:25

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

0773デフォルトの名無しさん

2010/08/29(日) 21:51:36

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

0774デフォルトの名無しさん

2010/08/29(日) 21:52:11

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

0775デフォルトの名無しさん

2010/08/29(日) 21:53:29

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

0776デフォルトの名無しさん

2010/08/29(日) 21:55:40

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

0777デフォルトの名無しさん

2010/08/29(日) 22:00:48

７７７

0778デフォルトの名無しさん

2010/08/29(日) 22:01:48

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

0779デフォルトの名無しさん

2010/08/29(日) 22:06:50

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

0780デフォルトの名無しさん

2010/08/29(日) 22:17:25

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

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

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

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

0781デフォルトの名無しさん

2010/08/29(日) 22:25:50

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

0782デフォルトの名無しさん

2010/08/29(日) 22:28:25

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

0783デフォルトの名無しさん

2010/08/29(日) 22:40:27

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

0784デフォルトの名無しさん

2010/08/29(日) 22:48:56

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

0785デフォルトの名無しさん

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

0786デフォルトの名無しさん

2010/08/29(日) 22:58:01

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

0787デフォルトの名無しさん

2010/08/29(日) 23:00:29

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

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

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

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

0788デフォルトの名無しさん

2010/08/29(日) 23:00:43

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

0789デフォルトの名無しさん

2010/08/29(日) 23:05:52

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

0790デフォルトの名無しさん

2010/08/29(日) 23:11:13

>>785
キチガイｗｗｗ

0791デフォルトの名無しさん

2010/09/02(木) 13:39:09

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

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

0792デフォルトの名無しさん

2010/09/02(木) 13:47:55

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

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

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

0793デフォルトの名無しさん

2010/09/02(木) 14:37:50

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

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

0794デフォルトの名無しさん

2010/09/03(金) 00:06:16

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

0795デフォルトの名無しさん

2010/09/03(金) 01:35:07

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

0796デフォルトの名無しさん

2010/09/03(金) 03:51:28

ん？

0797デフォルトの名無しさん

2010/09/03(金) 04:50:06

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

0798デフォルトの名無しさん

2010/09/03(金) 08:53:37

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

0799デフォルトの名無しさん

2010/09/03(金) 12:34:25

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

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

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

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

0800デフォルトの名無しさん

2010/09/03(金) 13:44:21

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

0801デフォルトの名無しさん

2010/09/03(金) 17:39:36

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

0802デフォルトの名無しさん

2010/09/03(金) 19:07:32

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

0803デフォルトの名無しさん

2010/09/03(金) 22:41:11

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

0804デフォルトの名無しさん

2010/09/04(土) 00:29:40

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

0805デフォルトの名無しさん

2010/09/04(土) 01:14:41

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

0806デフォルトの名無しさん

2010/09/04(土) 01:45:51

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

0807デフォルトの名無しさん

2010/09/04(土) 09:06:33

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

0808デフォルトの名無しさん

2010/09/04(土) 10:41:40

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

0809デフォルトの名無しさん

2010/09/04(土) 15:36:03

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

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

0810デフォルトの名無しさん

2010/09/04(土) 16:40:28

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

0811デフォルトの名無しさん

2010/09/04(土) 19:19:25

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

0812デフォルトの名無しさん

2010/09/04(土) 19:43:58

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

0813デフォルトの名無しさん

2010/09/04(土) 19:58:59

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

0814デフォルトの名無しさん

2010/09/05(日) 00:10:18

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

0815デフォルトの名無しさん

2010/09/05(日) 03:39:55

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

0816デフォルトの名無しさん

2010/09/05(日) 18:26:55

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

0817デフォルトの名無しさん

2010/09/05(日) 18:57:23

>>816
？

0818デフォルトの名無しさん

2010/09/05(日) 19:27:19

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

0819デフォルトの名無しさん

2010/09/05(日) 19:47:39

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

0820デフォルトの名無しさん

2010/09/05(日) 20:05:46

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

0821デフォルトの名無しさん

2010/09/05(日) 20:10:15

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

0822デフォルトの名無しさん

2010/09/05(日) 20:33:41

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

0823デフォルトの名無しさん

2010/09/05(日) 21:04:15

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

0824デフォルトの名無しさん

2010/09/05(日) 21:11:34

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

0825デフォルトの名無しさん

2010/09/05(日) 21:20:15

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

0826デフォルトの名無しさん

2010/09/05(日) 21:40:06

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

0827デフォルトの名無しさん

2010/09/05(日) 21:49:37

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

0828デフォルトの名無しさん

2010/09/05(日) 23:17:48

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

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

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

0829デフォルトの名無しさん

2010/09/05(日) 23:37:54

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

0830デフォルトの名無しさん

2010/09/06(月) 04:05:20

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

0831デフォルトの名無しさん

2010/09/06(月) 06:27:52

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

0832デフォルトの名無しさん

2010/09/06(月) 06:46:57

import *;
とかしてそう

0833デフォルトの名無しさん

2010/09/06(月) 19:12:53

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

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

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

0834デフォルトの名無しさん

2010/09/06(月) 19:17:53

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

0835デフォルトの名無しさん

2010/09/06(月) 19:22:03

ヤムチャなら仕方ない

0836デフォルトの名無しさん

2010/09/06(月) 20:13:45

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

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

0837デフォルトの名無しさん

2010/09/06(月) 21:04:57

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

0838デフォルトの名無しさん

2010/09/06(月) 21:19:41

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

0839デフォルトの名無しさん

2010/09/06(月) 21:23:00

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

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

0840デフォルトの名無しさん

2010/09/06(月) 21:24:07

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

0841デフォルトの名無しさん

2010/09/07(火) 00:11:50

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

0842デフォルトの名無しさん

2010/09/07(火) 00:14:32

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

0843デフォルトの名無しさん

2010/09/07(火) 01:04:18

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

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

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

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

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

0844デフォルトの名無しさん

2010/09/07(火) 06:28:03

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

0845デフォルトの名無しさん

2010/09/07(火) 06:58:56

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

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

0846デフォルトの名無しさん

2010/09/07(火) 07:05:05

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

0847デフォルトの名無しさん

2010/09/07(火) 07:18:36

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

0848デフォルトの名無しさん

2010/09/07(火) 08:01:20

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

0849デフォルトの名無しさん

2010/09/07(火) 08:20:12

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

0850デフォルトの名無しさん

2010/09/07(火) 17:50:29

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

0851デフォルトの名無しさん

2010/09/07(火) 19:46:59

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

0852デフォルトの名無しさん

2010/09/07(火) 19:48:04

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

0853デフォルトの名無しさん

2010/09/07(火) 19:56:23

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

0854デフォルトの名無しさん

2010/09/07(火) 20:01:09

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

0855デフォルトの名無しさん

2010/09/07(火) 20:11:17

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

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

0856デフォルトの名無しさん

2010/09/07(火) 20:42:48

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

0857デフォルトの名無しさん

2010/09/07(火) 20:46:24

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

0858デフォルトの名無しさん

2010/09/07(火) 20:51:25

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

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

0859デフォルトの名無しさん

2010/09/07(火) 20:56:20

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

0860デフォルトの名無しさん

2010/09/07(火) 21:06:32

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

0861デフォルトの名無しさん

2010/09/07(火) 21:27:31

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

0862デフォルトの名無しさん

2010/09/07(火) 21:30:36

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

0863デフォルトの名無しさん

2010/09/07(火) 21:37:50

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

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

0864デフォルトの名無しさん

2010/09/07(火) 21:43:48

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

0865864

2010/09/07(火) 21:55:59

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

0866デフォルトの名無しさん

2010/09/07(火) 22:05:10

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

0867デフォルトの名無しさん

2010/09/07(火) 22:13:17

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

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

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

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

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

0868デフォルトの名無しさん

2010/09/07(火) 22:18:55

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

0869デフォルトの名無しさん

2010/09/07(火) 22:30:04

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

0870デフォルトの名無しさん

2010/09/07(火) 22:36:53

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

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

0871デフォルトの名無しさん

2010/09/07(火) 22:54:25

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

0872デフォルトの名無しさん

2010/09/07(火) 23:00:59

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

0873デフォルトの名無しさん

2010/09/07(火) 23:25:02

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

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

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

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

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

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

0874デフォルトの名無しさん

2010/09/07(火) 23:27:08

問題はstatic変数

0875デフォルトの名無しさん

2010/09/07(火) 23:28:45

いっちゃてるな

0876デフォルトの名無しさん

2010/09/07(火) 23:35:51

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

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

0877デフォルトの名無しさん

2010/09/07(火) 23:47:07

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

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

0878デフォルトの名無しさん

2010/09/07(火) 23:48:42

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

これ都市伝説だろ

0879デフォルトの名無しさん

2010/09/07(火) 23:48:50

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

0880デフォルトの名無しさん

2010/09/07(火) 23:52:46

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

0881デフォルトの名無しさん

2010/09/07(火) 23:57:25

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

0882デフォルトの名無しさん

2010/09/08(水) 00:00:50

>>879
間違いじゃねーし

0883デフォルトの名無しさん

2010/09/08(水) 00:03:23

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

0884デフォルトの名無しさん

2010/09/08(水) 00:04:50

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

0885デフォルトの名無しさん

2010/09/08(水) 00:05:19

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

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

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

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

0886デフォルトの名無しさん

2010/09/08(水) 00:07:47

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

0887デフォルトの名無しさん

2010/09/08(水) 00:08:40

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

0888デフォルトの名無しさん

2010/09/08(水) 00:16:48

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

0889デフォルトの名無しさん

2010/09/08(水) 00:18:14

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

0890デフォルトの名無しさん

2010/09/08(水) 00:22:47

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

0891デフォルトの名無しさん

2010/09/08(水) 00:23:46

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

0892デフォルトの名無しさん

2010/09/08(水) 00:29:49

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

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

0893デフォルトの名無しさん

2010/09/08(水) 00:32:21

機能分割　構造化パラダイム。オブジェクト指向に限らない
隠蔽　モジュール化のパラダイム。オブジェクト指向に限らない
動的束縛　オブジェクト指向と関係してるが、静的束縛のほうが型安全で実行速度も速い
継承　クラスベースに固有の概念。プロトタイプベース涙目。LSPが満たせないのは明らか。後はダイヤモンド継承問題
多態性クラスベースに固有の概念(とwikiにあるが本当か？)。プロトタイプベース涙目
メッセージパッシングプロトタイプベースに固有の概念。クラスベース涙目
デザパタ Lispでは23個のうち16個が空気。元々、こういう個別技術は研究対象にすらならなかった
「もの中心」といえばデータ指向

0894デフォルトの名無しさん

2010/09/08(水) 00:40:58

C#なんかプロトタイプベースな考え方も導入されとるし
完全にOOPってのはこれから消えてくんじゃないかな
やっぱラムダ式とか便利だしもはや必須になりつつある

0895デフォルトの名無しさん

2010/09/08(水) 00:43:42

プロトタイプベースがメリットとはぜんぜん思えない

0896デフォルトの名無しさん

2010/09/08(水) 00:44:23

>その結果、非オブジェクト指向より大規模なソフトウェアを作れます。

問題は、その「大規模なソフトウェア」とやらが、目的の機能、顧客の要求に答えられるものになったかどうか、だ。
もちろん、がんばれば、どうにかなるよ。
でもしんどくね？

オブジェクト指向っていったらアレだろ？
複数のオブジェクトがメッセージという池の中で相互作用しあってどうのこうの。
で、その相互作用の結果が目的の機能/要求を満たしてなきゃならんという遠回り。

俺はね、メッセージの池、それをね、機能って呼んでるの。
機能の池の中にオブジェクトやらデータやらが浮かんでて、
「機能がオブジェクトの性質を決める」
オブジェクトが自分自身の性質を決めるのではなく、
機能が、周りとの関係が、関数というある種のフィルタが、その物の性質を決める。
だってそうだろ、100円を100円たらしめてるのは、100円に100円の機能を持たせているのは、
100円自身ではなく、市場経済の「機能」だろ。100円単体では、それはただの金属の円盤にすぎん。
市場経済の機能が有って初めて100円は100円の意味が出る。
100円というオブジェクトを指向しても何の意味もない。

で、機能ってのは、英語でfunction、つまり関数だっていってるの。関数は何かと何かの関係を定義したもの。
オブジェクトに着眼しちゃいかん。オブジェクトを指向しちゃいかん。
大事なのは、オブジェクトとオブジェクトの間にある見えない何か。
OOな人はそれを「メッセージ」というが、それはおかしい。正しくは「機能/関係」と言うべきだ。
物事はメッセージで動いていない。機能で動いているんだ。

0897デフォルトの名無しさん

2010/09/08(水) 00:46:16

オブジェクト指向言語を感じるのはコンストラクタとアクセス修飾子だな

0898デフォルトの名無しさん

2010/09/08(水) 00:49:53

>>895 俺も今のところそう思ってる。それ系の言語のプロフェッショナルに熱く語って欲しい

0899デフォルトの名無しさん

2010/09/08(水) 00:56:37

だからね、俺はね、常々ね、オブジェクト指向で出来ることは、セッターとゲッター、そいうったアクセサぐらいだといっとるのよ。
それ以上のこと、オブジェクト同士のかかわりやら何やらには、めっぽう無力。
でもね、大事なのは何時でも「機能/他者との関係」なわけ。これはOOPでは解決しない。
そこに注力しなきゃならないのに、OOPに拘ってる意味はもう無くて、
それこそ、継承とか言い出したらもうドツボなんよ。

0900デフォルトの名無しさん

2010/09/08(水) 00:57:41

自演うぜえー

0901デフォルトの名無しさん

2010/09/08(水) 00:59:59

>>899
やばい、俺が考えてたこととかなり同じだ
いや、自演じゃなくてマジで

俺はセッターゲッターすらも認めないけどな

0902デフォルトの名無しさん

2010/09/08(水) 01:00:21

オブジェクトを生成した瞬間から正しい状態になっているというお約束はすごいと思う。

0903デフォルトの名無しさん

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

0904デフォルトの名無しさん

2010/09/08(水) 01:15:48

また馬鹿がきた

0905デフォルトの名無しさん

2010/09/08(水) 01:27:23

>それに必要なオブジェクトを割り出すので目的の実現に関係ない
>オブジェクトは最初から出てきません。

「目的の実現に関係ないオブジェクトが出てくる」なんて、俺一言も書いてねーよ。

0906デフォルトの名無しさん

2010/09/08(水) 02:27:42

>>899
オブジェクト指向にすると問題が発生するのではなく
オブジェクト指向で解決できない問題があるという話ですよね。
非オブジェクト指向でなければならない理由にはならないのでは？
実装継承がコードを理解しにくくする場合があるのは確かですが、
大変有用な情報隠蔽まで一緒に否定する必要はないでしょう。

>>905
ではオブジェクト指向設計でも非オブジェクト指向設計と同じく
必要な関数(メソッド)とデータ(フィールド)しか含まない
ソフトウェアを作成できると考えているんですね。
オブジェクト思考プログラミングの記述が遠回りだという事だけが
オブジェクト指向に否定的な理由なんですね。

あなたはグローバル変数よりローカル変数の方が理解も保守もしやすい
という事はおそらく納得しているはずです。
裸の関数とデータ構造より抽象データ型の方が理解も保守もしやすい
という事をなぜ無視するのでしょうか？

0907デフォルトの名無しさん

2010/09/08(水) 03:13:29

>オブジェクト指向にすると問題が発生するのではなく
>オブジェクト指向で解決できない問題があるという話ですよね。
>非オブジェクト指向でなければならない理由にはならないのでは？

オブジェクト指向で解決できない問題をなぜオブジェクト指向で解決しようとするのかい

0908デフォルトの名無しさん

2010/09/08(水) 06:25:42

わけの判らない抽象化でさらにわけが判らなくなるのは納得しているはずです。
サブクラス化が進んでいくと見通しが悪くなるだけなのも納得しているはずです。
結局必要なのはテンプレートだけでオブジェクト指向なんて糞の役にも立たないことをなぜ無視するのでしょうか？

0909デフォルトの名無しさん

2010/09/08(水) 06:34:57

わけがわからないという意味ではテンプレートはもっとひどい。

0910デフォルトの名無しさん

2010/09/08(水) 06:51:38

C++のバージョンアップによってOOの役立たずはとうの昔に証明されてしまってる
新しいC++は(OOも一応申し訳程度に使える)テンプレートな言語になった
OOは状況を悪化させるだけの存在として忌避されている

0911デフォルトの名無しさん

2010/09/08(水) 06:52:14

確かにOOPは実用的な設計ができるようになるにはかなり経験を要するし
＞わけの判らない抽象化でさらにわけが判らなくなる
なんてのはある程度誰しもが通る道ではあるよな

低レベルの抽象を集めて、より大きな低レベルの抽象を作ってはならないってのは基本だ

0912デフォルトの名無しさん

2010/09/08(水) 07:01:38

糞みたいな設計でも、デバッグの苦痛に耐え抜けばそれなりに動いちゃうのがOOPの印象を悪くしてるよな
「こんな辛いことしなきゃいけないなんてOOPはおかしい」と考えちゃう要因

0913デフォルトの名無しさん

2010/09/08(水) 07:07:10

>>907
オブジェクト指向で解決しようとしてません。
構造化プログラミングは「機能/他者との関係」という問題を解決しませんが、
それは構造化プログラミングを使わない理由にならないというのと同じ話です。

>>908
サブクラス化については確かに多段継承は見通しが悪くなると思います。
しかしオブジェクト指向なんて糞の役にも立たないには同意できません。
１個の関数からだけ見えるローカル変数と同じように
数個の関数からだけ見えるフィールドは理解も保守もしやすいです。
オブジェクト指向のアイデアにはダメな物もあるが
素晴らしい物もあるから全否定すべきでないと考えています。

0914デフォルトの名無しさん

2010/09/08(水) 07:09:56

>>913
だからそれ構造化手法じゃん

小分けにはするだろ？
でもわざわざオブジェクト単位にまとめることになんの意味があるの？
それだとどうしていいの？
ってのが問題であって、小分けにすること自体は議論してないだろ

0915デフォルトの名無しさん

2010/09/08(水) 07:09:57

おーおー言ってれば相手にされた10数年前と今とでは見方が全く違うんだけど
昔の印象しか持てない人がいるわけだ
使う言語によってはOOPでもうまくいってるように見える場合もあるし

0916デフォルトの名無しさん

2010/09/08(水) 07:12:19

当たり前のものになったからな

0917デフォルトの名無しさん

2010/09/08(水) 07:15:32

言葉だけはえらい流行したよな
実態は爆笑もんだが

0918デフォルトの名無しさん

2010/09/08(水) 07:18:21

OOPつっても、普通に機能単位でオブジェクト切り分けていくけど
名前に翻弄されて「これはオブジェクトだからクラスにしないと・・・」とか思ってると破綻する

0919デフォルトの名無しさん

2010/09/08(水) 07:35:36

一時期から登場したデザパタが混乱に拍車を掛けたのは記憶に新しい
昔からあるノウハウを無理にOOに当てはめて広めようとしたので、
わけの判らない新技術として世間に認知された
しかしおーおーにデザパタを加えても何も起きなかった

0920デフォルトの名無しさん

2010/09/08(水) 08:09:22

OOpが役に立たないって　N88BASICでも使ってるのか？

0921デフォルトの名無しさん

2010/09/08(水) 08:17:31

長いこと同じ業界にいると視野が狭くなるんだよな

0922デフォルトの名無しさん

2010/09/08(水) 09:29:27

>>878
ENIAC のことを指してるなら都市伝説ではないが。

0923デフォルトの名無しさん

2010/09/08(水) 20:22:28

オブジェクト指向の欠点
・オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。
・将来拡張するか分からないのに、作成時から拡張性を意識した作りにしないといけない。（作成時では必要のない機能を実装している）
・構造が複雑なので、理解しにくいソースになる。本来ブラックボックスとして使うべきだが仕様書の不備や
Chain of Responsibility/Compositeパターンなどオブジェクト同士の関係性が強いオブジェクト群を修正するときにソースの理解が必要になる。

0924デフォルトの名無しさん

2010/09/08(水) 20:42:05

>オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。
ポインタ全否定派ですか？

0925デフォルトの名無しさん

2010/09/08(水) 20:45:12

OOPかどうかの基準ははっきりしない。
・オブジェクト指向型言語を使ったらOOPというわけではない。
・クラスを使ったらOOPというわけではない。

だけど、人がみるとなんとなくOOPかどうか見分けがつく。
不思議だ。

0926デフォルトの名無しさん

2010/09/08(水) 20:51:03

>>923
タイトルを

構造化手法の欠点

にしてもなんら違和感を感じない

0927デフォルトの名無しさん

2010/09/08(水) 20:59:46

お前の中ではそうなんだろうな。

0928デフォルトの名無しさん

2010/09/08(水) 21:18:52

>>924
>ポインタ全否定派ですか？
意味が分からない。

>>926
>構造化手法の欠点
>にしてもなんら違和感を感じない
なぜ、インスタンスが構造化手法なんだ？
もしかして、インスタンスの意味が分かってない？

0929デフォルトの名無しさん

2010/09/08(水) 21:36:17

>>928
インスタンスがスタックに置かれると思ってんの？

0930デフォルトの名無しさん

2010/09/08(水) 21:51:02

インスタンスが存在するものしか使用できないのは、手続き型言語一般の問題で、OOP特有の問題じゃないって言いたいんでしょ。
たしかにそりゃそうだ。

0931デフォルトの名無しさん

2010/09/08(水) 21:51:56

日本は、領土はとられまくり。ガスも抜かれまくり。
国内の政治は韓国人に支配されちゃったし、
国民の金はパチンコ屋経由で朝鮮半島に抜かれまくりだし、
国民が信じる新興宗教は韓国資本だし、
国民が熱狂するアイドルは韓国人。
いや～、もはや形無しですなあ。

0932デフォルトの名無しさん

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日､日曜日予定
場所は中国大使館前

0933デフォルトの名無しさん

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

0934デフォルトの名無しさん

2010/09/08(水) 22:26:33

しかし、関数には引数渡すわけだろ？
引数が無いと関数呼べないわな。だから、引数に渡すべきものが存在している関数しか呼べないわな。

え、引数なしの関数？
それはOOPではスタティックなクラスメソッドになるから、OOPでもインスタンスの有無関係なく呼べるわな。

お前アホだろ。OOP否定派の俺から見てもアホだ。

0935デフォルトの名無しさん

2010/09/08(水) 22:27:57

めんどくせー奴だな
構造化でも参照型は使うだろが

Null参照でエラー出したことないのか？

0936デフォルトの名無しさん

2010/09/08(水) 22:29:32

アホはほっとけ。無駄にスレが流れるだけだ。

0937デフォルトの名無しさん

2010/09/08(水) 22:33:48

もうすぐ堕ちるな

0938デフォルトの名無しさん

2010/09/08(水) 22:36:51

クラスって単に小さなプログラム単位でしか無いのに
なんでOOP目の敵にする奴がたまにいるのか謎だな

0939デフォルトの名無しさん

2010/09/08(水) 22:36:52

ぬるりでいいだろ

0940デフォルトの名無しさん

2010/09/08(水) 22:39:30

>>983
害悪でしかないから～

0941デフォルトの名無しさん

2010/09/08(水) 22:45:00

>>938
それはね、継承やらポリモやら言い出した奴が居るから。
OOPから継承とポリモ取ったら、ちょうどいい感じ。
ただ、それだったらCで良いやって話も。

オーバーロードとテンプレートの相性は抜群で強力だから、
継承やらポリモやらは捨て去って、そっち方面で煮詰めたほうが良いだろうな。

あれだな。
C言語 + マルチメソッド + 型推論
で、手続き型言語はFAじゃね。

ただ、関数型言語のアイデアも取り入れたいしなぁ。
誰か綺麗に纏め上げてくれんかなぁ。

0942デフォルトの名無しさん

2010/09/08(水) 22:51:35

>>941
マルチメソッドも型推論も多態性を実現するためのものだと思うんだが。
多態以外で有効な使い道があるなら教えて(煽りじゃなく純粋な疑問)

0943デフォルトの名無しさん

2010/09/08(水) 22:52:59

仮想関数は重いからダメ

0944デフォルトの名無しさん

2010/09/08(水) 22:54:58

C#でFAだろ

0945デフォルトの名無しさん

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

こんなノリで。

0946デフォルトの名無しさん

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

0947デフォルトの名無しさん

2010/09/08(水) 23:09:08

型推論があればタイプ量が減る。これは大切なこと

0948デフォルトの名無しさん

2010/09/08(水) 23:09:30

auto *p;
*p = &a;
*p = &b; // ここでエラーになるのが普通じゃないの

0949デフォルトの名無しさん

2010/09/08(水) 23:16:06

>>948
基底型無しでポリモするには、どうしても、何でもありの自動型無しポインタが必要なんだよ。
auto *p; としたとき、pはどんな型のポインタも取りえるとしないと、ポリモが絶対に出来ない。
void *p;　と違う点は、auto *p;　は、今自分自身が指してる対象の型を動的に判断できる点。
それに基づいて、マルチメソッドするのな。

やりすぎ感はあるから、やっぱポリモはいらないかもな。
型推論とオーバーロードだけでも十分強力だしな。それに静的で安全だし。
マルチメソッドは実行コストがえらいことになるしな。

0950デフォルトの名無しさん

2010/09/08(水) 23:27:22

定数でないならならない

0951デフォルトの名無しさん

2010/09/08(水) 23:35:31

タイプ量とか一番どうでもいい

0952デフォルトの名無しさん

2010/09/08(水) 23:40:06

c++って唯一メモリー管理可能なOOP言語だけど
なぜあんなに地雷埋めるんだろうね、。

0953デフォルトの名無しさん

2010/09/08(水) 23:49:51

禿だからさ

0954デフォルトの名無しさん

2010/09/09(木) 00:02:28

DだってObj-Cだってメモリ管理可能だぞ

0955デフォルトの名無しさん

2010/09/09(木) 00:07:50

Objective-Cでどうやってメモリ管理するの？

0956デフォルトの名無しさん

2010/09/09(木) 00:10:48

malloc

0957デフォルトの名無しさん

2010/09/09(木) 00:12:23

それじゃCじゃん

0958デフォルトの名無しさん

2010/09/09(木) 00:23:55

まあ、継承より任意の関数ぶち込めるプロトタイプベースなクラスの方がモダンだよなあ

0959デフォルトの名無しさん

2010/09/09(木) 00:24:19

え？

0960デフォルトの名無しさん

2010/09/09(木) 00:27:19

javascriptの亜種って出てこないのかな
goとかみたいな

0961デフォルトの名無しさん

2010/09/09(木) 00:39:41

タイプ量とかほざいてんのは間違いなく低脳ruby厨だろうな

0962デフォルトの名無しさん

2010/09/09(木) 01:08:29

上のポリモーフィズムの議論とかは型システムがあれば出来るわけで
型推論の有無は関係ない
templateにはメリットがあるかもしれんが、
そういうのはtemplate内でやってくれる。現行C++でも関数テンプレートは既に一部推論する
だから、基本的にはタイプ量が減るぐらいのもん

StreamBufferedReader = new StreamBufferdReader();
こんなコードを書くのはアホみたい

0963デフォルトの名無しさん

2010/09/09(木) 04:43:28

C++コンパイラ作ろうとすればはっきり判ると思うけど、
式単位では局所的な型推論は入ってるんだよね

0964デフォルトの名無しさん

2010/09/09(木) 12:23:31

>>961
C#のvarとか便利だよ。
右辺でわかってることを左辺に書くのとかめんどいよ。

0965デフォルトの名無しさん

2010/09/09(木) 14:31:05

構造化プログラミング
オブジェクト指向

次はなんだろう

0966デフォルトの名無しさん

2010/09/09(木) 14:45:30

オレオレ至高プログラミングだな。

0967デフォルトの名無しさん

2010/09/09(木) 19:27:19

アスベスト志向

0968デフォルトの名無しさん

2010/09/09(木) 19:28:30

アスベスト志向

0969デフォルトの名無しさん

2010/09/09(木) 21:13:05

アスベスト施工

0970デフォルトの名無しさん

2010/09/09(木) 21:35:31

>>960
Rhinoがあるじゃないか

0971デフォルトの名無しさん

2010/09/09(木) 22:30:15

次は0xだろ

0972デフォルトの名無しさん

2010/09/09(木) 23:10:53

>>934
>お前アホだろ。OOP否定派の俺から見てもアホだ。
だろうな、お前はまったくオブジェクト指向が理解出来ていない。

>>935
>構造化でも参照型は使うだろが
>Null参照でエラー出したことないのか？
インスタンスと言っているだろう、本当にオブジェクト指向が分かってないな。
お前の構造化は全て参照型で関数呼び出すのか？
お前は、構造化も分かってないだろう。

0973デフォルトの名無しさん

2010/09/09(木) 23:13:05

OO知らんアホに熱くなるなよｗｗｗ

0974デフォルトの名無しさん

2010/09/09(木) 23:15:10

いや、構造化も怪しいぞｗ
とにかく、バカには近寄るなｗｗｗ

0975デフォルトの名無しさん

2010/09/09(木) 23:23:58

まるでわかってるような口ぶり

0976デフォルトの名無しさん

2010/09/10(金) 01:01:28

>>972
通りすがりだけど
お前のOOPは全てクラス型でメソッド呼び出すのか？
お前は、自分が何を言ってるかも分かってないだろう。

OOPではプリミティブ型の引数を取るメソッドは禁止とか初耳。
JAVA超涙目

0977デフォルトの名無しさん

2010/09/10(金) 01:21:03

>>972
>>935は>>923の
>オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。

に対する反論だよ

あとインスタンス＝関数だと思ってない？
一連のレス読んでるとそんな感じがするんだけど

0978デフォルトの名無しさん

2010/09/10(金) 01:53:29

昔の人はオブジェクト指向なんてなくてもちゃんとしたプログラムを作れた

オブジェクト指向を知らなかった優秀な人が作ったプログラム>>>>>>>>>>>>>>>>オブジェクト指向をちゃんと勉強したことのある無能が作ったプログラム

オブジェクト指向はあると便利だがなかったからといって困るものじゃない

0979デフォルトの名無しさん

2010/09/10(金) 05:45:53

>>987
構造化手法以前もちゃんとしたプログラムは作れました
以下略

0980デフォルトの名無しさん

2010/09/10(金) 06:37:44

電鋸あるんだから使えよ

0981デフォルトの名無しさん

2010/09/10(金) 06:39:18

BTTB
すなわちBASICの時代に戻るのだ・・・

0982デフォルトの名無しさん

2010/09/10(金) 06:40:22

>>976
>お前のOOPは全てクラス型でメソッド呼び出すのか？
だから、「オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。」
と書いているだろう。関数と違ってオブジェクトを使う場合は存在チェックが必要だと書いている。

>>977
>あとインスタンス＝関数だと思ってない？
思ってないが、何を読めばそう思えるんだ？
関数は静的造られるし、オブジェクトは動的に造られる。
このオブジェクトの実体をインスタンスと言うんだ。

この「オブジェクトを使うにはインスタンスの存在確認が必要」は
マーチンやケントなど、オブジェクト指向の巨匠たちも頭を痛めた問題だ。
こんな一般的な欠点も理解出来ないとは。

0983デフォルトの名無しさん

2010/09/10(金) 06:41:15

プログラマが言語に合わせるのではなく
言語がプログラマに合わせるのだ

0984デフォルトの名無しさん

2010/09/10(金) 06:49:31

>>982
ポインタと動的確保について調べてから書き込むように
それでもわかんないんなら
どっかのC++スレで>>923と同じ主張をしてきなさい
みんなが親切におしえてくれるから

0985デフォルトの名無しさん

2010/09/10(金) 07:05:44

つーか、ポリモが特に必要ないのに継承するからコードがぐちゃぐちゃになるんだろ
設計できないのをOOPのせいにしてはいけないよ

0986デフォルトの名無しさん

2010/09/10(金) 07:56:39

>>982
> 関数は静的造られるし、オブジェクトは動的に造られる。

first-class objectとしての関数は無視ですかそうですか。

あと、君って相変わらず
　機能 = 手続き型の関数（≒サブルーチン） = 数学の関数（≒純粋関数型の関数）
だと思ってない？

0987デフォルトの名無しさん

2010/09/10(金) 08:07:27

> この「オブジェクトを使うにはインスタンスの存在確認が必要」は

Option型とパターンマッチング。

そもそも、データの中身やオブジェクトの状態が正しいかどうかをチェックするのは、
プログラミングの基本的な作法だ。君はそういうのを軽視する人なのかもしれないが。

0988デフォルトの名無しさん

2010/09/10(金) 08:18:01

>>982
言語にもよるが、インスタンスに依存しないなら、
staticでも付けとけよ。

0989デフォルトの名無しさん

2010/09/10(金) 10:05:13

人が火を使うとき、わりと慎重になる。
原子力を使うとき、もっと慎重になる。

OOPはもっと慎重に扱うべきだったのかもしれない。
ホビーユーザが犬猫動物で覚えて使って火傷、
中級ユーザが中規模プロジェクトに使って焼死。

0990デフォルトの名無しさん

2010/09/10(金) 10:35:18

クラスや継承がなかったときはどうしてたんだろう

ほとんど同じだけど、微妙に違う構造体
みたいなのがいくつかあったら継承便利だと思うんだが。

0991デフォルトの名無しさん

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;

0992デフォルトの名無しさん

2010/09/10(金) 10:48:34

unionも便利だったけど
逆にclass使うとunion使わなくなるんだよな
なんでだろ

0993デフォルトの名無しさん

2010/09/10(金) 10:59:13

そりゃunionよりもクラスの方がswitch文不要で便利だからだろう

0994デフォルトの名無しさん

2010/09/10(金) 11:37:43

それは継承とポリモフィズムのことか？
テンプレ/GENERICSじゃなくて？

0995デフォルトの名無しさん

2010/09/10(金) 12:20:03

だから！遅すぎたと言っているんだ！

0996デフォルトの名無しさん

2010/09/10(金) 12:21:46

押尾学指向

0997デフォルトの名無しさん

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

0998デフォルトの名無しさん

2010/09/10(金) 12:57:57

23万人だってよ
http://www.yomiuri.co.jp/national/news/20100910-OYT1T00389.htm
http://www.youtube.com/watch?v=1iOJ8kWQyqc

0999デフォルトの名無しさん

2010/09/10(金) 12:59:19

http://www.youtube.com/watch?v=z2_4DG-sRDU

1000デフォルトの名無しさん

2010/09/10(金) 13:01:01

http://www.youtube.com/watch?v=8yyYE4wy07o

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。