トップページ⇒tech
1001コメント409KB

OOP 2

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/11/10(水) 22:51:25
前スレのあらすじ

OOPってよくわかんないよね

http://hibari.2ch.net/test/read.cgi/tech/1284115490/
0159デフォルトの名無しさん2010/11/18(木) 00:18:00
それから、向こうのスレの人は俺しらねーぜ。
そのスレ自体しらん。今から読んでくる。

・・・読んできた。

リファクタリングの本だけ読んだことあるなぁ。
えらい分厚いくせに、そのほとんどがコード例で、しかも当たり前のことしか書いてない奴。
たしか、結構なお値段だったような。俺は研究室に置いてあったから、タダ見だが。
読まなくても解ってる奴は解ってるし、
解ってない奴は、読んでも解らん。そんな類の本だった記憶が。

あ、Rubyは美しいとか言ってるw

Pythonねぇ。selfはキモイだろう。
構造体にCスタイルの関数を突っ込めます。第一引数は自動でわたりますってアイデアは悪くないのだが、
なにか釈然としない。

全部読むと頭がおかしくなるからもう読まない。大分マズイ方向へ行ってる人だね。
0160デフォルトの名無しさん2010/11/18(木) 00:22:06
>>150
>>148で上げたデモで、まったくそのまま、それをやってるよ。
テーブル用意して変換してる。
0161デフォルトの名無しさん2010/11/18(木) 04:06:17
なんかOOPって深くやればやるほどめんどくさくなるよねえ。
再利用とか隠蔽なんかしなくていいから、俺はパッと見てわかりやすいソフトが作れればいいや。
0162デフォルトの名無しさん2010/11/18(木) 07:45:54
>>161
Prolog
0163デフォルトの名無しさん2010/11/18(木) 07:48:15
>>161
LISP
0164デフォルトの名無しさん2010/11/18(木) 08:17:38
>>161
規模の大きなソフトウェアや、メンテナンス時に地獄を見る発想。
0165デフォルトの名無しさん2010/11/18(木) 09:15:22
俺はパッと見てわかりやすくするための、
隠蔽なんだがｗ
で、それをするってことは、その単位が再利用しやすくなってるわけで。
0166デフォルトの名無しさん2010/11/18(木) 10:06:51
さんざんテンプレートやら型推論、ダックタイピングがどうのこうの言ってたのに
いまさらパッと見で分かりやすいとか言われてもね
0167デフォルトの名無しさん2010/11/18(木) 10:26:52
本当は静的型とOOPは互いに独立したモジュールであるべきだった
しかし、言語レベルでOOPをサポートし、それをしない言語との差別化をはかるために
静的型レベルのOOPが生まれた
0168デフォルトの名無しさん2010/11/18(木) 11:06:12
>>167
ALGOLで十分だったということかな？
0169デフォルトの名無しさん2010/11/18(木) 11:07:01
しかしjavaもc++もobjective-cもだいたいマルチパラダイム
01701682010/11/18(木) 11:10:03
すみません。誤爆です。
http://hibari.2ch.net/test/read.cgi/tech/1286791669/382
　へのレスでした。
0171デフォルトの名無しさん2010/11/18(木) 21:26:49
ぱっと見てわかりやすい云々はいつもの人が言ったんじゃないから。

それはそうとして、コード上げたら叩かれなくなった。
やっぱ手を動かした人は批判の対象になりにくいのな。
何事も口先だけじゃダメってことか。

そんで、色々考えたんだけど、
ポインタ代入時にいちいち型値変換するのもあれだなぁと。
だから、
auto *p;
p = (a*|b*);
p = (b*|c*);
のとき、pの型は、(a*|b*|b*|c*)と推論されることにしようと思う。
この場合、b*が重複してて、その分関数テーブルが少しでかくなるが、
型値変換を単なるオフセット計算で済ませられるのは美味しい。

それから、共用体風に拡張できるのもポインタに限定してしまおうと思う。
だから、(a*|b*)じゃなくて、(a|b *)になる。
ポインタの指す型は複数ありえますよって意味合い。

