2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

●●オブジェクト設計は何故流行らないの?●●02

1 :仕様書無しさん:2007/01/24(水) 01:37:40
☆☆前スレ☆☆
http://pc10.2ch.net/test/read.cgi/prog/1167841734/

2 :仕様書無しさん:2007/01/24(水) 01:51:18


コテ禁止



3 :仕様書無しさん:2007/01/24(水) 06:14:04
PEとかELFとかMach-Oに代わるものを設計するのか。
そりゃ流行らないだろうな。

4 :仕様書無しさん:2007/01/24(水) 12:04:04
機能単位じゃなくてオブジェクト単位で設計書書くと
「で、結局何ができるようになってるんだよ」というツッコミが
クライアントからくるからではないだろうか。

5 :仕様書無しさん:2007/01/24(水) 12:08:52
そこでユースケースですよ

6 :仕様書無しさん:2007/01/24(水) 15:48:38
ユースケースは、開発を通じて重要と言われているが、重要どころか
なくても言いと思う。
構造化設計で使われたDFDで十分だと思うべな。
DFDは、とってもわかりやすい。
構造化だ、オブジェクト指向だに関係なく普遍的にDFDマンセーでーす。

7 :仕様書無しさん:2007/01/24(水) 15:58:10
>>6
タイミングがシビアなシステムを設計したことないの?

8 :仕様書無しさん:2007/01/24(水) 16:06:42
>7
タイミングがシビアなシステムでユースケースをどうつかうの?
性能要求は機能外仕様なのでモロにユースケースの適用外だと思うけど。


9 :仕様書無しさん:2007/01/24(水) 16:07:50
タイミングと応答速度を混同しとる奴がいるな。

10 :仕様書無しさん:2007/01/24(水) 16:55:03
オブジェクト指向厨

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
タイミングはシーケンス図で書くもんだと思っていたが。。。

12 :7:2007/01/24(水) 17:03:20
俺もそう思う。

13 :仕様書無しさん:2007/01/24(水) 17:14:56
UML2.0ではタイミング図っていうのも一応あるぞ。
マイナーだし、シーケンス図で記述するタイミングとは
別のタイミングを記述するものだが。


14 :仕様書無しさん :2007/01/24(水) 18:58:37
結局おまえらUMLすら使えない
何もわからない人達なんだな

スレ削除しろ

15 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/24(水) 20:09:08
「データーを圧縮する一般的な方法は存在しない」
集合論で考えるとすぐ判る、数学の初歩だ。

さて、頭を数学的にきりかえて、ソフトウエア工学の問題点を指摘してみよう。

「ソフトウエアの設計の情報量はそれから作られるソースの情報量と等しいかそれよりも大きい」(ココ電球の定理)

なので設計とコーディングを分離する手法はうまく行かないのだ。
完全な設計とコーディングを分離すると重複作業が生じた上、コンパイルして実行したほうが早い物をわさわさ紙の上で何百倍もの時間をかけて
検証する事になってしまいコスト高である。
不完全な設計がまかり通るのはこれも原因だろうが
根本的な原因は工学一般の手法をそのままソフトウエアに持ってきてしまった事にある。


16 :仕様書無しさん:2007/01/24(水) 20:09:54
>>6
ユースケースってお客と話するときは結構便利かと思うが

17 :仕様書無しさん:2007/01/24(水) 20:41:51
DFDは設計を表現するモデルで、ユースケースは機能を表現するモデルです。プロセス中心でソフトウェアを分解する場合にはとてもわかりやすく有用なモデルですが、ユースケースの代用にはなりません。

18 :仕様書無しさん:2007/01/24(水) 20:52:08
工学一般の手法を、、、に同意

19 :仕様書無しさん:2007/01/24(水) 21:04:49
サンとインテルが手を組むのはJava派には朗報か?
Javaというとオブジェクト指向、オブジェクト指向というとJavaなので、
これでオブジェクト設計が普及するぞ。

20 :Six Perfections:2007/01/24(水) 21:09:57 ?2BP(0)
http://cocoa.gazo-ch.net/bbs/45/img/200701/1201505.jpg
http://pc10.2ch.net/test/read.cgi/tech/1169640060/


21 :仕様書無しさん:2007/01/24(水) 21:57:16
>>19
http://jp.sun.com/company/Press/release/2007/0123.html
これを読む限りオブジェクト開発ツールには何も触れていないね。

22 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/24(水) 22:11:02
普及すると給料下がるよ

23 :仕様書無しさん:2007/01/24(水) 22:25:59
>>22

無能の場合ね。

24 :仕様書無しさん:2007/01/24(水) 22:46:07
そんなことより、前スレからの流れで
「オブジェクト指向とは何か?」でもやれば?

25 :仕様書無しさん:2007/01/24(水) 22:56:34
>>24
オブジェクト指向含むソフトウエア関連って実学っしょ。哲学or宗教論争イラネ。


26 :仕様書無しさん:2007/01/24(水) 23:08:14
>>25
それを言ったら始まらない。
宗教論争が不毛なのは同意だが、そこに何らかの結論を
出して行かないと世の中は進んで行かないのよ。

27 :仕様書無しさん:2007/01/24(水) 23:27:10
>>15
相手にされてないコテにレスするのも何だが
設計・分析もコーディングも自分で出来るレベルの人間なら
判ってるハズだ。優秀なPGほど、設計・分析の段階での
消費時間が多くなる。逆にコーディングの時間は減っていく。
そして、最終的に違ってくるのはデバッグ期間。

キチンと設計できる人間は既にそのままコーディングできるのが
当たり前だからな。人に任せるより自分で書いた方が早いんだけど
全部自分でやるわけにはいかないから、実装チームに任せる。
一人開発に慣れてると、どうにもならなくなるよ?

28 :仕様書無しさん:2007/01/24(水) 23:27:20
>>26
もう結論は出てるよ。
でも、エライ人には、それが分からんのです。ってだけじゃないの?

29 :仕様書無しさん:2007/01/24(水) 23:34:25
>>28
それじゃ終わっちゃうじゃないか!w
諦めるんじゃない!

30 :仕様書無しさん:2007/01/24(水) 23:35:46
>>15
最後の一文は同意。

31 :仕様書無しさん:2007/01/24(水) 23:43:00
ひまならこれでもよんどけ。

ttp://d.hatena.ne.jp/squeaker/20070123#p1

32 :仕様書無しさん:2007/01/24(水) 23:44:41
なんかコテの意見に追従するのが癪だが。

開発工程が(詳細)設計とコーディングに分かれているのは、
太古の昔にリソースが高価で使用するのに神に謁見するように
扱われていた名残に過ぎないと思う。

従って、現代は詳細レベルの仕様書作成とコーディングが並列する必然性はないと思う。
PCのリソース使って仕様書つくって、IDEでコーディングしているのはなんとも意味ない。

クラスのコード書いた奴がJava.docみたいなのを一緒においていけばそれでよし。

このスレでいう設計は実現機能の合意文書ってレベルのものじゃないか?

33 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/24(水) 23:55:28
2000年から議論してて一向に話が進んでないけどな

34 :仕様書無しさん:2007/01/24(水) 23:57:31
>>32
PGが育ってSEになるからだとおもうよw

この流れで人が成長しベテラン扱いされると、
コードの組み方が真逆になるOOPに思考切り替えるのは無理。

35 :仕様書無しさん:2007/01/25(木) 00:00:36
>>27
>優秀なPGほど、設計・分析の段階での 
>消費時間が多くなる。逆にコーディングの時間は減っていく。 
>そして、最終的に違ってくるのはデバッグ期間。 

いまだにそんな「都市伝説」を信じている奴がいるとは・・・
この世には、殆ど設計書を書かない
「オープンソース」なんてものがあるという現実は、
>>27 の頭の中では、どう整理されているんだろうか?

もしかして、
「きっと、彼らは優秀だから "頭の中" だけで設計出来るんだよ。
俺ら凡人には真似ができないけどさ・・・」なんて感じ?


36 :仕様書無しさん:2007/01/25(木) 00:03:31
>>34
そんなことはPGに任せておけばいいのにというような
詳細レベルの仕様書はワンサカ作ってるだけのSEがいるな。w

// コーディングに限らず、NEなんかでも、
// 必死にIPアドレスの付番だけに躍起なる奴もいる。


確かにコードの組み方がマ逆^H^H真逆か・・・

37 :仕様書無しさん:2007/01/25(木) 00:27:53
まあ下書き無しで描いてる漫画家とかいるけどね。
そういう人を引き合いに出すのはどうかと。
設計ちゃんとやった方がいいと思うけどな。
コード描けない奴が無駄に豪華なドキュメント描いてるのは無駄だが。
Linux作った奴の使ってる手法なんて、あのレベルの人間だから有効な方法だと思うよ。

38 :仕様書無しさん:2007/01/25(木) 00:31:05
オープンソースなんて図抜けて優秀な連中が、膨大な時間かけて論議と試行錯誤を繰り返して作ってるんだよ。
同じだけの知能も時間もないんだから、凡人はダメなりにでも
がんばってしっかり設計すべきだと思うね。
コーディングとデバッグ、テスト、運用、保守、バージョンアップ、とか
設計がしっかりしてないとどんどん壊れていって、収集つかなくなるし。
それが不要って思うのは、単に設計できてないだけかと。

39 :仕様書無しさん:2007/01/25(木) 00:35:30
>>38
>オープンソースなんて図抜けて優秀な連中が、
>膨大な時間かけて論議と試行錯誤を繰り返して作ってるんだよ。

図抜けて優秀な連中でさえ、試行錯誤を繰り返すのに、
なぜか凡人は、最初の設計だけに時間を掛ければ、
後のコーディングはサラサラって感じで出来るよ、
って言いたいの?。


40 :仕様書無しさん:2007/01/25(木) 00:35:51
日本のプログラマの大半は料理人で言えばファーストフード店の厨房係レベルってこったね

41 :仕様書無しさん:2007/01/25(木) 00:36:55
単なる関数の塊みたいなクラス作ってる奴みると、
ちょっとは考えろと思う。
表に出てこない分には好きにしてくれだが。
こういう子にはOOP/OODは無理だなぁと判断してしまう。

42 :仕様書無しさん:2007/01/25(木) 00:38:15
凡人が設計工程だけやってて十分な設計が出来るわけが無い。
凡人なら設計が正しいかどうか検証するために実装してテストして、
そこからフィードバックを得なきゃならんの。

っつーかオブジェクト指向関係無い話になってるし。

43 :仕様書無しさん:2007/01/25(木) 00:38:30
>>39
サラサラ出来るってどこに書いてあるか教えてくれるかな?

44 :仕様書無しさん:2007/01/25(木) 00:40:05
>>40
日本に限らずじゃないかな。
日本は環境整ってて、いま景気いいから、なおさら平均レベルは下がってるだろうけど。
30歳未経験からOKなんて所もあるし。

>>41
経験にもよるだろ。

45 :仕様書無しさん:2007/01/25(木) 00:41:22
プログラムと等価な詳細設計をOODできるのは当然のことなので、
基本設計をOODする場合を考えよう。

46 :仕様書無しさん:2007/01/25(木) 03:27:34
>>35
オープンソースがほとんど設計書書かないって何それ?
「設計書」という形がないと設計がないと思う方がおかしい。

47 :仕様書無しさん:2007/01/25(木) 06:56:37
>>27
>優秀なPGほど、設計・分析の段階での
>消費時間が多くなる。逆にコーディングの時間は減っていく。
>そして、最終的に違ってくるのはデバッグ期間。
それが本当にそうか証明できないよね?

48 :仕様書無しさん:2007/01/25(木) 07:02:41
「優秀なPGは・・・」ではなくて、
無能なPGは行き当たりばったりでコードを書いて行き詰まるが、
そうでない奴にはそれがない。
という程度のことでは?

49 :仕様書無しさん:2007/01/25(木) 08:14:45
>>27
この書き込みは、絶対的に正しい。
禿しく同意の意を示したい。

50 :仕様書無しさん:2007/01/25(木) 08:41:07
>>49
1人設計になれてると、機能分業開発に出会った時どうにもならなくなる。

51 :仕様書無しさん:2007/01/25(木) 08:55:31
そこで口頭仕様ですよ

52 :仕様書無しさん:2007/01/25(木) 08:59:29
ボイスレコーダー用意!

53 :仕様書無しさん:2007/01/25(木) 09:02:11
もともと思いつきを口に出してるだけなので
聞き返す間も無く(口頭)仕様変更がおんどれらを襲う

54 :おじゃばさま:2007/01/25(木) 09:26:40
>27
仮に優秀な設計者なら正しく設計して、コーディング時間もテスト時間も短縮出来るとしよう。
では優秀でない設計者の場合はどうすればいいのだろう?
大人数のプロジェクトをやるなら、優秀でない人も出来る方式でなければならないのではないだろうか?
一人で開発するなら別だが。

また優秀な設計者は、設計のみを繰り返していても優秀なままでいられるのだろうか?
27の理論を実践していると、設計者は設計のみを行い、コーディング/テストに関わらなくなる。
もしそれでも優秀さを維持出来るとしたら、世の中はコボル時代から現在までの大量の優秀な設計者で
溢れているのではないだろうか?
もし優秀さを維持出来ないとしたら、優秀だったとしてもそれを維持出来ないため、
優秀になりたての人しか正しく設計出来ないことになる。
つまり27の論理で成功するのは、ほんの一部のプロジェクトになってしまうのではないだろうか?


55 :仕様書無しさん:2007/01/25(木) 09:41:43
>>27
要するに設計に長く時間を使っちゃいましたけど、
コーディングはすぐ終わりました。
って事?

俺は試作プロジェクトくらいしか
思いあたらないな。

56 :仕様書無しさん:2007/01/25(木) 10:45:17
>>14
UMLは設計文書の共通書式だぞ。

UML自体は道具ではない。
従来バラバラだったり我流だった書式を統一して、他の人にも読みやすくするのが目的だ。

UMLに適切なものがなければ、独自の書式でも構わない。
なにも、不適切なほうに合せる必要はないんだよ。

UMLを使えば設計が上手にできるなんて思っている連中には理解できないことだが。

57 :仕様書無しさん:2007/01/25(木) 11:08:00
>>50
>>27
>キチンと設計できる人間は既にそのままコーディングできるのが
>当たり前だからな。
とも書いている。
つまり、設計ばかりしてたのではなく、PGもやってたということ。

58 :仕様書無しさん:2007/01/25(木) 11:11:36
>>35
オープンソースは設計書を書かないのではない。
ソースはオープンだが設計書はクローズド。

オープンソースのプロジェクトの大半は、たった一人で、もしくはチームで分担してコードを書いていて、
他の人達がコードに手を入れるといっても、バグの修正や、細かい部分の改良でしかない。



59 :仕様書無しさん:2007/01/25(木) 11:15:08
UMLの全部を使う必要はない。
大概の技術書も、UMLのクラス図とシーケンス図しか使ってない。
これで十分でしょ。

>従来バラバラだったり我流だった書式を統一して、他の人にも読みやすくするのが目的だ。
クラス図とシーケンス図はこの目的のために使いましょう。

>UMLに適切なものがなければ、独自の書式でも構わない。
>なにも、不適切なほうに合せる必要はないんだよ。
独自の書式は賛成できない。
それがいいものなら、世に広めほしい。

60 :仕様書無しさん:2007/01/25(木) 12:47:19
>>54
大規模なプロジェクトを優秀でない設計者に設計させる時点で
終わってないか?

設計しかしなくなったとしても、プログラミング自体が趣味で
仕事とは関係なくコーディングする奴もそれなりにいると思うけど。
それに大手は知らないけど、ちょっとしたツールやコンバータが
必要になったら自分でちゃちゃっと書いちゃわないか?
コーディングする機会なんていくらでもあると思うが…

61 :仕様書無しさん:2007/01/25(木) 13:21:34
>>59
> 独自の書式は賛成できない。
> それがいいものなら、世に広めほしい。

何にでも使える「万能ナイフ」よりも、
特定の狭い応用領域に最適化されたものを
選んだほうが良い結果になることもある、ということだよ。

>>60
仕事で設計したものを実装するためのコードと、
趣味のコードや自分でちゃっちゃと書くコードは、
かなり違うと思うのですが、どうでしょう。

趣味のプログラミング歴10年とかいう新人を想像してみてよ。

62 :仕様書無しさん:2007/01/25(木) 13:27:30
全然関係ないけど、日本の大抵のプロジェクトは優秀でない設計者(SE)で溢れてるよな
SEって言葉自体何なんだ?Business Analysts?Software Analyst?Consultant?

63 :仕様書無しさん:2007/01/25(木) 13:30:41
>>62
日本のSE=Documentation Writer
AnalystやConsultantなんて一部にしかいない
海外じゃゴミ

64 :仕様書無しさん:2007/01/25(木) 17:05:28
>27
設計が良ければたしかにコーディング期間は短くなるだろう。

言葉の上ではたしかにそうだが、
コーディング期間を短くした割合と比較しての効果を考えると
途端に嘘くさくなる。

まずその部分を論理的に証明できないと、
都市伝説と言われても仕方ないな。

仮に、コーディングと設計を完全に分けれたらの話だけどな。



65 :仕様書無しさん:2007/01/25(木) 17:08:43
逆に、コーディングと設計を分けられないってのは何だ?
スパイラルとかしてるからOKだと思ってるんかい?


66 :仕様書無しさん:2007/01/25(木) 17:23:23
>65
言葉の上では必ず分けられる。

実際でも、要求仕様が確定していれば
先に設計を済ましてからコーディングの形でも可能だろう。

しかし、現実にそんなプロジェクトは
ほとんどないだろ。
つまり、そういうこと。



67 :仕様書無しさん:2007/01/25(木) 17:29:23
現実ないわけではない、貴方が知らないだけ。
設計レビュー絶対のところは幾らでもあるわけで。


68 :仕様書無しさん:2007/01/25(木) 17:37:25
最初から完璧な設計を仕上げるのは不可能だけど、本コーディング前に
時間をかけてある程度の見通しを付ける作業は無駄にはならないよっていう
ごく当たり前の話なのに、オマイラはなんでそんなに突っかかるんだ?

69 :仕様書無しさん:2007/01/25(木) 18:39:47
口頭仕様とノリだけでいままでやってきたからじゃないの

70 :仕様書無しさん:2007/01/25(木) 18:42:35
>68
決め付ける様な類の話は
デマか若しくは間違いを多く含んだ
悪質な話の事が多い。

って事は経験から学んだな、俺は。

あと、現実に役に立たない類の青臭い話も
俺はあまり好きじゃないかな。



71 :おじゃばさま:2007/01/25(木) 18:53:14
>60
俺の記述が悪かった。
優秀でないと言うより「普通の設計者」でも、安心して設計出来る必要があると言う事だ。
またコーディングついてだが、第一に自分の設計した業務に対するコーディングでないと意味がない。
第二に機会があるかないか不確定な要素を頼りにするのは、仕事としては危険である。

>68
時間を掛けて見通しをつける作業が無駄だと思っている。
なぜアタリマエなのか理由を知りたい。


72 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/25(木) 19:07:49
Javaを売り物にしている上場企業の社長の話だが
俺がフレームワークのインターフェース先に決めて分業しようとしたら、その社長

「中はどうなってるんだ」
「インターフェースだから中身はありません それぞれの担当者が決めるのです」

といったんだか、その社長、インターフェースの概念を理解できなくて「中身を作れ」
という無理な命令が飛んできて、そのままフィロソフィーもなくだらだらと中身を作って失敗した例をあげておこう。
偉い人が馬鹿だとどうしようもない。


73 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/25(木) 19:12:12
今まで見た自称「俺は設計できる」ってやつが大抵そんなんだった。

74 :仕様書無しさん:2007/01/25(木) 19:17:56
いい加減コテどもは消えてくれ

75 :おじゃばさま:2007/01/25(木) 19:20:24
設計の話になると必ず出て来るUML。しかしこれが成功しているとは、お世辞にも言い難い。
ユースケース図は子供の落書きと馬鹿にされ、クラス図はほとんどがソースからの自動生成。
その他の大量の書式は、UML入門書でしか使われず、辛うじてシーケンス図が使われる程度である。

元々、UMLの目的はプログラムを図表化事にある。
UMLが出初めの頃、ユースケース図、シーケンス図、クラス図、その他いくつかの表を使って
設計した事がある。しかし実際に設計してみて、なにかピンと来ない。
理由は1つのプログラムでも、UMLの書式は目的によって複数あるため、表現しきれないからだった。
UMLの特徴として、使いにくければ勝手に書式を作り、UMLだと言い張って良いと言うルールがある。
そこで既存のフォーマットにとらわれず、自由に書いてみる事にした。
その時は数人の設計者がいたので、それぞれ自由に書いてみることにした。
当然、内容はバラバラになった。
興味深いのは、それぞれは自分の設計書は見やすいと思っているが、他人の設計書は
確かにそれなりにいいと思うが、なにかが足りないと感じていた事だ。
つまり人によって重視するポイントが違うため、他人とはどこかが違うと感じるようだった。
そこて、重視するポイントを明確にしてやってみた。
ところがそれでも失敗した。


76 :仕様書無しさん:2007/01/25(木) 19:24:19
OSカーネル 非OO
ドライバ 非OO
カリカリミドル 非OO

業務アプリ 糞OO とろーりもっさりどろどろどろろろろろ

77 :仕様書無しさん:2007/01/25(木) 19:37:14
シーケンス図とクラス図くらいしか使ったこと無いよ。
ユースケースなんて見たことも無い。
しかしUMLうんぬん言う前に要件定義はきっちり済んでるのか?!
後から前提条件ひっくり返されたらどんな設計やってても意味が無い。
それにUMLで設計できる(または読める)ような人は、機能仕様から
ごりごりクラス作ってったほうが早いんじゃ無かろうか?


78 :おじゃばさま:2007/01/25(木) 19:40:25
出来た仕様書はどこかがイメージと違う。みんながそんな意見だった。
ではプログラミングのイメージとは何か?それを考えてみた。
俺は寝ている時や、考え事をしている時に、ふとプログラムを思いつく事がある。
そういう時には妙な図形としてイメージが浮かぶ。たとえば翼を広げた鳥のような形などだ。
通常意識してプログラミングしている時には、ソースコードとして思いつくプログラムだが、
無意識の時、つまりソースコードになる前には、俺は妙な図形として意識しているのかもしれないと思った。
そこで、先程書いたみんなのオリジナルUMLを見てみた。
そう、これが脳の中のプログラムイメージなのだ。
まさに千差万別。文字ベースもあれば、カラフルな図形もある。
吹き出しが大量に記述されたマンガのような物もあれば、線ばかりの水道管設計図のようなものもある。
つまり、人の脳内のプログラムは千差万別で、統一出来ないと言う事だった。


79 :仕様書無しさん:2007/01/25(木) 21:18:00
>>78
ほんで?UMLイラネってことか?

80 :仕様書無しさん:2007/01/25(木) 21:21:48
>>75
いーじゃねーかよ。シーケンス図は重宝してんだ。文句あるか。

>>77
ユースケースはやめとけ時間の無駄だ。


81 :仕様書無しさん:2007/01/25(木) 21:27:45
オブジェト設計が流行らない理由
1)クラス図、シーケンス図までかけるSEが少ない。
2)クラス図、シーケンス図を理解できるプログラマーが皆無に近い。
3)根本的にオブジェクト設計の重要なポイントを理解している者自体が少ない。
4)教育のための時間が、個人的にも、企業的にもない。
5)したがって、オブジェクト設計の利用価値を知らないわけですから、別に使う気にならない。
異常じゃない、以上。乙彼!!

82 :仕様書無しさん:2007/01/25(木) 21:29:38
>>81
goto >>1 ;

83 :仕様書無しさん:2007/01/25(木) 21:33:50
設計時にシーケンス図書くのは時間の無駄だろ。

84 :仕様書無しさん:2007/01/25(木) 21:37:00
>>83
PG設計という時間のときに、SEかPGが作る。


85 :仕様書無しさん:2007/01/25(木) 21:39:55
>>84
なんか役にたつ?

86 :仕様書無しさん:2007/01/25(木) 21:45:17
フローチャート最強だろ、これを描かないPGいないだろ
いつも脳内で描いてるだろ、も ま え ら、ネ

87 :仕様書無しさん:2007/01/25(木) 21:50:09
>>85
クラス図とシーケンス図であっという間にすばらしい実装が実現する。
な に か ?

88 :仕様書無しさん:2007/01/25(木) 21:51:49
フローチャートなんぞプログラミング言語で記述すりゃええ

void function() {
doHoge();
doHage();
while(true) {
doHagege() ;
}
}

妙な図を使って書くより何をやってるかよくわかるってもんだろ。

89 :仕様書無しさん:2007/01/25(木) 21:54:04
シーケンス図とかフローチャート書くより、コード書いたほうが速いし。

90 :仕様書無しさん:2007/01/25(木) 21:54:55
>>87
そして、ユースケースで確認すればプログラム完了、めでたし、めでたし

91 :仕様書無しさん:2007/01/25(木) 21:55:55
ユースケースドリブンってくらいだから、ユースケースの方が先だr

92 :仕様書無しさん:2007/01/25(木) 21:59:11
しかしなんでお前らはUMLとかの単なる表記法がそんなに大好きなのかね。
オブジェクト指向とは何かってことを正しく理解して、
オブジェクト指向の利点を正しく扱えるようになることを目指すほうが重要じゃないか?

93 :仕様書無しさん:2007/01/25(木) 22:02:54
>>92
タイピングばかりしてると、お絵かきって楽しいんだよな、
なかなかかっこよく描けたりすると嬉しいものです

94 :仕様書無しさん:2007/01/25(木) 22:03:22
>UMLとかの単なる表記法がそんなに大好き

好きな奴がいなそうに見えるが。

95 :仕様書無しさん:2007/01/25(木) 22:16:16
>>92
それを正しく表現する技法が必要でしょう。
UMLはそのために向いていると言われているんです。

96 :仕様書無しさん:2007/01/25(木) 22:19:40
うちの会社じゃみんなUMLの本を片手に設計やってるが、
オブジェクト指向をわかってないからとんでもない事態になってるぞ。
あれでプログラム書かされる奴がかわいそうだ。

97 :仕様書無しさん:2007/01/25(木) 22:24:17
>>96
そりゃそうだろう。
そりゃ、ぜひ、オブジェクト指向をわかってから使うよう警告か指導を与えてください。

98 :仕様書無しさん:2007/01/25(木) 22:27:53
>>97
>オブジェクト指向をわかってから使う
使わないとわからない、と思う。。

99 :仕様書無しさん:2007/01/25(木) 22:31:57
まるで珍問答みたいだな
こりゃダメだ

100 :仕様書無しさん:2007/01/25(木) 22:35:09
>>61,71
趣味のコーディングだろうが、長い目で見れば役に立たないことは
ないよ。むしろ業務だけでしかコーディングしてないと幅がなくなる。

俺は一応15年以上キャリアあるおっさんだけど、単に遊びで作った
ようなものが活きてくるなんてことはいくらでもあるよ。
ネットワークシステムとかシミュレーションとか。もちろんすぐに
効いてくるようなもんじゃないけどね。

>>64
完全に分けるとか、そんなことの前に自分で試せば判ることでしょ。
自分の研究時間にでも1人で設計からコーディングまでできる規模の
テーマ決めて、通常自分がコーディングにかけてきた時間の何割かを
回して作って見ればいい。

それでも全体としての効果は薄いと判断するなら、君にとっては
都市伝説だと判断すればいいだろ。

101 :仕様書無しさん:2007/01/25(木) 22:41:24
>>96-97
if(96->UMLの本を片手に設計) // 常にTRUE
SendMessage(96, WM_警告指導,オブジェクト指向を理解汁, 0);


102 :仕様書無しさん:2007/01/25(木) 22:44:05
>>101
レシーバーがないから無理w

103 :仕様書無しさん:2007/01/25(木) 22:46:54
IBMの人は、オブジェクト設計をRational(?)でバリバリですか?

104 :仕様書無しさん:2007/01/25(木) 22:51:54
IBMだけどEAつかってます

105 :仕様書無しさん:2007/01/26(金) 00:40:45
>100
別スレができたみたいだな。
まず、そっちで説得してみせてくれ。



106 :仕様書無しさん:2007/01/26(金) 01:00:33
>>105
別に説得するつもりなんかないが?
最初から「試す必要もない」と思ってる人間を説得することに
意味があるか?自分の部下なら別だけどな

107 :仕様書無しさん:2007/01/26(金) 01:25:43
ていうかさ、ここに来るOODやってる人って実装上のアイデアで
少しトリッキーなクラス設計することとかないの?
いやダメかも知れんが、OSやハードの特殊性があるのが現状で、
サブセットなんていくらでもあるでしょ。

そういう時はその特殊性を活かせるように通常1つのクラスに
個別に置くようなものを横断的なクラス作ったりしない?
それはアスペクト志向だからって言われちゃうとそれまでだけどw

結果的に1つの特殊なクラスで隠蔽できればいいわけで、マルチ
プラットフォームで書いてるつもりが、パフォーマンスの問題とかで
その都度手直しするより上手く行くことって多いと思うんだが…

108 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/27(土) 05:46:46
>>98
わかってたら使わないと思う

109 :仕様書無しさん:2007/01/27(土) 06:07:33
氏ね屑コテ

110 :仕様書無しさん:2007/01/27(土) 09:10:26
このスレの特徴
Javaが好き(当然業務開発オンリー)

OOPが好き(つうかJavaやってます「エヘン」とえばれる唯一の砦)

すこし経験つんだ(フレームワークの隙間コードとSQLから取得したコードの代入ばかりだが)

設計について薀蓄したい(上昇志向はとりあえずある)

UMLはいいぞと思う(UMLの設計者は大規模な設計をやるには向かないと公言しているのを知らない)

大規模ビジネスロジックをなんでもかんでもUMLでやろうとする

破綻する

わけわかんなくなる

このスレが立った

111 :仕様書無しさん:2007/01/27(土) 11:30:09
経緯と特徴は同じですかい

112 :仕様書無しさん:2007/01/27(土) 12:36:30
>>64
設計が悪くてグダグダになるのは、コーディングよりも、その後のデバッグとか全体テストとか。
期間を延ばすのは、再設計か、悪い設計を誤魔化すための膨大なコードの追加とテストだから。

113 :仕様書無しさん:2007/01/27(土) 12:42:33
>>70
現実にそぐわない理想論だといって、
最初から合格点より下を(無意識に)狙う人達には、
現状を少しずつでも改善する気すらないということでウンザリする。

理想が見えていなければ、理想に向かって進むことはできない。
ほんの少しでいいから向上心を持って、より良い方向に少しずつ動くべきだよ。



114 :仕様書無しさん:2007/01/27(土) 12:45:09
>>72
トップダウンの構造化設計です、とかいって誤魔化せばよかったのに。

ヘタにクビを突っ込む偉い人には、現場レベルの話を正直にする必要は、ないかと。

115 :仕様書無しさん:2007/01/27(土) 13:46:00
>112
俺は再設計するのは全然問題ないと思っている。

時間の消費は
詳細まで設計を書面で叩いてからコーディング>コーディングしながら再設計
と俺は考えるから。

設計上の問題もコーディング上で浮上しやすいしな。

適当なコード書いて誤魔化すのは問題が多いけど、
有用な場合も少なからずあるからな。
大抵は時間が絡んでの事だけど。
いまどきはMSを含む大抵のメーカーが
してるんじゃないか。




116 :仕様書無しさん:2007/01/27(土) 14:02:50
>113
理想はあっても時間は限られている訳で。
理想と現実が離れていればいる程
現実との擦りあわせは考えないと駄目だろ。

パッチ当てたり、機能限定バージョンにしたりな。

完成型が決まっていたとしても
今どき普通に開発できるのは
よっぽど恵まれているか
ボランティアのところだけ。



117 :仕様書無しさん:2007/01/27(土) 14:26:01
>>116
>>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
誤爆

120 :仕様書無しさん:2007/01/27(土) 15:13:02
>117
それを言うなら
そもそも、理想を持ってないとか
合格点より下云々の話からすでに的外れだ。


121 :仕様書無しさん:2007/01/27(土) 15:19:12
ふじつうが、JavaでCOBOLプログラミングするから。

タコフレームワークを強要されて困ってまつ。
”やさしい”と言う名のフレームワークにはご用心。

122 :仕様書無しさん:2007/01/27(土) 15:27:19
>>120
>>113>>70がそういう奴だといってるわけではないでしょ

123 :仕様書無しさん:2007/01/27(土) 15:34:01
>>120
チーム内で相互にコードレビューさせてほしいと言っても、
コードレビューしないで糞コードを堆積させたほうが早いからダメ
なんていう上司がいるんですよ。

後で困らないコードを書く一人前よりも、
とにかく糞コードを大量生産する新人のほうが、
重宝されることもあるよね。

124 :仕様書無しさん:2007/01/27(土) 15:52:09
>122
アンカー付いてたから誤解した。
すんまそん。



125 :仕様書無しさん:2007/01/28(日) 00:57:31
>>118-119
わざとらしい。


126 :仕様書無しさん:2007/01/28(日) 03:35:51
何も悩んでないならいいんだよ。
結果残せるかどうかでしょ?それは一時的な無理とかじゃなくて…
OODでやろうがその結果が上手く行かなかったら、自分の設計が
ダメだっただけじゃないか。そうやって成長して行くんじゃないの?

理想的な設計を理論で学ぶのは重要だよ。でもその理論と現実の
整合性を取れない奴はチーム率いて行けないよな?
設計ってのはその後の開発工程のすべてを左右するんだからさ。

逆に現実との整合性ばかり考えてる奴はチームを成長させられ
ないでしょ?自分自身が仮にも掴んだと思えるOOをどう現実の
仕事に活かして行くかは、設計・分析段階ですべてが決まるとか、
逆にコーディングしなきゃ何も始まらない、とか単純に考えてる
ステレオタイプの思考してる人間には無理。

自分のステータスが重要ってだけでOOD絶対だの、その逆を
語る奴が多すぎると思うよ。

127 :仕様書無しさん:2007/01/28(日) 03:58:53
そういうどっち付かずで中身のない正論はこういうスレでは面白くないからいらない。

128 :仕様書無しさん:2007/01/28(日) 12:53:07
>>127
同意。
126の発言には発展性がないね

129 :仕様書無しさん:2007/01/28(日) 17:01:29
>127
同意。

受け取り方次第でどうとでも解釈できる文章なので
そもそも書き込み自体に意味がないな。

