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

OOP 2

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

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

http://hibari.2ch.net/test/read.cgi/tech/1284115490/
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
オブ脳とか言い出さない奴。
0512デフォルトの名無しさん2010/12/01(水) 01:50:18
得意な言語にJavaとC++を挙げる奴。
0513デフォルトの名無しさん2010/12/01(水) 01:52:21
オブ脳あるって奴のクラス図みたら、クラスがすべて機能。
失笑。
0514デフォルトの名無しさん2010/12/01(水) 01:56:07
OOPはDOAとは違うんだし、機能に傾倒してもいいんじゃね？
0515デフォルトの名無しさん2010/12/01(水) 02:00:14
乳揺れ？
0516デフォルトの名無しさん2010/12/01(水) 02:32:02
>>509
疎結合とは、コンポーネントが他のコンポーネントの定義をほとんど知らないこと。

ダックタイピングは、外部のコンポーネントに一方的に条件を突きつける。
外部で実際には何が定義されているかなど知ったことではない。
0517デフォルトの名無しさん2010/12/01(水) 06:39:09
ダックタイピングはぶっちゃけハッシュ辞書（連想配列）に関数突っ込んだものと一緒だからな
キーが見つかればそれを呼ぶ、無ければ値がないから呼べない、という感じ
その際、相手の型なんて気にしていない、キーが存在するかどうかだけ

…というかJavaScriptがホントに連想配列とオブジェクトを同一存在として実装してるんだよな
x["hello"] = function(){ alert("Hello") }
x.hello()
なんてコードがマジでまかり通る
0518デフォルトの名無しさん2010/12/01(水) 08:36:35
>>517
Rubyといっしょだな
0519デフォルトの名無しさん2010/12/01(水) 09:08:48
>>518
ん？一緒か？
RubyのHashにキー追加してもそれはメソッドにならず
Objectにメソッド追加してもHashとしては使えないと思うが

それともダックタイピング共通の要素の部分について言ってる？
0520デフォルトの名無しさん2010/12/01(水) 11:30:24
外見から内部を想像して凝り固まってるんすね
0521デフォルトの名無しさん2010/12/01(水) 19:30:53
だけどハッシュだと遅いし、単一ディスパッチのvtableの優位性を壊せないから、
JavaやC++信者に変な言い訳をする余地を与えてしまう。
「マルチメソッドは便利で、対象性があって綺麗かもしれないけど、
　単一ディスパッチの方が、たとえ非対称でも実行効率が良いし、
　目的に応じて使い分ければいいんじゃね？」
とか言い出しかねない。
だから、ハッシュじゃなくて、単純なテーブルを使った
hoge_func_vtable [ ptr1->type ][ ptr2->type ]( ptr1->pointer, ptr2->pointer );
の方が良い。

オブジェクトにvtableを持たせるのではなく、
ポインタに自分の指してる型の型情報を持たせるってのがポイント。
C++のshared_ptrで使われてる手法。

とにかく、従来のオブジェクトにvtableを持たす方法は、何の将来性もないし、
不自然だし、まずいやり方だと言うことを認識させて、改めてもらうこと。
そんで、単一オブジェクトのvtableに頼った設計も糞だと発見してもらうこと。
ポインタに型情報を持たせる方法だと、intやdoubleといった基本型での動的多態すら可能。
インスタンスが型情報を持ってるわけではなく、ポインタが型情報を持つからこれが出来る。
それが便利だって言ってる訳ではないぞ。いかに自然かって事。基本型で多態できないのは、不自然だろ。

自然な言語仕様だから、自然な思考回路になり、自然な設計が出来るというもの。
対象性のある言語に対象性のある設計。非対称性はカオスの元。
解ってて使う分には構わないのかもしれないが、毒されりゃそりゃOO脳だ。
第一引数だけ特別扱い病。第一引数に機能ぶら下げ病。
プログラム設計するときに、クラスやオブジェクトのvtalbeが頭に浮かんで、
設計=vtableを組み立てること、ってなったらもう終わり。すっかりOO廃人。
0522デフォルトの名無しさん2010/12/01(水) 19:36:36
OO脳だがvtableなんて意識したことないな。
その論だと、むしろ意識しちゃってるおまいが一番のOO廃人なんじゃね？
0523デフォルトの名無しさん2010/12/01(水) 20:07:07
多態なりなんなり（機能）が重要なのであって、vtable（実装方法）とかどうでもいいわけだしな。
0524デフォルトの名無しさん2010/12/01(水) 20:52:19
自然な言語って料理のレシピみたいな手続き型で機能中心指向なもののことか
0525デフォルトの名無しさん2010/12/01(水) 21:03:22
手続き型はコンピュータにとっても自然だしな。人間からコンピュータまでフラットってことだよ。
0526デフォルトの名無しさん2010/12/01(水) 21:05:35
マルチディスパッチ自体が悪いんじゃなくて、
「マルチディスパッチがあれば、オブジェクト指向を置き換えられる」という発想がおかしいんだな。

