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

OOP 2

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

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

http://hibari.2ch.net/test/read.cgi/tech/1284115490/
0412デフォルトの名無しさん2010/11/28(日) 00:06:27
コードスニペット？
0413デフォルトの名無しさん2010/11/28(日) 00:44:13
処理構造の汎化って、フローチャートのことか？
意味無いと思うぞ。
だって、データ構造が抜け落ちてるから。

プログラムは、大まかに分けて、制御構造とデータ構造で成り立っている。
おのおのを単体で見るなら、なんら難しいことは無いが、
両者が絡み合うと途端に難しくなる。

http://www.nhk.or.jp/kanadigi-blog/photos/shiorin022.jpg
これは電波の図だが、制御構造とデータ構造のイメージは概ねこんな感じ。
互いに影響しながら振り子運動をする。

また、振り子運動における、位置エネルギーと速度エネルギーの関係とも言っていいし、
電圧と電流の関係とも言える。

おのおの単体で扱えれば簡単なんだが、互いに相互作用するから、
切り離せないんだ。
どっちかを基準にして考えることも出来ない。交互に頭を切り替えながら考える必要がある。
http://trickart.up.seesaa.net/image/rubin.gif
この絵のようにな。
0414デフォルトの名無しさん2010/11/28(日) 00:55:42
それでね、単一ディスパッチのOOがどういう立ち居地かというと、
わりとデータよりの発想で、だからバランスが悪いと俺はね。
マルチメソッドにしろというのはそういうこと。
0415デフォルトの名無しさん2010/11/28(日) 00:56:48
いつもの人は理解できないなら黙っててくれないかな＾＾；；
0416デフォルトの名無しさん2010/11/28(日) 04:02:25
マルチメソッドはダメだろう。オブジェクトが2個のときでさえ、相互に関係する処理がいくつかあれば
それを処理するメルチメソッド関数が何個も必要になる。3個、4個と増えればそれらの相互関係を処理するために
幾何級数的にマルチメソッド関数が増える。しかも1個でも書きもらせばバグになる。いたずらに複雑になるだけで
わかりやすさとはほど遠い。見た目がただの関数にしか見えないのもOOPらしくない。
0417デフォルトの名無しさん2010/11/28(日) 06:07:45
マルチミソ自体は別に悪くはないと思う
関数の数は、例えばオブジェクト2個なら片方をObjectか何かで取って
多態を使って変換してやるだけだろうし

ただいつもの人の場合は手段と目的がぐちゃぐちゃ
ただ批判したいがために出してる感じ
0418デフォルトの名無しさん2010/11/28(日) 11:01:37
いや、その理屈はおかしい。
だって、お前らオーバーロードは受け入れているんだろ？
あれは、全ての引数の型に基づいて関数を決定するぞ。
あれがよくて、なんでマルチメソッドはダメなんだ？
普通に機能強化なんだから、問題ないだろ。
OOPが好きな奴も嫌いな奴も納得できる、良い落しどころだろ。

テンプレートが便利なのも、いまや誰もが認めるところだろ。
あれが動的になるだけじゃん。
マルチメソッド+ダックタイピング、良いね。
次のスタンダードになりうると思うよ。
0419デフォルトの名無しさん2010/11/28(日) 11:21:43
>>411
ワークフローエンジンなんかは、いくつか出てるね
0420デフォルトの名無しさん2010/11/28(日) 12:27:34
>>418
プログラマを楽にすることに全く貢献してないから。
「あれもできる、これもできる」というのは、使いやすさとは関係ないんだよ。
0421デフォルトの名無しさん2010/11/28(日) 12:36:10
ttp://blog-imgs-24.fc2.com/t/a/i/taiikuyougu/20090818193227a9f.jpg
0422デフォルトの名無しさん2010/11/28(日) 12:39:06
>>418
あるクラスのメソッド呼び出しで、引数型をみて(ダックタイピングでも)
動的ディスパッチするだけなら特に問題はない。
動的言語としちゃ普通に便利だろ。
# ある開発において、動的と静的のどちらが向いてるかの問題はある。