良さそうな事を言ってるだけに残念。



130 :仕様書無しさん:2007/01/28(日) 17:34:13
>126は相対的な視点で疑問形が多いのが残念
経験則のほうが説得力ある。少なくともこのスレでは。

131 :仕様書無しさん:2007/01/28(日) 23:01:03
設計の詰めの甘さを後悔して、次は失敗してたまるものかと思うからこそ、何かを求めるわけで。

132 :仕様書無しさん:2007/01/28(日) 23:18:48
理想ばっか言ったり現実ばっか言ってるより、両方の狭間で
苦しんでるやつのが発展性あると思われ

133 :仕様書無しさん:2007/01/29(月) 00:52:02
>>126に嫉妬

134 :おじゃばさま:2007/01/29(月) 10:27:06
>79
本来の使い方である「プログラムを図表化し、相手に伝えるためのUML」は不要だ。
しかし別の用途がある。
1.ドキュメント形式が決まってないプロジェクトで、書式についてもめた時に適当なUMLを提示して、
 「これが業界標準のUMLですよ。知らないのですか?」とハッタリをかます。
2.プログラミングに詰まった時に、自分の考えを整理するために使う。
3.プログラムのイメージが掴めない新人PGへの研修資料として、色々なUMLを見せて参考にさせる。


135 :仕様書無しさん:2007/01/29(月) 17:38:56
>>134
1.の使い方はアリ。

136 :おじゃばさま:2007/01/29(月) 19:06:16
>123
「コードレビュー」がダメと言っているのか、「相互コードレビュー」がダメと言っているのかによるが、
「相互」コードレビューがダメと言っているなら、その上司は正しい。
それはコードレビューはリーダーが全コードを見ればいいだけで、相互に行うのは時間の無駄だからだ。

「また後で困らないコード〜」の意味する物が不明だが、クラスの共通化を初期の段階で行う事を
目指しているなら、状況によるが大量のコードを書かせる方が効率がいい場合が多い。
特にメンバーに新人が多い場合である。しかしこの場合、上級者によるチェックは必須である。


137 :おじゃばさま:2007/01/29(月) 19:55:11
>126
実装先行か論理先行かの違いだと思う。
理想的な学習方法は「実装研究(1年半)」→「論理学習(数日)」である。
実装先行の人間は、数冊の本を買って、2、3日かけて読めばいいだけである。
論理先行の人間は、一旦論理を忘れて1年半ぐらい実装研究をした後に、本を読み直せばいい。
問題なのは論理先行で、間違った癖がついてしまった人である。
例えば、サンプルコードレベルでしかないデザインパターンを、オブジェクト指向の本質だと
勘違いしてしまった人などである。
まあ、論理本→デザインパターンと学習すれば誰でも陥る罠である。勘違いしない方が稀だろう。
またこういう人は「実装先行の論理未学習の人」と議論になった場合、勝ててしまう場合が多い。
そのためまれに妙に自信のある人がいる。しかし、オブジェクト指向の利点を理解していない
(ぶっちゃけ、どこが便利なのか分かっていない)ため、そこを質問するとすぐに分かる。
まあ変な癖をなおすのは大変だが、出来ない事はない。
デザインパターンは後で論理学習の際に勉強した方がいいだろう。


138 :123:2007/01/29(月) 21:12:38
>>136
やろうと言っているのは、相互コードレビュー。

時間はかかるが、早期に問題を発見したり、
全体の技術レベルの底上げには必要なこと。

同じレベルの人でもスキルに偏りがあるので、
複数の人がレビューすることには意味がある。

後で困るコードというのは、
デバッグが困難なバグのあったり、
やたらと保守性が悪いコード。


139 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/29(月) 21:16:45
ソフト設計はおもちゃ

電子回路でも機械設計でもCAD化されてるのは設計情報から実物の試作品を自動で作ってしまう事ができるが
ソフト設計はお絵かきの玩具だもん。

140 :仕様書無しさん:2007/01/29(月) 22:38:21
コテはカキコ禁止だってば。

141 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/29(月) 23:44:59
利用規約を守りませう

142 :仕様書無しさん:2007/01/29(月) 23:51:44
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2

143 :ヨコ電球(∩T∀T)y-~~~~   ◆dVyiejwdxE :2007/01/29(月) 23:57:28
>>142
まあ、そうカリカリせずに。全員がコテになれば目立たなくなるんちゃう?

144 :仕様書無しさん:2007/01/29(月) 23:58:13
>2
>2
>2
>2
>2
>2
>2
>2
>2
>2

145 :ヨコ電球(∩T∀T)y-~~~~   ◆dVyiejwdxE :2007/01/30(火) 00:00:27
今となってはモックアップという言葉すら空しく響く。

146 :仕様書無しさん:2007/01/30(火) 00:06:50
とりあえずコテコテ言ってる奴は
税金払え

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の行く末を憂いております。俺は契約社員なんだよ、派遣じゃないんだよ。

150 :仕様書無しさん:2007/01/30(火) 00:46:14
>>137
まあね、デザパタ程度の質を勘違いしてる脳内先行の人はともかく
実装先行の人もやっておくべきだな。理論武装しないとダメだ

151 :仕様書無しさん:2007/01/30(火) 01:05:43
>>147
メンバーの粒を揃えるのはリーダーの役目。
意識を共有させるなんてのはOODに限らずなきゃ話にならない。
OODじゃない設計では粒が揃わなくても何とかなるなんてのは嘘。

152 :仕様書無しさん:2007/01/30(火) 05:30:45
>>147
粒が揃って無いからこそ、OODが機能するんだとおもうが。
問題は、粒ですらなく、粒に進化する事もできない人間が大半だという事だ。

153 :おじゃばさま:2007/01/30(火) 09:26:56
>138
それならば、その相互コードレビューは全く必要ない。時間の無駄だ。
なぜなら一番スキルのある奴が全部チェックすればいいだけだからだ。
またデバックが困難なバグと言うのは、おそらくバッファオーバラン等のバグで、
保守が困難と言うのは、コーディング規約を守っていない場合だと思うが、
これも一番スキルのあるやつのチェックに加えて、lintやワーニングレベルを上げてのチェックを行い、
コーディング規約を守ってない者には、再度規約を読ませて、修正と再試験をやらせればいい。

メンバーの質を揃える必要など全くない。
第一にメンバー全員に均等に仕事を割り振る必要はないからだ。
出来る人にはできるだけ、出来ない人にはそれなりに仕事をしてもらえばいいだけである。
もしリーダー以外が全員新人ならば、リーダー一人で全部コーディングして、単体試験以降を割り振ればいい。
新人でも人により出来る量は大幅に違う。出来る人には多めに割り振り、出来ない人には結合試験の
試験要員や、ドキュメント整理要員、パン買い出し要員などにすればいいだけである。
この場合、新人からリーダーへの不満が出るかもしれないが、リーダーの仕事を一番多大変にしておけば、
リーダーへの文句は出ない。出来る人新人から出来ない新人への不満は放置する。


154 :仕様書無しさん:2007/01/30(火) 21:30:50
>>153はPL未経験者? 贅沢すぎる。

> デバックが困難なバグと言うのは、おそらくバッファオーバラン等のバグ
> 保守が困難と言うのは、コーディング規約を守っていない場合

そんな高度な次元な、わけがない。
 解 読 不 能 な ヘ タ レ コ ー ド だ。

> リーダー一人で全部コーディングして、単体試験以降を割り振ればいい。

自ら過労死志願してどうするのかと小一時間(ry

> パン買い出し要員などにすればいいだけである。
> 出来る人新人から出来ない新人への不満は放置する。

パワハラでジ・エンド
要因確保でさらに過労死。

> 出来る人には多めに割り振り、

メンバーの不公平感爆発。


155 :仕様書無しさん:2007/01/30(火) 21:33:29
ただし「悪貨は良貨を駆逐する」ということがあるので、
極端に出来の悪い要員ははずすことはやむをえない。

156 :仕様書無しさん:2007/01/30(火) 21:37:16
>>154
いや大手では良く見る光景

157 :ヨヨ電球(∩T∀T)y-~~~~   ◆bRYFywpmvY :2007/01/30(火) 21:43:25
一人に抱え込ませると、バックレかまされた時がきつすぎる。

158 :仕様書無しさん:2007/01/30(火) 22:08:16
>>156
リーダ一人で全部コーディング・・・がか?

159 :仕様書無しさん:2007/01/30(火) 22:33:59
お前等まだやってんのか?w
もう、あたまわりーから、死ねよ、お前等w

まあ、オブジェクト指向で設計をキチンとやれば実装〜テスト〜納品までの時間は半分で済むとかいって
設計の期間に倍取られて、実装から納品までの期間を半分にされたら俺はブッ千切れるけどなw

160 :仕様書無しさん:2007/01/30(火) 23:09:59
>>159はもっといろいろと人生勉強してから出直すべきだな。
OO云々語る前に

161 :仕様書無しさん:2007/01/30(火) 23:13:47
>>160←加齢臭するw

162 :仕様書無しさん:2007/01/31(水) 01:11:59
頭っから否定はどうにもな…
OO使おうがどうしようが、自分のやり方で上手く行ってれば
いいってことに帰結しちゃうけどね…

163 :仕様書無しさん:2007/01/31(水) 03:18:53
しかし、自分の上手く行くやりかたに固守すると
進歩が無いのもたしか、やはり、最初は苦労するかもしれないが、
なるべく進んでるとされるやり方を積極的にとり入れるべきだと思う。


164 :仕様書無しさん:2007/01/31(水) 03:30:48
でも、この業界ってさ、
名前を変えただけの代物とか、
まともなところでは自明のものとしてやっていることに名前を付けただけの代物とか、
そういうのが多いと思わないか?

車輪の再発明が容易な分野なのだから、
ちょっとは自分の頭を使って、
自分のところの職場に最適な方法を、
自分で編み出してもいいと思うぞ。

これが新しいやりかたです! という流行を取り入れることが、
かえって退化になるような職場だってあるぞ。

165 :仕様書無しさん:2007/01/31(水) 07:30:30
いままで、他人が考えた、俺様流の痛さ、駄目さ加減を知らないのか?
はっきりいって、この日本の業界で、個人とか職場とか狭い範囲で考えた工夫に
まともな物は無いぞ。


166 :仕様書無しさん:2007/01/31(水) 08:12:52
オブジェクト指向は資産が積み上がった際の弊害までをシミュレーション
しきれなかったのが失敗だと思うよ。JAVAのAPIがまさにそれ。
乱立するオプンのimportクラスとのコンフリクトもあるな。
namespaceさえないJAVAは石器時代のオブジェクト指向言語。
オブジェクト指向といえば主流はJAVAだからオブジェクト指向設計を語っても
実装仕様が糞味噌だから何をいっても無駄の塊。

167 :164:2007/01/31(水) 08:38:07
>>165
いわんとすることが伝わらなかったようで、こちらの書き方が悪くてすみません。

言いたいのは2つ

1. いわゆる「銀の弾丸」の話のように、
新しい方法論を取り入れれば問題が解決するというのは考えが甘い。

2. スキルのある人なら誰でも考えつくようなことこそ、不偏的な標準作法であり、
それぞれの環境や状況によって生じる若干の違いは、
我流なのではなく、ケースバイケースの最適化だと言える。



あるところでは、「ペアプログラミング」という言葉を聞くより前に、
それを行っていて、新人がみるみるうちに成長して、
二人で三人分の仕事をこなしていたが、
流行の言葉に踊らされてペアプログラミングをやりはじめたチームでは、
二人で一人分未満の仕事しかできていなかったよ。

168 :仕様書無しさん:2007/01/31(水) 08:49:27
>>166
つ package

169 :仕様書無しさん:2007/01/31(水) 09:06:53
>>166

コンフリクトって聞いたことが無いんだけど
例えば、どのオプソのクラスとどのオプソのクラスが
コンフリフトおこしてるの?
すみませんが1つ例を上げてみてください。

170 :おじゃばさま:2007/01/31(水) 09:52:04
>154
読解不能なヘタレコード?
さすがにイメージが掴めない。ユビキタス社会並に意味が分からない。
変数やクラス名が全てa001などのコードとか、1メソッドの行数が3000行を越えるとか、
ネストが30階層ぐらいあるとか、フラグやステータスが10個ぐらいあって、AND/ORなどで判断している
などだろうか?ほとんどがコーディング規約に触れると思うが。

リーダー一人でコーディングが過労死?
まず一番時間がかかるのは単体試験項目作成及び単体試験である。これ以降を新人にやらせる。
またコーディングが出来た時点で逐次割り振るので、リーダーは「結合試験開始」から「最後の割り振り
コードに対する単体試験分の時間」を引いた時間を使うことが出来る。
定時に帰ったとしても十分な作業時間は確保されるだろう。
もしそれでも時間が足りないとしたら、そのチームの能力を遥かに超えた量と言う事になる。
もし均等に割り振ったとしたら、もっと時間が足りなくなる量だろう。
その場合は速やかに再スケジューリングを行う必要がある。

パワハラでジエンド?
出来ない人が辞めると言う事か?現実を見ると出来ない人が辞める確立は低い。
それはそういう対処を受けると出来ないと言う自覚が出来て、辞めても行く所がないと考えるからだと
思われる。またもし出来ない人が抜けても大した影響はない。

メンバーの不満爆発?
カースト制度の原理で階級があると組織は安定する。つまり出来る人と出来ない人との対処を買える事で
暗黙の階級を作る。表面的な不満が出るかもしれないが、実際にはチームは安定する。


171 :仕様書無しさん:2007/01/31(水) 10:02:06
んで、>>170は、どこで働いてるの?

172 :仕様書無しさん:2007/01/31(水) 17:46:56
>>164
言わんとするところはよくわかるぞ。
名づけ親になりたがる自称コンサルの多いこと多いことww

>>168
ワロタww


173 :仕様書無しさん :2007/01/31(水) 19:34:36
>170
おっ
神発見
うちの基幹系のサブシステム、コボルで2千万ステップくらいあるんだけど
大好きなJavaで書き換えてくれよ
一月くらい終わりそう?
できるよね?
それくらいの大口たたきまくってるもんね

実は学生で実務経験無しってのは・・・ありそうだなw

174 :仕様書無しさん:2007/01/31(水) 21:00:07
文盲コボラ乙

175 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/01(木) 00:56:01
ああ、今日はぐちゃぐちゃのソース解読して一日終わった。
明日も続きだ。

176 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/01(木) 00:57:59
C#でもあそこまで解読不能のコードを組めると言う事を実感したしだいだ。

177 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/01(木) 01:01:16
Javaの会社の面接でステップ数とか言われて面食らったけど
コボル換算ステップ数だそうだ。
構造化以降はステップ数で数えたこと無いんだが・・・

178 :仕様書無しさん:2007/02/01(木) 01:23:28
wc一発

179 :仕様書無しさん:2007/02/01(木) 01:43:22
blogでやれ糞コテ

180 :仕様書無しさん:2007/02/01(木) 02:24:33
解読不能ってのはさすがにないけどな。
一見解読不能でも馬鹿の考え方が理解できれば
何とかなるしw

そういう意味ではデキの悪い実装チームのPGが一人
抜けたくらい自分でやれば済むけど虚しくはなるなw

181 :仕様書無しさん:2007/02/01(木) 02:59:34
このスレには随分上からモノを言う人が多いですね。

182 :仕様書無しさん:2007/02/01(木) 03:10:49
本質的に理論をどう現場に普及させて行くかって
スレなんだから当たり前だろ。

183 :仕様書無しさん:2007/02/01(木) 03:22:08
>>182
なるほど、オブジェクト設計を現場に普及させようという人間は上からモノを言うのは当たり前なわけだ。


そりゃあ普及しないわwww

184 :仕様書無しさん:2007/02/01(木) 03:24:32
「どうかご理解ください」って言うのか?
お前さんは上司に恵まれてないなw

185 :仕様書無しさん:2007/02/01(木) 03:39:15
>>184
上から目線の言い方以外は「どうかご理解ください」という言い方しかわからない、と。

お前は一生上司になれそうもないなwww

186 :仕様書無しさん:2007/02/01(木) 03:44:45
そうつっかかるなよ。
「教育」が必要だってことだろ?教育ってのは上から目線
じゃないと成り立たない事が多いのよ。リーダーとして
経験ある人間なら判ると思うが…

新しい「概念」を導入するためにはさ。プロジェクト
リーダーやる時が君にも来るだろうから、年寄りの
一意見として心に留めておけや。

187 :ココ電球(∩T∀T)y-~~~~   ◆lkZWT52FFA :2007/02/01(木) 07:26:59
リーダーは部下を思いやり、部下はリーダーを敬う。それだけでおk

188 :仕様書無しさん:2007/02/01(木) 08:10:42
コンフリクト
クラス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に移植する際の注意点を見てみよう。


190 :おじゃばさま:2007/02/01(木) 19:57:30
まずデータベース設計だ。
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の入門書でも読んでいてもらいたい。


192 :仕様書無しさん:2007/02/01(木) 20:42:16
・・・なんでLinuxなんだか。
うーん。経験年数は一桁と読んだがどうか。
それらをまともに客に話すと
「COBOL処理系を買う(or創る)」と言い出しそうだね。

193 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/01(木) 22:46:22
コボルクラスを作ってあげれば解決

194 :仕様書無しさん:2007/02/01(木) 23:11:29
経験年数一桁どころか経験無しのサンデープログラマじゃない?
なんか日経コンピュータ全記事読んでますみたいな子だね
・・・お話にならないね

195 :仕様書無しさん:2007/02/01(木) 23:43:32
192=194=糞コボラ

196 :仕様書無しさん:2007/02/01(木) 23:58:21
俺はCOBOL知らんけど、そこまでしてCにする意味あるか?
コボラーばかりならOO-COBOLで書き換えた方が
いいんじゃないの?

197 :仕様書無しさん:2007/02/01(木) 23:58:32
>>192, >>194
おいおい、おじゃばはJavaだけでなくコボルやC言語できる香具師だぞ
コボルしか出来ない糞コボラ=192=194よりは使える香具師と思われ
糞コボラのように経験年数が多くても、使えないんじゃどうしようもない

198 :仕様書無しさん:2007/02/02(金) 00:53:47
おいおい神でありリーダであるおばかじゃなかった
おじゃばに一人でやってもらいたいんだが?
一人じゃできません、ごめんなさいって言えばいいものを
長々とつまらんこと書きやがって
もうおまえには頼まん

199 :768:2007/02/02(金) 00:59:28
>>197
コボルできるけど最近のオブジェクト指向COBOLやNetCOBOLの
ような開発環境は知らないから、Cに書き換えさせようってオチ?

いや、俺もCOBOL出来ないけどw

200 :199:2007/02/02(金) 01:00:43
すまん、768じゃないよw

201 :仕様書無しさん:2007/02/02(金) 01:14:28
>>198
おじゃばは、「一人でできんものは、何人いてもできん」つってるわけでしょ?
「おれなら一人でやってみせる」っていってるわけじゃないでしょ?

文盲コボラ乙

202 :仕様書無しさん:2007/02/02(金) 09:28:00
言語厨の知らない言葉は、適材適所。


203 :仕様書無しさん:2007/02/02(金) 16:42:04
またJava厨か!
ネットでも現場でも空気読むことができんやつらだ!!
一生オナってろ!

204 :ヨヨ電球(∩T∀T)y-~~~~   ◆gJIIKIVefM :2007/02/02(金) 17:10:17
長年ためこんだCOBOL資産の移行を安くあげようってのが、そもそもの間違い。
移行先をJavaにしようが、Cにしようが、それまでにかかったコストと同程度か、
あるいはそれ以上のものが要求される。
COBOL資産から受け継ぐことができるのは、しがらみにまみれたビジネスロジックだけ。
COBOLから逃れるには、会社ごと立ち上げなおす以外に方法は無いよ。

205 :仕様書無しさん:2007/02/02(金) 17:15:51
COBOLから逃れること を 
顧客が望んでいるとは思わないけど

206 :ヨヨ電球(∩T∀T)y-~~~~   ◆gJIIKIVefM :2007/02/02(金) 17:23:01
顧客は自分にとって本当に必要なものを知らないだけじゃなく、
自分が欲しいものさえ知らない。
COBOL技術者数の減少傾向が止まり、増加に転じることを切に願う。

207 :仕様書無しさん:2007/02/02(金) 18:18:35
コボル厨は
 ___  見えませ〜ん
‖    |     ∨
‖現実 ∧_∧   .ヘ∧
‖ \ ( ・∀・) (゚A●)
|| ̄ ̄⊂   )  (   と)
凵    し`J   U U


 ___  読めませ〜ん
‖    |     ∨
‖空気 ∧_∧   .ヘ∧
‖ \ ( ・∀・) (゚A●)
|| ̄ ̄⊂   )  (   と)
凵    し`J   U U


208 :ヨヨ電球(∩T∀T)y-~~~~   ◆gJIIKIVefM :2007/02/02(金) 21:32:14
Java厨は
 ___  見えませ〜ん
‖    |     ∨
‖納品 ∧_∧   .ヘ∧
‖ \ ( ・∀・) (゚A●)
|| ̄ ̄⊂   )  (   と)
凵    し`J   U U


 ___  読めませ〜ん
‖    |     ∨
‖期日 ∧_∧   .ヘ∧
‖ \ ( ・∀・) (゚A●)
|| ̄ ̄⊂   )  (   と)
凵    し`J   U U

209 :仕様書無しさん:2007/02/02(金) 21:48:39
二番煎じテラツマラナス

210 :ヨヨ電球(∩T∀T)y-~~~~   ◆gJIIKIVefM :2007/02/02(金) 21:59:37
再利用ですが、なにか?

211 :仕様書無しさん:2007/02/02(金) 22:05:31
糞コテテラツマラナス

212 :おじゃばさま:2007/02/02(金) 22:57:38
COBOLをCに移植する理由は説明済みだが、簡単に書きすぎて分からなかったのかな?
もう一度説明すると、汎用機のサポートが切れて(後継機が出ず、パーツのサポートも終わり、
本体や使用しているソフトウェアの修正サポートも打ち切られた)、サーバ機に移行する必要が
出来た時だな。まあ、サーバ機で同等のCOBOL環境があればそれでもいいのだが、汎用機と言うのは
顧客を抱え込むため独自仕様が満載の場合が多い。つまりそのままでは動かない。
どうせ金を掛けて移植するなら、今後、マシンやライブラリが変更になっても対応出来る物にしようと
思うのは、当然の事だろう。
その点で言えば、OSやDBの選択肢が豊富なJavaは最適と言えるが、Java技術者で1000K越えの
大規模開発経験者は少ないし、コボラーにいきなりJavaをマスターさせるのは絶望的だ。
だから次に汎用性があって、コボラーも5年ぐらい頑張ればマスター出来るC言語を勧める。
開発はC技術者に任せて、システムが出来上がる頃には、元コボラーでもCを覚えてメンテナンス
出来るようになっているという計算だ。


213 :仕様書無しさん:2007/02/02(金) 23:07:14
>どうせ金を掛けて移植するなら、今後、マシンやライブラリが変更になっても対応出来る物にしようと
>思うのは、当然の事だろう。
いや、思わない。額が違いすぎて、思いたくても思えない。

214 :おじゃばさま:2007/02/02(金) 23:21:13
>198
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億でも同じだと言う現象が発生する。
それならば発注側も新規を選ぶのではないだろうか?



216 :仕様書無しさん:2007/02/03(土) 00:13:43
>>215
おじゃば、おさん・爺C厨スレが過疎ってるから、たまには顔出し汁

217 :仕様書無しさん:2007/02/03(土) 00:18:40
>>215
なんじゃそりゃ?
だいたいプロジェクト複数押し付けられてそれらまとめての予算に決まってるじゃん。
つまり、期末に仕上がらなければ1プロジェクトの売上がまるまる落ちてその分赤になるんだから
もしものときを考えてできるだけ値切るに決まってんじゃん。
馬鹿かおめぇ。

218 :仕様書無しさん:2007/02/03(土) 00:44:49
とりあえず長すぎて読む気しねー
読む側の気持ちを考えられない奴にまともなコードなど書けるはずもない。
まずは2chでの文章の書き方を学べ。

219 :仕様書無しさん:2007/02/03(土) 00:46:20
読んでないけど机上の空論ぽいのは何となくわかる。
あと、長すぎ、ってのは、アンタのレスとしてはって意味でね。
別に前から良いこと書いてるわけでも、面白そうでもないんだから、
その長さは読んでもらえませんよって事。
簡潔にな。

220 :仕様書無しさん:2007/02/03(土) 01:12:49
まあまあそうおじゃばをいじめるなよ。
受け売りで内容まで理解してないから長文になってんだろ。
会社じゃ使えないのに的外れのうんちくたれまくって相手にされてないんだろ、
ここくらい自由に発言させてやろーぜ。

221 :仕様書無しさん:2007/02/03(土) 01:35:47
>>198
そりゃそうだ・・・(どんなでかいのでも?)一人でコーディングするって言ってるんだから・・・

>>204
残念ながらそれが現実・・・
俺は個人的にCOBOLerがJavaなり覚えて培ったノウハウをそっちに実装してくれれば、
結構すごいのにとおもうんだがな。

・・・そんなことやるわけねー orz...

222 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/03(土) 02:18:45
文革もそろそろおわりだし
OO紅衛兵も下放されちゃって平和な時代が戻る悪寒

223 :仕様書無しさん:2007/02/03(土) 02:54:34
あとはお前が死ねば至極平和だな

224 :仕様書無しさん:2007/02/03(土) 09:52:47
ここのスレタイは現実にそうなのですか?
.NETがわざわざVBをオブジェクト指向言語にしてまで言語をOOにしたのに
開発現場はOOではないということなんですか。
言語がOOでも生の現場の開発手法はOOではないということですか。

例えば、OO的でないということは、どういうことを指してそう言っている
のですか。よろしければ教えてください。

たとえば、一つのプロジェクトで、OO的にウオーターフロー的に構想された
上で構築されず、部品も全体構想もやや無秩序に作られている、
ということを意味するのですか。

225 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/02/03(土) 10:38:42
設計技術がインチキ
十分な設計情報をもった設計図はコードを自動生成できる。
あんなもん設計じゃねえ。

226 :仕様書無しさん:2007/02/03(土) 10:43:13
>>225
お間えの存在が一番 いんちき

227 :仕様書無しさん:2007/02/03(土) 11:03:00
>>226
せっかくコテにしてくれてんだから、消しちゃえよw

228 :仕様書無しさん:2007/02/03(土) 13:18:02
>>218-220
対案もってこねえで煽るばっかりか?
糞コボラは客観的に見てあきらかにおじゃば以下だろ。今すぐ市ねよ。
俺らはお前ら養うために働いてるんじゃねえぞ。

229 :仕様書無しさん:2007/02/03(土) 13:46:47
対案って言ったらオープンプラットフォームのOOサポートCOBOLで
いいだろ?LinuxでもSolarisでも運用できるんだから。

230 :仕様書無しさん:2007/02/03(土) 15:31:03
>>228
あんた誰?

231 :仕様書無しさん:2007/02/03(土) 16:59:38
現場では、よっぽど零細かつ技術力の無いとこ以外は、
すでに、すべてOOD、流行ってないなんていうのは、
現場にでてない人間の妄想だよ。

232 :仕様書無しさん:2007/02/03(土) 17:06:30
>>231
では、質問。

OOD であるか、そうでないかを
区別するものって何?


233 :仕様書無しさん:2007/02/03(土) 17:53:29
>>232
>>231のちんこが立つかどうか。

234 :仕様書無しさん:2007/02/03(土) 23:06:03
>>233
お前は黙っとけ。自分がこの業界に少しでも興味あるならな…

>>231
君の感覚のがオカシイ、既にOOD当たり前ってのは俺の業界でも
そうだが、よりハードに近いとこじゃ、んな事ない。
組み込み系とか。俺らが普通に使ってるWinでも最新GPUの
デバドラをOODでやろうと思うか?

俺はごめんだし、そういう仕事請けたら普通にOOなんか無視するよ。
現場に出てる人間だったらむしろ、そういう使い分けが判ってるハズ。

235 :仕様書無しさん:2007/02/03(土) 23:38:02
>>234
OODっていってんだから、業務アプリに決まってるだろ。
そこでなんでデバドラが出てくるんだか。

236 :仕様書無しさん:2007/02/04(日) 00:31:20
もう正直に教えてください。
ほぼそのままコードまで落とせるようなクラス図なりシーケンス図を
設計しているプロジェクトの経験ある人はいますか?


237 :仕様書無しさん:2007/02/04(日) 00:45:43
>>235
いや、おっしゃる通りなんだがトップは仕事の取り方
考えてないからw

238 :仕様書無しさん:2007/02/04(日) 00:47:06
>>236 UMLツールとかで、そういうのあったな。

俺もIARの Visual stateとかいうツールに興味があるが、覚える時間がない。


239 :仕様書無しさん:2007/02/04(日) 00:51:46
>>236
その質問に何の意味があるんだよ

240 :仕様書無しさん:2007/02/04(日) 00:55:40
>>236
そのままコーディングできないような設計は設計じゃないと
俺は思ってる。多少の齟齬はあってもね。
プロジェクトが上手く行ってるかどうかで言えば、すべて
クライアントから文句言われた事は無い。

でも、自分が結局コーディングのヘルプに入るのは多々。
設計を変更するわけじゃないから、自分の心の中では
「なんで俺が…」と唱えながらやってたりするんだけど、
設計してる時より楽しいのは秘密だw

241 :仕様書無しさん:2007/02/04(日) 01:27:09
>>234
>>232の質問には答えられないのか・・・
それじゃいままで勝手にくっちゃべってきた無能と変わらんのよw
それが説明できんからオブジェクト指向のよさもなにもはじまらんのだから・・・

242 :仕様書無しさん:2007/02/04(日) 01:41:01
設計にもいろいろあるけどな。
コーディング直前の設計と、顧客からヒヤリングして分かるように作った設計は違うしな。

243 :仕様書無しさん:2007/02/04(日) 01:47:17
>>242
そうだよな。
読み手不在の状態で書いた設計書ってどうあるべきか?ってのは
置いておいて、実際問題として抜けや漏れが多いよな。
完成するまで溜めて溜めて溜めて溜めて「バーン」と出すのだけは勘弁してほしい。
こっちにはその業務の知識が無いから読め無い場合だってあるんだから、
何がほしいとか何の情報が足りないとか実装する人にもちゃんと聞いてほしい。

244 :仕様書無しさん:2007/02/04(日) 02:00:24
いくら設計がOOでもコーディングでOOを無視する奴いるぜ。
一つのメソッドに何十行も何百行もコード書くなよ。
ちったぁコードの重複を避けることや再利用性にも気を使ってくれ。
メソッド単位でテストするのにどんだけテストケースを想定しなきゃなんないんだよ。
テストクラス用のテストクラスを書かせる気かっ!

245 :仕様書無しさん:2007/02/04(日) 02:18:56
まぁ関数分割が苦手な奴は多いな。
多分、変数のスコープを考えるのが面倒くさいんだろうけど。
インスタンス変数以外は全部ローカル変数にして一つのメソッド内にだらだら
書いちゃうのが楽っちゃあ楽なんだけど、結局その場凌ぎで、後で誰かが保守
する時に大変な目に合う。数ヶ月もすると本人も自分で何書いたのか忘れちゃ
うケースがほとんど。
あと、名前付けの苦手なやつ。get〜という名の関数が何も返さなかったり、
状態の真偽値を返す関数がis〜、has〜という名でなかったり非常に紛らわしい。
A型の俺は非常にいらいらする。

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とか)の表を作成したら120数個あった
一個解読するのに三日かかった。

249 :仕様書無しさん:2007/02/04(日) 04:28:20
あんたんとこの会社はよっぽどひまなのか?それとも工数に織り込み済み?
俺だったらそんなソース突っ返すがな。
汚いソースは人に迷惑(必要以上の時間の浪費とストレス)かけるという意味
では十分に犯罪だぜ。

250 :仕様書無しさん:2007/02/04(日) 04:59:34
OOだろうがなにがなんでも膨大なソースを作って客から金を巻き上げる。
それが商売なんだよ。

251 :仕様書無しさん:2007/02/04(日) 05:08:31
客が興味あるのはソースの膨大さではない。品質と納期とコストだ。

252 :仕様書無しさん:2007/02/04(日) 09:16:13
>>251
正論だが、目方(ドキュメントの量と作業時間)しか興味のない客というのも
現実存在する。

253 :仕様書無しさん:2007/02/04(日) 10:02:22
コストって固定だろ。受注金額のことだよね
受注側が「増やして」と言わない限り、
興味なんぞないだろ。


254 :仕様書無しさん:2007/02/04(日) 10:25:41
>>252
このさき生残れるのかなその会社
そして飾る見積もりだしなれして居る受託も。

255 :仕様書無しさん:2007/02/04(日) 12:34:26
ぐちゃぐちゃなソース書いて徒らに保守性下げて要員多量導入して(本来不要なはずの)誠実さをアピールして追加予算を営業力でとることを常としてる会社を俺は知っている。
まぁこんなところ多いんだろうけど。つまりこの世の経済ははおばかな会社とおばかな客でなりたっているんだな。

256 :仕様書無しさん:2007/02/04(日) 14:34:01
>>255
謀らずともそうなるプロジェクトに乾杯!

257 :仕様書無しさん:2007/02/04(日) 17:01:48
そのうちニュースになるかも知れんな。
「粉飾ステップ数疑惑」とかって。

258 :仕様書無しさん:2007/02/04(日) 18:07:54
>>257
if
(
count
==
0
)
{
unko
(
)
;
}
ってしてくれるソフト作ればなんだってできるw

259 :仕様書無しさん:2007/02/04(日) 18:10:16
500、600ステップのクラスが30ステップになっちゃマズイか?ヤッパリ.デキルンダケド

260 :仕様書無しさん:2007/02/04(日) 18:18:34
VS2005スレから来ました、記念カキコです
VS2005スレ住人がお世話になっています

261 :仕様書無しさん:2007/02/04(日) 18:20:46
>>257
あべしの社長とか逮捕されそう。

262 :朝鮮人:2007/02/04(日) 18:27:47
我々の破壊工作が徐々に成果を上げているな
高圧線の鉄塔を倒したのは直ぐに我々の仕業だとばれてしまったが
ITのプロジェクトを徐々に潰していっても、いまだに誰にも気づかれない
日本人がオブジェクト思考を使い出すと厄介な事になるからな
我々の同士のなんとか学会はいい仕事してくれているよ

