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

1 ：仕様書無しさん：2008/05/17(土) 08:50:17

2 ：仕様書無しさん：2008/05/17(土) 14:48:51

低能晒し続けて１０スレ

3 ：仕様書無しさん：2008/05/18(日) 09:39:47

おつ

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

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

4 ：仕様書無しさん：2008/05/18(日) 10:14:34

try-catchの中に分岐判断ロジックを書かなくてよい、ってことじゃ？

5 ：仕様書無しさん：2008/05/18(日) 11:15:21

スレ違いも甚だしいのでム板でどうぞ

6 ：仕様書無しさん：2008/05/18(日) 16:00:53

せんせい！質問！！！
「おじゃば」土日には出現しないんですか？

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

7 ：仕様書無しさん：2008/05/18(日) 21:12:55

try-catch の利点がわからんとか言うやつはまず例外とは何ぞやというところから考えてみろ。

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

8 ：仕様書無しさん：2008/05/18(日) 22:12:13

>>7
wiki からの抜き出しだけど、以下の様な内容だと考えている。

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

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

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

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

9 ：仕様書無しさん：2008/05/18(日) 23:27:57

>>8
catchでディスパッチできるっしょ？できない時はtry{}catchを複数書くしかないね。

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

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

10 ：仕様書無しさん：2008/05/19(月) 00:01:46

いい加減やめないか

11 ：仕様書無しさん：2008/05/19(月) 02:00:29

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

12 ：仕様書無しさん：2008/05/19(月) 02:54:56

>11
自己紹介乙

13 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/19(月) 11:05:33

なんか前スレ見えなくなってるのだが。これはどうなった？間違いなのか？

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

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

14 ：仕様書無しさん：2008/05/19(月) 11:41:42

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

15 ：仕様書無しさん：2008/05/19(月) 11:48:50

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

16 ：仕様書無しさん：2008/05/19(月) 12:36:42

>>13
優しい俺様が前スレからピックアップしてコピペしてやる。
読めよ、バカ野郎。

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

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 ：仕様書無しさん：2008/05/19(月) 13:59:56

せんせい！しつもん！！！
「おじゃば」は、書き散らかすだけ書き散らしていっさいレスを読まない人ですか？

18 ：仕様書無しさん：2008/05/19(月) 19:33:26

おじゃばって１スレ目からいたの？

19 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/19(月) 20:08:00

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

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

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

20 ：仕様書無しさん：2008/05/19(月) 20:15:44

>>19
構造化、を構造と読めないのか？とことんバカだな。
オブジェクト指向とオブジェクトをまったく別の単語にするのか？
お前、日本人か？ｗ

21 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/19(月) 20:16:18

結局確認したいのは、
オブジェクト指向：オブジェクト＝クラス＝データ＋処理
構造化：モジュール＝関数＝処理

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

22 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/19(月) 20:20:28

>>20
だからその「構造」って何だよ？
関数？構造体？ライブラリ？構造化なのでクラスはないぞ？

23 ：仕様書無しさん：2008/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 ：仕様書無しさん：2008/05/19(月) 20:29:01

>>22
お前、結局構造化もなんのことだかわかってねーじゃん。
>ttp://www.fukkan.com/fk/VoteDetail?no=8797
そんなんでよくそれは構造化だのOOだの言えたもんだな。

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

25 ：仕様書無しさん：2008/05/19(月) 20:40:11

>>19
966だが俺は基本だなんて言ってないぞ？
抽象論としては間違ってるってわけでもないと突き放しただけだ。

26 ：仕様書無しさん：2008/05/19(月) 20:41:03

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

27 ：仕様書無しさん：2008/05/19(月) 20:42:19

構造化プログラミング＝アルゴリズムとほぼ等しい

28 ：仕様書無しさん：2008/05/19(月) 20:52:59

>>21
インスタンスはどうなるんだ？

29 ：仕様書無しさん：2008/05/19(月) 20:56:21

クラスはオブジェクトじゃないよなぁ。

30 ：仕様書無しさん：2008/05/19(月) 20:58:13

>>22
>こうぞうか？かんすう？こーぞうたい？らいぶらり？
>まだしょうがくせいなのでわかりません＞＜

まで読んだ

31 ：仕様書無しさん：2008/05/19(月) 20:59:09

http://www.nicovideo.jp/watch/sm1577491

32 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/19(月) 21:30:48

>>23
どうでもいいから21に答えてくれ。

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

33 ：仕様書無しさん：2008/05/19(月) 21:42:45

>>32
オブジェクト指向には、おおざっぱに分類して以下のようなカテゴリーがございます

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

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

34 ：仕様書無しさん：2008/05/19(月) 21:46:16

わかったから
いい加減枝葉末節にこだわっても意味ないことに気付け

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

35 ：仕様書無しさん：2008/05/19(月) 21:47:35

>>32
9スレも使ってなんでこんな話してるの？

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

36 ：仕様書無しさん：2008/05/19(月) 21:48:10

34はおじゃば宛てな
わかると思うけど念のため

37 ：仕様書無しさん：2008/05/19(月) 22:07:47

>>34の続きな

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

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

38 ：仕様書無しさん：2008/05/19(月) 22:23:01

>>21
なんで自分の考え方の枠に無理矢理でも当てはめようとするんだよ
こんな乱暴な区別で理解したつもりになったってなんの得にもならないだろ

39 ：仕様書無しさん：2008/05/19(月) 23:30:26

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

40 ：仕様書無しさん：2008/05/19(月) 23:45:06

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

41 ：仕様書無しさん：2008/05/20(火) 00:10:26

>>24
まさか、その本が構造化の本だと思っていないよな？

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

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

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

42 ：仕様書無しさん：2008/05/20(火) 00:19:57

またお前か...

43 ：仕様書無しさん：2008/05/20(火) 00:26:01

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

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

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

44 ：仕様書無しさん：2008/05/20(火) 00:34:21

>>40　正解
>>43　アホ
まだインターフェースも分かっていないのかｗ

45 ：仕様書無しさん：2008/05/20(火) 00:51:36

>>38
>なんで自分の考え方の枠に無理矢理でも当てはめようとするんだよ
これ、もしかしてスレタイの答えなのかなぁ。と、思った。

46 ：仕様書無しさん：2008/05/20(火) 00:56:34

>>44
お前おじゃばだろ

47 ：仕様書無しさん：2008/05/20(火) 01:21:52

>38
その区別しか知らないからでしょ
それ以外は理解できる頭じゃないから仕方ない

48 ：仕様書無しさん：2008/05/20(火) 01:29:34

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

49 ：仕様書無しさん：2008/05/20(火) 01:39:13

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

50 ：仕様書無しさん：2008/05/20(火) 07:24:49

>>39
つか, 同じ枠で考えちゃだめなんだってば……… 別のものです。

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

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

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

51 ：仕様書無しさん：2008/05/20(火) 07:41:48

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

まで読んだ

52 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/20(火) 09:36:42

>>33
2番

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

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

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

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

53 ：仕様書無しさん：2008/05/20(火) 09:43:16

>>52
>オブジェクトはインタフェースだと言っている人の理由をきかねば。
そんな奴いたっけ？

54 ：仕様書無しさん：2008/05/20(火) 09:56:29

デザインパターン読んだけど、いや読もうとしたけど
数ページでもうだめ。助けてくれ

55 ：仕様書無しさん：2008/05/20(火) 09:59:03

>>52
オブジェクトはインタフェースだと言っている人ではないんだが
仮にTV受像機を作るとする

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

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

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

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

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

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

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

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

56 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/20(火) 10:07:41

>43
つまり、料金プランが変更されるのを見越して、各社の料金プランを実装って事か？

>45
なるほど！

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

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

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

57 ：仕様書無しさん：2008/05/20(火) 10:19:00

こいつは理解すると何も言えなくなるから理解したくないんだろう

58 ：仕様書無しさん：2008/05/20(火) 10:24:38

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

59 ：仕様書無しさん：2008/05/20(火) 10:34:15

>>56
分析におけるオブジェクトはデータ＋操作でも、まぁ良いと思うが、
分析におけるオブジェクトと実装におけるクラスはイコールではない。

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

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

で、何の話だ？

60 ：仕様書無しさん：2008/05/20(火) 10:41:38

>>59
分析と設計の区別がついてないおじゃばにその説明をしても無理だろうな･･･

61 ：仕様書無しさん：2008/05/20(火) 12:44:15

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

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

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

62 ：仕様書無しさん：2008/05/20(火) 12:55:30

>>56
>標準？　何が標準だ
>俺が業界標準なのだ

まで読んだ

63 ：仕様書無しさん：2008/05/20(火) 13:11:45

>>61
あ、どうもこんな変なスレにwていねいにありがとうございます。
それでは、どちらかといえばここを参照したほうがいい、
ということでよろしいでしょうか？
>http://d.hatena.ne.jp/sumim/20080415

64 ：仕様書無しさん：2008/05/20(火) 13:14:46

>>63
そうですね。番号が１と２で入れ替わっちゃっていますけれど（汗）。

65 ：仕様書無しさん：2008/05/20(火) 17:50:12

>48涙目wざまぁ

66 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/20(火) 19:26:10

>>55
>でも、これって OO に限らずどんなシステムにも言えることなんだよな
俺もそう思う。

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

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

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

67 ：仕様書無しさん：2008/05/20(火) 19:58:41

だから基本原理は皆わかってる
その上でそれをどう使うかって話をしてんだろ
お前だけが基礎の基礎で止まってると何回言えばいいんだボケ

68 ：仕様書無しさん：2008/05/20(火) 20:01:35

>>66
そりゃ、お前が彼の他のページが理解できなくて、
自分がEJBくらいしかメッセージの話を知らないということだな。よくわかるよ。

69 ：仕様書無しさん：2008/05/20(火) 20:07:48

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

70 ：仕様書無しさん：2008/05/20(火) 20:13:21

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

71 ：仕様書無しさん：2008/05/20(火) 20:16:49

>>61に対するおじゃばのレスは、
まるで自分は解っているかの様な書き方なのが気になる。

72 ：仕様書無しさん：2008/05/20(火) 20:24:26

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

まで読んだ

73 ：仕様書無しさん：2008/05/20(火) 20:30:37

>>72
まで読んだ、の人、いろいろ工夫してて面白い。

74 ：仕様書無しさん：2008/05/20(火) 20:34:19

>>71
いつものことだ。おじゃばはまったくわからないことはこうして知ってるふりして偉そうにするが、
ちょっとでも聞いたことがあって理解できないのは安心してオウム返しするから
すぐわかるｗ

75 ：仕様書無しさん：2008/05/20(火) 21:01:45

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

76 ：仕様書無しさん：2008/05/20(火) 21:06:04

なぜここでEJBの話が出てくるのかよく分からない。
もしかしてMDBのことをいいたいわけ？
だとしてそれがOOとどう絡むのよ。

77 ：仕様書無しさん：2008/05/20(火) 21:10:22

>>76
Java(EJB)でコーディングしてるから俺OO使えるんだぜ、っていう類だろ

78 ：仕様書無しさん：2008/05/20(火) 21:18:15

>>76、77
おじゃばは言葉には出せないけど、業務経験(笑)としてEJBとJMSをやったんで
これが出てきたという推測はできるね。JMSを知らない公算の方が大きいけど。

79 ：仕様書無しさん：2008/05/20(火) 23:23:12

おじゃばはまずポリフォー..もといポリモーフィズムにおけるインターフェースの
果たす役割を勉強した方がいいな。まぁそっからだな。質問するのはそのあとだな。

80 ：仕様書無しさん：2008/05/21(水) 00:14:36

>>72
よう、オレ。
基本は客先ＳＥをだまくらかすか共犯になるかだよな？
もう少しで客先に転職できるぞ♪

81 ：仕様書無しさん：2008/05/21(水) 00:17:47

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

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

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

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

82 ：仕様書無しさん：2008/05/21(水) 00:42:13

わびさびを解釈するオブジェクトが現れた時こそオブジェクト指向が完成の時を迎える。

83 ：仕様書無しさん：2008/05/21(水) 01:06:45

>>81
それじゃ結局何も言ってないのと同じだろーが。

84 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/21(水) 09:37:54

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

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

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

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

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

85 ：仕様書無しさん：2008/05/21(水) 09:53:22

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

まで読んだ

86 ：仕様書無しさん：2008/05/21(水) 10:02:44

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

87 ：仕様書無しさん：2008/05/21(水) 10:03:51

>>84
で、ポリモーフィズムってなんのことだ？

88 ：仕様書無しさん：2008/05/21(水) 10:11:55

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

89 ：仕様書無しさん：2008/05/21(水) 11:03:09

>>84
>OOの利点はポリモーフィズムだとか言うのの方が見たことないぞ。

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

90 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/21(水) 12:50:52

>>89
OOの手段だという記述はあっても、目的だという記述は見たことがないが。

91 ：仕様書無しさん：2008/05/21(水) 13:12:25

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

まで読んだ

92 ：仕様書無しさん：2008/05/21(水) 13:14:19

>>90
目的であるか手段であるか、と利点であるかどうかにどういう関連性があるんだ？

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

93 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/21(水) 13:23:17

>>92
目的＝利点だろう？

94 ：仕様書無しさん：2008/05/21(水) 13:56:11

>>93
目的が利点であったとして、手段が利点とならないわけではないだろう？

95 ：仕様書無しさん：2008/05/21(水) 14:31:30

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

96 ：仕様書無しさん：2008/05/21(水) 15:04:01

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

まで読んだ

97 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/21(水) 17:47:35

>>94
手段は利点にはならない。

98 ：仕様書無しさん：2008/05/21(水) 17:52:11

>>97
なぜ？

99 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/21(水) 18:20:51

>>98
手段は目的にならないからだ。

100 ：仕様書無しさん：2008/05/21(水) 18:48:04

101 ：仕様書無しさん：2008/05/21(水) 19:58:38

変更を見越して設計する必要が無くなるのなら、
行き当たりばったりでもいい、ちうことだよな。
すげーな、OO(AだかDだかPだか知らんけど)w

102 ：仕様書無しさん：2008/05/21(水) 20:15:52

> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点
> 目的＝利点

103 ：仕様書無しさん：2008/05/21(水) 20:18:04

>>84
インタフェースがOOの基本っていう話読みたかったらGoF買えよ
理解できなかった場合はUMLモデリングのエッセンスにも書いてあるからそっちを読め

104 ：仕様書無しさん：2008/05/21(水) 20:34:54

>>99
>手段は目的にならないからだ。
要するに『「目的＝利点」かつ「手段≠目的」』だから「利点≠手段」だといいたいのか？
なんだその小学生レベルの論理回路は。（正直ここまでひどいとは思わなんだ）

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

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

105 ：仕様書無しさん：2008/05/21(水) 20:42:48

ん、きっと何も言い返すことが出来ないからくやしくて言ってみただけ。
小学校低学年くらいのこどもがいる人はわかると思うよ。

106 ：仕様書無しさん：2008/05/21(水) 21:29:55

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

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

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

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

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

107 ：仕様書無しさん：2008/05/21(水) 21:33:06

不思議なんだが、おじゃばはなんでいつまでも基本レベルに留まってるの？
というかポリモーフィズムを否定するって、オブジェクトがわかってないってことじゃん。

108 ：仕様書無しさん：2008/05/21(水) 22:18:29

オブジェクトというかインターフェースな

109 ：仕様書無しさん：2008/05/21(水) 22:41:29

結局OOPも出来ない。

110 ：仕様書無しさん：2008/05/21(水) 22:46:12

インタフェースと組み合わせることで、応用範囲が広がるのは確かだけど、
元はオブジェクトだよ。

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

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

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

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

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

111 ：仕様書無しさん：2008/05/21(水) 23:20:14

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

112 ：仕様書無しさん：2008/05/21(水) 23:32:54

おじゃばはそれをオブジェクト指向と名付けちゃう。
オブジェクト指向が普及さないワケだ。

113 ：仕様書無しさん：2008/05/21(水) 23:59:07

おじゃばの頭はカプセル化どまり。つまり園児レベルだなこれ。

114 ：仕様書無しさん：2008/05/22(木) 04:59:56

>>99
>おじゃばはまだこれでも教えてるつもりなんだぜ？
>迷惑な話だよな
>わからない奴が人に教えようってんだから、最悪の先生だ

まで読んだ

115 ：仕様書無しさん：2008/05/22(木) 08:06:14

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

116 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/22(木) 09:34:54

>>101
OOの基本原理に従って設計すれば、オブジェクト単位での変更が容易になるため、将来を見越した仕様など
入れる必要はないと言う事だ。

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

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

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

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

117 ：仕様書無しさん：2008/05/22(木) 10:16:06

>>116
>オブジェクト＝インタフェースのみ
だから、誰がそんなことを言っていたのかとｗ

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

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

118 ：仕様書無しさん：2008/05/22(木) 10:32:29

>http://jibun.atmarkit.co.jp/lemb01/rensai/emb05/emb001.html
むしろ、仕様変更が発生しやすい組み込みにこそOOが有効という考え方もある。
世の中いろいろな仕事があるのだから、自分だけの業務経験(笑)で決めつけない
ほうがいいと思うよ。I社とやらの名誉のためにも。

119 ：仕様書無しさん：2008/05/22(木) 10:39:26

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

120 ：仕様書無しさん：2008/05/22(木) 10:44:28

わかったぞ、自作自演てやつだ
おじゃばっていうコテつかってわざと間違えて
名無しで説明してくれてるんだろ？

121 ：仕様書無しさん：2008/05/22(木) 11:14:22

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

122 ：仕様書無しさん：2008/05/22(木) 11:25:59

おじゃばは構成要素をOOだっていって延々語ってんの

123 ：仕様書無しさん：2008/05/22(木) 11:27:15

いや、レベルが低いだけだと思うよ。

124 ：仕様書無しさん：2008/05/22(木) 12:08:11

>>121
> だからカプセル化とかポリもーフィズムありきで考えるのではなく
だれも「ありき」なんていってないだろ。

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

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

125 ：仕様書無しさん：2008/05/22(木) 12:51:57

>>121
>I am おじゃば！
>I am おじゃば！！
>I am おじゃば！！！
>I am おじゃば！！！！
>I am おじゃば！！！！！
>I am おじゃば！！！！！！
>I am おじゃば！！！！！！！
>I am おじゃば！！！！！！！！

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

126 ：仕様書無しさん：2008/05/22(木) 13:02:41

>>121
>俺が悪かった
>俺がゆってたのはオブジェクトじゃなくて
>構造体と関数をくっつけただけの
>クラス指向だったんだ
>俺ははだかのおうさまだったのか…
>なんで誰も教えてくれなかったんだ

も読んだ

127 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/22(木) 17:40:17

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

128 ：仕様書無しさん：2008/05/22(木) 18:00:25

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

まで読んだ。

129 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/22(木) 18:04:09

>>128
初めて俺の言いたい事と一致したな。

130 ：仕様書無しさん：2008/05/22(木) 18:13:12

　仁和寺にある法師、年寄るまで岩清水を拝まざりければ、心うく覚えて、
ある時思ひ立ちて、ただひとり、徒歩より詣でけり。
極楽寺・高良などを拝みて、かばかりかと心得て帰りにけり。

　さて、かたへの人にあひて、「年比思ひつること、果たし侍りぬ。
聞きしに過ぎて尊くこそおはしけれ。そも、参りたる人ごとに山へ登りしは、
何事かありけん、ゆかしかりしかど、神へ参るこそ本意なれと思ひて、
山までは見ず」とぞ言ひける。

　少しのことにも、先達はあらまほしき事なり。

131 ：仕様書無しさん：2008/05/22(木) 18:21:15

>>128-129
おじゃばは皮肉も理解できないんだな
まあ想定の範囲内、か

132 ：仕様書無しさん：2008/05/22(木) 18:26:43

皮肉が理解できる頭があったら
既に恥ずかしくて首吊ってるよ

133 ：仕様書無しさん：2008/05/22(木) 18:39:34

継承を利用した差分プログラミングなんてとっくに廃れてるじゃん。
ロジックの共通性を根拠に継承を使ってはならないって今では常識。
共通するロジックが複数のクラスで現われる様なら、そのロジックには再利用性がある
って事だから、ユーティリティメソッドを提供するスティックなクラスに纏めるかアルゴリ
ズム自体をクラス化するかすればいい。
少なくとも、コーディング量が少なくて済むラッキーみたいなノリで継承を使う奴は、ろく
なもんじゃない。

134 ：仕様書無しさん：2008/05/22(木) 19:31:38

>>133
もう、それはOOじゃないな。構造化の共通サブルーチンだろ。
クラスメソッドにすると、ステートを外部で管理することになるからね。

135 ：仕様書無しさん：2008/05/22(木) 19:34:10

>>129
おじゃばさまに質問
オブジェクト指向がお薦めみたいだけど
アジャイル指向とアスペクト指向がオブジェクト指向とは
どう違うのかをわかりやすく教えて欲しい

136 ：仕様書無しさん：2008/05/22(木) 19:47:54

>>127
今時そんな目的でメソッドのオーバライドするやつはいねーよ。
そもそもその方法だとオーバライドした新規クラスを利用する側も
修正しなきゃならないだろ。

137 ：仕様書無しさん：2008/05/22(木) 19:58:50

もう全部visitorで

138 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/22(木) 19:59:59

>>133
>ロジックの共通性を根拠に継承を使ってはならないって今では常識。
その通り。
クラスは概念のインタフェースだとか言っている連中は、良く聞くように。
ただ、「今では常識」と言うより、「昔から基本」と言える。

>>134
その通り。

>>135
アジャイルは仕事の進め方。アスペクトはOOの上位版。

>>136
何！！確かに呼ぶ方も修正する。
呼ぶ方を修正しないでいけるのか？どうやるんだ？

139 ：仕様書無しさん：2008/05/22(木) 20:02:09

> クラスは概念のインタフェースだとか言っている連中は、良く聞くように。

お前、何言ってんの？

140 ：仕様書無しさん：2008/05/22(木) 20:03:27

>>134
入出力という形の単純なメソッドとして完結する場合、この実装が最も軽い。
その形に収まらない時はアルゴリズム自体をクラス化できないか考える。
java.util.*なんかが参考になる。
AOPが最近注目されてるけど、現状では実験的すぎて定石がまだない。

141 ：仕様書無しさん：2008/05/22(木) 20:07:15

＞アスペクトはOOの上位版
文脈だけで知ったかした感がありありだなｗｗｗｗｗ
どうしたらAOPがOOの上位版になるのか理由を教えてくれよｗｗｗｗｗ

142 ：仕様書無しさん：2008/05/22(木) 20:10:49

>>137
重いよｗ
StrategyやCoRなんかもアルゴリズムのクラス化ではよく使われるけど
ホントに今直ぐそれが必要か？と、自分に問いかけてから利用すべき。
本質的には10行ほどのコードを共有する為に、50行のコードを書き直し
50行のコードを書き足すとか、本末転倒もいいとこだからねｗ

143 ：仕様書無しさん：2008/05/22(木) 20:11:42

＞呼ぶ方を修正しないでいけるのか？どうやるんだ？

…は？
OO教えてくれる(笑)アナタが何を仰ってるの？

144 ：仕様書無しさん：2008/05/22(木) 20:24:57

>>138
クラスベースOOは縦でAOPは横。
分かるかな？分かんね～だろうなｗ

145 ：135：2008/05/22(木) 20:38:06

>>138
それじゃわかりません＞＜

146 ：仕様書無しさん：2008/05/22(木) 20:46:35

>>121
あ～ぁ、言っちゃたｗ、だいたいの奴はわかって黙っていたのにｗ
でも、おじゃばがOOを詳しいんじゃなくて、他の奴がバカなんだけどねｗ
特に、博士号もっていると自慢してる奴は、OOがまったく解らんバカだぞ
コテハンじゃないが、バカすぎてすぐわかるｗ

147 ：仕様書無しさん：2008/05/22(木) 21:09:15

>138
修正のためにオーバライド使うやつにあまり関わりたくないけど、
呼ぶ方を修正しないためにはどうすればいいと思う？
ネックになっているのはクラス名だけだろ？
そのクラス名を外部から渡せればこれは実現できる。
まあ、設定ファイルに書くってことだ。
それとファクトリーを理解すること。

それとさ、おじゃばのいってる差分修正なんかたいした話じゃないんだよ。
それって、シグネチャが変わらないって前提だろ、結局。
シグネチャとは、すなわちインタフェースなんだよ。
つまり、インタフェースをしっかり設計しなければ、
おあばの差分修正もたちどころに破綻するのはわかるよな。

148 ：仕様書無しさん：2008/05/22(木) 21:25:16

三三＼　　　　　／三
三三三＼　　　／三三
￣￣￣￣￣￣￣￣￣￣
　　　おじゃばがアスペクトを調べています

