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

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

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

1 :真面目なネラー:2007/01/04(木) 01:28:54
オブジェクト設計は何故、どうして流行しないのだろうか?
とても有益だと思うが?
30歳代ですが、中途採用試験でオブジェクト設計をやりたいと言っても
ほとんどスルーされます。
結局、PG屋で我慢してます。
 

2 :仕様書無しさん:2007/01/04(木) 01:34:12
駅前のオブジェ設計したい

3 :仕様書無しさん:2007/01/04(木) 01:35:59
オブジェクト設計www

4 :仕様書無しさん:2007/01/04(木) 01:47:35
人海戦術・長時間労働の蔓延で 客も会社もいかなる手法であろうと設計を評価しません。
今求められるのはお客様が右向けと言えば右を向き、脱げといわれれば脱ぐ従順さです。

5 :仕様書無しさん:2007/01/04(木) 02:01:26
>>1
周りは、本当の有用さがわかってないのだと感じる。

所詮は、トップの鶴の一声。下が遣りたいからっていっても、そのときは無視。
しかし、社長がオブジェクト設計の技術者を養成しなさいと言ったら、
とたんにその方向に行く。
大変だが、自分が遣りたかったら、業務とは切り離して勉強しておいたほうがよい。
俺はそうした、それでオブジェクト専門の部署ができて、そこの配属になった。
今は、それで給料がもらえている。
しかし、これもそう長くは続かないので、次の飯の種を探しているよ。

6 :真面目なネラー:2007/01/04(木) 02:36:22
なんで流行しないかは、やっぱ、必要ないからでしょうか?
あちこちの大手、中堅のITを面接しまくればはっきりするのでしょうが、
面接嫌いなものであまり生の情報が入りません。
少なくとも、私が面接した3社の中小ITは、Java、C++をやってるのに
オブジェクト設計には関心を示しませんでした。


7 :仕様書無しさん:2007/01/04(木) 05:05:39
オブジェクト専門w

8 :仕様書無しさん:2007/01/04(木) 06:25:31
これは俺も不思議に思っていた。
オブジェクト指向の設計をしたかったんだが、
あまりに見向きもされない(というか理解されない?)ので
しばらくまったく関係のないNEをやっていた。

9 :仕様書無しさん:2007/01/04(木) 14:35:39
中堅から上の年代の連中がオブジェクト指向(oo)を理解できないのが一番の理由かと。
そういうオレもベテランと言われる歳だが、積極的にooを推進しようとしても他のベテラン連中が
昔ながらの構造化設計(sd)しかできないため、若手もそのやり方しか身に付かずなかなか広まらない。
sdは仕事の中で見よう見まねでできるのに対し、ooは頭の切換が必要。
なので仕事をやりながら覚えるのは無理。これも壁のひとつだと思う。

10 :仕様書無しさん:2007/01/04(木) 14:43:36
原因:「オブジェクト指向設計」と「オブジェクト指向プログラミング」の相性が悪いから


11 :仕様書無しさん:2007/01/04(木) 14:44:40
もう思い切って希望者による別チームとした方がいいと思う
構造化しかやろうとしない人間はほっといて


12 :仕様書無しさん:2007/01/04(木) 14:53:41
>>10
構造化設計が構造化プログラミングから生まれたように、オブジェクト指向設計も
オブジェクト指向プログラミングから生まれたもの。
相性が悪いということは無いと思うが・・・

13 :仕様書無しさん:2007/01/04(木) 16:01:41
>>12
×: オブジェクト指向プログラミングから生まれたもの。
○: オブジェクト指向プログラミングから "無理やり" 生み出したもの。

この手の設計技法をひねり出す奴らは、
とりあえず新しいプログラミング技法に「設計」と名前を付けさえすれば
5年は飯を喰えると思っているようだし。

中身なんてどうでもいいんだよ。名前だけが重要なの。
http://d.hatena.ne.jp/keyword/%A5%AA%A5%D6%A5%B8%A5%A7%A5%AF%A5%C8%BB%D8%B8%FE%C0%DF%B7%D7

そのうちきっと「アスペクト指向設計」とか出てくるぞ。


14 :仕様書無しさん:2007/01/04(木) 19:33:01
でもさあ、仮にオブジェクト指向設計をやらないとしてSEはPGにどんな設計書をわたせばいいんだろう。
ウチのところだと手続きチックな処理定義書がPGに渡されて
んで基盤技術はASP.NETでおねがいします、とかそんな感じなんだよね。

とうぜんそんなもん何の役にもたたず、むりやりそこから実装レベルでクラス設計しなおすんだけど
ヨソはどうやってるんだろうか。。


15 :仕様書無しさん:2007/01/04(木) 20:03:44
>>14
>ヨソはどうやってるんだろうか。。

どこも同じだろ?

しかも、それらの仕様書が
下手にオブジェクトチックに書かれていると
もう手が付けられない。

酷いのになると、ユースケース作成時に書いた
ユースケースやアクターを
そのまま "オブジェクト" として設計書に記述してきやがる。

「何を作るのか?」の内容から「どう作るのか?」へ変換することが
本当の設計なのに、
「何を作るのか?」だけを拾い出して(もちろん内容は不十分・・・)、
それらを無理やりクラス図にマッピングなんかしてみたりして、
「完璧な設計だろ! これだけやってやったのに、何でモノが作れないんだ?」
なんて文句を垂れるのが、今の日本の SE の仕事。

手続きチックな処理定義書のほうが(変に縛られない分)まだ "まし" だよ。


16 :仕様書無しさん:2007/01/04(木) 20:36:08
なるほど、手続きチック処理定義書は単にゴミだが
勘違いOOD設計書は毒になるってわけか。。

となると、OODは推進しないほうが安全ってわけね。

17 :仕様書無しさん:2007/01/04(木) 20:58:16
会社自体がオブジェクト指向の設計に協力的なら、
実装に落とすまでの道筋の試行錯誤もできるだろうけどねぇ。

18 :仕様書無しさん:2007/01/04(木) 21:03:51
そんなものはオブジェクト専門の担当者にまかせておけばいいんだよ!

19 :仕様書無しさん:2007/01/04(木) 21:08:15
仕事上、どうしても線表がついてまわるからなぁ。

「試行錯誤の進捗率」の報告の仕方が見つかれば、
多少はこの業界も建設的になると思うのだが。


20 :仕様書無しさん:2007/01/04(木) 21:15:25
実装する奴が設計レベルの試行錯誤するのが現状である以上、
はっきりいってコード書かないSE(フィールドSE除く)なんていてもしゃーない。

21 :仕様書無しさん:2007/01/04(木) 22:08:49
熟練者は試行錯誤してる時間が極端に短いよね。使えない人間はいつまでも
うだうだやってる。そばで見ていて痛々しいぐらいにね。

22 :仕様書無しさん:2007/01/04(木) 22:50:34
>はっきりいってコード書かないSE(フィールドSE除く)なんていてもしゃーない。
コードを書かないのではなく「書けない」というのが最近のSEの常識。
VBだけでも知っていればいい方。酷いのになるとDB設計とUI設計だけのものを
設計書と信じて疑わないヤツもいる。

23 :仕様書無しさん:2007/01/04(木) 22:59:02
不思議でしゃーねーんだが、なんでコード書かないのよ?
書けないことないだろ、書けばいいだけなんだから。

SEの奴らはどういう風に教わってるの?

24 :仕様書無しさん:2007/01/04(木) 23:06:09
>SEの奴らはどういう風に教わってるの?

「書かない奴が一番偉い。仕事をしなければ失敗もしない。」と・・・


25 :仕様書無しさん:2007/01/04(木) 23:12:15
コードや技術も資産なのに、それが貯まらないとなると

26 :仕様書無しさん:2007/01/04(木) 23:16:01
コードを書くのは下っ端のやること。偉いヤツは設計しかしない。

と思いこんでいるのです。
実際、コードなんて書いたことすら無いという自称SEはたくさんいるよ。
そういうヤツに設計させるとロクでもない設計書作るけどな。

27 :仕様書無しさん:2007/01/04(木) 23:22:38
>>そういうヤツに設計させるとロクでもない設計書作るけどな。
みんなseはドリーマですよ。苦労するのは実際作る人

28 :仕様書無しさん:2007/01/04(木) 23:23:18
>コードを書くのは下っ端のやること。偉いヤツは設計しかしない。
>と思いこんでいるのです。

これ、相当古いと思うんだけど未だにこんなのいうとこあるのかな。
コボラか?

29 :仕様書無しさん:2007/01/04(木) 23:32:49
わざわざ オブジェクト設計だとか
そんなん数秒でやる仕事だ

30 :仕様書無しさん:2007/01/04(木) 23:34:03
>>28
ウチの会社では年寄りほど「コード書くのは下っ端」と思い込んでるフシがあるよ。
でもそれは「技術に追いつけなくなった」ことの言い訳に過ぎないのが見え見えなんだがな。

31 :仕様書無しさん:2007/01/04(木) 23:36:46
>>29
俺はコード書いては消してって何回もやらないとだめなタイプだから数秒では無理だ。

32 :仕様書無しさん:2007/01/05(金) 00:31:33
だって普通にERD+DFDのほうが分析/設計しやすいんだもん。
データベースこねくりまわすだけの業務ソフトに設計レベルのOOなんて必要ない。

33 :仕様書無しさん:2007/01/05(金) 01:01:25
>>31
頭の弱いやつだな。
オレと一緒だw

34 :仕様書無しさん:2007/01/05(金) 01:03:55
1はSIerじゃなくてIT企業うけたら?
スキル高い人多いし、向上心ある人には向いてると思う

35 :仕様書無しさん:2007/01/05(金) 03:11:02
数年前の話なんだけど、「本格的なオブジェクト指向開発をやるのでOODやれる人材が必要」
という話があり、C++やJavaでOOPやってた俺に白羽の矢が当たった。
当時、UMLとか勉強中だったし「オブジェクト指向設計やってくれ」ということで、
未熟ながらも腕を磨きたい一心で参画した・・・。

が、その現場はよどみ切ったコボラたちの巣窟であった。オブジェクト指向を全く知らない人間ばかりだった。
外資系の技術者が来て、たった2日でサジを投げて辞めたこともあったらしい。

(後でわかったが、その案件は新聞紙上で「○○○○が本格的なオブジェクト指向開発をする」と
 大々的に宣伝されていたようだ。オブジェクト指向わかる人間が欲しかったらしい。)

俺はめげずに、ユースケース図やクラス図、シーケンス図等を書き、さらにオブジェクト指向が
どういうものかというレベルから現場に啓蒙しようと努めたのだが、ことごとく否定され、
「こんな図は偉い人に見せても理解してもらえない」という理由により、設計図は没にされ、
代わりにフローチャートモドキの変な図やらを書かされるハメになった。

(こいつら、一体何がやりたかったのだろう・・・)

結局、オブジェクト指向の「オ」の字も出来なかったので、ついには俺も撤退させてもらったが、
こういう建前だけ「オブジェクト指向です」という状況もあるかもしれない。(迷惑な話だ。)

36 :仕様書無しさん:2007/01/05(金) 06:53:13
>>32
同意・・・

37 :仕様書無しさん:2007/01/05(金) 08:13:08
いかに優れた理論でも、実践に適用できないものは価値はないよな。

38 :仕様書無しさん:2007/01/05(金) 11:07:39
俺の会社だけに話を限定すると、オブジェクト指向で設計されたものを実装
してると、最終段階あたりでレスポンスの問題が発生しやすい。しかも、この
問題を解決するにはかなり骨が折れる。
それでもオブジェクト指向で設計する理由は、メンテが楽だから。メンテに
かかる労力を新規開発時にかけられる時間的余裕がある場合に限られる。

39 :仕様書無しさん:2007/01/05(金) 12:41:24
一昔前に「モジュール設計」というのが流行ったが、
何をモジュールと呼ぶのかで色々議論していたが、結局は誰もモジュール設計はしなかった

現代はオブジェクト志向も何をオブジェクトと呼ぶのかで色々議論してるだけで
結局は誰もオブジェクト指向設計なんてしないと思う。

最悪の場合はUMLで書かれたで非オブジェクト指向なものが出来るだけ
昔はgoto文がない非構造化プログラムが一杯あった。

40 :仕様書無しさん:2007/01/05(金) 15:55:14
つか、クラス的な考え無しで作ってる奴はさっさと消えれば良いのに


スパゲティはのちのちこまる

41 :仕様書無しさん:2007/01/05(金) 16:11:02
クラス的な考えは無くても良い。
オブジェクト的な考えがあれば良いのでは?


42 :仕様書無しさん:2007/01/05(金) 18:22:48
元SE(兼PG。つうか、実装の方が好きだった)です。

昔居た会社では新人研修と社内研修でオブジェクト指向を推し進めていました。
でも、研修でやる部分はファウラー風に言えばドメイン部分だけやって、全体の設計実装までは言及してません。
で、結局まともに実装物を作れないって感じになり、多分現場では役に立ってません。
(実際オブジェクト指向分析/設計/実装しているプロジェクトは見てません)
って、言うか、現場が求めてない感じでしたね〜。会社の偉い人が旗振ったのでそれにいやいや従ってたって感じ。

時々オブジェクト指向は銀の弾丸みたいに思っているオッサンも居たけどw

今はもうこの業界を離れて180度違うことをしています。

43 :仕様書無しさん:2007/01/05(金) 19:08:43
どうして

>今はもうこの業界を離れて180度違うことをしています。

という結論に到ったのかが、全く分からないのだが・・・


44 :仕様書無しさん:2007/01/05(金) 21:25:28
>時々オブジェクト指向は銀の弾丸みたいに思っているオッサンも居たけどw

ウチには原理主義者がいた。
組み込みやらせてみた。
クビになった。

45 :仕様書無しさん:2007/01/05(金) 21:46:03
>>44
>クビになった。 

もしかして、それは >>42 の事では?


46 :仕様書無しさん:2007/01/05(金) 21:51:06
このスレの結論としては、
コンサルに踊らされて会社の金を散々つぎ込んだ責任者はクビってことでおk?

47 :仕様書無しさん:2007/01/05(金) 21:59:23
>>46
いいや。

コンサルのサポートの元で社内全体の技術力向上を目指そうとした
一部の優秀な社員の努力を、社内政治の力だけで踏みにじり、
今までのやり方に強固にしがみつき続けるジジイ共は
クビって結論だろ?


48 :仕様書無しさん:2007/01/05(金) 23:15:26
普段からOOPのありがたみは感じているが、OOAやOODはよく知らない。
ただ、パフォーマンスの問題等で設計->実装の段階で実装レベルの設計やり直しが
発生するようなOODなんて無駄だと思う。流行るわけがない。

49 :仕様書無しさん:2007/01/05(金) 23:19:32
>>48
>ただ、パフォーマンスの問題等で設計->実装の段階で実装レベルの設計やり直しが 
>発生するようなOODなんて無駄だと思う。流行るわけがない。 

それはどんな設計でも発生する可能性はあると思うが?。


50 :仕様書無しさん:2007/01/05(金) 23:24:12
>>49
OODでは特にパフォーマンスの問題が発生しやすいと聞いたが?

51 :仕様書無しさん:2007/01/05(金) 23:31:16
>>35
その2日で辞めた人を見習いたい。
しょっぱなで見切りを誤って数ヶ月もつかまると
心身にダメージでかいからなあ。

52 :仕様書無しさん:2007/01/06(土) 00:13:57
>>50
なぜそうなるか、と考えたことがあるかい?
人から聞いたことを鵜呑みにして根拠もなく「流行るわけがない」とはこれ如何に。

53 :仕様書無しさん:2007/01/06(土) 00:21:22
>>52
経験がないのでなんともいえないのだが
OODでのクラス設計をそのままコードにしてうまくいくの?

54 :仕様書無しさん:2007/01/06(土) 00:50:19
設計次第としか言い様が

55 :仕様書無しさん:2007/01/06(土) 01:36:26
OOでパフォーマンス問題が発生するのは、多くの場合I/O部分を正規化し過ぎるためだと思う。
かつて流行りかけたEntityBeanも同様だったが、何事もやり過ぎはよくない。

例えば「社員テーブル」に対応する「社員クラス」というものがあるとする。
主なデータ項目は、部署コード、社員コード、氏名といったものだが、このまま社員クラスに
すると、部署名を引くのに別のクラス(ex.部署クラス)が必要となる。
確かにこれはこれでデータ構造上は理想的なものではあるが、当然ながらパフォーマンスへの
影響も無視できなくなる。
そこでどうするかと言えば、社員クラスに「部署名」も含めるわけだ。内部的にはViewを使って
部署テーブルを参照する。要するにクラスの正規化崩しを行うことになる。

今までこのやり方を通してきたが、パフォーマンス問題には一度も出くわしたことは無い。

56 :真面目なネラー:2007/01/06(土) 02:14:59
世の中Java屋は多いらしいが、シーケンス図とか設計屋から渡されないで
やっているのかな?
もうそのままPGに落とせるくらいまで、クラス図とシーケンス図を設計屋が
作成すれば、よく言われる再利用による高生産性だ、品質の良い拡張性だ、
・・・・・が実現できるはずなのに。
それに、クラス図を描いている内に、インターフェースの抽出も脳裏に
どんどん浮かんでくる。そして、それらをまとめていくと、おお、あの
デザイン・パターンが使えると閃いてくる。
が、が、が、・・・・が、お前は何をやってるんだ?、という空気が
当方の周りには充満してる。OOPはこのまま終焉するような気さえして来るんだけど。
みなさん、どう予想されますか?

57 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/06(土) 02:19:42
メンテナンスしにくいわ
デザパタ使ってプロセス隠蔽したプログラムで
プロセスのレアバグのデバッグやらされてたこっちの身にもなってくれ
使える(可能)と使える(優良)をすりかえてはいけません。

58 :仕様書無しさん:2007/01/06(土) 02:32:14
>>55
クラス設計とDB設計をごっちゃにして話をされてもねぇ

59 :仕様書無しさん:2007/01/06(土) 02:32:50
デザパタ使ってプロセス隠蔽?
どういう意味?

プロセスのレアバグ?
は??まるで意味がわからんwwww


60 :真面目なネラー:2007/01/06(土) 02:36:42
>>57
設計屋さんが、無理やりダザパタを使う様なことしていませんか?
無理やりデザパタをはめ込むと奇怪な可能現象が生じることでしょう。
すなおに使える場合だけに使うと、優良現象が生じると信じてますが。

61 :仕様書無しさん:2007/01/06(土) 02:40:48
>>58
そこをごっちゃに扱うことこそが OOD の思想の中核


62 :仕様書無しさん:2007/01/06(土) 03:21:37
>>61
おしい!ごっちゃに扱うのではなくて、「見かけ上」ごっちゃに扱えてる
ように振舞うものを作っちゃおうぜってのがOODの思想の中核。
実装段階におけるパフォーマンスの問題を議論する中において、クラスとDBを
ごっちゃに語ってしまう勘違い屋さんの話とはまた別の次元の話。

63 :仕様書無しさん:2007/01/06(土) 03:40:55
だいたいインスタンスと参照の区別が付いてないDB設計をしてあると腐るよね?

64 :仕様書無しさん:2007/01/06(土) 04:13:10
>>63
実表とView表のことかい?
まあ、最近のDBMSの内部処理的にはそれほど違いはないんだけどね。

65 :仕様書無しさん:2007/01/06(土) 04:16:01
簡単な理由だよ。歴史に学ぶべきだ。
パラダイムシフトは旧パラダイムを信奉する人間が死滅しないと完了しない。

66 :仕様書無しさん:2007/01/06(土) 04:28:02
OODはパラダイムシフトを起こすほどの力をもっているのか?ってことを
先に考えるべきでは?

67 :65:2007/01/06(土) 04:46:07
>>66
OOがパラダイムシフトとなり得ないのなら当然、流行らない。
OOがパラダイムシフトであるなら前述の理由で、すぐには流行らない。
結局、どちらにしても流行らない(笑)。

OOがパラダイムシフトとなりうるか否かを議論したければ、
別スレを立ててください。

68 :仕様書無しさん:2007/01/06(土) 04:52:07
日本語でおk

69 :仕様書無しさん:2007/01/06(土) 10:17:29
>>58
>>55の例では、クラス設計とDBをごっちゃに扱うのではなく、DBという「実装」を隠蔽しているだけ。
これはO/Rマッピングが生まれた背景なわけだが、そもそもRDB自体がOOとはとても相性が悪いから
ODBが普及するまでは何も変わらないと思う。だがそんな見通しは全く無し。

実際に、DBを使わない組み込み系ではOOはかなり使われている。

70 :真面目なネラー:2007/01/06(土) 14:15:44
>>69
>実際に、DBを使わない組み込み系ではOOはかなり使われている。

OOが使われているというのは、クラス図、シーケンス図の設計をしているということなのですか?
それとも、たんにPGのなかでインターフェースの多様態(C++だと仮想関数など)を使ってるということですか?
クラス図、シーケンス図を作成しているのならば、>>69の書き込みはすばらしい情報なのですが。

71 :仕様書無しさん:2007/01/06(土) 18:37:00
携帯電話を作るプロジェクトでは、完全にOOのやり方だった。
まずドメインを明確にし、そこからクラスを導き出していく。
もちろんシーケンス図やステート図も作った。
クラス図はまず概要レベルから徐々に実装レベルへと落とし込んでいくのだが、結構大変だったなあ。
出荷段階で既知バグは残ってしまったが、プロジェクト自体は最後まで非常に健全だったよ。

72 :仕様書無しさん:2007/01/06(土) 20:14:10
>>71
>まずドメインを明確にし、そこからクラスを導き出していく。 
>もちろんシーケンス図やステート図も作った。 
>クラス図はまず概要レベルから徐々に実装レベルへと落とし込んでいくのだが、結構大変だったなあ。 
>出荷段階で既知バグは残ってしまったが、プロジェクト自体は最後まで非常に健全だったよ。 

