OOスレ8 なぜオブジェクト指向は普及しないのか
過去ログ
part 1 http://pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 http://pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 http://pc11.2ch.net/test/read.cgi/prog/1185378099/
part 4 http://pc11.2ch.net/test/read.cgi/prog/1188396264/
part 5 http://pc11.2ch.net/test/read.cgi/prog/1189946678/
part 6 http://pc11.2ch.net/test/read.cgi/prog/1190731526/
part 7 http://pc11.2ch.net/test/read.cgi/prog/1192703383/
おじゃばは簡潔に書け オレオレルールも禁止
その他はスルー技術を身につけれ
おじゃばの低能はデフォ 熱くなった方が負け
part 1 http://pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 http://pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 http://pc11.2ch.net/test/read.cgi/prog/1185378099/
part 4 http://pc11.2ch.net/test/read.cgi/prog/1188396264/
part 5 http://pc11.2ch.net/test/read.cgi/prog/1189946678/
part 6 http://pc11.2ch.net/test/read.cgi/prog/1190731526/
part 7 http://pc11.2ch.net/test/read.cgi/prog/1192703383/
おじゃばは簡潔に書け オレオレルールも禁止
その他はスルー技術を身につけれ
おじゃばの低能はデフォ 熱くなった方が負け
|
|
|
まあデフォだよな
人をイラつかせる能力だけは高い。まぁ熱くなったら負けだな。
4 ：仕様書無しさん：2008/01/29(火) 21:59:58
なぜ8000レスもの駄レスを垂れ流している間にOOを学ぼうとしないのか
もう学ぶべきものがないから
6 ：仕様書無しさん：2008/01/29(火) 22:27:27
おまえらーーー、ぃぉぅ
まだまだ、つづくよーーー、おじゃばと楽しい仲間スレ
>>1
>その他はスルー技術を身につけれ
それが出来たら、スレ８まで行かないよｗ
Here, We Go Together With おじゃば
まだまだ、つづくよーーー、おじゃばと楽しい仲間スレ
>>1
>その他はスルー技術を身につけれ
それが出来たら、スレ８まで行かないよｗ
Here, We Go Together With おじゃば
Java/C++＝オブジェクト指向、っていうイメージが問題なんじゃね？
やっぱRubyだろ
業務で使ってるとこ見たことないわ
>>9
そんなことはないだろう
そんなことはないだろう
見たことないという個人的な体験を他人ごときが否定することは出来ないのだよ。
Objective-C の事も忘れないであげて下さい
COBOL++ こそ オブジェクト指向
COBOL も cObOl ってしとけばなんとなくカッコよかったのにな。つくづく残念だ。
CODASYLのばか
CODASYLのばか
part3より
926 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2007/08/23(木) 20:39:09
なんだと、チキショー！
やんのか、オラァ！！
926 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2007/08/23(木) 20:39:09
なんだと、チキショー！
やんのか、オラァ！！
ところで各コンパイラの癖の話はどうなったの？
コンパイラの癖じゃなくてライブラリーのバグだと思うんだが、
その点をおじゃばはスルーしている。
そろそろ、おじゃば語録でも作った方がよいかも知れない。
その点をおじゃばはスルーしている。
そろそろ、おじゃば語録でも作った方がよいかも知れない。
もうすぐおじゃばがくるよ！！
くるよ！！
くるよ！！
しょーもねえ弁明やこの場に及んでの話題逸らしを聞かされるくらいなら、
もうおじゃばこなくていいよ！！
いいよ！！
もうおじゃばこなくていいよ！！
いいよ！！
20 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/30(水) 09:33:41
前スレの宿題から片付けておくか。
>>984
俺みたいのの下に付くような幸運は、滅多にないから安心しろよ。
最近の流行は新人放置だからな。
>>985
大した仕事じゃないのは否定しない。そんなに難しくなかったからな。
俺がやった時は、振り分け判定部分はアセンブラ似のDBをCから呼び出して使用した。
コンパイラの癖は例を出して解説している所は非常に良いと思う。
どこかの誰かのように、「それは違う」「例はまだ？」を繰り返す人には、見習って欲しい物だ。
>>988
では、Solaris64でperlにSSH組み込む方法を教えてくれ。
ダウンロードするパッケージ名と、configure時のオプションでいいぞ。
もっと簡単な方法があればそれでもいいぞ。
>>984
俺みたいのの下に付くような幸運は、滅多にないから安心しろよ。
最近の流行は新人放置だからな。
>>985
大した仕事じゃないのは否定しない。そんなに難しくなかったからな。
俺がやった時は、振り分け判定部分はアセンブラ似のDBをCから呼び出して使用した。
コンパイラの癖は例を出して解説している所は非常に良いと思う。
どこかの誰かのように、「それは違う」「例はまだ？」を繰り返す人には、見習って欲しい物だ。
>>988
では、Solaris64でperlにSSH組み込む方法を教えてくれ。
ダウンロードするパッケージ名と、configure時のオプションでいいぞ。
もっと簡単な方法があればそれでもいいぞ。
21 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/30(水) 09:38:09
あとVCからgccへの移行時の注意だったかな。
VCと言ってもCだと言っていたから、WinのCからLinuxのCへの移植時の注意だな。
VCと言ってもCだと言っていたから、WinのCからLinuxのCへの移植時の注意だな。
22 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/30(水) 10:14:25
1.ライブラリに注意。
標準以外のライブラリを使用している場合、それが移植先の環境にもあるか確認する。
汎用DB等ならほぼ問題ないが、それ以外は殆ど使えなくなる事が多いので注意。
2.バス幅、バイトオーダーの違いに注意。
CPUのビット数、ビックエンディアン／リトルエンディアンの違いがある場合は、バイナリファイルに影響する。
具体的に言うと、外部IFにバイナリファイルを使用している場合、そのままでは使えないから注意。
3.ファイルシステムの違いに注意。
Linuxではファイルの権限が強化されているから注意だ。
具体的に言うと、open()やmkdir()のパラメータにパーミッションが追加／フラグ追加になるので注意。
4.関数の違いに注意。
Winでセキュリティー強化されている関数（strncpy_s()等）を使っている場合は修正が必要だ。
こんな所だな。
標準以外のライブラリを使用している場合、それが移植先の環境にもあるか確認する。
汎用DB等ならほぼ問題ないが、それ以外は殆ど使えなくなる事が多いので注意。
2.バス幅、バイトオーダーの違いに注意。
CPUのビット数、ビックエンディアン／リトルエンディアンの違いがある場合は、バイナリファイルに影響する。
具体的に言うと、外部IFにバイナリファイルを使用している場合、そのままでは使えないから注意。
3.ファイルシステムの違いに注意。
Linuxではファイルの権限が強化されているから注意だ。
具体的に言うと、open()やmkdir()のパラメータにパーミッションが追加／フラグ追加になるので注意。
4.関数の違いに注意。
Winでセキュリティー強化されている関数（strncpy_s()等）を使っている場合は修正が必要だ。
こんな所だな。
おじゃばがマメな上に馬鹿なのはよくわかった。
24 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/30(水) 19:27:02
>>993
関数のポインタは、sort()関数や、signal()関数などで使う。
自分で使う場合は、パラメータによって処理を変えたい場合に、内部のテーブルにパラメータと
一緒に保存して判定するようにすると、switchを使った場合より短く書ける。
また、関数のポインタを駆使すると、C++のクラスのような事も出来る。
ただ、前者はswitchの方が分かりやすいし、後者はC++を使った方がいい。
Solaris64の数値演算ライブラリの件が不評なので、有名なコンパイラの癖を紹介しよう。
「関数引数の実行順序は保証されない。」
int count = 0;
func(++count, ++count);
とあった場合、
コンパイラによっては、
func(2, 1);
で渡る物もあれば、
func(2, 2);
で渡る物もある。
結構知らない人もいるから、気をつけた方がいい。
これなら、100%コンパイラの癖だから文句はないだろう。ただ俺が苦労したのは前者だがな。
関数のポインタは、sort()関数や、signal()関数などで使う。
自分で使う場合は、パラメータによって処理を変えたい場合に、内部のテーブルにパラメータと
一緒に保存して判定するようにすると、switchを使った場合より短く書ける。
また、関数のポインタを駆使すると、C++のクラスのような事も出来る。
ただ、前者はswitchの方が分かりやすいし、後者はC++を使った方がいい。
Solaris64の数値演算ライブラリの件が不評なので、有名なコンパイラの癖を紹介しよう。
「関数引数の実行順序は保証されない。」
int count = 0;
func(++count, ++count);
とあった場合、
コンパイラによっては、
func(2, 1);
で渡る物もあれば、
func(2, 2);
で渡る物もある。
結構知らない人もいるから、気をつけた方がいい。
これなら、100%コンパイラの癖だから文句はないだろう。ただ俺が苦労したのは前者だがな。
おじゃばが自己顕示のためには努力するがやはり馬鹿なのはよくわかった。
がんばったのはわかった
非常に微笑ましい
しかし出だしからスレタイ無視だな
みんなｗｗ
非常に微笑ましい
しかし出だしからスレタイ無視だな
みんなｗｗ
>「関数引数の実行順序は保証されない。」
>int count = 0;
>func(++count, ++count);
if文の条件式なんか実行順序保証されないので
わざわざ分けたりする。
おじゃば、ちゃんとした技術者連れてきた方が良いぞ。
>int count = 0;
>func(++count, ++count);
if文の条件式なんか実行順序保証されないので
わざわざ分けたりする。
おじゃば、ちゃんとした技術者連れてきた方が良いぞ。
29 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/30(水) 20:20:51
>>29
http://www.st.rim.or.jp/~phinloda/cqa/cqa7.html
>Ｑ 【不定の例】
> 不定である場合としては、どのようなものがあるか。
>Ａ
> 典型的なものとしては、次のようなものがあります。
>
> * 式が評価される順序。
> * 副作用が生じる順序
> * 関数呼び出しの実引数が呼び出される順序。
> * errno 、 setjmp 等の実装がマクロか外部識別子であるか。
if(条件1 && 条件2）
の場合は、条件1,2という順番に動く事もあるし、
2,1という順番で動く事もある。
まあ、大抵順番に動くけどね。
ちなみに、関数の引数も不定なので（正直いうが、関数の引数も不定であると思っていたが、調べた事なかった）。
関数の引数に対するコンパイルの癖であり、ライブラリーのミスであると言い切れない。
（仕様外なので癖というのもおかしいが）
マスターＣのおじゃばのやり方は"明記されていないので礼儀上そうする"に外れているわけ。
http://www.st.rim.or.jp/~phinloda/cqa/cqa7.html
>Ｑ 【不定の例】
> 不定である場合としては、どのようなものがあるか。
>Ａ
> 典型的なものとしては、次のようなものがあります。
>
> * 式が評価される順序。
> * 副作用が生じる順序
> * 関数呼び出しの実引数が呼び出される順序。
> * errno 、 setjmp 等の実装がマクロか外部識別子であるか。
if(条件1 && 条件2）
の場合は、条件1,2という順番に動く事もあるし、
2,1という順番で動く事もある。
まあ、大抵順番に動くけどね。
ちなみに、関数の引数も不定なので（正直いうが、関数の引数も不定であると思っていたが、調べた事なかった）。
関数の引数に対するコンパイルの癖であり、ライブラリーのミスであると言い切れない。
（仕様外なので癖というのもおかしいが）
マスターＣのおじゃばのやり方は"明記されていないので礼儀上そうする"に外れているわけ。
↑の929は別スレのね。
というか、マトモなＣ技術者いなかったの？
・・・3人いれば誰か気が付くレベルの話だと思うんだが。
>func(++count, ++count);
がマジなら、調子乗った2年目に犯すミスだぜ？
おじゃば、Ｃやって2年目位だよな。
正直、マジにおじゃばにお説教したくなってきたよ。
というか、マトモなＣ技術者いなかったの？
・・・3人いれば誰か気が付くレベルの話だと思うんだが。
>func(++count, ++count);
がマジなら、調子乗った2年目に犯すミスだぜ？
おじゃば、Ｃやって2年目位だよな。
正直、マジにおじゃばにお説教したくなってきたよ。
>>32
なまあたたかく見守ろうよ
なまあたたかく見守ろうよ
いいかげんそれも大人げないような気がする。
つか、おじゃば自身が３～５年生以上は私の上ですって前から言ってるし、
勘弁してやってょうがいいんじゃないか？
ほら、あったろ、誰もが「俺はこんなに勉強してて周りに教えてやりたい」ときがさ。
でもそんなのは実際教える相手がいるとふっとんじまう。
なんでかったら、そいつに聞かせるための技術（笑）てのがあるわけで。
それができないからおじゃばは延々とここで「俺偉い」続けてるんだよな。
えらいえらい。よく勉強したね。がんばったね。
つか、おじゃば自身が３～５年生以上は私の上ですって前から言ってるし、
勘弁してやってょうがいいんじゃないか？
ほら、あったろ、誰もが「俺はこんなに勉強してて周りに教えてやりたい」ときがさ。
でもそんなのは実際教える相手がいるとふっとんじまう。
なんでかったら、そいつに聞かせるための技術（笑）てのがあるわけで。
それができないからおじゃばは延々とここで「俺偉い」続けてるんだよな。
えらいえらい。よく勉強したね。がんばったね。
そもそも言語規定にない振る舞いをあてにして実装する方がおかしいだろ。こういうのも癖っていうのか？
癖って、このコンパイラの吐くアセンブリはインライン関数をうまく展開してくれないとか、farジャンプ
を使いすぎるとか、ある最適化指定でテーブルジャンプを使いがちとか、ある条件で特定のレジスタしか使
わないとかそんな話じゃないの？
癖って、このコンパイラの吐くアセンブリはインライン関数をうまく展開してくれないとか、farジャンプ
を使いすぎるとか、ある最適化指定でテーブルジャンプを使いがちとか、ある条件で特定のレジスタしか使
わないとかそんな話じゃないの？
俺はおじゃばは悩んでるんじゃないかと思うよ。
Sun Studio11がでたくらいで、自分のこと「おじゃば」だろ、
COBOLも一応やって、CでDB絡んでクラサバもやってる、
でも組み込みまともにやったことないからアセンブラはしらない。
自分のスキルが迷走してて、でそれでも年行ったから部下がついたかと思えば
メールでしかまともに話してくれない。
そんな奴がマ板に救いを求めてるんだ。助けてやろうぜ。みんな。
Sun Studio11がでたくらいで、自分のこと「おじゃば」だろ、
COBOLも一応やって、CでDB絡んでクラサバもやってる、
でも組み込みまともにやったことないからアセンブラはしらない。
自分のスキルが迷走してて、でそれでも年行ったから部下がついたかと思えば
メールでしかまともに話してくれない。
そんな奴がマ板に救いを求めてるんだ。助けてやろうぜ。みんな。
おじゃばは悲しいくらいに低い山登ってるね。それが悲しいね。
>>35
評価順序の話は、コンパイラの癖というよりは、まずは、
「言語使用で不定とされているもの」、という話題だろうね。
不定とされている以上、コンパイルする以前の問題だと捉えるべきだろうね。
本来は、オブジェクトファイルの中を覗ける人間が呼ぶんだろうね、
ライブラリもリンカも関係のない、コンパイル作業の特徴を、コンパイラの癖と。
俺はまったくよく分からないけどさ。
>>35
評価順序の話は、コンパイラの癖というよりは、まずは、
「言語使用で不定とされているもの」、という話題だろうね。
不定とされている以上、コンパイルする以前の問題だと捉えるべきだろうね。
本来は、オブジェクトファイルの中を覗ける人間が呼ぶんだろうね、
ライブラリもリンカも関係のない、コンパイル作業の特徴を、コンパイラの癖と。
俺はまったくよく分からないけどさ。
間違えた。言語仕様ね。
>「関数引数の実行順序は保証されない。」
>int count = 0;
>func(++count, ++count);
そんな書き方をするなバカモノ
怪しいところはマがガードするのが作法
前置、後置という考え方を持ったままそのままぶっこむな
おじゃばのと比べれば断然こっちが正解
int count = 0;
int a = count++;
func(a, a);
結局はおじゃばが下手くそなだけ
利口な奴は最初からちゃんとガードするからな
コンパイラの癖だとか言ってごまかすなよ
>int count = 0;
>func(++count, ++count);
そんな書き方をするなバカモノ
怪しいところはマがガードするのが作法
前置、後置という考え方を持ったままそのままぶっこむな
おじゃばのと比べれば断然こっちが正解
int count = 0;
int a = count++;
func(a, a);
結局はおじゃばが下手くそなだけ
利口な奴は最初からちゃんとガードするからな
コンパイラの癖だとか言ってごまかすなよ
>>40
をいをい。。
をいをい。。
31が当たり前の指摘して、それに周りがはしゃいでいるだけだろ。
まあ、こないだの
＞簡単に言うと、実際にメモリ領域が確保されないのが定義で、確保されるのが宣言だ。
並みなわけだけど、おじゃばがどういう反応するのか楽しみだ。
・・・つーか、実際納品しているわけだよね。
同じようなミスで偶々動いて部分がある可能性があるわけで・・・、
おじゃば、そこんとこ見直ししておけよ。
まあ、こないだの
＞簡単に言うと、実際にメモリ領域が確保されないのが定義で、確保されるのが宣言だ。
並みなわけだけど、おじゃばがどういう反応するのか楽しみだ。
・・・つーか、実際納品しているわけだよね。
同じようなミスで偶々動いて部分がある可能性があるわけで・・・、
おじゃば、そこんとこ見直ししておけよ。
まぁ、処理系依存部分は癖っちゃ癖だからもう良いだろ。
が、>>24だけだと、規格から処理系依存の部分を抜き出しただけだから、
とりあえず、おじゃばに
int count = 0;
func(++count, ++count);
の場合に「どのコンパイラだとどういう動きをする」って
具体的に処理結果が変わるコンパイラの例を2、3あげてもらって
コンパイラの癖の話は終わらね？
唯一おじゃばから出てきたコンパイラ絡みの話がコレだし、
正直そろそろ飽きて来た。
が、>>24だけだと、規格から処理系依存の部分を抜き出しただけだから、
とりあえず、おじゃばに
int count = 0;
func(++count, ++count);
の場合に「どのコンパイラだとどういう動きをする」って
具体的に処理結果が変わるコンパイラの例を2、3あげてもらって
コンパイラの癖の話は終わらね？
唯一おじゃばから出てきたコンパイラ絡みの話がコレだし、
正直そろそろ飽きて来た。
>>46
ひどい自演をみた。
ひどい自演をみた。
>>46
おじゃばじゃないけど、経験レベルだが
WindowsのＣ、つーかゲイツ君とこのは素直に順番通りに動く。
でも、ヘルプに順番通りに動かないからな覚悟しておけよ！と書いてある。
所謂ＭＳクオリティ。
ソラリスはお行儀が悪いのか明記してない部分はランダムっぽい。
所謂Ｓｕｎクオリティ。
実験じゃなくて、あくまで経験レベルなんで勘弁してけろ。
漏れは、おじゃばじゃないからな。
おじゃばじゃないけど、経験レベルだが
WindowsのＣ、つーかゲイツ君とこのは素直に順番通りに動く。
でも、ヘルプに順番通りに動かないからな覚悟しておけよ！と書いてある。
所謂ＭＳクオリティ。
ソラリスはお行儀が悪いのか明記してない部分はランダムっぽい。
所謂Ｓｕｎクオリティ。
実験じゃなくて、あくまで経験レベルなんで勘弁してけろ。
漏れは、おじゃばじゃないからな。
いわゆる「ヒトが知らないことを教えたがる」人が多いマのひとを
自分がもっとひどくそういう奴であることで、すごい勢いで釣ってるのが
面白いなおじゃばは。すげーすげー。
自分がもっとひどくそういう奴であることで、すごい勢いで釣ってるのが
面白いなおじゃばは。すげーすげー。
スレタイについてだけど、
「OOが普及する」ってのは、OOを理解しているのがごく当たり前の状況って意味だよな
現場に１人か２人は存在する、ってのは普及してるとは言わないし、
OOに対応した言語を使ってるからOOを理解しているという意味でもないよな
ここで疑問なんだが、
なぜ「いや普及してる」と言い切れる奴がいるのかが不思議なんだわ
普及って言葉は、携帯電話が普及してる、とか、パソコンが普及してる、って使い方じゃん
オブジェクト指向ってよくわかりませんってな自称Java/C++技術者がごろごろいるのは
とても普及してるとは言えないでしょ
「OOが普及する」ってのは、OOを理解しているのがごく当たり前の状況って意味だよな
現場に１人か２人は存在する、ってのは普及してるとは言わないし、
OOに対応した言語を使ってるからOOを理解しているという意味でもないよな
ここで疑問なんだが、
なぜ「いや普及してる」と言い切れる奴がいるのかが不思議なんだわ
普及って言葉は、携帯電話が普及してる、とか、パソコンが普及してる、って使い方じゃん
オブジェクト指向ってよくわかりませんってな自称Java/C++技術者がごろごろいるのは
とても普及してるとは言えないでしょ
>>51
「ガソリンエンジンが普及してる」と言う白タク運転手がいるのとおなじじゃまいか。
「ガソリンエンジンが普及してる」と言う白タク運転手がいるのとおなじじゃまいか。
53 ：おじゃばさま ◆GxjxF3yEw6 ：2008/01/31(木) 20:00:03
>>31
if(条件1 && 条件2)
これで、条件2->条件1で動くコンパイラってあるのか？
俺は見たことないぞ。「&」じゃないよな？
>>39
あのさ、
func(++i, ++i);
だけど、実際こういう書き方した人がいたって話ではないぞ。引数の実行順が不定な例として出しただけだ。
不定な例に対して指導されても、こっちが恥ずかしくなるよ。つーか、ジョークか？後半見るとマジだな。
>>46
Linuxのgccが「func(2, 1);」で、VC2005が「func(2, 2);」だよ。
if(条件1 && 条件2)
これで、条件2->条件1で動くコンパイラってあるのか？
俺は見たことないぞ。「&」じゃないよな？
>>39
あのさ、
func(++i, ++i);
だけど、実際こういう書き方した人がいたって話ではないぞ。引数の実行順が不定な例として出しただけだ。
不定な例に対して指導されても、こっちが恥ずかしくなるよ。つーか、ジョークか？後半見るとマジだな。
>>46
Linuxのgccが「func(2, 1);」で、VC2005が「func(2, 2);」だよ。
おじゃばの
>これで、条件2->条件1で動くコンパイラってあるのか？
>俺は見たことないぞ。「&」じゃないよな？
ってどういう意味合いか、おじゃば以外の人教えてくれないか？
>これで、条件2->条件1で動くコンパイラってあるのか？
>俺は見たことないぞ。「&」じゃないよな？
ってどういう意味合いか、おじゃば以外の人教えてくれないか？
>>51 携帯電話の仕組みや機能すらろくに知らずに使ってる人がいっぱいいる。それと同じじゃね？
>>56
条件2が評価されたあとに条件1が評価されるってことじゃね？ 評価の順番がどっちからかという。
短絡評価をする言語だと、普通条件1からだと思うが、短絡評価しない言語の場合は、副作用のある
書き方さえしなければどっちでもいいこと。
条件2が評価されたあとに条件1が評価されるってことじゃね？ 評価の順番がどっちからかという。
短絡評価をする言語だと、普通条件1からだと思うが、短絡評価しない言語の場合は、副作用のある
書き方さえしなければどっちでもいいこと。
>関数のポインタは、sort()関数や、signal()関数などで使う。
>自分で使う場合は、パラメータによって処理を変えたい場合に、内部のテーブルにパラメータと
内部のテーブルって、共有メモリの事？
もしかしてＦのあのアホ現場？
もしそうなら、おじゃばソルジャー乙！と言って置こう。
>自分で使う場合は、パラメータによって処理を変えたい場合に、内部のテーブルにパラメータと
内部のテーブルって、共有メモリの事？
もしかしてＦのあのアホ現場？
もしそうなら、おじゃばソルジャー乙！と言って置こう。
>>56
今回はCの話だから、演算子の評価順序は && || ?: , だけは左項から右項へと
言うのが定義されているので&じゃないよな、と言ってると思われ。
おじゃばが言うと正しいモノも嘘に感じるから不思議だｗ
今回はCの話だから、演算子の評価順序は && || ?: , だけは左項から右項へと
言うのが定義されているので&じゃないよな、と言ってると思われ。
おじゃばが言うと正しいモノも嘘に感じるから不思議だｗ
>>58
なるほどね。
逆にコンパイルで順番が保証されると思ってるんだろうかおじゃばは・・・。
難癖付けるにしても最悪だな。
引数で逆に動くケースがあって自身満々に癖だ俺が直したといっておきながら、
if文はそんなケースあるのかよか・・・。
卑劣な言い方だな～（棒読み）
なるほどね。
逆にコンパイルで順番が保証されると思ってるんだろうかおじゃばは・・・。
難癖付けるにしても最悪だな。
引数で逆に動くケースがあって自身満々に癖だ俺が直したといっておきながら、
if文はそんなケースあるのかよか・・・。
卑劣な言い方だな～（棒読み）
>>53
＞Linuxのgccが「func(2, 1);」で
おじゃばは本当に技術者か？
なんだよ「Linuxのgcc」って。
ちなみにFedoraCore5入ってるgcc4.1は
#include <stdio.h>
void func(a, b){ printf("%d, %d\n", a, b); }
int main(){
int i = 0;
func(++i, ++i);
return 0;
}
で実行結果は「2, 2」だ。
出直せ。
>>59
＞内部のテーブルって、共有メモリの事？
違うと思われ。
typedef void (*funcType)(int id);
struct {
int id;
funcType func;
} tbl[] = { { 1, func1 },{ 2, func2 } };
もうCコンパイラの話止めようや。
＞Linuxのgccが「func(2, 1);」で
おじゃばは本当に技術者か？
なんだよ「Linuxのgcc」って。
ちなみにFedoraCore5入ってるgcc4.1は
#include <stdio.h>
void func(a, b){ printf("%d, %d\n", a, b); }
int main(){
int i = 0;
func(++i, ++i);
return 0;
}
で実行結果は「2, 2」だ。
出直せ。
>>59
＞内部のテーブルって、共有メモリの事？
違うと思われ。
typedef void (*funcType)(int id);
struct {
int id;
funcType func;
} tbl[] = { { 1, func1 },{ 2, func2 } };
もうCコンパイラの話止めようや。
func(++i, ++i) だと「2, 2」だけど、(当り前か)
func(i++, i++) だと「1, 0」だな。(stdcallだからこれも当り前か)
func(i++, i++) だと「1, 0」だな。(stdcallだからこれも当り前か)
あの～
func(++i,++i)；
だと引数の評価順序の話にならないんじゃないか。
a=1;
b=2;
func(++a,++b);
でfuncに 2,2 が渡るコンパイラがあったら、それはバグだろうよ。
引数の評価を全部終えてから渡さない処理系なんか見たこと無いぞ。
func(++i,++i)；
だと引数の評価順序の話にならないんじゃないか。
a=1;
b=2;
func(++a,++b);
でfuncに 2,2 が渡るコンパイラがあったら、それはバグだろうよ。
引数の評価を全部終えてから渡さない処理系なんか見たこと無いぞ。
あ、stdcallはMS仕様だった、cdeclか。ちなみに左から右へ渡すのは、Pascal呼出規約ね。
>62のコードだとたしかに 2, 2が出る、MacOSX gcc4.0.1
でも
#include <stdio.h>
void func(a, b){ printf("%d, %d¥n", a, b); }
int main(){
int i = 0;
int j,k;
func(j=++i, k=++i);
printf("%d, %d¥n",j,k);
return 0;
}
だと
2, 1
2, 1
が出る。なんか不思議。さぁアセンブリだ！
でも
#include <stdio.h>
void func(a, b){ printf("%d, %d¥n", a, b); }
int main(){
int i = 0;
int j,k;
func(j=++i, k=++i);
printf("%d, %d¥n",j,k);
return 0;
}
だと
2, 1
2, 1
が出る。なんか不思議。さぁアセンブリだ！
不思議でもなんでもないんだが...
>>68
しーっｗ黙ってなって。
しーっｗ黙ってなって。
俺ほどコンパイラの癖に悩まされたものは少ないだろう(笑)
>>コテ
おまえって、とにかく反論ありきで会話するんやな
性格も治りようがないんやろうけど、
レス打つ度に煽られ、つっこまれ、バカにされ、って毎度繰り返しやんか
自分に原因があるって散々言われとんのやからちょっと考えたらいいんとちゃうか？
別におまえがどんなに嫌われようがどうでもいいんやけどな
けど、ここまでひん曲がった奴はよう見らんわ
おまえって、とにかく反論ありきで会話するんやな
性格も治りようがないんやろうけど、
レス打つ度に煽られ、つっこまれ、バカにされ、って毎度繰り返しやんか
自分に原因があるって散々言われとんのやからちょっと考えたらいいんとちゃうか？
別におまえがどんなに嫌われようがどうでもいいんやけどな
けど、ここまでひん曲がった奴はよう見らんわ
OOについて大して触れられず100行きそうだなｗ
部下への技術指導にはOOで必要な部分だけ教えてたりする
客と話してユースケースとアクティビティ起こせるようになればいいかな～って感じ
当然言語なんて決めてないよ
客に予算が無ければVBとかで済ますし、金有るならJAVAかC+＋
やってもいいよと言う話になればC#で見積もり考えるかな
自分PGからSEになってるんでなおさら言語にこだわらない設計って大事だと思うぜ
部下への技術指導にはOOで必要な部分だけ教えてたりする
客と話してユースケースとアクティビティ起こせるようになればいいかな～って感じ
当然言語なんて決めてないよ
客に予算が無ければVBとかで済ますし、金有るならJAVAかC+＋
やってもいいよと言う話になればC#で見積もり考えるかな
自分PGからSEになってるんでなおさら言語にこだわらない設計って大事だと思うぜ
それがOOの根幹だしな
クラス分析がJavaとC++で違うとか言ってる奴がいたら、
それこそ説教もんだし
クラス分析がJavaとC++で違うとか言ってる奴がいたら、
それこそ説教もんだし
分析・設計が実装言語と関係ない。というのはOOに始まったことじゃないわな。
30年も前から同じこと言ってらぁ。
それが本当ならこんなにたくさんのプログラム言語は現れなかっただろうな。
30年も前から同じこと言ってらぁ。
それが本当ならこんなにたくさんのプログラム言語は現れなかっただろうな。
オブジェクト指向が普及してるかしてないか、調べたことは無いが、
普及していない、とするのならその原因は、
覚えるのがまんどいから
そして、
いつでも役に立つ訳ではないから
だろう。
普及していない、とするのならその原因は、
覚えるのがまんどいから
そして、
いつでも役に立つ訳ではないから
だろう。
77 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/01(金) 19:58:38
>>54
では有意義な情報を披露してくれ。
>>55
11人だな。俺が入ってないなら。
>>61
俺が直したなんて言ってないし、条件式で間違った例を出したのも俺ではない。
>>72
馬鹿にされているって意識はないな。
的を射ているのは性格の悪さだが、それはお互い様だろう？
では有意義な情報を披露してくれ。
>>55
11人だな。俺が入ってないなら。
>>61
俺が直したなんて言ってないし、条件式で間違った例を出したのも俺ではない。
>>72
馬鹿にされているって意識はないな。
的を射ているのは性格の悪さだが、それはお互い様だろう？
>>77
お前が全レスで短いときはどう返していいか悩んでるというのは皆知ってる。
お前が全レスで短いときはどう返していいか悩んでるというのは皆知ってる。
79 ：仕様書無しさん：2008/02/01(金) 20:58:50
ああ、そうだね。
スルーも多用する。
31のレスでもよく分かるな。
おじゃば（24）
>Solaris64の数値演算ライブラリの件が不評なので、有名なコンパイラの癖を紹介しよう。
>「関数引数の実行順序は保証されない。」
>結構知らない人もいるから、気をつけた方がいい。
>これなら、100%コンパイラの癖だから文句はないだろう。ただ俺が苦労したのは前者だがな
指摘(31)
>Ｑ 【不定の例】
> 不定である場合としては、どのようなものがあるか。
> * 関数呼び出しの実引数が呼び出される順序。
おじゃば（53）
>>>31
>if(条件1 && 条件2)
>これで、条件2->条件1で動くコンパイラってあるのか？
>俺は見たことないぞ。「&」じゃないよな？
なあ、おじゃば以外の人。
これってライブラリーのコンパイルの癖という発言にしか読めず。
最低限、Solarisのコンパイルの癖だとおじゃば言ってるようにしか読めないわけだが。
他の解釈ってある？
スルーも多用する。
31のレスでもよく分かるな。
おじゃば（24）
>Solaris64の数値演算ライブラリの件が不評なので、有名なコンパイラの癖を紹介しよう。
>「関数引数の実行順序は保証されない。」
>結構知らない人もいるから、気をつけた方がいい。
>これなら、100%コンパイラの癖だから文句はないだろう。ただ俺が苦労したのは前者だがな
指摘(31)
>Ｑ 【不定の例】
> 不定である場合としては、どのようなものがあるか。
> * 関数呼び出しの実引数が呼び出される順序。
おじゃば（53）
>>>31
>if(条件1 && 条件2)
>これで、条件2->条件1で動くコンパイラってあるのか？
>俺は見たことないぞ。「&」じゃないよな？
なあ、おじゃば以外の人。
これってライブラリーのコンパイルの癖という発言にしか読めず。
最低限、Solarisのコンパイルの癖だとおじゃば言ってるようにしか読めないわけだが。
他の解釈ってある？
おじゃばの処世術は「逃避」。
>>79
そこまでだと、なんか大人げないから、やめてあげなよ。
Ｃマスター〔笑〕に「オレが悪かった」いわさんでも。
いつもあんな聞きもしないのにうざってー長文書いて
自己顕示してくるおじゃばが>>77くらいなんだ。
やさしくしてあげようぜ、こわくないよってなｗ
そこまでだと、なんか大人げないから、やめてあげなよ。
Ｃマスター〔笑〕に「オレが悪かった」いわさんでも。
いつもあんな聞きもしないのにうざってー長文書いて
自己顕示してくるおじゃばが>>77くらいなんだ。
やさしくしてあげようぜ、こわくないよってなｗ
おじゃばが居ると自分よりバカが居て安心できるから
後ろ向きに生きている俺にはありがたい
後ろ向きに生きている俺にはありがたい
>Solaris64の数値演算ライブラリの件が不評なので
このスレで不評という意味合いに取れば、
コンパイラの癖という意味合いだと取れるな。
うん、おじゃばが馬鹿だと言うことはよくわかたよ。
このスレで不評という意味合いに取れば、
コンパイラの癖という意味合いだと取れるな。
うん、おじゃばが馬鹿だと言うことはよくわかたよ。
おまいら、もう旬を過ぎたが
if( func1(a++) == func2(a++) )
の場合、func1,func2の実行順序って決まってるのか？
if( func1(a++) == func2(a++) )
の場合、func1,func2の実行順序って決まってるのか？
マならせめて言語仕様くらい読めよ。どんだけずぼらだよ。
演算子の説明のとこに優先順位とあわせて結合順位の説明ないか？
演算子の説明のとこに優先順位とあわせて結合順位の説明ないか？
マならせめてスレタイくらい読めよ。どんだけずぼらだよ。
初期から一度もまともに論じたことねーだろ
何を今更KY
何を今更KY
【レス抽出】
対象スレ： OOスレ8 なぜオブジェクト指向は普及しないのか
キーワード： 未定義
抽出レス数：0
対象スレ： OOスレ8 なぜオブジェクト指向は普及しないのか
キーワード： 未定義
抽出レス数：0
F5かF10だけで十分なんでｗｗ
「なぜ～普及しないのか」ってなってんだからこれでいいんだよ。
普及してないから語り様がない。
普及してないから語り様がない。
91 ：仕様書無しさん：2008/02/02(土) 15:52:23
いや、逆じゃね。普及しすぎているから、
「なぜオブジェクト指向は普及しないのか」
といわれても語り様がない。
だから、C言語の話なんかをわいわいする。
「なぜオブジェクト指向は普及しないのか」
といわれても語り様がない。
だから、C言語の話なんかをわいわいする。
じゃあ、早すぎるけど次のスレタイは、
「なぜオブジェクト指向は空気のような存在になってしまったのか」
で。
「なぜオブジェクト指向は空気のような存在になってしまったのか」
で。
>>84
31のとこに、きちんと書いてあるぞ。
>&& という演算子は、左から右へ評価し、全てが真だった時には式全体の値を真とします。
>評価した結果が偽だった場合、そこで評価が打ち切られ、式全体の値を偽とします。
31のとこに、きちんと書いてあるぞ。
>&& という演算子は、左から右へ評価し、全てが真だった時には式全体の値を真とします。
>評価した結果が偽だった場合、そこで評価が打ち切られ、式全体の値を偽とします。
そもそも設計終わる前に製造始めなきゃならんからOOは有効じゃないと思う
んな決まりはなかったと思うが、特に技術的なノウハウが少い場合は
ウォーターフォールこそリスクが高すぎる。
人間がやることだからクリーンルームも完璧には無理だし。
ウォーターフォールこそリスクが高すぎる。
人間がやることだからクリーンルームも完璧には無理だし。
ウォーターフォールは切戻しが効かないという前提だからな。
というか、”仕切りなおし”という概念ってあったっけ？
切戻しとかと微妙に、つまりfoｒ文とGoto文くらいの違いが
あると思うんだけど。
というか、”仕切りなおし”という概念ってあったっけ？
切戻しとかと微妙に、つまりfoｒ文とGoto文くらいの違いが
あると思うんだけど。
設計上もコーディング上もgotoは御法度ということで。
但し、breakとexitは認める。永久ループはご勘弁!
但し、breakとexitは認める。永久ループはご勘弁!
わけあってJavaScriptでOOやってるが、意外といい言語だな。
スクリプト言語としての割り切り方が潔いというか、いちいち
クラス書かなくてもいいし、動的にプロパティや関数を追加でき
る手軽さがいい。言語で備えてるわけではないが、ミックスイン
も割りと簡単に実装できるし。
鯱張って大仰なクラスをしこしこ書くより、クロージャーでさくっ
てやっちゃった方が手っ取り早くてメンテも楽。
いやぁ今まで毛嫌いしててゴメンって感じ。
スクリプト言語としての割り切り方が潔いというか、いちいち
クラス書かなくてもいいし、動的にプロパティや関数を追加でき
る手軽さがいい。言語で備えてるわけではないが、ミックスイン
も割りと簡単に実装できるし。
鯱張って大仰なクラスをしこしこ書くより、クロージャーでさくっ
てやっちゃった方が手っ取り早くてメンテも楽。
いやぁ今まで毛嫌いしててゴメンって感じ。
>>100 そのわけ教えてくれ、興味しんしんだ
聞き流すことのできないヒトのスレはここですか？
ｴﾛｲ人教えて
クラス分析をやったことが無い初心者なんだけど
事前資料にこういうのがあると便利だぞ、とか、
こういうのは用意しとけってなものってある？
クラス分析をやったことが無い初心者なんだけど
事前資料にこういうのがあると便利だぞ、とか、
こういうのは用意しとけってなものってある？
>101 うちの会社にもAjaxの波が押し寄せてきたというだけのこと。
>102 確かに。仕様の共通化が進んでいつのまにかかなり使い易くなってたんだな。
>102 確かに。仕様の共通化が進んでいつのまにかかなり使い易くなってたんだな。
>>105
ｴﾛくないけど、対象の理解と実装上の制約。あと予算。
ｴﾛくないけど、対象の理解と実装上の制約。あと予算。
ajax の j って javascript の j でしょ。
MSならVBScriptでできるだろうからAVAXとでもいうのか。
ECMAScriptならAEAXか。
MSならVBScriptでできるだろうからAVAXとでもいうのか。
ECMAScriptならAEAXか。
普及してないのか？
ハード屋なのに二日に一度は毎日クラスライブラリの仕様を見たりメソッドが
どうの継承がどうのという話をしてるんだが
ま、学問として勉強したことはないので勘違いしてるかもしれないけど
ハード屋なのに二日に一度は毎日クラスライブラリの仕様を見たりメソッドが
どうの継承がどうのという話をしてるんだが
ま、学問として勉強したことはないので勘違いしてるかもしれないけど
>>108
MSでもJavaScriptでできるし、JavaScriptはECMAScriptの実装の一つ。
MSでもJavaScriptでできるし、JavaScriptはECMAScriptの実装の一つ。
学校の勉強で本格的にＯＯを使いこなせるレベルまで教育している所は稀。
新人教育でも同じようなもの（いやもっと酷いか）
なんやかんやで、新人が頭麻痺する頃にコーディングするわけで、学校で習ったレベルの
構造化的に組む。
経験積めば数年後にはある程度ＯＯを使いこなせるが、結局多くは我流なわけで、
はたからみれば、大差なくても語ると経験論からくるヒヅミで、
議論の際にドーデも良いことを喚く様になる。
新人教育でも同じようなもの（いやもっと酷いか）
なんやかんやで、新人が頭麻痺する頃にコーディングするわけで、学校で習ったレベルの
構造化的に組む。
経験積めば数年後にはある程度ＯＯを使いこなせるが、結局多くは我流なわけで、
はたからみれば、大差なくても語ると経験論からくるヒヅミで、
議論の際にドーデも良いことを喚く様になる。
おじゃばを擁護してみよう。
以前からの数値演算ライブラリの件とか
Solaris64とかは関係なく
おじゃば的にコンパイルの癖で言いたかったのは
「関数引数の実行順序は保証されない。」
という事だけなんだろう。
後の発言からそうだと理解したが。
以前からの数値演算ライブラリの件とか
Solaris64とかは関係なく
おじゃば的にコンパイルの癖で言いたかったのは
「関数引数の実行順序は保証されない。」
という事だけなんだろう。
後の発言からそうだと理解したが。
関数引数の順序は大抵の言語(C,C++含む)は仕様で定義されてるし、
言語によっては明示的に呼出規約を指定することもできる。
C++でWindowsAPIを直に扱ってる人には当り前の話なんだが。
逆に保証されないという言語があるんなら教えて欲しい。
言語によっては明示的に呼出規約を指定することもできる。
C++でWindowsAPIを直に扱ってる人には当り前の話なんだが。
逆に保証されないという言語があるんなら教えて欲しい。
おじゃばってあれだけ冗長な文章を書いていながら
不思議と後出しの情報が多すぎるよね
単に情報伝達が下手で伝えたいことが書けていないのか
後から繕おうとして付け足して破綻してるのか
どっちにしろあらゆる意味でダメだけど
不思議と後出しの情報が多すぎるよね
単に情報伝達が下手で伝えたいことが書けていないのか
後から繕おうとして付け足して破綻してるのか
どっちにしろあらゆる意味でダメだけど
もうその話題はいいべ
んだな
ん？呼出規約じゃなくて評価順序の話か。そりゃ言語仕様には無いだろうさ。
そもそも、そんな評価順序をあてにしてコード書くのが間違っとる。
当り前だし、常識。つか、この話はもういいな。
そもそも、そんな評価順序をあてにしてコード書くのが間違っとる。
当り前だし、常識。つか、この話はもういいな。
もうその話題はいいべ
んだな
クラスと継承位で十分だと思うの漏れだけ？
情けない事に下手にややこしい事しても設計能力が追いつかないだけなんだけど。
情けない事に下手にややこしい事しても設計能力が追いつかないだけなんだけど。
インターフェース
んだんだ
テンプレートパタンとMVCを押さえとけばなんとかなるべ
外部イテレータは便利
MVCってGUIじゃないの？
>>105
DFDやERDは作った方がいい
DFDやERDは作った方がいい
>>122
俺も同じ。ライブラリ使うだけで済む仕事ならそれで困らないし、
やらなきゃいけない事が実現できるなら道具はなんでもいい
「このぐらいやって初めてOOPをやってると言える」
という目安になるリンクでも貼っといてくれればいいんだけどね
俺も同じ。ライブラリ使うだけで済む仕事ならそれで困らないし、
やらなきゃいけない事が実現できるなら道具はなんでもいい
「このぐらいやって初めてOOPをやってると言える」
という目安になるリンクでも貼っといてくれればいいんだけどね
休日は餌の仕込みに余念がないスレ住人、乙。
最近、喰い付き悪いからさ。
悪食の癖に選びやがるから・・・。
そのうち、飢えさせる必要が出てくるかもな。
悪食の癖に選びやがるから・・・。
そのうち、飢えさせる必要が出てくるかもな。
ウォーターフォール最強だろ？
資格が無いから「オレオレが多い」「俺は正しい、お前はわかってない」とかが出てくるんだろ
誰が言いだしっぺとかそんなんどうでもいいから、
ちゃんと制定しないと「～～指向」祭りはおわらねーし
誰が言いだしっぺとかそんなんどうでもいいから、
ちゃんと制定しないと「～～指向」祭りはおわらねーし
とか言ってる時点でわかってねーし
ﾊｲﾊｲﾊﾞﾛｽﾊﾞﾛｽ
俺はわかってないことがわかってる
だからおじゃばよりは偉い
だからおじゃばよりは偉い
おじゃばのレスあった奴罰ゲームな。
おじゃばにちゃんとレス返す事。
おじゃばにちゃんとレス返す事。
('A`)ﾉ ﾏﾝﾄﾞｸｾ
もうさあ、完全スルーでいいじゃん
>>137 吹いたｗ
141 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/04(月) 20:51:06
>>79
俺はスルーを多用しているつもりはない。
79がスルーしたと思うのは、他の人が回答してしまったため俺が答えなかった物だろう。
31に対しては60が答えている。
癖の定義については、俺と同意見の人もいれば違う人もいる。
定義の違いについて議論しても無意味なので、基本的に内容のある書き込みにしか回答しない。
ちなみにスルーしてるのは、俺の方ではないだろう。
perlのSSH組み込み方法を教えてくれと言うのと、判定の&&と||は実行順序が決まっているだろうと言うのは
スルーされている。まあ、前者は答えられないだろうし、後者は自滅ミス（31の提示した資料に記述あり）
なので話題にしたくないのは分かるがな。
俺はスルーを多用しているつもりはない。
79がスルーしたと思うのは、他の人が回答してしまったため俺が答えなかった物だろう。
31に対しては60が答えている。
癖の定義については、俺と同意見の人もいれば違う人もいる。
定義の違いについて議論しても無意味なので、基本的に内容のある書き込みにしか回答しない。
ちなみにスルーしてるのは、俺の方ではないだろう。
perlのSSH組み込み方法を教えてくれと言うのと、判定の&&と||は実行順序が決まっているだろうと言うのは
スルーされている。まあ、前者は答えられないだろうし、後者は自滅ミス（31の提示した資料に記述あり）
なので話題にしたくないのは分かるがな。
142 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/04(月) 21:11:34
>>113
C言語の関数引数の実行順序は定義されていないし、コンパイラによって違うという例も提示されているが。
実行順序を明示的に指定できるのか？どうやるんだ？
>>114
俺の情報が後出しと思えるのは、俺の基本や常識を省略しているためだろう。
perlのコンパイルが分からなかったり、関数引数の問題点を演算子優先度と間違えたり、
関数ポインタを共有メモリに入れるのかと言っている人は、典型的な勉強不足だ。
ある程度の経験者ならそんな間違いはしない。
実際、あまりの内容に耐えきれずに、突っ込みを入れる人が続出しただろう。
C言語の関数引数の実行順序は定義されていないし、コンパイラによって違うという例も提示されているが。
実行順序を明示的に指定できるのか？どうやるんだ？
>>114
俺の情報が後出しと思えるのは、俺の基本や常識を省略しているためだろう。
perlのコンパイルが分からなかったり、関数引数の問題点を演算子優先度と間違えたり、
関数ポインタを共有メモリに入れるのかと言っている人は、典型的な勉強不足だ。
ある程度の経験者ならそんな間違いはしない。
実際、あまりの内容に耐えきれずに、突っ込みを入れる人が続出しただろう。
>>143
もうしばらくそっとしといてやれよ、かわいそうだろ。
もうしばらくそっとしといてやれよ、かわいそうだろ。
ファイルに固定長レコードが複数行あって、
その内容をＤＢに登録する場合、
どういうクラス分析をすればいい？
エロい人教えて
その内容をＤＢに登録する場合、
どういうクラス分析をすればいい？
エロい人教えて
>>144
おじゃばは、敗北を認めない男だからしょうがないよ。
自分の事かわいそうだとおもってないんだし。
演算子どじったなあぁとか。
内部テーブルは関数マトリクス表じゃないか脊髄反射いくない！それも間違いだけど。
とか謝罪しておこうと思った。
やっぱミスはミスと認めないと。
で、24のどこがコンパイルの癖なんだい。
単なるバグに見えるんだけど。
おじゃばは、敗北を認めない男だからしょうがないよ。
自分の事かわいそうだとおもってないんだし。
演算子どじったなあぁとか。
内部テーブルは関数マトリクス表じゃないか脊髄反射いくない！それも間違いだけど。
とか謝罪しておこうと思った。
やっぱミスはミスと認めないと。
で、24のどこがコンパイルの癖なんだい。
単なるバグに見えるんだけど。
>>142
関数引数の実行順序というか、スタックへ積む前の「評価順序」は定義されていない
場合が多いな、というか不定ということか。つまり仕様で明確に定義されておらず、
実装者次第ということ。これはポータビリティを考慮すると問題になるが、同一環境
の同一言語ではランダムなわけではないから定義されているともいえる。それでもそ
れに依存するのは良いことではないが。
そして、関数引数の呼出規約。つまり引数の渡し方（スタックへ積む順序）は仕様に
定義されている。また、明示的に指定できる言語もある。これが定義されてないとラ
イブラリなんて作れない。
評価順序と呼出規約は別物でここがズレている。おじゃばが曖昧なオレオレ用語を遣
うからよく誤解がおきるんだよ。
早とちりしないように人の文章は良く読む。誤解を与えないように技術的な言葉は正
しく使う。講釈たれたるなら、これは基本中の基本。
関数引数の実行順序というか、スタックへ積む前の「評価順序」は定義されていない
場合が多いな、というか不定ということか。つまり仕様で明確に定義されておらず、
実装者次第ということ。これはポータビリティを考慮すると問題になるが、同一環境
の同一言語ではランダムなわけではないから定義されているともいえる。それでもそ
れに依存するのは良いことではないが。
そして、関数引数の呼出規約。つまり引数の渡し方（スタックへ積む順序）は仕様に
定義されている。また、明示的に指定できる言語もある。これが定義されてないとラ
イブラリなんて作れない。
評価順序と呼出規約は別物でここがズレている。おじゃばが曖昧なオレオレ用語を遣
うからよく誤解がおきるんだよ。
早とちりしないように人の文章は良く読む。誤解を与えないように技術的な言葉は正
しく使う。講釈たれたるなら、これは基本中の基本。
スルースキルをいつまでたっても身につけられないやつが大杉
ていうか、おじゃばと絡むスレだしな。
おじゃばスルーするならこのスレ自体もういらんだろ。
おじゃばスルーするならこのスレ自体もういらんだろ。
>評価順序と呼出規約は別物でここがズレている。おじゃばが曖昧なオレオレ用語を遣
>うからよく誤解がおきるんだよ。
ついでに言葉足らず。言い方も乱暴で分かりにくい。話題のワープもある。
結局、おじゃばは関数の評価順序について24で薀蓄垂れたいだけで、
それに付いて褒めてほしいだけだろ。
後は付けたし。
ネギ食え。ネギ。
>うからよく誤解がおきるんだよ。
ついでに言葉足らず。言い方も乱暴で分かりにくい。話題のワープもある。
結局、おじゃばは関数の評価順序について24で薀蓄垂れたいだけで、
それに付いて褒めてほしいだけだろ。
後は付けたし。
ネギ食え。ネギ。
>perlのコンパイル
perl知らないんだけどインタプリタじゃないの？
perl知らないんだけどインタプリタじゃないの？
やっべ 罰ゲームか・・・
> 内容のある書き込みにしか回答しない
嘘吐き
> スルーしてるのは、俺の方ではないだろう。
こういうところはさりげなく「だろう」とか使いますねアナタ
> ～典型的な勉強不足
その直前のネタが勉強不足以前に無知丸出しなことはスルーしておいてあげるけど
> 俺の基本や常識を省略
ひとに伝達するうえでコレを省略したら意味ねーだろボケ
長々と書いてそこを省略してるとか技術者として致命的に
> 内容のある書き込みにしか回答しない
嘘吐き
> スルーしてるのは、俺の方ではないだろう。
こういうところはさりげなく「だろう」とか使いますねアナタ
> ～典型的な勉強不足
その直前のネタが勉強不足以前に無知丸出しなことはスルーしておいてあげるけど
> 俺の基本や常識を省略
ひとに伝達するうえでコレを省略したら意味ねーだろボケ
長々と書いてそこを省略してるとか技術者として致命的に
最後省略しちゃらめぇ
あぼーん多すぎ
おまえのあぼーんなんてしらね～よ
おじゃばは、なぜいつまでたっても自分がまともに相手にされないのかとか、
会社の奴にメールでしか会話してもらえないのはどうしてかとか
いい歳して真剣に考えられないんだろうか？
自己愛が強すぎるんだろうかねぇ
会社の奴にメールでしか会話してもらえないのはどうしてかとか
いい歳して真剣に考えられないんだろうか？
自己愛が強すぎるんだろうかねぇ
現実を直視することから逃げてるんだと思うよ
会社説明会行ったらJavaメインだったので入社止めた
おじゃばに遭遇する可能性に反射的に行動した
おじゃばに遭遇する可能性に反射的に行動した
160 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/05(火) 19:09:30
>>143
53で提示済み。
>>146
俺は敗北を認める男だよ。つまらないプライドはないから。
ただ今までここでは2回しか敗北した事はないな。
3行目～6行目はよくわからん。独り言か？
あと、コンパイラのバグもライブラリのバグも、癖だと思っている。
>>147
俺は実行順序の話をしているのだが。ソース見て分からないのか？
あとそれに依存するプログラムを書けなんて言ってないぞ。間違えやすいから気をつけろと言っている。
だからと言って、俺のサンプル通りに書く奴はいないぞ。間違えやすい例を示そうか？
C言語よりメンバー変数のあるC++で間違えやすい。
TableData tbl;
func(tbl.getId(), tbl.getName());
もしgetId()とgetName()内で、共通のメンバー変数にアクセスしていて、その処理がアクセス順序に
依存する場合問題が発生する。
147はfunc(++i, ++i)を見た時に、ここまで想像出来たかな？
ところで、C言語で関数引数の実行順序を指定する方法はどうなんだ？
53で提示済み。
>>146
俺は敗北を認める男だよ。つまらないプライドはないから。
ただ今までここでは2回しか敗北した事はないな。
3行目～6行目はよくわからん。独り言か？
あと、コンパイラのバグもライブラリのバグも、癖だと思っている。
>>147
俺は実行順序の話をしているのだが。ソース見て分からないのか？
あとそれに依存するプログラムを書けなんて言ってないぞ。間違えやすいから気をつけろと言っている。
だからと言って、俺のサンプル通りに書く奴はいないぞ。間違えやすい例を示そうか？
C言語よりメンバー変数のあるC++で間違えやすい。
TableData tbl;
func(tbl.getId(), tbl.getName());
もしgetId()とgetName()内で、共通のメンバー変数にアクセスしていて、その処理がアクセス順序に
依存する場合問題が発生する。
147はfunc(++i, ++i)を見た時に、ここまで想像出来たかな？
ところで、C言語で関数引数の実行順序を指定する方法はどうなんだ？
今日はいつもの電波が足りないぞ
もっとがんばれよ
もっとがんばれよ
| ∧ ∧
|/ ヽ ./ .∧
| ｀､ / ∧
| ￣￣￣ ヽ
|￣￣超火曜日￣￣￣）
|￣￣￣￣￣￣￣￣￣.＼
|ヽ-=・=-′ ヽ-=・=- / やあ
|:: ＼＿＿_／ /
|::::::: ＼／ /
|/ ヽ ./ .∧
| ｀､ / ∧
| ￣￣￣ ヽ
|￣￣超火曜日￣￣￣）
|￣￣￣￣￣￣￣￣￣.＼
|ヽ-=・=-′ ヽ-=・=- / やあ
|:: ＼＿＿_／ /
|::::::: ＼／ /
163 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/05(火) 19:33:46
>>150
話が通じている人もいるぞ。それはどう説明する？
>>151
perl自体のコンパイルの話だよ。前スレ後半の俺の書き込み見てみな。
>>152-159
オマエラ、本当に無意味な書き込みが多いな。煽るにしても技術的に煽ってみろよ。
第一、俺が提示したC言語マスターの条件だけど、152-159の中であれ全部クリアしている人いるのか？
簡単だとか初心者だとか言っていて、間違っていては本当に恥ずかしすぎるぞ。
マスターしていると言える挑戦者は、ID付けて書き込みしてみろ。俺が判定してやるよ。
話が通じている人もいるぞ。それはどう説明する？
>>151
perl自体のコンパイルの話だよ。前スレ後半の俺の書き込み見てみな。
>>152-159
オマエラ、本当に無意味な書き込みが多いな。煽るにしても技術的に煽ってみろよ。
第一、俺が提示したC言語マスターの条件だけど、152-159の中であれ全部クリアしている人いるのか？
簡単だとか初心者だとか言っていて、間違っていては本当に恥ずかしすぎるぞ。
マスターしていると言える挑戦者は、ID付けて書き込みしてみろ。俺が判定してやるよ。
│
J
∩＿∩ ∩＿∩
（・(ｪ)・ ） （ ・(ｪ)・）
J
∩＿∩ ∩＿∩
（・(ｪ)・ ） （ ・(ｪ)・）
>>163
こわくないから、素直になりなよ。
君が思ってるより、みんなやさしいんだから。
「ごめんなさい」と「ありがとう」がちゃんと言えれば
できるできないじゃなくても人は上手くつきあえるんだよ。
なにも自分が上だとか下だとかにこだわらなくてもいいんだ。
こわがらなくていいから。
こわくないから、素直になりなよ。
君が思ってるより、みんなやさしいんだから。
「ごめんなさい」と「ありがとう」がちゃんと言えれば
できるできないじゃなくても人は上手くつきあえるんだよ。
なにも自分が上だとか下だとかにこだわらなくてもいいんだ。
こわがらなくていいから。
＞2回しか敗北した事はないな。
自分が間違ってることに気付かないとか哀れ過ぎ
自分が間違ってることに気付かないとか哀れ過ぎ
この板でID付ける方法があるなら教えていただきたい
まさかIDってトリップのことじゃないよね？ ね？
まさかIDってトリップのことじゃないよね？ ね？
ライブラリのバグをコンパイラの癖と言い張る人間に何を言っても無駄。
Z80と8085アセンブラならマスターなんだけどなｗ
そもそも日本人は連携チーム作業が下手。
「俺はここからここまで。オマエはそこから向こうまで」 ←これがダメ
「俺とオマエでこことそこやろう」 ←これOK
人の上に立って、人を動かすのも下手。
「誠意があるなら残業くらい苦じゃないはずだ！ な？ それにここは俺を助けると思って…」
有能な奴はいるんだけど、そういう連中は職人気取りになる。
君は職人じゃなくて技術者だろう、と。
「俺はここからここまで。オマエはそこから向こうまで」 ←これがダメ
「俺とオマエでこことそこやろう」 ←これOK
人の上に立って、人を動かすのも下手。
「誠意があるなら残業くらい苦じゃないはずだ！ な？ それにここは俺を助けると思って…」
有能な奴はいるんだけど、そういう連中は職人気取りになる。
君は職人じゃなくて技術者だろう、と。
>>160
>>53であげた例について、>>62では、
おじゃばの言う「Linuxのgcc」では「func(2, 2);」と動いた、
といわれてるんだが、それについて何も無いのか？
何も無いなら「おじゃば提示した例が間違えている」のだが、
それでも「提示できた」ことになるのかね？
>>53であげた例について、>>62では、
おじゃばの言う「Linuxのgcc」では「func(2, 2);」と動いた、
といわれてるんだが、それについて何も無いのか？
何も無いなら「おじゃば提示した例が間違えている」のだが、
それでも「提示できた」ことになるのかね？
>>160
>あと、コンパイラのバグもライブラリのバグも、癖だと思っている。
まあ、これは平行線なのでいいとして、
>3行目～6行目はよくわからん。独り言か？
ああ、独り言だ、スルーしろよ。
確認なんだが、
>Solaris64の数値演算ライブラリの件が不評なので、有名なコンパイラの癖を紹介しよう。
>「関数引数の実行順序は保証されない。」
Solaris64でも無くて、数値演算ライブラリでもなくて普通にC言語の癖と認識して言ったのか？
ついでに、147じゃないが
>俺は実行順序の話をしているのだが。ソース見て分からないのか？
呼出規約同じで実行順序が違う場合は2,1→1,2か1,2→2,1になった場合。2.2は変わらず。
呼出規約が違って実行順序が同じ又は違う場合。2,1→2.2か2.2→2.1。
じゃねーか？自信全くないんで、審議しといてくれ。
>あと、コンパイラのバグもライブラリのバグも、癖だと思っている。
まあ、これは平行線なのでいいとして、
>3行目～6行目はよくわからん。独り言か？
ああ、独り言だ、スルーしろよ。
確認なんだが、
>Solaris64の数値演算ライブラリの件が不評なので、有名なコンパイラの癖を紹介しよう。
>「関数引数の実行順序は保証されない。」
Solaris64でも無くて、数値演算ライブラリでもなくて普通にC言語の癖と認識して言ったのか？
ついでに、147じゃないが
>俺は実行順序の話をしているのだが。ソース見て分からないのか？
呼出規約同じで実行順序が違う場合は2,1→1,2か1,2→2,1になった場合。2.2は変わらず。
呼出規約が違って実行順序が同じ又は違う場合。2,1→2.2か2.2→2.1。
じゃねーか？自信全くないんで、審議しといてくれ。
>>172
う～ん、確かにfunc(2,1)になるコンパイラを示さないと
本人が「有名な」コンパイラの癖だと言ってる裏がとれないなぁ、
「有名な」コンパイラの癖なんだから、ごろごろしてるんだろうなｗ
俺は「明らかに勉強不足」だから、そんなコンパイラは知らないんだけどさ。
う～ん、確かにfunc(2,1)になるコンパイラを示さないと
本人が「有名な」コンパイラの癖だと言ってる裏がとれないなぁ、
「有名な」コンパイラの癖なんだから、ごろごろしてるんだろうなｗ
俺は「明らかに勉強不足」だから、そんなコンパイラは知らないんだけどさ。
バグ製造マスター（笑）？
>>176
略してバカマスかｗ
略してバカマスかｗ
俺は171だが、あーもぉ、めんどうせぇな。おじゃば読解力ないのかよ。
あーめんどくせぇ。
おじゃばの>>24のカキコより。
>int count = 0;
>func(++count, ++count);
>とあった場合、
>コンパイラによっては、
>func(2, 1);
>で渡る物もあれば、
>func(2, 2);
>で渡る物もある。
ここで「渡る」と表現してるから、「評価順序」というより、コールスタックへの渡し方、
つまり「呼出規約」のことともとれる。実際俺はその時そう思った。
まぁ「関数引数の実行順序」という表現もしてるので、これが「評価順序」のことと察する
ことができればよかったんだが、俺は関数引数を渡す順序と考えてしまった。
だから、>>171で、（「引数の実行順序」などという誤解を生むような）オレオレ用語
を使うなと書いてる。
あーめんどくせぇ。
おじゃばの>>24のカキコより。
>int count = 0;
>func(++count, ++count);
>とあった場合、
>コンパイラによっては、
>func(2, 1);
>で渡る物もあれば、
>func(2, 2);
>で渡る物もある。
ここで「渡る」と表現してるから、「評価順序」というより、コールスタックへの渡し方、
つまり「呼出規約」のことともとれる。実際俺はその時そう思った。
まぁ「関数引数の実行順序」という表現もしてるので、これが「評価順序」のことと察する
ことができればよかったんだが、俺は関数引数を渡す順序と考えてしまった。
だから、>>171で、（「引数の実行順序」などという誤解を生むような）オレオレ用語
を使うなと書いてる。
...続き
>あとそれに依存するプログラムを書けなんて言ってないぞ。間違えやすいから気をつけろと言っている。
俺はどこにも、「おじゃばがそれに依存するプログラムを書けなんて言った」とは書いてない。
>147はfunc(++i, ++i)を見た時に、ここまで想像出来たかな？
俺が想像したのは上で書いたとおり。おじゃば用語に対する想像力が足りなかったのは認める。
>ところで、C言語で関数引数の実行順序を指定する方法はどうなんだ？
「C言語で関数引数の実行順序を指定する方法」なぞ知らんが、
「C言語で関数引数の呼出規約を指定する方法」については、
ttp://ja.wikipedia.org/wiki/%E5%91%BC%E5%87%BA%E8%A6%8F%E7%B4%84
でも読め。
ちなみに、今はどうか知らんが、C++Builderでは、__cdecl、__pascal、__fastcall、
__stdcallといったキーワードを指定して、呼出規約を明示的に指定できるようになってた。
繰り返すが頼むから言葉は正しく使ってくれ。技術用語については特に。
あぁ、めんどくせぇ...
>あとそれに依存するプログラムを書けなんて言ってないぞ。間違えやすいから気をつけろと言っている。
俺はどこにも、「おじゃばがそれに依存するプログラムを書けなんて言った」とは書いてない。
>147はfunc(++i, ++i)を見た時に、ここまで想像出来たかな？
俺が想像したのは上で書いたとおり。おじゃば用語に対する想像力が足りなかったのは認める。
>ところで、C言語で関数引数の実行順序を指定する方法はどうなんだ？
「C言語で関数引数の実行順序を指定する方法」なぞ知らんが、
「C言語で関数引数の呼出規約を指定する方法」については、
ttp://ja.wikipedia.org/wiki/%E5%91%BC%E5%87%BA%E8%A6%8F%E7%B4%84
でも読め。
ちなみに、今はどうか知らんが、C++Builderでは、__cdecl、__pascal、__fastcall、
__stdcallといったキーワードを指定して、呼出規約を明示的に指定できるようになってた。
繰り返すが頼むから言葉は正しく使ってくれ。技術用語については特に。
あぁ、めんどくせぇ...
すまん、>>178でかいた、「俺は171だが」は「俺は147だが」の間違い。
あぁめんどくせぇ、なぜ俺がこんな目に。もぉおじゃばとは関わりたくない。
俺がいつもの俺でなくなっていく...もう今日は寝る。
あぁめんどくせぇ、なぜ俺がこんな目に。もぉおじゃばとは関わりたくない。
俺がいつもの俺でなくなっていく...もう今日は寝る。
おじゃばは>66についてはどう説明するんだろう？
あたりまえっちゃあたりまえなんだけどな。
あたりまえっちゃあたりまえなんだけどな。
OOの話はどこ行った？
天の彼方に行った。
ねえみんな、OOっていう星を追いかけてみないか？
ねえみんな、OOっていう星を追いかけてみないか？
>>160
＞ もしgetId()とgetName()内で､共通のﾒﾝﾊﾞｰ変数にｱｸｾｽしていて､その処理がｱｸｾｽ順序に
＞ 依存する場合問題が発生する｡
＞ 147はfunc(++i, ++i)を見た時に､ここまで想像出来たかな?
147じゃないけど、『GetIDとGetNameがアクセスする』共通メンバーで、
アクセス順序に依存するようなメンバーって何？
例だからメソッド名とかは適当、ってことなら別にいいんだけど。
＞ もしgetId()とgetName()内で､共通のﾒﾝﾊﾞｰ変数にｱｸｾｽしていて､その処理がｱｸｾｽ順序に
＞ 依存する場合問題が発生する｡
＞ 147はfunc(++i, ++i)を見た時に､ここまで想像出来たかな?
147じゃないけど、『GetIDとGetNameがアクセスする』共通メンバーで、
アクセス順序に依存するようなメンバーって何？
例だからメソッド名とかは適当、ってことなら別にいいんだけど。
固定観念にとらわれるな。おじゃばのために一生懸命に想像力を働かせるんだ。
get系のメソッドで副作用おこしちゃダメだろとか考えた時点で負けだからな。
get系のメソッドで副作用おこしちゃダメだろとか考えた時点で負けだからな。
とりあえずおじゃばが「副作用」なる言葉を知らんことは想像できた
何を今更
> 俺の基本や常識を省略しているためだろう
こんな頭の悪い言い訳で誤魔化したつもりになってる時点で底が知れているわけだが
> 俺の基本や常識を省略しているためだろう
こんな頭の悪い言い訳で誤魔化したつもりになってる時点で底が知れているわけだが
188 ： ◆3TEx.sX7iI ：2008/02/06(水) 02:20:16
マスター（自称）です
俺も、今度から糞ライブラリにあたったら「コンパイラの癖」だと思うことにしよう。
「俺ほどコンパイラの癖に悩まされた奴はいない」
...ケータイやったことあれば誰でも言えそうだな...
「俺ほどコンパイラの癖に悩まされた奴はいない」
...ケータイやったことあれば誰でも言えそうだな...
とりあえずおじゃばが「不定」と「未定義」の区別を知らんことも想像できた
スレタイ無視の荒らしに釣られて荒らし化するスレはここですか？
ﾃﾗｷﾓｽ
194 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/06(水) 20:22:44
>>172
172は62か？そうなら俺が試したのを教えよう。RedHatとMiracleとMontavistaだ。
ちなみに上記は、func(2, 1)だぞ。func(2, 2)はVC2005。
詳細のバージョンは機密に引っ掛かるので、非公開にしておく。
62でないなら、グタグタ言う前に試してみろ。
>>173
何が言いたいのか、聞きたいのかよくわからんな。
とりあえずVC2005で呼び出し規約をcdeclにしても、func(2, 2)に変化はなかった。
>>174
結構、知らなかった人が多いようだな。よかったな勉強になって。
>>178
オレオレ用語と言うより、178のソース読解不足だろ。++countを使っている意味が分かってない。
あと、呼び出し規約で結果に変化があるか試してみた。VC2005はfunc(2, 2)で変化無し。
gccは呼び出し規約の変更方法が分からない。どうやるんだ？
172は62か？そうなら俺が試したのを教えよう。RedHatとMiracleとMontavistaだ。
ちなみに上記は、func(2, 1)だぞ。func(2, 2)はVC2005。
詳細のバージョンは機密に引っ掛かるので、非公開にしておく。
62でないなら、グタグタ言う前に試してみろ。
>>173
何が言いたいのか、聞きたいのかよくわからんな。
とりあえずVC2005で呼び出し規約をcdeclにしても、func(2, 2)に変化はなかった。
>>174
結構、知らなかった人が多いようだな。よかったな勉強になって。
>>178
オレオレ用語と言うより、178のソース読解不足だろ。++countを使っている意味が分かってない。
あと、呼び出し規約で結果に変化があるか試してみた。VC2005はfunc(2, 2)で変化無し。
gccは呼び出し規約の変更方法が分からない。どうやるんだ？
いつまでこのネタひっぱるつもりなんだよ
どう動くか不明なコードを書いてる時点で終わってる
それだけのこと
もういいだろ、このネタは
どう動くか不明なコードを書いてる時点で終わってる
それだけのこと
もういいだろ、このネタは
どうせOOネタやっても盛りあがらんけどな
オブジェクト指向って名前が普及しない一番の要因
なんも知らん人からすると全然検討つかんし
考える気も起らんだろうな
なんも知らん人からすると全然検討つかんし
考える気も起らんだろうな
おじゃばの脳も停滞してきたな
もっと頑張らないとおじゃばスレが落ちるぞ
もっと頑張らないとおじゃばスレが落ちるぞ
最初に名前つけた奴が失敗したってことだな
意味不明すぎて技術者からも敬遠される
それがいいこととは思わないけどね
意味不明すぎて技術者からも敬遠される
それがいいこととは思わないけどね
普及してるからこそ、興味を持つって人も多いんじゃないか？
gccもまともに扱えんでマスター(笑)かよ
冗談は顔だけにせーや
冗談は顔だけにせーや
ｵﾗｲﾘｰのmake買ってきたから俺もマスターだ
おらいりーのmake俺ももってる。
OSじゃなくてgccのバージョンを言えよ baka
ホントに検証されんのがこわいもんだから
>詳細のバージョンは機密に引っ掛かるので、非公開にしておく。
検証しづらいだろう商用Linuxの名前出して逃げてやがんのw
そのくせ
>62でないなら、グタグタ言う前に試してみろ。
だってよ、どっちなんだよ。ちなみにちょっと前の
fedora2(redhat互換のw)gcc3でやったらfunc(2,2)だったぞ'
そーかそーかredhatとfedoraってこーゆーとこで差別化されてるのか
いや～おじゃば、勉強になったよ、ありがとうｗ
ホントに検証されんのがこわいもんだから
>詳細のバージョンは機密に引っ掛かるので、非公開にしておく。
検証しづらいだろう商用Linuxの名前出して逃げてやがんのw
そのくせ
>62でないなら、グタグタ言う前に試してみろ。
だってよ、どっちなんだよ。ちなみにちょっと前の
fedora2(redhat互換のw)gcc3でやったらfunc(2,2)だったぞ'
そーかそーかredhatとfedoraってこーゆーとこで差別化されてるのか
いや～おじゃば、勉強になったよ、ありがとうｗ
Ｃ++やJava使いのくせにＯＯって何？とか言う奴がいる以上、
普及してるとは言えないな
興味を持つ人がいるってのは、言い方を変えれば「ブーム」
「最近携帯電話がブームです」とは言わないだろ
こういうのは普及してるって言い方が正しい
普及してるとは言えないな
興味を持つ人がいるってのは、言い方を変えれば「ブーム」
「最近携帯電話がブームです」とは言わないだろ
こういうのは普及してるって言い方が正しい
Ubuntu 7.10 gcc4.1.2
func(2, 2)
そんなgccほんとにあるのか？
func(2, 2)
そんなgccほんとにあるのか？
>>62
を実行してみた。
$ ./a.out
2, 2
$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux
を実行してみた。
$ ./a.out
2, 2
$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux
まてまて、おまいら。x86なのが良くないのかも知れないぞ
と思って、手持ちのPowerPC MacのYellowDogLinux gcc4
でやってみた。
2, 2
やっぱりか、と思うｗ
と思って、手持ちのPowerPC MacのYellowDogLinux gcc4
でやってみた。
2, 2
やっぱりか、と思うｗ
210 ：仕様書無しさん：2008/02/07(木) 20:56:22
>>210
movl $0, -20(%ebp)
leal -20(%ebp), %eax
incl (%eax)
leal -20(%ebp), %eax
incl (%eax)
movl -20(%ebp), %eax
movl %eax, -16(%ebp)
movl -20(%ebp), %eax
movl %eax, 4(%esp)
movl -16(%ebp), %eax
movl %eax, (%esp)
call _func
gcc 4.0.1 の-s出力。
２回インクリメントしてから引数に積んで渡してるから、
当たり前なんだよね。
movl $0, -20(%ebp)
leal -20(%ebp), %eax
incl (%eax)
leal -20(%ebp), %eax
incl (%eax)
movl -20(%ebp), %eax
movl %eax, -16(%ebp)
movl -20(%ebp), %eax
movl %eax, 4(%esp)
movl -16(%ebp), %eax
movl %eax, (%esp)
call _func
gcc 4.0.1 の-s出力。
２回インクリメントしてから引数に積んで渡してるから、
当たり前なんだよね。
212 ：仕様書無しさん：2008/02/07(木) 21:24:49
これコンパイラーのバグ？、癖？
>>210
bcc5.5の/S出力
;
; int i = 0;
;
@3:
xor eax,eax
;
; func(++i, ++i);
;
?live1@64: ; EAX = i
inc eax
push eax
inc eax
push eax
call _func
こっちは素直にEAXをiとしてインクリメントして積んで、ってやってる。
ま、わかりやすいかなｗ
bcc5.5の/S出力
;
; int i = 0;
;
@3:
xor eax,eax
;
; func(++i, ++i);
;
?live1@64: ; EAX = i
inc eax
push eax
inc eax
push eax
call _func
こっちは素直にEAXをiとしてインクリメントして積んで、ってやってる。
ま、わかりやすいかなｗ
っつわけで、おじゃば、コンパイラの癖って偉そうに語るなら
こういう説明をしねえとダメだろ。
ま、お前はきっと「俺が話題を出した」ことで自分の手柄にして
得意になるんだろうけどな。
こういう説明をしねえとダメだろ。
ま、お前はきっと「俺が話題を出した」ことで自分の手柄にして
得意になるんだろうけどな。
VS2005。
まあ、おかしかない。
00412E73 mov dword ptr [count],0
func(++count,++count);
00412E7A mov eax,dword ptr [count]
00412E7D add eax,1
00412E80 mov dword ptr [count],eax
00412E83 mov ecx,dword ptr [count]
00412E86 add ecx,1
00412E89 mov dword ptr [count],ecx
00412E8C mov edx,dword ptr [count]
00412E8F push edx
00412E90 mov eax,dword ptr [count]
00412E93 push eax
00412E94 call func (411802h)
まあ、おかしかない。
00412E73 mov dword ptr [count],0
func(++count,++count);
00412E7A mov eax,dword ptr [count]
00412E7D add eax,1
00412E80 mov dword ptr [count],eax
00412E83 mov ecx,dword ptr [count]
00412E86 add ecx,1
00412E89 mov dword ptr [count],ecx
00412E8C mov edx,dword ptr [count]
00412E8F push edx
00412E90 mov eax,dword ptr [count]
00412E93 push eax
00412E94 call func (411802h)
で、gccで
2, 1
になるのはどのバージョンでどのOSでターゲットは何なんだ？
2, 1
になるのはどのバージョンでどのOSでターゲットは何なんだ？
powerpcのgcc4だとこう。
li r0,0
stw r0,56(r30)
lwz r2,56(r30)
addi r0,r2,1
stw r0,56(r30)
lwz r2,56(r30)
addi r0,r2,1
stw r0,56(r30)
lwz r3,56(r30)
lwz r4,56(r30)
bl _func
いずれにせよメモリ上のi(count)を2回インクリメントしてから
引数に積んで渡す。bccが例外？かも。でもbccが直感的に
わかりやすいかな。
li r0,0
stw r0,56(r30)
lwz r2,56(r30)
addi r0,r2,1
stw r0,56(r30)
lwz r2,56(r30)
addi r0,r2,1
stw r0,56(r30)
lwz r3,56(r30)
lwz r4,56(r30)
bl _func
いずれにせよメモリ上のi(count)を2回インクリメントしてから
引数に積んで渡す。bccが例外？かも。でもbccが直感的に
わかりやすいかな。
統一質問した方がよくね？
1：2,1はどの環境（CPU、OS、gcc）で発生したのか？
2：「関数引数の実行順序は保証されない。」 とはこの場合どういう意味なのか
2,2になるはずなのでこの場合は意味をなさない事を強調していった。
答えられないなら、問題の所を上記のようにアセンブリで出してよい。
こんな所でどう>おじゃば以外の皆
1：2,1はどの環境（CPU、OS、gcc）で発生したのか？
2：「関数引数の実行順序は保証されない。」 とはこの場合どういう意味なのか
2,2になるはずなのでこの場合は意味をなさない事を強調していった。
答えられないなら、問題の所を上記のようにアセンブリで出してよい。
こんな所でどう>おじゃば以外の皆
いいんじゃね
彼にまともな回答は期待してないが
彼にまともな回答は期待してないが
220 ：仕様書無しさん：2008/02/07(木) 23:41:00
すいません、>>31で
if(条件1 && 条件2）は条件１が先に動くか条件２が先に動くかわからないとありますが、
if(条件1 || 条件2）も同じなんですか？
この形って条件判定が軽い、もしくは先に真と判定されやすいデータをよく左に書きません？
javascript(ecmascript)だと ( obj && obj.test ) みたいな条件よく書くけどこれは言語仕様に
左から右へ評価されるって書いてるのかな。
if(条件1 && 条件2）は条件１が先に動くか条件２が先に動くかわからないとありますが、
if(条件1 || 条件2）も同じなんですか？
この形って条件判定が軽い、もしくは先に真と判定されやすいデータをよく左に書きません？
javascript(ecmascript)だと ( obj && obj.test ) みたいな条件よく書くけどこれは言語仕様に
左から右へ評価されるって書いてるのかな。
221 ：仕様書無しさん：2008/02/07(木) 23:51:22
どうでもいいけど
コンクリートクラスを機能継承しまくるのやめれ
初心者ＯＯ厨にかかると
とんでもないデスマに陥る罠
コンクリートクラスを機能継承しまくるのやめれ
初心者ＯＯ厨にかかると
とんでもないデスマに陥る罠
func(++i, ++i) じゃなくて、func(i++, i++)の間違いとか？
gcc4.1.2 で func(i++, i++) だと、
:
movl $0, -8(%ebp)
movl -8(%ebp), %edx
incl -8(%ebp)
movl -8(%ebp), %eax
incl -8(%ebp)
movl %edx, 4(%esp)
movl %eax, (%esp)
call func
:
eaxが第一引数で、edxが第二引数。funcに渡されるのは 1,0。
右から左へ渡すから感覚的にはそんな感じだが。
gcc4.1.2 で func(i++, i++) だと、
:
movl $0, -8(%ebp)
movl -8(%ebp), %edx
incl -8(%ebp)
movl -8(%ebp), %eax
incl -8(%ebp)
movl %edx, 4(%esp)
movl %eax, (%esp)
call func
:
eaxが第一引数で、edxが第二引数。funcに渡されるのは 1,0。
右から左へ渡すから感覚的にはそんな感じだが。
>220
ショートサーキット
VB6では
以下略
ショートサーキット
VB6では
以下略
>>220
ttp://www.rfs.jp/sb/javascript/01/06.html
の演算子の結合性のとこに、&&は左って書いてあんだろ。
俺は論理演算が右結合の言語を今だかつて知らない。
ただ、結合と式の評価の話は別なのかも知れない。
ttp://www.rfs.jp/sb/javascript/01/06.html
の演算子の結合性のとこに、&&は左って書いてあんだろ。
俺は論理演算が右結合の言語を今だかつて知らない。
ただ、結合と式の評価の話は別なのかも知れない。
223も書いてるが、言語が短絡評価するかどうかにもよるな。
VB6は短絡評価しないからねぇ。
VB6は短絡評価しないからねぇ。
自分の話題提供で勉強になって良かったじゃないか
そこまで誰か予測できたか？そういう意図だったんだ最初から
とかおじゃばがぬかしやがるに256クロック。
そこまで誰か予測できたか？そういう意図だったんだ最初から
とかおじゃばがぬかしやがるに256クロック。
必死にOOネタを拒否するスレはここですか？
>>228
いえ、ここはCマスター(笑)のためのスレです。
いえ、ここはCマスター(笑)のためのスレです。
230 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/08(金) 09:30:25
よかったな、オマエラ。勉強になって。
そろそろ、OOネタでも出そうか。
そろそろ、OOネタでも出そうか。
ほんとに言うなよw Cマスター（笑）
何このコテ
敗北宣言と受け取ってよろしい？
敗北宣言と受け取ってよろしい？
上で、敗北を認める男とある。
もし敗北なら24で何故そんな論拠になったのか、結果としていった内容も間違いとなったのか
詳細に言って最後に間違いでしたと言うのだろう。
だから、まだおじゃばは敗北していない。
今回の質問は簡単だし質問数も多くない。
答えるんだおじゃば。
もし敗北なら24で何故そんな論拠になったのか、結果としていった内容も間違いとなったのか
詳細に言って最後に間違いでしたと言うのだろう。
だから、まだおじゃばは敗北していない。
今回の質問は簡単だし質問数も多くない。
答えるんだおじゃば。
おれはおじゃばの下でますたーになる修行をしたい
236 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/08(金) 21:00:30
>>233
何？24は間違ってないだろう？
質問って何だ？218か？既に213が答えているようだが。
それとも、RedHatでアセンブリしたコードを張り付けろって言っているのか？
何で自分で検証しないんだ？
これで俺が張り付けたら、また大恥じゃないか？
何？24は間違ってないだろう？
質問って何だ？218か？既に213が答えているようだが。
それとも、RedHatでアセンブリしたコードを張り付けろって言っているのか？
何で自分で検証しないんだ？
これで俺が張り付けたら、また大恥じゃないか？
よぉ、おじゃばよぉ、お前、自他共に認める馬鹿ずんずらよぉ？
『RedHatでアセンブリしたコード』って意味不明な日本語どこで習ったずらよ？
『RedHatでアセンブリしたコード』って意味不明な日本語どこで習ったずらよ？
俺の先生を苛めるな！！
で何からやればマスターになれますか？
で何からやればマスターになれますか？
OOマスター（笑）になるにはどうすれば良いんだ？
とうとう長文書いてごまかすこともできなくなってやがるｗ
OOマスター（笑）への道
一つ、まず「初めてのC言語」を読むべし。
一つ、素人相手に威張れるので関数ポインタを覚えるべし。
一つ、初心者レベルでOK。マスター（笑）認定。
一つ、手に負えないものは、コンパイラのバグとすべし。
一つ、息抜きにCOBOLをやるべし。
一つ、次にJavaをやるべし。C++から手を付けるのは無謀と思うべし。
一つ、Javaを理解したらオレオレ流OOについて2chにカキコすべし。
一つ、デザパタは多すぎて覚えられないのであきらめるべし。
一つ、一息ついたらC++へ進むべし。C+Javaと思えばなんとかなるべし。
一つ、アセンブラはさわりだけ。
一つ、だけどバイトオーダとエンディアンだけは覚えるべし。
一つ、2chへのカキコは平日勤務中にこっそりすべし。
一つ、独断的に語るべし。俺がルールだ。
一つ、過ちは決して認めないべし。
一つ、逆切れは煙に巻く有効な手段と思うべし。
一つ、土日祝祭日は絶対に2ch禁止
一つ、自宅にインターネット環境など不要。
一つ、オナニーは週2回まで。
一つ、まず「初めてのC言語」を読むべし。
一つ、素人相手に威張れるので関数ポインタを覚えるべし。
一つ、初心者レベルでOK。マスター（笑）認定。
一つ、手に負えないものは、コンパイラのバグとすべし。
一つ、息抜きにCOBOLをやるべし。
一つ、次にJavaをやるべし。C++から手を付けるのは無謀と思うべし。
一つ、Javaを理解したらオレオレ流OOについて2chにカキコすべし。
一つ、デザパタは多すぎて覚えられないのであきらめるべし。
一つ、一息ついたらC++へ進むべし。C+Javaと思えばなんとかなるべし。
一つ、アセンブラはさわりだけ。
一つ、だけどバイトオーダとエンディアンだけは覚えるべし。
一つ、2chへのカキコは平日勤務中にこっそりすべし。
一つ、独断的に語るべし。俺がルールだ。
一つ、過ちは決して認めないべし。
一つ、逆切れは煙に巻く有効な手段と思うべし。
一つ、土日祝祭日は絶対に2ch禁止
一つ、自宅にインターネット環境など不要。
一つ、オナニーは週2回まで。
2つめでだめだな
関数ポインタははかってるけど
どんなときに使えば良いのかさっぱりわからない
教えてマスター
関数ポインタははかってるけど
どんなときに使えば良いのかさっぱりわからない
教えてマスター
>236
＞答えているようだが。
アンタは何故他人の褌で(ry
＞何で自分で検証しないんだ？
自分の主張を裏付ける根拠は自分で提出してくださいませ
＞答えているようだが。
アンタは何故他人の褌で(ry
＞何で自分で検証しないんだ？
自分の主張を裏付ける根拠は自分で提出してくださいませ
冷静かつ低能がウリの奴と対話しようとする方が間違い
冷静...か？ド低脳なのは確かだけど。
>926 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2007/08/23(木) 20:39:09
>なんだと、チキショー！
>やんのか、オラァ！！
>926 名前：おじゃばさま ◆GxjxF3yEw6 [] 投稿日：2007/08/23(木) 20:39:09
>なんだと、チキショー！
>やんのか、オラァ！！
おじゃば以外の人にしつも～ん。
inc eax
push eax
inc eax
push eax
call _func
は2,1で
movl $0, -20(%ebp)
leal -20(%ebp), %eax
incl (%eax)
leal -20(%ebp), %eax
incl (%eax)
movl -20(%ebp), %eax
movl %eax, -16(%ebp)
movl -20(%ebp), %eax
movl %eax, 4(%esp)
movl -16(%ebp), %eax
movl %eax, (%esp)
call _func
は
2,2
関数引数の実行順序変わっても2.1⇔2.2にならないと思うけど。
それとソラリスでボーランドのＣコンパイラってメジャーなの？
正直しらないんで。
おじゃばは答えないで。
inc eax
push eax
inc eax
push eax
call _func
は2,1で
movl $0, -20(%ebp)
leal -20(%ebp), %eax
incl (%eax)
leal -20(%ebp), %eax
incl (%eax)
movl -20(%ebp), %eax
movl %eax, -16(%ebp)
movl -20(%ebp), %eax
movl %eax, 4(%esp)
movl -16(%ebp), %eax
movl %eax, (%esp)
call _func
は
2,2
関数引数の実行順序変わっても2.1⇔2.2にならないと思うけど。
それとソラリスでボーランドのＣコンパイラってメジャーなの？
正直しらないんで。
おじゃばは答えないで。
前者(TASM?)は、「1足して渡して、1足して渡して」るから結果的に（1, 2）と渡してる。
呼出規約が、cdeclだと右側から渡すから、（2, 1）と渡ることになる。
これが、
inc eax
inc eax
push eax
push eax
call _func
ってなると、（2, 2）で渡ることになるな。
後者(gas)はまさにこれで、「1足して、1足した後に渡してる」から結果的に（2, 2）と渡してる。
評価しながら足すか、全部評価した後で渡すかで、違う値を関数が受け取る可能性がある。
評価の順番が呼出規約の順番に従うかどうかにもよるけど、ここが言語的に不定とされてるんだな。
ソラリスのbccについては知らん。
呼出規約が、cdeclだと右側から渡すから、（2, 1）と渡ることになる。
これが、
inc eax
inc eax
push eax
push eax
call _func
ってなると、（2, 2）で渡ることになるな。
後者(gas)はまさにこれで、「1足して、1足した後に渡してる」から結果的に（2, 2）と渡してる。
評価しながら足すか、全部評価した後で渡すかで、違う値を関数が受け取る可能性がある。
評価の順番が呼出規約の順番に従うかどうかにもよるけど、ここが言語的に不定とされてるんだな。
ソラリスのbccについては知らん。
>>247
ボーランドはDOS-Windows環境にしかC/C++は出してないはずだけど？
なんでSolaris?
あ、おじゃばがStudio11使ってたって話からか。>210がタイミング良く
bcc出してきたから、CodeGearからbcc5,5落としてきて試しちゃったよ、
という俺は>213だけどね。
ボーランドはDOS-Windows環境にしかC/C++は出してないはずだけど？
なんでSolaris?
あ、おじゃばがStudio11使ってたって話からか。>210がタイミング良く
bcc出してきたから、CodeGearからbcc5,5落としてきて試しちゃったよ、
という俺は>213だけどね。
あ、ごめん>>246だった。
>>249
>Borland C++ 2005（英語版）
>Borland C++ 2005は、Windows、Linux、Solarisで利用可能なC++統合開発環境です。
> * Windows、Linux、Solarisのマルチプラットフォームサポート
> * BCC32、GCCの搭載および切り替え可能なコンパイラ
とあったので。
>Borland C++ 2005（英語版）
>Borland C++ 2005は、Windows、Linux、Solarisで利用可能なC++統合開発環境です。
> * Windows、Linux、Solarisのマルチプラットフォームサポート
> * BCC32、GCCの搭載および切り替え可能なコンパイラ
とあったので。
SolarisでCの開発っていったら、Ｆだよね。
おじゃばんって理解力皆無だね♪
コミュニケーション能力も皆無だね♯
コミュニケーション能力も皆無だね♯
おじゃばが、SolarisでPerlをコンパイルしなきゃならん理由ってなんだったんだろ？
普通はコンパイルするにしても、モジュールの方だよなぁ。
普通はコンパイルするにしても、モジュールの方だよなぁ。
257 ：仕様書無しさん：2008/02/11(月) 21:40:06
久しぶりに見たがまだやってたんだｗ
２ちゃんねらーにはＯＯは無理だからあきらめろｗｗｗ
あと、おじゃばさん、名前変えてもらえませんかね？
２ちゃんねらーにはＯＯは無理だからあきらめろｗｗｗ
あと、おじゃばさん、名前変えてもらえませんかね？
259 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/12(火) 09:49:03
>>237
頭のいい人間は、省略されている部分を想像して読み取る。
ただ今回の場合は、誰でもわかると思うが。
>>238
JavaかCだな。その前に良い先輩につくのが近道。
>>241
俺の認定した「初心者レベル」でも、自信を持ってマスターしていると宣言出来る人はいないみたいだぞ。
>>242
24で提示済み。
>>243
良いプライドを持っている人は、環境を用意して検証したりする。
悪いプライドしかない人は、243のような書き込みをする。
>>245
チキショー、オボエテロー！！
頭のいい人間は、省略されている部分を想像して読み取る。
ただ今回の場合は、誰でもわかると思うが。
>>238
JavaかCだな。その前に良い先輩につくのが近道。
>>241
俺の認定した「初心者レベル」でも、自信を持ってマスターしていると宣言出来る人はいないみたいだぞ。
>>242
24で提示済み。
>>243
良いプライドを持っている人は、環境を用意して検証したりする。
悪いプライドしかない人は、243のような書き込みをする。
>>245
チキショー、オボエテロー！！
で、この板でIDを付ける方法について詳しく
261 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/12(火) 19:33:10
>>254
頭のいい人間は、（以下略）
>>255,256
俺の発言を裏読みすれば想像つくのではないか？
「32->64ビット移行」とか。
>>257
何に？
>>260
名前の後に#と任意の文字列を追加する。
ちなみに、260の次の書き込みも予想が出来るが、それに対する俺の書き込みも予想が出来ると思う。
頭のいい人間は、（以下略）
>>255,256
俺の発言を裏読みすれば想像つくのではないか？
「32->64ビット移行」とか。
>>257
何に？
>>260
名前の後に#と任意の文字列を追加する。
ちなみに、260の次の書き込みも予想が出来るが、それに対する俺の書き込みも予想が出来ると思う。
262 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/12(火) 20:06:56
まず、オブジェクト指向設計（OOD）と、オブジェクト指向プログラミング（OOP）の話を混ぜるのは
やめよう。OODが普及していないのに異存はない。問題はOOPが普及しているか否かだろう。
実際、OOPが普及しているかと言われると、確かに普及していない部署がある。
特に、ずっとCで開発をやってきたプロジェクトがそうだ。
こういうプロジェクトは大抵ひどい。新規で作成するプログラムでも、外部変数を大量に使用したり、
1関数が数千行になっていたり、1ファイルに数万行入っていたりする。
さらに、内容不明なフラグがAND/ORを駆使して判定されていたり、処理順序や演算子の優先順位をや
ロックルールを無視した実装がされていたりする。
こういうプロジェクトは入れ替わりが激しく、最初は問題ないコードでも、多人数で改修するうちに、
そうなってしまう事が多い。
また長い間、同じプロジェクトに浸かっている人は、知識が深いが狭い。
そのため、想定外の処理が必要になると、思いつきや勢いで実装したりする。
こういう人は、経験年数は長いため、妙にプライドが高かったり、縄張り意識が強かったりして、
問題点を指摘しても聞き入れなかったりする。
こうなると、年中デスマーチだ。
やめよう。OODが普及していないのに異存はない。問題はOOPが普及しているか否かだろう。
実際、OOPが普及しているかと言われると、確かに普及していない部署がある。
特に、ずっとCで開発をやってきたプロジェクトがそうだ。
こういうプロジェクトは大抵ひどい。新規で作成するプログラムでも、外部変数を大量に使用したり、
1関数が数千行になっていたり、1ファイルに数万行入っていたりする。
さらに、内容不明なフラグがAND/ORを駆使して判定されていたり、処理順序や演算子の優先順位をや
ロックルールを無視した実装がされていたりする。
こういうプロジェクトは入れ替わりが激しく、最初は問題ないコードでも、多人数で改修するうちに、
そうなってしまう事が多い。
また長い間、同じプロジェクトに浸かっている人は、知識が深いが狭い。
そのため、想定外の処理が必要になると、思いつきや勢いで実装したりする。
こういう人は、経験年数は長いため、妙にプライドが高かったり、縄張り意識が強かったりして、
問題点を指摘しても聞き入れなかったりする。
こうなると、年中デスマーチだ。
263 ：仕様書無しさん：2008/02/12(火) 20:13:47
>>1
そういう環境を作らないから
そういう環境を作らないから
264 ：仕様書無しさん：2008/02/12(火) 20:15:39
昔javaスレでおじゃばさまとか言ってjava貶して遊んでたのが何時の間にかこてで使われてたんだなｗｗｗｗ
おじゃばに返答するときは、
”保証できない動作を癖という”おじゃばさまとか言おうぜ。
そうじゃない場合は、これ、あれ、それ、変数Oとかで、
”保証できない動作を癖という”おじゃばさまを呼び出す事。
”保証できない動作を癖という”おじゃばさまとか言おうぜ。
そうじゃない場合は、これ、あれ、それ、変数Oとかで、
”保証できない動作を癖という”おじゃばさまを呼び出す事。
また意味のない長文、釣りにしてもなんのひねりもないな。
>>262
さすがに、自分自身の事を語っているだけあって、具体的だな
さすがに、自分自身の事を語っているだけあって、具体的だな
きっと、おじゃばは、>>262で提起した問題がOOなら解決できると言いたいのだろう。
こんなの、OO云々以前の問題のような気もするが、それはさておき、
・1関数が数千行になっていたり、1ファイルに数万行入っていたりする。
・内容不明なフラグがAND/ORを駆使して判定
・処理順序や演算子の優先順位をやロックルールを無視した実装
・同じプロジェクトに浸かっている人は、知識が深いが狭い。
・想定外の処理が必要になると、思いつきや勢いで実装したりする。
・妙にプライドが高かったり、縄張り意識が強かったりして、問題点を指摘しても聞き入れなかったりする。
...なんて、OO言語であってもやる奴はやるんだが、さて、おじゃばはこれをOOPで
どのように解決してくれるんだろう...楽しみ... ぜひ論理的に理由をつけて教えて
頂きたい。
こんなの、OO云々以前の問題のような気もするが、それはさておき、
・1関数が数千行になっていたり、1ファイルに数万行入っていたりする。
・内容不明なフラグがAND/ORを駆使して判定
・処理順序や演算子の優先順位をやロックルールを無視した実装
・同じプロジェクトに浸かっている人は、知識が深いが狭い。
・想定外の処理が必要になると、思いつきや勢いで実装したりする。
・妙にプライドが高かったり、縄張り意識が強かったりして、問題点を指摘しても聞き入れなかったりする。
...なんて、OO言語であってもやる奴はやるんだが、さて、おじゃばはこれをOOPで
どのように解決してくれるんだろう...楽しみ... ぜひ論理的に理由をつけて教えて
頂きたい。
技術力で悪しき政治における問題を解決しようとするという愚行をまた繰り返す？。
それはマの話題じゃない。板違いの様相を呈してきたな。
それはマの話題じゃない。板違いの様相を呈してきたな。
別によくある話で気にするような問題じゃないじゃないか。
ここで食堂あたりで古株の人間にそうなった経緯を聞いたりとか、
ＯＯ言語に・・・つまりＣ＋＋に移行しないのかと聞いて、
30分の独演会の後に無理だと言われるっていうのもよくある話。
ここで食堂あたりで古株の人間にそうなった経緯を聞いたりとか、
ＯＯ言語に・・・つまりＣ＋＋に移行しないのかと聞いて、
30分の独演会の後に無理だと言われるっていうのもよくある話。
素朴な疑問だが、設計がオブジェクト指向でなくて、何故にコーディングがオブジェクト指向にできるんだ？
>261
>名前の後に#と任意の文字列を追加する。
>167
>まさかIDってトリップのことじゃないよね？ ね？
お馬鹿な君の回答は先読みされてますよ？
>名前の後に#と任意の文字列を追加する。
>167
>まさかIDってトリップのことじゃないよね？ ね？
お馬鹿な君の回答は先読みされてますよ？
OOPは学問なんだよ
ちゃんと勉強しなきゃだめ
しかもOOPだけでオブジェクト指向がわかったような気がしてしまうのが危険
ちゃんと勉強しなきゃだめ
しかもOOPだけでオブジェクト指向がわかったような気がしてしまうのが危険
>>273
極論を言えば関数分けしたプログラムはオブジェクト指向プログラミングと言えるから
もうちょっと緩めるとクラス使ってる、クラス図使ってる＝OOPという解釈だったりもする
勘違いしてる人に多いけど全くの間違いでは無いのが難点
極論を言えば関数分けしたプログラムはオブジェクト指向プログラミングと言えるから
もうちょっと緩めるとクラス使ってる、クラス図使ってる＝OOPという解釈だったりもする
勘違いしてる人に多いけど全くの間違いでは無いのが難点
>>276
なるほど、関数ポインタがあるのを知ってればCマスターってのと同じかｗ
なるほど、関数ポインタがあるのを知ってればCマスターってのと同じかｗ
278 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/13(水) 09:14:27
デスマーチになると、実際には大して進んでいなくても、すごく仕事をした気分になる。
また思考能力が激減し、先の事が考えられなくなる。
これが技術停滞を招く。つまり先の事など考えずに効率の悪い作業ばかり続き、
しかし充実感はあるので、進歩していなくても危機感を感じない。
プロジェクトによってはこれが何年も続く。こういうプロジェクトに残された人は悲惨だ。
落ち着いてきて時間が出来ても、やる気が減退しているため、新しい事を覚えようとしない。
基本的に大きなプロジェクトに関わっているため危機感がない。
こういう人にとっては、そのプロジェクトが世界の全てとなる。
そして、そのプロジェクトで使用しない物を、「役に立たない」と決めつけ、
新しい物は「必要ない」と無視し、そのプロジェクトで使用している物を全て「常識」とし、
それを知らない人を「初心者」と言い切る。
また思考能力が激減し、先の事が考えられなくなる。
これが技術停滞を招く。つまり先の事など考えずに効率の悪い作業ばかり続き、
しかし充実感はあるので、進歩していなくても危機感を感じない。
プロジェクトによってはこれが何年も続く。こういうプロジェクトに残された人は悲惨だ。
落ち着いてきて時間が出来ても、やる気が減退しているため、新しい事を覚えようとしない。
基本的に大きなプロジェクトに関わっているため危機感がない。
こういう人にとっては、そのプロジェクトが世界の全てとなる。
そして、そのプロジェクトで使用しない物を、「役に立たない」と決めつけ、
新しい物は「必要ない」と無視し、そのプロジェクトで使用している物を全て「常識」とし、
それを知らない人を「初心者」と言い切る。
簡潔に書くと、まで読んだ
で、func(2, 2)になるLinuxのgccのバージョンはいくつでターゲットは何なんだ？
ゆえにデスマーチのグラマーは消耗品と化す。
消耗品だから後からくる人間は営業的に劣化した人間。
当初は以外に凡ミスを発見したりとか、新しい方法の提案をする。
（でもデバッグのテストはしないし、資料を作ってプレゼンしない）
そのうち、デスマーチに飲まれる。
まで補足説明した。
消耗品だから後からくる人間は営業的に劣化した人間。
当初は以外に凡ミスを発見したりとか、新しい方法の提案をする。
（でもデバッグのテストはしないし、資料を作ってプレゼンしない）
そのうち、デスマーチに飲まれる。
まで補足説明した。
おじゃばはしったかまで読んだ
平日に無駄な長文を書くほどヒマな奴に、デスマ語る資格はないな
...まともな仕事してないだけなんだろうけどさ。
...まともな仕事してないだけなんだろうけどさ。
285 ：仕様書無しさん：2008/02/13(水) 18:27:52
286 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/13(水) 20:10:14
つまり、このデスマ中毒C厨が、OOの普及を阻害している。
OOを普及させるには、こいつらにJavaやC++を教えるのが近道と言えるだろう。
ただしこれは非常に難しい。試しに自社のデスマ中毒C厨にJavaを教えようとしてみるといい。
大抵の場合、「忙しくてそんな暇はない」と言われるだろう。たとえ居眠りしていてもだ。
と言う訳で、こいつらにJavaを教える方法を募集する。何かいい方法あるか？
OOを普及させるには、こいつらにJavaやC++を教えるのが近道と言えるだろう。
ただしこれは非常に難しい。試しに自社のデスマ中毒C厨にJavaを教えようとしてみるといい。
大抵の場合、「忙しくてそんな暇はない」と言われるだろう。たとえ居眠りしていてもだ。
と言う訳で、こいつらにJavaを教える方法を募集する。何かいい方法あるか？
>>286
てれるなよ、Cマスター（笑）。みんなお前にコンパイラの癖を教えてもらいたいんだぜ。
てれるなよ、Cマスター（笑）。みんなお前にコンパイラの癖を教えてもらいたいんだぜ。
Javaで良い仕事して見せれば？
>>286
C言語でプログラム作る時にOOPなんてケツ拭くほどの役にも立たんわ。
JAVA勉強させるなら、Cを使うプロジェクトから抜いて、JAVAを使う案件やらすだけだろ。
会社にそういう案件がないなら、JAVAの勉強なんてソレこそ無駄以外の何物でもない。
おじゃば、アホちゃうか？
C言語でプログラム作る時にOOPなんてケツ拭くほどの役にも立たんわ。
JAVA勉強させるなら、Cを使うプロジェクトから抜いて、JAVAを使う案件やらすだけだろ。
会社にそういう案件がないなら、JAVAの勉強なんてソレこそ無駄以外の何物でもない。
おじゃば、アホちゃうか？
無駄でも勉強は常にするべきだろ
>>286に書かれてるような奴に教えても「JAVAでデスマ」実績を増やすだけだ。
「ほら、OOなんて使えねー」ってなる。
「ほら、OOなんて使えねー」ってなる。
1000行の関数書く奴にJava教えても1000行のメソッド書くだけだろ。
別にJavaやC++は言語レベルでOOPしやすい仕様になってるってだけだろ？
CでOOPがまったくできないというわけじゃないんだよな？
ってことはだ、Cでクソース書く人間にJava教えたところで出来上がるのはクソースだろうが。
んな、言語変えるだけでスーパーPGになれるんなら苦労しないってｗ
CでOOPがまったくできないというわけじゃないんだよな？
ってことはだ、Cでクソース書く人間にJava教えたところで出来上がるのはクソースだろうが。
んな、言語変えるだけでスーパーPGになれるんなら苦労しないってｗ
お前ら、今日、チョコ貰えそうか？
おじゃばは、何個チョコ貰ったか夜報告するように
今度はJavaで殺す気か？と言われるに一票
296 ：仕様書無しさん：2008/02/14(木) 02:38:46
> つまり、このデスマ中毒C厨が、OOの普及を阻害している。
> OOを普及させるには、こいつらにJavaやC++を教えるのが近道と言えるだろう。
「算数が苦手な奴には数学を教えれば大丈夫」
と言ってるようなもんだ
> OOを普及させるには、こいつらにJavaやC++を教えるのが近道と言えるだろう。
「算数が苦手な奴には数学を教えれば大丈夫」
と言ってるようなもんだ
デスマ中毒厨、じゃなくて間にCを入れないと気が済まなかったところに
おじゃばが今回とても悔しかったのがにじむなｗ
おじゃばが今回とても悔しかったのがにじむなｗ
古いCentOS 2.0 gcc2.9.6 があったので>62を(ry
>>286まず、Cでデスマらないようにしろよ。
C++をやらせたければ、STLやBoostのありがたみを教えればいいと思うが、そのありがたみを理解できるかは別問題。
302 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/15(金) 09:23:13
>>282
人間は消耗品ではない。
>>287
語尾に（笑）とかｗとか付けている人を見ると、痛々しくて照れる。
>>288
良い仕事をしても、一部の人にしか分からないんだよな。
>>289
290がいいことを言った。
>>292,293
まずJavaで失敗する所から始まる。
>>294
2個
>>295
「一度死ね」と言う。
人間は消耗品ではない。
>>287
語尾に（笑）とかｗとか付けている人を見ると、痛々しくて照れる。
>>288
良い仕事をしても、一部の人にしか分からないんだよな。
>>289
290がいいことを言った。
>>292,293
まずJavaで失敗する所から始まる。
>>294
2個
>>295
「一度死ね」と言う。
>>302
チョコ２個も貰ったのか...凄いな
チョコ２個も貰ったのか...凄いな
同じ部の女性チームが下のコンビニで買ったチロルチョコ二つだろ
アレだけチョコやらないとノウガキ始まってうぜーからだれかやっとけ、
って感じがひとつ。
新人の天然のコが「おじゃばさんいつもなんかカワイソウだから」
ってのがひとつ。
って感じがひとつ。
新人の天然のコが「おじゃばさんいつもなんかカワイソウだから」
ってのがひとつ。
そういえばOODとOOPはどういう関係なんでしょうか?
自分にはOOPはOODを含んでるように思えるんですが
皆の解釈はどうなのかが知りたいんです。
自分にはOOPはOODを含んでるように思えるんですが
皆の解釈はどうなのかが知りたいんです。
>>306
ＯＯＤはユースケース作ってそっからクス図やシーケンス図作るところまで
言語依存しない（特定言語視野に入れるとクラス図は描きやすいけど）
ＯＯＰはクラスとかのオブジェクトの詳細を考えるところからコーディングまで
クラス設計部分がかぶってるように見えるけど
ＯＯＤはユースケース等からクラスを起こす
ＯＯＰはクラス図の詳細を詰めるところから
当然クラス図が完璧ではなかったりするのでＯＯＰフェーズに入ってから
ＯＯＤフェーズであるクラスの新規作成等に戻る場合もある
現実にはクラス設計からＯＯＰだと思われてるし、設計者がコーディングも兼ねる場合が
多いので境目はあいまいに運用されてるね
ＯＯＤはユースケース作ってそっからクス図やシーケンス図作るところまで
言語依存しない（特定言語視野に入れるとクラス図は描きやすいけど）
ＯＯＰはクラスとかのオブジェクトの詳細を考えるところからコーディングまで
クラス設計部分がかぶってるように見えるけど
ＯＯＤはユースケース等からクラスを起こす
ＯＯＰはクラス図の詳細を詰めるところから
当然クラス図が完璧ではなかったりするのでＯＯＰフェーズに入ってから
ＯＯＤフェーズであるクラスの新規作成等に戻る場合もある
現実にはクラス設計からＯＯＰだと思われてるし、設計者がコーディングも兼ねる場合が
多いので境目はあいまいに運用されてるね
>>307
教えてくれてありがとうございます。
OOPの参考書などでも、ユースケース等から載っていたので混乱していました。
OOPからクラスや言語を意識するわけなんですね。
その前の所はOODの守備範囲となるわけですか。
OODよりもっといい名前があると思う俺は間違いなく素人…
もっと勉強しなければ。
教えてくれてありがとうございます。
OOPの参考書などでも、ユースケース等から載っていたので混乱していました。
OOPからクラスや言語を意識するわけなんですね。
その前の所はOODの守備範囲となるわけですか。
OODよりもっといい名前があると思う俺は間違いなく素人…
もっと勉強しなければ。
一応書いておこっか
OOA：オブジェクト指向分析
OOD：オブジェクト指向設計
OOP：オブジェクト指向プログラミング
OOが普及してないと主張する人は分析・設計・プログラミングを総合して判断し、
普及してると主張する人はなぜかOOPのみに限定して語りたがる
OOA：オブジェクト指向分析
OOD：オブジェクト指向設計
OOP：オブジェクト指向プログラミング
OOが普及してないと主張する人は分析・設計・プログラミングを総合して判断し、
普及してると主張する人はなぜかOOPのみに限定して語りたがる
310 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/18(月) 12:25:00
>>303-305
オマエラの報告は？
>>306-308
俺の解釈では、OODはクラス図を含まない。用件定義、機能設計まで。
OODが普及していないのは、OODの定義が曖昧な為もあるが、OODが全ての設計に適している訳ではない事が
大きいだろう。オブジェクト指向とは抽象化の技術である。しかし現実の世界において抽象化して
意味のある物は少ない。隣の山田さんは、あくまでも隣の山田さんなのである。
哺乳類の山田さんと表現する事に、殆どの場合は意味をなさない。
オマエラの報告は？
>>306-308
俺の解釈では、OODはクラス図を含まない。用件定義、機能設計まで。
OODが普及していないのは、OODの定義が曖昧な為もあるが、OODが全ての設計に適している訳ではない事が
大きいだろう。オブジェクト指向とは抽象化の技術である。しかし現実の世界において抽象化して
意味のある物は少ない。隣の山田さんは、あくまでも隣の山田さんなのである。
哺乳類の山田さんと表現する事に、殆どの場合は意味をなさない。
どう考えても要件定義はOOA
ODAって最近ニュースで聞かなくなったね。
交通事故起こしたんだっけ？
おじゃば、もうちょい簡潔に書けるように努力しれ
分かりきってることを書くのはおまいの悪い癖
分かりきってることを書くのはおまいの悪い癖
>俺の解釈では、OODはクラス図を含まない。用件定義、機能設計まで。
解釈の幅がある所で、自分解釈だしてその理由を言わない。
それがおじゃばクオリティ。
解釈の幅がある所で、自分解釈だしてその理由を言わない。
それがおじゃばクオリティ。
そもそも散々そこらの話をしておいてやっとこさ言葉の定義て・・・
>>310
＞隣の山田さんは、あくまでも隣の山田さんなのである。
＞哺乳類の山田さんと表現する事に、殆どの場合は意味をなさない。
「クラス設計」の話にしか見えない。
例えばUMLでクラス図描くまでに他に継承の話なんて出てきたっけ？
おじゃば的にクラス図(クラス設計)はOOP。
つまり、おじゃばはOOPは「殆どの場合は意味をなさない」と言いたいに違いない。
本当にお疲れ様でした。
＞隣の山田さんは、あくまでも隣の山田さんなのである。
＞哺乳類の山田さんと表現する事に、殆どの場合は意味をなさない。
「クラス設計」の話にしか見えない。
例えばUMLでクラス図描くまでに他に継承の話なんて出てきたっけ？
おじゃば的にクラス図(クラス設計)はOOP。
つまり、おじゃばはOOPは「殆どの場合は意味をなさない」と言いたいに違いない。
本当にお疲れ様でした。
320 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/19(火) 18:50:01
>>311
「知能が高くない事を自覚して仕事する」ってどういう事だ？
俺が出来る事は、全員が出来ると考えていいと言う事かな？
>>313
俺の定義ではOOAとOODは分けていない。
「オブジェクト指向分析・設計」とまとめている。
>>316
当然の事を書くと簡潔に書けと言われ、省略すると全部書けと言われる。
まあ、知識には個人差があるから、基本的に多めに書く事にする。
>>317
オブジェクト指向設計は言語に依存しない。
クラス設計（詳細設計）と言うのは言語に依存し、画面・DB・外部IF設計（機能設計）などは言語に依存しない。
そのため、機能設計以前をオブジェクト指向設計とする。
>>319
継承と捉えるとそういう解釈になるかもしれないが、抽象化と捉えてくれ。
「知能が高くない事を自覚して仕事する」ってどういう事だ？
俺が出来る事は、全員が出来ると考えていいと言う事かな？
>>313
俺の定義ではOOAとOODは分けていない。
「オブジェクト指向分析・設計」とまとめている。
>>316
当然の事を書くと簡潔に書けと言われ、省略すると全部書けと言われる。
まあ、知識には個人差があるから、基本的に多めに書く事にする。
>>317
オブジェクト指向設計は言語に依存しない。
クラス設計（詳細設計）と言うのは言語に依存し、画面・DB・外部IF設計（機能設計）などは言語に依存しない。
そのため、機能設計以前をオブジェクト指向設計とする。
>>319
継承と捉えるとそういう解釈になるかもしれないが、抽象化と捉えてくれ。
>>320
量の多寡ではない。長文を読んでもらう技術も、箇条書きで説明する技術もある。
お前がなぜちゃんと読んでもらえないかをいつまでたっても学ぼうとしないのは
お前が揶揄してるコボラとかC厨と同じことだ。
量の多寡ではない。長文を読んでもらう技術も、箇条書きで説明する技術もある。
お前がなぜちゃんと読んでもらえないかをいつまでたっても学ぼうとしないのは
お前が揶揄してるコボラとかC厨と同じことだ。
> 俺が出来る事は、全員が出来ると考えていい
何を今更
そう考えてないとアホみたいに冗長なだけで
重要なところ(根拠)を省略した文章は書けないはずだが？
相手が自分の考えを理解していないと思うなら
根拠を添えたそれなりに説得力のある文章を書くはず
> まあ、知識には個人差があるから、基本的に多めに書く事にする。
くだらん知識の披露より
お前の独自設定(前提)と根拠を忘れずに
何を今更
そう考えてないとアホみたいに冗長なだけで
重要なところ(根拠)を省略した文章は書けないはずだが？
相手が自分の考えを理解していないと思うなら
根拠を添えたそれなりに説得力のある文章を書くはず
> まあ、知識には個人差があるから、基本的に多めに書く事にする。
くだらん知識の披露より
お前の独自設定(前提)と根拠を忘れずに
>>320
例えば
>俺が出来る事は、全員が出来ると考えていいと言う事かな？
こんなことを言う神経だ。お互いができることとできないことを
上手く補完して仕事をする、という姿勢が完全に欠落している。
あるのはただ「俺が知っていることを教えてやる」だけだ。
で、それで物を知ってればまだいい。指摘を受けても規格は読まない。
出任せでCの引数出して、実行もしないでLinuxのgccとか言って
つっこまれたら苦し紛れで検証できないような商用Linuxを持ちだす。
そんな態度で人に何かを伝えられるとでも思ってるのか。
おおかた、2ちゃんにいるようなのはたいしたこと無いとか思って
コテハンにしたんだろうが、ふざけんな、この糞野郎。
な、長文はやだろ？
例えば
>俺が出来る事は、全員が出来ると考えていいと言う事かな？
こんなことを言う神経だ。お互いができることとできないことを
上手く補完して仕事をする、という姿勢が完全に欠落している。
あるのはただ「俺が知っていることを教えてやる」だけだ。
で、それで物を知ってればまだいい。指摘を受けても規格は読まない。
出任せでCの引数出して、実行もしないでLinuxのgccとか言って
つっこまれたら苦し紛れで検証できないような商用Linuxを持ちだす。
そんな態度で人に何かを伝えられるとでも思ってるのか。
おおかた、2ちゃんにいるようなのはたいしたこと無いとか思って
コテハンにしたんだろうが、ふざけんな、この糞野郎。
な、長文はやだろ？
根拠のない話には説得力がない。当たり前だね。
>310
思いっきり間違ってる
要求仕様はOOAだ
OODで分析結果をクラスとインターフェースに落とさなかったらどこでやるんだよ
OODの定義が曖昧なのではなく、お前の知識が浅いだけ
OOの利点は一貫してOOAからOOPまで概念がぶれないこと
お前みたいに分析の手法はオレオレ、設計はするかどうか不明、OOPでがんばります、
ってのはOO分かってない初心者の典型
思いっきり間違ってる
要求仕様はOOAだ
OODで分析結果をクラスとインターフェースに落とさなかったらどこでやるんだよ
OODの定義が曖昧なのではなく、お前の知識が浅いだけ
OOの利点は一貫してOOAからOOPまで概念がぶれないこと
お前みたいに分析の手法はオレオレ、設計はするかどうか不明、OOPでがんばります、
ってのはOO分かってない初心者の典型
分析も設計もやったことないんだろ
OOA＝OODだし
OOA＝OODだし
OMTとBoochがそれなりに競い合ってたように
これからはUMLとおじゃば法が競い会うんだよ
それくらいおじゃばの考えはオリジナリティにあふれているんだ
決して不勉強なんじゃ無いんだよ
これからはUMLとおじゃば法が競い会うんだよ
それくらいおじゃばの考えはオリジナリティにあふれているんだ
決して不勉強なんじゃ無いんだよ
329 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/20(水) 09:28:43
>>321
読まれていると思うぞ。理解されているかは別として。
>>322
322は根拠を書けと言うし、316は分かりきっている事は書くなという。
どうしてこのように違う意見が出るのか、客観的に考えた事はあるか？
322が認めたくないだけで、原因は分かりきっていると思うぞ。
>>323
いやネタとしては面白い。
>>324
機能仕様書だよ。画面仕様、DB仕様、外部IF仕様。
>>326
じゃOOAとOODでは、具体的に何を見て、何を作るのだ？
あとその場合に構造化分析・設計との違いを教えてくれ。
読まれていると思うぞ。理解されているかは別として。
>>322
322は根拠を書けと言うし、316は分かりきっている事は書くなという。
どうしてこのように違う意見が出るのか、客観的に考えた事はあるか？
322が認めたくないだけで、原因は分かりきっていると思うぞ。
>>323
いやネタとしては面白い。
>>324
機能仕様書だよ。画面仕様、DB仕様、外部IF仕様。
>>326
じゃOOAとOODでは、具体的に何を見て、何を作るのだ？
あとその場合に構造化分析・設計との違いを教えてくれ。
>>320
分析と設計の違いが分からないおじゃば乙
分析と設計の違いが分からないおじゃば乙
>329
質問を先に答えろ
「OODで分析結果をクラスとインターフェースに落とさなかったらどこでやるんだよ」
質問を先に答えろ
「OODで分析結果をクラスとインターフェースに落とさなかったらどこでやるんだよ」
っていうか、今更だろ・・・。
狙ったかっていう位ずれたオレ流で、
返答に返答で返す捻じ曲がった根性。
ちなみに、こういう事いうと一切返答しないヘタレでもある。
狙ったかっていう位ずれたオレ流で、
返答に返答で返す捻じ曲がった根性。
ちなみに、こういう事いうと一切返答しないヘタレでもある。
>機能仕様書だよ。画面仕様、DB仕様、外部IF仕様。
OODはオブジェクト指向設計なので仕様じゃなくて設計書という方がふさわしくね。
（ポンチ図は仕様書とは認めたくないが言えるが設計とは言い難い）
ここでの問題はオブジェクト指向設計とはどういう風にするかが問題で、
だからクラス図の代わりの成果物って聞いたわけだが、
まあ、おじゃばらしい返答だとして、
どうOODとして成果を盛り込むのかって聞いておこう。
矢印で関連付けしたり、番号割り振ってオブジェクト～って禁止な。
追記：関数設計書ないのがおじゃばらしいな。
OODはオブジェクト指向設計なので仕様じゃなくて設計書という方がふさわしくね。
（ポンチ図は仕様書とは認めたくないが言えるが設計とは言い難い）
ここでの問題はオブジェクト指向設計とはどういう風にするかが問題で、
だからクラス図の代わりの成果物って聞いたわけだが、
まあ、おじゃばらしい返答だとして、
どうOODとして成果を盛り込むのかって聞いておこう。
矢印で関連付けしたり、番号割り振ってオブジェクト～って禁止な。
追記：関数設計書ないのがおじゃばらしいな。
336 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/20(水) 22:43:46
>>330,331
質問は明確だろう？答えを書く努力もせずに非難か？
見苦しいな。
>>332
分析結果はまず、OODで抽象化された物（オブジェクト）に落とす。
例を挙げるとRPGゲームの場合は、「地形」や「キャラクター」や「アイテム」などだ。
気象シュミレータなどの場合は、「地球」や「大気」や「海水」などだ。
そのオブジェクトをOOPでクラスに落とす。
つまり、クラスやインタフェースに落とすのはOOPだ。
質問は明確だろう？答えを書く努力もせずに非難か？
見苦しいな。
>>332
分析結果はまず、OODで抽象化された物（オブジェクト）に落とす。
例を挙げるとRPGゲームの場合は、「地形」や「キャラクター」や「アイテム」などだ。
気象シュミレータなどの場合は、「地球」や「大気」や「海水」などだ。
そのオブジェクトをOOPでクラスに落とす。
つまり、クラスやインタフェースに落とすのはOOPだ。
おじゃば、残業乙。
339 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/20(水) 23:15:24
>>333
預言者気取りか？
返答したぞ。予言が外れると、預言者はペテン師に名前が変わるんだよな。
>>334
OODの成果を明確に盛り込める標準的な設計書はない。
だからOODで落とした情報をさらに変換して、画面、DB、外部IFに落とさなければならない。
一応、一部のUML（ユースケース図、シーケンス図）を補助として使う場合もある。
追記：関数仕様書は外部提供でない限り、詳細設計に入るので、機能設計には入らない。
>>338
ここが分かりにくくなる所だ。オブジェクト指向設計は実在する物の設計には向かない。
だから電卓などの設計をOODで行ってはならない。適切に設計出来ない。
前にも言ったが、シミュレーションやゲームなどの分野に向く。
もしOODを使うなら、万能計算システムのような物を設計する時に用いるべきだろう。
預言者気取りか？
返答したぞ。予言が外れると、預言者はペテン師に名前が変わるんだよな。
>>334
OODの成果を明確に盛り込める標準的な設計書はない。
だからOODで落とした情報をさらに変換して、画面、DB、外部IFに落とさなければならない。
一応、一部のUML（ユースケース図、シーケンス図）を補助として使う場合もある。
追記：関数仕様書は外部提供でない限り、詳細設計に入るので、機能設計には入らない。
>>338
ここが分かりにくくなる所だ。オブジェクト指向設計は実在する物の設計には向かない。
だから電卓などの設計をOODで行ってはならない。適切に設計出来ない。
前にも言ったが、シミュレーションやゲームなどの分野に向く。
もしOODを使うなら、万能計算システムのような物を設計する時に用いるべきだろう。
>>336
クラスを抽出、分類するのは普通、設計の段階だろ。抽象化の意味分かってんのか？
プラグラミングの段階でクラスに分類なんて器用なこと、よっぽどちっちゃなシステム
でなければ俺には無理っ。クラス図とか、シーケンス図とか、なんのためにあるのかと...
クラスを抽出、分類するのは普通、設計の段階だろ。抽象化の意味分かってんのか？
プラグラミングの段階でクラスに分類なんて器用なこと、よっぽどちっちゃなシステム
でなければ俺には無理っ。クラス図とか、シーケンス図とか、なんのためにあるのかと...
>>336
331だが。
＞どう考えても要件定義はOOA
↓
＞俺の定義ではOOAとOODは分けていない。
＞「オブジェクト指向分析・設計」とまとめている。
↓
＞分析と設計の違いが分からないおじゃば乙
↓
＞質問は明確だろう？答えを書く努力もせずに非難か？
俺は何に答えれば良いんだ？
331だが。
＞どう考えても要件定義はOOA
↓
＞俺の定義ではOOAとOODは分けていない。
＞「オブジェクト指向分析・設計」とまとめている。
↓
＞分析と設計の違いが分からないおじゃば乙
↓
＞質問は明確だろう？答えを書く努力もせずに非難か？
俺は何に答えれば良いんだ？
>336
お前が言ってるのはOOAだな
RFPの要件を満たす条件をユースケース「地形」「キャラクター」やらに落とす
それを元に実装制約を考慮して、
OOD（設計段階）で実装制約を考慮してクラスやインターフェースに落とす
実装段階になってシーケンス図を書くとか言いだしたら、通常は引っ叩かれるな
別に俺はお前のように煽るつもりもないし、お前の知識不足を笑うつもりもないが、
知らないなら知らないと言っておけよ
誰が見てもそうだが、今のおまえの状況は「教えてる」じゃなく「教えてもらってる」だ
お前が言ってるのはOOAだな
RFPの要件を満たす条件をユースケース「地形」「キャラクター」やらに落とす
それを元に実装制約を考慮して、
OOD（設計段階）で実装制約を考慮してクラスやインターフェースに落とす
実装段階になってシーケンス図を書くとか言いだしたら、通常は引っ叩かれるな
別に俺はお前のように煽るつもりもないし、お前の知識不足を笑うつもりもないが、
知らないなら知らないと言っておけよ
誰が見てもそうだが、今のおまえの状況は「教えてる」じゃなく「教えてもらってる」だ
>>339
万能計算システムなんて曖昧な代物はメタファの使いかたとして不適切だな。
あと、OODの成果物からユースケース図とかシーケンス図とか、順序がばらばら。
というか、やっぱおじゃばは、オレ流解釈だし、ねっからの説明下手なんだな。
相手をするのに目眩を感じるほどの倦怠感を催させる。つぅことでもういいや。
万能計算システムなんて曖昧な代物はメタファの使いかたとして不適切だな。
あと、OODの成果物からユースケース図とかシーケンス図とか、順序がばらばら。
というか、やっぱおじゃばは、オレ流解釈だし、ねっからの説明下手なんだな。
相手をするのに目眩を感じるほどの倦怠感を催させる。つぅことでもういいや。
>>339
相変わらずいい加減すぎて分からない所だ。
おじゃばには設計は向かない。
だからOODについて語ってはならない。適切に設計できない。
前にも言ったが、おじゃばは給湯室の影で泣くなどの分野に向く。
もしOODを使うなら、って表現がおかしすぎて用いるべきではないだろう。
相変わらずいい加減すぎて分からない所だ。
おじゃばには設計は向かない。
だからOODについて語ってはならない。適切に設計できない。
前にも言ったが、おじゃばは給湯室の影で泣くなどの分野に向く。
もしOODを使うなら、って表現がおかしすぎて用いるべきではないだろう。
これが全てを物語ってるな
「OODを使うなら」
こっちに誘導すべきか？
こういう奴の対処法を教えてください
http://pc11.2ch.net/test/read.cgi/prog/1201701478/
「OODを使うなら」
こっちに誘導すべきか？
こういう奴の対処法を教えてください
http://pc11.2ch.net/test/read.cgi/prog/1201701478/
>>339
>預言者気取りか？
>返答したぞ。予言が外れると、預言者はペテン師に名前が変わるんだよな。
世間一般では安い挑発。2Chでは釣りって言うんだ。
>OODの成果を明確に盛り込める標準的な設計書はない。
シュレイアー・メラー法とかいくつかあるんだけど・・・。
おじゃば的に使えないっつー事？
>だからOODで落とした情報をさらに変換して、画面、DB、外部IFに落とさなければならない。
OOD→機能設→詳細設計って流れか？
>預言者気取りか？
>返答したぞ。予言が外れると、預言者はペテン師に名前が変わるんだよな。
世間一般では安い挑発。2Chでは釣りって言うんだ。
>OODの成果を明確に盛り込める標準的な設計書はない。
シュレイアー・メラー法とかいくつかあるんだけど・・・。
おじゃば的に使えないっつー事？
>だからOODで落とした情報をさらに変換して、画面、DB、外部IFに落とさなければならない。
OOD→機能設→詳細設計って流れか？
大体、根拠を書くことと、無駄を省くことが、相反するものだと考えてる時点で痛すぎる。
おじゃばの文書は、根拠を書かないくせに無駄に長文になるというのが特徴。
おじゃばの文書は、根拠を書かないくせに無駄に長文になるというのが特徴。
素人な俺はOO学習の題材を「電卓」にしようかと思い始めた。
>>336
330だが、
>質問は明確だろう？答えを書く努力もせずに非難か？
>見苦しいな。
質問が、明確と答えるのに何か関係あるのか？
もしかして、質問が明確なら答えも簡単と思っているのか？
それに、俺がなぜ「おじゃばさま」に分るように書く努力を
しないといけないんだ？ 俺にはついていけない思考だ．．．
まっ、批判ばかりするのも生産的じゃないから
>構造化分析・設計との違いを教えてくれ。
を一応答えるが、
「構造化分析はDOAやPOAで分析し
設計は、トップダウンやボトムアップで設計していく」
分る人間には、これで十分だと思うが、分らない人間にまず
自分が努力しないと、ね、「おじゃばさま」
330だが、
>質問は明確だろう？答えを書く努力もせずに非難か？
>見苦しいな。
質問が、明確と答えるのに何か関係あるのか？
もしかして、質問が明確なら答えも簡単と思っているのか？
それに、俺がなぜ「おじゃばさま」に分るように書く努力を
しないといけないんだ？ 俺にはついていけない思考だ．．．
まっ、批判ばかりするのも生産的じゃないから
>構造化分析・設計との違いを教えてくれ。
を一応答えるが、
「構造化分析はDOAやPOAで分析し
設計は、トップダウンやボトムアップで設計していく」
分る人間には、これで十分だと思うが、分らない人間にまず
自分が努力しないと、ね、「おじゃばさま」
おじゃばって、箇条書きがうまくできないレベルだよな。
おじゃば的に、OOAとOODを分けていない。
OOＡとして分析した結果をOODとして機能設計レベルで終わらせて詳細設計すると
解釈できるわけだがどうなん？
OOＡとして分析した結果をOODとして機能設計レベルで終わらせて詳細設計すると
解釈できるわけだがどうなん？
まともな設計書を書いたこともなさそうなおじゃばに、
何高望みしてるんだお前ら。かわいそうじゃないかおじゃばが。
何高望みしてるんだお前ら。かわいそうじゃないかおじゃばが。
わからないなら自分で調べるのが技術者だろ
勝手な解釈で理解したつもりになってるのはわからないより悪いな
営業がJAVAの案件持ってきた
おじゃばが居るところじゃないよな？
勝手な解釈で理解したつもりになってるのはわからないより悪いな
営業がJAVAの案件持ってきた
おじゃばが居るところじゃないよな？
厚顔無恥をここまで体現してる奴は珍しいな
虚言癖も凄まじいし、明らかに間違っていてもプライドが高過ぎて、
無理やり反論し続け傷を広げている
本人が未だに自覚していないのがさらに凄い
ごめんなさい、知識不足でした、の一言で済む話なのにな
堀江メール問題の永田のようでおこちゃま
虚言癖も凄まじいし、明らかに間違っていてもプライドが高過ぎて、
無理やり反論し続け傷を広げている
本人が未だに自覚していないのがさらに凄い
ごめんなさい、知識不足でした、の一言で済む話なのにな
堀江メール問題の永田のようでおこちゃま
ライブラリのバグ＝コンパイラの癖（笑）
356 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/21(木) 09:56:33
>>340
340の工程の分類は「設計」「コーディング」のようだが、
俺の分類は「機能設計」「詳細設計」「コーディング」で、
OODが「機能設計」、OOPは「詳細設計」+「コーディング」になっている。
だから、クラスに分類するのは「詳細設計」で、いきなり340に「コーディング」しろとは言っていない。
俺は出来るがな。
>>341
OOAとOODの参照資料と成果物、それと構造化との違いでいいよ。
>>342
教えてもらっていると言う感覚はないな。342と単に分類方法が違うだけのように見える。
「内容は問題ないが、分類方法が間違っている」と言う事でいいのかな？
ちなみに342の分類だとOODは言語に依存するし、OOPでやる事がなくなると思うが、それでいいのか？
>>343
ユースケースがOOAだと言いたいだけか？それなら俺はOOAとOODを分けていないといったはずだが。
内容については問題ないのか？342の分類についてはどういう意見だ？
>>344
全然内容が違うと言うなら、OODの正しい説明をしたらどうだ？
その意見では、344の給湯室の使い方が間違っているとしか指摘出来ないぞ。
340の工程の分類は「設計」「コーディング」のようだが、
俺の分類は「機能設計」「詳細設計」「コーディング」で、
OODが「機能設計」、OOPは「詳細設計」+「コーディング」になっている。
だから、クラスに分類するのは「詳細設計」で、いきなり340に「コーディング」しろとは言っていない。
俺は出来るがな。
>>341
OOAとOODの参照資料と成果物、それと構造化との違いでいいよ。
>>342
教えてもらっていると言う感覚はないな。342と単に分類方法が違うだけのように見える。
「内容は問題ないが、分類方法が間違っている」と言う事でいいのかな？
ちなみに342の分類だとOODは言語に依存するし、OOPでやる事がなくなると思うが、それでいいのか？
>>343
ユースケースがOOAだと言いたいだけか？それなら俺はOOAとOODを分けていないといったはずだが。
内容については問題ないのか？342の分類についてはどういう意見だ？
>>344
全然内容が違うと言うなら、OODの正しい説明をしたらどうだ？
その意見では、344の給湯室の使い方が間違っているとしか指摘出来ないぞ。
357 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/21(木) 10:33:36
>>346
>世間一般では安い挑発。2Chでは釣りって言うんだ。
挑発だよ。
>シュレイアー・メラー法とかいくつかあるんだけど・・・。おじゃば的に使えないっつー事？
「標準的」な設計書ではないと言う事。
もし有用な物があるなら、簡単に説明してもらえると助かる。
>OOD→機能設→詳細設計って流れか？
Yes
>>347
根拠が常識なら無駄になるだろう。ただし「常識」と言う物は人によって異なるがな。
>>349
>「構造化分析はDOAやPOAで分析し、設計は、トップダウンやボトムアップで設計していく」
分かる人には「どれだけ内容の薄い説明か」が分かる文章だな。
トップダウン、ボトムアップは構造化設計に関係ないだろう。本当に意味分かって言っているのか？
>世間一般では安い挑発。2Chでは釣りって言うんだ。
挑発だよ。
>シュレイアー・メラー法とかいくつかあるんだけど・・・。おじゃば的に使えないっつー事？
「標準的」な設計書ではないと言う事。
もし有用な物があるなら、簡単に説明してもらえると助かる。
>OOD→機能設→詳細設計って流れか？
Yes
>>347
根拠が常識なら無駄になるだろう。ただし「常識」と言う物は人によって異なるがな。
>>349
>「構造化分析はDOAやPOAで分析し、設計は、トップダウンやボトムアップで設計していく」
分かる人には「どれだけ内容の薄い説明か」が分かる文章だな。
トップダウン、ボトムアップは構造化設計に関係ないだろう。本当に意味分かって言っているのか？
OOAとOODと用語自体分かれているのに、結局はおじゃばは区別しないといいながら
分析をOODと言っている。
根拠や常識や知識じゃなくて、言葉遊びのレベルだな。
バグをコンパイラの癖と言ったりしているし、マジ言葉遊びだな～。
分析をOODと言っている。
根拠や常識や知識じゃなくて、言葉遊びのレベルだな。
バグをコンパイラの癖と言ったりしているし、マジ言葉遊びだな～。
>>358
分析・設計をちゃんとそれぞれの成果物として出したことのない、
小さな案件しかやったことのない奴なんだから仕方ないよおじゃばは。
前にも、なんか半年で何度か納品したとか言ってたし。
2chくらい背伸びしてみたいんだよ。かわいそうじゃないか。
生暖かく見守ってやろうぜ。
分析・設計をちゃんとそれぞれの成果物として出したことのない、
小さな案件しかやったことのない奴なんだから仕方ないよおじゃばは。
前にも、なんか半年で何度か納品したとか言ってたし。
2chくらい背伸びしてみたいんだよ。かわいそうじゃないか。
生暖かく見守ってやろうぜ。
> ただし「常識」と言う物は人によって異なるがな。
だから、その異なる部分(前提・根拠)を意図的に省いて、
共通部分を冗長に書き殴ってオナニーしてるのがお前だろ。
だから、その異なる部分(前提・根拠)を意図的に省いて、
共通部分を冗長に書き殴ってオナニーしてるのがお前だろ。
>>356
>俺の分類は「機能設計」「詳細設計」「コーディング」で、
>OODが「機能設計」、OOPは「詳細設計」+「コーディング」になっている。
って、なんで用語を独自解釈でねじ曲げるんだ？ 用語は一般的に認識されている意味で使おうぜ。
大体、OOの世界に「機能設計」とか「詳細設計」とか前時代からの言葉を無理矢理対応付けて理解
しようとしてる所に違和感を感じる。そいうえば、おじゃばもとコボラーだったな。今もか？
説明の仕方がちょっと古くさいんだよ。たまには、アジャイル開発とかXPの方法論を実践してみ？
>俺の分類は「機能設計」「詳細設計」「コーディング」で、
>OODが「機能設計」、OOPは「詳細設計」+「コーディング」になっている。
って、なんで用語を独自解釈でねじ曲げるんだ？ 用語は一般的に認識されている意味で使おうぜ。
大体、OOの世界に「機能設計」とか「詳細設計」とか前時代からの言葉を無理矢理対応付けて理解
しようとしてる所に違和感を感じる。そいうえば、おじゃばもとコボラーだったな。今もか？
説明の仕方がちょっと古くさいんだよ。たまには、アジャイル開発とかXPの方法論を実践してみ？
というか、おじゃばはクラス図使わないの～？
使うとすれば詳細設計あたり？
使うとすれば詳細設計あたり？
でも脳内プログラマがこれだけがんばってるのは評価していい
クラス図なんて用件定義段階からつかうだろ
うちでは、ケースツールに、適用するデザインパターンを指定したら、
クラス図やコラボレーション図、シーケンス図を自動生成してくれます。
あと、言語の雛型クラスのソースも。それを使ってさくさく開発してます。
クラス図やコラボレーション図、シーケンス図を自動生成してくれます。
あと、言語の雛型クラスのソースも。それを使ってさくさく開発してます。
>>357
>分かる人には「どれだけ内容の薄い説明か」が分かる文章だな。
>トップダウン、ボトムアップは構造化設計に関係ないだろう。本当に意味分かって言っているのか？
>>330で書いたようにやっぱり、分らない人間に教えるのは厳しいな
しかし、「トップダウン、ボトムアップは構造化設計に関係ない」とは．．． 取りあえず、これでも読めば
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%83%E3%83%97%E3%83%80%E3%82%A6%E3%83%B3%E8%A8%AD%E8%A8%88%E3%81%A8%E3%83%9C%E3%83%88%E3%83%A0%E3%82%A2%E3%83%83%E3%83%97%E8%A8%AD%E8%A8%88
しかし、説明の為一番に分りやすいと思ってトップダウンとボトムアップを書いたが
それすら、分らないとは．．． 上のウィキペディアでも書いてあるが
「トップダウン設計は1980年代にオブジェクト指向プログラミングが台頭してくるまで最も支持された手法であった。」
それを、「トップダウン、ボトムアップは構造化設計に関係ない」とは．．．
>分かる人には「どれだけ内容の薄い説明か」が分かる文章だな。
>トップダウン、ボトムアップは構造化設計に関係ないだろう。本当に意味分かって言っているのか？
>>330で書いたようにやっぱり、分らない人間に教えるのは厳しいな
しかし、「トップダウン、ボトムアップは構造化設計に関係ない」とは．．． 取りあえず、これでも読めば
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%83%E3%83%97%E3%83%80%E3%82%A6%E3%83%B3%E8%A8%AD%E8%A8%88%E3%81%A8%E3%83%9C%E3%83%88%E3%83%A0%E3%82%A2%E3%83%83%E3%83%97%E8%A8%AD%E8%A8%88
しかし、説明の為一番に分りやすいと思ってトップダウンとボトムアップを書いたが
それすら、分らないとは．．． 上のウィキペディアでも書いてあるが
「トップダウン設計は1980年代にオブジェクト指向プログラミングが台頭してくるまで最も支持された手法であった。」
それを、「トップダウン、ボトムアップは構造化設計に関係ない」とは．．．
これだけコミュニティを疲弊させる奴って
実際どんな奴なんやろか
嫌われてるのは確実だが
実際どんな奴なんやろか
嫌われてるのは確実だが
おじゃばはオレ流だから、疲れるのは覚悟しとかないと。
>>356
＞OOAとOODの参照資料と成果物、それと構造化との違いでいいよ。
別に構造化との違いなんかどうでも良いんだがな。
分析と設計は目的もやることも違うと言ってるだけ。
たとえ使ってるツールが同じもの、似たものだとしても、だ。
分析は「客の目的のために、どのようなシステムが必要か」を明示する。
客に対するヒアリングと分野の資料を参照して、成果物は要件定義書。
構造化分析との違いは、OOAでは「アクターがどのようにシステムを使用するか」に注目し、
構造化分析では「システムがどのようなデータをどう処理するか」に注目する。
これは、分析の中心がOOAではユースケースなのに対し、構造化分析ではDFDだから。
設計は「要件定義されたシステムを、どのように構築するか」を明示する。
要件定義書及び分析における副産物を参照して、成果物は設計書(設計仕様書)。
どんな設計書が出てくるかはプロジェクトごとに違う。
構造化設計とOODの違いは、モジュール構成が処理単位かクラス単位か。
で、「クラス図はOODでは作らずOOPで作るだ」なんて言ってるが、
分析、設計、実装(詳細設計)、どの工程でも作ることがある。
単に粒度が違うだけ。
構造化のモジュール構成図もそうだろ？
システムレベル、プロセスレベル、機能モジュール単体の内部レベル、
それぞれでモジュール構成図を作ることがあるが、粒度が違う。
＞OOAとOODの参照資料と成果物、それと構造化との違いでいいよ。
別に構造化との違いなんかどうでも良いんだがな。
分析と設計は目的もやることも違うと言ってるだけ。
たとえ使ってるツールが同じもの、似たものだとしても、だ。
分析は「客の目的のために、どのようなシステムが必要か」を明示する。
客に対するヒアリングと分野の資料を参照して、成果物は要件定義書。
構造化分析との違いは、OOAでは「アクターがどのようにシステムを使用するか」に注目し、
構造化分析では「システムがどのようなデータをどう処理するか」に注目する。
これは、分析の中心がOOAではユースケースなのに対し、構造化分析ではDFDだから。
設計は「要件定義されたシステムを、どのように構築するか」を明示する。
要件定義書及び分析における副産物を参照して、成果物は設計書(設計仕様書)。
どんな設計書が出てくるかはプロジェクトごとに違う。
構造化設計とOODの違いは、モジュール構成が処理単位かクラス単位か。
で、「クラス図はOODでは作らずOOPで作るだ」なんて言ってるが、
分析、設計、実装(詳細設計)、どの工程でも作ることがある。
単に粒度が違うだけ。
構造化のモジュール構成図もそうだろ？
システムレベル、プロセスレベル、機能モジュール単体の内部レベル、
それぞれでモジュール構成図を作ることがあるが、粒度が違う。
>>369
あんたも、もうおじゃばにモノ教えようとすんのやめたら？無駄だし。
あんたも、もうおじゃばにモノ教えようとすんのやめたら？無駄だし。
>>370
むしろ燃えてるんじゃ？
むしろ燃えてるんじゃ？
立つ前提が違うからな、コンパイルの癖は一般的な用語じゃないが、
今回のは英語から内容があきらかだからな。
あえて言うならば、OOA/OOD分けなかった理由をおじゃばは述べなくては
ならないわけだが・・・、少しづつズレタ言い方で誤魔化しているのはいつもの事だ。
ああ、違うと言うならはっきりだれにでも理解できる位明確に分けなかった理由を
言ってくれないか。ついでに分析・要件定義・設計・コーディングの進行と、
おじゃば的なOOとしての特色も。
今回のは英語から内容があきらかだからな。
あえて言うならば、OOA/OOD分けなかった理由をおじゃばは述べなくては
ならないわけだが・・・、少しづつズレタ言い方で誤魔化しているのはいつもの事だ。
ああ、違うと言うならはっきりだれにでも理解できる位明確に分けなかった理由を
言ってくれないか。ついでに分析・要件定義・設計・コーディングの進行と、
おじゃば的なOOとしての特色も。
コーダーが背伸びしてるだけ。
設計段階でクラス図を書いたことがあればこんなバカは言わないからな。
設計段階でクラス図を書いたことがあればこんなバカは言わないからな。
おじゃば予想：
1) 「用語の解釈は人それぞれ」と逃げる
2) いじめられっこの開き直り発言「お前ら勉強になったろ」
3) 後釣り宣言「スレが賑わってよかっただろ」
4) 的外れ一言レスで次へ持ち越し。
5) 別の話題を振って、逃げる。
1) 「用語の解釈は人それぞれ」と逃げる
2) いじめられっこの開き直り発言「お前ら勉強になったろ」
3) 後釣り宣言「スレが賑わってよかっただろ」
4) 的外れ一言レスで次へ持ち越し。
5) 別の話題を振って、逃げる。
376 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/22(金) 09:28:47
>>376
絶対ちゃんと読んでねーくせに。
絶対ちゃんと読んでねーくせに。
なにこの小学生並の敗北宣言
>>374
こんな奴コーダーでいたらぶっ飛ばす。つかクビにしてやる。
こんな奴コーダーでいたらぶっ飛ばす。つかクビにしてやる。
380 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/22(金) 21:39:35
で、本当に議論したいことは、「アクターがどのようにシステムを使用するか」
これを具体的にどうやるかなんだよな。
俺の場合は抽象化でやっているのだが、369はどうやってんだ？
あと、369はコテにしてくれよ。
366とか変なのがいて分かりにくい。「OOマスター」でどうだ？
これを具体的にどうやるかなんだよな。
俺の場合は抽象化でやっているのだが、369はどうやってんだ？
あと、369はコテにしてくれよ。
366とか変なのがいて分かりにくい。「OOマスター」でどうだ？
アーキテクチャ仮決めして概念モデルだしてユースケース回るかチェックするんだろ
>俺の場合は抽象化でやっているのだが、
具体的に書けっていってんのに、なにこのどうとでもとれるセリフ。
ほんと馬鹿は直らない。おっとスルーだったな。
具体的に書けっていってんのに、なにこのどうとでもとれるセリフ。
ほんと馬鹿は直らない。おっとスルーだったな。
383 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/22(金) 21:58:59
例えば在庫管理プログラムを作るとする。
入庫、出庫で分類したら、処理単位なので、POAだ。倉庫、商品などで分類したらDOAだ。
個人的には在庫管理プログラムならDOAが最適だと思うが、これを抽象化でやると変な設計しか思いつかない。
目的で分類？管理が目的だから管理を抽象化するのか？わからん。
入庫、出庫で分類したら、処理単位なので、POAだ。倉庫、商品などで分類したらDOAだ。
個人的には在庫管理プログラムならDOAが最適だと思うが、これを抽象化でやると変な設計しか思いつかない。
目的で分類？管理が目的だから管理を抽象化するのか？わからん。
OOマスターとか変な呼び名したら失礼だろう、ちゃんとしたSEに。
OOとか関係ないと本人が言ってるのに何言ってるんだこの馬鹿は。
教えて欲しいならその俺様用語をやめろと。
「在庫管理の考え方がわかりません、どこから手を着けたらいいでしょうか」
でいいじゃねーか、どうせ振ったほうもお前になんとかできるた思ってねー
から安心してればいいよ。
OOとか関係ないと本人が言ってるのに何言ってるんだこの馬鹿は。
教えて欲しいならその俺様用語をやめろと。
「在庫管理の考え方がわかりません、どこから手を着けたらいいでしょうか」
でいいじゃねーか、どうせ振ったほうもお前になんとかできるた思ってねー
から安心してればいいよ。
385 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/22(金) 22:25:33
照れるなよCマスター（笑）
ああ、おじゃばは2chに「優しく教えてくれる先生」を探しに来てたんだな
８スレ目にしてようやくわかったよ。馬鹿だろお前。
８スレ目にしてようやくわかったよ。馬鹿だろお前。
おじゃば、なんで366を気にしてんだ？
ちゃんと教えて貰ったんだから、礼ぐらい書いとけよ
ちゃんと教えて貰ったんだから、礼ぐらい書いとけよ
「抽象化でやる」ってどういう意味？
OOってオブジェクトを抽出するところやるんじゃないの？
OOってオブジェクトを抽出するところやるんじゃないの？
分析と設計をコーディング時にやるんだってさ
ソースを設計書としてユーザーレビューってか
お笑いだな
プロセスとかデータとか言う以前の大問題があるだろ
社会人なら次の話をする前に総括しろ ばかたれ
スネオマスターが
ソースを設計書としてユーザーレビューってか
お笑いだな
プロセスとかデータとか言う以前の大問題があるだろ
社会人なら次の話をする前に総括しろ ばかたれ
スネオマスターが
スネオマスター（笑）
在庫管理プログラム？共用体使えば、抽象化比較的楽にできると思うんだが、
結局商品のパターン分類で細分化しすぎ、すごい事になり、結局破綻するのが常なので
ここの部分のオブジェクト化をあきらめるのが吉。折衷案もいえないのがおじゃば。
と、おじゃばの思考をかってに推測して答えらしきものでっち上げた。
結局商品のパターン分類で細分化しすぎ、すごい事になり、結局破綻するのが常なので
ここの部分のオブジェクト化をあきらめるのが吉。折衷案もいえないのがおじゃば。
と、おじゃばの思考をかってに推測して答えらしきものでっち上げた。
>366とか変なのがいて分かりにくい。「OOマスター」でどうだ？
んっ？、「おじゃばさま」に嫌われたか？まっ、関係無いがｗ
「おじゃばさま」の初心者級の質問だと、歯ごたえがないと言う奴も多いと思うから
俺から質問、気が向いた奴は答えてくれ
・クラス定義の中に入れ子でクラス定義は、
オブジェクト指向として正しいか正しくないのか、それと、そう思う理由を教えてくれ
これは、「おじゃばさま」には聞いていないから答えるなよ(~_~ﾒ)
んっ？、「おじゃばさま」に嫌われたか？まっ、関係無いがｗ
「おじゃばさま」の初心者級の質問だと、歯ごたえがないと言う奴も多いと思うから
俺から質問、気が向いた奴は答えてくれ
・クラス定義の中に入れ子でクラス定義は、
オブジェクト指向として正しいか正しくないのか、それと、そう思う理由を教えてくれ
これは、「おじゃばさま」には聞いていないから答えるなよ(~_~ﾒ)
ん？ インナークラスのこと？
これは言語的にもサポートしてるものが多いし、正しくないとする理由は見当たらんが。
わざわざ別クラスにするまでもない、そのクラスだけで使うテンポラリー的なクラスとか、
そのクラスとだけ密結合するようなものなど、手軽に定義できるし、俺はわりと良く使う。
これは言語的にもサポートしてるものが多いし、正しくないとする理由は見当たらんが。
わざわざ別クラスにするまでもない、そのクラスだけで使うテンポラリー的なクラスとか、
そのクラスとだけ密結合するようなものなど、手軽に定義できるし、俺はわりと良く使う。
>>383
＞個人的には在庫管理プログラムならDOAが最適だと思うが、これを抽象化でやると変な設計しか思いつかない。
結局上流工程が良く分かってないんだから、どの道ムリ。
DOAにしろOOAにしろ、「抽象化でやる」とかいう謎なおじゃば独自の方法にしろ、
分析の話なのに「設計が思いつかない」なんて言葉が出てくること自体おかしい。
で、在庫管理プログラムだっけ？
分類とか、訳わかんねぇ。
分類だの思い付く付かないだの言う前に、とりあえずユースケース書け。
話はそこからだろうが。
OOA出来る出来ないに関わらず、客先と折衝して要件分析する人間が
ユースケースを書けない訳が無い。（出来不出来はあるだろうけど）
＞個人的には在庫管理プログラムならDOAが最適だと思うが、これを抽象化でやると変な設計しか思いつかない。
結局上流工程が良く分かってないんだから、どの道ムリ。
DOAにしろOOAにしろ、「抽象化でやる」とかいう謎なおじゃば独自の方法にしろ、
分析の話なのに「設計が思いつかない」なんて言葉が出てくること自体おかしい。
で、在庫管理プログラムだっけ？
分類とか、訳わかんねぇ。
分類だの思い付く付かないだの言う前に、とりあえずユースケース書け。
話はそこからだろうが。
OOA出来る出来ないに関わらず、客先と折衝して要件分析する人間が
ユースケースを書けない訳が無い。（出来不出来はあるだろうけど）
おじゃば、チューしようか？
ユースケースと設計は直接リンクしないよ
旧来型の開発に慣れちゃってるやつは、ユースケースは
設計の機能網羅性をチェックするためのもの、くらいに思っておけばいい
旧来型の開発に慣れちゃってるやつは、ユースケースは
設計の機能網羅性をチェックするためのもの、くらいに思っておけばいい
398 ：仕様書無しさん：2008/02/23(土) 09:15:00
オブジェクト指向が流行らないのは
オブジェクト指向の本がjavaのしかないからだ
オブジェクト指向の本がjavaのしかないからだ
このスレのOO有識者が散々言ってるように、
オブジェクト指向は実装だけでなく分析からの工程をカバーする。
OOで分析・設計するのであればUMLに準じた資料は必須になり、
クラス図、シーケンス図などの構造設計や、状態遷移図などの機能設計を書くことになる。
これ自体が機能設計書となるもので、その他の補完として文章による設計書を書く。
上の方で書いてあるが、工程によって粒度が違う、というのはまさしくその通りで、
分析から実装まで一貫してることがOOの最大の利点。
コーディング時にクラスやインターフェースを考える、というのは、
よほど時間が無いか、知らないか、現場の理解を得られないかだろ。
上に書いたのは理想で、必ずしも設計者がOOを理解してるかというとそうでもないし、
どちらかと言えばOO言語習得者の方がクラス等を理解してるのは確かにある。
要はOO分析・設計をできる奴が少ないってこと。
OOが普及しないのはこれが一番の要因だと思う。
オブジェクト指向は実装だけでなく分析からの工程をカバーする。
OOで分析・設計するのであればUMLに準じた資料は必須になり、
クラス図、シーケンス図などの構造設計や、状態遷移図などの機能設計を書くことになる。
これ自体が機能設計書となるもので、その他の補完として文章による設計書を書く。
上の方で書いてあるが、工程によって粒度が違う、というのはまさしくその通りで、
分析から実装まで一貫してることがOOの最大の利点。
コーディング時にクラスやインターフェースを考える、というのは、
よほど時間が無いか、知らないか、現場の理解を得られないかだろ。
上に書いたのは理想で、必ずしも設計者がOOを理解してるかというとそうでもないし、
どちらかと言えばOO言語習得者の方がクラス等を理解してるのは確かにある。
要はOO分析・設計をできる奴が少ないってこと。
OOが普及しないのはこれが一番の要因だと思う。
>>393
クラス内でのクラス定義はOMT/booch時代には考慮されてなかった気がする
UMLでも記述見かけた記憶が無いな（気がついて無いだけだと思うが）
クラス図ってのは外部IFを持ったくクラスを記述して行くものだし、メソッドも
初期のクラス設計時には全部書いたりしないよね
その内部クラスが他から使用（共用）されるなら記述するべきだが
そんなのは独立させるべきであって結果クラス内にはクラス記述しない
クラス内クラスを表現する表記ってUMLで決まってたら有無だけでも教えてほしい
調べるからさ
最近勉強不足なんで的外れならおじゃばを崇める
クラス内でのクラス定義はOMT/booch時代には考慮されてなかった気がする
UMLでも記述見かけた記憶が無いな（気がついて無いだけだと思うが）
クラス図ってのは外部IFを持ったくクラスを記述して行くものだし、メソッドも
初期のクラス設計時には全部書いたりしないよね
その内部クラスが他から使用（共用）されるなら記述するべきだが
そんなのは独立させるべきであって結果クラス内にはクラス記述しない
クラス内クラスを表現する表記ってUMLで決まってたら有無だけでも教えてほしい
調べるからさ
最近勉強不足なんで的外れならおじゃばを崇める
>>398
いや、それは言いすぎだろ・・・
いや、それは言いすぎだろ・・・
>400
つ UML2.0
つ UML2.0
>>402
細かいが、UML１．４からじゃないか？
細かいが、UML１．４からじゃないか？
>>394
それは、実装時のみテクニックとして「あり」と言う事か？
俺も実装時だけ考えれば、スコープを最小限に出来るから「あり」だと思うが
オブジェクト指向として考えるなら分析／設計段階で出てこない表記表現のクラスを定義するのは
「分析／設計でクラス分類をしない」と言ってる奴と同じになるしなｗ
>>400
俺も分析／設計をしていて、入れ子クラスを書いたことがない
だからと言って、俺の経験則からだけで入れ子クラスは
オブジェクト指向じゃないとも言えないし、俺の考えでは
入れ子クラスのほとんどが集約・コンポジションで機能的に代用出来る
どうしても入れ子クラスを使う場合は、そのクラスを拡張したくない場合とか（言語にもよると思うが）
しかし、「拡張させない」はオブジェクト指向なのか？ 分らん．．．
それは、実装時のみテクニックとして「あり」と言う事か？
俺も実装時だけ考えれば、スコープを最小限に出来るから「あり」だと思うが
オブジェクト指向として考えるなら分析／設計段階で出てこない表記表現のクラスを定義するのは
「分析／設計でクラス分類をしない」と言ってる奴と同じになるしなｗ
>>400
俺も分析／設計をしていて、入れ子クラスを書いたことがない
だからと言って、俺の経験則からだけで入れ子クラスは
オブジェクト指向じゃないとも言えないし、俺の考えでは
入れ子クラスのほとんどが集約・コンポジションで機能的に代用出来る
どうしても入れ子クラスを使う場合は、そのクラスを拡張したくない場合とか（言語にもよると思うが）
しかし、「拡張させない」はオブジェクト指向なのか？ 分らん．．．
多重継承ができん言語のときは使うかなぁ
多重継承って何言っているんだｗ
>>405
分析／設計で、細かいクラスまで全部定義する必要はないでしょ。
たとえば、UIから受け取った値を、意味的にまとまりのある集合として保持
しておきたいけど、汎用的に使えるようなものではない場合で、だけど配列
やマップだと見通しが悪くなりそうであれば、内部クラスとして表現するの
は全然ありだと思う。
設計の観点からのOOという意味ではもちろん違うが。コーディング上のテク
ニックとしてはあり。
あと、JavaのAPIでは、内部クラスって結構使われてるんだよなぁ。DOMの
実装でも使われてる。C++みたいにフレンド指定がないJavaでは、外側のク
ラスのメンバに自由にアクセスできる内部クラスに特殊な役割を受け持たせ
るってのも設計的にはありかもしれない。
分析／設計で、細かいクラスまで全部定義する必要はないでしょ。
たとえば、UIから受け取った値を、意味的にまとまりのある集合として保持
しておきたいけど、汎用的に使えるようなものではない場合で、だけど配列
やマップだと見通しが悪くなりそうであれば、内部クラスとして表現するの
は全然ありだと思う。
設計の観点からのOOという意味ではもちろん違うが。コーディング上のテク
ニックとしてはあり。
あと、JavaのAPIでは、内部クラスって結構使われてるんだよなぁ。DOMの
実装でも使われてる。C++みたいにフレンド指定がないJavaでは、外側のク
ラスのメンバに自由にアクセスできる内部クラスに特殊な役割を受け持たせ
るってのも設計的にはありかもしれない。
そりゃ、使わなきゃ実装はされんだろ。便利ちゃ便利だし。
>>383
在庫管理オブジェクトが在庫オブジェクトを管理するんじゃないか？
在庫管理オブジェクトが在庫オブジェクトを管理するんじゃないか？
在庫管理オブジェクトって、粒度でかすぎw
在庫オブジェクトって？？？
在庫オブジェクトって？？？
>>411
PS3の事じゃないのかｗ
PS3の事じゃないのかｗ
>>411
そうか？
410じゃないけど、>>383程度の情報しかないんなら、妥当なトコかと。
在庫オブジェクトは「在庫情報」ぐらいのエンティティと思われ。
在庫管理は「在庫情報管理」か？
「在庫情報」が属性として「商品名」と「在庫数」を持ってて、
「在庫情報管理」がユーザからの操作で「在庫情報一覧表示」「在庫数操作(増減)」をする、
って感じじゃねの？
設計まで行くと、もっと色々あるんだろうけどさ。
そうか？
410じゃないけど、>>383程度の情報しかないんなら、妥当なトコかと。
在庫オブジェクトは「在庫情報」ぐらいのエンティティと思われ。
在庫管理は「在庫情報管理」か？
「在庫情報」が属性として「商品名」と「在庫数」を持ってて、
「在庫情報管理」がユーザからの操作で「在庫情報一覧表示」「在庫数操作(増減)」をする、
って感じじゃねの？
設計まで行くと、もっと色々あるんだろうけどさ。
複数のクライアントとかリアルタイム処理とか在庫の種類分類によっても設計は変わっていく。
おじゃばが抽象化で変な設計になるっていうのは、分類によっては処理がガラリと変わるだと思うんだが。
おじゃばが抽象化で変な設計になるっていうのは、分類によっては処理がガラリと変わるだと思うんだが。
>>413
それただのマスターメンテだからw 在庫情報テーブル?の保守な。
在庫管理ってそんな単純なもんじゃないだろ。商品とか分類とか、
発注とか、仕入とか、いろんな要素がからんでくる。
普通、○△システムと呼ぶようなものを、○△オブジェクトとは
言わないから。
それただのマスターメンテだからw 在庫情報テーブル?の保守な。
在庫管理ってそんな単純なもんじゃないだろ。商品とか分類とか、
発注とか、仕入とか、いろんな要素がからんでくる。
普通、○△システムと呼ぶようなものを、○△オブジェクトとは
言わないから。
おいおい、だから分析と設計は分けようぜ。おじゃばの馬鹿じゃあるまいし、
必要な要件決まらない状態で「抽象化(笑)」したら、ただのマスタメンテに
なるだろそりゃ。そりゃすぐ設計したくなるのはマの性かもしらんけどさ。
必要な要件決まらない状態で「抽象化(笑)」したら、ただのマスタメンテに
なるだろそりゃ。そりゃすぐ設計したくなるのはマの性かもしらんけどさ。
むしろ、分析とか設計って言葉使わない方がいいよ
工程と勘違いされる危険がある
工程と勘違いされる危険がある
分析の段階での設計の予測・推測ってレベルだろ？
分析しながら設計の方法が全く頭に浮かばないのはヤバイと思うわけだが。
感触つかむレベルとそれが全てというのは話は別だと思うんだが。
分析しながら設計の方法が全く頭に浮かばないのはヤバイと思うわけだが。
感触つかむレベルとそれが全てというのは話は別だと思うんだが。
感触つかむっつか、フィジビリティの検証が必要
フィジビリティ
初めて聞いた言葉だ
初めて聞いた言葉だ
>>408
>設計の観点からのOOという意味ではもちろん違うが。コーディング上のテク
>ニックとしてはあり。
やはり、そんな感じで考える人間が多いのか
疑問だが
>たとえば、UIから受け取った値を、意味的にまとまりのある集合として保持
>しておきたいけど、汎用的に使えるようなものではない場合で、だけど配列
>やマップだと見通しが悪くなりそうであれば、内部クラスとして表現するの
>は全然ありだと思う。
の時、UIの入力項目が増えたり、他のオブジェクトから使用されるようになった場合
拡張はどうしているの？ソースレベルでの拡張か？
直接この話題には関係ないが、どうしてオブジェクト指向で作ったシステムを
改修するのに、ソースレベルで行なっている現場が多いんだろうな
オブジェクト指向の良さが半減するし、分析／設計で拡張性を考えた意味が無い
>>409
>そりゃ、使わなきゃ実装はされんだろ。便利ちゃ便利だし。
たしかに、それはそうだが、構造化言語でもGOTO文が実装されていたし
フローチャートの表記も出来た、また実行文を簡単に変えられて便利と言えば便利だが
将来苦労する。もちろん入れ子クラスとは程度の差はあるが、同じ事が言えないか？
まっ、そこまで深く考える必要もないのかも知れんが
この話は、ここで終了として次の問題を出すよ
多態性は、インターフェースと継承で実装出来るが
その使いわれの基準をどう考えているか教えてくれ
また、気が向いた奴だけ書いてくれ
>設計の観点からのOOという意味ではもちろん違うが。コーディング上のテク
>ニックとしてはあり。
やはり、そんな感じで考える人間が多いのか
疑問だが
>たとえば、UIから受け取った値を、意味的にまとまりのある集合として保持
>しておきたいけど、汎用的に使えるようなものではない場合で、だけど配列
>やマップだと見通しが悪くなりそうであれば、内部クラスとして表現するの
>は全然ありだと思う。
の時、UIの入力項目が増えたり、他のオブジェクトから使用されるようになった場合
拡張はどうしているの？ソースレベルでの拡張か？
直接この話題には関係ないが、どうしてオブジェクト指向で作ったシステムを
改修するのに、ソースレベルで行なっている現場が多いんだろうな
オブジェクト指向の良さが半減するし、分析／設計で拡張性を考えた意味が無い
>>409
>そりゃ、使わなきゃ実装はされんだろ。便利ちゃ便利だし。
たしかに、それはそうだが、構造化言語でもGOTO文が実装されていたし
フローチャートの表記も出来た、また実行文を簡単に変えられて便利と言えば便利だが
将来苦労する。もちろん入れ子クラスとは程度の差はあるが、同じ事が言えないか？
まっ、そこまで深く考える必要もないのかも知れんが
この話は、ここで終了として次の問題を出すよ
多態性は、インターフェースと継承で実装出来るが
その使いわれの基準をどう考えているか教えてくれ
また、気が向いた奴だけ書いてくれ
追記
これも、「おじゃばさま」には聞いていないから答えるなよ(~_~ﾒ)
これも、「おじゃばさま」には聞いていないから答えるなよ(~_~ﾒ)
> 直接この話題には関係ないが、どうしてオブジェクト指向で作ったシステムを
> 改修するのに、ソースレベルで行なっている現場が多いんだろうな
> オブジェクト指向の良さが半減するし、分析／設計で拡張性を考えた意味が無い
なんだかんだいってもオブジェクト指向のアウトプットを
一番表現しやすいのがソースコードだからに決まってる
ドメインモデルを表現しやすいのもソース
アーキテクチャを表現しやすいのもソース
実装時のみ必要なコード(糊とか)を表現するのも、もちろんソース
ドメインモデルの追加変更をソースで表現したとして
オブジェクト指向の良さが半減などとちっとも思わない
> 改修するのに、ソースレベルで行なっている現場が多いんだろうな
> オブジェクト指向の良さが半減するし、分析／設計で拡張性を考えた意味が無い
なんだかんだいってもオブジェクト指向のアウトプットを
一番表現しやすいのがソースコードだからに決まってる
ドメインモデルを表現しやすいのもソース
アーキテクチャを表現しやすいのもソース
実装時のみ必要なコード(糊とか)を表現するのも、もちろんソース
ドメインモデルの追加変更をソースで表現したとして
オブジェクト指向の良さが半減などとちっとも思わない
インターフェースと継承の使い分けって意味がわからん
インタフェースは外から見てどうか、継承するか別の手段を使うかは
内部的な構造としてどうか、についての話であって使い分けもへったくれもない
あるクラスを設計するとき、そのクラスだけ見てインタフェースがどうあるべきか
一意に定まると考えているとしたなら、それは考え方が違う
インタフェースは外から見てどうか、継承するか別の手段を使うかは
内部的な構造としてどうか、についての話であって使い分けもへったくれもない
あるクラスを設計するとき、そのクラスだけ見てインタフェースがどうあるべきか
一意に定まると考えているとしたなら、それは考え方が違う
>>424
勘違いしてないか？、俺がいいたのは継承を使わず
元のソースを改修する事を言っている
>>425
>インターフェースと継承の使い分けって意味がわからん
意味が分らないんだったら、答えなくていいから「おじゃばさま」の相手をしてくれ
勘違いしてないか？、俺がいいたのは継承を使わず
元のソースを改修する事を言っている
>>425
>インターフェースと継承の使い分けって意味がわからん
意味が分らないんだったら、答えなくていいから「おじゃばさま」の相手をしてくれ
427 ：仕様書無しさん：2008/02/24(日) 14:05:12
おじゃばが来ないと、なんだか楽しいですねｗ
>>422
UIの入力項目が増えたら、そりゃソースを弄るさ。
エンティティの設計が変わった可能性があるから、へたすりゃ、
モデル、ビュー、コントローラ、そしてビジネスロジック全般に
影響が及ぶ可能性があるからね。ソースを変えなくてすむのは、
予めそういう項目が変わるケースを想定してて、設定ファイルか
なんかに外だししてた場合だろうけど、そういうのは要件として
あがってる場合じゃなければ、設計の負荷が高すぎるからまず
やらん。
あと、PerlやRubyみたいなLLだと、下手に設定ファイルに定義
するより、ソース自体に設定項目定義するケースも多い。そして
変更がはいれば、もちろんソースを直に弄る。別に問題ない。
>>425じゃないけど、オレも、インターフェースと継承の使い分け
って意味がわからん。使い分けるというより、どちらも込みで設計
する場合が多いと思うが。デザパタの話か？
UIの入力項目が増えたら、そりゃソースを弄るさ。
エンティティの設計が変わった可能性があるから、へたすりゃ、
モデル、ビュー、コントローラ、そしてビジネスロジック全般に
影響が及ぶ可能性があるからね。ソースを変えなくてすむのは、
予めそういう項目が変わるケースを想定してて、設定ファイルか
なんかに外だししてた場合だろうけど、そういうのは要件として
あがってる場合じゃなければ、設計の負荷が高すぎるからまず
やらん。
あと、PerlやRubyみたいなLLだと、下手に設定ファイルに定義
するより、ソース自体に設定項目定義するケースも多い。そして
変更がはいれば、もちろんソースを直に弄る。別に問題ない。
>>425じゃないけど、オレも、インターフェースと継承の使い分け
って意味がわからん。使い分けるというより、どちらも込みで設計
する場合が多いと思うが。デザパタの話か？
>427
彼が絡むたびに話が斜め下にぶっとんで逝くからね
喧嘩腰にかつ的外れな俺ルールで冗長な主張を繰り返すから
彼が絡むたびに話が斜め下にぶっとんで逝くからね
喧嘩腰にかつ的外れな俺ルールで冗長な主張を繰り返すから
>>428
>UIの入力項目が増えたら、そりゃソースを弄るさ。
ソースを弄るのは、元のソースを修正すると言う意味か？
クラスを継承して、項目を追加しないのか？
俺は、項目の削除もクラスの拡張（継承）という形でやっているが
その前に前提を書いていなかったな、俺が考えていたのは
リリース後の改修のことだ。
>オレも、インターフェースと継承の使い分けって意味がわからん。
俺の考えが間違っているのか、それとも説明が悪いのか？
それじゃ、この問題の前に一つ質問
「多態性は、どのように実装しているかを教えてくれ」
>UIの入力項目が増えたら、そりゃソースを弄るさ。
ソースを弄るのは、元のソースを修正すると言う意味か？
クラスを継承して、項目を追加しないのか？
俺は、項目の削除もクラスの拡張（継承）という形でやっているが
その前に前提を書いていなかったな、俺が考えていたのは
リリース後の改修のことだ。
>オレも、インターフェースと継承の使い分けって意味がわからん。
俺の考えが間違っているのか、それとも説明が悪いのか？
それじゃ、この問題の前に一つ質問
「多態性は、どのように実装しているかを教えてくれ」
>>430
＞リリース後の改修のことだ。
428じゃないけど、UIの入力項目増えたら、さすがにソース弄る。
というか、クラスを改変する方向で考える、と言った方が良い？
ただ、複数のクライアントに同様のシステムをリリースしていて、
ある1つのクライアントに対する特別対応であるなら、
多分継承などで対処する。
＞リリース後の改修のことだ。
428じゃないけど、UIの入力項目増えたら、さすがにソース弄る。
というか、クラスを改変する方向で考える、と言った方が良い？
ただ、複数のクライアントに同様のシステムをリリースしていて、
ある1つのクライアントに対する特別対応であるなら、
多分継承などで対処する。
多態性の実装は、各クラスを設計する際の話でしょ
元が変わらないなら継承するし、
継承よりもオーバーライドが多そうと判断すればインターフェースを利用する
それだけのことじゃん
元が変わらないなら継承するし、
継承よりもオーバーライドが多そうと判断すればインターフェースを利用する
それだけのことじゃん
>>430
項目の増減に継承で対応するのは本来のOOの使いかたじゃないよね。
設計時点で判っていればやってないような継承ならなおさら。
変更の度に場当たり的に子クラスを作っていったら見通しが悪くなっ
て、保守性の向上というOO本来のメリットが損なわれてしまう。
なのでクラスの分割に意味を見出せるような特殊なケースでない限り
継承ではなくて、影響箇所を直接修正する方向で考える。
バージョン管理ソフトで管理してれば、前のバージョンにもすぐ戻せ
るし。
>「多態性は、どのように実装しているかを教えてくれ」
多態性はどのようにって、基底となるインターフェースなりクラスを
決めて、メソッドを派生クラスでオーバーライドさせるってのが普通
だと思うが... 俺はWeb屋だからTemplate Methodパターンとか
Comanndパターンをよく使うな。
項目の増減に継承で対応するのは本来のOOの使いかたじゃないよね。
設計時点で判っていればやってないような継承ならなおさら。
変更の度に場当たり的に子クラスを作っていったら見通しが悪くなっ
て、保守性の向上というOO本来のメリットが損なわれてしまう。
なのでクラスの分割に意味を見出せるような特殊なケースでない限り
継承ではなくて、影響箇所を直接修正する方向で考える。
バージョン管理ソフトで管理してれば、前のバージョンにもすぐ戻せ
るし。
>「多態性は、どのように実装しているかを教えてくれ」
多態性はどのようにって、基底となるインターフェースなりクラスを
決めて、メソッドを派生クラスでオーバーライドさせるってのが普通
だと思うが... 俺はWeb屋だからTemplate Methodパターンとか
Comanndパターンをよく使うな。
>>430
> 「多態性は、どのように実装しているかを教えてくれ」
コードレベルならアブストラクトファクトリとインターフェースで使ってるだろ
作業員はポリモであることは意識せずにいるな
あと外部イテレータとあわせて処理振り分ける
設計時にポリモ意識させるときはクラス図にでっかい枠引いてわかりやすくするな
その枠はコラボ図のハコと同じ扱い、あやしくなったらコラボ図持って間違ってないか相談
その枠残すか消すかはゆっくり考える
> 「多態性は、どのように実装しているかを教えてくれ」
コードレベルならアブストラクトファクトリとインターフェースで使ってるだろ
作業員はポリモであることは意識せずにいるな
あと外部イテレータとあわせて処理振り分ける
設計時にポリモ意識させるときはクラス図にでっかい枠引いてわかりやすくするな
その枠はコラボ図のハコと同じ扱い、あやしくなったらコラボ図持って間違ってないか相談
その枠残すか消すかはゆっくり考える
プレゼンテーションなんかOO分析的に見てどうでもいいだろ
そうもいっとられん。エンドユーザはUIの出来で
システムの評価が大きく変わるから。
システムの評価が大きく変わるから。
>393の口調が微妙におじゃばっぽくなってるのがちょっとだけ気になるｗ
しーっｗ 言うなｗ
他人の振りしてOO勉強しようとする姿勢は評価できる
>>431
なぜ、継承を使わない？オブジェクト指向の最大の利点の一つは
継承を使って差分プログラムが可能にすることだ。 それがデグレードのリスクを
最小限にし、テスト範囲を最小にすることが出来るからオブジェクト指向で作るんだろう。
とくにリリース後の改修なら、運用で揉まれて品質の高いクラスを修正する必要はない
とは言っても現場の方針で、そう決まっていれば従うしかないが．．．
>>432
俺には意味が分らん、「おじゃばさま」の相手をしてくれ
>>433
>項目の増減に継承で対応するのは本来のOOの使いかたじゃないよね。
俺とは考えが違うな、上でも書いたが差分プログラムこそが
オブジェクト指向が保守性を向上する為に、導入された機構だと思っている
>多態性はどのようにって、基底となるインターフェースなりクラスを
>決めて、メソッドを派生クラスでオーバーライドさせるってのが普通
多分俺の考えと同じだと思うが、
・スーパークラスから継承してサブクラスで多態性を実装する
・各クラスにインタフェースを適用して、多態性を実装する
この、二つの使い分け方を教えてくれ
>>434
>コードレベルならアブストラクトファクトリとインターフェースで使ってるだろ
いや、そんなに難しく考えられてもｗ 上の書いたように普通の多態性の話だ
それに、Abstract Factoryパターンの多態性は作成時だけだし
オブジェクトの多態性とは違うような気がするが．．．
>>437,439
失礼なｗ、お前もこっちはいいから「おじゃばさま」の相手をしてくれ
なぜ、継承を使わない？オブジェクト指向の最大の利点の一つは
継承を使って差分プログラムが可能にすることだ。 それがデグレードのリスクを
最小限にし、テスト範囲を最小にすることが出来るからオブジェクト指向で作るんだろう。
とくにリリース後の改修なら、運用で揉まれて品質の高いクラスを修正する必要はない
とは言っても現場の方針で、そう決まっていれば従うしかないが．．．
>>432
俺には意味が分らん、「おじゃばさま」の相手をしてくれ
>>433
>項目の増減に継承で対応するのは本来のOOの使いかたじゃないよね。
俺とは考えが違うな、上でも書いたが差分プログラムこそが
オブジェクト指向が保守性を向上する為に、導入された機構だと思っている
>多態性はどのようにって、基底となるインターフェースなりクラスを
>決めて、メソッドを派生クラスでオーバーライドさせるってのが普通
多分俺の考えと同じだと思うが、
・スーパークラスから継承してサブクラスで多態性を実装する
・各クラスにインタフェースを適用して、多態性を実装する
この、二つの使い分け方を教えてくれ
>>434
>コードレベルならアブストラクトファクトリとインターフェースで使ってるだろ
いや、そんなに難しく考えられてもｗ 上の書いたように普通の多態性の話だ
それに、Abstract Factoryパターンの多態性は作成時だけだし
オブジェクトの多態性とは違うような気がするが．．．
>>437,439
失礼なｗ、お前もこっちはいいから「おじゃばさま」の相手をしてくれ
気に入った。
× AbstractFactoryパターン
× Abstract Factory
× アブストラクトファクトリ
○ Abstract Factoryパターン
用語をきっちり使える人間は、話になる。
× AbstractFactoryパターン
× Abstract Factory
× アブストラクトファクトリ
○ Abstract Factoryパターン
用語をきっちり使える人間は、話になる。
>>441
コピペだからじゃないのか。
コピペだからじゃないのか。
差分プログラムにしたからテスト範囲が最小になるって考えは危険じゃね？
デグレードが恐いなら最初からテストドリブンにしといた方がいいよ。
リファクタリングにも有効だし。
デグレードが恐いなら最初からテストドリブンにしといた方がいいよ。
リファクタリングにも有効だし。
>>440
＞継承を使って
中略
＞品質の高いクラスを修正する必要はない
まず、継承して修正したところで基本的に、継承元のクラスは他のクラスが
継承することは無いし、オーバーライドされたメソッドはこの先利用されない。
次に、UIの入力項目が増えても、モデルを変更する必要が無いような修正であれば、
修正用に新規に作成されたクラスのテストを行うのと同じ程度のコストで
クラスを改修した場合のテストが行えるように、クラスの修正が出来る。
もしそれが出来ないならクラス設計とクラス内部の構造化がうまく出来て無いよ。
最後に、使用されないコードが残っていると保守性が下がる。
要は何だ。ケースバイケースだろうけど、他に派生する予定も無いのに継承で修正していく行為は、
C言語で、#ifdefとかで古いコードを全部残していくのと同じことしてるんじゃない？
＞継承を使って
中略
＞品質の高いクラスを修正する必要はない
まず、継承して修正したところで基本的に、継承元のクラスは他のクラスが
継承することは無いし、オーバーライドされたメソッドはこの先利用されない。
次に、UIの入力項目が増えても、モデルを変更する必要が無いような修正であれば、
修正用に新規に作成されたクラスのテストを行うのと同じ程度のコストで
クラスを改修した場合のテストが行えるように、クラスの修正が出来る。
もしそれが出来ないならクラス設計とクラス内部の構造化がうまく出来て無いよ。
最後に、使用されないコードが残っていると保守性が下がる。
要は何だ。ケースバイケースだろうけど、他に派生する予定も無いのに継承で修正していく行為は、
C言語で、#ifdefとかで古いコードを全部残していくのと同じことしてるんじゃない？
>>443
よく読んでみると、どうやらそのようだね。
「差分プログラムこそがオブジェクト指向が保守性を向上する為に、導入された機構」
実装の継承を有難がるのは、OOPにおいて初歩的な気がする。
「スーパークラスから継承してサブクラスで多態性を実装する」
「各クラスにインタフェースを適用して、多態性を実装する」
多態性を実装する、って言う言い方は一般的なのかな？
サブクラス群のオブジェクトは、実行時に多態性が発揮される、
っていうものかと。これは反論じゃなくて個人的な感想。
「Abstract Factoryパターンの多態性は作成時だけ」
ファクトリも製品も抽象化されっぱなしかと。
よく読んでみると、どうやらそのようだね。
「差分プログラムこそがオブジェクト指向が保守性を向上する為に、導入された機構」
実装の継承を有難がるのは、OOPにおいて初歩的な気がする。
「スーパークラスから継承してサブクラスで多態性を実装する」
「各クラスにインタフェースを適用して、多態性を実装する」
多態性を実装する、って言う言い方は一般的なのかな？
サブクラス群のオブジェクトは、実行時に多態性が発揮される、
っていうものかと。これは反論じゃなくて個人的な感想。
「Abstract Factoryパターンの多態性は作成時だけ」
ファクトリも製品も抽象化されっぱなしかと。
Aクラスに数値型の属性を2つ追加したいから、Aクラスを継承してBクラスをつくりました。
その後、さらに文字型の属性が1つ追加になったため、さらにBクラスを継承してCクラスを
つくりました。そしてその後、Bクラスに追加した属性の1つが、実は数値型ではなく文字列
型になり、さらに1つ不要な属性を削除しなければならなくなりました、とかなったらどうす
るんだろうね、このおじゃ、もとい、>>440は。
その後、さらに文字型の属性が1つ追加になったため、さらにBクラスを継承してCクラスを
つくりました。そしてその後、Bクラスに追加した属性の1つが、実は数値型ではなく文字列
型になり、さらに1つ不要な属性を削除しなければならなくなりました、とかなったらどうす
るんだろうね、このおじゃ、もとい、>>440は。
>>441,443
たしかに、コピペだｗ ただ元のソースも自分で書いたが
しかし、「アブストラクトファクトリ」はインパクトあるな、最初は何か分らなかったｗ
>>442
もしかして、「おじゃばさま」か？どれかに「おじゃばさま」が紛れ込んでいる気がするがｗ
「おじゃばさま」、この質問が終わったら消えるから、心配するな
>>444
>差分プログラムにしたからテスト範囲が最小になるって考えは危険じゃね？
たしかに言い過ぎた。これは訂正しとく、どんな時でもテストは慎重にやらないと駄目だな
>>445
>まず、継承して修正したところで基本的に、継承元のクラスは他のクラスが
>継承することは無いし、オーバーライドされたメソッドはこの先利用されない。
なぜだ、なぜ断言出来る？継承元のクラスも普通に使うだろ？
それに、継承元にメソッドを使わないなら、多態性じゃないだろう（抽象メソッドは別だが）
>修正用に新規に作成されたクラスのテストを行うのと同じ程度のコストで
>クラスを改修した場合のテストが行えるように、クラスの修正が出来る。
たしかに、注意してやればそれでも良いが（実際多くの現場がそうしているし）
しかし、だれもデグレードをしようしてする奴はいない
だから、ソースレベルじゃなく継承で行なうべきだと俺は思う
これは長くなりそうだから、これくらいにしとく。
たしかに、コピペだｗ ただ元のソースも自分で書いたが
しかし、「アブストラクトファクトリ」はインパクトあるな、最初は何か分らなかったｗ
>>442
もしかして、「おじゃばさま」か？どれかに「おじゃばさま」が紛れ込んでいる気がするがｗ
「おじゃばさま」、この質問が終わったら消えるから、心配するな
>>444
>差分プログラムにしたからテスト範囲が最小になるって考えは危険じゃね？
たしかに言い過ぎた。これは訂正しとく、どんな時でもテストは慎重にやらないと駄目だな
>>445
>まず、継承して修正したところで基本的に、継承元のクラスは他のクラスが
>継承することは無いし、オーバーライドされたメソッドはこの先利用されない。
なぜだ、なぜ断言出来る？継承元のクラスも普通に使うだろ？
それに、継承元にメソッドを使わないなら、多態性じゃないだろう（抽象メソッドは別だが）
>修正用に新規に作成されたクラスのテストを行うのと同じ程度のコストで
>クラスを改修した場合のテストが行えるように、クラスの修正が出来る。
たしかに、注意してやればそれでも良いが（実際多くの現場がそうしているし）
しかし、だれもデグレードをしようしてする奴はいない
だから、ソースレベルじゃなく継承で行なうべきだと俺は思う
これは長くなりそうだから、これくらいにしとく。
>>446
>サブクラス群のオブジェクトは、実行時に多態性が発揮される、
>っていうものかと。これは反論じゃなくて個人的な感想。
俺が聞いているのは、多態性の使い方じゃない、実装時の方針だ
>ファクトリも製品も抽象化されっぱなしかと。
おれには、「抽象化されっぱなし」が分らん「抽象化」は「おじゃばさま」に聞いてくれ
俺が言いたいのは、本来の多態性はメソッドを呼ばれた後
自メソッド・継承元メソッドのどちらを呼び出すか、動的に変えられる仕組みがあるが
Abstract Factoryパターンでクラス作成した時点でメソッドは決まっている。
これからは、「おじゃばさま」に聞いてくれ
>>447
>さらに1つ不要な属性を削除しなければならなくなりました、とかなったらどうす
>るんだろうね、このおじゃ、もとい、>>440は。
>俺は、項目の削除もクラスの拡張（継承）という形でやっている(>>430)
これからは、「おじゃばさま」に聞いてくれ
>サブクラス群のオブジェクトは、実行時に多態性が発揮される、
>っていうものかと。これは反論じゃなくて個人的な感想。
俺が聞いているのは、多態性の使い方じゃない、実装時の方針だ
>ファクトリも製品も抽象化されっぱなしかと。
おれには、「抽象化されっぱなし」が分らん「抽象化」は「おじゃばさま」に聞いてくれ
俺が言いたいのは、本来の多態性はメソッドを呼ばれた後
自メソッド・継承元メソッドのどちらを呼び出すか、動的に変えられる仕組みがあるが
Abstract Factoryパターンでクラス作成した時点でメソッドは決まっている。
これからは、「おじゃばさま」に聞いてくれ
>>447
>さらに1つ不要な属性を削除しなければならなくなりました、とかなったらどうす
>るんだろうね、このおじゃ、もとい、>>440は。
>俺は、項目の削除もクラスの拡張（継承）という形でやっている(>>430)
これからは、「おじゃばさま」に聞いてくれ
継承するってことは継承元のプライベートメンバとメソッドにアクセス
できなくなるってことだよねぇ。そんな都合よく継承できるってことは
最初の設計がそれをみこしてよっぽど緩い設計になってんだな。
できなくなるってことだよねぇ。そんな都合よく継承できるってことは
最初の設計がそれをみこしてよっぽど緩い設計になってんだな。
>>448
＞修正に継承云々
あぁ、なんとなく分かった。
俺が思ってたのは、入力項目が何かのクラスの属性になってて、
そのクラスの属性を増やす代わりに継承してクラスを置き換える程度の修正だと思ってたんだが、
もっと歴然とした「機能追加」か。
よく見たら確かに話の出だしで「この話と直接は関係ない」言ってるな。
すまんすまん。
＞修正に継承云々
あぁ、なんとなく分かった。
俺が思ってたのは、入力項目が何かのクラスの属性になってて、
そのクラスの属性を増やす代わりに継承してクラスを置き換える程度の修正だと思ってたんだが、
もっと歴然とした「機能追加」か。
よく見たら確かに話の出だしで「この話と直接は関係ない」言ってるな。
すまんすまん。
とりあえず、おじゃばは393以降の流れはレス禁止という事でおＫ？
ちょwwｗぉまwww本人以外ダレがおじゃばに「さま」なんかつけるかぁwww
そんで>449
>これからは、「おじゃばさま」に聞いてくれ
どんだけさびしがりなんだよ、おじゃばぁ、ﾊﾗｲﾃｪw
そんで>449
>これからは、「おじゃばさま」に聞いてくれ
どんだけさびしがりなんだよ、おじゃばぁ、ﾊﾗｲﾃｪw
こいつ多様性が何かわかって無くないか？
今週”も”ひどい自演を見るんだろうな
457 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/25(月) 09:27:58
>>395
ユースケース書くとなると、
「商品を仕入れる」「商品を出荷する」「在庫数を調べる」になるな。
>>410-418
普通に考えると413と同じようになる。しかし粒度が大きすぎるとも思う。ただ他に思いつかない。
413にした時の問題は、手間をかけてそういう設計にしても、実際には利点がほとんどない事だ。
OO的には管理する商品や手順が変わっても、変更が少ないと言う事になるが、実際にそこまで変更が
入るような事は少ないし、実際の業務に対応させるなら、ある程度特化した作り込みが必要になる。
それを分離して多くのパターンに対応させようとすると、何にも使えないような物になってしまう。
実際は413の設計で、さらにかなり業務に特化して作るようになると思うのだが、これでいいのか？
>>多態性と継承/IF使い分け方法議論の人
俺はこんなの悩んでないぞ。自演というのは明らかに人違いだ。
多態性はメソッドで解決。
IFは多重継承の代わりに使用。使用例はThread。
ユースケース書くとなると、
「商品を仕入れる」「商品を出荷する」「在庫数を調べる」になるな。
>>410-418
普通に考えると413と同じようになる。しかし粒度が大きすぎるとも思う。ただ他に思いつかない。
413にした時の問題は、手間をかけてそういう設計にしても、実際には利点がほとんどない事だ。
OO的には管理する商品や手順が変わっても、変更が少ないと言う事になるが、実際にそこまで変更が
入るような事は少ないし、実際の業務に対応させるなら、ある程度特化した作り込みが必要になる。
それを分離して多くのパターンに対応させようとすると、何にも使えないような物になってしまう。
実際は413の設計で、さらにかなり業務に特化して作るようになると思うのだが、これでいいのか？
>>多態性と継承/IF使い分け方法議論の人
俺はこんなの悩んでないぞ。自演というのは明らかに人違いだ。
多態性はメソッドで解決。
IFは多重継承の代わりに使用。使用例はThread。
はいはい。別人別人ｗ
これは所謂、別人マスター(笑)ですかねｗ
多態性を実践してるんじゃね？
あいかわらず迷走しているスレはここですかｗ
コテハンはインタフェースだから本人は隠蔽されてるわけだｗ
が、Javaだからfriendがないとｗ
が、Javaだからfriendがないとｗ
>IFは多重継承の代わりに使用。使用例はThread。
これってJavaの事前提で言ってるんだよな・・・。
これってJavaの事前提で言ってるんだよな・・・。
465 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/25(月) 19:50:01
>>462
JavaだとRunnableインタフェースとかだよ。詳しくは「トップダウン男」に聞けば？
あと、言っておきたいのが、「預言者クン」についてだ。
俺の次の行動を予測するのはいいが、外れた時は悲惨だから、少し考えてからやった方がいいと思う。
自分の希望ではなくて、俺の気持ちになって考えるのがコツだ。まあ無理だと思うが。
それと、別人を俺の自演だと言うのは構わないが、俺は自演しないので止めた方がいいと思う。
特に、454のように思い込みとか、「ﾊﾗｲﾃｪw」とか書かれていると、憐れとしか言えない。
少なくとも、俺と俺に間違われた人には、自演かどうかは分かっている。
自演でないと分かっているとして、454の文章を読んでみな。痛すぎるだろう？
JavaだとRunnableインタフェースとかだよ。詳しくは「トップダウン男」に聞けば？
あと、言っておきたいのが、「預言者クン」についてだ。
俺の次の行動を予測するのはいいが、外れた時は悲惨だから、少し考えてからやった方がいいと思う。
自分の希望ではなくて、俺の気持ちになって考えるのがコツだ。まあ無理だと思うが。
それと、別人を俺の自演だと言うのは構わないが、俺は自演しないので止めた方がいいと思う。
特に、454のように思い込みとか、「ﾊﾗｲﾃｪw」とか書かれていると、憐れとしか言えない。
少なくとも、俺と俺に間違われた人には、自演かどうかは分かっている。
自演でないと分かっているとして、454の文章を読んでみな。痛すぎるだろう？
ところで、迷彩で、挑発と擁護と否定で自演しているわけだけど、何でおじゃば以外みんな書き込まないの？
>>467
おじゃば以外誰もいないからに決まってるだろうが。
おじゃば以外誰もいないからに決まってるだろうが。
>>468
そうか、おじゃばも自作自演大変だな。
そうか、おじゃばも自作自演大変だな。
>>469
んだ、大変だ。
んだ、大変だ。
痛すぎる低能がなんか言うとりますが、
どこで人格形成誤ったのか誰か分析して
どこで人格形成誤ったのか誰か分析して
>465
> 俺の次の行動を予測するのはいいが、外れた時は悲惨だから、少し考えてからやった方がいいと思う。
> 自分の希望ではなくて、俺の気持ちになって考えるのがコツだ。まあ無理だと思うが。
↓
>261
> ちなみに、260の次の書き込みも予想が出来るが、それに対する俺の書き込みも予想が出来ると思う。
>274
> >261
> >名前の後に#と任意の文字列を追加する。
>
> >167
> >まさかIDってトリップのことじゃないよね？ ね？
>
>
> お馬鹿な君の回答は先読みされてますよ？
もしかして、自虐プレイですか？
> 俺の次の行動を予測するのはいいが、外れた時は悲惨だから、少し考えてからやった方がいいと思う。
> 自分の希望ではなくて、俺の気持ちになって考えるのがコツだ。まあ無理だと思うが。
↓
>261
> ちなみに、260の次の書き込みも予想が出来るが、それに対する俺の書き込みも予想が出来ると思う。
>274
> >261
> >名前の後に#と任意の文字列を追加する。
>
> >167
> >まさかIDってトリップのことじゃないよね？ ね？
>
>
> お馬鹿な君の回答は先読みされてますよ？
もしかして、自虐プレイですか？
>>457
＞手間をかけてそういう設計にしても
まだ分析だけです。
＞実際には利点がほとんどない事だ。
実際には分析する必要も無いほどシンプルなものを無理から分析しておいて
「利点がほとんどない」って何が言いたいんだ？
＞実際は413の設計で、さらにかなり業務に特化して作るようになると思うのだが、これでいいのか？
業務に特化した部分はユースケースに出てくる。
暇つぶしにもならん。
もうちょっとマトモな事書いてくれ。
＞手間をかけてそういう設計にしても
まだ分析だけです。
＞実際には利点がほとんどない事だ。
実際には分析する必要も無いほどシンプルなものを無理から分析しておいて
「利点がほとんどない」って何が言いたいんだ？
＞実際は413の設計で、さらにかなり業務に特化して作るようになると思うのだが、これでいいのか？
業務に特化した部分はユースケースに出てくる。
暇つぶしにもならん。
もうちょっとマトモな事書いてくれ。
476 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/26(火) 09:36:56
>>466-470,474
いや別に、怒っている訳でも、止めて欲しい訳でもないんだ。
チャック開けたままの人を注意しないと、罪悪感が残るだろう？
つまり俺は自分の罪悪感をなくしたいだけなんだ。
一回注意すれば、自分の罪悪感はなくなるから、あとは存分に電波トーク続けてくれ。
むしろ続けてくれた方が、ネタになるしな。
>>472
それは予想したかったのではなく、次の俺の発言を省略したかっただけだよ。
難しかったかな？
>>473
誰？OOマスターでもトップダウン男でもないように見えるが。
俺が命名してやろうか？愚痴厨でどうだ？
いや別に、怒っている訳でも、止めて欲しい訳でもないんだ。
チャック開けたままの人を注意しないと、罪悪感が残るだろう？
つまり俺は自分の罪悪感をなくしたいだけなんだ。
一回注意すれば、自分の罪悪感はなくなるから、あとは存分に電波トーク続けてくれ。
むしろ続けてくれた方が、ネタになるしな。
>>472
それは予想したかったのではなく、次の俺の発言を省略したかっただけだよ。
難しかったかな？
>>473
誰？OOマスターでもトップダウン男でもないように見えるが。
俺が命名してやろうか？愚痴厨でどうだ？
>>476
はいはい、なくなって良かったね、罪悪感ｗ
はいはい、なくなって良かったね、罪悪感ｗ
昔から思ってたけど
このひとネーミングセンス酷すぎんか？
おじゃば～とかって時点で小学生でも恥ずかしがりそうだけど
このひとネーミングセンス酷すぎんか？
おじゃば～とかって時点で小学生でも恥ずかしがりそうだけど
480 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/26(火) 19:43:52
>>478
「おじゃばさま」は残念ながら、俺のネーミングではないんだよな。
誰かに侮蔑的に言われたのを敢えて使っている。最近は気に入っている。
ついでに、「ﾊﾗｲﾃｪw」も命名しておこう。
腹で電波受信するみたいだから、「ﾊﾗ電波」なんてどうよ。
「おじゃばさま」は残念ながら、俺のネーミングではないんだよな。
誰かに侮蔑的に言われたのを敢えて使っている。最近は気に入っている。
ついでに、「ﾊﾗｲﾃｪw」も命名しておこう。
腹で電波受信するみたいだから、「ﾊﾗ電波」なんてどうよ。
自分で付けたものでないにせよ
気に入ってる時点でセンスがないことにはかわりないんじゃないの？
気に入ってる時点でセンスがないことにはかわりないんじゃないの？
483 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/26(火) 20:20:42
>>481
いや、ﾊﾗ電波は見込みあると思っている。もう一度出て来たら勇者と認定する。
名前空間マスター(笑) か。発想はまあまあだが、センスは悪いな。
俺なら、ネームスペーサーとかにするね。
>>482
それは言える。
いや、ﾊﾗ電波は見込みあると思っている。もう一度出て来たら勇者と認定する。
名前空間マスター(笑) か。発想はまあまあだが、センスは悪いな。
俺なら、ネームスペーサーとかにするね。
>>482
それは言える。
>>483
やっぱセンスねぇよｗ
やっぱセンスねぇよｗ
アホコテがくると荒れる
センスの欠片もねぇな
なんだ、俺の質問に誰も答えてくれないな,、そろそろ消えるか
しかし答えたくれたのが、俺が答えるなと言った「おじゃばさま」だけとは．．．
>>457
>俺はこんなの悩んでないぞ。自演というのは明らかに人違いだ。
>多態性はメソッドで解決。
>IFは多重継承の代わりに使用。使用例はThread。
まっ、単純に考えるのも間違いではないが「俺はこんなの悩んでないぞ」が気になるな
俺には、「おじゃばさま」の質問の方がよっぽど迷わんが
俺の枝葉の質問と違って「おじゃばさま」の質問は、基本だから書籍や資料を参考にすれば分ることだろ
「おじゃばさま」は、分析／設計をやったことがあるのか？
しかし答えたくれたのが、俺が答えるなと言った「おじゃばさま」だけとは．．．
>>457
>俺はこんなの悩んでないぞ。自演というのは明らかに人違いだ。
>多態性はメソッドで解決。
>IFは多重継承の代わりに使用。使用例はThread。
まっ、単純に考えるのも間違いではないが「俺はこんなの悩んでないぞ」が気になるな
俺には、「おじゃばさま」の質問の方がよっぽど迷わんが
俺の枝葉の質問と違って「おじゃばさま」の質問は、基本だから書籍や資料を参考にすれば分ることだろ
「おじゃばさま」は、分析／設計をやったことがあるのか？
「おじゃばさま」が俺の質問答えたから、俺も「おじゃばさま」の質問に答えてから消えるわ
>>383
>倉庫、商品などで分類したらDOAだ。
いや、オブジェクト指向でもそれで大丈夫だ。もともとクラス図はER図の拡張だから
そのあたりの分析は似てくる。後は棚卸をどう表現するとかが設計者のセンスが出るところだ。
この設計で俺が迷うの、商品の分類をサブクラスと内部フラグでどう表現するかだ
例えば、電化製品・書籍・食料品・飲料水などの製品と常温保管・冷蔵保管・冷凍保管が必要な商品分類があったとする
全てサブクラスにするのが一番良いと思うが、組み合わせが無数にあり
とても、全てをサブクラスで表現するのは無理だから、内部フラグとの組み合わせるしかない
それも整合性のとれたフラグじゃないといけない、例えば電化製品などに冷凍保管の有無みたいなフラグを持たせるのは間違っている
このあたりが難しいかな
あと、倉庫オブジェクトが製品オブジェクトを持つのか、逆に製品オブジェクトが倉庫オブジェクトを持つのか
普通に考えれば商品が倉庫にあるのは、ある一定期間だがら倉庫オブジェクトが製品オブジェクトを持つのが正しいと思う
その場合、１つの倉庫オブジェクトが複数の商品オブジェクトを管理するが
これをどう管理するかだ、一般的に考えればリストやChain of Responsibilityパターンなどで管理するが
オブジェクト指向らしく設計するなら、Chain of Responsibilityパターンを使う（階層で管理するなら、Compositeパターンとかでも良いが）
その制御用フィールドをどのように実装するかが難しいと思う（この制御用フィールドは商品が倉庫にある時だけしか使わんから）
以上だ、これで消えるから
>>383
>倉庫、商品などで分類したらDOAだ。
いや、オブジェクト指向でもそれで大丈夫だ。もともとクラス図はER図の拡張だから
そのあたりの分析は似てくる。後は棚卸をどう表現するとかが設計者のセンスが出るところだ。
この設計で俺が迷うの、商品の分類をサブクラスと内部フラグでどう表現するかだ
例えば、電化製品・書籍・食料品・飲料水などの製品と常温保管・冷蔵保管・冷凍保管が必要な商品分類があったとする
全てサブクラスにするのが一番良いと思うが、組み合わせが無数にあり
とても、全てをサブクラスで表現するのは無理だから、内部フラグとの組み合わせるしかない
それも整合性のとれたフラグじゃないといけない、例えば電化製品などに冷凍保管の有無みたいなフラグを持たせるのは間違っている
このあたりが難しいかな
あと、倉庫オブジェクトが製品オブジェクトを持つのか、逆に製品オブジェクトが倉庫オブジェクトを持つのか
普通に考えれば商品が倉庫にあるのは、ある一定期間だがら倉庫オブジェクトが製品オブジェクトを持つのが正しいと思う
その場合、１つの倉庫オブジェクトが複数の商品オブジェクトを管理するが
これをどう管理するかだ、一般的に考えればリストやChain of Responsibilityパターンなどで管理するが
オブジェクト指向らしく設計するなら、Chain of Responsibilityパターンを使う（階層で管理するなら、Compositeパターンとかでも良いが）
その制御用フィールドをどのように実装するかが難しいと思う（この制御用フィールドは商品が倉庫にある時だけしか使わんから）
以上だ、これで消えるから
自問自答、だけどおじゃば語だからなぁ。
職場でおじゃば、自宅で393という区切りはつけてるみたいだけど。
職場でおじゃば、自宅で393という区切りはつけてるみたいだけど。
消えるから＝土日は復活
>488
お前キモい
お前キモい
別人マスター（笑）なら、もう少し親クラスの言動を隠蔽しなきゃダメだろ？
495 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/27(水) 20:55:12
>>トップダウン男
一応、回答した努力には敬意を払うよ。愚痴厨よりは遥かにいい。
ただ、内容については全然賛同出来ない。
まず、487で基礎だから本を読めば分かると言っているのに、488が明確な答えにはなっていない。
> この設計で俺が迷うの、商品の分類をサブクラスと内部フラグでどう表現するかだ。
> （中略）
> このあたりが難しいかな
難しいなんて物じゃない、カオスだ。
商品種類と保管場所の組み合わせでサブクラスを表現？これは無理だろう。つーか無理って認めてるか。
商品で分類して、保管場所フラグを持つ？確かに無難だが、ただのDOAだろう。
倉庫オブジェクトが商品でオブジェクトを持つ？持つと言うのは管理すると言う意味だよな。
逆の商品が倉庫を管理するのは問題外だから考えない。
Chain of Responsibilityや、Compositeパターン？
イマイチ何を言いたいのか分からないが、倉庫で商品をリスト型や、階層構造で持つと言う事かな。
リストは安易だろう？シーケンシャルで処理する物か？検索も遅いだろう。
階層ってのも良いとは思えない。検索は早いだろうが、無限に収納出来るのか倉庫はないし、
あと何個入るのかも管理するのは面倒だろう。それならただの固定配列の方がマシだ。
一応、回答した努力には敬意を払うよ。愚痴厨よりは遥かにいい。
ただ、内容については全然賛同出来ない。
まず、487で基礎だから本を読めば分かると言っているのに、488が明確な答えにはなっていない。
> この設計で俺が迷うの、商品の分類をサブクラスと内部フラグでどう表現するかだ。
> （中略）
> このあたりが難しいかな
難しいなんて物じゃない、カオスだ。
商品種類と保管場所の組み合わせでサブクラスを表現？これは無理だろう。つーか無理って認めてるか。
商品で分類して、保管場所フラグを持つ？確かに無難だが、ただのDOAだろう。
倉庫オブジェクトが商品でオブジェクトを持つ？持つと言うのは管理すると言う意味だよな。
逆の商品が倉庫を管理するのは問題外だから考えない。
Chain of Responsibilityや、Compositeパターン？
イマイチ何を言いたいのか分からないが、倉庫で商品をリスト型や、階層構造で持つと言う事かな。
リストは安易だろう？シーケンシャルで処理する物か？検索も遅いだろう。
階層ってのも良いとは思えない。検索は早いだろうが、無限に収納出来るのか倉庫はないし、
あと何個入るのかも管理するのは面倒だろう。それならただの固定配列の方がマシだ。
というか、おじゃばと間違われたら、ショックのあまり一週間位ねこむだろ？
返答する気力も無くなるほど落ち込むぞ。
返答する気力も無くなるほど落ち込むぞ。
497 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/27(水) 21:09:01
つーか、ユースケースが関係ない。
基本的に従来のDOAにデザインパターンを混ぜただけに思える。
システムはあくまでも在庫管理で、ユースケースは仕入れる、出荷する、在庫数を調べるなのだから、
OOマスターの忠告を聞くとすると、それを設計しなければならないと思う。
俺なら、倉庫クラスがあったとしたら、その中で管理するのは1ダースケースクラスとか、
段ボールクラスとかにする。それぞれに収納コストなどがあって、1ダースケースは1コスト、段ボール
クラスは10コスト、倉庫100コストまで収容可能とかにする。
これなら、あと何個収容可能かとか、業務で重要になりそうな事が分かる。
もし冷凍収納が必要なら冷凍コンテナクラスや、倉庫自体を拡張して冷蔵倉庫などにする。
うまくやれば、不要な倉庫や、必要なコンテナ数や経費なども分かるようになると思う。
ただこれでいいのかは分からない。教えて、OOますたー！！
基本的に従来のDOAにデザインパターンを混ぜただけに思える。
システムはあくまでも在庫管理で、ユースケースは仕入れる、出荷する、在庫数を調べるなのだから、
OOマスターの忠告を聞くとすると、それを設計しなければならないと思う。
俺なら、倉庫クラスがあったとしたら、その中で管理するのは1ダースケースクラスとか、
段ボールクラスとかにする。それぞれに収納コストなどがあって、1ダースケースは1コスト、段ボール
クラスは10コスト、倉庫100コストまで収容可能とかにする。
これなら、あと何個収容可能かとか、業務で重要になりそうな事が分かる。
もし冷凍収納が必要なら冷凍コンテナクラスや、倉庫自体を拡張して冷蔵倉庫などにする。
うまくやれば、不要な倉庫や、必要なコンテナ数や経費なども分かるようになると思う。
ただこれでいいのかは分からない。教えて、OOますたー！！
498 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/27(水) 21:25:20
>>496
間違えた方がアフォだろう。内容を読んで理解していれば、別人だと分かる。
自演にしたがる人も命名しておくかな。
自演にしたがる理由は不明だが、何か妙な強迫観念がある気がする。
「自演観念房」にしておくか。
間違えた方がアフォだろう。内容を読んで理解していれば、別人だと分かる。
自演にしたがる人も命名しておくかな。
自演にしたがる理由は不明だが、何か妙な強迫観念がある気がする。
「自演観念房」にしておくか。
ﾊｲﾊｲﾊﾞﾛｽﾊﾞﾛｽ
>>393の方がおじゃばより微妙に馬鹿だな。
意図的かもしらんが。ま、大差はない。
意図的かもしらんが。ま、大差はない。
晒しスレから記念ﾊﾟﾋﾟｺ
2ちゃんで敵を特定したくなったらもう末期症状。
>>498
間違える方がアフォだろう。内容を読まずとも、別人ではないと分かる。
自演をしたがる人も命名しておくかな。
自演をしたがる理由は不明だが、何か妙な強迫観念がある気がする。
「自演房」にしておくか。
間違える方がアフォだろう。内容を読まずとも、別人ではないと分かる。
自演をしたがる人も命名しておくかな。
自演をしたがる理由は不明だが、何か妙な強迫観念がある気がする。
「自演房」にしておくか。
>>498
おじゃば、俺だけは味方だ、すなおになってみろよ。
みんな、自演ぐらいしたっていいじゃないか。
自宅と職場はちがう自分なんだぜ。バカだからってあんまり責めるなよ。
おじゃばはさびしかっただけなんだよ、な、おじゃば。
おじゃば、俺だけは味方だ、すなおになってみろよ。
みんな、自演ぐらいしたっていいじゃないか。
自宅と職場はちがう自分なんだぜ。バカだからってあんまり責めるなよ。
おじゃばはさびしかっただけなんだよ、な、おじゃば。
自演乙ｗ
>>506
そんな台詞って、言ってもらいたいというのもどうかしてるんじゃないのか。
そんな台詞って、言ってもらいたいというのもどうかしてるんじゃないのか。
511 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/28(木) 20:00:20
自演観念房なんてどうでもいいのだが、496のようにトップダウン男が書かない口実を与えるのは避けたい。
自演観念房や愚痴厨も内容について突っ込んだらどうだ？少しはトップダウン男を見習えよ。
それとも自演観念房も俺の自演とか言い出すのかな？ﾊﾗｲﾃｪw
自演観念房や愚痴厨も内容について突っ込んだらどうだ？少しはトップダウン男を見習えよ。
それとも自演観念房も俺の自演とか言い出すのかな？ﾊﾗｲﾃｪw
なんか混ざってきましたね
まぁ好きにすればいいけど
まぁ好きにすればいいけど
513 ：仕様書無しさん：2008/02/28(木) 20:05:36
昨日買ってきた問題でどうしてもわからない問題があったので何方か教えてください
1.以下の処理場を行うのに最適なコントロールを答えなさい
①処理を選択するコントロール②文字列やイメージを表示するコントロール
③ファイルの保存時に表示し保存用のファイル名を指定しるコントロール
④特定の範囲の数値を指定するコントロール［整数値のみ扱う］
⑤イメージファイルを格納して管理するコントロール
⑥複数の選択欄から一つを選択するコントロール
⑦一覧のアイテムの中から選択するコントロール［キー入力はできない］
1.以下の処理場を行うのに最適なコントロールを答えなさい
①処理を選択するコントロール②文字列やイメージを表示するコントロール
③ファイルの保存時に表示し保存用のファイル名を指定しるコントロール
④特定の範囲の数値を指定するコントロール［整数値のみ扱う］
⑤イメージファイルを格納して管理するコントロール
⑥複数の選択欄から一つを選択するコントロール
⑦一覧のアイテムの中から選択するコントロール［キー入力はできない］
宿題は自力でやりましょう
でないと成長しませんよ
でないと成長しませんよ
前提の用語の合意もなく、問題を出したがるのはおじゃば。以上。
>>511
>自演観念房や愚痴厨も内容について突っ込んだらどうだ？
もまいは、最近価値が無くなって来たんだよ。
ついでに劣化具合から最後の時が近づいてきたので、
昔なら去る連中が自演観念房や愚痴厨となって遊んでいる。
まともな質問はだんだん無くなってくるぞ。リピータは大事にしろよ。
>自演観念房や愚痴厨も内容について突っ込んだらどうだ？
もまいは、最近価値が無くなって来たんだよ。
ついでに劣化具合から最後の時が近づいてきたので、
昔なら去る連中が自演観念房や愚痴厨となって遊んでいる。
まともな質問はだんだん無くなってくるぞ。リピータは大事にしろよ。
517 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/28(木) 20:38:43
キャラクター紹介
おじゃばさま：俺。オブジェクト指向研究に命ををかける。常に喧嘩腰。
OOマスター：オブジェクト指向設計に詳しい。
トップダウン男：構造化は得意だが、オブジェクト指向は苦手。用語には詳しいがたまに使い方を間違える。
予言師：予言をするが外れる。預言者+詐欺師。
ﾊﾗ電波：妄想してそれに対して笑う。腹で電波を受信する。決め台詞はﾊﾗｲﾃｪw。
愚痴厨：愚痴しか言わない。
自演観念房：全て自演だと言い張る。
Cマスター（笑）：C言語と、業務基礎（DB、通信、サーバ）が出来る人。笑われているが意外と少ない。
ココ電球：C言語とアセンブラが得意だが、開発方法が我流。
69式おっさん：C言語マスター。底が見えない。
伊賀知己：数々の2ch忍法を使う。分身の術、身代わりの術、自爆。
タカヒロきゅん萌え：伊賀知己の別名。敵は全てタカヒロにされてしまう。
C厨：長年やっていても、C言語しか出来ない
Java房：長年やっていても、Javaしか出来ない。
コボラー：長年やっていても、COBOLしか出来ない。今は結構希少。
おじゃばさま：俺。オブジェクト指向研究に命ををかける。常に喧嘩腰。
OOマスター：オブジェクト指向設計に詳しい。
トップダウン男：構造化は得意だが、オブジェクト指向は苦手。用語には詳しいがたまに使い方を間違える。
予言師：予言をするが外れる。預言者+詐欺師。
ﾊﾗ電波：妄想してそれに対して笑う。腹で電波を受信する。決め台詞はﾊﾗｲﾃｪw。
愚痴厨：愚痴しか言わない。
自演観念房：全て自演だと言い張る。
Cマスター（笑）：C言語と、業務基礎（DB、通信、サーバ）が出来る人。笑われているが意外と少ない。
ココ電球：C言語とアセンブラが得意だが、開発方法が我流。
69式おっさん：C言語マスター。底が見えない。
伊賀知己：数々の2ch忍法を使う。分身の術、身代わりの術、自爆。
タカヒロきゅん萌え：伊賀知己の別名。敵は全てタカヒロにされてしまう。
C厨：長年やっていても、C言語しか出来ない
Java房：長年やっていても、Javaしか出来ない。
コボラー：長年やっていても、COBOLしか出来ない。今は結構希少。
>>517
ココ電だの69式オサーンだの、見捨てられた相手がそんなに恋しいのか。よしよし。
俺だけはそばにいてやるから安心しろw
あ、そうだ、Cマスター(笑)はおじゃば自身のことだから誇っていいぞ。
みんなそう褒めてるのに気がつかないのはさすがにおじゃばは謙虚だな。りっぱだ。
ココ電だの69式オサーンだの、見捨てられた相手がそんなに恋しいのか。よしよし。
俺だけはそばにいてやるから安心しろw
あ、そうだ、Cマスター(笑)はおじゃば自身のことだから誇っていいぞ。
みんなそう褒めてるのに気がつかないのはさすがにおじゃばは謙虚だな。りっぱだ。
キャラクター紹介
おじゃばさま：
スレ荒らし常習者。
オブジェクト指向研究に命ををかけると自称するが中身はゲッターセッターバカ。
知識はOOPに限定され、分析・設計は夏休みの独自研究レベルのためことごとく論破される。
内容のない長文の連投でごまかすのは得意。
常に断定口調だが根拠はなく、「俺が根拠」。
前提を提示しないのはデフォ。
謙虚さに欠けるなど人格の問題が多々見られ、「( ´_ゝ`)ふーん」されることもしばしば。
「ちなみに」「だから」「とりあえず」、これらの文章に意味は無い。
社会人としての常識は通じない。
友人ゼロ。職場孤立。低能。
補完よろ
おじゃばさま：
スレ荒らし常習者。
オブジェクト指向研究に命ををかけると自称するが中身はゲッターセッターバカ。
知識はOOPに限定され、分析・設計は夏休みの独自研究レベルのためことごとく論破される。
内容のない長文の連投でごまかすのは得意。
常に断定口調だが根拠はなく、「俺が根拠」。
前提を提示しないのはデフォ。
謙虚さに欠けるなど人格の問題が多々見られ、「( ´_ゝ`)ふーん」されることもしばしば。
「ちなみに」「だから」「とりあえず」、これらの文章に意味は無い。
社会人としての常識は通じない。
友人ゼロ。職場孤立。低能。
補完よろ
522 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/29(金) 09:16:08
↑などと書くのが愚痴厨。
特徴：OOの内容には触れず、延々と愚痴を言う。
特徴：OOの内容には触れず、延々と愚痴を言う。
>>522
どこが愚痴なんだ？
ぐ‐ち【愚痴】
（1）〔仏〕理非の区別のつかないおろかさ。「―邪見」
（2）言っても仕方のないことを言って嘆くこと。また、その言葉。「―をこぼす」「―を聞いてやる」
→愚痴の闇
広辞苑 第六版 (C)2008 株式会社岩波書店
まあ普通は(2)の意味なんだろうけど、>521はどう見ても「嘆いて」はいねーだろ。
まあ言葉の意味がおかしいのはおじゃばのデフォだからしかたあるまい。
がんばれやｗ
どこが愚痴なんだ？
ぐ‐ち【愚痴】
（1）〔仏〕理非の区別のつかないおろかさ。「―邪見」
（2）言っても仕方のないことを言って嘆くこと。また、その言葉。「―をこぼす」「―を聞いてやる」
→愚痴の闇
広辞苑 第六版 (C)2008 株式会社岩波書店
まあ普通は(2)の意味なんだろうけど、>521はどう見ても「嘆いて」はいねーだろ。
まあ言葉の意味がおかしいのはおじゃばのデフォだからしかたあるまい。
がんばれやｗ
524 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/29(金) 09:50:52
>>518
ﾊﾗ電波なら、
「おじゃば、そんなに悔しかったのか。
あまりの悔しさに、ハンカチ握り締めたまま、涙で枕を水没させて、溺死しかけて、
救急車呼んで、病院たらい回しされてるんだろ。ﾊﾗｲﾃｪw」
ぐらいやって欲しかったな。
>>523
なぜ悪口ではなく愚痴か説明しよう。
俺に対して、無知と言っても、俺が以前に示した知識を知らない人は、俺より無知と言う事になる。
同様にOOの議論に参加しない人は、俺よりOOを知らないと言う事になる。
そして想像に基づいた根拠で俺を非難する人は、俺より性格が悪いと言える。
愚痴厨の俺に対する殆どの悪口は、負け犬の遠吠えに聞こえる。
つまり俺にとっては、哀れな嘆きにしか聞こえないのである。
ﾊﾗ電波なら、
「おじゃば、そんなに悔しかったのか。
あまりの悔しさに、ハンカチ握り締めたまま、涙で枕を水没させて、溺死しかけて、
救急車呼んで、病院たらい回しされてるんだろ。ﾊﾗｲﾃｪw」
ぐらいやって欲しかったな。
>>523
なぜ悪口ではなく愚痴か説明しよう。
俺に対して、無知と言っても、俺が以前に示した知識を知らない人は、俺より無知と言う事になる。
同様にOOの議論に参加しない人は、俺よりOOを知らないと言う事になる。
そして想像に基づいた根拠で俺を非難する人は、俺より性格が悪いと言える。
愚痴厨の俺に対する殆どの悪口は、負け犬の遠吠えに聞こえる。
つまり俺にとっては、哀れな嘆きにしか聞こえないのである。
>>524
えらい後付だなｗ、意味が分からんけど。ま元気でよろしい。がんばりなよ。
えらい後付だなｗ、意味が分からんけど。ま元気でよろしい。がんばりなよ。
元気そうでなによりだ。
ところで、OOネタ投下しないのそれとも
>「関数引数の実行順序は保証されない。」
OOと関係ないネタまだ引っ張っているつもりなの？
漏れの知っている限り、bccは7、8年位前にwindowsで、10年前はDos環境で
有名だったコンパイラなんだが。そんな環境で開発しているのか？ソラリスどこいった？
bccとしても213からして、内容からして関数引数の実行順序はあんまし関係ないし。
ああ、予言するがこれは無視するか適当な因縁つけて言い訳するか
回答済みで終わらせるだろうな～と言って置こう。
ところで、OOネタ投下しないのそれとも
>「関数引数の実行順序は保証されない。」
OOと関係ないネタまだ引っ張っているつもりなの？
漏れの知っている限り、bccは7、8年位前にwindowsで、10年前はDos環境で
有名だったコンパイラなんだが。そんな環境で開発しているのか？ソラリスどこいった？
bccとしても213からして、内容からして関数引数の実行順序はあんまし関係ないし。
ああ、予言するがこれは無視するか適当な因縁つけて言い訳するか
回答済みで終わらせるだろうな～と言って置こう。
とうとう元気かどうか心配されるまでになったか。おかわいそうに。
>>528
コピペだからじゃないのか。って>441？
コピペだからじゃないのか。って>441？
530 ：おじゃばさま ◆GxjxF3yEw6 ：2008/02/29(金) 20:33:00
>>526
OOネタは497で提示中だ。
もっといい設計があれば、どんどん提示してくれ。
引数の実行順序なんてもう解決しているが、無視すると予言が当たってしまうので何か書こう。
まずbccを使って検証したのは俺じゃない。
bccの昔話をされても興味ないが、bccと言えば普通はBorland C++ Builderの事だろう。
今のバージョンは5.5。使っている人も多いと思うが？特にCORBA使う人とか。
OOネタは497で提示中だ。
もっといい設計があれば、どんどん提示してくれ。
引数の実行順序なんてもう解決しているが、無視すると予言が当たってしまうので何か書こう。
まずbccを使って検証したのは俺じゃない。
bccの昔話をされても興味ないが、bccと言えば普通はBorland C++ Builderの事だろう。
今のバージョンは5.5。使っている人も多いと思うが？特にCORBA使う人とか。
>>530
あ～あ、そこで知ったかでCORBAとか書かずにおれないおじゃばがかわいいｗ
あ～あ、そこで知ったかでCORBAとか書かずにおれないおじゃばがかわいいｗ
＞bccと言えば普通はBorland C++ Builderの事だろう。
＞今のバージョンは5.5。
どこの素人さん？
もうちょいググってらっしゃいな。
＞今のバージョンは5.5。
どこの素人さん？
もうちょいググってらっしゃいな。
smalltalkもsqueakも話題に上らないスレなんだな。
明日は>393が登場か
236のおじゃば発言から213はおじゃばの言ってること(らしい)なわけで、
でも、213から関数の実行順序が問題じゃないって明らかなわけだが。
おじゃば的に何を解決したのだろうか、さっぱりわからないのだが・・・。
だれか説明してけろ。
でも、213から関数の実行順序が問題じゃないって明らかなわけだが。
おじゃば的に何を解決したのだろうか、さっぱりわからないのだが・・・。
だれか説明してけろ。
↑終わってるぞ、空気よめるか？
え、このスレ空気読んでレスする必要性ってあるの？
だったら、撤回するわ、おじゃば返答せんでよいよ。
返答しないと予言する(ｗ。まじで返答するなよおじゃば(ｗ。
いやー、空気読むのって難しいわ。
だったら、撤回するわ、おじゃば返答せんでよいよ。
返答しないと予言する(ｗ。まじで返答するなよおじゃば(ｗ。
いやー、空気読むのって難しいわ。
うゎ、うぜ～
アホコテがいい気になってCコンパイラの癖とか分析と設計は同じとか強弁するのを、
周囲が検証して結局はアホコテがまた無知を晒しただけのことだろ
しかしそれを認めず長文でごまかしただけ
このスレのデフォじゃん
本人のプライドはズタズタなんだが、
それすらも認めたくないっていういつもの展開
周囲が検証して結局はアホコテがまた無知を晒しただけのことだろ
しかしそれを認めず長文でごまかしただけ
このスレのデフォじゃん
本人のプライドはズタズタなんだが、
それすらも認めたくないっていういつもの展開
>>536
俺213だけど、俺もおじゃばの自演にされちゃうのか。
わざわざフリーのbcc5.5落としてきて登録までして試したのに･･･
┏━┿━┓
┃ 人 ┃
┃ （__） ┃
┃ ┃
┃ ┃
┻ ┻
∧∧
/⌒ヽ)
i三 ∪
～三 |
(/~∪
俺213だけど、俺もおじゃばの自演にされちゃうのか。
わざわざフリーのbcc5.5落としてきて登録までして試したのに･･･
┏━┿━┓
┃ 人 ┃
┃ （__） ┃
┃ ┃
┃ ┃
┻ ┻
∧∧
/⌒ヽ)
i三 ∪
～三 |
(/~∪
遺憾のイを表明した>>541と同様、
俺は不満のフを表明する
俺は不満のフを表明する
543 ：536：2008/03/01(土) 09:53:00
・・・おじゃばが自分のやった事を213が検証しているだろうといっているので・・・
×236のおじゃば発言から213はおじゃばの言ってること(らしい)なわけで、
○236のおじゃば発言から213はおじゃばが言いたかった事(らしい)なわけで、
213に正式に謝罪する。542にもしておきます。
さて頸つるか・・・。
┏━┿━┓
┃ 人 ┃
┃ （__） ┃
┃ ┃
┃ ┃
┻ ┻
∧∧
/⌒ヽ)
i三 ∪
～三 |
(/~∪
×236のおじゃば発言から213はおじゃばの言ってること(らしい)なわけで、
○236のおじゃば発言から213はおじゃばが言いたかった事(らしい)なわけで、
213に正式に謝罪する。542にもしておきます。
さて頸つるか・・・。
┏━┿━┓
┃ 人 ┃
┃ （__） ┃
┃ ┃
┃ ┃
┻ ┻
∧∧
/⌒ヽ)
i三 ∪
～三 |
(/~∪
>>543
541だが、生㌔。
541だが、生㌔。
書き込みないなー。
そろそろ終りか？
そろそろ終りか？
９歳年下の女の子と付き合うことになったんだけど、
このスレでいい？
このスレでいい？
549 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/03(月) 19:54:36
>>532
違うのか？ググるも何も、ダウンロードして使った事あるが。
>>534
IDLの話をしたいなら、自分ですればいいのではないか？
まあ、何故BorlandからCORBAの話を出したか分からないようでは、期待は出来ないが。
>>538
関数引数の実行順序の件は、俺がサンプルコードを提示して、RedHatとMiracleとMintavistaで検証した。
それに無料のbccを使って検証した人もいる。つまり、やる気があれば誰でも検証出来ると言う事だ。
>>540
540は俺より無知ではないと言う事かな？ならば、497に答えてそれを証明してくれないか？
無知無知と言うわりには、口だけの連中が多くて情けない。
これも命名しよう。
ムチクチ：無知、無知と騒ぐ割りには口だけで、自分の知識を披露しない。
>>548
いや、【どこまでも】使えない新人 0x13
がいいんじゃね？
違うのか？ググるも何も、ダウンロードして使った事あるが。
>>534
IDLの話をしたいなら、自分ですればいいのではないか？
まあ、何故BorlandからCORBAの話を出したか分からないようでは、期待は出来ないが。
>>538
関数引数の実行順序の件は、俺がサンプルコードを提示して、RedHatとMiracleとMintavistaで検証した。
それに無料のbccを使って検証した人もいる。つまり、やる気があれば誰でも検証出来ると言う事だ。
>>540
540は俺より無知ではないと言う事かな？ならば、497に答えてそれを証明してくれないか？
無知無知と言うわりには、口だけの連中が多くて情けない。
これも命名しよう。
ムチクチ：無知、無知と騒ぐ割りには口だけで、自分の知識を披露しない。
>>548
いや、【どこまでも】使えない新人 0x13
がいいんじゃね？
時間が出来たので「おじゃばさま」の回答を、採点しようと思ったが
C++の話題になっているんだな、特定の言語には興味ないから
また、消えるか。
C++の話題になっているんだな、特定の言語には興味ないから
また、消えるか。
>>549
>RedHatとMiracleとMintavista
「gccの」バージョンとターゲットを逝ってからだろうな。
再現できなきゃ検証とは言わない。なにもしてないのと同じことだ。
bcc5.5をダウンロードして使った事があるのなら、まずbccを出せば良かろう。
俺が1時間かからずダウンロードして試すことができたのだから造作もないことだ。
俺はとにかくお前みたいな口ばかりのド低脳と一緒にされたのが腹が立つ213だよ。
>RedHatとMiracleとMintavista
「gccの」バージョンとターゲットを逝ってからだろうな。
再現できなきゃ検証とは言わない。なにもしてないのと同じことだ。
bcc5.5をダウンロードして使った事があるのなら、まずbccを出せば良かろう。
俺が1時間かからずダウンロードして試すことができたのだから造作もないことだ。
俺はとにかくお前みたいな口ばかりのド低脳と一緒にされたのが腹が立つ213だよ。
213だけど
>inc eax
>push eax
>inc eax
>push eax
incの実行順序変わっても変わりないじゃないか。
だから213のはおじゃば的に間違っているじゃないか？
｢関数引数の実行順序｣が違うケースなんだから。
213は結局が結果同じ場合だけで、おじゃばの言うケースじゃないので
検証されていないじゃないか？
いえ、213を非難しているわけじゃないですからね、
>inc eax
>push eax
>inc eax
>push eax
incの実行順序変わっても変わりないじゃないか。
だから213のはおじゃば的に間違っているじゃないか？
｢関数引数の実行順序｣が違うケースなんだから。
213は結局が結果同じ場合だけで、おじゃばの言うケースじゃないので
検証されていないじゃないか？
いえ、213を非難しているわけじゃないですからね、
>>555
いや、それを言っちゃうと｢関数引数の実行順序｣ってんはあのコードとは
最初から何の関係もないわけでｗ
｢関数引数の実行順序｣は決まってるけどどの時点で引数として渡すかが
決まってないだけ。
同じコンパイラが、こんなところでOSによって違うコードを吐くちゅう
妄想はどっからくるのかが不思議ではあるｗ
ひょっとしておじゃばの中では同じjavacがOSによって違うバイトコード
出すとか？そうじゃないか。あ、そこがネイティブじゃなくてJavaの利点
だ、とか思ってるんだ！うんうん、それならわかる。バカだもん。
いや、それを言っちゃうと｢関数引数の実行順序｣ってんはあのコードとは
最初から何の関係もないわけでｗ
｢関数引数の実行順序｣は決まってるけどどの時点で引数として渡すかが
決まってないだけ。
同じコンパイラが、こんなところでOSによって違うコードを吐くちゅう
妄想はどっからくるのかが不思議ではあるｗ
ひょっとしておじゃばの中では同じjavacがOSによって違うバイトコード
出すとか？そうじゃないか。あ、そこがネイティブじゃなくてJavaの利点
だ、とか思ってるんだ！うんうん、それならわかる。バカだもん。
>>556
おじゃばその事に気が付いていないから間接的にいってあげたんだおう。
・・・といったら失礼か、247辺りでその辺りはっきりいった後におじゃば話題転換しているもんな。
内容は理解しているが、対した問題じゃないとかそれは問題じゃないとホントに思っているだろうな・・・おじゃばは。
おじゃばその事に気が付いていないから間接的にいってあげたんだおう。
・・・といったら失礼か、247辺りでその辺りはっきりいった後におじゃば話題転換しているもんな。
内容は理解しているが、対した問題じゃないとかそれは問題じゃないとホントに思っているだろうな・・・おじゃばは。
>>554
最新版ではないが、BorlandはBorland C++Compilerをフリーダウンロードできる
ようにしてる。かつては製品版として売られていたコンパイラだ。
今は、Borlandから分社化してCodeGearって社名になってるが、今でもダウンロード
はできるみたい。これがC++Builderで使われてるコンパイラと同じものかどうかは
分からないが、一般的にbcc と言うと、Builderの方ではなく、Borland C++Compiler
の方だと思う。
最新版ではないが、BorlandはBorland C++Compilerをフリーダウンロードできる
ようにしてる。かつては製品版として売られていたコンパイラだ。
今は、Borlandから分社化してCodeGearって社名になってるが、今でもダウンロード
はできるみたい。これがC++Builderで使われてるコンパイラと同じものかどうかは
分からないが、一般的にbcc と言うと、Builderの方ではなく、Borland C++Compiler
の方だと思う。
まぁおじゃばに「ググれ」と言ったのは俺だが、答え出ちまったので付け加えると
＞bccの昔話をされても興味ないが、bccと言えば普通はBorland C++ Builderの事だろう。
＞今のバージョンは5.5。
おじゃばの言ってることも大概昔話だ、というこった。
＞bccの昔話をされても興味ないが、bccと言えば普通はBorland C++ Builderの事だろう。
＞今のバージョンは5.5。
おじゃばの言ってることも大概昔話だ、というこった。
本人のプライドはズタズタなんだが、
それすらも認めたくないっていういつもの展開
それすらも認めたくないっていういつもの展開
> 誰でも検証出来ると言う事だ
誰でもできることなのに、御託を並べてしようとしなかったのがお前。
その他の人間が検証(？)した結果を、自分の功績にしようとしてるのがお前。
以上。
誰でもできることなのに、御託を並べてしようとしなかったのがお前。
その他の人間が検証(？)した結果を、自分の功績にしようとしてるのがお前。
以上。
低能へ
規約も空気も読めない奴に期待してもしょうがないよな
低能でも性格最低なりにふんばってるんだよな
規約も空気も読めない奴に期待してもしょうがないよな
低能でも性格最低なりにふんばってるんだよな
>>同じコンパイラが、こんなところでOSによって違うコードを吐くちゅう
ググッタラ、設定やらなんやらでも変わる可能性があるそうだ(エー)。
でも仮に万が一にそうだとしたら、完全に癖でもなんでもなくて、全ての状況において不定なので癖でもなんでもなくなるが。
それと、検証が大変なのでそれをいくつかのパターンで行ったおじゃばはなんか変態になるわけだが。
ググッタラ、設定やらなんやらでも変わる可能性があるそうだ(エー)。
でも仮に万が一にそうだとしたら、完全に癖でもなんでもなくて、全ての状況において不定なので癖でもなんでもなくなるが。
それと、検証が大変なのでそれをいくつかのパターンで行ったおじゃばはなんか変態になるわけだが。
蛇足で墓穴掘っちゃうｗ
>>549
＞関数引数の実行順序の件は、俺がサンプルコードを提示して、RedHatとMiracleとMintavistaで検証した。
＞それに無料のbccを使って検証した人もいる。つまり、やる気があれば誰でも検証出来ると言う事だ。
配布の終わっている過去のLinuxと商用Linuxを並べ、OSのバージョンもgccのバージョンも書いてない。
ツテを頼ったり金を払ったりして、バージョンを今のヤツから1つ1つダウングレードしていき、
おじゃばの言う挙動をするバージョンが見つかるまで、最悪見つからずに全ての環境で、
サンプルコードをコンパイルして実行する作業をする。
お前はコレを「やる気」の一言で片付けるつもりか？
そもそもおじゃばは「linuxのgcc」と言っている。
bccはコンパイラが違うだろうが。
今個人で入手し易い「linuxのgcc」では幾つか検証されており、
全ての場合でおじゃばの言うケースが再現されて無いじゃないか。
「関数呼び出し時の引数の渡し方が変わるコンパイラがある」ことは検証された。(bcc)
「おじゃばの言った『具体的に処理結果が変わるコンパイラの例』が確かにそう動く」ことは検証されていない。
現状だとむしろ、出来る範囲で検証した結果「おじゃばの言ってることは嘘っぱち」という状態なわけだが。
＞関数引数の実行順序の件は、俺がサンプルコードを提示して、RedHatとMiracleとMintavistaで検証した。
＞それに無料のbccを使って検証した人もいる。つまり、やる気があれば誰でも検証出来ると言う事だ。
配布の終わっている過去のLinuxと商用Linuxを並べ、OSのバージョンもgccのバージョンも書いてない。
ツテを頼ったり金を払ったりして、バージョンを今のヤツから1つ1つダウングレードしていき、
おじゃばの言う挙動をするバージョンが見つかるまで、最悪見つからずに全ての環境で、
サンプルコードをコンパイルして実行する作業をする。
お前はコレを「やる気」の一言で片付けるつもりか？
そもそもおじゃばは「linuxのgcc」と言っている。
bccはコンパイラが違うだろうが。
今個人で入手し易い「linuxのgcc」では幾つか検証されており、
全ての場合でおじゃばの言うケースが再現されて無いじゃないか。
「関数呼び出し時の引数の渡し方が変わるコンパイラがある」ことは検証された。(bcc)
「おじゃばの言った『具体的に処理結果が変わるコンパイラの例』が確かにそう動く」ことは検証されていない。
現状だとむしろ、出来る範囲で検証した結果「おじゃばの言ってることは嘘っぱち」という状態なわけだが。
>>563
本当に検証をやってたら確かに変態だが、おじゃばは口だけの嘘つきだからいいの。
｢細かくは秘密だから言えない｣検証がどこにあるっつーのｗ
そりゃでまかせなら紅旗でもHanLinuxでもSUSE Enterpriseでも何とでも言えるわな。
本当に検証をやってたら確かに変態だが、おじゃばは口だけの嘘つきだからいいの。
｢細かくは秘密だから言えない｣検証がどこにあるっつーのｗ
そりゃでまかせなら紅旗でもHanLinuxでもSUSE Enterpriseでも何とでも言えるわな。
おじゃば予想：
1) 「用語の解釈は人それぞれ」と逃げる
2) いじめられっこの開き直り発言「お前ら勉強になったろ」
3) 後釣り宣言「スレが賑わってよかっただろ」
4) 的外れ一言レスで次へ持ち越し。
5) 別の話題を振って、逃げる。
1) 「用語の解釈は人それぞれ」と逃げる
2) いじめられっこの開き直り発言「お前ら勉強になったろ」
3) 後釣り宣言「スレが賑わってよかっただろ」
4) 的外れ一言レスで次へ持ち越し。
5) 別の話題を振って、逃げる。
そろそろかな～、おじゃばりん。
残業乙。
残業乙。
今日は、おじゃばさま、給湯室に行ったっきり帰ってきませんでした。どうしたんだろ...
RedHatってどのVer？
とりあえずCentOSでやってみっか？
とりあえずCentOSでやってみっか？
572 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/05(水) 19:02:47
>>551
口ばかりのド低能？人聞きが悪いな。
これで俺が書いたらオマエラ大恥だと、以前に忠告したのは覚えていないようだな。
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
movl $0, -4(%ebp)
subl $8, %esp
leal -4(%ebp), %eax
incl (%eax)
pushl -4(%ebp)
leal -4(%ebp), %eax
incl (%eax)
pushl -4(%ebp)
call func
addl $16, %esp
movl $0, %eax
leave
ret
.Lfe2:
.size main,.Lfe2-main
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)"
口ばかりのド低能？人聞きが悪いな。
これで俺が書いたらオマエラ大恥だと、以前に忠告したのは覚えていないようだな。
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
movl $0, -4(%ebp)
subl $8, %esp
leal -4(%ebp), %eax
incl (%eax)
pushl -4(%ebp)
leal -4(%ebp), %eax
incl (%eax)
pushl -4(%ebp)
call func
addl $16, %esp
movl $0, %eax
leave
ret
.Lfe2:
.size main,.Lfe2-main
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)"
>>572
はいはい、切り貼りごくろうさん。
はいはい、切り貼りごくろうさん。
213と基本同じね。
575 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/05(水) 19:36:46
>>551
3機種以上試した俺と、1機種試して得意げな213を一緒にしないで欲しいな。
ちなみに俺は疑り深いのでbcc32でも試したぞ。十数分で試せるのだから、試して当然だよな。
>>554
何？笑う所か？
>>555-557
160で問題となる実例を示しているのだから、意図は分かるよな？
>>559
もったいぶった割りにはそれだけか？558を見習えよ。
>>560
560にはプライドあるのか？
>>561
功績？ﾊﾗｲﾃｪw
3機種以上試した俺と、1機種試して得意げな213を一緒にしないで欲しいな。
ちなみに俺は疑り深いのでbcc32でも試したぞ。十数分で試せるのだから、試して当然だよな。
>>554
何？笑う所か？
>>555-557
160で問題となる実例を示しているのだから、意図は分かるよな？
>>559
もったいぶった割りにはそれだけか？558を見習えよ。
>>560
560にはプライドあるのか？
>>561
功績？ﾊﾗｲﾃｪw
これをしに一日つぶしてたの？
577 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/05(水) 20:00:53
>>562
低能って俺じゃないよな？
>>563,565,566
職業プログラマなら、複数のLinux環境があって当然だと思うがな。
複数の環境で検証なんて大変でも何でもない。Linux環境なんて、こっちには大量にあるからな。
メジャーな3機種を提示したのだから、1つぐらい使える環境を持っている人も多いだろう。
実際、試した人は、俺と同じ結果なので書いてないだけではないか？
RedHatやMiracleの結果がなくて、マイナーなOSの結果ばかりというのは不自然だろう。
つーか、565って本当に職業プログラマか？学生？
低能って俺じゃないよな？
>>563,565,566
職業プログラマなら、複数のLinux環境があって当然だと思うがな。
複数の環境で検証なんて大変でも何でもない。Linux環境なんて、こっちには大量にあるからな。
メジャーな3機種を提示したのだから、1つぐらい使える環境を持っている人も多いだろう。
実際、試した人は、俺と同じ結果なので書いてないだけではないか？
RedHatやMiracleの結果がなくて、マイナーなOSの結果ばかりというのは不自然だろう。
つーか、565って本当に職業プログラマか？学生？
｢機種｣はよそうよ、おじゃば。ほんとに不自由なんだからw
>職業プログラマなら、複数のLinux環境があって当然だと思うがな。
個人で？会社で？
個人で？会社で？
gccのあとに -Oをつけるとおもしろいよ、そのソース。
>>578
しょうがないだろ、おじゃばなんだから。
しょうがないだろ、おじゃばなんだから。
>>572
>551は恥でも何でもない。早いうちに出せないお前が恥ずかしいだけ。
ここまで言われないと出さない奴は、怠惰としかいえないだろう。
で、これでgccとOSのバージョンがわかったところで、どこが>194
>詳細のバージョンは機密に引っ掛かる
のかね。ただめんどくさいから言わなかったのか？
>551は恥でも何でもない。早いうちに出せないお前が恥ずかしいだけ。
ここまで言われないと出さない奴は、怠惰としかいえないだろう。
で、これでgccとOSのバージョンがわかったところで、どこが>194
>詳細のバージョンは機密に引っ掛かる
のかね。ただめんどくさいから言わなかったのか？
>>575
＞もったいぶった割りにはそれだけか？558を見習えよ。
何を見習えと？情報出せってことか？
Borland C++ Builderはもう販売配布されておらず、現在はCodeGear C++ Builder 2007。
これに付属されているBCCはバージョンが5.9x。(確か5.93だったかな)
コイツがBCCの「今のバージョン」だ。
旧バージョンのBCC 5.5.xはCodeGearで無料配布されている。
リンカ、リソースコンパイラのバージョンは5.5から変わってないが、
リソースリンカのバージョンが5.xから6.xに上がっていて、
多数のリソースがあるとリンクに失敗するバグなどがフィクスされている。
なのでリソースを多く使うGUIを作成する時などは、最新バージョンが必要になることがある。
ちょっと「C++ Builder bcc バージョン」あたりでググれば分かる程度の情報なのに
「bccと言えば普通はBorland C++ Builderの事」だの「今のバージョンは5.5」だの・・・。
趣味プログラマならそれでも良いと思うが、プロを名乗ってっておいてこの発言は恥だ。
その上「違うのか？ググるも何も、ダウンロードして使った事あるが。」だと？
疑り深いのなら、人を疑う前にまず自分の知識を疑え。裏を取ってからしゃべれ。
それが出来るようになってから「職業プログラマ」の云々を語れ。
＞もったいぶった割りにはそれだけか？558を見習えよ。
何を見習えと？情報出せってことか？
Borland C++ Builderはもう販売配布されておらず、現在はCodeGear C++ Builder 2007。
これに付属されているBCCはバージョンが5.9x。(確か5.93だったかな)
コイツがBCCの「今のバージョン」だ。
旧バージョンのBCC 5.5.xはCodeGearで無料配布されている。
リンカ、リソースコンパイラのバージョンは5.5から変わってないが、
リソースリンカのバージョンが5.xから6.xに上がっていて、
多数のリソースがあるとリンクに失敗するバグなどがフィクスされている。
なのでリソースを多く使うGUIを作成する時などは、最新バージョンが必要になることがある。
ちょっと「C++ Builder bcc バージョン」あたりでググれば分かる程度の情報なのに
「bccと言えば普通はBorland C++ Builderの事」だの「今のバージョンは5.5」だの・・・。
趣味プログラマならそれでも良いと思うが、プロを名乗ってっておいてこの発言は恥だ。
その上「違うのか？ググるも何も、ダウンロードして使った事あるが。」だと？
疑り深いのなら、人を疑う前にまず自分の知識を疑え。裏を取ってからしゃべれ。
それが出来るようになってから「職業プログラマ」の云々を語れ。
問題にするならCPUとか、コンパイラの種類、バージョンだと思うんだけど、
そして、例示するなら、元にしたCソースとアセンブル結果だと思うんだけど、
なんでおじゃばはディストリビューションに拘ってんだろ？ 謎だ。
そして、例示するなら、元にしたCソースとアセンブル結果だと思うんだけど、
なんでおじゃばはディストリビューションに拘ってんだろ？ 謎だ。
別にもういいんじゃねえの？
自己愛と虚栄心のかたまりを相手にしても疲れるだけじゃん
自己愛と虚栄心のかたまりを相手にしても疲れるだけじゃん
というか、ここまでで「前提」なわけだし、ようやく本題なんだよな～。
とりあえずはっきりさせたいのは、おじゃばは、
関数の実行順序が不定の事を言いたいようなんだけど、
それは呼び出しも含めて不定だと言いたいわけか？
とりあえずはっきりさせたいのは、おじゃばは、
関数の実行順序が不定の事を言いたいようなんだけど、
それは呼び出しも含めて不定だと言いたいわけか？
なぁー素朴な疑問だけど
このアホコテは何故最初から検証結果を貼らなかったの？
自信があるなら冗長なだけの文章を書くより
最初から検証結果貼れば良かったんじゃないの？
そうすればそれで納得させることができたはずだし
馬鹿にされることもなかっただろうし
恥の上塗りをする必要なんて当然なかったはず
今更説得力の欠片も無い文章とともに出しても微妙じゃね？
もしかして想像以上に頭悪いのか？
このアホコテは何故最初から検証結果を貼らなかったの？
自信があるなら冗長なだけの文章を書くより
最初から検証結果貼れば良かったんじゃないの？
そうすればそれで納得させることができたはずだし
馬鹿にされることもなかっただろうし
恥の上塗りをする必要なんて当然なかったはず
今更説得力の欠片も無い文章とともに出しても微妙じゃね？
もしかして想像以上に頭悪いのか？
>>591
アセンブリ出しても自分で読めなかったからだろうな。
>246-247あたりのわかりやすい解説で「教えてもらった」。
bccのこともそうだけど、結果的にこのスレはおじゃばにモノを教えるスレぶなってる。
アセンブリ出しても自分で読めなかったからだろうな。
>246-247あたりのわかりやすい解説で「教えてもらった」。
bccのこともそうだけど、結果的にこのスレはおじゃばにモノを教えるスレぶなってる。
262でイキナリ話題転換しているからな。分かりやすいな。
まあ、だからいい気になった頃に、526でちょっと安い挑発してみたわけだが（エー。
>引数の実行順序なんてもう解決しているが
と言っているのでアセンブリが素で分かっていないか、
そもそも例題と提示した事が違っていた事を問題としていなくて解決済みだと思っているわけだけど。
所で、前スレだがでSIP云々おじゃば言っていたが、あれからどう？
SIPと言っても色々あるわけだが、おじゃばは何やってんの？
まあ、だからいい気になった頃に、526でちょっと安い挑発してみたわけだが（エー。
>引数の実行順序なんてもう解決しているが
と言っているのでアセンブリが素で分かっていないか、
そもそも例題と提示した事が違っていた事を問題としていなくて解決済みだと思っているわけだけど。
所で、前スレだがでSIP云々おじゃば言っていたが、あれからどう？
SIPと言っても色々あるわけだが、おじゃばは何やってんの？
>>577
＞メジャーな3機種を提示したのだから・・・
＞つーか、565って本当に職業プログラマか？
もしかして、おじゃばは全てのプログラム作成会社が
Linuxサーバ系の仕事を受注してるという勘違いしてるんじゃないか？
＞メジャーな3機種を提示したのだから・・・
＞つーか、565って本当に職業プログラマか？
もしかして、おじゃばは全てのプログラム作成会社が
Linuxサーバ系の仕事を受注してるという勘違いしてるんじゃないか？
595 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/06(木) 09:50:45
>>586
確かに俺が間違っていた。俺が以前に落としたのはBorland C++ Compiler 5.5だった。
書く前に一度確認したのだが、Builderになっていたので、Builderと書いてしまった。
分社化されたのも最近か？1年半前はBorlandだった気がするが。
まあ、詳しい人間には些細な間違いも気になるのだろう。すまなかったな。
ところでbccが10年前のコンパイラだと言ってた奴はどこに行った？586にお礼言っておけよ。
>>590
そうだよ、片方実行されてセットされるか、両方実行されてセットされるかが不定だと言っている。
つーかさ、分かっていて言っているよな。
>>591
結果を貼らなかった理由は、機密情報が含まれている（場所を特定される可能性がある）からと、
どれだけ自分で調査する人間がいるか見たかっただけだ。ちなみに、RedHatは問題ないから貼った。
ちなみに全員納得させる気はないし、馬鹿にされたのも、恥の上塗りをしたのも俺ではない。
確かに俺が間違っていた。俺が以前に落としたのはBorland C++ Compiler 5.5だった。
書く前に一度確認したのだが、Builderになっていたので、Builderと書いてしまった。
分社化されたのも最近か？1年半前はBorlandだった気がするが。
まあ、詳しい人間には些細な間違いも気になるのだろう。すまなかったな。
ところでbccが10年前のコンパイラだと言ってた奴はどこに行った？586にお礼言っておけよ。
>>590
そうだよ、片方実行されてセットされるか、両方実行されてセットされるかが不定だと言っている。
つーかさ、分かっていて言っているよな。
>>591
結果を貼らなかった理由は、機密情報が含まれている（場所を特定される可能性がある）からと、
どれだけ自分で調査する人間がいるか見たかっただけだ。ちなみに、RedHatは問題ないから貼った。
ちなみに全員納得させる気はないし、馬鹿にされたのも、恥の上塗りをしたのも俺ではない。
しかし、ゆとりゆとりって言われてるが、ひでえもんだな、最近２ｃｈ見てるとひしひしと実感するぜ。
＞このアホコテは何故最初から検証結果を貼らなかったの？
とかさ、教えて頂けませんでしょうか位言えないのかって感じで、なに様？おれ様？かいって感じだな。
リアルでも立場分かってないんだろうなというところが滲み出ているのを散見する。
そして、ゆとりの字が現しているように、まさに手取り足取り教えてやらないと何もできない赤子と同じ。
君、おこずかい帳あたりから始めれば？みたいな。
語弊の無いように言っとくと、ゆとりってゆとり世代から１、２周したのも含めてね。
＞このアホコテは何故最初から検証結果を貼らなかったの？
とかさ、教えて頂けませんでしょうか位言えないのかって感じで、なに様？おれ様？かいって感じだな。
リアルでも立場分かってないんだろうなというところが滲み出ているのを散見する。
そして、ゆとりの字が現しているように、まさに手取り足取り教えてやらないと何もできない赤子と同じ。
君、おこずかい帳あたりから始めれば？みたいな。
語弊の無いように言っとくと、ゆとりってゆとり世代から１、２周したのも含めてね。
> 機密情報が含まれている（場所を特定される可能性がある）から
冗談は顔だけに
うまく抽出して貼ることができないほどの無能ですって意味でおk？
>596
はぁ？
冗談は顔だけに
うまく抽出して貼ることができないほどの無能ですって意味でおk？
>596
はぁ？
というか、CなりC++でも言語の規格として｢不定｣で処理系に依存するよ、
と明示されてるもんを｢コンパイラの癖｣と称するのはどーよ、ちう話じゃなかったのか？
｢関数引数の実行順序｣も不定なのは規格通りなんだから、おじゃばのコードが
左から評価されて(その都度)右から積む、つまり1,2が返る処理系があってもいっこうに
かまわないわけだろ。
と明示されてるもんを｢コンパイラの癖｣と称するのはどーよ、ちう話じゃなかったのか？
｢関数引数の実行順序｣も不定なのは規格通りなんだから、おじゃばのコードが
左から評価されて(その都度)右から積む、つまり1,2が返る処理系があってもいっこうに
かまわないわけだろ。
600 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/06(木) 19:51:05
>>596
確かにひどい結果だ。ただ俺はゆとり教育のせいだとは思わない。これは試験型学習法のせいだと思う。
試験型学習法というのは、問題と妥当な答えが必ず用意されていて、検証や考える時間を与えずに、
答えを与えてしまう物だ。答えは非常に良く出来ていて、少し考えたぐらいではそれ以上は得にくい物で、
それを唯一の正解として教えてしまう。この方法は非常に効率が良く、広く浅く教えるのに適している。
しかしこれにはいくつかの弊害がある。
一番の問題は学習意欲の喪失だ。検証や考える楽しみを奪ってしまう。
検証方法など考えもしないだろうし、教えられても面倒だと思うだけだろう。
次に、答えの用意されていない問題に対しての、対応能力に低下だ。
普段から検証や考える事をしていないので、解答のない問題には弱く、応用力もない。
勉強とは答えを調べる事だけだと思っているので、頑張っても本やネットで調べるぐらいしかやらない。
当然、本やネットに載ってない事には対応出来ないし、内容にしても細部に誤解や間違いが多かったりする。
これは検証していないため、問題点が分からなかったり、理解出来なかったりするためだ。
さらに試験型学習法に浸かっている人は、用語等の細かな違いを重視する。
これは試験では間違えると得点出来ない為であるが、それを重視するあまり、本質となる問題点や対処方法
などの重要な物を忘れてしまう。結果、重要でない所に力を注いでしまう。
確かにひどい結果だ。ただ俺はゆとり教育のせいだとは思わない。これは試験型学習法のせいだと思う。
試験型学習法というのは、問題と妥当な答えが必ず用意されていて、検証や考える時間を与えずに、
答えを与えてしまう物だ。答えは非常に良く出来ていて、少し考えたぐらいではそれ以上は得にくい物で、
それを唯一の正解として教えてしまう。この方法は非常に効率が良く、広く浅く教えるのに適している。
しかしこれにはいくつかの弊害がある。
一番の問題は学習意欲の喪失だ。検証や考える楽しみを奪ってしまう。
検証方法など考えもしないだろうし、教えられても面倒だと思うだけだろう。
次に、答えの用意されていない問題に対しての、対応能力に低下だ。
普段から検証や考える事をしていないので、解答のない問題には弱く、応用力もない。
勉強とは答えを調べる事だけだと思っているので、頑張っても本やネットで調べるぐらいしかやらない。
当然、本やネットに載ってない事には対応出来ないし、内容にしても細部に誤解や間違いが多かったりする。
これは検証していないため、問題点が分からなかったり、理解出来なかったりするためだ。
さらに試験型学習法に浸かっている人は、用語等の細かな違いを重視する。
これは試験では間違えると得点出来ない為であるが、それを重視するあまり、本質となる問題点や対処方法
などの重要な物を忘れてしまう。結果、重要でない所に力を注いでしまう。
>>600
で？
で？
>>600
やっと自分を省みる気になったのか？
やっと自分を省みる気になったのか？
おじゃばは真逆。
自分の知識や経験に縛られて本やネットで調べることをしない。
言語の話をしてるときに規格すら見ない。
だから用語が分からない。
さらに技術の話において用語が分からないから会話が成立しない。
これがおじゃば。
多分仕様書に「用語集」を書かないタイプの人間なのだろう。
自分の知識や経験に縛られて本やネットで調べることをしない。
言語の話をしてるときに規格すら見ない。
だから用語が分からない。
さらに技術の話において用語が分からないから会話が成立しない。
これがおじゃば。
多分仕様書に「用語集」を書かないタイプの人間なのだろう。
対応能力(･∀･)に低下だ！
＞そうだよ、片方実行されてセットされるか、両方実行されてセットされるかが不定だと言っている。
みんな不定だ不定だ、と言っているが、
おじゃばの出した「func(++i, ++i);」コレ。
落ち着いて見れば、そもそも未定義じゃねぇのか？
実行順序云々以前の問題だと思うんだが、俺の理解が間違えてるか？
みんな不定だ不定だ、と言っているが、
おじゃばの出した「func(++i, ++i);」コレ。
落ち着いて見れば、そもそも未定義じゃねぇのか？
実行順序云々以前の問題だと思うんだが、俺の理解が間違えてるか？
>>607
>不定と未定義の最も大きな違いは、不定のコードはプログラムとしては正しいが、
>未定義のコードは間違いであり、動作する保証すらないという所にあります。
プログラムは正しいので不定。
ちなみにおじゃばは上の方では不定という言葉を使っていない。
実行順序が保証されなくてそれは癖だと表現している。
160の文章から分かるようにpushの順序が肝の例題だしながら、
変数のアクセス順序のみしか基本的に説明していない。
（強いて言えば24の渡るとアクセスに言及しない”順序”がそういうことになる）
だから、みんなでpushの順序が問題であるとアセンブラだして結論だしたわけだ。
ちなみにおじゃばは、595まで不定という言葉も使ってないしpushの順序に関して明確に言及はしていない。
追記：
>>ところでbccが10年前のコンパイラだと言ってた奴はどこに行った？586にお礼言っておけよ。
ああ、それ漏れ。同時に251でもBorland復帰したと上の方でも言っている。
>漏れの知っている限り、bccは7、8年位前にwindowsで、10年前はDos環境で
そもそも、引っ掛けな文章なわけだが。
10年前にDos環境っていう時点でネタ確定だろ・・・
Turbo Cって知っているか？
あ、586礼必要？
>不定と未定義の最も大きな違いは、不定のコードはプログラムとしては正しいが、
>未定義のコードは間違いであり、動作する保証すらないという所にあります。
プログラムは正しいので不定。
ちなみにおじゃばは上の方では不定という言葉を使っていない。
実行順序が保証されなくてそれは癖だと表現している。
160の文章から分かるようにpushの順序が肝の例題だしながら、
変数のアクセス順序のみしか基本的に説明していない。
（強いて言えば24の渡るとアクセスに言及しない”順序”がそういうことになる）
だから、みんなでpushの順序が問題であるとアセンブラだして結論だしたわけだ。
ちなみにおじゃばは、595まで不定という言葉も使ってないしpushの順序に関して明確に言及はしていない。
追記：
>>ところでbccが10年前のコンパイラだと言ってた奴はどこに行った？586にお礼言っておけよ。
ああ、それ漏れ。同時に251でもBorland復帰したと上の方でも言っている。
>漏れの知っている限り、bccは7、8年位前にwindowsで、10年前はDos環境で
そもそも、引っ掛けな文章なわけだが。
10年前にDos環境っていう時点でネタ確定だろ・・・
Turbo Cって知っているか？
あ、586礼必要？
いや、いらんべ
副作用があいまいな部分が複数あるコードのふるまいは、常に未定義 である。
>関数 の引数の評価順は不定（unspecified）
また
>ある変数に 対して副作用が生じるような式においては、他の箇所でその変数を参照すること
>はできません。その結果は未定義とされています
であるから、おじゃばのコードは最初から｢言語規格上は不定、かつ実行結果は未定義｣。
そんなもん｢コンパイラの癖｣扱いにしたらだめだろ常考。
また
>ある変数に 対して副作用が生じるような式においては、他の箇所でその変数を参照すること
>はできません。その結果は未定義とされています
であるから、おじゃばのコードは最初から｢言語規格上は不定、かつ実行結果は未定義｣。
そんなもん｢コンパイラの癖｣扱いにしたらだめだろ常考。
612 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/07(金) 09:51:54
>>603
構造化設計や作業工程に関する用語については、基本情報処理の物を使用している。
確かにOOにそれらの用語を無理に当てはめている所もあるが、多くは他の人間が基本情報処理レベルの
知識が不足しているのだろう。
>>606-611
A.Cマスターならコンパイラの癖も理解してなければダメだろう。
B.それならsshの64ビット化のコンパイルで、こんな事があったから気をつけろ。
A.それは癖じゃなくてバグだろ。
B.ではこんな書き方をするとコンパイラによって実行結果が変わるから気をつけろ。
A.それは癖じゃなくて不定だろ。
A'.いや不定じゃなくて未定義だろう。
>本質となる問題点や対処方法などの重要な物を忘れてしまう。結果、重要でない所に力を注いでしまう。
コンパイル検証をしなかった人は、いくら俺を攻撃しても、やらなかった事実は変わらないし、
その人の価値が上がった訳でもない。少なくともこの点においては俺より知識が少なく、能力も低いと
言う事になる。つまり俺より無知で低能だと言う訳だ。
そうでないと言うなら、それを証明する必要がある。つまり497に答えてみろ。
構造化設計や作業工程に関する用語については、基本情報処理の物を使用している。
確かにOOにそれらの用語を無理に当てはめている所もあるが、多くは他の人間が基本情報処理レベルの
知識が不足しているのだろう。
>>606-611
A.Cマスターならコンパイラの癖も理解してなければダメだろう。
B.それならsshの64ビット化のコンパイルで、こんな事があったから気をつけろ。
A.それは癖じゃなくてバグだろ。
B.ではこんな書き方をするとコンパイラによって実行結果が変わるから気をつけろ。
A.それは癖じゃなくて不定だろ。
A'.いや不定じゃなくて未定義だろう。
>本質となる問題点や対処方法などの重要な物を忘れてしまう。結果、重要でない所に力を注いでしまう。
コンパイル検証をしなかった人は、いくら俺を攻撃しても、やらなかった事実は変わらないし、
その人の価値が上がった訳でもない。少なくともこの点においては俺より知識が少なく、能力も低いと
言う事になる。つまり俺より無知で低能だと言う訳だ。
そうでないと言うなら、それを証明する必要がある。つまり497に答えてみろ。
マゾなのはわかったから自虐プレイはほどほどにしてくんね？＞アホコテ
>B.ではこんな書き方をするとコンパイラによって実行結果が変わるから気をつけろ。
>A.それは癖じゃなくて不定だろ。
>A'.いや不定じゃなくて未定義だろう。
実際の流れ。
>これなら、100%コンパイラの癖だから文句はないだろう。ただ俺が苦労したのは前者だがな。
>癖って、このコンパイラの吐くアセンブリはインライン関数をうまく展開してくれないとか、farジャンプ
>を使いすぎるとか、ある最適化指定でテーブルジャンプを使いがちとか、ある条件で特定のレジスタしか使
>わないとかそんな話じゃないの？
>評価順序の話は、コンパイラの癖というよりは、まずは、
>「言語使用で不定とされているもの」、という話題だろうね。
正しい流れ：コンパイラの癖という言葉に他の一般的な概念があり、例には不定・未定義という正しい言葉がある。
当然”不定・未定義”の例を上げたおじゃばにも求めた
一般的にコンパイルの癖は上記の様に最適化されない部分をアセンブリで書く事をいう
不定の状況を説明しながら正しい用語を使わないでその事を認めずに意固地に癖という事使い続けたのはお前だ。
それは単純にからかいの種にしかならない。
常々一般化された・されていないという事を気にする癖に自分が知らないことは範囲外か？
言ってることは不足、用語は正しくないおれおれ用語。
いつも言われている事だけだ。
>A.それは癖じゃなくて不定だろ。
>A'.いや不定じゃなくて未定義だろう。
実際の流れ。
>これなら、100%コンパイラの癖だから文句はないだろう。ただ俺が苦労したのは前者だがな。
>癖って、このコンパイラの吐くアセンブリはインライン関数をうまく展開してくれないとか、farジャンプ
>を使いすぎるとか、ある最適化指定でテーブルジャンプを使いがちとか、ある条件で特定のレジスタしか使
>わないとかそんな話じゃないの？
>評価順序の話は、コンパイラの癖というよりは、まずは、
>「言語使用で不定とされているもの」、という話題だろうね。
正しい流れ：コンパイラの癖という言葉に他の一般的な概念があり、例には不定・未定義という正しい言葉がある。
当然”不定・未定義”の例を上げたおじゃばにも求めた
一般的にコンパイルの癖は上記の様に最適化されない部分をアセンブリで書く事をいう
不定の状況を説明しながら正しい用語を使わないでその事を認めずに意固地に癖という事使い続けたのはお前だ。
それは単純にからかいの種にしかならない。
常々一般化された・されていないという事を気にする癖に自分が知らないことは範囲外か？
言ってることは不足、用語は正しくないおれおれ用語。
いつも言われている事だけだ。
>言う事になる。つまり俺より無知で低能だと言う訳だ。
>そうでないと言うなら、それを証明する必要がある。つまり497に答えてみろ。
おじゃばは、単純におれおれ用語が多くてで言葉足らずなところが新人並で、
プライドがいっちょ前のどこにでもいるとっつぁん坊やとは思うけど。
無知でも低能でもないと思う。
能力はさほど疑わない。一言で言えば、性格ブス。
どこにでもいる使える部分よりも使えない部分に磨きをかける
平凡な代わり映えのしないくだらない人材だね。
そーいったわけなので無知・低能論に参入する機はない。
ああ、話題戻すのなら、どうぞご自由に・・・。元からそっちの議論は興味がないのでＲＯＭ専だし。
>そうでないと言うなら、それを証明する必要がある。つまり497に答えてみろ。
おじゃばは、単純におれおれ用語が多くてで言葉足らずなところが新人並で、
プライドがいっちょ前のどこにでもいるとっつぁん坊やとは思うけど。
無知でも低能でもないと思う。
能力はさほど疑わない。一言で言えば、性格ブス。
どこにでもいる使える部分よりも使えない部分に磨きをかける
平凡な代わり映えのしないくだらない人材だね。
そーいったわけなので無知・低能論に参入する機はない。
ああ、話題戻すのなら、どうぞご自由に・・・。元からそっちの議論は興味がないのでＲＯＭ専だし。
理解不足のしったかくんだろ。
「コンパイラの癖」と言ってみたはいいが、
その後ライブラリの話を持ち出してみたり、
コンパイラの話になってIDEが出てきたり、
なんか徹頭徹尾フワフワしてる。
「コンパイラの癖」と言ってみたはいいが、
その後ライブラリの話を持ち出してみたり、
コンパイラの話になってIDEが出てきたり、
なんか徹頭徹尾フワフワしてる。
初めてこのスレに来たがなんだかカオスだなｗ
620 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/07(金) 19:31:50
>>616
俺のコンパイラの癖の定義は、「コンパイラによって異なる動作」だ。
つまり、ライブラリのバグも、コンパイラのバグも、不定も未定義も、最適化の違いも癖だ。
俺にとっては、コンパイル時のパラメータの違いも、Makefileの違いも癖だ。
俺のまわりには同じ認識の人もいるし、このスレにだってコンパイラのバグは癖でもいいだろうと
言う人もいる。
616にとってのコンパイラの癖は、「最適化されない部分をアセンブリで書く事」？らしいが、
俺の知る限り、それが一般的だと言う認識はない。第一、日本語としておかしい。
コンパイラによる最適化が癖だと言うのに異存はないが、それが全てだと言うなら、
それは俺とは違うとしか言えない。第一、基本情報処理にコンパイラの癖の定義なんてない。
で、定義はそれぞれでいいとして、C言語マスターに求められる情報としての癖を考えてみよう。
俺の癖は、複数の環境でC言語を使うのに役に立つ。
616の癖は、組み込み系ぐらいでしかあまり関係ない情報だろう。実際、知らなくても影響ない。
で、616の情報を知らないと、C言語マスターと言えないのか？
それは、「組み込み系以外はC言語に非ず」とか言ってるのか？
俺のコンパイラの癖の定義は、「コンパイラによって異なる動作」だ。
つまり、ライブラリのバグも、コンパイラのバグも、不定も未定義も、最適化の違いも癖だ。
俺にとっては、コンパイル時のパラメータの違いも、Makefileの違いも癖だ。
俺のまわりには同じ認識の人もいるし、このスレにだってコンパイラのバグは癖でもいいだろうと
言う人もいる。
616にとってのコンパイラの癖は、「最適化されない部分をアセンブリで書く事」？らしいが、
俺の知る限り、それが一般的だと言う認識はない。第一、日本語としておかしい。
コンパイラによる最適化が癖だと言うのに異存はないが、それが全てだと言うなら、
それは俺とは違うとしか言えない。第一、基本情報処理にコンパイラの癖の定義なんてない。
で、定義はそれぞれでいいとして、C言語マスターに求められる情報としての癖を考えてみよう。
俺の癖は、複数の環境でC言語を使うのに役に立つ。
616の癖は、組み込み系ぐらいでしかあまり関係ない情報だろう。実際、知らなくても影響ない。
で、616の情報を知らないと、C言語マスターと言えないのか？
それは、「組み込み系以外はC言語に非ず」とか言ってるのか？
無駄に残業してないで早く帰れ
ライブラリは、コンパイルされる側ではあっても、コンパイラではない。
ライブラリにバグがあったとして、なぜそれがコンパイラの癖となり得るだろうか。
コンパイラのバグは言葉の通り。
不定、未定義は言語の規格。
最適化の違いは、これはコンパイラの個性であり、癖と呼びうる。
コンパイル時のパラメータの違いは、コンパイラの仕様。
Makefileの違い（？）は意味不明。なぜmakeの話に？？
おいらはここまで。二段目三段目については他の人の批判を待ってほしいｗ
ライブラリにバグがあったとして、なぜそれがコンパイラの癖となり得るだろうか。
コンパイラのバグは言葉の通り。
不定、未定義は言語の規格。
最適化の違いは、これはコンパイラの個性であり、癖と呼びうる。
コンパイル時のパラメータの違いは、コンパイラの仕様。
Makefileの違い（？）は意味不明。なぜmakeの話に？？
おいらはここまで。二段目三段目については他の人の批判を待ってほしいｗ
623 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/07(金) 20:05:10
内容をまともに語ったことがないお前が言うか
お前の独自用語＆独自解釈ラッシュは妄言そのものじゃん
お前の独自用語＆独自解釈ラッシュは妄言そのものじゃん
>>623
内容についても「俺とは違う」になっちまうだろうが。
内容についても「俺とは違う」になっちまうだろうが。
> 一般的だと言う認識はない
お前の一般的って？
今までのお前の発言からすればお前の思考が一般的だとは到底思えんが。
人間としておかしい。
お前の一般的って？
今までのお前の発言からすればお前の思考が一般的だとは到底思えんが。
人間としておかしい。
おじゃばの思考回路に吹いたｗ
だめだこりゃｗ
だめだこりゃｗ
628 ：仕様書無しさん：2008/03/07(金) 21:34:22
この業界で仕事してて用語の共通認識ってかなり重要な要素なんだが、
「俺様はこの認識だ。つべこべ言うな」的な態度はちょっと致命的だ
と思う。よくそれでこれまで仕事できてると思うよ。
おじゃばには俺からの餞別として古来より伝わるこの言葉を送ろう。
ありがたく受け取れ。
ググレカス
「俺様はこの認識だ。つべこべ言うな」的な態度はちょっと致命的だ
と思う。よくそれでこれまで仕事できてると思うよ。
おじゃばには俺からの餞別として古来より伝わるこの言葉を送ろう。
ありがたく受け取れ。
ググレカス
>俺のコンパイラの癖の定義は、「コンパイラによって異なる動作」だ。
例は言語仕様外によるコーディングミスなので、コンパイラ云々言うのがまずおかしいだけどね。
単なるコーディングのミスであり、別におじゃばの癖の定義はどうでもよくて、コンパイラ云々
なんで持ち出しているのって話なんだけど。
例は言語仕様外によるコーディングミスなので、コンパイラ云々言うのがまずおかしいだけどね。
単なるコーディングのミスであり、別におじゃばの癖の定義はどうでもよくて、コンパイラ云々
なんで持ち出しているのって話なんだけど。
func(++count, ++count);
こんな書き方するなバカ、で終了
こんな書き方するなバカ、で終了
俺ほど「コンパイラの癖」に笑かされた者も少いだろうw
>つまり、ライブラリのバグも、コンパイラのバグも、不定も未定義も、最適化の違いも癖だ。
まず、ここが違う。
言語仕様を不定も未定義も満たしていないケース。
ほかは言語仕様を満たしているかどうかで異なる。
言語仕様を満たしていない以上その動作は保証されていないわけで、振る舞いが違う結果になるのも当たり前。
コンパイラの解釈は関係ない。解釈が割り込まない所で、なんで癖という言葉が出てくるか不思議だという話。
つまり、動作的に保証されないことを癖という変な事になる。
おじゃばの言葉は癖すら保証されないと明言しているに等しい。
おじゃば流に言うなら、言語仕様・論理的に正しい時のコンパイラの解釈の差異が癖と呼ばれるべきであって、
保証されない事を癖といっているのがおかしい。
追記：俺、プログラマーだから言葉遊びでもおじゃばの発言に賛成できないよー。
まず、ここが違う。
言語仕様を不定も未定義も満たしていないケース。
ほかは言語仕様を満たしているかどうかで異なる。
言語仕様を満たしていない以上その動作は保証されていないわけで、振る舞いが違う結果になるのも当たり前。
コンパイラの解釈は関係ない。解釈が割り込まない所で、なんで癖という言葉が出てくるか不思議だという話。
つまり、動作的に保証されないことを癖という変な事になる。
おじゃばの言葉は癖すら保証されないと明言しているに等しい。
おじゃば流に言うなら、言語仕様・論理的に正しい時のコンパイラの解釈の差異が癖と呼ばれるべきであって、
保証されない事を癖といっているのがおかしい。
追記：俺、プログラマーだから言葉遊びでもおじゃばの発言に賛成できないよー。
>>612
＞B.ではこんな書き方をするとコンパイラによって実行結果が変わるから気をつけろ。
＞A.それは癖じゃなくて不定だろ。
＞A'.いや不定じゃなくて未定義だろう。
＞>本質となる問題点や対処方法などの重要な物を忘れてしまう。結果、重要でない所に力を注いでしまう。
正しくは
A'.出してる例は未定義じゃないのか？
まぁ概ねあると思ってた範囲内の返答でホッとした。
とりあえず>>603をもう一度書いておこう。
＞自分の知識や経験に縛られて本やネットで調べることをしない。
＞言語の話をしてるときに規格すら見ない。
＞だから用語が分からない。
＞さらに技術の話において用語が分からないから会話が成立しない。
＞これがおじゃば。
おじゃばのC言語に対する理解度が低いのは宣言と定義の件で分かってるので、
それは別にもうどうでも良いんだが、C言語で処理系依存の話をするときに
「未定義」と「未規定(不定)」の違いが分からないのは致命的。
(別にC言語を使ったコーディング能力が低いとは言って無いので)
＞B.ではこんな書き方をするとコンパイラによって実行結果が変わるから気をつけろ。
＞A.それは癖じゃなくて不定だろ。
＞A'.いや不定じゃなくて未定義だろう。
＞>本質となる問題点や対処方法などの重要な物を忘れてしまう。結果、重要でない所に力を注いでしまう。
正しくは
A'.出してる例は未定義じゃないのか？
まぁ概ねあると思ってた範囲内の返答でホッとした。
とりあえず>>603をもう一度書いておこう。
＞自分の知識や経験に縛られて本やネットで調べることをしない。
＞言語の話をしてるときに規格すら見ない。
＞だから用語が分からない。
＞さらに技術の話において用語が分からないから会話が成立しない。
＞これがおじゃば。
おじゃばのC言語に対する理解度が低いのは宣言と定義の件で分かってるので、
それは別にもうどうでも良いんだが、C言語で処理系依存の話をするときに
「未定義」と「未規定(不定)」の違いが分からないのは致命的。
(別にC言語を使ったコーディング能力が低いとは言って無いので)
633の続き
一応説明を入れておく。
>>24より
＞「関数引数の実行順序は保証されない。」
＞int count = 0; func(++count, ++count); とあった場合、
＞コンパイラによっては、 func(2, 1); で渡る物もあれば、 func(2, 2); で渡る物もある。
func(++count, ++count);は未定義なので、Cコンパイラはこの式をどのように扱っても構わない。
だから、この挙動がコンパイラによって変わることと「関数引数の実行順序」はあまり関係ない 。
確かに「関数引数の実行順序は保証されない」のであるけど、
「関数引数の実行順序」どころかコンパイル出来ることすら保証されない。
たとえ「int count = 0; func(++count, ++count); func(++count, ++count);」を
func(-1,-1);と解釈しようが、Cコンパイラとしては規格に準拠している。
関数引数の実行順序が「(例えば)スタックに積むタイミング」だとしても、
コレは多分処理系定義の動作。
もしかすると単なる未規定かも知れないが・・・。ごめん。良く知らんわ。
でもどちらにせよ、func(++count, ++count);とはあまり関係ない。
最後に、別に何が癖なのか、そこは否定するつもりは無いが、
「関数引数の実行順序は保証されない」というのがどういうことなのか、
「func(++count, ++count);」がC言語においてどういうコードなのか、
理解していないこと、理解する気も無いことは分かる。
一応説明を入れておく。
>>24より
＞「関数引数の実行順序は保証されない。」
＞int count = 0; func(++count, ++count); とあった場合、
＞コンパイラによっては、 func(2, 1); で渡る物もあれば、 func(2, 2); で渡る物もある。
func(++count, ++count);は未定義なので、Cコンパイラはこの式をどのように扱っても構わない。
だから、この挙動がコンパイラによって変わることと「関数引数の実行順序」はあまり関係ない 。
確かに「関数引数の実行順序は保証されない」のであるけど、
「関数引数の実行順序」どころかコンパイル出来ることすら保証されない。
たとえ「int count = 0; func(++count, ++count); func(++count, ++count);」を
func(-1,-1);と解釈しようが、Cコンパイラとしては規格に準拠している。
関数引数の実行順序が「(例えば)スタックに積むタイミング」だとしても、
コレは多分処理系定義の動作。
もしかすると単なる未規定かも知れないが・・・。ごめん。良く知らんわ。
でもどちらにせよ、func(++count, ++count);とはあまり関係ない。
最後に、別に何が癖なのか、そこは否定するつもりは無いが、
「関数引数の実行順序は保証されない」というのがどういうことなのか、
「func(++count, ++count);」がC言語においてどういうコードなのか、
理解していないこと、理解する気も無いことは分かる。
プロトコルが成立してはじめて通信ができる、のを
わからない自称プログラマのスレはここですか？
わからない自称プログラマのスレはここですか？
func(printf("a\n"),printf("b\n"));
不定。
プログラムとしては正しい。
'a','b'はかならず出力される。
順番は処理系が勝手に決めていい。
マニュアルにも明記不要。
func(++count, ++count);
未定義。
プログラムとしてそもそも誤り。0除算と同じレベル。
「引数の評価順序は処理系依存」の例としてふさわしくない罠。
不定。
プログラムとしては正しい。
'a','b'はかならず出力される。
順番は処理系が勝手に決めていい。
マニュアルにも明記不要。
func(++count, ++count);
未定義。
プログラムとしてそもそも誤り。0除算と同じレベル。
「引数の評価順序は処理系依存」の例としてふさわしくない罠。
どいつもこいつもなげーよー
３行でまとめて書いてくれ
３行でまとめて書いてくれ
func(++count, ++count);は
順序云々
以前の問題
順序云々
以前の問題
お
じゃ
ばか
じゃ
ばか
スレ違い
よそで
やれ
よそで
やれ
ぬこ大好き
る
ぽ
る
ぽ
func(++count, ++count); はバグ。おじゃばが直した。
おれすげー、みんな知っているかか？これってコンパイルの癖だぜ。
反応
・何当たり前の事いってるんだ？
・コンパイルの癖って何？
・式の評価順序と引数の挿入の説明が曖昧。
例)
混乱の元
>24 9行目「関数引数の実行順序は保証されない。」
答え
>595 9行目 そうだよ、片方実行されてセットされるか、両方実行されてセットされるかが不定だと言っている。
関数引数は評価順序も引数の挿入も不定です。！でもおじゃばの言葉は基本評価順序としか解釈できません！
結論：当たり前の事を言っておじゃば用語で惑わして、回りくどい説明で皆をさらに混乱させる。
模範答案を用意した質問をすると100レス位消費を抑えられる。
おれすげー、みんな知っているかか？これってコンパイルの癖だぜ。
反応
・何当たり前の事いってるんだ？
・コンパイルの癖って何？
・式の評価順序と引数の挿入の説明が曖昧。
例)
混乱の元
>24 9行目「関数引数の実行順序は保証されない。」
答え
>595 9行目 そうだよ、片方実行されてセットされるか、両方実行されてセットされるかが不定だと言っている。
関数引数は評価順序も引数の挿入も不定です。！でもおじゃばの言葉は基本評価順序としか解釈できません！
結論：当たり前の事を言っておじゃば用語で惑わして、回りくどい説明で皆をさらに混乱させる。
模範答案を用意した質問をすると100レス位消費を抑えられる。
汚邪罵はそんなの無視して100レスするよ。
なんでもコンパイラのせいにしたくなる時って、ちょっとかじって｢俺スゲー｣とか思う時期に
ありがちだよなぁ。そうそう、基本情報処理受かっていい気になってるくらいの。
でもさ、そんなときにいろんな人からの話をちゃんと聞けるかそうでないかで技術者になるための
低いけどハードルがある。教えたがりになったら危ないぞ、と考えられるかどうかだな。
ありがちだよなぁ。そうそう、基本情報処理受かっていい気になってるくらいの。
でもさ、そんなときにいろんな人からの話をちゃんと聞けるかそうでないかで技術者になるための
低いけどハードルがある。教えたがりになったら危ないぞ、と考えられるかどうかだな。
おじゃば召喚の儀式を始める・・・。
予言しよう。明日おじゃばはこない！
予言しよう。明日おじゃばはこない！
646 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/10(月) 09:52:48
「仕様上正しいのに異なる動作が癖」と言う癖定義野郎と、
「引数の実行される順番と、渡される順番は違う」順番定義野郎がいる訳だな。
実際、ど両方もどうでもいい内容だが、497に答える強者もいないし、こっちをやるか。
「仕様上正しいのに異なる動作が癖」と言うのはどうしようもないな。
俺は「コンパイラによって異なる動作」だと言っても、癖の定義なんて実際には決まっていないのだから、
互いに違うと言うだけになってしまう。そんな言い争い、続けても不毛だから、
もう「仕様上正しいのに異なる動作が癖」でいいよ。
で、俺の言ったのは全部間違いだとして、Cマスターに求められる知識としての癖の話をしてくれないか？
役に立つ知識を提供してくれよ。
「引数の実行される順番と、渡される順番は違う」か。
まあ言いたい事は分かるよ。しかし、俺の意図が伝わっていないのも分かった。
とりあえず、渡される順番が分かるコードを書いてみてくれないか？
printの例はだめだぞ、実行しても渡される順番の違いは分からない。
「引数の実行される順番と、渡される順番は違う」順番定義野郎がいる訳だな。
実際、ど両方もどうでもいい内容だが、497に答える強者もいないし、こっちをやるか。
「仕様上正しいのに異なる動作が癖」と言うのはどうしようもないな。
俺は「コンパイラによって異なる動作」だと言っても、癖の定義なんて実際には決まっていないのだから、
互いに違うと言うだけになってしまう。そんな言い争い、続けても不毛だから、
もう「仕様上正しいのに異なる動作が癖」でいいよ。
で、俺の言ったのは全部間違いだとして、Cマスターに求められる知識としての癖の話をしてくれないか？
役に立つ知識を提供してくれよ。
「引数の実行される順番と、渡される順番は違う」か。
まあ言いたい事は分かるよ。しかし、俺の意図が伝わっていないのも分かった。
とりあえず、渡される順番が分かるコードを書いてみてくれないか？
printの例はだめだぞ、実行しても渡される順番の違いは分からない。
>>646
｢Cマスター｣って、本気で気に入ってる、てか呼ばれたいんだ･･･絶句。
もういいよ、みんな呼んでるじゃないかCマスター(笑)。
ほんとにアセンブリ読もうという向上心がないのもよくわかった。
だいたいさ、コンパイラってソースを入力してオブジェクトを出力する
プログラムだろ？どんな出力がされてるか理解しようとしない奴が
検証も糞もあるまい。もういいから、Javaやってな。悪いこといわんから。
｢Cマスター｣って、本気で気に入ってる、てか呼ばれたいんだ･･･絶句。
もういいよ、みんな呼んでるじゃないかCマスター(笑)。
ほんとにアセンブリ読もうという向上心がないのもよくわかった。
だいたいさ、コンパイラってソースを入力してオブジェクトを出力する
プログラムだろ？どんな出力がされてるか理解しようとしない奴が
検証も糞もあるまい。もういいから、Javaやってな。悪いこといわんから。
お前いいこと言ったと思うが
Javaだって色々調査してたらすぐにネイティブで処理してる部分に行き着くと思うんだが
Javaだって色々調査してたらすぐにネイティブで処理してる部分に行き着くと思うんだが
おじゃば、ついに反論放棄ｗ
>>648
>647だが、たしかにバイトコードを見たりだとか必要だな。スマソ。そこで
public class fa {
public static void func(int a,int b) {
System.out.println(a + ","+ b);
}
public static void main(String[] args) {
int count=0;
func(++count,++count);
}
}
をコンパイルしてみた。結果は
1,2
バイトコードは
public static void main(java.lang.String[]);
Code:
0: iconst_0
1: istore_1
2: iinc 1, 1
5: iload_1
6: iinc 1, 1
9: iload_1
10: invokestatic #10; //Method func:(II)V
13: return
おお、Javaの規格通りに(笑)左から右に引数を渡しているな。なるほど。
>647だが、たしかにバイトコードを見たりだとか必要だな。スマソ。そこで
public class fa {
public static void func(int a,int b) {
System.out.println(a + ","+ b);
}
public static void main(String[] args) {
int count=0;
func(++count,++count);
}
}
をコンパイルしてみた。結果は
1,2
バイトコードは
public static void main(java.lang.String[]);
Code:
0: iconst_0
1: istore_1
2: iinc 1, 1
5: iload_1
6: iinc 1, 1
9: iload_1
10: invokestatic #10; //Method func:(II)V
13: return
おお、Javaの規格通りに(笑)左から右に引数を渡しているな。なるほど。
あ、javac 1.5.0_13だよ、書き忘れてたけどねw
>とりあえず、渡される順番が分かるコードを書いてみてくれないか？
>printの例はだめだぞ、実行しても渡される順番の違いは分からない。
よく分からないけど、おじゃばが困ってるようなので、
VC2005で渡される順番が分かるコードを書きました。
int i = 0;
_asm{
mov eax,i
add eax,1
mov i,eax
push eax
mov ecx,i
add ecx,1
mov i,ecx
push ecx
call func
add esp,8
}
我ながらお馬鹿な答えだと自画自賛したくなる。
>printの例はだめだぞ、実行しても渡される順番の違いは分からない。
よく分からないけど、おじゃばが困ってるようなので、
VC2005で渡される順番が分かるコードを書きました。
int i = 0;
_asm{
mov eax,i
add eax,1
mov i,eax
push eax
mov ecx,i
add ecx,1
mov i,ecx
push ecx
call func
add esp,8
}
我ながらお馬鹿な答えだと自画自賛したくなる。
>>646
＞「引数の実行される順番と、渡される順番は違う」
引数の実行される順番って評価順序のことだよな？
渡される順番って何のこと？
呼び出し規約絡みの話か？
C言語は引数渡すときに普通は右から順に渡すモンで、
基本的には変わらんと思うが。
アセンブラ見る以外で確認する方法は知らん。
スタックに積むタイミングの話はドコへ行ったのやら。
もしかしてコレが渡される順番なのか？
おじゃば言語は良く分からん。
＞「引数の実行される順番と、渡される順番は違う」
引数の実行される順番って評価順序のことだよな？
渡される順番って何のこと？
呼び出し規約絡みの話か？
C言語は引数渡すときに普通は右から順に渡すモンで、
基本的には変わらんと思うが。
アセンブラ見る以外で確認する方法は知らん。
スタックに積むタイミングの話はドコへ行ったのやら。
もしかしてコレが渡される順番なのか？
おじゃば言語は良く分からん。
誰か３行でスレタイとC言語について教えてくれ
ぬこ大好き
る
ぽ
る
ぽ
>>654
「なぜオブジェクト指向は普及しないのか」というタイトルのスレに
Ｃ言語をかじった程度の素人に毛が生えた程の自称職業プログラマが
基礎も知らずに無理に背伸びしてるのをからかっている。ぬこ大好き。
「なぜオブジェクト指向は普及しないのか」というタイトルのスレに
Ｃ言語をかじった程度の素人に毛が生えた程の自称職業プログラマが
基礎も知らずに無理に背伸びしてるのをからかっている。ぬこ大好き。
657 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/11(火) 10:00:47
>>647
Cマスターと呼ばれたい？俺はCマスターだよ。
>>650,652
コードの意味は理解出来たようだな。
>>653
スタック積むタイミングの話だよ。知ってて言っているだろ。
>>656
違うな。
「基礎を知らないベテランプログラマを、からかっている。」
だよ。
>>癖定義野郎
癖の例はどうなった？
Cマスターと呼ばれたい？俺はCマスターだよ。
>>650,652
コードの意味は理解出来たようだな。
>>653
スタック積むタイミングの話だよ。知ってて言っているだろ。
>>656
違うな。
「基礎を知らないベテランプログラマを、からかっている。」
だよ。
>>癖定義野郎
癖の例はどうなった？
>>657
スタックに積むタイミングってなに？
スタックに積むタイミングってなに？
>コードの意味は理解出来たよう
理解できてないのはお前ひとりだったわけだが
ようやく理解したの？
>基礎を知らないベテランプログラマを、からかっている。
自虐ですか？
Cマスター（笑）様
理解できてないのはお前ひとりだったわけだが
ようやく理解したの？
>基礎を知らないベテランプログラマを、からかっている。
自虐ですか？
Cマスター（笑）様
>>655
ｶﾞｯ
ｶﾞｯ
>>657
え、気がつかなかったの？
>で、俺の言ったのは全部間違いだとして、Cマスターに求められる知識としての癖の話をしてくれないか？
652が癖(笑)を訂正した例。わざわざ癖(笑)を訂正する必要性がないのでお馬鹿なソースコードだと書いてある。
Cで訂正する必要性がない仕様外であると明記された癖(笑)とかいわれた単なるバグをアセンブラで訂正。
Ｃで訂正できない癖を直すのが本懐なわけだが。
え、気がつかなかったの？
>で、俺の言ったのは全部間違いだとして、Cマスターに求められる知識としての癖の話をしてくれないか？
652が癖(笑)を訂正した例。わざわざ癖(笑)を訂正する必要性がないのでお馬鹿なソースコードだと書いてある。
Cで訂正する必要性がない仕様外であると明記された癖(笑)とかいわれた単なるバグをアセンブラで訂正。
Ｃで訂正できない癖を直すのが本懐なわけだが。
#include <stdio.h>
int main() {
char* target_string = "abcdefghijklmn";
char* one_character = NULL;
while( * (one_character = target_string++)) {
printf("%c", *one_character);
}
return 0;
}
昔
* (one_character = target_string++)
が何を意味するかわからない「自称Cマスター」が居たような希ガス。
ここのCマスターならきっと日本語で説明できるはずだ。
int main() {
char* target_string = "abcdefghijklmn";
char* one_character = NULL;
while( * (one_character = target_string++)) {
printf("%c", *one_character);
}
return 0;
}
昔
* (one_character = target_string++)
が何を意味するかわからない「自称Cマスター」が居たような希ガス。
ここのCマスターならきっと日本語で説明できるはずだ。
664 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/11(火) 19:39:19
>>663
俺に出した問題のようだな。これは、ポインタとかNULLとか分からない人向けの問題だぞ。なめてんのか？
つまらないからとっとと、答えてしまおう。まず、質問どおり答えると、
「* (one_character = target_string++) 」の意味するのは「現在の文字」だが、
そういう意図で出した問題ではないだろう。質問が悪い。
「while( * (one_character = target_string++)) {」が何を意味するかなら、
「文字列の最後（NULL）まで繰り返す」と言う答えになる。そういう問題にしたかったのだろう？
ちなみに俺の言う「Cマスター」とはレベルが違う。
上記、基本情報処理の午後の問題に出てくるような物が分かったとしても、Cマスターとは言えない。
俺が出したCマスターの条件は、言語レベルは理解しているのが当然で、fork()を使ってプロセス管理するとか、
ソケットを使った通信の手順とか、DBの使い方とか業務レベルの処理を組めるかと言う話になる。
俺に出した問題のようだな。これは、ポインタとかNULLとか分からない人向けの問題だぞ。なめてんのか？
つまらないからとっとと、答えてしまおう。まず、質問どおり答えると、
「* (one_character = target_string++) 」の意味するのは「現在の文字」だが、
そういう意図で出した問題ではないだろう。質問が悪い。
「while( * (one_character = target_string++)) {」が何を意味するかなら、
「文字列の最後（NULL）まで繰り返す」と言う答えになる。そういう問題にしたかったのだろう？
ちなみに俺の言う「Cマスター」とはレベルが違う。
上記、基本情報処理の午後の問題に出てくるような物が分かったとしても、Cマスターとは言えない。
俺が出したCマスターの条件は、言語レベルは理解しているのが当然で、fork()を使ってプロセス管理するとか、
ソケットを使った通信の手順とか、DBの使い方とか業務レベルの処理を組めるかと言う話になる。
666 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/11(火) 19:59:26
もしかして、ここに出て来るアセンブラやってる人って、C言語はあまり出来ない人か？
Cやっててアセンブラに移ったのかと思ってたが、よく考えてみると、アセンブラ専門にやってて
C苦手な人もいるよな。そうだとすると、今までの話の流れが納得出来る。
Cやっててアセンブラに移ったのかと思ってたが、よく考えてみると、アセンブラ専門にやってて
C苦手な人もいるよな。そうだとすると、今までの話の流れが納得出来る。
>>664
ったら失礼だな。>663はお前を試してるのに、それかｗ
つかお前、COBOLでいいようなことできて何がCマスターなんだ？何のためのCなんかね。
具体的な話になると、いきなり底が浅くなるおじゃばがかわいい。
ったら失礼だな。>663はお前を試してるのに、それかｗ
つかお前、COBOLでいいようなことできて何がCマスターなんだ？何のためのCなんかね。
具体的な話になると、いきなり底が浅くなるおじゃばがかわいい。
>もしかして、ここに出て来るアセンブラやってる人って、C言語はあまり出来ない人か？
デバッグの時にアセンブラみるのがＣプログラマーの嗜みです。
Ｃマスターは必要ないし、造語作って誤魔化せるのでいいらしいけど。
でも、普通のＣプログラマーなのでアセンブラ読みます。
つーか、バグ出しとしてログ仕込んでダンプ読むの普通じゃね？
Ｃマスターはしないの？
所でforkはUNIXのシステムコールなので厳密にはC言語じゃない。
WindowsだとCreateProcessだな。
というか、通信系では当たり前の処理で勝ち誇る理由がわからん。
ちなみにWindowsだとスレッドを使うのが主流。
そういえば、ずいぶん前だがJavaでソケット系の処理が蛸で笑われた事もあったなぁ。
デバッグの時にアセンブラみるのがＣプログラマーの嗜みです。
Ｃマスターは必要ないし、造語作って誤魔化せるのでいいらしいけど。
でも、普通のＣプログラマーなのでアセンブラ読みます。
つーか、バグ出しとしてログ仕込んでダンプ読むの普通じゃね？
Ｃマスターはしないの？
所でforkはUNIXのシステムコールなので厳密にはC言語じゃない。
WindowsだとCreateProcessだな。
というか、通信系では当たり前の処理で勝ち誇る理由がわからん。
ちなみにWindowsだとスレッドを使うのが主流。
そういえば、ずいぶん前だがJavaでソケット系の処理が蛸で笑われた事もあったなぁ。
おじゃばはforkって言いたいだけｗ どんだけ覚えたてだよｗ
>>668
>というか、通信系では当たり前の処理で勝ち誇る理由がわからん。
おじゃばは業務系の仕事をしてて、人付き合いがうまくいかないのを
｢俺はオブジェクト指向の技術屋でCマスター(笑)｣だからいいの、って
自分で納得したいのよ。かわいそうな奴なんだねｗ
>というか、通信系では当たり前の処理で勝ち誇る理由がわからん。
おじゃばは業務系の仕事をしてて、人付き合いがうまくいかないのを
｢俺はオブジェクト指向の技術屋でCマスター(笑)｣だからいいの、って
自分で納得したいのよ。かわいそうな奴なんだねｗ
>>668
>所でforkはUNIXのシステムコールなので厳密にはC言語じゃない。
そこはほら、RedHatとかMiracleとかMintavistaとかの｢メジャーな機種｣のUNIX(wはちがうのかもね。
>所でforkはUNIXのシステムコールなので厳密にはC言語じゃない。
そこはほら、RedHatとかMiracleとかMintavistaとかの｢メジャーな機種｣のUNIX(wはちがうのかもね。
>>671
では先生、NetBSDとPlan9ではどうですかｗ？
では先生、NetBSDとPlan9ではどうですかｗ？
>>664
＞俺が出したCマスターの条件は、言語レベルは理解しているのが当然で、
×言語レベルは理解しているのが当然で
○入門程度のC言語の文法は理解しているのが当然で
おじゃばの言う「Cマスター」は、とりあえず業務がこなせる程度のレベルで、
「C言語」そのものに対する理解度は、大して問題じゃないらしい。
＞俺が出したCマスターの条件は、言語レベルは理解しているのが当然で、
×言語レベルは理解しているのが当然で
○入門程度のC言語の文法は理解しているのが当然で
おじゃばの言う「Cマスター」は、とりあえず業務がこなせる程度のレベルで、
「C言語」そのものに対する理解度は、大して問題じゃないらしい。
>>所でforkはUNIXのシステムコールなので厳密にはC言語じゃない。
>そこはほら、RedHatとかMiracleとかMintavistaとかの｢メジャーな機種｣のUNIX(wはちがうのかもね。
まぁ落ち着け。
おじゃばは「メジャーな機種のLinux」とは言ったが「UNIX」とは言って無い。
だからきっとLinuxでは違うんだよｗｗ
>そこはほら、RedHatとかMiracleとかMintavistaとかの｢メジャーな機種｣のUNIX(wはちがうのかもね。
まぁ落ち着け。
おじゃばは「メジャーな機種のLinux」とは言ったが「UNIX」とは言って無い。
だからきっとLinuxでは違うんだよｗｗ
> もしかして、ここに出て来るアセンブラやってる人って、C言語はあまり出来ない人か？
おまえ・・・・・アホ？
極々簡単なアセンブリコードすら読めなくてよくCマスター(笑)とか言えるな
Cのデバッグするときに見ない馬鹿が居るのか？
DUMPも見ずにコンパイラの癖とか言う馬鹿は一味違うということか？
つーか何のためにCやってんの？
ちなみに俺は自慢じゃないがアセンブラでガリガリ書くのは到底無理
DUMPを読んで理解できる程度
おまえ・・・・・アホ？
極々簡単なアセンブリコードすら読めなくてよくCマスター(笑)とか言えるな
Cのデバッグするときに見ない馬鹿が居るのか？
DUMPも見ずにコンパイラの癖とか言う馬鹿は一味違うということか？
つーか何のためにCやってんの？
ちなみに俺は自慢じゃないがアセンブラでガリガリ書くのは到底無理
DUMPを読んで理解できる程度
folk関連のことをこれ以上言うと、おじゃばに通信系の処理するときにお前らも使うだろって言われるぞ(ｗ。
おじゃばのCマスターの定義と一般的なマスターに対する認識の次元が違うのはよくわかった。
そこら辺の本に書いてあるようなことを知ってるぐらいでマスター認定なんて。回りを見回せば
マスターだらけだな。あまりにも認識がズレてる。レベルが圧倒的に違いすぎるんだよ。
そこら辺の本に書いてあるようなことを知ってるぐらいでマスター認定なんて。回りを見回せば
マスターだらけだな。あまりにも認識がズレてる。レベルが圧倒的に違いすぎるんだよ。
今日もおじゃばは元気そうで快調そうだな。
497のレスとか癖の例とかだれか返答してあげれば～。
497のレスとか癖の例とかだれか返答してあげれば～。
>>497は質問の体を成してないからなぁ。質問のへたな子の相手は疲れるよ。
「コテハンの俺にCを教えろ」のスレはここですか？
497ねぇ・・・
>>497
＞ユースケースは仕入れる、出荷する、在庫数を調べるなのだから
客からの要望なのか、自社で汎用的なパッケージを作ろうとしてるのか分からんが、
要件はおじゃばしか知らんのだから、ちゃんとユースケース記述まで書いてくれ。
なんで俺らがおじゃばを客としてヒアリングせにゃならんのだ？
>>497
＞ユースケースは仕入れる、出荷する、在庫数を調べるなのだから
客からの要望なのか、自社で汎用的なパッケージを作ろうとしてるのか分からんが、
要件はおじゃばしか知らんのだから、ちゃんとユースケース記述まで書いてくれ。
なんで俺らがおじゃばを客としてヒアリングせにゃならんのだ？
682 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/12(水) 10:00:27
やっと分かったぞ、オマエラの正体が。
「WindowsのCプログラマ」だな。
「WindowsのCプログラマ」だな。
>>682
Windowsは作ってねーよｗ
Windowsは作ってねーよｗ
いつもながら言うことがコロコロ変わるアホだな
・・・いや、全く関係ないレベルで突っ込み入れられるんですけど。
687 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/12(水) 19:34:51
だから、Solarisネタには無関心だし、Linuxの環境は持ってないし、Borlandコンパイラに詳しい訳だ。
socket()には強気な割りには、fork()が苦手なのも納得出来る。Makefileの面倒さも知らない訳だ。
俺の出したCマスターの条件が気に入らなかったのも納得出来た。
確かにWindowsのCプログラマーには酷な話だ。ではWindowsのCマスターの呼び方を決めよう。
「Cマスター（Ｗ）」
でどうだ？一応言っておくが、ＷはWindowsのWだよ。
socket()には強気な割りには、fork()が苦手なのも納得出来る。Makefileの面倒さも知らない訳だ。
俺の出したCマスターの条件が気に入らなかったのも納得出来た。
確かにWindowsのCプログラマーには酷な話だ。ではWindowsのCマスターの呼び方を決めよう。
「Cマスター（Ｗ）」
でどうだ？一応言っておくが、ＷはWindowsのWだよ。
>>687
･･･バカ？いまさらいうこっちゃないけど。ディストリビューションが出てこないで
｢機種｣言う奴がなにを･･てか、LinuxでCやってる連中がアセンブリ読めないなんて事
俺にはとても恐ろしくて、
Linux板行ってちくってきちゃおーっとw
･･･バカ？いまさらいうこっちゃないけど。ディストリビューションが出てこないで
｢機種｣言う奴がなにを･･てか、LinuxでCやってる連中がアセンブリ読めないなんて事
俺にはとても恐ろしくて、
Linux板行ってちくってきちゃおーっとw
689 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/12(水) 20:07:12
>>688
単純に、Cマスター(ｗ)以下の連中がアセンブラ読めるはずが無いという事を盲信する為に、
おじゃば的に最下層と認定されるWindowsのCプログラマーだとレッテル張りする事をで精神的安定図ってるじゃないか？
まあ、それを抜きにしても、687は無様で無残だが。
単純に、Cマスター(ｗ)以下の連中がアセンブラ読めるはずが無いという事を盲信する為に、
おじゃば的に最下層と認定されるWindowsのCプログラマーだとレッテル張りする事をで精神的安定図ってるじゃないか？
まあ、それを抜きにしても、687は無様で無残だが。
しょうじき、Linux詳しくないんだけど、未だとFedoraを進めるのが基本だと思うんだけど。
ついでに、Cの簡単な動作確認ならVirtual PC使えば良いしと、これならただで済むし。
Red Hat > エンプラエディション使えって事じゃないか？
ついでに、Cの簡単な動作確認ならVirtual PC使えば良いしと、これならただで済むし。
Red Hat > エンプラエディション使えって事じゃないか？
>>693
俺は今ならUbuntuがいいかなと思う。
俺は今ならUbuntuがいいかなと思う。
要するに、「自分はマスター」と言いたくて、「自分がやったことがある事が出来ればマスター」ってことだろ。
ほら、あれだろ？営業が｢彼は一通りのＣ開発経験があります。Ｃマスターですよ！｣っていう意味合いだろ？
おじゃばが言いたいのは。
おじゃばが言いたいのは。
じゃあ組み込み環境でのCマスターは「Cマスター（E）」か？ｗ
もう何年も標準ライブラリはおろかfloat/double変数すら作っていませんorz
もう何年も標準ライブラリはおろかfloat/double変数すら作っていませんorz
699 ：仕様書無しさん：2008/03/12(水) 23:56:09
また伊賀知己か
700 ：仕様書無しさん：2008/03/13(木) 00:16:40
いいから消えろよ。
Unix/Linuxやってるからどうだとか、
Windowsやってるからどうだとか、
全くもってナンセンス
インフラ周りとUI周りではOSが違うことなんてしょっちゅうある
LinuxとWindowsとMacのそれぞれを使ってるけど、
makefileなんかいらないWindowsの開発環境はラクだと思うし、
autoconfのパッケージにも利点はあるし、
reseditを未だに使ってみたりもする
それぞれ違う知識が必要で、OSうんぬんで言語を語っても仕方ないし、
RedHatとTurboLinuxで挙動が違ってひっくり返ったこともあるし、
環境が違うことを卑下してる方がよっぽど変だと思うけどな
ちなみにLPIC2とSJC-WCは持ってる
Windowsやってるからどうだとか、
全くもってナンセンス
インフラ周りとUI周りではOSが違うことなんてしょっちゅうある
LinuxとWindowsとMacのそれぞれを使ってるけど、
makefileなんかいらないWindowsの開発環境はラクだと思うし、
autoconfのパッケージにも利点はあるし、
reseditを未だに使ってみたりもする
それぞれ違う知識が必要で、OSうんぬんで言語を語っても仕方ないし、
RedHatとTurboLinuxで挙動が違ってひっくり返ったこともあるし、
環境が違うことを卑下してる方がよっぽど変だと思うけどな
ちなみにLPIC2とSJC-WCは持ってる
folkやマルチスレッド、マルチプロセス、デーモン化、シグナル、mmap
非ブロッッキングのsocket通信、System V IPC、共有オブジェクト、
ここいらは、若僧レベルだよなぁ。
おじゃばは呼出規約も知らなかったようだから、ひょっとして、Cの関数
引数や戻り値の受渡しがどんなアセンブリコードに変換されるのかすら
イメージできてないんじゃないのか。だとしたら、マスターと呼ぶには
てんでお話にならないレベル。
非ブロッッキングのsocket通信、System V IPC、共有オブジェクト、
ここいらは、若僧レベルだよなぁ。
おじゃばは呼出規約も知らなかったようだから、ひょっとして、Cの関数
引数や戻り値の受渡しがどんなアセンブリコードに変換されるのかすら
イメージできてないんじゃないのか。だとしたら、マスターと呼ぶには
てんでお話にならないレベル。
folkって？ABCジュニアレベルかな？
RedHatが雑誌に付いてるって何年前の話？
CentOSとかがあるといえばあるけどさ
この馬鹿はなんで恥の上塗りをするかな
Windowsプログラマを馬鹿にした挙げ句
最近のLinuxディストリビューション(機種じゃないよ)事情も全く知らないとか
凄いねCマスター(笑)って
簡単なアセンブリコードすら読めず一体何をマスターしてるんだろうね？
お馬鹿スキルはマスターっぽいけど
マスターと言うからにはGCCとVCCの差異(癖)とかの知識は最低限必要じゃね？
Windowsプログラマを馬鹿にしてる時点でマスターも糞もねーよ
CentOSとかがあるといえばあるけどさ
この馬鹿はなんで恥の上塗りをするかな
Windowsプログラマを馬鹿にした挙げ句
最近のLinuxディストリビューション(機種じゃないよ)事情も全く知らないとか
凄いねCマスター(笑)って
簡単なアセンブリコードすら読めず一体何をマスターしてるんだろうね？
お馬鹿スキルはマスターっぽいけど
マスターと言うからにはGCCとVCCの差異(癖)とかの知識は最低限必要じゃね？
Windowsプログラマを馬鹿にしてる時点でマスターも糞もねーよ
なあ、おじゃばってそんなに若くないのかな？Redhatが雑誌の付録なんて言ってるんだから。
ひょっとして30代かな？なんかそんな歳で、こんなことで鼻高くしてるのってみっともねーな、
つーか悲しすぎるよ･･･
ひょっとして30代かな？なんかそんな歳で、こんなことで鼻高くしてるのってみっともねーな、
つーか悲しすぎるよ･･･
とりあえずmakefileの何が面倒なのか聞きたい
707 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/13(木) 10:00:43
いや、Windowsプログラマーを馬鹿にするつもりはないよ。
ただ、Cマスターと言うからにはgccとVCの違い（癖とは言わないらしい）とかの知識は最低限必要じゃね？
って事。
ただ、アセンブラやっててOSがWindowsだけってのは、確かにおかしい。
つまり、Cマスター（Ｅ）もいるわけだな。しかし組み込みはDBや画面系に弱いに違いない。
ただ、Cマスターと言うからにはgccとVCの違い（癖とは言わないらしい）とかの知識は最低限必要じゃね？
って事。
ただ、アセンブラやっててOSがWindowsだけってのは、確かにおかしい。
つまり、Cマスター（Ｅ）もいるわけだな。しかし組み込みはDBや画面系に弱いに違いない。
>>707
いや、自分はCマスターとか言ってるのお前だけだから。もういいよ、Cマスター(笑)。
いや、自分はCマスターとか言ってるのお前だけだから。もういいよ、Cマスター(笑)。
で、何ができるんよ。このアホコテは。
他を馬鹿にするだけで、結局本人は何もできないという・・・
他を馬鹿にするだけで、結局本人は何もできないという・・・
だんだん、おじゃば言うことが小さくなってきたな。
もうおじゃばがC言語をそんなに知らないことも
Linuxに対する認識が5年前で止まってることも分かったから、
そろそろオブジェクト指向の話に戻ろうや。
Linuxに対する認識が5年前で止まってることも分かったから、
そろそろオブジェクト指向の話に戻ろうや。
712 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/13(木) 20:56:04
は？
もう、このスレも潮時かもな
というか、おじゃばが潮時。
>>707
お前は自分より優秀な奴の存在を認めたくないだけじゃねえの？
優秀な奴ほどおこがましくて「マスターしてます」なんて言わないもんだよ
知識が多いから逆に自分が知らないことがあるのを自覚してるし、
上には上がいることも自覚してる
fork,forkとやかましいが、そこまでこだわる理由はなんだ？
基本は一本作って終わりだろ
まさか下手なコーディングでゾンビプロセス作りまくったとかのオチ？
お前は自分より優秀な奴の存在を認めたくないだけじゃねえの？
優秀な奴ほどおこがましくて「マスターしてます」なんて言わないもんだよ
知識が多いから逆に自分が知らないことがあるのを自覚してるし、
上には上がいることも自覚してる
fork,forkとやかましいが、そこまでこだわる理由はなんだ？
基本は一本作って終わりだろ
まさか下手なコーディングでゾンビプロセス作りまくったとかのオチ？
>>718
Windowsプログラマーにfolkはシステムコールだと指摘されたから、
その後もfolk、folkと煽られたから。
小学生レベルの反応だな。
つーか、親子プログラムだとパイプの方が重要に思えるの漏れだけ？
ちなみに、Windowsだと基本スレッドを使うのでおおむね必要なし。
Windowsプログラマーにfolkはシステムコールだと指摘されたから、
その後もfolk、folkと煽られたから。
小学生レベルの反応だな。
つーか、親子プログラムだとパイプの方が重要に思えるの漏れだけ？
ちなみに、Windowsだと基本スレッドを使うのでおおむね必要なし。
>>719
それには同意。がforkの綴りは直したほうがよさげだ。
それには同意。がforkの綴りは直したほうがよさげだ。
ふぉ、フォルク！？
ネ、ネタだよな！？
まさかfalseをファルスなんて言ってないよな！？
ネ、ネタだよな！？
まさかfalseをファルスなんて言ってないよな！？
いけね、おじゃばに馬鹿にされちゃう。
どうしよう(ｗ。
おじゃば、初歩的なスペルミスしちゃった～。
簡便してね。
どうしよう(ｗ。
おじゃば、初歩的なスペルミスしちゃった～。
簡便してね。
>>719
俺はLinuxだとソケットの方が良く使うかも。
俺はLinuxだとソケットの方が良く使うかも。
>>721
…今どき小学生でもそんな反応せんぞ。
…今どき小学生でもそんな反応せんぞ。
>>719=724
必死乙
必死乙
昔の人はいい言葉を遺したなぁ
能ある鷹は爪を隠す
能ある鷹は爪を隠す
Cの話題でスレ埋める勢いだな
どこぞの低能の所為で
どこぞの低能の所為で
というか、おじゃばが気まぐれすぎるのが問題なんだよな。
そもそもＣもわざわざ話題にするようなレベルの話じゃないし。
おじゃばじゃないかったら、バグ報告乙！ですます所だ。
そもそもＣもわざわざ話題にするようなレベルの話じゃないし。
おじゃばじゃないかったら、バグ報告乙！ですます所だ。
730 ：仕様書無しさん：2008/03/14(金) 06:07:47
馬鹿指数500% ( ﾟдﾟ )
731 ：仕様書無しさん：2008/03/14(金) 06:14:25
733 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/14(金) 09:46:10
>>716,717
ユースケース図を書けと言う事か？ユースケースならすでに書いているのだが、
システム：在庫管理
ユースケース：仕入れる、出荷する、在庫数を調べる
では足りないと言う事か？
アクターは利用者1つでいいと思うが。
それともアクターを、店員と管理者に分けて、
店員に、仕入れ、出荷、在庫数を調べるにして、
管理者に、倉庫の空きを調べる、必要な倉庫数を調べるとかにするか？
最初から複雑だと議論の余地がないので、単純な上の方でいいと思うが。
ユースケース図を書けと言う事か？ユースケースならすでに書いているのだが、
システム：在庫管理
ユースケース：仕入れる、出荷する、在庫数を調べる
では足りないと言う事か？
アクターは利用者1つでいいと思うが。
それともアクターを、店員と管理者に分けて、
店員に、仕入れ、出荷、在庫数を調べるにして、
管理者に、倉庫の空きを調べる、必要な倉庫数を調べるとかにするか？
最初から複雑だと議論の余地がないので、単純な上の方でいいと思うが。
場合によっちゃ、ザルだな
複雑な共通部品なんてＧＵＩ以外ないからじゃないの？
ＭＦＣなり、Ｑｔなり、準備されてるものを使うことはあっても
自前で用意することなんてあまりないし、誰かが用意してきても
迷惑じゃない？
用意されたクラス体系を覚えなきゃならんし、標準じゃないものなんて
使う気ににならない。
ゲーム業界なら必要だろうが。
ＭＦＣなり、Ｑｔなり、準備されてるものを使うことはあっても
自前で用意することなんてあまりないし、誰かが用意してきても
迷惑じゃない？
用意されたクラス体系を覚えなきゃならんし、標準じゃないものなんて
使う気ににならない。
ゲーム業界なら必要だろうが。
引き当てとか…
どうせ「ほーら、OOの話になったら誰も答えないだろ、俺エライ」つーのにもってきたいだけだろ。はいはい、えらいえらい。
ヒント：OOAとOODの違いって何？
739 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/14(金) 20:23:51
なんか無理っぽいな。
結局、OO設計やってる人はいないって事かな。
実際、俺も497に書いたような設計は業務には使わない。
多分、DBをDOAで設計して、構造化で機能分けして終わりだと思う。
まあそれでも、十分に運用に耐え得る物には出来る。
後から必要倉庫数を出せるようにしろとか言われたら、大変更になるがな。
まあ、ゼロから設計というのは、自由度が高い分、難しいのかもしれん。
誰か、OO設計して成功したとか体験談ないのかな？
結局、OO設計やってる人はいないって事かな。
実際、俺も497に書いたような設計は業務には使わない。
多分、DBをDOAで設計して、構造化で機能分けして終わりだと思う。
まあそれでも、十分に運用に耐え得る物には出来る。
後から必要倉庫数を出せるようにしろとか言われたら、大変更になるがな。
まあ、ゼロから設計というのは、自由度が高い分、難しいのかもしれん。
誰か、OO設計して成功したとか体験談ないのかな？
>>733
とりあえず「ユースケース記述」をググって来い
とりあえず「ユースケース記述」をググって来い
>>495
>まず、487で基礎だから本を読めば分かると言っているのに、488が明確な答えにはなっていない。
おれは、「基本だから書籍や資料を参考にすれば分る」と言った、俺が悩むところは詳細部分だ
>商品で分類して、保管場所フラグを持つ？確かに無難だが、ただのDOAだろう。
分析段階ではDOAもOOAもそんなに変わらない、設計を進めて行く段階で変わってくる
>Chain of Responsibilityや、Compositeパターン？
>イマイチ何を言いたいのか分からないが、倉庫で商品をリスト型や、階層構造で持つと言う事かな。
>リストは安易だろう？シーケンシャルで処理する物か？検索も遅いだろう。
オブジェクトをチェーン("Chain" of Responsibility)型で持つと言う事だ、このあたりから
DOAとオブジェクト指向の違いが出てくる、DOAがRDBを意識したデータ構造になる事が多いが
オブジェクト指向では、あくまでもオブジェクトを意識したデータ構造になる
だから、DOAと違いO／Rマッピングの設計が必要になってくる
「おじゃばさま」のレスを見ていると、このあたりの認識に問題がある「おじゃばさま」の
言っている事は、「オブジェクト指向」ではなく「クラス指向」に思えるが
>まず、487で基礎だから本を読めば分かると言っているのに、488が明確な答えにはなっていない。
おれは、「基本だから書籍や資料を参考にすれば分る」と言った、俺が悩むところは詳細部分だ
>商品で分類して、保管場所フラグを持つ？確かに無難だが、ただのDOAだろう。
分析段階ではDOAもOOAもそんなに変わらない、設計を進めて行く段階で変わってくる
>Chain of Responsibilityや、Compositeパターン？
>イマイチ何を言いたいのか分からないが、倉庫で商品をリスト型や、階層構造で持つと言う事かな。
>リストは安易だろう？シーケンシャルで処理する物か？検索も遅いだろう。
オブジェクトをチェーン("Chain" of Responsibility)型で持つと言う事だ、このあたりから
DOAとオブジェクト指向の違いが出てくる、DOAがRDBを意識したデータ構造になる事が多いが
オブジェクト指向では、あくまでもオブジェクトを意識したデータ構造になる
だから、DOAと違いO／Rマッピングの設計が必要になってくる
「おじゃばさま」のレスを見ていると、このあたりの認識に問題がある「おじゃばさま」の
言っている事は、「オブジェクト指向」ではなく「クラス指向」に思えるが
>>497
>つーか、ユースケースが関係ない。
俺は、ユースケース図は要件定義に使う
>俺なら、倉庫クラスがあったとしたら、その中で管理するのは1ダースケースクラスとか、
>段ボールクラスとかにする。それぞれに収納コストなどがあって、1ダースケースは1コスト、段ボール
>クラスは10コスト、倉庫100コストまで収容可能とかにする。
この辺りの考えもオブジェクトを意識しないで、クラス中心に考えているように見えるが．．．
「1ダースケース」「段ボール」は商品の一部じゃ無いのか？
倉庫から出すときに段ボールから商品だけを出すのか？
ここで重要なのは、入れ物の「1ダースケース」や「段ボール」じゃなく商品じゃないのか？
インスタンスを生成した場合、「1ダースケースクラス」や「段ボールクラス」がどのようなフィールドを持つ？
「コスト」だけか？、同じフィールドなら値を変えるだけだ、「1ダースケースクラス」「段ボールクラス」みたいな
別クラスを作るのはおかしい
もうちょっと具体的な問題を出したらどうだ
例えば、誰でも使ったことのあるレンタルビデオの「システム化」（ある意味在庫管理にもなる）
要件は
１．会員登録
２．ビデオ貸し出し
３．ビデオ返却
４．ビデオの移動・格納・消去
５．棚卸
こんな感じで要件までは決めないと、なんの事を聞きたいのか分からん
以上だ、あと「トップダウン男」は何だ？俺は「おじゃばさま」レベルに合わせて
「トップダウン設計」と書いただけだ、構造化でも別のちゃんとした手法を使っているぞ、失礼な
>つーか、ユースケースが関係ない。
俺は、ユースケース図は要件定義に使う
>俺なら、倉庫クラスがあったとしたら、その中で管理するのは1ダースケースクラスとか、
>段ボールクラスとかにする。それぞれに収納コストなどがあって、1ダースケースは1コスト、段ボール
>クラスは10コスト、倉庫100コストまで収容可能とかにする。
この辺りの考えもオブジェクトを意識しないで、クラス中心に考えているように見えるが．．．
「1ダースケース」「段ボール」は商品の一部じゃ無いのか？
倉庫から出すときに段ボールから商品だけを出すのか？
ここで重要なのは、入れ物の「1ダースケース」や「段ボール」じゃなく商品じゃないのか？
インスタンスを生成した場合、「1ダースケースクラス」や「段ボールクラス」がどのようなフィールドを持つ？
「コスト」だけか？、同じフィールドなら値を変えるだけだ、「1ダースケースクラス」「段ボールクラス」みたいな
別クラスを作るのはおかしい
もうちょっと具体的な問題を出したらどうだ
例えば、誰でも使ったことのあるレンタルビデオの「システム化」（ある意味在庫管理にもなる）
要件は
１．会員登録
２．ビデオ貸し出し
３．ビデオ返却
４．ビデオの移動・格納・消去
５．棚卸
こんな感じで要件までは決めないと、なんの事を聞きたいのか分からん
以上だ、あと「トップダウン男」は何だ？俺は「おじゃばさま」レベルに合わせて
「トップダウン設計」と書いただけだ、構造化でも別のちゃんとした手法を使っているぞ、失礼な
>>742
要件定義とは何かからおじゃばに教えるのか…物好きだな
要件定義とは何かからおじゃばに教えるのか…物好きだな
おじゃばみたいなやつは現場でも要件定義なんてさせてもらえないだろ
客と話してるかも疑問だ
客と話してるかも疑問だ
｢類が友を呼ぶ｣スレはここですか？
いいえ、ケフィアです。
おまいらC厨はうぜーな、おじゃばよりうぜー
どうせ構造化しか分からん中年PGか学生PGだろ
OOが分からないからって絡むな、C厨のスレに行けよ
おまいら消えろ、うぜーから
どうせ構造化しか分からん中年PGか学生PGだろ
OOが分からないからって絡むな、C厨のスレに行けよ
おまいら消えろ、うぜーから
うん、類友だなー。
中年のC厨は、自分が得意分野だけ元気がいいよなｗ
おじゃば最高
おじゃば天才
おじゃばは設計のプロ
おじゃばはJavaのメソッドを暗記している
おじゃばはCのすべてをマスターしている
おじゃばは”１０年前に”Linuxを極めている
おじゃば最高
おじゃば天才
おじゃば天才
おじゃばは設計のプロ
おじゃばはJavaのメソッドを暗記している
おじゃばはCのすべてをマスターしている
おじゃばは”１０年前に”Linuxを極めている
おじゃば最高
おじゃば天才
C厨にはおじゃば最高なんだろうな、レベルが同じだからｗ
本当うぜー、C厨
本当うぜー、C厨
ゆとり乙
中年PG・ゆとりPGは、本当にOOが嫌いなんだな
まったく理解できんから、しかたないがｗ
まったく理解できんから、しかたないがｗ
こうやって自分の世代以外の世代を嘲笑するレスが増えて行くわけか。
「俺たちはOOが理解できるからエリート世代だぜぇ」と言っているように聞こえるな。
本当の能力差は世代差ではなく個人差にあるということを理解すべきだと思うけどね
「俺たちはOOが理解できるからエリート世代だぜぇ」と言っているように聞こえるな。
本当の能力差は世代差ではなく個人差にあるということを理解すべきだと思うけどね
中年・ゆとりPG、ひがみ乙
>>756
たしかに、C厨には世代は関係ないなｗ
たしかに、C厨には世代は関係ないなｗ
というよりも、OOもCも理解が浅く終わっていて、
それも理由はおじゃばが理解できないからなのに、お互い排斥するなんて・・・、
おじゃばにこれ以上餌を与えるつもりか！
それも理由はおじゃばが理解できないからなのに、お互い排斥するなんて・・・、
おじゃばにこれ以上餌を与えるつもりか！
Cがどうこうはともかく、この仕事してる以上、やったことあることで、
しかもマスターしたと自分で言えることで、五年以上情報収集してない
ような奴はどうひいきめにみてもダメだと｢思う｣。無能じゃなくて怠惰。
しかもマスターしたと自分で言えることで、五年以上情報収集してない
ような奴はどうひいきめにみてもダメだと｢思う｣。無能じゃなくて怠惰。
継承を理解してても委譲を理解してない奴が多い
委譲か、使っているのは良く見るが
正しく実装しているのは見ないな
正しく実装しているのは見ないな
764 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/17(月) 08:36:33
>>742
1ダースケースや段ボールは商品の一部ではないと考えている。
例えば、コーラの1ダースケースはサイダーも入れられるかもしれないし、段ボールはお菓子を入れる事も
出来れば、衣服を入れる事も出来るかもしれない。またビールケースは商品を入れていなくても
スペースが必要だが、段ボールは畳んで収納出来る。冷凍庫は冷凍出来るが電源が必要かもしれない。
倉庫からは段ボール単位で出す事もあれば、段ボールをあけて数個の商品を出すかもしれない。
つまり、基本的にはコストだがコスト以外もあり、商品の一部というより入れ物だと思う。
俺の設計がクラス指向だと言うならそうかもしれないが、クラス指向=オブジェクト指向じゃないのか？
あと、トップダウン男が嫌なら、何ならいいのだ？
1ダースケースや段ボールは商品の一部ではないと考えている。
例えば、コーラの1ダースケースはサイダーも入れられるかもしれないし、段ボールはお菓子を入れる事も
出来れば、衣服を入れる事も出来るかもしれない。またビールケースは商品を入れていなくても
スペースが必要だが、段ボールは畳んで収納出来る。冷凍庫は冷凍出来るが電源が必要かもしれない。
倉庫からは段ボール単位で出す事もあれば、段ボールをあけて数個の商品を出すかもしれない。
つまり、基本的にはコストだがコスト以外もあり、商品の一部というより入れ物だと思う。
俺の設計がクラス指向だと言うならそうかもしれないが、クラス指向=オブジェクト指向じゃないのか？
あと、トップダウン男が嫌なら、何ならいいのだ？
766 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/17(月) 09:03:15
ビデオレンタルシステムか。
在庫管理より難しいと思うが、やるだけやってみるか。
アクターが3種類になるな。
客、店員、ビデオ業者
ユースケース見る限りでは、レンタル業務に必要な物と言う事だな。
会員登録（入会、修正、更新、脱会）、ビデオ（貸出し、返却、入荷、移動、廃棄）か。
ただ、ビデオは借りるが、レンタル業務の店員はやったことがないので、想像が多くなってしまう。
一番の問題は、顧客管理システムとビデオ貸出しシステムの2つを作って連動させるのか、
ビデオレンタルシステムとして1つの要素で設計するのかだ。
普通に考えれば、顧客管理とビデオ貸出しに分けて連動させるのだろうが、それでは面白みに欠ける。
しかし一つの要素で出来るのだろうか？
商品はビデオになるだろう。レンタル業務は結構複雑だ。まず新作か旧作かにより値段が変わる。
貸出し期間や会員レベルによっても変わる。ビデオは長持ちする事もあれば、破損や紛失もする。
シリーズ物で途中がずっとないなんて許されない。また延滞と言う要素もある。
在庫管理より難しいと思うが、やるだけやってみるか。
アクターが3種類になるな。
客、店員、ビデオ業者
ユースケース見る限りでは、レンタル業務に必要な物と言う事だな。
会員登録（入会、修正、更新、脱会）、ビデオ（貸出し、返却、入荷、移動、廃棄）か。
ただ、ビデオは借りるが、レンタル業務の店員はやったことがないので、想像が多くなってしまう。
一番の問題は、顧客管理システムとビデオ貸出しシステムの2つを作って連動させるのか、
ビデオレンタルシステムとして1つの要素で設計するのかだ。
普通に考えれば、顧客管理とビデオ貸出しに分けて連動させるのだろうが、それでは面白みに欠ける。
しかし一つの要素で出来るのだろうか？
商品はビデオになるだろう。レンタル業務は結構複雑だ。まず新作か旧作かにより値段が変わる。
貸出し期間や会員レベルによっても変わる。ビデオは長持ちする事もあれば、破損や紛失もする。
シリーズ物で途中がずっとないなんて許されない。また延滞と言う要素もある。
767 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/17(月) 09:23:15
こういうソースを読まないクセが妄想を発達させるんだろうな
770 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/17(月) 12:49:13
いやリンク張りを容認する文化が、ひな鳥世代を増長させるんだよ。
771完全勝利ｗ
>>764
クラスはいいから、まずユースケースについて書け
「思う」とか「かもしれない」とかが多い段階で
インターフェースがどうのこうのはまだ早い
> クラス指向=オブジェクト指向じゃないのか？
オブジェクト指向はオブジェクト指向
クラスはいいから、まずユースケースについて書け
「思う」とか「かもしれない」とかが多い段階で
インターフェースがどうのこうのはまだ早い
> クラス指向=オブジェクト指向じゃないのか？
オブジェクト指向はオブジェクト指向
775 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/17(月) 19:48:39
>>773
何が勝利なのか分からないが、考える事を放棄してリンクを張るより、
批判されようと自分の意見を書く方がカッコイイと思う。
あと、リンクのみやコピペのみって恥ずかしい行為だから、多用しない方がいいぞ。
なんか在庫管理でも誰も付いて来ていないのに、ビデオレンタルなんかは絶望的に見えるが、
まあやるだけやってみよう。トップダウン男は来るかな？
顧客管理と在庫管理を別々に設計して、連動させるのは妥当だ。業務ならこれで構造化で設計するだろう。
今回はオブジェクト指向なので、レンタルシステムとして設計してみよう。
まず、店舗と会員宅を設定し、商品（ビデオ）が移動する事によって、料金が発生するシステムだと
考えてみよう。会員宅に移動している期間によって料金が発生する。会員の借りられる枚数は
一度に10枚までなどの制限が入るだろう。店舗には商品棚があるが、倉庫の時のシステムとは違い、
収容量や収容位置はあまり気にする必要はないだろう。DVDは縦置きにしたり横置きにしたりで収容枚数が
変わるし、配置が頻繁に変わるので位置情報は無意味だ。強いて言うならジャンル事に変わるが、
ジャンルによる収容枚数も可変になる。また販売ではないので在庫は意味がない。
商品は全て棚に並べられると考える事にする。
何が勝利なのか分からないが、考える事を放棄してリンクを張るより、
批判されようと自分の意見を書く方がカッコイイと思う。
あと、リンクのみやコピペのみって恥ずかしい行為だから、多用しない方がいいぞ。
なんか在庫管理でも誰も付いて来ていないのに、ビデオレンタルなんかは絶望的に見えるが、
まあやるだけやってみよう。トップダウン男は来るかな？
顧客管理と在庫管理を別々に設計して、連動させるのは妥当だ。業務ならこれで構造化で設計するだろう。
今回はオブジェクト指向なので、レンタルシステムとして設計してみよう。
まず、店舗と会員宅を設定し、商品（ビデオ）が移動する事によって、料金が発生するシステムだと
考えてみよう。会員宅に移動している期間によって料金が発生する。会員の借りられる枚数は
一度に10枚までなどの制限が入るだろう。店舗には商品棚があるが、倉庫の時のシステムとは違い、
収容量や収容位置はあまり気にする必要はないだろう。DVDは縦置きにしたり横置きにしたりで収容枚数が
変わるし、配置が頻繁に変わるので位置情報は無意味だ。強いて言うならジャンル事に変わるが、
ジャンルによる収容枚数も可変になる。また販売ではないので在庫は意味がない。
商品は全て棚に並べられると考える事にする。
>>775
>774
>774
>>775
いいえ、それは俺々レンタルビデオシステムです
いいえ、それは俺々レンタルビデオシステムです
>>775
在庫は意味が無い？ほんとかなぁ...
在庫は意味が無い？ほんとかなぁ...
レンタルビデオ屋は棚卸しないのかな、年中無休なんでいつやってるか知らないが
>顧客管理と在庫管理を別々に設計して、連動させる
これだけだと意図がわからんから何もいえん
>店舗と会員宅を設定し、商品（ビデオ）が移動する事によって、料金が発生するシステムだと
>考えてみよう。会員宅に移動している期間によって料金が発生する。
ぇえええ？
店舗または商品が会員宅と直接関係持ってるのか？！
>会員の借りられる枚数は
>一度に10枚までなどの制限が入るだろう。店舗には商品棚があるが、倉庫の時のシステムとは違い、
>収容量や収容位置はあまり気にする必要はないだろう。DVDは縦置きにしたり横置きにしたりで収容枚数が
>変わるし、配置が頻繁に変わるので位置情報は無意味だ。
棚の番号だけでも残したら？
配置が変わるってのは客へのレンタルも含まれてるのかｗｗｗ？
>ジャンルによる収容枚数も可変になる。
そりゃあ固定じゃないだろ
ドラマもアニメも映画もそれぞれ２００枚きっかりってどんなだよ
>また販売ではないので在庫は意味がない。
在庫がなければその場で貸せないのだが…？
それとも何か？後日配送が暗黙の前提か？
>商品は全て棚に並べられると考える事にする。
これもまぁまぁ、ＯＫ
批判されようと自分の意見を書く方より
正しい意見と答えをいえる俺のほうがカッコイイと思う。
これだけだと意図がわからんから何もいえん
>店舗と会員宅を設定し、商品（ビデオ）が移動する事によって、料金が発生するシステムだと
>考えてみよう。会員宅に移動している期間によって料金が発生する。
ぇえええ？
店舗または商品が会員宅と直接関係持ってるのか？！
>会員の借りられる枚数は
>一度に10枚までなどの制限が入るだろう。店舗には商品棚があるが、倉庫の時のシステムとは違い、
>収容量や収容位置はあまり気にする必要はないだろう。DVDは縦置きにしたり横置きにしたりで収容枚数が
>変わるし、配置が頻繁に変わるので位置情報は無意味だ。
棚の番号だけでも残したら？
配置が変わるってのは客へのレンタルも含まれてるのかｗｗｗ？
>ジャンルによる収容枚数も可変になる。
そりゃあ固定じゃないだろ
ドラマもアニメも映画もそれぞれ２００枚きっかりってどんなだよ
>また販売ではないので在庫は意味がない。
在庫がなければその場で貸せないのだが…？
それとも何か？後日配送が暗黙の前提か？
>商品は全て棚に並べられると考える事にする。
これもまぁまぁ、ＯＫ
批判されようと自分の意見を書く方より
正しい意見と答えをいえる俺のほうがカッコイイと思う。
なんでおじゃばは「ユースケース記述を書け(または調べろ)」という意見を頑なにスルーするのか
ビデオレンタルシステムのアクターって店員とせいぜい管理者ぐらいのような気がするけど。
おじゃば的ビデオレンタルシステムは、客とビデオ業者にも使わせんのかよ。
つぅことはネットレンタルやEコマースも視野にいれてるっつことか。だったらなおのこと
ユースケース書けよ。システム範囲を決めずに設計なんかできるかよ。
おじゃばってもしかして、客の要件をろくにきかずに妄想でおれおれ設計するタイプか。
おじゃば的ビデオレンタルシステムは、客とビデオ業者にも使わせんのかよ。
つぅことはネットレンタルやEコマースも視野にいれてるっつことか。だったらなおのこと
ユースケース書けよ。システム範囲を決めずに設計なんかできるかよ。
おじゃばってもしかして、客の要件をろくにきかずに妄想でおれおれ設計するタイプか。
>>764
> 1ダースケースや段ボールは商品の一部ではないと考えている。
>例えば、コーラの1ダースケースはサイダーも入れられるかもしれないし、段ボールはお菓子を入れる事も
>出来れば、衣服を入れる事も出来るかもしれない。またビールケースは商品を入れていなくても
>スペースが必要だが、段ボールは畳んで収納出来る。冷凍庫は冷凍出来るが電源が必要かもしれない。
>倉庫からは段ボール単位で出す事もあれば、段ボールをあけて数個の商品を出すかもしれない。
>つまり、基本的にはコストだがコスト以外もあり、商品の一部というより入れ物だと思う。
分析や初期の設計段階から、「1ダースケース」や「段ボール」は詳細になり過ぎだとおもう
もう少し大枠で分析して、それを設計段階で徐々に詳細化しないと
例えば「倉庫」クラス→「場所」「コンテナ」(複数の商品を一括して管理・場所と違い移動可能）クラスで
「1ダースケース」「段ボール」クラスとか段階を踏んでいかないと
> 1ダースケースや段ボールは商品の一部ではないと考えている。
>例えば、コーラの1ダースケースはサイダーも入れられるかもしれないし、段ボールはお菓子を入れる事も
>出来れば、衣服を入れる事も出来るかもしれない。またビールケースは商品を入れていなくても
>スペースが必要だが、段ボールは畳んで収納出来る。冷凍庫は冷凍出来るが電源が必要かもしれない。
>倉庫からは段ボール単位で出す事もあれば、段ボールをあけて数個の商品を出すかもしれない。
>つまり、基本的にはコストだがコスト以外もあり、商品の一部というより入れ物だと思う。
分析や初期の設計段階から、「1ダースケース」や「段ボール」は詳細になり過ぎだとおもう
もう少し大枠で分析して、それを設計段階で徐々に詳細化しないと
例えば「倉庫」クラス→「場所」「コンテナ」(複数の商品を一括して管理・場所と違い移動可能）クラスで
「1ダースケース」「段ボール」クラスとか段階を踏んでいかないと
>俺の設計がクラス指向だと言うならそうかもしれないが、クラス指向=オブジェクト指向じゃないのか？
この例だと、「おじゃばさま」が「入れ物」クラスを作って在庫管理をしようとしている
しかし、「入れ物」はクラスにするのが本当に適切か？管理したい為の機能じゃないのか？
実際の動きをシュミレーションすると
「A段ボールオブジェクト」に、「商品が何個入っている？」とメッセージを送る
「A段ボールオブジェクト」は、「３個入ってます」となる、商品オブジェクトは管理されるだけだ
俺がこの在庫システムを作ると、商品オブジェクトをChain of Responsibilityパターンで関連付ける
そうしたときの動きをシュミレーションは
「1番目商品オブジェクト」に(「A段ボール」に入っている奴番号を数えろ）とメッセージを送る
（商品オブジェクトは次の商品オブジェクトにメッセージを送る(Chain of Responsibilityパターン))
「1番目商品オブジェクト」(俺は「A段ボール」に入っているから１、次へ）
「2番目商品オブジェクト」(俺は「B段ボール」に入っている関係ない、次へ)
「3番目商品オブジェクト」(俺は「A段ボール」に入っていて、前が１だから２、次へ）
「4番目商品オブジェクト」(俺は「B段ボール」に入っている関係ない、次へ)
「5番目商品オブジェクト」(俺は「A段ボール」に入っていて、前が２だから３で、最後だから３を返す）
と言う感じになる、商品オブジェクトは管理されていない、個々の商品オブジェクトが会話(メッセージ)しながら
関係する商品オブジェクトがカウントをアップさせていく、こんな感じがオブジェクト指向だと思う
つまり、オブジェクトは管理されるのでは無く自発的に行動するのがオブジェクト指向
今日は晩くなったから「レンタルシステム」は次に書く
この例だと、「おじゃばさま」が「入れ物」クラスを作って在庫管理をしようとしている
しかし、「入れ物」はクラスにするのが本当に適切か？管理したい為の機能じゃないのか？
実際の動きをシュミレーションすると
「A段ボールオブジェクト」に、「商品が何個入っている？」とメッセージを送る
「A段ボールオブジェクト」は、「３個入ってます」となる、商品オブジェクトは管理されるだけだ
俺がこの在庫システムを作ると、商品オブジェクトをChain of Responsibilityパターンで関連付ける
そうしたときの動きをシュミレーションは
「1番目商品オブジェクト」に(「A段ボール」に入っている奴番号を数えろ）とメッセージを送る
（商品オブジェクトは次の商品オブジェクトにメッセージを送る(Chain of Responsibilityパターン))
「1番目商品オブジェクト」(俺は「A段ボール」に入っているから１、次へ）
「2番目商品オブジェクト」(俺は「B段ボール」に入っている関係ない、次へ)
「3番目商品オブジェクト」(俺は「A段ボール」に入っていて、前が１だから２、次へ）
「4番目商品オブジェクト」(俺は「B段ボール」に入っている関係ない、次へ)
「5番目商品オブジェクト」(俺は「A段ボール」に入っていて、前が２だから３で、最後だから３を返す）
と言う感じになる、商品オブジェクトは管理されていない、個々の商品オブジェクトが会話(メッセージ)しながら
関係する商品オブジェクトがカウントをアップさせていく、こんな感じがオブジェクト指向だと思う
つまり、オブジェクトは管理されるのでは無く自発的に行動するのがオブジェクト指向
今日は晩くなったから「レンタルシステム」は次に書く
>>782
分析と設計の区別もつかない奴になにを求めてるんだｗ
こんなのに客の要件聞きに行かせられるかぁ？
レンタルビデオ屋のビデオ置き場に行って、客の話も訊かずに
「ココにはビールケースが入るかも知れない。2000ケースくらいか」
とかぶつぶつ言ってるような奴だぞｗ
分析と設計の区別もつかない奴になにを求めてるんだｗ
こんなのに客の要件聞きに行かせられるかぁ？
レンタルビデオ屋のビデオ置き場に行って、客の話も訊かずに
「ココにはビールケースが入るかも知れない。2000ケースくらいか」
とかぶつぶつ言ってるような奴だぞｗ
788 ：sage：2008/03/18(火) 01:57:04
>>784
何で商品が、自身を入れるハコに依存してんだ？
何で商品が、「次へ」チェインするの？
たかだか１個の商品を、
「段ボールに入る」ことを前提として
「線形アクセスされる」ことを前提として
設計するなよ。
関心の分離、抽象化、カプセル化、再利用性を知らんのか？
何で商品が、自身を入れるハコに依存してんだ？
何で商品が、「次へ」チェインするの？
たかだか１個の商品を、
「段ボールに入る」ことを前提として
「線形アクセスされる」ことを前提として
設計するなよ。
関心の分離、抽象化、カプセル化、再利用性を知らんのか？
>分析できないクンと長文クン
箱があってもなくてもいいが、まず、どっちなのかを明確にしろ
クラスにするとかしないとか、なんで「全て実装ありき」なんだ？
システム化する部分としない部分ぐらい線引きしろ
全自動宅配レンタルロボでも作るつもりか？
箱があってもなくてもいいが、まず、どっちなのかを明確にしろ
クラスにするとかしないとか、なんで「全て実装ありき」なんだ？
システム化する部分としない部分ぐらい線引きしろ
全自動宅配レンタルロボでも作るつもりか？
>長文クン
一応言っておくが、シュミレーションはやめとけ
一応言っておくが、シュミレーションはやめとけ
オブジェクト指向はともかく、
そこそこ経験を積んだ無能の作ったシステムが
なぜ崩壊するかわかった気がする。
そこそこ経験を積んだ無能の作ったシステムが
なぜ崩壊するかわかった気がする。
おじゃばはシステム設計者じゃないから
崩壊の直接原因にはならんだろうが
糞詳細設計とかクラス設計見るとおじゃばを思い出すようになった
崩壊の直接原因にはならんだろうが
糞詳細設計とかクラス設計見るとおじゃばを思い出すようになった
793 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/18(火) 09:39:18
>>778
ビデオレンタル業務を詳しく知らないので、そのの点は想像でしかない。
本屋と違って棚の下にはなかったような気がした。
>>779
棚卸し？入荷、移動、廃棄に分解してみたが、問題あるか？
>>780
その正しい意見で設計してくれよ。
>>782
確かに店舗のレンタルシステムは、店員しか触らないな。後で書いてみよう。
ビデオレンタル業務を詳しく知らないので、そのの点は想像でしかない。
本屋と違って棚の下にはなかったような気がした。
>>779
棚卸し？入荷、移動、廃棄に分解してみたが、問題あるか？
>>780
その正しい意見で設計してくれよ。
>>782
確かに店舗のレンタルシステムは、店員しか触らないな。後で書いてみよう。
794 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/18(火) 10:15:21
>>784
商品に全情報を入れて、チェーンで繋ぐと言う方式か。確かにシンプルだ。
いや前の書き込みを見ると、全情報とは言っていないか。情報がない場合は「なし」とか返させるのかな？
何かを調べる場合は全検索する訳だな。入荷出荷はチェーン操作で行い、在庫チェックは全検索か。
データ保存はO/Rマッピングかな？確かに面白いし可能だ。
問題は処理速度だけか。処理速度はどうする？インデックスみたいな物でも作るか？
商品に全情報を入れて、チェーンで繋ぐと言う方式か。確かにシンプルだ。
いや前の書き込みを見ると、全情報とは言っていないか。情報がない場合は「なし」とか返させるのかな？
何かを調べる場合は全検索する訳だな。入荷出荷はチェーン操作で行い、在庫チェックは全検索か。
データ保存はO/Rマッピングかな？確かに面白いし可能だ。
問題は処理速度だけか。処理速度はどうする？インデックスみたいな物でも作るか？
796 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/18(火) 19:35:26
問題に思えるのが、商品データの記憶方法と処理速度だ。
全属性を網羅した商品テーブルは作らないと思うから、複数のテーブルから商品1つを作成するように思える。
検索は頻繁に使うと思うので、開始時に全データをメモリに取り込むのかな？
いくら何でも、全データをメモリに取り込んだりしないと思うので、取り込まないと考える。
商品を追加するとして、例えば空いている箱に入れるとしたら、まず箱Aの商品数を集計して、
最大値に達していなければ、次の箱の集計を行うのかな？商品をメモリ上に持っていないとしたら、
1商品を検索するのに複数のテーブルを検索する気がする。
そして空いている箱を見つけたら、商品を追加して、テーブルを更新するのかな？
その間はロックしないと不整合が発生するが、商品単位なので、全ロックを掛ける必要がある気がする。
1回の商品登録に物凄い検索が必要になる気がするがどうなのだろうか？
斬新な設計だが無茶な気がする。それとも根本的に何か違うのかな？
全属性を網羅した商品テーブルは作らないと思うから、複数のテーブルから商品1つを作成するように思える。
検索は頻繁に使うと思うので、開始時に全データをメモリに取り込むのかな？
いくら何でも、全データをメモリに取り込んだりしないと思うので、取り込まないと考える。
商品を追加するとして、例えば空いている箱に入れるとしたら、まず箱Aの商品数を集計して、
最大値に達していなければ、次の箱の集計を行うのかな？商品をメモリ上に持っていないとしたら、
1商品を検索するのに複数のテーブルを検索する気がする。
そして空いている箱を見つけたら、商品を追加して、テーブルを更新するのかな？
その間はロックしないと不整合が発生するが、商品単位なので、全ロックを掛ける必要がある気がする。
1回の商品登録に物凄い検索が必要になる気がするがどうなのだろうか？
斬新な設計だが無茶な気がする。それとも根本的に何か違うのかな？
797 ： ◆Lfg5fzuOJ2 ：2008/03/18(火) 19:42:28
おじゃば最高
おじゃば天才
おじゃばは設計のプロ
おじゃばはJavaのメソッドを暗記している
おじゃばはCのすべてをマスターしている
おじゃばは”１０年前に”Linuxを極めている
おじゃば最高
おじゃば天才
おじゃば天才
おじゃばは設計のプロ
おじゃばはJavaのメソッドを暗記している
おじゃばはCのすべてをマスターしている
おじゃばは”１０年前に”Linuxを極めている
おじゃば最高
おじゃば天才
798 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/18(火) 19:42:48
ビデオレンタルのユースケースをやってみよう。
良く考えると、782の指摘通り、ビデオレンタル屋は店員が全てやっていると思う。
アクターは、「店員」だけにしてみよう。
ユースケースは「貸出し」「返却」「入荷」「廃棄」「会員登録」「会員修正」かな。
会員更新、脱会は会員修正で一元化出来る。
この後、どうするんだ？誰かやってみてくれ。
良く考えると、782の指摘通り、ビデオレンタル屋は店員が全てやっていると思う。
アクターは、「店員」だけにしてみよう。
ユースケースは「貸出し」「返却」「入荷」「廃棄」「会員登録」「会員修正」かな。
会員更新、脱会は会員修正で一元化出来る。
この後、どうするんだ？誰かやってみてくれ。
>>799
ヒント：ここの住人は茶番劇に興味が無くなった。
ヒント：ここの住人は茶番劇に興味が無くなった。
801 ： ◆4gjdpsjXG2 ：2008/03/18(火) 20:27:03
>>788
>何で商品が、自身を入れるハコに依存してんだ？
「ハコに依存」している、なにが依存しているんだ？委譲とか知らないのか？
>何で商品が、「次へ」チェインするの？
振る舞いに関するパターンが何の為に有るのか知らんのか？
上で「依存」とか書いといて．．．
>たかだか１個の商品を、
> 「段ボールに入る」ことを前提として
> 「線形アクセスされる」ことを前提として
>設計するなよ。
「たかだか１個の商品」がオブジェクトなんだが
お前はどの方法で設計しようしているんだ．．．
お前は、この中でもトップクラスの．．．だな、びっくりするわ
>>789
よく読め
>俺の設計がクラス指向だと言うならそうかもしれないが、クラス指向=オブジェクト指向じゃないのか？
に対する回答だ、分析・設計とは言っていない
>>794
>問題は処理速度だけか。処理速度はどうする？インデックスみたいな物でも作るか？
最初から実装を考えるな、最初は概念や論理的に正しい分析・設計のみ考えて
その結果レスポンスが出ない時に、概念を最小限変更したり、代案を考えるのが基本だ
>何で商品が、自身を入れるハコに依存してんだ？
「ハコに依存」している、なにが依存しているんだ？委譲とか知らないのか？
>何で商品が、「次へ」チェインするの？
振る舞いに関するパターンが何の為に有るのか知らんのか？
上で「依存」とか書いといて．．．
>たかだか１個の商品を、
> 「段ボールに入る」ことを前提として
> 「線形アクセスされる」ことを前提として
>設計するなよ。
「たかだか１個の商品」がオブジェクトなんだが
お前はどの方法で設計しようしているんだ．．．
お前は、この中でもトップクラスの．．．だな、びっくりするわ
>>789
よく読め
>俺の設計がクラス指向だと言うならそうかもしれないが、クラス指向=オブジェクト指向じゃないのか？
に対する回答だ、分析・設計とは言っていない
>>794
>問題は処理速度だけか。処理速度はどうする？インデックスみたいな物でも作るか？
最初から実装を考えるな、最初は概念や論理的に正しい分析・設計のみ考えて
その結果レスポンスが出ない時に、概念を最小限変更したり、代案を考えるのが基本だ
しかし、分析・設計とは離れるがオブジェクト指向で設計したシステムのレスポンス問題は
構造化(と言うかＤＢＭＳだが)よりやっかいになる事があるのも事実だしな
オブジェクト指向でソートは、基本的にアプリで行なう（SELECT文でソートは行なわない）
例えばC/S・Webだと、ＤＢサーバからデータ取り出してアプリ(ビジネス)サーバで
ソートなどデータ操作を行なうのがオブジェクト指向の基本だが
このやり方でも普通は大丈夫だ（逆にＲＤＢより早い場合もある）
だが、大規模なシステムやシビヤなシステムではACIDが心配になってくる
ＯＯＤＢとかを使えば大丈夫なのかもしれないが、あまり良い製品が．．．
長くなるから、また別の機会に書かせてもらうm(__)m
構造化(と言うかＤＢＭＳだが)よりやっかいになる事があるのも事実だしな
オブジェクト指向でソートは、基本的にアプリで行なう（SELECT文でソートは行なわない）
例えばC/S・Webだと、ＤＢサーバからデータ取り出してアプリ(ビジネス)サーバで
ソートなどデータ操作を行なうのがオブジェクト指向の基本だが
このやり方でも普通は大丈夫だ（逆にＲＤＢより早い場合もある）
だが、大規模なシステムやシビヤなシステムではACIDが心配になってくる
ＯＯＤＢとかを使えば大丈夫なのかもしれないが、あまり良い製品が．．．
長くなるから、また別の機会に書かせてもらうm(__)m
>>798
知らん分野に手を伸ばす前に、おじゃばの良く知ってる在庫管理で良いからユースケース記述書け。
知らん分野に手を伸ばす前に、おじゃばの良く知ってる在庫管理で良いからユースケース記述書け。
805 ： ◆YMbkZcHjxU ：2008/03/18(火) 21:27:56
おじゃばは２ちゃんねらとはレベルが段違い
>>804
今は分析・設計をやってるんだが
なぜユースケースを強要するんだ？、ユースケースは要件/機能定義だろう
どんな分析・設計方法を前提にしているか分からんが、多分
それだけユースケースにこだわるには、ユースケースドリブン開発か？
それでも、分析・設計時にユースケースを元にクラスを作るぐらいだろう？
分かるように説明してくれ
今は分析・設計をやってるんだが
なぜユースケースを強要するんだ？、ユースケースは要件/機能定義だろう
どんな分析・設計方法を前提にしているか分からんが、多分
それだけユースケースにこだわるには、ユースケースドリブン開発か？
それでも、分析・設計時にユースケースを元にクラスを作るぐらいだろう？
分かるように説明してくれ
>>806
何作るか分からんのに分析も設計もあったもんじゃないからだ
何作るか分からんのに分析も設計もあったもんじゃないからだ
だから、俺が簡単に要件定義した
>>742
>要件は
>１．会員登録
>２．ビデオ貸し出し
>３．ビデオ返却
>４．ビデオの移動・格納・消去
>５．棚卸
で、やっているんじゃないのか
もっと詳しく要件定義しろと言うことか？
ここ（スレ）なら、これぐらいでいいだろう
>>742
>要件は
>１．会員登録
>２．ビデオ貸し出し
>３．ビデオ返却
>４．ビデオの移動・格納・消去
>５．棚卸
で、やっているんじゃないのか
もっと詳しく要件定義しろと言うことか？
ここ（スレ）なら、これぐらいでいいだろう
>>393のやり方がどんな問題を解決していて、他と比べて何が優れているのかさっぱり分からない。
なんか、デザパタの使いどころを理解しないで、問題解決のためじゃなくデザパタを使うことが目
的になってないか？ この設計で、商品の数を数える以外に何が便利になるのか、もちっと有難み
の分かるような例を教えてくれよ。
つぅか、やっぱり実装ありきじゃなくて、問題の整理からすべきだよなぁ。
なんか、デザパタの使いどころを理解しないで、問題解決のためじゃなくデザパタを使うことが目
的になってないか？ この設計で、商品の数を数える以外に何が便利になるのか、もちっと有難み
の分かるような例を教えてくれよ。
つぅか、やっぱり実装ありきじゃなくて、問題の整理からすべきだよなぁ。
とりあえず、本題のレンタルビデオを書いとく
まず基本のクラスは
・会員クラス
・ビデオ棚クラス
・ビデオクラス
あと関連クラスで
・レンタルクラス
から俺は始める
あと、棚卸だが
>>779
>レンタルビデオ屋は棚卸しないのかな、年中無休なんでいつやってるか知らないが
>>793
>棚卸し？入荷、移動、廃棄に分解してみたが、問題あるか？
棚卸を疑問に思っているみたいだが、税制(会計)上やる必要があり
しかも年に数回しかやらない例外ケースだから
客からの機能要件に出てこない場合もあり、難しい
前にも書いたが
>>488
>後は棚卸をどう表現するとかが設計者のセンスが出るところだ。
設計者にこだわってもらいたい理由が分かって貰えたかな？
まず基本のクラスは
・会員クラス
・ビデオ棚クラス
・ビデオクラス
あと関連クラスで
・レンタルクラス
から俺は始める
あと、棚卸だが
>>779
>レンタルビデオ屋は棚卸しないのかな、年中無休なんでいつやってるか知らないが
>>793
>棚卸し？入荷、移動、廃棄に分解してみたが、問題あるか？
棚卸を疑問に思っているみたいだが、税制(会計)上やる必要があり
しかも年に数回しかやらない例外ケースだから
客からの機能要件に出てこない場合もあり、難しい
前にも書いたが
>>488
>後は棚卸をどう表現するとかが設計者のセンスが出るところだ。
設計者にこだわってもらいたい理由が分かって貰えたかな？
泊数毎の値段設定とか、抱合せ価格とか、新作→旧作の切替えとか、ジャンル分けとか、延滞請求とか、ポイント管理とか、属性（出演俳優、監督）設定とか、売れ筋集計とか、仕入予測とか、無視ですかそうですか。
>>808
こういうスレだからもっとちゃんと要件定義せにゃならんと思うんだが。
>>808でスレ見てる人が同じシステムを思い浮かべると思うか？
個々人が思い浮かべるシステムが違うのに、
それについて話し合っても、話が収束するわけ無いじゃん。
さておいても、OOAなりでエンティティの抽出するのに
ユースケース記述書かないなんて、このスレの住人にゃハードル高すぎだろ。
こういうスレだからもっとちゃんと要件定義せにゃならんと思うんだが。
>>808でスレ見てる人が同じシステムを思い浮かべると思うか？
個々人が思い浮かべるシステムが違うのに、
それについて話し合っても、話が収束するわけ無いじゃん。
さておいても、OOAなりでエンティティの抽出するのに
ユースケース記述書かないなんて、このスレの住人にゃハードル高すぎだろ。
レンタルビデオ屋として、1店舗に閉じているとして
・会員クラス
・ビデオクラス {貸し出し中/貸し出し可能}
・レンタルクラス {誰がどのビデオを借りているか}
で始めようぜ。
まず、会員とビデオとレンタルを一意に決めるためのIDを持つ必要がある。
・会員クラス
・ビデオクラス {貸し出し中/貸し出し可能}
・レンタルクラス {誰がどのビデオを借りているか}
で始めようぜ。
まず、会員とビデオとレンタルを一意に決めるためのIDを持つ必要がある。
おじゃば＝>393なのを知らないフリするのはいつまでですか？
>>811
オブジェクト指向設計分かってるか？
「泊数毎の値段設定」「抱合せ価格」「延滞請求」・・・レンタルクラスのフィールド
「ジャンル分け」「属性（出演俳優、監督）設定」・・・ビデオクラスのフィールド
「新作→旧作の切替え」「売れ筋集計」・・・ビデオクラスのメソッド（売れ筋ってうるのか？）
「ポイント管理」・・・会員クラスのフィールド
「仕入予測」これは、今回要件にないから作らなかったが作るとすれば「仕入先クラス」
こんな感じでクラスに入るが、どうだ
何故クラスから抽出しない？フィールドはまだしもメソッドを先に抽出したらＰＯＡだろうが
>>812
どうせ「おじゃばさま」しか答えんだろう、お前らはそれを批判するだけだ
だったら「個々人が思い浮かべる」もないだろう
それに、勘違いしている詳細に要件定義すればかえって
「個々人が思い浮かべるシステムが違う」になる
逆に単純に書いて「汎化」すれば詳細部分は違っても
共通認識は持ちやすい、これもオブジェクト指向の基本の一つだと思うが
オブジェクト指向設計分かってるか？
「泊数毎の値段設定」「抱合せ価格」「延滞請求」・・・レンタルクラスのフィールド
「ジャンル分け」「属性（出演俳優、監督）設定」・・・ビデオクラスのフィールド
「新作→旧作の切替え」「売れ筋集計」・・・ビデオクラスのメソッド（売れ筋ってうるのか？）
「ポイント管理」・・・会員クラスのフィールド
「仕入予測」これは、今回要件にないから作らなかったが作るとすれば「仕入先クラス」
こんな感じでクラスに入るが、どうだ
何故クラスから抽出しない？フィールドはまだしもメソッドを先に抽出したらＰＯＡだろうが
>>812
どうせ「おじゃばさま」しか答えんだろう、お前らはそれを批判するだけだ
だったら「個々人が思い浮かべる」もないだろう
それに、勘違いしている詳細に要件定義すればかえって
「個々人が思い浮かべるシステムが違う」になる
逆に単純に書いて「汎化」すれば詳細部分は違っても
共通認識は持ちやすい、これもオブジェクト指向の基本の一つだと思うが
これがCahin of Responsibility で出来上がっていくのか。大変そうだな。
ま、お手並拝見。
ま、お手並拝見。
あれ？
ビデオがシステム起動時にインスタンス化されているとして、会員とレンタルはいつ誰がインスタンス化するんだ？
ビデオがシステム起動時にインスタンス化されているとして、会員とレンタルはいつ誰がインスタンス化するんだ？
まぁ会員もシステム起動時でいいかw
レンタルはどうしよう？ 何かが必要だな...とりあえず
・貸し出し/返却管理GUI
とか定義しておくか
レンタルはどうしよう？ 何かが必要だな...とりあえず
・貸し出し/返却管理GUI
とか定義しておくか
>>393
前提を脳内完結してクラスとか言いだすから、要求を挙げろって言われてんのいい加減理解しろよ
あんたおじゃばにつっこみを入れておきながら、同じことやってんじゃん
聞かれたから回答してるだけ、とか言っても支離滅裂具合はおじゃばと何も変わらん
最低限これぐらいは決めろ
何も決まらない会議を見てるようだぞ
【業務要件について】
・客が借りに来るのか、それとも店員が貸しに行くのか 返却も同様（宅配かどうか）
・金銭の授受は発生するのかしないのか（図書館かどうか）
【設計方針について】
・どこから手をつけるのか また優先順位は
・実装時の影響を考慮するのかしないのか
前提を脳内完結してクラスとか言いだすから、要求を挙げろって言われてんのいい加減理解しろよ
あんたおじゃばにつっこみを入れておきながら、同じことやってんじゃん
聞かれたから回答してるだけ、とか言っても支離滅裂具合はおじゃばと何も変わらん
最低限これぐらいは決めろ
何も決まらない会議を見てるようだぞ
【業務要件について】
・客が借りに来るのか、それとも店員が貸しに行くのか 返却も同様（宅配かどうか）
・金銭の授受は発生するのかしないのか（図書館かどうか）
【設計方針について】
・どこから手をつけるのか また優先順位は
・実装時の影響を考慮するのかしないのか
>>816
> それに、勘違いしている詳細に要件定義すればかえって
> 「個々人が思い浮かべるシステムが違う」になる
> 逆に単純に書いて「汎化」すれば詳細部分は違っても
> 共通認識は持ちやすい、これもオブジェクト指向の基本の一つだと思うが
完全に意味不明
在庫管理システムの中でもレンタルビデオに特化してるのに
なぜ汎化の話が出てくるんだよ
> それに、勘違いしている詳細に要件定義すればかえって
> 「個々人が思い浮かべるシステムが違う」になる
> 逆に単純に書いて「汎化」すれば詳細部分は違っても
> 共通認識は持ちやすい、これもオブジェクト指向の基本の一つだと思うが
完全に意味不明
在庫管理システムの中でもレンタルビデオに特化してるのに
なぜ汎化の話が出てくるんだよ
オブジェクト指向自演分かってるか？
長文になると口調が同じになる つっこまれると全部取り込もうとする
いきなり俺俺用語を使う 自分が言うことを本題にしたがる
詳細な設計？をしたがるわりに何がしたいのかが全然分からない
脳内で敵を特定しようとする 下手な自演の基本だと思うが どうだ
長文になると口調が同じになる つっこまれると全部取り込もうとする
いきなり俺俺用語を使う 自分が言うことを本題にしたがる
詳細な設計？をしたがるわりに何がしたいのかが全然分からない
脳内で敵を特定しようとする 下手な自演の基本だと思うが どうだ
あ、あと「コテハンだけは譲れない」が抜けてた。すまん。
>>813
>まず、会員とビデオとレンタルを一意に決めるためのIDを持つ必要がある。
なぜ、この段階でIDを持つ必要がある？オブジェクト自身が一意だろう
IDを考えるのはRDBの実装考えてとか、人間が管理しやすいようにとか
もっと実装に近い設計段階だ
>>815,820
>始めようぜって、クラス名決める前に、まず要件決めろって。
ここで話してるのは分析・設計の話だから要件定義は誰が決めても良いよ、だからお前が決めて良いよ
俺には偉そうに要件定義しろと指図される覚えはないし
>>818
>あれ？
>ビデオがシステム起動時にインスタンス化されているとして、会員とレンタルはいつ誰がインスタンス化するんだ？
まだ早いだろう
>>819
>まぁ会員もシステム起動時でいいかw
最初から全会員作るのか？リソースは？
必要になった時に生成して、Flyweightパターンでプールしとけば良いとおもうが
しかし、まだその設計は早いだろう
>>821
>完全に意味不明
>在庫管理システムの中でもレンタルビデオに特化してるのに
>なぜ汎化の話が出てくるんだよ
あぁ～？、お前はすごいな．．．「汎化」の意味しっているのか？
「汎化」は別にオブジェクト指向だけの用語じゃないんだけどな
脳科学でも認識の用語で使うけどな
説明は今日は晩いから又にする
>まず、会員とビデオとレンタルを一意に決めるためのIDを持つ必要がある。
なぜ、この段階でIDを持つ必要がある？オブジェクト自身が一意だろう
IDを考えるのはRDBの実装考えてとか、人間が管理しやすいようにとか
もっと実装に近い設計段階だ
>>815,820
>始めようぜって、クラス名決める前に、まず要件決めろって。
ここで話してるのは分析・設計の話だから要件定義は誰が決めても良いよ、だからお前が決めて良いよ
俺には偉そうに要件定義しろと指図される覚えはないし
>>818
>あれ？
>ビデオがシステム起動時にインスタンス化されているとして、会員とレンタルはいつ誰がインスタンス化するんだ？
まだ早いだろう
>>819
>まぁ会員もシステム起動時でいいかw
最初から全会員作るのか？リソースは？
必要になった時に生成して、Flyweightパターンでプールしとけば良いとおもうが
しかし、まだその設計は早いだろう
>>821
>完全に意味不明
>在庫管理システムの中でもレンタルビデオに特化してるのに
>なぜ汎化の話が出てくるんだよ
あぁ～？、お前はすごいな．．．「汎化」の意味しっているのか？
「汎化」は別にオブジェクト指向だけの用語じゃないんだけどな
脳科学でも認識の用語で使うけどな
説明は今日は晩いから又にする
>>393
>「ハコに依存」している、なにが依存しているんだ？委譲とか知らないのか？
アホか。
お前784で『俺は「A段ボール」に入っているから１、次へ』って書いただろう。
委譲するならすりゃいいが、それでも商品オブジェクトが
『俺は「A段ボール」に入っている』と自己判断できたり、
『俺は「B段ボール」に入っていない』ということを知ったり、
それらを区別できるってことは、既に依存してるってことなんだよ。
>>何で商品が、「次へ」チェインするの？
>振る舞いに関するパターンが何の為に有るのか知らんのか？
>上で「依存」とか書いといて．．．
俺の質問は『何で「次へ」 しか チェインしないって決めてんだ？』だよこのタコ。
誰も『チェインってなぁ～に？』なんて聞いてないっての。
「前へ」はチェインしないのか？親子関係や入れ子関係にはなり得ないのか？
どういう『管理のされ方』が妥当かは、商品を扱うシーンで違ってくる。
だからどういう『管理のされ方』をするのか商品オブジェクトが知っているのはおかしいだろうと指摘したんだ。
>「たかだか１個の商品」がオブジェクトなんだが
「オブジェクトだから」能動的に何でもできるのが正しいとでも？
>お前はどの方法で設計しようしているんだ．．．
『どの方法』って・・・まさか『○○パターンで設計します』と言って欲しいのか？
パターンに傾倒しすぎなんだよ。デザパタが何のためにあるのかを考えてみろ。
お前知識は広そうだが理解が浅すぎるんじゃないのか。
そうじゃなければ経験が無さ過ぎるのか。１年目のPGか？
>「ハコに依存」している、なにが依存しているんだ？委譲とか知らないのか？
アホか。
お前784で『俺は「A段ボール」に入っているから１、次へ』って書いただろう。
委譲するならすりゃいいが、それでも商品オブジェクトが
『俺は「A段ボール」に入っている』と自己判断できたり、
『俺は「B段ボール」に入っていない』ということを知ったり、
それらを区別できるってことは、既に依存してるってことなんだよ。
>>何で商品が、「次へ」チェインするの？
>振る舞いに関するパターンが何の為に有るのか知らんのか？
>上で「依存」とか書いといて．．．
俺の質問は『何で「次へ」 しか チェインしないって決めてんだ？』だよこのタコ。
誰も『チェインってなぁ～に？』なんて聞いてないっての。
「前へ」はチェインしないのか？親子関係や入れ子関係にはなり得ないのか？
どういう『管理のされ方』が妥当かは、商品を扱うシーンで違ってくる。
だからどういう『管理のされ方』をするのか商品オブジェクトが知っているのはおかしいだろうと指摘したんだ。
>「たかだか１個の商品」がオブジェクトなんだが
「オブジェクトだから」能動的に何でもできるのが正しいとでも？
>お前はどの方法で設計しようしているんだ．．．
『どの方法』って・・・まさか『○○パターンで設計します』と言って欲しいのか？
パターンに傾倒しすぎなんだよ。デザパタが何のためにあるのかを考えてみろ。
お前知識は広そうだが理解が浅すぎるんじゃないのか。
そうじゃなければ経験が無さ過ぎるのか。１年目のPGか？
要件を決める前に妄想でクラス名を決めるのがクラス指向w
>824
おじゃば
地が出てるぞ
気をつけろ
おじゃば
地が出てるぞ
気をつけろ
828 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/19(水) 09:51:35
>>803
リソースとレスポンスの問題は課題として残ると言う事かな。
確かに設計と実装は切り離したいが、この問題が解決されるまでは仕事には使えないな。
>>804
すでに書いた。733とか。
>810
棚卸しって在庫数の確認の事か。確かに万引きされたら数が合わなくなるな。
どうやって確認するのか謎だが、紙に出力された一覧で目でチェックするか、残っている商品を
全部バーコードに読ませるかだな。非接触型のICタグなら後者もありかもしれんが、
やっぱり普通は前者かな。とりあえず、在庫数一覧のプリント出力でいいと思う。
リソースとレスポンスの問題は課題として残ると言う事かな。
確かに設計と実装は切り離したいが、この問題が解決されるまでは仕事には使えないな。
>>804
すでに書いた。733とか。
>810
棚卸しって在庫数の確認の事か。確かに万引きされたら数が合わなくなるな。
どうやって確認するのか謎だが、紙に出力された一覧で目でチェックするか、残っている商品を
全部バーコードに読ませるかだな。非接触型のICタグなら後者もありかもしれんが、
やっぱり普通は前者かな。とりあえず、在庫数一覧のプリント出力でいいと思う。
どうみてもただのマスタメンテです本当に(ry
どうでもいい素朴な疑問なんだが、
OOで設計した結果マスタメンテが出来上がったらなんか問題あんの？
OOで設計した結果マスタメンテが出来上がったらなんか問題あんの？
831 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/19(水) 20:40:58
>>811
811の指摘を考慮すると、ユースケースは
「貸出し」「返却」「入荷」「廃棄」「会員登録」「会員修正」
に加えて、
「価格表変更」「商品情報変更」「延滞督促」「ポイント管理」「ログ出力」
になるかな。
「商品情報変更」で旧作新作切り替えと行う。
「延滞督促」は、延滞者の一覧と電話番号を出力する。
「ポイント管理」は良く分からない。借りるとポイントが貯まって、現金の代わりに使えるとかかな。
「ログ管理」は貸出し情報のログを出力して、借り筋集計とか、仕入れ予測は別システムで行うのがいいだろう。
結構複雑になってきたな。
>>820
俺が出した課題ではないが、多分以下の通りで問題ないだろう。
・客が借りに来て、金銭授受が発生する。（ツタヤ店舗のイメージ）
・どこから手をつけるかは、自由だが、基本機能優先。
・動かないと意味がないので、最低限の実装時の影響は考慮する。
811の指摘を考慮すると、ユースケースは
「貸出し」「返却」「入荷」「廃棄」「会員登録」「会員修正」
に加えて、
「価格表変更」「商品情報変更」「延滞督促」「ポイント管理」「ログ出力」
になるかな。
「商品情報変更」で旧作新作切り替えと行う。
「延滞督促」は、延滞者の一覧と電話番号を出力する。
「ポイント管理」は良く分からない。借りるとポイントが貯まって、現金の代わりに使えるとかかな。
「ログ管理」は貸出し情報のログを出力して、借り筋集計とか、仕入れ予測は別システムで行うのがいいだろう。
結構複雑になってきたな。
>>820
俺が出した課題ではないが、多分以下の通りで問題ないだろう。
・客が借りに来て、金銭授受が発生する。（ツタヤ店舗のイメージ）
・どこから手をつけるかは、自由だが、基本機能優先。
・動かないと意味がないので、最低限の実装時の影響は考慮する。
なんだそりゃ。
そんなもん要件に無いんだから無視だろ。
おじゃばは何がしたいんだ？
そんなもん要件に無いんだから無視だろ。
おじゃばは何がしたいんだ？
833 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/19(水) 21:00:53
>>824
ツタヤのような巨大店舗のシステムを考えるとすると、商品や会員の情報をメモリに持つのはダメだろう。
あと、誰かが貸出しの受付を行っている最中は、他の人が借りられないとか、業務が止まるのも問題外だろう。
いくら実装を意識しないとは言っても、そのあたりはクリアする必要があると思う。
>>825
トップダウン男の現在の設計ではリソースとレスポンスに重大な問題がある。
あの在庫管理システムは、何でも入る巨大な袋に、1本の紐で繋いで、商品をぶち込むイメージだろう。
今のままでは、商品を確認する場合は、紐を辿って全商品を確認するしかない。
人間がやったら無茶だが、コンピューターの強力な処理能力で押し切るのかもしれない。
とりあえず、後で説明すると言っているから、説明を聞かないと何とも言えないな。
ツタヤのような巨大店舗のシステムを考えるとすると、商品や会員の情報をメモリに持つのはダメだろう。
あと、誰かが貸出しの受付を行っている最中は、他の人が借りられないとか、業務が止まるのも問題外だろう。
いくら実装を意識しないとは言っても、そのあたりはクリアする必要があると思う。
>>825
トップダウン男の現在の設計ではリソースとレスポンスに重大な問題がある。
あの在庫管理システムは、何でも入る巨大な袋に、1本の紐で繋いで、商品をぶち込むイメージだろう。
今のままでは、商品を確認する場合は、紐を辿って全商品を確認するしかない。
人間がやったら無茶だが、コンピューターの強力な処理能力で押し切るのかもしれない。
とりあえず、後で説明すると言っているから、説明を聞かないと何とも言えないな。
834 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/19(水) 21:07:04
>>832
「価格表変更」「商品情報変更」「延滞督促」は無視出来ないだろう？業務にならない。
「ポイント管理」「ログ出力」は必ず要望が出る機能だな。
今回は入れなくても、後で必ず必要になると思う。
一応、リアルを考えてビデオレンタルを出したと思うので、最低でも業務に耐え得るシステムに
したほうがいいと思う。
「価格表変更」「商品情報変更」「延滞督促」は無視出来ないだろう？業務にならない。
「ポイント管理」「ログ出力」は必ず要望が出る機能だな。
今回は入れなくても、後で必ず必要になると思う。
一応、リアルを考えてビデオレンタルを出したと思うので、最低でも業務に耐え得るシステムに
したほうがいいと思う。
C言語しか勉強してなかったときはあー構造化プログラミングって合理敵だなーと思ってて
オブジェクト指向はカタカナの専門用語多すぎるしパラダイムシフトとか言ってるし動物の喩えは胡散臭いしで
すごい異物の感じがして食わず嫌いだったけど、概念じゃなくてちゃんとプログラミングとして勉強したら
なんだこれ生まれるべくして生まれた存在じゃん、みたいな、割とすんなり理解できた
と素人が空気読まずに上がってるスレにカキコ
オブジェクト指向はカタカナの専門用語多すぎるしパラダイムシフトとか言ってるし動物の喩えは胡散臭いしで
すごい異物の感じがして食わず嫌いだったけど、概念じゃなくてちゃんとプログラミングとして勉強したら
なんだこれ生まれるべくして生まれた存在じゃん、みたいな、割とすんなり理解できた
と素人が空気読まずに上がってるスレにカキコ
>>834
＞一応、リアルを考えてビデオレンタルを出したと思うので、最低でも業務に耐え得るシステムに
＞したほうがいいと思う。
・・・
ならもっと初歩的な要件を考えろよ。
そもそもお前の脳内顧客の抱えている問題点は何だ？
顧客はそのシステムを使うことで何を解決したいんだ？
おじゃばの言う「業務に耐え得る」って何だよ。
唐突に
>要件は
>１．会員登録
>２．ビデオ貸し出し
>３．ry
って出てきたんだから
単に、システムにそれなりの具体性と複雑度が欲しかっただけじゃないのかよ？
＞一応、リアルを考えてビデオレンタルを出したと思うので、最低でも業務に耐え得るシステムに
＞したほうがいいと思う。
・・・
ならもっと初歩的な要件を考えろよ。
そもそもお前の脳内顧客の抱えている問題点は何だ？
顧客はそのシステムを使うことで何を解決したいんだ？
おじゃばの言う「業務に耐え得る」って何だよ。
唐突に
>要件は
>１．会員登録
>２．ビデオ貸し出し
>３．ry
って出てきたんだから
単に、システムにそれなりの具体性と複雑度が欲しかっただけじゃないのかよ？
こんなもん、ぐだぐだやってる間に、MVCとORMでちゃっちゃって作っちゃった方が良さそうだな。
昨日の宿題から行く
>>825
こいつだけは、本当にアホだ、この中でだれよりもオブジェクト指向を知らん奴かな？
>アホか。
>お前784で『俺は「A段ボール」に入っているから１、次へ』って書いただろう。
>委譲するならすりゃいいが、それでも商品オブジェクトが
>『俺は「A段ボール」に入っている』と自己判断できたり、
>『俺は「B段ボール」に入っていない』ということを知ったり、
>それらを区別できるってことは、既に依存してるってことなんだよ。
お前本当に委譲をしっているのか、「自己判断できたり」．．．
自己判断しないために、委譲するんだろう、ほんと呆れるしかないな～
>俺の質問は『何で「次へ」 しか チェインしないって決めてんだ？』だよこのタコ。
>誰も『チェインってなぁ～に？』なんて聞いてないっての。
>「前へ」はチェインしないのか？親子関係や入れ子関係にはなり得ないのか？
>どういう『管理のされ方』が妥当かは、商品を扱うシーンで違ってくる。
>だからどういう『管理のされ方』をするのか商品オブジェクトが知っているのはおかしいだろうと指摘したんだ。
だから、「振る舞いに関するパターンが何の為に有るのか知らんのか？」と聞いている
別に「Chain of Responsibilityパターンが何の為に有るか知らんのか」とは聞いていない
お前には意味がわらんだろうが、あと「チェイン」はなんだw
>「オブジェクトだから」能動的に何でもできるのが正しいとでも？
正しいかどうかは分からんが、"オブジェクト"指向で設計するとはそうゆう事だ
お前はもう引っ込めオブジェクト指向を知らなすぎる
>>825
こいつだけは、本当にアホだ、この中でだれよりもオブジェクト指向を知らん奴かな？
>アホか。
>お前784で『俺は「A段ボール」に入っているから１、次へ』って書いただろう。
>委譲するならすりゃいいが、それでも商品オブジェクトが
>『俺は「A段ボール」に入っている』と自己判断できたり、
>『俺は「B段ボール」に入っていない』ということを知ったり、
>それらを区別できるってことは、既に依存してるってことなんだよ。
お前本当に委譲をしっているのか、「自己判断できたり」．．．
自己判断しないために、委譲するんだろう、ほんと呆れるしかないな～
>俺の質問は『何で「次へ」 しか チェインしないって決めてんだ？』だよこのタコ。
>誰も『チェインってなぁ～に？』なんて聞いてないっての。
>「前へ」はチェインしないのか？親子関係や入れ子関係にはなり得ないのか？
>どういう『管理のされ方』が妥当かは、商品を扱うシーンで違ってくる。
>だからどういう『管理のされ方』をするのか商品オブジェクトが知っているのはおかしいだろうと指摘したんだ。
だから、「振る舞いに関するパターンが何の為に有るのか知らんのか？」と聞いている
別に「Chain of Responsibilityパターンが何の為に有るか知らんのか」とは聞いていない
お前には意味がわらんだろうが、あと「チェイン」はなんだw
>「オブジェクトだから」能動的に何でもできるのが正しいとでも？
正しいかどうかは分からんが、"オブジェクト"指向で設計するとはそうゆう事だ
お前はもう引っ込めオブジェクト指向を知らなすぎる
後は、明日にする今日は寝る
825 だが。
>>838
では、『俺は「A段ボール」に入っているから・・・』と識別するのは(具体的な例を挙げるなら)どのオブジェクトだ？
>「振る舞いに関するパターンが何の為に有るのか知らんのか？」と聞いている
振る舞いの設計方法は無数にある。
しかしその中には余計な負荷がかかったり、拡張性が大きく損なわれるなど、デメリットを抱えた設計も存在する。
当然ながら、カプセル化を保ったまま柔軟で堅牢なシステムを実現できるにこしたことは無い。
それを考えてゆくと、「多くの場面で有用」な「オブジェクトの連携方法」が見出される。
そうした先人の知恵を知ることで、設計を含め開発作業に関わる人達の意識共有が促進される。
その中にChain Of Responsibilityのように名前がつけられたものも含まれる。
さて、お前の設計は拡張性と堅牢性、さらにおじゃばが言うように処理効率に大きな欠陥があると思うが、どうだ？
オブジェクト指向を利用するメリットとして、カプセル化による安全確保と、高い拡張可能性、そしてその両立がある。
お前の設計はクライアントからの(予想され得る)仕様変更で、一から設計をやりなおさなくちゃいけなくなるんじゃないのか。
そんなこと無いかい？消えるとかいいながら 839 まで書き続けた 393 よ。起きてるんだろ？
>>838
では、『俺は「A段ボール」に入っているから・・・』と識別するのは(具体的な例を挙げるなら)どのオブジェクトだ？
>「振る舞いに関するパターンが何の為に有るのか知らんのか？」と聞いている
振る舞いの設計方法は無数にある。
しかしその中には余計な負荷がかかったり、拡張性が大きく損なわれるなど、デメリットを抱えた設計も存在する。
当然ながら、カプセル化を保ったまま柔軟で堅牢なシステムを実現できるにこしたことは無い。
それを考えてゆくと、「多くの場面で有用」な「オブジェクトの連携方法」が見出される。
そうした先人の知恵を知ることで、設計を含め開発作業に関わる人達の意識共有が促進される。
その中にChain Of Responsibilityのように名前がつけられたものも含まれる。
さて、お前の設計は拡張性と堅牢性、さらにおじゃばが言うように処理効率に大きな欠陥があると思うが、どうだ？
オブジェクト指向を利用するメリットとして、カプセル化による安全確保と、高い拡張可能性、そしてその両立がある。
お前の設計はクライアントからの(予想され得る)仕様変更で、一から設計をやりなおさなくちゃいけなくなるんじゃないのか。
そんなこと無いかい？消えるとかいいながら 839 まで書き続けた 393 よ。起きてるんだろ？
だんだん（表面上は）人が増えて盛り上がってきたねー（棒
似てる人ってよのなかいるもんだなぁ、びっくりしたぁ（棒
と思うが、どうだ？
似てる人ってよのなかいるもんだなぁ、びっくりしたぁ（棒
と思うが、どうだ？
商品の数だけ責任者が増えるとか狂気の沙汰だなｗ
リストでいいじゃん。
リストでいいじゃん。
393はどうしてこうも喧嘩腰なのかねぇ。ま、そんなとはいいが、
Chain of Responsibility はGUIのイベントメッセージの伝達とか、フィルタリングでよく使われるパターンだな。
だけど、今回のケース（商品が何万もある？）では、対象となるインスタンス（商品）が全てメモリに存在しないと性能的に
厳しいだろうし、マルチユーザの環境だと、排他と整合性も考慮しないといけない。
リクエストがある度にDBアクセス（DB使わないんだっけ？）を発生させるぐらいだったら、SQL文発行してやっちゃった方が
いいだろうし。
ORMとか使ってキャッシングの機能を活用するっていう手もあるかもしれんが、それにも限界がありそう。別の手段をとるに
しても設計のための設計を強いられることになって、保守性の向上という面では本末転倒になりそう。
と言う感じで、デザパタのメリットばかりに目を向けて安易に使うんじゃなくて、デメリットもよく勘案した上で、採用す
るかどうか判断した方がいいと思うが。
...あ、俺も393に怒られるかな。ごめんよ。
Chain of Responsibility はGUIのイベントメッセージの伝達とか、フィルタリングでよく使われるパターンだな。
だけど、今回のケース（商品が何万もある？）では、対象となるインスタンス（商品）が全てメモリに存在しないと性能的に
厳しいだろうし、マルチユーザの環境だと、排他と整合性も考慮しないといけない。
リクエストがある度にDBアクセス（DB使わないんだっけ？）を発生させるぐらいだったら、SQL文発行してやっちゃった方が
いいだろうし。
ORMとか使ってキャッシングの機能を活用するっていう手もあるかもしれんが、それにも限界がありそう。別の手段をとるに
しても設計のための設計を強いられることになって、保守性の向上という面では本末転倒になりそう。
と言う感じで、デザパタのメリットばかりに目を向けて安易に使うんじゃなくて、デメリットもよく勘案した上で、採用す
るかどうか判断した方がいいと思うが。
...あ、俺も393に怒られるかな。ごめんよ。
みんな、議論するほうが楽しくて、作るほうはどうでもいいんだねｗ
ぱやっぱり切実感がないとものは作れないな
ぱやっぱり切実感がないとものは作れないな
まぁぶっちゃけ業務レベルでマジメにやるとメンドクサイからな。
>>840
また無知な事ばかり書いているな、付き合いきれんから無視だなｗ
ここで、俺あての書込みを個別に対応するのも何だから整理して回答する
大きく分けて、この二つか
・要件定義
・レスポンス／リソース
・要求定義
要求定義の説明の前に>>821
>完全に意味不明
>在庫管理システムの中でもレンタルビデオに特化してるのに
>なぜ汎化の話が出てくるんだよ
の「汎化」を説明しとく
「汎化」とは、事象などを一般化・抽象化・帰納する事を言う
例を上げると
・ビデオを選ぶ
・カウンターに持っていく
・会員証とビデオを渡す
・お金を渡して、会員証とビデオを受け取る
と手続きで詳細書けば分かりやすいが
ネット・宅配でビデオを借りる人間には
上の手続きでは、理解出来ないかも知れない
これを「汎化」した『ビデオ貸し出し』と言えば
詳細部分は違っても一般的な業務の共通認識は出来る
また無知な事ばかり書いているな、付き合いきれんから無視だなｗ
ここで、俺あての書込みを個別に対応するのも何だから整理して回答する
大きく分けて、この二つか
・要件定義
・レスポンス／リソース
・要求定義
要求定義の説明の前に>>821
>完全に意味不明
>在庫管理システムの中でもレンタルビデオに特化してるのに
>なぜ汎化の話が出てくるんだよ
の「汎化」を説明しとく
「汎化」とは、事象などを一般化・抽象化・帰納する事を言う
例を上げると
・ビデオを選ぶ
・カウンターに持っていく
・会員証とビデオを渡す
・お金を渡して、会員証とビデオを受け取る
と手続きで詳細書けば分かりやすいが
ネット・宅配でビデオを借りる人間には
上の手続きでは、理解出来ないかも知れない
これを「汎化」した『ビデオ貸し出し』と言えば
詳細部分は違っても一般的な業務の共通認識は出来る
では要件定義に入る、俺の提示した要件では不満みたいだな>>812,820
詳細に書けと言う事か？要件定義を書けと言ってる奴はどんな開発手法を元に
言っているのか分からんが（RUPあたりか？）
俺の要件定義は「目的」を明記することだ、逆に手段を明記しては駄目だ
その「目的」だけを考えて分析・(初期段階の)設計していかないといけない
例えば上の『ビデオ貸し出し』が店頭・ネット／宅配・ネット配信
（最近では数日後にデータが消えるDVDもあるらしいから、この場合返却がいらない）
と色々なレンタル手段が増えたとしても基本的な目的(クラス)は変わっていない
手段に合わせて、クラスを拡張するば良いだけの事だ
>>820
>【業務要件について】
>・客が借りに来るのか、それとも店員が貸しに行くのか 返却も同様（宅配かどうか）
>・金銭の授受は発生するのかしないのか（図書館かどうか）
本当にそれが、分析や初期段階の設計に必要だと思うのか？
なぜ最初から手段を考える？その手段を聞いて何をどう分析・設計に反映させる？
あと、要件定義をやった事のある人間なら分かると思うが、最初から
全ての要件を正確に提示してくれる客は少ない、社内SEでもほとんど出来ない
だから、最初は大枠だけ捕らえて分析・設計を行い、その時に気づいたり発生する
問題点をまた、客にヒヤリングして要件を提示してもらう
お前は、客が最初から全ての要件を提示しないと客に
「要求を挙げろって言われてんのいい加減理解しろよ」と言うのか？
詳細に書けと言う事か？要件定義を書けと言ってる奴はどんな開発手法を元に
言っているのか分からんが（RUPあたりか？）
俺の要件定義は「目的」を明記することだ、逆に手段を明記しては駄目だ
その「目的」だけを考えて分析・(初期段階の)設計していかないといけない
例えば上の『ビデオ貸し出し』が店頭・ネット／宅配・ネット配信
（最近では数日後にデータが消えるDVDもあるらしいから、この場合返却がいらない）
と色々なレンタル手段が増えたとしても基本的な目的(クラス)は変わっていない
手段に合わせて、クラスを拡張するば良いだけの事だ
>>820
>【業務要件について】
>・客が借りに来るのか、それとも店員が貸しに行くのか 返却も同様（宅配かどうか）
>・金銭の授受は発生するのかしないのか（図書館かどうか）
本当にそれが、分析や初期段階の設計に必要だと思うのか？
なぜ最初から手段を考える？その手段を聞いて何をどう分析・設計に反映させる？
あと、要件定義をやった事のある人間なら分かると思うが、最初から
全ての要件を正確に提示してくれる客は少ない、社内SEでもほとんど出来ない
だから、最初は大枠だけ捕らえて分析・設計を行い、その時に気づいたり発生する
問題点をまた、客にヒヤリングして要件を提示してもらう
お前は、客が最初から全ての要件を提示しないと客に
「要求を挙げろって言われてんのいい加減理解しろよ」と言うのか？
・レスポンス／リソース
最初に何度も書くが実装(レスポンス／リソース)は分析・初期段階の設計では考えるな
それに今回の１倉庫単位の倉庫管理、人が処理をするレンタルビデオぐらいでは問題ない
もちろん、レンタルビデオがネット配信を始めるとか、倉庫が宅配業者で、その宅配業者
のシステムだと分からんが（宅配業者だと一日に何百万件以上ものトランザクションが発生し
関連するレコードが複数作られ、日本でもトップクラスの情報量になる）
オブジェクト指向は構造は複雑だが、ロジックはシンプルだから思うほどレスポンスは悪くならない
ただ構造化など他の設計方法では、RDBが大量データに対するレスポンス／リソース問題を解決する
機構を提供してくれるがオブジェクト指向では、それを自前で作るかO/Rマッピングで
上手くRDBに任せるしかない、とにかく、これぐらいのシステムではレスポンス／リソースは大丈夫だ
最初に何度も書くが実装(レスポンス／リソース)は分析・初期段階の設計では考えるな
それに今回の１倉庫単位の倉庫管理、人が処理をするレンタルビデオぐらいでは問題ない
もちろん、レンタルビデオがネット配信を始めるとか、倉庫が宅配業者で、その宅配業者
のシステムだと分からんが（宅配業者だと一日に何百万件以上ものトランザクションが発生し
関連するレコードが複数作られ、日本でもトップクラスの情報量になる）
オブジェクト指向は構造は複雑だが、ロジックはシンプルだから思うほどレスポンスは悪くならない
ただ構造化など他の設計方法では、RDBが大量データに対するレスポンス／リソース問題を解決する
機構を提供してくれるがオブジェクト指向では、それを自前で作るかO/Rマッピングで
上手くRDBに任せるしかない、とにかく、これぐらいのシステムではレスポンス／リソースは大丈夫だ
対話能力が低い奴ほど長文だな
設計書もだらだらとクソ長いんだろうな
>>846-848
もういっそ、細かいこと無しで「ビデオレンタル」で汎化しちまえよ。
こんなとこで好き勝手書いてるようなシステムに、客のヒアリングも何もねぇだろ。
何とんちんかんなこと言ってるんだ。目的がクラスというのも良く分からんが、客の
ヒアリング云々言うなら、一番大事な事が抜けてるぞ。客の目的だよ。客は一体この
システムを導入することで何を達成したいんだ？ 売上げUPか？ コスト削減か？
業務効率の向上か？ 店舗アピールか？ 顧客満足度の向上か？ これら全部か？
ここが明確にされてないと、プロジェクトの成否も判定できないし、へたすっと使い
もんにならないシステムができあがることになるぞ。
Chain of Responsibility なんて手段を最初に持ち出しというてよく言うわw
ろくに分析も終わってない段階で、「これぐらいのシステムではレスポンス／リソース
は大丈夫だ」なんて自信がどこから湧いてくるのか不思議でしょうがない。
もういっそ、細かいこと無しで「ビデオレンタル」で汎化しちまえよ。
こんなとこで好き勝手書いてるようなシステムに、客のヒアリングも何もねぇだろ。
何とんちんかんなこと言ってるんだ。目的がクラスというのも良く分からんが、客の
ヒアリング云々言うなら、一番大事な事が抜けてるぞ。客の目的だよ。客は一体この
システムを導入することで何を達成したいんだ？ 売上げUPか？ コスト削減か？
業務効率の向上か？ 店舗アピールか？ 顧客満足度の向上か？ これら全部か？
ここが明確にされてないと、プロジェクトの成否も判定できないし、へたすっと使い
もんにならないシステムができあがることになるぞ。
Chain of Responsibility なんて手段を最初に持ち出しというてよく言うわw
ろくに分析も終わってない段階で、「これぐらいのシステムではレスポンス／リソース
は大丈夫だ」なんて自信がどこから湧いてくるのか不思議でしょうがない。
ヒント：おじゃばの茶番劇
853 ：仕様書無しさん：2008/03/20(木) 21:53:37
巨乳にマラソンは無理っ！
すまん誤爆したorz
>巨乳にマラソンは無理っ！
馬鹿な！
ゆれる胸と透けるＴシャツを否定するなんて無理だ！
馬鹿な！
ゆれる胸と透けるＴシャツを否定するなんて無理だ！
>>847
＞俺の要件定義は「目的」を明記することだ
中略
＞本当にそれが、分析や初期段階の設計に必要だと思うのか？
必要です。
393の「要件定義」がどうかは知らんけど、世間ではそうではない。
一般的には要件定義の目的の1つに「顧客が持っている曖昧な要望について
どのような機能であるかをはっきりさせる」ということがある。
例えば顧客が漠然と言っている「ビデオ貸し出し」とは
システムとしてはどういう機能なのか、というようなことをはっきりさせる。
これが出来ていないと
＞最初は大枠だけ捕らえて分析・設計を行い、その時に気づいたり発生する
＞問題点をまた、客にヒヤリングして要件を提示してもらう
こんなのが当然だと思ってると、手戻りが多発し、デスマーチが生まれる。
要件定義書の次に顧客が見るのは基本的には現物な訳で、
実物見てから「こんなシステムが欲しかったんじゃない」とか言われる可能性もある。
だから要件定義書を作るプロセス辺りでユースケース記述を書いたり、
GUIならプロトタイプを作ったりするわけで。
大体設計しながら要件変更が当たり前だなんて、お前は一体何を元にして見積もり出してるんだよ。
KKDか？
>>848
＞とにかく、これぐらいのシステムではレスポンス／リソースは大丈夫だ
根拠は？
ツタヤ全店が同一システムを使用してネットワーク経由で貸し出し状況等を一元管理してたとしても平気ですか？
要件で決められて無いので、そういう使われ方をするシステムなのかも知れない。
＞俺の要件定義は「目的」を明記することだ
中略
＞本当にそれが、分析や初期段階の設計に必要だと思うのか？
必要です。
393の「要件定義」がどうかは知らんけど、世間ではそうではない。
一般的には要件定義の目的の1つに「顧客が持っている曖昧な要望について
どのような機能であるかをはっきりさせる」ということがある。
例えば顧客が漠然と言っている「ビデオ貸し出し」とは
システムとしてはどういう機能なのか、というようなことをはっきりさせる。
これが出来ていないと
＞最初は大枠だけ捕らえて分析・設計を行い、その時に気づいたり発生する
＞問題点をまた、客にヒヤリングして要件を提示してもらう
こんなのが当然だと思ってると、手戻りが多発し、デスマーチが生まれる。
要件定義書の次に顧客が見るのは基本的には現物な訳で、
実物見てから「こんなシステムが欲しかったんじゃない」とか言われる可能性もある。
だから要件定義書を作るプロセス辺りでユースケース記述を書いたり、
GUIならプロトタイプを作ったりするわけで。
大体設計しながら要件変更が当たり前だなんて、お前は一体何を元にして見積もり出してるんだよ。
KKDか？
>>848
＞とにかく、これぐらいのシステムではレスポンス／リソースは大丈夫だ
根拠は？
ツタヤ全店が同一システムを使用してネットワーク経由で貸し出し状況等を一元管理してたとしても平気ですか？
要件で決められて無いので、そういう使われ方をするシステムなのかも知れない。
393って、自分に不利な質問には答えてないし、適当に問題をはぐらかしてる。
なんだか本を読んで詰め込んだ知識を消化しきれないまま必死に自己弁護しながら語ってる印象だ。
まぁ、勉強しようとしてる分だけおじゃばよりましかな。ただおじゃばより若干頭が悪いな。
なんだか本を読んで詰め込んだ知識を消化しきれないまま必死に自己弁護しながら語ってる印象だ。
まぁ、勉強しようとしてる分だけおじゃばよりましかな。ただおじゃばより若干頭が悪いな。
いやおじゃば以下だろ
> 393って、自分に不利な質問には答えてないし、適当に問題をはぐらかしてる。
実務だと、デスマーチかプロジェクト崩壊につながること必至の最悪な態度だな。
自分の興味のあるところをつまみ食いするだけじゃなく、答えにくいことも
真摯に議論できて、まともなシステムが作れるのに。
実務だと、デスマーチかプロジェクト崩壊につながること必至の最悪な態度だな。
自分の興味のあるところをつまみ食いするだけじゃなく、答えにくいことも
真摯に議論できて、まともなシステムが作れるのに。
長文２人の前提は、「個別の客はいない。レンタルシステムのパッケージを作る」ということでOK？
それなら他の連中との食い違いは分かる
他の連中の前提はこうだ
１．客から「レンタルシステム作ってくれ」と依頼される
２．客にシステム化の目的と要件を確認する（RFP発生）
３．システム化に向けての分析・設計・製造を行い納品する
長文２人
１．とにかく実装してみる（何を作るかは作りながら考える）
２．デザパタを考えてみる（何の目的かは考えながら考える）
３．何のために作っているのかは考えてはダメ
・
・
１９２４１７９４３７２．デスマーチが終わらない
それなら他の連中との食い違いは分かる
他の連中の前提はこうだ
１．客から「レンタルシステム作ってくれ」と依頼される
２．客にシステム化の目的と要件を確認する（RFP発生）
３．システム化に向けての分析・設計・製造を行い納品する
長文２人
１．とにかく実装してみる（何を作るかは作りながら考える）
２．デザパタを考えてみる（何の目的かは考えながら考える）
３．何のために作っているのかは考えてはダメ
・
・
１９２４１７９４３７２．デスマーチが終わらない
なかなか鋭い分析だな。
言いえて妙
>847
お前は一体何の話がしたいんだ？
顧客の特徴や傾向の分析は今必要か？
いらねーだろ
> お前は、客が最初から全ての要件を提示しないと客に
> 「要求を挙げろって言われてんのいい加減理解しろよ」と言うのか？
よく読めバカ
>820はお前に言ってんだ、お前に
お前は一体何の話がしたいんだ？
顧客の特徴や傾向の分析は今必要か？
いらねーだろ
> お前は、客が最初から全ての要件を提示しないと客に
> 「要求を挙げろって言われてんのいい加減理解しろよ」と言うのか？
よく読めバカ
>820はお前に言ってんだ、お前に
俺ならビデオクラスをまず作るな。
そんでタイトルプロパティを・・・
総時間プロパティ
製作会社
主演
発売日
DBから引っ張ってきてレコード直接処理した方がいいよね。
sqlでできない処理があるならラップしてもいいけど。
そんでタイトルプロパティを・・・
総時間プロパティ
製作会社
主演
発売日
DBから引っ張ってきてレコード直接処理した方がいいよね。
sqlでできない処理があるならラップしてもいいけど。
>>843
>393はどうしてこうも喧嘩腰なのかねぇ。ま、そんなとはいいが、
そうだな反省する、これから無知な質問は無視するよ（対応すると疲れて怒りっぽくなる）
>Chain of Responsibility はGUIのイベントメッセージの伝達とか、フィルタリングでよく使われるパターンだな。
>だけど、今回のケース（商品が何万もある？）では、対象となるインスタンス（商品）が全てメモリに存在しないと性能的に
>厳しいだろうし、マルチユーザの環境だと、排他と整合性も考慮しないといけない。
なんで皆な実装ばかり意識するんだ分析・設計だろ、まっいいが実際単純なロジックのオブジェクトを1万個作ってやってみたらどうだ？
簡単に出来るだろう？
あと、「マルチユーザの環境だと、排他と整合性も考慮しないといけない。」よく考えてくれ
マルチユーザの環境でも、オブジェクトは実際のコードだからそれしか実行されない（RDBとは違う）
おれの考える「排他と整合性」とは違う事を言っているのか？
>と言う感じで、デザパタのメリットばかりに目を向けて安易に使うんじゃなくて、デメリットもよく勘案した上で、採用す
>るかどうか判断した方がいいと思うが。
そうだな、余談だが、「Chain of Responsibility はGUIのイベントメッセージの伝達」に使うのか？
Iteratorパターンの方がいいんじゃないか？
Chain of Responsibilityパターンを適用したのはよく勘案した上で、採用するどうか判断した結果なんだよな？
>>849-855
無知は無視
>393はどうしてこうも喧嘩腰なのかねぇ。ま、そんなとはいいが、
そうだな反省する、これから無知な質問は無視するよ（対応すると疲れて怒りっぽくなる）
>Chain of Responsibility はGUIのイベントメッセージの伝達とか、フィルタリングでよく使われるパターンだな。
>だけど、今回のケース（商品が何万もある？）では、対象となるインスタンス（商品）が全てメモリに存在しないと性能的に
>厳しいだろうし、マルチユーザの環境だと、排他と整合性も考慮しないといけない。
なんで皆な実装ばかり意識するんだ分析・設計だろ、まっいいが実際単純なロジックのオブジェクトを1万個作ってやってみたらどうだ？
簡単に出来るだろう？
あと、「マルチユーザの環境だと、排他と整合性も考慮しないといけない。」よく考えてくれ
マルチユーザの環境でも、オブジェクトは実際のコードだからそれしか実行されない（RDBとは違う）
おれの考える「排他と整合性」とは違う事を言っているのか？
>と言う感じで、デザパタのメリットばかりに目を向けて安易に使うんじゃなくて、デメリットもよく勘案した上で、採用す
>るかどうか判断した方がいいと思うが。
そうだな、余談だが、「Chain of Responsibility はGUIのイベントメッセージの伝達」に使うのか？
Iteratorパターンの方がいいんじゃないか？
Chain of Responsibilityパターンを適用したのはよく勘案した上で、採用するどうか判断した結果なんだよな？
>>849-855
無知は無視
>>856
>＞本当にそれが、分析や初期段階の設計に必要だと思うのか？
>必要です。
だから「その手段を聞いて何をどう分析・設計に反映させる？」
>393の「要件定義」がどうかは知らんけど、世間ではそうではない。
>一般的には要件定義の目的の1つに「顧客が持っている曖昧な要望について
>どのような機能であるかをはっきりさせる」ということがある。
どこの世間だ？まっいいが曖昧でも要望があれば分析・設計できる
と言うかそれが明確にして行くのが分析・設計だが？
>＞最初は大枠だけ捕らえて分析・設計を行い、その時に気づいたり発生する
>＞問題点をまた、客にヒヤリングして要件を提示してもらう
>こんなのが当然だと思ってると、手戻りが多発し、デスマーチが生まれる。
いや、客が全ての要件を提示したと思って進めて行く方がデスマーチになる
>要件定義書の次に顧客が見るのは基本的には現物な訳で、
>実物見てから「こんなシステムが欲しかったんじゃない」とか言われる可能性もある。
>だから要件定義書を作るプロセス辺りでユースケース記述を書いたり、
>GUIならプロトタイプを作ったりするわけで。
「要件定義書の次に顧客が見るのは基本的には現物な訳で」それも世間か？
分かってるか？ユースケースは手段を書くんじゃなく目的(要求)をかくんだぞ
>大体設計しながら要件変更が当たり前だなんて、お前は一体何を元にして見積もり出してるんだよ。
>KKDか？
不確定要素を考えないでプロジェクト進めているのか？それも世間か？すごいな今の世間はｗ
まっ多少の要件の追加や変更は不確定要素と言うレベルでもないが
>根拠は？
>ツタヤ全店が同一システムを使用してネットワーク経由で貸し出し状況等を一元管理してたとしても平気ですか？
>要件で決められて無いので、そういう使われ方をするシステムなのかも知れない。
全然大丈夫だと思っているが、何が問題だ？レスポンスかリソースかどっちが問題だ、両方か？
>＞本当にそれが、分析や初期段階の設計に必要だと思うのか？
>必要です。
だから「その手段を聞いて何をどう分析・設計に反映させる？」
>393の「要件定義」がどうかは知らんけど、世間ではそうではない。
>一般的には要件定義の目的の1つに「顧客が持っている曖昧な要望について
>どのような機能であるかをはっきりさせる」ということがある。
どこの世間だ？まっいいが曖昧でも要望があれば分析・設計できる
と言うかそれが明確にして行くのが分析・設計だが？
>＞最初は大枠だけ捕らえて分析・設計を行い、その時に気づいたり発生する
>＞問題点をまた、客にヒヤリングして要件を提示してもらう
>こんなのが当然だと思ってると、手戻りが多発し、デスマーチが生まれる。
いや、客が全ての要件を提示したと思って進めて行く方がデスマーチになる
>要件定義書の次に顧客が見るのは基本的には現物な訳で、
>実物見てから「こんなシステムが欲しかったんじゃない」とか言われる可能性もある。
>だから要件定義書を作るプロセス辺りでユースケース記述を書いたり、
>GUIならプロトタイプを作ったりするわけで。
「要件定義書の次に顧客が見るのは基本的には現物な訳で」それも世間か？
分かってるか？ユースケースは手段を書くんじゃなく目的(要求)をかくんだぞ
>大体設計しながら要件変更が当たり前だなんて、お前は一体何を元にして見積もり出してるんだよ。
>KKDか？
不確定要素を考えないでプロジェクト進めているのか？それも世間か？すごいな今の世間はｗ
まっ多少の要件の追加や変更は不確定要素と言うレベルでもないが
>根拠は？
>ツタヤ全店が同一システムを使用してネットワーク経由で貸し出し状況等を一元管理してたとしても平気ですか？
>要件で決められて無いので、そういう使われ方をするシステムなのかも知れない。
全然大丈夫だと思っているが、何が問題だ？レスポンスかリソースかどっちが問題だ、両方か？
>>857-862
はい、アホ無知は無視
>>843,856みたいに、俺と違う意見でも良いから、自分で考えてから書け
分析・設計を進める為に簡単にまとめると
・要件定義・・・目的を明記にする（済）
・分析 ・・・必要な要素(情報)を抽出する。 ここで注意するのは、現在のシステムを分析するんじゃなく将来あるべきシステムを分析する
・設計 ・・・これは、概念レベルと実装レベルに分ける
・概念 ・・・分析で抽出した要素(情報)を整理(クラス化)する
・実装 ・・・概念で作ったクラスを実装に即した形にする
はい、アホ無知は無視
>>843,856みたいに、俺と違う意見でも良いから、自分で考えてから書け
分析・設計を進める為に簡単にまとめると
・要件定義・・・目的を明記にする（済）
・分析 ・・・必要な要素(情報)を抽出する。 ここで注意するのは、現在のシステムを分析するんじゃなく将来あるべきシステムを分析する
・設計 ・・・これは、概念レベルと実装レベルに分ける
・概念 ・・・分析で抽出した要素(情報)を整理(クラス化)する
・実装 ・・・概念で作ったクラスを実装に即した形にする
おじゃば、笑えんな。
いや、というかこれだけ意見のズレ(成否は問わない)があっても、
壮烈に叩かれるおじゃばって・・・。
いや、というかこれだけ意見のズレ(成否は問わない)があっても、
壮烈に叩かれるおじゃばって・・・。
>>863
日本語の分からんアホは無視
>>864
>DBから引っ張ってきてレコード直接処理した方がいいよね。
>sqlでできない処理があるならラップしてもいいけど。
それでも出来るが、オブジェクト指向か？構造化になっていないか
日本語の分からんアホは無視
>>864
>DBから引っ張ってきてレコード直接処理した方がいいよね。
>sqlでできない処理があるならラップしてもいいけど。
それでも出来るが、オブジェクト指向か？構造化になっていないか
どう分析したら商品が責任者にみえたのか
アホだろこいつｗ>>865
アホだろこいつｗ>>865
全然分析・設計が進まない、真面目に書いている奴もいるのに。アホ相手するのを止めて進める
要件 １．会員登録の分析
現在：入会申込用紙に記入し、身分証と一緒に窓口にだし、受理されたら会員証を発行する（とヒアリング結果を仮定する）
入会申込用紙の内容：
・住所氏名など個人情報
・家族会員の場合家族の名前・生年月日
要素の抽出：
・入会申込用紙に書かれた内容
・身分証の種類とそれに伴う任意の番号（例えば免許書なら免許番号とか）
・発行した会員証の番号
・上記の発行日
これに将来あるべきシステムを考慮すると身分証の種類が増えるぐらいか？
その場合任意の番号がどう付けられるのか分からんから汎用的にする
これが俺の会員登録の分析だ、足りない部分は付け足したり
間違っていれば修正してくれ。前提条件にしているヒアリング結果も変更してもらって構わない。
要件 １．会員登録の分析
現在：入会申込用紙に記入し、身分証と一緒に窓口にだし、受理されたら会員証を発行する（とヒアリング結果を仮定する）
入会申込用紙の内容：
・住所氏名など個人情報
・家族会員の場合家族の名前・生年月日
要素の抽出：
・入会申込用紙に書かれた内容
・身分証の種類とそれに伴う任意の番号（例えば免許書なら免許番号とか）
・発行した会員証の番号
・上記の発行日
これに将来あるべきシステムを考慮すると身分証の種類が増えるぐらいか？
その場合任意の番号がどう付けられるのか分からんから汎用的にする
これが俺の会員登録の分析だ、足りない部分は付け足したり
間違っていれば修正してくれ。前提条件にしているヒアリング結果も変更してもらって構わない。
>>866
＞>＞本当にそれが、分析や初期段階の設計に必要だと思うのか？
＞>必要です。
＞だから「その手段を聞いて何をどう分析・設計に反映させる？」
反映させるという言葉自体に違和感を感じる。
システム開発の開始においては、まず、顧客の要望がある。
さらに、要望の出所である背景と目的(目標)がある。
そして、要望の中でより具体的な部分として業務要件がある。
ここまでは顧客が主体で定まる。
次に、要望、背景、目的から業務要件のうちどの部分をシステム化するか、
システム化の範囲を定める。
さらに、定められた範囲から、システムの機能要件を定める。
（その他に非機能要件などあれば追記する）
ここまでを開発者主体で定める。
以上を纏めた物が「要件定義書」だと思っているがどうか？
つまり、反映するまでも無く、業務要件を元に機能要件が決まり、
機能要件を元にシステムの分析・設計を行う。
例えば今要件(?)に「貸し出し」があるとして、
業務上「貸し出し」というのはどのようなことを行うのか、
業務上の「貸し出し」の中でシステムの「貸し出し」は
どのような機能を提供するのか、さっぱり分からない。
「貸し出し」という機能の名前は「業務での貸し出しにおいて使用される機能」と言うことしか伝わらない。
指定されたビデオに対してデータ上で貸し出しマークを付けるのは「貸し出し」機能だろうが、
客が端末で入力したビデオを店員に通知して、店員がビデオを持ってくる、コレも「貸し出し」機能だ。
今思ったんだが、393って要求分析とシステム分析を混同しとるのと違うか？
＞>＞本当にそれが、分析や初期段階の設計に必要だと思うのか？
＞>必要です。
＞だから「その手段を聞いて何をどう分析・設計に反映させる？」
反映させるという言葉自体に違和感を感じる。
システム開発の開始においては、まず、顧客の要望がある。
さらに、要望の出所である背景と目的(目標)がある。
そして、要望の中でより具体的な部分として業務要件がある。
ここまでは顧客が主体で定まる。
次に、要望、背景、目的から業務要件のうちどの部分をシステム化するか、
システム化の範囲を定める。
さらに、定められた範囲から、システムの機能要件を定める。
（その他に非機能要件などあれば追記する）
ここまでを開発者主体で定める。
以上を纏めた物が「要件定義書」だと思っているがどうか？
つまり、反映するまでも無く、業務要件を元に機能要件が決まり、
機能要件を元にシステムの分析・設計を行う。
例えば今要件(?)に「貸し出し」があるとして、
業務上「貸し出し」というのはどのようなことを行うのか、
業務上の「貸し出し」の中でシステムの「貸し出し」は
どのような機能を提供するのか、さっぱり分からない。
「貸し出し」という機能の名前は「業務での貸し出しにおいて使用される機能」と言うことしか伝わらない。
指定されたビデオに対してデータ上で貸し出しマークを付けるのは「貸し出し」機能だろうが、
客が端末で入力したビデオを店員に通知して、店員がビデオを持ってくる、コレも「貸し出し」機能だ。
今思ったんだが、393って要求分析とシステム分析を混同しとるのと違うか？
「うちは客そんないないからExcelでいいや。俺マクロ覚えようと思うんだよね」
「Excelだといちいち保存すんのめんどーじゃね？」
「Accessとかいうのついてるよね、ほら、データベース」
「アレめんどそうじゃん。ファイルメーカとかいうの買うのは？」
「金出すのか、しかたないかぁ」
「いっそ、張り込んでうち用のソフト作ってもらおうよ。
だいぶかかるだろうけど、うちに合ってるのならあとあといいし」
「予算出るの？」「うー苦しいけど。がんばってなんとかしようか」
『Chain of Responsibilityパターンを適用しようと思うが、どうだ？』
「？？」
「Excelだといちいち保存すんのめんどーじゃね？」
「Accessとかいうのついてるよね、ほら、データベース」
「アレめんどそうじゃん。ファイルメーカとかいうの買うのは？」
「金出すのか、しかたないかぁ」
「いっそ、張り込んでうち用のソフト作ってもらおうよ。
だいぶかかるだろうけど、うちに合ってるのならあとあといいし」
「予算出るの？」「うー苦しいけど。がんばってなんとかしようか」
『Chain of Responsibilityパターンを適用しようと思うが、どうだ？』
「？？」
ま、簡単にまとめれば、例がそもそも不適切。
以上。
以上。
この程度の業務仕様まとめるのに長文使うなよ
実務でやったら客に切れられるだけだろ
実務でやったら客に切れられるだけだろ
アホは無視、と書かなきゃ気が済まないおｊ、いや393に萌え。
それはともかく。>865
＞そうだな、余談だが、「Chain of Responsibility はGUIのイベントメッセージの伝達」に使うのか？
＞Iteratorパターンの方がいいんじゃないか？
いや、Chain of Responsibility （たらい回し）のサンプルはたいがいそのイベント伝達だけど。
委譲の実装例とかにもよく出てくるよね？
どんな本で勉強してるのかちょっち興味はあるな。
Iteratorパターンって、それひょっとしてメッセージキューのことか？
そりゃデータ構造的にはそうなるかもしれんけど。
どこまでもボトムアップな393。トップダウン男ったら失礼だぞ、おじゃばw
それはともかく。>865
＞そうだな、余談だが、「Chain of Responsibility はGUIのイベントメッセージの伝達」に使うのか？
＞Iteratorパターンの方がいいんじゃないか？
いや、Chain of Responsibility （たらい回し）のサンプルはたいがいそのイベント伝達だけど。
委譲の実装例とかにもよく出てくるよね？
どんな本で勉強してるのかちょっち興味はあるな。
Iteratorパターンって、それひょっとしてメッセージキューのことか？
そりゃデータ構造的にはそうなるかもしれんけど。
どこまでもボトムアップな393。トップダウン男ったら失礼だぞ、おじゃばw
>>393
あんまりキレんな
俺はお前をからかう気は無いから冷静に聞いてくれ
これだけ認識がずれてることに違和感を感じないか？
他の連中は「前提がよく分からないからそれをはっきりさせたい」って言ってるんだよ
簡単にいえば、仕様が分からないものは作れない、ってこと
にも関わらず、「なんとかパターンが」とか「レスポンスが」とか出てくるから
「まだそれを言うのは早いんじゃないか？」と言われてるんだよ
>>871のはOKだと思うが、まだ、その前段が確定してない
例えば、レンタルシステムの中にも複数のシステムが発生するかもしれんだろ
・顧客管理システム
・在庫管理システム
・店舗管理システム
・社員管理システム
・帳票出力システム
・金銭連携システム
・金融機関連携システム
・その他
と、どこまで手をつけたらいいのか分からないし、各システムを連携するかどうかも未決定
各システムを統合させるのかどうかも分からない
そのまま突き進んでもデスマるぞ？って言われてるのはここだよ
冷静に話しようや
あんまりキレんな
俺はお前をからかう気は無いから冷静に聞いてくれ
これだけ認識がずれてることに違和感を感じないか？
他の連中は「前提がよく分からないからそれをはっきりさせたい」って言ってるんだよ
簡単にいえば、仕様が分からないものは作れない、ってこと
にも関わらず、「なんとかパターンが」とか「レスポンスが」とか出てくるから
「まだそれを言うのは早いんじゃないか？」と言われてるんだよ
>>871のはOKだと思うが、まだ、その前段が確定してない
例えば、レンタルシステムの中にも複数のシステムが発生するかもしれんだろ
・顧客管理システム
・在庫管理システム
・店舗管理システム
・社員管理システム
・帳票出力システム
・金銭連携システム
・金融機関連携システム
・その他
と、どこまで手をつけたらいいのか分からないし、各システムを連携するかどうかも未決定
各システムを統合させるのかどうかも分からない
そのまま突き進んでもデスマるぞ？って言われてるのはここだよ
冷静に話しようや
878 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/21(金) 09:50:48
>>836
一応、売上分析や予測などの機能は「ログ出力」と言う形で外してある。
しかし、料金や延滞管理は外せないだろう？ここがレンタル業務の特徴なのだから。
店舗規模はツタヤのような、巨大チェーンの1店舗で行こう。
商品数は数万～数十万点、会員数は数百万人（全会員）、一日の利用者は数千人。
これらの規模で最低限のビデオレンタル業務が出来るのを「業務に耐え得る」とする。
商品数は数千点、会員数が数百人、一日の利用者が数十人のシステムを設計しても意味がないしな。
エクセルでやれって事になる。
一応、売上分析や予測などの機能は「ログ出力」と言う形で外してある。
しかし、料金や延滞管理は外せないだろう？ここがレンタル業務の特徴なのだから。
店舗規模はツタヤのような、巨大チェーンの1店舗で行こう。
商品数は数万～数十万点、会員数は数百万人（全会員）、一日の利用者は数千人。
これらの規模で最低限のビデオレンタル業務が出来るのを「業務に耐え得る」とする。
商品数は数千点、会員数が数百人、一日の利用者が数十人のシステムを設計しても意味がないしな。
エクセルでやれって事になる。
既存のシステムに勝つためには抜本的なアイデアも必要
くっだらない前提を並べてる時点でお前にはセンスがない
くっだらない前提を並べてる時点でお前にはセンスがない
>>878
そんな規模のシステムをここでウダウダできるのかそもそも。
つか、何のためにここでレンタルビデオ屋の話をしてるのか、
すっかり見失ってねーかそれじゃ。
って俺も何でなのかさっぱりわからないわけだが。
OOだとここがいいって示す、ちゅー流れでもなかったし。
強いて言えばおじゃばが話題を変えたかったくらいのコトかなｗ
そんな規模のシステムをここでウダウダできるのかそもそも。
つか、何のためにここでレンタルビデオ屋の話をしてるのか、
すっかり見失ってねーかそれじゃ。
って俺も何でなのかさっぱりわからないわけだが。
OOだとここがいいって示す、ちゅー流れでもなかったし。
強いて言えばおじゃばが話題を変えたかったくらいのコトかなｗ
881 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/21(金) 20:13:12
>>848
エクセルで出来る規模ならともかく、商品数が数十万、会員数が数百万なら、オンメモリやシーケンシャル
検索はダメだ。落ちる直前のデータまで救う必要があるから、自前のDBも現実的に無理だ。
あと865の「ロックオブジェクトは1つのみ」ってのもその説明だけではダメだ。
一般的な話だが、データを追加するには普通は「重複チェック」を行う。
普通はその時に関連するレコードをロックするので、その設計だと全レコードロックがかかる。
会員や商品の二重登録チェックだな。これの対応策がないとロックされるのは1個ではない。
今の所、848の説明では俺の納得出来る答えではない。
オンメモリ不可、DBは既存製品で、ロックの問題に対応した説明でないと、夢のシステムのままになる。
>>871
項目は最小限に絞ろう。適切に設計されていれば、後からの追加も簡単なはずだ。
入会申し込み用紙の内容。
・氏名
・住所
・生年月日
・電話番号
（家族会員制度なし）
要素の抽出
・上記内容
・会員番号
・入会日
（証明書は目視で確認+コピー（または画像）を保存）
エクセルで出来る規模ならともかく、商品数が数十万、会員数が数百万なら、オンメモリやシーケンシャル
検索はダメだ。落ちる直前のデータまで救う必要があるから、自前のDBも現実的に無理だ。
あと865の「ロックオブジェクトは1つのみ」ってのもその説明だけではダメだ。
一般的な話だが、データを追加するには普通は「重複チェック」を行う。
普通はその時に関連するレコードをロックするので、その設計だと全レコードロックがかかる。
会員や商品の二重登録チェックだな。これの対応策がないとロックされるのは1個ではない。
今の所、848の説明では俺の納得出来る答えではない。
オンメモリ不可、DBは既存製品で、ロックの問題に対応した説明でないと、夢のシステムのままになる。
>>871
項目は最小限に絞ろう。適切に設計されていれば、後からの追加も簡単なはずだ。
入会申し込み用紙の内容。
・氏名
・住所
・生年月日
・電話番号
（家族会員制度なし）
要素の抽出
・上記内容
・会員番号
・入会日
（証明書は目視で確認+コピー（または画像）を保存）
882 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/21(金) 20:22:18
>>877
システム的には、ビデオレンタルシステムに最低限必要な物だけと考えよう。
複数に分けて連携させるのか、1つで行くのか、どこから手をつけるかは設計者次第。
開発範囲と規模は、878に示した通りで。
>>880
一般的なシステムをOOで設計してみようと言う所から来ている。
トップダウン男がビデオレンタルを提案したのは、俺の在庫管理システムが抽象的すぎるからと言う事だ。
俺が話を変えたいという訳ではないし、俺に対するどちらの質問も受け付けよう。
システム的には、ビデオレンタルシステムに最低限必要な物だけと考えよう。
複数に分けて連携させるのか、1つで行くのか、どこから手をつけるかは設計者次第。
開発範囲と規模は、878に示した通りで。
>>880
一般的なシステムをOOで設計してみようと言う所から来ている。
トップダウン男がビデオレンタルを提案したのは、俺の在庫管理システムが抽象的すぎるからと言う事だ。
俺が話を変えたいという訳ではないし、俺に対するどちらの質問も受け付けよう。
>>881
いや、だからなんでそんなでかい話をそんな細かいところからすんだ？
そー393も言ってるのがどーしてわからないんだ？
会員数が中国人全部でも何でもいいんだけどさ、「何するのよ？」が
さっぱりわかんねーで設計だ実装だオブジェクト指向だってもダメだろよ。
「このシステムでやることは何？」
本来のお前の趣旨だと、ビデオ貸し出しの管理だけで、金銭とかチェーンは別じゃないのか？
Excelでできるようなことの方が、掲示板で話すのにはいいんじゃないのか？
いや、だからなんでそんなでかい話をそんな細かいところからすんだ？
そー393も言ってるのがどーしてわからないんだ？
会員数が中国人全部でも何でもいいんだけどさ、「何するのよ？」が
さっぱりわかんねーで設計だ実装だオブジェクト指向だってもダメだろよ。
「このシステムでやることは何？」
本来のお前の趣旨だと、ビデオ貸し出しの管理だけで、金銭とかチェーンは別じゃないのか？
Excelでできるようなことの方が、掲示板で話すのにはいいんじゃないのか？
884 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/21(金) 20:53:30
話について来られない人のために、簡単に状況を説明しよう。
まず、在庫管理の話。
1.トップダウン男が、在庫管理システムを設計。
2.数人がその設計では、リソース、レスポンス、堅牢性に問題があり、その設計自体がデザインパターンを
使いたいだけではないかと指摘。
3.トップダウン男が、設計でリソース、レスポンスは考えるな。オブジェクト指向はこういう物だと回答。
次にビデオレンタルの話。
1.数人がユースケースを出せと要求。
2.俺がユースケースを記載。
3.数人が詳細化を要求。
4.トップダウン男がまだ詳細化は必要なく、むしろ抽象化すべきと回答。
5.数人が詳細化しなければ設計出来ないと指摘。
6.俺が詳細化条件を提示。
トップダウン男と数人の違いは、数人は顧客の要求を明確にして詳細化しようとしているのに対して、
トップタウン男の方は、将来を見据えて抽象化しようとしている所だ。
設計方針から言うと全く逆だ。俺的には数人と同様、トップダウン男の設計に疑問を持っているが、
やると言っているのだから、どのようにやるのか勉強させてもらおうと思う。
まず、在庫管理の話。
1.トップダウン男が、在庫管理システムを設計。
2.数人がその設計では、リソース、レスポンス、堅牢性に問題があり、その設計自体がデザインパターンを
使いたいだけではないかと指摘。
3.トップダウン男が、設計でリソース、レスポンスは考えるな。オブジェクト指向はこういう物だと回答。
次にビデオレンタルの話。
1.数人がユースケースを出せと要求。
2.俺がユースケースを記載。
3.数人が詳細化を要求。
4.トップダウン男がまだ詳細化は必要なく、むしろ抽象化すべきと回答。
5.数人が詳細化しなければ設計出来ないと指摘。
6.俺が詳細化条件を提示。
トップダウン男と数人の違いは、数人は顧客の要求を明確にして詳細化しようとしているのに対して、
トップタウン男の方は、将来を見据えて抽象化しようとしている所だ。
設計方針から言うと全く逆だ。俺的には数人と同様、トップダウン男の設計に疑問を持っているが、
やると言っているのだから、どのようにやるのか勉強させてもらおうと思う。
>>884
おじゃばも393もまず実装からはいるのがまずくねーかと数人ｗが言ってる、の間違いじゃね？
おじゃばも393もまず実装からはいるのがまずくねーかと数人ｗが言ってる、の間違いじゃね？
ちょっとまて、おじゃばのユースケースに、誰か納得したかなー
>>872
なんだ長文書いて、結局具体的な要件定義の提示はないのか？
まっいいが、読んだ感想は
『それは、オブジェクト指向なのか？』と言う事だ
どの図でモデリングした結果だ？手法は何という？
なんか構造化で見たよう気がするが、気のせいか？
>>876
>いや、Chain of Responsibility （たらい回し）のサンプルはたいがいそのイベント伝達だけど。
>委譲の実装例とかにもよく出てくるよね？
「デザパタのメリットばかりに目を向けて安易に使うんじゃなくて、デメリットもよく勘案した上で
採用するかどうか判断した」じゃなかったのか？サンプルに乗っているから使ったのか？
Chain of ResponsibilityパターンとIteratorパターンの対比でメリット・デメリットを教えてくれ
>>877
>にも関わらず、「なんとかパターンが」とか「レスポンスが」とか出てくるから
>「まだそれを言うのは早いんじゃないか？」と言われてるんだよ
俺は何回も実装を考えるなと書いているが？
なんだ長文書いて、結局具体的な要件定義の提示はないのか？
まっいいが、読んだ感想は
『それは、オブジェクト指向なのか？』と言う事だ
どの図でモデリングした結果だ？手法は何という？
なんか構造化で見たよう気がするが、気のせいか？
>>876
>いや、Chain of Responsibility （たらい回し）のサンプルはたいがいそのイベント伝達だけど。
>委譲の実装例とかにもよく出てくるよね？
「デザパタのメリットばかりに目を向けて安易に使うんじゃなくて、デメリットもよく勘案した上で
採用するかどうか判断した」じゃなかったのか？サンプルに乗っているから使ったのか？
Chain of ResponsibilityパターンとIteratorパターンの対比でメリット・デメリットを教えてくれ
>>877
>にも関わらず、「なんとかパターンが」とか「レスポンスが」とか出てくるから
>「まだそれを言うのは早いんじゃないか？」と言われてるんだよ
俺は何回も実装を考えるなと書いているが？
>>881
>エクセルで出来る規模ならともかく、商品数が数十万、会員数が数百万なら、オンメモリやシーケンシャル
>検索はダメだ。落ちる直前のデータまで救う必要があるから、自前のDBも現実的に無理だ。
実装時は多分RDBを使うが、何回も書くがまだ実装は考えない
>今の所、848の説明では俺の納得出来る答えではない。
>オンメモリ不可、DBは既存製品で、ロックの問題に対応した説明でないと、夢のシステムのままになる。
865は「マルチユーザの環境だと、排他と整合性も考慮しないといけない。」と認識している
レコードの話では無いと思うが？
>（家族会員制度なし）
家族会員を外したか、設計に面白みを出そうと追加したが、確かにいまの状態ではシンプルがいいな
>（証明書は目視で確認+コピー（または画像）を保存）
証明書の番号を外してコピー（または画像）か、将来あるべきシステムとして大丈夫か？
番号で管理するば、会員番号から直ぐに証明書の番号が抽出できるが、コピーだと棚から探すのか？
>エクセルで出来る規模ならともかく、商品数が数十万、会員数が数百万なら、オンメモリやシーケンシャル
>検索はダメだ。落ちる直前のデータまで救う必要があるから、自前のDBも現実的に無理だ。
実装時は多分RDBを使うが、何回も書くがまだ実装は考えない
>今の所、848の説明では俺の納得出来る答えではない。
>オンメモリ不可、DBは既存製品で、ロックの問題に対応した説明でないと、夢のシステムのままになる。
865は「マルチユーザの環境だと、排他と整合性も考慮しないといけない。」と認識している
レコードの話では無いと思うが？
>（家族会員制度なし）
家族会員を外したか、設計に面白みを出そうと追加したが、確かにいまの状態ではシンプルがいいな
>（証明書は目視で確認+コピー（または画像）を保存）
証明書の番号を外してコピー（または画像）か、将来あるべきシステムとして大丈夫か？
番号で管理するば、会員番号から直ぐに証明書の番号が抽出できるが、コピーだと棚から探すのか？
>>883
>会員数が中国人全部でも何でもいいんだけどさ、「何するのよ？」が
>さっぱりわかんねーで設計だ実装だオブジェクト指向だってもダメだろよ。
>「このシステムでやることは何？」
>本来のお前の趣旨だと、ビデオ貸し出しの管理だけで、金銭とかチェーンは別じゃないのか？
>Excelでできるようなことの方が、掲示板で話すのにはいいんじゃないのか？
その通りだ、ここでやりたいのはオブジェクト指向で分析・設計を行なうこと
レンタルビデオのシステムだけなら、別にDOAでも構わないし、その方が向いている
あと、規模の問題だがビデオ・会員証・カウンター(人間)と物質が伴っているから大丈夫だ
いくらレンタルが多く発生してもカウンター(人間)数以上には処理できない
ツタヤのカウンターは全国であっても何千ぐらいだろう、そして同じタイミングで登録処理を
するのは？これぐらの規模で問題が起こるとは考えにくい、逆に起きても行列が長くなるだけ
しかし、何回も書くが分析・設計で実装は考えない
>>886
>おじゃばも393もまず実装からはいるのがまずくねーかと数人ｗが言ってる、の間違いじゃね？
俺が何時実装から入ったんだ？
>会員数が中国人全部でも何でもいいんだけどさ、「何するのよ？」が
>さっぱりわかんねーで設計だ実装だオブジェクト指向だってもダメだろよ。
>「このシステムでやることは何？」
>本来のお前の趣旨だと、ビデオ貸し出しの管理だけで、金銭とかチェーンは別じゃないのか？
>Excelでできるようなことの方が、掲示板で話すのにはいいんじゃないのか？
その通りだ、ここでやりたいのはオブジェクト指向で分析・設計を行なうこと
レンタルビデオのシステムだけなら、別にDOAでも構わないし、その方が向いている
あと、規模の問題だがビデオ・会員証・カウンター(人間)と物質が伴っているから大丈夫だ
いくらレンタルが多く発生してもカウンター(人間)数以上には処理できない
ツタヤのカウンターは全国であっても何千ぐらいだろう、そして同じタイミングで登録処理を
するのは？これぐらの規模で問題が起こるとは考えにくい、逆に起きても行列が長くなるだけ
しかし、何回も書くが分析・設計で実装は考えない
>>886
>おじゃばも393もまず実装からはいるのがまずくねーかと数人ｗが言ってる、の間違いじゃね？
俺が何時実装から入ったんだ？
要件 ２．ビデオ貸し出しの分析
現在：ビデオを棚または、返却後の一時保管場所から選別し、カウンターにビデオと会員証を出し
ビデオの何泊を決め料金を払いレンタルする。
貸出しの条件：
・貸出し中が１０本までを限度に借りられる（但し、クリーニング用ビデオは別）
・新作は、１泊しか選べない
・準新作は、３泊しか選べない
・延滞が発生中は借りられない
・年齢制限を満たしている物しか借りられない
・複数本で一組のビデオは１本とする
要素の抽出：
レンタル
・レンタルした人の会員番号
・借りた日時
・設定した宿泊数
ビデオ
・年齢制限
・何本組み
・新作/準新作(これはどう持つか？）
これに将来あるべきシステムとして、同じビデオを2回借りようとすると
告知するようにする、また値段を変更可能する例えばサービスデーは安くするとか
また、自由に修正してくれ、あと他の分析誰かやってくれないか？
現在：ビデオを棚または、返却後の一時保管場所から選別し、カウンターにビデオと会員証を出し
ビデオの何泊を決め料金を払いレンタルする。
貸出しの条件：
・貸出し中が１０本までを限度に借りられる（但し、クリーニング用ビデオは別）
・新作は、１泊しか選べない
・準新作は、３泊しか選べない
・延滞が発生中は借りられない
・年齢制限を満たしている物しか借りられない
・複数本で一組のビデオは１本とする
要素の抽出：
レンタル
・レンタルした人の会員番号
・借りた日時
・設定した宿泊数
ビデオ
・年齢制限
・何本組み
・新作/準新作(これはどう持つか？）
これに将来あるべきシステムとして、同じビデオを2回借りようとすると
告知するようにする、また値段を変更可能する例えばサービスデーは安くするとか
また、自由に修正してくれ、あと他の分析誰かやってくれないか？
＞ビデオの何泊を決め
＞貸出し中が１０本までを限度に
まず日本語の分析から始めようか
＞貸出し中が１０本までを限度に
まず日本語の分析から始めようか
>>891
こいつ分析初めてなのか？ 大事な「誰が」がぬけてるじゃないか。
暗黙の了解事なのかもしらんが、そういう基本を疎かにしてると
あとで痛い目を見ることになるぞ。
>将来あるべきシステムとして、同じビデオを2回借りようとすると
>告知するようにする
将来あるべき...ってw、そんなたいした機能じゃないじゃねぇか。
機会損失を招きかねないそんなお節介機能を本当に店側が求めてるか
どうかはさておき、年齢チェックとか延滞チェックするんだから、
そんぐらい今回やってやれよ。
人に分析を頼むなら、まず自分がちゃんと分析してみせろよ。つきあいきれん。
ま、こいつにChain of ResponsibilityパターンとIteratorパターン
の違いは永久に理解できんだろ。こっちが疲れるわ。頭悪いんだから、せめて
タメ語はやめてくれ。
こいつ分析初めてなのか？ 大事な「誰が」がぬけてるじゃないか。
暗黙の了解事なのかもしらんが、そういう基本を疎かにしてると
あとで痛い目を見ることになるぞ。
>将来あるべきシステムとして、同じビデオを2回借りようとすると
>告知するようにする
将来あるべき...ってw、そんなたいした機能じゃないじゃねぇか。
機会損失を招きかねないそんなお節介機能を本当に店側が求めてるか
どうかはさておき、年齢チェックとか延滞チェックするんだから、
そんぐらい今回やってやれよ。
人に分析を頼むなら、まず自分がちゃんと分析してみせろよ。つきあいきれん。
ま、こいつにChain of ResponsibilityパターンとIteratorパターン
の違いは永久に理解できんだろ。こっちが疲れるわ。頭悪いんだから、せめて
タメ語はやめてくれ。
>>892
「ビデオ何泊借りるか決める」
で良いか？
>貸出し中が１０本までを限度に
こっちはおかしいとは思わんが、１０本一日で借りるとは
限らんから、貸し出し中の本数が１０本になるまでだが、変か？
>>893
>ま、こいつにChain of ResponsibilityパターンとIteratorパターン
>の違いは永久に理解できんだろ。こっちが疲れるわ。頭悪いんだから、せめて
心配するな知ってるから、それよりお前が分からないんだろｗ
「ビデオ何泊借りるか決める」
で良いか？
>貸出し中が１０本までを限度に
こっちはおかしいとは思わんが、１０本一日で借りるとは
限らんから、貸し出し中の本数が１０本になるまでだが、変か？
>>893
>ま、こいつにChain of ResponsibilityパターンとIteratorパターン
>の違いは永久に理解できんだろ。こっちが疲れるわ。頭悪いんだから、せめて
心配するな知ってるから、それよりお前が分からないんだろｗ
自分で、「・複数本で一組のビデオは１本とする 」と書いといてもう忘却の彼方か。
俺はお前じゃないからお前の意図は分からんが、想像するに、正確には、
「任意期間中に同一会員に貸出し可能な最大本数は１０組まで」
ということじゃないのか。正解はお前しか知らんことだから、キレんなよ。
>心配するな知ってるから、それよりお前が分からないんだろｗ
心配するな、お前が知らないことは知ってるから。何故かって？ 自分の投稿よく読み直してみろよw
俺はお前じゃないからお前の意図は分からんが、想像するに、正確には、
「任意期間中に同一会員に貸出し可能な最大本数は１０組まで」
ということじゃないのか。正解はお前しか知らんことだから、キレんなよ。
>心配するな知ってるから、それよりお前が分からないんだろｗ
心配するな、お前が知らないことは知ってるから。何故かって？ 自分の投稿よく読み直してみろよw
なんかOOとか以前にプロジェクトの進め方がヘタそーだな
>>888
872なんだが。
>>867とか>>891とか
ちょっと待て。
お前のところでは、要件定義の後に要求分析をするのか？
俺には、>>891とかどう見ても要件定義してる真っ最中にしか見えないんだが。
393の要件定義って単に要望を並べただけで、393が言ってる「分析・(初期段階の)設計」が
世間(本なりネットなり)で良く言われるところの要件定義に思えてしょうがない。
要望と要件の違い、分かってるか？
ちょっと会員登録のところだけ簡単に要件定義書書いてみたから、
393の言うところの要件定義書もちゃんと書いてみてくれんか？
何か機能名だけチョロチョロっと箇条書きするのではなくて、文書の形で。
それとも要件定義書とかは書かないのか？
http://www-2ch.net:8080/up/download/1206118140175536.Y2cHWq
ちなみにこの段階だと、俺的にはOOがどうとか関係ないと思ってる。
だから「どこがOOなんだ？」と聞かれても困る。
872なんだが。
>>867とか>>891とか
ちょっと待て。
お前のところでは、要件定義の後に要求分析をするのか？
俺には、>>891とかどう見ても要件定義してる真っ最中にしか見えないんだが。
393の要件定義って単に要望を並べただけで、393が言ってる「分析・(初期段階の)設計」が
世間(本なりネットなり)で良く言われるところの要件定義に思えてしょうがない。
要望と要件の違い、分かってるか？
ちょっと会員登録のところだけ簡単に要件定義書書いてみたから、
393の言うところの要件定義書もちゃんと書いてみてくれんか？
何か機能名だけチョロチョロっと箇条書きするのではなくて、文書の形で。
それとも要件定義書とかは書かないのか？
http://www-2ch.net:8080/up/download/1206118140175536.Y2cHWq
ちなみにこの段階だと、俺的にはOOがどうとか関係ないと思ってる。
だから「どこがOOなんだ？」と聞かれても困る。
まめな奴だな、あんなアホにつき合ってるとアホが伝染るゾ。
そだな、そこまでしてプログラマモドキどもに物教えんでも。
ここでOOスゲェとか言わしておけばよかろうに。
ここでOOスゲェとか言わしておけばよかろうに。
まあでも、プログラマモドキが作業モドキを延々やってるのを打ち切る効用はあるだろ。
それとも、見なかったふりして俺作業続行か？
それとも、見なかったふりして俺作業続行か？
つーか、おじゃばの最初の発言みると、
精々新人研修＋程度のネタだという匂いがプンプンなんだが、
規定していけど(いつもの通り)。
まともな方に話を捻じ曲げるのはどーでも良いけど、
話大きくしすぐると、収集付かなくなると思うんだが。
まあ、いつもの事だけど。
他システムとの連携やリアルへの反映を適用すると落としどころ
がなくなると思うんだが。
精々新人研修＋程度のネタだという匂いがプンプンなんだが、
規定していけど(いつもの通り)。
まともな方に話を捻じ曲げるのはどーでも良いけど、
話大きくしすぐると、収集付かなくなると思うんだが。
まあ、いつもの事だけど。
他システムとの連携やリアルへの反映を適用すると落としどころ
がなくなると思うんだが。
きっと、おじゃばは393がうまくできないように話をでかくしてるんじゃないか？
おじゃばも393も同レベルなんだろ。
経験がないもんだから俺俺ルールで話をでかくすることだけ張り合ってる。
経験がないもんだから俺俺ルールで話をでかくすることだけ張り合ってる。
経験が無いだけじゃなくセンスも無いところまで同じレベル
双子の兄弟なのかもしれない
双子の兄弟なのかもしれない
とはいえ、おじゃばや393も同情する所があるんだけどな。
図がないせいで、イメージが掴めないので個人的に信奉している方法に話が言っちゃうので、
話がずれて、話が大きくなる。
まあ、好きでやってる事なので外野が言うべき事じゃないが。
図がないせいで、イメージが掴めないので個人的に信奉している方法に話が言っちゃうので、
話がずれて、話が大きくなる。
まあ、好きでやってる事なので外野が言うべき事じゃないが。
ちょっと話ぶったぎるけど、
「うちのプロジェクトは分析の段階からクラス図とか作ってるよ」
って人はどれぐらいいる？
この業界って、良い悪いは別として、設計者＞グラマ の力関係があるでしょ
グラマがOO分かってても設計者がクラスすら分かってないまま
機能設計しちゃうのが多いと思うのよね
結局は基本設計書、詳細設計書ってのがあって、クラス図も何も無いまま
いきなりコーディングってところが結構あると思うんだけど
これ、「OOやってます」「OO普及してます」って言っていいの？
実装時の言語仕様にクラスがありますってだけで、とても普及とは言えないと思うんだけど
「うちのプロジェクトは分析の段階からクラス図とか作ってるよ」
って人はどれぐらいいる？
この業界って、良い悪いは別として、設計者＞グラマ の力関係があるでしょ
グラマがOO分かってても設計者がクラスすら分かってないまま
機能設計しちゃうのが多いと思うのよね
結局は基本設計書、詳細設計書ってのがあって、クラス図も何も無いまま
いきなりコーディングってところが結構あると思うんだけど
これ、「OOやってます」「OO普及してます」って言っていいの？
実装時の言語仕様にクラスがありますってだけで、とても普及とは言えないと思うんだけど
>>907
OOなんか別に道具だからいいんじゃね、てーか開発時の方針だろそんなの。
詳細設計にないのはいくら何でもダメだろうけど。
誰もOOやるためにシステムなんか作らねえよ
お客へのセールストークには使うかもしれんけど
業務しすてむなんか、OOにして劇的に楽になるもんでもないし
俺らマが営業トーク真に受けてどーすんのよ
OOなんか別に道具だからいいんじゃね、てーか開発時の方針だろそんなの。
詳細設計にないのはいくら何でもダメだろうけど。
誰もOOやるためにシステムなんか作らねえよ
お客へのセールストークには使うかもしれんけど
業務しすてむなんか、OOにして劇的に楽になるもんでもないし
俺らマが営業トーク真に受けてどーすんのよ
909 ：仕様書無しさん：2008/03/23(日) 05:41:44
おじゃばはRubyとか分かるんかなｗｗ
>>895
>自分で、「・複数本で一組のビデオは１本とする 」と書いといてもう忘却の彼方か。
>俺はお前じゃないからお前の意図は分からんが、想像するに、正確には、
>「任意期間中に同一会員に貸出し可能な最大本数は１０組まで」
>ということじゃないのか。正解はお前しか知らんことだから、キレんなよ。
一組を1本としてるんだから１０本でもいいだろ
それと、任意期間中ってなんだ？どの期間なら最大本数が変わるんだ？
どの期間も最大本数は１０本じゃないのか？
>心配するな、お前が知らないことは知ってるから。何故かって？ 自分の投稿よく読み直してみろよw
これか>>888
>Chain of ResponsibilityパターンとIteratorパターンの対比でメリット・デメリットを教えてくれ
これは、>>843
>Chain of Responsibility はGUIのイベントメッセージの伝達とか、フィルタリングでよく使われるパターンだな。
この書込みが気になるからだ、コンテナのGUIとかならまだ少しはわからるが「GUIのイベントメッセージの伝達」
だけだとな、本当に分かって書いてるのか？分かっているならメリット・デメリットを教えてくれ
>自分で、「・複数本で一組のビデオは１本とする 」と書いといてもう忘却の彼方か。
>俺はお前じゃないからお前の意図は分からんが、想像するに、正確には、
>「任意期間中に同一会員に貸出し可能な最大本数は１０組まで」
>ということじゃないのか。正解はお前しか知らんことだから、キレんなよ。
一組を1本としてるんだから１０本でもいいだろ
それと、任意期間中ってなんだ？どの期間なら最大本数が変わるんだ？
どの期間も最大本数は１０本じゃないのか？
>心配するな、お前が知らないことは知ってるから。何故かって？ 自分の投稿よく読み直してみろよw
これか>>888
>Chain of ResponsibilityパターンとIteratorパターンの対比でメリット・デメリットを教えてくれ
これは、>>843
>Chain of Responsibility はGUIのイベントメッセージの伝達とか、フィルタリングでよく使われるパターンだな。
この書込みが気になるからだ、コンテナのGUIとかならまだ少しはわからるが「GUIのイベントメッセージの伝達」
だけだとな、本当に分かって書いてるのか？分かっているならメリット・デメリットを教えてくれ
>>897
まず、今回の目的は「正しいレンタルビデオシステムを設計まで行なう」じゃなく
「オブジェクト指向の勉強の為レンタルビデオシステムを設計まで行なう」だと思っている
それを
>ちなみにこの段階だと、俺的にはOOがどうとか関係ないと思ってる。
>だから「どこがOOなんだ？」と聞かれても困る。
オブジェクト指向と関係なく、何処の形式か分からん物を、ずっと俺に提示しろと
言っていたのか？俺に何を提示させたいんだ？
とにかく内容を見ていく
１．２．３．は、表題はこれで良いと思う
４．は、フィールドを抽出しているが、抽出するのは分析だろ
５．は、システム要件は今回は無し(今回は分析・設計がメイン)
付録Ａは、まずユースケースがなんで付録なんだ、メインだろ
んぅ？これはRUPを自社用にカスタマイズしたものか？
とりあえず、標準形式(?)のRUPに変換してみる
まず、今回の目的は「正しいレンタルビデオシステムを設計まで行なう」じゃなく
「オブジェクト指向の勉強の為レンタルビデオシステムを設計まで行なう」だと思っている
それを
>ちなみにこの段階だと、俺的にはOOがどうとか関係ないと思ってる。
>だから「どこがOOなんだ？」と聞かれても困る。
オブジェクト指向と関係なく、何処の形式か分からん物を、ずっと俺に提示しろと
言っていたのか？俺に何を提示させたいんだ？
とにかく内容を見ていく
１．２．３．は、表題はこれで良いと思う
４．は、フィールドを抽出しているが、抽出するのは分析だろ
５．は、システム要件は今回は無し(今回は分析・設計がメイン)
付録Ａは、まずユースケースがなんで付録なんだ、メインだろ
んぅ？これはRUPを自社用にカスタマイズしたものか？
とりあえず、標準形式(?)のRUPに変換してみる
>>続き
ユースケース：会員情報登録
アクター ：店員
目的 ：お客を会員として記録する
事前条件 ：会員の情報が登録されていないこと
基本系列 ：
1.アクターがこのユースケースを起動
2.システムは、会員情報を要求する
3.アクターはその情報を提示する
4.システムは、その情報が登録されていない確認して、その情報を登録する
代替系列 ：会員登録の中断
事後条件 ：会員の情報が登録されていること
備考 ：
1. 店員は、登録を指定する
2. システムは、会員IDを作成する
3. システムは、会員IDを表示する
4. 店員は、会員情報（名前、住所、生年月日及び電話番号）を入力する
5. 店員は、登録を指定する
6. システムは、会員情報(会員ID及び入力内容)を会員管理に追加する
シナリオ ：山田太郎はレンタルビデオ店の会員になろうと申し込んだが
身分証明書の住所と現住所が違うため認められず拒否された
こんな感じか？結局、RUPからユースケースの部分を自社用にカスタマイズして
表題つけ体裁を整えた物を「要件定義書」としていたのか
それならRUPみたいな物と書いてくれれば、話は噛み合ったんだが
しかし、それは純粋に要件定義部分だけじゃないだろう逆にRUPはシームレスに
開発を進めていけるように考えられている。俺はRUPのユースケースは
分析の準備段階も含まれていると思っているが、まっ今回は別に手法は特定していないので
それで進めたいんなら、それでも良いが
ユースケース：会員情報登録
アクター ：店員
目的 ：お客を会員として記録する
事前条件 ：会員の情報が登録されていないこと
基本系列 ：
1.アクターがこのユースケースを起動
2.システムは、会員情報を要求する
3.アクターはその情報を提示する
4.システムは、その情報が登録されていない確認して、その情報を登録する
代替系列 ：会員登録の中断
事後条件 ：会員の情報が登録されていること
備考 ：
1. 店員は、登録を指定する
2. システムは、会員IDを作成する
3. システムは、会員IDを表示する
4. 店員は、会員情報（名前、住所、生年月日及び電話番号）を入力する
5. 店員は、登録を指定する
6. システムは、会員情報(会員ID及び入力内容)を会員管理に追加する
シナリオ ：山田太郎はレンタルビデオ店の会員になろうと申し込んだが
身分証明書の住所と現住所が違うため認められず拒否された
こんな感じか？結局、RUPからユースケースの部分を自社用にカスタマイズして
表題つけ体裁を整えた物を「要件定義書」としていたのか
それならRUPみたいな物と書いてくれれば、話は噛み合ったんだが
しかし、それは純粋に要件定義部分だけじゃないだろう逆にRUPはシームレスに
開発を進めていけるように考えられている。俺はRUPのユースケースは
分析の準備段階も含まれていると思っているが、まっ今回は別に手法は特定していないので
それで進めたいんなら、それでも良いが
どうしてそんなに必死なんだ？
たしかに、そう考えると辞めたくなってきた
ここ見てると、「本末転倒」って四文字熟語が浮かんでくるのはおれだけじゃないはずだ(´・ω・`)
>>393
393の提示してる開発プロセスって何て名前のヤツ？
393の提示してる開発プロセスって何て名前のヤツ？
キレキレ自己満足プロセス
393のやってることって
オブジェクト指向っていうよりオナニー露出嗜好だよな
オブジェクト指向っていうよりオナニー露出嗜好だよな
俺がルールだ って奴の相手はほんと疲れるよ。
意見するとすぐキレる。そして友達は誰もいなくなった...
意見するとすぐキレる。そして友達は誰もいなくなった...
>>907が言ってることがこのスレを物語ってるな
実際の現場では分析と設計でOOを利用することはかなり少ない
分析段階からUMLを利用したいと考える奴もいれば
オブジェクト指向という言葉すら知らない奴もいる
コーディング出来ない設計者がOOを覚えるわけないしな
実際の現場では分析と設計でOOを利用することはかなり少ない
分析段階からUMLを利用したいと考える奴もいれば
オブジェクト指向という言葉すら知らない奴もいる
コーディング出来ない設計者がOOを覚えるわけないしな
でも、余裕のある場合はなんかマジメに設計するけどな～。
でもソーすると、上長がもまえ暇そうだなって顔or話をする。
そもそも、同じ部品のプログラマー(ｗしか設計マジメに見ない。
あ、大規模は別だけどね。
某Ｆできっちり作っていたよ(でも突っ込みが数箇所あった)
でもソーすると、上長がもまえ暇そうだなって顔or話をする。
そもそも、同じ部品のプログラマー(ｗしか設計マジメに見ない。
あ、大規模は別だけどね。
某Ｆできっちり作っていたよ(でも突っ込みが数箇所あった)
どこに何が書いてあるかわからんような独自図形使った大量のエクセル仕様書を
渡されるより、
・ユースケースでシステム化範囲を明確にし、
・アクティビティ図で業務フローを
・クラス図でモジュール構成を
って、せめてこんだけでも整理してやってくれれば、いらん誤解が少なくなって
お互いの意図も伝わり易いと思うんだけどな。せっかくの共通仕様の設計ツール
なんだから。
意図が伝わらなくて本来不要なはずのやり取りにどんだけ時間を費されてるか。
まぁ、UML知らん奴にいくら書けといってもしょうがないんだけどね。せめて覚え
る努力はやって欲しい。無駄な時間を省けるんだから。その無駄な時間も大事な仕
事のうちと変な認識もってる奴が多すぎる。
渡されるより、
・ユースケースでシステム化範囲を明確にし、
・アクティビティ図で業務フローを
・クラス図でモジュール構成を
って、せめてこんだけでも整理してやってくれれば、いらん誤解が少なくなって
お互いの意図も伝わり易いと思うんだけどな。せっかくの共通仕様の設計ツール
なんだから。
意図が伝わらなくて本来不要なはずのやり取りにどんだけ時間を費されてるか。
まぁ、UML知らん奴にいくら書けといってもしょうがないんだけどね。せめて覚え
る努力はやって欲しい。無駄な時間を省けるんだから。その無駄な時間も大事な仕
事のうちと変な認識もってる奴が多すぎる。
だからオブジェクト指向は普及しないのか
お互いに「相手が勉強・努力不足だ、俺は知識があるのに」と
思ってるようじゃダメだろうね。>926の独自図形にしたところで
書いて渡してる奴は「これくらい見りゃわかるだろ、つか早く見方覚えろや」
くらいに思ってるんだろうし。「俺はUML勉強したんだから」みたいな話じゃ
仕事の成果物を改変する理由にはならないだろうね。
思ってるようじゃダメだろうね。>926の独自図形にしたところで
書いて渡してる奴は「これくらい見りゃわかるだろ、つか早く見方覚えろや」
くらいに思ってるんだろうし。「俺はUML勉強したんだから」みたいな話じゃ
仕事の成果物を改変する理由にはならないだろうね。
どっかで読んだ記憶があったんだが、見つけた。
ttp://www.mamezou.net/modules/xfsection/article.php?articleid=39
もう、ここ読んで終わり。でいいんじゃね。
ttp://www.mamezou.net/modules/xfsection/article.php?articleid=39
もう、ここ読んで終わり。でいいんじゃね。
>>930
だが、おじゃばはリンクは読まないから終わらないんだなこれがｗ
だが、おじゃばはリンクは読まないから終わらないんだなこれがｗ
>>926
>・ユースケースでシステム化範囲を明確にし、
>・アクティビティ図で業務フローを
>・クラス図でモジュール構成を
業務システムだと、そういう「お絵描き」よりもER図をしっかり書いてほしい。
なぜオブジェクト指向は普及しないのかって、役に立たないからじゃね？
>・ユースケースでシステム化範囲を明確にし、
>・アクティビティ図で業務フローを
>・クラス図でモジュール構成を
業務システムだと、そういう「お絵描き」よりもER図をしっかり書いてほしい。
なぜオブジェクト指向は普及しないのかって、役に立たないからじゃね？
ER図も「お絵描き」なわけだが
SEと豚を一緒にするな、豚に謝れ
GUIのないコンピュータ（今はもう無いか）と少し似ているね。
使いこなせば強力なんだけど万人が使いこなせるわけではないから
使いこなせない人は旧来の方法にしがみつく。
GUIの出自に「コンピュータを万人が使いこなせるように」という大目標があったんだけど。
ソフト開発におけるOOを万人が使いこなせるようにするための方法があるかというと・・・無いな。
UIの工夫のようなことで何とかなるようなものじゃないもの。
OOは考え方だから。旧来の方法を使い続けている人たちが死滅するのを待つしかない。
使いこなせば強力なんだけど万人が使いこなせるわけではないから
使いこなせない人は旧来の方法にしがみつく。
GUIの出自に「コンピュータを万人が使いこなせるように」という大目標があったんだけど。
ソフト開発におけるOOを万人が使いこなせるようにするための方法があるかというと・・・無いな。
UIの工夫のようなことで何とかなるようなものじゃないもの。
OOは考え方だから。旧来の方法を使い続けている人たちが死滅するのを待つしかない。
>>936
それほどOOが新しい物でもない、ただの考え方だろ。
構造化をすれば馬鹿にでもシステムがメンテ出来るようになる
そう昔は言われてたそうだぜ。「少しは」なったけどな。
ましてGUIでないコンピュータが死滅などしたわけでも無い。
＞旧来の方法を使い続けている人たちが死滅するのを待つしかない。
のなら、その程度の価値しかない考え方だということさ。
それほどOOが新しい物でもない、ただの考え方だろ。
構造化をすれば馬鹿にでもシステムがメンテ出来るようになる
そう昔は言われてたそうだぜ。「少しは」なったけどな。
ましてGUIでないコンピュータが死滅などしたわけでも無い。
＞旧来の方法を使い続けている人たちが死滅するのを待つしかない。
のなら、その程度の価値しかない考え方だということさ。
会社が工数算定方法を昔のままOOに適用するなら無理がでることもある
会社というより頭の固い連中かな
分析設計に時間を掛けるという概念が無いんだろ
会社というより頭の固い連中かな
分析設計に時間を掛けるという概念が無いんだろ
「分析」という概念はない。そして「設計」は金取るから。ある。
940 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/24(月) 19:19:18
>>889,890
とりあえず性能は後回しにするが、納得していないのでよろしく。
証明書はコピーして画像ファイルで格納としよう。
手入力させると間違いが発生するし、証明書番号からの検索はあまり使いそうもないし、
画像なら免許証でも保険証でも対応出来る。
>>891
>現在：ビデオを棚または、返却後の一時保管場所から選別し、カウンターにビデオと会員証を出し
一応、ビデオでなくてDVDにしよう。棚から選んでカウンターまで持って来るのは客で、
一時保管場所からの持ち出しは無しにしよう。
>・貸出し中が１０本までを限度に借りられる（但し、クリーニング用ビデオは別）
クリーニング用は無しとしよう。
>・複数本で一組のビデオは１本とする
これも無しとしよう。パッケージ単位でレンタルとする。
>・何本組み
これもなし。
>・新作/準新作(これはどう持つか？）
新作／準新作／旧作で、それぞれ
当日、1/2泊、2/3泊、3/4泊、7/8泊、延滞
により料金が異なる場合がある。
また料金設定は店舗により異なり、特別料金（半額サービス）の時もある。
>これに将来あるべきシステムとして、同じビデオを2回借りようとすると
これは無しとしよう。
ただし、俺が「無し」と言うのは、将来やるか分からないから今回は無しと言う事で、もしトップダウン男
の設計として、未来を見据えて設計すると言う事なら、有りの分類になるのかもしれない。
とりあえず性能は後回しにするが、納得していないのでよろしく。
証明書はコピーして画像ファイルで格納としよう。
手入力させると間違いが発生するし、証明書番号からの検索はあまり使いそうもないし、
画像なら免許証でも保険証でも対応出来る。
>>891
>現在：ビデオを棚または、返却後の一時保管場所から選別し、カウンターにビデオと会員証を出し
一応、ビデオでなくてDVDにしよう。棚から選んでカウンターまで持って来るのは客で、
一時保管場所からの持ち出しは無しにしよう。
>・貸出し中が１０本までを限度に借りられる（但し、クリーニング用ビデオは別）
クリーニング用は無しとしよう。
>・複数本で一組のビデオは１本とする
これも無しとしよう。パッケージ単位でレンタルとする。
>・何本組み
これもなし。
>・新作/準新作(これはどう持つか？）
新作／準新作／旧作で、それぞれ
当日、1/2泊、2/3泊、3/4泊、7/8泊、延滞
により料金が異なる場合がある。
また料金設定は店舗により異なり、特別料金（半額サービス）の時もある。
>これに将来あるべきシステムとして、同じビデオを2回借りようとすると
これは無しとしよう。
ただし、俺が「無し」と言うのは、将来やるか分からないから今回は無しと言う事で、もしトップダウン男
の設計として、未来を見据えて設計すると言う事なら、有りの分類になるのかもしれない。
941 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/24(月) 19:29:14
>>913
>事前条件 ：会員の情報が登録されていないこと
これは登録時のチェックとしよう。前提条件として保証できない。
> 1. 店員は、登録を指定する
> :
> 2. システムは、会員IDを作成する
身分証明書の住所と申込用紙に記載された住所のチェックは、店員による目視とする。
また、IDの発行は会員登録が成功した時に、自動的に振られるとしよう。
>シナリオ：山田太郎はレンタルビデオ店の会員になろうと申し込んだが
>身分証明書の住所と現住所が違うため認められず拒否された
これは登録前の目視での確認のため、システムでは行わない。
シナリオとしては、
山田太郎はレンタルビデオ店の会員になろうと申し込んだが、すでに登録済みだったため拒否された。
または、
山田太郎はレンタルビデオ店の会員になろうと申し込んだが、ブラックリストに入っていたため拒否された。
>事前条件 ：会員の情報が登録されていないこと
これは登録時のチェックとしよう。前提条件として保証できない。
> 1. 店員は、登録を指定する
> :
> 2. システムは、会員IDを作成する
身分証明書の住所と申込用紙に記載された住所のチェックは、店員による目視とする。
また、IDの発行は会員登録が成功した時に、自動的に振られるとしよう。
>シナリオ：山田太郎はレンタルビデオ店の会員になろうと申し込んだが
>身分証明書の住所と現住所が違うため認められず拒否された
これは登録前の目視での確認のため、システムでは行わない。
シナリオとしては、
山田太郎はレンタルビデオ店の会員になろうと申し込んだが、すでに登録済みだったため拒否された。
または、
山田太郎はレンタルビデオ店の会員になろうと申し込んだが、ブラックリストに入っていたため拒否された。
942 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/24(月) 19:31:37
以上でやってみて。
次は何やるのかな？
次は何やるのかな？
>>942
とりあえずお前に人の心がないのがよくわかった。
とりあえずお前に人の心がないのがよくわかった。
なんつーか、長文うんざり？
>>943
今更だろ。
今更だろ。
そいつが他力本願なくせに偉そうなのはいつものこと
とりあえず、他の人間は自分よりも格下だと思っていて、
一つ上の高所から話しかけているつもりなのは確かだな、
うだつのあがらないつまらん上司と同じような感じだな。
まとまりの無い内容で、その癖言っている事を大きくいって
誤魔化している辺りそっくりだな。
一つ上の高所から話しかけているつもりなのは確かだな、
うだつのあがらないつまらん上司と同じような感じだな。
まとまりの無い内容で、その癖言っている事を大きくいって
誤魔化している辺りそっくりだな。
>>934
簡単に言えばそういうこと。
世の中豚ばかりなのが現実なんだけど、
研究者みたいな偉い人にはそれがわからんのです。
っていうか、研究者は研究者で、とにかく新しい事を言わないと
食っていけないから必死なんだろうけどね。
最近のソフトウェア工学の研究なんてマッチポンプの典型ではないかと。
付き合う必要ないよ
簡単に言えばそういうこと。
世の中豚ばかりなのが現実なんだけど、
研究者みたいな偉い人にはそれがわからんのです。
っていうか、研究者は研究者で、とにかく新しい事を言わないと
食っていけないから必死なんだろうけどね。
最近のソフトウェア工学の研究なんてマッチポンプの典型ではないかと。
付き合う必要ないよ
950 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/25(火) 09:44:03
トップダウン男は提示した内容で問題ないか、みんなに聞いているのだから答えただけだ。
大きな点では問題ないと思うが、細かい点でいつくか問題があったので指摘した。
オマエラも、愚痴る暇があったら、少しは協力したらどうだ？
大きな点では問題ないと思うが、細かい点でいつくか問題があったので指摘した。
オマエラも、愚痴る暇があったら、少しは協力したらどうだ？
>>950
少なくともてめーにだけは協力しねー。てか何によ？
少なくともてめーにだけは協力しねー。てか何によ？
952 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/25(火) 19:05:56
>>951
協力しないと言いつつ、「何によ」と言うのは協力したいのが伺える。
また「何によ」と言っているが、少し考えれば分かる内容なので、951にも分かっていると思われる。
まあ俺からは、「出来る事をやれ」とだけ言っておこう。
協力しないと言いつつ、「何によ」と言うのは協力したいのが伺える。
また「何によ」と言っているが、少し考えれば分かる内容なので、951にも分かっていると思われる。
まあ俺からは、「出来る事をやれ」とだけ言っておこう。
お前は何も「できない」わけか。なるほど。
前、言っただろリピータ大事にしろと。
大体お前と話している奇特な奴なんてもういないぜ。
大体お前と話している奇特な奴なんてもういないぜ。
おじゃばが「OOAとOODが分からないから、まずはOOAから教えてください」って言ってるだけだろ。
出だしの在庫管理辺りからそう。
個人的にはそんなことはどうでも良くて、393が>>867で書いた開発プロセス。
そういうのがホントに確立されてるなら、なんつー名前なのか知りたいんだけど、
名前がないなら紹介されてるウェブページとかでもいい。
誰か知らない？393でなくても良いし。
要件定義で(ウォーターフォールなりRUPなりで言う)要件を定義しないで、
システム分析は設計工程に含まれの「概念」と「実装」に分かれるらしい。
そして>>871や>>891
分析、だそうだが、何を分析したいのかさっぱり分からない。
インプットは目的(これすら良く分からんけど)で、
アウトプットは業務要件と要素？
抽出した要素も、何に注目して抽出されたのか分からない。
抽出した要素の使い道も分からない。
誰か教えてくれないか？
それで、この後どうなるんだ？
出だしの在庫管理辺りからそう。
個人的にはそんなことはどうでも良くて、393が>>867で書いた開発プロセス。
そういうのがホントに確立されてるなら、なんつー名前なのか知りたいんだけど、
名前がないなら紹介されてるウェブページとかでもいい。
誰か知らない？393でなくても良いし。
要件定義で(ウォーターフォールなりRUPなりで言う)要件を定義しないで、
システム分析は設計工程に含まれの「概念」と「実装」に分かれるらしい。
そして>>871や>>891
分析、だそうだが、何を分析したいのかさっぱり分からない。
インプットは目的(これすら良く分からんけど)で、
アウトプットは業務要件と要素？
抽出した要素も、何に注目して抽出されたのか分からない。
抽出した要素の使い道も分からない。
誰か教えてくれないか？
それで、この後どうなるんだ？
>>955
どうもならねぇよ、糞が。いいかげんにしろ。
どうもならねぇよ、糞が。いいかげんにしろ。
まぁ、このスレ的には、OOは結局使いもんにならんことがわかって順調ってことじゃね？
ちゃんとわかってる人が作った図なら子一時間レビューすれば
仕様をある程度知ってるはずの顧客にはわかりやすく通じるがな
おじゃばみたいにぐだぐだ書かれると通じない
仕様をある程度知ってるはずの顧客にはわかりやすく通じるがな
おじゃばみたいにぐだぐだ書かれると通じない
おじゃばの性格からして、このスレは(オレの）オブジェクト指向は普及しないのか？だからな。
そもそも、処理中心の考えで組まなくちゃ逝けないプログラムって言うものがあるわけで、
でもC++でクラス使って一応オブジェクト指向の場合おじゃばは納得できるのだろうか？
そもそも、処理中心の考えで組まなくちゃ逝けないプログラムって言うものがあるわけで、
でもC++でクラス使って一応オブジェクト指向の場合おじゃばは納得できるのだろうか？
>>897の要件定義書もう見れないのか？誰かアップしてくれ
しかし、よく自社の要件定義書をさらしたよな、何処の会社か分かる奴いないの？
しかし、よく自社の要件定義書をさらしたよな、何処の会社か分かる奴いないの？
963 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/26(水) 23:04:02
>>955
確立された手法ではないと思う。
また詳細は記述内容から読み取れと言う事で、955の読み取った内容でいいと思う。
>>959
俺が普段設計する時は、要求仕様が決まったら、コーディングを開始する。
コーディングが終わったら機能仕様書に落とす。それでも他の人が機能仕様書だけを書くより早い。
>>961
クズと言うのは議論にも参加せずに、他人の非難ばかりする奴だろう？
確立された手法ではないと思う。
また詳細は記述内容から読み取れと言う事で、955の読み取った内容でいいと思う。
>>959
俺が普段設計する時は、要求仕様が決まったら、コーディングを開始する。
コーディングが終わったら機能仕様書に落とす。それでも他の人が機能仕様書だけを書くより早い。
>>961
クズと言うのは議論にも参加せずに、他人の非難ばかりする奴だろう？
964 ：仕様書無しさん：2008/03/27(木) 01:27:33
OO支持の方、OO設計はどうやって勉強すればいいですか？
参考になる本、サイトを教えてください
よろしくお願いします
参考になる本、サイトを教えてください
よろしくお願いします
965 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/27(木) 12:41:41
>>964
OO設計に確立された方法はない。
いや正確に言うと、いっぱいあるが、どれも何にでも使える適切な方法ではないと言う所だ。
試しに下記HPを読んでみるといい。
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html
俺俺天国が実感出来るだろう。
つまりこれは未知の分野と言う事だ。
未知の分野での学習のこつは、「実験」→「分析」の繰り返しになる。
OO設計に確立された方法はない。
いや正確に言うと、いっぱいあるが、どれも何にでも使える適切な方法ではないと言う所だ。
試しに下記HPを読んでみるといい。
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html
俺俺天国が実感出来るだろう。
つまりこれは未知の分野と言う事だ。
未知の分野での学習のこつは、「実験」→「分析」の繰り返しになる。
966 ：仕様書無しさん：2008/03/27(木) 16:56:59
>>932
>業務システムだと、そういう「お絵描き」よりもER図をしっかり書いてほしい。
結局今の業務システムの作り方ってDOAのままだよね
DBに保存する、DBからもってきて表示する、しかやってない
だから面倒なモデリングなんかするんなら人集めて作っちゃえ、ってなるわけで
OOで設計する方が時間がかかるのは例のOMT本にも書いてあるしね
メリットがないんだろうなあ
>業務システムだと、そういう「お絵描き」よりもER図をしっかり書いてほしい。
結局今の業務システムの作り方ってDOAのままだよね
DBに保存する、DBからもってきて表示する、しかやってない
だから面倒なモデリングなんかするんなら人集めて作っちゃえ、ってなるわけで
OOで設計する方が時間がかかるのは例のOMT本にも書いてあるしね
メリットがないんだろうなあ
967 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/27(木) 20:45:55
トップダウン男も撃沈か。
仕方ないので、俺がやってみる事にする。
結局、ユースケース→クラス図→クラス（コード）に出来ればいい訳だ。
ただユースケースからクラス図への変換の方法が分からないし、どこにも書いてない。
まあやってみるか。
とりあえずユースケース図をもう一度考えてみよう。
誰かがアクターは店員のみだと言っていたが、ビデオを借りて店員まで持って行くのは会員だし、
新しいビデオ持って来り、古いビデオを回収したりするのは業者だから、それもアクターにしようと思う。
ただシステムに直接触らずに、店員に対して動作を実行している。アクターに対して別のアクターが
ユースケースを出していいのだろうか？まずい気がするので、アクターとアクターの間にシステムを
噛ませようと思う。
例えば、会員はカウンターを通して店員にビデオ渡す。ビデオ返すのは返却ボックスとしよう。
業者は仕入れ棚と廃棄棚を通して作業することにしよう。
そして、カウンター、返却ボックス、仕入れ棚、廃棄棚をシステムの一部とする。
そうすれば、アクターとシステムの関係は保たれるだろう。
仕方ないので、俺がやってみる事にする。
結局、ユースケース→クラス図→クラス（コード）に出来ればいい訳だ。
ただユースケースからクラス図への変換の方法が分からないし、どこにも書いてない。
まあやってみるか。
とりあえずユースケース図をもう一度考えてみよう。
誰かがアクターは店員のみだと言っていたが、ビデオを借りて店員まで持って行くのは会員だし、
新しいビデオ持って来り、古いビデオを回収したりするのは業者だから、それもアクターにしようと思う。
ただシステムに直接触らずに、店員に対して動作を実行している。アクターに対して別のアクターが
ユースケースを出していいのだろうか？まずい気がするので、アクターとアクターの間にシステムを
噛ませようと思う。
例えば、会員はカウンターを通して店員にビデオ渡す。ビデオ返すのは返却ボックスとしよう。
業者は仕入れ棚と廃棄棚を通して作業することにしよう。
そして、カウンター、返却ボックス、仕入れ棚、廃棄棚をシステムの一部とする。
そうすれば、アクターとシステムの関係は保たれるだろう。
客に店舗でシステムを使わせんのかよ。また変な要件を出してきたな。
なんか、おじゃばはユースケース自体を理解してないっぽいな。またオレ流解釈か。
ユースケースの枠はシステム境界。アクターはシステムとやり取りをする人や物（別のシステム）。
つまり、システムと係わりのないものをアクターとすることは間違ってるし設定的にも意味がない。
だから、客や業者もアクターにするというなら、システムを使って何をやらせるつもりなのか、
まず要件を決めないと。
それと、ユースケースからクラス図が難しいと思うんだったらロバストネス図を書くのがおすすめ。
なんか、おじゃばはユースケース自体を理解してないっぽいな。またオレ流解釈か。
ユースケースの枠はシステム境界。アクターはシステムとやり取りをする人や物（別のシステム）。
つまり、システムと係わりのないものをアクターとすることは間違ってるし設定的にも意味がない。
だから、客や業者もアクターにするというなら、システムを使って何をやらせるつもりなのか、
まず要件を決めないと。
それと、ユースケースからクラス図が難しいと思うんだったらロバストネス図を書くのがおすすめ。
>>897からのレスないな
それより、なんか話が噛み合わないと思う、考えたが
俺は、オブジェクト指向の勉強の為に設計まで行なうから、ニュアンスが伝わればいいぐらに考えているが
「おじゃばさま」を始め何人かは、実際の業務で意識して、実装出来るレベルまで行なうと考えているのか？
それなら、アーキテクチャーやツールなども考えないと
それより、なんか話が噛み合わないと思う、考えたが
俺は、オブジェクト指向の勉強の為に設計まで行なうから、ニュアンスが伝わればいいぐらに考えているが
「おじゃばさま」を始め何人かは、実際の業務で意識して、実装出来るレベルまで行なうと考えているのか？
それなら、アーキテクチャーやツールなども考えないと
なんやろ
ひととおり恥をかかせてやるのがいんやろか？
ひととおり恥をかかせてやるのがいんやろか？
ヒント：恥をかくにも知能が居る。
972 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/28(金) 09:27:43
>>968
ユースケースは理解している。
システムを店のコンピュータと考えた場合、操作するのは店員のみだから客や業者がアクター出ないと
言うのも分かっているから、967を書いた訳だ。
もし、アクターを店員一人だとして、システムはDVDレンタルシステムだとすると、
アクターは、「店員」
ユースケースは「貸出し」「返却」「入荷」「廃棄」「会員登録」「会員修正」になるだろう。
この後にどうするのか分からない。クラス図に出来ない。無理にやれば単なる構造化設計になる。
良いやり方があるなら、968がやってくれよ。これをクラス図にしてくれ。
ロバストネス図とか言うのを使ってもいいから、クラス図にしてくれ。
ユースケースは理解している。
システムを店のコンピュータと考えた場合、操作するのは店員のみだから客や業者がアクター出ないと
言うのも分かっているから、967を書いた訳だ。
もし、アクターを店員一人だとして、システムはDVDレンタルシステムだとすると、
アクターは、「店員」
ユースケースは「貸出し」「返却」「入荷」「廃棄」「会員登録」「会員修正」になるだろう。
この後にどうするのか分からない。クラス図に出来ない。無理にやれば単なる構造化設計になる。
良いやり方があるなら、968がやってくれよ。これをクラス図にしてくれ。
ロバストネス図とか言うのを使ってもいいから、クラス図にしてくれ。
973 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/28(金) 09:43:32
>>970,971
知ったかぶった所で、誰もDVDレンタルの設計が出来なかった事には違いない。
出来ると言うならやってみな。ユースケースからクラス図を作る所だけでいいぞ。
出来ないのに知ったかぶってて、それがバレバレなのは恥ずかしいだろう？
あ、恥をかくにも知能がいるのだったか。
知ったかぶった所で、誰もDVDレンタルの設計が出来なかった事には違いない。
出来ると言うならやってみな。ユースケースからクラス図を作る所だけでいいぞ。
出来ないのに知ったかぶってて、それがバレバレなのは恥ずかしいだろう？
あ、恥をかくにも知能がいるのだったか。
オマエいつも口だけだな
煽るだけ煽って自分は何もできない
そんな人生でいいのか？
煽るだけ煽って自分は何もできない
そんな人生でいいのか？
975 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/28(金) 19:59:25
>>974
誰に言っている？自虐ネタか？
アクター一人でやる方法は思いつかないので、出来る奴に任せる。
あと、前から言っている通り、要求仕様は「ツタヤ店舗で最低限のDVDの貸し出し」だ。
ネットでレンタルとか面倒な事は考慮しなくていい。
まあ適切にOOで設計されていれば、後からネット対応にするのも簡単なのかもしれないが。
俺の方は、カウンターや入荷棚をシステムの一部として、客や業者をアクターにする事にする。
「システムに触る=コンピュータの操作をする」と言う解釈ではなく、カウンターにDVDを置くのも
システムに触ると言う解釈をすれば問題ないと思っている。
となると、アクターは、
「店員」「会員」「業者」になる。
システムは大きい括りでは「レンタルシステム」だが、先ほどアクターを追加したため、
中に「カウンター」「返却箱」「仕入れ棚」「廃棄棚」を含むとしよう。
上記オブジェクト分けしたとすると、レンタルシステムを構成する残りの要素も分類しよう。
あとは、「商品棚」「DVD」「料金表」こんな所だろうか。
手順としてシステムを要素に分割していいのか分からないが、とりあえずこれでやってみようかと思う。
システムは、「レンタルシステム」で、
構成要素は「カウンター」「返却箱」「仕入れ棚」「廃棄棚」「商品棚」「DVD」「料金表」とする。
誰に言っている？自虐ネタか？
アクター一人でやる方法は思いつかないので、出来る奴に任せる。
あと、前から言っている通り、要求仕様は「ツタヤ店舗で最低限のDVDの貸し出し」だ。
ネットでレンタルとか面倒な事は考慮しなくていい。
まあ適切にOOで設計されていれば、後からネット対応にするのも簡単なのかもしれないが。
俺の方は、カウンターや入荷棚をシステムの一部として、客や業者をアクターにする事にする。
「システムに触る=コンピュータの操作をする」と言う解釈ではなく、カウンターにDVDを置くのも
システムに触ると言う解釈をすれば問題ないと思っている。
となると、アクターは、
「店員」「会員」「業者」になる。
システムは大きい括りでは「レンタルシステム」だが、先ほどアクターを追加したため、
中に「カウンター」「返却箱」「仕入れ棚」「廃棄棚」を含むとしよう。
上記オブジェクト分けしたとすると、レンタルシステムを構成する残りの要素も分類しよう。
あとは、「商品棚」「DVD」「料金表」こんな所だろうか。
手順としてシステムを要素に分割していいのか分からないが、とりあえずこれでやってみようかと思う。
システムは、「レンタルシステム」で、
構成要素は「カウンター」「返却箱」「仕入れ棚」「廃棄棚」「商品棚」「DVD」「料金表」とする。
976 ：おじゃばさま ◆GxjxF3yEw6 ：2008/03/28(金) 20:35:43
さて次はユースケースを考えてみよう。
会員--（DVDを選ぶ）-->商品棚
会員--（DVDを持って行く）-->カウンター
会員<--（DVDを受け取る）--カウンター
会員--（DVDを返す）-->返却棚
会員--（延滞料金を払う）-->カウンター
会員<--（延滞警告される）--カウンター
こんな所か。入会処理を忘れていたが後で書こう。
店員<--（貸し出し条件のチェック）--カウンター
店員<--（返却条件のチェック）--返却棚
店員<--（延滞チェック）--カウンター
店員<--（仕入れチェック）--仕入れ棚
店員<--（廃棄チェック）--商品棚
こう見ると、店員はチェックばかりのようだ。バイトにも使わせるのを考えるとこれもいい。
ただ、仕入れる商品や数を決めたり、料金を変えたりするのを考えると、アクターに店長が必要かもしれない。。
業者--（納入）-->仕入れ棚
業者<--（廃棄）--廃棄棚
会員--（DVDを選ぶ）-->商品棚
会員--（DVDを持って行く）-->カウンター
会員<--（DVDを受け取る）--カウンター
会員--（DVDを返す）-->返却棚
会員--（延滞料金を払う）-->カウンター
会員<--（延滞警告される）--カウンター
こんな所か。入会処理を忘れていたが後で書こう。
店員<--（貸し出し条件のチェック）--カウンター
店員<--（返却条件のチェック）--返却棚
店員<--（延滞チェック）--カウンター
店員<--（仕入れチェック）--仕入れ棚
店員<--（廃棄チェック）--商品棚
こう見ると、店員はチェックばかりのようだ。バイトにも使わせるのを考えるとこれもいい。
ただ、仕入れる商品や数を決めたり、料金を変えたりするのを考えると、アクターに店長が必要かもしれない。。
業者--（納入）-->仕入れ棚
業者<--（廃棄）--廃棄棚
どうもおじゃばはレンタルビデオ屋シュミレータを作りたいらしい。
もしくはユースケースが理解出来ていないかどっちか。
もしくはユースケースが理解出来ていないかどっちか。
周りが言葉を失っている中、
延々とつづけるキチガイ。
延々とつづけるキチガイ。
ooという文字を見ていたら、
タコヤキが食べたくなりました。
タコヤキが食べたくなりました。
ユースケースが、「DVDを選ぶ」とか、「DVDを持って行く」とか
いまだかつてない壮大なレンタルシステムができそうだな。
つぅか、お節介すぎてウゼェよこんなシステム。
おじゃばはやっぱりユースケースをちゃんと勉強した方がいい。
まぁ勉強しても独自解釈しちゃうところは救いようがないんだが。
いまだかつてない壮大なレンタルシステムができそうだな。
つぅか、お節介すぎてウゼェよこんなシステム。
おじゃばはやっぱりユースケースをちゃんと勉強した方がいい。
まぁ勉強しても独自解釈しちゃうところは救いようがないんだが。
俺も素人だけど、
アクター「店員」に、ユースケース「貸出」、「返却」。
くらいじゃだめなん？
アクター「店員」に、ユースケース「貸出」、「返却」。
くらいじゃだめなん？
>>982
その程度でいいよ
ユースケースにはシステム化要件以外も入れたほうがいいから
アクター「客」も入れようぜ
プレゼンしやすいし
客 ー 店員 － システム、陳列棚、陳列外棚 くらいの図でOK
陳列棚は客と店員に繋ごう
要件と要求のちがいを踏まえたうえで書けばシステム対象外入れてもOK
点線でかこって今回のシステム化はここですよ～って示すといい
その程度でいいよ
ユースケースにはシステム化要件以外も入れたほうがいいから
アクター「客」も入れようぜ
プレゼンしやすいし
客 ー 店員 － システム、陳列棚、陳列外棚 くらいの図でOK
陳列棚は客と店員に繋ごう
要件と要求のちがいを踏まえたうえで書けばシステム対象外入れてもOK
点線でかこって今回のシステム化はここですよ～って示すといい
おじゃば次のスレ立てる用意しろよー。
オブジェクト指向設計は、
システムを構築する側の脳内をいかに整理整頓し利用者に
満足してもらえるシステムをいかに効率よく間違いなく必要十分に
かつメンテナンス性を高めて提供できるようにするかの方法論
の一つということ。
構築する側の頭の整理の仕方として効率のよい正確なものが
他にあればそれで代替されても別におかしくはない。当面まだ
オブジェクト指向の考え方が進化の最前線にいるということ
なのだろうか。
ちょっと日本語がおかしいな
>>983
店員が使うシステムに、客がDVDを選ぶとか、DVDを持っていくとか
店員からしてみればあたりまえすぎる行動を、ユースケース図に書かれても
焦点をぼかせるだけで逆効果じゃね？ 店員が使うわけだから、店員の関心事
（システム化の範囲、問題領域）にフォーカスすべき。だから、今回の件では
アクターに客はいらねべ？もちろんビデオ業者も。店員と管理者ぐらいが妥当。
店員が使うシステムに、客がDVDを選ぶとか、DVDを持っていくとか
店員からしてみればあたりまえすぎる行動を、ユースケース図に書かれても
焦点をぼかせるだけで逆効果じゃね？ 店員が使うわけだから、店員の関心事
（システム化の範囲、問題領域）にフォーカスすべき。だから、今回の件では
アクターに客はいらねべ？もちろんビデオ業者も。店員と管理者ぐらいが妥当。
おじゃばは「客が店に入る」とか「客がお金を払う」とかも
ユースケースに書きそうだな
ユースケースに書きそうだな
>>988
客が1万円札を出す、とか客が棚のDVDの配置を変える、とかまで入るかも
客が1万円札を出す、とか客が棚のDVDの配置を変える、とかまで入るかも
客がDVDのケースと中身を入れ替える とか 万引きする とか
起業から倒産までフォローして欲しい
客を装った強盗が刃物を持ってカウンタへ押し入る、とか
客がエロビデオをカウンターに持っていったら店員がかわいい女の子で気まずい思いをする、とか