結局OOpが役に立たないのはなぜ?
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/04/14(水) 01:14:080357デフォルトの名無しさん
2010/05/01(土) 20:40:25関数だけでいいだろ
0358デフォルトの名無しさん
2010/05/01(土) 20:45:14オブジェクトが持つべきものは「責務」であって「状態」ではないからな。
だから、immutableなオブジェクトというのも当然アリ。
0359デフォルトの名無しさん
2010/05/01(土) 20:46:43>少なくとも一般的な意味でのOOとは別もんだろ
なんだ、この逃げ方は、なにが「一般的な意味でのOO」ってなんだｗ
お前が一般的と言っているのは、浅いお前の知識で思っているオブジェクト指向だろｗ
0360デフォルトの名無しさん
2010/05/01(土) 20:47:38immutableなオブジェクトでも、初期パラメータとしての「データ」はもちろんある。
0361デフォルトの名無しさん
2010/05/01(土) 20:55:50荒しだから、無視でいいだろう。
こいつのおかげで、スレが荒れている。
しかし、なんで荒しをやるんだ？
実生活でも、会社や周りから嫌われているんだろうな。
0362デフォルトの名無しさん
2010/05/01(土) 20:58:25本当にそうだよ、別のところでやればいいのに。
0363デフォルトの名無しさん
2010/05/01(土) 21:06:52それはその通りだね
immutableなオブジェクトしかないような「オブジェクト指向言語」は
俺は知らないが
>>361
まともな反論ができなければ荒らし認定か
つまらん奴だな
0364デフォルトの名無しさん
2010/05/01(土) 21:10:42いやお前、あの文脈でErlangがアクターモデルだからどうたらとか言われても
何の反論にもなってないんだが
その先の主張は何よ
ErlangはOOだとでもいいたいのか？
俺は定義の曖昧な基盤の上での不毛な論争は避けたいから、「一般的な意味での」
と断っただけだ
「一般的な意味では」Erlangは「並列計算指向の」「関数型言語」であり
「オブジェクト指向言語」ではないし
「一般的な意味では」オブジェクト指向言語はデータを中に持ちたがるし
副作用を多用する
0365デフォルトの名無しさん
2010/05/01(土) 21:16:070366デフォルトの名無しさん
2010/05/01(土) 21:19:080367デフォルトの名無しさん
2010/05/01(土) 21:21:27>>351がアホなツッコミを入れたから話が伸びただけで
もっと言うなら>>347の面白主張がなければ話そのものが始まらなかった
0368デフォルトの名無しさん
2010/05/01(土) 22:02:50関数は機能ひとつだけだろ。
オブジェクトは機能のセットとして「責務」を持つようにでｋる。
0369デフォルトの名無しさん
2010/05/01(土) 22:07:42もっと素直になれ、データを持ちたいからオブジェクトにしたいんだろうよ
単に関数をどこかにひとまとめにしたいだけなら、モジュールでいい
0370デフォルトの名無しさん
2010/05/01(土) 22:10:09> immutableなオブジェクトしかないような「オブジェクト指向言語」
Scalaは、言語仕様としてimmutableなオブジェクトをサポートしている。
副作用があるものも当然書けるがね。
0371デフォルトの名無しさん
2010/05/01(土) 22:15:52俺は「しかない」と言ってるんだから、反論になってないのは分かってるんだろうし、
そのつもりもないんだろうね
Scalaははねえ
下層のJava部分が言うまでもなく全部手続き型で副作用だらけ
勿論自分も副作用は普通にサポート
Javaの参照型オブジェクトには全てnullを突っ込めるし
nominal subtypingによる実行時ポリモーフィズムのお陰で
型安全性がJava同様中途半端で、型推論も半端
見方によっては何でも出来て超強力だが、見方によっては実に半端な
妥協的・折衷的言語だな
0372デフォルトの名無しさん
2010/05/01(土) 22:17:14素直になれって言われても、データを持ちたいからという「だけ」じゃないだろ。
関数「だけ」でいいだろ、って言い出したのはそっちだよな？
まあもともとオブジェクト指向なんて鵺のようなものなんだし、どっちでもいいけど。
0373デフォルトの名無しさん
2010/05/01(土) 22:18:19純粋なものがすなわち使いやすいわけではないからねぇ。
言語仕様のみでサポートできることにも限界はあるし。
0374デフォルトの名無しさん
2010/05/01(土) 22:18:44ああそりゃすまんかったｗ
個人的な見解だが、一部のクラスベースOO言語でクラスをただのnamespaceや
moduleとして利用している場合があるが、あれは馬鹿げた「乱用」だと思ってる
なぜそうまでしてクラスに書かせるのか
0375デフォルトの名無しさん
2010/05/01(土) 22:22:08それ「だけ」のためにクラスを利用してる言語だったら確かに意味がないけど、
そういうふう「にも」使えるというだけなら、別に実用上の問題はないんじゃないの。
0376デフォルトの名無しさん
2010/05/01(土) 22:25:01まあ、そう言ってしまえばそうなんだが、気分としては気持ち悪いし、
美しいとも思えないね
JavaやC#ではそういう用法はclassの第一級の使い方ではないから
本来不要なclassを記述した上で、それぞれの関数にはいちいちstaticと
書かなければならないし
0377デフォルトの名無しさん
2010/05/01(土) 22:34:04コードのパッケージングの仕組みと深く関わってる場合も多いわけだし、
そう簡単にそうだとは言い切れない部分もあるんでないかな。
0378デフォルトの名無しさん
2010/05/01(土) 22:34:420379デフォルトの名無しさん
2010/05/01(土) 22:36:21>>350
>状態があれば排他や状態のレプリケーションのコストが発生する
フィールドが並立処理の為に導入されたのもだが知らんのか？
レプリケーションのコストは、発生しない。データを冗長に持たないのがオブジェクト指向だ。
>>352
>アクターモデルは「メッセージパッシング」を用いはするが
>少なくとも一般的な意味でのOOとは別もんだろ
アクターモデルの概念は、オブジェクト指向言語に影響されているのも知らんのか？
もともとオブジェクト指向言語は、並立処理言語だったと知っているか？
0380デフォルトの名無しさん
2010/05/01(土) 22:39:16ん？
パッケージングの仕組みがそうだから言語デザインが汚くても従容と
受け入れてねってこと？ 良く分からん
同じCLI言語のVBにはmoduleあるじゃん
C#にはないけど
別にmoduleは、内部的には全てのメソッドがstaticなclassの構文糖でも
構わないんだよ
実際にVBのmoduleはそうだし
0381デフォルトの名無しさん
2010/05/01(土) 22:44:39> レプリケーションのコストは、発生しない。
> データを冗長に持たないのがオブジェクト指向だ。
あれは確かに書き方が悪かったかもしらんが
どっちも常に発生するって意味じゃないんだよ
状態を複製しないのなら、単一オブジェクトの状態を排他しつつ利用することに
なるから、並列計算においてはかなりのボトルネックになることが普通に想定
されるね
フィールド別れてたって、単にロックの粒度を細かくできるだけで
排他が必要なのは変わらん
wait free lockのような詳細はここでは問題にしないけど
> アクターモデルの概念は、オブジェクト指向言語に影響されているのも知らんのか？
勿論知っている、メッセージパッシング自体がそうだしね
ただし、出来上がっているErlangは少なくとも一般的な意味でのOO言語とは別物だし
OO言語とは呼ばれないね
0382デフォルトの名無しさん
2010/05/01(土) 22:48:34＞Erlangは状態をもつアクターモデルで
そりゃ、アクターの実行状態を「Erlang VMは」管理しているだろうね
それで？
プログラミング言語の文脈では、参照透明な、副作用の無い関数を「状態を持つ」
とは言わないよ
「普通は」ね
0383デフォルトの名無しさん
2010/05/01(土) 23:02:22責務の割り当が難しいことがあるんだよ。そういう場合はそれが問題の中心になってしまう。
Photoshopとかの画像編集ソフト使ったことある？
色彩やコントラストのコントロールなど機能が満載でいろんなことが出来る。
オブジェクト->色を変換
オブジェクト->明るさ（トーンカーブ）を調整
みたいな感じにね。
でも写真に写ってるモデルの髪の色を明るくしようとしたら、髪の毛だけを
選択範囲（オブジェクト ）として抽出しなければならないんだ。
そんなのどうやってやる？
下手にやると背景から浮いてしまって不自然なフォトレタッチになってしまうから
範囲選択それ自体がひとつのテクニックとして問題になってくる。
責務の抽出と割り当が難しい問題領域があるんだよ。
0384デフォルトの名無しさん
2010/05/01(土) 23:21:18おわり。
0385デフォルトの名無しさん
2010/05/01(土) 23:25:22それが最適解かは、そのソフトが目指すところによると思うけど。
0386デフォルトの名無しさん
2010/05/01(土) 23:36:44適当だけど
登場人物は
ImageOp、ImageSelection、Image
こんな感じでないの
イメージエディタの編集操作って基本的にイメージのセレクションに対して
作用するでしょ
セレクションを扱うこと自体はGUIでの基本的な問題だと思うけど
テキストエディタだってそうだし
0387デフォルトの名無しさん
2010/05/01(土) 23:40:42イメージのセレクションそれ自体はユーザに任されていて、エディタの機能は
「セレクト後」のオブジェクトに作用するだけだよね。
0388デフォルトの名無しさん
2010/05/01(土) 23:44:55>状態を複製しないのなら、単一オブジェクトの状態を排他しつつ利用することに
>なるから、並列計算においてはかなりのボトルネックになることが普通に想定
>されるね
また関数型くんは、わけの分からないことを書いている。
何の排他が必要なんだ？ 排他をしないでいいようにメッセージパッシングで作るんだろう。
それとも、メッセージ・キューの排他を言っているのか？
メッセージ・キューはOSやハードの問題で言語の問題じゃない。
いいかオブジェクト指向言語は、並行処理のために
昔からコルーチンやマルチスレッドが実装されている。
オブジェクト指向言語だからといってボトルネックになることはない。
0389デフォルトの名無しさん
2010/05/01(土) 23:56:56> 何の排他が必要なんだ？ 排他をしないでいいように
> メッセージパッシングで作るんだろう。
あのな
「メッセージパッシング」でゴマカすなよ
コードが参照透明で、副作用を持つか持たないかだけが問題だ
副作用を持つコードや可変な状態に、複数のスレッドからアクセスしたければ
必ず排他が必要だ
純粋に参照透明な純粋なオブジェクト指向言語なんて俺は知らないんだが、
知ってるんなら、教えてくれないか？
> いいかオブジェクト指向言語は、並行処理のために
> 昔からコルーチンやマルチスレッドが実装されている。
は？
マルチスレッドに対応しているからといって排他が不要だということにはならない
むしろその逆で、手続き的言語のマルチスレッドプログラミングにおいてこそ排他が
多用されるんだろうが
一方、コルーチンだけでスレッドやプロセスを用いないなら、排他は不要だが、
元の問題である、マルチコアの並列計算とは特に関係の無い問題になるんだが
0390デフォルトの名無しさん
2010/05/01(土) 23:58:51高みにいるつもりで人を「関数型くん」呼ばわりで馬鹿にした気になってんだな…
ご苦労なこった
0391デフォルトの名無しさん
2010/05/02(日) 00:15:46>作用を持つコードや可変な状態に、複数のスレッドからアクセスしたければ
>必ず排他が必要だ
単一のスレッドのスレッドからしかアクセスしなければ排他は必要ありません。
> 何の排他が必要なんだ？ 排他をしないでいいように
> メッセージパッシングで作るんだろう。
単一のスレッドのスレッドからしかアクセスしないための具体的な方法がこれです。
各スレッドが直接アクセスするかわりに単一のアクセス担当スレッドと
メッセージをやりとりすれば各スレッドに排他処理をばらまく必要はありません。
0392デフォルトの名無しさん
2010/05/02(日) 00:20:22ああすまん、いいたいことは分かった
比喩的な（形骸化した）「メッセージパッシング」じゃなくて
メールスロットを用いたメッセージパッシングのことだったのね
確かにそこでキューイングされているなら、排他は要らないし
全てのメッセージパッシングをそうやって実装しているOO言語であれば、
確かに排他処理をばらまく必要は無いね
すまんかった
0393デフォルトの名無しさん
2010/05/02(日) 00:32:30メッセージパッシングでやりとりしてるとしても、オブジェクト自身が
状態持ってると、最悪の場合、Webアプリケーションで言うDBサーバのような
状態になる
容易に多重化できず、レプリケーションするとしてもコストがかかり、
クリティカルかつボトルネックってことだ
一方で、重要な状態を持たないサーバまたはアプリケーションは、多重化しやすい
それは、プログラムでも同じことだ
まあ、最低限タイムクリティカルなコードが全部状態フリーで容易に
並列化可能なコードであれば実用上問題はないわけだけどな
0394デフォルトの名無しさん
2010/05/02(日) 10:59:48よって来やすいよね。ただの手を動かさないニートとか
決められた事を守れない他人不在の自己中とか
0395デフォルトの名無しさん
2010/05/02(日) 11:46:090396デフォルトの名無しさん
2010/05/02(日) 15:06:13ちゃんと文章読む癖をつけた方がいいと思う。
0397デフォルトの名無しさん
2010/05/02(日) 17:20:370398デフォルトの名無しさん
2010/05/02(日) 21:05:51そもそも対立概念（ライバル）が何かすらわからん。
0399デフォルトの名無しさん
2010/05/02(日) 21:45:030400デフォルトの名無しさん
2010/05/02(日) 22:45:410401デフォルトの名無しさん
2010/05/03(月) 13:38:28そこなんだよね、オブジェクト指向の定義自体が曖昧。
しいえて言うならば、
> http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91
> オブジェクト指向は「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。
どういった印象を受けますかね。
どことなく左なニュアンスで、俺はこれが嫌いなんだよね。
0402デフォルトの名無しさん
2010/05/03(月) 18:33:05ところで「左」って？
0403デフォルトの名無しさん
2010/05/03(月) 18:40:32そもそも大半のパラダイムに「対立概念」なんて無いハズなんだけどな。
よく対比される手続き型と関数型だって、じゃあ論理型は？ってなるし。
0404デフォルトの名無しさん
2010/05/03(月) 18:42:51対象って言ってんだから、対象だろうよ。
お前みたいなのが居るからOOPは嫌になる。
0405デフォルトの名無しさん
2010/05/03(月) 18:47:13手続き型と関数型は、副作用の有無で明確に色分けされてる。
では、OOPとそうでないものは、何を基準に色分けすればよい？
0406デフォルトの名無しさん
2010/05/03(月) 19:23:200407デフォルトの名無しさん
2010/05/03(月) 19:29:40もっとも副作用のない手続き型言語なんて俺は見たことがないが
0408デフォルトの名無しさん
2010/05/03(月) 20:28:08「述語（機能）よりもその対象を中心に据える」
⇔「対象がどういう機能を提供するかを中心に整理する」と考えるなら、
⇔「対象の責務から持つべき機能を逆算する」でいいと思うんだが。
昔はともかく、今の考え方でいえばオブジェクト指向において「責務」はキーワードだろう。
0409デフォルトの名無しさん
2010/05/03(月) 20:35:18言語パラダイムの説明としては非具体的過ぎて全然しっくり来ない
0410デフォルトの名無しさん
2010/05/03(月) 20:50:28言語パラダイムとしては、それこそ色々なアプローチが百家争鳴なわけで、
そこで定義するのは無理じゃないかな、正直な話。
それよか、デザイン手法の理解から入って、
その実装に役立つ手法を考えていく方が生産的だと思うな。
0411デフォルトの名無しさん
2010/05/03(月) 20:56:46「委譲より継承」「インタフェース」あたりがキーワードだろうな。
例えば、俺がさっき本屋で買った「インターフェイス指向設計」って本なんかは、
ぱらぱらとめくってみた感じ、その辺のエッセンスがまとまってそうな感じだった。
わりと「分かってる人向け」に書かれてるらしいのでお勧めできるかは微妙だが。
0412411
2010/05/03(月) 20:59:02× 「委譲より継承」
○ 「継承より委譲」
0413デフォルトの名無しさん
2010/05/03(月) 21:06:57それでは狭すぎる
非クラスベース、ダックタイピング、structual subtypingなOOが
ずっぽり抜けてるだろ
0414デフォルトの名無しさん
2010/05/03(月) 21:10:54データと、データの操作をひとまとめにした『オブジェクト』を中心に据えた言語
では駄目なのか
0415デフォルトの名無しさん
2010/05/03(月) 21:21:42という話が出てくるから、結局「オブジェクト指向の定義」として語るには微妙だよね、と。
なら、デザインレベルの話を中心にして、言語処理系ごとのテクニックを共有するに留めた方がよかないか。
>>414
それだと、例えば抽象データ型（もっと言えばインタフェース）が説明できない。
0416デフォルトの名無しさん
2010/05/03(月) 21:26:51> それだと、例えば抽象データ型（もっと言えばインタフェース）が説明できない。
具象のないインタフェース「だけ」で成立するオブジェクト指向言語は存在しないし
インタフェースのないオブジェクト指向言語なら沢山ある
つまり、それは本質ではないのでは？
インタフェースの背後にはかならず具体的なオブジェクトが存在するわけだろ
オブジェクトとオブジェクトが語り合う上で「インタフェースを経由する」
「メッセージパッシングを行う」といった手法は、重要ではあるにせよ
言語毎の詳細に過ぎないと思うが
0417デフォルトの名無しさん
2010/05/03(月) 21:48:07君の言うとおり、「オブジェクト指向」を名乗る言語処理系は色々あるし、
インタフェース的な要素をサポートしてない言語はたくさんあるわけだが、
少なくとも、GoF本に代表される最近主流の解釈でいけば、
「インタフェース」の概念は重要だろう。具象より抽象。
で、なぜ抽象中心で考えるべきか、という話には色々な事情があるわけだが、
分かりやすいところで言えば、アジャイル開発とかテスト駆動開発なんかとの
絡みが大きいんだと思う。単体テストのしやすさ、とかね。
0418デフォルトの名無しさん
2010/05/03(月) 21:52:38コードとデータを「まとめる」だけなら、CでもアセンブリでもMLでも可能なんだし
（「まとめる」の定義次第ではあるが）
0419デフォルトの名無しさん
2010/05/03(月) 21:54:56http://www.amazon.co.jp/dp/4798111112
本当は、議論の前にこういう原典的な本を読んだ方がいいんだろうけどな。
ただ、今日本屋で手に取ってみたが、ここまで分厚い（約1000ページ）と威圧感が凄いし、何より値段が。。
んで、手ごろな本というとなかなか無いのが悩ましい。
0420デフォルトの名無しさん
2010/05/03(月) 21:55:40オブジェクト指向があやふやになるのも仕方がないわな
0421デフォルトの名無しさん
2010/05/03(月) 21:56:16いやだから、GoF本の「インタフェースと実装の分離」は
C++とその一族みたいなクラス／継承ベースの静的型言語特有の問題だろ
それに、そうした言語においても、
インタフェースの背後には「必ず」具象オブジェクトがある「必ず」だ
あくまでその特有の言語において、具象を抽象化するプロトコルに過ぎん
アジャイル云々はそれこそどうでもいいだろ
OOの定義／共通項を抽象化しようとしてるんだから、反論するのなら
>>414に沿わない言語の例でも上げてみたらどうなんだ
インタフェースは何の反例にもなっていない、それらの言語にも
具体的なオブジェクトが「必ず」存在するんだから
0422デフォルトの名無しさん
2010/05/03(月) 21:59:28「オブジェクト指向でコードを書きやすい言語」というくらいかもね。
特に近年提唱されている実践とか開発手法を考慮すると、言語処理系だけで話は完結しないし。
0423デフォルトの名無しさん
2010/05/03(月) 22:02:14「まとめる」のは、単にオブジェクト指向的な設計手法
それをサポートする具体的な何か（たとえばクラス）を備えている言語が
オブジェクト指向言語、だろ
0424デフォルトの名無しさん
2010/05/03(月) 22:09:28例えば、DIコンテナを使って具象にMockを差し込むことで単体テストを容易にする、
みたいなことをやるのは、あくまでそのオブジェクトが果たす「責務」をテストしたいわけで、
具象自体は責務をエミュレートするMockと常に入れ替え可能なわけだ、この場合。
>>414も一面では正解だが、近年の実践を踏まえると誤解を招く可能性が高いと思う。
0425デフォルトの名無しさん
2010/05/03(月) 22:19:46言っている意味は分かるよ
書いている気分や設計としては、インタフェースを相手にしているのであって
具象、ましてやデータのことは考えていないと言いたい訳だろ
が、俺の考えでは、それはOOの「上の」設計の話だな
その例でも、結局（実行時に）仕事をするのは全て具象オブジェクトとその間の
やりとりなわけで、それがOOの共通項であり本質だと思うが
具象オブジェクトを隠蔽すべし、みたいなのは、あくまでOOの「上」での
良き設計の方法論に過ぎんと思う
例えて言えば、あんたのは「手続き型言語」と「構造化手法」をごっちゃに語っている
ようなものだ
0426デフォルトの名無しさん
2010/05/03(月) 22:32:55そっちの言いたいことも分かるが、そういう「下」の話を含めだすと、
議論の共通前提を作るという意味では、あまりメリットがない気がするんだよな。
アセンブラの時代ならともかく、今は人間の良き設計を良きコードに落とせてこそ
良き道具（＝言語処理系）だと思うし、「データと操作を一括りにできること」という
わりとアバウトな分類で色んな言語を括ることにどんなメリットがあるのかな、と。
0427デフォルトの名無しさん
2010/05/03(月) 22:37:49いやだから、インタフェースが全く「共通項」にはならないことは示したよね？
それどころか、手続き型言語における「構造化手法」より重要度が低く、弱いよ
JavaScript, Ruby, Pythonのような言語にはインタフェースはないし、
必要ですらないんだから
0428デフォルトの名無しさん
2010/05/03(月) 22:50:00それはイエス。
そもそも「データと操作を一括りにできること」という定義の提唱に対する反論であって、
それ自体に反対してるわけではないよ。俺の立場は、さっきも言ったように、
「オブジェクト指向は設計レベルを中心に論じるべき」という立場だからね。
0429デフォルトの名無しさん
2010/05/03(月) 22:54:10なるほど、OOはプログラミングパラダイムとしては定義不可、という立場？
最終的にその結論でも別にいいけど、俺にはインタフェースは反論の根拠としては
失礼ながら薄弱なように思えたので、もっと強烈なのがないのかと
こうして粘っているわけだｗ
0430デフォルトの名無しさん
2010/05/03(月) 23:00:09立場というか、お察しの通り動的型方面には弱いので正直分からんというか。
ただ、OOP or OOPLとして一貫性のある「オブジェクト指向」の説得的な定義は
今のところ見たことがないね。
「メッセージ指向か抽象データ型指向か」という話は言語談義としては面白いけど、
あんまし本質的だと思えない。
0431デフォルトの名無しさん
2010/05/04(火) 02:15:56> http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91
> オブジェクト指向は「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。
このニュアンスに従うと、
述語(対象1, 対象2, 対象3); //func(obj1, obj2, obj3);
こういう処理があったとして、
非OOPでは、述語(つまり関数)を中心に据えて指向し、
OOPでは、対象(つまり引数)を中心に据えて指向する、
ってことだろ。
ただ、単一ディスパッチのOOPの場合、
中心に据えるべき対象が定まらなくて困る場合があるよ、と。
0432デフォルトの名無しさん
2010/05/04(火) 02:26:36日本語でおｋ
0433デフォルトの名無しさん
2010/05/04(火) 02:28:51目的語と述語だと、述語の方が重要だと。
それは、述語が目的語と目的語の関係を定義するものだから。
目的語と目的語の関係を定義して、機能が生まれる。
functionは、関係の定義「関数」であり、同時に機能とも訳される。
その思想は大事にしたいんだよね。
0434デフォルトの名無しさん
2010/05/04(火) 02:39:38／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼ 「その思想は大事にしたいんだよね」
／ ⌒（__人__）⌒ ＼
| |r┬-| |
＼ `ー’´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一””””~~｀`’ー?､ -一”””’ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
0435デフォルトの名無しさん
2010/05/04(火) 12:11:10Wikipedia を盲信してるんだな。
0436デフォルトの名無しさん
2010/05/04(火) 12:15:21Object-oriented programming (OOP) is a programming paradigm that uses "objects" -- data structures consisting of datafields and methods together with their interactions -- to design applications and computer programs.
とはっきり書いてある
日本語版は駄目駄目だな
0437デフォルトの名無しさん
2010/05/04(火) 12:51:52英語版は別れてないのに
0438デフォルトの名無しさん
2010/05/04(火) 13:05:110439デフォルトの名無しさん
2010/05/05(水) 14:50:19# 「でも、おまえ、制御系書けないだろ」って奴に限って、そのノリが強いのが痛い
0440デフォルトの名無しさん
2010/05/05(水) 15:30:430441デフォルトの名無しさん
2010/05/05(水) 16:47:020442デフォルトの名無しさん
2010/05/05(水) 16:55:09新規にコーディングする場合、開放/閉鎖原則や単一責任原則など、
将来の再利用を考えてコーディングする。
もちろん、構造化で作るよりコストがかかるが、再利用が有効に働くなら、
初回にコストを掛けるのも悪くない。
しかし、改造でデータ・フィールドの持ち方の構造が（リストからツリーとか）
変るような変更なら、再利用を有効に機能しない。
そもそも、改造自体がない場合も多い。
技術者は預言者や占い師じゃない。将来どんな改造があるかなんて
予想出来ない。そんな不確定な再利用にコストを掛けるんじゃなく、
新規の仕様や改造の仕様を、その都度構造化でやったほうが
トータル的に見てもコストは低いんじゃないのか？
0443デフォルトの名無しさん
2010/05/05(水) 17:00:12MFCは失敗例っつーかなんというかゴミ
0444デフォルトの名無しさん
2010/05/05(水) 17:01:19ドカタはOOpの勉強なんかせんでええよ
0445デフォルトの名無しさん
2010/05/05(水) 17:07:10デザパタでは再利用性を向上するために短期的視点では面倒なことをやるわけだが
それも「クラス・継承ベースの多態・静的型のOOPL」という限定付の
世界での話に過ぎん
デザパタが対象としているタイプのOOPLの始祖とも言えるC++だが、STL以後の
標準ライブラリやboostのようなライブラリにおいて、
むしろテンプレートによるコンパイル時多態／ダックタイピングや
関数型に近い手法を多用するスタイルが主流になっていることに注意しよう
そのほうがずっと強力で汎用性が高いことをSTLが証明してしまった
からだ
ま、言語としてのC++自体を褒めはしないが、マルチパラダイムで組める
言語のほうが何にせよ気楽だね
0446デフォルトの名無しさん
2010/05/05(水) 17:21:18そういうメリットもある、という程度。
0447デフォルトの名無しさん
2010/05/05(水) 17:28:08OOの一番のメリットってなに？
0448デフォルトの名無しさん
2010/05/05(水) 17:31:0520年近く前の、テンプレートもないC++の草創期に作られたライブラリを今さらとりあげてゴミっていわれてもな。
0449デフォルトの名無しさん
2010/05/05(水) 17:40:04高凝集かつ疎結合なシステムを構築しやすい。
0450デフォルトの名無しさん
2010/05/05(水) 17:41:41C++のテンプレートは、C++言語の大きな欠点とされているだろ。
0451デフォルトの名無しさん
2010/05/05(水) 17:49:010452デフォルトの名無しさん
2010/05/05(水) 17:54:46それはOOだけじゃない。
0453デフォルトの名無しさん
2010/05/05(水) 17:56:34別にOOだけのウリだとは一言も言っていない。
0454デフォルトの名無しさん
2010/05/05(水) 18:15:15それだと、OOの一番のメリットっと言わないだろう。 普通は。
0455デフォルトの名無しさん
2010/05/05(水) 18:20:24別にC++のテンプレートを褒める気は無い
重要なのは、あの醜悪な道具を使ったSTL並の道具を
C++の伝統的なOOの手法では作れなかったということ
Stroustrup自身が、自分にはSTLのようなものは作れなかったし、その発想が
無かったと認めている
STLの作者自身はOO嫌いらしいね
0456デフォルトの名無しさん
2010/05/05(水) 18:27:36日本語でおｋ
■ このスレッドは過去ログ倉庫に格納されています