　　 _ｨ†N==ｭ_　 ~~~　　　　しばらくお待ちください。。。。。
　　/互巫乢/"/|　~~
　　Lｪｪｪｪｪｲ"/ |彡~
　｢ﾛﾛﾛﾛﾛﾛﾛｲ"/|彡
　∥￣￣￣７/ /彡
　∥＝＝＝／ /彡
`ミ＼j＿／／彡
　ミヽ＿_／彡
　　ミ　彡

149 ：仕様書無しさん：2008/05/22(木) 22:01:35

>>147
だれか、このおじゃば以上のアホが、何を言いたいのか
解説してくれ特に、これ
>そのクラス名を外部から渡せればこれは実現できる。
>まあ、設定ファイルに書くってことだ。

150 ：仕様書無しさん：2008/05/22(木) 22:04:21

おじゃばが突っ込む為の自作自演に一票

151 ：仕様書無しさん：2008/05/22(木) 22:08:59

おじゃばが出てこないと自演してるように見えちゃうぞ★
146とか149みたいにね
いや、俺はおじゃばが自演してるなんてこれっぽっちも思っちゃいない
思っているわけが無いだろう？
おじゃばは（自称）OOを理解した偉大な男だ
北の将軍様と比べても遜色ないほどに偉大だ
ノーベル賞を受賞してもいいぐらいだ
ただ、「いいかげんに自演はやめろ、おじゃばくん」
と、これだけは言わせてもらいたい

152 ：仕様書無しさん：2008/05/22(木) 22:21:58

>>147,150,151
自作自演乙、分かり易いぞｗ

153 ：仕様書無しさん：2008/05/22(木) 22:23:10

と、おじゃばがいってます

154 ：仕様書無しさん：2008/05/22(木) 22:25:03

なんか笑える展開になってきたな。
おじゃばはAOPでダメージ受けたからきょうはもう出てこないでしょ。

155 ：仕様書無しさん：2008/05/22(木) 22:28:45

>>147
すまんが、俺もわからん説明してくれ

156 ：仕様書無しさん：2008/05/22(木) 22:40:49

おじゃばはメソッドの書き換え＝オブジェクトの置き換えと言ってるが、
それは文字通りメソッドの書き換えでしかない。

OOの利点はオブジェクトの変更が容易　とか言ってるが、
そういう仕事はそもそも存在しない。
クラスの作り直しをするようなことはまずないし、
パッケージの作り直しなどは設計がヘタクソなだけ。

OOPの段階でのオブジェクトはクラスやパッケージのことを指す。
決してメソッドではない。

しかも例にあげているのは関数の書き換えだけで、
OOとはなんら関係がなく、
構造化と比較すること自体がナンセンス。

157 ：仕様書無しさん：2008/05/22(木) 22:43:05

そういやユースケースもコンポーネントもクラスもわかんねーって言ってたな。
言うだけ無駄か。

158 ：仕様書無しさん：2008/05/22(木) 22:58:05

>>149 >>155
OOとあんまり関係ないから説明しておくよ。
これはJavaなどでリフレクションを使って実現するのさ。
たとえばリソースバンドルに、ファクトリークラス名を指定する。
ここでは、ToolFactoryインタフェースを実装したFirstToolFactoryを
を仮定しよう。これを例えばconfig.popertiesファイルに書いておく。

TOOLFACRTORY=ja.co.foo.tool.FirstToolFactory

それをつかって、ファクトリクラスのインスタンスを生成。

String className = バンドルからTOOLFACRTORYをキーに取り出したクラス名
　：
ToolFactory toolFactory = Class.forName(className).newInstance();

後は、インタフェース経由で、ファクトリから個別実装を取り出す。

（続く）

159 ：146：2008/05/22(木) 22:58:18

>>149,155
だから、質問したら駄目だよｗ
OOがまったく解らんバカなんだからｗ

160 ：仕様書無しさん：2008/05/22(木) 22:59:10

>>158の続き

ここでToolFactoryインタフェースが以下のようなものだっだとする。
interface ToolFactory {
　public PrintTool getPrintTool();
　public DrawTool getDrawTool();
}

FirstToolFactoryは、PrintToolとDrawToolのインタフェースを実装した
独自のオブジェクトを内部で生成して返す。

ここで、先ほどの背低ファイルの内容をSecondToolFactoryにする。
このクラスは、やはり独自のツールを返せるが、
DrawToolだけ換えたいなら、そこだけSecondDrawToolオブジェクトを
返すようにすればいい。
プログラム内のコードは一切変更不要で、既存クラスの再コンパイルすらいらない。
なぜならシステムはインタフェースを経由して動いているから。

しかも、ファクトリーを経由させることで、複数のクラス郡を
多彩な組み合わせで動的に入れ替え可能となる。

161 ：仕様書無しさん：2008/05/22(木) 23:04:08

必死にOOP

162 ：仕様書無しさん：2008/05/22(木) 23:06:59

このように、一つのまとまったクラス群をコンポーネントとして
動的に入れ替え可能となることがポイントだよ。
再コンパイルすら不要ということね。

もちろんインタフェースの設計は重要。＞名無しで自演中のおじゃばさま

163 ：仕様書無しさん：2008/05/22(木) 23:13:26

OOとは関係ない話だな

164 ：仕様書無しさん：2008/05/22(木) 23:18:10

>>158,160,162
Java限定かよｗ
OOでは普通、メタクラスでやるんだけどねｗ
さすが、OOが解っていないｗ

165 ：仕様書無しさん：2008/05/22(木) 23:21:59

確かにこれは、デザパタとリフレクションの組み合わせに過ぎないが、
>>127がいかに泥臭いアホなことをやってるかがわかるだろう。

機能単位にコンポーネント化すれば、再コンパイルすら不要で
個々の機能の入れ替えができるのに、
おじゃばは呼び出し元を探して書き換えて、コンパイルしてこれがOOだというんだぜ。

166 ：146：2008/05/22(木) 23:22:10

>>164
だから、教えちゃ駄目だってｗ
でも、よく恥ずかしくなく説明出来たよなｗ
俺なら恥ずかしくって氏ぬなｗ

167 ：仕様書無しさん：2008/05/22(木) 23:26:48

ではメタクラスでどうやるのか説明してくれよ。
自演バレバレのwさん。

168 ：仕様書無しさん：2008/05/22(木) 23:31:41

>>165
>デザパタとリフレクションの組み合わせに過ぎない
これ笑うところ？
>>167
>ではメタクラスでどうやるのか説明してくれよ。
"説明してくれ"　おじゃばと一緒じゃんｗ

169 ：仕様書無しさん：2008/05/22(木) 23:33:54

要するにはずかしくて説明できないってことね。
おじゃば以下じゃん。

170 ：仕様書無しさん：2008/05/22(木) 23:37:00

リフレクションはJava限定じゃないだろ。インターフェースとリフレクションは
ある意味AOPの根幹を支える技術。

171 ：164：2008/05/22(木) 23:45:36

>>167
UMLで<<MetaClass>>だ

172 ：仕様書無しさん：2008/05/22(木) 23:49:24

>>170
Java限定じゃないが、全ての言語にあるわけじゃない
限定機能だ

173 ：仕様書無しさん：2008/05/22(木) 23:51:52

こいつ前スレでも自演してた奴だろ、こいつのウザさはおじゃばと双璧をなすな。

174 ：仕様書無しさん：2008/05/22(木) 23:54:04

>>171
で？
まさかそれしか書けないのか？
こちとらMDAもさんざんやって、使えないことはわかってるけどさ。

175 ：仕様書無しさん：2008/05/22(木) 23:58:44

>>174
クラス図から実装出来ないのか？
ほんとお前勘弁してくれよｗ

176 ：仕様書無しさん：2008/05/23(金) 00:02:40

そりゃ無理だわ。
世の中にまともなクラス図なんてまず存在しないもの。
クラス図はスナップショットで、しかもはしょってあるしな。
そもそもクラス図だけで実装できるやつ見てみたいね。

でもメタクラスとは関係ないね。メタクラスはどうした？

177 ：仕様書無しさん：2008/05/23(金) 00:04:10

>>172
今どきOO言語でリフレクションをサポートしない言語の方が珍しいっつうの。
サポートしてなくても動的ライブラリと関数ポインタ使ってそれに近いことはできる。

178 ：仕様書無しさん：2008/05/23(金) 00:15:43

>>176
>世の中にまともなクラス図なんてまず存在しないもの。
自分が読めないのを人のせいにするなよ

>でもメタクラスとは関係ないね。メタクラスはどうした？
関係ない？　本当クラス図を理解出来ないんだｗ

179 ：仕様書無しさん：2008/05/23(金) 00:23:19

笑うしかないけど、クラス図ではクラスの静的な関係しかわからないのはいいか？
その関係がいつどう発生するかは、他の図を見なければならない。
クラスの属性の更新も同じことだ。
それを隅から隅まで記述した設計書などほとんどないよ。

関係ないな。メタクラスがなんだかわかってないだろ？

180 ：仕様書無しさん：2008/05/23(金) 00:27:38

>>177
インタプリタ系だけだろう、EXE系は実装されているか？
自分の世界だけで物を考えるな

お前の言う「今どきOO言語」で使用出来る
リフレクション・動的ライブラリ・関数ポインタはUMLで表記出来るか？
「今どきOO言語」を使ってOOで開発しているんだろ？

181 ：仕様書無しさん：2008/05/23(金) 00:28:29

>>177
言語とOOを切り離して考える努力をしろ
どういうものを作るかと、どうやって作るかは別の話だ

182 ：仕様書無しさん：2008/05/23(金) 00:35:18

>>180,181
> リフレクション・動的ライブラリ・関数ポインタはUMLで表記出来るか？

177じゃないけど、余裕でできるだろ。何訳わからんこといってるんだ？
説明が足りなきゃ、他の図法や日本語を使えばいいし。

どういうものを作るかと、UMLを使うかは確かに別な話だよな。

183 ：仕様書無しさん：2008/05/23(金) 00:43:17

>>179
クラス図から実装できないとは　笑う　ほんと頭わるな～
俺はクラス図だけでシステムを完成させろとは書いてない
クラス図に書かれている事を実装出来ないのかと言う意味だ

>関係ないな。メタクラスがなんだかわかってないだろ？
関係ないのに、何故UMLには<<metaclass>>のキーワードが定義されているんだ？

184 ：仕様書無しさん：2008/05/23(金) 00:44:37

わるな？

185 ：仕様書無しさん：2008/05/23(金) 00:48:30

>>182
>177じゃないけど、余裕でできるだろ。何訳わからんこといってるんだ？
じゃ関数ポインタをお願いする、メソッドじゃなく関数だぞ

186 ：仕様書無しさん：2008/05/23(金) 00:48:36

>>183
だから、できないってばよ。
クラス図ってがわだけしか書いてないじゃん。
ひな形作れって話か？
そんなのツールでやれよ。

187 ：仕様書無しさん：2008/05/23(金) 00:55:25

メタクラスってのはUMLの文法を規定するためにあるんだ。
つまり、UMLはメタクラスを用いて、記法を拡張できる。

<<metaclass>>
関数ポインタ

実は、UMLのメタクラスも、メタメタクラスによって定義された記法の一つに過ぎない。
メタメタクラスを用いて、別な表記法向けの文法を定義することもできる。
実際、他のモデルも定義されてるよ。

188 ：仕様書無しさん：2008/05/23(金) 00:55:36

>>186
>そんなのツールでやれよ。
俺はツールでもかまわないが

189 ：仕様書無しさん：2008/05/23(金) 00:57:20

クラス図だけってのはOO設計が分かってないと言われても仕方ないな
インターフェースとクラスは常に組になるのがOO

OOの利点はオブジェクトの変更が容易なこと、とか言ってるマイナス工程者はほっとくとして、
アクティビティ以降導き出したクラス図には必ずインターフェースが存在する
コンポーネント間の相互関係がクラス図だけでは分からないからな

これが分かってない奴がテーブル項目のget,setを羅列するようなクラスを作る

190 ：仕様書無しさん：2008/05/23(金) 01:00:36

たいていのクラス図には、主要なメンバは書いてあっても、
細かい要件までは書いてないからなぁ。どんな入力に対して
どんな出力が正解かまでは判断つかないわなぁ。
クラスの概要を把握するのには役立っても、これで実装でき
ますなんて無責任なことはまず言えんわなぁ。

191 ：仕様書無しさん：2008/05/23(金) 01:03:48

それはできそこないのクラス図だろ・・・

192 ：>191：2008/05/23(金) 01:08:22

それはできそこないのクラスだろ・・・

193 ：仕様書無しさん：2008/05/23(金) 01:10:53

実装が出来るくらいの粒度で設計してやらんと、
出来上がった物が別物になってるぞw

194 ：仕様書無しさん：2008/05/23(金) 01:15:04

>>189,190
お前ら、ちゃんと読んでるか？
>修正のためにオーバライド使うやつにあまり関わりたくないけど、
>呼ぶ方を修正しないためにはどうすればいいと思う？
>ネックになっているのはクラス名だけだろ？
これの説明でメタクラスを使うと言っている、だからクラス図だけで良いだろう
別にクラス図だけでシステムを作れとは書いは、いない。

195 ：仕様書無しさん：2008/05/23(金) 01:19:13

誰彼かまわず噛みつく奴だなあ

196 ：仕様書無しさん：2008/05/23(金) 01:20:44

>>180
EXE系ってのが何を指すのかわからんが、コンパイラ型言語のことなら、
動的ライブラリと関数ポインタでそれに近いことはできる。
コンパイラ型なんだから、ネイティブな環境を駆使して、そういう仕組み
を作ればいいだけのこと。言語が仕様としてサポートしてないからできない
なんて発想はよくない。リフレクションは目的ではなくて、手段なんだから
できないならできないで別の手段を考えればいいだけのこと。当然リフレク
ションを使う際はその分のオーバヘッドがあるから利便性とのトレードオフ
も考えなくてはならない。

197 ：仕様書無しさん：2008/05/23(金) 01:22:37

>>194
もう必死だな。
だからどう使うのさ。単に説明すればいいのさ。
そろそろ寝るから、明日の夜までに書いといてね。

198 ：仕様書無しさん：2008/05/23(金) 01:28:23

>196
だからそれは作りの話だろって
リフレクションを使ってもいいし、
iniファイルでやってもいいし、
共有メモリ使ってもいいし、
ハードコーディングでもいいし

なんでリフレクションにこだわるんだ？
スレ違いも甚だしいし、OOとは全く関係ないだろ

199 ：仕様書無しさん：2008/05/23(金) 04:47:46

でも、けっきょくおじゃばの言ってることって
「理屈じゃ説明できないけど、やってみたらすごいんだよOOって。
なにがOOなのか構造化じゃないのかは、業務経験(笑)で知ったからうまく言えないけど。」
だよなぁ。否定するだろうけど。
…怪しげな宗教？

200 ：仕様書無しさん：2008/05/23(金) 07:59:22

>>198
おまい、リフレクションでどういうことができるかわかってねぇだろ？
比較対象がおかしいし。
あと、リフレクションはOOと組み合わせてこそ有効な使い方ができる。
OOと関係ないなんてアホも甚だしい。

201 ：仕様書無しさん：2008/05/23(金) 08:34:43

>>198
君は自分で「お前はおじゃば以下だ」などとのたまっているが
自分で自分をけなしていることには違いない
そうまでするほどにお前は地に落ちているということだ、滑稽だ
違うというならおじゃばとして出てこいよ
また遊んでやるからよ

202 ：仕様書無しさん：2008/05/23(金) 09:23:51

>>201
おじゃばはリフレクションなんか知らないだろ。
つかバカをみんなおじゃばにするのは良くない
おじゃばは、おじゃばらしいバカであったほうがいいよ。

203 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/23(金) 09:59:19

>>141
一応言っておくが、俺も説明を読んだ程度で使った事はない。
それによると、アスペクトはOOの苦手な、多くのクラスに散らばる処理（ログ出力や変換メソッドや140）を
親クラスにまとめる事が出来るらしい。OO技術者がみんな懸念していた事への、解決の手段を提供した
と言う事だな。使って見たいとは思っていたが忘れていた。今度使ってみるかな。

>>146
知っていて黙ってたのか。しかしハカセ多すぎないか？

>>147
Class.forNameを言っているようだが、確かにそれで出来るが、全ての呼び出しをファクトリーには
しないだろう？だからそれでは、予期した所しか変えられない。それとも全てファクトリーにするのか？
あとインタフェースが重要なのは分かるが、例えば1つのクラスに入るべき2つのメソッドが、別々の
クラスに入っていたらどうなる？1つのクラス修正では終わらないだろう？10個なら？入れ子ならどうだ？
インタフェースが無茶苦茶だとまずいのは当たり前、俺が言っているのはそっちの方だよ。

204 ：仕様書無しさん：2008/05/23(金) 10:31:39

>>203
を、ちゃんとぐぐってきたじゃん。偉いぞジジイ。で「上位版」だったかなｗ

205 ：仕様書無しさん：2008/05/23(金) 11:12:02

> Class.forNameを言っているようだが
ここで Class.forName を持ってきたあたりがいかにもおじゃばだな。
java.lang.reflect

> 1つのクラスに入るべき2つのメソッドが、別々のクラスに入っていたらどうなる？
それは OO 以前の問題だろ。

206 ：仕様書無しさん：2008/05/23(金) 11:56:39

> 俺も説明を読んだ程度で使った事はない
> 俺も説明を読んだ程度で使った事はない
> 俺も説明を読んだ程度で使った事はない
> 俺も説明を読んだ程度で使った事はない
> 俺も説明を読んだ程度で使った事はない
> 俺も説明を読んだ程度で使った事はない

OOを教えてくれる(笑)あなたが？

207 ：仕様書無しさん：2008/05/23(金) 13:43:19

ボブ「ほら、簡単でしょ？」
おじゃば「すげえ！構造化って最高！他はクズ！」
ボブ「ほら、簡単でしょ？」
おじゃば「すげえ！OOって最高！他はクズ！」
ボブ「ほら、簡単でしょ？」
おじゃば「すげえ！アスペクトって最高！他はクズ！」

208 ：仕様書無しさん：2008/05/23(金) 16:18:00

>>203
> アスペクトはOOの苦手な、多くのクラスに散らばる処理
MetaObject Programing ってご存じ？

C++/Java で可能なのかどうかは俺はしらんがwwWww

209 ：仕様書無しさん：2008/05/23(金) 18:17:15

>>208
知らないから教えて

210 ：仕様書無しさん：2008/05/23(金) 19:08:41

>>208
いまぐぐってWikipedia読んでみただけだけど、面白いねこれ。
神の手を持ち込んでしまえということだな、こりゃ。笑ったけど。

211 ：仕様書無しさん：2008/05/23(金) 19:16:08

あ、でもランタイムには神の手は動かないことで安全を確保しようっつことかな。
まさに型にこだわるのの究極？かもしらんね。

212 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/23(金) 20:29:19

>>156
言っている事が無茶苦茶だな。俺の言っている意味が通じていないようだ。
まず継承と勉強して、オーバーライドを習得するのが先だな。話はその後だ。

>>157
ユースケースからクラス図が作れなかっただけだ。
ちなみに、ユースケース図と言うのはOOと関係ない、要求仕様をまとめるための物で、
クラス図が作れる訳ないのは知りつつ、検証しただけだがな。

>>176
クラス図を見てシステム作れないようでは、PGレベルではないな。恥ずかしいぞ。
クラス図だけでシステム作れよ。

>>199
理論は単純だ。システムをクラス分割して、抽象化しているのだから、変更が容易なのは当たり前だろう。
理屈も実装方法も示したぞ。宗教っているのは、「適切に吟味する」とか言っている奴だろう。

213 ：仕様書無しさん：2008/05/23(金) 20:39:59

>>212
＞ユースケースからクラス図が作れなかっただけだ。
ユースケース駆動がほぼOOの上流工程のスタンダードなのに。
OOには関係ないんじゃなくて、コーダのおじゃばには関係ないだけだよ。

＞クラス図を見てシステム作れないようでは、PGレベルではないな
クラス図が真に出来上がった時点で、システムは8割方完成してる。
クラス図から何かのOOPLに翻訳してるだけの仕事はPGとは言わんし、
システム作ってるとも言わん。

ただのコーダ。

214 ：仕様書無しさん：2008/05/23(金) 20:44:32

>>212
>理屈も実装方法も示したぞ
笑うとこだな。setとgetがついたテーブル定義と、
ナントカ処理を言い換えた奴しか出してないくせに。
ちゃんと説明できてれば>127みたいな事はいわんだろな。
その>127についてだが、ではOOにしたことで構造化とどこが違って
修正が一部ですんだのかを説明してくれ(R)。
別に全部してくれとは言わんぞ。お前じゃあるまいしな。
一番効果的だと思ったところを、端的に
構造化だとこうだけど、OOだとこうできるから、変更が少ない。
簡単だろ？

215 ：仕様書無しさん：2008/05/23(金) 20:53:53

ああそうだ、お前の言い分だと分析や設計は別にいいみたいだから、
お得意のコーディングレベルでいいんじゃないかな。
クラス図だのインタフェースだのUMLはいらんぞ。

216 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/23(金) 20:58:58

>>205
で、全ての呼び出しで、リフレクションを使うのか？
OO以前の問題？ではどうやって決めるんだ？

>>206
俺だって何でも知っている訳ではないからな。

>>207
構造化の利点／欠点、OOの利点／欠点は何度も説明しているぞ。

>>208
209と同じ

>>213
ほー、ではいいかげん、ユースケース図からクラス図を作ってくれないか？レンタルシステムで。
ちなみに俺の他にも、出来る訳ないと思っている人はいて、どうやるか関心があるみたいだぞ。

では、クラス図から何も作れないのは何？

217 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/23(金) 21:07:34

>>214
あの例を見て分からないのか？仕方ないな。
あるシステムで利用者をクラス化しました。利用者件数が増えて3000人から10万人になり、
通信を使って外部のデータを使うことになりました。利用者を拡張したクラスを追加して使用するだけで、
修正が終わりました。次に通信を使うことになり、処理速度が遅くなりました。
拡張した利用者にキャッシュ機能を組み込むことにより、その修正だけで完了しました。

もし構造化で、DBのテーブルをなめて処理するような所があったら、全て作り直しだよな。

218 ：仕様書無しさん：2008/05/23(金) 21:10:03

>>217
いや、だから日本語はいいからコーディングレベルでったろ。
構造化だとこうで、OOだとこう。
簡単だろ？コードの方が得意なんだし。

219 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/23(金) 21:21:41

>>215
コードレベルか
--------------------------------------------------
Users us;
us.selectAll();
for(; us.hasNext(); ){
　　us.getRecord();
}

--------------------------------------------------
FILE *fp = fopen("user.dat", "rb");
for(; ;){
　　fgets(rec, sizeof(rec), 1, fp);
}

下の例がファイルから通信に変わりました。休日は返上です。

220 ：仕様書無しさん：2008/05/23(金) 21:32:59

>>219
そりゃ、OOと構造化の説明じゃねーじゃん･･･

221 ：仕様書無しさん：2008/05/23(金) 21:38:44

つまりおじゃばの言うOOは呼び出しに階層を入れるということだな。
それって構造化じゃないのか、はともかく、確かに抽象化(笑)ではあるな。

222 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/23(金) 21:42:17

利用者の抽象化だろ。
下の例にはこの後、通信が遅いからキャッシュ機能を組み込めと言われ、傷害事件が発生する悲劇が
待っているぞ。

223 ：仕様書無しさん：2008/05/23(金) 21:47:28

それを言ったら、お前の出したfgetsも、端末かファイルか関わらず読めるわけだよな。
抽象化のレベルが違うだけじゃないのか。どこを抽象化したらOOなんだ？

224 ：仕様書無しさん：2008/05/23(金) 21:47:30

そりゃお前の実装が稚拙だからじゃろ

225 ：仕様書無しさん：2008/05/23(金) 22:09:29

>>219
別に下の例のコードが存在する関数「GetUserData(void *dataList)」かなんかの実装が若干変わるだけだろ。

226 ：仕様書無しさん：2008/05/23(金) 22:20:52

ここまでを要約すると
おじゃばはSEXを高度に抽象化することによって
ちんぽには一切触れずに不動のまま
何回でも抜けるらしいことがわかった

227 ：仕様書無しさん：2008/05/23(金) 23:43:08

>おじゃば
おまえ、書店にあるオブジェクト指向の本はあらかた読んだって以前書いてたが、
あれはなんなんだ？

228 ：仕様書無しさん：2008/05/23(金) 23:52:42

>222
お前の言う「オブジェクト」とは具体的に言え
Javaで言えば何がオブジェクトで何がオブジェクトでないのか、
お前の認識を明確にしろ

229 ：仕様書無しさん：2008/05/24(土) 00:17:22

おじゃば構造化も分かってない説

230 ：仕様書無しさん：2008/05/24(土) 00:26:22

>>228
おじゃば的にはデータ＋メソッドだったらオブジェクトなんじゃね？

231 ：仕様書無しさん：2008/05/24(土) 00:46:18

おまえら、絶対コード書くなw
迷惑だw

232 ：仕様書無しさん：2008/05/24(土) 01:35:38

コード

233 ：仕様書無しさん：2008/05/24(土) 04:41:10

>>227
どこの田舎の書店だよ、って感じだよな。
オブジェクト指向と書いてある雑誌が2冊とか。

234 ：仕様書無しさん：2008/05/24(土) 06:54:41

>>203
根本的にアスペクト指向を理解できていない。
親クラスにまとめる・・・ではない。

>>219
学生？プロの書くコードではないな・・・。

235 ：仕様書無しさん：2008/05/24(土) 06:56:18

>>226
コンドームは、インターフェースってとこだな。
直にアクセスするよりもリスクが減る。

236 ：仕様書無しさん：2008/05/24(土) 07:20:07

>>234
バグだらけだもんな。
バイナリーとテキストの違いもわかってないし。EOFも・・・。
C++？ならそもそも fopen, fgets を使わないだろ・・・それに、
fgetsの引数の数、エラー処理、その他はサンプルだろうし許されるかもしれんが。

たった数行のプログラムでこれだけ問題を抱えることができるとは、
神かも知れん。

FILE *fp = fopen("user.dat", "rb");
for(; ;){
　　fgets(rec, sizeof(rec), 1, fp);
}

237 ：仕様書無しさん：2008/05/24(土) 07:27:14

>>217の意味がよくわからん、解説してくれ。

＞利用者件数が増えて3000人から10万人
この場合、なんでクラスを拡張するんだ？
「利用者」をクラス化してるんならインスタンスの数が3000から10万に変わるだけじゃないのか？

＞次に通信を使うことになり（略）キャッシュ機能を組み込む
OOの場合　：利用者クラスにキャッシュ変数を追加、通信メソッドを修正
非OOの場合：キャッシュ変数を追加、通信関数を修正
何か違うのか？

238 ：仕様書無しさん：2008/05/24(土) 07:54:12

>>217
>>219
データ取得部の変更に対して強い設計をオブジェクト指向的に解くと、
普通、データアクセス部を抽象化することになると思う。
サンプルによると「利用者クラス」にデータアクセス部分を抱き込んでる
時点で抽象化のレベルが一階層間違ってると思う。

サンプルでは、利用者オブジェクト（us, rec)に、getRecord を持たせるか
どうかが議論されているようだが、論点が違う。
（getRecordという名前のネーミングセンスは置いておいて）

データブロックから値を読み取りオブジェクトのメンバにセットする仕組み
のみを、Usersに持たせるべきだと思う。データの取得先（ファイル、通信、
DB）に関しては、別オブジェクトにすべきだろう。

つまり、getRecord メンバ関数がUsersに存在すること自体 NG という意味
です。

データの保存先の仕様を変えた場合に、本質的に関係のない「利用者クラス」
の変更が必要にならないように設計するというのが、オブジェクト指向的だと
思う。単一責務の原則(SPR)参照のこと。オブジェクトの生成に関しては、
デザインパターンの基礎なのでそちらを参照のこと。

239 ：仕様書無しさん：2008/05/24(土) 07:59:32

>>238
つまり「Usersクラスはデータの保持管理だけをすべき」ってことだよな？
つーことはデータを取得→Usersに対して値のセットを依頼するような
コントローラクラスが必要になると思うんだが、その善し悪しは時と場合によらないか？

240 ：238：2008/05/24(土) 08:24:40

>>239
> つまり「Usersクラスはデータの保持管理だけをすべき」ってことだよな？
そのとおりです。

>つーことはデータを取得→Usersに対して値のセットを依頼するような
>コントローラクラスが必要になると思うんだが、その善し悪しは時と
>場合によらないか？
おっしゃるとおり戦略は複数あると思います。ポイントは「変化のベクトル」
です。今回の例ですと、「利用者クラス」は変化しないというなら、
コントローラクラスを設けるのがよいと思います。が、利用者クラスに
亜種がいろいろできるようですと、今度は修正量が増えます。

コントローラクラスを用いない場合は、
「利用者クラス」は実際には、「利用者インターフェース」になるのかも
しれません。で、データ取得部をサブクラスにやらせるというのもありだと
思います。ただ、ここでも、あくまでも利用者インターエースには、
生成に関する（getRecords)のようなメンバを持たせたりはしません。

241 ：238：2008/05/24(土) 08:27:31

前者は、利用者クラスを変更すると、コントローラクラスも変更することになる
ということです。

242 ：仕様書無しさん：2008/05/24(土) 08:48:33

おじゃばが、オブジェクト指向だと言っている方のソースも
オブジェクト指向じゃないということだけは理解できた。

243 ：仕様書無しさん：2008/05/24(土) 14:34:03

おぶじぇくとしこうをりかいできました

　　／￣＼
　　| 　^o^　|　
　　＼＿／
　　＿|　|＿
　　|　　　　|
　　　　　　　　／￣＼
　　　　　　　　|　　　　 |　＜　それは　おじゃばくとしこうです
　　　　　　　　＼＿／
　　　　　　　　＿|　|＿
　　　　　　　　|　　　　　|

244 ：仕様書無しさん：2008/05/24(土) 14:46:36

構造体をfgetsで読もうとするバカって…

245 ：仕様書無しさん：2008/05/24(土) 15:58:35

多分、おじゃば的にはrecはcharの配列なんだろ、紛らわしい名前だが。
そして、無限ループにしてるんだから、きっとfgetsの後には何かが省略
されてるんだろ。と、好意的に解釈するとして....
しかし、>>219で、下の例だと休日返上で、上は休日返上じゃない理由が
わからん。上のUsersクラスのコードの中身が下のコードみたいになって
んだったら、結局やらなきゃならんことはたいして変わらんように思うが。
まさか、下の例がグローバルスコープにだらだら書いてある想定なのか？
あいからわず例えが悪いし、こいつの説明下手さは天下一品だな。

246 ：仕様書無しさん：2008/05/24(土) 16:49:37

for(;;)
こんなこと書くバカがまだいるんだな

247 ：仕様書無しさん：2008/05/24(土) 17:36:17

>>242
両方とも構造化ですらないような。

248 ：仕様書無しさん：2008/05/24(土) 17:43:43

>>240
あー、すまん。完全に>>214を読み違えてた。
外部のデータって利用者そのものか。
まさかそんなバカな設計だとは思いも寄らず、利用者が使うデータだと思いこんでた。
だったら>>240の主張する通り、factoryパターンみたいに生成用のクラスがいるべきだと思うよ。

249 ：仕様書無しさん：2008/05/24(土) 17:45:19

×>>214 ○>>217

250 ：仕様書無しさん：2008/05/24(土) 17:49:28

あ、逆だった
○>>214 ×>>217

251 ：仕様書無しさん：2008/05/24(土) 17:53:03

for('A')

252 ：仕様書無しさん：2008/05/24(土) 19:34:04

利用者クラスに利用者の追加・変更・削除を持たすような奴にOOはどうかなぁ？

253 ：仕様書無しさん：2008/05/24(土) 19:40:28

利用者テーブルのゲッターセッターの発想の延長　ってなだけだろ

254 ：仕様書無しさん：2008/05/24(土) 19:56:57

ORM使うときはモデルクラスに追加や削除メソッドって普通に持たせるけど

255 ：仕様書無しさん：2008/05/24(土) 19:57:22

って、自然と思うのか？

256 ：仕様書無しさん：2008/05/24(土) 20:00:35

利用者の集合に、利用者を追加とかすることはあってもそりゃないだろ。
コレクションは別のクラスだぜ。

257 ：仕様書無しさん：2008/05/24(土) 20:01:15

自然と思うかどうかはともかく、そういうやり方が推奨されてるし使い易い

258 ：仕様書無しさん：2008/05/24(土) 20:09:58

ま、そう言うとおじゃばはUsersはコレクションだと主張しそうだけど、
奴はレンタルの会員クラスに追加・変更・削除入れるからな。
区別は無さそうだろ？せめてこう書かなきゃな。これもおかしいけど。
Users us;
User u;
us.selectAll();
for(; us.hasNext(); ){
　　u=us.getRecord();
}

259 ：仕様書無しさん：2008/05/24(土) 20:11:08

自演乙

260 ：仕様書無しさん：2008/05/24(土) 20:15:16

ORMではモデルクラスのコレクションを取得するメソッド（大抵はスタティックメソッド）
もモデルクラスに持たせる。全然問題ない。
User user = User.get(userId);
user.name = "山田太郎";
User.update(user);

List list = User.getList(condition);

261 ：仕様書無しさん：2008/05/24(土) 20:15:52

で、せめて
us.insert(u);
us.update(u);
us.delete(u);
us.save();
とかでないとおかしくないか？

262 ：仕様書無しさん：2008/05/24(土) 20:23:14

おかしいとは思わない。使いややすいかどうかが大事。
ActiveRecordしかり、Hiernateしかり。

263 ：仕様書無しさん：2008/05/24(土) 20:23:43

>>260
おいおい、そこでListクラス出したら話が違うだろ。
まぁいいか。ORMとか一般的に言っちゃう奴だし。

264 ：仕様書無しさん：2008/05/24(土) 20:25:02

やべ、スペルミス。↑Hibernate の間違い

265 ：仕様書無しさん：2008/05/24(土) 20:28:44

というわけで、なぜORマッパが必要で、それでもOOとのマッチングはいまいちだ、
ちうおはなしでした。

266 ：仕様書無しさん：2008/05/24(土) 20:36:26

いまいちじゃないよ。DBの設計さえちゃんとしてればね。

267 ：仕様書無しさん：2008/05/24(土) 20:42:21

ん？そのちゃんと、には興味があるなぁ。
ORマッパに適したテーブル設計とかあるのか？

268 ：仕様書無しさん：2008/05/24(土) 20:51:23

ん？あるよ、ORマッパによっても変わるだろうけど、大抵は、複合キーは使わない
とか、自然キーも極力使わないとか、テーブル名は英語の複数形にするとか、単語の
区切りをアンダースコアで明確にするとか、多対多の表現にはそれぞれのキーフィー
ルドだけの関連テーブルを作るとか。まぁこうしないと使えないというわけではない
けど、そうした方が作るときの手間が省けるということ。
つまり、Convention Over Configurationという奴。

269 ：仕様書無しさん：2008/05/24(土) 20:55:20

>>260
そんな実装ありえないだろ？もう直感的に気持ち悪いぞ。
O/Rマッピング云々て話ですらねーよ。
その実装がO/Rマッピングを行う上で便利になるというなら
何がどう便利になるのか説明してくれ。

270 ：仕様書無しさん：2008/05/24(土) 20:55:51

てかさ、ORMだとモデルクラスに追加・変更・削除がある、んじゃなくて
それこそ親クラスから継承してるだけじゃないの？ってあるのには変わらないか。
SQLを組み上げるだけだもんね。でもORマッパでもEOFとかCayenneは別だよね。

271 ：仕様書無しさん：2008/05/24(土) 20:58:30

>>266
O/Rマッピングの利点は自動化で難点はパフォーマンス。
言語上の制約自体は変わらないから、マッチングが良くなったり悪くなったりはしない。

272 ：仕様書無しさん：2008/05/24(土) 20:58:34

>>269
気持ち悪いかどうかはともかく、実害ないじゃん。
俺は気持ち悪いとは思わないけど。
Activerecord のサンプルをググってみ？

273 ：仕様書無しさん：2008/05/24(土) 21:01:02

>>270
そのORMもO/Rマッピングと読んでいいの？
てか、ORMなんて略語持ち出したの誰だよ？
ORMと略される語呂は沢山あってウザイんだよ！ｗ

274 ：仕様書無しさん：2008/05/24(土) 21:03:28

>>273
>254だな。見てわかるとおり。

275 ：仕様書無しさん：2008/05/24(土) 21:04:18

自分が知らないからってウザイとかいうなよ、文脈から判断しろよ、ヴォk

276 ：仕様書無しさん：2008/05/24(土) 21:13:34

>>272
俺はRubyはさっぱりだけど、ActiveRecordぐぐってみたよ。
なんだ、モデルクラス(ActiveRecord)がコレクションのサブクラスじゃないか。
だったら納得した。よーするにDB上の物は全部コレクションだと。なるほど。

277 ：仕様書無しさん：2008/05/24(土) 21:13:52

>>272
詳細がない今の状態ですら嫌な予感しまくりだよ。
そこが直感で分かんない方が怖いよ。
個と群を同一視するメリットが何一つない。
一方で肥満化というデメリットは確実にある。

その実装がO/Rマッピングを行う上で便利になるというなら
何がどう便利になるのか説明してみ。

278 ：仕様書無しさん：2008/05/24(土) 21:16:39

これで月曜日におじゃばが「だから俺が言っただろう」言うだろうなｗ

279 ：仕様書無しさん：2008/05/24(土) 21:19:14

>>277
そもそも、Rubyには単一責任の原則などという理屈は通用しない。
Javaとはパラダイムが違う。
JavaとRubyのインピーダンスミスマッチだなｗ

280 ：仕様書無しさん：2008/05/24(土) 21:23:13

>>277
ちがうの、O/Rマッピングを行う上で便利になるんじゃなくて、
既にO/Rマッパがそういう基底クラスを用意してくれてて、使う方は
そういう使い方になってしまうの。
RubyのActiveRecordは、いわゆる「Active Recordパターン」の
一つの実装なの。他にもHibernatもCakePHPでも全部こんな感じなの。
俺にこれを気持ち悪いと思えといわれても俺が便利だと思うんだから、
俺の勝手だろ、お前は勝手に気持ち悪いと思ってればいいじゃん。

281 ：仕様書無しさん：2008/05/24(土) 21:31:23

ORMのモデルクラスは、個を現すというより個と群を生成する
ファクトリクラスみたいなもんじゃね？
まぁ役割は生成だけじゃなく、更新や検索など他にもあるけど。

282 ：仕様書無しさん：2008/05/24(土) 21:43:14

すまん、Hibernateはちょっと違ったかもしれん。
使ったのがずっと前のことなので勘違いしてた。

283 ：238：2008/05/24(土) 21:44:10

オブジェクト指向に熟練していても、データーベースに疎い人は意外と多い。
データーベースを知っているなら、ORMは使わないだろう。
SQLを知ってるならORMは不要だと思う。SQLで仕事をしないと高価なRDBMSを
使う意味が半減してしまうというのもあるな。

そもそも、オブジェクト指向が好きな人は、パフォーマンスに疎い。
どちらかというと、開発の生産性を重要視する。まぁ、パフォーマンスか
納期か？といわれると俺も納期を優先させてしまうんだけどね。

オブジェクト指向を理解できる理解力があるなら、SQLはすぐにマスター
できる。もったいない。

284 ：仕様書無しさん：2008/05/24(土) 21:47:27

つまり、アセンブラ最高と？

285 ：仕様書無しさん：2008/05/24(土) 21:47:39

>>283
きたなおじゃばw
なんの脈絡もなく上から発言、さすがだ。

286 ：仕様書無しさん：2008/05/24(土) 22:06:59

>283
オブジェクト指向が理解できるとSQLが理解できる、ってなんじゃそりゃ？
関連性が何もないだろ
まあいいや

ORMの話題だけど、
ORMの前に、そのクラスが持つ責務に対して、
どういったことをさせるかがOOの基本じゃん
そのインターフェースの内容が不明のまま会話してるから、噛み合わないんだろ

287 ：仕様書無しさん：2008/05/24(土) 22:10:20

それを>272のド素人に言ってやってくれ

288 ：仕様書無しさん：2008/05/24(土) 22:26:20

ListやVectorなんかがあるから、群を管理するクラスをわざわざ作る
必要性にせまられることはあまりなくなったな。Listインターフェース
が備えるメソッドで大体こと足りる。特にGenericが使えるようになって
からはそう。簡単なDBとのインタフェースはDaoパターンで十分。

289 ：仕様書無しさん：2008/05/24(土) 23:45:04

テーブルとかビューのデータクラス作るのは良いアイデアだとは思うんだが、
SQL書けば済むところを無理矢理こねくりまわすからO/Rマッピングは使いにくいんだよ。

290 ：238：2008/05/24(土) 23:45:46

データアクセス部分の実装の話に偏ってきている。データーベースに関して
実装に何を選ぶかは、パフォーマンスとか採用するシステムに依存するから
純粋なオブジェクト指向の議論から外れると思う。
まぁ、SQLの話をした俺も反省しないといけないんだが・・・。

291 ：仕様書無しさん：2008/05/24(土) 23:47:58

誰かがもう言ったかもしれんが
オブジェクト指向が普及しないのは
C言語（orアセンブラ）より実行速度が早いオブジェクト指向言語がないからだと思う

結局のところ肝心な物を作るときにはオブジェクト指向型言語は使えない

概念だけ取り入れることは可能かもしれんが、概念だけでまともに実装できるなら苦労はない。

292 ：仕様書無しさん：2008/05/24(土) 23:57:20

まぁ、いまやゲームでさえC++やJavaで作られる時代だというのに、
C言語が求められるほどの適用分野は限られるわけだが。

293 ：仕様書無しさん：2008/05/24(土) 23:58:34

なんか今カキコした時、書き込み中にへんなの出た。なんだこれ。

294 ：仕様書無しさん：2008/05/25(日) 00:00:16

そこまで速度を気にするアプリでもないのに
キチガイみたいにC++やJavaは遅くて使い物にならんと言う人種も確かに存在する。
そいつらの多くはOOが理解できないから「速度」を理由にして使いたくないだけ。

295 ：仕様書無しさん：2008/05/25(日) 00:14:09

よほどのことが無い限り言語の速度の影響は無い
マシンは年々速くなるし、メモリーが外部記憶もジャブキャブ使えるし

296 ：仕様書無しさん：2008/05/25(日) 00:39:55

>>295
数値計算とかでC++使う気おきんな、C もゴミ
一番コアな部分はフォートランになってしまう
vector/並列マシン系

297 ：仕様書無しさん：2008/05/25(日) 00:43:24

数値計算って...CでもC++でも最近の処理系はインラインアセンブラが使えるっしょ。
浮動小数点演算も大丈夫っしょ。

298 ：仕様書無しさん：2008/05/25(日) 00:44:54

>>297
粒度の細かい並列度あがんないじゃない
インラインとか使いたくねえし

299 ：仕様書無しさん：2008/05/25(日) 00:49:42

それは単に使ってるコンパイラの質の問題では？

300 ：仕様書無しさん：2008/05/25(日) 00:51:16

くせだろ、くせ（笑）

301 ：仕様書無しさん：2008/05/25(日) 00:51:55

言語仕様の問題
フォートランはvector/並列計算用のシンタックスがある

302 ：仕様書無しさん：2008/05/25(日) 00:59:01

スレチってるぞ

303 ：仕様書無しさん：2008/05/25(日) 01:03:05

それは実行速度の問題じゃなくて単にコードの書き易さの問題では？

304 ：仕様書無しさん：2008/05/25(日) 01:48:30

>>295
あるよん。おじゃばがJavaの速度影響は今更ないよとかっていって、
配列にデータ入れるプログラム試しに組んでみたら確かに早かったけど、
実地にあうデータ。つまり数値をランダムにしてみたら、Cの方が圧倒的に早かった。

特定の場合はJavaは早いけど全般的に普通に早いのはCと結論付けらた。

まあ、一年ちょっと前の話だけど。

305 ：仕様書無しさん：2008/05/25(日) 02:04:09

だけど、何かの処理のCPUタイムに0.1秒かかってたものが.001秒に
なったとして、大方の人間にはどうでもいいことだな。
大抵はメモリ内の処理よりも、ディスクアクセスや通信やその他の
外部装置へのアクセスの方がボトルネックになるからね。

306 ：仕様書無しさん：2008/05/25(日) 02:21:28

それもどうでもいいだろ
ユーザとしては細かいのを差し置いて全体的にはやけりゃいいんだから
そうなると作り手としては早くできるなら早くしといた方が良い

307 ：仕様書無しさん：2008/05/25(日) 02:33:42

そろそろスレチだが、
コンマ1秒の精度が必要かどうかをまず考えろって話だ。
ユーザとしては0.1秒の処理が0.01秒になっても意味がなかったりするだろ。

308 ：仕様書無しさん：2008/05/25(日) 02:37:44

ユーザと交渉しろということですね　わかります

309 ：仕様書無しさん：2008/05/25(日) 03:41:53

全体的に早くなったとしてもせいぜい10秒が9.8秒になるだけのことです。本当にありg(Ry

310 ：仕様書無しさん：2008/05/25(日) 03:52:13

少しのもたつきでも感じるといらいらする
そしてそのいらいらをもたつきの原因にぶつける

311 ：仕様書無しさん：2008/05/25(日) 04:13:49

まぁ一番もたついてんのは>>310自身なわけだが

312 ：仕様書無しさん：2008/05/25(日) 04:24:56

自分を棚に上げるのは常識だろ
相手が人間じゃないだけ良心的と思ってもらいたい

313 ：仕様書無しさん：2008/05/25(日) 18:24:09

Java の利点は生産性の高さに尽きる。パフォーマンスなどの品質が重要なら
間違いなく C/C++ だ。で、目的に応じていづれかの言語を使うというスタンス
で良いと思う。

ただ、技術者の中に特定の言語に固執する奴が多すぎる。
顧客の要求を聞いてから言語を選定すればいいだけのことじゃないのか？

Java は間違いなく遅いんだけど、開発効率は高いし別に悪い言語じゃない。
ただ、遅いという事実をごまかして、顧客に不利益を与えることは、プロ
としてどうかと思うぞ。

実際に、組み込み系で 1/100 sec レベルで精度が問われれば、Javaは
即却下だし、DTP系のフロントエンドで、マルチプラットフォームで動作
することが前提で、納期を短縮したかったら Java とかそーいった選択を
過去にしたことあるけど。そーいうもんじゃないのか？

314 ：仕様書無しさん：2008/05/25(日) 18:45:03

>>313
言ってることは正しいと思うが
オブジェクト指向がが普及しない理由ではないように思う。

オブジェクト指向がはやらない理由としては

１．末端エンジニアの不勉強
　UML,デザインパターン、覚えることが多すぎる。
　現場レベルでこれらを使いこなせてるエンジニアをいまだ見たことない。

２．オブジェクト指向を使う（に値する）場が少ない。
　本来、OS,DB,各種サーバーソフトウェアなどの大規模ソフトウェア開発においてオブジェクト指向が使われるべきだと思うが、結局使われるのはC言語。
　各会社の個別の業務管理システム程度なら関数指向で作れちゃうしな。。。

だとおもうがどうだろう？　

315 ：仕様書無しさん：2008/05/25(日) 18:45:11

>>313
正論だが、選定には顧客の思惑、社の意向等
いろいろ政治的な話がからんでくるから、みんな苦労してるんだわ

javaが流行ってるから、なんでもかんでもjava
EJB2.0で失敗したから、EJB3.0もダメだとか言い出すしな
RoR提案したら、顧客に知ってるやつがいないって事で
プレゼンする前に却下されたり

316 ：仕様書無しさん：2008/05/25(日) 18:50:55

>>314
確かに使える場所が限定されるから、使用する絶対人数が少なくなるわ
１つのプロジェクトでも使う必要がある部分は、ビジネスロジックや共通処理(例外・認証)を管理するFWだけで
下っ端PGはインターフェースに合わせてBLを組めば、OOを意識する必要は無い

FWを作るような人達は、少数精鋭でFWを作り終えたら
他のプロジェクトに引っ張りだされるからOOに携わる人数は当然少ない

317 ：仕様書無しさん：2008/05/25(日) 18:58:15

末端エンジニアもそうだが、
「Java/C++＝オブジェクト指向」
と思いこむIT関係者が多すぎることも問題

偽装請負が大半を占める中で、
技術者が特化した技術で食えることは稀で、
プロジェクトが変わるたびに似たような関数を書かされてる

火消しやコーディングのスタートに慣れてる奴は結構いると思うけど、
設計の専任がいるようでいないこの業界では、
分析～設計～製造というOOの利点を生かせてないのが現状だろうね

318 ：仕様書無しさん：2008/05/25(日) 19:12:33

>>314,316
じつはそれは構造化の段階ですでにそうだ。いまCOBOLerと呼ばれてるお年寄りたちは
あんたたちがBLだのFWだの妙な略語(笑)を使うまでもなく、十把一絡げに入って
技術はともかく業務知識をやってシステムエンジニアとやらになれ、単価あがるから。
と騙されてきた連中だよ。OOがはびこってその辺がはっきりしていいことだろな。
Javaでビジネスロジックだけ書けばいいんだから。

となればいいものを、実際はせんずりみたいに中途半端な自前フレームワークにあわせせるために
末端のドカタが徹夜なんかしてるのが、あいかわらずなんだろ。

319 ：仕様書無しさん：2008/05/25(日) 19:15:04

>318
読みにくいなあ

320 ：仕様書無しさん：2008/05/25(日) 19:17:55

>>318
えっと。。日本語で簡潔に

321 ：仕様書無しさん：2008/05/25(日) 19:21:50

ん、読みにくいだろ？要するに
おじゃばでもないのにクソスレageんな馬鹿野郎。
っつこった。

322 ：仕様書無しさん：2008/05/25(日) 19:25:10

>321
それは>314のおじゃばに言ってるんだよな？

323 ：仕様書無しさん：2008/05/25(日) 19:26:45

>>318
>自分自身文章力が無いのは自覚しているが

まで読んだ

324 ：仕様書無しさん：2008/05/25(日) 19:29:13

>>323
ん、ちゃんと読んでるじゃん。いつものまで読んだは面白いね。

325 ：仕様書無しさん：2008/05/25(日) 20:13:55

どうでもいっけど「抽象化でやる」ってことばが何となくモヤモヤします。

326 ：仕様書無しさん：2008/05/25(日) 20:46:01

言葉は気にしなくてもオッケ
コンポーネントが理解できれば自然にインターフェースとクラスが理解できるから

327 ：313：2008/05/25(日) 20:50:32

>>314
> 1. 末端エンジニアの不勉強
8年程前に社内にUMLやデザパタを広めるために会社の命令で活動した。
その時に感じたのが、保守派の存在。社内でもそこそこ出来るやつほど
反対する傾向があった。原因は、「プライド」。技術者って頑固なんよね。
ある程度の年齢になると、若いやつに負けそうな分野に突入するの
億劫になるみたいだ。

>2. オブジェクト指向を使う（に値する）場が少ない。
言えてる。オブジェクト指向じゃないとできない仕事って無いもんな。
1.ともからむが、C言語からしっかり勉強した奴の方がスキル高いことが多い。
オブジェクト指向言語って本当にできるやつ少ない。良い人材を集めるのに
苦労する。似非グルが多いのもオブジェクト指向言語の特徴だし。

328 ：仕様書無しさん：2008/05/25(日) 20:55:50

インターフェースで思い出したけど、むかし百式のプラモデルつくってるときに、肩のパーツの棒が短くて胴体とつながらないことがあってショックだった。
当時小学生低学年かな...。ちゃんと説明書どおりに作ったハズなんだが…。あれおじゃばが設計したの？

329 ：313：2008/05/25(日) 21:01:11

オブジェクト指向を導入するのには、開発スタイルそのものを変えないと
成功しないというのもあるとおもう。ウォーターフォール型だと失敗する
確率高い。開発初期から設計をばっちりにするには、要求分析をしつこく
やる必要があるが、普通、要求はいつまでたっても変化する。

オブジェクト指向の場合の設計変更は、構造化の時よりもしんどいしね。
抽象化は、設計が成功したときだけメリットがあるしね。

330 ：仕様書無しさん：2008/05/25(日) 21:02:58

>327
会社はメーカーだよね？
８年前ってのはまた先行性が高いね
Javaが完全に浸透してるとは言えない時だし

331 ：327：2008/05/25(日) 21:09:13

ご察しの通りメーカーで、数百人程のソフトの部署がある。
当時UMLは早すぎたのかもしれない。Ver 1.3 すらまだ出てなかった。

Rational がまだIBM に買収される前に Rose をいっぱい購入して
オブジェクト指向に取り組んだが・・・。
Rose にバグが多すぎで、「オブジェクト指向を使ってもRose程度のソフト
しか作れない。」と馬鹿にされたものだった。

まぁ、俺的には、かなり早い時期にUMLが勉強できてラッキーだったけどね。

332 ：仕様書無しさん：2008/05/25(日) 21:34:12

UMLが分かる技術者がいるメーカーってどんぐらいあるんやろ
このスレもコンポーネントやアクティビティの話題を持ち出して、
まともなこと言ってる人がたまにいるけど、
ま～、進展が無いスレだわ

333 ：仕様書無しさん：2008/05/25(日) 21:51:39

>>332
に聞くが、UMLって開発の現場で本当に役に立ってるか？
UMLってメンテナンス大変じゃん。

334 ：仕様書無しさん：2008/05/25(日) 22:10:10

開発のというか仕事の現場では全然見ないね
メンテが大変っていうより、メンテできる人がいない
納期で書く時間が無いとかってのも現実問題としてある

でも、
仕事外でスキル高い人が集まってるところでやってるのはUML必須だよ
ホワイトボードとmimio使ってるからUMLが無いと話ができないって理由からだけどね
できないというか細かい話をするときはUMLがラク
それはそれぞれやりやすい方法があるんじゃない？
うちはプロジェクターでUML映して、って感じ

335 ：仕様書無しさん：2008/05/25(日) 22:53:33

うちだと海外の人とやり取りするときに、UMLは共通言語として大活躍だな。

336 ：仕様書無しさん：2008/05/25(日) 22:56:10

いくら日曜にそれなり意味あるレスがついても月曜で全てが破壊される

337 ：仕様書無しさん：2008/05/25(日) 22:59:43

>>335
シリコンバレーのとある会社と共同開発やったことあるが、日本側は
UML使ってたがアメリカ側は使った事がないみたいだった。
かなり意外だったのを覚えている。UMLって世界的に見ても普及していると
思っていたんだがそうじゃないみたい。

338 ：仕様書無しさん：2008/05/25(日) 23:13:26

OOは「考え方」だし、UMLはその表現方法でしかないし
海外の人と接する機会は今までないから日本と同じかどうかわからんけど、
使ってるところもあれば、使ってないところもあるってだけでしょ
UML本で翻訳物が多いのを考えるとね

339 ：仕様書無しさん：2008/05/25(日) 23:43:16

>>334
UMLは速記ができるようになって初めて打ち合わせで役に立つようになる。
そうなるまで時間がかかるが、一旦出来るようになると便利だな。
うちは、プロジェクタにJudeの画面を出して議論してるよ。
メンバーにオブジェクト指向を理解しているやつが一人でもいれば、
周りの人間もどんどんスキルアップするしね。教育のツールとしても
役に立つなUMLは。

340 ：仕様書無しさん：2008/05/26(月) 01:43:32

>>338
ググってみた、日本でのUMLの普及率は10%程度で、欧米では70%、
中国は用語の統一の遅れで古いバージョンを使ってるとあった。
シリコンバレーでUMLが使われていないのは、オフショアの問題とかが
あるんだろな。

ただ、UMLの普及が遅れてえいる＝日本は相当遅れているということには
ならないと思う。（異論は多いだろうな・・・）

日本人同士のコミュニケーションってあんまり困らないし。UMLを
使わなくても話が通じる。よーは、欧米ほど必要性がないってこと。

日本語って名詞重視だしもともとオブジェクト指向的じゃん。
たとえば命令形。日本人って「お茶」と言われたら状況判断
（コンテキスト）でお茶が欲しいんだなって類推できるでしょ。
英語だと動詞からスタートだし。

欧米人の下手なオブジェクト指向の解説本をありがたがって、
すげー遠回りして勉強するからだめなのかも。

341 ：仕様書無しさん：2008/05/26(月) 01:46:17

お茶は名詞であって動詞じゃないけどな。

342 ：仕様書無しさん：2008/05/26(月) 01:56:07

まあそう言わずにお茶しよう

343 ：仕様書無しさん：2008/05/26(月) 02:09:07

そんな亊言ってお茶を濁して退散かい。

344 ：仕様書無しさん：2008/05/26(月) 02:42:56

そう茶々をいれんなよ

345 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/26(月) 09:57:20

>>225
だから、構造化で全ての関数にそれをやるのかって事だよ。

>>227
そんな事言ってないぞ。間違いを見つけてネタにするために、たまに立ち読みする程度だ。

>>228
簡単に言えば、fread()はオブジェクトじゃない。内容的にはfopen()、fread()、fclose()がまとまって、
class Files{
public:
　　fopen();
　　fread();
　　fclose();
private:
　　FILE *fp;
};
になればオブジェクトと言える。

346 ：仕様書無しさん：2008/05/26(月) 10:21:32

なんでいつも理解の一歩手前で見事に止まれるのか感心するは…

347 ：仕様書無しさん：2008/05/26(月) 10:29:10

いやいや、待つんだ
きっと書きかけなんだよ

348 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/26(月) 10:29:34

>>236
下はCだ。fgets()は引数修正した後に、fread()に修正忘れた。
書いていて面倒になったし、端的にでいいと言う話なので、エラーや終了処理は外した。
サンプルだから許されるよな？

>>237
レコード1件の検索の処理があって、例えば今まで1秒かかってもよかった処理でも、30秒になったらアウトだ。
もしファイルからソケットに変わったら、使う関数もロジックも修正で、その修正は利用者情報をアクセスする
いたるところに修正となるだろう。その後にキャッシュを組み込むとなれば、ロジック修正がいたるところに
入るだろう。修正する内容はあまり変わらなくても、構造化の場合は修正する場所が散らばっている。

>>238
Cの構造化に合わせるために、抽象レベルを合わせた。
また、Userクラスでなく、Usersしていると言えば238なら意味は分かるだろう。

349 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/26(月) 10:50:20

>>244-261
Cの例に合わせているのだから、258の例になるだろう？
で、効果は分かったのかな？あれでもファイルからソケットに変わっても修正の手間は変わらないと言うなら、
実際にやってみろと言うしかないな。業務経験のある人ならよく分かると思うが。

350 ：仕様書無しさん：2008/05/26(月) 12:06:30

↑仕事ないの？

351 ：仕様書無しさん：2008/05/26(月) 12:22:20

お前アホか
お前が上司ならこんなバカに仕事を振りたいと思うか？
わかりきったことを聞くんじゃねーよ

352 ：仕様書無しさん：2008/05/26(月) 13:12:25

>>350
一応、あるんでない？設計はやってないと思うが。

353 ：仕様書無しさん：2008/05/26(月) 13:13:31

>>349
本当に教えたいと思う気持ちがあるのなら、黙っていろ
お前がレベルを下げまくっているんだよ

354 ：仕様書無しさん：2008/05/26(月) 19:46:11

>>349
>>219は例が悪すぎる。
上と下が同じ目的を持つように作ってくれ。

355 ：仕様書無しさん：2008/05/26(月) 20:30:44

結論

　Q：何故普及しないのか？

　A：必要ないから

356 ：仕様書無しさん：2008/05/26(月) 21:48:16

で、おじゃば。>223はどうした？

357 ：仕様書無しさん：2008/05/26(月) 21:53:27

>>356
抽象化だけで語るなよ。問題の局所化、カプセル化がポイントだろ。

358 ：仕様書無しさん：2008/05/26(月) 23:35:23

>349
ならねぇよ低能

359 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/26(月) 23:47:49

>>328
多分、説明書を間違えて読んだのだろう。

>>353
レベルの高い話って何？
O/Rマッピングの話や、UMLの話ではないよな？

>>354
同じ目的だが。

>>356
機能の抽象化だけでは、オブジェクトの抽象化にならないんだよ。345は読んだか？

360 ：238：2008/05/26(月) 23:48:36

>>348
たぶん、根本的なところが理解できないんだと思う。
Users に、getRecord があることに違和感が無いのはちょっとやばいかも。
あと、>>345 の Files が複数形なのも意味不明だし。

とりあえず、自分の間違いに気がつくことだと思う。そうじゃないと
いつまでもグルグル同じところを回ってしまうことになる。

361 ：仕様書無しさん：2008/05/26(月) 23:48:52

>>348
/*
FILE *fp = fopen("user.dat", "rb");
for(; ;){
　　fgets(rec, sizeof(rec), 1, fp);
}*/

何ですかこれ？
fgets()はfread()の間違いと気付いているようだが、
無限ループに気付かないとは、いやはや・・・

362 ：仕様書無しさん：2008/05/26(月) 23:55:08

>>361
いや、パディングの問題があるから構造体にfread()で読み込んでも間違い
には変わりない。recがクラスならもっと最悪。
なんて言うか、どう考えても、このソース書いた人プロとは思えない。

363 ：仕様書無しさん：2008/05/26(月) 23:59:35

残業中ですね、わかります。

364 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/27(火) 00:03:23

UMLについて色々語っている人がいるようだが、
UMLが発生した訳と、失敗した訳と、今の状態に落ち着いた訳を知っている人はいるか？

365 ：仕様書無しさん：2008/05/27(火) 00:09:28

>>364
自分で調べてください。簡単に検索で引っ掛かります。

366 ：仕様書無しさん：2008/05/27(火) 00:14:22

UML失敗しとらんがな、使ってるところ（勝ち組）と使えてないところ（負け組）の
格差が広がっただけ。

367 ：仕様書無しさん：2008/05/27(火) 00:18:16

書籍の受け売りが好きな奴がいるな。
オブジェクト指向の書籍は嘘や間違いから注意な。

オブジェクト指向は、黎明期に「過去の技術の否定」と「誇大広告」を
やりすぎて、結果、口ほどでもなかったから１０年以上冷飯食ったという
悲しい過去があるのは知ってるだろ。

368 ：仕様書無しさん：2008/05/27(火) 00:20:08

>>366
俺もそう思う。過去に乱立した表記法からすれば、UMLは勝ち組だな。
知ったかぶりをする奴はスルーでOK。

369 ：仕様書無しさん：2008/05/27(火) 00:41:18

>>348
＞その後にキャッシュを組み込むとなれば、ロジック修正がいたるところに
＞入るだろう。修正する内容はあまり変わらなくても、構造化の場合は修正する場所が散らばっている。

そんなコードは構造化されてるとは言えない。
同様のコードは集約されてしかるべき。
その程度の変更で修正点が増えるようなコードは機能分割に失敗してる。

370 ：仕様書無しさん：2008/05/27(火) 05:17:31

おじゃばへ。
構造化とOOの違いはもういいから、
構造化されているコードとそうでないコードを示してくれ。
このままだとお前が構造化を理解しているのかがあやしい。
ただしgotoは使わない方がいいぞ。
gotoレスが構造化だなんてバカはいねーよさすがにこの板には。

371 ：仕様書無しさん：2008/05/27(火) 07:19:30

>>370
おじゃばへ
それができたら次は、構造化してないオブジェクト指向のコードも書いてみれ。

372 ：仕様書無しさん：2008/05/27(火) 07:28:49

おじゃばへ。
さらに、問題。
「利用者情報の読み出し」ではなくて、「デバッグ用のログを保存する」
場合を考える。将来ログを保存するデバイスが変更される前提なら、
どういう設計にしとけば修正を最小限に収めることができるか考察すること。

373 ：仕様書無しさん：2008/05/27(火) 08:50:08

おじゃばはLinuxもAOPもOOPも知ったかぶり
コーダーとしても三流、いや、それ以下か
業務経験以前の問題だ

#おじゃばなら窓際族になっても気にしないんだろうな
#持ち前のプラス思考でｗ

374 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/27(火) 09:37:39

>>360,361,362
論点が違う。

>>366
簡単なクラス図を作るのに、UMLハカセはユースケース図作れとか、コンポーネント図作れとか言っていたが、
何でそんなに手間がかかるのか疑問に思ったことはないか？
それに、システムが分かりやすい図に出来るなら、その図から実行ファイルを作る事が出来れば、
プログラミング言語なんかいらないのではないかと思うが、なぜ出来なかったのか疑問に思ったことはないか？

>>369
では、ファイルからレコードを取得する処理がありました。
fopen()を使いますか？fopen()をラップした関数を使いますか？

375 ：仕様書無しさん：2008/05/27(火) 09:38:52

コイツはナニを言ってるんだ・・・？
アホじゃね

376 ：仕様書無しさん：2008/05/27(火) 10:20:48

想像以上に頭悪いな
これじゃ、会話ができないわけだぜ
きっとおじゃばの正体は外道スライム
おじゃばさまはすでにキチ○イの領域におわす存在

377 ：仕様書無しさん：2008/05/27(火) 10:43:07

これだけ長いこと議論していて、なぜ間違いを認めないのか。レスが分散しているからわかりにくいのか。
関係ないことを書いたら負けというルールで、1対1で議論するか？

378 ：仕様書無しさん：2008/05/27(火) 11:04:40

間違いを認められないんじゃないか
高次機能障害とか強迫性障害とかで
それか、ここで書き込みするのが心の拠り所だったり…とか

379 ：仕様書無しさん：2008/05/27(火) 14:06:12

>>374
2ch で遊んでないで、まともな仕事してみろよwwwWw

380 ：仕様書無しさん：2008/05/27(火) 16:10:31

俺なんかUML使ってるからどこに海外旅行行っても不自由しないよ

381 ：仕様書無しさん：2008/05/27(火) 18:31:45

オブジェクト指向が普及しない理由って、
欠点の多い言語ばかりだからじゃないの？

概念を上手く実現できてないからでしょ。
概念そのものにも少し不足があるかもしれないけど。

382 ：仕様書無しさん：2008/05/27(火) 20:11:56

>>374
>簡単なクラス図を作るのに、UMLハカセはユースケース図作れとか、コンポーネント図作れとか言っていたが、
>何でそんなに手間がかかるのか疑問に思ったことはないか？
おじゃば、駄目だぞ博士の悪口言っちゃ、同じレベルになるぞ
博士は実践が出来ないから、教科書どうりの事しか言わん
博士以外で、簡単なクラス図を作るのにユースケース図を書く奴おらんから、心配するな

383 ：仕様書無しさん：2008/05/27(火) 20:33:14

>382
あんまり嘘教えるなよｗ

384 ：仕様書無しさん：2008/05/27(火) 20:38:46

「どうり」ね　うん　「どうり」ね

385 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/27(火) 20:42:28

>>370
名無しは質問者と解説者が違うせいか、論点がズレたりするんだよな。
370は構造化設計の話なのか構造化プログラミングの話なのか良く分からないし、
371の質問は意味不明だし、
372の質問のログは問題となる観点が多数含まれた内容だが、それとは全然関係ない観点で見ているようだ。
だから370がコード書いて説明してくれ。

>>377
いいぞ、議論しようか。つーか377は誰だ？何を主張している人かも分からない。
オブジェクト指向の利点についてでいいかな？

>>382
でもハカセの言う事を真に受けて、UMLの本を見て使わない図を暗記するのに全力を尽くす人がいるだろ？
UMLの本当の使い道が営業トークである事を、言っておくべきではないか？

386 ：仕様書無しさん：2008/05/27(火) 20:48:05

は？

387 ：仕様書無しさん：2008/05/27(火) 20:53:26

Q.名無し(370)
構造化とOOの違いはもういいから、構造化されているコードとそうでないコードを示してくれ

A.おじゃば
370は構造化設計の話なのか構造化プログラミングの話なのか良く分からない

オブジェクト指向の前に日本語を勉強しろよ

388 ：仕様書無しさん：2008/05/27(火) 21:08:35

>>383,384
ハカセ、何で必死なの？

389 ：仕様書無しさん：2008/05/27(火) 21:10:51

>385
> でもハカセの言う事を真に受けて、UMLの本を見て使わない図を暗記するのに全力を尽くす人がいるだろ？
> UMLの本当の使い道が営業トークである事を、言っておくべきではないか？

UMLの知識が無いことを棚に上げて八つ当たりか
自分自身の無知を自らバカにしてるようなもんだ

お前が使えないだけだろ
無知なら無知でいいじゃねーか
「知りません」「分かりません」とだけ言えばいいんだ

知らないことは恥ではないが、
お前のように知らないことの裏返しで情けない発言をするのは人間として最低だ

390 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/27(火) 21:12:07

>>387
話の流れは構造化設計の話だが、gotoがどうのと言うのは、構造化プログラミングの話だろう？
構造化設計されてない例。
main(){
　　この中に全て書く。
}

構造化プログラミングされていない例。
int func(){
　　FILE *fp = fopen("hoge.dat", "rb");
　　if(fp = NULL){
　　　　return 1;
　　}
　　char buff[100];
　　int sts = fread(buff, sizrof(buff), 1, fp);
　　if(sts < 1){
　　　　return 1;
　　}
　　return 0;
}

391 ：仕様書無しさん：2008/05/27(火) 21:16:57

結局、おじゃばにとってはOO（と自分で思う）もの以外はなにもかも構造化なんだろうな。
頼れるのがI社の業務経験とやらじゃ、しかたないけど。
よほどI社で設計が年寄りになるまでできなくてクビにでもなったんじゃね。

392 ：仕様書無しさん：2008/05/27(火) 21:18:48

>>390
>sizrof
ちったぁ自分が書いたもの見てからにしろよ、いくらアツくなってても。

393 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/27(火) 21:21:38

>>389
もしUMLが本当に成功していたなら、どんなシステムも分かりやすい図表で表す事が出来る。
その図表が本当に正しければ、それから実行ファイルやソースコードに変換出来ても不思議ではないよな？
もしそれが可能なら、プログラミング言語なんか不要になる訳だ。
「UMLさえ出来れば、プログラミング言語の知識など必要ない。好きな言語に変換すればいい。」
そう考えても不思議ではないよな？で実際にそう言うプロジェクトはあった訳だ。
有名な話だが、知らないのか？

394 ：仕様書無しさん：2008/05/27(火) 21:23:00

>>390
で、それが構造化されると？

395 ：仕様書無しさん：2008/05/27(火) 21:31:20

>>393
お前がコーダに誇りがあるのはよくわかった。
たしかに仕様記述から実際動くコードを出そうとして失敗した例は枚挙にいとまがないくらいだ。
ただ、だからといって仕様記述そのものが必要がないということにも、いまだかってなってはいない。
そうなるには、幼稚園からJava、小学校からCを教えて中学校でx86をやらんとな。
もっとも、ずーっとやっても日本語ができないお前みたいなのがいるのはしかたないけど。

396 ：仕様書無しさん：2008/05/27(火) 21:34:22

>>393
そんなにハカセを、いじめなくても
ハカセは、実践を知らないんだから
あと、ハカセ
>>394 は、何が言いたいの？

397 ：仕様書無しさん：2008/05/27(火) 21:35:23

命題：
>お得意のコーディングレベルでいいんじゃないかな。

答え：
>FILE *fp = fopen("user.dat", "rb");
>for(; ;){
>　　fgets(rec, sizeof(rec), 1, fp);
>}

俺的疑問：
無限ループです。for(; ;)の中に、breakなりreturnなりgotoなりで抜け出す処理いれないといけないわけだけど。

スレ代表返答：
360
>いつまでもグルグル同じところを回ってしまうことになる。

おじゃばの返答：
>>360,361,362
論点が違う。

俺の質問：
で、どこを論点にすればいいのかおじゃば教えてくれ。

398 ：仕様書無しさん：2008/05/27(火) 21:37:25

>393
本当に情けない奴だ

399 ：仕様書無しさん：2008/05/27(火) 21:37:44

>>390
先生、それどこからのコピペですか？？
変数名は変えてあるようですけど

下っ端コーダーすらできないおじゃば先生には禁句ですかな？？

400 ：仕様書無しさん：2008/05/27(火) 21:38:25

>396
おじゃばつまらん

401 ：仕様書無しさん：2008/05/27(火) 21:39:38

>>396
ん？俺ハカセなの？そりゃ光栄だな、おじゃばw
構造化とそうでないのを、っつ話じゃなかったっけ？

402 ：仕様書無しさん：2008/05/27(火) 21:44:54

>389がおじゃばの真理を突きすぎてて噴いたｗ

403 ：仕様書無しさん：2008/05/27(火) 21:47:35

構造化定理
1つの入り口と1つの出口を持つようなプログラムは、「順次・反復・分岐」の3つの基本的な論理構造によって記述できる

なので、390は構造化定理を満たしています。

どこが、満たしていないのか教えてくれない？

404 ：仕様書無しさん：2008/05/27(火) 21:50:38

おじゃばがOO側のコードでORMのひとに援護してもらってもなんにも言わなかったのは
O/Rマッパーがなんのことだか全然わからないせいなんだろうなぁ。
かわいそうだな、ORMのひと。

405 ：仕様書無しさん：2008/05/27(火) 22:19:31

>>390
その例がなぜ構造化されていなくて、構造化するとどうなるのかもぜひ教えていただきたい。

406 ：仕様書無しさん：2008/05/27(火) 22:20:17

>>403
1つの出口って、どれハカセ？

407 ：仕様書無しさん：2008/05/27(火) 22:25:45

いまどき、Cで、
　　if(fp = NULL){
なんてお決まりの間違いを犯す奴、久しぶりにみた。
目の錯覚かと思ったよw

408 ：仕様書無しさん：2008/05/27(火) 22:29:45

>>407
好意的に解釈するんだ
VBAの構文が混じってしまったのだと
………スマソやっぱ無理ｗｗｗｗ

409 ：仕様書無しさん：2008/05/27(火) 22:40:54

クローズもしてないし、こういうコード書く奴がそれと気づかず平気で
リソースリークを撒き散らかしてんだろうな。まさに悪い見本の典型だな。

410 ：仕様書無しさん：2008/05/27(火) 22:45:11

>>407
それは初心者が良くやる間違いだから、ココでやってしまっても不思議じゃないな。

411 ：仕様書無しさん：2008/05/27(火) 22:46:00

>>393
おじゃばって、詳細設計書に関数1つ1つの処理フローまで事細かに書くタイプの人？

俺は実装レベルと等価な設計書を書くなんてナンセンスだと思う方だし、
UMLは設計段階で使うだけだから、そこまで細かい表現能力はUMLには求めてない。

単にクラス図にせよシーケンス図にせよ「おれおれルール」で描かれてるより、
標準化されてるルールに基づいてる方が読み易い、読ませ易いから使ってるだけ。

オブジェクト指向設計の設計書で「クラス図が要らない」とか「アクティビティ図が要らない」とか
言うのであれば、それはUMLが成功したかどうかとは、また別問題だな。

412 ：仕様書無しさん：2008/05/27(火) 22:46:57

サンプルコードだし、
typo、コンパイルエラーは大目に見ようや。

とりあえずおじゃばさまは>>405に早く答えてくれ。

413 ：仕様書無しさん：2008/05/27(火) 22:48:19

つぅか、この関数は一体何をしようとしてるんだ？　
「構造化プログラミングされていない」以前の問題じゃね？
サンプルとしてあまりにもひどすぎる。無能の証でしかない。

414 ：仕様書無しさん：2008/05/27(火) 22:50:22

>>409
明示的にクローズしなくても自動的にクローズされる。
or
説明上必要ないので省略した。

と主張すると予想。

415 ：仕様書無しさん：2008/05/27(火) 23:01:29

>>403
だからハカセ、1つの出口って、どれ？
ごまかさないで、教えてくれよ

416 ：仕様書無しさん：2008/05/27(火) 23:05:09

>>414 関数からリターンするだけじゃクローズはされんだろ？
この関数が何千回も呼ばれてるうちに、ファイルが開けなくなるわな。

417 ：仕様書無しさん：2008/05/27(火) 23:07:43

>>415
肛門

418 ：仕様書無しさん：2008/05/27(火) 23:09:39

ま～どうせ１ファンクション中にreturnがたくさんあるから構造化されてないとか言い出すんだろ？

419 ：仕様書無しさん：2008/05/27(火) 23:12:28

おじゃばのせいで構造化の話が終わらない
おじゃばが議論したり、教えたりしようとするほど
OOから遠ざかっていく
おじゃばはスレストッパーというより、どこまでも壊していくスレクラッシャー

420 ：仕様書無しさん：2008/05/27(火) 23:14:52

ハカセは、いつも必死だな
いいから、「1つの出口」を早く教えろよ

421 ：仕様書無しさん：2008/05/27(火) 23:19:11

おじゃばの単純な頭では、関数分割すれば構造化。関数とデータをまとめればオブジェクト指向。
こんな低レベルの話を姿の見えない素人相手に延々と繰り返している。そしてこれからも...

422 ：仕様書無しさん：2008/05/27(火) 23:19:55

>>420
ぐぐったら入り口が211,000個もありました＞＜
http://www.google.co.jp/search?hl=ja&q=1%E3%81%A4%E3%81%AE%E5%87%BA%E5%8F%A3&lr=
ことわざの「ちりも山に積もる」ですね！

423 ：仕様書無しさん：2008/05/27(火) 23:23:27

>>420
入口と出口ってインプットとアウトプットだろ。
関数でいうと引数が入口で戻り値がアウトプットじゃね？

y=f(x)

のyが出力、xが入力。つぅか、おまいは素人か？

424 ： ◆ZnBI2EKkq. ：2008/05/27(火) 23:29:23

>>393
UMLが本当に確かに成功したなら、図表で明らかにどんなシステムも見せることができます。
本当にダイヤグラムを正当性に変換できても、それは実行ファイルです、ソースコード、そして、それが変換されます。
缶による神秘的な…がプログラミング言語であるということではありません、もっとも、それが不要になる理由はそれですか?
UMLが不要であり、プログラミング言語の知識などができるだけ不要であるので。それは好きな言語にそれを変換するだけでよいです。
それはそうです。それは神秘的ではありません。 . あなたが局面について考えても。プロジェクトは実際にそれが理由であるように言いました。それは有名な正当な話です。
それはプログラミング言語の知識の不要ななどで好きな言語にそれを変換するだけでよいです。「UMLさえできます。」 "

おじゃばさまはどう思いますか？

425 ：仕様書無しさん：2008/05/27(火) 23:38:54

UMLは万能ツールではなくて、補助ツール。まずそこの認識が誤っている。
どうして、使える○/使えない×、と極端に結論付けようとするんだろう。
便利に使える局面で使えばいいし、分かっている者同士であれば十分に意志
の疎通に利用できる。そして、UMLはUML自体の拡張も許容しているから、
気に入らなかったり、不足してるところはあれば自分で補っていけばいいだけ
のこと。自身の不勉強を棚にあげてツールに過渡の期待をするのはよくない。

426 ：仕様書無しさん：2008/05/27(火) 23:40:50

>>423
いいから、早く「1つの出口」を書けよ

427 ：仕様書無しさん：2008/05/27(火) 23:45:21

バカには説明してもわからんだろ

428 ：仕様書無しさん：2008/05/27(火) 23:46:26

ハカセが、逃げたｗ

429 ：仕様書無しさん：2008/05/27(火) 23:49:18

ハカセは忙しいんだよ、馬鹿の相手をするのはよっぽどヒマで退屈な時だ。
さて、俺も寝るか

430 ：仕様書無しさん：2008/05/28(水) 00:12:49

>422
ttp://www.google.co.jp/search?hl=ja&q=%221%E3%81%A4%E3%81%AE%E5%87%BA%E5%8F%A3%22&lr=

431 ：仕様書無しさん：2008/05/28(水) 00:13:30

>>427
説明してから言えよ、本当に情けない奴だな
int func(){
　　FILE *fp = fopen("hoge.dat", "rb");
　　if(fp = NULL){
　　　　return 1;
　　}
　　char buff[100];
　　int sts = fread(buff, sizrof(buff), 1, fp);
　　if(sts < 1){
　　　　return 1;
　　}
　　return 0;
}
これが、「1つの出口」で出来ているのか？
素人か？　OOも出来ん奴だと思っていたが
構造化も分からん奴だとは、本当に情けない
こいつ見たいに、口だけの人間がいるから
OOが普及しない

432 ：仕様書無しさん：2008/05/28(水) 00:21:41

>>403
もしかして、GOTO文使わない事が
構造化だと思っている？

433 ：仕様書無しさん：2008/05/28(水) 00:26:50

>>403
フローチャートで書けばわかるんじゃないの？

434 ：仕様書無しさん：2008/05/28(水) 00:34:47

>>423
>入口と出口ってインプットとアウトプットだろ。
>関数でいうと引数が入口で戻り値がアウトプットじゃね？
>y=f(x)
>のyが出力、xが入力。つぅか、おまいは素人か？
何？、一つの出口って、その意味じゃないだろうｗ
構造化の一つの出口と言ったら、ロジックが
同じ所で終了すると言う意味だ、お前は素人かｗ

435 ：仕様書無しさん：2008/05/28(水) 00:36:06

ハカセは酷いな

436 ：仕様書無しさん：2008/05/28(水) 00:40:02

>>431 俺はハカセじゃなくて、ただの駆け出しPGだが、
int型の戻り値を一つだけ返しているから、出口も一つだろ。
まさか、return文が複数あるから、おまいには出口も複数に見えたのか？

たとえば、
int func(){
　　int ret;
　　FILE *fp = fopen("hoge.dat", "rb");
　　if(fp != NULL){
　　　　char buff[100];
　　　　int sts = fread(buff, sizrof(buff), 1, fp);
　　　　if(sts < 1){
　　　　　　ret = 1;
　　　　} else {
　　　　　　ret = 0;
　　　　}
　　} else {
　　　　ret = 1;
　　}
　　return ret;
}

って書いてあったらおまいにも出口が一つに見えたのか？
おめでたい奴だな。
アセンブラレベルで見れば、戻り値を１つのレジスタにいれて返してるだけ
だよ。つうか、関数のシグネチャ見ればわかるだろ。

437 ：仕様書無しさん：2008/05/28(水) 00:41:58

>>216

>ほー、ではいいかげん、ユースケース図からクラス図を作ってくれないか？
>レンタルシステムで。ちなみに俺の他にも、出来る訳ないと思っている人
>はいて、どうやるか関心があるみたいだぞ。

ユースケース図（厳密にはユースケース）からクラス図を作る事は
普通にやることです。

ユースケースが発見されればユースケースの記述を行います。
ユースケース記述とは、システムをブラックボックスにした場合の
ユーザとオペレータ間で行われるシナリオです。

次にユースケースの分析・設計を行いす。分析・設計は、ユースケース単位
で行います。「ユースケースの実現」ですね。システムは、ホワイトボックス
として、ユースケース記述を実現するシステム内部の振る舞いや構造を
定義していきます。このとき、クラスを発見しなくてはいけませんが、
機械的にクラスを発見していく手法がいくつか提案されていますので
書籍を読み漁ってください。

ユースケースというのは、単なる楕円だと勘違いする人が多いですが、
実際には、ユースケースという単位（スライス）でシステムをとらえる事は
重要であり、UML設計の成果物はユースケース単位で管理すべきです。
もちろん、クラス図もユースケースから導き出します。

ユースケースからクラス図を導くのは、ソフト技術者の腕の見せ所であり
「変換ツール」の仕事ではありません。

438 ：仕様書無しさん：2008/05/28(水) 00:42:21

ユースケースは、確かにオブジェクト指向的ではありません。
ユースケースは、ずいぶん長い間UMLから仲間はずれでした。しかしながら
数多くの学者・技術者がユースケースの威力に気が付きUMLに加えたのです。

オブジェクト指向は、オブジェクト指向だけで成り立っているわけでは
ありません。ユースケースのような構造化手法がなければオブジェクト指向
が成立しないのです。

主に構造化的な手法が役に立つのは、「システムやサブシステムを
ブラックボックスとして考えたとき。」です。ブラックボックス化を
してしまうと、オブジェクトはただ一つ「ブラックボックス」になってる
オブジェクトのみです。この状態で、システムを分析する、すなわち
カプセル化された状態で、システムとのやり取りを記述するには、
構造化手法が有効です。

オブジェクト指向は、システムをサブシステムやクラスに分解することで
問題を解決するのですが、ブラックボックス化して問題を解く場合は、
これができません。たとえば、インターフェースを洗い出す時などです。

439 ：仕様書無しさん：2008/05/28(水) 00:43:19

コンパイルされたソースで構造化を語る奴って、只の意固地だろ。

440 ：仕様書無しさん：2008/05/28(水) 00:47:47

>>436
確かに、書いている内容は駆け出しっぽいな。
>>434
が正しい。

441 ：仕様書無しさん：2008/05/28(水) 00:48:46

>>436
レジスタを使うかどうかは処理系とコンパイル依存。気にしても無駄。

442 ：403：2008/05/28(水) 00:49:41

>>406
ほい勉強しな。

http://www.ailight.jp/blog/kazuk/archive/2005/03/11/4920.aspx

それに漏れはハカセじゃなくて修士なんだ。
情報理論じゃなくて脳科学なんだが。

443 ：仕様書無しさん：2008/05/28(水) 00:51:31

ロジック的にみても「関数は最後に戻り値を返す」という共通の出口が
一つだけだろ。返す値は異なっても出口は一つだ。
だから、>>436が正しいな。ソースを見ずとも概念を考えればわかること。

444 ：仕様書無しさん：2008/05/28(水) 00:53:36

そんな亊言ってるから奇妙なBUGを作り込むんだぞw

445 ：仕様書無しさん：2008/05/28(水) 00:57:38

しょうがない、馬鹿にもわかるようにわかりやすく説明してやるか、
自動販売機は複数のお金の投入口とジュースの選択ボタンがあり、
そしてジュースの出口が一つだ。どんなジュースがでてくるかわ
選択によってかわる。中のしくみはブラックボックス。わかった？

446 ：仕様書無しさん：2008/05/28(水) 01:03:50

>>441 まぁこの場合はintの戻り値だから、レジスタが使われる可能性大だけどな。

447 ：仕様書無しさん：2008/05/28(水) 01:07:11

>>443
やっぱ駆け出しだな。y=f(x)を見て出口が一つと言い切れる奴は
プロにはいない。

ヒント：例外処理

448 ：仕様書無しさん：2008/05/28(水) 01:09:40

必死だなw

449 ：仕様書無しさん：2008/05/28(水) 01:16:28

>>448
納得したようだな。

450 ：448：2008/05/28(水) 01:28:50

答え：
「1つの入り口と1つの出口を持つようなプログラムは、「順次・反復・分岐」
の3つの基本的な論理構造によって記述できる。」

つまり、「順次・反復・分岐」ではないもの（goto, return, break,
continue 例外処理）でフローを制御するのは好ましくないよ。
という、ダイクストラの主張のことを >>434 は言っている。
と俺は思う。

451 ：仕様書無しさん：2008/05/28(水) 03:08:14

オブジェクト指向は、黎明期に「過去の技術の否定」と「誇大広告」を
やりすぎて、結果、口ほどでもなかったから１０年以上冷飯食ったわけで

452 ：仕様書無しさん：2008/05/28(水) 03:16:34

プログラムは三つの基本的な考え「順次・反復・分岐」から成る。
と、いうなら「うん」とうなずくが。それを構造化とか言い出すと宇宙が爆発するぞ。

453 ：仕様書無しさん：2008/05/28(水) 07:21:17

おじゃばのせいで、どこまでも話が脱線していく

　　　　　　　　　　　　　　　　　　　　　「宇宙の法則が乱れる！」

　┝━━━━━━┿━━━━━┿━━━━┿━━━━━━┿━━━━━┿━━━━┿━━
OO　　　　　　　構造化　　　　　 UML　プログラムの基本構造　？　　　　　　　？　　　　　　？

　　　　　　　　　　　 ∩＿＿＿∩　　　　　/)
　　　　　　　　　　　 | ノ　　　　　ヽ　　　 ( i )))
　　　　　　　　　　　/　　●　　　● | 　/　/
　　　　　　　　　　 |　　　　( _●_)　 | ﾉ　/ いまここクマー
　　　　　　　　　　彡､　　　|∪|　　　　,/　　
　　　　　　　　　／　　　　ヽノ　　　/´

454 ：仕様書無しさん：2008/05/28(水) 07:25:05

>>452
「順次・反復・分岐」と「不偏契約を満たすサブルーチン」で構造化。

455 ：仕様書無しさん：2008/05/28(水) 07:27:57

>>451
Java もアプレットを「誇大広告」したがパフォーマンス、セキュリティ
動作環境の不備などの問題点が多く、叩かれ、瀕死の重傷を負っていた
時代があった。

456 ：仕様書無しさん：2008/05/28(水) 07:32:26

>>453
おじゃばの相手をするのはやめにしないか？
おじゃばは、ソースコードをさらした時点で
「分かった気になってる入門者レベル」だという事はもう分かっただろ。

恥ずかしげもなく糞コードさらせるなんてのは、自分のレベルの低さにすら
気が付いていない厚顔無恥さがないと為し得ない技だ。

まぁ、俺も駆け出しのころは、分かった気になって調子に乗ってた時代が
無いわけでもない。おじゃばもあと１００年勉強したら構造化くらいは
分かるようになるだろう。

457 ：仕様書無しさん：2008/05/28(水) 07:39:40

おじゃばのオブジェクト指向に対する熱意は買うんだけど、
取り組む姿勢がねじ曲がってるからいつまでたっても成長しない。
「自己顕示欲」を捨てるところからスタートしないとダメみたい。
そして、技術は、知ってるだけでは使えない。身につけないとね。

ペーパードライバーがレーサーに勝負を挑んでるようにしか見えない。

458 ：仕様書無しさん：2008/05/28(水) 07:57:34

>>454ちょっとわかりにくかった。すまん。
×構造化「する」
○それを「さして」構造化

459 ：仕様書無しさん：2008/05/28(水) 07:59:42

>>450
C言語で return を多用すると、関数の出口がたくさんになる。

使う側からしたら、例外処理などは除くと関数の出口は常に一つだが、
関数の実装側からすると出口が複数になる。

goto, return, break, continue は
「1つの入り口と1つの出口を持つ」
を崩してしまうから多用しないようにしようね。ということだ。

460 ：仕様書無しさん：2008/05/28(水) 08:09:19

構造化の問題点は、プログラムの制御しか問題の対象にしていないこと。
複雑なデータ、巨大なデータを扱う場合の解決策を何も出せていない。

でオブジェクト指向が登場した。ただ、プログラムの制御
（オブジェクトの振る舞い）の部分は、構造化の考えが使われている。

「オブジェクト指向 vs 構造化」ではなく
「オブジェクト指向(構造化を含む） vs 構造化のみ」
という図式になる。

規模の小さなプログラムでは構造化のみで十分。
ただ、書籍などのサンプルソースは小規模なのでいまいちオブジェクト指向
の利点がわからない。これも、オブジェクト指向が普及しない理由かもね。

461 ：仕様書無しさん：2008/05/28(水) 08:34:07

ジェネリックは便利だけどね
データ型がオブジェクトで管理することで
配列サイズを気にしなくなり、メモリ確保の手間がなくなった

ジェネリックのお求めは薬局・薬店で

462 ：仕様書無しさん：2008/05/28(水) 08:45:56

>>460
むしろ構造化部分を含んだ領域をその都度newするコストが無駄じゃね？
位にしか見えない。

463 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/28(水) 09:33:58

>>394
いいかげん観点を言わないと、話が広がりすぎるぞ。まあ俺は構わんがな。
構造化設計されている例。
main(){
　　read();
　　write();
}

構造化プログラミングされている例。
int func(){
　　int ret = 0;
　　FILE *fp = fopen("hoge.dat", "rb");
　　if(fp == NULL){
　　　　ret = 1;
　　}else{
　　　　char buff[100];
　　　　int sts = fread(buff, sizeof(buff), 1, fp);
　　　　if(sts < 1){
　　　　　　ret = 1;
　　　　}
　　　　fclose(fp);
　　}
　　return ret;
}

464 ：仕様書無しさん：2008/05/28(水) 10:15:03

全然例になってねー

465 ：仕様書無しさん：2008/05/28(水) 11:13:06

> 話が広がりすぎるぞ。

お前が単独で斜め上を錐揉み回転しながらすっとんでいってるようにしか見えない
何を言いたいのかもわからんし勝手に自爆して掻き回してるだけじゃない
話を広げず簡潔に相手を納得させることができない時点でお前は存在価値ゼロ

初心者でも笑ってくれそうな稚拙なソース晒しても
それ自体がそもそも全然「例」になってないし
お前の相手は初心者ではなく(おそらく)職業プログラマなんだから
もう少し現実に即した例を出さないと「納得させる」のは永遠に無理
可哀想だからヒントをあげるけどせめて「例」なら対比させないと

466 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/28(水) 19:52:33

>>395
仕様書が不要なんて言っていない。日本語が通じないのかな？

>>397
なにこれ？ネタ？ネタにしては寒いな。
一応答えておくと、OOと構造化の違いをソースレベルで表した物だから、両方をファイルからソケットに
変更した時の影響を比べて評価してくれ。

>>403,405
おいおい、何で説明文を知っているのに、内容を理解していない？

>>404
おいおい、俺はHibernateの問題点など、かなり昔にこのスレで話しているぞ。

>>407-
コンパイルエラーとかクローズしてないとかは、関係ないので、とりあえず無視する。

467 ：仕様書無しさん：2008/05/28(水) 20:06:10

>>466
つまらん。

468 ：仕様書無しさん：2008/05/28(水) 20:35:44

>>466
Users us;
us.selectAll();
for(; us.hasNext(); ){
　　us.getRecord();
}
このコードを構造化されたコードで書けば、例えばこう。
void *datalist;
void *rec;
int ret = 1;
getDataList(datalist);
while(ret){
ret = getRecord(datalist, rec, ret);
}

＞FILE *fp = fopen("user.dat", "rb");
＞for(; ;){
＞　　fgets(rec, sizeof(rec), 1, fp);
＞}
ナニコレ？機能分割されてんの？コレ。
ソフトウェアの処理フローから、処理フローに必要でない機能を直接呼びだすなよ。
処理フローは「データの一覧を取得する → データを1つずつ取得する」だろ。

「ファイルから1行ずつ文字列を取得するソフトウェア」を作りたいなら、
1番目の「OOの例」とか言うのがその目的を果たしてない。

>>219の2つのコードは、ソフトウェアとしては等価じゃないだろ。
結果として動作は同じかも知れないがな。

469 ：仕様書無しさん：2008/05/28(水) 20:36:52

おじゃばさま、、休日返上の前にリスケさせてもらえませんか？

470 ：仕様書無しさん：2008/05/28(水) 21:27:15

なんだ、おじゃばいらないじゃん。

471 ：仕様書無しさん：2008/05/28(水) 21:39:34

人の三倍の仕事をこなす男。
・・・と言えば聞こえはいいが、その実はコード量が人の三倍になるのであった。

472 ： ◆ZnBI2EKkq. ：2008/05/28(水) 22:08:13

> > 466

同紙によると、要求仕様です。日本の人々が死んでますか？

これはどういう意味ですか？あなたの意見ですか？寒さのためと思うのです。
これはおそらく、その答えはイエスでもあり、構造的な違いがあるのソースのレベルを表現した素材、の状態にするには、時間、
と比較して、変更される与える影響を評価する。

ご存じの説明書はなぜ知って、私には理解してのコンテンツですか？
こんにちは、私には非常に休止状態に問題は、この断層-古いと述べた。

と思うのですが、おじゃばさまはどうですか？

473 ：仕様書無しさん：2008/05/28(水) 22:17:33

ここは高卒の溜まり場か？

474 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/28(水) 22:38:08

>>411
使えるのを使うのは構わないと思うが、本を盲信して、説明を暗記しただけで習得した気分になって
人に勧めるが、自分では一枚も書けない人とかいる。あれはどうにかして欲しい。

>>構造化プログラミングを知らないハカセ
いったい何人いるのか分からないが、あきれた状況だな。
403,405,418,423,436,443,456、基礎からやり直せ。特に456失笑レベルだ。

>>457
どっちが正しいのか分かっていない時点で、457もハカセと同類だぞ。

>>465
あのさ、390が構造化されている例で、463がされていない例だよ。対比してるよな。
あと、別に俺が書きたくて書いたのではなく、書いてくれと言われて書いたんだよ。
少しは前後の繋がりを見てから言った方がいいのではないか？

475 ：仕様書無しさん：2008/05/28(水) 22:44:57

>>474

>なにこれ？ネタ？ネタにしては寒いな。
>一応答えておくと、OOと構造化の違いをソースレベルで表した物だから、両方をファイルからソケットに
>変更した時の影響を比べて評価してくれ。

おじゃば的に言えば、ソケットだろうがファイルだろうが無限ループで出口無いので構造化じゃないです。
強いて言えばバグって言いたいけど、おじゃばとの解釈をすり合わせると構造化じゃないです。

出口がないのに構造化なのー？ネタ？

476 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/28(水) 22:46:31

>>468
質問だけど、datalistはチェーンか？
もしチェーンなら、468はファイルから情報を読み出す際に、必ずチェーンを使うのか？

477 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/28(水) 23:01:59

>>475
ネタじゃないのか。C言語の勉強がしたいのかな？
#define MAX_LOOP (10000)
int func(){
　　int ret = 0;
　　FILE *fp = fopen("hoge.dat", "rb");
　　if(fp == NULL){
　　　　ret = 1;
　　}else{
　　　　char buff[100];
　　　　for(int cnt=0; (!feof(fp))&&(cnt<MAX_LOOP)&&(!ret); cnt++){
　　　　　　int sts = fread(buff, sizeof(buff), 1, fp);
　　　　　　if(sts < 1){
　　　　　　　　ret = 1;
　　　　　　}
　　　　}
　　　　fclose(fp);
　　}
　　return ret;
}

478 ：仕様書無しさん：2008/05/28(水) 23:23:01

>>422
ググり直したら1,710件になったぞ
http://www.google.co.jp/search?hl=ja&q=%221%E3%81%A4%E3%81%AE%E5%87%BA%E5%8F%A3%22&btnG=%E6%A4%9C%E7%B4%A2&lr=
""で囲むんだ

479 ：仕様書無しさん：2008/05/28(水) 23:23:10

> 対比してるよな。

は？
どこが対比？
これで何を伝えたいの？
相手を納得させる気あるの？

480 ：仕様書無しさん：2008/05/28(水) 23:24:10

>>478
430は完全スルー?

481 ： ◆ZnBI2EKkq. ：2008/05/28(水) 23:28:01

>>477
>>472に答えてください
おじゃばさま、お願いします
後生ですから本当によろしく

482 ：仕様書無しさん：2008/05/28(水) 23:28:22

>>476
別にdatalistは線形リストでも1つのメモリバッファでも
メモリバッファの配列でも構造体の配列でも、
データ構造の設計次第。
recの内容もdatalistの他での使われ方も分からないのに決まらんよ。

で、datalistがチェーン構造してたら、何か問題か？

483 ：仕様書無しさん：2008/05/29(木) 00:04:26

>>481
おじゃばはこういうことを言ってるんだと思うぞ。

仕様書には、不必要なものと書かれていません。日本語は行きませんか？

それですなんとこれがあるでしょう？それは、材料ですか？材料のために寒いです。
私がソケットでそれをファイルから変えたとき、私は影響を比較して、しばらくの間、それがOOとソースレベルで構築される違いを表したものであるので私が答えるとき、両方とも評価します。

なぜ、あなたは説明を知るために、内容を理解しませんか？

おい、私はあたりを問題を語りますかなり昔この糸で休止状態。

私は編集エラーまたは終わりのしてないとかはでそれを無視します。そして、まず第一に重要でありません。

484 ：>>478：2008/05/29(木) 00:07:41

>>480
http://www.google.co.jp/search?hl=ja&q=%22%E3%81%99%E3%81%BE%E3%82%93%E3%80%81%E8%A6%8B%E3%81%A6%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F%22&btnG=%E6%A4%9C%E7%B4%A2&lr=

485 ：仕様書無しさん：2008/05/29(木) 00:47:11

おまえら。。いつまで低レベルな次元で言い合いしてる気だ
スレチも甚だしいぞ

486 ：仕様書無しさん：2008/05/29(木) 01:00:18

いいじゃん、どうせいつもスレチるかカソるじゃん

487 ：仕様書無しさん：2008/05/29(木) 01:53:30

おじゃばに聞きたいんだけど、OO ってのは
「論理的に物事を把握できない愚者のツール」
ってことで FA ？

488 ：仕様書無しさん：2008/05/29(木) 03:21:28

おじゃばがバグ量産機なのはわかったわ

489 ：仕様書無しさん：2008/05/29(木) 06:53:23

>>477
自信満々で、糞コードさらせるのって笑える。
ひどすぎるにも程がある。

490 ：仕様書無しさん：2008/05/29(木) 08:11:35

マジレスです。

おじゃばさんは、もっと経験を積まれたほうが良いと思います。
「井の中の蛙」です。外の世界を知らないので何を言われても
理解できないのだと思います。

学生さんだと私は推察しているのですが、
私の職場にもあなたのような人が配属されます。
いろいろかじっているのですが、周りにちゃんと教えてくれる人がいないの
で、「分かっているつもり」でそれ以上成長してない人です。
何を分かっていないのかすらも分かっていないのです。

ソースコードを拝見させていただきましたが、一見すればレベルがすぐに
分かります。過去に同じようなソースコードを書く人に出会ったことが
あるからです。「独りよがり」というやつです。

こういう人を現場で教育するのには骨が折れます。プライドを傷つけない
ようにうまく正しい方向へ導かなくてはなりません。
ああ言えばこういうではなく、自分の間違いに気付いた方が有益です。

オブジェクト指向がなぜ普及しないのか？ですが、
オブジェクト指向は、その設計者の「思考」つまり「くせ」が色濃く出て
しまいがちです。で、人と人とには相性というのがあります。
オブジェクト指向を理解するというのは、「設計者の意図」を理解する
事、「設計者の思想・経験」を理解することになります。
オブジェクト指向はそんなに難しくないですが、「人」を理解するのは
難しいです。

おじゃばさんに根本的に欠如している能力だと思います。
自己顕示欲を捨て、貪欲にすべての人の能力を吸収するつもりでないと
オブジェクト指向を使いこなすことはできません。

491 ： ◆ZnBI2EKkq. ：2008/05/29(木) 08:14:21

>>477
どうやらC言語の勉強がしたいらしいな
そのソースを改善してみたぞ

#define MAX_LOOP (10000)
int func(){
　　int ret = 0;
　　FILE *fp = fopen("hoge.dat", "rb");
　　if (fp != NULL){
　　　　char buff[100];
　　　　for(int cnt=0; (!feof(fp))&&(cnt<MAX_LOOP)&&(!ret); cnt++){
　　　　　　if (fread(buff, sizeof(buff), 1, fp) < 1) ret = 1;
　　　　}
　　　　fclose(fp);
　　}
　　else ret = 1;
　　return ret;
}

492 ： ◆ZnBI2EKkq. ：2008/05/29(木) 08:19:17

訂正する
fcloseの位置がバグっていたとは思わなんだ
おじゃばくんのソースはまったくひどい

#define MAX_LOOP (10000)
int func(){
　　int ret = 0;
　　FILE *fp = fopen("hoge.dat", "rb");
　　if (fp != NULL){
　　　　char buff[100];
　　　　for(int cnt=0; (!feof(fp))&&(cnt<MAX_LOOP)&&(!ret); cnt++){
　　　　　　if (fread(buff, sizeof(buff), 1, fp) < 1) ret = 1;
　　　　}
　　}
　　else ret = 1;
　　fclose(fp);
　　return ret;
}

493 ：仕様書無しさん：2008/05/29(木) 09:14:06

>>477も>>492も、どっちもどっちだ。
お前ら、そのソースコードで何を表現したいんだ？

関数funcは1しか返さないんだから、変数retをreturnする必要も無いし、
fpがNULLの分岐も要らないし、挙動が変わらないんだからfeofを見る必要も無い。

ファイルから読み込んでるだけなんだから、ループの最大数も要らないんじゃないのか？

int func(){
　FILE *fp = fopen("hoge.dat", "rb");
　char buff[100];
　if(fp){
　　while(fread(略)>0){}
　　fclose();
　}
　return 1;
}

まぁ、だから何？って話なんだが、見るに耐えん。

494 ：仕様書無しさん：2008/05/29(木) 09:26:12

fcloseそんなところに置くな
char buff も使う時になってから用意しろ

495 ：仕様書無しさん：2008/05/29(木) 09:29:59

あ、Cか。ならcharbuffは宣言部で良いか

496 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/29(木) 09:52:39

>>437,438
DVDレンタルで、そのユースケース図の威力を見せてくれよ。
自分で出来ないなら人に勧めるなよ。

>>481
日→英、英→日翻訳してるのか？

>>482
構造化で単にファイルからデータを読み込むのに、必ずチェーンを使うのかって事。
変更がなければ無駄な処理じゃないか？

>>487
いや設計方法の一つ。

497 ：仕様書無しさん：2008/05/29(木) 10:25:39

>>490
マジレスに申し訳ないんだが、おじゃばはLinuxについて5年前の知識を得意げに
語ったり、機種と称して昔の商用ディストリビューションを言ったりする、
つまり、もういい歳したジジイだ。
ジジイで学生でもおかしかないが、
実際はI社とやらで精神を病んでここに必死で書いてるんだろうな。

498 ：仕様書無しさん：2008/05/29(木) 10:33:16

>>497
それは高評価すぎ。
単に、使えなくて、現役を引退させられたんじゃないか？

499 ： ◆ZnBI2EKkq. ：2008/05/29(木) 13:03:50

>>496
>日→英、英→日翻訳してるのか？
はあ？ふざけてないで答えろよ質問？
お前と俺の日本の言葉にケチつけようだったのか？
なぐったぞ

500 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/29(木) 17:25:16

>>490
490はベテランPGで、現場で教育しているのか？
で、
>オブジェクト指向を理解するというのは、「設計者の意図」を理解する
>事、「設計者の思想・経験」を理解することになります。
って教えるのか？490の部下に同情するよ。

つーかプライドを捨てるのはオマエだよ。俺にはくだらないプライドなんかない。
だからソースコードやクラス図も書けるし、自分の意見を曖昧な表現なしに言う。
俺に大海を見せたいなら、ソースコードを書いて見せてみろよ。

>>491,492
改悪だよ。実行文が1つでも{}で囲むのは常識だぞ。行追加されたら動作が変わるだろう。
あとfclose()の位置は正しい。オープンエラーの時はクローズしない。NULLにクローズする気か？

>>493
ひどいな。ループの中に処理を追加するつもりで書けよ。

501 ：仕様書無しさん：2008/05/29(木) 18:10:27

>ひどいな。ループの中に処理を追加するつもりで書けよ。

散々似たことやってきておいて他人にはケチつけるんだね。
おじゃばって卑劣だなー。

502 ：仕様書無しさん：2008/05/29(木) 18:28:15

>>500
> 自分の意見を曖昧な表現なしに言う。
これはひどい
今まで散々話をそらしまくったうえでよくそんなことがいえたものだ

503 ： ◆ZnBI2EKkq. ：2008/05/29(木) 18:31:10

>>500
うっはｗｗｗおぇｗｗｗｗｗｗｗ
初心者乙
拙者はお前様と違いました
プロのプログラマーです
おじゃばはあほで臭い

504 ：仕様書無しさん：2008/05/29(木) 18:39:30

　　　　char buff[100];
　　　　for(int cnt=0; (!feof(fp))&&(cnt<MAX_LOOP)&&(!ret); cnt++){
　　　　　　if (fread(buff, sizeof(buff), 1, fp) < 1) ret = 1;

先生、この処理の意味が分かりませんorz
int func() { return1; }

505 ：仕様書無しさん：2008/05/29(木) 19:10:16

>>500
くだらないプライドのない人間は

・自分の間違いを素直に認めることができます
・他人の助言に素直に耳を貸すことができます

おじゃばはどっちもできないよな

506 ：仕様書無しさん：2008/05/29(木) 19:40:35

いや、たしかにプライドは無いと思うぞ、おじゃばは。
本来の意味でな。

507 ：仕様書無しさん：2008/05/29(木) 19:41:33

それどころか、彼の人間像は卑屈でゆがんだ性格です、本当に
くだらないプライドを満足させるオナニーのことしか考えてないから
勉強しないし、頭が悪いままだ
惨めな人生を送ることについては、「勝手にしろ」と言いたいが、
まず、「おじゃば、人に迷惑をかけるな」よ

508 ：仕様書無しさん：2008/05/29(木) 19:48:29

はいはい、ではまず相手にしないことを覚えようよ。
前略)モナー。

509 ：仕様書無しさん：2008/05/29(木) 20:15:36

>>500
これを見ればおじゃばでもオブジェクト指向がわかるはずだ
http://www.google.co.jp/search?hl=ja&q=sm%E3%83%9E%E3%83%8B%E3%82%A2&lr=

510 ：仕様書無しさん：2008/05/29(木) 21:01:53

プライドを持てよおじゃば。

他人が「出来る」と言っていることが自分には出来ないのだろう？
悔しくないのか？出きるようになってやろうと思わないのか？

日々重ねた努力と経験に裏打ちされた自信。それが真のプライドとなるのだ！
プライドを持たぬものは、努力を惜しみ成長も止まる。

そんな人間に大切な仕事は任せられません。

511 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/29(木) 21:05:25

>>503
初心者乙って、正しいソースを間違って修正したのはお前だろう？

>>505-508
プライドが高くて、間違いを認めないで、やばくなると関係ない突っ込みを繰り返すのは、ハカセの方だろう。
頭が悪くて勉強しない？簡単なDVDレンタルのクラス図も書けず、OOと構造化の違いも説明できず、
構造化プログラミングも誤解していて、コードも改悪することしか出来ないのは誰だ？
つーか、何で俺が間違っている事になっている？
オブジェクト指向も構造化プログラミングも、ちょっと調べればどっちが間違えてるのか分かるだろう？
ハカセの根拠は自説と、怪しいはてなの書き込みぐらいしかないぞ。

512 ：仕様書無しさん：2008/05/29(木) 21:09:19

>>511
ハカセって誰だよｗ
だから、いつになったらここで勝負ｗしても満足できないとわかるんだ。
あ、勝ってるから飽きないんだな。そんならそれでいいね。
勝ちつづければいいさ。

513 ： ◆/hhXTUq7wc ：2008/05/29(木) 21:23:10

どなたか有能なプログラマーがいましたら、答えを教えてください。

「10個の整数をキーボードから配列に入力し、その中の最大値と最小値を表示するプログラムを作成しなさい。
なお、入力された整数も最後に表示すること。」
また詳細はここに載っています。

514 ：仕様書無しさん：2008/05/29(木) 21:28:51

ところでさーおじゃば、Javaっていつになったら2.0になると思う？
もう何年かけて今のバージョンまで来てるんだろうねぇ？

515 ： ◆3X1b8VAs/E ：2008/05/29(木) 21:33:22

ExcelBVAのテクニックは大体わかります。
しかし、「Excelを起動するとVB？が起動し、ユーザーフォームとExcelが分離している状態」
のプログラム技術を身につけたいと思っています。

これを会得するには、やっぱりVBの知識と多大なる努力が必要なんでしょうか？

516 ：仕様書無しさん：2008/05/29(木) 21:58:48

私の知っているVB6とEXCELのVBAを比べるならば、言語としては全く同じと考えておいてよいと思います。
ただし、VBAで使えるユーザーフォームとVB6が備えているフォームは一見似ていますが違います。
ユーザーフォームの方が誓約が多いようです。

したがって、改めてVBを別で学習したとしても、ことフォームに関してはそのままの知識ではいけません。
全く応用できない分けではありませんが、違いを意識する必要があります。

しかし、VBをこれから学ぶのであれば(仕事でVB6が与えられたというのでなければ).NETを選択する方が有益かと思います。

既にある程度のテクニックをお持ちならば、そのまま応用していく位の心構えで良いでしょう。
ただし、Officeの次期バージョンではVBAは無くなる(既に無くなった？)と聞いていますので、
マクロを移植したいと思った場合には注意が必要でしょう。

517 ：仕様書無しさん：2008/05/29(木) 23:04:32

とりあえず、”プライド”という言葉の個人的誹謗には
長文で返す事でプライドが無いことがわかるな。

518 ： ◆W9sVIg2yUM ：2008/05/29(木) 23:07:34

DreamSparkでダウンロードしたVS2008Proを家のPCと
学校のPCの両方にインストールしたいのですが，
ライセンス的に可能でしょうか？

519 ：仕様書無しさん：2008/05/29(木) 23:37:32

>>496
＞構造化で単にファイルからデータを読み込むのに、必ずチェーンを使うのかって事。

ちゃんとレイヤーを意識して、モジュールの意味を考えて、処理フローを考えてるか？
おじゃばが書いたモジュールの目的は何だ？
ファイルをオープンして、ファイルから一行ずつ読み込むことか？
それとも、データの集合からデータを1つずつ取り出すことか？

単にファイルから1行ずつ読むためだけのコードなら別にfgetsを直接呼べば良いよ。
それなら俺の勘違いだ。
しかし、ファイルから1行ずつ読み込むことと、
データの集合からデータを1つずつ取り出すことはイコールではない。

＞変更がなければ無駄な処理じゃないか？
無駄ではない。
そのモジュールの目的や意味をはっきりと意識する目的もある。
>>219で書いたモジュールは、どういう目的で作られたモジュールなのか、ということ。
そしてプログラムの階層構造の中で、どの階層に位置するのか、ということ。

520 ：仕様書無しさん：2008/05/30(金) 00:31:54

おじゃばの言う　プライド　てのは、「慢心」と読めば良いのかな？
自分で「俺には慢心など無い」って言うのは、「慢心の塊です」って言うのと等価な気がするのだった...

521 ：仕様書無しさん：2008/05/30(金) 00:34:38

ファイルからデータ読むのにバイナリ直接読み込むコーディングだなんてw
iniファイルの読み込みだってモジュール化されてんのにwww

522 ：仕様書無しさん：2008/05/30(金) 00:40:23

おじゃばは当然、

#define MAX_LOOP (10000)

の()は何か意図があってつけてんだよな？
ちょっと説明してみてくれよ。Cは得意なんだろ？

523 ：仕様書無しさん：2008/05/30(金) 00:51:06

>>518
ご自分でライセンス条項を読んでください。

ところで、学校のPCにソフトウェアをインストールする事は、学校側の許可が必要になるかと思いますが、そちらは大丈夫ですか？

524 ：仕様書無しさん：2008/05/30(金) 02:02:18

そして今宵もアホコテのためのスレ流しが行われたのであった

525 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/30(金) 11:55:41

>>510
前にも言ったがプライドには2種類ある。
それは自分を成長させるプライドと、自分を成長させないプライドだ。
510の言うプライドは前者で、510の言う通り重要だと思う。だからソースやサンプルも出している。
俺がないと言ったのは、後者の「つまらないプライド」だ。

>>512
簡単なDVDレンタルのクラス図すら書けない上に、クラスは概念のインタフェースだとか、
リターンが複数あっても構造化プログラミングだとか言っている人だよ。
俺が勝負したかったのは、レンタルシステム設計で、どちらが良い設計かの勝負だったのだが、
もうそんなレベルではないようだ。

>>514
1.4でほぼ完成しているから、そんなに急がなくてもいいのではないか？
つーか何か入れて欲しい機能でもあるのか？

526 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/30(金) 12:36:42

>>519,521
ファイルから1行読み出すだけのつもりで設計しました。
しかし、ファイルからソケットに変更になりました。大修正ではないですか？

データの集合から読み出すつもりで設計しました。
ファイルのまま変更はありませんでした。チェーンを制御する処理や、データを溜め込むリソースなど、
直接リードしていれば不要な処理です。ちなみに変更がなかったので、誰もそのソースを見る必要も、
理解する必要もありませんでした。モジュールの意味ははっきりしていましたが、作者しか知りません。
無駄ではありませんか？

>>522
define内容が数式だった場合、演算子の優先順位が変わるのを防ぐ。
そのため、数式でなくても括弧で囲む癖をつけている。
つーか、俺がコーディングに不安のあるレベルか、実務でやっているのか本を読んだ程度なのかは、
ソースコードを見れば分かるのではないか？490は口だけのようだがな。

527 ：仕様書無しさん：2008/05/30(金) 12:48:43

皆の今までのオマエの評価は「とても仕事をまかせられないひと」なんだけど

528 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/30(金) 12:55:50

>>527
それならハカセに任せれば？

529 ： ◆ZnBI2EKkq. ：2008/05/30(金) 13:00:57

と・こ・ろ・で！
おじゃばさまは自分のホームページくらい持ってるよな？
おじゃばさまなら ”当然 ”Linuxで自宅サーバーやったことあるよな？
”当然 ”だが、俺もあるぜよ
おじゃばさまのサイトアドレス教えてくれよｗ

530 ：仕様書無しさん：2008/05/30(金) 13:15:51

>>526
ここまで来ると悪意さえ感じる。

531 ：仕様書無しさん：2008/05/30(金) 13:18:30

なんか直に見てみたくなってきた。
これってもしかして・・・？

532 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/30(金) 18:36:56

>>529
自分のHPは持っていない。
Linuxサーバを公開していた事はあるが自宅ではない。結構金がかかるのでやめた。
自宅には各種サーバはあるが公開していない。
ちなみにサーバ公開していたらどうするつもりだった？侵入したら不正アクセス禁止法にひっかかるぞ。

533 ：仕様書無しさん：2008/05/30(金) 19:24:26

そりゃすげーすげー

534 ：仕様書無しさん：2008/05/30(金) 19:28:16

サイトがあるなら見せてくれ
↓
アク禁に

バカ

535 ：仕様書無しさん：2008/05/30(金) 20:21:17

サーバもHPも持たないくせに、自己顕示欲を２ちゃんのコテハンで満たそうという
最低の人間だな、板の迷惑も考えずいつまでも上げる。
議論がしたければ相当の板へ行けといっても垂れ流す。

もうね、ある種のいかれた人には技術の話なんか無理なのが
よくわかったとこがいいんじゃね、このスレ。

536 ：おじゃばさま ◆GxjxF3yEw6 ：2008/05/30(金) 20:53:09

>>535
半端な知識で自滅して、恥をかきまくっているのはお前だろう？
俺は別に罠にはめた訳でもないし、難しい事を言っている訳でもない。
間違っているから指摘しているだけだ。
大体、客先で恥をかくよりはずっとマシだろう。勉強し直せばいいではないか。
むしろ感謝してもらいたいぐらいだ。

537 ：仕様書無しさん：2008/05/30(金) 20:55:46

> それならハカセに任せれば？

「だったら○○ちゃんに～」
お前は小学生か
『オマエの評価』にお前以外は関係ねーだろ

> サーバ公開していたらどうするつもりだった？侵入したら不正アクセス禁止法にひっかかるぞ。

被害妄想激しいってレベルじゃねーぞ

538 ：仕様書無しさん：2008/05/30(金) 20:56:46

＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？
＞半端な知識で自滅して、恥をかきまくっているのはお前だろう？

　こ　れ　な　ん　て　自　虐　？

539 ：仕様書無しさん：2008/05/30(金) 20:57:09

>>536
自己紹介はもういいって

540 ： ◆ZnBI2EKkq. ：2008/05/30(金) 21:28:18

>>536
http://kains.dip.jp/
俺のHPだ

＞Linuxサーバを公開していた事はあるが自宅ではない。結構金がかかるのでやめた。
俺でも自宅サーバやってるぞ、貧乏な中年おじゃば。
電気代しかかからないし、電気代もノートPCを使って抑えるとかな。俺は玄箱を使ってる。
ピチピチの２３歳だぜ、貧乏なおっさんよ
HPはずいぶん更新してないけどな
実務でプログラマやってますんよ俺は

541 ：仕様書無しさん：2008/05/30(金) 21:32:27

省電力なら他にも VIA C7 とか AMD Geode とか色々あるよね

それはさておき
各種サーバが家にあって公開しない理由が費用ってイミフだよね
手間が理由ならまだわかるけどね

542 ：仕様書無しさん：2008/05/30(金) 21:39:10

たしかに、ハカセや修士は知識や知性が無いからな（常識も無いみたいだし）
おじゃばが怒るのは解る、一つの出口に
>http://www.ailight.jp/blog/kazuk/archive/2005/03/11/4920.aspx
のブログを根拠にしているし、ブログが根拠って常識がなさすぎる
それもブログ書いている本人が
>Blog ですから。自論を好きに書いてます。
と書いている。　あと、>>436
>アセンブラレベルで見れば、戻り値を１つのレジスタにいれて返してるだけ
戻り値が複数あれば、出口は複数と言いたいのか？　データとアルゴリズムに違いも
解らないみたいだし、普通アセンブラならRETが一つかどうかだろう
ほんとハカセや修士のせいでレベルが低くなった

レベルを戻す為におじゃばに質問、OOや例外処理のテストを
どんな感じでやっている？　構造化との違いとか
気が向いたら答えてくれ

543 ：542：2008/05/30(金) 21:44:50

　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧　　　　＜　ﾌｰ　自作自演も疲れるぜ
　（ﾟДﾟΛ)_Λ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　（￣⊃・∀･))
　｜｜￣|￣
　（_＿）＿）
　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧ｺﾞﾙｧ!　＜　な、なに見てんだｺﾞﾙｧ！
　（ﾟДﾟΛ_Λ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　（￣⊃・∀･))
　｜｜￣|￣
　（_＿）＿）

544 ：仕様書無しさん：2008/05/30(金) 21:45:03

先生！！！！！！
union {
int i;
char c[4];
} uni;
ってどんな時に使うんですか？

>>541
自宅はアナログのダイアルアップなんです＞＜
おじゃばってベトナムに住んでいるんですよ

545 ：仕様書無しさん：2008/05/30(金) 21:48:50

>>543
ハカセ必死ｗ
お前をウザイと思っているのは、おじゃばだけじゃないぞ

546 ：仕様書無しさん：2008/05/30(金) 21:55:38

はいはいわｋったわかった

547 ：仕様書無しさん：2008/05/30(金) 21:58:22

最近の自演は度が過ぎてるな

548 ：仕様書無しさん：2008/05/30(金) 22:07:58

>>546-547
ハカセ、何でそんなに必死なのｗ

549 ：仕様書無しさん：2008/05/30(金) 22:11:01

自分のことがよくわかってるじゃないかｗ
えらいぞおじゃばｗ

550 ： ◆ZnBI2EKkq. ：2008/05/30(金) 22:14:32

「知者不言、言者不知」
…物事に通じた人は、その知識などをむやみに言葉に出さないが、未熟な者は得意がってさかんに言いまくるものである。

551 ：仕様書無しさん：2008/05/30(金) 23:26:10

>>550と、得意がっております。
しかも二番煎じ。

552 ：仕様書無しさん：2008/05/30(金) 23:31:18

>>526
＞ファイルから1行読み出すだけのつもりで設計しました。
＞しかし、ファイルからソケットに変更になりました。大修正ではないですか？

ファイルから読み込むことが、そのアプリケーションの主たる目的であるなら、
もちろんメインフローにとても大きい影響がでるだろ。
しかし、ソケットに変更になった時点で、全く別の目的を持ったアプリケーションなわけだから
大修正以前に、新規に開発プロジェクトを開始すべき状況。

一見似てるだけで全く別モノのアプリケーションを開発する時に
「似てるモノがあるんだから」と工数を削るのはデスマーチの入り口。
アプリケーションの本質的な目的(メインフロー)にはあまり関係ないのに
「ファイルから1行読み出すだけのつもり」で作ったソフトの修正に苦しむなら、
単に設計サボったツケを払わされてるだけ。

この辺の話は構造化だろうがオブジェクト指向だろうが、そんなに変わらんよ。

＞無駄ではありませんか？
俺は無駄では無いと思うが。
大体において自分1人で開発するわけじゃないし、他人がメンテナンスすることも考えて仕事してるから。
が、おじゃばがそこまで強く「無駄だ」と主張するなら、俺は別にそこは否定する気は無い。

俺は「構造化設計ってのはこういうものだ」と言ってるだけであって、
おじゃばが「構造化設計は無駄だ」という主張をしたからと言って、
そのことにあまり興味は無い。
何が無駄で何が有益かは、人によって違うからな。

553 ： ◆ZnBI2EKkq. ：2008/05/30(金) 23:41:13

会話も議論も正論も無意味
自分の愚かさ、弱さ、無能さ、惨めさを少しでも自覚させ、
書き込むことを諦めさせる以外には無い

554 ：仕様書無しさん：2008/05/30(金) 23:44:06

そういや暫く前にもDB鯖が変わったら～とか言ってたな

開発初期ならともかくそんな根本を揺るがすようなシーンそうそうないっての
変わる可能性があるなら非OOでもそういう前提で実装するし
それ以前にアホコテ的OOじゃあ修正量変わらん

経験のあるPGならもう少し現実的な例を用意できるだろ

・・・彼には無理だよな　無茶言ってごめんな

555 ：仕様書無しさん：2008/05/31(土) 00:17:13

>>554
>そういや暫く前にもDB鯖が変わったら～とか言ってたな
>開発初期ならともかくそんな根本を揺るがすようなシーンそうそうないっての
>変わる可能性があるなら非OOでもそういう前提で実装するし
パッケージソフトだとよくある、相手のDBに合わせってカスタマイズするのがデフォ
もちろん、変更が頻繁にあるからOOで作ってある、実務経験が浅いのか？

556 ：仕様書無しさん：2008/05/31(土) 00:20:52

>>542
>>アセンブラレベルで見れば、戻り値を１つのレジスタにいれて返してるだけ
>戻り値が複数あれば、出口は複数と言いたいのか？　
お前バカ？日本語読めないの？
「戻り値を１つのレジスタに」って書いてあるだろ、「戻り値が1つ」とは書いて
ないだろ、アセンブラもよく分かってないようだし、アホ丸出しだなw

557 ：490 ：2008/05/31(土) 00:24:55

>>500
>>>>490
>>490はベテランPGで、現場で教育しているのか？
>>で、
>>>オブジェクト指向を理解するというのは、「設計者の意図」を理解する
>>>事、「設計者の思想・経験」を理解することになります。
>>って教えるのか？490の部下に同情するよ。
初心者に「設計者の意図」なんて言っても分からないのでそう言うことは
言いません。

私は、ベテランではありません。

> つーかプライドを捨てるのはオマエだよ。
> 俺にはくだらないプライドなんかない。
くだらないプライドがないのでしたら、もう少しソフトな日本語が書ける
はずです。

> だからソースコードやクラス図も書けるし、自分の意見を
> 曖昧な表現なしに言う。
> 俺に大海を見せたいなら、ソースコードを書いて見せてみろよ。

「井の中の蛙」は、自ら井戸の中から出て初めて大海を知ることができます。
井戸の中から大海は見ることができません。

558 ：490 ：2008/05/31(土) 00:25:16

>簡単なDVDレンタルのクラス図すら書けない云々・・・
クラス図を描くには、要求を定義しなくてはいけません。
レガシーシステムの有無、使用するキーメカニズム、商売の規模
そのほかにもさまざまな事柄が絡んできます。
要求に依存しない普遍的なDVDレンタル店のモデルが存在する
と考える人はまずいないでしょう。
DVDしかレンタルしていない店もまずありません。

レンタル店の例は、UMLモデルのサンプルとしてよくみかけますが、
あくまでもサンプルです。要求を極端に簡素化してモデル作成している
ため簡単なのは当たり前です。

DVDレンタル店のクラス図などと軽はずみなことは言わないことです。

559 ：仕様書無しさん：2008/05/31(土) 00:25:36

>555
＞非OOでもそういう前提で実装するし

読んでやれよ馬鹿

560 ：仕様書無しさん：2008/05/31(土) 00:26:41

>555 おじゃば
悪い癖がでてるぞ

561 ：仕様書無しさん：2008/05/31(土) 00:28:25

おじゃばって自作自演が下手すぎて、みっともない。

562 ：555：2008/05/31(土) 00:41:09

>>559
>もちろん、変更が頻繁にあるからOOで作ってある、実務経験が浅いのか？
理解しろよ、OOも解らんアホ

563 ：仕様書無しさん：2008/05/31(土) 00:45:12

>>562
素人(ハカセ)相手に、熱くなるなｗ

564 ：仕様書無しさん：2008/05/31(土) 00:49:45

>>563
が低学歴で人生の負け組である事はよーくわかった。

565 ：仕様書無しさん：2008/05/31(土) 00:55:13

それだけは同意

566 ：仕様書無しさん：2008/05/31(土) 00:56:43

？
DB鯖が変わったら～だからOOじゃないとダメなんだ！がおじゃばの主張じゃなかった？
なんでおじゃばの自演になってんだー？

567 ：仕様書無しさん：2008/05/31(土) 00:57:21

>>556
必死になるな、アホがｗ
お前がアセンブラを知らないのは、解ったから
もうちょっと、まともな知識のある事だけ書け

568 ：仕様書無しさん：2008/05/31(土) 00:59:05

ハカセは日本語が不得意なの？

569 ：仕様書無しさん：2008/05/31(土) 01:02:08

>>564
ハカセは超能力もあるんだ、すげーｗ

570 ：仕様書無しさん：2008/05/31(土) 01:02:13

>>477を見ていて、学生のころの俺がCを独学2、3ヶ月めくらいの時に書いたファイル分割ツールを思い出した。

素人なもんで、「いきなりコーディング」しちゃうわけだが、
当時、本の受け売りで「まずコメントだけでフローを書いてみる」というのを実践していた記憶がある。
...
int main(){
　/* 引数の処理 */
　/* 入出力ファイルのオープン */
　/* 指定のサイズに分割 */
　/* ファイルのクローズ */
}
このコメント1行に1関数を割り当てていくみたいな感じ。

実際にはファイルのオープンクローズくらいはmain関数に直に書いてしまうが、
指定のサイズに分割部分が>>477のelse内に相当する感じだったはず。（無論もう少し複雑だが）
そこでまた、上のような事を繰り替えしていく。

とりあえず、おじゃばにはこのやり方をオススメしてみる。

571 ：仕様書無しさん：2008/05/31(土) 01:03:54

ハカセは、菊池なのか？

572 ：仕様書無しさん：2008/05/31(土) 01:20:16

>>556
出口の話しにﾚｼﾞｽﾀの事しか書いて無いからじゃないの？
>データとアルゴリズムに違いも解らないみたいだし
って、542も書いているし、４３６よりは５４２のほうが
アセンブラ分かっていると思うよ

573 ：仕様書無しさん：2008/05/31(土) 01:21:26

ハカセは、ハカセは、ハカセは、って何か知らんが、
ハカセによっぽどコンプレックス持ってる奴がいるな

574 ：仕様書無しさん：2008/05/31(土) 01:23:31

>>572 自演乙

575 ：仕様書無しさん：2008/05/31(土) 01:28:42

>>573
ハカセ自惚れるな、さすがはハカセだなｗ

576 ：仕様書無しさん：2008/05/31(土) 01:30:39

今日も必死だなww がんばれよ、
俺ももう寝る。じゃ

577 ：仕様書無しさん：2008/05/31(土) 02:32:37

ハカセ、ハカセっておまえら...
http://ukgk.g.hatena.ne.jp/images/group/ukgk/diary/faerie/20071029.png

578 ：仕様書無しさん：2008/05/31(土) 08:17:24

returnやbreakやgotoや例外の他にexit(0)というのもあったな。

579 ：仕様書無しさん：2008/05/31(土) 08:21:41

542はおじゃばか？プライドがないコンプレックスを全面に押し出した文章書くので
他の文章から浮いているように漏れだけか？

580 ：仕様書無しさん：2008/05/31(土) 09:03:57

>>578
C言語の話でreturnやbreakがダメなら、switchやcontinueもダメだぞ。

581 ： ◆ZnBI2EKkq. ：2008/05/31(土) 09:04:08

おじゃばが営業マンになったようです。

おじゃば「うちの商品は最高ですお」
やらない夫「そうですか」
おじゃば「そうですお」
やらない夫「それでどうなんですか？」
おじゃば「だから！うちの商品は最高なんですお。買わないと損だお」
やらない夫「（印刷物を指差して）でもここのところなんて複雑そうじゃない？」
おじゃば「でもそれはそういうように作ったので、仕方が無いんですお」
やらない夫（それいっちゃだめだろ…　ｊｋ）
おじゃば「こちらが発注書になりますので、書いてくださいお」
やらない夫「（え？なにこの商談成立みたいな…）検討させていただきますので、
　　　　　　また後日連絡いたします。こちらの連絡先でよろしいですか？」
おじゃば「あ、そうだお。今すぐ即金払いというのは経営的に無理だお。しょうがないお」
やらない夫「……………」
おじゃば「どうかしましたかお？おっおっおっ？」

582 ：仕様書無しさん：2008/05/31(土) 09:06:14

>>581
おじゃばの悲惨さは救いようもないが、
お前も痛いわ

583 ：仕様書無しさん：2008/05/31(土) 13:45:07

わざわざこんなスレでコテつけてる時点で同類なのは明らか

584 ：仕様書無しさん：2008/05/31(土) 14:11:06

>>525
「Code Complete第2版上」では複数のreturn文が推奨されるケースがいくつか
書かれている。
以下引用
>「return文とexit文は、～標準の終了ルートを通じてルーチンを終了し、制御を
>呼び出し元のルーチンに戻す。」
>「ガード句とは、制御を早めに戻すための前提条件のようなものである。」
void funcA( encrtyptionKey key ) {
　　if (file.validName()) {
　　　　if (file.open()) {
　　　　　　if (encryptionKey.valid()) {
　　　　　　　　if (file.decrypt( key )) {
　　　　　　　　　　: なんかの処理
　　　　　　　　}
　　　　　　}
　　　　}
　　}
　　return;
}
void funcB( encrtyptionKey key ) {
　　if (!file.validName()) return;
　　if (!file.open()) return;
　　if (!encryptionKey().valid()) return;
　　if (file.decrypt( key )) return;
　　: なんかの処理
　　return;
}
ネストが深くなるfuncA()より、funcB()の方が見やすいというわけだ。
「リターンが複数あっても構造化プログラミング」だろ？　初心者レベルの話
だと思うんだが、おじゃばのレベルには難しいみたいだな。

585 ：仕様書無しさん：2008/05/31(土) 15:46:56

おじゃばよ、多くは望まない。とりあえずこの2つだけでいいから勉強してみてくれ。
・ユースケース記述
・抽象化
話ができるようになるのはそれからだ。それまで気長に待っとくからさ。

586 ：仕様書無しさん：2008/05/31(土) 17:14:41

>>584
Cにはなくて他の言語にはある例外処理がいかに有効かを示す例、なのかな。
どうでもいいけど、おじゃばは自分が読んだ本の名前も言えないような馬鹿だぞ。
そんな馬鹿に何を求めてるんだアンタは。

587 ：仕様書無しさん：2008/05/31(土) 17:20:40

>>585
>・ユースケース記述

前から思ってるんだが、ユースケース記述って、記法としてのUMLの敗北だよな。
なんで自然文で書かせるのか訳わからんよ。
アクティビティ図の記法とか適用できるはずだけどなぜやらんのかと思う。
フローチャートに似過ぎてしまうから？
UMLはその他にも、記述できないことはノートで書かせるとか、アホな仕様満載。
まあ、UML原理主義者そのものが、全てにおいて痛すぎるからな。

588 ：仕様書無しさん：2008/05/31(土) 17:29:45

>>586
関数のリターンと例外はセマンティクスが違うだろ。
例外はあくまで例外で、何かおかしな事態がおきたということを通知する
ための仕組み。関数のリターンは想定内の条件下での判断結果を返すため
の仕組み。混同しない方がいい。

589 ：仕様書無しさん：2008/05/31(土) 17:30:02

>>584
ネストを深くせずにreturn一つもできるぞ。NOP一つ分遅いけどな。
void funcC( encrtyptionKey key ) {
　　if (!file.validName()) ;
　　else if (!file.open()) ;
　　else if (!encryptionKey().valid()) ;
　　else if (file.decrypt( key )) ;
　　else {
　　: なんかの処理
　　}
　　return;
}

590 ：仕様書無しさん：2008/05/31(土) 17:34:27

>>589 それでも、funcBの方が見やすいな。

591 ：仕様書無しさん：2008/05/31(土) 17:35:20

>>587
>http://www.atmarkit.co.jp/im/carc/serial/renew_uml08/renew_uml08.html
これはわかりやすいと思った。機能分割の単位で書くな、とか。
ユーザの視点でまとめる、という点では自然言語で書くのが当然とも。
おじゃばみたいな、自然も人工もどの言語もダメなのは論外だけどさ。

592 ：仕様書無しさん：2008/05/31(土) 17:38:57

>>584,589
なぜ復号できなかったかわからない時点で、
その例はおかしいような気もするが。

593 ：仕様書無しさん：2008/05/31(土) 17:41:51

>>587
なぜ自然文で書かせるのか。
結局、人間が使うシステムだからさ。自然文が一番合理的で正確に伝えられる。
図は見る人によって曲解される可能性が大きいからな。おじゃばみたいに。

594 ：仕様書無しさん：2008/05/31(土) 17:44:34

>>591
@ITなんか引っ張ってくるなよ。
機能分割云々は関係ないだろ。
UML記述って、結局フローパターンと階層化で構成されているじゃん。
ユーザの視点でまとめるってのと、自然文で書くってのにも相関ないよ。
フロー記述が可能な記法を適用できるはず。
図の方がユーザにとっても流れを読みやすいとは思わんか？

595 ：仕様書無しさん：2008/05/31(土) 17:44:41

>>592 いや、論点はそういうロジックの中身云々の話じゃないからw

596 ：仕様書無しさん：2008/05/31(土) 17:48:54

>>594
おまい、仕様書は全部エクセルで書くタイプだろ？

597 ：仕様書無しさん：2008/05/31(土) 17:52:37

>>587
そもそもユースケース記述ってUMLだっけか？

598 ：仕様書無しさん：2008/05/31(土) 17:56:23

情報伝達の基本は５Ｗ２Ｈだよ。これを正確に伝えること。
教わらなかったか？

599 ：仕様書無しさん：2008/05/31(土) 17:57:05

>>596
いや、そんなことはない。
UMLのユースケース記述の例って、以下のようなやつだろ。
自然文って言ってもフローだよな。
まさかお前は文章で延々と書いてるのか。

主フロー
1.....
1.1.....
2...
3...

代替フロー1
1a....
1b.....

600 ：仕様書無しさん：2008/05/31(土) 18:01:48

>>597
それ重要だよな。
記法じゃないからUMLの仕様の範囲じゃないことは明かだけど、
ユースケース記述には必要なものとされてるだろ。
これって、ユースケース記法の記述力の弱さを示しているに過ぎない。

601 ：仕様書無しさん：2008/05/31(土) 18:07:18

>>599
それでいいじゃん、特に書き方は厳密に規定されてないわけだから、
番号を振るなり、記号を使うなり、罫線を使うなり、ケースバイケース
で自分が書きやすく、伝えやすいと思う書き方で書けばいいじゃね。
ただユースケース記述という、要求把握のための手法が示されてるだけ
の話だろ。

602 ：仕様書無しさん：2008/05/31(土) 18:10:19

>>601
それでいいならいいさ。Unifiedなんていわなけりゃね。

603 ：仕様書無しさん：2008/05/31(土) 18:11:49

ユースケース記述は、要件定義の時ばかりでなく、運用テストや
結合テストのテスト仕様を書くときにも役立つ。

604 ：仕様書無しさん：2008/05/31(土) 18:31:19

こうやってそれなりの知識を持って語れるおまぃらは問題ないんじゃね？
中にはエース級の自負を持って仕事してるやつもおると思うわ

問題なのは、
知識を得ることをせずに、でたらめな知識で文句言ってるだけの奴

605 ：仕様書無しさん：2008/05/31(土) 19:04:24

UMLで規定されてるユースケースの表記法はユースケース図だけであって、
「ユースケースモデルはユースケース図とユースケース記述でしなさい」
と要求してるのはRUPとかの開発プロセスの方。

ユースケース記述が自然言語はダメだろ、ってUMLにケチ付けるのはおかしいよ。
>>600のユースケース図の表現能力が低いってのは同意。

606 ：仕様書無しさん：2008/05/31(土) 19:09:22

>>526
>define内容が数式だった場合、演算子の優先順位が変わるのを防ぐ。

おいおい、いくらなんでも演算子の優先順位は変わらんだろ。
変わるのは式の評価順序な。あいかわらず日本語が不自由な奴だな。

607 ：仕様書無しさん：2008/05/31(土) 19:48:35

>606
多分分かってて書いてると思うけど、一応
defineは俺も数式の場合は必ず括弧をつけるようにしてる
こんな感じのであれば問題が出る可能性あるし

#define AAA 1+2
#define BBB (1+2)
int a=AAA*2; //結果は５
int b=BBB*2; //結果は６

けどまあ、おじゃばがアホなのは事実だけど

608 ：仕様書無しさん：2008/05/31(土) 19:53:36

UML 2.0の仕様書から抜粋

ユースケースの振る舞いは、相互作用図、アクティビティ図、ステートマシン図、
あるいは必要に応じて自然言語のテキスト等により記述できる。

おいおい、自然文は優先度一つ低いじゃねーかよ。
仕様書には、ステートマシン図でユースケースを記述した例が出てるぞ。

609 ：仕様書無しさん：2008/05/31(土) 19:56:44

お客が読むもんと、自分らで話通すのと区別つかないのはどーよとは思うな。
自分たちだけがシステムつくってるわけじゃねぇぞと。

610 ：仕様書無しさん：2008/05/31(土) 20:26:17

おいおい、UML2.0の話はまずいだろ、おじゃばがまた癇癪おこすぞ。
おじゃば1.0すら理解してないレベルだからな。

611 ：仕様書無しさん：2008/05/31(土) 21:46:09

1でも2でカンケーネーよ。UMLが嫌いなんだろ

612 ：仕様書無しさん：2008/05/31(土) 21:50:59

嫌いというより、
分からないもんだから八つ当たりをしてるってとこだな

613 ：仕様書無しさん：2008/05/31(土) 21:51:28

マジレスしとく。
ユースケース記述が何故軽視されているのか？を説明しよう。
実際ユースケース記述（シナリオ）は、要求を的確にしかも低コストで
表現するのに有効である事はかなり昔から知られていた。
この低コストというのがプロには重要だ。機械的な図ですべての要求が
記述できたとしてもコストがかかりすぎるからな。

ユースケースが軽視されたのは、UMLツールメーカーの陰謀に他ならない。
・図からソースコード生成
・開発ドキュメントの図による可視化
オブジェクト指向もそうだったように、UMLも例外なく普及を急ぐがあまり
「誇大広告」が横行していた。欧米人は、新しい技術を開発すると、
過去の技術を完全否定する。UMLは自然言語の対比させてメリットを強調
してきた。

UMLははっきり言って行き詰った。が、それを救ったのがユースケースなのだ。
結局、人の最大の思考のツールは、「自然言語」であり、自然言語とUML図が
相互に補い合ってより現実的な解が生まれた。

技術の普及の背景には「経済」が常に絡んでいる。正しさよりも、利益が
優先される。踊らされないように気を付けないと。

614 ：仕様書無しさん：2008/05/31(土) 21:54:22

自演か。。

615 ：仕様書無しさん：2008/05/31(土) 21:54:56

へー、そうなんだ。

616 ：仕様書無しさん：2008/05/31(土) 21:56:15

つまりエクセル最高と？

617 ：仕様書無しさん：2008/05/31(土) 22:03:06

「ユースケース記述＋図」ということ。
図だけでもユースケース記述だけでもだめ。

「万能ナイフ」も「打ち出の小槌」も「銀の弾丸」もソフト開発の世にない。
臨機応変にやればいい。新しい技術が出ると古い技術捨てたくなるんだろうが
その必要はない。

プロなら、問題をしっかり理解して適切な解決方法を見つけないとな。
とりあえず、古いやり方はNGというのは、頭が硬直している証拠だぞ。

618 ：仕様書無しさん：2008/05/31(土) 22:14:29

個人的にはユースケース図だけってのはナシだけど、
場合によっちゃユースケース記述だけってのはアリだな。

ユースケース同士の関係がシンプル(かプロトタイプに表される関係が特に無い)場合だとか、
アクターが少ない場合とかには、ユースケース図の意味があまり無い。

619 ：仕様書無しさん：2008/05/31(土) 22:20:48

というか、アクターとユースケースの関係なんか、
ユースケース記述の頭の表項目で十分だろ

620 ：仕様書無しさん：2008/05/31(土) 22:28:46

まあ、ぶっちゃけていえば、要求分析を行うツールとして、
ユースケースモデリングってのは貧弱なんだよね。
ユースケースフローに複数のアクターが関わる場合、その関係を記述できない。
本当なら、ワークフローツールのように、
アクターとアクティビティ図を絡ませる記法が必要だとおもう。

621 ：仕様書無しさん：2008/05/31(土) 22:45:34

てかね、ユースケース記述信奉してるやつって、どれだけ書いてるんだよ。

1.xxxx
1.1 aaaだったら、3.へ
2.xxxxx
3.xxxxxx
3.1 bbbだったら代替ケース3a参照
3.2 xxxx
4.xxx

こんなこと書いてるくらいだったら、フローチャートの方が数倍優れてるがな。
分岐でネストが深くなったり、飛んだりするとたちまち破綻するしな。
あと、繰り返しとかな。
シーケンス図も同じ過ちを繰り返してて、2.0で繰り返しとか分岐とか、
後付けで導入したけどひどいもんだ。
UMLってそれほどいいかよ。

622 ：仕様書無しさん：2008/05/31(土) 22:46:03

記法じゃなくて、
工夫が足りないんじゃね？

623 ：仕様書無しさん：2008/05/31(土) 23:01:05

>621
つ　オブジェクト指向

624 ：仕様書無しさん：2008/05/31(土) 23:04:06

フローチャートはどっちかっつうとプログラマ向けだろ。
ユースケース記述は要件定義用。それが細かくなりすぎるのはそもそも
ユースケースとする単位が間違っている可能性が大きい。

625 ：仕様書無しさん：2008/05/31(土) 23:08:12

「ユースケース」単位でシステムを見るという事を考えてみた事はあるか？

開発プロジェクトは、要求がソースコードに変換されれば良いわけではない。
ユースケースは、開発を進める際の工数見積もりの単位であり、開発の優先度の
単位であり、テストの単位であり、修正の影響範囲である。
システムの変更は、ユースケース単位で行われ、ユースケースごとに値段が
付けられる。

ユースケースに設計や実装をひもづけて管理することで、プロジェクトを管理
するという側面もあると思う。

626 ：仕様書無しさん：2008/05/31(土) 23:14:05

だからさ、そっちの方が頭が硬直してないか？
フローチャートはプログラマ用？
俺はそうは思わんが、別にフローチャートでなくてもいいぜ。
一般にいわれるユースケース記述は優れているかどうかが問題。
粒度の問題はあるが、そんな単純なユースケースばかりだと思ったら大間違い。
普通に分岐や繰り返しはあるだろう。

627 ：仕様書無しさん：2008/05/31(土) 23:19:07

まー分かればなに使ってもいいよ。

628 ：仕様書無しさん：2008/05/31(土) 23:23:56

例えば業務系のシステム構築の場合、客が話す要件をまとめる必要があるわけだが、
それをユースケース記述に起こす場合は、上から下へすとんと流れる正常系とせいぜい
幾つかの異常系ぐらいにしておいた方がいい。客の要望の本筋を把握するのが第一の
目的なんだから、あまり細かいレベルで書く必要はない。どうしても分岐が必要なら、
その分岐部分を別のユースケースにした方がいい。
細かいレベルは次の設計段階で、シーケンス図なりコラボレーション図なり、フロー
チャートなり使えばいい。

629 ：仕様書無しさん：2008/05/31(土) 23:25:05

OO関係ないけど、要求仕様のフォーマットにゃUSDMなんてのも有るぜ。
まぁぶっちゃけて言うとEXCELの表だな。
興味があったらググってみたら良い。

630 ：仕様書無しさん：2008/05/31(土) 23:30:22

しかし、ユースケースとユースケース記述区別できないやつ多すぎるな。

631 ：仕様書無しさん：2008/05/31(土) 23:36:09

>>628
ユースケース記述の目的は要件の把握ももちろんあるが、
クラスの抽出も大きな目的だぞ。ユースケース記述から
クラス候補を洗い出し、その下の設計レベルへもっていく。
そのためにわざざ子細に文章で書くわけだ。
そういう意味ではフローチャートとはちょっと目的が違うな。

632 ：仕様書無しさん：2008/05/31(土) 23:43:00

>>631
やっとおじゃばのテーマに迫ってきたな。
で、どの程度の文章で書いてるのさ？
それとフローチャートに文章を書けない理由はないけどね。

633 ：仕様書無しさん：2008/05/31(土) 23:49:25

フローチャートに文章を書けない理由はないけど、
クラス抽出の目的からすると分岐や繰り返しや線
なんかはいらんわな。それよりも舞台の登場人物
と役割が読み取れることの方が重要。

634 ：仕様書無しさん：2008/05/31(土) 23:53:19

結局、ユースケース記述はクラス抽出のためだけかい。
ハッキリ言っていらないな。

635 ：仕様書無しさん：2008/05/31(土) 23:57:10

まぁクラス抽出が不要な>>634には無用の長物だろうな。

636 ：仕様書無しさん：2008/06/01(日) 00:05:36

おいおい、クラス抽出のため、とか言ってる奴、
使ってないんじゃないか？
インターフェースとクラスの両方だろ

637 ：仕様書無しさん：2008/06/01(日) 00:09:13

おいおい、インターフェースとクラスの両方とか言ってる奴、
使ってないんじゃないか？
インターフェースもクラスも属性も関連もひっくるめて全部だろ

638 ：仕様書無しさん：2008/06/01(日) 00:12:46

なぜ、ここまでぐちゃぐちゃなのにおじゃばは叩かれるんだろうか？
それもほぼ統一された見解で・・・。
やはり、おじゃばの逆張りで開発するのが正しいのだろうか？

639 ：仕様書無しさん：2008/06/01(日) 00:13:26

ユースケース図は、アクターとサブジェクトとユースケースによって成り立っている。
ユースケースってのは、サブジェクトがアクターに対して公開している
インタフェースといえるわけだ。
このサブジェクトは、オブジェクトとして抽出される候補の一つだろう。

それに対して、ユースケース記述はユースケースの振る舞いを記述したものだから、
これはシステムの機能を記述したものといえるわけで、半分設計の範疇だろう。
どうしてこの部分を自然文にこだわるのか理解できないね。
さっきから指摘してるように、純粋なフローチャートでなくていいんだぜ。
アクターとフローが絡んでくれば、「舞台の登場人物と役割」は明示できるだろ。

640 ：仕様書無しさん：2008/06/01(日) 00:18:27

クラス抽出ならロバストネス図の方がよくね？
ユースケース→ロバストネスで行くのが一番手っ取り早いと思うが

641 ：仕様書無しさん：2008/06/01(日) 00:18:38

ユースケース図からいきなりクラスを抽出する奴とかよほどの残業好きか？
アクティビティを抽出して、コンポーネントにばらして、シナリオ抽出して、
ってやってく方がラクだろ

まさかおじゃばか？

642 ：仕様書無しさん：2008/06/01(日) 00:22:19

>>639
ちょ、ユースケース図のアクターってのは、開発目的とするシステムと関わる
「人」や「別のシステム」だぞ。ユースケース記述から見出すクラスやインター
フェースはシステム内部に現れる、システム自体に関わるものだ。
「ユースケースとアクターとのインターフェース」とはそもそもの粒度が違うだろ。

643 ：仕様書無しさん：2008/06/01(日) 00:26:15

>>642
もちろん粒度は違うさ。
大概はサブシステムかコンポーネントだろ。
だから候補と書いてるのさ。
ただし、それらはその後の詳細化でインタフェースになる可能性十分だけどね。

644 ：仕様書無しさん：2008/06/01(日) 00:27:40

またそうして「誰が読むための記述」つのを無視するわけだ。バカ？

645 ：仕様書無しさん：2008/06/01(日) 00:37:35

誰が読む以前にまず自分が理解できないことには話にならん。
つかユースケース記述は開発者（自分）向けだよな？
まぁアジャイルだと客も巻き込むだろうが。

646 ：仕様書無しさん：2008/06/01(日) 00:38:48

>>639
＞どうしてこの部分を自然文にこだわるのか理解できないね。
俺は、ユースケース記述は技術者でないお客様に見せる物だから、
というのが1つの理由としてあると思ってる。
（ユースケース図とユースケース記述のレビューには
　客の代表を参加させることを推奨してる開発プロセスがある）

あと自身の経験上の話で特に根拠があることではないけど、
図では気付かないけど自然言語にしてみると違和感があるということも
ソコソコある。

647 ：仕様書無しさん：2008/06/01(日) 00:43:32

>>646
こういう話は貴重だね。

> 図では気付かないけど自然言語にしてみると違和感があるということも
> ソコソコある。

確かにそれはあるかもな。妙に納得した。

648 ：仕様書無しさん：2008/06/01(日) 00:55:39

一つ投げとくか。
客は自然言語が一番理解できるのか。
UMLを含む各種図法は客の前には無力なのか。

649 ：仕様書無しさん：2008/06/01(日) 00:58:37

ドラマや映画でいうと、あらすじがユースケース図、脚本がユースケース記述
みたいなもんだな。登場人物同士の相関関係を本当に理解するためには始めから
終わりまで一通り観てみることが重要ということだ。
タイトルと解説文だけ見て全部理解した気になってるのがおじゃば。

650 ：仕様書無しさん：2008/06/01(日) 01:02:46

とても分かりにくい例えだな

651 ：仕様書無しさん：2008/06/01(日) 01:07:00

>>650
分かりにくいと考える前に、「自分の能力を疑ってみる」という思考フィルターを
自分のフィルターチェーンの最初の方に配置することをお薦めする。

652 ：仕様書無しさん：2008/06/01(日) 01:12:45

>>648
専門的な図はそれを知らないと客の方が身構えるからね、率直な意見を引き出せなくなる
可能性がある。
といってもUMLはそこら辺も意識してわかりやすさを重視してるから、うまく説明できれば、
UML図も効果的に使えると思うが。要は使う側の使い方次第では？

653 ：仕様書無しさん：2008/06/01(日) 01:18:24

>651
顧客にもそう言うの？

654 ：仕様書無しさん：2008/06/01(日) 01:22:52

>>653
アホか客に言うわけねぇだろ。
客には「そうですよね、ハハ、すみせん説明下手で。これはつまりですね、...」
と言うに決まってるだろ。常識だろが。

655 ：仕様書無しさん：2008/06/01(日) 01:26:26

UMLだけじゃ不足と考えたんなら、他に何でも使えるものを使え。
別にUMLが他のものを否定する和気でもあるまい。
UML自体がまだ拡張されたり変化していくだろうしな。

656 ：仕様書無しさん：2008/06/01(日) 01:26:54

>>649
650じゃないけどその例えは俺も分からんぞ。
ユースケース図は「システムを形作る概要図です」、
と言った方が伝わるし、
「その概要を文章で」、と言う方が伝わりやすい

657 ：仕様書無しさん：2008/06/01(日) 01:27:47

>>654
説明下手と自覚はしてたんだな

658 ：仕様書無しさん：2008/06/01(日) 01:33:38

>>656 それはそのまんまの説明じゃないか。メタファを使って説明してくれよ。

659 ：仕様書無しさん：2008/06/01(日) 01:38:01

>>658
そのまんまの説明で理解できることに
余計な例えなど必要無いだろ。

660 ：仕様書無しさん：2008/06/01(日) 01:40:34

これはどうだ、
レストランで例えるとメニューがユースケース図。
各料理のレシピがユースケース記述だ。
そして、レシピに沿って料理を作るのがコックこと我々プログラマの役目。
どうだ、これはうまいだろ？

661 ：仕様書無しさん：2008/06/01(日) 01:48:49

フフ、ぐぅのねも出ないようだな...

662 ：仕様書無しさん：2008/06/01(日) 01:50:41

さっきのよりは分かりやすい。
けど、ちょっと聞いていいか？
おまぃのとこの顧客や上役はそんなに物分かり悪いのか？

663 ：仕様書無しさん：2008/06/01(日) 01:58:08

いや、まぁうちの上司は、平日の昼間っから2chで何やら得意気にカキコ
してるような奴なんだが、こいつの物分かりの悪さは尋常じゃないもんで。

664 ：仕様書無しさん：2008/06/01(日) 02:10:25

そりゃ大変だな。
UMLのどこまでを説明するかは各プロジェクトで違うだろうが、
うちはユースケース図、アクティビティ図、コンポーネント図、オブジェクト図まではレビューする。
顧客とこっちの業務範囲とシステム化の認識が一致してるかどうかがキモだしな。
インターフェースとクラスは、やるときはやる程度。

顧客側にもシステム化に参画してもらわんと、成功する可能性は下がるし、
成功に繋げるためには、覚えてもらう必要があることは覚えてもらってる。
それがUMLだったり、システム用語だったり、その他だったり。

665 ：仕様書無しさん：2008/06/01(日) 11:53:06

このスレ、土日にレベルがアップしているような気がするのだが気のせい？

666 ：仕様書無しさん：2008/06/01(日) 11:59:58

>>648
客の前じゃUMLは無力だ。UMLは見栄えが悪いからね。お客用には
アレンジした図を見せることにしている。

667 ：仕様書無しさん：2008/06/01(日) 12:20:19

客がシステムに疎い素人の場合は、レビューをお願いするのはユースケース図と
ユースケース記述程度だろうな。
見栄えを気にするような相手にはそもそもシステム的な話が通じない場合が多い
から、適当に営業に作らせる。

668 ：仕様書無しさん：2008/06/01(日) 12:24:49

>>639
>それに対して、ユースケース記述はユースケースの振る舞いを
> 記述したものだから、これはシステムの機能を記述したもの
>といえるわけで、半分設計の範疇だろう。

ユースケースは、複数の段階がある。
ユースケース定義->ユースケース分析->ユースケース設計->・・・
つまり、あなたの言ってるのは、ユースケース設計にあたる。

ユースケース記述とユースケースの実現を混同している人が多いが
間違い。おれも何年もユースケース記述は全て分析・設計の範疇だと
思っていた。でも違った。

システムは、分析・設計後、サブシステムやクラスに分解される。
ユースケース定義では、システムを分解しない。つまり、要求定義の段階の
ユースケース記述の中に、出てきても良いのは以下のみ。
・システム自体
・システムに入出力されるオブジェクト
・アクター
つまり、主語は常に「システム」か「アクター」になる。

自然言語にこだわるのは、ユースケース定義だからだ。
まだ、分析・設計は始まっていない。

669 ：仕様書無しさん：2008/06/01(日) 12:32:59

ユースケーススライスという視点のことだな。
要求、分析、設計、実装、配置・・・すべての開発成果物を
ユースケース単位で管理するという考え方だな。

アクターの要求が、分析・分析のどの個所に反映されたのか？
アクターの要求が、実装のどの部分に関係しているのか？
をトレースできるようにするわけだ。

ユースケース単位で作業分担して分析・設計をして後で整合性を取る
ってのはチーム開発で有効だ。つまり、ユースケース分析・設計だ。
ユースケース分析・設計時にもユースケース記述を使うことができるけど
まぁ、普通はしないな。なぜかって。分析・設計は技術者がやるから
複雑なクラス図とか書いても誰も文句言わないしね。

670 ：668：2008/06/01(日) 12:34:57

誤：ユースケース記述とユースケースの実現を混同している人が多いが間違い。
正：ユースケース定義とユースケース設計（実現）を混同している人が多いが間違い。

671 ：仕様書無しさん：2008/06/01(日) 13:10:13

ユースケース図からいきなりクラス図を書けと言ってるおじゃばは
見当違いも甚だしいというわけですね。わかります。

672 ：仕様書無しさん：2008/06/01(日) 13:33:52

おじゃばはたかだかコーダくらいの実務経験(笑)しかよりどころがないから、
なんでもすぐコーディングしたがる。要求をまとめたりとかまでしたことないんだろ。
やったことしか理解できない奴というのはいるもんだ。

673 ：仕様書無しさん：2008/06/01(日) 16:43:14

ソフト開発の難しさの根本原因は、「要求定義」にある。
次から次へと新しいパラダイムが
生まれるのは、「要求の肥大化」が原因だ。

674 ：仕様書無しさん：2008/06/01(日) 16:45:10

えっ！そんなに生まれてるの！？

675 ：仕様書無しさん：2008/06/01(日) 16:45:41

図からソースコードを自動的に生成する話は昔からあるが、
「UMLの図の表現力」と「プログラミング言語の表現力の格差」を考えれば
無理だとわかるだろ。

さらに、自然言語の表現力は、プログラミング言語の表現力を凌ぐ。
情報量だけで考えると、要求定義から実装までの流れが
[曖昧な自然言語]->[図のみ]->[コード]
の順なら図のところで情報が欠落するだろ。

だから

[曖昧な自然言語]->[規則をもった自然言語＋図]->[コード]
となるわけ。

自然言語、図、表をうまく使い分けるのが賢いやり方だ。

676 ：仕様書無しさん：2008/06/01(日) 17:10:51

>>674
「プログラミングパラダイム」
でググればいい。いっぱいある。

677 ：仕様書無しさん：2008/06/01(日) 17:47:10

プログラミングパラダイムをググりながら気がつけば
エロエロパラダイスをググっている俺はどうせ負け組。

678 ：仕様書無しさん：2008/06/01(日) 17:53:09

プログラミングパラダイムとエロエロパラダイスの検索結果約 179 件中 1 - 10 件目 (0.49 秒)

679 ：仕様書無しさん：2008/06/01(日) 19:27:44

プログラミングパラダイスの検索結果約 85,600 件中 1 - 10 件目 (0.23 秒)
マジでパラダイスと書いてたのがあってﾜﾗﾀ

680 ：仕様書無しさん：2008/06/01(日) 19:35:58

しかもそれが政府の資料で、第５世代コンピュータの記述なのがさらに笑えた。
まさにパラダイスだな。
>ttp://www.meti.go.jp/policy/tech_evaluation/e00/03/h13/103.pdf
の、書類上の129ページ下段な。
新しいパラダイムとやらの墓場のような書類だ。笑えるぞ。

681 ：680：2008/06/01(日) 19:48:02

連投スマソ。同じ書類の151ページに、オブジェクト指向のことも出てくる。
次はコンポーネント指向だとさｗ
おい、おじゃば、この資料平成14年時点で作られてるから、
５年前で時間が止まってるお前にはわかりやすくてちょうどいいんじゃないか？

682 ：仕様書無しさん：2008/06/01(日) 20:23:10

いくらプログラミングのパラダイムは変わろうとも、人間の思考のパラダイムは
そうそう変えられるもんではないわな。ましてや素人同然のなんちゃんて技術者
が蔓延るこの業界ではなおさら。格差社会はこの業界にも確実に広がっている。

683 ：仕様書無しさん：2008/06/01(日) 20:36:13

オブジェクト指向分析というのがよく分からない
↓
次の段階として、オブジェクト指向設計というのもよく分からない

ＵＭＬは単なる図法であって、オブジェクト指向分析・設計の本質でないと言われても、どこから取り掛かれば良いのか？
糸口が分かりません。＞＜
メジャーな定番本を読破することから始めてみたら良いでしょうか？

最近はモデリングというキーワードでGoogle検索して、ヒットしたサイトを読んだりしてます。＾＾

684 ：仕様書無しさん：2008/06/01(日) 21:23:33

オブジェクト指向における分析と設計の間に明確な違いがあるわけではない。
「よっしゃーソースコード書けるぜ」と思った時が設計の終わりだと思えば良い。

結局作りたいものは「ソフトウェアシステム」オブジェクト指向で言えば
最大粒度のオブジェクトだ。そして、アクターとソフトウェアシステムとの
やりとり（ユースケース記述）は、どんなパラダイムでも同じものだ。
ユースケースは、システムをオブジェクトとして考えると操作にあたる。
つまり、メンバ関数みたいなものだ。（ユースケース記述は、関数の
定義にあたる。この段階で、システムよりも粒度のクラスは出てこない。）

そういう意味で、ユースケース記述はオブジェクト指向特有のものではない。
ユースケースはパラダイム非依存だ。（強いて言うなら関数指向、構造化）

だが、パラダイムによりその後の分析が違ってくる。
構造化なら、ユースケース（関数？）をさらに分解して、サブルーチンに
分ける。

オブジェクト指向なら、システムをサブシステムやオブジェクトに分けて
各オブジェクトに「責務」つまり役割を与える。要求定義時のユースケース
記述の各ステップは、オブジェクトの操作になる。

で、ユースケース記述を追っていくと、システム内のオブジェクトが
コミュニケーションして仕事をやってるような感じになる。

685 ：仕様書無しさん：2008/06/01(日) 21:37:13

>683
要は手順を知りたいってことだろ？
おおざっぱにはこんな感じ
１．業務を聞きだして、ロールとアクティビティからアクティビティ図を作成、
２．誰が何をどうするのか、ってとこからシステムの境界を導き出す＝ユースケース図
　　（アクティビティ図とユースケース図は同時っぽくてもいんじゃね？お好みで）
３．ユースケース図からコンポーネントの抽出
　　「商品を客に貸し出す」ってユースケースなら、商品管理とか顧客管理とか在庫管理とかがコンポーネント
４．コンポーネント間やアクターとコンポーネント間をコラボレーション図で表わす
　　「在庫を確認する」ってのなら、インターフェースが「在庫を確認する」で、
　　アクターが客とか店員とかで、コンポーネントが在庫管理
　　インターフェースが出てくるのがここ
５．ビールがおいしい季節になってきたのでもう一杯飲む
６．がんがれ

>684
ユースケース記述が関数の定義ってのは違うだろ

686 ：仕様書無しさん：2008/06/01(日) 21:48:53

>>684
日本語でおｋ＞＜

687 ：仕様書無しさん：2008/06/01(日) 21:49:24

>>685の手順ではクラスが一個もでてこないんだな。
アクターとコンポーネントとインターフェースだけかい。
これじゃブラックボックスだらけで作れんわ。

688 ：仕様書無しさん：2008/06/01(日) 22:03:28

>>687
途中で止めてるのぐらい分かってくれよ
２ちゃんよりテレビ優先なんだわ
じゃあ、５以降をざっと書くわ
５．コンポーネントの内部仕様からオブジェクト図を作成
６．オブジェクト図だけだとコンポーネントの構造が分かりにくいので、ここでクラス図を作成
これでコンポーネントの仕様がほぼ分かるでしょ
これが、コンポーネントの仕様（インターフェース）とその内部情報（クラス）を確定させる
７．パッケージ図でそれを表現するけど、テレビ始まったから止める

689 ：仕様書無しさん：2008/06/01(日) 22:09:13

テレビ好きに萌え＞＜

690 ：仕様書無しさん：2008/06/01(日) 22:26:19

>> 688
おまいの独自手順らしいが、コンポーネントのインターフェースはいいとして、
クラスのインターフェースは何を基準にどうやって決めるつもりなんだ。

691 ：仕様書無しさん：2008/06/01(日) 22:31:55

つか、>>688の3.のユースケース図からいきなりコンポーネントって
感性とかひらめきでやるのか？標準手順としては無茶すぎだろ。

692 ：仕様書無しさん：2008/06/01(日) 22:34:28

おまいらまさか、各フェーズを一発で決めてんの？
設計なんて、スパイラルだろ。手順なんて好きにやれよ。
結果は、色んな図面が出来上がってる事さ。

693 ：684：2008/06/01(日) 22:34:58

うちの場合
1. ユースケースの洗い出し
必要に応じてアクティビティ図を書いて業務を整理する。
2. ユースケース定義
ユースケースごとにユースケース記述作成
ユースケース記述を図示する場合、アクティビティ図か
アクターとシステムしか登場しないシーケンス図で表現する。
3. ユースケース分析
ユースケース記述のステップから似たような仕事をまとめて責務とする。
責務を担当するものとしてクラスやサブシステムを定義する。
ユースケース記述の各ステップをクラスやサブシステムに分配する。
4. サブシステム開発
Step 3. で定義したものがサブシステムなら、サブシステム
に対して、Step 1 からやればいい。この場合、サブシステムに分配された
システムレベルのユースケース記述のステップがユースケースになる。
これを繰り返すと粒度がだんだん小さくなってくる。
（ここで、ユースケースとユースケースの実現がネスト関係になり
ややこしい。ユースケース記述は、サブジェクトが何であるか
を見失わないのがコツ）
5. ユースケース設計(必要なら）
4. で、クラスの粒度が細かくなってきたら次は、メカニズムを実現する
クラスを参加させる。メカニズムとは、データベースアクセスや
画面表示系などの既存のクラスライブラリのこと。
ただ、ここまでしなくてもコードが書けるなら書いちゃうけどね。

>ユースケース記述が関数の定義ってのは違うだろ
なぜですか？理由が聞いてみたいです。

694 ：684：2008/06/01(日) 22:42:06

ユースケース分析・設計はユースケース毎に作業を行う。
なので、システム全体がどうなるのかはそのままでは見えない。

なので、適当なタイミングでユースケース分析・設計の成果物（クラス図）
をマージして、整合性をとる。マージは実際にはツールがやってくれるので
、開発者は、マージ結果をみておかしくないか検討する。

695 ：仕様書無しさん：2008/06/01(日) 22:50:16

自演乙

696 ：仕様書無しさん：2008/06/01(日) 22:56:32

自演ちゃうわハゲ

697 ：仕様書無しさん：2008/06/01(日) 22:59:02

でさ、本当は、設計と実装と評価も区別無くスパイラルで開発出来ればいいのにね。

698 ：仕様書無しさん：2008/06/01(日) 23:10:01

>>696
誰に言っているのか分からんのに
何で怒っているんだ、思い当たる事でも？

699 ：仕様書無しさん：2008/06/01(日) 23:24:07

テレビ終了　レスあったんで回答ね
>690
クラスのインターフェース＝コンポーネントのインターフェース　でいんじゃね？
粒度はあるけど、基本線は同じでしょ
ぶれちゃうと何のためのOOか分からんし

>691
あー、すまん　アクティビティ図抜けてた　ビール飲んでたんで
コンポーネントはユースケース図と「アクティビティ図」からね
おおざっぱに書いたんで申し訳
ただコラボレーションが先に分かる場合とかは、状況次第とかあるかも
特にプロトタイプ見せる場合とかはそうなるんじゃね？

>693
なんかユースケースシリーズのオンパレードだけど、他のUMLは書かないの？
ユースケースが関数の定義じゃないってのは、
コンポーネントが不定なんだからインターフェースもよく分からんじゃん
なのに関数が決まるってのは違和感あるんよね
もしかしたら3のユースケース分析から責務を抽出するまでの間（シナリオとか）をはしょって書いてる？
うちはユースケース図の粒度って考え方がほぼ無いんで

700 ：仕様書無しさん：2008/06/02(月) 00:58:52

持論を展開するのはいいが、持論だということはあらかじめ断っとけよ。
一般的な考えからすると間違いだらけだが、初心者は勘違いする可能性があるからな。

701 ：仕様書無しさん：2008/06/02(月) 01:50:04

持論というよりごくごく標準的なOO分析の手順だと思うが。
省略されてあるところはテレビに気を取られてたんだろｗ
ユースケースだけでなんでもかんでもやろうとする693の方は無理があるし、
>>697で誰かが書いてあるOOの利点に忠実なのは>>685の方だと思うが。
時間がかかる手順ってのはネックだがそれがOOだしな。
お前の言う一般的な考えってのを書いてみろよ。
つうか、お前おじゃばか？

702 ：仕様書無しさん：2008/06/02(月) 09:12:22

＞なんかユースケースシリーズのオンパレードだけど、他のUMLは書かないの？
とか
＞ユースケースだけでなんでもかんでもやろうとする693の方は無理があるし、
とか

>>693の「ユースケース～～」てのは、ユースケース駆動の開発プロセスの(特にRUPの)
工程を指す用語でしょ。一般的な話だと思う。

詳細は色々あるだろうけど、ユースケース分析でドメインクラス図描いたり、
ユースケース設計でシーケンス図描いたりりするのであって、
ユースケース図だけで何でもかんでもするわけじゃ無い。
(>>701の「ユースケースだけでなんでも～～」ってのが
　開発の中心にユースケースを置くこと自体に否定的だということなら、
　まぁそれはそれで議論の余地はありそうだけども)
ユースケースモデルが開発の中心にあるから、こういう名前になってるだけかな。

>>685も>>693も、プロセスの差はあれ、どっちが間違えてるとかは思わなかったけど。

703 ：683：2008/06/02(月) 10:38:56

>>684-702
なるほど！
こんな風にしてUMLが活用されてるんですね！
Google検索するときの参考になります。メモメモっと＾＾

704 ：仕様書無しさん：2008/06/02(月) 15:28:34

システムを作りたいという目的がはっきりしているのであれば何をしないといけないかなんて見えてくるだろ。
そのプロセスがすべてのプロジェクトや人で共通なわけが無いのに、それが決まってないと開発できないとほざくボケばっかりだから大変だよなぁ

705 ：仕様書無しさん：2008/06/02(月) 19:24:15

土日になると、レベルが落ちると思うのは俺だけ？

706 ：仕様書無しさん：2008/06/02(月) 19:28:37

釣り乙。

707 ：仕様書無しさん：2008/06/02(月) 19:34:14

俺は７０５じゃないが、確かにレベルが落ちると言うかOOじゃない

708 ：仕様書無しさん：2008/06/02(月) 19:46:37

自演乙。

709 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/02(月) 19:50:03

>>540
長時間のダウンが許されないサービスでは、自宅でのサーバ管理は難しい。
そうなると普通は回線使用料やラックの使用料などかかる。
またHPや掲示板、ブログをやるなら、無料サーバの方が効率がいい。
まあサーバ公開の練習には、自宅サーバはいいかもしれないが。
あと一応、忠告しておくが、
ドメインやIPを晒すのはよくない。個人情報がばれる可能性がある。
あと、サーバのOS、WEBサーバの種類やバージョンを晒すのもよくない。侵入される危険性が増える。

>>552
実際にシステムが大変更になったら、営業的に金を取れるから問題ないと言う考え方はまさにその通りで、
それはそれでいいと思うが、別の話だ。優秀な営業なら修正量に係わらず金を取れるだろうから。
まあファイルからソケットの修正は現実的ではないが、DBやWEBサービスへの変更なら十分考えられる。
それで設計をサボった罰だと言うのは別に構わないが、それがどうにかならないかと言うのが
プログラミング工学だろう。
俺は構造化が無駄だと言っている訳ではない。構造化とOOの違いを言っているだけで、例えば変更の
少ないシステムを作るなら、構造化の方が効率がいいと前から言っている。
まあ552も構造化はそういう物だと言っているだけと言う話なので、それなら何も異論はない。

710 ： ◆ZnBI2EKkq. ：2008/06/02(月) 20:07:34

>>709
>パンツを右から穿くか、左から穿くかでいつも悩む
>そうしていると時間になって、急いで穿くと
>左の穴に右の足を入れてしまう。
>すると右の穴に左の足が入って
>なぜかパンツの前後がさかしまになっているんだ。
>ションベンがしたくてもちんぽこ取り出せなくて困る。助けてくれ。

まで読んだ

711 ：仕様書無しさん：2008/06/02(月) 20:12:19

>>709
＞まあ552も構造化はそういう物だと言っているだけと言う話なので、

そんな話は言って無い。
話を戻すと>>219の下のコードは構造化されて無い、と最初からずっと言ってるだけ。

712 ：仕様書無しさん：2008/06/02(月) 20:21:04

個人の主張を垂れ流すblog程度がダウンが許されないサービスなのか。へぇ。

713 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/02(月) 20:23:44

>>554
ORACLEからPostgresに変えてくれと言う要望なんて良くある。
以前はSolarisやHP-UXからLinuxに変えてくれなども、頻繁にあった。
それによって、ミドルが大幅に変わったりする。
また試作品などは営業的な問題で、出来るだけ多くのOSやDBに対応してくれなどの要望もある。
経験あるPG？554が？
つーか、555にも言われてるな。

>>557
悪かったな、ベテランみたいな事を言っていたので勘違いした。3年目ぐらいかな。なら仕方がない。
まあ自分なりの意見は持っているようだから、一度、基本情報処理の試験勉強をしてみるといい。
自分が無意識のうちに設計していた事が、実は体系化されていることに気が付くだろう。
はっきり言うと、基礎が出来てないので557はOOもUMLも誤解している。
基本情報処理を身につけた後で、もう一度OOやUMLをやれば、本当の意味が分かるはずだ。
あと実践も足りないようだな。俺の指定した条件でDVDレンタルを設計出来ないようでは役に立たないぞ。

714 ： ◆ZnBI2EKkq. ：2008/06/02(月) 20:27:39

>あと実践も足りないようだな。俺の指定した条件でDVDレンタルを設計出来ないようでは役に立たないぞ。
おじゃばの股間にぶら下がっているしなびたアクセサリーもな

715 ：仕様書無しさん：2008/06/02(月) 20:33:31

＞3年目ぐらいかな。なら仕方がない。

いちいちこういうくだらんことを書くから信憑性をなくす

716 ： ◆taAZ7oPCCM ：2008/06/02(月) 20:42:02

>>715
心理的に相手より優位に立とうとして発言するから、否定的な言葉になってる
本当におじゃばはよく吠えるよね

717 ：仕様書無しさん：2008/06/02(月) 20:47:23

おじゃばさんの条件が指定されたDVDレンタルってどこにありますか？

718 ：仕様書無しさん：2008/06/02(月) 20:52:52

>> ◆ZnBI2EKkq.

OOの話とはズレちまってスレ違いだとは思うが
HP拝見しましたがあなたが作ったC# の NumericTextBoxはダメだね

719 ：仕様書無しさん：2008/06/02(月) 22:30:16

>713
読んでやれって

　　↓

> 変わる可能性があるなら非OOでもそういう前提で実装するし

720 ：仕様書無しさん：2008/06/02(月) 22:34:14

OracleとかPostgreができることが
ベテランの証なのですね、わかります。

721 ：684：2008/06/02(月) 22:45:11

>>702
おっしゃる通りベースはRUPです。
ただ、実務では、要求定義に重点を置く開発プロセスを実践している。
「テスト可能なユースケース」を実践するためにね。
早期にテストチームに参加してもらうためにそうしてる。
クラス図を読めるテスターがいないもんで。

ユースケース図で開発を進めていると誤解している人に補足だけど。
ユースケース設計といってもユースケース図ではなくて、ユースケースという
単位で管理された「クラス図やシーケンス図」。ユースケースに参加する
クラスについていろいろ考えるわけ。

オブジェクト指向は、システムをオブジェクトに分解するわけだが、
大きなシステムだと大量のクラスが出てきてしまい管理する必要がある。
サブシステム、レイヤー、ユースケースなどのプレースフォルダーを
利用して整理するんよ。

722 ：仕様書無しさん：2008/06/02(月) 22:51:48

placeHolderじゃないの？

723 ：仕様書無しさん：2008/06/02(月) 22:57:23

>>713
変更が多いと分かっているんなら、何指向だろうとそれに備えるだろうってんだコンチキショー
その中で、OOが有利と言ってるんだから、その根拠を示せば良いのに、「構造化の場合」といって出している先のコードの例じゃ比較にならん。
ちゃんと変更に備えた構造化で、それを凌ぐ変更の容易さを示さないと..

724 ：684：2008/06/02(月) 23:04:17

>>699
>ユースケースが関数の定義じゃないってのは、
>コンポーネントが不定なんだからインターフェースもよく分からんじゃん
>なのに関数が決まるってのは違和感あるんよね
「コンポーネント」という用語に引っかかってしまう。「サブシステム」
の事じゃないの？
まぁ、いいや。
オブジェクト指向設計を始める前、システムは一つの塊でしょ。
「システム」をオブジェクト（コンポーネント、サブシステム）として
考えて、ると「ユースケース」は関数となるわけ。

ちなみに、「システム（サブシステム）」は、外部の世界に対しては
「クラス」として振る舞い、内部に対しては「パッケージ」としてふるまう。
つまり、開発対象のシステム（サブジェクト）には、メンバ関数を持たせる
事が出来る。今開発しているシステムも、実は、大きなシステムの
サブシステムである場合も多い。

>もしかしたら3のユースケース分析から責務を抽出するまでの間（シナリオとか）をはしょって書いてる？
>うちはユースケース図の粒度って考え方がほぼ無いんで

725 ：仕様書無しさん：2008/06/02(月) 23:05:57

>>684
>「よっしゃーソースコード書けるぜ」と思った時が設計の終わりだと思えば良い。
>>721
>おっしゃる通りベースはRUPです。
RUPって分かってる？、ほんと土日はレベルが悪すぎる

726 ：684：2008/06/02(月) 23:28:25

>>725
抽象的な言い方でなくて何がどうおかしいのか指摘してもらわないとね。
教科書通りのRUPは、8年程前に Rational で高い金払ってお勉強したよ。
Rational のトレーナーは、分析レベルまでがちょうどコストパフォーマンス
が高いと言ってたけどね。
RUPも改定されてるから最新版はしらないけど・・・。

あなたの理解しているRUPについて語ってほしいんだけど・・・。できる？

727 ：仕様書無しさん：2008/06/02(月) 23:29:14

それをいうならレベルが低すぎだろ。
日本語すら怪しい奴が何言ってやがる。

728 ：仕様書無しさん：2008/06/02(月) 23:34:18

おじゃばが、開発プロセスやUMLの議論についていけない件について。

729 ：祐介：2008/06/02(月) 23:41:27

ユースケがどうしたって？

730 ：725：2008/06/03(火) 00:03:42

>>726,727
説明も何も、高い料金払って何を勉強したんだ？
なんでRUPと言う名前がついているのか分かっていないのか？そのがRUPの基礎だぞ
>「よっしゃーソースコード書けるぜ」と思った時が設計の終わりだと思えば良い。

731 ：725：2008/06/03(火) 00:05:14

×そのがRUPの基礎だぞ
○それがRUPの基礎だぞ

732 ：仕様書無しさん：2008/06/03(火) 00:07:22

アホ全開だな

733 ：仕様書無しさん：2008/06/03(火) 00:09:13

うっぷん溜まってるのね。
725の能力を生かせる会社に入るべきだと
おもうけど。

734 ：725：2008/06/03(火) 00:12:15

誹謗は良いが、俺が言っているRUPを理解出来たのか？

735 ：仕様書無しさん：2008/06/03(火) 00:21:20

ふうん、おじゃばって基礎情報処理までしか取れてないんだ。

736 ：仕様書無しさん：2008/06/03(火) 00:23:49

>>730
>なんでRUPと言う名前がついているのか分かっていないのか？

>>726-727　じゃないけど、

RUP （Rational Unified Process）
ラップ / ラショナル統一プロセス
ttp://www.atmarkit.co.jp/aig/04biz/rup.html

まー内容はともかくとして（おれは知らん）、名前の由来は単にラショナル社が作ったプロセスってだけじゃないのか？
上のページには「ユースケース単位に構築」とか書いてあるし、ユースケースという用語が多用されていることには違和感はなかった。
実際にはユースケース◯○って工程のなかでUMLの各種図を書いたりするんだろ？

737 ：725：2008/06/03(火) 00:44:37

ネットで検索するれば、分かるだろう
名前はRational　UPで「Unified Process」と言う事だ、これが一番大事なところなんだが
>「よっしゃーソースコード書けるぜ」と思った時が設計の終わりだと思えば良い。
まったくRUPを理解してないように見える

>>736
UP(Unified Process)の方で調べれば分かる

738 ：仕様書無しさん：2008/06/03(火) 00:50:13

コードが書けるかどうかなんて関係無い。
客先に出せるだけの量ともっともらしさだけが要求されるのさ。

まあ、たいていはデスマーチになるんだけどね。

739 ：仕様書無しさん：2008/06/03(火) 01:02:55

>>737
思わせぶりな書き方をしないで、UPは反復開発が基礎だから
>「よっしゃーソースコード書けるぜ」と思った時が設計の終わりだと思えば良い。
はちがうんじゃないの？くらいに言えばいいのに。
それだって１回の反復の話だと思って読めば間違いでもないだろ？
人のレベルうんぬんったって理解はされんぞ。

740 ：725：2008/06/03(火) 07:47:22

>>739
>思わせぶりな書き方をしないで、UPは反復開発が基礎だから
>>「よっしゃーソースコード書けるぜ」と思った時が設計の終わりだと思えば良い。
>はちがうんじゃないの？くらいに言えばいいのに。
俺が説明しても信用しないだろう、それに短い行数で全てを説明出来ない
だから、自分で調べた方が良い。

それにしても、俺の周りの技術者でUPを知らない奴はほとんどいない、特にRUPを知っていてUPが何かを
知らない奴なんて見たことないが

>それだって１回の反復の話だと思って読めば間違いでもないだろ？
間違いだ、反復型開発での反復計画の重要性・計画性が分かっていない
金を払って教えてもらっているのに、RUPの肝であるUPを教えてくれないのは、詐欺に近いぞ

741 ：仕様書無しさん：2008/06/03(火) 08:02:15

文句を垂れ流してるだけの平日がレベルが高いんですね。
分かります。

742 ：仕様書無しさん：2008/06/03(火) 08:28:15

>740
わかったわかった
俺はすごいんだもっと尊敬しろってことね
そんなのはチラシ裏にでも書いとけ

743 ：仕様書無しさん：2008/06/03(火) 08:50:34

おじゃばといい>740といい、そんなにしてまで人より偉いと思われたいのかね。
まったく逆効果なんだけどね。

744 ：仕様書無しさん：2008/06/03(火) 09:04:15

結局、反復開発がキーワードか？なんで最初からいわねえ？
ホントに解ってたのか？
コレまでにしたレスをちゃんと説明にあてていれば、助かったのに。俺が。

745 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/03(火) 09:46:46

>>570
残念ながら全然ダメだ。実際に仕事でプログラミングをやると、コードのほとんどはエラー処理となる。
入門書で教えるコードは通用しない。そんな本は捨てて、良い先輩を探した方がいい。

>>584
584が本当に分かっているが謎だが、もしそのコードがC++でなくて、デストラクタがないとしたら、
常駐プロセスにおいては致命的な問題がある。中級者レベルの話だが、分かるかな？

746 ：仕様書無しさん：2008/06/03(火) 09:54:05

>>709 ドメインやIPを晒すのはよくない。個人情報がばれる可能性がある。
ドメインやIPを晒すと個人情報がばれるような運用しか出来ないヘタレなのか？

747 ：仕様書無しさん：2008/06/03(火) 10:20:10

>>477なんて実践で使えないレベル

748 ：仕様書無しさん：2008/06/03(火) 10:57:01

おじゃばさま、>219の下をOOにするとこうだということですね、よくわかります。
public static int func() {
　FileInputStream fp = null;
　ObjectInputStream fo =null;
　int ret = 1;
　try {
　　FileInputStream fp = new FileInputStream("hoge.dat");
　　ObjectInputStream fo = new ObjectInputStream(fp);
　　while (true) {
　　　Record rec = (Record)fo.readObject();
　　　....
　　}
　　ret =0;
　} catch (IOException e) {
　} catch (ClassNotFoundException e) {
　} finally {
　　if (fo!=null) fo.close();
　　if (fp!=null) fp.close();
　}
　return ret;
}
当然RecordクラスはSerializableインタフェースが実装されているわけですね。

749 ：748：2008/06/03(火) 11:01:17

あ、いけない。tryの中最初の2行は
　　fp = new FileInputStream("hoge.dat");
　　fo = new ObjectInputStream(fp);
でないとまずいっすね

750 ：仕様書無しさん：2008/06/03(火) 13:08:31

パイプラインパターンで実装されたストリームをファクトリーメソッドパターンで
受け取ればストリームリードのロジックは単純なforeachで固定できる。
ファイルでもネットワークでもデータベースでも関係なし。

751 ： ◆ZnBI2EKkq. ：2008/06/03(火) 14:47:42

>>745
あ～、おじゃばくん。お茶汲みにいつまでかかっとるのかね？
エラー処理の話をしとるようだから、この多重例外処理を張っておくぞ
ttp://jeanne.wankuma.com/tips/csharp/programming/releasecom.html

752 ：仕様書無しさん：2008/06/03(火) 14:58:29

まあ、実装レベルでしか語れないなんて、いつまで経ってもOOが普及しないはずだな。

753 ：仕様書無しさん：2008/06/03(火) 15:05:50

>>751
お～、トラウマサイトじゃないかｗ
マジでCOM参照ウザ！
てか、引数に当たり前みたいな顔してnull要求するCOMは死ねって思うわ。
コンストラクタではnull返せないから、プライベートコンストラクタ定義して
ファクトリーメソッドパターンで自分をnewするとかキモイんじゃボケ！

754 ：仕様書無しさん：2008/06/03(火) 15:12:58

>>753
世間一般とズレてるのは君の方だから安心したまえ。

755 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/03(火) 19:41:31

UMLの歴史を知らない人がいるようだから書いておこう。

UMLはシステムを共通のフォーマットでモデリングすると言う事で始まった。
誰にでも分かりやすい共通のフォーマットで記述出来れば、誰ででも簡単にシステム設計出来て、
さらにそれを実行ファイルに変換出来れば、プログラミングの知識さえ不要と言う夢のプロジェクトだ。
かなりの人と企業が労力と金を掛けて取り組んだが、結局失敗した。歴史に残る大失敗だ。
失敗の原因は、粒度と分かりやすさの問題だ。粒度を高くするとソースコードと同じレベルになり、
誰にでも分かりやすくとはならないし、粒度を低くすると分かりやすくはなるが、有効な情報が少なすぎて
実用的ではなくなる。そして誰にでも丁度いい粒度と言う物は存在しない。
実際に大勢の開発者を集めて意見を聞くと、その人の習熟度や考え方の違いにより、適切と思われる粒度に
大きな違いがあるからだ。UMLに大金を投入して分かった事がある。
それは、「システムが最も適切にモデリングされた物は、ソースコードである。」
笑い話としても使われる有名な言葉だ。

しかし企業が金を出している以上、笑い話では通じない。成果を出す必要がある。
そしてUMLの迷走が始まった。様々な粒度の様々な観点の図や、今まで設計書として使われていた
あまり実用的でない図も追加された。ちなみに実用的な図は企業秘密にもかかわるため、公開されても
差し障りのない物が多く使われた。数を多くすることで形式上だけでも、Unifiedを保とうとした。
結果として、統一モデリングの失敗作に、差し障りのない様々な表が追加された物が出来上がった。

756 ：仕様書無しさん：2008/06/03(火) 19:52:09

要はお前が理解できてないってことだな

757 ：仕様書無しさん：2008/06/03(火) 19:53:23

長文でごまかすしかなくなったのですね。よくわかります。

758 ：仕様書無しさん：2008/06/03(火) 19:57:37

>>755
それが基本情報処理より先を取らない理由ですね。

759 ：仕様書無しさん：2008/06/03(火) 20:04:58

先生ごっこしたい奴はブログでやっとけ
他の連中もバカはほっとけ

それよりも>>684のRUP手法と>>685の業務分析手法の続きをやってほしい
どっちもすごい面白いし勉強になる

760 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/03(火) 20:06:46

問題だらけのUMLだがこれを救ったのがオブジェクト指向だ。
C++やJavaの普及により、継承、例外を使った処理が一般的になりつつあったが、既存のモジュール構成図、
フローチャートやHCPではこれらに対応出来なかった。多くの企業はこれに代わる物を探していた。
そして目をつけたのがUMLだ。
UMLは内容はともかく、多くの企業が研究していた物で、凄いというイメージがある。
しかも様々なフォーマットがあるため、既存の仕様書を少し手直しして、UMLだと言い張ることも出来る。
また、既存の規定がないなら、適当に使えそうなフォーマットを探して使う方が、新たにフォーマットから
作るよりは楽だ。何より規定があってなきがごとしなので、使う方としては自由にできる。
こうしてUMLはオブジェクト指向の設計書として使われる事となった。

761 ：仕様書無しさん：2008/06/03(火) 20:11:13

>>760
>HCP
じじぃ…

762 ：仕様書無しさん：2008/06/03(火) 20:14:56

>>759
今日も自演乙　がんがれ

763 ：仕様書無しさん：2008/06/03(火) 20:24:56

760とWikipediaと読み比べると、
文章一つ一つに細かな間違いがあるような気がするけど、
気のせい？

764 ：仕様書無しさん：2008/06/03(火) 20:26:23

>>762
おじゃばよ
つまらんぞ

765 ：仕様書無しさん：2008/06/03(火) 20:36:30

>>764
今日も簡単に釣られるなｗ
バレバレだぞ自演、がんがれｗｗｗ

766 ：仕様書無しさん：2008/06/03(火) 20:41:02

UMLの歴史　＝　ブーチが政治力で他の流派をぶち殺していく歴史

767 ：仕様書無しさん：2008/06/03(火) 20:48:43

>>764
バカはほっとけ。

768 ：仕様書無しさん：2008/06/03(火) 20:57:22

>>755,760
大嘘書きすぎ

769 ：仕様書無しさん：2008/06/03(火) 20:58:25

UMLのようなツールは必要ない by 坂村

770 ： ◆ZnBI2EKkq. ：2008/06/03(火) 21:04:12

>>755
文字数多くて読めません＞＜

771 ：仕様書無しさん：2008/06/03(火) 21:23:48

>>767
自作自演乙

772 ：仕様書無しさん：2008/06/03(火) 22:11:53

これが平日クオリティ

773 ：仕様書無しさん：2008/06/03(火) 22:14:08

>>755
歴史よりも活用方法が知りたいです。

774 ：仕様書無しさん：2008/06/03(火) 22:21:07

無茶言うなよ
そういうことは相手を見て言え

775 ：仕様書無しさん：2008/06/03(火) 22:27:52

>>755
>>760
間違いと妄想の混じった作り話をいつもと同じ文体で本当のことのように書かないでくれよ

会話ができないを通り越して不気味な感じがする

776 ：仕様書無しさん：2008/06/03(火) 22:33:25

>>755
粒度の高い（大きい？）、低い（小さい？）が逆じゃないか？
つぅか粒度は、粗い、細かいと表現した方が伝わり易いと思うぞ。
日本語ぐらいちゃんと使わないと、ただでさえアホな解説が(Ry

777 ：仕様書無しさん：2008/06/03(火) 22:42:37

いつもの文意を汲み取ってくれるひとはまだか

778 ：仕様書無しさん：2008/06/03(火) 22:53:03

あれ面白いケど、誉めると調子にのってつまらなくなるタイプとみた。

779 ：仕様書無しさん：2008/06/03(火) 23:04:14

>>755
>「システムが最も適切にモデリングされた物は、ソースコードである。」
本当に有名な言葉なのか？　ググっても見つかんねぇぞこのクソ野郎！
おじゃばのその「UMLの歴史」話は、妄想じゃねぇだろうな、ソースぐらい
あるんだろうな？　出典ぐらい書かねぇと説得力ねぇぞこのうんこ野郎！

780 ：684：2008/06/03(火) 23:18:13

すげースレ伸びてるな。
>>725
「よっしゃーソースコード書けるぜ。」なんだけど、
「１回の反復の話だと思って読めば間違いでもないだろ？」
という意味ではないよ。念のため。
厳密に言うと「ユースケース設計の終わり」のことを言ってたんだ。

ユースケースの話だけならこれでいいんだけど、RUPの話になるなら
話が違ってくる。もう一つの重要な要素「アーキテクチャー・セントリック」
の話もしないといけなくなる。
アーキテクチャー（フレームワーク）は、反復開発が適しているので、
「設計の終わり」とかそういうのないんよね。

で、今気がついたけど、ユースケースドリブンの説明を俺がしていて、
アーキテクチャー・セントリックの説明を >>725 がしていたみたいだな。
両方ともRUP/UPでは重要だな。

>間違いだ、反復型開発での反復計画の重要性・計画性が分かっていない
>金を払って教えてもらっているのに、RUPの肝であるUPを
>教えてくれないのは、詐欺に近いぞ
イテレーティブ（反復）開発だけじゃなくて、インクリメンタル開発も
重要だぞ。反復型開発は、万能ではないので、インクリメンタル型を採用
する開発領域だってある。これは経験的に分かってると思う。
基本的には、次のような感じかな。
- アーキテクチャーセントリック -> イテレーティブ
- ユースケース駆動 -> インクリメンタル
実際には、グレーな領域があるので一概には言えないけどね。

781 ：仕様書無しさん：2008/06/03(火) 23:28:55

テーマもまともだし、本人自身も真面目に解説してるつもりなのだろうが、
何故かこれだけの長文から知性のかけらも感じられないのは、不思議だ。
うまく説明できないが、日本語の文章として、言葉の端々になんかこうイラ
イラさせる雰囲気や滲みでるような馬鹿っぽさを感じさせられるのは、これ
も一種の才能といえるのだろうか。

782 ：仕様書無しさん：2008/06/03(火) 23:29:47

↑はおじゃばについてね。

783 ：仕様書無しさん：2008/06/03(火) 23:35:59

大意は間違ってないが、細かな間違いに満ちている。
いや、2chだからってスルーするのが筋だろうなーって思って読んでも、
実に的確に急所の部分が間違っていて結局スルーできない。

2ch補正をかけても掛け値無しの無能の働き者がおじゃば。

現実に一緒に仕事したら、”どうぞ座っていてください。何もしないでください”と言うかな。

784 ：684：2008/06/03(火) 23:48:02

たまにはスレタイに戻るけど

「粒度」なんだけど、この言葉は、オブジェクト指向を余計
ややこしくしている。
たとえば、「粒度」を粒度１～粒度１０と数値で表し、あらゆる
オブジェクトを「粒度」という一次元の基準で分類する事には無理がある。

少なくとも「スコープ」と「レベル」の２次元で考える方がわかりやすい。
スコープは、システムの中のある範囲のことで、UMLだと「サブシステム」
で表現できる。レベルは、どれだけ詳細に記述するかのことで、UMLだと
「レイヤー」で表現できる。
まぁ、粒度と言うと普通は、スコープの方を指す事が多いから間違いでも
ないけどね。

レイヤー分けの有名な事例は、OSI参照モデルね。
サブシステムは、コンポーネントと読み替えてもいいかな。

785 ：仕様書無しさん：2008/06/03(火) 23:51:23

UMLだとサブシステムで表現できる、ってのはそれも言い回しがヘンだろ
何を持ってサブシステムと言うんだ？
結局はユースケースをどれだけ細かくしたかって話か？

786 ：仕様書無しさん：2008/06/03(火) 23:53:17

おじゃばは結局UMLの何がダメだって言ってるの？
ダメだというからには一通り使ってみたんだよね？
だったらUML全般がダメとかじゃなくて、この図は
ここがダメとか、この図はここはいいけどこの場合
に対応しにくいとか、拡張のやり方に問題ありとか
そういう意見の書き方がありそうなもんだと思うけど。
そういう書き方はできないの？
若しくはUMLじゃなくて何を使えばいいと思ってるの？
それとも設計に図なんか入らねぇと思ってるの？
信憑性はともかくUMLの歴史の話なんかしていったい
何を言いたかったの？
そこら辺がよくわからないんだけど、どうなのよ？

787 ：684：2008/06/03(火) 23:57:28

>>783
彼もそのうち間違いに気がつくと思う。
そして、間違いに気づいた後は、爆発的に成長すると思う。

経験豊富な技術者なら、過去に何度も「ブレークスルー」を経験している
と思う。まぁ、それまでは、もがき苦しむんだけどね。

788 ：仕様書無しさん：2008/06/03(火) 23:59:18

思う思うとそう思う

789 ：仕様書無しさん：2008/06/04(水) 00:01:09

>>786
だからな、お前が釣れてな、
雑魚で面白くねえな、
ってこと。
スルーしろバカたれ。

790 ：仕様書無しさん：2008/06/04(水) 00:07:04

稚魚に雑魚呼ばわりされたかねぇ

791 ：684：2008/06/04(水) 00:12:01

>>785
「サブシステム」という言葉は「パッケージのステレオタイプ」という
意味で使っている。

「システム -> サブシステムの集合」
「サブシステム -> クラスの集合」
という風に分解していきます。サブシステムとクラスは、システムの一部です。
サブシステムやクラスは、システムのある範囲（スコープ）を司ります。
これが、スコープによる分解です。

サブシステムやクラスには責務（担当するお仕事）があります。
担当するお仕事についてどこまで細かく記述するのか？が次の分割
のヒントです。会社でも大きな仕事は上司達が、小さな仕事は部下たちが
するでしょ。

サブシステム分解は、コンポーネント、アーキテクチャー、フレームワーク
という概念に成長していくし、レイヤー分解を進めると、層毎にいくつかの
塊にして、クラスライブラリーを作ったりすることになる思う。

792 ：仕様書無しさん：2008/06/04(水) 00:36:59

先生ぶるのはおじゃばだけで十分だ
プロの技術者たちを相手にしてることを忘れるなよ

サブシステムの定義は何だという問いだけに答えればよろしい
余計な例えは必要最小限に留めておけ

OOの責務についてだが、クラスにのみ形成されるんじゃないか？
アクターもコンポーネントの一種だからな
アーキテクチャーうんぬんは別の話だろ

793 ：仕様書無しさん：2008/06/04(水) 01:01:08

>>792
>先生ぶるのはおじゃばだけで十分だ
>プロの技術者たちを相手にしてることを忘れるなよ
こういう文章は要らないと思うんだが。。。

> OOの責務についてだが、クラスにのみ形成されるんじゃないか？
「サブシステム」にも責務を割り当てられる。サブシステムは、
対外部には、「クラス」として振る舞い、内部に対しては、「パッケージ」
として振る舞う。

>アクターもコンポーネントの一種だからな
アクターは、クラスです。コンポーネントではありません。

オブジェクト指向が普及しない理由を一つ見つけた。
「意見が食い違う」→「自分を否定された気持になって気分を害する」
→「議論が白熱して成果なし」→「チームの雰囲気が悪くなる」
→「プロジェクト失敗」

794 ：仕様書無しさん：2008/06/04(水) 01:03:28

>>792
負けると「プロぶる」。先生とかハカセとか言い出す。
おじゃばと思考パターンが似ている。

自演乙。

795 ：仕様書無しさん：2008/06/04(水) 01:03:30

OOするまえに
対象がどんな振る舞いを必要なのか
計算付けないで単に静的OO（糞java化）
させようとするだけ

796 ：仕様書無しさん：2008/06/04(水) 01:08:40

>>784
> 「粒度」なんだけど、この言葉は、オブジェクト指向を余計
並列化の「粒度」を基準に考えればいいんじゃね？
インストラクションレベル
スレッドレベル
プロセスレベル
………
っても、わからんだろうな？
それなりにスケールするもの作ったことないらしいからw

797 ：仕様書無しさん：2008/06/04(水) 01:49:28

アクターがクラス？
めちゃくちゃだな

798 ：仕様書無しさん：2008/06/04(水) 01:51:24

>>745
>入門書をよんでもチンプンカンプンだ。
>先輩に聞いちゃおう！

まで読んだ

ぱくりスマソ。
しかし実際に入門書もちゃんと読んでないんじゃないか。
自分では考えずにすぐ、人に答え出させようとするし...

>>745のレスは二つともズレたところで否定しとるな。

799 ：仕様書無しさん：2008/06/04(水) 02:19:22

>>793
あんたのサブシステムの説明だと、コンポーネントのことを指してるようだが、
しかし、それでは内部・外部の説明が意味不明
あんたの説明にあるパッケージとは何を指してるんだ？
コンポーネントのことでも、そうでなくても、意味がおかしい
コラボレーションの説明がつかんだろ

コンポーネントであれば、
外部とのやりとりがインターフェースとなり、
その責務を持つものがクラスとなるわけじゃん

アクターがクラスとか言いだすに至っては、不勉強としか言いようがない・・・
もうわけわからん

普及しない理由は、あんた自身の不勉強にも一因あると思うけどな

800 ：仕様書無しさん：2008/06/04(水) 02:27:36

>>786
かんたん。自分がわからないからダメだ、と言ってる。
おじゃばはそういう奴。
もう年だからしかたないのかね。

801 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/04(水) 09:43:36

>>773
ユースケース図と言うのは、要求仕様をまとめるために作成する。
つまり要求仕様書をまとめるための物だ。要求仕様と言うのは場合によっては、顧客もはっきりと分かって
ない事もあり、ユースケースを見せながら説明する事で、要求仕様を明らかにする。
内容的には「要求仕様の箇条書き」と変わらない。そこまで聞き出して顧客に認識させるのが目的となる。

次の工程としては、実際は機能設計に入る。作るのは画面仕様書、DB仕様書、外部IF仕様書等だ。
これを作った後に、要求仕様を満たしているかの判定として、ユースケース図使うことになる。
まあ、ユースケース図もとに、大量の図を作成して、機能設計に戻すと言う方法がいいと言うなら
それでも構わないが、本当にやっているのか？少なくともDVDレンタルでは出来なかったようだが。

>>786
使えそうなのは、クラス図、シーケンス図、ユースケース図ぐらいだろう。
クラス図は提出用、シーケンス図は開発者への説明用、ユースケース図は客との打ち合わせ用に使う。
その他の図は詳細設計をやる時に、自分の考えをまとめる時に使えばいいかもしれないが、
人により観点が違うので参考程度にしておいた方がいい。人により善し悪しを感じる部分は事なる。
設計書として作るなら、UMLなんかより、要求仕様（要求仕様書）、機能仕様（画面仕様書、DB仕様書、
外部IF仕様書）、詳細仕様（JavaDoc等）の方が重要だ。モデリングする暇があるならクラスのガワだけ
でも書けと言いたい。
俺が歴史で言いたかったのは、UMLがどういう物か分かってた上で使っているのか？って事だ。

802 ：仕様書無しさん：2008/06/04(水) 12:31:53

UMLが失敗？
お前が失敗してるだけだろ

なんかずれてるよね。おじゃばさん

803 ： ◆ZnBI2EKkq. ：2008/06/04(水) 13:32:52

>>801
>妹が俺を継承したインスタンスを作らせてくれない
>最近となりに引っ越してきたステフは非処女だから論外
>でもほかにかわいこなんていないよなぁ
>そのときたまたま偶然犬が家の前を通りかかったんだ
>ん？犬？犬か…、待てよ
>こうなりゃ選り好みはできないか
>決意を胸に、俺はビーグル犬に踊りかかった

まで読んだ

804 ：仕様書無しさん：2008/06/04(水) 14:06:45

なんか最近　おじゃば　よりさらにウザイ小蠅が飛んでるなｗ
スルー力が試されてるんだろうか…

805 ：仕様書無しさん：2008/06/04(水) 14:13:15

DVDレンタルをよほど誇らしく思ってるらしい。幸せなやっちゃ。
要求仕様を何もまとめないで作り出すのは変だ、のところで終わってるのに
おじゃばと393の馬鹿ふたりがさわいだだけじゃねーか。
ところで、おじゃばがさかんに勝負したがってるハカセってあの393なのかな？

806 ：仕様書無しさん：2008/06/04(水) 14:47:15

どうなんだろね、俺はとっくにNGしちゃったから

807 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/04(水) 17:31:00

>>805
そうやって自分に言い訳してプライドを保っているのか。
そして心の中で「自分はやれば出来る子」と唱え続けるのかな。くだらん。

808 ：仕様書無しさん：2008/06/04(水) 17:45:24

>>1よ、お前の言うことが理解できない。

今はもう2008年だぞ。
Javaのフレームワークが乱立し、
Ajaxでもオブジェクト指向を使ったフレームワークが導入され、
どこへいってもオブジェクト指向しかない。

どうみたってオブジェクト指向は普及しているではないか？
もうこのスレは消えていると思ったがスレが10まで続くとは予想外だ。

809 ：仕様書無しさん：2008/06/04(水) 17:50:38

底辺のマがな、高い山の裾野の辺りでチョロチョロとやってるスレがここさ。

810 ：仕様書無しさん：2008/06/04(水) 19:31:33

>>801
＞俺が歴史で言いたかったのは、UMLがどういう物か分かってた上で使っているのか？って事だ。

UMLは、オブジェクト指向の黎明期に、乱立しつつあるオブジェクト指向開発プロセスにおいて
それぞれ独自に発展していたモデリング記法を統一する目的で作られた物。

それはともかく、モデリングしてる暇あったらどーたらと言ってるけど、
つまりおじゃばは、他の開発手法でもモデリングはしないということか？
例えばER図やDFD、モジュール構成図や状態遷移図は重要でない、と。
そんなもの書いている暇があったら、関数のプロトタイプ宣言だけでも書いて来い、
とそういうことだな？

811 ：仕様書無しさん：2008/06/04(水) 20:11:26

>俺が歴史で言いたかったのは、UMLがどういう物か分かってた上で使っているのか？って事だ。

マじゃなくても説明の前か後かにそういった説明を入れる。
おじゃば、えらそうに空虚な事を言った後に押し付けが撒くセコイ説明を入れる。
お前はいつも後だしじゃんけんの卑怯者だ。

812 ： ◆ZnBI2EKkq. ：2008/06/04(水) 20:51:18

>>807
>俺の輝かしい経歴をここに記す
>18歳　高等学校を卒業し、I社でSEとしてOOを使ったソフトウェア設計に従事する
>31歳　若くしてロスアラモス国立研究所に客員研究者として招聘される
>40歳　ベル研究所で遅延評価の研究チームに加わる
>6X歳　マイクロソフトからJava.netのエバンジェリストに認定される　←今ここ

まで読んだ

813 ：仕様書無しさん：2008/06/04(水) 20:57:21

おじゃばが無能で厚顔無恥で救いようが無い最低の性格なのは
今に始まったことじゃない
それでもおまいらは正しいことを教えてやろうとする

おじゃばごときゴミの相手するよりも、
自分のために時間を使った方がいいんジャマイカ？

間違ったことを正したくなるのも分からんでもないが、
相手は正真正銘の変質者だぞ

814 ：仕様書無しさん：2008/06/04(水) 20:57:24

>>812
訴えられるぞ

815 ：仕様書無しさん：2008/06/04(水) 21:07:07

研究所に

816 ：仕様書無しさん：2008/06/04(水) 23:16:29

2chみたいな匿名掲示板でプライドとか勇気があるとか何言ってんの？
いくら糞ソース晒して赤っ恥さらそうが、偉そうなこと書こうが匿名掲示板だぜ、
脳内で悪に立ち向かうヒーロー気取ってんのか知らんけど、何か根本的なところで
勘違いしてるよね、おじゃばさまって。もう一回言うけど、匿・名・掲・示・板だぜ。
ほれ、俺のちんこ ω ぶら～んぶら～ん

817 ：仕様書無しさん：2008/06/04(水) 23:43:02

>807
お前いつもそうやって自我を保ってるの？

818 ：仕様書無しさん：2008/06/05(木) 00:32:22

たしかにずっとレンタルシステムにこだわってるな。

>>810 おそらく汚邪婆は、そういった名前のついた図は使えないだろう。
下手をすると「箇条書き」さえできないかもしれん。

819 ：仕様書無しさん：2008/06/05(木) 00:39:52

おじゃばさますげぇーって言ってやれば、何か違うこと書いてくれんのかな？

820 ：仕様書無しさん：2008/06/05(木) 01:42:37

このスレを見ている人はこんなスレも見ています。(ver 0.20)
【テンパってるよw】早稲田セミナー梅田校スレ3 [資格全般]
TBS 土8ドラマ『ROOKIES (ルーキーズ)』45球目 [テレビドラマ]
▲　▼　穴専ってどうよ？　▼　▲ 第2章 [先物]

なんの脈絡も無いなｗｗ

821 ：仕様書無しさん：2008/06/05(木) 03:35:34

このスレ、次からはヲチに移動するか？

【元医師】yasuのURAぺーじ【豚切り】
http://pc11.2ch.net/test/read.cgi/net/1211772750/

ジャンルは違えど、こいつと同じ臭いを感じる

822 ：仕様書無しさん：2008/06/05(木) 03:50:30

ヲチするスレじゃないだろｗ

823 ：仕様書無しさん：2008/06/05(木) 12:01:55

このスレ自身がヲチスレみたいなものだしな

824 ： ◆ZnBI2EKkq. ：2008/06/05(木) 15:37:23

>2chみたいな匿名掲示板でプライドとか勇気があるとか何言ってんの？
>いくら糞ソース晒して赤っ恥さらそうが、偉そうなこと書こうが匿名掲示板だぜ、
まったくだ
俺が自宅サーバーやってるのだって口から出任せかもしれんし
大体俺から嘘をとったら何が残るというのだ

825 ：仕様書無しさん：2008/06/05(木) 15:44:04

まあ、いまどき自宅でサーバーって、どんだけ趣味って感じだろ。
趣味でサーバー立てるのなんか、誰でも出来るしなw

826 ：仕様書無しさん：2008/06/05(木) 16:34:12

それもこれもおじゃぱがのたうち回るから

827 ：仕様書無しさん：2008/06/05(木) 18:40:19

>>811
おい、いい加減にこのスレのスレタイの趣旨が時代遅れだと気づかんのかお前は？

828 ：仕様書無しさん：2008/06/07(土) 08:50:31

自演荒らしかよ
ホントに情けない奴だ

829 ：仕様書無しさん：2008/06/09(月) 11:25:56

型理論とか使ってOOを説明した本とかねーの？
ちゃんと計算機科学になってるOOというのが見てみたい！！！

830 ：仕様書無しさん：2008/06/09(月) 19:39:00

市長さんの本でも読んどけば？

831 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/09(月) 20:31:28

>>810
言い方が悪かった。UML書いている暇があったら、クラスのガワだけでも作れ、に訂正する。

>>811
前にも言ったが、後出しと感じる人は、基礎知識が不足しているんだよ。

>>813
だから正しい事って何だよ？

>>816
渾身の設計書出したら、叩かれた上に、ずっといい設計書を出されたら、プライドが傷つくのではないか？

>>818
つーかさ、何で仮にもクラス図まで書いた俺に言う？
途中で挫折した2人や、初期設計すら提示出来ない人はどうなんだ？
第一、俺のUMLの説明を見て、本気で業務で使った事がある人が誰なのか分からない時点でダメだがな。

832 ： ◆ZnBI2EKkq. ：2008/06/09(月) 21:23:45

そんなことはどうでもいい
妹さんは元気か？

833 ：仕様書無しさん：2008/06/09(月) 21:44:22

> ずっといい設計書を出されたら、プライドが傷つくのではないか？

いいこと考えた。
お前、俺のプライドを傷つけるぐらいずっといい設計書作って出せ。

834 ：仕様書無しさん：2008/06/10(火) 00:33:06

>渾身の設計書出したら、叩かれた上に、ずっといい設計書を出されたら、プライドが傷つくのではないか？

？仕事が進んでよいじゃないか。
おじゃば、言語も設計も道具って口先だけか？

強いて言えば、自分の考えさえ道具って割りきらないと逝けないと思うわけだが。

835 ：仕様書無しさん：2008/06/10(火) 03:16:31

お前らどんだけ、おじゃばさまが好きなんだよｗ

OOのメリットとデメリットを列挙すれば終わるだろ、こんなスレ。

836 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/10(火) 09:28:41

>>824
いや経験2-3年目で、自宅サーバでWEBサーバたてるのは、結構やる方だと思うよ。

>>829
俺が論理的で簡単に説明しているだろう。

>>833
在庫管理やDVDレンタルで出しただろう？DVDの方はレンタカーへの拡張も実演した。
まあ、ある程度のスキルがないと、良い設計なのかどうかの判断も出来ないと言う事は分かった。

>>834
何を言っているのか分からない。口先だけって誰の事だ？

837 ：仕様書無しさん：2008/06/10(火) 12:34:26

あんな糞じゃあ俺のプライドはおろかハートにも全く届かないな
非のうちどころのないようなものか
全く新しい発想でつくりあげたものを
出してもらわんとプライドが傷つく(笑)わけない

838 ： ◆ZnBI2EKkq. ：2008/06/10(火) 14:23:18

>>836
おじゃば程度に評価してもらうまでもなく、自分のレベルはそこそこ把握している
そしてそんな無意味なものより妹さんのことのほうがずっと大事だぞ
っておじゃばは老害Ｓヨじゃないか！
その妹がピチピチギャルのわけがないorz
よくもやってくれなたおじゃばあああああ！！！！！！！！！！！！！１！！

839 ：仕様書無しさん：2008/06/10(火) 14:46:46

>>836
自然言語での説明を論理と呼びたくありません
形式言語でお願いします

840 ：仕様書無しさん：2008/06/10(火) 16:46:43

>>836
> いや経験2-3年目で、自宅サーバでWEBサーバたてるのは、結構やる方だと思うよ。

うちの会社のうちの部署では、
「ディスクをきれいさっぱりフォーマットしたマシンに
OS をインストールして、ネットワークに接続する。」
ってのが、新入社員が最初に課せられる作業だったりするんだが…

与えられるマシンは、i386系の PC ではなく SUN や HP のマシンで
なおかつ、Solaris、HP-UX、Linux のインストールは禁止

次にやらされる作業が、dns/mail/web サーバの立ち上げ

この作業を入社後、3ヶ月で達成出来ない場合転属となりますが…

841 ：仕様書無しさん：2008/06/10(火) 16:51:31

freebsdですか

842 ：仕様書無しさん：2008/06/10(火) 17:30:17

>>840
それはいったいどんな「機種」なんだ？教えてくれ

とか帰ってくるからよした方がいいと思うぞ。

843 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/10(火) 17:43:56

>>837
俺の設計の意図が全く伝わってないと言う事は分かったよ。

>>839
クラス図も入れただろう？あれから読み取れ。

>>840
新人教育が面倒なので、古いSUNやHPを渡してOSインストールしとけと言って放置しておいたら、
3カ月後に新人の希望で転属になったって事だろう。
うちの会社のうちの部署？840の下だけって意味だよな？いや840が先輩にやられたって事かな？

844 ：仕様書無しさん：2008/06/10(火) 19:10:38

ここは番号飛びが激しいスレだなぁｗ
変なの。

845 ：仕様書無しさん：2008/06/10(火) 19:21:35

オブジェクト指向はもうみんな一定のレベルで独自に理解してるでよくね？

846 ：仕様書無しさん：2008/06/10(火) 19:36:53

最低でもこのレベルのモデリングはできないとオブジェクト指向が使えるとはいえない

＞365 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2008/04/15(火) 18:50:43
＞次にクラス化。とりあえずクラスと管理する要素を書いて見る。
＞-------------------------------
＞class ショップ{
＞　DVDリスト、料金表
＞}
＞class DVD extends 作品{
＞　シリアル番号、作品番号、入荷日
＞}
＞class 作品{
＞　タイトル、ジャンル、年令制限、発売日、レンタル開始日
＞}
＞class 料金表{
＞　期間、金額
＞}
＞class 会員{
＞　DVDリスト
＞}
＞class 倉庫{
＞　DVDリスト
＞}

847 ：仕様書無しさん：2008/06/10(火) 19:43:07

まとめてデータクラスにしちゃだめ？

848 ：仕様書無しさん：2008/06/10(火) 19:46:02

つうか、データクラスの派生で全部行ける。
でもってオペレーションは共通で行ける。

つうかそもそもオブジェクト指向を分かって無いだろおい。

849 ：仕様書無しさん：2008/06/10(火) 19:47:56

>>843
＞クラス図も入れただろう？あれから読み取れ。
おじゃば、クラス図なんて描いてないじゃん

850 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/10(火) 19:51:47

>>846
それは段階を追って説明するために、データの要素しか記載していない。OOとしてはあまりに不完全だ。
オブジェクト指向が使えると言えるなら、メソッドも記載しないとダメだろう。
DVDレンタルならこのレベルだ。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 商品{シリアル番号、作品番号、入荷日、貸出日：検索()};
class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------

851 ：仕様書無しさん：2008/06/10(火) 19:52:49

> 俺の設計の意図が全く伝わってない

伝わるように書いてから言え
つか君はあの程度で満足なの？

852 ： ◆ZnBI2EKkq. ：2008/06/10(火) 20:33:40

>>850
>俺はエスパーだから、客の要望もエスカレーターの女の下着も
>かかめば何でも見えるよ
>趣味じゃないからどっちもしないけどね
>このスレで恥ずかしいレスするのって最高に楽しいプレイだよ
>ああもっともっと恥ずかしいことしたい～

まで読んだ

853 ：仕様書無しさん：2008/06/10(火) 20:59:47

>>850
おいおい、全部同じメソッドで済ませろよw

854 ：仕様書無しさん：2008/06/10(火) 21:49:50

お前らもバカ相手に暇だなあ

855 ：仕様書無しさん：2008/06/10(火) 21:50:02

>>843
＞クラス図も入れただろう？あれから読み取れ。
どこにクラス図があった？

>>850
おじゃば、それを「クラス図だ」と言い張るなら、
クラスの相関関係はどう表現されているんだ？
（つか、そもそも「図」には見えないが）

お前は前スレだから前々スレだかで、クラス図と言える物を1つでも描いたのか？

856 ：仕様書無しさん：2008/06/10(火) 21:56:00

857 ：仕様書無しさん：2008/06/10(火) 22:05:18

UMLの不利な点をこんな所で露呈してどうすんのw

858 ：仕様書無しさん：2008/06/10(火) 23:47:57

>>850
商品、作品、会員、貸出履歴はグループとメンバーが一緒くたになって
しまっていませんか？

859 ：仕様書無しさん：2008/06/11(水) 08:54:57

秋葉の犯人＝おじゃばかと思った
おじゃばよ
バカで無能で人格最低でいいけど、
人殺しはしちゃだめだぞ
けどちょっとは人の話を聞けるようになるといいかもな

860 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/11(水) 09:14:29

>>849,855
テキストで書いただろう？DVDレンタルをレンタカーに拡張した時の例をつけよう。
それ以前に855はクラス図が何かを勉強する必要があるようだが。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 商品{シリアル番号、カタログ番号、入荷日、貸出日：検索()};
class カタログ{カタログ番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------
class DVDレンタル extends レンタルシステム;
class 作品 extends カタログ{タイトル、ジャンル、年令制限};
-----------------------------------------------------------------------------------------------
class レンタカー extends レンタルシステム;
class 車種 extends カタログ{メーカー、名称、グレード};
class レンタカー料金表 extends 料金表{保険種類};
class レンタカー会員 extends 会員{免許証番号、ゴールド識別};
class レンタカー貸出履歴 extends 貸出履歴{前払い分};
-----------------------------------------------------------------------------------------------

861 ：おじゃばさま ◆62pnJZSi8w ：2008/06/11(水) 09:39:27

>>860は偽者だ。
トリップをのっとられた。
>>860のクラス図を見ればこいつが偽者だとわかるはずだ。
OOがまるでわかっていない。
-----------------------------------------------------------------
-----------------------------------------------------------------
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 商品{シリアル番号、カタログ番号、入荷日、貸出日：検索()};
class カタログ{カタログ番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};

class 作品 extends カタログ{タイトル、ジャンル、年令制限};
class DVDレンタル extends レンタルシステム;

class レンタカー会員 extends 会員{免許証番号、ゴールド識別};
class 車種 extends カタログ{メーカー、名称、グレード};
class レンタカー料金表 extends 料金表{保険種類};
class レンタカー貸出履歴 extends 貸出履歴{前払い分};
class レンタカー extends レンタルシステム;

862 ：仕様書無しさん：2008/06/11(水) 09:51:30

お前らって仲いいな

863 ：仕様書無しさん：2008/06/11(水) 19:11:24

この糞設計で実装させられたら発狂する

864 ：仕様書無しさん：2008/06/11(水) 19:14:34

なぜ、無駄にメソッドを個別に作るのか？？？？？？？

865 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/11(水) 19:24:40

>>851
OOの基礎や利点を説明するために、DVDレンタルの最低限の限定仕様で作るという話だった。
何で、非のうちどころがないとか、全く新しい発想とか、伝わるように書けとか、あの程度で満足かとか
言う話になる？まあこれだけ強気で意味不明となると、最初の方を読んでいないとしか思えないが。

>>853
？

>>858
グループ（集合）か、メンバー（単体）かって意味かな。
それなら、商品、作品、会員、貸出履歴は全てグループだ。

>>861
何がやりたいのだ？どこか変えたのか？

>>864
どれが無駄だって？

866 ：仕様書無しさん：2008/06/11(水) 19:32:54

＞OOの基礎や利点を説明するために、DVDレンタルの最低限の限定仕様で作るという話
その程度のものでどうやってプライドを傷けるかのほうを論理的に詳しく。

867 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/11(水) 19:46:26

>>866
その程度すら出来ないと言う事になれば、プライドが傷つくのではないか？

868 ：仕様書無しさん：2008/06/11(水) 19:53:43

前から何度も言われてるはずだが…
お前の「教えてる」(笑)対象はそのレベルなんだろうが、
実際はお前以上のヤツが大半なことに気付け。
よって傷つくわけがない。

869 ：仕様書無しさん：2008/06/11(水) 20:37:24

べつに、出来なくても傷付きはしないがね。

870 ：仕様書無しさん：2008/06/11(水) 21:06:21

ねえねえ、おじゃばさまってひと、OOをわかってるつもりなの？
たしか前スレで、そのレンタルシステムとやらを作るとき、「やり方がわかんないから、もうクラス定義書いちゃえ」ってノリで作ってなかったっけ？

871 ：仕様書無しさん：2008/06/11(水) 21:08:34

レンタルとか・・・何故一般化しないのか？

オブジェクト指向を理解してないからさw

872 ：仕様書無しさん：2008/06/11(水) 22:08:02

別にバカ設計でいいんじゃないか？
おじゃば本人がそれでいいって言ってんだから
おじゃばのようなクズほっとけよ
バカの自己満足につきあうこともないだろ

873 ：仕様書無しさん：2008/06/11(水) 22:53:02

>>861, 861
一応、真面目に見てみた。どちらも最悪だな。
クラス名と操作の関係は、センスがないのか日本語能力がないのか
その両方か・・・。

874 ：仕様書無しさん：2008/06/12(木) 02:32:45

takano32,TAKANO Mitsuhiroこと高野光弘（日立製作所社員、日本UNIXユーザ会幹事）が、
自身の『32nd diary』で公然と日立の機密を開示し、障害者差別発言をしている問題。

1981年11月12日　千葉県のディズニーランドのそばで誕生
2001年4月1日　千葉大学に入学
2005年4月1日　千葉大学大学院へ進学、日本UNIXユーザ会に入会
2007年4月1日　日立製作所に入社、神奈川県秦野市の寮へ
2007年8月22日　「ついに職場で人が倒れた」と公表
2007年11月13日　「情報漏えい」を言う上司に「死んだほうがいいよ」と暴言
2007年12月28日　「社内システムクソうんこ」と発言し、仕組みも暴露
2008年5月23日　機密漏洩問題について一応の謝罪
2008年5月26日　「給料泥棒とかうんぬん言われた」と謝罪を忘れて告白
2008年5月27日　「心バキバキ川田くん」と前日の発言者の名前を公言
2008年5月31日　「キチガイ」と日立のユーザーに障害者差別発言を連発

2006年10月27日（日立製作所に入社前に忠告されたこと）
「日記やコメントの投稿日時から勤務時間に業務外のことをしていることが判明」は
某社の某親会社が 2ch で祭られたように、NG です。

6月も勤務時間中に更新し続ける高野光弘君の『32nd diary』にツッコミをどうぞ

875 ：仕様書無しさん：2008/06/12(木) 09:05:44

class 作品 extends カタログ
って定義をみて吹いた。
OO以前の問題だな、これ。。。

876 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/12(木) 10:03:01

>>868
この状況を見て、俺以上の人が大半と言っている時点で、状況を正しく認識しているとは思えない。
第一、基礎知識しか披露していない俺のレベルを、どうやって計っているのかも不明だ。
単に根拠もなく、868は俺より優秀だと思いたいだけではないか？

>>870
OO分かっている？OOの原理なんて単純な物だ。
実際に原理を説明して実演までしているのだから、俺がOOを分かっているかどうかは明らかなはずだが。
やり方が分からないと言っていたのは、「ユースケース図からクラス図を作る方法」だ。
名無しが出来ると言ったので、試しにやってみた時の話だ。ちなみに出来ると言っていた名無しは逃げた。

>>872,873,875
全然話にならないというなら、DVDレンタルで実演してみてくれよ。
その後にレンタカーに拡張までやってくれれば、俺との違いが明らかになるだろう。
そうすればどちらが正しいのか分かるのではないか？

877 ：仕様書無しさん：2008/06/12(木) 11:04:30

＞単に根拠もなく、868は俺より優秀だと思いたいだけではないか？

それなんて自己紹介？
お前が優秀だという根拠がどこにも無いんだが
お前の発言からは知性は微塵も感じられないし

878 ：仕様書無しさん：2008/06/12(木) 13:25:49

わかるだろ？なんて、この甘えんぼさんｗ

879 ： ◆ZnBI2EKkq. ：2008/06/12(木) 13:31:47

おじゃばより優秀なんて思いたくないなあ
そもそも
おじゃば程度と比較されるなんてレヴェルが低すぎて泣いちゃうよ俺
というかさぁ、おじゃば
君は魚の知識でさかなクンに勝負して勝てるか？
君が一方的に仕掛けているこのくだらない勝負もそういう類（たぐい）だよ

880 ：仕様書無しさん：2008/06/12(木) 19:03:33

>>865

>>>858
>それなら、商品、作品、会員、貸出履歴は全てグループだ。

では、これらのメンバー（単体）はオブジェクトとしては扱えないのですね？

881 ：仕様書無しさん：2008/06/12(木) 19:53:30

もっと抽象化を学べｗ

882 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/12(木) 19:59:18

>>877
確かに基礎しか言っていないのだから、俺が優秀かどうかは分からないだろう。
ただ、877やその他がまともな設計を出して来ないのだから、俺より優秀だとも言えない。
誰かが言っていたが、「おじゃばが詳しいんじゃなくて、他の奴がバカ」と言うのが正しい認識だろう。

>>879
つーか、879はC言語も通信も専門ではないだろう？

>>880
非常にいい所を突いてきたな。そこを突いて来たのは2人目だよ。一人目はextendsの間違いを指摘した人だ。
会員（単体）をオブジェクトで扱おうか、番号で扱おうか迷ったのだが、今回は番号にした。
だからそれぞれ、単体を表すのは、
商品：シルアル番号、作品：作品番号、会員：会員番号、貸出履歴：シリアル番号＋貸出日時
になっている。妥当だと思うが、何かいい方法でもあるか？

883 ：仕様書無しさん：2008/06/12(木) 20:06:54

データベースに繋げるなんて発想皆無なんだろうな
そんなに細かくクラス作ってさ、ひとつデータベースとのI/F作っちゃえば済む物をさ。

884 ：仕様書無しさん：2008/06/12(木) 22:53:57

それ、おもしろいかも。
RDBで組んだのとOOで組んだのを比べてみるという。

885 ：仕様書無しさん：2008/06/12(木) 23:16:47

対比しないし

886 ：仕様書無しさん：2008/06/12(木) 23:47:51

ADO.NET の DataSet みたいになるだけちゃうか

887 ：仕様書無しさん：2008/06/12(木) 23:50:44

>>880
>では、これらのメンバー（単体）はオブジェクトとしては扱えないのですね？
>>882
>商品：シルアル番号、作品：作品番号、会員：会員番号、貸出履歴：シリアル番号＋貸出日時
>になっている。妥当だと思うが、何かいい方法でもあるか？
普通に再起関連で表せばいいだろう、何を考える事があるんだ？

>>883
OOのセンスゼロだな

888 ：仕様書無しさん：2008/06/13(金) 00:08:52

>>882
とりあえず「貸出履歴：シリアル番号＋貸出日時」はだめだろ。
ど素人でもこんなミスはしない。
一時間以内に貸し借りを何度もした場合は、どーするの？

貸し出し履歴は一時オブジェクトだと言い切るなら
さらに救いようが無い。

オブジェクトの一意性をあらわすのに、時間を使う時点で程度が知れる。

889 ：仕様書無しさん：2008/06/13(金) 00:09:55

>>887
再起ってなに？馬鹿な俺にも分かるように説明してちょ。

890 ：仕様書無しさん：2008/06/13(金) 01:43:46

>>889
お前は本当に馬鹿だなｗｗｗ

891 ：仕様書無しさん：2008/06/13(金) 01:51:01

>>889
分かってるクセにいじわるだなー。

892 ：仕様書無しさん：2008/06/13(金) 03:19:47

ところでこのレンタルシステム（笑）って、誰が使うの？
客がセルフで物持ち出して会員番号入れて期日も入れたりすんの？
万引きし放題だね。

893 ：仕様書無しさん：2008/06/13(金) 05:16:26

ドメイン分析で失敗しているから全く現実味のないシステムになってるな。
レンタカーなんかどうでもいいからDVDレンタルを完成させないとね。

オブジェクト指向を理解していない奴は、レンタルシステムは、
いろいろなレンタルシステムで再利用できるみたいなこと言うんよね。
ちょっと経験のある者なら、アプリケーション開発では、クラスの再利用
（転用）を開発初期から考えてはいけないことくらい心得てるんだけどね。

このスレ見に来ている初心者にアドバイスだけど、オブジェクト指向は、
再利用（転用）は得意でないことを肝に銘じておくべき。
先輩技術者に、オブジェクト指向のメリットは、「継承による再利用」
だという奴がいたら「そいつにはついていってはいけない。」

ちなみに、フレームワーク開発やライブラリ（コンポーネント）開発では
再利用を開発初期から検討すべき。ただ、実装継承はなるべく使わないように
するのが鉄則だ。

894 ：仕様書無しさん：2008/06/13(金) 09:39:22

>>893
と、新人君が言っています

895 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/13(金) 09:52:04

>>883
各クラスの中で使用するDBインタフェースを、共通化すると言う話なら当たり前のことだが、
検索と更新のインタフェースを作って、データが必要になった時に直接随時使うと言う話なら、
それはOOではないな。何故無駄にメソッドを個別に作るのかとか言っている人かな？
理由は既に説明した。利用者がリモートDBになったり、DVDがビデオやCDになった時を考えるといい。

>>887
再起関連で表すって何だ？

>>888
確かにシリアル番号を振ってもいいが、この場合は秒まで入れれば問題ないだろう。

>>892
どういう意味だ？

896 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/13(金) 10:21:50

>>893
現実味がない？
機能限定されているが、要求仕様を満たしていて、すぐにでもコーディング可能な状態だと思うが。

再利用（転用）と書いている所をみると、転用に限定して言いたいのかな？
しかしOOが転用が得意でないと言う事ではなく、業務で実際にDVDレンタルをレンタカーに転用する事は
ほとんどないと言う事だろう？

フレームワークやライブラリでは再利用を想定って当たり前のことだが、なるべく継承を使うなって
どういう事だ？多重継承防止の事を言っているのか？その説明では全面禁止に読み取れるぞ。

つーか事実と誤解と誤りが入り交じった微妙な文章だな。

897 ：仕様書無しさん：2008/06/13(金) 10:27:13

>>895
>再起関連で表すって何だ？
わかっていないのか？　再帰関連の誤字だろう普通
普段からクラス図書かないから、再帰関連もわからないんだぞ
まずクラス図を書け

898 ： ◆ZnBI2EKkq. ：2008/06/13(金) 14:30:10

>>895
>確かにシリアル番号を振ってもいいが、この場合は秒まで入れれば問題ないだろう。
店舗数が多い場合（少なくてもやっちゃいけない）、秒単位で同じ時間に借りる人がでてくる
　　→　一意性がなくなる
　　→　複合キー　キター＞＜！

>>882
専門家（笑）

899 ：仕様書無しさん：2008/06/13(金) 14:32:50

そんな小規模なシステムに本格的にミジンコレベルまでベースクラス作ってってw
パッケージソフト買えよw

900 ：仕様書無しさん：2008/06/13(金) 14:52:37

設計のまずさが実装に影響を及ぼすいい見本だ

901 ：仕様書無しさん：2008/06/13(金) 18:49:50

お約束というレベルの処理をたった１レスの中で明確に間違えているのは、擁護しようがないわけだけど、それをさらに、認めないという傲慢さ。

わざとじゃなかってくらい、最悪SE像を具現化しているんだよなー。

902 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/13(金) 19:38:04

>>897
再帰だとしても意味が分からないが。

>>898
商品のシリアル番号はDVD一枚一枚に付けられた番号だから、店舗数が増えても同時に借りられる事はない。
問題になるのは、借りてすぐに返された場合だが、1秒以内に返却処理を行って、再度借りるのは
店舗レンタルにおいては無理だろうから、問題ないだろう。

903 ：仕様書無しさん：2008/06/13(金) 22:11:02

かまって君とおせっかい君が集うスレはここですか？

904 ： ◆ZnBI2EKkq. ：2008/06/13(金) 22:22:02

めんどくさくて（到底読む気なんておきない）おじゃばのクラス図（笑）を
適当に斜め読みしてたんだが
シリアル番号ってDVDのだったのかｗ
一枚一枚にユニークな番号を当てていくということは
10万枚のDVDがあったら、10万個の番号を手作業で振っていくのか
そんなことをしてる間に店が潰れるｗ

905 ：仕様書無しさん：2008/06/13(金) 22:48:53

アホコテ二人か

906 ：仕様書無しさん：2008/06/13(金) 23:12:48

>>896
つかうなと言ってるのは継承じゃなくて実装継承

907 ：仕様書無しさん：2008/06/13(金) 23:28:51

>>896
>現実味がない？
>機能限定されているが、要求仕様を満たしていて、
>すぐにでもコーディング可能な状態だと思うが。
冗談はよせ。

>再利用（転用）と書いている所をみると、転用に限定して言いたいのかな？
>しかしOOが転用が得意でないと言う事ではなく、業務で実際にDVDレンタルを
>レンタカーに転用する事はほとんどないと言う事だろう？
・・・やっぱ分かってないや。

>フレームワークやライブラリでは再利用を想定って当たり前のことだが、
>なるべく継承を使うなってどういう事だ？多重継承防止の事を言っている
>のか？その説明では全面禁止に読み取れるぞ。
レンタルシステムの再利用を継承で行われていることが愚かだと言っている
んだよ。レンタルシステムが未来に変更された場合にどうなるか考えてみな。
汎用的な部分と特化した部分を強結合している所がだめってこった。

>つーか事実と誤解と誤りが入り交じった微妙な文章だな。
そういうことは、的確に誤りを指摘できる奴が言うこった。

908 ：仕様書無しさん：2008/06/13(金) 23:31:55

>>906
ちゃんと理解しているやつもいるな。
おじゃばは、実装継承とインターフェース継承の違いを理解してない
みたいだけどな。基礎的なことなんだけどね。

909 ：仕様書無しさん：2008/06/13(金) 23:37:53

おじゃば、前にこのスレ見たときより
頭わるくなってるきがする(笑)

910 ：仕様書無しさん：2008/06/13(金) 23:44:17

>すぐにでもコーディング可能な状態だと思うが。
わかったわかった
言語は問わんからコーディングしてうpしてくれ

数日待つよ
突っ込むのはそれからにするからよろしく

>事実と誤解と誤りが入り交じった微妙な文章
お前の文章は誤解と誤りと妄想が入り交じって無知のスパイスが効いてる

911 ：893：2008/06/13(金) 23:46:37

>>902
>商品のシリアル番号はDVD一枚一枚に付けられた番号だから、
>店舗数が増えても同時に借りられる事はない。
>問題になるのは、借りてすぐに返された場合だが、1秒以内に返却処理を行って、
>再度借りるのは店舗レンタルにおいては無理だろうから、
>問題ないだろう。
秒まで入れるとは傑作だ。UTC を知らないのか？

秒まで考慮してもリスクは無くならない。
レンタルシステムは当然サーバーに配置されるわな。
複数の端末からレンタル処理を起こすわな。
となると、即時に処理が完了するとは言い切れないな。

あと、当然、サーバーの時計でタイムスタンプを付ける事になるだろう。
なら、サーバーの時刻がずれて、ある日、時刻合わせが行われたら
どうなる？
うるう年、うるう秒などあって時刻ってのは厄介なんだ。
あと、サマータイムとか導入されたらシステム崩壊か？

経験がなさすぎなんだよね。

912 ：仕様書無しさん：2008/06/14(土) 02:54:48

このスレの教訓。
相手を見て話をしよう。
自分が知ってることをまくし立てて相手がうんざりして黙るのを
勝利と喜ぶ幼稚な自分を反省しよう。
自分の言葉が分からないのは、相手が無能だからではない。

たとえ自分だけが有能でも、理解されなければ意味がない。
わかってくれない、わかるだろ？
そうもどかしく思ったら、それは自分の無能だ。

913 ：仕様書無しさん：2008/06/14(土) 03:40:36

というか単純に認識の共有の前提から崩れていると思うわけだが。

914 ：仕様書無しさん：2008/06/14(土) 04:34:48

アホコテが何を伝えたいかすらわからん
俺はばっかでーすとアピールしてることだけはわかるけど

915 ：仕様書無しさん：2008/06/14(土) 07:55:44

>>おじゃば
真面目に質問させてくれ。
１．なぜお前はここまで反感を買ってると思うか？
２．OO（分析含む）はクラス図があればそれで充足するか？
３．今までに読んだOO本は何？
４．業務時間中にレスしてるのか？
５．質問に質問を返すのはなぜか？

916 ：仕様書無しさん：2008/06/14(土) 07:57:18

こういうのはどうすんの？
・ブラック顧客リストの登録・判定
・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
・客がレンタル品を壊した場合
・盗まれた場合の商品の特定と登録抹消処理
・商品の予約をどうするか

917 ：仕様書無しさん：2008/06/14(土) 07:58:49

655 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2008/05/08(木) 09:52:48
>>638
車種毎に変わるなら車種に入れて、特定の車両毎に変わるなら商品を拡張した物に入れる。簡単だろう。

>>642
>・ブラック顧客リストの登録・判定
会員にフラグ追加。
>・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
運用対処。
>・客がレンタル品を壊した場合
破棄は導入済み。
>・盗まれた場合の商品の特定と登録抹消処理
棚卸しの処理を追加する必要がある。
>・商品の予約をどうするか
やり方はいろいろあるが、料金表に予約を追加すれば可能。

ってバカ

918 ：仕様書無しさん：2008/06/14(土) 11:55:13

商品IDのナンバリング生成規則とか、ＯＯと関係ねえべ。
なんでそんな本質と関係無い重箱の隅をとくとくと説明してるのかなぁ？

919 ：仕様書無しさん：2008/06/14(土) 12:27:27

>>918
本気で言ってるなら業界を去った方がいいな。
オブジェクト指向では、オブジェクトの一意性はとても重要なんだが。

920 ：仕様書無しさん：2008/06/14(土) 12:33:53

オブジェクト指向とは関係なくても、設計としては意味があるだろ。
オブジェクト指向かどうかは、設計が妥当かどうかに比べればそれこそ重箱の隅だ。

921 ：仕様書無しさん：2008/06/14(土) 12:37:14

>>919＝おじゃば
本気で言ってるなら人間辞めた方がいいな。
文章の読解力はとても重要なんだが。

922 ：919：2008/06/14(土) 12:43:36

>>921
誤爆だぞ。
おじゃばが一意性に関して設計ミスってる事を指摘してたんだが・・・。
だから、 >>918 をおじゃばかと思ってたんだが。。。違うみたいだが。

923 ：仕様書無しさん：2008/06/14(土) 12:45:06

ナンバリングの規則なんて、それこそ入れ替え可能な部分だろw
実装時に決定してりゃ済む問題だww

924 ：仕様書無しさん：2008/06/14(土) 12:51:17

>・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
運用対処。

ありえんだろ、これ

925 ：仕様書無しさん：2008/06/14(土) 12:54:52

>>920
OOスレだよねここ。
いつから設計スレになったの？

926 ：仕様書無しさん：2008/06/14(土) 13:05:56

もうコーディング可能なほど設計は完了した！とかほざくアホが居るから
皆でつつきまくって遊んでるだけじゃない？

927 ：仕様書無しさん：2008/06/14(土) 13:48:17

設計よりOOだろってやつは、こんなのがOOだっていうおじゃばの言い分には
納得してるんだろうか・・・

928 ：仕様書無しさん：2008/06/14(土) 13:51:01

>>927
おじゃばの発言にOOのエッセンスすら見えないから設計スレかと思ったんだけど？

929 ：仕様書無しさん：2008/06/14(土) 13:54:09

>925
お前みたいな「JavaやってるのでOO理解してます」なやつがいるから

930 ：仕様書無しさん：2008/06/14(土) 14:09:21

OOは分析・設計・実装フェーズでそれぞれ使うもの

931 ：仕様書無しさん：2008/06/14(土) 14:11:58

ここでは分析も無しにいきなり実装直前のチラシの裏的なOO設計しか語ってないがなw

932 ：仕様書無しさん：2008/06/14(土) 14:14:49

そもそも要件がアホコテの脳内にしかないものを並べて設計とか言われてもね

933 ：仕様書無しさん：2008/06/14(土) 18:41:21

このスレの構図
おじゃばさま vs. おばかさま達
たま～に来る傍観者がオレ

934 ：仕様書無しさん：2008/06/14(土) 19:44:11

毎日来てるくせにｗ

935 ：仕様書無しさん：2008/06/14(土) 19:47:13

名無しなのに正体バレバレなのは面白いな

936 ：仕様書無しさん：2008/06/14(土) 20:56:21

>>932
もういいって、バレバレだからさ。。。。

937 ：仕様書無しさん：2008/06/14(土) 20:58:51

？

938 ：仕様書無しさん：2008/06/14(土) 21:04:21

「おじゃば」がいなけりゃこのスレ過疎スレだろ。
糞設計してるくせに、まことしやかにオブジェクト指向を語る
気持ちの悪いやつと「おじゃば」が重なって、ムカつくだけなん
じゃねーのか？

日本のプログラミングの現場は腐っている。
向上心すら失っているやつ多い。やる気もくそもない。オブジェクト指向
なんてどーでもいい。とにかく、早く家に帰って寝たいってやつ多いんだよ。

オブジェクト指向設計をパーフェクトにやったとしても、
そいつの人生は別にハッピーになったりはしねーんだよ。
結局、自己満足と職人気質の世界なんだよ。日本では。

インセンティブなしで、２ちゃんでもプログラミングについて
議論したりして、何の得になるんだ？

オブジェクト指向全く理解していなくても、口がうまくて、アピール上手、
人当たりがいいやつが良い思いするんだよ。
オブジェクト指向を大上段に語って、裏で反感買って、結局損をするって
パターンも多いんじゃねーか？

本当に自分のことを優秀だと思うなら、その才能を別の事に生かした方が
金になると思うな。おれは。

939 ：仕様書無しさん：2008/06/14(土) 21:08:31

オブジェクト指向を推進して、何か得したことあるか？
金、名誉、女・・・・。なんでもいいや。

理想論とか空想とかは無しにしてくれよ。

940 ：仕様書無しさん：2008/06/14(土) 21:09:51

あらゆる宗教は信者から金を巻き上げるための手段にすぎない

941 ：仕様書無しさん：2008/06/14(土) 22:15:08

インセンティブw

942 ：仕様書無しさん：2008/06/14(土) 22:30:22

おじゃばは平日昼間だけのアゲ専
つまり仕事をなめてる窓際爺さんなんだが、そんな爺さん
のかまってカキコにいちいち反応してあげてるおまえ等も
同じ穴の貉。おじゃばが釣り師でおまえ等は雑魚。
ヤレヤレだぜ。

943 ：仕様書無しさん：2008/06/14(土) 22:32:56

そんな雑魚に突っ込むお前も大差ないと気付いているのだろうな？

944 ：仕様書無しさん：2008/06/14(土) 22:38:57

平日昼間から堂々と2chやってる奴ってのも嫌だが、
そんな給料泥棒的な行為を延々と見過ごしてる会社も嫌だな。
おじゃばの会社ってきっとセキュリティ対策とか甘々なんだろうな。

945 ：仕様書無しさん：2008/06/14(土) 22:52:35

>>942
おじゃばが爺さんのわけねぇだろ、文章を見る限り、
どうみても10代かせいぜい20代前半の語彙力と筆力だぞ。

946 ：仕様書無しさん：2008/06/14(土) 22:55:30

でも表現とか発想は団塊世代なんだよね

947 ：仕様書無しさん：2008/06/14(土) 22:55:31

オジャバメン

948 ：仕様書無しさん：2008/06/14(土) 23:26:14

再起ｗｗｗ

949 ：仕様書無しさん：2008/06/14(土) 23:35:46

糞スレぼちぼち終わり。
おじゃばには悪いが、月曜日までに終了。

950 ：仕様書無しさん：2008/06/14(土) 23:36:26

再起不能

951 ：仕様書無しさん：2008/06/14(土) 23:56:40

クソすれいちいちあげんな、おじゃばかよ。

952 ：仕様書無しさん：2008/06/15(日) 00:30:07

>>949　謝る必要ねぇだろw

953 ：仕様書無しさん：2008/06/15(日) 00:40:47

もう次スレたてんなよ。いらんだろ。

954 ：仕様書無しさん：2008/06/15(日) 01:02:23

こんな糞スレでも必要としている者が若干１名いる。
その男が喜び勇んで次スレも立てちゃうだろうがな。

955 ：仕様書無しさん：2008/06/15(日) 01:05:48

プラス一名だ
なんだかよく分からんが加勢するぜ

人の嫌がることをすすんでやります！

956 ：仕様書無しさん：2008/06/15(日) 07:56:48

>>955
>人の嫌がることをすすんでやります！
意味違うだろｗ

957 ：仕様書無しさん：2008/06/15(日) 08:33:31

>>954
糞設計してみんなに生き恥さらした、「おばかさま」がか？

958 ：仕様書無しさん：2008/06/15(日) 23:07:53

ここの住人はみんな糞だろ！
糞以外こんなスレに来る奴いないぞ

959 ：仕様書無しさん：2008/06/15(日) 23:50:26

おまえもな

960 ：仕様書無しさん：2008/06/16(月) 00:10:48

認めてるしｗ

961 ：仕様書無しさん：2008/06/16(月) 00:49:14

うんここにはクソしかいないよ。

962 ：仕様書無しさん：2008/06/16(月) 02:04:53

馬鹿相手に優越感を感じたい人が集まるスレがあると聞いてやってきましたｗｗｗ
(^Д^)

963 ：仕様書無しさん：2008/06/16(月) 10:15:10

なんだ、壊れたのか

964 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/17(火) 10:05:55

>>904
DVDにはすでにシリアル番号は振ってあるだろう。

>>907
「汎用的な部分と特化した部分を強結合している」と言うのはどこを言っているのか？
最初に言ったと思うが、DVDレンタルをレンタカーにしたのは、時間貸しシステムとしての共通点があるからだ。
この時間貸しが別の方法に変わった時を想定しているのかな？

>>908
インタフェース部に実装継承を使うなと言う事なら、フレームワークやライブラリでは再利用を想定
と同様で当たり前すぎだろ。

>>910
ソースを全部書けと言うのか？
いくらなんでも無茶言うな。

965 ：仕様書無しさん：2008/06/17(火) 11:03:21

もう少し待ってやるから
さっさとコーディングはじめろ

966 ：仕様書無しさん：2008/06/17(火) 17:00:56

モノをモデリングしたって答えなんて出ないよ。
ストーリーをモデリングするんだよ。

967 ：仕様書無しさん：2008/06/17(火) 17:51:13

>>964
>インタフェース部に実装継承を使うなと言う事なら、フレームワークやライブラリでは再利用を想定
何を言ってるんだかさっぱり・・・

968 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/17(火) 19:33:37

>>911
では貸出番号を振ろう。
ただ俺が問題ないと言ったのは、元々1店舗想定なので、サーバは1個でサーバ時間を使うのは当然だし、
通算秒を使うからサマータイムは関係ないからだ。つーかまるで端末時間を使って、
時刻の文字表現をDBキーにするような言い方だな。どんな経験してるのだ？

>>914
OOの利点が変更に強い事だと言うのを説明している。
理解不足をアピールしているのは914だろう？

>>915
>１．なぜお前はここまで反感を買ってると思うか？
分からないが、多分俺が間違いを指摘したからだと思う。
>２．OO（分析含む）はクラス図があればそれで充足するか？
充足する。
>３．今までに読んだOO本は何？
買ったのはOOを哺乳類で説明するやつ。もう持ってない。他は立ち読み。
>４．業務時間中にレスしてるのか？
個人情報に関することは答えない。
>５．質問に質問を返すのはなぜか？
多分、俺が常識と思っている事を質問者が知らないためだろう。

969 ：仕様書無しさん：2008/06/17(火) 19:53:32

> 分からないが、多分俺が間違いを指摘したからだと思う。

逆だよ
・お前が間違いだらけで
・間違いを指摘されても理解できないことは全て逆ギレするか無視する
からでそ

> 個人情報に関することは答えない。

個人情報関係ないでしょ
バカ？

> 多分、俺が常識と思っている事を質問者が知らないためだろう。

妄想を拠り所にした持論(俺様理論)を常識とか言われても困る

970 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/17(火) 20:15:10

>>918-923
923

>>925-932
だから俺のが気に入らなければ、自力でOOの利点を説明して実演すればいいのではないか？
ループの終了条件や通番付与などの的外れの指摘のみで、バカバカ言われてもどうしようもない。

>>938-939
得とか金とかは別の話だろう。
OOは設計方法の1つに過ぎないのだから、それが出来たから金持ちになれるなんて事はない。
単に仕事が楽になると言うだけだ。つーか早く帰って寝たいならOOぐらいマスターしておけと思う。
つーか何でOOを勉強しない口実を作る？
自分がオブジェクト指向を理解して、口がうまくて、アピール上手、人当たりがいいやつになればいいだろう。
金が欲しければ、優秀なメンバーを集めて起業すればいい。

971 ：仕様書無しさん：2008/06/17(火) 20:47:36

で、おじゃばはこのスレどうしたいわけ？
レンタルシステムを自分とハカセで勝負して作る場にしたいの？
それはよそでやれとしかいえんな。スレ別に起てるとか。
第一ハカセはもう逃げた(笑)んだから、お前の勝ちでいいだろ。
コーディングもこれでできる。よかったよかった。すごいなおじゃば。
さすが実務でOOやってる奴だ。とってもかなわないよ～。

これでいいんだろ？で、このお話はおわりね。

972 ：仕様書無しさん：2008/06/17(火) 22:58:17

もう相手するのがアホらしくて

973 ：仕様書無しさん：2008/06/18(水) 00:26:54

>>968
>では貸出番号をふろう
分かってくれたらそれでいい。

>通算秒
通算秒なんて今まで言ってなかったじゃん。新しい設計追加ね。
UTC使えって指摘されたのを採用したわけね。

一応、自分の設計ミスに気がついたみたいだな。
そうやって人は成長するもんだ。

974 ：仕様書無しさん：2008/06/18(水) 00:33:39

>>970
>つーか早く帰って寝たいならOOぐらいマスターしておけと思う。
マスターしていないお前が言うな。
OO分かったつもりで、糞設計撒き散らして異臭を放っているやつが
多いから OO が普及しないんだ。

確かに OO は普及しているように見える。ただ、その効果を存分に発揮
させるまで使いこめている奴は少ない。このスレの惨状を見れば、
その片鱗くらい見えるだろ。

偽物が多すぎるんだ。上流工程（要求把握、ドメイン分析）ができない奴
が、設計だけでゴリ押しして無益なコードを量産するから不幸が起こる。

975 ：仕様書無しさん：2008/06/18(水) 02:26:29

>>974
大手のうんこSIerのことですね、わかります。

976 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/18(水) 12:07:10

>>969
俺のが間違いの指摘って何だ？本当に分からん。
レンタル設計以降でまともな指摘は、extendsの取り忘れだけだったと思うが。
あとは間違いや論点の違う話ばかりだろう。

それに俺様理論を常識と言われても困るとか言っているが、俺のが言っている事を分かっている人もいるし、
WEBの掲示板でないOO説明で、少なくとも2箇所で俺の言っている事と同じ事が書いてあるが。

>>971
OOの設計方法を議論する事で、OOが普及しない訳も見えてくるのだから、全く問題ないだろう。
むしろ順調と言える。

>>974
OOの原理なんて簡単だ。オブジェクト毎の独立性を高めて、変更や再利用を容易にするというだけだからな。
なんかOOに幻想持ち過ぎているのではないか？
大体、糞設計が気に入らないと言うなら、自分の素晴らしい設計を書けばいいのではないか？
テキストで書くなら、30分もかからないだろう。つーか書けたらもう書いてるか。

977 ：仕様書無しさん：2008/06/18(水) 14:25:38

>WEBの掲示板でないOO説明で、少なくとも2箇所で俺の言っている事と同じ事が書いてあるが。
ここだけじゃなく別の掲示板でもやってるのか
やらなければならないことがあるだろ
新品の石鹸を一度で使い切るとか鏡に映った自分を相手にあっぷっぷで勝負するとかあるだろ

978 ：仕様書無しさん：2008/06/18(水) 14:26:28

にらめっこな

979 ：仕様書無しさん：2008/06/18(水) 14:31:19

http://pc11.2ch.net/test/read.cgi/tech/1212895856/894
これ、おじゃぱじゃないだろうな？ｗ

980 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/18(水) 21:56:40

>>973
つーか、貸出履歴の日時がdate型だと思わなかった時点でやばいのではないか？
少なくとも何人かは気が付いて、忠告もしていたようだが。

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

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

981 ：仕様書無しさん：2008/06/18(水) 22:26:29

OOスレも終焉か
偉そうに喋るからおじゃばってもっと分かってるかと思ってたけど、
ホントに使えない奴だってのがはっきり分かった

OO＝OOPです、とか言っちゃうし、
分析と設計は同じ物とかほざくし、
コンポーネントがなんなのかすら理解できてないくせ分かってるふりするし、
オブジェクトの切り分けが出来てないまま簡単に作れるとかほざくし、
無能なので会社では仕事与えられず勤務中に２chやってるし、
まさにゴミ
社会に不要で存在価値ゼロなのによく生きてられるな
お前、この仕事向いてないよ
このスレがお前の劣等感で成り立ってるってのだけがお前の生き甲斐
もしかして自分は才能あるとか思ってない？ﾌﾟ
お前若いよね、悪い意味で
２ちゃん読んでる暇あったらもちっと本でも読めば？

982 ：仕様書無しさん：2008/06/18(水) 22:31:34

おいおい、そこまで本当のこと言うなよ

983 ：仕様書無しさん：2008/06/18(水) 22:35:18

まあ、大体おじゃばみたいな奴ばかりだけどな。
ただ、おじゃばの悪い所は向上心があるところ。

結局始末に終えないモンスターになるだけだな。

無能は無能なりに、せせこましく仕事すればよいのに、
向上心を持った性で、有能な奴の足を引っ張るのが目に見えるようだ。

984 ：仕様書無しさん：2008/06/18(水) 22:43:14

向上心ではなく虚栄心だな
無能な奴のデフォルトだ

985 ：おじゃばさま ◆GxjxF3yEw6 ：2008/06/18(水) 22:45:56

>>981
劣等感なんてないし、自分は才能あると思っているし、仕事も多いし、向いていると思っているよ。
つーか劣等感があるのは981だろう？クラス図1枚書けない無能はお前だろう？八つ当たりするなよ。

986 ：仕様書無しさん：2008/06/18(水) 22:52:08

釣れた
と思ったら無能の職無しかよ
おまえセンスないよ
ろくなアイデアないんだったらカキコしないでいいですよ
恥かかせてごめんなさいね

987 ：仕様書無しさん：2008/06/18(水) 23:06:25

>>976
>>OOの原理なんて簡単だ。オブジェクト毎の独立性を高めて、
>>変更や再利用を容易にするというだけだからな。
まだ分かってないみたいだな。
独立性を高めて変更や再利用を容易にするのは、OO特有のものではないと
散々突っ込まれてもまだ言うか・・・。
あと、「原理」という言葉の使い方を間違っているので注意な。

>>なんかOOに幻想持ち過ぎているのではないか？
>>大体、糞設計が気に入らないと言うなら、自分の素晴らしい
>>設計を書けばいいのではないか？
糞設計各奴に俺の素晴らしい設計を理解できるはずがない。
そういうことは、せめて、凡人レベルの設計ができてから言ってくれ。

988 ：仕様書無しさん：2008/06/18(水) 23:13:17

>>985
>劣等感なんてないし、自分は才能あると思っているし、仕事も多いし、
>向いていると思っているよ。
おまえって、スーパーポジティブだな。
俺、おじゃば程度の実力だったら業界を去ると思う・・・・。

実力はなくてもポジティブな奴って「おだてられて」仕事
たくさん抱え込んでくれるから「便利な奴」だよな。
組織に、一人は必要だな。

989 ：仕様書無しさん：2008/06/18(水) 23:17:30

業界を去るとか簡単に言いますけどね
この業界にどっぷり浸かった身で他の業界で食ってけると思ってんですか？

990 ：仕様書無しさん：2008/06/18(水) 23:30:36

>劣等感なんてないし

この釣られかたした時点で劣等感の塊じゃないか

991 ：仕様書無しさん：2008/06/18(水) 23:37:08

>>989
「おじゃば程度の実力だったら」の話だろ。

992 ：仕様書無しさん：2008/06/18(水) 23:51:34

コピペで説明を、しかも用語定義ごときを貼っ付けてえばってる所が、
このスレの進展のなさと程度を物語ってるな。まぁ、おじゃばの馬鹿っ
ぽい説明よりましとはいえ、ほとんど無意味。これが自称有能君のカキ
コだぜ。笑っちゃうよ。

それではまた、がんばってループしちゃってください。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

993 ：仕様書無しさん：2008/06/19(木) 00:01:33

>>985
ﾜﾛﾀ

劣等感だの才能だの仕事の多さだのは知らないが。

少なくとも「OOはOOPでOOA/Dは役に立たない」とか「分析と設計は一緒」とか言ってるのはセンス無いし、
用語に限らず表現する言葉を軽視するところや人に伝える能力の低さ辺り、技術者開発者には向いて無い。

あぁ、おじゃばの仕事はドカタなコーダーだっけ？
なら向いてる可能性もあるかもな。
人足はコード書けりゃそれでいいからな。

994 ：仕様書無しさん：2008/06/19(木) 00:04:46

>>983
ITドカタという職業だから低脳が多いのは当たり前だな
だから、取り立てておじゃばが無能ってことはないよな
おじゃばを馬鹿にしている>>988もおじばと似たりよったりの
実力と思う。

>>985　おじゃばそれで良いいぞ。そうじゃなければ、底辺ITドカタ
なんてしないで別な仕事しているよな。まだまだ日本人ITドカタ
必要だからがんばってくれ。ただ、出せる人件費はオフショアの
の人件費がベースになるから、今後はかなり下がると思ってくれ。
こちからすると、やること同じなら同じ人件費しか出せん。

995 ：仕様書無しさん：2008/06/19(木) 00:37:43

>>994
と、零細企業に勤める無能ITドカタが申しております。

996 ：仕様書無しさん：2008/06/19(木) 00:38:28

次スレたてた奴、デフォで負け組みな。

997 ：仕様書無しさん：2008/06/19(木) 00:53:09

心配しなくてもアホコテが自演で立てるよ

998 ：仕様書無しさん：2008/06/19(木) 03:25:10

>>994
もうちょっと酒が抜けたときに書け。

999 ：仕様書無しさん：2008/06/19(木) 03:27:12

999

1000 ：仕様書無しさん：2008/06/19(木) 03:37:22

　糸冬　

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。