どう見てもウォーターフォールです。
本当に(ry


73 :仕様書無しさん:2007/01/06(土) 21:54:18
ウォーターフォールとオブジェクト指向設計は別に矛盾しないのでない?

74 :仕様書無しさん:2007/01/07(日) 00:09:05
ここにもいるのか、勘違いしているやつ。
オブジェクト指向は「技法」、ウォーターフォールはプロジェクト推進の「手法」。
別にオブジェクト指向を非インクリメンタル手法でやってもちーっとも構わないのだよ。
同様の勘違いは実はウチの社にもいて困っている。ちょっと本を囓った知ったかクンだけどな。
>>72みたいなヤツがいる限り、オブジェクト指向が流行ることはないような気がする。頼むから勉強してくれ。

75 :仕様書無しさん:2007/01/07(日) 00:33:52
別に>>72みたいなやり方でもいいじゃん。
ただこれしかないみたいに思ってたらずいぶんアレだけど。

76 :仕様書無しさん:2007/01/07(日) 00:49:32
>>71
常連になっていろいろと書き込んでくれろ!!
OOをきちんとやっているのを俺はまだ見たことがない。
>>71がメチャうらやましい。

77 :仕様書無しさん:2007/01/07(日) 03:39:50
いわゆる業務屋の俺がOOを扱う日は到来するのだろうか。

78 :仕様書無しさん:2007/01/07(日) 11:28:32
>>72
そもそも携帯などの組み込み系ならウォーターフォール以外あり得ない気がするぞ。
インクリメンタルやスパイラルで部分実装なんてされてもなあ・・・

79 :仕様書無しさん:2007/01/07(日) 13:11:47
>>78
なんか気の狂ったような納期が多いしね。
仕様書を渡された瞬間からすでになにもしようがないのが多いね。

80 :仕様書無しさん:2007/01/07(日) 15:24:16
>>78
>携帯などの組み込み系

携帯は組み込みじゃないだろ?


81 :仕様書無しさん:2007/01/07(日) 16:31:25
>>80
組み込みじゃねぇの?

82 :仕様書無しさん:2007/01/07(日) 18:16:50
担当する部分によって異なる。
電話をかける機能は組み込み系。でも電話帳は単なるアプリ。

83 :仕様書無しさん:2007/01/07(日) 18:39:18
携帯の開発にウォーターフォールが適しているかどうかは微妙なところ。
まずは商品スペックありきで始まり、開発中にそれがコロコロ変わるしね。
オレが関わったプロジェクトでは、線表自体はウォーターフォールのそれ。
でないと施主様(メーカー)が納得してくれないだろうな。
だがひとつのフェーズの中では行きつ戻りつするから、スパイラルに近いかも。
もちろん初めから仕様変更があることを見越しているから、なるべく依存関係を
断ち切った設計が基本。だがUIに変更が入ると結構痛かった記憶があるなあ。

84 :仕様書無しさん:2007/01/08(月) 00:22:26
>UIに変更が入ると結構痛かった記憶があるなあ。 

UIの変更が痛い "依存関係の断ち切り方" って・・・

何だそりゃ?
何の依存関係を断ち切ったんだ? 
もしかして担当者間の依存関係とか?


85 :仕様書無しさん:2007/01/08(月) 00:31:32
プログラマ数ヶ月或いは数年やったくらいで
設計している人が多いからじゃない?

オブジェクト指向の有効な使い方を理解せずに、
基本性質だけ理解してオブジェクト指向わかった気に
なっても設計はできない。
デザパタ理解っていっても、使えなきゃ意味ない。

使える部分と使えない部分、デザパタも大したことなかったり、
ベタで作った方がいい部分、他ツールで同系コード大量出力
した方がいい部分、と、設計する側がうまいことわかってないと
「オブジェクト指向」って一言で言ってもどんなのが出来るか
わかったもんじゃない。

そういや、コピペコード大量に書いてるだけのくせに
「オレはできる。お前はできないからそんなこと言ってるんだろ」
とかトンチンカンなことを言ってる同期がいったけな。

設計の何たるかもわからず、根性だけでコピペコードを
大量に出しさえすれば「とりあえず動く」そして「納品もできる」
さらには、「工数がかかって、会社は儲かる(苦笑)」てな
具合にいい事だらけだから、部長はこういう馬鹿を優遇するんだよな。
(工数がやっただけ出る優良企業相手だから、ということもある)

クソが作ったコードと私の作ったコードと、
中身は違って保守性も安定性も抜群に違っていても、
部長からしたら大した違いではないんだよな。

(続く)

86 :仕様書無しさん:2007/01/08(月) 00:32:44
(続き)

まあ、もともと3〜5年くらい下請けで技術磨いてから
上流行程に移行するつもりでいて、まさにそれを実現して
しまったから、こういうアホの環境とは既におさらばしてるんだけど。

下請け生活しながら、本来の目的である「動くものを作ること」を
半ばそっちのけで、「どのように設計するのが本筋か」を
勝手に追求して設計見直しやツール実験なども
勝手にやっていた(そういう環境にあったのは幸い)ので、
ぎゅうぎゅう詰めな生活ではなかった分、時間が持てたよ。

会社が業務AP専門ではなく、組み込み主体で、
業務AP方面だった私は管理する人もいなく、
適当にやらせてもらえたということが多い。(幸運)

いきなり上流行程に来ないで下請けで下積み生活しておいて
よかったと今は思っているよ。
周囲見ていると、下請けの言いなりで言い返せなかったり、
設計のよしあしや工数が妥当か判断できない人も多い。

時代は既に変わっていて、
「オブジェクト指向? あっそ。 だからなに?」
てな具合に当然のものになっているのに、
日本は未だにオブジェクト指向どうこう言ってるのがイタい。

87 :仕様書無しさん:2007/01/08(月) 00:37:31
>>85
>設計の何たるかもわからず

俺もいまだに分からん。
是非語ってくれ(w


88 :85:2007/01/08(月) 03:39:26
>>87
タダで教えるほど安くは無い。出直せ。

89 :仕様書無しさん:2007/01/08(月) 03:46:27
あのさ、既に過去に作ったものと同じようなものでない限り、ある程度実装しないと
詳細設計するの無理だよね?俺が馬鹿すぎるだけ?

90 :85:2007/01/08(月) 03:56:59
>>89
一つ一つの経験は縦のものであっても、
経験が増えてゆけば横の繋がりができ、応用ができるようになるのです。

一言で言ってしまうと、”経験不足”かと。
馬鹿ということはないのでは。 人の能力はさほど変わりませんよ。(例外除く)

わからないうちは、サンプルを実装してみて感触を掴むのはよい方法だと思います。

その程度のスキルのまま”設計”にまわされた人は悲惨です。
設計に根拠がないので、プロジェクトが破綻する可能性が高まります。

91 :仕様書無しさん:2007/01/08(月) 08:47:39
さんざん上司ぶってるくせにこういう都合の良いときだけ
上下関係無視して新入社員に責任が行くのが不思議。

こういうものが表に出るって事は
ベテランのチェックが甘いことも原因の一つなのだから
少しは自覚しろ。

ベテラン力が不足しているのであればベテランの補充をオススメする。

92 :仕様書無しさん:2007/01/08(月) 08:53:23
>>91
オブジェクト指向設計を
チェックできる奴がいないのに
オブジェクト指向で組むな。


93 :仕様書無しさん:2007/01/08(月) 08:54:54
言いたいことはわかるけどこのスレで議題にしてるのは
OOA/OODのことじゃないの?
あなたがいってるのはOOPのレイヤの設計で、
それが流行っていないって主張している奴は流石にいないんじゃないのかな。

94 :仕様書無しさん:2007/01/08(月) 08:54:58
>>92
お前前のプロジェクトでやっただろ!





以下延々と続く・・・

95 :仕様書無しさん:2007/01/08(月) 08:56:25
すみません>>93>>85へのレスです。

96 :仕様書無しさん:2007/01/08(月) 09:15:14
>>91
中途では限界がある。
仮にベテランが居たとしてもチェックマンとして
機能しなければ何もならん。

97 :仕様書無しさん:2007/01/08(月) 09:19:43
上司としてのスキルが無い奴を
上司として配置せざる終えない現実・・・

98 :仕様書無しさん:2007/01/08(月) 10:07:15
>>72
どこをどう読んだウォーターフォールだと言えるんだ?

99 :仕様書無しさん:2007/01/08(月) 11:52:42
>>93
>あなたがいってるのはOOPのレイヤの設計で、
>それが流行っていないって主張している奴は流石にいないんじゃないのかな。

ほんとうにOOPのレイヤの設計は流行しているの?
あなたは、どの地域の方?
やっぱ東京の人?
たぶん大手のSI企業の人なんでしょうね?


100 :仕様書無しさん:2007/01/08(月) 12:08:41
>>99
大手を派遣でまわりまくってるけど、いまだにそんな環境に出くわしたことないなw

101 :仕様書無しさん:2007/01/08(月) 12:37:27
小規模だったら良いけどね。
大規模だと机上の論理だとすぐ判明。

102 :仕様書無しさん:2007/01/08(月) 12:49:09
分かりづらいから流行らない。
流行らせるなら、どんなバカでも直感的に理解できるものでなければダメ。


103 :仕様書無しさん:2007/01/08(月) 12:52:51
>>102
わかりやすいと思うんだけどなんかわざわざ複雑に語りたがる奴がいるんだよw

104 :仕様書無しさん:2007/01/08(月) 13:49:17
>>99
たしかに大手だけど、OOPじゃないコードって逆にどんなのだよ。
Strutsとか使った場合でいうと、Action以降が急に手続き型になる感じか?
O/Rマッパーなんて、モロにドメインモデルを使用する前提なんだから、
少なくともHibernatetが流行っているっていう表現がまかりとおるんであれば
OOPも流行っているって言えるんじゃないだろうか。

105 :仕様書無しさん:2007/01/08(月) 14:05:38
>>104
Hibernatetって何ですか?
O/Rマッパーってオブジェクトとリソース(主にDB?)のマッピング?
う〜ん、最近、OOPをあきらめて情報を仕入れてないのでついていけませんね。
でも、本屋では必ず新刊書のチェックはしてるつもりだけど、HibernatetやO/R
なんていう文字列は見た記憶がありません。
Hibernatetなるものが流行ってるんですか???? 


106 :仕様書無しさん:2007/01/08(月) 14:08:50
Hibernate。つか細けえよ。

107 :仕様書無しさん:2007/01/08(月) 14:10:05
使い慣れない言葉なんて使って説明しようとするからそ(ry

108 :仕様書無しさん:2007/01/08(月) 14:17:28
ん?
OOP流行ってないことにしたい勢力が存在するのか?

109 :仕様書無しさん:2007/01/08(月) 14:19:50
>>108
いや、実際、使ってるのみたことないだけに俺はなんとも・・・

110 :仕様書無しさん:2007/01/08(月) 14:29:26
>>109
何の開発してんの?

111 :仕様書無しさん:2007/01/08(月) 14:33:14
>>110
なんの開発っていうか派遣。
なんでもやるぞ。
メインはC/C++だけど、VBやらjavaもやる。
でも、これまでそもそも設計なんて工程があったことがないw

112 :仕様書無しさん:2007/01/08(月) 14:37:16
プログラミングスタイル(あえてこう言うけど)を普及させる一番良い方法は、
そのスタイルで記述することが一番自然な言語を創って普及させてしまうことだ。

現状、OOPLによる開発がすでに多数派である現実を踏まえて語らないと
話は空転するばかり。

113 :仕様書無しさん:2007/01/08(月) 14:49:06
>>112
それって無理じゃね?
関数一覧クラスを作ることだって可能なんだぞ。
特にjavaとかjavaの作り方にあわせるよりこっちのがやりやすい気がしてる。

114 :仕様書無しさん:2007/01/08(月) 15:16:39
あるDQNソフト会社の営業から
「我が社では、業務経歴書に単なる経歴だけじゃなく、本人の自己アピールも入れて工夫してます」
と、社員たちの経歴書を自慢げに見せられたことがある。(ちなみに俺はフリーね)
それ読んで、うげ〜使えなさそーな社員ばかりだな〜と思ったのだが、
特に気になったのが、入社して間もないプログラムを始めたての新人が
「Javaのプログラムをやっと少し書けるようになりました。今はデザインパターンの勉強を一生懸命やってます」
という、自己アピール文だった。
実戦経験が全くなく、配列やリストの使いどころさえわかってない(基本的な道具の使い方を知らない)
新人君に、デザインパターンなんかいきなり勉強させてどうするんだろう、さすがDQN会社と思った。
(これ、デザインパターンがワーワー騒がれだした頃の話だけど、最近はどうなんだろうね。)

115 :仕様書無しさん:2007/01/08(月) 15:23:13
>>114
俺が派遣でまわった感じではデザパタなんて使われてるところは一件も無かったと言っておく。

116 :仕様書無しさん:2007/01/08(月) 15:24:45
>>115
実装レベルのデザパタなんて、「自分で勝手に使うもの」だといっておく。

117 :仕様書無しさん:2007/01/08(月) 15:30:11
>>116
じゃあ、みたことねぇな。

118 :仕様書無しさん:2007/01/08(月) 15:37:17
既存APIのラッパークラスつくってアダプタパターン?
それとかコレクションまわすときindexじゃなくてIteratorつかってイテレータパターン?

このレベルだとどうよ。

119 :仕様書無しさん:2007/01/08(月) 15:47:35
>>115==117
>じゃあ、みたことねぇな。
「自分で勝手に使っている場面」も見たことがない、つまり使ったことがない、ということか・・・

120 :仕様書無しさん:2007/01/08(月) 15:50:56
デザパタって、初めて本を読んでみたとき、
「なあんだぁ、ふだん自分が何気なくやってる実装法と似たようなのばっかりじゃないか」
と思ってしまった。まあ、幾つかは目新しく感じたけど。
デザパタって、鶴亀算とか植木算みたいなもんだろ。方程式の何たるかを知っていたら鶴亀算なんて
何気なく使っていくようになる。方程式より先に鶴亀算から教えるのは間違っている。
それと同じで日々鍛錬しているプログラマなら自然と身についていくものであり、新人にいきなり
やらせるなんて間違っている。

121 :仕様書無しさん:2007/01/08(月) 15:53:20
>120
> デザパタって、初めて本を読んでみたとき、
> 「なあんだぁ、ふだん自分が何気なくやってる実装法と似たようなのばっかりじゃないか」
> と思ってしまった。

それに名前をつけたものがデザイン(設計)パターンなんだが。GoF本の前のほうをよく読め。
デザインに適合したコーディング手法(集)、これがデザインパターン。

122 :仕様書無しさん:2007/01/08(月) 16:17:10
ある開発に携わる人の全てが、あるレベル以上のオブジェクト指向を
理解していればうまくいく。
けど一人でも変なのが混ざると全てがめちゃくちゃになることもある。

123 :120:2007/01/08(月) 16:43:02
>それに名前をつけたものがデザイン(設計)パターンなんだが。GoF本の前のほうをよく読め。
>デザインに適合したコーディング手法(集)、これがデザインパターン。

そんなもん知っとるし、GoF本だって読んだわい
えらそうにすんな、ボケ!

124 :仕様書無しさん:2007/01/08(月) 16:47:21
>>122
> けど一人でも変なのが混ざると全てがめちゃくちゃになることもある。

その変なのが下っ端PGならまだマシだけど、上司だった場合は・・・

125 :仕様書無しさん:2007/01/08(月) 16:52:15
>122
その変なのが120だと思うのは俺だけ?

126 :仕様書無しさん:2007/01/08(月) 17:06:59
まぁまぁ。理論と実践が両輪でなければならないってのは正しいんだし。

127 :仕様書無しさん:2007/01/08(月) 17:45:40
あまり言われてはいないがデザパタとオブジェクト指向には実はなんの関係もないw

128 :仕様書無しさん:2007/01/08(月) 17:48:51
てか、デザパタって設計手法ってより、実装技術だよね。
なんかオブジェクト指向の設計とは階層が違う気がする。

129 :仕様書無しさん:2007/01/08(月) 17:48:59
>>127
少なくともマとかムでは聞き飽きてますけど。。

130 :仕様書無しさん:2007/01/08(月) 17:51:02
>>128
>>93

131 :仕様書無しさん:2007/01/08(月) 17:52:44
>>130
そういう妙な用語使われると俺がついていけない。
もっとわかりやすくたのむ。
OOXとかいう略はすぐ忘れるので駄目だ。

132 :仕様書無しさん:2007/01/08(月) 17:53:57
>>114からいってスレ違いなんじゃね?

133 :仕様書無しさん:2007/01/08(月) 17:55:27
OOA/OODはかなり一般的な単語と思うが。。
まあ訳すとオブジェクト指向分析/オブジェクト指向設計ってわけだ。

134 :仕様書無しさん:2007/01/08(月) 17:57:18
>>127を厳密に適用するとそうなんだが、そんなに精密な話をしているとも思えないので
何でもありじゃなかろうか。

135 :仕様書無しさん:2007/01/08(月) 18:41:09
なんか「お人よし」な人がこのスレみて勘違いすると気の毒だから一応書くけど、
こんなスレに書いてあることを真に受けちゃダメだよ、マジで。

君と同じぐらいよくわかってない奴が知ったような口利いてるだけだからw

136 :仕様書無しさん:2007/01/08(月) 18:51:08
なんでそんなに逃げ腰なんだよww

137 :仕様書無しさん:2007/01/08(月) 18:56:45
>>135
勘違いするほどの中身があるスレとも思わないんだが。
何を煽っているのか理解に苦しむ。

138 :仕様書無しさん:2007/01/08(月) 18:59:03
まあ、とりあえず。

「オブジェクト指向設計」とは何か?

って所から話をしようぜ。

139 :仕様書無しさん:2007/01/08(月) 19:17:35
オブジェクト指向プログラミングは流行ってるのに
オブジェクト指向設計は流行ってないってことだよね?

140 :仕様書無しさん:2007/01/08(月) 19:23:35
いくら頑張ってもムダ
プロパーの出す設計書がぐだぐだだから・・・orz

141 :仕様書無しさん:2007/01/08(月) 19:24:13
>>139
オブジェクト指向設計をするためには、まずオブジェクト指向プログラミングのスキルが必須。
今はやっとオブジェクト指向プログラミングが定着してきた時代であり、この時期のプログラマ達が
将来オブジェクト指向設計で花を咲かすのでわ?


142 :仕様書無しさん:2007/01/08(月) 20:17:08
歴史はくりかえす。
○○設計をするためには、まず○○プログラミングのスキルが必須。
今はやっと○○プログラミングが定着してきた時代であり、この時期のプログラマ達が
将来○○設計で花を咲かすのでわ?

○○の部分は今は「オブジェクト指向」なのだろうが昔は「構造化」だったなぁ
将来は何になるのやら

143 :仕様書無しさん:2007/01/08(月) 20:29:47
>142
それがパラダイムシフトってこと。ただオブジェクト指向に続くパラダイムはまだ見えてこない。
既存の色んなものは違うんだろうな…。

144 :仕様書無しさん:2007/01/08(月) 20:59:44
>>143
アスペクト指向はとっくに実用段階だろ。

オブジェクト指向に内包されるってツッコミはなしってことで。
それ言ったら構造化設計もそうだし。

145 :仕様書無しさん:2007/01/08(月) 21:02:48
っていうか、構造化プログラミングっていうのはあるけど
構造化設計なんて概念あったっけ?w
俺は無いと思うけど。
こんな言葉遣いをする人っていうのはそもそも構造化の意味がよくわかってないんじゃないの?
構造化プログラミングなんて1時間で理解できるぐらい中身スカスカのものでしかないのにね。

146 :仕様書無しさん:2007/01/08(月) 21:03:29
>>144
> オブジェクト指向に内包されるってツッコミはなしってことで。
> それ言ったら構造化設計もそうだし。

もうごちゃごちゃは要らない。
オブジェクト指向に内包されるでも良いじゃん。

147 :仕様書無しさん:2007/01/08(月) 21:04:37
>>144
アスペクト指向は、パラダイムシフトってわけじゃないだろう

148 :仕様書無しさん:2007/01/08(月) 21:13:12
つか今までこの板で見かけたレスの焼き直しばっかじゃねーか。
そろそろ、なんか発展的な議論はじめてくれや。

149 :仕様書無しさん:2007/01/08(月) 21:14:33
>>142
何それ?
日本語しゃべってよw

150 :仕様書無しさん:2007/01/08(月) 21:15:58
>>145
>構造化設計なんて概念あったっけ?w 
http://www.google.co.jp/search?hl=ja&q=%E6%A7%8B%E9%80%A0%E5%8C%96%E8%A8%AD%E8%A8%88&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

>構造化プログラミングなんて1時間で理解できるぐらい中身スカスカのものでしかないのにね。 
「理解する」と「実践する」の間には天と地の開きがある。

学生は黙っとれ


151 :仕様書無しさん:2007/01/08(月) 21:27:06
そもそも「設計」の意味がわからない

152 :仕様書無しさん:2007/01/08(月) 21:35:54
絶景!

153 :仕様書無しさん:2007/01/08(月) 21:39:12
なんでこんな大祭りなんすか?(マ板級)
4日で150レスたぁ。
ことテクニカルな話題ではみんな新しもの好きなのかw

154 :仕様書無しさん:2007/01/08(月) 21:48:15
あたらしものずき
でなければプログラマになんかなっていない

155 :仕様書無しさん:2007/01/08(月) 21:54:08
新しもの好きって、オブジェクト指向が提唱されたの何年前なんだよ

156 :仕様書無しさん:2007/01/08(月) 22:01:52
プログラマは、職業としてはかなり新しい
OOは修得している人がまだ少ないから新しい(感じがする)

157 :仕様書無しさん:2007/01/08(月) 22:07:41
新し物好きが年をとるにつれて保守的になるってことね。

158 :仕様書無しさん:2007/01/08(月) 22:13:57
>>154
それは嘘だよ。
だってあきらかにVCに性能で負けてるのに
自分の使い慣れたエディターからいつまでたっても離れようとしない奴多いじゃない?

VCの使い方いつまでたっても覚えないからプロジェクト内のソースの文字列検索とかできないじゃん。
インテリセンス機能も使わないからいちいちメンバ変数探してコピーして貼ってって作業遅いんだよ。馬鹿。時代は変わったんだよ。ボケ。
って感じの奴いね?

159 :仕様書無しさん:2007/01/08(月) 22:23:26
それは新しいものを拒絶してるというよりカッコツケみたいなもんじゃないの?

本物のプログラマは〜、じゃないけど出来合いのものをそのまま使うのはかっこ悪い、
みたいな妙な「美学」を持ってる奴っているじゃん。
デキる奴はエディタにこだわるもんだ、みたいな理解不能な奴w
その類だよ。

160 :仕様書無しさん:2007/01/08(月) 22:28:56
>>159
動機はどうでもいい。
そもそもPC使わないでそろばん使い続ける奴だって似たようなもんだ。

161 :仕様書無しさん:2007/01/08(月) 22:38:56
新しい物好きなんかではない、なぜならエディタに固執する奴がいるじゃないか、
っていうのは動機を問題にしていると思うんですが。。

162 :仕様書無しさん:2007/01/08(月) 22:48:20
>>161
それは結果だろ

163 :仕様書無しさん:2007/01/08(月) 22:53:36
動機はともかく楽したいって奴はPGに向いてるよ

164 :仕様書無しさん:2007/01/09(火) 08:22:33
>>158-159
まぁエディタはなぁ・・・こだわる香具師がいても仕方ないかも。
俺はエディタこだわり薄いが、使い慣れたツールってのは大事だ。
こだわりを押し付けられたらたまらん。ということであれば同意。

ということで、
新しいものやより便利なものでも押し付けられたらやりにくい。

設計なんて、自分の世界だけで完結するものじゃないから、
普及がなかなかしないのでは。
OOを理解する奴が増えたら、流行るかもしれないというのに一票。

165 :仕様書無しさん:2007/01/09(火) 21:02:47
OOを理解する奴が増えないから、OOが流行らないのか?
OOが流行らないから、OOを理解する奴が増えないのか?

166 :仕様書無しさん:2007/01/09(火) 21:07:49
流行ってないから上が導入しない。だからOOできる奴が増えない。
よって後者。
センセーショナルで大流行なら導入ありき。2.0みたく。

167 :仕様書無しさん:2007/01/09(火) 21:18:33
その効果が数字に出ないから。


168 :仕様書無しさん:2007/01/09(火) 21:22:35
違うだろ。本当はみんなわかってるくせに。

まあどんな世界でも人の能力っていうのはピンキリではあるんだが、
この業界の特殊性として本来全く適性がない奴がPGやってるってケースがあまりにも多いからだよ。

169 :真面目なネラー:2007/01/09(火) 21:28:31
1です。
書き込みが予想より多いので感謝しています。
しかし、知りたいと思っていた”なぜオブジェクト設計は流行らないか?”は
今のところ判然としないですね。
Java、C++のプログラミングに熟練した人は、オブジェクト設計もできるだろうから、
きっとオブジェクト設計も徐々に流行ると、私は個人的に期待していました。
しかし、中小IT業界に居る私は、Java屋、C++屋はよく見かけますが、
オブジェクト設計屋は見たことがありません。
したがって、私も今のところ、
>>164さんの
>OOを理解する奴が増えたら、流行るかもしれないというのに一票。
と同意見です。

170 :仕様書無しさん:2007/01/09(火) 21:41:09
C++はなぜ流行り定着したのかを考えればヒントが見えると思うよ。( ・ω・)ノ

171 :仕様書無しさん:2007/01/09(火) 21:54:37
>>170
>C++はなぜ流行り定着したのか

海外の偉い奴らがこぞって C++ でライブラリを作ったために、
それらを必要とする奴らは、嫌でも使わなくてはならなくなった。

どんな低レベルの SE 達でも、
さすがに「言語の違い」という概念はは理解できたらしい。


172 :仕様書無しさん:2007/01/09(火) 23:14:13
>>171
C++のライブラリとはSTLのことか?
それとOOとは何の関係も無いと思うが。

173 :仕様書無しさん:2007/01/09(火) 23:22:06
>>127
>あまり言われてはいないがデザパタとオブジェクト指向には実はなんの関係もないw

おいおい、初心者も見てるんだからあまり変なこと書くなよwww
GOFのデザパタはオブジェクト指向が大前提。
逆に言うと分かりやすいと思うのだが、オブジェクト指向を理解していない人がデザパタの
解説を読んでもよく分からない、もしくは何に役立つか理解できない。

174 :仕様書無しさん:2007/01/09(火) 23:29:25
>>173
は?嘘吐くな。
オブジェクト指向を理解していないからそんなこといいだすんだ。
デザパタなんてどうやってもオブジェクト指向と関係ない。

オブジェクト指向の原点はシミュレーション。
実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点。
実装の都合で中間クラスをボコボコ作成するデザパタなんてどうやっても水と油なんだよ。

175 :仕様書無しさん:2007/01/09(火) 23:37:20
OOPがいかに生産性を高め、どれほどバグを少なくするかは、優秀なプログラマほどよく分かっていると思う。
だがオレの経験では、そういう人は設計作業に駆り出されることは少なく、効率の良いプログラマとして活躍
することが多いように思う。
それとは逆に、プログラムを書かせても今イチな人がある年齢に達すると設計屋になることが多く、
そういう人ほどレガシーな知識しか持っていないから、当然OOPなど全く理解できていない。

オブジェクト指向設計にはOOPの知識は不可欠のはずだが、そんな状況では相も変わらず構造化設計
でやる以外に無いのではないか。

176 :仕様書無しさん:2007/01/09(火) 23:37:33
>実装の都合で中間クラスをボコボコ作成するデザパタなんてどうやっても水と油

こんなのはじめて聞いた。
OO原理主義っていうやつ?

177 :仕様書無しさん:2007/01/09(火) 23:39:37
デザパタ登場以後のオブジェクト指向はそれ以前とは違うものだと思う。
ポリモルフィズム活用しまくりのデザインパターンの利点というと、
モジュール間の依存性をうまく切り離せるとか、
実装の切り替えが動的にできるとか…
そういったプログラム設計上の利点だな。
インターフェース継承こそがオブジェクト指向の神髄であって、
実装継承は駄目という風になったのもデザパタ登場の頃からじゃないか?

178 :仕様書無しさん:2007/01/09(火) 23:43:46
>>174>>175 = >>177
だよな?

話の流れが全く見えない。。

179 :仕様書無しさん:2007/01/09(火) 23:44:30
>>174
>オブジェクト指向の原点はシミュレーション

これは勘違いだね。正確には「オブジェクト指向の原点はSimulaというプログラム言語」となる。
Simulaはその名のとおりシミュレーションを行うためのPG言語だが、たまたまそうだっただけで
別に事務処理言語であっても良かったのだよ。

>実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
これには同意。

>実装の都合で中間クラスをボコボコ作成するデザパタ
これはデザパタが中間クラスをボコボコ作るのではない。OOPで書かれたプログラムを
分析した結果導き出されたパターンを整理したに過ぎない。

オブジェクト指向と無関係と言い切るならC言語(C++でなく)で
Singletonパターンを実装してみてくださいなwww

180 :仕様書無しさん:2007/01/09(火) 23:52:28
>>177
>インターフェース継承こそがオブジェクト指向の神髄
確かにこれはデザパタ登場の頃からよく聞くようになったことは事実だが、
デザパタ登場のはるか以前からあるModula2やObjective-Cでも、
インターフェイスは重要な概念だったらしい。
だから分かる人には分かっていたんだろうなあ。

181 :仕様書無しさん:2007/01/09(火) 23:53:15
>>179
待て。デザインパターンの実装をOOPLとバインドする必要はない、
っていうのは本当のこと。
今ググったらC言語でもシングルトンを実装することは出来る模様。

だけど普通に考えてデザパタ一番相性がいいのはOOPLだと思うので
俺はデザパタとOOPLが無関係とはおもわないが。

182 :仕様書無しさん:2007/01/09(火) 23:55:08
>>179
はぁ?全く意味不明。
Singletonなんてどのへんがオブジェクト指向なのよ?
こんなのただの実装技術じゃん。
なにを落としこむとこんなどうしようもない馬鹿なクラスができるの?

>これはデザパタが中間クラスをボコボコ作るのではない。OOPで書かれたプログラムを
>分析した結果導き出されたパターンを整理したに過ぎない。
これやるとオブジェクト指向が覆っちゃうの?
なんで

>実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点

に同意で変なクラスを作ろうとするの?
いらないクラス作ってることに気がつけよ。
こういうわけのわからない無駄に凝ったモン作ろうとする奴がいるから、
実際にあるモデルをそのままプログラムにおとしこめるオブジェクト指向がいいんだろ?
デザパタはオブジェクト指向とは関係ない気持ちの悪い実装技術なんだってw

183 :仕様書無しさん:2007/01/09(火) 23:59:36
>>182
>Singletonなんてどのへんがオブジェクト指向なのよ?
おっしゃるとおりの実装技術だが、オブジェクト指向特有の「インスタンス」を制御するための
とても有用な技術だよ。
もしかしてキミは、インスタンスとクラスの区別がついていないのではないか?
だとすると後半の主張も理解できるな。

184 :仕様書無しさん:2007/01/10(水) 00:02:14
>>182
お前の望むオブジェクト指向を体現する処理系ってのは存在するのか?

185 :仕様書無しさん:2007/01/10(水) 00:05:32
>>183
だから、なんでそんな話設計で出て来るんだよ。

186 :仕様書無しさん:2007/01/10(水) 00:07:05
>>183
なんかお前見てると問題の切り分けができてないから
そんな設計で実装技術なんか出すんだと思うんだけど。

187 :仕様書無しさん:2007/01/10(水) 00:07:09
>>185
オブジェクト指向って別に設計に閉じた話じゃないだろ。

188 :177:2007/01/10(水) 00:09:35
>>178 いや >>175とも別人だよ。
>>173の言うオブジェクト指向と>>174(=>>182かな?)の言う
それとは別物だってことで交通整理できないかな、と思ったのよ。

ちなみにわたしゃOODやOOAは分からん。
でもOOPでいうなら、>>182の言うところの気持ちの悪い実装技術こそが
最近のOOPの最強の武器なんだと思うぞ。

引っかき回してすまんが寝る。

189 :仕様書無しさん:2007/01/10(水) 00:10:42
>>185
>実際にあるモデルをそのままプログラムにおとしこめるオブジェクト指向
というところが分かっているなら、現実に数が限られたモノを表現するのに
Singletonは最適だと思わないかい?
現実にオレはそういう設計を行っているぞ。

どうもキミの主張は、単なる手続きをクラスで表現しただけのように思えるが。

190 :仕様書無しさん:2007/01/10(水) 00:11:39
Singleton are evil.
おれはSingletonをつかうときには後ろめたさを感じるんだけど
どうだろう。Singletonが有用とか言うとまともにOOでプログラム
を書けないと思われそう(インスタンスの管理が下手糞だ、とか)
なので、そういうことは俺は言わないな。

http://www.c2.com/cgi-bin/wiki?SingletonsAreEvil

C言語でSingletonがしたければ、グローバル変数を定義するだけで
終わりじゃないかとオモタよ。

言葉には定義というものがあって、一般名詞としての
デザインパターンには広義には、OO以外のパラダイムの
設計のテンプレも含まれるんだろうけど、俗に言う固有名詞
としてのデザインパターンはオブジェクト指向、狭義では
GoFのものを指す事が多いな。

デザインパターン(=設計のテンプレート)という考え方自体は
OOとは直交しているという見方も十分ありだとは個人的には思う。

つーか、みんなかなりOOに入れ込んでるな。
俺は仕事はOOでなくても全然いいよ。
個人的にはそんなに生産性が高いとは思わないし。
クラスライブラリは便利だけどな。



191 :仕様書無しさん:2007/01/10(水) 00:11:46
>>188
はぁ?なにをいってるの?

オブジェクト指向の利点は

>実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点

なんでしょ?
デザパタなんて使ったら知らない人はわけがわからないじゃない。
上記の利点は完全になくなっちゃうよね?

192 :仕様書無しさん:2007/01/10(水) 00:13:28
>>186
つかお前さっきデザインパターンは実装技術だつってたじゃねーか。

もっといえデザパタをOOPのレイヤに閉じる必要すらないと思うが。

それにアナリシスパターンなんかはどうなるんだよ。
完全にOOA/OODのレイヤがターゲットだと思うが、中間オブジェクトぽこぽこだぞ?

193 :仕様書無しさん:2007/01/10(水) 00:13:31
>>189
だから設計関係ないじゃんw
例えばその必要数が3つだとしてだからどうしたの?
俺はあくまでN個として設計するけど(って個数のあるもんは全部N個とするから関係ないけど)

ホント意味不明だよね。お前。

194 :仕様書無しさん:2007/01/10(水) 00:14:11
>>192
誰もアナリシスパターンの話なんてしてねぇしw

195 :仕様書無しさん:2007/01/10(水) 00:21:30
>>194
基地外か?

>デザパタなんて使ったら知らない人はわけがわからないじゃない。
>上記の利点は完全になくなっちゃうよね?

>実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点

なんだよこれ。恥を知れよ。

196 :仕様書無しさん:2007/01/10(水) 00:23:30
>>190
>おれはSingletonをつかうときには後ろめたさを感じるんだけど
確かにSingletonを乱用した結果、グローバル変数と全く変わらないものになるケースも多くあるから
気持ちは分からんでもないが、要は上手く使えということだよな。
例えば数が限られている資源を払い下げてくれるクラスなんかに使うととてもラク。
つーか世の中のDBPOOLの実装は皆そうなってるし。

197 :仕様書無しさん:2007/01/10(水) 00:24:38
>>191
>デザパタなんて使ったら知らない人はわけがわからないじゃない

デザパタの最大の問題点がこれなわけで。

198 :仕様書無しさん:2007/01/10(水) 00:26:51
>>195
なんだよ。反論してみろw

199 :仕様書無しさん:2007/01/10(水) 00:27:16
>>197
そんなの聞いたことがねえよ。
むしろ一般的な問題についてオレオレデザインを回避するために生まれたと認識しているが。

200 :仕様書無しさん:2007/01/10(水) 00:34:22
>>199
そのオレオレデザインがデザパタだろうがよ。
オブジェクト指向は実際にあるモデルをそのままプログラムに落としこむだけだ。
余計なクラスつくるんじゃねぇ。

201 :仕様書無しさん:2007/01/10(水) 00:36:25
>実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点

プログラムにおとしこむつったって、ドメインモデル以外の部分はどーすんのよ。
それともアーキテクチャの実装にはオブジェクト指向はあまり役立ってないとでも?

ほい、反論したぞ。
あと>>184にもレスよろ。

202 :仕様書無しさん:2007/01/10(水) 00:40:27
>>199
>そんなの聞いたことがねえよ。

不勉強。
GOFの目的は共通用語を作ることにあった。だから知らない人には全くハナシが通じない
であろうことにもGOF本ではちゃんと触れてある。

203 :仕様書無しさん:2007/01/10(水) 00:41:07
>>200
じゃあなんでもいいからお前が良しとする環境で一つ動くアプリ書いてみてくれや。
もちろん「実際にあるモデル」以外つかうんじゃねえぞ。

204 :仕様書無しさん:2007/01/10(水) 00:44:44
>>203
ほら、また、そうやってわかってないからソースコードばっかり気にする。
お前に設計なんて一生無理そうだなw

205 :仕様書無しさん:2007/01/10(水) 00:45:15
>>202
共通用語があろうがなかろうが、どの道実装はしなければいけないわけで。

それともデザパタを使わないオレオレ実装の方が、「実際にあるモデル」だけで
構築された「ハナシが通じやすい」実装が可能とでも?

206 :仕様書無しさん:2007/01/10(水) 00:47:01
>>204
おまえさっきデザパタは実装技術だつったろ。

207 :仕様書無しさん:2007/01/10(水) 00:47:49
>>205
ほら、やっぱりオブジェクト指向を理解してないじゃないか。

実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点

なんでこんな簡単なこともわからないんだ。

208 :仕様書無しさん:2007/01/10(水) 00:51:33
>>205
だから同じ実装するならなるべくパターンに沿ったものにした方が
誰が見ても理解できるし、メンテもし易くなるんじゃないかという考えが
根底にあるのが「デザパタ」なわけだ。

極論するとオレオレ実装禁止、デザパタを適用すべし、でも良かったの
かもしれんけど、GOFさん達もそこまでは言ってなかっただけ。
デザパタの名称だけで会話ができるなんてのは、ひとつのユートピア
に過ぎないのだろうけど、きっとそれを目指していたんだろうなあと。

209 :仕様書無しさん:2007/01/10(水) 00:53:03
>>208
だからw
オブジェクト指向ってのは実際のモデルをそのままクラスにできなきゃ意味ないんだってw
そこにデザパタやらオレオレ実装なんて入る余地ないんだよ。
わっかんねぇかなぁw

210 :仕様書無しさん:2007/01/10(水) 00:55:34
>>209
もうお前だまってろ。つか死ねガキ。

211 :仕様書無しさん:2007/01/10(水) 00:59:30
>>210
キレんなよ。
結局、オブジェクト指向を理解するってことは〜であることとかそういうことじゃなくて、

実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点

この↑本質が理解できることにつきると思うぜ。
いっぺん頭冷やしたらもう一度みてもらいたいぜ。
どんなオブジェクト指向の亜種よりも原点のシミュレーションで使われてたってところを
よく考えることに意味があると思うぜ。

212 :仕様書無しさん:2007/01/10(水) 01:00:06
197みたいのって何シンドロームっていうんだっけ?
俺様の描く「パーフェクトな世界」と違う、と嘆くこの幼稚園児のようなメンタリティw
簡単に言えば期待過剰の裏返しだな

デザパタっていうのはプログラムの構造を文字通りパターン化してラベリングすることによって、
プログラムを書いたり読んだりする際の複雑性をパターン認識によって
「いくらかでも」切り縮めよう、という発想であってもとより銀の弾丸なんかじゃないんだよ。

要はパターンの水準は違えど構造化と同じ発想なんだけど。
構造化っていうのは各人が俺様ルールでコード書くのは止めて
ループや分岐や関数といったパターンにはまるようなコードを書くようにすれば
コードを書く作業も読む作業もパターン認識によってある程度複雑度が減らせるよ、
って発想だったはず。

213 :仕様書無しさん:2007/01/10(水) 01:01:08
>>209が言うのはオブジェクト指向の理想のひとつだろうな。
実際に分析を繰り返していくと、現実のモデル以外にもいろんなクラスが
必要であることに気づくはず。

なんてことを書くと、それは実装だろうとか言うヤツがいそうだが、実装は実装、
あくまで分析の段階だけのハナシ。
分析フェーズで作るクラス図に<<singleton>>が書かれているのは親切だと思う。

214 :仕様書無しさん:2007/01/10(水) 01:01:11
実際のモデルをそのままクラスにできることと(ドメインモデルの抽出)、
それだけでは動くものをつくれないこと(アーキテクチャの必要性)とは全く矛盾せんわけだが。

ついでに言えば、実際のモデルをそのまま「クラス」にできること
はオブジェクト指向の本質ではない。「クラス指向」ってしってるか?

215 :仕様書無しさん:2007/01/10(水) 01:02:46
>>212
頼むからGOF本読んでから出直せよw

216 :仕様書無しさん:2007/01/10(水) 01:05:54
実際のモデル かぁ
現実世界をモデリングするという作業は
とても難しいよね。
もしかしてこれこそOOA?。

デザパタってデザインという言葉が付いているから
OODみたいに思われがちだけど。
OOPに属する言葉だと思うけどなぁ
だとしたらスレチ(ry

217 :仕様書無しさん:2007/01/10(水) 01:07:32
OOAってあれだろ。
ユースケースかいたり、概念レイヤのクラス抽出したりって奴。

218 :仕様書無しさん:2007/01/10(水) 01:08:03
この論争のきっかけ。

「デザパタとオブ指向は無関係」

だからオレはそもそもデザパタはオブ指向が前提だと

219 :仕様書無しさん:2007/01/10(水) 01:09:42
>>218
それ否定してるのはただの「わけしり顔」したい坊ちゃんだけだから
そんな奴は無視していいと思うけどw

220 :仕様書無しさん:2007/01/10(水) 01:10:59
>>218
いや「デザパタとオブ指向は無関係」ってのを聞きかじった奴が暴れてただけ。

221 :仕様書無しさん:2007/01/10(水) 01:12:38
「UMLとオブ指向は無関係」ってのは常識だからな。
きっとそれと間違えて覚えちまったんだろうな。

222 :仕様書無しさん:2007/01/10(水) 01:21:49
ケンカせんと、それぞれの分野で実利を追求したらいいんじゃね?

223 :仕様書無しさん:2007/01/10(水) 01:26:41
確かにGOF本の全てのパターンはOOPLを前提にしている。
だからといってGOFに記述されたパターン以外のパターンも確かに存在しているわけで
それら全てがOOPLを前提としているわけでは無い。
したがってデザパタという言葉の定義の問題だろ。
GOF本に書かれているパターン群のみをデザパタと呼ぶならそれはOOPと不可分だし、
より一般的な「設計の雛型」という意味を持たせるならそれはOOPと無関係と言う事になるでそ

224 :仕様書無しさん:2007/01/10(水) 01:30:52
>>173には「GOFのデザパタはオブジェクト指向が大前提」と書かれている。
それに妙な坊やがからんできたわけだが。もう寝たかな。

225 :仕様書無しさん:2007/01/10(水) 01:36:48
本とか言う時点で坊ちゃん。そんなながれじゃなかったやん。

226 :仕様書無しさん:2007/01/10(水) 01:38:22
つか、そろそろデザパタの話はいいだろ。

227 :仕様書無しさん:2007/01/10(水) 07:10:47
そもそもデザパタ作った奴ってオブジェクト指向わかってないしなw

228 :仕様書無しさん:2007/01/10(水) 07:55:33
結局、このスレに来る奴らは
「オブジェクト指向プログラミング」と
「オブジェクト指向設計」の違いが分からない、という訳ね。

「りんご」と「リンゴ・スター」
「バナナ」と「東京ばなな」
「西瓜」と「Suica」

ぐらいの違いがある筈なのだが・・・


229 :仕様書無しさん:2007/01/10(水) 08:26:15
>>228
また出たよ訳知り顔したがりの坊主がw
そんな訳がないのにな

230 :仕様書無しさん:2007/01/10(水) 12:58:44
流行らない理由の一端が、わかってきた気がする。

231 :仕様書無しさん:2007/01/10(水) 13:15:08
シーア派もスンニ派もイスラム教みたいな話か

232 :仕様書無しさん:2007/01/10(水) 13:26:01
自分のデザパタに酔いしれたせいで、
パフォーマンスが悪くなっちゃった

233 :仕様書無しさん:2007/01/10(水) 20:47:42
>>232
そのデメリットを超えるメリットが存在するならいんじゃね?

234 :仕様書無しさん:2007/01/10(水) 21:00:05
>>231
いや、うちが元祖だ、うちが本家だ、みたいな内輪争いをしてる感じかな。


235 :仕様書無しさん:2007/01/10(水) 21:26:56
>>234
全然的外れじゃん。
知った顔して的外れ恥ずかしい。ぷw
原点は決まってるだけに「どれがいいか」という議論だけに結構建設的だと思うぞ。

236 :仕様書無しさん:2007/01/10(水) 21:42:49
>原点は決まってるだけに「どれがいいか」という議論だけに
どういう意味かわからん

237 :仕様書無しさん:2007/01/10(水) 22:40:15
>>227
君はそのデザパタすら理解できてないね

238 :仕様書無しさん:2007/01/11(木) 00:19:05
Eclipseなんかはガンマが設計しているだけあって、設計が
すごいと聞いたことがある。けど解りづらいらしい。
(俺はJavaの人じゃないから良く知らん。一応、話を聞いた相手は
かなりハイレベルな人だ)

いや、GOFがOO解ってなかったらこの世にどれぐらいOOが
解っている人がいるか疑問だ。それこそ難しすぎるでしょ。

STLの作者(アレックス・ステファノブ)がOO解ってない
(ということは本当はないと思うが)というのなら、アリかもしれんが。
こっちはOO嫌いでJavaなんて糞だと本人が言っているし。STLは
iostream系と例外以外は継承をつかってない。

239 :仕様書無しさん:2007/01/11(木) 09:40:41
「汎用性とか柔軟性とかより、パフォーマンスをあげろ」って
上司がいったから
オブジェクト設計の中に、Cのゴリゴリプログラムを混ぜてんだけど
なんかRイp゚されてる気になる


240 :仕様書無しさん:2007/01/11(木) 18:18:22
>>239
きちんと設計されていれば、そういう「汚い」部分は隔離できる
できないのは設計能力が未熟なせいか、
80/20の法則を知らず全体を高速化しようとする馬鹿

241 :仕様書無しさん:2007/01/11(木) 21:05:07
同僚がGOFのことを「ごふ」と発音するんだが、こけた頬に青白い顔のせいで妙に笑える

242 :仕様書無しさん:2007/01/11(木) 23:53:06
ごふであってる。ごふごふ

243 :仕様書無しさん:2007/01/12(金) 02:00:05
なんとなくスレの流れを読んで・・・
外部設計と内部設計は分けて話しませんか?

244 :仕様書無しさん:2007/01/12(金) 03:01:25
何故流行らないのか?

それは直感的じゃないから。
俺は好きだけども。

例えば次元数の事を考えるとわかりやすい。

次元数は上がると普通はわかりにくさが増える。
それは単純に数が増えたのもあるけど、
それによって直感的な部分が減るのも大きな原因。

という訳で、次に流行るのは直感指向のS言語ですw


なんちゃってw



245 :仕様書無しさん:2007/01/12(金) 23:29:17
このスレを見る限りでは、流行らないのはオブジェクト設計そのものに
問題があるわけではなく、使える者が少なすぎることに原因がありそうだ。
Java、C++が組めればオブジェクト指向を理解していると思っている香具師
が多いのも原因の一つかもしれないが。。。。

246 :仕様書無しさん:2007/01/12(金) 23:55:39
>>245
一面で優れていても習熟が難しかったり、汎用化が出来ない技法は、優れていないってことだよ。
はやらないには理由がばっちり。


247 :仕様書無しさん:2007/01/13(土) 01:15:22
まぁあれだ。基本設計をooで書く必要は全くないが、
ooで詳細設計を立てて書けない奴は駄目だと思う。

248 :仕様書無しさん:2007/01/13(土) 01:18:46
流行がそんなに素晴らしいならWindowsは素晴らしいことだし、
ガングロ、コギャルは素晴らしいみたいだな

素晴らしいものが流行するならLispはもっと評価されてもいいはず

249 :仕様書無しさん:2007/01/13(土) 01:29:06
使いやすいから流行するんだよ。

250 :仕様書無しさん:2007/01/13(土) 01:56:02
>>247
そこまでは言いすぎと思う。

実際、OS系のプログラムはCで書かれているからといって
駄目って事はない。

なんていうか、学歴みたいなもので
優秀≠オブジェクト指向って感じ。



251 :仕様書無しさん:2007/01/13(土) 02:14:32
>>250
言葉足らずだった。失礼。
OOPをするのにっていう条件つきで。

具体的にはOO理解せずにJavaでプログラム書くのはちょっとと。

252 :仕様書無しさん:2007/01/13(土) 02:44:05
>>249
だからVBが流行したんだな。

253 :仕様書無しさん:2007/01/13(土) 03:54:46
>>252
否定はできんな。

254 :仕様書無しさん:2007/01/13(土) 11:17:28


勉強するのが単にめんどくさいからでは?
Cから入った人ばっかでは?

俺は多分Cから入ったらもうやらなかったと思うよ

だって多いしだるいもんもんもん


255 :仕様書無しさん:2007/01/13(土) 12:08:52
OODって無理がないか?

デザインとしてはそれほど不自然ではないけれど、RPCだDBアクセスだの
が挟まっていることをまったく考慮しておらず、むちゃくちゃパフォー
マンスが悪いに決まっているライブラリを設計・実装してしまい、アプリ
実装担当に迷惑を掛けまくるアホを見ることに事欠かないんだけどさ。

設計時点でパフォーマンスとかの低レベル層の考慮が必要な作業にな
ってしまうのに、そのあたりの知識も見識もない人間が設計するのは
良くないんではないかなと。で、そこまで出来る人間はすでに別技法
での開発に熟練してるので、今さらリスクを犯してよくわからん技法
を身につける必要はないと。


256 :仕様書無しさん:2007/01/13(土) 13:11:15
VCから入った人ばっかりとか。

257 :仕様書無しさん:2007/01/13(土) 16:26:17

ここでオブジェクト指向2.0を提案する


258 :仕様書無しさん:2007/01/13(土) 17:19:27
教義と現世でのご利益次第では

259 :仕様書無しさん:2007/01/13(土) 17:39:17
>>255
設計者の無能さと OOD の問題点との切り分けが出来ていないな。

多分 >>255 のソースも、上と同じように
ちゃんと切り分けを行っていない
「スイス・アーミーナイフ」みたいなもの
ばかりなんだろう。


260 :仕様書無しさん:2007/01/13(土) 17:40:37
テレビで、渋谷の女子高生にインタビューして「やっぱー、これからはー、オブジェクト志向?
みたいな?やだちょーかわいくね?」とか言わせるやらせ番組を流せば流行するよ。

261 :仕様書無しさん:2007/01/13(土) 17:42:58
10人中1、2人しかわからないオブジェクト設計は、現場では使えない。
頼むからPG屋さんたちもオブジェクト設計を解読できるまでになってくれ!!


262 :仕様書無しさん:2007/01/13(土) 18:14:58
人集める予算削っておいて、優秀な人が来ない、なんて笑い話だよなぁ。

263 :仕様書無しさん:2007/01/13(土) 18:35:41
>>260
それ面白い!ワロタ!
台本用意して、ファウラー氏と会話させても面白そう。
そんなの見たら、漏れだってムキになって勉強するよ。

264 :仕様書無しさん:2007/01/13(土) 20:47:01
>>262
そうだね。

265 :仕様書無しさん:2007/01/14(日) 06:36:04
>>261

むしろ、SEないし、えらい人がわからないのが問題の場合が多いよ
PGからしてみれば、OODの方が読みやすいので大歓迎だけど。

266 :仕様書無しさん:2007/01/14(日) 07:33:01
>>265
そうだね。

267 :仕様書無しさん:2007/01/14(日) 09:00:30
>>262
OOA, OOD, OOP が出来る人をどうやって見分けるかが問題だな。
現状ではなんちゃってOOが大部分だから選別作業も大変そうだし。
あとOO出来る人の単価は出来ない人の何割増が妥当なんだろうか?

268 :仕様書無しさん:2007/01/14(日) 10:29:24
OODは最後の最後で破談、じゃなくて破綻ってことがまれに起こるから、
大規模開発では怖くて使えない。

269 :仕様書無しさん:2007/01/14(日) 10:35:25
じゃあ破綻しないOOD++じゃないと流行らん、と。

270 :仕様書無しさん:2007/01/14(日) 10:44:22
理想形はOOD#

271 :仕様書無しさん:2007/01/14(日) 11:47:14
>>265
OOP用のキーワードだけ覚えてOODの利点を
全く理解せず自己満足で作り上げたコードほど
見苦しいものはないがな(´・ω・`)
でも無能はSDやっても酷いがな。(´・ω・`)


272 :仕様書無しさん:2007/01/14(日) 12:16:04
>>271

それは、設計が悪いんだよ。設計がきちんと
OODできれいに出来てれば、コーディングレベルでは、
そんなに、酷くなりようが無い。

273 :仕様書無しさん:2007/01/14(日) 12:17:30
「設計が悪い」僕にもそう思って

274 :仕様書無しさん:2007/01/14(日) 16:14:34
>>272
いや、なる。
作ってみたら実用的な速度がでねぇってのは設計じゃでてこないっしょ?
そんときにOOで作ったモンをばらして速度が出る構造にするってのはちょっと手間。
たまにOOで設計をすることばっかりにとらわれて、自分の設計に悪酔いしまくってて手段と目的が逆転してる
アフォなのいるから要注意と言っておく。かなりねちっこい馬鹿が多くて面倒なのも特長w

275 :仕様書無しさん:2007/01/14(日) 16:18:21
>>274
>そんときにOOで作ったモンをばらして速度が出る構造にするってのはちょっと手間。

それ、OOD のせいじゃなくて、ダメ設計のせいですから・・・


276 :仕様書無しさん:2007/01/14(日) 16:25:00
>>274
じゃあ、逆にOOじゃなかったらどうなるのさ?

OOじゃなければ、
「作ってみたら実用的な速度がでねぇ」
なんてことが起こらないのか?

それとも
「ばらして速度が出る構造にする」
ってのは、手間がかからないのか?

それとも
「自分の設計に悪酔いしまくってて手段と目的が逆転してるアフォ」
が出てこないのか?


277 :仕様書無しさん:2007/01/14(日) 16:34:43
>>274

クラスの粒度が細かすぎるとか、逆に荒すぎて、
実質、コーディングしながら設計することに
なってるとか、ほとんどの場合、設計段階の問題
っていうか、自分でも「設計に悪酔いしまくってて」
って、設計って書いてるじゃん。


278 :仕様書無しさん:2007/01/14(日) 17:18:11
>>275-277
別にOO特有のことをあげる必要もないと思うんだが。
処理速度の考慮漏れなんてそれこそ>>271のような問題で起こることじゃん。
俺の発言は>>272のレスを否定するだけの意味しかもたん。

>OODできれいに出来てれば、コーディングレベルでは、 そんなに、酷くなりようが無い。
これはtrueかfalseかで言ったらfalseだよね?

ってだけ。

279 :仕様書無しさん:2007/01/14(日) 17:23:13
ああ、かなり説明が飛んだな。
つまり組んでみて処理速度の考慮漏れがわかるのって結果論だよね?
問題があることがわかって、そこからそもそもどの時点が悪いの?ってなって
処理速度を考慮してない設計がまずいとかなるのっておかしくない?
それでOODだから・・・ってのは業務やるうえであまりにも現実味がないと思うんだけど。

280 :仕様書無しさん:2007/01/14(日) 17:53:34
A「振り子打法はすばらしい打法なんだよ」
B「でも草野球チームが振り子打法を取り入れてもプロには勝てないよ」
A「それは選手がヘボイからだよ。イチローが振り子打法すればメジャーでも通用する」
B「・・・・・・」

281 :仕様書無しさん:2007/01/14(日) 18:05:26
>>280
それで振り子打法がいい方法だって主張してるならかなり脳みその損傷が激しいと思う。

282 :仕様書無しさん:2007/01/14(日) 18:11:14
>>280
どうすれば振り子打法がいい方法であることを証明できるんだろうな?
結構、この例に似てるのかもわからんな。
イチローが有名になったことで振り子打法は知られるようになったけどそれがいい方法かどうかはわからないままだよな。
あくまでもそれでも可能ってだけの話で。
本来の振り方に変えたらもっと打率はあがるかもしれないし、
あまり知られてはいないがイチロー自身は足が速くてアウトになるはずの内野安打をヒットに変えることができるだけで
振り子自身はあまり効果が無いってデータみたことあるしな。

283 :仕様書無しさん:2007/01/14(日) 18:22:31
>>281
キミの読解力のほうが心配だ。

Bの最後の「・・・・・・」は「じゃあ、打法がすばらしいのじゃなくて、選手が
すばらしいってだけじゃん」っていう心の中のツッコミだろ。

284 :仕様書無しさん:2007/01/14(日) 18:28:12
>>283
じゃ、やっぱこの例でいうと
オブジェクト設計=振り子打法
であって
イチローと振り子打法の関係のように
設計ができることとオブジェクト設計ができることは結びつかないってことか。
まあ、そうだな。

285 :仕様書無しさん:2007/01/14(日) 18:34:39
デキる人がオブジェクト設計をやるとさもオブジェクト設計がすごそうに見えると。
要は。
まあ、全否定できないけど。

286 :仕様書無しさん:2007/01/14(日) 18:36:06
逆にいえば、コードが悪いのはPGのせいで
OODだからといって、コードが悪くなることも、
ないって結論になるが良いよね?

287 :仕様書無しさん:2007/01/14(日) 18:54:51
そういう結論に至ったレスを教えてほしいです。

288 :仕様書無しさん:2007/01/14(日) 19:30:54
なんとなくスレタイの理由がわかってきたな。

Q:オブジェクト指向設計は何故流行らないの?
A:オブジェクト指向設計が従来(もしくはその現場で前から使用している)の設計手法よりすぐれた方法であることを説明できないから

だな。

289 :仕様書無しさん:2007/01/14(日) 20:04:29
A:実際2倍も3倍も優れていないから。(多少は優れているが)

です。

290 :仕様書無しさん:2007/01/14(日) 20:07:21
つまり、従来型設計が悪い、オブジェクト指向が良いからではない。
どちらにしても、馬鹿の設計が駄目なだけ。

291 :仕様書無しさん:2007/01/14(日) 20:26:42
まずオブジェクト指向設計と従来設計の成果物を定義して
その相違を詳らかにしないと全く建設的な議論がすすまないと思われる。

292 :仕様書無しさん:2007/01/14(日) 20:35:07
いや、>>288だけど、>>289の方が正しい気がする。
大して効果が見込めないにもかかわらず>>291みたいなことを説明してまでやる意味がない。

従来のやり方だってメリットデメリットもそれぞれあるだろうし、
従来のやり方なら問題にならなかった部分だったのに新しいやり方に切り替えたがために
出てしまう問題のが余計ややこしい話しになる気がする。

もちろん、従来のやり方の問題であるなら誰かしら経験があるし、
新しいやり方ってのは新しい不具合を呼び込む可能性もある。

やっぱり最大の理由は>>289の「効果が薄い」ってのが一番の理由のような希ガス。
要はリスクとリターンを考えたときに手を出すべきじゃないってことだな。
単純に古いやり方にしがみついてるのとはちょっと違う。PCとそろばんみたいな明らかに効果がわかるもんならいいんだけどな。

293 :仕様書無しさん:2007/01/14(日) 20:39:45
銀の男根は無いって誰かが言ってただろ?


294 :仕様書無しさん:2007/01/14(日) 21:04:50
スレ最初から読んだがoo ooっ五月蝿いね

295 :仕様書無しさん:2007/01/14(日) 21:15:48
>>294
なんでこのスレきたの?
なんでこのスレきたの?

296 :仕様書無しさん:2007/01/14(日) 22:47:07
大体、OOの効果が出るのは保守や機能転用の時なんだから。
派遣やら外注がとりあえず言われた仕様を満たしていれば
後は知らない!直すなら金よこせ!
みたいなプログラムを量産しているうちは無理だろ。


297 :仕様書無しさん:2007/01/14(日) 23:05:13
>>296
それはおかしい。
別にきちんとした設計をしてればOOじゃなくても機能追加・差し替えは可能。


298 :仕様書無しさん:2007/01/14(日) 23:09:55
そりゃ可能は可能だろうよ。
だから
従来<OO
って話だろ。問題はその差が_か`かってことだが。

299 :仕様書無しさん:2007/01/14(日) 23:14:13
>>298
だから、別にその不等号からしておかしいわけで。
別にIOOを全否定しないが、使い手次第でどうとでもなる。

従来手法できちんとできる人ならOOも出来るし、出来ない奴は何を使っても糞を作る魔術師。

300 :仕様書無しさん:2007/01/14(日) 23:26:46
http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#id_272_
4−2、4−3が参考になるかな。

301 :仕様書無しさん:2007/01/14(日) 23:33:04
>>299
> 従来手法できちんとできる人ならOOも出来るし、出来ない奴は何を使っても糞を作る魔術師。

たしかにその通りなんだが、それで全てを結論付けてしまうと
そもそもソフトウェア工学なんて要らなくなるわけで
世の中COBOLが1つあれば十分ってことになってしまう。


302 :仕様書無しさん:2007/01/14(日) 23:38:27
>>301
それは違う論理。
貴方の考えの結論は冷戦崩壊で出ているわけだが。
社会主義的な単一言語、技術での競争否定は腐敗の始まり。

まずね、ソフト工学とかいってるけど、実際のプログラマ名乗る人の半分以上は、そのソフト工学っていうものを知らない。
自分たちのやってることが工学、生産という認識が無い。

303 :仕様書無しさん:2007/01/14(日) 23:45:31
>実際のプログラマ名乗る人の半分以上は、―
3分の1居れば上等だとおもうよ。
てか車の仕組み知らなくても運転できるとかってのと一緒だお。

304 :仕様書無しさん:2007/01/14(日) 23:47:15
それもちとちがう。
生産工学、看板方式の理論を知らなくても現場が動くのと同じってこと。

305 :仕様書無しさん:2007/01/14(日) 23:52:46
>>302
すべての質は個人の技量みたいな書き方をしたからそう言ったの。
それを言い出したらOOとか議論する意味がないでしょ。

もし意味がないって本気で思ってるなら、あなたはこのスレに居る必要はないよ。



306 :仕様書無しさん:2007/01/14(日) 23:58:22
車の仕組み知らなくても皆、燃費のいい車、馬力のある車に乗り換える。
皆、新しい車に乗り換える。
なら判るかな?車は伊達で作られてんじゃないんだよ。そして乗り換えられる理由がある。
(早いから、安いから、流行ってるから)

307 :仕様書無しさん:2007/01/15(月) 00:03:24
>>306
その例とOOが流行らない理由の結びつけは?
流行らないには理由があるってなって、結局やっぱり優れていないって結論になるんじゃないの?

三菱とかまつだの車みたいなもんでしょ、OOって。

308 :仕様書無しさん:2007/01/15(月) 00:05:29
少なくともこのスレでは、オブジェクト指向設計っていうものが
共通概念として明確に定義されてるとは思わないんだけどなあ。

それなのにオブジェクト指向設計が従来設計と比べて
どうだこうだって、何なんだろ。

309 :仕様書無しさん:2007/01/15(月) 00:13:03
いつの間にかOOは流行ってないって話になってる?

310 :仕様書無しさん:2007/01/15(月) 00:15:35
なんか沸いてるな

311 :仕様書無しさん:2007/01/15(月) 00:29:30
>>309
だってスレタイが流行ってないのが前提だもの。

312 :仕様書無しさん:2007/01/15(月) 00:29:52
決定権のある奴に理解できんからな。
オブジェクトコボルでも作って教えないとダメだろ。

313 :仕様書無しさん:2007/01/15(月) 00:33:15
>>310
メガネか?

314 :仕様書無しさん:2007/01/15(月) 00:43:04
設計フェーズの良し悪しを検証可能なのってPGしかいないんだから
少なくともSEとPGが分業制のところじゃ流行りようがないよな。

315 :仕様書無しさん:2007/01/15(月) 00:45:00
>>311
オブジェクト「設計」って書いてあるぞ。

316 :仕様書無しさん:2007/01/15(月) 00:49:00
外部設計検証 SE(顧客補助)
内部設計検証 PG(SE補助)

317 :仕様書無しさん:2007/01/15(月) 01:03:06
ああ、設計検証は指示者でなければ駄目か。

外部設計検証 顧客
内部設計検証 SE、顧客

318 :仕様書無しさん:2007/01/15(月) 01:05:02
>>316じゃ自己満になってしまうわな

319 :仕様書無しさん:2007/01/15(月) 01:10:25
実装後の確認(設計書どおりに実装出来ているかの確認)が>>316

320 :仕様書無しさん:2007/01/15(月) 01:13:49
オブジェクト設計ってそもそも何を言ってるんだ?
今あるオブジェクト指向ってEiffel系のクラス指向とSmalltalk系のメッセージ指向がごっちゃになってるあやふやな概念じゃん。
そんなわけわからん概念の上にある設計技法なんざ信頼できるわけがない。

321 :仕様書無しさん:2007/01/15(月) 01:17:26
>>320
信頼に足る設計技法なんてあるのかね。

322 :仕様書無しさん:2007/01/15(月) 01:32:18
オブジェクト設計以外の設計なんてあるの?
オブジェクト設計とかわざわざ言うのは年配の方ですか?

323 :仕様書無しさん:2007/01/15(月) 01:50:18
素朴な疑問。「設計」って結局何でしょ?

324 :仕様書無しさん:2007/01/15(月) 02:08:54
ものすごく単純な話さ、UMLを書けるSEが少ない。
フローチャートと画面遷移図がごっちゃになった設計書しかみんな書かないだろ

325 :仕様書無しさん:2007/01/15(月) 02:27:23
俺、UMLあんまり好きじゃないな。特にUML2.0。
記法としてUMLがいいか悪いかは微妙。

つーか、UMLで書けば問題解決するもんでもないと思うな。


326 :仕様書無しさん:2007/01/15(月) 03:48:43
あんまり物を考えない非技術系管理者は、自分じゃ何も判断できない業界紙依存症だから、
すぐその煽動に踊らされ昨日まで培ってきたやり方を忘れる。
そして真に実力のある古参技術者達は技術が古いと能力を過少評価され、
口先だけの新しい奴らに現役を取って代わられる。
そういった意味ではIT業界は2007年問題みたいなことが2、3のサイクルで起きているとも言えるね。

327 :仕様書無しさん:2007/01/15(月) 04:02:04
実装系のスレもあるのかな?

上の方でCでシングルトン実装って出てたけど普通に
staticにワーク作って関数だけ参照できるようにすれば
それで完成と思い。

328 :仕様書無しさん:2007/01/15(月) 06:17:51
流行らない理由。
UMLがまだ枯れてないってのもあるかな。
出た頃に比べれば普及しているようだが。

329 :仕様書無しさん:2007/01/15(月) 07:04:19
ぶっちゃけUMLがスレタイに影響を与える要素だと本気で思ってるとしたら脳みその損傷が激しいと思う。

330 :仕様書無しさん:2007/01/15(月) 08:22:36
>>329
もちつけ。スレタイへの影響って何さ?ww

331 :仕様書無しさん:2007/01/15(月) 08:42:16
今時、フローチャートは、まず書かないし
クラス図、シーケンス図は、ほぼ必ず書くから、
もし仮りに、UMLだけの問題なら、OODは、流行ってるといって
も良いような気がする。

332 :仕様書無しさん:2007/01/15(月) 08:45:35
>>331
いいなぁ。俺んとこはクラス図もシーケンス図もなく、
もちろんフローチャートだぞ。

こういう職場環境は滅ぶべきかな?

333 :仕様書無しさん:2007/01/15(月) 08:57:58
>>332

うーん、分野によるのかな?
でもシーケンスは、ともかくクラス図は、
オブジェクト指向言語なら必須の様な気がするんだけど、
あれ無いとPGが勘で勝手にクラス分けするのかなぁ。
言語自体がCとかアセンブラとか非オブジェクト指向言語
なら、それは、それで良い選択で昔通りの設計が、よいと
思うけど

334 :仕様書無しさん:2007/01/15(月) 09:51:48
UMLできますってのは、日本語できます、英語喋れますってのと同じこと。
それをもって何を喋るかが大事なのに、それを理解できない人が多いこと。
UML記法なんぞ簡単。問題は何を書くかを考える頭。

335 :332:2007/01/15(月) 10:00:54
>>333
今やってる分野は業務系中小請負。
仕様書を使うようになっただけマシになったんだぞww 笑ってくれ。
普及どころか、クラス図って何って状態だ。

自嘲はこれくらいにさせてもらって、

普及度が分野によるには違いないかも。
使用言語による選択より、設計(書)というのは、例えば客とSE・SEとPGが
意思疎通を図る言語のようなものだから、普及しているものが使われるという
側面のが大きいような気がする。

> あれ無いとPGが勘で勝手にクラス分けするのかなぁ。

はっきりいってそうなる。
しかし、システム化要件自体がフローチャート的なもの(バッチ処理など)
なので、問題にはなりにくい。

336 :仕様書無しさん:2007/01/15(月) 14:12:05
業務フローを書くときに、アクティビティ図とかみんな書かんのか。
それともみんなフローチャートは書かないけど、アクティビティ図は
書く、とかそういう主張なのか。

正直、ソフトウェア開発やっててフローチャートが不要とか、ありえない。
みんな仕様書はUML以外の図は書かないとか、そういう主義なのか。

オブジェクト指向じゃないと駄目、とかUMLじゃないと駄目、とか
俺からしてみればオイオイなんだけど。


337 :仕様書無しさん:2007/01/15(月) 14:17:48
伝わってなんぼでしょ?
まあ、記法が標準で入るならそれにこしたことはないが。
それで表現できないなら、別にそこに縛られることじゃないし。

338 :仕様書無しさん:2007/01/15(月) 15:15:32
>>336
フローチャートで書く位なら、UMLで書いた方がはるかに分かりやすいって事だろ?
つーか今時、OOPなんて空気みたいな概念じゃないの?
(ソフトウエア開発上あって当然)

339 :336:2007/01/15(月) 17:18:35
> フローチャートで書く位なら、UMLで書いた方がはるかに分かりやすいって事だろ?
???そうなのか???
クイックソートのアルゴリズムはフローチャートで書くより、
(アクティビティ図を除く)UMLで書いた方がわかりやすくなるのか?
その他にも仕様書を書く時点でフローが重要なものとかあるでしょ。
最近はワークフローエンジンとか流行っているけど、これも
基本はフロー(厳密にはBPMLとかつかうんだろうけど)だし。
フローチャートを完全にUML置きかえれるとは思えないんだけど。

もしかしてオブジェクト指向開発ではクイックソートのような
アルゴリズムは絶対につかわない!ということだったりして。

あと、前提条件として念を押しとくけど、フローチャートとアクティビティ図
は本質的には同一だよ。フローチャートをアクティビティ図に置き換えても
はるかにわかりやすくなることは絶対無い。

UMLでかけば分かりやすくなる、というのは思い込みだと思うな〜。

> つーか今時、OOPなんて空気みたいな概念じゃないの?
この発言の意図がわからない。何がいいたかったのか。

思うに本当にOOPが空気みたいな概念であれば、「UML>フローチャート」
という思い込みにはならないはず。無条件でUMLが優れていると
思ってしまうのは、それがあなたにとって特別な存在だから。


340 :336:2007/01/15(月) 17:35:11
あと、UMLは昔からある記法を持ってきて標準化している部分が
たくさんあるよね。

クラス図は確かに現状のクラス志向のオブジェクト指向に
あった表記法だと思うけど、これも元はといえばER図なんだよね。

個人的にUMLで一番オブジェクト指向らしい図といえば、
オブジェクト図とかコラボレーション図だと思うんだけど
どうだろう。

341 :仕様書無しさん:2007/01/15(月) 17:51:15
だから、ミクロな話はどうでもいいよ。
ここはマクロな話だろ?


342 :仕様書無しさん:2007/01/15(月) 18:17:16
やっぱ原理主義者って本当にいるんだね。

343 :仕様書無しさん:2007/01/15(月) 19:32:11
シーケンス図は正直分かりやすいと思った。
あれの活性化ってようはスコープの中ってことだよな。

344 :仕様書無しさん:2007/01/15(月) 19:55:08
クラス図、インターフェースもきっちり抽出したクラス図が設計できる人は
大手SIにしかいない!!
したがって、世間では流行らない。
きっちりしたクラス図が設計できる者は、このスレにいるのか? あっ!!

345 :仕様書無しさん:2007/01/15(月) 20:03:00
>>344
具体名挙げて。
俺、派遣で大手6社まわったけどそういう開発してるところにいったことない。

346 :仕様書無しさん:2007/01/15(月) 20:36:59
クラス図シーケンス図で設計やってるけど、正直酷いもんだよ。
あれを設計書でございますって言って渡されてごらんよ。最悪だよマジで。
全体が何をしたいのかを読みとるのがまず大変。
やっと全体がわかって細かいとこ見れるようになると、
一つのクラスが複数の責務を持ってるわ、クラス名称はいいかげんで意味不明だわ、
メソッドは何がしたいのか読み取れないわでわけわからん。
UMLで書いたって酷い設計は酷い設計なんだよね。


347 :仕様書無しさん:2007/01/15(月) 21:17:16
具象でなく抽象の概念のまま操作できることがオブジェクトの利点だと思うんだが
抽象概念の最小単位がインターフェイスであり、その単位で扱うと自然と疎結合になると

パフォーマンスとか言ってる奴は最小の単位を間違えてるんだろ
たとえ問題が出たところで大抵は一部の修正にとどまるやん

全ては抽象概念に落とし込むところが全てだと
Genericsとかとも相性がいいしな

348 :仕様書無しさん:2007/01/15(月) 21:20:30
C言語から移ったばかりだとC++は疎結合なグローバル変数を持ったプログラム程度にしか見えない。

349 :仕様書無しさん:2007/01/15(月) 21:23:16
フローチャートの必要性が見出せるような小規模なプロジェクトをしてる
エンジニアばかりじゃないって事だな


350 :336:2007/01/15(月) 21:38:54
大規模だとフローチャートがいらないのかw
業務フローの分析とかワークフローとかは小規模向けの
開発手法なのか。

351 :仕様書無しさん:2007/01/15(月) 21:42:00
>>346
それはあるね。
仕様書のどの部分を反映させた結果そういう図になったのかわからないと辛いね。
わかってもそれなりに辛いけど。
あの図だけホイって渡されて「後は仕様書と合わせてみればわかるから」って
「わかるわけねーじゃんw」っての多いしな。

しかも、担当者はそこで何故か(何故かなんて愚問だなw)作業を投げたがる。
聞きに言っても。
「ああ、設計書書いた人もう別のプロジェクト移っちゃったんですよw」
とか酷すぎるにもほどがある。
「設計はもう終わったからw」
ってどの口がこんな嘘っぱちをほざくのか・・・閻魔様に舌引っこ抜いてもらわな治らんのだろうなw

って状況が多いなw

352 :仕様書無しさん:2007/01/15(月) 21:46:41
>>350
フローチャートってあんまり役にたたんような希ガス。
できるならプログラムに直接ブレーク置いて実際に処理おっかけてみるとか
ソースをじっくりみたほうがなんぼかいいと思うんだけど。
てか、ソースとフローチャートって何が違うのかわからん。
ソースあればフローチャートいらないだろ?

353 :336:2007/01/15(月) 21:51:26
だからフローチャートは必ずしもアルゴリズムを書くだけの
ものじゃないんだって。設計の粒度によって役割が違うでしょ?

業務プロセスレベルの設計とかにもつかうんだって。

しつこいけど、フローチャート=アクティビティ図という前提で
話をしているので。フローチャートの使い道でイメージがわかなければ、
アクティビティ図の使い道に置き換えてもいい。手元にある
UMLや開発プロセスについてかかれてている本があったら開いてみて。



354 :仕様書無しさん:2007/01/15(月) 21:53:38
メインのプログラムはインターフェースを使ってプログラミングする。
ゴリゴリプログラミングするのは、そのインターフェースを実装するクラスのみ。
だから、拡張性がよい。
それにメインのプログラムは、みんなが共通に使うからバグがどんどん見つかり
品質がよくなる。
その代わり、メインのプログラムはきっちりと設計しないと、使いものにならない。
まずは、このオブジェクト設計の基本中の基本を理解している者以外はここに出ないことだ。
するとじきにスレ落ちするでしょう。

355 :仕様書無しさん:2007/01/15(月) 21:53:50
>>350
論点をずらさないでくれー
アナタの言うフローチャートとは、>>339で言ってたものでしょうが。
>>クイックソートのアルゴリズムはフローチャートで書くより
個々のメソッドの流れなど、いちいち設計でやる物じゃないって事だよ。

356 :336:2007/01/15(月) 22:01:02
> 論点をずらさないでくれー
いや、最初から俺はフローチャート=アクティビティ図で
業務プロセスも含めて発言しているよ。350ではその例の
ひとつとしてクイックソートをあげているだけ。

とりあえずコテハン(336)でスレを検索してくれ。

↓336での発言
> 業務フローを書くときに、アクティビティ図とかみんな書かんのか。
> それともみんなフローチャートは書かないけど、アクティビティ図は
> 書く、とかそういう主張なのか。
意味が解らなかったかもしれないけど、業務フローでアクティビティ図
を書くのはイコール、フローチャートを書いているようなものでしょ?
という意図だ。

357 :336:2007/01/15(月) 22:04:42
訂正
>350ではその例のひとつとしてクイックソートをあげているだけ。

>350ではフローチャートが必要な例のひとつとしてクイックソートを
>あげているだけ。


358 :仕様書無しさん:2007/01/15(月) 22:06:40
ここら辺で >>336 が
フローチャートが役に立つ
実例を挙げてくれなければ、
結局は水掛け論に終わってしまうよ。

何か「ネタ」を出してくれよ。


359 :336:2007/01/15(月) 22:31:35
まじで業務分析にアクティビティ図をつかうことを知らない
やつがこんなにいるのか...(´Д`;

いや、悪いけどマジで理解不足だから勉強してくれ。
こんなんじゃ、まともなオブジェクト指向設計とかできないだろ...。

例を挙げれば先にあげたBPML。
http://www.atmarkit.co.jp/aig/04biz/bpmn.html
http://www.atmarkit.co.jp/farc/rensai/bpmn04/bpmn04.html
http://www.techscore.com/tech/Seasar/Buri/1.html
> ビジネスプロセスを示すグラフ表現(フローチャート)に関する
> 業界標準の表記法。
オブジェクト指向全盛の今になってビジネスモデリング用の
フローチャートの標準が策定されるというのは、フローチャートが
今になっても必要だということじゃないのか?
だいたいBPMLができたモチベーションに、UMLのアクティビティ図でも
「不足」だからでてきたんだよ。

多分、これだけみんなオブジェクト指向設計について語ってる
ぐらいだから持っているだろうけど、「ラショナル統一プロセス入門 第3版
(ISBN-13:978-4756145543)」のP141からの「ビジネスモデリング作業分野」
とか読んでみて。ビジネスモデリングにアクティビティ図をつかっているだろ。

その他にも、ユースケース記述のフローは自然言語なので
文章では流れがわかりにくい場合は、補助的にフローを
アクティビティ図で書いたり。


360 :仕様書無しさん:2007/01/15(月) 22:42:08
>>359
議論の途中でかまわず突っ込むけど。
もう見た感じ役にたたねぇ臭いがプンプンすんだけど?
だってこんな楽なフローで終わるプログラムが業務でねぇもん。
それにこんな楽なフローで終わるっていうならこんな図書く意味無いと思うんだけど?

361 :336:2007/01/15(月) 22:50:59
心が折れそうだ。

>360
例だから簡単なのは当たり前だろ。
もっと複雑な例はWebでみつからない。
お前が複雑な例をつくってあげてみろというのは勘弁しれくれ。

じゃあ、君は流れを整理するのにフローチャート以外に何をつかうんだ。
散文形式もしくは箇条書きでだらだらと文章で書いて終わりか。
(それともお得意のUML?)
確かにそれも必要だが、それだけの文書と、フローチャートが
添えられている文書どっちがいい?



362 :仕様書無しさん:2007/01/15(月) 22:51:17
>>359
>フローチャートの標準が策定されるというのは、フローチャートが 
>今になっても必要だということじゃないのか? 

その論理が正しいのなら・・・

http://www.nikkansports.com/general/f-gn-tp0-20061222-133735.html

インターネット全盛の今になって新しい記念切手が発行されるというのは、
記念切手が今になっても必要だということじゃないのか? 


363 :仕様書無しさん:2007/01/15(月) 22:53:25
経験と勘だけでいうけどこういう処理を図にしたもんって現実味が無いよ。
模造紙5まい使っても書ききれ無い場合のが多いんじゃない?
あんまり大雑把に書くと役に立たんし、詳細に書き過ぎると資料として役に立たない。
全体を網羅できない上に概要を伝えるにも主旨が定められないしはっきりいって役に立たないと思う>処理図(フローでもアクティなんとかでもいいけど)

364 :336:2007/01/15(月) 22:54:26
これだけこっちが例を挙げているんだから、そっちも
反論に言葉尻を押さえるだけじゃなくて対案を提示してくれ。

「いや、それならこういうUMLをつかった、もっといい方法がある」
という意見なんでしょ。



365 :仕様書無しさん:2007/01/15(月) 22:55:06
業務分析なんて上流に携わらないからよくわからん。
役に立つってんなら役に立つんだろう。
でもオブジェクト指向設計の場合、
動的な処理の記述はクラスを発見した後でなければ考えられないよ。



366 :336:2007/01/15(月) 22:57:27
> あんまり大雑把に書くと役に立たんし、詳細に書き過ぎると資料として役に立たない。
それはクラス図でもDFDでも一緒だな。DFDなんかは最初からレイヤわけするもんだしな。
最初は情報のルートとして大雑把な情報は必要だし、細かいところではそれに応じた粒度の情報が必要だ。

BPMLに関していえば、ワークフローエンジンというのがあって、そのまま
シームレスに実装につかえるのが特徴だ。

367 :仕様書無しさん:2007/01/15(月) 22:57:38
>>361
>じゃあ、君は流れを整理するのにフローチャート以外に何をつかうんだ。
正直にいうと書いたことない。
ていうか書ききれる規模のもんにあたったことが無い。
これはいつも資料にならずに作業担当者の頭の中にある部分だね。

俺が経験したどのプロジェクトでもそうだったよ。
松下でも富士通でも日立でも沖でもNTTでもどこもそう。
これを資料できたところは一つもないね。

368 :仕様書無しさん:2007/01/15(月) 22:58:01
>>364
「流れ」を整理しなければ分からないような業務は、
先にその「構造」を整理したほうがずっと効果的だ、
というのが大方の意見だと思う。


369 :336:2007/01/15(月) 23:02:35
> 「流れ」を整理しなければ分からないような業務は、
> 先にその「構造」を整理したほうがずっと効果的だ、
> というのが大方の意見だと思う。
これは個人の思想の問題だろう。
構造が大事だという考え方は確かにある。

構造っていうのは静的なものの見方だよね(クラス図なんかがそう)。
それに対してフローやシーケンスは動的なものの見方。

昔から「静的なものの見方」VS「動的なものの見方」という
対立軸はあって、時代によってどっちかが優勢になることは
あるけど、どっちが絶対正しいというもんでもないぞ。
どっちも必要。



370 :仕様書無しさん:2007/01/15(月) 23:03:18
>>368
それだ。
いままでそれを言葉で表現できなかった。
デスクトップの付箋に保存しておこう。

371 :336:2007/01/15(月) 23:06:01
みんなが大好きなUMLの教科書にも、静的な側面だけで設計すると
良くない設計になるから、動的な側面と静的な側面(この側面を
ビューと呼ぶ)でそれぞれ設計してラウンドロビンしなさい、と
書いてあるだろ。


372 :仕様書無しさん:2007/01/15(月) 23:11:33
>>371
それって単純に言えば設計者の腕次第ってことだろ?

373 :仕様書無しさん:2007/01/15(月) 23:18:40
メイヤーのオブジェクト指向入門では、動的な処理の記述でシステムを特徴付けるのは不可能だって書いてあるね。
大目的を達成するための処理を記述するフローチャートは確かに便利だ。
でも実際の業務では大目的がころころ変わったり追加されたりする。
そのたびにフローチャートを作り直すなんてのは無理な話だからね。
では何を基本的な構造としてシステムを構築していくかって話しになったときに、
システムに不変的に存在し続けるクラスを基本としようってのがオブジェクト指向。


374 :仕様書無しさん:2007/01/15(月) 23:18:42
>>359
OMGはまたこんな胡散臭いもの作ったのか…。

まあそれは置いといて、オブジェクト指向が流行る前から処理の流れ(フローチャート)より
データの流れや構造にまず着目して設計するのは基本だろ。

375 :仕様書無しさん:2007/01/15(月) 23:19:36
>>373
そんな大層なもんじゃねぇだろw

376 :仕様書無しさん:2007/01/15(月) 23:20:50
このスレみてわかった。

ここって一般人からみれば、「オブジェクト指向マニア」
としか言いようが無い人しか来ないだろうけど、
それですら、オブジェクト指向の本質ひとつ取ったって、
こんだけ紛糾してコンセンサスが取れないのな。

こりゃ、永久に流行らんわ。

377 :仕様書無しさん:2007/01/15(月) 23:21:15
シーケンス図はあんまり役には立たんなぁ・・・。
一生懸命書いた努力は認めるけど大抵嘘ッパチだからなぁw

378 :仕様書無しさん:2007/01/15(月) 23:47:22
まあ、オブジェクト設計は将来できるであろう上位設計理論のための布石ってことで。
よくある話だ。

379 :仕様書無しさん:2007/01/15(月) 23:54:42
>>378
つか、将来的にもう少しシェイプアップしたほうがいいんじゃねぇの?>ソフト開発
予算少ないのに無駄な人材多すぎだよ。
こんだけ人数やら期間やら絞るんなら上流とか下流とか必要無いって。
一番面倒なのが上流と下流が別の奴ってのがそもそも駄目だ。
つか、設計云々とかじゃなくて普通に金の無駄。

380 :仕様書無しさん:2007/01/15(月) 23:56:13
どっちかっていうと仕様のシェイプアップが一番先かな。

381 :仕様書無しさん:2007/01/15(月) 23:57:49
>>379
どうすればいいの?
それが簡単に出来れば大金持ちだよ?


382 :仕様書無しさん:2007/01/15(月) 23:59:31
次段階にそのまま落とし込める仕様設計理論、ていうか普遍的テンプレートが必要。
今はできる人はテンプレ持ってるけど・・・ってことかいな。

383 :仕様書無しさん:2007/01/15(月) 23:59:36
海外に丸投げ

384 :仕様書無しさん:2007/01/16(火) 00:01:43
>>381
類似ソフトの仕様を徹底的に真似る。

385 :仕様書無しさん:2007/01/16(火) 00:04:08
> そのまま落とし込める仕様設計理論
これはMDAとかExcutiveUMLだな。
夢のまた夢のような気がする。実現すればしたでうれしいが、
期待してない。

> 普遍的テンプレートが必要
こっちはSoftwareFactoryっぽい?普遍的じゃなくて、問題領域
特化型だけど。


386 :仕様書無しさん:2007/01/16(火) 00:06:12
上流から下流って言うよりも、元請と下請けの関係を無くさないとな。
日本のソフト開発は大手が受けて子会社が仕事するって形になってる。
日本の物作り構造は全部そう。


387 :仕様書無しさん:2007/01/16(火) 00:08:29
アメリカもそうでしょ。

388 :仕様書無しさん:2007/01/16(火) 00:11:00
>>384
こんな感じ?
http://www.kingsoft.jp/


389 :仕様書無しさん:2007/01/16(火) 00:11:31
てか、現場の上流工程の実際ってどうよ?
俺はあんましよろしくないね。
理由としては駄目であっても駄目であることを説明しにくいから。
オブジェクト指向がいいか悪いかとかそういう議論といっしょだな。
YESかNOで表現できない分、話術でどこまでもでっちあげることができる。
あんまり開発者としてはうれしくない。

正直、プログラムが組めない人がソフト開発に参加するためのポジション的な要素が強いと思う。

390 :仕様書無しさん:2007/01/16(火) 00:14:03
>>388
おお、商品開発のあるべき姿だな。
これがなんかパクリだなんだってこだわりはじめた頃から物作りがおかしくなった。
と俺は勝手に思ってるんだけどね。

昔の松下はこうだったよな。
急にマネシタなんていう奴がでてきたけど。

391 :仕様書無しさん:2007/01/16(火) 00:18:34
>>385
>これはMDAとかExcutiveUMLだな。
ここら辺は詐欺師がセミナー代を稼ぐためのネタとして考え出したもので
売り出してる当人達も本気で実用性があるとは思ってないでしょ。

392 :仕様書無しさん:2007/01/16(火) 00:21:12
>>391
オブジェクト指向まわりっていうか、ソフトウェア工学まわりってそういうの多いよな。
大学の教授組(実際にソフト開発してない人)方には正直ご退場願いたいところだよね。

393 :仕様書無しさん:2007/01/16(火) 00:21:55
>391
やっぱりあれは詐欺なのか。
いや、どう考えたって無理そうなのでこれってどうなんだろうと思ったんだが。
本を読んだ人でイイ、イイ、言っている人が居たのでかなり悩んだが、すっきりしたよ。

オブジェクト指向周りは詐欺師も多いから、地雷を踏まないように気をつけなければ。


394 :仕様書無しさん:2007/01/16(火) 00:27:57
>>393
いや、本気でいいと思ってやってる人もいるんだろうけど、
開発期間(開発効率じゃなくて!開発期間(超重要))が1.5倍〜2倍は少なくなるようなもんじゃないと
導入にあんまり意味が無いと思うな。
セミナーまで開いて具体的な数字すらなくて「〜な気がする」で止まってるもんは本人にそのつもりがなくても詐欺でいいけど。

395 :仕様書無しさん:2007/01/16(火) 00:30:18
>本を読んだ人でイイ、イイ、言っている人が居たのでかなり悩んだが、すっきりしたよ。

こんな納得の仕方はないのでは。。?
AndroMDAとか簡単に試せるんだから使ってみればいいじゃない。

396 :仕様書無しさん:2007/01/16(火) 00:33:58
ようするにモデル駆動開発だろ?
モデルから完全なコードなりプログラムを吐き出してくれなきゃ手間が増えるばっかだ。

397 :仕様書無しさん:2007/01/16(火) 00:40:00
現状のMDAは「モデルから完全なコードなりプログラムを吐き出す」部分に関して
全く問題ないレベルに達しているだよ。

問題は「完全なモデルを定義する」のがものすごく大変ってところだな。

398 :仕様書無しさん:2007/01/16(火) 00:48:46
>開発期間(開発効率じゃなくて!開発期間(超重要))が1.5倍〜2倍は少なくなるようなもんじゃないと

こういう日本語ってプログラマーとしてどうなのよ?
って思いました。

399 :仕様書無しさん:2007/01/16(火) 01:15:39
http://www.tech-arts.co.jp/

UMLやらアジャイル開発やらの本を節操なく出してるこの(↑)会社ってどうよ?
サイトからして微妙に怪しい雰囲気を感じるんだが。

400 :仕様書無しさん:2007/01/16(火) 01:17:27
あははたしかにポッペンディークが
新興宗教の教祖に見えるなあ

401 :仕様書無しさん:2007/01/16(火) 01:22:28
オブジェクト指向関係の学者とか、ハッカーとかって
(リチャードストールマンとか)宗教家顔が多いよな。

逆にノイマンとかチューリングとかホーアとか昔の情報系数学者
は普通の学者顔なのに。


402 :仕様書無しさん:2007/01/16(火) 03:20:13
> まじで業務分析にアクティビティ図をつかうことを知らない
> やつがこんなにいるのか...(´Д`;

知ってるけど、使うと伝わんねーんだよ orz...

403 :仕様書無しさん:2007/01/16(火) 08:18:38
まずは、クラス図とシーケンス図で十分です。
それすらも設計できないから流行らない。

404 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/16(火) 20:52:47
どうせ仕様変わるんだし
画面図だけでいいよ
OOは君の心の中にあるんだ。
手法の問題ではないのだ。

フローチャートのブロックを枠で囲ってオブジェクト指向フローチャートとする。
もーばっちり

405 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/16(火) 20:57:41
オブジェクト指向は信者が優越感を得るために存在する。
生産性はマイナスになる。

406 :仕様書無しさん:2007/01/16(火) 21:04:53
画面図だけで十分な、単純なソフトしか作らない奴に言われてもなー

407 :仕様書無しさん:2007/01/16(火) 21:21:29
>>404
画面も仕様変更よくあるけどないよりはましかなー。

>>406
そういう無駄な煽りやめようぜ。
俺はどんなにでかいもんでも無くてもなんでも作れるから
俺とお前が業務でぶつかったら多分俺なんでも捨てちゃうぜw
「なくても作れる(俺)」と「あったほうがいい(お前)」がぶつかったらコストの安い俺の方に分があるんだぜ。

408 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/16(火) 21:54:18
画面仕様は変更されても ソース直して動かしてプリントスクリーンで取り込めばすぐに仕様書をフィードバックできる。
ほかの仕様書はだめね。

完成が近づくと、現状と異なる設計書、仕様書の山ができて、そっち直すほうがソース直すより時間かかる。
(ここで目が覚めるはずだが)
で最後放置。(自社開発の場合 請負は知らない)


409 :仕様書無しさん:2007/01/16(火) 22:16:48
何このキモコテ

410 :仕様書無しさん:2007/01/17(水) 01:01:48
>>408
それはキミの現場(会社?)が、開発途中で意思疎通や調整のために発生する
ドキュメントと、最終的に納品あるいは保存する成果物の区別が付いていないせい。

よくある間違いは、開発初期段階から納品ドキュメントを作ろうとすること。
国内ではどこでも見られる光景。ちなみに我が社も。オレは頑なに拒んでいるが。

411 :仕様書無しさん:2007/01/17(水) 02:27:48
まあどっちにしても手戻り前提で設計する奴は
なんちゃってSEですよ

412 :仕様書無しさん:2007/01/17(水) 02:36:17
開発全体として手戻りが発生せず
早く正確なものができる方法を採用できなければ駄目。

413 :仕様書無しさん:2007/01/17(水) 02:51:30
どの程度後続に対し詳細に情報提供すれば良いか読むべきだし
どの程度先方に対し詳細に情報提供して欲しいか言うべきだし
後続が「この情報が欲しい」と言った事に対して
文句を言う奴がいるPJは火を噴く。

414 :仕様書無しさん:2007/01/17(水) 02:55:25
規則も無い無法地帯では
あくまでも受け手が良し悪しを決めるから
受け手が積極的に確認する必要がある。

415 :仕様書無しさん:2007/01/17(水) 02:57:56
さらに確認したうえで不満があっても
伝えてない事であれば切れるべきではない。
むしろ情報提供できていない先方の責任。

416 :仕様書無しさん:2007/01/17(水) 02:59:20
一定水準以上の品質を要求するのであれば
ガイドラインを設けたら良い。

417 :仕様書無しさん:2007/01/17(水) 03:02:11
ガイドラインが無いんじゃ
受け手の責任とするのは無理があるんじゃないかな。

418 :仕様書無しさん:2007/01/17(水) 03:09:02
すまん。まちげーたw
×受け手の責任とするのは無理がある
○送り手の責任とするのは無理がある


419 :仕様書無しさん:2007/01/17(水) 03:20:35
だから問題が発生しても受け手は切れる必要は無く
送り手が受け手に合わせて修正すれば良いだけの
話だと思うんだけどな。

420 :仕様書無しさん:2007/01/17(水) 03:27:25
>>419
断定口調にしないとw

421 :仕様書無しさん:2007/01/17(水) 03:28:17
だから問題が発生しても受け手は切れる必要は無く
送り手が受け手に合わせて修正すれば良いだけの話だ。


422 :仕様書無しさん:2007/01/17(水) 07:31:45
>>412
>開発全体として手戻りが発生せず 
>早く正確なものができる方法を採用できなければ駄目。 

自分で分かっているとは思うんだけど・・・

そんなこと書いて、オモシロイの?


423 :仕様書無しさん:2007/01/17(水) 07:55:01
オブジェクト指向の開発じゃ反復型開発は当たり前。
実装からのフィードバック無しに最初から完全なモデルを書くのなんて不可能だし、
できたとしても非効率だよ。
UMLなんかはスケッチ程度に使ってレビュー実装テストを何度もやらなきゃ。

424 :仕様書無しさん:2007/01/17(水) 08:19:54
フィードバックと手戻りが混ぜ混ぜしてきてるよ。


425 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/17(水) 08:52:35
OOが生産性高いなら 競合他社を差し置いて受注独り占めで業容拡大の一途だろう。
OO普及から時間も十分たってるのにそうなってないのはOOの宣伝する生産性の向上がうそだから

426 :仕様書無しさん:2007/01/17(水) 09:04:04
OOが生産性が低いなら
オブジェクト指向言語ばかり流行るのはなぜだろう?
結局、生産現場では、今ではC++,Javaを始めとした
オブジェクト指向言語によるOOでの開発が主力


427 :おじゃばさま:2007/01/17(水) 09:50:04
オブジェクト指向プログラミングの生産性は高い訳ではない。
仕様が決まっていて変更が少ないとしたら、従来の構造化プログラミングの方が少ないステップ数になる。
OOPの利点は変更時の影響の少なさである。
例えばプログラムの出力先をファイルからDBに変えるとする。
適切にOOPされたコードでは驚くほど簡単に変更出来る。
構造化の場合は設計時からそれを予期していない場合、多くの場合は大変更になる。


428 :仕様書無しさん:2007/01/17(水) 14:05:18
>>427
作られたPGがOOPに則していたら、次の別プロジェクトクトに再利用できる。
OOPの生産性は、そこで大きくものを言う。

429 :仕様書無しさん:2007/01/17(水) 14:32:54
ってのが幻想というのは既に判ってると思うのだが。
その再利用性ってモジュール化したら再利用可能ってのと大差無い。

特定プロジェクトの成果物を他のプロジェクトで再利用ってのは、まず無い。
不特定向けに基本プロジェクトを作って、他にCustomizeするときに便利ってのはまだ理解できる。




430 :仕様書無しさん:2007/01/17(水) 14:43:38
OOPに再利用性は、さほどない。
構造化PG時代のライブラリと大差なく、単にその規模が大きくなっただけ。
モジュールの効率良い再利用性は、事実上不可能であると位置づけられてる。

OOPの有効性を語る事自体がナンセンスだ。規模の大きいプロジェクトでは
自然と使うものだし、使わなくていいなら使わなければいいだけの事

431 :おじゃばさま:2007/01/17(水) 19:27:10
再利用と言うより「変更のしやすさ」だよ。
確かに他のプロジェクトで使うとしたら、適切にモジュール化された物と変わらないだろう。
ただし、仕様変更の場合が違う。構造化が度重なる仕様変更で次第に複雑になるのに対して、
オブジェクト指向では仕様変更のたびに、コードが洗練されて行く。
これはオブジェクト指向では仕様変更が入っても、基本的にメソッドを追加するような方向で、
以前の処理を残して記述するため、曖昧だった処理の分割点が次第に明らかになっていくからだ。
現代のプログラミング開発では最初から仕様が明確になっている事が少ない。
そのため多くの仕様変更が開発中に発生する。オブジェクト指向はそれに合った開発方法と言える。

ただ変更が容易だと体感するにはある程度の経験とセンスが必要だな。
そのレベルに達している人は結構少ない。

432 :仕様書無しさん:2007/01/17(水) 19:39:31
>>431
それをどうやって人に説明するの?
俺はオブジェクト指向と従来のやりかたのどっちが変更しやすいか?
っていわれたら、はっきりいってわからないとしか言えないけど。

ちなみに業務で
「オブジェクト指向のが変更しやすいよなぁ?」
って聞かれたら
「大して変わらなくね?w」
って答える。

433 :仕様書無しさん:2007/01/17(水) 21:29:59
>>431
申し訳ないが、経験に基づかない机上の空論にしか見えないな。
少し具体例を挙げてみてくれないか。

434 :仕様書無しさん:2007/01/17(水) 21:38:33
あきらかに手続き(特にC)と比べて変更しやすいと思うが

まぁCでも似たようなことできるが関数ポインタの嵐になる
かつGenericでタイプセーフな形で作りやすくなったし

変更のしやすさを感じないなら疎結合を意識してつくってねぇってところだろうな

435 :仕様書無しさん:2007/01/17(水) 22:00:40
変更時こそGoFのデザインパターンの威力を実感できるでしょ。


436 :仕様書無しさん:2007/01/17(水) 22:11:55
ここ見てるとわかってない奴ばかりだなと思う
だから俺が稼げるわけだがwww

437 :仕様書無しさん:2007/01/17(水) 22:43:36
>>435
俺からすればデザパタが使えるなんて言ってる雑魚は全員攻撃対象だ。
オブジェクト指向そもそもわかってねぇじゃんwゲラゲラゲラw
まあ、いっしょにオブジェクト指向で中程度のプログラム組んでみりゃ納得すんだろうけど、
まわりに人がいないのは不幸なことだよねw

438 :仕様書無しさん:2007/01/17(水) 23:06:38
まー、他人の口からデザパタという言葉がでると攻撃本能が
刺激されるというのは気持ちとしてわからんでもないけど。

俺も含めてこのスレの住人はオブジェクト指向の深い知識が
ないのは確か。何か問題がでるとハイ、キタとばかりにデザパタ
とか言われると、萎えるな。そのレベルで人を煽るんだもん。

オブジェクト指向厨の特徴として、「オブジェクト指向はみんな
わかってないっ。周りにわかっている人間は俺だけっ」っつーの
がある(このスレではみんな同じ事を言っているでしょw)けど、
もうちょっと謙虚になった方がいいと思う(俺もだが)。

職場でオブジェクト指向がわかっていると思われるのが自分だけなのは
自分が賢いんじゃなくて、みんな興味がない(どうでもいい)だけだって。
本気で理解しようと思えば自分と同じくらいは誰でもできる
と思った方がいいと思うよ。

一回オブジェクト指向から距離を置いて考えられるように、
ソフトウェアでもオブジェクト指向(アジャイルとかも含む)以外の
ことを勉強したり、職場の人間関係や要領のいい仕事の
やり方とか考えた方がいいんじゃないかな。



439 :仕様書無しさん:2007/01/17(水) 23:11:43
で、結局実装のミクロな話は得意で語れるけど、このすれの主題を理解できないのがオブジェクト厨

440 :仕様書無しさん:2007/01/17(水) 23:23:36
今更、デザインパターンねえ。
昔勉強したときは、実装上のテクニックとしてVisitorパターンやObserverパターンは
感心したけど、他は当たり前のことや使う機会ないだろってパターンばっかだったな。
どっちにしても詳細設計やコーディングレベルの話でこのスレで語る話とはズレてるわな。

441 :仕様書無しさん:2007/01/17(水) 23:25:08
>>438
長いばっかで空っぽにもほどがあるw

442 :仕様書無しさん:2007/01/17(水) 23:34:32
>>436
オブジェクトがわかると稼げるんだ?

どうして?

443 :仕様書無しさん:2007/01/17(水) 23:34:40
>>438
そうじゃなくて、実際に使ってみることもしないのにつかえねーだなんだと
ぐだぐだいってるのがむかつくんだよ。

>自分が賢いんじゃなくて、みんな興味がない(どうでもいい)だけだって。
興味がないんだったら黙ってればいいじゃん。
大体、他のこと(特に実務レベルの)を勉強しない奴がオブジェクト指向にのみ
興味を持ったり、逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
ことありえないだろ。

まとめると「(オブジェクト指向みたいな)役に立つかどうかわからないことに必死になって、頭悪いんじゃない?」
みたいな態度をとってること自体が、ものすごい低能ぶりを晒してるってことに気づけない分際で偉そうに批判ばっかり
繰り返してる奴は死ねばいいってこと。

444 :仕様書無しさん:2007/01/17(水) 23:41:02
>>443
すれ違いって理解できない?


445 :仕様書無しさん:2007/01/17(水) 23:46:03
> そうじゃなくて、実際に使ってみることもしないのにつかえねーだなんだと
> ぐだぐだいってるのがむかつくんだよ。
使ってみてあえて使えないという人の存在を無視してるな。
批判するやつは理解できないやつかやったことのない奴かどっちかと
思っているというパターンも多いな。

だいたいどんな技術にも批判はあるわけであって、オブジェクト指向
の生産性や再利用性に疑問を投げかける意見があっても当然だ。
そういう批判に対して冷静に評価することも必要だろ。
どっちにしても入れ込みすぎ。

> 逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
> ことありえないだろ。
ついでにこういう人はいるよ。


446 :仕様書無しさん:2007/01/17(水) 23:57:12
あまりにぶっ飛んだ流れなので、ついにレスするけど
大きなソフトウェア開発(つまり業務開発)でOOPを使わないなんて事が
現実上あり得るのか?
このスレにいるのは、趣味PGか同人PGだろ?
OOPの実用性を否定するなんてあり得んぞ?
それが無いと開発できないのだから。

447 :仕様書無しさん:2007/01/17(水) 23:59:07
まあ、たしかに微妙なんだよなー。
オブジェクト指向なら開発期間が2分の1になりますよ!
なんていって、本当に開発期間を2分の1にされた挙句
時間あたりの給料も2分の1(つまり給料そのまま)じゃやってらんねぇしなw

そのうち残業代もでなくなるっぽいし、オブジェクト指向が使えると世間が認めることに意味がねぇよ。
つまり、実際は微妙なのに「オブジェクト指向導入したから期間は2分の1でいいよね?」とかめちゃくちゃな
ことを言われそうな気がするんだよね。

しかも、俺等の技術なんて評価されたことないじゃない?

448 :仕様書無しさん:2007/01/17(水) 23:59:14
OODははやってないっていってんじゃん。

449 :仕様書無しさん:2007/01/18(木) 00:00:35
>>446
大きなソフト開発で新規に携わったことないな。
いつも保守、改修、改造ばっかで・・・
だいたいC言語で書いてあるのばっかだからオブジェクト指向なんて欠片もない。

450 :仕様書無しさん:2007/01/18(木) 00:03:02
>>449
アナタの業務タイプを教えてくれ

451 :仕様書無しさん:2007/01/18(木) 00:03:07
大規模開発ほどオブジェクト指向は向いてないよ。
だって人数が多くなればなるほどオブジェクト指向わかってない奴が増えるもの。
うちの先輩の設計を見てきた俺が言うんだから間違いない。


452 :仕様書無しさん:2007/01/18(木) 00:05:34
>使ってみてあえて使えないという人の存在を無視
拡大解釈すんなよ。そんなこといってねー。

それにそういう奴は「こういうところで使えないと思うんだけどどうよ?」的なレスしなきゃ
何の意味もないだろ。

>> 逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
>> ことありえないだろ。
> ついでにこういう人はいるよ。
マジョリティではありえないし、そうでないならこれ書くことに何の意味があるの?

453 :仕様書無しさん:2007/01/18(木) 00:05:58
大規模っつったら、新規なんてそうそうないだろ。
つか、大規模のプロジェクトに関われば関わるほど保守の仕事が多くなるはず。
そこで必要になるのはオブジェクト指向なんかじゃないよな。

454 :仕様書無しさん:2007/01/18(木) 00:06:20
>>446
なにゆえ非OOを否定するのかわかんねぇ。
たしかに、ここではスレ違いかもしんないけど、例外みたく言う必要はないだろ。

455 :仕様書無しさん:2007/01/18(木) 00:06:40
あ、ゴメン
>>452>>445へのレス

456 :仕様書無しさん:2007/01/18(木) 00:06:54
> OOPの実用性を否定するなんてあり得んぞ?
大きなソフトウェア開発にOOPを使うことが必須でも、否定しちゃならん
ということにはならんと思うんですが。

OOP自体の実用性はプラマイゼロでも開発インフラ、フレームワークや
コンポーネントがあるからOOPをつかうというのもありだと思うんですが。
実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
が優れているからという理由以外がかなり大きいと思うんですが。

オブジェクト指向を批判する人に多いのは、プライマイゼロの評価で、
つまりプラマイゼロならその他の要因があればOOPをつかう選択も
ありうると思うんですが。

単純にパラダイムの優劣でだけですべてが決まるならLISP厨が
いっているみたいにLISPが天下をとってたかもしれない。
(個人的にはありえないと思うが)


457 :仕様書無しさん:2007/01/18(木) 00:08:39
>実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
>が優れているからという理由以外がかなり大きいと思うんですが。
なんだっつーの?

458 :仕様書無しさん:2007/01/18(木) 00:13:33
>実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
>が優れているからという理由以外がかなり大きいと思うんですが。
もう、こういうあいまいことわかってるふりして言う奴晒していこうぜ。
こういうただでさえあいまいなモンの議論してるときにアフォとしか思えない。
2ちゃんに二度とくる気になれないぐらいぶっ叩いてご退場いただこう。

で、なによ?

459 :仕様書無しさん:2007/01/18(木) 00:30:44
>458

> OOP自体の実用性はプラマイゼロでも開発インフラ、フレームワークや
> コンポーネントがあるからOOPをつかうというのもありだと思うんですが。
って書いてるでしょ。

あと、マイクロソフトやサンマイクロシステムズのような大手の
ソフトウェアベンダーがOOP関係のテクノロジを推進しているという
政治的理由。実際問題、力を持っているマイクロソフトなんかには
みんな追随するしかないでしょ。技術的優劣とは関係なしに。

これらの企業がまったく違うパラダイムを推進していたら、
今現在の状況はまったく違っていたのは間違いない。

ソフトウェア関係は標準になったり、デファクトスタンダードに
なったものが強いのはみんな良く知っているでしょ。


460 :仕様書無しさん:2007/01/18(木) 00:33:43
技術的優劣ですべてが決すると思っているのはイノセントすぎると
思うんだけど。

コンピュータ言語の基礎理論の研究している人で、既存のオブジェクト
志向言語よりもっといいものがあると思っている人はたくさんいるけど、
インフラのめんとかで結局実用的じゃなくて地団駄踏んでいることが多い。

461 :仕様書無しさん:2007/01/18(木) 00:34:33
単なるインクリメンタルモデルなら良いが
手戻り前提の意識で手抜き設計されては困る。

462 :仕様書無しさん:2007/01/18(木) 00:39:49
手戻りとは・・
×追加
○やり直し

463 :仕様書無しさん:2007/01/18(木) 00:41:00
>>459

> あと、マイクロソフトやサンマイクロシステムズのような大手の
> ソフトウェアベンダーがOOP関係のテクノロジを推進しているという
> 政治的理由。実際問題、力を持っているマイクロソフトなんかには
> みんな追随するしかないでしょ。技術的優劣とは関係なしに。
>
> これらの企業がまったく違うパラダイムを推進していたら、
> 今現在の状況はまったく違っていたのは間違いない。
>
> ソフトウェア関係は標準になったり、デファクトスタンダードに
> なったものが強いのはみんな良く知っているでしょ。

だからなんなのさ?


464 :仕様書無しさん:2007/01/18(木) 00:42:30
> だからなんなのさ?
だから批判していてもつかっている人はいるし、技術的な批判しちゃいけない
ということはないという話。理解できないのか。

465 :仕様書無しさん:2007/01/18(木) 00:48:29
>>464
> > だからなんなのさ?
> だから批判していてもつかっている人はいるし、技術的な批判しちゃいけない
> ということはないという話。理解できないのか。

理解できない。
その2行で事足りることを、あえて長文で難しく表現するのかが。

466 :仕様書無しさん:2007/01/18(木) 00:50:53
エンジニアの文章じゃないな。意図が全然伝わってこない。

467 :仕様書無しさん:2007/01/18(木) 00:51:23
>>459
さっきから何度も言われてると思うが、プログラミングの技術としてのオブジェクト指向と、
分析や設計の技術としてのオブジェクト指向を分けて考えようよ。
前者はこのスレでは叩かれてないし、みんな恩恵を理解して使用してるよ。

468 :仕様書無しさん:2007/01/18(木) 00:51:32
オブジェクト指向の定義そのものが10人いれば10通りあるわけで
「オブジェクト指向的な考え方」は有益、としか言えない。

教条主義的にオブジェクト指向と言われるものを何でも持ち込んで
構造を理解することの方が、コーディングするより遥かに難しい
設計をする奴も結構いるから嫌われる。

469 :仕様書無しさん:2007/01/18(木) 00:52:54
>>439
禿同。スレタイよく嫁と。

>>446
近年のモノならな。(OOPに限っては)
10年20年前のコードをメンテするような大規模プロジェクトもある(と思う)。

>>456
> 実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
> が優れているからという理由以外がかなり大きいと思うんですが。
言語がOOだからね。

470 :仕様書無しさん:2007/01/18(木) 01:01:23
上流の設計と下流の詳細設計及びコーディングなんて分けする奴の方がオブジェクト指向をわかってないね


471 :仕様書無しさん:2007/01/18(木) 01:02:18
>>470
厨房は学校池

472 :仕様書無しさん:2007/01/18(木) 01:09:36
まあ、ケイやストラウストラップもコーディングの効率性・保守性・
拡張性、といったことのために「概念」を提供してるんだけどな。
「設計・分析は何のためにあるか?」ってことを忘れてる奴が
多すぎる。モノを作るってのは形而上のことじゃないだろ。

473 :仕様書無しさん:2007/01/18(木) 01:13:02
>>469
OOPとOOD/OOAの関係は、ミクロとマクロの関係じゃないだろ。

474 :仕様書無しさん:2007/01/18(木) 01:13:24
>>434
> まぁCでも似たようなことできるが関数ポインタの嵐になる

いや、たいていモジュール化で済む、という話をしていたはずだけど。
dll(API)とか、COMとか、部品化する利点の一つは再利用性な
わけで、変更しやすさってその域からあまり大きく変わってないのでは?
という話だと思う。

475 :仕様書無しさん:2007/01/18(木) 01:14:20
>>471
>形而上

最近覚えたんでつか?


476 :仕様書無しさん:2007/01/18(木) 01:15:48
>>446
単にきみが世間知らずで見聞が狭いだけだと思う。
「オブジェクト指向?なにそれ?」な現場は掃いて捨てるほどある。

477 :仕様書無しさん:2007/01/18(木) 01:16:33
>>475
どこにレスしてんだよw

478 :仕様書無しさん:2007/01/18(木) 01:23:05
手戻りコストを抑えられたとしても決して0にならない。
よって、設計の手抜きを助長する考え方として説くべきではない。

479 :仕様書無しさん:2007/01/18(木) 01:27:12
趣味PGや同人PGの方が好きでやってるからOOPもしやすいんじゃないかな

480 :仕様書無しさん:2007/01/18(木) 01:27:18
>>473
「実装(OOP)のミクロな」と俺は読んだんだが。

>>474
COM使った時点でOOに片足つっこんでないかい?

>>476
あるよー。



481 :仕様書無しさん:2007/01/18(木) 01:31:35
多様な具象を知るから抽象化ができる。
前線を知らない大本営が戦略立ててもダメでしょ。
中にはいるかも知れないが、1万人に1人いるかいないか…

482 :仕様書無しさん:2007/01/18(木) 01:33:52
>>480
>「実装(OOP)のミクロな」と俺は読んだんだが。
あ、なるほど。失礼。

483 :仕様書無しさん:2007/01/18(木) 01:43:08
>>482
いえいえ^^
日本語でさえ、意思疎通は大変なのだから。

ましてOOD/OOA(言語はUMLか?)で意思疎通をするなら
プロジェクト関係者の過半が一定の共通理解している必要があるよね。

というのがスレタイに対する俺の意見。

484 :仕様書無しさん:2007/01/18(木) 01:43:23
多用な具象はプログラムではなく
ユーザーから抽出するべき。

485 :仕様書無しさん:2007/01/18(木) 01:47:51
>>484
それも一理あるが、プログラムが判らないんじゃ具現化できんよ。

486 :仕様書無しさん:2007/01/18(木) 01:48:17
>>483
でもOOD/OOAじゃなきゃ、どんな設計手法なら
プロジェクト関係者の過半が一定の共通理解できるっていうのかねえ?

487 :仕様書無しさん:2007/01/18(木) 01:50:29
もういいから自分の所だけオブジェクト指向でつくっとけ。

488 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 01:53:44
オブジェクト指向を振り回すやつはたいてい サブルーチンさえまともに作れないやつだけどな

489 :仕様書無しさん:2007/01/18(木) 01:55:56
コボラ乙

490 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 02:01:42
コボルしらね
Javaはさんざんやったけど 今はVCだな
デザパタも大抵のパターン少なくとも一度は使った
それで駄目だと証明できたので必要なときに部分的に使うことがあるくらいだ。
悪いことはいわんから、こんなたちの悪い宗教からは足を洗いたまえ。

491 :仕様書無しさん:2007/01/18(木) 02:02:55
別にUMLでもいいんだけど、補足資料が足りない奴が多いんだろ。
昔風のフローや画面図が必要なこともある。
判ってる自分だけの世界で完結しちゃうから現場が付いてこない。
法の制定と運用は違うわけだし、慣習法的な考え方も必要。
お前ら勉強しろよって言ってるだけじゃ、どうにもならんと思うよ。

492 :仕様書無しさん:2007/01/18(木) 02:08:55
JavaとかC+とかってなんかOOP的にしなきゃって思うじゃん

493 :仕様書無しさん:2007/01/18(木) 02:25:29
>>490
2ch黎明期じゃあるまいし、今日日そのレスはないだろ。

494 :仕様書無しさん:2007/01/18(木) 02:41:45
>>492
別に「OOP的」に書くのは問題ない。

Cにしたって未だに++は使う必要ないとか言ってる方がオカシイ。
OOP的概念の何を使うかってことだろ。例として言えば継承だって
単にクラスを継承することとインターフェースの継承は概念として
違うし、インターフェース継承だけして直接ハードウェアアクセス
するとこはモロにCで書くなんてよくあること。混在で何の問題もない。

ケースバイケースでリアリズムに徹すればいいと思うけどね。
ターゲットと開発メンバーを見てOOPの概念の何を採用するかを
決めればいいことだと思うよ。

495 :仕様書無しさん:2007/01/18(木) 02:58:45
ユーザーからの抽出が困難だから
仕様変更に強い考え方が生まれるのは理解できるが
設計が手抜きになる分、仕様変更が多くなり
実装チームが振り回されるだけ。
デスマ誘発率は高い。

496 :仕様書無しさん:2007/01/18(木) 03:03:51
>>490
ココ電逝ったあああああああああああああああああああああああああ

497 :仕様書無しさん:2007/01/18(木) 03:07:30
>>488
確かにサブルーチン書けてOOP使えなくても飯は喰える
OOP使えてサブルーチン書けないケースってのは
単に技量がアレなだけだな、君の株の腕みたいなもんだよ

498 :仕様書無しさん:2007/01/18(木) 04:04:19
そろそろお勉強のための本でも紹介してくれるとありがたく。

499 :仕様書無しさん:2007/01/18(木) 07:43:24
>>486
構造化設計なら理解している奴が多いと何度かレスがあるようだが・・・?

>>491
現実には、OOなプログラムを作ろうとしているものを、
フローチャートなどへ「翻訳」する作業が発生する。
それが補足資料的なものになるのかな。

>>495
そうかもしれない。仕様変更に強いからといってもそれに頼りすぎるとイクナイ。
ユーザから多用な具象を抽出する努力を放棄するエクスキューズにはならんと思われ。
(これはOOに限らん)

プログラムから抽出する「共通クラス」厨にはなりたくないものだww


500 :仕様書無しさん:2007/01/18(木) 08:12:59
まぁ、結局は数字を出さなきゃだめだってことだよ。
評価してもらうなら、ね。

漏れの場合は、
「この部分は本来これだけ工数が掛かるところを〜」
というのを上司に説明して、なんとか認めて貰ったことはある。
けど、結果は当たり前で、作業効率が上がった分、
仕事が増えて、給料据え置き。

そして、今では自分の睡眠時間を増やすためにOOを勉強してる。
そんなもんだろ、現実は。


501 :仕様書無しさん:2007/01/18(木) 08:20:20
おれも>>494に同意。
「こうでなくてはならない」から先に考えるべきではないと思う。

502 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 08:37:35
時計をオブジェクト指向で作ると失敗する

まずゼンマイオブジェクト 竜頭オブジェクト 歯車オブジェクトと 作っていき
針オブジェクトから派生した秒針 分針 時針オブジェクトで終わる。

すげー手間がかかる上になにもいいことがない

503 :仕様書無しさん:2007/01/18(木) 08:49:00
>>502
閏秒には対応しやすいだろ

504 :仕様書無しさん:2007/01/18(木) 08:56:16
>502
デザイン変更等が用意

大体、ゼンマイにしろ歯車にしろ作るのには
かわりないから、手間は良くも悪くもほとんど変わらん。

505 :仕様書無しさん:2007/01/18(木) 09:34:09
>>500
こういう人が設計工程で増えてくれば、普及するし楽にもなるんだがな。

506 :仕様書無しさん:2007/01/18(木) 09:34:46
>>498
ゴメ。イイのはあまりしらないんだ。


507 :おじゃばさま:2007/01/18(木) 09:51:13
>432,433
構造化プログラミング言語であるCでは、データ構造は構造体として分割するが、
処理は分割せずに関数として記述する。
そのため処理が追加された場合は、データは分割されるが、処理はごちゃ混ぜになる。
オブジェクト指向言語であるJavaではデータはフィールド変数、処理はメソッドとして分割される。
そのため処理が追加されても、データも処理も分割される。
で追加される処理が多ければ多いほど、それが共通の処理なのか、もしくはどの部分が共通でどの部分が
固有なのかが分かるため、それがどこのメソッドに追加されるのかが明確になってくる。
つまり、
Cでは仕様変更が発生すると、関数内にif文が追加され、コメントを見ないと分からないような
処理が増えて、複雑になる。
Jacaでは仕様変更が発生すると、クラスやメソッドが増えるが、今までの処理も共通化されたりして、
使いやすくなっていく。
と言うことだ。


508 :仕様書無しさん:2007/01/18(木) 10:01:21
で、結局コーディングレベルの話ばかりで、そもそもの話は夜中中無かったわけか。


509 :仕様書無しさん:2007/01/18(木) 10:42:01
>>508
キモコテはスルーでよろ

510 :おじゃばさま:2007/01/18(木) 10:55:29
オブジェクト指向プログラミングは明確な定義があるが、
オブジェクト指向設計は明確な定義があるがある訳ではないので、まず定義から始める必要があるだろう。
長々と書いても分かりにくいと思うので、
「オブジェクト指向設計」=「ユースケース図とシーケンス図を作る」
でいいかな?



511 :仕様書無しさん:2007/01/18(木) 11:01:54
>>510
ちげーよ、それはUMLを書けて喜ぶ奴のレベル。


512 :仕様書無しさん:2007/01/18(木) 11:08:22
>>503-504
でもアナログ時計からデジタル時計に作り変えたいときは、
結局は全部作り直しだから同じこと。


513 :仕様書無しさん:2007/01/18(木) 12:11:47
俺はオブジェクト指向はよくわからんけど
もしアナログ時計とデジタル時計をを作るなら、

時計エンジン+GUI (アナログなら針と文字盤、デジタルなら液晶)

ってなるんじゃね?
要は時間を情報として提供できる部分があって、
その情報を表示ドライバが引数に取ればいいだけのこと。

514 :仕様書無しさん:2007/01/18(木) 12:13:15
それ単にCのDLLとかでも一向に構わんのじゃ

515 :おじゃばさま:2007/01/18(木) 12:27:33
じゃオブジェクト指向設計の定義って何?

516 :仕様書無しさん:2007/01/18(木) 13:00:41
>>513
アナログとデジタルを勘違いしちょる。
表示板が問題じゃないんだよ、時間を測る装置がアナログ(ぜんまいなど)かデジタル(電子の波動)か。


517 :仕様書無しさん:2007/01/18(木) 13:06:18
オブジェクト指向は円周率が変わった場合にプログラムの変更が容易になるという利点がある。

518 :仕様書無しさん:2007/01/18(木) 14:01:47
もう答えが出たな。

つまり「小さい変更には便利かも知れないが、大きい変更ではあまり
利点はなく、コンポーネント化の利点と大きな差はない」
だから「利点があまり大きくないのだから、新しい技術を導入する
コストや、それに合わせていろいろ変更するコストを考えると
二の足を踏むのもむべなるかな」となって「だからOOは流行らない」

Q.E.D

519 :仕様書無しさん:2007/01/18(木) 17:04:57
>>518
のようなDQNがおるから。。。。。。

520 :おじゃばさま:2007/01/18(木) 18:11:31
>518
オブジェクト指向プログラミングが、大きい変更では利点がないなど言っていない。
コンポーネント化と同等の利点は、再利用時だとは言ったが、変更時だとは言っていない。
オブジェクト指向プログラミングはすでに流行して定着している。
流行していないのはオブジェクト指向設計である。
と言うか、定義すら曖昧ではないか?
構造化分析や構造化設計に対して、オブジェクト指向分析やオブジェクト指向設計と使っているだけで、
中身は曖昧なのではないかと思う。

521 :仕様書無しさん:2007/01/18(木) 18:49:18
オブジェクト指向って、再利用とか、作業の標準化とか、
部品化することで複雑化した場合のターゲット喪失の回避とか

そういうためのもんだろ。

天才ばっかりならマシン語で最速コード書けば良い。
サボるための技術なんだから、クソ難しく考える必要はないんだよ。

偉そうにすぐ自分で囲い込んだり
造語で語るのは、詐欺師。
業界の発展を妨げるから、消えてくれ。

522 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 19:18:33
欠点

オブジェクト指向やってると 早く家に帰れない


523 :仕様書無しさん:2007/01/18(木) 19:18:55
>>521
>そういうためのもんだろ。
違うってはじめは

http://ja.wikipedia.org/wiki/Simula
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、
というものである。気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。

ってもん。
別に再利用とか作業の標準化とか部品化なんて考えてない
単純に、感覚的に「考え易いでしょ?」っていう感覚的なもの。
なんでどっかの学者さんがこうやって定義してあります。みたいな答えをみんな求めるんだろう・・・。
「考え易いでしょ?」ってただそんだけだよ。そんだけ。

524 :仕様書無しさん:2007/01/18(木) 19:23:05
>>523でオブジェクト指向っぽいものをはじめに作った人に
「別に考え易くないです。」
って反論したとしても
「ああ、そう・・・wそりゃ残念・・・w」
程度のモンだと思うよ。
はじめは軽い考えで、「どうよ?いいんじゃね?」ってもうフィーリング100%だと思うよ。

なのに、再利用のためだとかどうとか無理やりこじつけすぎ。
どう考えたって再利用だのなんだの後付けだろ。
セミナーで金設けするために無理やり新しい用語作ったり、無駄に崇高なものにされた感がいなめない。

525 :仕様書無しさん:2007/01/18(木) 19:25:15
何故に、志村?
Smalltalkが初めじゃねぇか?

526 :仕様書無しさん:2007/01/18(木) 19:30:05
そらはやらんわな

527 :仕様書無しさん:2007/01/18(木) 19:43:15
>>525
よくよめ。違うってことがわかるから。

528 :おじゃばさま:2007/01/18(木) 19:49:44
オブジェクト指向プログラミングと、オブジェクト指向設計を明確に分けて言えと508が言っている。
オブジェクト指向プログラミングの利点は以前に述べた通りだが、オブジェクト指向設計は不明だ。
オブジェクト指向設計の定義自体が曖昧ではあるが、以下のHPで解説されている。
ttp://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#id_427_

ここを読んで俺なりに超要約した限りでは、
「ユースケース図とシーケンス図を作ればオブジェクト指向設計」と解釈したのだが、違うと言われた。

オブジェクト指向が省力化のためだと言われれば「そりゃそうだ」としか言えないが、
それでは構造化などもおなじな訳で、議論にならないのではないかと思う。
コンピュータ業界の発展を願うなら、オブジェクト指向設計を解説すべきではないだろうか?

529 :おじゃばさま:2007/01/18(木) 19:52:28
と書いてる間に解説する人が現れたこのスレも捨てた物ではないと思った。

530 :仕様書無しさん:2007/01/18(木) 19:54:50
>>528
>コンピュータ業界の発展を願うなら、オブジェクト指向設計を解説すべきではないだろうか?
本当に願うなら単純に数字だけに注目することだと思うぜ。
言葉だけじゃ全くの嘘も話す人間によって本当のことのように聞こえてしまう。

531 :仕様書無しさん:2007/01/18(木) 19:57:15
>>530
が数字をだしてくれるとwwwwww

532 :仕様書無しさん:2007/01/18(木) 20:01:06
>>531
いや、まだ、そんなところにいないんじゃないかな?
どういうことをして、どんな結果が出ればその方法が優れているって結論付けることができる
フォーマットを作らなきゃ。
まだ、はじめの一歩すら踏み出せてないってのが現状だと思う。

533 :仕様書無しさん:2007/01/18(木) 20:12:46
変更がありそうな部分で変更に影響しない部分のみをinterfaceに切り出し
具象インスタンスを注入する形をIocで

これだけでかなりのうまみがあると

534 :仕様書無しさん:2007/01/18(木) 20:15:01
>>533
そんなチャチな変更は変更と認めません。
もうガッツリ代わる奴が変更です。
ゲームなら残り1週間で3Dが2Dに2Dが3Dに変更されるぐらいの衝撃を基準に考えてください。

535 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 20:15:20
モジュールごとに分けてインターフェース決めてさ
中は各担当者が勝手なスタイルで作るのがいいと思うよ。
力んだOO厨の試行錯誤に付き合わされた挙句 「おまいらはOOを理解していない、勉強する気がない」 などと
喚かれるのは疲れるだけだしさあ。
OOの人のモジュールが優れていれば周りもついてくるからそうしようね。



536 :仕様書無しさん:2007/01/18(木) 20:19:04
>>535

実際の現場には、今時OOじゃ無い人なんて存在しないから
妄想書かないでね。

537 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 20:20:13
ぷっ これでオブジェクト指向のつもり?www
ってなのばっかりだけどな 

538 :仕様書無しさん:2007/01/18(木) 20:22:31
>>536
いや、その発言には賛同しかねる。

539 :仕様書無しさん:2007/01/18(木) 20:25:31
>>537

そういうのは、構造化プログラミングでも、
同じだったらしいよ、みんな、構造化できてるつもりで
スパゲティを作ってたって。

540 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 20:26:41
まず目に付くのは ライブラリをペタペタ延々と並べていってるの
次のソースもその次のソースもただライブラリをそのまま持ってきて延々と並べてるだけのやつ
構造がない
サブルーチンさえない。

センスのあるやつなら下位構造から上位構造までピラミッドみたいな全体図をもってるわけだが、
この手の人たちは一階建ての街を延々と建設するわけだ。

541 :仕様書無しさん:2007/01/18(木) 20:35:43
だからなんなのよこのキモコテ

542 :仕様書無しさん:2007/01/18(木) 20:58:23
市況板の名物でつ

543 :仕様書無しさん:2007/01/18(木) 21:10:36
引き取ってくれ

544 :仕様書無しさん:2007/01/18(木) 21:13:11
>>537
そら君のいる環境がそうなんだろう。
或いは、「類は友を呼ぶ」。

545 :仕様書無しさん:2007/01/18(木) 21:27:01
少なくとも、クラス図とシーケンス図の作成に自信のある人いますか?
日本に何人くらいいるだろうか?
それがこのスレの答えだと思うが・・・・・。

言わなくてもわかってもらえると思うが、クラス図は、
インターフェースをバリバリバリューに使ったものであること。
両図とも、PGがそのままコーディングに持っていけるレベルであること。

546 :仕様書無しさん:2007/01/18(木) 21:32:17
今時、クラス図シーケンス図ぐらい誰でも書くよ


547 :仕様書無しさん:2007/01/18(木) 21:37:07
>>546
が嘘つきでないなら、オブジェクト設計屋はわんさといて繁盛しているはずだが、
全く見かけないのは、やっぱ中小に居るからですか?

548 :仕様書無しさん:2007/01/18(木) 21:40:03
>両図とも、PGがそのままコーディングに持っていけるレベルであること。

バカバカしい。
UMLの教科書にも、いろんな開発プロセスの本にも、オブジェクト指向の解説本にも
UMLで全部やろうとするなって書いてあるだろ。
完全なモデルを作成するのなんて不可能だし、そもそもUMLじゃプログラミング言語の機能を全然表現できないんだよ。



549 :仕様書無しさん:2007/01/18(木) 21:40:59
>>547

大手だよ、みんなオブジェクト設計屋だから
ことさら、流行ったりしない。呼吸することが
流行と言わないのと同じだよ。

550 :仕様書無しさん:2007/01/18(木) 21:45:57
たいていの人は走ることができるがお金がもらえるほどに走れる人はどれだけいるだろうか?


551 :仕様書無しさん:2007/01/18(木) 21:49:40
>>550
たしかに興味のある質問です。
>>549さんあたりに答えていただければ幸いですが・・・

552 :仕様書無しさん:2007/01/18(木) 21:51:39
>>550

その感覚なら、正しいと思うけど
それは、他の設計方でも同じこと、
たとえば、低レベルのフローチャートでさえも
きちんとした物を書ける人は少ない。



553 :仕様書無しさん:2007/01/18(木) 21:52:12
西日本にいるものですが、東京ではオブジェクト設計は流行っていますか?

554 :仕様書無しさん:2007/01/18(木) 21:52:42
ココ電いますか?

555 :仕様書無しさん:2007/01/18(木) 21:55:25
>>553

クラス図、シーケンス図レベルでいえば
流行ってるいうより、あたりまえ
大抵ユースケース図も書いたりしてる。

556 :仕様書無しさん:2007/01/18(木) 22:02:15
クラス図シーケンス図なんてそりゃ書こうと思えば書けるが、
UMLで書いたってオブジェクト指向になってない奴はいっぱいいるし、
酷い設計は酷い設計でしかないの。
なんでそんなたかが表記法に熱心なのか。

557 :仕様書無しさん:2007/01/18(木) 22:08:43
なんか、至高とか、究極のオブジェクト指向があって
それでなければ、オブジェクト指向じゃ無いと言うような
人がいるみたい、本来、オブジェクト指向なんて
そんな大層な物で無いのに、誰でも普段から自然にやってること


558 :仕様書無しさん:2007/01/18(木) 22:08:58
>>556
ホントだよ。
設計糞なのにレタリングだけやたら凝ってる図は殺意さえ芽生えるってことを全員が自覚するべき。

559 :仕様書無しさん:2007/01/18(木) 22:10:19
個人的な意見ですが、ユースケースのシナリオは従来からあるようなもので
すから、わたしも使うというか、自然な気分で使っています。
でも、ユースケース図は、利点もあるのでしょうが、頭の中がごちゃごちゃ
するので使いません。
局所的に使うことはありますが。

560 :仕様書無しさん:2007/01/18(木) 22:10:41
>>557
それはこの↓内容に反してはいないだろうな。

http://ja.wikipedia.org/wiki/Simula
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、
というものである。気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。

俺はオブジェクト指向原理主義者だからこの定義には厳しいぞ。
デザパタなんて一切認めん。

561 :仕様書無しさん:2007/01/18(木) 22:11:21
>>559がユースケサンタマリア投入

562 :仕様書無しさん:2007/01/18(木) 22:13:31
>>560

それは、あくまでShimulaの開発動機だから、
Shimulaは、オブジェクト指向を目指して作られたものじゃ無いから


563 :仕様書無しさん:2007/01/18(木) 22:13:49
で、なに?
クラス図、シーケンス図、ユースケース図こんなに無駄な作業いるの?
てか、いつになったら組んでいいの?
実は実装すりゃ今頃おわってんじゃねーの?
まだ、なんか書くの?
はやくしてよ。
もう、俺のPCには完成品あって、あと出すだけなんだよw

564 :仕様書無しさん:2007/01/18(木) 22:14:37
>>562
そんなの原理主義者の俺に通じる道理ではないな。
それにそんな無駄な文章書いてるってことはちゃんと読んでないだろ?

565 :仕様書無しさん:2007/01/18(木) 22:15:54
>>560の言うオブジェクト指向の定義ってそれ?定義なのに例しか無いじゃん。
ちっと勉強足りないよ。smalltalkとeiffelの勉強してから原理主義者名乗んなさいな。

566 :仕様書無しさん:2007/01/18(木) 22:16:12
>>563

どんなに小規模な開発だよwwwww


567 :仕様書無しさん:2007/01/18(木) 22:17:00
>>565
はぁ?読んでネーのまるわかりw
よんでねーのにレスつけんなボケ。

568 :仕様書無しさん:2007/01/18(木) 22:17:12
>>560

ぶっちゃけ、あんた、どうでもいいから

569 :仕様書無しさん:2007/01/18(木) 22:19:59
>>566
逆に俺はそんなデカイ開発にかかわったことが無いな>クラス図、シーケンス図、ユースケース図
そもそもクラス図すらお目にかかったことがない。
DBの帳票が詳しくかかれているか、エクセルを印刷した紙に手書きで「○←このへんに●●関係おいて」って
書いてある現場が日常茶飯事だった・・・マジで。

570 :仕様書無しさん:2007/01/18(木) 22:21:13
>>563

そんな君には、アジャイルソフトウェア開発手法
ああ、どこかに、XPでの開発ないかなぁ

571 :仕様書無しさん:2007/01/18(木) 22:21:34
>>568
なんだと。
オブジェクト指向の原点だってのにそっちを無視して、
エセPGのいうことなんて信じるのか?
もうお前なんか一生オブジェクト指向理解できなきゃいいんだ。

572 :仕様書無しさん:2007/01/18(木) 22:22:07
       _ / '"  '"―-- 、__
      _ヽ`'            \
    ,.:'"                \
    /                   ヽ
   /    ,イ                 i
  ./   ノ、i.|i     、、         ヽ
  i    | ミ.\ヾヽ、___ヾヽヾ        |
  |   i 、ヽ_ヽ、_i  , / `__,;―'彡-i     |
  i  ,'i/ `,ニ=ミ`-、ヾ三''―-―' /    .|  
 .iイ . | |' ;'((   ,;/ '~ ゛   ̄`;)" c ミ     i
  .i  .i.| ' ,||  i| ._ _-i    ||:i   | r-、  ヽ、
 丿. `| ((  _゛_i__`'    (( ;   ノ// i |ヽi
/    i ||  i` - -、` i    ノノ  'i /ヽ | ヽ
'ノ    i ))  '--、_`7   ((   , 'i ノノ  ヽ
      Y  `--  "    ))  ノ ""i    ヽオブジェクト指向やってると 早く家に帰れない
     ノヽ、       ノノ  _/   i     \
    /ヽ ヽヽ、___,;//--'";;"  ,/ヽ、    ヾヽ

573 :仕様書無しさん:2007/01/18(木) 22:25:42
>>569

微妙に可哀想な気もするが
保険業界のシステムとかで、命擦り減らすより
増しなんだろうな。

574 :仕様書無しさん:2007/01/18(木) 22:26:40
オブジェクト指向の原理主義ってあるね。
で、近づきたくないね。
昔、知らないでその手の本を読んで馬鹿になりかけたよ。
最近といっても2000年以降だけど、実用本が出始めて俺は救われました。

575 :仕様書無しさん:2007/01/18(木) 22:29:18
560みたいななんかよくわからん文学的かつ曖昧な定義は
定義とは言わない。個人的に。偉い人の発言だったとしても。

オブジェクト指向について厳密に意味論を定義しようと
思うと難しいよ。そんなのできたら研究所で働けるよ。

Featherweight Javaやオブジェクト算法といった計算モデルや
F-logicとかつかってがんばればできるかも。俺には無理だ。

つーか、オブジェクト指向って理論的な面では研究が遅れているね。



576 :仕様書無しさん:2007/01/18(木) 22:29:42
>>574
なんだと。
俺のオブジェクト指向のオススメ書籍は憂鬱本だけだ。
他も色々読んだがこれが一番原理主義に近い。
図とか書くような解説もしてあるが、そこは別になくていいと思う。
この本の前半のオブジェクト指向の説明は正に神といっていい。

577 :仕様書無しさん:2007/01/18(木) 22:31:42
>>575
なにいってんだボケェ。
感覚で理解しろよ。
リンク先はいい説明してるじゃねぇか。
オブジェクト指向だとシミュレーション作り易そうじゃねぇか。
そんな気にさせる文章じゃねぇか。
その感覚がオブジェクト指向を覚えるってことだろうが。
考えるな!感じるんだ!

578 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 22:34:39
>>554
今来ました

579 :仕様書無しさん:2007/01/18(木) 22:36:37
キターーーーー

580 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 22:39:16
オブジェクト指向のファシズムが吹き荒れてた2000年ごろ
マ板だかム板だか忘れたが「オブジェクト指向逝ってよし」というスレを立てて最初の反旗を翻したのは私だ。
マ板でも古参コテなのでいじめないように

581 :仕様書無しさん:2007/01/18(木) 22:40:16
俺はオブジェクト指向設計ってよく知らないんだけど、UMLのユースケースは
図にする意味は分からんが要求機能の一覧だってことは分かる。
でも、そこからどうやったらクラスやオブジェクトが切り分けられて、きちんと
動くプログラムが論理的に設計されていくのかという過程の理屈がさっぱり
見えないんで、分かる人がいたらぜひ説明してもらいたいな。

582 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/18(木) 22:45:21
UML図の中にフローチャートを書けば完成じゃね?

583 :仕様書無しさん:2007/01/18(木) 22:49:33
>>582

オブジェクト指向がわからんのは、別に構わんが
モジュール分割とインターフェイスの設計ぐらいはしろ


584 :仕様書無しさん:2007/01/18(木) 22:57:44
コテは失せろ

585 :仕様書無しさん:2007/01/18(木) 23:12:26
だからさ、英語の文書の書き方を語りたいのに、単なる単語の表記を語ってるようなもの。
UMLなんて単なる表記の一種、オブジェクト設計とはなーんもかんけーない。


586 :仕様書無しさん:2007/01/18(木) 23:22:37
中身を知らないことが手に取るようにわかる頭悪いレスだな

587 :仕様書無しさん:2007/01/18(木) 23:26:08
ずーっと上の方でも書いたが、開発プロセスと設計技法を混同している人がホント多いのよ。
ウチの社にもいるのだが困ったことだよ。
放置しておくと「ウォーターフォールでオブジェクト指向なんて無理」とか言い出すしね。

例えばRUPではUMLの利用はほぼ必須だが、オブジェクト指向なんてひと言も書いていない。
UMLはただの書式(言語というとオレは抵抗を感じるので)。それで何をやろうが自由。
オブジェクト指向とはなーんの関係も無いのよ。

588 :仕様書無しさん:2007/01/18(木) 23:30:03
>>585
それはちがくね?ウチも組み込み機器の動作仕様をユースケースシナリオでも
書くし、ハード配置を独自のコンポーネント図で書いたりする。
RTOS内のタスク間通信は当然シーケンス図を使って書く。
そういうのは、まさに「もの」であるから、オブジェクト設計と呼べると思うけど。

その先の実装はアセンブラ20%、C言語80%で構造化プログラムオンリーだがね。
流石にクラス図は辛い。

589 :仕様書無しさん:2007/01/18(木) 23:30:06
論理学は普通、文法論(syntax)と意味論(semantics)の2つの側面から語られる。
同様にプログラミング言語も文法論と意味論で語られることが多い。
論理学およびプログラミング言語について理解するには、文法論も
意味論もどちらも重要。

つーのは当たり前だと思ったが、どうか。

UMLはオブジェクト指向の文法。UMLの文法を研究することで、それに
対応したUMLにおけるオブジェクト指向の意味が見えてくる。




590 :仕様書無しさん:2007/01/18(木) 23:37:08
UMLのうちクラス図がオブジェクト指向と相性がいいのは間違いない。
だが、
>UMLはオブジェクト指向の文法
これは間違っている。UMLはあくまで単なる表記法。構造化手法を念頭に置いて
使うこともできるし、オブジェクト指向にもなる。

591 :仕様書無しさん:2007/01/18(木) 23:38:29
オブジェクト指向でウォーターフォールはかなり非効率だ。
なぜか。
オブジェクト指向ではシステムをオブジェクトの相互作用で表現するわけだが、
オブジェクトの相互作用をモデリング言語で表現するのがかなり難しいからだ。


592 :仕様書無しさん:2007/01/18(木) 23:40:33
>>587
じゃあ実際にみんなどんな方法を使って設計してるの?
旧来の構造化手法やDOAを使ってるのか?それともOOAやOODとやらを使ってるのか?
そこが知りたい。

593 :仕様書無しさん:2007/01/18(木) 23:42:30
>>569 と同じ境遇の俺。
>>573 のいうことがちょっとだけありがたい。(周囲は保険業界のシステムで炎上中)

小規模開発(SE兼PGみたいな)場合、
小さなな変更がちょくちょくあるから、個人的にはOOP/OODのが断然やりやすい。
構造化設計しちゃうと、共通化していた部分が「えー?片方だけちょっと変えてくれ?」
というようなことが起こりやすい。

妙な派生クラスが増産されるのがいただけないが、
ユーザの機嫌を無意味に損ねることは回避できる。


594 :仕様書無しさん:2007/01/18(木) 23:42:40
そうです。
UMLは一般に利用されるものです。
上で誰かが書いてましたが、クラス図はオブジェクト指向にピッタリです。
たぶん、クラス図、シーケンス図はオブジェクト設計を意識してUMLに入れた
のではないでしょうか。

595 :仕様書無しさん:2007/01/18(木) 23:44:40
>>585
アメリカ人向けの法律を日本語で書くのもどうかと思うが。
(UMLは一応オブジェクト指向設計向け言語だし)

596 :仕様書無しさん:2007/01/18(木) 23:45:38
派生(継承)は気をつけて使う。
合成(コンポジション)を多用する。

597 :仕様書無しさん:2007/01/18(木) 23:45:51
どんな開発手法であれ、ウォーターフォールが非効率的になるケースが多いのは
数多くの事例が証明しているのだが。
それとオブジェクト指向は全く関連が無いよ。

因みにウォーターフォールがうまくいく(効率良く)条件は、
・比較的長期間のプロジェクトであること
・統率のとれた組織体であること
・各フェーズの役割と生み出される成果物が、末端にまで周知されていること
・変更要求は通常のタスクとは別次元で管理できること

598 :仕様書無しさん:2007/01/18(木) 23:46:29
>>587
>放置しておくと「ウォーターフォールでオブジェクト指向なんて無理」とか言い出すしね。 

そいつの本音は「ウォーターフォールでソフトウエア開発なんて無理」なのだと思う。



599 :仕様書無しさん:2007/01/18(木) 23:47:12
OMGがそれ向けの設計書としてUMLを推奨推進してるのがUML
C++でCのAPIだけ使って開発しようが知ったことではないが
C++はオブジェクト指向と何の関係もないとか馬鹿にしか理解できない理屈だよな

600 :仕様書無しさん:2007/01/18(木) 23:48:02
>>588
設計手法ってのは、その図面を書くために動かす脳みそを論理的に説明というか手順化なり理論化したもの。
UMLなり他の書式・表記は、あくまでその考えた結果を相手に伝えたり記録するためのコミュニケーションツール。

だから、UMLできます。って威張る人みると、だから?って言いたくなる。


601 :仕様書無しさん:2007/01/18(木) 23:52:57
UMLをオブジェクト指向以外につかっても全然問題ないわけですが。
さらに設計がオブジェクト指向で、実装がそれ以外でもいい。

UMLは言語の一種で、プログラミング言語の仲間でOOPLの親戚と
言っていい。例えばC++のようなプログラミング言語を手続き型
の使い方をしてもいいし、C言語でオブジェクト指向的なプログラミング
をしてもいい。これはUMLも同様。

ただ、UMLに関しては、仕様書でSemanticsが定義されている。
これを読めば「UMLが」想定している、定義しているオブジェクト指向が明確になる。
なのでUMLの深いところを理解すれば(通常はUML利用者は理解する必要が
なく、UMLの設計者だけ知っていればいいと言われる部分)、UMLに
おけるオブジェクト指向が見えてくる。これは恐らくもっと大きな枠の
オブジェクト指向の概念のサブセットになっているはず。


602 :仕様書無しさん:2007/01/18(木) 23:54:10
>UMLはオブジェクト指向の文法

こういうことを本気で言うヤツがいるから、ユースケース図とオブジェクト指向を
結びつけてしまう人が必ず出てくる。
UML自体はオブジェクト指向とは無関係。

ただし、オブジェクト指向設計をする上でクラス図は無くてはならないもの。
クラス図はUMLに取り入れられているから、確かに「オブジェクト指向はUMLで」
というのは間違いではない。
だが、UMLの図の中で実際にオブジェクト指向設計と純粋に関連するのは
・クラス図
・シーケンス図
・オブジェクト図
だけ。

603 :仕様書無しさん:2007/01/18(木) 23:55:20
つまり、UMLを読み解けば、少なくともブーチやヤコブソン、ランボーが
考えるオブジェクト指向がわかるってこと。


604 :仕様書無しさん:2007/01/18(木) 23:56:06
603は601の発言です。

605 :仕様書無しさん:2007/01/18(木) 23:58:38
OMGの仕様書の「Unified Modeling Language: Superstructure」、P8、9、10を見れ。



606 :仕様書無しさん:2007/01/18(木) 23:59:15
UMLと一括りにするから混乱するのだな。
実際にオブジェ設計やってるオマエラ、せいぜい書くのはクラス図とシーケンス図程度だろ?
オレも他にはたま〜にステートチャートを書くくらい。
ユースケース図などまったく知らん。

607 :592:2007/01/19(金) 00:01:49
UMLがオブジェクト指向と関係あろうがなかろうがどうでもいいから>>592に誰か答えてよ(;o;)

608 :仕様書無しさん:2007/01/19(金) 00:02:33
>>606
おう。そーだぞ。

609 :仕様書無しさん:2007/01/19(金) 00:03:45
>>605
なんでこのスレでOMGの仕様書まで出てくるんだろう?
盲目的に「長いものには巻かれる」タイプの人かい?
積極的にCORBA使ってんの?
結局そういうハナシと同じだぜ。

610 :仕様書無しさん:2007/01/19(金) 00:03:49
>>607
そんなの良いとこ鳥のごっちゃまぜだよ。
業務系だとRDBを使っている限り、オブジェクト指向設計だけじゃ駄目だし。

611 :仕様書無しさん:2007/01/19(金) 00:05:35
そのいいとこって奴の具体例を出してくれって言ってんだよぉぉおぉおお

612 :仕様書無しさん:2007/01/19(金) 00:07:37
>>611
銀の男根は無いんだよ。

613 :仕様書無しさん:2007/01/19(金) 00:09:32
>>597
>ウォーターフォールがうまくいく(効率良く)条件は、 

俺の知っているウォーターフォールがうまくいく条件

1.プロジェクトに期限を設定しない
2.線表はプロジェクトが終わった後に引く
3.多数のプロトタイプを作成した後にプロジェクトを開始する
4.設計段階では、設計書には罫線と日付だけを書いておく。
 その後、プロジェクト終了直前に「ドキュメントのメンテナンス」
 と称して、おもむろに本文を書き込む
5.結合テスト時のバグのために根本的な設計変更を行っても、
 記録上、それはただの「デバッグ」作業となっている


614 :仕様書無しさん:2007/01/19(金) 00:09:42
>609
言葉には意味が伴うように、表記法には必ず意味が付いてくる。
日本語の意味がわからないときは国語辞典で調べるように、
UMLの意味が知りたければOMGの仕様書を読むのが間違いないということ。

ただ、オブジェクト指向の観点からOMGがすべて正しいとは限らない。
正しいのはUMLにおける定義についてだけ。

615 :仕様書無しさん:2007/01/19(金) 00:11:25
>>606
ユースケースとクラス図を何度も往復して概念モデルを練り上げていく。
これがオブジェクト指向「分析」。

616 :仕様書無しさん:2007/01/19(金) 00:11:28
OOA/OODは名前だけは有名だけど、実は誰も使ってないし誰もその実態を知らないんだろ。

617 :仕様書無しさん:2007/01/19(金) 00:12:35
そりゃ根本的に設計能力のない奴が文法だけ覚えてもな。

618 :仕様書無しさん:2007/01/19(金) 00:14:18
オブジェクト指向分析や設計でいい本なんてあったか?アナリシスパターンとか?

619 :仕様書無しさん:2007/01/19(金) 00:15:46
>>615
それってつまり設計者のカンに頼って行き当たりばったりでやってるだけなんじゃ…

620 :仕様書無しさん:2007/01/19(金) 00:15:58
まあオレはOMGの仕様書など読んだことが無いが、UMLありきで話をするからややこしくなるんだな。
ここで問題、UMLとクラス図、どっちが先にできたでしょーか?

答:クラス図

UMLはその名のとおり、それまでバラバラだった表記法を「統一」しようとした
ことがきっかけで生まれたもの。それ以前からクラス図というのはあったし
オブジェ設計にも使われていた。

UMLを真剣に活用したい人はOMGの仕様書は読むべきだろうが、単にオブジェクト
指向による設計をするだけならそこまで必要ないというのはオレの個人的見解。

621 :仕様書無しさん:2007/01/19(金) 00:20:36
>>619
通常「分析」なんてフェーズないんだから、それよりマシ。

622 :仕様書無しさん:2007/01/19(金) 00:22:18
>>618
俺的には未だに「オブジェクト指向開発の落とし穴」かなあ
慣れで忘れかけてることを思い出させてくれる名著

623 :仕様書無しさん:2007/01/19(金) 00:27:12
>>621
構造化分析みたいに要求仕様から機械的にシステムが分割されていく
物凄い手法かと幻想を抱いてた。

624 :仕様書無しさん:2007/01/19(金) 00:34:09
構造化設計はコンピュータ的な思考だから、そのテの人にはおそらく楽なんだと思う。
それに対してオブジェクト指向分析ってのはモデリングがすべて。
これはコンピュータ的ではなく、むしろ社会学的な能力が必要。絶対に世間知らずな
兄ちゃんには無理。

ただしそのモデリングというのも、オレの経験上では制御系には比較的適応させ易い
けれども、上の方で誰か書いてたように業務系のRDBとはことごとく相性が悪い。
おそらく皆(オレも)ここでハマるんだろうなあ。

625 :仕様書無しさん:2007/01/19(金) 00:35:42
付け足し。

「モデリング」とは決して絵を描くことではないよ。念のため。

626 :仕様書無しさん:2007/01/19(金) 00:40:36
データベース関係なんかでも、正規化のような機械的にできる設計
(これがすべてではないが)があったり、むしろ古い手法の方が
数理的、システマチックな手法が多いよね。

アジャイルとかもそうだけど、人間中心の手法が多くなっているよね。
時代が進むとどんどんシステマチックじゃなくなっていって、
かつ効率的になっていくのがソフトウェアの進化じゃないだろうか。
他の分野に比べるとかなり変わっているよね。進化の方向が。

だいたい、ソフトウェア開発をやっている人間って、時代とともに、

数学者

ハッカー

専門家

普通の人

というように遷移しているので、どんどん社会性が求められてきて、
あんまり堅苦しいやり方は好まれないんじゃないだろうか。


627 :仕様書無しさん:2007/01/19(金) 00:40:45
>>623
構造化分析において要求仕様そのものは前提であるのに対して、オブジェクト指向分析は
要求仕様そのものの妥当な姿を追求する。
と、俺は勝手に思っている。

628 :仕様書無しさん:2007/01/19(金) 00:45:24
>>621
「分析」と称する会議が多すぎる件 orz

>>624
業務系のRDBとの相性の悪さってのは、ooやればやるほど痛感するな。


629 :仕様書無しさん:2007/01/19(金) 00:47:02 ?2BP(300)
>>1
オブジェクト設計という手法はどうでもいいの!
低コストで開発できるかどうかが重要なわけ。
儲かれば何でもいいのよ。
逆に、クラス図とかをこまごまと悠長に設計されていては会社としては困るわけ。
少なくとも、会社の上層部には理解されないのw
理論的に素晴らしいかどうかなんて関係ないの。 わかるかな?

630 :仕様書無しさん:2007/01/19(金) 00:49:03
>>629
理論的に正しいかどうかの件だけは別として、
設計工程を軽視するような会社はDQN。

631 :仕様書無しさん:2007/01/19(金) 00:49:14
>業務系のRDBとの相性の悪さ
最近はORMのノウハウも増えてきたから特に問題ないんじゃないの?

632 :仕様書無しさん:2007/01/19(金) 00:51:41
>>627
同意。結局人間の要求でしかないから整合性が取れてるなんてことは
まずないし、要求を満たすことで予測できない事態になることも多々。
予測力のない奴は分析なんかできない、と俺は思ってる。

633 :仕様書無しさん:2007/01/19(金) 00:54:50
>>631
そうかもしれないな。

>>632
スレチだが、要求の非整合を調整しようとすると、
机をすぐ蹴り飛ばす客にはどうしたらいいんでしょw

当然設計が暗礁に乗り上げ俺が10人目くらいのPLだった頃の話。

634 :仕様書無しさん:2007/01/19(金) 00:55:25
>>629
確かに企業は儲かってナンボだろうけど、技術屋は技術を磨き続けるのも使命。
それを理解しない経営者には決して優秀な技術者は付いてこないから、いずれ
企業としての価値が無くなるのも時間の問題。

635 :仕様書無しさん:2007/01/19(金) 00:55:48
つか今気づいたんだが、ORMでマップするものってOOA/OODの成果物なわけだよな。
少なくともJava界隈ではORMのフレームワークはかなり流行していると思うんだが、
これって逆に考えるとOOA/OODがかなり一般的に行われていることの証左と思うんだがどうよ?

636 :仕様書無しさん:2007/01/19(金) 00:57:17 ?2BP(300)
>>627
要求仕様は、構造化分析だろうが、オブジェクト指向分析だろうが必須だと思う。
ただし、要求仕様の検討に、オブジェクト指向を持ち込むというのはあるかもしれん。

637 :仕様書無しさん:2007/01/19(金) 00:57:23
> ORMのフレームワークはかなり流行

流行しているように思う。ただしまだ比較的大規模なものの場合。
ちょっとうらやしく眺めるだけの俺ガイル。

638 :仕様書無しさん:2007/01/19(金) 00:58:38
で、馬鹿正直にORM使うとパフォーマンス問題に直面するわけ。

639 :仕様書無しさん:2007/01/19(金) 00:59:28 ?2BP(300)
>>634
そういう会社をマジ紹介してくり・・・

640 :仕様書無しさん:2007/01/19(金) 01:00:05
>>636
要求仕様の検討にシーケンス図は便利だよ。

>>638
OTZ

641 :仕様書無しさん:2007/01/19(金) 01:00:47
>>633
俺はそれほど酷いのには会ったことないなあ。
運が良かっただけかも知れんがw
まず基本は「筋が通ってないでしょ?」的な話を先にしないこと。
代替案を出すのが先なんじゃないかな。「こうすれば、もっと
良くなる」的な。まあ、多少のゴマカシは必須w

642 :仕様書無しさん:2007/01/19(金) 01:06:55
>>633
思考より先に感情が動く人には何やったって無理。その人自身がそのクセを
直そうとすること、それにはまず自分を客観的に見るようにするしかないと思う。

ひとつ手があるな。
そいつがホレそうな女にしゃべらせる。エエカッコ見せようとすると、それほど
無茶なことも言わないんじゃないか。

643 :仕様書無しさん:2007/01/19(金) 01:09:06
問題点を指摘されると自分が責められてるように感じる
人間も多いからなあ

644 :仕様書無しさん:2007/01/19(金) 01:16:24
>>641-643
ありがトン。
正直、エンジニアの仕事とはかけ離れたことなので。


645 :仕様書無しさん:2007/01/19(金) 01:22:15 ?2BP(300)
>>640
オブジェクト指向などない時代から、
要求仕様にシ〜ケンス図は付き物だったぉ
まぁ、ちょっと視点やレベルが違うかもしれないけど・・・

646 :仕様書無しさん:2007/01/19(金) 01:27:45
>>645
分析フェーズでシーケンス図ってどうやって使うのかよく分からないなあ。

647 :仕様書無しさん:2007/01/19(金) 01:47:51
>>646
シーケンス図とかでググるといろいろあったよ。

648 :おじゃばさま:2007/01/19(金) 09:57:06
開発手法と設計は別の物と言われている。確かに別の物であるが、俺は密接に関係していると思う。
開発手法としてはウォーターフォールとかプロトタイプとかあるが、実はここに基本的な誤りがある。
それは「設計図」と「完成品」の認識の違いである。

例えば飛行機を作るとしよう。
”設計図を書いて試作品を作る。テスト飛行を繰り返し完成品となる。”
まあ、新しく作るならこんな感じになる。
これをソフトウェアに当てはめるとする。
ここで多くの人は「設計図=仕様書」「完成品=ソースコード」と考えるだろう。
”つまり、仕様書を書く。仕様書レビューを繰り返して完璧にして、ソースコードを作る。”
一見正しく見えるが、多くの開発経験者はそれでもうまく行かない事は経験済みだろう。
そして仕様書レビューが不十分だとして、無駄なレビューを繰り返す。
そして設計が悪いとか、オブジェクト指向がいいとか、SEが馬鹿だとかの話になる。

しかし最初の定義を変えたとする。
「設計書=ソースコード」「完成品=実行コード」としよう。
”ソースコードを書き、試作品を作る。試験を繰り返し完成品となる。”
この方法では失敗しない。まあ、問題がなくなるまで試験するのだから、当然と言えば当然だ。

つまり、要求仕様書をもらったら、即コーディングを始める。
外部インターフェース仕様書は作らずにソースコード(スタブまたは使用箇所の抜粋)を渡す。
DB仕様書も作らずにSQL文を渡す。プログラマ同士のやり取りはソースコードのみ。
どうしても客に見せる必要のある書類のみソースコード作った後に作る。
早急にテストを繰り返して完成品とする。
これが正しい開発方法であろう。


649 :仕様書無しさん:2007/01/19(金) 10:24:25
まあ、その程度の規模しかやってないならそれでいいんじゃないの?
5人以内、半年以内ならまあ出来そうだけど。
あと、他システムとのI/Fが無いとか。

650 :仕様書無しさん:2007/01/19(金) 14:41:04
>>648
>つまり、要求仕様書をもらったら、即コーディングを始める。

VBとかでスタンドアロン、単機能なアプリなら可能だろうが、
WEBアプリになればまず無理だな、漏れの場合。

651 :おじゃばさま:2007/01/19(金) 19:34:03
何で無理?
Javaのパッケージや、C++のネームスペースが適切に使われていれば出来るよ。でかくても関係ない。
出来ない原因は、これをやるとお年寄りのSEが怒るからだろう?
「バグが出ないように仕様書を作れ」だの「誰でもコーディング出来るように設計しろ」とか言うよな。
でも仕方ない。そういう人は多いし、人を選べない場合も多いからな。
だから内部ではこれで進めて、外部向けにはソースから仕様書おこして、表面上合わせればいい。

この手法は実は新しい物ではない。
驚くべき事に1992年にこれと同じ事を言った記事がある。
ttp://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html

一般に言われる「プロトタイプ法」「スパイラル法」「エクストリーミングプログラミング(XP)」
「アジャイル」なども、実はこの方式をお年寄りに認めさせるための方便であり、目的は同じだ。
またこれは構造化設計やオブジェクト指向など、ソフトウェア工学から出て来た話で、
決して小規模開発だけに限定した物ではない。
ソフトウェア工学というのは、品質のいいソフトをどれだけ効率よく開発するかと言う物である。


652 :仕様書無しさん:2007/01/19(金) 19:45:10
>>651
で、経緯はわかったけどそれがいい方法だってどうやって証明したの?
2〜3資料だしただけじゃロボトミーといっしょ。嘘かもしれない。
いや、10000の資料をもってきても信用できないな。
どういう理屈でそれがいい方法なのか?
って人を納得させる何かをいつも説明できない。
それが問題だ。
○○大学の権威が・・・ってのはもう長年使われて来過ぎてもう誰も信じない。
オオカミ少年もいいとこだろ?
○○会社の〜プロジェクトっていったって今度は有名過ぎて金注ぎ込み過ぎ。
そんだけ予算ありゃどうやったってうまくいくっつの?
だから例を出したら駄目なんだちゃんとどういう理屈でうまくいくのか?
これが説明できない。限りもう誰も説得なんてできる時代じゃないんだ。

653 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/19(金) 20:20:25
namespaceってオブジェクト指向に対する皮肉だと思うんだが・・・

654 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/19(金) 20:22:42
OO真理教
ひたすら人を見下すために存在する

655 :仕様書無しさん:2007/01/19(金) 20:27:53
あーところでちょっと聞いてみたいことがある。
あるところにDBとのやり取りを仲介してくれるDBManagerってクラスがあったとする。
で、他コンポーネントからもらったデータをAdapterで受け取って
Controllerってクラスがデータに応じた処理をやってDBManagerに渡してDBを更新するって設計があったとしよう。
シーケンスとしては
アクター → Adapter → Controller → DBManager
ってな感じになるわけだけど、これってオブジェクト指向って言えるかな?

これってさ、オブジェクトっぽいものが連携して処理を行ってるけど
実際にはトップダウンで処理を分解してってるだけでオブジェクト指向じゃないと思うんだが、
どう思う?

656 :仕様書無しさん:2007/01/19(金) 20:47:08
>>655
まず、実際の業務がわかんなきゃ話になんねー。

657 :仕様書無しさん:2007/01/19(金) 20:50:38
>>655
>アクター → Adapter → Controller → DBManager
の流れは、おっしゃるとおり別にオブジェクト指向だけで使われているわけでないね。
DBManagerの中に、インターフェースが使われていて、DBがOracleでもSQLSeverでも
その他いろいろなDBに対してもDBManagerを変更せずにそのDB用のクラスさえ追加すれば
いい様に作られているのがオブジェクト指向だね。

658 :仕様書無しさん:2007/01/19(金) 20:50:48
>>655
アプローチがすでにオブジェクト指向じゃないね。

659 :仕様書無しさん:2007/01/19(金) 20:53:14
>>657
そんなもん作ってもあんまり綺麗にはならん希ガス。
実行するSQL文からいって各DBで違うのにそんなもんおいてなんの意味があるのかと?

660 :仕様書無しさん:2007/01/19(金) 20:55:48
>>659
DBが何であってもそのメインのプログラムに一切変更を加えずに使える。


661 :仕様書無しさん:2007/01/19(金) 21:00:28
>>660
SQLで何かをする箇所が一番時間かかるところじゃねーの?
メインって別になんもねーじゃん。
あんま、メイン側と完全に分離してる意味ないと思うんだけど?
別にメインの方ってそんな大変じゃねーし。

662 :仕様書無しさん:2007/01/19(金) 21:03:54
あ、なんもねーってより、
1画面あたり期間いくらいくらでどうくんでもだれが組んでも
概ね予想を大きく外れることなく終わるって意味な。

663 :仕様書無しさん:2007/01/19(金) 21:35:04
>>662
別にオブジェクト指向で作ったほうがいいとかそういう話してないじゃん。


664 :仕様書無しさん:2007/01/19(金) 21:38:27
だから、すぐに枝葉の実装に逃げて、このスレをスレタイを読めないのが長文を書く。


665 :仕様書無しさん:2007/01/19(金) 21:42:10
RDBがあるかぎり、ORまっぷしようがそこがネックになる。
メモリー上に常にオブジェクトが活性化した状態で生息できるDBがあればいいんだけどね。
それでいて検索も俺が思ったとおりに出来て、すっぱやくて。


666 :仕様書無しさん:2007/01/19(金) 21:49:17
>>664
またおまえかよ。。
概念モデルとか設計モデルとかググって出直せよ。

667 :仕様書無しさん:2007/01/19(金) 21:54:09
DBってSQLのところでオブジェクト指向が生きてこない気がすんだよな。
複数のDB使うとどうしてもC言語的っていうかなんていうか。
でもDBごとわけるよりは同じ意味(用途?)のSQLを並べておきたいしな。

668 :仕様書無しさん:2007/01/19(金) 21:57:33
つORM

669 :仕様書無しさん:2007/01/19(金) 22:01:03
>>655
それぞれのクラスに「役割」が与えられた設計が成されていれば、広義のオブジェクト指向
と言えるとは思う。
ただこの場合の「本質」は何かと言えば、データを取り出したり変更したりすることだ。
そう考えると、ControllerとかDBManagerなんてのは取って付けたようなもの。
理想は>>665が言うようなことだが、やっぱ理想に過ぎないんだよな。

オレが何度もこのスレでRDBとOOが相性悪いと書いているのは、まさにこのこと。
さらに加えてデータの継承関係が不可能なこと。

670 :仕様書無しさん:2007/01/19(金) 22:04:23
>データの継承関係が不可能
http://www-06.ibm.com/jp/developerworks/java/050107/j_j-hibernate.html

671 :仕様書無しさん:2007/01/19(金) 22:22:02
DB部分なんて、オブジェクト指向だと自動生成のパーツじゃねーの?

672 :仕様書無しさん:2007/01/19(金) 22:24:12
>>665
それが必要なら、そーゆーオブジェクト作れよ・・。

673 :仕様書無しさん:2007/01/19(金) 22:30:58
>>671
それで出来る程度の単純なデータ構造だったらね。
ORマップツールの適用できる程度のシステムなんてたいしたシステムじゃないし。
データ構造が単純じゃないと駄目。

>>655
オブジェクト基地外。w
ODBって10年前からあるけど、流行らないし成功しないんだよ。
XMLデータベースもマイナー。

674 :仕様書無しさん:2007/01/19(金) 22:40:09
トップダウンになるのはソフトウェアをやっている以上しかたないよ。
統治分割が基本なので処理の流れを追いかけていくと、上層から複数の下層が
呼ばれる木構造になっているのが普通。そうしないと滅茶苦茶ファットな
クラスや関数ができてしまう。

もともとオブジェクト指向は構造化プログラミングの上に成り立っている
ので、構造化プログラミングを完全に排除するのは、根本的なところで間違ってる。
そもそも、オブジェクト指向開発でもレイヤ別けする開発はポピュラーでしょ。


675 :仕様書無しさん:2007/01/19(金) 22:49:26
自律オブジェクト指向ってのもあるけどな

676 :仕様書無しさん:2007/01/19(金) 22:50:38
完璧なプログラムを最初から目指そうとするのは、いいことだけど現実無理。

色々な書き方があるかな。

時間の問題もあるしな。

677 :仕様書無しさん:2007/01/19(金) 22:57:55
オブジェクト設計が流行らないのは、教育体制が悪いからだと思う。
最近の市販本は昔のものに比べてずいぶんよくなったが、現場で使える気にさせるような書き方じゃない。
研修の講師の人も、わからせる気がないんじゃないか?とか、
ほんとうにわかってるのか?という感じがする。

678 :仕様書無しさん:2007/01/19(金) 23:27:20
今度、わかりやすい本を書いて雑誌みたいな安い紙を使って300円くらいで出版してみようかと思うが・・・・。


679 :仕様書無しさん:2007/01/19(金) 23:32:20
そもそもオブジェクト指向設計って、従来の構造化設計に比べて何か強力なメリットは
あるのだろうか? それこそ経営層が喜びそうなやつ。
例えば
・生産性が上がる
・品質が良くなる
・保守性が高くなる
・納期が短くなる

多少という程度でなく劇的なインパクトが無い限り、新しい手法への移行など
進まないような気がする。
それこそがスレタイの答えになるのではないか?

680 :仕様書無しさん:2007/01/19(金) 23:36:35
OOP言語の方が非OOPの物より流行ってる以上
OOが流行ってないなど言うの寝言だな

681 :仕様書無しさん:2007/01/19(金) 23:43:25
>>679
工夫のしがいがあるのでオブジェクト指向のほうが
構造化設計より断然楽しい!
そういう意味では関数型でもいいんだけど、とにかく
毎日新しいことがしたい。

682 :仕様書無しさん:2007/01/19(金) 23:48:28
>工夫のしがいがあるのでオブジェクト指向のほうが
>構造化設計より断然楽しい!
>そういう意味では関数型でもいいんだけど、

言ってることが支離滅裂すぎて理解不能です><

683 :仕様書無しさん:2007/01/19(金) 23:50:45
デザインパターンの本に付いているCDのサンプルはいい教材です。
拡張性とかは、すぐに実感できました。
ただし、内容が幼稚すぎるのでもう少し業務よりのサンプルをお願いします。

684 :仕様書無しさん:2007/01/20(土) 00:07:21
>>681
楽しいじゃなくて、お金になるかどうかが問題なんだぞ。

685 :仕様書無しさん:2007/01/20(土) 00:07:54
>>655の設計って受け渡すデータそのものにメソッドを持たせるんじゃないの?
データクラスを設計するとこんな感じでさ。
public class Data extends DbManager
{
private Controller controller ;
// DataBaseを更新する
public void Update() {...};
public void SetData( int) {...};
public int GetData() {...};
}


686 :仕様書無しさん:2007/01/20(土) 00:10:30

このスレにいる人間は本当にプログラマなのか!!


687 :仕様書無しさん:2007/01/20(土) 00:10:57
OOがわかってない人たちで盛り上がっているね。
ヒントを言うと自転車の乗り方や泳ぎ方みたいなもんだよ。
でも、わかってしまうと話したくなくなるんだよ。
えらい遠回りをして辿り着いたのにタダでましてや2chで教えるわけないな。

688 :仕様書無しさん:2007/01/20(土) 00:12:25
>>684

安心しろ明らかにOOの方がお金になる。

689 :仕様書無しさん:2007/01/20(土) 00:13:27
>>685
そんなくだらない解説しなきゃわからないような設計ならどの道駄目だろ。

690 :仕様書無しさん:2007/01/20(土) 00:14:25
>>688
いや、残業代が増えるとかちっとも笑えないトンチではもうにこりともできなくなった。

691 :仕様書無しさん:2007/01/20(土) 00:16:01
>687
他人を見下すオブジェクト厨の典型w
「わかっているのは自分だけw」
オブジェクト厨のお仲間は何故かみんな同じように思っているよ。

なんでこういう人って勘違いしているんだろう。


692 :仕様書無しさん:2007/01/20(土) 00:17:10
おまえもなー

693 :仕様書無しさん:2007/01/20(土) 00:17:50
>>690

残業代が増えるのは見積りが悪いだけ


694 :仕様書無しさん:2007/01/20(土) 00:18:17
力関係が弱いだけ

695 :仕様書無しさん:2007/01/20(土) 00:20:12
どちらにせよ、OOとは関係ない
組込み系なんてOOじゃないけど、悲惨なもんだぞ

696 :仕様書無しさん:2007/01/20(土) 00:44:02
不定期なイベントを受け取って内部の状態を変化させていくモデルが表現し易いってのは、
SimulaやSmalltalkが生まれた経緯からして当然と言えば当然かな。

697 :仕様書無しさん:2007/01/20(土) 01:46:10
いくら有益でも、凡人に理解できない技術は発展しない。
凡人に理解できないと、人が集まらない。
人が集まらないと、仕事にならない。

698 :仕様書無しさん:2007/01/20(土) 02:34:40
このスレが流行ってる理由はなんすか?
マ板で伸びすぎw

699 :仕様書無しさん:2007/01/20(土) 02:40:03
なぜオブジェクト指向でなければいけないのか?
これに答えられる奴だけがオブジェクト指向を理解している

700 :仕様書無しさん:2007/01/20(土) 02:43:06
オブジェクト指向の中身云々より、技術者としてそれを知っておくことが重要だと思うんだ

701 :仕様書無しさん:2007/01/20(土) 02:53:01
>>699
出来る人が作ったフレームワークを利用し易いからでしょ。
答えられる奴だけが理解してるとかそんな御大層な理由はないよ。

702 :仕様書無しさん:2007/01/20(土) 02:56:34
>699-700
とりあえず税金払え

703 :仕様書無しさん:2007/01/20(土) 03:25:21
なぜ流行らないかというと、勉強するための本がないからです。

704 :仕様書無しさん:2007/01/20(土) 08:30:41
OOはメモリの無駄遣いだからです。

どうせ全体を理解できない・しようともしない、くせに
オブジェクト設計でエレガントなんて無理無理。

おまえらの仕様書は、完璧なオブジェクト設計の
結果が書かれているのかい?
仕様書に書かれてなければ、ただの突貫工事とかわらんぞ。



705 :仕様書無しさん:2007/01/20(土) 08:42:03
べつに完全である必要性は何処にも無いのですが。
OOなんて爺にはともかく、若者にはOOの方がわかりやすい
から、流行ってるにすぎません。

706 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/20(土) 08:46:41
オブジェクト指向で土日出勤して会社から書き込まれても説得力ないって

707 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/20(土) 08:50:49
ものじゃないものはオブジェクト指向では扱えないんだな
原理主義だと

708 :仕様書無しさん:2007/01/20(土) 08:51:26
仕事が無いからって妬んでるんじゃねぇよニート


709 :仕様書無しさん:2007/01/20(土) 08:51:35
だから、オブジェクト”設計”のすれです。
実装のミクロの枝葉の自分知識自慢はドッカイッテください。

710 :仕様書無しさん:2007/01/20(土) 09:31:37
>>709さんに100万票投入!!

711 :仕様書無しさん:2007/01/20(土) 09:33:19
実装できもしない設計など紙くず同然だ。
腐女子の妄想同人小説と同レベルのリアリティしかない。

712 :仕様書無しさん:2007/01/20(土) 09:33:54
プログラマー版じゃなく、情シス版に立てればよかったかもね。

713 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/20(土) 10:14:24
結論 

オブジェクト指向設計が流行らないのは実装を無視した関東軍の暴走みたいなものだから


ーーーーーーーーーーーーー 糸冬 了 −−−−−−−−−−−−−−−−−

714 :仕様書無しさん:2007/01/20(土) 10:17:02
しかし、実装は、OOP言語でやるので
実装に向いた設計をするとOODになるのは自明

715 :仕様書無しさん:2007/01/20(土) 10:22:46
設計は実装に依存するってわけだが。
本当にそれでいいのか?設計を実装する方法を模索するべきだよな

716 :仕様書無しさん:2007/01/20(土) 10:32:41
RDBを使って数億オーダーを超えるレコードを処理するシステムでは、
再利用性よりも保守性を重視したOODにならざるをえない。
それでも、ソース中のいたる所にSQL文を書き散らかされて、混乱する
ことだけは回避できる。それだけで十分。

717 :仕様書無しさん:2007/01/20(土) 10:35:16
>>715

結局、制約は、実装側にあるから、無理だな。
ハードから言語まで、PJ専用に新規開発できるなら、
少しは考えられるけど、ありえないから。

718 :仕様書無しさん:2007/01/20(土) 11:11:13
>>697
そもそも技術者ってのは凡人になれる職種じゃないってのに
どうしてこの業界は…

719 :仕様書無しさん:2007/01/20(土) 12:16:55
>>709
>実装のミクロの枝葉の自分知識自慢
だれもしてないとおもうけど。OOAとごっちゃになってるんじゃないの?

720 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/20(土) 12:31:25
絶対正義のオブジェクト指向の剣をかざす正義の戦士が悪のコボラーを退治しているつもりだろうが
傍から見るとオブジェクト指向って書かれた包丁を振り回して街行く人を無差別に襲ってるだけなんだな。

721 :仕様書無しさん:2007/01/20(土) 12:41:02
どうでもいいがその気持ち悪いコテ外せ
話はそれからにしよう

722 :仕様書無しさん:2007/01/20(土) 12:43:42
>>718 技術者も人間だから。

凡人になれる職種でないならば、
数を減らして高給にすればいいじゃん。

実際、高度な技術でないと遂行不可能なレベルの仕事は
超高給の能力主義ってのも無くは無い。

安い給料で半端なのを雇っても、
そちらの方がコスト安であれば、そうなるのが資本主義。



723 :仕様書無しさん:2007/01/20(土) 12:55:41
ハードウェアの設計はろくに勉強もしなかった奴には出来ないが、
ソフトウェアの設計は高卒でもできるって思われてるね。

724 :仕様書無しさん:2007/01/20(土) 14:12:21
>>723 別に回路設計だって、知ってるかどうかであって、

毎回0からスクラッチするようなプロの現場なんて、あまりないし
実際、そんんあ仕事はチームでやるから問題なし。

ソフトの場合は、大体雇い主が無能すぎる。
アニメーターの方がまだマシだわな。



725 :おじゃばさま:2007/01/20(土) 15:12:16
>652
それは俺の実績によって証明した。
あるプロジェクトで俺のチームと他の会社のチームの2つで開発した。
規模的に言えば両方とも10人6カ月ぐらいの規模だ。
相手チームは典型的な「ドキュメント重視型」。
俺のチームはスケジュール通りに完了。他のチームは納期にはコーディングが完了。
そりゃそうだ、6カ月のうち5カ月のは仕様書作り直してたのだから。
結合試験でもまともに動かずに結局納品まで6カ月遅延した。

次のは結構大きなプロジェクト。100人規模で10カぐらいのやつだ。
俺のチームは10人ぐらいで、サブシステムの1つをやることになった。
これもドキュメント重視。ただし俺のチームだけは例外的に俺のやり方を認められた。
簡単に言うと喧嘩してそこまで言うならやってみろって事になった。
俺のチームだけスケジュール通り。システム結合試験に間に合ったのは、俺のチームだけ。
次のチームが結合試験に入るまで1カ月の待たされた。
結局全チームが結合試験に入れたのは3カ月後だった。
暇な時間はドキュメント整理に使ったため、ドキュメントの完成度も高かった。


726 :仕様書無しさん:2007/01/20(土) 15:20:34
可哀想にとうとう妄想まで・・・


727 :仕様書無しさん:2007/01/20(土) 15:29:50
所詮アホコテだし。

728 :仕様書無しさん:2007/01/20(土) 15:30:05
コード書いて実際に動かしてみなかったらモデルがちゃんと動くかどうかどうやって確認するの?
アーキテクチャ検証だって、コード書かなきゃ出来ないと思うし。

だから分析・設計のフェーズは↓の流れになる。
実装→レビュー→実装→レビュー・・・→ドキュメント化

実装フェーズなんて、アセンブルしてデバッグするだけで稼動を使い切ってしまうし。

729 :仕様書無しさん:2007/01/20(土) 15:30:20
>>725
だから、そういう大人げ無い発言をやめろっての。
それで説得は無理だから。
実績なんて証明に使えないんだよ。
しかもレスの内容にしてもそれで何が説明できるのかまったく意味不明。

730 :仕様書無しさん:2007/01/20(土) 15:34:25
>>728
>コード書いて実際に動かしてみなかったらモデルがちゃんと動くかどうかどうやって確認するの?
全くだな。
紙面上でだけ矛盾がないことを確認するわするけど所詮人の目だな。
それで毎回戻りが派生してるしね。
流れぐらいは設計なんて無駄なことしてる間に組んじゃったほうが速い気がするけどなぁ。
そこからの細部のバグをとるのは結構時間食うけど、表面的に仕組みに矛盾がないことを確認する程度の
実装だったら組んじゃったほうが早いよなぁ・・・。
GUIアプリだったらフォーカスアウト時のチェックだの、画面遷移時の細かい動作だの気にしなきゃ組むのだけなら半月かからんこと多いしね。

731 :仕様書無しさん:2007/01/20(土) 15:35:54
ところでオブジェクト指向設計ってさ、抽象クラスを抽出して実装と抽象を分離するよな。
大規模開発でアプリケーション層の実装クラス群に依存するのってオブジェクト指向設計としてはダメだよな。
アプリケーション層を入れ替えるなんて不可能なんだが。


732 :仕様書無しさん:2007/01/20(土) 15:35:58
つーか任されたシステムが一番簡単だったとか
重要度が低かっただけだったとか色んなオチが考えられる以上
その程度の実績もどきで何を評価して欲しいのかわからん

これがウワサの糞コテクオリティ?

733 :仕様書無しさん:2007/01/20(土) 15:37:24
そうそいつこそうわさの糞コテクオリティ

734 :仕様書無しさん:2007/01/20(土) 15:37:30
>>651
2点、聞きたいことがある

1.
>だから内部ではこれで進めて、外部向けにはソースから仕様書おこして、表面上合わせればいい。 
それはその通り。なのに >>651 は、なぜそう出来ずに「喧嘩」になったのか?

2.
>>651 の手法が本当に上手くいったのならば、その現場(または会社)は
今後も >>651 の手法を真似ようとするはず。
で、実際にそうなったの?
ならなかったのならば、結局のところ、単に >>651 の扱いが上手かった
>> 651 の "上司(または客先)が優秀" だっただけじゃないの?

いわゆる「馬鹿と鋏は使いよう」って奴でさ・・・


735 :仕様書無しさん:2007/01/20(土) 15:39:34
>>728は素人だな
確かにテスト用な簡易検証コードは書くが、仕様実装レベルのものは書かない
低スキルな奴にそれを求めても無駄だからだ。スキルが無い奴ほど
>>728のサイクルをやりたがる。それをコントロールするのが俺様だ。
反面できる奴は簡易検証コードで報告してくる。こういう奴には任せても安心だ。
以上、経験から。


736 :仕様書無しさん:2007/01/20(土) 15:39:51
OOのおかげでDBのテーブルがすっきり木構造になってきたのが素晴らしい。
やっぱりデータの関係は1:Nだよな。

737 :仕様書無しさん:2007/01/20(土) 15:40:17
あ、もう1つあったな。。。ゴメン。

3.
>規模的に言えば両方とも10人6カ月ぐらいの規模だ。 
その数字の根拠は何?


738 :仕様書無しさん:2007/01/20(土) 15:40:56
>>732
そうそう。
背景に何があるかって大事だよな。
ただ、うまくいったうまくいっただけ連呼されてもな。

739 :仕様書無しさん:2007/01/20(土) 15:42:04
どっちにしてもオブジェクト指向で騒ぐ馬鹿共に優秀な技術者はいない
名物にうまいもの無しのようなものだ

740 :おじゃばさま:2007/01/20(土) 15:42:48
直接ソース方式を使えなくて失敗した例もある。
俺の上にドキュメント重視の上司がついた時だ。
作業内容を厳しく監視されたため、コーディングが出来なかった。コーディングすると怒られた。
まあ、試しにドキュメント重視でやってみるかとやってみたのが運の尽きだ。
一日の半分以上がドキュメントレビュー、残った時間がレビュー結果反映。
レビュー出席者に処理を説明するのに大半の時間を取られ、本当に決めたい所ではだれもついてこれずに
無言が続く。出席者の不意の疑問発言で中断することもしばしばあった。
ドキュメントの印刷と資料作成で土日がつぶれ、プリンタのトナーは切れて、コピー機が悲鳴を上げる。
誤印刷の廃棄でシュレッターが壊れ、新人が集められ人力シュレッターが行われた。
開発機関の80%が機能仕様書と詳細設計書の作成と再レビューに使われて、開発期間は削られた。
完璧な仕様書があればコーディングは簡単でバグがないとの意見から、
コーディング過程でプログラマ大量導入。期間の関係から単体試験は見送られた。
結合試験中に設計的な問題が大量発生。予算が尽き始めてプログラマ大量に外された。
ソースは勝手に修正され、ドキュメントとの相違は無視され出した。
残ったのは不完全な大量の仕様書と、だれが作ったかもう分からないソース。
度重なる納期延長で上の連中が次々に交代。結合試験後期には、予算は尽きて必要な人員まで外された。
結局俺の上司も外され自由に出来るようになったので、2カ月で作り直した。
まあ、俺がやってもドキュメント重視で方式では失敗するって事だな。

741 :仕様書無しさん:2007/01/20(土) 15:42:59
>>735
↑こいつなにいってんのかさっぱりわからないの俺だけ?

742 :仕様書無しさん:2007/01/20(土) 15:43:42
>>740
おい、もう、内容全然関係なくなってるからw

743 :仕様書無しさん:2007/01/20(土) 15:48:01
なぁ誇張表現は許してやるが
妄想はほどほどにしような?

744 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/20(土) 15:48:04
俺はハード設計もやってたから比較できるのでわかるけど
現代の工学一般では設計とは動作検証までを含むのが普通。

ところがソフトウエア工学だけ、動作検証を行ってない、「お絵かきの絵」を設計と称して下に下ろしてくる。
これがほとんどすべての問題点の原点だろう。
コーディングと動作検証までを設計に含めればすべて解決する。

コーディングを設計に含めない 現在のゆがんだソフトウエアの文化を改めるべきだな。

745 :仕様書無しさん:2007/01/20(土) 15:48:14
>>742
いやわからんでもないよ。
大手にはドキュメント書き終わるまでソース書いちゃだめっていう
頭の固いじじいが存在するのは確か

746 :仕様書無しさん:2007/01/20(土) 15:49:01
>>744
意外とまともな意見だな

747 :仕様書無しさん:2007/01/20(土) 15:49:14
これがウワサのアホコテ連鎖?
死に絶えろアホコテ共

748 :仕様書無しさん:2007/01/20(土) 15:55:08
>>747
いやいや、>>744は意外にまともだ。
コテの奴はコテの意味ねぇのにコテにするのがアフォなところだ。

749 :仕様書無しさん:2007/01/20(土) 15:58:14
お前がやってるのは仕事じゃねぇ、お絵かきだ
解消してない問題点洗い出して、そう言ってやれば誰でも改善するよ

750 :仕様書無しさん:2007/01/20(土) 16:00:34
>>749
どこに問題があるの?
問題点全部書いて一覧にして提出してよ。
とかいってくるに一票。

751 :仕様書無しさん:2007/01/20(土) 16:03:23
>>749-750
の話をしてるときにすでに期限が決まってたらどう動きようもないな。
ここでまだ期限が決まってないならなんでも言えるけど
期限が決まってたら馬鹿にまかせるよりこっちで引き受けて、
後にわかった不具合を細かいところまで全部書き止めておいて後で仕様変更の分だけ請求したほうがいい。
その後、その会社といい関係を続けたいならその資料はお蔵入り、
金の切れ目が縁の切れ目であるなら、かかった費用を全部請求して払ってもらう。

752 :仕様書無しさん:2007/01/20(土) 16:16:53
>748
>コテの意味ねぇのにコテにするのがアフォ

いわゆるここにいるのは全部アフォコテってことですね

753 :おじゃばさま:2007/01/20(土) 17:05:10
分かってもらえた人も結構多いので安心している。
つまり電球などの通り、「コーディング→テスト→再設計」を含めて設計とする事が正しいと言うことだ。
前置きが長くなったが、設計とコーディング/テストを分けて考える時点で根本的な問題があると言える。
そしていよいよ「オブジェクト指向設計は何故流行らないのか」と言う問題になる。


754 :仕様書無しさん:2007/01/20(土) 17:09:33
検証のためのコーディングはするが、設計を飛び越えた実装なんてしないだろ

755 :仕様書無しさん:2007/01/20(土) 17:22:22
糞コテがまともだったコテの意見をぱくってる…

756 :おじゃばさま:2007/01/20(土) 17:41:49
設計と実装を分ける事に問題がある。実装も設計の一部なのだ。
754も「できない」とは言わずに「しない」と言っている所を見ると、
出来るということは分かっているのだろう。
まず設計の本質を理解するためには、設計と実装を分けて考えると言う偏見を捨てなければならない。

757 :仕様書無しさん:2007/01/20(土) 18:58:56

「SEがPGに対して設計できないって馬鹿にしている」
という現状を見る限り、

SEは設計しかできない、PGは設計すらできないという事だろう。
そんなチームにOOPを導入して、いったい何のメリットがあるというのだ?

758 :仕様書無しさん:2007/01/20(土) 19:00:12
実装なんて単なる作業だろ?
設計してモデルツールで駆動させてあってればOK。
後はちゃいなでも何でも書かせればいいだけ。

759 :仕様書無しさん:2007/01/20(土) 19:13:19
それで所定の性能が確保できるなら問題ない。

応答速度も消費メモリもセキュリティも一切考慮せず
数時間おきに再起動することを前提としたり
致命的エラーを偶発的に起こして勝手に終了することを許容するなら
誰も苦労しない。

760 :仕様書無しさん:2007/01/20(土) 19:18:25
>>759

> 応答速度も消費メモリもセキュリティも一切考慮せず
これは設計の問題だが。

> 数時間おきに再起動することを前提としたり
> 致命的エラーを偶発的に起こして勝手に終了することを許容するなら
これはコーダーのレベルが低いだけ。
一切設計の問題じゃない。

761 :仕様書無しさん:2007/01/20(土) 19:23:44
>>760
>設計してモデルツールで駆動させてあってればOK。

のチェックには引っかからない。
つまりあんたにはバレない。

762 :仕様書無しさん:2007/01/20(土) 19:27:53
丸投げ、中間搾取の構造が崩れない限り

 プログラマに未来は無い。

763 :仕様書無しさん:2007/01/20(土) 21:05:31
SEが完璧な設計できるなら、
そのままグラフィック設計ツールで、
お絵かきプログラミングすればいいんよ。

具体的に変数型決めたり、タイミングを取ったときに破綻するなら
それはオブジェクト指向設計のどこかで、致命的なミスしてる。

そういうレベルまでSEの殆どが達してないから
実装担当から「設計の破綻で苦労するんだから、好きにやらせろ」って話が出る。

つまり、設計者が仕事してない。
おまえらクビね。




764 :仕様書無しさん:2007/01/20(土) 21:13:17
>>763
設計見て指摘できないこっちも悪いとか当然いいだすだろ。
責任の擦り合いをはじめてもしょうがないんだが・・・

765 :仕様書無しさん:2007/01/20(土) 21:13:37
仕様を覚えることができず、ツールの選定もろくにできない
なにやらせてもダメだから、仕様と関係ないレビューを繰り返しなじることにだけ特化する
SEとはそういう触手

766 :仕様書無しさん:2007/01/20(土) 21:14:33
そもそも得意げで設計(と思わしき物)を出してくる大手様に「全然駄目ですねやり直してください」とか言えないよ。
あいつ等馬鹿なのに自分でやりたがるんだ。

767 :仕様書無しさん:2007/01/20(土) 21:22:03
元請をよく馬鹿にする人いるけどさ、類は朋を呼ぶって奴だよ。
お前もその程度がお似合いなプログラマなんだよ。

768 :仕様書無しさん:2007/01/20(土) 21:23:56
設計以下の仕事が流れてくる会社って先生きのこだろう。

769 :仕様書無しさん:2007/01/20(土) 21:27:37
きのこる先生は生存する側の人物だで

770 :仕様書無しさん:2007/01/20(土) 21:28:57
>>767
まあ、それが弱いところだけどさw
ただ、これが原因で結局プロジェクトが赤字になっちゃうなら大手様でもなんでもないね。
ただの貧乏神でしかないさ。

>>768
はっきりいって足元みられるためにある階層だよな。
上はこれで作った気になってんだから救いようがねぇよな。
何年やっても技術が蓄積されないから結局安くならないしコストばかりかかると思うんだけどね。

771 :仕様書無しさん:2007/01/20(土) 21:45:40
設計した奴に十分なスキルがあるなら、設計者が実装する方が効率いいよな。
モデリング言語で基本設計してプログラミング言語で詳細設計するって感じで。

772 :仕様書無しさん:2007/01/20(土) 21:50:41
SEなんて職種は日本にしか居ないんじゃねーの。
本来のSEって営業のできるPGのことだと思ってるから特に。

773 :仕様書無しさん:2007/01/20(土) 22:10:43
んでも、設計者が実装していたらいくら時間あっても足りないよな。
特に一つの製品に100社以上関わるような大規模開発だと。

しかし、大抵できる奴に負荷が集中する。仕事取って来て進捗管理して
メール捌いて設計して実装してテスト手伝っている奴とか知っている。
仕事量に関して80:20の法則が成り立つのは本当に可哀想だ。

774 :仕様書無しさん:2007/01/20(土) 22:21:10
>>773
いいじゃん。
理論的には設計終わらないと実装できねぇんだからやりゃいいじゃん。
つか、せめてコア部分(てめぇで設計した部分)は動かして確かめろ。
って感じだな。

775 :仕様書無しさん:2007/01/20(土) 22:21:42
>>760
実際の開発現場では
最初の設計通りで最後まで済む事はまずない。
釣り師の現場もそうと断言できる。

名称が違うだけで実際は

設計→実装→再設計(修正含)→実装→…

の繰り返しなんだよ。
例えばOSとか。

駄目な設計や実装だと
この繰り返しが難しくなるのが致命的だな。

本題のOOの利点の一つは
この繰り返しのサイクルを短く出来る事だ。



776 :仕様書無しさん:2007/01/20(土) 22:25:16
>775
繰り返しによる開発が実情だ、という話は別にいいけど。

> 本題のOOの利点の一つは
> この繰り返しのサイクルを短く出来る事だ。
なんでOOだとサイクルが短くできるかわからん。
構造化プログラミングや論理型プログラミング、関数型プログラミング
と何が違うの?

777 :仕様書無しさん:2007/01/20(土) 22:32:30
最適化を行う対象を特定しやすい(=最適化後の汚さをカプセル化できる)ところとか?

778 :仕様書無しさん:2007/01/20(土) 22:32:57
>>776
それは自分も聞きたい。OO設計はなぜ開発サイクルが短くなるのか?

779 :仕様書無しさん:2007/01/20(土) 22:33:53
>>776
ばずわーど。

780 :仕様書無しさん:2007/01/20(土) 22:49:04
>>778
とりあえず、設計から実装まで同じチームや人で担当することが可能になり、
ドキュメントレスになるし色々無駄が省ける。

781 :775:2007/01/20(土) 22:52:30
>>776
誤解させてしまったようなので補足

大雑把に説明すると
デバイス層→アプリケーション層の間をレイヤー分割して設計する場合、
クラスやメタプログラム機能が充実してる
OOの方が部品化しやすい分再設計する場合に楽が出来る。

つまり、そういう事がなければ
OOで開発サイクルが短くなる事はない。



782 :仕様書無しさん:2007/01/20(土) 23:06:31
レイヤーとかモジュールとか言ってるけどさ、
俺の知ってる限りじゃ各層とも下位レイヤの実装クラスに依存してるから変更効かないよ。

783 :仕様書無しさん:2007/01/20(土) 23:07:14
>>781
それが従来のC言語での開発じゃできない理由が説明できてないじゃない?

784 :仕様書無しさん:2007/01/20(土) 23:09:02
>>782
そういう場面のが多いな。
汎用性が効く部分なんてMFCのCStringみたいなホント部品みたいなもんばっかりだし。
設計じゃでてこねぇよなぁ・・・

785 :仕様書無しさん:2007/01/20(土) 23:21:44
一般的だけどレイヤアプローチの設計って案外設計が難しいよな。
(この点は自分のスキルが低いのを認めないといけないけど)

上層が下層に依存してしまうという感覚を持つ人間の方が
マジョリティだと思うけど、本来OOの設計ではDIP(依存関係逆転の法則)
というのがあって、原則に反するらしい。下層が上層に依存する
のが正しいのだそうだ。

オブジェクト指向の原則の中では、他にもLSP(マルコフ置換の法則)
とかもレイヤアプローチでは必要な気がする。

余談だけど大きなアプリケーションを組む場合はレイヤーアプローチは
有力だけど、小さなアプリケーションを組むときは機敏性に欠ける
という意見もあるね。

なんかこのスレを見ていると大規模アプリを開発している人間が
偉い、という印象を受けるけど、実際の現場ではもっと小規模
アプリケーション開発者にもスポットを当てるべきだと思う。
そうしないとソフトウェア開発者全体の大きなパイに属する
人間が救済できない。



786 :仕様書無しさん:2007/01/20(土) 23:30:42
アジャイルソフトウェア開発の奥義に書いてあったな

787 :775:2007/01/20(土) 23:35:28
>>782
それは詳細設計次第。
例えばC++ではPCごとにSTLの使い方違わないでしょ。
そういうこと。>>777の書き込みの方法や他にもいろいろと参考にしてみては。

>>783
Cで開発出来ない事はないし
各レイヤーごとに開発して結合という方式で良いものは
レイヤーごとに効率よく開発できればいいと思う。

デバイスドライバ開発等、
そもそも、レイヤ内で完結してる開発もあるし。


788 :仕様書無しさん:2007/01/20(土) 23:39:33
>>785
レイヤーアプローチは、既にレイヤーが決定されている分には簡単だと思うんだ。
レイヤー設計から入るなら話は別だけど。

個人的に好きな設計は、上層と下層が両方とも依存しないタイプの設計。
自分が設計したのはOO設計ではなかったけど。

789 :775:2007/01/20(土) 23:59:20
>>788
設計を意識して開発してないようだけど、
設計の良し悪しは開発が進むと効いてくる
ボディーブローみたいなもんだよ。

今まで簡単な開発が出来たのなら、それはそれまでの設計が良かったって事。
そこで拡張するときに再設計を間違えると
それまでの良さも簡単に台無しになる。

俺は堅実なSEに求められる設計は
アッパーではなくボディーブローだと思う。


790 :仕様書無しさん:2007/01/20(土) 23:59:33
STLみたいに実装がカプセル化されたレイヤーに依存するならわかるけど、
下位レイヤーの実装クラスを継承してメソッドをこれこれこのようにオーバーライドして使え
って言われると結局実装に依存しちゃうんだよね。
安全な継承、安全なオーバーライドをするためにはちゃんと実装を調べなきゃいけないし。
それともレイヤー設計ってこんなもん?


791 :仕様書無しさん:2007/01/21(日) 04:40:16
なんか歯がゆくなるなあ。
オブジェクト指向設計を神格化するような奴は
オブジェクト指向がメッセージングなのか、クラス化なのか
インターフェースの継承なのか、何ら自ら定義してないし…
オブジェクト指向設計を否定する奴は、実装上の障害のこと
しか言ってないし…

スレタイに沿って言えば、ここの内容見る限りオブジェクト思考「的」
設計は流行っても理論上の「オブジェクト指向」は流行るわけないね。

792 :仕様書無しさん:2007/01/21(日) 04:40:43
>>785
>なんかこのスレを見ていると大規模アプリを開発している人間が偉い、という印象を受けるけど、

確かにこのテの勘違いクンは多いと思う。だが、大規模アプリを大規模として捕らえているヤツは
まだまだ未熟。本当に偉いのは規模を意識させないプロジェクト運営をやるヤツ。

793 :仕様書無しさん:2007/01/21(日) 05:52:00
実装にはなじまんなー。MSくらいのマップを作成しないとだめじゃん。

794 :仕様書無しさん:2007/01/21(日) 06:39:39
色々な実装の仕方があるんだから、ちゃんと統一しないとな。設計方針を。

そもそも設計というのは、実装の仕方まで縛ってしまうほど
あいまいさが無いものであるべきなのに、それが無いというのは、設計者が無能ということ。

彼のオナニーを延々と見続けるのは苦痛ではないかい?

795 :真面目なネラー:2007/01/21(日) 07:19:30
1ですが、ここまでのスレを読む限り、オブジェクト設計の流行らないのは
その評価自体がバラバラで、メリットの認識も低いし、実装屋を指導できる
設計屋も少なそう、といったあたりでしょうか?

796 :仕様書無しさん:2007/01/21(日) 07:38:40
勉強するための本がないからです。
共通のコンセンサスが取れない。

797 :仕様書無しさん:2007/01/21(日) 07:50:53
>>795
まとめるならそんな感じだね。

なにより、このスレのメンバー全員で1つのプロジェクトをやった場合、
OOPを採用したら、大失敗に終わるだろう。

798 :仕様書無しさん:2007/01/21(日) 08:24:13
>>797
2chで議論しまくってから開発すれば問題なし。

そもそも、現場は顔突き合わせて話し合うのが一番いいんだよ。

偉そうなSEや上流工程はいらね。

799 :仕様書無しさん:2007/01/21(日) 08:59:48
上流工程なしで基幹系の開発やってみてください。w


800 :仕様書無しさん:2007/01/21(日) 09:46:42
>>799
やったこともないのに含みをもたせるな馬鹿もの

801 :仕様書無しさん:2007/01/21(日) 09:50:41
ただの揚げ足だな、何の目的で任命されているか
その仕事を満足しない上流工程は無意味といってるだけ。

伝言ゲームの途中で毎回間違える人間のようなもん。

802 :仕様書無しさん:2007/01/21(日) 09:57:26
>>801
なにいってるのかさっぱりわからないけど
お前の書く仕様書もやっぱそんなもんなんだろうなw

803 :仕様書無しさん:2007/01/21(日) 10:34:34
>2chで議論しまくってから開発すれば問題なし。
>そもそも、現場は顔突き合わせて話し合うのが一番いいんだよ。

現場で会って話すのがいいのは確かだが、水掛け論にもなりやすい。
ていうか、ネットで論議しまくるだけで解決するなら、
コケるプロジェクトなんてないよね。
「問題なし」って言い切る人はダメだね。

804 :仕様書無しさん:2007/01/21(日) 12:26:24
ようするにオブジェクト設計って別に無能でも多少はきちんとした設計できる銀魂じゃないんでしょ。
むしろデキる人しか使えない。なら流行る必要性がない。
無能7割と言われる世の中じゃあ。

805 :仕様書無しさん:2007/01/21(日) 12:45:37
そもそもできる奴は何やってもできるからなぁ・・・

806 :仕様書無しさん:2007/01/21(日) 12:51:12
できない、奴は何をやってもできないし。
無能同士ならOODのほうが多少増しのなんだが。

807 :仕様書無しさん:2007/01/21(日) 13:05:49
>>806
>無能同士ならOODのほうが多少増しのなんだが。
いや、それもわからないでしょ?
それがそうであることを証明できないでしょ?
このスレでそういう確定できないことを勝手な決め付けで断定口調で話すのもう止めようぜ。
無駄に喧嘩するだけになっちゃうし。

808 :仕様書無しさん:2007/01/21(日) 13:10:36
>>807

わかった、OODのほうが増しな可能性もあるんだが

に訂正しとくよ。

809 :仕様書無しさん:2007/01/21(日) 13:14:59
>>808
なんとも意味のない発言になるなw
50%ともそれ以下ともそれ以上とも言え無いわけだしw

810 :仕様書無しさん:2007/01/21(日) 13:16:02
ちょっとスレ違いになるが、そもそも設計屋は実装手法を知っていなければならないものだろうか?
実はオレの周りにはそんな設計屋がいっぱいいるのですよ。もちろんオサーンばっかり。
実装手法どころかインフラの知識も無いヤツまでいるし。

811 :仕様書無しさん:2007/01/21(日) 13:30:28
>>809

OODが悪いとは言えないというのが
話の主旨、反論があれば、きちんとしたデータを出すように。



812 :仕様書無しさん:2007/01/21(日) 13:31:20
>>810
あー、細かい部分が確実に設計レベルに影響を与える現実があるからなぁ・・・
そんなことないっていうなら自分で組んでみろよっていうしかないわけで・・・

あと、設計がまずい/まずくないってことを確認する方法が実装してみるしかないんだよね。
どうしても人の目だと抜けや漏れが発生する。
これが致命的だとどんなに念入りにチェックしても結局組み直しになるしね。

813 :仕様書無しさん:2007/01/21(日) 13:33:05
>>811
やめてくれ。

A:「幽霊はいる!絶対にいる!」
B:「いねぇよwバーカw」
A:「いないっていうなら証拠をみせろよ!」
B:「お前こそ、幽霊もってこいよw」

的な議論をしたいのか?

814 :仕様書無しさん:2007/01/21(日) 13:35:48
>>810
できなきゃ虚業。

815 :仕様書無しさん:2007/01/21(日) 13:40:07
>>813

>>807からの流れだから
文句があれば>>807に言ってくれ



816 :仕様書無しさん:2007/01/21(日) 13:44:29
>>815
いや、もういーでしょ。
もう、こういう無駄な議論になるのわかってない奴このスレにいないでしょ。多分。

817 :仕様書無しさん:2007/01/21(日) 13:48:30
いや無能にOODは無理。これ定義

818 :仕様書無しさん:2007/01/21(日) 13:54:06
俺等もあれだな。
次のステージにいくときかもしれん。
もうオブジェクト指向の設計がいいか悪いかなんて実際どうでもいいだろ。
大事なのは

「いかにして、経営者から金を巻き上げるか?」

だろ?
こういうことを考えたときに開発期間が短くなるなんて変なプレゼンしちゃ駄目だろ?
品質とか保守とか盾にしてどんどん金をプログラマに流すように俺等団結してったほうがいい気がするぜ。

819 :仕様書無しさん:2007/01/21(日) 13:57:53
>>817

無能には、どんな手法であれ設計じたいが無理、

820 :仕様書無しさん:2007/01/21(日) 13:59:02
2chで俺たちとか言う奴ってきもー。
根本的に、金をもらって部分を開発する思想の時点で奴隷。


821 :仕様書無しさん:2007/01/21(日) 13:59:07
>818
新糞スレ立ててそっちでやってくれ。

822 :仕様書無しさん:2007/01/21(日) 14:01:06
>>818の続き)

で、そのダシにオブジェクト指向設計だの、
XPだのアジャイルだのわけのわからない(けどすごそうな)横文字入れていきたいね。
PGを長くやってたけど実際の品質をよくするなんて行為ははっきりいって俺等にとって一銭の得もねー。
いい加減わかってきてもいいだろ。
〜しないと問題になりますよ。
とか経営者を不安にさせろ、もう全員詐欺師になるぐらいの心意気が必要になってるのかもしれんな。
実際、いまのセキュリティだのなんだのって仕事はこんなのと同義だろ?
品質向上のための作業工程確立して無駄な資料たくさん作りまくってその工程を会社に認めさせるところまでいったら成功だな。

資料が膨大に増えたって正直俺は真面目に資料なんて作ったことねぇから作業量は実質0だ。
確かめられるもんならやってみろといいたい(エクセルで10MB超えてるようなもん誰も開きすらしないだろ)

823 :仕様書無しさん:2007/01/21(日) 14:01:42
>>818
お前もしつこい奴だな。
スレタイ読めよ。
ここはオブジェクト指向設計についてのスレ。
そういうのは別スレでやれや。

824 :仕様書無しさん:2007/01/21(日) 14:03:36
いるよね、関係ない話題でかってにアジって盛り上がる馬鹿。
運動好き。対立好き。

そんなにあれなら、自分でパッケージ作って売る側になればいいじゃん。


825 :仕様書無しさん:2007/01/21(日) 14:04:37
>>822
そんな発想だと、日本の産業自体がインドに負けるよ。

826 :仕様書無しさん:2007/01/21(日) 14:04:48
なんでクソコテに引き続き勘違い長文クンとかアホっぽいヤツが次々に現れるのか

827 :仕様書無しさん:2007/01/21(日) 14:06:19
ソフトウェア工学は昔からそんなもんだったがな。

828 :仕様書無しさん:2007/01/21(日) 14:09:02
>>813
役に立つかどうかわからない→だから「試さない」

これはアフォのやることだろ。
議論ってのは、「どうにかして役に立てようと工夫するため」にやるもんだ。

829 :仕様書無しさん:2007/01/21(日) 14:09:12
てか、基本的にみんなどうしたいの?
誰のためになんのために効率をよくしたいのかわからない。
予算削れたら、その分開発期間短くなるだけじゃん。

830 :仕様書無しさん:2007/01/21(日) 14:15:43
>>829
作業期間で報酬をもらう考えが間違ってる。
どっかの法案の話じゃないが、あれにも一理ある。


831 :仕様書無しさん:2007/01/21(日) 14:20:44
>>829
そう言われると、WEみたいだね。
「オブジェクト指向設計したんだから、工数少なくて済むだろ?」
ってSEが強制的に納期を縮めるような。

OOPもそうだけど、作業時間の再割当が目的だと思う。

832 :仕様書無しさん:2007/01/21(日) 14:22:10
>>830
じゃあ、WE賛成なんだ?
実は意外と多いのかな?>WE賛成

833 :仕様書無しさん:2007/01/21(日) 14:24:23
>>832
この業界だと特に大いと思うよ。
残業馬鹿みたいにしてる奴の8割は能力不足と生活残業だろ?

まあ、無理やりスレの趣旨にあわせるが、そういう馬鹿は大体新しい技術への向上心もない。
単に昔の仕事のやり直しを繰り返すだけ。

とはいっても、オブジェクト設計が流行らないのは、やっぱりそれほど絶対的に革新が無いからだろうね。

834 :仕様書無しさん:2007/01/21(日) 14:25:18
>>791
おれが思うのは、「オブジェクト指向」というのはたとえば「鶴翼の陣」みたいな、
あるいは「つばめ返し」みたいな、現場を離れたところで、エキスだけを取り出した
ものを煮詰めて作ったもの、そういう感じがする。

当然、現場においてそれらが万能なわけではない。
その根底にある考えや、そこに至るまでのさまざまな試行錯誤や取捨選択の
経緯や、そういうことが全体を組み立てるうえである程度役に立つ点は否定
できないが、万能律や大統一理論のように捉えていると、かえって役に立てる
ことはできなくなると思う。


835 :仕様書無しさん:2007/01/21(日) 14:31:32
>>834はオブジェクト指向入門って本を読んでね

836 :仕様書無しさん:2007/01/21(日) 14:33:13
>>833
>とはいっても、オブジェクト設計が流行らないのは、やっぱりそれほど絶対的に革新が無いからだろうね。
構造化設計技法だって結局流行らずCOBOLじゃ未だにコピペマンセーだよ。
草の根で設計技法が広まらないのは、単にやる気の問題が大きいと思う。

837 :仕様書無しさん:2007/01/21(日) 14:33:41
>>834
的を射たレスだな
つまり、机上の空論。
必死なのは、セミナー会社やもったいぶったSE、講師だけw

838 :仕様書無しさん:2007/01/21(日) 14:38:06
>>837

そうやって、米国には、追い付けず
インドに抜かされて行く訳だ、
>>837みたいなのがのさばってるから
日本のソフト業界は、10年遅れてるって言われるんだよ。

839 :仕様書無しさん:2007/01/21(日) 14:41:50
>>836
この業界で10年ぐらいだが、コボルの世界って一切関わったことないからしらない。
C、++、#、VB、.net、JAVA・・・。

ここの人が力説するほど、構造化もオブジェクト指向も別に敷居ないと思うんだけどね。
やってることに別に自慢もすることもないし、よくこのスレでも湧く自慢野郎って恥ずかしいね。
普通にやるべきことをさも特別なように・・・。


840 :仕様書無しさん:2007/01/21(日) 14:49:43
>>839
普通のことを普通にやらせるのがどれだけ難しいか。。
ここに普遍的な問題を見出せない「お前が」自慢野郎なんだよ。

841 :仕様書無しさん:2007/01/21(日) 14:50:53
>>838
机上の空論に拘る人間がいるからこそ遅れてるって見方はできないのか?
学生理論と現場の実装は違うんだよ

842 :仕様書無しさん:2007/01/21(日) 14:53:40
>>840
えへ。w


843 :仕様書無しさん:2007/01/21(日) 14:55:46
>>841

OODが日本独自の観念ならそうかもしれんが、
米国で作られて、普通に使われている実績のある物だからな。
結局、日本で馬鹿が古い方法に拘ってるにすぎない。


844 :仕様書無しさん:2007/01/21(日) 14:57:57
うちは、フツーにOOPを導入し、かなり成果上げてるけど、
導入したく無い組の強烈なステレヲタイプを崩すのは、
相当労力かかりそうだから傍観してるだけ。むしろ都合がいい。

OOPを導入するなら、2〜3プロジェクトは大赤字の覚悟で、
かなり痛みを伴い社員を成長させる覚悟無いと無理だし、
その過程で脱落者もいっぱい出るだろう。
でも派遣を入れているような会社が大半だろうし、
赤字覚悟で成長させようって発想が出ないでしょ、普通は。

OOPを実験するなら、中国やインドに投資したほうが思いっきり安くあがるし、
リスクも少ない、しかもハングリー精神旺盛でやる気満々。
日本人がOOPに挑戦する機会はもう与えられないよ。
国内のSEは、海外のSEを育てるための資金供給源として、
このままリスクの低い今の体制が続くだろう。

っておもってるんだけど、どうよ。

845 :仕様書無しさん:2007/01/21(日) 14:58:40
>>843
は!
アメリカ産のフレームワークがどれだけコロコロ変わってると思ってんだ?
Java系はまともだが、MSが提唱する新アークテクチャが長生きした試し
などないじゃん。

846 :仕様書無しさん:2007/01/21(日) 15:04:05
>>845
javaってまともなのー?俺、あれ嫌いなんだ・・・orz

847 :仕様書無しさん:2007/01/21(日) 15:04:37
>>845

それは、逆に言うとフレームワーク開発能力
が高いって事でもある。日本の企業じゃ半分の数の
フレームワークでさえ開発できんだろうね

848 :仕様書無しさん:2007/01/21(日) 15:05:38
>>845
Javaテクノロジーは、その多くが一貫して受け継がれてるけど
MSが提唱したテクノロジーは、しょちゅう寸断されてる

849 :仕様書無しさん:2007/01/21(日) 15:09:00
>>847
君はどこのセミナー会社の社員だ?

850 :仕様書無しさん:2007/01/21(日) 15:11:03
>>849

反論できなくなるとレッテル貼りかよ
どこまでもクズだなぁ

851 :仕様書無しさん:2007/01/21(日) 15:26:06
でも前のフレームワークを捨てるって駄目なことなのかなぁ。
駄目だから続かないって決め付けるのもどうかと・・・。

852 :仕様書無しさん:2007/01/21(日) 15:31:55
保守・運用したときに副作用が発生しにくくて、さらに機能を追加しやすかったら
別に何設計でもよかんべ。

853 :仕様書無しさん:2007/01/21(日) 15:32:09
>>848
どこが?w
JAVAというかジャカルタほどいい加減なことないと思うが。


854 :仕様書無しさん:2007/01/21(日) 15:32:25
>>835
甲州流軍学書を読んでね、と同じくらい無意味なレス。

855 :仕様書無しさん:2007/01/21(日) 15:39:07
>>853
Jakartaは、第三者が勝手にやってる同人組合みたいなもんだろ
確かに、Strutsなど最悪のクソプロジェクトが多発してるのは事実だが
分かってる人なら、どんなに雑誌で特集を組まれても見向きもしない。
私も始めからStrutsなどは一笑に付していた(勿論、いろいろ使用した上で)

こういうのに踊らされて飛びつくような人とOOPマンセー主義者は
似た者同士って事だよ


856 :仕様書無しさん:2007/01/21(日) 15:43:21
>>855
じゃばコミューからジャカルタの成果抜いたら何が残るの?W


857 :仕様書無しさん:2007/01/21(日) 15:44:59
>>855

可哀想に、最近仕事してないんだろうな?
ねぇ無職?無職でしょう

858 :仕様書無しさん:2007/01/21(日) 15:46:19
>>856
別にJakartaの全部を否定してる訳じゃない。
少なくとも本家Sunが提唱した技術は、すぐに破棄されたりしてないって事だよ。
JavaEEなどの、大幅なリファインはあっても。


859 :仕様書無しさん:2007/01/21(日) 15:47:56
>>857
はぁ?
君はセミナー会社で、資格講座を売り込む営業に忙しいんだろ?

860 :仕様書無しさん:2007/01/21(日) 15:51:22
オブジェクト指向がはやらないのは、オブジェクト指向が遅いから。
以上。

861 :仕様書無しさん:2007/01/21(日) 15:52:39
>>860

キター、アセンブラ原理主義者

862 :仕様書無しさん:2007/01/21(日) 15:53:26
>>860
はい、消えた。

863 :仕様書無しさん:2007/01/21(日) 16:16:38
オブジェクト指向がそんなに好きなわけじゃないんだけど、
OOPの実行速度が遅いということを言う人がときどきいるよね。
これは完全に濡れ衣だよね。

Javaが遅いのはオブジェクト指向だからじゃないし、
C++はC言語とそんなに変わらない(多少は変わるが)。

自称アセンブラが使えるベテランの人(C言語しかつかえない)
にC++は遅い、と言われてゲロゲロした気分になったことはある。
その人はアセンブラで書けば処理が速くなると思っている
(ここら辺もゲロゲロ)人で、コンパイラが吐くアセンブラコードとか
読んでない。

話をしてるとPentium以降(ってもう既にそんなに最近の話じゃないが)
のアセンブラの最適化とか全然知らないし。

OO厨も勘弁して欲しいが、こういうオヤジもどうにかして欲しい。
多分、OO厨が仮想敵としてムカついているのはこういう人なんだなと思う。


864 :仕様書無しさん:2007/01/21(日) 16:20:36
ゲロゲロって…
そんな表現する人がおっさんて言う相手はどんなおっさんだろう

865 :仕様書無しさん:2007/01/21(日) 16:21:05
>>861
いい響きだ

866 :仕様書無しさん:2007/01/21(日) 16:34:30
自分以外の同じくらいの年齢を指す。
すくなくてもおれはそー


867 :仕様書無しさん:2007/01/21(日) 16:51:39
けろけろ
ttp://www.sanrio.co.jp/characters/keroppi/welcome.html


868 :仕様書無しさん:2007/01/21(日) 20:35:33
OOPが長い間、一般的でなかった最大の理由は
その唯一の言語のsmalltalkが使いものにならないくらい遅かったからである。

C++が出たのは最近だよ。15年くらい前だったと思うが。

869 :仕様書無しさん:2007/01/21(日) 20:48:06
LISPは何故いつまでたっても流行らないの?

ってスレ立てていいですか?



ごめん、立ててよくても立てません

870 :仕様書無しさん:2007/01/21(日) 21:07:28
>>868
だからSmalltalkが遅いのはOOだからなの?
Smalltalkの選択したアーキテクチャの問題じゃないの?

たとえば当時のマシンではGCが遅かったとしても、それはGCの
問題であって、OOが遅いわけではない。


871 :仕様書無しさん:2007/01/21(日) 21:16:32
良く読めや低脳

872 :仕様書無しさん:2007/01/21(日) 21:26:55
JITが入ったSmalltalkは今のC++やJavaほどではないけど
使えないほど遅くはなかったと思う

ただ手軽に試せるようになったころはVBの絶頂期で...

873 :仕様書無しさん:2007/01/21(日) 22:21:04
こんな本が出版されたようですが、このスレの中の方々は原著をお読みになっていたのでしょうか?
http://www.amazon.co.jp/gp/product/4798111112/249-4566423-3261160

874 :仕様書無しさん:2007/01/21(日) 22:36:57
業者の宣伝レス乙。第一版と何が変わったのかは知らないが、原則・コンセプトとかいう
変な副題が付いて値段も上がってるのはどうかと思うぞ。

875 :仕様書無しさん:2007/01/21(日) 23:10:12
なーんか、こういうスレって盛り上がるけど
TVの討論番組と同じで無意味なんだよね

876 :仕様書無しさん:2007/01/21(日) 23:21:31
>875
しっ!そんな身も蓋もないこといったら一所懸命マジレスしてるコテの連中がかわいそうじゃないか。

877 :仕様書無しさん:2007/01/21(日) 23:26:48
> 875
つーか、プロレスと一緒でそれはお約束で言うのが無粋だと思ったんだけど、
違うのか(´Д`;

最近暇で面白いことがないので遊んでたんだけど。
あえて周りと逆のことを言ったり。

そもそも2chで実りのある議論をしようと思うほうが間違いなのでは。
俺は面白ければなんでもいいよ。


878 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 00:06:38
OODを採り入れると髪の毛が生えたり抜けた歯が生えたりします。
アトピーも一ヶ月で完治しますし、癌さえ直ります。

879 :仕様書無しさん:2007/01/22(月) 00:07:35
失せろ屑コテ

880 :仕様書無しさん:2007/01/22(月) 00:08:57
>>875
脳みそ足りない連中の集まりで議論は無理。

881 :仕様書無しさん:2007/01/22(月) 00:09:54
美少女プログラマがオブジェクト指向したいっ
って言えば俺もOOPマンセーです

882 :仕様書無しさん:2007/01/22(月) 00:17:21
俺も、やさしい美人SEが、OOわかんない〜とか言えば
COBOLでコーディングしても良い。

883 :仕様書無しさん:2007/01/22(月) 00:18:30
>>875
承知の上だから別になんとも。
やらずに一人で煮詰まっているよりかなりマシだろう。

884 :仕様書無しさん:2007/01/22(月) 00:19:36
>>882
チ○コ・オブジェクトとマ○コ・オブジェクトで説明したいww

885 :仕様書無しさん:2007/01/22(月) 00:20:28
少しでもまともな議論がしたいなら情報学板とかIDの出る板にスレ立ててやったほうが良いと思うよ

886 :仕様書無しさん:2007/01/22(月) 00:23:48
>>834
俺もそう思ってるよ。使えるとこは使うっていう現実的選択しかしない。
でも、ハードの世界であるようなアーキテクチャの革新と同じような
ことがソフトウェアではないんだなってことに、歯がゆい思いがする。
すでにオブジェクト指向がその解ではないということは証明されてると思う。

>>844
コンパイラの最適化依存になってる今のCPUアーキテクチャじゃ
むしろ遅くなる場合があるのはその通り。
しかし、Javaが遅いのは事実だし、CPUアーキテクチャが判ってる
人間なら、Cやアセンブラで書いて数倍違う速度出せるのも事実。

887 :886:2007/01/22(月) 00:27:23
すまん、レス違い
>>863 な

888 :仕様書無しさん:2007/01/22(月) 01:10:35
>>13
> そのうちきっと「アスペクト指向設計」とか出てくるぞ。
そら出るだろう。
アスペクト指向のこと何も考えないところに突っ込むよりはじめから考える方が良いもの。

889 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 01:12:21
IXIが民事再生法申請
あちゃー

http://www.nikkei.co.jp/news/sangyo/20070121AT1D2100Q21012007.html

東証二部上場で情報サービスのアイ・エックス・アイ(IXI)は21日、
大阪地裁に民事再生法の適用を申請し、
受理されたと発表した。負債総額は119億円だが、さらに100億円以上膨らむ可能性があるという。

890 :仕様書無しさん:2007/01/22(月) 01:14:28
失せろ屑コテ

891 :仕様書無しさん:2007/01/22(月) 01:15:37
叩きでもいいからレスがほしい。
俺にもそんな時期がありました・・・

892 :仕様書無しさん:2007/01/22(月) 01:16:34
悲しい人生だな・・・

893 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 01:17:37
空対空ミサイルなんかアセンブラだろ?

894 :仕様書無しさん:2007/01/22(月) 01:23:50
つまらん死ね

895 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 01:28:33
じゃあ地球シミュレーターはオブジェクト指向を使っているかについて

896 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 01:29:15
おおアカデミック!

897 :仕様書無しさん:2007/01/22(月) 01:54:11
> なーんか、こういうスレって盛り上がるけど
>TVの討論番組と同じで無意味なんだよね

そうか?テレビの討論番組は知らんがこのスレに関しては
俺には実に意味がある。というか勉強になる。
なぜ無意味になってしまうのか。
こいつの言うオブジェクト指向がどこがおかしいのか。
俺の言ってるオブジェクト指向とはどう違うのか。
一つ一つ検証すればいくらでも自分のためにする方法はある。

898 :仕様書無しさん:2007/01/22(月) 03:12:23
俺はオブジェクト指向関連嫌い。
最近はクラス嫌いはなくなったけどw
むしろ今、クラス化しておいたら、と後悔しているww

理由1 お客が基本的にオブジェクト思考は仕様変更しても良い
     すぐなおると思っているから。交渉が無意味に大変
     ”それはオブジェクト指向だから大丈夫でしょう”氏ねといいたいw
理由2 そこまでに至る設計時間が(100%)取れないから
     設計中にバンバン基本仕様かわるからw
     中途半端な設計ならなんでもかわらんと思ってるww
     納期が先なのがおかしいwww
理由3 やたらでかいものを仕様にのせてくるから
     マジつかわねーよ、そんな機能ww
     細かいとこまではつっこんでくるんだよねw
理由4 やっぱ設計時に実装でのパフォーマンスが見えにくくなるときあるよw
     設計でへくってるかもしれんが、
     ”思いっきり”が減る・・・そうすると仕様(夢)膨らんでさらに悪化w
こういうのがなきゃしっかり設計したいし、新技法もやってみたい
実際そんな時間がない・・・

工数の請求するときやりやすいやり方、というのが俺の正解なのかww

つーとお客さん側がそういうのが本当にわかる世代が頭取れればいいわけだw
うむ、老兵は去るとするかw

899 :仕様書無しさん:2007/01/22(月) 03:51:32
老兵さん、老兵さん、何で人月って残業込みで数えるの?

900 :仕様書無しさん:2007/01/22(月) 04:15:34
>>899
それはね、おぶじぇくとせっけえがないからだよ

901 :仕様書無しさん:2007/01/22(月) 05:15:50
お前を食い殺すためだろう

902 :仕様書無しさん:2007/01/22(月) 11:27:56
>>873
高すぎる。
経験的に高い本は、役立たずなのだが。
まあ、今度本屋で立ち読みしてみましょう。

903 :仕様書無しさん:2007/01/22(月) 11:44:20
>>885
OODの設計屋も少ないだろうが、OODのわかるPG屋はもっと少ないだろう。
その実態を知るには、このスレ板で意見を聞くのがよい。
テクニック(術)は知っているが、技法(技と法則)はわからない、
理解できないというPG屋が多いような気がする。
PG屋も頑張らないといけない。

904 :仕様書無しさん:2007/01/22(月) 17:02:51
>NASA,「ジェイムズ・ウェッブ宇宙望遠鏡」のソフトをIBM製UMLツールで開発
ttp://itpro.nikkeibp.co.jp/article/NEWS/20070122/259204/


905 :おじゃばさま:2007/01/22(月) 19:19:08
だから本来設計とすべき所を「設計」「実装」「テスト」と考えるから分からなくなる。
分離された「設計」見て最初に思う事は、「論理は分かるがどうやればいいか分からない」とか
「理想はそうだが最初からその理想どおりには出来ない」と言う事だろう。
それは当然である。全体の1/3しか見ていないのだから。
そこで多くのSEは「自分のスキルが足りない」と考えてしまう。
しかし安心していい。出来なくて当然なのだ。

ではオブジェクト指向設計とは何か?
一般的に言われている物は不完全なので、本来の形を考えて見よう。
オブジェクト指向プログラミングとは、簡単に言うとクラスを使って、データと処理をグループ化して
プログラミングすると言う事だ。そして実装、テスト、修正を繰り返すのが設計となる。
つまり「クラスを使ってデータと処理をグループ化するプログラミングで、実装、テスト、修正を繰り返す」
のが真のオブジェクト指向設計と言える。


906 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 19:22:21
おお!っと思ったけどだめね

>から約50人のプログラマが開発に参加し,C++言語で20万行のコードを書くという。

たったの20万行書くのに50人・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

907 :おじゃばさま:2007/01/22(月) 19:22:56
ではこれが何故流行らないか?
前述の論理で言うと、「C++もしくはJavaを適切に用いて、プロトタイプ法で開発する」
と言う事になる。
流行らない?いや流行っているというか今主流の開発方法だ。
つまり、「オブジェクト指向設計は流行っている」を言える。


908 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 19:25:43
コードに落とせるような細部まで設計してないし、そんな細部まで設計するならソース書いたほうが早い

一人4000行かよ ファイル2−5枚だな

909 :仕様書無しさん:2007/01/22(月) 19:27:09
>>905
そんな嘘ッパチは原理主義者の俺が許さない。
そもそも本来の形を語るのにシミュレーションの話はおろか、
simulaやsmalltalkの話まで出ないなんて詐欺にもほどがある。
はじめは実装テスト修正を繰り返すなんて話はなかった。
そんなのは後から都合がいいようにとって付けたセミナー用の話題でしかない。

910 :仕様書無しさん:2007/01/22(月) 19:33:58
>ココ電球(∩T∀T)y-~~~~
キチガイ?

911 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 19:34:31
他の工学では

・モックアップ
・原型試作
・シミュレーター

といった方法で検証を行い、設計とテストを繰り返す。
ところが運の悪い事に、今のソフトウエア設計は適切な試験方法がない。

車のお絵かきの絵を描いて「設計した」とは言わないのだが、ソフトウエアではこれがまかり通っている。
コーディングまで含めて設計とすべきだ。 テストルーチンなどとケチな事言わずに本ソース書くべき。

912 :仕様書無しさん:2007/01/22(月) 19:43:13
>905
 あんた!分析力あるぜっ♪

  世間にゃー通じないだろーけど

913 :おじゃばさま:2007/01/22(月) 19:46:49
>電球
会社の規模やプロジェクトにもよるので目安にしかならないが、一人の担当者に割り振る量は、
0.8〜1.7Kと言う所が多い。ベテランの仕事が出来る人の上限が、4Kぐらいだろう。
これは一度に詳細まで仕様を理解出来るのが、常人で4Kまでと言われているからだ。
ただし、4Kを完全に終わらせて、つぎの4Kをやる人はいる。
つまり、一人4000行と言うのは、かなり厳しいスケジュールになる。
大手では平均1.2Kぐらいが順当だろう。

>909
simulaやsmalltalkの話が出ないのは、それがオブジェクト指向プログラミングの要素に関するレベルでしか
ないからだ。つまり設計の中の実装の一部の話と言う事だ。
はじめはテスト実装を繰り返すなんて話はない?
「はじめ」が何を指すのか分からないが、プロトタイプ法自体は1990年代前半からすでにあった。
また、それ以前のコボルが主流だった時代には、書式やパラメータを変えるレベルでもリリースが
繰り返されており、そのリリース自体がテストだと考えると、繰り返し行われるリリース自体が
テスト実装繰り返しだと言える。つまり要素自体はあったと言える。


914 :仕様書無しさん:2007/01/22(月) 19:47:55
>ココ電球(∩T∀T)y-~~~~
ごるごるもあ?

915 :仕様書無しさん:2007/01/22(月) 20:11:28
>>913
ばぁかじゃねぇの?なに頓珍漢なこといってるの?w
http://ja.wikipedia.org/wiki/Simula

916 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 20:14:50
simula 後ろ後ろ!

917 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/22(月) 20:16:13
simulaはもう古い 
今はそのまんま東が旬だ


918 :仕様書無しさん:2007/01/22(月) 20:18:00
オブジェクト指向系開発プロセスの教科書にたいてい書かれている、
「この本に書かれている開発プロセスの適用範囲外」には必ず宇宙開発の
話がでてくる。
(覚えている範囲ではジムハイスミスの「適応型ソフトウエア開発」あたりか)

やつらの仕事は基本的にかかっている金額が膨大かつ、人命がかかって
いるので絶対失敗は許されない。リリースの時点で完璧でなくては
駄目で、それ以降の保守イテレーションで修正することはできない。
プライオリティは、生産性<<<品質なのでひとりあたりのコーディング
量が少ないのは科学的な裏づけがあってやってることでしょ。

バグを撲滅するためにJava PathFinderとか形式手法のツールを
つくったり、基本的に一般企業の人(ましてやこのスレにいる連中)とは
違うエリート連中がやっているから、自分たちの物差しで測らない方が
いいと思うぞ。



919 :仕様書無しさん:2007/01/22(月) 20:30:38
>>909、原理主義を名乗るならもうちょっと勉強してからにしないと…

オブジェクト指向には大きく分けてアラン・ケイのメッセージ指向(すべてをメッセージ
ングで…)と、ビョーン・ストラウストラップのクラス指向(ユーザー定義型を「クラス」で
実現する…)がある。現在主流の考え方は後者の流れ。

まず、シミュレーション言語のSIMULA Iで「プロセス」「アクション」と呼んでいたものを
SIMULA 67で汎用言語に発展させるときに「クラス」「オブジェクト」と言い換えたのが
言語機能としての「クラス」と「オブジェクト」の始まり。注意すべきことは、この時点で
は、まだ「オブジェクト指向」という考え方は存在しない。

そのSIMULA 67の「クラス」を利用して、ユーザーによるデータ型定義をサポートできな
いかと考えたのがストラウストラップ。つまり、ユーザー型定義(抽象データ型、カプセル
化)と、クラスの機能である「継承」「仮想関数による動的性(ポリモーフィズム)」が彼の
「オブジェクト指向」であると定義した。

ちなみに、前後するけれど、SIMULA 67の「オブジェクト」をメッセージの受け手にできないかと考え
たのがケイ。「オブジェクト」を非常に小さな(しかし万能の)コンピュータに、「メッセージング」を
高速のネットワークにそれぞれ見立てて、そうしたモデルでコンピューティングシステム
(特に個人向けの…)を構築できないかと模索して試作されたのがSmalltalkシステム。

話を戻して、ストラウストラップの「オブジェクト指向」(主にプログラミングや言語の話)を
ベースに、これをソフトウエアの設計段階に応用できないかと考えたのがブーチ。彼は
Ada(抽象データ型言語、つまり、クラスはないがユーザー定義型を定義できる機能を有する)
での開発の経験を通じて、この考え方に行き着いた。後に出てきたランボー、ヤコブソンと
紆余曲折があってUMLが誕生するまでの話は面倒なので端折る。

総じて、シミュレーションはオブジェクト指向と相性はいいかもしれないけれども、直接の
関係はない。SIMULA、Smalltalkもしかり。ケイのメッセージングの考え方は、今や、
形骸的に扱われるに過ぎず、「オブジェクト指向」を学ぶには混乱を招くばかりで益は少ない。

920 :仕様書無しさん:2007/01/22(月) 20:39:06
思うんだけど、ビョーン・ストラウストラップってオブジェクト指向
の歴史から言ってキーパーソンというか、「オブジェクト指向」に
大して大きな業績のある人なんだろうか。個人的にはC++という実用言語
の開発者というイメージなんだけど。

実際、"C++の設計と進化"とか読むとストラウストラップはオブジェクト指向
より、言語の構文論とか機能や言語の持つトリックとかに興味があるように
思うんだけど。実際、そういうスタンスで開発していたから、C++が
実用言語で足りえたように思う。


921 :仕様書無しさん:2007/01/22(月) 20:46:35
>>920
オブジェクト指向と聞いて、「カプセル化、継承、ポリモーフィズ」なんてみじんも
思い浮かばない人にとっては、たいした貢献はしていない人だと思うよ(反語的に)。

922 :仕様書無しさん:2007/01/22(月) 20:58:57
> オブジェクト指向と聞いて、「カプセル化、継承、ポリモーフィズ」なんてみじんも
> 思い浮かばない人にとっては、たいした貢献はしていない人だと思うよ(反語的に)。
相手をこの程度の見下し方しかできない人にこういうこと言われるとぐんにゃり。
穴があったら叫びたい、ホーア、ホーア。

923 :仕様書無しさん:2007/01/22(月) 21:00:39
やっぱりオブジェクト指向の元はシミュレーションだな。

924 :仕様書無しさん:2007/01/22(月) 21:01:02
>>906

電球の考え方は間違ってるよ。

特に科学技術関連分野って、1000行ですら大変なはず。
試行錯誤を繰り返し、拡張と削減の連続で20万行なんてとんでもなく大変だと思うが。

そういった環境だからこそ、C++が求められ、効果が上げられるんだろう。
もともとC++って、そういった奴らのために存在する言語だし、
一回書けば終りのような、さんすうレベルの単純作業には向かない。労力かかるだけ。

コード数が少ないからダメだとか言うのは、
そりゃ、SEが単なるライン工だという事を自ら認めているようなものだ。

925 :真面目なネラー:2007/01/22(月) 22:22:37
>904 :仕様書無しさん :2007/01/22(月) 17:02:51
>>NASA,「ジェイムズ・ウェッブ宇宙望遠鏡」のソフトをIBM製UMLツールで開発
>ttp://itpro.nikkeibp.co.jp/article/NEWS/20070122/259204/

キターーーーーーっていう感じですね!
こういうプロジェクトがアメリカでどんどん増殖すると、日本にも飛び火して、私も出番がやってきそうーーーー!!
超うれしいニュースです。

926 :仕様書無しさん:2007/01/22(月) 22:35:08
>>925
なんでぇ・・・これからかよ・・・
しかも、Rational Roseって・・・ギェェェェェェェェ!
Rational Rose自体のサポートがおっつかなくて終了ムードに一票w

927 :仕様書無しさん:2007/01/22(月) 22:44:12
いやRoseって普通にうちでも開発に使ってるけど、すんげ〜使いづらいよ。
しかもその記事、C++でコード書くって書いてあるじゃん。
RoseにC++のコード吐き出させて、その上で詳細を記述してくんだろうが
RoseじゃC++の威力を半分も引き出せませんよ。
Roseでモデル書いてエディタでコード書いてリバースかけてモデルに反映してなんてくそ面倒くさい。
情報の二重化は避けましょうってどんな教科書にも書いてあるのに偉い人にはわからんのです。

928 :仕様書無しさん:2007/01/22(月) 22:48:04
ストラウストラップを語るならクラス継承の構造的欠陥を
指摘したクックも語らないと片手落ちじゃねえの?

929 :仕様書無しさん:2007/01/22(月) 23:07:35
>>927
まあ、その辺の不具合(?)も含めてRose(IBM)もいっしょに
成長させていきましょうってプロジェクトなんだろうけど俺には全く未来が見えんw

930 :仕様書無しさん:2007/01/22(月) 23:16:03
>>928
もうちっと詳しく教えてください
_/ ̄|○

931 :仕様書無しさん:2007/01/23(火) 00:12:36
>>930
簡単にかつ乱暴に言うと、データ型による抽象化はオブジェクト指向では
ないと言ってる。それは「手続き」によってなされるべきだと。
クラス継承をそのデータ型に派生させることは、理論上問題があると
証明した人だな。だから「インターフェース継承」を提唱した。

ストラウストラップの言うポリモーフィズムとかはクラス継承あっての
概念だから、それに対して死刑宣告したも同然だなw
実際、ポリモーフィズムとか多用する奴はトラブル起こすだろ?

これはオブジェクト指向プログラミングの話だけど、構造的欠陥と
いうのは設計だろうが何だろうが、問題を起こすのは自明のこと。

932 :仕様書無しさん:2007/01/23(火) 00:21:15
931それって巡り巡って今我々がよく聞く一般的なドグマで言うと、

「実装継承は悪」

って話?

# はずしているかも知れんけど。


933 :仕様書無しさん:2007/01/23(火) 00:28:13
>>932
ちょっと違うな。静的な型チェックしかできないSmallTalkみたいな
言語で継承使っても何の問題もない。(ただのテンプレっちゃそうw)
C++で継承を多用すれば動的な型チェックが多くなる。
そういうコードに問題が多くなる。

934 :仕様書無しさん:2007/01/23(火) 00:36:51
>>933
この論文でいいのかな?あとでゆっくり読んでみるわ
http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf

で、
>C++で継承を多用すれば動的な型チェックが多くなる。
>そういうコードに問題が多くなる。
なんだけど、C++のテンプレートはその問題に対する解答にならなかったのかな?
継承を多用する代わりにポリシークラスを静的に組み合わせて多態性を実現すれば
動的な型チェックはしなくてすみそうだよね

935 :仕様書無しさん:2007/01/23(火) 00:44:21
>>931
> ストラウストラップの言うポリモーフィズムとかはクラス継承あっての
> 概念だから、それに対して死刑宣告したも同然だなw

でもオーバーロードができるC++では問題はないって補足的記述があったような希ガス。
当該論文の最後の方。俺的には、クックの指摘はEiffelの、特に、オーバーロードを認めず、
かつ、理論を無視して引数の共変に固執するメイヤーの継承モデル限定だと思うんだけど…。

936 :仕様書無しさん:2007/01/23(火) 00:46:09
>>944
それだね。読むの苦労するがw

実装の問題ですれ違いになるけど、多態性はどの言語でも実現できるよな。
MSは判っていたのかどうか知らんけど、MFCの頃まではテンプレートを
重視してた。

937 :仕様書無しさん:2007/01/23(火) 00:47:06
>>935
あ、俺が言っているのはこっちね。
http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf

938 :仕様書無しさん:2007/01/23(火) 00:51:41
>>931
いや、それはそう。ただ、C++もその要素を残してしまったのが問題で
ポリモーフィズム自体を否定してるわけではないと思う。
現実には「オーバーロードできる」から問題がないわけではなくて
その意識を常に全員が持ってないとダメだからマズイんでしょ。
そのために代替案を出してるわけであって…

939 :仕様書無しさん:2007/01/23(火) 00:57:35
論文の内容を読んでないけど、タイトルがいきなり
「オブジェクト指向プログラミング対抽象データ型」
ですか。抽象データ型はオブジェクト指向ではないのか。

ここで自分の無知が発覚。
自分の中で、オブジェクト指向=抽象データ型だったけど、
これをやり始めたのがC++で本来は違うんだな。
我ながらアホ過ぎます。

Smalltalkとかあんまり興味がなかったけど、やった方が
いいような気がしてきた。もうちょっと歴史を勉強しよう。

> 一方、Smalltalkとは別にSimulaの影響を受け作られたC++
> (1979年)は抽象データ型のスーパーセットとしてのクラス、
> オブジェクトに注目し、オブジェクト指向をカプセル化、継承、
> 多相性をサポートするものと再定義した。
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
Wikipediaの記事はよくまとまってるね。
これ書いた人も多分、オブジェクト指向原理主義者っぽいけど、
このスレの途中までによくいたエセとは違うリアル原理主義者っぽい。
こんな煽りスレで自分の見えてない部分を見せられるとは思わなかったよ。

重ね重ねアホ過ぎます。



940 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/23(火) 01:09:00
>>918
んなわけねーがな
試験装置つくってデバッグしすりゃいいし、
テスト飛行で何人か死んでもおけ


941 :939:2007/01/23(火) 01:11:58
ここで無知を自覚したんですが、識者の方々、こういう本来の
姿のオブジェクト指向について書かれた教科書って知っています?
(日本語の本がいいです)

ピアソンエデュケーションとかのような書店に並んでいる割と最近の
オブジェクト指向本は本筋からずれている印象を受ける。


942 :仕様書無しさん:2007/01/23(火) 01:17:31
>940
だからその試験装置をつくるのにいくらかかるんだ。
下手するとしょうもないバグでその試験装置も使い捨てになるし。

どっかのサイトに今まであった最大規模のソフトウェアバグに
よる損失の事例が載ってたな。どこだったか失念したが。
ソフトウェアバグによるスペースシャトルの打ち上げ失敗で
歴史に残るような損失を出したこともあるんだぞ。

どうでもいい自分の仕事を基準にしないように。
工員なんだから身の丈を知りなさい!


943 :仕様書無しさん:2007/01/23(火) 01:19:26
俺は原理主義者だけどストラウストラップがオブジェクト指向を理解していたとは到底思えないんだよね。
俺にとってのオブジェクト指向ははじめのSimulaの

開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、というものである。
気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。

だけ。
他はすべて蛇足。



944 :仕様書無しさん:2007/01/23(火) 01:21:59
>>941
「オブジェクト指向」の概念そのものが、いくつもあるなかで
そのどれを取捨選択しているか、という理念を持った本はひとつも
ないと思う。ほとんど、オブジェクト指向として提唱された理論を
全部ぶちこもうとしてるだけ…
もちろん取捨選択にしても、捨てる概念を詳細に紹介した上で理由を
述べて、採用しないとする本がいいんだけど、見たことないね。

結局、英語の論文読んで少しずつ自分なりの「オブジェクト指向」を
固めて行くしかないのが現状だと思うな。

945 :仕様書無しさん:2007/01/23(火) 01:29:11
>>943
これってよく見かけるけど。たぶん誰かの創作だよね。
Simulaはメンバ関数を「メソッド」とかいうふうに呼んでなかったし。

946 :仕様書無しさん:2007/01/23(火) 01:32:46
>>937の論文、要約の段階でフレキシビリティなsmalltalkの継承がうんたらって言ってるが
さすがにsmalltalkはわからんなぁ。eiffelやJavaやC++とは全然違うんだろう。
やっぱsmalltalkの勉強はオブジェクト指向を理解するためにちょっとはやらんとダメか。

947 :仕様書無しさん:2007/01/23(火) 01:39:31
>>943
その「原理主義者」っていったい何なの?
取りあえず、オブジェクト指向の理念は抽象化の理念だとしよう。
それはクラス志向なのかメッセージングなのかインターフェース
なのか、それともそのいくつかの組み合わせなのか…

基本的な理論を提唱した学者の間でも議論があるのに、それに対して
「原理主義」と言えるのが判らない。
君が原理主義者を名乗る以上、あまたの学者と議論できなきゃオカシイ
んだよ?オブジェクト指向と言われるようになってからの「オブジェクト」
という概念がすべてだと思ってるのは短絡的だと思うけどな。

>>946
今でもネットワークやらDBやら、色々なとこで概念的なものは生きている。
実際に使うことがあるかどうかは別にして、かじっといても損はない。

948 :939:2007/01/23(火) 01:42:37
>944
なんか書籍の感想についてはまさにそのとおりとうなずいてしまいます。
実は書籍を書いているレベルの人でもオブジェクト指向全体が俯瞰できて
いる人はあまりいないのでは?という気がしてきます。

そういう意味ではオブジェクト指向って難しすぎるわ。
今更ながら。


949 :仕様書無しさん:2007/01/23(火) 01:50:10
>>861,862,863
俺は20代。Javaは好んで使うほうだ。

同じJavaのコードをオブジェクト指向で書いたものと、そうでないものを
単純にパフォーマンスのみの観点で実行・比較してみろ。
馬鹿な客が1msec遅いといって騒ぎ出して徹夜させられるような業界では即死。

仕事で使えばわかるだろ?




950 :仕様書無しさん:2007/01/23(火) 01:50:11
>>943 はとりあえずソース出せ(だせるもんなら…)、って感じだよね。
ダールやニガートが1960年代に、すでにそういうことを書いていたのなら(つまり、
ケイやストラウストラップのオブジェクト指向が出たあとの「後出し」じゃないなら)
こっちも認識を改めなくもないけれど…。

951 :仕様書無しさん:2007/01/23(火) 01:57:05
>>944
>結局、英語の論文読んで少しずつ自分なりの「オブジェクト指向」を
>固めて行くしかないのが現状だと思うな。

オブジェクト指向の勉強に関してはまさにそのとおりで、
現状はそうするしかないよね。
でもそうすると、明日の仕事をする上でチームの仲間と
オブジェクト指向について共通した認識を持つことは不可能になっちゃうな。



952 :仕様書無しさん:2007/01/23(火) 02:03:35
>>951
それは、驚かさないように、ちょっとずつ(自分も周りも)馴らしてゆくしか…。
ストラウストラップが「カプセル化、継承、ポリモーフィズム」のルーツだと言っても
自分がオブジェクト指向を理解できていると信じている人のほとんどは拒絶反応を示すと思う。

953 :仕様書無しさん:2007/01/23(火) 02:11:17
>>952
いや〜勉強になったよ。ありがとう。
そろそろ寝なきゃならないんで失礼します。
これは実にためになるスレだわ。

954 :仕様書無しさん:2007/01/23(火) 02:13:54
>>948
そうだね。難しすぎるというかカオスになっちゃってるからw
でも、モノは考え方だから。自分なりの定義を見つけられた時に
抽象化という理想に少しだけ近づけるんだと思う。

>>951,952
設計・分析にしろ実装にしろ新しい概念をチームに意識付けるのは
「布教」しかないと思うよ。布教するには自身の勉強と現実との
整合性をどう取るかってのは重要だと思う。

押し付けるだけじゃなくて、心から納得させないとダメだしね。
それは長く遠い道のりかも知れないけど、やりがいはあるっても
言えるんだし頑張ろう…

955 :939:2007/01/23(火) 02:22:19
思い返せば同じようなことを言っている人はときどき見かけることが
あったような気がしたが、全然言ってることが直感的に理解できてなかった。

理解(中身の勉強はこれからだが)してしまえば、当たり前な感じがするけど。

でも、これは気づけというのも何かの弾みがないと無理。
布教する方も色々誤解を受けそうで大変だな。時間もかかるし、
もしかすると結果として納得してくれないかもしれない。

俺もマジで今日は勉強になった。


956 :仕様書無しさん:2007/01/23(火) 06:57:26
>>949

今時、Javaのコーディングに対して、
そんなこと、言う顧客からは、仕事を受けるな
絶対に得しないから、

957 :仕様書無しさん:2007/01/23(火) 07:01:05
>>945
>Simulaはメンバ関数を「メソッド」とかいうふうに呼んでなかったし。
だから何?

>>947
別に厳密な定義なんてどうでもいいんだよ。
実際に認識できるモデルをクラスに反映することさえ満たしてりゃ。
別に誰の考えとったってセミナーボウヤみたいに余計なクラスと作るだの、
再利用だの開発期間の短縮など押し付けてくる奴はいなかっただろ?
「はじめはどうなのよ?」っていう意見を投げることによってそういう雑音を吹き飛ばすことができる。
それだけでいいんだ。

958 :仕様書無しさん:2007/01/23(火) 07:06:06
SimulaはNGワード推奨だな

959 :仕様書無しさん:2007/01/23(火) 07:19:28
>>958
無理だろ。
それ抜きで語れるわけがない。

960 :仕様書無しさん:2007/01/23(火) 07:45:16
カタコトのOO話者を排除するスレはここでつか?

961 :おじゃばさま:2007/01/23(火) 09:44:14
ではそろそろオブジェクト指向の学習方法に入ろう。
ここでも大きな間違いが存在している。それは、「本を見て分かるのは知っている人だけ」と言う事である。
俺が初期に読みあさったオブジェクト指向関係の本は、例の動物や人間、ド○えもんやド○ミちゃんが
出てくる本だった。今考えれば、言いたいことは分かるが、当時としては「だからどうした」と思った。
カプセル化した構造化と比べて、どこが利点なのか不明だった。
時が過ぎ、新人教育のために資料を作る事になった。新人が対象のため、コードに依存しない抽象的な
説明を入れた資料だったが、試しにそれをいろいろな人に見てもらった。
評価は2つに分かれた。「よく分かる」と「よく分からない」だ。
それぞれの評価を行った人を分析してみると、意外なことが分かった。
「よく分かる」と答えた人は、オブジェクト指向をマスターしている人ばかり。
「よく分からない」と答えたのは、新人/ベテランに拘わらずオブジェクト指向未経験者だった。
またこれを書いた俺本人も、当然、分かりやすい資料だと思ったが、ふと気がついた。
これは俺が初期に読んだ動物と人間本に似ている。そしてこれが現在のオブジェクト指向書の縮図だ。

つまりこういう事だ。
発売されているほとんどの原理本は、筆者とオブジェクト指向をマスターした人にとっては良い本で、
オブジェクト指向をマスターしていない人にとっては悪い本なのだ。


962 :おじゃばさま:2007/01/23(火) 09:50:38
>918
宇宙開発とは失敗の連続である。
アポロ計画以前の段階ではアメリカのロケット打ち上げの成功率は30%程度だった。
ロケットが爆発し一瞬にして大金が失われる映像を見た事がある人も多いだろう。
問題は失敗しないことではなく、「失敗から学ぶ」「同じ失敗を繰り返さない」事である。
そこがデスマーチを繰り返すSヨには欠けているのだろう。

963 :仕様書無しさん:2007/01/23(火) 12:18:33
>>957
>>950

964 :仕様書無しさん:2007/01/23(火) 12:20:45
日本が失敗から学べないのは責任者は切腹っていう文化があるからだよ。
旧海軍でも、敗戦の将はことごとく船と一緒に沈んでるし。

失敗の大切なノウハウが生かされないのは、今も同じ。
あれだけ炎上させてよく会社にいれるね、って。

965 :仕様書無しさん:2007/01/23(火) 19:18:48
>>950
その文章何がいいたいのかわからない。

966 :おじゃばさま:2007/01/23(火) 20:35:04
ではオブジェクト指向の学習方法について話を戻そう。
前述の通り書籍を読みあさっても、未経験者には無駄だろう。
まず最初にすべき事は、オブジェクト指向プログラミングを実践することである。
具体的に言うと、
1.Javaの文法を覚える。
2.データをフィールド変数に記述し、ゲッター/セッターを作る。
3.処理をグループ化し、適切なクラス内にメソッドとして記述する。
4.仕様が変更になるたびに、どこのクラスにデータか処理を記述すべきか考え、修正を繰り返す。
(4を行っていると、修正のたびにプログラムが洗練されて行くと感じる頃が来るだろう。その時点で次に進む)
5.オブジェクト本を読み、原理について理解する。

Java以外のオブジェクト指向言語でも構わないが、難易度と用途の多さからJavaをお勧めする。
2でどう組んでいいか分からない時は、誰かのソースを参考にするのがいいが、適切なコードがない。
自社のプロジェクトでWEBアプリケーションを作っているなら、JavaBeanやStrutsのフォームクラスを
参考にするといいだろう。まあ、オブジェクト指向経験者にソースを見せてもらうのがいい。
4を実感するようになるには、個人差はあるが普通にプログラミングに携わっていれば、
半年〜1年半と言う所だろう。

967 :仕様書無しさん:2007/01/23(火) 20:42:29
javaは継承の悪用が激しいから嫌だな。
入門書もろくなのねーし。情報も少ない。クラスで組ませるくせにインスタンスが見え難い。
オブジェクト指向以前にこの辺の環境が悪過ぎる。
流行りの分野ではあるけど何故か少ない情報もあってオススメしない。

968 :仕様書無しさん:2007/01/23(火) 20:48:37
Javaで情報が少ないなら、他のオブジェクト指向はカスばかりだな

969 :仕様書無しさん:2007/01/23(火) 20:52:27
>>968
javaの書籍買ったことないでしょ?
あの入門書の少なさは異常。

970 :仕様書無しさん:2007/01/23(火) 20:53:41
BBSに講義調で書き込む人って
なに様のつもりなんだろう?
ちょっと不思議

971 :仕様書無しさん:2007/01/23(火) 21:17:35
そういうキャラは嫌いじゃない。
つーか今の時代実際にいるのか。
外国の講義の翻訳のイメージしかないんだが。

972 :仕様書無しさん:2007/01/23(火) 21:46:50
ネタでやってると確信できれば
味のあるキャラなのかもしれんが

俺的には、マジで教師気取りの
痛い人にしか見えないんで、
ちょっと遠慮したいキャラだな。


973 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/23(火) 22:15:39
>>942
そうだよ
あの手のモノは測定装置のほうがモノより金がかかる

974 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/23(火) 22:17:07
Beanって何をオブジェクトにしたんだろうか?

975 :仕様書無しさん:2007/01/23(火) 22:46:41
>>974
概念って言葉知ってる?

976 :仕様書無しさん:2007/01/23(火) 23:03:22
>>974
そりゃもう豆でしょうよ。

977 :仕様書無しさん:2007/01/23(火) 23:03:30
本物の業務を想定したサンプルを設計図からコーディングまで誰か出版したら
一挙に普及するべ!!
誰かやれよ!!

978 :仕様書無しさん:2007/01/23(火) 23:38:55
>>977
リアルすぎて初心者にひかれるのがオチ。
携帯Javaとかでお気軽ゲームとかのほうがキャッチーだろ?
まあ、携帯ってのもアレなんだけど。

979 :仕様書無しさん:2007/01/23(火) 23:39:47
>>977
無理だよ。その業務に特化した書物を、他分野の人間が買うと思う?
乗り物とか、動物の鳴き声とか、そういう例でわかんねーヤツには、
どうやって説明してもわかんねんだよ。

980 :仕様書無しさん:2007/01/23(火) 23:42:43
>>979
それはあるな。
体で覚える類のもんに近いしな。

981 :仕様書無しさん:2007/01/23(火) 23:48:33
>>977
家の本棚見回したら、それっぽいの何冊かあるけど。

982 :仕様書無しさん:2007/01/23(火) 23:57:22
憂鬱本の例もよくわからんしね。
憂鬱本ははじめの説明ででてきたSTGの自機、敵、弾でぜひやってほしかった。

983 :仕様書無しさん:2007/01/24(水) 00:26:27
>>957
全然原理主義者じゃないじゃん。いやリアリストでいいと思うけどさw

984 :仕様書無しさん:2007/01/24(水) 00:32:15
>>961 >>966
おもしろい話だな。
個人的には、オブジェクト指向経験者ではなくともプログラム経験者なら
わかりやすいはずだと思うんだが、プログラムも未経験者となると、
たぶん「分からない」と返って来るんだろうな。


せっかく盛り上がっているんで次スレ要るんじゃない?

985 :仕様書無しさん:2007/01/24(水) 00:52:42
昨日のクックの話を切り出した人って誰かわかったわ。
あまりにもタイムリーすぎる話の流れで。
今、寒いところで仕事している人でしょ。


986 :仕様書無しさん:2007/01/24(水) 01:08:41
>>984
じゃよろしく

987 :仕様書無しさん:2007/01/24(水) 01:22:32
>>985
いや俺だけど東京w
別にちょうどそういう問題にぶちあたったわけでもないw
JavaやC++のようなクラス志向をオブジェクト指向と定義してる
人が多いから気になっただけ。
JavaやC++をオブジェクト指向だけが目的の言語として、どうこう
言うのは間違ってると思ってるから言語批判ではないけどね。

988 :仕様書無しさん:2007/01/24(水) 01:38:14
>>986
つくった。
http://pc10.2ch.net/test/read.cgi/prog/1169570260/

989 :仕様書無しさん:2007/01/24(水) 08:25:15
2個できてるぞ。誰だよおい。
http://pc10.2ch.net/test/read.cgi/prog/1169568701/

…需要があるのは分かったが。

990 :仕様書無しさん:2007/01/24(水) 08:47:06
スレまでオブジェクト指向か。

991 :仕様書無しさん:2007/01/24(水) 14:40:55
ポリモーフィズム?

992 :仕様書無しさん:2007/01/24(水) 17:39:24
うめる?

993 :ココ電球(∩T∀T)y-~~~~   ◆tIS/.aX84. :2007/01/24(水) 19:51:22
1000ならオブジェクト指向壊滅

994 :仕様書無しさん:2007/01/24(水) 20:07:38
相変わらず暇そうだな>ココ電

995 :おじゃばさま:2007/01/24(水) 20:15:13
>964
では切腹の文化がプログラマに影響しているのかを考えてみよう。
まずは切腹の定義を明確にする必要がある。
はっきり言うと切腹の論理は分からないが、いくつかの種類があると思う。
1.悪い事をして切腹を強制される。
 一番に思いつくのがこれだ。しかし切腹というより打ち首と判断した方がいいだろう。
2.主君の悪事を諌めるために、主君への忠告として切腹する。
 これは闇奉行の最終回で主人公が主君の悪事を命をかけて止めた行為である。
 常軌を逸した崇高な行為であるが、主君が無情だったら無駄死にになる危険度の高い行為である。
3.悪い事をしたが反省し、お詫びのために腹を切る。
 いわゆる「死んで詫びる」である。1と違うのは強制されない点であろう。
他にもいろいろとありそうだが、きりがないのでこの辺りにしておこう。
ここで最も俺の「切腹」のイメージに近いのは、3番である。
ではこれをプログラマに当てはめてみよう。

996 :おじゃばさま:2007/01/24(水) 20:26:04
ではいくつかの例をあげてみよう。
1.左遷
 プロジェクトの予算が尽きると責任者は左遷される。
 左遷は上司命令で、いわゆる打ち首に当たるため、切腹とは言えない。
2.過労死
 プログラマのおける過労死は、精神的に追い詰められての自殺が多い。
 冷静な判断力を失っているため切腹とは言えない。
3.自殺
 プログラマにおける自殺は2と同様である。つまり切腹とは言えない。
4.バックレ
 プログラマに残された正当な権利であるが、反省がない。つまり切腹とは言えない。
主だった物に該当する物はない。
では逆に切腹をプログラマ世界にアレンジしてみよう。


997 :仕様書無しさん:2007/01/24(水) 21:35:17
ココ電が居ると聞いて市況からきました

998 :仕様書無しさん:2007/01/24(水) 21:35:54
ココ電バンザーイ

999 :仕様書無しさん:2007/01/24(水) 21:37:13
要らねぇからとっとと引き取れ屑

1000 :仕様書無しさん:2007/01/24(水) 21:37:45
ヌル(・ω・)ポリーン

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

290 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)