いつもの人は
「クラスは無くして全てマルチメソッドで表現すべき」
などと言うから頂けないんだ。
0423デフォルトの名無しさん2010/11/28(日) 12:56:51
クラスなくしても、型があるんだから良いだろ。
それに、マルチメソッドなのに、「クラスメソッド」って呼び名は変だろ。
オーバーロードの関数を、クラスメソッドって言うか？
0424デフォルトの名無しさん2010/11/28(日) 12:58:49
マルチメソッドって、マルチ「クラス」メソッドってことだろ。
複数のクラスに属しているメソッドだから、クラス定義部に書くことは出来ないぞ。
クラスメソッドって言えるか？
0425デフォルトの名無しさん2010/11/28(日) 13:00:28
>>423
もう一度言うぞ。
「機能等価であることと、使いやすさや読みやすさは関係ない」
0426デフォルトの名無しさん2010/11/28(日) 13:02:48
それは屁理屈だろ。なぜ関係ないかも説明せずにか。
機能等価の方が汎用性があっていいに決まってるじゃん。
0427デフォルトの名無しさん2010/11/28(日) 13:03:26
便利だから便利だからと言って色々追加したのが、今のC++なんだよ。
あのカオスをまた増殖させるのか？
0428デフォルトの名無しさん2010/11/28(日) 13:05:18
マルチメソッドにすると、オーバーロードと多態が統合されるんだから、
より一層シンプルになるわな。
0429デフォルトの名無しさん2010/11/28(日) 13:06:45
オーバーロードと多態消えるならな、どうせ残ってるだろ
0430デフォルトの名無しさん2010/11/28(日) 13:09:31
マルチメソッドはクラスを作る側ではなく使う側に属している。
カプセルの外から、総称アルゴリズムでオブジェクトを扱うためのグルーだ。
クラスを作る側がメソッドを提供する場合であっても、
マルチメソッドのインターフェースを決めるのは使う側で、
それをフックする考え方になる。
0431デフォルトの名無しさん2010/11/28(日) 13:09:51
両方消えたら、ただのCじゃないか。
それがよければそちらをどうぞ。超シンプルだぜ。

多態がオーバーロードに吸収されて、オーバーロードとして残る。
動的オーバーロード=動的多態=マルチメソッド
ってだけじゃん。何が複雑なのか解らない。
0432デフォルトの名無しさん2010/11/28(日) 13:12:56
あのね、１つの機能を実現する方法が複数有っただけで。
どれだけの弊害が起こるか想像できないんだね。
君は、一人だけでプログラムを作ってる人だと、見え見え。
0433デフォルトの名無しさん2010/11/28(日) 13:13:53
>>426
プログラミングにおいて、過剰に汎用性がある機能は逆に使いにくい。
理由は色々あるが、一つは、その機能を使って書かれているコードの意図が曖昧になるから。
他人が読んだときに分かりにくいコードなんて、第一級のバグの温床となりうる。