func1(a_t val1, b_t val2) { ... }
func2(a_t val1, b_t val2) { ... }
...

これらの関数は、どう逆立ちしたって a_t や b_t に密結合したものにならざるを得ない。
もし、どれかのデータ構造やアルゴリズムが変わったら、関連する関数を全て修正する必要が出てくる。
関数の種類 × 型同士の組み合わせの数だけそういう箇所が出てくるんだから…後は分かるな？

「メソッドはただ一つのオブジェクトに結びつく」というのは、責務を一つのオブジェクトにのみ負わせることで、
疎結合を実現するための手段なんだよ。機能を実現するために依存するオブジェクトが増えれば増えるだけ、
コードのメンテナンスは困難になる。
0527デフォルトの名無しさん2010/12/01(水) 21:09:01
>>525
NAND回路＜・・・
全加算器＜・・・
0528デフォルトの名無しさん2010/12/01(水) 21:10:38
なんで、マルチメソッドだと単一ディスパッチが使えないって発想になるのかがわからない。
func1(a_t val1, b_t val2) { set_value( val2, get_value( val1 ) ); }
とかすりゃ良いだろ。ただ、多重ディスパッチも出来ますってだけで。
第一、静的オーバーロードは既に普及している訳で。
0529デフォルトの名無しさん2010/12/01(水) 21:13:10
>>527
そんなもんは、電卓にすらある。
プログラマブルってことは、プログラムカウンタがあるってことだ。
=手続きってことだ。
05305262010/12/01(水) 21:14:56
>>528
その例だと、set_valueに依存性の問題を先送りしてるだけのように見えるが。
0531デフォルトの名無しさん2010/12/01(水) 21:18:34
>>530
だったら、obj->set_value( hoge_t hoge )でも同じことだよ。

>「マルチディスパッチがあれば、オブジェクト指向を置き換えられる」という発想がおかしいんだな。
この発言のアホさ加減がわからないの？
単一ディスパッチは多重ディスパッチに含まれるんだよ？
多重ディスパッチで無理なことは、単一ディスパッチでも無理だよ。ちょっと考えれば・・・考えなくてもわかることだろ。
どうしたら良いんだろうね。
0532デフォルトの名無しさん2010/12/01(水) 21:24:24
>>529
Haskell＜・・・

というのはともかく、コンピュータの本質は論理回路であり、
そして、論理回路そのものに手続き的な概念は存在しない。
現在のコンピュータで手続き型が自然に扱えるのは、
手続きが自然に扱えるようなアーキテクチャを持ったコンピュータが主流だから、というだけのこと。

「手続き型は手続きでプログラムできるアーキテクチャにとって自然だしな」なら使っていい。
0533デフォルトの名無しさん2010/12/01(水) 21:26:24
スレ汚しでしかない
0534デフォルトの名無しさん2010/12/01(水) 21:27:15
>>531
マルチディスパッチという方式について、>>526のどこで批判しているのか、
具体的に指してくれないか。
0535デフォルトの名無しさん2010/12/01(水) 21:29:11
自分の書いた文章ぐらい自分で読めるだろうによ・・・
こんなのしか居ないんかい。
0536デフォルトの名無しさん2010/12/01(水) 21:31:50
>>535
一行目で、

> マルチディスパッチ自体が悪いんじゃなくて、
> マルチディスパッチ自体が悪いんじゃなくて、
> マルチディスパッチ自体が悪いんじゃなくて、

と書いてあるのは読めるんだけどなぁ。
0537デフォルトの名無しさん2010/12/01(水) 21:32:53
つーか、俺、お前がマルチディスパッチに否定的だって言ってないよな。
>「マルチディスパッチがあれば、オブジェクト指向を置き換えられる」という発想がおかしいんだな。
この一文に言及しただけで。