そんで、型持ちポインタと普通のポインタも明確に区別したい。
だから、型持ちポインタは*でなくて、@を使おう。
auto *p; //型自動の普通のポインタ。推論される型が複数ある場合はコンパイルエラー。普通のポインタ。
auto @p; //型自動の型持ちポインタ。推論される型が複数でもOK。
とてもわかりやすくなったね。

あんま複雑なことしても意味ないし、これで十分かな。
0172デフォルトの名無しさん2010/11/18(木) 21:28:37
>>170
どこも同じようなことやってんだな
0173デフォルトの名無しさん2010/11/19(金) 00:37:03
>>171
> それはそうとして、コード上げたら叩かれなくなった。
> やっぱ手を動かした人は批判の対象になりにくいのな。
> 何事も口先だけじゃダメってことか。

だから最初からずーっと言われてたろ。仕様書上げろって。
プログラマにとってはコードや仕様書が何より説得力のある言葉なの。
0174デフォルトの名無しさん2010/11/19(金) 06:34:41
>>164
作る機能単位ごとに分割して作れば規模が大きかろうと小さかろうと別に地獄など見ませんが。
バグがあってもどの機能の中のどの部分かは仕様で決めてあるので場所を絞り込めるし。
OOP以前から普通にやってたことだと思いますけどね。
0175デフォルトの名無しさん2010/11/19(金) 07:06:58
>>174
上2行はOOPでやればよりやりやすいというだけ

批判派の人はよく「OOP以前もやってた」というけど
OOPはOOP以前の手法を土台にしてるんだからあたりまえのこと
0176デフォルトの名無しさん2010/11/19(金) 07:30:45
>>174
> バグがあってもどの機能の中のどの部分かは仕様で決めてあるので場所を絞り込める
簡単に書いちゃってるけどすっげー難しいんじゃね？
0177デフォルトの名無しさん2010/11/19(金) 09:26:44
>>175
機能単位に分割するのと、オブジェクト単位に分割するのは
まったくの思想ではないか。
01781772010/11/19(金) 09:28:10
"別の"思想
0179デフォルトの名無しさん2010/11/19(金) 20:04:31
>>174
マジレスすると機能単位はシステム工学で一番やっては駄目な方法。
システム工学では機能単位では無くデータ単位に行なうが良いとされている。
オブジェクト指向はもちろんデータにそれ専用の機能だが
構造化でもPOAよりDOAが優れている。
0180デフォルトの名無しさん2010/11/19(金) 20:28:49
>>177
「機能単位」の粒度にもよるけど
まったく別ってことはないと思うな
0181デフォルトの名無しさん2010/11/19(金) 21:44:25
>>179
>>164 をどのように評価するかだ。
大きいことが悪いのだ、という評価もあるわけだから。
0182デフォルトの名無しさん2010/11/19(金) 21:58:08
>>171
何傘？
結局のとこItumono人がItumono語の初心者から初級者への道を一歩進んだだけやん。
>>132まで戻って実体の多重継承はItumono人が理解できる段階に進んだだけで何か解決したこと無いし。
注意して使えば問題ない？C++が多重継承を残してるのは注意して使えば問題ないからやの。

れとも実体の継承を禁止、
f(A*);
f((B|C*));
g((A|B|C*)p){
　f(p);
}
を禁止してるのか知らん。
0183デフォルトの名無しさん2010/11/19(金) 22:29:43
>>173
sys.environment.value["PATH"] += ";C:\hoge\lib";
append(find(value(environment(sys)), "PATH"), ";C:\hoge\lib");
え〜173は下派に鞍替えったの？
0184デフォルトの名無しさん2010/11/19(金) 23:10:41
>>171
言葉で言っても理解できないじゃんあんた。

auto fp = ((HogeA|HogeB|HogeCInDllWhichCreatedAfterThisProgramCompiled*)(*)())dlsym(dll, "func");
これは無理で
auto fp = (auto@(*)())dlsym(dll, "func");
auto@で受けなければならないとはわかるな。じゃあ