263 :仕様書無しさん:2007/02/04(日) 18:45:29
>>255
そのばかな客が金を持っているという現実は変えられないわけで。

264 :仕様書無しさん:2007/02/04(日) 18:53:54
人生って辛いな。俺の子供にはこんな仕事させたくないな。
だが俺は我が道をゆく。そのうち改善されることを期待しつつ。

265 :仕様書無しさん:2007/02/04(日) 19:05:24
つうかこの業界もそろそろ資格制にすべきじゃね。
今はIT技術者不足で、初心者OK、やれ作れやの雰囲気だけど
そのうち積もり積もった歪に耐え切れなくなって絶対亀裂が生じるぜ。
多分将来は今よりもうちょっと整理されたソフトウェア工学と英語能力
は必須になると思う。つうかしないとダメだろ。へんな期待もたせる方
がよっぽど酷だと思う。自殺者天国日本の悪名が高まるだけだぜ。

266 :仕様書無しさん:2007/02/04(日) 19:31:48
>>265
お前、いつの時代から来たんだよw
浦島太郎にもほどがある。
もう、資格と実力がマッチしないことは明白になったから会社は実績しか見なくなったよ。

実績っつってもC++の実務経験○年とか緩いもんだけど。
結局、資格とる奴って会社で仕事しないで資格の勉強だけしてたり、
おおよそ実務と結びつかない能力ばっかりもってる奴が多いんだよね。
最低限の仕事だけこなしたら終わったこと報告しないで資格の勉強してるとかしょっちゅうある。

まあ、これも資格所有者の態度が悪いせいもあるんだぜ。
自業自得っちゃそうだけど未経験の人はこれのおかげで入りにくくなったな。

267 :仕様書無しさん:2007/02/04(日) 19:43:48
いやだから、会社はいってから資格とるんじゃなくて、試験に受かった奴しか
法律として仕事できないようにしないと資格制の意味がないっつうの。
まぁ今の資格諸々の内容が実務に必ずしもそぐわないのは認めるけど、例えば
医師の国家試験とか、調理師免許とかみたく、(これらって実技もあるよね?)
試験内容に実務レベルのスキルが反映されるようになるにはもう少しこの業界
の成熟を待つ必要があるんだと思う。たかだかまだ4,50年の産業でしょ。

268 :仕様書無しさん:2007/02/04(日) 19:47:07
>>267
意味がない。
病院とか準看護師も正看護師も助産婦も結局同じ仕事をさせられてる状況と同じようになるだけ。
国家資格での括りは役に立たない。
だいたい、お前、誰かどういう形で規制することを前提にそんな議論してんだ?
よしんば手をだしても刑事事件扱いにならんと誰も動かないぞ。
労働基準法と同じくザル法で終わる。

269 :仕様書無しさん:2007/02/04(日) 19:49:02
ああ、そのまえに適切な試験を作ることのほうが難しいな。
詰め込み教育ではまともなプログラマは育たない。
暗記が得意なだけで頭がパーな奴を上に上げても仕方がないだろ?(職場にいねぇ?w)

270 :仕様書無しさん:2007/02/04(日) 19:49:50
>>267
コンピュータが簡単に人命を左右できるくらいにまでこの社会がコンピュータに依存すれば、それもあるかな、と妄想。
今はまだ単なる道具。

271 :仕様書無しさん:2007/02/04(日) 19:53:31
現状、資格やらセミナーやらは金儲けの道具にしか過ぎんし、
売りたいソフトを全面に出した資格を国家認定なんてしてしまうと賄賂が横行するだろうな。
社会整備のが先じゃねぇの?

272 :仕様書無しさん:2007/02/04(日) 20:02:35
>>268
あぁ、じゃあ今の状況をどうしろと。俺はただ素人同然の奴が書いた
と思われるぐちゃぐちゃなソースをメンテするのにほとほと疲れ果てて
いるんだ。社内でいくらきちんとやってても外部からたまにこんなソー
スが俺の手元にまいこんでくる。自衛手段を講じなかった俺が悪いのか?
みんなそんなに世渡り上手なのか? あぁもう疲れた。頭痛が痛い。氏ぬ。

273 :仕様書無しさん:2007/02/04(日) 20:05:40
>>272
その解決策に資格なんてのが役に立たないってだけ。
仮にお前が望む形にしてもなんの解決策にもならんし、
資格試験斡旋会社みたいなのが儲けて終わりってだけだろ?

結局、人を採用するのに人を見る手間を惜しんじゃいけないってことだよ。

274 :仕様書無しさん:2007/02/04(日) 20:10:43
>>273
採用した責任をその会社がとるならそれもそうかもしれない。

275 :仕様書無しさん:2007/02/04(日) 20:19:50
今あるような試験じゃ無理かもしれんが、試験内容次第では一定の基準を
作ることはできるかもしれないな。例えば極端かもしれんが、Code Complete
に書かれてあるようなことを最低限理解し実践できるような素養をみる試験
とか。ま、今の状況とか環境では無理なのかもね。

276 :仕様書無しさん:2007/02/04(日) 20:25:34
>>275
無理無理。
そのときだけのその問題に限って「だけ」できるようにしてくるだけでしょ。
色々金が絡んでくるとそんなもんだんだん関係なくなってくるし辞めたほうがいい。
人の採用を第三者にまかせる姿勢がそもそも失敗のはじまりなんだよ。
人をみずに仕事はできない。

277 :仕様書無しさん:2007/02/04(日) 20:28:32
>>276
それは人材派遣業を批判していると理解していいのか?

278 :仕様書無しさん:2007/02/04(日) 20:31:38
>>277
別に、派遣だって面接ぐらいやるでしょ?
1時間やって見抜けないなら採用担当者が無能なだけだし批判なんてしてないよ。
そりゃ派遣がノータッチで入ってくるなら問題だけど。それって派遣じゃなくて請負いとか別の契約のときでしょ?

279 :仕様書無しさん:2007/02/04(日) 20:36:56
どうも、>>276は技術云々より人をみてその人柄?で人を選んでるみたいだな。
その考え方って医師とか弁護士にもあてはまんの?
それって主観的なもんじゃね。Aさんの好評価が必ずしもBさんの評価と一致
するとは限らないと思うんだけど。ましてや面接時だけで判断できる自信が俺
にはないんだな。まぁ間考え方の違いだけど。俺はできることなら試験もして
その結果も考慮したい。

280 :仕様書無しさん:2007/02/04(日) 20:42:42
誰が採点すんだゴルァって声が聞こえてきそうだな。
いや>>279さんはご自分でなさるんでしょうけど。

281 :仕様書無しさん:2007/02/04(日) 20:44:31
どうでもいいけど、俺、マコネル嫌い。
無駄に文章が冗長で、コードコンプリートはマコネルの知識自慢だから、
お金払ってまで読もうと言う気にならん。

もうちょっと情報は取捨選択しろと。

だいたいあの巻末の参考文献リストって何?必要なやつだけ書けっつーの。
あれはマコネルがこんなに本を読んでるという自慢にしか
役に立たん。参考文献って普通読者が孫引きするのに使うんだと
思ったがどうか。作者が読んだ本全部書けというのとは違う。


282 :仕様書無しさん:2007/02/04(日) 20:44:45
>>279
技術的な質問なら10分でもわかるよ。
ちゃんと深いところまで見てるかどうか?
やった人でないとわからないことまで話題に乗せることができるかどうかだけですぐわかるっしょ。

>技術云々より人をみてその人柄?で人を選んでるみたいだな。
>その考え方って医師とか弁護士にもあてはまんの?
そりゃそうでしょ?
例え医者だっていくら腕がよくても横領なんてしてる奴なんて病院ごと評判悪くなるでしょ?
弁護士だって事実を捻じ曲げて勝訴にもってくような奴なんて信じて戦えないでしょ?

試験じゃなにもわからないと思うがな、
というか、俺自身、「これが満足のいく試験だ」ってものが作れ無いからそう思う。
まあ、そのときその場所限りのもんならいいだろうけど、現場によって状況も違うしね。
汎用的なもん作るのはやっぱり難しいよ。

それにプログラムの試験なんて俺はプログラム作る以外無いと思ってるんだけど。
例えばWindowsのプログラムを作る試験を出したとしてMSDNやらインターネットの無い環境ってのがありえないんだよね。
そういうの考慮するとあんまり暗記でマス埋め問題やら、キーワードを埋める形の問題やらってのは
ほとんど意味がなくなるし。やっぱり、作らせてみるしかないかな?って思うんだよね。

283 :仕様書無しさん:2007/02/04(日) 20:52:58
> 試験じゃなにもわからないと思うがな、
これは明らかに違うよ。

「試験でわからない項目がある→試験で何もわからない」
んじゃなくて、
「試験でわからない項目がある→試験でわかることもある」
だと思うのだが、どうか。

試験が万能でないのは明らかだけど、試験はある一面を評価する
には役にたつ(暗記力や理解力、思考能力の一部の評価)ので、
入社試験ではやらないわけにはいかないと思うけどどうか。

試験で一番いいのは準備させずに抜き打ちでやるのが一番
いいと思うけどね。

試験ですべてを評価するのは愚かだけど、評価の一面として
試験をまったく無視するのも愚か。





284 :仕様書無しさん:2007/02/04(日) 20:53:57
どちらにしても試験を含めたいくつかの側面で同時に評価するのがいいと思う。

285 :仕様書無しさん:2007/02/04(日) 20:55:57
いや俺はやっぱりある程度の知識を備えた上で、その次に人となりの判断だ
と思う。滅多にないかもしれないが時には人命や人の生活に関わることも
あるこの仕事で、そんな主観的なものだけで判断する気には俺はなれない。
採用する側にもそれなりに責任のあることだし、もう少し根拠となるもの
にすがりたい気がするのはあまりにも小心者かなぁ。


286 :仕様書無しさん:2007/02/04(日) 20:59:38
これはもちろん冗談だが、

以下の仕様書に基づいて動作するアプリケーションを制限時間内に作れ。
手段は問わない。

とか言って、電源・ケース・キーボード・マウスと一通りのPCパーツ(もちろん全てリテール)&ケーブル類及び開発ソフト数種類を渡す。
部屋にはLANコネクタと100Vコンセントがある。
携帯は使用禁止、ジャミング稼動中。
さあどうしよう。

てな試験

287 :仕様書無しさん:2007/02/04(日) 21:00:37
>>283
じゃ、具体的にどんな問題を出すの?

俺は暗記は全部業務に役に立たないと思ってるけど。
用語とその意味のセットみたいなもんな。
これは物を作る力と直結しないといいきれるよ(俺の経験だけどねw)
効果的な質問なら1時間もある面接の中でちょっと聞けばすむ話しじゃない?

なんで作るなら面接で質問できなくて、且つ、技術力が測れるものだけど、そんなのある?
なんか試験作ってやらせる時間が無駄じゃね?

288 :仕様書無しさん:2007/02/04(日) 21:02:37
>>286
それもその場限りだなぁ・・・
極端な話、自分でできなくても出来る奴に連絡とれて「ほい、完成」でもそれはそいつの能力だろ?
っていうか実際の業務の95%が人との会話で成り立つもんなんだからその環境の想定は意味がないだろう。

289 :仕様書無しさん:2007/02/04(日) 21:06:39
10人ぐらいいっしょに試験はじめて、
「好きな人とグループになって課題のソフトを完成させなさい」
って方が効果あるかもなw
グループに入れない奴はその場で不採用。

290 :仕様書無しさん:2007/02/04(日) 21:07:15
>>288
見張ってりゃいんじゃないの?で、作った後に解説させると。
計2時間くらい見積もれば、いろいろ分かりそうな気もするけど。

291 :仕様書無しさん:2007/02/04(日) 21:08:43
>>290
いや、俺のいいたいことが伝わっとらんなw
俺は人に聞いて物を作ったとしてもそれはそいつの能力だといいたいんだ。
結果がすべて。これは物作りの前提だ。

292 :仕様書無しさん:2007/02/04(日) 21:10:55
人の認定制度/資格制度ではなくて
生産物の品質認定制度はどうか。


293 :仕様書無しさん:2007/02/04(日) 21:12:31
>>292
仮に富士通みたいに東証止めたシステムとかはどういう評価になんの?

294 :287:2007/02/04(日) 21:13:06
>287
俺の個人的な経験を言うと、話をすると普通なんだけど、論理的
思考能力が壊滅的な人って結構いるよ。

逆に職場でアホだけど話はうまいって奴いない?

自分は話をしただけではその人がちゃんと論理的にものを
考えることができるかどうか判断できない。

試験ができる奴は暗記力がいいだけだ、と思い込んでいる人が
結構いるけど、普通にあるプログラムの穴埋め問題をさせるとか、
アルゴリズムに関する質問をするとかいうでは駄目か。
あんまり普通の試験と変わらないけどこれで十分意味があると思う。

単純に暗記だけじゃなく理解を伴う試験をだせば暗記力だけ、
というのは簡単に回避できると思うんだけど。

プログラムを書くとかいうのは、頭が悪くても誰でも経験を
積めばできるようになるのであんまり好きでない。

プログラミング言語から離れたアルゴリズムみたいなのを
新人にやらせるとめちゃくちゃ露骨にセンスの差がでるので
こっちの方が好きだ。

295 :仕様書無しさん:2007/02/04(日) 21:13:27
どんなに優秀な人でも一定レベル以上の技術者になるにはそれなりに年月が
かかるもんだから、面接ん時は適正検査程度でいんじゃねーの?探せばいくら
でもあるっしょ。この業界意外とつぶしがきかないよ。言語やOS、経験した
技術や業務が違えば、一から勉強ってことはざらだし。適正検査でいいと思う。
ただこの業界常に勉強だから、適性検査がいくら優秀でも本人が怠け者だとど
うしようもないがな。

296 :仕様書無しさん:2007/02/04(日) 21:16:20
>>294
>逆に職場でアホだけど話はうまいって奴いない?
それで世の中渡ってきたならさぞ優秀な人間を連れてくるに違いないに一票。
そういうの「だけ」ってのも困るけど、そういうの「も」いないとうまくいかないのもソフト開発だからね。
評価するべきだと思うよ。

あと俺が聞きたいのは具体的な試験問題なんだけどそれは出ないのかな?

297 :287:2007/02/04(日) 21:21:58
>296
だから試験自体は
> 普通にあるプログラムの穴埋め問題をさせるとか、アルゴリズムに
> 関する質問をするとかいうでは駄目か。
と書いているんだが。後は適正試験とか。

これでもわからんことに関してははそもそも試験でそういうのを
測ろうというのが間違いなので、別途他の面接や見習い期間の
ようなもんでカバーする。

> そういうの「だけ」ってのも困るけど、そういうの「も」いないとうまくいかないのもソフト開発だからね。
だから、口頭だけだと「だけ」って奴が通ってしまうんだよ。
ペーパー試験だけで「暗記力だけ」って奴が通るように。

まあ、そもそもアホで口がうまいというやつは、個人的に痛い目に
あっているので私怨が入っているがw

298 :仕様書無しさん:2007/02/04(日) 21:24:14
>>297
お前が言ってるのは自分とソリの合わない奴を入れない方法であってうまくいく方法じゃないじゃないか。
馬鹿らしい。さよなら。

299 :287:2007/02/04(日) 21:26:50
追記

> そういうの「も」いないとうまくいかないのもソフト開発だからね。
とうのは当たり前で俺は最初から否定してないよ。
話が下手なのは本人も困るし周りも困る。

300 :287:2007/02/04(日) 21:29:32
>298
そういうあなたも試験だけできる奴とは一緒に仕事したくないんでしょ。
同じじゃないかw

いや、俺は試験も会話も両方できないと駄目。

301 :仕様書無しさん:2007/02/04(日) 21:35:08
じゃぁ、新人扮するベテランプログラマと一緒にソートのプログラムでも作ってみればいんじゃないの?
グループでどうこうでもいいけどさ。

302 :仕様書無しさん:2007/02/04(日) 21:37:01
おまえらこんなことでいがみあうようでは精神的にまだまだだな。
俺が上司なら、「チームの和を乱す傾向あり」っとチェックつけとくな。
期末評価気をつけろよ。お前らが人の採用云々の話は10年早いわ。

303 :仕様書無しさん:2007/02/04(日) 21:37:32
>>301
ソートなんてどっかのサイトからコピってきて貼って終わりだろ。

304 :仕様書無しさん:2007/02/04(日) 21:38:07
>>302
全くだな。
喧嘩したらすべてが駄目だ。

305 :仕様書無しさん:2007/02/04(日) 21:51:21
>>286のジョークの続き

この問題はかなり難しいので君には特別にヒントをあげよう。

・・・この仕様書には少なくとも7箇所の矛盾が確認されている・・・

306 :仕様書無しさん:2007/02/04(日) 22:34:17
>>305
誰も聞いてないよw

307 :仕様書無しさん:2007/02/04(日) 22:39:07
モデルを、どう見るか…で、オブジェクト(クラス)の別け方は、異なる。
ある「見方」で綺麗にまとめられているシステムでも
別の「見方」による要求が出て来た時に、例外を導入せざるを得なくなる。
それが積み重なると…

一元的な見方の単純システムが、すべての場合に対応できるなんて、思うのが間違い。
現実問題は、ほとんど、イル・ストラクチャなのだ。

イル・ストラクチャを、最も効率的に(その場あたり的に…と同義)解決するのが
goto文と、大域変数による情報の受け渡し&保持だ。
その結果は?・・・・・・雑化して保守不可能なカオスコード!

プログラマは考える。
これでは、いけない!
もっと表現力に優れた(体系的な表現が出来て)、拡張性と保守性に優れた
新しい「何か」が必要だと。

その無限サイクルの中で、一見役に立ちそうで、機能不十分な「何か」が
無限に生み出されて行くのだ。

308 :仕様書無しさん:2007/02/04(日) 22:42:28
誰か、>>307を3行程度にまとめてくんない?

309 :仕様書無しさん:2007/02/04(日) 22:43:14




310 :仕様書無しさん:2007/02/04(日) 22:46:08




311 :仕様書無しさん:2007/02/04(日) 22:55:31
似たようなプログラムを延々とバージョンアップする

(桃鉄とか)ならば、設計に長い時間を使ってもいいけどさ
殆どの場合は、毎回予想外のリクエストで構造がぶっ壊れるんだから

もっと気楽に作った方がいいだろ。
全てトレードオフだよ。

毎回スクラッチするから、飯の種になりえているわけで。

312 :仕様書無しさん:2007/02/05(月) 00:00:14



ぶっちゃけ、OODってメチャ難しいよな?

ぬるくわかってる奴は多いかもしれないが、明確にわかっている奴はほとんどいないよな。

だから、普及しないわけだよな。

313 :仕様書無しさん:2007/02/05(月) 00:08:24
構造化設計なら簡単で誰でも実践可能ってわけじゃないしな。
結局、現時点で一般に普及している確たる設計手法なんて何もないしな。
ことさらOODが普及してないってのもなんだかおかしな話だよな。
それなりに分かってる奴なら今時はOODでやってるって、ただそれだけの話だよな。

314 :仕様書無しさん:2007/02/05(月) 01:29:00
まず、現状なり自分のやり方を絶対と考えるのが
大きな間違い。

採用云々で論じてた輩なんかはその典型だな。
要は銀の弾丸はない訳だ。

今のやり方だって数年後には
笑い話になってるかもしれないしな。

日本の場合は業務にしろ何にしろ、
もっとオープンにするのが第一だな。

そうすれば、教育効果もあるし
下手なコード書く輩も減るだろうし
車輪の再生産的な事も減るだろう。

問題は日本人はそういう類のコミュニケーションが
著しく下手な事だな…

案外、外人が主導した方がうまくいくかもしれんな。



315 :仕様書無しさん:2007/02/05(月) 01:45:30
評論家気取り乙

316 :仕様書無しさん:2007/02/05(月) 02:08:20
>315
スレのレベルが下がり気味と思ったから
書き込んだまでだ。

お前はもちろん何も書き込まなくていいぞ。
他へ逝けw



317 :仕様書無しさん:2007/02/05(月) 02:40:02
まあOODがベストではないがベターだから取りあえず使ってます
って人は多いだろ。

318 :仕様書無しさん:2007/02/05(月) 04:22:32
>>314さん
>まず、現状なり自分のやり方を絶対と考えるのが
>大きな間違い。
>採用云々で論じてた輩なんかはその典型だな。
>要は銀の弾丸はない訳だ。
>>315さんはこのあたりに反応したのかと想像します。
設計手法にしても、(スレ違いではありますが)採用方法にしても、その時々で最善の判断し、結論を出すしかない訳で。
このレスを読むと、あなたはあなた自身の語っていることこそが「銀の弾丸」であると考えているようにも受け取れます。

>今のやり方だって数年後には
>笑い話になってるかもしれないしな。
これはあなた自身はOODは数年後に笑い話になると考えている、ということですか?
ま、そうでなくても、あなたなりの設計手法に関してのビジョンを提示して頂かないと議論にはなりませんよね。

>日本の場合は業務にしろ何にしろ、
>もっとオープンにするのが第一だな。
「業務にしろ何にしろ」とは具体的に何を指しているのかよくわかりませんが。
顧客側の業務ですか?それともシステムを開発する側の業務のことでしょうか?
その「業務にしろ何にしろ」をオープンにすればOODが流行ると考えている、ということですか?

>そうすれば、教育効果もあるし
>下手なコード書く輩も減るだろうし
>車輪の再生産的な事も減るだろう。
そもそも何をオープンにするのか良くわかりませんが、自分なりに想像するに。
僕はOODに理解が無いプロジェクトメンバーにOODを教える労力が楽になるとは思えませんね。
下手なコードを書く輩が減るとも思えません。

>問題は日本人はそういう類のコミュニケーションが
>著しく下手な事だな…
(2ちゃんの中ですらまともに議論出来ないあなたのような)まともな議論の出来ない人が多いとは僕も思います。

スルー出来なくてすいません>スレの皆様

319 :仕様書無しさん:2007/02/05(月) 04:23:47
資格制度なんか全廃してもいいよ。
肩書きをまずなんとかしようって思って生きてきた奴が
現場で通用することはほぼない。

320 :仕様書無しさん:2007/02/05(月) 06:56:27
オープンなのは股間の社会の窓だけだなw

321 :おじゃばさま:2007/02/05(月) 10:01:06
銀の弾はないと嘆いている人の多くは、単に問題分析が出来てないだけの場合が多い。
だから設計がどうのと言う以前に、問題分析の方法を学ぶべきだ。

面接では「その人間が今どのぐらい出来るか」は分かっても「その人間がこの先出来るようになるか」は
絶対に分からない。


322 :仕様書無しさん:2007/02/05(月) 11:00:02
銀の弾丸なんて無いよ。
嘆いてはいないけど

323 :仕様書無しさん:2007/02/05(月) 12:51:29
>>322
しかし劣化ウラン弾は豊富に存在する。


324 :仕様書無しさん:2007/02/05(月) 18:13:06
>>321
人見る目ねーな。
あと論理的に突っ込まれやすそうだな。
"絶対"かよww

325 :仕様書無しさん:2007/02/05(月) 18:40:06
>>324
いや、人を見るってのは相当難しいよ。
「上手く行けば成長して柱になれるかな」くらいは
判っても、本当にそうなるかどうかなんて神様じゃ
なきゃ判らん。逆にそれほど期待してなくても、
「まあ入れといてもいいか」くらいの奴が伸びたりさ。

ある程度の範囲で掴むことは出来ても、ピンポイントで
把握するのは難しいよな。俺が未熟っちゃそうなんだが
相当キャリアあっても、人を見直したりするのは茶飯事だな。

326 :仕様書無しさん:2007/02/05(月) 18:40:55
>>324
ん??

>面接では「その人間が今どのぐらい出来るか」は分かっても「その人間がこの先出来るようになるか」は
>絶対に分からない。

不確定要素だから「絶対」であってんじゃねの。




327 :仕様書無しさん:2007/02/05(月) 19:51:30
>>326
行末に「w」つける莫迦は放置の方向で。

328 :314:2007/02/06(火) 00:32:20
>318
設計の話から脱線したのは、
独り善がりな採用方法の話があまりに見苦しく感じたから。

それで代案として
業務内容等のオープン化を出した訳だが、
大雑把な話では企業より大きい枠での協力体制とか。

具体的かつ現実的な所では技術の共有化とか。
飯の種が無くなる事を
危惧する人もいるだろう。
しかし、俺はそうする事で
日本の相対的な価値が高まる方が得と考える。



329 :314:2007/02/06(火) 00:51:49
>318
OOの話に戻ると
現状はベターな考え方と思うが、
必ずもっと良い方法が生まれると思う。

それを言いたかったけど
少なくてもお前には伝わらなかった様だな。

あと、業務等のオープン化で
下手なコードが減る事はないと話てるが、
上手なコードや人が増えればいい訳だろ。

お前は変な所でネガティブだな。

俺もお前の書き込みは
納得いくものは一つもなかったよ。



330 :仕様書無しさん:2007/02/06(火) 01:04:18
>>329
横レスで申し訳ないが、
> 上手なコードや人が増えればいい訳だろ。
ということに賛成。

元が糞なシステム・コードはメゲるが、
少しでもマシになれば、それはそれでうれしいものだ。




331 :仕様書無しさん:2007/02/06(火) 01:30:53
>>329-330は自演っぽいなw
で、ずっとROMってた俺も横レスですけど。

>下手なコード書く輩も減るだろうし
って、お前自分で書いてるじゃんかw

>必ずもっと良い方法が生まれると思う。
これには俺も「おめでたい評論家気取り乙」という言葉を送りたい。

煽るつもりも無いけど、もっと具体的に書いてくれるとおもろいんじゃね?
おもしろくもない話しかでてこない気もするがw

332 :仕様書無しさん:2007/02/06(火) 02:15:43
> 上手なコードや人が増えればいい訳だろ。
だから、これをどうやって実現するのかを話して欲しいのだが

333 :314:2007/02/06(火) 03:05:48
>331
汎用の観点から
アセンブラ→C→C++という流れもあった訳だし、
現状が増え続ける物量への
最適な方法な訳ではないのはどの分野でも自明だろうが。

素人レベルに例示はしないけどなw
少しは自分で調べてみ?

それと、下手なコードや人はそれこそ無限にあるんだよw
上手なコードや人が増えれば
相対的に下手なものを相手する事が減るだろ。

お前って本当に馬鹿だなw
あと、>330氏は別の人だぞ。
俺の意見に部分的に賛成みたいだな。
まぁ、うれしいけどな。
自演話は想像もしなかった。
むしろ、お前の方が怪しいんじゃね?



334 :314:2007/02/06(火) 03:18:27
>332
上手なコードや人と接する機会が増えると言っているのに
実現方法がわからないのかよ。

ゆとり馬鹿?単なる低レベル?

>331や>332は書き込みだけで
馬鹿が筒抜けになってるなw

レベルもほとんど同じみたいだし、自演なんだろw



335 :おじゃばさま:2007/02/06(火) 09:56:32
採用と設計を変えれば、下手なコードを書く人が減ると言うのだろうか?
少し考えればそれは非常に困難だと気が付く。
仕事の出来る中途を定量的に採用するのは困難だし、設計方針を変えても理解出来なければ意味ない。
この問題点は「新人教育」にある。
多くの企業が結果重視を採用したため、新人教育という文化が廃れてしまった。
社員は新人教育によっては評価されず、またライバルがいない方が安心である。
結果的に新人は放置され、放置された新人が先輩になり、さらなる被害を生んだ。

これを解消するのは簡単である。
新人教育をすればいい。しかしここで言う新人教育とは、セミナーのような講習会とは違う。
いわばOJTだが、付きっきりで教えるのでもない。単にその新人に出来る仕事をやらせてサポートしつつ、
段階的に難易度を上げて行くだけである。
しかし実際には給料体系を含めて変える必要があるだろう。


336 :仕様書無しさん:2007/02/06(火) 10:57:25
>>335
単なる理想論で終わることが多すぎ
そのレスなんざその典型だ
>しかし実際には給料体系を含めて変える必要があるだろう。
これだけでは話が進まない。
そしてここに突っ込んだレスをしても無視するだろ。

「下手なコードを書く人を減らす為の、
その提示した新人教育にはどれだけの期間と費用がかかって、
その期間と費用に見合う効果がどれだけあるか」
まで書かないと説得力が無いだろ

337 :筒抜け馬鹿:2007/02/06(火) 11:02:58
>>334
煽られ部分は無視するとして。
そんな事で下手コードが減ると思っているなら
脳天気だと思わざるを得ない

338 :仕様書無しさん:2007/02/06(火) 11:13:00
>>335
2点。あと、おまえの力試しに付き合うのは飽きた。

339 :仕様書無しさん:2007/02/06(火) 23:36:20
>>338
市ねコボラ

340 :330:2007/02/07(水) 00:45:41
自作自演ってなんなのさー。 OTZ...
なんかスレが荒れてるけど、まぁいいや。

出来る人が増えると糞コード(と、スレタイに則って設計も)が減るかどうかだが、
個々のマが定量的に把握するのはちょっと難しいかもしれない。マクロ的な結果なので。

ざっくりと言えば、良貨は悪貨を駆逐する。
割と誰でも経験あることとおもうが、
そこそこにきちんと出来る人(=プロジェクトに必要な知識を持った人)が多い
プロジェクトだと、スムースに事が運んだり、不安が少なくて済まないか?


費用対効果が一番大きいのは、>>335の言う新人教育と思うが、
その理由は機会があれば、書きたい。
イラネだったらやめとく。


>>335
その方法へ移行期が先輩の新人潰しが一番激しくなるよ。
新人の時ほったらかされた先輩が居る間は。


341 :仕様書無しさん:2007/02/07(水) 00:54:06
悪貨生産者が、生産しているものが悪貨であることをまず認めないとね

342 :仕様書無しさん:2007/02/07(水) 00:57:16
>そこそこにきちんと出来る人(=プロジェクトに必要な知識を持った人)が多い
>プロジェクトだと、スムースに事が運んだり、不安が少なくて済まないか?
それは正しいが。
プロジェクトに必要な知識を持った人が少ない場合のことをツッコンデイイ?

343 :仕様書無しさん:2007/02/07(水) 01:23:30
>>342
それはそれで、聞きたい。

344 :仕様書無しさん:2007/02/07(水) 02:24:56
技術系の給与水準が低い
−>いい新人が来ない&教育費が出ない
−>技術水準が低い
−>給与水準が低い

の悪循環をなんとかしないとなあ。
プログラミング技術ってのはすごいものなんだ、金を出す価値があるんだ、
っていう感覚がなくなっちゃったのかなあ。

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万円
ただし労的コストと実際のコストは違うので、意味がないと言えるが、とりあえず数字が欲しい
みたいなので書いてみた。やぱり教育には労力がかかるんだなと言うのが感想かな。


346 :仕様書無しさん:2007/02/07(水) 15:58:24
真性キチガイ キタ━━━━━━(゚∀゚)━━━━━━ !!!!!

347 :仕様書無しさん:2007/02/07(水) 17:53:26
↑この世にはプログラマに向いてる奴と向いてない奴がいて、向いてない奴には
|いくらいい教師でも、まともなコードを書かせるのは至難のわざであり、また
みたいに、なんの役にも立たない煽りを書く奴にいいコードを書けるわけがな
いことだけは、俺にもなんとなくわかるようになってきた。

つまり、放漫な奴、傲岸不遜な奴のコードをみるといつも手抜きの痕跡がみられ、
そんな奴のコードで、きれいなコードというものはいまだかつてみたことがない。
センスも大事だが、多分、性格もプログラマの資質に大きく関係しているのだと
思う。

348 :\_____  ______/:2007/02/07(水) 17:58:13
         ∨       ノ
         __     /
        /⌒ ヽ  /        /
        (     )'゙ヽ.     _/
