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

OOP

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/09/10(金) 19:44:50
OOPをネタに罵ったり罵られたりするスレ

0175デフォルトの名無しさん2010/09/15(水) 21:46:41
そこが、今日の先生の技だよ
0176デフォルトの名無しさん2010/09/15(水) 23:53:38
>>173
お前の言う関係って具体的に何よ

>>174
ごめん結合度が低い、という言葉はあんまり適切じゃなかった。継承とかを例に出したのは完全に間違いだった。
もっと正しく言うと「オブジェクトの独立性が高すぎる」になるんだろうか。複数のクラスのインスタンスが関連し合う処理を書くときは
メッセージングより多重ディスパッチのほうが楽でしょ
0177デフォルトの名無しさん2010/09/15(水) 23:57:11
差分プログラミングは基本的に良くない
0178デフォルトの名無しさん2010/09/16(木) 00:29:11
>>177
禿同。
0179デフォルトの名無しさん2010/09/16(木) 01:17:21
オープンソース全般で行われていることですね！
0180デフォルトの名無しさん2010/09/16(木) 01:32:51
オープンソースは基本的に良くない
0181デフォルトの名無しさん2010/09/16(木) 01:34:57
このセンスｗ
0182デフォルトの名無しさん2010/09/16(木) 02:11:19
最近はソースはオープンでも、クローズドな展開が目立つな
昔からだけどな
0183デフォルトの名無しさん2010/09/16(木) 10:56:52
オープン過ぎるとコモンズの悲劇が起こる
クローズド過ぎるとアンチコモンズの悲劇が起きる
要はバランスの問題
0184デフォルトの名無しさん2010/09/16(木) 20:43:42
ちょっと質問させてくれ
ウィキペディアによると

>多重ディスパッチを採用する言語では、全ての引数がメソッド選択という観点では平等に扱われる。
>第一引数、第二引数、第三引数とマッチングを行うが、どれか特定の引数がその関数やメソッドを「所有」しているわけではない。

らしいんだけど、この場合関数やらメソッドやらはどこにあるの？
0185デフォルトの名無しさん2010/09/16(木) 20:44:46
グローバルとか（Javaのパッケージのような）名前空間とか
0186デフォルトの名無しさん2010/09/16(木) 20:50:01
>>185
グローバルとかに置いて煩雑にならないのかな
というか多重ディスパッチだけ抜き出すとあんまりOOっぽくないね
0187デフォルトの名無しさん2010/09/16(木) 21:32:16
名前空間ありゃ問題ないだろ
0188デフォルトの名無しさん2010/09/16(木) 22:00:30
>>184
CLOS 系だと総称関数に属しますね. いわゆる OO 言語とは全然、別物
まぁ、あっちは関数の扱いが全然異なってるから...
0189デフォルトの名無しさん2010/09/16(木) 22:14:40
マルチメソッドを実装したら、いわゆるOO言語でなくなる・・・
OOPって一体なんだったのだろう。
0190デフォルトの名無しさん2010/09/16(木) 22:22:28
OOA/OODの結果を効率よく実装するためのツール。
0191デフォルトの名無しさん2010/09/16(木) 22:25:45
・差分プログラミング
・多態
・カプセル化
クラスで何でもやろうとしたところが問題だったのだろう。

差分プログラミングは今となってはあまり重要ではない。
多態はなくてもいいけど、やるならマルチメソッドな方向でいいだろう。
カプセル化は今のクラスの仕組みでも良いかな。

ということで、継承が諸悪の根源ってことで良いだろう。
0192デフォルトの名無しさん2010/09/16(木) 22:28:50
その中だとむしろカプセル化が要らん
多態は使ってて良さが見えやすいから、
ダックタイピングやらパターンマッチやらテンプレートやらでいろんなアイディアが考え出されてる

カプセル化はなくても死なん
0193デフォルトの名無しさん2010/09/16(木) 22:38:28
OO脳としか。

