OOスレ10 なぜオブジェクト指向は普及しないのか

OOスレ10 なぜオブジェクト指向は普及しないのか at PROG

1:仕様書無しさん
08/05/17 08:50:17
過去ログ
part 1 ｽﾚﾘﾝｸ(prog板)
part 2 ｽﾚﾘﾝｸ(prog板)
part 3 ｽﾚﾘﾝｸ(prog板)
part 4 ｽﾚﾘﾝｸ(prog板)
part 5 ｽﾚﾘﾝｸ(prog板)
part 6 ｽﾚﾘﾝｸ(prog板)
part 7 ｽﾚﾘﾝｸ(prog板)
part 8 ｽﾚﾘﾝｸ(prog板)
part 9 ｽﾚﾘﾝｸ(prog板)

おじゃばは簡潔に書け　自演とオレオレルールも禁止
その他はスルー技術を身につけれ
おじゃばの低能はデフォ　熱くなった方が負け

2:仕様書無しさん
08/05/17 14:48:51
低能晒し続けて１０スレ

3:仕様書無しさん
08/05/18 09:39:47
おつ

>>999
古臭いってのも判るが、コードが簡潔に纏めることになる以外の
try-catchの利点ってわからんのよ。

実は以外に利点の説明って本にも載ってないし。
誰か利点教えて。

4:仕様書無しさん
08/05/18 10:14:34
try-catchの中に分岐判断ロジックを書かなくてよい、ってことじゃ？

5:仕様書無しさん
08/05/18 11:15:21
スレ違いも甚だしいのでム板でどうぞ

6:仕様書無しさん
08/05/18 16:00:53
せんせい！質問！！！
「おじゃば」土日には出現しないんですか？

# 以下独り言
# だとしたら、とんでもない穀潰だな、社会的には

7:仕様書無しさん
08/05/18 21:12:55
try-catch の利点がわからんとか言うやつはまず例外とは何ぞやというところから考えてみろ。

>>5
まあこのスレの内容はほとんどがスレ違いだから目くじら立てなくてもいいんじゃね？
>>6
>だとしたら、とんでもない穀潰だな、社会的には
そうじゃなくても明らかにry

8:仕様書無しさん
08/05/18 22:12:13
>>7
wiki からの抜き出しだけど、以下の様な内容だと考えている。

>例外が発生したことを見落として正常時の動作を継続してしまうと、
>より深刻・致命的な異常を招くおそれがある。それを避けるには例外が発生したことのチェックを綿密に行い、
>例外が検出された場合には適切な事後処理を行う他ない。

でもさ、例外処理で本格的な後始末やってる奴いるか？
精々メッセージボックス出す位だと思うが。
後はファイルやDB接続をきったりするわけだとか。

そもそも、try-catch内に複数の関数があった場合どれが原因なのか精査できるの？
知っている限りでは、システムのエラー番号をとったりする位だが。

例えば、WindowsのODBC使っている時にDBに対してSQL文発行が失敗した場合の後始末処理の仕方
ってどうやるか、想像つく？

9:仕様書無しさん
08/05/18 23:27:57
>>8
catchでディスパッチできるっしょ？できない時はtry{}catchを複数書くしかないね。

俺は寧ろメソッド単位のfinally句の必要性を強く感じる。
finallyで処理する為に変数の宣言位置がtryの外へ出ちゃうとか煩わしいし
メソッド内が巨大なtry{}catch{}finallyに囲われてるのも気分悪い。