auto f1p = (auto@(*)())dlsym(dll, "f1");
auto f2p = (void(*)(auto@))dlsym(dll, "f2");
f2p(f1p());
変換テーブルを作ってみろ
0185デフォルトの名無しさん2010/11/19(金) 23:52:50
>>158
>逆共用体化演算子
ダウンキャスト言え。
>ロード時にリンクエラーやらなんやら事前に調べてくれたほうがプログラマは嬉しいだろう。
実行時の自己書き換えやテーブルでCPUキャッシュを使い込むのをやめてくれたほうがうれしい。
0186デフォルトの名無しさん2010/11/20(土) 00:07:28
大卒！？論文を読み論文を書くことが教えられる場所にいてああなの？
OO、生産性やソフトウェア工学のの論文や研究者なんて山ほどあるだろに。
あんたにとって教授の言ったことが全ての世界なの？

OOはメッセージングである、という世界しか知らずに育ち、
その外側では過ごしたことが無くほとんど知らないから、
前スレでは藁人形叩きをやって、ポリモとかいう誰も使わない省略形を使って、
>>183の下派なのか。
子供なら社会の被害者とかいうけども、もう一介の社会人なんだからただの
0187デフォルトの名無しさん2010/11/20(土) 02:12:54
>>184
まず初めに断っておくけど、
関数を一つ一つ手動でロードするスタイルはとらないつもり。
load_lib( "lib.dll" );
こんな感じで一気に全部読み込む。
そんで、プログラムを再リンクする。そのとき、変換テーブルや関数テーブルも拡張する。
だから、ごく軽い再コンパイルのようなことが起こる。
ので、dllからのロードだからって、変な制限とかが付くことは無い。
だって、最コンパイルするんだからな。ある意味なんでもあり。
といっても、コードを最コンパイルする訳ではないぞ。あくまで、各種テーブルを拡張するだけ。すぐ終わる。
だから、再リンクと言ったほうが適切だな。
再リンクに必要な型推論の型の伝達関係は、予めdllに仕込む。
Itumono仕様のdllには何か特殊な環境取得関数が仕込まれてて、
load_libはそれを呼び出して、型の伝達関係etcをもらう。
環境取得関数の無いItumono仕様でないDLLをload_libすると失敗する。
Itumono仕様でないDLLはCスタイルで読み込むことになる。
その場合は型推論やポリモは適用されない。問題ないだろう。
0188デフォルトの名無しさん2010/11/20(土) 04:12:40
俺にはまるでわけわかめ
0189デフォルトの名無しさん2010/11/20(土) 06:23:59
もう一週間終わっちまったぜ
0190デフォルトの名無しさん2010/11/20(土) 20:02:26
プロトタイプベースはクラスの概念ないってよく聞くけど
継承の仕方が特殊なだけでクラスは使ってるよね

プロトタイプベースの言語はjavascriptしかしらんけどさ
0191デフォルトの名無しさん2010/11/20(土) 20:32:30
そりゃ概念は言語とは無関係だからな
0192デフォルトの名無しさん2010/11/21(日) 00:19:29
>>190
プロトタイプを使ってるからクラスは確かに存在しないはずだが
0193デフォルトの名無しさん2010/11/21(日) 08:30:49
>>192
クラスそのものとまでは言わないけど
（javascriptの）コンストラクタはクラスみたいなものでしょ
0194デフォルトの名無しさん2010/11/21(日) 08:39:59
似てるってことは違うってことじゃん？
0195デフォルトの名無しさん2010/11/21(日) 10:27:44
>>193
う〜ん、似てるようでもやっぱ根本が違うと思う。
コンストラクタは、使い方がクラスみたいなだけで
クラスと違って設計図そのものでは無いんだよね。
設計図そのものは親のインスタンスに求める感じ。