俺がむしろ聞かなきゃならんのか。
>>534について、俺がいつそんなこと言ったんだって。もう何もかもがおかしいよ。
出鱈目すぎて会話が機能してない。
0538デフォルトの名無しさん2010/12/01(水) 21:37:26
a_tとb_tは型変数なんだろ
型は変数に入れられないと考えるから密結合になる
型変数という発想ができないと疎結合は難しい
0539デフォルトの名無しさん2010/12/01(水) 21:40:25
それは、C++やJavaも同じじゃねーか。
0540デフォルトの名無しさん2010/12/01(水) 21:55:09
多重ディスパッチの話題は荒れるだけでなにも得るところがないな
すぐ実装よりになるし
0541デフォルトの名無しさん2010/12/01(水) 22:00:59
なぜ荒れるんだろうな。不思議不思議。
完全なOOPなら、マルチメソッドも実装されててしかるべきだし、
C風のスタイルが好きな人にも受け入れやすい仕組みと文法のはずなのに。
誰もが納得できそうな仕組みなのになぁ。不思議不思議
0542デフォルトの名無しさん2010/12/01(水) 22:02:47
マルチメソッドって何だかめんどくさそう
もし引数をk個とる関数があったとして、型がt種類あったらtのk乗個のメソッドを書かなくちゃいけないの？

例：
型a, b, cのいずれか2つを取るfuncがある場合、
func(a, a) func(a, b) func(a, c) func(b, a) func(b, b) func(b, c) func(c, a) func(c, b) func(c, c)通りの組み合わせが考えられる。


引数の組み合わせ爆発で大量のメソッドを誘発する臭いがぷんぷんするのはどうにかならないわけ？
一体何がスマートに書けるのかよくわかんね。
0543デフォルトの名無しさん2010/12/01(水) 22:06:45
要求仕様上、組み合わせ爆発が起こったときに、それを記述するためのものだからね。
要求仕様がそうなら、もう仕方ないでしょ。爆発に付き合うしか。
0544デフォルトの名無しさん2010/12/01(水) 22:11:53
>>541
最近のOOPLはたいてい使えるだろ
0545デフォルトの名無しさん2010/12/01(水) 22:12:51
>>543
そもそも、それを記述できるようにしなければならないという発想が余人には理解し難い
0546デフォルトの名無しさん2010/12/01(水) 22:14:21
>>543
共通インターフェースを作って多態させる
従来のシングルディスパッチの方がスマートに書ける気がする。
0547デフォルトの名無しさん2010/12/01(水) 22:16:33
>>542
それマルチメソッドかどうかに全然関係なくないか？
ふつーのOOPLでその要求を満たそうとすると、
型a, b, cにそれぞれa, b, cを引数に取るオーバーロードされたfuncを作るんだろう
つまり

a#func(a), a#func(b), a#func(c)
b#func(a), b#func(b), b#func(c)
c#func(a), b#func(b), c#func(c)

こうなる
全くおなじ話だと思うんだが
0548デフォルトの名無しさん2010/12/01(水) 22:21:45
>>545
記述できたったて何の問題ないだろ。問題の無さこそが重要なんだと思う。

>>547
そそ、概ねそういうことが言いたかった。
要求仕様が複雑だと、どう書いても、複雑になるんだ。
問題の抱えてる本質よりは、どうあがいてもシンプルにはならないんだ。
仕様が爆発してたら、プログラムも爆発する。
言語でどうにかなるのは、せいぜい記述性だけだろう。
対象性のある言語の方が制限が少ないから素直に書き下せる可能性が高いってだけ。
0549デフォルトの名無しさん2010/12/01(水) 22:24:05
んで、>>526への反論はまだ？
0550デフォルトの名無しさん2010/12/01(水) 22:26:20
>>546
その要求仕様は、共通のインターフェースを作れるってことは、爆発してないんだよ。
マルチディスパッチは単一ディスパッチもサポートするんんだから、
共通のインターフェースを作って纏めたい場合は、それを使えばいいじゃない。
0551デフォルトの名無しさん2010/12/01(水) 22:28:26
>>548
なぜ、仕様だけは運命論的に受け入れるべきとなるのか。
0552デフォルトの名無しさん2010/12/01(水) 22:28:49
責務君は、自分の責務のことしか考えない、自己カプセル化野郎だから、
コミュニケーションは無理なんだよ。
0553デフォルトの名無しさん2010/12/01(水) 22:32:20
>>551
自分のやりたいことや、顧客からの要求なんだから、仕方ないだろ。なんじゃこりゃ
0554デフォルトの名無しさん2010/12/01(水) 22:38:14
>>552
× 自分の責務のことしか考えない
○ 全ての責務を一手に引き受けて調整しようとする試みは必ず破綻する

>>553
要求仕様から、実装しやすい設計を考えればいいじゃない。
■ このスレッドは過去ログ倉庫に格納されています