多くのオブジェクト指向言語が、「オブジェクト」にメソッドを従属させているのは、
ある機能群をグループ化できるということの他に、使う側がそのメソッドを使っている文脈を明確化できるから、だと思う。
0434デフォルトの名無しさん2010/11/28(日) 13:15:25
何いってるのかわからない。
オーバーロードも多態も全て動的オーバーロードで解決しようって言ってるのに、
>１つの機能を実現する方法が複数有っただけでどれだけの弊害(ry
になるのか解らない。なんで逆を言うの？
方法が複数？一本化しようって言ってるのに？
なんでなんで。
0435デフォルトの名無しさん2010/11/28(日) 13:16:58
>>433
だったら、多態も差分プログラミングもカプセル化も全部同じ文法の、
C++やJavaはもっとダメだね。
0436デフォルトの名無しさん2010/11/28(日) 13:19:08
オブジェクト＝変数＋関数

↑これが過ちなんだろうな。

クラスベースOOPLで言うと、
クラスの実装をしてる時は、変数＋関数を扱ってるんだが、
クラスの実装が終わったあと、さぁOOPでラクしようってときに、
外からそのオブジェクトを見たときは

オブジェクト＝インタフェース＝型とメソッド名と引数と戻り値

こう考えられるからこそ、使うときラクできる。
変数も関数の実装も、考えなくていい。開放される。
0437デフォルトの名無しさん2010/11/28(日) 13:23:32
それは、
func( obj1, obj2 );
でも同じだろ。
funcの実装も、obj1とobj2の実装も、何も気にしなくて良い。
つーか、そんなのOOPの話じゃなくて、Cレベルの話だろ。
0438デフォルトの名無しさん2010/11/28(日) 13:26:45
>>435
同じ文法って何の話だ？
それに、別のレイヤの話をごちゃ混ぜにして何が言いたい。
0439デフォルトの名無しさん2010/11/28(日) 13:28:15
まだわかってない人がいて困るんだけど、
マルチメソッドの問題は、コンパイラの実装が困難なこと。
使い勝手が悪いって方向から攻めても無駄なんだよ。
オーバーロードはOKで、マルチメソッドはNGって主張は、
説明がつかないんだよ。

だから、マルチメソッドをどうしても否定したいなら、
コンパイラの実装について言及するのが正しいんだ。
0440デフォルトの名無しさん2010/11/28(日) 13:31:55
>>432
結局それなんだろうな。

コードを書くという事の本質的な困難は、機能をコードを落とす所それ自体にはないというのは、
大規模なコードを書いたり、複数人で開発したりする経験がないとなかなか分からないのかも。
0441デフォルトの名無しさん2010/11/28(日) 13:33:54
>>439
実装のできない処理系とか、プログラマ的には完全に無意味だと思うんですが。
自分が全知全能なら混沌とした世を平らげられるのに、と妄想してる中学生と何が違うの？
0442デフォルトの名無しさん2010/11/28(日) 13:35:20
実装例はこのスレで上げたはずだが。わざわざコード書いてな。
0443デフォルトの名無しさん2010/11/28(日) 13:36:35
>>437
例えばstrlen()を使うとき、
char obj[]の中身が'\0'で終わっている事を気にしなくちゃいけない。

それは、関数の実装により強いられていることで、
渡す引数もそれに対応して準備しなきゃ使えない。


一方、OOPでのstringクラスは、終端文字がどうであるかは問われない。
string#size()を呼び出すときも何も気にすることが無い。
0444デフォルトの名無しさん2010/11/28(日) 13:36:46
>>442
妄想処理系の擬似コードがいくらあっても、お腹はいっぱいにならんのですが。
0445デフォルトの名無しさん2010/11/28(日) 13:36:59
「さきほど光ルータの話がありましたが、もし仮に、明日光よりももっと速い、光を使わなくても速くて、熱効率も良くてですね、
そうしたものがどっかからポンと出て来た時に、これは続けられるんですか？」論だな
0446デフォルトの名無しさん2010/11/28(日) 13:38:44
>>443
len( string );
append( string, "hoge" );

で、何か問題があるの？
0447デフォルトの名無しさん2010/11/28(日) 13:45:02
(len "abcde")
(append "abcde" "hoge")
の方がすっきりしているとはおもわないのかね
0448デフォルトの名無しさん2010/11/28(日) 13:46:44
良いね。ただ、括弧も省略できると良いね。
len "abcd";
append "abcde" "hoge";
0449デフォルトの名無しさん2010/11/28(日) 13:51:44
表記法とコンパイラの実装はどうでもいいってば
0450デフォルトの名無しさん2010/11/28(日) 13:59:07
>>446
ああそうか。そうやってすれば結局は同じか…。
privateにはならないだけで。
Cは関数のオーバーロードできないから、
名前はどんどん苦しくなってくると思うけど。
問題はそれくらいのもんか。

そのstruct stringは、stringクラスを作った場合の、
メンバ変数を全部網羅してるものと考えていい？
0451デフォルトの名無しさん2010/11/28(日) 14:03:52
いっぺんC++やC++派生以外のOOPLやってみれば言いと思うよ
考えて言うだけより考えて実行するべき

何言ってるのかわからないが
0452デフォルトの名無しさん2010/11/28(日) 14:07:24
>>450
概ねそんな感じ。
ただ、マルチメソッドがあれば、Cと違って名前が苦しくならないね。
privateの問題は・・・まーカプセル化は何か特別な構文を用意すれば良いだろう。
ネームスペース単位でアクセス権を設けるとかさ。
自クラスからじゃないとアクセス駄目ってのも、苦しい場合がある品。
実際、結合度の高いクラス同士だとfriendとかするしな。
ネームスペース単位の方がむしろ柔軟かも試練。

>>449
どうでも良くないって。
obj.method(obj2);って表記だと、マルチメソッドに対応するのが難しい。
0453デフォルトの名無しさん2010/11/28(日) 14:10:12
>>451
単一ディスパッチ系以外の手続き型OOPでなにかお勧めある？
出来ればマルチメソッドの解決にハッシュ引かないのが良いんだが。
実装に興味がある。
0454デフォルトの名無しさん2010/11/28(日) 14:23:22
>>452
それって、新しい記法のOOPLを作るだけじゃないのか？
0455デフォルトの名無しさん2010/11/28(日) 14:26:31
マルチメソッドはスパゲティプログラムになりやすい。
オーバーロードは静的に統合されるから大丈夫。
0456デフォルトの名無しさん2010/11/28(日) 15:04:36
>>454
その新しいOOPL記法がfunc(obj1, obj2)。
なにか馴染みが有る気がするが、気にしない。
0457デフォルトの名無しさん2010/11/28(日) 16:37:22
>>452
>どうでも良くないって。
>obj.method(obj2);って表記だと、マルチメソッドに対応するのが難しい。
ここはコンパイラスレじゃないんだから
実装するのが難しいかどうかは関係ないしどうでもいい

マルチメソッドの話題自体は歓迎するけど
自分の考えた処理系を披露したいなら別なとこでやってくれ
0458デフォルトの名無しさん2010/11/28(日) 18:35:59
>>452
> 実際、結合度の高いクラス同士だとfriendとかするしな。

しねーよ。
デバッグ機能とテスト機能以外でfriendが必要なんて
クソ設計もいいトコだ。
設計から見直せ。
0459デフォルトの名無しさん2010/11/28(日) 19:16:16
あるオブジェクトへの操作を提供する別のクラスとかは
friendクラスで作ったりするけどなあ。
0460デフォルトの名無しさん2010/11/28(日) 19:31:43
>>459
その部分が密結合になってることのリスクを正確に理解した上でならいいかもしれないけどな。
俺なら、まず「設計を見直せ」とアドバイスする。
0461デフォルトの名無しさん2010/11/28(日) 19:42:06
いつもの人は、密結合であることがどれほどリスクが高い状態か理解できてない時点でお話にならん。

ちょっとしたアプリケーションを作ろうとしたら、一人で書いてたとしてもすぐぶち当たる問題だと思うんだけどな。
不思議だ。
0462デフォルトの名無しさん2010/11/28(日) 19:43:07
操作要求を溜め込んだクラスから、
どんな操作があったか実際に読み出せるのは、
その操作対象のオブジェクトだけ。だからfriend。

さあどうやって設計を見なおそう
0463デフォルトの名無しさん2010/11/28(日) 20:07:00
>>462
それだけだとよく分からんが、不精せずに操作要求を受け渡す窓口を作るべきなんでは。
0464デフォルトの名無しさん2010/11/28(日) 20:16:56
ノートＰＣメーカがマザボの部品の型番や接続方法を全部公開しているわけではないだろ
かといってノートＰＣメーカ内部でそれらの仕様を非公開のまま製造するわけでもないだろ

メンバへのアクセス制御で、利用者によって変わってくる部分の制御にfriendは使うべきってことなんじゃない？
0465デフォルトの名無しさん2010/11/28(日) 20:23:00
>>463
外部には操作要求以外の事をやってほしくないので、
操作対象のオブジェクトはconstで提供されるわけだが、
constメソッドでは外部から操作要求を達成できない。
かといってmutable使うのは何か違う気がする。

どうしよう。
0466デフォルトの名無しさん2010/11/28(日) 20:28:03
private, protected, public ではちょっと物足りないってのはあるよな。
0467デフォルトの名無しさん2010/11/28(日) 20:28:27
>>465
constじゃなくて、操作要求しかできないインターフェースを渡すようにすればおｋ
0468デフォルトの名無しさん2010/11/28(日) 20:34:18
>>467
その操作要求用のインターフェースクラスから
どんな操作要求があったかを取り出すには？
当然、操作を受け付けるオブジェクト以外には見えないようにしたい。
0469デフォルトの名無しさん2010/11/28(日) 21:10:56
>>468
操作要求を取り出せるインターフェースと取り出せないインターフェースの2つを用意して、
操作を受け付けるオブジェクトには前者、それ以外には後者を参照させるようにすればおｋ。
0470デフォルトの名無しさん2010/11/28(日) 21:17:01
>>466
OSGiみたいなモジュール単位で制御する仕組み欲しいよね的な話はわりとあるよね。
0471デフォルトの名無しさん2010/11/28(日) 21:49:18
>>468
DBオブジェクトとトランザクションオブジェクトがあって、
コミットするときにDBオブジェクトから要求の中身を取り出すような状況？
だとすればfriend賛成。総合的にはカプセル化を強めることができる。
同じような意味で、Factoryパターンとfriendは相性がいい。
0472デフォルトの名無しさん2010/11/28(日) 22:29:42
>>471
そういう話なら、SpringのTransactionの中身を調べてみるとかいいかもね。
0473デフォルトの名無しさん2010/11/28(日) 23:09:00
>>469
操作要求を取り出せるインターフェースと取り出せないインターフェースのデータのやりとりはどうすんのよ
0474デフォルトの名無しさん2010/11/28(日) 23:41:29
>>473
public interface ReadableQueue<T> {
　T get();
}
public interface WritableQueue<T> {
　void put(T request)
}

public class RequestQueue implements ReadableQueue<Request>, WritableQueue<Request> {
　... （実装）
}

RequestQueue queue = new RequestQueue();
ReadableQueue readable = queue; // 読み出し側にはこのインタフェースで渡す
WritableQueue writable = queue; // 書き込み側にはこのインタフェースで渡す
0475デフォルトの名無しさん2010/11/28(日) 23:59:49
friendより継承の方が結合強いって知らんのか
04764742010/11/29(月) 00:46:10
俺に言ってる？
0477デフォルトの名無しさん2010/11/29(月) 01:02:40
多重継承・・・
04784742010/11/29(月) 01:08:06
インタフェースを複数実装するのは多重継承とは違うぞ。。
0479デフォルトの名無しさん2010/11/29(月) 21:17:35
C#で多重ディスパッチ
http://ufcpp.net/study/csharp/sp4_multipledispatch.html
0480デフォルトの名無しさん2010/11/29(月) 21:44:54
いつもの人だが、C#やるな。少し見直した。
だが、
>ちなみに、 「dynamic の内部実装」 を呼んでもらえるとわかるんですが、 dynamic が内部的にやってることは、この if (s is ...) を動的に生成してるだけだったりもします。
これはいただけないね。

だけどここで興味深いのは、マルチメソッドの呼び出し文法だな。
(obj1, obj2).method()ではなく、func( obj1, obj2 );が採用されてる。
C#は、マルチメソッドを、動的オーバーロードとして実装したわけだ。
まー普通そう考える罠。
だけどどんどんカオスになるな。
obj1.method( (dynamic)obj2, (dynamic)obj3 );
↑3引数での多重ディスパッチ。
将来のことも考えれば、普通に、
func( obj1, obj2, obj3 );って書けたほうがよいよな。
そんで、参照に型情報持たせて、関数テーブルで多重ディスパッチできるようになるといいな。
C#に期待しとくか。
0481デフォルトの名無しさん2010/11/29(月) 22:07:11
とはいっても、単一ディスパッチを前提としたクラス単位のvtableとマルチメソッドの相性は最悪だから、
これからどうするんだろうね。
真面目にマルチメソッドをやるなら、俺の言ってる、参照に型情報を持たせる&型推論しかありえないのだが、
いまさらそんな魔改造は無理だよな。全部捨てるしかw
0482デフォルトの名無しさん2010/11/29(月) 22:17:08
× C#
○ .NET Framework 4.0

.NET 4.0で動的型言語(IronRuby, IronPython, etc..)を正式にサポートするようになったが、
dynamicキーワードは、C#側から動的型言語のオブジェクトと連携するための機能。
http://ufcpp.net/study/csharp/sp4_dynamic.html

C#自体が静的型言語である以上、多重ディスパッチは「そういうこともできる」という以上の意味はない。
つうか、C#自体の設計は変わってないんだからfunc( obj1, obj2 )としか書きようがない、というだけの話。

まぁ、素直にPythonかRuby使っとけ。
0483デフォルトの名無しさん2010/11/29(月) 22:38:25
なんだがっかり。MSもマルチメソッドにやる気なしか。
ifelse実装とか変だと思った。期待しないでおこう。
0484デフォルトの名無しさん2010/11/29(月) 22:59:00
>>481
> 参照に型情報を持たせる&型推論

そこまではC#の例も一緒なんだが、型情報使って分岐する以外に
コンパイラはどういうコードで動的にディスパッチすれば良いんだ？

つかな、そもそも多重ディスパッチがどうとかいう問題じゃなくて
グローバルなネームスペースで対等なオブジェクト同士が協調する時、
メソッドが
0485デフォルトの名無しさん2010/11/29(月) 23:01:15
途中で書いてもた。

メソッドがどのオブジェクトにも属せず宙に浮くのが問題なのであって、
マルチメソッドそのものはあまり問題じゃない。
0486デフォルトの名無しさん2010/11/29(月) 23:37:05
>>482
実際のところマルチメソッドもダックタイピングもグルー言語位でしか
使い道がなさそうだしな
0487デフォルトの名無しさん2010/11/30(火) 00:09:43
>メソッドがどのオブジェクトにも属せず宙に浮く

1．ネームスペースに属す。
2．Cでいうstatic。ファイル単位のグローバル空間。
3．動的オーバーロードだから名前が衝突しても問題なし。

C++のテンプレートは静的オーバーロードに頼った多態を多用するけど、
何か困ったことあるか？
std::findとかstd::sortとか。
0488デフォルトの名無しさん2010/11/30(火) 00:11:00
あ、
>2．Cでいうstatic。ファイル単位のグローバル空間。
は、ファイル単位でのグローバル空間に属するようなことも出来るだろうってことね。
ファイル外には公開しない奴な。
0489デフォルトの名無しさん2010/11/30(火) 01:42:43
>>487
状態やコンテキストがごっちゃになることを防げない。
0490デフォルトの名無しさん2010/11/30(火) 07:26:18
>>487
単純にOOとPOを混ぜると設計の一貫性が無くなって分かりづらい。

std::findとかstd::sortとかはコンテナのメンバ関数から呼ぶか、
OOPしない時に使うか、のどっちかじゃない？
0491デフォルトの名無しさん2010/11/30(火) 19:11:56
vtableとマルチメソッドには共通点もある。
それは「オブジェクトの型を (明示的に) 調べてはいけない」というルール。
このルールにより、古いコードに新しい型を「結合」できる。

マルチメソッドが密結合であるとは限らない。
0492デフォルトの名無しさん2010/11/30(火) 19:35:33
新しい実装クラスが増える度に明示的に定義しないといけないなら以下略。
0493デフォルトの名無しさん2010/11/30(火) 20:45:37
Acceptorが増える度にVisitorを修正しないといけない問題がそのまま残る。
そのまま。
結合度が高くなったとは言えない。
0494デフォルトの名無しさん2010/11/30(火) 21:08:55
何が言いたいのかよく分からないんだが。
0495デフォルトの名無しさん2010/11/30(火) 21:15:23
結合度っていうより参照度？
0496デフォルトの名無しさん2010/11/30(火) 21:34:24
>>494
今さらなにを言ってるんだ
OOPがよく分からないのは当たり前だろ
0497いつもの2010/11/30(火) 21:37:34
お前に100点
0498デフォルトの名無しさん2010/11/30(火) 21:46:35
>>489
マルチメソッド対応言語だからといって、シングルディスパッチしてはならないわけではないぞ。
update( obj )とか好きにすれば良い。

void func( obj1, obj2 )
{
　　set_value( obj2, get_value( obj1 ) );
}

C言語でもやってたことだろ。
ただ、関数の型に応じて関数がswitchするってだけだよ。

だいたい、
単一ディスパッチはOK、
静的オーバーロードもOK、
マルチメソッドはNG、
って主張は説明がつかないよ。

C++やJavaが単一ディスパッチなのは、単に手抜きってだけだしな。
MS的には、COMとの絡みもあるし、アレなんだろうが。
かなり昔にまで遡らないと、流れを正せないな。
まーお得意のマーシャリングでなんとかするのかね。
0499デフォルトの名無しさん2010/11/30(火) 22:01:42
マルチメソッドを導入することでOOP的には
どういうメリットがあんの？

マルチメソッドの機構よりもそっちを説明してくれよ
0500デフォルトの名無しさん2010/11/30(火) 22:09:06
OOPでなくなるのがマルチメソッドのメリットだから、
OOP的にはメリットが無い。
OOPの縛りが無くなって、普通に戻る。ただし、OOP以上の機能は有している。
それだけ。
0501デフォルトの名無しさん2010/11/30(火) 22:26:32
クラスというか型を定義したりそれのインスタンス使ったりしないの？
0502デフォルトの名無しさん2010/11/30(火) 22:29:07
使うんじゃない？
struct hoge_t{ int piyo; };
init( hoge_t *hoge ){ hoge->piyo = 0; }
0503デフォルトの名無しさん2010/11/30(火) 22:38:31
OOP以上の機能は有しているつーよりも
OOPにマルチメソッドついただけだな
>>482じゃないがRubyかPythonつかえばいいじゃない
0504デフォルトの名無しさん2010/11/30(火) 22:41:22
でも困ったことにデストラクタだけは欲しいんだよなー。
あれだけはOOPの功績だよ。
GCは微妙だなぁ。
いつ開放されるか解らないし、メモリ以外のリソースが絡むと役に立たないしな。
C#も開放周りはカオスだしな。
開放用のメソッドが、スタックが巻き戻る時に呼ばれるのと、GCから呼ばれるので二つあるんだっけか。
とくに後者はいつ呼ばれるかも解らないから、バグるとデバッグ困難だしなぁ。
結局メインメモリのリソースしか面倒見てくれないってのもなんだ中途半端な感じだしなぁ。
もうちょっと上手いやりかたは無いもんかね。
CGは糞だね！って言えるような代替アイデアが思い浮かばんから困る。
0505デフォルトの名無しさん2010/11/30(火) 22:46:02
もう一度、疎結合の重要性について演説しないとならないか。
0506デフォルトの名無しさん2010/11/30(火) 22:46:39
しかも、どの順番で開放関数が呼ばれるか解らないってのも、痛かったり。
手続き型ってのは手順が明確だから良い・・・というか、それが前提なわけで。
どの順で呼ばれても良いように書かなきゃならないのは、しんどいな・・・。

C++でグローバルオブジェクトの初期化順が不定で、使い物にならないのと同じ臭いがする。
手続き型手続き型手続き型あれあれあれあれ。
0507デフォルトの名無しさん2010/11/30(火) 22:54:39
>>499
RTTIで一々型判別しなくても良くなります
0508デフォルトの名無しさん2010/11/30(火) 23:11:16
動的言語の場合、とりあえずポインタで間接参照すれば疎結合になる
動的じゃない場合、ポインタで指せないものが色々あるので密結合になりがちである
0509デフォルトの名無しさん2010/12/01(水) 00:40:00
疎結合、密結合ってそういう意味なんだったか？
0510デフォルトの名無しさん2010/12/01(水) 01:44:06
オブ脳な奴って、どうすれば判断できる？
0511デフォルトの名無しさん2010/12/01(水) 01:47:39
オブ脳とか言い出さない奴。
■ このスレッドは過去ログ倉庫に格納されています