ttps://developer.mozilla.org/ja/Core_JavaScript_1.5_Guide/Working_with_Objects
ttps://developer.mozilla.org/ja/Core_JavaScript_1.5_Guide/Details_of_the_Object_Model
0196デフォルトの名無しさん2010/11/21(日) 11:55:28
>>195
>設計図そのものは親のインスタンスに求める
継承してるインスタンスはこのイメージですんなり納得できる

でも継承元のインスタンスを作るときは構成を書き出さなきゃならんわけでしょ？
呼び名が違うだけで「オブジェクト初期化子」も「コンストラクタ関数」も
クラスと(設計図としての)役割は変わらないと思うんだよね

もちろんクラスそのものじゃないから、いろいろ違いがあるのはわかるけどさ
0197デフォルトの名無しさん2010/11/21(日) 13:17:00
>>196
ちょっと暴論かなぁ、と思う。

JSはそれほど知らないんんで間違えてるかもだけど、
JSのコンストラクタは手続きを記述出来るだけで型を定義しない。
クラス構文は型を定義する。

JSのコンストラクタ(等？)を使ってプログラマはオブジェクトに
クラス型を持っているかのような振る舞いをさせることができるけど、
クラスに関する言語のサポートはなくて、自前で実装する必要がある。
0198デフォルトの名無しさん2010/11/21(日) 14:05:01
結局クラスまわりの構文さえサポートすれば、
実装が連想配列のコピーでもクラスベースな気がする
0199デフォルトの名無しさん2010/11/21(日) 14:53:58
それはその通りでしょ。
言語のパラダイムはソースコード上の表現の話で、
処理系の実装は関係ない。
0200デフォルトの名無しさん2010/11/21(日) 16:44:41
クラスﾍﾞｰｽ言語の利点としてメタクラスが使える。
クラスの概念があるからメタ化出来る。
これによりオブジェクトを高度に抽象化出来る。

これがプロトタイプベース言語では出来ないと思っているが
俺が知らないだけで出来る言語もあるかもしれないが。
（インタプリタは言語の仕様上難しいような気がする）

クラスはオブジェクトを作るだけじゃなく高度な多態性を提供してくれている。
0201デフォルトの名無しさん2010/11/21(日) 17:18:56
まーどうでもいいよね。
メタ化は研究者のオナニーみたいなもんだし。
0202デフォルトの名無しさん2010/11/21(日) 18:29:46
プロトタイプベースのクラスベースに対する最大の差異は、
「制約がつけられる」か否か、なのではないの？
0203デフォルトの名無しさん2010/11/21(日) 18:33:43
メタ化は、javascriptを出力するcgiみたいに、文字列ベースでやるのが一般的。
OOPはなぜか文字列を敵視したり型理論を信奉したりしている。
0204デフォルトの名無しさん2010/11/21(日) 18:41:34
>>203
その理屈で行くと、既存の処理系の上に俺言語的(DSL?)なものを構築するのもメタって言うのかなぁ。
0205デフォルトの名無しさん2010/11/21(日) 19:00:15
>>204が何をイメージしているのか良く分からないけど、
「メタプログラミング」っていう言葉はあるよ。
0206デフォルトの名無しさん2010/11/21(日) 23:42:35
まーC言語も機械語に対するメタ言語だしな。
メタプログラミングって何の意味も持たない言葉だな。
文字列ベースのメタプログラミングの話が出てたけど、
Cのマクロって確かに便利なんだよな。なんでもありで。その分危険だが。
そして誰も興味ないよ、この話題。
どうせ、メタ言語の、そのまたメタ言語も必要かどうかって話になって終わるに決まってる。
0207デフォルトの名無しさん2010/11/22(月) 00:12:22
>>203
メタっちゃメタなのかもしれんが, 手法的には全然柔軟性に欠るよな.
新しいシンタックス導入するの大変だし...
CL や scheme の macro は文字列ベースじゃないけど, 遥かに柔軟で扱いやすい

>>204
メタの定義をプログラムを吐き出すプログラムって意味とするなら, メタじゃないか?