.      /iー-‐'"i    ,;   /
    i ! ( ヽ.    )  ノ/ .:/
      (\.゙ヽ_(_/,イ/
    i ! (\\_,_)' ノ
      (\\_,_,)'
    i !  l ,i\ ヽ、 !
       し'

349 :仕様書無しさん:2007/02/07(水) 22:20:05
嵐がやってきた

350 :仕様書無しさん:2007/02/07(水) 22:45:23
変身忍者 嵐

351 :仕様書無しさん:2007/02/08(木) 00:25:49
コードコンプリート読め。

352 :仕様書無しさん:2007/02/08(木) 01:07:58
なんでマコネルの自慰ショーをここで勧めるか

353 :仕様書無しさん:2007/02/08(木) 02:28:27
流行ってるとか流行ってないって結局主観なんだから。

それより、今やるべきことはなんなんだ?
皆さんどうお考えですか?

モデル工藤なんてどうよ?
モデリングの修行を積んで、UML2.0に強くなって、OCLもきちんと勉強しとけばいいんでない?
きちんとモデル書いたらきちんとしたコード吐いてくれる時代がまもなく来るような気がするんだけど。
そのためのUML2.0だと思うし。
で、肝はやっぱりモデリングなんだからさ、OOちゃんとやっとくべきなんだと思うんだけど。
で、結局実装を意識したレベルのモデリングまで必要になるんだからさ、Javaしっかりやっとけばいいんでない?
流行るかどうかは別にして、食いっぱぐれは無いような気がする。

甘い?

354 :おじゃばさま:2007/02/08(木) 09:29:18
>347
つまり347の言いたい事は、きれいなコードを書くならセンスとマメな性格が必要だと言う事だろうか?
ちなみにセンスとマメな性格をを与える教育方法を教えてもらわないと、347の書き込みは
俺の計算式と同様「なんの役にも立たない煽り」になると思うのだがどうだろう?
それとも自分のコードは汚いと遠回しに言っているのだろうか?

しかし安心してくれ。
煽りと汚いコードに関連はないだろう。なぜなら俺のコードはきれいだからだ。
おそらくここで言う、きれいなコードは「他人が見ても理解しやすいコード」だろう。
それは適切なコーディングルールを決めて、コードチェックする事により、多くの場合がクリアされる
だろう。ただセンスとマメな性格の教育方法は、興味があるので教えていただきたい。


355 :仕様書無しさん:2007/02/08(木) 09:55:01
>>354
「人が見ても理解しやすい」ってのは人によって大きな開きがある。
共通部分をまとめたり、OOPの方がわかりやすいという人もいれば
処理順序がわかりやすいという理由でスパゲッティの方が読みやすいという人もいる。

356 :仕様書無しさん:2007/02/08(木) 10:01:50
>>353
脳内モデルを表現するにあたって、UMLを書くよりコードを書くほうが早いのが難点。

357 :仕様書無しさん:2007/02/08(木) 10:08:27
>>355
「人が見ても理解しやすい」ってのは、そんな主観的・感覚的な話じゃないぞ。
同じことをやるコードでも、OOPのコードは非OOPのコードより「情報量が多い」んだよ。
同様のことがスパゲッティのコードと非スパゲッティのコードにも言えるし。

358 :仕様書無しさん:2007/02/08(木) 12:33:29
>>357
「情報量が少ない(多い)コードは人が見ても理解しやすい」というのはまさに主観的な話だと思うが。

359 :仕様書無しさん:2007/02/08(木) 16:41:02
定量化する方法がなければ。
「理解しやすい」というアナログ的な感覚は
「主観的特性」であると判断するのが論理的かと

360 :おじゃばさま:2007/02/08(木) 20:58:07
そんな難しい事ではない。
例えば自分と同じ書き方をしている人がいたとする。その人のコードはきっと読みやすいだろう。
それを強制的に行わせる。つまりコーディングルールを強制することによって、まず自分がそれに慣れる。
そうなると、同じ書き方をしている他人のコードも見やすく感じる。
簡単な原理だ。


361 :仕様書無しさん:2007/02/08(木) 22:21:46
傲慢だ

362 :仕様書無しさん:2007/02/08(木) 23:30:10
くだらん。読みやすいかどうかなんて関係ない。
何故なら、本当に分担が設計通りに行ってるなら
人のソースなんか読む必要はないからだ。

インターフェースが厳密であって、機能を満たして
いるなら、人のソースを見る必要がどこにあるんだ…

363 :仕様書無しさん:2007/02/08(木) 23:55:27
ある時点の素晴らしい設計もインターフェースもそれほど強固なものではない。
時代や状況の変化に応じて、そのうち変更を余儀なくされる。
その時に被害を被るのは読みにくいソースを渡された誰かさんなのだ。

364 :仕様書無しさん:2007/02/08(木) 23:57:35
変更を予定してない設計がダメなだけ。
どういう要求が来るか予測できなきゃ設計なんかやるな。
だから拡張性を考えて設計すんだろ。

もちろん、雑魚過ぎてダメなPGなら、そんなの外して
最初からそこのコーディングは自分で引き受けろ。

365 :仕様書無しさん:2007/02/08(木) 23:57:49
>>362
デバッグ時は人のソースどころかOSSのソース、果てはAPサーバのソースまで潜っていかなきゃならんが。

366 :仕様書無しさん:2007/02/09(金) 00:00:04
>>364
>どういう要求が来るか予測できなきゃ設計なんかやるな。
>だから拡張性を考えて設計すんだろ。

こういうの今日日流行らないって、知ってていってるんだよな?

367 :仕様書無しさん:2007/02/09(金) 00:01:54
>>366
流行らないもクソもないでしょ。
実際にそういう現実があるんだから。実際にクライアントから
完璧だと言われる、モノあげなきゃプロじゃ無いんだよ。

368 :仕様書無しさん:2007/02/09(金) 00:06:48
人間の予想できる拡張性への配慮なんてたかが知れたものだ。
それは今レガシーシステムと呼ばれる代物を保守している人たちがよく分かって
いると思う。数年もたてば最適な方法論も代わってくるだろう。だが、末端の成
果物であるソースの面倒はリプレースされるまでは誰かがみなければならない。

369 :仕様書無しさん:2007/02/09(金) 00:08:38
過去の資産の置き換えは、また別の話だな。

370 :仕様書無しさん:2007/02/09(金) 00:10:23
>>367
YAGNIのいいとこわるいとこ、いろいろ試行錯誤のうえでの発言じゃなきゃ
今日日>>364は通用しないでしょ。

371 :仕様書無しさん:2007/02/09(金) 00:16:09
>>370
君が本当に仕事してんのかどうか疑問だね。
そりゃ開発中は「無茶言わないでください」って
クライアントに言う事もあるさ。

でもな、本当にクライアントが求めてる事を理解
してれば、要求仕様だけでは足りないってのは
判るハズだよ。最初の要求仕様だけで組もうとする
方が設計者としてどうかしてる。

色々揉めても最後には「ここまでやって頂いて、
ありがとうございます」とクライアントに頭下げ
させるような仕事しろよ。それこそやりがいだろ?

372 :仕様書無しさん:2007/02/09(金) 00:24:48
なんだろ、俺は370じゃないけど意味がよくわかんないな。
誠実さをアピールして情に訴えろってことかな。今の上司にもそれに近い
ことは言われるな。

373 :仕様書無しさん:2007/02/09(金) 00:25:30
>>371
爺い、めんどくせえからって2行目だけ読むなよ。。

あらかじめ拡張性のことを考えて設計しても、トータルコストは
安くならないって見方が今は一般的だって話だよ。
もちろん要求の変化や仕様の変更がガンガン入るって前提で。

374 :仕様書無しさん:2007/02/09(金) 00:27:31
コストだけ考えて仕事してたら生き残って行けないぞ。

375 :仕様書無しさん:2007/02/09(金) 00:30:27
まあ、それ以前に拡張性考えて設計するのが仕様満たすだけの
設計するよりコストかかるとか思ってる時点で雑魚だけどな…

376 :347:2007/02/09(金) 00:38:45
>>354
えーと、お取り込み中申し訳ないですが、俺が書いたのは、>>346に対してなんだけど。
おじゃばさまも意外と早とちりなんだな。


377 :仕様書無しさん:2007/02/09(金) 00:40:03
コストが同じなら議論するまでもないでしょ。あたまわるすぎ。

378 :仕様書無しさん:2007/02/09(金) 00:41:55
377はたぶん自分で拡張性あるつもりの設計して
何の意味もなかった悲しい人なんじゃないかな

379 :仕様書無しさん:2007/02/09(金) 00:43:04
>>376
別におかしくなくね?

380 :347:2007/02/09(金) 00:45:36
>>379
うんにゃおかしくなくなくね

381 :仕様書無しさん:2007/02/09(金) 00:45:53
>>378
YAGNIは俺の発明じゃねー。
つか俺はむしろ自分の練習や興味のためだけに設計に凝るタイプ。

382 :仕様書無しさん:2007/02/09(金) 00:46:45
>>380
どこがおかしいかわかんね

383 :仕様書無しさん:2007/02/09(金) 00:49:16
きれいなコーディングにセンスや性格が関係してると
言ってる347に答えてるんだから別におかしくないような。

>>381
横からなんだけどプロじゃねえだろw

384 :347:2007/02/09(金) 00:49:28
あーめんどくさい。もぅいい。寝る。

385 :仕様書無しさん:2007/02/09(金) 01:04:41
まあ381は学生臭がぷんぷんするけど、確かに
経験則から割り出した予測が役に立たない事もある。

でもコストが変わらないなら、拡張性高く作って
置くことに意味が無いわけじゃない。
つうか、むしろそん時作るより遥かに速い事のが多い。

そうじゃないって奴は能力が無いだけだろ。
YAGNIとか未だに信じてる奴がいる方が「え?」って感じ。

386 :仕様書無しさん:2007/02/09(金) 01:18:38
>>385
これでも今年でプロ10年目だよ。悪かったな。

だけど俺「YAGNIのいいとこわるいとこ云々」って>>370で書いてるし。
デザパタ厨もYAGNI厨も、いつか通ってきた道。

387 :仕様書無しさん:2007/02/09(金) 01:25:00
そりゃ悪かった。でもさ、デザパタもYAGNIなりも、実質上
コーディングレベルの話じゃん。

設計側が仕様のみで設計してたら、そりゃ変更あった時に
PGからはブーブー言われちゃうわけで、その辺はある程度
予測すんのも設計者の腕じゃないかなって言いたかっただけ。

388 :仕様書無しさん:2007/02/09(金) 01:33:15
垂直的な用途にも使用可能な水平的なソフトを同一コストで創ってしまう
という能力をお持ちならそれも支持出来ない事もないんだが。

本当に拡張性を高くするとコストが同じになるわけがない。

「コストが同じ程度の拡張性の向上が殆ど役に立ったためしがない」
という経験則がYAGNIという言葉の源泉なのだが。

389 :仕様書無しさん:2007/02/09(金) 01:45:40
設計上での拡張性はコーディング上での拡張性と切っても
切れないから、コスト的に同じになるわけがないと言う
気持ちも判る。

でも実際は違うんだよな。単純な例として言えば、
キャリアのないPGが組めば、S-JIS対応だけの仕様と
拡張性考えてUNICODE,EUCだの対応して作るのはコストが違う。
だけど、キャリアあるPGならまったくコストは変わらない。

「殆どないはずの、コストが同じ程度の拡張性の向上を
活かせる人材を抱える事が、企業の競争力を決める」
これが俺のYAGNIに対する答え。

390 :仕様書無しさん:2007/02/09(金) 01:57:16
>>389
YAGNIに対する一般的な解はもうあるよ。
「バランス感覚が大切」

100%得ならやれ、90%でもやれ、50%ならやるな
ってそれだけ。

391 :仕様書無しさん:2007/02/09(金) 01:58:44
そりゃそうだw

392 :おじゃばさま:2007/02/09(金) 09:12:40
>376
なるほどそれは気が付かなかった。つまり俺が自意識過剰だったと言う事か。気をつけよう。


393 :おじゃばさま:2007/02/09(金) 09:43:32
390に同意

394 :仕様書無しさん:2007/02/09(金) 15:23:38
ここで孔子様の
中庸の徳
という教えに再会出来るとは

395 :仕様書無しさん:2007/02/10(土) 09:07:24
まぁ、ほとんどの問題は、中庸が良いんだが、
その中庸の何処に線を引くかが難しいんだよな。
結局、正しいが、あんまり意味の無い意見のような気がする。

396 :仕様書無しさん:2007/02/10(土) 12:51:57
>>395
線を引くっていう考え方がおかしい。
デザパタにしろYAGNIにしろ、自分なりにつきつめて実践してみれば
自ずとどのあたりが中庸か浮かび上がってくる

397 :仕様書無しさん:2007/02/10(土) 21:15:56
そして現実が残った

398 :仕様書無しさん:2007/02/11(日) 00:46:20
アセンブラ使ってもCと同等の生産性を実現できるやつには
言語やルールを決める意味なんぞわかりはしないのであります。

399 :仕様書無しさん:2007/02/11(日) 03:09:33
どんなにアセンブラ極めたとしても、同等のCの能力あれば
同じ生産性にはならんだろ?
もしそうなら、ずーーとアセンブラで開発してたな…


400 :仕様書無しさん:2007/02/11(日) 03:11:12
>>なんでマコネルの自慰ショーをここで勧めるか
あれは自慰ショーだったのか。(ノ∀`)

401 :仕様書無しさん:2007/02/12(月) 01:13:15
普段からオブジェクト思考が出来る人を
オブジェクターというらしいのだけれど
本当?
通常JAVA等のプロジェクトには2〜3人はいて欲しいそうだけど
0が現状らしいです
本当?

ちなみにオブジェクターは頭の中でポリモーフィズムとか継承とかするから
新しい事柄に対しても比較的理解が早いらしいです
しかし、睡眠中にガーベージコレクションをやるらしいので
睡眠不足になると、訳のわからないことを口走るそうです
本当かな?

402 :仕様書無しさん:2007/02/12(月) 01:59:35
>>401 ノシ
ただし、クラスが上手く組み立てられないと思考破綻を起こします。

403 :仕様書無しさん:2007/02/12(月) 03:38:40
日本はどんどん恥ずかしい世界になっていくな。

野球のバッターを、
上級職として「バットでボールを打ち返せる人」って名前にするくらい恥ずかしい。

じゃーバッターって何?って話になりそうだ。

404 :仕様書無しさん:2007/02/12(月) 10:15:29
野球をオブジェクト指向で表現するとどうなるのかなぁ?
野球選手というスーパークラスがあって
ピッチャーやバッターはそのクラスを継承したものなんだろうか?
それとも別なオブジェクトだろうか?
ピッチャーやキャッチャー等の守備は
守備クラスを継承すればよいような気がするけど
だけど、継承とも違うかなぁ
ポリモーフィズムかなぁ
受けて投げ返すのは皆一緒だから

405 :仕様書無しさん:2007/02/12(月) 10:59:25
>>404
えー、攻撃側と守備側であることを状態で管理して、各ポジションごとに動作や、守備範囲を切り替えるとかじゃだめ?

406 :仕様書無しさん:2007/02/12(月) 21:19:34
>>405
>切り替える
とか言っている時点で、もうオブジェクト指向じゃないような気がする
切り替えるやり方ははひょっとしてサブルーチンの引数?
守備フラグ?(笑)
それは困る!

407 :仕様書無しさん:2007/02/12(月) 22:15:16
>>406
State Pattern
ポリモルフィズム

408 :仕様書無しさん:2007/02/12(月) 22:35:37
あてずっぽうで言わせてもらうと、ピッチャーやバッターは
ロール名であってクラス名ではないような気がする。
守備と攻撃もそう。

選手クラスのサブクラスでピッチャークラスとかつくると、
一時期の阪神みたいに、ピッチャーがファーストの守備に入って、
またピッチャーに戻るような守備位置の変更みたいなのに
対応できないでしょ。

インターフェイスの多重継承で対応してもあっさり破綻すると思うよ。
多重分類も大量に発生しそうだしな。

409 :仕様書無しさん:2007/02/13(火) 01:01:27
>>404のような思考が>>408みたいになる為には何が必要なんだろうね?

>>406
揚げ足取りは簡単だと思ってるかもしれないが。
>状態で管理して
状態を属性で持つんじゃなくて、クラスで持つ訳です。
それ位は勉強してから意見するように心がけるべきじゃないかと思った。
もしかしたらわかっててやってるのかもしれないですけど。

410 :おじゃばさま:2007/02/13(火) 09:25:17
現実世界にはオブジェクト指向的な物がほとんどないから、理解するのが難しい。
はっきりオブジェクト指向と言えるのは、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として監督機能を実装してるだけ。
まあ、そろそろそのあれが逆になってきてるけど。


415 :仕様書無しさん:2007/02/13(火) 13:08:11
>>410
この世はオブジェクトだらけですが・・・それを抽象化できないあんたに
センスがないだけ。

416 :仕様書無しさん:2007/02/13(火) 16:31:17
まて。
「単なる仕事上の生産物の設計方法論を、世界観にまで広げる」
ことはいかがなものかと

417 :仕様書無しさん:2007/02/13(火) 17:24:08
アホコテはもう少し自覚した方がいいと思う。

418 :仕様書無しさん:2007/02/13(火) 17:47:35
IFはしょせんもどきだよ。がんもどきのおでんのようなもの。

419 :おじゃばさま:2007/02/13(火) 19:46:47
>415
では野球選手でオブジェクト指向を表現してくれ。
昔流行った、「オブジェクト指向を理解してる人しか分からない自己満足説明本」にならないように
気を付けてな。人間と動物ネタや、ドラ○もんとドラ○ちゃんネタのような物は笑われるから避けた方がいい。

IFの現実的な役割は多重継承回避だ。
端的に言うと、スレッドとDB系の処理を継承したい場合に、多重継承したくないか出来ないので仕方なく
スレッドをインタフェースにする訳だ。オブジェクト指向の論理から言うとイリーガルな処理だ。


420 :仕様書無しさん:2007/02/13(火) 20:12:23
>IFの現実的な役割は多重継承回避だ。
アホか、オブジェクト間の依存度を減らすためにあるんだろ

421 :仕様書無しさん:2007/02/13(火) 20:30:25
ちとまずそうな気がするが
選手、コーチというI/Fを作り
選手I/Fを実装した野球選手抽象クラスを作り
野球選手抽象クラスにコーチI/Fのフィールドを登録するとか

422 :仕様書無しさん:2007/02/13(火) 21:45:42
野球選手抽象クラスは漏れも思いついた。
選手コレクションから各ポジション割り当てるだけなら、
兼任は簡単に実現出来ると思う。
じゃぁ、実装は?と言われると、やってみないとわからんなぁ。

423 :仕様書無しさん:2007/02/13(火) 21:54:19
>>419
Class BaseballPlayer
:
End Class
:の部分はドメインモデル(球団経営、ゲーム、シミュレーション、神の視点...)で変わってくる。
おじゃばさま、頭固いだろ。多重継承できないって泣いてるひまあったらmixin使えよ。

424 :仕様書無しさん:2007/02/13(火) 22:20:57
世界をオブジェクトで説明しようとするのは、いわばプラトンのイデア論みたいな
ものだろう。
でも、実際の現実世界は複雑系で、簡便なオブジェクトで表現できるような
ものではなかったりするよね。

425 :仕様書無しさん:2007/02/13(火) 23:33:43
とりあえず、各選手?ポジション?の
プロパティとメソッドはどんな感じになるのでしょうか?
また、チェンジとかはどんな風に考えるのでしょうか?
審判もクラスにするのでしょうか?
これを突き詰めるとオブジェクト思考にも
限界が見えてくるような気がします
どうでしょうか?

426 :仕様書無しさん:2007/02/14(水) 00:36:41
ヘタレな俺には頭がついていけなくなりつつあるのだが。

昨今の野球ゲームはきっとオブジェクトで作られているに違いない。と思う。

427 :仕様書無しさん:2007/02/14(水) 00:47:38
人間は、結局オブジェクトとして万物をとらえているのだから、
人間がわかる範囲はすべてオブジェクトになるのさ。
逆にオブジェクトにできないものは、どうがんばっても人間に理解できん。

428 :仕様書無しさん:2007/02/14(水) 01:06:40
>>427
それはちょっと極端かも。

429 :仕様書無しさん:2007/02/14(水) 02:19:05
もともとオブジェクト指向でなくても出来るものを、
オブジェクト指向に落とし込んでる訳で、
100点以外は不合格みたいな考え方だとハードル高過ぎるだろ。

430 :仕様書無しさん:2007/02/14(水) 05:55:04
個人的に状態をクラスとして表現してしまうような設計をする奴は
ドキュメント地獄になってしまうだけでなんのメリットもないと思うんだ。

431 :仕様書無しさん:2007/02/14(水) 05:56:58
オブジェクト指向的にどうか?
っていう話だと状態もクラスにできてしまうわけだから、
解釈次第でなんでもオブジェクトになりますって言ってるようなもんだし
なにか別の資料が必要になる希ガス。

432 :仕様書無しさん:2007/02/14(水) 06:28:27
>>425
んと、、、
「関係者」みたいな基本クラスを作って、それを継承させたのが「野球関係者」みたいなクラスで。
それぞれの「野球関係者」みたいなクラスには役割によって
「監督」「選手」「フロント」「コーチ」「審判」「得点係」「ウグイス嬢」みたいなインターフェースを持たせて。

例えば「選手」インターフェースには基本的な「投げる」「打つ」「取る」「走る」みたいな機能が入っていて、
その「選手」インターフェースを実装した「野球関係者」クラスを継承して
「ピッチャー」「キャッチャー」クラスなんかを作る。。。。

てな感じでどでしょ。



433 :仕様書無しさん:2007/02/14(水) 07:25:52
>>432
うざw
継承なんてあんまり突き詰めて使わないほうがいいぞ。
キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからw
しつこく使いまわした分だけバグが増えて行く。
コピペでうまくいく場合があることも理解するべき。

434 :仕様書無しさん:2007/02/14(水) 07:30:41
>>433

コピペは、論外、
あと、Javaのインターフェースって何かわかってる?

435 :仕様書無しさん:2007/02/14(水) 07:40:46
>>434
javaだって問題無いわけじゃないだろ?
swingなんてMFCより糞なありさまじゃんw

436 :仕様書無しさん:2007/02/14(水) 07:48:53
>>429
>>433
ひょっとしてデスマ渡り歩いてない?

437 :仕様書無しさん:2007/02/14(水) 07:53:47
>>436
何がいいたいの?
俺と俺の経験した環境を馬鹿にして俺のレス自体をひっくり返したいとか
そういう卑怯な論法ならもう飽きたよw
このスレだとそういうの多いからねw

438 :仕様書無しさん:2007/02/14(水) 08:12:33
BaseballPlayerクラスのコンストラクタを
BaseballPlayer(ポジションI/F,監督I/F)にするとか

439 :仕様書無しさん:2007/02/14(水) 08:15:19
じゃぁ、チームメイトとポジション固有の動作を切り分ければ良いね。
誰でもどのポジションに付けるし、兼任もできる。
ルールとして、複数のポジションを兼任するのは弾かないといけないけど。

440 :仕様書無しさん:2007/02/14(水) 08:16:55
クラスを関数の集まりとして使ったり使わなかったり

441 :仕様書無しさん:2007/02/14(水) 09:21:11
野球選手が芸能活動していたらどうなるだ?
新庄の引退前の状態(CM出演等)

442 :仕様書無しさん:2007/02/14(水) 09:23:03
野球選手がレストランを経営し、不動産投機を行い、株の売買をして
サッカーの中田みたいに企業の取締役だったらどうする

443 :仕様書無しさん:2007/02/14(水) 10:21:16
しかも愛人がいて愛人との間に子供がいて

444 :仕様書無しさん:2007/02/14(水) 10:31:55
>>433
>継承なんてあんまり突き詰めて使わないほうがいいぞ。
>キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからw

翻訳すると
『僕は最近最近ようやく「継承」を覚えて、その言葉をつかって話したくて仕方がないです。
「インターフェース」はよくわからないけど、似た感じのものだと思っています』

ということか。がんばれよw

445 :仕様書無しさん:2007/02/14(水) 10:40:44
検索結果
----Orekipedia-----
インターフェース
・多重継承が出来ないと揶揄されたために無理やり多重継承もどきを嘘でも
実現するようにしたジャワの糞仕様

446 :仕様書無しさん:2007/02/14(水) 10:42:46
なあんか、ジャワに実装するためのOO設計って
軽自動車のオーナーがF1出ますって言っているようで悲しいっス

447 :仕様書無しさん:2007/02/14(水) 13:18:21
委譲を使えば多重継承は必要ない。

448 :仕様書無しさん:2007/02/14(水) 14:06:08
>>441-442
そこまで行くと「野球の設計」の範疇では無いだろ。
スパコンで社会全体をシミュレートしたいなら話は別だが。

449 :仕様書無しさん:2007/02/14(水) 14:32:16
>>448
そうなんだけどね。しかしシステムが拡張されたときに
このような要件が追加できる設計ができたら>>448は神だよ。
ジャワ糞エンジニアには一人もいないけどね。

450 :仕様書無しさん:2007/02/14(水) 18:03:18
>>449
自分ができないことを指して人をけなすのって空しくないですかw

451 :仕様書無しさん:2007/02/14(水) 18:07:55
ジャワ糞で生きてて空しくならないですかw(半角)

昔からの言い伝え
全角を使う椰子にハイスキルは無し

452 :仕様書無しさん:2007/02/14(水) 19:25:09
>>444
煽ったつもりだろうけど
それをインターフェイスやら継承云々で解決するのは無駄じゃねぇの?
サブルーチンに必要な引数の絶対数からいってもう全然違うものを
こういうので解決するのって俺はやらないほうがいいと思うよ。

関数を呼び出す前準備から手順まで違うときなんかもあるだろうし。

はっきりいってこの問題だったらもう

bool actionA(※実際は関数名も具体的なものにして引数も2〜3個必要
bool actionB(※実際は関数名も具体的なものにして引数も5〜6個必要
bool actionCbegin(※実際は関数名も具体的なものにして引数も2〜3個必要
bool actionC(※実際は関数名も具体的なものにして引数も2〜3個必要
bool actionCend(※実際は関数名も具体的なものにして引数も2〜3個必要
bool actionD
bool actionE

※actionCは実行に関数を数個呼ぶ必要有り
※actionEはactionD実行中に呼ぶ必要有り、
 キャラタイプCから呼ぶときはactionDは実行できないかわりにactionEを直接呼ぶことができる。

とか実際はうまくまとまらないでしょ?

オブジェクト指向なんて捨てて
こんな感じでとにかくアクションの数だけずらーっと並べちゃって
これを適切に呼ぶ形にしちゃったほうがすっきりしそうだぜ。
もう、システムの仕様の気まぐれでどうにでもなる可能性を秘めているわけだから
オブジェクト指向なんて役に立たないと思うんだ。(少なくともこの場面では)

453 :おじゃばさま:2007/02/14(水) 19:48:04
>420
オブジェクト間の依存関係を減らす?
オブジェクトが交換可能と言う意味なら、継承だけでもいいだろう。
必要/不要の依存関係を指しているなら、実装は必要なので依存関係が減っている訳ではないだろう。

>423
そのドメインモデルを決めると抽象化されてしまうので、現実の物では表現が困難だと言っている。
あと、多重継承はいろいろな問題があるのでしたくない。無理にやればC++の二の舞いだ。
JavaにおけるIFはオブジェクト指向的ではないが、多重継承の代用としては現実的で無難な方法だ。
少なくともC++よりは遥かにマシだ。


454 :仕様書無しさん:2007/02/14(水) 20:08:38
746 名前: FM 投稿日: 2007/02/10(土) 13:46:59 ID:1v6kTVEm
昨日、仕事の帰りにインド人がやってるカレー屋に行ったんだけど、
カレー注文したらスプーンがついてこなくて
「あ、本格的な店なんだ」とか思って手で食ってたら、
半分くらい食ったときに、インド人の店員が奥から
すげー申し訳なさそうな顔してスプーン持ってきた



455 :仕様書無しさん:2007/02/14(水) 22:46:03
>>432
なんでこんな発想になっちゃうんだ?

なんつか、物自体に根源的な意味を求めるんじゃなくて
「外見」どう見えるかってところをモデル化するから
「オブジェクト」指向なんだろ?

456 :436:2007/02/14(水) 23:48:39
>>437
すみません
やっぱりデスマ渡り歩いているのね!
オブジェクト指向は良い道具だと思います
人間が道具に使われる心配はしなくて良いと思います
道具は臨機応変に取り替えればよいだけだと思います
JAVAでも、昔ながらの構造化プログラミングできますし
ところで野球について範囲を絞ったらどうでしょうか
ゲーム開始からゲーム終了までを考えると
各選手のインスタンスの寿命もゲーム開始から終了までとするとか
インスタンスの数=選手の数とするとか
選手以外のインスタンスは必要に応じて追加してよいだとか
どうでしょうか?

457 :仕様書無しさん:2007/02/14(水) 23:57:11
>>456
なんつーか、とにかく何でもいいからクラスにしたくてしょうがない!というふうに見える。

手当たり次第にクラス化していくんじゃなくて、クラスとして分類したほうが便利になる物を
クラスにするんだよ。

458 :仕様書無しさん:2007/02/15(木) 00:03:10
どっちでもいいけど業務内で統一が取れないのが問題なんだよな。
こだわりすぎるとドキュメント爆弾で埋もれる結果に。

459 :仕様書無しさん:2007/02/15(木) 06:56:16
ドキュメントなんぞいらん状態になるのが理想だがな。
状態をクラスでもってしまうとドキュメント爆弾を抱えることになる。
また、プログラム作るよりドキュメントを作るのが好きな奴がいるんだ。これが。
お前がアホなクラス作らなきゃ必要ねーっつーのw

460 :仕様書無しさん:2007/02/15(木) 07:03:56
コーディング段階でクラスを作るってどんな素人集団だよwwwww
これだから、まともなプロジェクトをやったこと無い人たちは、困る。
まぁ馬鹿だから、しょうがないけどな。


461 :仕様書無しさん:2007/02/15(木) 07:07:45
>>460
だって上からくる設計図からまともじゃねぇし。
いまから修正させてこっちに降りてくるのまってたら開発終わってんだよ。タコ。

462 :仕様書無しさん:2007/02/15(木) 07:10:05
メールのCCに偉い人のアドレス付けて送信する技術が必要になるよね。

463 :仕様書無しさん:2007/02/15(木) 07:26:25
>>461>>462

それは、そのプロジェクトが糞というだけで、
ドキュメントがいらないことを、示してないな。
っていうか、ドキュメントが糞で困ってるんだから
むしろ、ドキュメントが重要な事を示しているよな。

ちなみに
ドキュメント不要論者のバカマネージャー
http://pc10.2ch.net/test/read.cgi/prog/1163113144/
なんてスレもあったりする。

464 :仕様書無しさん:2007/02/15(木) 07:27:55
>>461
遅れた理由がこっちの責任でないことを丁寧に説明したpdfを書いて
メールのCCに偉い人のアドレスを付けて送信する技術があればおk

465 :仕様書無しさん:2007/02/15(木) 07:30:39
>>463
不要なドキュメントが必要になってしまうような設計がそもそも糞ってところを説明しなければならないのが難しいな。
ドキュメント書くのはいいけどね。
そもそもそれが必要になってしまうのはお前(設計した奴)がアフォだからってのを説明したいときはどうすればいいのだろか?

466 :おじゃばさま:2007/02/15(木) 09:49:55
一口にドキュメントと言っても、
要求仕様書、機能設計書、詳細設計書、操作説明書などがあるだろう。
プロトタイプ方式でも、要求仕様書と操作説明書は必要とされている。
今は詳細設計書を作っている所は少ないだろうから、機能設計書が必要かどうかの話だろう。


467 :仕様書無しさん:2007/02/15(木) 12:56:43
>>452
まず君は「オーバーロード」というものを覚えた方がいいな。
それから>>444が君の事を馬鹿にしてるのは
『投げる』という動作はインターフェースのメソッドだと言っているのに
>キャッチャーの投げるとピッチャーの投げるなんてどうせ別モンなんだからw
とか言ってるからだと思うな。

468 :仕様書無しさん:2007/02/15(木) 12:57:28
>>455
すいません、こんな発想で。

で、どんな発想ならよろしいんでしょうか。

469 :仕様書無しさん:2007/02/15(木) 17:03:39
>>467
オーバーロード?積み過ぎって何?

470 :仕様書無しさん:2007/02/15(木) 20:12:44
オーバーロード?

471 :仕様書無しさん:2007/02/15(木) 20:17:25
>>467
インターフェイスも引数変わったら終わりじゃね?

472 :仕様書無しさん:2007/02/15(木) 20:35:38
つ引数もオブジェクト

473 :仕様書無しさん:2007/02/15(木) 20:42:06
>>472
その逃げ方ってvoid*と何がちがうん?
結局必要っぽいもん全部放りこんどけw
ってことでしょ?
それと処理に実際に必要なもん以外に色んなモンが必要になって
結果的にプログラムがめちゃくちゃ汚くなるじゃん。

474 :仕様書無しさん:2007/02/15(木) 20:49:27
>>473

オブジェクトなら、必要なものだけ、設定できる。
void*とは全然違う

475 :仕様書無しさん:2007/02/15(木) 21:15:46
>>474
そんなことはないでしょ。
必要なものだけ設定すると引数がずれちゃうからクラスごと引数で渡すようにするんでしょ?
これを設計のズレととらずに許容範囲内の誤差として誤魔化すのがクラスで渡す方法の醍醐味でしょ?
void*も実際には似たような使い方すんだよ。
俺は別にまるで違うもんを設定することを危険とかいいたんじゃない。
こんなことをする必要が生じる時点でもうその設計は駄目だといいたい。

別に俺のやり方に従えとは言わんがたまには
なんで言語を作った奴は型を必要だと思ったのか?
また、型を誤魔化すってのはどういうことをすることか?
ってのを考えてみてほしいとおもう。
実際、こうやって引数の大枠を誤魔化して呼び続けるとどんな設計をしても表面上は問題が無いようにみえる。
(グローバル変数ですべてのデータをやりとりして、引数を1つも無い状態にしても同様)

476 :仕様書無しさん:2007/02/15(木) 21:19:46
>>475

君がクラスの意味がまるでわかっていないって事がわかった。


477 :仕様書無しさん:2007/02/15(木) 21:55:07
このカオス状態が開発現場の実態。
オブジェクト指向が流行らないんじゃなくて、
学習する、って当たり前のことができてないからだな。

478 :仕様書無しさん:2007/02/15(木) 21:59:11
まぁ構造化プログラミングの段階でもNGなコピペを進める馬鹿もいるし、
この国の情報産業は、もう駄目かもしれんね。

479 :仕様書無しさん:2007/02/15(木) 22:48:33
>>476
どうしてそう思うの?
反論してもらおうじゃんw

480 :仕様書無しさん:2007/02/15(木) 22:49:54
>>476
あ、俺は君がオブジェクト指向をわかったつもりになってるだけのレベルの低い開発者だと思ってるよw

481 :仕様書無しさん:2007/02/15(木) 23:07:45
なにいっても、難癖つけてくるから、無駄な事はしないよ。

482 :仕様書無しさん:2007/02/15(木) 23:11:16
>>481
>君がクラスの意味がまるでわかっていないって事がわかった。
だから、こういうスレでこんなレスつけちゃうんだよ。
自分の主張を説明できないならはじめっからレスなんてつけないでROMってろよ。
俺が君のレスをみて感じたことは「主張ができるほどプログラムを組んで無い」ってことだけだね。

483 :仕様書無しさん:2007/02/15(木) 23:20:41
なんでもいいけど、
このスレ内の認識のずれ(学習不足)のすさまじさが業界の現状をよく表してるわ。
オブジェクト指向だとか構造化だとか、
手法はなんでもいいから納品物として成り立つものを作るのが大事なんだよ。
一例だけど、
UMLとかの形式ばかりにこだわりすぎて必死に書いても、
ユーザーや技術未修得者に「分からん」と一蹴されるような手法でもあるんだから。
流行らない理由は分かりにくいことと、
「オブジェクト指向」なんていう意味が伝わりにくい名前だから。
まあ最初から学習放棄してる技術者もどうかと思うけど。

484 :仕様書無しさん:2007/02/15(木) 23:23:42
>>475

> これを設計のズレととらずに許容範囲内の誤差として誤魔化すのがクラスで渡す方法の醍醐味でしょ?
> void*も実際には似たような使い方すんだよ。

void*だと、呼び出し元を見に行かなきゃいけないだろ。
クラスによって、明確に定義されていれば、必要な情報のみ見れば良いだけで済む。

> 俺は別にまるで違うもんを設定することを危険とかいいたんじゃない。
> こんなことをする必要が生じる時点でもうその設計は駄目だといいたい。

設計として失敗だけど、後だしの仕様変更なら許容すべきでは?

> 別に俺のやり方に従えとは言わんがたまには
> なんで言語を作った奴は型を必要だと思ったのか?
> また、型を誤魔化すってのはどういうことをすることか?
> ってのを考えてみてほしいとおもう。

型そのものは、コンパイラにとっても、開発者にとっても必要だと思う。
型をごまかすという表現に拘ってるようだけど、
たどることが出来るならvoid*とは別物な訳で、
こういったごまかし方は、むしろ歓迎すべきでは?

> 実際、こうやって引数の大枠を誤魔化して呼び続けるとどんな設計をしても表面上は問題が無いようにみえる。
> (グローバル変数ですべてのデータをやりとりして、引数を1つも無い状態にしても同様)

別にグローバル変数を使って引数を無い状態を否定する権利はないが、
個人的には望まないし、選択しない。
最小限の情報で仕様変更が済ませるための一つの方法として、
オブジェクト設計がなされるべきで、目的に反する方法を選択する理由はない。

485 :仕様書無しさん:2007/02/15(木) 23:25:31
>>483
学習するのはいいけど
その前に何をもって「正しい」とするの?
本読むったってそれからいって著者同士で連携とれてるわけじゃないし、
所詮、その辺りはセミナー向けのでっちあげ教材な面も少なく無いじゃん。
ていうか、場合によっては100%セミナー教材じゃん。
そんなに自信があるなら、
使えるもんと使えないもんと選別してほしいんだけど。

486 :仕様書無しさん:2007/02/15(木) 23:27:41
>>484
は?意味がわからない。
とくに

>こういったごまかし方は、むしろ歓迎すべきでは?
こういったごまかし方ってどういったごまかし方?
非常に重要なところなんでぼかさないできっちり表現してみ?

487 :仕様書無しさん:2007/02/15(木) 23:31:01
>>486

> また、型を誤魔化すってのはどういうことをすることか?

だったら先に、こっちを説明してよ。

488 :仕様書無しさん:2007/02/15(木) 23:33:50
>>487
はぁ?なんで>>471,472,473,474,475,476の流れ見てわからない人がレスつけてるの?
場違いじゃない?

489 :仕様書無しさん:2007/02/15(木) 23:36:26
>>485
自分で何が使えるか使えないかも判断できないのか??
業務遂行に必要だけど未修得なら覚えればいいだろ。
不必要でどーでもいいならほっとけばいいだろ。

PJリーダーがトップダウンで「オブジェクト指向でよろしく!」って言ったところで、
下位作業者がわからんちん(オブジェクト指向を知らない)ならどうしようもないだろ。
オブジェクト指向ってのはあくまでも考え方。
言語(決まりを守らないと動かないもの)とは違うから
覚える努力というか度合いが各自違うわけ。
オブジェクト指向がPJの中で使えると判断するなら使えばいいし。

490 :仕様書無しさん:2007/02/15(木) 23:39:25
>>489
>自分で何が使えるか使えないかも判断できないのか??
それがみんなで噛み合ってないからスレが荒れることがわからないお前のがよっぽど無能だと思うよ俺はw

491 :仕様書無しさん:2007/02/15(木) 23:41:17
最低限

ドメインモデルとトランザクションスクリプトの違いが分かるようになってからここに来い。

492 :仕様書無しさん:2007/02/15(木) 23:43:22
>>490
483=489なんだが。

493 :仕様書無しさん:2007/02/15(木) 23:45:17
>>491
あんまり無茶言うと現場で浮いちゃうから気をつけろよ

494 :仕様書無しさん:2007/02/15(木) 23:45:41
>>492
別にアンカー間違ってねーんじゃねーのか?

495 :仕様書無しさん:2007/02/15(木) 23:47:53
>>494
ドメインモデル、トランザクションスクリプト、
なるほど、独りよがりが大好きなんですね。
わるいわるい

496 :仕様書無しさん:2007/02/15(木) 23:51:27
とりあえず金曜は飲み会デーだからそれでよし

497 :仕様書無しさん:2007/02/15(木) 23:57:32
じゃあ、各自、ドメインモデルとトランザクションスクリプトを勉強しておくということで

498 :仕様書無しさん:2007/02/15(木) 23:58:06
は〜い

499 :仕様書無しさん:2007/02/15(木) 23:59:09
開発言語がJavaだろうがC++だろうが実際人を集めると
10人中2,3人しか経験者がいなくて、残りが汎用機あがりやVBのみとかってことが
結構あったりする
自分がはずれを引きまくってるだけかもしれんが

500 :仕様書無しさん:2007/02/16(金) 00:05:34
>>499
それがほぼ現実だわな。
言語を考えた設計をきっちりやってることなんて皆無だしなあ。
なんとなく作り始めてなんとなく動いてる、そんな日本。

501 :仕様書無しさん:2007/02/16(金) 00:06:21
>>491じゃないけど、アーキテクチャとドメインモデルの関係を理解することが
C++なりJavaなりでオブジェクト指向設計を現場で実際に役立たすための第一歩だと思うな。

>>452からのやり取りも、このあたりがうまく整理できていないことが原因で話がおかしくなっていると感じる。

502 :仕様書無しさん:2007/02/16(金) 00:08:24
「アーキテクチャとドメインモデルの関係を理解することが第一歩だ」
と、プロジェクトで発言した日にゃあ、
「日本語で喋ってもらっていい?」
なんていわれそうだな。

503 :仕様書無しさん:2007/02/16(金) 00:11:26
アーティファクトってなーに?

504 :仕様書無しさん:2007/02/16(金) 00:12:39
成果物じゃなかったっけ

505 :仕様書無しさん:2007/02/16(金) 00:13:29
ドメインってPCに設定するドメイン?

506 :仕様書無しさん:2007/02/16(金) 00:13:30
人がつくったもの

507 :仕様書無しさん:2007/02/16(金) 00:13:35
>>502

俺の職場だと普通に通じるけどな・・・
格差社会ってやつ? < 違うか

508 :仕様書無しさん:2007/02/16(金) 00:15:45
>>500
その上、基本設計など大事なところは何故か業務知識重視で
JavaやC++経験者で業務知識があまりない人間より経験ないが業務知識あると
思われる人間のみで構成しようとして製造工程でいろいろ問題が出るのが最近のパターン
その上最近は、留学生という肩書きの中国人や韓国人までいるから、更にカオス度うp
こんな状態でOOを実践できるとは思えん

509 :仕様書無しさん:2007/02/16(金) 00:16:30
イネーブル(可)とディセーブル(不可)を
センシティブ(敏感)とインセンシティブ(鈍感)と
言ってる現場も格差社会の一つか

510 :仕様書無しさん:2007/02/16(金) 00:18:37
>>503

工芸品のことかな
★マークのついた武具だとか〜

511 :仕様書無しさん:2007/02/16(金) 00:18:47
>>509
ほざいてる本人からして意味がわかってなさそうな横文字使う奴って頭よさそうに見えない
頭がいい奴ってわかりやすい言葉を選んで説明してくれる奴ばっかりだよ

512 :仕様書無しさん:2007/02/16(金) 00:20:22
>>508
オフショア開発と言って祭り上げてるのを見たら・・・(泣
やっつけ仕事で手いっぱいだよ。。

513 :仕様書無しさん:2007/02/16(金) 00:20:31
まずはアーキテクチャとドメインモデルをわかりやすい言葉に直してみてくれ。

514 :仕様書無しさん:2007/02/16(金) 00:21:40
>>510
アーキテクチャの皮肉だろ
アーティファクトは考古学者が発掘したもんじゃね?

515 :仕様書無しさん:2007/02/16(金) 00:22:52
見える化ボードに「〜〜がエスカレーションを生む」とか書いてあるんですけど。
見えないんですけど。

516 :仕様書無しさん:2007/02/16(金) 00:33:40
>>489
> オブジェクト指向がPJの中で使えると判断するなら使えばいいし。

そういう判断もせないかんとは、PLとは大変な仕事なり。

>>499
> 10人中2,3人しか経験者がいなくて、

人転がし派遣をあてにしすぎればそういうことも多いかもしれんね。
おまいさんの上司がイクナイのかも。

>>507
ちょっとうらやましいかも。

>>513
激しくキボン

517 :491:2007/02/16(金) 00:35:18
>>495
>>502
・・・コボラーとか複雑なSQLが当たり前な人ですか?

オブジェクト指向が理解されない理由は現状Java使ったシステム開発でも必要性が感じられないからだ。

大抵どこのシステム開発でも設計時に、ビュー、エンティティ、コントロールは抽出するよな?
でも、ビューは画面、エンティティはただのデータ入れとく箱扱い。
だから、如何にコントロールが無理してチェック処理、計算処理を行うかにかかってる。

そういうシステムは馬鹿の1つ覚えみたくエンティティ貰ってはDBのテーブルにインサートするDAOと
一覧表示用に特化した超複雑なSELECT文発行してたりするDAOがある。

そんなんだからエンティティがロジックを持つってことが理解できないんだ。

オブジェクト指向で考えればDBなんてセッションタイムアウトとかガベージコレクションで消されないように
オブジェクトの生存期間を延ばすだけのただの箱に過ぎないんだよ。
いくらでも保持できる広大なメモリ量と鯖の電源切れない保証があれば全エンティティをメモリ上に蓄えておけばいい。

でもそんなわけがないから永続化したオブジェクトを簡単にメモリ上に展開できて、
尚且つ大量データの計算処理が得意なSQLも使えるRDBMSが便利だから使っているんだよ。

極論言えば永続化できて簡単にメモリ上に展開できればDBなんて不要でXMLとかファイルとかでも構わない。

518 :仕様書無しさん:2007/02/16(金) 00:38:51
>>517
昨日もらったチョコレートを
まで読んだ

519 :仕様書無しさん:2007/02/16(金) 00:46:52
>>517
ごめん。基本的なこと聞いていい?
JavaなのにDAOなの?
自分の知識が無いだけかな?

520 :491:2007/02/16(金) 00:50:23
1年に1回やってくるバレンタインデー。
でも俺は生まれて1度も本命チョコレートをもらった試しがない。いつも義理チョコばかりだ。
昨日もらったチョコレートを今日1つだけ食べた。もちろん義理チョコだ。
義理チョコを食べながら俺は泣いた。
どうしてバレンタインデーなんてものがあるのか・・・俺にあるのはデスマーチの毎日と納期だけだ。
くそ・・・っ、ビルの屋上からあの幸せそうなカップル目掛けて童貞万歳と叫びながらダイブしてやる・・・っ

521 :仕様書無しさん:2007/02/16(金) 00:51:06
つDataAccessObject=DAO

522 :仕様書無しさん:2007/02/16(金) 00:52:18
JavaでDAO使ってる俺って・・・orz

523 :491:2007/02/16(金) 00:52:59
>>519
ん、J2EE時代からよくあるレイヤ構造でいうと
プレゼン層、ビジネス層、データアクセス層(DAO)って感じで分かれてるね。
ビジネスロジックから直接DBアクセスしたりすると、ストレージが変わったときの修正が有り得んから。
SQLでもOracleやPostgreSQLで書き方違ったりするだろ?
その辺吸収するのがDAO層。

524 :仕様書無しさん:2007/02/16(金) 00:53:27
Javaだろうが何だろうがDAOは使うだろ。

525 :519:2007/02/16(金) 00:57:55
MS AccessとかのDAOと思っちゃったよ。

526 :仕様書無しさん:2007/02/16(金) 01:07:11
ビジネス層からDAO層に渡すのは
DataTransferがいいのかEntityがいいのかがいまだに判断がつかん

527 :仕様書無しさん:2007/02/16(金) 01:14:16
現状DTO使うしかないのでは。

528 :491:2007/02/16(金) 01:18:22
ぶっちゃけどっちでもいいかと。

あえて言えば

トランザクションスクリプト的観点から言えば前者。
DAOを独立したデータベースアクセス機能としてIF切るのであれば、ビジネス層のデータに依存するのはよろしくない。

しかしドメインモデル的観点から言えば後者。
永続化はビジネス層の一部の処理で、サービスクラスがオブジェクトの生存期間を延ばすために行うもの。
だから単純にDAOに対して、「このインスタンスどっかに永続化しといて、あとで使うから。」的に利用するものだと思われ。

529 :491:2007/02/16(金) 01:19:03
ちなみにhibernateとかいうORマッパ使うなら後者が必須ですよ。

530 :仕様書無しさん:2007/02/16(金) 01:28:52
>ちなみにhibernateとかいうORマッパ使うなら後者が必須ですよ。
必須ってことはないだろ。というか、必須の意味がわからない。

531 :仕様書無しさん:2007/02/16(金) 01:31:21
一連の流れを見てると
なぜオブジェクト指向が流行らないのかがよく分かる。
理解してる者の発言を見ればみるほど、
理解してない者がどんどん冷めていくんだろうな。

532 :仕様書無しさん:2007/02/16(金) 01:34:21
ドメインモデル、トランザクションスクリプト

テーブルモジュールは無視かよ(笑

533 :仕様書無しさん:2007/02/16(金) 01:35:26
>>531
なんでそう思う?

534 :仕様書無しさん:2007/02/16(金) 01:37:18
1レコード1DTOとして設計してるかぎりは前者ってこと。

hibernateはロードしたオブジェクトに変更くわえればトランザクションコミット時に自動でDBに反映されるからさ。
サービスでオブジェクト操作するんだからサービスまでエンティティもってこないと…
返り値はエンティティだから保存時もエンティティ。

535 :仕様書無しさん:2007/02/16(金) 01:37:41
コーディングも設計に含まれるわけで。

536 :仕様書無しさん:2007/02/16(金) 01:39:16
>>533
オブジェクト指向で使われる用語が親切じゃないからだよ。
ひたすら横文字で寄せ付けないオーラが出てる。
フリーになった奴が青色申告すると気合入れたはいいけど、
会計用語でへこむのと似てる。

537 :仕様書無しさん:2007/02/16(金) 01:43:39
>>531
中途半端にしか理解してない俺は確かに冷めてくる。
けれども、素人でもすぐに理解できるようであれとは思わない。

538 :仕様書無しさん:2007/02/16(金) 01:47:30
>>536

そういう人は適正がないから、PGをやめるべきだと思う。
正直、あまり良い職業じゃないし、他の道をさがせば。


539 :仕様書無しさん:2007/02/16(金) 01:48:41
ひたすら横文字なのは、対応する日本語(つか概念)がないからじゃね?
アーキテクチャをうまく訳せるか?

540 :仕様書無しさん:2007/02/16(金) 01:51:13
>>538
同じことを現場で言えるなら大したもんだけどね。

541 :仕様書無しさん:2007/02/16(金) 01:52:29
アーキテクチャ=設計概念
じゃだめ?

542 :仕様書無しさん:2007/02/16(金) 01:55:37
プロ管ドキュメント用語をひたすら日本語にして威張っていたやつが客にいたな。

WBS->課題管理表
Q/A->質疑応答一覧

など

543 :仕様書無しさん:2007/02/16(金) 01:57:33
追加。
WBSを課題管理表というのは明らかに違うとオモタが、
指摘したら逆切れされたので言わなくなった。

544 :仕様書無しさん:2007/02/16(金) 01:57:43
システム構成とかアプリケーションの内部構造とかフレームワークじゃね?
ハード、ソフトひっくるめていうこともあれば分けていうこともある。

545 :仕様書無しさん:2007/02/16(金) 02:01:02
アーキテクチャ=歯車
ドメインモデル=歯車の上で回るもの

546 :仕様書無しさん:2007/02/16(金) 02:06:48
全然予想もつかん横文字よりも
それなりに予想が付く日本語の方がまだマシだろ。
WBSなんていわれるよりも作業構成図とか分担表とか、
微妙に間違っててもなんのことかは分かる。
WBS=ワールドベースボール?なんて思われるよりマシ。
フレームワークも「アプリの土台です」って言えばそれなりに伝わるし。
相手が理解できるかどうかが分からんまま使うぐらいなら、ってことで。

547 :仕様書無しさん:2007/02/16(金) 05:02:39
>>540

むしろ、てめえが、横文字はわかりませんって現場でいえるのかって
言いたい、もし俺の前で言う奴がいたら、明日からこなくていいよって言ってあげるよ。

548 :仕様書無しさん:2007/02/16(金) 06:24:52
そもそも現場でオブジェクト指向が有効な理由を説明できた奴もいないがなw
このスレでも延々続いてるけど、まだ誰もオブジェクト指向が「従来」の方法より優れていることを説明できた奴がいない。

549 :仕様書無しさん:2007/02/16(金) 07:35:40
そもそも現場でオブジェクト指向が無効な理由を説明できた奴もいないがなw
このスレでも延々続いてるけど、まだ誰もオブジェクト指向が「従来」の方法より劣ってることを説明できた奴がいない。



550 :仕様書無しさん:2007/02/16(金) 07:40:41
>>548-549
どっちかができても進展はありそうだがなw

551 :仕様書無しさん:2007/02/16(金) 08:03:48
横文字並べたり、鼻っから説明することを諦めたり、
横文字わかんねぇーなら適正ねー、とか突っぱねるやつが、
現場でのオブジェクト指向に対する敷居を高くしてるんじゃないのか?


552 :仕様書無しさん:2007/02/16(金) 08:19:28
俺は大昔汎用機のCADを開発、メンテナンスしていたのだけど
1つのEXEでできていて、ソースコードをA4で印刷(当時ようやくレーザープリンターが出始めた頃)すると
厚さが1.5mくらいあったのよ
言語はFORTRANで書かれていて(一部アセンブラ)、
コメント見ると「これ以上追えん」とか書かれていて
変数も足りなくてこっそり違う変数(配列)を借用してたりして
まさにカオスでした
構造化プログラミングの限界だったようでした
一部の人が今のオブジェクト指向みたいなものを取り入れて
作っていましたが、単なるルールに過ぎず、なかなか守られなかった記憶があります
そんな経験があるから、オブジェクト指向は便利だと痛感します

553 :おじゃばさま:2007/02/16(金) 10:04:39
>552
まず構造化プログラミングが大規模開発に向かないというのは誤りである。
構造化プログラミングと言うのは、大規模開発用に開発された物だからだ。
大昔のCOBOLやアセンブラでは殆ど構造化プログラミングされていない。
つまり552は始めに構造化プログラミングを学ぶべきである。

オブジェクト指向プログラミングは、そんなに難解な訳ではない。
簡単に言うと構造化プログラミングが「データをグループ化する」のに対して、
オブジェクト指向プログラミングは「データと処理をグループ化する」のである。
ただしマスターするには時間がかかる。
実装方法を例に説明しよう。
まず構造体を作る要領で項目を抽出する。その項目をプライベートフィールド変数としてクラスを作成し、
それにアクセスするセッターとゲッターを作成する。そしてそのセッターとゲッターに処理を追加して行く。
最初はこれで進めよう。修正や仕様変更を進めるうちに、どこクラスやメソッドに変数や処理を入れる
べきなのか分かってくるだろう。
これが分かってきたら次の段階の「継承」に進むが、長くなるのでまた今度。


554 :おじゃばさま:2007/02/16(金) 10:09:14
オブジェクト指向の優れている点は、すでに説明済みだが、変更のしやすさである。
端的に説明すると、「DBがORACLEからPostgresに替えてくれ」と言う無茶を可能にする物である。

555 :仕様書無しさん:2007/02/16(金) 10:10:16
>構造化プログラミングと言うのは、大規模開発用に開発された物だからだ。
違うってば

556 :おじゃばさま:2007/02/16(金) 10:23:46
どう違うのだろうか?

557 :仕様書無しさん:2007/02/16(金) 10:43:38
もう莫迦晒さず黙ってろよ>おじゃま

558 :仕様書無しさん:2007/02/16(金) 10:51:58
ここ議論が活発でいいね。

全部読んではいないけど、一言発言させてくれ。
OOPも構造化も、その効用の一つには「カプセル化」、そして結局「コンポーネント化」、
そしてそれによる「容易な再利用可能化」が最大の利点だったかと思う。

つまり、仕事を分業して部品の機能に自動的に任せるところは任せて安心できる
環境を作り、どれだえk効率化できるか、生産性を上げられるか、ってところに
本来の眼目があったのがこういう近代的プログラミング手法の最大の目的が
あったはずだと思うんだけど、どうだろう。

そしてそれによってデバッグも効率化し、またメンテナンス性も向上し、と
至れり尽くせりの開発環境、保守環境が待っているはずだったのでは。

とすると、その目的が達成されるものであれば、本来は小やかましい哲学論
や宗教派閥論争にはでしゃばってほしくはなかったはずで、なんでこの時点でも
まだまだこのシステム工学の原点に関係して開発と保守の現場で問題が
ぬぐえないままなのだろうか?

わたしはこの本来の目的であった原点をこそ最重要視した改善こそが望まれる
のだと考えるわけですが・・・・・どうでしょうか。

559 :仕様書無しさん:2007/02/16(金) 10:54:28
あるいはもしかすると、OOPになっても、それでもまだまだ当初の目的であった
ことどもはなんら達成されてはいない、ということだのろうか、とも思った次第。

どうでしょうか?

560 :仕様書無しさん:2007/02/16(金) 11:12:01
ソフトウエア工学はバグが全くないと検証テストされた
たった1行のコードにバグが存在する可能性があるという
排他的論理和状況が常に存在する。それは処理するコード自体に
確かにバグはなくともそれに渡すデータにバグがある可能性が否定できないからだ。
このようなソフトウエア工学の現実を理解せずに他人が積み重ねた膨大なコード
をなんの疑いもなく再利用できる理想論としての完全主義者が考案したOO理論は
公約の果たせない政治家のようなものである。

561 :仕様書無しさん:2007/02/16(金) 11:19:19
>>558-559
解決/改善/達成はなされていない。
この問題は管理工学や組織論や要素還元主義に代表される哲学等の
所謂パラダイムシフトに関わっているからだ。
なぜならソフトウェアは人が創るものであるから。

プログラミング手法の進化だけでは解決する問題では無いのです。
一般的な表現をするなら、

局所的な最適化は全体の最適化に直結しない。

そして・・・
スレ違いです。

562 :仕様書無しさん:2007/02/16(金) 12:03:45
何故流行らないのか?
実践できる環境・人材が集まらないから

563 :仕様書無しさん:2007/02/16(金) 12:35:32
オブジェクト指向の理解なんて頭の良し悪しには関係ないんだよ。何故な
ら人間が普段の生活で気づかずに実践しているから。
Aさんは手先が器用とか、Bさんは絵を描くのがうまいとかっていう人の
属性や、ひもをひっぱると電気がつくとかっていうインターフェースをみ
んな何気に認識してんだよ。向上心をもって1年もやれば十分身につくし、
2年もやれば最善策もわかってくる。わかんないっていってる奴は向上心
もたずに、機ぼーっと械的にやってるからなんだよ。勉強しろ。

564 :仕様書無しさん:2007/02/16(金) 12:42:49
勉強始めて2年後の俺


565 :仕様書無しさん:2007/02/16(金) 12:48:11
>>561
「スレ違い」じゃないんじゃないかなぁ、と

というのは、目的が存在しない行動は本来的にあり得ないし、
そもそもが社会の発展をになう系沿い活動が根本である以上、
その構築に資する、そして資してきたはずの現代文明の道具たるはずの
「自動計算機」が、「使い物にならない」状態はほおっては置けないはずでは?

お金を掛けて世の中を駆動していくはずの道具が有効じゃない状況は
まちがっているし、効率的でないならそれを改善する本質論から始めないなら
元々の意味を外しているに違いないと思うのだが

566 :仕様書無しさん:2007/02/16(金) 12:48:53
系沿い活動が -> 経済活動

567 :仕様書無しさん:2007/02/16(金) 12:59:29
>そもそもが社会の発展をになう経済活動が根本である以上、
そもそもが社会の発展をになう経済活動が「Xの」根本
OR
そもそもが社会の発展をになう「Xは」経済活動「の」根本

何れにしても、「X」がなんなのかをはっきりしてもらいたい。

568 :仕様書無しさん:2007/02/16(金) 13:06:59
まぁ豚どもにいくら日本語しゃべろっていっても無理だからなぁ。
根本から間違っていたってことか。つうか、豚語で書かないと豚は理解できないよ。>>565

569 :仕様書無しさん:2007/02/16(金) 13:11:56
(´・ω・`) 根本からブー

570 :仕様書無しさん:2007/02/16(金) 13:13:29
真っ赤になって自演してるところが痛ましいw

571 :仕様書無しさん:2007/02/16(金) 13:33:53
>>567
そもそもが社会の発展をになう経済活動が「Xの」根本

-> そもそもが社会の発展をになう経済活動が「あらゆる事業の」根本

であります。

572 :仕様書無しさん:2007/02/16(金) 13:52:19
あらゆる事業をとおして、社会に相互の関係性をもたらすことを経済活動とよぶのでは?
「根本」の使い方間違っているよ。

573 :仕様書無しさん:2007/02/16(金) 13:54:22
>>572
じゃあ言うが、あなたは今日朝飯食べないとおなかへって仕事に打ち込めない
だろ?それを言ってるだけだよ、簡単に言えば。

つまり経済効率を追求しない事業はあり得ないし、哲学論で飯食ってる
わけじゃないだろってことだよ

574 :仕様書無しさん:2007/02/16(金) 13:55:48
だから、結果として効率追求できてないなら哲学論に価値はないってことであり、
また、トータルでの経済効率で勝つ方法論が最終的に解が「正解」であるはずだと。

575 :仕様書無しさん:2007/02/16(金) 13:56:56
すまん、
トータルでの経済効率で勝つ方法論が最終的な「正解」であるはずだと。

576 :仕様書無しさん:2007/02/16(金) 14:03:14
>おなかへって仕事に打ち込めない
何の話してんだよw「要は」が口癖のバカを思い出した。

577 :仕様書無しさん:2007/02/16(金) 14:04:46
いまは本当に経済効率としてのビジネスになっているのかどうか、そこだな。

578 :仕様書無しさん:2007/02/16(金) 14:08:29
>>571 はたぶん、
「そもそも経済活動が社会の発展をになっている以上〜」
って書きたかったんじゃないかなぁ。ちょっと説明下手なだけなんだよ。
そのぐらい察してやれよ。大人気ない。

579 :仕様書無しさん:2007/02/16(金) 14:11:39
えっらそーな文面で説明下手ってどないやねん!!

580 :仕様書無しさん:2007/02/16(金) 14:11:40
>>576
わからないのかなあ、おなかを満たすのが経済活動、
いくら哲学語っても、社会には結果として貢献しないなら意味はないと。
哲学でおなかはいっぱいにならないんじゃないのと。

結果として効率化してそれで飯が食えるんだというのならいいけどな。
仮に奇跡が起きて中国やインドが仕事の品質上げてきて日本からPGが
一切いらなくなる事態だってあっても、それ自体不思議というわけじゃないよ。

581 :仕様書無しさん:2007/02/16(金) 14:15:33
>>578
まあ下手といえば下手だけど、意味は「根本」は結果としての価値が重要だという話、
根本を忘れて大哲学に浸かっていてもしかたないでしょうと。

582 :仕様書無しさん:2007/02/16(金) 14:16:19
>> 580 もちつけもちつけ、文体がおかしくなってきてるぞ。

583 :仕様書無しさん:2007/02/16(金) 14:16:39
これは、日本語でおkを引き出すゲームか何かか?

584 :仕様書無しさん:2007/02/16(金) 14:19:01
話は、OOが組織論や人間論の問題とは別だという話から来ている。
で、それでは済ませられないんじゃないの、という話。

585 :仕様書無しさん:2007/02/16(金) 14:20:56
だって、仮に上司が頭が悪くていい方法提案してるのにわかってもらえない、
これはOOの問題じゃなくて、組織の問題だ、-> だからコンピュータは
あまり使い勝手のいいものにならないんだよ、って話はおかしいってことです.


586 :仕様書無しさん:2007/02/16(金) 14:42:50
普及を目指す道具や方法論にとっては、ユーザーの頭の悪さを乗り越えることこそ、
重要なブレイクスルーだと思う。
ユーザーの頭の悪さを嘆くUNIXを尻目に、Win95が爆発的に普及していったのは、
それを裏付ける出来事だった。いまだにTexを押し付けてくるダメおやじがいるけど、
はっきり言って、氏ねよって感じ。

587 :仕様書無しさん:2007/02/16(金) 15:29:40
ある意味面白そうなんでコテにしてくれw >>584-586

588 :仕様書無しさん:2007/02/16(金) 15:40:55
>>586は賛同者、ウレしーわ。

589 :仕様書無しさん:2007/02/16(金) 16:49:25
OO厨は、OOには得手不得手があるってことを認めたがらないところが痛い。
そして、なぜか周りに押し付けだすから性質が悪い。

590 :仕様書無しさん:2007/02/16(金) 17:23:51
>>589
それはエクリプスのプラグイン厨しかり
ひいては根幹のジャワ糞がスーパークラスという事に行き着く

591 :仕様書無しさん:2007/02/16(金) 17:29:41
ワロタw

このスレを見ている人はこんなスレも見ています。(ver 0.20)
[プログラム]
[テレビドラマ]
[転職]
[就職]
[就職]

ここは失業者の巣窟ですね。

592 :仕様書無しさん:2007/02/16(金) 17:37:16
ほんとだw
JavaやるとC++は有害に感じる
がジャワ糞の証でもあるな

593 :仕様書無しさん:2007/02/16(金) 17:58:54
老人がいくら戯言をほざいても
この先も、オブジェクト指向が主流でありつづけるのは、間違いないのだが、
まぁ老害は、趣味でアセンブラでもくんでな名wwwww

594 :仕様書無しさん:2007/02/16(金) 18:16:02
20年前の当時の若者の台詞より・・・
 老人がいくら戯言をほざいても
 この先も、構造化プログラミングが主流でありつづけるのは、間違いないのだが、
 まぁ老害は、趣味でgoto文でも書いてな名wwwww


595 :仕様書無しさん:2007/02/16(金) 18:17:24
この時間帯は喰い付き悪いな名wwwww


596 :仕様書無しさん:2007/02/16(金) 18:23:03
構造化自体は、今でも重要で、
goto文全盛の時期は、戻ってきてません
OO批判がOO+αの技術こそが次世代技術って言うのなら
正しいと思いますが、老害どもは、昔に戻せというばかり、
あきらかにgoto文と同じで時代の遺物ですな。


597 :仕様書無しさん:2007/02/16(金) 18:24:49
20年後の俺の息子の台詞より・・・
 老人がいくら戯言をほざいても
 この先も、センシティブミキシングが主流でありつづけるのは、間違いないのだが、
 まぁ老害は、趣味でクラスでもつくってな名wwwww

598 :仕様書無しさん:2007/02/16(金) 19:08:36
オブジェクト指向自体は、今でも重要で、
アセンブラ全盛の時期は、戻って(Ry

599 :仕様書無しさん:2007/02/16(金) 19:38:35
40年前の当時の若者の台詞より・・・
 老人がいくら戯言をほざいても
 この先も、電卓が主流でありつづけるのは、間違いないのだが、
 まぁ老害は、趣味でそろばんでも使ってな名wwwww

600 :おじゃばさま:2007/02/16(金) 19:59:41
オブジェクト指向と言うのは結局の所、「オブジェクト指向プログラミング」の事であり、
プログラムの詳細設計に用いる物である。
ソフトウェア工学(どのようにしたら高品質な物を低コストで作れるか)の観点から言うと、
現在の時点で最も有効なのは、「プロトタイプ方式」である。
ソフトウェアの品質が悪いのは、多くの場合、試験を行っていないのが問題であり、
現代においては特に「単体試験(分岐全ルート試験)」を行ってない事による場合が大半である。
実際、大手のベンダーでも分岐全ルートの単体試験と言っても、何のことか分からない中堅も多い。

つまり現代においては「プロトタイプ方式で、JavaやC#などを使い、オブジェクト指向プログラミング
で作成し、単体試験をしっかりやる」事で殆どの問題が解決する場合が多い。
ちなみに、「プロトタイプ方式で、Cなどを使い、構造化プログラミングで作成し、
単体試験をしっかりやる」事でも同様である。
と言うか、「プロトタイプ方式で、単体試験をしっかりやる」だけで殆どの解決である。
つまり、プロジェクトの成否と言語や設計技法は関係ない。


601 :仕様書無しさん:2007/02/16(金) 20:01:15
↑聞いたことない。次、↓

602 :おじゃばさま:2007/02/16(金) 20:04:05
聞け

603 :仕様書無しさん:2007/02/16(金) 20:12:21
>>553
おじゃば、嘘おしえんなよ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って単語の意味を教えてくれないか。

607 :仕様書無しさん:2007/02/16(金) 20:18:44
>>600
>つまり現代においては「プロトタイプ方式で、JavaやC#などを使い、オブジェクト指向プログラミング
>で作成し、単体試験をしっかりやる」事で殆どの問題が解決する場合が多い。
こんな強引な理論はじめてきいたよ。現場にいないとこんなんなっちゃうのか?

608 :仕様書無しさん:2007/02/16(金) 20:34:34
俺はテスト駆動に夢中さ

609 :491:2007/02/16(金) 20:40:23
ぬるぽだ配列インデックス例外だのコーディングバグだの単体はおいといて、

結合バグの大半は業務のステータスとモデルの状態との関係が満たされないことによる事前条件違反呼び出しだよ。

実行したのはいいが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"  |  | |

612 :仕様書無しさん:2007/02/16(金) 21:04:06
>>609
あなたが結局何を言いたいのかなんだかびみょーによく分からない。豚語でしゃべってみてくれ。

613 :仕様書無しさん:2007/02/16(金) 21:17:02
まぁまぁOOP厨。これ見てもちつけ

つ(継承 ポリモーフィズム カプセル可)

614 :仕様書無しさん:2007/02/16(金) 21:23:28
>>613
哲学すきですからw

615 :仕様書無しさん:2007/02/16(金) 21:28:27
>>612

発覚するバグの多くは、データがDBに無いのにそのデータを処理しようとするのが原因ってことですよ。

例えば、ログイン処理はIDからユーザ情報ひっぱってきてパスワード比較するでしょ?
でも、これはあらかじめユーザ登録したときにちゃんとIDとパスワードを登録しないとだめだよね。
当然こんなことが起きることは誰でも想定できるからエラーだったら画面にメッセージ出して知らせることが出来る。

でも、もっと複雑な情報(テーブルが100個とかの場合には
データが入ってると思っていたテーブルにレコードが無いことが往々にある。

さらにレコードが無いなら入れればいいだけなんだけど、
カラムの値も想定しない値だった場合には・・・気づきにくいよね?
こんなことはもう頭の中では想定し切れないからバグるんだよ。

616 :仕様書無しさん:2007/02/16(金) 21:28:44
>>600
結局そういうことなんでしょうが、つまり手抜きはできないってことで、
手抜きすれば品質が落ちる、しかししっかりやればコストが掛かる
コスト掛けてもよければいくらでもデバッグやりすぎるということはないはず
しかし結局それでコストかかれば元が取れないことに

要するにソフトウエアは人間が作る限界を越えられず、面倒なテストを
たくさんうあればどうしても効率が落ちてしまい、儲けもなくなってしまう結果に

>>609
それでもどうしても抜けはでますよね、人間ですからね。

でも>>600>>609でしっかりやれば初期不良程度の被害で済ませられる
ぐらいに品質は向上し致命的な欠陥を残さないで済む確率が上がる
結果として商売は継続可能な程度に仕事ができることになると、こういう
ことですよね w

617 :仕様書無しさん:2007/02/16(金) 21:34:40
要するにソフトウエアは人間が作る限界を越えられず、ということは、OOPでどんなにか
やってみても、やはりテストで格闘することには変わりはないわけで。

ただ、トータルでメリットがあるからそうしているのだと、いうことでなければ商売には
ならないわけでもあり、結局は商売として成り立つ成り立たないかによって判断されるしかない。

つまりは経済原則上の天秤で勝つか負けるかの問題に帰着するわけです、
OOPも価値論もすべて.

618 :仕様書無しさん:2007/02/16(金) 21:51:36
>>発覚するバグの多くは、データがDBに無いのにそのデータを処理しようとするのが原因ってことですよ。

そもそも何故DBの使用が前提になっているのかが分からない。DBまわりでしかバグって発覚しないのか?
そして文の意味がわからない。「データがDBに無かったらそのデータを処理しない」っていうのが仕様で、
それをプログラムで処理しようしたという状況の話なのかな・・・
普通、DBにありえないデータは制約を設定しとかない? あとは例外投げたりとか。 発覚するパグの多くが〜
って飛躍しすぎじゃない? それと、なんだかその辺の本やWebに書いてあるような安っぽい話を偉そうに書か
れてもって感じだが豚の俺にはよくわからないな。はずしてたらすまん。

619 :仕様書無しさん:2007/02/16(金) 21:52:39
あ、>>618>>615に対してね。

620 :仕様書無しさん:2007/02/16(金) 22:01:56
>>618
横レスだけど概ねバグってものの意味としては当たってると思うよ。
DBに限らず、要するに想定外の環境状況だってことでしょ。「想定外」は
要は設計の問題だとも言えなくもないけどね。設計でその仕様環境が
想定されているべきはずなのに、そこに漏れがあるために途中で想定外の
動作となってしまうと。

それは例外を投げるとか投げないとかじゃなくて、投げても結局は
想定外なんだからそれ以上の対応はできなわけでお客にとっては
要するにバグ、動かないものは価値がない、それだけってことで。

これは例外ですと自分のプログラムで出そうと、開発環境が出そうと
品質が悪いことには本来的には変わりはない、つまり、目的の結果を
達成できていないという業務目的のロジックという本来の商品目的が
外れているなら、いくらOOPの哲学ぶってもどうしようもないわけでしょ。

621 :仕様書無しさん:2007/02/16(金) 22:06:34
そういうときに、OOPならメンテナンス性も上がっていってバグへの対応も高速で
効率的で弊害もごく少なく対処できるようになっています、というふうにならない
のなら、OOP的に作られていますと言っても認めてもらえないかもね。

622 :仕様書無しさん:2007/02/16(金) 22:09:14
>>620
やっぱり分からんぞ。なんで「例外」=「品質が悪い」になるんだ?
例外ってビネスロジックエラーにも普通に使うだろ? バグじゃないだろ。
もしかしてシステム例外に限定した話になってる? 
データが無い=システムエラーってことか? そりゃ設計が悪いか制約の
設定漏れだろ。プログラムのバクではない。ましてやOOPとは関係ない。

623 :仕様書無しさん:2007/02/16(金) 22:11:49
結局OOPですとは言え、目的はビジネスロジックの実現であり実装がより
完全になるようにすることで商売がいいものになることでなければならず。
OOPでなかった時代だっていい仕事する仕事師は設計がやはり良かったと
いえばOOPだからすべて解決するというのは空想論なのでは。結局商売を
成功させるのは、OOPが必要条件だ、ともいえず、また当然ながら十分条件
でもない、ということなのでは。


624 :仕様書無しさん:2007/02/16(金) 22:16:15
OOP使って書いたほうが書きやすい俺は異端なのか?
クラス無しだと書きにくいっつーか
ローカルインナークラスまで含めると
小さなコードでも10クラス、大きなコードなら自然と数十クラス〜100越えになるんだが

625 :仕様書無しさん:2007/02/16(金) 22:17:26
ええい、誰が何書いてんのか分からんわい。お前ら酉つけろ。

626 :仕様書無しさん:2007/02/16(金) 22:29:00
>>622
例外が品質悪い、のではなくて、想定外の状況がたくさん出てくる、というところに
問題が生まれるのだ、ということでしょう。

想定外がたくさん出てくるということが、OOP的でなかったからなのか、それとも
OOPだったのにそうなったのか、それがもしOOPと関係なく、OOPであってもなくても
想定外が多いのだとしたら、結局OOPの良いほうへの寄与率は50%で必ずしも
品質上げることに寄与しない、ということになって、そうだとしたらOOPの価値は
言われるよりも低いじゃないか、ということでは?

627 :仕様書無しさん:2007/02/16(金) 22:38:13
>>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);
}
}

628 :仕様書無しさん:2007/02/16(金) 22:38:36
想定外の状況がたくさん出てくるってことは、OOP云々以前にそりゃ設計が悪いだろ。

629 :仕様書無しさん:2007/02/16(金) 22:38:44
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が出るだろ。
テーブルの状態、エンティティの状態がおかしいからこうなる。

630 :仕様書無しさん:2007/02/16(金) 22:42:09
もう、あれだ。ぷちオブジェクト指向でいいんじゃね?

631 :仕様書無しさん:2007/02/16(金) 23:01:42
>>630
中途半端なOOPならまだやらないほうがマシ。
ER図書いて処理はSQL、ストアドプロシージャでやればいい。

理由はDAO用のエンティティクラスに詰め替えるのが面倒だから。
エンティティクラス作るのならOOPやればいいじゃん?

632 :仕様書無しさん:2007/02/16(金) 23:14:26
>>629
だから、それを「テーブルの状態がおかしい」とするなら、passwordカラムに
「NOT NULL制約」をつけなかった設計者がバカだっつってんの。あったく

633 :仕様書無しさん:2007/02/16(金) 23:19:01
>>632

だから分かってないね・・・
じゃあ、NULLじゃなくて「必ず3レコードある」という制約は?

クラス図だと1対3といった個数制約。
その前提に基づいてクラスメソッド設計されるっしょ?
でも2個しかなかったら?どうDBの制約でカバーするの?

634 :仕様書無しさん:2007/02/16(金) 23:29:03
>>633
「必ず3レコードある」・・・なんだよそれ。
それがクリティカルな条件ならトリガ使うとか関数やストアドでロジックを局所化
するとかするだろうけど。
話の論点が変わってきているけど、結局そんな状況でプログラムに発生するバクっ
て別にDBに限った話じゃねぇじゃねぇかよ。

635 :仕様書無しさん:2007/02/16(金) 23:32:51
なんかね、こんな状態じゃあ、まだまだだね。
でも、そんな人を相手に商売しているから馬鹿にできないんだけどね。
みんな、まいどあり〜って感じだよ。ほんとに…

636 :仕様書無しさん:2007/02/17(土) 00:03:30
>>633
クラス図1対3でしょ? テーブルAとテーブルBだとして、テーブルA側に
Bの主キーフィールド3つ設けて、それらに外部キー制約つけるってのは?
これが何十個とかなったら、そうだなカウント用のテーブル設けて、その
カウントフィールドに 整合性制約つけるってのは?

スレ違い失礼・・・ただ設計で取り除けるリスクは極力そうするべきだね。

637 :仕様書無しさん:2007/02/17(土) 00:03:58
亀ですが
トランザクションスクリプト・ドメインモデル・テーブルモジュールの概要はこちらでどうぞ。

エンタープライズ・アプリケーション・アーキテクチャのパターン
http://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html

638 :仕様書無しさん:2007/02/17(土) 00:14:05
>>633
俺もあんたが何がいいたいのかわからん。
とりあえず今なら、AOP使ってもっとリッチなDBC環境を構築出来る気もする。

639 :仕様書無しさん:2007/02/17(土) 00:14:26
>>634
すまん。ちょっとムキになった。

DBで制約かければ解決するってことを言いたい訳じゃない。
DBの有り無しなんて関係ない。

要するに、メソッド呼ぶするときにエンティティのインスタンスの状態さえ
正しければ無事処理できるってことを言いたい。

DBに永続化したエンティティを取得してインスタンス使って処理するわけだから
レコード(クラスのインスタンス)とそのカラム(クラスの属性値)がおかしいと
メソッド呼んだときにバグるってこと。

640 :仕様書無しさん:2007/02/17(土) 00:23:50
>>637
それちゃんと本買って読んだほうがいいね。

641 :仕様書無しさん:2007/02/17(土) 00:32:54
Design by Contractがちっとも流行らないのは、
結局そういう「想定外の状況」から生まれるバグに対して
みんな大して困ってないってことなんじゃないの?

642 :仕様書無しさん:2007/02/17(土) 00:55:40
PoEAAは抽象的だけどよく読んで具体例考えながら読めば
大抵のJavaシステムはトランザクションスクリプトでしか作ってないことが分かる。
ライブラリレベルならドメインモデルが多い。MSならテーブルモジュールだね。

OOP信者ならシステム全体をドメインモデルで作りたいと思うのは当然だけど
作りやすさ、分かりやすさならトランザクションスクリプトの優勢。

だって画面で入力したデータをDTOに詰めてをDAOに渡せばDBに入れてくれるし、
計算はDBのSQLでやって結果だけDTOでもらって画面表示すればいいわけだし。
単純なデータの出し入れが目的なシステムならコレが楽チン。OOPなんていらない。

643 :仕様書無しさん:2007/02/17(土) 01:02:42
>>642

その構造をOOPじゃ無いと言い切るナイーブな意見はわからんな。
OOPのメソッドレベルの構造がトランザクション・スクリプトなだけなような。
そして、システム全体はドメインモデルを作っている構造だと思う。


644 :仕様書無しさん:2007/02/17(土) 01:04:21
>>642
あれ?いったんドメインオブジェクトを習得した開発者なら、よっぽど
簡単なものをつくるとき以外、二度とトランザクションスクリプトに戻りたいとは
思わないでしょう、って書いてあったと思うけど。

645 :仕様書無しさん:2007/02/17(土) 01:05:57
つかファウラーってアンチDTOの第一人者じゃないのか?

646 :仕様書無しさん:2007/02/17(土) 01:08:06
俺、DTOとかDAOってOOPの産物かと思ってた。だってOがついてるじゃん。

647 :仕様書無しさん:2007/02/17(土) 01:14:28
>>644

その本読んだ事無いから、誤解してるかもしれんが、
世の中の、ほとんどの業務が、その「よっぽど簡単な業務」に当てはまる
業務ロジックをオブジェクトの単位にして、それの組み合わせで実現だけだと思う。


648 :仕様書無しさん:2007/02/17(土) 01:21:16
ヒソヒソ( ゚д゚)ヤダァ(゚д゚ )ネェ、キイタ?( ゚д゚)オクサン(゚д゚ )アラヤダワァ
( ゚д゚)ヨノナカノ、ホトンドノギョウムガ、カンタンナギョウムナンデスッテー。(゚д゚ )マァ
( ゚д゚)ナメラレタモノネェー
ヒソヒソ( ゚д゚)ヤダァ

649 :仕様書無しさん:2007/02/17(土) 01:25:57
結局、自分たちが欲しいのは「便利で堅牢で優れたコンポーネント」であって、
自分が「便利で堅牢で優れたコンポーネント」を作りたいとは思わない

だって面倒じゃないか

650 :仕様書無しさん:2007/02/17(土) 01:26:12
まぁまぁ、これ見てもちつけ

つ(軽症 ポリウレタン カプセル蚊)

651 :仕様書無しさん:2007/02/17(土) 01:28:16
>>467
もしそうなら、ほとんどデスマなんて発生しない気がするんだけど。
むしろほとんどのプロジェクトがデスマである現状を鑑みるに、「よっぽど簡単な業務」はあまりないのではないかと。

652 :仕様書無しさん:2007/02/17(土) 01:32:07
>>651

10年近く仕事してるが、デスマなんてあったことがないが・・・
あった事のある範囲でだけど厳しいPJって業務が複雑なんじゃなくて
スケジュールと要員に問題がある例しかないような。

653 :仕様書無しさん:2007/02/17(土) 01:35:45
「便利で堅牢で優れたコンポーネント」は、
「「便利で堅牢で優れたコンポーネント」を作りたいとは思わない」ような
無能な開発者の代替となりうるぞ。

654 :仕様書無しさん:2007/02/17(土) 01:37:24
10年もやってデスマを体験したことがない・・・
果たしてそれは幸せなことなのか不幸なことなのか・・・>>652の仕事がそもそも
IT業界じゃないのか・・・俺にはもはや判断つかんよ・・・

655 :仕様書無しさん:2007/02/17(土) 01:37:53
>>651
多くのデスマーチは設計以前にいろいろ破綻していることが多い
オブジェクト設計では全てのデスマーチを消滅させることはできない

お前はオブジェクト設計を銀の弾丸だと妄想してないだろうな?

656 :仕様書無しさん:2007/02/17(土) 01:47:26
>>652
例えばさ、時間と金が無限にあると仮定したら開発のやり方なんてなんでもいいわけじゃん。
スケジュールと要員に問題があるからこそ、旧来方式よりよいやり方を模索しているわけで。

657 :仕様書無しさん:2007/02/17(土) 01:50:02
>>565
>目的が存在しない行動は本来あり得ないし、
???
まず、コボル上がりは、困る!
基本的にサブルーチンに引数があるという概念すら持ち合わせていないので
オブジェクト指向を語る資格は無い(キーボードに触れてはならぬ!!)
現実世界がオブジェクト指向で全て説明できるという現実世界の経験値が限りなく0に近いゲームオタクも困る!
現在はコンピューターのリソースが贅沢に使える環境なので
昔の構造化プログラミングよりも若干現実世界に近づいた考え方で
プログラムが組める、程度でしかないのだよ。オブジェクト指向は
また、オブジェクト指向は万能でない!と主張している、若干脳みそが至らないイマイチ君は声を小さくして欲しい!
ヴァカはひっこんでろ!
おれは、仕事をさっさと終わらせて、自転車で荒川サイクリングロードを走りたいんだよ
中野のキャバクラでオネーチャン口説きたいんだよ!
おれの作ったシステムを新聞で見たいんだよ!
(今のところ業界紙のみ)

658 :仕様書無しさん:2007/02/17(土) 01:53:19
>>656

それにだって、限度は、ある訳で、Javaだから開発期間は七割とかありえん
スケジュールを持ってくるのは、スケジュールが悪いだろう?


659 :仕様書無しさん:2007/02/17(土) 01:55:39
>>653
お前の目的は便利で堅牢で優れたコンポーネントを作ることなら別に構わん
だが、多くの開発プロジェクトの目的は便利で堅牢で優れたコンポーネントを作ることではない
多くの開発プロジェクトの目的はクライアントの望むものを作ることであり、
多くのクライアントは便利で堅牢で優れたコンポーネントを作ることは多分望んでいない
望んでいるとしても優先順位は低いだろう

昔の汎用機はDBMSにあたる部分やTCP/IPにあたる部分すら自作だったが
今は便利で堅牢で優れたコンポーネントがある
便利で堅牢で優れたコンポーネントはいずれ賢い誰かが作る

もう一度聞くけど、お前の目的はクライアントの目的と一致しているか?
「ライト、ついてますか」 by G.M.ワインバーグ

660 :仕様書無しさん:2007/02/17(土) 01:57:41
スケジュールも悪いし、政治も悪いんだが、一番たちが悪いのは、
俺関係ないも〜んっ、おたくらでやってねって無関心を装って気取っ
てるバカだ。

661 :仕様書無しさん:2007/02/17(土) 01:58:56
>>655
>>651はデスマの原因が業務の複雑性にあるんじゃないかっていってるだけで、
オブジェクト指向でデスマを解消できるとはひとことも言っていないわけだが。
むしろお前が銀の弾丸言いたいだけちゃうんかと。

662 :仕様書無しさん:2007/02/17(土) 01:59:21
目的は検収完了
コンポーネントの使用は目的のための手段。

663 :仕様書無しさん:2007/02/17(土) 02:03:09
>>659
今まで人海戦術でやってたことが出来合いのコンポーネント使うことで
工数かからなくなったら、クレクレいってるだけの雑魚は失業するんじゃないのってことを
いってるんだけど。
クライアントの目的とどう関係あるのかわからん。。

664 :仕様書無しさん:2007/02/17(土) 02:04:31
>>660
> 俺関係ないも〜んっ、おたくらでやってねって無関心を装って
> 気取ってるバカだ。
ああ、オブジェクト設計さえすれば自分以外の誰かが悪いと妄想する奴のことか
こういう奴は自分だけは正しいと勘違いしているから困る

665 :仕様書無しさん:2007/02/17(土) 02:05:48
俺はクライアントが望むものをへへぇっ、作ります、やります、まかせてください。
できます、できます、っいってコストもスキルもノウハウもリソースもスケジュール
も無視して仕事をいけいけどんどん進めちゃうクライアント至上主義の奴がデス
マを引き起こすということを知っている。クライアント至上主義の奴はクライアント
は仮に満足させられてもスタッフを不幸に引きずり込む。 Win-Winの関係は築けない。

666 :仕様書無しさん:2007/02/17(土) 02:09:40
>>658
いやだから誰もスケジュールが無茶なのをオブジェクト指向で全てなんとか出来るなんて言ってなくね?

667 :仕様書無しさん:2007/02/17(土) 02:11:53
>>664
>オブジェクト設計さえすれば自分以外の誰かが悪いと妄想する奴
常識的に考えて、こんな奴が存在すると考えることこそ妄想だろ。。


668 :仕様書無しさん:2007/02/17(土) 02:14:58
>>665
はいはい、君はクライアントよりも賢いね
ならばクライアントなんていらなくね?

自分の望むものを作って、それを欲しいと思う人間が金を出せばいい
うん、それが理想じゃね?
それこそが真のWin-Winの関係じゃね?

669 :仕様書無しさん:2007/02/17(土) 02:17:25
俺が今やってるプロジェクトボロボロなのは下位レイヤー担当がオブジェクト指向を全然理解してないせいだけどな。
インターフェースクラスの存在理由を理解してないアホばっかだから
平気で実装クラスを継承しろとか言ってくるんだぜ。
アホの作ったアホクラスを継承しなきゃいけないってことがこんなにストレスたまるとは知らんかったよ。


670 :仕様書無しさん:2007/02/17(土) 02:17:59
毎日8時間労働で帰れるような開発案件だけが黙ってても都合よく手元に流れて
くると、社会はマシンのように精密に計画された仕事をどっかの誰かが創造して、
くれていて適材適所で割り当てているのだと、本気で考えている想像力のないバ
カ多くて困る。

671 :仕様書無しさん:2007/02/17(土) 02:20:37
すべて人次第

672 :仕様書無しさん:2007/02/17(土) 02:25:16
>>665
あんたの中じゃ勝手に決着しちゃってるのかも知れないけど、

>世の中のほとんどの業務が非常に簡単な業務である
>世のデスマはほとんどスケジュールの問題である
(故に)
>オブジェクト指向は不要

っていう論理に納得する向きは少ないと思うんだけど。


673 :仕様書無しさん:2007/02/17(土) 02:26:36
>>668 いや、俺マジそれが理想だと思うよ。クライアントの行ってることが必ず
しも正しいとは限んないぜ。クライアントのバカ担当にあたったら目もあてられない。

674 :仕様書無しさん:2007/02/17(土) 02:30:08
>>669
それオブジェクト設計とは何にも関係なくね?
馬鹿と付き合うと疲れるのには同意

なんで馬鹿って馬鹿なままでいられるんだろうね?
生きてて恥ずかしくないのかね?

675 :仕様書無しさん:2007/02/17(土) 02:32:53
レベルが上がったり、下がったり激しいのは
書き込む人のレベルがバラバラだからなんだろうなw

まず技術者は良い方法を模索したり
探求する姿勢は必須と思うな。

目的が達成されさえすればれば良いという様な
考え方は経営視点としてはまぁ仕方ない側面もあるが、
技術者としては終わってる考え方だな。

雑魚レベルの人しか
その様な考え方はしないと思うが
危険な考え方だな。



676 :仕様書無しさん:2007/02/17(土) 02:33:46
>>672
オブジェクト指向は不要なんて誰が言った?
レス番付きで頼む
レスが示せなかったらお前の妄想ここに極まれりだな

677 :仕様書無しさん:2007/02/17(土) 02:37:23
>>675
> まず技術者は良い方法を模索したり
> 探求する姿勢は必須と思うな。
そうだね。オブジェクト設計が至高であり最高の設計方法という
思考停止に陥ってはいけないね。
常に良い方法を模索する必要がある

678 :仕様書無しさん:2007/02/17(土) 02:37:34
>>675
経営視点としても決して良いわけじゃないしな。
目的の達成は一種の義務みたいなもので、
人も会社もそれだけでは成長しない。

679 :仕様書無しさん:2007/02/17(土) 02:37:42
>>676
>>642

680 :仕様書無しさん:2007/02/17(土) 02:41:46
ここは自作自演がいっぱいでつね

681 :657:2007/02/17(土) 02:44:29
>>657
いい事を言った!

682 :仕様書無しさん:2007/02/17(土) 02:45:29
>673
お前の様なのが技術者の信用を
落としてるんだろうな…

もうさ、素直に辞めちゃえよ。
本当は仕事嫌いなんだろ?



683 :仕様書無しさん:2007/02/17(土) 02:48:13
>>676
つか、俺が言いたいのはむしろ

>世の中のほとんどの業務が非常に簡単な業務である
>世のデスマはほとんどスケジュールの問題である

こっちの前提条件が正しいかどうかってことだぞ。

684 :仕様書無しさん:2007/02/17(土) 02:49:43
>>682 の台詞が自身に向けた心の叫びに思える。>>682よ、そんなに気を張る必要ないんだぞ。楽になんな。人間自分が大事だぞ。自分が楽しくなきゃ、人を楽しくさせることなんてできないぞ。無理すんな。

685 :仕様書無しさん:2007/02/17(土) 02:50:33
やっぱりアールグレイパターンにおける
ストレートかオレンジペコーパターンのストレートだな

686 :仕様書無しさん:2007/02/17(土) 02:50:43
オブジェクト指向を妄信してる奴は
新興宗教を妄信している奴と同じぐらい使えない

オブジェクト指向が流行したらこの世の地獄だな
ノロウィルスが蔓延したほうがまだまし

687 :仕様書無しさん:2007/02/17(土) 02:52:19
>>668
俺は>>665ではないが、
少なくとも、俺ら(一応プロ)はプロでないクライアントより、
プログラムのことはよく知っている必要があり、クライアントの
言い分に全部従わなければならない存在ではないと思うぞ。

688 :仕様書無しさん:2007/02/17(土) 02:53:19
>>683

正確には

>世の中のほとんどの業務が非常に簡単な業務の組み合わせで表現できる。

だよ。

689 :仕様書無しさん:2007/02/17(土) 02:54:31
>>686
アンチ厨はOO厨以上に痛い。

690 :仕様書無しさん:2007/02/17(土) 02:59:57
>>688
うん。俺はそうは思わないってこと。

691 :657:2007/02/17(土) 03:08:12
>>657
だから、いい事言った!
皆、自分が無意味な存在である事を認めたくないんだね!
更に、害悪がある存在と認めることは絶対に出来ないんだね!

だけど、人間は存在に意味があるから生まれてきたんじゃないんだよ!
生まれてきてから、存在意義を見つけるのが人生なんだ!
ここに存在意義を見つけれなければ、別を探せばいいだけなんだ!
存在意義が見つけれないのに居座るのはよせ! 邪魔だから!
俺らが死ぬ!

692 :仕様書無しさん:2007/02/17(土) 03:10:08
もう寝ろっ

693 :仕様書無しさん:2007/02/17(土) 03:12:07
>684
妄想乙

極端な話、
糞まずい料理店で
ほのぼのと糞まずい料理創るのと
厳しい店で扱かれたり
時には罵声を浴びせられながらも
美味い料理創る事の喜びは意味が違うんだよ。

別に楽しいとかの話ではなくて。

要するに人それぞれなんだよ。ゆとり君w



694 :仕様書無しさん:2007/02/17(土) 03:13:44
プログラムの制御は順構造、分岐構造、繰り返し構造のみで表現可能だが、それしか使わないのは間違っている
オブジェクトで全てを表現可能だが、それしか使わないのは間違っている

デスマーチは設計技術の向上で解決できると思っているなら見当違いだ
そして、オブジェクト指向ができることは設計技術の向上とはなんら関係ない
オナニーをしたいな業務でやるな。自分一人のプロジェクトで思う存分するがいい

695 :仕様書無しさん:2007/02/17(土) 03:23:31
>>694
じゃあさ、設計技術の向上は何の役に立つの?
それと、設計技術の向上のためにはどうすべきなの?

俺はもちろん設計技術の向上は開発の効率化に寄与すると思ってるし、
オブジェクト指向関連の技術の習熟は設計技術の向上に寄与すると思ってるよ。

696 :仕様書無しさん:2007/02/17(土) 03:23:48
別にOOを否定するわけじゃないが、むしろ使ってるけど
最終的にはユーザから評価されないと
どんなにすばらしい設計をしてもダメなんだけどな

697 :仕様書無しさん:2007/02/17(土) 03:25:28
>694
OO信者のつもりはないが
お前痛すぎw

OOはオナニーだ

の様なスレを建てて
一度ぼろ糞に言われて来る事を勧めるw



698 :仕様書無しさん:2007/02/17(土) 03:27:33
主張だけで根拠の説明がない説得力に欠ける文章だね。北○○の主張に似ている。

699 :仕様書無しさん:2007/02/17(土) 03:27:48
>>696
そんなレイヤの違うことをいっしょくたに論じることに何の意味があるの?

700 :仕様書無しさん:2007/02/17(土) 03:34:47
ユーザのありがとうという感謝の言葉に、あぁ辛くてもがんばってやってよかった。と思います。
って、よく会社の採用案内のホームページに「先輩からの一言」とかに書いてあるじゃん。
そうことか? そういうことでエクスタシーを感じるということか? つまりマゾか?

701 :仕様書無しさん:2007/02/17(土) 03:36:21
>>695
> 設計技術の向上は何の役に立つの?
メンテの容易さと、同じスキルを持っている奴との意思疎通がしやすくなる
問題は「同じスキルを持っている奴」以外との意思疎通が難しくなる可能性がある

素人に技術用語を連発しても敬遠されるだけのように
オブジェクト指向を知らない奴にオブジェクト指向でしか通じない用語を話されても敬遠される

全世界がオブジェクト指向を知れば問題ないと言うならば
何故エスペラント語が流行しなかったのかを知る必要があるだろう


702 :仕様書無しさん:2007/02/17(土) 03:36:31
>698
低能にもわかる様に
わかる方法を書いてるだろうがw

お前の大好きな北〇〇とやらより
自分が低能な事にも気付かないんだな。

どうせ低能なんだから
まずやってみろw



703 :仕様書無しさん:2007/02/17(土) 03:38:11
根拠すらなく感情丸出しのレスとかも北朝鮮とか、被差別部落とか知能障害者に似ているね

704 :698:2007/02/17(土) 03:42:22
ごめん俺>>694向けだった。勘違いさせちゃったかな。まいいか。。。

705 :仕様書無しさん:2007/02/17(土) 03:47:42
>>691-692
悪いww吹いたwwwww


706 :仕様書無しさん:2007/02/17(土) 03:48:05
>700
お前、もういいよw
人として馬鹿すぎて話にならない。

お前はサッカー観て
球蹴って走り回って疲れて馬鹿と考えるか?

まず社会経験積むなりして
常識を覚えて来いよ。
話はそれからだw



707 :仕様書無しさん:2007/02/17(土) 03:48:04
>>701
あんた自身は設計技術の向上はすべきと思ってるの?不要と思ってるの?

はっきりいって開発効率の向上は、「即ち」雑魚の切捨てに他ならないんだから
>問題は「同じスキルを持っている奴」以外との意思疎通が難しくなる可能性がある
は別に問題にならないんじゃないかと考えるけど。

逆にいえば、雑魚といくら意思疎通できたからといってたいして足しにならないってこと。

708 :仕様書無しさん:2007/02/17(土) 03:53:19
>698

失礼、勘違いしました。



709 :698:2007/02/17(土) 03:55:53
あ、ついでに俺。>>700でもある。本当に申し訳ない。

710 :仕様書無しさん:2007/02/17(土) 03:56:37
素朴な疑問。

オブジェクト指向プログラミングって便利じゃね?

711 :仕様書無しさん:2007/02/17(土) 04:02:42
>>707
> あんた自身は設計技術の向上はすべきと思ってるの?不要と思ってるの?
設計技術の向上は必要だが、それはオブジェクト設計を学ぶこととは限らないと思っている
オブジェクト設計で満足してしまい、更なる研鑽を行えない人間にはなりたくない

また、開発効率の向上は設計技術の向上だけでは達成できないし、
開発効率の向上だけでは多分行き詰る
個人的には自分のランクと同じ人間としか円滑な意思疎通ができることよりも
雑魚≒クライアントと意思疎通できる方が優先順位が高いと思っている

712 :仕様書無しさん:2007/02/17(土) 05:53:51
>>710
その「オブジェクト指向プログラミング」が、どういう定義なのか
自分なりに説明できるのかい?

君が便利だと思う(オブジェクト指向プログラミングだと思っている)ものは
メッセージングなのかクラス志向なのかインターフェースなのか?
前スレでストラウストラップやクックの論議してた人達がいるけど
万人がOOプログラミングはこれだ!っていう結論は出てないよな?

君が言ってるのは(たぶん)「クラス志向プログラミングって便利じゃね?」
って話で「オブジェクト指向プログラミングは便利」とは違う。
OOPが便利と感じるのは俺も同じだが、そう感じてるSEやPGの中には相当温度差が
あるよな。プログラミングレベルでこうなんだから、設計からコーディングまで
意志統一するなんて難しい話だ。

713 :仕様書無しさん:2007/02/17(土) 06:41:25
このスレ見てると、

数学ができない人間に、
数学の大切さをわからせるのは無理と同じ次元を感じた。

714 :仕様書無しさん:2007/02/17(土) 07:00:24
長文語る人間も横文字の長ったらしい用語をなるべく使わない工夫をしようぜ。
突っ込まれたらどうせ自分だって説明できないだろ?
このスレ、日本の悪しき教育文化をそのままもってきたようなの多いしな。
教科書丸暗記したもののそれがなにかわからないっていうw
穴埋め問題はできるけど、その実内容はまったく理解してない奴みたい。

715 :仕様書無しさん:2007/02/17(土) 07:09:59
横文字苦手って明治生まれの爺かよ。
爺は、N88Basicでも組んでな。

716 :仕様書無しさん:2007/02/17(土) 07:17:21
>>715
その横文字がよ。
他に置き換えようがないぐらいみんなの認識が一致してるもんなら
別にかまやしないんだけどさ。
明らかに、みんながみんなそれぞれ別の書籍の別のもんみて
全然違う意味にとらえてることが多い。
しかも、大抵そういう言葉使ってレスする奴って自分の意見を最後まで確定させないで
いつでも変化つけて誤魔化せるようにしてて卑怯なレスが多い。

717 :仕様書無しさん:2007/02/17(土) 08:56:59
オブジェクト指向が流行らないのは、まだブームの時期だから。
浸透してないってこと。

業界内の意識があってるのは、
言語に依存してるものだけ。
クラス、ポリモーフィズム、継承あたりは「言語規約」があるから統一感があるけど、
型にはまる規約が無いフェーズになると破綻してる。

718 :仕様書無しさん:2007/02/17(土) 11:33:24
>>716

そういうのが、嫌なら、2chのそれもあからさまな、
釣りスレのこんな所に書き込むなよ。
ココは卑劣上等な場所なんだよ


719 :仕様書無しさん:2007/02/17(土) 11:39:26
>>711
あんたのいいたいことがさっぱりわからん。設計技術の向上は必要だが、オブジェクト指向は必要ないってことか?
そしてオブジェクト指向を学ぶと他人とのコミュニケーションがむずかしくなって、他の技術を学ぶとそうはならない
ってことか?

大体、クライアントと意思疎通する技術と開発者同士で意思疎通する技術との間に何か関係があるかな。
俺は無いと思うけど。

720 :仕様書無しさん:2007/02/17(土) 12:13:59
>>719
711じゃないけど、
技術向上=オブジェクト指向「だけ」とは限らないって言ってるだけじゃん。

721 :仕様書無しさん:2007/02/17(土) 12:46:14
豚どもと意思疎通するのは大変だということだよ。
俺は無力感を感じることがしょっちゅうだ。

オープンソースの優れたプロジェクトではそういう豚どものコアへの参加を徹底
的に排除しているな。開発プロジェクトを成功させるためには優れた技術者
だけでスタッフを構成することかベストだという認識はあちらの世界では既に常
識になっている。いくらがんばっても豚に日本語はしゃべらせられないのだ。

722 :仕様書無しさん:2007/02/17(土) 13:01:33
まぁ構造化がきちんとできてOOPが理解できない人には
メソッド内をコーディングしてもらえば良いのだが問題は、
結局、構造化が出来てる人はOOPも出来るから、
そんな人材はいないって事だよな。


723 :仕様書無しさん:2007/02/17(土) 13:40:27
このスレ自体がデスマ

724 :仕様書無しさん:2007/02/17(土) 13:46:57
>>722
構造化が出来てる人はOOPも出来る ってのは飛躍しすぎだと思うぞ。
今時、構造化にならないソース書く方が困難だと思うぞ。その質はともかく。

OOP出来ない奴は、「順次実行」、「繰り返し」、「条件分岐」は書けても、
それ以外の何かが欠けているんだよな。センス的な何かが。物事を抽象化して
整理する能力か。OOPってプログラミングの技術というより、寧ろ問題を整
理する能力だと思う。だからコーディング量は逆に増える場合もあるけど、冗
長性が排除される。ロジックが局所化され、適材適所に配置分散され、また階
層化される。そういった本質とか目的が理解できていない奴が多すぎると思う。

725 :仕様書無しさん:2007/02/17(土) 14:03:08
>>724
質が大問題だと思うが。
構造化をその程度と捉えるってのは、Classって書けばOOPってのと同じ程度のことを言ってる。

つうか、いつもながらすぐOOPになるんだよねこのすれ。
設計なのに。ミクロな話でしか語れない人が引き込む。


726 :仕様書無しさん:2007/02/17(土) 14:05:52
構造化できちんと機能分割するのと、
OOPでクラスを抽出するのは、
目的と方法は、おおよそ同じことやっていると思うぞ。

OOPのが後発の分ちょっとばかり高機能に過ぎないだけだ。

727 :仕様書無しさん:2007/02/17(土) 14:18:07
OOPでの問題はそれだけじゃないと思う。
百科事典的にたくさんあるクラスの海の中で結構な物知り博士になってる
必要があるのでは?あれこれやりたいことがあっても実現までの準備が
相当大変になることもあるとか。


728 :仕様書無しさん:2007/02/17(土) 14:31:03
クラスの海 orz...

729 :仕様書無しさん:2007/02/17(土) 14:43:09
>>720
言ってないじゃん

730 :仕様書無しさん:2007/02/17(土) 15:00:20
構造化設計ではおのおののデータの関連性についてうまく表現するやりかたが
ないことが原因で、システム全体に「本質的に相関関係にあるデータ」が分散管理
されてしまう。

731 :仕様書無しさん:2007/02/17(土) 15:11:38
ANSI Cでも構造化+データとの連携管理はできる。クラスという概念はないが
クラスの代わりに.cファイル単位でならね。それが出来ないと言う>>730はスキルがないだけ。
そんなことも知らずに設計を語れるはずがない。

732 :仕様書無しさん:2007/02/17(土) 15:17:45
>>731
出来る出来ないの話じゃないだろ。頭悪い奴だな。

「アセンブラでもメモリ破壊しないプログラムを書くことはできる。
それができない云々・・・」

733 :仕様書無しさん:2007/02/17(土) 15:23:44
>>731
構造化設計で一定のスキルがあるからこそ、データの相関をうまく取り扱うことが
如何に重要であるか、ひいてはオブジェクト指向をシステム開発に
どのように役立たせることができるかが理解できる、と思う。

734 :仕様書無しさん:2007/02/17(土) 15:31:35
なんかすごいややこしくてわかんなくなってきた。

例えばさ、VB6とかで共通処理をまとめてpublicでモジュールとかにするじゃない。
んでCSVの取り込みデータとか、よく使うデータのかたまりを
sub Mainモジュールの頭にpublicで構造体にするとするじゃない。

これって「構造化プログラミング」、だよね??


735 :仕様書無しさん:2007/02/17(土) 15:39:25
馬鹿共
publicで公開するのは素人だ

736 :仕様書無しさん:2007/02/17(土) 15:40:41
>>733は頭がよさそうだな。次世代のOO設計をリードしてくれ。期待するよ。

737 :仕様書無しさん:2007/02/17(土) 15:42:09
>>732はジャワ糞だな

738 :仕様書無しさん:2007/02/17(土) 15:43:39
protectedな内部クラスの使い方がいまいち理解できない。
誰か教えてエロっぽい人。

739 :仕様書無しさん:2007/02/17(土) 15:45:08
>>737
きょうび、プログラマが任意でメモリ破壊させることができる言語の方が少ないだろ。

740 :仕様書無しさん:2007/02/17(土) 15:47:48
>>738
ストラテジパターンとか。

741 :仕様書無しさん:2007/02/17(土) 15:48:35
>>736
オブジェクト指向の初歩の初歩なわけだが。。

742 :738:2007/02/17(土) 15:51:52
protectedな内部クラスのスコープの意味と使いかたがよく分かんねぇだよ。
メリットデメリット含めて誰か懇切丁寧に具体例を交えて教えてください。
ここにはびこる評論家もどきのエロっぽい人。


743 :738:2007/02/17(土) 15:53:02
あー、言語はJavaでございます。一応。

744 :仕様書無しさん:2007/02/17(土) 15:57:49
>>742
private/publicの内部クラスのスコープの意味と使い方はわかるのか?
protectedスコープのprivate/publicスコープに対するメリット・デメリットはわかるのか?

こいつらがわかれば自ずとわかるだろ。

745 :仕様書無しさん:2007/02/17(土) 16:01:17
>>742
ここに山ほどサンプルあるから、自分で研究しろ。

http://www.google.com/codesearch?hl=ja&lr=&q=lang%3Ajava+%22protected+class%22

746 :738:2007/02/17(土) 16:01:55
>>744
えーと、
おおざっぱにいうと、public にする他のクラス含めてどっからでもアクセスできる。
private だと自分と外部クラスからしかアクセスできないって感じでしょうか?
protected は「外部クラス、サブクラス及び同パッケージの他クラスからのみ使用する
ことができる。」ってかいてあるんですけど、public との違いがよくわからないので
あります。

747 :738:2007/02/17(土) 16:06:46
あー、今理解しました。ありがとうございました。よく見たら書いて
あるそのままですね。失礼しました。

748 :仕様書無しさん:2007/02/17(土) 18:03:47
非オブジェクトはプロシージャとデータをセットで管理できないです
例えば住所管理プログラムを考えると(データベースは使用しないとして)
住所データに対して
登録、削除、変更等の機能が必要だと思います
住所データ、登録プロシージャ、削除プロシージャ、変更プロシージャという風に作っていくと思います
これが、会社の業務システムの一部の社員名簿管理サブシステムとすると
他にも給与データ、勤怠データとか沢山のデータを扱う事になります
データとそれを扱うプロシージャがばらばらなのでメンテナンスが大変になります
似たような機能の関数を知らずに新たに作ってしまったり
給与プロシージャが勝手に名簿データを書き換えてみたり
ちょっと機能を変えたいときにはお得意のコピペでプロシージャを増やしてみたり
秘密のプロシージャがあったりと、まさにカオスです
オブジェクト指向はこういう問題が生じないように工夫されています
構造化プログラミングとは全然違います
大規模システムを作る際には非常に便利です
小さなプログラムでは特に必要ないかも知れません

749 :仕様書無しさん:2007/02/17(土) 18:04:24
構造化設計とOO設計のいいとこ取りをすればいいんじゃね?

750 :仕様書無しさん:2007/02/17(土) 18:07:41
>>748←こいつのいうようなのってそもそもオブジェクト指向ですらないような気がするんだが、
最近のはこういうのが流行ってるの?

751 :仕様書無しさん:2007/02/17(土) 18:13:18
>>750
オブジェクト指向じゃない例じゃないのか?

752 :仕様書無しさん:2007/02/17(土) 18:14:00
>データベースは使用しないとして
前提に無理があるw

753 :仕様書無しさん:2007/02/17(土) 18:16:58
構造化とオブジェクト指向が反するもののようにいうのはどういうことなの?
俺、同時にできると思うぜ。

754 :仕様書無しさん:2007/02/17(土) 18:22:05
>>731 に対する意見じゃね。つまり、 >>748 = >>730 , >>733 あたりだと思う。それなら、この唐突なカキコも話の流れがみえてくるんだが。

755 :仕様書無しさん:2007/02/17(土) 18:26:30
>>730>>733は俺だけど、>>748は違う人だよ。

756 :仕様書無しさん:2007/02/17(土) 18:28:16
あ、すまんかった。

757 :仕様書無しさん:2007/02/17(土) 18:40:23
>>748
データベースを使う場合は構造化プログラミングで我慢しろとでも?そんなの嫌です。

758 :仕様書無しさん:2007/02/17(土) 18:47:21
学習量の差がこのスレ住人の差だなあ。
スレタイは「設計」とある。
プログラミングじゃねーつの。

759 :仕様書無しさん:2007/02/17(土) 18:48:56
>>748
>例えば住所管理プログラムを考えると(データベースは使用しないとして)
オブジェクト設計ネタだとデータベースの話は避けるもんなの?
世の中のオブジェクト設計案件ってそういうのが大半なの?

「人間が一人だけだったら戦争は無くなる」ってのと同類のアホらしさを感じるのだけど。


760 :仕様書無しさん:2007/02/17(土) 18:51:42
>>759
メモリ上でやればいいじゃん。
実用的かどうかは別として。
>>748がいらんことを言ってるのは確かだけどな。

761 :仕様書無しさん:2007/02/17(土) 18:51:50
>>758
オブジェクト指向 設計 実装 シームレス
あたりでググれ。話はそれからだ。

762 :仕様書無しさん:2007/02/17(土) 18:54:25
>>761
スレタイを読め。
話はそれからだ。

763 :仕様書無しさん:2007/02/17(土) 18:56:02
>>759
>オブジェクト設計ネタだとデータベースの話は避けるもんなの?

そんなわけないじゃん。

764 :仕様書無しさん:2007/02/17(土) 18:57:06
>>758
設計とプログラミングを全く関連性のないものとして切り離してしまう
お前のその柔軟性のなさにお前の学習量の程度がしれる。コーダーか?

765 :仕様書無しさん:2007/02/17(土) 18:57:26
>>762
どのあたりのレスがプログラミングに特化した話なのかおしえてくれや。

766 :仕様書無しさん:2007/02/17(土) 18:59:58
>>764
どこにそんなこと書いてあるんだ?
ホントに文章読まない奴だな。

767 :仕様書無しさん:2007/02/17(土) 19:02:52
>>766
設計とプログラミングの関連性を理解するのであれば、
別にここでプログラミングの話題に話が及んでも構わな
いと思うんだが。それともお前が設計に特化したネタで
もふるか?

768 :仕様書無しさん:2007/02/17(土) 19:03:20
俺は>>764じゃないけど、

>>766
俺もお前が何をいいたいのか全然わからん

769 :仕様書無しさん:2007/02/17(土) 19:05:36
>>767
先生教えてください。
オブジェクト設計はなぜ流行らないのですか?

770 :仕様書無しさん:2007/02/17(土) 19:10:23
まぁまぁ、お前らこれでも見てもちつけ。
つ(景勝、ポルノグラフィ、カプセルホテル)

771 :仕様書無しさん:2007/02/17(土) 19:12:30
UMLが流行らないって話?

772 :仕様書無しさん:2007/02/17(土) 19:13:00
>>769
それはね、坊や、OOPを理解できない人が多いからだよ。

773 :仕様書無しさん:2007/02/17(土) 19:15:22
>>772
うん、僕わかったよ。
じゃあここの住人の話が脱線してるのはどうしてなの?

774 :仕様書無しさん:2007/02/17(土) 19:18:39
流行ってないって前提がおかしい
すでにほとんどの企業はオブジェクト指向設計を取り入れている。

775 :仕様書無しさん:2007/02/17(土) 19:20:44
>>773
ん〜、どうだろ。脱線してるかなぁ。君がそう思うんなら、
君が脱線してないと思うネタをふってごらん、そしたら君
が望むような展開になると思うよ。がんばれっ。

776 :仕様書無しさん:2007/02/17(土) 19:23:28
プログラミング出来ない人が設計出来ないように
OOP出来ない人も、オブジェクト指向設計が出来ないと

777 :仕様書無しさん:2007/02/17(土) 19:23:51
>>774
そのとおり。オブジェクト指向が流行ってないなんていまだに言ってるのは
環境に恵まれない哀れなプログラマ達の怨嗟の声としか思えない。

778 :仕様書無しさん:2007/02/17(土) 19:26:38
>>775
うん!僕わかったよ!
おじさんありがと!

779 :仕様書無しさん:2007/02/17(土) 19:27:43
>>776
出来ない。OOP言語をひとつも使いこなしてないなら、
上の方で出てきていたPoEAAの内容なんてひとつも理解できないと思う。

780 :仕様書無しさん:2007/02/17(土) 19:28:37
じゃないよ、能無しをコントールする仕組みでデザインされたOO(P)(D)
はほっとくとろくなもんしかアウトプットできない>>777をドカタとして囲い込むための仕組みだからさ。

781 :仕様書無しさん:2007/02/17(土) 19:33:31
とりあえず派遣で渡り歩いてる俺の見た環境の多くは
無い環境は全く無い。
有る環境(と思われる)は活きてない。
のがほとんどだったな。

まあ、プロジェクトの成功失敗を決めてるのはオブジェクト指向云々じゃないな。
昔ながらの組み方全開の人もオブジェクト指向がどうのこうのいいながら組んでる人も
共存してても別に問題あるわけじゃないし。

782 :仕様書無しさん:2007/02/17(土) 19:45:12
オブジェクト指向という「考え方」の存在は浸透してるが、
どの現場でも完全には使いこなせていないということだな。

783 :仕様書無しさん:2007/02/17(土) 19:48:34
>>781は実際そうなんだと思うけど、どうなんだろ。

ゴミを予算内・スケジュール内で組んだとしてそれでプロジェクト成功だなんて
いうのであれば別だけど、オブジェクト指向含むいろんな新しい方法論を
学習したり実践したりするタイプの人間以外がゴミ以外生産できると思えないし、
またいろんな開発方法を会得した人間があえて旧来方式での開発を選択するとも思えない。

784 :仕様書無しさん:2007/02/17(土) 20:08:26
まず、従来のやり方と共存できるってことをアピールすることから始めてみてはどうだろうか?

785 :仕様書無しさん:2007/02/17(土) 20:15:42
>>784
残念ながら、共存は難しい

786 :仕様書無しさん:2007/02/17(土) 20:20:00
>>785
むしろオブジェクト指向の一番の利点だと思うんだけどな。
クラス内で完結してるもんが多いんだし、使用例サンプル通りにクラス・メソッド呼んでくれるだけで動くもんがほとんどじゃん。

フレームワークを構成するような作りになってたらなんのためのオブジェクト指向なんだよwって思わないでもないがw

787 :仕様書無しさん:2007/02/17(土) 20:20:58
オブジェクト指向には、インターフェイスで受け渡される値さえ正しければ
中身は、どうでも良いと言う思想があるから、共存は出来ると思うよ。


788 :仕様書無しさん:2007/02/17(土) 20:43:50
そろそろだらだら書き込みするだけじゃなくて
このスレで得られた成果を発表したらどうだね。

789 :仕様書無しさん:2007/02/17(土) 21:19:46
>>788
「まずは従来の方法との共存を」

790 :仕様書無しさん:2007/02/17(土) 21:52:13
勉強したり実践したりしたこともないものに対してアンチになる奴って一体なんなの?

791 :仕様書無しさん:2007/02/17(土) 22:06:08
>>790
レイプされたこともないのにレイプ犯非難するなとかそういうアフォな議論したいのか?

792 :仕様書無しさん:2007/02/17(土) 22:10:30
>>791
全然構造が違うだろ、アホか。

793 :仕様書無しさん:2007/02/17(土) 22:13:07
かれらは、老人なので新しい物は、
役に立つ立たないにかかわらず、
すべて嫌いなのです。

794 :仕様書無しさん:2007/02/17(土) 22:37:04
>>792
それを確かめるためにちょっといってくる。

795 :仕様書無しさん:2007/02/17(土) 23:26:23
>793
違うな。
老人は過去に効果的と思われた方法を使って
一定の成果を上げたんだろう。

その経験から自分の方法に盲信してるんだと思う。

もちろん、優秀な技術者はそうはならないがな。

問題は老人を盲信から覚めさせる事は
ほとんど不可能な程に難しいって事だな…



796 :仕様書無しさん:2007/02/18(日) 00:35:53
ラクをするための考え方のはずが、
その存在のために苦しむ人間が多いオブジェクト指向。
偽装請負による現場のカオス化が無くならない限り、
一般的な開発案件は振り回され続けるんだろうな。

797 :仕様書無しさん:2007/02/18(日) 00:58:43
ざっと見たけどお前ら本当にオブジェクト指向をなーんもわかってないのな。
抽象データ型とか全然しらねーだろ?


798 :仕様書無しさん:2007/02/18(日) 01:02:42
   ∩___∩         |
   | ノ\     ヽ        |
  /  ●゛  ● |        |
  | ∪  ( _●_) ミ       j
 彡、   |∪|   |        J
/     ∩ノ ⊃  ヽ
(  \ / _ノ |  |
.\ “  /__|  |
  \ /___ /

799 :仕様書無しさん:2007/02/18(日) 01:06:59
>>797
説明して。

800 :仕様書無しさん:2007/02/18(日) 01:11:58
またオブジェクト指向対抽象データ型かよ。
なんつか、実学ベースの話したいんだけど。

801 :仕様書無しさん:2007/02/18(日) 01:12:49
>>800
していいよ。してっ。

802 :仕様書無しさん:2007/02/18(日) 01:36:21
>>800
どういう話になんの?

803 :仕様書無しさん:2007/02/18(日) 01:41:06
+   +
  ∧_∧ ∩ +
 (0゚´∀`)彡  <<800 wktk!wktk!
 (0゚∪⊂彡 +
 と__)__) +

804 :仕様書無しさん:2007/02/18(日) 01:51:56
      ☆ チン     マチクタビレタ〜
                        マチクタビレタ〜
       ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        ヽ ___\(\・∀・) < 実学ベースの話しまだ〜?
            \_/⊂ ⊂_ )   \_____________
          / ̄ ̄ ̄ ̄ ̄ ̄ /|
       | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
       |  愛媛みかん  |/

805 :仕様書無しさん:2007/02/18(日) 02:13:40
   ∧ ∧    ┌────────
  ( ´ー`)   < シラネーヨ
   \ <     └───/|────
    \.\______//
      \       /
       ∪∪ ̄∪∪


806 :仕様書無しさん:2007/02/18(日) 02:54:23
ただいま>>797がGoogle検索中です。
しばらくお待ちください。

807 :仕様書無しさん:2007/02/18(日) 04:23:22
オブジェクト設計ってオブジェクト指向を使った設計のことですか?
UMLとかデザパタとかの話でしょうか?
設計ってどのレベルまで細かく明記するんですか?
各クラスのメソッドとかプロパティは全て網羅するんでしょうか?
設計時点で定義されるから、プログラマはプライベートな変数とかメソッドとか
も別に考える必要はないんですか?実装のためのローカル変数ぐらいですか?
一般的にどうなんでしょう?設計者と実装者の役割のボーダーはどのレベル
でひかれるんでしょうか?UMLで図を描くのが設計者で、そのテンプレートを
もとに実装するのがプログラマなんでしょうか? だとしたらプログラマはとりあえ
ず構造化プログラミングができればなんとかなるんでしょうか?
実際の現場ではどうなんでしょうか? 
よろしければ教えてください。

808 :仕様書無しさん:2007/02/18(日) 04:31:50


809 :仕様書無しさん:2007/02/18(日) 05:50:07
嫌++

810 :仕様書無しさん:2007/02/18(日) 06:01:48
>>807
よくよんだら結構実のある質問だけど羅列したところがアホだな。

811 :仕様書無しさん:2007/02/18(日) 06:19:18
嫌#

812 :748:2007/02/18(日) 08:18:40
>>データベースは使用しないとして
説明がめんどくさくなるから
設計とコーディングを切り離す云々て話だけど
最近の言語はコーディングも昔ほど手間がかからなくなてきたせいか
設計からコーディングまで同じ人がやるよ
これがオブジェクト指向の恩恵だと思う
オブジェクト指向が流行らないのは
上層部が、オブジェクト思考から最も遠いコボル経験ばかりだったりするのも
一員だと思う
コボルは構造化すら出来ていないですから
エラー処理でGOTO文書くと怒るし


813 :仕様書無しさん:2007/02/18(日) 09:28:40
>>807
「分析モデル 設計モデル 実装モデル」でググれ。

あと、上流・下流は分業しない。同じ人間がやる。

814 :仕様書無しさん:2007/02/18(日) 09:35:55
>>813
そうあるべきだが、そうなってないよな。
俺は>>807ではないが、ググってヒットすることを聞きたいんじゃないと思うぞ。

815 :仕様書無しさん:2007/02/18(日) 09:38:26
「上流・下流は分業しない。同じ人間がやる」は、間違い
普通は分業する。たまに要員確保の問題で同じ人がやる事もあるけど。


816 :800:2007/02/18(日) 09:40:47
実学ベースの話っていう言い方が悪かったかも知らんが
オブジェクト指向の起源とかそういう話じゃなくて、
しょうもないことでもいいから仕事に役立つ話聞きたい。

817 :仕様書無しさん:2007/02/18(日) 09:43:02
>>814
>そうあるべきだが、そうなってないよな。
なってないね。
だが、まず>>807はググるべきと感じた。

818 :仕様書無しさん:2007/02/18(日) 09:47:32
>>815
スパイラル開発じゃないとオブジェクト指向開発のメリットがない。
んで、スパイラル開発だと分業できん。やってられん。

819 :仕様書無しさん:2007/02/18(日) 09:51:33
>>818
別にウォータフォールでもオブジェクト指向はメリットがあると思うが
アジャイルならともかく、スパイラルなら分業できるしっていうか
普通分業するし。

820 :仕様書無しさん:2007/02/18(日) 09:56:54
>>819
無理っしょ。
分業なんかしたら、スパイラルはできないよ。
期間的な問題で無理。
設計から開発にまわして、もう一度設計に渡して開発に・・・ってこれが
別のチームじゃ情報の伝達だけで開発終わっちゃうよ。
仕組み的にできるできないの話じゃなくて時間的に絶対に無理。

821 :仕様書無しさん:2007/02/18(日) 10:04:07
>>820

だから実際に普通にやってるって、
伝達時間より分業の方が効果あるから
っていうか、最近のPGは客先で説明・交渉は出来んし
SEは、プログラムが組めんからやらざるえない。



822 :仕様書無しさん:2007/02/18(日) 10:04:24
>>819
完全にアーキテクチャフリーなモデルをつくれればいいんだけど、
現実は「XXという実装が可能であれば」「XXという設計モデルにしたい」ってなる。
要は、部分部分で実装・検証繰り返しながらじゃないとまともな設計にならん。

823 :748:2007/02/18(日) 10:04:39
>>820
同感
俺は単体試験、結合試験まで一人でやった事あるけど(メーカー的にはNGらしい)
小さなシステムですけど、バグは殆ど出なかったよ

824 :仕様書無しさん:2007/02/18(日) 10:06:18
>SEは、プログラムが組めんからやらざるえない。
この時点でオブジェクト開発導入無理な希ガス

825 :仕様書無しさん:2007/02/18(日) 10:12:44
>>824

最近のSEがプログラム組めん実際事実でしょ
後、構造化設計の方がSEのプログラム技術は必要だよ。
オブジェクト指向は、抽象化されてるから、
ある程度、実装を知らなくても設計ができる。

826 :仕様書無しさん:2007/02/18(日) 10:21:54
>>825
>最近のSEがプログラム組めん実際事実でしょ
事実かも知らんが、正しい有り様とは思えん。

>オブジェクト指向は、抽象化されてるから、
>ある程度、実装を知らなくても設計ができる。
これもおかしい。いろんな実装を知ってるからこそ、
あるひとつの具体的な実装形態にバインドされない
モデルを作成することができると思う。

827 :仕様書無しさん:2007/02/18(日) 10:28:30
>>826

正しいか正しくないかなんていってないよ。
事実を述べたまで、正しいかどうかなら
正しくないだろうね。
でも世の中は正しくない事の方が多いんだよ。

オブジェクト指向設計の上流工程で
言語実装が出てくるのはおかしいと理解できてれば文句は無いよ。
理想を言えばそのとおりだと思う。

828 :仕様書無しさん:2007/02/18(日) 10:35:50
>>821
>伝達時間より分業の方が効果あるから
そんなわけねーじゃん。
嘘っ八をいうな。
こればっかりは絶対にないね。

829 :仕様書無しさん:2007/02/18(日) 10:36:21
>>827
スパイラルの話に戻ると、スパイラルは分業できないのは「事実」だと思うんだが。

>言語実装が出てくるのはおかしい
言語実装が出てくるのは「いただけない」けど、設計者が実装方法を一つも答えられないのは「論外」

830 :仕様書無しさん:2007/02/18(日) 10:43:34
>>829

事実分業してるんだからしょうがないと言ってる。

あと、スパイラルは、分業できないと言うソースがあったらあげてくれよ。

831 :仕様書無しさん:2007/02/18(日) 10:45:45
>>830
SEはコード書けなくてもいいってソースが無いのと同様、
スパイラルの分業は理想かもしらんが、事実上無理。

832 :仕様書無しさん:2007/02/18(日) 10:49:15
>>830
設計者は実装者に何を引き渡す?
実装者は設計者にどうやってフィードバックする?

833 :748:2007/02/18(日) 10:49:26
昔はプログラミングも
コーダー、パンチャーという風に細かく分かれてたよ
仕様書だって、書く人とワープロに入力する人と分かれていたんじゃないかな
そういう時代なら分業も随分意味があると思う
いまは面倒な事は全部コンピュータがやってくれるので
あえて分業する必要性がなくなってきていると思う
今行われているのは分業というより分担が主流だと思う
ただ、作る人と営業する人、要求仕様を決める人は普通別だと思う
こういう作り方をしているプロジェクトと
大人数で伝言ゲームごっこがメインのプロジェクトでは
後者のほうが非常にコストがかかるはずなのに
同じ予算でやろうとするから、あちこちに無理が生じて
デスマになってしまうのだと思う


834 :仕様書無しさん:2007/02/18(日) 10:55:44
>>832
それだよな。
人に成果物を渡すってのが双方にとってどんだけ手間かってのがわかってないよな。
渡すほうも確認するのはもちろんだけど、受け取ったほうもそれを全部確認せにゃならん。
もう、感覚で絶対に不可能ってわかる。

835 :仕様書無しさん:2007/02/18(日) 11:00:10
>>832

普通に設計書だな、
主に外部設計書に対して実装、設計者、客がそれぞれに修正案をだす。
って感じだな。当然、その時点のシステムを実際触っての、修正変更も
それぞれのレベルの設計書に盛り込まれる。

836 :仕様書無しさん:2007/02/18(日) 11:03:18
>>834

ウォータフォールでは、全部確認せんのか?するだろう?
スパイラルはウォータフォールの全工程を繰り返して
完成に至るものだから、ウォーターフォールで出来れば
スパイラルでも出来る。

837 :仕様書無しさん:2007/02/18(日) 11:08:02
>>835
まさか、詳細設計とかプログラム設計とか別にドキュメントあるんじゃないだろうな。。

838 :仕様書無しさん:2007/02/18(日) 11:10:24
>>836
金も納期も無限にある前提なら
>ウォーターフォールで出来ればスパイラルでも出来る。
は正しいな。

だが、
「ウォーターフォールより金も納期も品質も良くならない」なら
スパイラルを選択する意味はない。

839 :仕様書無しさん:2007/02/18(日) 11:15:03
>>837

プログラムと詳細は、ないけど、
要求仕様、基本仕様、外部設計、詳細設計は、別にドキュメントがあるよ。
各仕様書もさらに分かれているし。
例えば、外部なら、画面仕様、画面遷移図等

840 :仕様書無しさん:2007/02/18(日) 11:17:51
>>838

ウォーターフォールでは手戻りNGなんだから
スパイラル以上の納期、金、品質になる事は
普通無いと思うけど。


841 :仕様書無しさん:2007/02/18(日) 11:38:40
>>840
なんつか、あんたはウォータフォールモデルでエンハンス繰り返してるのを
スパイラルと呼んでるだけの気がするんだけど。。

842 :仕様書無しさん:2007/02/18(日) 11:51:59
>>841

俺の言ってるスパイラルとは、これのスパイラルモデルだけど
ttp://www.ics.kagoshima-u.ac.jp/edu/SoftwareEngineering/process-model.html

843 :仕様書無しさん:2007/02/18(日) 11:52:14
>>840
なんでだよ。
単純に考えても
(分析→設計→実装→リリース)が1回のウォータフォールに対して、
(分析→設計→実装→リリース)がn回のスパイラルの方が
イテレーションの数だけ「→」が多いんだから稼動面で不利だろ。

844 :仕様書無しさん:2007/02/18(日) 11:57:55
>>843

複雑な物を一回で作るより、単純な物に仕様を追加して行くほうが
明らかに簡単だし、早いだろう。

845 :仕様書無しさん:2007/02/18(日) 12:06:37
アジャイルだったら分析設計実装は毎日やるから、分業なんて無理だな。
そもそもいくつかあるソフトウェア開発プロセスで推奨してる分業は
機能単位であって業務単位じゃねーしな。
ウォーターフォールしか知らない&他を知ろうともしない奴は分業って固定観念に取り付かれててすげー迷惑だが。

846 :仕様書無しさん:2007/02/18(日) 12:07:31
例えると
ウォータープルーフモデルの適用が最適なのは
プラモデル作成くらいかな?
0からものを作る場合
ウォータープルーフモデルではかなり無理がある
ところで、オブジェクト指向は頭が良くないと出来ないという誤った認識があると思う
要は上層部がオブジェクト指向に対応できなくて
自分達の立場を守るために
オブジェクト指向の否定を展開しているに過ぎないと思う
若い連中はそれに踊らされているだけだと思う

847 :仕様書無しさん:2007/02/18(日) 12:10:40
>>844
http://www.metabolics.co.jp/XP/dX.html
http://www.objectclub.jp/download/files/technicaldoc/rup_xp.pdf
に目をとおして、分業可能性についてもういちど考えてみてくれ。

848 :仕様書無しさん:2007/02/18(日) 12:27:00
>>847

それ、スパイラル開発じゃないから
見てもしょうがないよ

849 :仕様書無しさん:2007/02/18(日) 12:29:35
>>848
is-a スパイラルだろ。

850 :仕様書無しさん:2007/02/18(日) 12:33:29
>>849

何処にスパイラルと書いてあるんだ?
スパイラルと言えば1988年にバリー・ボームが提唱ものだぞ

851 :仕様書無しさん:2007/02/18(日) 12:35:35
>>848
お前はRUPとかAgileとかは知らんが、純然たるスパイラル開発(そんなものがあるかは知らんが)
では分業は可能だと主張したいのか?
この議論は「オブジェクト指向開発では」っていう前提があるはずだよな?

852 :仕様書無しさん:2007/02/18(日) 12:37:37
>>851

そのとおり

>>この議論は「オブジェクト指向開発では」っていう前提があるはずだよな?

それについては知らなかったすまんな。

853 :仕様書無しさん:2007/02/18(日) 12:44:41
俺が経験してきてるここ最近の開発って、SEと称する連中が
客から要望聞いて、おおざっぱな画面設計とDB設計(なんと
要件が固まりきらないうちにDB設計されてしまう)と、要件が
箇条書きになっているようなもんを基本設計書ですって渡して
きて、これで詳細設計におとしてくださいという。そしてその後、
頻繁に画面ちょっと変わりましたぁ。対応してください〜い。とか
言ってくる。こんなんでまともなクラス設計なんてできるわけがない。
そしていざ実装という時点でも、要件が変わるもんだから、画面と
DB設計書を修正したものを渡してきやがる。本人達はこれが
スパイラル開発だぁ。と思っているらしい。全くこっちにとっちゃ
悪夢のスパイラルだよ。

854 :仕様書無しさん:2007/02/18(日) 12:45:56
ところでOODの定義って何?
なにをやってればOODって事になるの?

855 :仕様書無しさん:2007/02/18(日) 12:50:11
>>853

あるね。本来スパイラルでは、
要求分析フェイズ以外に仕様変更・追加は無いはずなのにね。


856 :仕様書無しさん:2007/02/18(日) 12:52:50
>>854
UMLにのっとっていればよいのでは
とりあえずシナリオ書いて
シナリオから書けば
>>853のような事態にはならないと思う
シナリオも無しに画面とDB設計は無謀だと思う
お客さんは実は自分が欲しいシステムを本当は知らないというのは
結構重要なポイントだと思う

857 :仕様書無しさん:2007/02/18(日) 12:55:03
業務システムのユースケースでさ「利用者情報を登録する」ってユースケースあるじゃん?

これを構造化で実現しようとすると、登録プロシージャに利用者情報を渡すってイメージになるでしょ?
で、利用者情報を渡された登録プロシージャにはDBにインサートする処理を書くわけ。
DB中心に考える人はこれがとても分かりやすい。

でも、これをオブジェクト指向で設計すると、イメージとしては「利用者」というインスタンスをnewするだけでもう処理は終わりなんだよ。
だって、メモリ上に利用者情報のインスタンスが出来た時点でシステムには登録されている状態になるでしょ?
あとはこのインスタンスをDBでもXMLにでも永続化しておいて、後からこのインスタンスを利用できるようになっていればいいだけなのさ。

OOPだとメモリ上で全部やろう!っていうのが基本的な考え方だよ。
でも超大量インスタンスを抱え込めるメモリなんてないから、適材適所でシステム作りましょうってこと。

1件ずつの処理ならメモリ上で処理しても問題ないけど100万インスタンスをメモリ上に展開して処理するのは
性能、リソースの観点から好ましくないから、SQLで一括で処理しちゃえば?って考えだと思う。

858 :仕様書無しさん:2007/02/18(日) 12:55:59
>>856

そういう意味ならば、UMLにのっとって仕様書を書けば
ウォーターフォールだろうと狭い意味でのスパイラルだろうと
OODで良いのか?


859 :仕様書無しさん:2007/02/18(日) 13:03:56
開発プロセスとOODは直接関係ない。
だけどオブジェクト指向開発のメリットを引き出しやすい開発プロセスはあると思う。

860 :仕様書無しさん:2007/02/18(日) 13:10:09
>>859

同意だが、
旧来の開発プロセスでもOODが完全に無意味って事も無いと思う。

861 :仕様書無しさん:2007/02/18(日) 13:16:46
>>853 に書かれているようなバカ連中には、ある特徴的な類似点がある。
まず、仕様書(本人達はそう言ってる)が例外なくExcelである。そして、
DBはテーブルの主キーにことごく自然キー(特に複合キー)を使う。DB
への制約はまずかけない。なかにはNOT NULL制約すら書いてない場合もある。
とにかく、複合キーはいただけない。実装レベルへの負荷にかなり影響する。
オブジェクト指向による実装を知らないからこんな上流、下流のミスマッチ
がおこる。SEの仕事はこういうことだという認識がそのまま下流に浸透して
しまうのも問題だ。それこそ悪夢のスパイラルが永遠に伝承されていくことに
なる。スパイラルはほんと、日本では誤った認識されていると思うよ。

862 :仕様書無しさん:2007/02/18(日) 13:21:05
>>857
飛躍しすぎだと思う
「利用者」のデータセットインスタンスを指していると思うけど
登録が必要なら削除や追加も必要だったり
削除したものは復活できるのかとか
登録時のIDみたいなものは削除後は欠番にするのかとか
ユーザーインターフェースはオフコン上がりのオペレーターが多いから
オフコンライクにするとか
派遣社員でまかなうからオフィスライクな感じにするとか
ここら辺は設計よりも前の要求定義だと思うけど

863 :仕様書無しさん:2007/02/18(日) 13:25:39
>>862
>>857じゃないけど、>>857のどこに対するつっこみなのかわからん。

864 :仕様書無しさん:2007/02/18(日) 13:26:17
>>862
うん、当然それはそうだけど、内部の処理に関しては一緒でしょ?
登録はインスタンスの生成
追加もインスタンスの生成
削除はインスタンスの永続性の解除

論理削除かどうかってのはクラスが論理削除属性持つかどうかのクラス設計でしょ。

UI設計はインスタンスをどう見せるかってだけでまた別の要求定義だと思う。



865 :仕様書無しさん:2007/02/18(日) 13:26:46
うわぁ
業務アプリの世界

866 :仕様書無しさん:2007/02/18(日) 13:30:06
●●オブジェクト設計は何故流行らないの?●●02
 ↓
●●新しいパラダイムの業務アプリ設計は何故流行らないの?●●02

オブジェクト設計==新しいパラダイムの業務アプリ設計
だったんだなあ。うーん。よく分かった。

867 :仕様書無しさん:2007/02/18(日) 13:31:38
↑なんでこの人はここ数時間の流れだけでそう断定してしまうのだろう。
頭の弱い人なのかな。

868 :仕様書無しさん:2007/02/18(日) 13:34:25
>>866

業務アプリに限って説明してるけど、OOPの考え方の基本は一緒ですよ。
ほとんどの業務アプリはエンティティのCRUDユースケースだし。

ライブラリとかちょっとしたユーティリティ作るときにも
OOPの考え方だと修正が楽できるよ。
このデータに関しては修正ありそうだから別クラスに切り出しておくかとか
処理方法は統一したいからIFで切ってコマンドパターン使おうとかさ。

869 :仕様書無しさん:2007/02/18(日) 13:34:59
>OOPだとメモリ上で全部やろう!っていうのが基本的な考え方だよ
そおなんっスか。うーん。カーネルはちびちびとバッファを節約して
頑張っているのに業務の人は自分の事しか考えなくて良いからお気楽ですね。

870 :仕様書無しさん:2007/02/18(日) 13:38:25
>ライブラリとかちょっとしたユーティリティ作るときにも
デバイスドライバより下層には当てはまらないから万能ではないと思うけどね。
ここで言うライブラリとかちょっとしたユーティリティって
消費税を計算するスタティックメソッドみたいなレベルでしょ。
大きなくくりで「業務アプリ」に含まれると思うけど。

>業務アプリに限って説明してるけど
をきちんと説明してないし、応用範囲が明確に示されていないよ。
大丈夫?それで設計できるの?

871 :仕様書無しさん:2007/02/18(日) 13:39:52
↑あ、この人寂しがりやさんだ。

872 :仕様書無しさん:2007/02/18(日) 13:41:35
>>869
>カーネルはちびちびとバッファを節約して
>頑張っているのに業務の人は自分の事しか考えなくて良いからお気楽ですね。
あたりまえだろバカ。

873 :仕様書無しさん:2007/02/18(日) 13:41:40
>>869

そうだよ、だから楽できるんだよ。
そもそもJVM起動するときにあらかじめヒープ領域確保されちゃってるでしょう。
その中でどうメモリ使おうかは設計の自由じゃまいか。

さすがに超大量のデータ処理をOOPでやろう!ってのはOutOfMemoryエラーとかで
VM落ちちゃう可能性あって無理だけど、1インスタンス数十kb程度なら問題ないっしょ。
てかもう領域確保されちゃってるし使わなきゃ損。

マシンスペックも日々向上してるしねw



874 :仕様書無しさん:2007/02/18(日) 13:44:10
消費税を計算するスタティックメソッドって何だろう・・・
消費税計算したきゃ価格属性持ってるインスタンスに計算メソッド追加するだけじゃん?
ライブラリでもなんでもないし・・・

875 :仕様書無しさん:2007/02/18(日) 13:45:38
商品毎に税率違うのか

876 :仕様書無しさん:2007/02/18(日) 13:46:23
java設定させるんじゃなくて必要なら必要なだけとって勝手に動けよな

877 :仕様書無しさん:2007/02/18(日) 13:47:06
設計という事は、物理メモリに対してjavaのクラスインスタンスの
瞬間最大総量を計算して余裕があるのを前提に>>873が話しているのならば
いいでしょう。でも君のレスみると、ざっくりとだいじょうぶしょのノリで
万事テキトーな雰囲気が漂うんだけど。javaのSEさんってみんなこんのばっかりなの?

878 :仕様書無しさん:2007/02/18(日) 13:48:10
一律でも商品毎でもどっちでも同じでしょ?
「商品「クラスに税率計算メソッド持ってれば、それを継承した「本」とか「家電」とかも
まとめて計算できるし、本だけ税率変えたければ本の計算メソッドオーバーライドすればいいだけだし・・・

879 :仕様書無しさん:2007/02/18(日) 13:49:15
いや「物理メモリ」じゃないから

880 :仕様書無しさん:2007/02/18(日) 13:50:06
>>877

そりゃ最大瞬間風速は予測するさ。
GCされることが分かってたとしても、同一スレッド内に生成される
インスタンス数くらいは考慮して設計するよ。

881 :仕様書無しさん:2007/02/18(日) 13:52:38
ただ、どうみてもこの処理リソース消費ヤバイだろ・・・的なこと以外は
最初からリソース懸念して設計してないな。
テストしてみて懸念される箇所だけ処理方法かえるってのがセオリーかな。

自分の中ではリソース、性能よりも拡張性、修正のし易さにプライオリティ置いてるからかなぁ

882 :仕様書無しさん:2007/02/18(日) 13:54:12
>>878
>一律でも商品毎でもどっちでも同じでしょ?
同じじゃねーよ。おまえ税率変わるたびにコード書き直すつもりかよ。

883 :仕様書無しさん:2007/02/18(日) 13:56:07
>>882

じゃあ税率はプロパティファイルに設定値出ししとけばいいだけじゃない(・∀・)

884 :仕様書無しさん:2007/02/18(日) 13:58:25
>>879
>いや「物理メモリ」じゃないから
物理メモリだってば。ハードウェアのメモリをOS管轄の
memoryマッパで初期化してるんだよ。VMのソース覗いたことないの?
「JavaのTCP/IPにはソケットを使わない」の名言を思い出してしまった。スマソ

885 :仕様書無しさん:2007/02/18(日) 13:59:03
>>877
Javaよりprofile関係充実してるのなくね?
スクリプト系とかどうするのよ。

886 :仕様書無しさん:2007/02/18(日) 14:07:23
>>885
スマヌこちら低脳のため意味がわからん。

887 :仕様書無しさん:2007/02/18(日) 14:13:21
>>884
Java良く知らんのだけどJavaはスワップしちゃ駄目なんですか?

888 :仕様書無しさん:2007/02/18(日) 14:14:50
スタティックメソッドって出てたけど、税率計算処理に対して商品データを渡すってことは考えないで、
OOPだと個々のデータが処理を持つって考え方だよ〜

データを取りまとめる親玉がいて、それが個々のデータに計算を任せる。
もしかしたら親玉もまた別の親玉に取りまとめられているかもしれない。これがOOP。


889 :仕様書無しさん:2007/02/18(日) 14:31:55
消費税計算、難しいですね
旧来なら消費税を返す関数を作るところだけど
OOPなら商品のプロパティなりメソッドで返すようにするんですね
そういえば大抵のオブジェクトには tostring が用意されていたりしますね

890 :仕様書無しさん:2007/02/18(日) 14:34:52
OOPの流行らない一番の原因、それは

「客がオブジェクト指向が分からない。」

だと思うよ。

データベースのER図はこれです。
処理は○○処理、××処理、・・・があり、この処理を呼ぶとこうデータを処理します。
といったほうが分かる。

OOPだと最終的なクラス図見せられてもデータ構造は分かるけど、
処理が細切れに各クラスに分割されるので一目見ただけだと分かりにくい。

クラス図+シーケンス図で初めて処理内容が分かる。


891 :仕様書無しさん:2007/02/18(日) 14:38:06
>>889
それ以前の問題として、税率は商品の属性なのか?

892 :仕様書無しさん:2007/02/18(日) 14:40:56
税率は国家クラスの属性だからグローバルでいいよ。

893 :仕様書無しさん:2007/02/18(日) 14:44:04
客かどのレベルの客かが問題だな
エンドユーザだとDBもERもわからんだろうし、ある意味やりたい放題だし、
ある程度の企業のシステム部だと変に言葉とかに詳しくて、かえって困ったりする。
>>890みたいな感じの客は、メーカ系列系のソフトハウスかな。


894 :仕様書無しさん:2007/02/18(日) 14:50:39
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);

}
}

