OOP 2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/11/10(水) 22:51:25OOPってよくわかんないよね
http://hibari.2ch.net/test/read.cgi/tech/1284115490/
0175デフォルトの名無しさん
2010/11/19(金) 07:06:58上2行はOOPでやればよりやりやすいというだけ
批判派の人はよく「OOP以前もやってた」というけど
OOPはOOP以前の手法を土台にしてるんだからあたりまえのこと
0176デフォルトの名無しさん
2010/11/19(金) 07:30:45> バグがあってもどの機能の中のどの部分かは仕様で決めてあるので場所を絞り込める
簡単に書いちゃってるけどすっげー難しいんじゃね？
0177デフォルトの名無しさん
2010/11/19(金) 09:26:44機能単位に分割するのと、オブジェクト単位に分割するのは
まったくの思想ではないか。
0178177
2010/11/19(金) 09:28:100179デフォルトの名無しさん
2010/11/19(金) 20:04:31マジレスすると機能単位はシステム工学で一番やっては駄目な方法。
システム工学では機能単位では無くデータ単位に行なうが良いとされている。
オブジェクト指向はもちろんデータにそれ専用の機能だが
構造化でもPOAよりDOAが優れている。
0180デフォルトの名無しさん
2010/11/19(金) 20:28:49「機能単位」の粒度にもよるけど
まったく別ってことはないと思うな
0181デフォルトの名無しさん
2010/11/19(金) 21:44:25>>164 をどのように評価するかだ。
大きいことが悪いのだ、という評価もあるわけだから。
0182デフォルトの名無しさん
2010/11/19(金) 21:58:08何傘？
結局のとこItumono人がItumono語の初心者から初級者への道を一歩進んだだけやん。
>>132まで戻って実体の多重継承はItumono人が理解できる段階に進んだだけで何か解決したこと無いし。
注意して使えば問題ない？C++が多重継承を残してるのは注意して使えば問題ないからやの。
れとも実体の継承を禁止、
f(A*);
f((B|C*));
g((A|B|C*)p){
f(p);
}
を禁止してるのか知らん。
0183デフォルトの名無しさん
2010/11/19(金) 22:29:43sys.environment.value["PATH"] += ";C:\hoge\lib";
append(find(value(environment(sys)), "PATH"), ";C:\hoge\lib");
え〜173は下派に鞍替えったの？
0184デフォルトの名無しさん
2010/11/19(金) 23:10:41言葉で言っても理解できないじゃんあんた。
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>逆共用体化演算子
ダウンキャスト言え。
>ロード時にリンクエラーやらなんやら事前に調べてくれたほうがプログラマは嬉しいだろう。
実行時の自己書き換えやテーブルでCPUキャッシュを使い込むのをやめてくれたほうがうれしい。
0186デフォルトの名無しさん
2010/11/20(土) 00:07:28OO、生産性やソフトウェア工学のの論文や研究者なんて山ほどあるだろに。
あんたにとって教授の言ったことが全ての世界なの？
OOはメッセージングである、という世界しか知らずに育ち、
その外側では過ごしたことが無くほとんど知らないから、
前スレでは藁人形叩きをやって、ポリモとかいう誰も使わない省略形を使って、
>>183の下派なのか。
子供なら社会の被害者とかいうけども、もう一介の社会人なんだからただの
0187デフォルトの名無しさん
2010/11/20(土) 02:12:54まず初めに断っておくけど、
関数を一つ一つ手動でロードするスタイルはとらないつもり。
load_lib( "lib.dll" );
こんな感じで一気に全部読み込む。
そんで、プログラムを再リンクする。そのとき、変換テーブルや関数テーブルも拡張する。
だから、ごく軽い再コンパイルのようなことが起こる。
ので、dllからのロードだからって、変な制限とかが付くことは無い。
だって、最コンパイルするんだからな。ある意味なんでもあり。
といっても、コードを最コンパイルする訳ではないぞ。あくまで、各種テーブルを拡張するだけ。すぐ終わる。
だから、再リンクと言ったほうが適切だな。
再リンクに必要な型推論の型の伝達関係は、予めdllに仕込む。
Itumono仕様のdllには何か特殊な環境取得関数が仕込まれてて、
load_libはそれを呼び出して、型の伝達関係etcをもらう。
環境取得関数の無いItumono仕様でないDLLをload_libすると失敗する。
Itumono仕様でないDLLはCスタイルで読み込むことになる。
その場合は型推論やポリモは適用されない。問題ないだろう。
0188デフォルトの名無しさん
2010/11/20(土) 04:12:400189デフォルトの名無しさん
2010/11/20(土) 06:23:590190デフォルトの名無しさん
2010/11/20(土) 20:02:26継承の仕方が特殊なだけでクラスは使ってるよね
プロトタイプベースの言語はjavascriptしかしらんけどさ
0191デフォルトの名無しさん
2010/11/20(土) 20:32:300192デフォルトの名無しさん
2010/11/21(日) 00:19:29プロトタイプを使ってるからクラスは確かに存在しないはずだが
0193デフォルトの名無しさん
2010/11/21(日) 08:30:49クラスそのものとまでは言わないけど
（javascriptの）コンストラクタはクラスみたいなものでしょ
0194デフォルトの名無しさん
2010/11/21(日) 08:39:590195デフォルトの名無しさん
2010/11/21(日) 10:27:44う〜ん、似てるようでもやっぱ根本が違うと思う。
コンストラクタは、使い方がクラスみたいなだけで
クラスと違って設計図そのものでは無いんだよね。
設計図そのものは親のインスタンスに求める感じ。
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>設計図そのものは親のインスタンスに求める
継承してるインスタンスはこのイメージですんなり納得できる
でも継承元のインスタンスを作るときは構成を書き出さなきゃならんわけでしょ？
呼び名が違うだけで「オブジェクト初期化子」も「コンストラクタ関数」も
クラスと(設計図としての)役割は変わらないと思うんだよね
もちろんクラスそのものじゃないから、いろいろ違いがあるのはわかるけどさ
0197デフォルトの名無しさん
2010/11/21(日) 13:17:00ちょっと暴論かなぁ、と思う。
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:43OOPはなぜか文字列を敵視したり型理論を信奉したりしている。
0204デフォルトの名無しさん
2010/11/21(日) 18:41:34その理屈で行くと、既存の処理系の上に俺言語的(DSL?)なものを構築するのもメタって言うのかなぁ。
0205デフォルトの名無しさん
2010/11/21(日) 19:00:15「メタプログラミング」っていう言葉はあるよ。
0206デフォルトの名無しさん
2010/11/21(日) 23:42:35メタプログラミングって何の意味も持たない言葉だな。
文字列ベースのメタプログラミングの話が出てたけど、
Cのマクロって確かに便利なんだよな。なんでもありで。その分危険だが。
そして誰も興味ないよ、この話題。
どうせ、メタ言語の、そのまたメタ言語も必要かどうかって話になって終わるに決まってる。
0207デフォルトの名無しさん
2010/11/22(月) 00:12:22メタっちゃメタなのかもしれんが, 手法的には全然柔軟性に欠るよな.
新しいシンタックス導入するの大変だし...
CL や scheme の macro は文字列ベースじゃないけど, 遥かに柔軟で扱いやすい
>>204
メタの定義をプログラムを吐き出すプログラムって意味とするなら, メタじゃないか?
>>206
抽象化されたアセンブラでって意味ならそうだが， メタプログラミングとは言わんと思う
C++ のテンプレートメタプログラミングなんて, とても涙ぐましい努力をしていると思う
# メタプログラミングにマッチした文法じゃないんだよ, 手続き型ベースの言語は...
0208デフォルトの名無しさん
2010/11/22(月) 00:24:560209デフォルトの名無しさん
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シンプルに保ちたいならそうしたらよい。
0214デフォルトの名無しさん
2010/11/22(月) 08:18:560215デフォルトの名無しさん
2010/11/22(月) 08:45:27カプセル化じゃないか？
実装の隠蔽
0216デフォルトの名無しさん
2010/11/22(月) 09:53:110217デフォルトの名無しさん
2010/11/22(月) 11:31:10・メソッドをオーバーライドする
いずれにせよ、名前空間か辞書のようなものを操作している。
0218デフォルトの名無しさん
2010/11/22(月) 12:44:22他の多態性や継承と比べて何が利点だと思うことは？
あとOOP歴とその内容（規模や開発が新規がメインか改修がメインかなど）を教えて。
多分OOPをどうのように活用しているかで本質と思うものが変ってくると思う。
俺はOOPで大規模なプログラムを５年以上改修しているから
差分プログラムがOOPの本質だと思う。
抽象化も差分プログラムの為のツールの一つだと考えている。
新規がメインの人は、複数の人間との並行作業が続くから
影響されにくい「実装の隠蔽」が大事だと思うだろうし
そもそも差分プログラムを行なう機会も少ないはず。
0219デフォルトの名無しさん
2010/11/22(月) 13:30:07以下はクラスベースの話ね
よくOOPの代表的な機能として
カプセル化、多態性、継承の三つが上げられるけど
多態性と継承はカプセル化(クラス)あっての技術
カプセル化を使用しなくても多態性と継承は実現できるかも知れないけど
クラスベースの言語でわざわざ別の手法は使わないだろうし
何が利点かというよりもこれがなければ始まらない
そういう意味でOOPの本質はカプセル化
>OOP歴とその内容
5年くらいで、新規がメイン
0220デフォルトの名無しさん
2010/11/22(月) 13:59:42クラスがそれらを同時に提供するからそのように使うだけで
「クラスベースの本質はクラス」以上のことは言えてないように思う。
0221デフォルトの名無しさん
2010/11/22(月) 14:05:090222デフォルトの名無しさん
2010/11/22(月) 14:14:34いずれにせよ、オブジェクト指向の本質を動詞一個だけで表現するやつはアホだ
0223デフォルトの名無しさん
2010/11/22(月) 14:17:38考えは分かったけど、俺とじゃカプセル化の考えが少し違う。
カプセル化は構造化言語でも一部の言語では導入している。
構造化言語＋カプセル化＝構造化言語とされているが
多態性、継承は構造化言語では導入されていない。（多態性はOOP的狭義な意味の方で）
多態性、継承をは構造化言語に導入するとそれはOOPに近く構造化言語では無いと判断される。
構造化言語＋（多態性、継承）＝オブジェクト指向言語と考えられる。
話が長くなったけどつまり、カプセル化自身がOOP特有の機能ではないと思っている。
OOP特有の機能でもないものがOOPの本質と言われても．．．、となる。
> 5年くらいで、新規がメイン
それだと自分で作ったクラスの継承もほとんどしないでしょう。（共通クラスの継承とか別にして）
改修をメインにやっていると品質が一番になってくる。
デグレードが一番嫌われし、その為にOOPを活用すると別の側面（本質）が見えてくると思う。
0224デフォルトの名無しさん
2010/11/22(月) 14:35:270225デフォルトの名無しさん
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:12public/privateよりも、「staticではない」ことが重要。
0227デフォルトの名無しさん
2010/11/22(月) 15:58:05>全部publicでも、継承や多態は出来ると思うけれども。
「フィールドをすべてpublicで公開しないこと」はカプセル化に含まれるが
それが全てではない
>「クラスベースの本質はクラス」以上のことは言えてないように思う。
言われて見ればそんな気がする
>>223
OOPに特有かどうかをOOPLと非OOPLで比較するのはいかがなものかと
0228デフォルトの名無しさん
2010/11/22(月) 15:59:00それは特徴が書かれていると思う、日本語の「本質」とは意味が違うよね？
あと、全体的にOO・OOP・OOPLの話が混じってない？
0229デフォルトの名無しさん
2010/11/22(月) 20:55:05放っておけば、喧嘩し始めます。
なぜか？定義が無いからです。議論すら成り立ちません。
つまり・・OOに「本質」は、有りません。
しいて言えば、オブジェクトをフューチャーすること。
その程度です。
0230デフォルトの名無しさん
2010/11/22(月) 20:57:27この不毛なやり取り、これが現状ですよ。
0231デフォルトの名無しさん
2010/11/22(月) 21:08:030232デフォルトの名無しさん
2010/11/22(月) 21:23:16てか、利点がつまり本質であるわけではないので、
それは「OOPする目的」を聞かないと。
そもそも聞いているものが違う。
0233デフォルトの名無しさん
2010/11/22(月) 21:32:29>213 名前：デフォルトの名無しさん[sage] 投稿日：2010/11/22(月) 08:17:01
>OOPの本質が仮想とかメタというわけじゃない
>シンプルに保ちたいならそうしたらよい。
彼がそういうから、じゃ、本質って何？って聞いたんだが。
0234デフォルトの名無しさん
2010/11/22(月) 21:41:20は良い物だと思うぞ。仮に無理矢理答えてみると。
本質？ ≒ 過去の経験から出てきたノウハウを有効に使える、1つの方法論。
0235デフォルトの名無しさん
2010/11/22(月) 21:48:39一言で表す言葉はないんじゃないかな
あったら「[本質]指向」と呼ばれてる
0236デフォルトの名無しさん
2010/11/22(月) 22:13:06過去の経験とは、非OOPの経験のことだろ
いわば、猿が進化して人間になった
不満があるとすれば
猿と人間の境界がはっきりしないことと、進化の仕方が何通りもあることだろう
0237デフォルトの名無しさん
2010/11/22(月) 23:59:47でもこの前テレビでやってた番組では、
チンパンジーは「物」にしか興味を示さなくて、
一方人間の赤ちゃんは人間の「行動」にも興味を示すんだってさ。
人間は行動を理解できるから人間・・・
行動・・関数・・手続き・・・アレアレ？
チンパンジーは物しか理解できない、行動は理解できない猿頭・・・
アレ？オブジェクト指向？進化？なにそれ。
アレアレアレ？進化って退化の事なの？
0238デフォルトの名無しさん
2010/11/23(火) 00:35:23言葉遊びしたいなら経験則のない世界行った方がいい
0239デフォルトの名無しさん
2010/11/23(火) 00:44:31またこの展開かよ。
0240デフォルトの名無しさん
2010/11/23(火) 00:53:17物を物としか捉えられないより
物と行動を結びつけて両方に着目出来るほうが
進化してると思うぞ
0241デフォルトの名無しさん
2010/11/23(火) 01:09:50物→行動
じゃなくて、
行動→物
でしょ。
0242デフォルトの名無しさん
2010/11/23(火) 01:57:55OOP自体には表記法の順序は関係ないぞ
0243デフォルトの名無しさん
2010/11/23(火) 02:01:55物は「物」単体でしか捉えられないのがサルの赤ちゃん
人間の赤ちゃんは「物」に加えて「物の行動」にも興味をしめすんだろ？
OOP的なのはどっちなんだろうな
0244デフォルトの名無しさん
2010/11/23(火) 02:04:410245デフォルトの名無しさん
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:020247デフォルトの名無しさん
2010/11/23(火) 03:32:39func( obj1, obj2 )だとどういう動作するのか把握しにくい。
中で何やってるかわからないとそれを知るために追いかけていかなきゃなんなくなる。
デバッグしたり改変するのに必要だからね。
書いた人間だけがわかりやすいと思って書いたコードを保守させられるのは苦痛。
0248デフォルトの名無しさん
2010/11/23(火) 03:40:18でもそれ、OOPでも関係なくない？
全ては要求仕様で決まることでしょ。
0249デフォルトの名無しさん
2010/11/23(火) 06:51:040250デフォルトの名無しさん
2010/11/23(火) 07:49:26何々を何々せよ。という構造が一番
わかりやすいから、命令文は
そうなってるのではないか？
0251デフォルトの名無しさん
2010/11/23(火) 08:42:390252デフォルトの名無しさん
2010/11/23(火) 09:27:16表記法の事で議論したいならよそでやれよ
0253デフォルトの名無しさん
2010/11/23(火) 10:06:40obj.method() は objをmethod()する、と読めるし、
func(obj1,obj2) は obj1,obj2に対してfunc() しろ、と読めるし、
1 2 + は、1 (に) 2 を + しなさい、読める。
述語の位置が前でも後でも意味は明解。だから、端的に意志を伝えたい
命令形はこうなる。ここにあげた三つのパターンのどれにも優位性が
あるとは思えない。
0254デフォルトの名無しさん
2010/11/23(火) 10:47:370255デフォルトの名無しさん
2010/11/23(火) 11:03:13確かに相性は悪くないと思うが、プログラミング言語界ではちょっと異端な仕様なんだよな
0256デフォルトの名無しさん
2010/11/23(火) 11:21:57チンパンジーは神を信じないが、人間様はそういうことにこだわるのだ
0257デフォルトの名無しさん
2010/11/23(火) 11:24:560258デフォルトの名無しさん
2010/11/23(火) 11:58:53それは、OOPLのよくある表記法がそうなだけで、OOPがどうかって話じゃない。
>書いた人間だけがわかりやすいと思って書いたコードを保守させられるのは苦痛。
これ自体は同意だけど、結局前任とどれだけセンスが似てるかの問題だと思うよ。
代表的には演算子のオーバーロードとか。
大事なのはモジュールの独立性なんじゃないの？
0259デフォルトの名無しさん
2010/11/23(火) 12:52:46という人もいるし
extern "C" のように低レベルの共通性があるからメタクラスいらねぇという人もいる
表記にこだわるのは前者
0260デフォルトの名無しさん
2010/11/23(火) 14:41:57外からは初期化関数呼べば実装はどうあれ初期化できる
多態だって、外から関数呼べば型はどうあれ適切に動作する、と
その中と外をばっさりやらせるのがOOPL、という程度の認識
0261デフォルトの名無しさん
2010/11/23(火) 16:21:51オブジェクトは作成時からデータの整合性がとれているから
それだと外部からコントロールされる受動的なイメージになるから違うと思う。
オブジェクトは能動的だと思う。
0262デフォルトの名無しさん
2010/11/23(火) 16:56:41能動的に動作する「もの」とその関連で構築されるのは、
プロセス計算とかアクターモデルとか言われるものだけだろう
JavaやC#あたりの言語では、スレッドに対応するオブジェクトだけが能動的で、
他は全部そこから呼ばれる側だから、受動的と言える
メッセージパッシングがただの関数呼び出しだしな
少なくともそうした言語でのstackやqueueを能動的なオブジェクトと捉える人は
いないんじゃないの
0263デフォルトの名無しさん
2010/11/23(火) 17:34:49初期化前には触らせない、ってのはOOPLが押し進めた部分ということで
受動的か能動的かは別にして(言葉の問題な気がする)、自律的ではあるね
0264デフォルトの名無しさん
2010/11/23(火) 18:15:27>>260の言う「初期化関数」が生の型ではなくいわゆるopaque pointerを返し、
操作はそのポインタと操作関数を通して行うようになっていれば、
カプセル化／data abstractionは容易に達成できる
つーか、よくある「ハンドル」の類は全部それだ（stdioのFILE*はモロ出しだが）
その程度ならOOPLに限った話ではないよ
0265デフォルトの名無しさん
2010/11/23(火) 18:26:52オブジェクトを受動的に作るのは違うと思う。
「能動的」か>>263の言うような「「自律的」や「主体的」（いろいろ言葉はあるが）に作る。
外部よりコントロールされないように作るもの。
>メッセージパッシングがただの関数呼び出しだしな
メッセージパッシングは、メッセージの通知で手順になってはいけない。
「最初に初期化してから、その後機能１を実行する」など
メッセージに手順が入り混んではいけない。
手順が入り混むと、外部から受動的に操作される。
だから、メッセージパッシングを
単純な関数呼び出しと同じに考えるのは違うと思う。
0266デフォルトの名無しさん
2010/11/23(火) 18:32:08それはオブジェクトをデザインする場合の指針の話で
上のはオブジェクトというものの定義や性質、あるいは（言語レベルの）実装の
話じゃないの
ちょっと次元が違う話のような
「手順になってはいけない」は大いに結構だが、
実装として、C++の系統の「オブジェクト指向言語」においては、
それはただの（場合によっては動的ディスパッチつきの）関数呼び出しだろう
0267デフォルトの名無しさん
2010/11/23(火) 18:51:10obj.method()とfunc( obj1, obj2 )は、表記の問題でしかなく、意味は等価だって言ってるの、
わかるんだけど、必ずしもそうとは言い切れなくない？
センスがどうとかじゃなく、もっとほら。何か違うでしょ。
多くのOOPLは単一ディスパッチなので、、多態は、第一引数に基づいてのみ、行われる。
だから、第一引数だけ、「特別」なんだよ。
obj.method()とfunc( obj1, obj2 )の違いはそこなんだ。
前者は、メソッドがobjに関連づく。メソッドにとって、objは特別なもの。
後者は、関数はobj1とobj2を等価に扱う。obj1とobj2のどちらに属すると言うものでもない。
あくまでfuncが目的で、その道具として、引数にobjを取る。
そこらへんの思考形態の違い。
百歩譲っても、OOPはマルチメソッドじゃなきゃおかしいんだよ。
JavaとかC++とかはどうかしてる。
人間の思考形態を退化させる洗脳装置だよ。あまり関わるな。
単一ディスパッチなので、単一のオブジェクト/クラスにメソッドが関連付けられるから、
どうしても思考回路が物中心になる。だから、「オブジェクト指向」なんて言われる。
だいたい、第一引数だけ特別扱いすることに、何の整合性がある？
引数は、第一だろうが第二だろうが、等価に扱われるべきだろ。それが自然だろ？
不自然なことすると、どっか歪んできてやがては破綻する。しわ寄せが出来る。
ちなみに、C++やJavaが単一ディスパッチなのは、それが便利だからじゃないぞ。
単にパフォーマンス上の理由と、コンパイラ実装コストからの物だ。
基底クラスを使っての多態もそう。
要はそれが手っ取り早かったってだけ。
出来るなら、ダックタイピング+マルチメソッドの方が便利に決まってる。
ちなみに、慎重派のLISPer達は、CLOSでマルチメソッドにしてる。流石だな。
0268デフォルトの名無しさん
2010/11/23(火) 19:13:55構造体と関数だと手順になる。
260 >外からは初期化関数呼べば実装はどうあれ初期化できる
の「「外から」が手順になってしまう。
オブジェクトは作成時からデータが初期化されているから
いつでも「オブジェクト」ならメッセージパッシング出来ると思う。
0269デフォルトの名無しさん
2010/11/23(火) 19:15:070270デフォルトの名無しさん
2010/11/23(火) 19:18:50オブジェクト指向に出てくる言葉の中でこれが一番わからん。
単なる関数呼び出しとの違いはなんなの？
0271デフォルトの名無しさん
2010/11/23(火) 19:25:08意味が分からん
初期化関数というのは、コンストラクタと等価だぞ？
初期化関数を呼ぶ前はオブジェクトがなくて、関数がオブジェクトをこしらえて、
それを返す
fopen()を考えて欲しい
0272デフォルトの名無しさん
2010/11/23(火) 19:27:33Stack stack;
stack.push(x);
のように書く
Cのような言語では関数名の衝突を避けなければならないので、
通常もっと長い名前が必要になる
stack_t stack = create_stack();
stack_push(stack, x);
のような感じになるだろう
ここで典型的なclass指向のOO言語のclassが、少なくとも
適度な名前空間としての機能を果たしていることが分かる
表記の違いではあるが、名前の衝突を気にせず短く書けていいですね、というわけだ
0273272
2010/11/23(火) 19:28:47関数呼び出しについては、型のパターンマッチをコンパイラが行ってくれるので、
非OO的に記述する場合にも、長い名前を使う必要は無い、つまり
stack_t stack = create_stack();
push(stack, x);
のようなインタフェースであっても問題はない
「コンストラクタ関数」だけはパターンマッチは効かないが、
操作する関数については、どこかにある
void push(stack_t stack, int x);
のような関数を、コンパイラが探してくれるわけだ
push()という（短い）名前は勿論衝突するかもしれないが、
引数の型が違えば別の関数として扱われるので、問題は無い
よって、オーバーローディングを持つ静的型言語であれば、
クラスの提供する名前空間が実は必要が無いことがわかる
0274デフォルトの名無しさん
2010/11/23(火) 19:29:08望ましいモジュール化・抽象化の表現を推奨するのがOOPであって、
Cではできない革新的な何かを目指すものじゃないんじゃないかな
■ このスレッドは過去ログ倉庫に格納されています