無くても死なんカプセル化ぐらいにしか使えんのがOOPだと言うのに。
0194デフォルトの名無しさん2010/09/16(木) 22:38:31
>>189
おそらくハゲの人には, いいアイデアに思えたのでは???
各種 lisp 系も, 最初は (object <- message ...) みたいな
表記をしてたみたいですけど, まじめに考えると
「だめなんちゃう， (object <- message ...) は???」
に, なったみたいですね
まぁ,
変数は型を持たないけど, オブジェクトは型を持ちまくってる言語の
特性が， 特性が!!!
てなところでしょうか?
0195デフォルトの名無しさん2010/09/16(木) 22:42:39
日本語でおk
0196デフォルトの名無しさん2010/09/16(木) 22:44:54
> (せめてメッセージング指向とかで良かっただろうがよ)
これは同意ｗ

今OOPとして広まっている多くの言語で、OOPはメッセージ指向ではないし、
そうなっているのでメッセージ指向の言語をOOPというのにも違和感あるし
0197デフォルトの名無しさん2010/09/16(木) 22:45:13
lisp 系の, 歴史流れ書いてるだけなんで
> 日本語でおk
とか， きかれても…

0198デフォルトの名無しさん2010/09/16(木) 22:45:21
>>190を無視して処理系の詳細を語ることに拘泥するのがこのスレの限界。
0199デフォルトの名無しさん2010/09/16(木) 22:48:52
>>197
変な改行したり、感嘆符や句読点がおかしいのは気にならないのか？
0200デフォルトの名無しさん2010/09/16(木) 22:50:27
句点をコンマで書く人なら気にならないのでは？
0201デフォルトの名無しさん2010/09/16(木) 22:50:57
>>199
まぁ, そう言われりゃそうだなw
0202デフォルトの名無しさん2010/09/16(木) 22:56:26
というか、ケイ君の言ってるOOPを、彼の思想をもとに真面目に実装したら、

void messaging_hoge( A *a, B *b )
　　//ケイ君の言う「メッセージング」の正体は、実は私です。
　　//数学の世界では関数と呼ばれています。
　　//オブジェクト間の相互作用を担当します。
　　//当然マルチメソッドに対応しています。
　　//ケイ君いわく、一番重要な存在らしいです。光栄です。
{
　　a->set_value( b->get_value() );
　　　　//型内の整合性はアクセサで完全に保障されてるんだからね。
　　　　//だから安心して思う存分コミュニケーションしちゃっていいんだからね。
　　　　//継承？多態？そんなの知らないわよ。メッセージングでなんとかしてよね！
}

となると思うんだが。
なぜ彼はSmalltalkなんぞに肩入れしたのだろうな。
良い事言ってるのに、やってることがwww一番たちわるいな。
上記っぽい言語作ってりゃ、今頃ケイ君の評価もうなぎ上り、
皆も美味しい美味しい言いながら食べてくれてただろうに。
0203デフォルトの名無しさん2010/09/16(木) 23:02:08
>>202
> 　　//数学の世界では関数と呼ばれています。

ソース。
0204デフォルトの名無しさん2010/09/16(木) 23:11:52
>>202
そんなところに納めたら構文拡張できないじゃないか
あの言語は, 通常の言語の if 文ですら message だぞ
0205デフォルトの名無しさん2010/09/16(木) 23:12:49
おれはカプセル化のためにOOPL使ってる
0206デフォルトの名無しさん2010/09/16(木) 23:14:30
>>205
お前は正しい、と俺だけが保障してやる。
0207デフォルトの名無しさん2010/09/16(木) 23:23:39
結局、どう依存関係を整理できるのか、ってのが大事なわけで
継承なんかはポリモが絶対必要な場面以外では使うべきじゃないんだよな。
0208デフォルトの名無しさん2010/09/16(木) 23:30:00
んだ。ある記法が適切かどうかは、それによってどれだけ複雑さを縮減できるかによる。
文法で云々するのは多くの場合ナンセンス。
0209デフォルトの名無しさん2010/09/16(木) 23:44:03
構造化言語は文法で可読性やら安全性やら飛躍的に高めたろ
0210デフォルトの名無しさん2010/09/16(木) 23:47:27
>>209
特定の文法を強制することで、可読性や安全性が高まったことに価値があるのであって、
if { ... } else { ... }という記法そのものに意味があるわけじゃない。
0211デフォルトの名無しさん2010/09/16(木) 23:49:12
お前がなに言ってるか分からない
0212デフォルトの名無しさん2010/09/16(木) 23:49:38
継承に関しても同じだろ
継承の記法に意味があるわけじゃない
0213デフォルトの名無しさん2010/09/16(木) 23:55:07
>>210
そうか?
try {...} catch { ...} じゃないけど interrupy-disabled {...} みたいな
構文が自由に定義できるとバグが減ると思わないか?
まぁ, c++ あたりは scoped... みたいな物を導入して逃げることは可能だが
0214デフォルトの名無しさん2010/09/16(木) 23:55:47
また馬鹿がきた
0215デフォルトの名無しさん2010/09/17(金) 00:03:02
>>213
その記法が、可読性を改善する効用があるなら有用だろうね。
ただし、それが有用か否かは、そのコードが置かれているコンテクストに依存するだろう。
0216デフォルトの名無しさん2010/09/17(金) 00:13:03
あーまた論点がズレてきつつあるな。俺がいないと本当にだめだなぁ。
OOPのそれは文法云々関係なく、もっと根本でやらかしてる。
それは、データと制御は元来別物なのにも関わらず、単一のデータに制御を括り付けてしまったこと。
データの切れ目と制御の切れ目が一致するとは限らないだろ？
なのにデータの切れ目にあわせて制御をぶった切ったら、制御構造はめちゃくちゃハチャメチャになるだろ？

そもそも、制御はデータよりも偉い。
何故かというと、データに意味を持たせるのが制御だから。
どうやって制御がデータに意味を持たせるかというと、
他のデータとそのデータの相対的な関係を定義することで、意味を持たせる。
数学の「1」はメソッドを持たない。あるのは他の数との相対的な関係を定めた定理だけ。
1は2の半分だし、2は1の倍。1や2の実態なぞ無いのだよ、有るのは他者との相対的な関係の定義だけ→関数型言語にいらっしゃーい。
コンピュータの世界も割りと同じで、
整数値はただのビット列にすぎないんだけど、他との演算や、printfなんかの文字列への変換なんかを通して、
初めてただのビット列が整数の意味を持って、そして機能する。
自分自身で自分自身の意味を定義しても仕方ない。そんな行為はまるで青少年の主張と同レベル。
うつ病患者の自分探しの旅と変わりない。
0217デフォルトの名無しさん2010/09/17(金) 00:14:51
おまえはコテハンつけろ
0218デフォルトの名無しさん2010/09/17(金) 00:18:41
>>216
おまえは何を言っている?
*いわゆる OO 言語* にしか当てはまってないじゃん?
0219デフォルトの名無しさん2010/09/17(金) 00:20:18
メッセージ信者は今更定義論争すんなよ
0220デフォルトの名無しさん2010/09/17(金) 00:21:49
カプセル化がOOPの本質じゃないならおれはOOPいらね
0221デフォルトの名無しさん2010/09/17(金) 00:30:51
依存関係が整理できたら可読性は自然に上がる。