895 :仕様書無しさん:2007/02/18(日) 14:51:10
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;

}

}

896 :仕様書無しさん:2007/02/18(日) 14:53:03
細かい計算方法は突っ込みどころ満載だけど、GoodsListインスタンスをUserが持っていれば
簡単にショッピングカートWebサイトの出来上がり。

897 :仕様書無しさん:2007/02/18(日) 14:54:48
つか、処理なんてわからなくていいよ。
手続きの塊としてしかシステムを理解できないのは、旧態依然のやり方に頭が毒されてるから。
内部でどんな処理されてるかなんて知らんが自動販売機も使えるしExcelも使える。

898 :仕様書無しさん:2007/02/18(日) 15:02:14
>>897
それは、プログラムなんて出来なくても、設計は行えるという意味ですか?

899 :仕様書無しさん:2007/02/18(日) 15:05:57
>>898
実装設計は言語依存だから無理だけど
基本的なOOPの考えがしっかりしてれば

このクラスはこの責務があってこの属性、関連を持たせる。
で、このメソッド呼ぶと関連持ってるクラスのこのメソッド使って計算してこれを返す。

ってことが分かれば、あとは各クラスについてそれの繰り返しだから設計は問題なく出来ると思うよ。


900 :仕様書無しさん:2007/02/18(日) 15:10:41
たかじん終わったからもういいや