>>206
抽象化されたアセンブラでって意味ならそうだが， メタプログラミングとは言わんと思う

C++ のテンプレートメタプログラミングなんて, とても涙ぐましい努力をしていると思う
# メタプログラミングにマッチした文法じゃないんだよ, 手続き型ベースの言語は...
0208デフォルトの名無しさん2010/11/22(月) 00:24:56
メタプログラムとメタクラスは別物なんだが。
0209デフォルトの名無しさん2010/11/22(月) 00:51:44
メタプログラミング＝プログラムを生成するプログラム
通常はコンパイル時の問題、少なくとも
トランスレータ、マクロやテンプレートのようなものを利用したものはそう

メタクラスはただのクラスのクラス、クラスはメタクラスのインスタンス
実行時のオブジェクトとして普通に扱えるもの

メタとか言っても全然違いますよ
Lispは強力なマクロ（メタプログラミングの道具）を備えていると同時に
メタオブジェクトプロトコルも備えている

Javaや.NETのような言語のごく普通のユーザも、リフレクションや
イントロスペクションの恩恵に当たり前に浴している
別になんも難しくも無いし怖くも無いよ
0210デフォルトの名無しさん2010/11/22(月) 01:07:38
>通常はコンパイル時の問題
とは書いたけど、勿論実行時のメタプログラミングも可能で
evalがあればごく簡単

Cのような言語では、実行可能なメモリ領域に機械語を書き込むような形になるけど

そうそう、データについてのデータをメタデータと言いますね
0211デフォルトの名無しさん2010/11/22(月) 04:01:14
モノに指示を与える概念で書ければわかりやすいよというシンプルな話だったはずなのに
いつの間にか仮想とかメタとかめんどくさいものになってしまった。
こんなんじゃこれ以上普及するはずがない。
0212デフォルトの名無しさん2010/11/22(月) 04:22:43
めんどうくさいことになったのは、元の発想が間違っていたからかもしれない、と気づけるかどうかだな。
設計屋してたらわかるでしょ。変な事したら面倒なことになってくって。
もっとシンプルでも誰も困らないのにな。
どうしても本を売りたいらしい。
0213デフォルトの名無しさん2010/11/22(月) 08:17:01
OOPの本質が仮想とかメタというわけじゃない
シンプルに保ちたいならそうしたらよい。
0214デフォルトの名無しさん2010/11/22(月) 08:18:56
ちなみにOOPの本質って何ですか？
0215デフォルトの名無しさん2010/11/22(月) 08:45:27
異論は出ると思うが

カプセル化じゃないか？
実装の隠蔽
0216デフォルトの名無しさん2010/11/22(月) 09:53:11
もうちょい広く、抽象化だろ。
0217デフォルトの名無しさん2010/11/22(月) 11:31:10
・フィールドを隠蔽する
・メソッドをオーバーライドする
いずれにせよ、名前空間か辞書のようなものを操作している。
0218デフォルトの名無しさん2010/11/22(月) 12:44:22
>>215
他の多態性や継承と比べて何が利点だと思うことは？
あとOOP歴とその内容（規模や開発が新規がメインか改修がメインかなど）を教えて。

多分OOPをどうのように活用しているかで本質と思うものが変ってくると思う。

俺はOOPで大規模なプログラムを５年以上改修しているから
差分プログラムがOOPの本質だと思う。
抽象化も差分プログラムの為のツールの一つだと考えている。

新規がメインの人は、複数の人間との並行作業が続くから
影響されにくい「実装の隠蔽」が大事だと思うだろうし
そもそも差分プログラムを行なう機会も少ないはず。
0219デフォルトの名無しさん2010/11/22(月) 13:30:07
>>218
以下はクラスベースの話ね

よくOOPの代表的な機能として
カプセル化、多態性、継承の三つが上げられるけど
多態性と継承はカプセル化(クラス)あっての技術

カプセル化を使用しなくても多態性と継承は実現できるかも知れないけど
クラスベースの言語でわざわざ別の手法は使わないだろうし

