オブジェクト指向逝って良し！

いらねーよ。んなもんは。
オブジェクト指向を礼賛する奴は「マルチメディア」を礼賛してた
やつと同じ。
本質がわかってない。

本質って？

まぁソフトクリームでも食べて落ちつけよ
　　　　　　　　　　 人
　　　　　　　　ノ⌒　丿
　　　　　＿／　　 ::（
　　　　/　　　　　:::::::＼
　　　 （　　　　　:::::::;;;;;;;）＿
　　　　＼＿――￣￣::::::::::＼
　　　 ﾉ￣　　　　　::::::::::::::::::::::）
　　　（　　　　　::::::::::::::;;;;;;;;;;;;人
　　／￣―――――￣￣::::::::＼
　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ
　　　　　 丶1　　　 八.　 !/
　　　　　　 ζ, 　　 八.　 j
　　　 　 　　i　　　 丿 ､　j
　　　　 　　 |　 　 　八 　 |
　　 　　　　 | !　　　 i　､　|
　　　　　　 | i し　"　i　 　'|
　　　　　　|ﾉ　(　　　i　 　 i|
　　　　　 (　'~ヽ　　　!　　‖
　 　 　 　 │　 　　　i　 　‖
　　　　　　|　　　　　　! 　 ||
　　　　　　|　　　 │　　　　|
　　 　　　|　 　 　 　| 　 　| |
　　　　　| 　 　　　　|　　　| |
　　　　 | 　　　　 　 !　　 　| |
　　　　|　　 　　　　 　　　|　‖
　　　／　 　　　　　　　　 　　ヾ
　　/ 　 　 　　　　　　　　　　　ヽ

>>1
ちゃんと言いたい事を正確にスレ名にしようね。

オブジェクト指向自身じゃなくて、
「何も分かってないくせにオブジェクト指向マンセーなどと
いいふらすミーハー馬鹿SEは逝ってよし！」っていう意味でしょ？

「COBOL逝ってよし！」と「低脳馬鹿COBOLER逝ってよし！」は
全く意味が違うぞ。

良く解らないから怯えてるんじゃないの？
いろはぐらいは理解してる？

オブジェクト指向に関しては色んな奴が、
色んなことを言ってるので、わけがわからん。
中には、よくわかってないのに語る奴もいるから
なおさら混乱する。

>>6
で、ナニがどうわからないのか説明してみ？

言語レベルのオブジェクト指向なら分かるんだが、
設計、分析レベルになると何だかよくわかんねーよ。

それに何か胡散臭いんだよね。机上の空論っぽいし。
あれって、構造化設計の本じゃ最早食えなくなった
方法論屋（？）が、C++が流行りだしたもんだから、
大挙してOOに群がってグチャグチャにしちまったって
印象なんだけど。

それをまた生真面目に実践しようとする
舶来理論信仰の日本人。

>>3
今度自分のティムポに生クリームぬって女に舐めさせて
みようと思う。let's変態

>>8
だから、

> 設計、分析レベルになると何だかよくわかんねーよ。

具体的にどんなことがわからないのか。

> それに何か胡散臭いんだよね。机上の空論っぽいし。

どんなところが胡散臭いのか、どんなところが机上の空論
っぽいのか説明してみ？

１だけどオブジェクト指向の利点ってなに？

>>1
そんなこともしらずにオブジェクト指向がいらないなんて
こと言ってたのか？

ちったあ、勉強しろ。

＝＝終了＝＝

>>11
一つの例であることを断った上で挙げれば
規模の大きなソフトを作るにあたって
手続き型や構造化設計の場合よりも全体が把握しやすく
脳味噌への負担が少なくて済むこと。
もちろん状況やPGの能力などによって話は変わる。

>1
敢えて言うならチンコケース。

オブジェクト指向いいねえ。
粘土細工みたいで好きだな。

継承が必要な理由を逝ってみ？

>>16
アホVBプログラマはくんな、ボケ、シネ。逝ってよし。

>>16
「必要」っていう言葉は使わない方がいいと思うよ。
極論すれば「アセンブラがあれば書けないことはない」から。
大抵の技術ってのは「必要不可欠」なんじゃなくて
「あったら何かと便利or儲かる」ってなもんでしょ？

チンコケースはカプセル化と再利用性と可搬性に優れている。

継承？便利だから。
なんでもかんでも一度に決められないんだわ、俺。
クラス設計いじってるうちにだんだん考えまとまってくるってこと、あるでしょ？
オレはあるんだけど。

>>16
多態性をつかって実行時に違うクラスのインスタンスを同じように
扱いたいからと、製造・検査・デバッグの工程が楽になるから。
「どこまで継承するか」が結構重要なので、設計を頭の悪いプログラマには
決してまかせられないところが欠点。

オブジェクト指向のメリットってがわかってないやつにはぜったい良い設計できない。

専門卒のVBプログラマはせめてこっちが言ったことを
守る努力はして欲しい。理解する頭が無いのはしょうがないことだから。
間違っても「そんなことしていいことあるんですか？
構造化設計で苦労したことないですけど」とか言わないでくれ。

オブジェクト指向３つの良さ
１．面白い
２．わかる
３．テストで点が取れる

だいたい、なんでオブジェクト指向「ごとき」が、
わからないやつがこんなに多いんだ？
2chって、やっぱホトンドがドアホで逝ってる厨房ばかりか。

哲学やれ。

>>25
こういう意味不明厨房ばっか。シネ、チンカスが。

>>24
違うよ。世のプログラマの半数は頭が弱いんだよ。
学力が無くて仕方なくコンピュータ系専門学校いって、
プログラマになったってやつが多いからな。

>>26
>>25ではないが、少し解説
オブジェクト指向の考え方って、哲学（ちょっと古いやつ）みたいなんだよ。
全て「物」(Object)としてとらえる。
「物」(Object)は属性と振る舞いを持っている・・・とか。

さりげなく、自作自演で
専門卒頭悪い、そしてその反対の俺は頭がいい！
と言っているが、完全な自慰行為だな。

マジで騙りたいと重い麻酔。
まず、オブジェクト指向という日本語が、初めて聞く人には全くなんのことやらわからないと思うんですよね。
とくにＶＢプログラマなんかは、オブジェクトなんかに触れる機械が少ないと思うんですよ。
なんのことはない、必要なものを現実の法則に従ってごく自然に並べればいいだけのことだと思うんです。
でも、よくあるJava等の冒頭で出てくる解説文なんかでは、全く意味不明だと思うんですよね。
あれで理解できたら凄いっていうか。そもそもクラスというものを知らないであろう初心者をターゲットにした本なんかで、ああいうことをやると混乱の素なんだと思うんですよね。
例を挙げると、テレビがあって、テレビには電源がついてる状態と消えている状態がある。テレビはスイッチを入れる機能を持っている。チャンネルを変える機能を持っている。
これでわかりますか？わからないでしょう。初心者（ＶＢer）が躓くのはこれらの意味が不明だからです。
ですから、自分が今まで慣れ親しんできた手続き型が、最上の方法であると勘違いしてしまうのです。
一度オブジェクト指向を半分でも理解したなら、考えがかわると思いマすぅ。

>>12
まず言質を取ってやろうとしたのに逃げられな。

誰でもいいが13以外の人も答えて欲しい。

質問再掲
１だけどオブジェクト指向の利点ってなに？

>>1
一回、オブジェクト指向言語でDrawソフト作ってみたら？
目からウロコ落ちると思うよ。

じゃあ、例えばカードゲームの「Solitaier」をオブジェクト指向的
設計をするとしたら、どう組みたてる？

＞１
たとえばな。
type unko
integer tinko
string tinkoa
end type
public tinkokusai()
ああもうＶＢの文法忘れたから書けん。残念だ・・・。

１だけどオブジェクト指向の利点ってなに？

答えを待ってます。

まぁ、一流国立なら基礎学力は高いんだけど、
やっていることが古い、専門が少ないんだよね。
だいたい、プログラミングとか全然関係無い学部だった人が、
会社入ってこれからはソフトウェアの時代だから、ソフトやれ！
と言われてやるようなもんだからたいしたことができないのは
当然だね。
まぁ、私大の一流大学なら、大半は、時流もの（最先端ではない）
をやるから、応用の末端はできるけど、案外、基礎的なことを
飛ばしているらしいね。
そして、全然関係無い所で趣味でやってた俺の方が上♪

>>34
まず、オブジェクト指向的設計手法をまなべ、ぼけ。
思いつく単語、振る舞いをならべてみろ。

>>30
んでもってそれをコードに直すと、テレビというのがオブジェクトで、
On/Off状態とか、今設定されているチャンネル番号がメンバ変数で、
スイッチを弄るとか、チャンネルを変更するというのがメンバ関数
になるわけだよね。

テレビオブジェクトを使う人は、テレビオブジェクトを生成して、場合
によって「スイッチを弄る関数」とか「チャンネルを変更する関数」を、
その必要があるときによんでやる。すると、テレビオブジェクトはその
関数の実装に応じてメンバ変数を変更するとともに、必要なら関数戻り値
とかで、関数を呼んだほうのやつに新しい状態によってもたらされる
何かを渡してやる事ができるわけだ。

で、なにが利点かというと、テレビオブジェクトは、機能さえマッチ
するならどのプログラムにでも、中身を疑わずに「コレはテレビの
機能を持っているオブジェクトだ」ということでインポートできるわね。
さらに、自分のプログラム用にカスタマイズした機能のついたテレビが
欲しい時には、例えばテレビを継承した衛星テレビとかでも作れば、
衛星テレビをつくる時に必要な実装は、元のテレビオブジェクトとの
差分だけで済むという事だね。

まぁ、一流国立なら基礎学力は高いんだけど、
やっていることが古い、専門が少ないんだよね。
だいたい、マルチメディアとか全然関係無い学部だった人が、
会社入ってこれからはマルチメディアの時代だから、マルチメディア
やれ！ と言われてやるようなもんだからたいしたことができないのは
当然だね。
まぁ、私大の一流大学なら、大半は、時流もの（最先端ではない）
をやるから、応用の末端はできるけど、案外、基礎的なことを
飛ばしているらしいね。
そして、全然関係無い所で趣味でやってた俺の方が上♪


１だけどオブジェクト指向の利点ってなに？

答えを待ってます。

>オブジェクト指向の利点ってなに？

楽。
開発が楽にならないものを開発者が受けいれるわけない。

>>36
ソースの使いまわしがしやすい、かな
実はオブジェクトオリエンテッドな言語は使ってないけど、
オブジェクト指向の考えかたを知ってから設計の仕方やソース
の書き方が変わったといった感じ。

Cで、変数（=クラス変数）と、変数構造体のリンクリスト（=インスタンスリスト）
と、それの操作用関数ポインタ（=クラス関数）で出来てる構造体をつくって、
無理やりオブジェクト指向もどきなコードかいてます。変でしょうか？

VB使って喜んでる厨房は十分オブジェクト指向の恩恵に
あずかっとるやろ。

>>43
別に変じゃない。OSカーネルだってそうやって書かれている。

返事が少ないから次じゃ！

質問２「オブジェクト」とは何ですか？

>>1は本でも読んで出直してきたら？

もうちょっと勉強してから「いらねーよ。」とか言おうね

>>46

お前な、教えてもらったら少しは感謝するか、お前なりの意見を
出すかしろ。

聞くだけ聞いて、自分のわからないところを次々と聞いていこう
なんて、甘えてんじゃねえよ、ボケ厨房。

市ね。

>>46
その単語の意味どおり、「モノ」のこと。
名前のついているものはみんなオブジェクト。

例：ディスプレイ、ウインドウフレーム、ソケット、時計、うんこ、
レジスタ、クーラー、手紙、コンビニエンスストア、マンコ、

など、なんでもオブジェクト。

ただし、プログラムをする上で、それをオブジェクトとして
プログラムする事が適しているのかどうかを判断するのは、
設計上の問題。

>>46
お前の人間性が最悪だから誰も教えてくれないんだよな

VBでも、だましポリモーフィズムは可能。
継承が無いので、やる気にならないけど。

前にも書いたけど、言質を取ろうとしているのです。

質問２「オブジェクト」とは何ですか？

「オブジェクト指向」を礼賛している方なら当然答えられますよね？

>>53
じゃ、次の質問に行く前にお前の前の質問にわざわざ答えた
方の回答に対して、すべてお前なりの意見をつけろ。

だからさぁ、OOでプログラミングしたくなけりゃしなくていいんだよ。

質も〜ん！
動名詞をFunctionObjectに見立てるのはいいのですかー？

オブジェクトとはCObjectのインスタンスなのさ

＞５３
お前のその鬼の首を取ったような口調はなんだ。

>>53
お前には知る資格が無い！

>>53 >>46で既にオブジェクトは「物」だって説明がついてる
じゃん。扱おうとする対象をオブジェクトと呼ぶってことで。

カプセル化、データ抽象の意義ならわかるんだが、
継承とか多態とか、そんな重要だとは思えない。
よく継承ができないからOOじゃないとか鬼の首とったように
言うけど、継承できなくてもあんまり困らん。
コードの再利用って言ったって、コピペの柔軟性には
遠く及ばない。

>>61
不細工しか知らないんだね。

>>61
＞コードの再利用って言ったって、コピペの柔軟性には
＞遠く及ばない。

ライブラリのソースコードをコピペするよりはヘッダ読んで
継承したほうが楽だよ

>>61
別にお前は知らんでいいんだYO！

やれやれ、結局だれも判ってなかったのか。

つうことで、「オブジェクト指向」とは「マルチメディア」と同じで
判ってないと言うと「判ってる」と主張してる人から叩かれる
一種の宗教ということが証明されました。

＊＊＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊＊＊＊＊＊

多態こそオブジェクト指向の本質だ。
理解できない61は逝ってよし。

>>61
オブジェクト指向で設計、コーディングしてて、継承と
多態なんて、頻繁に出るのが普通だろ。

お前にとって重要でないなら使うなよ。どうでもいいよ。

>>1
クソが。二度とでてくんな。チンカス厨房め。

なんで怒るの？

怒ってるんじゃなくてバカにしてるんだよ。

>>65
こいつは、「俺の理解できない事は全部嘘」
というカルト宗教にはまっている事が判明しました。
加えて、どうやらかなりの馬鹿のようなので、
答えを言うのは無駄のようです。

お相手した皆さん、ご苦労様でした。

>>61
コピペした部分にバグが出たとき、全然柔軟じゃありません。

>>69
この世界にはオブジェクト指向で語れることがいっぱいあるだろ。気づけ！

補足
次の言語アークテクチャーが現れた時には
「俺はオブジェクト指向をわかってるんだぜ」と今言ってる人は
「俺はマルチメディアをわかってるんだぜ」と言ってた人と
同じ運命を辿るでしょう。

補足

このカルトかぶれは、世の中に対しても人間の精神に対しても
役に立たない予言しかしないので、よっぽどの基地外クソ馬鹿
しか入信しないでしょう。

オブジェクト指向とマルチメディアを同列に語ってる時点で
頭痛いんですが、、、

>>76
やつは現実を逃避したいだけだよ

絵描きと同じよ。人物や物を良く観察することが大事。

つうか。
全く同じままで再利用することなんて稀じゃないすか。
大なり小なり修正を加えるわけで。
そういう再利用性に関して言えばコピペが一番柔軟に
対処できる。
あらかじめどんな変更を加えるか予知できない以上、
どんなに慎重にクラス設計しても、
継承による再利用には限界があるわけで。

つーか、Cでコピペしてる馬鹿がOOP覚えてもクラスをコピペする
だけ。
同じ。

>>79
コピペを使ってると、コピペ使った部分を修正する必要が
でたときに、コピペしてる場所全部修正することになるだろ。

なんで、こんなことまで説明しないとここでは話が進まない
んだ。

>>79
抽象的なイメージで分割できるprotectedな小さい関数沢山
作っておいて、継承クラスで必要に応じて呼べばいいだけじゃん。
80％が似ているコードだったらそうするぞ、おいらなら。

コピペ、ダメ、絶対。

>>79
もしかして基底クラスは一度作ったら修正加えないもんだと
思ってますか？

コピペで何とかなると思ってる６１は小規模趣味プログラマ

>>61
その変化に耐えることができるのがオブジェクト指向なんだよ・・・

１はあのジョークサイトを真に受けてしまったんだよ。

６１だった。

>>84
いや、年数多い奴にもそういうのいる。

継承でも良いし集約でアダプタ作っても良い
オブジェクト指向は楽しいね
あーなんかコード書きたくなってきた

>>87
1は逝っちゃってるからね

そもそも1は、オブジェクト指向について、ここにいる
人たちに「一から」教えてもらおうとしているだけでは。

って、今話してるのは61さんか。

いやだから、再利用の柔軟性に関して言えば
コピペ＞関数＞継承、ですよ、絶対。
実際、オブジェクト指向が流行り始めた当初はともかく、
継承が再利用性とか差分プログラミングと
からめて言及されることは少なくなったと思うんですが。

＞いやだから、再利用の柔軟性に関して言えば
＞コピペ＞関数＞継承、ですよ、絶対。

アホカ。市ねボケ。保守のしやすさ、変更のしやすさ、
バグの少なさにかんしては、

コピペ＜＜＜＜＜＜＜＜＜関数＜継承

だろ。

コピペは同じものしか作れないんだから全然柔軟じゃないだろ。

柔軟に変更できるのは61が労力を費やしているから。
コピペのおかげじゃあーりません。

>>92
あんた、お手軽ということと柔軟性という言葉をいっしょにしてるだろ。
継承利用できるように、基底クラスを改編する作業よりは、コピペの方が、
とりあえず動くだけなら確かにお手軽だよ。

でも、1000KL規模のプロジェクトでそんなことやったら、時限爆弾仕込んだ
も同然だよ。

>>92
1000行以上書いたことない発言だな

酷いな、説明よりレッテル張りと罵倒かい。

派生クラスでの不都合を修正するために元のクラスを変更したら
別の派生クラスに不都合がでるだろうが。

>>97
あほ。そんな変更の仕方しか思いつかないのか？
どう変更するつもりなんだ？？？

>>1
継承、多態、カプセル化、などなど
色々とオブジェクト指向を語るキーワードはありますが、
これがオブジェクト指向だ！、というものはないと思います。

まず第一に、オブジェクト指向というのは方法論です。
オブジェクト指向プログラミング言語はその方法論を
コードの形で表現するにあたって便利な文法機能を
整備したものに過ぎず、C++やJavaを使ったプログラムであれば
オブジェクト指向と呼べるというようなものではありません。

第二に、所詮は一つの方法論に過ぎませんから、常に有効なものでもありません。
下手にオブジェクト指向するよりも、素直に手続きを並べたりした方が
よほど楽で確実な場合は幾らでもあります。

これらを踏まえた上でオブジェクト指向の利点を言えば、
それはずばり、解決すべき問題とその解決手段との距離が短くなる、
ということに尽きると思います。

→次の発言に続きます・・・

ソフトウェアは何らかの問題を解決するための手段です。
私達はある問題の解決をコンピュータに依頼するために、
プログラミング言語を用いてその問題の解法を記述します。

このような文脈において最も理想的なのは、
問題を記述すればコンピュータが解法を勝手に考えてくれることでしょう。
ですが実際にはそれは夢想に過ぎません。
プログラマは解決すべき問題の内容を解析し、
コンピュータの能力を利用した解法を考え出さなくてはなりません。

プログラミング言語の発展過程に見るプログラミングパラダイムの変遷は、
この問題解析と解法の記述を以下に効率化するかにあると見ることができると思います。
手続き型言語では解法を一つ一つの手順単位で
ひとかたまりのものとして記述しなければなりませんでした。

構造化言語では解法を部分的な解法に分解し、
それらの解法を容易に様々に組み合わせることを可能にし
問題を部分的に解析する余地や解法を再利用して効率化できるようになりました。

オブジェクト指向では更に踏み込み、
解決すべき問題となっている状況をそっくりそのまま
コンピュータ上に表現することで問題のシミュレータを作り出し、
そのシミュレータを制御する形で問題を解決する方法を与えてくれました。

→次の発言に続きます・・・

この発展過程に沿って、プログラマの作業領域が少しずつ減少しています。
手続き型言語では問題の解析から最終的な解法の完全な逐次的な記述までを
考えなければならなかったのが、問題の解析から解法の記述、
場合によっては制御の余地を残しつつ問題をコンピュータ上に表現すればよい
という形に変化したのです。

オブジェクト指向およびそのための実装技術を利用することにより、
プログラマはコンピュータの使いこなしのための頭脳労働から離れ、
問題の理解や解法の分析により集中することができます。
これが、解決すべき問題とその解決手段との距離が短くなる、
ということの意味です。これは非常に大きな利点だと思います。

以上、あくまでも私見ですが、よろしければご参考までにどうぞ：）

>>97
既存のルート変更するなんて馬鹿がいるかよ。
既存ルートの処理を関数分割して切り出すだけでいいじゃん。

>>92
全く別の画面が10枚あるソフトがあって、全画面共通の機能として
マウス右クリックでメニューが出ます。
この処理をどこに書きますか？

>>99-100
判りやすい回答ありがとうございました。

>>102
コピペの方が速いのでは？

解決したので
----------------------- 終了 -----------------------

オブジェクト指向＝認知科学の奴隷

>>105
おめー、煽って教えてもらおうってハラか・・・・・

>>105
とりあえず動くまでが速いか遅いかに、なんで拘泥するんだよ！
1000行以下厨房プログラマならともかく。

http://www.njk.co.jp/otg/Study/OOPrinciple/

>>1
ほれ勉強してこい

夏厨の季節が近いのか…
あるいは、研修終了直後馬鹿新入社員か？

理解力低いくせに自身たっぷりなアホが増えたなあ。

＞とりあえず動くまでが速いか遅いかに、なんで拘泥するんだよ！

んじゅあ「オブジェクト指向」の利点はなんですか？

>>111
私の私見のことをおっしゃっているのでしたら
まだまだ未熟で申し訳ありません。
今の私にはあの程度の理解が精一杯です。
当方、今年度入社したばかりの新米PGです。

一人で２万行超（空行除く）やったことあるYO >>96

>>114
それが自慢ということはやはり学生か。。

だめだコリャ

>>114
晒しage

OO信者うざ

んじゃ、別の質問
MVC は Most Verbose Cording の略だと
思うのですが？
識者の感想求む。

とりあえずは一個の関数しか使わないのに
将来を見越して多機能なオブジェクトを作るのってめんどくさくないですか？

OOに信者なんているのか？
OOやってる人は、楽だからやってるだけだと思うが。

OOが理解できない低能が、それを信者と呼ぶなら、
魔女狩りみたいなもんだな。無知馬鹿は御し難し。

まあ、わかってないのにわかった振りしている馬鹿は
カルト信者っぽく見えるけどねー。

どんな技術であれ信奉すれば自滅する。
状況が永劫に変化しないと仮定するのでない限り
どんな技術も適材適所のものでしかない。

筋道立てて反論できないと怒る
信者OR頭悪い

>>119
そんなのどうでもいい。
頭でっかちになってるんじゃない？
勉強止めてコーディングしてみれば？

>>119
Model　View　Controllerだ。クラス分割方法の理想論。

Model：内部スキーマ（例えば、アプリのデータ記録領域）
View：外部スキーマ（例えば、アプリのUI）
Controller:Model-View間のイベント通知機構
（上の例なら、UIのボタン押下イベントをModelに通知して、
Modelで、ボタン押下に割り当てられるデータ処理を行うとか）

筋道立てて反論できないと怒る
信者OR頭悪い OR
「わかってないのにわかった振りしている馬鹿」 >>121

>>120
そんな必要ないだろ。

タンスのスキーマのほこり

なんか、スゲー低レベルスレだな。

>>1と、匿名煽り荒氏うざ。

>>125
その言い方は聊か御幣があるように思われ。
Controller が常にほとんど何もしないように聞こえる。

View →(Event)→ Controller →(OperationRequest)→ Model

20年以上の歴史があるモデルというのも珍しいと思う。

>>129
煽るな

130 っす。
御幣ってなんだよ(藁
なんでこんなもんが第一候補に・・・
正しくは語弊っす。

>>120
一つしか使わないんだったら、オブジェクト作るのたしかに無駄
まぁ、最初に最低限の物作っといて別の操作必要になったら継承して拡張でいいんじゃない？

>>130
でもさー、実際Controllerって殆ど何もしないでしょ？

Observerパターンつかって、ViewがOberveableで、
ControllerがObserverで、Modelが実作業領域という構成
が普通じゃないの？

>>134
うーん。他所の実装見たことあるわけじゃないから
何が普通かと言われると困るな。
俺は基本的にデザパタに出てくるパターンとMVCは区別してる。
デザパタ風に言えば、

Model:Observable View:Observer
Controller:Observer View:Observable

というのに加えて、Controller が Mediator チックってところ。
あと蛇足だろうけど、Modelにはプリミティブな編集機能だけ持たせて
複雑な編集機能はそれを組み合わせる形で Controller に実装する。
この場合、Controller はただのイベントディスパッチャとは言えない。
モデル解釈間違ってるかな？

じゃ、わかりやすくJavaServletで説明！
View (JSP) 検索ボタンクリック！
Controler (Servlet) 検索文字を解析して検索開始！
Model (Bean) 検索結果を格納
View (JSP) 検索結果を表示！これじゃ駄目？

>>135
Contorllerが、イベントに対応する処理を自分自身に実装
しているということね。
おいらのは、イベントに対応する処理をModelに実装していて、
Controllerはそれを呼び出しているというだけの違いだよ。

どちらでもいいとおもうんだけど。あとは会社の方針とかに
よって決めてくだされ。

ObserverやObservableって何？

>>136
ついでに言うと、その場合EJBコンテナの先に、
EJBコンテナ：View
JDBCドライバ：Controller
RDBMS:Model
という関係も存在する。多段のMVCはありがちな話。

>>138
簡潔にまとまってるんでここでも読んでみるべし。

http://www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html

>>138
Obというサーバーです。

あるいは
EJBコンテナ：View
JDBCドライバ＋RDBMSストアドプロシージャ：Controller
RDBMS:Model

という考え方もあるね。
>>139は>>134の例で、これは>>135の例だね。

ところで皆さんは
DBにクエリーを発行するのに
Controler使う？
それともModelで使う？

プログラムの難易度を行数で決める痛いヤツがいるな。
そりゃ、コピペとかでプログラミングすれば、ステップ数は増大するわな(藁

>>143
それ以上はスレ違いかと

DBはModelで使うでしょ？
Modelの目的がDBの隠蔽って意味もあるし
Modelにストアドのパラメーターを
送るだけだと思うけど？

>>143
130 だけど、相手が DB の場合は Model だなぁ。
Controller をスクリプト処理装置的に位置付けるのは
Model の応答速度が十分速いとわかってる時だから。
大した処理をしないことが分かっていて且つ
ローカルの高速な DB を弄るんなら Controller に処理置くかも。

うちは迷わずModelだよ
コントローラーはユーザからの入力と各Model/Viewにイベント通知という
仕事しかしない。

PACモデルで実装したことある人いる？
コントローラー層間のやりとりが具体的にイメージできないんだけど

> 大した処理をしないことが分かっていて且つ

それってModelを省略してControllerに内包する場合でしょ？
DBとのやりとりってビジネスロジックだからModel以外に書くのは
スマートじゃないと思う

１は30年つづいてる方法論を、パソコンやCD-ROMドライブを売るための
売り文句を同列で並べているのか。残念ながら本質を一番わかってないのはオマエ

いや、そういう話じゃないよ。
俺は MVC ってのは Model は
極力仕様を固定するものだと考えてて、
長期的な仕様変更に際していじるとしたら
なるべく Controller に集約したいと考えてるわけ。
だから、Model にはプリミティブな処理を、
Controller にはそれを組み合わせた機能を、と位置付けてる。
これが基本的な理想ね。
ただ、DB 相手にこれを真面目にやってたら
パフォーマンスがお話にならないので、
Model と Controller での役割分担率を Model よりにする、
という風な発想でデザインを考える。
ビジネスロジックはデータを弄るものだから Model に置く、
という風にはあんまり考えない。

あ。151 は >>149 ね。

んーーではModelについて質問！
ある結果セットをModelに格納して
その結果セットをグルーピングしなければならない
とすると、それもModelでするんですかね？
表示方法って考えだったらViewでするような気が
あーーーMVC難しいーーー！！

>>151
それだとビジネスロジックがModelとControllerに分離するので萎え
仕様変更ってのはそのアプリケーションのつくりが変わるってこと
だから、Modelは変更になるよ。アプリの作りが変わっても変更しないで
いい部分っていうのは、違うアプリケーションとも共通で使える部分。
M/V/Cのそれぞれにそういう部分がある。

どっちかっていうとMVCじゃなくデザパタよりな話
使う

>>153
そのグルーピングの意味づけ次第だとは思うけど、と前置きしておいて、
Modelじゃないの？MVCのメリットの一つに、分業も楽になるっていうのがある
よねえ？Modelは業務に詳しい人、Controllerはシステムに詳しい人、Viewは
画面デザインセンスのある人がやればいい。Webシステムなんかの場合、
プログラムをしらないWebデザイナーにHTMLを書いてもらえる(JSPやPHP等を
使って)ので、Viewのロジックは（表示用の物であっても)極力少なくするが吉

>>154
それもよく分かる。分担比率考える際にいつも頭悩ませてるし(藁
Controller をディスパッチャにするってのは確かに堅実だと思う。
じゃあなんで積極的にそうしないのかっていうと、
オブジェクトの粒度がアンバランスな気がしてならないってこと。
Controller が薄くなって Model が太るのってどうかな、とね。
一つの逃げとして使ってるのは、

View - Controller - Service - Model

っていう４層構造だと考えて実装上は Service と Model を
一まとめにするっていうやり方。
ビジネスロジックなんかは Service に置いて、
DB 設計が Model にあたると見なすわけ。
ほとんど詭弁なんだけど、まあ気分的にはすっきりする(藁

>>153
やっぱViewだろ
Modelなるべく生データーを保持しといたほうがいいよ。
UIはなるべくViewに集約させたほうが....
ModelはあくまでDBのラップにとどめておいた方が
仕様変更のときViewいじればいいだけなんで..

んーーーー
>>155 さんの言うことも同意
>>157 さんの言うことも同意
んーどっちが良いんだろ
プロジェクトによるってことですかね？

> っていう４層構造だと考えて実装上は Service と Model を

自分で「ほとんど詭弁」って言っちゃってるけど、要は実利が
ある方法はどれかって話で、無理矢理あたらしい構造の意味づけをする必要はない。
でもって、「Controller が薄くなって Model が太るのってどうかな」って
いう考えがどこからくるのかわからない。もし一つのユーザーの操作について、
View-Controller-Modelがそれぞれ一つのクラスしか関連しないと考えているなら
大間違い。Contollerは一個でも、Viewは正常系と異常系で違うクラスだったりするし、
Modelに至っては複数絡むほうが普通でしょ？

>>157
> ModelはあくまでDBのラップにとどめておいた方が
> 仕様変更のときViewいじればいいだけなんで..

それを行ったらModelにいれておけば
仕様変更のときModelいじればいいだけじゃんよ..

>>1
仕事でプログラムするんじゃなければ、そのとおりでいいよ。

>>159
オブジェクトの粒度を揃えたいというのは
自分の頭の中でイメージのバランスをとりたいから。
ここでのオブジェクトの粒度っていうのは、
処理の複雑さとか実装量とかを含めた総合的なものね。
俺の場合はそういうバランスをとるとイメージがやりやすくなる。
それと、粒度を均質にすることで個々の部位の可搬性が高まるということも期待してる。
自分が考えるときに負担がないってのは実利だよ。

>>157
それだとModelの意味無いような...
ViewでResultSet直接いじるのと変わらない
と思う。

>>157
DB定義やビジネスロジックが頻繁に仕様変更があるのはきっと何か間違ってるぞ。
よってModelに入れとけばいいと思う。

>>159
ああ、あと追加しとくと、
Controller に関係するオブジェクトが沢山あるんだから
ディスパッチャといえども薄いってことにはならないだろ、
という話については、
ツリー構造なりのテーブル組んでディスパッチすれば
どうにかなるようなケースしか扱ったことがないんで、
その程度だとどうしても薄く思えてしまうと答えておく。

>>163
横槍スマソ。
それまでコンピュータを導入してなかったところに
新たにシステム一式を導入することになり、
それに合わせて業務スタイルも変更するという事例があって、
その時は開発途中で徐々にビジネスロジックを変更していった。
元データは紙で用意したものがあってフォーマットは固まってた。
そういう経験があるもんで、ビジネスロジックと
DB設計とを比較すると前者の方が流動的だと感じてしまう。
例外的な話かもしんないけど一応そういう話もあるってことで。

基礎的な質問でごめんだけど、

オブジェクト指向ってどういうのを言うの？

本読んでも言ってる事がばらばらな感じがして実体がつかめないんです。
自分なりの解釈では、構造体をデータだけでなく関数も要素として扱えるように
拡張させた言語っていうふうに認識しているんですが、違いますか？

>>109他
コピペ厨に行数で勝とうなんて馬鹿だな。

>>166
それはclassでっせ
間違いじゃないけど
それは一部です。

>>166
「鬼畜米英」と同じような流行語です。
批判すると狂信者に叩かれます。
次の言語パラダイムにシフトするまで我慢してください。

>>166
問題の対象となるナニカを、Objectという概念でとらえること、
とらえようとする試みをいいます。

Objectは、データの集まりでもいいし、抽象的な概念でもいいし、
具体的な処理の集まりでもいいし、それら全部を併せ持っていても
いなくてもいい。

（この後は、なんか、その辺の本を読んでくれ）

てことかな。

>>169
流行じゃなくてスタンダードでしょ
君はどんな言語使ってんの？

しかし、現実問題、オブジェクト指向の次のパラダイムって
みえてこないよね。

エージェントとか研究レベルのものじゃなくて、2chの皆様
にも影響があるようなやつ^^

俺がSEやってる間は、もうパラダイムシフトで悩むことは
無いんじゃないかという気がしてくる。

>>169
で、君は次のパラダイムシフトがくるまで、バカにされ
続けてください。

ルネッサンスだな。

データ+アルゴリズムの時代に戻るのさ！

>>170
のように参考書には書いてありますが、意味不明と感じたら
それは正しいのです。
別に理解しなくてもC++は書けますし。

あ、またレス増えてるし。
じゃあ、

＞Objectは、データの集まりでもいいし、抽象的な概念でもいいし、
＞具体的な処理の集まりでもいいし、それら全部を併せ持っていても
＞いなくてもいい。

って概念を使ってなんか特殊なプログラム書けるのかい？

いいから、1は死ね。

1はOOPになんか恨みでもあるのか(藁

>って概念を使ってなんか特殊なプログラム書けるのかい？

特殊ってなんだ？まず決めてくれ。

>>176
最後は全部マシン語になるんだから
オブジェクト指向だろうがアセンブラだろうが
書けるものに違いのあるわけはない。
書きやすさの問題だっての。

反論出来ないんですか・・・
単純な質問しかしてないのに。

>>1
お前は、人には質問するくせに、人の質問には答えないね。

しかし1は質問に答えないやつだなぁ

つうか、逆に聞きたい。
「オブジェクト指向」とやらに触れる前はどんなプログラム
書いていたんだろう？
そこらへんの違いかもね。

> 粒度を均質にすることで個々の部位の可搬性が高まるということも期待してる。

そうかなあ、Modelは現実世界にある物のシミュレートだから、
分析・設計にModelのサイズが絡むこと自体が間違っていると思うけど

>>1
> 別に理解しなくてもC++は書けますし。
あー、いっぱいいるよね。Cの拡張としてしかC++を使えてないやつ
> 概念を使ってなんか特殊なプログラム書けるのかい？
特殊なプログラムなんじゃなくて、普通のプログラムを書くのが楽になるの。
理解できないならかえって大変だから使わなくていいよ。
一生コーダーでいてください。

>>1 は煽りの練習してるんでは？

>>176
偏執的だね。
1というオブジェクトのデータはたぶん、オブジェクト指向はいらない
というデータが一個だけ入ってて
それを書き換えるためのメッセージインタフェースを持たないんだね。

とりあえず他の人も見れるのでブロードキャストしときます。

＞＞Objectは、データの集まりでもいいし、抽象的な概念でもいいし、
＞＞具体的な処理の集まりでもいいし、それら全部を併せ持っていても
＞＞いなくてもいい。
＞
＞って概念を使ってなんか特殊なプログラム書けるのかい？

汚い例だけどわかりやすいものでは
MFCをつかったウィンドウアプリケーションとかだね。

とりあえず、簡単に、Windowというオブジェクトを
使ってプログラムが書けるよ。

簡単にってとこがポイントね。

別にコピペをしてもいいよ。
コピペという継承手段を用いてるだけだから。

もちろんSDKを使えば、MFCなしで書けるし
SDKやMFCで使ってるコードをコピーしてきて
書き直してコンパイルしてもいいけどね。

オブジェクト指向は、別に特別なものを作るための概念じゃないよ。

>>185
その辺は仕事分野の違いかも。
俺は据付の社内システムとかよりも
パッケージ製品作る仕事の方が多いから
Model の直接的な再利用って結構多いのよ。

>>179
「オブジェクト指向」特有のプログラム。
話のながれから判りそうなことだが。

>>189
君が特殊と思っても周りにとっては普通

>>189
一人ならずオブジェクト指向は作業効率の問題だって言ってるじゃん(藁
作業効率以外にオブジェクト指向ならではってのがなきゃ駄目なわけ？

>>185
うーん、Modelを再利用するのに、機能の重みが一定の方が
管理が楽っていうのはわかるけどね。
Modelでも複雑な計算とかする部分は、ドメインモデルと
マッチさせずに独立的なクラスにしたりするし。

ごめん>>188の間違い

1はオブジェクト指向だけじゃなくて日本語の理解も
うまく処理できないようなのでほっとこう。

JDKのライブラリをいっさい継承を使わずにコピペで作ってたら
まだバージョン1.0.2もできてないと思うけど。

揚げ足取りだけか・・・。
「オブジェクト指向を判ってます」は
どうみても
「マルチメディアを判ってます」といっしょだぞ。

クラスを理解している。
継承を理解している。
インスタンスを理解している。
カプセル化を理解している。

というのと「オブジェクト指向」を理解している
というのは上の定義から全然ちがうじゃんか？

>>192
俺も自分のやり方が常に通用するなんて思ってないよ。
結局は道具の使い分けが肝心だからね。
分野だの状況だのに合わせて色々と方法がある、と。
たった一つの冴えたやり方ってのがあるなら知りたいけどさ(藁

>>194
はクラスと「オブジェクト指向」を混同してるのか？

オブジェクト指向って何って質問した166です。
回答してくれた方どうもです。
正直言って概念が抽象的でイマイチ理解できてません。(^^;

たとえば、あるデータをハードディスクに書き込むプログラムを設計した時に、
書き込むデータを一つのオブジェクトとして、
書き込まれる媒体をもう一つのオブジェクトとして設定しておけば、
書き込まれる媒体がハードディスクじゃなくて、
MOになったり、FDDになったりした時にも
プログラム自体に大幅な変更を加えることなく
柔軟にソースの使いまわしが出来るっていうことですかねぇ。

なんか著しく誤解してますか？

>>198
それは論理デバイスと物理デバイスの対応というDOS時代から
あった概念ですぞ。（オブジェクトという言葉は使わないが）

>>198
多態の効能としてそういうのがあるというのは確か。
だけど、それだけがオブジェクト指向というわけではないよ。
うまく説明できないけど、オブジェクト指向って定義できるもんじゃないと思う。

>>1
だ・か・ら、OO を使わないと書けないプログラムなんてないってば。
C を使わないと書けないプログラムなんてないでしょ。理論的には
アセンブラで何でも書けるでしょ。

>>200
前向きに賛成。
発展的に解決ということでよろしいでしょうか？＞ALL

>>197
オマエが>>105で「コピペの方が速いのでは？ 」って言ってる

みんなオブジェクト指向は理解してるのを前提にMVCやら再利用性について
話してるのに、低次元に引き戻すのやめてくだちい

つーかあまりにも煽りのパターンを継承したやり方（自分の質問に対して
有用な回答は無視、自分への質問も無視、「揚げ足取りか」と特定の
レスを批判するだけ）だよね。ネタスレだった？
だとしたら俺は見事にひっかかった口だな

鬱市

質問に答えないってどれでしょう？

「1はOOPになんか恨みでもあるのか(藁 」
つうのは無視してますが？

>>198
論理デバイスに対する書き込み操作のことをいってるね。

論理デバイスは、中身がなんであれ大体連続した書き込みと読み込み
ができる。不連続な書き込みと読み込みも出来るんだ。

と気づいたときに、

ああ、これを一つのオブジェクトとしてとらえるとすっきりするな。

と考えるのが、オブジェクト指向的なやりかたです。

使い回しが出来るかどうかは、実際にプログラムするときの
問題（特にプログラミング言語の問題）で、オブジェクト指向とは
直接関係がありません。

で、実際に、そうすることでなにが便利かというと
具体的なデバイスの中身（HDD/めもり/MO/テープ)を知らなくても、
それらを扱うプログラムを、物理的な性質に依存することなく、
オブジェクトが持つ特性だけに着目して作り置きしておくことが
出来ることです。（まあ、でも、これは、全体の中のごく一部なんだけどね）

>>198
例えば >>100 でシミュレーションっていう言い方が出てたけど
何がそのシミュレーション上でオブジェクト化されるかが凄く多様。
Printer とか Display みたいな具象物かもしれないし、
Amount とか SortAlgorithm みたいな抽象物かもしれない。
何をオブジェクト化してもいいんだよね。
だから、これをオブジェクト化するのがオブジェクト指向、なんて言い方はできない。
その意味で言って、オブジェクトとは何か、というのは
対応するものを挙げることで定義できるようなものとは思えないなぁ。

>>200
ちなみに何が「マルチメディア」なのか特定できない
つうのも一緒ねｗ

>>206
＞その意味で言って、オブジェクトとは何か、というのは
＞対応するものを挙げることで定義できるようなものとは思えないなぁ。

同意。
材料は同じでも、そのシステムで着目すべき点によって、
作成するオブジェクトは変わってくる。

>>166
オブジェクト指向言語のメリットとしては、隠蔽とか継承とかあるよね。でも、
隠蔽とか継承という概念なんて、C でも書こうと思えば書ける。

例えば FILE *fp; fp=fopen(FILENAME, "r"); なんて、FILE 構造体がどういう
メンバを持っているかを意識してないでしょ? ちゃんと隠蔽が実現されている。
# むりやり構造体の中身を覗こうとすれば覗けるけどね。そこが「書こうと
# 思えば書ける」というレベルの限界。

で、だ。オブジェクト指向言語で開発する利点は、設計と実装が一つの流れを
構成できることにある。例えば設計者はテレビという「モノ」を考えればよい。
機能 (電源 ON/OFF) や状態 (現在のチャンネルなど) を考えるわけね。
それをそのままコードに落としこめるのが利点。

C だとなかなかそうはいかない。結局実装するときは関数単位で考えなきゃ
ならないからね。不可能じゃないけど、難しい。

要は、「オブジェクト指向言語を利用すること」と「オブジェクト指向で
開発すること」は別物ってこと。

とりあえず、1は放置ということでよろしいか？

おぶじぇくと指向、いまいちよくわかってない。
っていうかこの辺複数人数で開発する事に殆ど
関わった事ないから実態不明。
ただ、会話・コミュニの必要性が少なかった気
がする。ということで自立心の薄い僕はアウト（笑）

独りで研究しても実践性に欠けるっぽい。

なんか一人で脳味噌がツボにハマってきた(藁
オブジェクトの対応概念を明確に定義できないなら
なんで俺は自分はオブジェクト指向してるって自覚してるんだ？(藁
自分なりに「これがオブジェクトだ！」っていう条件があるはず。

つーか、こんな時間に......。

マルチメディアと一緒にするあたりがヤバすぎ

>>1
なんで俺がお前宛の質問をさがさにゃならんのよ？
>>10, >>54,あと自分がどんなしゅほうをつかっているのかって質問も
あったでしょ？

1の質問に対する答え
質問１>>11
>>13,>>20,>>21 (>>16への答えだけど、>>11の回答にもなっている)
質問２>>46
>>50,

61まできて飽きた。あとは自分で探せ。自分の意見も言わずに人のいったことに
けちつけるだけじゃ、政治を批判してる主婦のオバちゃんと一緒だぞ？

>>209
同意。
例えば、2chのHTMLを解析してオブジェクトとして保持しようと思ったら。

クラスが

・2CH
・Ita
・Sure
・Resu

という感じででてきて、

2CH --◇ Ita --◇ Sure --◇ Resu

になる。

2CHはフィールドとしてアドレスとかIta全部とか持ってる。
で、HTMLをパースして2CHオブジェクトを生成する2CHGeneraterとかがいる。

非常にわかりやすいし、コードにも落としやすい。

対象概念の分割を自由に行うのがオブジェクト指向、
って理屈を考えてみたんだけどどう思う？
手続き型とか構造化だったら個々の手順とか処理単位でしか
対象概念を分割してなかったのを、
プログラマの考え方に合わせてメタ構造も含めて
自由自在に分割して表現するのがオブジェクト指向。
外してる？

>>10は私への質問ではないです。

> その意味で言って、オブジェクトとは何か、というのは
> 対応するものを挙げることで定義できるようなものとは思えないなぁ。

そだよ。オブジェクト指向は手続き型に対する用語であって、「オブジェクトがなにか」
をきっちり定義する必要なんかない。思考エネルギーを別の部分にむけてください。

したがって
> ちなみに何が「マルチメディア」なのか特定できないつうのも一緒ねｗ
とは全く違うので誤解の内容に

しかもマルチメディアって定義ちゃんとあったし。言葉の定義は
「音声・文字・画像・動画など多数のメディアの混合」みたいな感じだった。
実体は「CD-ROMで配布されるPCソフト」を指すことが多く、要は広告コピーみたいな
ものだった。それと（おそらく1が生まれる前からつづいてる)概念モデルを
同列に扱うのは論外。

> >>10は私への質問ではないです。

そうみたいね。ゴメソ。でもそうやって自分がつっこめる
ところしかレスしない姿勢が、煽りの典型パターンだっていうことには
気づいてるよね？もちろん。

とりあえず >>1 に放り投げておく。

OOPの利点は高度に注意深く設計されたオブジェクト(クラス)を
組み合わせることで、効率よく、かつ安全にプログラミングが出来ること。

これにより、プログラム設計・作成工程の短縮化が可能になる。

また、もう一つの利点だが、
必要に応じオブジェクトの多態性を利用して、本当に解決したい
問題の解決へ、既存の概念や手続きを活用できること。

より複雑化する問題の解決アプローチとして、
すでにある解決法が流用できるならば、それを流用しない手はない。

流用に至る設計の過程と、じっそうに於いて、OOPは役にたつ。

OOPでなえれば解決できない問題というのは、特にないが
OOPを利用した方がスマートに解決できる場合も多い。

OOPとOOは違うもんだけど、俺の知ってるOOの応用例がOOPしかないから
OOPについて書いた。

OOは、べつに、見限るべきものではないと思うぞ。

んじゃ、眠いから、おやすみ。

>>216
彼は設計者なのだな。で、オレはプログラマ。彼は今オレにおおまかな
設計を示した。数日後、>>216 にコードを渡すわけだが、まぁ
そこそこ彼の意に沿ったものを完成させられるだろう。

つまりオブジェクト指向を使うとコミュニケーションが比較的容易なわけだ。
俺が退職しても、別の人が >>216 の設計ドキュメントを読んで、おおまかな
流れを理解することができる。それから俺の書いたコードを読めば、メンテも
しやすいだろう。

もちろん、「非 OO だとコミュニケーションができない」というわけじゃない。
単に「OO だとコミュニケーションが比較的容易」なだけ。

>>166 に説明することにしたから、もう >>1 はどっか行っていいよ。

実は>>166がとっくに寝てたりしてな

1って質問だけじゃなくての意見も書いてるじゃん
>>169
（>>166のオブジェクト指向ってなんですか？に対して）
>「鬼畜米英」と同じような流行語です。

>>175
> >>170
> のように参考書には書いてありますが、意味不明と感じたら
> それは正しいのです。

相手するだけ無駄だったな

>>220
＞でもそうやって自分がつっこめる
＞ところしかレスしない姿勢が、煽りの典型パターンだっていうことには
＞気づいてるよね？もちろん。

お前はアホか？
質問に答えてないというからレスしたのに。
やはり煽りは無視すべきだった。

寝ますわ。
オブジェクト指向言語を苦労して習得した人には酷なスレだった
のかもしれません。
俺は３日でアプリ完成まで行ったけどね。

いろいろ回答ありがとうです。

>>205
> 論理デバイスは、中身がなんであれ大体連続した書き込みと読み込み
> ができる。不連続な書き込みと読み込みも出来るんだ。
> と気づいたときに、

> ああ、これを一つのオブジェクトとしてとらえるとすっきりするな。
ここでいう、「これ」っていうのは、「論理デバイス」のことですよね？
(一応確認)

> オブジェクトが持つ特性だけに着目して作り置きしておくことが
> 出来ることです。（まあ、でも、これは、全体の中のごく一部なんだけどね）
たとえば、perlだとjcode.pmとか、DelphiだとTEditだったりとか
そういう物を差しているんでしょうか。

>>206
> Amount とか SortAlgorithm みたいな抽象物かもしれない。
sortをオブジェクト化したという例で考えてみると、例えば
逆順でソートするかどうかを意味するようなreverseプロパティが設定できるように
してみたりとか、そういう事ですかねぇ。

>>209
ごめんなさい。隠蔽も継承もよく分かってません。
さっきもウェブで調べてドキュメント読んだんですが、理解不能でした(^-^;

>>216
それだと、構造体でも大差ないように感じるのですが、
どうなんでしょう。

>>222
プログラミングする時に見通しが付き易いのがOOのメリットっていうことですか。

>>223
寝てないよ〜。ウェブとかも見て、調べながら書いてるし、
レスつくの早いから書き込めないのです。(^-^;

>>225
> 俺は３日でアプリ完成まで行ったけどね。

3日で hello world を書いたのか。それはびっくり。
もう二度と来るなよ。


さて、「とりあえず動くものを作るまでの時間」は OO と非 OO で
どちらが長いと思う?＞ALL 俺の場合は OO 歴が浅いので、設計に
時間がかかるから、現在は 非 OO の方が早く完成させられる。
慣れてくると OO でもそこそこ早く作れるものなの?

# 完成後の保守性とか、作成中の仕様変更などは考えないものとして。

Ｃ＋＋コンパイラでもＣのまま作れるしな。３日でつくれるなら、まだ
それほど深入りはしてなさそう。とあおってみるテスト。

結局
> わざわざ答えた方の回答に対して、すべてお前なりの意見をつけろ。

> 君はどんな言語使ってんの？

>> ちなみに何が「マルチメディア」なのか特定できないつうのも一緒ねｗ
> とは全く違う

これらには全く答える気がないのね。ならお前はとっとと寝ろ。
ついでにそのまま起きないでくれればみんな幸せ。

>>226
>sortをオブジェクト化したという例で考えてみると、例えば
>逆順でソートするかどうかを意味するようなreverseプロパティが設定できるように
>してみたりとか、そういう事ですかねぇ。
うーん。あくまでも「例えば」だね。
ReverseSort なんてオブジェクト作ってもいいんだし。

ちなみに、Property + Method + Event っていうのも一つのモデルだよ。
で、モデルと文法とは直接には関係するもんじゃない。
VB とか C# だと この PME モデルでオブジェクトを記述する文法があるけど、
C++ や Java だと直接的にはそんな文法はなく、Method のみで表現する。
じゃあ Java で PME モデルは使えないのかというとそんなことはなくて、
Java のクラスライブラリはきっちり PME モデルを使っている。
例えば、

Property Get UserName() As String
Property Let UserName(ByVal name As String)

って構文が VB にはあるけど、これを Java では、

String getUserName();
void setUserName(String name);

っていうメソッドで代替して記述する。
書き方は違えど、これはプロパティになる。

寝る前にちょこっと返事
>>226

＞> ああ、これを一つのオブジェクトとしてとらえるとすっきりするな。
＞ここでいう、「これ」っていうのは、「論理デバイス」のことですよね？

そういうことよん。

＞> オブジェクトが持つ特性だけに着目して作り置きしておくことが
＞> 出来ることです。（まあ、でも、これは、全体の中のごく一部なんだけどね）
＞たとえば、perlだとjcode.pmとか、DelphiだとTEditだったりとか
＞そういう物を差しているんでしょうか。

そういうことよん。

> さて、「とりあえず動くものを作るまでの時間」は OO と非 OO で
> どちらが長いと思う?＞ALL

最終的にOOにするものを非OOでプロトタイプつくるのは無駄。
作りたい機能が技術的に実現可能かのテストプログラムなら非OOでつくる。
あほが３日でどうこうとか言ってたけど、２人月くらいのプログラムでも
仕様変更やメンテの可能性がまったくないなら非OOで十分な場合も多い。

OOで作った方が柔軟性が高いのでOOにするけど。
1は少なくとも職業プログラマではないようですね。

>>226
> それだと、構造体でも大差ないように感じるのですが、

C で書くなら構造体と関数になるね。もちろんそれでも書くことは
できる。

例えば Java だと、String クラスというものがある。
　http://java.sun.com/j2se/1.3/ja/docs/ja/api/java/lang/String.html
「文字列というモノ」を表すためのクラスだね。
String オブジェクトに対して行える操作は全て上記 URL に書いてある。

一方、C のような非 OO だと、文字列を表すのは char * というメモリ
領域で、strcpy, strlen, strcmp など数多くの操作関数がある。問題なのは、
「モノを表す領域 (char *)」と、それの操作関数がバラバラに記述されている
ことなのだな。これではメンテナンスしにくいし、全体の見通しも悪い。

また、char * という型がたまたま一致すれば、strcpy の引数に対して誤った
引数を渡してしまう可能性もある。一方 String クラスならば、String の
オブジェクトに対してしか文字列の操作はできない。

モノとそれに対する操作がひとまとめにできるのがオブジェクト
指向型 *言語* の利点。これはあくまで言語の特徴。

それとは別に、設計と実装の壁をなくすことができるという、
オブジェクト指向による *開発* の利点というのがある、と。

>>226
一つの方便ではあるけれど、
ソフトウェアを幾つかの装置の集まりとして捉えて、
一つの装置を一つのオブジェクトとして表現する、
というところから始めてもいいんじゃないかな？
一つの装置は幾つかの関連する機能と
自分の稼動状態を示すプロパティを持っていて、
更に周囲の装置に対する通信機能も持ってると考えてね。
そういう装置が作る小さな社会みたいなものとして
ソフトウェアの全体像を考えてみるわけ。
ここから先へ発展していかなくちゃ駄目なんだけど、
スタート地点としてはまあいいんじゃないかと。

1の人の意見に僕個人の趣味は合致。って1の文しか見ないで書くけど（笑）
どーでも良いけど、無茶苦茶書きこみ速いのは何故？
yahoo検索であさってて・・・
「作る人の味方」ってほむぺを参考にオブジェクト指向を真似てみた。
で、疲れた。そんだけ。職場等の実態はイマダニさっぱり不明。

>>232
てことは、OO の設計に慣れた人でも、とりあえずモノを作るだけなら
非 OO の方が早くできる、って結論でよい?

もちろん仕様変更は起こりうるし、メンテもしなくちゃいけないから、
本番では OO を使うよ。

>>230
う〜ん。やはりこれだけだと、構造体が関数・データの両方を
持てるようになっただけ、以上のメリットが感じられないです。

でも、PMEモデルに縛られないってことは、自分で全く新しいモデルを
創造して自由にかく事も出来るって事ですか。(それがいいかどうかは別として)

プログラミングのずいぶん根幹部分に関っているんですねぇ。<OO

1はイタイ人と同じ思考能力だったということで解決w

>>236
俺の意見も追加させて。
最終的なロジックが見えてるなら非OOで書く方が早い。
それが見えないんだったら分析と実装が重なっているOOの方が早い。

>>235
だから、1人で作るだけなら OO のメリットは薄れるから
非 OO でもいいんじゃない、って言ってるじゃん。

「天才プログラマ発見」スレ以外に書き込むなら、もちょっと
マトモな日本語書こうよ。まぁ、あのスレに比べたら電波色は
かなり薄れてはいるけど。

>>239
thanks. 勉強になります。

>>233
ほほー。なんとなく分かって来た気がする。
たしかに、OOと非OOで出来上がったもので比較すれば
OOの方が分かり易そうな物ができそうです。

>>236
そもそもOOPでつくる「とりあえず動く物」って、
「各クラスをインスタンス化してメッセージのやりとりがとりあえずできる物」
じゃないの？各メッセージを受け取った後の処理は丁寧に実装するけど。

「とりあえず動く物」じゃなくて「お客さんに見せるだけの画面遷移」なら
HTMLで書いたりDelphiでさっくり作っちゃうからOOは意識しない。
DelphiやVBでボタンとかOnClickイベントとかがすでにOOの恩恵であるけど。

徒歩と飛行機みたいなもんだな。飛行場までいくのが手間だから、徒歩で行きましょうと。
すきなだけ歩いてクレよ。

>>237
オブジェクト指向は自由だよ。そこが長短両方に繋がってる。
自由度を生かしてメリットを引き出すのも、
引き締めができなくてわけわかになるのも、
どちらもプログラマの能力次第。

コーディング作業上の直接的なメリットってのは
あまり期待しない方がいいと思うな。
俺の場合の話だけど、ある程度の規模にならないと
OOやっててよかったっていう実感は沸かない。
細かなロジックはどうでもよくて、
ソフトの全体構造を決めることが一番重要な問題であるとき、
OOしてるおかげで抽象的な概念だけ考えてればいいっていうのが
すごく嬉しい。ロジックレベルではコードが自然言語の文に
近くなるってのが嬉しいぐらいだけど、それは別にOOじゃなくても
構造化プログラミングでだって実現できる。
やっぱ、脳味噌が楽だってのがでかいよ。

>>234
具体性があるので、イメージし易いですね。
「サブルーチン」をもっと大きなものに拡張して行った感じですかね。

>>246
大切なのはコミュニケーションを意識するというところ。
オブジェクト同士がそれぞれに関係を持っていて、
その関係の中で情報交換をしあうというイメージが大切。
一本道の処理の流れを考えるんじゃなくて、
それぞれが自分の仕事を行う職人の集まる工場として
全体をイメージしてみるといいと思う。
バケツリレーじゃなくて並列した協調作業ね。
オブジェクト指向って並列処理チックな感覚があるよ。

>166
> 構造体が関数・データの両方を持てる

やろうと思えばCで関数ポインタ使ってできるけどね。
それは実装の一例でしかないので、それだけがメリットなわけじゃない。
プログラムを機能とデータの集まりで作っていたのが、オブジェクトと
関連で作るように変わるので、プログラミングの概念から全然変わる。

といってもここでうだうだ質問しててもイメージわかないと思うから、
経験を積むしかないよ。ポインタを初めて勉強したときだって、理屈は
わかっても「じゃあどういう時に使うべきなの？」って想像するの
難しかったでしょ？ましてやポインタのポインタなんて「使うこと
あるんだろうか」とか考えたでしょ。でも現場はいったらそんなこと
理解してるのが前提で応用することを要求される。

訂正
>>243
○ 処理は丁寧に実装するけど。
× 処理は後で丁寧に実装する。

>>243
んとね、OO 経験が浅いオレは、何をクラスにするか、どういう名前にするか、
ということを考えるのに時間がかかるのね。

非 OO なら適当にやりたい処理を順番に書いていって、複数箇所に同じ処理が
でてくるようなら、その部分を関数に昇格させる、と。

OO に慣れたら、何をクラスにするかを決めるのにほとんど時間がかからない
のかなと思って質問してみました。

OOでは、オブジェクト同士の関係が重要だということみたいですが、
ここでいう関係ってどういうことなんでしょう。。

>>246
> 「サブルーチン」をもっと大きなものに拡張して行った感じですかね。

これが危険。130さんが言ってくれてるけど、オブジェクト同士の関連を意識した
プログラム作りになるので、「サブルーチン」のように「処理のまとまり」を
拡張するのとは本質的に異なる。

これを勘違いしたままだと、OOPLを手続き型言語の機能拡張版ととらえてしまう。

OOPL = オブジェクト指向プログラミング言語

Smalltalk や MAX+plus II なんかを使ってみると楽。
一度作ったモジュールはそのまま張り付けるだけみたいなかんじ。
C++ には File Scope を設けるべきだったという論もある。
C++ で OO をするのは慣れるまでは大変かと…

>>240

むしろ個人で作るときのほうが非ＯＯよりＯＯ
の方が楽っぽい気もするけど・・・どうなん？
他人の力を借り易そうだし・・・。
>238
1は痛い人というか、僕潰し派のにおいも
しますけど。やたら文面似せてるし。

これで寝るけど、
歴史的に見た場合、プログラミング言語の発展過程で
何がコアだったのかっていうとソフトウェアのアーキテクチャに
関するノウハウが言語に反映されてきたってことだと思う。
自己書き換えも当たり前だったアセンブラが
手続き型の時代には確定した手順の羅列になり、
構造化の時代には関数単位でのツリー構造になり、
OOP言語の時代にはオブジェクト単位での緩やかな集合体になった、と。
そういう風な変化はそうすることにメリットがあると
考えられたから起こってきたわけで、
その根本にあるのはコンピュータが社会に浸透して
ソフトウェアに対する要求とソフトの規模とが拡大した
のに追随しなければならないという背景だと思う。
実際、でかいもの作るときほどOOはありがたいし、
小物作るんだったら手続き型の方が楽でいい。
大きな規模のソフトを作って実践してみたら分かると思うな。
148 さんも言ってたように実践してみるといいだろうね。

じゃ、おやすみ〜。

OOわかっていてもプログラムが汚いやつ、
構造化ができていない奴は逝ってよし！と言いたくなる。

>>250
えっと、じゃ結局「画面だけのサンプル」じゃなくて本当に
「とりあえず動く物」なのね？

非OOの方がはやいかどうかは規模次第だね。小規模なら非OOの
方が早いというだけで、「とりあえず動く物」だから非OOの方が
早いというわけではありません。

でも非OOでつくったものは、部分的に関数をなんらかのクラスの操作に
変えることができるかもしれないけど、プロトタイプ作成の工程自体が
無駄なのでやりません。

徒歩で速いときも、もちろんある。

>>247
ooと並列処理を一緒にするのは変。

どうも、いろいろ答えてくれてありがとう。
かなり勉強になりました。

それで、結論ですけれど、オブジェクト指向型言語っていうのは、
ソフトウェアを個々のパーツごとに作れるように拡張された言語で、
そのような拡張を実現するために、PMEに縛られないモデルを作れたりなど
そういう自由度が高く設定されているっていう解釈でOKですか。

>>251 166さん
> OOでは、オブジェクト同士の関係が重要だということみたいですが、
> ここでいう関係ってどういうことなんでしょう。。

たとえば、野球県プログラムを、
「宴会場」「おじさん」「コンパニオン」「審判」という
モデルでプログラムするとすると、
・各クラスのインスタンス化
・宴会場へみんなが入場　←　宴会場と人との関連
・審判が号令　←　審判からおじさんとコンパニオンへの関連
・二人がじゃんけんをする　←二人から審判への関連
・審判が勝敗判定してコンパニオンに「負け」に通知　←審判からコンパニオンへの関連
・コンパニオンが脱ぐ　←　コンパニオンクラスに実装されｔる「脱ぐ」関数の実行

ってな感じかな
おれもねるか

だいぶ分かって来たんで、あとは、実際プログラム組んで
勉強してみたいと思います。てことで。ネます。

相手してくれた方どうもありがと〜。

>>259
並列処理「チック」ね(藁
並列処理まんまで意識しちゃいないよ。
一本道のフローをベースに考えるのではない
っていうことを強調したかったからああ書いた。
大目に見てね。

>>260
オブジェクト指向は方法論であって、
オブジェクト指向プログラミング言語はその方法論に沿った
表現が容易な言語。これが基本。これは 99 さんの発言の通り。

今一般的なオブジェクト指向プログラミング言語の特徴は、
オブジェクトを記述する文法が整備されているということ。
何を持って文法概念上のオブジェクトとするのかは言語によって違う。
VB、C#、ObjectPascal などでは PME モデルがベース。
C++、Java などではメソッドオンリーのモデルがベース。
共通しているのは、データとそのデータに対する処理を一体化できる、
ということぐらいで、これをOOP言語の特徴として解説する場合が多い。
ただし、それはOOP「言語」の特徴であって必ずしもOOPの特徴ではない。

OOPの特徴は対象把握の仕方を制約しないということにある。
OOP言語はその把握の仕方のある種のパターンを文法に織り込んだものに過ぎない。
非OOP言語でもOOP流の対象把握にそってプログラムを書くことはできる。
この時、非OOP言語でOOPしてることになる。

上っ面だけだけどまとめるとこんなところ。
今度こそ寝る(藁

>>263
ooの本質とは離れている気がするよ。
なんかカプセル化を意識しすぎというか。。。

十時間で260レス超・・・

>>261
野球拳のモデリング的には、

参加者というクラスがあって
脱ぐ と ジャンケン というメソッド
衣類の状態(または枚数?) という属性
があれば本質的に十分だと思うが。

いろいろ、思いつくこともあるだろうけど、
「本質的に」欠かせない概念だけ残すのがポイント

>>264
んじゃ何が本質だ？

>>1
OOが理解できなかったから、教えて欲しかったんだろ？
あと、ついでにマルチメディアの意味もいまだに解ってないんだろ？
だったらそう書けよ。教えないけど。

例えば、ある人はある程度規模がでかくないとOOは非効率という。
ある人は規模に関係なく工程を短縮するという。
ある人は継承が本質という、ある人はカプセル化が本質という。
てんでバラバラ。よってオブジェクト指向逝って良し！

だいたい方法論が先にあって、言語が後みたいな
言い方してるけど、そこからして大嘘じゃん

モデルの作り方と、表現の仕方は表裏一体だとおもうけど、
どのへんが大嘘なの？単に君の認識不足では？

継承がＯＯの本質だと考えるバカが消えたことに安堵を憶える。

このスレは１３０がいるから安心。１も結構判っている奴だな。ただそれだけ。

>>269
バラバラじゃなくて、どれもOOの側面を言ってる。
> オブジェクト指向逝って良し！
って思うのは勝手だけど、そんなに喧嘩ごしで主張することないじゃん。
269はそんなにみんなで仕事したとかそういう経験がないだけなんだと思うよ。
別にOOPできなくても、気にすることないよ。

>>270
どうして大嘘だと思うの？

初心者がはなっからオブジェクト指向言語ってのはどうかと。
ついてけなくなる子が出てきちゃうんじゃないかなぁ。
せめてC、できればCに似たような感じの仕様でインタプリタ形式のやつが
フリーであれば一番いいような気がする。
今となってはBASICのGoto命令は教育上よろしくないしな（ｗ

なによりも、「自分がパソコンを動かせた」っていう感覚を持ってもらうのが大切かと。
簡単なことはほんとに簡単にできて、凝って行けば難しいことも出来るってのが入門用としては理想だと思う。

つーか、言語なんてツールなんだから
用途によって使い分ければ良いじゃん。
OOがどんなケースにも万能だなんて誰も書いてないだろ。

あと、継承の話があったけど、
継承が使えるということと、
継承できる場合は全部継承で解決する、ということは違う。
これも、ケースによって使い分ければいいだけの話。

ついでに、1はバカ

>>274
Objective-Cでもだめなのかなぁ。解説本がないっか。。。
でも、C++より、全然シンプルだし。

>>275 は電波
だれが言語の話をした？

お前　なんかとまともに話そうとしてるやつは１人も居ないよ。相手してもらってるつもりだったらお前の勘違い。全部ネタレス。お前にゃわからんだろうが。

これからオブジェクト指向言語を習得しようとする人への
アドバイスだ。

オブジェクト指向言語を速く習得したかったら、言語だけ見て
オブジェクト指向なんぞ忘れろ。
C++ならクラス、継承、カプセル化、などが判れば問題無し。

逆に「オブジェクト指向」の説明は電波だから一切無視してよし。

オブジェクト指向の三大要素
・継承--------逝ってよし！！
・多態性------激しく逝ってよし！！
・カプセル化--使えるのはこれだけ。

>>264
166 さん向けの「スタート地点」としての説明だよ。
俺の OO 観を語ってるわけじゃない。

>>269
統一的見解がなけりゃ逝ってよしってのは乱暴じゃない？
構造化プログラミングであっても解釈は一つじゃないよ？

>>270
歴史上の時間順序を見ればそれは正解。
オブジェクト指向ってのは後知恵的に整理されて出てきた概念。
だけどOOPが先にあってOOP言語は手段の一つに過ぎないと
位置付けることでOOP言語の文法概念に制約されずに
OOPの自由度を高められるんだからこういう論法も捨てたもんじゃない。

>>272
俺よりも 148 さんの説明をよく読む方がいいと思うよ。
俺、どうも理解がイメージ主体でいい加減だ(藁

ところでAgent指向とか並列オブジェクト指向とか呼ばれるもののこと知ってる?>誰となく

でもなー、
VBで設計と実装を同時にしているような
連中にOOなんて理解できうも無さそうだし、
ていうか
>>279 は実際に仕事に反映できない
という僻みがはいっているな。

>>282
並列オブジェクト指向ってのは聞いたことないなぁ。
エージェント指向は名前だけ。
エージェントってのが今ひとつよく分からない。
とりあえずプログラムが実行状態つきで
マシンバウンダリ越えて移動するというのが特徴らしいけど
詳しいことは知らない。

ここって日本語理解できない奴多いな。
全然話がかみ合ってない。
こりゃ絶望的だな。

>>279
言語から入ってOOPを学ぶっていうのなら賛成だけどね。
俺自身、C++初めてから４年ぐらい経験つまないと
あ、俺今OOPしてるなってな感覚は身に付かなかった。
もちろんクラスだの継承だの多態だのは
それまでにもがんがん使っていても、だよ。

>>285
お前には難しすぎたようだな。積木からやりなおしな

>>281

130さんのoo観が知りたいな。

私はこんな感じ。

ooで最も意識しなければいけないのは、再利用性。
カプセル化は基礎的なもの。
コンポジションで置き換える方が出来るような継承は悪。

ooエンジニア(設計以下)には、これらは必須。
・アーキテクチャパターン
・デザインパターン
・リファクタリング
・各言語イディオム
・UML(道具として)。

これでやっとooの恩恵が得られる気がするよ。

>>288
対象を空間的なイメージで捉えて
空間上の領域の相互作用の総体として
全体が形成されると考えること、が俺にとっての OO。
この場合の空間っていうのは物理的な広がりのそれに限定しない。
非常にイメージ的だけど、実際こう思ってる(藁

実装や設計作業を踏まえた上での OO の実践としては
259 さんの意見とほぼ同様。扱うものが抽象的だから
語彙を業界内でどんどん共有しないとコミュニケーションできないし
そもそもそうやって共有することで再利用が進むわけだからね。

ただ、それをやらないと OO の恩恵がないかっていうとそれには同意できない。
これは極論なんだけど、アセンブラで書くことを前提にして
OO せずに巨大で複雑なソフトの設計やれって言われてできる？
大きなものの設計能力ってのが OO の最大の恩恵だと思う。
これはツールやパターンがなくても実感できると思うな。

agentは自立的に動作するオブジェクト。
この世界ではメソッド呼び出しとは呼ばない。この辺調べれば>>247後半あたりが
妙であることがわかるのでは?とね。

>>290
だったらエージェント的なことって割と普通なのかもね。
システムを幾つかのプロセスに分けて
プロセス間通信やったりするのってそれっぽくない？
俺はこういうのも OO の一環として捉えてる。

>>291
コンポーネント指向？（って最近聞かない・・・）

オブジェクト指向ってなんですか？

Tk

>>1
つまり１は抽象的な概念を理解することができないようだ。
そうだろ？１

>>293
新言語を売るためのキャッチフレーズです。

>>296
Javaの習得に失敗したクチですか？

>>289

ooの恩恵は、開発効率もあるが、
再利用とか、拡張性とか、メンテナンス性の方がさらに重要だとおもうがどうか。
言いたいのは、
再利用を高めるために、
カプセル化というのは、ほんのわずかな意味でしかないということ。
クラス間の依存度とか、どう抽象化するのか
というのが再利用につながるとおもうよ。

>>295
抽象的な概念というのと抽象的にしか理解してないというのは
ちがうよ　藁

abstract class Heapを継承した、
MaximumHeap, MinimumHeapクラスを作って喜びました。
OOP?

>>1
１は、結局OOのメリットとされているものすら解らなかったんだろう？
１がOOを他人に教えることになったら、どう説明すんの？
ひたすらサンプルコード見せるのか？

「魚を与えるより、魚釣りの仕方を教えろ」って諺があるだろ？
コードの説明をする前に、概念についてしっかり理解しておくのが大事なんだよ。
結局それがOO言語の習得の早道なわけ。
もしOOの概念がわからないなら、OO言語はマスター不能。

参考書読んで訳わかんなくなってる人への説明。

オブジェクト指向のオブジェクトとはプログラムの操作対照となる
データ−やI/Oの事。

全てのプログラムはつまるところ、データ−やI/Oを操作する事しか
していないので、設計の段階から扱うデータ−やI/Oに注目し、
それに関数を張り付れば完成という考え方が本来の考え。
それ以上でもそれ以下でもない。

オブジェクト指向の信者によって、効率とは無縁なところで概念の
拡張が計られ、また、マルチメディアがそうであったように、
（携帯電話、CD,文字放送もマルチメディアだと言っていた）
従来からある手法や概念までオブジェクト指向の一部と主張して
いるのは単なる宣伝に過ぎない。

対象となるデータ−の無いルーチン
（ループによる時間待ちルーチンやHALT）はもちろんオブジェクト
指向では扱う事ができない。

俺が初めてOO言語を知ったときは
「なんて便利なんだ!」って感動したけどな〜。
なんでOOが不要だと思う人がいるのかがよくわからん。

俺の組んでるプログラムが特殊なのか・・・?

信者とアンチはウラハラの関係で、どっちもバカ

最初のころ、
関数（構造体）；
とするのを
構造体．関数（）；
と形式的に書き換えてるだけじゃんって思った。
何がありがたいんだろうって。

>>303
宣伝とは裏腹に効率悪いから。
無理に何が何でもオブジェクト指向化すると
C++のCStringみたいに効率落ちてイライラするだけ。

>>302=1
>参考書読んで訳わかんなくなってる人への説明。
参考書が訳わからん解説してることが多いのには同意するが(笑)

>オブジェクト指向のオブジェクトとはプログラムの操作対照となる
>データ−やI/Oの事。
「自分自身のデーターの扱い方を知っている変数」ぐらいの方がいいだろう。
オブジェクトの使用者はオブジェクトの中にどんなデータが入っているかしらなくても
メソッド呼び出しという形でデータを扱えるというのがオブジェクト。

CのFILE構造体なんかがそれに近いな。
FILE構造体の中身を知らなくてもfopen()やfprintf()なんかで
扱えるよな?

>対象となるデータ−の無いルーチン
>（ループによる時間待ちルーチンやHALT）はもちろんオブジェクト
>指向では扱う事ができない。
それはオブジェクトの行うべき動作なので、
メソッドの中に実装するんじゃないかな?

>>306
それは単にCStringクラスの実装がアホだからじゃないの？

>>298
俺、別にカプセル化にこだわったつもりないんだけど(藁
再利用性は確かに大きい。でもメインだとは思ってないなぁ。
構造化プログラミングの時代から再利用はがんがんやってたし、
その時に比べて再利用度が上がったかというと今のところそういう実感はない。
これはこれから先ずっと続けていけばまた変わってくるかな？
拡張性やメンテナンス性が重要というのは同意。
なんにしても、何が最大の恩恵か、という話はあまり考えたことない。
おいしいところは全部使えばいいんだからさ(藁

>306=1
効率っていうのは実行の効率のこと?
作成の効率と実行の効率をごっちゃにしてはいけませんぜ。

OOは作成の効率を上げるものであって実行の効率を上げるものではない。

>305
それだけだとたしかにたいして嬉しくないけど、
規模が大きくなるといろいろと嬉しいことがあったりする。

オブジェクトとは役割を一まとめにしたもの、と言っとこう。
一概にデータ中心とは言えません。
メンテナンスの単位(区切り)を明確にすることでメンテナンス性(+可読性/利便性)を上げる。
役割の独立性が高ければ*おまけとして*再利用性も上がる。ﾊｲﾂｷﾞﾄﾞｰｿﾞ

利点を理解していない上に、はなっから否定する事しか
考えていない石頭に、文章で説明しても、どうせ聞く
つもり無いから無駄なんじゃないの？このスレ。

>>302
>オブジェクト指向の信者によって、効率とは無縁なところで概念の
>拡張が計られ、また、マルチメディアがそうであったように、
>（携帯電話、CD,文字放送もマルチメディアだと言っていた）
>従来からある手法や概念までオブジェクト指向の一部と主張して
>いるのは単なる宣伝に過ぎない。

これ、根本的に乱暴な考え方が根底にあると思うよ。
新しい技術っていうのは常に既存のものにはない要素「だけを」
追加しなくっちゃいけないと言ってるように聞こえる。
過去の資産を統合、再整理する技術だってあるわけじゃない。

1 さんの周囲に何でもOOPだって言い張るバカがいるなら
そりゃ叩いてやりゃいいけどさ、
OOPだってソフトを作るツールの一つに過ぎないんだから
OOPvs非OOPみたいな構図でとらえるのがそもそも間違いだよ。
使って便利なものを使えばそれで十分。

>>307
「自分自身の〜」って表現はよくあるけど、あれはよくないね。
そもそも「変数」という概念自体が微妙に間違ってるからね。
クラス＝構造体＋関数 という発想も正しくはない。

サービスを主体的に行う「なにか」がオブジェクトであり、
オブジェクトが、どんな状態をもち、
どういうメッセージに対してどんな振る舞いをするか、
という、オブジェクトの性質を規定したものがクラス。

なんていっても、馬鹿にはわかんねーだろうな。

オブジェクト指向の最大の欠点は、馬鹿にも高度な抽象化能力を
要求することだと思うね。よってオブジェクト指向逝ってよし！

>> 43
これって具体的にどんなふうに、コーディングしてます？
参考文献とかポインタがあれば、きぼーん

>>313
一個自分の経験を追加。
一時C++マンセーな状態になって片っ端からクラス化して
やろうって意気込んでた時期があったんだけど、
あの時はかえって作業効率落ちたね。
クラスにするメリットのないようなものまでクラスにしてたから。
だいぶ量をこなすようになってから、
クラスのねじくぎにあたるものは別に関数でもいいじゃん、
って思えるようになって、
それ以後は作業効率がぐんと上がった。
全てがオブジェクト、というのは理想かもしれないけど
実装レベルですぐにそれが実現できるようなもんでないのは確か。
仕事となればなおのこと現実に即した判断が必要だね。

ソフトウェア設計がきちんとできないやつには、OOPは危険なおもちゃ。

Java/Ruby位になれば厨房に対しても非OOLよりはましでは?

>>310
もちろん作成の効率のこと。

>>312
別にオブジェクト指向でなくても（役割別に？）ソースファイルは
分けて書きますし。

オブジェクト指向プログラミングは暗黙のうちに将来のメンテナンス
の為の選好投資分を含んでいるからその分効率が落ちる。
選好投資分以上のものが将来回収できるなら、オブジェクト指向は
効率が良いと言えるでしょう。
しかし、メンテナンスでのアクセス関数の修正は全体の１％ぐらい
じゃないかな？
それ以外の関数はオブジェクト指向でなくても作るから関係ないし。

オブジェクト指向から外れるけど、
可読性は理論としては判るけど、実際のプログラムでは
基本クラスならともかく、多重継承しているような上位の奴だと
やっぱ、特に判りやすいと言う事は無いんじゃない？

>>314
微妙に間違っているのはわかってます。
でも正確さを重視して解説すると妙に抽象的な説明にならざるを得ないんで。

>オブジェクト指向の最大の欠点は、馬鹿にも高度な抽象化能力を
>要求することだと思うね。よってオブジェクト指向逝ってよし！
う〜ん・・・。
これは「馬鹿逝ってよし!」とすべきでは。
理解している人が使えば効率が上るのもまた事実。
(でも現実の作業で馬鹿排除とはいかないしなぁ・・・)

>>318
同意。

>>319
将来のメンテナンスのための先行投資、と言うけれど、
開発プロセス自体が一種のメンテナンス作業だと思う。
お客さんからの仕様変更なんて日常茶飯事なわけで、
納品してからの仕様変更がどうというよりも、
開発の真っ最中の仕様変更に対する強さがあると思う。
実際、納品後の改訂作業で救われたって思うことよりも
開発途中で初期段階にこうしててよかったって
思うことの方が圧倒的に多い。

>>314
参考書読んで訳判らなくなってる人にそんな説明するんだ。

そうか、オブジェクトってのは主体的にサービスを行っちゃうもの
なのか。
そんな高度な抽象的概念は私には理解できませんなー。
私はてっきり、メンバー関数を呼び出したから動いてるのかと
思いましたよ。

思いましたよ＞思ってましたよ

>>323
だから、馬鹿には理解できないんだってば。

>>1
作成の効率ですか?
>>1殿はよほどOOとの相性の良くないプログラムを
組んでいるのでしょうな・・・

>>323=1
「こういう動作をしろという命令をする」＝「関数呼び出し」
「自主的にサービスを行う」＝「関数がオブジェクト自身のメンバその他を操作する」
抽象的概念云々という>>314の主張通りか。

あと、クラスライブラリを作るやつと使うやつを区別しないとね。
厨房にはライブラリは作れません。
でもOOじゃなければどうかというと、状態を持たない関数群なら
厨房でも作れるでしょうけど、状態やコレクションを管理する
抽象化された関数ライブラリは、やはり厨房にはまともなもの
は作れないでしょう。
ライブラリを使うときはOOなほうが誰にとってもやりやすいでしょう。
非OOでは関数ライブラリにインスタンスという概念を持ち込む必要性が
あるときにやっぱ苦しいし。そんなわけで分かってないやつに対しても
OOは意義があるということでよいですか?(藁

じゃあ、１は使う奴になればいいってことで、
そろそろ終了かな。

皆自分を表明してるみたいだから一応(藁
>そうか、オブジェクトってのは主体的にサービスを行っちゃうもの
>なのか
主体的にサービスって何?
一般にサービスってのはクライアントからの要求があってそれに答えること
だから、主体的ってのは良くわかんないぞ(藁

>>99-101
が結論でいいんじゃないかな。すごくまとまっている。
自分の言葉でここまで書ける>>99-101さんはすごい。
他の番号でも書いていたら教えてね、>>99-101さん。

>>330
私も良く書けてると思う。

>>330
>>113

>>332 工学的なセンスのある人なんだよ。
新米かどうかは関係無い。


「主体的サービス」の返事が来ないな−。
オブジェクト指向信者が、つい唱えてしまった呪文の言葉を聞けた
のになあー。

>>333
信者のあぶり出しが目的？
で、OOPそのものは問題視してない？
根性悪ぅ〜(藁

>>1
いいから死ねって。

>>1
まず、おまえがオブジェクト指向が従来の手続き型言語
にくらべて、どういうところがダメで必要ないと思った
のかを具体的に説明しろ。

>>330 >>331
99-101 です。
お褒めをいただきありがとうございます。
実務経験が浅くまだまだ未熟ですので、
これからも勉強を続けていきたいと思います。
ちなみに、今回が初書き込みです＾＾；

>>333=1
クライアントはサーバーのすべき作業を知らなくてもいいっていうことだよ。

ありきたりな例だけどオブジェクトとしてエレベーターを考える。
クライアントは壁のスイッチを押してエレベーターを呼ぶ(＝「メソッド呼び出し」)。
するとエレベーターは
主体的に現在自分のいる階を調べ、
主体的にどこの階にクライアントがいるか調べ、
主体的にクライアントの階に移動する。
(もちろんここでもエレベーターを作る人とエレベーターを使う人は別。)

こんなんでいいかい?

>>1 のマウントポジションを取って、心行くまで
顔面をえぐるようにパンチを入れまくりたい。

>>337
プログラマーとしてはそうなのかも知れませんが、
システム工学あたりをやられていたみたいな感じですね。
がんばってください。

なんとなく前半読んじゃったよ(藁。なるほど1はあるていどわかってて、
解ってないのに解ってると思い込んでるやつをあぶり出そうとしてるわけだ。
ある程度成功してるね。(藁
# でも、やっぱり「ある程度」みたいだけど(藁
ところでBean/JSP/ServletをMVCとよく言うけど、漏れはこれはMVC本来の
意図を反映しきれていないと思うんだけど、MVCって何?って聞くと「これの
事だよ」って言う人多いね。
MVCの利点って何?(藁

>対象となるデータ−の無いルーチン
>（ループによる時間待ちルーチンやHALT）はもちろんオブジェクト
>指向では扱う事ができない。

ループで待つのは誰なのか？
HALTは誰から誰にメッセージを送るのか？
この「誰か」を明確にして、送る人の責任、受ける人の責任を明確にするのがオブジェクト指向。
その誰かが必ずしもデータを所有している必要はありません。

誰かが時間を待つなら、その誰かが時間を待つ処理を持てばいい。
時間の正確さについては、その誰かが責任を持つ。

多くのものに同じ処理を記述するのが無駄だと思うなら、
時間管理者を作り、待ちたいときは彼に処理を委託するようにします。
時間の正確さは委託された時間管理者が責任を持ちます。
タイマーのカウンタ変数の更新も時間管理者が責任を持って管理します。

オブジェクト指向が優秀とされ、生産性があがると言われているのは、
コードの再利用性よりも責任の所在が明確になることのほうが大きいのです。
構造化では処理に対する責任が曖昧だから、仕様やコードのデバッグに苦労します。
そういう苦労を少しでも抑えて楽をしたいからオブジェクト指向を使うのです。
そんな苦労とは無縁だと言うのなら、オブジェクト指向なんて要りません。

オブジェクト指向を取り入れて失敗したと考えている人は
コードの再利用にばかり目が行っているでしょう。
メッセージをオブジェクトに送るのは、処理の流れを作るだけではありません。
オブジェクトの責任が重くなったら、複数のオブジェクトに責任を分散させます。
自分（オブジェクト）が責任を取れない処理はしない。
こうして各オブジェクトが受け持つ責任を軽くしておけば、
自ずと単純で明快なクラスの集合となり、クラスのメンテが楽になるのです。
クラス分けは、データを単位として行うのではなく、責任を単位として行うのです。

オブジェクトの協調動作には難しい面があることも事実です。
それを補うために、UMLといったモデリング技術や、デザインパターンのようなものが必要になってきます。
でもこれはオブジェクト指向の欠点ではありません。
構造化にも同じ問題があるのですが、誰も問題を具体的に把握できなかっただけ。

>>338
単なるサブルーチンでも同じ事するが？

>>341
そうか？俺も読み返してみたが、1はオブジェクト指向が
理解できずに、わめいているだけだと思ったが。。。
で、煽るだけ煽って人の質問には答えずに、アゲアシ
取りしかしていないようなのだが。。。

>>>332 工学的なセンスのある人なんだよ。
>新米かどうかは関係無い。

確かに言ってることは間違ってはいない。けど、これで知らない人に納得させられる?
1はこういう抽象的な記述を嫌ってたはずなのになぜ賛辞してるの?
1さん質問に答えてね(藁

>>343=1
そう。同じ。
で、なにが疑問なの?

＞３４１
おお、出てきた。１の思惑は当たった。

>>344
>>341=>>1

>>342
かなり当を得た見解だと思う。
責任の明確化ね。確かにそう言えるなぁ。
勉強になった。サンキュ

1の実力はともかくとしてわかってない人が多いのはあたり。
1も同じ(藁

>>349
追記。
責任の明確化っていうのは当を得ていると思うけど、
責任関係の前提にまだ何かモデルが隠れてるようにも思った。
当事者を想定するような・・・うーん。表現しにくい。
ただ単に責任っていうだけじゃないと思うな。

まとめると「憂鬱な〜」を読めということだな。

ああ、ごめん
>なんとなく前半読んじゃったよ(藁。なるほど1はあるていどわかってて、
>解ってないのに解ってると思い込んでるやつをあぶり出そうとしてるわけだ。
>ある程度成功してるね。(藁
># でも、やっぱり「ある程度」みたいだけど(藁
この「ある程度」なのは1の理解度の話だから

>>351
一人でツボにハマってるんだけど(藁
例えばOSの階層構造を考えてみると各階層ごとに責任がはっきりしてる。
じゃあOSはOOっぽいか？あんまりそういう風な感じはしない。
単に責任というだけでは足りないなと思うのはこういうところ。
一体何がOOくささなんだろう・・・。

>>334
これ以上オブジェクト指向マンセーを大きくしたらマズイのでやってます。
マッカーシー旋風みたいなものか。

>>346
かわされたか。
では
＞メッセージに対してどんな振る舞いをするか、
＞という、オブジェクトの性質を規定したものがクラス。

メッセージってなんのこと？

うるせえ。

>>1 は、なんでこれだけ批判されてるにもかかわらず、
その批判は無視して厚顔無恥にも投稿できるんだろうか。。。

>>354
レイヤー単位で考えるとOOっぽくないけど
ドライバやサービス、アプリなんかのインスタンス単位で
考えるとOOっぽさが出てくるような気がする。
責任に加えて協調という概念も必要じゃないかと思える。

>>349
前提があるとすれば、それは情報隠蔽やカプセル化かな。
オブジェクト指向を解説する人は、情報隠蔽のことばかり話して、
なぜ隠蔽しないといけないか（責任を明確にするため）を話さないから、
「データの所有者を明確にするだけ」「データの更新だけに責任を持てばいい」
と誤解してしまうのだと思います。
実際に責任を持たなければならないのは、
そのオブジェクトに対して与えられた使命に対してであり、
それを全うするためにデータやメセッドを「持つ」わけです。
だからクラスにはデータメンバとメソッドメンバがあると。

>>357
教えてクンじゃシカトされるから、
煽って教えてもらおうと思ってんだよ。
だから１の狙い通り

>>1
>これ以上オブジェクト指向マンセーを大きくしたらマズイのでやってます。

リストラ対象か

>>357
いいんだよ。1 はネタ提供マシーンだと思っておけばよい。

俺も「わかっているけどあえて質問して相手の理解力を計る、
相手に考えさせる」ことはよくあるけど、1のは OO を批判
するという確固たる (そしてアホらしい) 信念があって、
そのためによくわかってない奴を探そうとしているだけだから。

>>355=1
SmallTalk用語。＜メッセージ
OOを語る上で良く出る用語。
本質的にはC++のメンバ関数呼び出しと同じ。
(もっとも、SmallTalkは使ったこと無いんですが。)

>>359
いや、そういう話ではなくて、
責任の明確化＝オブジェクト指向、隠蔽その他はその手段、
というだけでは概念的に不足しているな、と思ってしまう。
責任の明確化だけで終わるなら、極端な話、
ソフト一本の責任を外部仕様で明確化すればオブジェクト指向だ、
なんて話を持ち出せなくもない。
実際にはそんなことはなくて、内部でその責任を更に分割する。
じゃあその分割ポリシーって何だろう？、ということ。
メタのレベルでOOらしい分割ポリシーがあるように思う。
それが責任あるものの「協調」という概念なのかな、と。

>>358
下手な構造だったとしても、レイヤー分けされているＯＳは
オブジェクト指向だと言っていいと思います。

どのように協調して働けばいいのかという点については、
実はオブジェクト指向を超えたところにある問題です。

そこを解決するためには、今のところ泥臭い方法しかなく、
せいぜいUMLやデザパタを使ったりする程度ですが、
そういうレベルで話をできることは
オブジェクト指向の利点の一つだと思います。

>>343
エレベーターが複数あった場合、管理がめんどくさくないかな？

責任だけでも一応OOだよ。でもレイヤをオブジェクトというには大きいねえ。
そのレイヤを担うオブジェクト群の窓口となるFacadeはいてもおかしくないけど。
違う言い方すれば、他のものへの依存を極力なくした単位を関数より大きくして、
ライブラリより小さくしたものをオブジェクトと呼んでみよう。
メンテナンスの区切り単位を一つ増やしたようなもんだね。
いまどきは協調/多態まで含めて言うけど。

>>365
そこらは感覚の違いだね。
レイヤー単位だとOOと言えなくもないとは俺も思う。
そしてそれ以上に、OOっぽさに乏しいとも思う。
あ、OOかくあるべし、という泥沼はやるつもりないんでよろしく(藁

>>368
そうだね。
ただ、オブジェクト指向だというのと、
優れた設計だというのは別物で、
オブジェクト指向だから優れているとは言えないと思う。

逆にいえば、ＯＳのモジュールを継承・汎化できて、
コンテナに格納できちゃったりなんかすると、
優れたオブジェクト指向ＯＳだとは言えるけど、
それでもWindowsを「劣ったオブジェクト指向ＯＳ」だと言うことはできるということかな。

とりあえず、OOに明確な定義はない、と。
最適粒度や凝集性なんてのもまちまちだしね。
そして今日もプログラマは悩むわけだ(藁

レイヤー単位だと、レイヤーが持つ責任が重過ぎないかい？
適度な責任ということだけでこれは説明が付きそうだけど。

>>369
そりゃ当たり前だよね。＜OOP!=優秀
そもそも何が優秀かっていう尺度が状況によってばらばらだし。
技術者である以上はなにかを盲信したら負け、ってのがある。

蒸気機関の発明はその後の熱力学の誕生と発展によって
極限まで効率を高める事ができた。
科学的思考ー現象の原理の追求は分析的な頭脳を持つ人には
当たり前のころだと思う。

分析的な頭脳を持った人なら工学上の原理を無意識にでも
追求してしまうと思う。

最初は実践的なオブジェクト思考型のプログラミング手法だけがあった。
その後、その概念を原理化、一般化しようとした一派が出てきた。
だが、この一派は現実の検証を怠るという態度を持った為に
彼らの唱える原理はしだいに現実と噛み合わなくなっていった。

オブジェクト指向の概念はソフトウエア開発の生産性、信頼性その他
に必ずしも寄与する物とは言えず、逆に障害にさえなる場合も
確認されている。

オブジェクト指向は開発手法の原理にはなり得ない。
実装面での有用性を考慮しつつ、一手段として用いるべきで、
原理としての概念の研究や原理面からの開発アプローチは
一種の擬似科学（擬似工学）とでも言うべきものだと認識している。

簡単に纏めてみた。

オブジェクト指向とは
明確な処理責任を担うオブジェクトと呼ばれるモジュールの
協調する総体として対象物(ソフトに限らない)を捉える方法論である。
なお、オブジェクトの最適な責任分担はもっぱら再利用性を目安にして判断される。

どう？＞ALL

大きさはこの際関係ないよ。オブジェクト*指向*なんだからさ。
何をオブジェクトとみなすかは多種多様。
その代わり、オブジェクトの粒度はメンテナンス性に直結するので、
大域的にオブジェクト指向であっても、メンテナンス単位が大きい
(オブジェクトの粒度が小さい)ため面倒という状況はありえる。
今はアプリケーションはオブジェクトとみなしていいけど、昔は
アプリケーションとシステムが一体だったこともあるわけで。
で、指向するわけだから、オブジェクトとみなす単位をその昔の
ものより小さくしていこうという考え方。

>>373
要はOOはツールであって適材適所の使い分けのできない信者は逝け、と。
んなものOOに限った話じゃないじゃん(藁

>>1
>実装面での有用性を考慮しつつ、一手段として用いるべきで、

こんな誰でもわかってることを何必死に言ってんだ？（藁

つーか不毛。これ以上議論することに何の意味があるのか。

暇つぶし。

1ってひまだなぁ…。

>>374
「協調する」てちうところに、メッセージのやりとりの
雰囲気をからめたいね。

１って、Ｃ＋＋とかＪＡＶＡに反発をかんじてるコボラー？

>>381
そそそ(笑)
ただ、協調＝メッセージのやりとり、と固めるのもなんか違う。
Mediator - Colleague だとメッセージって雰囲気が強いけど
Adapter - Adaptee だとメッセージというよりも
名前の通りにカポっと何かをかぶせてる感じがする。
ただ、何れの場合でも幾つかのオブジェクトが協調しあってはいるな、と。

1って、パラダイムシフトに挫折して退行した低能プログラマだろ。

ところで、この中に「マルチメディア」を判ってた人はいないの？

>>1
ネタ提供マシーン。もうちょい面白いネタを提供してくれ。

>>385
not monomedia

>>385
話そらすなよ

こちらの鋭い質問に全く答えられずにネタはないだろう

>>389
俺、答えたけどレスもらってない(藁

>>390
自己レス。「質問」には答えてないか(藁

しかし、1のように優れた煽り職人ははじめてみた、感動した。

氏んだほうがよくない?

>>385=1
マルチメディアの定義は>>219でとっくにでてる
おまえわかっててわざとボケてるんだろ？優秀だな

>こちらの鋭い質問

うわ、「鋭い」じゃなくて、1が「本読んだけど理解できなかった」の間違い。
いろんな人の発言の中に答えがいっぱいでてるのに、それでも
1には理解できなかった様子

誰も答えてないようなので

1の質問
> メッセージってなんのこと？

オブジェクト間のやりとりのことです。これがC++やJavaでは
関数呼び出しになっているのは、それぞれの言語の実装にすぎないので、
メッセージ＝メンバ関数の呼出ではありません。

それが理解できていないなら、「これからオブジェクト指向を勉強する人へ」
なんて発言はまだ早すぎます。

>>396
既出です。

>こちらの鋭い質問に全く答えられずにネタはないだろう
こっちの質問にも答えてくれ。
まずは>>345あたりから。
わかっるつもりが少しでもあるなら自分の言葉で説明してみなよ。
最後のチャンスだ。

不勉強なやつの思いこみも度が過ぎると犯罪的だな
> だが、この一派は現実の検証を怠るという態度を持った為に
> 彼らの唱える原理はしだいに現実と噛み合わなくなっていった。

ﾊｧ?デザパタがどうやって生まれてるか知ってる？

> 実装面での有用性を考慮しつつ、一手段として用いるべきで、

文章としては合ってるけど、おまえのは継承やカプセル化を利用して
便利になるところだけ使いましょう、ってだけで構造化プログラミングの
拡張でしかない。

> 原理としての概念の研究や原理面からの開発アプローチは
> 一種の擬似科学（擬似工学）とでも言うべきものだと認識している。

おまえがそう認識するのはおまえの勝手。オブジェクト指向についてこれなかった
おばかちゃん達となにも変わらない。

JDKというソース付きのサンプルもあるし、そういうOOなものを利用するコードも
OOで書いた方が効率いい。

４００！やーい馬鹿１！氏ねテメー

1さんのレベルがわからん。
プロ？素人？
プロなら経験は？これまで携わってきたプロジェクトは？
コーダー？プログラマー？SE？アーキテクト？

これらの回答によって付けるレスも変わると思うし。

>>401
中学2年位じゃない？
複数人での開発経験のある人だとは思えない。

うん。そんな気がするのよ。
個人で趣味でってなら、別にオブジェクト指向の哲学的/心理学的
側面なんて理解する必要ないし、できないだろうし。
一番OOPとOOを混同しているのは1さんだと思うんだけど。
1さんももう少し他人に理解されやすい文章を書くように
心がけようよ。OOの重要な側面にコミュニケーション促進が
あることは理解してるでしょ？
1さんの文章からはコミュニケーションを取ろうとする
意思を感じないよ。
そろそろこのスレ終了して良いんじゃないの>1

オブジェクト指向は既に開発手法の原理として確立している。
それが証拠にそれで仕事をしている人たちが大勢いる。
これを疑似科学だと言う人は、単に理解不足なだけ。
むしろ、これだけ広まっているというのに、勉強不足も甚だしい。

理解不足からくる疑念はいつの時代でもあった。
アインシュタインが相対性理論を批判する奴らと一緒で、
自分が理解できないものを否定しているだけに過ぎない。

s/アインシュタインが/アインシュタインの/

>>404,405
じゃあどういう原理？って1さんに突っ込まれて終わりな
発言はいらないから。どうせ答えられないだろうし。

1さん早く出て来いって。話が進まん。

構造化設計を木造建築だとすれば、
オブジェクト指向は、鉄筋コンクリート建築だと思いねー。

要は、作るべき対象と設計方法論のトレードオフじゃねーか！！

犬小屋をコンクリートで作る奴は逝ってよし！！。

開発手法が科学じゃないのは確かだと思うけど。
確信とかポリシーに近いと思う。

オブジェクト指向を体験できる言語 or 開発ツールって何？
とりあえず、WebObjectsかなって思うけど。

>>409
Smalltalk
やってみると分かる。やっぱり凄い。教養として知っておくべき。

http://www.squeak.org

↑ここにあるよ。

>>409
言語:Smalltalk,Ruby
開発ツール:質問の意味がわからん。

Smalltalk 登場って30年近く前なんだよなぁ・・・。

Eiffelってどうよ？つか何て読むのか教えて。
アイフル？

エッフェルだ。馬鹿。

由来わかる？＞エッフェル

>>４１４
読み方くらいで偉そうにするなハゲ

SmalltakもRubyもEiffelもやったことないっす。
なんというか本を読んで勉強するより実際に
言語や開発ツールで強制的にオブジェクト指向が
身に付くものがあればいいかなーと思って。
そんなのないかなーと。横着者なんで。

JavaScript(ﾏｼﾞﾃﾞ)>>409

オブジェクト指向ってそんな凄いかねぇ？
継承とか多態とかメッセージとかいう単語だけ聞けば
なんだこれは？神秘的だ（ｗ）とか思ってビビるけど、
実際、流行し始めた当初は、何かミステリアスなもんだと
考えてた奴も多かったんでは。わからないものは神秘的。
けど蓋を開けてみれば、実際にやってることは、
大したことないっつーか、名前負けしてるっつーか。
見立てという言葉が一番しっくりくるな。

まじで？

Javaがいいんでない？

ボケ。全てのオブジェクトの行動を開始させるのはクラス神の仕事である。

>>422
神父様！
するとメッセージとは天使の事と考えて良いのでしょうか！？

>>417
ありません。OOは概念です。

メッセージといえば、
オブジェクト同士が主体的にコミュニケーションを
とりあってるような印象を受けるが、
実際には主体的にメッセージを送っているのは
つまるところプログラマのみで
オブジェクトは受け専門、操作される客体に過ぎない。

送るような印象を受けるが、
実際にはオブジェクトは受信専門で、
送ってるのはプログラマ。

>>423
神オブジェクトからのメッセージはお告げメソッドで受け渡されます。
人オブジェクト同士のメッセージは単なる会話です。
ただし麻原ショウコウオブジェクトや福永法源オブジェクトも
お告げメソッドを持っていますので注意。

あのー、ＶＢってオブジェクト指向なんですか？
糞厨房でごめんなさい、逝きます。

違う。

>>419
どの「オブジェクト指向」を指して言ってる?
Smalltalkやったことあるか?

Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！
Rubyに決まってるだろ！

Rubyやったことないけど、別にいらないんでしょ？

このスレももう終わりだな

>>430みたいな信者にまとわりつかれてRubyもかわいそうだな。

>>432
1も逝ったみたいだしねぇ・・・。

マルチメディアとオブジェクト指向の類似性

�@定義がはっきりしない。
�Aマスコミにより歪曲宣伝されている。
�B理解できないと正直に言うと理解していると主張する人から叩かれる。
�C以前からあった別のものまでウリナラの発祥ニダと主張し始める。
�D理解していると主張している人は最先端の技術者だと自認している。
�E馬鹿馬鹿しいが、認めないと仕事が来ない。
�F商品にこの名前を付けるととりあえず売れる。
�G役にたたない。

もういいよ。お疲れさん。

>>436

お疲れサン言うならageないでよ（笑）

>>435

しつこいようだけど

> �@定義がはっきりしない。

どちらも定義が確立しています。

> �Aマスコミにより歪曲宣伝されている。

ＯＯを歪曲宣伝しているのは糞エンジニアだと思うよ。

> �B理解できないと正直に言うと理解していると主張する人から叩かれる。

だって基本概念自体は簡単だもの。マルチメディアも。ＯＯも。

> �C以前からあった別のものまでウリナラの発祥ニダと主張し始める。

意味不明
とりあえずＯＯを最初に学ぶときは「構造化設計のカプセル化を発展させた物」
と捉えると解りやすいのかもしれない。
＃構造化プログラミングのカプセル化を理解しているのならば、ね。

> �D理解していると主張している人は最先端の技術者だと自認している。

少なくとも構造化より新しい技術ではあるし、
ＯＯ以上に業界に広まっている新しいパラダイムってないんじゃない？
なによりＯＯ自体が未だ発展途上だし。

> �E馬鹿馬鹿しいが、認めないと仕事が来ない。

ＯＯを馬鹿にする１が馬鹿なだけ。
理解し応用すればいくらでも作業効率が上がる物を
頭から否定する奴に仕事なんて渡したくないよ。

> �F商品にこの名前を付けるととりあえず売れる。

それは名前だけで飛びつく奴が馬鹿なだけ。
ただ、今時ＯＯ的アプローチもできない商品は使いづらくてたまらん。
優れたＯＯで作られた製品はバージョンアップに対応しやすく、
インターフェースも使いやすい物にしやすいのでやっぱり扱いやすい。
商品選択の重視項目としてＯＯを用いるのは悪くないと思う。

> �G役にたたない。

馬鹿にはね。
どんな道具も使い方を知らなければ役には立たない。
パソコンにさわったこともない中年サラリーマンにパソコンを与えても
役に立たないのと同じ。

このスレ見てると目が腐るんで放置スレにしたいんですが。
いかがでしょうか？＞皆様（除く1）

いやしかし、1がいなけりゃかなり面白いすれ。
っていうか、1がいたから盛り上がったのかもな。。。。(笑)

とりあえず、130氏のオブジェクト指向のまとめを
ベースにもう少し洗練した定義にしたいな。

メイヤーさんの本読めばいいのに＞all

>>1はハングル板の厨房だったのか…

理解してない人を叩いたりしないよねえ。理解できないくせに
「オブジェクト指向役に立たない」とかいうやつは叩くけど。

それに、オブジェクト指向なんてたかが原理的な話であって
最先端だなんて思ってない。OOがわかった上でMVCやPACのモデルを
つかって、デザパタを組み合わせるのは設計者なら当たり前で、
技術としてちょっと前ならCORBA、今ならJSP+Servlet(古い？)を使うのは
最先端だと思う。

あとはだいたい>>437に同意

オブジェクト指向は泥棒の始り。

あちこちのアイデアを盗んでは別の名前を付けて売りつけるオブジェクト指向。
オブジェクト指向の説明で「各々独立して動くオブジェクトがメッセージを
交換しながら協調して作業を行う」なんて説明が出てきても疑問に思わない
人がいるのはオドロキだ。
これはシステムーサブシステム構造のパクリだが、概念の作者が寝不足
だったのか、まるっきり破綻している。
オブジェクトが「自立して動く」訳が無い。
辻褄を合わせるために呼び出しのことを「メッセージ」なんて呼んで誤魔化そう
としたみたいだが、それじゃオブジェクトはマルチプロセスじゃないと
存在しないのかい？
これだけでもドツボに嵌ってると言えるのに、あろうことか最近は
「並列オブジェクト指向」なんてのを研究してる馬・・・人が出てきた。

「並列オブジェクト指向はいいよ。君達一般プログラマーの使ってる
擬似オブジェクト指向と違って、オブジェクト間の同期を取るのが少し
難しいけどエレガントだよ。」
などとのたまう信・・・人がでてくるのもそう遠くは無いだろう。

ドロボーのし過ぎは脳によろしくないようで。

じゃあ、本当に自立駆動するオブジェクトが
メッセージパッシングによって強調動作するシステムならば
オブジェクト指向という概念が独特のものであるとすることに
異論はないわけですな：）？
で、しかもそれが開発効率を上げたりするようならば
オブジェクト指向の有効性にも異論はない、と：）

>>445
開発効率が上がるものを拒否する人が居ますかいな。
でも、それはシステムーサブシステム構造そのものだから
全然独自じゃないです。

システムのノードが対等の関係にある場合ならば
それはメイン・サブの関係にあるとは言えますまい。
この点はいかがですかな：）？

COMのアウトプロセスは明らかに並列動作です。
最近流行りのブラウザ内蔵はCOMを利用してい
るので有効性についても確認できます。

なんか、1の煽りもマンネリして飽きた。

>>447
んんにゃ。システムーサブシステム構造ってのは
メインシステムとサブシステムからできてるんじゃなくて、
個々のサブシステムが集まって一個のシステムを作るという構造だから
全部対等。

>>448
そりゃ最初からマルチプロセスじゃんか。

>>450
なるほど。あくまでも旧来の概念で説明できる枠組みから
オブジェクト指向は踏み出していないとおっしゃるわけですな：）？

>「各々独立して動くオブジェクトがメッセージを
交換しながら協調して作業を行う」

並列に動くわけじゃないんだからいいじゃん。独立っ
て言うのは非依存ということでしょ、カプセル化と隠
蔽は基本じゃん。

>これはシステムーサブシステム構造のパクリだが、

システムをオブジェクトとして捉えることも可能。
サブシステムなんとかは「開発手法」として「隠蔽」
「継承」とか取り入れてないだろ。だからカプセル
化を開発手法として説明したければオブジェクト指
向しかない。

>オブジェクトが「自立して動く」訳が無い。

COMのように動く事例もある。

>呼び出しのことを「メッセージ」なんて呼んで誤魔化そう

処理系と指向を分離するために定義した言葉だろ。
メッセージが実装においてなんになるかは開発者が決めること。

オブジェクト指向が新しいものである必要ないっつの。
既存の技術を整理して体系化したものだって立派な技術。
ガイシュツじゃん。

飽きました

そね、1は自分のボケ発言への回答は無視するし

> 呼び出しのことを「メッセージ」なんて呼んで誤魔化そう
> としたみたいだが、それじゃオブジェクトはマルチプロセスじゃないと
> 存在しないのかい？

とうとう電波くんになっちゃったか。まったく意味不明。
メッセージはオブジェクト間の呼び出し。それが関数呼び出しなのか
メッセージにオブジェクト投げるのかは実装依存の問題。

あとオブジェクトが自走ということを難しく考えすぎ。
アプリケーションが「あずかり知らないところで処理が動く」だけで
マルチスレッドは関係ない。各処理をシングルスレッドで順番に動かしてもいい。

わかった？ついでにマルチメディアの定義もわかった？
「わかったorまだわからない」くらいは一度教えてくれ。
次々と的はずれな質問を出す前にな

揚げ足とられそうだから一応補足しとくか。本を読んでもわからないんじゃ
きっと補足もするだけ無駄だとは思うけど

>「あずかり知らないところで処理が動く」
は、処理内容についてまったく関知しないということであって、処理のスタートと
エンドは関知してていいんだよ。マルチスレッドでもスタートは関知するしね。

ﾃﾞｷの悪い小学生に一生懸命方程式を教ｴﾃﾙﾐﾀｲ!!

皆さんCOMオブジェクト説とか出たり、定義がバラバラなようで。

じゃ、とりあえず１に宿題。
>>451 >>452 >>456
に答えてね！
無視はなしだよ！
ちなみに、>>459はどの答えかな？（藁

１以外の皆様
ご存知の通り、１はいくつかの質問に関しては無視しているか、見落としている
ためか、答えていません。このスレのレスの速さには感動しましたが、いい議論を
していると思うので、１への集中砲火は避け、１に回答する時間をあげましょう。
気持ちはよくわかるが(笑)、あわてて攻撃してもいいことはないと思われ。
（１が通常の生活をしている人間なら、明日かなあ。）

自己レス。
＞明日かなあ。
→今日の昼か夜ぐらいかなあ。

昔から時々居るよな、１みたいなやつ。
出る杭は打たないと気がすまない。
こういうやつは、一番権威のある理論に噛み付くんだよ。
それで自分が最も優れていると思い込みたいんだ。

しかし実際のところは、自分のアホさをさらけだしているだけ。

周りにクロールができる人が何人かいるとする。
そして１は平泳ぎしかできない。
周りの皆がクロールの泳ぎ方を語っているときに、
１は「クロールで実際に泳げるわけが無い、クロールなんか机上の空論だ」と
叫んでいるようなものだ。周りの皆は１のことを笑うだけだ。
しかし泳げない人の何人かは１のいうことを信用してしまっている。
そして１は自分の論が正しいと思い込みを深めてしまう。
泳げる人にとってみればごく普通のことなのに、泳げない人にとっては不思議なことになる。

オブジェクト指向は教科書を読んでもなかなか身につかない。
独学で覚えるのは難しい。
しかしそばに指導者がいて実戦で練習できれば、
オブジェクト指向なんて誰でもすぐに使えるようになるような簡単な理論。
クロールの泳ぎ方を口で説明するのがとても難しいように、
ここで１にオブジェクト指向を教えるのは難しいだろう。
オブジェクト指向は習うより慣れるしかないんだよ。
プログラムを始めて覚えたときのようにね。

[5:462] クロール逝って良し！

1 名前：１ 投稿日：2001/07/14(土) 20:35
いらねーよ。んなもんは。
クロールを礼賛する奴は「マルチメディア」を礼賛してた
やつと同じ。
本質がわかってない。

・・・つまんなったですか。逝って来ます（鬱）。

>>463
あわれだな。逝ってよし！

小泉を礼賛するやつは「マルチメディア」礼賛してた
やつとおなじ。
本質がわかってない。

>皆さんCOMオブジェクト説とか出たり、定義がバラバラなようで。

出したの僕なので一応。コンポーネント指向とかエージェ
ント指向みたいなものはすべてオブジェクト指向が基にな
ってますから、コンポーネント指向であるCOMはオブジェク
ト指向であります。

でも「COMオブジェクト説」は知らん。どんな説だそれ。

俺は1の言いたいことがわかるなぁ。
クロールの例で言えばクロール自体は非常に効果的で実用的なんだけど(OOPね)それを一般化して
「全身の使える部位をすべて効果的に使い定期的に息継ぎをしなるべく体を流線形に保つ泳法」
とかいわれてるような気分なんだよね(OOD/OOA)さらに
「利用可能なりソースはすべて使い、消費しなければならないものは定期的に供給し、抵抗をなる
べくなくす」とかいわれちゃうとおいおいって感じになる(OO)
OOPは俺の生産性を確実に高めてくれたし、OOの考え方は価値があると思うけどどんな状況でもそれに
縛られるようなものではないと思うな。
遠泳が目的なら平泳ぎのほうが適してるだろうし、スクーバなら手は動かさないほうがいい。そんな状
況でも「利用可能なりソースはすべて…」は成り立つっていわれればそうなんだけど、そこまでやら
れるとアホラシイ。

何でオブジェクト指向にこだわるのかわからん。
単なる一つの手法じゃん。

いまどきMSXでインターネットでもしてるんなら話は別だが。
おもいっきりOOの恩恵を受けつつ、自身も提供されるオブジェクトを使ってる
分際で、何をかいわんやだね。

酸素逝ってよし！　みたいな（w

１はコボラーで失職寸前のようだからみんないたわってあげてYO

>>467の考え方は強迫観念でしょ。

全くオブジェクト指向ではないように組んだ場合
どうなるかを考えれば「逝ってよし」なんて口が
裂けてもいえない。

OOPは泳法ではなく、目的地までの到達手段なん
だから「泳ぐ」のか「走る」のか「車で行く」と
いう違いでしょ。事を急いて走ってもいいけど、
結局は事前にルートを調べて車で行った方がいい。
最後にどの車で行くのかがC/C++/COM/etcでしょ。

要するにオブジェクト指向は逝ってよし！ってことですか？

あー、はいはい

なぜそんなにOOが嫌いなのか分からない。OOだろうと何だろうと
方法の一つなんだからプロのPGならOOもその他の手法も身に付ければよい。

>>474
ネタスレにつきご配慮のほどをお願いいたします。

>>474
言語の方はまだいいけど、一人歩きしてる概念の方は逝って良し過ぎる
というお話。

宿題だそうな。
>>451
剽窃（ひょうせつ）が多すぎるね、偶然とは思えない。

>>476
もうちょっと付け足すと、
OOPでやれば何でもできると思っている、上司・客
が逝ってよし。

>>476
その言語作ってるほうは、その概念で作ってるんだってば！
あんたの預かり知らん次元でな。

Windows使うんだろ？IEとかネスケで書き込んでんだろ？
頭がおかしいのか？

>>452は質問なのか？,>>456
と合わせてあえて答えてみる。
システムーサブシステム構造のパクリだと言ったけど、メッセージまで出し
ちゃったらマルチプロセスとメッセージシステムそのものやんか。
>>456は両者を学ぶ前にオブジェクト指向に触れてしまったのか。

設計上のマルチプロセスのメッセージとオブジェクト指向のメッセージを
どう区別するつもりなんだろう？
実装上の問題だから区別する必要無いなんて言ったら、プロセス設計の最適化
は実装上の問題になってしまう。
文字列操作の度に別スレッド起こしたりする大変なシステムが出来あがって
しまうぞよ。

オブジェクト指向屋さんとマルチプロセス屋さんが一緒に仕事したら
一体動言う事になるのやらｗ
最後まで誤解したままコミュニケーションが成立したりして。ｗ

１はコボラーで、Javaの新規プロジェクトから外されました。
落ち込んだのはわかるが、スレは立てるな。コボルスレに帰れ。悪いことはいわんから。

>>479
オブジェクト指向にこだわってるクライアントや上司が持ってくる
設計書が流れ図だったりｗ

マルチプロセス屋さん？
ぷ！

479じゃなくて478ね

>>482
でもUML持ってこられたらかなり困っているであろう１

ホント1は都合の悪いレスには答えないな

1さんはデバッグとかしたことありますか？

いや、これくらい聞いておいたほうがいいだろう。
そもそも前提が明らかでないから。

>>1　はどの言語を使う、または使えるのか明確にせよ
>>１　はオブジェクト指向の恩恵を受けているのか、いないのか述べよ
>>１　はどのようなシステムを構築している、もしくはしたことがあるのか述べよ

都合が悪すぎるかな？この質問は。

何度も出てるとおり
1はおぶじぇくとしこうはそこそこわかっててつかってるけど
わかってないのにわかった振りしてるのを
たたき出したいだけじゃないの？

買いかぶりすぎです。
わかってたらマルチメディアなんか引き合いに出せません（赤面）

多分煽って付いてきたレスを会社で自慢げに話したいだけと思われ。

でもねえー。
なんか、1批判してる連中のオブジェクト指向の説明って
とんちんかんなのあるよね。
全部じゃないけど。

オブジェクト指向がなんなのか
ヨーク考える機会かもれないよ。

あ、もちろん1のも変なとこ多いよ。
でもまあ、ただのあおりだと思えば許容範囲。
誰かがつっこんでるしね

宗教と同じとか流行語だとか言ってる時点で
なんだかなぁ
わからないならわからないって言えばいいのに。。。

名無しになって擁護してみたりとかさぁ(w

>>490
それはないな。オブジェクト指向を知っていたら絶対にしないような誤解が多すぎる。
メッセージの混同とかね。

マルチプロセスって、実際には時分割で動いたりしているわけで、
本当に同時に動いているわけじゃないよね。
でも一見すると同時に動いているように見えるので、
平行して動作するものだという認識もまた私たちにはある。
俺たちは実際の実装と、概念的なイメージを、区別して考えているんだよ。
ここが重要。

オブジェクト同士がメッセージを送りあって並列に動くというのは、
マルチプロセスとは関係ないけど、実装は実装、概念は概念というふうに
分けて考えられるのは同じだし、概念的な面では似ている。
オブジェクト指向を知っていれば、メッセージを送りあって協調して……と聞けば、
それは概念の話で、必ずしも実装の話ではないとすぐに分かる。
しかし１はここを混同していて、実装と概念を区別できていない。
ここの区別ができていないのはオブジェクト指向に対する経験が不足しているからだろうね。
だって、１がプログラミングそのものの経験を十分に積んでいるということは伝わってくるからね。
ただオブジェクト指向をイメージできないだけなんだよ。

あと、組み込みでＲＴＯＳを使っている立場から言わせて貰うと、
オブジェクト指向におけるメッセージは普通にメッセージと呼んで、
ＯＳのメッセージ機能を指す場合には「ＯＳのメッセージ機能」とか呼ぶ。
そもそも普通はそういうのにはラッパーをかますから、直接ＯＳのメッセージ機能を
呼び出すことって全然無い。

だってさ、
>>494
とかの言ってるの、なんか、変だもん。

わかった振りして、OOPのことわかったように言うの変だよ。
カコワルイ

この次おまえは
「１ですけど、このスレ立てたのは僕じゃないですよ」

と、言うううううぅっ！

>システムーサブシステム構造のパクリだと言ったけど、メッセージまで出し
>ちゃったらマルチプロセスとメッセージシステムそのものやんか。

あなたの言う「マルチプロセスとメッセージシステム」を概念
上に再構築したあと、隠蔽やプロパティ、メソッドなどの用語
を再定義し、より洗練した手法がOOPといえなくもないかも。
そのものならOOPと新たに定義しません。M$じゃあるまいし。

メッセージとは SendMessage() ではありませんよ？

>設計上のマルチプロセスのメッセージとオブジェクト指向のメッセージを
>どう区別するつもりなんだろう？

C言語上で普通の関数とオブジェクト指向的な関数郡を区別
できないのが良い例で、明快に区別できると考えるのが無
理です。

>実装上の問題だから区別する必要無いなんて言ったら、プロセス設計の最適化
>は実装上の問題になってしまう。

理解できません。

>オブジェクト指向屋さんとマルチプロセス屋さんが一緒に仕事したら

オブジェクト指向は仕事ではありません。
同様にマルチプロセスも以下略。
またマルチプロセスと相反するものではなく、
協調できるものです。具体例は(以下略)。

>>494

マルチプロセッサシステムでは同時に動くこともありえます。
もちろんオブジェクト指向の話ではなくて実装系の話ですが。

おいおい一人で何やってんだ？

jisakujien kakkowarui

>> OOPでやれば何でもできると思っている、上司・客が逝ってよし。

同意

終わっちゃったのか……。

せっかく>>494とかが頑張ってくれたのにねぇ。


>>500
ＯＯＰは実際大抵のことができる。
*ただし*、納期の短縮はできない。むしろ延びる。
２次開発以降の納期短縮及びバグの抑止は可能、という話。

１次でも２次でも納期短縮できると思っている似非理解者は確かに逝って良し。

確かに分析・設計フェイズのコストはよりかかるだろうけど、
テスティングフェイズにおけるコストを抑える一助になって、
結果的に、納期が（ＯＯを適用しなかった場合よりも）
短縮することもありうるんじゃないかな？

設計も慣れたら、時間かわらないけど。
何より仕事の分担がしやすい。

OOPで納期の短縮は出来ない、
ということでよろしいですか？

短縮したという経験の持ち主の話、希望！

OOPがプログラマの自己満足でない証拠は？
顧客にメリットはあるのか？
「安い、速い、バグがない」のうち（納期が）「速い」は無いってこと？

顧客としては「バグはあって当たり前」の態度がむかつくんだYO

>>507
もっと金くれればバグつぶしできるんだよ。
金くれないからバグ取りを客にやってもらうんだYO!

まあ自己満足的側面もないとは言い切れないような気もしないでもない。
けど、ある程度、開発の規模がでかくなると、
OOじゃないと開発不可能だとおもうYO

ある程度規模がでかくなると構造化プログラミングじゃないと
開発不可能になるのと同じように。

どの程度規模で不可能になるかは能力差あると思うけど。

バグ潰すのに金とるのかYO！

俺は1の言うことはよくわかる。1は体感的にがっちり理解したことしか「わかっ
た」と言いたくないのだろう。OOに限らず開発手法を語る奴は、頭の良すぎる
奴と頭の悪すぎる奴のどっちかで、1は前者の言うことは理解できずに、後者
のいいかげんさはわかるんじゃないの。あるいは、悪い設計のライブラリの駄
目さ加減はわかるけど、良い設計のライブラリの美しさはわからないのか出あっ
たことがないか。

1よ。今の道を突っ走れ。君は正しい。そして、君の認める言語としてのOOPの
良さをもっともっと追及しろ。納得できないものには絶対納得するな。いつか
君は立派なOO信者になるだろう。

>>510
あたりまえだYO!
こっちだって生活がかかってるんだ。
のんきにバグつぶししてるひまないんだ

不良品はタダで交換が基本だYO！

もちろん、見つかったバグはタダで直すYO!
でも、バグを見つける作業はやってられないYO!

納得できん！結局人間は馬鹿ってこと？
プログラミングって結局手作りってことだな？
出でよAI！お前ら失業！
あのころはOOで激論交わしたよなぁ
ってダンボールの中で泣け！

以上、ダンボールの中からカキコしてみました（藁

>>511
1には無理だと思うよ。頭悪いから。

78 名前：仕様書無しさん 投稿日：2001/07/18(水) 20:29
>>77
ASP、JSP、Java Servlet を使った Web アプリが最先端技術だと思っている
奴が多いが、Web アプリは、CICS よりも数段劣る糞システムなんだな。
最近、Web アプリに多くを期待する糞バカが多くて困るよ。

http://mentai.2ch.net/test/read.cgi?bbs=prog&key=993637661&ls=50

1が馬鹿だと言う奴の方が馬鹿だ。

>ある程度、開発の規模がでかくなると、
>OOじゃないと開発不可能だとおもうYO

こういうのも現実無視の世迷言だよねー。
OO概念以前からあった大規模システムの存在など無視してる。
誰かが「机上の空論」って書いてたけど、現実とのすり合わせを
怠っちゃいけません。

それから私がプロセスとオブジェクトを混同しているとか書いてる
人がいますが、私は全く逆のことを書いたはずです。

他にも自作自演とか電波が飛び交っておりますが、これもOO概念の
影響でしょうか？
日本の将来が心配です。

OOを理解していない人や、うまく説明できない人が多いってわかった感じ。

>>520
　確かにね。新人とかがそれを言うと、俺も諭すケド。
　昔は、仕様書レベルで意識合わせの必要があった。（密にね）

　でも、コンパイルレベル（厳密にはチト違うが）で
　整合をとってくれるので、
　昔よりは随分楽になった。のも事実だ。

　で、さらにいうと、その結果、よくクラッシュするＡＰが
　続出してるのも事実だがな。

　工数削減にはイチヤクかってるで。

>>1
は、OOPができる！人への醜い嫉妬でしょう。

算数のわからない厨房が、
「算数は使えないので逝ってよし！」って
空に向かって唾吐いてる。

>それから私がプロセスとオブジェクトを混同しているとか書いてる
>人がいますが、私は全く逆のことを書いたはずです。

逆の事を書いた？　どこにもないぞ。
オブジェクトがメッセージをどうやってやり取りしているのかイメージできないから、
オブジェクト指向のことを概念だけのものだとあなたは誤解しています。
当然すぎるから余り語られていないけど、オブジェクト指向の概念というのは、
コンピューターで実装することを前提に組み立てられているのです。

どうして１はオブジェクト指向を理解できないのか。
プログラミングの初心者がポインタの話につまづくのは、
物理的なメモリの配置をイメージできないからでしょう。
しかし変数を入れる箱というような抽象的な話ばかりするから理解しにくい。
これと同じようなものかと。
オブジェクト指向を説明するとき、オブジェクトがメッセージを……という話をすると、
それが概念上は正しくても、説明としてはあまりうまくないと思う。
１のような人には、仮想関数を使った汎化がどのような仕組みで動いて、
それが何の役に立つのかということを説明したほうが早いんじゃないかな。
クラスの抽象化について教えるよりも先にポリモーフィズムに興味を持たせると。

>>525

ツッコミどころ満載。>>1よりもマシですか？

>メッセージをどうやってやり取りしているのかイメージできないから、

関数呼び出しにやり取りが要るわけ？

>コンピューターで実装することを前提に組み立てられているのです。

OOはどちらかといえば設計手法だと思いますが。
OOPはOOに基づく設計による開発手法。
OOが実装を前提とするなら、実装をしないOOはOOではありませんか。

>プログラミングの初心者がポインタの話につまづくのは、
>物理的なメモリの配置をイメージできないからでしょう。

ポインタは純粋にマインに存在するものなので、
頭の中に存在するOOとは全く別物です。

>１のような人には、仮想関数を使った汎化がどのような仕組みで動いて、

「関数へのポインタを隠しメンバとして保持し、
コンストラクタで書き換えていきます。
これにより多態が実現できます。」が分かりやすいんですか。

>クラスの抽象化について教えるよりも先にポリモーフィズムに興味を持たせると。

抽象化と多態性は表裏です。抽象化だけして具体化でき
ないのであれば意味がありません。抽象化したしたもの
の特化例が一つしかなければ抽象化する意味がありません。

訂正。
ポインタは僕のものではなくてマシンの中に存在します。

>>527
ツッコミどころ満載なのはお前。
お前がオブジェクト指向を理解していることはわかったけど、
526の話の意図を一ミリも読めてないよ。

抽象化と多態が別だとは書かれてないし、
お前がOOと呼んでいるのはOOAだし、
１がメッセージを誤解しているのは確か。
メッセージには関数呼び出ししかないと思い込んでいるのも痛いね。

>>1
どうもなぁ。まず、罵倒はやめようよ。意味ないし。

OOがどれぐらい効果のあるものなのかというのはここで議論しても
水掛け論になる。と言うのは、幾ら事例を挙げたところで「そんな
の例外」とか「こういう考え方もできる」と返せばまた罵倒合戦に
なるから。真面目にOOの有効性を議論したかったら業界を広くサー
ベイして調査報告でも作らないと駄目っしょ。実際、これだけ沢山
プログラマがいるんだから事例にだって相当な幅がある。駄目だっ
たよ、って話も、最高だったよ、って話も、どっちだって沢山掘り
出せるはず。多数決とったり特定の事例を重視したりするの？

OOが大風呂敷を広げているのかどうかってのも同じ文脈で、言うだ
け不毛。例えば、僕の周囲にOOで何でもできるなんて大風呂敷広げ
ている奴はいない。それどころか、色々な手法をハイブリッドで使っ
てる奴の方が多い。インタプリタ組んでシステムの上層はまんま手
続き型で書いて中間層はオブジェクト群で高水準ライブラリにして
最下層は構造化設計で書くとかね。でも、大風呂敷広げてる奴だっ
ているだろうし、大学の研究論文とか見てたらそれっぽい話も割と
ある。何が一般的かなんて話はやるだけきりがない。

OOがこれまでにあった概念を盗んでいるかと言えばそれは言いすぎ。
大体、これまでの概念でできたことを全く違ったアプローチで実現
することができて、そのアプローチのことをOOと呼ぶ、なんて話を
してる奴がいるの？そういう奴がいて、その上で「お前の言ってる
話なんて全部昔の技術の中にあるじゃん。泥棒だ」って言うならま
だ分かる。でも、OOの解説書はどちらかというと、これまでの技術
の蓄積の中にオブジェクトというメタファーで解釈できるものを見
出して、そのメタファーの体系としてソフトウェア製作の技術を捉
えなおそうっていうスタンスのものが多いと思うよ。デザパタなん
てその典型。当然ながらこれは過去の資産を前提にしてるわけで、
新技術だなんて触れ込みはない。OOを実践してると自称するプログ
ラマの多数に支持されている大家でOO万能主義を掲げてる人がいる
なら教えて欲しい。

例えば僕があるソフトを作ったとして、そのソフトを逆コンパイル
したとする。逆コンパイラを変えれば、出てくるソースはBASICになっ
たりC++になったりする。で、BASIC逆コンパイラを使った人が「こ
のソフトはBASICで書ける。OOなんてはったりだ」と言い、C++逆コ
ンパイラを使った人が「このソフトはC++で書ける。OOこそ最高だ」
と言う。そんな不毛なやりとりをしてるように見える。実際には、
一つの問題の切り口が何通りもあって、それぞれに個性があるとい
うだけの話。どの個性がどういう状況にマッチするかなんてのは個
別の問題であって、一概にどうこう言えるもんじゃない。

結局のところ、僕には >>1 さんがOOという問題の切り口が増えるこ
とにどんな不満を持ってるのかよく分からない。アセンブラがあれ
ばBASICなんて要らない、BASICがあればC++なんて要らない、C++が
あれば・・・そういう暴論を重ねてるだけだと思うなぁ。手段が増
えること自体は十分すばらしいことだと思うんだけど？なんでそん
なにOOのことを嫌うの？

>抽象化と多態が別だとは書かれてないし、

抽象化と多態は別物です。
ただし、別々に教えても意味ないです。

>お前がOOと呼んでいるのはOOAだし、

「OOに基づく設計」はOOAですね。
OO=OOAとするなら、「OOAに基づく設計」はOOAAですか。

>メッセージには関数呼び出ししかないと思い込んでいるのも痛いね。

該当部分についてはちょっと日本語的な誤解があったようです。
メッセージ発行に関する手続きみたいに読んでしまいました。

ただ、OOPに触れるときにいきなりRPCを利用しなくてもいいでしょうし、
最も簡単なメッセージが関数呼び出しであることは異存ないと思います。
で、「関数呼び出しをイメージできない」人がいるのか疑問です。
居たとしてもそれは果たしてプログラマですかね。

ところで実装において関数呼び出しとは全く異なるメッセージ
の発行方法は知らないんですが、どういったものなんでしょうか。
メッセージものだって最終的には関数呼び出しになるわけだし。
純粋に質問です。

関数っていうのやめてくれない?

>>530
たとえば複数のスレッドをオブジェクトと見立てたとき、
あらかじめ決めたグローバル変数の変化を監視することで
メッセージのやりとりを行ってもよいのでは？

ホントにやるなら排他制御が必要な場合がほとんどなので、
排他制御とフラグ立て・監視・通信はそれぞれ関数のような
パッケージングされたものになるのが妥当だが...

>>532
Windows以外はプログラミングには明るくないんのですが、

・そんなことしたらCPU100%食う
・ていうか素直にWin32イベント使え

というツッコミをかわしきれれば納得です。ていうかコン
ピュータのアーキテクチャと言語のほとんどが関数を基底
にすえているので、質の悪い質問であったかもしれません。

>>1には>>529さんがまとめちゃった気がするし、
もう言いたいことはいったのであとは反応待ちですか。

そういうので構成されたのがあってもいいという例だから、
細かい実装の話しはなしね。ばかばかしい。

＞それどころか、色々な手法をハイブリッドで使っ
＞てる奴の方が多い。インタプリタ組んでシステムの上層はまんま手
＞続き型で書いて中間層はオブジェクト群で高水準ライブラリにして
＞最下層は構造化設計で書くとかね

上層インタプリタは俺だけじゃなかったのか。
周りから奇異な目で見られてたが、結構正道だったのね。

>>535
それってVBのこと？

駄目だ確かにオブジェクト指向を解った気になってるやつが一杯だ。
しかしそれ以上に相手の意図を汲まない揚げ足取りが多すぎ。
オブジェクト指向勘違い君は逝ってよしということでいいでしょもう。

>>536
いやぜんぜん違うと思う。

>>529
言語は否定してないけど概念だけ机上の空論で発達させるのを
否定してます。
言語教えようとして、「基礎だから」って言ってあの概念を
注入したら「オブジェクト指向で逝って良し」になってしまいます。

>>538
VB言語→COM→ランタイム

同じじゃん(藁

アセンブラ、Ｃ，Ｃ＋＋，ＶＣでそうやってます。
ＶＢは知らない。

>>1
さて、こいつらどうするよ？

ワシは寝る。

>ところで実装において関数呼び出しとは全く異なるメッセージ
>の発行方法は知らないんですが、どういったものなんでしょうか。

とりあえず一つあげると、関数の戻り値。
メッセージに対する応答をメッセージで返しているわけね。

他には、ＯＳの通信機能やコールバックを使って
オブジェクトにメッセージを受け取らせることもある。
メッセージキューも、直接関数を呼び出すものではないね。

オブジェクト指向を知らない人のために補足しておくと、
既にあるものをメッセージと呼びなおしたわけじゃないから。
送り出す者と、受け取る対象は、どちらもクラスオブジェクトであり、
対象を明確にしていると言う点が重要。
機能的に見れば、どれもオブジェクト指向とは関係ないように見える。
しかしそもそもオブジェクト指向を実現するために、
従来からある機能を利用しているに過ぎないだけ。

ちなみにRoseやVisioのUMLアドインなんかでは、
メソッドの呼び出しのほかに、イベント経由での呼び出しや、
返答なんかも登録できるよ。

>「OOに基づく設計」はOOAですね。

「OOPは」を抜いたら、当然そう読めるよな。
でも元の文脈では、OOはOOAでありOOPはOOAに基づいているとしか読めんよ。

>OO=OOAとするなら、「OOAに基づく設計」はOOAAですか。

君がそう思っていたのではないの？
↓これを書いたのはキミでは？

>OOはどちらかといえば設計手法だと思いますが。
>OOPはOOに基づく設計による開発手法。

JAVAは糞ってことだな

>>539
529 です。

教育面においてOOP言語よりも先にOOの話をしてしまうことの弊害は
分かる。OOP言語からOOを学んだ方が地に足が付いていていいとも思
う。だけど、OOP言語はOKだけどOOは駄目というのは納得がいかない
なぁ。

釈迦説法かもしれないけれど、OOP言語ではなくOOが有効である例を
一つだけ。

PMEオブジェクトモデルを使うとコンポーネントの設計が非常にやり
やすくなる。だけど、PMEのそれぞれを簡単に書けるような文法をど
のOOP言語でも整備しているわけじゃない。実例で言えば、VB、BCB、
ObjectPascal、C#はそのための構文を持ってるけど、C++、Javaは持っ
てない。でも、JavaではPMEモデルに沿ってクラスライブラリをデザ
インすることで、ライブラリの見通しのよさを実現していると思う。
getName/setNameというペアになったメソッドがあるとして、これを
プロパティという考え方以外で解釈するのは強引だと思う。これはJava
の文法だけからOOを捉えていてはなかなかすっきりとは解釈できない
ことの一例。言語に依存しないOOの範囲で考えてからそれをある実装
モデルにまとめる、という流れ自体はそれなりに有効であることを否
定して欲しくない。

それと、OOに関連する概念を実装上の経験を伴うことなく「机上の空
論」だけで作り上げてしまうような奴がいるとしたら、それはOOが悪
いというんじゃなくて単にその人材が安直なだけ。世間に受け入れら
れるOO上の資産は、大抵の場合明確な実績を背景にしている。1 さん
の言い方はその辺りを十把一絡げにしているように思えてならない。

それと、「机上の空論」が問題になるのはそれを無理矢理に押し通し
た場合であって、十分な検証や慎重な取り組みをもってすれば「机上
の空論」にも意味があるのだということをちゃんと含意した物言いを
して欲しい。でないと、前例のないものは何一つ作れないことになっ
てしまう。

1 さんがOOを批判するのが、教育の場における理論先行への危惧と、
現実に無頓着な「机上の空論」型のOOに対するものであって、それ以
外については特に問題視してないのなら、そのことをはっきりさせて
欲しい。でないと、わざわざ喧嘩を売るためにここに来てる愉快犯に
見えてしまう。

> 上層インタプリタは俺だけじゃなかったのか。
> 周りから奇異な目で見られてたが、結構正道だったのね。

『Java言語で学ぶデザインパターン入門』
http://www.hyuki.com/dp/index.html

この本の「第23章 Interpreter ― 文法規則をクラスで表現する」に
それについて書いてあります。

1さんはこの概念(とその効用)を回りの人に伝えられなかったわけですが、
ちゃんと表現して、伝達できてる人もいるわけです。
「Interpreterパターンで行こう」「OK」
話がこれだけですむのと、
あなたのように一から独自の用語で表現するのと比べて、
どれだけコミュニケーションのコストが削減されるか考えてみてください。

「オブジェクト指向」という抽象概念が実際的な効用を持っていることの、
ひとつの実例です。

>>544
>他には、ＯＳの通信機能やコールバックを使って
>メッセージキューも、直接関数を呼び出すものではないね。

これについてはオブジェクトの実装が関数という形態以外に
考えにくいので議論しません。突き詰めればすべて関数だし、
緩めればダイレクトなもの以外はすべて関数ではありませんから。

>>545
>君がそう思っていたのではないの？

僕がそう思っていたと仮定して「OOによる設計手法」を解釈すると、
その仮定であなた(読み手)は「OOAによる設計手法」という解釈を
したことになり、これは矛盾しているので、仮定も成立しないとい
うことになりませんか。

>OOはどちらかといえば設計手法だと思いますが。

これは「頭の中だけのもの」という点と、OOPの前にOOを
理解している必要があることとOOPの前になんらかのOOA
をしなければいけないという点などの類似からこう書きました。

>「Interpreterパターンで行こう」「OK」
>話がこれだけですむのと、
>あなたのように一から独自の用語で表現するのと比べて、
>どれだけコミュニケーションのコストが削減されるか考えてみてください。
>「オブジェクト指向」という抽象概念が実際的な効用を持っていることの、
>ひとつの実例です。
これこそまさにアイデアの盗用の例だと思う。デザインパターンが有効なのはわかるが、
それはOOとはまるで関係の無い概念だ。

>>550
529 です。

なんで盗用とまで言いたがるのかがよく分からない。

デザパタそれ自体は確かにOO以外「にも」有効なもので、その意味で
言ってOOそのものであると言えないというのなら分かる。でも、デザ
パタに出てくるパターンはクラスやインスタンスなどの概念を基礎と
して説明されてる。つまり、デザパタにおいては、パターンはOOの枠
組みの中で実現されることが第一に想定されていると思う。もちろん
クラスやインスタンスという考え方それ自体はOOそのものではないし、
昔の技術にだって同等のものを見出すことはできるけど、それらを一
つの体系に統合したものとしては現時点で見てOOがもっともすっきり
していると思う。

繰り返しになるけれど、デザパタの中では過去の実績を分析してパター
ンを抽出したということが明記されていて、独自の新しいアプローチ
で旧来のものにはなかった新規性がどうこうなんて話は書かれていな
い。つまり、それは過去の資産になんらかの形で立脚することを前提
にしている。過去の資産を整理して新しい名前を付けた時点で盗用だ
と言うのなら、デザパタの内容は全てが盗用になってしまう。

僕は、デザパタというのは過去に作られてきた色々な資産をアーキテ
クチャの再利用という観点に立って再検討し、アーキテクチャの表現
手段として柔軟性の高いOOという方法論を採用したものだと思う。OO
ベースの解釈を採用することで、アーキテクチャを個別の手法ではな
く容易に組み合わせ可能な同列のものとしてカタログ化し、更に大ま
かながらもそれを実装するためのモデルまで表現することができた、
というメリットがあるとも思う。

余計な一言かもしれないけれど、OOというのは明確なアーキテクチャ
の複合物として対象を把握する方法論だと思う。個々のアーキテクチャ
はこれまでの技術の中にも当然見出されて然るべきだし、本当に有効
なものならば実績とともにそうでなくちゃならない。別の言い方をす
ればOOというのは過去の資産を体系化して扱いやすくするための手法
であって、それを盗用と言うのは、教科書の内容は研究者の論文の盗
用と言うのとどう違うのか分からない。

>なんで盗用とまで言いたがるのかがよく分からない。
548の文脈で語られた
>「Interpreterパターンで行こう」「OK」 話がこれだけですむのと、
という利点は
>僕は、デザパタというのは過去に作られてきた色々な資産をアーキテ
>クチャの再利用という観点に立って再検討し
というデザインパターンの性質から得られている。これはOOと関係ない。
クラサバだってイベントドリブンだってデザインパターンだし、
同じように利益がある。

>余計な一言かもしれないけれど、OOというのは明確なアーキテクチャ
>の複合物として対象を把握する方法論だと思う。
OOをそう定義するのなら好きにしてくれ。それこそ大風呂敷だと思うが。

>>552
529 です。

>>「Interpreterパターンで行こう」「OK」 話がこれだけですむのと、

名前を付けることができたのはデザパタの実績立脚というスタンス
に基づく利点、と言うのなら分かる。だけど、その名前に対応する
概念を分かりやすく表記できたのはOOのおかげだと思う。

デザパタに出てくるパターンそのものがOOの産物であるとは言って
ないよ？デザパタはその表現手段としてOOを基礎にすることで分か
りやすい記述を実現し、そのおかげでカタログ本の形にまとめるこ
とができたのが利点だと言っている。だから、デザパタを活用する
ことで得られる利益の直接的な源はOOではないにしても、その活用
を容易にするためのツールとしてOOが有効であることは言えるとい
う切り口で書いている。OOではない別の表現手段によって広く受け
入れられるデザパタ本が書けるのなら、その具体的な表現方法を例
示して、その上でその手段に対するOOの短所を指摘して欲しい。あ
るいは、デザパタでのパターンの表現ポリシーがOOではないことを
明確に論証して欲しい。

アーキテクチャについては、全てのアーキテクチャをOOがまかなう
というようなことを言っているつもりはない。あくまでも現在利用
されているアーキテクチャの中のある範囲をカバーするものでしか
なく、今後どこまでその範囲が広がるのかは蓋を開けてみないと分
からない。それに、その範囲を広げていく過程でオブジェクトとは
また違った基本概念が出てきて、その時にはOOではない別のものが
できていくのだろうとも思う。この点についてはおまけ程度の一言
だったのでこれ以上はやめておく。

僕はOO以外の方法がOOに比較して駄目だなんてことは一言も言って
ない。便利なものはなんだって使えばいい。OOを重要視するのは、
それでカバーできる範囲が比較的広いからであって、それ一つで全
てが片付くとは思ってもいないし書いてもいない。

よく分からんが、あなたの頭にあるデザインパターンとは
・OOPLでシステムを作る時
・ある程度詳細に立ち入ったパターン。なのでは？
アセンブラでテーブルジャンプパターンとかは対象外で
イベントドリブンやトランザクションなどはアーキテクチャーパターン
になるのだろう。
でもこれらも皆デザインパターンであって名前をつけることによって
コミュニケーションが円滑になっている。君はその利点のことを
>「Interpreterパターンで行こう」「OK」 話がこれだけですむのと
と評したのではなかったのか？

それによしんばデザインパターンの表現にOOが適してるとしても(これも
曖昧だUMLのことか？)
>「Interpreterパターンで行こう」「OK」 話がこれだけですむのと
この利点は直接的にはOOとは関係が無い。最初から
「デザインパターンを表現するときにOOの抽象概念は便利だ」
とかいってもらいたい。

>>554
529 です。

えっと、これは僕向けのレスだよね？(笑)

誤解があるような気がするんだけど、529 以後、はっきり「529 です」
と断っているもの以外は僕の発言じゃないよ。

余談として付け加えておけば、僕にとってのデザパタは特定の言語に
依存するものではなく、単にそれに合致する状況があった時にそう呼
称するアーキテクチャ、という程度のものでしかない。アセンブラで
テーブルを使ってジャンプする、というのに該当するパターンは知ら
ないけれど、もしそれに相当するものがOOの流儀にそってデザパタに
記載されているならばデザパタの一種として捉えると思う。今のとこ
ろそういうのはデザパタの一種だとは思わないし、だからOO的に捉え
るということもせず、OOで捉えられるアーキテクチャと相補的に利用
するものとして扱ってる。

UMLによる表記が曖昧かどうかはUMLそれ自身の問題であって別のもの
だと思うし、そもそもOOが現時点で完成された手法だとも思ってない
から、それは今後の課題ということでいいと思う。デザパタの表記に
OOの流儀が適していると思ってはいる。結局のところ、言葉は拙かっ
たとは思うけれど、デザパタに関しては「デザインパターンを表現す
るときにOOの抽象概念は便利だ」というスタンスで僕は最初から書き
続けている。

それよりも、それだけ執拗にOOを批判するのなら、デザパタを表現す
る上でOO以上に優れた方法がある、もしくはデザパタの表現がOOには
一切立脚していないということをはっきり示して欲しい。僕は別にOO
信者ではないけれど、OOはそれなりに有効な方法であるとは思ってい
て、デザパタにおけるOO流の表記はその代表例だと思っているので、
それを理由を明示せずに否定されるのはどうにも釈然としない。

>それよりも、それだけ執拗にOOを批判するのなら、デザパタを表現す
>る上でOO以上に優れた方法がある、もしくはデザパタの表現がOOには
>一切立脚していないということをはっきり示して欲しい。僕は別にOO
>信者ではないけれど、OOはそれなりに有効な方法であるとは思ってい
>て、デザパタにおけるOO流の表記はその代表例だと思っているので、
>それを理由を明示せずに否定されるのはどうにも釈然としない。

俺だってOOを否定なんかしてないぞ(きちんと定義されてないものをどうや
って否定する？)しつこいようだが
>「Interpreterパターンで行こう」「OK」 話がこれだけですむのと
はいくらなんでもOOとは関係ないし、それをあたかもOOであるかのように
語るのを否定してるだけだ。
君が548でないならもう一度>>548から読み直してくれ。

もう一つ
>UMLによる表記が曖昧かどうかはUMLそれ自身の問題であって別のもの
>だと思うし、そもそもOOが現時点で完成された手法だとも思ってない
UMLが曖昧だといったのではない。

>デザパタはその表現手段としてOOを基礎にすることで分か
>りやすい記述を実現し、そのおかげでカタログ本の形にまとめるこ
この「OOを基礎にすることで分かりすい記述を実現し」の『記述』とはなにか？
という意味で曖昧と言ったんだ。それがUMLのことをさしているのなら
「わかりやすいのはOOのおかげとは言い切れない。UML!=OOだから」
といわさせてもらう。

>>556
529 です。

読み返してみた。確かに僕の方で誤解があったと思う。盗用という
表現は行き過ぎなので取り違えというぐらいにして欲しい。ただし、
僕自身のごく個人的なポリシーとして、デザパタの背景には表記だ
けでなく概念面でもOOの影響が少なくないと考えていることは付け
加えておきたい。このことについてやり合うつもりはないけれど、
僕はその程度にはOOのことを重視しているのだという参考までに。
いずれにせよ、誤解のことは早とちりして申し訳ない。

ところで、OOが明確に定義されていないのかどうかと言えば、これ
はどうとも言えないことだと思う。ある実装モデルにそって明確な
定義の下で実践していると考えている人もいるだろうし、特定の定
義を与えずにメタファーとして柔らかいままにする方がいいと考え
て実践している人もいるだろう。この辺りは構造化プログラミング
でもあまり変わらない話じゃないかな？普通は手続き型プログラミ
ングからの発展として、関数のような単位への分解を行うものを構
造化と呼ぶけれど、そこから更に踏み込んで条件分岐などにも一定
のパターンを与えるところまでを徹底してこそ構造化だとか、手続
き型言語のサブルーチンは構造化だとか構造化でないとか、少なく
とも一つの意見に完全に収斂しているものでもないと思う。そもそ
もオブジェクト「指向」であって記号的に定義されるようなもので
もない。僕自身はメタファーとして考えている。

>>557
529 です。

上掲の内容はここで一区切りとして、こちらの話を本題にしたい。

話が迷走しないように状況を設定したいと思う。

まず、僕はあなたは「OOの成果と呼ばれているものの大半はOOによ
るものではない」という立場を取っていると捉えている。その上で、
上記の文を読む限りだと、「デザパタの分かりやすさはOOのおかげ
ではない」とのスタンスも取っていると思う。

これに対して僕は、「OOの成果と呼ばれているものは旧来の成果を
簡便に利用できるようにしたことであって、構文糖衣のようなもの
としての性質が最も大きい」というスタンスを取る。その上で、
「デザパタの分かりやすさはOOのおかげである」との意見で、あな
たの言うことに反論したい。

論点は、「デザパタはOOのおかげで分かりやすくなっているのか？」、
に絞りこむということでどうだろう？

そんなのに付き合うほど暇じゃないって言うのならやめておく(笑)

>>559
面白そうだけど、後でね

>>560
529 です。

りょ〜かい。今から帰宅(笑)

　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣
　 (　　,,)＜　　ときゅん逝ってよち
　＠＿）　　＼＿＿＿＿＿＿＿＿

　 ∧ ∧　　 ／￣￣￣￣￣￣￣￣￣￣
　(,,・д・)＜　なんつったりちて
　＠＿）　　 ＼＿＿＿＿＿＿＿＿

デザインパターンの定義をちゃんとしてないからでしょ。
GoFのはあくまで「オブジェクト指向による再利用のための」だ。
オブジェクト指向によるデザインパターンもあれば、オブジェクト指向に
こだわらないデザインパターンもあり得る。
最近はイディオムみたいな細いものもパターンという呼び方をしてるが、
そういうのなんかまさにオブジェクト指向でなくても適用できるでしょ。
あんまりパターンを引き合いに出してOOの話をしない方がよいよ。

>>563
529 です。

デザパタに出てくるパターンの内容がOOであるという話はしてない
よ。デザパタという本の表現におけるOOの効用という話をしている
ところ。パターンとOOの関連の度合いは別にして、パターン即OOな
んてことは僕も554さんも言ってない。それに、非OOのパターンのこ
とも含意して話をしているつもり。ところで僕はGoFのデザパタ本を
想定して話をしてるんだけど、ひょっとしてデザパタの通り名で有
名な他の本があるの？それなら554さんと僕とで行き違いがあるのか
もしれない。

>>560
529 です。

フライング気味だけど今から食事なんで書いてみる(笑

まず、僕の立場では、GoFのデザパタにおけるOOは、パターンを構成
する上での部品となる、メタモデルの役割を果たしていると考える。
デザパタでは、継承、多態、クラス、インスタンス、といった、OOP
言語でよく見られる概念の組み合わせによって実装されるオブジェ
クト、という概念を想定している。さしあたってはこれをデザパタ
における狭義で限定的なOOとしておく。

ここで一区切りして、もし今挙げたオブジェクトという概念がそれ
自体既にOOとは無縁のものでこういうモデルがあることがOOなのだ
とは言えない、と言うならこれ以上言うことは何もない。そこまで
言われてしまうと、これはもう感覚の違いとしか言いようがない。

以下では、上記のモデルはOOの一環であるとして考えてみる。

実際、少なくとも、パターンを提示する際にConcreteな派生クラス
を想定したり、CompositeやSingletonでインスタンスの数や包含関
係を意識したりなど、これらの要素がデザパタのあちこちに顔を出
しているのは間違いない。特に、継承と多態の組み合わせで、共通
するインターフェイスに対して異なる実装をバインドするという考
え方は随所に現れている。デザパタにおける記法は、先に定義した
ようなオブジェクトの持つ性質を記号化したものであって、この意
味で言って記法の裏にはOOがあると言える。表題にも「オブジェク
ト指向による」とあるぐらいだから、これは認めてしかるべきだと
思う。

この上で問題となるのは、そのような方法を使うことで本当にデザ
パタは分かりやすくなっているのか、に集約される。

これは別の視点から捉えれば、OOではない別の方法でデザパタをよ
り分かりやすく表現できるものがあるかどうか、ということと同じ
ことだと考える。もしそのような方法があるならば世間でよく知ら
れているからという以外にOOに頼る理由はない。逆に、そのような
方法がないのなら、絶対的にではないとしても相対的に最善の策と
して、パターン表現のためにOOを使う理由とメリットがある。

これについて僕の立場から完全に白黒をつけようと思ったら、ソフ
トウェア開発におけるありとあらゆるパラダイムを羅列して非OOに
分類されるものに代替物がないことを言えばいいけれど、それはで
きる話ではないのでやらない。ただ、上記のようなモデルを前提す
るという意味でのOOに従った統一的な記法でデザパタ内のパターン
が記述されていること、を言うに留める。記法が統一的であればこ
れを読解する上で知識の使い回しができるのだから、そうでないも
のに比べてずっと読みやすく分かりやすいのは確かだ。

僕の言えることはこれぐらい。これで考えが浅いと言われるともう
「ごめんなさい」としか言いようがない(笑)

あんたら暇っていうか、仕事さぼってるっていうか、よくそんなに
細かく書いてる時間あんね？学生？ほんと不思議。おれなんか３行が
限度。かつ、くだらないことした書けない。仕事してんの？

OO設計の難しさはどういう責任分担にするか決定することだかんね。
へんな責務の分担をすると、悲惨なことになるよね。お手本があると楽だわさ。

>「デザパタはOOのおかげで分かりやすくなっているのか？」

これを論じるなら、私はパターンの抽象度に注目したいです。
「アレで行こう」という時の「アレ」が指しているものの抽象化のレベル。
これが、コードにベッタリ密着しているものなら、
わざわざ誤解を生みやすい言葉を使う必要もなく
コードそのものを流用した方が間違いがありません。
一方、これがコードからあまりにもかけ離れていたら、
「アレで行こう」と決めた後に考えることが多すぎて、
コミュニケーションの行き違いや設計上の決断のミスが発生する
確率が高くなります。

それで私の主張は
「デザパタはOOのおかげでほどよい抽象化レベルの記述方法を得た。
だから使えるものになっている」
ということです。

もしOO抜きだったらデザパタは、
単なる個別ライブラリの構造設計書か空虚な精神論になってしまい、
これだけ支持を集めるものにはなっていなかっただろうと、
私は感じます。(これはただの感覚なんで「俺はそう思わん」と
言われたら返す言葉はないですが・・・)

ＣＯＢＯＬ逝って良し！！
シャレにならん・・・

■PC-Success 個人情報流出に対するホームページ

http://whythishappened.tripod.co.jp

上層インタプリタがOOだと言ってる人いるし・・・。
こう人数が多いと出版業界のライターの仕業とは言えないな。
オブジェクト指向症候群とでも言ったほうがいいかも

>>572
周りの人間が病気なのではなく、
お前だけがオブジェクト指向拒絶症だったということに
早く気づけよ。

新人を潰す手段としては有効だなｗ
JAVAスレ見ててそう思った。

>>488　だが、あなたは質問に答えないな。
都合の悪いレスは全部無視か。

水野？（ｗ

NeverOO ichi ;
while(true) {
__try {
____ichi = 2ch.nextOOargument() ;
__} catch(InvalidTypeException e) {
____audience.studiesAboutOOmoreFrom(e) ;
__}
}

>>576
Javaで書いたのは「1の型は静的であって変化する見込みがない」ということ？

>>574
じゃ、こちらの質問に答えてね。
574の本名は
574の勤務先は
574の学歴は？

オブジェクト指向でプログラムを部品化して
再利用をもくろんでも、技術の進歩と
システムの大幅な変更で結局一から作り直したほうが
いい場合が出てくる。
そう考えるとクラスの多重継承なんて
あんまり意味ないな。

オブジェクト指向の恩恵を受けているのは、クラスライブラリの開発者と
それを利用するプログラマーだ。
ライブラリ開発者にとっては開発が効率良く行え、プログラマーにとっては
メソッドが継承されるので、同じ使用方法で新しいクラスを利用できる。
使い捨てのプログラムしか書いていない人には、理解できないだろうね。

>>580
俺は絶えず進化してるから使い捨てマンセー。
Win32 API を C で直接たたいて何が悪い？
オブジェクト指向はあくまで考え方、
C でもオブジェクト指向プログラミングは可能だ。

悪いが、オブジェクト指向がいらないとか言ってるレベルでは
日本人プログラマーはインド人に負けちゃうぞ。
もうちょと勉強してくれよ。

MFCのライブラリについて言えば、なにも全部クラス化すること
ないじゃんかと思う。
入力ファイル名を加工して出力ファイル名（複数）の自動生成やろう
としてCStringで閉口した経験がある。
拡張子を変えてファイル名に番号つけるだけの４文字変更なのに
なんであんなに苦労しなきゃならんのか？
結局文字列を取り出してCで書き換えたり・・・。
意味ねえっつうの。

>>582
使い捨てならなおさらオブジェクト指向だろ。
部品化が進めば、組み合わせるだけで作れる。
双方向リストを使うたびに組むのは面倒だろ？

>>584
それはMFCやC++といった環境特有の問題であって、
オブジェクト指向の問題じゃないな。
C++BuilderのAnsiStirngで、
sprintfっていうメソッドを使ってみればわかるよ。

Immutableって言葉知ってる?

そろそろ１には飽きたので、あたらしいオブジェクト指向のスレ立てていいっすか?

>>586
オッケーっす。ここの１は排除ということで(藁）
で、１はここに隔離。

ちがうな。MSは「オブジェクト指向化すれば効率上がる」という
ドグマを忠実に守っただけじゃ。

MFCみたいな代物をとりあげてOOとか言わないでくれ・・・。

いや、さすがにそこまでは言ってない　^^;

なんだなんだ。逃げる気か！
だせー

>>584
MFCを引き合いにしてオブジェクト指向を非難するのは、
VBを引き合いにして構造化プログラミングを非難するのと
同じくらい卑怯です。

すいません。質問いいですか？

まず手続きあって、それにデータを渡す事で動作するのが
「手続き型」

まずデータがあって、それにメッセージを渡すことで動作するのが
「オブジェクト指向」

こう理解してたんですが、これって合ってます？

>>593
データではなく、まず、オブジェクトありき、だ。

オブジェクト=データの時もあるし
オブジェクト=データ+手続きの時もあるし
オブジェクト=手続きの時もあるし
オブジェクト=からっぽの時もある

つか、勘違いしてそうだからいうけど、
手続き型とオブジェクト指向は同列のものじゃないよ。

手続き型言語でオブジェクト指向プログラミングをする
論理記述型言語でオブジェクト指向プログラミングをする

どっちもありだ。

手続き型言語で構造化プログラミングをする

も、ありだ。

>>593
その理解は部分的なものです。
このスレの過去レスをよく読んでみてください。

>>592
MFCはC++究極のオブジェクト指向クラスライブラリです。
あそこまでやってダメってことはOOダメってことでしょ。

つうかなんでsageで話す？ (^^;

>>596
MFC見て究極のオブジェクト指向だなんて言うなっつの！！
ありゃ単にWindowsAPIに元々あるオブジェクト指向的な考えを
そのままクラスにラッピングしただけ。
MFC独自のオブジェクト指向的なものはあのフレームワークぐらいなもの。
せめてJavaのクラスライブラリの勉強ぐらいしてから語ってくれ。

今思ったけどVC++は並列オブジェクト指向を取り入れてたりする
(^^; VC++に石を投げないで下さい。

>>596
>MFCはC++究極のオブジェクト指向クラスライブラリです。
ヲイヲイ正気かよ。
そりゃsageもするわいや

>>598
逝って良しの１と >>1 は別人か？
どうでもいいがVCの並列オブジェクト指向って何だ？

MFCはAPIをラップしたクラスライブラリ。
でもそれはそれで、十分に役に立っている。

じゃあ、構造化プログラミングを最も巧く実現している言語が
他にあるんですね？
その最高の奴はJAVAなんでしょうか？

>>602
何故そこでJavaが出てくる・・・。
まだMLやらHaskellを引き合いにだす方が納得できるぐらいだぞ。

>>594-595
どうもありがとうございます。
勉強し直して来ます。

>>600
VCはメッセージ駆動のマルチスレッドですがなにか。
MFCのビュー・ドキュメント間のやり取りなんかもろ並列。

つうか剽窃したのはワシではないので石を投げないで下さい。

>MFCはAPIをラップしたクラスライブラリ。
>でもそれはそれで、十分に役に立っている。

つーか、他に選択子が無いから使ってるだけだろ。

>>603
>>597が薦めるから。

>>605
学生か？なら今のうちに謝っとけ。
そんなもんを並列とか言ってるようじゃ話にならん。

逝って良しの１＝１です。

>>607
勝手に曲解するなよ。
MFCみたいな腐れ設計ライブラリでOO語られちゃたまらないって言ってんの。
JavaのライブラリはこれまでのOOの成果を積極的に取り入れてる。
これが最高とは言わないがそれぐらい知らなくてOO語るなっつの。

>>608
並列オブジェクト指向の並列。
完全にマルチスレッドじゃないといけないということは無いでしょう。

>>611
じゃあ並列オブジェクト指向ってのがどういうものなのか説明してみ。
多分他のプログラマから「それはただのオブジェクト指向だ」と突っ込みが入る。
それを全部論破できたら正論だ。

MFCはともかく、ATLならＯＯＰとして認めてくれるかね。
Ｃ＃のクラスライブラリはどうかね。

>>612
各オブジェクトが並列に動く奴。

ATLはMFCに比べれば随分とマシではあるが
設計思想面で言えばJavaのライブラリには明らかに劣る。
C#のライブラリなんて知ってる奴まだいないだろ。

ATL,C#が良いのですね。

>>614
「並列に動く」ってのはどういう意味だ？
「並列に動かない」ってのはどういう意味だ？
明確に区別して説明してくれ。

あう
C#＞JAVA>ATLなのですか？

>C#＞JAVA>ATLなのですか？

正式リリースされてもないライブラリがなんで比較対照に入るんだYO!

>>617
そういえばマルチCPUとか、高速で切り替えるTSSでないかぎり
並列じゃないですねー。

マルチスレッド逝って良しとワシに言わせるつもりですか？

>>620
誰もそんなこと言っちゃあいない。
「並列オブジェクト指向」と「オブジェクト指向」の違いを
はっきりさせろってことだ。

じゃやっぱJAVAなのですか？

そういえばJavaってVCLなどを参考にしたって
どこかのインタビューで出ていたよな。

ATLは多重継承をうまく利用している。

OOの初歩の勉強用にはいいよ：）＜Javaのライブラリ

各オブジェクトが並列に動くのが並列オブジェクト指向で
オブジェクト指向の集合の部分集合。

>>623
VCLはいいですよ。VCL見てからMFCがゴミだと悟りました(笑)

つうかワシにOOを語らせないでくれ。
逝ってしまう。

>>626
説明になってない。
「並列に動く」とはどういうことだ？
「並列に動かない」場合と比較してどういう違いがあるんだ？
その違いに伴う得手不得手の例示も含めて説明してくれ。

>>629
それくらい解れ。

>>630
説明できないなら出てくるな。

VCLって何？

>>629
別スレッドだっちゅうの。
得手、不得手と言われても、マルチプロセスのラベルを張り替えてる
だけなので特にないんでない？

>>633
まだ説明になってない。
並列動作＝マルチスレッド動作だとして、
それを採用した並列オブジェクト指向と
そうでないオブジェクト指向にどういう違いがあるんだ？
得手不得手に違いがないならなんで手法を分けるんだ？

それはOO支持者に聞いてください。

>>635
逃げずに説明しろ。
用語一つ説明できないでどうしてOO批判ができると思ってるんだ？

OOの用語は定義がはっきりせず理解できないのが多いつうのも
ワシの趣旨なのですが。

>>632
Delphiのライブラリで、C++Builderでも使える。
VCLを使うと、MFCの糞さがよくわかる。

でもVCLにもおかしいところが多々ある。
初期の設計は美しく感じたけど、
増築を繰り返してやばくなっているところがある。
特にウィンドウのドッキング処理はやばくて、
ドッキングすると誤動作しまくるコンポがある。

それでもMFCなんて目じゃないくらい良くできていると思うし、
それだけMFCが糞だということでもある。

>>637
じゃあなんでその理解できない用語を使ってるんだ？
理解できないものをわざわざ使う理由は何故だ？
MFCのDocView構造を並列オブジェクト指向と呼ぶような奴はいない。
となれば、あんたはあんたなりの理解に基づいてそう言ったわけだ。
その理解がはっきりしていないと言うなら、どうしてそんないい加減な知識で批判ができるんだ？

得手不得手と関係無くMFCのそれは並列OOじゃんか？

>>637
そうそう、うっかり忘れるところだった。
並列オブジェクト指向とオブジェクト指向の違いも説明してくれ。
用語の曖昧さはそれはそれ、これはこれ、だ。

>>641
自分で説明してくれ。
ワシは寝る。

>>640
人の発言はよく読め。
MFCのDocView構造を並列オブジェクト指向と呼ぶような奴はいない。
並列オブジェクト指向とオブジェクト指向の違いを明確にした上で
DocView構造が前者の条件を満たすことを示してくれ。

>>642
俺も寝るが、自分の使った言葉を責任をもって説明するまでは
誰もあんたの言うことなんか聞かんだろう。
それはOO以前の問題だ。

じゃあおやすみ。

説明はしてるだろーが。
まるでマルチスレッド知らないみたいなレスだな。
集合概念もわからないみたいだし。
得手不得手なんて質問で都合の良いフレーム作って詰問してるだけじゃんか。

>>643はいちいち人に「これは並列OOP」「これはちがう」と指摘してもらった
のを暗記するタイプの人なのね。

結局1は教えてほしかったわけか…。それなりに教えてもらえたようだけど、
変な煽り方のせいで無駄が多くなったね。
馬鹿意見も混じってるからちゃんと理解できたんだかどうだか。
並列オブジェクト指向と言えば、簡単にいえば全てのオブジェクトが
スレッドを持っていて、メッセージが来るのを待ち受けている(サーバみたいなもの)。
メッセージが来ると(メソッドが呼ばれると)要求メッセージはオブジェクトのキューに
溜められて、オブジェクトに割りあたってるスレッドが順次処理していくわけ。
メッセージの発信元と受信オブジェクトは完全に非同期になるものだよ。

>>645
おはよう。

>各オブジェクトが並列に動くのが並列オブジェクト指向で
>オブジェクト指向の集合の部分集合。

この論法は並列というキーワードを入れ替えても通用するよな？

>各オブジェクトが直列に動くのが直列オブジェクト指向で
>オブジェクト指向の集合の部分集合。

>各オブジェクトがまったり動くのがまったりオブジェクト指向で
>オブジェクト指向の集合の部分集合。

はめこむキーワードの意味を定義しなければ説明にならん。
集合と言うなら X = { x | ... } の ... で使われる述語の説明が抜け落ちてる。

得手不得手を考えるのは技術者として当たり前のことだ。
特性の分からん技術を訳もわからず使い分けて飯食ってるのか？
OOと呼ばれているものと旧来の技術とでは
得手不得手に違いがないのにOOの方は分かりにくい、だから意味がない
あんたの論法はそういう論法ではなかったか？

>>645

俺の聞きたいことは簡単だ。

・並列オブジェクト指向とオブジェクト指向の違いを明確に示してくれ。

・その上でMFCのDocView構造が前者に属することを示してくれ。

・並列オブジェクト指向が明確に定義できないと言うなら
　どうしてDocView構造をそう呼ぶのか分かりやすく説明してくれ。

他のプログラマはDocViewを並列オブジェクト指向とは呼ばない。
つまりあんたは人から聞いてそう思ったのではなく
自分なりの考えでそう判断したわけだ。
その判断が正論ならば他のプログラマも話を聞くが
真っ当な理由がないなら単にあんたがオブジェクト指向を
理解してないDQNだと判断するだけの話だ。

やっぱOOはかなりヤバイ概念だな。脳を侵食する。
真面目に勉強すると逝ってしまう。
従来通り、デバイスはデバイスと呼ぶことにしよう。
画面の表示物体は従来通りオブジェクト・・・ってあれ？
オブジェクト指向が出て来るずーーーーと前から表示物体は
CGの方ではオブジェクトと呼ばれていたのだ。
デバイスーデバイスドライバ構造
表示物体ー表示物体ドライバ構造
こう呼ぶことにしてOOP依然の概念をしっかり把握することにする。

依然＞以前

>>646
オブジェクト指向の解説に載ってた定義からすると、
各オブジェクトが自立動作しててもいいんじゃないの？

いろんな専門家？がOOのオブジェクトに望んでいる機能と、
現在のOOPLで実現できるプログラムが行っていることって、
ぜんぜん違う気がするねえ。

あと、オブジェクトという単語自体が指し示すものは、全ての
抽象概念のメタだと思うよ。
>デバイスーデバイスドライバ構造
>表示物体ー表示物体ドライバ構造
4つともオブジェクトの一種。

MFCのビュー・ドキュメント構造が並列オブジェクト指向

相手の論法で相手の論理をおちょくったつもりだったが、
相手はショックを受けて考え直すどころか、定義からの分類も
判らない暗記型人だった。
そういうこと。

>>652
そうだけど、危険思想なのでワシは避ける事にします。

>>653
話をそらさずに答えてもらいたいものだな。

>>32 の論法を使わせてもらえば
質問再掲
並列オブジェクト指向の利点ってなに？

>>176 の論法を使わせてもらえば
「並列オブジェクト指向」って概念を使ってなんか特殊なプログラムを書けるのかい？

>>65 の論法を使わせてもらえば
やれやれ、結局 1 は判ってなかったのか。

つうことで、「DocView＝並列オブジェクト指向」とは
「オブジェクト指向を礼賛する奴は「マルチメディア」を礼賛してた
やつと同じ。本質がわかってない。」と同じで
これが真実だと言うと「んなわきゃない」と主張してる人から叩かれる
一種の宗教ということが証明されました。

＊＊＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊＊＊＊＊＊

>>651
それはなんの本だ?引用してみそ。
OOというところのオブジェクトは並列だろうがなんだろうが関係ないが、
並列OOというからには定義があるぞ。
並列OOはOOの一種というのは言うまでもないでしょ。

>>655
ああ、ちょっとミスったな。以下の通り訂正させてくれ。

>>65 の論法を使わせてもらえば
やれやれ、結局 1 は判ってなかったのか。

つうことで、「DocView＝並列オブジェクト指向」とは
「オブジェクト指向を礼賛する奴は「マルチメディア」を礼賛してた
やつと同じ。本質がわかってない。」と同じで
これが間違いだと指摘すると「んなわきゃない」と主張してる 1 が喚きたてる
一種の宗教ということが証明されました。

＊＊＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊＊＊＊＊＊

>>649
C言語ですらオブジェクトという用語が使われている事を知らないのか?
だから「オブジェクト指向」でしょ。言葉どおり受け取ればそんなに疑問は無いと思うが。

529 です。

554さんまだ？まさか554さん==1さんなの？？

ま、技術は１の蚊帳の外で進んでるんだよ。
わかんない人叩いてもかわいそうだからもう終わりにしませんか？

>>578
あたりで、ちょっと壊れた人だとおもいました。

529 です。

僕は554さん待ちなんで週明けまで一人ﾏﾀｰﾘ進行する。

>>660
進んでないっつうの。
殆どは旧来の技術の言い換え、剽窃。

既存の技術を一歩推し進めた概念にパクリもくそもない。
言い換え結構。
そう言い換えれば共通言語のもとに物づくりができるってことさ

あ、554はワシではないよ。
いくらなんでもインタプリタをOO概念だなんて言わないわい。

全然共通化進んでないじゃんか。（泣

Windows９５はWindows３．１のパクリです。
剽窃は許せませんです。逝ってよしです

だからあんたも空気のようにその恩恵にあずかってるんだってば。
あんたは「ソフトごときに金が払えるか」といってるワレザーと同等。

↑
あんたってのは１のことね

それにしても人の話を全然聞かないやつだな…。できるだけ好意的に見てやろうとしてたのに。
自分の主張もまともな根拠が認められないし。たまに出てきて
つまらんレスしか付けないんだから、悲惨な1の資格ありだぞこのままじゃ。

>>666
どこがどう進んでないのか逝って見ろ

>>1
648 の質問に答えてもらいたいんだがな。
それとも答えられないのか？

やれやれ、ろくにスレ読んでない人が言葉に反応してるだけか。
多くの人が前の文章を読まないのを狙ってなのか
「質問に答えてない」とか言いつづけてる奴もいるしな。
それとも日本語が読めないのか。
オブジェクト指向の正体は群集心理かもね。

>>673
まさか理由付けを行うことをしないままで
「DocView構造を並列オブジェクト指向として定義する」とでも言うのか？
その論法を使うとおよそどんな言葉でも自由に定義できるな？
「言って良しの１をOOの理解できないDQNとして定義する」と言っても異論はないわけだな？

それって俺のことかな？

>>1　はどの言語を使う、または使えるのか明確にせよ
>>１　はオブジェクト指向の恩恵を受けているのか、いないのか述べよ
>>１　はどのようなシステムを構築している、もしくはしたことがあるのか述べよ

オブジェクト指向なんて考え方次第。
Cでもオブジェクト指向なプログラミングはできますよ。

ところでなんだか子供の喧嘩みたいになっているのはなぜ?

>>676
過去ログ参照のこと。特に >>1 が周囲を無視する様子を。

プログラマって暇人多いんだね
どーんなに相手がおばかでもまめにレス
返してくるならこんなに話し続けるんだもの

全く、ここに居るやつはひまじんばっかりだな。

>>665
529 です。

554 さん != 1 さんとのこと了解。554 さんは Interpreter パター
ンやインタプリタを指してOOだなんて言ってないよ。

>>676　こういうそれまでの流れを無視して見下した言い方する奴が一番むかつく。
しかも内容が。。。
オブジェクト指向設計したものをCでプログラミングするなんて想像したくも無い。

>>678
>>679
こういうのを楽しむのが２chの醍醐味でないかい？(藁

OO初心者なんですけどMFCのドキュメントビューって
並列オブジェクト指向と呼ぶべきものなんですか?
このスレだけを見ているとどちらが正しいのかよく分からない….

>>681
Cの方が組みやすかったよ。

>>680
共通のOO概念があれば上層インタプリタ概念が少ないコミュニケーションで
理解できる、とかだったけどね。

>>683
ワシが保証しましょう。
でも概念に振りまわされちゃダメよ。

>>685
ありがとうございます.
もしよろしければMFCを学ぶ上で
お勧めの本なども教えてください＾＾；
MFC難しいです….

VISUALC＋＋プログラミングテクニック（アスキー出版局PPS）

>>687
すばやいレスありがとうございます＾＾
早速本屋でチェックしてきます!!

でもOO信者にMFCのビュードキュメント構造が並列オブジェクト指向
などと言わないほうがいいです。
並列OOは時代の最先端を行く未知の技術だと信じてる人に
MFCが並列OOだなどと言おう物なら相手の感情を害するだけです。
オレモナー。

単なるテンプレート構造と並列OOを取り違えている上に
人の言うことも聞かずに他人に適当なこと教えるのはどうかと思うがな。
そういうひねくれた物言いは煽り以下の最低な部類だと思うぜ >>689

言っとくが俺このスレに初カキコなんで。

そんな抽象的な批判でなく、並列OOの定義はこう、MFCのはこうだから
MFCのは並列OOではないと論理的に話せないものだろうか？
あ、MFCはテンプレートでもあるね。VD構造以外の部分もね。
でも並列でもあるよ。

論理的に話そうとして言ってることの意味が
わからなくなるのは良くあることなのですか？

>>691
並列OOという言葉を持ち出した当人が
それで目を丸くした他人に言葉の説明を迫るとはこれいかに？

>>693
ワシの方は理由を説明し終わっている。
それでも違うと言うのなら別の説明をすべきだという話の流れ。

質問：MFCってDocumentとViewそれぞれ別個にスレッド割り付けてあるの？

漏れはDel使いなので分からん。
普通そういうことはしないと思うんだが実際のところどうなん？

>>695
んなわけネージャン。
DocumentとViewは単にプログラミングの手法に過ぎん。
内部でスレッドに別れてたらお笑いだぜ。

>>696
現状のシングルプロセッサのPC＆C++みたいな言語で
マルチスレッドや内部言語処理系も持たずに並列OOってできるの？？

>>697
ここの並列○○ってクラスタとかSMPのことだったわけ？
違うでしょ。

>>698
そもそも並列OOってよく分かってない(笑)
>>646 氏の説明に沿うとマルチスレッドも内部言語処理系もなしで
どうやるのか想像ができんですよ。

>>695
DELって知らないけど、
VC（MFCも）について言えばマルチウインドウに対応するため
でしょう。
外部要因による再描画の必要がなければ要らないでしょうね。
全画面バッファしてOSが勝手に再描画としなかったのは
メモリ節約の為でしょう。

>>700
マルチウィンドウに対応するためにマルチスレッドを使ってるの？
MDIでチャイルドウィンドウひとつづつに
スレッドを用意するなんてのは聞いたことはあるよーなないよーな。
MFCはデフォでそういう実装になってるの？？

ここ放置スレだろ？もういいからsageでやれよ。

>あ、MFCはテンプレートでもあるね。VD構造以外の部分もね。
>でも並列でもあるよ。

ｵｲｵｲ･･･
表示部とデータ部の並列性をもって並列OOとまで呼ぶか。
MSも大喜びだな。学会にでも発表して笑われてこい。

んじゃ聞くが、
1)STL使うだけで並列OOの実装か？
2)1:nでDoc-Viewは構成できるが、それも並列か？
3)Doc-Viewのユニットが他のDoc-Viewとの調停機構を持っているか？
4)Viewの存在しないDoc、Docの存在しないViewのインスタンスは
　どう解釈するのか？　　　　
5)CWinAppが破壊されてもDoc-Viewの処理は非同期で続くか？

>>693
俺も目を丸くしてもいいかな。

>>702
おもしろいJAN！

529 です。

554 さんが来るまでスレだけは残しといてね(笑)

OOは悪くない。
悪いのは厨象論を並べ立てて悦に入っているOOの教科書。
クラスとは構造体の定義と関数の宣言を一緒くたにしたものである。
継承とはメンバの追加をコンパイラにやらせる仕組みである。
これでいいじゃんの。
泥臭い?ほっとけ。

だからsageでやれって。

ああ、複数のウインドウの事ね。
重ね合わせなどで別々に再描画しなきゃならない。
MFCじゃなくてOSがやってるでしょう。

IE二つ立ち上げてこのプログラマー版のロゴを半分重ねて見てみれば？

>>708
OSの内部処理どうやって調べたんだYO!
見た目でマルチスレッドかどうか分かるのかYO!

…と言いつつsage(藁

>>703
難しくてわかんないです。

抽象的な議論で結論が導き出せないのは
日本の会社ではよくあることです。
そろそろsageませんか？

>>710
703 じゃないけど

> 5)CWinAppが破壊されてもDoc-Viewの処理は非同期で続くか？

並列OOなら処理フローにおけるオブジェクトの独立性があるから
CWinAppがなくてもDocumentとViewの処理は同時並列に行われるはず。
それは本当か？

・・・という意味だと思われ。
俺 MFCしらんから保証はできないけど。

KERNELやUSERにアニメーションGIFの描画ルーチンが
入ってるとしたらそらえらいことだが。

OO以前に分かってないことが多すぎるんじゃないか・・・。

>>712
本当にそうならWordがクラッシュしても書きかけ文書を
救済する手立てはいっぱいありそうだがな。
あいにくそうじゃないのよ。

MFCのDocument-ViewはCWndか何かの派生になってて
Win内部のメッセージ機構使ってるのか？
それ以前にこの程度のモデルでそんな並列化してたら
メンバ変数へのアクセス制御が面倒で仕方ないと思うが。
いちいちクリティカルセクション作ったり、、うざすぎ。

>>1
>並列OOの定義はこう、MFCのはこうだから
>MFCのは並列OOではないと論理的に話せないものだろうか？

っていっといて難しいからわかりませんはないだろ。
700レスも引っ張っといてそのザマか？

>>703
529 です。

僕はMFCも並列OOもきちんとフォローしたことがないんで黙ってる
けど処理フローの独立性は少なくとも必須条件だと思う。１さんも
この部分だけははっきりさせておいた方がいいんじゃないかな？
712 さんの質問に答えておくべき。

>>718
529 です。

失礼。718 の >>703 は >>710 の間違い。

せんせー、そもそもOOってなんですかぁ？
なんかの略なのぉ？

>>720
Oo itteyoshi!! Omaemona- の略。

>>720
ここで聞け

http://www.edu.pref.ibaraki.jp/kodomo/top.htm

ObjectOreantedだっけ？
オブジェクト指向のこと。

>>723
で？ >>712 への返答はどうよ？

んー、今思ったけどCtrl-Alt−Delでタスク一個しか出てこないな・・・。

ｴﾗｿｳﾆｶｲﾃ ｼｶﾓ ｽﾍﾟﾙﾐｽ ﾒﾁｬｶｺﾜﾙｲ

>>1
つーかおまえさ、AfxBeginThread()も使ったことないだろ。
プロセスとスレッドの違いわかってる？

>>725
まさかスレッドとプロセスを混同してるんじゃ。

ところで、
タスクマネージャをいちいちCtrl-Alt-Delで
起動してるのですか？

本当はSDK知らないでMFCしか使ったことなかったりして。
そうだとしたらもうおしまいですな。

>>729
SDKどころかMFCそのものを知らないと思われ。

晒しageにするの？とりあえずsage

>>1 はVCでMFCかじって OO以前に自爆した厨房と判明しましたsage

同じ様なもんじゃない？

>>733
同じもんだったらなんで分けるんだYO!
YO!YO!YO!

俺は１がMSDN必死で読んでる間くらいはsageでかまわんよ。

スレッドはマルチプロセス実現の手法の一つじゃない？
他にはTSSがあるね。

ヲヒヲヒ。ひょっとして元COBOLERか？

>>1
おまえおもしろすぎる。

あれだな。
経験値だけは高いCOBOLERでWinとVCに触れてMFCを眺めて
「なんだこのちーぷなしすてむわ。これがOOなのか」
とか思ってそのまま勘違いしてしまったタイプだな。
みんな、そっとしておいてやろうぜ。な？

>>739
いやちがうって。このスレ１からみてみなよ。
コンピュータ基礎もしっかりやった格上の人間との事だ。

ここから100個ほどの間の1のﾚｽが面白過ぎage
ちゅうか珍しい人もいるもんだ(藁

>>736
OSによって揺れはあるがWindowsじゃ次の通りだ。

プロセス：アプリケーションインスタンス
スレッド：ファンクションインスタンス
ファイバー：継続(教養があるならSchemeぐらい知ってるな？)

プロセスとスレッドではリソースに対する考え方が違う。
スレッド間でプロセスの保持するリソースを共有できる。
現実面で言えば実行コストにも差がある。
アセンブリレベルでは実装も全然違う。

>>742
ちょっとだけ突っ込み。
プロセスにはプライマリスレッドが割り付けられて
そっちで実際の実行処理が行われるから
プロセスはリソースホルダとしての機能がメインだよ。

スレの趣旨とは異なりますが
１をたたく（あるいは１がたたかれているのを見る）スレとしては上出来でしたね。

＊＊＊＊＊＊＊＊＊ 終了 ＊＊＊＊＊＊＊＊＊

529 です。

554 さんが来るまで終了はしないで(笑)

実験してみたけど、ドキュメントの中で（read()）とかでブロックすると
ビューも止まる。
別スレッドというのは間違い。
少なくともDocからビューへのスレッドの切り替えは行われていない模様。
判ってた人には私が間違ってましたと言っておきます。

でもスレ読み返すと判ってなくて叩いてる人もいるのでそれは除外。

>>747
お。自分で実験したのはえらい。
Doc-View==並列OO説も撤回？

間違いです。すいません。

>>749
漏れに謝られても困るけど(藁
謝るなら >>683 だと思われ。
このスレ読んでるかな？＜683

このスレ、全部読んでみたけど面白かったヨ。
でも後半はなんか Windows に特化した話になってツマラン。。。
ところで 1 は大阪弁になったり、江戸っ子風、ですます調、である調、
煽り調とかなり多態だな〜。違う人？

今更だけど 130 の >>374 良いね〜！

1も謝ったことだし

#==========終了======================

130=751のｼﾞｻｸｼﾞｴﾝ厨うぜぇ

>>753
？違うぞ。しかし、頭悪そうなやつに半角カタカナ使うやつ多いナ。

７００かけてようやく己の非を認めたか。

長かったな。

>>755
しかし認めたのは「Doc-View構造!=並列OO」のみであって
「OO==剽窃＋曖昧な抽象論==ゴミ」という部分には触れてないぞ。

あれだけ自信満々に言ってた事がとんちんかんだった事にやっと
気付いたのだから、他の主張についても疑う気持ちくらい芽生え
てくれている事を期待する。

>>757
芽生えてないと思うぞ。

>>747
>でもスレ読み返すと判ってなくて叩いてる人もいるのでそれは除外。

そんな奴いたか？

芽生えてませんが何か？

はいはい。偽者やって煽り入れなくてもいいからsageろって。

途中から読んでませんが、Doc-View構造なんてOOP以前に
真面目に議論する対象ではないような気がするんですが。

オブジェクト指向以前、構造化プログラミング以前から、表示と内部データー
なんて分けるのが当たり前だったよ。
APIで組んでもやっぱし分けるね。

>>762
まだまだ懲りない粘着君発見!!!
あっ、ageちゃった。

だから何?としかいいようがない-_-

>>1 は分類としては既に電波ではないかと思うがどうよ？
小物叩きスレに出てる奴との類似点ありまくり。

>>762
俺もさ、オブジェクト指向やドキュメントビューが流行していると言うからさ、
Ｃ言語でそれなりに分離とか隠蔽とか考えながら作ってたよ。
１０年前にはこれが多分オブジェクト指向なんじゃないかと思い込んでいた。

その後になってC++をやりはじめて、大失敗を経験してから、
ようやくオブジェクト指向とは何なのかわかってきた。
それまでまったくオブジェクト指向のことを理解してやしなかった。
昔やっていた真似事は、真似事にすらなっていなかった。

これがオブジェクトだと決めただけではオブジェクト指向にはならないし、
データ管理と表示モジュールを切り分けただけではドキュメントビューにはならない。
それを理解できるようになるには、１がオブジェクト指向への疑念を晴らした上で、
実際に２年くらいプロジェクトで経験してみるしかないだろうな。

そりゃ、全体の設計が巧く出来ない人はファイル分離したって巧くなるわけが
ないわな。766はそう言う意味だろうか？
説明を省略するのはOO派に多いなー。
COMが（シリアルIOの）OOだって言ってた人はいったいドウナル？
DirectXはOOモジュールですか？

COM＝Component Object Model

何を言ってるんだこいつは？

　∧ ∧ 　 　　 ／￣￣￣￣￣￣￣￣￣
　( ﾟ∀ﾟ)　　＜　　逝ってヨシ
　 | つ[|lllll］).　＼＿＿＿＿＿＿＿＿＿
〜| 　 |
　 ∪∪
http://freezone.kakiko.com/omaemoner/ite.swf

762で逝ってるのは隠蔽とか保護とかのレベルじゃないのか。
ファイル分離ってなんだおい！！！！

＞構造化プログラミング以前から、表示と内部データー
＞なんて分けるのが当たり前だったよ。

表示サブルーチンとデータ保持構造体を「ファイル」で
分けてましたって言ってるだけじゃねーだろうな。
いや、なんとなく聞こえるぞ。

保護や隠蔽は実現のための手法であってインタラクションの方が重要だろ。

>そりゃ、全体の設計が巧く出来ない人はファイル分離したって巧くなるわけが
>ないわな。766はそう言う意味だろうか？

それじゃあどういう設計が巧い設計なのだ？
そして感覚や経験だけで巧いか下手かを判断しているのか？
そこを学術的に体系立ててまとめなおし、論理的に巧拙を判断できるものが
オブジェクト指向だということに気づけアホ。

あと大失敗したと言うのは、オブジェクト指向のメリットが全く発揮できなかったというレベルの話。
構造化設計レベルの話なら十分に成功と言えるものだったよ。

DirectXもCOMだね。
DirectXなんかオブジェクト指向ばりばりやんけ。
X8でX7のインターフェイスを取得できるだろ。

いまどきオブジェクト指向を知らないで仕事しているやつがいるとは…。
JavaやDelphiとかを触ったことも無いの？
あれのクラスライブラリってオブジェクト指向丸出しだから、
使っているだけで理解できるようになるでしょう。
MFCじゃ理解できるようにはならないと思うけど。

１がオブジェクト指向に持つ偏見と誤解にはあきれるばかりだ。
よほど自分の設計とプログラムに自信があるんだろうな。
これだけオブジェクト指向がもてはやされている中で、
それを覚えようという気がおきないのだからたいしたものだ。

偏見や誤解以前に無知に過ぎると思われ。
せめて使用言語やライブラリ、OOでの実務経験を述べて欲しいところ。
C++とMFCのみとか言ったら極刑ものですな。

>>775
そんなの、ほとんど経験がないにきまってるじゃん。
経験があったらここまで無知じゃないだろ。