901 :仕様書無しさん:2007/02/18(日) 15:14:49
>>898
設計時は、自分で実装しなきゃいけない手続きがどれなのかすらわからん
前段と後段のフレームワークのスキマコード

902 :仕様書無しさん:2007/02/18(日) 15:21:19
実は消費税ひとつとっても業務システムの場合そう単純じゃないんだよね
データはは内税で持たせるのかにするのか、外税で持たせるのかにするのか、
計算は総額に対して行うのか商品ごとに行うのか
総額の場合、日計、月計、年計で丸め誤差が出るがどうすのか
要求によっては、商品ごとに丸め方をかえてくれだとか
打ち合わせしているうちにお客さんの業務や会計処理に誤りを見つけてしまったり
それが法的に問題ありだったり
あげくの果ては、そういった業務改善についてのコンサルタントまがいの事してたりして
まあ、田舎の話なんだけど
お客さんのところに電算部門とかあって
コボラー中心で構成されていたら
OOPはムリポ

903 :仕様書無しさん:2007/02/18(日) 15:24:31
>>901

別に設計時にわかる必要は無いと思うが
OODだと理想的には、細かい手続きは、実装に任せるはずだし。

904 :仕様書無しさん:2007/02/18(日) 15:28:30
>>903
いやだから、わからんでもいいとゆうておる