何が利点かというよりもこれがなければ始まらない
そういう意味でOOPの本質はカプセル化

>OOP歴とその内容
5年くらいで、新規がメイン
0220デフォルトの名無しさん2010/11/22(月) 13:59:42
全部publicでも、継承や多態は出来ると思うけれども。
クラスがそれらを同時に提供するからそのように使うだけで
「クラスベースの本質はクラス」以上のことは言えてないように思う。
0221デフォルトの名無しさん2010/11/22(月) 14:05:09
malloc/freeの抽象化じゃないかな？
0222デフォルトの名無しさん2010/11/22(月) 14:14:34
「隠蔽することが本質」か「委譲することが本質」かという問題だが
いずれにせよ、オブジェクト指向の本質を動詞一個だけで表現するやつはアホだ
0223デフォルトの名無しさん2010/11/22(月) 14:17:38
>>219
考えは分かったけど、俺とじゃカプセル化の考えが少し違う。
カプセル化は構造化言語でも一部の言語では導入している。
構造化言語＋カプセル化＝構造化言語とされているが
多態性、継承は構造化言語では導入されていない。（多態性はOOP的狭義な意味の方で）
多態性、継承をは構造化言語に導入するとそれはOOPに近く構造化言語では無いと判断される。
構造化言語＋（多態性、継承）＝オブジェクト指向言語と考えられる。

話が長くなったけどつまり、カプセル化自身がOOP特有の機能ではないと思っている。
OOP特有の機能でもないものがOOPの本質と言われても．．．、となる。

> 5年くらいで、新規がメイン
それだと自分で作ったクラスの継承もほとんどしないでしょう。（共通クラスの継承とか別にして）
改修をメインにやっていると品質が一番になってくる。
デグレードが一番嫌われし、その為にOOPを活用すると別の側面（本質）が見えてくると思う。
0224デフォルトの名無しさん2010/11/22(月) 14:35:27
ひたすら複雑に考えるのが好きな人がやるのがOOPなんですね
0225デフォルトの名無しさん2010/11/22(月) 15:17:38
カプセル化＋動的ディスパッチ、ということでいいのではないかなあ
動的型言語では動的ディスパッチは当たり前なので、やはりカプセル化のほうに
本義があると思う
ISA継承は静的型言語で動的ディスパッチを実現するための仕組みの一つに過ぎないよね

http://en.wikipedia.org/wiki/Object-oriented_programming
ここにも

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

と書いてある
0226デフォルトの名無しさん2010/11/22(月) 15:32:12
public staticとprivate staticは非OOと実質同じだから、
public/privateよりも、「staticではない」ことが重要。
0227デフォルトの名無しさん2010/11/22(月) 15:58:05
>>220
>全部publicでも、継承や多態は出来ると思うけれども。
「フィールドをすべてpublicで公開しないこと」はカプセル化に含まれるが
それが全てではない

>「クラスベースの本質はクラス」以上のことは言えてないように思う。
言われて見ればそんな気がする

>>223
OOPに特有かどうかをOOPLと非OOPLで比較するのはいかがなものかと
0228デフォルトの名無しさん2010/11/22(月) 15:59:00
>>225
それは特徴が書かれていると思う、日本語の「本質」とは意味が違うよね？
あと、全体的にOO・OOP・OOPLの話が混じってない？
0229デフォルトの名無しさん2010/11/22(月) 20:55:05
信者どうしで潰しあいするのが彼らの特徴です。
放っておけば、喧嘩し始めます。
なぜか？定義が無いからです。議論すら成り立ちません。
つまり・・OOに「本質」は、有りません。
しいて言えば、オブジェクトをフューチャーすること。
その程度です。
0230デフォルトの名無しさん2010/11/22(月) 20:57:27
まーこうなるの解ってて、OOPの本質は？とか聞いたんだがな。
この不毛なやり取り、これが現状ですよ。
0231デフォルトの名無しさん2010/11/22(月) 21:08:03
そうやって「なぜなぜ坊や」を一生やってれば？
0232デフォルトの名無しさん2010/11/22(月) 21:23:16
>>218
てか、利点がつまり本質であるわけではないので、
それは「OOPする目的」を聞かないと。

