●●オブジェクト設計は何故流行らないの？●●02
1 ：仕様書無しさん：
|
|
|
コテ禁止
3 ：仕様書無しさん：2007/01/24(水) 06:14:04
PEとかELFとかMach-Oに代わるものを設計するのか。
そりゃ流行らないだろうな。
そりゃ流行らないだろうな。
4 ：仕様書無しさん：2007/01/24(水) 12:04:04
機能単位じゃなくてオブジェクト単位で設計書書くと
「で、結局何ができるようになってるんだよ」というツッコミが
クライアントからくるからではないだろうか。
「で、結局何ができるようになってるんだよ」というツッコミが
クライアントからくるからではないだろうか。
そこでユースケースですよ
6 ：仕様書無しさん：2007/01/24(水) 15:48:38
ユースケースは、開発を通じて重要と言われているが、重要どころか
なくても言いと思う。
構造化設計で使われたDFDで十分だと思うべな。
DFDは、とってもわかりやすい。
構造化だ、オブジェクト指向だに関係なく普遍的にDFDマンセーでーす。
なくても言いと思う。
構造化設計で使われたDFDで十分だと思うべな。
DFDは、とってもわかりやすい。
構造化だ、オブジェクト指向だに関係なく普遍的にDFDマンセーでーす。
7 ：仕様書無しさん：2007/01/24(水) 15:58:10
>>6
タイミングがシビアなシステムを設計したことないの？
タイミングがシビアなシステムを設計したことないの？
>7
タイミングがシビアなシステムでユースケースをどうつかうの？
性能要求は機能外仕様なのでモロにユースケースの適用外だと思うけど。
タイミングがシビアなシステムでユースケースをどうつかうの？
性能要求は機能外仕様なのでモロにユースケースの適用外だと思うけど。
タイミングと応答速度を混同しとる奴がいるな。
オブジェクト指向厨
1970年代生まれに多くの症例を見受けられるシンドローム。
症状によって、以下の3段階に分類される。
中二OO病
すべてOO。何でも無理矢理OO。OOP最高！このころ書いたコードの保守は大変な場合が多い。OO厨が誰しも経験する、忘れがたい過去。
「コボラー」や「VB厨」をやたらに非難する。
高二OO病
中二OO病をネタにする人々。マジ中二OO病の人をウォッチしたりする。
OO的手法をやたらと毛嫌いする。（例：「デザインパターンなんて意味ねー」）
(別解?) やたらYAGNIとか現実解を強調してしまう。
大二OO病
OO厨でありつつも、DOA厨と敵対関係にならずに付き合いができる、すこし大人のOO厨。
http://d.hatena.ne.jp/keyword/OO%bf%df
1970年代生まれに多くの症例を見受けられるシンドローム。
症状によって、以下の3段階に分類される。
中二OO病
すべてOO。何でも無理矢理OO。OOP最高！このころ書いたコードの保守は大変な場合が多い。OO厨が誰しも経験する、忘れがたい過去。
「コボラー」や「VB厨」をやたらに非難する。
高二OO病
中二OO病をネタにする人々。マジ中二OO病の人をウォッチしたりする。
OO的手法をやたらと毛嫌いする。（例：「デザインパターンなんて意味ねー」）
(別解?) やたらYAGNIとか現実解を強調してしまう。
大二OO病
OO厨でありつつも、DOA厨と敵対関係にならずに付き合いができる、すこし大人のOO厨。
http://d.hatena.ne.jp/keyword/OO%bf%df
11 ：仕様書無しさん：2007/01/24(水) 16:59:48
>>7
タイミングはシーケンス図で書くもんだと思っていたが。。。
タイミングはシーケンス図で書くもんだと思っていたが。。。
俺もそう思う。
UML2.0ではタイミング図っていうのも一応あるぞ。
マイナーだし、シーケンス図で記述するタイミングとは
別のタイミングを記述するものだが。
マイナーだし、シーケンス図で記述するタイミングとは
別のタイミングを記述するものだが。
結局おまえらUMLすら使えない
何もわからない人達なんだな
スレ削除しろ
何もわからない人達なんだな
スレ削除しろ
15 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/24(水) 20:09:08
「データーを圧縮する一般的な方法は存在しない」
集合論で考えるとすぐ判る、数学の初歩だ。
さて、頭を数学的にきりかえて、ソフトウエア工学の問題点を指摘してみよう。
「ソフトウエアの設計の情報量はそれから作られるソースの情報量と等しいかそれよりも大きい」（ココ電球の定理）
なので設計とコーディングを分離する手法はうまく行かないのだ。
完全な設計とコーディングを分離すると重複作業が生じた上、コンパイルして実行したほうが早い物をわさわさ紙の上で何百倍もの時間をかけて
検証する事になってしまいコスト高である。
不完全な設計がまかり通るのはこれも原因だろうが
根本的な原因は工学一般の手法をそのままソフトウエアに持ってきてしまった事にある。
集合論で考えるとすぐ判る、数学の初歩だ。
さて、頭を数学的にきりかえて、ソフトウエア工学の問題点を指摘してみよう。
「ソフトウエアの設計の情報量はそれから作られるソースの情報量と等しいかそれよりも大きい」（ココ電球の定理）
なので設計とコーディングを分離する手法はうまく行かないのだ。
完全な設計とコーディングを分離すると重複作業が生じた上、コンパイルして実行したほうが早い物をわさわさ紙の上で何百倍もの時間をかけて
検証する事になってしまいコスト高である。
不完全な設計がまかり通るのはこれも原因だろうが
根本的な原因は工学一般の手法をそのままソフトウエアに持ってきてしまった事にある。
>>6
ユースケースってお客と話するときは結構便利かと思うが
ユースケースってお客と話するときは結構便利かと思うが
DFDは設計を表現するモデルで、ユースケースは機能を表現するモデルです。プロセス中心でソフトウェアを分解する場合にはとてもわかりやすく有用なモデルですが、ユースケースの代用にはなりません。
工学一般の手法を、、、に同意
19 ：仕様書無しさん：2007/01/24(水) 21:04:49
サンとインテルが手を組むのはJava派には朗報か？
Javaというとオブジェクト指向、オブジェクト指向というとJavaなので、
これでオブジェクト設計が普及するぞ。
Javaというとオブジェクト指向、オブジェクト指向というとJavaなので、
これでオブジェクト設計が普及するぞ。
20 ：Six Perfections：2007/01/24(水) 21:09:57 BE:998514959-2BP(0)
http://cocoa.gazo-ch.net/bbs/45/img/200701/1201505.jpg
http://pc10.2ch.net/test/read.cgi/tech/1169640060/
http://pc10.2ch.net/test/read.cgi/tech/1169640060/
21 ：仕様書無しさん：2007/01/24(水) 21:57:16
22 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/24(水) 22:11:02
普及すると給料下がるよ
そんなことより、前スレからの流れで
「オブジェクト指向とは何か？」でもやれば？
「オブジェクト指向とは何か？」でもやれば？
>>15
相手にされてないコテにレスするのも何だが
設計・分析もコーディングも自分で出来るレベルの人間なら
判ってるハズだ。優秀なPGほど、設計・分析の段階での
消費時間が多くなる。逆にコーディングの時間は減っていく。
そして、最終的に違ってくるのはデバッグ期間。
キチンと設計できる人間は既にそのままコーディングできるのが
当たり前だからな。人に任せるより自分で書いた方が早いんだけど
全部自分でやるわけにはいかないから、実装チームに任せる。
一人開発に慣れてると、どうにもならなくなるよ？
相手にされてないコテにレスするのも何だが
設計・分析もコーディングも自分で出来るレベルの人間なら
判ってるハズだ。優秀なPGほど、設計・分析の段階での
消費時間が多くなる。逆にコーディングの時間は減っていく。
そして、最終的に違ってくるのはデバッグ期間。
キチンと設計できる人間は既にそのままコーディングできるのが
当たり前だからな。人に任せるより自分で書いた方が早いんだけど
全部自分でやるわけにはいかないから、実装チームに任せる。
一人開発に慣れてると、どうにもならなくなるよ？
>>15
最後の一文は同意。
最後の一文は同意。
なんかコテの意見に追従するのが癪だが。
開発工程が(詳細)設計とコーディングに分かれているのは、
太古の昔にリソースが高価で使用するのに神に謁見するように
扱われていた名残に過ぎないと思う。
従って、現代は詳細レベルの仕様書作成とコーディングが並列する必然性はないと思う。
PCのリソース使って仕様書つくって、IDEでコーディングしているのはなんとも意味ない。
クラスのコード書いた奴がJava.docみたいなのを一緒においていけばそれでよし。
このスレでいう設計は実現機能の合意文書ってレベルのものじゃないか？
開発工程が(詳細)設計とコーディングに分かれているのは、
太古の昔にリソースが高価で使用するのに神に謁見するように
扱われていた名残に過ぎないと思う。
従って、現代は詳細レベルの仕様書作成とコーディングが並列する必然性はないと思う。
PCのリソース使って仕様書つくって、IDEでコーディングしているのはなんとも意味ない。
クラスのコード書いた奴がJava.docみたいなのを一緒においていけばそれでよし。
このスレでいう設計は実現機能の合意文書ってレベルのものじゃないか？
33 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/24(水) 23:55:28
２０００年から議論してて一向に話が進んでないけどな
>>27
>優秀なPGほど、設計・分析の段階での
>消費時間が多くなる。逆にコーディングの時間は減っていく。
>そして、最終的に違ってくるのはデバッグ期間。
いまだにそんな「都市伝説」を信じている奴がいるとは・・・
この世には、殆ど設計書を書かない
「オープンソース」なんてものがあるという現実は、
>>27 の頭の中では、どう整理されているんだろうか？
もしかして、
「きっと、彼らは優秀だから "頭の中" だけで設計出来るんだよ。
俺ら凡人には真似ができないけどさ・・・」なんて感じ？
>優秀なPGほど、設計・分析の段階での
>消費時間が多くなる。逆にコーディングの時間は減っていく。
>そして、最終的に違ってくるのはデバッグ期間。
いまだにそんな「都市伝説」を信じている奴がいるとは・・・
この世には、殆ど設計書を書かない
「オープンソース」なんてものがあるという現実は、
>>27 の頭の中では、どう整理されているんだろうか？
もしかして、
「きっと、彼らは優秀だから "頭の中" だけで設計出来るんだよ。
俺ら凡人には真似ができないけどさ・・・」なんて感じ？
>>34
そんなことはPGに任せておけばいいのにというような
詳細レベルの仕様書はワンサカ作ってるだけのSEがいるな。ｗ
// コーディングに限らず、NEなんかでも、
// 必死にIPアドレスの付番だけに躍起なる奴もいる。
確かにコードの組み方がマ逆^H^H真逆か・・・
そんなことはPGに任せておけばいいのにというような
詳細レベルの仕様書はワンサカ作ってるだけのSEがいるな。ｗ
// コーディングに限らず、NEなんかでも、
// 必死にIPアドレスの付番だけに躍起なる奴もいる。
確かにコードの組み方がマ逆^H^H真逆か・・・
37 ：仕様書無しさん：2007/01/25(木) 00:27:53
まあ下書き無しで描いてる漫画家とかいるけどね。
そういう人を引き合いに出すのはどうかと。
設計ちゃんとやった方がいいと思うけどな。
コード描けない奴が無駄に豪華なドキュメント描いてるのは無駄だが。
Linux作った奴の使ってる手法なんて、あのレベルの人間だから有効な方法だと思うよ。
そういう人を引き合いに出すのはどうかと。
設計ちゃんとやった方がいいと思うけどな。
コード描けない奴が無駄に豪華なドキュメント描いてるのは無駄だが。
Linux作った奴の使ってる手法なんて、あのレベルの人間だから有効な方法だと思うよ。
38 ：仕様書無しさん：2007/01/25(木) 00:31:05
オープンソースなんて図抜けて優秀な連中が、膨大な時間かけて論議と試行錯誤を繰り返して作ってるんだよ。
同じだけの知能も時間もないんだから、凡人はダメなりにでも
がんばってしっかり設計すべきだと思うね。
コーディングとデバッグ、テスト、運用、保守、バージョンアップ、とか
設計がしっかりしてないとどんどん壊れていって、収集つかなくなるし。
それが不要って思うのは、単に設計できてないだけかと。
同じだけの知能も時間もないんだから、凡人はダメなりにでも
がんばってしっかり設計すべきだと思うね。
コーディングとデバッグ、テスト、運用、保守、バージョンアップ、とか
設計がしっかりしてないとどんどん壊れていって、収集つかなくなるし。
それが不要って思うのは、単に設計できてないだけかと。
>>38
>オープンソースなんて図抜けて優秀な連中が、
>膨大な時間かけて論議と試行錯誤を繰り返して作ってるんだよ。
図抜けて優秀な連中でさえ、試行錯誤を繰り返すのに、
なぜか凡人は、最初の設計だけに時間を掛ければ、
後のコーディングはサラサラって感じで出来るよ、
って言いたいの？。
>オープンソースなんて図抜けて優秀な連中が、
>膨大な時間かけて論議と試行錯誤を繰り返して作ってるんだよ。
図抜けて優秀な連中でさえ、試行錯誤を繰り返すのに、
なぜか凡人は、最初の設計だけに時間を掛ければ、
後のコーディングはサラサラって感じで出来るよ、
って言いたいの？。
日本のプログラマの大半は料理人で言えばファーストフード店の厨房係レベルってこったね
単なる関数の塊みたいなクラス作ってる奴みると、
ちょっとは考えろと思う。
表に出てこない分には好きにしてくれだが。
こういう子にはOOP/OODは無理だなぁと判断してしまう。
ちょっとは考えろと思う。
表に出てこない分には好きにしてくれだが。
こういう子にはOOP/OODは無理だなぁと判断してしまう。
凡人が設計工程だけやってて十分な設計が出来るわけが無い。
凡人なら設計が正しいかどうか検証するために実装してテストして、
そこからフィードバックを得なきゃならんの。
っつーかオブジェクト指向関係無い話になってるし。
凡人なら設計が正しいかどうか検証するために実装してテストして、
そこからフィードバックを得なきゃならんの。
っつーかオブジェクト指向関係無い話になってるし。
43 ：仕様書無しさん：2007/01/25(木) 00:38:30
>>39
サラサラ出来るってどこに書いてあるか教えてくれるかな？
サラサラ出来るってどこに書いてあるか教えてくれるかな？
44 ：仕様書無しさん：2007/01/25(木) 00:40:05
プログラムと等価な詳細設計をOODできるのは当然のことなので、
基本設計をOODする場合を考えよう。
基本設計をOODする場合を考えよう。
47 ：仕様書無しさん：2007/01/25(木) 06:56:37
「優秀なPGは・・・」ではなくて、
無能なPGは行き当たりばったりでコードを書いて行き詰まるが、
そうでない奴にはそれがない。
という程度のことでは？
無能なPGは行き当たりばったりでコードを書いて行き詰まるが、
そうでない奴にはそれがない。
という程度のことでは？
49 ：仕様書無しさん：2007/01/25(木) 08:14:45
>>49
１人設計になれてると、機能分業開発に出会った時どうにもならなくなる。
１人設計になれてると、機能分業開発に出会った時どうにもならなくなる。
そこで口頭仕様ですよ
ボイスレコーダー用意！
もともと思いつきを口に出してるだけなので
聞き返す間も無く（口頭）仕様変更がおんどれらを襲う
聞き返す間も無く（口頭）仕様変更がおんどれらを襲う
54 ：おじゃばさま：2007/01/25(木) 09:26:40
>27
仮に優秀な設計者なら正しく設計して、コーディング時間もテスト時間も短縮出来るとしよう。
では優秀でない設計者の場合はどうすればいいのだろう？
大人数のプロジェクトをやるなら、優秀でない人も出来る方式でなければならないのではないだろうか？
一人で開発するなら別だが。
また優秀な設計者は、設計のみを繰り返していても優秀なままでいられるのだろうか？
27の理論を実践していると、設計者は設計のみを行い、コーディング／テストに関わらなくなる。
もしそれでも優秀さを維持出来るとしたら、世の中はコボル時代から現在までの大量の優秀な設計者で
溢れているのではないだろうか？
もし優秀さを維持出来ないとしたら、優秀だったとしてもそれを維持出来ないため、
優秀になりたての人しか正しく設計出来ないことになる。
つまり27の論理で成功するのは、ほんの一部のプロジェクトになってしまうのではないだろうか？
仮に優秀な設計者なら正しく設計して、コーディング時間もテスト時間も短縮出来るとしよう。
では優秀でない設計者の場合はどうすればいいのだろう？
大人数のプロジェクトをやるなら、優秀でない人も出来る方式でなければならないのではないだろうか？
一人で開発するなら別だが。
また優秀な設計者は、設計のみを繰り返していても優秀なままでいられるのだろうか？
27の理論を実践していると、設計者は設計のみを行い、コーディング／テストに関わらなくなる。
もしそれでも優秀さを維持出来るとしたら、世の中はコボル時代から現在までの大量の優秀な設計者で
溢れているのではないだろうか？
もし優秀さを維持出来ないとしたら、優秀だったとしてもそれを維持出来ないため、
優秀になりたての人しか正しく設計出来ないことになる。
つまり27の論理で成功するのは、ほんの一部のプロジェクトになってしまうのではないだろうか？
>>14
UMLは設計文書の共通書式だぞ。
UML自体は道具ではない。
従来バラバラだったり我流だった書式を統一して、他の人にも読みやすくするのが目的だ。
UMLに適切なものがなければ、独自の書式でも構わない。
なにも、不適切なほうに合せる必要はないんだよ。
UMLを使えば設計が上手にできるなんて思っている連中には理解できないことだが。
UMLは設計文書の共通書式だぞ。
UML自体は道具ではない。
従来バラバラだったり我流だった書式を統一して、他の人にも読みやすくするのが目的だ。
UMLに適切なものがなければ、独自の書式でも構わない。
なにも、不適切なほうに合せる必要はないんだよ。
UMLを使えば設計が上手にできるなんて思っている連中には理解できないことだが。
57 ：仕様書無しさん：2007/01/25(木) 11:08:00
>>35
オープンソースは設計書を書かないのではない。
ソースはオープンだが設計書はクローズド。
オープンソースのプロジェクトの大半は、たった一人で、もしくはチームで分担してコードを書いていて、
他の人達がコードに手を入れるといっても、バグの修正や、細かい部分の改良でしかない。
オープンソースは設計書を書かないのではない。
ソースはオープンだが設計書はクローズド。
オープンソースのプロジェクトの大半は、たった一人で、もしくはチームで分担してコードを書いていて、
他の人達がコードに手を入れるといっても、バグの修正や、細かい部分の改良でしかない。
59 ：仕様書無しさん：2007/01/25(木) 11:15:08
UMLの全部を使う必要はない。
大概の技術書も、UMLのクラス図とシーケンス図しか使ってない。
これで十分でしょ。
＞従来バラバラだったり我流だった書式を統一して、他の人にも読みやすくするのが目的だ。
クラス図とシーケンス図はこの目的のために使いましょう。
＞UMLに適切なものがなければ、独自の書式でも構わない。
＞なにも、不適切なほうに合せる必要はないんだよ。
独自の書式は賛成できない。
それがいいものなら、世に広めほしい。
大概の技術書も、UMLのクラス図とシーケンス図しか使ってない。
これで十分でしょ。
＞従来バラバラだったり我流だった書式を統一して、他の人にも読みやすくするのが目的だ。
クラス図とシーケンス図はこの目的のために使いましょう。
＞UMLに適切なものがなければ、独自の書式でも構わない。
＞なにも、不適切なほうに合せる必要はないんだよ。
独自の書式は賛成できない。
それがいいものなら、世に広めほしい。
>>54
大規模なプロジェクトを優秀でない設計者に設計させる時点で
終わってないか？
設計しかしなくなったとしても、プログラミング自体が趣味で
仕事とは関係なくコーディングする奴もそれなりにいると思うけど。
それに大手は知らないけど、ちょっとしたツールやコンバータが
必要になったら自分でちゃちゃっと書いちゃわないか？
コーディングする機会なんていくらでもあると思うが…
大規模なプロジェクトを優秀でない設計者に設計させる時点で
終わってないか？
設計しかしなくなったとしても、プログラミング自体が趣味で
仕事とは関係なくコーディングする奴もそれなりにいると思うけど。
それに大手は知らないけど、ちょっとしたツールやコンバータが
必要になったら自分でちゃちゃっと書いちゃわないか？
コーディングする機会なんていくらでもあると思うが…
>>59
> 独自の書式は賛成できない。
> それがいいものなら、世に広めほしい。
何にでも使える「万能ナイフ」よりも、
特定の狭い応用領域に最適化されたものを
選んだほうが良い結果になることもある、ということだよ。
>>60
仕事で設計したものを実装するためのコードと、
趣味のコードや自分でちゃっちゃと書くコードは、
かなり違うと思うのですが、どうでしょう。
趣味のプログラミング歴10年とかいう新人を想像してみてよ。
> 独自の書式は賛成できない。
> それがいいものなら、世に広めほしい。
何にでも使える「万能ナイフ」よりも、
特定の狭い応用領域に最適化されたものを
選んだほうが良い結果になることもある、ということだよ。
>>60
仕事で設計したものを実装するためのコードと、
趣味のコードや自分でちゃっちゃと書くコードは、
かなり違うと思うのですが、どうでしょう。
趣味のプログラミング歴10年とかいう新人を想像してみてよ。
全然関係ないけど、日本の大抵のプロジェクトは優秀でない設計者（SE）で溢れてるよな
SEって言葉自体何なんだ？Business Analysts?Software Analyst?Consultant?
SEって言葉自体何なんだ？Business Analysts?Software Analyst?Consultant?
>27
設計が良ければたしかにコーディング期間は短くなるだろう。
言葉の上ではたしかにそうだが、
コーディング期間を短くした割合と比較しての効果を考えると
途端に嘘くさくなる。
まずその部分を論理的に証明できないと、
都市伝説と言われても仕方ないな。
仮に、コーディングと設計を完全に分けれたらの話だけどな。
設計が良ければたしかにコーディング期間は短くなるだろう。
言葉の上ではたしかにそうだが、
コーディング期間を短くした割合と比較しての効果を考えると
途端に嘘くさくなる。
まずその部分を論理的に証明できないと、
都市伝説と言われても仕方ないな。
仮に、コーディングと設計を完全に分けれたらの話だけどな。
65 ：仕様書無しさん：2007/01/25(木) 17:08:43
逆に、コーディングと設計を分けられないってのは何だ？
スパイラルとかしてるからOKだと思ってるんかい？
スパイラルとかしてるからOKだと思ってるんかい？
>65
言葉の上では必ず分けられる。
実際でも、要求仕様が確定していれば
先に設計を済ましてからコーディングの形でも可能だろう。
しかし、現実にそんなプロジェクトは
ほとんどないだろ。
つまり、そういうこと。
言葉の上では必ず分けられる。
実際でも、要求仕様が確定していれば
先に設計を済ましてからコーディングの形でも可能だろう。
しかし、現実にそんなプロジェクトは
ほとんどないだろ。
つまり、そういうこと。
67 ：仕様書無しさん：2007/01/25(木) 17:29:23
現実ないわけではない、貴方が知らないだけ。
設計レビュー絶対のところは幾らでもあるわけで。
設計レビュー絶対のところは幾らでもあるわけで。
最初から完璧な設計を仕上げるのは不可能だけど、本コーディング前に
時間をかけてある程度の見通しを付ける作業は無駄にはならないよっていう
ごく当たり前の話なのに、オマイラはなんでそんなに突っかかるんだ？
時間をかけてある程度の見通しを付ける作業は無駄にはならないよっていう
ごく当たり前の話なのに、オマイラはなんでそんなに突っかかるんだ？
口頭仕様とノリだけでいままでやってきたからじゃないの
>68
決め付ける様な類の話は
デマか若しくは間違いを多く含んだ
悪質な話の事が多い。
って事は経験から学んだな、俺は。
あと、現実に役に立たない類の青臭い話も
俺はあまり好きじゃないかな。
決め付ける様な類の話は
デマか若しくは間違いを多く含んだ
悪質な話の事が多い。
って事は経験から学んだな、俺は。
あと、現実に役に立たない類の青臭い話も
俺はあまり好きじゃないかな。
71 ：おじゃばさま：2007/01/25(木) 18:53:14
>60
俺の記述が悪かった。
優秀でないと言うより「普通の設計者」でも、安心して設計出来る必要があると言う事だ。
またコーディングついてだが、第一に自分の設計した業務に対するコーディングでないと意味がない。
第二に機会があるかないか不確定な要素を頼りにするのは、仕事としては危険である。
>68
時間を掛けて見通しをつける作業が無駄だと思っている。
なぜアタリマエなのか理由を知りたい。
俺の記述が悪かった。
優秀でないと言うより「普通の設計者」でも、安心して設計出来る必要があると言う事だ。
またコーディングついてだが、第一に自分の設計した業務に対するコーディングでないと意味がない。
第二に機会があるかないか不確定な要素を頼りにするのは、仕事としては危険である。
>68
時間を掛けて見通しをつける作業が無駄だと思っている。
なぜアタリマエなのか理由を知りたい。
72 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/25(木) 19:07:49
Ｊａｖａを売り物にしている上場企業の社長の話だが
俺がフレームワークのインターフェース先に決めて分業しようとしたら、その社長
「中はどうなってるんだ」
「インターフェースだから中身はありません それぞれの担当者が決めるのです」
といったんだか、その社長、インターフェースの概念を理解できなくて「中身を作れ」
という無理な命令が飛んできて、そのままフィロソフィーもなくだらだらと中身を作って失敗した例をあげておこう。
偉い人が馬鹿だとどうしようもない。
俺がフレームワークのインターフェース先に決めて分業しようとしたら、その社長
「中はどうなってるんだ」
「インターフェースだから中身はありません それぞれの担当者が決めるのです」
といったんだか、その社長、インターフェースの概念を理解できなくて「中身を作れ」
という無理な命令が飛んできて、そのままフィロソフィーもなくだらだらと中身を作って失敗した例をあげておこう。
偉い人が馬鹿だとどうしようもない。
73 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/25(木) 19:12:12
今まで見た自称「俺は設計できる」ってやつが大抵そんなんだった。
いい加減コテどもは消えてくれ
75 ：おじゃばさま：2007/01/25(木) 19:20:24
設計の話になると必ず出て来るUML。しかしこれが成功しているとは、お世辞にも言い難い。
ユースケース図は子供の落書きと馬鹿にされ、クラス図はほとんどがソースからの自動生成。
その他の大量の書式は、UML入門書でしか使われず、辛うじてシーケンス図が使われる程度である。
元々、UMLの目的はプログラムを図表化事にある。
UMLが出初めの頃、ユースケース図、シーケンス図、クラス図、その他いくつかの表を使って
設計した事がある。しかし実際に設計してみて、なにかピンと来ない。
理由は1つのプログラムでも、UMLの書式は目的によって複数あるため、表現しきれないからだった。
UMLの特徴として、使いにくければ勝手に書式を作り、UMLだと言い張って良いと言うルールがある。
そこで既存のフォーマットにとらわれず、自由に書いてみる事にした。
その時は数人の設計者がいたので、それぞれ自由に書いてみることにした。
当然、内容はバラバラになった。
興味深いのは、それぞれは自分の設計書は見やすいと思っているが、他人の設計書は
確かにそれなりにいいと思うが、なにかが足りないと感じていた事だ。
つまり人によって重視するポイントが違うため、他人とはどこかが違うと感じるようだった。
そこて、重視するポイントを明確にしてやってみた。
ところがそれでも失敗した。
ユースケース図は子供の落書きと馬鹿にされ、クラス図はほとんどがソースからの自動生成。
その他の大量の書式は、UML入門書でしか使われず、辛うじてシーケンス図が使われる程度である。
元々、UMLの目的はプログラムを図表化事にある。
UMLが出初めの頃、ユースケース図、シーケンス図、クラス図、その他いくつかの表を使って
設計した事がある。しかし実際に設計してみて、なにかピンと来ない。
理由は1つのプログラムでも、UMLの書式は目的によって複数あるため、表現しきれないからだった。
UMLの特徴として、使いにくければ勝手に書式を作り、UMLだと言い張って良いと言うルールがある。
そこで既存のフォーマットにとらわれず、自由に書いてみる事にした。
その時は数人の設計者がいたので、それぞれ自由に書いてみることにした。
当然、内容はバラバラになった。
興味深いのは、それぞれは自分の設計書は見やすいと思っているが、他人の設計書は
確かにそれなりにいいと思うが、なにかが足りないと感じていた事だ。
つまり人によって重視するポイントが違うため、他人とはどこかが違うと感じるようだった。
そこて、重視するポイントを明確にしてやってみた。
ところがそれでも失敗した。
76 ：仕様書無しさん：2007/01/25(木) 19:24:19
OSカーネル 非OO
ドライバ 非OO
カリカリミドル 非OO
業務アプリ 糞OO とろーりもっさりどろどろどろろろろろ
ドライバ 非OO
カリカリミドル 非OO
業務アプリ 糞OO とろーりもっさりどろどろどろろろろろ
77 ：仕様書無しさん：2007/01/25(木) 19:37:14
シーケンス図とクラス図くらいしか使ったこと無いよ。
ユースケースなんて見たことも無い。
しかしUMLうんぬん言う前に要件定義はきっちり済んでるのか？！
後から前提条件ひっくり返されたらどんな設計やってても意味が無い。
それにUMLで設計できる（または読める）ような人は、機能仕様から
ごりごりクラス作ってったほうが早いんじゃ無かろうか？
ユースケースなんて見たことも無い。
しかしUMLうんぬん言う前に要件定義はきっちり済んでるのか？！
後から前提条件ひっくり返されたらどんな設計やってても意味が無い。
それにUMLで設計できる（または読める）ような人は、機能仕様から
ごりごりクラス作ってったほうが早いんじゃ無かろうか？
78 ：おじゃばさま：2007/01/25(木) 19:40:25
出来た仕様書はどこかがイメージと違う。みんながそんな意見だった。
ではプログラミングのイメージとは何か？それを考えてみた。
俺は寝ている時や、考え事をしている時に、ふとプログラムを思いつく事がある。
そういう時には妙な図形としてイメージが浮かぶ。たとえば翼を広げた鳥のような形などだ。
通常意識してプログラミングしている時には、ソースコードとして思いつくプログラムだが、
無意識の時、つまりソースコードになる前には、俺は妙な図形として意識しているのかもしれないと思った。
そこで、先程書いたみんなのオリジナルUMLを見てみた。
そう、これが脳の中のプログラムイメージなのだ。
まさに千差万別。文字ベースもあれば、カラフルな図形もある。
吹き出しが大量に記述されたマンガのような物もあれば、線ばかりの水道管設計図のようなものもある。
つまり、人の脳内のプログラムは千差万別で、統一出来ないと言う事だった。
ではプログラミングのイメージとは何か？それを考えてみた。
俺は寝ている時や、考え事をしている時に、ふとプログラムを思いつく事がある。
そういう時には妙な図形としてイメージが浮かぶ。たとえば翼を広げた鳥のような形などだ。
通常意識してプログラミングしている時には、ソースコードとして思いつくプログラムだが、
無意識の時、つまりソースコードになる前には、俺は妙な図形として意識しているのかもしれないと思った。
そこで、先程書いたみんなのオリジナルUMLを見てみた。
そう、これが脳の中のプログラムイメージなのだ。
まさに千差万別。文字ベースもあれば、カラフルな図形もある。
吹き出しが大量に記述されたマンガのような物もあれば、線ばかりの水道管設計図のようなものもある。
つまり、人の脳内のプログラムは千差万別で、統一出来ないと言う事だった。
>>78
ほんで？UMLｲﾗﾈってことか？
ほんで？UMLｲﾗﾈってことか？
81 ：仕様書無しさん：2007/01/25(木) 21:27:45
オブジェト設計が流行らない理由
１）クラス図、シーケンス図までかけるSEが少ない。
２）クラス図、シーケンス図を理解できるプログラマーが皆無に近い。
３）根本的にオブジェクト設計の重要なポイントを理解している者自体が少ない。
４）教育のための時間が、個人的にも、企業的にもない。
５）したがって、オブジェクト設計の利用価値を知らないわけですから、別に使う気にならない。
異常じゃない、以上。乙彼！！
１）クラス図、シーケンス図までかけるSEが少ない。
２）クラス図、シーケンス図を理解できるプログラマーが皆無に近い。
３）根本的にオブジェクト設計の重要なポイントを理解している者自体が少ない。
４）教育のための時間が、個人的にも、企業的にもない。
５）したがって、オブジェクト設計の利用価値を知らないわけですから、別に使う気にならない。
異常じゃない、以上。乙彼！！
設計時にシーケンス図書くのは時間の無駄だろ。
84 ：仕様書無しさん：2007/01/25(木) 21:37:00
>>84
なんか役にたつ？
なんか役にたつ？
フローチャート最強だろ、これを描かないPGいないだろ
いつも脳内で描いてるだろ、も ま え ら、ネ
いつも脳内で描いてるだろ、も ま え ら、ネ
87 ：仕様書無しさん：2007/01/25(木) 21:50:09
フローチャートなんぞプログラミング言語で記述すりゃええ
void function() {
doHoge();
doHage();
while(true) {
doHagege() ;
}
}
妙な図を使って書くより何をやってるかよくわかるってもんだろ。
void function() {
doHoge();
doHage();
while(true) {
doHagege() ;
}
}
妙な図を使って書くより何をやってるかよくわかるってもんだろ。
シーケンス図とかフローチャート書くより、コード書いたほうが速いし。
>>87
そして、ユースケースで確認すればプログラム完了、めでたし、めでたし
そして、ユースケースで確認すればプログラム完了、めでたし、めでたし
ユースケースドリブンってくらいだから、ユースケースの方が先だr
92 ：仕様書無しさん：2007/01/25(木) 21:59:11
しかしなんでお前らはUMLとかの単なる表記法がそんなに大好きなのかね。
オブジェクト指向とは何かってことを正しく理解して、
オブジェクト指向の利点を正しく扱えるようになることを目指すほうが重要じゃないか？
オブジェクト指向とは何かってことを正しく理解して、
オブジェクト指向の利点を正しく扱えるようになることを目指すほうが重要じゃないか？
＞UMLとかの単なる表記法がそんなに大好き
好きな奴がいなそうに見えるが。
好きな奴がいなそうに見えるが。
95 ：仕様書無しさん：2007/01/25(木) 22:16:16
96 ：仕様書無しさん：2007/01/25(木) 22:19:40
うちの会社じゃみんなUMLの本を片手に設計やってるが、
オブジェクト指向をわかってないからとんでもない事態になってるぞ。
あれでプログラム書かされる奴がかわいそうだ。
オブジェクト指向をわかってないからとんでもない事態になってるぞ。
あれでプログラム書かされる奴がかわいそうだ。
97 ：仕様書無しさん：2007/01/25(木) 22:24:17
99 ：仕様書無しさん：2007/01/25(木) 22:31:57
まるで珍問答みたいだな
こりゃダメだ
こりゃダメだ
>>61,71
趣味のコーディングだろうが、長い目で見れば役に立たないことは
ないよ。むしろ業務だけでしかコーディングしてないと幅がなくなる。
俺は一応15年以上キャリアあるおっさんだけど、単に遊びで作った
ようなものが活きてくるなんてことはいくらでもあるよ。
ネットワークシステムとかシミュレーションとか。もちろんすぐに
効いてくるようなもんじゃないけどね。
>>64
完全に分けるとか、そんなことの前に自分で試せば判ることでしょ。
自分の研究時間にでも１人で設計からコーディングまでできる規模の
テーマ決めて、通常自分がコーディングにかけてきた時間の何割かを
回して作って見ればいい。
それでも全体としての効果は薄いと判断するなら、君にとっては
都市伝説だと判断すればいいだろ。
趣味のコーディングだろうが、長い目で見れば役に立たないことは
ないよ。むしろ業務だけでしかコーディングしてないと幅がなくなる。
俺は一応15年以上キャリアあるおっさんだけど、単に遊びで作った
ようなものが活きてくるなんてことはいくらでもあるよ。
ネットワークシステムとかシミュレーションとか。もちろんすぐに
効いてくるようなもんじゃないけどね。
>>64
完全に分けるとか、そんなことの前に自分で試せば判ることでしょ。
自分の研究時間にでも１人で設計からコーディングまでできる規模の
テーマ決めて、通常自分がコーディングにかけてきた時間の何割かを
回して作って見ればいい。
それでも全体としての効果は薄いと判断するなら、君にとっては
都市伝説だと判断すればいいだろ。
>>101
レシーバーがないから無理ｗ
レシーバーがないから無理ｗ
103 ：仕様書無しさん：2007/01/25(木) 22:46:54
IBMの人は、オブジェクト設計をRational(?)でバリバリですか？
IBMだけどEAつかってます
>100
別スレができたみたいだな。
まず、そっちで説得してみせてくれ。
別スレができたみたいだな。
まず、そっちで説得してみせてくれ。
ていうかさ、ここに来るOODやってる人って実装上のアイデアで
少しトリッキーなクラス設計することとかないの？
いやダメかも知れんが、OSやハードの特殊性があるのが現状で、
サブセットなんていくらでもあるでしょ。
そういう時はその特殊性を活かせるように通常１つのクラスに
個別に置くようなものを横断的なクラス作ったりしない？
それはアスペクト志向だからって言われちゃうとそれまでだけどｗ
結果的に１つの特殊なクラスで隠蔽できればいいわけで、マルチ
プラットフォームで書いてるつもりが、パフォーマンスの問題とかで
その都度手直しするより上手く行くことって多いと思うんだが…
少しトリッキーなクラス設計することとかないの？
いやダメかも知れんが、OSやハードの特殊性があるのが現状で、
サブセットなんていくらでもあるでしょ。
そういう時はその特殊性を活かせるように通常１つのクラスに
個別に置くようなものを横断的なクラス作ったりしない？
それはアスペクト志向だからって言われちゃうとそれまでだけどｗ
結果的に１つの特殊なクラスで隠蔽できればいいわけで、マルチ
プラットフォームで書いてるつもりが、パフォーマンスの問題とかで
その都度手直しするより上手く行くことって多いと思うんだが…
108 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/27(土) 05:46:46
>>98
わかってたら使わないと思う
わかってたら使わないと思う
氏ね屑コテ
110 ：仕様書無しさん：2007/01/27(土) 09:10:26
このスレの特徴
Javaが好き(当然業務開発オンリー)
↓
OOPが好き(つうかJavaやってます「エヘン」とえばれる唯一の砦)
↓
すこし経験つんだ(フレームワークの隙間コードとSQLから取得したコードの代入ばかりだが)
↓
設計について薀蓄したい(上昇志向はとりあえずある)
↓
UMLはいいぞと思う(UMLの設計者は大規模な設計をやるには向かないと公言しているのを知らない)
↓
大規模ビジネスロジックをなんでもかんでもUMLでやろうとする
↓
破綻する
↓
わけわかんなくなる
↓
このスレが立った
Javaが好き(当然業務開発オンリー)
↓
OOPが好き(つうかJavaやってます「エヘン」とえばれる唯一の砦)
↓
すこし経験つんだ(フレームワークの隙間コードとSQLから取得したコードの代入ばかりだが)
↓
設計について薀蓄したい(上昇志向はとりあえずある)
↓
UMLはいいぞと思う(UMLの設計者は大規模な設計をやるには向かないと公言しているのを知らない)
↓
大規模ビジネスロジックをなんでもかんでもUMLでやろうとする
↓
破綻する
↓
わけわかんなくなる
↓
このスレが立った
経緯と特徴は同じですかい
>>70
現実にそぐわない理想論だといって、
最初から合格点より下を(無意識に)狙う人達には、
現状を少しずつでも改善する気すらないということでウンザリする。
理想が見えていなければ、理想に向かって進むことはできない。
ほんの少しでいいから向上心を持って、より良い方向に少しずつ動くべきだよ。
現実にそぐわない理想論だといって、
最初から合格点より下を(無意識に)狙う人達には、
現状を少しずつでも改善する気すらないということでウンザリする。
理想が見えていなければ、理想に向かって進むことはできない。
ほんの少しでいいから向上心を持って、より良い方向に少しずつ動くべきだよ。
>112
俺は再設計するのは全然問題ないと思っている。
時間の消費は
詳細まで設計を書面で叩いてからコーディング＞コーディングしながら再設計
と俺は考えるから。
設計上の問題もコーディング上で浮上しやすいしな。
適当なコード書いて誤魔化すのは問題が多いけど、
有用な場合も少なからずあるからな。
大抵は時間が絡んでの事だけど。
いまどきはMSを含む大抵のメーカーが
してるんじゃないか。
俺は再設計するのは全然問題ないと思っている。
時間の消費は
詳細まで設計を書面で叩いてからコーディング＞コーディングしながら再設計
と俺は考えるから。
設計上の問題もコーディング上で浮上しやすいしな。
適当なコード書いて誤魔化すのは問題が多いけど、
有用な場合も少なからずあるからな。
大抵は時間が絡んでの事だけど。
いまどきはMSを含む大抵のメーカーが
してるんじゃないか。
>113
理想はあっても時間は限られている訳で。
理想と現実が離れていればいる程
現実との擦りあわせは考えないと駄目だろ。
パッチ当てたり、機能限定バージョンにしたりな。
完成型が決まっていたとしても
今どき普通に開発できるのは
よっぽど恵まれているか
ボランティアのところだけ。
理想はあっても時間は限られている訳で。
理想と現実が離れていればいる程
現実との擦りあわせは考えないと駄目だろ。
パッチ当てたり、機能限定バージョンにしたりな。
完成型が決まっていたとしても
今どき普通に開発できるのは
よっぽど恵まれているか
ボランティアのところだけ。
118 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/27(土) 14:56:41
最近休日にいやる事と言えば OO厨と朝鮮人と大阪人と関空叩く事くらいかな
119 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/27(土) 14:57:04
誤爆
>117
それを言うなら
そもそも、理想を持ってないとか
合格点より下云々の話からすでに的外れだ。
それを言うなら
そもそも、理想を持ってないとか
合格点より下云々の話からすでに的外れだ。
121 ：仕様書無しさん：2007/01/27(土) 15:19:12
ふじつうが、JavaでCOBOLﾌﾟﾛｸﾞﾗﾐﾝｸﾞするから。
タコフレームワークを強要されて困ってまつ。
”やさしい”と言う名のフレームワークにはご用心。
タコフレームワークを強要されて困ってまつ。
”やさしい”と言う名のフレームワークにはご用心。
>>120
チーム内で相互にコードレビューさせてほしいと言っても、
コードレビューしないで糞コードを堆積させたほうが早いからダメ
なんていう上司がいるんですよ。
後で困らないコードを書く一人前よりも、
とにかく糞コードを大量生産する新人のほうが、
重宝されることもあるよね。
チーム内で相互にコードレビューさせてほしいと言っても、
コードレビューしないで糞コードを堆積させたほうが早いからダメ
なんていう上司がいるんですよ。
後で困らないコードを書く一人前よりも、
とにかく糞コードを大量生産する新人のほうが、
重宝されることもあるよね。
>122
アンカー付いてたから誤解した。
すんまそん。
アンカー付いてたから誤解した。
すんまそん。
何も悩んでないならいいんだよ。
結果残せるかどうかでしょ？それは一時的な無理とかじゃなくて…
OODでやろうがその結果が上手く行かなかったら、自分の設計が
ダメだっただけじゃないか。そうやって成長して行くんじゃないの？
理想的な設計を理論で学ぶのは重要だよ。でもその理論と現実の
整合性を取れない奴はチーム率いて行けないよな？
設計ってのはその後の開発工程のすべてを左右するんだからさ。
逆に現実との整合性ばかり考えてる奴はチームを成長させられ
ないでしょ？自分自身が仮にも掴んだと思えるOOをどう現実の
仕事に活かして行くかは、設計・分析段階ですべてが決まるとか、
逆にコーディングしなきゃ何も始まらない、とか単純に考えてる
ステレオタイプの思考してる人間には無理。
自分のステータスが重要ってだけでOOD絶対だの、その逆を
語る奴が多すぎると思うよ。
結果残せるかどうかでしょ？それは一時的な無理とかじゃなくて…
OODでやろうがその結果が上手く行かなかったら、自分の設計が
ダメだっただけじゃないか。そうやって成長して行くんじゃないの？
理想的な設計を理論で学ぶのは重要だよ。でもその理論と現実の
整合性を取れない奴はチーム率いて行けないよな？
設計ってのはその後の開発工程のすべてを左右するんだからさ。
逆に現実との整合性ばかり考えてる奴はチームを成長させられ
ないでしょ？自分自身が仮にも掴んだと思えるOOをどう現実の
仕事に活かして行くかは、設計・分析段階ですべてが決まるとか、
逆にコーディングしなきゃ何も始まらない、とか単純に考えてる
ステレオタイプの思考してる人間には無理。
自分のステータスが重要ってだけでOOD絶対だの、その逆を
語る奴が多すぎると思うよ。
そういうどっち付かずで中身のない正論はこういうスレでは面白くないからいらない。
>127
同意。
受け取り方次第でどうとでも解釈できる文章なので
そもそも書き込み自体に意味がないな。
良さそうな事を言ってるだけに残念。
同意。
受け取り方次第でどうとでも解釈できる文章なので
そもそも書き込み自体に意味がないな。
良さそうな事を言ってるだけに残念。
>126は相対的な視点で疑問形が多いのが残念
経験則のほうが説得力ある。少なくともこのスレでは。
経験則のほうが説得力ある。少なくともこのスレでは。
設計の詰めの甘さを後悔して、次は失敗してたまるものかと思うからこそ、何かを求めるわけで。
理想ばっか言ったり現実ばっか言ってるより、両方の狭間で
苦しんでるやつのが発展性あると思われ
苦しんでるやつのが発展性あると思われ
>>126に嫉妬
134 ：おじゃばさま：2007/01/29(月) 10:27:06
>79
本来の使い方である「プログラムを図表化し、相手に伝えるためのUML」は不要だ。
しかし別の用途がある。
1.ドキュメント形式が決まってないプロジェクトで、書式についてもめた時に適当なUMLを提示して、
「これが業界標準のUMLですよ。知らないのですか？」とハッタリをかます。
2.プログラミングに詰まった時に、自分の考えを整理するために使う。
3.プログラムのイメージが掴めない新人PGへの研修資料として、色々なUMLを見せて参考にさせる。
本来の使い方である「プログラムを図表化し、相手に伝えるためのUML」は不要だ。
しかし別の用途がある。
1.ドキュメント形式が決まってないプロジェクトで、書式についてもめた時に適当なUMLを提示して、
「これが業界標準のUMLですよ。知らないのですか？」とハッタリをかます。
2.プログラミングに詰まった時に、自分の考えを整理するために使う。
3.プログラムのイメージが掴めない新人PGへの研修資料として、色々なUMLを見せて参考にさせる。
>>134
１．の使い方はアリ。
１．の使い方はアリ。
136 ：おじゃばさま：2007/01/29(月) 19:06:16
>123
「コードレビュー」がダメと言っているのか、「相互コードレビュー」がダメと言っているのかによるが、
「相互」コードレビューがダメと言っているなら、その上司は正しい。
それはコードレビューはリーダーが全コードを見ればいいだけで、相互に行うのは時間の無駄だからだ。
「また後で困らないコード～」の意味する物が不明だが、クラスの共通化を初期の段階で行う事を
目指しているなら、状況によるが大量のコードを書かせる方が効率がいい場合が多い。
特にメンバーに新人が多い場合である。しかしこの場合、上級者によるチェックは必須である。
「コードレビュー」がダメと言っているのか、「相互コードレビュー」がダメと言っているのかによるが、
「相互」コードレビューがダメと言っているなら、その上司は正しい。
それはコードレビューはリーダーが全コードを見ればいいだけで、相互に行うのは時間の無駄だからだ。
「また後で困らないコード～」の意味する物が不明だが、クラスの共通化を初期の段階で行う事を
目指しているなら、状況によるが大量のコードを書かせる方が効率がいい場合が多い。
特にメンバーに新人が多い場合である。しかしこの場合、上級者によるチェックは必須である。
137 ：おじゃばさま：2007/01/29(月) 19:55:11
>126
実装先行か論理先行かの違いだと思う。
理想的な学習方法は「実装研究（1年半）」→「論理学習（数日）」である。
実装先行の人間は、数冊の本を買って、2、3日かけて読めばいいだけである。
論理先行の人間は、一旦論理を忘れて1年半ぐらい実装研究をした後に、本を読み直せばいい。
問題なのは論理先行で、間違った癖がついてしまった人である。
例えば、サンプルコードレベルでしかないデザインパターンを、オブジェクト指向の本質だと
勘違いしてしまった人などである。
まあ、論理本→デザインパターンと学習すれば誰でも陥る罠である。勘違いしない方が稀だろう。
またこういう人は「実装先行の論理未学習の人」と議論になった場合、勝ててしまう場合が多い。
そのためまれに妙に自信のある人がいる。しかし、オブジェクト指向の利点を理解していない
（ぶっちゃけ、どこが便利なのか分かっていない）ため、そこを質問するとすぐに分かる。
まあ変な癖をなおすのは大変だが、出来ない事はない。
デザインパターンは後で論理学習の際に勉強した方がいいだろう。
実装先行か論理先行かの違いだと思う。
理想的な学習方法は「実装研究（1年半）」→「論理学習（数日）」である。
実装先行の人間は、数冊の本を買って、2、3日かけて読めばいいだけである。
論理先行の人間は、一旦論理を忘れて1年半ぐらい実装研究をした後に、本を読み直せばいい。
問題なのは論理先行で、間違った癖がついてしまった人である。
例えば、サンプルコードレベルでしかないデザインパターンを、オブジェクト指向の本質だと
勘違いしてしまった人などである。
まあ、論理本→デザインパターンと学習すれば誰でも陥る罠である。勘違いしない方が稀だろう。
またこういう人は「実装先行の論理未学習の人」と議論になった場合、勝ててしまう場合が多い。
そのためまれに妙に自信のある人がいる。しかし、オブジェクト指向の利点を理解していない
（ぶっちゃけ、どこが便利なのか分かっていない）ため、そこを質問するとすぐに分かる。
まあ変な癖をなおすのは大変だが、出来ない事はない。
デザインパターンは後で論理学習の際に勉強した方がいいだろう。
>>136
やろうと言っているのは、相互コードレビュー。
時間はかかるが、早期に問題を発見したり、
全体の技術レベルの底上げには必要なこと。
同じレベルの人でもスキルに偏りがあるので、
複数の人がレビューすることには意味がある。
後で困るコードというのは、
デバッグが困難なバグのあったり、
やたらと保守性が悪いコード。
やろうと言っているのは、相互コードレビュー。
時間はかかるが、早期に問題を発見したり、
全体の技術レベルの底上げには必要なこと。
同じレベルの人でもスキルに偏りがあるので、
複数の人がレビューすることには意味がある。
後で困るコードというのは、
デバッグが困難なバグのあったり、
やたらと保守性が悪いコード。
139 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/29(月) 21:16:45
ソフト設計はおもちゃ
電子回路でも機械設計でもCAD化されてるのは設計情報から実物の試作品を自動で作ってしまう事ができるが
ソフト設計はお絵かきの玩具だもん。
電子回路でも機械設計でもCAD化されてるのは設計情報から実物の試作品を自動で作ってしまう事ができるが
ソフト設計はお絵かきの玩具だもん。
コテはカキコ禁止だってば。
141 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/29(月) 23:44:59
利用規約を守りませう
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
143 ：ヨコ電球（∩T∀T)y-~~~~ ◆dVyiejwdxE ：2007/01/29(月) 23:57:28
>>142
まあ、そうカリカリせずに。全員がコテになれば目立たなくなるんちゃう？
まあ、そうカリカリせずに。全員がコテになれば目立たなくなるんちゃう？
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2
145 ：ヨコ電球（∩T∀T)y-~~~~ ◆dVyiejwdxE ：2007/01/30(火) 00:00:27
今となってはモックアップという言葉すら空しく響く。
とりあえずコテコテ言ってる奴は
税金払え
税金払え
147 ：ヨコ電球（∩T∀T)y-~~~~ ◆dVyiejwdxE ：2007/01/30(火) 00:11:01
メンバーの粒が揃わない限り、意思の疎通さえ難しくなる。それがOODの限界。
148 ：仕様書無しさん：2007/01/30(火) 00:16:17
おっと、この人まともの真実な正確な現実なことを言ってるよ。
149 ：ヨコ電球（∩T∀T)y-~~~~ ◆dVyiejwdxE ：2007/01/30(火) 00:28:27
OODの行く末を憂いております。俺は契約社員なんだよ、派遣じゃないんだよ。
153 ：おじゃばさま：2007/01/30(火) 09:26:56
>138
それならば、その相互コードレビューは全く必要ない。時間の無駄だ。
なぜなら一番スキルのある奴が全部チェックすればいいだけだからだ。
またデバックが困難なバグと言うのは、おそらくバッファオーバラン等のバグで、
保守が困難と言うのは、コーディング規約を守っていない場合だと思うが、
これも一番スキルのあるやつのチェックに加えて、lintやワーニングレベルを上げてのチェックを行い、
コーディング規約を守ってない者には、再度規約を読ませて、修正と再試験をやらせればいい。
メンバーの質を揃える必要など全くない。
第一にメンバー全員に均等に仕事を割り振る必要はないからだ。
出来る人にはできるだけ、出来ない人にはそれなりに仕事をしてもらえばいいだけである。
もしリーダー以外が全員新人ならば、リーダー一人で全部コーディングして、単体試験以降を割り振ればいい。
新人でも人により出来る量は大幅に違う。出来る人には多めに割り振り、出来ない人には結合試験の
試験要員や、ドキュメント整理要員、パン買い出し要員などにすればいいだけである。
この場合、新人からリーダーへの不満が出るかもしれないが、リーダーの仕事を一番多大変にしておけば、
リーダーへの文句は出ない。出来る人新人から出来ない新人への不満は放置する。
それならば、その相互コードレビューは全く必要ない。時間の無駄だ。
なぜなら一番スキルのある奴が全部チェックすればいいだけだからだ。
またデバックが困難なバグと言うのは、おそらくバッファオーバラン等のバグで、
保守が困難と言うのは、コーディング規約を守っていない場合だと思うが、
これも一番スキルのあるやつのチェックに加えて、lintやワーニングレベルを上げてのチェックを行い、
コーディング規約を守ってない者には、再度規約を読ませて、修正と再試験をやらせればいい。
メンバーの質を揃える必要など全くない。
第一にメンバー全員に均等に仕事を割り振る必要はないからだ。
出来る人にはできるだけ、出来ない人にはそれなりに仕事をしてもらえばいいだけである。
もしリーダー以外が全員新人ならば、リーダー一人で全部コーディングして、単体試験以降を割り振ればいい。
新人でも人により出来る量は大幅に違う。出来る人には多めに割り振り、出来ない人には結合試験の
試験要員や、ドキュメント整理要員、パン買い出し要員などにすればいいだけである。
この場合、新人からリーダーへの不満が出るかもしれないが、リーダーの仕事を一番多大変にしておけば、
リーダーへの文句は出ない。出来る人新人から出来ない新人への不満は放置する。
>>153はPL未経験者？ 贅沢すぎる。
> デバックが困難なバグと言うのは、おそらくバッファオーバラン等のバグ
> 保守が困難と言うのは、コーディング規約を守っていない場合
そんな高度な次元な、わけがない。
解 読 不 能 な ヘ タ レ コ ー ド だ。
> リーダー一人で全部コーディングして、単体試験以降を割り振ればいい。
自ら過労死志願してどうするのかと小一時間(ry
> パン買い出し要員などにすればいいだけである。
> 出来る人新人から出来ない新人への不満は放置する。
パワハラでジ・エンド
要因確保でさらに過労死。
> 出来る人には多めに割り振り、
メンバーの不公平感爆発。
> デバックが困難なバグと言うのは、おそらくバッファオーバラン等のバグ
> 保守が困難と言うのは、コーディング規約を守っていない場合
そんな高度な次元な、わけがない。
解 読 不 能 な ヘ タ レ コ ー ド だ。
> リーダー一人で全部コーディングして、単体試験以降を割り振ればいい。
自ら過労死志願してどうするのかと小一時間(ry
> パン買い出し要員などにすればいいだけである。
> 出来る人新人から出来ない新人への不満は放置する。
パワハラでジ・エンド
要因確保でさらに過労死。
> 出来る人には多めに割り振り、
メンバーの不公平感爆発。
ただし「悪貨は良貨を駆逐する」ということがあるので、
極端に出来の悪い要員ははずすことはやむをえない。
極端に出来の悪い要員ははずすことはやむをえない。
>>154
いや大手では良く見る光景
いや大手では良く見る光景
157 ：ヨヨ電球（∩T∀T)y-~~~~ ◆bRYFywpmvY ：2007/01/30(火) 21:43:25
一人に抱え込ませると、バックレかまされた時がきつすぎる。
>>156
リーダ一人で全部コーディング・・・がか？
リーダ一人で全部コーディング・・・がか？
159 ：仕様書無しさん：2007/01/30(火) 22:33:59
お前等まだやってんのか？ｗ
もう、あたまわりーから、死ねよ、お前等ｗ
まあ、オブジェクト指向で設計をキチンとやれば実装～テスト～納品までの時間は半分で済むとかいって
設計の期間に倍取られて、実装から納品までの期間を半分にされたら俺はブッ千切れるけどなｗ
もう、あたまわりーから、死ねよ、お前等ｗ
まあ、オブジェクト指向で設計をキチンとやれば実装～テスト～納品までの時間は半分で済むとかいって
設計の期間に倍取られて、実装から納品までの期間を半分にされたら俺はブッ千切れるけどなｗ
>>159はもっといろいろと人生勉強してから出直すべきだな。
OO云々語る前に
OO云々語る前に
>>160←加齢臭するｗ
頭っから否定はどうにもな…
OO使おうがどうしようが、自分のやり方で上手く行ってれば
いいってことに帰結しちゃうけどね…
OO使おうがどうしようが、自分のやり方で上手く行ってれば
いいってことに帰結しちゃうけどね…
しかし、自分の上手く行くやりかたに固守すると
進歩が無いのもたしか、やはり、最初は苦労するかもしれないが、
なるべく進んでるとされるやり方を積極的にとり入れるべきだと思う。
進歩が無いのもたしか、やはり、最初は苦労するかもしれないが、
なるべく進んでるとされるやり方を積極的にとり入れるべきだと思う。
でも、この業界ってさ、
名前を変えただけの代物とか、
まともなところでは自明のものとしてやっていることに名前を付けただけの代物とか、
そういうのが多いと思わないか?
車輪の再発明が容易な分野なのだから、
ちょっとは自分の頭を使って、
自分のところの職場に最適な方法を、
自分で編み出してもいいと思うぞ。
これが新しいやりかたです! という流行を取り入れることが、
かえって退化になるような職場だってあるぞ。
名前を変えただけの代物とか、
まともなところでは自明のものとしてやっていることに名前を付けただけの代物とか、
そういうのが多いと思わないか?
車輪の再発明が容易な分野なのだから、
ちょっとは自分の頭を使って、
自分のところの職場に最適な方法を、
自分で編み出してもいいと思うぞ。
これが新しいやりかたです! という流行を取り入れることが、
かえって退化になるような職場だってあるぞ。
いままで、他人が考えた、俺様流の痛さ、駄目さ加減を知らないのか？
はっきりいって、この日本の業界で、個人とか職場とか狭い範囲で考えた工夫に
まともな物は無いぞ。
はっきりいって、この日本の業界で、個人とか職場とか狭い範囲で考えた工夫に
まともな物は無いぞ。
166 ：仕様書無しさん：2007/01/31(水) 08:12:52
オブジェクト指向は資産が積み上がった際の弊害までをシミュレーション
しきれなかったのが失敗だと思うよ。JAVAのAPIがまさにそれ。
乱立するオプンのimportクラスとのコンフリクトもあるな。
namespaceさえないJAVAは石器時代のオブジェクト指向言語。
オブジェクト指向といえば主流はJAVAだからオブジェクト指向設計を語っても
実装仕様が糞味噌だから何をいっても無駄の塊。
しきれなかったのが失敗だと思うよ。JAVAのAPIがまさにそれ。
乱立するオプンのimportクラスとのコンフリクトもあるな。
namespaceさえないJAVAは石器時代のオブジェクト指向言語。
オブジェクト指向といえば主流はJAVAだからオブジェクト指向設計を語っても
実装仕様が糞味噌だから何をいっても無駄の塊。
>>165
いわんとすることが伝わらなかったようで、こちらの書き方が悪くてすみません。
言いたいのは2つ
1. いわゆる「銀の弾丸」の話のように、
新しい方法論を取り入れれば問題が解決するというのは考えが甘い。
2. スキルのある人なら誰でも考えつくようなことこそ、不偏的な標準作法であり、
それぞれの環境や状況によって生じる若干の違いは、
我流なのではなく、ケースバイケースの最適化だと言える。
あるところでは、「ペアプログラミング」という言葉を聞くより前に、
それを行っていて、新人がみるみるうちに成長して、
二人で三人分の仕事をこなしていたが、
流行の言葉に踊らされてペアプログラミングをやりはじめたチームでは、
二人で一人分未満の仕事しかできていなかったよ。
いわんとすることが伝わらなかったようで、こちらの書き方が悪くてすみません。
言いたいのは2つ
1. いわゆる「銀の弾丸」の話のように、
新しい方法論を取り入れれば問題が解決するというのは考えが甘い。
2. スキルのある人なら誰でも考えつくようなことこそ、不偏的な標準作法であり、
それぞれの環境や状況によって生じる若干の違いは、
我流なのではなく、ケースバイケースの最適化だと言える。
あるところでは、「ペアプログラミング」という言葉を聞くより前に、
それを行っていて、新人がみるみるうちに成長して、
二人で三人分の仕事をこなしていたが、
流行の言葉に踊らされてペアプログラミングをやりはじめたチームでは、
二人で一人分未満の仕事しかできていなかったよ。
>>166
つ package
つ package
170 ：おじゃばさま：2007/01/31(水) 09:52:04
>154
読解不能なヘタレコード？
さすがにイメージが掴めない。ユビキタス社会並に意味が分からない。
変数やクラス名が全てa001などのコードとか、1メソッドの行数が3000行を越えるとか、
ネストが30階層ぐらいあるとか、フラグやステータスが10個ぐらいあって、AND/ORなどで判断している
などだろうか？ほとんどがコーディング規約に触れると思うが。
リーダー一人でコーディングが過労死？
まず一番時間がかかるのは単体試験項目作成及び単体試験である。これ以降を新人にやらせる。
またコーディングが出来た時点で逐次割り振るので、リーダーは「結合試験開始」から「最後の割り振り
コードに対する単体試験分の時間」を引いた時間を使うことが出来る。
定時に帰ったとしても十分な作業時間は確保されるだろう。
もしそれでも時間が足りないとしたら、そのチームの能力を遥かに超えた量と言う事になる。
もし均等に割り振ったとしたら、もっと時間が足りなくなる量だろう。
その場合は速やかに再スケジューリングを行う必要がある。
パワハラでジエンド？
出来ない人が辞めると言う事か？現実を見ると出来ない人が辞める確立は低い。
それはそういう対処を受けると出来ないと言う自覚が出来て、辞めても行く所がないと考えるからだと
思われる。またもし出来ない人が抜けても大した影響はない。
メンバーの不満爆発？
カースト制度の原理で階級があると組織は安定する。つまり出来る人と出来ない人との対処を買える事で
暗黙の階級を作る。表面的な不満が出るかもしれないが、実際にはチームは安定する。
読解不能なヘタレコード？
さすがにイメージが掴めない。ユビキタス社会並に意味が分からない。
変数やクラス名が全てa001などのコードとか、1メソッドの行数が3000行を越えるとか、
ネストが30階層ぐらいあるとか、フラグやステータスが10個ぐらいあって、AND/ORなどで判断している
などだろうか？ほとんどがコーディング規約に触れると思うが。
リーダー一人でコーディングが過労死？
まず一番時間がかかるのは単体試験項目作成及び単体試験である。これ以降を新人にやらせる。
またコーディングが出来た時点で逐次割り振るので、リーダーは「結合試験開始」から「最後の割り振り
コードに対する単体試験分の時間」を引いた時間を使うことが出来る。
定時に帰ったとしても十分な作業時間は確保されるだろう。
もしそれでも時間が足りないとしたら、そのチームの能力を遥かに超えた量と言う事になる。
もし均等に割り振ったとしたら、もっと時間が足りなくなる量だろう。
その場合は速やかに再スケジューリングを行う必要がある。
パワハラでジエンド？
出来ない人が辞めると言う事か？現実を見ると出来ない人が辞める確立は低い。
それはそういう対処を受けると出来ないと言う自覚が出来て、辞めても行く所がないと考えるからだと
思われる。またもし出来ない人が抜けても大した影響はない。
メンバーの不満爆発？
カースト制度の原理で階級があると組織は安定する。つまり出来る人と出来ない人との対処を買える事で
暗黙の階級を作る。表面的な不満が出るかもしれないが、実際にはチームは安定する。
んで、>>170は、どこで働いてるの?
>170
おっ
神発見
うちの基幹系のサブシステム、コボルで２千万ステップくらいあるんだけど
大好きなJavaで書き換えてくれよ
一月くらい終わりそう？
できるよね？
それくらいの大口たたきまくってるもんね
実は学生で実務経験無しってのは･･･ありそうだなｗ
おっ
神発見
うちの基幹系のサブシステム、コボルで２千万ステップくらいあるんだけど
大好きなJavaで書き換えてくれよ
一月くらい終わりそう？
できるよね？
それくらいの大口たたきまくってるもんね
実は学生で実務経験無しってのは･･･ありそうだなｗ
文盲コボラ乙
175 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/01(木) 00:56:01
ああ、今日はぐちゃぐちゃのソース解読して一日終わった。
明日も続きだ。
明日も続きだ。
176 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/01(木) 00:57:59
Ｃ＃でもあそこまで解読不能のコードを組めると言う事を実感したしだいだ。
177 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/01(木) 01:01:16
Ｊａｖａの会社の面接でステップ数とか言われて面食らったけど
コボル換算ステップ数だそうだ。
構造化以降はステップ数で数えたこと無いんだが・・・
コボル換算ステップ数だそうだ。
構造化以降はステップ数で数えたこと無いんだが・・・
wc一発
blogでやれ糞コテ
解読不能ってのはさすがにないけどな。
一見解読不能でも馬鹿の考え方が理解できれば
何とかなるしｗ
そういう意味ではデキの悪い実装チームのPGが一人
抜けたくらい自分でやれば済むけど虚しくはなるなｗ
一見解読不能でも馬鹿の考え方が理解できれば
何とかなるしｗ
そういう意味ではデキの悪い実装チームのPGが一人
抜けたくらい自分でやれば済むけど虚しくはなるなｗ
181 ：仕様書無しさん：2007/02/01(木) 02:59:34
このスレには随分上からモノを言う人が多いですね。
本質的に理論をどう現場に普及させて行くかって
スレなんだから当たり前だろ。
スレなんだから当たり前だろ。
「どうかご理解ください」って言うのか？
お前さんは上司に恵まれてないなｗ
お前さんは上司に恵まれてないなｗ
そうつっかかるなよ。
「教育」が必要だってことだろ？教育ってのは上から目線
じゃないと成り立たない事が多いのよ。リーダーとして
経験ある人間なら判ると思うが…
新しい「概念」を導入するためにはさ。プロジェクト
リーダーやる時が君にも来るだろうから、年寄りの
一意見として心に留めておけや。
「教育」が必要だってことだろ？教育ってのは上から目線
じゃないと成り立たない事が多いのよ。リーダーとして
経験ある人間なら判ると思うが…
新しい「概念」を導入するためにはさ。プロジェクト
リーダーやる時が君にも来るだろうから、年寄りの
一意見として心に留めておけや。
187 ：ココ電球（∩T∀T)y-~~~~ ◆lkZWT52FFA ：2007/02/01(木) 07:26:59
リーダーは部下を思いやり、部下はリーダーを敬う。それだけでおｋ
188 ：仕様書無しさん：2007/02/01(木) 08:10:42
コンフリクト
クラスDateが有名
クラスDateが有名
189 ：おじゃばさま：2007/02/01(木) 19:25:27
>173
とりあえず概算見積もりをしてみよう。
2千万Stepだとして、1人月1Kで計算してみる。すると2万人月となる。
1人月100万円だとして200億円。こちらで集められるプログラマが600人だとして約3年。
金額は200億円で、期間は3年かかります。
最初に作った時に比べれば、かなり格安で早いと思うがどうかな？
コボルのプログラムを他言語に移植する理由は、おそらく汎用機がサポート切れで使えなくなり、
UNIXサーバ等に変更する必要に迫られた時などだろう。
コボルをJavaに移植するのはお勧めしない。
コボラーがJavaを理解するのは数年かかり、Java技術者でそれほど大規模のシステムを経験した人は
稀だからだ。コボルからの移植はCをお勧めする。
幸い、Javaの動くマシンでCをサポートしていない物はないだろう。
ではコボルをCに移植する際の注意点を見てみよう。
とりあえず概算見積もりをしてみよう。
2千万Stepだとして、1人月1Kで計算してみる。すると2万人月となる。
1人月100万円だとして200億円。こちらで集められるプログラマが600人だとして約3年。
金額は200億円で、期間は3年かかります。
最初に作った時に比べれば、かなり格安で早いと思うがどうかな？
コボルのプログラムを他言語に移植する理由は、おそらく汎用機がサポート切れで使えなくなり、
UNIXサーバ等に変更する必要に迫られた時などだろう。
コボルをJavaに移植するのはお勧めしない。
コボラーがJavaを理解するのは数年かかり、Java技術者でそれほど大規模のシステムを経験した人は
稀だからだ。コボルからの移植はCをお勧めする。
幸い、Javaの動くマシンでCをサポートしていない物はないだろう。
ではコボルをCに移植する際の注意点を見てみよう。
190 ：おじゃばさま：2007/02/01(木) 19:57:30
まずデータベース設計だ。
COBOLですでにSQL型のデータベースを使用している場合は問題ないが、多くのCOBOLシステムは
ただのファイルを使用しているだろう。
これをデータベースに置き換える場合、ファイルをテーブルに変更するが、正規化を知らないような
初心者にやらせてはいけない。コボラーにやらせるとファイルをそのままテーブルにするクソ野郎が
出て来るが、その場合はテーブル設計の本を渡して、3年勉強してから来いと言うべきである。
まともなDB設計者がいないなら、DB化は諦めてファイルベースで作るのをお勧めする。
次に気をつけなければいけないのは漢字コードだ。汎用機の場合はEBCDICコードなどが使われており、
EUCに変更する必要がある場合がある。変換で顧客名などが化けると大問題になる可能性があるので、
データ移行の調査は事前にしておこう。
次に気をつけるのは演算精度である。
COBOLでは桁数や小数点演算を気にする必要はないが、Linuxではそうはいかない。
まず浮動小数点を使用した場合の誤差は許容されるかを確認しよう。
許容されない場合は演算ライブラリを使用する必要がある。
その場合、事前に作業者全員に告知し、使用方法を習得させる必要がある。
浮動小数点の誤差が許容されても、最大桁数が問題になる場合がある。
32ビットLinuxでは色々と面倒なことが発生するので、64ビットSolarisやHP-UXをお勧めする。
COBOLですでにSQL型のデータベースを使用している場合は問題ないが、多くのCOBOLシステムは
ただのファイルを使用しているだろう。
これをデータベースに置き換える場合、ファイルをテーブルに変更するが、正規化を知らないような
初心者にやらせてはいけない。コボラーにやらせるとファイルをそのままテーブルにするクソ野郎が
出て来るが、その場合はテーブル設計の本を渡して、3年勉強してから来いと言うべきである。
まともなDB設計者がいないなら、DB化は諦めてファイルベースで作るのをお勧めする。
次に気をつけなければいけないのは漢字コードだ。汎用機の場合はEBCDICコードなどが使われており、
EUCに変更する必要がある場合がある。変換で顧客名などが化けると大問題になる可能性があるので、
データ移行の調査は事前にしておこう。
次に気をつけるのは演算精度である。
COBOLでは桁数や小数点演算を気にする必要はないが、Linuxではそうはいかない。
まず浮動小数点を使用した場合の誤差は許容されるかを確認しよう。
許容されない場合は演算ライブラリを使用する必要がある。
その場合、事前に作業者全員に告知し、使用方法を習得させる必要がある。
浮動小数点の誤差が許容されても、最大桁数が問題になる場合がある。
32ビットLinuxでは色々と面倒なことが発生するので、64ビットSolarisやHP-UXをお勧めする。
191 ：おじゃばさま：2007/02/01(木) 20:04:06
最も気をつけなければいけないのは開発方法だ。
COBOLとCで一番違うのはモジュール粒度である。COBOLのプロジェクトでは保守用に詳細設計書を
作る所があるが、これをCに適用すると細かすぎてしまい膨大な量になる。
またCOBOLでは単体試験と結合試験の違いがなく、モジュール試験として行う場合があるが、
これをCに適用してしまうと粗すぎる。
ドキュメントと試験はC開発者に全て任せて、コボラーはCの入門書でも読んでいてもらいたい。
COBOLとCで一番違うのはモジュール粒度である。COBOLのプロジェクトでは保守用に詳細設計書を
作る所があるが、これをCに適用すると細かすぎてしまい膨大な量になる。
またCOBOLでは単体試験と結合試験の違いがなく、モジュール試験として行う場合があるが、
これをCに適用してしまうと粗すぎる。
ドキュメントと試験はC開発者に全て任せて、コボラーはCの入門書でも読んでいてもらいたい。
・・・なんでLinuxなんだか。
うーん。経験年数は一桁と読んだがどうか。
それらをまともに客に話すと
「COBOL処理系を買う（or創る）」と言い出しそうだね。
うーん。経験年数は一桁と読んだがどうか。
それらをまともに客に話すと
「COBOL処理系を買う（or創る）」と言い出しそうだね。
193 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/01(木) 22:46:22
コボルクラスを作ってあげれば解決
経験年数一桁どころか経験無しのサンデープログラマじゃない？
なんか日経コンピュータ全記事読んでますみたいな子だね
･･･お話にならないね
なんか日経コンピュータ全記事読んでますみたいな子だね
･･･お話にならないね
192=194=糞コボラ
俺はCOBOL知らんけど、そこまでしてCにする意味あるか？
コボラーばかりならOO-COBOLで書き換えた方が
いいんじゃないの？
コボラーばかりならOO-COBOLで書き換えた方が
いいんじゃないの？
197 ：仕様書無しさん：2007/02/01(木) 23:58:32
>>192, >>194
おいおい、おじゃばはJavaだけでなくコボルやC言語できる香具師だぞ
コボルしか出来ない糞コボラ=192=194よりは使える香具師と思われ
糞コボラのように経験年数が多くても、使えないんじゃどうしようもない
おいおい、おじゃばはJavaだけでなくコボルやC言語できる香具師だぞ
コボルしか出来ない糞コボラ=192=194よりは使える香具師と思われ
糞コボラのように経験年数が多くても、使えないんじゃどうしようもない
198 ：仕様書無しさん：2007/02/02(金) 00:53:47
おいおい神でありリーダであるおばかじゃなかった
おじゃばに一人でやってもらいたいんだが？
一人じゃできません、ごめんなさいって言えばいいものを
長々とつまらんこと書きやがって
もうおまえには頼まん
おじゃばに一人でやってもらいたいんだが？
一人じゃできません、ごめんなさいって言えばいいものを
長々とつまらんこと書きやがって
もうおまえには頼まん
すまん、768じゃないよｗ
言語厨の知らない言葉は、適材適所。
またJava厨か！
ネットでも現場でも空気読むことができんやつらだ！！
一生オナってろ！
ネットでも現場でも空気読むことができんやつらだ！！
一生オナってろ！
204 ：ヨヨ電球（∩T∀T)y-~~~~ ◆gJIIKIVefM ：2007/02/02(金) 17:10:17
長年ためこんだCOBOL資産の移行を安くあげようってのが、そもそもの間違い。
移行先をJavaにしようが、Cにしようが、それまでにかかったコストと同程度か、
あるいはそれ以上のものが要求される。
COBOL資産から受け継ぐことができるのは、しがらみにまみれたビジネスロジックだけ。
COBOLから逃れるには、会社ごと立ち上げなおす以外に方法は無いよ。
移行先をJavaにしようが、Cにしようが、それまでにかかったコストと同程度か、
あるいはそれ以上のものが要求される。
COBOL資産から受け継ぐことができるのは、しがらみにまみれたビジネスロジックだけ。
COBOLから逃れるには、会社ごと立ち上げなおす以外に方法は無いよ。
COBOLから逃れること を
顧客が望んでいるとは思わないけど
顧客が望んでいるとは思わないけど
206 ：ヨヨ電球（∩T∀T)y-~~~~ ◆gJIIKIVefM ：2007/02/02(金) 17:23:01
顧客は自分にとって本当に必要なものを知らないだけじゃなく、
自分が欲しいものさえ知らない。
COBOL技術者数の減少傾向が止まり、増加に転じることを切に願う。
自分が欲しいものさえ知らない。
COBOL技術者数の減少傾向が止まり、増加に転じることを切に願う。
207 ：仕様書無しさん：2007/02/02(金) 18:18:35
コボル厨は
＿＿＿ 見えませ～ん
∥ | ∨
∥現実 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
＿＿＿ 読めませ～ん
∥ | ∨
∥空気 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
＿＿＿ 見えませ～ん
∥ | ∨
∥現実 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
＿＿＿ 読めませ～ん
∥ | ∨
∥空気 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
208 ：ヨヨ電球（∩T∀T)y-~~~~ ◆gJIIKIVefM ：2007/02/02(金) 21:32:14
Java厨は
＿＿＿ 見えませ～ん
∥ | ∨
∥納品 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
＿＿＿ 読めませ～ん
∥ | ∨
∥期日 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
＿＿＿ 見えませ～ん
∥ | ∨
∥納品 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
＿＿＿ 読めませ～ん
∥ | ∨
∥期日 ∧_∧ .ﾍ∧
∥ ＼ ( ･∀･) (ﾟA●)
||￣￣⊂ ) ( と)
凵 し`Ｊ U U
二番煎じﾃﾗﾂﾏﾗﾅｽ
210 ：ヨヨ電球（∩T∀T)y-~~~~ ◆gJIIKIVefM ：2007/02/02(金) 21:59:37
再利用ですが、なにか？
糞コテﾃﾗﾂﾏﾗﾅｽ
212 ：おじゃばさま：2007/02/02(金) 22:57:38
COBOLをCに移植する理由は説明済みだが、簡単に書きすぎて分からなかったのかな？
もう一度説明すると、汎用機のサポートが切れて（後継機が出ず、パーツのサポートも終わり、
本体や使用しているソフトウェアの修正サポートも打ち切られた）、サーバ機に移行する必要が
出来た時だな。まあ、サーバ機で同等のCOBOL環境があればそれでもいいのだが、汎用機と言うのは
顧客を抱え込むため独自仕様が満載の場合が多い。つまりそのままでは動かない。
どうせ金を掛けて移植するなら、今後、マシンやライブラリが変更になっても対応出来る物にしようと
思うのは、当然の事だろう。
その点で言えば、OSやDBの選択肢が豊富なJavaは最適と言えるが、Java技術者で1000K越えの
大規模開発経験者は少ないし、コボラーにいきなりJavaをマスターさせるのは絶望的だ。
だから次に汎用性があって、コボラーも5年ぐらい頑張ればマスター出来るC言語を勧める。
開発はC技術者に任せて、システムが出来上がる頃には、元コボラーでもCを覚えてメンテナンス
出来るようになっているという計算だ。
もう一度説明すると、汎用機のサポートが切れて（後継機が出ず、パーツのサポートも終わり、
本体や使用しているソフトウェアの修正サポートも打ち切られた）、サーバ機に移行する必要が
出来た時だな。まあ、サーバ機で同等のCOBOL環境があればそれでもいいのだが、汎用機と言うのは
顧客を抱え込むため独自仕様が満載の場合が多い。つまりそのままでは動かない。
どうせ金を掛けて移植するなら、今後、マシンやライブラリが変更になっても対応出来る物にしようと
思うのは、当然の事だろう。
その点で言えば、OSやDBの選択肢が豊富なJavaは最適と言えるが、Java技術者で1000K越えの
大規模開発経験者は少ないし、コボラーにいきなりJavaをマスターさせるのは絶望的だ。
だから次に汎用性があって、コボラーも5年ぐらい頑張ればマスター出来るC言語を勧める。
開発はC技術者に任せて、システムが出来上がる頃には、元コボラーでもCを覚えてメンテナンス
出来るようになっているという計算だ。
>どうせ金を掛けて移植するなら、今後、マシンやライブラリが変更になっても対応出来る物にしようと
>思うのは、当然の事だろう。
いや、思わない。額が違いすぎて、思いたくても思えない。
>思うのは、当然の事だろう。
いや、思わない。額が違いすぎて、思いたくても思えない。
214 ：おじゃばさま：2007/02/02(金) 23:21:13
>198
190は198にこき使われているだろう作業者と、COBOL移植をする不幸に見舞われた人へのアドバイスであり、
191の最後の行は198に対するアドバイスである。
あと201のおかげで198が俺の書き込みをどう解釈したか分かった。勉強になった。
>203
以前に会議室のホワイトボードに
-------------------------------------------------------------------------
無能プログラマーの行動
・空気を読めと言う
・仕様書の行間を読めと言う
・．．．
-------------------------------------------------------------------------
などと書かれていた事があり、その後、入って来たSEがそれを知らずに、
ホワイトボードをバックに、PGに「行間読め」「空気読め」発言を連発し説教した事があった。
またその時のPGの回答が傑作だったので、俺も使うようにしている。
「空気は見えないので読めません！！」
190は198にこき使われているだろう作業者と、COBOL移植をする不幸に見舞われた人へのアドバイスであり、
191の最後の行は198に対するアドバイスである。
あと201のおかげで198が俺の書き込みをどう解釈したか分かった。勉強になった。
>203
以前に会議室のホワイトボードに
-------------------------------------------------------------------------
無能プログラマーの行動
・空気を読めと言う
・仕様書の行間を読めと言う
・．．．
-------------------------------------------------------------------------
などと書かれていた事があり、その後、入って来たSEがそれを知らずに、
ホワイトボードをバックに、PGに「行間読め」「空気読め」発言を連発し説教した事があった。
またその時のPGの回答が傑作だったので、俺も使うようにしている。
「空気は見えないので読めません！！」
215 ：おじゃばさま：2007/02/02(金) 23:48:45
>213
では金額が同じだとしたらどうだろう？
このようなソフトウェアの金額というのは、発注側の予算によって決まる。
そして大手のシステムでは、システムの耐用年数などが決まっていて、それを過ぎると予算が確保される
ようになっている。つまり実際には機能で金額が決まるのではなく、予算で決まるのだ。
例えば前システム開発費が300億だったとしよう。
耐用年数が過ぎたら次に計上される予算は、大体、前システムと同様になる。で300億だったとする。
新規でやったら300億で、COBOLのまま移植は200億だったとしよう。
発注側は予算が300億なら、300億でも200億でもいいのである。別に100億が自分の給料になる訳ではない。
ちなみに受注側は200億より300億の方がいいのである。予算のギリギリを取るのが営業の鉄則である。
という訳で、300億でも200億でも同じだと言う現象が発生する。
それならば発注側も新規を選ぶのではないだろうか？
では金額が同じだとしたらどうだろう？
このようなソフトウェアの金額というのは、発注側の予算によって決まる。
そして大手のシステムでは、システムの耐用年数などが決まっていて、それを過ぎると予算が確保される
ようになっている。つまり実際には機能で金額が決まるのではなく、予算で決まるのだ。
例えば前システム開発費が300億だったとしよう。
耐用年数が過ぎたら次に計上される予算は、大体、前システムと同様になる。で300億だったとする。
新規でやったら300億で、COBOLのまま移植は200億だったとしよう。
発注側は予算が300億なら、300億でも200億でもいいのである。別に100億が自分の給料になる訳ではない。
ちなみに受注側は200億より300億の方がいいのである。予算のギリギリを取るのが営業の鉄則である。
という訳で、300億でも200億でも同じだと言う現象が発生する。
それならば発注側も新規を選ぶのではないだろうか？
216 ：仕様書無しさん：2007/02/03(土) 00:13:43
>>215
おじゃば、おさん・爺C厨スレが過疎ってるから、たまには顔出し汁
おじゃば、おさん・爺C厨スレが過疎ってるから、たまには顔出し汁
217 ：仕様書無しさん：2007/02/03(土) 00:18:40
>>215
なんじゃそりゃ？
だいたいプロジェクト複数押し付けられてそれらまとめての予算に決まってるじゃん。
つまり、期末に仕上がらなければ１プロジェクトの売上がまるまる落ちてその分赤になるんだから
もしものときを考えてできるだけ値切るに決まってんじゃん。
馬鹿かおめぇ。
なんじゃそりゃ？
だいたいプロジェクト複数押し付けられてそれらまとめての予算に決まってるじゃん。
つまり、期末に仕上がらなければ１プロジェクトの売上がまるまる落ちてその分赤になるんだから
もしものときを考えてできるだけ値切るに決まってんじゃん。
馬鹿かおめぇ。
218 ：仕様書無しさん：2007/02/03(土) 00:44:49
とりあえず長すぎて読む気しねー
読む側の気持ちを考えられない奴にまともなコードなど書けるはずもない。
まずは２ｃｈでの文章の書き方を学べ。
読む側の気持ちを考えられない奴にまともなコードなど書けるはずもない。
まずは２ｃｈでの文章の書き方を学べ。
219 ：仕様書無しさん：2007/02/03(土) 00:46:20
読んでないけど机上の空論ぽいのは何となくわかる。
あと、長すぎ、ってのは、アンタのレスとしてはって意味でね。
別に前から良いこと書いてるわけでも、面白そうでもないんだから、
その長さは読んでもらえませんよって事。
簡潔にな。
あと、長すぎ、ってのは、アンタのレスとしてはって意味でね。
別に前から良いこと書いてるわけでも、面白そうでもないんだから、
その長さは読んでもらえませんよって事。
簡潔にな。
まあまあそうおじゃばをいじめるなよ。
受け売りで内容まで理解してないから長文になってんだろ。
会社じゃ使えないのに的外れのうんちくたれまくって相手にされてないんだろ、
ここくらい自由に発言させてやろーぜ。
受け売りで内容まで理解してないから長文になってんだろ。
会社じゃ使えないのに的外れのうんちくたれまくって相手にされてないんだろ、
ここくらい自由に発言させてやろーぜ。
>>198
そりゃそうだ・・・(どんなでかいのでも?）一人でコーディングするって言ってるんだから・・・
>>204
残念ながらそれが現実・・・
俺は個人的にCOBOLerがJavaなり覚えて培ったノウハウをそっちに実装してくれれば、
結構すごいのにとおもうんだがな。
・・・そんなことやるわけねー orz...
そりゃそうだ・・・(どんなでかいのでも?）一人でコーディングするって言ってるんだから・・・
>>204
残念ながらそれが現実・・・
俺は個人的にCOBOLerがJavaなり覚えて培ったノウハウをそっちに実装してくれれば、
結構すごいのにとおもうんだがな。
・・・そんなことやるわけねー orz...
222 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/03(土) 02:18:45
文革もそろそろおわりだし
OO紅衛兵も下放されちゃって平和な時代が戻る悪寒
OO紅衛兵も下放されちゃって平和な時代が戻る悪寒
あとはお前が死ねば至極平和だな
224 ：仕様書無しさん：2007/02/03(土) 09:52:47
ここのスレタイは現実にそうなのですか？
．ＮＥＴがわざわざＶＢをオブジェクト指向言語にしてまで言語をＯＯにしたのに
開発現場はＯＯではないということなんですか。
言語がＯＯでも生の現場の開発手法はＯＯではないということですか。
例えば、ＯＯ的でないということは、どういうことを指してそう言っている
のですか。よろしければ教えてください。
たとえば、一つのプロジェクトで、ＯＯ的にウオーターフロー的に構想された
上で構築されず、部品も全体構想もやや無秩序に作られている、
ということを意味するのですか。
．ＮＥＴがわざわざＶＢをオブジェクト指向言語にしてまで言語をＯＯにしたのに
開発現場はＯＯではないということなんですか。
言語がＯＯでも生の現場の開発手法はＯＯではないということですか。
例えば、ＯＯ的でないということは、どういうことを指してそう言っている
のですか。よろしければ教えてください。
たとえば、一つのプロジェクトで、ＯＯ的にウオーターフロー的に構想された
上で構築されず、部品も全体構想もやや無秩序に作られている、
ということを意味するのですか。
225 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/03(土) 10:38:42
設計技術がインチキ
十分な設計情報をもった設計図はコードを自動生成できる。
あんなもん設計じゃねえ。
十分な設計情報をもった設計図はコードを自動生成できる。
あんなもん設計じゃねえ。
226 ：仕様書無しさん：2007/02/03(土) 10:43:13
>>225
お間えの存在が一番 いんちき
お間えの存在が一番 いんちき
>>226
せっかくコテにしてくれてんだから、消しちゃえよｗ
せっかくコテにしてくれてんだから、消しちゃえよｗ
対案って言ったらオープンプラットフォームのOOサポートCOBOLで
いいだろ？LinuxでもSolarisでも運用できるんだから。
いいだろ？LinuxでもSolarisでも運用できるんだから。
230 ：仕様書無しさん：2007/02/03(土) 15:31:03
>>228
あんた誰？
あんた誰？
現場では、よっぽど零細かつ技術力の無いとこ以外は、
すでに、すべてOOD、流行ってないなんていうのは、
現場にでてない人間の妄想だよ。
すでに、すべてOOD、流行ってないなんていうのは、
現場にでてない人間の妄想だよ。
233 ：仕様書無しさん：2007/02/03(土) 17:53:29
>>233
お前は黙っとけ。自分がこの業界に少しでも興味あるならな…
>>231
君の感覚のがオカシイ、既にOOD当たり前ってのは俺の業界でも
そうだが、よりハードに近いとこじゃ、んな事ない。
組み込み系とか。俺らが普通に使ってるWinでも最新GPUの
デバドラをOODでやろうと思うか？
俺はごめんだし、そういう仕事請けたら普通にOOなんか無視するよ。
現場に出てる人間だったらむしろ、そういう使い分けが判ってるハズ。
お前は黙っとけ。自分がこの業界に少しでも興味あるならな…
>>231
君の感覚のがオカシイ、既にOOD当たり前ってのは俺の業界でも
そうだが、よりハードに近いとこじゃ、んな事ない。
組み込み系とか。俺らが普通に使ってるWinでも最新GPUの
デバドラをOODでやろうと思うか？
俺はごめんだし、そういう仕事請けたら普通にOOなんか無視するよ。
現場に出てる人間だったらむしろ、そういう使い分けが判ってるハズ。
236 ：仕様書無しさん：2007/02/04(日) 00:31:20
もう正直に教えてください。
ほぼそのままコードまで落とせるようなクラス図なりシーケンス図を
設計しているプロジェクトの経験ある人はいますか？
ほぼそのままコードまで落とせるようなクラス図なりシーケンス図を
設計しているプロジェクトの経験ある人はいますか？
238 ：仕様書無しさん：2007/02/04(日) 00:47:06
>>236
その質問に何の意味があるんだよ
その質問に何の意味があるんだよ
>>236
そのままコーディングできないような設計は設計じゃないと
俺は思ってる。多少の齟齬はあってもね。
プロジェクトが上手く行ってるかどうかで言えば、すべて
クライアントから文句言われた事は無い。
でも、自分が結局コーディングのヘルプに入るのは多々。
設計を変更するわけじゃないから、自分の心の中では
「なんで俺が…」と唱えながらやってたりするんだけど、
設計してる時より楽しいのは秘密だｗ
そのままコーディングできないような設計は設計じゃないと
俺は思ってる。多少の齟齬はあってもね。
プロジェクトが上手く行ってるかどうかで言えば、すべて
クライアントから文句言われた事は無い。
でも、自分が結局コーディングのヘルプに入るのは多々。
設計を変更するわけじゃないから、自分の心の中では
「なんで俺が…」と唱えながらやってたりするんだけど、
設計してる時より楽しいのは秘密だｗ
241 ：仕様書無しさん：2007/02/04(日) 01:27:09
242 ：仕様書無しさん：2007/02/04(日) 01:41:01
設計にもいろいろあるけどな。
コーディング直前の設計と、顧客からヒヤリングして分かるように作った設計は違うしな。
コーディング直前の設計と、顧客からヒヤリングして分かるように作った設計は違うしな。
243 ：仕様書無しさん：2007/02/04(日) 01:47:17
>>242
そうだよな。
読み手不在の状態で書いた設計書ってどうあるべきか？ってのは
置いておいて、実際問題として抜けや漏れが多いよな。
完成するまで溜めて溜めて溜めて溜めて「バーン」と出すのだけは勘弁してほしい。
こっちにはその業務の知識が無いから読め無い場合だってあるんだから、
何がほしいとか何の情報が足りないとか実装する人にもちゃんと聞いてほしい。
そうだよな。
読み手不在の状態で書いた設計書ってどうあるべきか？ってのは
置いておいて、実際問題として抜けや漏れが多いよな。
完成するまで溜めて溜めて溜めて溜めて「バーン」と出すのだけは勘弁してほしい。
こっちにはその業務の知識が無いから読め無い場合だってあるんだから、
何がほしいとか何の情報が足りないとか実装する人にもちゃんと聞いてほしい。
いくら設計がＯＯでもコーディングでＯＯを無視する奴いるぜ。
一つのメソッドに何十行も何百行もコード書くなよ。
ちったぁコードの重複を避けることや再利用性にも気を使ってくれ。
メソッド単位でテストするのにどんだけテストケースを想定しなきゃなんないんだよ。
テストクラス用のテストクラスを書かせる気かっ！
一つのメソッドに何十行も何百行もコード書くなよ。
ちったぁコードの重複を避けることや再利用性にも気を使ってくれ。
メソッド単位でテストするのにどんだけテストケースを想定しなきゃなんないんだよ。
テストクラス用のテストクラスを書かせる気かっ！
まぁ関数分割が苦手な奴は多いな。
多分、変数のスコープを考えるのが面倒くさいんだろうけど。
インスタンス変数以外は全部ローカル変数にして一つのメソッド内にだらだら
書いちゃうのが楽っちゃあ楽なんだけど、結局その場凌ぎで、後で誰かが保守
する時に大変な目に合う。数ヶ月もすると本人も自分で何書いたのか忘れちゃ
うケースがほとんど。
あと、名前付けの苦手なやつ。get～という名の関数が何も返さなかったり、
状態の真偽値を返す関数がis～、has～という名でなかったり非常に紛らわしい。
Ａ型の俺は非常にいらいらする。
多分、変数のスコープを考えるのが面倒くさいんだろうけど。
インスタンス変数以外は全部ローカル変数にして一つのメソッド内にだらだら
書いちゃうのが楽っちゃあ楽なんだけど、結局その場凌ぎで、後で誰かが保守
する時に大変な目に合う。数ヶ月もすると本人も自分で何書いたのか忘れちゃ
うケースがほとんど。
あと、名前付けの苦手なやつ。get～という名の関数が何も返さなかったり、
状態の真偽値を返す関数がis～、has～という名でなかったり非常に紛らわしい。
Ａ型の俺は非常にいらいらする。
246 ：仕様書無しさん：2007/02/04(日) 02:36:35
>>244-245←俺はこいつらが本当に設計についていってるのかなんなのかさっぱりわからないけどみんなはどうなの？
247 ：仕様書無しさん：2007/02/04(日) 02:40:25
現場にいる立場としては身につまされる話だ。
248 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/04(日) 04:14:16
マジック変数（status=1,2,3とか）の表を作成したら１２０数個あった
一個解読するのに三日かかった。
一個解読するのに三日かかった。
あんたんとこの会社はよっぽどひまなのか？それとも工数に織り込み済み？
俺だったらそんなソース突っ返すがな。
汚いソースは人に迷惑（必要以上の時間の浪費とストレス）かけるという意味
では十分に犯罪だぜ。
俺だったらそんなソース突っ返すがな。
汚いソースは人に迷惑（必要以上の時間の浪費とストレス）かけるという意味
では十分に犯罪だぜ。
250 ：仕様書無しさん：2007/02/04(日) 04:59:34
ＯＯだろうがなにがなんでも膨大なソースを作って客から金を巻き上げる。
それが商売なんだよ。
それが商売なんだよ。
251 ：仕様書無しさん：2007/02/04(日) 05:08:31
客が興味あるのはソースの膨大さではない。品質と納期とコストだ。
コストって固定だろ。受注金額のことだよね
受注側が「増やして」と言わない限り、
興味なんぞないだろ。
受注側が「増やして」と言わない限り、
興味なんぞないだろ。
ぐちゃぐちゃなソース書いて徒らに保守性下げて要員多量導入して（本来不要なはずの）誠実さをアピールして追加予算を営業力でとることを常としてる会社を俺は知っている。
まぁこんなところ多いんだろうけど。つまりこの世の経済ははおばかな会社とおばかな客でなりたっているんだな。
まぁこんなところ多いんだろうけど。つまりこの世の経済ははおばかな会社とおばかな客でなりたっているんだな。
256 ：仕様書無しさん：2007/02/04(日) 14:34:01
>>255
謀らずともそうなるプロジェクトに乾杯！
謀らずともそうなるプロジェクトに乾杯！
そのうちニュースになるかも知れんな。
「粉飾ステップ数疑惑」とかって。
「粉飾ステップ数疑惑」とかって。
259 ：仕様書無しさん：2007/02/04(日) 18:10:16
５００、６００ステップのクラスが３０ステップになっちゃマズイか？ﾔｯﾊﾟﾘ.ﾃﾞｷﾙﾝﾀﾞｹﾄﾞ
260 ：仕様書無しさん：2007/02/04(日) 18:18:34
VS2005スレから来ました、記念カキコです
VS2005スレ住人がお世話になっています
VS2005スレ住人がお世話になっています
>>257
あべしの社長とか逮捕されそう。
あべしの社長とか逮捕されそう。
我々の破壊工作が徐々に成果を上げているな
高圧線の鉄塔を倒したのは直ぐに我々の仕業だとばれてしまったが
ITのプロジェクトを徐々に潰していっても、いまだに誰にも気づかれない
日本人がオブジェクト思考を使い出すと厄介な事になるからな
我々の同士のなんとか学会はいい仕事してくれているよ
高圧線の鉄塔を倒したのは直ぐに我々の仕業だとばれてしまったが
ITのプロジェクトを徐々に潰していっても、いまだに誰にも気づかれない
日本人がオブジェクト思考を使い出すと厄介な事になるからな
我々の同士のなんとか学会はいい仕事してくれているよ
>>255
そのばかな客が金を持っているという現実は変えられないわけで。
そのばかな客が金を持っているという現実は変えられないわけで。
人生って辛いな。俺の子供にはこんな仕事させたくないな。
だが俺は我が道をゆく。そのうち改善されることを期待しつつ。
だが俺は我が道をゆく。そのうち改善されることを期待しつつ。
つうかこの業界もそろそろ資格制にすべきじゃね。
今はＩＴ技術者不足で、初心者ＯＫ、やれ作れやの雰囲気だけど
そのうち積もり積もった歪に耐え切れなくなって絶対亀裂が生じるぜ。
多分将来は今よりもうちょっと整理されたソフトウェア工学と英語能力
は必須になると思う。つうかしないとダメだろ。へんな期待もたせる方
がよっぽど酷だと思う。自殺者天国日本の悪名が高まるだけだぜ。
今はＩＴ技術者不足で、初心者ＯＫ、やれ作れやの雰囲気だけど
そのうち積もり積もった歪に耐え切れなくなって絶対亀裂が生じるぜ。
多分将来は今よりもうちょっと整理されたソフトウェア工学と英語能力
は必須になると思う。つうかしないとダメだろ。へんな期待もたせる方
がよっぽど酷だと思う。自殺者天国日本の悪名が高まるだけだぜ。
266 ：仕様書無しさん：2007/02/04(日) 19:31:48
>>265
お前、いつの時代から来たんだよｗ
浦島太郎にもほどがある。
もう、資格と実力がマッチしないことは明白になったから会社は実績しか見なくなったよ。
実績っつってもＣ＋＋の実務経験○年とか緩いもんだけど。
結局、資格とる奴って会社で仕事しないで資格の勉強だけしてたり、
おおよそ実務と結びつかない能力ばっかりもってる奴が多いんだよね。
最低限の仕事だけこなしたら終わったこと報告しないで資格の勉強してるとかしょっちゅうある。
まあ、これも資格所有者の態度が悪いせいもあるんだぜ。
自業自得っちゃそうだけど未経験の人はこれのおかげで入りにくくなったな。
お前、いつの時代から来たんだよｗ
浦島太郎にもほどがある。
もう、資格と実力がマッチしないことは明白になったから会社は実績しか見なくなったよ。
実績っつってもＣ＋＋の実務経験○年とか緩いもんだけど。
結局、資格とる奴って会社で仕事しないで資格の勉強だけしてたり、
おおよそ実務と結びつかない能力ばっかりもってる奴が多いんだよね。
最低限の仕事だけこなしたら終わったこと報告しないで資格の勉強してるとかしょっちゅうある。
まあ、これも資格所有者の態度が悪いせいもあるんだぜ。
自業自得っちゃそうだけど未経験の人はこれのおかげで入りにくくなったな。
いやだから、会社はいってから資格とるんじゃなくて、試験に受かった奴しか
法律として仕事できないようにしないと資格制の意味がないっつうの。
まぁ今の資格諸々の内容が実務に必ずしもそぐわないのは認めるけど、例えば
医師の国家試験とか、調理師免許とかみたく、（これらって実技もあるよね？）
試験内容に実務レベルのスキルが反映されるようになるにはもう少しこの業界
の成熟を待つ必要があるんだと思う。たかだかまだ４，５０年の産業でしょ。
法律として仕事できないようにしないと資格制の意味がないっつうの。
まぁ今の資格諸々の内容が実務に必ずしもそぐわないのは認めるけど、例えば
医師の国家試験とか、調理師免許とかみたく、（これらって実技もあるよね？）
試験内容に実務レベルのスキルが反映されるようになるにはもう少しこの業界
の成熟を待つ必要があるんだと思う。たかだかまだ４，５０年の産業でしょ。
268 ：仕様書無しさん：2007/02/04(日) 19:47:07
>>267
意味がない。
病院とか準看護師も正看護師も助産婦も結局同じ仕事をさせられてる状況と同じようになるだけ。
国家資格での括りは役に立たない。
だいたい、お前、誰かどういう形で規制することを前提にそんな議論してんだ？
よしんば手をだしても刑事事件扱いにならんと誰も動かないぞ。
労働基準法と同じくザル法で終わる。
意味がない。
病院とか準看護師も正看護師も助産婦も結局同じ仕事をさせられてる状況と同じようになるだけ。
国家資格での括りは役に立たない。
だいたい、お前、誰かどういう形で規制することを前提にそんな議論してんだ？
よしんば手をだしても刑事事件扱いにならんと誰も動かないぞ。
労働基準法と同じくザル法で終わる。
269 ：仕様書無しさん：2007/02/04(日) 19:49:02
ああ、そのまえに適切な試験を作ることのほうが難しいな。
詰め込み教育ではまともなプログラマは育たない。
暗記が得意なだけで頭がパーな奴を上に上げても仕方がないだろ？（職場にいねぇ？ｗ）
詰め込み教育ではまともなプログラマは育たない。
暗記が得意なだけで頭がパーな奴を上に上げても仕方がないだろ？（職場にいねぇ？ｗ）
271 ：仕様書無しさん：2007/02/04(日) 19:53:31
現状、資格やらセミナーやらは金儲けの道具にしか過ぎんし、
売りたいソフトを全面に出した資格を国家認定なんてしてしまうと賄賂が横行するだろうな。
社会整備のが先じゃねぇの？
売りたいソフトを全面に出した資格を国家認定なんてしてしまうと賄賂が横行するだろうな。
社会整備のが先じゃねぇの？
>>268
あぁ、じゃあ今の状況をどうしろと。俺はただ素人同然の奴が書いた
と思われるぐちゃぐちゃなソースをメンテするのにほとほと疲れ果てて
いるんだ。社内でいくらきちんとやってても外部からたまにこんなソー
スが俺の手元にまいこんでくる。自衛手段を講じなかった俺が悪いのか？
みんなそんなに世渡り上手なのか？ あぁもう疲れた。頭痛が痛い。氏ぬ。
あぁ、じゃあ今の状況をどうしろと。俺はただ素人同然の奴が書いた
と思われるぐちゃぐちゃなソースをメンテするのにほとほと疲れ果てて
いるんだ。社内でいくらきちんとやってても外部からたまにこんなソー
スが俺の手元にまいこんでくる。自衛手段を講じなかった俺が悪いのか？
みんなそんなに世渡り上手なのか？ あぁもう疲れた。頭痛が痛い。氏ぬ。
273 ：仕様書無しさん：2007/02/04(日) 20:05:40
>>272
その解決策に資格なんてのが役に立たないってだけ。
仮にお前が望む形にしてもなんの解決策にもならんし、
資格試験斡旋会社みたいなのが儲けて終わりってだけだろ？
結局、人を採用するのに人を見る手間を惜しんじゃいけないってことだよ。
その解決策に資格なんてのが役に立たないってだけ。
仮にお前が望む形にしてもなんの解決策にもならんし、
資格試験斡旋会社みたいなのが儲けて終わりってだけだろ？
結局、人を採用するのに人を見る手間を惜しんじゃいけないってことだよ。
>>273
採用した責任をその会社がとるならそれもそうかもしれない。
採用した責任をその会社がとるならそれもそうかもしれない。
今あるような試験じゃ無理かもしれんが、試験内容次第では一定の基準を
作ることはできるかもしれないな。例えば極端かもしれんが、Code Complete
に書かれてあるようなことを最低限理解し実践できるような素養をみる試験
とか。ま、今の状況とか環境では無理なのかもね。
作ることはできるかもしれないな。例えば極端かもしれんが、Code Complete
に書かれてあるようなことを最低限理解し実践できるような素養をみる試験
とか。ま、今の状況とか環境では無理なのかもね。
>>275
無理無理。
そのときだけのその問題に限って「だけ」できるようにしてくるだけでしょ。
色々金が絡んでくるとそんなもんだんだん関係なくなってくるし辞めたほうがいい。
人の採用を第三者にまかせる姿勢がそもそも失敗のはじまりなんだよ。
人をみずに仕事はできない。
無理無理。
そのときだけのその問題に限って「だけ」できるようにしてくるだけでしょ。
色々金が絡んでくるとそんなもんだんだん関係なくなってくるし辞めたほうがいい。
人の採用を第三者にまかせる姿勢がそもそも失敗のはじまりなんだよ。
人をみずに仕事はできない。
>>276
それは人材派遣業を批判していると理解していいのか？
それは人材派遣業を批判していると理解していいのか？
278 ：仕様書無しさん：2007/02/04(日) 20:31:38
>>277
別に、派遣だって面接ぐらいやるでしょ？
１時間やって見抜けないなら採用担当者が無能なだけだし批判なんてしてないよ。
そりゃ派遣がノータッチで入ってくるなら問題だけど。それって派遣じゃなくて請負いとか別の契約のときでしょ？
別に、派遣だって面接ぐらいやるでしょ？
１時間やって見抜けないなら採用担当者が無能なだけだし批判なんてしてないよ。
そりゃ派遣がノータッチで入ってくるなら問題だけど。それって派遣じゃなくて請負いとか別の契約のときでしょ？
どうも、>>276は技術云々より人をみてその人柄？で人を選んでるみたいだな。
その考え方って医師とか弁護士にもあてはまんの？
それって主観的なもんじゃね。Ａさんの好評価が必ずしもＢさんの評価と一致
するとは限らないと思うんだけど。ましてや面接時だけで判断できる自信が俺
にはないんだな。まぁ間考え方の違いだけど。俺はできることなら試験もして
その結果も考慮したい。
その考え方って医師とか弁護士にもあてはまんの？
それって主観的なもんじゃね。Ａさんの好評価が必ずしもＢさんの評価と一致
するとは限らないと思うんだけど。ましてや面接時だけで判断できる自信が俺
にはないんだな。まぁ間考え方の違いだけど。俺はできることなら試験もして
その結果も考慮したい。
誰が採点すんだゴルァって声が聞こえてきそうだな。
いや>>279さんはご自分でなさるんでしょうけど。
いや>>279さんはご自分でなさるんでしょうけど。
どうでもいいけど、俺、マコネル嫌い。
無駄に文章が冗長で、コードコンプリートはマコネルの知識自慢だから、
お金払ってまで読もうと言う気にならん。
もうちょっと情報は取捨選択しろと。
だいたいあの巻末の参考文献リストって何？必要なやつだけ書けっつーの。
あれはマコネルがこんなに本を読んでるという自慢にしか
役に立たん。参考文献って普通読者が孫引きするのに使うんだと
思ったがどうか。作者が読んだ本全部書けというのとは違う。
無駄に文章が冗長で、コードコンプリートはマコネルの知識自慢だから、
お金払ってまで読もうと言う気にならん。
もうちょっと情報は取捨選択しろと。
だいたいあの巻末の参考文献リストって何？必要なやつだけ書けっつーの。
あれはマコネルがこんなに本を読んでるという自慢にしか
役に立たん。参考文献って普通読者が孫引きするのに使うんだと
思ったがどうか。作者が読んだ本全部書けというのとは違う。
282 ：仕様書無しさん：2007/02/04(日) 20:44:45
>>279
技術的な質問なら１０分でもわかるよ。
ちゃんと深いところまで見てるかどうか？
やった人でないとわからないことまで話題に乗せることができるかどうかだけですぐわかるっしょ。
>技術云々より人をみてその人柄？で人を選んでるみたいだな。
>その考え方って医師とか弁護士にもあてはまんの？
そりゃそうでしょ？
例え医者だっていくら腕がよくても横領なんてしてる奴なんて病院ごと評判悪くなるでしょ？
弁護士だって事実を捻じ曲げて勝訴にもってくような奴なんて信じて戦えないでしょ？
試験じゃなにもわからないと思うがな、
というか、俺自身、「これが満足のいく試験だ」ってものが作れ無いからそう思う。
まあ、そのときその場所限りのもんならいいだろうけど、現場によって状況も違うしね。
汎用的なもん作るのはやっぱり難しいよ。
それにプログラムの試験なんて俺はプログラム作る以外無いと思ってるんだけど。
例えばWindowsのプログラムを作る試験を出したとしてＭＳＤＮやらインターネットの無い環境ってのがありえないんだよね。
そういうの考慮するとあんまり暗記でマス埋め問題やら、キーワードを埋める形の問題やらってのは
ほとんど意味がなくなるし。やっぱり、作らせてみるしかないかな？って思うんだよね。
技術的な質問なら１０分でもわかるよ。
ちゃんと深いところまで見てるかどうか？
やった人でないとわからないことまで話題に乗せることができるかどうかだけですぐわかるっしょ。
>技術云々より人をみてその人柄？で人を選んでるみたいだな。
>その考え方って医師とか弁護士にもあてはまんの？
そりゃそうでしょ？
例え医者だっていくら腕がよくても横領なんてしてる奴なんて病院ごと評判悪くなるでしょ？
弁護士だって事実を捻じ曲げて勝訴にもってくような奴なんて信じて戦えないでしょ？
試験じゃなにもわからないと思うがな、
というか、俺自身、「これが満足のいく試験だ」ってものが作れ無いからそう思う。
まあ、そのときその場所限りのもんならいいだろうけど、現場によって状況も違うしね。
汎用的なもん作るのはやっぱり難しいよ。
それにプログラムの試験なんて俺はプログラム作る以外無いと思ってるんだけど。
例えばWindowsのプログラムを作る試験を出したとしてＭＳＤＮやらインターネットの無い環境ってのがありえないんだよね。
そういうの考慮するとあんまり暗記でマス埋め問題やら、キーワードを埋める形の問題やらってのは
ほとんど意味がなくなるし。やっぱり、作らせてみるしかないかな？って思うんだよね。
> 試験じゃなにもわからないと思うがな、
これは明らかに違うよ。
「試験でわからない項目がある→試験で何もわからない」
んじゃなくて、
「試験でわからない項目がある→試験でわかることもある」
だと思うのだが、どうか。
試験が万能でないのは明らかだけど、試験はある一面を評価する
には役にたつ(暗記力や理解力、思考能力の一部の評価)ので、
入社試験ではやらないわけにはいかないと思うけどどうか。
試験で一番いいのは準備させずに抜き打ちでやるのが一番
いいと思うけどね。
試験ですべてを評価するのは愚かだけど、評価の一面として
試験をまったく無視するのも愚か。
これは明らかに違うよ。
「試験でわからない項目がある→試験で何もわからない」
んじゃなくて、
「試験でわからない項目がある→試験でわかることもある」
だと思うのだが、どうか。
試験が万能でないのは明らかだけど、試験はある一面を評価する
には役にたつ(暗記力や理解力、思考能力の一部の評価)ので、
入社試験ではやらないわけにはいかないと思うけどどうか。
試験で一番いいのは準備させずに抜き打ちでやるのが一番
いいと思うけどね。
試験ですべてを評価するのは愚かだけど、評価の一面として
試験をまったく無視するのも愚か。
どちらにしても試験を含めたいくつかの側面で同時に評価するのがいいと思う。
いや俺はやっぱりある程度の知識を備えた上で、その次に人となりの判断だ
と思う。滅多にないかもしれないが時には人命や人の生活に関わることも
あるこの仕事で、そんな主観的なものだけで判断する気には俺はなれない。
採用する側にもそれなりに責任のあることだし、もう少し根拠となるもの
にすがりたい気がするのはあまりにも小心者かなぁ。
と思う。滅多にないかもしれないが時には人命や人の生活に関わることも
あるこの仕事で、そんな主観的なものだけで判断する気には俺はなれない。
採用する側にもそれなりに責任のあることだし、もう少し根拠となるもの
にすがりたい気がするのはあまりにも小心者かなぁ。
これはもちろん冗談だが、
以下の仕様書に基づいて動作するアプリケーションを制限時間内に作れ。
手段は問わない。
とか言って、電源・ケース・キーボード・マウスと一通りのＰＣパーツ（もちろん全てリテール）＆ケーブル類及び開発ソフト数種類を渡す。
部屋にはＬＡＮコネクタと１００Ｖコンセントがある。
携帯は使用禁止、ジャミング稼動中。
さあどうしよう。
てな試験
以下の仕様書に基づいて動作するアプリケーションを制限時間内に作れ。
手段は問わない。
とか言って、電源・ケース・キーボード・マウスと一通りのＰＣパーツ（もちろん全てリテール）＆ケーブル類及び開発ソフト数種類を渡す。
部屋にはＬＡＮコネクタと１００Ｖコンセントがある。
携帯は使用禁止、ジャミング稼動中。
さあどうしよう。
てな試験
>>283
じゃ、具体的にどんな問題を出すの？
俺は暗記は全部業務に役に立たないと思ってるけど。
用語とその意味のセットみたいなもんな。
これは物を作る力と直結しないといいきれるよ（俺の経験だけどねｗ）
効果的な質問なら１時間もある面接の中でちょっと聞けばすむ話しじゃない？
なんで作るなら面接で質問できなくて、且つ、技術力が測れるものだけど、そんなのある？
なんか試験作ってやらせる時間が無駄じゃね？
じゃ、具体的にどんな問題を出すの？
俺は暗記は全部業務に役に立たないと思ってるけど。
用語とその意味のセットみたいなもんな。
これは物を作る力と直結しないといいきれるよ（俺の経験だけどねｗ）
効果的な質問なら１時間もある面接の中でちょっと聞けばすむ話しじゃない？
なんで作るなら面接で質問できなくて、且つ、技術力が測れるものだけど、そんなのある？
なんか試験作ってやらせる時間が無駄じゃね？
288 ：仕様書無しさん：2007/02/04(日) 21:02:37
>>286
それもその場限りだなぁ・・・
極端な話、自分でできなくても出来る奴に連絡とれて「ほい、完成」でもそれはそいつの能力だろ？
っていうか実際の業務の９５％が人との会話で成り立つもんなんだからその環境の想定は意味がないだろう。
それもその場限りだなぁ・・・
極端な話、自分でできなくても出来る奴に連絡とれて「ほい、完成」でもそれはそいつの能力だろ？
っていうか実際の業務の９５％が人との会話で成り立つもんなんだからその環境の想定は意味がないだろう。
１０人ぐらいいっしょに試験はじめて、
「好きな人とグループになって課題のソフトを完成させなさい」
って方が効果あるかもなｗ
グループに入れない奴はその場で不採用。
「好きな人とグループになって課題のソフトを完成させなさい」
って方が効果あるかもなｗ
グループに入れない奴はその場で不採用。
人の認定制度／資格制度ではなくて
生産物の品質認定制度はどうか。
生産物の品質認定制度はどうか。
>>292
仮に富士通みたいに東証止めたシステムとかはどういう評価になんの？
仮に富士通みたいに東証止めたシステムとかはどういう評価になんの？
>287
俺の個人的な経験を言うと、話をすると普通なんだけど、論理的
思考能力が壊滅的な人って結構いるよ。
逆に職場でアホだけど話はうまいって奴いない？
自分は話をしただけではその人がちゃんと論理的にものを
考えることができるかどうか判断できない。
試験ができる奴は暗記力がいいだけだ、と思い込んでいる人が
結構いるけど、普通にあるプログラムの穴埋め問題をさせるとか、
アルゴリズムに関する質問をするとかいうでは駄目か。
あんまり普通の試験と変わらないけどこれで十分意味があると思う。
単純に暗記だけじゃなく理解を伴う試験をだせば暗記力だけ、
というのは簡単に回避できると思うんだけど。
プログラムを書くとかいうのは、頭が悪くても誰でも経験を
積めばできるようになるのであんまり好きでない。
プログラミング言語から離れたアルゴリズムみたいなのを
新人にやらせるとめちゃくちゃ露骨にセンスの差がでるので
こっちの方が好きだ。
俺の個人的な経験を言うと、話をすると普通なんだけど、論理的
思考能力が壊滅的な人って結構いるよ。
逆に職場でアホだけど話はうまいって奴いない？
自分は話をしただけではその人がちゃんと論理的にものを
考えることができるかどうか判断できない。
試験ができる奴は暗記力がいいだけだ、と思い込んでいる人が
結構いるけど、普通にあるプログラムの穴埋め問題をさせるとか、
アルゴリズムに関する質問をするとかいうでは駄目か。
あんまり普通の試験と変わらないけどこれで十分意味があると思う。
単純に暗記だけじゃなく理解を伴う試験をだせば暗記力だけ、
というのは簡単に回避できると思うんだけど。
プログラムを書くとかいうのは、頭が悪くても誰でも経験を
積めばできるようになるのであんまり好きでない。
プログラミング言語から離れたアルゴリズムみたいなのを
新人にやらせるとめちゃくちゃ露骨にセンスの差がでるので
こっちの方が好きだ。
どんなに優秀な人でも一定レベル以上の技術者になるにはそれなりに年月が
かかるもんだから、面接ん時は適正検査程度でいんじゃねーの？探せばいくら
でもあるっしょ。この業界意外とつぶしがきかないよ。言語やＯＳ、経験した
技術や業務が違えば、一から勉強ってことはざらだし。適正検査でいいと思う。
ただこの業界常に勉強だから、適性検査がいくら優秀でも本人が怠け者だとど
うしようもないがな。
かかるもんだから、面接ん時は適正検査程度でいんじゃねーの？探せばいくら
でもあるっしょ。この業界意外とつぶしがきかないよ。言語やＯＳ、経験した
技術や業務が違えば、一から勉強ってことはざらだし。適正検査でいいと思う。
ただこの業界常に勉強だから、適性検査がいくら優秀でも本人が怠け者だとど
うしようもないがな。
>>294
>逆に職場でアホだけど話はうまいって奴いない？
それで世の中渡ってきたならさぞ優秀な人間を連れてくるに違いないに一票。
そういうの「だけ」ってのも困るけど、そういうの「も」いないとうまくいかないのもソフト開発だからね。
評価するべきだと思うよ。
あと俺が聞きたいのは具体的な試験問題なんだけどそれは出ないのかな？
>逆に職場でアホだけど話はうまいって奴いない？
それで世の中渡ってきたならさぞ優秀な人間を連れてくるに違いないに一票。
そういうの「だけ」ってのも困るけど、そういうの「も」いないとうまくいかないのもソフト開発だからね。
評価するべきだと思うよ。
あと俺が聞きたいのは具体的な試験問題なんだけどそれは出ないのかな？
>296
だから試験自体は
> 普通にあるプログラムの穴埋め問題をさせるとか、アルゴリズムに
> 関する質問をするとかいうでは駄目か。
と書いているんだが。後は適正試験とか。
これでもわからんことに関してははそもそも試験でそういうのを
測ろうというのが間違いなので、別途他の面接や見習い期間の
ようなもんでカバーする。
> そういうの「だけ」ってのも困るけど、そういうの「も」いないとうまくいかないのもソフト開発だからね。
だから、口頭だけだと「だけ」って奴が通ってしまうんだよ。
ペーパー試験だけで「暗記力だけ」って奴が通るように。
まあ、そもそもアホで口がうまいというやつは、個人的に痛い目に
あっているので私怨が入っているがｗ
だから試験自体は
> 普通にあるプログラムの穴埋め問題をさせるとか、アルゴリズムに
> 関する質問をするとかいうでは駄目か。
と書いているんだが。後は適正試験とか。
これでもわからんことに関してははそもそも試験でそういうのを
測ろうというのが間違いなので、別途他の面接や見習い期間の
ようなもんでカバーする。
> そういうの「だけ」ってのも困るけど、そういうの「も」いないとうまくいかないのもソフト開発だからね。
だから、口頭だけだと「だけ」って奴が通ってしまうんだよ。
ペーパー試験だけで「暗記力だけ」って奴が通るように。
まあ、そもそもアホで口がうまいというやつは、個人的に痛い目に
あっているので私怨が入っているがｗ
298 ：仕様書無しさん：2007/02/04(日) 21:24:14
追記
> そういうの「も」いないとうまくいかないのもソフト開発だからね。
とうのは当たり前で俺は最初から否定してないよ。
話が下手なのは本人も困るし周りも困る。
> そういうの「も」いないとうまくいかないのもソフト開発だからね。
とうのは当たり前で俺は最初から否定してないよ。
話が下手なのは本人も困るし周りも困る。
>298
そういうあなたも試験だけできる奴とは一緒に仕事したくないんでしょ。
同じじゃないかｗ
いや、俺は試験も会話も両方できないと駄目。
そういうあなたも試験だけできる奴とは一緒に仕事したくないんでしょ。
同じじゃないかｗ
いや、俺は試験も会話も両方できないと駄目。
じゃぁ、新人扮するベテランプログラマと一緒にソートのプログラムでも作ってみればいんじゃないの？
グループでどうこうでもいいけどさ。
グループでどうこうでもいいけどさ。
おまえらこんなことでいがみあうようでは精神的にまだまだだな。
俺が上司なら、「チームの和を乱す傾向あり」っとチェックつけとくな。
期末評価気をつけろよ。お前らが人の採用云々の話は１０年早いわ。
俺が上司なら、「チームの和を乱す傾向あり」っとチェックつけとくな。
期末評価気をつけろよ。お前らが人の採用云々の話は１０年早いわ。
>>301
ソートなんてどっかのサイトからコピってきて貼って終わりだろ。
ソートなんてどっかのサイトからコピってきて貼って終わりだろ。
>>305
誰も聞いてないよｗ
誰も聞いてないよｗ
モデルを、どう見るか…で、オブジェクト（クラス）の別け方は、異なる。
ある「見方」で綺麗にまとめられているシステムでも
別の「見方」による要求が出て来た時に、例外を導入せざるを得なくなる。
それが積み重なると…
一元的な見方の単純システムが、すべての場合に対応できるなんて、思うのが間違い。
現実問題は、ほとんど、イル・ストラクチャなのだ。
イル・ストラクチャを、最も効率的に（その場あたり的に…と同義）解決するのが
goto文と、大域変数による情報の受け渡し＆保持だ。
その結果は？・・・・・・雑化して保守不可能なカオスコード！
プログラマは考える。
これでは、いけない！
もっと表現力に優れた（体系的な表現が出来て）、拡張性と保守性に優れた
新しい「何か」が必要だと。
その無限サイクルの中で、一見役に立ちそうで、機能不十分な「何か」が
無限に生み出されて行くのだ。
ある「見方」で綺麗にまとめられているシステムでも
別の「見方」による要求が出て来た時に、例外を導入せざるを得なくなる。
それが積み重なると…
一元的な見方の単純システムが、すべての場合に対応できるなんて、思うのが間違い。
現実問題は、ほとんど、イル・ストラクチャなのだ。
イル・ストラクチャを、最も効率的に（その場あたり的に…と同義）解決するのが
goto文と、大域変数による情報の受け渡し＆保持だ。
その結果は？・・・・・・雑化して保守不可能なカオスコード！
プログラマは考える。
これでは、いけない！
もっと表現力に優れた（体系的な表現が出来て）、拡張性と保守性に優れた
新しい「何か」が必要だと。
その無限サイクルの中で、一見役に立ちそうで、機能不十分な「何か」が
無限に生み出されて行くのだ。
308 ：仕様書無しさん：2007/02/04(日) 22:42:28
誰か、>>307を3行程度にまとめてくんない？
む
り
ぽ
り
ぽ
ぬ
こ
飯
こ
飯
似たようなプログラムを延々とバージョンアップする
(桃鉄とか)ならば、設計に長い時間を使ってもいいけどさ
殆どの場合は、毎回予想外のリクエストで構造がぶっ壊れるんだから
もっと気楽に作った方がいいだろ。
全てトレードオフだよ。
毎回スクラッチするから、飯の種になりえているわけで。
(桃鉄とか)ならば、設計に長い時間を使ってもいいけどさ
殆どの場合は、毎回予想外のリクエストで構造がぶっ壊れるんだから
もっと気楽に作った方がいいだろ。
全てトレードオフだよ。
毎回スクラッチするから、飯の種になりえているわけで。
312 ：仕様書無しさん：2007/02/05(月) 00:00:14
ぶっちゃけ、OODってメチャ難しいよな？
ぬるくわかってる奴は多いかもしれないが、明確にわかっている奴はほとんどいないよな。
だから、普及しないわけだよな。
構造化設計なら簡単で誰でも実践可能ってわけじゃないしな。
結局、現時点で一般に普及している確たる設計手法なんて何もないしな。
ことさらOODが普及してないってのもなんだかおかしな話だよな。
それなりに分かってる奴なら今時はOODでやってるって、ただそれだけの話だよな。
結局、現時点で一般に普及している確たる設計手法なんて何もないしな。
ことさらOODが普及してないってのもなんだかおかしな話だよな。
それなりに分かってる奴なら今時はOODでやってるって、ただそれだけの話だよな。
まず、現状なり自分のやり方を絶対と考えるのが
大きな間違い。
採用云々で論じてた輩なんかはその典型だな。
要は銀の弾丸はない訳だ。
今のやり方だって数年後には
笑い話になってるかもしれないしな。
日本の場合は業務にしろ何にしろ、
もっとオープンにするのが第一だな。
そうすれば、教育効果もあるし
下手なコード書く輩も減るだろうし
車輪の再生産的な事も減るだろう。
問題は日本人はそういう類のコミュニケーションが
著しく下手な事だな…
案外、外人が主導した方がうまくいくかもしれんな。
大きな間違い。
採用云々で論じてた輩なんかはその典型だな。
要は銀の弾丸はない訳だ。
今のやり方だって数年後には
笑い話になってるかもしれないしな。
日本の場合は業務にしろ何にしろ、
もっとオープンにするのが第一だな。
そうすれば、教育効果もあるし
下手なコード書く輩も減るだろうし
車輪の再生産的な事も減るだろう。
問題は日本人はそういう類のコミュニケーションが
著しく下手な事だな…
案外、外人が主導した方がうまくいくかもしれんな。
評論家気取り乙
>315
スレのレベルが下がり気味と思ったから
書き込んだまでだ。
お前はもちろん何も書き込まなくていいぞ。
他へ逝けw
スレのレベルが下がり気味と思ったから
書き込んだまでだ。
お前はもちろん何も書き込まなくていいぞ。
他へ逝けw
まあOODがベストではないがベターだから取りあえず使ってます
って人は多いだろ。
って人は多いだろ。
>>314さん
＞まず、現状なり自分のやり方を絶対と考えるのが
＞大きな間違い。
＞採用云々で論じてた輩なんかはその典型だな。
＞要は銀の弾丸はない訳だ。
>>315さんはこのあたりに反応したのかと想像します。
設計手法にしても、（スレ違いではありますが）採用方法にしても、その時々で最善の判断し、結論を出すしかない訳で。
このレスを読むと、あなたはあなた自身の語っていることこそが「銀の弾丸」であると考えているようにも受け取れます。
＞今のやり方だって数年後には
＞笑い話になってるかもしれないしな。
これはあなた自身はOODは数年後に笑い話になると考えている、ということですか？
ま、そうでなくても、あなたなりの設計手法に関してのビジョンを提示して頂かないと議論にはなりませんよね。
＞日本の場合は業務にしろ何にしろ、
＞もっとオープンにするのが第一だな。
「業務にしろ何にしろ」とは具体的に何を指しているのかよくわかりませんが。
顧客側の業務ですか？それともシステムを開発する側の業務のことでしょうか？
その「業務にしろ何にしろ」をオープンにすればOODが流行ると考えている、ということですか？
＞そうすれば、教育効果もあるし
＞下手なコード書く輩も減るだろうし
＞車輪の再生産的な事も減るだろう。
そもそも何をオープンにするのか良くわかりませんが、自分なりに想像するに。
僕はOODに理解が無いプロジェクトメンバーにOODを教える労力が楽になるとは思えませんね。
下手なコードを書く輩が減るとも思えません。
＞問題は日本人はそういう類のコミュニケーションが
＞著しく下手な事だな…
（２ちゃんの中ですらまともに議論出来ないあなたのような）まともな議論の出来ない人が多いとは僕も思います。
スルー出来なくてすいません＞スレの皆様
＞まず、現状なり自分のやり方を絶対と考えるのが
＞大きな間違い。
＞採用云々で論じてた輩なんかはその典型だな。
＞要は銀の弾丸はない訳だ。
>>315さんはこのあたりに反応したのかと想像します。
設計手法にしても、（スレ違いではありますが）採用方法にしても、その時々で最善の判断し、結論を出すしかない訳で。
このレスを読むと、あなたはあなた自身の語っていることこそが「銀の弾丸」であると考えているようにも受け取れます。
＞今のやり方だって数年後には
＞笑い話になってるかもしれないしな。
これはあなた自身はOODは数年後に笑い話になると考えている、ということですか？
ま、そうでなくても、あなたなりの設計手法に関してのビジョンを提示して頂かないと議論にはなりませんよね。
＞日本の場合は業務にしろ何にしろ、
＞もっとオープンにするのが第一だな。
「業務にしろ何にしろ」とは具体的に何を指しているのかよくわかりませんが。
顧客側の業務ですか？それともシステムを開発する側の業務のことでしょうか？
その「業務にしろ何にしろ」をオープンにすればOODが流行ると考えている、ということですか？
＞そうすれば、教育効果もあるし
＞下手なコード書く輩も減るだろうし
＞車輪の再生産的な事も減るだろう。
そもそも何をオープンにするのか良くわかりませんが、自分なりに想像するに。
僕はOODに理解が無いプロジェクトメンバーにOODを教える労力が楽になるとは思えませんね。
下手なコードを書く輩が減るとも思えません。
＞問題は日本人はそういう類のコミュニケーションが
＞著しく下手な事だな…
（２ちゃんの中ですらまともに議論出来ないあなたのような）まともな議論の出来ない人が多いとは僕も思います。
スルー出来なくてすいません＞スレの皆様
資格制度なんか全廃してもいいよ。
肩書きをまずなんとかしようって思って生きてきた奴が
現場で通用することはほぼない。
肩書きをまずなんとかしようって思って生きてきた奴が
現場で通用することはほぼない。
オープンなのは股間の社会の窓だけだなｗ
321 ：おじゃばさま：2007/02/05(月) 10:01:06
銀の弾はないと嘆いている人の多くは、単に問題分析が出来てないだけの場合が多い。
だから設計がどうのと言う以前に、問題分析の方法を学ぶべきだ。
面接では「その人間が今どのぐらい出来るか」は分かっても「その人間がこの先出来るようになるか」は
絶対に分からない。
だから設計がどうのと言う以前に、問題分析の方法を学ぶべきだ。
面接では「その人間が今どのぐらい出来るか」は分かっても「その人間がこの先出来るようになるか」は
絶対に分からない。
銀の弾丸なんて無いよ。
嘆いてはいないけど
嘆いてはいないけど
>>324
いや、人を見るってのは相当難しいよ。
「上手く行けば成長して柱になれるかな」くらいは
判っても、本当にそうなるかどうかなんて神様じゃ
なきゃ判らん。逆にそれほど期待してなくても、
「まあ入れといてもいいか」くらいの奴が伸びたりさ。
ある程度の範囲で掴むことは出来ても、ピンポイントで
把握するのは難しいよな。俺が未熟っちゃそうなんだが
相当キャリアあっても、人を見直したりするのは茶飯事だな。
いや、人を見るってのは相当難しいよ。
「上手く行けば成長して柱になれるかな」くらいは
判っても、本当にそうなるかどうかなんて神様じゃ
なきゃ判らん。逆にそれほど期待してなくても、
「まあ入れといてもいいか」くらいの奴が伸びたりさ。
ある程度の範囲で掴むことは出来ても、ピンポイントで
把握するのは難しいよな。俺が未熟っちゃそうなんだが
相当キャリアあっても、人を見直したりするのは茶飯事だな。
>>326
行末に「ｗ」つける莫迦は放置の方向で。
行末に「ｗ」つける莫迦は放置の方向で。
>318
設計の話から脱線したのは、
独り善がりな採用方法の話があまりに見苦しく感じたから。
それで代案として
業務内容等のオープン化を出した訳だが、
大雑把な話では企業より大きい枠での協力体制とか。
具体的かつ現実的な所では技術の共有化とか。
飯の種が無くなる事を
危惧する人もいるだろう。
しかし、俺はそうする事で
日本の相対的な価値が高まる方が得と考える。
設計の話から脱線したのは、
独り善がりな採用方法の話があまりに見苦しく感じたから。
それで代案として
業務内容等のオープン化を出した訳だが、
大雑把な話では企業より大きい枠での協力体制とか。
具体的かつ現実的な所では技術の共有化とか。
飯の種が無くなる事を
危惧する人もいるだろう。
しかし、俺はそうする事で
日本の相対的な価値が高まる方が得と考える。
>318
OOの話に戻ると
現状はベターな考え方と思うが、
必ずもっと良い方法が生まれると思う。
それを言いたかったけど
少なくてもお前には伝わらなかった様だな。
あと、業務等のオープン化で
下手なコードが減る事はないと話てるが、
上手なコードや人が増えればいい訳だろ。
お前は変な所でネガティブだな。
俺もお前の書き込みは
納得いくものは一つもなかったよ。
OOの話に戻ると
現状はベターな考え方と思うが、
必ずもっと良い方法が生まれると思う。
それを言いたかったけど
少なくてもお前には伝わらなかった様だな。
あと、業務等のオープン化で
下手なコードが減る事はないと話てるが、
上手なコードや人が増えればいい訳だろ。
お前は変な所でネガティブだな。
俺もお前の書き込みは
納得いくものは一つもなかったよ。
>>329-330は自演っぽいなｗ
で、ずっとROMってた俺も横レスですけど。
＞下手なコード書く輩も減るだろうし
って、お前自分で書いてるじゃんかｗ
＞必ずもっと良い方法が生まれると思う。
これには俺も「おめでたい評論家気取り乙」という言葉を送りたい。
煽るつもりも無いけど、もっと具体的に書いてくれるとおもろいんじゃね？
おもしろくもない話しかでてこない気もするがｗ
で、ずっとROMってた俺も横レスですけど。
＞下手なコード書く輩も減るだろうし
って、お前自分で書いてるじゃんかｗ
＞必ずもっと良い方法が生まれると思う。
これには俺も「おめでたい評論家気取り乙」という言葉を送りたい。
煽るつもりも無いけど、もっと具体的に書いてくれるとおもろいんじゃね？
おもしろくもない話しかでてこない気もするがｗ
> 上手なコードや人が増えればいい訳だろ。
だから、これをどうやって実現するのかを話して欲しいのだが
だから、これをどうやって実現するのかを話して欲しいのだが
>331
汎用の観点から
アセンブラ→C→C++という流れもあった訳だし、
現状が増え続ける物量への
最適な方法な訳ではないのはどの分野でも自明だろうが。
素人レベルに例示はしないけどなw
少しは自分で調べてみ？
それと、下手なコードや人はそれこそ無限にあるんだよw
上手なコードや人が増えれば
相対的に下手なものを相手する事が減るだろ。
お前って本当に馬鹿だなw
あと、>330氏は別の人だぞ。
俺の意見に部分的に賛成みたいだな。
まぁ、うれしいけどな。
自演話は想像もしなかった。
むしろ、お前の方が怪しいんじゃね？
汎用の観点から
アセンブラ→C→C++という流れもあった訳だし、
現状が増え続ける物量への
最適な方法な訳ではないのはどの分野でも自明だろうが。
素人レベルに例示はしないけどなw
少しは自分で調べてみ？
それと、下手なコードや人はそれこそ無限にあるんだよw
上手なコードや人が増えれば
相対的に下手なものを相手する事が減るだろ。
お前って本当に馬鹿だなw
あと、>330氏は別の人だぞ。
俺の意見に部分的に賛成みたいだな。
まぁ、うれしいけどな。
自演話は想像もしなかった。
むしろ、お前の方が怪しいんじゃね？
>332
上手なコードや人と接する機会が増えると言っているのに
実現方法がわからないのかよ。
ゆとり馬鹿？単なる低レベル？
>331や>332は書き込みだけで
馬鹿が筒抜けになってるなw
レベルもほとんど同じみたいだし、自演なんだろw
上手なコードや人と接する機会が増えると言っているのに
実現方法がわからないのかよ。
ゆとり馬鹿？単なる低レベル？
>331や>332は書き込みだけで
馬鹿が筒抜けになってるなw
レベルもほとんど同じみたいだし、自演なんだろw
335 ：おじゃばさま：2007/02/06(火) 09:56:32
採用と設計を変えれば、下手なコードを書く人が減ると言うのだろうか？
少し考えればそれは非常に困難だと気が付く。
仕事の出来る中途を定量的に採用するのは困難だし、設計方針を変えても理解出来なければ意味ない。
この問題点は「新人教育」にある。
多くの企業が結果重視を採用したため、新人教育という文化が廃れてしまった。
社員は新人教育によっては評価されず、またライバルがいない方が安心である。
結果的に新人は放置され、放置された新人が先輩になり、さらなる被害を生んだ。
これを解消するのは簡単である。
新人教育をすればいい。しかしここで言う新人教育とは、セミナーのような講習会とは違う。
いわばOJTだが、付きっきりで教えるのでもない。単にその新人に出来る仕事をやらせてサポートしつつ、
段階的に難易度を上げて行くだけである。
しかし実際には給料体系を含めて変える必要があるだろう。
少し考えればそれは非常に困難だと気が付く。
仕事の出来る中途を定量的に採用するのは困難だし、設計方針を変えても理解出来なければ意味ない。
この問題点は「新人教育」にある。
多くの企業が結果重視を採用したため、新人教育という文化が廃れてしまった。
社員は新人教育によっては評価されず、またライバルがいない方が安心である。
結果的に新人は放置され、放置された新人が先輩になり、さらなる被害を生んだ。
これを解消するのは簡単である。
新人教育をすればいい。しかしここで言う新人教育とは、セミナーのような講習会とは違う。
いわばOJTだが、付きっきりで教えるのでもない。単にその新人に出来る仕事をやらせてサポートしつつ、
段階的に難易度を上げて行くだけである。
しかし実際には給料体系を含めて変える必要があるだろう。
>>335
単なる理想論で終わることが多すぎ
そのレスなんざその典型だ
>しかし実際には給料体系を含めて変える必要があるだろう。
これだけでは話が進まない。
そしてここに突っ込んだレスをしても無視するだろ。
「下手なコードを書く人を減らす為の、
その提示した新人教育にはどれだけの期間と費用がかかって、
その期間と費用に見合う効果がどれだけあるか」
まで書かないと説得力が無いだろ
単なる理想論で終わることが多すぎ
そのレスなんざその典型だ
>しかし実際には給料体系を含めて変える必要があるだろう。
これだけでは話が進まない。
そしてここに突っ込んだレスをしても無視するだろ。
「下手なコードを書く人を減らす為の、
その提示した新人教育にはどれだけの期間と費用がかかって、
その期間と費用に見合う効果がどれだけあるか」
まで書かないと説得力が無いだろ
>>335
2点。あと、おまえの力試しに付き合うのは飽きた。
2点。あと、おまえの力試しに付き合うのは飽きた。
>>338
市ねコボラ
市ねコボラ
自作自演ってなんなのさー。 OTZ...
なんかスレが荒れてるけど、まぁいいや。
出来る人が増えると糞コード(と、スレタイに則って設計も)が減るかどうかだが、
個々のマが定量的に把握するのはちょっと難しいかもしれない。マクロ的な結果なので。
ざっくりと言えば、良貨は悪貨を駆逐する。
割と誰でも経験あることとおもうが、
そこそこにきちんと出来る人(＝プロジェクトに必要な知識を持った人)が多い
プロジェクトだと、スムースに事が運んだり、不安が少なくて済まないか？
費用対効果が一番大きいのは、>>335の言う新人教育と思うが、
その理由は機会があれば、書きたい。
イラネだったらやめとく。
>>335
その方法へ移行期が先輩の新人潰しが一番激しくなるよ。
新人の時ほったらかされた先輩が居る間は。
なんかスレが荒れてるけど、まぁいいや。
出来る人が増えると糞コード(と、スレタイに則って設計も)が減るかどうかだが、
個々のマが定量的に把握するのはちょっと難しいかもしれない。マクロ的な結果なので。
ざっくりと言えば、良貨は悪貨を駆逐する。
割と誰でも経験あることとおもうが、
そこそこにきちんと出来る人(＝プロジェクトに必要な知識を持った人)が多い
プロジェクトだと、スムースに事が運んだり、不安が少なくて済まないか？
費用対効果が一番大きいのは、>>335の言う新人教育と思うが、
その理由は機会があれば、書きたい。
イラネだったらやめとく。
>>335
その方法へ移行期が先輩の新人潰しが一番激しくなるよ。
新人の時ほったらかされた先輩が居る間は。
悪貨生産者が、生産しているものが悪貨であることをまず認めないとね
>そこそこにきちんと出来る人(＝プロジェクトに必要な知識を持った人)が多い
>プロジェクトだと、スムースに事が運んだり、不安が少なくて済まないか？
それは正しいが。
プロジェクトに必要な知識を持った人が少ない場合のことをツッコンデイイ？
>プロジェクトだと、スムースに事が運んだり、不安が少なくて済まないか？
それは正しいが。
プロジェクトに必要な知識を持った人が少ない場合のことをツッコンデイイ？
>>342
それはそれで、聞きたい。
それはそれで、聞きたい。
技術系の給与水準が低い
－＞いい新人が来ない＆教育費が出ない
－＞技術水準が低い
－＞給与水準が低い
の悪循環をなんとかしないとなあ。
プログラミング技術ってのはすごいものなんだ、金を出す価値があるんだ、
っていう感覚がなくなっちゃったのかなあ。
－＞いい新人が来ない＆教育費が出ない
－＞技術水準が低い
－＞給与水準が低い
の悪循環をなんとかしないとなあ。
プログラミング技術ってのはすごいものなんだ、金を出す価値があるんだ、
っていう感覚がなくなっちゃったのかなあ。
345 ：おじゃばさま：2007/02/07(水) 09:12:43
>336
新人教育の方法は非常に難しい。もう少し正確に言うと、教師を選ぶのが非常に難しい。
この教師の選び方により、コスト、期間、効果は大幅に変わってくる。
教師は特別に優秀な技術者である必要はない。ある程度の技術力があり、それを簡単に説明出来る能力を持ち、
新人の尊敬を得るテクニックを知っていて、精神的に大人であれば良い。
コストと言っても講習会をやる訳でもないので、単純には計算出来ない。
新人が一人前の仕事が出来るまでの給料と、教師が教育に割く労力がコストになるが、これも新人の成長度、
教師が新人を使う効率によって大幅に変わる。
あまり参考にはならないが、教師が1人の新人を教育しつつ作業するとすると一人につき約20%程度の
能力が落ちる。まあ1人～2人が妥当だ。5人付けたら教師は教育で手一杯だろう。
ただしうまく組み合わせることにより（例えば新人同士をライバルに仕立てる）労力は大幅に変わる。
また教師は通常全力を出してない事が多いため、40%の労力でも無視出来る場合も多い。
期間は人による。まあ、半年～3年と言う所だろう。
では講師1人に新人を2人付けたとして計算しよう。講師の定時内余剰処理能力が20%あったとし20%を無視。
新人が100%の能力を得るまで1年半として、0%から段階的に100%まで上昇するとして平均50%。2人で100%。
教師のコストが100万で、新人が50万だとする。
教師は100万×20%×18カ月=360万、新人が50万×100%×18カ月=900万、計1260万円
ただし労的コストと実際のコストは違うので、意味がないと言えるが、とりあえず数字が欲しい
みたいなので書いてみた。やぱり教育には労力がかかるんだなと言うのが感想かな。
新人教育の方法は非常に難しい。もう少し正確に言うと、教師を選ぶのが非常に難しい。
この教師の選び方により、コスト、期間、効果は大幅に変わってくる。
教師は特別に優秀な技術者である必要はない。ある程度の技術力があり、それを簡単に説明出来る能力を持ち、
新人の尊敬を得るテクニックを知っていて、精神的に大人であれば良い。
コストと言っても講習会をやる訳でもないので、単純には計算出来ない。
新人が一人前の仕事が出来るまでの給料と、教師が教育に割く労力がコストになるが、これも新人の成長度、
教師が新人を使う効率によって大幅に変わる。
あまり参考にはならないが、教師が1人の新人を教育しつつ作業するとすると一人につき約20%程度の
能力が落ちる。まあ1人～2人が妥当だ。5人付けたら教師は教育で手一杯だろう。
ただしうまく組み合わせることにより（例えば新人同士をライバルに仕立てる）労力は大幅に変わる。
また教師は通常全力を出してない事が多いため、40%の労力でも無視出来る場合も多い。
期間は人による。まあ、半年～3年と言う所だろう。
では講師1人に新人を2人付けたとして計算しよう。講師の定時内余剰処理能力が20%あったとし20%を無視。
新人が100%の能力を得るまで1年半として、0%から段階的に100%まで上昇するとして平均50%。2人で100%。
教師のコストが100万で、新人が50万だとする。
教師は100万×20%×18カ月=360万、新人が50万×100%×18カ月=900万、計1260万円
ただし労的コストと実際のコストは違うので、意味がないと言えるが、とりあえず数字が欲しい
みたいなので書いてみた。やぱり教育には労力がかかるんだなと言うのが感想かな。
346 ：仕様書無しさん：2007/02/07(水) 15:58:24
真性キチガイ ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
↑この世にはプログラマに向いてる奴と向いてない奴がいて、向いてない奴には
｜いくらいい教師でも、まともなコードを書かせるのは至難のわざであり、また
∟みたいに、なんの役にも立たない煽りを書く奴にいいコードを書けるわけがな
いことだけは、俺にもなんとなくわかるようになってきた。
つまり、放漫な奴、傲岸不遜な奴のコードをみるといつも手抜きの痕跡がみられ、
そんな奴のコードで、きれいなコードというものはいまだかつてみたことがない。
センスも大事だが、多分、性格もプログラマの資質に大きく関係しているのだと
思う。
｜いくらいい教師でも、まともなコードを書かせるのは至難のわざであり、また
∟みたいに、なんの役にも立たない煽りを書く奴にいいコードを書けるわけがな
いことだけは、俺にもなんとなくわかるようになってきた。
つまり、放漫な奴、傲岸不遜な奴のコードをみるといつも手抜きの痕跡がみられ、
そんな奴のコードで、きれいなコードというものはいまだかつてみたことがない。
センスも大事だが、多分、性格もプログラマの資質に大きく関係しているのだと
思う。
348 ：＼＿＿＿＿＿ ＿＿＿＿＿＿／：2007/02/07(水) 17:58:13
∨ ﾉ
__ /
/⌒ ヽ ／ ／
（ ）'ﾞヽ. _／
. ／iｰ-‐'"i ,; ／
i ! （ ヽ. ） ﾉ/ .:／
（＼.ﾞヽ＿（_／,ｲ／
i ! （＼＼＿,＿）' ﾉ
（＼＼＿,＿,）'
i ! l ,i＼ ヽ､ !
し'
__ /
/⌒ ヽ ／ ／
（ ）'ﾞヽ. _／
. ／iｰ-‐'"i ,; ／
i ! （ ヽ. ） ﾉ/ .:／
（＼.ﾞヽ＿（_／,ｲ／
i ! （＼＼＿,＿）' ﾉ
（＼＼＿,＿,）'
i ! l ,i＼ ヽ､ !
し'
349 ：仕様書無しさん：2007/02/07(水) 22:20:05
嵐がやってきた
変身忍者 嵐
コードコンプリート読め。
なんでマコネルの自慰ショーをここで勧めるか
流行ってるとか流行ってないって結局主観なんだから。
それより、今やるべきことはなんなんだ？
皆さんどうお考えですか？
モデル工藤なんてどうよ？
モデリングの修行を積んで、UML2.0に強くなって、OCLもきちんと勉強しとけばいいんでない？
きちんとモデル書いたらきちんとしたコード吐いてくれる時代がまもなく来るような気がするんだけど。
そのためのUML2.0だと思うし。
で、肝はやっぱりモデリングなんだからさ、OOちゃんとやっとくべきなんだと思うんだけど。
で、結局実装を意識したレベルのモデリングまで必要になるんだからさ、Javaしっかりやっとけばいいんでない？
流行るかどうかは別にして、食いっぱぐれは無いような気がする。
甘い？
それより、今やるべきことはなんなんだ？
皆さんどうお考えですか？
モデル工藤なんてどうよ？
モデリングの修行を積んで、UML2.0に強くなって、OCLもきちんと勉強しとけばいいんでない？
きちんとモデル書いたらきちんとしたコード吐いてくれる時代がまもなく来るような気がするんだけど。
そのためのUML2.0だと思うし。
で、肝はやっぱりモデリングなんだからさ、OOちゃんとやっとくべきなんだと思うんだけど。
で、結局実装を意識したレベルのモデリングまで必要になるんだからさ、Javaしっかりやっとけばいいんでない？
流行るかどうかは別にして、食いっぱぐれは無いような気がする。
甘い？
354 ：おじゃばさま：2007/02/08(木) 09:29:18
>347
つまり347の言いたい事は、きれいなコードを書くならセンスとマメな性格が必要だと言う事だろうか？
ちなみにセンスとマメな性格をを与える教育方法を教えてもらわないと、347の書き込みは
俺の計算式と同様「なんの役にも立たない煽り」になると思うのだがどうだろう？
それとも自分のコードは汚いと遠回しに言っているのだろうか？
しかし安心してくれ。
煽りと汚いコードに関連はないだろう。なぜなら俺のコードはきれいだからだ。
おそらくここで言う、きれいなコードは「他人が見ても理解しやすいコード」だろう。
それは適切なコーディングルールを決めて、コードチェックする事により、多くの場合がクリアされる
だろう。ただセンスとマメな性格の教育方法は、興味があるので教えていただきたい。
つまり347の言いたい事は、きれいなコードを書くならセンスとマメな性格が必要だと言う事だろうか？
ちなみにセンスとマメな性格をを与える教育方法を教えてもらわないと、347の書き込みは
俺の計算式と同様「なんの役にも立たない煽り」になると思うのだがどうだろう？
それとも自分のコードは汚いと遠回しに言っているのだろうか？
しかし安心してくれ。
煽りと汚いコードに関連はないだろう。なぜなら俺のコードはきれいだからだ。
おそらくここで言う、きれいなコードは「他人が見ても理解しやすいコード」だろう。
それは適切なコーディングルールを決めて、コードチェックする事により、多くの場合がクリアされる
だろう。ただセンスとマメな性格の教育方法は、興味があるので教えていただきたい。
>>354
「人が見ても理解しやすい」ってのは人によって大きな開きがある。
共通部分をまとめたり、OOPの方がわかりやすいという人もいれば
処理順序がわかりやすいという理由でスパゲッティの方が読みやすいという人もいる。
「人が見ても理解しやすい」ってのは人によって大きな開きがある。
共通部分をまとめたり、OOPの方がわかりやすいという人もいれば
処理順序がわかりやすいという理由でスパゲッティの方が読みやすいという人もいる。
>>353
脳内モデルを表現するにあたって、UMLを書くよりコードを書くほうが早いのが難点。
脳内モデルを表現するにあたって、UMLを書くよりコードを書くほうが早いのが難点。
>>355
「人が見ても理解しやすい」ってのは、そんな主観的・感覚的な話じゃないぞ。
同じことをやるコードでも、OOPのコードは非OOPのコードより「情報量が多い」んだよ。
同様のことがスパゲッティのコードと非スパゲッティのコードにも言えるし。
「人が見ても理解しやすい」ってのは、そんな主観的・感覚的な話じゃないぞ。
同じことをやるコードでも、OOPのコードは非OOPのコードより「情報量が多い」んだよ。
同様のことがスパゲッティのコードと非スパゲッティのコードにも言えるし。
358 ：仕様書無しさん：2007/02/08(木) 12:33:29
>>357
「情報量が少ない(多い)コードは人が見ても理解しやすい」というのはまさに主観的な話だと思うが。
「情報量が少ない(多い)コードは人が見ても理解しやすい」というのはまさに主観的な話だと思うが。
定量化する方法がなければ。
「理解しやすい」というアナログ的な感覚は
「主観的特性」であると判断するのが論理的かと
「理解しやすい」というアナログ的な感覚は
「主観的特性」であると判断するのが論理的かと
360 ：おじゃばさま：2007/02/08(木) 20:58:07
そんな難しい事ではない。
例えば自分と同じ書き方をしている人がいたとする。その人のコードはきっと読みやすいだろう。
それを強制的に行わせる。つまりコーディングルールを強制することによって、まず自分がそれに慣れる。
そうなると、同じ書き方をしている他人のコードも見やすく感じる。
簡単な原理だ。
例えば自分と同じ書き方をしている人がいたとする。その人のコードはきっと読みやすいだろう。
それを強制的に行わせる。つまりコーディングルールを強制することによって、まず自分がそれに慣れる。
そうなると、同じ書き方をしている他人のコードも見やすく感じる。
簡単な原理だ。
傲慢だ
くだらん。読みやすいかどうかなんて関係ない。
何故なら、本当に分担が設計通りに行ってるなら
人のソースなんか読む必要はないからだ。
インターフェースが厳密であって、機能を満たして
いるなら、人のソースを見る必要がどこにあるんだ…
何故なら、本当に分担が設計通りに行ってるなら
人のソースなんか読む必要はないからだ。
インターフェースが厳密であって、機能を満たして
いるなら、人のソースを見る必要がどこにあるんだ…
ある時点の素晴らしい設計もインターフェースもそれほど強固なものではない。
時代や状況の変化に応じて、そのうち変更を余儀なくされる。
その時に被害を被るのは読みにくいソースを渡された誰かさんなのだ。
時代や状況の変化に応じて、そのうち変更を余儀なくされる。
その時に被害を被るのは読みにくいソースを渡された誰かさんなのだ。
変更を予定してない設計がダメなだけ。
どういう要求が来るか予測できなきゃ設計なんかやるな。
だから拡張性を考えて設計すんだろ。
もちろん、雑魚過ぎてダメなＰＧなら、そんなの外して
最初からそこのコーディングは自分で引き受けろ。
どういう要求が来るか予測できなきゃ設計なんかやるな。
だから拡張性を考えて設計すんだろ。
もちろん、雑魚過ぎてダメなＰＧなら、そんなの外して
最初からそこのコーディングは自分で引き受けろ。
>>362
デバッグ時は人のソースどころかOSSのソース、果てはAPサーバのソースまで潜っていかなきゃならんが。
デバッグ時は人のソースどころかOSSのソース、果てはAPサーバのソースまで潜っていかなきゃならんが。
人間の予想できる拡張性への配慮なんてたかが知れたものだ。
それは今レガシーシステムと呼ばれる代物を保守している人たちがよく分かって
いると思う。数年もたてば最適な方法論も代わってくるだろう。だが、末端の成
果物であるソースの面倒はリプレースされるまでは誰かがみなければならない。
それは今レガシーシステムと呼ばれる代物を保守している人たちがよく分かって
いると思う。数年もたてば最適な方法論も代わってくるだろう。だが、末端の成
果物であるソースの面倒はリプレースされるまでは誰かがみなければならない。
過去の資産の置き換えは、また別の話だな。
>>370
君が本当に仕事してんのかどうか疑問だね。
そりゃ開発中は「無茶言わないでください」って
クライアントに言う事もあるさ。
でもな、本当にクライアントが求めてる事を理解
してれば、要求仕様だけでは足りないってのは
判るハズだよ。最初の要求仕様だけで組もうとする
方が設計者としてどうかしてる。
色々揉めても最後には「ここまでやって頂いて、
ありがとうございます」とクライアントに頭下げ
させるような仕事しろよ。それこそやりがいだろ？
君が本当に仕事してんのかどうか疑問だね。
そりゃ開発中は「無茶言わないでください」って
クライアントに言う事もあるさ。
でもな、本当にクライアントが求めてる事を理解
してれば、要求仕様だけでは足りないってのは
判るハズだよ。最初の要求仕様だけで組もうとする
方が設計者としてどうかしてる。
色々揉めても最後には「ここまでやって頂いて、
ありがとうございます」とクライアントに頭下げ
させるような仕事しろよ。それこそやりがいだろ？
なんだろ、俺は370じゃないけど意味がよくわかんないな。
誠実さをアピールして情に訴えろってことかな。今の上司にもそれに近い
ことは言われるな。
誠実さをアピールして情に訴えろってことかな。今の上司にもそれに近い
ことは言われるな。
>>371
爺い、めんどくせえからって２行目だけ読むなよ。。
あらかじめ拡張性のことを考えて設計しても、トータルコストは
安くならないって見方が今は一般的だって話だよ。
もちろん要求の変化や仕様の変更がガンガン入るって前提で。
爺い、めんどくせえからって２行目だけ読むなよ。。
あらかじめ拡張性のことを考えて設計しても、トータルコストは
安くならないって見方が今は一般的だって話だよ。
もちろん要求の変化や仕様の変更がガンガン入るって前提で。
コストだけ考えて仕事してたら生き残って行けないぞ。
まあ、それ以前に拡張性考えて設計するのが仕様満たすだけの
設計するよりコストかかるとか思ってる時点で雑魚だけどな…
設計するよりコストかかるとか思ってる時点で雑魚だけどな…
コストが同じなら議論するまでもないでしょ。あたまわるすぎ。
378 ：仕様書無しさん：2007/02/09(金) 00:41:55
377はたぶん自分で拡張性あるつもりの設計して
何の意味もなかった悲しい人なんじゃないかな
何の意味もなかった悲しい人なんじゃないかな
>>376
別におかしくなくね？
別におかしくなくね？
>>379
うんにゃおかしくなくなくね
うんにゃおかしくなくなくね
>>380
どこがおかしいかわかんね
どこがおかしいかわかんね
あーめんどくさい。もぅいい。寝る。
まあ381は学生臭がぷんぷんするけど、確かに
経験則から割り出した予測が役に立たない事もある。
でもコストが変わらないなら、拡張性高く作って
置くことに意味が無いわけじゃない。
つうか、むしろそん時作るより遥かに速い事のが多い。
そうじゃないって奴は能力が無いだけだろ。
YAGNIとか未だに信じてる奴がいる方が「え？」って感じ。
経験則から割り出した予測が役に立たない事もある。
でもコストが変わらないなら、拡張性高く作って
置くことに意味が無いわけじゃない。
つうか、むしろそん時作るより遥かに速い事のが多い。
そうじゃないって奴は能力が無いだけだろ。
YAGNIとか未だに信じてる奴がいる方が「え？」って感じ。
そりゃ悪かった。でもさ、デザパタもYAGNIなりも、実質上
コーディングレベルの話じゃん。
設計側が仕様のみで設計してたら、そりゃ変更あった時に
ＰＧからはブーブー言われちゃうわけで、その辺はある程度
予測すんのも設計者の腕じゃないかなって言いたかっただけ。
コーディングレベルの話じゃん。
設計側が仕様のみで設計してたら、そりゃ変更あった時に
ＰＧからはブーブー言われちゃうわけで、その辺はある程度
予測すんのも設計者の腕じゃないかなって言いたかっただけ。
垂直的な用途にも使用可能な水平的なソフトを同一コストで創ってしまう
という能力をお持ちならそれも支持出来ない事もないんだが。
本当に拡張性を高くするとコストが同じになるわけがない。
「コストが同じ程度の拡張性の向上が殆ど役に立ったためしがない」
という経験則がYAGNIという言葉の源泉なのだが。
という能力をお持ちならそれも支持出来ない事もないんだが。
本当に拡張性を高くするとコストが同じになるわけがない。
「コストが同じ程度の拡張性の向上が殆ど役に立ったためしがない」
という経験則がYAGNIという言葉の源泉なのだが。
設計上での拡張性はコーディング上での拡張性と切っても
切れないから、コスト的に同じになるわけがないと言う
気持ちも判る。
でも実際は違うんだよな。単純な例として言えば、
キャリアのないＰＧが組めば、S-JIS対応だけの仕様と
拡張性考えてUNICODE,EUCだの対応して作るのはコストが違う。
だけど、キャリアあるPGならまったくコストは変わらない。
「殆どないはずの、コストが同じ程度の拡張性の向上を
活かせる人材を抱える事が、企業の競争力を決める」
これが俺のYAGNIに対する答え。
切れないから、コスト的に同じになるわけがないと言う
気持ちも判る。
でも実際は違うんだよな。単純な例として言えば、
キャリアのないＰＧが組めば、S-JIS対応だけの仕様と
拡張性考えてUNICODE,EUCだの対応して作るのはコストが違う。
だけど、キャリアあるPGならまったくコストは変わらない。
「殆どないはずの、コストが同じ程度の拡張性の向上を
活かせる人材を抱える事が、企業の競争力を決める」
これが俺のYAGNIに対する答え。
そりゃそうだｗ
392 ：おじゃばさま：2007/02/09(金) 09:12:40
>376
なるほどそれは気が付かなかった。つまり俺が自意識過剰だったと言う事か。気をつけよう。
なるほどそれは気が付かなかった。つまり俺が自意識過剰だったと言う事か。気をつけよう。
393 ：おじゃばさま：2007/02/09(金) 09:43:32
390に同意
ここで孔子様の
中庸の徳
という教えに再会出来るとは
中庸の徳
という教えに再会出来るとは
まぁ、ほとんどの問題は、中庸が良いんだが、
その中庸の何処に線を引くかが難しいんだよな。
結局、正しいが、あんまり意味の無い意見のような気がする。
その中庸の何処に線を引くかが難しいんだよな。
結局、正しいが、あんまり意味の無い意見のような気がする。
397 ：仕様書無しさん：2007/02/10(土) 21:15:56
そして現実が残った
アセンブラ使ってもCと同等の生産性を実現できるやつには
言語やルールを決める意味なんぞわかりはしないのであります。
言語やルールを決める意味なんぞわかりはしないのであります。
399 ：仕様書無しさん：2007/02/11(日) 03:09:33
どんなにアセンブラ極めたとしても、同等のＣの能力あれば
同じ生産性にはならんだろ？
もしそうなら、ずーーとアセンブラで開発してたな…
同じ生産性にはならんだろ？
もしそうなら、ずーーとアセンブラで開発してたな…
400 ：仕様書無しさん：2007/02/11(日) 03:11:12
>>なんでマコネルの自慰ショーをここで勧めるか
あれは自慰ショーだったのか。(ﾉ∀`)
あれは自慰ショーだったのか。(ﾉ∀`)
普段からオブジェクト思考が出来る人を
オブジェクターというらしいのだけれど
本当？
通常JAVA等のプロジェクトには２～３人はいて欲しいそうだけど
０が現状らしいです
本当？
ちなみにオブジェクターは頭の中でポリモーフィズムとか継承とかするから
新しい事柄に対しても比較的理解が早いらしいです
しかし、睡眠中にガーベージコレクションをやるらしいので
睡眠不足になると、訳のわからないことを口走るそうです
本当かな？
オブジェクターというらしいのだけれど
本当？
通常JAVA等のプロジェクトには２～３人はいて欲しいそうだけど
０が現状らしいです
本当？
ちなみにオブジェクターは頭の中でポリモーフィズムとか継承とかするから
新しい事柄に対しても比較的理解が早いらしいです
しかし、睡眠中にガーベージコレクションをやるらしいので
睡眠不足になると、訳のわからないことを口走るそうです
本当かな？
>>401 ﾉｼ
ただし、クラスが上手く組み立てられないと思考破綻を起こします。
ただし、クラスが上手く組み立てられないと思考破綻を起こします。
日本はどんどん恥ずかしい世界になっていくな。
野球のバッターを、
上級職として「バットでボールを打ち返せる人」って名前にするくらい恥ずかしい。
じゃーバッターって何?って話になりそうだ。
野球のバッターを、
上級職として「バットでボールを打ち返せる人」って名前にするくらい恥ずかしい。
じゃーバッターって何?って話になりそうだ。
野球をオブジェクト指向で表現するとどうなるのかなぁ？
野球選手というスーパークラスがあって
ピッチャーやバッターはそのクラスを継承したものなんだろうか？
それとも別なオブジェクトだろうか？
ピッチャーやキャッチャー等の守備は
守備クラスを継承すればよいような気がするけど
だけど、継承とも違うかなぁ
ポリモーフィズムかなぁ
受けて投げ返すのは皆一緒だから
野球選手というスーパークラスがあって
ピッチャーやバッターはそのクラスを継承したものなんだろうか？
それとも別なオブジェクトだろうか？
ピッチャーやキャッチャー等の守備は
守備クラスを継承すればよいような気がするけど
だけど、継承とも違うかなぁ
ポリモーフィズムかなぁ
受けて投げ返すのは皆一緒だから
>>404
えー、攻撃側と守備側であることを状態で管理して、各ポジションごとに動作や、守備範囲を切り替えるとかじゃだめ？
えー、攻撃側と守備側であることを状態で管理して、各ポジションごとに動作や、守備範囲を切り替えるとかじゃだめ？
あてずっぽうで言わせてもらうと、ピッチャーやバッターは
ロール名であってクラス名ではないような気がする。
守備と攻撃もそう。
選手クラスのサブクラスでピッチャークラスとかつくると、
一時期の阪神みたいに、ピッチャーがファーストの守備に入って、
またピッチャーに戻るような守備位置の変更みたいなのに
対応できないでしょ。
インターフェイスの多重継承で対応してもあっさり破綻すると思うよ。
多重分類も大量に発生しそうだしな。
ロール名であってクラス名ではないような気がする。
守備と攻撃もそう。
選手クラスのサブクラスでピッチャークラスとかつくると、
一時期の阪神みたいに、ピッチャーがファーストの守備に入って、
またピッチャーに戻るような守備位置の変更みたいなのに
対応できないでしょ。
インターフェイスの多重継承で対応してもあっさり破綻すると思うよ。
多重分類も大量に発生しそうだしな。
>>404のような思考が>>408みたいになる為には何が必要なんだろうね？
>>406
揚げ足取りは簡単だと思ってるかもしれないが。
＞状態で管理して
状態を属性で持つんじゃなくて、クラスで持つ訳です。
それ位は勉強してから意見するように心がけるべきじゃないかと思った。
もしかしたらわかっててやってるのかもしれないですけど。
>>406
揚げ足取りは簡単だと思ってるかもしれないが。
＞状態で管理して
状態を属性で持つんじゃなくて、クラスで持つ訳です。
それ位は勉強してから意見するように心がけるべきじゃないかと思った。
もしかしたらわかっててやってるのかもしれないですけど。
410 ：おじゃばさま：2007/02/13(火) 09:25:17
現実世界にはオブジェクト指向的な物がほとんどないから、理解するのが難しい。
はっきりオブジェクト指向と言えるのは、Windowsのウィンドウぐらいだな。
はっきりオブジェクト指向と言えるのは、Windowsのウィンドウぐらいだな。
411 ：仕様書無しさん：2007/02/13(火) 09:32:47
キャッチャーで兼任監督の場合はどうするんだ
412 ：仕様書無しさん：2007/02/13(火) 09:34:17
多重継承ができないとキャッチャーで兼任監督を完全に実装できないな
ということはジャワはだめということで修了だな
ということはジャワはだめということで修了だな
413 ：仕様書無しさん：2007/02/13(火) 12:09:44
監督、選手、コーチ、見たいなのはインターフェースで持たせるってのは?
414 ：仕様書無しさん：2007/02/13(火) 12:44:57
まあI/Fだな。
たーふるの場合、単にキャッチャでI/Fとして監督機能を実装してるだけ。
まあ、そろそろそのあれが逆になってきてるけど。
たーふるの場合、単にキャッチャでI/Fとして監督機能を実装してるだけ。
まあ、そろそろそのあれが逆になってきてるけど。
まて。
「単なる仕事上の生産物の設計方法論を、世界観にまで広げる」
ことはいかがなものかと
「単なる仕事上の生産物の設計方法論を、世界観にまで広げる」
ことはいかがなものかと
ｱﾎｺﾃはもう少し自覚した方がいいと思う。
418 ：仕様書無しさん：2007/02/13(火) 17:47:35
IFはしょせんもどきだよ。がんもどきのおでんのようなもの。
419 ：おじゃばさま：2007/02/13(火) 19:46:47
>415
では野球選手でオブジェクト指向を表現してくれ。
昔流行った、「オブジェクト指向を理解してる人しか分からない自己満足説明本」にならないように
気を付けてな。人間と動物ネタや、ドラ○もんとドラ○ちゃんネタのような物は笑われるから避けた方がいい。
IFの現実的な役割は多重継承回避だ。
端的に言うと、スレッドとDB系の処理を継承したい場合に、多重継承したくないか出来ないので仕方なく
スレッドをインタフェースにする訳だ。オブジェクト指向の論理から言うとイリーガルな処理だ。
では野球選手でオブジェクト指向を表現してくれ。
昔流行った、「オブジェクト指向を理解してる人しか分からない自己満足説明本」にならないように
気を付けてな。人間と動物ネタや、ドラ○もんとドラ○ちゃんネタのような物は笑われるから避けた方がいい。
IFの現実的な役割は多重継承回避だ。
端的に言うと、スレッドとDB系の処理を継承したい場合に、多重継承したくないか出来ないので仕方なく
スレッドをインタフェースにする訳だ。オブジェクト指向の論理から言うとイリーガルな処理だ。
＞IFの現実的な役割は多重継承回避だ。
アホか、オブジェクト間の依存度を減らすためにあるんだろ
アホか、オブジェクト間の依存度を減らすためにあるんだろ
ちとまずそうな気がするが
選手、コーチというI/Fを作り
選手I/Fを実装した野球選手抽象クラスを作り
野球選手抽象クラスにコーチI/Fのフィールドを登録するとか
選手、コーチというI/Fを作り
選手I/Fを実装した野球選手抽象クラスを作り
野球選手抽象クラスにコーチI/Fのフィールドを登録するとか
野球選手抽象クラスは漏れも思いついた。
選手コレクションから各ポジション割り当てるだけなら、
兼任は簡単に実現出来ると思う。
じゃぁ、実装は？と言われると、やってみないとわからんなぁ。
選手コレクションから各ポジション割り当てるだけなら、
兼任は簡単に実現出来ると思う。
じゃぁ、実装は？と言われると、やってみないとわからんなぁ。
>>419
Class BaseballPlayer
:
End Class
：の部分はドメインモデル（球団経営、ゲーム、シミュレーション、神の視点...）で変わってくる。
おじゃばさま、頭固いだろ。多重継承できないって泣いてるひまあったらmixin使えよ。
Class BaseballPlayer
:
End Class
：の部分はドメインモデル（球団経営、ゲーム、シミュレーション、神の視点...）で変わってくる。
おじゃばさま、頭固いだろ。多重継承できないって泣いてるひまあったらmixin使えよ。
世界をオブジェクトで説明しようとするのは、いわばプラトンのイデア論みたいな
ものだろう。
でも、実際の現実世界は複雑系で、簡便なオブジェクトで表現できるような
ものではなかったりするよね。
ものだろう。
でも、実際の現実世界は複雑系で、簡便なオブジェクトで表現できるような
ものではなかったりするよね。
とりあえず、各選手？ポジション？の
プロパティとメソッドはどんな感じになるのでしょうか？
また、チェンジとかはどんな風に考えるのでしょうか？
審判もクラスにするのでしょうか？
これを突き詰めるとオブジェクト思考にも
限界が見えてくるような気がします
どうでしょうか？
プロパティとメソッドはどんな感じになるのでしょうか？
また、チェンジとかはどんな風に考えるのでしょうか？
審判もクラスにするのでしょうか？
これを突き詰めるとオブジェクト思考にも
限界が見えてくるような気がします
どうでしょうか？
ヘタレな俺には頭がついていけなくなりつつあるのだが。
昨今の野球ゲームはきっとオブジェクトで作られているに違いない。と思う。
昨今の野球ゲームはきっとオブジェクトで作られているに違いない。と思う。
人間は、結局オブジェクトとして万物をとらえているのだから、
人間がわかる範囲はすべてオブジェクトになるのさ。
逆にオブジェクトにできないものは、どうがんばっても人間に理解できん。
人間がわかる範囲はすべてオブジェクトになるのさ。
逆にオブジェクトにできないものは、どうがんばっても人間に理解できん。
>>427
それはちょっと極端かも。
それはちょっと極端かも。
もともとオブジェクト指向でなくても出来るものを、
オブジェクト指向に落とし込んでる訳で、
100点以外は不合格みたいな考え方だとハードル高過ぎるだろ。
オブジェクト指向に落とし込んでる訳で、
100点以外は不合格みたいな考え方だとハードル高過ぎるだろ。
個人的に状態をクラスとして表現してしまうような設計をする奴は
ドキュメント地獄になってしまうだけでなんのメリットもないと思うんだ。
ドキュメント地獄になってしまうだけでなんのメリットもないと思うんだ。
オブジェクト指向的にどうか？
っていう話だと状態もクラスにできてしまうわけだから、
解釈次第でなんでもオブジェクトになりますって言ってるようなもんだし
なにか別の資料が必要になる希ガス。
っていう話だと状態もクラスにできてしまうわけだから、
解釈次第でなんでもオブジェクトになりますって言ってるようなもんだし
なにか別の資料が必要になる希ガス。
432 ：仕様書無しさん：2007/02/14(水) 06:28:27
>>425
んと、、、
「関係者」みたいな基本クラスを作って、それを継承させたのが「野球関係者」みたいなクラスで。
それぞれの「野球関係者」みたいなクラスには役割によって
「監督」「選手」「フロント」「コーチ」「審判」「得点係」「ウグイス嬢」みたいなインターフェースを持たせて。
例えば「選手」インターフェースには基本的な「投げる」「打つ」「取る」「走る」みたいな機能が入っていて、
その「選手」インターフェースを実装した「野球関係者」クラスを継承して
「ピッチャー」「キャッチャー」クラスなんかを作る。。。。
てな感じでどでしょ。
んと、、、
「関係者」みたいな基本クラスを作って、それを継承させたのが「野球関係者」みたいなクラスで。
それぞれの「野球関係者」みたいなクラスには役割によって
「監督」「選手」「フロント」「コーチ」「審判」「得点係」「ウグイス嬢」みたいなインターフェースを持たせて。
例えば「選手」インターフェースには基本的な「投げる」「打つ」「取る」「走る」みたいな機能が入っていて、
その「選手」インターフェースを実装した「野球関係者」クラスを継承して
「ピッチャー」「キャッチャー」クラスなんかを作る。。。。
てな感じでどでしょ。
433 ：仕様書無しさん：2007/02/14(水) 07:25:52
>>432
うざｗ
継承なんてあんまり突き詰めて使わないほうがいいぞ。
キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからｗ
しつこく使いまわした分だけバグが増えて行く。
コピペでうまくいく場合があることも理解するべき。
うざｗ
継承なんてあんまり突き詰めて使わないほうがいいぞ。
キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからｗ
しつこく使いまわした分だけバグが増えて行く。
コピペでうまくいく場合があることも理解するべき。
437 ：仕様書無しさん：2007/02/14(水) 07:53:47
BaseballPlayerクラスのコンストラクタを
BaseballPlayer(ポジションI/F,監督I/F)にするとか
BaseballPlayer(ポジションI/F,監督I/F)にするとか
じゃぁ、チームメイトとポジション固有の動作を切り分ければ良いね。
誰でもどのポジションに付けるし、兼任もできる。
ルールとして、複数のポジションを兼任するのは弾かないといけないけど。
誰でもどのポジションに付けるし、兼任もできる。
ルールとして、複数のポジションを兼任するのは弾かないといけないけど。
440 ：仕様書無しさん：2007/02/14(水) 08:16:55
クラスを関数の集まりとして使ったり使わなかったり
441 ：仕様書無しさん：2007/02/14(水) 09:21:11
野球選手が芸能活動していたらどうなるだ?
新庄の引退前の状態(CM出演等)
新庄の引退前の状態(CM出演等)
442 ：仕様書無しさん：2007/02/14(水) 09:23:03
野球選手がレストランを経営し、不動産投機を行い、株の売買をして
サッカーの中田みたいに企業の取締役だったらどうする
サッカーの中田みたいに企業の取締役だったらどうする
しかも愛人がいて愛人との間に子供がいて
444 ：仕様書無しさん：2007/02/14(水) 10:31:55
>>433
＞継承なんてあんまり突き詰めて使わないほうがいいぞ。
＞キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからｗ
翻訳すると
『僕は最近最近ようやく「継承」を覚えて、その言葉をつかって話したくて仕方がないです。
「インターフェース」はよくわからないけど、似た感じのものだと思っています』
ということか。がんばれよｗ
＞継承なんてあんまり突き詰めて使わないほうがいいぞ。
＞キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからｗ
翻訳すると
『僕は最近最近ようやく「継承」を覚えて、その言葉をつかって話したくて仕方がないです。
「インターフェース」はよくわからないけど、似た感じのものだと思っています』
ということか。がんばれよｗ
445 ：仕様書無しさん：2007/02/14(水) 10:40:44
検索結果
----Orekipedia-----
インターフェース
・多重継承が出来ないと揶揄されたために無理やり多重継承もどきを嘘でも
実現するようにしたジャワの糞仕様
----Orekipedia-----
インターフェース
・多重継承が出来ないと揶揄されたために無理やり多重継承もどきを嘘でも
実現するようにしたジャワの糞仕様
446 ：仕様書無しさん：2007/02/14(水) 10:42:46
なあんか、ジャワに実装するためのOO設計って
軽自動車のオーナーがF1出ますって言っているようで悲しいっス
軽自動車のオーナーがF1出ますって言っているようで悲しいっス
委譲を使えば多重継承は必要ない。
449 ：仕様書無しさん：2007/02/14(水) 14:32:16
450 ：仕様書無しさん：2007/02/14(水) 18:03:18
>>449
自分ができないことを指して人をけなすのって空しくないですかｗ
自分ができないことを指して人をけなすのって空しくないですかｗ
451 ：仕様書無しさん：2007/02/14(水) 18:07:55
ジャワ糞で生きてて空しくならないですかw(半角)
昔からの言い伝え
全角を使う椰子にハイスキルは無し
昔からの言い伝え
全角を使う椰子にハイスキルは無し
452 ：仕様書無しさん：2007/02/14(水) 19:25:09
>>444
煽ったつもりだろうけど
それをインターフェイスやら継承云々で解決するのは無駄じゃねぇの？
サブルーチンに必要な引数の絶対数からいってもう全然違うものを
こういうので解決するのって俺はやらないほうがいいと思うよ。
関数を呼び出す前準備から手順まで違うときなんかもあるだろうし。
はっきりいってこの問題だったらもう
bool actionA(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionB(※実際は関数名も具体的なものにして引数も５～６個必要
bool actionＣbegin(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionＣ(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionＣend(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionD
bool actionE
※actionCは実行に関数を数個呼ぶ必要有り
※actionEはactionD実行中に呼ぶ必要有り、
キャラタイプＣから呼ぶときはactionDは実行できないかわりにactionEを直接呼ぶことができる。
とか実際はうまくまとまらないでしょ？
オブジェクト指向なんて捨てて
こんな感じでとにかくアクションの数だけずらーっと並べちゃって
これを適切に呼ぶ形にしちゃったほうがすっきりしそうだぜ。
もう、システムの仕様の気まぐれでどうにでもなる可能性を秘めているわけだから
オブジェクト指向なんて役に立たないと思うんだ。（少なくともこの場面では）
煽ったつもりだろうけど
それをインターフェイスやら継承云々で解決するのは無駄じゃねぇの？
サブルーチンに必要な引数の絶対数からいってもう全然違うものを
こういうので解決するのって俺はやらないほうがいいと思うよ。
関数を呼び出す前準備から手順まで違うときなんかもあるだろうし。
はっきりいってこの問題だったらもう
bool actionA(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionB(※実際は関数名も具体的なものにして引数も５～６個必要
bool actionＣbegin(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionＣ(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionＣend(※実際は関数名も具体的なものにして引数も２～３個必要
bool actionD
bool actionE
※actionCは実行に関数を数個呼ぶ必要有り
※actionEはactionD実行中に呼ぶ必要有り、
キャラタイプＣから呼ぶときはactionDは実行できないかわりにactionEを直接呼ぶことができる。
とか実際はうまくまとまらないでしょ？
オブジェクト指向なんて捨てて
こんな感じでとにかくアクションの数だけずらーっと並べちゃって
これを適切に呼ぶ形にしちゃったほうがすっきりしそうだぜ。
もう、システムの仕様の気まぐれでどうにでもなる可能性を秘めているわけだから
オブジェクト指向なんて役に立たないと思うんだ。（少なくともこの場面では）
453 ：おじゃばさま：2007/02/14(水) 19:48:04
>420
オブジェクト間の依存関係を減らす？
オブジェクトが交換可能と言う意味なら、継承だけでもいいだろう。
必要／不要の依存関係を指しているなら、実装は必要なので依存関係が減っている訳ではないだろう。
>423
そのドメインモデルを決めると抽象化されてしまうので、現実の物では表現が困難だと言っている。
あと、多重継承はいろいろな問題があるのでしたくない。無理にやればC++の二の舞いだ。
JavaにおけるIFはオブジェクト指向的ではないが、多重継承の代用としては現実的で無難な方法だ。
少なくともC++よりは遥かにマシだ。
オブジェクト間の依存関係を減らす？
オブジェクトが交換可能と言う意味なら、継承だけでもいいだろう。
必要／不要の依存関係を指しているなら、実装は必要なので依存関係が減っている訳ではないだろう。
>423
そのドメインモデルを決めると抽象化されてしまうので、現実の物では表現が困難だと言っている。
あと、多重継承はいろいろな問題があるのでしたくない。無理にやればC++の二の舞いだ。
JavaにおけるIFはオブジェクト指向的ではないが、多重継承の代用としては現実的で無難な方法だ。
少なくともC++よりは遥かにマシだ。
454 ：仕様書無しさん：2007/02/14(水) 20:08:38
746 名前： FM 投稿日： 2007/02/10(土) 13:46:59 ID:1v6kTVEm
昨日、仕事の帰りにインド人がやってるカレー屋に行ったんだけど、
カレー注文したらスプーンがついてこなくて
「あ、本格的な店なんだ」とか思って手で食ってたら、
半分くらい食ったときに、インド人の店員が奥から
すげー申し訳なさそうな顔してスプーン持ってきた
昨日、仕事の帰りにインド人がやってるカレー屋に行ったんだけど、
カレー注文したらスプーンがついてこなくて
「あ、本格的な店なんだ」とか思って手で食ってたら、
半分くらい食ったときに、インド人の店員が奥から
すげー申し訳なさそうな顔してスプーン持ってきた
>>437
すみません
やっぱりデスマ渡り歩いているのね！
オブジェクト指向は良い道具だと思います
人間が道具に使われる心配はしなくて良いと思います
道具は臨機応変に取り替えればよいだけだと思います
JAVAでも、昔ながらの構造化プログラミングできますし
ところで野球について範囲を絞ったらどうでしょうか
ゲーム開始からゲーム終了までを考えると
各選手のインスタンスの寿命もゲーム開始から終了までとするとか
インスタンスの数＝選手の数とするとか
選手以外のインスタンスは必要に応じて追加してよいだとか
どうでしょうか？
すみません
やっぱりデスマ渡り歩いているのね！
オブジェクト指向は良い道具だと思います
人間が道具に使われる心配はしなくて良いと思います
道具は臨機応変に取り替えればよいだけだと思います
JAVAでも、昔ながらの構造化プログラミングできますし
ところで野球について範囲を絞ったらどうでしょうか
ゲーム開始からゲーム終了までを考えると
各選手のインスタンスの寿命もゲーム開始から終了までとするとか
インスタンスの数＝選手の数とするとか
選手以外のインスタンスは必要に応じて追加してよいだとか
どうでしょうか？
>>456
なんつーか、とにかく何でもいいからクラスにしたくてしょうがない！というふうに見える。
手当たり次第にクラス化していくんじゃなくて、クラスとして分類したほうが便利になる物を
クラスにするんだよ。
なんつーか、とにかく何でもいいからクラスにしたくてしょうがない！というふうに見える。
手当たり次第にクラス化していくんじゃなくて、クラスとして分類したほうが便利になる物を
クラスにするんだよ。
どっちでもいいけど業務内で統一が取れないのが問題なんだよな。
こだわりすぎるとドキュメント爆弾で埋もれる結果に。
こだわりすぎるとドキュメント爆弾で埋もれる結果に。
459 ：仕様書無しさん：2007/02/15(木) 06:56:16
ドキュメントなんぞいらん状態になるのが理想だがな。
状態をクラスでもってしまうとドキュメント爆弾を抱えることになる。
また、プログラム作るよりドキュメントを作るのが好きな奴がいるんだ。これが。
お前がアホなクラス作らなきゃ必要ねーっつーのｗ
状態をクラスでもってしまうとドキュメント爆弾を抱えることになる。
また、プログラム作るよりドキュメントを作るのが好きな奴がいるんだ。これが。
お前がアホなクラス作らなきゃ必要ねーっつーのｗ
コーディング段階でクラスを作るってどんな素人集団だよwwwww
これだから、まともなプロジェクトをやったこと無い人たちは、困る。
まぁ馬鹿だから、しょうがないけどな。
これだから、まともなプロジェクトをやったこと無い人たちは、困る。
まぁ馬鹿だから、しょうがないけどな。
461 ：仕様書無しさん：2007/02/15(木) 07:07:45
メールのＣＣに偉い人のアドレス付けて送信する技術が必要になるよね。
>>461>>462
それは、そのプロジェクトが糞というだけで、
ドキュメントがいらないことを、示してないな。
っていうか、ドキュメントが糞で困ってるんだから
むしろ、ドキュメントが重要な事を示しているよな。
ちなみに
ドキュメント不要論者のバカマネージャー
http://pc10.2ch.net/test/read.cgi/prog/1163113144/
なんてスレもあったりする。
それは、そのプロジェクトが糞というだけで、
ドキュメントがいらないことを、示してないな。
っていうか、ドキュメントが糞で困ってるんだから
むしろ、ドキュメントが重要な事を示しているよな。
ちなみに
ドキュメント不要論者のバカマネージャー
http://pc10.2ch.net/test/read.cgi/prog/1163113144/
なんてスレもあったりする。
>>463
不要なドキュメントが必要になってしまうような設計がそもそも糞ってところを説明しなければならないのが難しいな。
ドキュメント書くのはいいけどね。
そもそもそれが必要になってしまうのはお前（設計した奴）がアフォだからってのを説明したいときはどうすればいいのだろか？
不要なドキュメントが必要になってしまうような設計がそもそも糞ってところを説明しなければならないのが難しいな。
ドキュメント書くのはいいけどね。
そもそもそれが必要になってしまうのはお前（設計した奴）がアフォだからってのを説明したいときはどうすればいいのだろか？
466 ：おじゃばさま：2007/02/15(木) 09:49:55
一口にドキュメントと言っても、
要求仕様書、機能設計書、詳細設計書、操作説明書などがあるだろう。
プロトタイプ方式でも、要求仕様書と操作説明書は必要とされている。
今は詳細設計書を作っている所は少ないだろうから、機能設計書が必要かどうかの話だろう。
要求仕様書、機能設計書、詳細設計書、操作説明書などがあるだろう。
プロトタイプ方式でも、要求仕様書と操作説明書は必要とされている。
今は詳細設計書を作っている所は少ないだろうから、機能設計書が必要かどうかの話だろう。
467 ：仕様書無しさん：2007/02/15(木) 12:56:43
>>452
まず君は「オーバーロード」というものを覚えた方がいいな。
それから>>444が君の事を馬鹿にしてるのは
『投げる』という動作はインターフェースのメソッドだと言っているのに
＞キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからw
とか言ってるからだと思うな。
まず君は「オーバーロード」というものを覚えた方がいいな。
それから>>444が君の事を馬鹿にしてるのは
『投げる』という動作はインターフェースのメソッドだと言っているのに
＞キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからw
とか言ってるからだと思うな。
468 ：仕様書無しさん：2007/02/15(木) 12:57:28
469 ：仕様書無しさん：2007/02/15(木) 17:03:39
>>467
オーバーロード？積み過ぎって何？
オーバーロード？積み過ぎって何？
470 ：仕様書無しさん：2007/02/15(木) 20:12:44
オーバーロード？
>>467
インターフェイスも引数変わったら終わりじゃね？
インターフェイスも引数変わったら終わりじゃね？
つ引数もオブジェクト
>>472
その逃げ方ってvoid*と何がちがうん？
結局必要っぽいもん全部放りこんどけｗ
ってことでしょ？
それと処理に実際に必要なもん以外に色んなモンが必要になって
結果的にプログラムがめちゃくちゃ汚くなるじゃん。
その逃げ方ってvoid*と何がちがうん？
結局必要っぽいもん全部放りこんどけｗ
ってことでしょ？
それと処理に実際に必要なもん以外に色んなモンが必要になって
結果的にプログラムがめちゃくちゃ汚くなるじゃん。
>>474
そんなことはないでしょ。
必要なものだけ設定すると引数がずれちゃうからクラスごと引数で渡すようにするんでしょ？
これを設計のズレととらずに許容範囲内の誤差として誤魔化すのがクラスで渡す方法の醍醐味でしょ？
void*も実際には似たような使い方すんだよ。
俺は別にまるで違うもんを設定することを危険とかいいたんじゃない。
こんなことをする必要が生じる時点でもうその設計は駄目だといいたい。
別に俺のやり方に従えとは言わんがたまには
なんで言語を作った奴は型を必要だと思ったのか？
また、型を誤魔化すってのはどういうことをすることか？
ってのを考えてみてほしいとおもう。
実際、こうやって引数の大枠を誤魔化して呼び続けるとどんな設計をしても表面上は問題が無いようにみえる。
（グローバル変数ですべてのデータをやりとりして、引数を１つも無い状態にしても同様）
そんなことはないでしょ。
必要なものだけ設定すると引数がずれちゃうからクラスごと引数で渡すようにするんでしょ？
これを設計のズレととらずに許容範囲内の誤差として誤魔化すのがクラスで渡す方法の醍醐味でしょ？
void*も実際には似たような使い方すんだよ。
俺は別にまるで違うもんを設定することを危険とかいいたんじゃない。
こんなことをする必要が生じる時点でもうその設計は駄目だといいたい。
別に俺のやり方に従えとは言わんがたまには
なんで言語を作った奴は型を必要だと思ったのか？
また、型を誤魔化すってのはどういうことをすることか？
ってのを考えてみてほしいとおもう。
実際、こうやって引数の大枠を誤魔化して呼び続けるとどんな設計をしても表面上は問題が無いようにみえる。
（グローバル変数ですべてのデータをやりとりして、引数を１つも無い状態にしても同様）
このカオス状態が開発現場の実態。
オブジェクト指向が流行らないんじゃなくて、
学習する、って当たり前のことができてないからだな。
オブジェクト指向が流行らないんじゃなくて、
学習する、って当たり前のことができてないからだな。
まぁ構造化プログラミングの段階でもNGなコピペを進める馬鹿もいるし、
この国の情報産業は、もう駄目かもしれんね。
この国の情報産業は、もう駄目かもしれんね。
479 ：仕様書無しさん：2007/02/15(木) 22:48:33
>>476
あ、俺は君がオブジェクト指向をわかったつもりになってるだけのレベルの低い開発者だと思ってるよｗ
あ、俺は君がオブジェクト指向をわかったつもりになってるだけのレベルの低い開発者だと思ってるよｗ
なにいっても、難癖つけてくるから、無駄な事はしないよ。
>>481
>君がクラスの意味がまるでわかっていないって事がわかった。
だから、こういうスレでこんなレスつけちゃうんだよ。
自分の主張を説明できないならはじめっからレスなんてつけないでＲＯＭってろよ。
俺が君のレスをみて感じたことは「主張ができるほどプログラムを組んで無い」ってことだけだね。
>君がクラスの意味がまるでわかっていないって事がわかった。
だから、こういうスレでこんなレスつけちゃうんだよ。
自分の主張を説明できないならはじめっからレスなんてつけないでＲＯＭってろよ。
俺が君のレスをみて感じたことは「主張ができるほどプログラムを組んで無い」ってことだけだね。
なんでもいいけど、
このスレ内の認識のずれ（学習不足）のすさまじさが業界の現状をよく表してるわ。
オブジェクト指向だとか構造化だとか、
手法はなんでもいいから納品物として成り立つものを作るのが大事なんだよ。
一例だけど、
UMLとかの形式ばかりにこだわりすぎて必死に書いても、
ユーザーや技術未修得者に「分からん」と一蹴されるような手法でもあるんだから。
流行らない理由は分かりにくいことと、
「オブジェクト指向」なんていう意味が伝わりにくい名前だから。
まあ最初から学習放棄してる技術者もどうかと思うけど。
このスレ内の認識のずれ（学習不足）のすさまじさが業界の現状をよく表してるわ。
オブジェクト指向だとか構造化だとか、
手法はなんでもいいから納品物として成り立つものを作るのが大事なんだよ。
一例だけど、
UMLとかの形式ばかりにこだわりすぎて必死に書いても、
ユーザーや技術未修得者に「分からん」と一蹴されるような手法でもあるんだから。
流行らない理由は分かりにくいことと、
「オブジェクト指向」なんていう意味が伝わりにくい名前だから。
まあ最初から学習放棄してる技術者もどうかと思うけど。
>>475
> これを設計のズレととらずに許容範囲内の誤差として誤魔化すのがクラスで渡す方法の醍醐味でしょ？
> void*も実際には似たような使い方すんだよ。
void*だと、呼び出し元を見に行かなきゃいけないだろ。
クラスによって、明確に定義されていれば、必要な情報のみ見れば良いだけで済む。
> 俺は別にまるで違うもんを設定することを危険とかいいたんじゃない。
> こんなことをする必要が生じる時点でもうその設計は駄目だといいたい。
設計として失敗だけど、後だしの仕様変更なら許容すべきでは？
> 別に俺のやり方に従えとは言わんがたまには
> なんで言語を作った奴は型を必要だと思ったのか？
> また、型を誤魔化すってのはどういうことをすることか？
> ってのを考えてみてほしいとおもう。
型そのものは、コンパイラにとっても、開発者にとっても必要だと思う。
型をごまかすという表現に拘ってるようだけど、
たどることが出来るならvoid*とは別物な訳で、
こういったごまかし方は、むしろ歓迎すべきでは？
> 実際、こうやって引数の大枠を誤魔化して呼び続けるとどんな設計をしても表面上は問題が無いようにみえる。
> （グローバル変数ですべてのデータをやりとりして、引数を１つも無い状態にしても同様）
別にグローバル変数を使って引数を無い状態を否定する権利はないが、
個人的には望まないし、選択しない。
最小限の情報で仕様変更が済ませるための一つの方法として、
オブジェクト設計がなされるべきで、目的に反する方法を選択する理由はない。
> これを設計のズレととらずに許容範囲内の誤差として誤魔化すのがクラスで渡す方法の醍醐味でしょ？
> void*も実際には似たような使い方すんだよ。
void*だと、呼び出し元を見に行かなきゃいけないだろ。
クラスによって、明確に定義されていれば、必要な情報のみ見れば良いだけで済む。
> 俺は別にまるで違うもんを設定することを危険とかいいたんじゃない。
> こんなことをする必要が生じる時点でもうその設計は駄目だといいたい。
設計として失敗だけど、後だしの仕様変更なら許容すべきでは？
> 別に俺のやり方に従えとは言わんがたまには
> なんで言語を作った奴は型を必要だと思ったのか？
> また、型を誤魔化すってのはどういうことをすることか？
> ってのを考えてみてほしいとおもう。
型そのものは、コンパイラにとっても、開発者にとっても必要だと思う。
型をごまかすという表現に拘ってるようだけど、
たどることが出来るならvoid*とは別物な訳で、
こういったごまかし方は、むしろ歓迎すべきでは？
> 実際、こうやって引数の大枠を誤魔化して呼び続けるとどんな設計をしても表面上は問題が無いようにみえる。
> （グローバル変数ですべてのデータをやりとりして、引数を１つも無い状態にしても同様）
別にグローバル変数を使って引数を無い状態を否定する権利はないが、
個人的には望まないし、選択しない。
最小限の情報で仕様変更が済ませるための一つの方法として、
オブジェクト設計がなされるべきで、目的に反する方法を選択する理由はない。
>>483
学習するのはいいけど
その前に何をもって「正しい」とするの？
本読むったってそれからいって著者同士で連携とれてるわけじゃないし、
所詮、その辺りはセミナー向けのでっちあげ教材な面も少なく無いじゃん。
ていうか、場合によっては１００％セミナー教材じゃん。
そんなに自信があるなら、
使えるもんと使えないもんと選別してほしいんだけど。
学習するのはいいけど
その前に何をもって「正しい」とするの？
本読むったってそれからいって著者同士で連携とれてるわけじゃないし、
所詮、その辺りはセミナー向けのでっちあげ教材な面も少なく無いじゃん。
ていうか、場合によっては１００％セミナー教材じゃん。
そんなに自信があるなら、
使えるもんと使えないもんと選別してほしいんだけど。
>>485
自分で何が使えるか使えないかも判断できないのか？？
業務遂行に必要だけど未修得なら覚えればいいだろ。
不必要でどーでもいいならほっとけばいいだろ。
PJリーダーがトップダウンで「オブジェクト指向でよろしく！」って言ったところで、
下位作業者がわからんちん（オブジェクト指向を知らない）ならどうしようもないだろ。
オブジェクト指向ってのはあくまでも考え方。
言語（決まりを守らないと動かないもの）とは違うから
覚える努力というか度合いが各自違うわけ。
オブジェクト指向がPJの中で使えると判断するなら使えばいいし。
自分で何が使えるか使えないかも判断できないのか？？
業務遂行に必要だけど未修得なら覚えればいいだろ。
不必要でどーでもいいならほっとけばいいだろ。
PJリーダーがトップダウンで「オブジェクト指向でよろしく！」って言ったところで、
下位作業者がわからんちん（オブジェクト指向を知らない）ならどうしようもないだろ。
オブジェクト指向ってのはあくまでも考え方。
言語（決まりを守らないと動かないもの）とは違うから
覚える努力というか度合いが各自違うわけ。
オブジェクト指向がPJの中で使えると判断するなら使えばいいし。
最低限
ドメインモデルとトランザクションスクリプトの違いが分かるようになってからここに来い。
ドメインモデルとトランザクションスクリプトの違いが分かるようになってからここに来い。
>>490
483=489なんだが。
483=489なんだが。
>>491
あんまり無茶言うと現場で浮いちゃうから気をつけろよ
あんまり無茶言うと現場で浮いちゃうから気をつけろよ
>>492
別にアンカー間違ってねーんじゃねーのか？
別にアンカー間違ってねーんじゃねーのか？
とりあえず金曜は飲み会デーだからそれでよし
じゃあ、各自、ドメインモデルとトランザクションスクリプトを勉強しておくということで
は～い
開発言語がJavaだろうがC++だろうが実際人を集めると
10人中2,3人しか経験者がいなくて、残りが汎用機あがりやVBのみとかってことが
結構あったりする
自分がはずれを引きまくってるだけかもしれんが
10人中2,3人しか経験者がいなくて、残りが汎用機あがりやVBのみとかってことが
結構あったりする
自分がはずれを引きまくってるだけかもしれんが
>>491じゃないけど、アーキテクチャとドメインモデルの関係を理解することが
C++なりJavaなりでオブジェクト指向設計を現場で実際に役立たすための第一歩だと思うな。
>>452からのやり取りも、このあたりがうまく整理できていないことが原因で話がおかしくなっていると感じる。
C++なりJavaなりでオブジェクト指向設計を現場で実際に役立たすための第一歩だと思うな。
>>452からのやり取りも、このあたりがうまく整理できていないことが原因で話がおかしくなっていると感じる。
「アーキテクチャとドメインモデルの関係を理解することが第一歩だ」
と、プロジェクトで発言した日にゃあ、
「日本語で喋ってもらっていい？」
なんていわれそうだな。
と、プロジェクトで発言した日にゃあ、
「日本語で喋ってもらっていい？」
なんていわれそうだな。
アーティファクトってなーに？
成果物じゃなかったっけ
ドメインってＰＣに設定するドメイン？
人がつくったもの
>>500
その上、基本設計など大事なところは何故か業務知識重視で
JavaやC++経験者で業務知識があまりない人間より経験ないが業務知識あると
思われる人間のみで構成しようとして製造工程でいろいろ問題が出るのが最近のパターン
その上最近は、留学生という肩書きの中国人や韓国人までいるから、更にカオス度うｐ
こんな状態でOOを実践できるとは思えん
その上、基本設計など大事なところは何故か業務知識重視で
JavaやC++経験者で業務知識があまりない人間より経験ないが業務知識あると
思われる人間のみで構成しようとして製造工程でいろいろ問題が出るのが最近のパターン
その上最近は、留学生という肩書きの中国人や韓国人までいるから、更にカオス度うｐ
こんな状態でOOを実践できるとは思えん
イネーブル（可）とディセーブル（不可）を
センシティブ（敏感）とインセンシティブ（鈍感）と
言ってる現場も格差社会の一つか
センシティブ（敏感）とインセンシティブ（鈍感）と
言ってる現場も格差社会の一つか
まずはアーキテクチャとドメインモデルをわかりやすい言葉に直してみてくれ。
見える化ボードに「～～がエスカレーションを生む」とか書いてあるんですけど。
見えないんですけど。
見えないんですけど。
>>489
> オブジェクト指向がPJの中で使えると判断するなら使えばいいし。
そういう判断もせないかんとは、ＰＬとは大変な仕事なり。
>>499
> 10人中2,3人しか経験者がいなくて、
人転がし派遣をあてにしすぎればそういうことも多いかもしれんね。
おまいさんの上司がイクナイのかも。
>>507
ちょっとうらやましいかも。
>>513
激しくキボン
> オブジェクト指向がPJの中で使えると判断するなら使えばいいし。
そういう判断もせないかんとは、ＰＬとは大変な仕事なり。
>>499
> 10人中2,3人しか経験者がいなくて、
人転がし派遣をあてにしすぎればそういうことも多いかもしれんね。
おまいさんの上司がイクナイのかも。
>>507
ちょっとうらやましいかも。
>>513
激しくキボン
>>495
>>502
・・・コボラーとか複雑なSQLが当たり前な人ですか？
オブジェクト指向が理解されない理由は現状Java使ったシステム開発でも必要性が感じられないからだ。
大抵どこのシステム開発でも設計時に、ビュー、エンティティ、コントロールは抽出するよな？
でも、ビューは画面、エンティティはただのデータ入れとく箱扱い。
だから、如何にコントロールが無理してチェック処理、計算処理を行うかにかかってる。
そういうシステムは馬鹿の1つ覚えみたくエンティティ貰ってはDBのテーブルにインサートするDAOと
一覧表示用に特化した超複雑なSELECT文発行してたりするDAOがある。
そんなんだからエンティティがロジックを持つってことが理解できないんだ。
オブジェクト指向で考えればDBなんてセッションタイムアウトとかガベージコレクションで消されないように
オブジェクトの生存期間を延ばすだけのただの箱に過ぎないんだよ。
いくらでも保持できる広大なメモリ量と鯖の電源切れない保証があれば全エンティティをメモリ上に蓄えておけばいい。
でもそんなわけがないから永続化したオブジェクトを簡単にメモリ上に展開できて、
尚且つ大量データの計算処理が得意なSQLも使えるRDBMSが便利だから使っているんだよ。
極論言えば永続化できて簡単にメモリ上に展開できればDBなんて不要でXMLとかファイルとかでも構わない。
>>502
・・・コボラーとか複雑なSQLが当たり前な人ですか？
オブジェクト指向が理解されない理由は現状Java使ったシステム開発でも必要性が感じられないからだ。
大抵どこのシステム開発でも設計時に、ビュー、エンティティ、コントロールは抽出するよな？
でも、ビューは画面、エンティティはただのデータ入れとく箱扱い。
だから、如何にコントロールが無理してチェック処理、計算処理を行うかにかかってる。
そういうシステムは馬鹿の1つ覚えみたくエンティティ貰ってはDBのテーブルにインサートするDAOと
一覧表示用に特化した超複雑なSELECT文発行してたりするDAOがある。
そんなんだからエンティティがロジックを持つってことが理解できないんだ。
オブジェクト指向で考えればDBなんてセッションタイムアウトとかガベージコレクションで消されないように
オブジェクトの生存期間を延ばすだけのただの箱に過ぎないんだよ。
いくらでも保持できる広大なメモリ量と鯖の電源切れない保証があれば全エンティティをメモリ上に蓄えておけばいい。
でもそんなわけがないから永続化したオブジェクトを簡単にメモリ上に展開できて、
尚且つ大量データの計算処理が得意なSQLも使えるRDBMSが便利だから使っているんだよ。
極論言えば永続化できて簡単にメモリ上に展開できればDBなんて不要でXMLとかファイルとかでも構わない。
1年に1回やってくるバレンタインデー。
でも俺は生まれて1度も本命チョコレートをもらった試しがない。いつも義理チョコばかりだ。
昨日もらったチョコレートを今日1つだけ食べた。もちろん義理チョコだ。
義理チョコを食べながら俺は泣いた。
どうしてバレンタインデーなんてものがあるのか・・・俺にあるのはデスマーチの毎日と納期だけだ。
くそ・・・っ、ビルの屋上からあの幸せそうなカップル目掛けて童貞万歳と叫びながらダイブしてやる・・・っ
でも俺は生まれて1度も本命チョコレートをもらった試しがない。いつも義理チョコばかりだ。
昨日もらったチョコレートを今日1つだけ食べた。もちろん義理チョコだ。
義理チョコを食べながら俺は泣いた。
どうしてバレンタインデーなんてものがあるのか・・・俺にあるのはデスマーチの毎日と納期だけだ。
くそ・・・っ、ビルの屋上からあの幸せそうなカップル目掛けて童貞万歳と叫びながらダイブしてやる・・・っ
つDataAｃｃessObject＝DAO
JavaでDAO使ってる俺って・・・orz
>>519
ん、J2EE時代からよくあるレイヤ構造でいうと
プレゼン層、ビジネス層、データアクセス層（DAO）って感じで分かれてるね。
ビジネスロジックから直接DBアクセスしたりすると、ストレージが変わったときの修正が有り得んから。
SQLでもOracleやPostgreSQLで書き方違ったりするだろ？
その辺吸収するのがDAO層。
ん、J2EE時代からよくあるレイヤ構造でいうと
プレゼン層、ビジネス層、データアクセス層（DAO）って感じで分かれてるね。
ビジネスロジックから直接DBアクセスしたりすると、ストレージが変わったときの修正が有り得んから。
SQLでもOracleやPostgreSQLで書き方違ったりするだろ？
その辺吸収するのがDAO層。
Javaだろうが何だろうがDAOは使うだろ。
MS AccessとかのDAOと思っちゃったよ。
ビジネス層からDAO層に渡すのは
DataTransferがいいのかEntityがいいのかがいまだに判断がつかん
DataTransferがいいのかEntityがいいのかがいまだに判断がつかん
現状DTO使うしかないのでは。
ぶっちゃけどっちでもいいかと。
あえて言えば
トランザクションスクリプト的観点から言えば前者。
DAOを独立したデータベースアクセス機能としてIF切るのであれば、ビジネス層のデータに依存するのはよろしくない。
しかしドメインモデル的観点から言えば後者。
永続化はビジネス層の一部の処理で、サービスクラスがオブジェクトの生存期間を延ばすために行うもの。
だから単純にDAOに対して、「このインスタンスどっかに永続化しといて、あとで使うから。」的に利用するものだと思われ。
あえて言えば
トランザクションスクリプト的観点から言えば前者。
DAOを独立したデータベースアクセス機能としてIF切るのであれば、ビジネス層のデータに依存するのはよろしくない。
しかしドメインモデル的観点から言えば後者。
永続化はビジネス層の一部の処理で、サービスクラスがオブジェクトの生存期間を延ばすために行うもの。
だから単純にDAOに対して、「このインスタンスどっかに永続化しといて、あとで使うから。」的に利用するものだと思われ。
ちなみにhibernateとかいうORマッパ使うなら後者が必須ですよ。
＞ちなみにhibernateとかいうORマッパ使うなら後者が必須ですよ。
必須ってことはないだろ。というか、必須の意味がわからない。
必須ってことはないだろ。というか、必須の意味がわからない。
一連の流れを見てると
なぜオブジェクト指向が流行らないのかがよく分かる。
理解してる者の発言を見ればみるほど、
理解してない者がどんどん冷めていくんだろうな。
なぜオブジェクト指向が流行らないのかがよく分かる。
理解してる者の発言を見ればみるほど、
理解してない者がどんどん冷めていくんだろうな。
532 ：仕様書無しさん：2007/02/16(金) 01:34:21
ドメインモデル、トランザクションスクリプト
テーブルモジュールは無視かよ（笑
テーブルモジュールは無視かよ（笑
>>531
なんでそう思う？
なんでそう思う？
1レコード1DTOとして設計してるかぎりは前者ってこと。
hibernateはロードしたオブジェクトに変更くわえればトランザクションコミット時に自動でDBに反映されるからさ。
サービスでオブジェクト操作するんだからサービスまでエンティティもってこないと…
返り値はエンティティだから保存時もエンティティ。
hibernateはロードしたオブジェクトに変更くわえればトランザクションコミット時に自動でDBに反映されるからさ。
サービスでオブジェクト操作するんだからサービスまでエンティティもってこないと…
返り値はエンティティだから保存時もエンティティ。
コーディングも設計に含まれるわけで。
ひたすら横文字なのは、対応する日本語（つか概念）がないからじゃね？
アーキテクチャをうまく訳せるか？
アーキテクチャをうまく訳せるか？
>>538
同じことを現場で言えるなら大したもんだけどね。
同じことを現場で言えるなら大したもんだけどね。
アーキテクチャ＝設計概念
じゃだめ？
じゃだめ？
プロ管ドキュメント用語をひたすら日本語にして威張っていたやつが客にいたな。
ＷＢＳ->課題管理表
Q/A->質疑応答一覧
など
ＷＢＳ->課題管理表
Q/A->質疑応答一覧
など
追加。
WBSを課題管理表というのは明らかに違うとオモタが、
指摘したら逆切れされたので言わなくなった。
WBSを課題管理表というのは明らかに違うとオモタが、
指摘したら逆切れされたので言わなくなった。
システム構成とかアプリケーションの内部構造とかフレームワークじゃね？
ハード、ソフトひっくるめていうこともあれば分けていうこともある。
ハード、ソフトひっくるめていうこともあれば分けていうこともある。
アーキテクチャ＝歯車
ドメインモデル＝歯車の上で回るもの
ドメインモデル＝歯車の上で回るもの
全然予想もつかん横文字よりも
それなりに予想が付く日本語の方がまだマシだろ。
WBSなんていわれるよりも作業構成図とか分担表とか、
微妙に間違っててもなんのことかは分かる。
WBS＝ワールドベースボール？なんて思われるよりマシ。
フレームワークも「アプリの土台です」って言えばそれなりに伝わるし。
相手が理解できるかどうかが分からんまま使うぐらいなら、ってことで。
それなりに予想が付く日本語の方がまだマシだろ。
WBSなんていわれるよりも作業構成図とか分担表とか、
微妙に間違っててもなんのことかは分かる。
WBS＝ワールドベースボール？なんて思われるよりマシ。
フレームワークも「アプリの土台です」って言えばそれなりに伝わるし。
相手が理解できるかどうかが分からんまま使うぐらいなら、ってことで。
そもそも現場でオブジェクト指向が有効な理由を説明できた奴もいないがなｗ
このスレでも延々続いてるけど、まだ誰もオブジェクト指向が「従来」の方法より優れていることを説明できた奴がいない。
このスレでも延々続いてるけど、まだ誰もオブジェクト指向が「従来」の方法より優れていることを説明できた奴がいない。
そもそも現場でオブジェクト指向が無効な理由を説明できた奴もいないがなｗ
このスレでも延々続いてるけど、まだ誰もオブジェクト指向が「従来」の方法より劣ってることを説明できた奴がいない。
このスレでも延々続いてるけど、まだ誰もオブジェクト指向が「従来」の方法より劣ってることを説明できた奴がいない。
>>548-549
どっちかができても進展はありそうだがなｗ
どっちかができても進展はありそうだがなｗ
横文字並べたり、鼻っから説明することを諦めたり、
横文字わかんねぇーなら適正ねー、とか突っぱねるやつが、
現場でのオブジェクト指向に対する敷居を高くしてるんじゃないのか？
横文字わかんねぇーなら適正ねー、とか突っぱねるやつが、
現場でのオブジェクト指向に対する敷居を高くしてるんじゃないのか？
俺は大昔汎用機のCADを開発、メンテナンスしていたのだけど
１つのEXEでできていて、ソースコードをA4で印刷（当時ようやくレーザープリンターが出始めた頃）すると
厚さが１．５ｍくらいあったのよ
言語はFORTRANで書かれていて（一部アセンブラ）、
コメント見ると「これ以上追えん」とか書かれていて
変数も足りなくてこっそり違う変数（配列）を借用してたりして
まさにカオスでした
構造化プログラミングの限界だったようでした
一部の人が今のオブジェクト指向みたいなものを取り入れて
作っていましたが、単なるルールに過ぎず、なかなか守られなかった記憶があります
そんな経験があるから、オブジェクト指向は便利だと痛感します
１つのEXEでできていて、ソースコードをA4で印刷（当時ようやくレーザープリンターが出始めた頃）すると
厚さが１．５ｍくらいあったのよ
言語はFORTRANで書かれていて（一部アセンブラ）、
コメント見ると「これ以上追えん」とか書かれていて
変数も足りなくてこっそり違う変数（配列）を借用してたりして
まさにカオスでした
構造化プログラミングの限界だったようでした
一部の人が今のオブジェクト指向みたいなものを取り入れて
作っていましたが、単なるルールに過ぎず、なかなか守られなかった記憶があります
そんな経験があるから、オブジェクト指向は便利だと痛感します
553 ：おじゃばさま：2007/02/16(金) 10:04:39
>552
まず構造化プログラミングが大規模開発に向かないというのは誤りである。
構造化プログラミングと言うのは、大規模開発用に開発された物だからだ。
大昔のCOBOLやアセンブラでは殆ど構造化プログラミングされていない。
つまり552は始めに構造化プログラミングを学ぶべきである。
オブジェクト指向プログラミングは、そんなに難解な訳ではない。
簡単に言うと構造化プログラミングが「データをグループ化する」のに対して、
オブジェクト指向プログラミングは「データと処理をグループ化する」のである。
ただしマスターするには時間がかかる。
実装方法を例に説明しよう。
まず構造体を作る要領で項目を抽出する。その項目をプライベートフィールド変数としてクラスを作成し、
それにアクセスするセッターとゲッターを作成する。そしてそのセッターとゲッターに処理を追加して行く。
最初はこれで進めよう。修正や仕様変更を進めるうちに、どこクラスやメソッドに変数や処理を入れる
べきなのか分かってくるだろう。
これが分かってきたら次の段階の「継承」に進むが、長くなるのでまた今度。
まず構造化プログラミングが大規模開発に向かないというのは誤りである。
構造化プログラミングと言うのは、大規模開発用に開発された物だからだ。
大昔のCOBOLやアセンブラでは殆ど構造化プログラミングされていない。
つまり552は始めに構造化プログラミングを学ぶべきである。
オブジェクト指向プログラミングは、そんなに難解な訳ではない。
簡単に言うと構造化プログラミングが「データをグループ化する」のに対して、
オブジェクト指向プログラミングは「データと処理をグループ化する」のである。
ただしマスターするには時間がかかる。
実装方法を例に説明しよう。
まず構造体を作る要領で項目を抽出する。その項目をプライベートフィールド変数としてクラスを作成し、
それにアクセスするセッターとゲッターを作成する。そしてそのセッターとゲッターに処理を追加して行く。
最初はこれで進めよう。修正や仕様変更を進めるうちに、どこクラスやメソッドに変数や処理を入れる
べきなのか分かってくるだろう。
これが分かってきたら次の段階の「継承」に進むが、長くなるのでまた今度。
554 ：おじゃばさま：2007/02/16(金) 10:09:14
オブジェクト指向の優れている点は、すでに説明済みだが、変更のしやすさである。
端的に説明すると、「DBがORACLEからPostgresに替えてくれ」と言う無茶を可能にする物である。
端的に説明すると、「DBがORACLEからPostgresに替えてくれ」と言う無茶を可能にする物である。
>構造化プログラミングと言うのは、大規模開発用に開発された物だからだ。
違うってば
違うってば
556 ：おじゃばさま：2007/02/16(金) 10:23:46
どう違うのだろうか？
もう莫迦晒さず黙ってろよ>おじゃま
558 ：仕様書無しさん：2007/02/16(金) 10:51:58
ここ議論が活発でいいね。
全部読んではいないけど、一言発言させてくれ。
OOPも構造化も、その効用の一つには「カプセル化」、そして結局「コンポーネント化」、
そしてそれによる「容易な再利用可能化」が最大の利点だったかと思う。
つまり、仕事を分業して部品の機能に自動的に任せるところは任せて安心できる
環境を作り、どれだえｋ効率化できるか、生産性を上げられるか、ってところに
本来の眼目があったのがこういう近代的プログラミング手法の最大の目的が
あったはずだと思うんだけど、どうだろう。
そしてそれによってデバッグも効率化し、またメンテナンス性も向上し、と
至れり尽くせりの開発環境、保守環境が待っているはずだったのでは。
とすると、その目的が達成されるものであれば、本来は小やかましい哲学論
や宗教派閥論争にはでしゃばってほしくはなかったはずで、なんでこの時点でも
まだまだこのシステム工学の原点に関係して開発と保守の現場で問題が
ぬぐえないままなのだろうか？
わたしはこの本来の目的であった原点をこそ最重要視した改善こそが望まれる
のだと考えるわけですが・・・・・どうでしょうか。
全部読んではいないけど、一言発言させてくれ。
OOPも構造化も、その効用の一つには「カプセル化」、そして結局「コンポーネント化」、
そしてそれによる「容易な再利用可能化」が最大の利点だったかと思う。
つまり、仕事を分業して部品の機能に自動的に任せるところは任せて安心できる
環境を作り、どれだえｋ効率化できるか、生産性を上げられるか、ってところに
本来の眼目があったのがこういう近代的プログラミング手法の最大の目的が
あったはずだと思うんだけど、どうだろう。
そしてそれによってデバッグも効率化し、またメンテナンス性も向上し、と
至れり尽くせりの開発環境、保守環境が待っているはずだったのでは。
とすると、その目的が達成されるものであれば、本来は小やかましい哲学論
や宗教派閥論争にはでしゃばってほしくはなかったはずで、なんでこの時点でも
まだまだこのシステム工学の原点に関係して開発と保守の現場で問題が
ぬぐえないままなのだろうか？
わたしはこの本来の目的であった原点をこそ最重要視した改善こそが望まれる
のだと考えるわけですが・・・・・どうでしょうか。
559 ：仕様書無しさん：2007/02/16(金) 10:54:28
あるいはもしかすると、OOPになっても、それでもまだまだ当初の目的であった
ことどもはなんら達成されてはいない、ということだのろうか、とも思った次第。
どうでしょうか？
ことどもはなんら達成されてはいない、ということだのろうか、とも思った次第。
どうでしょうか？
560 ：仕様書無しさん：2007/02/16(金) 11:12:01
ソフトウエア工学はバグが全くないと検証テストされた
たった1行のコードにバグが存在する可能性があるという
排他的論理和状況が常に存在する。それは処理するコード自体に
確かにバグはなくともそれに渡すデータにバグがある可能性が否定できないからだ。
このようなソフトウエア工学の現実を理解せずに他人が積み重ねた膨大なコード
をなんの疑いもなく再利用できる理想論としての完全主義者が考案したOO理論は
公約の果たせない政治家のようなものである。
たった1行のコードにバグが存在する可能性があるという
排他的論理和状況が常に存在する。それは処理するコード自体に
確かにバグはなくともそれに渡すデータにバグがある可能性が否定できないからだ。
このようなソフトウエア工学の現実を理解せずに他人が積み重ねた膨大なコード
をなんの疑いもなく再利用できる理想論としての完全主義者が考案したOO理論は
公約の果たせない政治家のようなものである。
>>558-559
解決/改善/達成はなされていない。
この問題は管理工学や組織論や要素還元主義に代表される哲学等の
所謂パラダイムシフトに関わっているからだ。
なぜならソフトウェアは人が創るものであるから。
プログラミング手法の進化だけでは解決する問題では無いのです。
一般的な表現をするなら、
局所的な最適化は全体の最適化に直結しない。
そして・・・
スレ違いです。
解決/改善/達成はなされていない。
この問題は管理工学や組織論や要素還元主義に代表される哲学等の
所謂パラダイムシフトに関わっているからだ。
なぜならソフトウェアは人が創るものであるから。
プログラミング手法の進化だけでは解決する問題では無いのです。
一般的な表現をするなら、
局所的な最適化は全体の最適化に直結しない。
そして・・・
スレ違いです。
何故流行らないのか？
実践できる環境・人材が集まらないから
実践できる環境・人材が集まらないから
オブジェクト指向の理解なんて頭の良し悪しには関係ないんだよ。何故な
ら人間が普段の生活で気づかずに実践しているから。
Ａさんは手先が器用とか、Ｂさんは絵を描くのがうまいとかっていう人の
属性や、ひもをひっぱると電気がつくとかっていうインターフェースをみ
んな何気に認識してんだよ。向上心をもって１年もやれば十分身につくし、
２年もやれば最善策もわかってくる。わかんないっていってる奴は向上心
もたずに、機ぼーっと械的にやってるからなんだよ。勉強しろ。
ら人間が普段の生活で気づかずに実践しているから。
Ａさんは手先が器用とか、Ｂさんは絵を描くのがうまいとかっていう人の
属性や、ひもをひっぱると電気がつくとかっていうインターフェースをみ
んな何気に認識してんだよ。向上心をもって１年もやれば十分身につくし、
２年もやれば最善策もわかってくる。わかんないっていってる奴は向上心
もたずに、機ぼーっと械的にやってるからなんだよ。勉強しろ。
勉強始めて2年後の俺
↓
↓
>>561
「スレ違い」じゃないんじゃないかなぁ、と
というのは、目的が存在しない行動は本来的にあり得ないし、
そもそもが社会の発展をになう系沿い活動が根本である以上、
その構築に資する、そして資してきたはずの現代文明の道具たるはずの
「自動計算機」が、「使い物にならない」状態はほおっては置けないはずでは？
お金を掛けて世の中を駆動していくはずの道具が有効じゃない状況は
まちがっているし、効率的でないならそれを改善する本質論から始めないなら
元々の意味を外しているに違いないと思うのだが
「スレ違い」じゃないんじゃないかなぁ、と
というのは、目的が存在しない行動は本来的にあり得ないし、
そもそもが社会の発展をになう系沿い活動が根本である以上、
その構築に資する、そして資してきたはずの現代文明の道具たるはずの
「自動計算機」が、「使い物にならない」状態はほおっては置けないはずでは？
お金を掛けて世の中を駆動していくはずの道具が有効じゃない状況は
まちがっているし、効率的でないならそれを改善する本質論から始めないなら
元々の意味を外しているに違いないと思うのだが
系沿い活動が -> 経済活動
>そもそもが社会の発展をになう経済活動が根本である以上、
そもそもが社会の発展をになう経済活動が「Xの」根本
OR
そもそもが社会の発展をになう「Xは」経済活動「の」根本
何れにしても、「X」がなんなのかをはっきりしてもらいたい。
そもそもが社会の発展をになう経済活動が「Xの」根本
OR
そもそもが社会の発展をになう「Xは」経済活動「の」根本
何れにしても、「X」がなんなのかをはっきりしてもらいたい。
まぁ豚どもにいくら日本語しゃべろっていっても無理だからなぁ。
根本から間違っていたってことか。つうか、豚語で書かないと豚は理解できないよ。>>565
根本から間違っていたってことか。つうか、豚語で書かないと豚は理解できないよ。>>565
(´･ω･`) 根本からﾌﾞｰ
真っ赤になって自演してるところが痛ましいｗ
あらゆる事業をとおして、社会に相互の関係性をもたらすことを経済活動とよぶのでは？
「根本」の使い方間違っているよ。
「根本」の使い方間違っているよ。
>>572
じゃあ言うが、あなたは今日朝飯食べないとおなかへって仕事に打ち込めない
だろ？それを言ってるだけだよ、簡単に言えば。
つまり経済効率を追求しない事業はあり得ないし、哲学論で飯食ってる
わけじゃないだろってことだよ
じゃあ言うが、あなたは今日朝飯食べないとおなかへって仕事に打ち込めない
だろ？それを言ってるだけだよ、簡単に言えば。
つまり経済効率を追求しない事業はあり得ないし、哲学論で飯食ってる
わけじゃないだろってことだよ
だから、結果として効率追求できてないなら哲学論に価値はないってことであり、
また、トータルでの経済効率で勝つ方法論が最終的に解が「正解」であるはずだと。
また、トータルでの経済効率で勝つ方法論が最終的に解が「正解」であるはずだと。
すまん、
トータルでの経済効率で勝つ方法論が最終的な「正解」であるはずだと。
トータルでの経済効率で勝つ方法論が最終的な「正解」であるはずだと。
>おなかへって仕事に打ち込めない
何の話してんだよｗ「要は」が口癖のバカを思い出した。
何の話してんだよｗ「要は」が口癖のバカを思い出した。
いまは本当に経済効率としてのﾋﾞｼﾞﾈｽになっているのかどうか、そこだな。
えっらそーな文面で説明下手ってどないやねん！！
>>576
わからないのかなあ、おなかを満たすのが経済活動、
いくら哲学語っても、社会には結果として貢献しないなら意味はないと。
哲学でおなかはいっぱいにならないんじゃないのと。
結果として効率化してそれで飯が食えるんだというのならいいけどな。
仮に奇跡が起きて中国やインドが仕事の品質上げてきて日本からPGが
一切いらなくなる事態だってあっても、それ自体不思議というわけじゃないよ。
わからないのかなあ、おなかを満たすのが経済活動、
いくら哲学語っても、社会には結果として貢献しないなら意味はないと。
哲学でおなかはいっぱいにならないんじゃないのと。
結果として効率化してそれで飯が食えるんだというのならいいけどな。
仮に奇跡が起きて中国やインドが仕事の品質上げてきて日本からPGが
一切いらなくなる事態だってあっても、それ自体不思議というわけじゃないよ。
>> 580 もちつけもちつけ、文体がおかしくなってきてるぞ。
これは、日本語でおｋを引き出すゲームか何かか？
話は、OOが組織論や人間論の問題とは別だという話から来ている。
で、それでは済ませられないんじゃないの、という話。
で、それでは済ませられないんじゃないの、という話。
だって、仮に上司が頭が悪くていい方法提案してるのにわかってもらえない、
これはOOの問題じゃなくて、組織の問題だ、-> だからコンピュータは
あまり使い勝手のいいものにならないんだよ、って話はおかしいってことです.
これはOOの問題じゃなくて、組織の問題だ、-> だからコンピュータは
あまり使い勝手のいいものにならないんだよ、って話はおかしいってことです.
普及を目指す道具や方法論にとっては、ユーザーの頭の悪さを乗り越えることこそ、
重要なブレイクスルーだと思う。
ユーザーの頭の悪さを嘆くUNIXを尻目に、Win95が爆発的に普及していったのは、
それを裏付ける出来事だった。いまだにTexを押し付けてくるダメおやじがいるけど、
はっきり言って、氏ねよって感じ。
重要なブレイクスルーだと思う。
ユーザーの頭の悪さを嘆くUNIXを尻目に、Win95が爆発的に普及していったのは、
それを裏付ける出来事だった。いまだにTexを押し付けてくるダメおやじがいるけど、
はっきり言って、氏ねよって感じ。
ある意味面白そうなんでｺﾃにしてくれｗ >>584-586
>>586は賛同者、ウレしーわ。
OO厨は、OOには得手不得手があるってことを認めたがらないところが痛い。
そして、なぜか周りに押し付けだすから性質が悪い。
そして、なぜか周りに押し付けだすから性質が悪い。
590 ：仕様書無しさん：2007/02/16(金) 17:23:51
ﾜﾛﾀｗ
このスレを見ている人はこんなスレも見ています。(ver 0.20)
[プログラム]
[テレビドラマ]
[転職]
[就職]
[就職]
ここは失業者の巣窟ですね。
このスレを見ている人はこんなスレも見ています。(ver 0.20)
[プログラム]
[テレビドラマ]
[転職]
[就職]
[就職]
ここは失業者の巣窟ですね。
592 ：仕様書無しさん：2007/02/16(金) 17:37:16
ほんとだw
JavaやるとC++は有害に感じる
がジャワ糞の証でもあるな
JavaやるとC++は有害に感じる
がジャワ糞の証でもあるな
老人がいくら戯言をほざいても
この先も、オブジェクト指向が主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でアセンブラでもくんでな名wwwww
この先も、オブジェクト指向が主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でアセンブラでもくんでな名wwwww
20年前の当時の若者の台詞より・・・
老人がいくら戯言をほざいても
この先も、構造化プログラミングが主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でgoto文でも書いてな名wwwww
老人がいくら戯言をほざいても
この先も、構造化プログラミングが主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でgoto文でも書いてな名wwwww
この時間帯は喰い付き悪いな名wwwww
構造化自体は、今でも重要で、
goto文全盛の時期は、戻ってきてません
OO批判がOO＋αの技術こそが次世代技術って言うのなら
正しいと思いますが、老害どもは、昔に戻せというばかり、
あきらかにgoto文と同じで時代の遺物ですな。
goto文全盛の時期は、戻ってきてません
OO批判がOO＋αの技術こそが次世代技術って言うのなら
正しいと思いますが、老害どもは、昔に戻せというばかり、
あきらかにgoto文と同じで時代の遺物ですな。
20年後の俺の息子の台詞より・・・
老人がいくら戯言をほざいても
この先も、センシティブミキシングが主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でクラスでもつくってな名wwwww
老人がいくら戯言をほざいても
この先も、センシティブミキシングが主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でクラスでもつくってな名wwwww
オブジェクト指向自体は、今でも重要で、
アセンブラ全盛の時期は、戻って(Ry
アセンブラ全盛の時期は、戻って(Ry
40年前の当時の若者の台詞より・・・
老人がいくら戯言をほざいても
この先も、電卓が主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でそろばんでも使ってな名wwwww
老人がいくら戯言をほざいても
この先も、電卓が主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でそろばんでも使ってな名wwwww
600 ：おじゃばさま：2007/02/16(金) 19:59:41
オブジェクト指向と言うのは結局の所、「オブジェクト指向プログラミング」の事であり、
プログラムの詳細設計に用いる物である。
ソフトウェア工学（どのようにしたら高品質な物を低コストで作れるか）の観点から言うと、
現在の時点で最も有効なのは、「プロトタイプ方式」である。
ソフトウェアの品質が悪いのは、多くの場合、試験を行っていないのが問題であり、
現代においては特に「単体試験（分岐全ルート試験）」を行ってない事による場合が大半である。
実際、大手のベンダーでも分岐全ルートの単体試験と言っても、何のことか分からない中堅も多い。
つまり現代においては「プロトタイプ方式で、JavaやC#などを使い、オブジェクト指向プログラミング
で作成し、単体試験をしっかりやる」事で殆どの問題が解決する場合が多い。
ちなみに、「プロトタイプ方式で、Cなどを使い、構造化プログラミングで作成し、
単体試験をしっかりやる」事でも同様である。
と言うか、「プロトタイプ方式で、単体試験をしっかりやる」だけで殆どの解決である。
つまり、プロジェクトの成否と言語や設計技法は関係ない。
プログラムの詳細設計に用いる物である。
ソフトウェア工学（どのようにしたら高品質な物を低コストで作れるか）の観点から言うと、
現在の時点で最も有効なのは、「プロトタイプ方式」である。
ソフトウェアの品質が悪いのは、多くの場合、試験を行っていないのが問題であり、
現代においては特に「単体試験（分岐全ルート試験）」を行ってない事による場合が大半である。
実際、大手のベンダーでも分岐全ルートの単体試験と言っても、何のことか分からない中堅も多い。
つまり現代においては「プロトタイプ方式で、JavaやC#などを使い、オブジェクト指向プログラミング
で作成し、単体試験をしっかりやる」事で殆どの問題が解決する場合が多い。
ちなみに、「プロトタイプ方式で、Cなどを使い、構造化プログラミングで作成し、
単体試験をしっかりやる」事でも同様である。
と言うか、「プロトタイプ方式で、単体試験をしっかりやる」だけで殆どの解決である。
つまり、プロジェクトの成否と言語や設計技法は関係ない。
601 ：仕様書無しさん：2007/02/16(金) 20:01:15
↑聞いたことない。次、↓
602 ：おじゃばさま：2007/02/16(金) 20:04:05
聞け
>>553
おじゃば、嘘おしえんなよwww
構造化プログラミングって、順次実行、繰り返し、条件分岐の三つの制御構造を使ってコーディング
することだろ。お前流に端的に言ってやるとgotoを使わないってことだ。
データのグループ化って構造体とかコレクションの話だろ。構造化と構造体をごっちゃにしてんじゃ
ねぇのか？えらそうに。もっかい基礎からやり直してこい。
おじゃば、嘘おしえんなよwww
構造化プログラミングって、順次実行、繰り返し、条件分岐の三つの制御構造を使ってコーディング
することだろ。お前流に端的に言ってやるとgotoを使わないってことだ。
データのグループ化って構造体とかコレクションの話だろ。構造化と構造体をごっちゃにしてんじゃ
ねぇのか？えらそうに。もっかい基礎からやり直してこい。
604 ：仕様書無しさん：2007/02/16(金) 20:14:29
まあまあ、ジャワ糞どおし仲良くしろ
605 ：仕様書無しさん：2007/02/16(金) 20:16:44
>>603はコテにするといいぞ。
「ううぷさま」とかがいいと思うよ
「ううぷさま」とかがいいと思うよ
606 ：仕様書無しさん：2007/02/16(金) 20:17:22
ところでだれかsubtypeって単語の意味を教えてくれないか。
>>600
>つまり現代においては「プロトタイプ方式で、JavaやC#などを使い、オブジェクト指向プログラミング
>で作成し、単体試験をしっかりやる」事で殆どの問題が解決する場合が多い。
こんな強引な理論はじめてきいたよ。現場にいないとこんなんなっちゃうのか？
>つまり現代においては「プロトタイプ方式で、JavaやC#などを使い、オブジェクト指向プログラミング
>で作成し、単体試験をしっかりやる」事で殆どの問題が解決する場合が多い。
こんな強引な理論はじめてきいたよ。現場にいないとこんなんなっちゃうのか？
俺はテスト駆動に夢中さ
ぬるぽだ配列インデックス例外だのコーディングバグだの単体はおいといて、
結合バグの大半は業務のステータスとモデルの状態との関係が満たされないことによる事前条件違反呼び出しだよ。
実行したのはいいがDBにレコードがなかったり、想定される値と違う値がはいってるとか。
業務フロー、ステートチャートの各状態とインスタンス(DBテーブル)の状態のミスマッチが根本原因。
だから、ステータスの値とその時のオブジェクトの状態を厳密に1対1で定義して、
ステータス更新前には必ずその状態をみたしているかアサーション使って厳密にテストをしてみればいい。
結合バグの大半は業務のステータスとモデルの状態との関係が満たされないことによる事前条件違反呼び出しだよ。
実行したのはいいがDBにレコードがなかったり、想定される値と違う値がはいってるとか。
業務フロー、ステートチャートの各状態とインスタンス(DBテーブル)の状態のミスマッチが根本原因。
だから、ステータスの値とその時のオブジェクトの状態を厳密に1対1で定義して、
ステータス更新前には必ずその状態をみたしているかアサーション使って厳密にテストをしてみればいい。
610 ：仕様書無しさん：2007/02/16(金) 20:41:33
＿
| |
| |
|＿＿|
（°Д°）殆どの問題が解決する場合が多い可能性が必ずしも無きにしも非ずといったところでしょうか・・・・
／ | ＼
/＿ .|/￣￣￣￣/ ビコビコ
__(＿_|つ / おじゃば/ ＿＿＿＿
＼/＿＿＿＿/
| |
| |
|＿＿|
（°Д°）殆どの問題が解決する場合が多い可能性が必ずしも無きにしも非ずといったところでしょうか・・・・
／ | ＼
/＿ .|/￣￣￣￣/ ビコビコ
__(＿_|つ / おじゃば/ ＿＿＿＿
＼/＿＿＿＿/
611 ：仕様書無しさん：2007/02/16(金) 20:49:33
./ ;ヽ
l ＿,,,,,,,,＿,;;;;i ＜いいぞ ベイべー！
l l''|~___;;､_y__ lﾐ;l 実戦を知らない奴ほどよく吠える！！
ﾞl;| | `'",;_,i`'"|;i |
,r''i ヽ, '~rーj`c=/
,／ ヽ ヽ`ｰ"/:: `ヽ
/ ﾞヽ ￣､::::: ﾞl, ホント 戦場は地獄だぜ！ フゥハハハーハァー
|;/"⌒ヽ, ＼ ヽ: _l＿ ri ri
l l ヽr‐─ヽ＿|_⊂////;`ゞ--―─-r| | / |
ﾞlﾞl, l,|｀ﾞﾞﾞ''―ll＿__l,,l,|,iﾉ二二二二│｀""""""""""""|二;;二二;;二二二i≡二三三l
| ヽ ヽ _|＿ ＿ "l￣￣￣￣￣￣ |二;;二二;;二='''''''''''￣ﾉ
/"ヽ 'j＿／ヽヽ,￣ ,,,/"''''''''''''⊃r‐l'二二二T￣￣￣ ［iﾞ''''''''''''''''"ﾞﾞﾞ￣`"
／ ヽ ー──''''''""(;;) ｀ﾞ,j" | | |
l ＿,,,,,,,,＿,;;;;i ＜いいぞ ベイべー！
l l''|~___;;､_y__ lﾐ;l 実戦を知らない奴ほどよく吠える！！
ﾞl;| | `'",;_,i`'"|;i |
,r''i ヽ, '~rーj`c=/
,／ ヽ ヽ`ｰ"/:: `ヽ
/ ﾞヽ ￣､::::: ﾞl, ホント 戦場は地獄だぜ！ フゥハハハーハァー
|;/"⌒ヽ, ＼ ヽ: _l＿ ri ri
l l ヽr‐─ヽ＿|_⊂////;`ゞ--―─-r| | / |
ﾞlﾞl, l,|｀ﾞﾞﾞ''―ll＿__l,,l,|,iﾉ二二二二│｀""""""""""""|二;;二二;;二二二i≡二三三l
| ヽ ヽ _|＿ ＿ "l￣￣￣￣￣￣ |二;;二二;;二='''''''''''￣ﾉ
/"ヽ 'j＿／ヽヽ,￣ ,,,/"''''''''''''⊃r‐l'二二二T￣￣￣ ［iﾞ''''''''''''''''"ﾞﾞﾞ￣`"
／ ヽ ー──''''''""(;;) ｀ﾞ,j" | | |
>>609
あなたが結局何を言いたいのかなんだかびみょーによく分からない。豚語でしゃべってみてくれ。
あなたが結局何を言いたいのかなんだかびみょーによく分からない。豚語でしゃべってみてくれ。
まぁまぁOOP厨。これ見てもちつけ
つ（継承 ポリモーフィズム カプセル可）
つ（継承 ポリモーフィズム カプセル可）
>>613
哲学すきですからｗ
哲学すきですからｗ
>>612
発覚するバグの多くは、データがDBに無いのにそのデータを処理しようとするのが原因ってことですよ。
例えば、ログイン処理はIDからユーザ情報ひっぱってきてパスワード比較するでしょ？
でも、これはあらかじめユーザ登録したときにちゃんとIDとパスワードを登録しないとだめだよね。
当然こんなことが起きることは誰でも想定できるからエラーだったら画面にメッセージ出して知らせることが出来る。
でも、もっと複雑な情報（テーブルが100個とかの場合には
データが入ってると思っていたテーブルにレコードが無いことが往々にある。
さらにレコードが無いなら入れればいいだけなんだけど、
カラムの値も想定しない値だった場合には・・・気づきにくいよね？
こんなことはもう頭の中では想定し切れないからバグるんだよ。
発覚するバグの多くは、データがDBに無いのにそのデータを処理しようとするのが原因ってことですよ。
例えば、ログイン処理はIDからユーザ情報ひっぱってきてパスワード比較するでしょ？
でも、これはあらかじめユーザ登録したときにちゃんとIDとパスワードを登録しないとだめだよね。
当然こんなことが起きることは誰でも想定できるからエラーだったら画面にメッセージ出して知らせることが出来る。
でも、もっと複雑な情報（テーブルが100個とかの場合には
データが入ってると思っていたテーブルにレコードが無いことが往々にある。
さらにレコードが無いなら入れればいいだけなんだけど、
カラムの値も想定しない値だった場合には・・・気づきにくいよね？
こんなことはもう頭の中では想定し切れないからバグるんだよ。
>>600
結局そういうことなんでしょうが、つまり手抜きはできないってことで、
手抜きすれば品質が落ちる、しかししっかりやればコストが掛かる
コスト掛けてもよければいくらでもデバッグやりすぎるということはないはず
しかし結局それでコストかかれば元が取れないことに
要するにソフトウエアは人間が作る限界を越えられず、面倒なテストを
たくさんうあればどうしても効率が落ちてしまい、儲けもなくなってしまう結果に
>>609
それでもどうしても抜けはでますよね、人間ですからね。
でも>>600や>>609でしっかりやれば初期不良程度の被害で済ませられる
ぐらいに品質は向上し致命的な欠陥を残さないで済む確率が上がる
結果として商売は継続可能な程度に仕事ができることになると、こういう
ことですよね ｗ
結局そういうことなんでしょうが、つまり手抜きはできないってことで、
手抜きすれば品質が落ちる、しかししっかりやればコストが掛かる
コスト掛けてもよければいくらでもデバッグやりすぎるということはないはず
しかし結局それでコストかかれば元が取れないことに
要するにソフトウエアは人間が作る限界を越えられず、面倒なテストを
たくさんうあればどうしても効率が落ちてしまい、儲けもなくなってしまう結果に
>>609
それでもどうしても抜けはでますよね、人間ですからね。
でも>>600や>>609でしっかりやれば初期不良程度の被害で済ませられる
ぐらいに品質は向上し致命的な欠陥を残さないで済む確率が上がる
結果として商売は継続可能な程度に仕事ができることになると、こういう
ことですよね ｗ
要するにソフトウエアは人間が作る限界を越えられず、ということは、OOPでどんなにか
やってみても、やはりテストで格闘することには変わりはないわけで。
ただ、トータルでメリットがあるからそうしているのだと、いうことでなければ商売には
ならないわけでもあり、結局は商売として成り立つ成り立たないかによって判断されるしかない。
つまりは経済原則上の天秤で勝つか負けるかの問題に帰着するわけです、
OOPも価値論もすべて．
やってみても、やはりテストで格闘することには変わりはないわけで。
ただ、トータルでメリットがあるからそうしているのだと、いうことでなければ商売には
ならないわけでもあり、結局は商売として成り立つ成り立たないかによって判断されるしかない。
つまりは経済原則上の天秤で勝つか負けるかの問題に帰着するわけです、
OOPも価値論もすべて．
>>発覚するバグの多くは、データがDBに無いのにそのデータを処理しようとするのが原因ってことですよ。
そもそも何故DBの使用が前提になっているのかが分からない。DBまわりでしかバグって発覚しないのか？
そして文の意味がわからない。「データがDBに無かったらそのデータを処理しない」っていうのが仕様で、
それをプログラムで処理しようしたという状況の話なのかな・・・
普通、DBにありえないデータは制約を設定しとかない？ あとは例外投げたりとか。 発覚するパグの多くが～
って飛躍しすぎじゃない？ それと、なんだかその辺の本やWebに書いてあるような安っぽい話を偉そうに書か
れてもって感じだが豚の俺にはよくわからないな。はずしてたらすまん。
そもそも何故DBの使用が前提になっているのかが分からない。DBまわりでしかバグって発覚しないのか？
そして文の意味がわからない。「データがDBに無かったらそのデータを処理しない」っていうのが仕様で、
それをプログラムで処理しようしたという状況の話なのかな・・・
普通、DBにありえないデータは制約を設定しとかない？ あとは例外投げたりとか。 発覚するパグの多くが～
って飛躍しすぎじゃない？ それと、なんだかその辺の本やWebに書いてあるような安っぽい話を偉そうに書か
れてもって感じだが豚の俺にはよくわからないな。はずしてたらすまん。
>>618
横レスだけど概ねバグってものの意味としては当たってると思うよ。
DBに限らず、要するに想定外の環境状況だってことでしょ。「想定外」は
要は設計の問題だとも言えなくもないけどね。設計でその仕様環境が
想定されているべきはずなのに、そこに漏れがあるために途中で想定外の
動作となってしまうと。
それは例外を投げるとか投げないとかじゃなくて、投げても結局は
想定外なんだからそれ以上の対応はできなわけでお客にとっては
要するにバグ、動かないものは価値がない、それだけってことで。
これは例外ですと自分のプログラムで出そうと、開発環境が出そうと
品質が悪いことには本来的には変わりはない、つまり、目的の結果を
達成できていないという業務目的のロジックという本来の商品目的が
外れているなら、いくらOOPの哲学ぶってもどうしようもないわけでしょ。
横レスだけど概ねバグってものの意味としては当たってると思うよ。
DBに限らず、要するに想定外の環境状況だってことでしょ。「想定外」は
要は設計の問題だとも言えなくもないけどね。設計でその仕様環境が
想定されているべきはずなのに、そこに漏れがあるために途中で想定外の
動作となってしまうと。
それは例外を投げるとか投げないとかじゃなくて、投げても結局は
想定外なんだからそれ以上の対応はできなわけでお客にとっては
要するにバグ、動かないものは価値がない、それだけってことで。
これは例外ですと自分のプログラムで出そうと、開発環境が出そうと
品質が悪いことには本来的には変わりはない、つまり、目的の結果を
達成できていないという業務目的のロジックという本来の商品目的が
外れているなら、いくらOOPの哲学ぶってもどうしようもないわけでしょ。
そういうときに、OOPならメンテナンス性も上がっていってバグへの対応も高速で
効率的で弊害もごく少なく対処できるようになっています、というふうにならない
のなら、OOP的に作られていますと言っても認めてもらえないかもね。
効率的で弊害もごく少なく対処できるようになっています、というふうにならない
のなら、OOP的に作られていますと言っても認めてもらえないかもね。
>>620
やっぱり分からんぞ。なんで「例外」＝「品質が悪い」になるんだ？
例外ってビネスロジックエラーにも普通に使うだろ？ バグじゃないだろ。
もしかしてシステム例外に限定した話になってる？
データが無い＝システムエラーってことか？ そりゃ設計が悪いか制約の
設定漏れだろ。プログラムのバクではない。ましてやＯＯＰとは関係ない。
やっぱり分からんぞ。なんで「例外」＝「品質が悪い」になるんだ？
例外ってビネスロジックエラーにも普通に使うだろ？ バグじゃないだろ。
もしかしてシステム例外に限定した話になってる？
データが無い＝システムエラーってことか？ そりゃ設計が悪いか制約の
設定漏れだろ。プログラムのバクではない。ましてやＯＯＰとは関係ない。
結局OOPですとは言え、目的はビジネスロジックの実現であり実装がより
完全になるようにすることで商売がいいものになることでなければならず。
OOPでなかった時代だっていい仕事する仕事師は設計がやはり良かったと
いえばOOPだからすべて解決するというのは空想論なのでは。結局商売を
成功させるのは、OOPが必要条件だ、ともいえず、また当然ながら十分条件
でもない、ということなのでは。
完全になるようにすることで商売がいいものになることでなければならず。
OOPでなかった時代だっていい仕事する仕事師は設計がやはり良かったと
いえばOOPだからすべて解決するというのは空想論なのでは。結局商売を
成功させるのは、OOPが必要条件だ、ともいえず、また当然ながら十分条件
でもない、ということなのでは。
OOP使って書いたほうが書きやすい俺は異端なのか？
クラス無しだと書きにくいっつーか
ローカルインナークラスまで含めると
小さなコードでも10クラス、大きなコードなら自然と数十クラス～100越えになるんだが
クラス無しだと書きにくいっつーか
ローカルインナークラスまで含めると
小さなコードでも10クラス、大きなコードなら自然と数十クラス～100越えになるんだが
ええい、誰が何書いてんのか分からんわい。お前ら酉つけろ。
>>622
例外が品質悪い、のではなくて、想定外の状況がたくさん出てくる、というところに
問題が生まれるのだ、ということでしょう。
想定外がたくさん出てくるということが、OOP的でなかったからなのか、それとも
OOPだったのにそうなったのか、それがもしOOPと関係なく、OOPであってもなくても
想定外が多いのだとしたら、結局OOPの良いほうへの寄与率は５０％で必ずしも
品質上げることに寄与しない、ということになって、そうだとしたらOOPの価値は
言われるよりも低いじゃないか、ということでは？
例外が品質悪い、のではなくて、想定外の状況がたくさん出てくる、というところに
問題が生まれるのだ、ということでしょう。
想定外がたくさん出てくるということが、OOP的でなかったからなのか、それとも
OOPだったのにそうなったのか、それがもしOOPと関係なく、OOPであってもなくても
想定外が多いのだとしたら、結局OOPの良いほうへの寄与率は５０％で必ずしも
品質上げることに寄与しない、ということになって、そうだとしたらOOPの価値は
言われるよりも低いじゃないか、ということでは？
>>622
>やっぱり分からんぞ。なんで「例外」＝「品質が悪い」になるんだ？
>例外ってビネスロジックエラーにも普通に使うだろ？ バグじゃないだろ。
想定される例外は検査例外でハンドルするようになってるだろ？
でも、あると思っていたデータが無かったとか、想定されない状態のデータ（オブジェクト）を扱おうとすれば
それは当然システムエラーだ。
publi class UserDAO{
public User findUser(String userId){
//DBのユーザTBLからデータ引っ張ってきてUserインスタンスを生成、セットして返す。
}
}
public class User{
private String userId;
private String password;
boolean auth(String password){
return this.password.equals(password);
}
}
>やっぱり分からんぞ。なんで「例外」＝「品質が悪い」になるんだ？
>例外ってビネスロジックエラーにも普通に使うだろ？ バグじゃないだろ。
想定される例外は検査例外でハンドルするようになってるだろ？
でも、あると思っていたデータが無かったとか、想定されない状態のデータ（オブジェクト）を扱おうとすれば
それは当然システムエラーだ。
publi class UserDAO{
public User findUser(String userId){
//DBのユーザTBLからデータ引っ張ってきてUserインスタンスを生成、セットして返す。
}
}
public class User{
private String userId;
private String password;
boolean auth(String password){
return this.password.equals(password);
}
}
想定外の状況がたくさん出てくるってことは、OOP云々以前にそりゃ設計が悪いだろ。
public class AuthService{
punlic boolean auth(String userId,String password){
UserDAO dao = new UserDAO();
User user = dao.findUser(userId);
return user.auth(password);
}
}
としたときにUserクラスで認証しようとしてもユーザTBLにパスワード属性がNULLだったら
NullPointerExceptionが出るだろ。
テーブルの状態、エンティティの状態がおかしいからこうなる。
punlic boolean auth(String userId,String password){
UserDAO dao = new UserDAO();
User user = dao.findUser(userId);
return user.auth(password);
}
}
としたときにUserクラスで認証しようとしてもユーザTBLにパスワード属性がNULLだったら
NullPointerExceptionが出るだろ。
テーブルの状態、エンティティの状態がおかしいからこうなる。
630 ：仕様書無しさん：2007/02/16(金) 22:42:09
もう、あれだ。ぷちオブジェクト指向でいいんじゃね？
>>630
中途半端なOOPならまだやらないほうがマシ。
ER図書いて処理はSQL、ストアドプロシージャでやればいい。
理由はDAO用のエンティティクラスに詰め替えるのが面倒だから。
エンティティクラス作るのならOOPやればいいじゃん？
中途半端なOOPならまだやらないほうがマシ。
ER図書いて処理はSQL、ストアドプロシージャでやればいい。
理由はDAO用のエンティティクラスに詰め替えるのが面倒だから。
エンティティクラス作るのならOOPやればいいじゃん？
>>632
だから分かってないね・・・
じゃあ、NULLじゃなくて「必ず3レコードある」という制約は？
クラス図だと1対3といった個数制約。
その前提に基づいてクラスメソッド設計されるっしょ？
でも2個しかなかったら？どうDBの制約でカバーするの？
だから分かってないね・・・
じゃあ、NULLじゃなくて「必ず3レコードある」という制約は？
クラス図だと1対3といった個数制約。
その前提に基づいてクラスメソッド設計されるっしょ？
でも2個しかなかったら？どうDBの制約でカバーするの？
>>633
「必ず3レコードある」・・・なんだよそれ。
それがクリティカルな条件ならトリガ使うとか関数やストアドでロジックを局所化
するとかするだろうけど。
話の論点が変わってきているけど、結局そんな状況でプログラムに発生するバクっ
て別にＤＢに限った話じゃねぇじゃねぇかよ。
「必ず3レコードある」・・・なんだよそれ。
それがクリティカルな条件ならトリガ使うとか関数やストアドでロジックを局所化
するとかするだろうけど。
話の論点が変わってきているけど、結局そんな状況でプログラムに発生するバクっ
て別にＤＢに限った話じゃねぇじゃねぇかよ。
635 ：仕様書無しさん：2007/02/16(金) 23:32:51
なんかね、こんな状態じゃあ、まだまだだね。
でも、そんな人を相手に商売しているから馬鹿にできないんだけどね。
みんな、まいどあり～って感じだよ。ほんとに…
でも、そんな人を相手に商売しているから馬鹿にできないんだけどね。
みんな、まいどあり～って感じだよ。ほんとに…
>>633
クラス図1対3でしょ？ テーブルAとテーブルBだとして、テーブルA側に
Bの主キーフィールド3つ設けて、それらに外部キー制約つけるってのは？
これが何十個とかなったら、そうだなカウント用のテーブル設けて、その
カウントフィールドに 整合性制約つけるってのは？
スレ違い失礼・・・ただ設計で取り除けるリスクは極力そうするべきだね。
クラス図1対3でしょ？ テーブルAとテーブルBだとして、テーブルA側に
Bの主キーフィールド3つ設けて、それらに外部キー制約つけるってのは？
これが何十個とかなったら、そうだなカウント用のテーブル設けて、その
カウントフィールドに 整合性制約つけるってのは？
スレ違い失礼・・・ただ設計で取り除けるリスクは極力そうするべきだね。
亀ですが
トランザクションスクリプト・ドメインモデル・テーブルモジュールの概要はこちらでどうぞ。
エンタープライズ・アプリケーション・アーキテクチャのパターン
http://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
トランザクションスクリプト・ドメインモデル・テーブルモジュールの概要はこちらでどうぞ。
エンタープライズ・アプリケーション・アーキテクチャのパターン
http://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
>>634
すまん。ちょっとムキになった。
DBで制約かければ解決するってことを言いたい訳じゃない。
DBの有り無しなんて関係ない。
要するに、メソッド呼ぶするときにエンティティのインスタンスの状態さえ
正しければ無事処理できるってことを言いたい。
DBに永続化したエンティティを取得してインスタンス使って処理するわけだから
レコード（クラスのインスタンス）とそのカラム（クラスの属性値）がおかしいと
メソッド呼んだときにバグるってこと。
すまん。ちょっとムキになった。
DBで制約かければ解決するってことを言いたい訳じゃない。
DBの有り無しなんて関係ない。
要するに、メソッド呼ぶするときにエンティティのインスタンスの状態さえ
正しければ無事処理できるってことを言いたい。
DBに永続化したエンティティを取得してインスタンス使って処理するわけだから
レコード（クラスのインスタンス）とそのカラム（クラスの属性値）がおかしいと
メソッド呼んだときにバグるってこと。
>>637
それちゃんと本買って読んだほうがいいね。
それちゃんと本買って読んだほうがいいね。
Design by Contractがちっとも流行らないのは、
結局そういう「想定外の状況」から生まれるバグに対して
みんな大して困ってないってことなんじゃないの？
結局そういう「想定外の状況」から生まれるバグに対して
みんな大して困ってないってことなんじゃないの？
PoEAAは抽象的だけどよく読んで具体例考えながら読めば
大抵のJavaシステムはトランザクションスクリプトでしか作ってないことが分かる。
ライブラリレベルならドメインモデルが多い。MSならテーブルモジュールだね。
OOP信者ならシステム全体をドメインモデルで作りたいと思うのは当然だけど
作りやすさ、分かりやすさならトランザクションスクリプトの優勢。
だって画面で入力したデータをDTOに詰めてをDAOに渡せばDBに入れてくれるし、
計算はDBのSQLでやって結果だけDTOでもらって画面表示すればいいわけだし。
単純なデータの出し入れが目的なシステムならコレが楽チン。OOPなんていらない。
大抵のJavaシステムはトランザクションスクリプトでしか作ってないことが分かる。
ライブラリレベルならドメインモデルが多い。MSならテーブルモジュールだね。
OOP信者ならシステム全体をドメインモデルで作りたいと思うのは当然だけど
作りやすさ、分かりやすさならトランザクションスクリプトの優勢。
だって画面で入力したデータをDTOに詰めてをDAOに渡せばDBに入れてくれるし、
計算はDBのSQLでやって結果だけDTOでもらって画面表示すればいいわけだし。
単純なデータの出し入れが目的なシステムならコレが楽チン。OOPなんていらない。
>>642
その構造をOOPじゃ無いと言い切るナイーブな意見はわからんな。
OOPのメソッドレベルの構造がトランザクション・スクリプトなだけなような。
そして、システム全体はドメインモデルを作っている構造だと思う。
その構造をOOPじゃ無いと言い切るナイーブな意見はわからんな。
OOPのメソッドレベルの構造がトランザクション・スクリプトなだけなような。
そして、システム全体はドメインモデルを作っている構造だと思う。
>>642
あれ？いったんドメインオブジェクトを習得した開発者なら、よっぽど
簡単なものをつくるとき以外、二度とトランザクションスクリプトに戻りたいとは
思わないでしょう、って書いてあったと思うけど。
あれ？いったんドメインオブジェクトを習得した開発者なら、よっぽど
簡単なものをつくるとき以外、二度とトランザクションスクリプトに戻りたいとは
思わないでしょう、って書いてあったと思うけど。
つかファウラーってアンチDTOの第一人者じゃないのか？
俺、DTOとかDAOってOOPの産物かと思ってた。だってOがついてるじゃん。
>>644
その本読んだ事無いから、誤解してるかもしれんが、
世の中の、ほとんどの業務が、その「よっぽど簡単な業務」に当てはまる
業務ロジックをオブジェクトの単位にして、それの組み合わせで実現だけだと思う。
その本読んだ事無いから、誤解してるかもしれんが、
世の中の、ほとんどの業務が、その「よっぽど簡単な業務」に当てはまる
業務ロジックをオブジェクトの単位にして、それの組み合わせで実現だけだと思う。
ﾋｿﾋｿ( ﾟдﾟ)ﾔﾀﾞｧ(ﾟдﾟ )ﾈｪ､ｷｲﾀ?( ﾟдﾟ)ｵｸｻﾝ(ﾟдﾟ )ｱﾗﾔﾀﾞﾜｧ
( ﾟдﾟ)ﾖﾉﾅｶﾉ、ﾎﾄﾝﾄﾞﾉｷﾞｮｳﾑｶﾞ、ｶﾝﾀﾝﾅｷﾞｮｳﾑﾅﾝﾃﾞｽｯﾃｰ。(ﾟдﾟ )ﾏｧ
( ﾟдﾟ)ﾅﾒﾗﾚﾀﾓﾉﾈｪｰ
ﾋｿﾋｿ( ﾟдﾟ)ﾔﾀﾞｧ
( ﾟдﾟ)ﾖﾉﾅｶﾉ、ﾎﾄﾝﾄﾞﾉｷﾞｮｳﾑｶﾞ、ｶﾝﾀﾝﾅｷﾞｮｳﾑﾅﾝﾃﾞｽｯﾃｰ。(ﾟдﾟ )ﾏｧ
( ﾟдﾟ)ﾅﾒﾗﾚﾀﾓﾉﾈｪｰ
ﾋｿﾋｿ( ﾟдﾟ)ﾔﾀﾞｧ
結局、自分たちが欲しいのは「便利で堅牢で優れたコンポーネント」であって、
自分が「便利で堅牢で優れたコンポーネント」を作りたいとは思わない
だって面倒じゃないか
自分が「便利で堅牢で優れたコンポーネント」を作りたいとは思わない
だって面倒じゃないか
まぁまぁ、これ見てもちつけ
つ（軽症 ポリウレタン カプセル蚊）
つ（軽症 ポリウレタン カプセル蚊）
「便利で堅牢で優れたコンポーネント」は、
「「便利で堅牢で優れたコンポーネント」を作りたいとは思わない」ような
無能な開発者の代替となりうるぞ。
「「便利で堅牢で優れたコンポーネント」を作りたいとは思わない」ような
無能な開発者の代替となりうるぞ。
>>565
>目的が存在しない行動は本来あり得ないし、
？？？
まず、コボル上がりは、困る！
基本的にサブルーチンに引数があるという概念すら持ち合わせていないので
オブジェクト指向を語る資格は無い（キーボードに触れてはならぬ！！）
現実世界がオブジェクト指向で全て説明できるという現実世界の経験値が限りなく０に近いゲームオタクも困る！
現在はコンピューターのリソースが贅沢に使える環境なので
昔の構造化プログラミングよりも若干現実世界に近づいた考え方で
プログラムが組める、程度でしかないのだよ。オブジェクト指向は
また、オブジェクト指向は万能でない！と主張している、若干脳みそが至らないイマイチ君は声を小さくして欲しい！
ヴァカはひっこんでろ！
おれは、仕事をさっさと終わらせて、自転車で荒川サイクリングロードを走りたいんだよ
中野のキャバクラでオネーチャン口説きたいんだよ！
おれの作ったシステムを新聞で見たいんだよ！
（今のところ業界紙のみ）
>目的が存在しない行動は本来あり得ないし、
？？？
まず、コボル上がりは、困る！
基本的にサブルーチンに引数があるという概念すら持ち合わせていないので
オブジェクト指向を語る資格は無い（キーボードに触れてはならぬ！！）
現実世界がオブジェクト指向で全て説明できるという現実世界の経験値が限りなく０に近いゲームオタクも困る！
現在はコンピューターのリソースが贅沢に使える環境なので
昔の構造化プログラミングよりも若干現実世界に近づいた考え方で
プログラムが組める、程度でしかないのだよ。オブジェクト指向は
また、オブジェクト指向は万能でない！と主張している、若干脳みそが至らないイマイチ君は声を小さくして欲しい！
ヴァカはひっこんでろ！
おれは、仕事をさっさと終わらせて、自転車で荒川サイクリングロードを走りたいんだよ
中野のキャバクラでオネーチャン口説きたいんだよ！
おれの作ったシステムを新聞で見たいんだよ！
（今のところ業界紙のみ）
>>653
お前の目的は便利で堅牢で優れたコンポーネントを作ることなら別に構わん
だが、多くの開発プロジェクトの目的は便利で堅牢で優れたコンポーネントを作ることではない
多くの開発プロジェクトの目的はクライアントの望むものを作ることであり、
多くのクライアントは便利で堅牢で優れたコンポーネントを作ることは多分望んでいない
望んでいるとしても優先順位は低いだろう
昔の汎用機はDBMSにあたる部分やTCP/IPにあたる部分すら自作だったが
今は便利で堅牢で優れたコンポーネントがある
便利で堅牢で優れたコンポーネントはいずれ賢い誰かが作る
もう一度聞くけど、お前の目的はクライアントの目的と一致しているか？
「ライト、ついてますか」 by G.M.ワインバーグ
お前の目的は便利で堅牢で優れたコンポーネントを作ることなら別に構わん
だが、多くの開発プロジェクトの目的は便利で堅牢で優れたコンポーネントを作ることではない
多くの開発プロジェクトの目的はクライアントの望むものを作ることであり、
多くのクライアントは便利で堅牢で優れたコンポーネントを作ることは多分望んでいない
望んでいるとしても優先順位は低いだろう
昔の汎用機はDBMSにあたる部分やTCP/IPにあたる部分すら自作だったが
今は便利で堅牢で優れたコンポーネントがある
便利で堅牢で優れたコンポーネントはいずれ賢い誰かが作る
もう一度聞くけど、お前の目的はクライアントの目的と一致しているか？
「ライト、ついてますか」 by G.M.ワインバーグ
スケジュールも悪いし、政治も悪いんだが、一番たちが悪いのは、
俺関係ないも～んっ、おたくらでやってねって無関心を装って気取っ
てるバカだ。
俺関係ないも～んっ、おたくらでやってねって無関心を装って気取っ
てるバカだ。
>>655
>>651はデスマの原因が業務の複雑性にあるんじゃないかっていってるだけで、
オブジェクト指向でデスマを解消できるとはひとことも言っていないわけだが。
むしろお前が銀の弾丸言いたいだけちゃうんかと。
>>651はデスマの原因が業務の複雑性にあるんじゃないかっていってるだけで、
オブジェクト指向でデスマを解消できるとはひとことも言っていないわけだが。
むしろお前が銀の弾丸言いたいだけちゃうんかと。
目的は検収完了
コンポーネントの使用は目的のための手段。
コンポーネントの使用は目的のための手段。
>>659
今まで人海戦術でやってたことが出来合いのコンポーネント使うことで
工数かからなくなったら、クレクレいってるだけの雑魚は失業するんじゃないのってことを
いってるんだけど。
クライアントの目的とどう関係あるのかわからん。。
今まで人海戦術でやってたことが出来合いのコンポーネント使うことで
工数かからなくなったら、クレクレいってるだけの雑魚は失業するんじゃないのってことを
いってるんだけど。
クライアントの目的とどう関係あるのかわからん。。
>>660
> 俺関係ないも～んっ、おたくらでやってねって無関心を装って
> 気取ってるバカだ。
ああ、オブジェクト設計さえすれば自分以外の誰かが悪いと妄想する奴のことか
こういう奴は自分だけは正しいと勘違いしているから困る
> 俺関係ないも～んっ、おたくらでやってねって無関心を装って
> 気取ってるバカだ。
ああ、オブジェクト設計さえすれば自分以外の誰かが悪いと妄想する奴のことか
こういう奴は自分だけは正しいと勘違いしているから困る
俺はクライアントが望むものをへへぇっ、作ります、やります、まかせてください。
できます、できます、っいってコストもスキルもノウハウもリソースもスケジュール
も無視して仕事をいけいけどんどん進めちゃうクライアント至上主義の奴がデス
マを引き起こすということを知っている。クライアント至上主義の奴はクライアント
は仮に満足させられてもスタッフを不幸に引きずり込む。 Win-Winの関係は築けない。
できます、できます、っいってコストもスキルもノウハウもリソースもスケジュール
も無視して仕事をいけいけどんどん進めちゃうクライアント至上主義の奴がデス
マを引き起こすということを知っている。クライアント至上主義の奴はクライアント
は仮に満足させられてもスタッフを不幸に引きずり込む。 Win-Winの関係は築けない。
>>658
いやだから誰もスケジュールが無茶なのをオブジェクト指向で全てなんとか出来るなんて言ってなくね？
いやだから誰もスケジュールが無茶なのをオブジェクト指向で全てなんとか出来るなんて言ってなくね？
>>665
はいはい、君はクライアントよりも賢いね
ならばクライアントなんていらなくね？
自分の望むものを作って、それを欲しいと思う人間が金を出せばいい
うん、それが理想じゃね？
それこそが真のWin-Winの関係じゃね？
はいはい、君はクライアントよりも賢いね
ならばクライアントなんていらなくね？
自分の望むものを作って、それを欲しいと思う人間が金を出せばいい
うん、それが理想じゃね？
それこそが真のWin-Winの関係じゃね？
俺が今やってるプロジェクトボロボロなのは下位レイヤー担当がオブジェクト指向を全然理解してないせいだけどな。
インターフェースクラスの存在理由を理解してないアホばっかだから
平気で実装クラスを継承しろとか言ってくるんだぜ。
アホの作ったアホクラスを継承しなきゃいけないってことがこんなにストレスたまるとは知らんかったよ。
インターフェースクラスの存在理由を理解してないアホばっかだから
平気で実装クラスを継承しろとか言ってくるんだぜ。
アホの作ったアホクラスを継承しなきゃいけないってことがこんなにストレスたまるとは知らんかったよ。
毎日８時間労働で帰れるような開発案件だけが黙ってても都合よく手元に流れて
くると、社会はマシンのように精密に計画された仕事をどっかの誰かが創造して、
くれていて適材適所で割り当てているのだと、本気で考えている想像力のないバ
カ多くて困る。
くると、社会はマシンのように精密に計画された仕事をどっかの誰かが創造して、
くれていて適材適所で割り当てているのだと、本気で考えている想像力のないバ
カ多くて困る。
すべて人次第
>>665
あんたの中じゃ勝手に決着しちゃってるのかも知れないけど、
>世の中のほとんどの業務が非常に簡単な業務である
>世のデスマはほとんどスケジュールの問題である
(故に)
>オブジェクト指向は不要
っていう論理に納得する向きは少ないと思うんだけど。
あんたの中じゃ勝手に決着しちゃってるのかも知れないけど、
>世の中のほとんどの業務が非常に簡単な業務である
>世のデスマはほとんどスケジュールの問題である
(故に)
>オブジェクト指向は不要
っていう論理に納得する向きは少ないと思うんだけど。
>>668 いや、俺マジそれが理想だと思うよ。クライアントの行ってることが必ず
しも正しいとは限んないぜ。クライアントのバカ担当にあたったら目もあてられない。
しも正しいとは限んないぜ。クライアントのバカ担当にあたったら目もあてられない。
レベルが上がったり、下がったり激しいのは
書き込む人のレベルがバラバラだからなんだろうなw
まず技術者は良い方法を模索したり
探求する姿勢は必須と思うな。
目的が達成されさえすればれば良いという様な
考え方は経営視点としてはまぁ仕方ない側面もあるが、
技術者としては終わってる考え方だな。
雑魚レベルの人しか
その様な考え方はしないと思うが
危険な考え方だな。
書き込む人のレベルがバラバラだからなんだろうなw
まず技術者は良い方法を模索したり
探求する姿勢は必須と思うな。
目的が達成されさえすればれば良いという様な
考え方は経営視点としてはまぁ仕方ない側面もあるが、
技術者としては終わってる考え方だな。
雑魚レベルの人しか
その様な考え方はしないと思うが
危険な考え方だな。
>>675
> まず技術者は良い方法を模索したり
> 探求する姿勢は必須と思うな。
そうだね。オブジェクト設計が至高であり最高の設計方法という
思考停止に陥ってはいけないね。
常に良い方法を模索する必要がある
> まず技術者は良い方法を模索したり
> 探求する姿勢は必須と思うな。
そうだね。オブジェクト設計が至高であり最高の設計方法という
思考停止に陥ってはいけないね。
常に良い方法を模索する必要がある
ここは自作自演がいっぱいでつね
>>657
いい事を言った！
いい事を言った！
>673
お前の様なのが技術者の信用を
落としてるんだろうな…
もうさ、素直に辞めちゃえよ。
本当は仕事嫌いなんだろ？
お前の様なのが技術者の信用を
落としてるんだろうな…
もうさ、素直に辞めちゃえよ。
本当は仕事嫌いなんだろ？
やっぱりアールグレイパターンにおける
ストレートかオレンジペコーパターンのストレートだな
ストレートかオレンジペコーパターンのストレートだな
オブジェクト指向を妄信してる奴は
新興宗教を妄信している奴と同じぐらい使えない
オブジェクト指向が流行したらこの世の地獄だな
ノロウィルスが蔓延したほうがまだまし
新興宗教を妄信している奴と同じぐらい使えない
オブジェクト指向が流行したらこの世の地獄だな
ノロウィルスが蔓延したほうがまだまし
>>668
俺は>>665ではないが、
少なくとも、俺ら（一応プロ）はプロでないクライアントより、
プログラムのことはよく知っている必要があり、クライアントの
言い分に全部従わなければならない存在ではないと思うぞ。
俺は>>665ではないが、
少なくとも、俺ら（一応プロ）はプロでないクライアントより、
プログラムのことはよく知っている必要があり、クライアントの
言い分に全部従わなければならない存在ではないと思うぞ。
>>686
アンチ厨はＯＯ厨以上に痛い。
アンチ厨はＯＯ厨以上に痛い。
>>688
うん。俺はそうは思わないってこと。
うん。俺はそうは思わないってこと。
>>657
だから、いい事言った！
皆、自分が無意味な存在である事を認めたくないんだね！
更に、害悪がある存在と認めることは絶対に出来ないんだね！
だけど、人間は存在に意味があるから生まれてきたんじゃないんだよ！
生まれてきてから、存在意義を見つけるのが人生なんだ！
ここに存在意義を見つけれなければ、別を探せばいいだけなんだ！
存在意義が見つけれないのに居座るのはよせ！ 邪魔だから！
俺らが死ぬ！
だから、いい事言った！
皆、自分が無意味な存在である事を認めたくないんだね！
更に、害悪がある存在と認めることは絶対に出来ないんだね！
だけど、人間は存在に意味があるから生まれてきたんじゃないんだよ！
生まれてきてから、存在意義を見つけるのが人生なんだ！
ここに存在意義を見つけれなければ、別を探せばいいだけなんだ！
存在意義が見つけれないのに居座るのはよせ！ 邪魔だから！
俺らが死ぬ！
もう寝ろっ
>684
妄想乙
極端な話、
糞まずい料理店で
ほのぼのと糞まずい料理創るのと
厳しい店で扱かれたり
時には罵声を浴びせられながらも
美味い料理創る事の喜びは意味が違うんだよ。
別に楽しいとかの話ではなくて。
要するに人それぞれなんだよ。ゆとり君w
妄想乙
極端な話、
糞まずい料理店で
ほのぼのと糞まずい料理創るのと
厳しい店で扱かれたり
時には罵声を浴びせられながらも
美味い料理創る事の喜びは意味が違うんだよ。
別に楽しいとかの話ではなくて。
要するに人それぞれなんだよ。ゆとり君w
プログラムの制御は順構造、分岐構造、繰り返し構造のみで表現可能だが、それしか使わないのは間違っている
オブジェクトで全てを表現可能だが、それしか使わないのは間違っている
デスマーチは設計技術の向上で解決できると思っているなら見当違いだ
そして、オブジェクト指向ができることは設計技術の向上とはなんら関係ない
オナニーをしたいな業務でやるな。自分一人のプロジェクトで思う存分するがいい
オブジェクトで全てを表現可能だが、それしか使わないのは間違っている
デスマーチは設計技術の向上で解決できると思っているなら見当違いだ
そして、オブジェクト指向ができることは設計技術の向上とはなんら関係ない
オナニーをしたいな業務でやるな。自分一人のプロジェクトで思う存分するがいい
>>694
じゃあさ、設計技術の向上は何の役に立つの？
それと、設計技術の向上のためにはどうすべきなの？
俺はもちろん設計技術の向上は開発の効率化に寄与すると思ってるし、
オブジェクト指向関連の技術の習熟は設計技術の向上に寄与すると思ってるよ。
じゃあさ、設計技術の向上は何の役に立つの？
それと、設計技術の向上のためにはどうすべきなの？
俺はもちろん設計技術の向上は開発の効率化に寄与すると思ってるし、
オブジェクト指向関連の技術の習熟は設計技術の向上に寄与すると思ってるよ。
別にOOを否定するわけじゃないが、むしろ使ってるけど
最終的にはユーザから評価されないと
どんなにすばらしい設計をしてもダメなんだけどな
最終的にはユーザから評価されないと
どんなにすばらしい設計をしてもダメなんだけどな
>694
OO信者のつもりはないが
お前痛すぎw
OOはオナニーだ
の様なスレを建てて
一度ぼろ糞に言われて来る事を勧めるw
OO信者のつもりはないが
お前痛すぎw
OOはオナニーだ
の様なスレを建てて
一度ぼろ糞に言われて来る事を勧めるw
主張だけで根拠の説明がない説得力に欠ける文章だね。北○○の主張に似ている。
>>696
そんなレイヤの違うことをいっしょくたに論じることに何の意味があるの？
そんなレイヤの違うことをいっしょくたに論じることに何の意味があるの？
ユーザのありがとうという感謝の言葉に、あぁ辛くてもがんばってやってよかった。と思います。
って、よく会社の採用案内のホームページに「先輩からの一言」とかに書いてあるじゃん。
そうことか？ そういうことでエクスタシーを感じるということか？ つまりマゾか？
って、よく会社の採用案内のホームページに「先輩からの一言」とかに書いてあるじゃん。
そうことか？ そういうことでエクスタシーを感じるということか？ つまりマゾか？
>>695
> 設計技術の向上は何の役に立つの？
メンテの容易さと、同じスキルを持っている奴との意思疎通がしやすくなる
問題は「同じスキルを持っている奴」以外との意思疎通が難しくなる可能性がある
素人に技術用語を連発しても敬遠されるだけのように
オブジェクト指向を知らない奴にオブジェクト指向でしか通じない用語を話されても敬遠される
全世界がオブジェクト指向を知れば問題ないと言うならば
何故エスペラント語が流行しなかったのかを知る必要があるだろう
> 設計技術の向上は何の役に立つの？
メンテの容易さと、同じスキルを持っている奴との意思疎通がしやすくなる
問題は「同じスキルを持っている奴」以外との意思疎通が難しくなる可能性がある
素人に技術用語を連発しても敬遠されるだけのように
オブジェクト指向を知らない奴にオブジェクト指向でしか通じない用語を話されても敬遠される
全世界がオブジェクト指向を知れば問題ないと言うならば
何故エスペラント語が流行しなかったのかを知る必要があるだろう
>698
低能にもわかる様に
わかる方法を書いてるだろうがw
お前の大好きな北〇〇とやらより
自分が低能な事にも気付かないんだな。
どうせ低能なんだから
まずやってみろw
低能にもわかる様に
わかる方法を書いてるだろうがw
お前の大好きな北〇〇とやらより
自分が低能な事にも気付かないんだな。
どうせ低能なんだから
まずやってみろw
根拠すらなく感情丸出しのレスとかも北朝鮮とか、被差別部落とか知能障害者に似ているね
ごめん俺>>694向けだった。勘違いさせちゃったかな。まいいか。。。
>700
お前、もういいよw
人として馬鹿すぎて話にならない。
お前はサッカー観て
球蹴って走り回って疲れて馬鹿と考えるか？
まず社会経験積むなりして
常識を覚えて来いよ。
話はそれからだw
お前、もういいよw
人として馬鹿すぎて話にならない。
お前はサッカー観て
球蹴って走り回って疲れて馬鹿と考えるか？
まず社会経験積むなりして
常識を覚えて来いよ。
話はそれからだw
>>701
あんた自身は設計技術の向上はすべきと思ってるの？不要と思ってるの？
はっきりいって開発効率の向上は、「即ち」雑魚の切捨てに他ならないんだから
>問題は「同じスキルを持っている奴」以外との意思疎通が難しくなる可能性がある
は別に問題にならないんじゃないかと考えるけど。
逆にいえば、雑魚といくら意思疎通できたからといってたいして足しにならないってこと。
あんた自身は設計技術の向上はすべきと思ってるの？不要と思ってるの？
はっきりいって開発効率の向上は、「即ち」雑魚の切捨てに他ならないんだから
>問題は「同じスキルを持っている奴」以外との意思疎通が難しくなる可能性がある
は別に問題にならないんじゃないかと考えるけど。
逆にいえば、雑魚といくら意思疎通できたからといってたいして足しにならないってこと。
>698
失礼、勘違いしました。
失礼、勘違いしました。
あ、ついでに俺。>>700でもある。本当に申し訳ない。
素朴な疑問。
オブジェクト指向プログラミングって便利じゃね？
オブジェクト指向プログラミングって便利じゃね？
>>707
> あんた自身は設計技術の向上はすべきと思ってるの？不要と思ってるの？
設計技術の向上は必要だが、それはオブジェクト設計を学ぶこととは限らないと思っている
オブジェクト設計で満足してしまい、更なる研鑽を行えない人間にはなりたくない
また、開発効率の向上は設計技術の向上だけでは達成できないし、
開発効率の向上だけでは多分行き詰る
個人的には自分のランクと同じ人間としか円滑な意思疎通ができることよりも
雑魚≒クライアントと意思疎通できる方が優先順位が高いと思っている
> あんた自身は設計技術の向上はすべきと思ってるの？不要と思ってるの？
設計技術の向上は必要だが、それはオブジェクト設計を学ぶこととは限らないと思っている
オブジェクト設計で満足してしまい、更なる研鑽を行えない人間にはなりたくない
また、開発効率の向上は設計技術の向上だけでは達成できないし、
開発効率の向上だけでは多分行き詰る
個人的には自分のランクと同じ人間としか円滑な意思疎通ができることよりも
雑魚≒クライアントと意思疎通できる方が優先順位が高いと思っている
>>710
その「オブジェクト指向プログラミング」が、どういう定義なのか
自分なりに説明できるのかい？
君が便利だと思う(オブジェクト指向プログラミングだと思っている)ものは
メッセージングなのかクラス志向なのかインターフェースなのか？
前スレでストラウストラップやクックの論議してた人達がいるけど
万人がOOプログラミングはこれだ！っていう結論は出てないよな？
君が言ってるのは（たぶん）「クラス志向プログラミングって便利じゃね？」
って話で「オブジェクト指向プログラミングは便利」とは違う。
OOPが便利と感じるのは俺も同じだが、そう感じてるSEやPGの中には相当温度差が
あるよな。プログラミングレベルでこうなんだから、設計からコーディングまで
意志統一するなんて難しい話だ。
その「オブジェクト指向プログラミング」が、どういう定義なのか
自分なりに説明できるのかい？
君が便利だと思う(オブジェクト指向プログラミングだと思っている)ものは
メッセージングなのかクラス志向なのかインターフェースなのか？
前スレでストラウストラップやクックの論議してた人達がいるけど
万人がOOプログラミングはこれだ！っていう結論は出てないよな？
君が言ってるのは（たぶん）「クラス志向プログラミングって便利じゃね？」
って話で「オブジェクト指向プログラミングは便利」とは違う。
OOPが便利と感じるのは俺も同じだが、そう感じてるSEやPGの中には相当温度差が
あるよな。プログラミングレベルでこうなんだから、設計からコーディングまで
意志統一するなんて難しい話だ。
このスレ見てると、
数学ができない人間に、
数学の大切さをわからせるのは無理と同じ次元を感じた。
数学ができない人間に、
数学の大切さをわからせるのは無理と同じ次元を感じた。
長文語る人間も横文字の長ったらしい用語をなるべく使わない工夫をしようぜ。
突っ込まれたらどうせ自分だって説明できないだろ？
このスレ、日本の悪しき教育文化をそのままもってきたようなの多いしな。
教科書丸暗記したもののそれがなにかわからないっていうｗ
穴埋め問題はできるけど、その実内容はまったく理解してない奴みたい。
突っ込まれたらどうせ自分だって説明できないだろ？
このスレ、日本の悪しき教育文化をそのままもってきたようなの多いしな。
教科書丸暗記したもののそれがなにかわからないっていうｗ
穴埋め問題はできるけど、その実内容はまったく理解してない奴みたい。
横文字苦手って明治生まれの爺かよ。
爺は、N88Basicでも組んでな。
爺は、N88Basicでも組んでな。
>>715
その横文字がよ。
他に置き換えようがないぐらいみんなの認識が一致してるもんなら
別にかまやしないんだけどさ。
明らかに、みんながみんなそれぞれ別の書籍の別のもんみて
全然違う意味にとらえてることが多い。
しかも、大抵そういう言葉使ってレスする奴って自分の意見を最後まで確定させないで
いつでも変化つけて誤魔化せるようにしてて卑怯なレスが多い。
その横文字がよ。
他に置き換えようがないぐらいみんなの認識が一致してるもんなら
別にかまやしないんだけどさ。
明らかに、みんながみんなそれぞれ別の書籍の別のもんみて
全然違う意味にとらえてることが多い。
しかも、大抵そういう言葉使ってレスする奴って自分の意見を最後まで確定させないで
いつでも変化つけて誤魔化せるようにしてて卑怯なレスが多い。
オブジェクト指向が流行らないのは、まだブームの時期だから。
浸透してないってこと。
業界内の意識があってるのは、
言語に依存してるものだけ。
クラス、ポリモーフィズム、継承あたりは「言語規約」があるから統一感があるけど、
型にはまる規約が無いフェーズになると破綻してる。
浸透してないってこと。
業界内の意識があってるのは、
言語に依存してるものだけ。
クラス、ポリモーフィズム、継承あたりは「言語規約」があるから統一感があるけど、
型にはまる規約が無いフェーズになると破綻してる。
>>711
あんたのいいたいことがさっぱりわからん。設計技術の向上は必要だが、オブジェクト指向は必要ないってことか？
そしてオブジェクト指向を学ぶと他人とのコミュニケーションがむずかしくなって、他の技術を学ぶとそうはならない
ってことか？
大体、クライアントと意思疎通する技術と開発者同士で意思疎通する技術との間に何か関係があるかな。
俺は無いと思うけど。
あんたのいいたいことがさっぱりわからん。設計技術の向上は必要だが、オブジェクト指向は必要ないってことか？
そしてオブジェクト指向を学ぶと他人とのコミュニケーションがむずかしくなって、他の技術を学ぶとそうはならない
ってことか？
大体、クライアントと意思疎通する技術と開発者同士で意思疎通する技術との間に何か関係があるかな。
俺は無いと思うけど。
豚どもと意思疎通するのは大変だということだよ。
俺は無力感を感じることがしょっちゅうだ。
オープンソースの優れたプロジェクトではそういう豚どものコアへの参加を徹底
的に排除しているな。開発プロジェクトを成功させるためには優れた技術者
だけでスタッフを構成することかベストだという認識はあちらの世界では既に常
識になっている。いくらがんばっても豚に日本語はしゃべらせられないのだ。
俺は無力感を感じることがしょっちゅうだ。
オープンソースの優れたプロジェクトではそういう豚どものコアへの参加を徹底
的に排除しているな。開発プロジェクトを成功させるためには優れた技術者
だけでスタッフを構成することかベストだという認識はあちらの世界では既に常
識になっている。いくらがんばっても豚に日本語はしゃべらせられないのだ。
まぁ構造化がきちんとできてOOPが理解できない人には
メソッド内をコーディングしてもらえば良いのだが問題は、
結局、構造化が出来てる人はOOPも出来るから、
そんな人材はいないって事だよな。
メソッド内をコーディングしてもらえば良いのだが問題は、
結局、構造化が出来てる人はOOPも出来るから、
そんな人材はいないって事だよな。
このスレ自体がデスマ
>>722
構造化が出来てる人はOOPも出来る ってのは飛躍しすぎだと思うぞ。
今時、構造化にならないソース書く方が困難だと思うぞ。その質はともかく。
ＯＯＰ出来ない奴は、「順次実行」、「繰り返し」、「条件分岐」は書けても、
それ以外の何かが欠けているんだよな。センス的な何かが。物事を抽象化して
整理する能力か。ＯＯＰってプログラミングの技術というより、寧ろ問題を整
理する能力だと思う。だからコーディング量は逆に増える場合もあるけど、冗
長性が排除される。ロジックが局所化され、適材適所に配置分散され、また階
層化される。そういった本質とか目的が理解できていない奴が多すぎると思う。
構造化が出来てる人はOOPも出来る ってのは飛躍しすぎだと思うぞ。
今時、構造化にならないソース書く方が困難だと思うぞ。その質はともかく。
ＯＯＰ出来ない奴は、「順次実行」、「繰り返し」、「条件分岐」は書けても、
それ以外の何かが欠けているんだよな。センス的な何かが。物事を抽象化して
整理する能力か。ＯＯＰってプログラミングの技術というより、寧ろ問題を整
理する能力だと思う。だからコーディング量は逆に増える場合もあるけど、冗
長性が排除される。ロジックが局所化され、適材適所に配置分散され、また階
層化される。そういった本質とか目的が理解できていない奴が多すぎると思う。
725 ：仕様書無しさん：2007/02/17(土) 14:03:08
>>724
質が大問題だと思うが。
構造化をその程度と捉えるってのは、Classって書けばOOPってのと同じ程度のことを言ってる。
つうか、いつもながらすぐOOPになるんだよねこのすれ。
設計なのに。ミクロな話でしか語れない人が引き込む。
質が大問題だと思うが。
構造化をその程度と捉えるってのは、Classって書けばOOPってのと同じ程度のことを言ってる。
つうか、いつもながらすぐOOPになるんだよねこのすれ。
設計なのに。ミクロな話でしか語れない人が引き込む。
構造化できちんと機能分割するのと、
OOPでクラスを抽出するのは、
目的と方法は、おおよそ同じことやっていると思うぞ。
OOPのが後発の分ちょっとばかり高機能に過ぎないだけだ。
OOPでクラスを抽出するのは、
目的と方法は、おおよそ同じことやっていると思うぞ。
OOPのが後発の分ちょっとばかり高機能に過ぎないだけだ。
OOPでの問題はそれだけじゃないと思う。
百科事典的にたくさんあるクラスの海の中で結構な物知り博士になってる
必要があるのでは？あれこれやりたいことがあっても実現までの準備が
相当大変になることもあるとか。
百科事典的にたくさんあるクラスの海の中で結構な物知り博士になってる
必要があるのでは？あれこれやりたいことがあっても実現までの準備が
相当大変になることもあるとか。
クラスの海 orz...
>>720
言ってないじゃん
言ってないじゃん
構造化設計ではおのおののデータの関連性についてうまく表現するやりかたが
ないことが原因で、システム全体に「本質的に相関関係にあるデータ」が分散管理
されてしまう。
ないことが原因で、システム全体に「本質的に相関関係にあるデータ」が分散管理
されてしまう。
731 ：仕様書無しさん：2007/02/17(土) 15:11:38
ANSI Cでも構造化+データとの連携管理はできる。クラスという概念はないが
クラスの代わりに.cファイル単位でならね。それが出来ないと言う>>730はスキルがないだけ。
そんなことも知らずに設計を語れるはずがない。
クラスの代わりに.cファイル単位でならね。それが出来ないと言う>>730はスキルがないだけ。
そんなことも知らずに設計を語れるはずがない。
>>731
構造化設計で一定のスキルがあるからこそ、データの相関をうまく取り扱うことが
如何に重要であるか、ひいてはオブジェクト指向をシステム開発に
どのように役立たせることができるかが理解できる、と思う。
構造化設計で一定のスキルがあるからこそ、データの相関をうまく取り扱うことが
如何に重要であるか、ひいてはオブジェクト指向をシステム開発に
どのように役立たせることができるかが理解できる、と思う。
734 ：仕様書無しさん：2007/02/17(土) 15:31:35
なんかすごいややこしくてわかんなくなってきた。
例えばさ、VB6とかで共通処理をまとめてpublicでモジュールとかにするじゃない。
んでCSVの取り込みデータとか、よく使うデータのかたまりを
sub Mainモジュールの頭にpublicで構造体にするとするじゃない。
これって「構造化プログラミング」、だよね？？
例えばさ、VB6とかで共通処理をまとめてpublicでモジュールとかにするじゃない。
んでCSVの取り込みデータとか、よく使うデータのかたまりを
sub Mainモジュールの頭にpublicで構造体にするとするじゃない。
これって「構造化プログラミング」、だよね？？
735 ：仕様書無しさん：2007/02/17(土) 15:39:25
馬鹿共
publicで公開するのは素人だ
publicで公開するのは素人だ
736 ：仕様書無しさん：2007/02/17(土) 15:40:41
>>733は頭がよさそうだな。次世代のOO設計をリードしてくれ。期待するよ。
737 ：仕様書無しさん：2007/02/17(土) 15:42:09
>>732はジャワ糞だな
protectedな内部クラスの使い方がいまいち理解できない。
誰か教えてエロっぽい人。
誰か教えてエロっぽい人。
>>737
きょうび、プログラマが任意でメモリ破壊させることができる言語の方が少ないだろ。
きょうび、プログラマが任意でメモリ破壊させることができる言語の方が少ないだろ。
>>738
ストラテジパターンとか。
ストラテジパターンとか。
>>736
オブジェクト指向の初歩の初歩なわけだが。。
オブジェクト指向の初歩の初歩なわけだが。。
protectedな内部クラスのスコープの意味と使いかたがよく分かんねぇだよ。
メリットデメリット含めて誰か懇切丁寧に具体例を交えて教えてください。
ここにはびこる評論家もどきのエロっぽい人。
メリットデメリット含めて誰か懇切丁寧に具体例を交えて教えてください。
ここにはびこる評論家もどきのエロっぽい人。
あー、言語はJavaでございます。一応。
>>742
private/publicの内部クラスのスコープの意味と使い方はわかるのか？
protectedスコープのprivate/publicスコープに対するメリット・デメリットはわかるのか？
こいつらがわかれば自ずとわかるだろ。
private/publicの内部クラスのスコープの意味と使い方はわかるのか？
protectedスコープのprivate/publicスコープに対するメリット・デメリットはわかるのか？
こいつらがわかれば自ずとわかるだろ。
>>742
ここに山ほどサンプルあるから、自分で研究しろ。
http://www.google.com/codesearch?hl=ja&lr=&q=lang%3Ajava+%22protected+class%22
ここに山ほどサンプルあるから、自分で研究しろ。
http://www.google.com/codesearch?hl=ja&lr=&q=lang%3Ajava+%22protected+class%22
>>744
えーと、
おおざっぱにいうと、public にする他のクラス含めてどっからでもアクセスできる。
private だと自分と外部クラスからしかアクセスできないって感じでしょうか？
protected は「外部クラス、サブクラス及び同パッケージの他クラスからのみ使用する
ことができる。」ってかいてあるんですけど、public との違いがよくわからないので
あります。
えーと、
おおざっぱにいうと、public にする他のクラス含めてどっからでもアクセスできる。
private だと自分と外部クラスからしかアクセスできないって感じでしょうか？
protected は「外部クラス、サブクラス及び同パッケージの他クラスからのみ使用する
ことができる。」ってかいてあるんですけど、public との違いがよくわからないので
あります。
あー、今理解しました。ありがとうございました。よく見たら書いて
あるそのままですね。失礼しました。
あるそのままですね。失礼しました。
非オブジェクトはプロシージャとデータをセットで管理できないです
例えば住所管理プログラムを考えると（データベースは使用しないとして）
住所データに対して
登録、削除、変更等の機能が必要だと思います
住所データ、登録プロシージャ、削除プロシージャ、変更プロシージャという風に作っていくと思います
これが、会社の業務システムの一部の社員名簿管理サブシステムとすると
他にも給与データ、勤怠データとか沢山のデータを扱う事になります
データとそれを扱うプロシージャがばらばらなのでメンテナンスが大変になります
似たような機能の関数を知らずに新たに作ってしまったり
給与プロシージャが勝手に名簿データを書き換えてみたり
ちょっと機能を変えたいときにはお得意のコピペでプロシージャを増やしてみたり
秘密のプロシージャがあったりと、まさにカオスです
オブジェクト指向はこういう問題が生じないように工夫されています
構造化プログラミングとは全然違います
大規模システムを作る際には非常に便利です
小さなプログラムでは特に必要ないかも知れません
例えば住所管理プログラムを考えると（データベースは使用しないとして）
住所データに対して
登録、削除、変更等の機能が必要だと思います
住所データ、登録プロシージャ、削除プロシージャ、変更プロシージャという風に作っていくと思います
これが、会社の業務システムの一部の社員名簿管理サブシステムとすると
他にも給与データ、勤怠データとか沢山のデータを扱う事になります
データとそれを扱うプロシージャがばらばらなのでメンテナンスが大変になります
似たような機能の関数を知らずに新たに作ってしまったり
給与プロシージャが勝手に名簿データを書き換えてみたり
ちょっと機能を変えたいときにはお得意のコピペでプロシージャを増やしてみたり
秘密のプロシージャがあったりと、まさにカオスです
オブジェクト指向はこういう問題が生じないように工夫されています
構造化プログラミングとは全然違います
大規模システムを作る際には非常に便利です
小さなプログラムでは特に必要ないかも知れません
749 ：仕様書無しさん：2007/02/17(土) 18:04:24
構造化設計とOO設計のいいとこ取りをすればいいんじゃね？
750 ：仕様書無しさん：2007/02/17(土) 18:07:41
>>748←こいつのいうようなのってそもそもオブジェクト指向ですらないような気がするんだが、
最近のはこういうのが流行ってるの？
最近のはこういうのが流行ってるの？
>>750
オブジェクト指向じゃない例じゃないのか？
オブジェクト指向じゃない例じゃないのか？
752 ：仕様書無しさん：2007/02/17(土) 18:14:00
>データベースは使用しないとして
前提に無理があるｗ
前提に無理があるｗ
753 ：仕様書無しさん：2007/02/17(土) 18:16:58
構造化とオブジェクト指向が反するもののようにいうのはどういうことなの？
俺、同時にできると思うぜ。
俺、同時にできると思うぜ。
あ、すまんかった。
>>748
データベースを使う場合は構造化プログラミングで我慢しろとでも？そんなの嫌です。
データベースを使う場合は構造化プログラミングで我慢しろとでも？そんなの嫌です。
学習量の差がこのスレ住人の差だなあ。
スレタイは「設計」とある。
プログラミングじゃねーつの。
スレタイは「設計」とある。
プログラミングじゃねーつの。
>>748
>例えば住所管理プログラムを考えると（データベースは使用しないとして）
オブジェクト設計ネタだとデータベースの話は避けるもんなの？
世の中のオブジェクト設計案件ってそういうのが大半なの？
「人間が一人だけだったら戦争は無くなる」ってのと同類のアホらしさを感じるのだけど。
>例えば住所管理プログラムを考えると（データベースは使用しないとして）
オブジェクト設計ネタだとデータベースの話は避けるもんなの？
世の中のオブジェクト設計案件ってそういうのが大半なの？
「人間が一人だけだったら戦争は無くなる」ってのと同類のアホらしさを感じるのだけど。
>>762
どのあたりのレスがプログラミングに特化した話なのかおしえてくれや。
どのあたりのレスがプログラミングに特化した話なのかおしえてくれや。
まぁまぁ、お前らこれでも見てもちつけ。
つ（景勝、ポルノグラフィ、カプセルホテル）
つ（景勝、ポルノグラフィ、カプセルホテル）
771 ：仕様書無しさん：2007/02/17(土) 19:12:30
UMLが流行らないって話？
>>769
それはね、坊や、ＯＯＰを理解できない人が多いからだよ。
それはね、坊や、ＯＯＰを理解できない人が多いからだよ。
流行ってないって前提がおかしい
すでにほとんどの企業はオブジェクト指向設計を取り入れている。
すでにほとんどの企業はオブジェクト指向設計を取り入れている。
776 ：仕様書無しさん：2007/02/17(土) 19:23:28
プログラミング出来ない人が設計出来ないように
OOP出来ない人も、オブジェクト指向設計が出来ないと
OOP出来ない人も、オブジェクト指向設計が出来ないと
780 ：仕様書無しさん：2007/02/17(土) 19:28:37
じゃないよ、能無しをコントールする仕組みでデザインされたOO(P)(D)
はほっとくとろくなもんしかアウトプットできない>>777をドカタとして囲い込むための仕組みだからさ。
はほっとくとろくなもんしかアウトプットできない>>777をドカタとして囲い込むための仕組みだからさ。
とりあえず派遣で渡り歩いてる俺の見た環境の多くは
無い環境は全く無い。
有る環境（と思われる）は活きてない。
のがほとんどだったな。
まあ、プロジェクトの成功失敗を決めてるのはオブジェクト指向云々じゃないな。
昔ながらの組み方全開の人もオブジェクト指向がどうのこうのいいながら組んでる人も
共存してても別に問題あるわけじゃないし。
無い環境は全く無い。
有る環境（と思われる）は活きてない。
のがほとんどだったな。
まあ、プロジェクトの成功失敗を決めてるのはオブジェクト指向云々じゃないな。
昔ながらの組み方全開の人もオブジェクト指向がどうのこうのいいながら組んでる人も
共存してても別に問題あるわけじゃないし。
オブジェクト指向という「考え方」の存在は浸透してるが、
どの現場でも完全には使いこなせていないということだな。
どの現場でも完全には使いこなせていないということだな。
>>781は実際そうなんだと思うけど、どうなんだろ。
ゴミを予算内・スケジュール内で組んだとしてそれでプロジェクト成功だなんて
いうのであれば別だけど、オブジェクト指向含むいろんな新しい方法論を
学習したり実践したりするタイプの人間以外がゴミ以外生産できると思えないし、
またいろんな開発方法を会得した人間があえて旧来方式での開発を選択するとも思えない。
ゴミを予算内・スケジュール内で組んだとしてそれでプロジェクト成功だなんて
いうのであれば別だけど、オブジェクト指向含むいろんな新しい方法論を
学習したり実践したりするタイプの人間以外がゴミ以外生産できると思えないし、
またいろんな開発方法を会得した人間があえて旧来方式での開発を選択するとも思えない。
まず、従来のやり方と共存できるってことをアピールすることから始めてみてはどうだろうか？
>>784
残念ながら、共存は難しい
残念ながら、共存は難しい
>>785
むしろオブジェクト指向の一番の利点だと思うんだけどな。
クラス内で完結してるもんが多いんだし、使用例サンプル通りにクラス・メソッド呼んでくれるだけで動くもんがほとんどじゃん。
フレームワークを構成するような作りになってたらなんのためのオブジェクト指向なんだよｗって思わないでもないがｗ
むしろオブジェクト指向の一番の利点だと思うんだけどな。
クラス内で完結してるもんが多いんだし、使用例サンプル通りにクラス・メソッド呼んでくれるだけで動くもんがほとんどじゃん。
フレームワークを構成するような作りになってたらなんのためのオブジェクト指向なんだよｗって思わないでもないがｗ
オブジェクト指向には、インターフェイスで受け渡される値さえ正しければ
中身は、どうでも良いと言う思想があるから、共存は出来ると思うよ。
中身は、どうでも良いと言う思想があるから、共存は出来ると思うよ。
そろそろだらだら書き込みするだけじゃなくて
このスレで得られた成果を発表したらどうだね。
このスレで得られた成果を発表したらどうだね。
>>788
「まずは従来の方法との共存を」
「まずは従来の方法との共存を」
勉強したり実践したりしたこともないものに対してアンチになる奴って一体なんなの？
>>790
レイプされたこともないのにレイプ犯非難するなとかそういうアフォな議論したいのか？
レイプされたこともないのにレイプ犯非難するなとかそういうアフォな議論したいのか？
>>791
全然構造が違うだろ、アホか。
全然構造が違うだろ、アホか。
かれらは、老人なので新しい物は、
役に立つ立たないにかかわらず、
すべて嫌いなのです。
役に立つ立たないにかかわらず、
すべて嫌いなのです。
>>792
それを確かめるためにちょっといってくる。
それを確かめるためにちょっといってくる。
>793
違うな。
老人は過去に効果的と思われた方法を使って
一定の成果を上げたんだろう。
その経験から自分の方法に盲信してるんだと思う。
もちろん、優秀な技術者はそうはならないがな。
問題は老人を盲信から覚めさせる事は
ほとんど不可能な程に難しいって事だな…
違うな。
老人は過去に効果的と思われた方法を使って
一定の成果を上げたんだろう。
その経験から自分の方法に盲信してるんだと思う。
もちろん、優秀な技術者はそうはならないがな。
問題は老人を盲信から覚めさせる事は
ほとんど不可能な程に難しいって事だな…
ラクをするための考え方のはずが、
その存在のために苦しむ人間が多いオブジェクト指向。
偽装請負による現場のカオス化が無くならない限り、
一般的な開発案件は振り回され続けるんだろうな。
その存在のために苦しむ人間が多いオブジェクト指向。
偽装請負による現場のカオス化が無くならない限り、
一般的な開発案件は振り回され続けるんだろうな。
797 ：仕様書無しさん：2007/02/18(日) 00:58:43
ざっと見たけどお前ら本当にオブジェクト指向をなーんもわかってないのな。
抽象データ型とか全然しらねーだろ？
抽象データ型とか全然しらねーだろ？
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
>>797
説明して。
説明して。
またオブジェクト指向対抽象データ型かよ。
なんつか、実学ベースの話したいんだけど。
なんつか、実学ベースの話したいんだけど。
>>800
していいよ。してっ。
していいよ。してっ。
>>800
どういう話になんの？
どういう話になんの？
+ +
∧＿∧ ∩ +
（0ﾟ´∀`)彡 <<800 wktk!wktk!
（0ﾟ∪⊂彡 +
と＿_）__） +
∧＿∧ ∩ +
（0ﾟ´∀`)彡 <<800 wktk!wktk!
（0ﾟ∪⊂彡 +
と＿_）__） +
☆ ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ～
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 実学ベースの話しまだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| 愛媛みかん |／
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 実学ベースの話しまだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| 愛媛みかん |／
805 ：仕様書無しさん：2007/02/18(日) 02:13:40
∧ ∧ ┌────────
( ´ー｀) ＜ シラネーヨ
＼ < └───/|────
＼.＼＿＿＿＿__／/
＼ ／
∪∪￣∪∪
( ´ー｀) ＜ シラネーヨ
＼ < └───/|────
＼.＼＿＿＿＿__／/
＼ ／
∪∪￣∪∪
ただいま>>797がGoogle検索中です。
しばらくお待ちください。
しばらくお待ちください。
オブジェクト設計ってオブジェクト指向を使った設計のことですか？
ＵＭＬとかデザパタとかの話でしょうか？
設計ってどのレベルまで細かく明記するんですか？
各クラスのメソッドとかプロパティは全て網羅するんでしょうか？
設計時点で定義されるから、プログラマはプライベートな変数とかメソッドとか
も別に考える必要はないんですか？実装のためのローカル変数ぐらいですか？
一般的にどうなんでしょう？設計者と実装者の役割のボーダーはどのレベル
でひかれるんでしょうか？ＵＭＬで図を描くのが設計者で、そのテンプレートを
もとに実装するのがプログラマなんでしょうか？ だとしたらプログラマはとりあえ
ず構造化プログラミングができればなんとかなるんでしょうか？
実際の現場ではどうなんでしょうか？
よろしければ教えてください。
ＵＭＬとかデザパタとかの話でしょうか？
設計ってどのレベルまで細かく明記するんですか？
各クラスのメソッドとかプロパティは全て網羅するんでしょうか？
設計時点で定義されるから、プログラマはプライベートな変数とかメソッドとか
も別に考える必要はないんですか？実装のためのローカル変数ぐらいですか？
一般的にどうなんでしょう？設計者と実装者の役割のボーダーはどのレベル
でひかれるんでしょうか？ＵＭＬで図を描くのが設計者で、そのテンプレートを
もとに実装するのがプログラマなんでしょうか？ だとしたらプログラマはとりあえ
ず構造化プログラミングができればなんとかなるんでしょうか？
実際の現場ではどうなんでしょうか？
よろしければ教えてください。
嫌
嫌++
>>807
よくよんだら結構実のある質問だけど羅列したところがアホだな。
よくよんだら結構実のある質問だけど羅列したところがアホだな。
嫌#
>>データベースは使用しないとして
説明がめんどくさくなるから
設計とコーディングを切り離す云々て話だけど
最近の言語はコーディングも昔ほど手間がかからなくなてきたせいか
設計からコーディングまで同じ人がやるよ
これがオブジェクト指向の恩恵だと思う
オブジェクト指向が流行らないのは
上層部が、オブジェクト思考から最も遠いコボル経験ばかりだったりするのも
一員だと思う
コボルは構造化すら出来ていないですから
エラー処理でGOTO文書くと怒るし
説明がめんどくさくなるから
設計とコーディングを切り離す云々て話だけど
最近の言語はコーディングも昔ほど手間がかからなくなてきたせいか
設計からコーディングまで同じ人がやるよ
これがオブジェクト指向の恩恵だと思う
オブジェクト指向が流行らないのは
上層部が、オブジェクト思考から最も遠いコボル経験ばかりだったりするのも
一員だと思う
コボルは構造化すら出来ていないですから
エラー処理でGOTO文書くと怒るし
「上流・下流は分業しない。同じ人間がやる」は、間違い
普通は分業する。たまに要員確保の問題で同じ人がやる事もあるけど。
普通は分業する。たまに要員確保の問題で同じ人がやる事もあるけど。
実学ベースの話っていう言い方が悪かったかも知らんが
オブジェクト指向の起源とかそういう話じゃなくて、
しょうもないことでもいいから仕事に役立つ話聞きたい。
オブジェクト指向の起源とかそういう話じゃなくて、
しょうもないことでもいいから仕事に役立つ話聞きたい。
>>819
無理っしょ。
分業なんかしたら、スパイラルはできないよ。
期間的な問題で無理。
設計から開発にまわして、もう一度設計に渡して開発に・・・ってこれが
別のチームじゃ情報の伝達だけで開発終わっちゃうよ。
仕組み的にできるできないの話じゃなくて時間的に絶対に無理。
無理っしょ。
分業なんかしたら、スパイラルはできないよ。
期間的な問題で無理。
設計から開発にまわして、もう一度設計に渡して開発に・・・ってこれが
別のチームじゃ情報の伝達だけで開発終わっちゃうよ。
仕組み的にできるできないの話じゃなくて時間的に絶対に無理。
>>819
完全にアーキテクチャフリーなモデルをつくれればいいんだけど、
現実は「XXという実装が可能であれば」「XXという設計モデルにしたい」ってなる。
要は、部分部分で実装・検証繰り返しながらじゃないとまともな設計にならん。
完全にアーキテクチャフリーなモデルをつくれればいいんだけど、
現実は「XXという実装が可能であれば」「XXという設計モデルにしたい」ってなる。
要は、部分部分で実装・検証繰り返しながらじゃないとまともな設計にならん。
>SEは、プログラムが組めんからやらざるえない。
この時点でオブジェクト開発導入無理な希ガス
この時点でオブジェクト開発導入無理な希ガス
>>825
>最近のSEがプログラム組めん実際事実でしょ
事実かも知らんが、正しい有り様とは思えん。
>オブジェクト指向は、抽象化されてるから、
>ある程度、実装を知らなくても設計ができる。
これもおかしい。いろんな実装を知ってるからこそ、
あるひとつの具体的な実装形態にバインドされない
モデルを作成することができると思う。
>最近のSEがプログラム組めん実際事実でしょ
事実かも知らんが、正しい有り様とは思えん。
>オブジェクト指向は、抽象化されてるから、
>ある程度、実装を知らなくても設計ができる。
これもおかしい。いろんな実装を知ってるからこそ、
あるひとつの具体的な実装形態にバインドされない
モデルを作成することができると思う。
>>826
正しいか正しくないかなんていってないよ。
事実を述べたまで、正しいかどうかなら
正しくないだろうね。
でも世の中は正しくない事の方が多いんだよ。
オブジェクト指向設計の上流工程で
言語実装が出てくるのはおかしいと理解できてれば文句は無いよ。
理想を言えばそのとおりだと思う。
正しいか正しくないかなんていってないよ。
事実を述べたまで、正しいかどうかなら
正しくないだろうね。
でも世の中は正しくない事の方が多いんだよ。
オブジェクト指向設計の上流工程で
言語実装が出てくるのはおかしいと理解できてれば文句は無いよ。
理想を言えばそのとおりだと思う。
>>827
スパイラルの話に戻ると、スパイラルは分業できないのは「事実」だと思うんだが。
>言語実装が出てくるのはおかしい
言語実装が出てくるのは「いただけない」けど、設計者が実装方法を一つも答えられないのは「論外」
スパイラルの話に戻ると、スパイラルは分業できないのは「事実」だと思うんだが。
>言語実装が出てくるのはおかしい
言語実装が出てくるのは「いただけない」けど、設計者が実装方法を一つも答えられないのは「論外」
昔はプログラミングも
コーダー、パンチャーという風に細かく分かれてたよ
仕様書だって、書く人とワープロに入力する人と分かれていたんじゃないかな
そういう時代なら分業も随分意味があると思う
いまは面倒な事は全部コンピュータがやってくれるので
あえて分業する必要性がなくなってきていると思う
今行われているのは分業というより分担が主流だと思う
ただ、作る人と営業する人、要求仕様を決める人は普通別だと思う
こういう作り方をしているプロジェクトと
大人数で伝言ゲームごっこがメインのプロジェクトでは
後者のほうが非常にコストがかかるはずなのに
同じ予算でやろうとするから、あちこちに無理が生じて
デスマになってしまうのだと思う
コーダー、パンチャーという風に細かく分かれてたよ
仕様書だって、書く人とワープロに入力する人と分かれていたんじゃないかな
そういう時代なら分業も随分意味があると思う
いまは面倒な事は全部コンピュータがやってくれるので
あえて分業する必要性がなくなってきていると思う
今行われているのは分業というより分担が主流だと思う
ただ、作る人と営業する人、要求仕様を決める人は普通別だと思う
こういう作り方をしているプロジェクトと
大人数で伝言ゲームごっこがメインのプロジェクトでは
後者のほうが非常にコストがかかるはずなのに
同じ予算でやろうとするから、あちこちに無理が生じて
デスマになってしまうのだと思う
>>832
それだよな。
人に成果物を渡すってのが双方にとってどんだけ手間かってのがわかってないよな。
渡すほうも確認するのはもちろんだけど、受け取ったほうもそれを全部確認せにゃならん。
もう、感覚で絶対に不可能ってわかる。
それだよな。
人に成果物を渡すってのが双方にとってどんだけ手間かってのがわかってないよな。
渡すほうも確認するのはもちろんだけど、受け取ったほうもそれを全部確認せにゃならん。
もう、感覚で絶対に不可能ってわかる。
>>832
普通に設計書だな、
主に外部設計書に対して実装、設計者、客がそれぞれに修正案をだす。
って感じだな。当然、その時点のシステムを実際触っての、修正変更も
それぞれのレベルの設計書に盛り込まれる。
普通に設計書だな、
主に外部設計書に対して実装、設計者、客がそれぞれに修正案をだす。
って感じだな。当然、その時点のシステムを実際触っての、修正変更も
それぞれのレベルの設計書に盛り込まれる。
>>835
まさか、詳細設計とかプログラム設計とか別にドキュメントあるんじゃないだろうな。。
まさか、詳細設計とかプログラム設計とか別にドキュメントあるんじゃないだろうな。。
>>836
金も納期も無限にある前提なら
>ウォーターフォールで出来ればスパイラルでも出来る。
は正しいな。
だが、
「ウォーターフォールより金も納期も品質も良くならない」なら
スパイラルを選択する意味はない。
金も納期も無限にある前提なら
>ウォーターフォールで出来ればスパイラルでも出来る。
は正しいな。
だが、
「ウォーターフォールより金も納期も品質も良くならない」なら
スパイラルを選択する意味はない。
>>841
俺の言ってるスパイラルとは、これのスパイラルモデルだけど
ttp://www.ics.kagoshima-u.ac.jp/edu/SoftwareEngineering/process-model.html
俺の言ってるスパイラルとは、これのスパイラルモデルだけど
ttp://www.ics.kagoshima-u.ac.jp/edu/SoftwareEngineering/process-model.html
>>840
なんでだよ。
単純に考えても
(分析→設計→実装→リリース)が1回のウォータフォールに対して、
(分析→設計→実装→リリース)がn回のスパイラルの方が
イテレーションの数だけ「→」が多いんだから稼動面で不利だろ。
なんでだよ。
単純に考えても
(分析→設計→実装→リリース)が1回のウォータフォールに対して、
(分析→設計→実装→リリース)がn回のスパイラルの方が
イテレーションの数だけ「→」が多いんだから稼動面で不利だろ。
アジャイルだったら分析設計実装は毎日やるから、分業なんて無理だな。
そもそもいくつかあるソフトウェア開発プロセスで推奨してる分業は
機能単位であって業務単位じゃねーしな。
ウォーターフォールしか知らない＆他を知ろうともしない奴は分業って固定観念に取り付かれててすげー迷惑だが。
そもそもいくつかあるソフトウェア開発プロセスで推奨してる分業は
機能単位であって業務単位じゃねーしな。
ウォーターフォールしか知らない＆他を知ろうともしない奴は分業って固定観念に取り付かれててすげー迷惑だが。
例えると
ウォータープルーフモデルの適用が最適なのは
プラモデル作成くらいかな？
０からものを作る場合
ウォータープルーフモデルではかなり無理がある
ところで、オブジェクト指向は頭が良くないと出来ないという誤った認識があると思う
要は上層部がオブジェクト指向に対応できなくて
自分達の立場を守るために
オブジェクト指向の否定を展開しているに過ぎないと思う
若い連中はそれに踊らされているだけだと思う
ウォータープルーフモデルの適用が最適なのは
プラモデル作成くらいかな？
０からものを作る場合
ウォータープルーフモデルではかなり無理がある
ところで、オブジェクト指向は頭が良くないと出来ないという誤った認識があると思う
要は上層部がオブジェクト指向に対応できなくて
自分達の立場を守るために
オブジェクト指向の否定を展開しているに過ぎないと思う
若い連中はそれに踊らされているだけだと思う
>>844
http://www.metabolics.co.jp/XP/dX.html
http://www.objectclub.jp/download/files/technicaldoc/rup_xp.pdf
に目をとおして、分業可能性についてもういちど考えてみてくれ。
http://www.metabolics.co.jp/XP/dX.html
http://www.objectclub.jp/download/files/technicaldoc/rup_xp.pdf
に目をとおして、分業可能性についてもういちど考えてみてくれ。
>>848
is-a スパイラルだろ。
is-a スパイラルだろ。
>>848
お前はRUPとかAgileとかは知らんが、純然たるスパイラル開発（そんなものがあるかは知らんが）
では分業は可能だと主張したいのか？
この議論は「オブジェクト指向開発では」っていう前提があるはずだよな？
お前はRUPとかAgileとかは知らんが、純然たるスパイラル開発（そんなものがあるかは知らんが）
では分業は可能だと主張したいのか？
この議論は「オブジェクト指向開発では」っていう前提があるはずだよな？
853 ：仕様書無しさん：2007/02/18(日) 12:44:41
俺が経験してきてるここ最近の開発って、ＳＥと称する連中が
客から要望聞いて、おおざっぱな画面設計とＤＢ設計（なんと
要件が固まりきらないうちにＤＢ設計されてしまう）と、要件が
箇条書きになっているようなもんを基本設計書ですって渡して
きて、これで詳細設計におとしてくださいという。そしてその後、
頻繁に画面ちょっと変わりましたぁ。対応してください～い。とか
言ってくる。こんなんでまともなクラス設計なんてできるわけがない。
そしていざ実装という時点でも、要件が変わるもんだから、画面と
ＤＢ設計書を修正したものを渡してきやがる。本人達はこれが
スパイラル開発だぁ。と思っているらしい。全くこっちにとっちゃ
悪夢のスパイラルだよ。
客から要望聞いて、おおざっぱな画面設計とＤＢ設計（なんと
要件が固まりきらないうちにＤＢ設計されてしまう）と、要件が
箇条書きになっているようなもんを基本設計書ですって渡して
きて、これで詳細設計におとしてくださいという。そしてその後、
頻繁に画面ちょっと変わりましたぁ。対応してください～い。とか
言ってくる。こんなんでまともなクラス設計なんてできるわけがない。
そしていざ実装という時点でも、要件が変わるもんだから、画面と
ＤＢ設計書を修正したものを渡してきやがる。本人達はこれが
スパイラル開発だぁ。と思っているらしい。全くこっちにとっちゃ
悪夢のスパイラルだよ。
ところでOODの定義って何？
なにをやってればOODって事になるの？
なにをやってればOODって事になるの？
>>854
UMLにのっとっていればよいのでは
とりあえずシナリオ書いて
シナリオから書けば
>>853のような事態にはならないと思う
シナリオも無しに画面とDB設計は無謀だと思う
お客さんは実は自分が欲しいシステムを本当は知らないというのは
結構重要なポイントだと思う
UMLにのっとっていればよいのでは
とりあえずシナリオ書いて
シナリオから書けば
>>853のような事態にはならないと思う
シナリオも無しに画面とDB設計は無謀だと思う
お客さんは実は自分が欲しいシステムを本当は知らないというのは
結構重要なポイントだと思う
業務システムのユースケースでさ「利用者情報を登録する」ってユースケースあるじゃん？
これを構造化で実現しようとすると、登録プロシージャに利用者情報を渡すってイメージになるでしょ？
で、利用者情報を渡された登録プロシージャにはDBにインサートする処理を書くわけ。
DB中心に考える人はこれがとても分かりやすい。
でも、これをオブジェクト指向で設計すると、イメージとしては「利用者」というインスタンスをnewするだけでもう処理は終わりなんだよ。
だって、メモリ上に利用者情報のインスタンスが出来た時点でシステムには登録されている状態になるでしょ？
あとはこのインスタンスをDBでもXMLにでも永続化しておいて、後からこのインスタンスを利用できるようになっていればいいだけなのさ。
OOPだとメモリ上で全部やろう！っていうのが基本的な考え方だよ。
でも超大量インスタンスを抱え込めるメモリなんてないから、適材適所でシステム作りましょうってこと。
1件ずつの処理ならメモリ上で処理しても問題ないけど100万インスタンスをメモリ上に展開して処理するのは
性能、リソースの観点から好ましくないから、SQLで一括で処理しちゃえば？って考えだと思う。
これを構造化で実現しようとすると、登録プロシージャに利用者情報を渡すってイメージになるでしょ？
で、利用者情報を渡された登録プロシージャにはDBにインサートする処理を書くわけ。
DB中心に考える人はこれがとても分かりやすい。
でも、これをオブジェクト指向で設計すると、イメージとしては「利用者」というインスタンスをnewするだけでもう処理は終わりなんだよ。
だって、メモリ上に利用者情報のインスタンスが出来た時点でシステムには登録されている状態になるでしょ？
あとはこのインスタンスをDBでもXMLにでも永続化しておいて、後からこのインスタンスを利用できるようになっていればいいだけなのさ。
OOPだとメモリ上で全部やろう！っていうのが基本的な考え方だよ。
でも超大量インスタンスを抱え込めるメモリなんてないから、適材適所でシステム作りましょうってこと。
1件ずつの処理ならメモリ上で処理しても問題ないけど100万インスタンスをメモリ上に展開して処理するのは
性能、リソースの観点から好ましくないから、SQLで一括で処理しちゃえば？って考えだと思う。
開発プロセスとOODは直接関係ない。
だけどオブジェクト指向開発のメリットを引き出しやすい開発プロセスはあると思う。
だけどオブジェクト指向開発のメリットを引き出しやすい開発プロセスはあると思う。
>>853 に書かれているようなバカ連中には、ある特徴的な類似点がある。
まず、仕様書（本人達はそう言ってる）が例外なくExcelである。そして、
DBはテーブルの主キーにことごく自然キー（特に複合キー）を使う。ＤＢ
への制約はまずかけない。なかにはNOT NULL制約すら書いてない場合もある。
とにかく、複合キーはいただけない。実装レベルへの負荷にかなり影響する。
オブジェクト指向による実装を知らないからこんな上流、下流のミスマッチ
がおこる。ＳＥの仕事はこういうことだという認識がそのまま下流に浸透して
しまうのも問題だ。それこそ悪夢のスパイラルが永遠に伝承されていくことに
なる。スパイラルはほんと、日本では誤った認識されていると思うよ。
まず、仕様書（本人達はそう言ってる）が例外なくExcelである。そして、
DBはテーブルの主キーにことごく自然キー（特に複合キー）を使う。ＤＢ
への制約はまずかけない。なかにはNOT NULL制約すら書いてない場合もある。
とにかく、複合キーはいただけない。実装レベルへの負荷にかなり影響する。
オブジェクト指向による実装を知らないからこんな上流、下流のミスマッチ
がおこる。ＳＥの仕事はこういうことだという認識がそのまま下流に浸透して
しまうのも問題だ。それこそ悪夢のスパイラルが永遠に伝承されていくことに
なる。スパイラルはほんと、日本では誤った認識されていると思うよ。
>>857
飛躍しすぎだと思う
「利用者」のデータセットインスタンスを指していると思うけど
登録が必要なら削除や追加も必要だったり
削除したものは復活できるのかとか
登録時のIDみたいなものは削除後は欠番にするのかとか
ユーザーインターフェースはオフコン上がりのオペレーターが多いから
オフコンライクにするとか
派遣社員でまかなうからオフィスライクな感じにするとか
ここら辺は設計よりも前の要求定義だと思うけど
飛躍しすぎだと思う
「利用者」のデータセットインスタンスを指していると思うけど
登録が必要なら削除や追加も必要だったり
削除したものは復活できるのかとか
登録時のIDみたいなものは削除後は欠番にするのかとか
ユーザーインターフェースはオフコン上がりのオペレーターが多いから
オフコンライクにするとか
派遣社員でまかなうからオフィスライクな感じにするとか
ここら辺は設計よりも前の要求定義だと思うけど
>>862
うん、当然それはそうだけど、内部の処理に関しては一緒でしょ？
登録はインスタンスの生成
追加もインスタンスの生成
削除はインスタンスの永続性の解除
論理削除かどうかってのはクラスが論理削除属性持つかどうかのクラス設計でしょ。
UI設計はインスタンスをどう見せるかってだけでまた別の要求定義だと思う。
うん、当然それはそうだけど、内部の処理に関しては一緒でしょ？
登録はインスタンスの生成
追加もインスタンスの生成
削除はインスタンスの永続性の解除
論理削除かどうかってのはクラスが論理削除属性持つかどうかのクラス設計でしょ。
UI設計はインスタンスをどう見せるかってだけでまた別の要求定義だと思う。
865 ：仕様書無しさん：2007/02/18(日) 13:26:46
うわぁ
業務アプリの世界
業務アプリの世界
866 ：仕様書無しさん：2007/02/18(日) 13:30:06
●●オブジェクト設計は何故流行らないの？●●02
↓
●●新しいパラダイムの業務アプリ設計は何故流行らないの？●●02
オブジェクト設計==新しいパラダイムの業務アプリ設計
だったんだなあ。うーん。よく分かった。
↓
●●新しいパラダイムの業務アプリ設計は何故流行らないの？●●02
オブジェクト設計==新しいパラダイムの業務アプリ設計
だったんだなあ。うーん。よく分かった。
↑なんでこの人はここ数時間の流れだけでそう断定してしまうのだろう。
頭の弱い人なのかな。
頭の弱い人なのかな。
>>866
業務アプリに限って説明してるけど、OOPの考え方の基本は一緒ですよ。
ほとんどの業務アプリはエンティティのCRUDユースケースだし。
ライブラリとかちょっとしたユーティリティ作るときにも
OOPの考え方だと修正が楽できるよ。
このデータに関しては修正ありそうだから別クラスに切り出しておくかとか
処理方法は統一したいからIFで切ってコマンドパターン使おうとかさ。
業務アプリに限って説明してるけど、OOPの考え方の基本は一緒ですよ。
ほとんどの業務アプリはエンティティのCRUDユースケースだし。
ライブラリとかちょっとしたユーティリティ作るときにも
OOPの考え方だと修正が楽できるよ。
このデータに関しては修正ありそうだから別クラスに切り出しておくかとか
処理方法は統一したいからIFで切ってコマンドパターン使おうとかさ。
869 ：仕様書無しさん：2007/02/18(日) 13:34:59
>OOPだとメモリ上で全部やろう！っていうのが基本的な考え方だよ
そおなんっスか。うーん。カーネルはちびちびとバッファを節約して
頑張っているのに業務の人は自分の事しか考えなくて良いからお気楽ですね。
そおなんっスか。うーん。カーネルはちびちびとバッファを節約して
頑張っているのに業務の人は自分の事しか考えなくて良いからお気楽ですね。
870 ：仕様書無しさん：2007/02/18(日) 13:38:25
>ライブラリとかちょっとしたユーティリティ作るときにも
デバイスドライバより下層には当てはまらないから万能ではないと思うけどね。
ここで言うライブラリとかちょっとしたユーティリティって
消費税を計算するスタティックメソッドみたいなレベルでしょ。
大きなくくりで「業務アプリ」に含まれると思うけど。
>業務アプリに限って説明してるけど
をきちんと説明してないし、応用範囲が明確に示されていないよ。
大丈夫?それで設計できるの?
デバイスドライバより下層には当てはまらないから万能ではないと思うけどね。
ここで言うライブラリとかちょっとしたユーティリティって
消費税を計算するスタティックメソッドみたいなレベルでしょ。
大きなくくりで「業務アプリ」に含まれると思うけど。
>業務アプリに限って説明してるけど
をきちんと説明してないし、応用範囲が明確に示されていないよ。
大丈夫?それで設計できるの?
↑あ、この人寂しがりやさんだ。
>>869
そうだよ、だから楽できるんだよ。
そもそもJVM起動するときにあらかじめヒープ領域確保されちゃってるでしょう。
その中でどうメモリ使おうかは設計の自由じゃまいか。
さすがに超大量のデータ処理をOOPでやろう！ってのはOutOfMemoryエラーとかで
VM落ちちゃう可能性あって無理だけど、1インスタンス数十kb程度なら問題ないっしょ。
てかもう領域確保されちゃってるし使わなきゃ損。
マシンスペックも日々向上してるしねｗ
そうだよ、だから楽できるんだよ。
そもそもJVM起動するときにあらかじめヒープ領域確保されちゃってるでしょう。
その中でどうメモリ使おうかは設計の自由じゃまいか。
さすがに超大量のデータ処理をOOPでやろう！ってのはOutOfMemoryエラーとかで
VM落ちちゃう可能性あって無理だけど、1インスタンス数十kb程度なら問題ないっしょ。
てかもう領域確保されちゃってるし使わなきゃ損。
マシンスペックも日々向上してるしねｗ
消費税を計算するスタティックメソッドって何だろう・・・
消費税計算したきゃ価格属性持ってるインスタンスに計算メソッド追加するだけじゃん？
ライブラリでもなんでもないし・・・
消費税計算したきゃ価格属性持ってるインスタンスに計算メソッド追加するだけじゃん？
ライブラリでもなんでもないし・・・
商品毎に税率違うのか
java設定させるんじゃなくて必要なら必要なだけとって勝手に動けよな
877 ：仕様書無しさん：2007/02/18(日) 13:47:06
設計という事は、物理メモリに対してjavaのクラスインスタンスの
瞬間最大総量を計算して余裕があるのを前提に>>873が話しているのならば
いいでしょう。でも君のレスみると、ざっくりとだいじょうぶしょのノリで
万事テキトーな雰囲気が漂うんだけど。javaのSEさんってみんなこんのばっかりなの?
瞬間最大総量を計算して余裕があるのを前提に>>873が話しているのならば
いいでしょう。でも君のレスみると、ざっくりとだいじょうぶしょのノリで
万事テキトーな雰囲気が漂うんだけど。javaのSEさんってみんなこんのばっかりなの?
一律でも商品毎でもどっちでも同じでしょ？
「商品「クラスに税率計算メソッド持ってれば、それを継承した「本」とか「家電」とかも
まとめて計算できるし、本だけ税率変えたければ本の計算メソッドオーバーライドすればいいだけだし・・・
「商品「クラスに税率計算メソッド持ってれば、それを継承した「本」とか「家電」とかも
まとめて計算できるし、本だけ税率変えたければ本の計算メソッドオーバーライドすればいいだけだし・・・
いや「物理メモリ」じゃないから
ただ、どうみてもこの処理リソース消費ヤバイだろ・・・的なこと以外は
最初からリソース懸念して設計してないな。
テストしてみて懸念される箇所だけ処理方法かえるってのがセオリーかな。
自分の中ではリソース、性能よりも拡張性、修正のし易さにプライオリティ置いてるからかなぁ
最初からリソース懸念して設計してないな。
テストしてみて懸念される箇所だけ処理方法かえるってのがセオリーかな。
自分の中ではリソース、性能よりも拡張性、修正のし易さにプライオリティ置いてるからかなぁ
884 ：仕様書無しさん：2007/02/18(日) 13:58:25
>>879
>いや「物理メモリ」じゃないから
物理メモリだってば。ハードウェアのメモリをOS管轄の
memoryマッパで初期化してるんだよ。VMのソース覗いたことないの?
「JavaのTCP/IPにはソケットを使わない」の名言を思い出してしまった。スマソ
>いや「物理メモリ」じゃないから
物理メモリだってば。ハードウェアのメモリをOS管轄の
memoryマッパで初期化してるんだよ。VMのソース覗いたことないの?
「JavaのTCP/IPにはソケットを使わない」の名言を思い出してしまった。スマソ
886 ：仕様書無しさん：2007/02/18(日) 14:07:23
>>885
スマヌこちら低脳のため意味がわからん。
スマヌこちら低脳のため意味がわからん。
887 ：仕様書無しさん：2007/02/18(日) 14:13:21
>>884
Java良く知らんのだけどJavaはスワップしちゃ駄目なんですか？
Java良く知らんのだけどJavaはスワップしちゃ駄目なんですか？
スタティックメソッドって出てたけど、税率計算処理に対して商品データを渡すってことは考えないで、
OOPだと個々のデータが処理を持つって考え方だよ～
データを取りまとめる親玉がいて、それが個々のデータに計算を任せる。
もしかしたら親玉もまた別の親玉に取りまとめられているかもしれない。これがOOP。
OOPだと個々のデータが処理を持つって考え方だよ～
データを取りまとめる親玉がいて、それが個々のデータに計算を任せる。
もしかしたら親玉もまた別の親玉に取りまとめられているかもしれない。これがOOP。
消費税計算、難しいですね
旧来なら消費税を返す関数を作るところだけど
OOPなら商品のプロパティなりメソッドで返すようにするんですね
そういえば大抵のオブジェクトには tostring が用意されていたりしますね
旧来なら消費税を返す関数を作るところだけど
OOPなら商品のプロパティなりメソッドで返すようにするんですね
そういえば大抵のオブジェクトには tostring が用意されていたりしますね
OOPの流行らない一番の原因、それは
「客がオブジェクト指向が分からない。」
だと思うよ。
データベースのER図はこれです。
処理は○○処理、××処理、・・・があり、この処理を呼ぶとこうデータを処理します。
といったほうが分かる。
OOPだと最終的なクラス図見せられてもデータ構造は分かるけど、
処理が細切れに各クラスに分割されるので一目見ただけだと分かりにくい。
クラス図＋シーケンス図で初めて処理内容が分かる。
「客がオブジェクト指向が分からない。」
だと思うよ。
データベースのER図はこれです。
処理は○○処理、××処理、・・・があり、この処理を呼ぶとこうデータを処理します。
といったほうが分かる。
OOPだと最終的なクラス図見せられてもデータ構造は分かるけど、
処理が細切れに各クラスに分割されるので一目見ただけだと分かりにくい。
クラス図＋シーケンス図で初めて処理内容が分かる。
>>889
それ以前の問題として、税率は商品の属性なのか？
それ以前の問題として、税率は商品の属性なのか？
税率は国家クラスの属性だからグローバルでいいよ。
客かどのレベルの客かが問題だな
エンドユーザだとDBもERもわからんだろうし、ある意味やりたい放題だし、
ある程度の企業のシステム部だと変に言葉とかに詳しくて、かえって困ったりする。
>>890みたいな感じの客は、メーカ系列系のソフトハウスかな。
エンドユーザだとDBもERもわからんだろうし、ある意味やりたい放題だし、
ある程度の企業のシステム部だと変に言葉とかに詳しくて、かえって困ったりする。
>>890みたいな感じの客は、メーカ系列系のソフトハウスかな。
public class Goods {
private String name;
private int price;
//プロパティファイルから読み込んでもOK
private static Double taxRate = 0.05;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getPrice() {
return price;
}
public void setPrice(int price) {
this.price = price;
}
//消費税込みの価格を返す
public Double getTaxedPrice(){
return price*(1+taxRate);
}
}
private String name;
private int price;
//プロパティファイルから読み込んでもOK
private static Double taxRate = 0.05;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getPrice() {
return price;
}
public void setPrice(int price) {
this.price = price;
}
//消費税込みの価格を返す
public Double getTaxedPrice(){
return price*(1+taxRate);
}
}
public class GoodsList {
private List<Goods> goodsList;
public List<Goods> getGoodsList() {
return goodsList;
}
public void setGoodsList(List<Goods> goodsList) {
this.goodsList = goodsList;
}
//消費税込みの商品総額を取得
public Double getTotalPrice(){
Double sum = 0.0;
for(Iterator i = goodsList.iterator();i.hasNext();){
Goods goods = (Goods)i.next();
sum += goods.getTaxedPrice();
}
return sum;
}
}
private List<Goods> goodsList;
public List<Goods> getGoodsList() {
return goodsList;
}
public void setGoodsList(List<Goods> goodsList) {
this.goodsList = goodsList;
}
//消費税込みの商品総額を取得
public Double getTotalPrice(){
Double sum = 0.0;
for(Iterator i = goodsList.iterator();i.hasNext();){
Goods goods = (Goods)i.next();
sum += goods.getTaxedPrice();
}
return sum;
}
}
細かい計算方法は突っ込みどころ満載だけど、GoodsListインスタンスをUserが持っていれば
簡単にショッピングカートWebサイトの出来上がり。
簡単にショッピングカートWebサイトの出来上がり。
つか、処理なんてわからなくていいよ。
手続きの塊としてしかシステムを理解できないのは、旧態依然のやり方に頭が毒されてるから。
内部でどんな処理されてるかなんて知らんが自動販売機も使えるしExcelも使える。
手続きの塊としてしかシステムを理解できないのは、旧態依然のやり方に頭が毒されてるから。
内部でどんな処理されてるかなんて知らんが自動販売機も使えるしExcelも使える。
>>897
それは、プログラムなんて出来なくても、設計は行えるという意味ですか？
それは、プログラムなんて出来なくても、設計は行えるという意味ですか？
>>898
実装設計は言語依存だから無理だけど
基本的なOOPの考えがしっかりしてれば
このクラスはこの責務があってこの属性、関連を持たせる。
で、このメソッド呼ぶと関連持ってるクラスのこのメソッド使って計算してこれを返す。
ってことが分かれば、あとは各クラスについてそれの繰り返しだから設計は問題なく出来ると思うよ。
実装設計は言語依存だから無理だけど
基本的なOOPの考えがしっかりしてれば
このクラスはこの責務があってこの属性、関連を持たせる。
で、このメソッド呼ぶと関連持ってるクラスのこのメソッド使って計算してこれを返す。
ってことが分かれば、あとは各クラスについてそれの繰り返しだから設計は問題なく出来ると思うよ。
たかじん終わったからもういいや
実は消費税ひとつとっても業務システムの場合そう単純じゃないんだよね
データはは内税で持たせるのかにするのか、外税で持たせるのかにするのか、
計算は総額に対して行うのか商品ごとに行うのか
総額の場合、日計、月計、年計で丸め誤差が出るがどうすのか
要求によっては、商品ごとに丸め方をかえてくれだとか
打ち合わせしているうちにお客さんの業務や会計処理に誤りを見つけてしまったり
それが法的に問題ありだったり
あげくの果ては、そういった業務改善についてのコンサルタントまがいの事してたりして
まあ、田舎の話なんだけど
お客さんのところに電算部門とかあって
コボラー中心で構成されていたら
OOPはﾑﾘﾎﾟ
データはは内税で持たせるのかにするのか、外税で持たせるのかにするのか、
計算は総額に対して行うのか商品ごとに行うのか
総額の場合、日計、月計、年計で丸め誤差が出るがどうすのか
要求によっては、商品ごとに丸め方をかえてくれだとか
打ち合わせしているうちにお客さんの業務や会計処理に誤りを見つけてしまったり
それが法的に問題ありだったり
あげくの果ては、そういった業務改善についてのコンサルタントまがいの事してたりして
まあ、田舎の話なんだけど
お客さんのところに電算部門とかあって
コボラー中心で構成されていたら
OOPはﾑﾘﾎﾟ
>>902
それは言えるね。
OOPなら「丸め方法」とかいってストラテジーパターンで
丸め実装を切り替えられるようにしとけるけどそんなクラスがいる自体
理解できないだろうなぁ・・・
日計とかの集計系は特にOOPだと楽だよ。
商品インスタンスで日付が今日のデータだけ集めるのも
Double sum = 0.0;
for(Iterator i = goodsList.iterator();i.hasNext();){
if(日付が今日のもの){
Goods goods = (Goods)i.next();
sum += goods.getTaxedPrice();
}
}
return sum;
だし。SQLだと超複雑怪奇になるけど
それは言えるね。
OOPなら「丸め方法」とかいってストラテジーパターンで
丸め実装を切り替えられるようにしとけるけどそんなクラスがいる自体
理解できないだろうなぁ・・・
日計とかの集計系は特にOOPだと楽だよ。
商品インスタンスで日付が今日のデータだけ集めるのも
Double sum = 0.0;
for(Iterator i = goodsList.iterator();i.hasNext();){
if(日付が今日のもの){
Goods goods = (Goods)i.next();
sum += goods.getTaxedPrice();
}
}
return sum;
だし。SQLだと超複雑怪奇になるけど
906 ：仕様書無しさん：2007/02/18(日) 15:30:32
>>894-895
ちょっちまってくれ
たかが消費税を計算するのにそんなにクラスと変動可変データの結合度を強く持たせるのは
汎用性というかクラス設計に問題があるとおもうが。といっても代替案はないけどね。
ちょっとみんなで考えてほしいよ。疎結合なクラスというのをさ。
消費税の例でいいじゃん。
ちょっちまってくれ
たかが消費税を計算するのにそんなにクラスと変動可変データの結合度を強く持たせるのは
汎用性というかクラス設計に問題があるとおもうが。といっても代替案はないけどね。
ちょっとみんなで考えてほしいよ。疎結合なクラスというのをさ。
消費税の例でいいじゃん。
間違い、
Goods goods = (Goods)i.next();
if(日付が今日のもの){
sum += goods.getTaxedPrice();
}
だ。
Goods goods = (Goods)i.next();
if(日付が今日のもの){
sum += goods.getTaxedPrice();
}
だ。
>>906
>たかが消費税を計算するのにそんなにクラスと変動可変データの結合度を強く持たせるのは
>汎用性というかクラス設計に問題があるとおもうが。といっても代替案はないけどね。
それこそストラテジーパターンだよ。
消費税計算方法とかいうクラスを別に作って、商品リストが集計するときに
商品クラスにセットしてあげればいいじゃん。
>たかが消費税を計算するのにそんなにクラスと変動可変データの結合度を強く持たせるのは
>汎用性というかクラス設計に問題があるとおもうが。といっても代替案はないけどね。
それこそストラテジーパターンだよ。
消費税計算方法とかいうクラスを別に作って、商品リストが集計するときに
商品クラスにセットしてあげればいいじゃん。
909 ：仕様書無しさん：2007/02/18(日) 15:34:25
本来のOOの基本的な考え方だと
センダにメッセージを投げる(仕事の依頼)=>レシバは仕事をし、結果を返す
この場合消費税があってもなくてもセンダ側は意識しないで結果だけを求め
られるのが理想。税抜き、税込みどちらの計算もレシバが面倒をみてくれるはず。
しかしここで問題なのが結合度。レシバ側のクラス設計と変動データをどう
解決するかがポイント。
センダにメッセージを投げる(仕事の依頼)=>レシバは仕事をし、結果を返す
この場合消費税があってもなくてもセンダ側は意識しないで結果だけを求め
られるのが理想。税抜き、税込みどちらの計算もレシバが面倒をみてくれるはず。
しかしここで問題なのが結合度。レシバ側のクラス設計と変動データをどう
解決するかがポイント。
910 ：仕様書無しさん：2007/02/18(日) 15:36:32
そしてポリモアフィズムを利用した美しい昇華のシナリオが満たせるかどうか。
・全商品に一律同じアルゴリズムで消費税計算させたい。
⇒DefaultStrategyをセット
・一部商品は違うアルゴリズムで計算させたい
⇒商品を継承した本クラスにだけBookStrategyをセット
こうしておけば、商品クラスのgetTaxtedPriceでポリモーフィズムつかって
それぞれ違うアルゴリズムで計算できる。
⇒DefaultStrategyをセット
・一部商品は違うアルゴリズムで計算させたい
⇒商品を継承した本クラスにだけBookStrategyをセット
こうしておけば、商品クラスのgetTaxtedPriceでポリモーフィズムつかって
それぞれ違うアルゴリズムで計算できる。
そんなもん考えてる暇があったらどんどんコーディングしたほうが
早い
早い
913 ：仕様書無しさん：2007/02/18(日) 15:41:35
ストラテジパターンで内部スイッチを切り替えるのにフラグパラメータ
が必要なるということ?
理想論だけどポリモで解決できる方法はないだろうか?
が必要なるということ?
理想論だけどポリモで解決できる方法はないだろうか?
915 ：仕様書無しさん：2007/02/18(日) 15:44:29
クラスの継承でポリモね。それはパターン数が莫大になった場合は
使えないよね。パターン数が限定的ならばひとつの解決方法。
使えないよね。パターン数が限定的ならばひとつの解決方法。
それでも修正時間のほうが短い
>>913
ちがうよ。消費税計算方法っていうクラスのIFだけ同じにしといて
呼び出し側（GoodList）が実装クラスを入れ替えれてやれば商品クラスがフラグ持つ必要ない。
集計方法を知っているのはGoodsListクラスだからね。
ゴリゴリ集計処理をGoodsListクラスに書いてもいいけど修正が大変じゃん？
ちがうよ。消費税計算方法っていうクラスのIFだけ同じにしといて
呼び出し側（GoodList）が実装クラスを入れ替えれてやれば商品クラスがフラグ持つ必要ない。
集計方法を知っているのはGoodsListクラスだからね。
ゴリゴリ集計処理をGoodsListクラスに書いてもいいけど修正が大変じゃん？
>>916
やってることは結局GoodListで集計するんだから、それをゴリゴリ書くのか、
それともストラテジパターン使って消費税計算処理をセットして集計させるかの違いだよ？
GoodsListの利用側はGoodsListがゴリゴリ集計処理を頑張っていようが
ストラテジーパターンつかって集計してようがしったこっちゃない。
やってることは結局GoodListで集計するんだから、それをゴリゴリ書くのか、
それともストラテジパターン使って消費税計算処理をセットして集計させるかの違いだよ？
GoodsListの利用側はGoodsListがゴリゴリ集計処理を頑張っていようが
ストラテジーパターンつかって集計してようがしったこっちゃない。
>>916
public Double getTotalPrice(){
for(商品数だけ繰り返し){
if(商品が本だったら){
if(本で尚且つ○○だったら)
sum+=XX;
}else if(本で尚且つ××だったら){
if(でも何とかの場合は除く){
continue;
}
sum+=YY;
}
if(商品が家電だったら){
sum+=ZZ;
}
}
return sum;
}
public Double getTotalPrice(){
for(商品数だけ繰り返し){
if(商品が本だったら){
if(本で尚且つ○○だったら)
sum+=XX;
}else if(本で尚且つ××だったら){
if(でも何とかの場合は除く){
continue;
}
sum+=YY;
}
if(商品が家電だったら){
sum+=ZZ;
}
}
return sum;
}
920 ：仕様書無しさん：2007/02/18(日) 16:00:43
>>917
IFね了解。
IFとかアブストラクトの落とし穴って、結局インプリメントする
クラス全てに影響がでちゃうのがどうもね。
消費税計算ってもっとジェネリックな位置にあると仮定して別の
解決方法はないですか?
>集計処理をGoodsListクラスに書いてもいいけど
仕様は満たせるけど合理的ではないですな。
IFね了解。
IFとかアブストラクトの落とし穴って、結局インプリメントする
クラス全てに影響がでちゃうのがどうもね。
消費税計算ってもっとジェネリックな位置にあると仮定して別の
解決方法はないですか?
>集計処理をGoodsListクラスに書いてもいいけど
仕様は満たせるけど合理的ではないですな。
>消費税計算ってもっとジェネリックな位置にあると仮定して別の
>解決方法はないですか?
うーん、一般的なのはやっぱ上のパターン使っちゃう奴じゃないかなぁ？
価格渡せば消費税込みの価格返すメソッドを持つIFのクラスを、具象クラス単位に作る。
汎用性が欲しければデフォルトの1個作って予めセットしておけばいいだけでしょ？
汎用的っていうのは、とりあえず商品インスタンス渡せば中で区別して
それぞれ計算処理してくれる汎用クラスってことでしょ？>>919みたいな。
そういうのがあっていいかも知れないけど
「変更が入りそうなところはどこか」に着目すれば、個別に切り出しておくほうがメリットあると思われ。
>解決方法はないですか?
うーん、一般的なのはやっぱ上のパターン使っちゃう奴じゃないかなぁ？
価格渡せば消費税込みの価格返すメソッドを持つIFのクラスを、具象クラス単位に作る。
汎用性が欲しければデフォルトの1個作って予めセットしておけばいいだけでしょ？
汎用的っていうのは、とりあえず商品インスタンス渡せば中で区別して
それぞれ計算処理してくれる汎用クラスってことでしょ？>>919みたいな。
そういうのがあっていいかも知れないけど
「変更が入りそうなところはどこか」に着目すれば、個別に切り出しておくほうがメリットあると思われ。
922 ：仕様書無しさん：2007/02/18(日) 16:24:03
public Double getTotalPrice(){
の汎用クラス関数は業務の局所的な依存ではいいよね。これしかない。
でもさ、ジェネリックなカテゴリはいちど作ったら全部使える(使いたい)
データ型依存なぞ無い。という理想を目指すとどうなるんだろう。
1. このメソッドの内部判断が膨れ上がる
2. Prototypeパターンを利用する
どうすればいい?
の汎用クラス関数は業務の局所的な依存ではいいよね。これしかない。
でもさ、ジェネリックなカテゴリはいちど作ったら全部使える(使いたい)
データ型依存なぞ無い。という理想を目指すとどうなるんだろう。
1. このメソッドの内部判断が膨れ上がる
2. Prototypeパターンを利用する
どうすればいい?
923 ：仕様書無しさん：2007/02/18(日) 16:25:17
さっきから消費税の実装レベルの話してる奴はあったまわりぃなｗ
「結局1.05掛けるだけだろ。」
って話になって現場の設計に温度差が出る現状。
って話になって現場の設計に温度差が出る現状。
925 ：仕様書無しさん：2007/02/18(日) 16:25:59
毎回毎回、設計だっつってんのにこんな糞レベルの話持ち出していい加減馬鹿過ぎで頭にくる
ここは宿題を答えるスレか？
928 ：仕様書無しさん：2007/02/18(日) 16:29:20
だからさ、設計のスレだっていってんのにソースコードなんて貼ってる奴は素質ねぇんだよ。
実装レベルで出る問題点だって範囲が広すぎてレスにソース貼った程度じゃ表現できねぇっての。
そんなこともわからないほど経験が浅いからムカツクんだよ。
実装レベルで出る問題点だって範囲が広すぎてレスにソース貼った程度じゃ表現できねぇっての。
そんなこともわからないほど経験が浅いからムカツクんだよ。
>>927
日本語でおｋ
日本語でおｋ
>>928の経験が浅いこともよくわかった
消費税程度のもんになんでストラテジとかいってんの、んなもんテンプレート
メソッドパターンとかで十分だと思うけど。そんなことやってたたらシステム全体
がストラテジだらけになっちゃうよ。ドキュメントにまとめて説明したり、理解さ
せるのに時間かかりそうだな。ただの自己満足じゃないの？ むりやり小難しくし
てない？。技術を使うのが目的になっちゃってるような。
メソッドパターンとかで十分だと思うけど。そんなことやってたたらシステム全体
がストラテジだらけになっちゃうよ。ドキュメントにまとめて説明したり、理解さ
せるのに時間かかりそうだな。ただの自己満足じゃないの？ むりやり小難しくし
てない？。技術を使うのが目的になっちゃってるような。
現実問題として、設計段階でこんなちまちまやってたら、
いつまで経っても終わらんわな。
いつまで経っても終わらんわな。
936 ：仕様書無しさん：2007/02/18(日) 16:33:53
だいたい、何？
はぁ？消費税？
なんでこんなもんクラスにしてんだよ。
馬鹿か、アホか、給料ドロボーもたいがいにしろよ。
プログラマなんて辞めろ。今すぐ辞めろ。なんでこんなアホ、野放しにしとくんだ。
早く死ねよ。
はぁ？消費税？
なんでこんなもんクラスにしてんだよ。
馬鹿か、アホか、給料ドロボーもたいがいにしろよ。
プログラマなんて辞めろ。今すぐ辞めろ。なんでこんなアホ、野放しにしとくんだ。
早く死ねよ。
>>931
ハヤクネタフレや。もしくは死ね。
ハヤクネタフレや。もしくは死ね。
938 ：仕様書無しさん：2007/02/18(日) 16:34:34
>>935
頭悪いんだよ。お前。早く死ね。
頭悪いんだよ。お前。早く死ね。
>>932
宿題がんばれよ
宿題がんばれよ
まぁ、茶でものんでもちつけもちつけ。
次スレは、くだらないスレにならないよう、>>925がナイスなネーミングで
たてるそうです。乞うご期待。。。
たてるそうです。乞うご期待。。。
あえて、簡単な例で、じっくり考えてみようって
趣旨が判らんのかね
趣旨が判らんのかね
何が「設計レベルの高度な・・・」だよ恥ずかしくないのか、マジ死ねや。
>>925じゃないけど、
「上流工程でオブジェクト指向が～」の方がいいわな。
「上流工程でオブジェクト指向が～」の方がいいわな。
だから上流も下流もないっての
結局はスレタイの主語がはっきりしないから
前提で混乱してるってことだわな。
前提で混乱してるってことだわな。
そもそもオブジェクト設計ってなんだよ？造語か？
>>946
じゃあ韓流でおｋ？
じゃあ韓流でおｋ？
濁流濁流
次スレ
●●ｵﾌﾞｼﾞｪｸﾄ設計は何故流行らないの？（2）●●
http://pc10.2ch.net/test/read.cgi/prog/1169568701/l50
重複再利用で。
とてつもないグッドなスレタイ思いついた人居たら、俺が別途立てますが
●●ｵﾌﾞｼﾞｪｸﾄ設計は何故流行らないの？（2）●●
http://pc10.2ch.net/test/read.cgi/prog/1169568701/l50
重複再利用で。
とてつもないグッドなスレタイ思いついた人居たら、俺が別途立てますが
>>948
これは確かにおかしいな
これは確かにおかしいな
オブジェクト指向が設計段階で何故流行らないの？（スレタイ改め）(2)
どう？>all
どう？>all
954 ：仕様書無しさん：2007/02/18(日) 16:49:05
あーあ
荒れちゃったよ
荒れちゃったよ
955 ：仕様書無しさん：2007/02/18(日) 16:50:17
簡単な例の解決もできないのだから複雑な問題解決は絶対できんだろうなあ。
それこそ焼きビーフンのような設計になってしまう。
それこそ焼きビーフンのような設計になってしまう。
恥ずかしながら俺は、オブジェクト設計とクラス設計の違いがわからん。
焼きビーフン設計とはなんだ？？
初めて聞いたぞ。
初めて聞いたぞ。
上流、下流とはいってもオブジェクト指向開発って結局業務分析からエンティティ抽出して
その関連を定義して、ユースケースでエンティティ操作するんだろ？
それが実装に落ちると基本的にはエンティティ部分は変わらないが、
実装方法としてのOOPやデザインパターンがある。それにの則った話に過ぎないと思うんだがどうか？
エンティティ抽出までは出来たOOP理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。
その関連を定義して、ユースケースでエンティティ操作するんだろ？
それが実装に落ちると基本的にはエンティティ部分は変わらないが、
実装方法としてのOOPやデザインパターンがある。それにの則った話に過ぎないと思うんだがどうか？
エンティティ抽出までは出来たOOP理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。
×エンティティ抽出までは出来たOOP理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。
○エンティティ抽出までは出来たが、OOPを理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。
○エンティティ抽出までは出来たが、OOPを理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。
>>958
すまんが日本語に翻訳してもらえないか。
すまんが日本語に翻訳してもらえないか。
教科書的には税金の計算方法が変化する可能性がある場合はストラテジパターン
なんだろうけど、仕事の場合は、設計してるソフトウェアの業務ドメイン
による、というのが実際のところだよな。
実業務では実装も設計および要求と無関係でいられることはない。
(と無理やり設計の話に結びつける)
不必要な柔軟性も不十分な柔軟性と同じように保守性を下げるから、
なんでもかんでもストラテジ、とか仕事でされるとマジで逝ってよしだな。
なんだろうけど、仕事の場合は、設計してるソフトウェアの業務ドメイン
による、というのが実際のところだよな。
実業務では実装も設計および要求と無関係でいられることはない。
(と無理やり設計の話に結びつける)
不必要な柔軟性も不十分な柔軟性と同じように保守性を下げるから、
なんでもかんでもストラテジ、とか仕事でされるとマジで逝ってよしだな。
962 ：仕様書無しさん：2007/02/18(日) 16:55:19
963 ：仕様書無しさん：2007/02/18(日) 16:58:36
頭の中では理想を貫きたいのだが
実際は客が要求する正規化もろくにされてない昔から使ってるDB
を現代のOOP言語システムでリメイクする。
データ構造の基本設計は前近代なのに最先端技術と結びつけようとする
ところに歪がでる。結局理想は理想でしかなくなり、ジャワのコードは
シーケンシャルな手続き代入文で終始する。
実際は客が要求する正規化もろくにされてない昔から使ってるDB
を現代のOOP言語システムでリメイクする。
データ構造の基本設計は前近代なのに最先端技術と結びつけようとする
ところに歪がでる。結局理想は理想でしかなくなり、ジャワのコードは
シーケンシャルな手続き代入文で終始する。
>>960
上流、下流とはいってもオブジェクト指向開発って
結局業務分析から扱うデータ抽出して、その関連を定義して、CRUD操作するんだろ？
それが実装に落ちると基本的にはデータ構造は変わらないが、
実装方法としてて、オブジェクト指向プログラミングやデザインパターンがある。
それにの則った話に過ぎないと思うんだがどうか？
データ構造の抽出までは出来たが、OOPを理解してなくて単なるSQLでのDBへのCRUD操作、
複雑なSQLベースのシステムになる例が多すぎる訳で。
上流、下流とはいってもオブジェクト指向開発って
結局業務分析から扱うデータ抽出して、その関連を定義して、CRUD操作するんだろ？
それが実装に落ちると基本的にはデータ構造は変わらないが、
実装方法としてて、オブジェクト指向プログラミングやデザインパターンがある。
それにの則った話に過ぎないと思うんだがどうか？
データ構造の抽出までは出来たが、OOPを理解してなくて単なるSQLでのDBへのCRUD操作、
複雑なSQLベースのシステムになる例が多すぎる訳で。
まぁあれだ。
オブジェクト指向で使われる用語は、
それなりに個々が学習しないと認識がずれる。
実装段階は言語規約（クラス、継承とか）を守る必要があるのでPGもそこは学習するが、
「考え方」の一つであるオブジェクト指向は個々の学習には期待できん。
オブジェクト指向で使われる用語は、
それなりに個々が学習しないと認識がずれる。
実装段階は言語規約（クラス、継承とか）を守る必要があるのでPGもそこは学習するが、
「考え方」の一つであるオブジェクト指向は個々の学習には期待できん。
>>964
おまぃ、いい奴だな。
おまぃ、いい奴だな。
ボクはね。こうおもうんだ。
この世からRDBMSとSQLが無くなればOOPを理解せざるを得ない。
どう？
この世からRDBMSとSQLが無くなればOOPを理解せざるを得ない。
どう？
ボクはね、こう思うんだ。
PG職、SE職は免許制。
PG職、SE職は免許制。
☆ ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ～
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 焼きビーフン設計まだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| スレタイ微 |／
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 焼きビーフン設計まだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| スレタイ微 |／
>>968
データの保存先なんて別にDBじゃなくてもいいでしょー？
ファイルでファイルシステムに保存したっていいし
XMLに保存してもいいじゃん。
OOPで考えればオブジェクトを長期保存できればDBなんて別にいらんのよ。
便利でアクセスが早いから使ってるだけ。
シムシティってゲームあるけど、DB使ってるか？
メモリ状態をそのままスナップショットとってRAMに入れて永続化してるだけでしょ？
警察署オブジェクトが建物テーブルに格納されているか？
データの保存先なんて別にDBじゃなくてもいいでしょー？
ファイルでファイルシステムに保存したっていいし
XMLに保存してもいいじゃん。
OOPで考えればオブジェクトを長期保存できればDBなんて別にいらんのよ。
便利でアクセスが早いから使ってるだけ。
シムシティってゲームあるけど、DB使ってるか？
メモリ状態をそのままスナップショットとってRAMに入れて永続化してるだけでしょ？
警察署オブジェクトが建物テーブルに格納されているか？
＿∧＿∧＿∧＿
☆ ﾊﾟﾘﾝ 〃 ∧＿∧ |
ヽ ＿, ＿＼（・∀・ ） ＜ マ
＼乂／⊂ ⊂ ) ＿ |＿ ＿ ＿ ＿＿
／￣￣￣￣￣￣￣／| . ∨ ∨ ∨
| ￣ ￣￣￣￣￣￣:| :|
| .|／
＿ _＿_
＼>,＼／
＜⌒／ヽ-、_ ＿
＜_/＿＿＿＿ノ
☆ ﾊﾟﾘﾝ 〃 ∧＿∧ |
ヽ ＿, ＿＼（・∀・ ） ＜ マ
＼乂／⊂ ⊂ ) ＿ |＿ ＿ ＿ ＿＿
／￣￣￣￣￣￣￣／| . ∨ ∨ ∨
| ￣ ￣￣￣￣￣￣:| :|
| .|／
＿ _＿_
＼>,＼／
＜⌒／ヽ-、_ ＿
＜_/＿＿＿＿ノ
>>972
まぁ、情報処理技術者資格に当てはめるかどうかは別の話として、
学習する奴・しない奴の選別の材料ぐらいはほしいんだよな。
オープンソースなんて出来ない奴を排除してるから、
評価されるものが出来てるわけで。
まぁ、情報処理技術者資格に当てはめるかどうかは別の話として、
学習する奴・しない奴の選別の材料ぐらいはほしいんだよな。
オープンソースなんて出来ない奴を排除してるから、
評価されるものが出来てるわけで。
>>971
データが格納されてると考える限り、RAMに有ろうがファイルに有ろうが
どうやっても、例のトランザクションコードになるように思えるのだが
ファイルからデータを呼び出して書き込む（ｒｙ
ってコードになると思うぞ。
データが格納されてると考える限り、RAMに有ろうがファイルに有ろうが
どうやっても、例のトランザクションコードになるように思えるのだが
ファイルからデータを呼び出して書き込む（ｒｙ
ってコードになると思うぞ。
そこは基本的に同じだよ。
問題はSQLクエリの便利さにOOPの良さが消されちゃってるってこと。
SQLではオブジェクト上でも、関連のないデータも結合して取ってこれちゃうからね。
問題はSQLクエリの便利さにOOPの良さが消されちゃってるってこと。
SQLではオブジェクト上でも、関連のないデータも結合して取ってこれちゃうからね。
いきなり2つのファイル内のこの属性を結合してマッチしたファイルを取得するなんてファイルシステムじゃ出来ないでしょ？
OOPなら、個々のファイルをインスタンス化すれば関連を使って辿れるんだよ。
OOPなら、個々のファイルをインスタンス化すれば関連を使って辿れるんだよ。
つ ORM
そうか、クラスの関連無視してデータ取れたり計算できるところが
クラスをただのデータを入れる箱にしている根本原因てことか。
クラスをただのデータを入れる箱にしている根本原因てことか。
>>977
おまぃ、説明うまぃな
おまぃ、説明うまぃな
>>976
なるほど、そういう意味か。
それなら、それが悪いかどうかは、かなり微妙なんじゃないか？
俺らはOOを生かす事が目的じゃなくて、
総合的になるだけ楽な設計・実装をするのが目的だから、
便利なら、RDBMSを使うべきだ。
なるほど、そういう意味か。
それなら、それが悪いかどうかは、かなり微妙なんじゃないか？
俺らはOOを生かす事が目的じゃなくて、
総合的になるだけ楽な設計・実装をするのが目的だから、
便利なら、RDBMSを使うべきだ。
☆ ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ～
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 新ｽﾚまだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| カプセル化 |／
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 新ｽﾚまだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| カプセル化 |／
―――――――――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ | ☆／
| | ∧＿∧ | | ﾁﾝﾁﾝうっせーんだよ ｺﾞﾙｧ！ :|＼ ＼∧＿∧
| | （# ´Д｀）| | | ＼ （；´Д｀）○
| |⌒ て) 人 ／￣ ＼ : ＼￣￣／| ○
| |（ ___三ﾜ ＜ ＞ ＝＝＝＝≡≡≡三三三三:|￣￣￣￣￣￣￣ :| :|
| | ) ） | ∨ | カプセル化 :|／
￣￣￣￣'￣￣￣￣ |
|
＿＿＿＿.＿＿＿＿ | ☆／
| | ∧＿∧ | | ﾁﾝﾁﾝうっせーんだよ ｺﾞﾙｧ！ :|＼ ＼∧＿∧
| | （# ´Д｀）| | | ＼ （；´Д｀）○
| |⌒ て) 人 ／￣ ＼ : ＼￣￣／| ○
| |（ ___三ﾜ ＜ ＞ ＝＝＝＝≡≡≡三三三三:|￣￣￣￣￣￣￣ :| :|
| | ) ） | ∨ | カプセル化 :|／
￣￣￣￣'￣￣￣￣ |
ﾁﾝ ☆ ﾁﾝ ☆
ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ～ ﾁﾝ ♪
♪
♪ ☆ﾁﾝ .☆ ｼﾞｬｰﾝ！ ﾏﾁｸﾀﾋﾞﾚﾀ～!
☆ ﾁﾝ 〃 ∧＿∧ ヽ ／￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（・∀・ #） ／＼＿／ ＜ まだー？
ﾁﾝ ＼＿／⊂ つ ∥ ＼＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／| ∥ ﾏﾁｸﾀﾋﾞﾚﾀ～!
| ￣ ￣￣￣￣￣￣:| :| ／|＼
| |／
ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ～ ﾁﾝ ♪
♪
♪ ☆ﾁﾝ .☆ ｼﾞｬｰﾝ！ ﾏﾁｸﾀﾋﾞﾚﾀ～!
☆ ﾁﾝ 〃 ∧＿∧ ヽ ／￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（・∀・ #） ／＼＿／ ＜ まだー？
ﾁﾝ ＼＿／⊂ つ ∥ ＼＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣￣／| ∥ ﾏﾁｸﾀﾋﾞﾚﾀ～!
| ￣ ￣￣￣￣￣￣:| :| ／|＼
| |／
外的な品質（顧客に対する品質）と内的な品質（開発者にとっての品質）を別々に
考えて議論できないものだろうか？
考えて議論できないものだろうか？
開発中にもコロコロ仕様が変わり根本から考え直す必要がしょっちゅう
出てくる現状で内的な品質向上なんて無理。
営業が顧客満足しか考えてないからね、メンテナンス無視した一時的な
満足度しか上げられない。
出てくる現状で内的な品質向上なんて無理。
営業が顧客満足しか考えてないからね、メンテナンス無視した一時的な
満足度しか上げられない。
論外。それは
コストとスケジュールの見直しのない仕様変更を
受け入れるような組織／プロジェクトが元凶なのだ。
>>986
各種品質特性を二分して別個に考えることに意味があるとは思えない。
そう思わないなら、その利点／意味を提示してみて欲しい
コストとスケジュールの見直しのない仕様変更を
受け入れるような組織／プロジェクトが元凶なのだ。
>>986
各種品質特性を二分して別個に考えることに意味があるとは思えない。
そう思わないなら、その利点／意味を提示してみて欲しい
梅
991 ：仕様書無しさん：2007/02/18(日) 23:47:14
みんな暇ね～☆
いや、ハングル語や広東語を交えて書かれると
解読不能だよ！
きちんと日本語使って欲しいな！
解読不能だよ！
きちんと日本語使って欲しいな！
993 ：仕様書無しさん：2007/02/20(火) 00:33:56
OO厨 兄ｗ
994 ：仕様書無しさん：2007/02/20(火) 01:07:52
体調が悪いので休ませてください・・・
↑嘘つくな！
昨日終電で・・・
↑昼から来てたくせに何言ってんだよ！
↑嘘つくな！
昨日終電で・・・
↑昼から来てたくせに何言ってんだよ！
1000ならBoehm GCをインストールして使ってみる
997
998
999
1000なら俺はオブジェクト神になれる。
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。