ただまあ、プログラミングによほど習熟してなきゃ
わからんでいいという意味もわからんだろうが。

905 :仕様書無しさん:2007/02/18(日) 15:29:02
>>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だと超複雑怪奇になるけど

906 :仕様書無しさん:2007/02/18(日) 15:30:32
>>894-895
ちょっちまってくれ
たかが消費税を計算するのにそんなにクラスと変動可変データの結合度を強く持たせるのは
汎用性というかクラス設計に問題があるとおもうが。といっても代替案はないけどね。
ちょっとみんなで考えてほしいよ。疎結合なクラスというのをさ。
消費税の例でいいじゃん。

907 :仕様書無しさん:2007/02/18(日) 15:31:17
間違い、

Goods goods = (Goods)i.next();
if(日付が今日のもの){
sum += goods.getTaxedPrice();
}

だ。

908 :仕様書無しさん:2007/02/18(日) 15:33:08
>>906
>たかが消費税を計算するのにそんなにクラスと変動可変データの結合度を強く持たせるのは
>汎用性というかクラス設計に問題があるとおもうが。といっても代替案はないけどね。

それこそストラテジーパターンだよ。
消費税計算方法とかいうクラスを別に作って、商品リストが集計するときに
商品クラスにセットしてあげればいいじゃん。