そもそも聞いているものが違う。
0233デフォルトの名無しさん2010/11/22(月) 21:32:29
本質とか言い出したのは俺じゃないから。

>213 名前：デフォルトの名無しさん[sage] 投稿日：2010/11/22(月) 08:17:01
>OOPの本質が仮想とかメタというわけじゃない
>シンプルに保ちたいならそうしたらよい。

彼がそういうから、じゃ、本質って何？って聞いたんだが。
0234デフォルトの名無しさん2010/11/22(月) 21:41:20
OOには色々疑問点があるかもしれないが、OOPL上で利点を使ったOOP
は良い物だと思うぞ。仮に無理矢理答えてみると。
本質？　≒　過去の経験から出てきたノウハウを有効に使える、1つの方法論。
0235デフォルトの名無しさん2010/11/22(月) 21:48:39
データの分割統治を明示的にやれることじゃね

一言で表す言葉はないんじゃないかな
あったら「[本質]指向」と呼ばれてる
0236デフォルトの名無しさん2010/11/22(月) 22:13:06
>>234
過去の経験とは、非OOPの経験のことだろ
いわば、猿が進化して人間になった

不満があるとすれば
猿と人間の境界がはっきりしないことと、進化の仕方が何通りもあることだろう
0237デフォルトの名無しさん2010/11/22(月) 23:59:47
じゃーC言語はサルで、OOは人間ってこと？
でもこの前テレビでやってた番組では、
チンパンジーは「物」にしか興味を示さなくて、
一方人間の赤ちゃんは人間の「行動」にも興味を示すんだってさ。
人間は行動を理解できるから人間・・・
行動・・関数・・手続き・・・アレアレ？
チンパンジーは物しか理解できない、行動は理解できない猿頭・・・
アレ？オブジェクト指向？進化？なにそれ。

アレアレアレ？進化って退化の事なの？
0238デフォルトの名無しさん2010/11/23(火) 00:35:23
静物が構造体で自意識を伴うのがオブジェクト、かな
言葉遊びしたいなら経験則のない世界行った方がいい
0239デフォルトの名無しさん2010/11/23(火) 00:44:31
猿とか人間とか、進化がどうとか言い出したの俺じゃねーし。
またこの展開かよ。
0240デフォルトの名無しさん2010/11/23(火) 00:53:17
>>237
物を物としか捉えられないより
物と行動を結びつけて両方に着目出来るほうが
進化してると思うぞ
0241デフォルトの名無しさん2010/11/23(火) 01:09:50
だけど、
物→行動
じゃなくて、
行動→物
でしょ。
0242デフォルトの名無しさん2010/11/23(火) 01:57:55
それは表記法の話？
OOP自体には表記法の順序は関係ないぞ
0243デフォルトの名無しさん2010/11/23(火) 02:01:55
>>237
物は「物」単体でしか捉えられないのがサルの赤ちゃん
人間の赤ちゃんは「物」に加えて「物の行動」にも興味をしめすんだろ？
OOP的なのはどっちなんだろうな
0244デフォルトの名無しさん2010/11/23(火) 02:04:41
概念記述が目的の道具なんだから、「物＝物理的な物体」なんて前提は無意味。
0245デフォルトの名無しさん2010/11/23(火) 03:25:08
物の行動じぇねーよ。他者の行動だよ。
だいたい、物の行動ってなんだよ、意味わかんねぇし、物が動いてたら、チンパンジーだろうと人間だろうとそりゃ興味示すだろ。
そういうことじゃない。