逆に、可読性が上がったからといって依存関係が整理されてるとは限らない。
0222デフォルトの名無しさん2010/09/17(金) 00:31:54
>>218
ケイ君流のメッセージング主体のオブジェクト指向の思想は、
関数型言語や手続き型言語の専売特許なんだからな。
関数型や手続き型は、初めっから、
関係、関数、制御、手続き、メッセージング、コミュニケーション、相対性、機能、
そういったものが物事の主体で設計のキモだと言っていたのに
(関数型、手続き型という名前からして明らかだろ？)、
そこへ、ケイ君が適当な再発明で殴りこんできたんだからな。OOPという変な名前でな。
0223デフォルトの名無しさん2010/09/17(金) 00:38:49
数百行の単位で可読性が高いだけの構文を
プログラム全体が整理されていると勘違いしてはいけない。
0224デフォルトの名無しさん2010/09/17(金) 00:39:56
中身ないレスばっか
0225デフォルトの名無しさん2010/09/17(金) 00:51:01
>>224
仲間入りおめ
0226デフォルトの名無しさん2010/09/17(金) 01:26:39
>>213
それやりすぎると、RubyとRailsは別言語みたいに比喩されるおそれあるんだが
0227デフォルトの名無しさん2010/09/17(金) 02:17:20
>>194
従来の文法と親和性の高いやり方を選んだだけじゃね
C++だって既にあった文法と親和性の高い方法を選んだだけなんだし
0228デフォルトの名無しさん2010/09/17(金) 02:18:07
>>226
個人的には実際に別言語と言いたい
0229デフォルトの名無しさん2010/09/17(金) 04:11:20
>>222
すまんがケイ以前に、そうだな、具体的には例えばSmalltalk-72が考案された1972年以前に、
メッセージングがLISPの専売特許であると主張した論文があれば出してみてくれまいか？（もちろん反語的にだが）
0230デフォルトの名無しさん2010/09/17(金) 06:37:12
微妙に異なる構造体とそれの操作関数が膨大になって、管理に困った、どうする？
→ オブジェクト指向
だと思ってるので、構造体の操作に関係ないところはオブジェクト指向的な設計は必ずしも必要ない。

>>216
> データの切れ目と制御の切れ目が一致するとは限らないだろ？
そうゆうとこは無理に OO しなくていいと思う。
0231デフォルトの名無しさん2010/09/17(金) 07:01:21
>>220
プロトタイプベースもOOPと言われてるあたり本質では無いんだろうな
0232デフォルトの名無しさん2010/09/17(金) 08:21:41
”オブジェクトがー”って書いてあれば大抵オブジェクト指向
オブジェクトは未定義であっても
0233デフォルトの名無しさん2010/09/17(金) 10:07:04
>>231
そういうふうに共通項を括りだしてOOの本質を語ろうとすると確実に填るよ。
ついでに言うと、実装面での共通機構のくくり出しによる分類もしかり。

「カプセル化のOO」、「メッセージングのOO」、「プロトタイプベースのOO」とそれをサポートするOOPは
それぞれメジャーでよく知られているし、互いに強い影響を与え合ってはいるけれど（特に実装面で）、
出自や特色は異なる別物だから、概念や運用法はそれぞれの違いを意識して学んだほうがいい。

だから、この場合、220がたまたまカプセル化（この場合抽象データ型を意味するのであれば―だけど。
情報隠蔽であればケイも重視している）が本質ではないOO、つまり実行時動的性を重視するOOである
後二者が嫌いってだけのレベルの話。
0234デフォルトの名無しさん2010/09/17(金) 11:41:48
プロトタイプベースは基本的に良くない
0235デフォルトの名無しさん2010/09/17(金) 11:43:34
OOPのキモはやっぱ多態だと思うけどな〜
インターフェース、抽象クラス、ダックタイピング、多重ディスパッチ…OOPLにはだいたいどれか入ってると思う
多態の要素が無いOOPLってあるの？
0236デフォルトの名無しさん2010/09/17(金) 12:02:37
OOPLじゃなくても多胎ぐらいできるぞ
裏を返せばどういうことか判るよな
0237デフォルトの名無しさん2010/09/17(金) 12:18:10
該当メソッド名があればコールできるようなＯＯＰＬのことかい？
あれは果たして多態とよぶのであろうか・・・。
0238デフォルトの名無しさん2010/09/17(金) 12:35:18
言語に何があるかでなく
何が言語にあって欲しいかいらないか語ってくれ
0239デフォルトの名無しさん2010/09/17(金) 16:58:18
>>237
それダックタイピングではなくて？
0240デフォルトの名無しさん2010/09/17(金) 21:57:40
いよいよ混沌としてきたな。
でもそれがOOPの本質。
ケイ君の頭のバグが具現化したものが元祖OOP。
バグがバグを呼んで二次三次四次災害と永遠にループ。
自然治癒できないから、いっそ切り取ろう。。
OOPのことは忘れよう。皆で一斉に。
0241デフォルトの名無しさん2010/09/17(金) 22:03:39
お前ら本当はオブジェクト指向で、プログラム作ったことないだろう。
作ってるつもりでも、それが本当にオブジェクト指向だと断言出来るか？
口だけの技術者が作ったプログラムを見せて、オブジェクト指向じゃないのに
偉そうにオブジェクト指向はこう作るんだとか言っている奴が多いからなｗ
0242デフォルトの名無しさん2010/09/17(金) 22:06:23
お
作
口
偉

いまいち。
0243デフォルトの名無しさん2010/09/17(金) 23:17:44
OOPっていったら多態だけど、
その仕組みに付随して色々便利機能がついてるから、どれが本質かわかんなくなりガチなんだよな
0244デフォルトの名無しさん2010/09/17(金) 23:30:20
なんでお前ら、そこまで処理系の機能でOO語ることに執着するん？
0245デフォルトの名無しさん2010/09/17(金) 23:55:34
じゃあこの世に存在しない、理想の OOP について、どうぞ。
0246デフォルトの名無しさん2010/09/18(土) 00:05:33
分析・設計の観点を無視してOOPを語っても無意味だろ。
俺は「OO」と言ってるのに、「OOP」に変換されてる辺りが象徴的。
0247デフォルトの名無しさん2010/09/18(土) 00:08:32
OOPで出来る事を無視して設計語ってもしょうがないだろ
0248デフォルトの名無しさん2010/09/18(土) 00:22:00
チューリング完全な言語なら、どんなプログラムだって「出来る」。

分析・設計を、どれだけ素直にコードに落とし「やすい」かが重要なんだろ。
目的を無視して道具を弄んだって袋小路に陥るに決まってる。
0249デフォルトの名無しさん2010/09/18(土) 00:22:37
OOAとかOODとかは派生物だから、OOと言えば普通はOOP
0250デフォルトの名無しさん2010/09/18(土) 00:24:59
>>249
30年前ならその言い分は正しかったかもしれないがな。
0251デフォルトの名無しさん2010/09/18(土) 00:25:50
分析や設計もコードでやれよ。
classと空のメソッド作ればいいだけじゃん。
0252デフォルトの名無しさん2010/09/18(土) 00:27:41
>>246
ごめん、 oriented て形容詞だから、その後に何もないのが気になって。
0253デフォルトの名無しさん2010/09/18(土) 00:28:00
>>251
そこでTDD等の開発手法の話を持ち出すならいいと思うよ。
0254デフォルトの名無しさん2010/09/18(土) 00:30:08
テストはもっと見えてからじゃないと用意できない
0255デフォルトの名無しさん2010/09/18(土) 08:26:26
論議も良いが、実益の話が出来ない時点で議論が不毛と感じる。
しかも継承を否定する意見も多い、継承はオブジェクト指向なかで
実利を一番説明しやすい部分なのに。
0256デフォルトの名無しさん2010/09/18(土) 09:54:31
継承は、安易に使用すると弊害の方が大きいからな。
0257デフォルトの名無しさん2010/09/18(土) 09:59:29
実利強調するなら説明してから言えよ
0258デフォルトの名無しさん2010/09/18(土) 10:29:59
>>254
ユースケースで仕様を固めておけば、実装始める前にテストケースの骨格(メソッド名が決まってないので、やりたいことをコメントで記述)ぐらいはつくれるんじゃないかな
0259デフォルトの名無しさん2010/09/18(土) 11:15:37
やっぱりOOP使うならUMLは理解できるようにしたほうがいいのかな