909 :仕様書無しさん:2007/02/18(日) 15:34:25
本来のOOの基本的な考え方だと
センダにメッセージを投げる(仕事の依頼)=>レシバは仕事をし、結果を返す
この場合消費税があってもなくてもセンダ側は意識しないで結果だけを求め
られるのが理想。税抜き、税込みどちらの計算もレシバが面倒をみてくれるはず。
しかしここで問題なのが結合度。レシバ側のクラス設計と変動データをどう
解決するかがポイント。

910 :仕様書無しさん:2007/02/18(日) 15:36:32
そしてポリモアフィズムを利用した美しい昇華のシナリオが満たせるかどうか。

911 :仕様書無しさん:2007/02/18(日) 15:40:55
・全商品に一律同じアルゴリズムで消費税計算させたい。
⇒DefaultStrategyをセット

・一部商品は違うアルゴリズムで計算させたい
⇒商品を継承した本クラスにだけBookStrategyをセット

こうしておけば、商品クラスのgetTaxtedPriceでポリモーフィズムつかって
それぞれ違うアルゴリズムで計算できる。

912 :仕様書無しさん:2007/02/18(日) 15:41:17
そんなもん考えてる暇があったらどんどんコーディングしたほうが
早い

913 :仕様書無しさん:2007/02/18(日) 15:41:35
ストラテジパターンで内部スイッチを切り替えるのにフラグパラメータ
が必要なるということ?
理想論だけどポリモで解決できる方法はないだろうか?

914 :仕様書無しさん:2007/02/18(日) 15:44:20
>>912

でもそれだとif文の入れ子かSwitch文になるよ?
あとでまた別の方法で・・・となったときも修正大変そうじゃね?

915 :仕様書無しさん:2007/02/18(日) 15:44:29
クラスの継承でポリモね。それはパターン数が莫大になった場合は
使えないよね。パターン数が限定的ならばひとつの解決方法。

916 :仕様書無しさん:2007/02/18(日) 15:46:12
それでも修正時間のほうが短い

917 :仕様書無しさん:2007/02/18(日) 15:47:23
>>913
ちがうよ。消費税計算方法っていうクラスのIFだけ同じにしといて
呼び出し側(GoodList)が実装クラスを入れ替えれてやれば商品クラスがフラグ持つ必要ない。

集計方法を知っているのはGoodsListクラスだからね。
ゴリゴリ集計処理をGoodsListクラスに書いてもいいけど修正が大変じゃん?

918 :仕様書無しさん:2007/02/18(日) 15:51:19
>>916
やってることは結局GoodListで集計するんだから、それをゴリゴリ書くのか、
それともストラテジパターン使って消費税計算処理をセットして集計させるかの違いだよ?

GoodsListの利用側はGoodsListがゴリゴリ集計処理を頑張っていようが
ストラテジーパターンつかって集計してようがしったこっちゃない。

919 :仕様書無しさん:2007/02/18(日) 16:00:09
>>916

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クラスに書いてもいいけど
仕様は満たせるけど合理的ではないですな。

921 :仕様書無しさん:2007/02/18(日) 16:15:36
>消費税計算ってもっとジェネリックな位置にあると仮定して別の
>解決方法はないですか?

うーん、一般的なのはやっぱ上のパターン使っちゃう奴じゃないかなぁ?
価格渡せば消費税込みの価格返すメソッドを持つIFのクラスを、具象クラス単位に作る。
汎用性が欲しければデフォルトの1個作って予めセットしておけばいいだけでしょ?

汎用的っていうのは、とりあえず商品インスタンス渡せば中で区別して
それぞれ計算処理してくれる汎用クラスってことでしょ?>>919みたいな。

そういうのがあっていいかも知れないけど
「変更が入りそうなところはどこか」に着目すれば、個別に切り出しておくほうがメリットあると思われ。

922 :仕様書無しさん:2007/02/18(日) 16:24:03
public Double getTotalPrice(){
の汎用クラス関数は業務の局所的な依存ではいいよね。これしかない。
でもさ、ジェネリックなカテゴリはいちど作ったら全部使える(使いたい)
データ型依存なぞ無い。という理想を目指すとどうなるんだろう。

1. このメソッドの内部判断が膨れ上がる
2. Prototypeパターンを利用する
どうすればいい?

923 :仕様書無しさん:2007/02/18(日) 16:25:17
さっきから消費税の実装レベルの話してる奴はあったまわりぃなw

924 :仕様書無しさん:2007/02/18(日) 16:25:42
「結局1.05掛けるだけだろ。」
って話になって現場の設計に温度差が出る現状。

925 :仕様書無しさん:2007/02/18(日) 16:25:59
毎回毎回、設計だっつってんのにこんな糞レベルの話持ち出していい加減馬鹿過ぎで頭にくる

926 :仕様書無しさん:2007/02/18(日) 16:27:04
ここは宿題を答えるスレか?

927 :仕様書無しさん:2007/02/18(日) 16:28:06
>>925

それでは、高度な話題をどうか、書いてくれません。

928 :仕様書無しさん:2007/02/18(日) 16:29:20
だからさ、設計のスレだっていってんのにソースコードなんて貼ってる奴は素質ねぇんだよ。
実装レベルで出る問題点だって範囲が広すぎてレスにソース貼った程度じゃ表現できねぇっての。
そんなこともわからないほど経験が浅いからムカツクんだよ。

929 :仕様書無しさん:2007/02/18(日) 16:29:42
>>927
日本語でおk

930 :仕様書無しさん:2007/02/18(日) 16:30:33
>>928

ムカツクんなら、見なきゃ良いのに・・・

931 :仕様書無しさん:2007/02/18(日) 16:31:23
>>928の経験が浅いこともよくわかった

932 :仕様書無しさん:2007/02/18(日) 16:33:35
>>925
じゃあお前がネタ振れ、このザコ
理解できねからってファビョってんじゃねえボケ
死ね。

933 :仕様書無しさん:2007/02/18(日) 16:33:39
消費税程度のもんになんでストラテジとかいってんの、んなもんテンプレート
メソッドパターンとかで十分だと思うけど。そんなことやってたたらシステム全体
がストラテジだらけになっちゃうよ。ドキュメントにまとめて説明したり、理解さ
せるのに時間かかりそうだな。ただの自己満足じゃないの? むりやり小難しくし
てない?。技術を使うのが目的になっちゃってるような。

934 :仕様書無しさん:2007/02/18(日) 16:33:43
現実問題として、設計段階でこんなちまちまやってたら、
いつまで経っても終わらんわな。

935 :仕様書無しさん:2007/02/18(日) 16:33:46
>>928

すみません、実装コードは参考程度に考えてください。
データがメソッドを持つことの意味が分からない場合には
ソース書いたほうが早い気がしたので。

936 :仕様書無しさん:2007/02/18(日) 16:33:53
だいたい、何?
はぁ?消費税?
なんでこんなもんクラスにしてんだよ。
馬鹿か、アホか、給料ドロボーもたいがいにしろよ。
プログラマなんて辞めろ。今すぐ辞めろ。なんでこんなアホ、野放しにしとくんだ。
早く死ねよ。

937 :仕様書無しさん:2007/02/18(日) 16:34:25
>>931
ハヤクネタフレや。もしくは死ね。

938 :仕様書無しさん:2007/02/18(日) 16:34:34
>>935
頭悪いんだよ。お前。早く死ね。

939 :仕様書無しさん:2007/02/18(日) 16:34:59
>>932
宿題がんばれよ

940 :仕様書無しさん:2007/02/18(日) 16:36:00
まぁ、茶でものんでもちつけもちつけ。

941 :仕様書無しさん:2007/02/18(日) 16:36:33
次スレは、くだらないスレにならないよう、>>925がナイスなネーミングで
たてるそうです。乞うご期待。。。

942 :仕様書無しさん:2007/02/18(日) 16:37:12
あえて、簡単な例で、じっくり考えてみようって
趣旨が判らんのかね

943 :仕様書無しさん:2007/02/18(日) 16:37:45
>>928
煽るようで非常に申し訳ないですが、

当然実際の業務AP開発じゃこんなのは一部に過ぎないですお(^ω^)
ただOOPの概念というか基礎的な部分をソース交えて説明したかっただけだお(^ω^)

944 :仕様書無しさん:2007/02/18(日) 16:38:12
何が「設計レベルの高度な・・・」だよ恥ずかしくないのか、マジ死ねや。

945 :仕様書無しさん:2007/02/18(日) 16:38:14
>>925じゃないけど、
「上流工程でオブジェクト指向が〜」の方がいいわな。

946 :仕様書無しさん:2007/02/18(日) 16:43:31
だから上流も下流もないっての

947 :仕様書無しさん:2007/02/18(日) 16:43:46
結局はスレタイの主語がはっきりしないから
前提で混乱してるってことだわな。

948 :仕様書無しさん:2007/02/18(日) 16:45:13
そもそもオブジェクト設計ってなんだよ?造語か?

949 :仕様書無しさん:2007/02/18(日) 16:45:32
>>946
じゃあ韓流でおk?

950 :仕様書無しさん:2007/02/18(日) 16:46:03
濁流濁流

951 :仕様書無しさん:2007/02/18(日) 16:46:09
次スレ
●●オブジェクト設計は何故流行らないの?(2)●●
http://pc10.2ch.net/test/read.cgi/prog/1169568701/l50
重複再利用で。

とてつもないグッドなスレタイ思いついた人居たら、俺が別途立てますが

952 :仕様書無しさん:2007/02/18(日) 16:46:31
>>948
これは確かにおかしいな

953 :仕様書無しさん:2007/02/18(日) 16:48:58
オブジェクト指向が設計段階で何故流行らないの?(スレタイ改め)(2)
どう?>all

954 :仕様書無しさん:2007/02/18(日) 16:49:05
あーあ
荒れちゃったよ

955 :仕様書無しさん:2007/02/18(日) 16:50:17
簡単な例の解決もできないのだから複雑な問題解決は絶対できんだろうなあ。
それこそ焼きビーフンのような設計になってしまう。

956 :仕様書無しさん:2007/02/18(日) 16:50:45
恥ずかしながら俺は、オブジェクト設計とクラス設計の違いがわからん。

957 :仕様書無しさん:2007/02/18(日) 16:50:58
焼きビーフン設計とはなんだ??
初めて聞いたぞ。

958 :仕様書無しさん:2007/02/18(日) 16:51:21
上流、下流とはいってもオブジェクト指向開発って結局業務分析からエンティティ抽出して
その関連を定義して、ユースケースでエンティティ操作するんだろ?

それが実装に落ちると基本的にはエンティティ部分は変わらないが、
実装方法としてのOOPやデザインパターンがある。それにの則った話に過ぎないと思うんだがどうか?
エンティティ抽出までは出来たOOP理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。



959 :仕様書無しさん:2007/02/18(日) 16:52:36
×エンティティ抽出までは出来たOOP理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。
○エンティティ抽出までは出来たが、OOPを理解してなくて単なるトランザクションスクリプトになる例が多すぎる訳で。






960 :仕様書無しさん:2007/02/18(日) 16:53:30
>>958
すまんが日本語に翻訳してもらえないか。

961 :仕様書無しさん:2007/02/18(日) 16:53:52
教科書的には税金の計算方法が変化する可能性がある場合はストラテジパターン
なんだろうけど、仕事の場合は、設計してるソフトウェアの業務ドメイン
による、というのが実際のところだよな。

実業務では実装も設計および要求と無関係でいられることはない。
(と無理やり設計の話に結びつける)

不必要な柔軟性も不十分な柔軟性と同じように保守性を下げるから、
なんでもかんでもストラテジ、とか仕事でされるとマジで逝ってよしだな。



962 :仕様書無しさん:2007/02/18(日) 16:55:19
>>961
それだよ。理想と現実のせめぎあいと妥協の産物
これがOOの現実。

963 :仕様書無しさん:2007/02/18(日) 16:58:36
頭の中では理想を貫きたいのだが
実際は客が要求する正規化もろくにされてない昔から使ってるDB
を現代のOOP言語システムでリメイクする。
データ構造の基本設計は前近代なのに最先端技術と結びつけようとする
ところに歪がでる。結局理想は理想でしかなくなり、ジャワのコードは
シーケンシャルな手続き代入文で終始する。

964 :仕様書無しさん:2007/02/18(日) 16:58:51
>>960
上流、下流とはいってもオブジェクト指向開発って
結局業務分析から扱うデータ抽出して、その関連を定義して、CRUD操作するんだろ?

それが実装に落ちると基本的にはデータ構造は変わらないが、
実装方法としてて、オブジェクト指向プログラミングやデザインパターンがある。

それにの則った話に過ぎないと思うんだがどうか?
データ構造の抽出までは出来たが、OOPを理解してなくて単なるSQLでのDBへのCRUD操作、
複雑なSQLベースのシステムになる例が多すぎる訳で。


965 :仕様書無しさん:2007/02/18(日) 16:59:27
まぁあれだ。
オブジェクト指向で使われる用語は、
それなりに個々が学習しないと認識がずれる。
実装段階は言語規約(クラス、継承とか)を守る必要があるのでPGもそこは学習するが、
「考え方」の一つであるオブジェクト指向は個々の学習には期待できん。


966 :仕様書無しさん:2007/02/18(日) 17:01:16
>>964
おまぃ、いい奴だな。

967 :仕様書無しさん:2007/02/18(日) 17:01:51
ボクはね。こうおもうんだ。

この世からRDBMSとSQLが無くなればOOPを理解せざるを得ない。

どう?

968 :仕様書無しさん:2007/02/18(日) 17:02:37
>>964

RDBを使うなってこと?

969 :仕様書無しさん:2007/02/18(日) 17:04:09
ボクはね、こう思うんだ。
PG職、SE職は免許制。

970 :仕様書無しさん:2007/02/18(日) 17:07:31
      ☆ チン     マチクタビレタ〜
                        マチクタビレタ〜
       ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        ヽ ___\(\・∀・) < 焼きビーフン設計まだ〜?
            \_/⊂ ⊂_ )   \_____________
          / ̄ ̄ ̄ ̄ ̄ ̄ /|
       | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
       |  スレタイ微  |/

971 :仕様書無しさん:2007/02/18(日) 17:08:16
>>968

データの保存先なんて別にDBじゃなくてもいいでしょー?
ファイルでファイルシステムに保存したっていいし
XMLに保存してもいいじゃん。

OOPで考えればオブジェクトを長期保存できればDBなんて別にいらんのよ。
便利でアクセスが早いから使ってるだけ。

シムシティってゲームあるけど、DB使ってるか?
メモリ状態をそのままスナップショットとってRAMに入れて永続化してるだけでしょ?
警察署オブジェクトが建物テーブルに格納されているか?


972 :仕様書無しさん:2007/02/18(日) 17:08:51
>>969

ある程度同意だが、誰がどういうテストをするかが問題だな。
今の情報処理技術者資格試験を考えると上手く行くとは思えん。

973 :仕様書無しさん:2007/02/18(日) 17:09:03
                       _∧_∧_∧_
        ☆ パリン 〃   ∧_∧   |
          ヽ _, _\(・∀・ ) <  マ
             \乂/⊂ ⊂ ) _ |_ _ _ __
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/| .  ∨ ∨ ∨
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/



   _  ___
   \>,\/

          <⌒/ヽ-、_ _
          <_/____ノ

974 :仕様書無しさん:2007/02/18(日) 17:12:30
>>972
まぁ、情報処理技術者資格に当てはめるかどうかは別の話として、
学習する奴・しない奴の選別の材料ぐらいはほしいんだよな。
オープンソースなんて出来ない奴を排除してるから、
評価されるものが出来てるわけで。

975 :仕様書無しさん:2007/02/18(日) 17:14:32
>>971

データが格納されてると考える限り、RAMに有ろうがファイルに有ろうが
どうやっても、例のトランザクションコードになるように思えるのだが

ファイルからデータを呼び出して書き込む(ry

ってコードになると思うぞ。

976 :仕様書無しさん:2007/02/18(日) 17:18:10
そこは基本的に同じだよ。

問題はSQLクエリの便利さにOOPの良さが消されちゃってるってこと。
SQLではオブジェクト上でも、関連のないデータも結合して取ってこれちゃうからね。

977 :仕様書無しさん:2007/02/18(日) 17:20:31
いきなり2つのファイル内のこの属性を結合してマッチしたファイルを取得するなんてファイルシステムじゃ出来ないでしょ?
OOPなら、個々のファイルをインスタンス化すれば関連を使って辿れるんだよ。

978 :仕様書無しさん:2007/02/18(日) 17:21:40
つ ORM

979 :仕様書無しさん:2007/02/18(日) 17:23:34
そうか、クラスの関連無視してデータ取れたり計算できるところが
クラスをただのデータを入れる箱にしている根本原因てことか。

980 :仕様書無しさん:2007/02/18(日) 17:24:25
>>977
おまぃ、説明うまぃな

981 :仕様書無しさん:2007/02/18(日) 17:27:07
>>976

なるほど、そういう意味か。
それなら、それが悪いかどうかは、かなり微妙なんじゃないか?
俺らはOOを生かす事が目的じゃなくて、
総合的になるだけ楽な設計・実装をするのが目的だから、
便利なら、RDBMSを使うべきだ。


982 :仕様書無しさん:2007/02/18(日) 17:28:44
      ☆ チン     マチクタビレタ〜
                        マチクタビレタ〜
       ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        ヽ ___\(\・∀・) < 新スレまだ〜?
            \_/⊂ ⊂_ )   \_____________
          / ̄ ̄ ̄ ̄ ̄ ̄ /|
       | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
       |  カプセル化  |/


983 :仕様書無しさん:2007/02/18(日) 17:36:00
―――――――――――――‐┬┘
                        |
       ____.____    |                                 ☆/
     |        | ∧_∧ |   |    チンチンうっせーんだよ ゴルァ!  :|\   \∧_∧
     |        | (# ´Д`)|   |                        |  \  (;´Д`)○
     |        |⌒     て)  人                    / ̄ \ : \ ̄ ̄/| ○
     |        |(  ___三ワ <  >  ====≡≡≡三三三三:| ̄ ̄ ̄ ̄ ̄ ̄ ̄ :| :|
     |        | )  )  |   ∨                    |  カプセル化   :|/
        ̄ ̄ ̄ ̄' ̄ ̄ ̄ ̄    |

984 :仕様書無しさん:2007/02/18(日) 17:38:45
チン      ☆  チン       ☆
       チン    マチクタビレタ〜   チン     ♪
           ♪
    ♪          ☆チン    .☆   ジャーン!   マチクタビレタ〜!
        ☆ チン   〃  ∧_∧  ヽ         / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ  ___\(・∀・ #) /\_/ <  まだー?
        チン    \_/⊂    つ    ‖     \__________
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|     ‖        マチクタビレタ〜!
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|   /|\
        |             |/

985 :仕様書無しさん:2007/02/18(日) 17:50:15
次スレ
●●オブジェクト設計は何故流行らないの?(2)●●
http://pc10.2ch.net/test/read.cgi/prog/1169568701/

986 :仕様書無しさん:2007/02/18(日) 19:19:37
外的な品質(顧客に対する品質)と内的な品質(開発者にとっての品質)を別々に
考えて議論できないものだろうか?

987 :仕様書無しさん:2007/02/18(日) 19:25:36
開発中にもコロコロ仕様が変わり根本から考え直す必要がしょっちゅう
出てくる現状で内的な品質向上なんて無理。
営業が顧客満足しか考えてないからね、メンテナンス無視した一時的な
満足度しか上げられない。

988 :仕様書無しさん:2007/02/18(日) 20:35:31
論外。それは
コストとスケジュールの見直しのない仕様変更を
受け入れるような組織/プロジェクトが元凶なのだ。

>>986
各種品質特性を二分して別個に考えることに意味があるとは思えない。
そう思わないなら、その利点/意味を提示してみて欲しい

989 :仕様書無しさん:2007/02/18(日) 20:51:05
俺は>>986じゃないけど、
単純に技術論だけを語りたいか、経済的な観点も含めて語るかじゃないの?
どちらを選択するかで内容も変わってくると思うけど・・・

990 :仕様書無しさん:2007/02/18(日) 22:13:57


991 :仕様書無しさん:2007/02/18(日) 23:47:14
みんな暇ね〜☆

992 :仕様書無しさん:2007/02/19(月) 00:09:24
いや、ハングル語や広東語を交えて書かれると
解読不能だよ!
きちんと日本語使って欲しいな!

993 :仕様書無しさん:2007/02/20(火) 00:33:56
OO厨 兄w

994 :仕様書無しさん:2007/02/20(火) 01:07:52
体調が悪いので休ませてください・・・
 ↑嘘つくな!
昨日終電で・・・
 ↑昼から来てたくせに何言ってんだよ!


995 :仕様書無しさん:2007/02/20(火) 01:31:15
新スレはこちら
【OOD/P】オブジェクト指向開発はなぜ流行らないの?★3
http://pc10.2ch.net/test/read.cgi/prog/1171808096/

996 :仕様書無しさん:2007/02/20(火) 12:13:16
1000ならBoehm GCをインストールして使ってみる

997 :仕様書無しさん:2007/02/20(火) 12:16:12
997

998 :仕様書無しさん:2007/02/20(火) 12:16:42
998

999 :仕様書無しさん:2007/02/20(火) 12:17:13
999

1000 :仕様書無しさん:2007/02/20(火) 12:17:43
1000なら俺はオブジェクト神になれる。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

289 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)