AOP的にメソッドの前と後、そしてエラー時の振る舞いをメソッド外に書けると楽
なんだけどね。
ただスコープの問題(エラー時の振る舞いをメソッド外に記述できるとして、この
メソッド外からどの範囲の変数が見えて良いのか、または見えなければならな
いのかって事ね)が絡むんでどうするのが良いのやら('A`)

10:仕様書無しさん
08/05/19 00:01:46
いい加減やめないか

11:仕様書無しさん
08/05/19 02:00:29
いい加減やめろと言われてやめるほどまともな人はもうこのスレにいねーよ。
>>9
昔のMSBasicのon error gotoや、
RM-Basic(HP)のException Sectionは良かったのかな。
後者は関数や手続きにひとつ例外処理部があるってやつ。
ただスコープの問題はしょせんERRORLEVEL程度だけどね。

12:仕様書無しさん
08/05/19 02:54:56
>11
自己紹介乙

13:おじゃばさま ◆GxjxF3yEw6
08/05/19 11:05:33
なんか前スレ見えなくなってるのだが。これはどうなった？間違いなのか？

URLﾘﾝｸ(e-words.jp)
オブジェクト指向　【object oriented】
読み方：オブジェクトしこう
分野：プログラミング > オブジェクト指向 > オブジェクト指向
▼ 関連用語
　ソフトウェアの設計や開発において、操作手順よりも操作対象に重点を置く考え方。
　関連するデータの集合と、それに対する手続き(メソッド)を「オブジェクト」と呼ばれる一つのまとまりとして管理し、その組み合わせによってソフトウェアを構築する。
　すでに存在するオブジェクトについては、利用に際してその内部構造や動作原理の詳細を知る必要はなく、外部からメッセージを送れば機能するため、特に大規模なソフトウェア開発において有効な考え方であるとされている。
　データやその集合を現実世界の「モノ」になぞらえた考え方であることから、「オブジェクト」指向と呼ばれる。 … 続きを読む

URLﾘﾝｸ(itpro.nikkeibp.co.jp)
オブジェクト指向が登場した背景
　オブジェクト指向は，英語では“object oriented”であり，「もの指向」「もの中心」といった意味を持ちます。
一言で表現するなら「オブジェクト（もの）中心に考えるソフトウエア開発手法」と言えるでしょう。
　従来の開発手法は，ソフトウエアが実現する「機能」に着目しました。
最初に全体として実現する機能を定義し，それを徐々に細かい機能に分割していくのが基本的なやり方です。
この手法は「構造化分析/設計手法」として体系化されており，長い間主流として使われてきました。
　オブジェクト指向では全体の機能を一枚岩ととらえずに，データと手続きを持った「オブジェクト」の集まりとしてとらえます。
ソフトウエア全体として機能を実現するだけでなく，保守性や再利用性に配慮して，個々の部品の独立性も重視するわけです。

14:仕様書無しさん
08/05/19 11:41:42
>>11
いや、スコープこそが問題だよ。
スコープの問題気にしないならAOPでも、もっと単純なDynamicProxyでも前後処理は
挟めるし、例外処理に至ってはcatch句の処理をメソッドへ追い出しゃ済む話だ。
スコープ通そうとするとリフレクション使って捏ね繰ってもできるかどうかはやってみな
いと分からない。少なくとも直ぐには思いつかない。

15:仕様書無しさん
08/05/19 11:48:50
>>13
前スレで答え出た。
ある種のOOを説明してはいるけど具体性に乏しく実務的じゃない。
言葉遊びと薀蓄語りがしたいならその抽象的なOO捏ね繰り回せばいいじゃん。
その手のOO話したがる奴って薀蓄本読んだだけの門外漢ばっかじゃん。
玄人素人は問わないにしても、仮にもマ板だろ？
プログラム書けない奴はプログラマーって言わないんだよｗ

16:仕様書無しさん
08/05/19 12:36:42
>>13
優しい俺様が前スレからピックアップしてコピペしてやる。
読めよ、バカ野郎。

949 ：仕様書無しさん [sage] DATE:2008/05/16(金) 19:59:45
>>943-944
この辺が一番尤もらしい説明のような気がするが
URLﾘﾝｸ(d.hatena.ne.jp)

963 ：仕様書無しさん [sage] DATE:2008/05/16(金) 21:16:08
>>961
客向けには正しいが、俺たちには間違いだろうな。
とくに>943は全部嘘だ。だってお前、動物うんぬんがろくでもないと思ったんだろ？俺もだ。
>944は、下の５行、「構造化」を「手続き型」に、「オブジェクト指向」ないしは「オブジェクト」を
「構造化」に置換しても全く意味がとおる。データ構造＋アルゴリズムってな構造化の本尊が言ってたことだ。
よってこれもあまり説得力はない説明だな。
だが営業のトークとしては通る。しかたないことだな。

966 ：仕様書無しさん [sage] DATE:2008/05/16(金) 21:38:43
>>961
薀蓄本は読みやすく部外者には耳当たりが良いから広がりやすい。でも、実務的ではない。
>>943-944は薀蓄本的OOの説明で実務的ではないけど、>>949が示す様にOOにも色んな
種類があるから、間違ってるってわけでもない。

968 ：仕様書無しさん [sage] DATE:2008/05/16(金) 22:07:40
>961
だから初心者にもわかるようにかみ砕いてかみ砕いた内容だろ？
で、お前はいつから基礎の基礎より上のステップへ進むんだ？

17:仕様書無しさん
08/05/19 13:59:56
せんせい！しつもん！！！
「おじゃば」は、書き散らかすだけ書き散らしていっさいレスを読まない人ですか？

18:仕様書無しさん
08/05/19 19:33:26
おじゃばって１スレ目からいたの？

19:おじゃばさま ◆GxjxF3yEw6
08/05/19 20:08:00
優しい16にはお礼を言っておこう。ありがとう。
で内容についてだが、「オブジェクト＝データ＋処理」かって話だぞ。そんなに難しい話ではないだろう。
963は間違いだと言っていて、966はOOにも色々あるから間違いではないと言っていて、
966は基本だ（正しい）と言っている訳だな。結論は出ていないのではないか？

>>963
944の下の5行？下の2行の間違いかな？下から5-3行目は構造化の説明だからな。
>構造化では全体の機能を一枚岩ととらえずに，データと手続きを持った「構造化」の集まりとしてとらえます。
”データと手続きを持った「構造化」”は意味不明だな。モジュールや関数にすれば意味は通るが間違いだ。
第一、「オブジェクト＝概念に基づくインタフェース」でデータは関係ないと言う話だろう？
何で今度は構造化が「データと手続き」になるんだ？

>>966
はてなのページを見たが、メッセージの話は基本的に読者の読み違えだ。
メッセージをメソッド呼び出しと解釈すれば、1番と2番は同じ意味だ。
3番目は意味不明。聞いたことない。ただ例の「thisの型判定禁止」とか言っているのを見る限りでは、
なんか別の話を勘違いしているように思える。ウィリアム・クックと言うのも知らない。
まあ、詳細が分からないので確かなことは言えないが、マイナーである事は確かだ。

20:仕様書無しさん
08/05/19 20:15:44
>>19
構造化、を構造と読めないのか？とことんバカだな。
オブジェクト指向とオブジェクトをまったく別の単語にするのか？
お前、日本人か？ｗ

21:おじゃばさま ◆GxjxF3yEw6
08/05/19 20:16:18
結局確認したいのは、
オブジェクト指向：オブジェクト＝クラス＝データ＋処理
構造化：モジュール＝関数＝処理

963を見ると構造化も怪しいので、確認しておこう。
説明が、客向けで抽象的だと言うなら、上の説明はPGでも分かる具体的な内容だろう。
オブジェクト指向：オブジェクト＝概念に基づくインタフェース（処理）
って話が正しいのかって事だ。これが解決しないと先には進めないだろう。

22:おじゃばさま ◆GxjxF3yEw6
08/05/19 20:20:28
>>20
だからその「構造」って何だよ？
関数？構造体？ライブラリ？構造化なのでクラスはないぞ？

23:仕様書無しさん
08/05/19 20:24:53
>>16が貼ってない分。
975 名前: 仕様書無しさん Mail: sage 投稿日: 2008/05/17(土) 06:07:12
そっか、実務経験、つかやったことしか頭に入らないからLinuxもやった当時
の知識のまんまなんだ、おじゃばって。なんか納得したぞ。
でもさ、本もまともに読まないで、俺は実務経験あるからお前らに教えてやる、じゃ
まるっきりコボラーのジジィじゃん。コボラーだって業務の勉強はそれなりに
本読んだりしてるよなあ。
976 名前: 仕様書無しさん Mail: sage 投稿日: 2008/05/17(土) 08:01:35
まさしく、「JavaやってるのでOO分かってます」だな

よ、じじいｗ

24:仕様書無しさん
08/05/19 20:29:01
>>22
お前、結局構造化もなんのことだかわかってねーじゃん。
>URLﾘﾝｸ(www.fukkan.com)
そんなんでよくそれは構造化だのOOだの言えたもんだな。

お前、ホントに実務経験あるのか？

25:仕様書無しさん
08/05/19 20:40:11
>>19
966だが俺は基本だなんて言ってないぞ？
抽象論としては間違ってるってわけでもないと突き放しただけだ。

26:仕様書無しさん
08/05/19 20:41:03
おじゃばのOO、ってのはどんなI社(笑)の実務経験からくるのか興味はあるな。
俺らが普通想像するI社(笑)があのI社だったら、ほぼ営業妨害に等しいほどバカなことを言ってるわけだがｗ

27:仕様書無しさん
08/05/19 20:42:19
構造化プログラミング＝アルゴリズムとほぼ等しい

28:仕様書無しさん
08/05/19 20:52:59
>>21
インスタンスはどうなるんだ？

29:仕様書無しさん
08/05/19 20:56:21
クラスはオブジェクトじゃないよなぁ。

30:仕様書無しさん
08/05/19 20:58:13
>>22
>こうぞうか？かんすう？こーぞうたい？らいぶらり？
>まだしょうがくせいなのでわかりません＞＜

まで読んだ

31:仕様書無しさん
08/05/19 20:59:09
URLﾘﾝｸ(www.nicovideo.jp)

32:おじゃばさま ◆GxjxF3yEw6
08/05/19 21:30:48
>>23
どうでもいいから21に答えてくれ。

>>24
文脈は、
「技法」では全体の機能を一枚岩ととらえずに，データと手続きを持った「技法を構成するパーツ」の
集まりとしてとらえます。
だろう。構造はパーツでないので入らないって事だよ。日本語の問題だ。つーかわざとか？
あと構造化を知らないとしたら問題は実務経験ではなく、勉強したかだ。
基本情報処理に明記されているのだから。

33:仕様書無しさん
08/05/19 21:42:45
>>32
オブジェクト指向には、おおざっぱに分類して以下のようなカテゴリーがございます

1.“メッセージングによる可能な限り動的な処理・実装・設計”（メッセージ指向とも）
2.“抽象データ型のスーパーセット”“継承によるプログラミング”（クラス指向とも）
3.“手続きによる抽象化”（これは前二者とは異質…）

あなたが、話の論点として立脚しているのはどのカテゴリーに一番近いでしょうか？
それによって回答の内容が変わってきます

34:仕様書無しさん
08/05/19 21:46:16
わかったから
いい加減枝葉末節にこだわっても意味ないことに気付け

お前以外はどう活かすかって話をしてるのに
お前だけが基礎の基礎の定義に凝り固まって話が進まない
OOについて語る技術者なら頼むからレベルを引き上げてくれ

35:仕様書無しさん
08/05/19 21:47:35
>>32
9スレも使ってなんでこんな話してるの？

.構造化の構造ってのは、機能分割によるシステム構造だよ。
言語にマッピングされる時は関数によって実現する。
I社で汎用機経験あるならさんざんHIPO書いただろ？
構造化ってのは、基本的にデータは外から渡される。
いわゆる入力-処理-出力がベースとなる基本構造だからだ。
構造化によって、処理の組み立てに一定の秩序ができたけど、
データに対してはできなかった。
なぜなら、データは外から渡されるから。
だから処理のあちこちで同じデータに対する入出力が発生した。
それでも、シングルスレッドで、基本一本道な時代は問題は少なかった。
また、優秀な技術者はOO的にデータアクセスを局所化する設計をしていた。
ここまでが構造化の話。

36:仕様書無しさん
08/05/19 21:48:10
34はおじゃば宛てな
わかると思うけど念のため

37:仕様書無しさん
08/05/19 22:07:47
>>34の続きな

OOはデータ+手続きとよくいわれるが、その本質は責任範囲明確化システムだといえる。
データに対するアクセスを局所化し、その責任者に名前を付ける。
これがすべての基本だよ。
メッセージパッシングは、単なる呼び出しではないよ。
責任範囲のことだけをやるということを意味している。
よくある例は、花屋に注文をだすのが俺の責任、相手に配達するのは花屋の責任。

だからOOの場合、無秩序にデータが外に出れば出るほど、
システムはOOの目指すところから離れ、混乱してくるといえるだろう。
データ構造とその責任範囲を明確化することがOOのポイントだ。

38:仕様書無しさん
08/05/19 22:23:01
>>21
なんで自分の考え方の枠に無理矢理でも当てはめようとするんだよ
こんな乱暴な区別で理解したつもりになったってなんの得にもならないだろ

39:仕様書無しさん
08/05/19 23:30:26
>>33
１．については語れるほど俺は詳しくないんだが、データとロジックを１単位として考える
って以外に２．的OOとの共通点がみつけられない。
てか、アラン・ケイ的OOを日本語の文章だけサラっと眺めた印象だと、何そのCOM？っ
て思っちゃったよ。きっと俺の不見識なんだろうけどｗ

40:仕様書無しさん
08/05/19 23:45:06
オブジェクト＝データ＋処理でいいじゃん。で、この概念に慣れてきたら、
次に類似するオブジェクトをクラスに分類し、共通する特徴を持つクラスは、
それらを整理（汎化）して共通（親）クラスを作りましょう。さらに設計を
押し進め、抽象クラスやインターフェースを導出しましょう。そして実装に
際しては個々の具体的な処理を実現するために、これらのクラスを継承（特化）
したクラスを作りましょう。抽象クラスと具象クラスの分離は慣れるまで大変
ですが、数をこなして経験をつめばある程度感覚的によい設計ができるように
なります。がんばりましょう...
うへ、こりゃまるで初心者向けの説明だな、オラこっぱずかしいだ。

41:仕様書無しさん
08/05/20 00:10:26
>>24
まさか、その本が構造化の本だと思っていないよな？

>>27
OOでもアルゴリズムはあるが

>>35
>.構造化の構造ってのは、機能分割によるシステム構造だよ。
>言語にマッピングされる時は関数によって実現する。
I関数の無い構造化言語もあるけど

お前(ら)相変わらず、アホだなｗ

42:仕様書無しさん
08/05/20 00:19:57
またお前か...

43:仕様書無しさん
08/05/20 00:26:01
>40
> 次に類似するオブジェクトをクラスに分類し、共通する特徴を持つクラスは、
> それらを整理（汎化）して共通（親）クラスを作りましょう。さらに設計を
> 押し進め、抽象クラスやインターフェースを導出しましょう。

細かい話になるけど、設計手順としてはちょっと良くないな
まずはインターフェースが確定した上で汎化を行うのがOOとしては正解だろうね
似たクラスかどうかはシナリオからオブジェクト図が抽出できて初めて分かることで、
実装しながらやるってのは、ちゃんと分析してないってことだし

とはいいつつも、それじゃあ時間かかるから、
>40の方法でそれっぽく作業しちゃうところが多いのも仕方ないのかもね

44:仕様書無しさん
08/05/20 00:34:21
>>40　正解
>>43　アホ
まだインターフェースも分かっていないのかｗ

45:仕様書無しさん
08/05/20 00:51:36
>>38
>なんで自分の考え方の枠に無理矢理でも当てはめようとするんだよ
これ、もしかしてスレタイの答えなのかなぁ。と、思った。

46:仕様書無しさん
08/05/20 00:56:34
>>44
お前おじゃばだろ

47:仕様書無しさん
08/05/20 01:21:52
>38
その区別しか知らないからでしょ
それ以外は理解できる頭じゃないから仕方ない

48:仕様書無しさん
08/05/20 01:29:34
>>33
3.については厳密にはそうでない、と書いてあるがAppleScriptは近いちゃ近いな。
1.の色も強いのでこう書いてるんだけど。Appleの関係は1.が強いよね、
Objective-Cなんかも、そのクラスがもってないメソッドを呼んでも文法上問題ない。
そいつが知らないメッセージを投げられた、という考え方。
3.の色が表面的に強いのはJavaScriptかな？アレも「プロトタイプ指向」とか
言われてるけど、そりゃ2.の方向から無理矢理見てるだけのような気がする。

49:仕様書無しさん
08/05/20 01:39:13
おじゃばを見てると、昔gotoが無いのが構造化だよ、という
素人でも？わかりやすい話だけをかたくなに主張して、
ロジックはフローチャートでここへ飛ぶとか書いてるくせに
制御用のフラグばっかり作ってgotoレスにして得意になってる奴がいた、
のを思い出したよ

50:仕様書無しさん
08/05/20 07:24:49
>>39
つか, 同じ枠で考えちゃだめなんだってば……… 別のものです。

OO 言語として 1.が意味のあるのは smalltalk くらいじゃないかと思う。
# ML 方面を探せば他にもあるかも知れないが, こっちはやっていないので不明

ただし, smalltalk 環境はデザパタの宝庫とも呼ばれていたりするので,
OO 設計とかの視点で見た場合は共通する部分も多いような気もする。
# MVC パターン発祥の地は smalltalk ってのは有名な話だ。

あと, OO に分類すべきかどうかは置いといて、並列計算分野ではとても重要。

51:仕様書無しさん
08/05/20 07:41:48
>>32
>「テクニック」に引っかからないで、contextThe整関数はモノリスと「テクニックを構成する部品」のグルー
>プとしてデータと手順で捕らえられます。 .Because、構造が部品でない、それはそうです。入るもの。それ
>は日本の問題です。それ。ーわざと、山のupThe問題は構造化を知らなかったかどうかということです、それ
>が業務上の経験でなく、研究したか否かに関係なく。それが不可欠の情報処理で明確に説明されるので。

まで読んだ

52:おじゃばさま ◆GxjxF3yEw6
08/05/20 09:36:42
>>33
2番

>>34
枝葉じゃなで幹だろう。「オブジェクト」の解釈が違うのだから。

>>35
機能で分けて、データに対する紐付けがない。基本だよな。

>>37
データ＋処理でいいって事だろう。基本だよな。
オブジェクトがデータ＋処理だと言う事については、アランのも同じだろう。

>>40
それでいいと思うが、オブジェクトはインタフェースだと言っている人の理由をきかねば。

53:仕様書無しさん
08/05/20 09:43:16
>>52
>オブジェクトはインタフェースだと言っている人の理由をきかねば。
そんな奴いたっけ？

54:仕様書無しさん
08/05/20 09:56:29
デザインパターン読んだけど、いや読もうとしたけど
数ページでもうだめ。助けてくれ

55:仕様書無しさん
08/05/20 09:59:03
>>52
オブジェクトはインタフェースだと言っている人ではないんだが
仮にTV受像機を作るとする

要素技術としては, 受信機, 表示装置, 音声再生装置が必要

受信機には, 映像信号と音声信号が一緒になって入ってくるから
表示装置/音声再生装置への振り分け機能が必要となる

この時、機能としてみれば振り分け機能なんだが、信号(メッセージ)
としてみた場合、映像出力->表示装置/音声出力->音声再生装置の
二つのインタフェースが必要となる。

で、このインタフェースがちゃんと定義できてなければ、TV受像機は
動作しない。

以下同様に、
映像信号を表示する場合、CRT を使うか LCD を使うかによって………

なので、
機能分割も重要だが機能間のインタフェースもしっかり定義する必要がある。
と、言ってるだけなんじゃねぇの？

逆に言えば、インタフェースと機能がきちんと定義されてれば中身は
ブラックボックスでいいと…

でも、これって OO に限らずどんなシステムにも言えることなんだよな

56:おじゃばさま ◆GxjxF3yEw6
08/05/20 10:07:41
>43
つまり、料金プランが変更されるのを見越して、各社の料金プランを実装って事か？

>45
なるほど！

>48
3について知っているのか？説明してくれ。

>49
オブジェクトの定義が違うのに、オブジェクト指向について話せないだろう？

>50
1は結局、EJBの方に流れて失敗してる。もう分散の分野ぐらいにしか使い道がないのではないか？
つーかいまだに1でオブジェクト指向を説明する人がいる自体、普及の遅さを感じる。

57:仕様書無しさん
08/05/20 10:19:00
こいつは理解すると何も言えなくなるから理解したくないんだろう

58:仕様書無しさん
08/05/20 10:24:38
>>56
>分散の分野ぐらいにしか使い道がないのではないか？
ちょっとまて、お前OOA/Dはシミュレーションだのゲームにしか役に立たないとか
言ってたよな。
じゃ結局お前がOO(?)を普及させたい、あるいはした方がいい、したと感じるのはどんなアプリなんだ？
いままでの口ぶりだと業務経験(笑)からかDOAですむような垂直業務アプリしか頭にないみたいだけど。
そんな分野ならもうPHPだのRoRで作る時代になりつつあるからことさら騒がんでも。
コテハンが示すとおりJavaで作ってるのになんでみんなOOわからないのよ？ってのが
お前の立ち位置じゃないのか？

59:仕様書無しさん
08/05/20 10:34:15
>>56
分析におけるオブジェクトはデータ＋操作でも、まぁ良いと思うが、
分析におけるオブジェクトと実装におけるクラスはイコールではない。

分析ではどのようなオブジェクトがどう存在するのか、全体を把握しなければならないが、
実装する段階では、個々のクラスが割り当てられた責務を果たせれば良い。
分析で1つのオブジェクトでも、実装では複数のクラスで実現されることもあるし、
分析したオブジェクトが持っている属性が、実装するクラスでも属性として持っている必要はない。

そのギャップを埋めるのが設計。

で、何の話だ？

60:仕様書無しさん
08/05/20 10:41:38
>>59
分析と設計の区別がついてないおじゃばにその説明をしても無理だろうな･･･

61:仕様書無しさん
08/05/20 12:44:15
すみません。くだんのリンク先の人間ですが、追記にも書いたとおり３のクックのは忘れてください。
これはリスコフの提唱した抽象データ型（データと手続きのセット。ユーザー定義型とも）について、
手続きを型に従属させる場合をあらためてＯＯと定義し、そうでない場合を
従来通り、抽象データ型と区別してはどうかという提案であるようです。したがって、大枠では
「データ型を意識する」という観点で、２、つまり、ストラウストラップやメイヤーたちのＯＯに含めて
よいように思います。よって、最近認知されてきたプロトタイプベースのＯＯを加えてあらためて世の中には、

１．メッセージングを意識するＯＯ
２．データ型を意識するＯＯ
３．プロトタイプベースのＯＯ

の三系統がある、ということになります。

62:仕様書無しさん
08/05/20 12:55:30
>>56
>標準？　何が標準だ
>俺が業界標準なのだ

まで読んだ

63:仕様書無しさん
08/05/20 13:11:45
>>61
あ、どうもこんな変なスレにwていねいにありがとうございます。
それでは、どちらかといえばここを参照したほうがいい、
ということでよろしいでしょうか？
>URLﾘﾝｸ(d.hatena.ne.jp)

64:仕様書無しさん
08/05/20 13:14:46
>>63
そうですね。番号が１と２で入れ替わっちゃっていますけれど（汗）。

65:仕様書無しさん
08/05/20 17:50:12
>48涙目wざまぁ

66:おじゃばさま ◆GxjxF3yEw6
08/05/20 19:26:10
>>55
>でも、これって OO に限らずどんなシステムにも言えることなんだよな
俺もそう思う。

>>58
シミュレーション等以外だと、前から言っているが、
新規で多くの修正が入る可能性のあり、短期で修正する必要のあるシステム。

>>59
オブジェクトがデータ＋処理かと言う話だよ。
次の話は、修正を見越して実装する必要があるかの話になるかな。

>>61
本人は気が付いているのか分からないが紛わしい。
実際にはOOの基本原理があって、61の記載は実現方法や実装の種類でしかないが、
まるで原理が違うOOが3種類あるように見える。
OOの基本原理を説明しなければ、単に混乱するだけだと思う。
ちなみに現在のEJBの状況を見る限りでは、61の言う「メッセージングを意識するOO」はOOの説明から
外した方がいいと思う。

67:仕様書無しさん
08/05/20 19:58:41
だから基本原理は皆わかってる
その上でそれをどう使うかって話をしてんだろ
お前だけが基礎の基礎で止まってると何回言えばいいんだボケ

68:仕様書無しさん
08/05/20 20:01:35
>>66
そりゃ、お前が彼の他のページが理解できなくて、
自分がEJBくらいしかメッセージの話を知らないということだな。よくわかるよ。

69:仕様書無しさん
08/05/20 20:07:48
>>67
しかたないよ、I社の業務経験(笑)しかよりどころがなくて、自分で本も読めなくて
ここへ来て教えて君しかできないんだから。
ん？そう考えると、なにもおじゃばはOOをなんだかんだ言う理由なんかないじゃん。
別にいまさら仕事でやってるわけでもないだろうし。こんなんでやってたら怖いけどｗ

70:仕様書無しさん
08/05/20 20:13:21
>>66
>OOの基本原理、とおじゃばが信じてるのは型こだわりだぜ、ってーの。
だいたいそのお前が信じた基本原理からしてどこからきたの、が
せいぜいどこの入門書にも書いてあるだろ、っつ根拠しかねーじゃん、お前ｗ

71:仕様書無しさん
08/05/20 20:16:49
>>61に対するおじゃばのレスは、
まるで自分は解っているかの様な書き方なのが気になる。

72:仕様書無しさん
08/05/20 20:24:26
>>66
>納品したからといって一切油断はできないよね
>今も５年前に納品したシステムのバグを潰してる
>それにともなう追加料金はゼロ
>金にならないバグフィックスの仕事を４つかかえてる
>ITって人を騙すのが仕事、騙してナンボだろ
>客も、元請も、部下も、上司も、社長さえも騙す
>バグを隠蔽し、ログは辻褄あわせで改ざんもやる

まで読んだ

73:仕様書無しさん
08/05/20 20:30:37
>>72
まで読んだ、の人、いろいろ工夫してて面白い。

74:仕様書無しさん
08/05/20 20:34:19
>>71
いつものことだ。おじゃばはまったくわからないことはこうして知ってるふりして偉そうにするが、
ちょっとでも聞いたことがあって理解できないのは安心してオウム返しするから
すぐわかるｗ

75:仕様書無しさん
08/05/20 21:01:45
>>66
> 俺もそう思う。
本とにそう思ってる？
インタフェースとしてバッファリング戦略取るかストリーム戦略取るかで
サブシステムの作りは大幅に変わるんだよ…
システム全体のスループットとかも変わってくるんだよ…

76:仕様書無しさん
08/05/20 21:06:04
なぜここでEJBの話が出てくるのかよく分からない。
もしかしてMDBのことをいいたいわけ？
だとしてそれがOOとどう絡むのよ。

77:仕様書無しさん
08/05/20 21:10:22
>>76
Java(EJB)でコーディングしてるから俺OO使えるんだぜ、っていう類だろ

78:仕様書無しさん
08/05/20 21:18:15
>>76、77
おじゃばは言葉には出せないけど、業務経験(笑)としてEJBとJMSをやったんで
これが出てきたという推測はできるね。JMSを知らない公算の方が大きいけど。

79:仕様書無しさん
08/05/20 23:23:12
おじゃばはまずポリフォー..もといポリモーフィズムにおけるインターフェースの
果たす役割を勉強した方がいいな。まぁそっからだな。質問するのはそのあとだな。

80:仕様書無しさん
08/05/21 00:14:36
>>72
よう、オレ。
基本は客先ＳＥをだまくらかすか共犯になるかだよな？
もう少しで客先に転職できるぞ♪

81:仕様書無しさん
08/05/21 00:17:47
>>61
>１．メッセージングを意識するＯＯ
>２．データ型を意識するＯＯ
>３．プロトタイプベースのＯＯ
オブジェクト指向は、突き詰めてしまうと理解しがたいもので、
時代とともに解釈の主流が変化してきてる。その、産物がこの３つの
解釈。プロトタイプベース・オブジェクト指向も実はずいぶん古い。

これらの解釈は、初心者がオブジェクト指向を理解するのに役に立つし、
プログラミング言語に密接に関係する。

ただ、真のオブジェクト指向というものがあるとするならば、これらは、
それぞれの立場（利益）に基づいたビュー（見方）でしかない。

個人的には、学者の論文のタイトルのために現れた用語やプログラミング
言語の宣伝用の用語に思えてならない。

82:仕様書無しさん
08/05/21 00:42:13
わびさびを解釈するオブジェクトが現れた時こそオブジェクト指向が完成の時を迎える。

83:仕様書無しさん
08/05/21 01:06:45
>>81
それじゃ結局何も言ってないのと同じだろーが。

84:おじゃばさま ◆GxjxF3yEw6
08/05/21 09:37:54
>>67
オブジェクトはデータ＋処理ではないとか、変更を見越して設計する必要があるとか、
OOの利点は設計時のインタフェースをそのまま実装出来ることとか、OOの利点はポリモーフィズムだとか
言っている人がいるのだが。これで基本が分かっていると言えるのか？

>>68
68は理解出来たのか？訂正する前の3番も。

>>69
仕事でやってるよ。

>>70
入門書に書いてあるなら根拠になるのではないか？
第一、オブジェクトが概念のインタフェースだとか、OOの利点はポリモーフィズムだとか言うのの方が
見たことないぞ。根拠があるのか？

>>75
それは違うな。
バッファリングでもストリーミングでも、入出力系のクラスを変更するだけで対応出来るようになるのが
OOだ。システムの作り大幅に変わるようなら設計ミスだ。

85:仕様書無しさん
08/05/21 09:53:22
>>84
>仕事と生活のストレスで胃潰瘍になったが
>バファリンのやさしさで何とか生きてます
>俺の中ではバファリン＞風俗嬢です
>ちなみに俺のSEXインターフェイスはすごく…　ちいさいです

まで読んだ

86:仕様書無しさん
08/05/21 10:02:44
>>84
どんな入門書か本の名前も出せないボケジジイが何を言っても根拠にならんな。
根拠というのは検証できて初めて根拠になるんだよ。
しかし･･･こんなにまともに本も読まない年寄りがいるんじゃ、I社とやらもたかが知れてるな。
あ、クビにでもなったのかｗ

87:仕様書無しさん
08/05/21 10:03:51
>>84
で、ポリモーフィズムってなんのことだ？

88:仕様書無しさん
08/05/21 10:11:55
>>84
>入出力系のクラスを変更するだけで対応出来るようになる
なぜOOだとそうなるんだ？だってお前設計はDOAで十分、
JavaでOOPすればいいってたじゃねーか。いまさら設計もOOなのか？

89:仕様書無しさん
08/05/21 11:03:09
>>84
>OOの利点はポリモーフィズムだとか言うのの方が見たことないぞ。

いやこれは入門書にも普通に書いてあるだろ。ポリモーフィズムと書いてあるかどうかは別として。

90:おじゃばさま ◆GxjxF3yEw6
08/05/21 12:50:52
>>89
OOの手段だという記述はあっても、目的だという記述は見たことがないが。

91:仕様書無しさん
08/05/21 13:12:25
>>90
>俺は言葉をしているつもりはない
>ただ、予想の斜め上を行くようなレスを心がけている
>そうするといつかとんでもない高みにいる自分に気づく
>ここまでくると誰も昇ってこようとはしない
>だが、上だけでなく、横にも伸びているわけであって
>それはつまり、とんでもなく傾いている
>最悪なのが、俺が理論武装した土台が最高に脆いという
>欠陥を孕んでいて…あ、あ、あ！やめろ蹴るな倒れるうあうわああああ

まで読んだ

92:仕様書無しさん
08/05/21 13:14:19
>>90
目的であるか手段であるか、と利点であるかどうかにどういう関連性があるんだ？

OO の手段としてポリモーフィズムを用いることでプログラミング上の利点が発生するんだろ

93:おじゃばさま ◆GxjxF3yEw6
08/05/21 13:23:17
>>92
目的＝利点だろう？

94:仕様書無しさん
08/05/21 13:56:11
>>93
目的が利点であったとして、手段が利点とならないわけではないだろう？

95:仕様書無しさん
08/05/21 14:31:30
ようするに、おじゃばはポリモーフィズムがなんで導入されたか理解できないから
説明して欲しいとお願いしてるわけだよ。入門書にはたいてい載ってるのに
読んでもわからないと。いいかげん察してあげないと。やさしくしようぜみんな。

96:仕様書無しさん
08/05/21 15:04:01
>>93
>ポリモーフィズム？
>そんなものは認めてないぞ
>黙って継承だけしてればいいものを
>余計なことをするから「おにいちゃんぱんつみないで！」
>とか言い出すんだ
>本当はパンツの履き替えもしたいのに
>もっともっとぐへへｈ

まで読んだ

97:おじゃばさま ◆GxjxF3yEw6
08/05/21 17:47:35
>>94
手段は利点にはならない。

98:仕様書無しさん
08/05/21 17:52:11
>>97
なぜ？

99:おじゃばさま ◆GxjxF3yEw6
08/05/21 18:20:51
>>98
手段は目的にならないからだ。

100:仕様書無しさん
08/05/21 18:48:04
h

101:仕様書無しさん
08/05/21 19:58:38
変更を見越して設計する必要が無くなるのなら、
行き当たりばったりでもいい、ちうことだよな。
すげーな、OO(AだかDだかPだか知らんけど)w

102:仕様書無しさん
08/05/21 20:15:52
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点

103:仕様書無しさん
08/05/21 20:18:04
>>84
インタフェースがOOの基本っていう話読みたかったらGoF買えよ
理解できなかった場合はUMLモデリングのエッセンスにも書いてあるからそっちを読め

104:仕様書無しさん
08/05/21 20:34:54
>>99
>手段は目的にならないからだ。
要するに『「目的＝利点」かつ「手段≠目的」』だから「利点≠手段」だといいたいのか？
なんだその小学生レベルの論理回路は。（正直ここまでひどいとは思わなんだ）

いいか、目的を達成するために手段があるということはわかるよな。
で、その手段を選択するからには、「手段」に「目的を果たすために」利する点が
あるからだよな。
そもそもおじゃばの主張する「目的＝利点」に対する根拠は何よ。

・・・まあいいや。要するに >>95-96 だろうから。

105:仕様書無しさん
08/05/21 20:42:48
ん、きっと何も言い返すことが出来ないからくやしくて言ってみただけ。
小学校低学年くらいのこどもがいる人はわかると思うよ。

106:仕様書無しさん
08/05/21 21:29:55
>>84
> バッファリングでもストリーミングでも、入出力系のクラスを変更するだけで対応出来るようになるのが
> OOだ。システムの作り大幅に変わるようなら設計ミスだ。

素朴な疑問なんだけど、あなたの頭の中には、使える資源が無限大にあるわけ？

ロードバランサー前提の設計と、無しの設計だと
オブジェクトの分割自体変わるよ

「数トランザクション/秒」の処理なのか「数キロトランザクション/秒」
かによって、システムに要求される資源量も変わるよ

つか、組み込み系なんかだと MPEG 展開とか資源量によっては
バッファリング戦略取るとシステム自体が破綻するんだけど

107:仕様書無しさん
08/05/21 21:33:06
不思議なんだが、おじゃばはなんでいつまでも基本レベルに留まってるの？
というかポリモーフィズムを否定するって、オブジェクトがわかってないってことじゃん。

108:仕様書無しさん
08/05/21 22:18:29
オブジェクトというかインターフェースな

109:仕様書無しさん
08/05/21 22:41:29
結局OOPも出来ない。

110:仕様書無しさん
08/05/21 22:46:12
インタフェースと組み合わせることで、応用範囲が広がるのは確かだけど、
元はオブジェクトだよ。

オブジェクトという単位にデータと手続きをカプセル化することによって、
それぞれのオブジェクトが独立して同じ名前の手続きを持てることになった。
この潜在的なオブジェクトの性質がポリモーフィズムを実現している。
つまり、クラスAのオブジェクトとクラスBのオブジェクトでそれぞれ
同じメソッドmを持てるということだね。

動的束縛を行う言語であれば、これはメッセージmに答えられる能力を
各オブジェクトが有しているということになる。
SmalltalkやObjective-Cなどがこれにあたり、ここには継承も
インタフェースも関係がない。

次に、このポリモーフィズムの性質を静的な言語で実現する時、
まず利用されるのが継承関係を用いた方法だ。
例えば、図形クラスを継承した楕円クラスと矩形クラスで共通した
親クラスのメソッドを持ちながら振る舞いを変えるという方法だね。
後から三角形クラスも追加できるなどOOならではの拡張性が生み出される。
お馴染みのtoString()などもこの例だね。
抽象クラスによる利用もここに含まれるだろう。

３つ目がインタフェースによる利用。インタフェースを利用することで、
実装継承の枠を越えて、ポリモーフィズムを活用できる。
それでも動的な言語には追いつかないが、設計の自由度は高まるといえる。

4番目がリフレクションを活用した動的な利用。これはより最初の例に
近くなっている。

111:仕様書無しさん
08/05/21 23:20:14
カプセル化、継承、ポリモーフィズムはOOの基本中の基本。いろはのい。
その是非云々を無意味に問いかけるのはいいかげんやめれ。
それとも、おじゃばはこれらの基本を根本から覆すような理論を会得した
とでもいうのか？　だったらその理論を表現する言語でも開発してみせろよ。
その方が早いべ。あ？

112:仕様書無しさん
08/05/21 23:32:54
おじゃばはそれをオブジェクト指向と名付けちゃう。
オブジェクト指向が普及さないワケだ。

113:仕様書無しさん
08/05/21 23:59:07
おじゃばの頭はカプセル化どまり。つまり園児レベルだなこれ。

114:仕様書無しさん
08/05/22 04:59:56
>>99
>おじゃばはまだこれでも教えてるつもりなんだぜ？
>迷惑な話だよな
>わからない奴が人に教えようってんだから、最悪の先生だ

まで読んだ

115:仕様書無しさん
08/05/22 08:06:14
いや、おじゃばはきっとクラスとインスタンスの区別もよくついてない。
2,3スレ目かでクラス＝オブジェクトだ、とかやってたし。あれから理解も進んでない様子。
ということは、カプセル化もあやしいぞ。
構造体に関数くっつけただけでOO完成とか本気で思ってそうだし。

116:おじゃばさま ◆GxjxF3yEw6
08/05/22 09:34:54
>>101
OOの基本原理に従って設計すれば、オブジェクト単位での変更が容易になるため、将来を見越した仕様など
入れる必要はないと言う事だ。

>>103
インタフェースが基本でないと言っている訳ではなく、「オブジェクト＝インタフェースのみ」ではない
と言っているだけだ。

>>104
だから、ポリモーフィズムの「目的を果たすために利する点」を言えよ。
「目的＝利点」の根拠？小学生の三段論法より基本的だと思うが、答えないとダメか？

>>106
組み込み系はOOに向かないので除外してくれ。
比較的資源に余裕のあるミドルやアプリの分野なら、バッファを制御する手段はいくらでもあるだろう。
俺が言うまでもなく、106は知っているのではないか？

>>107
ポリモーフィズムを否定している訳ではない。
「カプセル化、継承、ポリモーフィズムは、OOの手段であって目的ではない」と言う基本的な事を
言っている。目的を忘れて手段に溺れるのを防ぐために。

117:仕様書無しさん
08/05/22 10:16:06
>>116
>オブジェクト＝インタフェースのみ
だから、誰がそんなことを言っていたのかとｗ

カプセル化、継承、ポリモーフィズムは、OOの手段であって目的ではない
だから、誰がそんなことを言っていたのかとｗ

ホントに日本語が通じてない。つか用語を理解しないで表面をなぞるからそうなのか？
お前、「OOの基本原理に従って設計すれば、オブジェクト単位での変更が容易になる」
ってほんとに思ってるのか？そう思う根拠は何だ？
入門書に書いてあるから
そうですか。はいはい。

118:仕様書無しさん
08/05/22 10:32:29
>URLﾘﾝｸ(jibun.atmarkit.co.jp)
むしろ、仕様変更が発生しやすい組み込みにこそOOが有効という考え方もある。
世の中いろいろな仕事があるのだから、自分だけの業務経験(笑)で決めつけない
ほうがいいと思うよ。I社とやらの名誉のためにも。

119:仕様書無しさん
08/05/22 10:39:26
てか、おじゃばってこの調子だとなぜOOだと資源が多く必要なのかも
説明できないような気がする。おじゃば、なんて名前のくせに負荷分散だとかの
スキルもまるで無さそうだし。

120:仕様書無しさん
08/05/22 10:44:28
わかったぞ、自作自演てやつだ
おじゃばっていうコテつかってわざと間違えて
名無しで説明してくれてるんだろ？

121:仕様書無しさん
08/05/22 11:14:22
話のコシを折るようですまんが、はたからみてると
おじゃばさまってののほうがオブジェクト指向についてわかってるように感じる
おじゃばさまが言ってるのってカプセル化も継承もインターフェイス志向も重要な要素だけど
もっと重要なのは、オブジェクトという単位で考えることで、疎結合になったり再利用性が高まったり
保守性が高まったり、可読性が高まったり、変更に耐えやすいようになっていたりって
いわゆるオブジェクト指向の利点とすることを第一に考えるべきだ
だからカプセル化とかポリもーフィズムありきで考えるのではなく、それは一手段として使ったら？
って言ってるんじゃねーのかな
だとすればおじゃばさまが正しいと思うのだけど。
それとも俺の好意的な読解ミスなんだろうか

122:仕様書無しさん
08/05/22 11:25:59
おじゃばは構成要素をOOだっていって延々語ってんの

123:仕様書無しさん
08/05/22 11:27:15
いや、レベルが低いだけだと思うよ。

124:仕様書無しさん
08/05/22 12:08:11
>>121
> だからカプセル化とかポリもーフィズムありきで考えるのではなく
だれも「ありき」なんていってないだろ。

> だとすればおじゃばさまが正しい
だとしないのでおじゃばが正しいとはいえない。OK?

それにしてもこんなひどいｊ(ry

125:仕様書無しさん
08/05/22 12:51:57
>>121
>I am おじゃば！
>I am おじゃば！！
>I am おじゃば！！！
>I am おじゃば！！！！
>I am おじゃば！！！！！
>I am おじゃば！！！！！！
>I am おじゃば！！！！！！！
>I am おじゃば！！！！！！！！

　まで読んだ！！！！！！！！！！

126:仕様書無しさん
08/05/22 13:02:41
>>121
>俺が悪かった
>俺がゆってたのはオブジェクトじゃなくて
>構造体と関数をくっつけただけの
>クラス指向だったんだ
>俺ははだかのおうさまだったのか…
>なんで誰も教えてくれなかったんだ

も読んだ

127:おじゃばさま ◆GxjxF3yEw6
08/05/22 17:40:17
>>117
>お前、「OOの基本原理に従って設計すれば、オブジェクト単位での変更が容易になる」
>ってほんとに思ってるのか？そう思う根拠は何だ？
つまり実感がないわけだ。俺は実務で経験していて実感がある。
例えば俺が作ったプログラムで、データ件数が500倍に増えて検索が遅くなった。
検索メソッドを上書きしただけで、比較的楽に修正できた。
またDBで扱っていたデータが、リモートファイルに変更になった。レコード取得のメソッドを上書きしただけ。
他にも電文が大幅に変更になった時も、受信後のファイル出力メソッドを上書きして、処理を少し追加した
だけで修正できた。ちなみに使用しているDBの製品が変わった時も、修正はごく一部だった。
構造化で作っていたら、場合によっては作り直しに近い内容だと言うのは、117は知っているはずだ。
おまけに、修正後に元に戻してと言われても楽勝。以前の機能は全く損なわれていない。

128:仕様書無しさん
08/05/22 18:00:25
>>127
>実装の継承ってスゲーんだぜ？
>なんてったってコーディング量が少なくていいもん。
>これぞOOって感じだよ。いやあOOってすばらしいなあ。
>分析？　設計？　インタフェース？　ポリフォー（笑）フィズム？
>お前らはいつまでたっても本質に至れないな。

まで読んだ。

次ページ