10/04/02 08:05:22
>>569
まー、そういうのもあるかもしれないがねぇ。
今や、別にそんなに肩肘張るような新味のあるものでもないとも思うけど。
>>574
非オブジェクト指向「言語」でも、オブジェクト指向「言語」と同等の表現はできるって奴だね。
まぁ、OOPL処理系を作る以外で本当にやる奴ぁいないと思うけどさ。
ただ、本当は、「言語」の話と、「指向」の話と、「分析」の話は分けたほうが良いのだろう。
でないと、特定の言語（「C言語」とか）に対する好き嫌いの話と混ざる。
言語は、彼流に言うところの、プログラマにうまい「ウソ」を見せるインタフェースにあたるところだから、
どうしても混同されやすいところがあるのは仕方ないけど。
578:デフォルトの名無しさん
10/04/02 08:21:39
ああそうだ。
>>548
> それじゃあれですかね、数学の数字の「1」もウソの産物なんですかね。
イエス。正確には、その「ウソ」は公理系と呼ぶがね。
（「なぜ0で割ってはいけないのか？」という動画が面白いので、一度見てみるといい）
ついでに言えば、文字の'1'も、ASCIIコードなら0x31に割り当てられたものでしかない。
電圧の高低にどういう意味を割り当てるか、というのは使う側の価値観に依存するんだよ。
こんなのは、中二病でもなんでもなくて基礎教養だ。
579:デフォルトの名無しさん
10/04/02 09:10:28
嘘でも本当でも、世の中プラグマティストが
多いんだよねー
580:デフォルトの名無しさん
10/04/02 09:31:56
>>560
各オブジェクトに対応した大量のif文を含むグローバルな関数ToString()を用意して、
foreach(Object o in objects){
names += ToString(o);
}
とかやることになるだろう。ToString()の実装が悩ましくなりそうだ。
581:デフォルトの名無しさん
10/04/02 09:37:38
>>565
> 構造体にタグ入れといてclass1_toString(),class2_toString()・・にswitchって感じ
メソッドの数だけswitchが発生し、
新たなtoStringを必要とする新たなクラス（？）が発生したら、
対応するswitchに追記をしなければいけなくなる。
一方、ポリモーフィズムを用いれば、
新クラスをいくら作成しても、
toString呼び出し部分の既存のコードに変更はない。
> 関数ポインタ使う仕組みとかでもいける
俺なら素直に、OOPLを使う。
>>552
> 柔軟性は損なわれるがな。
柔軟な方がボクは好きです。
カプセル化も、OOPLのもので不自由したことなどありません。
582:デフォルトの名無しさん
10/04/02 09:40:08
>>581
>メソッドの数だけswitchが発生し、
>新たなtoStringを必要とする新たなクラス（？）が発生したら、
>対応するswitchに追記をしなければいけなくなる。
これはデメリットなの？
追加されたら追加されたとわかる記述はどこかにほしいんだけど
583:デフォルトの名無しさん
10/04/02 09:42:27
構造体に同じ型もたせて呼び出すだけと違うんか？
584:デフォルトの名無しさん
10/04/02 09:48:09
少なくとも、俺なら変更箇所が散らばるのは嫌だよ。
toStringだけじゃなくても、よく使うメソッドは沢山あって、
rubyで言うと、to_i, to_f, to_a, inspect, hashといろいろあるとする。
>>580が言ってるように頑張ったとすると、各グローバル変数、
ToI, ToF, ToA, Inspect, Hashの内部のスイッチに、
新たな構造体について追記をしなきゃいけなくなるのでは？
> 追加されたら追加されたとわかる記述はどこかにほしいんだけど
あなたが何を欲しがるかにまで、ケチをつけるつもりはないよ。
585:デフォルトの名無しさん
10/04/02 09:49:41
>>586訂正：
×各グローバル変数
○各グローバルな関数
586:デフォルトの名無しさん
10/04/02 09:50:31
いかん、脳が弱っとるｗ >>585のリンク先は>>584…。
587:デフォルトの名無しさん
10/04/02 09:52:58
>>584
変更箇所が散らばるのが嫌？
俺はしかるべきところにしかるべき処理があったほうがいいと思うんだけど
WindowsのプログラムならOnXXXXのところにその処理があったほうがよくねーか？
したらたとえ処理対象が同一のものでもメッセージを処理する場所で当然バラバラになると思うんだけど
これを強引にまとめちゃうこともできるっちゃできるけど
知らない人がみたら混乱するだけでなんにもメリットないんじゃないの？
588:デフォルトの名無しさん
10/04/02 09:56:55
>>584
それとさっきっから勘違いしてるみたいだけど
この話題はオブジェクト指向言語にたまたまついている
オブジェクト指向とはあまり関係がない機能の一部の話であって
オブジェクト指向とはあまり関係がないんだけど
こんなところさぐってオブジェクト指向わかった気になるのって間違ってると思うんだけどどうよ？
589:デフォルトの名無しさん
10/04/02 09:58:58
>>582
どうとるかは人によると思うけど
まともに動いているメソッドに、直接触れなくてもいいのは安心できる。
switchくらいなら、まぁ…いいんだろうけど。複雑な処理の追記や、ロ
ジックの変更は、問題が波及する。
なので、クラスへ個別に記述した方が安心。
クラス増加 = メソッド増加と考えることもできる。
追加されたかどうかの確認なら、運用で対処とか、grepとか、IDEの機能
で補完できる気もする。
590:デフォルトの名無しさん
10/04/02 10:00:06
へ？この話題はれっきとしたポリモフィズムの話だよな？
591:デフォルトの名無しさん
10/04/02 10:03:50
>>589
>まともに動いているメソッドに、直接触れなくてもいいのは安心できる。
実際は挙動が変わってるんだからそれはただのまやかしだろう
>>590
じゃ、設計段階でそうなってるの？
違うでしょ？
それにこの手にことやろうと思ったら圧倒的にＣ言語のがやりやすいよ
超でかいメモリプール作ってそこに構造体全部いれるようにしてアドレステーブル作れば
現在使用中のメモリ量まで一括して出せる
592:デフォルトの名無しさん
10/04/02 10:05:09
>>587
> 変更箇所が散らばるのが嫌？
これはあれだよ、
新しいtoStringの実装を必要とする新しいクラス（？）ができたときに、
>>580方式でのグローバルなToString関数の中に、
newclass_toString関数を呼ぶ記述を追記する必要がある、という意味で、
newclass_toStringだけじゃなくToStringも触らなきゃいけない、
変更箇所が一箇所じゃないという意味。
一方、ポリモーフィズムを用いれば、
上の例だとnewclass_toString関数だけ変更すればい。
> WindowsのプログラムならOnXXXXのところにその処理があったほうがよくねーか？
その処理、とは？ newclass_toStringに相当する処理のこと？
593:デフォルトの名無しさん
10/04/02 10:16:10
>>588
> こんなところさぐってオブジェクト指向わかった気になるのって間違ってると思うんだけどどうよ？
朝からずいぶんな言い草だなｗ
オブジェクト指向分かった気になんかなってないし、
オブジェクト指向が何なのかにさえあまり興味は無い。
今はカプセル化とかポリモーフィズムとか、
そういう個別の恩恵についてコメントしてるだけ。
オブジェクト指向がどうの、という結論は求めてない。
594:デフォルトの名無しさん
10/04/02 10:35:27
>>591
まやかしか…確かに。
だが、前提として責任が明確に分かれているのは、利点ではないか？
595:デフォルトの名無しさん
10/04/02 10:39:36
>>594
は？見た目が変わってないのに挙動が変わってる状態のどの辺が明確なの？
596:デフォルトの名無しさん
10/04/02 10:45:52
見た目って、どこの見た目？
597:デフォルトの名無しさん
10/04/02 10:49:23
>>596
ポリモった部分
ちなみに言っておくけど俺の立場はＣ＋＋反対派な
598:デフォルトの名無しさん
10/04/02 10:50:58
Ｃ＋＋っつーかオブジェクト指向反対派だな
特にポリモなんて完全に後付けでしかもこれ入れた奴ってオブジェクト指向理解できてないだろ
そういうわけわからん経過も含めてこの機能は嫌いだな
599:デフォルトの名無しさん
10/04/02 10:54:30
Cの構造体でできることは、インスタンス変数とクラスメソッド（staticメソッド）の組み合わせでしょ？
インスタンス変数とインスタンスメソッドの組み合わせはどうやって作んの？
600:デフォルトの名無しさん
10/04/02 10:55:46
前に上がってる例でいけば
switch文に、増加した分岐処理が記述されている事。
また、増加した処理関数が別名で追記される事。
が、明確だ。という意味かな。
601:デフォルトの名無しさん
10/04/02 11:00:51
>>598
確かに
オブジェクト指向って、具体的なオブジェクトだけでなくて
人それぞれで考えが異なるような抽象化されたオブジェクトも含んでる
ポリモーフィズムはそう言った分かりにくさを助長してるかもしれん
それなのに、型名による動的な分岐は簡単に出来ない
でも俺はC++好きだけどね
602:デフォルトの名無しさん
10/04/02 11:04:03
ポリモーフィズムが嫌いなら、関数ポインタでループさせるのも嫌いなんだよな
603:デフォルトの名無しさん
10/04/02 11:11:13
>>591
簡易的なメモリ管理クラスを継承したクラスを使用すれば
固まったプール作らなくても実現できる
管理方法の切り替えも楽にできる
もちろんオブジェクト指向じゃなくても可能
ただ切り替えが分かりやすいってだけだがね
604:デフォルトの名無しさん
10/04/02 11:12:34
カプセル化やポリモーフィズムは好きだが、
C++は好きじゃない。C#も好きじゃない。それらに比べりゃCが好き。
ただCでOOPLの真似事をしようと思うくらいなら、素直にC++を使う。
605:デフォルトの名無しさん
10/04/02 11:13:43
>>601
「型名による動的な分岐は簡単に出来ない」かどうかは、継承元となっているクラスの
設計次第だろう。オブジェクト指向そのものの問題ではない。
object.GetType().Nameみたいなので型名が取得できれば、分岐は簡単だ。
606:デフォルトの名無しさん
10/04/02 11:15:09
C++のtemplateはどうよ
ポリシークラスこそオブジェクト指向
607:デフォルトの名無しさん
10/04/02 11:18:13
>>605
可能かどうかの話だったら可能だよ
言語仕様の話かもしれないが、リソースとして名前を持つんじゃなくて
型名で分岐させる方法があるべきだと思ってる
608:デフォルトの名無しさん
10/04/02 11:18:54
ポリモー（ｒｙこそがＯＯＰの肝じゃなかったのか
609:デフォルトの名無しさん
10/04/02 11:25:31
>>599
非OOPerどもは、そもそもクラスメソッドとインスタンスメソッドの区別がつかないし、
インスタンスメソッドを使う理由もわからない。
変数と関数ポインタのまとまりをオブジェクトと勘違いしてやがる。
610:デフォルトの名無しさん
10/04/02 11:25:41
>>606
俺（>>581,584,592,593,604）ね、それ大嫌い。
あんなもんで静的にポコポコ複製させて、
肝心のOOP機能については消極的でさ。virtualつけろとかなんとかｗ
Javaみたいに基本virtualで例外finalにしてほしかった。ケチくさいんよｗ
ハゲ（すとらうすとらっぷ）は自分の本のなかでテンプレートをひたすら自賛してたけど。
611:デフォルトの名無しさん
10/04/02 11:47:05
>>610
静的な「構造」のみを提供するのがtemplateだからね
複製は仕方ねえよｗ
部品と構造（設計）、具体的なオブジェクトを分けて考えるならtemplateは強力
言われてる通りまだまだ発展途上だけどね
これが使いこなせてこそオブジェクト指向が語れると思う
612:デフォルトの名無しさん
10/04/02 11:49:24
>>608
俺はそう思わない
あくまでも副産物的なもの
ポリシークラスによる部品と、構造を提供するtemplate
クラスのカプセル化こそが本質
613:デフォルトの名無しさん
10/04/02 11:55:54
そんな難しい話はわかりませんが、同じ引数の同名関数を大量に生産するのはやめてくださいｗ
614:デフォルトの名無しさん
10/04/02 11:56:28
>>609
ああ、俺にもクラスメソッドとインスタンスメソッドの区別 ― というか、その区別の存在意義 ― は
良くわからない。
「インスタンスメソッド」とはいっても、そいつはクラス設計で定義されているんだから、
「インスタンスメソッド」を、インスタンスごとにオーバーライドできなければ、それは、結局、クラスの
メソッドなのだ。
真にあるインスタンス固有のメソッドがある言語は、Io言語みたいなやつ。というか、この言語では、
クラスとインスタンスの区別がない。
615:デフォルトの名無しさん
10/04/02 11:58:26
>>613
コンパイル後だから別にいいじゃん
exeファイルのサイズが制限されてるんならわかるが
616:デフォルトの名無しさん
10/04/02 12:00:05
>>614
ポリモーがあるから分けてるだけじゃね？
便利だけど俺もあんまし好きじゃない
617:デフォルトの名無しさん
10/04/02 12:47:55
interfaceに対してプログラミングせよ、ってまだメジャーじゃないんだな。
多態性のメリットって結局そこだと思うんだが。
618:デフォルトの名無しさん
10/04/02 12:53:32
>>611
テンプレートなんてはじめＣ＋＋に入ってなかっただろ
完全に後付けかつオブジェクト指向と関係無い
お前、なんか違う方向行ってるぜｗ
ちなみに継承も後付け
後付け機能はホント使えないのばっかだな
619:デフォルトの名無しさん
10/04/02 13:15:10
てかクラスメソッドとインスタンスメソッドなんて全く別モンじゃねえかｗ
クラスメソッドなんて非ＯＯＰと変わらんｗ
620:デフォルトの名無しさん
10/04/02 13:37:22
>>618
後付けだから関係ないとかわけわからんこと言うなよ
よりオブジェクト指向の方向に進化してる
template使ったことないだろお前
621:デフォルトの名無しさん
10/04/02 15:04:39
>>620
バーカ、無くてもオブジェクト指向言語って主張してた時期があるのに
明らかにいらねーだろそんな機能
だいたい言語の機能一つとって設計と関係ない内容重視してんじゃねーよ低脳
だからお前みたいなのは役に立たないっていうんだよ
622:デフォルトの名無しさん
10/04/02 15:13:42
エージェント指向はどうなった？
というか、これからはCPUのマルチプロセッサ化が急速に進むだろう
から並列処理を簡単にできる言語、しかもオブジェクト指向と矛盾
しない言語が望まれるのでは？
623:デフォルトの名無しさん
10/04/02 15:14:42
>>621
わからないなら無理にレス返さなくていいよ
624:デフォルトの名無しさん
10/04/02 15:24:49
>>622
コンパイラの最適化では使われそうだけど、どうなんだろうな
ユーザに指定できたとしてもCPU命令を直接扱うのって面倒だしね
625:デフォルトの名無しさん
10/04/02 15:35:18
>>623
アレアレ？もしかして得意になってテンプレート勉強したんだけど
実はまったくオブジェクト指向と関係なかったってオチついちゃって意気消沈？ﾆﾔﾆﾔｗ
626:デフォルトの名無しさん
10/04/02 15:36:33
>>625
>>620
わからないなら無理にレスしなくていいって
627:デフォルトの名無しさん
10/04/02 15:51:54
>>626
アレアレ？
ageちゃうの？
もしかして図星？ﾆﾔﾆﾔｗ
全然関係ないことに時間費やしちゃった？ｗ
ざーんねんｗテンプレートをどんなに一生懸命勉強してもオブジェクト指向理解できないからｗ
628:デフォルトの名無しさん
10/04/02 15:54:34
templateってあくまでＣ＋＋の特徴的な機能であってＯＯＰとは無関係だろ
629:デフォルトの名無しさん
10/04/02 15:57:43
>>628
はぁ？特徴なんて表してねーだろ
寝ぼけんなよｗ
オブジェクト指向を全く理解してないアフォの入れたオナニーだ
630:デフォルトの名無しさん
10/04/02 16:00:13
だって別にtemplateってオブジェクト指向関係なしに使えるよねえ
631:デフォルトの名無しさん
10/04/02 16:03:40
>>628
メソッドのポリシークラス化によって型にとらわれない部品を作成できる
そのポリシークラスを利用する構造をまたtemplateによって記述できる
使う側はすでに用意された構造のみを利用して新しいオブジェクトを作成できる
だから、具体的に記述箇所がほとんどなくなる
新しいプロジェクトごとに細かいメソッドを用意することがない
プラモデル作るような感じで、部品を取り寄せるだけでよくなる
632:デフォルトの名無しさん
10/04/02 16:13:15
それって、フレームワークや組み込み関数と
同じレベルで使ってるってこと？
業務に特化した基礎クラス作ればいいとは思うが…
633:デフォルトの名無しさん
10/04/02 16:18:21
>>632
同じレベルというか、型レベルで最初からアダプタになってる
同じレベルで扱うこともできるし、自ら作成した特化したポリシーを使ってもいい
業務に特化したクラスを一度作ったとしても
次のプロジェクトでそのまま流用できるほど汎用的に作ってあっても
無理な仕様変更には対応できない
やっぱり新しいクラスを作らなければならない
これは、プログラミングするということ自体が動的動作を目的にしてるから
コンパイル時点で切り替えるということをtemplateは実現できる
634:デフォルトの名無しさん
10/04/02 16:21:26
＞コンパイル時点で切り替えるということをtemplateは実現できる
コンパイル時点で切り替えるということはできない
templateはそれを実現できる
です
635:デフォルトの名無しさん
10/04/02 16:45:36
何でもできるみたいな言い方になってるけど、事実なんでもできる
プログラミングが継承とコンポジションの構造、テンプレート指定子だけで終わる
636:デフォルトの名無しさん
10/04/02 17:53:36
質問、JavaやC#のジェネリクスとはどう違うの？
637:デフォルトの名無しさん
10/04/02 18:04:36
とは言え動的に切り替えたいことだってありますから
638:デフォルトの名無しさん
10/04/02 18:04:50
>>624
クロックが頭打ちとなった今、並列処理にマッチしたパラダイムが必要なのでしょうね。
そういうものとして今までに候補にあがったものはどのようなものでしょうか？
639:デフォルトの名無しさん
10/04/03 00:26:53
>>622
> 並列処理を簡単にできる言語、しかもオブジェクト指向と矛盾しない
すくなくとも、オブジェクト指向なんかいらん！
オブジェクト、オブジェクト言う奴に限って並列化のこととか、どこ吹く風だしな
640:デフォルトの名無しさん
10/04/03 00:40:49
>>639
っ【Scala】
641:デフォルトの名無しさん
10/04/03 00:45:07
>>638
すまん、あまり詳しくないんだ
GPGPUもまだわからない状況だし、マルチコアCPUの命令仕様も扱ったことない
ただ言えることは、
まだif分岐が起こるとそこで先読みが打ち止めになる
最適化で分岐を減らしたり、本当に単純な分岐を別のCPU命令に置き換えると爆速になるのは今も変わらない
CISK RISKレベルのシフトが起こるかもしれないけど、まだまだ先の話
642:デフォルトの名無しさん
10/04/03 01:56:54
並列化は制御に対して行われるものだから、
オブジェクト中心で考えるオブジェクト指向とは相性が悪いよ。
制御構造をないがしろにしてきた罰だな。
オブジェクトの振る舞いを記述することで、プログラムを表現しようという発想が、
本当に正しかったのかどうか今一度見直しましょう。
そもそも、プログラムって何でしたっけ？
「運動会のプログラム」のプログラムってどういう意味？
プログラムの本質は何？
プログラムの提供する機能は、何によってもたらされる？
何を中心に考えるべき？
何を「指向」すべき？
本当に大切なものが、ないがしろにされて無い？
わかりやすい「物」よりも、
見えにくい「何か」が大切だったりするものなんじゃないの？
643:デフォルトの名無しさん
10/04/03 02:08:08
並列化と言ったら関数型だな
644:デフォルトの名無しさん
10/04/03 02:15:15
関数、いい言葉だ。
関数は英語でfunctionと書くが、機能もfunctionと訳される。
これはとても重要な事。
645:デフォルトの名無しさん
10/04/03 02:38:23
>>642
知ったかぶりもここまで来ると感動的だな。
>>644
オブジェクト指向と違って、君の大好きな手続き型の対極に位置する概念なんだがな。。
646:デフォルトの名無しさん
10/04/03 12:13:11
人間の使いやすさと、機能性、性能とか
ぜんぶ手に入るものなの？
処理系やコンパイラが頭よけりゃいいのかな
647:デフォルトの名無しさん
10/04/03 14:05:59
>>646
> 人間の使いやすさと、機能性、性能とか
それを 「どこに向かって言ってるか?」 だな
648:デフォルトの名無しさん
10/04/05 01:59:37
写像としての関数なんて、数学と文字列処理で、
演算子と一緒の場合に使う時くらい。
他にはほとんど使えない。
何かに使えないかという工夫なのか、
エラー発生を通知するboolを返す関数が常態化しているが、
try出現で古典的手法になったじゃん。
関数なんてほとんど形骸化しているんだよ。
実際、戻り値なんてほとんどの場合いらないんだよね。
void関数が大活躍なのに、return必須とか鬱陶しいくらい。
OOPで、methodという名前に変更されたのもうなずける。
methodは、functionというよりBASICの命令文なんだよ。
object.method()というのは、
「objectさんは、methodして」という命令文。
649:デフォルトの名無しさん
10/04/05 08:42:07
>>648
on error goto
650:デフォルトの名無しさん
10/04/05 18:36:38
例外なんぞ劣化したgoto
651:デフォルトの名無しさん
10/04/05 19:27:13
危険性を取り除いたgotoと言い給え
652:デフォルトの名無しさん
10/04/05 20:04:29
いずれにせよ所詮 goto
653:デフォルトの名無しさん
10/04/05 20:36:58
GO★TO
654:デフォルトの名無しさん
10/04/05 22:44:12
関数という超エレガントな発想を否定してしまうとは。
OOP脳は怖いね。
> object.method()というのは、
> 「objectさんは、methodして」という命令文。
object1 さんと object2 さんに method してほしい場合はどうするんですかね。
method( object1, object2 )とは書けないですよね。
object1.method( object2 ) と書きますか？それとも、
object2.method( object1 ) と書きますか？
こんな簡単なことにすら頭を悩ます必要がある、それがOOP。
655:デフォルトの名無しさん
10/04/05 22:52:03
URLﾘﾝｸ(ja.wikipedia.org)サブルーチン
> 関数 (function) が返す値は戻り値（もどりち）または返り値（かえりち）と呼ばれる。function が関数と
> 訳されるのは、単に機能の実装を行うだけでなく、引数としてとりうる値の集合から、戻り値としてとりうる
> 値の集合への写像のように捉えることができるためである。したがって、ほとんどの命令型プログラミング
> 言語では次の点において数学の関数とは異なる。
>
> * 引数が同じでも状況に応じて戻り値が異なる（状態を持つ）
> * 関数の処理の実行によってシステムに変化が発生する（副作用を持つ）
> * 戻り値が存在しない場合がある
>
> ただし、純粋な関数型言語における関数は、状態や副作用などをもたず、数学の関数に近い性質を持つ。
656:デフォルトの名無しさん
10/04/05 22:53:38
> object.method()というのは、
> 「objectさんは、methodして」という命令文。
あー気持ち悪い。日本語的には
「objectをmethodしてください」、でいいだろ。
それが英語風だとmethod( object )になるってだけで。
なんだよ、objectさんって。
オブジェクトには処理手順がくっついてるってだけで、
実際に処理を実行するのはCPUなりスレッドなりだろ。
すくなくとも、オブジェクトが実行するわけじゃねーだろ。
657:デフォルトの名無しさん
10/04/05 22:59:53
>>654
object1とobject2が相互に入れ替え可能な処理ならその通りだけど、
それはmethod(object1, object2)でも同じことだよね。
入れ替え可能でないなら、どちらを先に書くか悩まなければいけないのは
どちらの記法でも同じだし、むしろ非対称なobject1.method(object2)の方が
意味が確定しやすいとすら言える。
658:デフォルトの名無しさん
10/04/05 23:07:33
>>656
「methodの処理を実行する。それはobjectの責務である」って考えてみたらどうか。
659:デフォルトの名無しさん
10/04/05 23:21:01
あーまた何か言い出した。
どちらを先に書くか悩む？なにいってんだ。
そんなもんは好きにすればよい。
関数作るやつが勝手にきめりゃいいんだよ。
単に処理の対象としてobj1とobj2を指定するってだけなんだからな。
OOPの場合、まずもって、いずれかのオブジェクトに処理をぶら下げるのが美徳なわけだが、
その処理が複数のオブジェクト間に作用するものである場合、
どのオブジェクトにぶら下げるのか迷うし、どこにぶら下げても「汚い」。
すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
これは、制御構造とデータ構造が本質的に別物だから。
なのに、処理をオブジェクトに紐付けるのは愚行だ。
データは単体では何もできない。複数のデータが相互作用しあって初めて機能が提供される。
その、データとデータをコミュニケートさせるのが「制御」。
制御はデータとデータの間を取り持ち、機能を提供する。
つまり、制御はデータとデータの「間」にあるもの。
それをデータにぶら下げるなんて、アホだね。
660:デフォルトの名無しさん
10/04/05 23:26:17
>>658
なんで処理の実行が、「処理の対象物」の責務になるんだよ。
rm file もしくは file . rm 。
これ、削除処理はファイルの責務か？
しかもなんでそこまで複雑に考えなきゃならん。
普通に、
命令 対象物1 対象物2 対象物3
の並びでいいだろ。超シンプル、超わかりやすい。
661:デフォルトの名無しさん
10/04/05 23:33:22
object.method() を後付けで超飛躍的解釈を施すこと自体が不思議なんですが。
普通に method のかくれた第一引数が object のポインタ、として今までこまったことがないのですが、それは単に私が c++ から入ってしまったせいかなあ？
662:デフォルトの名無しさん
10/04/05 23:36:24
> すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
そりゃそうだ。
> これは、制御構造とデータ構造が本質的に別物だから。
そもそも何を「本質的」と言ってるのか説明が欲しいところだけど、それはともかくとして、
もしかして「データ＝主体」とか思ってるのかな。
それぞれが責務を持ち、外部に役務（サービス）を提供するのがオブジェクトだとすれば、
外部に対してそう見えていれば良いのであって、別に「データ＝主体」である必要はない。
そうであってもいいけどさ。
とりあえず、オブジェクト指向をちゃんと理解してから批判しようや。
君のやってるのはただの藁人形叩き。
663:デフォルトの名無しさん
10/04/05 23:43:31
>>660
ファイルシステムはどこ行ったの？
あと、「分かりやすい」という言葉を安易に連発するのはやめないか。
せめて「命令型パラダイムと親和性が高い」とかにしとこうぜ。
純粋関数型や制約プログラミングだってあるわけだし。
664:デフォルトの名無しさん
10/04/05 23:46:35
>もしかして「データ＝主体」とか思ってるのかな。
なんじゃこれ、なにいってるのかわかんね。
プログラムの主体は機能で、
機能は制御によってもたらされるから、
プログラムの主体は制御だ。
データなんてものは、なが～い目で見れば一時変数に過ぎん。
665:デフォルトの名無しさん
10/04/05 23:47:04
専門用語使ってりゃあ自分は気持ちいいかもしれないけど他人に対する説得力は欠けるぞｗ
666:デフォルトの名無しさん
10/04/05 23:50:49
>ファイルシステムはどこ行ったの？
ファイルシステムは対象物として指定しているか、
グローバル変数として渡るかのどっちかだ。
どちらにしても、何らかの手法で 命令rm はファイルシステムを知り、
対象のファイルを削除する。当たり前のことだろ。
667:デフォルトの名無しさん
10/04/05 23:57:11
>>664
なら、個々に状態を持った機能＝オブジェクトでいいじゃない。
「責務と役務」というのは、それを外部にどう見せるかという話。
>>666
なら、「ファイルの削除を実行する。それはファイルシステムの責務である。」という
分析も成り立つよね。
ていうか、ファイルシステムなんて「役務（サービス）を提供する責務を持つ機能」そのものだし。
668:デフォルトの名無しさん
10/04/06 00:12:19
>>667
前半：
クラスがデータを持たない、ただのインターフェイスだってんなら、いいとおもうよ。
要はただの関数のテーブルを外部に公開しているだけっていう。
でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。
後半：
話し合ってる「層」がずれてる。
ファイルをどう削除するかの責任を持つのは rmコマンド だ。
rmコマンドはいくつかのオプション引数をとるかもしれないだろ？
それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか？
rmコマンドが責任を持つほか仕方ないだろ。
669:デフォルトの名無しさん
10/04/06 00:50:43
まーいろいろいいたいことはあるが、
まず、処理そのものが状態を持つべきではないんだ。
引数で指定すべし。そんなに手間か？
それから、ここからが本番なんだが、
責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。
そんなに色々な言葉使ってまで「それっぽく」して煙に巻きたいかよ。
一言「機能」でいいだろ。複雑な言い回ししたって現実は何にもかわんねーんだよ。
「それっぽく」聞こえる、ただそれだけ。
670:デフォルトの名無しさん
10/04/06 01:27:42
お前らこんなスレにいるぐらいだから、
ぶっちゃけ本当はOOPに嫌気がさしてるんだろ？
マジでマジで。
671:デフォルトの名無しさん
10/04/06 01:46:00
プログラム書くために、思考の形態を、そのまま記述できる手法は良いと思う。
自分の場合は、いかにフローに落とすか、ってイメージが強いなぁ。
木構造でしか考えられないな…。
672:デフォルトの名無しさん
10/04/06 08:02:48
>>668
> でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。
え？ なんで？ 世の中、自分の「状態」を持たないサービスの方がむしろ少数派だよ？
例えばだけど、ファイルシステムとかGoogleとか2chを、役務（サービス）を提供する
オブジェクトと考えてみたらどうよ。
> ファイルをどう削除するかの責任を持つのは rmコマンド だ。
> rmコマンドはいくつかのオプション引数をとるかもしれないだろ？
> それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか？
っ【Commandパターン】
「コマンド」だって、自分の役務（サービス）を提供するオブジェクトの一つと看做すことも
できるわけでね。それと同様に、Fileオブジェクト（≠ファイル）とかファイルシステムを、
固有の責務を持ったオブジェクトと看做す、という分析も同じくらいアリだというだけの話。
673:デフォルトの名無しさん
10/04/06 08:20:01
>>669
> まず、処理そのものが状態を持つべきではないんだ。
そうだよ。状態を持つのは「オブジェクト」だ。
とりあえず、そのオブジェクトがどう実装されているか、という部分はブラックボックスとして
考えてみるのが良いと思うよ。んで、Javaでいうinterfaceだけでコーディングする世界を考える。
（オブジェクトはマイクロコンピュータである、ってのはアラン・ケイの台詞だったか？）
> 引数で指定すべし。そんなに手間か？
小規模なコードなら、君の言うとおり、あまりご利益はないかもね。
状態が複雑に絡み合った大規模なコードでこそメリットがある考え方、というのは前提。
> 責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。
一般的な用語だと思うけどなぁ。
一つ言えるのは、「機能」をどういう形でどの責任範囲で外部に提供するか、
という側面を強調している点で一貫してるよね。
674:デフォルトの名無しさん
10/04/06 11:33:32
>>642
意味不明だ。オブジェクト指向は制御を阻害しないぞ。多数のスレッドを扱うならば、むしろ
クラスのインスタンスで非同期メソッドを呼び、個別結果をインスタンス変数に格納し、全体状況を
スタティック変数に放り込むほうが楽だろう。
>>643
並列化までは、オブジェクト指向だろうが関数型だろうが、あまり変わららないかもしれない。
超並列化時代に突入するまでは、関数型が主役になりそうにはない。
675:デフォルトの名無しさん
10/04/06 20:10:08
長文ご苦労としか。OOP脳では所詮この程度か。
知ってて当たり前のことしか書かれてない。あー言えばこう言うの世界。
それでも、OOPが優勢になることはないんだよ。
これはもう時代の流れで決まってること。
共産主義と同じですたれるのだ。
なぜそんなことがいえるか、この辺の感覚的な部分は、
なかなかわかってもらえないようだけど、
なるべく簡潔に説明すると、
プログラムの機能は、
「制御でデータの関係を定義する」
ことで成り立つから。
オブジェクトに制御をぶら下げた時点で、構造的におわっとる。
676:デフォルトの名無しさん
10/04/06 20:12:53
変な言語を使い、変な思考で構築しているうちに、
変な頭になっちゃうのさ。あーおそろしー。
右も左もわからないやつが使うのがOOP。
677:デフォルトの名無しさん
10/04/06 20:14:14
開発環境のベンダーなんかは、わざとやってるのかもしれないがな。
檻に閉じ込めておくために。洗脳おそろしや。
678:デフォルトの名無しさん
10/04/06 20:27:39
>>654
OOPをサポートする言語のほとんどにはstatic関数があります。
679:デフォルトの名無しさん
10/04/06 20:29:17
なぜ、static関数のような非OOP的機能が用意されたかを考えなさい。
680:デフォルトの名無しさん
10/04/06 20:29:51
大体struct使う奴にOOPうんたらとか言われると微妙に気分が悪い。
681:デフォルトの名無しさん
10/04/06 20:42:44
C++最強説浮上
682:デフォルトの名無しさん
10/04/06 20:54:02
>>675
> プログラムの機能は、「制御でデータの関係を定義する」ことで成り立つから。
だから、それは数ある分析手法の一つでしかないと何度（ｒｙ
大雑把に言えば、「ユーザがどんなサービスを受けたいか」とか、
「写像と制約によって何を定義したいか」とかでコード化する対象を分析し、
コードを記述する手法が数多くある。
命令型パラダイムはそのうちの一つに過ぎない、それだけのことだ。
んで、要求が複雑になり変化が早くなったことで、「どんなサービスを受けたいか」で
定義する手法の需要が上がっているのが現在。
はっきり言えば、君のそれは、手続きベースでプログラムを書く人間の都合を押し付けてるだけなんだよ、
そんなもんは「本質」でもなんでもない。
683:デフォルトの名無しさん
10/04/06 22:16:27
車1.ワイパー()
は納得いくが、
車1.洗車()
は確かに気持ち悪い。
洗車機能は、洗車機にあるのであって、車にあるわけではない。
そいういうときはstaticで
洗車機::洗車(車1)
とすれば無問題なのかもしれない。
だが、多数の自動車インスタンスを一括して洗車()したい場合、どうするか？
という問題がある。
もちろん、いろいろなタイプの自動車が入り混じっているし、
続々と新車が発表されている。
で、解決に、
foreach (車配列){ ((洗車可能)車).洗車(); }
のような一括処理のために、やっぱり、車クラスに洗車メソッドを付けてしまう。
一見エレガントでも、こういうのは気持ち悪いと言われればそうかもしれない。
でもこれはOOPの問題というより、クラス設計の問題だが・・・
684:デフォルトの名無しさん
10/04/06 22:19:16
ああ言えばこう言う。
>「どんなサービスを受けたいか」
言い回しがすでにきめぇ。何で変に受身なんだよ。
普通に、
「必要な機能は何か」
でいいだろ。そういうところが頭おかしいっていってんだよ、受身野郎がよ。
685:デフォルトの名無しさん
10/04/06 22:28:14
車に基づいて洗車の処理が決定するようだけど、
他の要因でも洗車の処理が変わりうる場合はどうするんだ？
686:デフォルトの名無しさん
10/04/06 22:28:53
俺はずっと手続き型で来た人間だけど。
>>684
UPの開始工程が要求分析だからじゃないの？
客先がプログラム知らんから頭悪そうな言い方になる。
687:デフォルトの名無しさん
10/04/06 22:33:34
普段から自分たちを奴隷に見立ててるから、
「オブジェクト様が～なさる」、みたいな発想になるんだよ。
プログラムは指示書なんだから、
「これとこれとこれ、あれしといて」
でいいんだよ。