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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/10 01:30 / Filesize : 337 KB / Number-of Response : 908
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：仕様書無しさん mailto:sage [2008/03/29(土) 23:02:52 ]: 過去ログ
part 1 pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 pc11.2ch.net/test/read.cgi/prog/1185378099/
part 4 pc11.2ch.net/test/read.cgi/prog/1188396264/
part 5 pc11.2ch.net/test/read.cgi/prog/1189946678/
part 6 pc11.2ch.net/test/read.cgi/prog/1190731526/
part 7 pc11.2ch.net/test/read.cgi/prog/1192703383/
part 8 pc11.2ch.net/test/read.cgi/prog/1201610928/

おじゃばは簡潔に書け　自演とオレオレルールも禁止
その他はスルー技術を身につけれ
おじゃばの低能はデフォ　熱くなった方が負け
2 名前：仕様書無しさん mailto:sage [2008/03/29(土) 23:04:50 ]: ガンダムOOが面白いって評判なんだけど。
3 名前：仕様書無しさん mailto:sage [2008/03/29(土) 23:07:56 ]: 自演はデフォ
4 名前：仕様書無しさん mailto:sage [2008/03/30(日) 00:25:41 ]: ひたいはデコ
5 名前：仕様書無しさん mailto:sage [2008/03/30(日) 13:12:19 ]: OOは結局誰が生き残ったのさ
6 名前：仕様書無しさん [2008/03/30(日) 13:44:15 ]: オブジェクト指向プログラミングは普及してると思うが
7 名前：仕様書無しさん mailto:sage [2008/03/30(日) 16:40:32 ]: 分析と設計は普及していない
8 名前：底辺プログラマ mailto:sage [2008/03/30(日) 18:40:38 ]: てかOO以降の流れって、実装能力のある人がデザインする前提じゃね？
日本はプログラムを書けないSEが中間層に挟まりすぎ。
そんでOODのアウトプットって、顧客に「なんとなく分かったよーな錯覚を持たせる」
力があるから、結局日本だと、
「無能SEが下流に責任を押し付けるための都合のよい道具」として
悪用されているだけって気がするよ。
9 名前：仕様書無しさん mailto:sage [2008/03/30(日) 19:43:22 ]: おまえ等、前スレが消化しきれてないことを忘れちゃいないか？
10 名前：仕様書無しさん mailto:sage [2008/03/30(日) 19:58:03 ]: もうおなかいっぱい
11 名前：仕様書無しさん mailto:sage [2008/03/30(日) 22:29:11 ]: >>6
あんまり普及してないんじゃね?
12 名前：おじゃばさま ◆GxjxF3yEw6 [2008/03/31(月) 09:50:06 ]: なんか前スレ読めないのだが。
13 名前：仕様書無しさん mailto:sage [2008/03/31(月) 09:52:46 ]: 馬鹿には読めない
14 名前：仕様書無しさん mailto:sage [2008/03/31(月) 13:43:17 ]: >>8
わたしは思うんですが、こうした細部が外部の部外者からは「意味が
読めない」仕組みである、プログラミングという知的システムの持つ
宿命的な性質に由来していて、それはN88BASICの時代から実は
それほど変化してはいないと思うのです。

簿記の内容とかは常識で考えればそれほど敷居は高くはない。
建築構造設計ならそれなりのソフトに書ければ安全かどうかぐらいは
すぐにわかる。

しかし、込み入った内部構造が実装されているプログラミングという
高度な知的資産んついては、外部の部外者の人間にはそう簡単には
解読し理解できない。そこにこの世界の生産性の限界、保守性の限界
が宿命的に運命付けられていて、構築する側の労働の性質として特徴
的な困難が横たわっていると思う。

それを解決する手段がいままでいろいろ提案されてきたと言う中でこの
OOもあるだけで、しかし、この根本的な困難を決定的に解決するには
至っておらず、業界の労働の性質はほとんど永遠に変わることはない
のではないか。OOの次がまだ見えていない現状から見るとそう思えて
ならない。
15 名前：おじゃばさま ◆GxjxF3yEw6 [2008/03/31(月) 19:23:27 ]: >>14
別に大量生産すればいいって物でもないのだから、生産性を上げたりしなくてもいいんじゃね？
16 名前：おじゃばさま ◆GxjxF3yEw6 [2008/03/31(月) 19:53:59 ]: 前スレが見えなくなってしまったので、もう一度DVDレンタルの設計過程を書こう。
アクター一人でやる方法は思いつかないので、出来る奴に任せる。

俺はカウンターや入荷棚をシステムの一部として、客や業者をアクターにする事にする。
「システムに触る=コンピュータの操作をする」と言う解釈ではなく、カウンターにDVDを置くのも
システムに触ると言う解釈をすれば問題ないと思っている。
となると、アクターは、
「店員」「店長」「会員」「業者」になる。店長はこの前やってみて必要だと思ったので追加した。
システムは大きい括りでは「レンタルシステム」だが、先ほどアクターを追加したため、
中に「カウンター」「返却箱」「仕入れ棚」「廃棄棚」を含むとしよう。
上記オブジェクト分けしたとすると、レンタルシステムを構成する残りの要素も分類しよう。
あとは、「商品棚」「DVD」「料金表」こんな所だろうか。
手順としてシステムを要素に分割していいのか分からないが、とりあえずこれでやってみようかと思う。
システムは、「レンタルシステム」で、
構成要素は「カウンター」「返却箱」「仕入れ棚」「廃棄棚」「商品棚」「DVD」「料金表」とする。
17 名前：おじゃばさま ◆GxjxF3yEw6 [2008/03/31(月) 19:59:03 ]: さて次はユースケースだ。まず会員。
会員--（入会申請を行う）-->カウンター
会員--（退会申請を行う）-->カウンター
会員--（DVDを選ぶ）-->商品棚
会員--（DVDを持って行く）-->カウンター
会員<--（DVDを受け取る）--カウンター
会員--（DVDを返す）-->返却棚
会員--（延滞料金を払う）-->カウンター
会員<--（延滞警告される）--カウンター
次に店員。
店員<--（入会のチェック）--カウンター
店員<--（退会のチェック）--カウンター
店員<--（貸し出し条件のチェック）--カウンター
店員<--（返却条件のチェック）--返却棚
店員<--（延滞チェック）--カウンター
店員<--（仕入れチェック）--仕入れ棚
店員<--（廃棄チェック）--商品棚
こう見るとチェックばかりだが、バイトにも触らせる事を考えると、システム的には良い物かもしれない。
18 名前：おじゃばさま ◆GxjxF3yEw6 [2008/03/31(月) 20:08:52 ]: 次は店長。
店長と業者間には何か噛ませようと思うが、新しく何かを作るのは面倒なので、仕入れ棚で代用する。
廃棄はどうしようか。一つ一つチェックするのは難しいと思うので、廃棄条件を入れて置くと、
自動的に廃棄することにしよう。とりあえず、商品棚に対して廃棄条件の設定で考えて見る。
あとは料金変更かな。
店長<--（新作DVD一覧の参照）--仕入れ棚
店長--（DVD発注）-->仕入れ棚
店長--（廃棄条件の設定）-->商品棚
店長--（料金の設定）-->料金表
最後に業者だ。
業者--（新作DVD一覧の設定）--仕入れ棚
業者<--（注文DVD一覧の参照）--仕入れ棚
業者--（納入）-->仕入れ棚
業者<--（廃棄）--廃棄棚
19 名前：仕様書無しさん mailto:sage [2008/03/31(月) 20:20:04 ]: あまりに全スレ最後が的確で大笑いだ。
>988 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 17:01:20
>おじゃばは「客が店に入る」とか「客がお金を払う」とかも
>ユースケースに書きそうだな
>989 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 17:48:23
>>>988
>客が1万円札を出す、とか客が棚のDVDの配置を変える、とかまで入るかも
>990 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 18:11:42
>客がDVDのケースと中身を入れ替える　とか　万引きする　とか
>991 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/29(土) 18:27:42
>起業から倒産までフォローして欲しい
>992 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/30(日) 00:09:26
>客を装った強盗が刃物を持ってカウンタへ押し入る、とか
>993 名前: 仕様書無しさん Mail: sage 投稿日: 2008/03/30(日) 00:15:46
>客がエロビデオをカウンターに持っていったら店員がかわいい女の子で気まずい思いをする、とか
20 名前：仕様書無しさん mailto:sage [2008/03/31(月) 20:48:19 ]: >>18
こんな感じ？

ユースケース　～レンタルシステムの戦い～
　∧＿∧　　　　　　　　　　　　∧＿∧
　(　･ω･)＝つ≡つ ⊂≡⊂＝(･ω･　)
　(っ　≡つ＝つ　　　　⊂＝⊂≡　⊂)
　./　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ　ﾊﾞﾊﾞﾊﾞﾊﾞ (　　　＼
　( /￣∪　　　　　　　　　　　　 ∪￣＼)

[会員の行動選択]
会員--（入会申請を行う）-->カウンター

　∧＿∧　　　　身構えて反撃してやんよ
　(　･ω･)
　(っ　　つ
　/　　　)
　( /￣∪
21 名前：仕様書無しさん mailto:sage [2008/03/31(月) 20:49:17 ]: [店員の行動選択]
会員<--（延滞警告される）--カウンター

　　　　　　　　　⊂≡⊂＝
　　　　　　　　⊂≡⊂＝
　　　　 ∧＿∧ ⊂≡⊂＝
　；;;；;、(･ω(:;(⊂＝⊂≡
　　　　(っΣ⊂≡⊂＝
　　　　/　　　⊂≡⊂＝
　　　　( /￣∪ ⊂≡⊂＝
　　　　　　　　　⊂≡⊂＝
　　　　　　　　⊂≡⊂＝
　　　　　　ﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞ
22 名前：仕様書無しさん mailto:sage [2008/03/31(月) 20:57:51 ]: [店長の行動選択]
店員<--（丹念にじっとりとチェック）--店長
　∧＿∧　　まとめてアッーしてやんよ
　(　･ω･)
　(っ　　っ　　｡　　ﾋﾟｭﾋﾟｭﾋﾟｭﾋﾟｭﾋﾟｭ
　/　　二つ゜｡ﾟ　° 。
　( /￣∪　　　｡゜　｡　｡
23 名前：仕様書無しさん [2008/03/31(月) 22:20:45 ]: OO分析、設計は、「じっくり分析設計して」、「初期の開発は冗長に時間がかかったとしても」「将来の変更を楽にする」、というのが基本だからな。

こんなの流行るわけがない。
競争原理で動いている社会なのに、そんなゆっくりやる余裕がある会社なんてほんの一握り。
24 名前：仕様書無しさん mailto:sage [2008/03/31(月) 22:34:03 ]: おじゃばじゃないけど、そこまでおじゃばのユースケース図（？）は間違ってない
ただ、一番大事なところが不足している
システムの境界線が無い
客がどうこうってのはユースケース図に書いてもいいがシステムの境界外
もし「先に言ってるからいいだろ」的なことを言い出したら、それこそユースケース図の目的を分かってない
25 名前：仕様書無しさん [2008/03/31(月) 23:03:39 ]: >>15
というか、システム構築の生産性とは、低コストにして開発サイクルの
短期化が可能かどうか、そしてメンテナンス性の向上がどれだけ画期的
に見込めるかという視点でして。

これについては、あと10年経っても状況に変化はあるような気がしない
のです。ということで。
26 名前：仕様書無しさん mailto:sage [2008/04/01(火) 01:44:43 ]: くだらないレスですまないが
開発における生産性が向上し続ければ。ある段階で保守の必要性はなくなる。
「保守するより作ったほうが早くて安い」という分岐点に到達するということだ。
これを過去に試算した人間がいる。十年ほど前だが。
この分岐点に到達するには「生産性が100倍向上すれば良い」とのこと。
・・・すまない。全然現実性のない話だ。
27 名前：仕様書無しさん mailto:sage [2008/04/01(火) 08:12:35 ]: >>23
その基本ってだれがいいだしたんだろうな。どっかのコンサル屋かね。
ときどき聞くけど。
そんなんでできるわけないのに。
基本といってもその背後には色々と前提とか裏があるから、そのまま実行に移してもムリポ。
28 名前：仕様書無しさん [2008/04/01(火) 08:34:50 ]: >>27
ぇぇぇぇ・・・・・・・・

Jランボーさんのオブジェクト指向方法論OMT読んだ？
はっきり書いてあるよ。
29 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/01(火) 09:29:38 ]: 前スレは読めなくなってしまったので、俺の最後の書き込み以降は読んでない。
誰かがアクター店員だけのクラス図書いたのか？それとも19に書かれている事程度の話か？
19に書いてある事なら、「アクターに店員と業者を入れるために無理してシステム化した」と何度も
言っているので理解して欲しい。気に入らないならアクター一人で設計してみてくれ。

>>20
20の最初の表は的確だ。確かにこのままだと打ち合いになる。これでいいのかは謎だ。
ほとんどの要求はアクターからのリクエストに変更出来ると思うが、会員登録とレンタルと返却は
無理な気がする。システム側からアクターに対して通知がある場合はどうすればいいのだろうか。
あくまでもアクターが主体としてイベントがないか確認すると言う形式にしなければならないのだろうか？

>>24
システムの境界線としては、
「カウンター」「返却箱」「仕入れ棚」「廃棄棚」「商品棚」「DVD」「料金表」
がシステム側で、それを統括して「レンタルシステム」としてみた。
これらと、「店員」「店長」「業者」「会員」の間がシステムの境界線となる。
30 名前：仕様書無しさん mailto:sage [2008/04/01(火) 10:52:34 ]: >>28
読んでない。検索してみたが絶版らしいし図書館にも無い。
はっきりなんて書いてあるの？
31 名前：仕様書無しさん mailto:sage [2008/04/01(火) 18:58:07 ]: >>23に書いてあることのうち、「じっくり分析設計」は良いとして
後の2つは今日的にはむしろ否定的な考えが主流じゃないの？

そういうポリシーを何て呼ぶのかは忘れたけど、
「仕様の変更や拡張への備えは必要最小限で」やった方が結局は無駄がないんだよね。

もちろん「必要最小限」の部分は程度問題なんだけど
32 名前：仕様書無しさん [2008/04/01(火) 19:35:43 ]: >>28
絶版だったのか。OO分析設計の原点というか、聖典だったはずだが。

１．４　オブジェクト指向開発の有効性の根拠
（略）
オブジェクト指向開発による主な利益は開発時間の短縮ではない。
オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである。
（略）
33 名前：仕様書無しさん mailto:sage [2008/04/01(火) 19:38:16 ]: >>32
それだけ読むとえらい予防線はってる、と思うわけだがw
34 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/01(火) 20:00:16 ]: >>25,26
その生産性の向上と言うのは、いくつかの方法で進んでいる。
OOもその一つと言えなくもないが、もっと劇的なのはミドルウェアの充実と、簡易言語の登場だろう。
ミドルウェアの充実と言うのは、DBのような物も含む。もしDBと同じ事をファイル操作関数で
やっていたら、大変な手間になっているだろう。またPHPなどの用途を特化した言語の登場も見逃せない。
PHPで簡単に作れる物でも、Cでゼロから作ったら大変な手間だろう。
だからその点では確実に進んでいる。
しかし逆に足を引っ張っている所がある。それは人員管理だ。
能力主義が普及してからかなりの時間が経ち、今の中堅PGは先輩から何も教えてもらわなかった世代だ。
彼らは人により能力に大きな開きがある。しかも我流の人が多く、教える事に慣れていない人も多い。
25の言う生産性を向上させる方法で、最も有効なのは、作った人間に保守させる事である。
しかし通常、ベテランを保守に占有させることは、営業的な面から困難だ。
そのため、普通はベテランに新人を付けて、開発時から一緒にやらせて、保守フェーズになったら
新人に引き継ぐという方法をとる。しかし今やこの方法は崩れてしまった。
まず新人を入れる予算がない。あっても、ベテランが新人を教育しない。ベテランのスキルもまばらだ。
それ以前に、製造を海外に丸投げする例も多い。結果、優秀な人間なら数人で作れる物を、
数倍の人間をかけて作成し、誰が作ったかも分からない物を、システムの目的も知らない人が保守する。
これが生産性を落としている原因となっている。
35 名前：仕様書無しさん [2008/04/01(火) 20:07:57 ]: ・開発側：将来の保守性のためにしっかり分析設計してきっちり作りたい。やっぱりOO。
・営業側：いいから安く早く作れよ。客の気分に合わせて当初の想定外の機能も作れよな。1日で。予算3万円で。死んでもやれ。

OOの普及以前の問題。
36 名前：仕様書無しさん mailto:sage [2008/04/01(火) 20:28:15 ]: >34
で？
37 名前：仕様書無しさん mailto:sage [2008/04/01(火) 20:31:19 ]: 開発の生産性が上がらない理由に、
なぜ開発後の保守が関係するのかさっぱりわからん
38 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/01(火) 20:32:51 ]: >>23
適材適所だろう。
常に変更が見込まれる分野においては、劇的な効果がある事もある。
DVDレンタルシステムにしても、もし店舗での貸出しかなければ、構造化で最小限作った方が早い。
しかし、正しく設計してあれば、アクターやシステム要素の変更も容易なはずだ。
つまりネットでの貸し出しや、CDや本の貸出への変更も容易なはずだ。
ただ、DVDレンタルではやはり効果は薄いと思う。ネット対応は作り直した方が早いかもしれない。

最も効果があるのは、ネットゲームだろう。今のネットゲームは新しい要素を入れて行かないと、
すぐにユーザに飽きられてしまう。新しいマップ、アイテム、魔法、モンスター、シナリオなどを増やす
必要があるし、場合によっては基本システムすらを拡張する必要さえある。
新しい要素を入れるたびに作り直していたのでは間に合わない。
逆に言うとこのような特殊な分野で効果を発揮する物であって、全てに対して効果がある物ではないだろう。
39 名前：仕様書無しさん mailto:sage [2008/04/01(火) 20:37:04 ]: >>38
それからどした
40 名前：仕様書無しさん mailto:sage [2008/04/01(火) 20:38:01 ]: なんもかんもダンプ出力するのをやめろ
41 名前：仕様書無しさん mailto:sage [2008/04/01(火) 20:41:12 ]: >>40
しーっ、この子はこれで何かした気になってるんだからそっとしておこうよ。
42 名前：仕様書無しさん mailto:sage [2008/04/01(火) 20:43:21 ]: ネトゲしたことないのか
43 名前：仕様書無しさん mailto:sage [2008/04/01(火) 22:27:13 ]: >>35
粗製乱造する仕事ばかりさせられてると、プログラマーもいやになっちまうよな。
長年修行した大工なのにほったて小屋ばかり作らされるというか。
プログラミングは本来、芸術的なものだと思うんだが、仕事ならそんなことはいってられない。

漏れは仕事で書くのやめて趣味で書くようになったんだが、今すげーおもしろいよ。
無数のクラスがまるで生き物のように分裂・変化をくりかえしながら成長していく過程や
自分の知識が一つのアプリに結晶化していくのをみると幸せ。
44 名前：仕様書無しさん mailto:sage [2008/04/01(火) 23:27:30 ]: 趣味で書くなら、もうクラスベースな言語自体使わないなぁ
クラスベースだと所詮は静的な設計が先にありきになるから、変化に弱いでしょ
弱いってか、ちょっとした変化を起こすための実装コストがやたらと高い
45 名前：仕様書無しさん mailto:sage [2008/04/02(水) 00:33:51 ]: >>44
規模によると思う。小さいアプリだとクラスベースにしても割高。
アプリの成長過程で分岐点があって、クラスベースでないとつらくなってくる地点があると思う。
この地点を知ると、クラスの粒度をどのあたりに設定するか、それまでとは切り口が変わってくる。
この分岐点に直面したことがあるかないかが、ＰＧたちの主義を二分するんじゃないかな。

テレビカメラだの音声ユニットだのそういうパーツを作るのがミクロ的だとすると、
それを組み合わせてロボットをこさえるのはマクロ的という意味合いなんだけど、
設計の変化にはマクロ的な視点での変化とミクロ的な変化があって、
オブジェクト指向はマクロ的なところでの変化には強いと思うけど。

最終的にはオブジェクト指向も用途によるということなんだが。
46 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/02(水) 19:38:41 ]: 規模というより人数ではないか？
OOの柔軟性を利用して、素人が作ったひどい部分を後から作り直すのだろう？
47 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/02(水) 19:41:35 ]: >>44
クラスベースは変化に強い。作り方を間違っているのだろう。
ちなみにクラスを使って構造化で作ると、とんでもなく変化に弱い物になる。
48 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/02(水) 20:00:20 ]: さて、DVDレンタルシステムのユースケース図を作成したが、これをどうやってクラス図にするのだろうか？
普通の考えれば、システムとその要素をクラスにして、ユースケースをメソッドにする。
しかしシステムから通知される部分はどうなるのだろうか？またアクターはどう表現するのだろうか？
アクターをクラスにしないとすると、ただの構造化でマスターメンテを作るのと違いが分からない。
まあ、よく分からないので、全部クラスにしてみる。
アクターもクラス、システムの要素もクラスにしよう。そうなるとアクターとシステムの殴り合いになるが、
その間のやり取りをレンタルシステムと言うクラスで、カバーしてみようかと思う。
かなり無茶だが面白そうだ。明らかに構造化とは違うし、成功すれば柔軟性も出る気がする。
49 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/02(水) 20:26:08 ]: class カウンター{
　set入会申請();
　set退会申請();
　setDVDを借りる();
　set延滞料金を払う();
　get延滞警告される();
　get入会のチェック();
　get退会のチェック();
　get貸し出し条件のチェック()
　get延滞チェック();
};
class 商品棚{
　getDVDを選ばせる();
　get廃棄チェック();
　set廃棄条件の設定();
};
class 返却棚{
　setDVDを返す();
　get返却条件のチェック();
};
50 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/02(水) 20:26:32 ]: class 仕入れ棚{
　get仕入れチェック();
　get新作DVD一覧の参照();
　setDVD発注();
　set新作DVD一覧の設定();
　get注文DVD一覧の参照();
　set納入();
};
class 廃棄棚{
　get廃棄();
};
class 料金表{
　set料金の設定();
};
51 名前：仕様書無しさん mailto:sage [2008/04/02(水) 20:28:35 ]: >48
なにいってるんだ?
ってか、相手しちゃだめな人?
52 名前：仕様書無しさん mailto:sage [2008/04/02(水) 21:42:44 ]: レスはすべてsageないし、他人の意見には耳を貸さない
まともに相手にされなくともレスし続ける自分をかっこいいとすら思ってる
いつも同じことしかできない壊れたジュークを相手にしちゃいけない
53 名前：仕様書無しさん mailto:sage [2008/04/02(水) 21:46:39 ]: >52
ｔｈｘ
登録しとくｗ
54 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:18:39 ]: >>48-50
基礎からやり直せ
55 名前：仕様書無しさん [2008/04/02(水) 22:20:16 ]: >>49-50
俺の部下がこんな設計出してきたらどうしよう・・・
56 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:20:42 ]: 今までのはただの馬鹿な設計者レベルだったが
>>49-50は犯罪レベルだな
57 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:30:55 ]: >>49-50
ｸｿﾜﾛﾀｗｗｗ
58 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:42:14 ]: バカおじゃば、おまいは素直で応用のきかない園児か
だから俺理論を展開するんじゃなくてせめて本読んで基礎を押さえてからにしろとあれほd(ry
59 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:50:32 ]: >>49-50に足りないであろうクラスを補完して
クラス図をおこそうとしたら、テラカオスな状態にｗｗｗ
60 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:56:35 ]: 　get廃棄();
が秀逸すぎる。
呼ぶのはバイトか？ホームレスか？
61 名前：仕様書無しさん mailto:sage [2008/04/02(水) 22:56:37 ]: 相互参照と循環参照が発生しまくりそうなんだけど
62 名前：仕様書無しさん [2008/04/02(水) 23:11:54 ]: >>60
ﾌｲﾀｗｗｗｗｗｗｗｗ
63 名前：仕様書無しさん [2008/04/02(水) 23:19:24 ]: class おじゃばさま {
　getクラス設計();
　get煽られる();
　getクラス再設計();
};

class 名無し {
　get煽る();
};

出来た！
64 名前：仕様書無しさん mailto:sage [2008/04/02(水) 23:22:09 ]: かなりひどいが分析も設計もできない子だから仕方ないんだろ
おじゃば、ヒントやるよ
商品棚クラス、返却棚クラスは不要だ
業態を考えればわかるはず
メソッドも変だな　DVDを選ばせる、じゃなくて、客が何かを選ぶ　が正解

よく考えてみろ
ステータスが変わるものはなんだ？
客の状態が変わるのか？違うだろ
根本のクラスは、商品（CD、DVD、VHS）だろ
それらが、店にあるかないか、誰が借りてるか、いくらか、いつ購入したか、廃棄したか、
だろ
ちょっといかんぞ
65 名前：仕様書無しさん mailto:sage [2008/04/02(水) 23:24:41 ]: ヒントじゃなくて答え
66 名前：仕様書無しさん mailto:sage [2008/04/02(水) 23:46:01 ]: カススレだな
タイトルだけでお気に入りにいれたが、削除しよう……
67 名前：仕様書無しさん mailto:sage [2008/04/02(水) 23:47:16 ]: なんで自己アピールしてるの？
おじゃばがレスしたらどうすんだよ
68 名前：44 mailto:sage [2008/04/03(木) 00:00:01 ]: 予想外のレスが付いているので一応書くけど

>趣味で書くなら、もうクラスベースな言語自体使わないなぁ

の後ろは当然
「プロトタイプベースな言語を使うよ」

が省略されています。
（クラスベース⇔プロトタイプベースってのは常識だと思うけど・・・）

オブジェクト指向vs構造化みたいな話は誰もしてないです。
69 名前：仕様書無しさん mailto:sage [2008/04/03(木) 00:06:08 ]: おじゃばじゃないんだから常識とか言うなよ
70 名前：44 mailto:sage [2008/04/03(木) 00:09:26 ]: googleで「クラスベース」で検索した結果からも、
これはまぁ常識と言っていいんじゃ？
71 名前：仕様書無しさん mailto:sage [2008/04/03(木) 00:24:50 ]: 見習いの俺がプロトタイプベースについて勉強してきた。

で…
クラスベースとプロトタイプベースを併せたら最強？
72 名前：仕様書無しさん mailto:sage [2008/04/03(木) 00:34:20 ]: 二兎追うものは一兎も得んぞ。利便性と性能はいつでもトレードオフ。
お手軽にやりたい時はプロトタイプベースかもなぁ。作ってて面白いし。
73 名前：仕様書無しさん mailto:sage [2008/04/03(木) 01:27:18 ]: お手軽な言語ではお手軽なもんしかつくれんよ
そこもトレードオフな
74 名前：仕様書無しさん mailto:sage [2008/04/03(木) 01:51:01 ]: >>72
プロトタイプベースな言語は具体的になにを使ってるの？
75 名前：仕様書無しさん mailto:sage [2008/04/03(木) 08:24:32 ]: >>71
rubyか？
76 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 09:40:20 ]: とりあえず「-->」をset、「<--」をgetにしてみた。

>>58
ユースケース図をクラス図に変換する方法が書かれた物は見たことがない。

>>59、61
確かにカオスだ。本当にユースケースからクラス図が作れるのか疑問に思っている。
もしかしたらユースケース図は、要求仕様を抽出ためだけの物のような気がしてきた。

>>64
ユースケースを見ると「getDVDを選ばせる();」は間違いなので、「setDVDを選ぶ();」にする。
ただ、「基本クラスはDVD～」については、言いたい事は分かるが、ユースケース図をクラス図にすると
言う企画なので、DVDを出すならユースケースから書いてくれ。
77 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 09:47:58 ]: カウンターが気になる。入会処理とレンタル処理は種類が違う気がする。分けよう。
class 入会カウンター{
　set入会申請();　set退会申請();
};
class レンタルカウンター{
　setDVDを借りる();　set延滞料金を払う();
　get延滞警告される();　get入会のチェック();　get退会のチェック();
　get貸し出し条件のチェック();　get延滞チェック();
};
class 商品棚{
　setDVDを選らぶ();
　get廃棄チェック();　set廃棄条件の設定();
};
class 返却棚{
　setDVDを返す();
　get返却条件のチェック();
};
class 仕入れ棚{
　get仕入れチェック();　get新作DVD一覧の参照();　get注文DVD一覧の参照();
　setDVD発注();　set新作DVD一覧の設定();　set納入();
};
class 廃棄棚{
　get廃棄();
};
class 料金表{
　set料金の設定();
};
78 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 09:50:57 ]: アクターをクラスにしたとして、メソッドはどうするか。
システム要素クラスのメソッドのうち、setをアクター側に持って行ってみようか。
79 名前：仕様書無しさん mailto:sage [2008/04/03(木) 13:11:20 ]: そもそも、ユースケースは「システム化の範囲」を示すもの
ユースケースからクラス図が作れるというのが間違いのもと

それ以前のもんだいとしてgetter/setterしかないクラスってすごい違和感がある
例えば会員IDとかDVDのIDは最低必要じゃないのか？
そして、そのIDは誰が管理するのかを決める必要はないのか？

これではOOPLを使ってスパゲティコードを作っているだけだ
80 名前：仕様書無しさん mailto:sage [2008/04/03(木) 13:24:10 ]: OOP => オブジェクトオリエンテッドパスタ
81 名前：仕様書無しさん mailto:sage [2008/04/03(木) 14:50:03 ]: おじゃばの擬似コード？、getだのsetだのつけてるからjavaっぽく見えるだけだよ。
getsetとっぱらって、各メソッド？名の後ろに処理()ってつけてみなよ。
OOどころか見事に手続き型設計だから。それでも穴ありまくりだけどさ。
module 仕入れ棚{
　仕入れチェック処理();　新作DVD一覧の参照処理();　注文DVD一覧の参照処理();
　DVD発注処理();　新作DVD一覧の設定処理();　納入処理();
};
module 廃棄棚{
　廃棄処理();
};
module 料金表{
　料金の設定処理();
};

なぜ処理だけ先に書きたがるかといえば、本人が言うとおり
「コーディングから入る」程度の仕事しかしてないからだろうねぇ。
分析なんて背伸びしないで設計の基礎から勉強したらどうかなぁ？
82 名前：仕様書無しさん mailto:sage [2008/04/03(木) 15:27:42 ]: >>75
orz 俺、殆どクラスベースの使い方しかしてないYO。
perlから乗り換えたらマジ使いやすくて尿漏れた。

>>77
　・メンバ変数の定義
　・パブリックメソッドは、メンバ変数の値をどう変更すべきかの定義

を教えてくれ。
データ構造、メンバ変数はパブリックメソッドによりどう変わって行くかがわからんと
『おじゃば様の頭の中では』プログラムはどう動いているのかが
全然理解できん。
83 名前：仕様書無しさん mailto:sage [2008/04/03(木) 16:15:40 ]: >>77
クラス図もどきを描くほうがいい気はする。
上から順にクラス名、変数、メソッド。

例)
　　---------------------------
　　ユーザー
　　---------------------------
　　- ユーザー名
　　- 現在借りてるDVD(可変長配列)
　　- 一時登録されたDVD(可変長配列)
　　---------------------------
　　+ 返却(DVD名) : OK / NG
　　 + 延滞金額算出() : 延滞してるDVD全ての、延滞金額
　　+ 延滞金支払い(金額) : OK / NG
　　+ 一時登録(DVD名) : 一時登録OK or　延滞ありで貸し出せない or 貸出本数MAXまで到達
　　+ 新規貸出金額算出() : 一時登録されたDVDの、合計金額
　　+ 本登録(金額) : OK/NG
　　+ 一時登録クリア
　　+ ユーザー名取得 : ユーザー名
　　- 貸出本数チェック() : (一時登録されたDVDの本数 + 現在借りてるDVDの本数)
　　---------------------------
84 名前：仕様書無しさん mailto:sage [2008/04/03(木) 16:16:40 ]: 　+ 返却(DVD名) = 「- 現在借りてるDVD」から、指定されたDVDを削除。空文字はエラー。
　　　　　　　　　なけりゃ、ポップアップでエラーメッセージ出す。
　+ 延滞金額算出 = 「- 現在借りてるDVD」から延滞しているものを見つけ、延滞金額を合算。
　　　　　　　　　なけりゃ0円を返す。
　+ 延滞金支払い(金額) = 金額と「+ 延滞金額算出」の額を比較。金額のほうがデカければ
　　　　　　　　　「現在借りているDVD」の延滞金額を全てゼロにする。金額に0円以下の入力はエラー。
　+ 一時登録(DVD名) = 「- 一時登録されたDVD」にDVDを登録。空文字はエラー。
　　　　　　　　　内部的に「-貸し出し本数チェック()」で、貸出本数をチェック。
　　　　　　　　　貸出本数チェックでエラーが出たら「もう貸し出せんわ」とエラーをポップアップ。
　+ 新規貸出金額算出　= 「- 一時登録されたDVD」のリストから、貸出金額を算出する
　+ 本登録(金額) = 金額と「+ 新規貸出金額算出」の額を比較。金額の方がデカければ、
　　　　　　　　　「一時登録されたDVD」にあるDVDすべてを「現在借りているDVD」に移動する。
　　　　　　　　　金額に0円以上の入力はエラー。
　+ 一時登録クリア = 「- 一時登録されたDVD」の配列をクリア。要素を0コにする。
　+ ユーザー名取得 = ユーザー名を返す。たぶんレジのモニタに名前出すときに使う。

orz DVDの定義してないから意味不明だ。
85 名前：83-84 mailto:sage [2008/04/03(木) 16:18:01 ]: 一回目の書き出しだから、バグってても文句言わんでくれ。
二、三度書き直さないと上手く行かんのが常。
86 名前：仕様書無しさん mailto:sage [2008/04/03(木) 16:38:01 ]: ほらほらｗ
いい加減DOAに戻ろうよｗ
みんなでテーブル考えようよｗ
87 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 19:53:19 ]: >>79
やっぱりユースケースとクラス図は関係無いのか？
俺もそう思うのだが、さんざん名無し連中はユースケース図書けって言っているぞ。
ユースケース図からクラス図は作れないでOK？作れる人はいるのか？
get/setは矢印の方向に合わせて付けてみた。

>>81
だからアクターなくして、システム側だけにメソッド付けたら、構造化のマスターメンテと変わらない
のではないかと、前から言っているだろう？次にどうすればいいか教えてくれ。
88 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 20:07:08 ]: >>83
アクター側に全メソッドを付けるって事か？
で、このクラス図はどうやって作った？アクターを主体にして、アクターの行動をメソッドにした
のかと思ったが違うようだし。
89 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 20:14:41 ]: >>83
アクター側に全メソッドを付けるって事か？
で、このクラス図はどうやって作った？アクターを主体にして、アクターの行動をメソッドにした
のかと思ったが違うようだし。
90 名前：仕様書無しさん mailto:sage [2008/04/03(木) 20:17:39 ]: なんか、妙なクラス設計になってない？
いいのかなぁ……
91 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/03(木) 20:25:48 ]: せっかく途中までやったので、アクターも登場させよう。setは全部アクターに持って行く。

class 会員{　set入会申請();　set退会申請();　setDVDを借りる();　set延滞料金を払う();
　setDVDを選らぶ();　setDVDを返す();};
class 店長{　setDVD発注();　set廃棄条件の設定();　set料金の設定();};
class 業者{　set新作DVD一覧の設定();　set納入();　get廃棄();};
class 入会カウンター{};
class レンタルカウンター{
　get延滞警告される();　get入会のチェック();　get退会のチェック();
　get貸し出し条件のチェック();　get延滞チェック();};
class 商品棚{　get廃棄チェック();};
class 返却棚{　get返却条件のチェック();};
class 仕入れ棚{　get仕入れチェック();　get新作DVD一覧の参照();　get注文DVD一覧の参照();};
class 廃棄棚{};
class 料金表{};
92 名前：仕様書無しさん mailto:sage [2008/04/03(木) 20:26:26 ]: >>87
ユースケース図描けたぁだーれもいってねーよ、バカ。
だからその、やることがはっきりしてねーのにコーディングしたがんなってるだけ。
何をやるかまず決めろってるだろがよ。
93 名前：仕様書無しさん mailto:sage [2008/04/03(木) 20:27:58 ]: >>91
クラス変数とかインスタンス変数は？
94 名前：仕様書無しさん mailto:sage [2008/04/03(木) 20:42:53 ]: >>87
じゃ、それでいいじゃん、マスタメンテに合ってる仕事なんだろ。
無理にOOにして何がいいのよ。
95 名前：仕様書無しさん mailto:sage [2008/04/03(木) 20:52:40 ]: >>87
ユースケース駆動型開発の1つの例。
まずは誰かがやってることを真似て来いよ。

ttp://csx.jp/~marunomaruno/ood01.html?c=indexum00

おじゃばはレンタルビデオの話を続けたいなら
在庫管理、レンタル屋、他のもいいと思うんで、
デタラメでも、ここにある図、表、仕様書を
一通り書いてきてから、話を進めてくれ。

まぁ各人RUPとか名詞抽出法の良し悪しとか思うところあるだろうけど、
おじゃばに言っても始まらないだろ
96 名前：仕様書無しさん mailto:sage [2008/04/03(木) 22:59:23 ]: >>95
おじゃばはリンク先は読まないぞ、ユースケースからクラスを抽出する方法だけ要約すると

まず、ユースケースは「ユースケース記述」＋「ユースケース図」＝「ユースケース」で
この「ユースケース記述」の名詞に着目してエンティティを抽出してクラス図を作成する
レンタル屋だと「会員」「商品」「レンタル」
俺もこれは良し悪しあると思うが、これが一般的で標準だ

>>79
>ユースケースからクラス図が作れるというのが間違いのも
>>87
>>>79
>やっぱりユースケースとクラス図は関係無いのか？
>俺もそう思うのだが、さんざん名無し連中はユースケース図書けって言っているぞ。
普段は人の意見を聞かないのに、なんでこんな素人のアホを信じるんだ　自演か？
とにかく、ユースケース記述を書け
97 名前：仕様書無しさん mailto:sage [2008/04/03(木) 23:07:48 ]: ユースケースからいきなりクラスへの変換は無謀だろうよ。いきなりアクターをクラスにとか無茶すぎる。
とりあえずDVD貸出しについて殴り書きしてみたけど、分析手順としては下のような感じじゃねぇの？

（1）概要分析（by ユーザへのヒアリング）
[ユースケース]
・DVDを貸し出す

[シナリオ検討]
・客は店員に借りるDVDを伝え会員カードを渡す。
・店員は会員カードの有効性を確認する。
・客は泊数に応じた料金を支払う。
・店員は客にDVDを渡し会員カードを返却する。

-事前条件
・DVDの在庫があること。

-事後条件
・DVDを貸し出す。
・DVDの在庫を-1する。

（2）詳細分析（by さらにヒアリング）
・会員カードの有効性はどのように確認するのか？
・在庫の有無はどのように確認しているのか？
・泊数に応じた料金はどのように設定すのか？
:

【クラス候補（名詞）の洗い出し】
DVD、客、店員、会員カード、有効性、泊数、料金、在庫
98 名前：仕様書無しさん mailto:sage [2008/04/03(木) 23:08:32 ]: ------続き

（3）整理（わかるところから妥当性を考慮しながらクラスに分類）
●【DVD】
・DVD管理No.
・タイトル
---
・貸し出す()
・返却する()
:

●【客】
・会員番号
・名前
---
・入会する()
・退会する()

●【会員カード】（※客に従属）
・会員番号
・有効期限

●【料金】（※DVDに従属）
・泊数

。。。てな具合に（1）～（3）を繰り返しながらクラスの抽出、関連、役割分担などを詰めていく感じだとおもうが。
合わせて、MVCに則して、モデル、それと上の分析で出現していないコントローラの役割をになうクラスを検討するなど。
99 名前：仕様書無しさん mailto:sage [2008/04/04(金) 02:31:29 ]: なぜ、DVD自身に
・貸し出す()
・返却する()
が？
なぜ、客自身に
・入会する()
・退会する()
が？
100 名前：99 mailto:sage [2008/04/04(金) 03:16:15 ]: DVD, 会員には管理簿があって、
DVD管理簿に貸出(), 返却()
会員管理簿に入会(), 退会()

貸し出し/返却管理GUI(笑) がレンタルを生成
DVD, 会員をレンタルで紐付け
101 名前：仕様書無しさん mailto:sage [2008/04/04(金) 08:19:52 ]: >>99
オブジェクト指向だから
102 名前：仕様書無しさん mailto:sage [2008/04/04(金) 08:27:15 ]: 設計が変だからでしょ。
「取引」みたいなデータ型を持ち込んだ方が直感的だと思うよ
103 名前：仕様書無しさん mailto:sage [2008/04/04(金) 08:31:38 ]: 設計からダメダメさが如実に伝わってくる
これはデスマの予感

総員第一種撤退準備！
104 名前：仕様書無しさん mailto:sage [2008/04/04(金) 08:43:22 ]: デスマにはならんだろ
下から設計修正できる内容だから

でもおじゃばが相手だと修正厳しいか？
105 名前：仕様書無しさん mailto:sage [2008/04/04(金) 08:44:11 ]: OOA/D/Pを使うことを前提にした開発プロセスってユースケース駆動以外に何があんのかな？

>>99-100
殴り書きって書いてあるし、とりあえず手順としてだから、
分析結果が怪しいのはしょうが無いんじゃない？

そもそもユースケースにシステムの境界が無くて
シナリオにシステムが出てこない訳で、出発点から怪しい。

おじゃばは(俺には)アクターに客、店員をクラス化したい(システム内部に含めたい)らしい。
「客、店員」と「それらが利用するサブシステム」の両方を含むシステムを作りたいようなので
さらにその大きなシステムを利用するアクターが必要。

システム分析では、アクターは「利用者」なので、アクターはクラスになりえない。
106 名前：仕様書無しさん mailto:sage [2008/04/04(金) 19:44:03 ]: >>97-98
駄目だな、OOが分かってない
おじゃばよりレベル低いぞ
107 名前：仕様書無しさん mailto:sage [2008/04/04(金) 19:48:57 ]: とりあえず納期をまず決めてだな
108 名前：仕様書無しさん mailto:sage [2008/04/04(金) 20:11:30 ]: >>98
料金ってｗ
109 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/04(金) 20:11:49 ]: >>92
なにそれ、現実逃避？コミュニケーション拒否？前スレ読んでないとか？

>>94
一般業務を無理にOOにしたらどうなるかって言う企画だ。

>>95
読んでみた。つーか95、読んでないだろう？
クラス図の作成方法が書いてないつーか、クラス図リンク切れしている上に、中途半端のまま終わってる。
内容も項目抽出はDOAだし、途中からO/Rマッピングもどきの話になっているし、無駄なUMLを大量に作っている
割りには、クラス図1つすら出来てない。これUMLだけ勉強して挫折した人のHPだ。
人に勧めるならせめて1回は読んでくれよ。

>>96
レンタルは違うが、会員、商品はDOAだ。95のHPでの項目抽出も完全にDOAだ。DB設計してるし。
一般的って言うのはDOAで一般的と言う話だろう？あと、普段から出来るだけ人の意見を聞いてるぞ。
110 名前：仕様書無しさん [2008/04/04(金) 20:18:07 ]: VB2005で
期限付きプログラムってどうやれば作れるんですか？
111 名前：仕様書無しさん mailto:sage [2008/04/04(金) 20:31:01 ]: >>109
>一般業務を無理にOOにしたらどうなるかって言う企画だ。
そーだったのかｗ誰が始めたコトやら。
おじゃばが手続き型でしか設計できない、つかコーディングしかしないし、
いままでまともなOOA?OODだかの同意とれるようなもんも出てないから
一般業務(なにが一般なんだかおじゃばは相変わらず自分の世界だけど)では
OOは役立たずっつことでおｋ？それとも分析や設計には要らないけど、
コーディングにはあとのメンテが楽、ちゅう客には理解できない理由で役に立つから、
使わなきゃ、先端だし周りは知らないし俺教えてあげてかっこいいしくらいなもん？
112 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/04(金) 20:36:48 ]: >>97
>【クラス候補（名詞）の洗い出し】
>DVD、客、店員、会員カード、有効性、泊数、料金、在庫
DOAでない事は認めよう。抽出ポリシーは読み取れないが。
DVDのフィールドはいいとして、貸し出しすると返却するがメソッドになるのか？
DVDクラスではなく、DVD管理簿クラス？
あと、会員カードをクラスにするのか？客に従属って何？フィールド変数か継承か？
あとMVCってOOとはむしろ逆の考え方だが、それに則するってどういうことだ？ビュークラスを分離するのか？

つーか名詞で抽出ではなくて、～する人（物）で抽出と言う意味ではないのかな？
～erで抽出ならオブジェクト指向的だが。翻訳間違えているのではないか？

>>105
別に店員だけでもいい。ユースケースとクラス図が出来れば。
つーかクラス図だけでもいいから、そのクラス図を作る手順を説明しないと、他の人が設計出来ないだろう。
その手順でやれば誰がやっても同じようなクラス図が出来ると言うのが、「確立されている」と言う意味
なのだから。
113 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/04(金) 20:55:28 ]: >>111
俺は前から、通常の業務は構造化設計で設計して、オブジェクト指向プログラミングでプログラムすれば、
何の問題もなく出来ると言っている。
オブジェクト指向設計が役に立つのは、シミュレーションやゲームの分野ぐらいだろうと言った。
オブジェクト指向として設計する手順としては、システムを実際の物体として捉えて、その後に
その構成要素を抽象化して設計する方法を在庫管理で示した。それが良いのか悪いのかは分からないが。

そうしたら、OOは一般業務でも役に立つから、ビデオレンタルで設計してやると言う事になった。
設計法方としては、ユースケース図を書いてから、どうにかすると言う話だった。
で、設計者が逃走したので、俺が引き継いでいる訳だ。
だから無理に俺と張り合う必要はない。この方法は俺も分からないし、RESがなかった所を見ると、
誰も分かってない。間違えても文句は言わないからやってみたらどうだ？
114 名前：仕様書無しさん mailto:sage [2008/04/04(金) 21:12:00 ]: >>113
そうか。俺は別におじゃばと張り合う？ことはなにもないし、
一般業務とおじゃばが呼ぶもんにはOOPなんかいらねぇと思うから、それ以外は納得。
しかたなくJavaでは書いてるけど、OOPなんかじゃないシステムの方が多いだろ。
じゃ本来のスレタイにそって言えば、
(おじゃばの言う)一般業務にはオブジェクト指向は普及する必要はない
でおｋ？それともコーディングに便利程度にはあったほうがいい、つことでいいかな？
115 名前：仕様書無しさん [2008/04/05(土) 00:46:10 ]: そもそもOOを理解できていないおじゃばが何を言っても（ｒｙ
116 名前：仕様書無しさん mailto:sage [2008/04/05(土) 00:46:36 ]: > 設計者が逃走したので
>>101, >>106 がその設計者様のような気がしてならないんだが。
違ってたらスマン
117 名前：仕様書無しさん [2008/04/05(土) 01:44:09 ]: 反対するんだったらさ、対案出そうよ。馬鹿じゃないんだろ？
対案出さないんだったら、煽りとしか思えないだろ？それぐらい分かるよな？
118 名前：仕様書無しさん mailto:sage [2008/04/05(土) 02:04:41 ]: >>117 だな。特に w で終わってる奴は馬鹿の煽りの典型。
そして本人は馬鹿だということが分かっていない最悪のパターン。
ﾔﾚﾔﾚ┐(´ー｀)┌だな。悔しかったら(Ry...
119 名前：仕様書無しさん mailto:sage [2008/04/05(土) 06:31:56 ]: >>117
誰が何に反対してるのかさっぱり分からんが
いい加減な設計をしておいて
だからOOAは使えないという結論に持っていこうとすることに自分は反対だ
120 名前：仕様書無しさん mailto:sage [2008/04/05(土) 09:37:35 ]: >>109
＞つーか95、読んでないだろう？
読んだっつの。

＞無駄なUMLを大量に作っている
無駄かどうかOOA分からないくせに勝手に判断するなよ。
守破離とか、そういう言葉知らないのか？
まずは真似ろ。

面倒くさいとか良く分からないとかなら、まずちゃんとしたユースケース図を描け。
>>17はオブジェクト指向でのユースケース図じゃない。
表記法の問題ではなくて、内容としておかしい。
何度も言われているように、システムの範囲が分からない。
システムで分からなきゃ、この際プログラムと言いかえても良いよ。
それと原則として、プログラムと直接やり取りしないことは、ユースケース図には含めない。

ユースケース図を作ったら、1つ1つのユースケースに対してユースケース記述を書く。

そこまで終わってから、ようやく次に分析の粒度の粗いクラス図(ドメインモデル)の作成だ。
ユースケース図からクラス図を直接作る方法なんてねぇよ。(俺が知らないだけかも知れないが)
121 名前：仕様書無しさん mailto:sage [2008/04/05(土) 10:10:27 ]: >>120
ユースケースって何？っておじゃばにいっても無駄。つか
＞分からないくせに勝手に判断するなよ。
は誰が何度言っても、おじゃばの本質に関わる部分らしいのでｗ
言うだけ無駄。無駄無駄。
122 名前：仕様書無しさん mailto:sage [2008/04/05(土) 10:38:30 ]: >>120
システムを含まないものもユースケース図に書いていいよ
逆に書かないとダメ
その上でシステムの境界線を明確にすることが大事なんだから
123 名前：仕様書無しさん mailto:sage [2008/04/05(土) 10:45:51 ]: >>99
>なぜ、DVD自身に
>・貸し出す()
>・返却する()
>が？
貸し出しや返却があった時にDVDインスタンスへ送るメッセージのつもりなんだがまずいかな？
コードにすると次のような感じ

　 class DVD {
　　:
　　貸し出す() {
　　　:
　　　update( { rent => true } );
　　}
　　返却する() {
　　　:
　　　update( { rent => false } );
　　}
　}

ORM使えば、update()でrent フィールド（貸し出し中フラグ）を更新することになる。
124 名前：仕様書無しさん mailto:sage [2008/04/05(土) 10:46:45 ]: >>100
まぁ分析進めてけば当然、関連クラス（レンタル）も抽出されてくると思う。
管理簿クラス？の必要性は、俺にはまだちょっとわからない。

[コントローラ]　　　[DVD]　　　[レンタル]
　　　｜　貸し出す()｜　　　　　　｜
　　　｜－－－－＞｜　　　　　　｜
　　　｜　　　　　　　｜　　　　　　｜
　　　｜　　　　生成する()　　　　｜
　　　｜－－－－－－－－－＞｜
　　　｜　　　　　　　｜　　　　　　｜

>>108
料金クラスはちょっとやりすぎかもしれない。まぁ、とっかかりの分析ということで。
泊数に応じた料金を得るのに、[DVD].[料金list].get料金(泊数) みたいなのを想像
したんだが...

おじゃばへのレスは.... めんどくさいからいいや。
125 名前：仕様書無しさん mailto:sage [2008/04/05(土) 11:13:18 ]: ...と読み直してて思ったんだが、貸し出し中フラグじゃなくて、貸し出し数
の増減で管理した方がいいのかもしれない。同一タイトルなのに別インスタンス
ってのは冗長だったな。やっぱり管理簿クラスみたいなものの方がいいのかもしれん。

　　貸し出す() {
　　　:
if (rentCount < stock) // 在庫があれば
　　　 update( { "rentCount" => ++rentCount } );
}
　　}
126 名前：仕様書無しさん mailto:sage [2008/04/06(日) 16:46:50 ]: 俺がビデオ屋でバイトしていたときによくあったこと。

　・カウンターで、誰にどのＤＶＤを貸したか、その履歴を確認したい。
　⇒過去１週間のカウンター処理を時系列でさかのぼって貸し出し履歴が見たい。
　・ある客が棚からＤＶＤを持ってきて、
　　「自分が過去に借りたかどうか調べてほしい」という。
　⇒その客の貸し出し履歴（過去１年）を時系列でさかのぼって確認したい。

以上２つの要望に応えてくれないか。
俺が実務で設計する中で、こういう
"普段ほとんど使わないのに、必ず必要になり、なおかつその管理に負荷がかかるデータ"
の扱いに困ることがあるから。参考にしたい。
125 の DVD クラスではこの要望に応えるには無理があるだろう。
どんな設計が良いだろうか？
127 名前：仕様書無しさん [2008/04/06(日) 16:57:51 ]: さて、そろそろOOが普及しない理由が具体例と共に見えてきた頃だね。

客は設計者との打ち合わせなんか無視して当初の想定外の要求を出してくるよ。
何度念押ししても言ってなかったことを言い出す。
きちんと打ち合わせすれば大丈夫だとか、契約範囲外だとか、
実際の金が動いている現場でそんな強弁できるという考えが大間違い。
128 名前：126 mailto:sage [2008/04/06(日) 17:18:18 ]: >>127
だからそれは皆わかった上であえてやって「みてる」んだっての。
スレ嫁
129 名前：仕様書無しさん mailto:sage [2008/04/06(日) 17:56:51 ]: >>127
そこで言いなりになるか交渉のスキルが持てるかが、
奴隷か技術者かの分かれ目でもある。
結局我々はシステムを作るだけの作業者ではなく、
システムとユーザとのインタフェースでもあるからだ。

なんて言えたらカコイイけどなｗ
130 名前：仕様書無しさん mailto:sage [2008/04/06(日) 18:00:24 ]: >>126
「レンタル」自体を取り引きデータとして残しておけば、それを使って要件を満たせるんじゃね？
もしくは、別に履歴クラスみたいなのをつくって、取り引き履歴を残していくみたいな。
実装はDBだったら、SQLごりごりか、ORM使ってってなると思うんで、OO設計的な工夫は特にいら
ないような気もするが。そういう意味じゃなくて？
131 名前：126 mailto:sage [2008/04/06(日) 18:50:15 ]: >>130
うん、まぁそうなんだけど。
当然ながら、履歴に数百、数千件の DVD インスタンスを持たせるわけにはいかない。
そしたら、やっぱ各 DVD には何かしら ID を持たせるしかないわけでしょ。
(履歴クラスみたいなのにはその ID だけ持たせる、と)

となると、システム全体を再度見渡してみるに、
ID で管理するほうが DVD クラスを作るより、軽量に済ませられる部分が出てくるはず。
となると、DVD クラスが必要になる場面って結構少なくなるんじゃなかろうかと。
システムのあらゆるところで ID ベースの設計になり、
実装するとなると結局管理簿クラス(≒DBのラッパ)になっちゃう。

となると、"無理やりＯＯでやってみよう!"の主旨からずれてしまわない？
と疑問が沸くわけで。
しかしそれでもどこまでＯＯで表現できるのか、見てみたいわけだ。
いや、問いが漠然としてて済まないが。
132 名前：仕様書無しさん [2008/04/06(日) 18:54:18 ]: OODBで終了
133 名前：仕様書無しさん mailto:sage [2008/04/06(日) 19:35:02 ]: >>131
OOとRDBをいっしょくたに扱おうとする場合に生じる問題はずっと言われてるな。
必要とされた背景や概念が違うからしょうが無いんだけど。だけど、

・過去１週間のカウンター処理を時系列でさかのぼって貸し出し履歴が見たい。
・その客の貸し出し履歴（過去１年）を時系列でさかのぼって確認したい。

については、仮りにデータは何百万件でも、最終的に取り出すデータはせいぜい何百
件というレベルだろうから、DAOパターンを使って、抽出はSQLで、メモリに取り込ん
だ後は、OOでって考え方でやるケースが多いんじゃなかろうか。
仮りに抽出対象が何千件だったとしても、それをいっぺんに画面表示しても、見るの
が大変だと思うんで、数十件単位のページング処理いれて、抽出処理もその単位でやる
とか。
あと、最近のORMは、関連するクラス（テーブル）が実際に必要になった時に読み込む
遅延読み込みとか、独自のキャッシュ機構をもってたりして、パフォーマンスの問題や
排他の問題も工夫されているんで、全てをOOでやりたいという場合は、ORMを使うこと
になるんだと思う。ただなんにしても、この部分はある程度の工夫と妥協（あきらめ？）
が必要で、慣れるまでが大変なんで、ここがOOが敬遠される理由のひとつにもなってる。
134 名前：仕様書無しさん mailto:sage [2008/04/06(日) 20:05:29 ]: なにこの独り言。
135 名前：仕様書無しさん [2008/04/06(日) 20:11:32 ]: 要するにOOは現実の開発には適していないんだよね。
趣味でやる分にはいいんだけど。
136 名前：仕様書無しさん [2008/04/06(日) 20:17:13 ]: いらね、ですむことだな。
137 名前：仕様書無しさん mailto:sage [2008/04/06(日) 20:49:18 ]: class Cashier{

get貸し出し履歴（期間）｛

　foreach（this.rentals as rental）{

}
138 名前：仕様書無しさん mailto:sage [2008/04/06(日) 22:22:32 ]: OOって全部一人でやれれば便利なところも多いんだけど、チームや外部とやるとなると、
わかってない奴、間違った覚えかたしてる奴、ポリシーが違う奴、いろいろいるから、
かえってカオスになりやすいというか、気の合う人同士じゃないといろいろめんどい。
139 名前：仕様書無しさん mailto:sage [2008/04/06(日) 23:21:32 ]: ユースケースから直で実装クラス図に行くからおかしくなる

ユースケース→概念モデル出し→大枠のアーキ仮決め→ユースケース廻るかチェック
→ユースケース（シナリオ追加）→概念モデル追加→アーキ拡張→・・・
これがいわゆるOOAだろ
いうまでも無くここで一番だいじなのは概念モデル導出で、昔でいうところのDBテーブル設計にあたる部分
140 名前：仕様書無しさん mailto:sage [2008/04/06(日) 23:24:44 ]: 概念ユースケース書いたらロバストネス図くらい用意しようよ。
141 名前：仕様書無しさん mailto:sage [2008/04/06(日) 23:51:55 ]: >履歴に数百、数千件の DVD インスタンス
はぁ？履歴はあくまで履歴だろ？なんでDVDインスタンスまで必要なの？
142 名前：仕様書無しさん mailto:sage [2008/04/07(月) 00:28:05 ]: >>133
RDBを一つのオブジェクトとして扱えば、上手くまとまる気がする。
143 名前：仕様書無しさん mailto:sage [2008/04/07(月) 00:55:14 ]: 俺のチンコはシングルトンだが、俺のハートはマルチインスタンス。
神さまも罪な事をしてくれるぜ...
144 名前：仕様書無しさん mailto:sage [2008/04/07(月) 01:58:16 ]: メッセージの送り先が無いのか
それは神さまからの罰なんだろう
受け入れ先が無いことを受け入れろ
145 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/07(月) 09:39:51 ]: >>114
普通はJavaで書いたらOOPでやるだろう。基本システム（継承、例外）や標準クラスはOOP向きだから、
OOPでやらないと面倒な事になる。OODが一般業務に有効なのかは分からないしが、OOPは十分有効だ。

>>120
読んだなら何でクラス図がリンク切れで、クラス図への変換方法も書いてないのに書かせる？
ユースケースも何で自分で書かない？俺のを修正するぐらいなら手間もかからないだろう？
何でUMLと作成手順には詳しいのに、実際のシーケンス図やドメインモデルも出して来ない？
146 名前：仕様書無しさん mailto:sage [2008/04/07(月) 09:56:22 ]: >>145
>基本システム（継承、例外）や標準クラスはOOP向きだから、
さすが現実に大きな仕事したことがないヤツは言うことが違うねぇ。
コーディング規約とか、ドキュメント標準があるような仕事してから
一般業務だのを語ったほうが、って他のヤツもさんざん言ってたね。
まぁいいや。
147 名前：見習い mailto:sage [2008/04/07(月) 13:27:40 ]: >>146
クラスを使うな、って規約があるの？

…まさか、カプセル化やモジュール化を妨げる規約？
148 名前：仕様書無しさん mailto:sage [2008/04/07(月) 21:23:22 ]: >>145
つか>>95のページでリンク切れてる図なんて、俺のところだと無いわけだが。
おじゃばの通信環境が悪いだけじゃないの？

＞ユースケースも何で自分で書かない？俺のを修正するぐらいなら手間もかからないだろう？
＞何でUMLと作成手順には詳しいのに、実際のシーケンス図やドメインモデルも出して来ない？

そんなの面倒くさいからに決まってんじゃん。
仕事でも無いのに、おじゃばのためになんぞでそんな面倒くさいことやってられない。
何で俺が面倒くさいことまでして書かにゃならないの？

まぁ面倒くさくないところで、ユースケース図だけ。
www.dotup.org/uploda/www.dotup.org12559.jpg.html

大体おじゃばこそ、前スレで「次に何をするんだ？」と聞いておきながら、
散々言われてる「ユースケース記述を書く」ということをしないのは何故よ？
149 名前：仕様書無しさん mailto:sage [2008/04/07(月) 21:30:52 ]: 床屋の看板だから。
150 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/07(月) 23:05:49 ]: >>146
何言っている？JavaでOO禁止などのコーディング規約があるのか？
確かにCの規約を流用したままの所もあるかもしれないが、それでも普通は修正するだろう？

>>148
店員--（DVDを登録する）-->システム
店員--（DVDを削除する）-->システム
店員--（DVDを貸し出す）-->システム
店員--（DVDを返却する）-->システム
店員--（会員を登録する）-->システム
店員--（会員を削除する）-->システム
つまりこういう事だな。で次は？
ユースケース記述ってユースケース図じゃないのか？97のか？シーケンス図か？
つーか97やシーケンス図を全ユースケースに対して書くのか？膨大じゃないか？
とりあえず、148のユースケース図からクラス図を作ってくれよ。
151 名前：仕様書無しさん mailto:sage [2008/04/07(月) 23:27:45 ]: ユースケース図からクラス図なんて直に作れるわけねぇだろ。アホの相手は疲れる。
152 名前：仕様書無しさん mailto:sage [2008/04/07(月) 23:40:21 ]: ユースケース記述ってユースケース図じゃない
153 名前：152 mailto:sage [2008/04/07(月) 23:41:53 ]: 「じゃない」は「とは違う」の方の意味だ、念のため
154 名前：仕様書無しさん mailto:sage [2008/04/07(月) 23:44:37 ]: ユースケース記述ってのは自然言語で表現されるシナリオのこと
155 名前：仕様書無しさん mailto:sage [2008/04/08(火) 01:29:49 ]: ちなみに、ユースケ・サンタマリアはUMLとは関係ない。
156 名前：仕様書無しさん mailto:sage [2008/04/08(火) 06:07:47 ]: だからさ、ちゃんと基礎から学ぶ方法を身につけずに、行き当たりばったりで
流行の言葉身につけたような気になってるバカがあばれるからって
その上さらに中途半端に物教えようとしてどーすんのよ。
157 名前：仕様書無しさん mailto:sage [2008/04/08(火) 06:28:40 ]: つ　おじゃばの低能はデフォ　熱くなった方が負け
158 名前：仕様書無しさん mailto:sage [2008/04/08(火) 06:54:23 ]: OOおよびUMLがダメなのは、カタカナ語の濫用しすぎなところ
ドメイン、モデル、クラス、など一般的には聞きなれない言葉を平気に持ち出してくる
これから学ぼうとする技術者や、見せられる顧客がうんざりするのは当然

ユースケース図も、業務分析図とか業務領域図とかの名前にすればいいのに、
完全な和訳をやろうとしすぎて逆に断念し、
知らない人からすると「ユースケースってなに？」となり本末転倒

パッケージ図、コンポーネント図、アクティビティ図、コラボレーション図、ステートチャート図
ここまでくると一般的な純正日本人は完全にお手上げ
名前からどういう図なのか全く想像できない

技術者の努力不足もよくないが、
やる前にやる気を削ぐぐらい敷居を高く見せるのは完全に失敗してる
159 名前：仕様書無しさん mailto:sage [2008/04/08(火) 08:24:07 ]: では和名案をどうぞ↓
ユースケース図：
パッケージ図：
コンポーネント図：
アクティビティ図：
コラボレーション図：
ステートチャート図：
160 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/08(火) 11:12:24 ]: なんかもう、ユースケースからクラス図は絶望的っぽくなって来たので、ドメイン図をやるか。
つーかこのドメイン図ってER図だろう？完全にDOAだが仕方ない。
普通にテーブル設計してみる。
----------------------------------------------------------------------------------------
会員（会員番号、住所、氏名、生年月日、入会日、退会日）
商品（シリアル番号、DVD番号、入荷日、廃棄日）
DVD情報（DVD番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日）
料金表（料金番号、期間、金額）
料金管理（料金番号、優先順位、開始レンタル開始日、終了レンタル開始日、DVD番号、ジャンル）
貸出管理（貸出番号、シリアル番号、会員番号、貸出日、返却予定日、料金、延滞料金）
----------------------------------------------------------------------------------------
料金の所は難しいので、貸し出し時に料金管理から初期表示させて、特別料金なら手動で変更可能とする。
料金管理はレンタル開始日、DVD番号、ジャンルのANDで指定可能。省略時はNULLを指定。
貸出管理には料金表から料金と延滞料金を設定する。料金表の期間には延滞も含む。
161 名前：仕様書無しさん mailto:sage [2008/04/08(火) 11:20:41 ]: >なんかもう、ユースケースからクラス図は絶望的っぽくなって来たので、ドメイン図をやるか。

絶望しているのはみんなからあんたです。
いえ、もう1スレ目からだけど。
162 名前：仕様書無しさん mailto:sage [2008/04/08(火) 13:04:17 ]: ユースケース図：業務分析図
パッケージ図：ソフトウェア依存関係図
コンポーネント図：物理的依存関係図
アクティビティ図：拡張フローチャート
コラボレーション図：相互作用図
ステートチャート図：拡張状態遷移図

ちなみに、「ユースケース」＝「ユースケース図」＋「ユースケース記述」なんだが
www.atmarkit.co.jp/im/carc/serial/renew_uml08/renew_uml08.html
お前がやっていることはプログラム＝データ構造＋アルゴリズムなのに
アルゴリズムのみを定義してみたが、一向にプログラムにならんと言っているだけだ
163 名前：仕様書無しさん mailto:sage [2008/04/08(火) 13:09:26 ]: おじゃばは、リンク先みないし冗長な説明が嫌い。
おじゃばは、リンクも張るし冗長な説明しかしない。
164 名前：仕様書無しさん mailto:sage [2008/04/08(火) 13:20:25 ]: >>162
ちょｗ　リンク先ｗ

ttp://java-house.jp/ml/archive/j-h-b/020739.html#body
からの流れで高木さんにフルボッコにされた、あの萩本順三か。
165 名前：仕様書無しさん mailto:sage [2008/04/08(火) 15:10:44 ]: >>148 >>150
…のユースケースでシステムが用意する必要があるデータ↓

・DVD情報
・会員情報

ここからクラス図を作るんでしょ？
ちがうの？
166 名前：仕様書無しさん mailto:sage [2008/04/08(火) 16:01:48 ]: デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ
www.atmarkit.co.jp/news/analysis/200803/31/sier.html
167 名前：仕様書無しさん mailto:sage [2008/04/08(火) 17:23:12 ]: >>166
そんなもんいいから、近代的な開発手法の一つでも取り入れろよ。
168 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/08(火) 19:43:11 ]: >>162
で、ユースケース記述を書くとクラス図が出来るのか？
ユースケース図ですら関係無さそうなのに、ユースケース記述はもっと関係ないのではないか？
148から1つでいいからクラス図を作ってくれ。

>>164
「デザインパターン使えばOOだと思っている」+「UML使えばOOだと思っている」の人か。
オブジェクト指向設計が普及しない訳が分かって来たな。
169 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/08(火) 19:59:05 ]: で、ユースケース図からは無理だと言う事は分かったが、ドメイン図からは出来るのかな？
テーブル設計なら160でやった内容で、DOAならもう作れると思うが、OOはこの後どうするんだ？
170 名前：393 mailto:sage [2008/04/08(火) 21:23:34 ]: 久しぶりに、書いてみる
>>79　ユースケースからクラス図を書く人間はいっぱいいるぞ
>>109 >内容も項目抽出はDOAだし、途中からO/Rマッピングもどきの話になっているし、無駄なUMLを大量に作っている
何をもってDOAと言っているのか分からん、見てみたが一般的なオブジェクト指向分析だと思う
>>125 それは構造化
>>126 俺ならレスポンスが要求されるから、クラスメソッドで実装し直にDBにアクセスする
この時のO/Rマッピングはストアドプロシージャで行なう
>>127 それはウォーターフォール開発の問題点で、オブジェクト指向とは関係ない
ウォーターフォール開発の弱点を解決するのが反復型開発で、オブジェクト指向との相性も良い
>>131 >となると、"無理やりＯＯでやってみよう!"の主旨からずれてしまわない？
なにをもってオブジェクト指向らしいと言っているのかが分からん
>>140 ロバストネス図はそんなに詳しく無いが、ユースケースから書ける物か？概念クラス図はいらないのか？
>>146 >さすが現実に大きな仕事したことがないヤツは言うことが違うねぇ。
お前は、大規模開発やった事があるのか？あれば、それはウォーターフォール開発・反復型開発のどっちだった？
>>151 今回は皆がある程度業務理解しているレンタル屋で要件も少ないから、書けなくない（社内SEが詳しい仕様を聞かなずに作るレベル）
>>160 >つーかこのドメイン図ってER図だろう？完全にDOAだが仕方ない。
ドメイン図って何だ？パッケージ図の事かそれともクラス図か？
171 名前：仕様書無しさん mailto:sage [2008/04/08(火) 21:33:20 ]: で、おじゃばはオブジェクト指向をお前のやってる業務に普及させたいのか？
普及なんかしてないのは十分わかった。
だれもおじゃばが望む分析から設計はOOではできてない。
お前自身、分析設計はDOAでしかできない。なのになんで、
JavaにはOOPの仕組みがあるからOOは役に立つ、って話になるんだ？
OOって、COBOLで十進演算があるから便利、VBでイベント処理が簡単で便利、
それくらいの話になっちまうぞ？そんならそれでいいけどな。
172 名前：仕様書無しさん mailto:sage [2008/04/08(火) 21:41:42 ]: >>170
そんなに聞いても逃げたヤツはだめだ、ってことになると思うよ。
君OOかぶれのバカとしか見られてないし。
173 名前：仕様書無しさん [2008/04/08(火) 21:42:51 ]: > >>127 それはウォーターフォール開発の問題点で、オブジェクト指向とは関係ない
> ウォーターフォール開発の弱点を解決するのが反復型開発で、オブジェクト指向との相性も良い

それはOOを勘違いしてるよ。
ちゃんと勉強しようね。

OO分析設計は分析設計初期開発段階で保守段階の変更の可能性を十分に検討し尽くす
という前提だから効果があるのに、現実ではそんなことが不可能だから使い物にならない。

OOは、分析設計及び最初の開発のコストを高めて、保守段階のコストを下げるトレードオフ手法。
ところが現実にはOOをきちんと理解している奴がほとんどいなくて、当初のコストが上がっていることを理解せず、
平気でさらにコスト高なことをさせてしまうから「分析設計及び最初の開発のコストを高めた」のがさらに数倍のコストになり、しかも、保守段階のコストも下がらない。

結局OOは使われず、またOO離れが進み、OO理解者が減り、たまに出てくるOO好きもOO無理解者のコスト増大法によって鬱になってつぶれていく。
174 名前：仕様書無しさん mailto:sage [2008/04/08(火) 21:47:31 ]: >>173
だとするよ、理解する価値が最初から無いもんじゃない？せんずりじゃん。
175 名前：仕様書無しさん [2008/04/08(火) 21:49:09 ]: >>174
正解。
研究者が描いたズリネタで、マニア技術者がセンズリしてるだけ。
176 名前：仕様書無しさん mailto:sage [2008/04/08(火) 21:53:26 ]: OOで一番効率よいのはCOM辺りの貼り付けだけでコードがほとんど無いプログラミングじゃないか？
177 名前：仕様書無しさん mailto:sage [2008/04/08(火) 21:53:36 ]: ･･･といって、それはXXのことじゃん？ってちゃんと･･･むりむり。
178 名前：仕様書無しさん [2008/04/08(火) 21:54:39 ]: 関係者全員が完璧に理解していれば、後は設計方針とか宗教的な話だけで済むのに
そもそも全員が完璧に理解できる程易しいものじゃないので無意味。
きちんとdeployされていればうまく使える手法のはずなのに、そのdeployment手法が
まったくダメってのが悲しいね。

その良い例がおじゃば。

なんというか、OOの手詰まり感って、
超高速で動くリニアモーターカーを作ったけれど、線路は作れませんでした、
みたいな感じ。
179 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:00:12 ]: おじゃばは理解するんじゃなくて理解しろだからな～。
おじゃばが言ってるのは結局自分に対する共感であって
現実に対する妥協じゃないだよな。
180 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:01:16 ]: >>178
そこまでOOに幻想もてるのがすけーな。宗教だろそれ。俺だけが知ってることにしたいのか？
181 名前：仕様書無しさん [2008/04/08(火) 22:02:26 ]: >>180
いちおう博士号まで取ったからね。
だからダメさも良く分かってる。
182 名前：仕様書無しさん [2008/04/08(火) 22:05:18 ]: 良く言う、1人のOO理解者と99人のソルジャーのためのモデルって、
そもそも現実はそうじゃないからね。

1人のお客さん、1人のOO理解者、99人のソルジャー、
最初の1人を無視してる時点でダメ。
お客様は予想不可能、この前提が入ってないと使えない。
183 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:06:08 ]: ダメなもんで博士号をとったら、そのひとはえらい、のかも知れないね。
俺は一緒に仕事はしたくないなぁ。
184 名前：仕様書無しさん [2008/04/08(火) 22:08:43 ]: >>183
ソフトウェア工学の研究者なんて、みんな絵に書いたモチだけで論文書いてる。
この50年で現実に使い物になった研究なんて形式言語理論やら構文木がｺﾝﾊﾟｲﾗに利用されてる部分くらいだろうし。
185 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:18:10 ]: >>184
俺OOはともかくアンタには会いたくないな。プライドがないもん。
186 名前：仕様書無しさん [2008/04/08(火) 22:24:32 ]: >>185
たぶん研究ってものに対する見方が研究をしたことがある奴とない奴で違うからだろうけど、
研究の成果なんて失敗100個で成功1個出てくればいい方だよ。
失敗は成功の元だよ。
一度誰かが失敗して、問題を明らかにすることも重要。

話を戻すと、OOは失敗作。

とは言え、条件付では現時点でほぼ最良の手法。
まぁ、その条件ってのが、現実では成立しない条件だから意味が無いわけだが・・・
187 名前：393 mailto:sage [2008/04/08(火) 22:25:49 ]: >>173
>それはOOを勘違いしてるよ。
>ちゃんと勉強しようね。
オブジェクト指向と関係ないと言っているが

>>127
>客は設計者との打ち合わせなんか無視して当初の想定外の要求を出してくるよ。
>何度念押ししても言ってなかったことを言い出す。
>きちんと打ち合わせすれば大丈夫だとか、契約範囲外だとか、
>実際の金が動いている現場でそんな強弁できるという考えが大間違い。
これがオブジェクト指向特有の問題だと思うのか？
構造化では、この問題はないと思うのか？
それとも構造化を使わなければ、解決出来ると思っているのか？
そもそもUPを理解しているのか？

お前は、何だったら勉強しているんだ？
188 名前：393 mailto:sage [2008/04/08(火) 22:30:31 ]: 間違い
×それとも構造化を使わなければ、解決出来ると思っているのか？
○それとも構造化を使えば、解決出来ると思っているのか？
189 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:32:27 ]: さすがにお勉強なさっておられる人は言葉遣いに知性が現れているな。
190 名前：仕様書無しさん [2008/04/08(火) 22:33:55 ]: >>187
だから、OOと関係無い、と思ってるのはそもそもOOを勘違いしてるからという指摘だよ。

OO特有の問題なんだよ。
意図的にサイクルの前半のコストを上げて、後半のコストを下げるという、ただのトレードオフだということを理解していない奴が多すぎる。

ほぼ最古のOOの聖典、Jランボーの「オブジェクト指向方法論OMT」の１０ページ目の１２行目。
「オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである。」

従来と比べてより時間がかかる方法なんだよ。
それを理解せず、これまでと同じ程度の「再設計」「手戻り」を出せば、
従来の手法と比べて飛躍的にコストが増大する。
191 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:40:10 ]: >>190
俺はOOはモジュール化の手法だと思ってるんだけど、ちがうの？
192 名前：仕様書無しさん [2008/04/08(火) 22:48:19 ]: >>191
広義というか、特定のソフトウェア開発に対してOOを適用することを
高い抽象度で捉えたら、OOは、前半苦労して後半楽するための道具。

それが毎回適しているとも限らないし、
前半の苦労が場合によっては数倍になる可能性が高い場合には使うべきではない道具。

だから1人で長く一つのソフトを開発するにはいいんだけどね。
金を払っているということでお客さんの立場が強くて、
「どうしても」の一言でいままでの打ち合わせの話を覆される可能性があるなら
使うべきではないんだよね。
193 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:51:57 ]: というか君が前提としている内容「OOは、前半苦労して後半楽するための道具」を
誰も受け入れていないので話がかみ合わない
194 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:53:26 ]: >>192
何をどうすればコストが数倍になるんだ…
195 名前：仕様書無しさん [2008/04/08(火) 22:54:55 ]: >>193

www.ijinden.com/_c_04/James_E_Rumbaugh.html

オブジェクト指向開発についての一般的な誤解の一つに、開発が容易になり短期間で
すむはずだという見解が根強くあるが、ランボー氏は上記著書の中でその考えを明快に
否定している。

「オブジェクト指向開発による主な利益は開発時間の短縮ではない。
オブジェクト指向開発は従来の開発方法と比べてより時間のかかるものである」

「オブジェクト指向方法論ＯＭＴ」より

オブジェクト指向開発の最も顕著な利益は、コンピュータ・システムの構造が人間に分
かり易い形に構成されるという点にある。このことはそのシステムの変更時や、そのシ
ステムを土台にした次のシステムの開発時に威力を発揮する。つまり、最初に作って
それでおしまいではなく、「継続的な改変と成長の過程にこそ生きたシステムがある」
という観点に立ったときに初めてオブジェクト指向開発の本領が発揮されるのである。
このことは通常の一回限りの受託開発では往々にして忘れられるか理解されないことが
多く、特にマネージャクラスがわかっていないとプロジェクトは予算と納期の狭間で深刻
な困難に直面することになる。
196 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:58:51 ]: >>195
…それ、再開発や手戻りがあっても大丈夫って結論にならないか？
197 名前：仕様書無しさん mailto:sage [2008/04/08(火) 22:59:40 ]: >>195
わかってないなあ。

君の言葉で説得しないと意味がないんだよ。
「本を読めば書いてある」と言いたいんだろうが、
本を読んだ人は君の言葉なんか聞く意味がない。
だって君はその本に書いてある以上のことを何一つ言っていないだろう？
198 名前：仕様書無しさん [2008/04/08(火) 23:03:21 ]: >>196
良い指摘。
再開発や手戻りがあっても大丈夫、というのも程度の問題なんだよね。
お客さんが話を根底から覆すことは無い、が成立していないとダメ。
199 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:05:50 ]: >>192
＞金を払っているということで（以降

そら違うよ。
＞「どうしても」の一言でいままでの打ち合わせの話を覆される可能性があるなら
覆されるときに、さらに金と時間(というか仕様変更にかかるコスト)を客から取れ、つー話。
そこでなぁなぁに仕事を受けるからデスマーチ化する。

お客様は確かに受注側にとっては尊重すべき存在だけど、
客先の1つ2つ切っても生きていける体力が会社になければ、
まともな職場環境なんて作れない。

OOは全然関係ないな。スマン。
200 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:07:06 ]: >>198
お前はプロジェクトを白紙に戻すお客が居ると思っているのか。
それは、現実的にありえんよ。
201 名前：393 mailto:sage [2008/04/08(火) 23:07:11 ]: >>190
>意図的にサイクルの前半のコストを上げて、後半のコストを下げるという、ただのトレードオフだということを理解していない奴が多すぎる。
それと
>客は設計者との打ち合わせなんか無視して当初の想定外の要求を出してくるよ。
>何度念押ししても言ってなかったことを言い出す。
>きちんと打ち合わせすれば大丈夫だとか、契約範囲外だとか、
>実際の金が動いている現場でそんな強弁できるという考えが大間違い。
は別の話だ、ライフサイクルの話をしているだが
本当に分かっているのか？
202 名前：仕様書無しさん [2008/04/08(火) 23:08:35 ]: >>196 >>198
ちょっと補足。

お客さんが可能性A,B,C,D,Eを最初に提示して、
それに対応できるよう設計、開発しておき、実際Aのみ対応しておいて、
あとから、B,C・・・と変わっても対応可能、というのがOOの強み。

ところが現実は、お客さんが示す可能性A,B,C,D,Eどころか、
後でX,Y,Z等を出してくる。当然、A,B,C,D,E対応で高コストな分析設計開発を
していたのに、さらに再度高コストなA,B,C,D,E,X,Y,Z対応をやりなおすことになる。
203 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:09:53 ]: そもそもOOというのは系のダイナミズムに注目したところが新しいと思う。
それが適した場面はもちろんあるだろうけど、
多くの業務は「帳票」が中心にどーんと座っているわけで。
そこにインピーダンスミスマッチがあると感じるんだよな。
所詮モデリングの核心がvalue objectなんだもの。
204 名前：仕様書無しさん [2008/04/08(火) 23:12:07 ]: >>199
それも良い指摘なんだけど、客がOOのコスト高を理解していないから、
往々にして「なんでやり直しにそんなに時間、金、人がかかるんですか？」
となってしまうのよ。

>>200
白紙というか、人によっては、今までの打ち合わせを完全無視するのが平気な人も
いるんだよね。不思議な感覚だけど。まぁ決定権がある場合、1度で関係切るけど。
でも、その1回は仕方なくやるハメになる。

>>201
ライフサイクルの開始をどこに想定してる？
205 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:12:14 ]: >>202
別に再設計する必要はないだろ。
本当にOOなら。
206 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:13:05 ]: >>202
ダイアグラムのIN/OUTを柔軟に設計しておけば
想定範囲内での拡張には構造化設計でも十分に対応できますが。
207 名前：仕様書無しさん [2008/04/08(火) 23:16:42 ]: >>205
そもそもOOがうまく使える前提の場合はそうだね。再設計は不要。
たとえば一人で分析、設計、開発するケース。

ただ現実のチーム開発のほとんどはOOがうまく使えないケースが多いということ。
208 名前：仕様書無しさん [2008/04/08(火) 23:19:08 ]: >>206
そうだね。対応できるね。
まぁOOはその対応に主眼を置いただけって感じだしね。
209 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:20:55 ]: >>207
こうゆうレスを見る度に思うんだけど、
一体普段はどうやってチーム開発してるんだろうって。
210 名前：仕様書無しさん [2008/04/08(火) 23:23:32 ]: >>209
チームが悪いというか、現実のお客さんが理想的な客ばかりではなく、むしろ
無茶言い出す方が多いということよ。
211 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:24:38 ]: >>202
それはOOであるとか構造化であるとかというより、
アジャイルとか、そういう開発手法そのもの問題にならないか？

例えばプロトタイピングして、要件定義から覆るような要望があったとしたら、
OO、構造化に関わらず今までの全ての作業が無駄になる可能性が高いのでは？

その上でOOでは、許容できる手戻りや機能変更の範囲が構造化よりも大きいと思う。
212 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:27:18 ]: >>210
例えばどんな？
213 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:28:20 ]: >>210
時間をかけて設計しても、どうせ客が無茶言い出して引っくり返すから無駄
という主張にしかなっていないような気がする
分析設計手法とは無関係で、単にウォーターフォールは駄目という結論にしかならない
214 名前：仕様書無しさん [2008/04/08(火) 23:29:02 ]: >>211
お。良い理解してる希ｶﾞｽ。
ほぼそのとおりなんだけど、OOは許容できない程に手戻りした時のダメージが
構造化より大きいという感じ。

許容できる手戻りなら、その範囲も従来より広いし、ダメージも少ない。
ただ許容できない場合、一気にﾃﾞｽﾏ化。
215 名前：仕様書無しさん [2008/04/08(火) 23:30:18 ]: >>213
ちがう。ひっくり返って無駄になるコスト、再度やりなおすコストが
従来と比べてでかすぎる、と。
216 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:32:33 ]: >>215
そりゃウォーターフォールを前提にして設計に時間かけてるからだろ

「ひっくり返って無駄」という発想そのものが
ウォーターフォールに凝り固まったオールドタイプの発想だと気付け
217 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:32:42 ]: >>214
俺はOOは構造化の発展だと思ってるんだけど、ちがうの？
218 名前：仕様書無しさん [2008/04/08(火) 23:40:00 ]: >>216
現実はウォーターフォールから逃れられない面があるわけよ。
開発の外側の話も含んでしまうけど。

>>217
発展という面もあるけど、コストは全然高くなっている。
それは上の方に書いたJランボーの言葉のとおり。
219 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:43:13 ]: ドメイン図とはなんだ？
しかもERがどうとかってなんの関係があるんだ？
ドメインの意味を分かってないだろ
220 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:46:04 ]: >>218
ひっくり返ったら無駄って発想にツッコミが入ってるんですけど…

つか、設計に時間をかけてモジュール化をすると、変更に強くなるから逆にコストが下がるんですけど。
221 名前：仕様書無しさん [2008/04/08(火) 23:47:38 ]: >>220
だから変更範囲の問題なのよ。
結局、想定している変更範囲、または暗黙のうちに想定に入る変更に対応している設計開発してるだけで、想定を超えたら終了ってこと。
222 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:48:40 ]: 開発はともかく人生はウォーターフォールから逃れられないから
学問に費やしたコストはちゃんと回収しないとな
223 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:49:12 ]: >>221
…モジュール化の意味分かってる？
224 名前：仕様書無しさん [2008/04/08(火) 23:51:46 ]: >>223
モジュール化による利点は隠蔽、な。
でもそのモジュール使わない話になったら無意味ってこと。

ちょっと極端すぎる例かもしれないが、
画像表示ソフト作ってください、という話で進めてたら、客が望んでいたのは動画再生ソフトしかも表示不要でストリーミングするだけ、とかな。
モジュール化以前の問題。
まぁ極端すぎる例だが、このとき分析設計、初期開発にコストをかければかける程、
ダメージが大きい、という話。
225 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:52:17 ]: 一体おまいらは何についての解を求めようとしてるんだ？
226 名前：仕様書無しさん [2008/04/08(火) 23:53:30 ]: >>225
客はアホだという話。
227 名前：仕様書無しさん [2008/04/08(火) 23:53:58 ]: 客というか営業かもな。
228 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:55:19 ]: んー、再設計について実務経験からだけど、ちょっと思ったことがある。
とりとめもないし、個人的な短い実務経験だから、これが真だとは言えないけど。

構造化もOOもどちらも使うことがあるけど、大体許容出来ない仕様変更があった場合、
そもそも設計思想を潰してゴリ押しすることが多いように思う。実務では。
つまり仕様変更直後の開発中に、もう一度構造化やOOで分析からやり直したりはしない。

例えばグローバルなメソッドやフラグが交差するようなスパゲッティな設計とコードになる。

で、一段落してからリファクタリングする、と。
リファクタリングする時に分析から見直して、分析結果がドラスティックに変わるようなら、
OOを使っていた方が、既存の部分で利用可能なコードは少なくなるような気は、確かにする。
分析結果があまり変わらなかったら、どちらでも大して手間は変わらないかな。

まぁそういうことを言いたいわけじゃないんだろうけどね。
229 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:56:20 ]: >>224
一言いいか？愚痴スレ池
230 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:56:32 ]: 例はともかく、客自身がどういうシステムが欲しいのか
自分自身でうまく表現できないことはよくあるからな
紙芝居を作って客からOKでても、やっぱり違うと言いだす客はいるし
231 名前：仕様書無しさん [2008/04/08(火) 23:57:17 ]: 営業：「この案件、前にやったあれとかなり似てるよね？
　　　5000万で取ってきたけど大丈夫だよね？」

開発：「全然違いますから・・・
　　　前回、赤字でもあれほど使いまわしが効くように作ったのに、
　　　全く違うものなの取ってきたら前回の苦労は水の泡ですが」

これはある。
232 名前：仕様書無しさん [2008/04/08(火) 23:58:40 ]: >>229
愚痴じゃなくて質問に淡々と答えていただけなのによ・・・
233 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:58:46 ]: >>231
良くある。
そして結局無理に使いまわすことになって、とんでもないことになることも良くある。
234 名前：仕様書無しさん mailto:sage [2008/04/08(火) 23:59:49 ]: なんか自演臭がするんだが
235 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:00:07 ]: >>224
なんで隠蔽するのか分かってる？
236 名前：仕様書無しさん [2008/04/09(水) 00:03:10 ]: >>235
変更による影響範囲を小さくするためな。

ところが、モジュールを設計、開発したこと自体が無駄なケースもある、というケースでは
モジュールの設計に時間をかければかけるほど無駄と。
237 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:04:17 ]: >OOを使っていた方が、既存の部分で利用可能なコードは少なくなるような気は、確かにする。

OOだとデータと振る舞いが結合しているからな。
「分析結果がドラスティックに変わる」というのは大抵の場合
クラスへの責任の持たせ方が変わるということで
その段階でそれまでのデータと振る舞いの結合が一旦切られて
組み直されることになる。こうなるとOO設計を前提に作られている
システムは却って再利用がきかない。
238 名前：仕様書無しさん [2008/04/09(水) 00:04:39 ]: 一貫してアゲまくってるのが俺
239 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:09:25 ]: アジャイル宣言以前のオブジェクトテクノロジについて批判してるやつは自重しろよ
ランボーの本だってウォーターフォールしかなかった20年以上前の話だろ
240 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:17:32 ]: >>236
一体どんなケースだよ…
ん～と…

・白紙に戻される(これは追加料金とるよな…)
・扱うデータがかわる
・別のプログラムとコンバート

くらい？
241 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:20:31 ]: >>200
某信販会社や某銀行で実際に起こってるよ
結局債務不履行と客に訴えられ訴訟にもなってるね

銀行の方は要件レベルでおかしかったのに続行したからな・・・
242 名前：仕様書無しさん [2008/04/09(水) 00:28:39 ]: >>240
・白紙に戻される(これは追加料金とるよな…)
・扱うデータがかわる
はあった

・別のプログラムとコンバート
ってのは無かった希ｶﾞｽ
243 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:29:25 ]: >>236
>>240だとイマイチ決定打に欠けるんで今後の為に聞いておきたい。

どんなケース？
244 名前：仕様書無しさん mailto:sage [2008/04/09(水) 00:58:36 ]: >200
中止するお客はいるよ?
245 名前：>168 mailto:sage [2008/04/09(水) 01:07:15 ]: >で、ユースケース記述を書くとクラス図が出来るのか？
>ユースケース図ですら関係無さそうなのに、ユースケース記述はもっと関係ないのではないか？

ユースケース図、って単なる見出しでしかないだろ？
そのユースケースにおいてシステム(=たいていは複数のオブジェクトの連携)が何をするのかを書き出さなきゃ
話はそれからだ
246 名前：245 mailto:sage [2008/04/09(水) 01:12:38 ]: ついでにいうとロバストネス図≒概念クラス図がユースケースから作れる
247 名前：仕様書無しさん mailto:sage [2008/04/09(水) 06:13:51 ]: OOはウォーターフォールが前提、という斬新な人がいるスレはここですか？
248 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/09(水) 10:06:03 ]: >>170
簡単に言うと、DBのテーブル設計をDOAと言うんだよ。
あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。

>>171
JavaではOOPの仕組みがあるから、OODは役に立つとは言っていないだろう？
OODを普及させたいとも言っていない。
JavaやC++を使うならOOPは必須だし、どんな分野にも使えるし、普及している。
OODは特定分野にしか有効でないと思うが、どんな分野でも使えると言う名無しがいるので検証してみた
ところだ。

>>173
>OO分析設計は分析設計初期開発段階で保守段階の変更の可能性を十分に検討し尽くす
はっきり言っておくと、これは間違いだ。
設計の初期段階で変更の可能性を検討し尽くすのは構造化設計の手法で、それに限界があるので、
OO設計が出て来た。OO設計の特徴は、全てをオブジェクト単位で抽象化する事によって、
変更があろうがなかろうが、オブジェクト単位での変更を容易にするという手法だ。
初期開発コストは増大するが2倍にはならない。ソースコード換算だと構造化に比べて約1.2倍程度だ。
これを高いと見るか低いと見るかは場合によるだろう。
249 名前：仕様書無しさん mailto:sage [2008/04/09(水) 10:56:00 ]: こいつのレスは場合に寄らず間違いだらけ
250 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/09(水) 17:35:35 ]: >>178
関係者全員が完璧に理解って、普通はOOでなくてもありえないだろう。
あと、ダメなのは俺じゃなくて、「俺の示した例」だろう？
それに、OOに幻想持ち過ぎじゃないか？

>>179
では現実に対する妥協例を見せてくれ。

>>181
誰にでも分かるように出した例だから、博士じゃなくでも分かるだろう。
あと博士ならダメでない方法でクラス図まで作ってくれ。

>>245,246
つーか、自分では書けないのか？
UMLの種類と内容に詳しいが、実務ではクラス図1枚書けない人がいる。
この人はプログラムの作成経験が殆ど無いが、UMLの本だけ読みあさった、なんちゃって学者だ。
もしかして245,246は、なんちゃって学者か？
251 名前：仕様書無しさん [2008/04/09(水) 17:47:41 ]: おじゃばはうぜーから黙ってろ。
このクソキチガイ。
252 名前：仕様書無しさん mailto:sage [2008/04/09(水) 19:51:17 ]: >>251
いや、おじゃばはつっこめそうなヤツにしかレスしないし、
自分へのつっこみは手に負えないのはスルーしちゃうから
クソキチガイというよりはただの卑怯者「だと思う」よ。
自分よりできる存在に目をつぶって、ここで語りたいだけだよ。
253 名前：仕様書無しさん mailto:sage [2008/04/09(水) 21:21:43 ]: >>248 おじゃば
>あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。

自分が理解できてないものをどうやって書くつもりだったんだ？
分析や設計についてお前が正しいだの間違いだのいう発言すること自体が、間違いだろ
クラス図うんぬん言ってるが、
要件定義を聞いていきなりコーディングするお前に書けるとは思えんな
今の流れを見ても悲惨すぎて、かわいそうなぐらいだ
254 名前：仕様書無しさん mailto:sage [2008/04/09(水) 21:40:29 ]: それが分かるほどの知能は無い
255 名前：393 mailto:sage [2008/04/09(水) 22:28:34 ]: >>248
>簡単に言うと、DBのテーブル設計をDOAと言うんだよ。
それは違うだろ、DBを使わないシステムではDOAは不可能になる
DOAはPOAの対比で生まれたものだから、モジュールを設計する視点の違いだ

昨日は開発ライフサイクルの手法と開発手法を一緒にするアホが
いたから話が反れた、元に戻す為に俺なりのクラス図まで書いてみる
要件は：会員登録・貸出し・返却の基本業務から始める
まず、ユースケース図は>>148で良いと思う
抽出した要素は
　★　ＤＶＤ　★　　　　★　会員　★　　　　　★　レンタル　★
　　タイトル　　　　　　　カード番号　　　　　　　貸出日
　　入荷日　　　　　　　氏名　　　　　　　　　　　返却予定日
　　　　　　　　　　　　　　生年月日　　　　　　　　返却日
　　　　　　　　　　　　　　電話番号　　　　　　　　料金
　　　　　　　　　　　　　　郵便番号
　　　　　　　　　　　　　　住所

これから、概念レベルのクラス図を書くと、こんな感じになる
www.dotup.org/uploda/www.dotup.org14203.jpg
多重渡やロールの確認もまだしていないし、クラス自体も
まだまだ荒いと思うが「おじゃばさま」追加・修正してくれ
256 名前：仕様書無しさん mailto:sage [2008/04/09(水) 22:30:04 ]: ねぇ。あのさぁ。みなさん、特定の一人の遊び場をいつまで維持してあげるつもりなの？
全員が飽きる前に新しい人が来るからエンドレスになっているように見えるんだけど。
257 名前：仕様書無しさん mailto:sage [2008/04/09(水) 22:32:45 ]: 自分で答えを言ってるじゃん
258 名前：仕様書無しさん mailto:sage [2008/04/09(水) 22:40:24 ]: ゴールド会員とか家族会員とかはどっから出てきたんだ？
259 名前：仕様書無しさん mailto:sage [2008/04/09(水) 23:03:01 ]: なんで業者と店の人間ことかかないで
借りる関係だけ記述してるんだよ

おまえしばくぞ前○だろ貴様
260 名前：仕様書無しさん mailto:sage [2008/04/09(水) 23:11:00 ]: どちらかと言うと、DVDとビデオが分かれてるのが気になる・・・

>>259
概念クラス図にアクターなんて出て来ないべ？
釣られたか？
261 名前：仕様書無しさん mailto:sage [2008/04/09(水) 23:46:39 ]: >>255
レンタルビデオ店に法人会員なんてあるんだ。知らなかった。
これって、「レンタル」に関するクラス図だよね。オーソドックスで悪くない
クラス図だとは思うけど、家族会員と個人会員の関連がこのクラス図だとよく
分からんな。誰が誰の家族ってどうやって分かるんだろ？
262 名前：仕様書無しさん mailto:sage [2008/04/10(木) 00:01:15 ]: ユースケースを分析した
結果も出さずにいきなり実装に
近いクラス図出してくるのはどうなのよｗ
概念クラスじゃ無いだろうそれ
263 名前：仕様書無しさん mailto:sage [2008/04/10(木) 00:32:47 ]: 何も心配することはない。仕様なんてものはみんなの心の中にあるんだよ。
ほら目を閉じてごらん。きっと見えてくるから。みんなのひきった笑顔が。
264 名前：仕様書無しさん mailto:sage [2008/04/10(木) 00:46:03 ]: 何コレ

なんつーか・・・何が不足してるんだろ？
センスとか経験とかそういう根本的な部分？
265 名前：仕様書無しさん mailto:sage [2008/04/10(木) 03:49:14 ]: >>264
自分が何をしているのか、という認識がうまくできないレベルの話。
もう、おじゃばと393のキテレツOOモドキ漫才でもいいような気がしてきたよ。
266 名前：仕様書無しさん mailto:sage [2008/04/10(木) 10:55:23 ]: 文系大学でてSE職してて勘違いしてるんだろきっと
267 名前：仕様書無しさん mailto:sage [2008/04/10(木) 11:15:05 ]: デスマ突入に備えてもう少しキャラが欲しいとこだな
もっとこう絶望的な雰囲気を醸し出せるような
268 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/10(木) 12:12:07 ]: >>251
図星か。でも恥かくのがここで良かっただろう？仕事だったら悲惨だぞ。

>>252
俺は自分より出来る存在と戦ってみたいと思っている。
で、俺が無視した出来る存在って誰だ？ほとんどがレス無しか、他の人に撃沈させられてるようだが。
番号指定してくれれば、俺が参戦するが。

>>253
設計が出来ないのに、要求仕様聞いてコーディングが出来る訳ないだろう？
愚痴る暇があったら、俺のドメイン図もどきを修正して本物にしてくれよ。
269 名前：仕様書無しさん mailto:sage [2008/04/10(木) 12:13:55 ]: どっちかというと都合の悪いレスほどスルーしている傾向があるように記憶しているが
270 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/10(木) 12:37:16 ]: >>255
簡単に言い過ぎたが、DBのテーブル設計の手法で、モジュール設計すると言う意味だ。まあ言うまでもないかな。
では本題に入ろう。ユースケースから名詞を抽出して、「DVD」「会員」「レンタル」にしたののか？
-----------------------------------------------------------------
店員--（DVDを登録する）-->システム
店員--（DVDを削除する）-->システム
店員--（DVDを貸し出す）-->システム
店員--（DVDを返却する）-->システム
店員--（会員を登録する）-->システム
店員--（会員を削除する）-->システム
-----------------------------------------------------------------
ユースケースが上記だとすると、DVD、会員はいいとして、レンタルはどこから持って来た？
DVDの登録～返却を「レンタル」にしたのか？
そうすると、会員の登録、削除も「何か」にするのではないか？
271 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/10(木) 12:42:08 ]: >>269
だからどれだ？気にも止めなかったやつかな？
一例をあげてみろ。
272 名前：仕様書無しさん mailto:sage [2008/04/10(木) 12:46:59 ]: 自覚がないっておそろしい
273 名前：仕様書無しさん mailto:sage [2008/04/10(木) 12:57:32 ]: >>267
これ以上絶望的なってどんなヤツがいるのよｗ
274 名前：仕様書無しさん mailto:sage [2008/04/10(木) 14:55:06 ]: >>273
知識もなければ空気も読めないくせに
ムードメーカーを気取ってより悪いほうへヨイショする奴がほしい
アイディアに対して反対や批判ばかりでは冷戦状況を作りだすことは難しい
275 名前：仕様書無しさん mailto:sage [2008/04/10(木) 18:40:51 ]: >>268
質問にちゃんと答えな

>あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。

自分が理解できてないものをどうやって書くつもりだったんだ？
276 名前：仕様書無しさん mailto:sage [2008/04/10(木) 19:04:42 ]: おじゃばはそろそろおばかに改名した方がいいぞ
277 名前：仕様書無しさん mailto:sage [2008/04/10(木) 20:13:57 ]: >俺は自分より出来る存在と戦ってみたいと思っている。
こんなレス乞食の相手は393だけで十分。やらせておけ。
278 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/10(木) 20:20:46 ]: >>275
>>あとドメイン図の事だが、俺も良く分からないがER図もどきらしい。誰かのリンク先に書いてあった。
>自分が理解できてないものをどうやって書くつもりだったんだ？
ドメイン図は良く分からないが、ER図もどきと理解したので、テーブル設計を書いただろう？
書くつもりではなく、すでに160に書いてある。ER図の意味が分からなかったのか？

>>276
つまり俺は答えを言っていたのに、275にはどれが答えか分からなかった訳だな。
で、俺がバカになるのか？それは厳しいな。
279 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/10(木) 20:25:03 ]: >>277
虚勢を張っても、クラス図1枚出せない277は、怪しくてもクラス図を出した俺や393以下である事には変わりない。
つまり俺が乞食なら、277は乞食以下と言う事だ。
280 名前：仕様書無しさん mailto:sage [2008/04/10(木) 20:26:18 ]: らしいとかもどきとかそんな理解度で胸を張れるお前にはがっかりだ
281 名前：仕様書無しさん mailto:sage [2008/04/10(木) 20:30:43 ]: レス乞食は仕方ないなぁ。これでいいのか、ほれほれ。
282 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/10(木) 20:36:19 ]: >>281
ヤッター！！バカレスGET！！アリガトー！！
283 名前：仕様書無しさん mailto:sage [2008/04/10(木) 20:54:02 ]: ﾊｲﾊｲﾊﾞﾛｽﾊﾞﾛｽ
284 名前：仕様書無しさん mailto:sage [2008/04/10(木) 20:54:49 ]: なんでおじゃばはこのスレに粘着してるの？
285 名前：仕様書無しさん mailto:sage [2008/04/10(木) 20:59:31 ]: >>271
一例か。おれは >>269 ではないけど挙げてみるか。

>>182 からの議論がこのスレにしては珍しくそこそこまともに盛り上がっていたが
それがひとしきり終わった後のおじゃばのレス↓

> >>181
> 誰にでも分かるように出した例だから、博士じゃなくでも分かるだろう。
> あと博士ならダメでない方法でクラス図まで作ってくれ。
>
> >>245,246
> つーか、自分では書けないのか？

完全スルー。
286 名前：仕様書無しさん mailto:sage [2008/04/10(木) 21:09:31 ]: >>285
おじゃばは、お客相手にしたこと無いから言えないんだろうね。
前スレでCの呼び出し規約の話が出てアセンブリのことになっても、
嘘つき呼ばわりされるまで知らん顔決め込んでたし。
臆病、つか卑怯なんだよ、おじゃばって。そのくせ乞食だし。
287 名前：仕様書無しさん mailto:sage [2008/04/10(木) 21:18:01 ]: どっちかというと卑怯とか意図してやってるわけではなく
妄想を書いた時点で証明責任レベルまで果たしたつもりになっちゃうキチガイ系かと

つーか「証明」に必要なプロセス（所謂ソース提示など）か
ソースとしてどんなものが認められるか
このどちらかないしは両方がわかってないと思われ
理解していればここまで純粋に憶測や妄想だけ書き殴って胸を張れるわけがない
288 名前：仕様書無しさん mailto:sage [2008/04/10(木) 21:21:10 ]: >>287
そうか。キチガイならしかたないな。
289 名前：仕様書無しさん mailto:sage [2008/04/10(木) 22:16:24 ]: >>278
よくあるドメインモデルの図はクラス図だけど。
クラス図自体がER図を参考にしてる上に、
ドメインモデルにゃ操作を書かない手法もあるらしいので、
そうなると見分けは付きづらいかもな。
290 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:05:38 ]: おじゃばって、ユースケース図から名詞抽出とか、クラス図を作らせようとして、ほらほら作ってみろって、
煽っているようにみえるんだけど、これは気のせいか？それとも本当ににおじゃばはよくわかってないのか。
それにしては妙に自身満々だし...　ユースケース図で要件の全てが表現できるなんて信じるほど素人でも
あるまいし、まさか、ユースケース図とユースケース記述を取り違えているのか、それともユースケース図の
目的が本当にわかってないのか、よく、わからん。不思議な男だ。釣り？
291 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:15:01 ]: おじゃばは何がしたいん？
ユースケース図もどきを書きたいのかアクティビティ図の出来そこないを書きたいのか、
UMLにないドメイン図（意味不明）とやらを書きたいのか、
一体どうしたいん？
UMLを学習したいってことでいいの？
292 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:17:56 ]: 素直に俺らにどうか教えてくださいって
頭下げりゃいいのになこれだから変に
プライドのあるバカは扱いにくくて困る
293 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:20:38 ]: ちょっと対人関係障害気味のイタイ人だろ
ちょっと値段聞いただけで、自分の世界に入ってひたすら技術の話しまくる頭のおかしそうな秋葉原あたりの店員みたいな奴だな
294 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:23:33 ]: >290
ハッタリでしょ　どう見てもわかってる人間の発言じゃないし
それでいて自分の言ってることが正しいと思ってるみたいだから手に負えないが

>292
> プライドのあるバカは扱いにくくて困る
たまに居るけどホント手に負えない
295 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:26:02 ]: >>261
>クラス図だとは思うけど、家族会員と個人会員の関連がこのクラス図だとよく
>分からんな。誰が誰の家族ってどうやって分かるんだろ？
確かに間違っているな、修正してみる
まず家族用のクラスを追加するとして
この場合、法人会員にも同じ事が言えるから、法人・家族会員より上位の抽象概念「団体会員」を
導入する、これに「メンバー」(家族用のクラス)を関連付ける、
あと団体会員用カードも追加する、これで大丈夫か？
www.dotup.org/uploda/www.dotup.org15092.jpg

>>277
>では本題に入ろう。ユースケースから名詞を抽出して、「DVD」「会員」「レンタル」にしたののか？
俺は名詞から抽出しない、別の方法を使っている、メジャーじゃないがなかなか良い!!

>ユースケースが上記だとすると、DVD、会員はいいとして、レンタルはどこから持って来た？
レンタルはDVDと会員の関連として抽出した（関連クラス）

>DVDの登録～返却を「レンタル」にしたのか？
>そうすると、会員の登録、削除も「何か」にするのではないか？
今回は「要件：会員登録・貸出し・返却の基本業務」だけ行なう
全て俺が行なうのも駄目だと思う、そこは誰か別の奴がやってくれ

しかし概念クラス図に対するつっこみが少ないな、かなり基本的な間違いや
小さい間違いも多いだが？
一応、俺から質問だしてみる、今回のクラス図では商品の新作・準新作・旧作が
上手く表現出来ていない（入荷日からの判定と思ったが、再入荷の場合は最初から旧作になるとか問題もある）
これを上手く表現してくれ
296 名前：393 mailto:sage [2008/04/10(木) 23:27:34 ]: 295=393 名前忘れた
297 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:28:05 ]: >俺は自分より出来る存在と戦ってみたいと思っている。
こう言ってるんだから、勝負したいだけだろ。
なにがしたいのかったら、それだけ。OOも実はどうでもいいの。
勝ちたいだけだから、別に学習しなくてもいい。つか学ぶ気ナシ。
「出してみろ」「教えてくれ」を字面どおりとってはだめ。ただの挑発。
残念だが勝負の相手は393くらいしか無理。がんがれ。
298 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:31:24 ]: つ KY
299 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:41:21 ]: 弱いからこそ俺TUEEEEEしたい
という見本か
300 名前：仕様書無しさん mailto:sage [2008/04/10(木) 23:41:58 ]: >>295
＞俺は名詞から抽出しない、別の方法を使っている、
＞メジャーじゃないがなかなか良い!!
なかなか良いなら参考にしたいんで、もうちょい具体的に説明頼む。
301 名前：仕様書無しさん mailto:sage [2008/04/11(金) 00:06:29 ]: 根本的な話だが、
ユースケース図はいつ出来上がるんだ？
302 名前：仕様書無しさん mailto:sage [2008/04/11(金) 00:07:25 ]: >>300
見識ぶった言いかたをしたかっただけで、実際はそんな大した方法じゃないと思うよ。
>>295
「商品の新作・準新作・旧作」が入荷日からの判定でまずければ、レンタル開始日からの
判定とか、新旧フラグとかで判定すればいいんじゃねぇの？　でもこれって、仕様の話で、
OOとはあまり関係ない。
303 名前：仕様書無しさん mailto:sage [2008/04/11(金) 00:13:45 ]: >>278
もう少し社会人としてまともな回答があると思ってたが、
それをお前に求めるのは無理があったようだ
304 名前：>250 mailto:sage [2008/04/11(金) 02:39:05 ]: >店員--（DVDを貸し出す）-->システム
とりあえずここ、97にシナリオあるじゃん
んで、99～100あたりにクラスが
305 名前：仕様書無しさん mailto:sage [2008/04/11(金) 08:00:55 ]: >>295
とりあえず、個人会員、家族会員、法人会員の違い（何ができて、何ができない？）だけでも説明してくれ。
過去ログに見当たらないんだが。つか、要件決めないで、よく設計なんてできるな。
まぁ、お前の頭ん中では完結してるんだろうが、こういうことは明示しとかないとデスマの元だからな。
306 名前：仕様書無しさん mailto:sage [2008/04/11(金) 08:10:39 ]: >>305
誰が質問していいと言った？
末端のコーダには知る必要も資格もない
黙って俺たちの考えたとおりに作ればいいんだよ

とかいうキャラを393氏に望むのはちょっと無理かな
307 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/11(金) 09:49:41 ]: >>285
>>OO分析設計は分析設計初期開発段階で保守段階の変更の可能性を十分に検討し尽くす
>はっきり言っておくと、これは間違いだ。
>中略
>初期開発コストは増大するが2倍にはならない。ソースコード換算だと構造化に比べて約1.2倍程度だ。
248で言っているが、議題の前提条件が間違っているので、そのあたりに関する議論は意味がない。
次に誰かが言っていた、改修時の変更が容易だというのは同意だし、俺がオブジェクト単位で変更が容易
と言っている所から読み取れると思う。また大変更があった場合に対処が大変だというのは、
構造化に比べて約1.2倍と言っているので、作り直した時の影響度も読み取れるだろう。
ちなみに、客の要求が全然違っていた場合の対応を、OOでカバーしようと言うのは問題外だと言うのは
同意だし、そのあたりは他の人の意見で決着がついているように見えた。
つまり議論の大半が的外れで、それについても数人の指摘で決着がついていたので参加しなかった訳だ。
308 名前：仕様書無しさん mailto:sage [2008/04/11(金) 10:01:22 ]: オブジェクト単位で変更が容易に設計するのが大変だと言っている様に見えるのだが・・・。
おじゃばは、他人の保守や改修の経験ないが無いやり捨てＳＥ？
309 名前：仕様書無しさん mailto:sage [2008/04/11(金) 10:17:33 ]: >>308
大規模開発の経験もないみたい。ちっちゃなとこで自分だけがお山の大将してんじゃね？
310 名前：仕様書無しさん mailto:sage [2008/04/11(金) 16:14:38 ]: しかしなんだな
OOをちゃんと理解していないとOOの利点を生かせないとなると
大規模開発ではちゃんと理解していないSE/PGが一人でも混じっていたらアウトということになる
派遣や偽装請負が盛んなこのご時世に背信者を完全に排除するのは無理のような気がするが
311 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/11(金) 20:02:51 ]: >>290
前にも書いたが、ユースケース図からクラス図を作る方法は分からない。
俺はユースケース図は要求仕様をまとめるだけの物と思っていたが、違うと言っている名無しがいるので
検証している。

>>291
前から言っているが、ユースケース図からクラス図が作れるのかを見たい。
ダメなら別の方法でもいいから、俺の抽象化以外の方法で、クラス図を作る方法が見たい。

>>292
教えてください、お願いします。つまらないプライドはありません。
312 名前：仕様書無しさん mailto:sage [2008/04/11(金) 20:09:47 ]: >>311
嘘くせぇよｗ、つか嘘もそこまで図々しけりゃ大変なもんだ。
みんな言ってるけど、何したいんだお前？こんなとこで勝負してるヒマあったら
本なりネットなりで勉強すればいいじゃん。お山の大将だから勝負したいだけだろ？
313 名前：仕様書無しさん mailto:sage [2008/04/11(金) 20:10:23 ]: >>307
的外れはお前。
つーかOOを何一つ理解せずにOOを語ろうとするな。
このクソ荒らしが。
314 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/11(金) 20:54:20 ]: >>295
DVD、会員、レンタルを抽出した方法が分からないので、コメントが難しい。
ユースケース図とは関係ないと言う事だな。本人も抽出方法は認識していないように思える。
手順を明確化しないと本人しか出来ないので、分析してみる。
システムは、「会員」が「DVD」を「レンタル」する物との認識で、「誰」が「何」を「どうする」で
抽出したのだろうか？それぐらいしか思い当たらない。

次にクラス図を見てみよう。
まず、抽出された会員、DVD、レンタルの使われ方が良く分からない。
会員はすでに分割されているし、DVDは要素のひとつに追いやられている（レンタル商品に変わった？）し、
レンタルはレンタルするになった（？）ようだ。イマイチ抽出したのかな要素との関連が不明だ
次に、俺の考えていた仕様では、ツタヤの店舗貸しを想定していたので、ゴールドカードも、
家族会員もない。ビデオも捨ててDVDのみにしたと思うし、料金も通常料金と特別料金の分類で
ツタヤの料金体系を表現出来るのか謎だ。電話と住所を分けた理由も不明だ。俺は延滞時の連絡先
を想定していたが、別の用途を想定しているのか？
つまり、ツタヤの店舗レンタルとは全く別物に見える。
ツタヤレンタルではなく、295の考えるオリジナルレンタルを想定しているのか？
それともツタヤレンタルをベースに、今後考えられる拡張を想定して設計したのか？
どうも関連や目的が掴みにくくて、コメントが難しい。
315 名前：仕様書無しさん mailto:sage [2008/04/11(金) 22:09:09 ]: ボケるならちゃんとボケろ、つっこむなら上手くつっこめ、あ゛ーイライラする、この馬鹿コンビ
316 名前：仕様書無しさん mailto:sage [2008/04/11(金) 23:05:07 ]: 空気読まずに暇つぶしの結果を投下。

>>148のユースケースを4つぐらいあわせて機械的に分析してみた。
www.uploda.org/uporg1363351.zip.html

実務でこんなやり方はしないケド。
317 名前：仕様書無しさん mailto:sage [2008/04/11(金) 23:10:44 ]: 原田ウイルス入りとか
舐めてるなｗ
318 名前：>314 mailto:sage [2008/04/12(土) 01:14:50 ]: * バウンダリ
* エンティティ
* コントロール
が、いろはのい
だよ

>システムは、「会員」が「DVD」を「レンタル」する物との認識で、「誰」が「何」を「どうする」で
>抽出したのだろうか？それぐらいしか思い当たらない。
319 名前：仕様書無しさん mailto:sage [2008/04/12(土) 11:25:05 ]: またロバストネス厨か
320 名前：>311 mailto:sage [2008/04/12(土) 14:48:14 ]: ユースケース図とユースケース記述は違うと何度言ったら(ry

も前さんは見出しタイトルだけ見て内容が分かるエスパーかw
321 名前：仕様書無しさん mailto:sage [2008/04/12(土) 15:54:51 ]: おじゃばが、
ユースケース図 →　ユースケース記述（→　ロバストネス分析） →　クラス図
でなく、
ユースケース図 →　クラス図
と思いこんでるのはもはや確定。まさかと思っていたが。
というか、こんだけ指摘されてもまるで気づかないバカさ加減にうんざりする。
おじゃばの頭の中は、「ユースケース＝ユースケース図」という観念で凝り固まっているのだろう。
322 名前：仕様書無しさん mailto:sage [2008/04/12(土) 16:01:45 ]: 訂正。
どうやら、おじゃばは
「ユースケース＝ユースケース図＝ただのお絵書き」
と思っている節がある。要求分析を完全になめてる。
323 名前：仕様書無しさん mailto:sage [2008/04/12(土) 16:06:25 ]: >>322
なめてる、ってかコーディングからはじめちゃって他のヤツより仕事早いぜすげぇだろ俺、
とかマジで言うバカ丸出しのヤツがそんなもん理解できるワケねぇだろ。高望みするなよｗ
324 名前：仕様書無しさん mailto:sage [2008/04/12(土) 16:37:00 ]: おじゃばがバカ理論を展開しながら偉そうに、「まず」とか「次に」とか
書く度に俺のイライラ具合は次第に最高潮に達していく。
「熱くなった方が負け」なのは分かっているんだが。
325 名前：仕様書無しさん mailto:sage [2008/04/12(土) 17:00:44 ]: 気持ちはわからんでもないが・・・
こーゆータイプの人間はウザいしな

接続語があるがゆえに一見それっぽい文章なくせして
全て根拠のない自信を拠り所にしてるため
まともなところがひとつもないのが特に手に負えない
つーか接続語の使い方も滅茶だし
挙げ句妄想だけで話を進めておきながらわからないヤツが悪いと来る
所謂キチガイなんでしょうな
326 名前：仕様書無しさん mailto:sage [2008/04/12(土) 17:03:04 ]: ・妄想なのに勝ち気
・自分が理解できないと罵倒する

とにかくおじゃばは最低レベルの人間
327 名前：仕様書無しさん mailto:sage [2008/04/12(土) 17:03:35 ]: 245 ：>168：2008/04/09(水) 01:07:15
>で、ユースケース記述を書くとクラス図が出来るのか？
>ユースケース図ですら関係無さそうなのに、ユースケース記述はもっと関係ないのではないか？

ユースケース図、って単なる見出しでしかないだろ？
そのユースケースにおいてシステム(=たいていは複数のオブジェクトの連携)が何をするのかを書き出さなきゃ
話はそれからだ

246 ：245：2008/04/09(水) 01:12:38
ついでにいうとロバストネス図≒概念クラス図がユースケースから作れる

> >>245,246
> つーか、自分では書けないのか？

完全スルー。
328 名前：仕様書無しさん mailto:sage [2008/04/12(土) 17:08:56 ]: >>327
おじゃばは自分でわからないことはそうやって挑発するから、
余り指摘するような親切はしないほうがいいだろ、
それしたって、そうだったごめんとは言わないから。
キチガイを論理的にやりこめようとするのは無駄なことだし。
329 名前：仕様書無しさん mailto:sage [2008/04/12(土) 17:20:11 ]: くやしぃのう
330 名前：仕様書無しさん mailto:sage [2008/04/12(土) 17:44:41 ]: だから、>>1にあるようにスルー技術を、だな。
どうしてもむかついたらキチガイ乙、とでも書く程度のがいいんじゃまいか。
331 名前：393 mailto:sage [2008/04/12(土) 18:48:13 ]: >>300 >>302見たいな奴がいるから書かない
>>301 >>148が書いていたが
>>302
>「商品の新作・準新作・旧作」が入荷日からの判定でまずければ、レンタル開始日からの
>判定とか、新旧フラグとかで判定すればいいんじゃねぇの？　でもこれって、仕様の話で、
>OOとはあまり関係ない。
オブジェクト指向の話をしているんだが、なんで構造化なんだ？分かっているか？
「仕様の話で、OOとはあまり関係ない。」仕様をどうモデリングしてシステムに組込むか、を話しているんだが．．．
>>308　それは最初は、>>127の話か？それなら、「博士号」が間違っているが
>>311 業務知識も無く、いきなりユースケース「図」だけ渡されても概念クラス図は完成出来ないが、誰が言ったんだ？

>>314
>DVD、会員、レンタルを抽出した方法が分からないので、コメントが難しい。
>ユースケース図とは関係ないと言う事だな。本人も抽出方法は認識していないように思える。
概念クラスの抽出方法と言うことか？簡単に説明するが自分で勉強しろ
まず、初期段階にはユースケースが必ず必須と言う訳では無い『手法』による
（自分が知っている手法だけが正しいと思っている奴が多すぎる）
今回の「DVD」と「会員」は、『もの』として抽出した
これは何でか分かるよな？、レンタル店業務を『もの』『こと』で分類した場合『もの』は「DVD」と「会員」となる
その「DVD」・「会員」の関連として「レンタル」を抽出した、ここまでが静的モデルになる

>会員はすでに分割されているし、DVDは要素のひとつに追いやられている（レンタル商品に変わった？）し、
拡張を想定して作ってある、実装はしないが拡張を想定して分析・設計した方が良い（この段階ならコストもあまり掛からない）
将来「Blu-ray Disc」などが追加されても、このモデリングなら一商品が増えるだけだから、修正コストも軽減できると思うが
332 名前：仕様書無しさん mailto:sage [2008/04/12(土) 19:39:19 ]: わはは、がまんできねぇででてきやがんのｗ
333 名前：仕様書無しさん mailto:sage [2008/04/12(土) 19:43:07 ]: プロジェクトが妄想なら顧客もいないわけで
モデルが正しいかどうか誰がどうやって決めるんだろう
334 名前：仕様書無しさん mailto:sage [2008/04/12(土) 20:09:58 ]: >>333
本人が決めるんだろ。本人が設計して、本人が正しいかどうか判断する。
お気楽、極楽。くだらんお遊びだな。
335 名前：仕様書無しさん mailto:sage [2008/04/12(土) 20:14:08 ]: 聖火ゲームの仕様
つくろうよ
336 名前：仕様書無しさん mailto:sage [2008/04/12(土) 20:23:17 ]: >>391
「仕様をどうモデリングしてシステムに組込むか、を話しているんだが」

だからその仕様の話をちゃんとしてくれよ。お前の頭の中にあるレンタル業務
での「家族会員」、「法人会員」、「ゴールドカード」の要件をちゃんと説明
してくれよ。それがわからなきゃ分析しようもないだろ。それぐらい分からんか？
まるで馬鹿な客か素人を相手にしてるようだ。俺たちゃエスパーじゃねぇっつうの。
337 名前：仕様書無しさん mailto:sage [2008/04/12(土) 20:24:28 ]: >>391 に期待
338 名前：仕様書無しさん mailto:sage [2008/04/12(土) 20:27:07 ]: 来るよエスパー
339 名前：391 mailto:sage [2008/04/12(土) 20:35:28 ]: 待たせたな私が>>391だ。そして私はこのスレの>>331であり。またの名は前スレの393でもある。

では続けてどうぞ↓
340 名前：仕様書無しさん mailto:sage [2008/04/12(土) 20:36:52 ]: なんだバカか。
341 名前：仕様書無しさん mailto:sage [2008/04/12(土) 23:33:34 ]: >393
なんでそんなに相手をイラつかせるような書きぶりをするの？
342 名前：仕様書無しさん mailto:sage [2008/04/12(土) 23:34:25 ]: >394
ですね、わかります。
343 名前：仕様書無しさん mailto:sage [2008/04/13(日) 00:17:43 ]: >395
それは違うだろ
344 名前：316 mailto:sage [2008/04/13(日) 16:45:02 ]: >>317
JPEG17枚zipで固めただけで原田扱いﾋﾄﾞｽ・・・
か、入れたつもりないけど、マジでどっかでウィルス混入してた？
だったらｽﾝﾏﾍﾝ。
345 名前：仕様書無しさん mailto:sage [2008/04/13(日) 19:51:53 ]: >>344
博士、最低
346 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/14(月) 09:57:05 ]: >>312
嘘つきはお前だろう。クラス図の書き方を教えてくれるのではなかったのか？

>>313
いくら本を読んでも、実務経験が少なくて本の内容を実感出来ないと、筆者の意図と違った解釈をする。

>>316
テキストでここに書いてくれ。

>>318
なぜここでバウンダリーとエンティティーが出て来るのか分からない。

>>320-328
だから俺の書いたユースケース図に対して、全てのユースケース記述を書けというのか？
膨大な量になるぞ。それに誰かの書いたユースケース記述には、数を-1するとかあったが、
数をどこに持つのかもも決まってないのに、そんなの書けないだろう？
大体、オブジェクト分割がされてないのに、複数のオブジェクトの連携をどうやって書くのだ？
270の簡単なユースケース図からも、どれぐらいの詳細度で書けばいいの分からない。
だから、327が書いてくれ。
347 名前：仕様書無しさん mailto:sage [2008/04/14(月) 10:19:50 ]: キチガイ乙
348 名前：仕様書無しさん mailto:sage [2008/04/14(月) 12:32:31 ]: できないことを丸投げしておきながらなんでこんな態度になるんだろ
349 名前：仕様書無しさん mailto:sage [2008/04/14(月) 12:39:48 ]: >>346
氏ね。
350 名前：仕様書無しさん mailto:sage [2008/04/14(月) 20:57:33 ]: >>346
＞テキストでここに書いてくれ。
断る
351 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/14(月) 21:13:08 ]: >>331
「もの」と「こと」で分類して、「もの」を抽出した後に、その「もの」たちの関連（？）を抽出するのか？
いまいちよく分からないな。業務を日本語にして、そこから抽出したのか？
それだと人によっては、かなり違った抽出になると思うが。
デパートの売上管理とかだと、客、商品、とかなるのか？店員や売り場はどうなる？
銀行の預金システムだと、客、金か？普通預金とか定期預金とかの種類はどうなる？

クラス図は拡張を想定して作ったのか？この段階ならコストも低く抑えられる？
DVDのレンタル商品化はいいとしても、ゴールド会員や家族会員のシステムは高くつくのではないか？
実際に必要とも思えないし。大体、どういう会員システムなのか分からないな。
内容も生年月日が複数の所にあったり、メンバーとレンタル会員と会員カードが別れていたりと、
俺には到底理解出来ない構造だ。誰かが言っていたが、会員の種類によって何が変わるのかさっぱり読めない。
料金が変わるのか？ポイントが共有出来るとかか？携帯電話とクレジットカードが混じってないか？
第一、OOとは抽象化して変更を容易にするシステムだ。レンタル会員を会員として抽象化して実装するのは
いいとしても、ゴールド会員とか家族会員とかまだ必要ない物を特化して実装する意味があるのか？
ちなみにこの先、どう変更すればいいのかは分からない。俺が無理なので多分誰でも無理だろう。
きっと、331がやるしかない。クラス図完成させてみてくれ。
352 名前：仕様書無しさん mailto:sage [2008/04/14(月) 21:30:18 ]: ・まず日本語がおかしい
・頼むなら下手に出ろカス
・質問事項の合間にある「思う」の理由を書け

はい、再提出。
353 名前：仕様書無しさん mailto:sage [2008/04/14(月) 21:31:39 ]: レンタルシステム程度のユースケース記述が膨大とか、今までどんなもん作ってきたんだよ。
おじゃばは「腹が減ったが箸は持ちたくない。口元まで運んでくれ」と言ってるようなもの。
354 名前：仕様書無しさん [2008/04/14(月) 21:32:36 ]: OOのプロジェクトってOOでの設計・開発経験者じゃないと敷居高いでしょ。

自分で本読んで勉強しましたって言っても、実務じゃないもんなぁ
355 名前：仕様書無しさん mailto:sage [2008/04/14(月) 21:38:12 ]: ＞内容も生年月日が複数の所にあったり、メンバーとレンタル会員と会員カードが別れていたりと、
＞俺には到底理解出来ない構造だ。
うｐされてたクラス図保存して無いんで確認出来ないんだが、
コイツ、クラス図読めてないんじゃ無いか？

まぁ393のクラス図もどう分析した結果なのか
良く分からなかったと思った憶えがあるけども。
356 名前：仕様書無しさん mailto:sage [2008/04/14(月) 21:52:15 ]: >>351
こいつもう駄目じゃね？
357 名前：仕様書無しさん mailto:sage [2008/04/14(月) 21:58:08 ]: どっちにしてもDVDレンタルなんて今どき儲けの主力じゃないから
どうでもいい業務のIT化のために命削ってる奴らがいると思うと
無理な仕変を要求してストレス解消したくなる気持ちも分からなくもないか・・・な？
358 名前：393 mailto:sage [2008/04/14(月) 23:01:41 ]: >>351
>「もの」と「こと」で分類して、「もの」を抽出した後に、その「もの」たちの関連（？）を抽出するのか？
>いまいちよく分からないな。業務を日本語にして、そこから抽出したのか？
なんて説明すれば分かるんだ？テーブルの「マスタ」と「トランザクション」と言えば分かるか?

>それだと人によっては、かなり違った抽出になると思うが。
もちろん違うが間違いとも言えない、正解は多数あるからな

>デパートの売上管理とかだと、客、商品、とかなるのか？店員や売り場はどうなる？
デパート売上管理のシステムが分からないから推測だが
「店舗」「フロアｰ」「販売員」「商品」なんかが「もの」(マスタ)になると思う
>銀行の預金システムだと、客、金か？普通預金とか定期預金とかの種類はどうなる？
これもは、「預金通帳」「本店・支店」とかが「もの」(マスタ)になると思うが

>クラス図は拡張を想定して作ったのか？この段階ならコストも低く抑えられる？
>DVDのレンタル商品化はいいとしても、ゴールド会員や家族会員のシステムは高くつくのではないか？
>内容も生年月日が複数の所にあったり、メンバーとレンタル会員と会員カードが別れていたりと、
>俺には到底理解出来ない構造だ。誰かが言っていたが、会員の種類によって何が変わるのかさっぱり読めない。
>料金が変わるのか？ポイントが共有出来るとかか？携帯電話とクレジットカードが混じってないか？
「ゴールド会員」「家族会員」「ビデオ」は実装しないし、仕様にも無い
しかし、違った角度のクラスを導入し将来のクラス拡張を考えるのはいい事
今あるクラスだけで拡張性を考えても、なかなか上手く出来ないが
「個人会員」と違う「団体会員」を考える事で汎用性のあるクラス図に成っていく
これは俺のやり方だから、違和感があるなら、その部分は見るな
と言うか、お前らも書け
359 名前：仕様書無しさん mailto:sage [2008/04/14(月) 23:41:09 ]: 意味の無い長文をどれだけ意味ありげに書けるかを競うスレはここですか？
360 名前：仕様書無しさん mailto:sage [2008/04/14(月) 23:45:32 ]: >>359
永遠にノレンに腕押しするスレです
361 名前：仕様書無しさん mailto:sage [2008/04/15(火) 00:15:10 ]: >>346
＞だから俺の書いたユースケース図に対して、全てのユースケース記述を書けというのか？
＞膨大な量になるぞ。
RUPじゃ書くんだよ。
ユースケース10や20は全然膨大じゃないが(メンドクサイけどな)
練習でやるには多いと思うなら、ユースケース削れ。機能を削れ。
ちなみに俺はオブジェクト指向開発プロセスはRUPしか知らんので、あしからず。
他のプロセスについては、むしろ俺が聞きたい。

＞どれぐらいの詳細度で書けばいいの分からない。
>>270ぐらいだったら単純なもんだろ。
この程度のルールでメインフローだけ書いてみ。
[ルール]
1. 「(通し番号). 店員(またはシステム)は～～を～～する」という形式で書く
2. ユースケースの通し番号1は店員、システムのどちらから始めても良い
3. 動詞は、番号1つにつき基本的に1つ。多くても2つ
4. 店員から見えることだけを書く
362 名前：仕様書無しさん mailto:sage [2008/04/15(火) 02:15:21 ]: > 318 ：>314：2008/04/12(土) 01:14:50
> * バウンダリ
> * エンティティ
> * コントロール
> が、いろはのい
> だよ
>
> >システムは、「会員」が「DVD」を「レンタル」する物との認識で、「誰」が「何」を「どうする」で
> >抽出したのだろうか？それぐらいしか思い当たらない。
>
> 346 ：おじゃばさま ◆GxjxF3yEw6 ：2008/04/14(月) 09:57:05
> >>318
> なぜここでバウンダリーとエンティティーが出て来るのか分からない。

...店員が"バウンダリ"を使うことで、"コントローラ"「レンタル」を生成し、それは"エンティティ"「会員」「DVD」とひもづく
とか説明があればいいんですか？＞＜
363 名前：仕様書無しさん mailto:sage [2008/04/15(火) 07:54:16 ]: ロバスト房の言うことにマジレスいくない
364 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/15(火) 18:47:56 ]: >>358
すまんが分からない。
デパートと銀行の例を見た限りでは、少なくとも俺は358と同じ抽出は出来ないと言う事は分かった。
抽象化のために別の観点から見るのは分かったが、358やUML厨のやり方でクラス図を書くのは無理だ。
仕方ないので、俺のやり方で書いて見る。前に言った通り、設備から業務を抽象化する方法だ。
レンタルシステムはDVDを会員に移動する事によって、業務が発生するシステムだと考える。
包含関係は以下の通り。
------------------
レンタルシステム
　ショップ
　　DVD...
　　料金表
　会員...
　　DVD...
　倉庫
　　DVD...
------------------
「...」は複数存在するリストのような物と言う意味。
レンタルシステムはショップ、会員リスト、倉庫から出来ている。
ショップはDVDと料金表から出来ているとする。
365 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/15(火) 18:50:43 ]: 次にクラス化。とりあえずクラスと管理する要素を書いて見る。
-------------------------------
class ショップ{
　DVDリスト、料金表
}
class DVD extends 作品{
　シリアル番号、作品番号、入荷日
}
class 作品{
　タイトル、ジャンル、年令制限、発売日、レンタル開始日
}
class 料金表{
　期間、金額
}
class 会員{
　DVDリスト
}
class 倉庫{
　DVDリスト
}
-------------------------------
366 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/15(火) 19:52:06 ]: 次に足りない要素を追加してみる。
前述の構成では現在のDVDの場所は分かっても、過去の貸し出し履歴は分からない。
class 貸出履歴{
　シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金
}
次に貸し出し業務の動作をメソッドとして追加する。
貸出、返却、入荷、廃棄はレンタルシステムに、入会、更新、脱会は会員に持たせる。
貸出履歴には、登録、検索を持たせる。あとは適当に加えて完成とする。細かいメソッドは省略する。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{DVDリスト、料金表};
class DVD extends 作品{シリアル番号、作品番号、入荷日、貸出日：検索()};
class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、DVDリスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{DVDリスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------
367 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/15(火) 20:08:15 ]: >>361
面倒だがやってみるか。本当にクラス図に出来るのだろうな？
----------------------------------------------------------------
店員--（DVDを登録する）-->システム
01.店員はDVDの情報を入力する。
02.店員は登録ボタンを押す。
店員--（DVDを削除する）-->システム
01.店員はDVDの一覧を表示する。
02.店員は一覧から削除するDVDを選択する。
03.店員は削除ボタンを押す。
店員--（DVDを貸し出す）-->システム
01.店員は会員からDVDと会員証を受け取る。
02.店員は会員証が有効かをチェックする。
03.店員は会員から貸し出し期間を聞く。
04.店員はDVDを貸し出し登録する。
店員--（DVDを返却する）-->システム
01.店員は返却ボックスからDVDを取り出す。
02.店員はDVDを返却登録する。
店員--（会員を登録する）-->システム
01.店員は会員から必要書類を受け取る。
02.店員は会員の情報を入力する。
03.店員は登録ボタンを押す。
店員--（会員を削除する）-->システム
01.店員は会員の一覧を表示する。
02.店員は一覧から削除する会員を選択する。
03.店員は削除ボタンを押す。
368 名前：仕様書無しさん mailto:sage [2008/04/15(火) 21:56:21 ]: ここ３スレほど見てるが
何がおじゃばをここまで駆り立てるのか全く理解できない
369 名前：仕様書無しさん mailto:sage [2008/04/15(火) 22:16:10 ]: 俺もこうなんというかうまく言えないんだが、おじゃばって、素質が無いんじゃなかろうか。
370 名前：仕様書無しさん mailto:sage [2008/04/15(火) 22:39:16 ]: >>367
ごめん。
おじゃばがソコまでユースケースについて知らなかったとは思ってなかった。

ユースケースは「アクターとシステムのやり取り」を書くものなんだ。
アクターとアクターのやり取りとか、アクターがシステムと関係なく行う行動とかは書かないんだよ。
例えば
＞03.店員は会員から貸し出し期間を聞く。
とか
＞01.店員は返却ボックスからDVDを取り出す。
とか。

それと、>>367のフローだと、システムは店員に対して、一切動かないことになる。
システムが主語の文が無いから。
店員が操作しても画面は全く動かなくて、システム内部では何がしかの処理が行われている、
そういうシステムを想定してるなら、ユースケースとしてアリだとは思う。
が、多分対話的に動作することを想定してると思うので、
「客は～～」「システムは～～」が必ず交互になるように書いてみると、
ソレっぽくなるかもしれない。

例えばこんな感じ
店員--（DVDを削除する）-->システム
01.店員はDVD一覧表示ボタンを押す。
02.システムはDVDの一覧を表示する。
03.店員は一覧から削除するDVDを選択する。
04.システムは選択されたDVDを表示する。
05.店員は削除ボタンを押す。
371 名前：仕様書無しさん mailto:sage [2008/04/15(火) 22:41:55 ]: 単純に自分が間違っていないという前提に立っているだけだろう。

正しいからその論理に則るというが常人だが、自分が正しいから
その倫理が正しいというのがおじゃば。
372 名前：仕様書無しさん mailto:sage [2008/04/15(火) 22:53:48 ]: >>370
おじゃばに教えてやっても無駄だよ。教えたとおりに解釈しないし。無限ループのもとだよ。
おじゃばに教えるのは、馬の耳に拡声器で念仏を唱えるよなもんだよ。後ろ足で蹴られるよ。
373 名前：仕様書無しさん mailto:sage [2008/04/15(火) 23:02:25 ]: このスレの状況

while (true) {
if (おじゃば->set知識(名無し->知識) == ERROR)
continue;
}
374 名前：>367 [2008/04/16(水) 00:49:58 ]: 店員--（DVDを登録する）-->システム
01.店員はDVDの情報を入力し、システムに登録を指示する。
02.システムはDVDの情報を保持する。

店員--（DVDを削除する）-->システム
01.システムは店員の指示に従ってDVDの一覧を表示する。
02.店員は一覧から削除するDVDを選択し、システムに削除を指示する。
03.システムはDVDの情報を削除する。

店員--（DVDを貸し出す）-->システム
01.店員はシステムに会員証の情報を入力する。
02.システムは会員証が有効かをチェックする。←どんなルール？あと貸し出し限度とかあるのでは？
03.店員システムにDVDの情報と貸し出し期間を入力する。←タイトルによっては期間に制限があるとか？
04.システムはDVDの貸し出し情報を保持する。←料金計算が必要だろ？

店員--（DVDを返却する）-->システム
01.店員は返却DVDの情報をシステムに登録する。
02.システムはDVDの返却情報を保持する。←ここは、貸し出し情報とつき合わせる必要があるし

こんな感じでおｋ
375 名前：仕様書無しさん mailto:sage [2008/04/16(水) 00:50:25 ]: おじゃばがユースケース図と言って書いてるものは、アクティビティ図もどき
UMLでは「ロールがアクティビティをする」という言い方になる

アクターとユースケースは事前に客からヒアリングした結果から導き出したアクティビティ図から抽出する
ユースケース図より、システムの境界を判定する

そのあとにコンポーネントの抽出を行う
おじゃばに分かるように言えば、コンポーネントの組み合わせでユースケースが実現されているってこと
商品管理だとか販売管理だとか顧客管理だとかだな

コンポーネントのつながりを表すのがコラボレーション図
当然アクターもコンポーネントとして表現できる
店員　―　在庫管理　みたいな感じ

ここからシナリオの抽出になるんだが、
教えてほしければ「教えてください」と言え

おじゃばはUMLが不便なものだと言いたげだが、
そんなに不便なものではないし、
己の知識不足の八つ当たりにしか見えない
376 名前：>375 [2008/04/16(水) 00:55:05 ]: >ここからシナリオの抽出になる

いや違うなw そこじゃない
>ユースケース図より、システムの境界を判定
の次でおｋ
コンポーネント、コラボレーションはその後で
377 名前：仕様書無しさん mailto:sage [2008/04/16(水) 01:13:05 ]: >376
374じゃないけどそれは変だろ
どこでインターフェースの抽出を行うんだ？
378 名前：仕様書無しさん mailto:sage [2008/04/16(水) 01:22:47 ]: いんたーふぇーすなんてもっと詳細化してからじゃまいか？
ユースケースて概要レベルでそ？
379 名前：378 mailto:sage [2008/04/16(水) 01:24:35 ]: あ、377のいうインターフェースって対ユーザなのかな？
だとすると「シナリオと同時に」
380 名前：仕様書無しさん mailto:sage [2008/04/16(水) 01:26:29 ]: おいおい
まさかクラス図からインターフェースをひっぱりだすとか
おじゃばみたいなこと言うつもりじゃないだろうな？
381 名前：仕様書無しさん mailto:sage [2008/04/16(水) 01:31:14 ]: >クラス図からインターフェースをひっぱりだす
一緒もしくはインターフェースが先では内科医？
382 名前：仕様書無しさん mailto:sage [2008/04/16(水) 01:39:29 ]: >381
クラスと一緒ってのはないな
アクターからコンポーネントとかコンポーネント間の接続がインターフェース
レンタルシステムでいえば、こんな感じ
アクター：店員→インターフェース：「在庫を確認する」→コンポーネント：在庫管理

>375が書いてるシナリオってのはインターフェースに着目してからのことだと思う
今までの流れだとおじゃばはそこが分かってないからあえて書いてないのかも
なので俺も書かないｗ
383 名前：仕様書無しさん [2008/04/16(水) 04:22:29 ]: ＞ttp://java-house.jp/ml/archive/j-h-b/020739.html#body
＞からの流れで高木さんにフルボッコにされた、あの萩本順三か。

おまえ見る目がない。
H氏の対応は大人的で、技術的にも正しい事言っていたぞ。
384 名前：仕様書無しさん mailto:sage [2008/04/16(水) 08:52:12 ]: 結局おじゃばはユースケースを理解してなかったんだな。いつものオレ解釈だったんだな。やれやれ。
385 名前：仕様書無しさん mailto:sage [2008/04/16(水) 08:59:51 ]: よく分からないことは、分からないです。で十分なわけだけどねー。
386 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/16(水) 09:46:50 ]: >>370
だから、俺はユースケース記述とか、他の図が書きたい訳ではない。見たいのはクラス図だ。
店員とシステムが交互になるなら、読む時に自分で補完して解釈してくれ。
で、ここから概要クラス図とか言うのが作れると言う話だが。作ってくれ。

>>375-385
話が通じないのはオマエラだろう。俺は別にUMLの図の説明が聞きたい訳ではない。
クラス図を作ってくれと言っている。書き方が分からなければ、366の形式でいい。
第一、UMLの用途と問題点については、過去スレで何度も書いている。また俺に説明させたいのか？
387 名前：仕様書無しさん mailto:sage [2008/04/16(水) 10:47:13 ]: 何のためにクラス図がみたいんだっけ？
388 名前：仕様書無しさん mailto:sage [2008/04/16(水) 10:48:54 ]: これだからコーダは困るよ。
389 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/16(水) 20:26:39 ]: やっぱり無理か。オマエラ全員正座な。
390 名前：仕様書無しさん mailto:sage [2008/04/16(水) 20:40:52 ]: よくわからないんですが、ＤＢ使わない縛りなんですか？
ＤＢ使うとおじゃばとか言う人のクラス図は使いたくないって感じなんですが。
391 名前：仕様書無しさん mailto:sage [2008/04/16(水) 21:27:57 ]: >>386
作ったが。
www.dotup.org/uploda/www.dotup.org19684.jpg.html

やっぱ367じゃシステムの振る舞いがさっぱり見えないわ。
ユースケースがショボすぎて、まともな図にならなかった。
ホントは分析を反復して、ユースケースともども修正していくんだけどな。
392 名前：仕様書無しさん mailto:sage [2008/04/16(水) 21:55:55 ]: >>386
よほどUMLを理解した自信が有るようですね。
393 名前：仕様書無しさん mailto:sage [2008/04/16(水) 22:33:22 ]: な、後ろ足で蹴られただろ。おじゃばを相手にすると知能が吸い取られるからやめとけ。
394 名前：仕様書無しさん mailto:sage [2008/04/16(水) 23:05:57 ]: おじゃばはクラス図が欲しいとかいってるが、この調子じゃクラス図の見方もろくに
知らないんじゃないか。
>>386がせっかく作ったクラス図みても、これが正しいのかわからんだろ。だから、
自分のユースケース記述がいかに間違いだらけで見当違いなものかということにも気づ
かんだろ。もしこれで奇跡的に自分のバカさ加減に気づくことができたら、おじゃばは
>>386に感謝した方がいいな。
395 名前：仕様書無しさん mailto:sage [2008/04/16(水) 23:07:43 ]: あ、まちがった俺が馬鹿だ。↑は>>386じゃなくて、>>391ね。
396 名前：393 mailto:sage [2008/04/17(木) 00:08:57 ]: とりあえず、一人でクラス図を作ってみる
前に質問した「商品の新作・準新作・旧作」を考えて行く
まず『汎化』する、ここまでは定石だから分かると思うが
www.dotup.org/uploda/www.dotup.org19898.jpg

しかし、この関連では一つの商品に対して関連付けられているが
実際のレンタル店ではタイトル別に新旧を決めているから
商品の『カテゴリー化』が必要になり、これに新旧状態を関連付けると
www.dotup.org/uploda/www.dotup.org19899.jpg
こんな感じになる
397 名前：仕様書無しさん mailto:sage [2008/04/17(木) 08:11:29 ]: >>396
あ・・・ありえねぇ・・・。
まずそもそも新旧状態はまだ属性だろ。
新旧状態が何かしら属性や操作を持つことが判明してからクラスにするべきじゃね？
けどまぁ1つ目の図はまだわかる。

でも2つ目、明らかにおかしいだろ。てか、意図が全然見えない。
「レンタル商品」に「タイトル」属性があって、
さらに「ビデオ名」「DVD名」クラスが存在した上属性に「タイトル」がある。
意味が分からん。
DVD名とビデオ名を分けた理由も分からないし、汎化したクラスは出て来ないのか？
DVD名とDVD、ビデオ名とビデオに集約が無いし、
2つ目の図は一体何が言いたいの？

新旧がタイトルに付随してることを強調したいなら、
「レンタル商品」の属性から「タイトル」を削って(てかクラスにする)、
「レンタル商品」と新しく作った「タイトル」クラスを集約で繋いで、
「タイトル」クラスに「新旧状態」を集約すべきじゃねぇの？
タイトルの無いレンタル商品が今後出てくるのか？
それとも、DVD名とビデオ名で何か違うの？

まぁ前提の「新旧がタイトルに付随してること」自体ビミョーだと思うけど・・・。
新作か旧作かはタイトルによらず商品で決まると思うんだがな。
別の商品でたまたまタイトルが同じ商品だとおかしくなる。
それかもしくは「～～名」クラスが、すでにクラス名として正しくなく、
DVDやビデオの名前以外の何かを表しているのかもしれない。

うー・・・言葉で書いてもうまく説明できねぇ。
長文スマン。
398 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/17(木) 10:16:42 ]: >>390
OOなので記憶方式には依存しない。つまり、例えば「会員」オブジェクトがあったとすると、
要素（会員番号、DVDリストなど）が管理出来て、動作（入会、更新など）が実装出来る物なら、
DBだろうがファイルだろうが、社会保険庁のDBだろうが記憶力のいいバーテンだろうが、何でもいい。
ただ今回の場合は、メソッド実行の度に、複数または1つのテーブルを検索に行く方式になるだろう。

このようにオブジェクト単位で、変更が容易なのがオブジェクト指向の特徴だ。
作品オブジェクトを外部のDBにするのも簡単だろう。しかし、この時点でパフォーマンスや構造が問題になる
事もある。その場合はキャッシュ機能を組み込んだり、人によってはデザインパターンを参考にしたりする。
ただ、390も分かっていると思うが、ビデオレンタル程度なら>>160で作ったテーブルに対して、
処理を行うプログラムを作った方が早い。
399 名前：仕様書無しさん mailto:sage [2008/04/17(木) 10:42:18 ]: みんな、よけいな口出ししないでおじゃばと393にまかせたらいいのに。
きっといいものできると、思うﾌﾟよ。
400 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/17(木) 19:14:00 ]: >>391,394,396
俺のユースケース記述が見当違いだから391になった？システム側の記述がないなら付け足せばいいだろう。
391のクラス図が正しいか分からない？一目見れば間違っているのは分かる。
391は間違いだが、396の方は無茶苦茶だ。397が混乱するのも当然だろう。
391、396は何をOOと言っているのか分からないが、基礎が全然違う。
オブジェクトというのは、「状態（情報）を保持し、動作を提供する」物だ。
構造化で以下の処理があるとする。構造化の場合は状態と動作の関連がない。
------------------------------------
DVD登録()、DVD更新()、DVD削除()、
会員登録()、会員更新()、会員削除()
------------------------------------
OOだと以下になる。状態はクラスを構成する情報と考えてもいい。
------------------------------------
class DVD{DVD状態、登録()、更新()、削除()}
class 会員{会員状態、登録()、更新()、削除()}
------------------------------------
なぜこうするのかの目的とか利点は、398に書いた通り。つーかこれ基礎なのだが。
401 名前：仕様書無しさん mailto:sage [2008/04/17(木) 19:54:46 ]: ところで、同タイトルのDVD複数ある場合が普通なので在庫数と出荷数と延滞数とかも
加えないといけないと思うのもれだけ？
漏れ、商店や倉庫関連のアプリ組んだ事一回しかないけど、在庫数と出荷数を
作らないクラス設計ってありなの？

VDのタイトルと在庫管理は別にしないと冗長になると思うんだけど。
DB使うんならおじゃばのはアリでも良いけど、メモリやExcelなら簡便だな～。
402 名前：仕様書無しさん mailto:sage [2008/04/17(木) 20:07:54 ]: 結局Excelでちまちま帳票作ったのが一番安上がりで確実で汎用性も高いってことでFAなのか・・・
現場はバーコード管理でコード入力の手間を省くだけで全然満足なんだよな・・・

おまいらお払い箱だpgrpgrpgr
403 名前：仕様書無しさん mailto:sage [2008/04/17(木) 21:26:12 ]: >>398
>このように～変更が容易
どのように？なんら事例なり根拠がないのに「このように」とか書かれても分からんよ。
>DBだろうがファイルだろうが
ってことはオブジェクト指向でなくてもいいだろうし...
404 名前：仕様書無しさん mailto:sage [2008/04/17(木) 21:45:56 ]: おじゃばはなんでどうでもいいような低レベルの話をまるで自分だけが知っている高度な話のようにくどくど書くんだろうな。次元が低すぎるから話が噛み合わないんだろうな。
405 名前：仕様書無しさん mailto:sage [2008/04/17(木) 21:50:35 ]: >>400
> ------------------------------------
> class DVD{DVD状態、登録()、更新()、削除()}
> class 会員{会員状態、登録()、更新()、削除()}
> ------------------------------------

全然違う。
なんでDVDが、自分自身がどう管理されてるかを知ってるんだよ？

------------------------------------
class DVD{DVD状態、更新()}
class 会員{会員状態、更新()}
class DVD一覧{登録()、削除()}
class 会員一覧{登録()、削除()}
------------------------------------

＞オブジェクトというのは、「状態（情報）を保持し、動作を提供する」物だ。
モジュール指向の機能モジュールと、どう違うんだ？

おじゃばは多分OOPも分かってない。
OOPLの機能を便利に使ってるだけだ。
406 名前：仕様書無しさん mailto:sage [2008/04/17(木) 21:58:48 ]: おじゃばのOOの理解は、
構造体に変数と関数をパッケージ化できて、アクセス制限がつけられて、再利用できる。
って程度のもんだろ。多分本質はなんもわかってない。
くどくどと初心者レベルのくだらない説明を得意気に語っているところをみてもそんな気がする。
407 名前：仕様書無しさん mailto:sage [2008/04/17(木) 22:28:29 ]: おじゃばさまにクラスベースとプロトタイプベースのどちらが好みか聞いてみたい。
あと、多重継承よりミックスインを断固支持するかとか、ジェネリックプログラミング
とOOの両方が適用できる場面でどちらの方法を重要視するかとか、その判断基準とか。
まぁ、なにがなんでもOOがベストってわけじゃないのは常識だよね。ダイナミックバイ
ンディング使うよりCase文でさらっとやっちゃった方がお手軽だし。その辺、おじゃば
さま的にはどう思うわけよ？　OOは好きなのか？得意の演説ぶちかましてくれよ。
408 名前：仕様書無しさん mailto:sage [2008/04/17(木) 23:11:41 ]: >>400
＞391のクラス図が正しいか分からない？一目見れば間違っているのは分かる。
どこが間違えてる？
409 名前：393 mailto:sage [2008/04/18(金) 00:51:16 ]: >>397,400
長文だから一応説明するが、レベル的に分かるかが心配だ
>あ・・・ありえねぇ・・・。
>まずそもそも新旧状態はまだ属性だろ。
>新旧状態が何かしら属性や操作を持つことが判明してからクラスにするべきじゃね？
ここはモデラーなら基礎だと思って説明を省いたが、分からないか．．．
まず、新旧状態はレンタル商品の要素だ、このように状態を持つ場合
状態をクラスで表現するのが定石になる、詳しく説明するのも疲れるから『状態(STATE)パターン』を勉強してくれ
（こんな当然の事も「ありえねぇ」とか「無茶苦茶だ」とかは、こっちが「ありえねぇ」と思うが、素人だと思って我慢するか）

>でも2つ目、明らかにおかしいだろ。てか、意図が全然見えない。
>「レンタル商品」に「タイトル」属性があって、
>さらに「ビデオ名」「DVD名」クラスが存在した上属性に「タイトル」がある。
>意味が分からん。
『カテゴリー化』を知っているか？　まっ知っていたら、こんな事は書かないか．．．
『カテゴリー化』は共通のカテゴリーを抽出してクラスにすること、例えば
「ハリーポッター・秘密の部屋」のDVDが複数のあったとする、システム上一つ一つのDVDで管理する場合と
「ハリーポッター・秘密の部屋」のDVDとして複数のDVDを管理したい場合がある、このような時DVDの『カテゴリー』をクラスで表現する
『汎化』とは関係ないから、『汎化』のタイトルと『カテゴリー化』のタイトルは同じ属性でもかまわない
分かるか？

もう、面倒くさくなってきた、後は明日書く（つもり）
410 名前：仕様書無しさん mailto:sage [2008/04/18(金) 01:44:59 ]: 新→旧の一つの状態遷移のためだけにstateパターン使うの？
411 名前：仕様書無しさん mailto:sage [2008/04/18(金) 01:54:35 ]: >新旧状態が何かしら属性や操作を持つことが判明してからクラスにするべき
　↑
　↓
>状態をクラスで表現するのが定石

「ありえねぇ」

>DVD名とビデオ名を分けた理由も分からない
>DVD名とDVD、ビデオ名とビデオに集約が無い
　↑
　↓
>システム上一つ一つのDVDで管理する場合と
>複数のDVDを管理したい場合がある、このような時DVDの『カテゴリー』をクラスで表現する

「無茶苦茶だ」
412 名前：仕様書無しさん mailto:sage [2008/04/18(金) 02:11:46 ]: >>407
気持ちは分からなくもないが、おじゃばはそもそもOOもジェネリックプログラミングも全く理解していないので、
その質問自体を正しく受け止めてくれないよ。
言葉のキャッチボール不可能。

こちらがどれだけ優しくボール投げても、おじゃばのマブタはアロンアルファでくっついているような状態。
こちらのボールは取る気無しだし、おじゃばからは四方八方にウンコが投げられてくる。
413 名前：仕様書無しさん mailto:sage [2008/04/18(金) 08:26:50 ]: >396

おもくそ吹いた
コンポーネントが分からんｽｸﾞﾙ
414 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/18(金) 09:32:58 ]: >>392
392もUMLの本当の歴史を知れば、全部の図を覚えることがどれだけ馬鹿げた事かわかるよ。

>>401
レンタルの場合は同じ作品でもディスクが違えば別の人が借りるので、別々に管理が必要。

>>402
ツタヤでExcelは無理だろう。またExcelしかない銀行に金を預けたいと思うか？

>>403
このようにの例が分からない？その前に書いてあるだろう？
オブジェクト指向でなくてもいい？全然話が通じてないようだな。悪いが何故通じないのか分からない。

>>404,405
知っていたらあのようなクラス図にはならないんじゃないか？
あと確かに厳密に言えば405の方が適切かもしれないが、391の図はそうにもなってないだろう。
何で391にコメントしない？リンクだから見なかっただけか？
415 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/18(金) 10:06:37 ]: >>406
だって初心者レベルをクリアしてないだろう？

>>407
クラスベースが好み。多重継承反対。ジェネリックとOO？OOではなくてポリフォーフィズムの事かな？
それはジェネリックが使えればジェネリックだろう。
ダイナミックバインディングの代わりにcase文？WEBサービスのダイナミックバインディングと、
C構文のswitch～caseを言っているのか？イマイチ分からないが、用途によるだろう。
少々質問が変だな。無理してないか？

>>408
貸し出し、返却など、機能でクラスが別れている所。
416 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/18(金) 10:43:11 ]: >>409
無茶苦茶だと言ったのは悪かった。俺には理解不能に訂正する。
理解不能なので、もしかしたら出来るのかもしれない。
とりあえずクラス図完成させてくれ。主要部分だけでもいいから。

>>412
>ダイナミックバインディング使うよりCase文でさらっとやっちゃった方がお手軽だし。
>その辺、おじゃばさま的にはどう思うわけよ？
これの意味が分からないから説明してくれ。
417 名前：仕様書無しさん mailto:sage [2008/04/18(金) 11:10:48 ]: 自分の無知ゆえに人にものを頼むときに
なんでそんな態度になるんだお前は
418 名前：仕様書無しさん mailto:sage [2008/04/18(金) 12:48:33 ]: >>407 >>412 涙目ｗ　予言どおりになってるｗ

おじゃばにレスをするのがいかに無駄かってこと。
これは、今までどれだけの人間が指摘してきたか。
419 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/18(金) 19:58:00 ]: リンクだと見ない人がいるようなので、書いてみる。
まず391のクラス構成だ。適当に書いてみた。間違っていたら修正してくれ。
------------------------------------------
class DVD登録画面{実行()}
class DVD登録{}
class DVD削除画面{実行()}
class DVD削除{}
class DVD貸出画面{実行()}
class DVD貸出{}
class DVD返却画面{実行()}
class DVD返却{}
class DVD{DVD情報：貸出()、返却()}
class 会員登録画面{実行()}
class 会員登録{}
class 会員削除画面{実行()}
class 会員削除{}
class 会員{会員情報：取得()}
class 一覧{取得()}
420 名前：仕様書無しさん mailto:sage [2008/04/18(金) 19:59:18 ]: 修正する気も起こらん位・・・
421 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/18(金) 20:15:46 ]: 次に396。こっちは途中から分からなくなったので、最初のベースのを書く。修正してくれ。
------------------------------------------------
class レンタル会員{名称}
class 会員カード{カード番号、有効期限}
class 通常会員カード extends 会員カード{}
class 団体会員カード extends 会員カード{}
class コールド会員カード extends 会員カード{}
class メンバー{氏名、生年月日}
class 電話{電話番号}
class 住所{郵便番号、住所}
class 個人会員 extends レンタル会員{}
class 団体会員 extends レンタル会員{}
class 法人会員 extends 団体会員{}
class 家族会員 extends 団体会員{}
class レンタル商品{タイトル、入荷日}
class レンタルする{貸出日、返却日、返却予定日}
class DVD extends レンタル商品{}
class ビデオ extends レンタル商品{}
class 料金表{}
class 通常料金表 extends 料金表{}
class 割引料金表 extends 料金表{}
422 名前：仕様書無しさん mailto:sage [2008/04/18(金) 20:19:02 ]: おまいらの気持ちは今、ひとつになっていると思うｗ
423 名前：仕様書無しさん mailto:sage [2008/04/18(金) 20:27:18 ]: もうなんつーかダメだな、このひと。
424 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/18(金) 20:33:53 ]: だろ？やっと分かってくれたか。
425 名前：仕様書無しさん mailto:sage [2008/04/18(金) 20:35:15 ]: で？
426 名前：403 mailto:sage [2008/04/18(金) 20:37:52 ]: >>414
>>398の前半は「方式に依存しない」の「方式」を羅列しているだけだ。
「変更が容易」の説明ではない。

でもって、「記憶方式に依存しない」「変更が容易」になるように意識すれば、OO以外でも可能だろう？
おじゃばの好きな構造化とかも、繰り返し研究されてきた成果じゃないのか？（まあ素人のおれには良く分からんが）
ことさら「OOならでは」みたいに主張する意味はないんじゃないか。
427 名前：仕様書無しさん mailto:sage [2008/04/18(金) 20:40:12 ]: >>405
＞なんでDVDが、自分自身がどう管理されてるかを知ってるんだよ？

＞------------------------------------
＞class DVD{DVD状態、更新()}

これでも、自分がどう管理されてるか知っている、もしくは知らされている事になると思うんだけど。

>>406
本質ｵｼｴｰﾃ
428 名前：仕様書無しさん mailto:sage [2008/04/18(金) 20:51:36 ]: これは．．．OOは普及しないな
おじゃばのクラスの実装はPL/SQLで実装すべき
間違ってもJavaで実装すべきではないな
429 名前：仕様書無しさん mailto:sage [2008/04/18(金) 21:15:43 ]: おじゃば、とんだ道化だな。俺は決してお前が嫌いではない。
時として虚勢を張ってみせることも大事なことだ。しかし、...
人間には向き不向きがあるということもそろそろ学んだ方がいい。
430 名前：仕様書無しさん mailto:sage [2008/04/19(土) 01:13:35 ]: おじゃばという生物は何故ここまで理解力が無いんだ？
431 名前：仕様書無しさん mailto:sage [2008/04/19(土) 09:17:24 ]: >>430
ヒント：そういう指摘さえ、煽りと受け取るため。
432 名前：仕様書無しさん mailto:sage [2008/04/19(土) 10:13:20 ]: >>414
>レンタルの場合は同じ作品でもディスクが違えば別の人が借りるので、別々に管理が必要。

>class DVD extends 作品{
>　シリアル番号、作品番号、入荷日
>}
>class 作品{
>　タイトル、ジャンル、年令制限、発売日、レンタル開始日
>}
>class ショップ{
>　DVDリスト、料金表
>}

これって、一個一個のDVDはDVDリストで管理して、DVDクラスの中に
DVDの情報が入っているとしか思えないだけど。
一個一個のDVDを管理しているシリアル番号だから、継承でＤＶＤクラス作る
必要性はないだけなんだけど・・・。そうすれば、数分の一に在庫管理情報が減る。

だから、
>タイトルと在庫管理は別にしないと冗長になると思うんだけど
といったわけなんだが。

ポンチ図レベルでこれ位パッと思い浮かばないと後々影響出るぞ。
こういったポンチ図は共通情報とか固有情報とか固定情報の洗い出しに使うわけだから。
433 名前：仕様書無しさん mailto:sage [2008/04/19(土) 12:08:26 ]: おじゃばは、帰納法も演繹法も知らんのか。
「～だ」、「以前に書いた」、「～してくれ」
常に断定的で、自己中な記憶頼りで、他人任せ。
悲しいかな、根拠を書かない。書く習慣がない。
前に書いたというなら、せめて引用するぐらい
の配慮が欲しい。
おじゃばの文章には、「～だから～となる」と
いう書き方が皆無だ。これじゃぁ人を納得させ
る文章は書けない。ただの落書き。
434 名前：仕様書無しさん mailto:sage [2008/04/19(土) 13:19:38 ]: おじゃば！！！

これで開発(分析、設計、コーディング)すればいいんだよ！！１
ホントおじゃばに最適だと思うよ！

yuukiremix.s33.xrea.com/chirashi/
435 名前：仕様書無しさん mailto:sage [2008/04/19(土) 13:31:04 ]: おじゃばはリンク先は見ないよ、つぅか、見ても
難しそうだったら、見なかったことにする。

あ、でもこれは飛びつくかも。
436 名前：393 mailto:sage [2008/04/19(土) 13:40:38 ]: 続き
>>397
>DVD名とDVD、ビデオ名とビデオに集約が無いし、
お前クラス図読めないのか？「関連」で書いたのが間違いだと言いたいのか？
「集約」「関連」「コンポジション」の違い分かっているか？
「集約」と「関連」は機能的には同じだぞ、分かっているか？
俺は概念的意味合いで使い分けしているが、人が「集約」を「関連」で書いても間違いだとは言わない

>新旧がタイトルに付随してることを強調したいなら、
>「レンタル商品」の属性から「タイトル」を削って(てかクラスにする)、
だから「汎化」の属性と「カテゴリー化」の属性を一緒にするな

>「レンタル商品」と新しく作った「タイトル」クラスを集約で繋いで、
お前の「集約」の基準はなんだ？カテゴリーはDVDの発売前に作ったり
DVDが全て無くなってもカテゴリーを残して置くこともある（再入荷もあるしな）
俺はこれだけ、繋がりが弱い場合「関連」と判断する
逆に、「集約」で繋がっている「DVD名」「ビデオ名」と「新旧状態」は
「新旧状態」が「DVD名」「ビデオ名」の要素で関連が強いから「集約」を使っている
437 名前：393 mailto:sage [2008/04/19(土) 13:41:12 ]: >「タイトル」クラスに「新旧状態」を集約すべきじゃねぇの？
>タイトルの無いレンタル商品が今後出てくるのか？
>それとも、DVD名とビデオ名で何か違うの？
あとから考えたら、そっちの方が良いと思ったが、それでも「ありえねぇ」と言われるほど間違ったクラス図じゃない

>まぁ前提の「新旧がタイトルに付随してること」自体ビミョーだと思うけど・・・。
>新作か旧作かはタイトルによらず商品で決まると思うんだがな。
同じタイトルのレンタル商品で、新作と旧作が別にあるレンタル店見たことあるか？
お前の言っている「商品」はDVD一つ一つの商品じゃなく「カテゴリー化」された「商品」の事を言ってないか？
例えば「カローラ」と言う商品(車)があるが、これは「カテゴリー化」された商品で
実際自分で運転する商品は「車台番号」ごとの商品になるがそれ毎に値段を設定するのか？

>別の商品でたまたまタイトルが同じ商品だとおかしくなる。
オブジェクト指向分かっているか？実際に関連付けるときは
「クラス」(DVD名)じゃ無く、「オブジェクト」を関連付けるだが
タイトルなんて関連付けには関係ない、その「カテゴリー化」した
オブジェクトの属性がタイトルだと言う事だが、分かっているのか？
なんで、こんな発想になるんだ？意味がわからん
438 名前：仕様書無しさん mailto:sage [2008/04/19(土) 13:59:19 ]: >>436-437 お前OO分かっているか？
439 名前：仕様書無しさん mailto:sage [2008/04/19(土) 14:01:24 ]: 「タイトル」という言葉の合意形成ができていないな。
2種の意味で用いられている。
440 名前：仕様書無しさん mailto:sage [2008/04/19(土) 14:48:42 ]: こんな馬鹿なモデラーの作ったクラス図でコード書かされたら発狂するな
441 名前：仕様書無しさん mailto:sage [2008/04/19(土) 15:14:52 ]: >>436　いってることは、正しいよ。でもむかつく
関連も解らない奴に、そこまで書く必要あるの？
442 名前：仕様書無しさん mailto:sage [2008/04/19(土) 16:24:09 ]: ＞長文クン
簡潔に書く努力をしろ
相手の読む気を失うようであれば意味がない
443 名前：仕様書無しさん mailto:sage [2008/04/19(土) 16:45:46 ]: >>397
>うー・・・言葉で書いてもうまく説明できねぇ。
>長文スマン。
長文書いといて、最後にまとめられないってｗ
謝れば済む問題じゃないだろｗ
444 名前：仕様書無しさん mailto:sage [2008/04/19(土) 20:17:35 ]: 開発ごっこやるんだったら、誰か依頼人役をやったら？
445 名前：仕様書無しさん mailto:sage [2008/04/19(土) 21:32:40 ]: おじゃば氏が>>414でTSUTAYAの名を出したことからして
依頼企業もそれくらいの規模を妄想しているんだろう
既にTSUTAYAはネットレンタルまでやってるってのに
それと同規模の企業を想定しても全然面白くない

つべやニコがある時代に空気も読めずに脱サラして
レンタルDVD店をはじめたという設定ならやってもいい
446 名前：仕様書無しさん mailto:sage [2008/04/19(土) 21:42:52 ]: つーか、おじゃばって学生だよな？
まさかその知識で仕事してないよな？
447 名前：仕様書無しさん mailto:sage [2008/04/19(土) 21:47:53 ]: >>446 学生じゃないはず。多分社会人5年目ぐらい？にしてはだいぶ御粗末だが。
448 名前：仕様書無しさん mailto:sage [2008/04/19(土) 21:57:40 ]: >>447
まじかよ・・・・・・・・・・・（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
絶対一緒に仕事したくないな
449 名前：仕様書無しさん mailto:sage [2008/04/20(日) 00:55:52 ]: 中二病だろ
450 名前：仕様書無しさん mailto:sage [2008/04/20(日) 01:29:31 ]: 普通の神経なら恥ずかしくて言えないようなことを得意気にに語るからな。
しかもそれが大概間違った解釈してるし。しかし俺は意外とおじゃばは30近いか
下手すっと超えてるんじゃないかと思ってるんだが。妙におっさん臭いとこあるし。
..にしては文章が稚拙でやはりまだ20代かと思ったりもするが。
451 名前：仕様書無しさん mailto:sage [2008/04/20(日) 01:52:41 ]: お前20代に謝れ
452 名前：仕様書無しさん mailto:sage [2008/04/20(日) 02:28:30 ]: >>415
亀レスすまSo。ダイナミックバインディングは端的に言うと「仮想関数の呼び出し」のことだよ。
ここまでゆえば、Case文との対比もピンとくるよねすけ。
そうか、おじゃばさまはクラスベースが好きか。つぅかできればその根拠も書いて欲しかったな。
俺は、試験的にちゃっちゃっとアイデアを試してみる分にはプロトタイプベースでやっちゃうな。
でもやっぱりシステムを本格的に構築する時にはクラスベースになっちゃうかなぁ。ま、俺が言語
自体がプロトタイプベースをサポートしているコンパイラ言語を知らないというのもあるんだけど
ね。ジェネリックプログラミングについては、・・・まんまとひっかかったね。ウシシシシシシッ
ジェネリックとOOは相反するものだと言う人がたまにいるけど、そんなことはない。ちゃんと設計
すればうまく融合してくれるよ。例えば、ん～何がいいかなぁ、簡単な例でいくと、例えばオブジェ
クトの大小を判定する処理が必要なケースで、OOでIComaparableとかいうインターフェースこ
さえたり、<オペレータをオーバライドして、C++の場合だと、
template <class T>
const T& max(const T& a, const T& b) { return a < b ? b : a; }
とかね。これはおじゃばさまには初心者レベルすぎて失礼すぎたかな。でもまんまとひっかかった
しぃ。うふ
ま、今日はこの辺で、実は飲み会帰りで酔っ払ってて、もしかしたら変なこと言ってたかも、そん
時はごみんちゃいませ。
あ、あと、多重継承断固反対の根拠もよろぴくぅ。ミックスインが好きってことでいいんだよね？
453 名前：仕様書無しさん [2008/04/20(日) 02:40:52 ]: つぅか、そろそろ誰か>>415の『ポリフォーフィズム』に遠慮せずにつっこめよ
454 名前：仕様書無しさん mailto:sage [2008/04/20(日) 09:32:59 ]: >>453
はげわろすｗ　見逃してたｗ
455 名前：仕様書無しさん mailto:sage [2008/04/20(日) 10:23:40 ]: 長文スルーされてる証拠だフォーーーーーーーーッ！！！
今時HG、フォーーーーーーーッ！！！
456 名前：仕様書無しさん mailto:sage [2008/04/20(日) 10:54:17 ]: 単なるtypoじゃなくて、その用語を言いなれてない、
めったに口にしない、日常的に用いてない感があふれてフォーッ！

これに対するクソみたいな弁明も予想されてフォーッ！
457 名前：仕様書無しさん mailto:sage [2008/04/20(日) 16:51:54 ]: こういうどうでもいいことは素直に謝る気もするな。
「これは気づかなかった。ただのtypoだ。わかるだろう？」
みたいな。
でも「本質ではないところにしか突っ込めない(ry」みたいに煽ってくるかもな。
458 名前：仕様書無しさん mailto:sage [2008/04/20(日) 16:59:25 ]: www.google.co.jp/search?q=%E3%83%9D%E3%83%AA%E3%83%95%E3%82%A9%E3%83%BC%E3%83%95%E3%82%A3%E3%82%BA%E3%83%A0

ポリフォーフィズムの検索結果約 258 件中 1 - 10 件目 (0.15 秒)

結構いるんだな。
459 名前：仕様書無しさん mailto:sage [2008/04/20(日) 17:01:06 ]: ついでに調べたらﾌｲﾀｗｗｗ

「ポリフォーミズムの検索結果約 137 件中 1 - 10 件目 (0.56 秒) 」
460 名前：仕様書無しさん [2008/04/20(日) 17:17:20 ]: >>458
おじゃば並の知性の持ち主が日本に結構な数いるということなのか、恐ぇよ。。
そん中でおじゃばの発言がはやくも8番目に登場してるしw
461 名前：仕様書無しさん mailto:sage [2008/04/20(日) 17:21:27 ]: おじゃばは、自分の知らないことはオウム返しするからわかりやすいぞ。
>>169
>で、ユースケース図からは無理だと言う事は分かったが、ドメイン図からは出来るのかな？
ドメイン図がなんだかさっぱりわからないときはこーやって煽る。
462 名前：仕様書無しさん mailto:sage [2008/04/20(日) 17:33:42 ]: >>450
前スレのディストリビューション知らないで機種とか言ってたり、
知ってるgccのバージョンが2.xx止まりだったり、
Cマスター(笑)でperlモジュールの話してるあたりとか、
なんだかんだ言って構造化もちゃんとできてない手続きロジックしか
出せないとこからして、実は３０代後半の線もあると思う。

周りに相手にされてなくて、自分だけOO知ってるぞ、が支えになってる。
463 名前：仕様書無しさん mailto:sage [2008/04/20(日) 18:15:00 ]: おまえ等まだおじゃばのことがよくわかってないようだな。
おじゃばがこのスレでやりたいことは学校ごっこなんだよ。
おじゃばがやりたいのはもちろん先生。そしておじゃばが
おまえ等に期待してるのはOOを習いたてのちょっと出来の
悪い生徒たちだ。「カプセル化って意味あるんですか？」
とか、「継承って何が便利なんですか？」とか聞いてくる
ような生徒を期待してるんだよ。先生より出来のいい生徒
や先生の揚げ足取りしてくるような生徒なんか想定してな
いんだよ。あと他の先生役がいてもいいが、その先生はお
じゃばより出来が悪く、おじゃばより生徒からの人気がな
い先生でなくてはならない。そういう環境をおじゃばは望
んでいるんだよ。

だから、おまえ等がぐっと我慢して、出来の悪い生徒を演
じてくれれば、おじゃばも気持ち良くカキコできるし、こ
のスレも安泰だというわけだ。というわけで協力してやれ。
464 名前：仕様書無しさん mailto:sage [2008/04/20(日) 18:32:39 ]: >>463

120点。
長文にして分かりにくく書いたつもりなんだろうけど、
目的がしっかりしていて文章が飛ばないので長文でも分かりやすい。
465 名前：仕様書無しさん mailto:sage [2008/04/20(日) 19:01:16 ]: >>464 てれるなぁ。
ついでに言っとくと、おじゃばがよく、俺等にやれって言ってるのは
本人的には多分、先生気取りで宿題出してるつもりだから。
466 名前：仕様書無しさん mailto:sage [2008/04/20(日) 19:01:22 ]: いや、これ難しいだろ。
どこを縦読み？
467 名前：仕様書無しさん mailto:sage [2008/04/20(日) 19:32:48 ]: >>466
左上から斜め読みじゃないか？
468 名前：仕様書無しさん mailto:sage [2008/04/20(日) 21:22:33 ]: >>466は縦読みだな
469 名前：仕様書無しさん mailto:sage [2008/04/20(日) 23:02:56 ]: >>409
亀レスやけども。
＞状態をクラスで表現するのが定石になる、詳しく説明するのも疲れるから『状態(STATE)パターン』を勉強してくれ
まぁポリシーやらプロセスやらの違いかも知れんけど、
分析レベルでデザパタ考え始めるのは、ちょいと早過ぎるんとちゃうか？
概念モデル作っとんの？それとも設計のクラス図作っとんの？
470 名前：仕様書無しさん mailto:sage [2008/04/20(日) 23:08:54 ]: その通りだな　デザパタは必要ない
しかし間違っていることがある
理解できる相手では無いということだ
471 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/21(月) 09:23:39 ]: >>426
だから前から言っているように、構造化は変更を予測してモジュール化された所は変更が容易だが、
OOは全てのクラス単位で変更が容易だと言う所が違う。つまりOOの場合は、変更を予測しなくていいと言う事。

>>432
すまんが、作品に作品番号が抜けていたので、366では追加しておいた。
継承は不要だな。DVDと作品を分離する時に失敗したようだ。やっとまともな指摘が入って安心した。

>>433
自分が基礎知識だと思っている事を、他人が知らないと認識するのは結構難しい。
だから分からない所は質問してくれ。

>>436,437
421を修正してくれ最新版にしてくれ。不要なのは削ってくれ。あれで完成か？

>>446-451
で、366,419,421のうち、どのクラス図が正しいと思うのか、意見を聞かせてくれよ。
どれでもないなら自分で書いてみろよ。
472 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/21(月) 12:48:35 ]: >>452
仮想関数かcaseかなら、OOなら仮想関数呼び出しの方だろう。OOならcaseは排除すべきだ。
クラスベースの方が好みなのは、大きいシステムを作った場合に奇麗に作れるからだ。
まあ適材適所だから、JavaScriptでいいレベルなら、JavaScript使うがな。
ジェネリックは、ひっかかってないだろう？OOではなくてポリモーフィズムではないかと言っている。
第一、ジェネリックとOOが相反する物だと言う話は聞いた事がない。
つーか、452がポリモーフィズムが分かっていないって事かな。それとも酔っ払っているだけか。
多重継承反対の理由は、分かりにくくなるからだ。まあ想像はついていただろう？
つまり用語の使い方が少し間違っていたというのは、わざとだと言う事だな。それなら納得出来る。

>>453-459
ポリモーフィズムの間違いだ。

>>462
不当な評価だ。ちなみにディストリビューションは知っている。
長いから意味は少し異なるが、機種という表現にしただけだ。
462の全ての評価がこのレベルのくだらない事なので、全部にコメントするのは面倒だからやめておく。
473 名前：仕様書無しさん mailto:sage [2008/04/21(月) 12:57:45 ]: > 長いから意味は少し異なる

？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
474 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/21(月) 13:43:11 ]: ディストリビューションと言う言い方は長いから、意味は少し異なるが、読めば意味は伝わると思ったので、
機種という表現にしただけだ。
でいいかな。
ダリィ
475 名前：仕様書無しさん mailto:sage [2008/04/21(月) 14:37:07 ]: >>474
要するに、意味は少し異なるが、読めば意味は伝わると思うので
>>462　にあることはまったくその通りで反論できない
ということでいいかな。
476 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/21(月) 18:23:37 ]: >>475
462は洞察力も分析力も低い上に、内容もどうでもいい事だから、反論するのもかったるいって事。
477 名前：仕様書無しさん mailto:sage [2008/04/21(月) 18:47:02 ]: 使い方は間違ってるけど、伝わらないのは読み手が悪い。と。
478 名前：仕様書無しさん mailto:sage [2008/04/21(月) 19:04:55 ]: おじゃば氏の態度は協力しようという気を萎えさせるのに十分だ
これまで何人の猛者がこうして撃破されていったのだろう
479 名前：仕様書無しさん mailto:sage [2008/04/21(月) 19:24:52 ]: >>476
>475
480 名前：仕様書無しさん mailto:sage [2008/04/21(月) 19:27:29 ]: つまりおじゃばくんは「鳥」等の表現も知らないのですな
481 名前：仕様書無しさん mailto:sage [2008/04/21(月) 19:35:58 ]: なぜオブジェクト指向は普及しないのかって？おじゃばみたいのがいるからだろ。
482 名前：仕様書無しさん mailto:sage [2008/04/21(月) 19:41:29 ]: >>472
おじゃばなぁ、不当な評価だという主張にも根拠が必要だわな当然。
名無しは誰だかわからないんだから、その都度ネゴシエートしないとだめ。
2chで特定の「オマエラ」なるヤツに向かってするのがバカなんだよ。
うわっつらのOO先生ごっこがしたけりゃmixiにでも自分でブログでもすればいいのに
度胸もなくて2chのネタ板で常時ageでコテハン。恥ずかしくないんだろうか？
勝負したきゃせめてム板ででもやりゃいいのに、怖いんだろこのおくびょうもんが。
483 名前：仕様書無しさん mailto:sage [2008/04/21(月) 19:46:55 ]: つまり、はっきり「くだらない」とおじゃばがいうのは
もはや反論もできない事実、でいいな。
484 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/21(月) 20:03:08 ]: >>463
初心者の質問や怪しい設計を放置するから、俺が基礎を教える事になっているだけだ。
ダメな生徒を演じなくていいから、初心者の質問に答えたり、怪しい設計にコメントしたりしてくれよ。

>>465
誰よりも俺が宿題やってると思うが。

>>481
俺じゃなくて、UML厨とデザパタ厨のせいだろう。

>>482
このスレで度胸のあるのは3人いる。クラス図を書いた3人だ。
その次に度胸のあるのは、そのクラス図に対してコメントをした人だ。
残りを臆病者と呼ぶ。オマエはどれだ？
485 名前：仕様書無しさん mailto:sage [2008/04/21(月) 20:06:52 ]: >継承は不要だな。DVDと作品を分離する時に失敗したようだ。やっとまともな指摘が入って安心した。

継承が不要じゃなくて、商品名(作品)と管理処理を別にするのは基本中の基本だ。
486 名前：仕様書無しさん mailto:sage [2008/04/21(月) 20:08:00 ]: >>484
あの、ここでそれをするという合意形成がまるでできないから
誰もまともに相手してないんだよ。
おじゃばとは言葉が通じないな、とわかって誰もが通り過ぎる。
ここはそういうスレ、にお前がしたの。バカだから。
487 名前：仕様書無しさん mailto:sage [2008/04/21(月) 20:17:16 ]: おじゃばをひたすらおだてて生態を観察するスレ
ならできるぞ
488 名前：仕様書無しさん mailto:sage [2008/04/21(月) 20:20:05 ]: >>487
それはそれで毎日の餌やりがたいへんではないかと。
長文で「と思う」連発するまで飢えさせるのもいいかもしれんけどね。
489 名前：仕様書無しさん mailto:sage [2008/04/21(月) 20:39:47 ]: >>484
> 初心者の質問や怪しい設計を放置するから、俺が基礎を教える事になっているだけだ。
> ダメな生徒を演じなくていいから、初心者の質問に答えたり、怪しい設計にコメントしたりしてくれよ。

お前の設計、散々指摘されとるじゃないか
490 名前：仕様書無しさん mailto:sage [2008/04/21(月) 21:21:22 ]: >>489
おじゃばは自分は初心者じゃないからいくら指摘されてもいい、ちう頭だから。
言うだけ無駄。
491 名前：仕様書無しさん mailto:sage [2008/04/21(月) 21:37:03 ]: なんだかんだでもう9スレも続いてるのかよ
継続は力というやつか
492 名前：仕様書無しさん mailto:sage [2008/04/21(月) 21:59:25 ]: ＞ディストリビューションと言う言い方は長い

？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
493 名前：仕様書無しさん mailto:sage [2008/04/21(月) 22:02:11 ]: 確かにあれだけ冗長な文章を書いておきながら
こんなところでキータイプ回数節約されてもなぁｗ
そらコイツの文章読みにくくて当然だわ
494 名前：仕様書無しさん mailto:sage [2008/04/21(月) 22:22:39 ]: なんか、このスレってず～～～～～っつとこの調子だな。

1)おじゃばがボケる。
　↓
2)名無しがツッこむ。
　↓
3)おじゃばが逆切れする。
　↓
4)名無しがあきれる。←今ここ。
　↓
5) 1)へ戻る。

そろそろ飽きたわ。
495 名前：仕様書無しさん mailto:sage [2008/04/21(月) 22:28:47 ]: >>494
393氏のが意外と教科書どおりなのでちょっと期待している
496 名前：仕様書無しさん mailto:sage [2008/04/22(火) 00:02:14 ]: >で、366,419,421のうち、どのクラス図が正しいと思うのか、意見を聞かせてくれよ。
>どれでもないなら自分で書いてみろよ。

>374 ベースで
class DVD登録画面{登録実行()}
class DVD削除画面{削除実行()}
class DVD貸出画面{is妥当な会員()、is貸出可能()、料金計算()、貸出実行()}
class DVD返却画面{is返却可能()、延滞料金計算()、返却実行()}
class DVD{タイトル、料金、状態、状態更新()}
class DVD管理簿{一覧()、登録()、削除()}
class レンタル管理簿{一覧()、登録()、削除()}
まぁ要求があいまいすぎるので不明な点が多すぎて全然納得いかんが
497 名前：496 mailto:sage [2008/04/22(火) 00:07:15 ]: う～ん、
>362 の言うとおり "レンタル"コントローラがあったほうがよさげ...orz

まぁ会員関係も考慮してないしw
498 名前：393 mailto:sage [2008/04/22(火) 00:25:32 ]: 新旧状態を入れた形でクラス図を修正する
www.dotup.org/uploda/www.dotup.org23690.jpg

次にレンタルを考えていくが、その前に誰も指摘しないので
このクラス図の間違いを修正する
(いまのクラス図だと、同じDVDを2度と借りれない)
www.dotup.org/uploda/www.dotup.org23692.jpg

レンタルを考える前に、先に質問に答えとく
>>469
>まぁポリシーやらプロセスやらの違いかも知れんけど、
>分析レベルでデザパタ考え始めるのは、ちょいと早過ぎるんとちゃうか？
>概念モデル作っとんの？それとも設計のクラス図作っとんの？
「動的分類は概念レベルに入るか？」と言う事か
これは、人や手法によって違うが、俺は「動的分類・多重分類」は概念レベルに
入らないと思う。しかし今回は規模が小さいから「概念レベル」「実装レベル」で
書いていこう思っている、そう考えると「実装レベル」ではない
とりあえず、「概念レベル」と次の段階の「仕様レベル」で書いてみる
www.dotup.org/uploda/www.dotup.org23693.jpg
こんな感じになる。
499 名前：仕様書無しさん mailto:sage [2008/04/22(火) 00:35:46 ]: >498
いや、だから新旧状態がなんでクラスなのさ？
a.状態を保持しているか、b.処理を行うか、c.判断するか
しないならクラスの意味ないだろ...
500 名前：仕様書無しさん mailto:sage [2008/04/22(火) 02:13:56 ]: >>499
たとえば新しい状態を追加する必要がでてきたような場合に
「新旧状態」を親とする新しいクラスを追加するだけですむので
（無論そうなるようにインターフェースが予め適切に設定されている必要があるが）
変更箇所を限定できるというメリットがある
501 名前：仕様書無しさん mailto:sage [2008/04/22(火) 02:22:59 ]: 料金表、ってちょっと考えると新旧状態に関係するよね。
「旧作一律100円の日」とか。
そういうのはどこに載るんだろう？
502 名前：仕様書無しさん mailto:sage [2008/04/22(火) 02:35:33 ]: >500
いや、だから「新しい状態」って何するのよ？

>501
料金を計算するところ
"料金表"が計算するところならそこだけど...
503 名前：仕様書無しさん mailto:sage [2008/04/22(火) 02:38:56 ]: >>502
たとえば「新作」、「準新作」、「旧作」に加えて「古典」というようなカテゴリーを追加して
別扱いにするような場合
504 名前：仕様書無しさん mailto:sage [2008/04/22(火) 02:53:54 ]: そこまでいうとジャンルがいるんでは。
邦画・洋画・時代劇・ドラマ・アニメ・特撮・アダルト
これらも追加とか「邦画100円の日」とか考えると属性じゃなくて
クラスにしたほうがいいのかな？
505 名前：仕様書無しさん mailto:sage [2008/04/22(火) 03:30:15 ]: >>504
それは設計が大分進んだ段階（もしくは納期直前）で仕様変更（というか抜け）とすべき
新しいWebサービスを作るのではなく既存の業務をシステム化する話だから
顧客の業務に存在しない・顧客に要求されない事項についての設計は基本的に不要
それこそ使われないシステムというやつだ
506 名前：仕様書無しさん mailto:sage [2008/04/22(火) 03:46:53 ]: >>505
その線引きが脳内にしかないから、ユースケースちゃんと作らないとね
ってこったろ。でもさ。これDVDレンタルだろ？
ビデオがありでジャンルがないのは実用に足るのかねぇ
507 名前：仕様書無しさん mailto:sage [2008/04/22(火) 04:29:42 ]: だいたい、あるのかどうかも分からない法人会員だの家族会員だの
拡張性のためにとやらでいきなり妄想で作ってんのに、
現実のレンタルにあるジャンルやらレンタル形態、
m泊n日とか何本組でいくらとかがごそっとないのがなー。
クラス図いじる前に店行って何本か借りてこいっつーの。
これだからすぐモノ作りたがる奴は困るよ。
508 名前：仕様書無しさん mailto:sage [2008/04/22(火) 09:29:45 ]: >>498
現状で新旧状態によって変わることって、あんまりなくない？
料金を変えようにも、レンタルは料金を商品に聞きに行くのではなくて、独立した料金表を見に行く。
かつ、商品から状態を取得してるわけでもない。(料金表に商品、商品名、新旧状態との関連がない)
要望としてすら出てきてないんで想像だけど、返却予定日が変わんのかなぁ・・・。

状態をクラス化するメリットって「複数の」振る舞いが状態によって変わる場合ではない？
あとづけで新旧状態を属性からクラスに変えても、
カプセル化のおかげでそれほど修正の範囲が狭そうなんで、
個人的には、まだ属性にしておく方がよいと考えてる。(あくまで個人的には)

そういや今の関連だと、商品も商品名も料金表(料金)と何の関係も無いように見えるんだけど。
クラズ図には無いけど「料金種別(属性もしくは操作の返値)」的なものが商品にあって、
レンタルは料金種別を商品から取得して、それをキーに料金表を参照する。
って風になんのかね？

393はどういう意図で描いた？
特に商品や新旧で料金変えるつもりは無し？
509 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/22(火) 10:08:43 ]: >>486-494
哀れだな。設計の内容は全く分からないのか？

>>496
419はOOと言うより、MVCを意識しているだけだろう。
MVCはWEB画面を設計する際に、表示系を変えやすくするための物で、OOとは直接関係ない。
画面系をMVCにするのは構わないが、今回設計すべき所は、MVCを使うとするとコントロールクラス内部で
使用するクラスの部分だ。もしDVD貸出コントロールクラスで、直接テーブルを更新し、
DVD返却コントロールクラスでも、直接テーブルを更新しているなら、構造化と変わらない。
DVDが変更になったら、複数のクラスが影響を受けるだろう。
496はもっとひどい。MVCからビューとコントロールを結合したようだな。そして全体のコントロールの
行き場がなくなったか。とりあえずMVCは忘れた方がいいのではないか？

>>498
いろいろあるが、まず最初に507とほぼ同意見。
不要なクラスは消して欲しいな。あれで完成と言う事なら、次の問題点を指摘するが。
510 名前：仕様書無しさん mailto:sage [2008/04/22(火) 10:41:35 ]: おじゃばが哀れとかくだらんと言うのは、図星で悔しいという内容の表現。
読めば意味が伝わると思う。
511 名前：仕様書無しさん mailto:sage [2008/04/22(火) 10:44:44 ]: >>509
>まず最初に507とほぼ同意見。
お前んのもねーじゃねーか。人の尻馬に乗るなよｗ
512 名前：仕様書無しさん mailto:sage [2008/04/22(火) 10:58:42 ]: >510
伝わるねぇ。
ついに反論ごっこすらもできなくなったみたいだし。

>511
今更言うなよ。
コイツいつもそうじゃん。
513 名前：仕様書無しさん mailto:sage [2008/04/22(火) 14:36:14 ]: >>498
タイトルなんて同じものがいくらでもあるのにそれはないだろ。
最新作、新作、旧作全てに共通する要素を基本クラスにするべきだと思う。
共通するものとはなんだ？
当然、商品情報だよな。

あれ？クラス図って基本クラス中心に書くの？
514 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/22(火) 19:18:24 ]: >>510
正直言って、洞察力も解析力も低い人間の指摘は、妄想としか思えないだろう。
妄想は図星に程遠いし、悔しいと言う感情が起こるはずもない。
起こるとすれば哀れだと言う感情ぐらいなので、そう言った訳だ。
515 名前：仕様書無しさん mailto:sage [2008/04/22(火) 19:26:32 ]: >>514
もはや反論のしようもなく、なんと言えばいいかわからずこの時間でやっと３行書けた。
読めば意味が伝わると思う。
516 名前：仕様書無しさん mailto:sage [2008/04/22(火) 19:28:33 ]: 515のほうが不思議と説得力があるな
妄想しか並べられない人間が負け惜しみで妄想は～とかどんな自虐なのかと
517 名前：仕様書無しさん mailto:sage [2008/04/22(火) 19:33:46 ]: >>>486-494
>哀れだな。設計の内容は全く分からないのか？

なんだ、オレに対するレスはなしか。
518 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/22(火) 20:03:14 ]: >>515
いや正直な気持ちを書いたんだよ。マジで。納得出来る内容だろう？

>>517
俺って485か？それならば、485の言う通りだ。ただ、作品番号入れたら継承は不要なので外す。
519 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:09:00 ]: 納得させたかったらディストリビューションという単語を
「あえて使わなかった」「まっとうな」理由を述べたほうがよくね？

つーかディストリビューションという単語の意味をよくわかってません
って素直に吐いたほうが納得してもらえると思うけど？
520 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:16:36 ]: >>518
いや正直に反論できないって書いたんだよ、マジで。読めば意味が伝わるだろう？
521 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:22:00 ]: まぁ、これ以上いまどき「redhatは雑誌の付録」とか言った時代遅れにかまってもしょうがねぇだろ。
ほっといてやんなよ。
522 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:38:23 ]: 　､＿＿＿＿＿＿＿＿＿＿＿
　､＞　　　　　　　　　　　　　　.|
　　＞＿＿＿＿＿＿＿＿　　 .|
　　￣　　.|./＿　　＿＼ |　　 |
　　　　　　| /　ヽ／　ヽ　|　　|
.　　　　　 | | 　・ | ・　　|　 V⌒ｉ
　　　＿　 |.＼　人＿_ノ　　　6 |
　　　＼￣　　○　　　　　　　　/
.　　　　＼　　　　　　　　　厂
　　　　　／　＿＿＿＿_／
　　　　　￣￣, -/へ／＼/｀- ､
　　　　　　／./　 ./o　　　　i.　＼
　　　　　　∧
／￣￣￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
昼飯のスパゲティナポリタンを眺めながら、積年の疑問を考えていた。
それは「なぜナポリタンは赤いのだろうか」という問いである。
簡単に見えて、奥の深い問題だ。
「赤いから赤いのだ」などとトートロジーを並べて悦に入る浅薄な人間もいるが、
それは思考停止に他ならず、知性の敗北以外なにものでもない。
「赤方偏移」という現象がある。
宇宙空間において、地球から高速に遠ざかる天体ほどドップラー効果により、
そのスペクトル線が赤色の方に遷移するという現象である。
つまり、本来のナポリタンが何色であろうとも、ナポリタンが我々から
高速で遠ざかっているとすれば、毒々しく赤く見えるはずなのだ。
目の前のナポリタンは高速で動いているか否か？
それはナポリタンの反対側に回ってみることでわかる。
運動の逆方向から観察することで、スペクトルは青方遷移し、
青く見えるはずなのだ。
逆に回ってみたところ、ナポリタンは赤かった。
よってこのナポリタンは高速移動をしていないと言える。
523 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:48:17 ]: >>522
「Linuxのgcc」よりはそっちのほうが読めば意味は伝わるな。
524 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:51:40 ]: 流れぶったぎるけど、もうレンタルシステムはやめようや
いつまで経っても要件がはっきりしないし、
OO分析をする以前の話で止まってるし、
「お前は馬鹿」の応酬で生産性が無いし

既存のをやろうよ
例えばWindows付属のゲームのフリーセルやスパイダーを作る、
とかした方が明確に分かりやすいじゃん
拡張性と妄想を同一視するようなこともないしね
525 名前：仕様書無しさん mailto:sage [2008/04/22(火) 20:55:29 ]: 　　　　　　＿＿__
　　　　／'':::::::::::::::''＼　　　　　　　　　　　　　　__,,,──,,,_
　─　/:::::::::::::::::::::::::::::::ヽ　　　　　　　　　　　 ∠:::::::::::::::::::::＼
　￣（::::::::::::::::::::::::::::::::::::|　　　　　　　　　　　│|:::::::::::::::::::::::ヽ
　　　　|＼:::::::::::::::::::::::::丿　　　　　　　　　　　├|::::::::::::::::::::::::::|
　　　　|　||)ヽ:::::::::::::::／　　　　　　　　　＿___＿.| |)、:::::::::::::::::::ﾉ
　＿＿ヽ／::|｀ヽvv, |::＼　　　　　　　|＼＿_　.| 　＼_::∧:_／
　── ./::::/⌒ヽ'￣｀＼|.　　　　　　　|＼||￣　＼＿_ |　　|
　　　　 W |______,　　　,.－'－、.　　　　|＼||＿＿_　　/──ヽ
　　　　　　 |　　|　／　＿＿＿＼　　|＼||＿__|　／￣￣￣ヽ
　　　　　　　| 　|ヽ/ ／、　　　ﾉ|｀.|　　 |　 ||　　　|＿_|　　　　　|
　　　　　　　|　 |　| /　　＼_／ |:ﾉ　　　|　.|| ........　|　 |　　　　　|
　　　　　(,⌒ 丿　|::|　　./::| 　￣⌒ヽ　＼ｼｭｯ l|i|! !丿　　　　　|
　　　　　　￣　　　｀|　　⌒ヽ｀─ |　　|　ｼｭｯ i||!|i|!i|!,＿＿＿＿|
　　　　　　　　　　　　＼|　　|　　'─ ′ 　　（￣￣|:::::::::::::::::::::ﾉ
　　　　　　　　　　　　　'─-′　　　　　_,,..i'"':,｀-─└───
　　　　　　∧
／￣￣￣　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
ナポリタンが赤いことは証明されたがなぜ赤いかは不明なままだわ。
そこで、集合論的な考えを取り入れて考察することにしたの。
すると１つの疑問が浮かぶ。「ナポリタンだけが赤いのか？」。
一般的にスパゲッティは赤いわよね。少なくともわたしはこの数十年の人生で
青いスパゲッティや緑、橙、それら不気味と形容できうる色彩のスパゲッティを見たことが無いの。
だけど今からさかのぼること数時間、わたしは黒のスパゲッティを目の当たりにしたわ。
黒いスパゲッティが存在することから
逆説的に背理的に黒いナポリタンも存在することが確認できるのよ。
526 名前：仕様書無しさん mailto:sage [2008/04/22(火) 21:06:19 ]: >>524
何でそんなことをこのスレでいまさらやろうとするんだ？
もっとまともなとこでやりゃいいじゃん。
527 名前：仕様書無しさん mailto:sage [2008/04/22(火) 21:07:06 ]: 荒らしてんのアホコテだろ
528 名前：仕様書無しさん mailto:sage [2008/04/22(火) 22:09:54 ]: 自動車でいいだろ？
何もソフトに限る必要は無いわけだし
529 名前：仕様書無しさん mailto:sage [2008/04/22(火) 22:16:02 ]: >>おじゃば
真面目に質問させてくれ。
１．なぜお前はここまで反感を買ってると思うか？
２．OO（分析含む）はクラス図があればそれで充足するか？
３．今までに読んだOO本は何？
４．業務時間中にレスしてるのか？
５．質問に質問を返すのはなぜか？

簡潔に頼むわ
530 名前：仕様書無しさん mailto:sage [2008/04/22(火) 22:17:23 ]: >>528
スポーツカーがどうとか、積載量がどうとか、
「拡張性」の名のもとに、何もまとまりそうにない
531 名前：仕様書無しさん mailto:sage [2008/04/22(火) 22:31:25 ]: おじゃばが、OOのエキスパートだというなら、こんな正解の出ないことチンタラやってるより、
その高度なスキルを使った開発手法を示してみせるのが一番だと思うんだが。どうせなら、おじゃば
が何か面白いテーマを決めて、要件定義から製造、或いはテスト、メンテまで一通り開発しながら、
その思考の仮定をつぶさに示して見せればいいんじゃね。それこそ有無を言わせぬ圧倒的な能力を
示してみせればいいんだよ。結果で示せるから客観的に判断できるし、出来が良ければきっと応援
してくれる人もでてくるだろう。いつまでも、「俺は偉い」、「お前は馬鹿だ」じゃ水かけ論だろ？
532 名前：仕様書無しさん mailto:sage [2008/04/22(火) 22:51:28 ]: 圧倒的な能力とか夢から醒めて

つか彼はよくわからないことは全て「お前がやれ」とか職場によくいる無能の典型ですがな
そんなやつに無茶な要求してやるなよ　可哀想だろ
533 名前：おじゃば予測回答 mailto:sage [2008/04/22(火) 23:00:29 ]: １．なぜお前はここまで反感を買ってると思うか？
　　答え：反感？　お前らがひがんでんだろＷＷＷＷＷ
２．OO（分析含む）はクラス図があればそれで充足するか？
　　答え：あたりまえだろ
３．今までに読んだOO本は何？
　　答え：１０日でわかるオブジェクト指向を読んで３日でマスターしたぜ
４．業務時間中にレスしてるのか？
　　答え：業務時間なんて暇だろ？　ぷぷっ、お前ら無能だから忙しいんだよＷＷＷ
５．質問に質問を返すのはなぜか？
　　答え：？　意味がわからないぞ
534 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:05:25 ]: >>531
まぁ待て。
おじゃばはちゃんと「OOA・OODはよく知らん」的な発言をしてたと思うぞ。
535 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:21:09 ]: 発言もなにも明らからにわかっとらんだろこいつ。分かっとらんのに口だけは達者
536 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:27:40 ]: >>518
おめえ顔が真っ赤だぞ。
537 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:32:36 ]: >>534
その割には、オブジェクト指向の向き/不向きな分野など偉そうに語ってましたが...
538 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:32:56 ]: ttp://itpro.nikkeibp.co.jp/article/COLUMN/20061107/252787/?ST=develop
の中で住井さんがオブジェクト指向の何がいいのかわからない
って書いてあるけど皆さん(除く:おじゃば氏)はどう思います？
539 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:41:35 ]: お前ら虐めすぎだろ

もっとやれ
540 名前：仕様書無しさん mailto:sage [2008/04/22(火) 23:42:08 ]: >>518
分離するじゃなくてマスターデータ(作品)と在庫管理(ＤＶＤ)は別処理にするのが基本。
なんでそこで、継承なんて事した設計したのかって聞いているんだが。

マスターデータと管理データ一緒くたになるわけどどう処理するつもりだったの？
マスターデータ毎一々管理データ弄くる内容以外方法あるの？

考え中だから間違ったとかって言い訳なんないミスだと個人的に思うんだが。
まあ、おじゃばは違う意見かもしれないので上記と合わせて改めて質問しよう。

１:考え中で間違ったのか？
２:そうでないなら、マスターデータと在庫管理を一緒にするプログラムを構想していた。
３:その他(内容を具体的に書いてね)

どれ？
541 名前：393 mailto:sage [2008/04/22(火) 23:43:19 ]: >>499,502,507
新旧状態を「動的分類」と分析した、つまり「責務」が動的変わると思っている
実装レベルで変更可能な「責務」(メソッド)が追加されると思う、まだ概念レベルだから
「責務」(メソッド)はクラス図に実装していない、これで分かるか？
あと、多分これはインターフェースで実装すると思う
前のスレで、インターフェースと継承の使い分け方を聞いたが、
こんな場合などを想定して聞いた（あまり納得出来る回答は無かったが）

>>500,503
その通りだと思うが補足を書いとく、「動的分類」の簡単表現方法としてフラグがある
前に>>302もそう回答したが、この場合、条件文でその都度処理を振り分ける事になる
これが何故駄目か？　それはオブジェクト視点になっていないからだ
オブジェクト自身が今どのような状態（新旧）を分かっているのに
毎回条件文で判定する必要はない（その状態に必要な要素(フィールド)と責務(メソッド)があれば良い）
クラス視点で考えるから、毎回判定を必要とする考えになる
何度も言うが、オブジェクト指向はオブジェクト視点で考えないといけない

>>501,504,507 レンタルを考える時に、料金・期間を考えようと思っている

>>509
>いろいろあるが、まず最初に507とほぼ同意見。
>不要なクラスは消して欲しいな。あれで完成と言う事なら、次の問題点を指摘するが。
まだ完成でないが、問題点の指摘しても構わない、そうやって
徐々に作って行くつもりだが、「おじゃばさま」は別に設計するんじゃなかったのか？
それから、なんで「おじゃばさま」はツール使わないんだ？
542 名前：仕様書無しさん mailto:sage [2008/04/23(水) 00:26:04 ]: >538
OCamlなるものの知識は自分には無いが、
ソースが汚いのは理解できた
著者がOOを理解できてないのも理解できた
543 名前：仕様書無しさん mailto:sage [2008/04/23(水) 00:38:16 ]: >>529
>>533も良いがもっと冗長な文章を書くだろうな。
おれもおじゃばの回答予想してみたよ。
1.反感と言うより、お前らは俺の言うことを理解できない僻みから煽っているだけだろう。
2.必ずしも十分ではない（注：何が不足かは語ろうとしない）が、クラス図は必須だろう。
3.有名どころの本はすべて読んだ（注：具体的な書名は語らない）。お前たちは何を読んだんだ？おれの知らない本があったら教えてくれよ。
4.お前の業務時間が俺の業務時間だとは限らないだろう。そんな事も分からないのか？学生か？
5.それはお前たちの質問の意図が分からないからだろう。文章力が足りないのではないか？意図が伝わらないのはお前たちが分かっていない証拠だろう。
544 名前：仕様書無しさん mailto:sage [2008/04/23(水) 00:44:46 ]: 似てるｗ
イライラするぞｗ
545 名前：仕様書無しさん mailto:sage [2008/04/23(水) 00:47:17 ]: >>541
＞　オブジェクト自身が今どのような状態（新旧）を分かっているのに

日付変わったら状態変わる。
レンタル屋は24時間営業が多いから。
546 名前：仕様書無しさん mailto:sage [2008/04/23(水) 07:36:07 ]: 393 は名前欄に393と入れたり、消したり大変そうだな。

>>538
オブジェクト指向は少なくとも個人開発には絶大な効果があるよ。
複雑な物事をすっきりと整理し、各フェーズで注力すべきことを
分類する手助けをしてくれる。しかしこれがことチーム開発となる
と、優れたチームリーダと設計者、その設計の意図を汲んで実装で
きるPG、そして望むべくは優れたメンターがいるチームでなければ、
中途半端なOO技術は却って足かせとなったり融通がきかなくなる
確率がかなり高くなる。というのが俺の経験上の率直な意見。
ドロドロぐちゃぐちゃなスパゲティよりはまだ、フォークによく絡
まる単純なスパゲティの方がまし。

>>509
おじゃばよ、デザパタの組合せともいえるMVCパターンが、OOと関係ないという
明確な理由を教えてくれよ。あと、MVCはWebだけのものではないぞ。
547 名前：仕様書無しさん mailto:sage [2008/04/23(水) 07:37:37 ]: >393は要するに自分でDVDレンタルの話を振ってはみたが
会員側がなんとなく寂しいのでいろいろ妄想で付け加えた、でいいんだよね？
誰も法人会員や家族会員がDVDレンタルに必要とは言ってねえよなぁ。
548 名前：仕様書無しさん mailto:sage [2008/04/23(水) 07:40:44 ]: >>546
おじゃばに明確な理由を求めてはいけない。おじゃばは何を書いても
読めば意図は伝わると思っているから。
549 名前：仕様書無しさん mailto:sage [2008/04/23(水) 09:01:33 ]: OOが本当に拡張性が優れているのなら、将来のためにどうこう、が必要じゃなくて
いま現在最低限なものを作って、必要になったらそのとき簡単に追加できるよ、
というのを示さなくちゃいかんだろ。将来性のためにいま無いものをつけておく、
なんていったら、逆に拡張性がないちゅう主張にならんか？
だから法人会員だのなんだのは要らんと思うよ。
550 名前：仕様書無しさん [2008/04/23(水) 10:24:06 ]: >>519
519が信じるかどうかはともかく、ディストリビューションは長いから機種にしただけ。
俺的にはLinuxに詳しかったら知っていたら、ディストリビューションを知らないのではないかと言う
発想自体、出て来ないのではないかと思う。
REDHATが雑誌の付録は時代遅れだと言うのは認めるが、519の指摘は的外れだ。
俺なら時代遅れの方を責める。だから洞察力が低いと言った。納得できたか？

>>524
いや、プロセスを見るのが目的だから、今のままでいい。問題点がよく出ていると思う。

>>529
533と543が代わりに答えてくれているので、そんな感じ。

>>531
364-366でやっている。
ただこれは俺のOOのやり方で、名無しは「やり方が違う」と言っている。
実際、俺のと他の二人のを見れば、結果は分かるだろうと思ったのだが、分かっている人と分かっていない
人がいるようなので、これから違いを説明して行くつもり。
551 名前：仕様書無しさん mailto:sage [2008/04/23(水) 10:35:33 ]: >>550
日本語でおｋ
552 名前：仕様書無しさん mailto:sage [2008/04/23(水) 10:52:18 ]: >>550
何も言い返せなかったのでとにかくレスだけでもしてみた、ということだな。
読めば意味は伝わる。
553 名前：仕様書無しさん mailto:sage [2008/04/23(水) 11:45:16 ]: ＞Linuxに詳しかったら知っていたら

？
お前様の過去の発言を集約するとお前様が詳しいようには見えないわけですよ
当然時代おくれ発言の件も含めてね
過去にちょっと使ってみました程度の付け焼き刃知識しか持っていないように見える
これが妄想ではない推測ってヤツですよ

あとなんで名無し？
やっぱ名無し荒らしはお前様でしたか？
554 名前：仕様書無しさん mailto:sage [2008/04/23(水) 11:56:06 ]: 「長いから言い換えた」
この時点で間違ってるのだから
意味が「大きく変わって」いるのだから
素直に謝ればいいのではなかろうか

何故正当化しようと必死なのかと
正当化したければもう少しまともな理由を捏造すべき
555 名前：仕様書無しさん mailto:sage [2008/04/23(水) 12:03:35 ]: この手のコテハンつけたキチガイって、名無しは誰かひとり、とか数人の特定のヤツ
といった妄想をして、それに向かって吼えるという傾向があるからなぁ。
オマエラ、とか名無し、とか敵を特定したくてしかたないんだろうなぁ。
２ちゃんでは不毛なのに、なぜそんなことするのかは疑問なんだけどね。
556 名前：仕様書無しさん mailto:sage [2008/04/23(水) 12:32:01 ]: 糞コテには自分が優秀だと勘違いした目立ちたがりが多い
実際は無知とか無能とか呼ばれるアホそのものなんだけど
ついでにかまってちゃんであることも多い
現実世界では空気扱いか邪魔者扱いだから2chでかまってもらえて嬉しいわけですよ
現実世界では言い負けするから議論の基礎もわからないが
2chの議論ごっこなら実際は負けてても勝ったつもりにはなれるので依存する
支離滅裂な発言で周囲をドン引きさせながらでも
自分はとてもいいことを言ったとトンデモ認識できる人種だから
彼がその典型例
彼の今までの発言を見ればそれがわかるだろう？

相手が少ないとか弱いとか思い込むとか
仮想的を自分の都合のいいように設定するとか
アホの基本中の基本だよ
そして一方的に噛みついて勝手に自滅までワンパターン
557 名前：仕様書無しさん mailto:sage [2008/04/23(水) 12:55:01 ]: >>556
この手の人間のやっかいな理由として、
「自覚がない」を忘れちゃダメだろ。
558 名前：仕様書無しさん mailto:sage [2008/04/23(水) 14:51:21 ]: >>557
そうだな、おじゃばは　俺は違うな（根拠にならない妄言）だから。
とか言いそうだし。
559 名前：仕様書無しさん mailto:sage [2008/04/23(水) 17:36:12 ]: とりあえずお前らに言っておく。

レス番書くなら引用符を忘れるな。
560 名前：仕様書無しさん mailto:sage [2008/04/23(水) 19:29:53 ]: >>542
え～。むしろ著者が専門外のはずなのに、
オブジェクト指向まともに理解してるから関心たんだけど。
例えばC++ならネームスペース、テンプレート、オーバーライド等
オブジェクト指向以外の言語からの借り物が満載なわけです。
カプセル化、多態、委譲、デザパタの類はオブジェクト指向以外の言語でもできます。
で、どの辺がオブジェクト指向なのか追及すると継承と差分プログラミング
ってことになると思うけど、継承を使いまわすとわかりづらくなるので
避けて通るようなことも確かに多いでしょ。
まさにオブジェクト指向もどきだよなと。
561 名前：仕様書無しさん [2008/04/23(水) 19:52:34 ]: >>540
確かに、マスター管理と在庫を一緒にするプログラムなら面白かったかもしれないが、実際には違う。
最初にDVDは何か継承して作ろうと思ってextendsにした。その後、作品を作ったのでDVDのextendsに
くっつけたが、よく考えて見るとextendsにする必要性がなかった。
そこでDVDに作品番号を追加して分離したつもりが、extendsを取り忘れた。

>>541
364-366で設計済み。
ツール？ソースからのリバースしか使った事がない。

>>546
端的に言うと、データと関連する処理を1つのクラスにすると言うのが、OOの考え方だ。
MVCはデータとはちょっと違うがビューと処理を分離しようと言う考え方だ。だからむしろ逆の考え方だ。
デザパタはOOの（あまり実用性のない）サンプル集として使えるが、それを組み合わせて使っているからと
言って、OOになるとは限らない。OO部品でも処理毎に分類していれば、それは構造化と変わらないだろう。
562 名前：仕様書無しさん mailto:sage [2008/04/23(水) 20:18:09 ]: >確かに、マスター管理と在庫を一緒にするプログラムなら面白かったかもしれないが、実際には違う。

面白くない。ファイルにするにせよ、ＤＢにするにせよデータストアの管理がすごい面倒なわけだが。

>最初にDVDは何か継承して作ろうと思ってextendsにした。その後、作品を作ったのでDVDのextendsに
>くっつけたが、よく考えて見るとextendsにする必要性がなかった。

つまり、そこら辺推敲せずに上げたわけね。
作品番号で関連付けされているから問題ないだろと言いたいわけだな。

それはともかく、基幹データ系を何かに継承して作るの？
基幹データ系を元に継承して作るのが基本じゃね？

というのがクラスの基本だと思うわけだが違うの？
563 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/23(水) 20:22:18 ]: >>547,549
俺もそう思う。

>>553
Cコンパイラの件を見れば、少なくとも商用Linux3種で、コンパイル出来る環境にアクセス出来ると言うのが
分かるだろう。素直に考えれば、過去に触った付け焼き刃程度か分かるのではないか？
まあ、俺が無理して見栄を張っていると考えるのは勝手だが。
あと名前が名無しに変わってた。550,561は俺の発言だ。

>>554
正当化するつもりはない。些細な事だし、分かる人には分かっているのだから。
俺が言いたいのは、俺の心理を読んでいるみたいだけど、間違っているよと言う忠告だけだ。

>>555-557
俺は違うな。
564 名前：仕様書無しさん mailto:sage [2008/04/23(水) 20:29:25 ]: >>561,562
あはは、とうとうコテハンやめたけどageはかわらないのな。
いつもの自作自演はともかく、またもや基幹データ系なる言葉出してるし。

読めば意図が伝わる、からいいんだけどさ(笑)
565 名前：仕様書無しさん mailto:sage [2008/04/23(水) 20:31:08 ]: >>563
はいはい、分けてるつもりなのね。意図はわかったw
566 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/23(水) 20:33:39 ]: >>562
そう思う。反論する所はない。おっしゃる通りだ。
ああ、面白いというのは無茶だから面白いと言う意味だ。
567 名前：仕様書無しさん mailto:sage [2008/04/23(水) 21:02:57 ]: なんだよ
結局荒れてるじゃん
568 名前：キチガイ ◆Z4QrFDzwrY [2008/04/23(水) 21:18:06 ]: >>566
「商用Linux3種の検索結果約 123 件」とGoogle先生は仰っています
それで、おじゃまさまは今までにLinuxのどの”機種”を使ったの？
Linuxで何ができる？
Apache, Squid, Tomcat, Xen, MySQL, PostgreSQL, Oracle, … etc
何がしかのLinuxを使ったサーバのセットアップは当　然　経験済みだよね？
本番環境にXWindow入れてないよね？　SSH使えるよね？
>Cコンパイラの件を見れば、少なくとも商用Linux3種で、コンパイル出来る環境にアクセス出来ると言うのが
分かるだろう。
Cコンパイラの件ってのがわからないが、Cのコンパイルぐらい
yum install gcc(RHEL系), aptitude install gcc(debian系)でインストールして
gcc -o test test.cで終わりだろ
569 名前：仕様書無しさん mailto:sage [2008/04/23(水) 22:07:34 ]: >>541
＞それはオブジェクト視点になっていないからだ
俺は逆の意見。
むしろ責務が把握出来て無い段階でオブジェクトの内部構造を決めてしまうのは
思考停止なんじゃないかな、と思う。
「状態はとりあえずクラスにしておけば大丈夫」程度に思ってるように見える。

図を見る限り、今はレンタル商品名が新旧状態を把握出来てれば良いだけで、
新旧状態が属性だろうとクラスだろうとレンタル商品名オブジェクトの
振る舞いとしては大差は無い。(そらまだ振る舞い(責務？)が割り当てられて無いから当然)

多分、図に描かれて無いけど、経験とかから出てきた十分に根拠がある
責務やクラスの構成がある程度393の頭の中にあって、
そこから描かれたクラスの構成なんじゃないだろうか。
でも頭の中にあるものは俺には見えないので、分析や設計のプロセスが
若干飛躍してるように見えてる気がする。
570 名前：仕様書無しさん mailto:sage [2008/04/23(水) 22:26:08 ]: >>563
＞少なくとも商用Linux3種で、コンパイル出来る環境にアクセス出来る

付け焼き刃程度っていうかぶっちゃけ初歩中の初歩じゃない？
その程度でどうしてそんなに自慢げなのかな？
せめてもう少しハッタリ効かせたほうがいいよ？

＞正当化するつもりはない。

え？言動不一致も甚だしいよね？

＞些細な事だし、

意味合いが大きく変わってるよ？
つか無駄に傷口を広げてるのはお前自身の発言だよ？

＞分かる人には分かっている

明らかに間違っていることはわかったよ？
それでいいのかな？

＞俺の心理を読んでいるみたい

心理を読むってそれなんて妄想？
間違ったのがわかっているなら謝ればって忠告じゃない？
もしかして忠告は全て攻撃と受け取るタイプの人種＝阿呆なの？
571 名前：仕様書無しさん mailto:sage [2008/04/23(水) 23:00:50 ]: linuxとかgccとかmvcとか、どうでもいいだろ
572 名前：仕様書無しさん mailto:sage [2008/04/23(水) 23:08:32 ]: どうでもよくないことはなんだ？
573 名前：仕様書無しさん mailto:sage [2008/04/23(水) 23:34:56 ]: >>568
話の本筋と関係ないことに突っ込むのもなんだが・・・
＞gcc -o test test.cで終わりだろ

test という名前をつけるのはやめれｗ
574 名前：>509 mailto:sage [2008/04/23(水) 23:54:33 ]: >そして全体のコントロールの行き場がなくなったか。
いや、それは497で書いてるし、

>とりあえずMVCは忘れた方がいいのではないか？
MVCなんて一言も書いてない
575 名前：仕様書無しさん mailto:sage [2008/04/23(水) 23:54:54 ]: 見ていて訳が分からないので、要求仕様を勝手にまとめてみた。

１．レンタルショップにて使用する
　　レンタルシステムを開発してほしい。
２．レンタルシステムは会員制であり、
　　初回に会員登録をしてからの利用となる。
３．レンタルする際には、カードを提示してもらう。
４．レンタル情報を一元管理し、
　　レンタルの延滞などかチェックできるようにしたい。
５．レンタルできる商品は現在「ビデオ」と「ＤＶＤ」である。
　　だが、今後「ブルーレイ」等が出てきても対応できるようにしてほしい。
６．現在、会員は個人登録に限っているが、今後顧客を増加させるために、
　　「家族や企業単位で登録していただくとレンタル料金を安くする」
　　ということをしたい。
７．また、長年当ショップを利用していただいたお客様には、
　　別途レンタル料金を安く出来るようにしたい。
８．レンタル商品には「新作」・「準新作」・「旧作」とあり、
　　作品ごとに以上の属性がつく。
９．料金は、主に「新作」等の属性によって判断されるが、
　　特価日や特殊な作品によっては値段が違う場合があるので、
　　それに対応して欲しい。

とりあえずこんなところかな？
なんか足りないような気もするが・・・
違っているところや足りないところ、余分があったら言ってくれ。
あと、言葉が悪いところが有るかもしれない。そこはつっこんでくれ。

長文失礼
576 名前：仕様書無しさん mailto:sage [2008/04/23(水) 23:59:58 ]: >>564
562だが、おれはおじゃばじゃないぞ。
不名誉な。
オレもオマエモナー(古)。
577 名前：仕様書無しさん mailto:sage [2008/04/24(木) 01:25:09 ]: >端的に言うと、データと関連する処理を1つのクラスにすると言うのが、OOの考え方だ。
>MVCはデータとはちょっと違うがビューと処理を分離しようと言う考え方だ。だからむしろ逆の考え方だ。

M,V,Cそれぞれがクラス(郡)になると思うんだけど(^^;
※ttp://www.shos.info/develop/oo/ooword.html#mvc
　>GUI アプリケーションを Model (ビジネスロジック部分)，View (表示・入出力部分)，Controller (通信・制御）のように三つの部分に分けてなるべく独立した作りとする．
　>各部分間の相互依存性を低減させることで全体の保守性・拡張性を向上させることを目的としている．
578 名前：仕様書無しさん mailto:sage [2008/04/24(木) 01:29:39 ]: >３．レンタルする際には、カードを提示してもらう。
Q)カードがあれば常にOK? 他に条件はないのか？

>４．レンタル情報を一元管理し、
>　　レンタルの延滞などかチェックできるようにしたい。
Q)チェックしてどうする?(どうしたい?)

>９．料金は、主に「新作」等の属性によって判断されるが、
>　　特価日や特殊な作品によっては値段が違う場合があるので、
Q)kwsk
579 名前：仕様書無しさん mailto:sage [2008/04/24(木) 01:41:03 ]: つか、MVCはsmalltalkの基本パターンだったりするわけで
>ttp://www.cue.im.dendai.ac.jp/~masuda/mvc/index.html
OOと逆の考え方なんていったら、じゃそのOOって何よ？
おじゃばはMVCがクラス(モジュール)の作り方だとでも思ってるのか。
ほんとに何も知らないのによくもまあ・・・
580 名前：仕様書無しさん mailto:sage [2008/04/24(木) 02:21:28 ]: >>572
linuxとかスレ違いだろ
アホコテも悲惨だが釣られてあげすぎ
581 名前：仕様書無しさん mailto:sage [2008/04/24(木) 02:25:47 ]: いいからMVCは捨てろ
話がずれる
582 名前：仕様書無しさん mailto:sage [2008/04/24(木) 02:36:36 ]: MVCは拘りと美学だよ
583 名前：仕様書無しさん mailto:sage [2008/04/24(木) 02:57:03 ]: 話がずれる、ってあーた、DVDレンタルを作るスレでもないよね本来。
584 名前：仕様書無しさん mailto:sage [2008/04/24(木) 07:10:49 ]: >>579
Smalltalk?ああ、よく知っている。何年か使ったがあれはOOとは方向性が違うと思う。
とか言いそうだぞ、おじゃば。
585 名前：仕様書無しさん mailto:sage [2008/04/24(木) 18:49:45 ]: Smalltalkは実業務では使われていないだろう。
的なおじゃばレスを以前見たような…
586 名前：仕様書無しさん mailto:sage [2008/04/24(木) 18:50:44 ]: >583
課題みたいなもんやし、レンタルシステムでOOを考えるのは悪くない
ただ、提案者がOOを理解してないことと、
協調性が無さ過ぎるため形になってないだけ
587 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/24(木) 19:08:10 ]: >>568
前スレ落ちていたから知らないのか。
Cコンパイラの件というのは、コンパイラの動作に違いを確認すると言う話があった時に、
俺がHEDHAT(EL)、Miracle、Montavistaで検証したら、名無しに商用なので検証出来ないと文句を言われた件だ。
質問に簡単に答えておくとSquid、Xen以外は経験済み。あと、商用では普通yumなどは使わない。
ハンドルがキ○ガイになっている所を見ると、質問に素人臭さが出ているのは、わざとかな？

>>570
3つで初級なら、3つ検証出来なかった多くの人は、初級以下になるのではないか？
心理を読むと言うのは、その前の発言で「図星で悔しい」と予想していた件だよ。

>>574
では「～処理」でクラスが分かれているのは何故だ？

>>575
要求仕様は出してある。
・ツタヤ店舗、DVDレンタルのみを想定
・会員1種類
・料金体系
「当日、1/2泊、2/3泊、3/4泊、7/8泊、延滞」×「新作、準新作、旧作」
「旧作半額、旧作5本で1000円」などもあり
498の設計は設計者が独自に拡張して設計した物だ。
確か498は「OOとは変更を予測して作成する」物で「設計時に組み込んでおけば低いコストで実現出来る」
と言っていた。だから設計に合わせて要求を変える事なく、本当に低コストかとか、要求にある機能
との整合性は取れるのかなどを考えるべきだと思う。
588 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/24(木) 19:32:58 ]: >>577,579
MVCはあくまでも画面デザインのメンテナンス性を上げる、OOとは別の手段であって、OOではない。
ちなみに、
>各部分間の相互依存性を低減させることで全体の保守性・拡張性を向上させることを目的としている．
これは嘘だろう。ビューとコントロールは密接だ。デザインやレイアウトを変更するのは自由でも、
項目が増えればコントローラーは変更になる。Strutsの経験があれば分かるはずだ。
MVCは全体の保守性、拡張性を落として、ビューのメンテナンス性を向上させた物だ。

OOとは抽象化によって、オブジェクト単位での変更を容易にした物を言う。
つまりDVDがCDになったとして、多くのクラスに変更が必要になる設計はOOとは言えないと言う事になる。
589 名前：仕様書無しさん mailto:sage [2008/04/24(木) 19:50:34 ]: >>587
あれ、それはコンパイラの癖じゃなかったのか？
590 名前：仕様書無しさん mailto:sage [2008/04/24(木) 19:55:01 ]: >>588
StrutsのMVCが問題があるという発想にならないのか？
あれ(俺が知ってる1.1までは)はXMLに汚いところを逃がしただけのもんだぞ。
お前と同様時代遅れかもしらんがなｗ
591 名前：仕様書無しさん mailto:sage [2008/04/24(木) 20:08:26 ]: >>588
ついでに言うと、お前、Modelのことはどーでもいいのか？
項目が増えればうんぬんはModelのことが何もわかってないつことだぞ。
そこが無くて何が抽象化なんだ？
592 名前：仕様書無しさん mailto:sage [2008/04/24(木) 21:11:32 ]: >>587
＞・ツタヤ店舗、DVDレンタルのみを想定
こんな要求があってたまるか。
俺はツタヤでバイトしたこと無いので、
ツタヤがどんなシステムを使ってるかなど知らぬ。

おじゃばが言ってるのは、単なる「業務の説明」で
システムに対する要求仕様どころか要望にすらなってねぇよ。
なんだ？お前の言うOOはコンサルから始まるのか？

「ツタヤみたいなレンタルビデオ屋を作りたいんですがどうすれば良いですか？」

知　る　か
593 名前：仕様書無しさん mailto:sage [2008/04/24(木) 21:12:29 ]: >>587
> 検証出来なかった
アセンブリコードすら読めず
挙げ句すぐに証拠を出せずうだうだうだうだ引き延ばしては
ごまかしてたのは誰なんだい？
594 名前：仕様書無しさん mailto:sage [2008/04/24(木) 21:35:19 ]: おじゃばさまぁ、しつも～んっ！

>OOとは抽象化によって、オブジェクト単位での変更を容易にした物を言う。
ここで言ってる抽象化ってどういう意味ですか？具体的に教えてください。

>つまりDVDがCDになったとして、多くのクラスに変更が必要になる設計はOOとは言えないと言う事になる。
DVDが貸し衣装やレンタル建築機材になったとした場合も同じですか？
595 名前：仕様書無しさん mailto:sage [2008/04/24(木) 22:46:34 ]: >>592
でもそういうのってままあるらしいね

○○（業界最大手）みたいなシステムをうちの会社にも作ってくれ

とかそんなの
596 名前：仕様書無しさん mailto:sage [2008/04/24(木) 22:55:58 ]: >>595
同じものを作れっていうんだから驚くよね。買って来れば？って言いたくなる。
597 名前：仕様書無しさん mailto:sage [2008/04/24(木) 23:51:44 ]: 最近はトヨタ方式にしてくれって言ってくるクライアントがいたな
日経に洗脳されてるようだった
598 名前：仕様書無しさん mailto:sage [2008/04/25(金) 00:13:51 ]: >>587
それだけでシステムが開発できるとでも思ってるのか？
そもそも、『要求』が無いじゃないか。

>>578
ありがとう。

>>３．レンタルする際には、カードを提示してもらう。
>Q)カードがあれば常にOK? 他に条件はないのか？
カードがあればOK。他の条件は一切無いものとする。

>>４．レンタル情報を一元管理し、
>>　　レンタルの延滞などかチェックできるようにしたい。
>Q)チェックしてどうする?(どうしたい?)
返却予定日（延滞の発生しない最終日）から１週間が経過したら、
借り主に延滞通知（手紙）を１週間毎に送信する。送信先は、
会員登録時に住所を記入してもらい、そこへ発送する。
それ以外には使用しない。
599 名前：仕様書無しさん mailto:sage [2008/04/25(金) 00:15:01 ]: >>598続き
>>９．料金は、主に「新作」等の属性によって判断されるが、
>>　　特価日や特殊な作品によっては値段が違う場合があるので、
>Q)kwsk
通常料金　　新作：４７０円　１泊２日
　　　　　準新作：３７０円　２泊３日
　　　　　　旧作：３００円　７泊８日
特別料金
・特定の１週間について、旧作を１本１００円とする。
・特定の１ヶ月について、旧作４本をまとめて１０００円とする。
・クーポンを使用して１００円引きすることができる。
　（クーポンには作品名が１作品明記されており、その作品にのみ適用可能）

だいぶ足りなかったな。すまん。
まだあったらよろしく頼む。

長文失礼
600 名前：393 mailto:sage [2008/04/25(金) 00:32:17 ]: 取りあえず、貸出状態と色々な料金・期間に対応する為に「会員」「レンタル」「商品」に追加してみる
www.dotup.org/uploda/www.dotup.org25258.jpg

次に考えるのは複数割引、今のモデルだとレンタルが1件単位になっているから、レンタルの複数対応を
考えて見るが、その前に>>569に回答しとくと、
www.dotup.org/uploda/www.dotup.org25260.jpg
まず、「新旧状態」は要素では無い、要素を区別するものだ、要素は「新作状態」「準新作状態」「旧作状態」になる（図の左）
この要素は、動的に変化するがUMLではこれを＜＜動的＞＞のステレオタイプで表現するのがルールだ（図の真中）
このままでは、既存の言語では表現出来ないのでSTATEパターンを使って表現する（図の右）

>「状態はとりあえずクラスにしておけば大丈夫」程度に思ってるように見える。
ちゃんと要素抽出して、UMLのルールに従っている

>図を見る限り、今はレンタル商品名が新旧状態を把握出来てれば良いだけで、
>新旧状態が属性だろうとクラスだろうとレンタル商品名オブジェクトの
>振る舞いとしては大差は無い。(そらまだ振る舞い(責務？)が割り当てられて無いから当然)
もともと新旧状態と言う要素はない、それに基本的に型（クラス）は要素によって
分けるもので「責務」は関係してこない（もちろん最終的に「責務」の無い型（クラス）は
使いようがないから、作成しないが）

>>599
なるべくモデリングしてみる、俺からの提案は
将来的には、会員登録しなくても借りられるようになる（返す必要がなくなる）
会員制はビジネス客を限定するから、出来れば辞めたいと考えるはず
でも、逆に客を囲いたいからポイント制もあるかもしれない、両方に対応出来るようにする
601 名前：>584 mailto:sage [2008/04/25(金) 00:43:24 ]: >では「～処理」でクラスが分かれている
???
602 名前：>600 mailto:sage [2008/04/25(金) 00:48:17 ]: >599 みたく、新旧状態によって「料金やレンタル可能な期間が違う」って話がでてねーよ
ってことだろ？

>>新旧状態が属性だろうとクラスだろうとレンタル商品名オブジェクトの
>>振る舞いとしては大差は無い。(そらまだ振る舞い(責務？)が割り当てられて無いから当然)
603 名前：仕様書無しさん mailto:sage [2008/04/25(金) 03:11:53 ]: なるほど、難しいところはスルーして先送りするのがオブジェクト指向か。
そりゃ開発効率はいいやなｗ
604 名前：仕様書無しさん mailto:sage [2008/04/25(金) 03:32:26 ]: そして設計に時間を費やして肝心のモノはいつまでたっても出てこない
不安にかられた顧客が現場で目にしたものは数枚の落書きだけだった・・・
605 名前：仕様書無しさん mailto:sage [2008/04/25(金) 07:05:12 ]: >>600
>会員登録しなくても借りられるようになる（返す必要がなくなる）
それを世間的には販売と呼ぶんじゃないのかw
606 名前：仕様書無しさん mailto:sage [2008/04/25(金) 07:45:12 ]: >>561
>デザパタはOOの（あまり実用性のない）サンプル集として使えるが、

その台詞はデザパタをマスター（笑）した者だけが吐ける台詞だ。デザパタをマスター（笑）
していないお前に言われても説得力がない。
607 名前：仕様書無しさん mailto:sage [2008/04/25(金) 08:26:34 ]: 長々このスレやってるけど、どー考えてもおじゃばはOO否定派にしか思えないんだが。
OOの利点が本人にもよく説明できないコーディングレベルの抽象化(笑)しかない、と主張。
分析にも設計にも役に立たないと主張。ヒアリングも分析も設計も区別ついてないんだけどｗ
いったい何がしたいんだろコイツ。やっぱ学校の先生ごっこかな？
608 名前：仕様書無しさん mailto:sage [2008/04/25(金) 08:43:58 ]: というよりも、クラス図とかみるとコボラー臭感じるの漏れだけ？
609 名前：仕様書無しさん mailto:sage [2008/04/25(金) 09:38:00 ]: >>608
俺もそれは思った。redhat付録の件とか、ひな鳥世代とか言う発言からして年寄り臭い。
～処理とか結局手続き単位でしか考えられないみたいだし、肝心のOOはコーダレベルで
Strutsについてけないし。背伸びしてるけど取り残されてるか、病気でブランクでもあんじゃね？
610 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/25(金) 09:53:46 ]: >>590,591
ではMVCにする事によって、「全体」の保守性、拡張性が向上するのか？
もし向上するなら何故、GUIや画面関係だけでなく、全体に採用しないのか？

>>592
当初はツタヤを想定していたが、WEB店舗やCDレンタルを含めると複雑になるから外した。
つーか592の発言はひどいな。本気で言っているのか？596もひどい。
はっきり言って、587の情報である程度設計出来ないようでは、設計者としては失格だ。
595,597の言うような場合もあるし、極端な例では「予算余ったから何か作って」と言うのもある。
要求が曖昧なほど、SEの技量の見せ所だろう
>客：「ツタヤみたいなレンタルビデオ屋を作りたいんですがどうすれば良いですか？」
>592：「知　る　か」
>596：「ツタヤで買って来れば？」
こんな会社、やばいんじゃないか？

>>594
>ここで言ってる抽象化ってどういう意味ですか？具体的に教えてください。
システムから状態と動作のセットを抜き出すことだ。
今回のシステムで言うと、DVDレンタルから、会員の情報と処理を抜き出してクラスにする事だ。

>DVDが貸し衣装やレンタル建築機材になったとした場合も同じですか？
非常に良い指摘だ。適切に抽象化されていれば、理論的には同様の形態のサービスにも変更が容易になる。
つまり、DVDのように客に期間で商品を貸出すサービスに転用可能と言う事だ。
貸衣裳や建築機器は、DVDと貸しだし期間や商品の扱いがかなり違うようなので変更が多いだろうが、
レンタカーなどは少し変更すれば流用可能になるはずだ。必要性は別にしてだが。
611 名前：仕様書無しさん mailto:sage [2008/04/25(金) 11:16:16 ]: 必要性って話ならここ数スレの流れが全て要らないよね
つーかお前の存在が一番要らない・・・・
612 名前：仕様書無しさん mailto:sage [2008/04/25(金) 11:23:49 ]: >>610
>ではMVCにする事によって、「全体」の保守性、拡張性が向上するのか？
>もし向上するなら何故、GUIや画面関係だけでなく、全体に採用しないのか？
だから、Modelはどーしたんだｗ
全体って何？夜間バッチとかも入れてか？そらぁViewが無い部分はMVCにゃならんだろ。
あ、夜間バッチでも帳票出力はあるな。あれもMVC使ってるぞ。
結局おじゃばはMVCが何なのか知らないんだな。毎度のことだけど。
613 名前：仕様書無しさん mailto:sage [2008/04/25(金) 15:14:25 ]: お前ら熱くなりすぎ
おじゃばが賢くなったらこのスレの存在意義が無くなるだろ
614 名前：393 mailto:sage [2008/04/25(金) 20:42:55 ]: よく分からん議論だな

普通MVCと言ったら、MVCアーキテクチャの事だろ、違うのか？
つまり、構造の事だから厳密にはオブジェクト指向には関係ない
MVCパターンは、MVCアーキテクチャを実装する手法の一つで
オブジェクト指向に関係はするが．．．
話が噛み合ってないじゃないか？
615 名前：仕様書無しさん mailto:sage [2008/04/25(金) 21:33:07 ]: OOじゃないMVCパターンでModelクラスが何の仕事するのか教えてください
616 名前：仕様書無しさん mailto:sage [2008/04/25(金) 22:06:50 ]: つぅかOO使わないMVCなんてあんのかよ。MVCとOOが関係無いなんてバカじゃねぇの？
カレー粉とカレーパンが関係無いとでもいうつもりか？　カレー粉を使った新しい調理方
にしか興味ねぇのかよ。
617 名前：仕様書無しさん mailto:sage [2008/04/25(金) 22:48:34 ]: >614
分からないなら口を出すな
618 名前：仕様書無しさん mailto:sage [2008/04/25(金) 23:05:06 ]: また393に、やられているよｗ
お前らの知識じゃ393には敵わなだろう
619 名前：仕様書無しさん mailto:sage [2008/04/25(金) 23:09:34 ]: >>610
>（抽象化とは）システムから状態と動作のセットを抜き出すことだ。

ここおかしいです。システムはこれから作ろう、或いは考えようとしてるもだから、
通常まだ存在していません。存在してないものから何かを抜き出すことはできません。
抜き出すべき場所は問題領域（ドメイン）からです。システム開発における抽象化
とは、問題領域の中での物事の役割とらえ、その特徴をクラスとして或いはクラス同
士の関連として表現することです。結果として対象物が持つべきインタフェースの
抽出を行うことになります。そのインターフェースを実装するために、結果的に状
態を保持する必要があるケースもありますが、状態の保持は必須ではありません。
繰り返しますが、抽象化とは、着目しているオブジェクトが受け持つべき役割を見出
し、外部とのインターフェースを決めてやることです。

それと、レンタカーとDVDレンタルのシステムが、少しの変更で流用可能になるだろ
うというのはあまりにも楽観的すぎます。商品の属性（レンタカーにはグレードや
オプション、保険などがあります）が違います、返却方法（レンタカーは返却場所を
選べたりします）も違います、清算方法（レンタカーは後払いだったり、残油量によっ
て料金も変わったりします）も違います。もちろん商品管理の方法も違います。
DVDレンタルシステムがレンタカーに流用できるのは、あらかじめ、両方に対応できる
ように設計していた場合だけです。そして普通、そういう要件でもない限り、限られた
予算と工数の中でそんなことまで考えて設計しません。
620 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/26(土) 00:50:41 ]: >>615
簡単に言うと、ビューの内容でデータベースの内容を書き換えたりするのだろう？

>>616
カレー粉を使っているから、カレーパンはカレーだと言うと事で、
デザパタ部品を使っているから、OOになると言うと論理か？
でもカレー粉を使っていても、インド料理にはなるとは限らないぞ。

>619
外部とのIFを決めるには、内部で保持すべき情報と、動作を把握しなければならないのではないか？
あと一応、「理論的」には「同様の形態のサービス」にも変更が容易になる、と書いた。
つまり形態が違うので実際にはDVDをレンタカーにするのは難しいが、それを承知でやってみよう。
その前にDVDのは抽象化が低く、DVDと名前が入っていてしまったので、DVDは商品に名前を変えておく。
あと良く見たら、会員に住所や氏名が抜けていたので追加した。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 商品{シリアル番号、作品番号、入荷日、貸出日：検索()};
class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------
621 名前：おじゃばさま ◆GxjxF3yEw6 [2008/04/26(土) 00:54:44 ]: ツタヤでもDVDは別の店に返せるようだが、簡略化のため1店舗の設計にした。
レンタカーも簡略化のため1店舗とする。また燃料は満タンにして返すとする。
-----------------------------------------------------------------------------------------------
class 車種 extends 作品{メーカー、名称、グレード};
class レンタカー料金表 extends 料金表{保険種類};
class レンタカー会員 extends 会員{免許証番号、ゴールド識別};
class レンタカー貸出履歴 extends 貸出履歴{前払い分};
-----------------------------------------------------------------------------------------------
結構簡単に変更出来るのではないかな？
622 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:06:39 ]: >>620
・・・これっぽっちも抽象化されてないじゃん
あ、抽象化（笑）って「DVD」って入れないことを言うのかｗ
たしかにそれなら「作品」を「車輌」に置換すればレンタカーになるな。
おーすごいぞ抽象化（笑）
623 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:14:41 ]: >>621
基底クラスに「レンタルシステム」、そっから「DVDレンタル」「レンタカー」としないと抽象化じゃないだろ。
あらゆるレンタル業務はまずTSUTAYAからはじまるのかｗ
624 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:18:53 ]: >>620-621
ちょ、おじゃば、無理しすぎだろ。無理しすぎてかえって複雑になってる。
レンタカーは会員必須じゃない時点で根本的に無理があるし、車種が継承している
作品には、レンタカーにゃいらん属性がいっぱいあるし、なんで、こんな無理してまで
流用しなきゃなんねんだ？　こんなんじゃ破綻すんの目に見えてっだろ？全然説得力ねぇよ。

読解力ねぇな、普通に読めば、
カレー粉を使っているから、カレーパンとカレー粉は関係ある。
OOを使っているから、MVCとOOは関係あると言ってる。曲解すんな。
625 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:22:53 ]: おじゃばの理論でいけば、ビデオレンタルシステムをサラ金のシステムへも流用できそうだな。
626 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:34:52 ]: 時々居るよね
OO信者のクセしてまともな設計が出来ない馬鹿
627 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:48:12 ]: >>620
>>外部とのIFを決めるには、内部で保持すべき情報と、動作を把握しなければならないのではないか？

必ずしも内部で情報を保持する必要はない。インターフェースを満たしていさえすればいい。
例えば簡単な例で、6面さいころを抽象化したとしよう。さいころに与えるインターフェースは、

int 振る()

だ。引数はとらず、int型（正確には1～6の数値だが）の値をランダムに返しさえすれば条件を満たす。
内部的に情報を保持しようがしまいがどうでもいい。実装者次第だ。
さいころをいかさまに使いたい場合は、特定の条件下で特定の目がでるようにするために内部状態を
保持する必要があるかもしれないが、通常は、

int 振る() {
　　return int(random(6) + 1);
}

などといった実装で十分だ。繰り返すがインターフェースの条件さえ満たせば、クラス内部で状態を
保持することは直接的な必須条件ではない。抽象化において状態の保持が必須なら、Javaでもインター
フェースは不要で抽象クラスのみがあればよいということになってしまう。Javaでどうしてインター
フェースという言語機能が提供されているのか少しは考えてみればいい。
おじゃばは頭の思考が硬すぎてこちらの意図を伝えるのに苦労させられる。もうすこし相手の意図を汲む
努力と、想像力を働かして柔軟な思考をするようにして欲しい。
628 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:49:28 ]: 無茶言うなバカ野郎
629 名前：仕様書無しさん mailto:sage [2008/04/26(土) 01:56:16 ]: そうだ、無茶言うな
>おじゃばは頭の思考が硬すぎてこちらの意図を伝えるのに苦労させられる。
だけじゃばくって、おじゃばは自分の言うことはどんなに変でも意図は伝わると考えてるあまえんぼさんなんだぞ。
630 名前：仕様書無しさん mailto:sage [2008/04/26(土) 02:03:30 ]: 「あまえんぼさん」なんて、かわいいもんじゃないだろ。
631 名前：仕様書無しさん mailto:sage [2008/04/26(土) 02:25:24 ]: >>620 そりゃ形態が同じなら流用できるし、形態が違えば流用が難しくなるのはあたり前だろ。お前バカか？いや、あまえんぼさんか？
632 名前：仕様書無しさん mailto:sage [2008/04/26(土) 03:39:43 ]: >>624
＞レンタカーは会員必須じゃない時点で根本的に無理がある

レンタカーの場合免許が必要なわけで、これは国が唯一の番号だと保障してくれてるわけだから
全ての免許取得者は会員であるが未入力であると言う仮定が成立する。
633 名前：仕様書無しさん mailto:sage [2008/04/26(土) 04:52:56 ]: >おじゃば
自ら要件を壊すなよ
DVDのみ、って自分で要件定義したんだろ
ちょっと話になったぐらいで「レンタカーの考慮を加える」とか言うと話がまた変わるだろ
自分で自分の首を絞めてどうすんだ
634 名前：仕様書無しさん mailto:sage [2008/04/26(土) 09:21:40 ]: >class 作品{作品番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
>class 車種 extends 作品{メーカー、名称、グレード};

ふむ、カローラに年齢制限があるのか。

>結構簡単に変更出来るのではないかな？

利用・保守する側は結構大変そうだがな。
635 名前：仕様書無しさん mailto:sage [2008/04/26(土) 13:11:46 ]: おじゃばはER図からおこしたテーブル項目にgetter,setterをつけたものが
クラスだと思ってるからな。考え方がDOAから抜けきれていない。
636 名前：仕様書無しさん mailto:sage [2008/04/26(土) 13:29:19 ]: >>635
そのDOAもあやしいがｗショップと倉庫はどう違うのよ。貸し出し中かどうかのために
倉庫なんてのをつくったのかいな。
637 名前：仕様書無しさん mailto:sage [2008/04/26(土) 13:46:45 ]: おじゃばは今日も元気に廃棄getしてますか？
638 名前：仕様書無しさん mailto:sage [2008/04/26(土) 14:29:00 ]: おじゃばのモデリングみてたら頭がくらくらしてきた。
車種 is 作品 ?
車の属性に「色」を追加してくれっていわれたら、いったいどのクラスに追加したらいいんだ？
グレードは同じなのに、色が増えるたんびに車種のインスタンスも増やさなきゃならないのか？
カーナビとか、チャイルドシートとか、レンタカーのオプションがどんだけあるか分かってんのか？
汎用化しようとして、本来簡単なことを無駄に複雑にしてる例の典型。しかもその汎用化すら怪しい
ものになってる。
こんな馬鹿馬鹿しい設計を、無理矢理使えるように実装させられる身にもなってみろ、バカ野郎。
639 名前：仕様書無しさん mailto:sage [2008/04/26(土) 18:43:07 ]: オブジェクト指向の極意はサブシステム化にある。
分かるかな。
640 名前：仕様書無しさん mailto:sage [2008/04/26(土) 20:57:06 ]: レンタルならこれが答え
・会員台帳
・貸出台帳
・代金台帳
641 名前：仕様書無しさん mailto:sage [2008/04/26(土) 21:12:12 ]: >>638
おじゃばは、そういう大勢で大きなシステム組んだこと無いヤツだから言うだけ無駄.
半年で何回か納品したとか、仕様を書かずにコーディングから始めた自分が周りより仕事早いぜ、って威張るレベル。
設計したもんをヒトに作らせるなんてとんでもない。なのに知識は五年前のおっさんなんだよなぁ。
642 名前：仕様書無しさん mailto:sage [2008/04/26(土) 21:55:17 ]: こういうのはどうすんの？
・ブラック顧客リストの登録・判定
・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
・客がレンタル品を壊した場合
・盗まれた場合の商品の特定と登録抹消処理
・商品の予約をどうするか
643 名前：仕様書無しさん mailto:sage [2008/04/26(土) 22:10:10 ]: >>632
ビデオレンタルの場合は、「レンタルする」の事前条件が、「会員であること」
なわけで、システム的には会員番号をキーにした設計がされている可能性が高い。
一方、レンタカーの場合は、免許証の内容が流動的だという点を考慮する必要が
ある。たんに期限だけをチェックすればいいというものではない。免停や取消に
なっている可能性もあるし、オートバイのレンタルには自動二輪免許が、大型トラッ
クの場合は大型免許が必要だろう。その免許をとった時点で免許証も書き換えられ
ているわけだから、免許証の有効性は、毎回現物を目視して確認する必要がある。
DBに登録しておいたものを照合して終わりというわけにはいかないし、ビデオレン
タルとは手続きがかなり違う。また業種が違うわけだから、管理資料として必要な
出力物の内容も違うだろう。無理して流用できなくもないかもしれないが、よっぽ
どうまく設計されていない限り、流用によるメリットよりデメリットの方が大きい
だろう。

>>634
車はR18指定ってことじゃね？つぅかこれは年齢制限というより、免許証を提示さ
れた時点で満たしてる事だけどな。会員の属性としては、年齢というより生年月日
を使うべきだろうな。
644 名前：仕様書無しさん mailto:sage [2008/04/26(土) 22:18:52 ]: >>643
性犯罪者はエロビデオレンタルしたらいけないらしいよ。
つまり、

免許停止＝性犯罪の前歴あり
645 名前：仕様書無しさん mailto:sage [2008/04/26(土) 22:21:23 ]: >>642
その件でしたら、今回は予算的に厳しい状況でございますので、
二次開発でということにさせてはいただけないでしょうか？
646 名前：仕様書無しさん mailto:sage [2008/04/26(土) 22:33:07 ]: >>644 性犯罪の前歴ってどうやってチェックすんの？
647 名前：仕様書無しさん mailto:sage [2008/04/26(土) 22:35:09 ]: >>645
ちょっと！これやってもらわないとお金払えないからね！
648 名前：仕様書無しさん [2008/04/26(土) 23:43:19 ]: >>646
普通に警察のホームページに書いてあるよ。
名前と住所と顔写真入りで。
649 名前：仕様書無しさん mailto:sage [2008/04/26(土) 23:56:12 ]: 書いてねぇよアホ。書いてあったとしてもいちいちチェックなんかしてらんねぇよ。
650 名前：仕様書無しさん mailto:sage [2008/04/28(月) 20:48:32 ]: おじゃば、いっちょまえに休みかよ、おじゃばのくせに。
651 名前：仕様書無しさん mailto:sage [2008/04/29(火) 01:32:49 ]: 601 ：>584：2008/04/25(金) 00:43:24
>では「～処理」でクラスが分かれている
???
652 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/08(木) 08:58:23 ]: >>623
実際は623の言う通り、レンタルを基底にするべきだろう。
ただ注意すべき点は、DVDレンタルしかない時点で基底と派生に分割する必要はないと言う事だ。
では分割して見よう。作品をカタログにしてみる。
-----------------------------------------------------------------------------------------------
class レンタルシステム{ショップ、会員、倉庫：貸出()、返却()、入荷()、廃棄()};
class ショップ{商品リスト、料金表};
class 商品{シリアル番号、カタログ番号、入荷日、貸出日：検索()};
class カタログ{カタログ番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日：一括登録()、検索()};
class 料金表{期間、金額：料金算出()、登録()、更新()、削除()};
class 会員{会員番号、住所、氏名、年齢、電話番号、商品リスト：入会()、更新()、脱会()、延滞検索()};
class 倉庫{商品リスト：入庫()、出庫()};
class 貸出履歴{シリアル番号、会員番号、貸出日、返却予定日、返却日、料金、延滞料金：登録()、検索()};
-----------------------------------------------------------------------------------------------
class DVDレンタル extends レンタルシステム;
class 作品 extends カタログ{タイトル、ジャンル、年令制限};
-----------------------------------------------------------------------------------------------
class レンタカー extends レンタルシステム;
class 車種 extends カタログ{メーカー、名称、グレード};
class レンタカー料金表 extends 料金表{保険種類};
class レンタカー会員 extends 会員{免許証番号、ゴールド識別};
class レンタカー貸出履歴 extends 貸出履歴{前払い分};
-----------------------------------------------------------------------------------------------
653 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/08(木) 09:21:21 ]: >>627
インタフェースを考えるだけでは不十分だ。
ちなみにサイコロの例は、627は認識していないかもしれないが、1～6の値を扱うと言う前提がなければ
サイコロにはならない。例えば「イカサマで振る」が増えたとしよう。627の例ではこうだ。
int 振る();
int イカサマで振る();
これはただの関数だ。俺の例ではこうだ。
class サイコロ{
　　int num;
　　int 振る();
　　int イカサマで振る();
};
実際にnumを管理しているのか、乱数発生器なのかはあまり重要ではない。
しかし、状態がなければメソッド間のつながりが見えない。
ここは構造化とOOの重要な違いだから気をつけるように。
654 名前：仕様書無しさん mailto:sage [2008/05/08(木) 09:28:55 ]: >>653
メソッド間のつながりなんか見えない方が使う側にはいいに決まってるだろ？
何を言ってるんだお前。メンバ全部publicにしろとでも?どこがOOよw
655 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/08(木) 09:52:48 ]: >>638
車種毎に変わるなら車種に入れて、特定の車両毎に変わるなら商品を拡張した物に入れる。簡単だろう。

>>642
>・ブラック顧客リストの登録・判定
会員にフラグ追加。
>・深夜２時とかは今日に含めるのか明日なのか（営業日付の概念）
運用対処。
>・客がレンタル品を壊した場合
破棄は導入済み。
>・盗まれた場合の商品の特定と登録抹消処理
棚卸しの処理を追加する必要がある。
>・商品の予約をどうするか
やり方はいろいろあるが、料金表に予約を追加すれば可能。

>>643
連絡先が必要なのだから、会員登録みたいな物は必要だろう。
会員証の代わりに免許証を使って、有効性は目視で確認すれば良い。

>>651
処理で分類するのは構造化。OOはオブジェクト（物）で分類する。
656 名前：仕様書無しさん mailto:sage [2008/05/08(木) 13:31:22 ]: >>652
データと機能が全部分離してたらOOじゃなくなるぞ…
657 名前：656 mailto:sage [2008/05/08(木) 13:34:35 ]: と、思ったらそうでもなかった>>652
でもクラス多過ぎてワケワカメ。
658 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/08(木) 19:35:13 ]: >>654
意味が通じていないようだな。見えると言うのを「アクセス可能（public）」と理解したのかな
「メソッド間のつながりが見えない。」は「メソッド間のつながりが把握出来ない。」と言う意味だぞ。

>>657
いきなり652を見ると抵抗があるかもしれないが、620、621を見れば、経緯が把握出来ると思う。
そんなに難しくはない。
659 名前：仕様書無しさん mailto:sage [2008/05/08(木) 19:59:23 ]: >>658
>627がいってるように、なぜインタフェースが言語仕様にあるのか考えたか？
おじゃばはどうも想像力がないな。お前、LinuxなりJavaVMがどんな状態を保持してるか
考えてAPI呼ぶか？なんでも自分で作ってる気になってんじゃねーよ、アセンブラも読めないくせに。

それはともかく、イカサマで振るメソッドがあったとしても、そこでnumｇ必要な説明がないんだけど。
読めば意図がわかるってやつか？あいかわらずあまえんぼさんだなｗ
660 名前：仕様書無しさん mailto:sage [2008/05/08(木) 20:16:38 ]: ところで、「メソッド間のつながり」って何のことだ？
661 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/08(木) 20:36:44 ]: >>659
Javaにインタフェースと言う言語仕様があるから、インタフェースの構造はOOだと言いたいのかな？
それ以前にインタフェースがある理由を知らないようだな。Javaでは多重継承が出来ないからインタフェースで
解消しているんだよ。知らなかったか？スレッドに2種類の実装方法がある理由は知らないのかな？
APIはOOとは関係ないぞ。CやperlにだってAPIはあるだろう？

理由は書いてあるだろう。
「1～6の値を扱うと言う前提がなければサイコロにはならない」と。
num1to6とかにした方が良かったかな？
662 名前：仕様書無しさん mailto:sage [2008/05/08(木) 20:47:30 ]: >>661
へえｗ、なんで多重継承じゃなくてインタフェースにしたんだろ？
663 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:04:26 ]: >>653
相変わらず無様だな

今時新人でもこう考えるだろ
interface さいころ {
int 振る();
}

class 素人 implements さいころ {
int 振る(){普通に振る実装}
}

class いかさま師 implements さいころ {
int 振る(){いかさまで振る実装}
}
664 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/08(木) 21:07:53 ]: サイコロの例だと分かりにくいようだな。簡単な例を示す。
会員と商品があるとする。
------------------------------------------------------
class 会員{
　　住所; 氏名; 年齢;
　　登録(); 更新(); 削除();
};
class 商品{
　　商品名; 定価;
　　登録(); 更新(); 削除();
};
------------------------------------------------------
627だと次のようになる。
------------------------------------------------------
登録(); 更新(); 削除();
登録(); 更新(); 削除();
------------------------------------------------------
さて、会員が変更になったとする。
どれを変更すればいい？分からないだろう？
665 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:16:21 ]: >>664
会員の何が変更になったかもわからんのに
どれを変更すればいい？とか意味がわからんわ
666 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:17:15 ]: >>664
会員のインスタンス.更新()；
じゃないのか？何がわからないんだ？
667 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:20:10 ]: ああ、結局>635だからおじゃばはそっから出れないんだね。さすが年寄りｗ
668 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:22:39 ]: >>664
せっかく>>627がインタフェースを教えてくれてるのに。
せめて頭を下げて教えを請えよ。見てて痛々しいよ。
抽象化についてさっぱり噛み合ってないぞ。
669 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:27:04 ]: ぜんぜんOOじゃないじゃん。なにが物で分類するよｗ
６面体のサイコロも８面体のサイコロも、いかさま師はちゃんと振るんだぜ。
670 名前：仕様書無しさん mailto:sage [2008/05/08(木) 21:31:52 ]: >>661
「Javaでは多重継承が出来ないからインタフェースで解消しているんだよ。知らなかったか？」
この一言だけでおじゃばのレベルの低さが分かるわ(つД｀)
671 名前：仕様書無しさん mailto:sage [2008/05/08(木) 22:17:09 ]: 抽象化(笑)
おじゃばは結局OOが嫌いなんじゃないのか。
672 名前：仕様書無しさん mailto:sage [2008/05/08(木) 22:47:29 ]: >664
ぶっちゃけた話、お前、アホだろ。
それで誰をどんなふうに説得したいのか、先が何も見えてこない。
優しい俺様だから大サービスで一応教えてあげるけど、
そんな初歩の初歩で止まってるのは、お前だけ、だよ。
673 名前：仕様書無しさん mailto:sage [2008/05/09(金) 00:03:55 ]: >655
>処理で分類
はぁ...
オブジェクトが備えているべき"役割"で分けるのが一般常識
なんだよ"物"で分類ってw
674 名前：仕様書無しさん mailto:sage [2008/05/09(金) 00:38:50 ]: なんだろ、俺が読解力ないんだろうか、>>661 を読むと、まるで

多重継承みたいなことをしないんだったらインターフェースもいらない

って読めてしまうんだが、...まさかなぁ...そんなわけないし、あぁ、
きっと俺が疲れすぎておじゃばの意図をちゃんと掴みきれてないんだな、
うん、きっとそうだ。いかんいかん、もう寝よ
675 名前：仕様書無しさん mailto:sage [2008/05/09(金) 02:32:41 ]: おじゃばは必死に「物」を主張してるが、そのくせインターフェースの意味を分かってない
OO設計としてのインターフェースの意味はコンポーネント間の接続で、
その接続を受ける側が「インターフェース」と呼んでるだけのこと
多重継承があろうがなかろうが、そんなものは言語仕様でしかなく、インターフェースは変わらない

OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できることなんだよ
多重継承が、とか言いだすのはそもそもコンポーネント間の接続が理解できてない証拠で、
「Javaで作ってるからOO分かってます」、と言ってるようなもんだ
JavaだろうがC++だろうが、さらに言えばCでもbasicでもインターフェースは変わらない
実装方法が違うだけのこと
JavaやC++はその点で実装しやすくなってるだけ

サイコロとか車とかに脱線しまくる前に基本を身に付けろ
676 名前：仕様書無しさん mailto:sage [2008/05/09(金) 03:28:09 ]: >>675
>多重継承が、とか言いだすのはそもそもコンポーネント間の接続が理解できてない証拠で、
>「Javaで作ってるからOO分かってます」、と言ってるようなもんだ
残念なことにおじゃばは大まじめにそう言ってるんだなこれが。
>113,>145
OOは言語だけの話でいいそうだ。うへぇ。
677 名前：仕様書無しさん mailto:sage [2008/05/09(金) 07:44:43 ]: おじゃばがデザパタを理解できない理由がわかった。
678 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 09:54:31 ]: >>665,666
会員情報に対する登録／更新を探さないと分からないだろう？
会員クラスになっていれば、強い制約ではないが、会員の情報に対する処理というのは分かるが、
クラスになっていなければ、結局全てのメソッドの中を見て、会員情報を使っているか見る事になる。
たとえコメントで会員情報登録と書いてあったとしても、何の制約もない。

>>668
一般的なインタフェースを言っているのか、Javaのインタフェースを言っているのかと言うと、
>Javaでもインターフェースは不要で抽象クラスのみがあればよいということになってしまう。
>Javaでどうしてインターフェースという言語機能が提供されているのか少しは考えてみればいい。
と言っているのだから、Javaのインタフェースを言っているのだろう？
たから抽象クラスだけではダメな理由を答えたのだが。他にどういう理由がある？

>>669
物と言うのは物体と言う意味ではないぞ。実体を持たない「ルール」みたいな物も含む。
つまり「オブジェクト」の事だ。日本語では良い訳がないから「物」になってしまう。
679 名前：仕様書無しさん mailto:sage [2008/05/09(金) 10:05:51 ]: >>678
日本語で言え。
680 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 10:43:00 ]: >>675
>OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できることなんだよ
これだとすると、必ず聞かれる疑問点がある。
「それだとCでモジュール（外部関数）化するのとどう違うの？」
これにはどう答えるのかな？
681 名前：仕様書無しさん mailto:sage [2008/05/09(金) 10:55:30 ]: >>680
その答えが今みんなが教えてくれているインタフェースについての説明にも含まれているんだよ。

>>661 のような誤ったインタフェースの理解をしているおじゃばにはわからんだろうが・・・。
682 名前：仕様書無しさん mailto:sage [2008/05/09(金) 11:12:13 ]: マ業全体がしょぼいから
683 名前：仕様書無しさん mailto:sage [2008/05/09(金) 11:32:29 ]: >>680
おちついて、ゆっくり文章を読み直してみては。
あせらず、最初から順番に理解していけばいい。
684 名前：仕様書無しさん mailto:sage [2008/05/09(金) 11:37:50 ]: >678
正直な話、制約どうのこうの以前に、お前の頭をどうにかしたほうがいいぞ。

＞強い制約ではない
お前の話じゃあ、結局破綻しとるがな。
超シンプルなシステムならともかく、
世の中にはお前のような頭の固いアホが書いたスパゲッティプログラムもあってだな、
結局全部検索せにゃならんことには変わりないっつーオチ。

お前に設計させると、確実に破綻するだろうな。。
基礎の基礎程度の知識で、理想論と妄想だけで構築されば、当然。。
685 名前：仕様書無しさん mailto:sage [2008/05/09(金) 11:44:18 ]: すごいアホが居るな。
どうやったらここまでアホになれるのか不思議でたまらん。
686 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 12:43:05 ]: つーかまたOOの利点から始めるのか？
俺の意見では「OOの利点はオブジェクト単位で変更が容易」だが、これはこれでいいのかな？

675の意見では「OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できること」らしいが、
これにはみんな賛成なのか？
ちなみに、「それだとCでモジュール（外部関数）化するのとどう違うの？」の回答はまだないが。
687 名前：仕様書無しさん mailto:sage [2008/05/09(金) 12:54:15 ]: >>686
もうよせ。話が全然噛み合ってねぇ。
688 名前：仕様書無しさん mailto:sage [2008/05/09(金) 13:08:27 ]: >>686
＞これはこれでいいのかな？
よくないから、話題がループしていることにいい加減気づけ。

＞（前略）回答はまだないが。
>>681,683 が回答だ。このスレを理解しながら読みさえすれば答はすでに自明。
689 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 17:36:49 ]: >>688
675はOOはCのモジュール化と変わらないと言っているように読み取れる。それでいいと言う事かな？
そうなると、391の処理で分割するクラス構成もOOだと言う事になるが、それでいいのかな？
690 名前：仕様書無しさん mailto:sage [2008/05/09(金) 17:55:56 ]: 一から出直しておいで…。

まずは本屋で本買って読むのがオススメ。
非OOPLの勉強もしっかりしておくんだよ。
それで何が不便かをまず学ぶんだ。
次に、OOPを少しずつ学んでいくといい。

まずは、自習しなさい。
691 名前：仕様書無しさん mailto:sage [2008/05/09(金) 18:01:59 ]: on_

おじゃばにまず必要なのは OO(P) の知識じゃないな。読解力だ・・・。
692 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 19:12:11 ]: >>690
690はまず俺のレンタルシステム例を見て勉強するのをお勧めする。
「OOの利点は、OO設計時のインターフェースがOOPでそのまま実装できること」なんて言っていると笑われるぞ。
693 名前：仕様書無しさん mailto:sage [2008/05/09(金) 19:20:46 ]: インターフェースってコンセプトを理解できるかどうかってだけの話なのに
なんでいきなりCのモジュールとか出してくるの？
694 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 19:45:55 ]: >>693
設計時にインタフェースしか考慮しないなら、Cのモジュールと同じだろうと言う事だよ。

「OOの利点はオブジェクト単位での変更が容易と言う事だ」と言う前提がないと、他の二人の設計を
評価出来ない。「OOの利点は設計時のインタフェースがそのまま実装可能？」設計ミスでもない限り、
普通はそのまま実装可能だろう？わけわからん。

と言う訳で、残の二人の設計が本当に「変更が容易」か検証してみよう。
作者に検証してもらうのがいいのだが、もういないのかな？
695 名前：仕様書無しさん mailto:sage [2008/05/09(金) 19:56:40 ]: >>694
675もう一回読み直せ
696 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 20:09:54 ]: まず、「新作／旧作」や「電話番号」がクラスになっているやつ。
あれ、基本機能すらクリアしていないから、出来れば基本機能ぐらいはクリアするようにして欲しい。
今のままだと、デスマ突入で、リリース可能時期未定って感じだ。

次に処理でクラスが分かれているやつ。
------------------------------------------
class DVD登録画面{実行()} class DVD登録{} class DVD削除画面{実行()} class DVD削除{}
class DVD貸出画面{実行()} class DVD貸出{} class DVD返却画面{実行()} class DVD返却{}
class DVD{DVD情報：貸出()、返却()}
class 会員登録画面{実行()} class 会員登録{} class 会員削除画面{実行()} class 会員削除{}
class 会員{会員情報：取得()} class 一覧{取得()}
------------------------------------------
はっきり言って、これだけでは分からない。管理しているデータが分からない。
多分、作者の頭の中にはテーブル設計があるのだろう。以前に俺が設計したテーブルを当てはめてみる。
----------------------------------------------------------------------------------------
会員（会員番号、住所、氏名、生年月日、入会日、退会日）
商品（シリアル番号、DVD番号、入荷日、廃棄日）
DVD情報（DVD番号、タイトル、ジャンル、年令制限、発売日、レンタル開始日）
料金表（料金番号、期間、金額）
料金管理（料金番号、優先順位、開始レンタル開始日、終了レンタル開始日、DVD番号、ジャンル）
貸出管理（貸出番号、シリアル番号、会員番号、貸出日、返却予定日、料金、延滞料金）
----------------------------------------------------------------------------------------
697 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/09(金) 20:31:39 ]: >>695
お前こそ話の流れを読め。
インタフェース設計する時に、内部構造を把握する必要があるかと言う話ではなく、
クラス設計をする時に、インターフェースのみの考慮で十分かという話だぞ。
698 名前：仕様書無しさん mailto:sage [2008/05/09(金) 20:36:50 ]: >>694 >>696
お前はアホか。
分析段階のしかも分析途中の図持ち出して、勝手に設計扱いすんなよ。
699 名前：仕様書無しさん mailto:sage [2008/05/09(金) 21:27:46 ]: おじゃぱの書き込みを飛ばして読むと勉強になるな
700 名前：仕様書無しさん mailto:sage [2008/05/09(金) 22:09:19 ]: 誰かちゃんと言えよ。つか俺が言う。
おじゃば、あまったれるのもいいかげんにしろ。
誰がお前にそこらの本に嫌ってほど書いてある物を手取り足取り教えなきゃならん。
話が通じるようになってから出直してこいよ。
701 名前：仕様書無しさん mailto:sage [2008/05/10(土) 01:32:12 ]: つぅか糞おじゃば　
つぅかこのスレもいらないんじゃね？
実際糞おじゃばがいなかったGWにはいらなかったし。
つぅか糞おじゃば　いちいちこのスレあげんじゃねぇよ。糞おじゃば!!!!vok
702 名前：仕様書無しさん mailto:sage [2008/05/10(土) 01:40:33 ]: それでいいと言う事かな？
703 名前：仕様書無しさん mailto:sage [2008/05/10(土) 02:15:52 ]: OOの利点はポリモーフだろが
そのためのインタフェースじゃないのか？
704 名前：仕様書無しさん mailto:sage [2008/05/10(土) 02:18:16 ]: >>697
NO

…てか、誰がそんな話し始めたんだ？
705 名前：仕様書無しさん mailto:sage [2008/05/10(土) 02:27:47 ]: >>696
インターフェイスとクラス設計を比べないこと…

あ、
もしかして'うっかりさん'かな？
706 名前：仕様書無しさん mailto:sage [2008/05/10(土) 02:40:21 ]: 素人考えで悪いんだけど、インターフェースとか抽象クラスって字面どおりに解釈すれば良いんじゃないの？
例えばUSBにはマウスだろうとディスクドライブだろうとプリンタだろうと、インターフェース規格があってれば接続できる。
抽象クラスの方は、例えば「HDD」、「FDD」に対して「ディスクドライブ」という、抽象的な表現でその本質／共通の性質に着目する。みたいな。
多重継承とインターフェースは別に関係無いっぽい。JAVAでは単純に多重継承禁止。

C++のclassでvirtualを使って作る抽象クラスは上のインターフェースと抽象クラスの二つ目的で使用できるけど、
文法レベルで目的を明確化出きるようにしたのがJAVAなんじゃないかな？
707 名前：仕様書無しさん mailto:sage [2008/05/10(土) 08:41:35 ]: >>627
>必ずしも内部で情報を保持する必要はない。インターフェースを満たしていさえすればいい。
バカすぎるｗ、OOをまったく理解出来てないなorz
内部情報を持たないオブジェクトを作るなんて、それはOOじゃない

>>675
>OO設計としてのインターフェースの意味はコンポーネント間の接続で、
>その接続を受ける側が「インターフェース」と呼んでるだけのこと
こいつもバカか？（コンポーネント間の接続）はっ？　（「インターフェース」と呼んでる『だけ』のこと）「だけ」ってｗｗｗ
708 名前：仕様書無しさん mailto:sage [2008/05/10(土) 08:47:53 ]: ┌─────┐
│基地外警報│
└─────┘
`ヽ(´ー`)ﾉ
　 (　へ)
　く
709 名前：仕様書無しさん mailto:sage [2008/05/10(土) 09:14:33 ]: 誰か、もう少しまともなIFの説明したら？
710 名前：仕様書無しさん mailto:sage [2008/05/10(土) 10:11:47 ]: 理解する気が無い相手に説明するのは無駄じゃん
711 名前：仕様書無しさん mailto:sage [2008/05/10(土) 10:17:29 ]: いや、理解する・しないは別に、ちゃんとIFを説明しないと
俺も６２７や６７５は違うと思う
712 名前：仕様書無しさん mailto:sage [2008/05/10(土) 10:49:21 ]: じゃ、お前がしろ。おじゃばにわかるようにな。
と言われると想像できないんだろうか？
713 名前：仕様書無しさん mailto:sage [2008/05/10(土) 11:19:08 ]: ┌─────┐
│基地外警報│
└─────┘
`ヽ(´ー`)ﾉ
　 (　へ)
　く
714 名前：仕様書無しさん mailto:sage [2008/05/10(土) 11:58:20 ]: >711
読解力なさすぎ
715 名前：仕様書無しさん mailto:sage [2008/05/10(土) 12:01:07 ]: 土曜はおじゃばの自演曜日だからな
716 名前：>>706 mailto:sage [2008/05/10(土) 12:08:24 ]: よくあるOOの説明としては、
「オブジェクトの振る舞いはオブジェクト自身が知っている」またはもっと強く、
「オブジェクトの振る舞いはオブジェクト自身しか分からない」。
これを実現するために（情報隠蔽を含む）カプセル化がある。

一方インターフェースとは、メッセージパッシングのメッセージの、形式／書式を表現していると解釈した。
メッセージの内容はオブジェクト間の関係というか、投げる側の目的、受ける側の役割で変わってくる。

オブジェクトの「振る舞い」は分からんくても、その「役割／機能」は分かっているから、
目的に合わせて、先に上げたUSB機器のような適切な機器（オブジェクト）をつないでやれば良い。
717 名前：仕様書無しさん mailto:sage [2008/05/10(土) 13:47:47 ]: デザパタのほとんどはインターフェース（若しくは抽象クラス）を前提にしいている。
逆にいうと、中身を定義しないからこそいろいろなケースに適用することができる。
デザパタが考え方や概念を抽象化したものとするなら、抽象化が必ずしも中身ありき
でないことを示す好例だろう。
もともと、抽象化とはなんぞやというところから始まった話だと思うが、どこで>>697
の論旨になったのかわからない。
718 名前：仕様書無しさん mailto:sage [2008/05/10(土) 15:11:24 ]: >>707
＞内部情報を持たないオブジェクトを作るなんて、それはOOじゃない
概念クラスと実装クラスをごっちゃにするな。
719 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:03:17 ]: 最近の携帯電話は、テレビのリモコン代りに使えたりするが、それは、
携帯電話が「チャンネルを送信する」というインターフェースを備えて
いるからだ。逆に言えば、ひげそりだろうが、やかんだろうが、この
インターフェースを備えてさえいれば、テレビのリモコンになりうるわけだ。
何で出来ていようが、実装方法がどうだろうが、関係ない。ボタンを押すタイ
プだろうが、Wiiみたいに振る形式だろうが、音声認識だろうが関係ない。
データはもちろん大事だが、いきなり内部情報がどうだ、扱うデータがどうだ
とデータありきで考えるのは実装レベルでの視点であって、抽象化を意識した
設計者の視点ではない。おじゃばは結局DOAのアプローチから抜けきれていない。
720 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:11:05 ]: >>718
そうか？
>>627
>int 振る() {
>　　return int(random(6) + 1);
>}
>などといった実装で十分だ。繰り返すがインターフェースの条件さえ満たせば、クラス内部で状態を
>保持することは直接的な必須条件ではない。
って実装レベルで書いてるぞ、>>707の言っている事が正しいと俺も思うよ
721 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:18:42 ]: >>716,717,719
また、分けのわからん奴らが、うその説明してるなｗ
722 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:20:22 ]: >>720

int 振る()
が概念

int 振る() {
　　return int(random(6) + 1);
}
が実装

じゃね？　振るという概念に対して実装はいくらでもある。
723 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:32:10 ]: >>722
違うだろ、よく嫁め
>＞内部情報を持たないオブジェクトを作るなんて、それはOOじゃない
>概念クラスと実装クラスをごっちゃにするな。
と書いているから、、内部情報を待たせないオブジェクトの話だろ
本人じゃないから分からんが、メソッドの概念・実装の話じゃないと思うぞ
724 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:39:34 ]: 俺は本人だが、>722が正しい。
725 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:46:31 ]: >＞内部情報を持たないオブジェクトを作るなんて、それはOOじゃない
>概念クラスと実装クラスをごっちゃにするな。
普通これ読んで、そう思うかｗｗｗ

>>718,722,724 自作自演乙
726 名前：仕様書無しさん mailto:sage [2008/05/10(土) 16:53:04 ]: >>720,721,>>723,725 こいつおじゃばより頭悪そうだな。
727 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:00:21 ]: >>725の方がまともだと思うけどね。
インタフェースをメソッドレベルで説明するなんてアホすぎる。
あとデザパタ持ち出してるやつもアホ。
728 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:07:03 ]: 俺の場合は、結論だけ述べて根拠を示さない奴をアホかどうかの判定基準にしているが、
そういう意味では、>>727はアホの中のアホだな。
729 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:13:48 ]: 俺は理解出来ないで書く奴の方が、そうとうバカだと思うぞｗｗｗ、
730 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:18:31 ]: ということは、>>729も、そうとうバカだなｗｗｗ
731 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:28:27 ]: 流れを読まずに発言するが、
>>706さんの感覚が俺には一番近い。

JavaのinterfaceはOOPLとしての心意気で、
同様に、C++のvirtualはOOPへの及び腰。

まず先にこういう話があっての、
Javaのinterfaceは型の多重継承を可能にした、
の話をすればいいと思う。な、聡明なおまいら。
732 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:31:16 ]: 修正しとく。

な、C++では純粋仮想関数だけのクラスを先に作って嬉しがる聡明なおまいら。
733 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:34:51 ]: >>730
そんなにカリカリするな、自分が書いたのを批判されて怒るのは分かるが
おじゃばはもっと大人の対応をするぞ。　
それに、おじゃばと一緒で浅い知識で書いたら批判ぐらい覚悟しとかないと
734 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:35:43 ]: すまんが、
>C++のvirtualはOOPへの及び腰
の意味がわからん。
735 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:38:16 ]: >>733
確かにその点だけは、おじゃばは大人かもｗ
736 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:42:37 ]: >>733
アホか、そんなセリフは、お前の深い知識の文章とやらを書いてからにしろよ。
あ、俺ちょっと出かけるが、あとで出来栄えを見てやるから、今日中にお前の
深い知識を書いとけよ。
737 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:43:02 ]: >>733
>おじゃばはもっと大人の対応をするぞ。
たしかにｗわからなかったらオウム返しするし、切れるのは嘘つきくらい言われてからだしな。
でも言ってることの中身はそれとは全然関係ないけど。
738 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:45:41 ]: もうそろそろ自演はやめないか、みっともない。もともと土日は過疎スレなんだし。
739 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:50:31 ]: >>734
virtualをつけないと派生クラスでオーバーライドできない。
というのをOOPLとしては消極的だ、と俺は思っちゃうから。

一方、Javaならオーバーライドできるのが基本で、
それをさせたくないときにfinal修飾子によって、
メソッドをサブクラスでオーバーライドできなくする。

何がデフォか、っていうのは姿勢の違いに見えますよね。
740 名前：仕様書無しさん mailto:sage [2008/05/10(土) 17:51:40 ]: >733
・・・え？
あれで大人な対応なのか？
では、我々は何なのだ？
741 名前：仕様書無しさん mailto:sage [2008/05/10(土) 18:09:51 ]: >>739
単にC++が、仮想関数テーブルをデフォで参照するオーバーヘッドを嫌がっただけでは？
742 名前：仕様書無しさん mailto:sage [2008/05/10(土) 18:18:10 ]: 実行時のコストと、言語としてのOOPL度（？）がぶつかったとき、
どちらをどう選んでいくかが見ものですよね。
virtualの例は、俺にとってはOOPL度を下げた、と見えただけです。
オーバーライドはOOPの前提になってる、って思ってるからです。
743 名前：仕様書無しさん mailto:sage [2008/05/10(土) 18:18:57 ]: 前提、っていうと言いすぎですが。まあｗ
744 名前：仕様書無しさん mailto:sage [2008/05/10(土) 18:36:44 ]: 俺に言わせれば、ヘッダファイルのvirtualの有無をみて、
クラスの設計意図を把握する手がかりになるというのはあるがな。
745 名前：仕様書無しさん mailto:sage [2008/05/10(土) 18:59:24 ]: ちょっと試みに書いてみるよ。

昔、インタフェース(interface)に「界面」という訳語を当てた人がいたが、
これはなかなかいい訳語だと思う。
インタフェースとはまさに外界に対して提示する側面(face)であり、
同時(inter)に外界から認識するための面でもあるからね。
これに名前をつけたのがインタフェースだといえる。

設計者の立場からすると、インタフェースとはオブジェクトに
提供させる役割や義務の名前をつけ宣言したものと考えることができる。
俺も>>706のUSBインタフェースの例は、分かりやすいと思う。

一般にオブジェクトは複数のインタフェースを実装することが可能であるので、
設計の自由度を向上させることができる。
USBインタフェースとDiskインタフェースを持つ、USBDisk抽象クラスを
定義するなどという使い方ができるわけだね。
言語によって異なるが、JavaやObjCのように文法上インタフェースを
抽象クラスと区別しているものは、設計を実装に移しやすいよ。
また、Javaのようにインタフェースを派生して新たなインタフェースを定義できるものは、
さらに応用がきくだろう。
このように、インタフェースと実装を分離すると、設計がやりやすくなる。

（長くてはねられたので続く。）
746 名前：仕様書無しさん mailto:sage [2008/05/10(土) 19:00:03 ]: また、オブジェクトを利用する側から見ても、インタフェースで要求することで、
オブジェクトが役割を実装していることが保証できるとともに、
その局面に必要な役割を明示でき、設計が分かりやすくなる。
さらに、インタフェースでの要求は、実装を交換できるという可能性を持つので、
プラグインのような交換可能な機能やデバッグ用のモックのようなものを必要とする
場合に活用でき、システムの拡張性は高まるだろう。

このように結構便利なインタフェースだが、何でもかんでもインタフェースで
設計すれば良いわけではない。まずは、システム境界の認識と外界に対する
役割を分析し、各レベルで交換可能なものと不可能なものを見極めることが大事だと思う。

なんか、長くなっちまったな、、すまん。
747 名前：仕様書無しさん mailto:sage [2008/05/10(土) 19:03:38 ]: >>745
このスレでobjcの名を見るとは思わなかったｗ
この調子でsmalltalk界隈の人が来てくれないかな。
OOとはなんぞや、OOP、そしてOOPLとは、と語れる人。
748 名前：仕様書無しさん mailto:sage [2008/05/10(土) 19:42:28 ]: >>736
>アホか、そんなセリフは、お前の深い知識の文章とやらを書いてからにしろよ。
おじゃばと同じような事を、言うんだなｗ
まっ落ち着け、なんで皆が>>627がおかしいと言っているのか
もう一度考えてみろ
749 名前：仕様書無しさん mailto:sage [2008/05/10(土) 19:56:35 ]: >>748
言ってねぇよおじゃば。お前だけだ。わざわざｗつけてまでご苦労。
750 名前：仕様書無しさん mailto:sage [2008/05/10(土) 19:57:53 ]: おじゃばが増殖してる・・・
751 名前：仕様書無しさん mailto:sage [2008/05/10(土) 20:04:14 ]: >>750
バカの代名詞だからしかたないだろ。マ板でいま最低の罵倒語だな。おじゃばは。
752 名前：仕様書無しさん mailto:sage [2008/05/10(土) 20:10:46 ]: おまえら。インタフェースとはプロトコルのことだ。
753 名前：仕様書無しさん mailto:sage [2008/05/10(土) 20:33:42 ]: >>752
ObjCではプロトコル(@protocol)と呼ばれてたね。
Javaはインタフェースの文法を策定する時、ObjCのプロトコルを
参考にしたとされている。

ObjCは動的な型付けを行う言語なので、もともとはプロトコルは
文法にはなかった。プロトコルがObjCに導入されたわけは、
NeXTが独自の分散オブジェクト技術であるPDOを提供したためだった。
分散環境でやり取りされるオブジェクトにプロトコルという制約を課すことで、
動作を保証したかったためだった。
これ、豆知識な。
754 名前：仕様書無しさん mailto:sage [2008/05/10(土) 20:57:45 ]: あまり役にたちそうもない豆知識だな
755 名前：仕様書無しさん mailto:sage [2008/05/10(土) 20:59:11 ]: つぎは当然カテゴリの話になるわけだな。
756 名前：仕様書無しさん mailto:sage [2008/05/10(土) 21:33:44 ]: まあカテゴリの話読みたいやつはいないだろうけど、一応書いとくな。

カテゴリはプロトコル違って最初から文法にあった。
少なくともNeXTstep1.0のころからあった。
これはクラスの拡張技術みたいなもので、ちょっと面白い。
例えば、既存のクラスのカテゴリを定義して、それを実装すると、
クラスの継承なしにクラスの機能を拡張できる。

また、ObjCは動的束縛を行う言語なので、メソッドが呼ばれないなら
そのメソッドの宣言だけして、実装しなくてもエラーにならないんだよ。
NeXTのライブラリは、デリゲート機能をこれを使って提供していた。

思うに、ObjCは、C + Smalltalk（特に言語仕様はSmalltalkから影響を受けてる）
だから、Smalltalkのような開発者によるクラスの拡張を、
カテゴリによって実現したかったんだと思う。

脱線し過ぎたから,ROMにもどる。
757 名前：仕様書無しさん mailto:sage [2008/05/10(土) 23:41:37 ]: どんな深い知識を披露してくれてるかと思えば >>748 かよ。
予想していたとはいえ、お前にはがっかりだよ。
758 名前：仕様書無しさん mailto:sage [2008/05/11(日) 01:39:34 ]: >>748
> まっ落ち着け、なんで皆が>>627がおかしいと言っているのか
> もう一度考えてみろ

皆？お前とおじゃばだけやろ
同一人物なのはバレバレなのはこのスレでは禁句やったな
759 名前：仕様書無しさん mailto:sage [2008/05/11(日) 07:57:42 ]: サイコロをオブジェクトにした時点でだめだな。
760 名前：仕様書無しさん mailto:sage [2008/05/11(日) 09:19:17 ]: >>758
おれもおかしいと思うけど、何か？
761 名前：仕様書無しさん mailto:sage [2008/05/11(日) 10:06:18 ]: 正直Javaのインターフェースってあまり知らなくて調べてみたんだが、

・多重継承は複数のクラスのゴタマゼ。
・インターフェースは抽象化された入り口・出口の共通化。

って感じ？

インターフェースは共通化の為に多重継承を可能にしているのであって
クラスの多重継承の様に多元的な機能の一元化じゃなくて、色んなクラスの多様性の為
の単純化でしかないと思うんだけど。

ソース的には前者が複雑で後者が単純だけど。

軽く一時間調べてみただけなので間違ってたらごめんちゃい。
762 名前：仕様書無しさん mailto:sage [2008/05/11(日) 10:20:13 ]: インタフェースはフォースのことだ。
763 名前：仕様書無しさん mailto:sage [2008/05/11(日) 12:32:11 ]: これ笑えるw
ttp://blogs.wankuma.com/nagise/archive/2008/05/10/137150.aspx

何にも理解していない奴の典型だな
764 名前：仕様書無しさん mailto:sage [2008/05/11(日) 13:04:57 ]: >>763
たしかに。そんなこと言い出したらJavaよりもっとその傾向が強い言語があるじゃないか。OO関係なし。
つ[COBOL]
765 名前：仕様書無しさん mailto:sage [2008/05/11(日) 13:36:16 ]: 静的オブジェクト指向の理想は、コンパイルが通った時点でバグがなくなっていることです
*11。その強い型付けを最大限に生かし、間違えることができない型設計をすることが、
後の生産性を高めます。だから、クラスの設計が終わってしまえば、そのクラスについて忘れる
ことが許される。強い型システムがクラスの使い方を導出してくれます。導かれるままに使うだけでいい。
私がJavaで大量にロジックを書くことができる理由は、効率よく忘れることが許されているからに他なりません。
俯瞰視点で設計するときは細部を見ることはないし、細部を作るときには全体を見ることはない。

偉い人本当なのかｗ？教えてくれよ？
なんかおじゃば様より頭悪そうな書き込みにしか見えんｗ
766 名前：仕様書無しさん mailto:sage [2008/05/11(日) 14:41:58 ]: みんな自演に見える
767 名前：仕様書無しさん mailto:sage [2008/05/11(日) 14:45:33 ]: そうか？
>>763って、単にOOPLの範囲で動的型付けと静的型付けを比べてるだけだろ？
OOについて何か語りたい文章なわけじゃないと思うんだけど。
768 名前：仕様書無しさん mailto:sage [2008/05/11(日) 16:29:30 ]: つ[VB6]
769 名前：仕様書無しさん mailto:sage [2008/05/11(日) 17:07:45 ]: ゴールデンウィーク中の過疎が嘘のような盛況ぶり、どうしたんだ？
と思ったらほとんど自演かよ...
770 名前：仕様書無しさん mailto:sage [2008/05/11(日) 19:44:10 ]: え、頭がいい人が、おじゃばみたいな分析と設計の区別もつかないようなただのコーダを
こき使って、コーディングやテストだけさせてこれがオブジェクト指向だと騙すのには
Javaが最適だという話じゃないのか。たしかにおじゃばはいい歳こいてコーディング先だし
ちょうどいいわな、なんだか知らんがすげー時代遅れだし。奴隷で使うにはいいんじゃね？
771 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/12(月) 10:04:16 ]: >>770
しかし、レンタルシステムの例で、設計が完了したのは俺だけのようだぞ。
698が処理型クラスの設計を完了させるなら、早く完了させてくれ。
どちらにせよ、770の言う頭のいい人は、OOの利点を示す以前に、初期設計自体完了させられないようだ。
それで俺が設計出来ないとか言っても、全然説得力がないのではないか？

簡単にインタフェースとOOの関係を説明しておこう。
C言語の外部モジュールで説明しよう。外部モジュールと言うのは、例えばデータベース関係の処理を
外部モジュール化して入出力を合わせておくと、データベースの製品が変わっても変更が少ないというやつだ。
これはOOが広まる以前から存在していて、CにもPerlにもCOBOLにも存在する。
これは便利だが問題があった。それは外部モジュールとして設計した場所しか交換可能ではないと言う事だ。
つまり、外部モジュール化したが、データベースは交換しなかったとか、予想も指定なかった所を
交換する必要が出てきたなどだ。そのため、設計者は仕様を先読みして、変更が入りそうな所を
外部モジュール化する必要があった。しかしそれは設計者の経験に依存し、また新規の設計で
早い間隔で仕様変更が入るシステムの設計などには向いていなかった。
772 名前：仕様書無しさん mailto:sage [2008/05/12(月) 10:28:49 ]: >>771
日本語で書け。
773 名前：仕様書無しさん mailto:sage [2008/05/12(月) 11:36:24 ]: >>771
>>770は>>763に関するレスだろー
774 名前：仕様書無しさん mailto:sage [2008/05/12(月) 12:08:55 ]: 自意識過剰だな、ほんとに。
775 名前：仕様書無しさん mailto:sage [2008/05/12(月) 12:25:00 ]: > 設計が完了した

？？？？

ココもしかして笑うところですかね？
776 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/12(月) 14:11:51 ]: そこで注目されたのがオブジェクト指向だ。
元々シミュレーション分野で生まれたオブジェクト指向は変更に強く、オブジェクト単位での取り替えを
可能にする。つまりC++では全てのクラス単位で取り替えが可能になるということだ。
ただし、今までのインタフェースのみに着目していた方法では、これは実現出来ない。
簡単に言うとメソッド（関数）をグループ化する必要があるからだ。（実際にはそれだけではないが）
そのため、クラスで何の情報を扱うか把握する必要がある。だからクラス設計ではインタフェースのみの
考慮では不十分で、何の情報（状態）を扱うのか把握する必要がある。

これは基本だ。
「設計段階で修正を予想する必要がある」とか、「クラスはインタフェースのみ考慮すればいい」
とか言うのは、構造化時代の考えから抜けられない人だ。俺に言う事ではない。
また、「インタフェースがCのモジュールと何が違うのか」に答えられないのも当然だ。
それだけでは同じなのだから。
つまり、基本を勉強し直せと言うのは、俺にではなく、これらの人に言うのが望ましい。

>>775
なにがおかしい？
設計例や問題点すら出せずに、無意味な書き込みしか出来ない775の方が、すごく恥ずかしいと思うが。
俺的には間違った設計をして突っ込まれるより、遥かに恥ずかしいと思う。
777 名前：仕様書無しさん mailto:sage [2008/05/12(月) 15:17:21 ]: >>776
ん？なんか説明したか？
もっかい意図が伝わるように書け。
778 名前：仕様書無しさん mailto:sage [2008/05/12(月) 15:25:37 ]: おじゃばはあれだけ大量に書いてあったなかで
ちゃんと読めたのは>770だけなようだな。
気に障ったのはホントだからだろ。いやいやわかってるって。冗談だよ、
ホントじゃないホントじゃない、違うってば。うぷぷっ
779 名前：仕様書無しさん mailto:sage [2008/05/12(月) 19:19:09 ]: >>771
設計が完了したのか。
だったら、設計書をupしてほしいな。
それを見れば、その設計書がOOかどうかなんて、
すぐに分かると思うぞ。
みんなでレビューすればいい。
780 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/12(月) 19:35:32 ]: >>777
設計したインタフェースの所のみが交換可能なのが、Cのモジュールで、構造化。
全てのオブジェクト単位で交換可能なのが、Java/C++のクラスで、オブジェクト指向。

こんな基礎も知らずに、デザパタがどうとか、OO設計がどうとか言う自体が滑稽だ。
って事。

>>778
キモイ。

>>779
652を見て分からないのか？
いきなり652が分からなければ、364-366、620-621、652の順で見れば分かると思うが。
ちなみに何人かは理解しているようだが。
781 名前：仕様書無しさん mailto:sage [2008/05/12(月) 19:46:22 ]: ふーん。つまり言語の特性によっからないと変更に強いシステムはできない、という主張か？＞おじゃば。
あのな、お前の物言いはお題目だけで具体的な根拠がないから誰もまともに相手してないんだぞ。
DOAで設計してJavaでOOPすればここがいい、ってわかりやすく説明すればいいのに
全部のレンタルはツタヤから、なんてやってるからしかたねーだろ？
782 名前：仕様書無しさん mailto:sage [2008/05/12(月) 19:51:02 ]: せいぜい設計ごっこじゃん
マジメにやってから威張れよｗ
783 名前：仕様書無しさん mailto:sage [2008/05/12(月) 20:36:33 ]: ま、おじゃばに言えるのは
おっさん無理しないでコーディングがんばれや、Javaやってりゃオブジェクト指向でいーんだろ、
はいはいついってってるよねーえらいねーって感じ？
784 名前：仕様書無しさん mailto:sage [2008/05/12(月) 20:41:21 ]: なるほどツタヤで借りたものを客に又貸しする商売なのですね、わかります
785 名前：仕様書無しさん mailto:sage [2008/05/12(月) 20:45:55 ]: >>780
>ちなみに何人かは理解しているようだが
そっちはレス番はどうした。自演だからかｗ
786 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/12(月) 20:49:18 ]: >>781
>ふーん。つまり言語の特性によっからないと変更に強いシステムはできない、という主張か？＞おじゃば。
そんな事言ってないだろう。OOがオブジェクト毎の交換が容易だと言っているだけだ。
実例として、DVDレンタルからレンタカーへの修正で、その効果を見せただろう。何見てるんだよ、お前は。

>>782-784
その設計ゴッコすら出来ない782は何だ？
つーか、俺の設計の意図どころか、基本構造すら読み取れないんだな。
マジメに勉強が必要なのはオマエラだよ。簡単な設計すら出来ないのに学者気取りかよ。恥ずかしい。
364-366、620-621、652を読んで勉強しろ。
787 名前：仕様書無しさん mailto:sage [2008/05/12(月) 20:59:28 ]: >>786
>実例として、DVDレンタルからレンタカーへの修正で、その効果を見せただろう。何見てるんだよ、お前は。
は？だれも納得してない上に、お前自分でレンタルシステムに抽象化(笑)してるやんか。
そのうえそれOOじゃねえだろ。じゃDOA奈良どうなるんだ？
788 名前：仕様書無しさん mailto:sage [2008/05/12(月) 21:08:03 ]: 一般？業務の分析や設計にはOOは要らない、プログラミングだけOOでも有効と言ってみたり、
自分の設計はコーディングレベルじゃなくOOで有効だと言ってみたり
いったいどっちなんだよ、おじゃば。
789 名前：仕様書無しさん mailto:sage [2008/05/12(月) 21:15:20 ]: 設計書って言いながら提出するのが652とか底辺コーダにも程があるだろ
790 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/12(月) 21:23:10 ]: >>787
程度が知れたな。
DOAでのテーブル設計は、160で実施済みだ。ある程度の設計者なら、あれにテーブル毎の登録更新削除処理
を追加すれば完了だということが分かる。見たいのか？やってやってもいいぞ。

>>788
だから最初に、実務だとDVDとレンタカーは普通は別に作るから有効ではないと言っただろう。
あくまでもOOの原理を説明するためにやったんだよ。
ただOODはシミュレーションやゲームの分野では有効だし、OODと同じ性質を持つOOPは多くのシステムで
プログラミングレベルで有効だと言っている。
791 名前：仕様書無しさん mailto:sage [2008/05/12(月) 21:36:10 ]: >>790
>OODと同じ性質を持つOOPは多くのシステムでプログラミングレベルで有効だと
いや、だからそこが全然示せてないから。
792 名前：仕様書無しさん mailto:sage [2008/05/12(月) 21:41:01 ]: >>790
それじゃ>>770の言うとおりだな、確かに。
793 名前：仕様書無しさん mailto:sage [2008/05/12(月) 22:38:32 ]: >>771
なんで外部モジュール以外は交換できないの？
794 名前：仕様書無しさん mailto:sage [2008/05/12(月) 23:04:29 ]: >>757
説明してやるよ、バカには難しかったみたいだからな

>>627
>などといった実装で十分だ。繰り返すがインターフェースの条件さえ満たせば、クラス内部で状態を
>保持することは直接的な必須条件ではない。抽象化において状態の保持が必須なら、Javaでもインター
データが無いインスタンスは生成しない。オブジェクトはデータ＋操作でオブジェクトだ
これは基本中の基本だぞ、こんなのも分からん奴がいるとは、情けないぞ
設計のやり方も疑問だが>>627のケースを実現したいならクラスメソッドを使って実装する
インスタンスは生成しない、本当にこんな初歩も分からんのか

あと
>>717
>デザパタのほとんどはインターフェース（若しくは抽象クラス）を前提にしいている。
>逆にいうと、中身を定義しないからこそいろいろなケースに適用することができる。
>デザパタが考え方や概念を抽象化したものとするなら、抽象化が必ずしも中身ありき
>でないことを示す好例だろう。
お前アホ過ぎる、GOFのデザパタ読んだこと有るのか？GOFのデザパタではIFじゃなく
多重継承を使っているんだぞ、それを「好例」とは、本当に知識が無いな、お前は
795 名前：仕様書無しさん mailto:sage [2008/05/12(月) 23:30:07 ]: おいおい
多重継承とかでたらめ言うなよ
796 名前：仕様書無しさん mailto:sage [2008/05/12(月) 23:30:15 ]: 世界は型を意識しない
多重継承を意識しない方法へどんどん
突き進んでいるのにここのバカ供といったら
GOFだOOだと10年前の戯言と言い続けてるなｗ

だから何時までたってもクラス設計すら危ういし
ましてやフレームワークなんて高尚すぎて作れない
結果コーディング小作人止まり

おじゃばはた並みうぜーしはよ氏ね
797 名前：仕様書無しさん mailto:sage [2008/05/12(月) 23:30:59 ]: >>794
それだと>>627が説明している事を捉えていないぞ
798 名前：仕様書無しさん mailto:sage [2008/05/12(月) 23:39:06 ]: なんで皆、罵倒しながらでないとレスできないんだ？
799 名前：仕様書無しさん mailto:sage [2008/05/12(月) 23:42:15 ]: OOの弊害だな
800 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:05:36 ]: >786
>364-366,620-621,652を読んで勉強しろ。

こんな低レベルなモンから学ぶもんなんか欠片もねぇよ
お前はいつまで初心者レベルで止まってるつもりだ？
801 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:08:07 ]: >>795-799
デザパタを語るならＧＯＦぐらい読めば、アホっぽいよ
802 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:16:09 ]: >>801
GOFなんて97年に読んだけど？
でお前はGOFの最近の論文やら
寄稿した文書は読んだことあるかい？

無いだろ？お前の方がアホだよ
803 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:27:15 ]: データが無いインスタンスは生成しないんだったら、いっそのこと、
言語からインターフェースなんか無くして、データの無いインスタンス
を生成しようとしたらコンパイルエラーにすればいいのにな。
なんでそうしないんだろうな。

>>794は、メソッドだけで構成されるユーティリティクラスを作ったり
しないのか？　データを持たずクラス名だけが違う例外クラスを定義し
たりしないのか？長いif文やcase文を避けるために、データを持た
ない列挙オブジェクトやステートオブジェクトを使ったりしないのか？
executeメソッドだけを備えたコマンドオブジェクトを作ることはない
のか？それとも頭が「データの無いインスタンスはありえない」でこり
固まっていてそういう発想に至らないのか？

あと、「デザインパターン　インターフェース」でググっとけ。
「デザインパターン　多重継承」でもいいぞ。
804 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:47:24 ]: >655
> 処理で分類するのは構造化。OOはオブジェクト（物）で分類する。

>678
> 物と言うのは物体と言う意味ではないぞ。実体を持たない「ルール」みたいな物も含む。
> つまり「オブジェクト」の事だ。日本語では良い訳がないから「物」になってしまう。

あのさ問題はオブジェクト"を"どのように分けるか？だろが
オブジェクトで分けるからです、なんてアホ杉

あと
>OOの利点はポリモーフだろが
>そのためのインタフェース
だ
805 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:48:19 ]: >>795
読んでから言えよアホがｗ

>>796
お前がデザパタとか言い出したんだろ、知識も無いくせに
恥じかくから、もう書かない方がいいんじゃないかｗ

>>798
>>748でやさしく言ってやっただろう、なんで、その時にちゃんと考えない
考えたら、こんな恥をさらす事もなかったのになｗ

>>802
>GOFなんて97年に読んだけど？
97年だと原文で読んだのか凄いな、でも内容が理解出来ないのは
読んだと書かないで、見たと書けｗ

>>803
>>>794は、メソッドだけで構成されるユーティリティクラスを作ったり
>しないのか？　データを持たずクラス名だけが違う例外クラスを定義し
お前、クラスメソッド理解してるか？

あと
>あと、「デザインパターン　インターフェース」でググっとけ。
>「デザインパターン　多重継承」でもいいぞ。
あのな、俺は「好例」って書いているのがおかしいっと言っているんだ
なんでインターフェースの説明にデザパタを根拠にする
おじゃばもインターフェースバカも両方間違ってるのが分からんか？
806 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:52:51 ]: >>803
>あと、「デザインパターン　インターフェース」でググっとけ。
>「デザインパターン　多重継承」でもいいぞ。
ここの人間はググた物しか読まないから、知識がないんじゃない？
書籍読んだ方がいいよ
807 名前：仕様書無しさん mailto:sage [2008/05/13(火) 00:57:35 ]: >>805
>読んだと書かないで、見たと書けｗ
たしかにｗ
808 名前：仕様書無しさん mailto:sage [2008/05/13(火) 01:03:03 ]: >>805 おいおい、継承による拡張を想定してインスタンスメソッドにしとくやり方
を知らんのか？データがなければ全部クラスメソッドにすんのか？想像以上に頭
が硬いな。

だいたい、>>627 をよく読むと、データのないインスタンスを作れるといってると
いうより、インターフェースさえ満たしていれば、中身はブラックボックスでいい
ということを言ってるように思える。　ということで読解力の無いのは>>805 だな。
809 名前：>>798 mailto:sage [2008/05/13(火) 01:21:57 ]: >>805
なんか勘違いしてるみたいだが、おれ>>627じゃないからね。
あと、君ひとりに対して>>798を書いたわけでもないし。

せっかく優しく言ったつもりなら、それを続ければ良いよ。
自分から相手の位置まで落ちることないだろ。
810 名前：>>809 mailto:sage [2008/05/13(火) 02:02:19 ]: あ、ちなみに俺も>>627については、読解力云々は抜きにして>>808の後半の様に解釈したよ。
(こう書くと自演って言われそうだが）

一方で>>803の真ん中らへんにある列挙とかステートオブジェクトっていうのは、
保守性とかを意識したもので、本来独立したオブジェクトでなくても良いもののように思える。
811 名前：仕様書無しさん mailto:sage [2008/05/13(火) 05:26:11 ]: 何かこのスレって見えない敵と戦ってるやつばかりだなぁ
812 名前：仕様書無しさん mailto:sage [2008/05/13(火) 05:48:53 ]: 類は友を呼ぶ。
813 名前：仕様書無しさん mailto:sage [2008/05/13(火) 07:45:23 ]: こいつ（>>805）が自分のカキコ以外は全て>>627と思ってんだろ
814 名前：仕様書無しさん mailto:sage [2008/05/13(火) 08:06:37 ]: メンバ変数は基本的にプライベートにするのは同意だよな。
そしたら、ゲッター、セッターも含めて公開されたメソッドは全て
インターフェースと考えればどうだろう。
そしたらほら、世界はインターフェースを備えたオブジェクトだらけだ。

インターフェースが返すものが、内部変数だろうが、計算結果だろうが
DBから取得したものだろうが、別のオブジェクトだろうが関係ねぇべ。
815 名前：仕様書無しさん mailto:sage [2008/05/13(火) 08:52:53 ]: デザインパターン厨が湧くと必ず荒れる
816 名前：仕様書無しさん mailto:sage [2008/05/13(火) 09:19:54 ]: オブジェクト思考は、プログラマの為のものなので
プログラマ以外が見ると、散らばったパズルに見える。
プログラマは、見るべき所を探せるので可読性が上がるが
それ以外の人間は、ミラーハウスに迷い込んだ感じになる。
817 名前：仕様書無しさん mailto:sage [2008/05/13(火) 09:23:25 ]: ┌─────┐
│基地外警報│
└─────┘
`ヽ(´ー`)ﾉ
　 (　へ)
　く
818 名前：仕様書無しさん mailto:sage [2008/05/13(火) 09:28:20 ]: 行数が短くなるので単価が安く見積もられてしまうとか？
819 名前：仕様書無しさん mailto:sage [2008/05/13(火) 09:39:18 ]: >>808 >>814
やっとマトモな人がいたｗ　安心したｗ

カプセル化して内部の実装を隠して、
クラス外からは気にしなくて言いようにして、
変わりに、インタフェースという単位で扱える。

そのあたりまえの利点を説いているだけの人と、
メンバ変数を保持しないクラス設計（？）を勝手に批判してる人。
>>620「外部とのIFを決めるには、内部で保持すべき情報と、動作を把握しなければならい」
に対して>>627が「必ずしも内部で情報を保持する必要はない」と言っただけのこと。
>>627は「データが無いインスタンス」などの話をしていない。

くいちがっとるがな。

でさらに>>794が「オブジェクトはデータ＋操作でオブジェクトだ」
などとトンチンカンなことを言い出す。さらにこいつは、
「>>627のケースを実現したいならクラスメソッドを使って実装する」
などと言ってる。唐突というかなんと言うか。
完全に>>627からの流れに乗れていない。
820 名前：仕様書無しさん mailto:sage [2008/05/13(火) 09:49:55 ]: 糞コテが恥をかくスレはここですかｗ
821 名前：仕様書無しさん mailto:sage [2008/05/13(火) 09:54:43 ]: >>820
たしかにおじゃばが>819をどう読み違えるかは楽しみだw
822 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/13(火) 11:04:06 ]: >>819
おいおい、627以前の話の流れは無視かよ。
俺のレンタルシステムのクラス設計の話をしていたのだろう？
何で一般的なインタフェース設計の話になるんだ？
823 名前：仕様書無しさん mailto:sage [2008/05/13(火) 11:19:38 ]: あんな糞以下のレンタルシステム設計（笑）の話なんて
いちいち覚えてね～よｗｗｗｗｗ
824 名前：仕様書無しさん mailto:sage [2008/05/13(火) 11:40:20 ]: 自意識過剰。
825 名前：仕様書無しさん mailto:sage [2008/05/13(火) 12:18:29 ]: >>822
流れを無視して話を変えた、と受け取るのが無理解の証。

>>627に対して意気揚々と>>653「インタフェースを考えるだけでは不十分だ。
状態がなければメソッド間のつながりが見えない。」などと答えたことに始まって、
それ以降（それ以前からか？）、ずっと一人だけインタフェースを理解できていない。

内部の実装を考えなくていいように、外からそれらに依存しなくていいように、
「クラスを設計の話」をしようとすると、「インタフェース設計（？）」の話になる。
外部からはインタフェースとして捉えるだけで十分であってほしいし、
メソッド間のつながり（？）なんて考えなくていいようにしたいはずだ。

もちろん、実際に具体的なクラスを実装するときには、
好きなデータ型やアルゴリズムをやりくりしたらいいし、
「データが無いインスタンス」とやらに悩む必要は無い。
インタフェースどおりの要求を満たせばいい。

クラス設計の話をするからこそ、インタフェースという観点が大事になる。
それを初学者に対して、やさしく指摘してあげたのが>>627だろう。
826 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/13(火) 18:31:56 ]: はっきり言うと、インタフェースを理解できてない人はここにはいない。
ただのインタフェースを設計するのに、内部構造を知る必要があるとは誰も言っていない。
クラスのインタフェースを設計するのに、そのクラスで管理する情報（状態）を把握する必要があると言っている。

627は構造化の人だ。クラスを知らないか、構造化と同じだと思っている。825も同じだと思っている人だろう。
そのため構造化のインタフェース設計の基礎を繰り返す。
ちなみに機能（○○登録など）でクラス分けした人、あれも構造化の人だ。
そのためあのクラス図には、内部情報の記述がない。クラス図と言うよりモジュール構成図だ。
もしかしたら、627や825かもしれない。
827 名前：仕様書無しさん mailto:sage [2008/05/13(火) 19:11:04 ]: 理解できてない人が居るじゃないか
そうお前だよお前
828 名前：仕様書無しさん mailto:sage [2008/05/13(火) 19:25:55 ]: >>826
お前な、
>ただのインタフェースを設計するのに、内部構造を知る必要があるとは誰も言っていない。
>クラスのインタフェースを設計するのに、そのクラスで管理する情報（状態）を把握する必要があると言っている。
隠蔽ってなんだと･･･
829 名前：仕様書無しさん mailto:sage [2008/05/13(火) 19:33:39 ]: おじゃばは焦るとあいつはもっと悪い探しを始めるからわかりやすいなｗ
830 名前：仕様書無しさん mailto:sage [2008/05/13(火) 19:42:23 ]: つか、俺はバカじゃないとこんなに思いたくない奴って、いるか？
いい歳こけば自分が他の奴よりわからなくったって仕方ない、教えてもらおう、って思うよな。
>>826みたいに見苦しいことをしてまで守るものって、プライドじゃなくてガキのわがままだろ。
いいかげん、ちったぁオトナになれや、おじゃば。
831 名前：仕様書無しさん mailto:sage [2008/05/13(火) 19:46:29 ]: 無理だろ
仕事中に書き込む暇がこんなにある
オフィスでもゴミ扱いな人間なんだから
832 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/13(火) 19:55:47 ]: >>828
カプセル化とかは別の話だ。つーか、クラス図を見たことはないのか？
833 名前：仕様書無しさん mailto:sage [2008/05/13(火) 19:55:59 ]: >>831
いや、俺はこいつはほんとにオフィスにいるのかどうか怪しいと思う。
知識が古いし、持ちだす例がいちいちおやじくさい。構造化じゃないとこに今どきこだわるとことか。
どっかの施設で平日にネットいじれる環境にいる、昔病んだロートルじゃないかな？おじゃばって。
834 名前：仕様書無しさん mailto:sage [2008/05/13(火) 20:11:16 ]: インターフェイスって外部との接点なんだから、外部とヤリトリスる情報が必要なんざゃないか？
835 名前：仕様書無しさん mailto:sage [2008/05/13(火) 20:14:19 ]: 外部とヤリトリスる情報

ここだけこんなカタカナになるって普段どんだけ「○リトリス」って単語入力してんだろうと想像してしまう。
836 名前：仕様書無しさん mailto:sage [2008/05/13(火) 20:21:57 ]: >>835
おじゃばの名前で書けないんだ、別人という演出だよ、わかってやりなｗ
837 名前：仕様書無しさん mailto:sage [2008/05/13(火) 20:50:33 ]: >>808
>だいたい、>>627 をよく読むと、データのないインスタンスを作れるといってると
>いうより、インターフェースさえ満たしていれば、中身はブラックボックスでいい
>ということを言ってるように思える。　ということで読解力の無いのは>>805 だな。

>>810
>あ、ちなみに俺も>>627については、読解力云々は抜きにして>>808の後半の様に解釈したよ。

>>819
>カプセル化して内部の実装を隠して、
>クラス外からは気にしなくて言いようにして、
>変わりに、インタフェースという単位で扱える。
>そのあたりまえの利点を説いているだけの人と、
>メンバ変数を保持しないクラス設計（？）を勝手に批判してる人。
>でさらに>>794が「オブジェクトはデータ＋操作でオブジェクトだ」
>などとトンチンカンなことを言い出す。さらにこいつは、

お前ら本当にアホだな
>読解力の無いのは>>805 だな。
読解力の無い？、アホかｗ
>インターフェースさえ満たしていれば、中身はブラックボックスでいい
そんなの読めば分かる、分かった上で知識が浅いと書いているんだ
そんな事も分からんのか？　お前らの言っているのはOOA/DのIFの考えじゃない
お前らの言っているのはプロトコル系(CORBA,COM)のIFの特徴なんだよ
だからデータの無いオブジェクトとか平気で書けるんだろうが、ボケが

>トンチンカンなことを言い出す
お前らの方がよっぽどトンチンカンに見えるぞ
838 名前：仕様書無しさん mailto:sage [2008/05/13(火) 21:00:37 ]: >>826
「クラスのインタフェースを設計するのに、
そのクラスで管理する情報（状態）を把握する必要があると言っている。」

必要とは、必ず要するということだ。必要など無いと言ってる。
クラスのインタフェースを設計するのに重要なのは、
設計するクラス群の連携について把握することだ。
そして、各クラスのインタフェースを把握することだ。

インタフェースの実装としてクラス定義をするなら、
その定義に内部情報でもなんでも登場させればいい。
思う存分好きなだけ、内部データを明記すればよかろう。
839 名前：仕様書無しさん mailto:sage [2008/05/13(火) 21:02:44 ]: OO様「そんなくだらないことはどうでも良い。
　　　　お前等がどんな構造やどんな処理をしているかなど知りたくもない。
　　　　だが、俺が呼び出したら指示通りに動け、余計なこともするな。」
840 名前：仕様書無しさん mailto:sage [2008/05/13(火) 21:09:36 ]: >>837
アホとバカとボケと説明のない用語の羅列だけじゃ、誰も納得しないよ。
何がしたいのかな？
841 名前：>>810 mailto:sage [2008/05/13(火) 22:15:22 ]: >>839
おれは>>627の文章の解釈（内容そのものではなく）について言っているのであって、
>そんなの読めば分かる、
のであれば、別にあんたを否定するつもりはないぞ。
「データ＋操作＝オブジェクト」も入門書やネットでも良く見かける説明だしな。

それじゃ、OOA/Dとプロトコル系のIFの考え方、特徴の違いについて説明してくれよ。
842 名前：仕様書無しさん mailto:sage [2008/05/13(火) 22:20:54 ]: >>841
未だと満遍なく敷き詰めてギチギチに
Cの構造体で渡す仕様しかないか
それ以上に細かく上位操作が定義されてるか
ぐらいしか違いないよ

SIPとかはえープロトコルはデータだけしか
あんまり意識されてないけどさ
843 名前：仕様書無しさん mailto:sage [2008/05/13(火) 22:31:56 ]: インターフェースはオブジェクトの特性を考えて振舞を抽象化したもんだろ？　
それなのに必ず内部情報とセットで考えないといけないとなったら、
せっかくの抽象化の利点が薄れてしまうだろ？

汎用的に使える「レンタルインターフェース」を考えるんじゃない、ビデ
オインターフェースにするか、DVDインターフェースにするか、レンタカー
インターフェースにするか、貸し衣裳インターフェースにするか、...
属性といっしょに考えないといけないからな。さぁさぁどれか選べ。

と言ってるようなもんだろ。つぅか、せっかくの便利な機能になんで
わざわざそういう制限を課さなきゃなんねんだ？　バカじゃん。
あと>>837は明らかに説明がへたくそ。間違ってる上に説明がへただからレスが
なにやら神秘的な雰囲気を醸し出している。全レスしてる暇があったら勉強しろよ。
844 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/13(火) 22:41:40 ]: >>837
口は悪いが、言っている事は間違ってない。

>>838
>設計するクラス群の連携について把握することだ。
「クラス群の連携？」もう支離滅裂だな。連携するのが前提なクラスなのか？それこそカプセル化はどうした？
「メソッド（関数）群の連携」の間違いじゃないのか？
で、メソッド群の連携を把握するには、そのクラスで管理する情報を把握しないと出来ないだろう？

>>842
俺も841と同じ事を聞きたい。
俺はCの構造体もSIPも知っているが、842の回答の意味が分からない。
Cの構造体がどうのと言うのはおそらくスタンプ結合の事だと思うが、スタンプ結合がOOに反する事は
誰でも知っているのではないかと思う。

>>843
841の質問に答えてくれないか？
845 名前：仕様書無しさん mailto:sage [2008/05/13(火) 22:43:54 ]: 残業中？
846 名前：仕様書無しさん mailto:sage [2008/05/13(火) 22:56:13 ]: おじゃば、ひょっとしてインターフェースを設計したことないんじゃないのか？
ほんとうに、属性とメソッドの組合せしか設計してないんじゃないのか？
それで抽象化をわかっているといってるわけじゃないよな？
それともお前の抽象化は一般的なものとは違うのか？　あ、これはお前の得意技
だったな。
847 名前：仕様書無しさん mailto:sage [2008/05/13(火) 23:22:52 ]: おじゃばが何を言いたいのかマジでわからん。

>>844の>>838へのレスで、
何故、「クラス群の連携」が支離滅裂なのか、（クラス図とかに「クラス群の連携」を書かないか？）
その後になぜ「カプセル化はどうした？」となるのか、
さらには、「メソッド（関数）群の連携の間違いじゃないのか？」と勝手に結論づけて
「メソッド群の連携を把握するには、そのクラスで管理する情報を把握しないと出来ないだろう？」
と意味不明な質問を投げ返している。

こいつは、本当にまっとうな日本人なのか？
848 名前：仕様書無しさん mailto:sage [2008/05/13(火) 23:27:44 ]: OOとか今更はやらねーしなぁ
総称型が普通になるとOOすると
逆に邪魔くさくなるよなぁ
849 名前：仕様書無しさん mailto:sage [2008/05/14(水) 00:48:29 ]: >>822 何で一般的なインタフェース設計の話になるんだ？

こんなこと言ってること時点でインターフェースを理解できてない証拠

例を出さないと嫌らしいので一応書いてみますわ
レンタル業務では、レンタル管理と在庫管理と商品管理の各コンポーネントで実際は管理するはず
前提のシナリオとオブジェクトはオレオレなのと半端分析なので、そこは考慮よろしく
----
レンタル管理コンポーネント
　インターフェース「貸し出す」「返してもらう」
　クラス「レンタル内容」

在庫管理コンポーネント
　インターフェース「在庫を確認する」「在庫を確保する」
　クラス「在庫」「保管場所」「出庫」

商品管理コンポーネント
　インターフェース「商品を見る」「商品の情報を取得」
　クラス「商品」「業者」
----
何人かが言ってるように、DOAとかPOAとかはそもそも全く関係が無く、
業務をどうやって実現するかが大事
インターフェースとクラスはコンポーネントから導き出さないといけないし、
コンポーネントはユースケースから導きださないといけないし、
ユースケースはアクティビティから導き出さないといけない
そこがすっ飛んで、「クラス図を出せ」とか言いだしてるのがOO設計が分かってない証拠

コンポーネント仕様が、インターフェースと情報の両方を確定させるわけで、
クラス内部の情報が必要、というよりも、
どういう業務を行うのか、ということを持ってインターフェースが確定する
別に設計から実装の手順を言ってるわけじゃなくて、これができることがOOの一番の利点だし
850 名前：仕様書無しさん mailto:sage [2008/05/14(水) 01:02:34 ]: >>849
断言する。
そこまで丁寧に書いても間違いなくおじゃばは理解できない。
かつ、支離滅裂論を展開する。

無限ループだな。
851 名前：仕様書無しさん mailto:sage [2008/05/14(水) 02:39:46 ]: >>850
そりゃ、当たり前だろ。おじゃばはOOD/Aは不要でOOPがJavaによって可能だから
それでOOは十分、という誰にも理解できないコーダ原理主義を信じてる。
ただ単に自分に理解できないモノは不要だ、という年寄りによくあるやつだ。

どんなにやさしく言っても、理屈で北鮮の奴を説得できないのと同じだろうな。
852 名前：仕様書無しさん mailto:sage [2008/05/14(水) 07:36:45 ]: OO古いよｗ
流行らないってｗ
853 名前：仕様書無しさん mailto:sage [2008/05/14(水) 08:01:51 ]: 古いかどうかが問題ではなく実際に使えるかどうかが問題なのだが
854 名前：仕様書無しさん mailto:sage [2008/05/14(水) 08:50:36 ]: まぁ、自分が理解できないものを流行らねぇと思いたくなる気持ちもわからんではないが。
855 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 09:06:23 ]: >>846
だから、841の
>それじゃ、OOA/Dとプロトコル系のIFの考え方、特徴の違いについて説明してくれよ。
に答えてくれよ。
俺の質問の「Cのモジュール化とどう違うの」にでもいいぞ。

>>847
847がクラス設計において、「カプセル化はメソッドに対してではなく、クラスに対して適用する物」
と言う事を知らないからだろう。

>>849
>レンタル管理コンポーネント
>　インターフェース「貸し出す」「返してもらう」
>　クラス「レンタル内容」
インタフェースの「貸し出す」と「返してもらう」が、クラス「レンタル内容」に属すると言うのを
どうやって決めるんだ？
もし、「レンタル状況確認」インタフェースが増えたら、クラス「レンタル内容」に入れるのか、
他のクラスに入れるのか、新しいクラスを作るのか、どうやって決めるんだ？
インタフェース名の日本語内容から勘で決めるのかな？
856 名前：仕様書無しさん mailto:sage [2008/05/14(水) 09:34:23 ]: >>849
ほらな、だから言うだけ無駄だって。こいつは人の言うことは考えもしないで質問するくせに
自分の言うことはむちゃくちゃでも意図は伝わるだろとかマジで言うあまえんぼさんなんだからさ。
857 名前：仕様書無しさん mailto:sage [2008/05/14(水) 09:41:02 ]: >>844
一連のクラス群の連携を考えるからこそ、
どう組み合わされて仕事をするか吟味したり、
そして、クラスの役割や独立性を吟味したり、
相互に依存関係がありすぎないか吟味したり、
明瞭なインタフェースかどうかを吟味したりして、
クラス群にそれぞれのインタフェースを確立していく。

メンバ変数やメンバ関数の実装を隠し、
インタフェースを意識させて設計する。
これがカプセル化じゃないなら何？

> メソッド群の連携を把握するには、そのクラスで管理する情報を把握

そもそも、それはクラスで管理する情報を把握することで、
なぜ可能になるのだろうか？　まったくピンとこない。
各抽象メソッドの実装は与えられていないのに？
内部情報とメソッドの関係はどこに出てくる？

>>664
class 会員{
　　住所; 氏名; 年齢;
　　登録(); 更新(); 削除();
};

これのどこを読めばどんな「メソッド間のつながり」
とやらが見えてくるのか教えて欲しい。
実装を意識できない他者へ、何が見えるのか。
858 名前：仕様書無しさん mailto:sage [2008/05/14(水) 09:41:16 ]: >>855
>>844の>>838へのレスは俺にとっても意味不明なんだが。

特にコレ。
>連携するのが前提なクラスなのか？
そら連携するのは前提だろうに。
OOなシステムってのはそもそも、システム内部のクラス群が連携して動作するもんだろ。
連携は、相互作用とか協調とか言い換えてもいいかも知れない。

他のクラスと連携しないクラス、言いかえれば、
どのクラスからも操作もされないし、どのクラスも操作しないクラス。
(get/setも、まぁ操作にコミで)
そんなクラスをシステム内で何に使うんだ？
859 名前：仕様書無しさん mailto:sage [2008/05/14(水) 09:44:40 ]: >847がクラス設計において、「カプセル化はメソッドに対してではなく、クラスに対して適用する物」
>と言う事を知らないからだろう。

インターフェースは各クラスに共通化された部分に対する設計であり。
カプセル化はとりあえず関係ないぞ。

共通部分だからカプセル化は関係ないし。

各クラスの動作しらないとインターフェースを作れないし。
カプセル化はそれを承知した上でインターフェースごと(当然継承されたクラスで確立された)行う。

847の言ってることはそういった前提だし、だれもが無意識化にやっている事だ。
おじゃばはそういった認識が無かったけどカプセル化をやっていたと無知を告白しているようなもんだけど。

と、Java組んだ事ないしインターフェースのお勉強は一時間しかやっていない漏れが言ってみる。
でもこうしてお勉強するとCの多重継承の代わりとなんでおじゃばがいったのか判らん。
代替じゃなくて代償じゃん。
860 名前：仕様書無しさん mailto:sage [2008/05/14(水) 09:47:34 ]: ところで、おじゃば、判ってないかもしれないがこの場合の連携とは
実体同士でのデータのやり取りを必ずしも意味しないぞ。
861 名前：仕様書無しさん mailto:sage [2008/05/14(水) 09:53:32 ]: ところで、「メソッド間のつながり」なるわけのわからない用語を
おじゃばがどっから持ってきたのかは興味があるな。
グローバル変数とかシングルトンが大好きな馬鹿が言いそうなことだけどな。
862 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 10:04:30 ]: >>849
一度確認させてもらおう。
>レンタル管理コンポーネント
>　インターフェース「貸し出す」「返してもらう」
>　クラス「レンタル内容」
これは、
class レンタル内容{
　　貸し出す();
　　返してもらう();
};
と解釈したが、それでいいのかな？
もしかして、
class レンタル管理コンポーネント{
　　貸し出す();
　　返してもらう();　
};
とか、別の意味かな？
863 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 10:19:40 ]: >>857
-------------------------------------------------------------------------
class 会員{
　登録();更新();削除();
};
class 連絡先{
　登録();更新();削除();
};
これに、「住所一覧取得()」が追加になりました。どのクラスに追加しますか？
-------------------------------------------------------------------------
class 会員{
　住所、氏名、年齢
　登録();更新();削除();
};
class 連絡先{
　電話番号
　登録();更新();削除();
};
これに、「住所一覧取得()」が追加になりました。どのクラスに追加しますか？
864 名前：仕様書無しさん mailto:sage [2008/05/14(水) 10:35:38 ]: ほらな。ずーっとおじゃばはコーダの枠からから出るつもりが無いんだよ。
設計やら分析の話をいくらやさしくしてやっても聞く気がない。
いいかげん無駄なことはやめたら？
865 名前：仕様書無しさん mailto:sage [2008/05/14(水) 10:55:24 ]: >>864
それ以前に、勝ち負けばっかり考えてて人の言うことを理解しようとする気がないよコイツ。
そんなんでよく社会生活ができてるもんだよね。してないのかも。
866 名前：仕様書無しさん mailto:sage [2008/05/14(水) 11:14:58 ]: 無限ループって怖くね？
867 名前：仕様書無しさん mailto:sage [2008/05/14(水) 11:34:17 ]: ホントOOの基礎中の基礎レベルの概念しかしらないんだな
この程度の内容で誰に何を伝えたいのかと
868 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 11:40:26 ]: いや理解してるって。
857の説明はクラス関係ないだろう？クラスを関数に変更して読めば、構造化そのものの説明だろ。
857は構造化の説明で、オブジェクト指向じゃないって言っているんだよ。
それに基礎中の基礎だと言う事は知っているが、基礎も分からなかったら先に進めないだろう。
869 名前：仕様書無しさん mailto:sage [2008/05/14(水) 11:51:41 ]: わかってるならさっさと話を進めてみせろよｗ

お前毎度毎度「基礎中の基礎」で止まってオシマイじゃない
初心者向けの本のコピペでもいいから
さっさともうすこしまともなことを書いてレベルを引き上げろ
870 名前：仕様書無しさん mailto:sage [2008/05/14(水) 11:56:17 ]: 構造化に敵意を燃やす、90年代前半の頭しかないのになにを言っとるんだこのジジイは。
871 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 12:55:14 ]: 「オブジェクト単位で変更可能」ってのが否定されたら、進めようがないだろう？
それに俺は構造化も詳しいぞ。別に構造化を否定している訳ではない。
実務でDVDレンタルを作るなら、OOより構造化で作った方が、シンプルで少ない量で出来る。
ただ、OOと構造化は違うと言っているだけだ。
872 名前：仕様書無しさん mailto:sage [2008/05/14(水) 13:06:04 ]: OO？いいえ、それは00(ゼロツー)です。
873 名前：仕様書無しさん mailto:sage [2008/05/14(水) 14:03:13 ]: >>871
OO(P) と構造化は相反する概念じゃないよ。
874 名前：仕様書無しさん mailto:sage [2008/05/14(水) 14:29:13 ]: >>863
> これに、「住所一覧取得()」が追加になりました。どのクラスに追加しますか？

set住所一覧を持つクラスがあればそれに対応させて追加するだろうし、
住所管理を役割として受け持つべきクラスがあれば、そこに追加する。
いずれにせよ、クラスの相互関係を考えて、ふさわしいクラスを決める。

既存のクラスのクラス定義で、どの変数を持っているかは、
何かの参考にはなりえたとしても、決定的な基準じゃない。
あくまで、他との連携が不自然じゃないかどうかで決める。
あくまで、オブジェクトの特性に従って決める。
あくまで、特定の実装に拠らないでいいように決める。

> メソッド群の連携を把握するには、そのクラスで管理する情報を把握

メソッドの実装は与えられていないのに？
内部情報とメソッドとの対応はどこに出てくる？

>>863のどこを読めばどんな「メソッド間のつながり」
とやらが見えてくるのか、順を追って教えて欲しい。
875 名前：仕様書無しさん mailto:sage [2008/05/14(水) 17:26:10 ]: 元の話がどうなってんのかサッパリ分からんが、そもそも会員とか連絡先クラスが
登録、更新、削除なんてメソッドを持つ必要があるのか？てか、要不要以前に待つ
事はありえんだろ？例が既に現実離れしてる気が・・・・・・

会員クラスが電話番号を持ってないのも意味不明だし、連絡先クラスに至っては
電話番号しか持ってないし(これ誰の電話番号か分かんないじゃんｗ)、何かもう
全体的に意味不明すぐるんだが（ﾟдﾟ）ﾎﾟｶｰﾝ
876 名前：仕様書無しさん mailto:sage [2008/05/14(水) 18:35:19 ]: >>875
それはね、元を作ったおじゃばさまとへんなコテハンつけてるのがね、
会員テーブルはadd,uppdate,deleteができるだろ、くらいのバカな頭でメソッドと称してるだけなの。
会員を登録、会員を変更、会員を削除、と考えれば会員にそんなメソッドがあるわけないだろ。
何に会員を登録、と考えられないほどバカなのよ。許してね。まともな人はここ来ない方がいいけど、
このバカがいつもageるのが良くないんで。かんべんしてちょうだい。
877 名前：仕様書無しさん mailto:sage [2008/05/14(水) 19:01:01 ]: あの人、自分でOOの考え方を崩してるのに気が付いてないんだよ
878 名前：仕様書無しさん mailto:sage [2008/05/14(水) 19:45:32 ]: > 会員を登録、会員を変更、会員を削除、と考えれば会員にそんなメソッドがあるわけないだろ。
わろたｗ　ヽ(´ー｀)ノｲｯﾁｬｯﾀ､ｲｯﾁｬｯﾀ　誰がいつそれを言うのかと思ってたｗ
879 名前：仕様書無しさん mailto:sage [2008/05/14(水) 20:07:25 ]: >>878
しまった、つい言っちゃったよｗ失敗。我慢できなかったんだよ～
880 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 20:45:20 ]: この人達にOOを教えるのは無理と悟った。
まあ、クラス設計が出来ない訳は分かったよ。不自然じゃないか適切に吟味するんだよな。
出来ればその手法でレンタルシステムを設計してくれないか？ついでに利点を教えてもらえると助かる。
881 名前：仕様書無しさん mailto:sage [2008/05/14(水) 20:51:17 ]: >>880
でた、「この人達」ｗもういいじゃないか、お前がそれで納得したんなら。
無理にレンタルシステムを引っ張って、勝負(笑)しなくても。お前はお前の道を行けばいい。
それが平和というものだろう？
882 名前：仕様書無しさん mailto:sage [2008/05/14(水) 20:58:39 ]: >>800
ここまで200レス以上も使って、いろんな人から、
いろんな言葉を尽くしてもらって、それでも、
自分が何を理解出来てないかすら気づけない。

インタフェースのことすら理解できない人間は、
まずは本買って自習することをオススメする。

半年ROMって出直しておいで…。さようなら。
883 名前：仕様書無しさん mailto:sage [2008/05/14(水) 20:59:50 ]: >>882の修正
×>>800
○>>880
884 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 21:03:55 ]: 確かにその通りだが、レンタルシステムでやれと言い出したのは俺じゃない。
人にやらせておいて、3人逃亡だよ。少しは文句言ってもバチは当たらないだろう？
885 名前：仕様書無しさん mailto:sage [2008/05/14(水) 21:11:34 ]: 彼は無駄にステレオタイプが強すぎる希ガス
初心者並の見方しかできてない　経験不足か？
オブジェクトのとらえかたは色々あるということに気づいてないんじゃないかと

つーか説得力の欠片もないレスで誰に何を教えようとしたのかと
挙げ句いつもの通り理解できない「この人達」が悪い　ですか
仮に「この人達」がバカだとしても
そのバカに教えられなかった時点で負けだということに気付いてくれ

そして教えるに足るだけの知識が自分に備わってないことに気付いてくれ
「この人達」的には初心者本以下の繰り返しをされても何も学ぶことはないのだから
886 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 21:24:26 ]: >>885
確かにその通りだ。俺の負けだよ。
でも、彼らに教えられる人間はいるのか？
887 名前：仕様書無しさん mailto:sage [2008/05/14(水) 21:28:03 ]: インタフェースとは、仕様を表現するものである。
888 名前：仕様書無しさん mailto:sage [2008/05/14(水) 21:39:00 ]: >886
だから何度も言ってるじゃん
「お前が何を教えたいか」がさっぱりわからない

「この人達」のほうがよっぽど理解してるようにみえるし
889 名前：仕様書無しさん mailto:sage [2008/05/14(水) 21:59:47 ]: そもそも話の出所はどこじゃらホイ？とか思って辿ってみたらスレの最初まで
戻って吹いた。なんじゃこのスレｗ

>>887
インターフェイスなんてのは型システム上の些細だけど便利な仕掛け。
それ以上でもそれ以下でもない。
その手の小洒落た言い回しは物事を無駄にややこしくするだけで誰の得にも
ならんから止めとけｗ
890 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:05:39 ]: インタフェースとは、仕様を表現するものであり、
アーキテクトの道具である。
891 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:09:02 ]: >>889
大切なのは概念なんだよ。
便利な仕掛けレベルの理解で終わるなよ。ガンバレ。
892 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:11:11 ]: >>889
小洒落てるか？
そのまんまだじゃね？
「便利な仕掛け」とかの方がよっぽどややこしく思うんだけど。

Javaのinterfaceって、クラスの外部IF仕様をコードレベルで規定するだけのもんじゃねの？
893 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:14:25 ]: >>889
カルチャーショックだったかなｗ
894 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:21:15 ]: 概念って要求の集合って捉え方でいいの？
「クラスaはb概念を満す」みたいな使い方する
情報原はboostのドキュメントと90年代前半ぐらいに出た型理論の本(名前忘れた)
895 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:24:25 ]: 概念をインタフェースすると仕様になるよね。
896 名前：おじゃばさま ◆GxjxF3yEw6 [2008/05/14(水) 22:33:12 ]: あー、もう教えるのは諦めた。教えてもらおう。
センセー、クラスって何ですかー
897 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:34:33 ]: 仕様をインターフェイスすると概念が生まれるんじゃね？ｗ

>>892
そしてhogeImplとか一杯書いちゃうんだ？うわ！ウザｗｗｗｗｗ
898 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:39:13 ]: 既に分かってる人に教えても釈迦に説法でしょう？
教えるのが下手でも、分かってるならば、それで良いじゃないですか
時間の無駄ですよ
899 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:40:46 ]: 概念を満すモデルの持つインターフェース
900 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:50:31 ]: >>896
教えてるつもりだったのか！？
901 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:52:36 ]: >896
( ´_ゝ`)ふーん
902 名前：仕様書無しさん mailto:sage [2008/05/14(水) 22:55:36 ]: クラスもまた概念であった。
903 名前：仕様書無しさん mailto:sage [2008/05/14(水) 23:04:13 ]: 言葉遊びじゃなくて数式でスッキリサッパリ理解できるものは無いのか？
904 名前：仕様書無しさん mailto:sage [2008/05/14(水) 23:06:19 ]: =
905 名前：仕様書無しさん mailto:sage [2008/05/14(水) 23:29:33 ]: ハノイの塔
906 名前：仕様書無しさん mailto:sage [2008/05/14(水) 23:47:42 ]: おじゃばが、>>871で言ってる「オブジェクト単位で変更可能」
にするためにもそもそもインターフェースが重要なんだけどな。
おじゃばはいったいどうやって変更可能にする気だったんだ？
でもまぁ、もいっか...
907 名前：仕様書無しさん mailto:sage [2008/05/15(木) 02:18:27 ]: そうまでしてものを教えたい、というおじゃばの情熱というか執念はオブジェクト指向よりずっと謎だw
しかも、何を教えたいとか誰に教えたいとかが訳がわからないでただ「教えたい」
その思いの後ろにどんな心の闇があるのやら。こわいこわい。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef