10/03/28 22:44:00
オブジェクト指向ってさ、なんで無理にメソッドの集合で全ての物事を抽象化しようとするのかね？
例えば無いかもしれないデータを表現するのにメソッドの集合で定義すると、
template <class T>
class Option {
public:
T get();
bool isNone();
};
という風に抽象化されると思うけど、これだと実体がNoneなのにgetが呼ばれてエラーになる可能性がある
代数的データ型みたいにメソッドの集合と場合分けの構造と両方持てばいいのに
370:デフォルトの名無しさん
10/03/28 22:46:24
>>363
手戻りが減らせればコストを減らせて金になると思うけど。
371:デフォルトの名無しさん
10/03/28 22:48:58
>>365
ワークフローが中心になるタイプの業務システムとかだとそういう側面はあるかもしれないな。
そこは、オブジェクト指向というよりフレームワークのレベルでどうにかする問題だという気もするけど。
372:デフォルトの名無しさん
10/03/28 22:50:25
>>368
デザインによって副作用は減らせると思うけど、完全に取り除くことはできないわけだし。
それに、そういううまいデザインとオブジェクト指向の採用は矛盾しないんじゃない？
373:デフォルトの名無しさん
10/03/28 22:50:30
>>363 ではないんだけど
現実には >>362 の様な理由によって
>「より使いやすく」「より分かりやすく」「より安全に」プログラム
できていないことが問題だろ
374:デフォルトの名無しさん
10/03/28 22:53:45
>>369
参照に代入されたnullを「ない」の意味で使うか、Null Objectを定義すればよし。
375:デフォルトの名無しさん
10/03/28 22:53:59
ちんこの遊び場はここですか
376:デフォルトの名無しさん
10/03/28 22:56:39
>>373
もちろんオブジェクト指向は万能な「銀の弾丸」じゃない。
そこを補うのが、例えば>>367みたいな実践。
377:デフォルトの名無しさん
10/03/28 22:57:15
>371
オブジェクト指向の利点を活かすには、それを含めてってことだけどな。
草創期からOODに取り組んでいたウェブスターが言ったのは、人材だの会社の
政治的な側面も考えて「環境を整えてからやれ」ってこと。
378:デフォルトの名無しさん
10/03/28 23:04:29
>>374
nullを使ったらnullチェックが必要になるのでisNoneを呼び忘れる危険と変わらないのでは？
Null Objectってどうやって使うの？まさかtypeid？それこそ場合分けの構造じゃんか
こういう小手先の芸じゃなくて、言語使用として場合分けの構造をサポートした方がいいという判断で、
Scalaとかはcase classを導入したんだと思うんだけどなー
379:デフォルトの名無しさん
10/03/28 23:05:03
オブジェクト指向じゃない言語は本当に迷宮入りする事があると思う
ある意味怖い
380:デフォルトの名無しさん
10/03/28 23:08:19
>>378
URLﾘﾝｸ(www.hyuki.com)
381:デフォルトの名無しさん
10/03/28 23:14:16
>>379
200人規模のプロジェクトだとオブジェクト指向でも平気で迷宮入りするのは気のせい?
382:デフォルトの名無しさん
10/03/28 23:15:10
>>380
ありがとう
読んでみたけど、Null Objectでどうやってgetを実装するの？
戻り値がないので無理でしょ
やっぱりメソッドの集合で物事を抽象化するには限界があるのだと思うよ
限界があるというか、もっといい方法がある場合があるので、そちらも使うべき
383:デフォルトの名無しさん
10/03/28 23:15:40
200人いれば200のオブジェクト指向があるってのが事実。
大統一理論があると思ってはいけないｗ
384:デフォルトの名無しさん
10/03/28 23:17:18
>>382
べつにnullを使っちゃいけないということはないと思うけどなぁ。
いい方法があれば併用すべきというのは同意。
385:デフォルトの名無しさん
10/03/28 23:22:27
>>382
ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
基本的にパターンマッチは記述を簡潔にするのが目的だと思うけど。
OOがやる抽象化は拡張できるようにするためでしょ。
386:デフォルトの名無しさん
10/03/28 23:26:08
>>381
そんなレベルじゃない
自分で自分が作った物が分からなくなる
オブジェクト指向だとプログラム自体がある程度設計書だがそれがない
387:デフォルトの名無しさん
10/03/28 23:28:02
>>384
同位THX
ついでだからさらに続けると、
一旦場合分けの構造の有用性を受け入れると、意外とその適用範囲が広いことが分かると思うのよ
Scalaではかなり使われているし、関数型言語ではいわずもがな
とすると、これはもう、
"メソッドの集合で全てを表現しようとしたオブジェクト指向はやりすぎでした、間違いでした"
という結論にならざるを得ないのだけど、どうよ？
388:デフォルトの名無しさん
10/03/28 23:34:30
メソッドどころか「データの抽象化がオブジェクト指向ではない」ってのは、
高名なクック船長がおっしゃってますｗ
389:デフォルトの名無しさん
10/03/28 23:35:58
>>385
>ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
あれ？
オブジェクト指向ってsiwtch caseを使わずにオブジェクトのメソッドで抽象化するというのが原則じゃなかったっけ？
switch caseを使うって事は、場合分けの構造がやっぱり必要って事になるよ
390:デフォルトの名無しさん
10/03/28 23:36:21
>>386
それはどうしてそういえるの？
391:385
10/03/28 23:44:14
>>389
極端に言えば、パターンマッチはswitch caseがあれば、場合わけの構造とやらがあるので、いらんでしょ?
OOでわざわざ抽象化してデザインすると、それを外部から拡張できるようになる。
それとも場合わけの構造ってなにか具体的な定義があるの?
392:デフォルトの名無しさん
10/03/28 23:46:23
>>391
ぶっちゃけそんな細かいとこどーでもいいよ
実装方法なんてどーだっていいし
オブジェクト指向となんも関係ないのに
それがオブジェクト指向だと思ってる可愛そうな脳みそしてる奴多いな
オブジェクト指向はあくまでも仕様をオブジェクトに落とすだけだ
そんな細部の話が出てくる時点でもうおかしいだろ
393:デフォルトの名無しさん
10/03/28 23:55:48
>>392
個人的な意見だけど、オブジェクト指向って言葉は、
「オブジェクトという概念を中心に据えたテクニックや分析手法の集合」なんじゃないのかな。
その具体的なテクニックの代表例が、例えばデザインパターン。
だから、人によって見解に相違が出てくるのは当然だし、
「○○という定義に沿ってなければオブジェクト指向じゃない」みたいな話はあんまり意味がないんじゃないかな。
394:デフォルトの名無しさん
10/03/28 23:55:58
>>391
>極端に言えば、パターンマッチはswitch caseがあれば、場合わけの構造とやらがあるので、いらんでしょ?
確かにswitch caseがあれば、パターンマッチはそれの強力版みたいなものなので、原理的にはいらない
それは同位
うん？でも議論がかみ合ってないな
別にパターンマッチが必要と言っているのでは無く、
switch caseという便利なものを否定しようとするオブジェクト指向はいまいちじゃない？と言っている
395:374
10/03/29 00:01:47
>>394
そりゃ、goto禁止すると例外処理がきれいにかけないから構造化プログラミングはいまいち、
って言ってるようなもんだよ。
あくまで「原則」は「原則」なわけで、どういう書き方が最適かは状況による。
将来拡張する可能性が高いなら、switch caseはハードコーディングされてあまり良くない。
そうでなければ以下略。
396:デフォルトの名無しさん
10/03/29 00:06:14
>>393
違うよ
はじめはシミュレーション用の言語だったんだから
オブジェクト＝物体と仕様をわかりやすく落とし込むために作られた
たしか気体分子同士の関係をみるためだったかな？
仕様をそのままコードに落とせるのが目的なんだから
デザパタなんて入る隙間なんてない
よってデザパタがオブジェクト指向だという奴はオブジェクト指向を理解してない
大事なのは仕様
397:385
10/03/29 00:06:39
>>394
否定してないと思うけど?
だって大抵のOOには場合わけが書ける言語構造があるし、分岐のコードみたんな書くよね。
否定されるのは拡張が必要になるのに、それをやりにくくするコードを書く場合。
場合わけのコードをばらまくことを推奨する言語が、メンテナンスとか拡張とか頭にないってことなんじゃないの?
便利だといって後のことなんも考えてませんみたいな。
398:デフォルトの名無しさん
10/03/29 00:07:06
>>388
クック船長がどう言っていようが、
Stroustrup（発音しらん）艦長がなにを言っていようが、
ケイ番長がなにを言っていようが、
このさい関係ない
そんな定義論に興味ない
Abstract Data Typeは使いにくい場面が多いし、偏りすぎ
ただそれだけ
399:デフォルトの名無しさん
10/03/29 00:11:11
>>395
>そりゃ、goto禁止すると例外処理がきれいにかけないから構造化プログラミングはいまいち、
>って言ってるようなもんだよ。
なるほど
合点がいった
ありがとう
400:デフォルトの名無しさん
10/03/29 00:13:19
>>390
どこに何に対する処理か分からないルーチンがばら撒かれるから
オブジェクト指向だとオブジェクト自体に処理が書かれるからどこにあるか分かる
401:デフォルトの名無しさん
10/03/29 00:15:42
>>397
>場合わけのコードをばらまくことを推奨する言語が、メンテナンスとか拡張とか頭にないってことなんじゃないの?
>便利だといって後のことなんも考えてませんみたいな。
でもここは同意できないな
場合分けのコードってメンテナンス性も拡張性も落とさない
ただし静的型付けがあれば、かな
402:385
10/03/29 00:25:46
>>401
型でチェックできればいいってもんではない。
コードに手を入れるのは大変だし、取り除くのも大変。
パターンマッチにも拡張性が低いから拡張できるようにって取り組みがあった気がするが。
403:デフォルトの名無しさん
10/03/29 00:27:50
>>398
その通りだけどｗ
表記色々あるが、ストラブストラップ艦長が成功したのは抽象化そのものに
こだわるより、Cとの親和性を重視した結果。
そもそもJavaにおける「プリミティブな型」を考えりゃわかるけど、同じメソッドを
持ってるオブジェクトであるはずでもコピーではまったく同一に扱えないわけで…
メッセージ志向がオブジェクト指向なのかどうかも誰も確定できない状態で、
OODが正しいなんて言うのが間違い。OOD的考え方の導入に利があるかどうかの
話でしかないんだけどな。
404:デフォルトの名無しさん
10/03/29 00:31:49
同じコードを１０箇所とかにコピペするのを止めて欲しい
仕様変更でコードを変更するだけで死んでしまう
405:デフォルトの名無しさん
10/03/29 00:32:55
>>402
つOCamlの多相バリアント
元のコードには手を入れずに拡張できる
406:デフォルトの名無しさん
10/03/29 00:37:29
>>396
いわゆるGoF本の正式なタイトルは、
「オブジェクト指向における再利用のためのデザインパターン(Design Patterns Elements of Reusable Object-Oriented Software)」
なんだけどな。。
407:デフォルトの名無しさん
10/03/29 00:39:59
>>406
だからといって本人達が理解しているかどうかは全く別
少なくとも俺には製作者のオナニーにしか見えない
408:デフォルトの名無しさん
10/03/29 00:41:43
>>407
本人ってのは誰？ GoFのおっちゃん？
409:デフォルトの名無しさん
10/03/29 00:42:52
それとデザパタははじめの設計思想のシミュのための～って部分の原型すらないじゃない
仕様をそのままコードに落としこめるメリットをまるごと削り取って
パターンどおりに作ると安全性、汎用性の名のもとに余計な仕様は入れるは、
オナニークラスはいれるは仕様からコードを説明はできないわであまりにも酷い
やってることが給料泥棒と変わらないよ
だいたい、だれが汎用性なんていれてくれって頼んだよ？
410:デフォルトの名無しさん
10/03/29 00:44:04
>>402
「開放-閉鎖原則(The Open-Closed Principle)」の考えに基づくなら、
「変更に対して閉じており、拡張に対して開いている」方が良い、という結論にはなるね。
411:デフォルトの名無しさん
10/03/29 00:45:18
>>405
拡張できるといってもレコードの拡張とはサブタイピング関係が逆になるので要注意な
412:デフォルトの名無しさん
10/03/29 00:46:33
>>409
> だいたい、だれが汎用性なんていれてくれって頼んだよ？
君以外のコーダーと一週間後の自分。
メンテナンス性の向上に役立たない汎用性が不必要であることは言うまでもないが。
413:デフォルトの名無しさん
10/03/29 00:47:36
ぶっちゃけデザパタは「馬鹿は何も考えるな！この通りに作れ！」っていうリアリズムだろｗ
414:デフォルトの名無しさん
10/03/29 00:52:24
さっきから
>オブジェクト指向は仕様をそのままコードに落とせる
と叫んでいるイタい上司がいるのですが、なんとかなりませんか？
415:デフォルトの名無しさん
10/03/29 00:56:22
>>414
何ともなりません。自分でやってみて実証してくださいとお願いするしかないですｗ
416:デフォルトの名無しさん
10/03/29 00:56:39
Ａ．アセンブラかマシン語
Ｂ．超高級言語（ネイティブな母語のようなもの）のインタープリタ
概念というより、言語の問題だろうな…
417:デフォルトの名無しさん
10/03/29 01:13:27
ずっと粘着してる奴コテつけろ
だれだかわからない
418:デフォルトの名無しさん
10/03/29 01:23:39
>>414
成り立ちから考えてデザパタはどうやってもやってることが違う
419:デフォルトの名無しさん
10/03/29 01:27:01
まあ、ちゃんとプログラムやってたら
ほとんどのデザパタはいつのまにかやってるもんだと思う
420:デフォルトの名無しさん
10/03/29 01:30:23
>>419
俺とお前の作り方は違うんだな
俺はあくまでも仕様書に書いた構造をコードに落とす
そこにデザパタが介在する隙間はない
パターンなんてねぇから
421:デフォルトの名無しさん
10/03/29 01:41:35
>>420
仕様書があるならそれでいいと思う
リファレンスとして仕様書があるから早いしわかりやすい
デザパタはある意味共通化された設計だから分かりやすいってとこもあるが
無理にデザパタにあてはめるのは意味ない
ちゃんと設計してたらデザパタとだいたい同じ設計が出来上がるもんだと思ってるかしな
422:デフォルトの名無しさん
10/03/29 01:43:10
だって元々デザパタは経験則で生まれたもんだろ。
マトモなPGが組めば同じようなパターンになるのは当然。
それを「知識」として受け取るような奴がいるから困ることになる。
たとえば誰が使っても単一の生成しかしないようなオブジェクトにおいて、
[factory methodだから～]とか言ってnewしてからCreateってなのを、あたかも
理想的な実装であるかのように強要する奴はいらない。それだけだろｗ
423:デフォルトの名無しさん
10/03/29 01:48:46
>>422
そうだな
デザパタに限ったことではないがこれが唯一解みたいなのはいて欲しくない
わかってデザパタ使ってほしい
424:デフォルトの名無しさん
10/03/29 01:53:33
オブジェクト指向の意味は
privateによるカプセル化と、
ポリシークラスによる構造定義が真の意味だと思ってる
工期がどうってのはあくまで副次的な産物
425:デフォルトの名無しさん
10/03/29 09:19:47
オブジェクト指向で用意されたライブラリがクソ使いやすいんだが。
String, Array, Hashとか基本的な奴ほど特に。
Cでやろうとするとすごく煩雑にならないか？
426:デフォルトの名無しさん
10/03/29 09:24:22
だよねー
その３つがあればなんでもつくれるよねー
427:デフォルトの名無しさん
10/03/29 21:23:31
>>425
Cでの実装も、継承、多態を考えなければ、そう難しくはないと思うよ。
たとえば文字列の場合、
公開用の型として
typedef struct {int class_id;} t_string;
実装用の型として、
typedef struct {int class_id; char* str; } t_string_impl;
を用意しておき、
インスタンス生成の関数が呼ばれたら、t_string_implを生成し、キャストして、ライブラリの外へはt_stringを返す（正確にはポインタを返す）。
その他、文字列操作に関する関数は、返されたt_stringを渡して、ライブラリの中で、キャストしてt_string_implを取り出し、操作する。
使う側としては、インスタンスのポインタと関数のセットで扱うので、そう違いはないかと。
継承、多態を実現しようとすると>>425のいうとおり、煩雑になると思う。
ってゆうか、C++つかいやがれってことです。
428:デフォルトの名無しさん
10/03/29 22:39:04
>>425
>オブジェクト指向で用意されたライブラリがクソ使いやすいんだが。
>String, Array, Hashとか基本的な奴ほど特に。
それは別にオブジェクト指向である必要はないよね
MLならモジュール、Haskellなら型クラスというやり方もある
オブジェクト指向しか知らない人は世界が狭いよ
429:デフォルトの名無しさん
10/03/29 22:46:13
プログラミングにおける「良い習慣」を全部オブジェクト指向の手柄にしちゃうのが初心者
430:デフォルトの名無しさん
10/03/30 21:26:39
昔は、cは関数が豊富でよい、と言われていたものだが。
431:デフォルトの名無しさん
10/03/30 22:04:56
オブジェクト指向設計と絡めてＣ＋＋の利点を説明できない人ってなんなの？
サブルーチンに対してばっかり話してるけどそんなのＣ言語の標準関数と変わらないじゃん
全然オブジェクト指向出てこないんだけど？ｗ
432:デフォルトの名無しさん
10/03/30 22:20:05
>>431
何が変わらないの？
433:デフォルトの名無しさん
10/03/30 22:23:06
newしたらオブジェクト指向
434:デフォルトの名無しさん
10/03/30 22:25:02
>>432
設計じゃないという意味
設計の話でstrcpyとか出てこないでしょ？
だけどこの板に巣くってる馬鹿な人は
いつもオブジェクト指向の話するのに文字列クラスなんて馬鹿なもん出して説明しようとしてる
いい加減、オブジェクト指向理解できてないって気づけよｗ
435:デフォルトの名無しさん
10/03/30 22:42:27
ここは別にOODと言ってないんだから設計の話じゃなくてもいいだろ。OOPでもｗ
436:デフォルトの名無しさん
10/03/30 22:52:18
だったら別スレ建てろよ
邪魔だな邪魔
オブジェクト指向理解してねぇしｗ
437:デフォルトの名無しさん
10/03/30 22:54:43
別スレはお前だろ。元々オブジェクト指向ってのは実装が先だぞ。
設計なんてのはその考え方を推し進める上で、後から出てきた話だ。
438:デフォルトの名無しさん
10/03/30 23:26:18
>>437
はぁ？
馬鹿は糞して寝ろよｗ
439:デフォルトの名無しさん
10/03/30 23:52:52
ちんこさんチンコンパイラはまだですか？
440:デフォルトの名無しさん
10/03/31 00:19:45
>>431
オブジェクト指向言語としてのC++はあまり評価が高くないように思うが。
441:デフォルトの名無しさん
10/03/31 00:48:00
オブジェクト指向言語としてのC++、なんて話じゃないな。１人が勘違いしてるだけ
442:デフォルトの名無しさん
10/03/31 04:38:57
情報隠蔽に、コーディングレベルでの意味を見出せない。
言語レベルでのコントロール規制…うーむ。
443:デフォルトの名無しさん
10/03/31 04:51:32
データを勝手に変更させないってことじゃないのか
例えばマイナス入れちゃ駄目な変数に勝手にマイナス入れられないようにするとか
444:デフォルトの名無しさん
10/03/31 05:07:58
＞一行目
private指定で、getterだけで使用…？ 他の思いつかない俺はダメだな。
ハードコーディングしたデータを使うだけなら、別段規制する必要性を感じない。
人間は間違うもんだ…という前提にたっての規制なら…意味あるか
＞二行目
setterで入力データのチェックを行う。というのが思いついた。
関数言語でも入力内容のチェックを通すのは容易い。
わざわざそれを隠蔽と称して、setterで行う意味合いはなんだろう。
考えなければ…
そもそも、前面に出やすい「再利用性」も疑問が残る。
関数とオブジェクト指向の再利用性の違い、とはなんだろう？
恐らく、考える階層が違うのだろうが…。
445:デフォルトの名無しさん
10/03/31 07:57:02
>>442
静的型検証と同じこと。
特に、自分以外の人間と一緒にコーディングする時のことを考えてみるとよろし。
「昨日の自分と今日の自分は別人」とか言ったりもするし。
cf. 契約ベースプログラミング
446:デフォルトの名無しさん
10/03/31 08:01:48
>>444
継承できるかできないかの差かと思う
これができないとコピペが乱立する
447:デフォルトの名無しさん
10/03/31 08:06:59
>>444
言うまでも無いが、なんでもかんでもgetter/setterを実装するならあんまり意味がない。
そのオブジェクトが他のオブジェクトに対して、本当に提供すべき「サービス」は何か、ということを考える。
オブジェクトは、責任分散協調系の中の主体の一つ。
再利用性については、何を意識しているかによるけど、
一時期盛んに言われていた「継承は再利用のためにある」みたいな説明は、
最近は批判されていることが多いね。
個人的には、メンテナンス性が向上すれば自ずと再利用性も向上する、程度に考えているが。
あと、「人間は間違うもの」という認識は、君が考えている以上に超重要。
448:デフォルトの名無しさん
10/03/31 08:18:54
参考になりそうなキーワード：
単一責任原則
"Tell, Don't Ask."
449:デフォルトの名無しさん
10/03/31 09:04:11
あまり専門用語使ってると説得力ない希ガス
よく分かんねで終わってしまいそう
450:デフォルトの名無しさん
10/03/31 09:05:42
言ってる方は気持ちいいだろうけど
451:デフォルトの名無しさん
10/03/31 10:19:39
>>446
> これができないとコピペが乱立する
出来なくても, unix の kernel にはコピペないよ
452:デフォルトの名無しさん
10/03/31 10:28:50
>>451は何を根拠にそう発言したのだろうかｗ
453:デフォルトの名無しさん
10/03/31 10:59:32
>>451
少なくとも, v6 のソースには見受けられなかったし, 4.2BSD もそうだった
*BSD や Open Solaris でもみかけないな.
Linux のドライバにはあるかも知れない.
454:デフォルトの名無しさん
10/03/31 11:15:37
オブジェクト恥垢
455:デフォルトの名無しさん
10/03/31 12:23:31
OOPのポイントは2つ。
１．クラスのインスタンス化
２．メッセージング
「なぜクラスをインスタンス化する必要があるのか」、
「メソッド呼び出しとメッセージ送信の違いは何か」、
を明解に答えることができれば、
OOPを理解している、とみていいんじゃないの。
456:デフォルトの名無しさん
10/03/31 13:08:56
そのふたつはObjective-Cをマスターすることによって理解できるな
457:デフォルトの名無しさん
10/03/31 13:30:35
「変数と、それを操作するメソッドを1つにまとめる」（クラス）
「ユニークな変数にはユニークなメソッドを用いる」（クラスのインスタンス化）
Javaで、Stringクラスを100個インスタンス化したとする。文字列の長さを得るには、
オブジェクトa.length();
オブジェクトb.length();
オブジェクトc.length();
…
とするわけだが、ここで、オブジェクトaのlength()が対応しているのは、
オブジェクトa内部に隠蔽された変数であって、オブジェクトbやcの変数ではない。
このように変数とメソッドが1対1で対応していることの利点は、
片方を知っていればもう片方を知る必要がなくなるということ。
要するに、メソッドを知っていればそれに対応する変数を知る必要がなくなる（隠蔽可能になる）ということ。
変数とメソッドを分離した場合は、変数の隠蔽ができなくなるので、
変数とメソッドの両方を知る必要がでてくる。
変数を隠蔽するという観点からすれば、変数の入力はsetter、出力はgetterで行うのが望ましい、
ということになるね。
458:デフォルトの名無しさん
10/03/31 14:07:54
メッセージングについては、
URLﾘﾝｸ(www.geocities.jp)
を読めば分かるんじゃね。
OOPってのは、要するに、
可能な限りオブジェクトを他から切り離して単独で動かそうとするプログラミングのことでしょ。
その仕組みがインスタンス化だったりメッセージングだったりするわけで。
非OOPでもOOPのようなことはできるじゃん、ってな意見だかネタだかをよく聞くけど、
そんなこと当たり前のことだよねぇ。できるかできないかの話じゃなくて、簡単か難しいかの話。
非OOPでも、「ローカル変数なんていらん！全部グローバル変数でいいだろ！」
ってなことを言われても、まあ、間違いではないんだけど、普通はやらないからねぇ。
459:デフォルトの名無しさん
10/03/31 19:24:23
> このように変数とメソッドが1対1で対応していることの利点は、
> 片方を知っていればもう片方を知る必要がなくなるということ。
？？？
片方を知っていれば、もう片方を知る必要が無い？何言ってんの？
おまえ、自分の書いたOOPのサンプルコードで、
> オブジェクトa.length();
このように、"オブジェクトa" と length() の両方を指定しているよな。
"オブジェクトa" だけでも、"length()" だけでも、思ったようには動いてくれないよな？
両方知ってる必要があるんだよな？片方だけを知ってれば良いってのはどんな寝言？
まったく、OOP信者はマジキチだな。
460:デフォルトの名無しさん
10/03/31 19:39:49
>>457が言ってる「変数」って、オブジェクトaの内部状態のことでしょ。
461:デフォルトの名無しさん
10/03/31 19:50:24
Cの関数でも、
構造体aを指定しているのに、
なぜか構造体bのメンバが変更される、
とかありえないから。
struct hoge a, b;
func( &a ); //なぜかbのメンバが変更される。
その発想が怖い。
462:デフォルトの名無しさん
10/03/31 20:01:12
>>461
func(hoge)が、内部でbを変更するコードになっていればありうる。
463:デフォルトの名無しさん
10/03/31 20:11:08
そしてそれはOOPの欠点だ。
Cなら有りえない。
464:デフォルトの名無しさん
10/03/31 20:15:27
単に関数付き構造体ってことじゃないのか
構造体みたく好き勝手に値変えられない構造体みたいな
465:デフォルトの名無しさん
10/03/31 20:28:16
>>464
言語仕様レベルではね。特に後段が重要なのではあるが。
466:デフォルトの名無しさん
10/03/31 21:46:10
>>459
Javaで、Stringクラスを～、って言ってんだから、
メソッドa.length()に対応する変数は、
オブジェクト内部に隠蔽された変数（文字列の長さを表す数値）のことでしょ。
ていうか、Javaすら知らないんだったら黙っとけよ。
467:デフォルトの名無しさん
10/03/31 21:53:08
しかし、>>459の発言は痛過ぎるね。
まさに、Javaを知りません、OOPLを知りません、ってな文章だなｗ
468:デフォルトの名無しさん
10/03/31 22:11:06
まあ重要なのはそういう隠蔽化ではないけどな。
誰かがStringを継承して、ある特殊なエンコードに対応したクラスを作ってくれたとしても、
その中身をあまり知らずに安易にStringと同様の使い方をすることはできないしね。
469:デフォルトの名無しさん
10/03/31 22:14:30
涙ふけって、OOP信者よ。
変数とメソッドが一対一で対応って意味不明だろ。
クラスとメソッドが一対一で対応しているわけで。
470:デフォルトの名無しさん
10/03/31 22:18:00
常に対応してるんだったらメソッドなんかいらんわな
単純な関係が崩れたときのためにアクセサを通すわけで
471:デフォルトの名無しさん
10/03/31 22:24:04
あーまた変な事言い出した。
メソッドがクラスと対応しているのは当たり前だろ。
472:デフォルトの名無しさん
10/03/31 22:27:58
オブジェクト指向なんてもはや基礎教養だろ。
踏まえた上でどう実践していくかというフェーズで、
信じるとか信じないとかいう段階はとうに通り過ぎてる。
まぁ、理解したつもり、のレベルのやつがとても多いのは事実だけどなー。
473:デフォルトの名無しさん
10/03/31 22:30:26
>>471
まず、クラスとは何か、メソッドとは何か、という言葉の定義の確認から始めた方が
いい気がするな。
474:デフォルトの名無しさん
10/03/31 22:36:23
SmalltalkやCLOSも学んだ方がいい
といってもちんこは人の話を聞かないのであった
475:デフォルトの名無しさん
10/03/31 22:36:46
隔離されたグローバル変数(というか環境)みたいなもん
476:デフォルトの名無しさん
10/03/31 22:44:18
>>472
Javaの話をしていたんだよね。JavaってクラスベースのOOP言語だよね。
クラスとメソッドが対応するのは当たり前だよね。
メソッドのアドレスが格納されている、いわゆるvtableはクラスごとに用意されるのは知ってるよね。
そしたら、クラスとメソッドが関連付けられるのは自明だよね。
>オブジェクト指向を踏まえた上でどう実践していくかというフェーズで、
そのOOP前提みたいな論調はなんなんですかね。
まーOOPで出来る事はデータの整合をとる事ぐらいだってのが、
大衆にも大体ばれてきてて、
「だったらデータの整合性の管理だけをOOPに任せよう」、
って意味での「踏まえる」ならわかるが。
477:デフォルトの名無しさん
10/03/31 23:08:32
>>476
たぶん前半は俺宛じゃないと思うが、
それはどちらかというと「クラスインスタンス」じゃないか？
あと、データの整合性を取る云々は、「責務の分担を保障できる」と考えてみてはどうかな。
もちろん、慎重にコーディングすれば非OOPLでもできる話だが、
OOPLを使ったほうが当然効率が良い。
478:デフォルトの名無しさん
10/03/31 23:23:41
>>477
メソッドがクラスにくっついてるのがクラスベースのOOP。
メソッドがインスタンスにくっついてるのがプロトタイプベースのOOP。
こんなの常識過ぎるだろ。
そこの区別の問題があるから、JavaのようなクラスベースのOOPを説明するなら、
「メソッドはクラスと関連付けられる」って表現が適切なんだよ。
メソッドはインスタンスと関連付けられる、と書くと、プロトタイプベースなのかと勘違いされる。
479:デフォルトの名無しさん
10/03/31 23:30:00
>>478
クラスの中のメソッドと対応してる時はなんなのよ
480:デフォルトの名無しさん
10/03/31 23:32:06
えらく無知を晒してるやついるけど
オブジェクト指向は魔法みたいなものと勘違いしてんじゃねーの？
ほとんど似たようなものだろ
481:デフォルトの名無しさん
10/03/31 23:42:53
>>478
だからクラスインスタンスと書いたわけだが。
クラスに紐付く、という説明だとインスタンスを生成することの意味が分からなくなるし、
それにポリモーフィズムの説明ができない。
482:デフォルトの名無しさん
10/03/31 23:47:32
>>478
CLOS みたく、どっちにも付いてないのは何て言うんだ
483:デフォルトの名無しさん
10/04/01 00:03:47
>>481
Javaのポリモーフィズムはインスタンスのクラスに基づいて行われる。
わかる？
インスタンスのクラスのメソッドが呼ばれる。
もう一度言うよ。
インスタンスのクラスのメソッドが呼ばれる。
インスタンスがメソッドを持っているわけではない。クラスがメソッドを持ってる。
メソッドの呼び出しは、インスタンス→動的クラス判定→メソッドと、クラス経由で呼び出される。
「クラスのメソッド～」って表現、日常的に使うでしょ。
一方、インスタンスがメソッドを持ってるのは、プロトタイプベースと言う。
でもちょっと考えれば分かりそうなもの。
Javaでは同じクラスのインスタンスであれば、
ポリモーフィズム時に呼び出されるメソッドは同じものになるよね。
これはメソッドがクラスに結びついているから。
484:デフォルトの名無しさん
10/04/01 00:06:36
てか本当に初心者が多いな。
こんなんがOOP万歳してるんだろうな。
せいぜい今のうちにいい夢みてればいいよ。
すぐに 大人たちは嘘つきだ って言い出すから。
485:デフォルトの名無しさん
10/04/01 00:25:32
>>483
いや、内部的にはその通りだよ。
というか、俺と同じことを言ってるようにしか見えんのだが。
後段については、インスタンスを外部から呼び出す側は、
そのインスタンスの実装クラスが何か、ということは意識しないよね、という話。
あるインタフェースを実装したインスタンスのメソッドを呼ぶと、
実装クラスに合わせて処理が動的にディスパッチされる、
という話を認めると、何か都合が悪いのかもしれないけどさ。
(もちろん、これはOOの要素技術の一つであって、定義でも本質でもない)
486:デフォルトの名無しさん
10/04/01 00:28:13
OOPをやってると、どんどん恥垢が溜まっていくのだろうか…
487:デフォルトの名無しさん
10/04/01 00:39:53
>>486
反論ないなら寝るけど、他人を自分と同レベルに引きずり落とすことに熱心になるくらいなら、
自分の世界を広げる努力をした方がいいと思うよ。
488:486
10/04/01 00:48:27
すみません特別誰の発言に向けた言葉でもありません…
コーディングしてると垢のようなものが溜まっていくような感覚がしまして…
思考が固まっていくような…独り言でした…紛らわしくてすみません…
489:デフォルトの名無しさん
10/04/01 00:52:39
コーディングが煮詰まると恥垢が溜まるとは珍しい人ですね。
490:デフォルトの名無しさん
10/04/01 00:55:19
削れば恥垢は落ちます…
僕と一緒に綺麗になりましょうよ…ウホッ
491:デフォルトの名無しさん
10/04/01 01:02:42
OOPがもし発明されなかったら、
入力支援の方向が左になってたんだろうか。
構造体の変数書くと、その構造体を使う関数が左にずらりと並ぶ・・・
492:デフォルトの名無しさん
10/04/01 01:10:57
>後段については、インスタンスを外部から呼び出す側は、
>そのインスタンスの実装クラスが何か、ということは意識しないよね、という話。
その、何か気にしないで済む「実装クラス」とメソッド群は対応しているだよね。
実装クラスが判明すれば、メソッドは一意に決定するんだよね。
クラスが分かればメソッドは決定するんだよね。
クラスがメソッドを決めるんだよね。
だったら、メソッドはクラスにぶら下ってるよね。
てかもう本当にいやになってきた。
JavaなんかのクラスベースのOOPでメソッドがクラスに関連づいてるってことを否定する人って何なのよ。
クラス作らなきゃポリモーフィズム出来ないって時点で気づけよ。
メソッドがクラスにくくりついてるから、
多態したいだけクラス作らなきゃ多態できないんだ。
同じクラスのインスタンスで多態できるか？出来ないよな。
ちなみに、プロトタイプベースだとこれが出来る。
その差はなんだ？メソッドがクラスにぶら下っているか、インスタンスにぶら下っているかの差だよな。
493:デフォルトの名無しさん
10/04/01 01:21:02
>>491
俺も昔それを考えた事がある。
俺の結論はこう。
「関数名を書くと、引数にとりうる型の参照可能な変数が列挙される」
要は引数を補完する。何気に便利そうだ。
ところで、OOPで使われる object.method() って並びは英語的に変じゃない？
俺たちはコンピュータに命令を下しているわけだから、命令文的に、
command( object ) の方が自然に思えるのだが。
やっぱOOPって何から何までキモいと思う。
494:デフォルトの名無しさん
10/04/01 01:24:42
アドレス空間上、コード領域に置かれるのが判ってるなら～ベースなんてどうでもよくね？ｗ
495:デフォルトの名無しさん
10/04/01 01:31:03
>>492
インスタンスの利用者から見れば、クラスベースであれプロトタイプベースであれ、
メソッドのコードが実際にはどこにぶら下がっていようが、処理系がその詳細を
隠蔽する以上、「インスタンスのメソッドを呼び出す」という風に見えるのだから、
多態性を説明する時に、メソッドがクラスに紐付いていることを過度に強調してなんか意味あるの？
っていう話じゃないの。
496:デフォルトの名無しさん
10/04/01 01:36:45
>>493
Objectが主語だからでしょ。
497:デフォルトの名無しさん
10/04/01 01:49:33
>>495
インスタンスの設計者はどうなるんだよ。
使う側が気にしなくても良いってのはいつでも真理だよ。
それに俺は何も強調して無いぞ。
俺「メソッドはクラスに関連付いてる」
彼「どちらかというとメソッドはクラスインスタンスに関連付いてるんじゃね」
俺「どちらかというとクラスでしょ」
498:デフォルトの名無しさん
10/04/01 01:51:57
>>493
＞「関数名を書くと、引数にとりうる型の参照可能な変数が列挙される」
おぉ、いいね。
これはOOPであっても実装してほしいぞ。
変数マークアップ機能の次はこれだ。
＞object.method() って並びは英語的に変じゃない？
英語的にも日本語的にも変だな。
command( object ) という書き方がゼロになっていないということも、
戸惑わされる。中には、どちらの表現もできたりする。
object.method() は廃止の方向でいいかもな。
499:デフォルトの名無しさん
10/04/01 01:58:39
>>496
> Objectが主語
object.getValue();
オブジェクトが値を得るわけじゃないのに主語？
操作の対象なんだから、オブジェクトのその名のとおり、目的語が適当だと思うんだがな。
オブジェクト指向って名前止めて、主観指向に改名すりゃいいのに。
この破綻したパラダイムにはそっちのがお似合いだろーよ。
500:デフォルトの名無しさん
10/04/01 02:09:24
>>496
objectは目的語ですよ。辞書的にみて。。。。。という冗談は置いといて、
objectにmethodというメッセージを送って処理を行わせる。
英語的には、Let object methodという感じなのかな？
こじつけだけど。
501:デフォルトの名無しさん
10/04/01 02:25:46
もっとバトルしてくんねぇかなあ
OOPer vs アンチOOPer
ま、アンチOOPerはOOPを理解できないって点で既に劣ってるわけだがｗ
理解してたら争う意味もねぇな
502:デフォルトの名無しさん
10/04/01 02:26:56
現実にはやっぱりオブジェクトは目的語だとおもうよ。
コンピュータに処理をさせる対象として「オブジェクト」なんだから。
でも、OOPの世界ではオブジェクトは、まるで主語であるかのような語順だし、
考え方も、オブジェクトを中心に考えるってんだから、
主語にしようと試みてるのだろうね、現実がどうであろうと。
壮大なウソを突き通そうとするのは大変なものだね。頑張れ北朝鮮、まけるな左翼団体。
object1.hoge();
object2.piyo();
とかさー。
個性豊かなオブジェクト達が、
めいめいに、「僕は～する」、「僕は～する」、と、ぶつくさ独り言を唱えてて、
一向にまとまらない様は、オブジェクト指向の本質ですらあると思う。
command( object1, object2 );
と命令してやりたくなる。
503:デフォルトの名無しさん
10/04/01 02:44:06
そんでオブジェクト同士が生命維持装置のごとくメッセージを飛ばしあいこしてさー。
プログラマはそれのご機嫌取りに終始させられて。
んで、オブジェクト当人たちはウジウジしててなかなか他のオブジェクトと関わろうとしないしさ、
誰が音頭取るんだよ、とか思ってたら、コンポーネント！とか叫びながら、
親分クラスが登場してきてさー、
そしたら変な木構造が出来上がって、
こんどは、それにそぐわないような処理は出来ませんとか言い出して、
だったら、単一の木構造は止めようとか言うから、ガベコレだね、って
どーすんのこれ。
504:デフォルトの名無しさん
10/04/01 07:43:23
>>497
ポリモーで動的に管理したら、実際に動いてるクラスが何かを知る方法って簡単には無いよね
インスタンス単位でみないと、アップキャストされた基底クラスなのか
基底クラスのままのインスタンスなのかで違うやろ
いくらクラスで設計しても、インスタンス管理の設計もしなくちゃならんわけだし
貴方の言いたい方向がよくわからん
505:デフォルトの名無しさん
10/04/01 08:06:04
>>504
多態性をC言語で表現するのは無理ではないけど明らかにしんどいし、
「それOOPじゃなくてもできるじゃんｗｗｗ」の彼としては目を背けたい部分なんじゃないか。
506:デフォルトの名無しさん
10/04/01 08:19:39
>>502
> 現実にはやっぱりオブジェクトは目的語だとおもうよ。
語順的にはそういうケースは多いな。
ただ、オブジェクトを主体として考える概念であることには違いない。
各主体に責務を割り当てて、（君曰くウジウジしてる）オブジェクト同士に適切な関係を設定してやると。
「関数に書かれた手続きをプログラマが仕切ってグワっと並べるのがプログラミングだろ！」
というのは確かに漢らしいかもしれないけど、それで物事が片付くのはかなり小さなシステムに限定される
ということに気づかないと、確かにオブジェクト指向はプログラマの主導権をスポイルする軟弱な概念に見えるのかもな。
507:デフォルトの名無しさん
10/04/01 09:22:32
thread.run()とか、object.toString()とか、すごく自然だ。
508:デフォルトの名無しさん
10/04/01 09:57:31
おまいら実際、どんだけの物を書いたの？
俺はJavaで5万行。Rmi+JDBC+Appletなシステムを一人で書いた。
C++で一万行。PlatformSDK+Win32API使ってエディタ書いた。
一方、Cでは宿題スレの宿題を書いた。
上記エディタは最初BCCのCを使って書いていたが、
なんだが息苦しくなってC++で書き直す羽目になった。
AbstractWindowを作って、色々派生させて画一的に扱いたかったから。
509:デフォルトの名無しさん
10/04/01 10:56:38
批判ではなく、純粋な質問なのだが
何行書いた、というのは具体的にどんな意味があるの？
510:デフォルトの名無しさん
10/04/01 11:13:41
規模の目安。
なるべく簡潔に書く派と、そうでもない派があれど、
百行と一万行は規模が違うし、一万行と十万行も規模が違う。
（そうでもない派ってのは、可読性のため一時変数を導入したり、
コメントもたっぷりつけたり、改行を間に入れがちなスタイルだったり）
おまいらがどんな規模のものを想定して発言してるのか聞いてみたかっただけ。
規模が大きくなればなるほど、カプセル化やポリモーフィズムが恋しくなるから。
511:デフォルトの名無しさん
10/04/01 11:14:00
ＯＯＰだと例えばシューティングゲームでの敵を処理する場合
移動する場合 enemy.move() とか書けて
さらに同じ敵でも敵クラス継承すれば enemyTypeA.move() とか enemyTypeB.move() とか
違う敵の種類でも .move() と同じ書き方しても使用するインスタンスにより違う動きをさせることができるから直感的に記述することができる
さらに敵クラスがオブジェクトクラスを継承したものだとすると
それを自機クラスに継承させると myShip.move() と同じように書ける
同じことＣでやろうとするとどうなるか
関数名をいくつも用意させなければならない羽目になる
例えば move_EnemyTypeA(EnemyTypeA *enemyTypeA), move_EnemyTypeB(EnemyTypeB *enemyTypeB), move_MyShip(MyShip, *myShip)
とか用意しなくいけなくなり、面倒になる
これがＣ＋＋なら move() だけで済み、これだけで「動く」という処理を直感的に記述することができる
取りあえずの１例としてＯＯＰの便利さを示した
512:デフォルトの名無しさん
10/04/01 11:52:56
OOPは利点が多々あるが、そんな直感的な記述はすべきではない
513:デフォルトの名無しさん
10/04/01 11:57:25
>>512
なぜだね？
514:デフォルトの名無しさん
10/04/01 13:07:52
根本的に、コンピュータはマシン語でしか動かない
その為、結局どんな手法でも、複雑さは変らないが
手法によって複雑さを、人間に表現させる方法に差が出る（手法や言語は、人間が理解し易くする為の物）
・POA（機能中心アプローチ）：”アルゴリズム”を中心に、複雑な処理を表現する
・DOA（データ中心アプローチ）：”データ構造”を中心に、複雑な処理を表現する
・OOA（オブジェクト指向）：アルゴリズム＋データ構造(クラス)の”構造(オブジェクトの連係)”を中心に、複雑な処理を表現する
515:デフォルトの名無しさん
10/04/01 13:41:25
>>493
「彼女を守る」「法律を守る」で「守る」の意味は全然違う。「彼女を守る」ことは「彼女に
従う」ことではない。
英語だと、「I drew a veil」は「私はヴェールを描いた」だが、「I drew a veil over my face」だと、
「私は顔にヴェールをかぶった」となる。
英語のようにメソッドを先に記述すると、解釈が文末までなかなか確定しなくて不便だ。
「Join(Thread)」だと、どうも心が落ち着かない。オブジェクトを先に記述する「Thread.Join()」ほうが
好まれた。
516:デフォルトの名無しさん
10/04/01 14:46:56
メッセージングのアイデアはアラン・ケイの発案だが、彼はこんなふうに説明している。参考まで。
このような柔軟な機能はどれだけ複雑である必要があるだろうか?
文法上は決して複雑で無くてもよい。なじみ深い英語の語順である主語、
動詞、目的語(よく前置詞や、たまに暗黙の主語を伴う)があれば全く十分だ。
オブジェクト指向の言い方で言うと、主語はメッセージのレシーバであり、
文の残りはメッセージだ。《略》という事で、オブジェクトはただ
ネットワーク上のピア・ピア・サーバのように考えられ、使われると考える。
(これは偶然ではなく、六十年代後期におけるARPAnet から Internet にかけての
開発にさかのぼるアイデアを起源とする)。
URLﾘﾝｸ(metatoys.org)
517:デフォルトの名無しさん
10/04/01 15:01:35
アラン・ケイには敬意を表するが、
彼の言ってることをあまり理解したいとは…思わないｗ
518:デフォルトの名無しさん
10/04/01 15:18:36
class S
{
void V()
{
o.C();
}
};
こんな感じだと思っていたのに
519:デフォルトの名無しさん
10/04/01 18:21:29
>>515
Thread.Join()の方がキモいと思うがなぁ。
だって、実際にJoin処理を行うのはコンピュータであって、Threadじゃないから。
computer.join(thread)ってイメージ。
今思いついたが、please.join(thread)って書き方が洒落てて面白いかもしれない。
pleaseってクラス作って、グローバルな関数を全部ぶち込んどく(笑
でもさー、
アセンブリでもadd a, bと書くし、Unixのシェルでもcat fileとか書くんだから、
やっぱコマンドが前に来るのが自然な発想なんじゃないの？
不自然なことすると、ウソが雪ダルマ式に膨らんで、どっかで詰むよ。
520:デフォルトの名無しさん
10/04/01 18:32:04
でさー、
目的語を前に置くのは、そう言う方言だから仕方が無い、ということで了承したとしても、
目的語が二つ以上あった場合はどうするんだという問題が残るよね。
(object1, object2).method;
こうは書けないんだろ？
だったら素直に、func(object1, object2);で良いと思うのだが。
521:デフォルトの名無しさん
10/04/01 18:44:25
引数が二個以上あるとややこしい。
strcpyに渡す二つの変数、どっちがsrcかdstか分からなくなる。
str.copyTo(str2)のほうが見やすいのでは？ どうかね？
522:デフォルトの名無しさん
10/04/01 20:09:33
>>519
それを言い出すと、そもそも「コンピュータに処理を命令（コマンド）する」という概念自体が
「ウソ」なわけだが。
物理的には電気信号の微細な変化に過ぎないし、理論的にもチューリングマシンの
定義に「命令」とか「コマンド」なんて単語は出てこない。計算機に算譜を入力する行為が
「命令」のアナロジーと相性が良いから、という程度の話。
極端に言えば、コンピュータ技術ってのは、ただの電気信号の変化に過ぎないものを、
いかにうまく「ウソ」をついて、それに何か意味を持っているかのごとく人間に誤解させるか、
そういうものだと言ってもいい。
それを「人間から計算機への命令」という形で見せるか、「計算機の中にある仮想的な
ノード間でのメッセージのやり取り」という形で見せるかは、単に流儀の問題に過ぎない。
そして、>>520-521のやり取りで如実に現れているが、特に二者関係を扱うときに、
「ただ一つの計算機に人間が命令して仕事をさせる」というモデルでは、うまく扱えないことが多い。
そこをうまく概念化して整理できるのが、オブジェクト指向の利点の一つだ。
とりあえず、君がオブジェクト指向の何に躓いてるのかは何となく見えたけど、まぁ、あれだ、
もっと広い物の見方を身につけろ、としか言えんな。
計算機の世界の広さは、人間の発想力の広さと同じなんだよ。それを自分で狭めるこたない。
523:デフォルトの名無しさん
10/04/01 21:10:12
>>518
クラスを作ることはオブジェクト指向言語では必須ではないはず。
クラスをつくらない言語というのもあるから（何かは忘れた）。
あと、インスタンス化のオブジェクト指向言語では必須ではないはず。
C++やJavaはピュアオブジェクト指向言語ではなく、マルチパラダイム言語なんだよね。
>>520
目的語２つというのはおかしいよね。
その場合だと、意味的にはobject1, object2の２つをもつセットにmethodを行わせるという形になるんじゃない。
524:デフォルトの名無しさん
10/04/01 21:12:57
うわ、でたよ。得意技の詭弁。
池沼じみた発言をしてすぐ煙に巻こうとする。
なんでもそうだけど、コマンド的なものが前に来るのが一般的で、
それを否定しようが無いから、電気信号が～とかわけわからんこと言い出す。
if文が {}(x)if だったら嫌だろ？
for文が {}(;;)for だったら嫌だろ？
>特に二者関係を扱うときに、
>「ただ一つの計算機に人間が命令して仕事をさせる」というモデルでは、うまく扱えないことが多い。
簡単だよ。command( object1, object2 ) ほらよ、object1とobject2の2者間の関係をうまく扱えたよ。
「ただ一つの計算機に人間が命令して仕事をさせる」ってモデルは現実を良くあらわしているし、
なにもウソは無いし、それでみんなうまくやってきているわけだから、
それを「うまく扱えない事が多い」って言うのは現実を否定している罠。
だって、一台のコンピュータに命令を下して皆仕事してるんだろ。
それに、2者間の関係を表すのは一般的にはOOPのほうが苦手だ。
object1.relation(object2);
object2.relation(object1);
メソッドをどっちのクラスに実装すべきか迷うし、どっちに実装したとしても不自然で不細工だな。
525:デフォルトの名無しさん
10/04/01 21:18:57
>>523
>目的語２つというのはおかしいよね。
なんでおかしいんだよ。
複数のオブジェクトに対して処理をしたいことだってあるだろ。
目的語は常に一つってのはOOP脳か何かか？
526:デフォルトの名無しさん
10/04/01 21:27:38
前、別のスレであった奴
(map (lambda (x y) (+ x y)) '(1 2 3) '(4 5 6))
map(lambda x,y:x+y,[1,2,3],[4,5,6])
[[1,2,3],[4,5,6]].transpose.map{|x,y| x+y}
rubyの方はあまり直感的じゃないと思う
527:デフォルトの名無しさん
10/04/01 21:37:21
>>524
> if文が {}(x)if だったら嫌だろ？
> for文が {}(;;)for だったら嫌だろ？
逆ポーランド記法、でググってみるといいと思うよ。
ていうか、関数型言語だとそういう感じの記法ってよく見かけないっけ（制御文であるかは知らんけど）。
本題の話をすると、>>522は別に詭弁でもなんでもなくて、むしろコンピュータの本質だよ。
プログラミングというのは、人間の物の見方、すなわち価値観を計算機に入力することだ、と言ってもいい。
オブジェクト指向的な価値観は絶対ではないが、一方で、命令的なパラダイムもある時期に支配的だった
価値観の反映に過ぎない。どちらも、対象をモデル化するためのもので、表現の仕方が違うだけ。
だからこそ、君がやってるように、OOPLでの表現を非OOPLで表現することができるわけだ。
その上で、わざわざ分かりにくく、効率の悪い方法で表現する必要もなかろ、という話。
528:デフォルトの名無しさん
10/04/01 21:55:41
>>520
それよくある。
二つのクラスに密接に関わる関数を、
どっちのクラスにメソッドとして装備させようか、
判断がつかないのな。
結局、Utl とか、Ability とかの名前の静的クラスを用意して、
static な関数を集めることで便利に使えている。
そこに関連する定数も集めておく。
静的クラスは案外使える。
何でも new できればいいわけじゃないって。
>>521
str2 = str1
が一番見やすいと思うｗ
演算子への適用もOOPの利点だよな。
vector + vector
ができるのがいいんだけどな。
529:デフォルトの名無しさん
10/04/01 22:06:17
逆ポーランド記法ぐらいしってるって。
「嫌だろ」という話をしてるんだ。事実、あんま使われねーだろ、読みにくいから。
ざっくり言うと、今、「後置記法は読みずらいだろ」みたいな話をしているわけでしょ？
なんで、電気信号がどうとかって話になるんだ？詭弁だろ。
それに、コンピュータが「何か」するのは事実だろ。
実際お前の目の前で「何か」しているだろ。
オブジェクト指向みたいに、そう言う風に見せかけているだけじゃなくて、
ハードウェアレベルで「何か」しているよね。
それに指示出すこと考えているんだから、そのハードウェア構成を端的にモデル化した
言語で指示出したいよね？何がある？ただの電卓と違う点は何処？
まずメモリ空間があるよね。次にプログラムカウンタがあるよね。
だったら、プログラミングってのはメモリ空間をどう分割するかという「データ構造」と、
プログラムカウンタをどう制御するかという「制御構造」に終始することになるよね。
OOPなにそれ。オブジェクトがメッセージ投げ合ってどうのこうの？好きにやってよ。
どっかでハードウェア構成とのギャップが出てきて苦しむんだ。
実際のハードウェア構成と合っていない、それが「ウソ」だということだ。
お前の言うわけのわからん「ウソ」の定義と違って明確だな。
530:デフォルトの名無しさん
10/04/01 22:07:09
ベクターの足し算が＋で出来るとか、どうでもよすぎる
531:デフォルトの名無しさん
10/04/01 22:18:51
>>529
おまえ、OOPの良さが理解できないんだろ？
OOPすら理解できない能無しは発言しないでくれるかな。
532:デフォルトの名無しさん
10/04/01 22:21:31
俺の知る限り、物事を深く理解する者は、その暗部も認めるものだ。
533:デフォルトの名無しさん
10/04/01 22:26:02
良い部分を知らない奴と、良し悪しの両方を理解している奴じゃ次元が違うっしょ。
534:デフォルトの名無しさん
10/04/01 22:30:48
>>529
これほど歪んだアセンブラへの愛の吐露は初めて見た。
> まずメモリ空間があるよね。次にプログラムカウンタがあるよね。
> だったら、プログラミングってのはメモリ空間をどう分割するかという「データ構造」と、
> プログラムカウンタをどう制御するかという「制御構造」に終始することになるよね。
1. OSや低レベル言語処理系がハードウェアをそういう風に見せているだけ、だけどな。
2. そういう道具立てを使って、異なる価値観に基づいたモデル化をするという方法もあるのだよ。
仮想化って知ってる？
> それに指示出すこと考えているんだから、そのハードウェア構成を端的にモデル化した
> 言語で指示出したいよね？
実現したいユーザ体験を、簡潔かつ変更に強い形でモデル化できる言語で指示を出したいです。
> OOPなにそれ。オブジェクトがメッセージ投げ合ってどうのこうの？好きにやってよ。
> どっかでハードウェア構成とのギャップが出てきて苦しむんだ。
多少の処理負荷の増大よりも、モデル化のしやすさを追求して人間に楽をさせてくれるのがオブジェクト指向。
ギャップなんてものは、ハードウェア性能の向上で既に吸収されている。
> 実際のハードウェア構成と合っていない、それが「ウソ」だということだ。
単体ハードウェアを前提にするのが好きみたいだけど、
分散コンピューティングとか並行プログラミングって知ってるかな？
535:デフォルトの名無しさん
10/04/01 22:33:05
なんで悪い部分だけをピンポイントで知りえると思うのか。
せっかくなので、OOPの良い部分を語ってもらいましょうかね。
カプセル化？多態？オーバーロード？何が挙がるかな。
でも、多くの人たちが挙げる利点の中には、
OOPとコンピュータの相性が悪い部分を吸収するために
仕方なく追加したような妥協的機能を、何故かありがたがっている変なケースもあるよ。
物は言いようという奴。
536:デフォルトの名無しさん
10/04/01 22:47:34
ほらまたOOP信者の詭弁ごっごが始まった。五万とみてきた。
こういう風になればいいなぁ～ああいう風になればいいなぁ～そんなばっか。
何が出来て何が出来ないかまるで区別が付いていない。
お前に限って言えば、「～って用語知ってる？」
こんなばっか。しかも提灯記事に使われるようなキャッチーな技術用語ばっか。
お前にそれらの用語のバックグラウンドに潜む技術が必要になることは
永遠に無いだろうになー、ご苦労な請った。
> 実現したいユーザ体験を、簡潔かつ変更に強い形でモデル化できる言語で指示を出したいです。
何これ(笑 政治家みたいな言い回しだな。出来るといいね。被れてる間は無理だと思うが。
> 多少の処理負荷の増大よりも、モデル化のしやすさを追求して人間に楽をさせてくれるのがオブジェクト指向。
「追求して」だってさ。いつからOOPはそんな言語になったんだ。
どうやったらそんな無責任で適当な事ばっかいえるのか。お前やっぱおかしいよ。
> ギャップなんてものは、ハードウェア性能の向上で既に吸収されている。
はぁ？実行時のオーバーヘッドのはなしなんかしてたっけ？
ゆわば設計時のオーバーヘッドの話をしていたんじゃないの？大丈夫？
537:デフォルトの名無しさん
10/04/01 22:52:42
>>536
技術的な反論をしてくれないかな。
あと、君の言う「プログラム」というのはどの程度の規模と複雑さを想定している？
538:デフォルトの名無しさん
10/04/01 22:56:14
ちなみに、非スタンドアロン環境（並行コンピューティングとか）に対する反論もまだだね。
ぜひ合理的にお願いしたいところだけど。
539:デフォルトの名無しさん
10/04/01 23:02:01
オブジェクト指向の出発点には些細なウソが含まれてて、
そのウソを突き通すために、OOPで書かれたプログラムやOOP自体が、
雪ダルマ式にファットになってる。
そのウソがあったからこそ、あることに目を瞑ったからこそ、
夢が広がったんだけれど、でも、もともとがウソから始まってるから、
物語は悲しい幕引きになる。現実逃避の産物といえるな。
OOPにあるのは生産性ではなくてエンターテイメント性だったってわけさ。
540:デフォルトの名無しさん
10/04/01 23:02:40
メモリ空間やプログラムカウンタっていうハードウェアがある、とか思ってる件についても聞こうか。
541:デフォルトの名無しさん
10/04/01 23:09:23
オブジェクト指向ってようするにモジュールを分割する手法のひとつでしょ
542:デフォルトの名無しさん
10/04/01 23:12:46
>>519
そう書くと、Computer.Join(Char, String)か、Computer.Join(Thread)とかになる。
文字列結合のJoin()とスレッド同期のJoin()が全く違うことをやるので、気持ち悪い。
あと、String.Replace("a", "b").Replace("c","d")を、Replace(Replace(String, "a", "b"), "c", "d")
みたいに書かなければならなくなる。
>>520
オブケクト配列を対象とするメソッドは、(Object1, Object2).Method()で問題ないだろう。
543:デフォルトの名無しさん
10/04/01 23:15:25
>あと、君の言う「プログラム」というのはどの程度の規模と複雑さを想定している？
これは難しいな。OOPを使わないで、機能ごとにモジュール化していくかぎりは、
モジュールごとで完全なカプセル化が行えるから、それほど複雑にならないし、
規模と複雑さは「なんでも」って事になるだろうな。
OOP使わない方がカプセル化は硬くなるし、オーバーライドやオーバーロードなどの
あいまいさも減るから、安全になる、とは言っとく。
反例挙げるなら再利用性について言及すべきだったな。
>ちなみに、非スタンドアロン環境（並行コンピューティングとか）に対する反論もまだだね。
>ぜひ合理的にお願いしたいところだけど。
ノイマン型コンピュータである限り構造は同じだ。
メモリ空間があって、プログラムカウンタがある。ただ、それらが複数あるってだけだ。
データ構造と制御構造は複雑に成るだろうが、それは、ハードウェア構成が複雑なのだから仕方が無い。
何もウソは無い。
544:デフォルトの名無しさん
10/04/01 23:17:03
>>539
君が言ってる「命令」や「ハードウェア」は、それもまた「ウソ」の産物だというのは既に指摘したよね。
べつに、「ウソ」だから悪いわけじゃない。
人間に対してより素晴らしい「ウソ」をつける計算機環境こそ、我らの目指すべきものだからね。
そして、「ウソ」のつき方も一通りじゃない。
例えば、「ウソ」の上に「ウソ」を塗り固めた環境を用意して、その上でコーディングするというのもアリだ。
早い話が、スクリプトのランタイムとか、Javaや.NETの仮想マシンとかだな。
そういう環境で処理性能も同時に追求したいなら、JITに任せればいいわけだし。
545:デフォルトの名無しさん
10/04/01 23:24:30
>>543
っ【マルチプルインスタンス】
> メモリ空間があって、プログラムカウンタがある。ただ、それらが複数あるってだけだ。
複数あって協調させなきゃいけない時点で、
単純な「人間 vs. 計算機」の命令モデルは破綻するわけですが。
546:デフォルトの名無しさん
10/04/01 23:27:24
>>542
> 文字列結合のJoin()とスレッド同期のJoin()が全く違うことをやるので、気持ち悪い。
そりゃお前普通にコンパイルエラーだろ。オーバーロードなぞ俺も嫌いだ。
>あと、String.Replace("a", "b").Replace("c","d")を、Replace(Replace(String, "a", "b"), "c", "d")
>みたいに書かなければならなくなる。
あーどうしよう、
String.Replace("a", "b").Replace("c","d")
が汚く見えてしまう。
547:デフォルトの名無しさん
10/04/01 23:34:47
>>539
言いたいこと、なんとなくはわかるけど。
関数を構造体と合体させたのは確かに問題が多いかもしれない。
それで、グローバルオンリーの関数群のカプセル化機能が
付加できなかったわけではないし、
構造体だけ継承を付ければ、よかったかもしれない。
とにかく、もっとシンプルな言語の進化であったほうがよかったのは、認める。
僕は、OOPがもっと理想的な状態でコンパイルされれば、
それほど遅くなるはずがないと思っている。
ベースのよりマシン語レベルへの変換が行われにくさがあるから、
コンパイラが完全になりにくいだけなんだよ。
それでも、マシン語レベルまで落とすことは不可能だと思わないし、
現に最近のコンパイラはより速いコードをはくようになった。
上の議論で目的語が二つ以上のとき苦手というのがあったが、
逆に、一つに集中しているときは得意というのもある。
jQueryのメソッドチェーンとかさ。
大規模ならOOPという意見があるが、
クラス設計ミスると、とてつもないことにならんの？
小規模なスクリプト系で、他人が念入りに設計したものを使うのにOOPは便利じゃん。
548:デフォルトの名無しさん
10/04/01 23:41:31
>>544
> 君が言ってる「命令」や「ハードウェア」は、それもまた「ウソ」の産物だというのは既に指摘したよね。
またなんか言い出した。こいつ本当にどうしようもないな。
それじゃあれですかね、数学の数字の「1」もウソの産物なんですかね。
まぁそんなことはどうでも良いんですけどね、だってそれは、お前の言ってる
中学生のいいわけみたいな意味で「ウソ」という言葉を使っているわけじゃないからな。
俺は明確に、ハードウェアとのミスマッチ、実態とのミスマッチが俺の言う「ウソ」の定義だと
宣言しているわけで。お前の勝手な定義で話し進められても困る。
>>545
メモリ空間をどう分断するか、それは、マルチプルインスタンスそのものだ。
データをどう配置するかって話だからな。
> 複数あって協調させなきゃいけない時点で、
> 単純な「人間 vs. 計算機」の命令モデルは破綻するわけですが。
「人間 vs. 複数の計算機」になるだけだろ。
こんどは複数の計算機に対して命令を出すわけだ。
どういった状態でネットワーク化されているかによって書き方が変わってくるだろうが、
そこにウソは無いよ。
549:デフォルトの名無しさん
10/04/01 23:44:52
>>547
> クラス設計ミスると、とてつもないことにならんの？
クラス設計をミスって大被害を負うような規模で、非OOで組むとか想像もしたくないな。
その辺のリスクを軽減できる、オブジェクト指向より良い抽象化手法が出てくる可能性は否定しない。
どちらにせよ、ハードウェア大好きな彼が望む方向とは真逆だろう。
550:デフォルトの名無しさん
10/04/01 23:45:29
また、文字列クラス（＝サブルーチン）でオブジェクト指向語るアフォがでたのか？
だからそんなサブルーチンじゃ
オブジェクト指向の話なんかできねっつのｗ
なんでいつまでたっても設計レベルの話ができないんだこいつはｗ
551:デフォルトの名無しさん
10/04/01 23:47:55
>>547
おー分かてるねー。
もともとオブジェクトってのはデータ構造寄りの発想なのに、
そんなところに、制御構造をぶら下げた罪は大きい。
おかげで制御構造はズタズタ。
パゲッティーって何の事だったっけ、人類は過去から学ばないものだね。
後半の実行速度云々は俺はあんま気にしないけどな。
552:デフォルトの名無しさん
10/04/01 23:49:43
>クラス設計をミスって大被害を負うような規模で、非OOで組むとか想像もしたくないな。
非OOPでモジュール単位で完璧なカプセル化を行った方が
はるかに安全なんだよ。柔軟性は損なわれるがな。
やっぱりわからない人なんだね。
553:デフォルトの名無しさん
10/04/01 23:51:53
>>548
例えばだが、いまどきのOSで、君の大好きな「メモリ空間」が
物理アドレスと一対一対応じゃないことくらいは当然知ってるよね・・・？
それに、まさか仮想メモリを指して「ハードウェアとミスマッチだからてめーは駄目だ」とか言わないとは思うが。
> メモリ空間をどう分断するか、それは、マルチプルインスタンスそのものだ。
> データをどう配置するかって話だからな。
それ、全部処理系に任せようよ。
> 「人間 vs. 複数の計算機」になるだけだろ。
> こんどは複数の計算機に対して命令を出すわけだ。
君も、既に計算機が自律分散協調であることの恩恵を受けてるはずなんだがなぁ。
そんなに命令モデルでないと許せないなら、今日からGoogleを使うのはやめた方がいい。
554:デフォルトの名無しさん
10/04/01 23:54:00
>>552
> 柔軟性は損なわれるがな。
OOが支持される理由、その答えを自分で言ってるわけだが。
555:デフォルトの名無しさん
10/04/02 00:09:23
>>553
？？？
仮想メモリはハードウェアとマッチしてるだろ？何言ってんだ？
> それ、全部処理系に任せようよ。
データの配置を処理系が面倒見てくれるのは悪くないと思うよ。
でもそんな話してたっけ。
> 自律分散協調
で、でたー。まさに人権屋的発想。こういうやつらこそOOPを駄目にしているのだろうな。
いちおう教えといてあげるけど、お前、多分いわゆる中2病状態だよ。
あとでわかるよ。
556:デフォルトの名無しさん
10/04/02 00:16:44
あれだよ、柔軟性は必要になってから書き足しても問題ないし、
再利用性は、初めから期待するだけ無駄というもの。
どうせ使いまわせるのは、使いまわす必要が無いほど単純なものか、
もしくは、完璧にカプセル化された製品レベルの巨大なモジュールかのどっちかだ。
557:デフォルトの名無しさん
10/04/02 00:51:02
>>555
> 仮想メモリはハードウェアとマッチしてるだろ？何言ってんだ？
逆だ、ソフトに合わせるようにハードが作ってあるだけだ
誰かがもっと効率のいい仮想メモリ管理アルゴリズムを思いつけばハードもかわる
558:デフォルトの名無しさん
10/04/02 01:28:06
またサブルーチン馬鹿が現れたか
559:デフォルトの名無しさん
10/04/02 01:53:24
なんでサブルーチンでオブジェクト指向の話をするのかわからないな
んで結局、メモリがどーだとか実行速度がどーだとか関係ない話に行っちゃう
馬鹿だろ？
頭悪いだろ？
設計とかやったことないだろ？
なんでそんなに頭悪いの？
560:デフォルトの名無しさん
10/04/02 02:31:39
俺はOOPLが当たり前の世代なので、非OOPな人にマジで聞きたい
複数のクラスのインスタンスがごちゃ混ぜに入れられたコレクションの
各要素を文字列化し、出力する…という処理は
OOPLだと各要素に対してtoString()とかそれに準ずるメソッド呼べば良いんだが
非OOPLではどう書けば良いんだ？
561:デフォルトの名無しさん
10/04/02 03:01:10
>>560
なんでそんなサブルーチンの話をするの？
562:デフォルトの名無しさん
10/04/02 03:02:50
>561
何故って、どうやって書くのか疑問に思ったから
563:デフォルトの名無しさん
10/04/02 03:09:11
>>562
じゃ、スレ違いだから別スレでやってね
564:デフォルトの名無しさん
10/04/02 03:10:46
このスレで話していいよ。
OOPvs非OOP
565:デフォルトの名無しさん
10/04/02 03:26:34
構造体にタグ入れといてclass1_toString(),class2_toString()・・にswitchって感じじゃない？
関数ポインタ使う仕組みとかでもいける
566:デフォルトの名無しさん
10/04/02 03:26:44
聞きかじりオブジェクト指向ばっかｗ
567:デフォルトの名無しさん
10/04/02 03:28:57
何か色んな階層の話に飛び火して
意味が分からない。
568:デフォルトの名無しさん
10/04/02 03:29:11
サブルーチン馬鹿よりかはマシだな
569:デフォルトの名無しさん
10/04/02 03:31:37
まあさ・・・
オブジェクト指向が有用でも別にお前が偉いわけじゃないって種類の反感があるんだよ
570:デフォルトの名無しさん
10/04/02 03:32:51
オブジェクト指向にstatic変数があるのがおかしいと思う。
これさえなければたとえCであってもOOPになると思う。(スタックがすごいことになるが)
571:デフォルトの名無しさん
10/04/02 03:35:17
singletonにはstaticが…
572:デフォルトの名無しさん
10/04/02 03:44:57
>>565
for内にswitchでcase型:みたいな感じになるワケね
なるほど、言われてみれば単純な答えだった
しかし頭がOOPLなのでその単純な答えが出てこなかった
下段はむしろ書く前に思いついたんだけど
それじゃ、まんまOOPだから非OOP的には無いんだよなぁ…と思って
573:デフォルトの名無しさん
10/04/02 03:51:16
>>572
>非OOP的には無いんだよなぁ
いやCでも普通にありな手法じゃない？lisp系だったらクロージャでほいほいだし
574:デフォルトの名無しさん
10/04/02 04:54:11
まあCは関数ポインタ使えば、構造体がメソッドも含むオブジェクトに早変わりするからなｗ
そんな手法は大昔から使われてるし、そういう真似ができるからObjective-CはCで書かれてるわけで。
575:デフォルトの名無しさん
10/04/02 05:03:48
>>572
言われてみればじゃねぇだろ
馬鹿だから知らなかったんだろｗ
576:デフォルトの名無しさん
10/04/02 07:50:01
>>555
> 仮想メモリはハードウェアとマッチしてるだろ？何言ってんだ？
Amazon EC2が、どういう方法でサービスをホストしてるか知ったら発狂しそうだな。
> > 自律分散協調
> で、でたー。まさに人権屋的発想。こういうやつらこそOOPを駄目にしているのだろうな。
> いちおう教えといてあげるけど、お前、多分いわゆる中2病状態だよ。
> あとでわかるよ。
えー、実用技術としてGoogleのバックエンドでバリバリ動いてて、最近超注目されてるのに。
興味があるなら、BigTableとかMapReduceとかで検索してみるといい。
それに、何が人権なのかよく分からんが、むしろ単細胞生物のメタファの方が適切じゃね。
577:デフォルトの名無しさん
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
> すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
そりゃそうだ。
> これは、制御構造とデータ構造が本質的に別物だから。
そもそも何を「本質的」と言ってるのか説明が欲しいところだけど、それはともかくとして、
もしかして「データ＝主体」とか思ってるのかな。
それぞれが責務を持ち、外部に役務（サービス）を提供するのがオブジェクトだとすれば、
外部に対してそう見えていれば良いのであって、別に「データ＝主体」である必要はない。
そうであってもいいけどさ。
とりあえず、オブジェクト指向をちゃんと理解してから批判しようや。
君のやってるのはただの藁人形叩き。