●●オブジェクト設計は何故流行らないの？●●
1 ：真面目なネラー：
オブジェクト設計は何故、どうして流行しないのだろうか？
とても有益だと思うが？
３０歳代ですが、中途採用試験でオブジェクト設計をやりたいと言っても
ほとんどスルーされます。
結局、ＰＧ屋で我慢してます。
とても有益だと思うが？
３０歳代ですが、中途採用試験でオブジェクト設計をやりたいと言っても
ほとんどスルーされます。
結局、ＰＧ屋で我慢してます。
|
|
|
駅前のオブジェ設計したい
オブジェクト設計ｗｗｗ
人海戦術・長時間労働の蔓延で 客も会社もいかなる手法であろうと設計を評価しません。
今求められるのはお客様が右向けと言えば右を向き、脱げといわれれば脱ぐ従順さです。
今求められるのはお客様が右向けと言えば右を向き、脱げといわれれば脱ぐ従順さです。
5 ：仕様書無しさん：2007/01/04(木) 02:01:26
>>1
周りは、本当の有用さがわかってないのだと感じる。
所詮は、トップの鶴の一声。下が遣りたいからっていっても、そのときは無視。
しかし、社長がオブジェクト設計の技術者を養成しなさいと言ったら、
とたんにその方向に行く。
大変だが、自分が遣りたかったら、業務とは切り離して勉強しておいたほうがよい。
俺はそうした、それでオブジェクト専門の部署ができて、そこの配属になった。
今は、それで給料がもらえている。
しかし、これもそう長くは続かないので、次の飯の種を探しているよ。
周りは、本当の有用さがわかってないのだと感じる。
所詮は、トップの鶴の一声。下が遣りたいからっていっても、そのときは無視。
しかし、社長がオブジェクト設計の技術者を養成しなさいと言ったら、
とたんにその方向に行く。
大変だが、自分が遣りたかったら、業務とは切り離して勉強しておいたほうがよい。
俺はそうした、それでオブジェクト専門の部署ができて、そこの配属になった。
今は、それで給料がもらえている。
しかし、これもそう長くは続かないので、次の飯の種を探しているよ。
6 ：真面目なネラー：2007/01/04(木) 02:36:22
なんで流行しないかは、やっぱ、必要ないからでしょうか？
あちこちの大手、中堅のＩＴを面接しまくればはっきりするのでしょうが、
面接嫌いなものであまり生の情報が入りません。
少なくとも、私が面接した３社の中小ＩＴは、Ｊａｖａ、Ｃ＋＋をやってるのに
オブジェクト設計には関心を示しませんでした。
あちこちの大手、中堅のＩＴを面接しまくればはっきりするのでしょうが、
面接嫌いなものであまり生の情報が入りません。
少なくとも、私が面接した３社の中小ＩＴは、Ｊａｖａ、Ｃ＋＋をやってるのに
オブジェクト設計には関心を示しませんでした。
7 ：仕様書無しさん：2007/01/04(木) 05:05:39
オブジェクト専門ｗ
これは俺も不思議に思っていた。
オブジェクト指向の設計をしたかったんだが、
あまりに見向きもされない（というか理解されない？）ので
しばらくまったく関係のないNEをやっていた。
オブジェクト指向の設計をしたかったんだが、
あまりに見向きもされない（というか理解されない？）ので
しばらくまったく関係のないNEをやっていた。
中堅から上の年代の連中がオブジェクト指向(oo)を理解できないのが一番の理由かと。
そういうオレもベテランと言われる歳だが、積極的にooを推進しようとしても他のベテラン連中が
昔ながらの構造化設計(sd)しかできないため、若手もそのやり方しか身に付かずなかなか広まらない。
sdは仕事の中で見よう見まねでできるのに対し、ooは頭の切換が必要。
なので仕事をやりながら覚えるのは無理。これも壁のひとつだと思う。
そういうオレもベテランと言われる歳だが、積極的にooを推進しようとしても他のベテラン連中が
昔ながらの構造化設計(sd)しかできないため、若手もそのやり方しか身に付かずなかなか広まらない。
sdは仕事の中で見よう見まねでできるのに対し、ooは頭の切換が必要。
なので仕事をやりながら覚えるのは無理。これも壁のひとつだと思う。
原因：「オブジェクト指向設計」と「オブジェクト指向プログラミング」の相性が悪いから
もう思い切って希望者による別チームとした方がいいと思う
構造化しかやろうとしない人間はほっといて
構造化しかやろうとしない人間はほっといて
>>12
×: オブジェクト指向プログラミングから生まれたもの。
○: オブジェクト指向プログラミングから "無理やり" 生み出したもの。
この手の設計技法をひねり出す奴らは、
とりあえず新しいプログラミング技法に「設計」と名前を付けさえすれば
５年は飯を喰えると思っているようだし。
中身なんてどうでもいいんだよ。名前だけが重要なの。
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
そのうちきっと「アスペクト指向設計」とか出てくるぞ。
×: オブジェクト指向プログラミングから生まれたもの。
○: オブジェクト指向プログラミングから "無理やり" 生み出したもの。
この手の設計技法をひねり出す奴らは、
とりあえず新しいプログラミング技法に「設計」と名前を付けさえすれば
５年は飯を喰えると思っているようだし。
中身なんてどうでもいいんだよ。名前だけが重要なの。
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
そのうちきっと「アスペクト指向設計」とか出てくるぞ。
でもさあ、仮にオブジェクト指向設計をやらないとしてSEはPGにどんな設計書をわたせばいいんだろう。
ウチのところだと手続きチックな処理定義書がPGに渡されて
んで基盤技術はASP.NETでおねがいします、とかそんな感じなんだよね。
とうぜんそんなもん何の役にもたたず、むりやりそこから実装レベルでクラス設計しなおすんだけど
ヨソはどうやってるんだろうか。。
ウチのところだと手続きチックな処理定義書がPGに渡されて
んで基盤技術はASP.NETでおねがいします、とかそんな感じなんだよね。
とうぜんそんなもん何の役にもたたず、むりやりそこから実装レベルでクラス設計しなおすんだけど
ヨソはどうやってるんだろうか。。
>>14
>ヨソはどうやってるんだろうか。。
どこも同じだろ？
しかも、それらの仕様書が
下手にオブジェクトチックに書かれていると
もう手が付けられない。
酷いのになると、ユースケース作成時に書いた
ユースケースやアクターを
そのまま "オブジェクト" として設計書に記述してきやがる。
「何を作るのか？」の内容から「どう作るのか？」へ変換することが
本当の設計なのに、
「何を作るのか？」だけを拾い出して（もちろん内容は不十分・・・）、
それらを無理やりクラス図にマッピングなんかしてみたりして、
「完璧な設計だろ！ これだけやってやったのに、何でモノが作れないんだ？」
なんて文句を垂れるのが、今の日本の SE の仕事。
手続きチックな処理定義書のほうが（変に縛られない分）まだ "まし" だよ。
>ヨソはどうやってるんだろうか。。
どこも同じだろ？
しかも、それらの仕様書が
下手にオブジェクトチックに書かれていると
もう手が付けられない。
酷いのになると、ユースケース作成時に書いた
ユースケースやアクターを
そのまま "オブジェクト" として設計書に記述してきやがる。
「何を作るのか？」の内容から「どう作るのか？」へ変換することが
本当の設計なのに、
「何を作るのか？」だけを拾い出して（もちろん内容は不十分・・・）、
それらを無理やりクラス図にマッピングなんかしてみたりして、
「完璧な設計だろ！ これだけやってやったのに、何でモノが作れないんだ？」
なんて文句を垂れるのが、今の日本の SE の仕事。
手続きチックな処理定義書のほうが（変に縛られない分）まだ "まし" だよ。
なるほど、手続きチック処理定義書は単にゴミだが
勘違いOOD設計書は毒になるってわけか。。
となると、OODは推進しないほうが安全ってわけね。
勘違いOOD設計書は毒になるってわけか。。
となると、OODは推進しないほうが安全ってわけね。
会社自体がオブジェクト指向の設計に協力的なら、
実装に落とすまでの道筋の試行錯誤もできるだろうけどねぇ。
実装に落とすまでの道筋の試行錯誤もできるだろうけどねぇ。
そんなものはオブジェクト専門の担当者にまかせておけばいいんだよ！
仕事上、どうしても線表がついてまわるからなぁ。
「試行錯誤の進捗率」の報告の仕方が見つかれば、
多少はこの業界も建設的になると思うのだが。
「試行錯誤の進捗率」の報告の仕方が見つかれば、
多少はこの業界も建設的になると思うのだが。
実装する奴が設計レベルの試行錯誤するのが現状である以上、
はっきりいってコード書かないSE(フィールドSE除く)なんていてもしゃーない。
はっきりいってコード書かないSE(フィールドSE除く)なんていてもしゃーない。
熟練者は試行錯誤してる時間が極端に短いよね。使えない人間はいつまでも
うだうだやってる。そばで見ていて痛々しいぐらいにね。
うだうだやってる。そばで見ていて痛々しいぐらいにね。
22 ：仕様書無しさん：2007/01/04(木) 22:50:34
＞はっきりいってコード書かないSE(フィールドSE除く)なんていてもしゃーない。
コードを書かないのではなく「書けない」というのが最近のSEの常識。
VBだけでも知っていればいい方。酷いのになるとDB設計とUI設計だけのものを
設計書と信じて疑わないヤツもいる。
コードを書かないのではなく「書けない」というのが最近のSEの常識。
VBだけでも知っていればいい方。酷いのになるとDB設計とUI設計だけのものを
設計書と信じて疑わないヤツもいる。
不思議でしゃーねーんだが、なんでコード書かないのよ？
書けないことないだろ、書けばいいだけなんだから。
SEの奴らはどういう風に教わってるの？
書けないことないだろ、書けばいいだけなんだから。
SEの奴らはどういう風に教わってるの？
>SEの奴らはどういう風に教わってるの？
「書かない奴が一番偉い。仕事をしなければ失敗もしない。」と・・・
「書かない奴が一番偉い。仕事をしなければ失敗もしない。」と・・・
25 ：仕様書無しさん：2007/01/04(木) 23:12:15
コードや技術も資産なのに、それが貯まらないとなると
コードを書くのは下っ端のやること。偉いヤツは設計しかしない。
と思いこんでいるのです。
実際、コードなんて書いたことすら無いという自称SEはたくさんいるよ。
そういうヤツに設計させるとロクでもない設計書作るけどな。
と思いこんでいるのです。
実際、コードなんて書いたことすら無いという自称SEはたくさんいるよ。
そういうヤツに設計させるとロクでもない設計書作るけどな。
>>そういうヤツに設計させるとロクでもない設計書作るけどな。
みんなseはドリーマですよ。苦労するのは実際作る人
みんなseはドリーマですよ。苦労するのは実際作る人
>コードを書くのは下っ端のやること。偉いヤツは設計しかしない。
>と思いこんでいるのです。
これ、相当古いと思うんだけど未だにこんなのいうとこあるのかな。
コボラか？
>と思いこんでいるのです。
これ、相当古いと思うんだけど未だにこんなのいうとこあるのかな。
コボラか？
29 ：仕様書無しさん：2007/01/04(木) 23:32:49
わざわざ オブジェクト設計だとか
そんなん数秒でやる仕事だ
そんなん数秒でやる仕事だ
>>29
俺はコード書いては消してって何回もやらないとだめなタイプだから数秒では無理だ。
俺はコード書いては消してって何回もやらないとだめなタイプだから数秒では無理だ。
だって普通にERD+DFDのほうが分析/設計しやすいんだもん。
データベースこねくりまわすだけの業務ソフトに設計レベルのOOなんて必要ない。
データベースこねくりまわすだけの業務ソフトに設計レベルのOOなんて必要ない。
1はSIerじゃなくてIT企業うけたら？
スキル高い人多いし、向上心ある人には向いてると思う
スキル高い人多いし、向上心ある人には向いてると思う
数年前の話なんだけど、「本格的なオブジェクト指向開発をやるのでOODやれる人材が必要」
という話があり、C++やJavaでOOPやってた俺に白羽の矢が当たった。
当時、UMLとか勉強中だったし「オブジェクト指向設計やってくれ」ということで、
未熟ながらも腕を磨きたい一心で参画した・・・。
が、その現場はよどみ切ったコボラたちの巣窟であった。オブジェクト指向を全く知らない人間ばかりだった。
外資系の技術者が来て、たった２日でサジを投げて辞めたこともあったらしい。
(後でわかったが、その案件は新聞紙上で「○○○○が本格的なオブジェクト指向開発をする」と
大々的に宣伝されていたようだ。オブジェクト指向わかる人間が欲しかったらしい。)
俺はめげずに、ユースケース図やクラス図、シーケンス図等を書き、さらにオブジェクト指向が
どういうものかというレベルから現場に啓蒙しようと努めたのだが、ことごとく否定され、
「こんな図は偉い人に見せても理解してもらえない」という理由により、設計図は没にされ、
代わりにフローチャートモドキの変な図やらを書かされるハメになった。
(こいつら、一体何がやりたかったのだろう・・・)
結局、オブジェクト指向の「オ」の字も出来なかったので、ついには俺も撤退させてもらったが、
こういう建前だけ「オブジェクト指向です」という状況もあるかもしれない。(迷惑な話だ。)
という話があり、C++やJavaでOOPやってた俺に白羽の矢が当たった。
当時、UMLとか勉強中だったし「オブジェクト指向設計やってくれ」ということで、
未熟ながらも腕を磨きたい一心で参画した・・・。
が、その現場はよどみ切ったコボラたちの巣窟であった。オブジェクト指向を全く知らない人間ばかりだった。
外資系の技術者が来て、たった２日でサジを投げて辞めたこともあったらしい。
(後でわかったが、その案件は新聞紙上で「○○○○が本格的なオブジェクト指向開発をする」と
大々的に宣伝されていたようだ。オブジェクト指向わかる人間が欲しかったらしい。)
俺はめげずに、ユースケース図やクラス図、シーケンス図等を書き、さらにオブジェクト指向が
どういうものかというレベルから現場に啓蒙しようと努めたのだが、ことごとく否定され、
「こんな図は偉い人に見せても理解してもらえない」という理由により、設計図は没にされ、
代わりにフローチャートモドキの変な図やらを書かされるハメになった。
(こいつら、一体何がやりたかったのだろう・・・)
結局、オブジェクト指向の「オ」の字も出来なかったので、ついには俺も撤退させてもらったが、
こういう建前だけ「オブジェクト指向です」という状況もあるかもしれない。(迷惑な話だ。)
>>32
同意・・・
同意・・・
いかに優れた理論でも、実践に適用できないものは価値はないよな。
俺の会社だけに話を限定すると、オブジェクト指向で設計されたものを実装
してると、最終段階あたりでレスポンスの問題が発生しやすい。しかも、この
問題を解決するにはかなり骨が折れる。
それでもオブジェクト指向で設計する理由は、メンテが楽だから。メンテに
かかる労力を新規開発時にかけられる時間的余裕がある場合に限られる。
してると、最終段階あたりでレスポンスの問題が発生しやすい。しかも、この
問題を解決するにはかなり骨が折れる。
それでもオブジェクト指向で設計する理由は、メンテが楽だから。メンテに
かかる労力を新規開発時にかけられる時間的余裕がある場合に限られる。
一昔前に「モジュール設計」というのが流行ったが、
何をモジュールと呼ぶのかで色々議論していたが、結局は誰もモジュール設計はしなかった
現代はオブジェクト志向も何をオブジェクトと呼ぶのかで色々議論してるだけで
結局は誰もオブジェクト指向設計なんてしないと思う。
最悪の場合はUMLで書かれたで非オブジェクト指向なものが出来るだけ
昔はgoto文がない非構造化プログラムが一杯あった。
何をモジュールと呼ぶのかで色々議論していたが、結局は誰もモジュール設計はしなかった
現代はオブジェクト志向も何をオブジェクトと呼ぶのかで色々議論してるだけで
結局は誰もオブジェクト指向設計なんてしないと思う。
最悪の場合はUMLで書かれたで非オブジェクト指向なものが出来るだけ
昔はgoto文がない非構造化プログラムが一杯あった。
40 ：仕様書無しさん：2007/01/05(金) 15:55:14
つか、クラス的な考え無しで作ってる奴はさっさと消えれば良いのに
スパゲティはのちのちこまる
スパゲティはのちのちこまる
クラス的な考えは無くても良い。
オブジェクト的な考えがあれば良いのでは？
オブジェクト的な考えがあれば良いのでは？
元SE(兼PG。つうか、実装の方が好きだった)です。
昔居た会社では新人研修と社内研修でオブジェクト指向を推し進めていました。
でも、研修でやる部分はファウラー風に言えばドメイン部分だけやって、全体の設計実装までは言及してません。
で、結局まともに実装物を作れないって感じになり、多分現場では役に立ってません。
(実際オブジェクト指向分析/設計/実装しているプロジェクトは見てません)
って、言うか、現場が求めてない感じでしたね～。会社の偉い人が旗振ったのでそれにいやいや従ってたって感じ。
時々オブジェクト指向は銀の弾丸みたいに思っているオッサンも居たけどw
今はもうこの業界を離れて180度違うことをしています。
昔居た会社では新人研修と社内研修でオブジェクト指向を推し進めていました。
でも、研修でやる部分はファウラー風に言えばドメイン部分だけやって、全体の設計実装までは言及してません。
で、結局まともに実装物を作れないって感じになり、多分現場では役に立ってません。
(実際オブジェクト指向分析/設計/実装しているプロジェクトは見てません)
って、言うか、現場が求めてない感じでしたね～。会社の偉い人が旗振ったのでそれにいやいや従ってたって感じ。
時々オブジェクト指向は銀の弾丸みたいに思っているオッサンも居たけどw
今はもうこの業界を離れて180度違うことをしています。
どうして
>今はもうこの業界を離れて180度違うことをしています。
という結論に到ったのかが、全く分からないのだが・・・
>今はもうこの業界を離れて180度違うことをしています。
という結論に到ったのかが、全く分からないのだが・・・
>時々オブジェクト指向は銀の弾丸みたいに思っているオッサンも居たけどw
ウチには原理主義者がいた。
組み込みやらせてみた。
クビになった。
ウチには原理主義者がいた。
組み込みやらせてみた。
クビになった。
46 ：仕様書無しさん：2007/01/05(金) 21:51:06
このスレの結論としては、
コンサルに踊らされて会社の金を散々つぎ込んだ責任者はクビってことでおｋ？
コンサルに踊らされて会社の金を散々つぎ込んだ責任者はクビってことでおｋ？
>>46
いいや。
コンサルのサポートの元で社内全体の技術力向上を目指そうとした
一部の優秀な社員の努力を、社内政治の力だけで踏みにじり、
今までのやり方に強固にしがみつき続けるジジイ共は
クビって結論だろ？
いいや。
コンサルのサポートの元で社内全体の技術力向上を目指そうとした
一部の優秀な社員の努力を、社内政治の力だけで踏みにじり、
今までのやり方に強固にしがみつき続けるジジイ共は
クビって結論だろ？
普段からOOPのありがたみは感じているが、OOAやOODはよく知らない。
ただ、パフォーマンスの問題等で設計->実装の段階で実装レベルの設計やり直しが
発生するようなOODなんて無駄だと思う。流行るわけがない。
ただ、パフォーマンスの問題等で設計->実装の段階で実装レベルの設計やり直しが
発生するようなOODなんて無駄だと思う。流行るわけがない。
>>48
>ただ、パフォーマンスの問題等で設計->実装の段階で実装レベルの設計やり直しが
>発生するようなOODなんて無駄だと思う。流行るわけがない。
それはどんな設計でも発生する可能性はあると思うが？。
>ただ、パフォーマンスの問題等で設計->実装の段階で実装レベルの設計やり直しが
>発生するようなOODなんて無駄だと思う。流行るわけがない。
それはどんな設計でも発生する可能性はあると思うが？。
>>49
OODでは特にパフォーマンスの問題が発生しやすいと聞いたが？
OODでは特にパフォーマンスの問題が発生しやすいと聞いたが？
設計次第としか言い様が
OOでパフォーマンス問題が発生するのは、多くの場合I/O部分を正規化し過ぎるためだと思う。
かつて流行りかけたEntityBeanも同様だったが、何事もやり過ぎはよくない。
例えば「社員テーブル」に対応する「社員クラス」というものがあるとする。
主なデータ項目は、部署コード、社員コード、氏名といったものだが、このまま社員クラスに
すると、部署名を引くのに別のクラス（ex.部署クラス）が必要となる。
確かにこれはこれでデータ構造上は理想的なものではあるが、当然ながらパフォーマンスへの
影響も無視できなくなる。
そこでどうするかと言えば、社員クラスに「部署名」も含めるわけだ。内部的にはViewを使って
部署テーブルを参照する。要するにクラスの正規化崩しを行うことになる。
今までこのやり方を通してきたが、パフォーマンス問題には一度も出くわしたことは無い。
かつて流行りかけたEntityBeanも同様だったが、何事もやり過ぎはよくない。
例えば「社員テーブル」に対応する「社員クラス」というものがあるとする。
主なデータ項目は、部署コード、社員コード、氏名といったものだが、このまま社員クラスに
すると、部署名を引くのに別のクラス（ex.部署クラス）が必要となる。
確かにこれはこれでデータ構造上は理想的なものではあるが、当然ながらパフォーマンスへの
影響も無視できなくなる。
そこでどうするかと言えば、社員クラスに「部署名」も含めるわけだ。内部的にはViewを使って
部署テーブルを参照する。要するにクラスの正規化崩しを行うことになる。
今までこのやり方を通してきたが、パフォーマンス問題には一度も出くわしたことは無い。
56 ：真面目なネラー：2007/01/06(土) 02:14:59
世の中Java屋は多いらしいが、シーケンス図とか設計屋から渡されないで
やっているのかな？
もうそのままPGに落とせるくらいまで、クラス図とシーケンス図を設計屋が
作成すれば、よく言われる再利用による高生産性だ、品質の良い拡張性だ、
・････が実現できるはずなのに。
それに、クラス図を描いている内に、インターフェースの抽出も脳裏に
どんどん浮かんでくる。そして、それらをまとめていくと、おお、あの
デザイン・パターンが使えると閃いてくる。
が、が、が、・・・・が、お前は何をやってるんだ？、という空気が
当方の周りには充満してる。OOPはこのまま終焉するような気さえして来るんだけど。
みなさん、どう予想されますか？
やっているのかな？
もうそのままPGに落とせるくらいまで、クラス図とシーケンス図を設計屋が
作成すれば、よく言われる再利用による高生産性だ、品質の良い拡張性だ、
・････が実現できるはずなのに。
それに、クラス図を描いている内に、インターフェースの抽出も脳裏に
どんどん浮かんでくる。そして、それらをまとめていくと、おお、あの
デザイン・パターンが使えると閃いてくる。
が、が、が、・・・・が、お前は何をやってるんだ？、という空気が
当方の周りには充満してる。OOPはこのまま終焉するような気さえして来るんだけど。
みなさん、どう予想されますか？
57 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/06(土) 02:19:42
メンテナンスしにくいわ
デザパタ使ってプロセス隠蔽したプログラムで
プロセスのレアバグのデバッグやらされてたこっちの身にもなってくれ
使える（可能）と使える（優良）をすりかえてはいけません。
デザパタ使ってプロセス隠蔽したプログラムで
プロセスのレアバグのデバッグやらされてたこっちの身にもなってくれ
使える（可能）と使える（優良）をすりかえてはいけません。
>>55
クラス設計とDB設計をごっちゃにして話をされてもねぇ
クラス設計とDB設計をごっちゃにして話をされてもねぇ
デザパタ使ってプロセス隠蔽？
どういう意味？
プロセスのレアバグ？
は？？まるで意味がわからんｗｗｗｗ
どういう意味？
プロセスのレアバグ？
は？？まるで意味がわからんｗｗｗｗ
60 ：真面目なネラー：2007/01/06(土) 02:36:42
>>57
設計屋さんが、無理やりダザパタを使う様なことしていませんか？
無理やりデザパタをはめ込むと奇怪な可能現象が生じることでしょう。
すなおに使える場合だけに使うと、優良現象が生じると信じてますが。
設計屋さんが、無理やりダザパタを使う様なことしていませんか？
無理やりデザパタをはめ込むと奇怪な可能現象が生じることでしょう。
すなおに使える場合だけに使うと、優良現象が生じると信じてますが。
>>61
おしい！ごっちゃに扱うのではなくて、「見かけ上」ごっちゃに扱えてる
ように振舞うものを作っちゃおうぜってのがOODの思想の中核。
実装段階におけるパフォーマンスの問題を議論する中において、クラスとDBを
ごっちゃに語ってしまう勘違い屋さんの話とはまた別の次元の話。
おしい！ごっちゃに扱うのではなくて、「見かけ上」ごっちゃに扱えてる
ように振舞うものを作っちゃおうぜってのがOODの思想の中核。
実装段階におけるパフォーマンスの問題を議論する中において、クラスとDBを
ごっちゃに語ってしまう勘違い屋さんの話とはまた別の次元の話。
だいたいインスタンスと参照の区別が付いてないＤＢ設計をしてあると腐るよね？
簡単な理由だよ。歴史に学ぶべきだ。
パラダイムシフトは旧パラダイムを信奉する人間が死滅しないと完了しない。
パラダイムシフトは旧パラダイムを信奉する人間が死滅しないと完了しない。
OODはパラダイムシフトを起こすほどの力をもっているのか？ってことを
先に考えるべきでは？
先に考えるべきでは？
>>66
OOがパラダイムシフトとなり得ないのなら当然、流行らない。
OOがパラダイムシフトであるなら前述の理由で、すぐには流行らない。
結局、どちらにしても流行らない（笑）。
OOがパラダイムシフトとなりうるか否かを議論したければ、
別スレを立ててください。
OOがパラダイムシフトとなり得ないのなら当然、流行らない。
OOがパラダイムシフトであるなら前述の理由で、すぐには流行らない。
結局、どちらにしても流行らない（笑）。
OOがパラダイムシフトとなりうるか否かを議論したければ、
別スレを立ててください。
日本語でおｋ
>>58
>>55の例では、クラス設計とDBをごっちゃに扱うのではなく、DBという「実装」を隠蔽しているだけ。
これはO/Rマッピングが生まれた背景なわけだが、そもそもRDB自体がOOとはとても相性が悪いから
ODBが普及するまでは何も変わらないと思う。だがそんな見通しは全く無し。
実際に、DBを使わない組み込み系ではOOはかなり使われている。
>>55の例では、クラス設計とDBをごっちゃに扱うのではなく、DBという「実装」を隠蔽しているだけ。
これはO/Rマッピングが生まれた背景なわけだが、そもそもRDB自体がOOとはとても相性が悪いから
ODBが普及するまでは何も変わらないと思う。だがそんな見通しは全く無し。
実際に、DBを使わない組み込み系ではOOはかなり使われている。
70 ：真面目なネラー：2007/01/06(土) 14:15:44
>>69
>実際に、DBを使わない組み込み系ではOOはかなり使われている。
OOが使われているというのは、クラス図、シーケンス図の設計をしているということなのですか？
それとも、たんにPGのなかでインターフェースの多様態（C++だと仮想関数など）を使ってるということですか？
クラス図、シーケンス図を作成しているのならば、>>69の書き込みはすばらしい情報なのですが。
>実際に、DBを使わない組み込み系ではOOはかなり使われている。
OOが使われているというのは、クラス図、シーケンス図の設計をしているということなのですか？
それとも、たんにPGのなかでインターフェースの多様態（C++だと仮想関数など）を使ってるということですか？
クラス図、シーケンス図を作成しているのならば、>>69の書き込みはすばらしい情報なのですが。
携帯電話を作るプロジェクトでは、完全にOOのやり方だった。
まずドメインを明確にし、そこからクラスを導き出していく。
もちろんシーケンス図やステート図も作った。
クラス図はまず概要レベルから徐々に実装レベルへと落とし込んでいくのだが、結構大変だったなあ。
出荷段階で既知バグは残ってしまったが、プロジェクト自体は最後まで非常に健全だったよ。
まずドメインを明確にし、そこからクラスを導き出していく。
もちろんシーケンス図やステート図も作った。
クラス図はまず概要レベルから徐々に実装レベルへと落とし込んでいくのだが、結構大変だったなあ。
出荷段階で既知バグは残ってしまったが、プロジェクト自体は最後まで非常に健全だったよ。
>>71
>まずドメインを明確にし、そこからクラスを導き出していく。
>もちろんシーケンス図やステート図も作った。
>クラス図はまず概要レベルから徐々に実装レベルへと落とし込んでいくのだが、結構大変だったなあ。
>出荷段階で既知バグは残ってしまったが、プロジェクト自体は最後まで非常に健全だったよ。
どう見てもウォーターフォールです。
本当に(ry
>まずドメインを明確にし、そこからクラスを導き出していく。
>もちろんシーケンス図やステート図も作った。
>クラス図はまず概要レベルから徐々に実装レベルへと落とし込んでいくのだが、結構大変だったなあ。
>出荷段階で既知バグは残ってしまったが、プロジェクト自体は最後まで非常に健全だったよ。
どう見てもウォーターフォールです。
本当に(ry
ウォーターフォールとオブジェクト指向設計は別に矛盾しないのでない？
ここにもいるのか、勘違いしているやつ。
オブジェクト指向は「技法」、ウォーターフォールはプロジェクト推進の「手法」。
別にオブジェクト指向を非インクリメンタル手法でやってもちーっとも構わないのだよ。
同様の勘違いは実はウチの社にもいて困っている。ちょっと本を囓った知ったかクンだけどな。
>>72みたいなヤツがいる限り、オブジェクト指向が流行ることはないような気がする。頼むから勉強してくれ。
オブジェクト指向は「技法」、ウォーターフォールはプロジェクト推進の「手法」。
別にオブジェクト指向を非インクリメンタル手法でやってもちーっとも構わないのだよ。
同様の勘違いは実はウチの社にもいて困っている。ちょっと本を囓った知ったかクンだけどな。
>>72みたいなヤツがいる限り、オブジェクト指向が流行ることはないような気がする。頼むから勉強してくれ。
別に>>72みたいなやり方でもいいじゃん。
ただこれしかないみたいに思ってたらずいぶんアレだけど。
ただこれしかないみたいに思ってたらずいぶんアレだけど。
76 ：仕様書無しさん：2007/01/07(日) 00:49:32
いわゆる業務屋の俺がOOを扱う日は到来するのだろうか。
>>80
組み込みじゃねぇの？
組み込みじゃねぇの？
担当する部分によって異なる。
電話をかける機能は組み込み系。でも電話帳は単なるアプリ。
電話をかける機能は組み込み系。でも電話帳は単なるアプリ。
携帯の開発にウォーターフォールが適しているかどうかは微妙なところ。
まずは商品スペックありきで始まり、開発中にそれがコロコロ変わるしね。
オレが関わったプロジェクトでは、線表自体はウォーターフォールのそれ。
でないと施主様（メーカー）が納得してくれないだろうな。
だがひとつのフェーズの中では行きつ戻りつするから、スパイラルに近いかも。
もちろん初めから仕様変更があることを見越しているから、なるべく依存関係を
断ち切った設計が基本。だがUIに変更が入ると結構痛かった記憶があるなあ。
まずは商品スペックありきで始まり、開発中にそれがコロコロ変わるしね。
オレが関わったプロジェクトでは、線表自体はウォーターフォールのそれ。
でないと施主様（メーカー）が納得してくれないだろうな。
だがひとつのフェーズの中では行きつ戻りつするから、スパイラルに近いかも。
もちろん初めから仕様変更があることを見越しているから、なるべく依存関係を
断ち切った設計が基本。だがUIに変更が入ると結構痛かった記憶があるなあ。
>UIに変更が入ると結構痛かった記憶があるなあ。
UIの変更が痛い "依存関係の断ち切り方" って・・・
何だそりゃ？
何の依存関係を断ち切ったんだ？
もしかして担当者間の依存関係とか？
UIの変更が痛い "依存関係の断ち切り方" って・・・
何だそりゃ？
何の依存関係を断ち切ったんだ？
もしかして担当者間の依存関係とか？
85 ：仕様書無しさん：2007/01/08(月) 00:31:32
プログラマ数ヶ月或いは数年やったくらいで
設計している人が多いからじゃない？
オブジェクト指向の有効な使い方を理解せずに、
基本性質だけ理解してオブジェクト指向わかった気に
なっても設計はできない。
デザパタ理解っていっても、使えなきゃ意味ない。
使える部分と使えない部分、デザパタも大したことなかったり、
ベタで作った方がいい部分、他ツールで同系コード大量出力
した方がいい部分、と、設計する側がうまいことわかってないと
「オブジェクト指向」って一言で言ってもどんなのが出来るか
わかったもんじゃない。
そういや、コピペコード大量に書いてるだけのくせに
「オレはできる。お前はできないからそんなこと言ってるんだろ」
とかトンチンカンなことを言ってる同期がいったけな。
設計の何たるかもわからず、根性だけでコピペコードを
大量に出しさえすれば「とりあえず動く」そして「納品もできる」
さらには、「工数がかかって、会社は儲かる（苦笑）」てな
具合にいい事だらけだから、部長はこういう馬鹿を優遇するんだよな。
（工数がやっただけ出る優良企業相手だから、ということもある）
クソが作ったコードと私の作ったコードと、
中身は違って保守性も安定性も抜群に違っていても、
部長からしたら大した違いではないんだよな。
（続く）
設計している人が多いからじゃない？
オブジェクト指向の有効な使い方を理解せずに、
基本性質だけ理解してオブジェクト指向わかった気に
なっても設計はできない。
デザパタ理解っていっても、使えなきゃ意味ない。
使える部分と使えない部分、デザパタも大したことなかったり、
ベタで作った方がいい部分、他ツールで同系コード大量出力
した方がいい部分、と、設計する側がうまいことわかってないと
「オブジェクト指向」って一言で言ってもどんなのが出来るか
わかったもんじゃない。
そういや、コピペコード大量に書いてるだけのくせに
「オレはできる。お前はできないからそんなこと言ってるんだろ」
とかトンチンカンなことを言ってる同期がいったけな。
設計の何たるかもわからず、根性だけでコピペコードを
大量に出しさえすれば「とりあえず動く」そして「納品もできる」
さらには、「工数がかかって、会社は儲かる（苦笑）」てな
具合にいい事だらけだから、部長はこういう馬鹿を優遇するんだよな。
（工数がやっただけ出る優良企業相手だから、ということもある）
クソが作ったコードと私の作ったコードと、
中身は違って保守性も安定性も抜群に違っていても、
部長からしたら大した違いではないんだよな。
（続く）
86 ：仕様書無しさん：2007/01/08(月) 00:32:44
（続き）
まあ、もともと３～５年くらい下請けで技術磨いてから
上流行程に移行するつもりでいて、まさにそれを実現して
しまったから、こういうアホの環境とは既におさらばしてるんだけど。
下請け生活しながら、本来の目的である「動くものを作ること」を
半ばそっちのけで、「どのように設計するのが本筋か」を
勝手に追求して設計見直しやツール実験なども
勝手にやっていた（そういう環境にあったのは幸い）ので、
ぎゅうぎゅう詰めな生活ではなかった分、時間が持てたよ。
会社が業務ＡＰ専門ではなく、組み込み主体で、
業務ＡＰ方面だった私は管理する人もいなく、
適当にやらせてもらえたということが多い。（幸運）
いきなり上流行程に来ないで下請けで下積み生活しておいて
よかったと今は思っているよ。
周囲見ていると、下請けの言いなりで言い返せなかったり、
設計のよしあしや工数が妥当か判断できない人も多い。
時代は既に変わっていて、
「オブジェクト指向？ あっそ。 だからなに？」
てな具合に当然のものになっているのに、
日本は未だにオブジェクト指向どうこう言ってるのがイタい。
まあ、もともと３～５年くらい下請けで技術磨いてから
上流行程に移行するつもりでいて、まさにそれを実現して
しまったから、こういうアホの環境とは既におさらばしてるんだけど。
下請け生活しながら、本来の目的である「動くものを作ること」を
半ばそっちのけで、「どのように設計するのが本筋か」を
勝手に追求して設計見直しやツール実験なども
勝手にやっていた（そういう環境にあったのは幸い）ので、
ぎゅうぎゅう詰めな生活ではなかった分、時間が持てたよ。
会社が業務ＡＰ専門ではなく、組み込み主体で、
業務ＡＰ方面だった私は管理する人もいなく、
適当にやらせてもらえたということが多い。（幸運）
いきなり上流行程に来ないで下請けで下積み生活しておいて
よかったと今は思っているよ。
周囲見ていると、下請けの言いなりで言い返せなかったり、
設計のよしあしや工数が妥当か判断できない人も多い。
時代は既に変わっていて、
「オブジェクト指向？ あっそ。 だからなに？」
てな具合に当然のものになっているのに、
日本は未だにオブジェクト指向どうこう言ってるのがイタい。
87 ：仕様書無しさん：2007/01/08(月) 00:37:31
88 ：85：2007/01/08(月) 03:39:26
>>87
タダで教えるほど安くは無い。出直せ。
タダで教えるほど安くは無い。出直せ。
あのさ、既に過去に作ったものと同じようなものでない限り、ある程度実装しないと
詳細設計するの無理だよね？俺が馬鹿すぎるだけ？
詳細設計するの無理だよね？俺が馬鹿すぎるだけ？
90 ：85：2007/01/08(月) 03:56:59
>>89
一つ一つの経験は縦のものであっても、
経験が増えてゆけば横の繋がりができ、応用ができるようになるのです。
一言で言ってしまうと、”経験不足”かと。
馬鹿ということはないのでは。 人の能力はさほど変わりませんよ。（例外除く）
わからないうちは、サンプルを実装してみて感触を掴むのはよい方法だと思います。
その程度のスキルのまま”設計”にまわされた人は悲惨です。
設計に根拠がないので、プロジェクトが破綻する可能性が高まります。
一つ一つの経験は縦のものであっても、
経験が増えてゆけば横の繋がりができ、応用ができるようになるのです。
一言で言ってしまうと、”経験不足”かと。
馬鹿ということはないのでは。 人の能力はさほど変わりませんよ。（例外除く）
わからないうちは、サンプルを実装してみて感触を掴むのはよい方法だと思います。
その程度のスキルのまま”設計”にまわされた人は悲惨です。
設計に根拠がないので、プロジェクトが破綻する可能性が高まります。
91 ：仕様書無しさん：2007/01/08(月) 08:47:39
さんざん上司ぶってるくせにこういう都合の良いときだけ
上下関係無視して新入社員に責任が行くのが不思議。
こういうものが表に出るって事は
ベテランのチェックが甘いことも原因の一つなのだから
少しは自覚しろ。
ベテラン力が不足しているのであればベテランの補充をオススメする。
上下関係無視して新入社員に責任が行くのが不思議。
こういうものが表に出るって事は
ベテランのチェックが甘いことも原因の一つなのだから
少しは自覚しろ。
ベテラン力が不足しているのであればベテランの補充をオススメする。
言いたいことはわかるけどこのスレで議題にしてるのは
OOA/OODのことじゃないの？
あなたがいってるのはOOPのレイヤの設計で、
それが流行っていないって主張している奴は流石にいないんじゃないのかな。
OOA/OODのことじゃないの？
あなたがいってるのはOOPのレイヤの設計で、
それが流行っていないって主張している奴は流石にいないんじゃないのかな。
上司としてのスキルが無い奴を
上司として配置せざる終えない現実・・・
上司として配置せざる終えない現実・・・
98 ：仕様書無しさん：2007/01/08(月) 10:07:15
>>72
どこをどう読んだウォーターフォールだと言えるんだ？
どこをどう読んだウォーターフォールだと言えるんだ？
99 ：仕様書無しさん：2007/01/08(月) 11:52:42
>>93
>あなたがいってるのはOOPのレイヤの設計で、
>それが流行っていないって主張している奴は流石にいないんじゃないのかな。
ほんとうにOOPのレイヤの設計は流行しているの？
あなたは、どの地域の方？
やっぱ東京の人？
たぶん大手のSI企業の人なんでしょうね？
>あなたがいってるのはOOPのレイヤの設計で、
>それが流行っていないって主張している奴は流石にいないんじゃないのかな。
ほんとうにOOPのレイヤの設計は流行しているの？
あなたは、どの地域の方？
やっぱ東京の人？
たぶん大手のSI企業の人なんでしょうね？
>>99
大手を派遣でまわりまくってるけど、いまだにそんな環境に出くわしたことないなｗ
大手を派遣でまわりまくってるけど、いまだにそんな環境に出くわしたことないなｗ
101 ：仕様書無しさん：2007/01/08(月) 12:37:27
小規模だったら良いけどね。
大規模だと机上の論理だとすぐ判明。
大規模だと机上の論理だとすぐ判明。
102 ：仕様書無しさん：2007/01/08(月) 12:49:09
分かりづらいから流行らない。
流行らせるなら、どんなバカでも直感的に理解できるものでなければダメ。
流行らせるなら、どんなバカでも直感的に理解できるものでなければダメ。
>>102
わかりやすいと思うんだけどなんかわざわざ複雑に語りたがる奴がいるんだよｗ
わかりやすいと思うんだけどなんかわざわざ複雑に語りたがる奴がいるんだよｗ
>>99
たしかに大手だけど、OOPじゃないコードって逆にどんなのだよ。
Strutsとか使った場合でいうと、Action以降が急に手続き型になる感じか？
O/Rマッパーなんて、モロにドメインモデルを使用する前提なんだから、
少なくともHibernateｔが流行っているっていう表現がまかりとおるんであれば
OOPも流行っているって言えるんじゃないだろうか。
たしかに大手だけど、OOPじゃないコードって逆にどんなのだよ。
Strutsとか使った場合でいうと、Action以降が急に手続き型になる感じか？
O/Rマッパーなんて、モロにドメインモデルを使用する前提なんだから、
少なくともHibernateｔが流行っているっていう表現がまかりとおるんであれば
OOPも流行っているって言えるんじゃないだろうか。
105 ：仕様書無しさん：2007/01/08(月) 14:05:38
>>104
Hibernateｔって何ですか？
O/Rマッパーってオブジェクトとリソース（主にDB？）のマッピング？
う～ん、最近、OOPをあきらめて情報を仕入れてないのでついていけませんね。
でも、本屋では必ず新刊書のチェックはしてるつもりだけど、HibernateｔやO/R
なんていう文字列は見た記憶がありません。
Hibernateｔなるものが流行ってるんですか？？？？
Hibernateｔって何ですか？
O/Rマッパーってオブジェクトとリソース（主にDB？）のマッピング？
う～ん、最近、OOPをあきらめて情報を仕入れてないのでついていけませんね。
でも、本屋では必ず新刊書のチェックはしてるつもりだけど、HibernateｔやO/R
なんていう文字列は見た記憶がありません。
Hibernateｔなるものが流行ってるんですか？？？？
Hibernate。つか細けえよ。
使い慣れない言葉なんて使って説明しようとするからそ（ｒｙ
ん？
OOP流行ってないことにしたい勢力が存在するのか？
OOP流行ってないことにしたい勢力が存在するのか？
>>108
いや、実際、使ってるのみたことないだけに俺はなんとも・・・
いや、実際、使ってるのみたことないだけに俺はなんとも・・・
>>109
何の開発してんの？
何の開発してんの？
プログラミングスタイル（あえてこう言うけど）を普及させる一番良い方法は、
そのスタイルで記述することが一番自然な言語を創って普及させてしまうことだ。
現状、OOPLによる開発がすでに多数派である現実を踏まえて語らないと
話は空転するばかり。
そのスタイルで記述することが一番自然な言語を創って普及させてしまうことだ。
現状、OOPLによる開発がすでに多数派である現実を踏まえて語らないと
話は空転するばかり。
あるDQNソフト会社の営業から
「我が社では、業務経歴書に単なる経歴だけじゃなく、本人の自己アピールも入れて工夫してます」
と、社員たちの経歴書を自慢げに見せられたことがある。(ちなみに俺はフリーね)
それ読んで、うげ～使えなさそーな社員ばかりだな～と思ったのだが、
特に気になったのが、入社して間もないプログラムを始めたての新人が
「Javaのプログラムをやっと少し書けるようになりました。今はデザインパターンの勉強を一生懸命やってます」
という、自己アピール文だった。
実戦経験が全くなく、配列やリストの使いどころさえわかってない(基本的な道具の使い方を知らない)
新人君に、デザインパターンなんかいきなり勉強させてどうするんだろう、さすがDQN会社と思った。
(これ、デザインパターンがワーワー騒がれだした頃の話だけど、最近はどうなんだろうね。)
「我が社では、業務経歴書に単なる経歴だけじゃなく、本人の自己アピールも入れて工夫してます」
と、社員たちの経歴書を自慢げに見せられたことがある。(ちなみに俺はフリーね)
それ読んで、うげ～使えなさそーな社員ばかりだな～と思ったのだが、
特に気になったのが、入社して間もないプログラムを始めたての新人が
「Javaのプログラムをやっと少し書けるようになりました。今はデザインパターンの勉強を一生懸命やってます」
という、自己アピール文だった。
実戦経験が全くなく、配列やリストの使いどころさえわかってない(基本的な道具の使い方を知らない)
新人君に、デザインパターンなんかいきなり勉強させてどうするんだろう、さすがDQN会社と思った。
(これ、デザインパターンがワーワー騒がれだした頃の話だけど、最近はどうなんだろうね。)
>>114
俺が派遣でまわった感じではデザパタなんて使われてるところは一件も無かったと言っておく。
俺が派遣でまわった感じではデザパタなんて使われてるところは一件も無かったと言っておく。
>>115
実装レベルのデザパタなんて、「自分で勝手に使うもの」だといっておく。
実装レベルのデザパタなんて、「自分で勝手に使うもの」だといっておく。
>>116
じゃあ、みたことねぇな。
じゃあ、みたことねぇな。
既存APIのラッパークラスつくってアダプタパターン？
それとかコレクションまわすときindexじゃなくてIteratorつかってイテレータパターン？
このレベルだとどうよ。
それとかコレクションまわすときindexじゃなくてIteratorつかってイテレータパターン？
このレベルだとどうよ。
デザパタって、初めて本を読んでみたとき、
「なあんだぁ、ふだん自分が何気なくやってる実装法と似たようなのばっかりじゃないか」
と思ってしまった。まあ、幾つかは目新しく感じたけど。
デザパタって、鶴亀算とか植木算みたいなもんだろ。方程式の何たるかを知っていたら鶴亀算なんて
何気なく使っていくようになる。方程式より先に鶴亀算から教えるのは間違っている。
それと同じで日々鍛錬しているプログラマなら自然と身についていくものであり、新人にいきなり
やらせるなんて間違っている。
「なあんだぁ、ふだん自分が何気なくやってる実装法と似たようなのばっかりじゃないか」
と思ってしまった。まあ、幾つかは目新しく感じたけど。
デザパタって、鶴亀算とか植木算みたいなもんだろ。方程式の何たるかを知っていたら鶴亀算なんて
何気なく使っていくようになる。方程式より先に鶴亀算から教えるのは間違っている。
それと同じで日々鍛錬しているプログラマなら自然と身についていくものであり、新人にいきなり
やらせるなんて間違っている。
>120
> デザパタって、初めて本を読んでみたとき、
> 「なあんだぁ、ふだん自分が何気なくやってる実装法と似たようなのばっかりじゃないか」
> と思ってしまった。
それに名前をつけたものがデザイン(設計)パターンなんだが。GoF本の前のほうをよく読め。
デザインに適合したコーディング手法(集)、これがデザインパターン。
> デザパタって、初めて本を読んでみたとき、
> 「なあんだぁ、ふだん自分が何気なくやってる実装法と似たようなのばっかりじゃないか」
> と思ってしまった。
それに名前をつけたものがデザイン(設計)パターンなんだが。GoF本の前のほうをよく読め。
デザインに適合したコーディング手法(集)、これがデザインパターン。
122 ：仕様書無しさん：2007/01/08(月) 16:17:10
ある開発に携わる人の全てが、あるレベル以上のオブジェクト指向を
理解していればうまくいく。
けど一人でも変なのが混ざると全てがめちゃくちゃになることもある。
理解していればうまくいく。
けど一人でも変なのが混ざると全てがめちゃくちゃになることもある。
>それに名前をつけたものがデザイン(設計)パターンなんだが。GoF本の前のほうをよく読め。
>デザインに適合したコーディング手法(集)、これがデザインパターン。
そんなもん知っとるし、GoF本だって読んだわい
えらそうにすんな、ボケ！
>デザインに適合したコーディング手法(集)、これがデザインパターン。
そんなもん知っとるし、GoF本だって読んだわい
えらそうにすんな、ボケ！
125 ：仕様書無しさん：2007/01/08(月) 16:52:15
>122
その変なのが120だと思うのは俺だけ？
その変なのが120だと思うのは俺だけ？
まぁまぁ。理論と実践が両輪でなければならないってのは正しいんだし。
127 ：仕様書無しさん：2007/01/08(月) 17:45:40
あまり言われてはいないがデザパタとオブジェクト指向には実はなんの関係もないｗ
てか、デザパタって設計手法ってより、実装技術だよね。
なんかオブジェクト指向の設計とは階層が違う気がする。
なんかオブジェクト指向の設計とは階層が違う気がする。
>>127
少なくともマとかムでは聞き飽きてますけど。。
少なくともマとかムでは聞き飽きてますけど。。
>>114からいってスレ違いなんじゃね？
OOA/OODはかなり一般的な単語と思うが。。
まあ訳すとオブジェクト指向分析/オブジェクト指向設計ってわけだ。
まあ訳すとオブジェクト指向分析/オブジェクト指向設計ってわけだ。
>>127を厳密に適用するとそうなんだが、そんなに精密な話をしているとも思えないので
何でもありじゃなかろうか。
何でもありじゃなかろうか。
なんか「お人よし」な人がこのスレみて勘違いすると気の毒だから一応書くけど、
こんなスレに書いてあることを真に受けちゃダメだよ、マジで。
君と同じぐらいよくわかってない奴が知ったような口利いてるだけだからw
こんなスレに書いてあることを真に受けちゃダメだよ、マジで。
君と同じぐらいよくわかってない奴が知ったような口利いてるだけだからw
なんでそんなに逃げ腰なんだよｗｗ
まあ、とりあえず。
「オブジェクト指向設計」とは何か？
って所から話をしようぜ。
「オブジェクト指向設計」とは何か？
って所から話をしようぜ。
オブジェクト指向プログラミングは流行ってるのに
オブジェクト指向設計は流行ってないってことだよね？
オブジェクト指向設計は流行ってないってことだよね？
140 ：仕様書無しさん：2007/01/08(月) 19:23:35
いくら頑張ってもムダ
プロパーの出す設計書がぐだぐだだから・・・orz
プロパーの出す設計書がぐだぐだだから・・・orz
>>139
オブジェクト指向設計をするためには、まずオブジェクト指向プログラミングのスキルが必須。
今はやっとオブジェクト指向プログラミングが定着してきた時代であり、この時期のプログラマ達が
将来オブジェクト指向設計で花を咲かすのでわ？
オブジェクト指向設計をするためには、まずオブジェクト指向プログラミングのスキルが必須。
今はやっとオブジェクト指向プログラミングが定着してきた時代であり、この時期のプログラマ達が
将来オブジェクト指向設計で花を咲かすのでわ？
歴史はくりかえす。
○○設計をするためには、まず○○プログラミングのスキルが必須。
今はやっと○○プログラミングが定着してきた時代であり、この時期のプログラマ達が
将来○○設計で花を咲かすのでわ？
○○の部分は今は「オブジェクト指向」なのだろうが昔は「構造化」だったなぁ
将来は何になるのやら
○○設計をするためには、まず○○プログラミングのスキルが必須。
今はやっと○○プログラミングが定着してきた時代であり、この時期のプログラマ達が
将来○○設計で花を咲かすのでわ？
○○の部分は今は「オブジェクト指向」なのだろうが昔は「構造化」だったなぁ
将来は何になるのやら
>142
それがパラダイムシフトってこと。ただオブジェクト指向に続くパラダイムはまだ見えてこない。
既存の色んなものは違うんだろうな…。
それがパラダイムシフトってこと。ただオブジェクト指向に続くパラダイムはまだ見えてこない。
既存の色んなものは違うんだろうな…。
っていうか、構造化プログラミングっていうのはあるけど
構造化設計なんて概念あったっけ？w
俺は無いと思うけど。
こんな言葉遣いをする人っていうのはそもそも構造化の意味がよくわかってないんじゃないの？
構造化プログラミングなんて1時間で理解できるぐらい中身スカスカのものでしかないのにね。
構造化設計なんて概念あったっけ？w
俺は無いと思うけど。
こんな言葉遣いをする人っていうのはそもそも構造化の意味がよくわかってないんじゃないの？
構造化プログラミングなんて1時間で理解できるぐらい中身スカスカのものでしかないのにね。
>>144
アスペクト指向は、パラダイムシフトってわけじゃないだろう
アスペクト指向は、パラダイムシフトってわけじゃないだろう
つか今までこの板で見かけたレスの焼き直しばっかじゃねーか。
そろそろ、なんか発展的な議論はじめてくれや。
そろそろ、なんか発展的な議論はじめてくれや。
>>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時間で理解できるぐらい中身スカスカのものでしかないのにね。
「理解する」と「実践する」の間には天と地の開きがある。
学生は黙っとれ
>構造化設計なんて概念あったっけ？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
そもそも「設計」の意味がわからない
絶景！
なんでこんな大祭りなんすか？（マ板級）
４日で１５０レスたぁ。
ことテクニカルな話題ではみんな新しもの好きなのかｗ
４日で１５０レスたぁ。
ことテクニカルな話題ではみんな新しもの好きなのかｗ
あたらしものずき
でなければプログラマになんかなっていない
でなければプログラマになんかなっていない
新しもの好きって、オブジェクト指向が提唱されたの何年前なんだよ
プログラマは、職業としてはかなり新しい
OOは修得している人がまだ少ないから新しい（感じがする）
OOは修得している人がまだ少ないから新しい（感じがする）
新し物好きが年をとるにつれて保守的になるってことね。
>>154
それは嘘だよ。
だってあきらかにＶＣに性能で負けてるのに
自分の使い慣れたエディターからいつまでたっても離れようとしない奴多いじゃない？
ＶＣの使い方いつまでたっても覚えないからプロジェクト内のソースの文字列検索とかできないじゃん。
インテリセンス機能も使わないからいちいちメンバ変数探してコピーして貼ってって作業遅いんだよ。馬鹿。時代は変わったんだよ。ボケ。
って感じの奴いね？
それは嘘だよ。
だってあきらかにＶＣに性能で負けてるのに
自分の使い慣れたエディターからいつまでたっても離れようとしない奴多いじゃない？
ＶＣの使い方いつまでたっても覚えないからプロジェクト内のソースの文字列検索とかできないじゃん。
インテリセンス機能も使わないからいちいちメンバ変数探してコピーして貼ってって作業遅いんだよ。馬鹿。時代は変わったんだよ。ボケ。
って感じの奴いね？
それは新しいものを拒絶してるというよりカッコツケみたいなもんじゃないの？
本物のプログラマは～、じゃないけど出来合いのものをそのまま使うのはかっこ悪い、
みたいな妙な「美学」を持ってる奴っているじゃん。
デキる奴はエディタにこだわるもんだ、みたいな理解不能な奴w
その類だよ。
本物のプログラマは～、じゃないけど出来合いのものをそのまま使うのはかっこ悪い、
みたいな妙な「美学」を持ってる奴っているじゃん。
デキる奴はエディタにこだわるもんだ、みたいな理解不能な奴w
その類だよ。
新しい物好きなんかではない、なぜならエディタに固執する奴がいるじゃないか、
っていうのは動機を問題にしていると思うんですが。。
っていうのは動機を問題にしていると思うんですが。。
>>161
それは結果だろ
それは結果だろ
動機はともかく楽したいって奴はＰＧに向いてるよ
>>158-159
まぁエディタはなぁ・・・こだわる香具師がいても仕方ないかも。
俺はエディタこだわり薄いが、使い慣れたツールってのは大事だ。
こだわりを押し付けられたらたまらん。ということであれば同意。
ということで、
新しいものやより便利なものでも押し付けられたらやりにくい。
設計なんて、自分の世界だけで完結するものじゃないから、
普及がなかなかしないのでは。
OOを理解する奴が増えたら、流行るかもしれないというのに一票。
まぁエディタはなぁ・・・こだわる香具師がいても仕方ないかも。
俺はエディタこだわり薄いが、使い慣れたツールってのは大事だ。
こだわりを押し付けられたらたまらん。ということであれば同意。
ということで、
新しいものやより便利なものでも押し付けられたらやりにくい。
設計なんて、自分の世界だけで完結するものじゃないから、
普及がなかなかしないのでは。
OOを理解する奴が増えたら、流行るかもしれないというのに一票。
165 ：仕様書無しさん：2007/01/09(火) 21:02:47
OOを理解する奴が増えないから、OOが流行らないのか？
OOが流行らないから、OOを理解する奴が増えないのか？
OOが流行らないから、OOを理解する奴が増えないのか？
流行ってないから上が導入しない。だからＯＯできる奴が増えない。
よって後者。
センセーショナルで大流行なら導入ありき。２．０みたく。
よって後者。
センセーショナルで大流行なら導入ありき。２．０みたく。
その効果が数字に出ないから。
違うだろ。本当はみんなわかってるくせに。
まあどんな世界でも人の能力っていうのはピンキリではあるんだが、
この業界の特殊性として本来全く適性がない奴がPGやってるってケースがあまりにも多いからだよ。
まあどんな世界でも人の能力っていうのはピンキリではあるんだが、
この業界の特殊性として本来全く適性がない奴がPGやってるってケースがあまりにも多いからだよ。
169 ：真面目なネラー：2007/01/09(火) 21:28:31
１です。
書き込みが予想より多いので感謝しています。
しかし、知りたいと思っていた”なぜオブジェクト設計は流行らないか？”は
今のところ判然としないですね。
Java、C++のプログラミングに熟練した人は、オブジェクト設計もできるだろうから、
きっとオブジェクト設計も徐々に流行ると、私は個人的に期待していました。
しかし、中小IT業界に居る私は、Java屋、C++屋はよく見かけますが、
オブジェクト設計屋は見たことがありません。
したがって、私も今のところ、
>>164さんの
＞OOを理解する奴が増えたら、流行るかもしれないというのに一票。
と同意見です。
書き込みが予想より多いので感謝しています。
しかし、知りたいと思っていた”なぜオブジェクト設計は流行らないか？”は
今のところ判然としないですね。
Java、C++のプログラミングに熟練した人は、オブジェクト設計もできるだろうから、
きっとオブジェクト設計も徐々に流行ると、私は個人的に期待していました。
しかし、中小IT業界に居る私は、Java屋、C++屋はよく見かけますが、
オブジェクト設計屋は見たことがありません。
したがって、私も今のところ、
>>164さんの
＞OOを理解する奴が増えたら、流行るかもしれないというのに一票。
と同意見です。
C++はなぜ流行り定着したのかを考えればヒントが見えると思うよ。( ･ω･)ﾉ
>>170
>C++はなぜ流行り定着したのか
海外の偉い奴らがこぞって C++ でライブラリを作ったために、
それらを必要とする奴らは、嫌でも使わなくてはならなくなった。
どんな低レベルの SE 達でも、
さすがに「言語の違い」という概念はは理解できたらしい。
>C++はなぜ流行り定着したのか
海外の偉い奴らがこぞって C++ でライブラリを作ったために、
それらを必要とする奴らは、嫌でも使わなくてはならなくなった。
どんな低レベルの SE 達でも、
さすがに「言語の違い」という概念はは理解できたらしい。
>>127
＞あまり言われてはいないがデザパタとオブジェクト指向には実はなんの関係もないｗ
おいおい、初心者も見てるんだからあまり変なこと書くなよｗｗｗ
GOFのデザパタはオブジェクト指向が大前提。
逆に言うと分かりやすいと思うのだが、オブジェクト指向を理解していない人がデザパタの
解説を読んでもよく分からない、もしくは何に役立つか理解できない。
＞あまり言われてはいないがデザパタとオブジェクト指向には実はなんの関係もないｗ
おいおい、初心者も見てるんだからあまり変なこと書くなよｗｗｗ
GOFのデザパタはオブジェクト指向が大前提。
逆に言うと分かりやすいと思うのだが、オブジェクト指向を理解していない人がデザパタの
解説を読んでもよく分からない、もしくは何に役立つか理解できない。
>>173
は？嘘吐くな。
オブジェクト指向を理解していないからそんなこといいだすんだ。
デザパタなんてどうやってもオブジェクト指向と関係ない。
オブジェクト指向の原点はシミュレーション。
実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点。
実装の都合で中間クラスをボコボコ作成するデザパタなんてどうやっても水と油なんだよ。
は？嘘吐くな。
オブジェクト指向を理解していないからそんなこといいだすんだ。
デザパタなんてどうやってもオブジェクト指向と関係ない。
オブジェクト指向の原点はシミュレーション。
実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点。
実装の都合で中間クラスをボコボコ作成するデザパタなんてどうやっても水と油なんだよ。
OOPがいかに生産性を高め、どれほどバグを少なくするかは、優秀なプログラマほどよく分かっていると思う。
だがオレの経験では、そういう人は設計作業に駆り出されることは少なく、効率の良いプログラマとして活躍
することが多いように思う。
それとは逆に、プログラムを書かせても今イチな人がある年齢に達すると設計屋になることが多く、
そういう人ほどレガシーな知識しか持っていないから、当然OOPなど全く理解できていない。
オブジェクト指向設計にはOOPの知識は不可欠のはずだが、そんな状況では相も変わらず構造化設計
でやる以外に無いのではないか。
だがオレの経験では、そういう人は設計作業に駆り出されることは少なく、効率の良いプログラマとして活躍
することが多いように思う。
それとは逆に、プログラムを書かせても今イチな人がある年齢に達すると設計屋になることが多く、
そういう人ほどレガシーな知識しか持っていないから、当然OOPなど全く理解できていない。
オブジェクト指向設計にはOOPの知識は不可欠のはずだが、そんな状況では相も変わらず構造化設計
でやる以外に無いのではないか。
＞実装の都合で中間クラスをボコボコ作成するデザパタなんてどうやっても水と油
こんなのはじめて聞いた。
OO原理主義っていうやつ？
こんなのはじめて聞いた。
OO原理主義っていうやつ？
デザパタ登場以後のオブジェクト指向はそれ以前とは違うものだと思う。
ポリモルフィズム活用しまくりのデザインパターンの利点というと、
モジュール間の依存性をうまく切り離せるとか、
実装の切り替えが動的にできるとか…
そういったプログラム設計上の利点だな。
インターフェース継承こそがオブジェクト指向の神髄であって、
実装継承は駄目という風になったのもデザパタ登場の頃からじゃないか？
ポリモルフィズム活用しまくりのデザインパターンの利点というと、
モジュール間の依存性をうまく切り離せるとか、
実装の切り替えが動的にできるとか…
そういったプログラム設計上の利点だな。
インターフェース継承こそがオブジェクト指向の神髄であって、
実装継承は駄目という風になったのもデザパタ登場の頃からじゃないか？
>>174
＞オブジェクト指向の原点はシミュレーション
これは勘違いだね。正確には「オブジェクト指向の原点はSimulaというプログラム言語」となる。
Simulaはその名のとおりシミュレーションを行うためのPG言語だが、たまたまそうだっただけで
別に事務処理言語であっても良かったのだよ。
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
これには同意。
＞実装の都合で中間クラスをボコボコ作成するデザパタ
これはデザパタが中間クラスをボコボコ作るのではない。OOPで書かれたプログラムを
分析した結果導き出されたパターンを整理したに過ぎない。
オブジェクト指向と無関係と言い切るならC言語（C++でなく）で
Singletonパターンを実装してみてくださいなｗｗｗ
＞オブジェクト指向の原点はシミュレーション
これは勘違いだね。正確には「オブジェクト指向の原点はSimulaというプログラム言語」となる。
Simulaはその名のとおりシミュレーションを行うためのPG言語だが、たまたまそうだっただけで
別に事務処理言語であっても良かったのだよ。
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
これには同意。
＞実装の都合で中間クラスをボコボコ作成するデザパタ
これはデザパタが中間クラスをボコボコ作るのではない。OOPで書かれたプログラムを
分析した結果導き出されたパターンを整理したに過ぎない。
オブジェクト指向と無関係と言い切るならC言語（C++でなく）で
Singletonパターンを実装してみてくださいなｗｗｗ
>>177
＞インターフェース継承こそがオブジェクト指向の神髄
確かにこれはデザパタ登場の頃からよく聞くようになったことは事実だが、
デザパタ登場のはるか以前からあるModula2やObjective-Cでも、
インターフェイスは重要な概念だったらしい。
だから分かる人には分かっていたんだろうなあ。
＞インターフェース継承こそがオブジェクト指向の神髄
確かにこれはデザパタ登場の頃からよく聞くようになったことは事実だが、
デザパタ登場のはるか以前からあるModula2やObjective-Cでも、
インターフェイスは重要な概念だったらしい。
だから分かる人には分かっていたんだろうなあ。
>>179
待て。デザインパターンの実装をOOPLとバインドする必要はない、
っていうのは本当のこと。
今ググったらC言語でもシングルトンを実装することは出来る模様。
だけど普通に考えてデザパタ一番相性がいいのはOOPLだと思うので
俺はデザパタとOOPLが無関係とはおもわないが。
待て。デザインパターンの実装をOOPLとバインドする必要はない、
っていうのは本当のこと。
今ググったらC言語でもシングルトンを実装することは出来る模様。
だけど普通に考えてデザパタ一番相性がいいのはOOPLだと思うので
俺はデザパタとOOPLが無関係とはおもわないが。
>>179
はぁ？全く意味不明。
Singletonなんてどのへんがオブジェクト指向なのよ？
こんなのただの実装技術じゃん。
なにを落としこむとこんなどうしようもない馬鹿なクラスができるの？
>これはデザパタが中間クラスをボコボコ作るのではない。OOPで書かれたプログラムを
>分析した結果導き出されたパターンを整理したに過ぎない。
これやるとオブジェクト指向が覆っちゃうの？
なんで
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
に同意で変なクラスを作ろうとするの？
いらないクラス作ってることに気がつけよ。
こういうわけのわからない無駄に凝ったモン作ろうとする奴がいるから、
実際にあるモデルをそのままプログラムにおとしこめるオブジェクト指向がいいんだろ？
デザパタはオブジェクト指向とは関係ない気持ちの悪い実装技術なんだってｗ
はぁ？全く意味不明。
Singletonなんてどのへんがオブジェクト指向なのよ？
こんなのただの実装技術じゃん。
なにを落としこむとこんなどうしようもない馬鹿なクラスができるの？
>これはデザパタが中間クラスをボコボコ作るのではない。OOPで書かれたプログラムを
>分析した結果導き出されたパターンを整理したに過ぎない。
これやるとオブジェクト指向が覆っちゃうの？
なんで
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
に同意で変なクラスを作ろうとするの？
いらないクラス作ってることに気がつけよ。
こういうわけのわからない無駄に凝ったモン作ろうとする奴がいるから、
実際にあるモデルをそのままプログラムにおとしこめるオブジェクト指向がいいんだろ？
デザパタはオブジェクト指向とは関係ない気持ちの悪い実装技術なんだってｗ
>>182
＞Singletonなんてどのへんがオブジェクト指向なのよ？
おっしゃるとおりの実装技術だが、オブジェクト指向特有の「インスタンス」を制御するための
とても有用な技術だよ。
もしかしてキミは、インスタンスとクラスの区別がついていないのではないか？
だとすると後半の主張も理解できるな。
＞Singletonなんてどのへんがオブジェクト指向なのよ？
おっしゃるとおりの実装技術だが、オブジェクト指向特有の「インスタンス」を制御するための
とても有用な技術だよ。
もしかしてキミは、インスタンスとクラスの区別がついていないのではないか？
だとすると後半の主張も理解できるな。
>>182
お前の望むオブジェクト指向を体現する処理系ってのは存在するのか？
お前の望むオブジェクト指向を体現する処理系ってのは存在するのか？
>>183
だから、なんでそんな話設計で出て来るんだよ。
だから、なんでそんな話設計で出て来るんだよ。
>>185
オブジェクト指向って別に設計に閉じた話じゃないだろ。
オブジェクト指向って別に設計に閉じた話じゃないだろ。
>>178 いや >>175とも別人だよ。
>>173の言うオブジェクト指向と>>174（=>>182かな？）の言う
それとは別物だってことで交通整理できないかな、と思ったのよ。
ちなみにわたしゃOODやOOAは分からん。
でもOOPでいうなら、>>182の言うところの気持ちの悪い実装技術こそが
最近のOOPの最強の武器なんだと思うぞ。
引っかき回してすまんが寝る。
>>173の言うオブジェクト指向と>>174（=>>182かな？）の言う
それとは別物だってことで交通整理できないかな、と思ったのよ。
ちなみにわたしゃOODやOOAは分からん。
でもOOPでいうなら、>>182の言うところの気持ちの悪い実装技術こそが
最近のOOPの最強の武器なんだと思うぞ。
引っかき回してすまんが寝る。
>>185
＞実際にあるモデルをそのままプログラムにおとしこめるオブジェクト指向
というところが分かっているなら、現実に数が限られたモノを表現するのに
Singletonは最適だと思わないかい？
現実にオレはそういう設計を行っているぞ。
どうもキミの主張は、単なる手続きをクラスで表現しただけのように思えるが。
＞実際にあるモデルをそのままプログラムにおとしこめるオブジェクト指向
というところが分かっているなら、現実に数が限られたモノを表現するのに
Singletonは最適だと思わないかい？
現実にオレはそういう設計を行っているぞ。
どうもキミの主張は、単なる手続きをクラスで表現しただけのように思えるが。
Singleton are evil.
おれはSingletonをつかうときには後ろめたさを感じるんだけど
どうだろう。Singletonが有用とか言うとまともにOOでプログラム
を書けないと思われそう(インスタンスの管理が下手糞だ、とか)
なので、そういうことは俺は言わないな。
http://www.c2.com/cgi-bin/wiki?SingletonsAreEvil
C言語でSingletonがしたければ、グローバル変数を定義するだけで
終わりじゃないかとオモタよ。
言葉には定義というものがあって、一般名詞としての
デザインパターンには広義には、OO以外のパラダイムの
設計のテンプレも含まれるんだろうけど、俗に言う固有名詞
としてのデザインパターンはオブジェクト指向、狭義では
GoFのものを指す事が多いな。
デザインパターン(=設計のテンプレート)という考え方自体は
OOとは直交しているという見方も十分ありだとは個人的には思う。
つーか、みんなかなりOOに入れ込んでるな。
俺は仕事はOOでなくても全然いいよ。
個人的にはそんなに生産性が高いとは思わないし。
クラスライブラリは便利だけどな。
おれはSingletonをつかうときには後ろめたさを感じるんだけど
どうだろう。Singletonが有用とか言うとまともにOOでプログラム
を書けないと思われそう(インスタンスの管理が下手糞だ、とか)
なので、そういうことは俺は言わないな。
http://www.c2.com/cgi-bin/wiki?SingletonsAreEvil
C言語でSingletonがしたければ、グローバル変数を定義するだけで
終わりじゃないかとオモタよ。
言葉には定義というものがあって、一般名詞としての
デザインパターンには広義には、OO以外のパラダイムの
設計のテンプレも含まれるんだろうけど、俗に言う固有名詞
としてのデザインパターンはオブジェクト指向、狭義では
GoFのものを指す事が多いな。
デザインパターン(=設計のテンプレート)という考え方自体は
OOとは直交しているという見方も十分ありだとは個人的には思う。
つーか、みんなかなりOOに入れ込んでるな。
俺は仕事はOOでなくても全然いいよ。
個人的にはそんなに生産性が高いとは思わないし。
クラスライブラリは便利だけどな。
>>188
はぁ？なにをいってるの？
オブジェクト指向の利点は
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
なんでしょ？
デザパタなんて使ったら知らない人はわけがわからないじゃない。
上記の利点は完全になくなっちゃうよね？
はぁ？なにをいってるの？
オブジェクト指向の利点は
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
なんでしょ？
デザパタなんて使ったら知らない人はわけがわからないじゃない。
上記の利点は完全になくなっちゃうよね？
>>186
つかお前さっきデザインパターンは実装技術だつってたじゃねーか。
もっといえデザパタをOOPのレイヤに閉じる必要すらないと思うが。
それにアナリシスパターンなんかはどうなるんだよ。
完全にOOA/OODのレイヤがターゲットだと思うが、中間オブジェクトぽこぽこだぞ？
つかお前さっきデザインパターンは実装技術だつってたじゃねーか。
もっといえデザパタをOOPのレイヤに閉じる必要すらないと思うが。
それにアナリシスパターンなんかはどうなるんだよ。
完全にOOA/OODのレイヤがターゲットだと思うが、中間オブジェクトぽこぽこだぞ？
>>189
だから設計関係ないじゃんｗ
例えばその必要数が３つだとしてだからどうしたの？
俺はあくまでＮ個として設計するけど（って個数のあるもんは全部Ｎ個とするから関係ないけど）
ホント意味不明だよね。お前。
だから設計関係ないじゃんｗ
例えばその必要数が３つだとしてだからどうしたの？
俺はあくまでＮ個として設計するけど（って個数のあるもんは全部Ｎ個とするから関係ないけど）
ホント意味不明だよね。お前。
>>192
誰もアナリシスパターンの話なんてしてねぇしｗ
誰もアナリシスパターンの話なんてしてねぇしｗ
>>194
基地外か？
＞デザパタなんて使ったら知らない人はわけがわからないじゃない。
＞上記の利点は完全になくなっちゃうよね？
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
なんだよこれ。恥を知れよ。
基地外か？
＞デザパタなんて使ったら知らない人はわけがわからないじゃない。
＞上記の利点は完全になくなっちゃうよね？
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
なんだよこれ。恥を知れよ。
>>190
＞おれはSingletonをつかうときには後ろめたさを感じるんだけど
確かにSingletonを乱用した結果、グローバル変数と全く変わらないものになるケースも多くあるから
気持ちは分からんでもないが、要は上手く使えということだよな。
例えば数が限られている資源を払い下げてくれるクラスなんかに使うととてもラク。
つーか世の中のDBPOOLの実装は皆そうなってるし。
＞おれはSingletonをつかうときには後ろめたさを感じるんだけど
確かにSingletonを乱用した結果、グローバル変数と全く変わらないものになるケースも多くあるから
気持ちは分からんでもないが、要は上手く使えということだよな。
例えば数が限られている資源を払い下げてくれるクラスなんかに使うととてもラク。
つーか世の中のDBPOOLの実装は皆そうなってるし。
>>195
なんだよ。反論してみろｗ
なんだよ。反論してみろｗ
＞実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
プログラムにおとしこむつったって、ドメインモデル以外の部分はどーすんのよ。
それともアーキテクチャの実装にはオブジェクト指向はあまり役立ってないとでも？
ほい、反論したぞ。
あと>>184にもレスよろ。
プログラムにおとしこむつったって、ドメインモデル以外の部分はどーすんのよ。
それともアーキテクチャの実装にはオブジェクト指向はあまり役立ってないとでも？
ほい、反論したぞ。
あと>>184にもレスよろ。
>>202
共通用語があろうがなかろうが、どの道実装はしなければいけないわけで。
それともデザパタを使わないオレオレ実装の方が、「実際にあるモデル」だけで
構築された「ハナシが通じやすい」実装が可能とでも？
共通用語があろうがなかろうが、どの道実装はしなければいけないわけで。
それともデザパタを使わないオレオレ実装の方が、「実際にあるモデル」だけで
構築された「ハナシが通じやすい」実装が可能とでも？
>>204
おまえさっきデザパタは実装技術だつったろ。
おまえさっきデザパタは実装技術だつったろ。
>>205
だから同じ実装するならなるべくパターンに沿ったものにした方が
誰が見ても理解できるし、メンテもし易くなるんじゃないかという考えが
根底にあるのが「デザパタ」なわけだ。
極論するとオレオレ実装禁止、デザパタを適用すべし、でも良かったの
かもしれんけど、GOFさん達もそこまでは言ってなかっただけ。
デザパタの名称だけで会話ができるなんてのは、ひとつのユートピア
に過ぎないのだろうけど、きっとそれを目指していたんだろうなあと。
だから同じ実装するならなるべくパターンに沿ったものにした方が
誰が見ても理解できるし、メンテもし易くなるんじゃないかという考えが
根底にあるのが「デザパタ」なわけだ。
極論するとオレオレ実装禁止、デザパタを適用すべし、でも良かったの
かもしれんけど、GOFさん達もそこまでは言ってなかっただけ。
デザパタの名称だけで会話ができるなんてのは、ひとつのユートピア
に過ぎないのだろうけど、きっとそれを目指していたんだろうなあと。
>>209
もうお前だまってろ。つか死ねガキ。
もうお前だまってろ。つか死ねガキ。
>>210
キレんなよ。
結局、オブジェクト指向を理解するってことは～であることとかそういうことじゃなくて、
実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
この↑本質が理解できることにつきると思うぜ。
いっぺん頭冷やしたらもう一度みてもらいたいぜ。
どんなオブジェクト指向の亜種よりも原点のシミュレーションで使われてたってところを
よく考えることに意味があると思うぜ。
キレんなよ。
結局、オブジェクト指向を理解するってことは～であることとかそういうことじゃなくて、
実際にあるモデルをそのままプログラムにおとしこめるのが最大の利点
この↑本質が理解できることにつきると思うぜ。
いっぺん頭冷やしたらもう一度みてもらいたいぜ。
どんなオブジェクト指向の亜種よりも原点のシミュレーションで使われてたってところを
よく考えることに意味があると思うぜ。
197みたいのって何シンドロームっていうんだっけ？
俺様の描く「パーフェクトな世界」と違う、と嘆くこの幼稚園児のようなメンタリティw
簡単に言えば期待過剰の裏返しだな
デザパタっていうのはプログラムの構造を文字通りパターン化してラベリングすることによって、
プログラムを書いたり読んだりする際の複雑性をパターン認識によって
「いくらかでも」切り縮めよう、という発想であってもとより銀の弾丸なんかじゃないんだよ。
要はパターンの水準は違えど構造化と同じ発想なんだけど。
構造化っていうのは各人が俺様ルールでコード書くのは止めて
ループや分岐や関数といったパターンにはまるようなコードを書くようにすれば
コードを書く作業も読む作業もパターン認識によってある程度複雑度が減らせるよ、
って発想だったはず。
俺様の描く「パーフェクトな世界」と違う、と嘆くこの幼稚園児のようなメンタリティw
簡単に言えば期待過剰の裏返しだな
デザパタっていうのはプログラムの構造を文字通りパターン化してラベリングすることによって、
プログラムを書いたり読んだりする際の複雑性をパターン認識によって
「いくらかでも」切り縮めよう、という発想であってもとより銀の弾丸なんかじゃないんだよ。
要はパターンの水準は違えど構造化と同じ発想なんだけど。
構造化っていうのは各人が俺様ルールでコード書くのは止めて
ループや分岐や関数といったパターンにはまるようなコードを書くようにすれば
コードを書く作業も読む作業もパターン認識によってある程度複雑度が減らせるよ、
って発想だったはず。
>>209が言うのはオブジェクト指向の理想のひとつだろうな。
実際に分析を繰り返していくと、現実のモデル以外にもいろんなクラスが
必要であることに気づくはず。
なんてことを書くと、それは実装だろうとか言うヤツがいそうだが、実装は実装、
あくまで分析の段階だけのハナシ。
分析フェーズで作るクラス図に<<singleton>>が書かれているのは親切だと思う。
実際に分析を繰り返していくと、現実のモデル以外にもいろんなクラスが
必要であることに気づくはず。
なんてことを書くと、それは実装だろうとか言うヤツがいそうだが、実装は実装、
あくまで分析の段階だけのハナシ。
分析フェーズで作るクラス図に<<singleton>>が書かれているのは親切だと思う。
実際のモデルをそのままクラスにできることと（ドメインモデルの抽出）、
それだけでは動くものをつくれないこと（アーキテクチャの必要性）とは全く矛盾せんわけだが。
ついでに言えば、実際のモデルをそのまま「クラス」にできること
はオブジェクト指向の本質ではない。「クラス指向」ってしってるか？
それだけでは動くものをつくれないこと（アーキテクチャの必要性）とは全く矛盾せんわけだが。
ついでに言えば、実際のモデルをそのまま「クラス」にできること
はオブジェクト指向の本質ではない。「クラス指向」ってしってるか？
>>212
頼むからGOF本読んでから出直せよｗ
頼むからGOF本読んでから出直せよｗ
実際のモデル かぁ
現実世界をモデリングするという作業は
とても難しいよね。
もしかしてこれこそOOA？。
デザパタってデザインという言葉が付いているから
OODみたいに思われがちだけど。
OOPに属する言葉だと思うけどなぁ
だとしたらスレチ(ry
現実世界をモデリングするという作業は
とても難しいよね。
もしかしてこれこそOOA？。
デザパタってデザインという言葉が付いているから
OODみたいに思われがちだけど。
OOPに属する言葉だと思うけどなぁ
だとしたらスレチ(ry
OOAってあれだろ。
ユースケースかいたり、概念レイヤのクラス抽出したりって奴。
ユースケースかいたり、概念レイヤのクラス抽出したりって奴。
この論争のきっかけ。
「デザパタとオブ指向は無関係」
だからオレはそもそもデザパタはオブ指向が前提だと
「デザパタとオブ指向は無関係」
だからオレはそもそもデザパタはオブ指向が前提だと
>>218
いや「デザパタとオブ指向は無関係」ってのを聞きかじった奴が暴れてただけ。
いや「デザパタとオブ指向は無関係」ってのを聞きかじった奴が暴れてただけ。
「UMLとオブ指向は無関係」ってのは常識だからな。
きっとそれと間違えて覚えちまったんだろうな。
きっとそれと間違えて覚えちまったんだろうな。
ケンカせんと、それぞれの分野で実利を追求したらいいんじゃね？
確かにGOF本の全てのパターンはOOPLを前提にしている。
だからといってGOFに記述されたパターン以外のパターンも確かに存在しているわけで
それら全てがOOPLを前提としているわけでは無い。
したがってデザパタという言葉の定義の問題だろ。
GOF本に書かれているパターン群のみをデザパタと呼ぶならそれはOOPと不可分だし、
より一般的な「設計の雛型」という意味を持たせるならそれはOOPと無関係と言う事になるでそ
だからといってGOFに記述されたパターン以外のパターンも確かに存在しているわけで
それら全てがOOPLを前提としているわけでは無い。
したがってデザパタという言葉の定義の問題だろ。
GOF本に書かれているパターン群のみをデザパタと呼ぶならそれはOOPと不可分だし、
より一般的な「設計の雛型」という意味を持たせるならそれはOOPと無関係と言う事になるでそ
>>173には「GOFのデザパタはオブジェクト指向が大前提」と書かれている。
それに妙な坊やがからんできたわけだが。もう寝たかな。
それに妙な坊やがからんできたわけだが。もう寝たかな。
本とか言う時点で坊ちゃん。そんなながれじゃなかったやん。
つか、そろそろデザパタの話はいいだろ。
そもそもデザパタ作った奴ってオブジェクト指向わかってないしなｗ
結局、このスレに来る奴らは
「オブジェクト指向プログラミング」と
「オブジェクト指向設計」の違いが分からない、という訳ね。
「りんご」と「リンゴ・スター」
「バナナ」と「東京ばなな」
「西瓜」と「Suica」
ぐらいの違いがある筈なのだが・・・
「オブジェクト指向プログラミング」と
「オブジェクト指向設計」の違いが分からない、という訳ね。
「りんご」と「リンゴ・スター」
「バナナ」と「東京ばなな」
「西瓜」と「Suica」
ぐらいの違いがある筈なのだが・・・
230 ：仕様書無しさん：2007/01/10(水) 12:58:44
流行らない理由の一端が、わかってきた気がする。
シーア派もスンニ派もイスラム教みたいな話か
232 ：仕様書無しさん：2007/01/10(水) 13:26:01
自分のデザパタに酔いしれたせいで、
パフォーマンスが悪くなっちゃった
パフォーマンスが悪くなっちゃった
>>232
そのデメリットを超えるメリットが存在するならいんじゃね？
そのデメリットを超えるメリットが存在するならいんじゃね？
＞原点は決まってるだけに「どれがいいか」という議論だけに
どういう意味かわからん
どういう意味かわからん
>>227
君はそのデザパタすら理解できてないね
君はそのデザパタすら理解できてないね
Eclipseなんかはガンマが設計しているだけあって、設計が
すごいと聞いたことがある。けど解りづらいらしい。
(俺はJavaの人じゃないから良く知らん。一応、話を聞いた相手は
かなりハイレベルな人だ)
いや、GOFがOO解ってなかったらこの世にどれぐらいOOが
解っている人がいるか疑問だ。それこそ難しすぎるでしょ。
STLの作者(アレックス・ステファノブ)がOO解ってない
(ということは本当はないと思うが)というのなら、アリかもしれんが。
こっちはOO嫌いでJavaなんて糞だと本人が言っているし。STLは
iostream系と例外以外は継承をつかってない。
すごいと聞いたことがある。けど解りづらいらしい。
(俺はJavaの人じゃないから良く知らん。一応、話を聞いた相手は
かなりハイレベルな人だ)
いや、GOFがOO解ってなかったらこの世にどれぐらいOOが
解っている人がいるか疑問だ。それこそ難しすぎるでしょ。
STLの作者(アレックス・ステファノブ)がOO解ってない
(ということは本当はないと思うが)というのなら、アリかもしれんが。
こっちはOO嫌いでJavaなんて糞だと本人が言っているし。STLは
iostream系と例外以外は継承をつかってない。
239 ：仕様書無しさん：2007/01/11(木) 09:40:41
「汎用性とか柔軟性とかより、パフォーマンスをあげろ」って
上司がいったから
オブジェクト設計の中に、Ｃのゴリゴリプログラムを混ぜてんだけど
なんかＲｲｐﾟされてる気になる
上司がいったから
オブジェクト設計の中に、Ｃのゴリゴリプログラムを混ぜてんだけど
なんかＲｲｐﾟされてる気になる
同僚がGOFのことを「ごふ」と発音するんだが、こけた頬に青白い顔のせいで妙に笑える
ごふであってる。ごふごふ
なんとなくスレの流れを読んで・・・
外部設計と内部設計は分けて話しませんか？
外部設計と内部設計は分けて話しませんか？
何故流行らないのか？
それは直感的じゃないから。
俺は好きだけども。
例えば次元数の事を考えるとわかりやすい。
次元数は上がると普通はわかりにくさが増える。
それは単純に数が増えたのもあるけど、
それによって直感的な部分が減るのも大きな原因。
という訳で、次に流行るのは直感指向のS言語ですw
なんちゃってw
それは直感的じゃないから。
俺は好きだけども。
例えば次元数の事を考えるとわかりやすい。
次元数は上がると普通はわかりにくさが増える。
それは単純に数が増えたのもあるけど、
それによって直感的な部分が減るのも大きな原因。
という訳で、次に流行るのは直感指向のS言語ですw
なんちゃってw
245 ：仕様書無しさん：2007/01/12(金) 23:29:17
このスレを見る限りでは、流行らないのはオブジェクト設計そのものに
問題があるわけではなく、使える者が少なすぎることに原因がありそうだ。
Java、C++が組めればオブジェクト指向を理解していると思っている香具師
が多いのも原因の一つかもしれないが。。。。
問題があるわけではなく、使える者が少なすぎることに原因がありそうだ。
Java、C++が組めればオブジェクト指向を理解していると思っている香具師
が多いのも原因の一つかもしれないが。。。。
246 ：仕様書無しさん：2007/01/12(金) 23:55:39
まぁあれだ。基本設計をooで書く必要は全くないが、
ooで詳細設計を立てて書けない奴は駄目だと思う。
ooで詳細設計を立てて書けない奴は駄目だと思う。
流行がそんなに素晴らしいならWindowsは素晴らしいことだし、
ガングロ、コギャルは素晴らしいみたいだな
素晴らしいものが流行するならLispはもっと評価されてもいいはず
ガングロ、コギャルは素晴らしいみたいだな
素晴らしいものが流行するならLispはもっと評価されてもいいはず
使いやすいから流行するんだよ。
>>249
だからVBが流行したんだな。
だからVBが流行したんだな。
>>252
否定はできんな。
否定はできんな。
254 ：仕様書無しさん：2007/01/13(土) 11:17:28
勉強するのが単にめんどくさいからでは？
Ｃから入った人ばっかでは？
俺は多分Ｃから入ったらもうやらなかったと思うよ
だって多いしだるいもんもんもん
255 ：仕様書無しさん：2007/01/13(土) 12:08:52
OODって無理がないか？
デザインとしてはそれほど不自然ではないけれど、RPCだDBアクセスだの
が挟まっていることをまったく考慮しておらず、むちゃくちゃパフォー
マンスが悪いに決まっているライブラリを設計・実装してしまい、アプリ
実装担当に迷惑を掛けまくるアホを見ることに事欠かないんだけどさ。
設計時点でパフォーマンスとかの低レベル層の考慮が必要な作業にな
ってしまうのに、そのあたりの知識も見識もない人間が設計するのは
良くないんではないかなと。で、そこまで出来る人間はすでに別技法
での開発に熟練してるので、今さらリスクを犯してよくわからん技法
を身につける必要はないと。
デザインとしてはそれほど不自然ではないけれど、RPCだDBアクセスだの
が挟まっていることをまったく考慮しておらず、むちゃくちゃパフォー
マンスが悪いに決まっているライブラリを設計・実装してしまい、アプリ
実装担当に迷惑を掛けまくるアホを見ることに事欠かないんだけどさ。
設計時点でパフォーマンスとかの低レベル層の考慮が必要な作業にな
ってしまうのに、そのあたりの知識も見識もない人間が設計するのは
良くないんではないかなと。で、そこまで出来る人間はすでに別技法
での開発に熟練してるので、今さらリスクを犯してよくわからん技法
を身につける必要はないと。
VＣから入った人ばっかりとか。
ここでオブジェクト指向2.0を提案する
教義と現世でのご利益次第では
>>255
設計者の無能さと OOD の問題点との切り分けが出来ていないな。
多分 >>255 のソースも、上と同じように
ちゃんと切り分けを行っていない
「スイス・アーミーナイフ」みたいなもの
ばかりなんだろう。
設計者の無能さと OOD の問題点との切り分けが出来ていないな。
多分 >>255 のソースも、上と同じように
ちゃんと切り分けを行っていない
「スイス・アーミーナイフ」みたいなもの
ばかりなんだろう。
260 ：仕様書無しさん：2007/01/13(土) 17:40:37
テレビで、渋谷の女子高生にインタビューして「やっぱー、これからはー、オブジェクト志向？
みたいな？やだちょーかわいくね？」とか言わせるやらせ番組を流せば流行するよ。
みたいな？やだちょーかわいくね？」とか言わせるやらせ番組を流せば流行するよ。
261 ：仕様書無しさん：2007/01/13(土) 17:42:58
１０人中１、２人しかわからないオブジェクト設計は、現場では使えない。
頼むからPG屋さんたちもオブジェクト設計を解読できるまでになってくれ！！
頼むからPG屋さんたちもオブジェクト設計を解読できるまでになってくれ！！
人集める予算削っておいて、優秀な人が来ない、なんて笑い話だよなぁ。
>>262
そうだね。
そうだね。
>>265
そうだね。
そうだね。
267 ：仕様書無しさん：2007/01/14(日) 09:00:30
>>262
OOA, OOD, OOP が出来る人をどうやって見分けるかが問題だな。
現状ではなんちゃってOOが大部分だから選別作業も大変そうだし。
あとOO出来る人の単価は出来ない人の何割増が妥当なんだろうか？
OOA, OOD, OOP が出来る人をどうやって見分けるかが問題だな。
現状ではなんちゃってOOが大部分だから選別作業も大変そうだし。
あとOO出来る人の単価は出来ない人の何割増が妥当なんだろうか？
268 ：仕様書無しさん：2007/01/14(日) 10:29:24
OODは最後の最後で破談、じゃなくて破綻ってことがまれに起こるから、
大規模開発では怖くて使えない。
大規模開発では怖くて使えない。
じゃあ破綻しないOOD++じゃないと流行らん、と。
理想形はOOD#
「設計が悪い」僕にもそう思って
>>272
いや、なる。
作ってみたら実用的な速度がでねぇってのは設計じゃでてこないっしょ？
そんときにＯＯで作ったモンをばらして速度が出る構造にするってのはちょっと手間。
たまにＯＯで設計をすることばっかりにとらわれて、自分の設計に悪酔いしまくってて手段と目的が逆転してる
アフォなのいるから要注意と言っておく。かなりねちっこい馬鹿が多くて面倒なのも特長ｗ
いや、なる。
作ってみたら実用的な速度がでねぇってのは設計じゃでてこないっしょ？
そんときにＯＯで作ったモンをばらして速度が出る構造にするってのはちょっと手間。
たまにＯＯで設計をすることばっかりにとらわれて、自分の設計に悪酔いしまくってて手段と目的が逆転してる
アフォなのいるから要注意と言っておく。かなりねちっこい馬鹿が多くて面倒なのも特長ｗ
>>274
じゃあ、逆にＯＯじゃなかったらどうなるのさ？
ＯＯじゃなければ、
「作ってみたら実用的な速度がでねぇ」
なんてことが起こらないのか？
それとも
「ばらして速度が出る構造にする」
ってのは、手間がかからないのか？
それとも
「自分の設計に悪酔いしまくってて手段と目的が逆転してるアフォ」
が出てこないのか？
じゃあ、逆にＯＯじゃなかったらどうなるのさ？
ＯＯじゃなければ、
「作ってみたら実用的な速度がでねぇ」
なんてことが起こらないのか？
それとも
「ばらして速度が出る構造にする」
ってのは、手間がかからないのか？
それとも
「自分の設計に悪酔いしまくってて手段と目的が逆転してるアフォ」
が出てこないのか？
>>274
クラスの粒度が細かすぎるとか、逆に荒すぎて、
実質、コーディングしながら設計することに
なってるとか、ほとんどの場合、設計段階の問題
っていうか、自分でも「設計に悪酔いしまくってて」
って、設計って書いてるじゃん。
クラスの粒度が細かすぎるとか、逆に荒すぎて、
実質、コーディングしながら設計することに
なってるとか、ほとんどの場合、設計段階の問題
っていうか、自分でも「設計に悪酔いしまくってて」
って、設計って書いてるじゃん。
>>275-277
別にＯＯ特有のことをあげる必要もないと思うんだが。
処理速度の考慮漏れなんてそれこそ>>271のような問題で起こることじゃん。
俺の発言は>>272のレスを否定するだけの意味しかもたん。
>OODできれいに出来てれば、コーディングレベルでは、 そんなに、酷くなりようが無い。
これはtrueかfalseかで言ったらfalseだよね？
ってだけ。
別にＯＯ特有のことをあげる必要もないと思うんだが。
処理速度の考慮漏れなんてそれこそ>>271のような問題で起こることじゃん。
俺の発言は>>272のレスを否定するだけの意味しかもたん。
>OODできれいに出来てれば、コーディングレベルでは、 そんなに、酷くなりようが無い。
これはtrueかfalseかで言ったらfalseだよね？
ってだけ。
ああ、かなり説明が飛んだな。
つまり組んでみて処理速度の考慮漏れがわかるのって結果論だよね？
問題があることがわかって、そこからそもそもどの時点が悪いの？ってなって
処理速度を考慮してない設計がまずいとかなるのっておかしくない？
それでＯＯＤだから・・・ってのは業務やるうえであまりにも現実味がないと思うんだけど。
つまり組んでみて処理速度の考慮漏れがわかるのって結果論だよね？
問題があることがわかって、そこからそもそもどの時点が悪いの？ってなって
処理速度を考慮してない設計がまずいとかなるのっておかしくない？
それでＯＯＤだから・・・ってのは業務やるうえであまりにも現実味がないと思うんだけど。
A「振り子打法はすばらしい打法なんだよ」
B「でも草野球チームが振り子打法を取り入れてもプロには勝てないよ」
A「それは選手がヘボイからだよ。イチローが振り子打法すればメジャーでも通用する」
B「・・・・・・」
B「でも草野球チームが振り子打法を取り入れてもプロには勝てないよ」
A「それは選手がヘボイからだよ。イチローが振り子打法すればメジャーでも通用する」
B「・・・・・・」
>>280
それで振り子打法がいい方法だって主張してるならかなり脳みその損傷が激しいと思う。
それで振り子打法がいい方法だって主張してるならかなり脳みその損傷が激しいと思う。
>>280
どうすれば振り子打法がいい方法であることを証明できるんだろうな？
結構、この例に似てるのかもわからんな。
イチローが有名になったことで振り子打法は知られるようになったけどそれがいい方法かどうかはわからないままだよな。
あくまでもそれでも可能ってだけの話で。
本来の振り方に変えたらもっと打率はあがるかもしれないし、
あまり知られてはいないがイチロー自身は足が速くてアウトになるはずの内野安打をヒットに変えることができるだけで
振り子自身はあまり効果が無いってデータみたことあるしな。
どうすれば振り子打法がいい方法であることを証明できるんだろうな？
結構、この例に似てるのかもわからんな。
イチローが有名になったことで振り子打法は知られるようになったけどそれがいい方法かどうかはわからないままだよな。
あくまでもそれでも可能ってだけの話で。
本来の振り方に変えたらもっと打率はあがるかもしれないし、
あまり知られてはいないがイチロー自身は足が速くてアウトになるはずの内野安打をヒットに変えることができるだけで
振り子自身はあまり効果が無いってデータみたことあるしな。
>>283
じゃ、やっぱこの例でいうと
オブジェクト設計＝振り子打法
であって
イチローと振り子打法の関係のように
設計ができることとオブジェクト設計ができることは結びつかないってことか。
まあ、そうだな。
じゃ、やっぱこの例でいうと
オブジェクト設計＝振り子打法
であって
イチローと振り子打法の関係のように
設計ができることとオブジェクト設計ができることは結びつかないってことか。
まあ、そうだな。
デキる人がオブジェクト設計をやるとさもオブジェクト設計がすごそうに見えると。
要は。
まあ、全否定できないけど。
要は。
まあ、全否定できないけど。
逆にいえば、コードが悪いのはPGのせいで
OODだからといって、コードが悪くなることも、
ないって結論になるが良いよね？
OODだからといって、コードが悪くなることも、
ないって結論になるが良いよね？
そういう結論に至ったレスを教えてほしいです。
なんとなくスレタイの理由がわかってきたな。
Ｑ：オブジェクト指向設計は何故流行らないの？
Ａ：オブジェクト指向設計が従来（もしくはその現場で前から使用している）の設計手法よりすぐれた方法であることを説明できないから
だな。
Ｑ：オブジェクト指向設計は何故流行らないの？
Ａ：オブジェクト指向設計が従来（もしくはその現場で前から使用している）の設計手法よりすぐれた方法であることを説明できないから
だな。
A:実際２倍も３倍も優れていないから。（多少は優れているが）
です。
です。
290 ：仕様書無しさん：2007/01/14(日) 20:07:21
つまり、従来型設計が悪い、オブジェクト指向が良いからではない。
どちらにしても、馬鹿の設計が駄目なだけ。
どちらにしても、馬鹿の設計が駄目なだけ。
まずオブジェクト指向設計と従来設計の成果物を定義して
その相違を詳らかにしないと全く建設的な議論がすすまないと思われる。
その相違を詳らかにしないと全く建設的な議論がすすまないと思われる。
いや、>>288だけど、>>289の方が正しい気がする。
大して効果が見込めないにもかかわらず>>291みたいなことを説明してまでやる意味がない。
従来のやり方だってメリットデメリットもそれぞれあるだろうし、
従来のやり方なら問題にならなかった部分だったのに新しいやり方に切り替えたがために
出てしまう問題のが余計ややこしい話しになる気がする。
もちろん、従来のやり方の問題であるなら誰かしら経験があるし、
新しいやり方ってのは新しい不具合を呼び込む可能性もある。
やっぱり最大の理由は>>289の「効果が薄い」ってのが一番の理由のような希ガス。
要はリスクとリターンを考えたときに手を出すべきじゃないってことだな。
単純に古いやり方にしがみついてるのとはちょっと違う。ＰＣとそろばんみたいな明らかに効果がわかるもんならいいんだけどな。
大して効果が見込めないにもかかわらず>>291みたいなことを説明してまでやる意味がない。
従来のやり方だってメリットデメリットもそれぞれあるだろうし、
従来のやり方なら問題にならなかった部分だったのに新しいやり方に切り替えたがために
出てしまう問題のが余計ややこしい話しになる気がする。
もちろん、従来のやり方の問題であるなら誰かしら経験があるし、
新しいやり方ってのは新しい不具合を呼び込む可能性もある。
やっぱり最大の理由は>>289の「効果が薄い」ってのが一番の理由のような希ガス。
要はリスクとリターンを考えたときに手を出すべきじゃないってことだな。
単純に古いやり方にしがみついてるのとはちょっと違う。ＰＣとそろばんみたいな明らかに効果がわかるもんならいいんだけどな。
銀の男根は無いって誰かが言ってただろ？
スレ最初から読んだがoo ooっ五月蝿いね
大体、OOの効果が出るのは保守や機能転用の時なんだから。
派遣やら外注がとりあえず言われた仕様を満たしていれば
後は知らない！直すなら金よこせ！
みたいなプログラムを量産しているうちは無理だろ。
派遣やら外注がとりあえず言われた仕様を満たしていれば
後は知らない！直すなら金よこせ！
みたいなプログラムを量産しているうちは無理だろ。
そりゃ可能は可能だろうよ。
だから
従来＜ＯＯ
って話だろ。問題はその差が㍉か㌔かってことだが。
だから
従来＜ＯＯ
って話だろ。問題はその差が㍉か㌔かってことだが。
>>298
だから、別にその不等号からしておかしいわけで。
別にIOOを全否定しないが、使い手次第でどうとでもなる。
従来手法できちんとできる人ならOOも出来るし、出来ない奴は何を使っても糞を作る魔術師。
だから、別にその不等号からしておかしいわけで。
別にIOOを全否定しないが、使い手次第でどうとでもなる。
従来手法できちんとできる人ならOOも出来るし、出来ない奴は何を使っても糞を作る魔術師。
>>299
> 従来手法できちんとできる人ならOOも出来るし、出来ない奴は何を使っても糞を作る魔術師。
たしかにその通りなんだが、それで全てを結論付けてしまうと
そもそもソフトウェア工学なんて要らなくなるわけで
世の中COBOLが１つあれば十分ってことになってしまう。
> 従来手法できちんとできる人ならOOも出来るし、出来ない奴は何を使っても糞を作る魔術師。
たしかにその通りなんだが、それで全てを結論付けてしまうと
そもそもソフトウェア工学なんて要らなくなるわけで
世の中COBOLが１つあれば十分ってことになってしまう。
>>301
それは違う論理。
貴方の考えの結論は冷戦崩壊で出ているわけだが。
社会主義的な単一言語、技術での競争否定は腐敗の始まり。
まずね、ソフト工学とかいってるけど、実際のプログラマ名乗る人の半分以上は、そのソフト工学っていうものを知らない。
自分たちのやってることが工学、生産という認識が無い。
それは違う論理。
貴方の考えの結論は冷戦崩壊で出ているわけだが。
社会主義的な単一言語、技術での競争否定は腐敗の始まり。
まずね、ソフト工学とかいってるけど、実際のプログラマ名乗る人の半分以上は、そのソフト工学っていうものを知らない。
自分たちのやってることが工学、生産という認識が無い。
＞実際のプログラマ名乗る人の半分以上は、―
３分の１居れば上等だとおもうよ。
てか車の仕組み知らなくても運転できるとかってのと一緒だお。
３分の１居れば上等だとおもうよ。
てか車の仕組み知らなくても運転できるとかってのと一緒だお。
それもちとちがう。
生産工学、看板方式の理論を知らなくても現場が動くのと同じってこと。
生産工学、看板方式の理論を知らなくても現場が動くのと同じってこと。
305 ：仕様書無しさん：2007/01/14(日) 23:52:46
>>302
すべての質は個人の技量みたいな書き方をしたからそう言ったの。
それを言い出したらOOとか議論する意味がないでしょ。
もし意味がないって本気で思ってるなら、あなたはこのスレに居る必要はないよ。
すべての質は個人の技量みたいな書き方をしたからそう言ったの。
それを言い出したらOOとか議論する意味がないでしょ。
もし意味がないって本気で思ってるなら、あなたはこのスレに居る必要はないよ。
車の仕組み知らなくても皆、燃費のいい車、馬力のある車に乗り換える。
皆、新しい車に乗り換える。
なら判るかな？車は伊達で作られてんじゃないんだよ。そして乗り換えられる理由がある。
（早いから、安いから、流行ってるから）
皆、新しい車に乗り換える。
なら判るかな？車は伊達で作られてんじゃないんだよ。そして乗り換えられる理由がある。
（早いから、安いから、流行ってるから）
少なくともこのスレでは、オブジェクト指向設計っていうものが
共通概念として明確に定義されてるとは思わないんだけどなあ。
それなのにオブジェクト指向設計が従来設計と比べて
どうだこうだって、何なんだろ。
共通概念として明確に定義されてるとは思わないんだけどなあ。
それなのにオブジェクト指向設計が従来設計と比べて
どうだこうだって、何なんだろ。
いつの間にかOOは流行ってないって話になってる？
なんか沸いてるな
>>309
だってスレタイが流行ってないのが前提だもの。
だってスレタイが流行ってないのが前提だもの。
312 ：仕様書無しさん：2007/01/15(月) 00:29:52
決定権のある奴に理解できんからな。
オブジェクトコボルでも作って教えないとダメだろ。
オブジェクトコボルでも作って教えないとダメだろ。
>>310
メガネか？
メガネか？
設計フェーズの良し悪しを検証可能なのってPGしかいないんだから
少なくともSEとPGが分業制のところじゃ流行りようがないよな。
少なくともSEとPGが分業制のところじゃ流行りようがないよな。
>>311
オブジェクト「設計」って書いてあるぞ。
オブジェクト「設計」って書いてあるぞ。
外部設計検証 SE（顧客補助）
内部設計検証 PG（SE補助）
内部設計検証 PG（SE補助）
ああ、設計検証は指示者でなければ駄目か。
外部設計検証 顧客
内部設計検証 SE、顧客
外部設計検証 顧客
内部設計検証 SE、顧客
>>316じゃ自己満になってしまうわな
実装後の確認（設計書どおりに実装出来ているかの確認）が>>316
320 ：仕様書無しさん：2007/01/15(月) 01:13:49
オブジェクト設計ってそもそも何を言ってるんだ？
今あるオブジェクト指向ってEiffel系のクラス指向とSmalltalk系のメッセージ指向がごっちゃになってるあやふやな概念じゃん。
そんなわけわからん概念の上にある設計技法なんざ信頼できるわけがない。
今あるオブジェクト指向ってEiffel系のクラス指向とSmalltalk系のメッセージ指向がごっちゃになってるあやふやな概念じゃん。
そんなわけわからん概念の上にある設計技法なんざ信頼できるわけがない。
>>320
信頼に足る設計技法なんてあるのかね。
信頼に足る設計技法なんてあるのかね。
322 ：仕様書無しさん：2007/01/15(月) 01:32:18
オブジェクト設計以外の設計なんてあるの？
オブジェクト設計とかわざわざ言うのは年配の方ですか？
オブジェクト設計とかわざわざ言うのは年配の方ですか？
素朴な疑問。「設計」って結局何でしょ？
324 ：仕様書無しさん：2007/01/15(月) 02:08:54
ものすごく単純な話さ、UMLを書けるSEが少ない。
フローチャートと画面遷移図がごっちゃになった設計書しかみんな書かないだろ
フローチャートと画面遷移図がごっちゃになった設計書しかみんな書かないだろ
俺、UMLあんまり好きじゃないな。特にUML2.0。
記法としてUMLがいいか悪いかは微妙。
つーか、UMLで書けば問題解決するもんでもないと思うな。
記法としてUMLがいいか悪いかは微妙。
つーか、UMLで書けば問題解決するもんでもないと思うな。
326 ：仕様書無しさん：2007/01/15(月) 03:48:43
あんまり物を考えない非技術系管理者は、自分じゃ何も判断できない業界紙依存症だから、
すぐその煽動に踊らされ昨日まで培ってきたやり方を忘れる。
そして真に実力のある古参技術者達は技術が古いと能力を過少評価され、
口先だけの新しい奴らに現役を取って代わられる。
そういった意味ではIT業界は2007年問題みたいなことが2、3のサイクルで起きているとも言えるね。
すぐその煽動に踊らされ昨日まで培ってきたやり方を忘れる。
そして真に実力のある古参技術者達は技術が古いと能力を過少評価され、
口先だけの新しい奴らに現役を取って代わられる。
そういった意味ではIT業界は2007年問題みたいなことが2、3のサイクルで起きているとも言えるね。
実装系のスレもあるのかな？
上の方でCでシングルトン実装って出てたけど普通に
staticにワーク作って関数だけ参照できるようにすれば
それで完成と思い。
上の方でCでシングルトン実装って出てたけど普通に
staticにワーク作って関数だけ参照できるようにすれば
それで完成と思い。
流行らない理由。
UMLがまだ枯れてないってのもあるかな。
出た頃に比べれば普及しているようだが。
UMLがまだ枯れてないってのもあるかな。
出た頃に比べれば普及しているようだが。
ぶっちゃけUMLがスレタイに影響を与える要素だと本気で思ってるとしたら脳みその損傷が激しいと思う。
>>329
もちつけ。スレタイへの影響って何さ？ｗｗ
もちつけ。スレタイへの影響って何さ？ｗｗ
今時、フローチャートは、まず書かないし
クラス図、シーケンス図は、ほぼ必ず書くから、
もし仮りに、UMLだけの問題なら、OODは、流行ってるといって
も良いような気がする。
クラス図、シーケンス図は、ほぼ必ず書くから、
もし仮りに、UMLだけの問題なら、OODは、流行ってるといって
も良いような気がする。
>>332
うーん、分野によるのかな？
でもシーケンスは、ともかくクラス図は、
オブジェクト指向言語なら必須の様な気がするんだけど、
あれ無いとPGが勘で勝手にクラス分けするのかなぁ。
言語自体がCとかアセンブラとか非オブジェクト指向言語
なら、それは、それで良い選択で昔通りの設計が、よいと
思うけど
うーん、分野によるのかな？
でもシーケンスは、ともかくクラス図は、
オブジェクト指向言語なら必須の様な気がするんだけど、
あれ無いとPGが勘で勝手にクラス分けするのかなぁ。
言語自体がCとかアセンブラとか非オブジェクト指向言語
なら、それは、それで良い選択で昔通りの設計が、よいと
思うけど
334 ：仕様書無しさん：2007/01/15(月) 09:51:48
UMLできますってのは、日本語できます、英語喋れますってのと同じこと。
それをもって何を喋るかが大事なのに、それを理解できない人が多いこと。
UML記法なんぞ簡単。問題は何を書くかを考える頭。
それをもって何を喋るかが大事なのに、それを理解できない人が多いこと。
UML記法なんぞ簡単。問題は何を書くかを考える頭。
>>333
今やってる分野は業務系中小請負。
仕様書を使うようになっただけマシになったんだぞｗｗ 笑ってくれ。
普及どころか、クラス図って何って状態だ。
自嘲はこれくらいにさせてもらって、
普及度が分野によるには違いないかも。
使用言語による選択より、設計（書）というのは、例えば客とＳＥ・ＳＥとＰＧが
意思疎通を図る言語のようなものだから、普及しているものが使われるという
側面のが大きいような気がする。
> あれ無いとPGが勘で勝手にクラス分けするのかなぁ。
はっきりいってそうなる。
しかし、システム化要件自体がフローチャート的なもの（バッチ処理など）
なので、問題にはなりにくい。
今やってる分野は業務系中小請負。
仕様書を使うようになっただけマシになったんだぞｗｗ 笑ってくれ。
普及どころか、クラス図って何って状態だ。
自嘲はこれくらいにさせてもらって、
普及度が分野によるには違いないかも。
使用言語による選択より、設計（書）というのは、例えば客とＳＥ・ＳＥとＰＧが
意思疎通を図る言語のようなものだから、普及しているものが使われるという
側面のが大きいような気がする。
> あれ無いとPGが勘で勝手にクラス分けするのかなぁ。
はっきりいってそうなる。
しかし、システム化要件自体がフローチャート的なもの（バッチ処理など）
なので、問題にはなりにくい。
業務フローを書くときに、アクティビティ図とかみんな書かんのか。
それともみんなフローチャートは書かないけど、アクティビティ図は
書く、とかそういう主張なのか。
正直、ソフトウェア開発やっててフローチャートが不要とか、ありえない。
みんな仕様書はUML以外の図は書かないとか、そういう主義なのか。
オブジェクト指向じゃないと駄目、とかUMLじゃないと駄目、とか
俺からしてみればオイオイなんだけど。
それともみんなフローチャートは書かないけど、アクティビティ図は
書く、とかそういう主張なのか。
正直、ソフトウェア開発やっててフローチャートが不要とか、ありえない。
みんな仕様書はUML以外の図は書かないとか、そういう主義なのか。
オブジェクト指向じゃないと駄目、とかUMLじゃないと駄目、とか
俺からしてみればオイオイなんだけど。
337 ：仕様書無しさん：2007/01/15(月) 14:17:48
伝わってなんぼでしょ？
まあ、記法が標準で入るならそれにこしたことはないが。
それで表現できないなら、別にそこに縛られることじゃないし。
まあ、記法が標準で入るならそれにこしたことはないが。
それで表現できないなら、別にそこに縛られることじゃないし。
> フローチャートで書く位なら、ＵＭＬで書いた方がはるかに分かりやすいって事だろ？
？？？そうなのか？？？
クイックソートのアルゴリズムはフローチャートで書くより、
(アクティビティ図を除く)UMLで書いた方がわかりやすくなるのか？
その他にも仕様書を書く時点でフローが重要なものとかあるでしょ。
最近はワークフローエンジンとか流行っているけど、これも
基本はフロー(厳密にはBPMLとかつかうんだろうけど)だし。
フローチャートを完全にUML置きかえれるとは思えないんだけど。
もしかしてオブジェクト指向開発ではクイックソートのような
アルゴリズムは絶対につかわない！ということだったりして。
あと、前提条件として念を押しとくけど、フローチャートとアクティビティ図
は本質的には同一だよ。フローチャートをアクティビティ図に置き換えても
はるかにわかりやすくなることは絶対無い。
UMLでかけば分かりやすくなる、というのは思い込みだと思うな～。
> つーか今時、ＯＯＰなんて空気みたいな概念じゃないの？
この発言の意図がわからない。何がいいたかったのか。
思うに本当にOOPが空気みたいな概念であれば、「UML＞フローチャート」
という思い込みにはならないはず。無条件でUMLが優れていると
思ってしまうのは、それがあなたにとって特別な存在だから。
？？？そうなのか？？？
クイックソートのアルゴリズムはフローチャートで書くより、
(アクティビティ図を除く)UMLで書いた方がわかりやすくなるのか？
その他にも仕様書を書く時点でフローが重要なものとかあるでしょ。
最近はワークフローエンジンとか流行っているけど、これも
基本はフロー(厳密にはBPMLとかつかうんだろうけど)だし。
フローチャートを完全にUML置きかえれるとは思えないんだけど。
もしかしてオブジェクト指向開発ではクイックソートのような
アルゴリズムは絶対につかわない！ということだったりして。
あと、前提条件として念を押しとくけど、フローチャートとアクティビティ図
は本質的には同一だよ。フローチャートをアクティビティ図に置き換えても
はるかにわかりやすくなることは絶対無い。
UMLでかけば分かりやすくなる、というのは思い込みだと思うな～。
> つーか今時、ＯＯＰなんて空気みたいな概念じゃないの？
この発言の意図がわからない。何がいいたかったのか。
思うに本当にOOPが空気みたいな概念であれば、「UML＞フローチャート」
という思い込みにはならないはず。無条件でUMLが優れていると
思ってしまうのは、それがあなたにとって特別な存在だから。
あと、UMLは昔からある記法を持ってきて標準化している部分が
たくさんあるよね。
クラス図は確かに現状のクラス志向のオブジェクト指向に
あった表記法だと思うけど、これも元はといえばER図なんだよね。
個人的にUMLで一番オブジェクト指向らしい図といえば、
オブジェクト図とかコラボレーション図だと思うんだけど
どうだろう。
たくさんあるよね。
クラス図は確かに現状のクラス志向のオブジェクト指向に
あった表記法だと思うけど、これも元はといえばER図なんだよね。
個人的にUMLで一番オブジェクト指向らしい図といえば、
オブジェクト図とかコラボレーション図だと思うんだけど
どうだろう。
341 ：仕様書無しさん：2007/01/15(月) 17:51:15
だから、ミクロな話はどうでもいいよ。
ここはマクロな話だろ？
ここはマクロな話だろ？
やっぱ原理主義者って本当にいるんだね。
シーケンス図は正直分かりやすいと思った。
あれの活性化ってようはスコープの中ってことだよな。
あれの活性化ってようはスコープの中ってことだよな。
344 ：仕様書無しさん：2007/01/15(月) 19:55:08
クラス図、インターフェースもきっちり抽出したクラス図が設計できる人は
大手SIにしかいない！！
したがって、世間では流行らない。
きっちりしたクラス図が設計できる者は、このスレにいるのか？ あっ！！
大手SIにしかいない！！
したがって、世間では流行らない。
きっちりしたクラス図が設計できる者は、このスレにいるのか？ あっ！！
345 ：仕様書無しさん：2007/01/15(月) 20:03:00
346 ：仕様書無しさん：2007/01/15(月) 20:36:59
クラス図シーケンス図で設計やってるけど、正直酷いもんだよ。
あれを設計書でございますって言って渡されてごらんよ。最悪だよマジで。
全体が何をしたいのかを読みとるのがまず大変。
やっと全体がわかって細かいとこ見れるようになると、
一つのクラスが複数の責務を持ってるわ、クラス名称はいいかげんで意味不明だわ、
メソッドは何がしたいのか読み取れないわでわけわからん。
UMLで書いたって酷い設計は酷い設計なんだよね。
あれを設計書でございますって言って渡されてごらんよ。最悪だよマジで。
全体が何をしたいのかを読みとるのがまず大変。
やっと全体がわかって細かいとこ見れるようになると、
一つのクラスが複数の責務を持ってるわ、クラス名称はいいかげんで意味不明だわ、
メソッドは何がしたいのか読み取れないわでわけわからん。
UMLで書いたって酷い設計は酷い設計なんだよね。
具象でなく抽象の概念のまま操作できることがオブジェクトの利点だと思うんだが
抽象概念の最小単位がインターフェイスであり、その単位で扱うと自然と疎結合になると
パフォーマンスとか言ってる奴は最小の単位を間違えてるんだろ
たとえ問題が出たところで大抵は一部の修正にとどまるやん
全ては抽象概念に落とし込むところが全てだと
Genericsとかとも相性がいいしな
抽象概念の最小単位がインターフェイスであり、その単位で扱うと自然と疎結合になると
パフォーマンスとか言ってる奴は最小の単位を間違えてるんだろ
たとえ問題が出たところで大抵は一部の修正にとどまるやん
全ては抽象概念に落とし込むところが全てだと
Genericsとかとも相性がいいしな
C言語から移ったばかりだとC++は疎結合なグローバル変数を持ったプログラム程度にしか見えない。
フローチャートの必要性が見出せるような小規模なプロジェクトをしてる
エンジニアばかりじゃないって事だな
エンジニアばかりじゃないって事だな
大規模だとフローチャートがいらないのかｗ
業務フローの分析とかワークフローとかは小規模向けの
開発手法なのか。
業務フローの分析とかワークフローとかは小規模向けの
開発手法なのか。
>>346
それはあるね。
仕様書のどの部分を反映させた結果そういう図になったのかわからないと辛いね。
わかってもそれなりに辛いけど。
あの図だけホイって渡されて「後は仕様書と合わせてみればわかるから」って
「わかるわけねーじゃんｗ」っての多いしな。
しかも、担当者はそこで何故か（何故かなんて愚問だなｗ）作業を投げたがる。
聞きに言っても。
「ああ、設計書書いた人もう別のプロジェクト移っちゃったんですよｗ」
とか酷すぎるにもほどがある。
「設計はもう終わったからｗ」
ってどの口がこんな嘘っぱちをほざくのか・・・閻魔様に舌引っこ抜いてもらわな治らんのだろうなｗ
って状況が多いなｗ
それはあるね。
仕様書のどの部分を反映させた結果そういう図になったのかわからないと辛いね。
わかってもそれなりに辛いけど。
あの図だけホイって渡されて「後は仕様書と合わせてみればわかるから」って
「わかるわけねーじゃんｗ」っての多いしな。
しかも、担当者はそこで何故か（何故かなんて愚問だなｗ）作業を投げたがる。
聞きに言っても。
「ああ、設計書書いた人もう別のプロジェクト移っちゃったんですよｗ」
とか酷すぎるにもほどがある。
「設計はもう終わったからｗ」
ってどの口がこんな嘘っぱちをほざくのか・・・閻魔様に舌引っこ抜いてもらわな治らんのだろうなｗ
って状況が多いなｗ
>>350
フローチャートってあんまり役にたたんような希ガス。
できるならプログラムに直接ブレーク置いて実際に処理おっかけてみるとか
ソースをじっくりみたほうがなんぼかいいと思うんだけど。
てか、ソースとフローチャートって何が違うのかわからん。
ソースあればフローチャートいらないだろ？
フローチャートってあんまり役にたたんような希ガス。
できるならプログラムに直接ブレーク置いて実際に処理おっかけてみるとか
ソースをじっくりみたほうがなんぼかいいと思うんだけど。
てか、ソースとフローチャートって何が違うのかわからん。
ソースあればフローチャートいらないだろ？
だからフローチャートは必ずしもアルゴリズムを書くだけの
ものじゃないんだって。設計の粒度によって役割が違うでしょ？
業務プロセスレベルの設計とかにもつかうんだって。
しつこいけど、フローチャート＝アクティビティ図という前提で
話をしているので。フローチャートの使い道でイメージがわかなければ、
アクティビティ図の使い道に置き換えてもいい。手元にある
UMLや開発プロセスについてかかれてている本があったら開いてみて。
ものじゃないんだって。設計の粒度によって役割が違うでしょ？
業務プロセスレベルの設計とかにもつかうんだって。
しつこいけど、フローチャート＝アクティビティ図という前提で
話をしているので。フローチャートの使い道でイメージがわかなければ、
アクティビティ図の使い道に置き換えてもいい。手元にある
UMLや開発プロセスについてかかれてている本があったら開いてみて。
354 ：仕様書無しさん：2007/01/15(月) 21:53:38
メインのプログラムはインターフェースを使ってプログラミングする。
ゴリゴリプログラミングするのは、そのインターフェースを実装するクラスのみ。
だから、拡張性がよい。
それにメインのプログラムは、みんなが共通に使うからバグがどんどん見つかり
品質がよくなる。
その代わり、メインのプログラムはきっちりと設計しないと、使いものにならない。
まずは、このオブジェクト設計の基本中の基本を理解している者以外はここに出ないことだ。
するとじきにスレ落ちするでしょう。
ゴリゴリプログラミングするのは、そのインターフェースを実装するクラスのみ。
だから、拡張性がよい。
それにメインのプログラムは、みんなが共通に使うからバグがどんどん見つかり
品質がよくなる。
その代わり、メインのプログラムはきっちりと設計しないと、使いものにならない。
まずは、このオブジェクト設計の基本中の基本を理解している者以外はここに出ないことだ。
するとじきにスレ落ちするでしょう。
>>350
論点をずらさないでくれー
アナタの言うフローチャートとは、>>339で言ってたものでしょうが。
＞＞クイックソートのアルゴリズムはフローチャートで書くより
個々のメソッドの流れなど、いちいち設計でやる物じゃないって事だよ。
論点をずらさないでくれー
アナタの言うフローチャートとは、>>339で言ってたものでしょうが。
＞＞クイックソートのアルゴリズムはフローチャートで書くより
個々のメソッドの流れなど、いちいち設計でやる物じゃないって事だよ。
> 論点をずらさないでくれー
いや、最初から俺はフローチャート＝アクティビティ図で
業務プロセスも含めて発言しているよ。350ではその例の
ひとつとしてクイックソートをあげているだけ。
とりあえずコテハン(336)でスレを検索してくれ。
↓336での発言
> 業務フローを書くときに、アクティビティ図とかみんな書かんのか。
> それともみんなフローチャートは書かないけど、アクティビティ図は
> 書く、とかそういう主張なのか。
意味が解らなかったかもしれないけど、業務フローでアクティビティ図
を書くのはイコール、フローチャートを書いているようなものでしょ？
という意図だ。
いや、最初から俺はフローチャート＝アクティビティ図で
業務プロセスも含めて発言しているよ。350ではその例の
ひとつとしてクイックソートをあげているだけ。
とりあえずコテハン(336)でスレを検索してくれ。
↓336での発言
> 業務フローを書くときに、アクティビティ図とかみんな書かんのか。
> それともみんなフローチャートは書かないけど、アクティビティ図は
> 書く、とかそういう主張なのか。
意味が解らなかったかもしれないけど、業務フローでアクティビティ図
を書くのはイコール、フローチャートを書いているようなものでしょ？
という意図だ。
訂正
>350ではその例のひとつとしてクイックソートをあげているだけ。
↓
>350ではフローチャートが必要な例のひとつとしてクイックソートを
>あげているだけ。
>350ではその例のひとつとしてクイックソートをあげているだけ。
↓
>350ではフローチャートが必要な例のひとつとしてクイックソートを
>あげているだけ。
まじで業務分析にアクティビティ図をつかうことを知らない
やつがこんなにいるのか...(´Д｀;
いや、悪いけどマジで理解不足だから勉強してくれ。
こんなんじゃ、まともなオブジェクト指向設計とかできないだろ...。
例を挙げれば先にあげた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からの「ビジネスモデリング作業分野」
とか読んでみて。ビジネスモデリングにアクティビティ図をつかっているだろ。
その他にも、ユースケース記述のフローは自然言語なので
文章では流れがわかりにくい場合は、補助的にフローを
アクティビティ図で書いたり。
やつがこんなにいるのか...(´Д｀;
いや、悪いけどマジで理解不足だから勉強してくれ。
こんなんじゃ、まともなオブジェクト指向設計とかできないだろ...。
例を挙げれば先にあげた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からの「ビジネスモデリング作業分野」
とか読んでみて。ビジネスモデリングにアクティビティ図をつかっているだろ。
その他にも、ユースケース記述のフローは自然言語なので
文章では流れがわかりにくい場合は、補助的にフローを
アクティビティ図で書いたり。
>>359
議論の途中でかまわず突っ込むけど。
もう見た感じ役にたたねぇ臭いがプンプンすんだけど？
だってこんな楽なフローで終わるプログラムが業務でねぇもん。
それにこんな楽なフローで終わるっていうならこんな図書く意味無いと思うんだけど？
議論の途中でかまわず突っ込むけど。
もう見た感じ役にたたねぇ臭いがプンプンすんだけど？
だってこんな楽なフローで終わるプログラムが業務でねぇもん。
それにこんな楽なフローで終わるっていうならこんな図書く意味無いと思うんだけど？
心が折れそうだ。
>360
例だから簡単なのは当たり前だろ。
もっと複雑な例はWebでみつからない。
お前が複雑な例をつくってあげてみろというのは勘弁しれくれ。
じゃあ、君は流れを整理するのにフローチャート以外に何をつかうんだ。
散文形式もしくは箇条書きでだらだらと文章で書いて終わりか。
(それともお得意のUML?)
確かにそれも必要だが、それだけの文書と、フローチャートが
添えられている文書どっちがいい？
>360
例だから簡単なのは当たり前だろ。
もっと複雑な例はWebでみつからない。
お前が複雑な例をつくってあげてみろというのは勘弁しれくれ。
じゃあ、君は流れを整理するのにフローチャート以外に何をつかうんだ。
散文形式もしくは箇条書きでだらだらと文章で書いて終わりか。
(それともお得意のUML?)
確かにそれも必要だが、それだけの文書と、フローチャートが
添えられている文書どっちがいい？
>>359
>フローチャートの標準が策定されるというのは、フローチャートが
>今になっても必要だということじゃないのか？
その論理が正しいのなら・・・
http://www.nikkansports.com/general/f-gn-tp0-20061222-133735.html
インターネット全盛の今になって新しい記念切手が発行されるというのは、
記念切手が今になっても必要だということじゃないのか？
>フローチャートの標準が策定されるというのは、フローチャートが
>今になっても必要だということじゃないのか？
その論理が正しいのなら・・・
http://www.nikkansports.com/general/f-gn-tp0-20061222-133735.html
インターネット全盛の今になって新しい記念切手が発行されるというのは、
記念切手が今になっても必要だということじゃないのか？
経験と勘だけでいうけどこういう処理を図にしたもんって現実味が無いよ。
模造紙５まい使っても書ききれ無い場合のが多いんじゃない？
あんまり大雑把に書くと役に立たんし、詳細に書き過ぎると資料として役に立たない。
全体を網羅できない上に概要を伝えるにも主旨が定められないしはっきりいって役に立たないと思う＞処理図（フローでもアクティなんとかでもいいけど）
模造紙５まい使っても書ききれ無い場合のが多いんじゃない？
あんまり大雑把に書くと役に立たんし、詳細に書き過ぎると資料として役に立たない。
全体を網羅できない上に概要を伝えるにも主旨が定められないしはっきりいって役に立たないと思う＞処理図（フローでもアクティなんとかでもいいけど）
これだけこっちが例を挙げているんだから、そっちも
反論に言葉尻を押さえるだけじゃなくて対案を提示してくれ。
「いや、それならこういうUMLをつかった、もっといい方法がある」
という意見なんでしょ。
反論に言葉尻を押さえるだけじゃなくて対案を提示してくれ。
「いや、それならこういうUMLをつかった、もっといい方法がある」
という意見なんでしょ。
365 ：仕様書無しさん：2007/01/15(月) 22:55:06
業務分析なんて上流に携わらないからよくわからん。
役に立つってんなら役に立つんだろう。
でもオブジェクト指向設計の場合、
動的な処理の記述はクラスを発見した後でなければ考えられないよ。
役に立つってんなら役に立つんだろう。
でもオブジェクト指向設計の場合、
動的な処理の記述はクラスを発見した後でなければ考えられないよ。
> あんまり大雑把に書くと役に立たんし、詳細に書き過ぎると資料として役に立たない。
それはクラス図でもDFDでも一緒だな。DFDなんかは最初からレイヤわけするもんだしな。
最初は情報のルートとして大雑把な情報は必要だし、細かいところではそれに応じた粒度の情報が必要だ。
BPMLに関していえば、ワークフローエンジンというのがあって、そのまま
シームレスに実装につかえるのが特徴だ。
それはクラス図でもDFDでも一緒だな。DFDなんかは最初からレイヤわけするもんだしな。
最初は情報のルートとして大雑把な情報は必要だし、細かいところではそれに応じた粒度の情報が必要だ。
BPMLに関していえば、ワークフローエンジンというのがあって、そのまま
シームレスに実装につかえるのが特徴だ。
>>361
>じゃあ、君は流れを整理するのにフローチャート以外に何をつかうんだ。
正直にいうと書いたことない。
ていうか書ききれる規模のもんにあたったことが無い。
これはいつも資料にならずに作業担当者の頭の中にある部分だね。
俺が経験したどのプロジェクトでもそうだったよ。
松下でも富士通でも日立でも沖でもＮＴＴでもどこもそう。
これを資料できたところは一つもないね。
>じゃあ、君は流れを整理するのにフローチャート以外に何をつかうんだ。
正直にいうと書いたことない。
ていうか書ききれる規模のもんにあたったことが無い。
これはいつも資料にならずに作業担当者の頭の中にある部分だね。
俺が経験したどのプロジェクトでもそうだったよ。
松下でも富士通でも日立でも沖でもＮＴＴでもどこもそう。
これを資料できたところは一つもないね。
> 「流れ」を整理しなければ分からないような業務は、
> 先にその「構造」を整理したほうがずっと効果的だ、
> というのが大方の意見だと思う。
これは個人の思想の問題だろう。
構造が大事だという考え方は確かにある。
構造っていうのは静的なものの見方だよね(クラス図なんかがそう)。
それに対してフローやシーケンスは動的なものの見方。
昔から「静的なものの見方」VS「動的なものの見方」という
対立軸はあって、時代によってどっちかが優勢になることは
あるけど、どっちが絶対正しいというもんでもないぞ。
どっちも必要。
> 先にその「構造」を整理したほうがずっと効果的だ、
> というのが大方の意見だと思う。
これは個人の思想の問題だろう。
構造が大事だという考え方は確かにある。
構造っていうのは静的なものの見方だよね(クラス図なんかがそう)。
それに対してフローやシーケンスは動的なものの見方。
昔から「静的なものの見方」VS「動的なものの見方」という
対立軸はあって、時代によってどっちかが優勢になることは
あるけど、どっちが絶対正しいというもんでもないぞ。
どっちも必要。
みんなが大好きなUMLの教科書にも、静的な側面だけで設計すると
良くない設計になるから、動的な側面と静的な側面(この側面を
ビューと呼ぶ)でそれぞれ設計してラウンドロビンしなさい、と
書いてあるだろ。
良くない設計になるから、動的な側面と静的な側面(この側面を
ビューと呼ぶ)でそれぞれ設計してラウンドロビンしなさい、と
書いてあるだろ。
>>371
それって単純に言えば設計者の腕次第ってことだろ？
それって単純に言えば設計者の腕次第ってことだろ？
メイヤーのオブジェクト指向入門では、動的な処理の記述でシステムを特徴付けるのは不可能だって書いてあるね。
大目的を達成するための処理を記述するフローチャートは確かに便利だ。
でも実際の業務では大目的がころころ変わったり追加されたりする。
そのたびにフローチャートを作り直すなんてのは無理な話だからね。
では何を基本的な構造としてシステムを構築していくかって話しになったときに、
システムに不変的に存在し続けるクラスを基本としようってのがオブジェクト指向。
大目的を達成するための処理を記述するフローチャートは確かに便利だ。
でも実際の業務では大目的がころころ変わったり追加されたりする。
そのたびにフローチャートを作り直すなんてのは無理な話だからね。
では何を基本的な構造としてシステムを構築していくかって話しになったときに、
システムに不変的に存在し続けるクラスを基本としようってのがオブジェクト指向。
>>373
そんな大層なもんじゃねぇだろｗ
そんな大層なもんじゃねぇだろｗ
376 ：仕様書無しさん：2007/01/15(月) 23:20:50
このスレみてわかった。
ここって一般人からみれば、「オブジェクト指向マニア」
としか言いようが無い人しか来ないだろうけど、
それですら、オブジェクト指向の本質ひとつ取ったって、
こんだけ紛糾してコンセンサスが取れないのな。
こりゃ、永久に流行らんわ。
ここって一般人からみれば、「オブジェクト指向マニア」
としか言いようが無い人しか来ないだろうけど、
それですら、オブジェクト指向の本質ひとつ取ったって、
こんだけ紛糾してコンセンサスが取れないのな。
こりゃ、永久に流行らんわ。
シーケンス図はあんまり役には立たんなぁ・・・。
一生懸命書いた努力は認めるけど大抵嘘ッパチだからなぁｗ
一生懸命書いた努力は認めるけど大抵嘘ッパチだからなぁｗ
まあ、オブジェクト設計は将来できるであろう上位設計理論のための布石ってことで。
よくある話だ。
よくある話だ。
>>378
つか、将来的にもう少しシェイプアップしたほうがいいんじゃねぇの？＞ソフト開発
予算少ないのに無駄な人材多すぎだよ。
こんだけ人数やら期間やら絞るんなら上流とか下流とか必要無いって。
一番面倒なのが上流と下流が別の奴ってのがそもそも駄目だ。
つか、設計云々とかじゃなくて普通に金の無駄。
つか、将来的にもう少しシェイプアップしたほうがいいんじゃねぇの？＞ソフト開発
予算少ないのに無駄な人材多すぎだよ。
こんだけ人数やら期間やら絞るんなら上流とか下流とか必要無いって。
一番面倒なのが上流と下流が別の奴ってのがそもそも駄目だ。
つか、設計云々とかじゃなくて普通に金の無駄。
どっちかっていうと仕様のシェイプアップが一番先かな。
次段階にそのまま落とし込める仕様設計理論、ていうか普遍的テンプレートが必要。
今はできる人はテンプレ持ってるけど・・・ってことかいな。
今はできる人はテンプレ持ってるけど・・・ってことかいな。
海外に丸投げ
>>381
類似ソフトの仕様を徹底的に真似る。
類似ソフトの仕様を徹底的に真似る。
> そのまま落とし込める仕様設計理論
これはMDAとかExcutiveUMLだな。
夢のまた夢のような気がする。実現すればしたでうれしいが、
期待してない。
> 普遍的テンプレートが必要
こっちはSoftwareFactoryっぽい？普遍的じゃなくて、問題領域
特化型だけど。
これはMDAとかExcutiveUMLだな。
夢のまた夢のような気がする。実現すればしたでうれしいが、
期待してない。
> 普遍的テンプレートが必要
こっちはSoftwareFactoryっぽい？普遍的じゃなくて、問題領域
特化型だけど。
上流から下流って言うよりも、元請と下請けの関係を無くさないとな。
日本のソフト開発は大手が受けて子会社が仕事するって形になってる。
日本の物作り構造は全部そう。
日本のソフト開発は大手が受けて子会社が仕事するって形になってる。
日本の物作り構造は全部そう。
アメリカもそうでしょ。
てか、現場の上流工程の実際ってどうよ？
俺はあんましよろしくないね。
理由としては駄目であっても駄目であることを説明しにくいから。
オブジェクト指向がいいか悪いかとかそういう議論といっしょだな。
ＹＥＳかＮＯで表現できない分、話術でどこまでもでっちあげることができる。
あんまり開発者としてはうれしくない。
正直、プログラムが組めない人がソフト開発に参加するためのポジション的な要素が強いと思う。
俺はあんましよろしくないね。
理由としては駄目であっても駄目であることを説明しにくいから。
オブジェクト指向がいいか悪いかとかそういう議論といっしょだな。
ＹＥＳかＮＯで表現できない分、話術でどこまでもでっちあげることができる。
あんまり開発者としてはうれしくない。
正直、プログラムが組めない人がソフト開発に参加するためのポジション的な要素が強いと思う。
>>388
おお、商品開発のあるべき姿だな。
これがなんかパクリだなんだってこだわりはじめた頃から物作りがおかしくなった。
と俺は勝手に思ってるんだけどね。
昔の松下はこうだったよな。
急にマネシタなんていう奴がでてきたけど。
おお、商品開発のあるべき姿だな。
これがなんかパクリだなんだってこだわりはじめた頃から物作りがおかしくなった。
と俺は勝手に思ってるんだけどね。
昔の松下はこうだったよな。
急にマネシタなんていう奴がでてきたけど。
>391
やっぱりあれは詐欺なのか。
いや、どう考えたって無理そうなのでこれってどうなんだろうと思ったんだが。
本を読んだ人でイイ、イイ、言っている人が居たのでかなり悩んだが、すっきりしたよ。
オブジェクト指向周りは詐欺師も多いから、地雷を踏まないように気をつけなければ。
やっぱりあれは詐欺なのか。
いや、どう考えたって無理そうなのでこれってどうなんだろうと思ったんだが。
本を読んだ人でイイ、イイ、言っている人が居たのでかなり悩んだが、すっきりしたよ。
オブジェクト指向周りは詐欺師も多いから、地雷を踏まないように気をつけなければ。
>>393
いや、本気でいいと思ってやってる人もいるんだろうけど、
開発期間（開発効率じゃなくて！開発期間（超重要））が１．５倍～２倍は少なくなるようなもんじゃないと
導入にあんまり意味が無いと思うな。
セミナーまで開いて具体的な数字すらなくて「～な気がする」で止まってるもんは本人にそのつもりがなくても詐欺でいいけど。
いや、本気でいいと思ってやってる人もいるんだろうけど、
開発期間（開発効率じゃなくて！開発期間（超重要））が１．５倍～２倍は少なくなるようなもんじゃないと
導入にあんまり意味が無いと思うな。
セミナーまで開いて具体的な数字すらなくて「～な気がする」で止まってるもんは本人にそのつもりがなくても詐欺でいいけど。
＞本を読んだ人でイイ、イイ、言っている人が居たのでかなり悩んだが、すっきりしたよ。
こんな納得の仕方はないのでは。。？
AndroMDAとか簡単に試せるんだから使ってみればいいじゃない。
こんな納得の仕方はないのでは。。？
AndroMDAとか簡単に試せるんだから使ってみればいいじゃない。
ようするにモデル駆動開発だろ？
モデルから完全なコードなりプログラムを吐き出してくれなきゃ手間が増えるばっかだ。
モデルから完全なコードなりプログラムを吐き出してくれなきゃ手間が増えるばっかだ。
現状のMDAは「モデルから完全なコードなりプログラムを吐き出す」部分に関して
全く問題ないレベルに達しているだよ。
問題は「完全なモデルを定義する」のがものすごく大変ってところだな。
全く問題ないレベルに達しているだよ。
問題は「完全なモデルを定義する」のがものすごく大変ってところだな。
398 ：仕様書無しさん：2007/01/16(火) 00:48:46
＞開発期間（開発効率じゃなくて！開発期間（超重要））が１．５倍～２倍は少なくなるようなもんじゃないと
こういう日本語ってプログラマーとしてどうなのよ？
って思いました。
こういう日本語ってプログラマーとしてどうなのよ？
って思いました。
あははたしかにポッペンディークが
新興宗教の教祖に見えるなあ
新興宗教の教祖に見えるなあ
オブジェクト指向関係の学者とか、ハッカーとかって
(リチャードストールマンとか)宗教家顔が多いよな。
逆にノイマンとかチューリングとかホーアとか昔の情報系数学者
は普通の学者顔なのに。
(リチャードストールマンとか)宗教家顔が多いよな。
逆にノイマンとかチューリングとかホーアとか昔の情報系数学者
は普通の学者顔なのに。
> まじで業務分析にアクティビティ図をつかうことを知らない
> やつがこんなにいるのか...(´Д｀;
知ってるけど、使うと伝わんねーんだよ orz...
> やつがこんなにいるのか...(´Д｀;
知ってるけど、使うと伝わんねーんだよ orz...
403 ：仕様書無しさん：2007/01/16(火) 08:18:38
まずは、クラス図とシーケンス図で十分です。
それすらも設計できないから流行らない。
それすらも設計できないから流行らない。
404 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/16(火) 20:52:47
どうせ仕様変わるんだし
画面図だけでいいよ
ＯＯは君の心の中にあるんだ。
手法の問題ではないのだ。
フローチャートのブロックを枠で囲ってオブジェクト指向フローチャートとする。
もーばっちり
画面図だけでいいよ
ＯＯは君の心の中にあるんだ。
手法の問題ではないのだ。
フローチャートのブロックを枠で囲ってオブジェクト指向フローチャートとする。
もーばっちり
405 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/16(火) 20:57:41
オブジェクト指向は信者が優越感を得るために存在する。
生産性はマイナスになる。
生産性はマイナスになる。
画面図だけで十分な、単純なソフトしか作らない奴に言われてもなー
407 ：仕様書無しさん：2007/01/16(火) 21:21:29
>>404
画面も仕様変更よくあるけどないよりはましかなー。
>>406
そういう無駄な煽りやめようぜ。
俺はどんなにでかいもんでも無くてもなんでも作れるから
俺とお前が業務でぶつかったら多分俺なんでも捨てちゃうぜｗ
「なくても作れる（俺）」と「あったほうがいい（お前）」がぶつかったらコストの安い俺の方に分があるんだぜ。
画面も仕様変更よくあるけどないよりはましかなー。
>>406
そういう無駄な煽りやめようぜ。
俺はどんなにでかいもんでも無くてもなんでも作れるから
俺とお前が業務でぶつかったら多分俺なんでも捨てちゃうぜｗ
「なくても作れる（俺）」と「あったほうがいい（お前）」がぶつかったらコストの安い俺の方に分があるんだぜ。
408 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/16(火) 21:54:18
画面仕様は変更されても ソース直して動かしてプリントスクリーンで取り込めばすぐに仕様書をフィードバックできる。
ほかの仕様書はだめね。
完成が近づくと、現状と異なる設計書、仕様書の山ができて、そっち直すほうがソース直すより時間かかる。
（ここで目が覚めるはずだが）
で最後放置。（自社開発の場合 請負は知らない）
ほかの仕様書はだめね。
完成が近づくと、現状と異なる設計書、仕様書の山ができて、そっち直すほうがソース直すより時間かかる。
（ここで目が覚めるはずだが）
で最後放置。（自社開発の場合 請負は知らない）
何このキモコテ
>>408
それはキミの現場（会社？）が、開発途中で意思疎通や調整のために発生する
ドキュメントと、最終的に納品あるいは保存する成果物の区別が付いていないせい。
よくある間違いは、開発初期段階から納品ドキュメントを作ろうとすること。
国内ではどこでも見られる光景。ちなみに我が社も。オレは頑なに拒んでいるが。
それはキミの現場（会社？）が、開発途中で意思疎通や調整のために発生する
ドキュメントと、最終的に納品あるいは保存する成果物の区別が付いていないせい。
よくある間違いは、開発初期段階から納品ドキュメントを作ろうとすること。
国内ではどこでも見られる光景。ちなみに我が社も。オレは頑なに拒んでいるが。
411 ：仕様書無しさん：2007/01/17(水) 02:27:48
まあどっちにしても手戻り前提で設計する奴は
なんちゃってSEですよ
なんちゃってSEですよ
412 ：仕様書無しさん：2007/01/17(水) 02:36:17
開発全体として手戻りが発生せず
早く正確なものができる方法を採用できなければ駄目。
早く正確なものができる方法を採用できなければ駄目。
どの程度後続に対し詳細に情報提供すれば良いか読むべきだし
どの程度先方に対し詳細に情報提供して欲しいか言うべきだし
後続が「この情報が欲しい」と言った事に対して
文句を言う奴がいるPJは火を噴く。
どの程度先方に対し詳細に情報提供して欲しいか言うべきだし
後続が「この情報が欲しい」と言った事に対して
文句を言う奴がいるPJは火を噴く。
規則も無い無法地帯では
あくまでも受け手が良し悪しを決めるから
受け手が積極的に確認する必要がある。
あくまでも受け手が良し悪しを決めるから
受け手が積極的に確認する必要がある。
さらに確認したうえで不満があっても
伝えてない事であれば切れるべきではない。
むしろ情報提供できていない先方の責任。
伝えてない事であれば切れるべきではない。
むしろ情報提供できていない先方の責任。
一定水準以上の品質を要求するのであれば
ガイドラインを設けたら良い。
ガイドラインを設けたら良い。
ガイドラインが無いんじゃ
受け手の責任とするのは無理があるんじゃないかな。
受け手の責任とするのは無理があるんじゃないかな。
すまん。まちげーたｗ
×受け手の責任とするのは無理がある
○送り手の責任とするのは無理がある
×受け手の責任とするのは無理がある
○送り手の責任とするのは無理がある
だから問題が発生しても受け手は切れる必要は無く
送り手が受け手に合わせて修正すれば良いだけの
話だと思うんだけどな。
送り手が受け手に合わせて修正すれば良いだけの
話だと思うんだけどな。
>>419
断定口調にしないとｗ
断定口調にしないとｗ
だから問題が発生しても受け手は切れる必要は無く
送り手が受け手に合わせて修正すれば良いだけの話だ。
送り手が受け手に合わせて修正すれば良いだけの話だ。
423 ：仕様書無しさん：2007/01/17(水) 07:55:01
オブジェクト指向の開発じゃ反復型開発は当たり前。
実装からのフィードバック無しに最初から完全なモデルを書くのなんて不可能だし、
できたとしても非効率だよ。
UMLなんかはスケッチ程度に使ってレビュー実装テストを何度もやらなきゃ。
実装からのフィードバック無しに最初から完全なモデルを書くのなんて不可能だし、
できたとしても非効率だよ。
UMLなんかはスケッチ程度に使ってレビュー実装テストを何度もやらなきゃ。
フィードバックと手戻りが混ぜ混ぜしてきてるよ。
425 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/17(水) 08:52:35
ＯＯが生産性高いなら 競合他社を差し置いて受注独り占めで業容拡大の一途だろう。
ＯＯ普及から時間も十分たってるのにそうなってないのはＯＯの宣伝する生産性の向上がうそだから
ＯＯ普及から時間も十分たってるのにそうなってないのはＯＯの宣伝する生産性の向上がうそだから
OOが生産性が低いなら
オブジェクト指向言語ばかり流行るのはなぜだろう？
結局、生産現場では、今ではC++,Javaを始めとした
オブジェクト指向言語によるOOでの開発が主力
オブジェクト指向言語ばかり流行るのはなぜだろう？
結局、生産現場では、今ではC++,Javaを始めとした
オブジェクト指向言語によるOOでの開発が主力
427 ：おじゃばさま：2007/01/17(水) 09:50:04
オブジェクト指向プログラミングの生産性は高い訳ではない。
仕様が決まっていて変更が少ないとしたら、従来の構造化プログラミングの方が少ないステップ数になる。
OOPの利点は変更時の影響の少なさである。
例えばプログラムの出力先をファイルからDBに変えるとする。
適切にOOPされたコードでは驚くほど簡単に変更出来る。
構造化の場合は設計時からそれを予期していない場合、多くの場合は大変更になる。
仕様が決まっていて変更が少ないとしたら、従来の構造化プログラミングの方が少ないステップ数になる。
OOPの利点は変更時の影響の少なさである。
例えばプログラムの出力先をファイルからDBに変えるとする。
適切にOOPされたコードでは驚くほど簡単に変更出来る。
構造化の場合は設計時からそれを予期していない場合、多くの場合は大変更になる。
428 ：仕様書無しさん：2007/01/17(水) 14:05:18
429 ：仕様書無しさん：2007/01/17(水) 14:32:54
ってのが幻想というのは既に判ってると思うのだが。
その再利用性ってモジュール化したら再利用可能ってのと大差無い。
特定プロジェクトの成果物を他のプロジェクトで再利用ってのは、まず無い。
不特定向けに基本プロジェクトを作って、他にCustomizeするときに便利ってのはまだ理解できる。
その再利用性ってモジュール化したら再利用可能ってのと大差無い。
特定プロジェクトの成果物を他のプロジェクトで再利用ってのは、まず無い。
不特定向けに基本プロジェクトを作って、他にCustomizeするときに便利ってのはまだ理解できる。
430 ：仕様書無しさん：2007/01/17(水) 14:43:38
OOPに再利用性は、さほどない。
構造化ＰＧ時代のライブラリと大差なく、単にその規模が大きくなっただけ。
モジュールの効率良い再利用性は、事実上不可能であると位置づけられてる。
ＯＯＰの有効性を語る事自体がナンセンスだ。規模の大きいプロジェクトでは
自然と使うものだし、使わなくていいなら使わなければいいだけの事
構造化ＰＧ時代のライブラリと大差なく、単にその規模が大きくなっただけ。
モジュールの効率良い再利用性は、事実上不可能であると位置づけられてる。
ＯＯＰの有効性を語る事自体がナンセンスだ。規模の大きいプロジェクトでは
自然と使うものだし、使わなくていいなら使わなければいいだけの事
431 ：おじゃばさま：2007/01/17(水) 19:27:10
再利用と言うより「変更のしやすさ」だよ。
確かに他のプロジェクトで使うとしたら、適切にモジュール化された物と変わらないだろう。
ただし、仕様変更の場合が違う。構造化が度重なる仕様変更で次第に複雑になるのに対して、
オブジェクト指向では仕様変更のたびに、コードが洗練されて行く。
これはオブジェクト指向では仕様変更が入っても、基本的にメソッドを追加するような方向で、
以前の処理を残して記述するため、曖昧だった処理の分割点が次第に明らかになっていくからだ。
現代のプログラミング開発では最初から仕様が明確になっている事が少ない。
そのため多くの仕様変更が開発中に発生する。オブジェクト指向はそれに合った開発方法と言える。
ただ変更が容易だと体感するにはある程度の経験とセンスが必要だな。
そのレベルに達している人は結構少ない。
確かに他のプロジェクトで使うとしたら、適切にモジュール化された物と変わらないだろう。
ただし、仕様変更の場合が違う。構造化が度重なる仕様変更で次第に複雑になるのに対して、
オブジェクト指向では仕様変更のたびに、コードが洗練されて行く。
これはオブジェクト指向では仕様変更が入っても、基本的にメソッドを追加するような方向で、
以前の処理を残して記述するため、曖昧だった処理の分割点が次第に明らかになっていくからだ。
現代のプログラミング開発では最初から仕様が明確になっている事が少ない。
そのため多くの仕様変更が開発中に発生する。オブジェクト指向はそれに合った開発方法と言える。
ただ変更が容易だと体感するにはある程度の経験とセンスが必要だな。
そのレベルに達している人は結構少ない。
>>431
それをどうやって人に説明するの？
俺はオブジェクト指向と従来のやりかたのどっちが変更しやすいか？
っていわれたら、はっきりいってわからないとしか言えないけど。
ちなみに業務で
「オブジェクト指向のが変更しやすいよなぁ？」
って聞かれたら
「大して変わらなくね？ｗ」
って答える。
それをどうやって人に説明するの？
俺はオブジェクト指向と従来のやりかたのどっちが変更しやすいか？
っていわれたら、はっきりいってわからないとしか言えないけど。
ちなみに業務で
「オブジェクト指向のが変更しやすいよなぁ？」
って聞かれたら
「大して変わらなくね？ｗ」
って答える。
あきらかに手続き(特にC)と比べて変更しやすいと思うが
まぁCでも似たようなことできるが関数ポインタの嵐になる
かつGenericでタイプセーフな形で作りやすくなったし
変更のしやすさを感じないなら疎結合を意識してつくってねぇってところだろうな
まぁCでも似たようなことできるが関数ポインタの嵐になる
かつGenericでタイプセーフな形で作りやすくなったし
変更のしやすさを感じないなら疎結合を意識してつくってねぇってところだろうな
変更時こそGoFのデザインパターンの威力を実感できるでしょ。
436 ：仕様書無しさん：2007/01/17(水) 22:11:55
ここ見てるとわかってない奴ばかりだなと思う
だから俺が稼げるわけだがｗｗｗ
だから俺が稼げるわけだがｗｗｗ
>>435
俺からすればデザパタが使えるなんて言ってる雑魚は全員攻撃対象だ。
オブジェクト指向そもそもわかってねぇじゃんｗゲラゲラゲラｗ
まあ、いっしょにオブジェクト指向で中程度のプログラム組んでみりゃ納得すんだろうけど、
まわりに人がいないのは不幸なことだよねｗ
俺からすればデザパタが使えるなんて言ってる雑魚は全員攻撃対象だ。
オブジェクト指向そもそもわかってねぇじゃんｗゲラゲラゲラｗ
まあ、いっしょにオブジェクト指向で中程度のプログラム組んでみりゃ納得すんだろうけど、
まわりに人がいないのは不幸なことだよねｗ
まー、他人の口からデザパタという言葉がでると攻撃本能が
刺激されるというのは気持ちとしてわからんでもないけど。
俺も含めてこのスレの住人はオブジェクト指向の深い知識が
ないのは確か。何か問題がでるとハイ、キタとばかりにデザパタ
とか言われると、萎えるな。そのレベルで人を煽るんだもん。
オブジェクト指向厨の特徴として、「オブジェクト指向はみんな
わかってないっ。周りにわかっている人間は俺だけっ」っつーの
がある(このスレではみんな同じ事を言っているでしょｗ)けど、
もうちょっと謙虚になった方がいいと思う(俺もだが)。
職場でオブジェクト指向がわかっていると思われるのが自分だけなのは
自分が賢いんじゃなくて、みんな興味がない(どうでもいい)だけだって。
本気で理解しようと思えば自分と同じくらいは誰でもできる
と思った方がいいと思うよ。
一回オブジェクト指向から距離を置いて考えられるように、
ソフトウェアでもオブジェクト指向(アジャイルとかも含む)以外の
ことを勉強したり、職場の人間関係や要領のいい仕事の
やり方とか考えた方がいいんじゃないかな。
刺激されるというのは気持ちとしてわからんでもないけど。
俺も含めてこのスレの住人はオブジェクト指向の深い知識が
ないのは確か。何か問題がでるとハイ、キタとばかりにデザパタ
とか言われると、萎えるな。そのレベルで人を煽るんだもん。
オブジェクト指向厨の特徴として、「オブジェクト指向はみんな
わかってないっ。周りにわかっている人間は俺だけっ」っつーの
がある(このスレではみんな同じ事を言っているでしょｗ)けど、
もうちょっと謙虚になった方がいいと思う(俺もだが)。
職場でオブジェクト指向がわかっていると思われるのが自分だけなのは
自分が賢いんじゃなくて、みんな興味がない(どうでもいい)だけだって。
本気で理解しようと思えば自分と同じくらいは誰でもできる
と思った方がいいと思うよ。
一回オブジェクト指向から距離を置いて考えられるように、
ソフトウェアでもオブジェクト指向(アジャイルとかも含む)以外の
ことを勉強したり、職場の人間関係や要領のいい仕事の
やり方とか考えた方がいいんじゃないかな。
で、結局実装のミクロな話は得意で語れるけど、このすれの主題を理解できないのがオブジェクト厨
今更、デザインパターンねえ。
昔勉強したときは、実装上のテクニックとしてVisitorパターンやObserverパターンは
感心したけど、他は当たり前のことや使う機会ないだろってパターンばっかだったな。
どっちにしても詳細設計やコーディングレベルの話でこのスレで語る話とはズレてるわな。
昔勉強したときは、実装上のテクニックとしてVisitorパターンやObserverパターンは
感心したけど、他は当たり前のことや使う機会ないだろってパターンばっかだったな。
どっちにしても詳細設計やコーディングレベルの話でこのスレで語る話とはズレてるわな。
>>438
長いばっかで空っぽにもほどがあるｗ
長いばっかで空っぽにもほどがあるｗ
>>438
そうじゃなくて、実際に使ってみることもしないのにつかえねーだなんだと
ぐだぐだいってるのがむかつくんだよ。
＞自分が賢いんじゃなくて、みんな興味がない(どうでもいい)だけだって。
興味がないんだったら黙ってればいいじゃん。
大体、他のこと（特に実務レベルの）を勉強しない奴がオブジェクト指向にのみ
興味を持ったり、逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
ことありえないだろ。
まとめると「（オブジェクト指向みたいな）役に立つかどうかわからないことに必死になって、頭悪いんじゃない？」
みたいな態度をとってること自体が、ものすごい低能ぶりを晒してるってことに気づけない分際で偉そうに批判ばっかり
繰り返してる奴は死ねばいいってこと。
そうじゃなくて、実際に使ってみることもしないのにつかえねーだなんだと
ぐだぐだいってるのがむかつくんだよ。
＞自分が賢いんじゃなくて、みんな興味がない(どうでもいい)だけだって。
興味がないんだったら黙ってればいいじゃん。
大体、他のこと（特に実務レベルの）を勉強しない奴がオブジェクト指向にのみ
興味を持ったり、逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
ことありえないだろ。
まとめると「（オブジェクト指向みたいな）役に立つかどうかわからないことに必死になって、頭悪いんじゃない？」
みたいな態度をとってること自体が、ものすごい低能ぶりを晒してるってことに気づけない分際で偉そうに批判ばっかり
繰り返してる奴は死ねばいいってこと。
> そうじゃなくて、実際に使ってみることもしないのにつかえねーだなんだと
> ぐだぐだいってるのがむかつくんだよ。
使ってみてあえて使えないという人の存在を無視してるな。
批判するやつは理解できないやつかやったことのない奴かどっちかと
思っているというパターンも多いな。
だいたいどんな技術にも批判はあるわけであって、オブジェクト指向
の生産性や再利用性に疑問を投げかける意見があっても当然だ。
そういう批判に対して冷静に評価することも必要だろ。
どっちにしても入れ込みすぎ。
> 逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
> ことありえないだろ。
ついでにこういう人はいるよ。
> ぐだぐだいってるのがむかつくんだよ。
使ってみてあえて使えないという人の存在を無視してるな。
批判するやつは理解できないやつかやったことのない奴かどっちかと
思っているというパターンも多いな。
だいたいどんな技術にも批判はあるわけであって、オブジェクト指向
の生産性や再利用性に疑問を投げかける意見があっても当然だ。
そういう批判に対して冷静に評価することも必要だろ。
どっちにしても入れ込みすぎ。
> 逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
> ことありえないだろ。
ついでにこういう人はいるよ。
あまりにぶっ飛んだ流れなので、ついにレスするけど
大きなソフトウェア開発（つまり業務開発）でＯＯＰを使わないなんて事が
現実上あり得るのか？
このスレにいるのは、趣味ＰＧか同人ＰＧだろ？
ＯＯＰの実用性を否定するなんてあり得んぞ？
それが無いと開発できないのだから。
大きなソフトウェア開発（つまり業務開発）でＯＯＰを使わないなんて事が
現実上あり得るのか？
このスレにいるのは、趣味ＰＧか同人ＰＧだろ？
ＯＯＰの実用性を否定するなんてあり得んぞ？
それが無いと開発できないのだから。
まあ、たしかに微妙なんだよなー。
オブジェクト指向なら開発期間が２分の１になりますよ！
なんていって、本当に開発期間を２分の１にされた挙句
時間あたりの給料も２分の１（つまり給料そのまま）じゃやってらんねぇしなｗ
そのうち残業代もでなくなるっぽいし、オブジェクト指向が使えると世間が認めることに意味がねぇよ。
つまり、実際は微妙なのに「オブジェクト指向導入したから期間は２分の１でいいよね？」とかめちゃくちゃな
ことを言われそうな気がするんだよね。
しかも、俺等の技術なんて評価されたことないじゃない？
オブジェクト指向なら開発期間が２分の１になりますよ！
なんていって、本当に開発期間を２分の１にされた挙句
時間あたりの給料も２分の１（つまり給料そのまま）じゃやってらんねぇしなｗ
そのうち残業代もでなくなるっぽいし、オブジェクト指向が使えると世間が認めることに意味がねぇよ。
つまり、実際は微妙なのに「オブジェクト指向導入したから期間は２分の１でいいよね？」とかめちゃくちゃな
ことを言われそうな気がするんだよね。
しかも、俺等の技術なんて評価されたことないじゃない？
OODははやってないっていってんじゃん。
>>449
アナタの業務タイプを教えてくれ
アナタの業務タイプを教えてくれ
大規模開発ほどオブジェクト指向は向いてないよ。
だって人数が多くなればなるほどオブジェクト指向わかってない奴が増えるもの。
うちの先輩の設計を見てきた俺が言うんだから間違いない。
だって人数が多くなればなるほどオブジェクト指向わかってない奴が増えるもの。
うちの先輩の設計を見てきた俺が言うんだから間違いない。
＞使ってみてあえて使えないという人の存在を無視
拡大解釈すんなよ。そんなこといってねー。
それにそういう奴は「こういうところで使えないと思うんだけどどうよ？」的なレスしなきゃ
何の意味もないだろ。
>> 逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
>> ことありえないだろ。
> ついでにこういう人はいるよ。
マジョリティではありえないし、そうでないならこれ書くことに何の意味があるの？
拡大解釈すんなよ。そんなこといってねー。
それにそういう奴は「こういうところで使えないと思うんだけどどうよ？」的なレスしなきゃ
何の意味もないだろ。
>> 逆によく勉強する奴がオブジェクト指向にのみ興味がないなんて
>> ことありえないだろ。
> ついでにこういう人はいるよ。
マジョリティではありえないし、そうでないならこれ書くことに何の意味があるの？
大規模っつったら、新規なんてそうそうないだろ。
つか、大規模のプロジェクトに関われば関わるほど保守の仕事が多くなるはず。
そこで必要になるのはオブジェクト指向なんかじゃないよな。
つか、大規模のプロジェクトに関われば関わるほど保守の仕事が多くなるはず。
そこで必要になるのはオブジェクト指向なんかじゃないよな。
> ＯＯＰの実用性を否定するなんてあり得んぞ？
大きなソフトウェア開発にOOPを使うことが必須でも、否定しちゃならん
ということにはならんと思うんですが。
OOP自体の実用性はプラマイゼロでも開発インフラ、フレームワークや
コンポーネントがあるからOOPをつかうというのもありだと思うんですが。
実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
が優れているからという理由以外がかなり大きいと思うんですが。
オブジェクト指向を批判する人に多いのは、プライマイゼロの評価で、
つまりプラマイゼロならその他の要因があればOOPをつかう選択も
ありうると思うんですが。
単純にパラダイムの優劣でだけですべてが決まるならLISP厨が
いっているみたいにLISPが天下をとってたかもしれない。
(個人的にはありえないと思うが)
大きなソフトウェア開発にOOPを使うことが必須でも、否定しちゃならん
ということにはならんと思うんですが。
OOP自体の実用性はプラマイゼロでも開発インフラ、フレームワークや
コンポーネントがあるからOOPをつかうというのもありだと思うんですが。
実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
が優れているからという理由以外がかなり大きいと思うんですが。
オブジェクト指向を批判する人に多いのは、プライマイゼロの評価で、
つまりプラマイゼロならその他の要因があればOOPをつかう選択も
ありうると思うんですが。
単純にパラダイムの優劣でだけですべてが決まるならLISP厨が
いっているみたいにLISPが天下をとってたかもしれない。
(個人的にはありえないと思うが)
＞実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
＞が優れているからという理由以外がかなり大きいと思うんですが。
なんだっつーの？
＞が優れているからという理由以外がかなり大きいと思うんですが。
なんだっつーの？
458 ：仕様書無しさん：2007/01/18(木) 00:13:33
>実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
>が優れているからという理由以外がかなり大きいと思うんですが。
もう、こういうあいまいことわかってるふりして言う奴晒していこうぜ。
こういうただでさえあいまいなモンの議論してるときにアフォとしか思えない。
２ちゃんに二度とくる気になれないぐらいぶっ叩いてご退場いただこう。
で、なによ？
>が優れているからという理由以外がかなり大きいと思うんですが。
もう、こういうあいまいことわかってるふりして言う奴晒していこうぜ。
こういうただでさえあいまいなモンの議論してるときにアフォとしか思えない。
２ちゃんに二度とくる気になれないぐらいぶっ叩いてご退場いただこう。
で、なによ？
>458
> OOP自体の実用性はプラマイゼロでも開発インフラ、フレームワークや
> コンポーネントがあるからOOPをつかうというのもありだと思うんですが。
って書いてるでしょ。
あと、マイクロソフトやサンマイクロシステムズのような大手の
ソフトウェアベンダーがOOP関係のテクノロジを推進しているという
政治的理由。実際問題、力を持っているマイクロソフトなんかには
みんな追随するしかないでしょ。技術的優劣とは関係なしに。
これらの企業がまったく違うパラダイムを推進していたら、
今現在の状況はまったく違っていたのは間違いない。
ソフトウェア関係は標準になったり、デファクトスタンダードに
なったものが強いのはみんな良く知っているでしょ。
> OOP自体の実用性はプラマイゼロでも開発インフラ、フレームワークや
> コンポーネントがあるからOOPをつかうというのもありだと思うんですが。
って書いてるでしょ。
あと、マイクロソフトやサンマイクロシステムズのような大手の
ソフトウェアベンダーがOOP関係のテクノロジを推進しているという
政治的理由。実際問題、力を持っているマイクロソフトなんかには
みんな追随するしかないでしょ。技術的優劣とは関係なしに。
これらの企業がまったく違うパラダイムを推進していたら、
今現在の状況はまったく違っていたのは間違いない。
ソフトウェア関係は標準になったり、デファクトスタンダードに
なったものが強いのはみんな良く知っているでしょ。
技術的優劣ですべてが決すると思っているのはイノセントすぎると
思うんだけど。
コンピュータ言語の基礎理論の研究している人で、既存のオブジェクト
志向言語よりもっといいものがあると思っている人はたくさんいるけど、
インフラのめんとかで結局実用的じゃなくて地団駄踏んでいることが多い。
思うんだけど。
コンピュータ言語の基礎理論の研究している人で、既存のオブジェクト
志向言語よりもっといいものがあると思っている人はたくさんいるけど、
インフラのめんとかで結局実用的じゃなくて地団駄踏んでいることが多い。
単なるインクリメンタルモデルなら良いが
手戻り前提の意識で手抜き設計されては困る。
手戻り前提の意識で手抜き設計されては困る。
手戻りとは・・
×追加
○やり直し
×追加
○やり直し
>>459
> あと、マイクロソフトやサンマイクロシステムズのような大手の
> ソフトウェアベンダーがOOP関係のテクノロジを推進しているという
> 政治的理由。実際問題、力を持っているマイクロソフトなんかには
> みんな追随するしかないでしょ。技術的優劣とは関係なしに。
>
> これらの企業がまったく違うパラダイムを推進していたら、
> 今現在の状況はまったく違っていたのは間違いない。
>
> ソフトウェア関係は標準になったり、デファクトスタンダードに
> なったものが強いのはみんな良く知っているでしょ。
だからなんなのさ？
> あと、マイクロソフトやサンマイクロシステムズのような大手の
> ソフトウェアベンダーがOOP関係のテクノロジを推進しているという
> 政治的理由。実際問題、力を持っているマイクロソフトなんかには
> みんな追随するしかないでしょ。技術的優劣とは関係なしに。
>
> これらの企業がまったく違うパラダイムを推進していたら、
> 今現在の状況はまったく違っていたのは間違いない。
>
> ソフトウェア関係は標準になったり、デファクトスタンダードに
> なったものが強いのはみんな良く知っているでしょ。
だからなんなのさ？
> だからなんなのさ？
だから批判していてもつかっている人はいるし、技術的な批判しちゃいけない
ということはないという話。理解できないのか。
だから批判していてもつかっている人はいるし、技術的な批判しちゃいけない
ということはないという話。理解できないのか。
>>464
> > だからなんなのさ？
> だから批判していてもつかっている人はいるし、技術的な批判しちゃいけない
> ということはないという話。理解できないのか。
理解できない。
その2行で事足りることを、あえて長文で難しく表現するのかが。
> > だからなんなのさ？
> だから批判していてもつかっている人はいるし、技術的な批判しちゃいけない
> ということはないという話。理解できないのか。
理解できない。
その2行で事足りることを、あえて長文で難しく表現するのかが。
エンジニアの文章じゃないな。意図が全然伝わってこない。
>>459
さっきから何度も言われてると思うが、プログラミングの技術としてのオブジェクト指向と、
分析や設計の技術としてのオブジェクト指向を分けて考えようよ。
前者はこのスレでは叩かれてないし、みんな恩恵を理解して使用してるよ。
さっきから何度も言われてると思うが、プログラミングの技術としてのオブジェクト指向と、
分析や設計の技術としてのオブジェクト指向を分けて考えようよ。
前者はこのスレでは叩かれてないし、みんな恩恵を理解して使用してるよ。
オブジェクト指向の定義そのものが１０人いれば１０通りあるわけで
「オブジェクト指向的な考え方」は有益、としか言えない。
教条主義的にオブジェクト指向と言われるものを何でも持ち込んで
構造を理解することの方が、コーディングするより遥かに難しい
設計をする奴も結構いるから嫌われる。
「オブジェクト指向的な考え方」は有益、としか言えない。
教条主義的にオブジェクト指向と言われるものを何でも持ち込んで
構造を理解することの方が、コーディングするより遥かに難しい
設計をする奴も結構いるから嫌われる。
>>439
禿同。スレタイよく嫁と。
>>446
近年のモノならな。(OOPに限っては)
10年20年前のコードをメンテするような大規模プロジェクトもある（と思う）。
>>456
> 実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
> が優れているからという理由以外がかなり大きいと思うんですが。
言語がOOだからね。
禿同。スレタイよく嫁と。
>>446
近年のモノならな。(OOPに限っては)
10年20年前のコードをメンテするような大規模プロジェクトもある（と思う）。
>>456
> 実際、現状、大規模開発でOOPが使われている理由は、オブジェクト指向
> が優れているからという理由以外がかなり大きいと思うんですが。
言語がOOだからね。
470 ：仕様書無しさん：2007/01/18(木) 01:01:23
上流の設計と下流の詳細設計及びコーディングなんて分けする奴の方がオブジェクト指向をわかってないね
>>470
厨房は学校池
厨房は学校池
まあ、ケイやストラウストラップもコーディングの効率性・保守性・
拡張性、といったことのために「概念」を提供してるんだけどな。
「設計・分析は何のためにあるか？」ってことを忘れてる奴が
多すぎる。モノを作るってのは形而上のことじゃないだろ。
拡張性、といったことのために「概念」を提供してるんだけどな。
「設計・分析は何のためにあるか？」ってことを忘れてる奴が
多すぎる。モノを作るってのは形而上のことじゃないだろ。
>>469
OOPとOOD/OOAの関係は、ミクロとマクロの関係じゃないだろ。
OOPとOOD/OOAの関係は、ミクロとマクロの関係じゃないだろ。
>>434
> まぁCでも似たようなことできるが関数ポインタの嵐になる
いや、たいていモジュール化で済む、という話をしていたはずだけど。
dll(API)とか、COMとか、部品化する利点の一つは再利用性な
わけで、変更しやすさってその域からあまり大きく変わってないのでは？
という話だと思う。
> まぁCでも似たようなことできるが関数ポインタの嵐になる
いや、たいていモジュール化で済む、という話をしていたはずだけど。
dll(API)とか、COMとか、部品化する利点の一つは再利用性な
わけで、変更しやすさってその域からあまり大きく変わってないのでは？
という話だと思う。
>>475
どこにレスしてんだよｗ
どこにレスしてんだよｗ
手戻りコストを抑えられたとしても決して０にならない。
よって、設計の手抜きを助長する考え方として説くべきではない。
よって、設計の手抜きを助長する考え方として説くべきではない。
479 ：仕様書無しさん：2007/01/18(木) 01:27:12
趣味PGや同人PGの方が好きでやってるからOOPもしやすいんじゃないかな
多様な具象を知るから抽象化ができる。
前線を知らない大本営が戦略立ててもダメでしょ。
中にはいるかも知れないが、１万人に１人いるかいないか…
前線を知らない大本営が戦略立ててもダメでしょ。
中にはいるかも知れないが、１万人に１人いるかいないか…
>>482
いえいえ^^
日本語でさえ、意思疎通は大変なのだから。
ましてOOD/OOA(言語はUMLか？)で意思疎通をするなら
プロジェクト関係者の過半が一定の共通理解している必要があるよね。
というのがスレタイに対する俺の意見。
いえいえ^^
日本語でさえ、意思疎通は大変なのだから。
ましてOOD/OOA(言語はUMLか？)で意思疎通をするなら
プロジェクト関係者の過半が一定の共通理解している必要があるよね。
というのがスレタイに対する俺の意見。
多用な具象はプログラムではなく
ユーザーから抽出するべき。
ユーザーから抽出するべき。
>>484
それも一理あるが、プログラムが判らないんじゃ具現化できんよ。
それも一理あるが、プログラムが判らないんじゃ具現化できんよ。
487 ：仕様書無しさん：2007/01/18(木) 01:50:29
もういいから自分の所だけオブジェクト指向でつくっとけ。
488 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 01:53:44
オブジェクト指向を振り回すやつはたいてい サブルーチンさえまともに作れないやつだけどな
コボラ乙
490 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 02:01:42
コボルしらね
Javaはさんざんやったけど 今はVCだな
デザパタも大抵のパターン少なくとも一度は使った
それで駄目だと証明できたので必要なときに部分的に使うことがあるくらいだ。
悪いことはいわんから、こんなたちの悪い宗教からは足を洗いたまえ。
Javaはさんざんやったけど 今はVCだな
デザパタも大抵のパターン少なくとも一度は使った
それで駄目だと証明できたので必要なときに部分的に使うことがあるくらいだ。
悪いことはいわんから、こんなたちの悪い宗教からは足を洗いたまえ。
別にUMLでもいいんだけど、補足資料が足りない奴が多いんだろ。
昔風のフローや画面図が必要なこともある。
判ってる自分だけの世界で完結しちゃうから現場が付いてこない。
法の制定と運用は違うわけだし、慣習法的な考え方も必要。
お前ら勉強しろよって言ってるだけじゃ、どうにもならんと思うよ。
昔風のフローや画面図が必要なこともある。
判ってる自分だけの世界で完結しちゃうから現場が付いてこない。
法の制定と運用は違うわけだし、慣習法的な考え方も必要。
お前ら勉強しろよって言ってるだけじゃ、どうにもならんと思うよ。
JavaとかC+とかってなんかOOP的にしなきゃって思うじゃん
>>490
2ch黎明期じゃあるまいし、今日日そのレスはないだろ。
2ch黎明期じゃあるまいし、今日日そのレスはないだろ。
>>492
別に「OOP的」に書くのは問題ない。
Cにしたって未だに++は使う必要ないとか言ってる方がオカシイ。
OOP的概念の何を使うかってことだろ。例として言えば継承だって
単にクラスを継承することとインターフェースの継承は概念として
違うし、インターフェース継承だけして直接ハードウェアアクセス
するとこはモロにCで書くなんてよくあること。混在で何の問題もない。
ケースバイケースでリアリズムに徹すればいいと思うけどね。
ターゲットと開発メンバーを見てOOPの概念の何を採用するかを
決めればいいことだと思うよ。
別に「OOP的」に書くのは問題ない。
Cにしたって未だに++は使う必要ないとか言ってる方がオカシイ。
OOP的概念の何を使うかってことだろ。例として言えば継承だって
単にクラスを継承することとインターフェースの継承は概念として
違うし、インターフェース継承だけして直接ハードウェアアクセス
するとこはモロにCで書くなんてよくあること。混在で何の問題もない。
ケースバイケースでリアリズムに徹すればいいと思うけどね。
ターゲットと開発メンバーを見てOOPの概念の何を採用するかを
決めればいいことだと思うよ。
ユーザーからの抽出が困難だから
仕様変更に強い考え方が生まれるのは理解できるが
設計が手抜きになる分、仕様変更が多くなり
実装チームが振り回されるだけ。
デスマ誘発率は高い。
仕様変更に強い考え方が生まれるのは理解できるが
設計が手抜きになる分、仕様変更が多くなり
実装チームが振り回されるだけ。
デスマ誘発率は高い。
496 ：仕様書無しさん：2007/01/18(木) 03:03:51
>>490
ココ電逝ったあああああああああああああああああああああああああ
ココ電逝ったあああああああああああああああああああああああああ
497 ：仕様書無しさん：2007/01/18(木) 03:07:30
そろそろお勉強のための本でも紹介してくれるとありがたく。
>>486
構造化設計なら理解している奴が多いと何度かレスがあるようだが・・・？
>>491
現実には、OOなプログラムを作ろうとしているものを、
フローチャートなどへ「翻訳」する作業が発生する。
それが補足資料的なものになるのかな。
>>495
そうかもしれない。仕様変更に強いからといってもそれに頼りすぎるとｲｸﾅｲ。
ユーザから多用な具象を抽出する努力を放棄するエクスキューズにはならんと思われ。
(これはOOに限らん)
プログラムから抽出する「共通クラス」厨にはなりたくないものだｗｗ
構造化設計なら理解している奴が多いと何度かレスがあるようだが・・・？
>>491
現実には、OOなプログラムを作ろうとしているものを、
フローチャートなどへ「翻訳」する作業が発生する。
それが補足資料的なものになるのかな。
>>495
そうかもしれない。仕様変更に強いからといってもそれに頼りすぎるとｲｸﾅｲ。
ユーザから多用な具象を抽出する努力を放棄するエクスキューズにはならんと思われ。
(これはOOに限らん)
プログラムから抽出する「共通クラス」厨にはなりたくないものだｗｗ
まぁ、結局は数字を出さなきゃだめだってことだよ。
評価してもらうなら、ね。
漏れの場合は、
「この部分は本来これだけ工数が掛かるところを～」
というのを上司に説明して、なんとか認めて貰ったことはある。
けど、結果は当たり前で、作業効率が上がった分、
仕事が増えて、給料据え置き。
そして、今では自分の睡眠時間を増やすためにOOを勉強してる。
そんなもんだろ、現実は。
評価してもらうなら、ね。
漏れの場合は、
「この部分は本来これだけ工数が掛かるところを～」
というのを上司に説明して、なんとか認めて貰ったことはある。
けど、結果は当たり前で、作業効率が上がった分、
仕事が増えて、給料据え置き。
そして、今では自分の睡眠時間を増やすためにOOを勉強してる。
そんなもんだろ、現実は。
おれも>>494に同意。
「こうでなくてはならない」から先に考えるべきではないと思う。
「こうでなくてはならない」から先に考えるべきではないと思う。
502 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 08:37:35
時計をオブジェクト指向で作ると失敗する
まずゼンマイオブジェクト 竜頭オブジェクト 歯車オブジェクトと 作っていき
針オブジェクトから派生した秒針 分針 時針オブジェクトで終わる。
すげー手間がかかる上になにもいいことがない
まずゼンマイオブジェクト 竜頭オブジェクト 歯車オブジェクトと 作っていき
針オブジェクトから派生した秒針 分針 時針オブジェクトで終わる。
すげー手間がかかる上になにもいいことがない
>>502
閏秒には対応しやすいだろ
閏秒には対応しやすいだろ
>502
デザイン変更等が用意
大体、ゼンマイにしろ歯車にしろ作るのには
かわりないから、手間は良くも悪くもほとんど変わらん。
デザイン変更等が用意
大体、ゼンマイにしろ歯車にしろ作るのには
かわりないから、手間は良くも悪くもほとんど変わらん。
>>500
こういう人が設計工程で増えてくれば、普及するし楽にもなるんだがな。
こういう人が設計工程で増えてくれば、普及するし楽にもなるんだがな。
507 ：おじゃばさま：2007/01/18(木) 09:51:13
>432,433
構造化プログラミング言語であるCでは、データ構造は構造体として分割するが、
処理は分割せずに関数として記述する。
そのため処理が追加された場合は、データは分割されるが、処理はごちゃ混ぜになる。
オブジェクト指向言語であるJavaではデータはフィールド変数、処理はメソッドとして分割される。
そのため処理が追加されても、データも処理も分割される。
で追加される処理が多ければ多いほど、それが共通の処理なのか、もしくはどの部分が共通でどの部分が
固有なのかが分かるため、それがどこのメソッドに追加されるのかが明確になってくる。
つまり、
Cでは仕様変更が発生すると、関数内にif文が追加され、コメントを見ないと分からないような
処理が増えて、複雑になる。
Jacaでは仕様変更が発生すると、クラスやメソッドが増えるが、今までの処理も共通化されたりして、
使いやすくなっていく。
と言うことだ。
構造化プログラミング言語であるCでは、データ構造は構造体として分割するが、
処理は分割せずに関数として記述する。
そのため処理が追加された場合は、データは分割されるが、処理はごちゃ混ぜになる。
オブジェクト指向言語であるJavaではデータはフィールド変数、処理はメソッドとして分割される。
そのため処理が追加されても、データも処理も分割される。
で追加される処理が多ければ多いほど、それが共通の処理なのか、もしくはどの部分が共通でどの部分が
固有なのかが分かるため、それがどこのメソッドに追加されるのかが明確になってくる。
つまり、
Cでは仕様変更が発生すると、関数内にif文が追加され、コメントを見ないと分からないような
処理が増えて、複雑になる。
Jacaでは仕様変更が発生すると、クラスやメソッドが増えるが、今までの処理も共通化されたりして、
使いやすくなっていく。
と言うことだ。
で、結局コーディングレベルの話ばかりで、そもそもの話は夜中中無かったわけか。
>>508
キモコテはスルーでよろ
キモコテはスルーでよろ
510 ：おじゃばさま：2007/01/18(木) 10:55:29
オブジェクト指向プログラミングは明確な定義があるが、
オブジェクト指向設計は明確な定義があるがある訳ではないので、まず定義から始める必要があるだろう。
長々と書いても分かりにくいと思うので、
「オブジェクト指向設計」＝「ユースケース図とシーケンス図を作る」
でいいかな？
オブジェクト指向設計は明確な定義があるがある訳ではないので、まず定義から始める必要があるだろう。
長々と書いても分かりにくいと思うので、
「オブジェクト指向設計」＝「ユースケース図とシーケンス図を作る」
でいいかな？
511 ：仕様書無しさん：2007/01/18(木) 11:01:54
512 ：仕様書無しさん：2007/01/18(木) 11:08:22
俺はオブジェクト指向はよくわからんけど
もしアナログ時計とデジタル時計をを作るなら、
時計エンジン＋ＧＵＩ (アナログなら針と文字盤、デジタルなら液晶)
ってなるんじゃね？
要は時間を情報として提供できる部分があって、
その情報を表示ドライバが引数に取ればいいだけのこと。
もしアナログ時計とデジタル時計をを作るなら、
時計エンジン＋ＧＵＩ (アナログなら針と文字盤、デジタルなら液晶)
ってなるんじゃね？
要は時間を情報として提供できる部分があって、
その情報を表示ドライバが引数に取ればいいだけのこと。
それ単にCのDLLとかでも一向に構わんのじゃ
515 ：おじゃばさま：2007/01/18(木) 12:27:33
じゃオブジェクト指向設計の定義って何？
516 ：仕様書無しさん：2007/01/18(木) 13:00:41
オブジェクト指向は円周率が変わった場合にプログラムの変更が容易になるという利点がある。
518 ：仕様書無しさん：2007/01/18(木) 14:01:47
もう答えが出たな。
つまり「小さい変更には便利かも知れないが、大きい変更ではあまり
利点はなく、コンポーネント化の利点と大きな差はない」
だから「利点があまり大きくないのだから、新しい技術を導入する
コストや、それに合わせていろいろ変更するコストを考えると
二の足を踏むのもむべなるかな」となって「だからOOは流行らない」
Q.E.D
つまり「小さい変更には便利かも知れないが、大きい変更ではあまり
利点はなく、コンポーネント化の利点と大きな差はない」
だから「利点があまり大きくないのだから、新しい技術を導入する
コストや、それに合わせていろいろ変更するコストを考えると
二の足を踏むのもむべなるかな」となって「だからOOは流行らない」
Q.E.D
519 ：仕様書無しさん：2007/01/18(木) 17:04:57
>>518
のようなDQNがおるから。。。。。。
のような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
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、
というものである。気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
ってもん。
別に再利用とか作業の標準化とか部品化なんて考えてない
単純に、感覚的に「考え易いでしょ？」っていう感覚的なもの。
なんでどっかの学者さんがこうやって定義してあります。みたいな答えをみんな求めるんだろう・・・。
「考え易いでしょ？」ってただそんだけだよ。そんだけ。
>そういうためのもんだろ。
違うってはじめは
http://ja.wikipedia.org/wiki/Simula
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、
というものである。気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
ってもん。
別に再利用とか作業の標準化とか部品化なんて考えてない
単純に、感覚的に「考え易いでしょ？」っていう感覚的なもの。
なんでどっかの学者さんがこうやって定義してあります。みたいな答えをみんな求めるんだろう・・・。
「考え易いでしょ？」ってただそんだけだよ。そんだけ。
524 ：仕様書無しさん：2007/01/18(木) 19:23:05
>>523でオブジェクト指向っぽいものをはじめに作った人に
「別に考え易くないです。」
って反論したとしても
「ああ、そう・・・ｗそりゃ残念・・・ｗ」
程度のモンだと思うよ。
はじめは軽い考えで、「どうよ？いいんじゃね？」ってもうフィーリング１００％だと思うよ。
なのに、再利用のためだとかどうとか無理やりこじつけすぎ。
どう考えたって再利用だのなんだの後付けだろ。
セミナーで金設けするために無理やり新しい用語作ったり、無駄に崇高なものにされた感がいなめない。
「別に考え易くないです。」
って反論したとしても
「ああ、そう・・・ｗそりゃ残念・・・ｗ」
程度のモンだと思うよ。
はじめは軽い考えで、「どうよ？いいんじゃね？」ってもうフィーリング１００％だと思うよ。
なのに、再利用のためだとかどうとか無理やりこじつけすぎ。
どう考えたって再利用だのなんだの後付けだろ。
セミナーで金設けするために無理やり新しい用語作ったり、無駄に崇高なものにされた感がいなめない。
何故に、志村？
Smalltalkが初めじゃねぇか？
Smalltalkが初めじゃねぇか？
そらはやらんわな
>>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_
ここを読んで俺なりに超要約した限りでは、
「ユースケース図とシーケンス図を作ればオブジェクト指向設計」と解釈したのだが、違うと言われた。
オブジェクト指向が省力化のためだと言われれば「そりゃそうだ」としか言えないが、
それでは構造化などもおなじな訳で、議論にならないのではないかと思う。
コンピュータ業界の発展を願うなら、オブジェクト指向設計を解説すべきではないだろうか？
オブジェクト指向プログラミングの利点は以前に述べた通りだが、オブジェクト指向設計は不明だ。
オブジェクト指向設計の定義自体が曖昧ではあるが、以下のHPで解説されている。
ttp://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#id_427_
ここを読んで俺なりに超要約した限りでは、
「ユースケース図とシーケンス図を作ればオブジェクト指向設計」と解釈したのだが、違うと言われた。
オブジェクト指向が省力化のためだと言われれば「そりゃそうだ」としか言えないが、
それでは構造化などもおなじな訳で、議論にならないのではないかと思う。
コンピュータ業界の発展を願うなら、オブジェクト指向設計を解説すべきではないだろうか？
529 ：おじゃばさま：2007/01/18(木) 19:52:28
と書いてる間に解説する人が現れたこのスレも捨てた物ではないと思った。
>>528
>コンピュータ業界の発展を願うなら、オブジェクト指向設計を解説すべきではないだろうか？
本当に願うなら単純に数字だけに注目することだと思うぜ。
言葉だけじゃ全くの嘘も話す人間によって本当のことのように聞こえてしまう。
>コンピュータ業界の発展を願うなら、オブジェクト指向設計を解説すべきではないだろうか？
本当に願うなら単純に数字だけに注目することだと思うぜ。
言葉だけじゃ全くの嘘も話す人間によって本当のことのように聞こえてしまう。
で>>530
が数字をだしてくれるとwwwwww
が数字をだしてくれるとwwwwww
>>531
いや、まだ、そんなところにいないんじゃないかな？
どういうことをして、どんな結果が出ればその方法が優れているって結論付けることができる
フォーマットを作らなきゃ。
まだ、はじめの一歩すら踏み出せてないってのが現状だと思う。
いや、まだ、そんなところにいないんじゃないかな？
どういうことをして、どんな結果が出ればその方法が優れているって結論付けることができる
フォーマットを作らなきゃ。
まだ、はじめの一歩すら踏み出せてないってのが現状だと思う。
変更がありそうな部分で変更に影響しない部分のみをinterfaceに切り出し
具象インスタンスを注入する形をIocで
これだけでかなりのうまみがあると
具象インスタンスを注入する形をIocで
これだけでかなりのうまみがあると
535 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 20:15:20
モジュールごとに分けてインターフェース決めてさ
中は各担当者が勝手なスタイルで作るのがいいと思うよ。
力んだOO厨の試行錯誤に付き合わされた挙句 「おまいらはOOを理解していない、勉強する気がない」 などと
喚かれるのは疲れるだけだしさあ。
OOの人のモジュールが優れていれば周りもついてくるからそうしようね。
中は各担当者が勝手なスタイルで作るのがいいと思うよ。
力んだOO厨の試行錯誤に付き合わされた挙句 「おまいらはOOを理解していない、勉強する気がない」 などと
喚かれるのは疲れるだけだしさあ。
OOの人のモジュールが優れていれば周りもついてくるからそうしようね。
537 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 20:20:13
ぷっ これでオブジェクト指向のつもり？ｗｗｗ
ってなのばっかりだけどな
ってなのばっかりだけどな
>>536
いや、その発言には賛同しかねる。
いや、その発言には賛同しかねる。
540 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 20:26:41
まず目に付くのは ライブラリをペタペタ延々と並べていってるの
次のソースもその次のソースもただライブラリをそのまま持ってきて延々と並べてるだけのやつ
構造がない
サブルーチンさえない。
センスのあるやつなら下位構造から上位構造までピラミッドみたいな全体図をもってるわけだが、
この手の人たちは一階建ての街を延々と建設するわけだ。
次のソースもその次のソースもただライブラリをそのまま持ってきて延々と並べてるだけのやつ
構造がない
サブルーチンさえない。
センスのあるやつなら下位構造から上位構造までピラミッドみたいな全体図をもってるわけだが、
この手の人たちは一階建ての街を延々と建設するわけだ。
だからなんなのよこのキモコテ
市況板の名物でつ
引き取ってくれ
545 ：仕様書無しさん：2007/01/18(木) 21:27:01
少なくとも、クラス図とシーケンス図の作成に自信のある人いますか？
日本に何人くらいいるだろうか？
それがこのスレの答えだと思うが・・・・・。
言わなくてもわかってもらえると思うが、クラス図は、
インターフェースをバリバリバリューに使ったものであること。
両図とも、PGがそのままコーディングに持っていけるレベルであること。
日本に何人くらいいるだろうか？
それがこのスレの答えだと思うが・・・・・。
言わなくてもわかってもらえると思うが、クラス図は、
インターフェースをバリバリバリューに使ったものであること。
両図とも、PGがそのままコーディングに持っていけるレベルであること。
今時、クラス図シーケンス図ぐらい誰でも書くよ
547 ：仕様書無しさん：2007/01/18(木) 21:37:07
>両図とも、PGがそのままコーディングに持っていけるレベルであること。
バカバカしい。
UMLの教科書にも、いろんな開発プロセスの本にも、オブジェクト指向の解説本にも
UMLで全部やろうとするなって書いてあるだろ。
完全なモデルを作成するのなんて不可能だし、そもそもUMLじゃプログラミング言語の機能を全然表現できないんだよ。
バカバカしい。
UMLの教科書にも、いろんな開発プロセスの本にも、オブジェクト指向の解説本にも
UMLで全部やろうとするなって書いてあるだろ。
完全なモデルを作成するのなんて不可能だし、そもそもUMLじゃプログラミング言語の機能を全然表現できないんだよ。
たいていの人は走ることができるがお金がもらえるほどに走れる人はどれだけいるだろうか？
551 ：仕様書無しさん：2007/01/18(木) 21:49:40
553 ：仕様書無しさん：2007/01/18(木) 21:52:12
西日本にいるものですが、東京ではオブジェクト設計は流行っていますか？
554 ：仕様書無しさん：2007/01/18(木) 21:52:42
ココ電いますか？
クラス図シーケンス図なんてそりゃ書こうと思えば書けるが、
UMLで書いたってオブジェクト指向になってない奴はいっぱいいるし、
酷い設計は酷い設計でしかないの。
なんでそんなたかが表記法に熱心なのか。
UMLで書いたってオブジェクト指向になってない奴はいっぱいいるし、
酷い設計は酷い設計でしかないの。
なんでそんなたかが表記法に熱心なのか。
なんか、至高とか、究極のオブジェクト指向があって
それでなければ、オブジェクト指向じゃ無いと言うような
人がいるみたい、本来、オブジェクト指向なんて
そんな大層な物で無いのに、誰でも普段から自然にやってること
それでなければ、オブジェクト指向じゃ無いと言うような
人がいるみたい、本来、オブジェクト指向なんて
そんな大層な物で無いのに、誰でも普段から自然にやってること
559 ：仕様書無しさん：2007/01/18(木) 22:10:19
個人的な意見ですが、ユースケースのシナリオは従来からあるようなもので
すから、わたしも使うというか、自然な気分で使っています。
でも、ユースケース図は、利点もあるのでしょうが、頭の中がごちゃごちゃ
するので使いません。
局所的に使うことはありますが。
すから、わたしも使うというか、自然な気分で使っています。
でも、ユースケース図は、利点もあるのでしょうが、頭の中がごちゃごちゃ
するので使いません。
局所的に使うことはありますが。
>>557
それはこの↓内容に反してはいないだろうな。
http://ja.wikipedia.org/wiki/Simula
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、
というものである。気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
俺はオブジェクト指向原理主義者だからこの定義には厳しいぞ。
デザパタなんて一切認めん。
それはこの↓内容に反してはいないだろうな。
http://ja.wikipedia.org/wiki/Simula
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、
というものである。気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
俺はオブジェクト指向原理主義者だからこの定義には厳しいぞ。
デザパタなんて一切認めん。
>>559がユースケサンタマリア投入
で、なに？
クラス図、シーケンス図、ユースケース図こんなに無駄な作業いるの？
てか、いつになったら組んでいいの？
実は実装すりゃ今頃おわってんじゃねーの？
まだ、なんか書くの？
はやくしてよ。
もう、俺のＰＣには完成品あって、あと出すだけなんだよｗ
クラス図、シーケンス図、ユースケース図こんなに無駄な作業いるの？
てか、いつになったら組んでいいの？
実は実装すりゃ今頃おわってんじゃねーの？
まだ、なんか書くの？
はやくしてよ。
もう、俺のＰＣには完成品あって、あと出すだけなんだよｗ
>>560の言うオブジェクト指向の定義ってそれ？定義なのに例しか無いじゃん。
ちっと勉強足りないよ。smalltalkとeiffelの勉強してから原理主義者名乗んなさいな。
ちっと勉強足りないよ。smalltalkとeiffelの勉強してから原理主義者名乗んなさいな。
>>566
逆に俺はそんなデカイ開発にかかわったことが無いな＞クラス図、シーケンス図、ユースケース図
そもそもクラス図すらお目にかかったことがない。
ＤＢの帳票が詳しくかかれているか、エクセルを印刷した紙に手書きで「○←このへんに●●関係おいて」って
書いてある現場が日常茶飯事だった・・・マジで。
逆に俺はそんなデカイ開発にかかわったことが無いな＞クラス図、シーケンス図、ユースケース図
そもそもクラス図すらお目にかかったことがない。
ＤＢの帳票が詳しくかかれているか、エクセルを印刷した紙に手書きで「○←このへんに●●関係おいて」って
書いてある現場が日常茶飯事だった・・・マジで。
＿ / '" '"―-- ､__
＿ヽ`' ＼
,.:'" ＼
／ ヽ
/ ,ｲ i
./ ノ、i.|i ､、 ヽ
i | ﾐ.＼ヾヽ､＿＿_ヾヽヾ |
| i ､ヽ_ヽ､_i , / `__,;―'彡-i |
i ,'i/ `,ﾆ＝ﾐ`-､ヾ三''―-―' / .|
.iｲ . | |' ;'(( ,;/ '~ ゛ ￣`;)" c ﾐ i
.i .i.| ' ,|| i| ._ _-i ||:i | ｒ-､ ヽ、
丿. `| (( _゛_i__`' (( ; ﾉ// i |ヽi
/ i || i` - -､` i ﾉﾉ 'i /ヽ | ヽ
'ﾉ i )) '--､＿`7 (( , 'i ﾉノ ヽ
Y `-- " )) ﾉ ""i ヽオブジェクト指向やってると 早く家に帰れない
ﾉヽ､ ﾉﾉ _/ i ＼
/ヽ ヽヽ､＿＿_,;//--'";;" ,/ヽ、 ヾヽ
＿ヽ`' ＼
,.:'" ＼
／ ヽ
/ ,ｲ i
./ ノ、i.|i ､、 ヽ
i | ﾐ.＼ヾヽ､＿＿_ヾヽヾ |
| i ､ヽ_ヽ､_i , / `__,;―'彡-i |
i ,'i/ `,ﾆ＝ﾐ`-､ヾ三''―-―' / .|
.iｲ . | |' ;'(( ,;/ '~ ゛ ￣`;)" c ﾐ i
.i .i.| ' ,|| i| ._ _-i ||:i | ｒ-､ ヽ、
丿. `| (( _゛_i__`' (( ; ﾉ// i |ヽi
/ i || i` - -､` i ﾉﾉ 'i /ヽ | ヽ
'ﾉ i )) '--､＿`7 (( , 'i ﾉノ ヽ
Y `-- " )) ﾉ ""i ヽオブジェクト指向やってると 早く家に帰れない
ﾉヽ､ ﾉﾉ _/ i ＼
/ヽ ヽヽ､＿＿_,;//--'";;" ,/ヽ、 ヾヽ
574 ：仕様書無しさん：2007/01/18(木) 22:26:40
オブジェクト指向の原理主義ってあるね。
で、近づきたくないね。
昔、知らないでその手の本を読んで馬鹿になりかけたよ。
最近といっても２０００年以降だけど、実用本が出始めて俺は救われました。
で、近づきたくないね。
昔、知らないでその手の本を読んで馬鹿になりかけたよ。
最近といっても２０００年以降だけど、実用本が出始めて俺は救われました。
560みたいななんかよくわからん文学的かつ曖昧な定義は
定義とは言わない。個人的に。偉い人の発言だったとしても。
オブジェクト指向について厳密に意味論を定義しようと
思うと難しいよ。そんなのできたら研究所で働けるよ。
Featherweight Javaやオブジェクト算法といった計算モデルや
F-logicとかつかってがんばればできるかも。俺には無理だ。
つーか、オブジェクト指向って理論的な面では研究が遅れているね。
定義とは言わない。個人的に。偉い人の発言だったとしても。
オブジェクト指向について厳密に意味論を定義しようと
思うと難しいよ。そんなのできたら研究所で働けるよ。
Featherweight Javaやオブジェクト算法といった計算モデルや
F-logicとかつかってがんばればできるかも。俺には無理だ。
つーか、オブジェクト指向って理論的な面では研究が遅れているね。
>>574
なんだと。
俺のオブジェクト指向のオススメ書籍は憂鬱本だけだ。
他も色々読んだがこれが一番原理主義に近い。
図とか書くような解説もしてあるが、そこは別になくていいと思う。
この本の前半のオブジェクト指向の説明は正に神といっていい。
なんだと。
俺のオブジェクト指向のオススメ書籍は憂鬱本だけだ。
他も色々読んだがこれが一番原理主義に近い。
図とか書くような解説もしてあるが、そこは別になくていいと思う。
この本の前半のオブジェクト指向の説明は正に神といっていい。
>>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
オブジェクト指向のファシズムが吹き荒れてた２０００年ごろ
マ板だかム板だか忘れたが「オブジェクト指向逝ってよし」というスレを立てて最初の反旗を翻したのは私だ。
マ板でも古参コテなのでいじめないように
マ板だかム板だか忘れたが「オブジェクト指向逝ってよし」というスレを立てて最初の反旗を翻したのは私だ。
マ板でも古参コテなのでいじめないように
581 ：仕様書無しさん：2007/01/18(木) 22:40:16
俺はオブジェクト指向設計ってよく知らないんだけど、UMLのユースケースは
図にする意味は分からんが要求機能の一覧だってことは分かる。
でも、そこからどうやったらクラスやオブジェクトが切り分けられて、きちんと
動くプログラムが論理的に設計されていくのかという過程の理屈がさっぱり
見えないんで、分かる人がいたらぜひ説明してもらいたいな。
図にする意味は分からんが要求機能の一覧だってことは分かる。
でも、そこからどうやったらクラスやオブジェクトが切り分けられて、きちんと
動くプログラムが論理的に設計されていくのかという過程の理屈がさっぱり
見えないんで、分かる人がいたらぜひ説明してもらいたいな。
582 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/18(木) 22:45:21
UML図の中にフローチャートを書けば完成じゃね？
コテは失せろ
だからさ、英語の文書の書き方を語りたいのに、単なる単語の表記を語ってるようなもの。
UMLなんて単なる表記の一種、オブジェクト設計とはなーんもかんけーない。
UMLなんて単なる表記の一種、オブジェクト設計とはなーんもかんけーない。
中身を知らないことが手に取るようにわかる頭悪いレスだな
ずーっと上の方でも書いたが、開発プロセスと設計技法を混同している人がホント多いのよ。
ウチの社にもいるのだが困ったことだよ。
放置しておくと「ウォーターフォールでオブジェクト指向なんて無理」とか言い出すしね。
例えばRUPではUMLの利用はほぼ必須だが、オブジェクト指向なんてひと言も書いていない。
UMLはただの書式（言語というとオレは抵抗を感じるので）。それで何をやろうが自由。
オブジェクト指向とはなーんの関係も無いのよ。
ウチの社にもいるのだが困ったことだよ。
放置しておくと「ウォーターフォールでオブジェクト指向なんて無理」とか言い出すしね。
例えばRUPではUMLの利用はほぼ必須だが、オブジェクト指向なんてひと言も書いていない。
UMLはただの書式（言語というとオレは抵抗を感じるので）。それで何をやろうが自由。
オブジェクト指向とはなーんの関係も無いのよ。
>>585
それはちがくね？ウチも組み込み機器の動作仕様をユースケースシナリオでも
書くし、ハード配置を独自のコンポーネント図で書いたりする。
RTOS内のタスク間通信は当然シーケンス図を使って書く。
そういうのは、まさに「もの」であるから、オブジェクト設計と呼べると思うけど。
その先の実装はアセンブラ20%、C言語80%で構造化プログラムオンリーだがね。
流石にクラス図は辛い。
それはちがくね？ウチも組み込み機器の動作仕様をユースケースシナリオでも
書くし、ハード配置を独自のコンポーネント図で書いたりする。
RTOS内のタスク間通信は当然シーケンス図を使って書く。
そういうのは、まさに「もの」であるから、オブジェクト設計と呼べると思うけど。
その先の実装はアセンブラ20%、C言語80%で構造化プログラムオンリーだがね。
流石にクラス図は辛い。
論理学は普通、文法論(syntax)と意味論(semantics)の2つの側面から語られる。
同様にプログラミング言語も文法論と意味論で語られることが多い。
論理学およびプログラミング言語について理解するには、文法論も
意味論もどちらも重要。
つーのは当たり前だと思ったが、どうか。
UMLはオブジェクト指向の文法。UMLの文法を研究することで、それに
対応したUMLにおけるオブジェクト指向の意味が見えてくる。
同様にプログラミング言語も文法論と意味論で語られることが多い。
論理学およびプログラミング言語について理解するには、文法論も
意味論もどちらも重要。
つーのは当たり前だと思ったが、どうか。
UMLはオブジェクト指向の文法。UMLの文法を研究することで、それに
対応したUMLにおけるオブジェクト指向の意味が見えてくる。
UMLのうちクラス図がオブジェクト指向と相性がいいのは間違いない。
だが、
＞UMLはオブジェクト指向の文法
これは間違っている。UMLはあくまで単なる表記法。構造化手法を念頭に置いて
使うこともできるし、オブジェクト指向にもなる。
だが、
＞UMLはオブジェクト指向の文法
これは間違っている。UMLはあくまで単なる表記法。構造化手法を念頭に置いて
使うこともできるし、オブジェクト指向にもなる。
591 ：仕様書無しさん：2007/01/18(木) 23:38:29
オブジェクト指向でウォーターフォールはかなり非効率だ。
なぜか。
オブジェクト指向ではシステムをオブジェクトの相互作用で表現するわけだが、
オブジェクトの相互作用をモデリング言語で表現するのがかなり難しいからだ。
なぜか。
オブジェクト指向ではシステムをオブジェクトの相互作用で表現するわけだが、
オブジェクトの相互作用をモデリング言語で表現するのがかなり難しいからだ。
>>569 と同じ境遇の俺。
>>573 のいうことがちょっとだけありがたい。(周囲は保険業界のシステムで炎上中）
小規模開発（ＳＥ兼ＰＧみたいな)場合、
小さなな変更がちょくちょくあるから、個人的にはOOP/OODのが断然やりやすい。
構造化設計しちゃうと、共通化していた部分が「えー？片方だけちょっと変えてくれ？」
というようなことが起こりやすい。
妙な派生クラスが増産されるのがいただけないが、
ユーザの機嫌を無意味に損ねることは回避できる。
>>573 のいうことがちょっとだけありがたい。(周囲は保険業界のシステムで炎上中）
小規模開発（ＳＥ兼ＰＧみたいな)場合、
小さなな変更がちょくちょくあるから、個人的にはOOP/OODのが断然やりやすい。
構造化設計しちゃうと、共通化していた部分が「えー？片方だけちょっと変えてくれ？」
というようなことが起こりやすい。
妙な派生クラスが増産されるのがいただけないが、
ユーザの機嫌を無意味に損ねることは回避できる。
594 ：仕様書無しさん：2007/01/18(木) 23:42:40
そうです。
UMLは一般に利用されるものです。
上で誰かが書いてましたが、クラス図はオブジェクト指向にピッタリです。
たぶん、クラス図、シーケンス図はオブジェクト設計を意識してUMLに入れた
のではないでしょうか。
UMLは一般に利用されるものです。
上で誰かが書いてましたが、クラス図はオブジェクト指向にピッタリです。
たぶん、クラス図、シーケンス図はオブジェクト設計を意識してUMLに入れた
のではないでしょうか。
596 ：仕様書無しさん：2007/01/18(木) 23:45:38
派生（継承）は気をつけて使う。
合成（コンポジション）を多用する。
合成（コンポジション）を多用する。
どんな開発手法であれ、ウォーターフォールが非効率的になるケースが多いのは
数多くの事例が証明しているのだが。
それとオブジェクト指向は全く関連が無いよ。
因みにウォーターフォールがうまくいく（効率良く）条件は、
・比較的長期間のプロジェクトであること
・統率のとれた組織体であること
・各フェーズの役割と生み出される成果物が、末端にまで周知されていること
・変更要求は通常のタスクとは別次元で管理できること
数多くの事例が証明しているのだが。
それとオブジェクト指向は全く関連が無いよ。
因みにウォーターフォールがうまくいく（効率良く）条件は、
・比較的長期間のプロジェクトであること
・統率のとれた組織体であること
・各フェーズの役割と生み出される成果物が、末端にまで周知されていること
・変更要求は通常のタスクとは別次元で管理できること
OMGがそれ向けの設計書としてUMLを推奨推進してるのがUML
C++でCのAPIだけ使って開発しようが知ったことではないが
C++はオブジェクト指向と何の関係もないとか馬鹿にしか理解できない理屈だよな
C++でCのAPIだけ使って開発しようが知ったことではないが
C++はオブジェクト指向と何の関係もないとか馬鹿にしか理解できない理屈だよな
600 ：仕様書無しさん：2007/01/18(木) 23:48:02
>>588
設計手法ってのは、その図面を書くために動かす脳みそを論理的に説明というか手順化なり理論化したもの。
UMLなり他の書式・表記は、あくまでその考えた結果を相手に伝えたり記録するためのコミュニケーションツール。
だから、UMLできます。って威張る人みると、だから？って言いたくなる。
設計手法ってのは、その図面を書くために動かす脳みそを論理的に説明というか手順化なり理論化したもの。
UMLなり他の書式・表記は、あくまでその考えた結果を相手に伝えたり記録するためのコミュニケーションツール。
だから、UMLできます。って威張る人みると、だから？って言いたくなる。
UMLをオブジェクト指向以外につかっても全然問題ないわけですが。
さらに設計がオブジェクト指向で、実装がそれ以外でもいい。
UMLは言語の一種で、プログラミング言語の仲間でOOPLの親戚と
言っていい。例えばC++のようなプログラミング言語を手続き型
の使い方をしてもいいし、C言語でオブジェクト指向的なプログラミング
をしてもいい。これはUMLも同様。
ただ、UMLに関しては、仕様書でSemanticsが定義されている。
これを読めば「UMLが」想定している、定義しているオブジェクト指向が明確になる。
なのでUMLの深いところを理解すれば(通常はUML利用者は理解する必要が
なく、UMLの設計者だけ知っていればいいと言われる部分)、UMLに
おけるオブジェクト指向が見えてくる。これは恐らくもっと大きな枠の
オブジェクト指向の概念のサブセットになっているはず。
さらに設計がオブジェクト指向で、実装がそれ以外でもいい。
UMLは言語の一種で、プログラミング言語の仲間でOOPLの親戚と
言っていい。例えばC++のようなプログラミング言語を手続き型
の使い方をしてもいいし、C言語でオブジェクト指向的なプログラミング
をしてもいい。これはUMLも同様。
ただ、UMLに関しては、仕様書でSemanticsが定義されている。
これを読めば「UMLが」想定している、定義しているオブジェクト指向が明確になる。
なのでUMLの深いところを理解すれば(通常はUML利用者は理解する必要が
なく、UMLの設計者だけ知っていればいいと言われる部分)、UMLに
おけるオブジェクト指向が見えてくる。これは恐らくもっと大きな枠の
オブジェクト指向の概念のサブセットになっているはず。
＞UMLはオブジェクト指向の文法
こういうことを本気で言うヤツがいるから、ユースケース図とオブジェクト指向を
結びつけてしまう人が必ず出てくる。
UML自体はオブジェクト指向とは無関係。
ただし、オブジェクト指向設計をする上でクラス図は無くてはならないもの。
クラス図はUMLに取り入れられているから、確かに「オブジェクト指向はUMLで」
というのは間違いではない。
だが、UMLの図の中で実際にオブジェクト指向設計と純粋に関連するのは
・クラス図
・シーケンス図
・オブジェクト図
だけ。
こういうことを本気で言うヤツがいるから、ユースケース図とオブジェクト指向を
結びつけてしまう人が必ず出てくる。
UML自体はオブジェクト指向とは無関係。
ただし、オブジェクト指向設計をする上でクラス図は無くてはならないもの。
クラス図はUMLに取り入れられているから、確かに「オブジェクト指向はUMLで」
というのは間違いではない。
だが、UMLの図の中で実際にオブジェクト指向設計と純粋に関連するのは
・クラス図
・シーケンス図
・オブジェクト図
だけ。
つまり、UMLを読み解けば、少なくともブーチやヤコブソン、ランボーが
考えるオブジェクト指向がわかるってこと。
考えるオブジェクト指向がわかるってこと。
603は601の発言です。
OMGの仕様書の「Unified Modeling Language: Superstructure」、P8、9、10を見れ。
UMLと一括りにするから混乱するのだな。
実際にオブジェ設計やってるオマエラ、せいぜい書くのはクラス図とシーケンス図程度だろ？
オレも他にはたま～にステートチャートを書くくらい。
ユースケース図などまったく知らん。
実際にオブジェ設計やってるオマエラ、せいぜい書くのはクラス図とシーケンス図程度だろ？
オレも他にはたま～にステートチャートを書くくらい。
ユースケース図などまったく知らん。
UMLがオブジェクト指向と関係あろうがなかろうがどうでもいいから>>592に誰か答えてよ（；ｏ；）
>>606
おう。そーだぞ。
おう。そーだぞ。
610 ：仕様書無しさん：2007/01/19(金) 00:03:49
611 ：仕様書無しさん：2007/01/19(金) 00:05:35
そのいいとこって奴の具体例を出してくれって言ってんだよぉぉおぉおお
>>611
銀の男根は無いんだよ。
銀の男根は無いんだよ。
>>597
>ウォーターフォールがうまくいく（効率良く）条件は、
俺の知っているウォーターフォールがうまくいく条件
1.プロジェクトに期限を設定しない
2.線表はプロジェクトが終わった後に引く
3.多数のプロトタイプを作成した後にプロジェクトを開始する
4.設計段階では、設計書には罫線と日付だけを書いておく。
その後、プロジェクト終了直前に「ドキュメントのメンテナンス」
と称して、おもむろに本文を書き込む
5.結合テスト時のバグのために根本的な設計変更を行っても、
記録上、それはただの「デバッグ」作業となっている
>ウォーターフォールがうまくいく（効率良く）条件は、
俺の知っているウォーターフォールがうまくいく条件
1.プロジェクトに期限を設定しない
2.線表はプロジェクトが終わった後に引く
3.多数のプロトタイプを作成した後にプロジェクトを開始する
4.設計段階では、設計書には罫線と日付だけを書いておく。
その後、プロジェクト終了直前に「ドキュメントのメンテナンス」
と称して、おもむろに本文を書き込む
5.結合テスト時のバグのために根本的な設計変更を行っても、
記録上、それはただの「デバッグ」作業となっている
>609
言葉には意味が伴うように、表記法には必ず意味が付いてくる。
日本語の意味がわからないときは国語辞典で調べるように、
UMLの意味が知りたければOMGの仕様書を読むのが間違いないということ。
ただ、オブジェクト指向の観点からOMGがすべて正しいとは限らない。
正しいのはUMLにおける定義についてだけ。
言葉には意味が伴うように、表記法には必ず意味が付いてくる。
日本語の意味がわからないときは国語辞典で調べるように、
UMLの意味が知りたければOMGの仕様書を読むのが間違いないということ。
ただ、オブジェクト指向の観点からOMGがすべて正しいとは限らない。
正しいのはUMLにおける定義についてだけ。
OOA/OODは名前だけは有名だけど、実は誰も使ってないし誰もその実態を知らないんだろ。
そりゃ根本的に設計能力のない奴が文法だけ覚えてもな。
618 ：仕様書無しさん：2007/01/19(金) 00:14:18
オブジェクト指向分析や設計でいい本なんてあったか？アナリシスパターンとか？
>>615
それってつまり設計者のカンに頼って行き当たりばったりでやってるだけなんじゃ…
それってつまり設計者のカンに頼って行き当たりばったりでやってるだけなんじゃ…
まあオレはOMGの仕様書など読んだことが無いが、UMLありきで話をするからややこしくなるんだな。
ここで問題、UMLとクラス図、どっちが先にできたでしょーか？
答：クラス図
UMLはその名のとおり、それまでバラバラだった表記法を「統一」しようとした
ことがきっかけで生まれたもの。それ以前からクラス図というのはあったし
オブジェ設計にも使われていた。
UMLを真剣に活用したい人はOMGの仕様書は読むべきだろうが、単にオブジェクト
指向による設計をするだけならそこまで必要ないというのはオレの個人的見解。
ここで問題、UMLとクラス図、どっちが先にできたでしょーか？
答：クラス図
UMLはその名のとおり、それまでバラバラだった表記法を「統一」しようとした
ことがきっかけで生まれたもの。それ以前からクラス図というのはあったし
オブジェ設計にも使われていた。
UMLを真剣に活用したい人はOMGの仕様書は読むべきだろうが、単にオブジェクト
指向による設計をするだけならそこまで必要ないというのはオレの個人的見解。
>>619
通常「分析」なんてフェーズないんだから、それよりマシ。
通常「分析」なんてフェーズないんだから、それよりマシ。
構造化設計はコンピュータ的な思考だから、そのテの人にはおそらく楽なんだと思う。
それに対してオブジェクト指向分析ってのはモデリングがすべて。
これはコンピュータ的ではなく、むしろ社会学的な能力が必要。絶対に世間知らずな
兄ちゃんには無理。
ただしそのモデリングというのも、オレの経験上では制御系には比較的適応させ易い
けれども、上の方で誰か書いてたように業務系のRDBとはことごとく相性が悪い。
おそらく皆（オレも）ここでハマるんだろうなあ。
それに対してオブジェクト指向分析ってのはモデリングがすべて。
これはコンピュータ的ではなく、むしろ社会学的な能力が必要。絶対に世間知らずな
兄ちゃんには無理。
ただしそのモデリングというのも、オレの経験上では制御系には比較的適応させ易い
けれども、上の方で誰か書いてたように業務系のRDBとはことごとく相性が悪い。
おそらく皆（オレも）ここでハマるんだろうなあ。
付け足し。
「モデリング」とは決して絵を描くことではないよ。念のため。
「モデリング」とは決して絵を描くことではないよ。念のため。
データベース関係なんかでも、正規化のような機械的にできる設計
(これがすべてではないが)があったり、むしろ古い手法の方が
数理的、システマチックな手法が多いよね。
アジャイルとかもそうだけど、人間中心の手法が多くなっているよね。
時代が進むとどんどんシステマチックじゃなくなっていって、
かつ効率的になっていくのがソフトウェアの進化じゃないだろうか。
他の分野に比べるとかなり変わっているよね。進化の方向が。
だいたい、ソフトウェア開発をやっている人間って、時代とともに、
数学者
↓
ハッカー
↓
専門家
↓
普通の人
というように遷移しているので、どんどん社会性が求められてきて、
あんまり堅苦しいやり方は好まれないんじゃないだろうか。
(これがすべてではないが)があったり、むしろ古い手法の方が
数理的、システマチックな手法が多いよね。
アジャイルとかもそうだけど、人間中心の手法が多くなっているよね。
時代が進むとどんどんシステマチックじゃなくなっていって、
かつ効率的になっていくのがソフトウェアの進化じゃないだろうか。
他の分野に比べるとかなり変わっているよね。進化の方向が。
だいたい、ソフトウェア開発をやっている人間って、時代とともに、
数学者
↓
ハッカー
↓
専門家
↓
普通の人
というように遷移しているので、どんどん社会性が求められてきて、
あんまり堅苦しいやり方は好まれないんじゃないだろうか。
629 ：仕様書無しさん：2007/01/19(金) 00:47:02 BE:560496858-2BP(300)
>>1
オブジェクト設計という手法はどうでもいいの！
低コストで開発できるかどうかが重要なわけ。
儲かれば何でもいいのよ。
逆に、クラス図とかをこまごまと悠長に設計されていては会社としては困るわけ。
少なくとも、会社の上層部には理解されないのｗ
理論的に素晴らしいかどうかなんて関係ないの。 わかるかな？
オブジェクト設計という手法はどうでもいいの！
低コストで開発できるかどうかが重要なわけ。
儲かれば何でもいいのよ。
逆に、クラス図とかをこまごまと悠長に設計されていては会社としては困るわけ。
少なくとも、会社の上層部には理解されないのｗ
理論的に素晴らしいかどうかなんて関係ないの。 わかるかな？
＞業務系のRDBとの相性の悪さ
最近はORMのノウハウも増えてきたから特に問題ないんじゃないの？
最近はORMのノウハウも増えてきたから特に問題ないんじゃないの？
>>631
そうかもしれないな。
>>632
スレチだが、要求の非整合を調整しようとすると、
机をすぐ蹴り飛ばす客にはどうしたらいいんでしょｗ
当然設計が暗礁に乗り上げ俺が10人目くらいのPLだった頃の話。
そうかもしれないな。
>>632
スレチだが、要求の非整合を調整しようとすると、
机をすぐ蹴り飛ばす客にはどうしたらいいんでしょｗ
当然設計が暗礁に乗り上げ俺が10人目くらいのPLだった頃の話。
>>629
確かに企業は儲かってナンボだろうけど、技術屋は技術を磨き続けるのも使命。
それを理解しない経営者には決して優秀な技術者は付いてこないから、いずれ
企業としての価値が無くなるのも時間の問題。
確かに企業は儲かってナンボだろうけど、技術屋は技術を磨き続けるのも使命。
それを理解しない経営者には決して優秀な技術者は付いてこないから、いずれ
企業としての価値が無くなるのも時間の問題。
つか今気づいたんだが、ORMでマップするものってOOA/OODの成果物なわけだよな。
少なくともJava界隈ではORMのフレームワークはかなり流行していると思うんだが、
これって逆に考えるとOOA/OODがかなり一般的に行われていることの証左と思うんだがどうよ？
少なくともJava界隈ではORMのフレームワークはかなり流行していると思うんだが、
これって逆に考えるとOOA/OODがかなり一般的に行われていることの証左と思うんだがどうよ？
> ORMのフレームワークはかなり流行
流行しているように思う。ただしまだ比較的大規模なものの場合。
ちょっとうらやしく眺めるだけの俺ガイル。
流行しているように思う。ただしまだ比較的大規模なものの場合。
ちょっとうらやしく眺めるだけの俺ガイル。
で、馬鹿正直にORM使うとパフォーマンス問題に直面するわけ。
>>634
そういう会社をマジ紹介してくり・・・
そういう会社をマジ紹介してくり・・・
>>633
俺はそれほど酷いのには会ったことないなあ。
運が良かっただけかも知れんがｗ
まず基本は「筋が通ってないでしょ？」的な話を先にしないこと。
代替案を出すのが先なんじゃないかな。「こうすれば、もっと
良くなる」的な。まあ、多少のゴマカシは必須ｗ
俺はそれほど酷いのには会ったことないなあ。
運が良かっただけかも知れんがｗ
まず基本は「筋が通ってないでしょ？」的な話を先にしないこと。
代替案を出すのが先なんじゃないかな。「こうすれば、もっと
良くなる」的な。まあ、多少のゴマカシは必須ｗ
>>633
思考より先に感情が動く人には何やったって無理。その人自身がそのクセを
直そうとすること、それにはまず自分を客観的に見るようにするしかないと思う。
ひとつ手があるな。
そいつがホレそうな女にしゃべらせる。エエカッコ見せようとすると、それほど
無茶なことも言わないんじゃないか。
思考より先に感情が動く人には何やったって無理。その人自身がそのクセを
直そうとすること、それにはまず自分を客観的に見るようにするしかないと思う。
ひとつ手があるな。
そいつがホレそうな女にしゃべらせる。エエカッコ見せようとすると、それほど
無茶なことも言わないんじゃないか。
問題点を指摘されると自分が責められてるように感じる
人間も多いからなあ
人間も多いからなあ
>>645
分析フェーズでシーケンス図ってどうやって使うのかよく分からないなあ。
分析フェーズでシーケンス図ってどうやって使うのかよく分からないなあ。
>>646
シーケンス図とかでググるといろいろあったよ。
シーケンス図とかでググるといろいろあったよ。
648 ：おじゃばさま：2007/01/19(金) 09:57:06
開発手法と設計は別の物と言われている。確かに別の物であるが、俺は密接に関係していると思う。
開発手法としてはウォーターフォールとかプロトタイプとかあるが、実はここに基本的な誤りがある。
それは「設計図」と「完成品」の認識の違いである。
例えば飛行機を作るとしよう。
”設計図を書いて試作品を作る。テスト飛行を繰り返し完成品となる。”
まあ、新しく作るならこんな感じになる。
これをソフトウェアに当てはめるとする。
ここで多くの人は「設計図＝仕様書」「完成品＝ソースコード」と考えるだろう。
”つまり、仕様書を書く。仕様書レビューを繰り返して完璧にして、ソースコードを作る。”
一見正しく見えるが、多くの開発経験者はそれでもうまく行かない事は経験済みだろう。
そして仕様書レビューが不十分だとして、無駄なレビューを繰り返す。
そして設計が悪いとか、オブジェクト指向がいいとか、SEが馬鹿だとかの話になる。
しかし最初の定義を変えたとする。
「設計書＝ソースコード」「完成品＝実行コード」としよう。
”ソースコードを書き、試作品を作る。試験を繰り返し完成品となる。”
この方法では失敗しない。まあ、問題がなくなるまで試験するのだから、当然と言えば当然だ。
つまり、要求仕様書をもらったら、即コーディングを始める。
外部インターフェース仕様書は作らずにソースコード（スタブまたは使用箇所の抜粋）を渡す。
DB仕様書も作らずにSQL文を渡す。プログラマ同士のやり取りはソースコードのみ。
どうしても客に見せる必要のある書類のみソースコード作った後に作る。
早急にテストを繰り返して完成品とする。
これが正しい開発方法であろう。
開発手法としてはウォーターフォールとかプロトタイプとかあるが、実はここに基本的な誤りがある。
それは「設計図」と「完成品」の認識の違いである。
例えば飛行機を作るとしよう。
”設計図を書いて試作品を作る。テスト飛行を繰り返し完成品となる。”
まあ、新しく作るならこんな感じになる。
これをソフトウェアに当てはめるとする。
ここで多くの人は「設計図＝仕様書」「完成品＝ソースコード」と考えるだろう。
”つまり、仕様書を書く。仕様書レビューを繰り返して完璧にして、ソースコードを作る。”
一見正しく見えるが、多くの開発経験者はそれでもうまく行かない事は経験済みだろう。
そして仕様書レビューが不十分だとして、無駄なレビューを繰り返す。
そして設計が悪いとか、オブジェクト指向がいいとか、SEが馬鹿だとかの話になる。
しかし最初の定義を変えたとする。
「設計書＝ソースコード」「完成品＝実行コード」としよう。
”ソースコードを書き、試作品を作る。試験を繰り返し完成品となる。”
この方法では失敗しない。まあ、問題がなくなるまで試験するのだから、当然と言えば当然だ。
つまり、要求仕様書をもらったら、即コーディングを始める。
外部インターフェース仕様書は作らずにソースコード（スタブまたは使用箇所の抜粋）を渡す。
DB仕様書も作らずにSQL文を渡す。プログラマ同士のやり取りはソースコードのみ。
どうしても客に見せる必要のある書類のみソースコード作った後に作る。
早急にテストを繰り返して完成品とする。
これが正しい開発方法であろう。
649 ：仕様書無しさん：2007/01/19(金) 10:24:25
まあ、その程度の規模しかやってないならそれでいいんじゃないの？
５人以内、半年以内ならまあ出来そうだけど。
あと、他システムとのI/Fが無いとか。
５人以内、半年以内ならまあ出来そうだけど。
あと、他システムとのI/Fが無いとか。
651 ：おじゃばさま：2007/01/19(金) 19:34:03
何で無理？
Javaのパッケージや、C++のネームスペースが適切に使われていれば出来るよ。でかくても関係ない。
出来ない原因は、これをやるとお年寄りのSEが怒るからだろう？
「バグが出ないように仕様書を作れ」だの「誰でもコーディング出来るように設計しろ」とか言うよな。
でも仕方ない。そういう人は多いし、人を選べない場合も多いからな。
だから内部ではこれで進めて、外部向けにはソースから仕様書おこして、表面上合わせればいい。
この手法は実は新しい物ではない。
驚くべき事に1992年にこれと同じ事を言った記事がある。
ttp://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
一般に言われる「プロトタイプ法」「スパイラル法」「エクストリーミングプログラミング（XP）」
「アジャイル」なども、実はこの方式をお年寄りに認めさせるための方便であり、目的は同じだ。
またこれは構造化設計やオブジェクト指向など、ソフトウェア工学から出て来た話で、
決して小規模開発だけに限定した物ではない。
ソフトウェア工学というのは、品質のいいソフトをどれだけ効率よく開発するかと言う物である。
Javaのパッケージや、C++のネームスペースが適切に使われていれば出来るよ。でかくても関係ない。
出来ない原因は、これをやるとお年寄りのSEが怒るからだろう？
「バグが出ないように仕様書を作れ」だの「誰でもコーディング出来るように設計しろ」とか言うよな。
でも仕方ない。そういう人は多いし、人を選べない場合も多いからな。
だから内部ではこれで進めて、外部向けにはソースから仕様書おこして、表面上合わせればいい。
この手法は実は新しい物ではない。
驚くべき事に1992年にこれと同じ事を言った記事がある。
ttp://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
一般に言われる「プロトタイプ法」「スパイラル法」「エクストリーミングプログラミング（XP）」
「アジャイル」なども、実はこの方式をお年寄りに認めさせるための方便であり、目的は同じだ。
またこれは構造化設計やオブジェクト指向など、ソフトウェア工学から出て来た話で、
決して小規模開発だけに限定した物ではない。
ソフトウェア工学というのは、品質のいいソフトをどれだけ効率よく開発するかと言う物である。
>>651
で、経緯はわかったけどそれがいい方法だってどうやって証明したの？
２～３資料だしただけじゃロボトミーといっしょ。嘘かもしれない。
いや、１００００の資料をもってきても信用できないな。
どういう理屈でそれがいい方法なのか？
って人を納得させる何かをいつも説明できない。
それが問題だ。
○○大学の権威が・・・ってのはもう長年使われて来過ぎてもう誰も信じない。
オオカミ少年もいいとこだろ？
○○会社の～プロジェクトっていったって今度は有名過ぎて金注ぎ込み過ぎ。
そんだけ予算ありゃどうやったってうまくいくっつの？
だから例を出したら駄目なんだちゃんとどういう理屈でうまくいくのか？
これが説明できない。限りもう誰も説得なんてできる時代じゃないんだ。
で、経緯はわかったけどそれがいい方法だってどうやって証明したの？
２～３資料だしただけじゃロボトミーといっしょ。嘘かもしれない。
いや、１００００の資料をもってきても信用できないな。
どういう理屈でそれがいい方法なのか？
って人を納得させる何かをいつも説明できない。
それが問題だ。
○○大学の権威が・・・ってのはもう長年使われて来過ぎてもう誰も信じない。
オオカミ少年もいいとこだろ？
○○会社の～プロジェクトっていったって今度は有名過ぎて金注ぎ込み過ぎ。
そんだけ予算ありゃどうやったってうまくいくっつの？
だから例を出したら駄目なんだちゃんとどういう理屈でうまくいくのか？
これが説明できない。限りもう誰も説得なんてできる時代じゃないんだ。
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
ってな感じになるわけだけど、これってオブジェクト指向って言えるかな？
これってさ、オブジェクトっぽいものが連携して処理を行ってるけど
実際にはトップダウンで処理を分解してってるだけでオブジェクト指向じゃないと思うんだが、
どう思う？
あるところにDBとのやり取りを仲介してくれるDBManagerってクラスがあったとする。
で、他コンポーネントからもらったデータをAdapterで受け取って
Controllerってクラスがデータに応じた処理をやってDBManagerに渡してDBを更新するって設計があったとしよう。
シーケンスとしては
アクター → Adapter → Controller → DBManager
ってな感じになるわけだけど、これってオブジェクト指向って言えるかな？
これってさ、オブジェクトっぽいものが連携して処理を行ってるけど
実際にはトップダウンで処理を分解してってるだけでオブジェクト指向じゃないと思うんだが、
どう思う？
>>655
まず、実際の業務がわかんなきゃ話になんねー。
まず、実際の業務がわかんなきゃ話になんねー。
657 ：仕様書無しさん：2007/01/19(金) 20:50:38
>>655
＞アクター → Adapter → Controller → DBManager
の流れは、おっしゃるとおり別にオブジェクト指向だけで使われているわけでないね。
DBManagerの中に、インターフェースが使われていて、DBがOracleでもSQLSeverでも
その他いろいろなDBに対してもDBManagerを変更せずにそのDB用のクラスさえ追加すれば
いい様に作られているのがオブジェクト指向だね。
＞アクター → Adapter → Controller → DBManager
の流れは、おっしゃるとおり別にオブジェクト指向だけで使われているわけでないね。
DBManagerの中に、インターフェースが使われていて、DBがOracleでもSQLSeverでも
その他いろいろなDBに対してもDBManagerを変更せずにそのDB用のクラスさえ追加すれば
いい様に作られているのがオブジェクト指向だね。
>>655
アプローチがすでにオブジェクト指向じゃないね。
アプローチがすでにオブジェクト指向じゃないね。
660 ：仕様書無しさん：2007/01/19(金) 20:55:48
>>660
ＳＱＬで何かをする箇所が一番時間かかるところじゃねーの？
メインって別になんもねーじゃん。
あんま、メイン側と完全に分離してる意味ないと思うんだけど？
別にメインの方ってそんな大変じゃねーし。
ＳＱＬで何かをする箇所が一番時間かかるところじゃねーの？
メインって別になんもねーじゃん。
あんま、メイン側と完全に分離してる意味ないと思うんだけど？
別にメインの方ってそんな大変じゃねーし。
あ、なんもねーってより、
１画面あたり期間いくらいくらでどうくんでもだれが組んでも
概ね予想を大きく外れることなく終わるって意味な。
１画面あたり期間いくらいくらでどうくんでもだれが組んでも
概ね予想を大きく外れることなく終わるって意味な。
だから、すぐに枝葉の実装に逃げて、このスレをスレタイを読めないのが長文を書く。
RDBがあるかぎり、ORまっぷしようがそこがネックになる。
メモリー上に常にオブジェクトが活性化した状態で生息できるDBがあればいいんだけどね。
それでいて検索も俺が思ったとおりに出来て、すっぱやくて。
メモリー上に常にオブジェクトが活性化した状態で生息できるDBがあればいいんだけどね。
それでいて検索も俺が思ったとおりに出来て、すっぱやくて。
ＤＢってＳＱＬのところでオブジェクト指向が生きてこない気がすんだよな。
複数のＤＢ使うとどうしてもＣ言語的っていうかなんていうか。
でもＤＢごとわけるよりは同じ意味（用途？）のＳＱＬを並べておきたいしな。
複数のＤＢ使うとどうしてもＣ言語的っていうかなんていうか。
でもＤＢごとわけるよりは同じ意味（用途？）のＳＱＬを並べておきたいしな。
つORM
>>655
それぞれのクラスに「役割」が与えられた設計が成されていれば、広義のオブジェクト指向
と言えるとは思う。
ただこの場合の「本質」は何かと言えば、データを取り出したり変更したりすることだ。
そう考えると、ControllerとかDBManagerなんてのは取って付けたようなもの。
理想は>>665が言うようなことだが、やっぱ理想に過ぎないんだよな。
オレが何度もこのスレでRDBとOOが相性悪いと書いているのは、まさにこのこと。
さらに加えてデータの継承関係が不可能なこと。
それぞれのクラスに「役割」が与えられた設計が成されていれば、広義のオブジェクト指向
と言えるとは思う。
ただこの場合の「本質」は何かと言えば、データを取り出したり変更したりすることだ。
そう考えると、ControllerとかDBManagerなんてのは取って付けたようなもの。
理想は>>665が言うようなことだが、やっぱ理想に過ぎないんだよな。
オレが何度もこのスレでRDBとOOが相性悪いと書いているのは、まさにこのこと。
さらに加えてデータの継承関係が不可能なこと。
DB部分なんて、オブジェクト指向だと自動生成のパーツじゃねーの？
>>665
それが必要なら、そーゆーオブジェクト作れよ・・。
それが必要なら、そーゆーオブジェクト作れよ・・。
>>671
それで出来る程度の単純なデータ構造だったらね。
ORマップツールの適用できる程度のシステムなんてたいしたシステムじゃないし。
データ構造が単純じゃないと駄目。
>>655
オブジェクト基地外。ｗ
ODBって10年前からあるけど、流行らないし成功しないんだよ。
XMLデータベースもマイナー。
それで出来る程度の単純なデータ構造だったらね。
ORマップツールの適用できる程度のシステムなんてたいしたシステムじゃないし。
データ構造が単純じゃないと駄目。
>>655
オブジェクト基地外。ｗ
ODBって10年前からあるけど、流行らないし成功しないんだよ。
XMLデータベースもマイナー。
トップダウンになるのはソフトウェアをやっている以上しかたないよ。
統治分割が基本なので処理の流れを追いかけていくと、上層から複数の下層が
呼ばれる木構造になっているのが普通。そうしないと滅茶苦茶ファットな
クラスや関数ができてしまう。
もともとオブジェクト指向は構造化プログラミングの上に成り立っている
ので、構造化プログラミングを完全に排除するのは、根本的なところで間違ってる。
そもそも、オブジェクト指向開発でもレイヤ別けする開発はポピュラーでしょ。
統治分割が基本なので処理の流れを追いかけていくと、上層から複数の下層が
呼ばれる木構造になっているのが普通。そうしないと滅茶苦茶ファットな
クラスや関数ができてしまう。
もともとオブジェクト指向は構造化プログラミングの上に成り立っている
ので、構造化プログラミングを完全に排除するのは、根本的なところで間違ってる。
そもそも、オブジェクト指向開発でもレイヤ別けする開発はポピュラーでしょ。
自律オブジェクト指向ってのもあるけどな
676 ：仕様書無しさん：2007/01/19(金) 22:50:38
完璧なプログラムを最初から目指そうとするのは、いいことだけど現実無理。
色々な書き方があるかな。
時間の問題もあるしな。
色々な書き方があるかな。
時間の問題もあるしな。
677 ：仕様書無しさん：2007/01/19(金) 22:57:55
オブジェクト設計が流行らないのは、教育体制が悪いからだと思う。
最近の市販本は昔のものに比べてずいぶんよくなったが、現場で使える気にさせるような書き方じゃない。
研修の講師の人も、わからせる気がないんじゃないか？とか、
ほんとうにわかってるのか？という感じがする。
最近の市販本は昔のものに比べてずいぶんよくなったが、現場で使える気にさせるような書き方じゃない。
研修の講師の人も、わからせる気がないんじゃないか？とか、
ほんとうにわかってるのか？という感じがする。
678 ：仕様書無しさん：2007/01/19(金) 23:27:20
今度、わかりやすい本を書いて雑誌みたいな安い紙を使って300円くらいで出版してみようかと思うが・・・・。
そもそもオブジェクト指向設計って、従来の構造化設計に比べて何か強力なメリットは
あるのだろうか？ それこそ経営層が喜びそうなやつ。
例えば
・生産性が上がる
・品質が良くなる
・保守性が高くなる
・納期が短くなる
多少という程度でなく劇的なインパクトが無い限り、新しい手法への移行など
進まないような気がする。
それこそがスレタイの答えになるのではないか？
あるのだろうか？ それこそ経営層が喜びそうなやつ。
例えば
・生産性が上がる
・品質が良くなる
・保守性が高くなる
・納期が短くなる
多少という程度でなく劇的なインパクトが無い限り、新しい手法への移行など
進まないような気がする。
それこそがスレタイの答えになるのではないか？
OOP言語の方が非OOPの物より流行ってる以上
OOが流行ってないなど言うの寝言だな
OOが流行ってないなど言うの寝言だな
＞工夫のしがいがあるのでオブジェクト指向のほうが
＞構造化設計より断然楽しい！
＞そういう意味では関数型でもいいんだけど、
言ってることが支離滅裂すぎて理解不能です＞＜
＞構造化設計より断然楽しい！
＞そういう意味では関数型でもいいんだけど、
言ってることが支離滅裂すぎて理解不能です＞＜
683 ：仕様書無しさん：2007/01/19(金) 23:50:45
デザインパターンの本に付いているCDのサンプルはいい教材です。
拡張性とかは、すぐに実感できました。
ただし、内容が幼稚すぎるのでもう少し業務よりのサンプルをお願いします。
拡張性とかは、すぐに実感できました。
ただし、内容が幼稚すぎるのでもう少し業務よりのサンプルをお願いします。
>>681
楽しいじゃなくて、お金になるかどうかが問題なんだぞ。
楽しいじゃなくて、お金になるかどうかが問題なんだぞ。
>>655の設計って受け渡すデータそのものにメソッドを持たせるんじゃないの？
データクラスを設計するとこんな感じでさ。
public class Data extends DbManager
{
private Controller controller ;
// DataBaseを更新する
public void Update() {...};
public void SetData( int) {...};
public int GetData() {...};
}
データクラスを設計するとこんな感じでさ。
public class Data extends DbManager
{
private Controller controller ;
// DataBaseを更新する
public void Update() {...};
public void SetData( int) {...};
public int GetData() {...};
}
このスレにいる人間は本当にプログラマなのか！！
687 ：仕様書無しさん：2007/01/20(土) 00:10:57
OOがわかってない人たちで盛り上がっているね。
ヒントを言うと自転車の乗り方や泳ぎ方みたいなもんだよ。
でも、わかってしまうと話したくなくなるんだよ。
えらい遠回りをして辿り着いたのにタダでましてや2chで教えるわけないな。
ヒントを言うと自転車の乗り方や泳ぎ方みたいなもんだよ。
でも、わかってしまうと話したくなくなるんだよ。
えらい遠回りをして辿り着いたのにタダでましてや2chで教えるわけないな。
>>685
そんなくだらない解説しなきゃわからないような設計ならどの道駄目だろ。
そんなくだらない解説しなきゃわからないような設計ならどの道駄目だろ。
>>688
いや、残業代が増えるとかちっとも笑えないトンチではもうにこりともできなくなった。
いや、残業代が増えるとかちっとも笑えないトンチではもうにこりともできなくなった。
>687
他人を見下すオブジェクト厨の典型ｗ
「わかっているのは自分だけｗ」
オブジェクト厨のお仲間は何故かみんな同じように思っているよ。
なんでこういう人って勘違いしているんだろう。
他人を見下すオブジェクト厨の典型ｗ
「わかっているのは自分だけｗ」
オブジェクト厨のお仲間は何故かみんな同じように思っているよ。
なんでこういう人って勘違いしているんだろう。
692 ：仕様書無しさん：2007/01/20(土) 00:17:10
おまえもなー
694 ：仕様書無しさん：2007/01/20(土) 00:18:17
力関係が弱いだけ
どちらにせよ、OOとは関係ない
組込み系なんてOOじゃないけど、悲惨なもんだぞ
組込み系なんてOOじゃないけど、悲惨なもんだぞ
不定期なイベントを受け取って内部の状態を変化させていくモデルが表現し易いってのは、
SimulaやSmalltalkが生まれた経緯からして当然と言えば当然かな。
SimulaやSmalltalkが生まれた経緯からして当然と言えば当然かな。
いくら有益でも、凡人に理解できない技術は発展しない。
凡人に理解できないと、人が集まらない。
人が集まらないと、仕事にならない。
凡人に理解できないと、人が集まらない。
人が集まらないと、仕事にならない。
このスレが流行ってる理由はなんすか？
マ板で伸びすぎｗ
マ板で伸びすぎｗ
699 ：仕様書無しさん：2007/01/20(土) 02:40:03
なぜオブジェクト指向でなければいけないのか？
これに答えられる奴だけがオブジェクト指向を理解している
これに答えられる奴だけがオブジェクト指向を理解している
700 ：仕様書無しさん：2007/01/20(土) 02:43:06
ｵﾌﾞｼﾞｪｸﾄ指向の中身云々より、技術者としてそれを知っておくことが重要だと思うんだ
>699-700
とりあえず税金払え
とりあえず税金払え
なぜ流行らないかというと、勉強するための本がないからです。
OOはメモリの無駄遣いだからです。
どうせ全体を理解できない・しようともしない、くせに
オブジェクト設計でエレガントなんて無理無理。
おまえらの仕様書は、完璧なオブジェクト設計の
結果が書かれているのかい？
仕様書に書かれてなければ、ただの突貫工事とかわらんぞ。
どうせ全体を理解できない・しようともしない、くせに
オブジェクト設計でエレガントなんて無理無理。
おまえらの仕様書は、完璧なオブジェクト設計の
結果が書かれているのかい？
仕様書に書かれてなければ、ただの突貫工事とかわらんぞ。
べつに完全である必要性は何処にも無いのですが。
OOなんて爺にはともかく、若者にはOOの方がわかりやすい
から、流行ってるにすぎません。
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
ものじゃないものはオブジェクト指向では扱えないんだな
原理主義だと
原理主義だと
仕事が無いからって妬んでるんじゃねぇよニート
だから、オブジェクト”設計”のすれです。
実装のミクロの枝葉の自分知識自慢はドッカイッテください。
実装のミクロの枝葉の自分知識自慢はドッカイッテください。
710 ：仕様書無しさん：2007/01/20(土) 09:31:37
>>709さんに100万票投入！！
実装できもしない設計など紙くず同然だ。
腐女子の妄想同人小説と同レベルのリアリティしかない。
腐女子の妄想同人小説と同レベルのリアリティしかない。
712 ：仕様書無しさん：2007/01/20(土) 09:33:54
プログラマー版じゃなく、情シス版に立てればよかったかもね。
713 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/20(土) 10:14:24
結論
オブジェクト指向設計が流行らないのは実装を無視した関東軍の暴走みたいなものだから
ーーーーーーーーーーーーー 糸冬 了 －－－－－－－－－－－－－－－－－
オブジェクト指向設計が流行らないのは実装を無視した関東軍の暴走みたいなものだから
ーーーーーーーーーーーーー 糸冬 了 －－－－－－－－－－－－－－－－－
しかし、実装は、OOP言語でやるので
実装に向いた設計をするとOODになるのは自明
実装に向いた設計をするとOODになるのは自明
設計は実装に依存するってわけだが。
本当にそれでいいのか？設計を実装する方法を模索するべきだよな
本当にそれでいいのか？設計を実装する方法を模索するべきだよな
RDBを使って数億オーダーを超えるレコードを処理するシステムでは、
再利用性よりも保守性を重視したOODにならざるをえない。
それでも、ソース中のいたる所にSQL文を書き散らかされて、混乱する
ことだけは回避できる。それだけで十分。
再利用性よりも保守性を重視したOODにならざるをえない。
それでも、ソース中のいたる所にSQL文を書き散らかされて、混乱する
ことだけは回避できる。それだけで十分。
720 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/20(土) 12:31:25
絶対正義のオブジェクト指向の剣をかざす正義の戦士が悪のコボラーを退治しているつもりだろうが
傍から見るとオブジェクト指向って書かれた包丁を振り回して街行く人を無差別に襲ってるだけなんだな。
傍から見るとオブジェクト指向って書かれた包丁を振り回して街行く人を無差別に襲ってるだけなんだな。
どうでもいいがその気持ち悪いコテ外せ
話はそれからにしよう
話はそれからにしよう
722 ：仕様書無しさん：2007/01/20(土) 12:43:42
>>718 技術者も人間だから。
凡人になれる職種でないならば、
数を減らして高給にすればいいじゃん。
実際、高度な技術でないと遂行不可能なレベルの仕事は
超高給の能力主義ってのも無くは無い。
安い給料で半端なのを雇っても、
そちらの方がコスト安であれば、そうなるのが資本主義。
凡人になれる職種でないならば、
数を減らして高給にすればいいじゃん。
実際、高度な技術でないと遂行不可能なレベルの仕事は
超高給の能力主義ってのも無くは無い。
安い給料で半端なのを雇っても、
そちらの方がコスト安であれば、そうなるのが資本主義。
723 ：仕様書無しさん：2007/01/20(土) 12:55:41
ハードウェアの設計はろくに勉強もしなかった奴には出来ないが、
ソフトウェアの設計は高卒でもできるって思われてるね。
ソフトウェアの設計は高卒でもできるって思われてるね。
>>723 別に回路設計だって、知ってるかどうかであって、
毎回0からスクラッチするようなプロの現場なんて、あまりないし
実際、そんんあ仕事はチームでやるから問題なし。
ソフトの場合は、大体雇い主が無能すぎる。
アニメーターの方がまだマシだわな。
毎回0からスクラッチするようなプロの現場なんて、あまりないし
実際、そんんあ仕事はチームでやるから問題なし。
ソフトの場合は、大体雇い主が無能すぎる。
アニメーターの方がまだマシだわな。
725 ：おじゃばさま：2007/01/20(土) 15:12:16
>652
それは俺の実績によって証明した。
あるプロジェクトで俺のチームと他の会社のチームの2つで開発した。
規模的に言えば両方とも10人6カ月ぐらいの規模だ。
相手チームは典型的な「ドキュメント重視型」。
俺のチームはスケジュール通りに完了。他のチームは納期にはコーディングが完了。
そりゃそうだ、6カ月のうち5カ月のは仕様書作り直してたのだから。
結合試験でもまともに動かずに結局納品まで6カ月遅延した。
次のは結構大きなプロジェクト。100人規模で10カぐらいのやつだ。
俺のチームは10人ぐらいで、サブシステムの1つをやることになった。
これもドキュメント重視。ただし俺のチームだけは例外的に俺のやり方を認められた。
簡単に言うと喧嘩してそこまで言うならやってみろって事になった。
俺のチームだけスケジュール通り。システム結合試験に間に合ったのは、俺のチームだけ。
次のチームが結合試験に入るまで1カ月の待たされた。
結局全チームが結合試験に入れたのは3カ月後だった。
暇な時間はドキュメント整理に使ったため、ドキュメントの完成度も高かった。
それは俺の実績によって証明した。
あるプロジェクトで俺のチームと他の会社のチームの2つで開発した。
規模的に言えば両方とも10人6カ月ぐらいの規模だ。
相手チームは典型的な「ドキュメント重視型」。
俺のチームはスケジュール通りに完了。他のチームは納期にはコーディングが完了。
そりゃそうだ、6カ月のうち5カ月のは仕様書作り直してたのだから。
結合試験でもまともに動かずに結局納品まで6カ月遅延した。
次のは結構大きなプロジェクト。100人規模で10カぐらいのやつだ。
俺のチームは10人ぐらいで、サブシステムの1つをやることになった。
これもドキュメント重視。ただし俺のチームだけは例外的に俺のやり方を認められた。
簡単に言うと喧嘩してそこまで言うならやってみろって事になった。
俺のチームだけスケジュール通り。システム結合試験に間に合ったのは、俺のチームだけ。
次のチームが結合試験に入るまで1カ月の待たされた。
結局全チームが結合試験に入れたのは3カ月後だった。
暇な時間はドキュメント整理に使ったため、ドキュメントの完成度も高かった。
可哀想にとうとう妄想まで・・・
所詮アホコテだし。
コード書いて実際に動かしてみなかったらモデルがちゃんと動くかどうかどうやって確認するの？
アーキテクチャ検証だって、コード書かなきゃ出来ないと思うし。
だから分析・設計のフェーズは↓の流れになる。
実装→レビュー→実装→レビュー・・・→ドキュメント化
実装フェーズなんて、アセンブルしてデバッグするだけで稼動を使い切ってしまうし。
アーキテクチャ検証だって、コード書かなきゃ出来ないと思うし。
だから分析・設計のフェーズは↓の流れになる。
実装→レビュー→実装→レビュー・・・→ドキュメント化
実装フェーズなんて、アセンブルしてデバッグするだけで稼動を使い切ってしまうし。
>>728
>コード書いて実際に動かしてみなかったらモデルがちゃんと動くかどうかどうやって確認するの？
全くだな。
紙面上でだけ矛盾がないことを確認するわするけど所詮人の目だな。
それで毎回戻りが派生してるしね。
流れぐらいは設計なんて無駄なことしてる間に組んじゃったほうが速い気がするけどなぁ。
そこからの細部のバグをとるのは結構時間食うけど、表面的に仕組みに矛盾がないことを確認する程度の
実装だったら組んじゃったほうが早いよなぁ・・・。
ＧＵＩアプリだったらフォーカスアウト時のチェックだの、画面遷移時の細かい動作だの気にしなきゃ組むのだけなら半月かからんこと多いしね。
>コード書いて実際に動かしてみなかったらモデルがちゃんと動くかどうかどうやって確認するの？
全くだな。
紙面上でだけ矛盾がないことを確認するわするけど所詮人の目だな。
それで毎回戻りが派生してるしね。
流れぐらいは設計なんて無駄なことしてる間に組んじゃったほうが速い気がするけどなぁ。
そこからの細部のバグをとるのは結構時間食うけど、表面的に仕組みに矛盾がないことを確認する程度の
実装だったら組んじゃったほうが早いよなぁ・・・。
ＧＵＩアプリだったらフォーカスアウト時のチェックだの、画面遷移時の細かい動作だの気にしなきゃ組むのだけなら半月かからんこと多いしね。
ところでオブジェクト指向設計ってさ、抽象クラスを抽出して実装と抽象を分離するよな。
大規模開発でアプリケーション層の実装クラス群に依存するのってオブジェクト指向設計としてはダメだよな。
アプリケーション層を入れ替えるなんて不可能なんだが。
大規模開発でアプリケーション層の実装クラス群に依存するのってオブジェクト指向設計としてはダメだよな。
アプリケーション層を入れ替えるなんて不可能なんだが。
つーか任されたシステムが一番簡単だったとか
重要度が低かっただけだったとか色んなオチが考えられる以上
その程度の実績もどきで何を評価して欲しいのかわからん
これがウワサの糞コテクオリティ？
重要度が低かっただけだったとか色んなオチが考えられる以上
その程度の実績もどきで何を評価して欲しいのかわからん
これがウワサの糞コテクオリティ？
733 ：仕様書無しさん：2007/01/20(土) 15:37:24
そうそいつこそうわさの糞コテクオリティ
>>651
２点、聞きたいことがある
1.
>だから内部ではこれで進めて、外部向けにはソースから仕様書おこして、表面上合わせればいい。
それはその通り。なのに >>651 は、なぜそう出来ずに「喧嘩」になったのか？
2.
>>651 の手法が本当に上手くいったのならば、その現場（または会社）は
今後も >>651 の手法を真似ようとするはず。
で、実際にそうなったの？
ならなかったのならば、結局のところ、単に >>651 の扱いが上手かった
>> 651 の "上司（または客先）が優秀" だっただけじゃないの？
いわゆる「馬鹿と鋏は使いよう」って奴でさ・・・
２点、聞きたいことがある
1.
>だから内部ではこれで進めて、外部向けにはソースから仕様書おこして、表面上合わせればいい。
それはその通り。なのに >>651 は、なぜそう出来ずに「喧嘩」になったのか？
2.
>>651 の手法が本当に上手くいったのならば、その現場（または会社）は
今後も >>651 の手法を真似ようとするはず。
で、実際にそうなったの？
ならなかったのならば、結局のところ、単に >>651 の扱いが上手かった
>> 651 の "上司（または客先）が優秀" だっただけじゃないの？
いわゆる「馬鹿と鋏は使いよう」って奴でさ・・・
735 ：仕様書無しさん：2007/01/20(土) 15:39:34
>>728は素人だな
確かにテスト用な簡易検証コードは書くが、仕様実装レベルのものは書かない
低スキルな奴にそれを求めても無駄だからだ。スキルが無い奴ほど
>>728のサイクルをやりたがる。それをコントロールするのが俺様だ。
反面できる奴は簡易検証コードで報告してくる。こういう奴には任せても安心だ。
以上、経験から。
確かにテスト用な簡易検証コードは書くが、仕様実装レベルのものは書かない
低スキルな奴にそれを求めても無駄だからだ。スキルが無い奴ほど
>>728のサイクルをやりたがる。それをコントロールするのが俺様だ。
反面できる奴は簡易検証コードで報告してくる。こういう奴には任せても安心だ。
以上、経験から。
OOのおかげでDBのテーブルがすっきり木構造になってきたのが素晴らしい。
やっぱりデータの関係は１：Nだよな。
やっぱりデータの関係は１：Nだよな。
あ、もう１つあったな。。。ゴメン。
3.
>規模的に言えば両方とも10人6カ月ぐらいの規模だ。
その数字の根拠は何？
3.
>規模的に言えば両方とも10人6カ月ぐらいの規模だ。
その数字の根拠は何？
739 ：仕様書無しさん：2007/01/20(土) 15:42:04
どっちにしてもオブジェクト指向で騒ぐ馬鹿共に優秀な技術者はいない
名物にうまいもの無しのようなものだ
名物にうまいもの無しのようなものだ
740 ：おじゃばさま：2007/01/20(土) 15:42:48
直接ソース方式を使えなくて失敗した例もある。
俺の上にドキュメント重視の上司がついた時だ。
作業内容を厳しく監視されたため、コーディングが出来なかった。コーディングすると怒られた。
まあ、試しにドキュメント重視でやってみるかとやってみたのが運の尽きだ。
一日の半分以上がドキュメントレビュー、残った時間がレビュー結果反映。
レビュー出席者に処理を説明するのに大半の時間を取られ、本当に決めたい所ではだれもついてこれずに
無言が続く。出席者の不意の疑問発言で中断することもしばしばあった。
ドキュメントの印刷と資料作成で土日がつぶれ、プリンタのトナーは切れて、コピー機が悲鳴を上げる。
誤印刷の廃棄でシュレッターが壊れ、新人が集められ人力シュレッターが行われた。
開発機関の80%が機能仕様書と詳細設計書の作成と再レビューに使われて、開発期間は削られた。
完璧な仕様書があればコーディングは簡単でバグがないとの意見から、
コーディング過程でプログラマ大量導入。期間の関係から単体試験は見送られた。
結合試験中に設計的な問題が大量発生。予算が尽き始めてプログラマ大量に外された。
ソースは勝手に修正され、ドキュメントとの相違は無視され出した。
残ったのは不完全な大量の仕様書と、だれが作ったかもう分からないソース。
度重なる納期延長で上の連中が次々に交代。結合試験後期には、予算は尽きて必要な人員まで外された。
結局俺の上司も外され自由に出来るようになったので、2カ月で作り直した。
まあ、俺がやってもドキュメント重視で方式では失敗するって事だな。
俺の上にドキュメント重視の上司がついた時だ。
作業内容を厳しく監視されたため、コーディングが出来なかった。コーディングすると怒られた。
まあ、試しにドキュメント重視でやってみるかとやってみたのが運の尽きだ。
一日の半分以上がドキュメントレビュー、残った時間がレビュー結果反映。
レビュー出席者に処理を説明するのに大半の時間を取られ、本当に決めたい所ではだれもついてこれずに
無言が続く。出席者の不意の疑問発言で中断することもしばしばあった。
ドキュメントの印刷と資料作成で土日がつぶれ、プリンタのトナーは切れて、コピー機が悲鳴を上げる。
誤印刷の廃棄でシュレッターが壊れ、新人が集められ人力シュレッターが行われた。
開発機関の80%が機能仕様書と詳細設計書の作成と再レビューに使われて、開発期間は削られた。
完璧な仕様書があればコーディングは簡単でバグがないとの意見から、
コーディング過程でプログラマ大量導入。期間の関係から単体試験は見送られた。
結合試験中に設計的な問題が大量発生。予算が尽き始めてプログラマ大量に外された。
ソースは勝手に修正され、ドキュメントとの相違は無視され出した。
残ったのは不完全な大量の仕様書と、だれが作ったかもう分からないソース。
度重なる納期延長で上の連中が次々に交代。結合試験後期には、予算は尽きて必要な人員まで外された。
結局俺の上司も外され自由に出来るようになったので、2カ月で作り直した。
まあ、俺がやってもドキュメント重視で方式では失敗するって事だな。
741 ：仕様書無しさん：2007/01/20(土) 15:42:59
>>735
↑こいつなにいってんのかさっぱりわからないの俺だけ？
↑こいつなにいってんのかさっぱりわからないの俺だけ？
>>740
おい、もう、内容全然関係なくなってるからｗ
おい、もう、内容全然関係なくなってるからｗ
なぁ誇張表現は許してやるが
妄想はほどほどにしような？
妄想はほどほどにしような？
744 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/20(土) 15:48:04
俺はハード設計もやってたから比較できるのでわかるけど
現代の工学一般では設計とは動作検証までを含むのが普通。
ところがソフトウエア工学だけ、動作検証を行ってない、「お絵かきの絵」を設計と称して下に下ろしてくる。
これがほとんどすべての問題点の原点だろう。
コーディングと動作検証までを設計に含めればすべて解決する。
コーディングを設計に含めない 現在のゆがんだソフトウエアの文化を改めるべきだな。
現代の工学一般では設計とは動作検証までを含むのが普通。
ところがソフトウエア工学だけ、動作検証を行ってない、「お絵かきの絵」を設計と称して下に下ろしてくる。
これがほとんどすべての問題点の原点だろう。
コーディングと動作検証までを設計に含めればすべて解決する。
コーディングを設計に含めない 現在のゆがんだソフトウエアの文化を改めるべきだな。
>>744
意外とまともな意見だな
意外とまともな意見だな
これがウワサのアホコテ連鎖？
死に絶えろアホコテ共
死に絶えろアホコテ共
お前がやってるのは仕事じゃねぇ、お絵かきだ
解消してない問題点洗い出して、そう言ってやれば誰でも改善するよ
解消してない問題点洗い出して、そう言ってやれば誰でも改善するよ
>>749-750
の話をしてるときにすでに期限が決まってたらどう動きようもないな。
ここでまだ期限が決まってないならなんでも言えるけど
期限が決まってたら馬鹿にまかせるよりこっちで引き受けて、
後にわかった不具合を細かいところまで全部書き止めておいて後で仕様変更の分だけ請求したほうがいい。
その後、その会社といい関係を続けたいならその資料はお蔵入り、
金の切れ目が縁の切れ目であるなら、かかった費用を全部請求して払ってもらう。
の話をしてるときにすでに期限が決まってたらどう動きようもないな。
ここでまだ期限が決まってないならなんでも言えるけど
期限が決まってたら馬鹿にまかせるよりこっちで引き受けて、
後にわかった不具合を細かいところまで全部書き止めておいて後で仕様変更の分だけ請求したほうがいい。
その後、その会社といい関係を続けたいならその資料はお蔵入り、
金の切れ目が縁の切れ目であるなら、かかった費用を全部請求して払ってもらう。
>748
＞コテの意味ねぇのにコテにするのがアフォ
いわゆるここにいるのは全部アフォコテってことですね
＞コテの意味ねぇのにコテにするのがアフォ
いわゆるここにいるのは全部アフォコテってことですね
753 ：おじゃばさま：2007/01/20(土) 17:05:10
分かってもらえた人も結構多いので安心している。
つまり電球などの通り、「コーディング→テスト→再設計」を含めて設計とする事が正しいと言うことだ。
前置きが長くなったが、設計とコーディング／テストを分けて考える時点で根本的な問題があると言える。
そしていよいよ「オブジェクト指向設計は何故流行らないのか」と言う問題になる。
つまり電球などの通り、「コーディング→テスト→再設計」を含めて設計とする事が正しいと言うことだ。
前置きが長くなったが、設計とコーディング／テストを分けて考える時点で根本的な問題があると言える。
そしていよいよ「オブジェクト指向設計は何故流行らないのか」と言う問題になる。
検証のためのコーディングはするが、設計を飛び越えた実装なんてしないだろ
糞コテがまともだったコテの意見をぱくってる…
756 ：おじゃばさま：2007/01/20(土) 17:41:49
設計と実装を分ける事に問題がある。実装も設計の一部なのだ。
754も「できない」とは言わずに「しない」と言っている所を見ると、
出来るということは分かっているのだろう。
まず設計の本質を理解するためには、設計と実装を分けて考えると言う偏見を捨てなければならない。
754も「できない」とは言わずに「しない」と言っている所を見ると、
出来るということは分かっているのだろう。
まず設計の本質を理解するためには、設計と実装を分けて考えると言う偏見を捨てなければならない。
「SEがPGに対して設計できないって馬鹿にしている」
という現状を見る限り、
SEは設計しかできない、PGは設計すらできないという事だろう。
そんなチームにOOPを導入して、いったい何のメリットがあるというのだ？
実装なんて単なる作業だろ？
設計してモデルツールで駆動させてあってればOK。
後はちゃいなでも何でも書かせればいいだけ。
設計してモデルツールで駆動させてあってればOK。
後はちゃいなでも何でも書かせればいいだけ。
それで所定の性能が確保できるなら問題ない。
応答速度も消費メモリもセキュリティも一切考慮せず
数時間おきに再起動することを前提としたり
致命的エラーを偶発的に起こして勝手に終了することを許容するなら
誰も苦労しない。
応答速度も消費メモリもセキュリティも一切考慮せず
数時間おきに再起動することを前提としたり
致命的エラーを偶発的に起こして勝手に終了することを許容するなら
誰も苦労しない。
>>759
> 応答速度も消費メモリもセキュリティも一切考慮せず
これは設計の問題だが。
> 数時間おきに再起動することを前提としたり
> 致命的エラーを偶発的に起こして勝手に終了することを許容するなら
これはコーダーのレベルが低いだけ。
一切設計の問題じゃない。
> 応答速度も消費メモリもセキュリティも一切考慮せず
これは設計の問題だが。
> 数時間おきに再起動することを前提としたり
> 致命的エラーを偶発的に起こして勝手に終了することを許容するなら
これはコーダーのレベルが低いだけ。
一切設計の問題じゃない。
762 ：仕様書無しさん：2007/01/20(土) 19:27:53
丸投げ、中間搾取の構造が崩れない限り
プログラマに未来は無い。
プログラマに未来は無い。
763 ：仕様書無しさん：2007/01/20(土) 21:05:31
ＳＥが完璧な設計できるなら、
そのままグラフィック設計ツールで、
お絵かきプログラミングすればいいんよ。
具体的に変数型決めたり、タイミングを取ったときに破綻するなら
それはオブジェクト指向設計のどこかで、致命的なミスしてる。
そういうレベルまでＳＥの殆どが達してないから
実装担当から「設計の破綻で苦労するんだから、好きにやらせろ」って話が出る。
つまり、設計者が仕事してない。
おまえらクビね。
そのままグラフィック設計ツールで、
お絵かきプログラミングすればいいんよ。
具体的に変数型決めたり、タイミングを取ったときに破綻するなら
それはオブジェクト指向設計のどこかで、致命的なミスしてる。
そういうレベルまでＳＥの殆どが達してないから
実装担当から「設計の破綻で苦労するんだから、好きにやらせろ」って話が出る。
つまり、設計者が仕事してない。
おまえらクビね。
764 ：仕様書無しさん：2007/01/20(土) 21:13:17
仕様を覚えることができず、ツールの選定もろくにできない
なにやらせてもダメだから、仕様と関係ないレビューを繰り返しなじることにだけ特化する
SEとはそういう触手
なにやらせてもダメだから、仕様と関係ないレビューを繰り返しなじることにだけ特化する
SEとはそういう触手
そもそも得意げで設計（と思わしき物）を出してくる大手様に「全然駄目ですねやり直してください」とか言えないよ。
あいつ等馬鹿なのに自分でやりたがるんだ。
あいつ等馬鹿なのに自分でやりたがるんだ。
元請をよく馬鹿にする人いるけどさ、類は朋を呼ぶって奴だよ。
お前もその程度がお似合いなプログラマなんだよ。
お前もその程度がお似合いなプログラマなんだよ。
設計以下の仕事が流れてくる会社って先生きのこだろう。
きのこる先生は生存する側の人物だで
>>767
まあ、それが弱いところだけどさｗ
ただ、これが原因で結局プロジェクトが赤字になっちゃうなら大手様でもなんでもないね。
ただの貧乏神でしかないさ。
>>768
はっきりいって足元みられるためにある階層だよな。
上はこれで作った気になってんだから救いようがねぇよな。
何年やっても技術が蓄積されないから結局安くならないしコストばかりかかると思うんだけどね。
まあ、それが弱いところだけどさｗ
ただ、これが原因で結局プロジェクトが赤字になっちゃうなら大手様でもなんでもないね。
ただの貧乏神でしかないさ。
>>768
はっきりいって足元みられるためにある階層だよな。
上はこれで作った気になってんだから救いようがねぇよな。
何年やっても技術が蓄積されないから結局安くならないしコストばかりかかると思うんだけどね。
設計した奴に十分なスキルがあるなら、設計者が実装する方が効率いいよな。
モデリング言語で基本設計してプログラミング言語で詳細設計するって感じで。
モデリング言語で基本設計してプログラミング言語で詳細設計するって感じで。
SEなんて職種は日本にしか居ないんじゃねーの。
本来のSEって営業のできるPGのことだと思ってるから特に。
本来のSEって営業のできるPGのことだと思ってるから特に。
んでも、設計者が実装していたらいくら時間あっても足りないよな。
特に一つの製品に100社以上関わるような大規模開発だと。
しかし、大抵できる奴に負荷が集中する。仕事取って来て進捗管理して
メール捌いて設計して実装してテスト手伝っている奴とか知っている。
仕事量に関して80:20の法則が成り立つのは本当に可哀想だ。
特に一つの製品に100社以上関わるような大規模開発だと。
しかし、大抵できる奴に負荷が集中する。仕事取って来て進捗管理して
メール捌いて設計して実装してテスト手伝っている奴とか知っている。
仕事量に関して80:20の法則が成り立つのは本当に可哀想だ。
>>760
実際の開発現場では
最初の設計通りで最後まで済む事はまずない。
釣り師の現場もそうと断言できる。
名称が違うだけで実際は
設計→実装→再設計（修正含）→実装→…
の繰り返しなんだよ。
例えばOSとか。
駄目な設計や実装だと
この繰り返しが難しくなるのが致命的だな。
本題のOOの利点の一つは
この繰り返しのサイクルを短く出来る事だ。
実際の開発現場では
最初の設計通りで最後まで済む事はまずない。
釣り師の現場もそうと断言できる。
名称が違うだけで実際は
設計→実装→再設計（修正含）→実装→…
の繰り返しなんだよ。
例えばOSとか。
駄目な設計や実装だと
この繰り返しが難しくなるのが致命的だな。
本題のOOの利点の一つは
この繰り返しのサイクルを短く出来る事だ。
>775
繰り返しによる開発が実情だ、という話は別にいいけど。
> 本題のOOの利点の一つは
> この繰り返しのサイクルを短く出来る事だ。
なんでOOだとサイクルが短くできるかわからん。
構造化プログラミングや論理型プログラミング、関数型プログラミング
と何が違うの？
繰り返しによる開発が実情だ、という話は別にいいけど。
> 本題のOOの利点の一つは
> この繰り返しのサイクルを短く出来る事だ。
なんでOOだとサイクルが短くできるかわからん。
構造化プログラミングや論理型プログラミング、関数型プログラミング
と何が違うの？
最適化を行う対象を特定しやすい（＝最適化後の汚さをカプセル化できる）ところとか？
>>776
それは自分も聞きたい。OO設計はなぜ開発サイクルが短くなるのか？
それは自分も聞きたい。OO設計はなぜ開発サイクルが短くなるのか？
>>776
ばずわーど。
ばずわーど。
>>776
誤解させてしまったようなので補足
大雑把に説明すると
デバイス層→アプリケーション層の間をレイヤー分割して設計する場合、
クラスやメタプログラム機能が充実してる
OOの方が部品化しやすい分再設計する場合に楽が出来る。
つまり、そういう事がなければ
OOで開発サイクルが短くなる事はない。
誤解させてしまったようなので補足
大雑把に説明すると
デバイス層→アプリケーション層の間をレイヤー分割して設計する場合、
クラスやメタプログラム機能が充実してる
OOの方が部品化しやすい分再設計する場合に楽が出来る。
つまり、そういう事がなければ
OOで開発サイクルが短くなる事はない。
レイヤーとかモジュールとか言ってるけどさ、
俺の知ってる限りじゃ各層とも下位レイヤの実装クラスに依存してるから変更効かないよ。
俺の知ってる限りじゃ各層とも下位レイヤの実装クラスに依存してるから変更効かないよ。
>>781
それが従来のＣ言語での開発じゃできない理由が説明できてないじゃない？
それが従来のＣ言語での開発じゃできない理由が説明できてないじゃない？
一般的だけどレイヤアプローチの設計って案外設計が難しいよな。
(この点は自分のスキルが低いのを認めないといけないけど)
上層が下層に依存してしまうという感覚を持つ人間の方が
マジョリティだと思うけど、本来OOの設計ではDIP(依存関係逆転の法則)
というのがあって、原則に反するらしい。下層が上層に依存する
のが正しいのだそうだ。
オブジェクト指向の原則の中では、他にもLSP(マルコフ置換の法則)
とかもレイヤアプローチでは必要な気がする。
余談だけど大きなアプリケーションを組む場合はレイヤーアプローチは
有力だけど、小さなアプリケーションを組むときは機敏性に欠ける
という意見もあるね。
なんかこのスレを見ていると大規模アプリを開発している人間が
偉い、という印象を受けるけど、実際の現場ではもっと小規模
アプリケーション開発者にもスポットを当てるべきだと思う。
そうしないとソフトウェア開発者全体の大きなパイに属する
人間が救済できない。
(この点は自分のスキルが低いのを認めないといけないけど)
上層が下層に依存してしまうという感覚を持つ人間の方が
マジョリティだと思うけど、本来OOの設計ではDIP(依存関係逆転の法則)
というのがあって、原則に反するらしい。下層が上層に依存する
のが正しいのだそうだ。
オブジェクト指向の原則の中では、他にもLSP(マルコフ置換の法則)
とかもレイヤアプローチでは必要な気がする。
余談だけど大きなアプリケーションを組む場合はレイヤーアプローチは
有力だけど、小さなアプリケーションを組むときは機敏性に欠ける
という意見もあるね。
なんかこのスレを見ていると大規模アプリを開発している人間が
偉い、という印象を受けるけど、実際の現場ではもっと小規模
アプリケーション開発者にもスポットを当てるべきだと思う。
そうしないとソフトウェア開発者全体の大きなパイに属する
人間が救済できない。
アジャイルソフトウェア開発の奥義に書いてあったな
>>782
それは詳細設計次第。
例えばC++ではPCごとにSTLの使い方違わないでしょ。
そういうこと。>>777の書き込みの方法や他にもいろいろと参考にしてみては。
>>783
Cで開発出来ない事はないし
各レイヤーごとに開発して結合という方式で良いものは
レイヤーごとに効率よく開発できればいいと思う。
デバイスドライバ開発等、
そもそも、レイヤ内で完結してる開発もあるし。
それは詳細設計次第。
例えばC++ではPCごとにSTLの使い方違わないでしょ。
そういうこと。>>777の書き込みの方法や他にもいろいろと参考にしてみては。
>>783
Cで開発出来ない事はないし
各レイヤーごとに開発して結合という方式で良いものは
レイヤーごとに効率よく開発できればいいと思う。
デバイスドライバ開発等、
そもそも、レイヤ内で完結してる開発もあるし。
>>785
レイヤーアプローチは、既にレイヤーが決定されている分には簡単だと思うんだ。
レイヤー設計から入るなら話は別だけど。
個人的に好きな設計は、上層と下層が両方とも依存しないタイプの設計。
自分が設計したのはOO設計ではなかったけど。
レイヤーアプローチは、既にレイヤーが決定されている分には簡単だと思うんだ。
レイヤー設計から入るなら話は別だけど。
個人的に好きな設計は、上層と下層が両方とも依存しないタイプの設計。
自分が設計したのはOO設計ではなかったけど。
>>788
設計を意識して開発してないようだけど、
設計の良し悪しは開発が進むと効いてくる
ボディーブローみたいなもんだよ。
今まで簡単な開発が出来たのなら、それはそれまでの設計が良かったって事。
そこで拡張するときに再設計を間違えると
それまでの良さも簡単に台無しになる。
俺は堅実なSEに求められる設計は
アッパーではなくボディーブローだと思う。
設計を意識して開発してないようだけど、
設計の良し悪しは開発が進むと効いてくる
ボディーブローみたいなもんだよ。
今まで簡単な開発が出来たのなら、それはそれまでの設計が良かったって事。
そこで拡張するときに再設計を間違えると
それまでの良さも簡単に台無しになる。
俺は堅実なSEに求められる設計は
アッパーではなくボディーブローだと思う。
STLみたいに実装がカプセル化されたレイヤーに依存するならわかるけど、
下位レイヤーの実装クラスを継承してメソッドをこれこれこのようにオーバーライドして使え
って言われると結局実装に依存しちゃうんだよね。
安全な継承、安全なオーバーライドをするためにはちゃんと実装を調べなきゃいけないし。
それともレイヤー設計ってこんなもん？
下位レイヤーの実装クラスを継承してメソッドをこれこれこのようにオーバーライドして使え
って言われると結局実装に依存しちゃうんだよね。
安全な継承、安全なオーバーライドをするためにはちゃんと実装を調べなきゃいけないし。
それともレイヤー設計ってこんなもん？
なんか歯がゆくなるなあ。
オブジェクト指向設計を神格化するような奴は
オブジェクト指向がメッセージングなのか、クラス化なのか
インターフェースの継承なのか、何ら自ら定義してないし…
オブジェクト指向設計を否定する奴は、実装上の障害のこと
しか言ってないし…
スレタイに沿って言えば、ここの内容見る限りオブジェクト思考「的」
設計は流行っても理論上の「オブジェクト指向」は流行るわけないね。
オブジェクト指向設計を神格化するような奴は
オブジェクト指向がメッセージングなのか、クラス化なのか
インターフェースの継承なのか、何ら自ら定義してないし…
オブジェクト指向設計を否定する奴は、実装上の障害のこと
しか言ってないし…
スレタイに沿って言えば、ここの内容見る限りオブジェクト思考「的」
設計は流行っても理論上の「オブジェクト指向」は流行るわけないね。
>>785
＞なんかこのスレを見ていると大規模アプリを開発している人間が偉い、という印象を受けるけど、
確かにこのテの勘違いクンは多いと思う。だが、大規模アプリを大規模として捕らえているヤツは
まだまだ未熟。本当に偉いのは規模を意識させないプロジェクト運営をやるヤツ。
＞なんかこのスレを見ていると大規模アプリを開発している人間が偉い、という印象を受けるけど、
確かにこのテの勘違いクンは多いと思う。だが、大規模アプリを大規模として捕らえているヤツは
まだまだ未熟。本当に偉いのは規模を意識させないプロジェクト運営をやるヤツ。
実装にはなじまんなー。ＭＳくらいのマップを作成しないとだめじゃん。
794 ：仕様書無しさん：2007/01/21(日) 06:39:39
色々な実装の仕方があるんだから、ちゃんと統一しないとな。設計方針を。
そもそも設計というのは、実装の仕方まで縛ってしまうほど
あいまいさが無いものであるべきなのに、それが無いというのは、設計者が無能ということ。
彼のオナニーを延々と見続けるのは苦痛ではないかい？
そもそも設計というのは、実装の仕方まで縛ってしまうほど
あいまいさが無いものであるべきなのに、それが無いというのは、設計者が無能ということ。
彼のオナニーを延々と見続けるのは苦痛ではないかい？
795 ：真面目なネラー：2007/01/21(日) 07:19:30
１ですが、ここまでのスレを読む限り、オブジェクト設計の流行らないのは
その評価自体がバラバラで、メリットの認識も低いし、実装屋を指導できる
設計屋も少なそう、といったあたりでしょうか？
その評価自体がバラバラで、メリットの認識も低いし、実装屋を指導できる
設計屋も少なそう、といったあたりでしょうか？
勉強するための本がないからです。
共通のコンセンサスが取れない。
共通のコンセンサスが取れない。
上流工程なしで基幹系の開発やってみてください。ｗ
>>799
やったこともないのに含みをもたせるな馬鹿もの
やったこともないのに含みをもたせるな馬鹿もの
ただの揚げ足だな、何の目的で任命されているか
その仕事を満足しない上流工程は無意味といってるだけ。
伝言ゲームの途中で毎回間違える人間のようなもん。
その仕事を満足しない上流工程は無意味といってるだけ。
伝言ゲームの途中で毎回間違える人間のようなもん。
803 ：仕様書無しさん：2007/01/21(日) 10:34:34
＞２ｃｈで議論しまくってから開発すれば問題なし。
＞そもそも、現場は顔突き合わせて話し合うのが一番いいんだよ。
現場で会って話すのがいいのは確かだが、水掛け論にもなりやすい。
ていうか、ネットで論議しまくるだけで解決するなら、
コケるプロジェクトなんてないよね。
「問題なし」って言い切る人はダメだね。
＞そもそも、現場は顔突き合わせて話し合うのが一番いいんだよ。
現場で会って話すのがいいのは確かだが、水掛け論にもなりやすい。
ていうか、ネットで論議しまくるだけで解決するなら、
コケるプロジェクトなんてないよね。
「問題なし」って言い切る人はダメだね。
ようするにオブジェクト設計って別に無能でも多少はきちんとした設計できる銀魂じゃないんでしょ。
むしろデキる人しか使えない。なら流行る必要性がない。
無能７割と言われる世の中じゃあ。
むしろデキる人しか使えない。なら流行る必要性がない。
無能７割と言われる世の中じゃあ。
そもそもできる奴は何やってもできるからなぁ・・・
できない、奴は何をやってもできないし。
無能同士ならOODのほうが多少増しのなんだが。
無能同士ならOODのほうが多少増しのなんだが。
>>806
>無能同士ならOODのほうが多少増しのなんだが。
いや、それもわからないでしょ？
それがそうであることを証明できないでしょ？
このスレでそういう確定できないことを勝手な決め付けで断定口調で話すのもう止めようぜ。
無駄に喧嘩するだけになっちゃうし。
>無能同士ならOODのほうが多少増しのなんだが。
いや、それもわからないでしょ？
それがそうであることを証明できないでしょ？
このスレでそういう確定できないことを勝手な決め付けで断定口調で話すのもう止めようぜ。
無駄に喧嘩するだけになっちゃうし。
ちょっとスレ違いになるが、そもそも設計屋は実装手法を知っていなければならないものだろうか？
実はオレの周りにはそんな設計屋がいっぱいいるのですよ。もちろんｵｻｰﾝばっかり。
実装手法どころかインフラの知識も無いヤツまでいるし。
実はオレの周りにはそんな設計屋がいっぱいいるのですよ。もちろんｵｻｰﾝばっかり。
実装手法どころかインフラの知識も無いヤツまでいるし。
>>810
あー、細かい部分が確実に設計レベルに影響を与える現実があるからなぁ・・・
そんなことないっていうなら自分で組んでみろよっていうしかないわけで・・・
あと、設計がまずい／まずくないってことを確認する方法が実装してみるしかないんだよね。
どうしても人の目だと抜けや漏れが発生する。
これが致命的だとどんなに念入りにチェックしても結局組み直しになるしね。
あー、細かい部分が確実に設計レベルに影響を与える現実があるからなぁ・・・
そんなことないっていうなら自分で組んでみろよっていうしかないわけで・・・
あと、設計がまずい／まずくないってことを確認する方法が実装してみるしかないんだよね。
どうしても人の目だと抜けや漏れが発生する。
これが致命的だとどんなに念入りにチェックしても結局組み直しになるしね。
>>810
できなきゃ虚業。
できなきゃ虚業。
いや無能にＯＯＤは無理。これ定義
俺等もあれだな。
次のステージにいくときかもしれん。
もうオブジェクト指向の設計がいいか悪いかなんて実際どうでもいいだろ。
大事なのは
「いかにして、経営者から金を巻き上げるか？」
だろ？
こういうことを考えたときに開発期間が短くなるなんて変なプレゼンしちゃ駄目だろ？
品質とか保守とか盾にしてどんどん金をプログラマに流すように俺等団結してったほうがいい気がするぜ。
次のステージにいくときかもしれん。
もうオブジェクト指向の設計がいいか悪いかなんて実際どうでもいいだろ。
大事なのは
「いかにして、経営者から金を巻き上げるか？」
だろ？
こういうことを考えたときに開発期間が短くなるなんて変なプレゼンしちゃ駄目だろ？
品質とか保守とか盾にしてどんどん金をプログラマに流すように俺等団結してったほうがいい気がするぜ。
2chで俺たちとか言う奴ってきもー。
根本的に、金をもらって部分を開発する思想の時点で奴隷。
根本的に、金をもらって部分を開発する思想の時点で奴隷。
>818
新糞スレ立ててそっちでやってくれ。
新糞スレ立ててそっちでやってくれ。
（>>818の続き）
で、そのダシにオブジェクト指向設計だの、
ＸＰだのアジャイルだのわけのわからない（けどすごそうな）横文字入れていきたいね。
ＰＧを長くやってたけど実際の品質をよくするなんて行為ははっきりいって俺等にとって一銭の得もねー。
いい加減わかってきてもいいだろ。
～しないと問題になりますよ。
とか経営者を不安にさせろ、もう全員詐欺師になるぐらいの心意気が必要になってるのかもしれんな。
実際、いまのセキュリティだのなんだのって仕事はこんなのと同義だろ？
品質向上のための作業工程確立して無駄な資料たくさん作りまくってその工程を会社に認めさせるところまでいったら成功だな。
資料が膨大に増えたって正直俺は真面目に資料なんて作ったことねぇから作業量は実質０だ。
確かめられるもんならやってみろといいたい（エクセルで１０ＭＢ超えてるようなもん誰も開きすらしないだろ）
で、そのダシにオブジェクト指向設計だの、
ＸＰだのアジャイルだのわけのわからない（けどすごそうな）横文字入れていきたいね。
ＰＧを長くやってたけど実際の品質をよくするなんて行為ははっきりいって俺等にとって一銭の得もねー。
いい加減わかってきてもいいだろ。
～しないと問題になりますよ。
とか経営者を不安にさせろ、もう全員詐欺師になるぐらいの心意気が必要になってるのかもしれんな。
実際、いまのセキュリティだのなんだのって仕事はこんなのと同義だろ？
品質向上のための作業工程確立して無駄な資料たくさん作りまくってその工程を会社に認めさせるところまでいったら成功だな。
資料が膨大に増えたって正直俺は真面目に資料なんて作ったことねぇから作業量は実質０だ。
確かめられるもんならやってみろといいたい（エクセルで１０ＭＢ超えてるようなもん誰も開きすらしないだろ）
いるよね、関係ない話題でかってにアジって盛り上がる馬鹿。
運動好き。対立好き。
そんなにあれなら、自分でパッケージ作って売る側になればいいじゃん。
運動好き。対立好き。
そんなにあれなら、自分でパッケージ作って売る側になればいいじゃん。
>>822
そんな発想だと、日本の産業自体がインドに負けるよ。
そんな発想だと、日本の産業自体がインドに負けるよ。
なんでクソコテに引き続き勘違い長文クンとかアホっぽいヤツが次々に現れるのか
ソフトウェア工学は昔からそんなもんだったがな。
てか、基本的にみんなどうしたいの？
誰のためになんのために効率をよくしたいのかわからない。
予算削れたら、その分開発期間短くなるだけじゃん。
誰のためになんのために効率をよくしたいのかわからない。
予算削れたら、その分開発期間短くなるだけじゃん。
>>829
そう言われると、WEみたいだね。
「オブジェクト指向設計したんだから、工数少なくて済むだろ？」
ってSEが強制的に納期を縮めるような。
OOPもそうだけど、作業時間の再割当が目的だと思う。
そう言われると、WEみたいだね。
「オブジェクト指向設計したんだから、工数少なくて済むだろ？」
ってSEが強制的に納期を縮めるような。
OOPもそうだけど、作業時間の再割当が目的だと思う。
>>832
この業界だと特に大いと思うよ。
残業馬鹿みたいにしてる奴の8割は能力不足と生活残業だろ？
まあ、無理やりスレの趣旨にあわせるが、そういう馬鹿は大体新しい技術への向上心もない。
単に昔の仕事のやり直しを繰り返すだけ。
とはいっても、オブジェクト設計が流行らないのは、やっぱりそれほど絶対的に革新が無いからだろうね。
この業界だと特に大いと思うよ。
残業馬鹿みたいにしてる奴の8割は能力不足と生活残業だろ？
まあ、無理やりスレの趣旨にあわせるが、そういう馬鹿は大体新しい技術への向上心もない。
単に昔の仕事のやり直しを繰り返すだけ。
とはいっても、オブジェクト設計が流行らないのは、やっぱりそれほど絶対的に革新が無いからだろうね。
834 ：仕様書無しさん：2007/01/21(日) 14:25:18
>>791
おれが思うのは、「オブジェクト指向」というのはたとえば「鶴翼の陣」みたいな、
あるいは「つばめ返し」みたいな、現場を離れたところで、エキスだけを取り出した
ものを煮詰めて作ったもの、そういう感じがする。
当然、現場においてそれらが万能なわけではない。
その根底にある考えや、そこに至るまでのさまざまな試行錯誤や取捨選択の
経緯や、そういうことが全体を組み立てるうえである程度役に立つ点は否定
できないが、万能律や大統一理論のように捉えていると、かえって役に立てる
ことはできなくなると思う。
おれが思うのは、「オブジェクト指向」というのはたとえば「鶴翼の陣」みたいな、
あるいは「つばめ返し」みたいな、現場を離れたところで、エキスだけを取り出した
ものを煮詰めて作ったもの、そういう感じがする。
当然、現場においてそれらが万能なわけではない。
その根底にある考えや、そこに至るまでのさまざまな試行錯誤や取捨選択の
経緯や、そういうことが全体を組み立てるうえである程度役に立つ点は否定
できないが、万能律や大統一理論のように捉えていると、かえって役に立てる
ことはできなくなると思う。
>>834はオブジェクト指向入門って本を読んでね
>>833
＞とはいっても、オブジェクト設計が流行らないのは、やっぱりそれほど絶対的に革新が無いからだろうね。
構造化設計技法だって結局流行らずCOBOLじゃ未だにコピペマンセーだよ。
草の根で設計技法が広まらないのは、単にやる気の問題が大きいと思う。
＞とはいっても、オブジェクト設計が流行らないのは、やっぱりそれほど絶対的に革新が無いからだろうね。
構造化設計技法だって結局流行らずCOBOLじゃ未だにコピペマンセーだよ。
草の根で設計技法が広まらないのは、単にやる気の問題が大きいと思う。
>>836
この業界で10年ぐらいだが、コボルの世界って一切関わったことないからしらない。
C、＋＋、＃、VB、.net、JAVA・・・。
ここの人が力説するほど、構造化もオブジェクト指向も別に敷居ないと思うんだけどね。
やってることに別に自慢もすることもないし、よくこのスレでも湧く自慢野郎って恥ずかしいね。
普通にやるべきことをさも特別なように・・・。
この業界で10年ぐらいだが、コボルの世界って一切関わったことないからしらない。
C、＋＋、＃、VB、.net、JAVA・・・。
ここの人が力説するほど、構造化もオブジェクト指向も別に敷居ないと思うんだけどね。
やってることに別に自慢もすることもないし、よくこのスレでも湧く自慢野郎って恥ずかしいね。
普通にやるべきことをさも特別なように・・・。
うちは、フツーにＯＯＰを導入し、かなり成果上げてるけど、
導入したく無い組の強烈なステレヲタイプを崩すのは、
相当労力かかりそうだから傍観してるだけ。むしろ都合がいい。
ＯＯＰを導入するなら、２～３プロジェクトは大赤字の覚悟で、
かなり痛みを伴い社員を成長させる覚悟無いと無理だし、
その過程で脱落者もいっぱい出るだろう。
でも派遣を入れているような会社が大半だろうし、
赤字覚悟で成長させようって発想が出ないでしょ、普通は。
ＯＯＰを実験するなら、中国やインドに投資したほうが思いっきり安くあがるし、
リスクも少ない、しかもハングリー精神旺盛でやる気満々。
日本人がＯＯＰに挑戦する機会はもう与えられないよ。
国内のＳＥは、海外のＳＥを育てるための資金供給源として、
このままリスクの低い今の体制が続くだろう。
っておもってるんだけど、どうよ。
導入したく無い組の強烈なステレヲタイプを崩すのは、
相当労力かかりそうだから傍観してるだけ。むしろ都合がいい。
ＯＯＰを導入するなら、２～３プロジェクトは大赤字の覚悟で、
かなり痛みを伴い社員を成長させる覚悟無いと無理だし、
その過程で脱落者もいっぱい出るだろう。
でも派遣を入れているような会社が大半だろうし、
赤字覚悟で成長させようって発想が出ないでしょ、普通は。
ＯＯＰを実験するなら、中国やインドに投資したほうが思いっきり安くあがるし、
リスクも少ない、しかもハングリー精神旺盛でやる気満々。
日本人がＯＯＰに挑戦する機会はもう与えられないよ。
国内のＳＥは、海外のＳＥを育てるための資金供給源として、
このままリスクの低い今の体制が続くだろう。
っておもってるんだけど、どうよ。
845 ：仕様書無しさん：2007/01/21(日) 14:58:40
>>845
javaってまともなのー？俺、あれ嫌いなんだ・・・orz
javaってまともなのー？俺、あれ嫌いなんだ・・・orz
848 ：仕様書無しさん：2007/01/21(日) 15:05:38
>>847
君はどこのセミナー会社の社員だ？
君はどこのセミナー会社の社員だ？
でも前のフレームワークを捨てるって駄目なことなのかなぁ。
駄目だから続かないって決め付けるのもどうかと・・・。
駄目だから続かないって決め付けるのもどうかと・・・。
保守・運用したときに副作用が発生しにくくて、さらに機能を追加しやすかったら
別に何設計でもよかんべ。
別に何設計でもよかんべ。
854 ：仕様書無しさん：2007/01/21(日) 15:32:25
>>835
甲州流軍学書を読んでね、と同じくらい無意味なレス。
甲州流軍学書を読んでね、と同じくらい無意味なレス。
>>853
Jakartaは、第三者が勝手にやってる同人組合みたいなもんだろ
確かに、Strutsなど最悪のクソプロジェクトが多発してるのは事実だが
分かってる人なら、どんなに雑誌で特集を組まれても見向きもしない。
私も始めからStrutsなどは一笑に付していた（勿論、いろいろ使用した上で）
こういうのに踊らされて飛びつくような人とＯＯＰマンセー主義者は
似た者同士って事だよ
Jakartaは、第三者が勝手にやってる同人組合みたいなもんだろ
確かに、Strutsなど最悪のクソプロジェクトが多発してるのは事実だが
分かってる人なら、どんなに雑誌で特集を組まれても見向きもしない。
私も始めからStrutsなどは一笑に付していた（勿論、いろいろ使用した上で）
こういうのに踊らされて飛びつくような人とＯＯＰマンセー主義者は
似た者同士って事だよ
860 ：仕様書無しさん：2007/01/21(日) 15:51:22
オブジェクト指向がはやらないのは、オブジェクト指向が遅いから。
以上。
以上。
>>860
はい、消えた。
はい、消えた。
オブジェクト指向がそんなに好きなわけじゃないんだけど、
OOPの実行速度が遅いということを言う人がときどきいるよね。
これは完全に濡れ衣だよね。
Javaが遅いのはオブジェクト指向だからじゃないし、
C++はC言語とそんなに変わらない(多少は変わるが)。
自称アセンブラが使えるベテランの人(C言語しかつかえない)
にC++は遅い、と言われてゲロゲロした気分になったことはある。
その人はアセンブラで書けば処理が速くなると思っている
(ここら辺もゲロゲロ)人で、コンパイラが吐くアセンブラコードとか
読んでない。
話をしてるとPentium以降(ってもう既にそんなに最近の話じゃないが)
のアセンブラの最適化とか全然知らないし。
OO厨も勘弁して欲しいが、こういうオヤジもどうにかして欲しい。
多分、OO厨が仮想敵としてムカついているのはこういう人なんだなと思う。
OOPの実行速度が遅いということを言う人がときどきいるよね。
これは完全に濡れ衣だよね。
Javaが遅いのはオブジェクト指向だからじゃないし、
C++はC言語とそんなに変わらない(多少は変わるが)。
自称アセンブラが使えるベテランの人(C言語しかつかえない)
にC++は遅い、と言われてゲロゲロした気分になったことはある。
その人はアセンブラで書けば処理が速くなると思っている
(ここら辺もゲロゲロ)人で、コンパイラが吐くアセンブラコードとか
読んでない。
話をしてるとPentium以降(ってもう既にそんなに最近の話じゃないが)
のアセンブラの最適化とか全然知らないし。
OO厨も勘弁して欲しいが、こういうオヤジもどうにかして欲しい。
多分、OO厨が仮想敵としてムカついているのはこういう人なんだなと思う。
ゲロゲロって…
そんな表現する人がおっさんて言う相手はどんなおっさんだろう
そんな表現する人がおっさんて言う相手はどんなおっさんだろう
865 ：仕様書無しさん：2007/01/21(日) 16:21:05
>>861
いい響きだ
いい響きだ
自分以外の同じくらいの年齢を指す。
すくなくてもおれはそー
すくなくてもおれはそー
OOPが長い間、一般的でなかった最大の理由は
その唯一の言語のsmalltalkが使いものにならないくらい遅かったからである。
C++が出たのは最近だよ。15年くらい前だったと思うが。
その唯一の言語のsmalltalkが使いものにならないくらい遅かったからである。
C++が出たのは最近だよ。15年くらい前だったと思うが。
LISPは何故いつまでたっても流行らないの？
ってスレ立てていいですか？
ごめん、立ててよくても立てません
ってスレ立てていいですか？
ごめん、立ててよくても立てません
>>868
だからSmalltalkが遅いのはOOだからなの？
Smalltalkの選択したアーキテクチャの問題じゃないの？
たとえば当時のマシンではGCが遅かったとしても、それはGCの
問題であって、OOが遅いわけではない。
だからSmalltalkが遅いのはOOだからなの？
Smalltalkの選択したアーキテクチャの問題じゃないの？
たとえば当時のマシンではGCが遅かったとしても、それはGCの
問題であって、OOが遅いわけではない。
良く読めや低脳
JITが入ったSmalltalkは今のC++やJavaほどではないけど
使えないほど遅くはなかったと思う
ただ手軽に試せるようになったころはVBの絶頂期で．．．
使えないほど遅くはなかったと思う
ただ手軽に試せるようになったころはVBの絶頂期で．．．
こんな本が出版されたようですが、このスレの中の方々は原著をお読みになっていたのでしょうか？
http://www.amazon.co.jp/gp/product/4798111112/249-4566423-3261160
http://www.amazon.co.jp/gp/product/4798111112/249-4566423-3261160
業者の宣伝レス乙。第一版と何が変わったのかは知らないが、原則・コンセプトとかいう
変な副題が付いて値段も上がってるのはどうかと思うぞ。
変な副題が付いて値段も上がってるのはどうかと思うぞ。
875 ：仕様書無しさん：2007/01/21(日) 23:10:12
なーんか、こういうスレって盛り上がるけど
TVの討論番組と同じで無意味なんだよね
TVの討論番組と同じで無意味なんだよね
>875
しっ！そんな身も蓋もないこといったら一所懸命マジレスしてるコテの連中がかわいそうじゃないか。
しっ！そんな身も蓋もないこといったら一所懸命マジレスしてるコテの連中がかわいそうじゃないか。
> 875
つーか、プロレスと一緒でそれはお約束で言うのが無粋だと思ったんだけど、
違うのか(´Д｀;
最近暇で面白いことがないので遊んでたんだけど。
あえて周りと逆のことを言ったり。
そもそも2chで実りのある議論をしようと思うほうが間違いなのでは。
俺は面白ければなんでもいいよ。
つーか、プロレスと一緒でそれはお約束で言うのが無粋だと思ったんだけど、
違うのか(´Д｀;
最近暇で面白いことがないので遊んでたんだけど。
あえて周りと逆のことを言ったり。
そもそも2chで実りのある議論をしようと思うほうが間違いなのでは。
俺は面白ければなんでもいいよ。
878 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 00:06:38
ＯＯＤを採り入れると髪の毛が生えたり抜けた歯が生えたりします。
アトピーも一ヶ月で完治しますし、癌さえ直ります。
アトピーも一ヶ月で完治しますし、癌さえ直ります。
失せろ屑コテ
>>875
脳みそ足りない連中の集まりで議論は無理。
脳みそ足りない連中の集まりで議論は無理。
美少女プログラマがオブジェクト指向したいっ
って言えば俺もOOPマンセーです
って言えば俺もOOPマンセーです
俺も、やさしい美人SEが、OOわかんない～とか言えば
COBOLでコーディングしても良い。
COBOLでコーディングしても良い。
>>882
チ○コ・オブジェクトとマ○コ・オブジェクトで説明したいｗｗ
チ○コ・オブジェクトとマ○コ・オブジェクトで説明したいｗｗ
少しでもまともな議論がしたいなら情報学板とかIDの出る板にスレ立ててやったほうが良いと思うよ
>>834
俺もそう思ってるよ。使えるとこは使うっていう現実的選択しかしない。
でも、ハードの世界であるようなアーキテクチャの革新と同じような
ことがソフトウェアではないんだなってことに、歯がゆい思いがする。
すでにオブジェクト指向がその解ではないということは証明されてると思う。
>>844
コンパイラの最適化依存になってる今のCPUアーキテクチャじゃ
むしろ遅くなる場合があるのはその通り。
しかし、Javaが遅いのは事実だし、CPUアーキテクチャが判ってる
人間なら、Cやアセンブラで書いて数倍違う速度出せるのも事実。
俺もそう思ってるよ。使えるとこは使うっていう現実的選択しかしない。
でも、ハードの世界であるようなアーキテクチャの革新と同じような
ことがソフトウェアではないんだなってことに、歯がゆい思いがする。
すでにオブジェクト指向がその解ではないということは証明されてると思う。
>>844
コンパイラの最適化依存になってる今のCPUアーキテクチャじゃ
むしろ遅くなる場合があるのはその通り。
しかし、Javaが遅いのは事実だし、CPUアーキテクチャが判ってる
人間なら、Cやアセンブラで書いて数倍違う速度出せるのも事実。
すまん、レス違い
>>863 な
>>863 な
889 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 01:12:21
ＩＸＩが民事再生法申請
あちゃー
http://www.nikkei.co.jp/news/sangyo/20070121AT1D2100Q21012007.html
東証二部上場で情報サービスのアイ・エックス・アイ（ＩＸＩ）は21日、
大阪地裁に民事再生法の適用を申請し、
受理されたと発表した。負債総額は119億円だが、さらに100億円以上膨らむ可能性があるという。
あちゃー
http://www.nikkei.co.jp/news/sangyo/20070121AT1D2100Q21012007.html
東証二部上場で情報サービスのアイ・エックス・アイ（ＩＸＩ）は21日、
大阪地裁に民事再生法の適用を申請し、
受理されたと発表した。負債総額は119億円だが、さらに100億円以上膨らむ可能性があるという。
失せろ屑コテ
叩きでもいいからレスがほしい。
俺にもそんな時期がありました・・・
俺にもそんな時期がありました・・・
悲しい人生だな・・・
893 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 01:17:37
空対空ミサイルなんかアセンブラだろ？
つまらん死ね
895 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 01:28:33
じゃあ地球シミュレーターはオブジェクト指向を使っているかについて
896 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 01:29:15
おおアカデミック！
> なーんか、こういうスレって盛り上がるけど
>TVの討論番組と同じで無意味なんだよね
そうか?テレビの討論番組は知らんがこのスレに関しては
俺には実に意味がある。というか勉強になる。
なぜ無意味になってしまうのか。
こいつの言うオブジェクト指向がどこがおかしいのか。
俺の言ってるオブジェクト指向とはどう違うのか。
一つ一つ検証すればいくらでも自分のためにする方法はある。
>TVの討論番組と同じで無意味なんだよね
そうか?テレビの討論番組は知らんがこのスレに関しては
俺には実に意味がある。というか勉強になる。
なぜ無意味になってしまうのか。
こいつの言うオブジェクト指向がどこがおかしいのか。
俺の言ってるオブジェクト指向とはどう違うのか。
一つ一つ検証すればいくらでも自分のためにする方法はある。
俺はオブジェクト指向関連嫌い。
最近はクラス嫌いはなくなったけどｗ
むしろ今、クラス化しておいたら、と後悔しているｗｗ
理由１ お客が基本的にオブジェクト思考は仕様変更しても良い
すぐなおると思っているから。交渉が無意味に大変
”それはオブジェクト指向だから大丈夫でしょう”氏ねといいたいｗ
理由２ そこまでに至る設計時間が（１００％）取れないから
設計中にバンバン基本仕様かわるからｗ
中途半端な設計ならなんでもかわらんと思ってるｗｗ
納期が先なのがおかしいｗｗｗ
理由３ やたらでかいものを仕様にのせてくるから
マジつかわねーよ、そんな機能ｗｗ
細かいとこまではつっこんでくるんだよねｗ
理由４ やっぱ設計時に実装でのパフォーマンスが見えにくくなるときあるよｗ
設計でへくってるかもしれんが、
”思いっきり”が減る・・・そうすると仕様（夢）膨らんでさらに悪化ｗ
こういうのがなきゃしっかり設計したいし、新技法もやってみたい
実際そんな時間がない・・・
工数の請求するときやりやすいやり方、というのが俺の正解なのかｗｗ
つーとお客さん側がそういうのが本当にわかる世代が頭取れればいいわけだｗ
うむ、老兵は去るとするかｗ
最近はクラス嫌いはなくなったけどｗ
むしろ今、クラス化しておいたら、と後悔しているｗｗ
理由１ お客が基本的にオブジェクト思考は仕様変更しても良い
すぐなおると思っているから。交渉が無意味に大変
”それはオブジェクト指向だから大丈夫でしょう”氏ねといいたいｗ
理由２ そこまでに至る設計時間が（１００％）取れないから
設計中にバンバン基本仕様かわるからｗ
中途半端な設計ならなんでもかわらんと思ってるｗｗ
納期が先なのがおかしいｗｗｗ
理由３ やたらでかいものを仕様にのせてくるから
マジつかわねーよ、そんな機能ｗｗ
細かいとこまではつっこんでくるんだよねｗ
理由４ やっぱ設計時に実装でのパフォーマンスが見えにくくなるときあるよｗ
設計でへくってるかもしれんが、
”思いっきり”が減る・・・そうすると仕様（夢）膨らんでさらに悪化ｗ
こういうのがなきゃしっかり設計したいし、新技法もやってみたい
実際そんな時間がない・・・
工数の請求するときやりやすいやり方、というのが俺の正解なのかｗｗ
つーとお客さん側がそういうのが本当にわかる世代が頭取れればいいわけだｗ
うむ、老兵は去るとするかｗ
老兵さん、老兵さん、何で人月って残業込みで数えるの？
900 ：仕様書無しさん：2007/01/22(月) 04:15:34
>>899
それはね、おぶじぇくとせっけえがないからだよ
それはね、おぶじぇくとせっけえがないからだよ
お前を食い殺すためだろう
902 ：仕様書無しさん：2007/01/22(月) 11:27:56
903 ：仕様書無しさん：2007/01/22(月) 11:44:20
>>885
OODの設計屋も少ないだろうが、OODのわかるPG屋はもっと少ないだろう。
その実態を知るには、このスレ板で意見を聞くのがよい。
テクニック（術）は知っているが、技法（技と法則）はわからない、
理解できないというPG屋が多いような気がする。
PG屋も頑張らないといけない。
OODの設計屋も少ないだろうが、OODのわかるPG屋はもっと少ないだろう。
その実態を知るには、このスレ板で意見を聞くのがよい。
テクニック（術）は知っているが、技法（技と法則）はわからない、
理解できないというPG屋が多いような気がする。
PG屋も頑張らないといけない。
905 ：おじゃばさま：2007/01/22(月) 19:19:08
だから本来設計とすべき所を「設計」「実装」「テスト」と考えるから分からなくなる。
分離された「設計」見て最初に思う事は、「論理は分かるがどうやればいいか分からない」とか
「理想はそうだが最初からその理想どおりには出来ない」と言う事だろう。
それは当然である。全体の1/3しか見ていないのだから。
そこで多くのSEは「自分のスキルが足りない」と考えてしまう。
しかし安心していい。出来なくて当然なのだ。
ではオブジェクト指向設計とは何か？
一般的に言われている物は不完全なので、本来の形を考えて見よう。
オブジェクト指向プログラミングとは、簡単に言うとクラスを使って、データと処理をグループ化して
プログラミングすると言う事だ。そして実装、テスト、修正を繰り返すのが設計となる。
つまり「クラスを使ってデータと処理をグループ化するプログラミングで、実装、テスト、修正を繰り返す」
のが真のオブジェクト指向設計と言える。
分離された「設計」見て最初に思う事は、「論理は分かるがどうやればいいか分からない」とか
「理想はそうだが最初からその理想どおりには出来ない」と言う事だろう。
それは当然である。全体の1/3しか見ていないのだから。
そこで多くのSEは「自分のスキルが足りない」と考えてしまう。
しかし安心していい。出来なくて当然なのだ。
ではオブジェクト指向設計とは何か？
一般的に言われている物は不完全なので、本来の形を考えて見よう。
オブジェクト指向プログラミングとは、簡単に言うとクラスを使って、データと処理をグループ化して
プログラミングすると言う事だ。そして実装、テスト、修正を繰り返すのが設計となる。
つまり「クラスを使ってデータと処理をグループ化するプログラミングで、実装、テスト、修正を繰り返す」
のが真のオブジェクト指向設計と言える。
906 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 19:22:21
おお！っと思ったけどだめね
＞から約50人のプログラマが開発に参加し，C＋＋言語で20万行のコードを書くという。
たったの20万行書くのに５０人・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
＞から約50人のプログラマが開発に参加し，C＋＋言語で20万行のコードを書くという。
たったの20万行書くのに５０人・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
907 ：おじゃばさま：2007/01/22(月) 19:22:56
ではこれが何故流行らないか？
前述の論理で言うと、「C++もしくはJavaを適切に用いて、プロトタイプ法で開発する」
と言う事になる。
流行らない？いや流行っているというか今主流の開発方法だ。
つまり、「オブジェクト指向設計は流行っている」を言える。
前述の論理で言うと、「C++もしくはJavaを適切に用いて、プロトタイプ法で開発する」
と言う事になる。
流行らない？いや流行っているというか今主流の開発方法だ。
つまり、「オブジェクト指向設計は流行っている」を言える。
908 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/22(月) 19:25:43
コードに落とせるような細部まで設計してないし、そんな細部まで設計するならソース書いたほうが早い
一人４０００行かよ ファイル２－５枚だな
一人４０００行かよ ファイル２－５枚だな
909 ：仕様書無しさん：2007/01/22(月) 19:27:09
>>905
そんな嘘ッパチは原理主義者の俺が許さない。
そもそも本来の形を語るのにシミュレーションの話はおろか、
simulaやsmalltalkの話まで出ないなんて詐欺にもほどがある。
はじめは実装テスト修正を繰り返すなんて話はなかった。
そんなのは後から都合がいいようにとって付けたセミナー用の話題でしかない。
そんな嘘ッパチは原理主義者の俺が許さない。
そもそも本来の形を語るのにシミュレーションの話はおろか、
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年代前半からすでにあった。
また、それ以前のコボルが主流だった時代には、書式やパラメータを変えるレベルでもリリースが
繰り返されており、そのリリース自体がテストだと考えると、繰り返し行われるリリース自体が
テスト実装繰り返しだと言える。つまり要素自体はあったと言える。
会社の規模やプロジェクトにもよるので目安にしかならないが、一人の担当者に割り振る量は、
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
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はもう古い
今はそのまんま東が旬だ
今はそのまんま東が旬だ
オブジェクト指向系開発プロセスの教科書にたいてい書かれている、
「この本に書かれている開発プロセスの適用範囲外」には必ず宇宙開発の
話がでてくる。
(覚えている範囲ではジムハイスミスの「適応型ソフトウエア開発」あたりか)
やつらの仕事は基本的にかかっている金額が膨大かつ、人命がかかって
いるので絶対失敗は許されない。リリースの時点で完璧でなくては
駄目で、それ以降の保守イテレーションで修正することはできない。
プライオリティは、生産性＜＜＜品質なのでひとりあたりのコーディング
量が少ないのは科学的な裏づけがあってやってることでしょ。
バグを撲滅するためにJava PathFinderとか形式手法のツールを
つくったり、基本的に一般企業の人(ましてやこのスレにいる連中)とは
違うエリート連中がやっているから、自分たちの物差しで測らない方が
いいと思うぞ。
「この本に書かれている開発プロセスの適用範囲外」には必ず宇宙開発の
話がでてくる。
(覚えている範囲ではジムハイスミスの「適応型ソフトウエア開発」あたりか)
やつらの仕事は基本的にかかっている金額が膨大かつ、人命がかかって
いるので絶対失敗は許されない。リリースの時点で完璧でなくては
駄目で、それ以降の保守イテレーションで修正することはできない。
プライオリティは、生産性＜＜＜品質なのでひとりあたりのコーディング
量が少ないのは科学的な裏づけがあってやってることでしょ。
バグを撲滅するためにJava PathFinderとか形式手法のツールを
つくったり、基本的に一般企業の人(ましてやこのスレにいる連中)とは
違うエリート連中がやっているから、自分たちの物差しで測らない方が
いいと思うぞ。
>>909、原理主義を名乗るならもうちょっと勉強してからにしないと…
オブジェクト指向には大きく分けてアラン・ケイのメッセージ指向（すべてをメッセージ
ングで…）と、ビョーン・ストラウストラップのクラス指向（ユーザー定義型を「クラス」で
実現する…）がある。現在主流の考え方は後者の流れ。
まず、シミュレーション言語のSIMULA Iで「プロセス」「アクション」と呼んでいたものを
SIMULA 67で汎用言語に発展させるときに「クラス」「オブジェクト」と言い換えたのが
言語機能としての「クラス」と「オブジェクト」の始まり。注意すべきことは、この時点で
は、まだ「オブジェクト指向」という考え方は存在しない。
そのSIMULA 67の「クラス」を利用して、ユーザーによるデータ型定義をサポートできな
いかと考えたのがストラウストラップ。つまり、ユーザー型定義（抽象データ型、カプセル
化）と、クラスの機能である「継承」「仮想関数による動的性（ポリモーフィズム）」が彼の
「オブジェクト指向」であると定義した。
ちなみに、前後するけれど、SIMULA 67の「オブジェクト」をメッセージの受け手にできないかと考え
たのがケイ。「オブジェクト」を非常に小さな（しかし万能の）コンピュータに、「メッセージング」を
高速のネットワークにそれぞれ見立てて、そうしたモデルでコンピューティングシステム
（特に個人向けの…）を構築できないかと模索して試作されたのがSmalltalkシステム。
話を戻して、ストラウストラップの「オブジェクト指向」（主にプログラミングや言語の話）を
ベースに、これをソフトウエアの設計段階に応用できないかと考えたのがブーチ。彼は
Ada（抽象データ型言語、つまり、クラスはないがユーザー定義型を定義できる機能を有する）
での開発の経験を通じて、この考え方に行き着いた。後に出てきたランボー、ヤコブソンと
紆余曲折があってUMLが誕生するまでの話は面倒なので端折る。
総じて、シミュレーションはオブジェクト指向と相性はいいかもしれないけれども、直接の
関係はない。SIMULA、Smalltalkもしかり。ケイのメッセージングの考え方は、今や、
形骸的に扱われるに過ぎず、「オブジェクト指向」を学ぶには混乱を招くばかりで益は少ない。
オブジェクト指向には大きく分けてアラン・ケイのメッセージ指向（すべてをメッセージ
ングで…）と、ビョーン・ストラウストラップのクラス指向（ユーザー定義型を「クラス」で
実現する…）がある。現在主流の考え方は後者の流れ。
まず、シミュレーション言語のSIMULA Iで「プロセス」「アクション」と呼んでいたものを
SIMULA 67で汎用言語に発展させるときに「クラス」「オブジェクト」と言い換えたのが
言語機能としての「クラス」と「オブジェクト」の始まり。注意すべきことは、この時点で
は、まだ「オブジェクト指向」という考え方は存在しない。
そのSIMULA 67の「クラス」を利用して、ユーザーによるデータ型定義をサポートできな
いかと考えたのがストラウストラップ。つまり、ユーザー型定義（抽象データ型、カプセル
化）と、クラスの機能である「継承」「仮想関数による動的性（ポリモーフィズム）」が彼の
「オブジェクト指向」であると定義した。
ちなみに、前後するけれど、SIMULA 67の「オブジェクト」をメッセージの受け手にできないかと考え
たのがケイ。「オブジェクト」を非常に小さな（しかし万能の）コンピュータに、「メッセージング」を
高速のネットワークにそれぞれ見立てて、そうしたモデルでコンピューティングシステム
（特に個人向けの…）を構築できないかと模索して試作されたのがSmalltalkシステム。
話を戻して、ストラウストラップの「オブジェクト指向」（主にプログラミングや言語の話）を
ベースに、これをソフトウエアの設計段階に応用できないかと考えたのがブーチ。彼は
Ada（抽象データ型言語、つまり、クラスはないがユーザー定義型を定義できる機能を有する）
での開発の経験を通じて、この考え方に行き着いた。後に出てきたランボー、ヤコブソンと
紆余曲折があってUMLが誕生するまでの話は面倒なので端折る。
総じて、シミュレーションはオブジェクト指向と相性はいいかもしれないけれども、直接の
関係はない。SIMULA、Smalltalkもしかり。ケイのメッセージングの考え方は、今や、
形骸的に扱われるに過ぎず、「オブジェクト指向」を学ぶには混乱を招くばかりで益は少ない。
思うんだけど、ビョーン・ストラウストラップってオブジェクト指向
の歴史から言ってキーパーソンというか、「オブジェクト指向」に
大して大きな業績のある人なんだろうか。個人的にはC++という実用言語
の開発者というイメージなんだけど。
実際、"C++の設計と進化"とか読むとストラウストラップはオブジェクト指向
より、言語の構文論とか機能や言語の持つトリックとかに興味があるように
思うんだけど。実際、そういうスタンスで開発していたから、C++が
実用言語で足りえたように思う。
の歴史から言ってキーパーソンというか、「オブジェクト指向」に
大して大きな業績のある人なんだろうか。個人的にはC++という実用言語
の開発者というイメージなんだけど。
実際、"C++の設計と進化"とか読むとストラウストラップはオブジェクト指向
より、言語の構文論とか機能や言語の持つトリックとかに興味があるように
思うんだけど。実際、そういうスタンスで開発していたから、C++が
実用言語で足りえたように思う。
> オブジェクト指向と聞いて、「カプセル化、継承、ポリモーフィズ」なんてみじんも
> 思い浮かばない人にとっては、たいした貢献はしていない人だと思うよ（反語的に）。
相手をこの程度の見下し方しかできない人にこういうこと言われるとぐんにゃり。
穴があったら叫びたい、ホーア、ホーア。
> 思い浮かばない人にとっては、たいした貢献はしていない人だと思うよ（反語的に）。
相手をこの程度の見下し方しかできない人にこういうこと言われるとぐんにゃり。
穴があったら叫びたい、ホーア、ホーア。
やっぱりオブジェクト指向の元はシミュレーションだな。
>>906
電球の考え方は間違ってるよ。
特に科学技術関連分野って、１０００行ですら大変なはず。
試行錯誤を繰り返し、拡張と削減の連続で２０万行なんてとんでもなく大変だと思うが。
そういった環境だからこそ、C++が求められ、効果が上げられるんだろう。
もともとC++って、そういった奴らのために存在する言語だし、
一回書けば終りのような、さんすうレベルの単純作業には向かない。労力かかるだけ。
コード数が少ないからダメだとか言うのは、
そりゃ、SEが単なるライン工だという事を自ら認めているようなものだ。
電球の考え方は間違ってるよ。
特に科学技術関連分野って、１０００行ですら大変なはず。
試行錯誤を繰り返し、拡張と削減の連続で２０万行なんてとんでもなく大変だと思うが。
そういった環境だからこそ、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/
キターーーーーーっていう感じですね！
こういうプロジェクトがアメリカでどんどん増殖すると、日本にも飛び火して、私も出番がやってきそうーーーー！！
超うれしいニュースです。
＞＞NASA，「ジェイムズ・ウェッブ宇宙望遠鏡」のソフトをIBM製UMLツールで開発
＞ttp://itpro.nikkeibp.co.jp/article/NEWS/20070122/259204/
キターーーーーーっていう感じですね！
こういうプロジェクトがアメリカでどんどん増殖すると、日本にも飛び火して、私も出番がやってきそうーーーー！！
超うれしいニュースです。
いやRoseって普通にうちでも開発に使ってるけど、すんげ～使いづらいよ。
しかもその記事、C++でコード書くって書いてあるじゃん。
RoseにC++のコード吐き出させて、その上で詳細を記述してくんだろうが
RoseじゃC++の威力を半分も引き出せませんよ。
Roseでモデル書いてエディタでコード書いてリバースかけてモデルに反映してなんてくそ面倒くさい。
情報の二重化は避けましょうってどんな教科書にも書いてあるのに偉い人にはわからんのです。
しかもその記事、C++でコード書くって書いてあるじゃん。
RoseにC++のコード吐き出させて、その上で詳細を記述してくんだろうが
RoseじゃC++の威力を半分も引き出せませんよ。
Roseでモデル書いてエディタでコード書いてリバースかけてモデルに反映してなんてくそ面倒くさい。
情報の二重化は避けましょうってどんな教科書にも書いてあるのに偉い人にはわからんのです。
ストラウストラップを語るならクラス継承の構造的欠陥を
指摘したクックも語らないと片手落ちじゃねえの？
指摘したクックも語らないと片手落ちじゃねえの？
930 ：仕様書無しさん：2007/01/22(月) 23:16:03
>>930
簡単にかつ乱暴に言うと、データ型による抽象化はオブジェクト指向では
ないと言ってる。それは「手続き」によってなされるべきだと。
クラス継承をそのデータ型に派生させることは、理論上問題があると
証明した人だな。だから「インターフェース継承」を提唱した。
ストラウストラップの言うポリモーフィズムとかはクラス継承あっての
概念だから、それに対して死刑宣告したも同然だなｗ
実際、ポリモーフィズムとか多用する奴はトラブル起こすだろ？
これはオブジェクト指向プログラミングの話だけど、構造的欠陥と
いうのは設計だろうが何だろうが、問題を起こすのは自明のこと。
簡単にかつ乱暴に言うと、データ型による抽象化はオブジェクト指向では
ないと言ってる。それは「手続き」によってなされるべきだと。
クラス継承をそのデータ型に派生させることは、理論上問題があると
証明した人だな。だから「インターフェース継承」を提唱した。
ストラウストラップの言うポリモーフィズムとかはクラス継承あっての
概念だから、それに対して死刑宣告したも同然だなｗ
実際、ポリモーフィズムとか多用する奴はトラブル起こすだろ？
これはオブジェクト指向プログラミングの話だけど、構造的欠陥と
いうのは設計だろうが何だろうが、問題を起こすのは自明のこと。
931それって巡り巡って今我々がよく聞く一般的なドグマで言うと、
「実装継承は悪」
って話？
# はずしているかも知れんけど。
「実装継承は悪」
って話？
# はずしているかも知れんけど。
>>932
ちょっと違うな。静的な型チェックしかできないSmallTalkみたいな
言語で継承使っても何の問題もない。（ただのテンプレっちゃそうｗ）
C++で継承を多用すれば動的な型チェックが多くなる。
そういうコードに問題が多くなる。
ちょっと違うな。静的な型チェックしかできないSmallTalkみたいな
言語で継承使っても何の問題もない。（ただのテンプレっちゃそうｗ）
C++で継承を多用すれば動的な型チェックが多くなる。
そういうコードに問題が多くなる。
>>933
この論文でいいのかな？あとでゆっくり読んでみるわ
http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf
で、
>C++で継承を多用すれば動的な型チェックが多くなる。
>そういうコードに問題が多くなる。
なんだけど、C++のテンプレートはその問題に対する解答にならなかったのかな？
継承を多用する代わりにポリシークラスを静的に組み合わせて多態性を実現すれば
動的な型チェックはしなくてすみそうだよね
この論文でいいのかな？あとでゆっくり読んでみるわ
http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf
で、
>C++で継承を多用すれば動的な型チェックが多くなる。
>そういうコードに問題が多くなる。
なんだけど、C++のテンプレートはその問題に対する解答にならなかったのかな？
継承を多用する代わりにポリシークラスを静的に組み合わせて多態性を実現すれば
動的な型チェックはしなくてすみそうだよね
>>931
> ストラウストラップの言うポリモーフィズムとかはクラス継承あっての
> 概念だから、それに対して死刑宣告したも同然だなｗ
でもオーバーロードができるC++では問題はないって補足的記述があったような希ガス。
当該論文の最後の方。俺的には、クックの指摘はEiffelの、特に、オーバーロードを認めず、
かつ、理論を無視して引数の共変に固執するメイヤーの継承モデル限定だと思うんだけど…。
> ストラウストラップの言うポリモーフィズムとかはクラス継承あっての
> 概念だから、それに対して死刑宣告したも同然だなｗ
でもオーバーロードができるC++では問題はないって補足的記述があったような希ガス。
当該論文の最後の方。俺的には、クックの指摘はEiffelの、特に、オーバーロードを認めず、
かつ、理論を無視して引数の共変に固執するメイヤーの継承モデル限定だと思うんだけど…。
>>931
いや、それはそう。ただ、C++もその要素を残してしまったのが問題で
ポリモーフィズム自体を否定してるわけではないと思う。
現実には「オーバーロードできる」から問題がないわけではなくて
その意識を常に全員が持ってないとダメだからマズイんでしょ。
そのために代替案を出してるわけであって…
いや、それはそう。ただ、C++もその要素を残してしまったのが問題で
ポリモーフィズム自体を否定してるわけではないと思う。
現実には「オーバーロードできる」から問題がないわけではなくて
その意識を常に全員が持ってないとダメだからマズイんでしょ。
そのために代替案を出してるわけであって…
論文の内容を読んでないけど、タイトルがいきなり
「オブジェクト指向プログラミング対抽象データ型」
ですか。抽象データ型はオブジェクト指向ではないのか。
ここで自分の無知が発覚。
自分の中で、オブジェクト指向＝抽象データ型だったけど、
これをやり始めたのが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の記事はよくまとまってるね。
これ書いた人も多分、オブジェクト指向原理主義者っぽいけど、
このスレの途中までによくいたエセとは違うリアル原理主義者っぽい。
こんな煽りスレで自分の見えてない部分を見せられるとは思わなかったよ。
重ね重ねアホ過ぎます。
「オブジェクト指向プログラミング対抽象データ型」
ですか。抽象データ型はオブジェクト指向ではないのか。
ここで自分の無知が発覚。
自分の中で、オブジェクト指向＝抽象データ型だったけど、
これをやり始めたのが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
ここで無知を自覚したんですが、識者の方々、こういう本来の
姿のオブジェクト指向について書かれた教科書って知っています？
(日本語の本がいいです)
ピアソンエデュケーションとかのような書店に並んでいる割と最近の
オブジェクト指向本は本筋からずれている印象を受ける。
姿のオブジェクト指向について書かれた教科書って知っています？
(日本語の本がいいです)
ピアソンエデュケーションとかのような書店に並んでいる割と最近の
オブジェクト指向本は本筋からずれている印象を受ける。
>940
だからその試験装置をつくるのにいくらかかるんだ。
下手するとしょうもないバグでその試験装置も使い捨てになるし。
どっかのサイトに今まであった最大規模のソフトウェアバグに
よる損失の事例が載ってたな。どこだったか失念したが。
ソフトウェアバグによるスペースシャトルの打ち上げ失敗で
歴史に残るような損失を出したこともあるんだぞ。
どうでもいい自分の仕事を基準にしないように。
工員なんだから身の丈を知りなさい！
だからその試験装置をつくるのにいくらかかるんだ。
下手するとしょうもないバグでその試験装置も使い捨てになるし。
どっかのサイトに今まであった最大規模のソフトウェアバグに
よる損失の事例が載ってたな。どこだったか失念したが。
ソフトウェアバグによるスペースシャトルの打ち上げ失敗で
歴史に残るような損失を出したこともあるんだぞ。
どうでもいい自分の仕事を基準にしないように。
工員なんだから身の丈を知りなさい！
俺は原理主義者だけどストラウストラップがオブジェクト指向を理解していたとは到底思えないんだよね。
俺にとってのオブジェクト指向ははじめのSimulaの
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、というものである。
気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
だけ。
他はすべて蛇足。
俺にとってのオブジェクト指向ははじめのSimulaの
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、というものである。
気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
だけ。
他はすべて蛇足。
>>941
「オブジェクト指向」の概念そのものが、いくつもあるなかで
そのどれを取捨選択しているか、という理念を持った本はひとつも
ないと思う。ほとんど、オブジェクト指向として提唱された理論を
全部ぶちこもうとしてるだけ…
もちろん取捨選択にしても、捨てる概念を詳細に紹介した上で理由を
述べて、採用しないとする本がいいんだけど、見たことないね。
結局、英語の論文読んで少しずつ自分なりの「オブジェクト指向」を
固めて行くしかないのが現状だと思うな。
「オブジェクト指向」の概念そのものが、いくつもあるなかで
そのどれを取捨選択しているか、という理念を持った本はひとつも
ないと思う。ほとんど、オブジェクト指向として提唱された理論を
全部ぶちこもうとしてるだけ…
もちろん取捨選択にしても、捨てる概念を詳細に紹介した上で理由を
述べて、採用しないとする本がいいんだけど、見たことないね。
結局、英語の論文読んで少しずつ自分なりの「オブジェクト指向」を
固めて行くしかないのが現状だと思うな。
>>937の論文、要約の段階でフレキシビリティなsmalltalkの継承がうんたらって言ってるが
さすがにsmalltalkはわからんなぁ。eiffelやJavaやC++とは全然違うんだろう。
やっぱsmalltalkの勉強はオブジェクト指向を理解するためにちょっとはやらんとダメか。
さすがにsmalltalkはわからんなぁ。eiffelやJavaやC++とは全然違うんだろう。
やっぱsmalltalkの勉強はオブジェクト指向を理解するためにちょっとはやらんとダメか。
>>943
その「原理主義者」っていったい何なの？
取りあえず、オブジェクト指向の理念は抽象化の理念だとしよう。
それはクラス志向なのかメッセージングなのかインターフェース
なのか、それともそのいくつかの組み合わせなのか…
基本的な理論を提唱した学者の間でも議論があるのに、それに対して
「原理主義」と言えるのが判らない。
君が原理主義者を名乗る以上、あまたの学者と議論できなきゃオカシイ
んだよ？オブジェクト指向と言われるようになってからの「オブジェクト」
という概念がすべてだと思ってるのは短絡的だと思うけどな。
>>946
今でもネットワークやらDBやら、色々なとこで概念的なものは生きている。
実際に使うことがあるかどうかは別にして、かじっといても損はない。
その「原理主義者」っていったい何なの？
取りあえず、オブジェクト指向の理念は抽象化の理念だとしよう。
それはクラス志向なのかメッセージングなのかインターフェース
なのか、それともそのいくつかの組み合わせなのか…
基本的な理論を提唱した学者の間でも議論があるのに、それに対して
「原理主義」と言えるのが判らない。
君が原理主義者を名乗る以上、あまたの学者と議論できなきゃオカシイ
んだよ？オブジェクト指向と言われるようになってからの「オブジェクト」
という概念がすべてだと思ってるのは短絡的だと思うけどな。
>>946
今でもネットワークやらDBやら、色々なとこで概念的なものは生きている。
実際に使うことがあるかどうかは別にして、かじっといても損はない。
>944
なんか書籍の感想についてはまさにそのとおりとうなずいてしまいます。
実は書籍を書いているレベルの人でもオブジェクト指向全体が俯瞰できて
いる人はあまりいないのでは？という気がしてきます。
そういう意味ではオブジェクト指向って難しすぎるわ。
今更ながら。
なんか書籍の感想についてはまさにそのとおりとうなずいてしまいます。
実は書籍を書いているレベルの人でもオブジェクト指向全体が俯瞰できて
いる人はあまりいないのでは？という気がしてきます。
そういう意味ではオブジェクト指向って難しすぎるわ。
今更ながら。
>>861,862,863
俺は20代。Javaは好んで使うほうだ。
同じJavaのコードをオブジェクト指向で書いたものと、そうでないものを
単純にパフォーマンスのみの観点で実行・比較してみろ。
馬鹿な客が1msec遅いといって騒ぎ出して徹夜させられるような業界では即死。
仕事で使えばわかるだろ?
俺は20代。Javaは好んで使うほうだ。
同じJavaのコードをオブジェクト指向で書いたものと、そうでないものを
単純にパフォーマンスのみの観点で実行・比較してみろ。
馬鹿な客が1msec遅いといって騒ぎ出して徹夜させられるような業界では即死。
仕事で使えばわかるだろ?
>>943 はとりあえずソース出せ（だせるもんなら…）、って感じだよね。
ダールやニガートが1960年代に、すでにそういうことを書いていたのなら（つまり、
ケイやストラウストラップのオブジェクト指向が出たあとの「後出し」じゃないなら）
こっちも認識を改めなくもないけれど…。
ダールやニガートが1960年代に、すでにそういうことを書いていたのなら（つまり、
ケイやストラウストラップのオブジェクト指向が出たあとの「後出し」じゃないなら）
こっちも認識を改めなくもないけれど…。
>>944
>結局、英語の論文読んで少しずつ自分なりの「オブジェクト指向」を
>固めて行くしかないのが現状だと思うな。
オブジェクト指向の勉強に関してはまさにそのとおりで、
現状はそうするしかないよね。
でもそうすると、明日の仕事をする上でチームの仲間と
オブジェクト指向について共通した認識を持つことは不可能になっちゃうな。
>結局、英語の論文読んで少しずつ自分なりの「オブジェクト指向」を
>固めて行くしかないのが現状だと思うな。
オブジェクト指向の勉強に関してはまさにそのとおりで、
現状はそうするしかないよね。
でもそうすると、明日の仕事をする上でチームの仲間と
オブジェクト指向について共通した認識を持つことは不可能になっちゃうな。
>>951
それは、驚かさないように、ちょっとずつ（自分も周りも）馴らしてゆくしか…。
ストラウストラップが「カプセル化、継承、ポリモーフィズム」のルーツだと言っても
自分がオブジェクト指向を理解できていると信じている人のほとんどは拒絶反応を示すと思う。
それは、驚かさないように、ちょっとずつ（自分も周りも）馴らしてゆくしか…。
ストラウストラップが「カプセル化、継承、ポリモーフィズム」のルーツだと言っても
自分がオブジェクト指向を理解できていると信じている人のほとんどは拒絶反応を示すと思う。
>>948
そうだね。難しすぎるというかカオスになっちゃってるからｗ
でも、モノは考え方だから。自分なりの定義を見つけられた時に
抽象化という理想に少しだけ近づけるんだと思う。
>>951,952
設計・分析にしろ実装にしろ新しい概念をチームに意識付けるのは
「布教」しかないと思うよ。布教するには自身の勉強と現実との
整合性をどう取るかってのは重要だと思う。
押し付けるだけじゃなくて、心から納得させないとダメだしね。
それは長く遠い道のりかも知れないけど、やりがいはあるっても
言えるんだし頑張ろう…
そうだね。難しすぎるというかカオスになっちゃってるからｗ
でも、モノは考え方だから。自分なりの定義を見つけられた時に
抽象化という理想に少しだけ近づけるんだと思う。
>>951,952
設計・分析にしろ実装にしろ新しい概念をチームに意識付けるのは
「布教」しかないと思うよ。布教するには自身の勉強と現実との
整合性をどう取るかってのは重要だと思う。
押し付けるだけじゃなくて、心から納得させないとダメだしね。
それは長く遠い道のりかも知れないけど、やりがいはあるっても
言えるんだし頑張ろう…
思い返せば同じようなことを言っている人はときどき見かけることが
あったような気がしたが、全然言ってることが直感的に理解できてなかった。
理解(中身の勉強はこれからだが)してしまえば、当たり前な感じがするけど。
でも、これは気づけというのも何かの弾みがないと無理。
布教する方も色々誤解を受けそうで大変だな。時間もかかるし、
もしかすると結果として納得してくれないかもしれない。
俺もマジで今日は勉強になった。
あったような気がしたが、全然言ってることが直感的に理解できてなかった。
理解(中身の勉強はこれからだが)してしまえば、当たり前な感じがするけど。
でも、これは気づけというのも何かの弾みがないと無理。
布教する方も色々誤解を受けそうで大変だな。時間もかかるし、
もしかすると結果として納得してくれないかもしれない。
俺もマジで今日は勉強になった。
>>945
>Simulaはメンバ関数を「メソッド」とかいうふうに呼んでなかったし。
だから何？
>>947
別に厳密な定義なんてどうでもいいんだよ。
実際に認識できるモデルをクラスに反映することさえ満たしてりゃ。
別に誰の考えとったってセミナーボウヤみたいに余計なクラスと作るだの、
再利用だの開発期間の短縮など押し付けてくる奴はいなかっただろ？
「はじめはどうなのよ？」っていう意見を投げることによってそういう雑音を吹き飛ばすことができる。
それだけでいいんだ。
>Simulaはメンバ関数を「メソッド」とかいうふうに呼んでなかったし。
だから何？
>>947
別に厳密な定義なんてどうでもいいんだよ。
実際に認識できるモデルをクラスに反映することさえ満たしてりゃ。
別に誰の考えとったってセミナーボウヤみたいに余計なクラスと作るだの、
再利用だの開発期間の短縮など押し付けてくる奴はいなかっただろ？
「はじめはどうなのよ？」っていう意見を投げることによってそういう雑音を吹き飛ばすことができる。
それだけでいいんだ。
SimulaはNGワード推奨だな
カタコトのOO話者を排除するスレはここでつか？
961 ：おじゃばさま：2007/01/23(火) 09:44:14
ではそろそろオブジェクト指向の学習方法に入ろう。
ここでも大きな間違いが存在している。それは、「本を見て分かるのは知っている人だけ」と言う事である。
俺が初期に読みあさったオブジェクト指向関係の本は、例の動物や人間、ド○えもんやド○ミちゃんが
出てくる本だった。今考えれば、言いたいことは分かるが、当時としては「だからどうした」と思った。
カプセル化した構造化と比べて、どこが利点なのか不明だった。
時が過ぎ、新人教育のために資料を作る事になった。新人が対象のため、コードに依存しない抽象的な
説明を入れた資料だったが、試しにそれをいろいろな人に見てもらった。
評価は2つに分かれた。「よく分かる」と「よく分からない」だ。
それぞれの評価を行った人を分析してみると、意外なことが分かった。
「よく分かる」と答えた人は、オブジェクト指向をマスターしている人ばかり。
「よく分からない」と答えたのは、新人／ベテランに拘わらずオブジェクト指向未経験者だった。
またこれを書いた俺本人も、当然、分かりやすい資料だと思ったが、ふと気がついた。
これは俺が初期に読んだ動物と人間本に似ている。そしてこれが現在のオブジェクト指向書の縮図だ。
つまりこういう事だ。
発売されているほとんどの原理本は、筆者とオブジェクト指向をマスターした人にとっては良い本で、
オブジェクト指向をマスターしていない人にとっては悪い本なのだ。
ここでも大きな間違いが存在している。それは、「本を見て分かるのは知っている人だけ」と言う事である。
俺が初期に読みあさったオブジェクト指向関係の本は、例の動物や人間、ド○えもんやド○ミちゃんが
出てくる本だった。今考えれば、言いたいことは分かるが、当時としては「だからどうした」と思った。
カプセル化した構造化と比べて、どこが利点なのか不明だった。
時が過ぎ、新人教育のために資料を作る事になった。新人が対象のため、コードに依存しない抽象的な
説明を入れた資料だったが、試しにそれをいろいろな人に見てもらった。
評価は2つに分かれた。「よく分かる」と「よく分からない」だ。
それぞれの評価を行った人を分析してみると、意外なことが分かった。
「よく分かる」と答えた人は、オブジェクト指向をマスターしている人ばかり。
「よく分からない」と答えたのは、新人／ベテランに拘わらずオブジェクト指向未経験者だった。
またこれを書いた俺本人も、当然、分かりやすい資料だと思ったが、ふと気がついた。
これは俺が初期に読んだ動物と人間本に似ている。そしてこれが現在のオブジェクト指向書の縮図だ。
つまりこういう事だ。
発売されているほとんどの原理本は、筆者とオブジェクト指向をマスターした人にとっては良い本で、
オブジェクト指向をマスターしていない人にとっては悪い本なのだ。
962 ：おじゃばさま：2007/01/23(火) 09:50:38
>918
宇宙開発とは失敗の連続である。
アポロ計画以前の段階ではアメリカのロケット打ち上げの成功率は30%程度だった。
ロケットが爆発し一瞬にして大金が失われる映像を見た事がある人も多いだろう。
問題は失敗しないことではなく、「失敗から学ぶ」「同じ失敗を繰り返さない」事である。
そこがデスマーチを繰り返すSヨには欠けているのだろう。
宇宙開発とは失敗の連続である。
アポロ計画以前の段階ではアメリカのロケット打ち上げの成功率は30%程度だった。
ロケットが爆発し一瞬にして大金が失われる映像を見た事がある人も多いだろう。
問題は失敗しないことではなく、「失敗から学ぶ」「同じ失敗を繰り返さない」事である。
そこがデスマーチを繰り返すSヨには欠けているのだろう。
964 ：仕様書無しさん：2007/01/23(火) 12:20:45
日本が失敗から学べないのは責任者は切腹っていう文化があるからだよ。
旧海軍でも、敗戦の将はことごとく船と一緒に沈んでるし。
失敗の大切なノウハウが生かされないのは、今も同じ。
あれだけ炎上させてよく会社にいれるね、って。
旧海軍でも、敗戦の将はことごとく船と一緒に沈んでるし。
失敗の大切なノウハウが生かされないのは、今も同じ。
あれだけ炎上させてよく会社にいれるね、って。
>>950
その文章何がいいたいのかわからない。
その文章何がいいたいのかわからない。
966 ：おじゃばさま：2007/01/23(火) 20:35:04
ではオブジェクト指向の学習方法について話を戻そう。
前述の通り書籍を読みあさっても、未経験者には無駄だろう。
まず最初にすべき事は、オブジェクト指向プログラミングを実践することである。
具体的に言うと、
1.Javaの文法を覚える。
2.データをフィールド変数に記述し、ゲッター／セッターを作る。
3.処理をグループ化し、適切なクラス内にメソッドとして記述する。
4.仕様が変更になるたびに、どこのクラスにデータか処理を記述すべきか考え、修正を繰り返す。
（4を行っていると、修正のたびにプログラムが洗練されて行くと感じる頃が来るだろう。その時点で次に進む）
5.オブジェクト本を読み、原理について理解する。
Java以外のオブジェクト指向言語でも構わないが、難易度と用途の多さからJavaをお勧めする。
2でどう組んでいいか分からない時は、誰かのソースを参考にするのがいいが、適切なコードがない。
自社のプロジェクトでWEBアプリケーションを作っているなら、JavaBeanやStrutsのフォームクラスを
参考にするといいだろう。まあ、オブジェクト指向経験者にソースを見せてもらうのがいい。
4を実感するようになるには、個人差はあるが普通にプログラミングに携わっていれば、
半年～1年半と言う所だろう。
前述の通り書籍を読みあさっても、未経験者には無駄だろう。
まず最初にすべき事は、オブジェクト指向プログラミングを実践することである。
具体的に言うと、
1.Javaの文法を覚える。
2.データをフィールド変数に記述し、ゲッター／セッターを作る。
3.処理をグループ化し、適切なクラス内にメソッドとして記述する。
4.仕様が変更になるたびに、どこのクラスにデータか処理を記述すべきか考え、修正を繰り返す。
（4を行っていると、修正のたびにプログラムが洗練されて行くと感じる頃が来るだろう。その時点で次に進む）
5.オブジェクト本を読み、原理について理解する。
Java以外のオブジェクト指向言語でも構わないが、難易度と用途の多さからJavaをお勧めする。
2でどう組んでいいか分からない時は、誰かのソースを参考にするのがいいが、適切なコードがない。
自社のプロジェクトでWEBアプリケーションを作っているなら、JavaBeanやStrutsのフォームクラスを
参考にするといいだろう。まあ、オブジェクト指向経験者にソースを見せてもらうのがいい。
4を実感するようになるには、個人差はあるが普通にプログラミングに携わっていれば、
半年～1年半と言う所だろう。
javaは継承の悪用が激しいから嫌だな。
入門書もろくなのねーし。情報も少ない。クラスで組ませるくせにインスタンスが見え難い。
オブジェクト指向以前にこの辺の環境が悪過ぎる。
流行りの分野ではあるけど何故か少ない情報もあってオススメしない。
入門書もろくなのねーし。情報も少ない。クラスで組ませるくせにインスタンスが見え難い。
オブジェクト指向以前にこの辺の環境が悪過ぎる。
流行りの分野ではあるけど何故か少ない情報もあってオススメしない。
Javaで情報が少ないなら、他のオブジェクト指向はカスばかりだな
BBSに講義調で書き込む人って
なに様のつもりなんだろう？
ちょっと不思議
なに様のつもりなんだろう？
ちょっと不思議
そういうキャラは嫌いじゃない。
つーか今の時代実際にいるのか。
外国の講義の翻訳のイメージしかないんだが。
つーか今の時代実際にいるのか。
外国の講義の翻訳のイメージしかないんだが。
ネタでやってると確信できれば
味のあるキャラなのかもしれんが
俺的には、マジで教師気取りの
痛い人にしか見えないんで、
ちょっと遠慮したいキャラだな。
味のあるキャラなのかもしれんが
俺的には、マジで教師気取りの
痛い人にしか見えないんで、
ちょっと遠慮したいキャラだな。
973 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/23(火) 22:15:39
974 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/23(火) 22:17:07
Ｂｅａｎって何をオブジェクトにしたんだろうか？
>>974
概念って言葉知ってる？
概念って言葉知ってる？
>>974
そりゃもう豆でしょうよ。
そりゃもう豆でしょうよ。
977 ：仕様書無しさん：2007/01/23(火) 23:03:30
本物の業務を想定したサンプルを設計図からコーディングまで誰か出版したら
一挙に普及するべ！！
誰かやれよ！！
一挙に普及するべ！！
誰かやれよ！！
>>977
家の本棚見回したら、それっぽいの何冊かあるけど。
家の本棚見回したら、それっぽいの何冊かあるけど。
憂鬱本の例もよくわからんしね。
憂鬱本ははじめの説明ででてきたＳＴＧの自機、敵、弾でぜひやってほしかった。
憂鬱本ははじめの説明ででてきたＳＴＧの自機、敵、弾でぜひやってほしかった。
>>957
全然原理主義者じゃないじゃん。いやリアリストでいいと思うけどさｗ
全然原理主義者じゃないじゃん。いやリアリストでいいと思うけどさｗ
>>961 >>966
おもしろい話だな。
個人的には、オブジェクト指向経験者ではなくともプログラム経験者なら
わかりやすいはずだと思うんだが、プログラムも未経験者となると、
たぶん「分からない」と返って来るんだろうな。
せっかく盛り上がっているんで次スレ要るんじゃない？
おもしろい話だな。
個人的には、オブジェクト指向経験者ではなくともプログラム経験者なら
わかりやすいはずだと思うんだが、プログラムも未経験者となると、
たぶん「分からない」と返って来るんだろうな。
せっかく盛り上がっているんで次スレ要るんじゃない？
昨日のクックの話を切り出した人って誰かわかったわ。
あまりにもタイムリーすぎる話の流れで。
今、寒いところで仕事している人でしょ。
あまりにもタイムリーすぎる話の流れで。
今、寒いところで仕事している人でしょ。
>>984
じゃよろしく
じゃよろしく
>>985
いや俺だけど東京ｗ
別にちょうどそういう問題にぶちあたったわけでもないｗ
JavaやC++のようなクラス志向をオブジェクト指向と定義してる
人が多いから気になっただけ。
JavaやC++をオブジェクト指向だけが目的の言語として、どうこう
言うのは間違ってると思ってるから言語批判ではないけどね。
いや俺だけど東京ｗ
別にちょうどそういう問題にぶちあたったわけでもないｗ
JavaやC++のようなクラス志向をオブジェクト指向と定義してる
人が多いから気になっただけ。
JavaやC++をオブジェクト指向だけが目的の言語として、どうこう
言うのは間違ってると思ってるから言語批判ではないけどね。
スレまでオブジェクト指向か。
ポリモーフィズム？
うめる？
993 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/01/24(水) 19:51:22
１０００ならオブジェクト指向壊滅
相変わらず暇そうだな＞ココ電
995 ：おじゃばさま：2007/01/24(水) 20:15:13
>964
では切腹の文化がプログラマに影響しているのかを考えてみよう。
まずは切腹の定義を明確にする必要がある。
はっきり言うと切腹の論理は分からないが、いくつかの種類があると思う。
1.悪い事をして切腹を強制される。
一番に思いつくのがこれだ。しかし切腹というより打ち首と判断した方がいいだろう。
2.主君の悪事を諌めるために、主君への忠告として切腹する。
これは闇奉行の最終回で主人公が主君の悪事を命をかけて止めた行為である。
常軌を逸した崇高な行為であるが、主君が無情だったら無駄死にになる危険度の高い行為である。
3.悪い事をしたが反省し、お詫びのために腹を切る。
いわゆる「死んで詫びる」である。1と違うのは強制されない点であろう。
他にもいろいろとありそうだが、きりがないのでこの辺りにしておこう。
ここで最も俺の「切腹」のイメージに近いのは、3番である。
ではこれをプログラマに当てはめてみよう。
では切腹の文化がプログラマに影響しているのかを考えてみよう。
まずは切腹の定義を明確にする必要がある。
はっきり言うと切腹の論理は分からないが、いくつかの種類があると思う。
1.悪い事をして切腹を強制される。
一番に思いつくのがこれだ。しかし切腹というより打ち首と判断した方がいいだろう。
2.主君の悪事を諌めるために、主君への忠告として切腹する。
これは闇奉行の最終回で主人公が主君の悪事を命をかけて止めた行為である。
常軌を逸した崇高な行為であるが、主君が無情だったら無駄死にになる危険度の高い行為である。
3.悪い事をしたが反省し、お詫びのために腹を切る。
いわゆる「死んで詫びる」である。1と違うのは強制されない点であろう。
他にもいろいろとありそうだが、きりがないのでこの辺りにしておこう。
ここで最も俺の「切腹」のイメージに近いのは、3番である。
ではこれをプログラマに当てはめてみよう。
996 ：おじゃばさま：2007/01/24(水) 20:26:04
ではいくつかの例をあげてみよう。
1.左遷
プロジェクトの予算が尽きると責任者は左遷される。
左遷は上司命令で、いわゆる打ち首に当たるため、切腹とは言えない。
2.過労死
プログラマのおける過労死は、精神的に追い詰められての自殺が多い。
冷静な判断力を失っているため切腹とは言えない。
3.自殺
プログラマにおける自殺は2と同様である。つまり切腹とは言えない。
4.バックレ
プログラマに残された正当な権利であるが、反省がない。つまり切腹とは言えない。
主だった物に該当する物はない。
では逆に切腹をプログラマ世界にアレンジしてみよう。
1.左遷
プロジェクトの予算が尽きると責任者は左遷される。
左遷は上司命令で、いわゆる打ち首に当たるため、切腹とは言えない。
2.過労死
プログラマのおける過労死は、精神的に追い詰められての自殺が多い。
冷静な判断力を失っているため切腹とは言えない。
3.自殺
プログラマにおける自殺は2と同様である。つまり切腹とは言えない。
4.バックレ
プログラマに残された正当な権利であるが、反省がない。つまり切腹とは言えない。
主だった物に該当する物はない。
では逆に切腹をプログラマ世界にアレンジしてみよう。
997 ：仕様書無しさん：2007/01/24(水) 21:35:17
ココ電が居ると聞いて市況からきました
ココ電バンザーイ
要らねぇからとっとと引き取れ屑
ﾇﾙ(･ω･)ﾎﾟﾘｰﾝ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。