人間の赤ちゃんは、
「他人」の動作を真似するのな。
他人がfunc( obj1, obj2 )してたら、自分もfunc( obj1, obj2 )する。funcって面白そうだなーって同調するのな。
物そのものよりも、funcに興味を示す。だから引数も道具として複数取りうる。
funcが目的で、objは道具なんだ。
一方チンパンジーは、物を投げてその跳ね返り方とかを見たりして喜ぶ。
まさにobj.action()って感じだな。これは何だろうの世界。
なんだか解らんからとりあえず投げてみる猿頭。
ちなみにチンパンジーは他のチンパンジーが居ても同調せず、我関せずらしい。
手渡されたオブジェクトに夢中w有る意味し合わせ。

俺にも経験あるぜ。クリスマスプレゼントに何かもらったら、もうそれに夢中なのな。
でもしばらくすると、だんだん飽きてきて、これ、他のことにも使えるんじゃないかって模索し始める。
obj.method()からfunc( obj1, obj2 ) に思考が切り替わった瞬間だな。
0246デフォルトの名無しさん2010/11/23(火) 03:28:02
つまりね、それが「創造性」ってこと。
0247デフォルトの名無しさん2010/11/23(火) 03:32:39
obj.method()ならコード見ただけで何やろうとしてるか想像しやすいが、
func( obj1, obj2 )だとどういう動作するのか把握しにくい。
中で何やってるかわからないとそれを知るために追いかけていかなきゃなんなくなる。
デバッグしたり改変するのに必要だからね。
書いた人間だけがわかりやすいと思って書いたコードを保守させられるのは苦痛。
0248デフォルトの名無しさん2010/11/23(火) 03:40:18
複数オブジェクト間に跨る処理は複雑だってことでしょ。
でもそれ、OOPでも関係なくない？
全ては要求仕様で決まることでしょ。
0249デフォルトの名無しさん2010/11/23(火) 06:51:04
詭弁の特徴のガイドラインでも張っとくべきなんかな。
0250デフォルトの名無しさん2010/11/23(火) 07:49:26
>>247
何々を何々せよ。という構造が一番
わかりやすいから、命令文は
そうなってるのではないか？
0251デフォルトの名無しさん2010/11/23(火) 08:42:39
>>250 はたとえば「1 2 +」が一番わかりやすいと主張するのかな？
0252デフォルトの名無しさん2010/11/23(火) 09:27:16
obj.method()かfunc( obj1, obj2 )なんてのはOOPとは関係ない
表記法の事で議論したいならよそでやれよ
0253デフォルトの名無しさん2010/11/23(火) 10:06:40
>>251
obj.method() は objをmethod()する、と読めるし、
func(obj1,obj2) は obj1,obj2に対してfunc() しろ、と読めるし、
1 2 + は、1 (に) 2 を + しなさい、読める。
述語の位置が前でも後でも意味は明解。だから、端的に意志を伝えたい
命令形はこうなる。ここにあげた三つのパターンのどれにも優位性が
あるとは思えない。
0254デフォルトの名無しさん2010/11/23(火) 10:47:37
forthの表記法って日本人には解りやすいと思うけどな
0255デフォルトの名無しさん2010/11/23(火) 11:03:13
どっかの日本語プログラミング言語もFORTHをベースにしてたっけね
確かに相性は悪くないと思うが、プログラミング言語界ではちょっと異端な仕様なんだよな
0256デフォルトの名無しさん2010/11/23(火) 11:21:57
表記法は、宗教的儀礼なのだ
チンパンジーは神を信じないが、人間様はそういうことにこだわるのだ
0257デフォルトの名無しさん2010/11/23(火) 11:24:56
いや判らんぞ。チンパン神とか言う神を信仰してるかも知れん。
0258デフォルトの名無しさん2010/11/23(火) 11:58:53
>>247
それは、OOPLのよくある表記法がそうなだけで、OOPがどうかって話じゃない。

>書いた人間だけがわかりやすいと思って書いたコードを保守させられるのは苦痛。

これ自体は同意だけど、結局前任とどれだけセンスが似てるかの問題だと思うよ。
代表的には演算子のオーバーロードとか。

大事なのはモジュールの独立性なんじゃないの？
■ このスレッドは過去ログ倉庫に格納されています