0260デフォルトの名無しさん2010/09/18(土) 11:20:49
UMLこそ罠じゃね？
あんな静的な図が何の役にたつのだろうか。
0261デフォルトの名無しさん2010/09/18(土) 11:43:27
理解できることに越したことはない。
UML理解≠OO理解だが。
0262デフォルトの名無しさん2010/09/18(土) 11:55:42
>>256
弊害が出るなら継承を適用しなければ良いと思うが。
ところで、弊害とは？設計不良による継承の弊害じゃなくて？
設計から来る継承の弊害じゃないなら、継承自身の弊害を具体的に聞きたい。

>>257
継承の長所は既存ソースに手を加えないこと。
構造化時代の問題として、「実績のあるプログラムを
いかに既存部分に影響なく機能追加・削除出来るか」があった。
その答えの一つが継承だ。
0263デフォルトの名無しさん2010/09/18(土) 12:58:06
そして地層のように継承されて誰もメンテしないカオスの塊になるわけだ
「そのソースは俺の担当じゃない」「管理してた人は10年前に辞めました」
0264デフォルトの名無しさん2010/09/18(土) 12:59:53
protected 変数があって、派生クラスでそれを使う以上、
クラス階層の成長は、それに足をひっぱられるわな。
0265デフォルトの名無しさん2010/09/18(土) 13:11:37
「正しく使えば」が前提ならgotoもグローバル変数も人畜無害になっちゃうよ
0266デフォルトの名無しさん2010/09/18(土) 14:06:09
>>262
っ【リスコフ置換原則】
0267デフォルトの名無しさん2010/09/18(土) 14:37:20
>>263
ソースは見なくていい、機能させ分かっていれば。
標準ライブラリのクラスを継承する時に中身を見ないと継承できないか？

>>264
それは内部の変数の設定でも行儀良くGetter・Setterを使えば済むこと。

>>265
別に継承を「正しく使えば」とは書いていない、どんな使い方でも
既存部分に影響を与えない利点はある。
0268デフォルトの名無しさん2010/09/18(土) 14:42:53
>>267
少なくとも、近年では差分プログラミングを目的とした継承(IS-A)より、
インタフェースを介したオブジェクト間での委譲(HAS-A)がより良いとされているよ。
0269デフォルトの名無しさん2010/09/18(土) 15:07:47
>ソースは見なくていい、機能させ分かっていれば。

バグ修正するときどうすんだよ
0270デフォルトの名無しさん2010/09/18(土) 15:18:07
継承だと中身を見るまではしなくて良いが、ある程度はクラス全体を理解しておきたい
has-aなら利用側と全く変わらない理解度でおkだし、誤った継承もしにくいよ
0271デフォルトの名無しさん2010/09/18(土) 15:19:06
テストがないの汚物(レガシーコード)は消毒(リファクタリング)ﾀﾞｧ~!!

まあ、間違った挙動に依存しているコードがあるかもしれないから、
おいそれとなおさねーよがMSの流儀ですね。
0272デフォルトの名無しさん2010/09/18(土) 15:42:43
増築こそ長生きの秘訣
ただし被せたらうまくいかない
つまり継承は×
0273デフォルトの名無しさん2010/09/18(土) 16:02:39
>>268
俺の知識では、それは多態の話だとおもうが。
それに、インタフェースはクラス全体で見ると差分プログラムと言えなくもないが
メソッドレベルだと、新規プログラミングで差分プログラミングじゃない。

>>269
既存ソースがなくてもバグは取れる。
そもそも前提条件が違う、業務運用を長年行なって品質の確かな
既存クラスに影響を与えず、機能追加・削除出来るから継承を使う。

>>270,271
同意。
0274デフォルトの名無しさん2010/09/18(土) 16:49:55
なんか次は、

メソッド全体で見ると差分プログラムと言えなくもないが
行レベルだと、新規プログラミングで差分プログラミングじゃない。

とか言いそうな勢いだな。
■ このスレッドは過去ログ倉庫に格納されています