結局OOpが役に立たないのはなぜ?
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/04/14(水) 01:14:080052デフォルトの名無しさん
2010/04/18(日) 21:50:11お前か？
0053デフォルトの名無しさん
2010/04/18(日) 22:05:080054デフォルトの名無しさん
2010/04/18(日) 22:47:331. 構造体＋操作関数である
2. 責務である
3. アクターである
4. 抽象概念である
のどれ？
0055デフォルトの名無しさん
2010/04/18(日) 23:35:49だから、中置記法だと引数が二つしか取れねーだろーがよ、馬鹿かよ。
0056デフォルトの名無しさん
2010/04/18(日) 23:49:07前置記法だと、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いいから>>48の式を中置記法に直してみるんだ。
そもそも、(+ 1 2 3)は(+ 1 (+ 2 3))の糖衣構文なわけだがね（結合則が逆かも）。
そもそも、>>47の言う通り、そういう引数の取り方が自然な時はそうすればいい。
そして、その書き方は二項演算の組み合わせによる表現とは全く等価で矛盾しない。
0058デフォルトの名無しさん
2010/04/19(月) 00:01:49C言語の標準関数
char *fgets(char *s, int n, FILE *fp);
を中値記法で書いてみろ。
0059デフォルトの名無しさん
2010/04/19(月) 00:04:58まず、その問題系の演算規則を定義してください。
0060デフォルトの名無しさん
2010/04/19(月) 00:07:420061デフォルトの名無しさん
2010/04/19(月) 00:12:540062デフォルトの名無しさん
2010/04/19(月) 00:18:43fgetsはsもnもfpも同時に使う。結合の順序なし。
早く中値記法で書いてください。
0063デフォルトの名無しさん
2010/04/19(月) 00:29:190064デフォルトの名無しさん
2010/04/19(月) 00:32:09これに突っ込まれても困るけどな。
そもそも>>58が、どんな前提条件において何を想定してるのかが分からないわけで。
0065デフォルトの名無しさん
2010/04/19(月) 00:44:32副作用が出るわけだから無意味だわな。
それから、関数呼び出しを中置記法ですることについて今話していることぐらいは分かってるよな。
>>64
意外にきれいに書けたね。
でも、こう書ける場合ばかりじゃない。
copyTo(s)でもう一度nが必要な場面もあるからな。
0066デフォルトの名無しさん
2010/04/19(月) 00:47:30がんばって2つのオペランドになるように分解しても、
こんどはオペランドを同時に扱えない。
関数呼び出しには不適切ということ。
0067デフォルトの名無しさん
2010/04/19(月) 07:52:250068デフォルトの名無しさん
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:12fp.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だろう常考
0071デフォルトの名無しさん
2010/04/19(月) 14:42:250072デフォルトの名無しさん
2010/04/19(月) 16:40:40x1, x2,... -> (x1, x2, ...)
のような演算を考えると、単純に2項演算に分割できないよね
単純に2項に分割して逐次適用すると
(((x1, x2), x3), x4...)
のようになってしまう
0073デフォルトの名無しさん
2010/04/19(月) 18:31:45あと、仮に弊害があるとして、それはどの程度のインパクトなの？
0074デフォルトの名無しさん
2010/04/19(月) 18:32:39弊害って、見てわかんないの？
フラットなリストと入れ子のリストは別もんでしょ
0075デフォルトの名無しさん
2010/04/19(月) 18:43:44LISPは見たことがないの？
0076デフォルトの名無しさん
2010/04/19(月) 18:47:57ああなるほど
Lispのlist関数だと思えば、consで実現できる
タプルのような、consの組み合わせで表現されない構造を作りたいのだと
思ってくれ
俺が本当に念頭に置いていたのはzipやzipWithの類だけど
0077デフォルトの名無しさん
2010/04/19(月) 18:55:59OOなら典型的には
foo.zipWith(other)
のように、2つのリストをペアリングするインタフェースになる
これは
zip(L1, L2, L3...)
より劣る
そして残念ながら、zipWithを数回繰り返して同じ結果を得ることはできない
0078デフォルトの名無しさん
2010/04/19(月) 19:50:22で？
0079デフォルトの名無しさん
2010/04/19(月) 19:52:310080デフォルトの名無しさん
2010/04/19(月) 19:54:47強いていえば、上の例で分かるように
OO的な記述が向いている時と向いていないときがあるので、
OO至上主義的な、ピュアOOみたいなのは俺は苦手
マルチパラダイムになっていると嬉しい
0081デフォルトの名無しさん
2010/04/19(月) 19:57:460082デフォルトの名無しさん
2010/04/19(月) 19:59:35「N項演算において、先頭の1個をとりあえずレシーバとする」みたいなやり方は
バイナリ演算よりも、さらに不自然さが際立つだけだろう
数学的には対等なオペランドでしかないんだから、概念を的確に
モデル化しているとは到底いえない
0083デフォルトの名無しさん
2010/04/19(月) 20:07:02演算を考える
intやdoubleの加算のようなものだ
演算が可換な場合は、関数的に記述すればオペランドを交換できるので、
ずっと実装がシンプルで済む
OOスタイルでは、こういうことは不可能だな
0084デフォルトの名無しさん
2010/04/19(月) 20:13:56「N項演算を表現できないOOは破綻している！」とか言われても意味が分からん、という話。
あと、仮に二項演算で実装するにしろ、ユーザに見せるAPIはラップして提供すりゃいいわけだしな。
（もちろん、N項演算として実装してそれを見せたっていい。どちらが最適かは状況による）
さらに言えば、N項形式で表現した方が（ユーザが）分かりやすい場合があるのはいいとして、
それがOOのコンセプトを全面的に棄却する必要があるほど一般的かつクリティカルかどうか。
0085デフォルトの名無しさん
2010/04/19(月) 20:14:41俺のレスが読めないの？
「全面的に棄却しろ」とは一言も言っていないんだが
>>80読めよ
0086デフォルトの名無しさん
2010/04/19(月) 20:16:39だから、そこで言ってる「OOスタイル」って何のこと？ ちゃんと定義して。
0087デフォルトの名無しさん
2010/04/19(月) 20:17:40ああ、あんまり厳密な議論ではないけど
1.add(2.0)
みたいなものだと思ってくれて構わない
どっちかのオペランドをレシーバにする
0088デフォルトの名無しさん
2010/04/19(月) 20:20:24俺は、そういうことを言ってた奴向けに反論を書いてたんだよ。
適切な記述を実現できるなら、マルチパラダイムが悪いとは全く思わない。
0089デフォルトの名無しさん
2010/04/19(月) 20:21:27なるほど、なら俺らは別にケンカする必要は無いね
stackやqueue、GUIみたいなものに非常にOOが向いているのは俺も同意するし
0090デフォルトの名無しさん
2010/04/19(月) 20:27:27>>84でも書いたが、レシーバを特定しない形で記述するのが自然ならそうすればいいと思うよ。
Singletonパターンにしても、「推奨されない」けどパターンの一つなわけだしね。
>>89
同意感謝。
0091デフォルトの名無しさん
2010/04/19(月) 20:36:390092デフォルトの名無しさん
2010/04/19(月) 21:53:57> つうか、別に三項以上でも、委譲を使えば(中置記法で書くのに)多くの場合は困らんけどな。
> 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お前はまず人の話をちゃんと聞くところから始めろ。
0094デフォルトの名無しさん
2010/04/19(月) 22:12:13>これらが静的型言語だからであってOOの問題ではない。
静的型言語であることと、多重ディスパッチをサポートしないことにはなんら関係はないだろ。
サポートしない理由は単に、手抜き&実行時のコスト&分割コンパイル云々 ってだけだ。
>>93
まずもって、「obj1.method(obj2, obj3);」が三項の中置記法で、
obj1 operator obj2 obj3 の並びになってる。
この並びを許すのなら、前置記法と中置記法は等価だし、何も問題ない。
でも、中置って普通二項だろ。三項以上とる演算に中置記法使うのがキモイと散々言ってるわけで。
むりに二項に分解すると、オペランドを同時に参照できなくなるし、
素直に前置記法か後置記法でいいだろ。そうすれば何の問題も出ないわけで。
あえて中置記法つかう意味はあるか？ないだろ。素直に考えろよ。
JavaやC++は間違ったんだよ。でも間違いは誰にでもあることだ。
0095デフォルトの名無しさん
2010/04/19(月) 22:21:240096デフォルトの名無しさん
2010/04/19(月) 22:35:31object1.method( object2, object3 );
という文法を維持したまま、どう拡張しえるんだ？
普通に考えれば、多重ディスパッチは動的オーバーロードなわけで、
JavaやC++にはすでに静的オーバーロードがあることを考えれば、
動的オーバーロードをサポートする形で多重ディスパッチをサポートすることになるわな。
てことは、func( object1 );でポリモするし、
従来の仮想関数の記法は、ただのキモい古傷になるわな。
object1.method( object2, object3 );
あー何度見てもキモい。第一引数のみ特別扱い。ドットと括弧の対象性も悪い。
func( object1, object2, object3 );
きれいだなー。
0097デフォルトの名無しさん
2010/04/19(月) 22:38:47OO何もわかっていないな。
0098デフォルトの名無しさん
2010/04/19(月) 23:01:42ただ、
メソッド呼び出しの文法は、func( obj1, obj2, ... );のスタイルで統一しときゃよかったのに。
後の祭りだな。
なんつーか、はしゃいじゃったんだろうな。
パラダイムシフトだーとか言って、第一引数だけ前に出して、
「ほら、オブジェクト主体だー」とか、何かそういう主張がしてみたい時期だったのだろうか。
今までとは違うってことをアピールしたかったのだろうか。よーわからん。
何処まで行っても手続き型プログラムの主体が、
その名のとおり、「手続き」であることは変わりようが無いのにな。
0099デフォルトの名無しさん
2010/04/19(月) 23:07:33適材適所で使えば良いだけだろ。
0100デフォルトの名無しさん
2010/04/19(月) 23:23:36この辺は頭悪かったな。あえて変える必要は無かったわな。
せっかくオーバーロードはCのスタイルを維持したのにな。
>>99
いわゆる今あるC++のOOPは、構造体のセッターとゲッターを定義する特殊な構文として、
OOPとは切り離して、なにか別のものとしてしまった方が良かったのかもしれない。
カプセル化機構とか適当な名前つけてさ。
別で動的オーバーロード(マルチメソッド)をサポートして、
そっちをポリモ機能(OOP機能)と称すれば良かったのではないかな。
要は、ポリモ機能とカプセル化機能を其々独立する。
俺が言語設計するなら、そうするな。
0101デフォルトの名無しさん
2010/04/19(月) 23:35:00{
obj1.set_value(0); //←カプセル化機能
}
あーすっきりした。
つまるところは、カプセル化機能のついでに、同じところにポリモ機能も押し込めちゃってたから、
無理が出てたんだな。
これからはこれで行こう。
0102デフォルトの名無しさん
2010/04/20(火) 00:03:31しかも、ポリモと言ったとき、カプセル化の意も含んでる場合もあるし、逆もまたある。
そういった状況だから、オブジェクト指向という抽象的な言葉で曖昧に表現してきたわけだ。
オブジェクトの振る舞いを定義して〜とかの変な話にもなった。
ポリモという言葉は曖昧だから、動的オーバーロードと表現するとする。
カプセル化という言葉も曖昧だから、アトミック操作と表現するとする。
動的オーバーロードとアトミック操作を明確に区別して、別々の構文を用意する。
すると、オブジェクト指向という言葉はもう要らないわな。
なんせ、
動的オーバーロードがしたい場合は、それ用の構文を使う、
アトミック操作がしたい場合は、それ用の構文を使う、
ただそれだけのことだからな。
消えてなくなったねオブジェクト指向、万歳。
すばらしい整理力だね、今日は気持ちよく眠れる。
0103デフォルトの名無しさん
2010/04/20(火) 01:07:360104デフォルトの名無しさん
2010/04/20(火) 01:14:28モジュールより型クラスだろjk
オーバーロードなんだから
010593
2010/04/20(火) 07:59:55オーケー、オーケー。
そこまで言うなら、もう、新しくそういう言語処理系を作ってコンセプトを実証してくれよ。
名前は"No More Object"でNoMO言語とかでどうだ？
向こう見ずな信念がイノベーションを起こす可能性も無いとは言えないしな。
俺は応援してるぞ。うん。
というわけで、百の言葉より一のコードだ。早速取り掛かっておくれよ。
0106デフォルトの名無しさん
2010/04/20(火) 08:08:35>102の話はHaskellの型クラスの話だと思われ
有用性は既に実証されている
0107デフォルトの名無しさん
2010/04/20(火) 08:09:59解説して。
0108デフォルトの名無しさん
2010/04/20(火) 08:15:22ある局面において有用、というのはもちろんそうだろうけど、アンチOO君が言ってるのはそういうことじゃないしな。
0109デフォルトの名無しさん
2010/04/20(火) 12:18:21map(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:120112デフォルトの名無しさん
2010/04/20(火) 19:56:23電子レンジで卵が調理できないことと、
電子レンジというコンセプトそのものの是非は何の関係もない。
ところで、Haskellはダメだなんて主張してる奴はいたか？
0113デフォルトの名無しさん
2010/04/20(火) 20:48:430114デフォルトの名無しさん
2010/04/20(火) 21:01:200115デフォルトの名無しさん
2010/04/20(火) 21:07:35method(obj1, arguments... )
の形式だな
最近
obj1.method(arguments ...)
の書き方もできるようになったみたいだけど
0116デフォルトの名無しさん
2010/04/20(火) 21:47:57電磁波っていうか遠赤外線は大事
結局電磁波だけど
0117デフォルトの名無しさん
2010/04/20(火) 23:32:49どんな勉強したら、そんなアホな考えになるんだ？
オブジェクト指向が良い悪いと言う前に
もう一度、イチからオブジェクト指向を勉強した方がいいぞ。
0118デフォルトの名無しさん
2010/04/20(火) 23:42:53いつもそう
まぁ、所詮定義も糞もない文系脳の生み出した経験論だからしょうがないか
0119デフォルトの名無しさん
2010/04/20(火) 23:50:500120デフォルトの名無しさん
2010/04/21(水) 01:27:39・メッセージング
・カプセル化 / 継承 / ポリモーフィズム
あと何かあった気がするが、とりあえず…
メッセージングとカプセル化は、結構別物だと思う。
どの階層で纏め上げるかによるけど、「抽象化」が大事なんじゃないかなー。
例えば、ファイルなら、ファイルという抽象化オブジェクト。
後は、ファイルの操作をオブジェクトにつければよい。
内部処理は、さらに下位層での話しになる。
0121デフォルトの名無しさん
2010/04/21(水) 08:16:48http://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通りすがりの2chネラ 2008/05/20 14:47
今回元ネタふったのは私なんで, 謝罪に参りました。ご迷惑をお掛けしたようで申し訳ございませんでした。
根がハード屋なもんで, 個人的には「自分がなにすりゃいいか分かってるもの」にコマンドなりメッセージ送りつけて
勝手に動いてくれればオブジェクトなんですけどねぇ。なんで, みんな流儀にこだわるんでしょうか?
0124デフォルトの名無しさん
2010/04/21(水) 09:37:13それなんてErlang？
0125デフォルトの名無しさん
2010/04/21(水) 09:41:06自分がどこまでやるか？
どこから別のオブジェクトに任せるか？
の切り分けが難しいです
0126デフォルトの名無しさん
2010/04/21(水) 10:24:48それアクターモデルとかπ計算とかだよね
でも「メッセージパッシング」といわれて、そういうものを想定するのは
結構自然な発想のような気はする
0127デフォルトの名無しさん
2010/04/21(水) 11:07:52が流行ったのは、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ううん。なるほどねぇ。と考えると、現状がやっぱり最適なのかね。
obj.method(arg)の形がキモイっていうのはちょっとだけ思ったけど、代替案とかないかなぁ。
(obj,arg)->Add
(obj,arg)->Sub
(obj,arg)->Multiply
こんな感じで、引数を先に書いておいて、関数を書いてみるとか。
IDEは、引数から関数を絞り込んでおくとかね。
0129デフォルトの名無しさん
2010/04/21(水) 12:51:18それなんてFORTH？
0130デフォルトの名無しさん
2010/04/21(水) 13:43:54http://pc12.2ch.net/test/read.cgi/tech/1271086841/
0131デフォルトの名無しさん
2010/04/21(水) 14:06:12F#のパイプライン演算子とかそれに近いかもね
0132デフォルトの名無しさん
2010/04/21(水) 14:24:50>>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やり方が悪いから爆発させているのであって、だからと言って電子レンジで卵を調理できないと
結論付けるのはいかがなものか。
0134デフォルトの名無しさん
2010/04/21(水) 15:29:160135デフォルトの名無しさん
2010/04/21(水) 19:06:29「素人にはおすすめできない」くらいでどうだ。
0136デフォルトの名無しさん
2010/04/21(水) 19:40:30いいね。
0137デフォルトの名無しさん
2010/04/21(水) 20:58:25>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メソッド名じゃなくて、引数を補完すればよいと思う。
func(
まで書くと、取りうる型でかつ参照可能なインスタンスを列挙する。
関数名は一つなのに対し、引数は複数取りうるわけだから、そっちを補完したほうが便利じゃね？
あと、関数名はマニュアルに載ってて決まりきってるけど、
変数名は皆バラバラに付けるし、マニュアルにも載ってないから、
そっち補完したほうがいいのでは。
0140デフォルトの名無しさん
2010/04/21(水) 21:35:47でも、型の提供元が違ってたら、当然基底型も違うだろうし、
そうなるとポリモできない。
仕方ないから、ポリモするためだけのアダプタ型を作ったりする。(むなしいね)
だったらもう、動的オーバーロードでポリモしたほうが素直だろう。
そうは思わんかね。
現状、型の定義に多くを求めすぎだよ。
0141デフォルトの名無しさん
2010/04/21(水) 21:54:45元々色々な出自があったにせよ、少なくとも今は、
『柔軟性やメンテナンス性の高い、高凝集度・疎結合なシステムの実現を目的として、
責務と状態を最小化した「オブジェクト」の集合でシステムを構成するという考え方』
がオブジェクト指向、ということでいいんじゃないかな。
で、それを実現する「手段」については色々と提唱されていると。
で、個々の要素技術の是非はまだまだ議論は収束しないだろうけど、
少なくとも、「高凝集度・疎結合なシステム」に貢献するか否かという軸で評価されるべきだろう。
例えば、obj1.method(...)という記法にしても、「責務を持つ主体を明確化する」というのが
一つの目的なのは確か。これが万能かは別として、多くの問題領域の整理に役立つことは、
既に各方面で実証されている。
ま、どうしても電子レンジで卵をチンしたいなら勝手にすればいいけどさ。
0142デフォルトの名無しさん
2010/04/21(水) 22:00:25もっとも、最終目標は何千個ものゆで卵だろうから風呂釜より大きな鍋が必要になるかもしれない
とりあえず新しい理論の下では誰がその恩恵を受けることになるのだろう
0143デフォルトの名無しさん
2010/04/21(水) 22:03:12構造体内のデータの整合性を守るためのアクセサも完備。(アトミック機能となずけたい)
多くの人は満足すると思うがなぁ。
アトミック機能：
構造体をなるたけ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君の言うとおり、真価を発揮するのはまさに何千個ものゆで卵を相手にする時。
（ゆで卵数個でもある程度の恩恵は受けられるけどね。人間はそんなに優秀じゃない）
人間の理解能力の限界を余裕で超える構築物を相手に、
それをいかに人間が理解できるレベルに落とし込むか、という話をしている時に、
「俺のゆで卵は電子レンジで解決できない！」
なんてスコープも目的も違う話を喚かれてもなぁ、という。
0147デフォルトの名無しさん
2010/04/21(水) 22:20:10ダックタイピングしたいの？
0148デフォルトの名無しさん
2010/04/21(水) 22:34:57少なくともメソッド名が同じじゃなきゃタッグタイピングは出来ない。
同じ機能は同じメソッドでなきゃならないなんて制約は、まず通用しないだろうね。
そういうのをやりたくないんだよね。どうせ出来ないから。
だから、使う側が動的オーバーロード使ってアダプタ関数作ってインターフェースを整える。
あくまで使う側の都合でポリモしたいわけだから、使う側がインターフェースを整える。
型でインターフェースを整えない。
これは現実問題仕方の無いことだと思う。
実は、おれ自身は動的オーバーロードに消極的で、
どうしてもポリモしたい時のための逃げ道ぐらいに考えてる。
とにかく型の定義から仮想関数や共通に扱うためのインターフェースを排除したい。
これを型に含めるのはおかしい。というか、出来やしない。
これが出来るのは、演算子や文字列への変換など、決まりきってる基本的なことだけ。
出来もしないことは、やらない。やる、とも言わない、言ってほしくもない。
0149デフォルトの名無しさん
2010/04/21(水) 22:38:07> 型は自フィールドの整合性を取る、それが精一杯の責任範囲。
> だろ？
君の能力の限界はそうなのかもしれないが、仮にそうだとして、
何千個ものゆで卵に対して、火打石と薪でチャレンジするドンキホーテと一緒に仕事はしたくないな。
0150デフォルトの名無しさん
2010/04/21(水) 22:43:27多様なライブラリを使うから、ライブラリ間でインターフェースが整わない。
整ってない現状がすでにある。
インターフェースを整える責任はすでに放棄されているに等しい。
0151デフォルトの名無しさん
2010/04/21(水) 22:43:46んで、君はいったいソフトウェア開発における何の課題を解決しようとしているの？
■ このスレッドは過去ログ倉庫に格納されています