●●ｵﾌﾞｼﾞｪｸﾄ設計は何故流行らないの？（2）●●
1 ：仕様書無しさん：
オブジェクト設計は何故、どうして流行しないのだろうか？
とても有益だと思うが？
このままでは、宝の持ち腐れです。
原因追求と対応を、ねらーでやろうじゃないですか。
という高邁な気持ちを持ってマターリ行きましょう。
とても有益だと思うが？
このままでは、宝の持ち腐れです。
原因追求と対応を、ねらーでやろうじゃないですか。
という高邁な気持ちを持ってマターリ行きましょう。
|
|
|
2 ：仕様書無しさん：2007/01/24(水) 01:14:48
あくまでマー版でやるわけだ。
マーが使えるようにならないと流行なんてしないものな。
マーが使えるようにならないと流行なんてしないものな。
コテ禁止
4 ：このスレは使用しません：2007/01/24(水) 15:44:46
・・・
いつの時代も体制に与しない自由な精神が新たな時代への道しるべとなってきた。
・・・
前スレより解放されし人々を惑わさんと偽りの重複スレ誘導がなされようと運命は我らに味方している。
見よ！>>1が記されし刻（とき）を！
「ををっ（兵士のどよめき）」
正義は我らにあり、正義は汝らにあり、
我らの敵すなわち汝らの敵をこの板より永久に滅っせよ！
いつの時代も体制に与しない自由な精神が新たな時代への道しるべとなってきた。
・・・
前スレより解放されし人々を惑わさんと偽りの重複スレ誘導がなされようと運命は我らに味方している。
見よ！>>1が記されし刻（とき）を！
「ををっ（兵士のどよめき）」
正義は我らにあり、正義は汝らにあり、
我らの敵すなわち汝らの敵をこの板より永久に滅っせよ！
6 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/01(木) 22:49:58
で、マルチメディアと ＡＩ と ファジー とＭＩＳはどこに捨ててきたんだ？
7 ：仕様書無しさん：2007/02/11(日) 01:06:47
これからはオブジェクト指向の時代だ。
君も勉強してるか？
それはそうと、何だねこのフローチャートは？
線が曲がってるじゃないか。
いいか、フローチャートの線1本1本を、心をこめて丁寧に引けば
バグなんか発生しないんだよ。
君も勉強してるか？
それはそうと、何だねこのフローチャートは？
線が曲がってるじゃないか。
いいか、フローチャートの線1本1本を、心をこめて丁寧に引けば
バグなんか発生しないんだよ。
今時フローチャートか？ｗ
ＵＭＬにはフローチャートの必要性説いてる？
関数レベルの話しで資料いらんよな？
結合レベルの資料のほうが有益だよな？
で、こんなもん書いてる馬鹿が未だにいたんだよな…
Ｈ系の前任者。
ＵＭＬにはフローチャートの必要性説いてる？
関数レベルの話しで資料いらんよな？
結合レベルの資料のほうが有益だよな？
で、こんなもん書いてる馬鹿が未だにいたんだよな…
Ｈ系の前任者。
答えが出ました。
「SQLが便利すぎるから」
だそうです。
「SQLが便利すぎるから」
だそうです。
確かにSQLは便利ではあるが、それは旧来の概念に基ずくもの。オブジェクト指向
のパラダイムとはミスマッチである。N+1セレクト問題が典型。
しかし旧来の考え方から抜けきれず、この便利さは代えがたいと考える人は多いし、
また今のところそれに置き換わりそうな技術も現れていない。
一時期オブジェクト指向データベースというものが脚光をあびかけたこともあったが、
それもほとんどみかけなくなった。一部が既存の製品にとりこまれたぐらいか。
暫くは便利さとミスマッチというジレンマを抱えながらＳＱＬとつきあっていくしかないの
かもしれない。
のパラダイムとはミスマッチである。N+1セレクト問題が典型。
しかし旧来の考え方から抜けきれず、この便利さは代えがたいと考える人は多いし、
また今のところそれに置き換わりそうな技術も現れていない。
一時期オブジェクト指向データベースというものが脚光をあびかけたこともあったが、
それもほとんどみかけなくなった。一部が既存の製品にとりこまれたぐらいか。
暫くは便利さとミスマッチというジレンマを抱えながらＳＱＬとつきあっていくしかないの
かもしれない。
階層化というツリー上の構造をもつオブジェクトを、２次元のマトリックスである
テーブルにマッピングしようというところに無理がある。
[上司]1 --- n◇[部下]っていう1:N の関係をJOINしたテーブルからいっぺんに
取得しようとすると、
[上司] [部下]
[山田部長][田中]
[山田部長][中村]
[山田部長][鈴木]
[山田部長][斉藤]
： ：
ってなんとも冗長なデータを扱うことになる。 それがいやなら、[山田部長]で
SELECT一回、そしてぶらさがる、各部下に対してSELECT発行するっていう形
態になる。部長が複数ならそれの繰り返しになる。
それに対して、クラス上では部下は単なる部下リストで表現されて、自由にアク
セスできる。処理の対象も特定の部下だったり、部下全員だったり。しかしＤＢ
と関連付けようとするとそのためのアクセス戦略をねらなければならない。特定
の部下だけが必要ならば、そもそも部下がリストである必要もなくなってくる。
このミスマッチをどう克服するかが、今後の課題だと思う。
テーブルにマッピングしようというところに無理がある。
[上司]1 --- n◇[部下]っていう1:N の関係をJOINしたテーブルからいっぺんに
取得しようとすると、
[上司] [部下]
[山田部長][田中]
[山田部長][中村]
[山田部長][鈴木]
[山田部長][斉藤]
： ：
ってなんとも冗長なデータを扱うことになる。 それがいやなら、[山田部長]で
SELECT一回、そしてぶらさがる、各部下に対してSELECT発行するっていう形
態になる。部長が複数ならそれの繰り返しになる。
それに対して、クラス上では部下は単なる部下リストで表現されて、自由にアク
セスできる。処理の対象も特定の部下だったり、部下全員だったり。しかしＤＢ
と関連付けようとするとそのためのアクセス戦略をねらなければならない。特定
の部下だけが必要ならば、そもそも部下がリストである必要もなくなってくる。
このミスマッチをどう克服するかが、今後の課題だと思う。
あぁ・・・
決まりごと、覚えることが多すぎて鬱だ
鉄骨ダッシュでも見よぅ
決まりごと、覚えることが多すぎて鬱だ
鉄骨ダッシュでも見よぅ
>>14 もちょっと読んでみろ。
俺は「そして２人は服を脱ぎ・・・」のとこでティシュとりにいった。
俺は「そして２人は服を脱ぎ・・・」のとこでティシュとりにいった。
ORマッピングすればいいじゃん
社員テーブルに社員区分とかの弁別子カラムもつか
別テーブルに分けるかすれば課長オブジェクトも平社員オブジェクトは格納可能。
ていうかここまでくるとORMスレいけって感じだな。
このスレ的には必要性が理解できればOKだろ。
社員テーブルに社員区分とかの弁別子カラムもつか
別テーブルに分けるかすれば課長オブジェクトも平社員オブジェクトは格納可能。
ていうかここまでくるとORMスレいけって感じだな。
このスレ的には必要性が理解できればOKだろ。
お勧めの本きぼ
>>18 山田部長がいっぱい
これって
社員
｛
上司
List 部下
｝
ってクラスつくってDBからとってきた値を入れれば良いだけじゃないの？
何処が問題なのかわからん？
社員
｛
上司
List 部下
｝
ってクラスつくってDBからとってきた値を入れれば良いだけじゃないの？
何処が問題なのかわからん？
>>20 ちょ、なんだよそのクラス設計
上司が窓際だな
>>23 つ N+1セレクト問題。
ま、なんにしても少しスレ違いかもな。
ま、なんにしても少しスレ違いかもな。
問題ありすぎ
>>28
N:1等の構造の表現がObjectとDB間で出来ないのが問題だったんじゃないの。
そこで、適切な構造のクラスを作ってレコードを落とし込めば無問題といいたいんだが。
RecordSetだと構造が現せないなじゃん
N:1等の構造の表現がObjectとDB間で出来ないのが問題だったんじゃないの。
そこで、適切な構造のクラスを作ってレコードを落とし込めば無問題といいたいんだが。
RecordSetだと構造が現せないなじゃん
どこにも構造の表現ができないとは書いてないんだが
特に問題はない、ただ余計な手間と無駄が生じるというだけ。
もういいよ、スレ違いだから。
もういいよ、スレ違いだから。
35 ：仕様書無しさん：2007/02/19(月) 19:47:24
実装をどーするかなんて瑣末な話を設計スレでするなよ。
なんでインタフェースから設計してくって発想が無いかな
なんでインタフェースから設計してくって発想が無いかな
インタフェースから設計してく？
永続化クラスにインタフェースつけるのか？
画面から見て必要な機能でIF切るなら分かるが、そのIFの内部実装をOOでやるか手続きでやるかは自由だろ？
このスレは内部をOOで設計する方法について語るスレじゃなかったのか？
永続化クラスにインタフェースつけるのか？
画面から見て必要な機能でIF切るなら分かるが、そのIFの内部実装をOOでやるか手続きでやるかは自由だろ？
このスレは内部をOOで設計する方法について語るスレじゃなかったのか？
38 ：仕様書無しさん：2007/02/20(火) 00:22:09
くそっ、前ｽﾚと全然雰囲気が違うぞ
全然話についていけねーや
とりあえず前の仕事では
SQL発行して、階層構造のARRAYクラスに入れていたよ
小計とかも全部そのクラスに実装していた
出力はＶＢＲｅｐｏｒｔだったかな（Ｅｘｃｅｌに落とせる奴
シーゲートの製品だったかな）
全然話についていけねーや
とりあえず前の仕事では
SQL発行して、階層構造のARRAYクラスに入れていたよ
小計とかも全部そのクラスに実装していた
出力はＶＢＲｅｐｏｒｔだったかな（Ｅｘｃｅｌに落とせる奴
シーゲートの製品だったかな）
>>38
階層構造のArrayクラスについてkwsk。
階層構造のArrayクラスについてkwsk。
40 ：仕様書無しさん：2007/02/20(火) 00:32:34
ＯＯ厨 弟ｗ
41 ：仕様書無しさん：2007/02/20(火) 00:55:43
すまんですが
こっちのスレに統一お願いしますです。
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
このスレを始めた”真面目なネラー”ですが、ｵﾌﾞｼﾞｪｸﾄ指向開発が日常茶飯事に早くなってもらいたいです。
こっちのスレに統一お願いしますです。
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
このスレを始めた”真面目なネラー”ですが、ｵﾌﾞｼﾞｪｸﾄ指向開発が日常茶飯事に早くなってもらいたいです。
42 ：仕様書無しさん：2007/02/20(火) 01:21:32
このｽﾚは終了しました。
再利用しろよ馬鹿
スパイラルで破棄に決まってんだろ
エコ主義の前ではそんな横暴は認めん
似たようなクラスを再生成するな。
それは当然のことだ
しかしあるものは有効利用せねばならん
しかしあるものは有効利用せねばならん
無駄ｽﾚ終了
工エエェェ(´д｀)ェェエエ工
52 ：仕様書無しさん：2007/02/20(火) 02:20:31
53 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/02/24(土) 23:28:49
しかしライブラリ全部覚えとくのって大変
失せろ糞コテ
56 ：仕様書無しさん：2007/03/11(日) 13:28:33
ＯＯ厨 隠し子w
しかし、マジで、デザパタ＝クラス設計レベルのノウハウ と思ってるのか？
とんでもない勘違いだぞ。
とんでもない勘違いだぞ。
58 ：仕様書無しさん：2007/04/28(土) 23:36:16
負け犬必死ｗ
早く代案出せこのバカチョン
早く代案出せこのバカチョン
■Suisui解任動議 今現在
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 27 (42.2%)
解任反対 : 37 (57.8%)
票差 : 10 / 合計: 64
賛成票が増えて42%になりました。
もし反対票がなければ、あと11票（8%超）の賛成票が集まればsuisuiは解任になります。
■投票期限まで あと 4 日
投票期日 : 2007年5月2日 (水) 00:02 (UTC) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）
彼を解任させたいかさせたくないかを考えるまであと4日あります。
議論まとめページを良く読んでじっくり考えましょう。
■以下の条件を満たさなければ投票することはできませんので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ プログラマのWikipedia ウィキペディア
http://pc11.2ch.net/test/read.cgi/prog/1177487026/
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 27 (42.2%)
解任反対 : 37 (57.8%)
票差 : 10 / 合計: 64
賛成票が増えて42%になりました。
もし反対票がなければ、あと11票（8%超）の賛成票が集まればsuisuiは解任になります。
■投票期限まで あと 4 日
投票期日 : 2007年5月2日 (水) 00:02 (UTC) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）
彼を解任させたいかさせたくないかを考えるまであと4日あります。
議論まとめページを良く読んでじっくり考えましょう。
■以下の条件を満たさなければ投票することはできませんので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ プログラマのWikipedia ウィキペディア
http://pc11.2ch.net/test/read.cgi/prog/1177487026/
デザパタはカタログであって、戦術ではない。
■Suisui（今泉 誠）解任動議 今現在
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 32 (42.1%)
解任反対 : 44 (57.9%)
票差 : 12 / 合計: 76
今後、13票以上の解任賛成票が投じられない限り、Suisuiの留任は保証されます。
■投票期限まであと50時間を切りました。
投票期日 : 2007年5月2日 (水) 00:02 (協定世界時) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）
広域ブロック、対話拒否で批判されている彼を留任させるべきか、そうでないかを考えるまであとおよそ50時間近くあります。議論まとめページを良く読んでじっくり考えましょう。
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui/%E8%AD%B0%E8%AB%96%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%9F%E3%83%9A%E3%83%BC%E3%82%B8
■以下の条件を満たさなければ無効票になりますので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ 【百科事典】ウィキペディア第i386刷【Wikipedia】
http://hobby9.2ch.net/test/read.cgi/hobby/1177830010/
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui_20070421#.E8.A7.A3.E4.BB.BB.E3.81.AB.E8.B3.9B.E6.88.90_.28Demand_the_resignation_of_the_sysop.29
解任賛成 : 32 (42.1%)
解任反対 : 44 (57.9%)
票差 : 12 / 合計: 76
今後、13票以上の解任賛成票が投じられない限り、Suisuiの留任は保証されます。
■投票期限まであと50時間を切りました。
投票期日 : 2007年5月2日 (水) 00:02 (協定世界時) まで
（注意！ : 日本時間では2007年5月2日 (水) 09:02 までが投票期日となります！）
広域ブロック、対話拒否で批判されている彼を留任させるべきか、そうでないかを考えるまであとおよそ50時間近くあります。議論まとめページを良く読んでじっくり考えましょう。
http://ja.wikipedia.org/wiki/Wikipedia:%E7%AE%A1%E7%90%86%E8%80%85%E3%81%AE%E8%A7%A3%E4%BB%BB/Suisui/%E8%AD%B0%E8%AB%96%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%9F%E3%83%9A%E3%83%BC%E3%82%B8
■以下の条件を満たさなければ無効票になりますので注意して下さい。
* 初めて編集した時から動議提出時までに1ヶ月以上を経過していること。
* その間、標準名前空間を50回以上編集し、
* 動議提出時から遡って直近1ヶ月の標準名前空間編集回数が5回以上あること。
■なお、この解任は、彼をメタウィキのスチュワードという
役職から解任させるものではありません。
日本ウィキペディアでの管理者という役職を解任させる是非を問うものです。
2chでのデマに惑わされないよう要注意して下さい。
■関連スレ 【百科事典】ウィキペディア第i386刷【Wikipedia】
http://hobby9.2ch.net/test/read.cgi/hobby/1177830010/
仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。
変化を抱擁せよ
test
12345678901234567890
あいうえおかきくけこ
iiiiiiiiiiiiiiiiiiii
12345678901234567890
あいうえおかきくけこ
iiiiiiiiiiiiiiiiiiii
66 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/08(火) 22:37:45
明治初期のお話
若いのが「文明開化だああ」って叫びながら家に下駄で上がりこんで
仏壇を蹴倒すのが流行った。
オブジェクト指向も同じものだとつくづく思うのであった。
若いのが「文明開化だああ」って叫びながら家に下駄で上がりこんで
仏壇を蹴倒すのが流行った。
オブジェクト指向も同じものだとつくづく思うのであった。
67 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/08(火) 22:42:18
補足知識
・下駄 明治時代は新しいものだった。
・仏壇蹴倒す 廃仏毀釈という当時のナウい思想にのっていた。
・土足で上がりこむ 欧米式にのっとって玄関で靴を脱がない。
一見狂ったように見えるが、本人にはそれなりの理由があるのであった。
・下駄 明治時代は新しいものだった。
・仏壇蹴倒す 廃仏毀釈という当時のナウい思想にのっていた。
・土足で上がりこむ 欧米式にのっとって玄関で靴を脱がない。
一見狂ったように見えるが、本人にはそれなりの理由があるのであった。
この局面で
温故知新
という言葉は有効かな？
温故知新
という言葉は有効かな？
有効だよ。
俺はどんな場面でも有効だと思っている
俺はどんな場面でも有効だと思っている
70 ：仕様書無しさん：2007/05/16(水) 22:37:39
落っこちてたからあげとく。資源を大切に。
71 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/16(水) 23:35:46
とりあえずこっちのスレッドを使っておくか。
>電球
まず生産性が悪い会社があるのは認めよう。しかし生産性の悪い会社は一般的には「大手ベンダー」だ。
大手ベンダーでは担当が0.5Kなどと言う所もざらにある。
ここで気をつけなければならないのは、人件費を削るしか頭にない経営者は人数を減らすと言う事だ。
「品質を落として生産性を上げる」のが「人件費を削るしか頭にない経営者」。
生産性を下げたら人件費が増してしまう。当然だろう？
>電球
まず生産性が悪い会社があるのは認めよう。しかし生産性の悪い会社は一般的には「大手ベンダー」だ。
大手ベンダーでは担当が0.5Kなどと言う所もざらにある。
ここで気をつけなければならないのは、人件費を削るしか頭にない経営者は人数を減らすと言う事だ。
「品質を落として生産性を上げる」のが「人件費を削るしか頭にない経営者」。
生産性を下げたら人件費が増してしまう。当然だろう？
「品質を落として生産性を上げる」って矛盾してないか、普通、品質が落ちる
ほど生産性も下がってくだろ。テスト通らないんだから当然だろ。
もしそれで生産性が上がったとしたら、それを虚偽の生産性という。
ほど生産性も下がってくだろ。テスト通らないんだから当然だろ。
もしそれで生産性が上がったとしたら、それを虚偽の生産性という。
おじゃばが言いたいのは、品質基準を下げるとか、
表に見えにくい部分の実装を省いて手抜きするいう意味じゃなかろうか、
想像だが。
表に見えにくい部分の実装を省いて手抜きするいう意味じゃなかろうか、
想像だが。
74 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/17(木) 00:01:24
>電球
ちなみに1K当たりの単体試験項目数と、結合試験項目数を教えてくれ。
試験項目表は書いているよな？これでどの程度の品質なのか予想がつく。
>72,73
人件費を削るしか頭にない経営者は、虚偽の生産性を上げると言っている。
ちなみに1K当たりの単体試験項目数と、結合試験項目数を教えてくれ。
試験項目表は書いているよな？これでどの程度の品質なのか予想がつく。
>72,73
人件費を削るしか頭にない経営者は、虚偽の生産性を上げると言っている。
それは生産性が上がったとは言わない。ただ仕様や機能が削られただけ。
>>72
>もしそれで生産性が上がったとしたら、それを虚偽の生産性という。
品質を上げる方法って、要するにテストをどれだけやるかって話だろ？
でも、テストに時間を割けば割くほど、その他の作業にかけられる時間が
少なくなるから生産性が落ちるのは当たり前。
それともテストに掛けるべき時間には上限値があるとでも思っているの？
１００％完璧なテストを行うことができるとでも？
>もしそれで生産性が上がったとしたら、それを虚偽の生産性という。
品質を上げる方法って、要するにテストをどれだけやるかって話だろ？
でも、テストに時間を割けば割くほど、その他の作業にかけられる時間が
少なくなるから生産性が落ちるのは当たり前。
それともテストに掛けるべき時間には上限値があるとでも思っているの？
１００％完璧なテストを行うことができるとでも？
>品質を上げる方法って、要するにテストをどれだけやるかって話だろ？
これが成立するのは実装段階以降に限るのだが
これが成立するのは実装段階以降に限るのだが
テスト仕様書に記載されたテストを終えて検収が終わるまでは完了じゃない。
少なくともうちではそうだが。テスト仕様書の網羅性、完璧性は別の話。
少なくともうちではそうだが。テスト仕様書の網羅性、完璧性は別の話。
生産性ってさ、何を指している？
記述したソースコードの量/時間 ？
検収をパスした機能/時間 ?
正しくは
売り上げ/時間
なんだけど...
記述したソースコードの量/時間 ？
検収をパスした機能/時間 ?
正しくは
売り上げ/時間
なんだけど...
「品質のクリア」についてその背景の考え方を詳しくお願いしたい。
生産性って単純に時間当たりの生産量のことだろ？ でこの場合の生産がなにか
というと、決められた仕様のシステムを作り上げることで、品質が悪いってこと
は、つまり仕様を満たしてないってことじゃないの？ それとも仕様も自分達だ
けで決めてんの？生産の定義を自分達で変えられるんだったら、そりゃ生産性も
変えられるわな。
というと、決められた仕様のシステムを作り上げることで、品質が悪いってこと
は、つまり仕様を満たしてないってことじゃないの？ それとも仕様も自分達だ
けで決めてんの？生産の定義を自分達で変えられるんだったら、そりゃ生産性も
変えられるわな。
品質 = 買い手からみて許せるかどうか、じゃね？
あんなに頻繁にクラッシュするソフトなのに、でも許されてるマイク□ソフトw
「いー仕事してますね」的な日本のものはたいていオーバークオリティだYo
まぁあまり見かけないけどね
あんなに頻繁にクラッシュするソフトなのに、でも許されてるマイク□ソフトw
「いー仕事してますね」的な日本のものはたいていオーバークオリティだYo
まぁあまり見かけないけどね
>83 実際に金に変えられないなら、無駄を作りこんでいるだけ
(いわゆる罪庫)
そんな基準で満足してるようじゃどう見ても底辺いつまでも乙ですありがとうございましたってことだ
(いわゆる罪庫)
そんな基準で満足してるようじゃどう見ても底辺いつまでも乙ですありがとうございましたってことだ
>>83
>つまり仕様を満たしてないってことじゃないの？
仕様を満たしているかどうかは、結局テストで確認するんだろ？
でも、どんなテストでも「本当に」仕様を満たしているかは
分からない。
もちろん、仕様に「・・・のテストに全て合格する事」
と書いてある場合もあるが、それはタテマエに過ぎない。
たまたまテストに合格して、いざ運用したらコケてしまった、
なんて時に、怒らない客なんている筈がない。
>つまり仕様を満たしてないってことじゃないの？
仕様を満たしているかどうかは、結局テストで確認するんだろ？
でも、どんなテストでも「本当に」仕様を満たしているかは
分からない。
もちろん、仕様に「・・・のテストに全て合格する事」
と書いてある場合もあるが、それはタテマエに過ぎない。
たまたまテストに合格して、いざ運用したらコケてしまった、
なんて時に、怒らない客なんている筈がない。
大抵のオブジェクト設計が必要なシステムは
設計以前の問題を抱えているからな．．．
政治的な駆け引きとか、スキルのある人員とか
納期と金額とか．．．
設計以前の問題を抱えているからな．．．
政治的な駆け引きとか、スキルのある人員とか
納期と金額とか．．．
意味がよく分からんが、品質悪いもので金に換えられるとしたら、そっちの方が歪んでるだろ。客が馬鹿か、単なるラッキーか。何にしろ正常じゃない。
ま、金だけが全ての奴には関係無いのかもしらんが。
ま、金だけが全ての奴には関係無いのかもしらんが。
> 客が馬鹿か、単なるラッキーか。
宗教かもw
宗教かもw
>>86 まともなテスト仕様書書いたことないだろ？
確かにテスト仕様書に全てが網羅できるとは思わないが、少なくとも仕様として
文書化され合意を得たものについては、全て記載する。納品物ということもある
が自分達を守るための最低限の証拠にもなる。
確かにテスト仕様書に全てが網羅できるとは思わないが、少なくとも仕様として
文書化され合意を得たものについては、全て記載する。納品物ということもある
が自分達を守るための最低限の証拠にもなる。
>>90
>少なくとも仕様として
>文書化され合意を得たものについては、全て記載する。
だから何？
客が求めている事（ここでは「仕様を満たす」と同義語として扱う）は、
「テストに合格する」ことじゃない。
「運用で支障が発生しないこと」だろ？
>少なくとも仕様として
>文書化され合意を得たものについては、全て記載する。
だから何？
客が求めている事（ここでは「仕様を満たす」と同義語として扱う）は、
「テストに合格する」ことじゃない。
「運用で支障が発生しないこと」だろ？
経営者視点、営業視点だとお金かもしらんが、技術者視点から見た生産性は
やっぱり品質も満たしてこそだと思うが。
やっぱり品質も満たしてこそだと思うが。
93 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 01:03:45
市場法則が働くのなら品質が低いものは安くなるので企業の生産性は下がる
>>91
「運用で支障が発生しないこと」をどうやって保証すんだよ？
それに限りなく近づけるためのテスト仕様書でありテストだろうが。
運用で支障が発生するってことは、想定外の原因か、テスト仕様書の
記載漏れということになる。
「運用で支障が発生しないこと」をどうやって保証すんだよ？
それに限りなく近づけるためのテスト仕様書でありテストだろうが。
運用で支障が発生するってことは、想定外の原因か、テスト仕様書の
記載漏れということになる。
あ、あとテスターの手抜きという可能性もあるが、これは論外。
97 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 01:06:46
そーだ
フローチャートだと全ての分岐を塗りつぶしていけば条件のテストは終了にできる。
経路で他の変数を引きずらないように、各処理単位で独立するように書く必要があるが
フローチャートだと全ての分岐を塗りつぶしていけば条件のテストは終了にできる。
経路で他の変数を引きずらないように、各処理単位で独立するように書く必要があるが
98 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 01:11:48
プログラムのバグよりコミュニケーションのバグのほうが多いけどなあ。
よおっく確認しようとすると嫌がる人とか、時間を合わせて更新する事を忘れちゃう人とか
よおっく確認しようとすると嫌がる人とか、時間を合わせて更新する事を忘れちゃう人とか
>>95
>「運用で支障が発生しないこと」をどうやって保証すんだよ？
>それに限りなく近づけるためのテスト仕様書でありテストだろうが。
だから、最初から「テストは完全な品質の保証とはならない」と
言っているつもりだが？
>「運用で支障が発生しないこと」をどうやって保証すんだよ？
>それに限りなく近づけるためのテスト仕様書でありテストだろうが。
だから、最初から「テストは完全な品質の保証とはならない」と
言っているつもりだが？
うちでは、最低限、メソッド単位のINとOUTのパターンの網羅、境界値、限界値の
検査はやってる。自然とメソッドの粒度が細かくなり、目的が明確になって、
コードもきれいになる。
検査はやってる。自然とメソッドの粒度が細かくなり、目的が明確になって、
コードもきれいになる。
飽きた。寝る。おやすみ。
参照透明とかそういうのわかんないでコード書いてる奴ばっかなのに、
テストばっかり頑張ったっムダだな
テストばっかり頑張ったっムダだな
仕様があればテストはできる。
仕様にバグがあればテストは無駄な作業
>>103
下らない事聞かないの
下らない事聞かないの
>>105
ちょw 仕様のバグが無駄にするのはテストだけじゃないぞ、と。
ちょw 仕様のバグが無駄にするのはテストだけじゃないぞ、と。
>オブジェクト設計は何故、どうして流行しないのだろうか？
もう十分流行してるのでは？
>原因追求と対応
いわゆるOOP言語ばっか、そゆこと
もう十分流行してるのでは？
>原因追求と対応
いわゆるOOP言語ばっか、そゆこと
テスト仕様書が書けない場合は、大概、仕様が理解できていないか、
仕様の検討が不十分か、それがちゃんと文書化されてない、または
周知されてないか、だ。
テストファーストの有効性はその洗い出しを早期にでき、全体の意識
合わせをしやすいことにもある。必然的に品質も生産性も上がる。
仕様の検討が不十分か、それがちゃんと文書化されてない、または
周知されてないか、だ。
テストファーストの有効性はその洗い出しを早期にでき、全体の意識
合わせをしやすいことにもある。必然的に品質も生産性も上がる。
111 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/17(木) 11:45:49
単体試験では、プログラムがプログラマの思った通りに動作するかチェックする。
普通は、全分岐の検証、入出力パターンと上限値下限値チェックを行う。
「入出力パターンと上限値下限値」しかやらない所も多いが、これでは業務用としては最低限の品質だ。
大手ベンダーでは、（実際に実行されているかは別として）全分岐の試験を行う事になっている。
恐ろしい事に、単体試験をやらない所もある。ただこれは実際には会社の規模にかかわらず存在する。
いかに素晴らしい試験実施基準が指定されていても、やらない人やごまかす人は出て来る。
結合試験では、プログラムが機能設計を満たしているか検証する。
普通は、機能仕様書や操作説明書に記述されている機能が、全て満たされていて動作するかチェックする。
普通は全画面の入出力・遷移チェック、一連の正常動作チェック、入出力エラーチェックなどを行う。
恐ろしい事に、これしかやらない所も存在する。
総合試験では、実際の運用を想定した試験を行う。
普通は、運用試験（インストールから日々の業務、月次処理まで）、高負荷試験、連続稼働試験などを行う。
プログラマが実際に行うと言うより、現場の人や保守部隊が行うので、プログラム品質とは少々違う。
ただ問題が発生したら、修正するのはPGだが。
規模の大小はあれ、これが一般的なテスト手順だ。
これをちゃんと行っていれば、みんなが指摘していた問題はほぼ解消された品質になるはずだ。
で、みんなの所の「1K当たりの単体試験項目数と結合試験項目数」はいくつ？
普通は、全分岐の検証、入出力パターンと上限値下限値チェックを行う。
「入出力パターンと上限値下限値」しかやらない所も多いが、これでは業務用としては最低限の品質だ。
大手ベンダーでは、（実際に実行されているかは別として）全分岐の試験を行う事になっている。
恐ろしい事に、単体試験をやらない所もある。ただこれは実際には会社の規模にかかわらず存在する。
いかに素晴らしい試験実施基準が指定されていても、やらない人やごまかす人は出て来る。
結合試験では、プログラムが機能設計を満たしているか検証する。
普通は、機能仕様書や操作説明書に記述されている機能が、全て満たされていて動作するかチェックする。
普通は全画面の入出力・遷移チェック、一連の正常動作チェック、入出力エラーチェックなどを行う。
恐ろしい事に、これしかやらない所も存在する。
総合試験では、実際の運用を想定した試験を行う。
普通は、運用試験（インストールから日々の業務、月次処理まで）、高負荷試験、連続稼働試験などを行う。
プログラマが実際に行うと言うより、現場の人や保守部隊が行うので、プログラム品質とは少々違う。
ただ問題が発生したら、修正するのはPGだが。
規模の大小はあれ、これが一般的なテスト手順だ。
これをちゃんと行っていれば、みんなが指摘していた問題はほぼ解消された品質になるはずだ。
で、みんなの所の「1K当たりの単体試験項目数と結合試験項目数」はいくつ？
する、行う。だけで相手を納得させようってのが間違い。
どこが間違いか、どこがひどいか具体的に書かずに断定する奴も同類に見えるが。
OOでもＷＦの用語を使うのかね？
×単体試験では、プログラムがプログラマの思った通りに動作するかチェックする。
○単体試験は、プログラムが機能仕様書を満たしていないことを発見する工程である。
あるケースが機能仕様書を満たしていることを確認できた場合、「その試験ケースは失敗した」と称される。
×結合試験では、プログラムが機能設計を満たしているか検証する。
○結合試験では、その名の通り、プログラム間のインターフェースを確認する。
（この段階でプログラム間のインターフェース設計にバグが存在することがままあるが、それはまた別のはなし）
（試験一般に言えることだが、）
試験はプログラムの正当性を確認する工程ではない。
試験はプログラムの不当性を発見するための工程である。
×単体試験では、プログラムがプログラマの思った通りに動作するかチェックする。
○単体試験は、プログラムが機能仕様書を満たしていないことを発見する工程である。
あるケースが機能仕様書を満たしていることを確認できた場合、「その試験ケースは失敗した」と称される。
×結合試験では、プログラムが機能設計を満たしているか検証する。
○結合試験では、その名の通り、プログラム間のインターフェースを確認する。
（この段階でプログラム間のインターフェース設計にバグが存在することがままあるが、それはまた別のはなし）
（試験一般に言えることだが、）
試験はプログラムの正当性を確認する工程ではない。
試験はプログラムの不当性を発見するための工程である。
116 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 19:11:26
オブジェクト指向だと分岐試験できないじゃん
∧∧
（ ･ω･） …
＿| ⊃／(＿＿_
／ └-(＿＿＿_／
￣￣￣￣￣￣￣
＿＿＿＿＿＿＿＿＿＿_
∧∧ 。o ○ ..分岐試験 ﾑﾆｬﾑﾆｬ...〕
（ -ω -） ￣￣￣￣￣￣￣￣￣￣~
＿| ⊃／(＿＿_
／ └-(＿＿＿_／
￣￣￣￣￣￣￣
＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
（ ･ω･） …
＿| ⊃／(＿＿_
／ └-(＿＿＿_／
￣￣￣￣￣￣￣
＿＿＿＿＿＿＿＿＿＿_
∧∧ 。o ○ ..分岐試験 ﾑﾆｬﾑﾆｬ...〕
（ -ω -） ￣￣￣￣￣￣￣￣￣￣~
＿| ⊃／(＿＿_
／ └-(＿＿＿_／
￣￣￣￣￣￣￣
＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
>>116
できるって。Mockとか知ってっか？
できるって。Mockとか知ってっか？
119 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/17(木) 20:24:06
>115
単体試験は「機能仕様書を満たしているか」の試験ではない。
仕様書レベルで言うと「詳細設計書を満たしているか」になるが、最近は詳細設計書を作らない事も多いので、
プログラマの意図通りに動くかの検証となる。
結合試験は外部IFの試験だけではない。外部IFの試験は結合試験の「一部」に過ぎない。
115の認識で言うと、試験内容が全く足りない。
もし仮に115が115の言う「単体試験」と「結合試験」しかやっていないとしたら、
俺の言う所の「結合試験しかやらない人」になる。ちなみにそういう人も結構いる。
ただこれでは捏造しない限り、大手ベンダーの品質監査は通らない。
大手ベンダーの品質基準は、部署やプロジェクトによって開きはあるが、
大体、単体試験項目数100件／Kstep、結合試験20件／kstepぐらいである。
単体試験は「機能仕様書を満たしているか」の試験ではない。
仕様書レベルで言うと「詳細設計書を満たしているか」になるが、最近は詳細設計書を作らない事も多いので、
プログラマの意図通りに動くかの検証となる。
結合試験は外部IFの試験だけではない。外部IFの試験は結合試験の「一部」に過ぎない。
115の認識で言うと、試験内容が全く足りない。
もし仮に115が115の言う「単体試験」と「結合試験」しかやっていないとしたら、
俺の言う所の「結合試験しかやらない人」になる。ちなみにそういう人も結構いる。
ただこれでは捏造しない限り、大手ベンダーの品質監査は通らない。
大手ベンダーの品質基準は、部署やプロジェクトによって開きはあるが、
大体、単体試験項目数100件／Kstep、結合試験20件／kstepぐらいである。
120 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/17(木) 20:35:38
全分岐確認試験はデバッカを使用する。EclipseやVC++、gdbなどを使用して効率を高める。
しかし分岐試験で重要なのは、試験項目表を書く事である。全分岐を確認しながら考える事で、
多くの矛盾や問題を発見出来る。残念ながらここを自動化することは出来ない。
これを行い修正する事によって、かなりソースコードが整理される。
試験項目表を書く事によって、単体試験の目的の半分は達成されたと考えて良い。
ちなみに「全分岐試験をやれ」と言われて、「そんなのやった事もないし、聞いた事もない」と
逆切れしている人がごくたまにいるが、そういう人には仕事を頼まないのが賢明である。
しかし分岐試験で重要なのは、試験項目表を書く事である。全分岐を確認しながら考える事で、
多くの矛盾や問題を発見出来る。残念ながらここを自動化することは出来ない。
これを行い修正する事によって、かなりソースコードが整理される。
試験項目表を書く事によって、単体試験の目的の半分は達成されたと考えて良い。
ちなみに「全分岐試験をやれ」と言われて、「そんなのやった事もないし、聞いた事もない」と
逆切れしている人がごくたまにいるが、そういう人には仕事を頼まないのが賢明である。
なんつーかキミって視野狭いね
自分の価値観押しつけてるだけぽ
自分の価値観押しつけてるだけぽ
122 ：仕様書無しさん：2007/05/17(木) 20:46:38
>>121
常識じゃまいか？ 少し教科書的過ぎるから読んでいて退屈だけど。
問題は、そこまで品質を高めておいて、なぜ市場で問題が出るのか、とか
期間的に厳しい場合は、どこで品質を保つのか、とかなんだけどね。
常識じゃまいか？ 少し教科書的過ぎるから読んでいて退屈だけど。
問題は、そこまで品質を高めておいて、なぜ市場で問題が出るのか、とか
期間的に厳しい場合は、どこで品質を保つのか、とかなんだけどね。
>121
ご指摘のとおり。彼のレスは、
自分の周りの規定事項と、本で読んだ知識と、品質管理レベルにおける自己の判断の全てを
正しいものとして並べて書いているから、
「彼の視野の狭さを読み取れる人」以外には有害なレスなのです。
しかしながら彼は自分の正しさを信じて疑いません。
彼がたずねる事項すべてが、他の現場の現状に関する事項しかないのがこの証拠です。
大手ベンダーで仕事をしているようですが「井の中の蛙」的な人物かと
ご指摘のとおり。彼のレスは、
自分の周りの規定事項と、本で読んだ知識と、品質管理レベルにおける自己の判断の全てを
正しいものとして並べて書いているから、
「彼の視野の狭さを読み取れる人」以外には有害なレスなのです。
しかしながら彼は自分の正しさを信じて疑いません。
彼がたずねる事項すべてが、他の現場の現状に関する事項しかないのがこの証拠です。
大手ベンダーで仕事をしているようですが「井の中の蛙」的な人物かと
>>119-120
「プログラマの意図通りに動くかの検証」って、また随分主観的で曖昧なものを検査するんだな。
それだと、プログラマが仕様の意味を取り違えてても試験は通っちゃうじゃねぇか。
普通、テスト仕様書にはプログラマの意図なんか書かないぞ。あくまで、仕様を満たしているかどうか
を検査するためのものだ。そのためにはプログラムを製造する人とはテスト仕様書を書く人は分けた方
がいい。
あと、わざわざデバッガなんか使って目視するより、テストデータ揃えてJUnitなんかのテストツール使った方が正確だし、再利用できるから便利。
「プログラマの意図通りに動くかの検証」って、また随分主観的で曖昧なものを検査するんだな。
それだと、プログラマが仕様の意味を取り違えてても試験は通っちゃうじゃねぇか。
普通、テスト仕様書にはプログラマの意図なんか書かないぞ。あくまで、仕様を満たしているかどうか
を検査するためのものだ。そのためにはプログラムを製造する人とはテスト仕様書を書く人は分けた方
がいい。
あと、わざわざデバッガなんか使って目視するより、テストデータ揃えてJUnitなんかのテストツール使った方が正確だし、再利用できるから便利。
>>124
彼のいる職場ではああいう慣習らしい
彼のいる職場ではああいう慣習らしい
126 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 23:54:00
>>118
また他分野からの盗用かよ
また他分野からの盗用かよ
127 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 23:54:51
設計書に分岐無いんだろ？
どうすんだよ
どうすんだよ
128 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/17(木) 23:55:55
試験のためにフローチャート描きます。
UML厨は自滅しますね。
UML厨は自滅しますね。
分岐無いって纏め方はヒデェ。
UMLにゃアクティビティ図があるゼ。
UMLにゃアクティビティ図があるゼ。
皆さんは
たった二行のわりにアホ臭満載のレスを連投するアホコテと
ひたすら冗長なわりに間が抜けたレスを投下するアホコテと
どちらがいいですか
たった二行のわりにアホ臭満載のレスを連投するアホコテと
ひたすら冗長なわりに間が抜けたレスを投下するアホコテと
どちらがいいですか
131 ：仕様書無しさん：2007/05/18(金) 00:12:13
もう一度オブジェクト指向使っちゃうとやめられんね。
ズラズラと書かれると読むのめんどくさい
ズラズラと書かれると読むのめんどくさい
132 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/18(金) 00:39:59
そのまえに文字列はCStringで統一しよう。（C++のばやい）
ここらへんから始めた方がよくないか？
ここらへんから始めた方がよくないか？
それもばやいによりけりだな
> 文字列はCStringで統一しよう
症例名： 基本データ型への執着
症状：
基本データ型を使っているがいつも対になる操作のセットがある
基本データ型を使っているがいつもそれで条件判断をしている
治療法：
* データをオブジェクト化する
症例名： 基本データ型への執着
症状：
基本データ型を使っているがいつも対になる操作のセットがある
基本データ型を使っているがいつもそれで条件判断をしている
治療法：
* データをオブジェクト化する
CStringって基本データ型か？
136 ：仕様書無しさん：2007/05/18(金) 01:24:29
CStringはMFCの文字列で
C++の文字列はstring
C++の文字列はstring
137 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/18(金) 01:30:34
ああそうだったVCね
char*
std::string
CString
ごっちゃで書かれても困る。
char*
std::string
CString
ごっちゃで書かれても困る。
前提を示さない症
>>135
VCでchar使ってる奴はCStringクラス使え、っていう意見の後押しじゃねぇの？
VCでchar使ってる奴はCStringクラス使え、っていう意見の後押しじゃねぇの？
>>137
重要な文字列型にはもう一つあるだろ CComBSTR とその周辺も忘れるな
重要な文字列型にはもう一つあるだろ CComBSTR とその周辺も忘れるな
文字列にはエンコードの問題もつきまとうからねぇ
143 ：仕様書無しさん：2007/05/18(金) 01:56:35
エンコード気にするのは、２バイト文字使う人たちだけだから
MSは無視してんじゃないの
MSは無視してんじゃないの
.Net FrameworkやVBは手厚いよ、C++/MFCだけ放置プレーになっとる
MS的にC++とMFCは、もう過去の遺産にしたいんじゃなかったっけか？
つかもうMFC捨てていいよ、混乱しすぎ
マイクロソフトはMFCというかWin32APIを過去の遺産にしたいらしい
今回のVistaでやるとか言いつつ結局できなかったみたいだけど
マイクロソフトはMFCというかWin32APIを過去の遺産にしたいらしい
今回のVistaでやるとか言いつつ結局できなかったみたいだけど
147 ：仕様書無しさん：2007/05/18(金) 03:01:29
ＭＦＣは消えるだろ。
148 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/18(金) 04:36:22
エンコードで困った事は一度も無い。
入り口と出口で変換すれば済む事。
入り口と出口で変換すれば済む事。
入り口と出口で変換したら何がどう済むのか分からん
ATLとWTLはVistaが糞な限り不滅
151 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/18(金) 09:26:42
>121,123
人は自分の知っている事しか分からない。だから俺の意見は俺の視野だけで出来ているのは当然だ。
だから是非とも121と123のテスト分類や内容を聞かせて欲しい。
>124
124は全て結合試験の事を言っている。仕様の誤りは結合試験で検出する。
なんか根本的に分かってない人がいるのかもしれないが、俺の書いたのはPGが関係する試験全部だ。
つまり「単体試験」→「結合試験」→「総合試験」と全部順番にやるんだぞ。
テスト仕様書を別の人が書いた方がいいのも、自動化ツールで再試験しやすくしておいた方がいいのも、
全て結合試験以降の事だ。
つーか単体試験の存在自体知らない人もいるとは知っていたが、案外多いって事かな。
人は自分の知っている事しか分からない。だから俺の意見は俺の視野だけで出来ているのは当然だ。
だから是非とも121と123のテスト分類や内容を聞かせて欲しい。
>124
124は全て結合試験の事を言っている。仕様の誤りは結合試験で検出する。
なんか根本的に分かってない人がいるのかもしれないが、俺の書いたのはPGが関係する試験全部だ。
つまり「単体試験」→「結合試験」→「総合試験」と全部順番にやるんだぞ。
テスト仕様書を別の人が書いた方がいいのも、自動化ツールで再試験しやすくしておいた方がいいのも、
全て結合試験以降の事だ。
つーか単体試験の存在自体知らない人もいるとは知っていたが、案外多いって事かな。
152 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/18(金) 09:55:44
>122
問題が発生する原因の多くは、「単体試験をやっていない」からだろう。
時間がない時の対応はいろいろあるが、とりあえず有効なのは2つだ。
「バグ発生時の関連バグの抽出を徹底させる」と「スキルの低いPGを製造から試験に回す」だな。
問題が発生する原因の多くは、「単体試験をやっていない」からだろう。
時間がない時の対応はいろいろあるが、とりあえず有効なのは2つだ。
「バグ発生時の関連バグの抽出を徹底させる」と「スキルの低いPGを製造から試験に回す」だな。
どのテストも観点と範囲が違うだけで、仕様書通りに動作するか検査するという意味では同じだろ。
--以下、ＩＴ用語辞典e-Wordsより抜粋
単体テスト 【unit test】
読み方 ： たんたいテスト
別名 ： ユニットテスト
システムのテスト手法の一つで、個々のモジュール(部品)のみを対象としたテスト。対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。
複数のモジュールを組み合わせて行なうテストは結合テスト、システム全体を対象に行なうテストはシステムテストという。
--以下、ＩＴ用語辞典e-Wordsより抜粋
単体テスト 【unit test】
読み方 ： たんたいテスト
別名 ： ユニットテスト
システムのテスト手法の一つで、個々のモジュール(部品)のみを対象としたテスト。対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。
複数のモジュールを組み合わせて行なうテストは結合テスト、システム全体を対象に行なうテストはシステムテストという。
おじゃばんところでは、単体テスト仕様書は書かずに、
結合テスト仕様書に全部書くのか。結合テスト大変だろ？
結合テスト仕様書に全部書くのか。結合テスト大変だろ？
JUnitはどっちかっつうと単体テストツールよ。なんでUnitって名前がついてると思ってんの？
>>151
アンカー使え。
大筋はそんなに間違ったことは言っちゃいないと思うが幾つか。
俺が読んで視野狭く見えたところの1つは
単体テストは詳細設計に基づくテストで、
詳細設計を行った人の意図通りに動くかのテストだろうが、
詳細設計者はプログラマとは限らない。
だから「プログラマの意図」と言われても
何を指してるか分からない。
君の職場では多分プログラマが詳細設計を行うのが当たり前なのか、
または詳細設計のフェイズを飛ばしてるんだろう。
テスト仕様書を別の人が書いた方がいいのも、自動化ツールで再試験しやすくしておいた方がいいのも、
「単体試験」→「結合試験」→「総合試験」
の全てで当てはまる。
＞テスト仕様書を別の人が書いた方がいい
作った人がテストを行った場合、「正しいはずだ」という思い込みが発生する。
＞自動化ツールで再試験しやすくしておいた方がいい
ソースコードに修正が入った場合、当然単体テストからやり直すため
ここからは個人宛でもないが
単体テスト知らないとか、開発してたら当然SDEMかSLCPは
知ってるものだと思ってたが違うのか？
テストだったら、PT、IT、STとか聞いたことない？
アンカー使え。
大筋はそんなに間違ったことは言っちゃいないと思うが幾つか。
俺が読んで視野狭く見えたところの1つは
単体テストは詳細設計に基づくテストで、
詳細設計を行った人の意図通りに動くかのテストだろうが、
詳細設計者はプログラマとは限らない。
だから「プログラマの意図」と言われても
何を指してるか分からない。
君の職場では多分プログラマが詳細設計を行うのが当たり前なのか、
または詳細設計のフェイズを飛ばしてるんだろう。
テスト仕様書を別の人が書いた方がいいのも、自動化ツールで再試験しやすくしておいた方がいいのも、
「単体試験」→「結合試験」→「総合試験」
の全てで当てはまる。
＞テスト仕様書を別の人が書いた方がいい
作った人がテストを行った場合、「正しいはずだ」という思い込みが発生する。
＞自動化ツールで再試験しやすくしておいた方がいい
ソースコードに修正が入った場合、当然単体テストからやり直すため
ここからは個人宛でもないが
単体テスト知らないとか、開発してたら当然SDEMかSLCPは
知ってるものだと思ってたが違うのか？
テストだったら、PT、IT、STとか聞いたことない？
>>151
>人は自分の知っている事しか分からない。だから俺の意見は俺の視野だけで出来ているのは当然だ。
マジか？ 普通意見書くときは、自分の経験だけじゃなく一般的な考え方も調べるだろ。恥かかないように、
誤解を与えないように、迷惑かけないように。
あと、アンカーは、>>151 のように、>が二つな。その方が大多数にとって親切。それと、>>151-152と書けば、
連番をで一挙に指定できるから。
>人は自分の知っている事しか分からない。だから俺の意見は俺の視野だけで出来ているのは当然だ。
マジか？ 普通意見書くときは、自分の経験だけじゃなく一般的な考え方も調べるだろ。恥かかないように、
誤解を与えないように、迷惑かけないように。
あと、アンカーは、>>151 のように、>が二つな。その方が大多数にとって親切。それと、>>151-152と書けば、
連番をで一挙に指定できるから。
>>151
大体ね、言葉の定義そのものが違うのではないかと思うんだよ。
システム内の動作単位（プログラム／クラス）のホワイトボックステストのみを単体試験と呼んでいないかい？
自分が単体試験と考えているものと別のものを単体試験と呼んでいるレスを読めば反応したくなるのは自然だろ？
沢山のレスが付いているのはその証拠だと思わないか？
大体ね、言葉の定義そのものが違うのではないかと思うんだよ。
システム内の動作単位（プログラム／クラス）のホワイトボックステストのみを単体試験と呼んでいないかい？
自分が単体試験と考えているものと別のものを単体試験と呼んでいるレスを読めば反応したくなるのは自然だろ？
沢山のレスが付いているのはその証拠だと思わないか？
単体で仕様通り動かないことがわかっていながら結合テスト開始か
阿呆は死んでくれ
阿呆は死んでくれ
160 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/18(金) 22:01:35
>>153
辞書的な意味を言っているのではなく、単体試験や結合試験と呼ばれる工程で実際に行われている事を
言っている。だから内容まで書いただろう？もし自分の所で呼び方が違うなら読み替えて理解してくれ。
>>154
何言っている？俺は分けて書いてるぞ？
>>155
このJUnit自体がおかしいと思っている。
単体試験の工程を自動化した所で、修正が入ればテストルーチンも変更になる。
実際に単体試験でJUnitを使った事があるが、説明どおりに全メソッドにつけると開発量が3倍になる。
おまけに全分岐は出来ないので、十分な試験が出来る訳ではない。
結合試験でサンプルデータと結果データを保持しておいて、修正後の再試験に使うのはよくやる手だが、
単体試験に使う人はいない。だからJUnitは止めた。
辞書的な意味を言っているのではなく、単体試験や結合試験と呼ばれる工程で実際に行われている事を
言っている。だから内容まで書いただろう？もし自分の所で呼び方が違うなら読み替えて理解してくれ。
>>154
何言っている？俺は分けて書いてるぞ？
>>155
このJUnit自体がおかしいと思っている。
単体試験の工程を自動化した所で、修正が入ればテストルーチンも変更になる。
実際に単体試験でJUnitを使った事があるが、説明どおりに全メソッドにつけると開発量が3倍になる。
おまけに全分岐は出来ないので、十分な試験が出来る訳ではない。
結合試験でサンプルデータと結果データを保持しておいて、修正後の再試験に使うのはよくやる手だが、
単体試験に使う人はいない。だからJUnitは止めた。
161 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/18(金) 22:49:32
>>156
俺の開発方法では、詳細設計を飛ばしてコーディングを行う。
詳細設計書いて別人にコーディングさせるなら、156のやり方で問題ない。
>ここからは個人宛でもないが
これ以降は誰に何言っているのかいまいち分からないが、「SDEMかSLCP」は知らない。
ただ各社で工程の略称が違うのは知られている事で、「PT、IT、ST」などの略称は使わずに、
日本語名と内容を記述した。
>>157
一般的な考えや常識と言うのも、主観による物だろう。俺にとってはあの試験分類は常識だ。
ただ同じように常識だと思っている人もいるようなので、少なくともある所では常識だと考えていいだろう。
ちなみに157は、2chに書き込むのに「恥をかかないように」などと気をつけているのか？
実にくだらない。匿名掲示板の名無しが恥なんて気にする必要はないだろう？
もし間違いを指摘されたら、別人の振りをして書き込めばいいのだから。コテより遥かに楽だ。
恥をかかないようになんて気にせず、内容に対して発言したらどうだ？
俺の開発方法では、詳細設計を飛ばしてコーディングを行う。
詳細設計書いて別人にコーディングさせるなら、156のやり方で問題ない。
>ここからは個人宛でもないが
これ以降は誰に何言っているのかいまいち分からないが、「SDEMかSLCP」は知らない。
ただ各社で工程の略称が違うのは知られている事で、「PT、IT、ST」などの略称は使わずに、
日本語名と内容を記述した。
>>157
一般的な考えや常識と言うのも、主観による物だろう。俺にとってはあの試験分類は常識だ。
ただ同じように常識だと思っている人もいるようなので、少なくともある所では常識だと考えていいだろう。
ちなみに157は、2chに書き込むのに「恥をかかないように」などと気をつけているのか？
実にくだらない。匿名掲示板の名無しが恥なんて気にする必要はないだろう？
もし間違いを指摘されたら、別人の振りをして書き込めばいいのだから。コテより遥かに楽だ。
恥をかかないようになんて気にせず、内容に対して発言したらどうだ？
162 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/18(金) 22:59:43
>>158
まあ、呼び方が違うのを反論したくなるのも分かる。
だから呼び方だけでなく内容も書いた。相違点は内容を見て判断してくれ。
>>159
仕様というのは「機能仕様（画面仕様、画面遷移、外部IF等）」を言っているのか？
「詳細仕様（JavaDocレベル）」を言っているのか？
詳細仕様を言っているのなら、俺は仕様通りに動かないのに結合試験に進めとは言っていないし、
機能仕様を言っているのなら、お前が市ね。
まあ、呼び方が違うのを反論したくなるのも分かる。
だから呼び方だけでなく内容も書いた。相違点は内容を見て判断してくれ。
>>159
仕様というのは「機能仕様（画面仕様、画面遷移、外部IF等）」を言っているのか？
「詳細仕様（JavaDocレベル）」を言っているのか？
詳細仕様を言っているのなら、俺は仕様通りに動かないのに結合試験に進めとは言っていないし、
機能仕様を言っているのなら、お前が市ね。
>>162
＞詳細仕様を言っているのなら、俺は仕様通りに動かないのに結合試験に進めとは言っていないし、
>>151より
＞124は全て結合試験の事を言っている。仕様の誤りは結合試験で検出する。
言ってるじゃねぇか。
詳細仕様も仕様だろ。
>>124含めて読んだら余計に「詳細仕様の確認は単体テストじゃしない」
と言ってるように読める。
お前が氏ね。
いやなら国語を勉強し直せ。
言葉の定義が曖昧すぎて使い方が時々で違うから、
言ってることが支離滅裂だ。
＞詳細仕様を言っているのなら、俺は仕様通りに動かないのに結合試験に進めとは言っていないし、
>>151より
＞124は全て結合試験の事を言っている。仕様の誤りは結合試験で検出する。
言ってるじゃねぇか。
詳細仕様も仕様だろ。
>>124含めて読んだら余計に「詳細仕様の確認は単体テストじゃしない」
と言ってるように読める。
お前が氏ね。
いやなら国語を勉強し直せ。
言葉の定義が曖昧すぎて使い方が時々で違うから、
言ってることが支離滅裂だ。
以降、おじゃばさまが刑期を終え罪を償い出所するまで、おじゃばさまは
スルーの方向で。それが本人のためでもある。
スルーの方向で。それが本人のためでもある。
鬱の人にがんばれは禁句らしいしな。
166 ：仕様書無しさん：2007/05/19(土) 00:07:15
人間、羞恥心を失ったら終わりだよ
>>160
JUnitを誤解してる気がする。
まず、JUnitで分岐網羅テストが出来ないと言ってるのは何故？
めっちゃ網羅テストしとるけど。
#ちなみにうちの単体テストはパス網羅
次に、JUnitを使う理由は再テストの自動化だけが目的では無い。
まぁあくまで「うち場合は」ということなんだけど、
どちらかと言うと単体テストをフレームワーク化して
「テストの質」を底上げするために使ってる。
フレームワーク化することで、まずテスト者による
テストの質のバラつきが少なくなる。(やっぱあるけど)
それに実際に行ったテスト手順がテストシナリオとして
残るから、行った手順そのものをレビュー出来る。
# 単体テスト仕様書に書かれている手順の通りに
# 単体テストが行われているとは限らない
再テストもほぼ同様の条件で行うことが出来る。
個人のスキルに頼りきったテストなんてしてたら
誰かがプロジェクト引き継いだ後はどうするんだ？
# 自分1人で全部作り上げて、保守メンテまでずっと面倒見るとか
# 詳細テスト仕様書に、何1つ知らない人がテスト出来るほど
# テスト手順が詳細に書いてあるなら良いのかも知れんけど
JUnitを誤解してる気がする。
まず、JUnitで分岐網羅テストが出来ないと言ってるのは何故？
めっちゃ網羅テストしとるけど。
#ちなみにうちの単体テストはパス網羅
次に、JUnitを使う理由は再テストの自動化だけが目的では無い。
まぁあくまで「うち場合は」ということなんだけど、
どちらかと言うと単体テストをフレームワーク化して
「テストの質」を底上げするために使ってる。
フレームワーク化することで、まずテスト者による
テストの質のバラつきが少なくなる。(やっぱあるけど)
それに実際に行ったテスト手順がテストシナリオとして
残るから、行った手順そのものをレビュー出来る。
# 単体テスト仕様書に書かれている手順の通りに
# 単体テストが行われているとは限らない
再テストもほぼ同様の条件で行うことが出来る。
個人のスキルに頼りきったテストなんてしてたら
誰かがプロジェクト引き継いだ後はどうするんだ？
# 自分1人で全部作り上げて、保守メンテまでずっと面倒見るとか
# 詳細テスト仕様書に、何1つ知らない人がテスト出来るほど
# テスト手順が詳細に書いてあるなら良いのかも知れんけど
せっかく書いたんで空気無視して続き投下
最後に単体テストの再試験の話だけど
「結合試験でサンプルデータと結果データを保持しておいて、
修正後の再試験に使うのはよくやる手だが、
単体試験に使う人はいない。」
と言っているが。
じゃあソースコード修正後の単体テストはどのようにするの？
例えば仕様変更であるメソッドでif文が1つ増えたとして
・if文の中を通るパスと通らないパスを1回ずつ確認しました。
というだけの単体テストと、これにくわえて
・前回のテストを全て再テストし、他の仕様に影響がないことを確認しました。
という単体テストでは、信頼度が全然違う、というのがうちのスタンス。
最後に単体テストの再試験の話だけど
「結合試験でサンプルデータと結果データを保持しておいて、
修正後の再試験に使うのはよくやる手だが、
単体試験に使う人はいない。」
と言っているが。
じゃあソースコード修正後の単体テストはどのようにするの？
例えば仕様変更であるメソッドでif文が1つ増えたとして
・if文の中を通るパスと通らないパスを1回ずつ確認しました。
というだけの単体テストと、これにくわえて
・前回のテストを全て再テストし、他の仕様に影響がないことを確認しました。
という単体テストでは、信頼度が全然違う、というのがうちのスタンス。
おじゃばへの最後の通告だ。ありがたく受け取れ。
170 ：仕様書無しさん：2007/05/19(土) 00:23:05
漫然とJUnitでテストケース書いてたらものすごく大変な目にあうのは、おじゃばのいうとおり。
参照透明な関数的メソッドを可能な限り多くして、副作用を伴う手続き的メソッドを少なくしていく意識を持たないと
なかなかJUnitの効果が実感できない。
参照透明な関数的メソッドを可能な限り多くして、副作用を伴う手続き的メソッドを少なくしていく意識を持たないと
なかなかJUnitの効果が実感できない。
2chネラーって意外と親切なんだな。涙でてきた。
ここまでわかったこと。おじゃばの定義では。
まず、動作単位の内部構造（データ設計／論理設計）は文書化しない。
それゆえそのホワイトボックス試験については試験仕様書も作らない。
（作るのは大変な手間だから作っているところは少ないと思うが）
これは「プログラムがプログラマの思った通りに動作するかチェックする」という発言から判断可能だ。
おじゃばはこれを単体試験と呼んでいる。（自分はこれをデバッグと呼んでいる）
次に「プログラムが機能設計を満たしているか検証する。」
の発言に見るように、機能設計書に基づいた試験を行うようだ。
（機能設計書／機能仕様書を基に試験仕様書を作成するか否かは明示されていないが）
おじゃばはこれを結合試験と呼んでいる。（自分はこれを単体試験と呼んでいる）
そして「総合試験では、実際の運用を想定した試験を行う。」と言っている。まあこれはよしとしよう。
ここで問題は動作単位間のインターフェースの齟齬を発見する為の工程が記述していないことだ。
（自分はこれを結合試験と呼んでいる）
おじゃばが言っている総合試験がこれに当たるのだろうか？確認したい＞おじゃば
そして最後に「読み替えろ」とはあまりに不遜な発言だ。
呼び方のフェーズが一つずれているので混乱するぞ。
ここでおじゃばの職場の呼び方に付き合う義理はない。
良く調べて、一般的な言葉を使ってくれ。
まず、動作単位の内部構造（データ設計／論理設計）は文書化しない。
それゆえそのホワイトボックス試験については試験仕様書も作らない。
（作るのは大変な手間だから作っているところは少ないと思うが）
これは「プログラムがプログラマの思った通りに動作するかチェックする」という発言から判断可能だ。
おじゃばはこれを単体試験と呼んでいる。（自分はこれをデバッグと呼んでいる）
次に「プログラムが機能設計を満たしているか検証する。」
の発言に見るように、機能設計書に基づいた試験を行うようだ。
（機能設計書／機能仕様書を基に試験仕様書を作成するか否かは明示されていないが）
おじゃばはこれを結合試験と呼んでいる。（自分はこれを単体試験と呼んでいる）
そして「総合試験では、実際の運用を想定した試験を行う。」と言っている。まあこれはよしとしよう。
ここで問題は動作単位間のインターフェースの齟齬を発見する為の工程が記述していないことだ。
（自分はこれを結合試験と呼んでいる）
おじゃばが言っている総合試験がこれに当たるのだろうか？確認したい＞おじゃば
そして最後に「読み替えろ」とはあまりに不遜な発言だ。
呼び方のフェーズが一つずれているので混乱するぞ。
ここでおじゃばの職場の呼び方に付き合う義理はない。
良く調べて、一般的な言葉を使ってくれ。
確かにJUnit「だけ」ではカバレージ（網羅性）は100%にならない
特にprivateなメソッドの場合とか、どう考えてもthrowされないだろう例外のcatch処理
JUnitは確かに便利だが万能ではない
>>172
少なくとも俺の周りでは単体試験とデバッグは同義だぞ
私の普通は１プログラムは１人のプログラマが製造と試験方案作成とテストを行い、
それを単体テスト（UT)と呼んでいる
そして、プログラムを作るためのインプットを詳細設計書と定義していて、
詳細設計書を書いた人間とソースコードレビューと試験方案のレビューを行い、
認識の誤りが無いかどうかのチェックを行っている。
なお、詳細設計書にはI/F仕様、画面仕様、機能仕様が記載されている
そして、自システムに閉じている状態で想定通りに動作していることを
確認するのが結合テスト（IT）、これのインプットは基本設計書と呼んでいる
画面遷移やプログラムの連携が想定どおりに行われているかの確認を行う
総合テスト（ST）では外部システムとのI/Fの食い違いや
負荷テスト、顧客が操作を行う代表的なシステムの使われ方をピックアップして
想定どおりに外部システムとの連携を行えるかというシナリオを洗い出して
試験を行う、これのインプットは要件定義書と呼ばれる
つまり、要件定義従った動作を確認するための試験を総合テスト（ST）
基本設計書に従った動作を確認するための試験を結合テスト（IT）
詳細設計書に従った動作を確認するための試験を単体試験（UT）と位置づけている
おそらく、１プログラムを多人数で触ることがあるならばPTという工程は必要だと思うが
それはもしかして１プログラムに多くの機能を詰め込みすぎているからだと思う
個人的な感覚としてプログラムのテストは単体試験で十分だ
特にprivateなメソッドの場合とか、どう考えてもthrowされないだろう例外のcatch処理
JUnitは確かに便利だが万能ではない
>>172
少なくとも俺の周りでは単体試験とデバッグは同義だぞ
私の普通は１プログラムは１人のプログラマが製造と試験方案作成とテストを行い、
それを単体テスト（UT)と呼んでいる
そして、プログラムを作るためのインプットを詳細設計書と定義していて、
詳細設計書を書いた人間とソースコードレビューと試験方案のレビューを行い、
認識の誤りが無いかどうかのチェックを行っている。
なお、詳細設計書にはI/F仕様、画面仕様、機能仕様が記載されている
そして、自システムに閉じている状態で想定通りに動作していることを
確認するのが結合テスト（IT）、これのインプットは基本設計書と呼んでいる
画面遷移やプログラムの連携が想定どおりに行われているかの確認を行う
総合テスト（ST）では外部システムとのI/Fの食い違いや
負荷テスト、顧客が操作を行う代表的なシステムの使われ方をピックアップして
想定どおりに外部システムとの連携を行えるかというシナリオを洗い出して
試験を行う、これのインプットは要件定義書と呼ばれる
つまり、要件定義従った動作を確認するための試験を総合テスト（ST）
基本設計書に従った動作を確認するための試験を結合テスト（IT）
詳細設計書に従った動作を確認するための試験を単体試験（UT）と位置づけている
おそらく、１プログラムを多人数で触ることがあるならばPTという工程は必要だと思うが
それはもしかして１プログラムに多くの機能を詰め込みすぎているからだと思う
個人的な感覚としてプログラムのテストは単体試験で十分だ
俺も単体テストについては、十分なテストケースがあればこれだけでテストは十分だと思う
これがキチンとできていれば別のテストで問題が発生する事は殆ど無いから軽くやっとけば十分なような気がしている。
それと、あらゆるコードをテスト駆動型で作らなくても、事後テストでもテストケースが熟慮されていれば問題は発生しないな。
テスト駆動型は仕様書もコードというのが気持ちいいが、コードで書きにくい仕様なら無理してテストファーストしなくても事後テストでも良いだろうと思う、またそのほうが効率的。
どうでもいいが、電球は一から勉強しなおすか死んだほうがいいだろうw
これがキチンとできていれば別のテストで問題が発生する事は殆ど無いから軽くやっとけば十分なような気がしている。
それと、あらゆるコードをテスト駆動型で作らなくても、事後テストでもテストケースが熟慮されていれば問題は発生しないな。
テスト駆動型は仕様書もコードというのが気持ちいいが、コードで書きにくい仕様なら無理してテストファーストしなくても事後テストでも良いだろうと思う、またそのほうが効率的。
どうでもいいが、電球は一から勉強しなおすか死んだほうがいいだろうw
>>173
ぐはっ・・・
JUnit-addonとかはJUnitでは無いのか・・・。
勉強不足で申し訳ない。
ちなみにうちでは単体テスト（クラス単体テスト、関数単体テスト）は必須ではないけど、
商品として出す場合はテストで1度も通ってないパスがあるプログラムは出せない。
品質管理部門でストップを食らう。
後の方のテストになるほどでホワイトボックステストするのが辛いから、
大体単体テストで全パス網羅することが多い。
ぐはっ・・・
JUnit-addonとかはJUnitでは無いのか・・・。
勉強不足で申し訳ない。
ちなみにうちでは単体テスト（クラス単体テスト、関数単体テスト）は必須ではないけど、
商品として出す場合はテストで1度も通ってないパスがあるプログラムは出せない。
品質管理部門でストップを食らう。
後の方のテストになるほどでホワイトボックステストするのが辛いから、
大体単体テストで全パス網羅することが多い。
>>173 F関係の人ですか?
>>175
どうしてもカバレージ率を100%にしたいなら
java.lang.reflectを使って無理やりprivateなメソッドを呼び出す方法や
djUnitのモックアップで無理やり例外をthrowする方法は存在するが
カバレージ率を100%にすることでバグはなくなることはない（品質は多少はあがるけど）
むしろ、そこまでコストをかけてまで品質を上げることに意味はあるのか？
XPから生まれ、軽快な開発を旨とするJUnitの思想からすると
カバレージ率を無理やり100%にすることはメリットより
デメリットのほうが大きい気がする。
どうしてもカバレージ率を100%にしたいなら
java.lang.reflectを使って無理やりprivateなメソッドを呼び出す方法や
djUnitのモックアップで無理やり例外をthrowする方法は存在するが
カバレージ率を100%にすることでバグはなくなることはない（品質は多少はあがるけど）
むしろ、そこまでコストをかけてまで品質を上げることに意味はあるのか？
XPから生まれ、軽快な開発を旨とするJUnitの思想からすると
カバレージ率を無理やり100%にすることはメリットより
デメリットのほうが大きい気がする。
横槍だけど、完全にするぐらいなら、コードを二重化して突合せチェック入れたほうがコスト的に安くて信頼性があがりそうだしね。
要求条件として必要だとしても偏執狂的なやり方になるなら、別の方法を模索するのもありだと思うな。
要求条件として必要だとしても偏執狂的なやり方になるなら、別の方法を模索するのもありだと思うな。
Javaの場合、テスタビリティを優先するなら、Privateメソッドは作らねぇな。
Protectedにしとく。テストクラスを同一パッケージでつくれば、そのメソッド
呼べるからね。C++の場合はfriend指定があるから関係無いけど。
Protectedにしとく。テストクラスを同一パッケージでつくれば、そのメソッド
呼べるからね。C++の場合はfriend指定があるから関係無いけど。
>>177
個人的にはそこまでする必要は無いと思うんだけど、
仕事が基本的に研究部門なもんで、商品開発になるとその辺のノウハウが無いんだよね。
(どこまでコストかけて、どこまで品質上げるかとか)
なもんで、客先(自社だが)で言われたままにその通りにしてる状態。
研究系(CESのデモ用とか)の場合は、そこまでやってない。
個人的にはそこまでする必要は無いと思うんだけど、
仕事が基本的に研究部門なもんで、商品開発になるとその辺のノウハウが無いんだよね。
(どこまでコストかけて、どこまで品質上げるかとか)
なもんで、客先(自社だが)で言われたままにその通りにしてる状態。
研究系(CESのデモ用とか)の場合は、そこまでやってない。
漏れは宇宙指向で設計しているのよ。
俺は分子指向だ。
183 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/20(日) 05:05:59
依然挙げたOthello2はクラスごとにテストルーチンがついているわけだが
184 ：仕様書無しさん：2007/05/20(日) 12:31:08
Javaは、デフォルトでfriend指定ですYO
うちのコーディング規約では明示的にスコープ指定しないと駄目なんですＹＯ
テストの話は別スレ立ててやれ
激しくスレ違い
つか、もまいらコテハンに釣られすぎ
反省しる
激しくスレ違い
つか、もまいらコテハンに釣られすぎ
反省しる
187 ：ココ電球（∩T∀T)y-~~~~ ◆UXDcDJfhK. ：2007/05/21(月) 01:19:33
うっせぇ ボケ
オブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。
オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方である。
機能中心でもなんとかなるのが災いしてオブジェクト設計が流行らない？
オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方である。
機能中心でもなんとかなるのが災いしてオブジェクト設計が流行らない？
はいはいﾊﾞﾛｽﾊﾞﾛｽ
オブジェクト設計は流行ってるよ。Javaは衰退気味だけど。
オブジェクト指向での設計が流行ってるかどうかの話に
Javaがどうのこうのは関係が無い
ｸﾗｽ図書いてたり、もしくはプロジェクト内がそういう仕事ぶりなら
オブジェクト指向で設計してると言ってもいい
しかし従来のガントチャート管理でこの機能をいつまでに作れ、
という作り方をやってるんじゃあ、機能分類にしかなっとらん
優秀な奴がいれば方向修正もキクだろうが、大規模PJだとそれもままならん
Javaがどうのこうのは関係が無い
ｸﾗｽ図書いてたり、もしくはプロジェクト内がそういう仕事ぶりなら
オブジェクト指向で設計してると言ってもいい
しかし従来のガントチャート管理でこの機能をいつまでに作れ、
という作り方をやってるんじゃあ、機能分類にしかなっとらん
優秀な奴がいれば方向修正もキクだろうが、大規模PJだとそれもままならん
テスタビリティはＯＯＰを語るのに重要なポイントですけど？
>Javaは衰退気味だけど。
どこの星から来たの、きみ？
>Javaは衰退気味だけど。
どこの星から来たの、きみ？
>ガントチャート管理でこの機能をいつまでに作れ、
>という作り方をやってるんじゃあ、機能分類にしかなっとらん
アホですか？
>という作り方をやってるんじゃあ、機能分類にしかなっとらん
アホですか？
テストはOOに限らず開発方法論全般にかかわる最大のフロンティアではないかと
ばっｗ おまっっｗｗ
わけわかんねーのがOOのフロンティアスピリットなんだから突っ込み禁止だろｗｗｗｗ
わけわかんねーのがOOのフロンティアスピリットなんだから突っ込み禁止だろｗｗｗｗ
ユーザサイドの考え方が出来ない奴ばっかだな
You The Side
お前はもう、邪魔だから横で大人しくしてろ
お前はもう、邪魔だから横で大人しくしてろ
200 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/21(月) 11:52:25
>>163
163が詳細設計の事を言っているなら誤解だよ。
俺は詳細設計書を書かないから最初の発言で、仕様というのは機能仕様の事だ。
>>167
異常ルートを網羅するのが非常に困難だから。全部やるには標準クラスや関数のスタブが必要。
変更が入ると変更点＋スタブ＋確認モジュールと、普通の3倍ぐらいの修正が入る。
入出力のチェックだけでは人によるばらつきが多い。2ケースでOKにする人もいれば、100ケースの人もいる。
全パスチェックの方がばらつきが少ない。単体試験（詳細設計）レベルの引き継ぎはしない。
機能設計レベルで引き継ぎ、問題が発生したら時間をかけてソース解析する。
if文の追加が一行入ったら、基本的に単体試験は修正箇所の試験しかやらない。
と言うか、大きな修正が入った時にしか単体試験はやらないし、単体試験をやり直す事はなく、
新しく単体試験項目表を書く。
if文の追加というのは、ほとんどバグ修正の事だろう。
バグ修正の場合は、バグ票を試験項目の扱いとし、修正箇所の単体試験と関連する結合試験を行い、
結果をバグ票に記入、または添付する。基本的に単体試験項目表は使い捨て。
163が詳細設計の事を言っているなら誤解だよ。
俺は詳細設計書を書かないから最初の発言で、仕様というのは機能仕様の事だ。
>>167
異常ルートを網羅するのが非常に困難だから。全部やるには標準クラスや関数のスタブが必要。
変更が入ると変更点＋スタブ＋確認モジュールと、普通の3倍ぐらいの修正が入る。
入出力のチェックだけでは人によるばらつきが多い。2ケースでOKにする人もいれば、100ケースの人もいる。
全パスチェックの方がばらつきが少ない。単体試験（詳細設計）レベルの引き継ぎはしない。
機能設計レベルで引き継ぎ、問題が発生したら時間をかけてソース解析する。
if文の追加が一行入ったら、基本的に単体試験は修正箇所の試験しかやらない。
と言うか、大きな修正が入った時にしか単体試験はやらないし、単体試験をやり直す事はなく、
新しく単体試験項目表を書く。
if文の追加というのは、ほとんどバグ修正の事だろう。
バグ修正の場合は、バグ票を試験項目の扱いとし、修正箇所の単体試験と関連する結合試験を行い、
結果をバグ票に記入、または添付する。基本的に単体試験項目表は使い捨て。
201 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/21(月) 12:46:57
>>172
単体試験項目表は手書きで書く。
内容は機密事項なので詳しくは言えないが、非常に泥臭い方法で、全分岐と全ループの試験を行う。
結合試験項目を機能仕様書ベースで作るのは認識どおり。
外部IFの試験は結合試験で行う。なぜなら外部IF仕様書は機能仕様書だからだ。
>>173
分類の違いはあれ、やってる事はほぼ同じなので異存はない。
>>175
後の方のテストになるほどでホワイトボックステストするのが辛いのは同意。
>>177
JUnitの試験コードをメンテするぐらいなら、手書きで毎回試験項目書いた方が早いと言うのが俺の結論。
>>179
なんかそれって根本的に間違ってないか？
>>180
客側に合わせるのは基本だが、俺は内部的には上記の手順で行って、外部的には客に合わせて出す。
品質を保つなら自社の基準を持つべきだと思う。
単体試験項目表は手書きで書く。
内容は機密事項なので詳しくは言えないが、非常に泥臭い方法で、全分岐と全ループの試験を行う。
結合試験項目を機能仕様書ベースで作るのは認識どおり。
外部IFの試験は結合試験で行う。なぜなら外部IF仕様書は機能仕様書だからだ。
>>173
分類の違いはあれ、やってる事はほぼ同じなので異存はない。
>>175
後の方のテストになるほどでホワイトボックステストするのが辛いのは同意。
>>177
JUnitの試験コードをメンテするぐらいなら、手書きで毎回試験項目書いた方が早いと言うのが俺の結論。
>>179
なんかそれって根本的に間違ってないか？
>>180
客側に合わせるのは基本だが、俺は内部的には上記の手順で行って、外部的には客に合わせて出す。
品質を保つなら自社の基準を持つべきだと思う。
相変わらず意味不明で独断的な文章だな。
長文のわりには想定条件が曖昧で主張の根拠も説明不足。
だから、つっこまれると、あれは俺的にはこういう意味のつもりだったということになる。
まるで無意味。徒労。無駄。非効率。というより寧ろ有害。
長文のわりには想定条件が曖昧で主張の根拠も説明不足。
だから、つっこまれると、あれは俺的にはこういう意味のつもりだったということになる。
まるで無意味。徒労。無駄。非効率。というより寧ろ有害。
機密事項って...ただのマトリックスだろが。機密ってほどのもんかよ。
204 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/21(月) 19:52:48
フロンティアだと思ったら 何かを求めて振り返ってもそこにはただ風が吹いているだけだった。
205 ：仕様書無しさん：2007/05/21(月) 20:22:13
206 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/21(月) 23:08:14
祭りは嫌いなので、うるさいから窓閉めてバイオ４やってた
個人的な感想を言わせて貰うと
業務システムにはオブジェクト指向は向かない
例えば、業務フロー、ビジネスフロー、ワークフローなどのフロー制御の最小単位って
「入力データ→何かの処理→出力データ」で
次の処理は前の出力データが入力データであることが多い
この場合、無理にオブジェクト指向を適用するよりもデータフローの方が
設計手法としては適切で、素直にモデリングできそうなな気がする。
もちろん、別のシステムにおいては（特に画面系）の場合は
データフローなんかよりもオブジェクト指向の方が向いているだろう
つまり、オブジェクト指向は多くのシステム構築のシェアを占める
業務システムには向いていないので流行らないと結論する
もちろん、フレームワークとか、コンポーネントとか、
業務フローを使いやすくするための「裏方」としても使える設計方法だとは思う
業務システムにはオブジェクト指向は向かない
例えば、業務フロー、ビジネスフロー、ワークフローなどのフロー制御の最小単位って
「入力データ→何かの処理→出力データ」で
次の処理は前の出力データが入力データであることが多い
この場合、無理にオブジェクト指向を適用するよりもデータフローの方が
設計手法としては適切で、素直にモデリングできそうなな気がする。
もちろん、別のシステムにおいては（特に画面系）の場合は
データフローなんかよりもオブジェクト指向の方が向いているだろう
つまり、オブジェクト指向は多くのシステム構築のシェアを占める
業務システムには向いていないので流行らないと結論する
もちろん、フレームワークとか、コンポーネントとか、
業務フローを使いやすくするための「裏方」としても使える設計方法だとは思う
208 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/22(火) 09:26:33
209 ：仕様書無しさん：2007/05/22(火) 10:12:18
>207
揚げ足をとるつもりは無いんだけど、
「フレームワーク」と「コンポーネント」をＯＯ化したら、
それはもうほぼ全体のＯＯ化と違うの？
>208
ワケ分かんね
揚げ足をとるつもりは無いんだけど、
「フレームワーク」と「コンポーネント」をＯＯ化したら、
それはもうほぼ全体のＯＯ化と違うの？
>208
ワケ分かんね
210 ：仕様書無しさん：2007/05/22(火) 11:25:52
>209
違う
業務システムの実ロジック部はJ2EEで言うトランザクションスクリプト形式で組む方が効率が良いんじゃないかという提案で、
俺もそうするほうがやりやすいんじゃないかと思う。
そしてそれを動かすワークフロー部はOO設計することが多い。
最近はそれをBPMパッケージとしてフレームワーク化する流れだと感じている。
違う
業務システムの実ロジック部はJ2EEで言うトランザクションスクリプト形式で組む方が効率が良いんじゃないかという提案で、
俺もそうするほうがやりやすいんじゃないかと思う。
そしてそれを動かすワークフロー部はOO設計することが多い。
最近はそれをBPMパッケージとしてフレームワーク化する流れだと感じている。
>>210
業務システムでは、そのワークフロー部もあわせて作るケースの方が多いんじゃないの？
客が違えばワークフローも違うわけだし、ましてや業務が違えばフローもがらっと変わる。
BPMでそこまで柔軟に対応できるとは、まだ思えないけど。
業務システムでは、そのワークフロー部もあわせて作るケースの方が多いんじゃないの？
客が違えばワークフローも違うわけだし、ましてや業務が違えばフローもがらっと変わる。
BPMでそこまで柔軟に対応できるとは、まだ思えないけど。
212 ：209：2007/05/22(火) 13:52:13
213 ：209：2007/05/22(火) 13:54:59
個人的に、プロシージャで良い思いをしたことがないので
（主にメンテの点で）、トランザクションスクリプト形式には警戒してしまう。
（主にメンテの点で）、トランザクションスクリプト形式には警戒してしまう。
214 ：210：2007/05/22(火) 16:37:14
>212
ごめん
言いたいこと分かった。違わないと思う。
ワークフローはタスクという抽象概念を取り出せば容易にフレームワーク化できる。
>|タスク.進める();
といった感じで。
トランザクションスクリプトにするのはあくまでもOOを理解できない末端PGのため。
それ以外のとこはお好きにどうぞ。
ごめん
言いたいこと分かった。違わないと思う。
ワークフローはタスクという抽象概念を取り出せば容易にフレームワーク化できる。
>|タスク.進める();
といった感じで。
トランザクションスクリプトにするのはあくまでもOOを理解できない末端PGのため。
それ以外のとこはお好きにどうぞ。
C++で書かれたソフトってCで書かれたものに比べて重すぎない？
重すぎるってことはない。
217 ：仕様書無しさん：2007/05/22(火) 18:35:22
じゃ、肥満て言うことで
218 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/22(火) 21:29:45
業務をオブジェクト指向的にしたいなら、まずワークフローを捨てる必要がある。
219 ：仕様書無しさん：2007/05/22(火) 21:49:42
いやぽ
>>218
誰もしたがって無いから流行らねぇって言ってんだろ？
誰もしたがって無いから流行らねぇって言ってんだろ？
仮にアーキテクチャにドメインモデルを採用したとしても
ワークフローを捨てる必要はない
というかレイヤが違う
ワークフローつったら、アクティビティのことだ。
アクティビティの中で蠢いてるのがドメインモデルだろうが
トランザクションスクリプトだろうがかまわん。
ワークフローを捨てる必要はない
というかレイヤが違う
ワークフローつったら、アクティビティのことだ。
アクティビティの中で蠢いてるのがドメインモデルだろうが
トランザクションスクリプトだろうがかまわん。
>>214
>トランザクションスクリプトにするのはあくまでもOOを理解できない末端PGのため。
確かに・・。現に今、ドメインモデルを理解しない人たちの手によって作られた
コードの再設計をさせられてるw
>トランザクションスクリプトにするのはあくまでもOOを理解できない末端PGのため。
確かに・・。現に今、ドメインモデルを理解しない人たちの手によって作られた
コードの再設計をさせられてるw
>>218
相変わらず、ワケ分かんねえ。
相変わらず、ワケ分かんねえ。
>218
まずお前が居なくなれ
>221
同意
アクティビティ＝タスクね
まずお前が居なくなれ
>221
同意
アクティビティ＝タスクね
>>218
ど素人の知ったかぶりにも程があるぞ。
ど素人の知ったかぶりにも程があるぞ。
>>207
>人的な感想を言わせて貰うと
>業務システムにはオブジェクト指向は向かない
>
>例えば、業務フロー、ビジネスフロー、ワークフローなどのフロー制御の最小単位って
「入力データ→何かの処理→出力データ」で
>次の処理は前の出力データが入力データであることが多い
>
>この場合、無理にオブジェクト指向を適用するよりもデータフローの方が
>設計手法としては適切で、素直にモデリングできそうなな気がする。
これは非常によく分かるわ、この種の処理はそもそもオブジェクト指向スタイルより純粋関数型言語(いわゆるLISPとかHaskellとか)の方に向いている
逆にこの点をよくよく考えてみれば、たとえばC#のdelegateや、C++の関数オブジェクトのようなクロージャーで実装すれば綺麗に作れるのではと思っている。
現状デザインパターンではこのあたりの研究は全くされていないので実は研究余地大有りなのではと思っていたりする。(現状ではJavaを中心にしているので激しく手落ちになっている)
まぁ、まだまだOOには進化余地があるんだろうな、もっともそれはOOでは無いかもしれんが。
>人的な感想を言わせて貰うと
>業務システムにはオブジェクト指向は向かない
>
>例えば、業務フロー、ビジネスフロー、ワークフローなどのフロー制御の最小単位って
「入力データ→何かの処理→出力データ」で
>次の処理は前の出力データが入力データであることが多い
>
>この場合、無理にオブジェクト指向を適用するよりもデータフローの方が
>設計手法としては適切で、素直にモデリングできそうなな気がする。
これは非常によく分かるわ、この種の処理はそもそもオブジェクト指向スタイルより純粋関数型言語(いわゆるLISPとかHaskellとか)の方に向いている
逆にこの点をよくよく考えてみれば、たとえばC#のdelegateや、C++の関数オブジェクトのようなクロージャーで実装すれば綺麗に作れるのではと思っている。
現状デザインパターンではこのあたりの研究は全くされていないので実は研究余地大有りなのではと思っていたりする。(現状ではJavaを中心にしているので激しく手落ちになっている)
まぁ、まだまだOOには進化余地があるんだろうな、もっともそれはOOでは無いかもしれんが。
また自演か
228 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 02:18:51
あーそうそう
業務フローって言葉どおり、開発でも保守変更でも 要求仕様はフローチャートの形をしている。
フローチャート型に組んであるのは変更しやすいが、ステートモデルだのコマンドパターンだので組んであるのは
解読から変更に対する安全性の確認からなにからなにまで悪い事だらけ。
業務フローって言葉どおり、開発でも保守変更でも 要求仕様はフローチャートの形をしている。
フローチャート型に組んであるのは変更しやすいが、ステートモデルだのコマンドパターンだので組んであるのは
解読から変更に対する安全性の確認からなにからなにまで悪い事だらけ。
229 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 02:28:20
なぜフローがあってオブジェクトが無いのか
それは大きな組織単位ならオブジェクトはあるけど、
個々の人間が見えてくるスケールだと フローはあってもオブジェクトは無い。
なぜならば個々の人間は２４時間、一年３６５日働き続けるわけではないので休んだり交代したりするので
オブジェクト化された作業配分だと業務が止まってしまうからだ。
だからフローは保存されるけど、オブジェクトは保存されない。
大昔の平安時代あたりの業務分担だとオブジェクト化されていたけど。
誰かが病気になると組織止まるけど。
それは大きな組織単位ならオブジェクトはあるけど、
個々の人間が見えてくるスケールだと フローはあってもオブジェクトは無い。
なぜならば個々の人間は２４時間、一年３６５日働き続けるわけではないので休んだり交代したりするので
オブジェクト化された作業配分だと業務が止まってしまうからだ。
だからフローは保存されるけど、オブジェクトは保存されない。
大昔の平安時代あたりの業務分担だとオブジェクト化されていたけど。
誰かが病気になると組織止まるけど。
230 ：仕様書無しさん：2007/05/23(水) 02:42:22
トンデモ理論炸裂中ｗ
釣られたい・・・
なんでこんな美味しそうなエサをぶら下げられるんだ・・・
なんでこんな美味しそうなエサをぶら下げられるんだ・・・
また自演か
>>229
お前のオブジェクトって何よ？
データフローでもオブジェクト（に似たようなもの）は存在するぞ
まず、お前は用語を自分流に解釈することを止めろ
多分、お前って他人と自分の認識のズレによるバグが多くないか？
例えば自分はこの仕様はこう認識にしていたのに
相手側はこういう風に認識していたという感じの奴
そして、それは相手が未熟だからズレが生じているとか思ってないか？
だとしたらお前はかなり重症だ、処方箋はない。
お前のオブジェクトって何よ？
データフローでもオブジェクト（に似たようなもの）は存在するぞ
まず、お前は用語を自分流に解釈することを止めろ
多分、お前って他人と自分の認識のズレによるバグが多くないか？
例えば自分はこの仕様はこう認識にしていたのに
相手側はこういう風に認識していたという感じの奴
そして、それは相手が未熟だからズレが生じているとか思ってないか？
だとしたらお前はかなり重症だ、処方箋はない。
おかしなHN付けてる時点で、自己陶酔型のちょっと認知能力に問題がある
人間だということは明白だろう。
分かりやすく言えばストーカー気質のパーソナリティだと思われる。
相手に本気で拒絶されてるのに「ま～た恥かしがっちゃって」みたいな反応しかできないタイプだね
人間だということは明白だろう。
分かりやすく言えばストーカー気質のパーソナリティだと思われる。
相手に本気で拒絶されてるのに「ま～た恥かしがっちゃって」みたいな反応しかできないタイプだね
235 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 08:38:40
オセロで結果は出した。
それを踏まえて書くように
それを踏まえて書くように
236 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 08:56:44
インドのカースト制度もオブジェクト指向だな
237 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/23(水) 09:24:44
カーストこそ構造化だろう。
いまひどい自演を見た。悲しいね。
>>228
物凄く大事なところに間違いがあると思われ
物凄く大事なところに間違いがあると思われ
>>240
やつのいう「悪い事だらけ」とは、「自分が莫迦な所為でさっぱり理解できない」の意。
やつのいう「悪い事だらけ」とは、「自分が莫迦な所為でさっぱり理解できない」の意。
これからはマルチエージェント指向
243 ：仕様書無しさん：2007/05/23(水) 12:22:12
こいつ(>228)がいう業務仕様が、１つのタスクの中の処理の仕様ということであれば、
その処理自体はコマンドの中に実装されそう。
その処理自体はコマンドの中に実装されそう。
コボラ * OOPの話題 = カオス発生
一日スレを離れて、建設的な議論を期待して帰ってきたら、
大型釣堀場に変わってたｗ
平安時代って何よｗｗｗ
大型釣堀場に変わってたｗ
平安時代って何よｗｗｗ
246 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 18:56:57
行く川の流れは絶えずして、しかももとの水にあらず。
よどみに浮ぶうたかたは、かつ消えかつ結びて、久しく止とゞまる事なし。
世の中にある人と住家すみかと、またかくの如し。
よどみに浮ぶうたかたは、かつ消えかつ結びて、久しく止とゞまる事なし。
世の中にある人と住家すみかと、またかくの如し。
247 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/23(水) 19:16:24
つわものどもがゆめのあと。
248 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 19:20:57
平安時代から鎌倉時代にかけて、すでオブジェクトよりにフローのほうが良い事に気づいてた人がいた
249 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/23(水) 19:49:28
昔の人は川の水が変化する事は読めても、川自体が変化する事は読めなかったのだろう。
だからよお、オブジェクトとフローは別に対立概念じゃねえって。
いくらオブジェクト指向だからって、フローはシステムから無くなりゃしない。
逆に、手続き型のプログラムをスカラ値だけで書くことは出来るけど
見方を変えればintやlongだってオブジェクトだ。
いくらオブジェクト指向だからって、フローはシステムから無くなりゃしない。
逆に、手続き型のプログラムをスカラ値だけで書くことは出来るけど
見方を変えればintやlongだってオブジェクトだ。
前半は否定しないが、intやlongは流石に見方変えてもオブジェクトじゃないんじゃね？
Javaでは基本型だが、OOPLでは組み込み数値型もオブジェクト扱いってのは珍しくないぞ
単語にこだわりすぎたかな・・・。
整数型のオブジェクトはあると思うが、int型はメソッド無いだろ？
だからオブジェクトとは呼べないんじゃないかなって感じの意味でしたとさ
整数型のオブジェクトはあると思うが、int型はメソッド無いだろ？
だからオブジェクトとは呼べないんじゃないかなって感じの意味でしたとさ
254 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 21:06:31
intクラスやLongクラスあるだろ
255 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/23(水) 21:13:29
オブジェクト史観の人は
プログラム技術が
非構造化→構造化→オブジェクト指向
というように、オブジェクト指向を最初から最高位におき、一直線に進化してきたと思い込んでいる。
そしてプログラムの中にまで階級（クラス）の概念を持ち込み、階級闘争の種を撒く。
世代間闘争に持ち込もうとする考え方が文化大革命の紅衛兵に似てるし
オブジェクト指向を広めたのは共産主義者ではないのか？
プログラム技術が
非構造化→構造化→オブジェクト指向
というように、オブジェクト指向を最初から最高位におき、一直線に進化してきたと思い込んでいる。
そしてプログラムの中にまで階級（クラス）の概念を持ち込み、階級闘争の種を撒く。
世代間闘争に持ち込もうとする考え方が文化大革命の紅衛兵に似てるし
オブジェクト指向を広めたのは共産主義者ではないのか？
ここんとこの書き込みで電球のレベルが低いのが丸裸だな
あ、前からかｗ
あ、前からかｗ
電圧低すぎｗ
電力たったの1W。豆電球並みw
オブジェクト史観が歴史を歪曲していると言いたいのか
>>253
そういうのはC++ぐらいだぞ
そういうのはC++ぐらいだぞ
どういう学習をしたら電球のような知識が身に付くんだ？
上の奴も言ってるが、
構造化 VS オブジェクト指向 の図式になぜ持っていく必要があるのか謎。
知りたくもないけど。
そんなことよりも、電球よ。
お前友達いないだろ。
別にそのことでお前が寂しかろうが平気だろうが、それはどーでもいい。
しかしな、お前の周りに人がいないということは文面見てりゃ分かるのよ。
おじゃばも友達いなさそうだな。
文面から判断して申し訳ないが、はっきり言って二人とも人として嫌いだわ。
上の奴も言ってるが、
構造化 VS オブジェクト指向 の図式になぜ持っていく必要があるのか謎。
知りたくもないけど。
そんなことよりも、電球よ。
お前友達いないだろ。
別にそのことでお前が寂しかろうが平気だろうが、それはどーでもいい。
しかしな、お前の周りに人がいないということは文面見てりゃ分かるのよ。
おじゃばも友達いなさそうだな。
文面から判断して申し訳ないが、はっきり言って二人とも人として嫌いだわ。
何でもできるというのは中途半端ということなんだよな
ナイフは万能でも、あんまし使う機会はないだろ？
料理をする為に一番使いやすい刃物は包丁だ
ナイフで料理することはできなくは無いが包丁のようには使えない
業務フローを素直に表現できるのはデータフローだと思うし、
オブジェクト指向で業務フローを表現できなくは無いが、
別にオブジェクト指向である必然性は無いと思う。
で、さらにデータフローってリレーショナルDBとも相性がいいんだよね
DFDとER図、これは多分あと１０年は無くならないね
実はまだCOBOLで新規開発案件があったりするんだぜ
ナイフは万能でも、あんまし使う機会はないだろ？
料理をする為に一番使いやすい刃物は包丁だ
ナイフで料理することはできなくは無いが包丁のようには使えない
業務フローを素直に表現できるのはデータフローだと思うし、
オブジェクト指向で業務フローを表現できなくは無いが、
別にオブジェクト指向である必然性は無いと思う。
で、さらにデータフローってリレーショナルDBとも相性がいいんだよね
DFDとER図、これは多分あと１０年は無くならないね
実はまだCOBOLで新規開発案件があったりするんだぜ
>253
残念。int型の値がメソッド持ってる言語なんざザラにある。
残念。int型の値がメソッド持ってる言語なんざザラにある。
intクラス普通にあるのか。
狭い知識でしゃべって正直すまんかった。
狭い知識でしゃべって正直すまんかった。
Rubyとか？
266 ：仕様書無しさん：2007/05/24(木) 08:36:06
業務フローに限らず現実に存在するものを素直に表すのがオブジェクト指向なんだがな
267 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/24(木) 09:16:16
>>261
友達はいっぱいいるから、261の分析は信頼性が低いと言える。
友達はいっぱいいるから、261の分析は信頼性が低いと言える。
>別にオブジェクト指向である必然性は無いと思う。
必然性に駆られてするような設計しかしないなら、確かに
既存の方法論にしがみついておけば良いと思うよ。
窓際でｺﾎﾞﾙ案件に励んでください。
必然性に駆られてするような設計しかしないなら、確かに
既存の方法論にしがみついておけば良いと思うよ。
窓際でｺﾎﾞﾙ案件に励んでください。
>>267
もしもし、脳内のセリフがたれ流れてますよ。
もしもし、脳内のセリフがたれ流れてますよ。
270 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/24(木) 09:28:16
>>252
OOPL でも何でもない C ですら、すべての変数はオブジェクト。
OOPL でも何でもない C ですら、すべての変数はオブジェクト。
>>271 それではCのintのメソッドは？インスタンス変数は？
>>272
OOPL ではないので、そんなものありません。阿呆ですか？
OOPL ではないので、そんなものありません。阿呆ですか？
メソッドのないオブジェクトなんて、まるで>>273のようだ。
275 ：仕様書無しさん：2007/05/24(木) 13:43:14
>>273 Cのintをオブジェクトと言い張る根拠は？
オブジェクトと呼ぶべき物の条件は？
オブジェクトと呼ぶべき物の条件は？
>>275
RYFM
RYFM
>>276
YSLE
YSLE
278 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/24(木) 19:09:13
>>275
状態以外に動作も保持する。
状態以外に動作も保持する。
初期化も動作でしょうか？
人生.init();
java.lang.Mathのようにオブジェクトを生成しても無意味なクラスがあるならば
Cのintもメソッドのないオブジェクトと言えないか？
一部のオブジェクト指向論者って頭固いんじゃないの？
だからデザインパターンみたいなマニュアルとか、
オブジェクトの定義とかガチガチの自分の思想を他人に押し付けようとする
それが素晴らしいものならば、皆が使う。
そうでないならば、それは本当に素晴らしいものであるかを自問してみるといい
自問できずに「よいものはよい」で思考停止すると現在のコボラー以下の存在になるぞ
Cのintもメソッドのないオブジェクトと言えないか？
一部のオブジェクト指向論者って頭固いんじゃないの？
だからデザインパターンみたいなマニュアルとか、
オブジェクトの定義とかガチガチの自分の思想を他人に押し付けようとする
それが素晴らしいものならば、皆が使う。
そうでないならば、それは本当に素晴らしいものであるかを自問してみるといい
自問できずに「よいものはよい」で思考停止すると現在のコボラー以下の存在になるぞ
流行らない理由がこのスレに満載。
確かにOOを神格化して専門用語をばらまいてる奴が
このスレには多いな
そもそも「オブジェクト指向」という言葉自体が意味不明で、
それだけで敬遠されてる現状はある
流行らせたい・浸透させたいのなら
資格を作って用語や概念等の統一が無いと駄目だな
このスレには多いな
そもそも「オブジェクト指向」という言葉自体が意味不明で、
それだけで敬遠されてる現状はある
流行らせたい・浸透させたいのなら
資格を作って用語や概念等の統一が無いと駄目だな
284 ：仕様書無しさん：2007/05/25(金) 09:11:24
283はツッコミどころ満載だけどガマンガマン…
285 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/25(金) 09:28:30
それならば、リアカーもエンジンのない自動車と言えるのではないか？
287 ：仕様書無しさん：2007/05/25(金) 11:18:14
どれならば？ｗ
まずは自動車の教習所行ってこい
まずは自動車の教習所行ってこい
>>281
極端に言えば、「オブジェクト」という単語には「モノ」程度の意味しかありません。
# C が定義する「オブジェクト」が何なのかは、技術者の自覚があるなら
# 規格票をあたりましょう。
その「モノ」に「動作」と「状態」の両方をカプセル化する手法が「オブジェクト指向」
だというだけのことです。
>それが素晴らしいものならば、皆が使う。
どれだけ素晴らしくとも、敷居が高ければ使う人は限られてくるでしょう？
尤も、「敷居が高いから駄目なんだ」というのも正当な評価のひとつではあるでしょうけど。
# なので、私は「アーロンチェアは高いから駄目」と思っています。
極端に言えば、「オブジェクト」という単語には「モノ」程度の意味しかありません。
# C が定義する「オブジェクト」が何なのかは、技術者の自覚があるなら
# 規格票をあたりましょう。
その「モノ」に「動作」と「状態」の両方をカプセル化する手法が「オブジェクト指向」
だというだけのことです。
>それが素晴らしいものならば、皆が使う。
どれだけ素晴らしくとも、敷居が高ければ使う人は限られてくるでしょう？
尤も、「敷居が高いから駄目なんだ」というのも正当な評価のひとつではあるでしょうけど。
# なので、私は「アーロンチェアは高いから駄目」と思っています。
289 ：仕様書無しさん：2007/05/25(金) 11:27:29
コボラーは確かにダメなじじい多いからなあ。
まあ、要するに、アレだ。
定義うんぬんを議論するのもいいけどさ、
きちんと規約化してさ、
保守しやすくすりゃいいんじゃん？
（思考停止でごめんちょ）
まあ、要するに、アレだ。
定義うんぬんを議論するのもいいけどさ、
きちんと規約化してさ、
保守しやすくすりゃいいんじゃん？
（思考停止でごめんちょ）
>>281
「デザインパターンみたいなマニュアル」（笑）
「デザインパターンみたいなマニュアル」（笑）
必ずしもすばらしいものが受け入れられるとは限らない。歴史が示している。
コボラ * OOPの話題 = カオス発生ｗ
>>283
>そもそも「オブジェクト指向」という言葉自体が意味不明
意味不明なら調べましょうね。君が知らないだけだから。
>それだけで敬遠されてる現状はある
[訂正]→それだけで私は敬遠してしまっている
>流行らせたい・浸透させたいのなら
もうしてるから。君が知らないだけだよ。
>資格を作って用語や概念等の統一が無いと駄目だな
資格あるから。統一もされてるから。君が知らないだけだね。
釣りだったなら、おめでとう。
本気だったら、あまりに痛々しいから、もうROMにまわった方がいいよ。
コボル頑張ってね、おじいちゃん。
>そもそも「オブジェクト指向」という言葉自体が意味不明
意味不明なら調べましょうね。君が知らないだけだから。
>それだけで敬遠されてる現状はある
[訂正]→それだけで私は敬遠してしまっている
>流行らせたい・浸透させたいのなら
もうしてるから。君が知らないだけだよ。
>資格を作って用語や概念等の統一が無いと駄目だな
資格あるから。統一もされてるから。君が知らないだけだね。
釣りだったなら、おめでとう。
本気だったら、あまりに痛々しいから、もうROMにまわった方がいいよ。
コボル頑張ってね、おじいちゃん。
COBOLを馬鹿にする奴は、大概、COBOLの本質を理解していないOO気触れだ。
COBOLの本質になど興味は無いｗｗｗｗｗｗ
見当違いのOOP批判がどうしても鼻についただけｗｗｗｗｗ
見当違いのOOP批判がどうしても鼻についただけｗｗｗｗｗ
特定の言語とその処理系を馬鹿にしてなぞいない。
その言語の限界とコンピューティングの限界を同一視している人を馬鹿にしているだけさ。
その言語の限界とコンピューティングの限界を同一視している人を馬鹿にしているだけさ。
過保護な言語に甘える奴はスクリプトでも弄っときな。
過去の遺産にしがみつく老害は、スパゲティコードで萎れたチンコでも弄っときな。
Cに対するオブジェクト指向言語の例でC++でなくC#を挙げる本があったんですが
これはC#に比べてC++が圧倒的にオブジェクト指向に向いてないって事なんでしょうか？
これはC#に比べてC++が圧倒的にオブジェクト指向に向いてないって事なんでしょうか？
A. C++ は OOPL とは認めないよ派の人が書いた
B. C++ 本は世間に溢れてるから、C# の本の方が売れると思った
C. C++ 本なんか書いたらハゲるという強迫観念があった
B. C++ 本は世間に溢れてるから、C# の本の方が売れると思った
C. C++ 本なんか書いたらハゲるという強迫観念があった
／￣＼♯♯♯
｜ ♯♯♯
＼＿／♯♯♯
｜ ♯♯♯
＼＿／♯♯♯
304 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/25(金) 18:53:27
>>302
D. C++ を良く知らない人が書いた。
D. C++ を良く知らない人が書いた。
ﾈﾀと言えど、糞ｺﾃに乗っかられると不愉快です。
>>293
>>資格を作って用語や概念等の統一が無いと駄目だな
>資格あるから。統一もされてるから。君が知らないだけだね。
オブジェクト指向の資格ってなんだ？
まさかUML技術者とか言ってんの？
本気だったら、あまりに痛々しいから、もうROMにまわった方がいいよ。
就職頑張ってね、おじいちゃん。
>>資格を作って用語や概念等の統一が無いと駄目だな
>資格あるから。統一もされてるから。君が知らないだけだね。
オブジェクト指向の資格ってなんだ？
まさかUML技術者とか言ってんの？
本気だったら、あまりに痛々しいから、もうROMにまわった方がいいよ。
就職頑張ってね、おじいちゃん。
_,＿＿＿
／ ＿_｀ヾ),_
/〃 (⌒゛`ヾｖ"ヽﾐ､
i / /´ おじゃば.i l|
| 彳 〃_. _ヾ!/ ／￣￣￣￣￣￣￣￣￣
| _ !" ´ﾟ｀冫く´ﾟ｀l ＜ C++ を良く知らない人が書いた。
（^ゝ " ,ｒ_､_.)、 |,,.. -─‐＼＿＿＿＿＿＿＿＿__
ヽ_j ､ /,.ｰ=-／ : : : : : >>302::）ﾉ:ヽ
＼_ "ヽ ^/ : : : : : : ｿ⌒ﾞヾ"ヾ､ : :ヽ
／⌒ - - ! : : : : : : ） ⌒ ⌒ヾ :(_,
／ ／| | : : : : :(, ＿ ） __ ）!:_ﾉ
＼ ＼|≡∨ ヽ （aイ ´ﾟ i | . ﾟ｀〈 ／￣￣￣￣￣￣￣￣￣
＼⊇ ＼:_| " . ノ ､_)､ ﾞ.ﾉ ＜ 乗っかられると不愉快です。
| (_ｿ人 ｌ ｰ=‐;! ﾉ ＼＿＿＿＿＿＿＿＿＿
（ ／⌒ｖ⌒＼ ＼ヽ＿_,ﾉ
ﾊﾟﾝﾊﾟﾝ| 丶／⌒ - - ＼
/ ＼ | | / |
/ ノ＼＿_| |・_三_・ノ| |
/ /ﾊﾟﾝﾊﾟﾝ| | | |
/＿_/ | | | |
⊆ | ｜ ⊇
／ ＿_｀ヾ),_
/〃 (⌒゛`ヾｖ"ヽﾐ､
i / /´ おじゃば.i l|
| 彳 〃_. _ヾ!/ ／￣￣￣￣￣￣￣￣￣
| _ !" ´ﾟ｀冫く´ﾟ｀l ＜ C++ を良く知らない人が書いた。
（^ゝ " ,ｒ_､_.)、 |,,.. -─‐＼＿＿＿＿＿＿＿＿__
ヽ_j ､ /,.ｰ=-／ : : : : : >>302::）ﾉ:ヽ
＼_ "ヽ ^/ : : : : : : ｿ⌒ﾞヾ"ヾ､ : :ヽ
／⌒ - - ! : : : : : : ） ⌒ ⌒ヾ :(_,
／ ／| | : : : : :(, ＿ ） __ ）!:_ﾉ
＼ ＼|≡∨ ヽ （aイ ´ﾟ i | . ﾟ｀〈 ／￣￣￣￣￣￣￣￣￣
＼⊇ ＼:_| " . ノ ､_)､ ﾞ.ﾉ ＜ 乗っかられると不愉快です。
| (_ｿ人 ｌ ｰ=‐;! ﾉ ＼＿＿＿＿＿＿＿＿＿
（ ／⌒ｖ⌒＼ ＼ヽ＿_,ﾉ
ﾊﾟﾝﾊﾟﾝ| 丶／⌒ - - ＼
/ ＼ | | / |
/ ノ＼＿_| |・_三_・ノ| |
/ /ﾊﾟﾝﾊﾟﾝ| | | |
/＿_/ | | | |
⊆ | ｜ ⊇
概念の統一？
複数のOO、複数の教祖が存在するのに。
そんなことが可能な訳が
複数のOO、複数の教祖が存在するのに。
そんなことが可能な訳が
309 ：仕様書無しさん：2007/05/25(金) 21:46:16
頭固くてOOを理解できないだけなのに、そこでCOBOL賛辞に走るのが理解できない。
>資格
OOP一般を対象にした資格なんて聞いたことねえな。金払うやついるのか
一番近いのは、SCJPやらのサン資格かな。
>概念
基本概念は統一されてるだろ。Inheritance、Polymorphism、Encapsulation。
OOPを元にした言語の授業に出れば、必ず出てくる。
>資格
OOP一般を対象にした資格なんて聞いたことねえな。金払うやついるのか
一番近いのは、SCJPやらのサン資格かな。
>概念
基本概念は統一されてるだろ。Inheritance、Polymorphism、Encapsulation。
OOPを元にした言語の授業に出れば、必ず出てくる。
310 ：仕様書無しさん：2007/05/25(金) 22:18:34
結局、おまいらOOを使ってるのか？
他にも実用的な例でGRASPパターンとか色々あるけど適当に挙げてくれないかな
>>308
UMLは一応統一したな。表記方法だけだけどな
ところで、お前ら本当にデータとそのデータを操るメソッドは結び付けなければならないと思ってる？
shのようにデータとコマンドがパラパラでもいいんじゃね？
そしてパイプで繋げて単純なコマンドを組み合わせて複雑なデータ操作を行う
そういうアプローチ方法は邪道ですか？
UMLは一応統一したな。表記方法だけだけどな
ところで、お前ら本当にデータとそのデータを操るメソッドは結び付けなければならないと思ってる？
shのようにデータとコマンドがパラパラでもいいんじゃね？
そしてパイプで繋げて単純なコマンドを組み合わせて複雑なデータ操作を行う
そういうアプローチ方法は邪道ですか？
それがiterator pattern
>309
英単語検索乙
英単語検索乙
>>312
別に邪道ではない。
unixに代表されるツールボックスアプローチは現在も有効な局面は多々ある。
しかしながらこの方法は「データは単純なバイト列」という前提が必須なのだ。
このアプローチの必須な前提を満たすためにどれだけのデメリットが発生するかはご自身で検討されたい。
思うに。
OOPの「多種多様なデータをカプセル化する」という一側面は、
ツールボックスとは別方向からのアプローチであることの証拠だね。
別に邪道ではない。
unixに代表されるツールボックスアプローチは現在も有効な局面は多々ある。
しかしながらこの方法は「データは単純なバイト列」という前提が必須なのだ。
このアプローチの必須な前提を満たすためにどれだけのデメリットが発生するかはご自身で検討されたい。
思うに。
OOPの「多種多様なデータをカプセル化する」という一側面は、
ツールボックスとは別方向からのアプローチであることの証拠だね。
単純なバイト列のデータとそうでないデータの違いが分かりません。
>>315
OOPの基本思想が「データをカプセル化」することであるならば
DBみたいにデータは誰にでも見れるようなシステムとは相性悪そうだな
基本的に業務システムはデータは単純なバイト列でどうにかなる局面が多いし
多種多様なデータはDBに突っ込むかXMLにするだろ？
XMLも少し複雑なテキストファイルに過ぎない
オブジェクト設計が有効な場所は多分、画面のような状態を持った局面が有効だと思うけど
最近はブラウザ＆Javascriptでどうにかしてしまうからな
おそらく、オブジェクト設計が有効なシステムは信者が思っているほど多くないよ
ま、FATクライアントを作りたいならオブジェクト指向は有効だと思うよ
OOPの基本思想が「データをカプセル化」することであるならば
DBみたいにデータは誰にでも見れるようなシステムとは相性悪そうだな
基本的に業務システムはデータは単純なバイト列でどうにかなる局面が多いし
多種多様なデータはDBに突っ込むかXMLにするだろ？
XMLも少し複雑なテキストファイルに過ぎない
オブジェクト設計が有効な場所は多分、画面のような状態を持った局面が有効だと思うけど
最近はブラウザ＆Javascriptでどうにかしてしまうからな
おそらく、オブジェクト設計が有効なシステムは信者が思っているほど多くないよ
ま、FATクライアントを作りたいならオブジェクト指向は有効だと思うよ
大概のDBにはアクセス制限かけられますが。
>286
「組込整数がオブジェクト」な言語の中に
「演算子は整数クラスのメソッド」って扱いの言語もあるね。
「組込整数がオブジェクト」な言語の中に
「演算子は整数クラスのメソッド」って扱いの言語もあるね。
なんかさー、
コンピューター使う理由って、ラクするためってのが基本じゃん。
オブジェクト指向ってさー、
設計段階でえらい大変だけどさー、
それによって最終青果物がいいものになるかって言われると
別に実感わかないんだよねー
なんかさー、
最終的にいいものを作るっていう目的よりも
オブジェクト指向で作る、ってのが目的になってるよーで
微妙なんだよねー
コンピューター使う理由って、ラクするためってのが基本じゃん。
オブジェクト指向ってさー、
設計段階でえらい大変だけどさー、
それによって最終青果物がいいものになるかって言われると
別に実感わかないんだよねー
なんかさー、
最終的にいいものを作るっていう目的よりも
オブジェクト指向で作る、ってのが目的になってるよーで
微妙なんだよねー
お前はエンドユーザかw
手段の自己目的化
プログラミングも楽をするために存在する
どっかの真田じゃあるまいし「こんなこともあろうかと」なんて無駄なことはするな
eep It Simple, Stupidを知らないと使うべきでない箇所で
無駄に汎用性の高いデザインパターンを使いたがる
デザインパターンを使いたがる奴は間違いなく厨二病患者
まともなプログラマなら、仕様が複雑になったから仕方なしに使う。
オブジェクト指向も使うべきときに使えばいい
何でもかんでもオブジェクト指向で何とかしようとする奴は
「馬鹿の一つ覚え」と言う
どっかの真田じゃあるまいし「こんなこともあろうかと」なんて無駄なことはするな
eep It Simple, Stupidを知らないと使うべきでない箇所で
無駄に汎用性の高いデザインパターンを使いたがる
デザインパターンを使いたがる奴は間違いなく厨二病患者
まともなプログラマなら、仕様が複雑になったから仕方なしに使う。
オブジェクト指向も使うべきときに使えばいい
何でもかんでもオブジェクト指向で何とかしようとする奴は
「馬鹿の一つ覚え」と言う
>>320
あのさー
ゲームにおけるコンピュータの使い方はさー
放り出さない程度に難しくてめんどくさい事をユーザーにやらせる事なんだなー
これをゲームバランスっちゅーんだなー
エクセルやワードとは違うんだなー
力の限りラクチン簡単にしてしまったらゲームにならないんだなー
あのさー
ゲームにおけるコンピュータの使い方はさー
放り出さない程度に難しくてめんどくさい事をユーザーにやらせる事なんだなー
これをゲームバランスっちゅーんだなー
エクセルやワードとは違うんだなー
力の限りラクチン簡単にしてしまったらゲームにならないんだなー
>>325
誤爆した、メンゴ
誤爆した、メンゴ
でもさー、
毎年のようにマシンスペックとか上がってるけどさー、
それで仕事が劇的に速くなったってことはなくってさー、
それどころか.NetとかAjaxとか覚えることいろいろあってさー、
作る側はなんか全然ラクにならないんだよねー
技術者にもできる人とできない人がいて、
新しいこと覚える人も覚えない人もいて、
エロい人が多分いい技術を世に出してくれてるんだろーけどさー
技術者側が疲れちゃってるような気がするんだよねー
XPだー、CMMだー、PMBOKだー
とか手法とかもいろいろあるしさー
技術者って頑張りっぱなしだなーって
毎年のようにマシンスペックとか上がってるけどさー、
それで仕事が劇的に速くなったってことはなくってさー、
それどころか.NetとかAjaxとか覚えることいろいろあってさー、
作る側はなんか全然ラクにならないんだよねー
技術者にもできる人とできない人がいて、
新しいこと覚える人も覚えない人もいて、
エロい人が多分いい技術を世に出してくれてるんだろーけどさー
技術者側が疲れちゃってるような気がするんだよねー
XPだー、CMMだー、PMBOKだー
とか手法とかもいろいろあるしさー
技術者って頑張りっぱなしだなーって
それがマの宿命。いやなら辞めろ。
技術オタじゃないとマはやっていけないという事ですか
なんかさー
ラクをするためのものを作るんだから
もうちょっとラクして作りたいんだよねー
ラクをするためのものを作るんだから
もうちょっとラクして作りたいんだよねー
あと100年待て
自分の仕事は自分で楽にするのが優秀なマ。愚痴ってばかりの奴はカス。
いろんなCASEツールを使いこなすだけでもだいぶ違うと思う
バッチ処理とか利用したらUML使った設計と同時にテストの作成も行い
それらを反復することを殆ど自動で行うとか出来るし
便利な時代になったもんだ
バッチ処理とか利用したらUML使った設計と同時にテストの作成も行い
それらを反復することを殆ど自動で行うとか出来るし
便利な時代になったもんだ
教条主義に生きて幸福ならそれでいいじゃん
周囲に迷惑かけない限りw
周囲に迷惑かけない限りw
336 ：仕様書無しさん：2007/05/26(土) 04:41:01
>>新しいクラスを勝手に作ってはいけません。
>>private class禁止。
今のプロジェクトこんな感じ、もう死にそうだお。
>>private class禁止。
今のプロジェクトこんな感じ、もう死にそうだお。
337 ：仕様書無しさん：2007/05/26(土) 04:54:48
､--‐冖'⌒￣￣`ｰ-､
／⌒` 三ミヽｰ-ﾍ,_
__,{ ;;,, ミミ ｉ ´Z,
ゝ ''〃//,,, ,,..｀ミﾐ､_ノリ}j; f彡
_) 〃///, ,;彡'rffｯ､ｨ彡'ﾉ从iﾉ彡
>';;,, ノ丿川j !川｜; :.`7ﾗ公 '>了
_く彡川fﾞノ'ノﾉ ノ_ノノﾉイシﾉ｜ }.: '〈八ﾐ､､;.)
ヽ.:.:.:.:.:.;=､彡／‐-ニ''_ｰ＜、{_,ﾉ -一ヾ`~;.;.;）
く .:.:.:.:.:!ﾊ.Yイ ぇ'无ﾃ,`ヽ｝｝}ィt于 ｀|ィ"~
):.:.:.:.:|.Y }: :! ｀二´/' ; |丶ﾆ ﾉﾉ
） :.: ﾄ､リ: :!ヾ:、 丶 ; | ﾞ ｲ:} 逆に考えるんだ
｛ .:.: ｌ ｛: : } ｀ ,.__(__,} /ﾉ
ヽ ! `'ﾞ! ,.,,.`三'ﾞ､,_ /´ 「public禁止よりマシ」と
,/´{ ﾐ l /ﾞ,:-…-～､ ） |
,r{ ＼ ﾐ ＼ `' '≡≡' " ﾉ 考えるんだ
__ノ ヽ ＼ ヽ＼ 彡 ,ｲ_
＼ ＼ ヽ 丶. ノ!|ヽ｀ヽ、
＼ ＼ヽ ｀¨¨¨¨´/ |ｌ ト､ ｀'ｰ-､__
＼ ｀'ｰ-､ /／ /:.:.} ｀'ｰ､_
｀､＼ ／⌒ヽ /!:.:.|
｀､ ＼ /ヽLｆ___ハ/ {
／⌒` 三ミヽｰ-ﾍ,_
__,{ ;;,, ミミ ｉ ´Z,
ゝ ''〃//,,, ,,..｀ミﾐ､_ノリ}j; f彡
_) 〃///, ,;彡'rffｯ､ｨ彡'ﾉ从iﾉ彡
>';;,, ノ丿川j !川｜; :.`7ﾗ公 '>了
_く彡川fﾞノ'ノﾉ ノ_ノノﾉイシﾉ｜ }.: '〈八ﾐ､､;.)
ヽ.:.:.:.:.:.;=､彡／‐-ニ''_ｰ＜、{_,ﾉ -一ヾ`~;.;.;）
く .:.:.:.:.:!ﾊ.Yイ ぇ'无ﾃ,`ヽ｝｝}ィt于 ｀|ィ"~
):.:.:.:.:|.Y }: :! ｀二´/' ; |丶ﾆ ﾉﾉ
） :.: ﾄ､リ: :!ヾ:、 丶 ; | ﾞ ｲ:} 逆に考えるんだ
｛ .:.: ｌ ｛: : } ｀ ,.__(__,} /ﾉ
ヽ ! `'ﾞ! ,.,,.`三'ﾞ､,_ /´ 「public禁止よりマシ」と
,/´{ ﾐ l /ﾞ,:-…-～､ ） |
,r{ ＼ ﾐ ＼ `' '≡≡' " ﾉ 考えるんだ
__ノ ヽ ＼ ヽ＼ 彡 ,ｲ_
＼ ＼ ヽ 丶. ノ!|ヽ｀ヽ、
＼ ＼ヽ ｀¨¨¨¨´/ |ｌ ト､ ｀'ｰ-､__
＼ ｀'ｰ-､ /／ /:.:.} ｀'ｰ､_
｀､＼ ／⌒ヽ /!:.:.|
｀､ ＼ /ヽLｆ___ハ/ {
>>327
プログラマーとは楽をするためにはどんな苦労もいとわない人種の事なんだよ。
メキシコの田舎町。海岸に小さなボートが停泊していた。
メキシコ人の漁師が小さな網に魚をとってきた。
その魚はなんとも生きがいい。それを見たアメリカ人旅行者は、
「すばらしい魚だね。どれくらいの時間、漁をしていたの」 と尋ねた。
すると漁師は
「そんなに長い時間じゃないよ」
と答えた。旅行者が
「もっと漁をしていたら、もっと魚が獲れたんだろうね。おしいなあ」
と言うと、
漁師は、自分と自分の家族が食べるにはこれで十分だと言った。
「それじゃあ、あまった時間でいったい何をするの」
と旅行者が聞くと、漁師は、
「日が高くなるまでゆっくり寝て、それから漁に出る。戻ってきたら子どもと遊んで、
女房とシエスタして。 夜になったら友達と一杯やって、ギターを弾いて、
歌をうたって…ああ、これでもう一日終わりだね」
プログラマーとは楽をするためにはどんな苦労もいとわない人種の事なんだよ。
メキシコの田舎町。海岸に小さなボートが停泊していた。
メキシコ人の漁師が小さな網に魚をとってきた。
その魚はなんとも生きがいい。それを見たアメリカ人旅行者は、
「すばらしい魚だね。どれくらいの時間、漁をしていたの」 と尋ねた。
すると漁師は
「そんなに長い時間じゃないよ」
と答えた。旅行者が
「もっと漁をしていたら、もっと魚が獲れたんだろうね。おしいなあ」
と言うと、
漁師は、自分と自分の家族が食べるにはこれで十分だと言った。
「それじゃあ、あまった時間でいったい何をするの」
と旅行者が聞くと、漁師は、
「日が高くなるまでゆっくり寝て、それから漁に出る。戻ってきたら子どもと遊んで、
女房とシエスタして。 夜になったら友達と一杯やって、ギターを弾いて、
歌をうたって…ああ、これでもう一日終わりだね」
338 つづき
すると旅行者はまじめな顔で漁師に向かってこう言った。
「ハーバード・ビジネス・スクールでＭＢＡを取得した人間として、
きみにアドバイスしよう。いいかい、きみは毎日、もっと長い時間、
漁をするべきだ。 それであまった魚は売る。
お金が貯まったら大きな漁船を買う。そうすると漁獲高は上がり、儲けも増える。
その儲けで漁船を２隻、３隻と増やしていくんだ。やがて大漁船団ができるまでね。
そうしたら仲介人に魚を売るのはやめだ。
自前の水産品加工工場を建てて、そこに魚を入れる。
その頃にはきみはこのちっぽけな村を出てメキソコシティに引っ越し、
ロサンゼルス、ニューヨークへと進出していくだろう。
きみはマンハッタンのオフィスビルから企業の指揮をとるんだ」
すると旅行者はまじめな顔で漁師に向かってこう言った。
「ハーバード・ビジネス・スクールでＭＢＡを取得した人間として、
きみにアドバイスしよう。いいかい、きみは毎日、もっと長い時間、
漁をするべきだ。 それであまった魚は売る。
お金が貯まったら大きな漁船を買う。そうすると漁獲高は上がり、儲けも増える。
その儲けで漁船を２隻、３隻と増やしていくんだ。やがて大漁船団ができるまでね。
そうしたら仲介人に魚を売るのはやめだ。
自前の水産品加工工場を建てて、そこに魚を入れる。
その頃にはきみはこのちっぽけな村を出てメキソコシティに引っ越し、
ロサンゼルス、ニューヨークへと進出していくだろう。
きみはマンハッタンのオフィスビルから企業の指揮をとるんだ」
「日が高くなるまでゆっくり寝て、それから漁に出る。戻ってきたら子どもと遊んで、
女房とシエスタして。 夜になったら友達と一杯やって、ギターを弾いて、
歌をうたって…ああ、これでもう一日終わりだね」
女房とシエスタして。 夜になったら友達と一杯やって、ギターを弾いて、
歌をうたって…ああ、これでもう一日終わりだね」
339 つづき
漁師は尋ねた。
「そうなるまでにどれくらいかかるのかね」
「二〇年、いやおそらく二五年でそこまでいくね」
「それからどうなるの」
「それから？ そのときは本当にすごいことになるよ」
と旅行者はにんまりと笑い、
「今度は株を売却して、きみは億万長者になるのさ」
「それで？」
「そうしたら引退して、海岸近くの小さな村に住んで、
日が高くなるまでゆっくり寝て、 日中は釣りをしたり、
子どもと遊んだり、奥さんとシエスタして過ごして、
夜になったら友達と一杯やって、ギターを弾いて、
歌をうたって過ごすんだ。 どうだい。すばらしいだろう」
儲ける前と儲けた後はやっている事は同じだが何か違う気がするんだな・・・
ああ俺は後者がいい
漁師は尋ねた。
「そうなるまでにどれくらいかかるのかね」
「二〇年、いやおそらく二五年でそこまでいくね」
「それからどうなるの」
「それから？ そのときは本当にすごいことになるよ」
と旅行者はにんまりと笑い、
「今度は株を売却して、きみは億万長者になるのさ」
「それで？」
「そうしたら引退して、海岸近くの小さな村に住んで、
日が高くなるまでゆっくり寝て、 日中は釣りをしたり、
子どもと遊んだり、奥さんとシエスタして過ごして、
夜になったら友達と一杯やって、ギターを弾いて、
歌をうたって過ごすんだ。 どうだい。すばらしいだろう」
儲ける前と儲けた後はやっている事は同じだが何か違う気がするんだな・・・
ああ俺は後者がいい
342 ：仕様書無しさん：2007/05/26(土) 06:28:54
底辺PGが最低限の暮らしをするには、朝から晩まで魚をとり続けなきゃならんから、
その例は当てはまらないけどな。
その例は当てはまらないけどな。
最終青果物…
野菜かっ＼(゜□゜)
野菜かっ＼(゜□゜)
作ってくれるなら使うけど、
自分で作るのは面倒だからイヤ。
だからOOPは流行らない。
自分で作るのは面倒だからイヤ。
だからOOPは流行らない。
>>344
そしてバカが増える、と・・
そしてバカが増える、と・・
>>320
> オブジェクト指向ってさー、
> 設計段階でえらい大変だけどさー、
OOPの不勉強を棚に上げるな。
> それによって最終青果物がいいものになるかって言われると
> 別に実感わかないんだよねー
OOPの不勉強を棚に上げるな。
> 最終的にいいものを作るっていう目的よりも
> オブジェクト指向で作る、ってのが目的になってるよーで
> 微妙なんだよねー
それこそが間違っている証。有利になるから好んで使うのが普通。
オブジェクト指向で作る、なんていうのを目的に設定するのが愚かすぎ。
オブジェクト指向を神格化、という単語がうえのほうに出てきたが、
まさにこういう連中にこそ言ってやりたい。豚に真珠。
> コンピューター使う理由って、ラクするためってのが基本じゃん。
そのためのOOPです。それが分かりませんか？
ただし、銀の弾丸である、ということを言ってるのではない。
有利になる場合があれば、それは使うし、ラクになるということ。
けっして、不純な理由で無理矢理使ったりはしない。
> オブジェクト指向ってさー、
> 設計段階でえらい大変だけどさー、
OOPの不勉強を棚に上げるな。
> それによって最終青果物がいいものになるかって言われると
> 別に実感わかないんだよねー
OOPの不勉強を棚に上げるな。
> 最終的にいいものを作るっていう目的よりも
> オブジェクト指向で作る、ってのが目的になってるよーで
> 微妙なんだよねー
それこそが間違っている証。有利になるから好んで使うのが普通。
オブジェクト指向で作る、なんていうのを目的に設定するのが愚かすぎ。
オブジェクト指向を神格化、という単語がうえのほうに出てきたが、
まさにこういう連中にこそ言ってやりたい。豚に真珠。
> コンピューター使う理由って、ラクするためってのが基本じゃん。
そのためのOOPです。それが分かりませんか？
ただし、銀の弾丸である、ということを言ってるのではない。
有利になる場合があれば、それは使うし、ラクになるということ。
けっして、不純な理由で無理矢理使ったりはしない。
>>346
単純にOOPムズいんだよ。
開発対象を抽象的なクラスに分割するのが既にムズい。
ネットで「OOPとは」って書いてあるところは理解出来るが、
それ以上はサッパリ分からない。
それと、この部分。
＞ > 設計段階でえらい大変だけどさー、
＞ OOPの不勉強を棚に上げるな。
OOP不勉強云々じゃなくて、>>320が普段設計サボってるだけ。
OOPじゃなくても設計はえらい大変。
ただ、OOPでやると、設計ちゃんと終わらせないと先に進まなくなるだけ。
単純にOOPムズいんだよ。
開発対象を抽象的なクラスに分割するのが既にムズい。
ネットで「OOPとは」って書いてあるところは理解出来るが、
それ以上はサッパリ分からない。
それと、この部分。
＞ > 設計段階でえらい大変だけどさー、
＞ OOPの不勉強を棚に上げるな。
OOP不勉強云々じゃなくて、>>320が普段設計サボってるだけ。
OOPじゃなくても設計はえらい大変。
ただ、OOPでやると、設計ちゃんと終わらせないと先に進まなくなるだけ。
>>347
そりゃあ、いっちゃあ悪いけど君に適性が無いんだよ。
俺にはむしろクラスに分割するのが難しい、とかOOPが難しいって感覚が理解できない。
むしろ、なるほどOOPを使うとこのように複雑性が縮減されるのか、
という感慨を持つのが普通のPGがOOP使えるようになったときに感じる普通の感覚だと思う。
そりゃあ、いっちゃあ悪いけど君に適性が無いんだよ。
俺にはむしろクラスに分割するのが難しい、とかOOPが難しいって感覚が理解できない。
むしろ、なるほどOOPを使うとこのように複雑性が縮減されるのか、
という感慨を持つのが普通のPGがOOP使えるようになったときに感じる普通の感覚だと思う。
>>348
いや、ぶっちゃけ適性無いんだろうなぁ。
指定した日付の時間単位でメモ出来るカレンダーを
JAVA使ってためしに作って他の人に見せたとき、
指定要素数のリスト構造を持ったクラスを作って
そこから継承して年クラス、月クラス、日クラス、時間クラスまで作ったら、
「クラス、細かく作りすぎ」言われた。
年月日クラス1つで良いらしい。
似た様な性質のモノはクラス作るんじゃないのか？
よく分からん。
と、こんなレベル。
デカい構造のプログラム全体を1度に把握出来るほど頭良くないから
OOPとか出来るようになりたいんだが、別の道を探すべきか・・・orz
いや、ぶっちゃけ適性無いんだろうなぁ。
指定した日付の時間単位でメモ出来るカレンダーを
JAVA使ってためしに作って他の人に見せたとき、
指定要素数のリスト構造を持ったクラスを作って
そこから継承して年クラス、月クラス、日クラス、時間クラスまで作ったら、
「クラス、細かく作りすぎ」言われた。
年月日クラス1つで良いらしい。
似た様な性質のモノはクラス作るんじゃないのか？
よく分からん。
と、こんなレベル。
デカい構造のプログラム全体を1度に把握出来るほど頭良くないから
OOPとか出来るようになりたいんだが、別の道を探すべきか・・・orz
>>349 複雑に考えすぎ。んなもん、配列とハッシュだけでできる。
シンプルイズベスト。分かり易さを犠牲にしてなんの技術か。
シンプルイズベスト。分かり易さを犠牲にしてなんの技術か。
組込み一度でもやれば
OOPなんてLSIだと思えば
別にどうということもない。
クラスが旨く組めないのは別の問題。
分割の下手な回路設計なんか幾らでもあるw。
OOPなんてLSIだと思えば
別にどうということもない。
クラスが旨く組めないのは別の問題。
分割の下手な回路設計なんか幾らでもあるw。
>347
設計をちゃんと終わらせなくても先に進まないことはないぞ。
むしろ中途半端なままでも進めることができる。
これはOOPに限った話ではないと思うがな。
あれこれ突っ込むと「難しい」って逃げる奴は、
大概頭悪くて理解できないか理解しようとしないクソ。
OO批判するやつはOOの良いところと悪いところ、
今までのやりかたの良いところと悪いところをちゃんと把握した上で批判しろ。
設計をちゃんと終わらせなくても先に進まないことはないぞ。
むしろ中途半端なままでも進めることができる。
これはOOPに限った話ではないと思うがな。
あれこれ突っ込むと「難しい」って逃げる奴は、
大概頭悪くて理解できないか理解しようとしないクソ。
OO批判するやつはOOの良いところと悪いところ、
今までのやりかたの良いところと悪いところをちゃんと把握した上で批判しろ。
特定の時刻って本質にたいして、年月日ってのは表現だと考えたほうがシンプルだわな。
この流れで配列とかハッシュとかの話を出す奴は失格だなｗ
むしろコード書き始めるまえの設計なんてものに、あまり信用をおかないのが最近の傾向だな。
設計が途中で変わったり機能が追加されたときに、影響範囲を極小化したり、デグレしないように
工夫したりするのがオブジェクト指向の利点なんじゃね？
オープンクローズドの原則とかDIとかデザパタとかテストケースとかリファクタリングとか使ってさ
設計が途中で変わったり機能が追加されたときに、影響範囲を極小化したり、デグレしないように
工夫したりするのがオブジェクト指向の利点なんじゃね？
オープンクローズドの原則とかDIとかデザパタとかテストケースとかリファクタリングとか使ってさ
>>351-355 全然ダメ。はやめに別の仕事探した方がいいよ。
反復型開発とかアジャイルとかいうやつか
メモ帳アプリで時間クラスとかありえねぇwww
下位レイヤのソフトウェアでリソースがカツカツの環境で、
のんきにオブジェクト指向とか言ってられない。
コードサイズ全部で64Kとか言われてる状況で
レジスタアクセスのためのクラスなんて作れない。
usecオーダー、nsecオーダーのタイミングで頑張ってるのに、
メソッドをコールするオーバーヘッドが辛いです。
そもそも環境上ソースコードはCかアセンブラでしか書けないのに
オブジェクト指向な設計されても実装しづらいよ・・・。
いやまぁ、冗談だけどね。
のんきにオブジェクト指向とか言ってられない。
コードサイズ全部で64Kとか言われてる状況で
レジスタアクセスのためのクラスなんて作れない。
usecオーダー、nsecオーダーのタイミングで頑張ってるのに、
メソッドをコールするオーバーヘッドが辛いです。
そもそも環境上ソースコードはCかアセンブラでしか書けないのに
オブジェクト指向な設計されても実装しづらいよ・・・。
いやまぁ、冗談だけどね。
>>356 のようなニートって多いですね＾＾
ＯＯ設計が流行らないのは、それだけでは次工程のプログラマたちが「効率アップした！」とか
「プログラミングが楽になった！」って実感がないからでは？いや、逆に、「難しくって、やりにくい」とか
「ＯＯで、プログラミングの効率が悪化した！」って思うことが多いからではないでしょうか？
ここ１年くらい、Ｃ＋＋が気になって、「Ｃ＋＋の設計と進化」をスタートに、Ｃ＋＋の定番とされる本を約２０冊くらい購入しました。
それらを読んで、感じたのは
「ＯＯ設計は必要。でも、具体的なプログラミングを効率化するには、それだけでは役にたたない」
「プログラム実装の世界には、その世界で効率化する手法がある。特にＣ＋＋では、「ＯＯＰとは無縁」のテンプレート
を活用したＳＴＬとか、ジェネリックプログラム技法が重要で、それらを活用するとき、上位概念としてＯＯＰが役
にたつ。」って感じました。
たぶん、技術者として、マスターする大変さを考えてみれば、ＯＯ設計なら、頭が良い方なら、がり勉すれば、ＩＴ業界未経験の
ど素人でも、一週間程度でマスターできるかもしれません。でも、Ｃ＋＋のＳＴＬやジェネリックプログラミング技法のマスターは
不可能でしょう。たぶん、Ｃ＋＋以前のＣ言語の段階も無理でしょうね。
それは、短期のがり勉で建築士の試験だけに合格できても、すばらしい技術を持つ宮大工になれないのと同じです。
そして、プログラマは、忙しいためか、なかなかＳＴＬやジェネリックプログラミング技法を学ぶ時間が取れない。
それらを教えることのできる先生も、専門学校にはいない。当然、会社に入っても教える人はいない。
一部のプログラマがちょっと頑張って、「ＯＯ設計はいいよ！」と言って実践したが、結果はさんざんだった。
ってところではないでしょうか？（勝手な推定）で、結局のところ、効率アップしないのでＯＯ設計は流行らない・・・。
「プログラミングが楽になった！」って実感がないからでは？いや、逆に、「難しくって、やりにくい」とか
「ＯＯで、プログラミングの効率が悪化した！」って思うことが多いからではないでしょうか？
ここ１年くらい、Ｃ＋＋が気になって、「Ｃ＋＋の設計と進化」をスタートに、Ｃ＋＋の定番とされる本を約２０冊くらい購入しました。
それらを読んで、感じたのは
「ＯＯ設計は必要。でも、具体的なプログラミングを効率化するには、それだけでは役にたたない」
「プログラム実装の世界には、その世界で効率化する手法がある。特にＣ＋＋では、「ＯＯＰとは無縁」のテンプレート
を活用したＳＴＬとか、ジェネリックプログラム技法が重要で、それらを活用するとき、上位概念としてＯＯＰが役
にたつ。」って感じました。
たぶん、技術者として、マスターする大変さを考えてみれば、ＯＯ設計なら、頭が良い方なら、がり勉すれば、ＩＴ業界未経験の
ど素人でも、一週間程度でマスターできるかもしれません。でも、Ｃ＋＋のＳＴＬやジェネリックプログラミング技法のマスターは
不可能でしょう。たぶん、Ｃ＋＋以前のＣ言語の段階も無理でしょうね。
それは、短期のがり勉で建築士の試験だけに合格できても、すばらしい技術を持つ宮大工になれないのと同じです。
そして、プログラマは、忙しいためか、なかなかＳＴＬやジェネリックプログラミング技法を学ぶ時間が取れない。
それらを教えることのできる先生も、専門学校にはいない。当然、会社に入っても教える人はいない。
一部のプログラマがちょっと頑張って、「ＯＯ設計はいいよ！」と言って実践したが、結果はさんざんだった。
ってところではないでしょうか？（勝手な推定）で、結局のところ、効率アップしないのでＯＯ設計は流行らない・・・。
STLもBoostも独学で3日で使いこなせるようになりましたが何か？
凄いですね^^
OOは宗教と一緒
信じたい奴は信じればいい
無用だと感じてる奴が「無用だ」と言えば信者は宗教のよさを必死にアピールし、
OOが本当にすばらしいものだとしても信者以外には迷惑でしかない
信じたい奴は信じればいい
無用だと感じてる奴が「無用だ」と言えば信者は宗教のよさを必死にアピールし、
OOが本当にすばらしいものだとしても信者以外には迷惑でしかない
367 ：仕様書無しさん：2007/05/26(土) 17:54:33
>>365 もうガマンできない、この論調は看過できない。
なぜ、自分がメリットを味わえなかったというだけのものを、
恨みがましく「信者」「神格化」などという言葉を使って茶化すのか。
自分の業務に不要ならばそれで十分、だまっておればよい。
使う人々はメリットがあるからこそ、好んで使っているだけ。
宗教だなんだといい始めるのはまったくもって不毛。
なぜ、自分がメリットを味わえなかったというだけのものを、
恨みがましく「信者」「神格化」などという言葉を使って茶化すのか。
自分の業務に不要ならばそれで十分、だまっておればよい。
使う人々はメリットがあるからこそ、好んで使っているだけ。
宗教だなんだといい始めるのはまったくもって不毛。
３日？、向いているのですね。凄いです。そういう方にどんどん頑張ってもらいたいです。
「Ｃ＋＋？それはいいかもしれないけど、判る人ほとんどいないから誰もメンテできなくなるかも？」
って言われます。自分も「Ｃ＋＋、ＳＴＬ、Boost完璧！」って言いきれないから、結局はＣ＋＋が使われない。
個人的には、「ＯＯＰはまあ、どうでもいい。でもＣ＋＋で、テンプレート、ＳＴＬ＆Boostは役にたつ」
これらを使うと、コーディングが楽で、初回からまともに動作し、デバッグが楽で、いいなあと感じています。
「Ｃ＋＋？それはいいかもしれないけど、判る人ほとんどいないから誰もメンテできなくなるかも？」
って言われます。自分も「Ｃ＋＋、ＳＴＬ、Boost完璧！」って言いきれないから、結局はＣ＋＋が使われない。
個人的には、「ＯＯＰはまあ、どうでもいい。でもＣ＋＋で、テンプレート、ＳＴＬ＆Boostは役にたつ」
これらを使うと、コーディングが楽で、初回からまともに動作し、デバッグが楽で、いいなあと感じています。
素直にJavaかC#にしとけば？
>>367
これならいいか？
OOはテレビと一緒
見たい奴は見ればいい
PTAが「子供の教育に悪い」と言えば若者はバカバカしくて楽しいのを必死にアピールし、
番組が本当にすばらしいものだとしてもその娯楽が好きな者以外には迷惑でしかない
言い回しだけで釣れてくれるなよ、雑魚狙いじゃないんだから
これならいいか？
OOはテレビと一緒
見たい奴は見ればいい
PTAが「子供の教育に悪い」と言えば若者はバカバカしくて楽しいのを必死にアピールし、
番組が本当にすばらしいものだとしてもその娯楽が好きな者以外には迷惑でしかない
言い回しだけで釣れてくれるなよ、雑魚狙いじゃないんだから
優秀な人達の間では十分に流行ってる。
馬鹿にはなかなか理解されない。
で、おｋ？
馬鹿にはなかなか理解されない。
で、おｋ？
>>370 あのさあ、その新しい言い回し、言ってることがいまいち分からない。
結局OOPのすばらしさ（？）を必死に（？）アピールするやつがウザイってこと？
言い回しというか>>365にあるような理解不足自体が滑稽なわけで。
OOPを使う理由が、信者だから、有効だと「信じて」いるから、ってのが。
結局OOPのすばらしさ（？）を必死に（？）アピールするやつがウザイってこと？
言い回しというか>>365にあるような理解不足自体が滑稽なわけで。
OOPを使う理由が、信者だから、有効だと「信じて」いるから、ってのが。
また雑魚だよ
不漁だな
不漁だな
出来の良いOOP＞普通の手続き＞できの悪いOOP
って構造だろ。
やりたいことより、やらせる知識のほうが膨大てのが滑稽。
って構造だろ。
やりたいことより、やらせる知識のほうが膨大てのが滑稽。
膨大か？
知識というより感性の問題だと思うが。感性があれば自然と覚える。
どうやって作るか、ってのと、
何を作るか、ってのがごちゃごちゃしてると
そりゃ>372みたいな坊ちゃんが出現してもしょうがないわな
何を作るか、ってのがごちゃごちゃしてると
そりゃ>372みたいな坊ちゃんが出現してもしょうがないわな
負け犬の遠吠えｗ
別に開発効率上げるためにOO設計してるわけじゃないんだけどね^^;
380 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/26(土) 18:43:50
ハウスマヌカンとおなじだよね
流行言葉なだけ
流行言葉なだけ
OOは理想論ばかり
ドキュメント作るのがめんどい
構造がわかりにくい
開発効率が激しく落ちる
いいことねーなー
ドキュメント作るのがめんどい
構造がわかりにくい
開発効率が激しく落ちる
いいことねーなー
>>やりたいことより、やらせる知識のほうが膨大てのが滑稽。
その傾向はちょっとあるかも？つまりは、大型トラックが必要な荷物のある人は、難しい大型免許が必要。
でも、チャリで十分な人には免許自体がいらない。だから、免許取得の勉強なんていらない。
ただ、やっている仕事は「チャリ」でいいのか、普通免許ぐらいは必要かも、ってところかな？
いまのところ、軽トラが必要な荷物でも、人海戦術により、チャリで運んでいる人（プログラマ）が
割と多いってところかもしれない。みんながそうなら、それでもいいし、人月かせげてピンハネの額がでかくなる。
その傾向はちょっとあるかも？つまりは、大型トラックが必要な荷物のある人は、難しい大型免許が必要。
でも、チャリで十分な人には免許自体がいらない。だから、免許取得の勉強なんていらない。
ただ、やっている仕事は「チャリ」でいいのか、普通免許ぐらいは必要かも、ってところかな？
いまのところ、軽トラが必要な荷物でも、人海戦術により、チャリで運んでいる人（プログラマ）が
割と多いってところかもしれない。みんながそうなら、それでもいいし、人月かせげてピンハネの額がでかくなる。
>382
おまぃ、うまぃことぃうな
おまぃ、うまぃことぃうな
>>381とは一緒に仕事したくねぇなぁ
Newton別冊買ってきた！これから原子について勉強するぞ。
これでオブジェクト指向はバッチリかぁ？
これでオブジェクト指向はバッチリかぁ？
ちょっと皆さんに質問です。
私はあんまりオブジェクト指向に触れて居ないので良く分かりません。
言語としてC言語を使うことが決まっています。
設計をオブジェクト指向で行った場合、
機能分割による設計よりもスムーズに設計/実装出来ますか？
私はあんまりオブジェクト指向に触れて居ないので良く分かりません。
言語としてC言語を使うことが決まっています。
設計をオブジェクト指向で行った場合、
機能分割による設計よりもスムーズに設計/実装出来ますか？
あなたを含める開発担当者が
オブジェクト指向を理解してるかどうかが問題です
もし理解していないなら
「英語が分からないんですけどアメリカで英語の教師をすることはできますか？」
と言ってるようなもんです
オブジェクト指向を理解してるかどうかが問題です
もし理解していないなら
「英語が分からないんですけどアメリカで英語の教師をすることはできますか？」
と言ってるようなもんです
流行らないねぇ。
客にはあんまりメリット無いもの。
新規の開発ならごまかせるかも知れないが、リプレースの場合、
最新のサーバー機に交換して処理能力は確実にアップしてるにもかかわらず、
パフォーマンスは従来のシステムの１．５倍とか・・・
開発する側が楽するためにＣＰＵを使ってちゃ客は納得しないって。
客にはあんまりメリット無いもの。
新規の開発ならごまかせるかも知れないが、リプレースの場合、
最新のサーバー機に交換して処理能力は確実にアップしてるにもかかわらず、
パフォーマンスは従来のシステムの１．５倍とか・・・
開発する側が楽するためにＣＰＵを使ってちゃ客は納得しないって。
OOの有効性と、作る側の下手糞さは別問題。
パフォーマンス重視ならアセンブラ使えということになってしまう。
>>392
初心者を混乱さすなよｗｗ
初心者を混乱さすなよｗｗ
>>391
最近のコンパイラの最適化は良くしたもんで、かなり良いコード吐くよ
メンテまで考えるとCで良いとオモ。
アセンブラ使う部分ももちろんあるが。
この辺の話はoo設計するかどうかとは、あんま関係無い気もする。
最近のコンパイラの最適化は良くしたもんで、かなり良いコード吐くよ
メンテまで考えるとCで良いとオモ。
アセンブラ使う部分ももちろんあるが。
この辺の話はoo設計するかどうかとは、あんま関係無い気もする。
>>387
>設計をオブジェクト指向で行った場合、
>機能分割による設計よりもスムーズに設計/実装出来ますか？
構造計算を知らない建築デザイナーが、景観、センスが抜群に良い、すばらしい建物、けれど「細い柱がちょっぴり」
ってデザインをしたらどうなるか、わかりますよね。
上流設計の経験だけで、Ｃ＋＋等の実装を知らないＳＥが、オブジェクト指向の設計やったら、上記のような感じになる
気がします。「実装が不可能だろうが、俺の仕事は終わった。あとは、おまえらに任せた。後は知ーらね。よろしく！」
って感じでしょう。
もちろん、きちんと実装まで理解している方なら、知らない人よりもＣ言語でスムーズな実装ができると思います。
でも、Ｃ言語では、オブジェクト指向のポリモフィズムといったところや、オブジェクト指向とは全然関係ないけど、
オブジェクト指向以上に、プログラマにとって美味しいテンプレートやＳＴＬが使えないので、かなり不利に感じます。
もちろん、シンプルなシステムなら、Ｃ言語でＯＫ。複雑、でかい、スピード要求がきつい、変更が多い、ってシステムで
こそ、Ｃ＋＋が本領発揮すると思います。
>設計をオブジェクト指向で行った場合、
>機能分割による設計よりもスムーズに設計/実装出来ますか？
構造計算を知らない建築デザイナーが、景観、センスが抜群に良い、すばらしい建物、けれど「細い柱がちょっぴり」
ってデザインをしたらどうなるか、わかりますよね。
上流設計の経験だけで、Ｃ＋＋等の実装を知らないＳＥが、オブジェクト指向の設計やったら、上記のような感じになる
気がします。「実装が不可能だろうが、俺の仕事は終わった。あとは、おまえらに任せた。後は知ーらね。よろしく！」
って感じでしょう。
もちろん、きちんと実装まで理解している方なら、知らない人よりもＣ言語でスムーズな実装ができると思います。
でも、Ｃ言語では、オブジェクト指向のポリモフィズムといったところや、オブジェクト指向とは全然関係ないけど、
オブジェクト指向以上に、プログラマにとって美味しいテンプレートやＳＴＬが使えないので、かなり不利に感じます。
もちろん、シンプルなシステムなら、Ｃ言語でＯＫ。複雑、でかい、スピード要求がきつい、変更が多い、ってシステムで
こそ、Ｃ＋＋が本領発揮すると思います。
実際の現場はオブジェクト指向とC++でオブジェクトスパゲッティ状態だから、
オブジェクトベースとC言語がお勧め。
オブジェクト指向は難しいから、ポリモフィズムを香具師に与えるのは危険すぎる。
オブジェクトベースとC言語がお勧め。
オブジェクト指向は難しいから、ポリモフィズムを香具師に与えるのは危険すぎる。
デザインとロジックを開発言語レベルで分けろって事？
全員分かってるくせになぜ言わないんだ？
「自分が知ってる方法でやれ」
「自分が知ってる方法でやれ」
むしろ、「知らなきゃ学べ」
>>388
＞「英語が分からないんですけどアメリカで英語の教師をすることはできますか？」
どちらかというと「アメリカで英語の教師をした方が良いですか？」という話でしょうか。
「アメリカで英語の教師をした方が良い」というのであれば
それから「英語を勉強する」ことになると思います。
>>392
ザクっと調べてみましたが、なにやら良く分からず・・・。
具体的な話をすれば、モジュール指向な設計にして、モジュール=物(名詞)として
1種のオブジェクトが1つのインスタンスとして1ファイルが1インスタンス、となる形ですか？
何言ってるのか自分でも分からなくなって来ました・・・。
>>395
上のオブジェクトベースの話とあわせると、
C言語を使うに合ったオブジェクトの考え方があるので
その方向で設計するのは有益、ということですか？
まとめると、機能分割する時に考える「モジュール」を
もっと「オブジェクト」として強く認識する方が理解しやすい、ということ？
何となく理解が斜め上を向いてる気がしますが・・・。
＞「英語が分からないんですけどアメリカで英語の教師をすることはできますか？」
どちらかというと「アメリカで英語の教師をした方が良いですか？」という話でしょうか。
「アメリカで英語の教師をした方が良い」というのであれば
それから「英語を勉強する」ことになると思います。
>>392
ザクっと調べてみましたが、なにやら良く分からず・・・。
具体的な話をすれば、モジュール指向な設計にして、モジュール=物(名詞)として
1種のオブジェクトが1つのインスタンスとして1ファイルが1インスタンス、となる形ですか？
何言ってるのか自分でも分からなくなって来ました・・・。
>>395
上のオブジェクトベースの話とあわせると、
C言語を使うに合ったオブジェクトの考え方があるので
その方向で設計するのは有益、ということですか？
まとめると、機能分割する時に考える「モジュール」を
もっと「オブジェクト」として強く認識する方が理解しやすい、ということ？
何となく理解が斜め上を向いてる気がしますが・・・。
言語を学べは自然と構造化手法は身につく。言語が強制するからな。
だけどＯＯは、言語の文法を覚えただけでは身につかない。
知識とセンスが要求される。
ＯＯを覚えなくてもとりあえず動くプログラムはつくれるから、それ以上
努力したくない奴らがなんやかんや理由をつけて抵抗を試みてるのが
今の現状。
だけどＯＯは、言語の文法を覚えただけでは身につかない。
知識とセンスが要求される。
ＯＯを覚えなくてもとりあえず動くプログラムはつくれるから、それ以上
努力したくない奴らがなんやかんや理由をつけて抵抗を試みてるのが
今の現状。
402 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/26(土) 22:07:00
車の運転は一人でやるのが一番効率的だ。
それをハンドル係、ブレーキ係、アクセル係、ギア係、スターター係に分けて操作しようというのがオブジェクト指向。
分業によって効率が上がり、１０人分の運転ができるというのがOOの理論。
もちろん間違ってるが、ワークシェアリングを進めたい会社では有用。
電球交換で経験があるのでインド人には受け入れやすい。
それをハンドル係、ブレーキ係、アクセル係、ギア係、スターター係に分けて操作しようというのがオブジェクト指向。
分業によって効率が上がり、１０人分の運転ができるというのがOOの理論。
もちろん間違ってるが、ワークシェアリングを進めたい会社では有用。
電球交換で経験があるのでインド人には受け入れやすい。
>>402
例が悪すぎて何も伝わってこない。
例が悪すぎて何も伝わってこない。
現状、妥協するところは妥協する「ゆるいオブジェクト指向」がベストかな。
完璧なオブジェクト指向は目指さないほうがいい。人間関係のためにも。
完璧なオブジェクト指向は目指さないほうがいい。人間関係のためにも。
ココ電球がインドから来たということだけはなんとなく理解できた。
406 ：仕様書無しさん：2007/05/26(土) 22:50:45
>>400
C言語を使うに合ったオブジェクトの考え方があるので
その方向で設計するのは有益、ということですか？
そうですね。Ｃ言語では、ポリモーフィズムはそのままでは実現できないけど、
「なんちゃって」的な関数ポインタを使うストラテジパターンっていうのは可能ですし、
グローバル変数を排除するカプセル化とか変数領域を動的に確保して、コンストラクター/
デストラクタもどき、を利用するってのも意味あることだと思います。
ＯＯの思想を知って、Ｃ言語に反映させることは、有益だと思います。
もともとＣ＋＋は、Ｃ言語のフロントプロセッサーとして装備された経緯があるわけですしね。
ただ、ＯＯでのモジュールは構造化設計の単なる「モジュール分割」ではありません。
Effective C++第３版とか、Exceptional C++ Styleを参考にされると良いと思います。
（ただし、Ｃ＋＋が判ってないと、これらの書籍がスラスラとは読めないと思いますが・・）
>>404
完璧なオブジェクト指向は目指さないほうがいい。人間関係のためにも。
ちょっと同感。オブジェクト指向ではないにしても、「完璧！」って思うプログラムが素人がメンテして
メタメタになることありますからね。
完璧なオブジェクト指向のＣ＋＋プログラムは、初心者プログラマにとっては
小学生に「数Ⅱの問題を解け！」っていうようなもんでしょうから。
メンテなんていわれたら、いきなり戦意喪失でしょうね。
C言語を使うに合ったオブジェクトの考え方があるので
その方向で設計するのは有益、ということですか？
そうですね。Ｃ言語では、ポリモーフィズムはそのままでは実現できないけど、
「なんちゃって」的な関数ポインタを使うストラテジパターンっていうのは可能ですし、
グローバル変数を排除するカプセル化とか変数領域を動的に確保して、コンストラクター/
デストラクタもどき、を利用するってのも意味あることだと思います。
ＯＯの思想を知って、Ｃ言語に反映させることは、有益だと思います。
もともとＣ＋＋は、Ｃ言語のフロントプロセッサーとして装備された経緯があるわけですしね。
ただ、ＯＯでのモジュールは構造化設計の単なる「モジュール分割」ではありません。
Effective C++第３版とか、Exceptional C++ Styleを参考にされると良いと思います。
（ただし、Ｃ＋＋が判ってないと、これらの書籍がスラスラとは読めないと思いますが・・）
>>404
完璧なオブジェクト指向は目指さないほうがいい。人間関係のためにも。
ちょっと同感。オブジェクト指向ではないにしても、「完璧！」って思うプログラムが素人がメンテして
メタメタになることありますからね。
完璧なオブジェクト指向のＣ＋＋プログラムは、初心者プログラマにとっては
小学生に「数Ⅱの問題を解け！」っていうようなもんでしょうから。
メンテなんていわれたら、いきなり戦意喪失でしょうね。
オブジェクト指向って何？
って技術者の割合ってどんぐらいなんだろな
ここの粘着がいくら「不勉強だ」と叫んでも
不勉強であることを知らない連中も少なくないだろ
って技術者の割合ってどんぐらいなんだろな
ここの粘着がいくら「不勉強だ」と叫んでも
不勉強であることを知らない連中も少なくないだろ
>それをハンドル係、ブレーキ係、アクセル係、ギア係、スターター係に分けて操作しようというのがオブジェクト指向。
>分業によって効率が上がり、１０人分の運転ができるというのがOOの理論。
いや、違うだろｗ
車の運転は一人でするけど、ギアとかスターターまでは自分で操作しませんから・・
そういうところを隠蔽（カプセル化）するのがオブジェクト指向技術の一つ
>分業によって効率が上がり、１０人分の運転ができるというのがOOの理論。
いや、違うだろｗ
車の運転は一人でするけど、ギアとかスターターまでは自分で操作しませんから・・
そういうところを隠蔽（カプセル化）するのがオブジェクト指向技術の一つ
理解できないならまだしも、オブジェクト指向って何？
って言ってる奴は技術者とは呼びたくない。
って言ってる奴は技術者とは呼びたくない。
あ、ギアとかスターターって車のインターフェースの所の話ね。
ギアなんてかくからデファレンシャルギアとか考えたじゃねーかｗ
まぁ、そもそも電球のOOの考え方は違う
ギアなんてかくからデファレンシャルギアとか考えたじゃねーかｗ
まぁ、そもそも電球のOOの考え方は違う
>>400
> まとめると、機能分割する時に考える「モジュール」を
> もっと「オブジェクト」として強く認識する方が理解しやすい、ということ？
設計のレベルでオブジェクトとして認識して設計することは、十分なメリットがあると思うよ。
でもね、実装の段階でソレをやるのは、個人的にはお勧めしない。
後でメンテする人間を地獄に陥れたければ、やってもよいけどｗ
つーかコードのメンテ作業で地獄に叩き落とされた＿|￣|○
> まとめると、機能分割する時に考える「モジュール」を
> もっと「オブジェクト」として強く認識する方が理解しやすい、ということ？
設計のレベルでオブジェクトとして認識して設計することは、十分なメリットがあると思うよ。
でもね、実装の段階でソレをやるのは、個人的にはお勧めしない。
後でメンテする人間を地獄に陥れたければ、やってもよいけどｗ
つーかコードのメンテ作業で地獄に叩き落とされた＿|￣|○
そんな技術者は幾らでもいる。
指向であって手法でないところが
普及しない理由。なくたってなんとかなる。
指向であって手法でないところが
普及しない理由。なくたってなんとかなる。
413 ：仕様書無しさん：2007/05/26(土) 23:37:14
理解できないなら、使うな、ってことだな
プログラミング自体は簡単だけど、ちゃんと動くように作り上げるのは難しい。
オブジェクト指向はそれを助ける一片ではあるが、全てではない。
オブジェクト指向はそれを助ける一片ではあるが、全てではない。
415 ：仕様書無しさん：2007/05/26(土) 23:38:13
現実的なOOは本当のOOじゃないから
あんまり深入りしてもあれだよなぁ。OOしないと再開発DQNに
なるから嫌だけどね
あんまり深入りしてもあれだよなぁ。OOしないと再開発DQNに
なるから嫌だけどね
おいらは、組み込み系だけど「OOって何？」って人は少ないけど
入門書読んだレベルしかない技術者はたくさんいるよ。
おいらも独学だから「これでいい」って自分の設計に自信が持てないでいるしね。
自分よりも詳しい人の設計やなんかに触れる機会も極端にすくないしなぁ。。。
そういう職場にいる人が、ちょっとうらやますぃな
入門書読んだレベルしかない技術者はたくさんいるよ。
おいらも独学だから「これでいい」って自分の設計に自信が持てないでいるしね。
自分よりも詳しい人の設計やなんかに触れる機会も極端にすくないしなぁ。。。
そういう職場にいる人が、ちょっとうらやますぃな
ここは実にレベルの低いスレでつね。
普及しない理由は、現状で満足してる技術者がほとんどだからだろうね。
仕事だからといって3Kでもガマンしてたり、なんとなく仕事してるだけで飯が食えてるから。
でも悲しいよね。
OO知ればもっとラクに仕事できるのにね。
仕事だからといって3Kでもガマンしてたり、なんとなく仕事してるだけで飯が食えてるから。
でも悲しいよね。
OO知ればもっとラクに仕事できるのにね。
現存する技術を可能な限り上手く使っていったら
35歳定年説とか、3Kとかから逃れられるんですか？
35歳定年説とか、3Kとかから逃れられるんですか？
420 ：仕様書無しさん：2007/05/27(日) 00:05:24
>>419
googleになれるんじゃね？
googleになれるんじゃね？
３５歳定年説が正しいかどうかは知らんが、
できる奴は３５歳になる前からできる奴だし、
できない奴は３５歳になる前からできない奴
どーしても気になるなら
コンサルタントでぼったくってる会社に行けばよし
悪銭チュアとかの無能ぶりを見習え
できる奴は３５歳になる前からできる奴だし、
できない奴は３５歳になる前からできない奴
どーしても気になるなら
コンサルタントでぼったくってる会社に行けばよし
悪銭チュアとかの無能ぶりを見習え
OOはA型向き。
B型やAB型には向かないからあきらめた方がいい。さようなら。
B型やAB型には向かないからあきらめた方がいい。さようなら。
423 ：仕様書無しさん：2007/05/27(日) 00:10:13
>>422
OOだけにO型は神とか？ｗ
OOだけにO型は神とか？ｗ
居酒屋の会話みたいだなｗｗ
ＯＯとＡが相性いいのは確か。
自己中のＢにも、気まぐれなＡＢにも向かない。さようなら。
自己中のＢにも、気まぐれなＡＢにも向かない。さようなら。
>>416
オプソが山ほどあるから、それ読めばいいじゃん。
オプソが山ほどあるから、それ読めばいいじゃん。
電球はBだな。間違いない。
428 ：仕様書無しさん：2007/05/27(日) 00:24:11
>>417
ここは実にレベルの低いスレでつね。
418の言うように、３Ｋで長時間労働のため勉強する時間も無く、疲れて意欲も出ないから、ＯＯについて、
平均的なレベルが低くなっても、しかたないと思う。
Ｃ＋＋の勉強はできているが、私の先月の残業時間はたったの０．５時間しかない・・・。だから、Ｃ＋＋
について、いろいろと勉強しようという気力が残っているともいえる。
でも、給与明細を見ると、なんといか、ちょっと悲しい。
意味無く、生活残業って手もあるけど（文句は言われないけど）通常勤務中に真面目に仕事をやったら
残業時間帯でがんばる気力なんて残っていない。もう若くないからね。（５０代・・）
ＯＯとＣ＋＋のテンプレートを駆使すれば、いろんな書籍にあるようにコードの生産性は１００倍くらいにも
なるかもしれない。（Ｃ言語比）
だから、残業・徹夜をする体力が無くても、十分やっていけると思う。
あ、もちろんブラックな企業にいたら無理だろう。常識の通じる企業で働いていることが条件。
ここは実にレベルの低いスレでつね。
418の言うように、３Ｋで長時間労働のため勉強する時間も無く、疲れて意欲も出ないから、ＯＯについて、
平均的なレベルが低くなっても、しかたないと思う。
Ｃ＋＋の勉強はできているが、私の先月の残業時間はたったの０．５時間しかない・・・。だから、Ｃ＋＋
について、いろいろと勉強しようという気力が残っているともいえる。
でも、給与明細を見ると、なんといか、ちょっと悲しい。
意味無く、生活残業って手もあるけど（文句は言われないけど）通常勤務中に真面目に仕事をやったら
残業時間帯でがんばる気力なんて残っていない。もう若くないからね。（５０代・・）
ＯＯとＣ＋＋のテンプレートを駆使すれば、いろんな書籍にあるようにコードの生産性は１００倍くらいにも
なるかもしれない。（Ｃ言語比）
だから、残業・徹夜をする体力が無くても、十分やっていけると思う。
あ、もちろんブラックな企業にいたら無理だろう。常識の通じる企業で働いていることが条件。
ただの道具なんだから、違いはせいぜい「鍬」と「トラクター」の差ぐらいじゃないの？
家庭菜園でトラクターを使う、てのは間違いだろうし、逆に東京ドームぐらいの広さの農地を
鍬を使って耕せ、と指示するのも間違っているだろう。
後者の場合は、たぶんトラクターを購入し運転講習会で使い方を学んでから仕事をした方が楽なはず。
ただ、ありがちなのはトラクターを買ってはくれない、買ってあっても動かし方がわからない
から鍬を使わざるを得ない、東京ドームの広さかと思ってトラクターを準備してたら実は
野球盤の話だった、とかいうことだったりするのはこまるけど。
つまりは、規模と状況に応じて選択しましょう、ご利用は計画的に。
家庭菜園でトラクターを使う、てのは間違いだろうし、逆に東京ドームぐらいの広さの農地を
鍬を使って耕せ、と指示するのも間違っているだろう。
後者の場合は、たぶんトラクターを購入し運転講習会で使い方を学んでから仕事をした方が楽なはず。
ただ、ありがちなのはトラクターを買ってはくれない、買ってあっても動かし方がわからない
から鍬を使わざるを得ない、東京ドームの広さかと思ってトラクターを準備してたら実は
野球盤の話だった、とかいうことだったりするのはこまるけど。
つまりは、規模と状況に応じて選択しましょう、ご利用は計画的に。
オブジェクト指向FizzBuzzと手続きFizzBuzz
あんま変わんね
puts (1..100).map |i|
i % 15 == 0 ? "FizzBuzz" :
i % 3 == 0 ? "Fizz" :
i % 5 == 0 ? "Buzz" : i
end
i = 0
while i++ < 100
puts i % 15 == 0 ? "FizzBuzz" :
i % 3 == 0 ? "Fizz" :
i % 5 == 0 ? "Buzz" : i
end
あんま変わんね
puts (1..100).map |i|
i % 15 == 0 ? "FizzBuzz" :
i % 3 == 0 ? "Fizz" :
i % 5 == 0 ? "Buzz" : i
end
i = 0
while i++ < 100
puts i % 15 == 0 ? "FizzBuzz" :
i % 3 == 0 ? "Fizz" :
i % 5 == 0 ? "Buzz" : i
end
C++&STL厨はそれらがあればなんでもできるみたいなのを執拗に押し付けてくるからイヤだな。
できるかどうかは別にして。
あと「Ｃ＋＋」を見ると吐き気がするんだがｗ
できるかどうかは別にして。
あと「Ｃ＋＋」を見ると吐き気がするんだがｗ
なんかさー、
オブジェクト指向使う理由がさー、
ちゃんと周知できてないままってのが多いような気がするんだよなー
だってさー、
オブジェクト指向で開発やるならさー、
要員も言語だけで集めるとまずんじゃん
それにさー、
どうやって作るか論ばっかりでさー、
本来の目的なはずの何を作るかってのがさー、
少し放置されて技術者論ばかりだってのも困るよねー
オブジェクト指向使う理由がさー、
ちゃんと周知できてないままってのが多いような気がするんだよなー
だってさー、
オブジェクト指向で開発やるならさー、
要員も言語だけで集めるとまずんじゃん
それにさー、
どうやって作るか論ばっかりでさー、
本来の目的なはずの何を作るかってのがさー、
少し放置されて技術者論ばかりだってのも困るよねー
ジジイは頑固だから流行ものには目を向けない。
構造化の場合には「確かにこれは保守工数は下がる」という実感があったから良いけど。
OOの場合にはコストの低下を実感することは難しい。
構造化の場合には「確かにこれは保守工数は下がる」という実感があったから良いけど。
OOの場合にはコストの低下を実感することは難しい。
>>435
構造化はスパゲティを無くすと同時に重複ロジックを減らす
重複ロジック減らせば保守工数は下がる
オブジェクト指向はメタレベルで重複ロジックを減らすことで
更に保守工数の引き下げを目論む
うまくいっているかどうかは別として、OOのメリットを感覚的に
理解するのはそれほど難しくは無い
構造化はスパゲティを無くすと同時に重複ロジックを減らす
重複ロジック減らせば保守工数は下がる
オブジェクト指向はメタレベルで重複ロジックを減らすことで
更に保守工数の引き下げを目論む
うまくいっているかどうかは別として、OOのメリットを感覚的に
理解するのはそれほど難しくは無い
>>436
newすりゃオブジェクト指向だとおもってるだろ
newすりゃオブジェクト指向だとおもってるだろ
439 ：仕様書無しさん：2007/05/27(日) 01:03:44
難しい話してるとこすまん。
頼む！みんなの力を貸してくれ！
ツール開発方面が停滞気味で、日本がハンガリーに猛追されてます！
ちょっとでいいから覗いて下さい＞＜
【日本VSハンガリー】一番クリックした国が優勝click80【超接戦】
http://wwwww.2ch.net/test/read.cgi/news4vip/1180180150/
ひたすらクリック
http://www.clickclickclick.com/default.asp
まとめサイト
http://www33.atwiki.jp/clickvip/
頼む！みんなの力を貸してくれ！
ツール開発方面が停滞気味で、日本がハンガリーに猛追されてます！
ちょっとでいいから覗いて下さい＞＜
【日本VSハンガリー】一番クリックした国が優勝click80【超接戦】
http://wwwww.2ch.net/test/read.cgi/news4vip/1180180150/
ひたすらクリック
http://www.clickclickclick.com/default.asp
まとめサイト
http://www33.atwiki.jp/clickvip/
>>438 ま た 知ったかぶり、か
釣れるのは雑魚ばかりか
>>443
非難されたら、釣りに変更か・・バカも大変だな
>>444
やっぱり理解出来てねえじゃねえか
構造化とOOPの違いを見せるために、フルコード書く必要ねえっての
それが分からないから>>441みたいなバカ発言するんだよ、バカ
非難されたら、釣りに変更か・・バカも大変だな
>>444
やっぱり理解出来てねえじゃねえか
構造化とOOPの違いを見せるために、フルコード書く必要ねえっての
それが分からないから>>441みたいなバカ発言するんだよ、バカ
＞構造化とOOPの違いを見せるために、フルコード書く必要ねえっての
確かにそうだな
確かにそうだな
FizzBuzzがどんなクラスかわからんけど、インスタンスを持つ必要がない
>>444
ひょっとして、サンのAPI仕様にあるクラスが全てだと思ってるのか？
ひょっとして、サンのAPI仕様にあるクラスが全てだと思ってるのか？
>>432の上が、構造化っていう意味がわからん。
コード読めてねえだろ。
コード読めてねえだろ。
問題領域の本質を理解する細部だけをみずに全体を俯瞰してみる心がけが大切ぢゃ。
解決領域の探索はヒューリスティックであり、また客の要求や政治などでころころと変わるものぢゃからのぉ。フォッフォッフォッ...
解決領域の探索はヒューリスティックであり、また客の要求や政治などでころころと変わるものぢゃからのぉ。フォッフォッフォッ...
>>447
またバカが来た
インスタンスにすることでOOPの違いを見せてんだろーが
ていうか俺>>436じゃないのになんでこんな必死になってるんだ
もうめんどくさいからいいよ、バカは勘違いしたまま周りに迷惑かけてろ
またバカが来た
インスタンスにすることでOOPの違いを見せてんだろーが
ていうか俺>>436じゃないのになんでこんな必死になってるんだ
もうめんどくさいからいいよ、バカは勘違いしたまま周りに迷惑かけてろ
馬鹿は目の前のプログラム書くことに必死で、あとあとのことなんか考える余裕も想像性もないからな。
ま、FizzBuzzごときに>>436 の分析はやりすぎの感もあるが。違いは明白。
ま、FizzBuzzごときに>>436 の分析はやりすぎの感もあるが。違いは明白。
標準出力じゃなくて、HTML形式での出力に変更になりました。
なんらかの理由で、剰余演算子(%)を使ってはいけないことになりました。
さぁ、どうする？
って時に、よく設計されたＯＯの方が対処しやすいってことだろ。
そんなことする想像できない馬鹿にはＯＯは向かないってこった。
さっさと寝ろ。
なんらかの理由で、剰余演算子(%)を使ってはいけないことになりました。
さぁ、どうする？
って時に、よく設計されたＯＯの方が対処しやすいってことだろ。
そんなことする想像できない馬鹿にはＯＯは向かないってこった。
さっさと寝ろ。
>>436のを俺なりに書き直してやるよ。
class FizzBuzz implements Problem {
・・・
}
Problem fizzBuzz = new FizzBuzz(new SolutionA());
fizzBuzz.solve();
これなら少しはわかるわ。
だが、こんなコード書いたところでFizzBuzzの出題者のニーズとあまりにかけはなれている。
class FizzBuzz implements Problem {
・・・
}
Problem fizzBuzz = new FizzBuzz(new SolutionA());
fizzBuzz.solve();
これなら少しはわかるわ。
だが、こんなコード書いたところでFizzBuzzの出題者のニーズとあまりにかけはなれている。
FizzBuzzはあくまで例だろが。世の中にころがってる問題は広くて複雑だぞ。
それとも、そのぐらいの具体例が無いと理解できないか。
想像力働かせろよ。
それとも、そのぐらいの具体例が無いと理解できないか。
想像力働かせろよ。
>>457
あんた、いい人だな
今、「なんでFizzBuzzクラスが必要なんだ！」って思ってる奴。
これがOOP風なんだってことを分かってもらうしか無い。
分からなくていいよ、って人は一生構造化で問題ない。
別に、OOPが全ての問題に対して優れてるワケでもないんだしな。
あんた、いい人だな
今、「なんでFizzBuzzクラスが必要なんだ！」って思ってる奴。
これがOOP風なんだってことを分かってもらうしか無い。
分からなくていいよ、って人は一生構造化で問題ない。
別に、OOPが全ての問題に対して優れてるワケでもないんだしな。
その後、やっぱり、剰余演算子(%)を使ってくれと言われました...
>>436
うはwww おまえ大丈夫か？
うはwww おまえ大丈夫か？
463 ：仕様書無しさん：2007/05/27(日) 02:15:23
クラスが増えるとメンテナンス性が悪くなると言う理由で、一機能、一クラスがコーディング規約。
これって何処の宗教？
一クラスで実装するとなると、クラス内のメソッドで分けることになるけど、
こりゃＣ言語とかわらんなぁ。
これって何処の宗教？
一クラスで実装するとなると、クラス内のメソッドで分けることになるけど、
こりゃＣ言語とかわらんなぁ。
C++ならメンバ関数よりフレンドなヘルパ関数として実装すると言う手もあるぞ
>>466
お前マジっぽいからもう一回レスするぞ。
俺==>>432==>>457
なおかつ、>>462に禿堂な。
>>436がOOP風なんて冗談じゃねえよ
FizzBuzzをクラス化する意味なんてまるっきりない
YAGNIでも調べて来いといいたいところだが、
はっきり言ってそれ以前の問題
お前マジっぽいからもう一回レスするぞ。
俺==>>432==>>457
なおかつ、>>462に禿堂な。
>>436がOOP風なんて冗談じゃねえよ
FizzBuzzをクラス化する意味なんてまるっきりない
YAGNIでも調べて来いといいたいところだが、
はっきり言ってそれ以前の問題
目が覚めた。
>>467
別に俺はFizzBuzzごときをクラス化する意味があるとは書いてない。
そしてどっちが優れてるとも書いてない。>>432のコードも十分立派だよ。
勝手な思い込みも結構だが。もちっと冷静にな。
>>468
puts() は改行も出力する。
これでおまえの頭でも理解出来るだろ？
>>467
別に俺はFizzBuzzごときをクラス化する意味があるとは書いてない。
そしてどっちが優れてるとも書いてない。>>432のコードも十分立派だよ。
勝手な思い込みも結構だが。もちっと冷静にな。
>>468
puts() は改行も出力する。
これでおまえの頭でも理解出来るだろ？
スレタイとレス群の内容が全然違うことに
早く気が付いて欲しいもんだね
早く気が付いて欲しいもんだね
もう薄々気づいてるかも知れんが、こういうくだらん理屈を
くどくど議論するような人間が集まって、まともな仕事ができるのかと・・・
自分ひとりの世界でやるんならＯＯもいいかも知れんが、
プロジェクトとしてやるとなると人間関係おかしくなったりする。
結論の出ない会議を何度と無く繰り返し、結局プロジェクトが
ポシャった経験あり。
教訓
あまりＯＯに固執しすぎてはいけない。
くどくど議論するような人間が集まって、まともな仕事ができるのかと・・・
自分ひとりの世界でやるんならＯＯもいいかも知れんが、
プロジェクトとしてやるとなると人間関係おかしくなったりする。
結論の出ない会議を何度と無く繰り返し、結局プロジェクトが
ポシャった経験あり。
教訓
あまりＯＯに固執しすぎてはいけない。
>>472
バカが黙ってれば何の問題も起こらない。
要は、全体の理解度が上がれば良いだけの話・・
チームプレイは重要だが、結論の出ない会議が続くようなら、
より理解度の高いメンバだけで動かしてしまえば良い。
うだうだやって結局レベルの低い奴に合わせるよりは、
結果的に良いものが出来る。
OOに固執しすぎない、というのには当然同意する
バカが黙ってれば何の問題も起こらない。
要は、全体の理解度が上がれば良いだけの話・・
チームプレイは重要だが、結論の出ない会議が続くようなら、
より理解度の高いメンバだけで動かしてしまえば良い。
うだうだやって結局レベルの低い奴に合わせるよりは、
結果的に良いものが出来る。
OOに固執しすぎない、というのには当然同意する
OOPって昔のプログラマ達を
優秀なプログラマとただのドライバユーザに
ばっさり別ける技術だと思うぜ。
中身わかんなくたって使えればおっけ。
優秀なプログラマとただのドライバユーザに
ばっさり別ける技術だと思うぜ。
中身わかんなくたって使えればおっけ。
475 ：仕様書無しさん：2007/05/27(日) 08:09:17
>>流行らないねぇ。
>>客にはあんまりメリット無いもの。
>>新規の開発ならごまかせるかも知れないが、リプレースの場合、
>>最新のサーバー機に交換して処理能力は確実にアップしてるにもかかわらず、
>>パフォーマンスは従来のシステムの１．５倍とか・・・
>>開発する側が楽するためにＣＰＵを使ってちゃ客は納得しないって。
ＣＯＢＯＬのネイティブプログラムがわずか数秒のバッチをＪａｖａ系にリプレース。
はっきり言って勝つ気がしねぇーーー。御馬鹿フレームワークを使うんだが、何十回と
ｊｖｍ起動するからな。ﾊｲﾊｲﾜﾛｽ
>>客にはあんまりメリット無いもの。
>>新規の開発ならごまかせるかも知れないが、リプレースの場合、
>>最新のサーバー機に交換して処理能力は確実にアップしてるにもかかわらず、
>>パフォーマンスは従来のシステムの１．５倍とか・・・
>>開発する側が楽するためにＣＰＵを使ってちゃ客は納得しないって。
ＣＯＢＯＬのネイティブプログラムがわずか数秒のバッチをＪａｖａ系にリプレース。
はっきり言って勝つ気がしねぇーーー。御馬鹿フレームワークを使うんだが、何十回と
ｊｖｍ起動するからな。ﾊｲﾊｲﾜﾛｽ
476 ：仕様書無しさん：2007/05/27(日) 08:16:59
gcjでもつっこんでおけば
糞単純なバッチ処理ならそれこそ100%動作するよ。
糞単純なバッチ処理ならそれこそ100%動作するよ。
477 ：仕様書無しさん：2007/05/27(日) 08:25:48
勝ち負けの基準はなんだよｗ
＞ＣＯＢＯＬのネイティブプログラムがわずか数秒のバッチをＪａｖａ系にリプレース。
漏れCOBOLじゃないがRPG+CLのプログラムをSQL+Javaでリプレースは
あるけど、新鯖のマシンパワーもあるけど、明らかに生産性とかは上だし
現場でのウケは従来のRPG+CLよりもいいぞ。
そもそもCOBOLの数秒バッチをJavaでやるってあたりがDQNな感じなのだが,
まあ、そういう現場もあるのだろう。
漏れCOBOLじゃないがRPG+CLのプログラムをSQL+Javaでリプレースは
あるけど、新鯖のマシンパワーもあるけど、明らかに生産性とかは上だし
現場でのウケは従来のRPG+CLよりもいいぞ。
そもそもCOBOLの数秒バッチをJavaでやるってあたりがDQNな感じなのだが,
まあ、そういう現場もあるのだろう。
おまぃらの支離滅裂ぶりがOOを象徴してるな
[オブジェクト指向]
戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
尻尾から蛇が伸びて天蓋においでのコン猿様を支えている。無理やりこじつけるために色々な曼荼羅図表が必要だが
ユーザの一言で連鎖的に灰塵に帰す砂上の楼閣。
ひとたび疑義を唱えようものなら、宗教裁判が待っている『天動説』の現代版。
戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
尻尾から蛇が伸びて天蓋においでのコン猿様を支えている。無理やりこじつけるために色々な曼荼羅図表が必要だが
ユーザの一言で連鎖的に灰塵に帰す砂上の楼閣。
ひとたび疑義を唱えようものなら、宗教裁判が待っている『天動説』の現代版。
481 ：仕様書無しさん：2007/05/27(日) 10:05:59
>>480
>戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
６月号の日経ソフトウエアの付録「オブジェクト指向入門ブック」を読まれたらいいと思う。
オブジェクト指向について、ＵＭＬやＪａｖａなどをネタに、セミナーや資格やスクール、書籍で儲けよう
と思う輩が、「プログラミング技術」とプログラムとは直接関係ない「汎用の情報整理技術」をごちゃまぜ
に、オブジェクト技術に関係ないものを混ぜ込んでセールス・宣伝した結果、そのように誤認識した人
が多いと感じる。
かくゆう私も、しばらく虚偽の宣伝に「おめでたい設計手法」と誤認していた時期があるから480を
責める気はない・・・。
>戦場では必要の無いもの 。世界が親亀・小亀で出来上がっているというおめでたい設計手法。
６月号の日経ソフトウエアの付録「オブジェクト指向入門ブック」を読まれたらいいと思う。
オブジェクト指向について、ＵＭＬやＪａｖａなどをネタに、セミナーや資格やスクール、書籍で儲けよう
と思う輩が、「プログラミング技術」とプログラムとは直接関係ない「汎用の情報整理技術」をごちゃまぜ
に、オブジェクト技術に関係ないものを混ぜ込んでセールス・宣伝した結果、そのように誤認識した人
が多いと感じる。
かくゆう私も、しばらく虚偽の宣伝に「おめでたい設計手法」と誤認していた時期があるから480を
責める気はない・・・。
[オブジェクト指向]
システム開発に関わる人間(主に開発者)を、人間ではなく「物(オブジェクト)」として捉え、
非人道的な手段を取る事でコストを下げる開発手法。具体的には格安単金、サービス残業、脅迫リストラ等の事。
オブジェクト指向開発ではNewキーワードでいくらでもオブジェクトを生成できる為、
役に立たなくなったオブジェクトは直ちにプロジェクトから破棄される。
偽装派遣業者が利益を上げるための常套手段。
システム開発に関わる人間(主に開発者)を、人間ではなく「物(オブジェクト)」として捉え、
非人道的な手段を取る事でコストを下げる開発手法。具体的には格安単金、サービス残業、脅迫リストラ等の事。
オブジェクト指向開発ではNewキーワードでいくらでもオブジェクトを生成できる為、
役に立たなくなったオブジェクトは直ちにプロジェクトから破棄される。
偽装派遣業者が利益を上げるための常套手段。
>>481
ちょっと善意的過ぎる意見だと思うな。
最初からプログラマに向いてないんだと思う。
OOの発想のさわりだけでも聞いてその有用性にピンと来ないというのは。
たとえOOに関して要領を得ない駄文が幅を利かせている事実を差し引くとしても。
私見だけれども、OOが分からないというのはステートマシンが分からないということだろう。
継承とか多様性のようなどちらかというと派生的な概念を除けば、OOというのは
ステートマシンの発想を発展させたものなわけで。
それなりのPGなら、OOPの経験の有無にかかわらずプログラムとはステートマシンの
組み合わせである、という認識を明示的にであれ暗黙的であれ持っているはずだ。
ちょっと善意的過ぎる意見だと思うな。
最初からプログラマに向いてないんだと思う。
OOの発想のさわりだけでも聞いてその有用性にピンと来ないというのは。
たとえOOに関して要領を得ない駄文が幅を利かせている事実を差し引くとしても。
私見だけれども、OOが分からないというのはステートマシンが分からないということだろう。
継承とか多様性のようなどちらかというと派生的な概念を除けば、OOというのは
ステートマシンの発想を発展させたものなわけで。
それなりのPGなら、OOPの経験の有無にかかわらずプログラムとはステートマシンの
組み合わせである、という認識を明示的にであれ暗黙的であれ持っているはずだ。
484 ：仕様書無しさん：2007/05/27(日) 10:57:50
UMLが静的なモデル図で動的な情報が欠如している事に
きがついてないままOO、OOOOOOって叫んでるやつが
日本には多すぎるだけ。んで中途半端にOOOOOOOOってUOの
死んだ時みたいに叫んでる状態になってるだけ
きがついてないままOO、OOOOOOって叫んでるやつが
日本には多すぎるだけ。んで中途半端にOOOOOOOOってUOの
死んだ時みたいに叫んでる状態になってるだけ
何をどーしたら「モジュール」が「オブジェクト」と呼べるモノになるのかが分からない。
ていうか、ぶっちゃけ単にモジュール化を意識した設計との境目が分からない。
(イベント駆動のタスクとか、バッファ管理モジュールとか)
オブジェクト指向的な設計は無意識にある程度やってると思うが、何をどうすればオブジェクト指向なのか
はっきり意識しようとすればするほど、何が「オブジェクト指向」が分からなくなる気がする。
根本が概念概念しすぎて、具体的なところで派生が多いので、
「良いオブジェクト指向の設計」の仕方が良く分からない。
例とか見たら結局「今までとどーちがうの？」みたいな。
モジュールの独立性に注視した単なるモジュール分割と
オブジェクト指向な設計は何が違うんだ。
ていうか、ぶっちゃけ単にモジュール化を意識した設計との境目が分からない。
(イベント駆動のタスクとか、バッファ管理モジュールとか)
オブジェクト指向的な設計は無意識にある程度やってると思うが、何をどうすればオブジェクト指向なのか
はっきり意識しようとすればするほど、何が「オブジェクト指向」が分からなくなる気がする。
根本が概念概念しすぎて、具体的なところで派生が多いので、
「良いオブジェクト指向の設計」の仕方が良く分からない。
例とか見たら結局「今までとどーちがうの？」みたいな。
モジュールの独立性に注視した単なるモジュール分割と
オブジェクト指向な設計は何が違うんだ。
OOが判らないって訳じゃなくて、現場じゃ必要ないって事だろ?
実は俺もそう感じる。デスマ体験すればくだらないなって思えますよ。
OOはソフトウェア開発の救世主とか、根本的な解決法ではないってこと。
道具を使うのは人であって、人がダメなら何やってもダメだな。
根本的なところで、人間側に問題があるのだと思うよ。
実は俺もそう感じる。デスマ体験すればくだらないなって思えますよ。
OOはソフトウェア開発の救世主とか、根本的な解決法ではないってこと。
道具を使うのは人であって、人がダメなら何やってもダメだな。
根本的なところで、人間側に問題があるのだと思うよ。
そういうのを「倒錯」と呼ぶ。
分かり易くいえば、イソップ物語の「すっぱいブドウ」そのもの。
OOを理解したうえで、「現場で不要」と判断を下しているわけじゃない。
有用性が理解できないから、「現場で不要」と認知を歪めてるだけw
分かり易くいえば、イソップ物語の「すっぱいブドウ」そのもの。
OOを理解したうえで、「現場で不要」と判断を下しているわけじゃない。
有用性が理解できないから、「現場で不要」と認知を歪めてるだけw
現場で「必須」じゃないと言えば良いかな。
必須じゃないものには金かけてくれない会社もあんのよ。
せめて開発用PCは新しいの買わせてくれ・・・うちの会社よ・・・orz
必須じゃないものには金かけてくれない会社もあんのよ。
せめて開発用PCは新しいの買わせてくれ・・・うちの会社よ・・・orz
別にモジュールでもオブジェクトでも読みやすければOK。
オブジェクト指向の設計をしないならば、クラスを構造体以上の役割で使うな。
フレームワークとかライブラリとか使うな。
関数は全てstaticメソッドにしろ。
何も問題ない。
オブジェクト指向の設計をしないならば、クラスを構造体以上の役割で使うな。
フレームワークとかライブラリとか使うな。
関数は全てstaticメソッドにしろ。
何も問題ない。
お前の頭が問題
491 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/27(日) 14:01:43
OO厨が全日空のシステムダウンさせたらしい
役者の演技による映画やドラマ作り＝オブジェクト指向開発
セルやクレイによるアニメ作り＝構造化開発
セルやクレイによるアニメ作り＝構造化開発
また、安直なオープン系移行か(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ
また、安直なオープン系移行か(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ
また、安直なオープン系移行か(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ
また、安直なオープン系移行か(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ
また、安直なオープン系移行か(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ
また、安直なオープン系移行か(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ(･∀･)ﾆﾔﾆﾔ
ttp://itpro.nikkeibp.co.jp/article/NEWS/20060424/236105/
全日本空輸（ANA）は約100億円を投じて，国内線の予約システムをオープン系に全面刷新する。近くシステム仕様の検討に入り，2007年から順次，稼働を開始。
コピペ君って馬鹿だな、まで読んだ。
ん～、設計や分析でコレがいいって書籍ある？
いまいちピンと来るモンがなくて・・・
習ってできるようなことで金を取ろうってのが間違い
本なんて取っ掛かりにすぎない
本なんて取っ掛かりにすぎない
>>495
あるけど教えたくないね。
あるけど教えたくないね。
すくなくともUMLは廃棄したいな。
フローチャートの悪夢の再来だよ。
フローチャートの悪夢の再来だよ。
500 ：仕様書無しさん：2007/05/27(日) 21:31:51
本を読んでどうにかなると思っている時点でｒｙ
>>502
それは、当然やってるけど・・・
どうしたら「正しい設計」「正しい分析」になっているのかが
いまいち自信がもてないから、なんかいい本ないかなと
設計や分析の妥当性が習得できるとっかかりになるような本は
ナイカナと・・・
それは、当然やってるけど・・・
どうしたら「正しい設計」「正しい分析」になっているのかが
いまいち自信がもてないから、なんかいい本ないかなと
設計や分析の妥当性が習得できるとっかかりになるような本は
ナイカナと・・・
これが自分の提唱したOOです。
と言い切れる人間を呼ばなければ
と言い切れる人間を呼ばなければ
>>504
でも、使っている以上は「自分なりの正しさ」つーか、
検証可能な妥当性っていう基準を持ってるわけでしょ?
自分なりの正しさが確立できないのは、
OOに対する認識にあやまりがあるのかな？ということで
なんか、おすすめって本があったら知りたいと思っただけ
でも、使っている以上は「自分なりの正しさ」つーか、
検証可能な妥当性っていう基準を持ってるわけでしょ?
自分なりの正しさが確立できないのは、
OOに対する認識にあやまりがあるのかな？ということで
なんか、おすすめって本があったら知りたいと思っただけ
495からの流れ見てると
「オブジェクト指向設計なんて解釈は人それぞれで有名無実」
と言ってるように見えるんだけど・・・
「オブジェクト指向設計なんて解釈は人それぞれで有名無実」
と言ってるように見えるんだけど・・・
もちろん相対的な正しさってのはあるぞ
勘違いスンナ
勘違いスンナ
正しさっつか、妥当性な。
数学的な正しさより、バランスとかそういうものも必要になってくるからな
数学的な正しさより、バランスとかそういうものも必要になってくるからな
>>508
モジュールでもオブジェクトでも、自分なりの正しさみたいなもんを
確立しないと、仕事としては使えないでしょ？
経験をつむのが一番なんだけど、それ系の業務に携わってないと
経験はなかなか積めないし・・・
したがって、そういうのの手助けになるような本ってないかなぁ
なんて思ったりしたのですよ
なんか、詳しそうな人も多そうだし・・・
モジュールでもオブジェクトでも、自分なりの正しさみたいなもんを
確立しないと、仕事としては使えないでしょ？
経験をつむのが一番なんだけど、それ系の業務に携わってないと
経験はなかなか積めないし・・・
したがって、そういうのの手助けになるような本ってないかなぁ
なんて思ったりしたのですよ
なんか、詳しそうな人も多そうだし・・・
OOの勉強をすればするほど
OOは自分ひとりでやるのがいいと思えてくる
周りは勉強しないからなあ
JavaやC++というだけでオブジェクト指向でしょ、なんて言う連中と
一体なんの話をしろって感じで、むなしさを感じるばっかり
これは自分の環境に限った話かもしれんけどね
OOは自分ひとりでやるのがいいと思えてくる
周りは勉強しないからなあ
JavaやC++というだけでオブジェクト指向でしょ、なんて言う連中と
一体なんの話をしろって感じで、むなしさを感じるばっかり
これは自分の環境に限った話かもしれんけどね
大規模にならんとメリットの無い指向だし。
初心者本あたってもメリットは判らんわな。
つーかOOPイランで済む業種なんてあんのか？
初心者本あたってもメリットは判らんわな。
つーかOOPイランで済む業種なんてあんのか？
OOPLを使わないところ
514 ：仕様書無しさん：2007/05/27(日) 23:39:18
組み込み
515 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/27(日) 23:39:47
大規模だとOOに向かないって本に書いてあったってここで見たぞ
516 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/27(日) 23:41:15
小規模 → OOに向かない
大規模 → OOに向かない
OOは完全に正しいが、使い方が間違ってるだけ
大規模 → OOに向かない
OOは完全に正しいが、使い方が間違ってるだけ
＞ 経験をつむのが一番なんだけど、それ系の業務に携わってないと
＞ 経験はなかなか積めないし・・・
それ系の業務ってのが何をいっているかわからないけど、
漫然ととりくんでたら何の技術も身につかないし。
むしろ分析・設計だけやってても上達するわけねえって。
＞ 経験はなかなか積めないし・・・
それ系の業務ってのが何をいっているかわからないけど、
漫然ととりくんでたら何の技術も身につかないし。
むしろ分析・設計だけやってても上達するわけねえって。
大規模じゃなくて、大人数でやるには向いてない罠
まず英語だ。英語で簡潔できのきいたドキュメントが残せないようだと見込みない。
あと、クラスや関数とか変数の名前な。これも機能や性質をよく表わす名前をつけられ
るネーミングセンスがないと、こいつセンスねぇなということになる。
お前らと関わる奴ら全員が全員、お前ほど英語を知らないわけじゃないということだ。
気をつけろ。
あと、クラスや関数とか変数の名前な。これも機能や性質をよく表わす名前をつけられ
るネーミングセンスがないと、こいつセンスねぇなということになる。
お前らと関わる奴ら全員が全員、お前ほど英語を知らないわけじゃないということだ。
気をつけろ。
英語はなあ。。
メソッドやクラスの名前つけのために英語そのものを勉強するよりも、
オプソ読みまくったほうが効率いいよ。
メソッドやクラスの名前つけのために英語そのものを勉強するよりも、
オプソ読みまくったほうが効率いいよ。
オプソ読みまくるにもある程度の英語は必須だゾ。と。
それ系の業務ってのは、OOの導入されてる業務ってことな
非OO系の業務なんだわ
漠然と取り組んでるつもりはなくって
コーディングレベルはC++とJavaはとりあえず覚えて
自分で大体の要求決めて、分析、設計して、コーディングして検証してる。
で、どうしたらいいか分からない部分とかは、理屈で追求していくのだけど
圧倒的に時間が少ない+理屈で追求の方向が間違ってたら何にもならない。
コーディングレベルで言うとEffectiveC++みたいに、因果律のはっきりした
本ってのがOOの概念レベルでないかなって探してるのよ。
ってことで、なんか、いい本ないかな？
非OO系の業務なんだわ
漠然と取り組んでるつもりはなくって
コーディングレベルはC++とJavaはとりあえず覚えて
自分で大体の要求決めて、分析、設計して、コーディングして検証してる。
で、どうしたらいいか分からない部分とかは、理屈で追求していくのだけど
圧倒的に時間が少ない+理屈で追求の方向が間違ってたら何にもならない。
コーディングレベルで言うとEffectiveC++みたいに、因果律のはっきりした
本ってのがOOの概念レベルでないかなって探してるのよ。
ってことで、なんか、いい本ないかな？
523 ：仕様書無しさん：2007/05/28(月) 00:05:04
いらねーと思うよ
UMLの解析できるツールと静的解析できるツール
2本ぐらい引っ張りだして、最初の部分とデータ構造だけ解析する
あとは書いてることを理解すればいい。英語はいらん嘘書いてるし
UMLの解析できるツールと静的解析できるツール
2本ぐらい引っ張りだして、最初の部分とデータ構造だけ解析する
あとは書いてることを理解すればいい。英語はいらん嘘書いてるし
ま、ひとそれぞれ、各々の好きなやり方で精進しなされ。ふぉふぉ
>>525
メイヤーのオブジェクト指向入門は家にある
勉強しはじめた頃に買って、わかんねぇって放置してた・・・
逝って来よう。
例が悪かったな、
TIPS集って言うよりも、ケースワークでもいいから、
何故こういう設計にしたのかとか、そういう問題領域について
ちゃんと書かれてる本がいいです。
メイヤーのオブジェクト指向入門は家にある
勉強しはじめた頃に買って、わかんねぇって放置してた・・・
逝って来よう。
例が悪かったな、
TIPS集って言うよりも、ケースワークでもいいから、
何故こういう設計にしたのかとか、そういう問題領域について
ちゃんと書かれてる本がいいです。
それをいうなら解決領域
>>524
それハードの話でソフト関係なくね？
それハードの話でソフト関係なくね？
>>528
ファウラーの本とかは読んだ？
ファウラーの本とかは読んだ？
532 ：495：2007/05/28(月) 00:40:53
535 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 01:31:00
ANAの障害はJavaだという噂だぞ。
OO厨おわたね
OO厨おわたね
うそ？ 出所は？ ハード障害じゃなかったのか。
537 ：仕様書無しさん：2007/05/28(月) 01:38:24
>>536
原因はITドカタの能力
原因はITドカタの能力
そんなドカタを束ね切れなかったなんちゃってプロマネの限界
539 ：仕様書無しさん：2007/05/28(月) 01:46:07
>>535
ココ電、おまい核心を言うなよ
おじゃばさまのコメント欲しいな
ま、これでも読んでくれ
http://itpro.nikkeibp.co.jp/a/biz/jirei/jir0707/jir_o13.shtml
ココ電、おまい核心を言うなよ
おじゃばさまのコメント欲しいな
ま、これでも読んでくれ
http://itpro.nikkeibp.co.jp/a/biz/jirei/jir0707/jir_o13.shtml
541 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 02:08:35
新システムで利用する米ユニシス製パッケージ「AirCore」の開発言語はJava。「
542 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 02:10:50
失敗事例
「オブジェクト指向で組んでいたため 表面に出てきた障害フローをソースレベルで追跡することが困難となり・・・」
「オブジェクト指向で組んでいたため 表面に出てきた障害フローをソースレベルで追跡することが困難となり・・・」
まだ新システムには移してないんじゃね？
言語だけで成功・失敗で一喜一憂してる電球とその同類哀れｗｗｗｗｗ
つうか、障害なんて昔からあるし、今時の新システムでおきる障害なんて
そのシステムでOO言語とりいれてるケースは必然的に多くなるっしょ。
何で勝ち誇ったようなカキコするのか分からんが、子供かよ。
そのシステムでOO言語とりいれてるケースは必然的に多くなるっしょ。
何で勝ち誇ったようなカキコするのか分からんが、子供かよ。
そうだな、今回はのANAはJavaが想定よりも遅かったのが原因くさいな
オブジェクト指向というよりも、負荷試験をまともにやってなかったのが敗因だと思う
オブジェクト指向というよりも、負荷試験をまともにやってなかったのが敗因だと思う
548 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 02:47:45
そうではない
始発便から反応が遅くなり始めってあるから すいてる時間帯に障害がおき始めた
始発便から反応が遅くなり始めってあるから すいてる時間帯に障害がおき始めた
原因調査中の段階で
外野が推測で話をしてもしょーがない
どーでもいいが、
システム化が万全だと思ってる世間の風潮自体にも問題あるんじゃねーの？
便利を追求しまくるのはいいが、１００％を現代人は求めすぎ
本当にどーでもいいが、PS3やらXBOXの開発者とか大変だろーな
携帯なんかはさらにコクだろーな
外野が推測で話をしてもしょーがない
どーでもいいが、
システム化が万全だと思ってる世間の風潮自体にも問題あるんじゃねーの？
便利を追求しまくるのはいいが、１００％を現代人は求めすぎ
本当にどーでもいいが、PS3やらXBOXの開発者とか大変だろーな
携帯なんかはさらにコクだろーな
システム化なんて世間一般は気にしない。
係員に詰め寄ればなんとかなるぐらいの認識。
係員に詰め寄ればなんとかなるぐらいの認識。
>>495
ん～、設計や分析でコレがいいって書籍ある？
いまいちピンと来るモンがなくて・・・
遅いレスだけど、「Ｃ＋＋ＦＡＱ 第２版 Ｃ＋＋を極めるためのＱ＆Ａ集」ピアソン・エデュケーション (\5,400(税抜き)
がいいと思う。（アマゾンで目次と抜粋が見れる）
タイトルだけ見ると、Ｃ＋＋の言語にかんするＱＡ集と思っちゃうんだが、それ以外にも面白い内容がある。
第３章 マネジメントの観点を理解する
第３９章 オブジェクト指向Ｃ＋＋への移行
39.07 OO/C++を学ぶ鍵は何か
39.09 優れたＣプログラマであることが、OO/C++を学ぶ役にたつか
第３章は、「テクノロジばかり見て、ビジネスを見失うな」って内容だし、第３９章は、学習方法についてのアドバイス。
39.07の答えは、
-->トップクラスの専門家のいる実プロジェクトで、「年季奉公」すること
一部に、Exceptional C++ Styleと対立するような記述もあるけど、発行日が2000年と2006年の差を考えると、許せると思う。
C++FAQでの内容に、C++ Styleの内容を補足追加って感じかな？
Exceptional C++ Styleの１３章のガイドライン
教訓＃１ 例外仕様を決して書いてはならない。
は、日ごろ感じていた疑問への回答で、納得。
ん～、設計や分析でコレがいいって書籍ある？
いまいちピンと来るモンがなくて・・・
遅いレスだけど、「Ｃ＋＋ＦＡＱ 第２版 Ｃ＋＋を極めるためのＱ＆Ａ集」ピアソン・エデュケーション (\5,400(税抜き)
がいいと思う。（アマゾンで目次と抜粋が見れる）
タイトルだけ見ると、Ｃ＋＋の言語にかんするＱＡ集と思っちゃうんだが、それ以外にも面白い内容がある。
第３章 マネジメントの観点を理解する
第３９章 オブジェクト指向Ｃ＋＋への移行
39.07 OO/C++を学ぶ鍵は何か
39.09 優れたＣプログラマであることが、OO/C++を学ぶ役にたつか
第３章は、「テクノロジばかり見て、ビジネスを見失うな」って内容だし、第３９章は、学習方法についてのアドバイス。
39.07の答えは、
-->トップクラスの専門家のいる実プロジェクトで、「年季奉公」すること
一部に、Exceptional C++ Styleと対立するような記述もあるけど、発行日が2000年と2006年の差を考えると、許せると思う。
C++FAQでの内容に、C++ Styleの内容を補足追加って感じかな？
Exceptional C++ Styleの１３章のガイドライン
教訓＃１ 例外仕様を決して書いてはならない。
は、日ごろ感じていた疑問への回答で、納得。
552 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 18:50:39
で、OO厨は自首したん？
554 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/28(月) 19:39:17
ちょっと調べた所によると、処理不能になったサーバが、フェイルオーバーで切り替わらずに、
リクエストをホスト？に返し続けたらしい。でリクエストが溜まり続けて速度低下。
客観的に見るとかなり見つけづらい不具合だな。異常時でリクエストも多くて長時間でないと発生しない。
とりあえず、自分のシステムで同様の問題がないか、チェックして見た方がいいかもな。
JavaVMが重いとかそんなレベルではないようだ。
リクエストをホスト？に返し続けたらしい。でリクエストが溜まり続けて速度低下。
客観的に見るとかなり見つけづらい不具合だな。異常時でリクエストも多くて長時間でないと発生しない。
とりあえず、自分のシステムで同様の問題がないか、チェックして見た方がいいかもな。
JavaVMが重いとかそんなレベルではないようだ。
555 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 20:22:40
コネクション解放するの忘れてましたとは書けないわなあ
556 ：仕様書無しさん：2007/05/28(月) 20:30:35
まじかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗい、いやありうるｗ
いやいくらなんでも・・・
そんな初歩的な負荷試験もやらないなんて
そんな初歩的な負荷試験もやらないなんて
558 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 21:30:11
６台あるサーバーってアプリケーションサーバーだろ
３台３台で切り替えるようになってた。
アプリケーションサーバーであるあまり使わない処理を行ったあと（予約キャンセルとか座席配置しなおしとか）、
コネクションを解放するのを忘れて、その処理が来るたびにコネクションが減っていった。
タイムアウトでしばらくすると解放されるので平日はなんとか動いていた。
そして日曜日が来た・・・
つうのはどうよ？
３台３台で切り替えるようになってた。
アプリケーションサーバーであるあまり使わない処理を行ったあと（予約キャンセルとか座席配置しなおしとか）、
コネクションを解放するのを忘れて、その処理が来るたびにコネクションが減っていった。
タイムアウトでしばらくすると解放されるので平日はなんとか動いていた。
そして日曜日が来た・・・
つうのはどうよ？
559 ：仕様書無しさん：2007/05/28(月) 21:45:34
ソフトウェアより、制御プログラムのほうが多い。
制御プログラムではメモリも限られている。
例)携帯電話
PIC
オブジェクトの作成によりメモリ圧迫。
オブジェクト指向は便利だけど組み込み系のプログラム開発向きではない。
制御プログラムではメモリも限られている。
例)携帯電話
PIC
オブジェクトの作成によりメモリ圧迫。
オブジェクト指向は便利だけど組み込み系のプログラム開発向きではない。
560 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 22:05:45
ホストでメモリ不足なんてありえない
その前にディスクが限界速度にいってしまうから
その前にディスクが限界速度にいってしまうから
ココ電球（∩T∀T)y-~~~~
話噛みあってねぇよ。黙ってろ
563 ：仕様書無しさん：2007/05/28(月) 22:20:04
>>560
何で泣きながら煙草吸ってるの？
何で泣きながら煙草吸ってるの？
きっとそうやって誰かが突っ込んでくれるの待ってる寂しい奴なんだよ
565 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/28(月) 22:53:12
市況民に聞いてくれ
>>557
結局、より重要な事は設計方法ではなくて
テストケースをどれだけきちんと想定しているか
って事ときちんとテストをするかって事だな。
個人的にはOOで重要な業務システムを
開発するとかありえないし、恐ろしくて信用できたもんじゃないけどなw
結局、より重要な事は設計方法ではなくて
テストケースをどれだけきちんと想定しているか
って事ときちんとテストをするかって事だな。
個人的にはOOで重要な業務システムを
開発するとかありえないし、恐ろしくて信用できたもんじゃないけどなw
はあ？テストに関しては、OOが一番だろ？
569 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 00:46:46
システムのテストね
プログラムのテストではないね
プログラムのテストではないね
OO自体の問題よりも、
理解していない経営者やPMが無理やり導入することが問題
理解していない経営者やPMが無理やり導入することが問題
>>568
ああ、一番テストがやりにくい
特に例外をthrowなんてしてないメソッドがthrow宣言されてて、
それをcatchした場合の挙動とかの確認が難しいね
Cとかなら戻り値をデバッガで無理やり変える方法があるが
例えばJavaだとそういう場合、どうテストすればいいの？
ああ、一番テストがやりにくい
特に例外をthrowなんてしてないメソッドがthrow宣言されてて、
それをcatchした場合の挙動とかの確認が難しいね
Cとかなら戻り値をデバッガで無理やり変える方法があるが
例えばJavaだとそういう場合、どうテストすればいいの？
>>571
あんまOO関係ないな。
C++やC#なら同様にデバッガで同じく無理矢理出来る。
JAVAのデバッガでJBuilderとかなら同様に出来たような覚えがある。
他の環境は出来るか出来ないか分からんな。
あんまOO関係ないな。
C++やC#なら同様にデバッガで同じく無理矢理出来る。
JAVAのデバッガでJBuilderとかなら同様に出来たような覚えがある。
他の環境は出来るか出来ないか分からんな。
573 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 02:57:32
一行ずつｔry-catchで囲う
>>571
>例外をthrowなんてしてないメソッドがthrow宣言されてて、仮にthrows節が
宣言されている場合は呼び出す側のコードの直前でthrow句を記述すれば良い。
もしチェック例外時に何らかの復帰処理が必要であり、呼び出されるコードの参照値が
必要である場合、内部のコードは通常、実装であり未定義であるから、そのような参照
値を期待して復帰処理を記述すべきではない。
次に、非チェック例外である場合はthrows節は記述されておらず、プログラムの処理に
おいて回避可能な例外であるため実行時における予測不可能な挙動をとり得る、これを
テストするには>>573しかない。でも、例えばOutOfMemory Errorで続くテストコードが完璧
に動くことを期待するのは馬鹿げている。
>Cとかなら戻り値をデバッガで無理やり変える方法があるが
Cで戻り値が取れる場合は上記の「チェック例外時」に相当するためCのコードで呼ばれる
関数の戻り値を、呼ぶ側で記述するに等しい。
Cでも同様ではあるが呼び出された側のポインタや参照値を、実装内部でどの程度処理
が進行したかを期待して復帰処理を記述すべきではない。
上記、非チェック例外と対比してCでのエラーはbus errorとかsegment faultとかに該当する
（もちろんOSがある場合;-)これを精密にテストするにはsignalを捕まえてやる必要がある。
（もちろんOSに依存する、OSが無ければ暴走するよ）
さてココからが本題だ、近代の構造化例外処理は、まだ完全に確立されていない（権威化
されていない）Sun率いるJames Goslingでは例外はすべてcatchせよだ、一方Microsoft
率いるBruce Eckelは検査例外とされるものはcatchするな、としている。そしてC++では・・
それぞれ長所短所があるのだが興味のある人は自分で調べてね♪
>>572-573
そだね。ソフトウエアのクラッシュテストなんて最近していないな・・・IBMのBlackTeamは
ご健在なんだろうか・・
>例外をthrowなんてしてないメソッドがthrow宣言されてて、仮にthrows節が
宣言されている場合は呼び出す側のコードの直前でthrow句を記述すれば良い。
もしチェック例外時に何らかの復帰処理が必要であり、呼び出されるコードの参照値が
必要である場合、内部のコードは通常、実装であり未定義であるから、そのような参照
値を期待して復帰処理を記述すべきではない。
次に、非チェック例外である場合はthrows節は記述されておらず、プログラムの処理に
おいて回避可能な例外であるため実行時における予測不可能な挙動をとり得る、これを
テストするには>>573しかない。でも、例えばOutOfMemory Errorで続くテストコードが完璧
に動くことを期待するのは馬鹿げている。
>Cとかなら戻り値をデバッガで無理やり変える方法があるが
Cで戻り値が取れる場合は上記の「チェック例外時」に相当するためCのコードで呼ばれる
関数の戻り値を、呼ぶ側で記述するに等しい。
Cでも同様ではあるが呼び出された側のポインタや参照値を、実装内部でどの程度処理
が進行したかを期待して復帰処理を記述すべきではない。
上記、非チェック例外と対比してCでのエラーはbus errorとかsegment faultとかに該当する
（もちろんOSがある場合;-)これを精密にテストするにはsignalを捕まえてやる必要がある。
（もちろんOSに依存する、OSが無ければ暴走するよ）
さてココからが本題だ、近代の構造化例外処理は、まだ完全に確立されていない（権威化
されていない）Sun率いるJames Goslingでは例外はすべてcatchせよだ、一方Microsoft
率いるBruce Eckelは検査例外とされるものはcatchするな、としている。そしてC++では・・
それぞれ長所短所があるのだが興味のある人は自分で調べてね♪
>>572-573
そだね。ソフトウエアのクラッシュテストなんて最近していないな・・・IBMのBlackTeamは
ご健在なんだろうか・・
575 ：仕様書無しさん：2007/05/29(火) 07:12:00
>>574
さてココからが本題だ、近代の構造化例外処理は、まだ完全に確立されていない（権威化
だから、「Exceptional C++ Style」では、「例外仕様を決して書いてはならない」として、
try/catchを使うな、とアドバイスしている。
さてココからが本題だ、近代の構造化例外処理は、まだ完全に確立されていない（権威化
だから、「Exceptional C++ Style」では、「例外仕様を決して書いてはならない」として、
try/catchを使うな、とアドバイスしている。
ガベージコレクタのないC++で例外を出すとメモリーリークしやすいからな
コンストラクタ内のメンバとスーパークラスのコンストラクタの指定のところでの new がメモリーリークを引き起こす問題も最近修正されたばかりだしな。
つかC++で完璧にメモリーリークのない例外処理実装とか無理、だから最初から使わない。
おれは構造化例外がC++の問題ではなくて、ガベージコレクタ未実装が決定的なC++の問題だと思う。
コンストラクタ内のメンバとスーパークラスのコンストラクタの指定のところでの new がメモリーリークを引き起こす問題も最近修正されたばかりだしな。
つかC++で完璧にメモリーリークのない例外処理実装とか無理、だから最初から使わない。
おれは構造化例外がC++の問題ではなくて、ガベージコレクタ未実装が決定的なC++の問題だと思う。
おれは、ボーランド派だから try __finally で解決。
C++は、catch しかねーもんな
C++は、catch しかねーもんな
ガベージコレクタがあるC++なんてC++じゃないよ
プロブラマ様の書いたことを「忠実」に行うのがC++の長所であり短所だ
ガベージコレクタが欲しければJavaなり別言語を開発するなりすればいい
プロブラマ様の書いたことを「忠実」に行うのがC++の長所であり短所だ
ガベージコレクタが欲しければJavaなり別言語を開発するなりすればいい
579 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/29(火) 19:32:14
>>578
その通り。
その通り。
コンパイラ型言語には難しい。インタプリタ型や中間言語方式ならむしろ無い方がおかしい。
581 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 20:44:07
new 使わないで書けばいいの
VC++
VC++
例外発生したらメモリリークが起こるとか抜かす素人は、
auto_ptr とか shared_ptr みたいな自動化オブジェクト
を使いこなせないバカチンだろ？
auto_ptr とか shared_ptr みたいな自動化オブジェクト
を使いこなせないバカチンだろ？
そもそも自動変数の破棄を全部ふっとばして例外ジャンプするなんぞという古腐ったコンパイラ、いつまで使ってる気ですか？
どうせ、VC++6.0ですよね。糞会社の糞々仕様をいつまで引き伸ばして活用するする気ですか？ いい加減、方向転換したらどうですか？
どうせ、VC++6.0ですよね。糞会社の糞々仕様をいつまで引き伸ばして活用するする気ですか？ いい加減、方向転換したらどうですか？
584 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 20:59:59
いくつだろ？
C#と同じやつ
C#と同じやつ
VC++6の頃の付属STLはうんこ
ココ電の文章って主語や目的語が曖昧で、勘の鈍い俺には何を言いたいのかよく分かんねぇや。
すぐauto_ptrとかいいだすバカいるけどさ。
そんなもん使うくらいならGCのある言語に移行した方がマシなわけさ。
ド素人は黙っとけっつうの。
そんなもん使うくらいならGCのある言語に移行した方がマシなわけさ。
ド素人は黙っとけっつうの。
あいわかりまつた
589 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 21:18:04
でも全日空のシステム吹っ飛ぶし・・・
なにがでもなのか、さっぱりわからん
ヒント：かまってちゃんは無視
VC++を基準に考えるのはよくない。
あれは負の遺産だ。
あれは負の遺産だ。
iostream と Makefile の自動作成機能を抹消した会社だ。
次は何をしでかすか分かったもんじゃないぞ。
次は何をしでかすか分かったもんじゃないぞ。
ガベージコレクトなんつー過保護なもん、要らん
インタープリターの国へカエレ
インタープリターの国へカエレ
我等ぬるぽの世界の住人
596 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 21:52:26
はあああああ南斗究極奥義断己相殺拳！
がっ
がっ
ダングリングポインタはプログラマの天敵
shared_ptrみたいな糞遅えの使ってられっかよ
599 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/29(火) 22:23:56
糞スレだな
糞コテだな
>>582
auto_ptr shared_ptr 程度で全部解決できるなら簡単な話だよ
コンストラクタ周りでおこる、new の直後 shared_ptr の直前で例外が発生したらどうするんだ？
回避しきれるか？
auto_ptr shared_ptr 程度で全部解決できるなら簡単な話だよ
コンストラクタ周りでおこる、new の直後 shared_ptr の直前で例外が発生したらどうするんだ？
回避しきれるか？
603 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/30(水) 02:40:46
日本語で書けよ
auto_ptrとか初めて知った
おれはレベルが上がった！
かしこさが３上がった！
ちからが１上がった！
すばやさが２上がった！
むしばが２本増えた！
おれはレベルが上がった！
かしこさが３上がった！
ちからが１上がった！
すばやさが２上がった！
むしばが２本増えた！
>>603
自分のことよく分かってるじゃないか
自分のことよく分かってるじゃないか
606 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/30(水) 09:37:34
C++をJavaと同じように使わない方がいいぞ。
de?
>>601
コンストラクタで例外が発生するような危険なコードを単に書かなきゃいいだけの話じゃないのか？
コンストラクタで例外が発生するような危険なコードを単に書かなきゃいいだけの話じゃないのか？
だな、コンストラクタに危険なコードを含めるのは悪いプラクティスだ。
次のプログラムを実行して「破棄したあるよ！」が表示されない
処理系は、逝かれてる。 Test on Borland C++Compiler
class auto_test
{
public :
auto_test() {MessageBox(NULL,"作成したあるよ！","auto_test",MB_OK) ; }
~auto_test() { MessageBox(NULL,"破棄したあるよ！","auto_test",MB_OK) ; }
void abone() { MessageBox(NULL,"あぼ～ん","auto_test",MB_OK) ; }
};
static void b() {throw std::runtime_error("エラーぽよん！") ;}
static void a()
{
auto_test test ;
test.abone() ;
b() ;
}
WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
try {
a() ;
}catch(std::exception &e) {
MessageBox(NULL,e.what(),"Error",MB_OK) ;
}
return 0;
}
処理系は、逝かれてる。 Test on Borland C++Compiler
class auto_test
{
public :
auto_test() {MessageBox(NULL,"作成したあるよ！","auto_test",MB_OK) ; }
~auto_test() { MessageBox(NULL,"破棄したあるよ！","auto_test",MB_OK) ; }
void abone() { MessageBox(NULL,"あぼ～ん","auto_test",MB_OK) ; }
};
static void b() {throw std::runtime_error("エラーぽよん！") ;}
static void a()
{
auto_test test ;
test.abone() ;
b() ;
}
WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
try {
a() ;
}catch(std::exception &e) {
MessageBox(NULL,e.what(),"Error",MB_OK) ;
}
return 0;
}
612 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/30(水) 19:33:33
インスタンスを破棄しないのやら、デストラクタ呼んでくれないのなんかJavaでもあるよ。
613 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/30(水) 19:37:33
つうかその例ではクラスの中でエラー処理＞解放やるべきだな。
普通にやってるな
普通にやってるな
614 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/30(水) 19:38:54
つまり、C++で例外とオートポインタとスレッドは使うなって事。
Borland だけは例外。
なにやっても大丈夫。
なにやっても大丈夫。
616 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/30(水) 19:47:05
>>612
インスタンスを破棄しないのは、プログラマが参照を消し忘れてるからだ。
サーブレットのフィールド変数にMapとか持たせていて、その中に入れた物の消し忘れなんかが多い。
Javaではスコープが外れても、すぐにはデストラクタを呼ばない。解放はgc依存。これは仕様。
つまり電球の使い方が間違っているんだよ。
インスタンスを破棄しないのは、プログラマが参照を消し忘れてるからだ。
サーブレットのフィールド変数にMapとか持たせていて、その中に入れた物の消し忘れなんかが多い。
Javaではスコープが外れても、すぐにはデストラクタを呼ばない。解放はgc依存。これは仕様。
つまり電球の使い方が間違っているんだよ。
例えば変な引数で宣言した時にコンストラクタ例外吐かせるよりは
コンパイルエラーになるようにしろってことですかゐ？
コンパイルエラーになるようにしろってことですかゐ？
そんなエラー発生させて何の得があるんだ？
表明ってあるじゃん。アサーション。
あれってコンストラクタ引数には使わないのが一般的なのか？
あれってコンストラクタ引数には使わないのが一般的なのか？
620 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/30(水) 21:02:43
static void a()
{
try{
auto_test test ;
test.abone() ;
b() ;
}catch( Exception e ){
//エラー 処理
}
}
ということだが
621 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/05/30(水) 21:03:46
あ、stdのexception？
使ったこと無いけど引っかかるの？
使ったこと無いけど引っかかるの？
std::exception なんて基礎中の基礎だろ？
バカかお前は？
バカかお前は？
>>608
初期化リスト(コンストラクタの後ろにぶら下がっている変数名()の部分)で例外が発生すると起こるよ。
この間のVisualStudio2005のアップデートで修正されていたが、殆どメーカ独自対処状態だな。
初期化リスト(コンストラクタの後ろにぶら下がっている変数名()の部分)で例外が発生すると起こるよ。
この間のVisualStudio2005のアップデートで修正されていたが、殆どメーカ独自対処状態だな。
あとは迂闊な使い方
void test()
{
func( boost::shared_ptr<MyClass>( new MyClass ) , sub_func() ) ;
}
とかかな、sub_func 内で例外が発生すると、new と shared_ptr のコンストラクタの間に例外となっても文句が言えないのはC++の仕様。
void test()
{
func( boost::shared_ptr<MyClass>( new MyClass ) , sub_func() ) ;
}
とかかな、sub_func 内で例外が発生すると、new と shared_ptr のコンストラクタの間に例外となっても文句が言えないのはC++の仕様。
基本的にC++の問題はnewから、管理オブジェクト(auto_ptrでもshared_ptrでも独自マネージャーやコンテナでも同様)までの間に
隙があることで、本来newと同時に管理下におくべきインスタンスがすり抜けてしまうという事。
極限まで少なくする事は可能だが、究極的にはやはりガベージコレクタが必要かと。
隙があることで、本来newと同時に管理下におくべきインスタンスがすり抜けてしまうという事。
極限まで少なくする事は可能だが、究極的にはやはりガベージコレクタが必要かと。
C++の本質的な問題は「C」であること
そしてCとはプログラマは間違いを犯さないという前提条件で設計された言語
そしてCとはプログラマは間違いを犯さないという前提条件で設計された言語
BOOST_NO_EXCEPTIONSの使い方教えてください
>626
違うな。
Cはコンピューターにより近い言語ってなだけ
プログラマーどうこうは関係ない
違うな。
Cはコンピューターにより近い言語ってなだけ
プログラマーどうこうは関係ない
make_shared_ptrって何？
こちらは boost.orgでの見解、こちらの方がシンプルでいいかと
http://boost.cppll.jp/HEAD/libs/smart_ptr/shared_ptr.htm
void f(shared_ptr<int>, int);
int g();
void ok()
{
shared_ptr<int> p(new int(2));
f(p, g());
}
void bad()
{
f(shared_ptr<int>(new int(2)), g());
}
http://boost.cppll.jp/HEAD/libs/smart_ptr/shared_ptr.htm
void f(shared_ptr<int>, int);
int g();
void ok()
{
shared_ptr<int> p(new int(2));
f(p, g());
}
void bad()
{
f(shared_ptr<int>(new int(2)), g());
}
632 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/31(木) 10:26:09
コンストラクタでのエラーは、プライベート変数にstatusとかを確保して、エラー発生時に設定し、
コンストラクタ終了後に、getStatus()とかで参照出来るようにしておくと良い。
コンストラクタ終了後に、getStatus()とかで参照出来るようにしておくと良い。
ｆａｃｔｏｒｙクラスに子のvalidity管理させるならまだしも
それはいささか不味いんじゃないんだろうか？
それはいささか不味いんじゃないんだろうか？
634 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/31(木) 10:47:30
>>633
どうやんの？
どうやんの？
>>634
class Object {
Data data;
public:
Object(const Data& data_) : data(data_);
int run();
};
class Factory {
boost::ptr_vector<Object> container;
public:
int create(const Data& data_);
int run(unsigned int ID)
};
ってな感じで作っておいて、
factory側のcreate()内でcontainer.push_back(new Objece)でObjectを作るようにする。
こうするとObjectクラス内のコンストラクタでdomain_errorを投げるような仕様でもcreate()内で
容易に補足できるし、Objectに外部からIDを使ってFactoryのインターフェース経由でアクセスすることで、
無効なオブジェクトの呼び出しをそのインタフェース内で制限する事も出来る。
いわゆる仮想コンストラクタとかfactory patternって呼ばれるやつなんだけど、
オブジェクトが振る舞いを持つならこっちの方が管理が楽だと思うんだけどどうか？
まぁ、こいつ自身や他のsingleton的なオブジェクトは、
コンストラクタ内で投げられる例外を直接処理することになるだろうけど…
class Object {
Data data;
public:
Object(const Data& data_) : data(data_);
int run();
};
class Factory {
boost::ptr_vector<Object> container;
public:
int create(const Data& data_);
int run(unsigned int ID)
};
ってな感じで作っておいて、
factory側のcreate()内でcontainer.push_back(new Objece)でObjectを作るようにする。
こうするとObjectクラス内のコンストラクタでdomain_errorを投げるような仕様でもcreate()内で
容易に補足できるし、Objectに外部からIDを使ってFactoryのインターフェース経由でアクセスすることで、
無効なオブジェクトの呼び出しをそのインタフェース内で制限する事も出来る。
いわゆる仮想コンストラクタとかfactory patternって呼ばれるやつなんだけど、
オブジェクトが振る舞いを持つならこっちの方が管理が楽だと思うんだけどどうか？
まぁ、こいつ自身や他のsingleton的なオブジェクトは、
コンストラクタ内で投げられる例外を直接処理することになるだろうけど…
>>629
違いません。
Cは言語設計者が>>626に書かれている前提を仮定して設計したから
>コンピューターにより近い言語
になったわけで、
設計思想とその結果を混同なさらないでください。
決してはじめから「コンピューターにより近い言語」
を設計しようとしたわけではありません。
違いません。
Cは言語設計者が>>626に書かれている前提を仮定して設計したから
>コンピューターにより近い言語
になったわけで、
設計思想とその結果を混同なさらないでください。
決してはじめから「コンピューターにより近い言語」
を設計しようとしたわけではありません。
プログラマが間違いを犯すのを前提とした言語なんてないと思うが。
そんなもんがあったらデバッグなんて不要だな。
そんなもんがあったらデバッグなんて不要だな。
やっぱassertは必要だね～
>>638
それは順序が逆。
それは順序が逆。
>>640
わかってないね。
コンパイラの警告メッセージの仕様はベンダーが決めることであって
言語仕様とは無関係なんだよ。
最適化機能もベンダーが追加する機能に過ぎない。
コンパイラの話をしているのではなくて言語仕様の話をしているんだ。
わかってないね。
コンパイラの警告メッセージの仕様はベンダーが決めることであって
言語仕様とは無関係なんだよ。
最適化機能もベンダーが追加する機能に過ぎない。
コンパイラの話をしているのではなくて言語仕様の話をしているんだ。
>>648
原理主義者というほどでもないけど
経験が少なすぎて良い方法が思いつかなくてGoFとかのパターンに頼りっぱなしなんです＞＜
だから何かつっこまれて良い意見もらえるかなぁと思って書いてみたんですが…
何か他に手軽で優れた管理法ってあるんでしょうか？
原理主義者というほどでもないけど
経験が少なすぎて良い方法が思いつかなくてGoFとかのパターンに頼りっぱなしなんです＞＜
だから何かつっこまれて良い意見もらえるかなぁと思って書いてみたんですが…
何か他に手軽で優れた管理法ってあるんでしょうか？
650 ：おじゃばさま ◆GxjxF3yEw6 ：2007/05/31(木) 20:40:21
>>637
一部の特定のオブジェクトをそれで管理するならいいかもしれないが、
コンストラクタに処理が入っているクラス全部をそれで管理するのは現実的じゃないな。
デザインパターンは面白いが、実用的でないのが多いからな。
一部の特定のオブジェクトをそれで管理するならいいかもしれないが、
コンストラクタに処理が入っているクラス全部をそれで管理するのは現実的じゃないな。
デザインパターンは面白いが、実用的でないのが多いからな。
デザパタは十分実用的だと思うが。おじゃばが使い方を知らないだけ。
つObjectiveC
653 ：仕様書無しさん：2007/06/01(金) 00:51:33
余程の全能の者でなければC++は使いこなせないのだよ諸君
>>655
読んでるし、631は私だ
読んでるし、631は私だ
自演乙
658 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/01(金) 02:55:31
なんか無駄な知識いっぱい詰め込んで自慢してるのがいるが
センス無いだけなんだよ。
センスがあれば知識を選べる。
センス無いだけなんだよ。
センスがあれば知識を選べる。
お前はセンスも知識も無いというオチか
>>658
無駄な知識は必要ないが、お前は必要な知識を詰めておけ、語る内容があんまりだw
無駄な知識は必要ないが、お前は必要な知識を詰めておけ、語る内容があんまりだw
なんかSTLとかboostを普通に使うだけで
newみたいなものをまったく使わなくても数バイトぐらいメモリリークするんだけど
これってなんなの？環境依存？
newみたいなものをまったく使わなくても数バイトぐらいメモリリークするんだけど
これってなんなの？環境依存？
>>662
VC6なら依存
VC6なら依存
マイクロソフト製は、造るだけできちんとテストしてねーです。
665 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/01(金) 20:04:16
今日保守してたソースがやたらにスパゲティーなんで、なぜだろうと考えて結論が出た。
コンソールアプリなのにドキュメントビュー分離をやろうとしてその上メッセージ機構もなんもないので
ぐちゃぐちゃのスパゲティー蝶々結び状態になっているのが主な原因であった。
コンソールアプリなのにドキュメントビュー分離をやろうとしてその上メッセージ機構もなんもないので
ぐちゃぐちゃのスパゲティー蝶々結び状態になっているのが主な原因であった。
666 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/01(金) 20:05:36
教条主義の間違いは
１）場合の条件を考えない
２）合成の誤謬を平気でやる
３）現実より理論を優先する。
といったことだな。
１）場合の条件を考えない
２）合成の誤謬を平気でやる
３）現実より理論を優先する。
といったことだな。
667 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/01(金) 20:07:11
技術者にとって一番大事なのは直感とイマジネーション
全体主義的ディストピアに生きる我々が毎日せっせせっせと
拵えているものはまるでその世界に相反する自堕落で無秩序
なカオスの如き紛い物。オーウェリアンの鎖に繋がれてユー
トピアに君臨する悪魔に魅入られた悲しき宿命のプログラマ。
拵えているものはまるでその世界に相反する自堕落で無秩序
なカオスの如き紛い物。オーウェリアンの鎖に繋がれてユー
トピアに君臨する悪魔に魅入られた悲しき宿命のプログラマ。
669 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/01(金) 21:18:59
直感とイマジネーションで使えないのがC++だな。
what_to_doのレイヤとhow_to_doのレイヤがごっちゃまぜになっちまうのがC++のだめなところ。
671 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/01(金) 21:55:33
>>670
どういう意味だ？
どういう意味だ？
直感とイマジネーションを表現したいんだったらコンパイラ言語は使うな
スクリプト言語でも使っていればいい
スクリプト言語でも使っていればいい
フラットな地面の上に、抽象レベルの違う手続きが節操なく並べられていくのがC++。
直感とイマジネーションは人一倍あるんだが体がゆうことを聞かない
>what_to_doのレイヤとhow_to_doのレイヤがごっちゃまぜになっちまうのがC++のだめなところ。
>フラットな地面の上に、抽象レベルの違う手続きが節操なく並べられていくのがC++。
C++は歴史があるからしょうがないと思うよ
標準化するときにSTLだけでなく、書き方標準等も決めてもらえるといいんだが・・・
書き方といえば、数年前にC++を初めたグループがちょうどオブジェクト指向の流行り始めでノウハウらしいノウハウが無い頃の知識を延々つかっているのが少し困る。
書き方の実態がclass指向+差分プログラミングで、継承=機能拡張としか捕らえていない人に辟易。
これら分かったつもりのオブジェクト指向問題がとても深刻だと感じる。
実装を追うな、インターフェイスを追えといっても理解できないみたいで・・・
JavaあたりのOOしやすい言語で二～三年やりこんで意識をクラスよりインスタンス中心に、コードよりインターフェイスを中心にという考え方を根付かせて欲しいな。
templateや例外を使いこなせろとは言わない、せめて継承を使いこなせるようになってくれと切に思う。
まぁ、この辺はC++だけの問題なんだが。
>フラットな地面の上に、抽象レベルの違う手続きが節操なく並べられていくのがC++。
C++は歴史があるからしょうがないと思うよ
標準化するときにSTLだけでなく、書き方標準等も決めてもらえるといいんだが・・・
書き方といえば、数年前にC++を初めたグループがちょうどオブジェクト指向の流行り始めでノウハウらしいノウハウが無い頃の知識を延々つかっているのが少し困る。
書き方の実態がclass指向+差分プログラミングで、継承=機能拡張としか捕らえていない人に辟易。
これら分かったつもりのオブジェクト指向問題がとても深刻だと感じる。
実装を追うな、インターフェイスを追えといっても理解できないみたいで・・・
JavaあたりのOOしやすい言語で二～三年やりこんで意識をクラスよりインスタンス中心に、コードよりインターフェイスを中心にという考え方を根付かせて欲しいな。
templateや例外を使いこなせろとは言わない、せめて継承を使いこなせるようになってくれと切に思う。
まぁ、この辺はC++だけの問題なんだが。
OOの話題
↓
糞コテが荒らす
↓
話題がOOからずれる
無限ループ
もまぃら偉そうなこと言ってるだけで生産性ゼロだな
↓
糞コテが荒らす
↓
話題がOOからずれる
無限ループ
もまぃら偉そうなこと言ってるだけで生産性ゼロだな
では、実り多いOOの話題をどうぞ。
↓
↓
OO信者が逃げ出す言葉
「DBのトランザクション」
「DBのトランザクション」
EJBやADO.NETでちょちょいのぱですが何か？
Javaで作ってるからOOです、って言わんばかりの勢いだな
681 ：仕様書無しさん：2007/06/02(土) 02:49:37
OOだけじゃノドスは倒せんわな
ちょちょいのぱ
ぶはｗｗ
ぶはｗｗ
ちょちょいのぱ の検索結果 約 996 件中 1 - 10 件目 (0.29 秒)
ちょちょいのちょい の検索結果 約 54,700 件中 1 - 10 件目 (0.13 秒)
残念ながら主流派ではないようだ
ちょちょいのちょい の検索結果 約 54,700 件中 1 - 10 件目 (0.13 秒)
残念ながら主流派ではないようだ
↑
以上、実り多いOOの話題でした。
以上、実り多いOOの話題でした。
うーん。勉強になった。
有難うございました。
有難うございました。
>>684=685
つまらん
つまらん
宣言的トランザクションがうらやましいんだろ
OO最強
OO最強
OOが最強？
だったらなぜ、わかりにくいとか失敗プロジェクトとか
問題が噴出するんだ？
問題の全てが人間側にあるとは思えん
だったらなぜ、わかりにくいとか失敗プロジェクトとか
問題が噴出するんだ？
問題の全てが人間側にあるとは思えん
691 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 11:29:06
失敗を追求されても
「あなたたちはOOを判ってない！」
って叫ぶので失敗例は報告されていません。
「あなたたちはOOを判ってない！」
って叫ぶので失敗例は報告されていません。
692 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 11:29:57
失敗例 今俺が保守してるプロジェクト
要は電球がOOを理解してなくてまずい保守をやってるだけでしょ
694 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 11:51:50
OOなんて馬鹿でも理解できる。
そんなのより難しいコンピューター周辺技術がいっぱいあるのに
実力の無い人がOO、OOと騒ぐのさ。
「オブジェクト指向だ」って言えばごまかせると思ってる。
痛いんだよ。
そんなのより難しいコンピューター周辺技術がいっぱいあるのに
実力の無い人がOO、OOと騒ぐのさ。
「オブジェクト指向だ」って言えばごまかせると思ってる。
痛いんだよ。
こらこら電球、お前の書き込みを読む限りオブジェクト指向のイロハのイさえ分かっているようには見えんぞぉ
>>694
仮にお前のいうとおりでも、OOの良し悪しと何の関係もないぞ
仮にお前のいうとおりでも、OOの良し悪しと何の関係もないぞ
電球の言ってることは一理ある。というか実際見たことがあるわ。
OOに責任があるわけではないが、
「オブジェクト指向」という名前がピンとこないせいか、
名前だけが一人歩きしてる様は悲惨だったな
本人乙じゃねーぞ
OOに責任があるわけではないが、
「オブジェクト指向」という名前がピンとこないせいか、
名前だけが一人歩きしてる様は悲惨だったな
本人乙じゃねーぞ
どうみても電球は中二病だな
699 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 11:56:52
ああ、OOヲタクの薀蓄まで覚えようとは思わないから。
OOOイラネ
変な宗教の教義覚えても意味無いもん。
OOOイラネ
変な宗教の教義覚えても意味無いもん。
701 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 11:57:55
失敗例 ANAの予約システム
>>700
はあ？見積もりするのはPGじゃねえだろバカ
はあ？見積もりするのはPGじゃねえだろバカ
703 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:03:33
一太郎Ark も失敗作だな
ほらね。
すぐ頭沸騰するし。
冷静に判断できずにマイナス作業しまくってるんじゃねーぞ
すぐ頭沸騰するし。
冷静に判断できずにマイナス作業しまくってるんじゃねーぞ
JAVA使ってコボルの10倍の生産性だせない奴のことを
低スキルだって言ってんだよ
低スキルだって言ってんだよ
Java=OOって図式はやめろ電球
じゃあ、わかった言い直すよ。
おなじ案件でも、言語がCOBOLとJavaなら違う見積もり工数が出される
大抵の場合COBOLの方が見積もり工数がかなり大きくなる
したがって、あるプロジェクトの成否を評価する際に
「Javaを採用したことが良くなかった」とするのは「不公平」である
これでわかるか？
おなじ案件でも、言語がCOBOLとJavaなら違う見積もり工数が出される
大抵の場合COBOLの方が見積もり工数がかなり大きくなる
したがって、あるプロジェクトの成否を評価する際に
「Javaを採用したことが良くなかった」とするのは「不公平」である
これでわかるか？
失敗例も少ないが、成功例も少ない
それってもしかして「流行してない」ってことじゃね？
とりあえずOO設計が優れていて、大規模システムに向いているのなら
OO設計でOSかコンパイラを作ってくれ
話はそれから聞こう
それってもしかして「流行してない」ってことじゃね？
とりあえずOO設計が優れていて、大規模システムに向いているのなら
OO設計でOSかコンパイラを作ってくれ
話はそれから聞こう
OSとかコンパイラはたいして大規模じゃないだろ
いまどきCOBOLとJavaのどっちを採用するかで悩むとこなんてあるのか？
まあそのつっこみはおいといて、
結局言語で選ぶんだろ
OOなんか関係ないじゃん
要因集めでOO理解してるかどうか、なんて聞いたことねーし
まあそのつっこみはおいといて、
結局言語で選ぶんだろ
OOなんか関係ないじゃん
要因集めでOO理解してるかどうか、なんて聞いたことねーし
714 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:26:55
以前にも出したけど
統計ではJavaのプロジェクト成功率は比較的低い
統計ではJavaのプロジェクト成功率は比較的低い
脳内統計はいいからソースだせよ
719 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:32:06
OOのOS たしかあったな
>>690=702=707=710=715 が必死なんで誰か助けてあげれ
>>721
見苦しいですよ
見苦しいですよ
723 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:40:42
ネクストデザイン-オブジェクト指向？よくある初歩の失敗事例
http://www.nextdesign.co.jp/casestudy_anti_pattern.html
http://www.nextdesign.co.jp/casestudy_anti_pattern.html
724 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:41:24
豆蔵のチーフコンサルタントが「失敗しないオブジェクト指向教育」を指南
http://itpro.nikkeibp.co.jp/article/NEWS/20051220/226498/
http://itpro.nikkeibp.co.jp/article/NEWS/20051220/226498/
725 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:43:32
組込みソフトウェア開発のためのオブジェクト指向モデリング 失敗事例
http://www.cbook24.com/bm_detail.asp?sku=4798111767
http://www.cbook24.com/bm_detail.asp?sku=4798111767
726 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:44:21
727 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 12:48:00
この解説は間違いね。
このコンサルタントはデータベースを理解していない。
ーーーーーーーーーーーーーーーーーーーーーーーー
データベースのためのコードが冗長
特にリレーショナルデータベースを使用している場合の問題点です。データベースにアクセスするためのオブジェクトの導入や、責務の
割り付けが考慮されていないために、同じテーブルにアクセスするためのSQL文が散在し、開発が進むにつれて、これら
SQL関係の変更工数が増大し、バグも多発するというケースがあります。オブジェクト指向設計やO/Rマッピングの概念を持たずに、各実装者が
必要に応じてSQL文を書いているような場合には、必ずと言って良いほど見受けられる問題です。もっとも良い解決策はオブジェクト指向データベースを
利用することです。
このコンサルタントはデータベースを理解していない。
ーーーーーーーーーーーーーーーーーーーーーーーー
データベースのためのコードが冗長
特にリレーショナルデータベースを使用している場合の問題点です。データベースにアクセスするためのオブジェクトの導入や、責務の
割り付けが考慮されていないために、同じテーブルにアクセスするためのSQL文が散在し、開発が進むにつれて、これら
SQL関係の変更工数が増大し、バグも多発するというケースがあります。オブジェクト指向設計やO/Rマッピングの概念を持たずに、各実装者が
必要に応じてSQL文を書いているような場合には、必ずと言って良いほど見受けられる問題です。もっとも良い解決策はオブジェクト指向データベースを
利用することです。
>>727
どう間違いなのか、ココ電なりに解説してみてくれ
どう間違いなのか、ココ電なりに解説してみてくれ
電球、おまえ自分の書いたことの責任ももてないのか？
「統計」のソースを出せよ
「統計」のソースを出せよ
オブジェクト指向 失敗 の検索結果 約 379,000 件中 1 - 10 件目 (0.10 秒)
ただいま電球必死にぐぐってます
しばらくおまちくださいｗｗ
ただいま電球必死にぐぐってます
しばらくおまちくださいｗｗ
電球さんは今自分のPJがJavaで火を噴いてるんだよ。
今までのCやCOBOLの失敗談は置いといて、
とりあえずJavaを使ったPJに対して愚痴を言いたいだけなのよ。
もちろんOO関係なくね。
生温かくスルーしてあげよう
今までのCやCOBOLの失敗談は置いといて、
とりあえずJavaを使ったPJに対して愚痴を言いたいだけなのよ。
もちろんOO関係なくね。
生温かくスルーしてあげよう
>>728
電球じゃないけど、
DBとOOは相性が悪いが、RDBは枯れていて、それなりの実績もあるので捨てるわけには行かない
だがこのコンサルは
> もっとも良い解決策はオブジェクト指向データベースを 利用することです。
新規導入で基幹系じゃないどうでもいいシステムならいいが、
実績もないし、枯れてもいない、データ移行にもコストがかかるオブジェクト指向データベースを勧めるのは本末転倒
このコンサルはシステム構築の目的はオブジェクト指向言語でシステム構築することが目的になっているように読める
電球じゃないけど、
DBとOOは相性が悪いが、RDBは枯れていて、それなりの実績もあるので捨てるわけには行かない
だがこのコンサルは
> もっとも良い解決策はオブジェクト指向データベースを 利用することです。
新規導入で基幹系じゃないどうでもいいシステムならいいが、
実績もないし、枯れてもいない、データ移行にもコストがかかるオブジェクト指向データベースを勧めるのは本末転倒
このコンサルはシステム構築の目的はオブジェクト指向言語でシステム構築することが目的になっているように読める
OOとDBが相性が悪いっていう理由が分からん
つ トランザクション
トランザクションがなにか
む
あえて分からないフリをしてるのか、
それとも真性なのかどっちだ？
あえて分からないフリをしてるのか、
それとも真性なのかどっちだ？
非OOと比較してどーなのかと
>714
ソースは？
流石にお前の体感とか言わんよな
ソースは？
流石にお前の体感とか言わんよな
739 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 13:36:05
DBのテーブルはファイルではない
個々のテーブルが独立しているように捉えるのは間違いで
多くの場合、各テーブルは相互に関係しあっていてDB全体で一個のものなのだ。
一部だけ切り離して扱おうとするアプローチは間違い。
個々のテーブルが独立しているように捉えるのは間違いで
多くの場合、各テーブルは相互に関係しあっていてDB全体で一個のものなのだ。
一部だけ切り離して扱おうとするアプローチは間違い。
電球、ソースが無いなら無いと言え
741 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 13:41:02
アンカーちゃんとつけろよ
「オブジェクト指向は戦場では必要なし」スレで紹介された統計データがある 探してくれ。
「オブジェクト指向は戦場では必要なし」スレで紹介された統計データがある 探してくれ。
探してきたぞ
http://www.gyve.org/~jet/lang2.txt
内容抜粋
フリーソフトウェアプロジェクトの成功とプログラミング言語との関係を算出
する極めていいかげんな方法を考案したので、その方法といくつかのプログラミング
言語に対する算出結果を報告する。
これがお前のいう統計だな？
極めていいかげんな方法、と書いた本人がつづってるんだが、
それをお前は「統計」と言うんだな？
http://www.gyve.org/~jet/lang2.txt
内容抜粋
フリーソフトウェアプロジェクトの成功とプログラミング言語との関係を算出
する極めていいかげんな方法を考案したので、その方法といくつかのプログラミング
言語に対する算出結果を報告する。
これがお前のいう統計だな？
極めていいかげんな方法、と書いた本人がつづってるんだが、
それをお前は「統計」と言うんだな？
743 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 13:48:14
そいうや OOCOBOLってあったな
どうなったんだろ？
どうなったんだろ？
744 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 13:50:00
謙遜という概念が無いのかな>>742
電球、お前は日本語を正しく使うという概念が無い
はっきり言えば、使えない奴と周りから思われてるのがよく分かる
ついでに言えば、一貫性が無い・責任感が無い、とも影で言われてるだろう
はっきり言えば、使えない奴と周りから思われてるのがよく分かる
ついでに言えば、一貫性が無い・責任感が無い、とも影で言われてるだろう
トランザクションとOOが相性悪い理由はどうなったんだ
常識的に考えて、宣言的トランザクション使えるOOの圧勝じゃねえか
常識的に考えて、宣言的トランザクション使えるOOの圧勝じゃねえか
なあ素朴な疑問なんだが
このコテってアホだろ？
このコテってアホだろ？
よく知らんけど。
宣言的トランザクションってアスペクト指向じゃね？
宣言的トランザクションってアスペクト指向じゃね？
コテと遊ぶスレです
750 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 14:18:16
オセロ勝負で負けたくせに
忘れたころに威張りだすOOちゅ
忘れたころに威張りだすOOちゅ
OOの話の中でトランザクション持ち出したり宣言的だなんていってるアホがいるのが恥ずかしいな
一番恥ずかしいのは電球だけど。電球なだけに頭も軽い
一番恥ずかしいのは電球だけど。電球なだけに頭も軽い
752 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 14:36:50
恥ずかしいやつだな
トランザクションがOOと相性が悪いってのが判ってないのが
トランザクションがOOと相性が悪いってのが判ってないのが
一方的に詭弁を並べ立てて勝利宣言したら勝ったことになるんだね
さっすがぁ～♪
さっすがぁ～♪
>>751
叩かれるのを恐れて、なんの意見出せないお前が一番恥ずかしい♪
叩かれるのを恐れて、なんの意見出せないお前が一番恥ずかしい♪
OOとトランザクションの相性が悪い理由を教えてください。
また、非OOとトランザクションの相性についてもそれと比較して教えてください。
また、非OOとトランザクションの相性についてもそれと比較して教えてください。
早くこたえてやれよ。>>751
OOとDBやトランザクションの相性が悪いっていってる人達は、結局どんな解決策とってんだろ？
SQL文を生書きとかJavaのJTAを直で使ってるとか？
SQL文を生書きとかJavaのJTAを直で使ってるとか？
まだ答えられないの？
極端にレベルの低い連中が集まってるスレはここですか？
760 ：仕様書無しさん：2007/06/02(土) 15:25:44
この板としては平均レベルだろ。
この程度の知識でも十分技術者はやっていけるということです
よかったですね^^
よかったですね^^
762 ：仕様書無しさん：2007/06/02(土) 15:33:38
やっていけてない奴の掃きだめがこの板だろ。
40過ぎたら大半は無職だぞ。
上手く言えば鬱も発症。
40過ぎたら大半は無職だぞ。
上手く言えば鬱も発症。
763 ：仕様書無しさん：2007/06/02(土) 15:36:46
マ板のバカヤロー
764 ：仕様書無しさん：2007/06/02(土) 15:37:55
なんだとコノヤロー
765 ：仕様書無しさん：2007/06/02(土) 15:40:51
さあ卒業ですよぉ、みんな俺と一緒に樹海へ行こう
まぁまぁ、喧嘩せずに仲良くやってこうぜ。どうせ大した奴はこの板にゃいないんだからよ。
767 ：仕様書無しさん：2007/06/02(土) 15:43:55
いっ、一緒にしないでよねっ！！
なんかヘンなのがいるな
769 ：仕様書無しさん：2007/06/02(土) 15:49:08
ようやく自覚したかｗ
770 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 19:05:31
上の方で説明してるだろうが
あほか
あほか
771 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 19:06:13
えーもうすぐ５０だしー
あほはおまえだ。何をいっているのか、全くわからない。
相手するだけ無駄。逝っちゃってるから。
774 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 19:12:53
DB扱った事の無い人はわかんないだろうねー
>>772のわからないは、お前の発言のことだよ。おじぃちゃん聞こえてる？
何が。
電球さんは50でしたか、明日は我が身という言葉を肝に銘じておきます。
ぶ
電球土曜にひきこもりの粘着かよ
友達も彼女もいねーとしょーがねーかｗｗ
挙句に技術も常識もねーときてるｗｗｗｗ
電球土曜にひきこもりの粘着かよ
友達も彼女もいねーとしょーがねーかｗｗ
挙句に技術も常識もねーときてるｗｗｗｗ
779 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 20:20:36
おまえがな
780 ：仕様書無しさん：2007/06/02(土) 20:28:33
文末にwつける香具師基地外
電球はどの言語が得意？ COBOLとみたが
OO厨房は、やっぱJavaかな
ちなみに、おいはVB6かな
電球はどの言語が得意？ COBOLとみたが
OO厨房は、やっぱJavaかな
ちなみに、おいはVB6かな
781 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 20:30:53
マシン語
VC＋＋
Java
マシン語みたいな記号スクリプト一般
VC＋＋
Java
マシン語みたいな記号スクリプト一般
じじい談話かよｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
783 ：仕様書無しさん：2007/06/02(土) 20:35:15
ちょ、すげーじゃね、マシン語、VC＋＋、Javaとは
お舞ら、平伏せ
お舞ら、平伏せ
finalの使い方を知らないでJavaできます、って言われてもなあ
>>781 マシン語じゃなくて8086系のアセンブリ言語だろ？
そりゃひでえなｗｗｗ
787 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 20:44:55
ああそうだ
マシン語もできたけど（いきなり１６進数で書く） 今はちょっとねえ。
マシン語もできたけど（いきなり１６進数で書く） 今はちょっとねえ。
定数を理解してない奴が言語を語る件について
789 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 20:47:37
java のfinalは定数じゃなくてマクロだよ
今時、自前でジャンプ先とかアドレス計算する奴は基地外
マクロじゃなくて修飾子
電球は必死に言い訳を考え中です。
しばらくおまちください。
しばらくおまちください。
793 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 20:56:22
おまいさっき定数だって言わなかったか？
いつものように都合の悪いことはスルーするに一票ｗｗｗ
おまいさっきマクロだって言わなかったか？
796 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 21:08:00
混乱させようとしてもだめだぞ
>>794 は基地外に1億票
797 電球自演乙
マクロって言ったじゃん
素直さが無いのは社会人として致命的だ
電球は基地外に１億票
だが、素直さが無いのはPGとして当たり前
もう糞コテ遊びやめないか？
おい糞コテ。お前も匿名とはいえ恥さらし続けても仕方ないだろう？
おい糞コテ。お前も匿名とはいえ恥さらし続けても仕方ないだろう？
805 ：仕様書無しさん：2007/06/02(土) 21:20:20
>>803の白旗を受け入れ、皆の衆、リアル世界に戻れ
>>804
つまらん
つまらん
「Java の final はマクロ」 by 糞コテ
迷言集へ登録しましょう
迷言集へ登録しましょう
809 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 21:26:30
javaの static final定数は定数フィールドが無く
定数を参照しているように書いている部分に定数が直に埋め込まれているのです。
定数を参照しているように書いている部分に定数が直に埋め込まれているのです。
以上グーグル検索結果でした
マクロをなかったことにしようと必死だな
813 ：仕様書無しさん：2007/06/02(土) 22:41:46
814 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 23:18:38
違います
コンパイル時に埋め込まれます
コンパイル時に埋め込まれます
static finalはコンパイル時だな
別に電球じゃねーぞ
別に電球じゃねーぞ
816 ：仕様書無しさん：2007/06/02(土) 23:30:35
ココ電球とその仲間たちｗｗｗ
でもそれがfinalとの関係にはつながらないんだが・・
>java のfinalは定数じゃなくてマクロだよ
なんだこれは？
なんだこれは？
一応言っておくが別に電球の味方をしてるわけではない
ただしマクロがどうたらという電球の論は間違ってる
それだけだ
ただしマクロがどうたらという電球の論は間違ってる
それだけだ
finalの意味を完全に理解していない電球が
いつの間にかstatic付きへと話をすり替えた。
いつの間にかstatic付きへと話をすり替えた。
821 ：仕様書無しさん：2007/06/02(土) 23:39:35
>>814-815
お前らstatic final 指定できんの数値や文字列だけとか思ってないか？
static final obj = new Hoge(100, 'ABC');
:
a = obj.getValue(200);
のaの値をコンパイル時にどう置換するってんだ？
どうみても実行時だろ。
お前らstatic final 指定できんの数値や文字列だけとか思ってないか？
static final obj = new Hoge(100, 'ABC');
:
a = obj.getValue(200);
のaの値をコンパイル時にどう置換するってんだ？
どうみても実行時だろ。
822 ：仕様書無しさん：2007/06/02(土) 23:41:49
>final フィールドは読み取り専用のフィールドで、その値は、構築時 (あるいは、static final フィールドの場合クラスの初期化時) に一度だけ設定されることになっています。
824 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/02(土) 23:55:11
そのIBMの説明は間違いよ
825 ：仕様書無しさん：2007/06/03(日) 00:02:35
じゃぁSUNも間違ってると？
ttp://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246476
の
8.3.1.2 final Fields
ttp://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246476
の
8.3.1.2 final Fields
826 ：仕様書無しさん：2007/06/03(日) 00:03:24
ココ電球ファンクラブｗ
すまん。どうやら間違ってたようだ。
いやまてまて、間違ってないぞ
finalには他の使い方もあるんですけど
インスタンスイニシャライザとかクラスローダーとかって何ですか？
828誰だよ・・・
まさか電球か？そこまでやるかよ・・・
まさか電球か？そこまでやるかよ・・・
>>830
何っつか、何につかうのってきけば？
何っつか、何につかうのってきけば？
833 ：仕様書無しさん：2007/06/03(日) 00:18:21
俺、java知らんが
つまり、finalにはdynamic bindingとstatic bindingがあるといことだろ。
C++じゃ普通じゃな、ココ電!
ま、俺的にはjavaのfinalはstatic bindingと妄想してたが
つまり、finalにはdynamic bindingとstatic bindingがあるといことだろ。
C++じゃ普通じゃな、ココ電!
ま、俺的にはjavaのfinalはstatic bindingと妄想してたが
834 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 00:21:24
例
static final int a = 1;
if( a==0 ){ // ここと
// この中はコンパイルされない。
}
static final int a = 1;
if( a==0 ){ // ここと
// この中はコンパイルされない。
}
ひたすらスレタイを無視するスレはここですか？
ここです
>>834 それはただの最適化。言語仕様とは違う。
電球はさ、Javaが嫌いなだけなら専用スレたてろよ。
839 ：仕様書無しさん：2007/06/03(日) 00:28:17
このスレの副題はココ電球と僕たちだろ？
840 ：仕様書無しさん：2007/06/03(日) 00:28:55
>>839
それには激しく同意
それには激しく同意
841 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 00:30:55
言語仕様じゃないもんね
コンパイラの話だもんね
コンパイラの話だもんね
>>838
いやいや、電球スレこそふさわしい、ココだよココw
いやいや、電球スレこそふさわしい、ココだよココw
>fainal
>fainal
>fainal
>fainal
>fainal
>fainal
>fainal
新人なんですけど、
OOをJavaでやってます
先輩からクラスわけが肝心だと言われたのですが
コツとかありますか？
電球お断りです
OOをJavaでやってます
先輩からクラスわけが肝心だと言われたのですが
コツとかありますか？
電球お断りです
845 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 00:34:41
ココに来て電球にお伺いしないとはとんでもない奴だ、恥を知れ
ところで何時の間に final の話が static final の話になったん？
848 ：仕様書無しさん：2007/06/03(日) 00:36:08
>>841 プリプロセッサとコンパイラは別物だし、
コンパイラの実装なんてベンダーの気分次第。
結論。javaのfinalはマクロなどでは決してありません。
勝手に自分の都合のいい解釈を押し付けるな。
コンパイラの実装なんてベンダーの気分次第。
結論。javaのfinalはマクロなどでは決してありません。
勝手に自分の都合のいい解釈を押し付けるな。
849 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 00:36:14
勝ったな
文句なしだな
文句なしだな
>>847
電球があほだから
電球があほだから
とうとう掲示板の一個人の登校を持ち出してきやがったか
「Java final コンパイラ」で検索したらしい
「Java final コンパイラ」で検索したらしい
852 ：仕様書無しさん：2007/06/03(日) 00:38:31
ファイナルアンサー？
853 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 00:38:43
いつもニコニコ全コンパイル
電球が土曜に寂しいひきこもりをしている件について
しかも9年前の投稿。Visual J++ 1.1って
>855
そんなの新人に見せてもなんもならん
>844
先輩について聞け
本とか読んですぐに身につくものでもない
あえて言うなら、自分が見えてる範囲のものをそのまま表現するだけだ
そんなの新人に見せてもなんもならん
>844
先輩について聞け
本とか読んですぐに身につくものでもない
あえて言うなら、自分が見えてる範囲のものをそのまま表現するだけだ
電球あほすぎるｗ
859 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 00:49:06
適当なのなかったからそれでいいだろ。
SUNのjavac.exeでもおんなじだ。
泣きを見たくなかったらクラス生成時に初期化されるなんて説明が間違いであって
コンパイル時に埋め込まれるって事を胆に命じておくことだな。
SUNのjavac.exeでもおんなじだ。
泣きを見たくなかったらクラス生成時に初期化されるなんて説明が間違いであって
コンパイル時に埋め込まれるって事を胆に命じておくことだな。
Stringはプリミティブに近い扱いだからstatic finalで定義しとくとマクロっぽく動いているように見えるけど本質はどうかな・・
で？
す、すみません
デザインパターンって何ですか！？！？？！
リンクのデザインパターンの落とし穴という目次自体意味がわからないです（汗
デザインパターンって何ですか！？！？？！
リンクのデザインパターンの落とし穴という目次自体意味がわからないです（汗
>>859 どんな泣き見ることになるの？
final static なら
ココ電の
>コンパイル時に埋め込まれるって事
が常識的なやり方(実装）に思うが違うのか？
ココ電の
>コンパイル時に埋め込まれるって事
が常識的なやり方(実装）に思うが違うのか？
新人にわかるわけがない
電球のガキっぽいところは
マジでむかつく
マジでむかつく
>>864 お前、さてはおじゃばだな？
>>867 違うぞ
オジャバは土日はレスしないってことを知らないな。おまいはまだマ版の新人だろ
オジャバは土日はレスしないってことを知らないな。おまいはまだマ版の新人だろ
>>868 そんなことわかるめぇ？ 土日はコテ外してるかもしらん。
なんせ会社のＰＣから書き込むぐらいの奴だからな。
なんせ会社のＰＣから書き込むぐらいの奴だからな。
デザインパターンと玉葱はよくにている
若い頃には旨さが理解できなく、煮込めば煮込むほど甘みがでておいしくなる
スライスを水にさらしただけで食すのもまたよし
若い頃には旨さが理解できなく、煮込めば煮込むほど甘みがでておいしくなる
スライスを水にさらしただけで食すのもまたよし
電球とかどうでもいいんだけど、static finalな値を持つクラスをコンパイルしたら、
その値を参照してるクラスも自動的にコンパイルかかるようになってるよね。
その値を参照してるクラスも自動的にコンパイルかかるようになってるよね。
873 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 01:13:03
マクロはまだ～？
>>872
よくわからんが、それはfinal staticがスタティックリンクだからってことか？
よくわからんが、それはfinal staticがスタティックリンクだからってことか？
876 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 01:27:03
ちゃう
teisuu = 0;
・・・
a = class.teisuu
をコンパイルすると
a=0 に変換されてコンパイルされる。
複雑な式を使っても確定値ならコンパイラが計算して確定値を埋め込む
プリプロセッサの振る舞いだ
teisuu = 0;
・・・
a = class.teisuu
をコンパイルすると
a=0 に変換されてコンパイルされる。
複雑な式を使っても確定値ならコンパイラが計算して確定値を埋め込む
プリプロセッサの振る舞いだ
電球は自分の発言に責任もたないよな
マクロについて答えてやれよ
マクロについて答えてやれよ
それが無能クオリティ
879 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/03(日) 01:34:40
おまい、こんだけ説明してるのになに言っちゃってんの
つ マクロ
>>879
負け犬の遠吠えだな
負け犬の遠吠えだな
だからプリミティブ型とクラスでは挙動違うから。
そもそもすれ違いですから。
そもそもすれ違いですから。
883 ：仕様書無しさん：2007/06/03(日) 01:46:40
電球いなくなれ
static final int a = new Random().nextInt(10);
とかはコンパイル後も毎回値が変わるから実行時に評価されるてるようだな。
とかはコンパイル後も毎回値が変わるから実行時に評価されるてるようだな。
そうか、されるてるか
コテが悲惨なスレランキング入り記念カキコ
888 ：仕様書無しさん：2007/06/03(日) 23:40:53
ココ電逝ったぁぁあああああああああああああああああああああ
889 ：仕様書無しさん：2007/06/03(日) 23:41:08
ココ電逝ったぁあああああああああああああああ
890 ：仕様書無しさん：2007/06/03(日) 23:42:18
class JesusChrist {
}
}
891 ：仕様書無しさん：2007/06/03(日) 23:43:20
class Yen extends Currency {
}
}
ココ電逝ったぁぁあああ
／:.:.:.:::::ヽ,
（（ i:.:.:.:.:::::::::l_N
i:.:.:.:::::::::::}） ＜ 市況にかえるぞ
!:.:.:.:::::::::::ヽ
ﾉ:.:.:.:::::::::::i::::}
i:.:./:::::::／i:/､
〃/ﾚ ∧/―〈／､
/ ﾘ､: :i: : :i: :',ヽ_)
/ ヽ.┼r―┘
（T∀T∩)l .l l |
⊂ .│,' | |
ヽ （ ノ_,' L」
(( （＿）し'ー' ー'
, '' , ''
（（ i:.:.:.:.:::::::::l_N
i:.:.:.:::::::::::}） ＜ 市況にかえるぞ
!:.:.:.:::::::::::ヽ
ﾉ:.:.:.:::::::::::i::::}
i:.:./:::::::／i:/､
〃/ﾚ ∧/―〈／､
/ ﾘ､: :i: : :i: :',ヽ_)
/ ヽ.┼r―┘
（T∀T∩)l .l l |
⊂ .│,' | |
ヽ （ ノ_,' L」
(( （＿）し'ー' ー'
, '' , ''
オブジェクト指向ってやっぱり集められたPGは
OO経験者として募集されてるの？
そんな話聞いたことなくって
OO経験者として募集されてるの？
そんな話聞いたことなくって
895 ：仕様書無しさん：2007/06/04(月) 00:04:17
ココ電球さんもプロでグラマー。
896 ：仕様書無しさん：2007/06/04(月) 00:08:07
ココ電は来月、参議院議員になっているからな。
>>894
聞いたことねーな
聞いたことねーな
モデリングの練習って今だと何参考にしてる？
もう８年前のモデリングじゃ古くてアフォ臭いからさ
何か良さげなものあったら教えてちょ
もう８年前のモデリングじゃ古くてアフォ臭いからさ
何か良さげなものあったら教えてちょ
ケーキ屋さんとお客さんと店員さんと、ケーキと値段
900 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/04(月) 20:33:44
901 ：仕様書無しさん：2007/06/04(月) 21:03:36
902 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/04(月) 21:31:27
反省してるか？
903 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/04(月) 21:32:09
おじゃばは反省どころか日本語も判らんようだな。
904 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/04(月) 21:35:45
∥
｣{_
j!＾ll
ll ll
ll ll
ll ll
ll ll
ll ll
_,z-'ｰ ､ ll ll
ｨ´, ,__,､Nﾊ ll. ll
ゝ(ﾅｰ' _')ﾘ＿, -－'､_ ｌレ-－ｚ ← おじゃば
ＹP￣/ o､ ｀ﾄl､ 八ｒ-x‐ﾃ
/^ｰ< ノヾ⌒､ｰ'､ |ﾘｌト､Ｖ´ ,､‐ヘ、
{ ,ニ､/ ,! //川／｀Y ＼ ＼
ヽ{ ﾊ､__∠／/彡ｲ⌒ ｰヽ‐- ヽ- ヽ
｀ヾ=≦ﾆ三≦彡ｲ ﾉ
｀ヽﾆt=ヽ {､ ＿,／
＼ﾞヽﾆﾝ´ ￣ ￣ ／
` －---－''´
>>904
ココ電、これは何をしているんだ？
ココ電、これは何をしているんだ？
>>906
夜食を捕獲しようと罠を張ったの忘れて外に出てしまったのさ面目ない。
なぜ裸かかって？そりゃ、デスマ中でこんな山中だ雨が降った今日じゃ
ねーと体と頭あらえねーもんな。
自己申告しておくけど結構くせーから近寄らない方がいいぞ
夜食を捕獲しようと罠を張ったの忘れて外に出てしまったのさ面目ない。
なぜ裸かかって？そりゃ、デスマ中でこんな山中だ雨が降った今日じゃ
ねーと体と頭あらえねーもんな。
自己申告しておくけど結構くせーから近寄らない方がいいぞ
908 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/04(月) 23:19:56
おしおき中の図
ほんとにおまえはつまらんのな
910 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/05(火) 11:42:54
>>901
Javaのコーディングルールは1.4で止まってる。新文法使う必要性がないんだよな。
1.5のGenericは互換性がなくなるだけで利点がない。オブジェクト指向とは関係ないし。
コーディングの行数を減らすだけの技術だな。俺はJavaへのGeneric導入は反対派だよ。
JavaにAssertとGeneric入れたバカは氏ねって感じ。templateやoperatorはC++で使っている。
Javaのコーディングルールは1.4で止まってる。新文法使う必要性がないんだよな。
1.5のGenericは互換性がなくなるだけで利点がない。オブジェクト指向とは関係ないし。
コーディングの行数を減らすだけの技術だな。俺はJavaへのGeneric導入は反対派だよ。
JavaにAssertとGeneric入れたバカは氏ねって感じ。templateやoperatorはC++で使っている。
911 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/05(火) 11:46:42
一日中暇そうなヤツだな
おじゃばは年寄りだけあって保守的なんだな。
下位バージョンで使えない機能を追加できないとなると進化は止まってしまう。
assertを否定する意味もわからん。
下位バージョンで使えない機能を追加できないとなると進化は止まってしまう。
assertを否定する意味もわからん。
914 ：仕様書無しさん：2007/06/05(火) 12:28:51
画面IDなんかをそのままクラス名にするのは止めて頂きたい。
XD0023 って何をするクラスなのかいちいち調べんの面倒臭いんだよ。
XD0023 って何をするクラスなのかいちいち調べんの面倒臭いんだよ。
915 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/05(火) 20:07:14
日立かどっかですか？
社内規定でそういうクラス名つけてるとか
社内規定でそういうクラス名つけてるとか
916 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/05(火) 20:09:34
>>913
使うか使わないかを選んでいるだけで、新しい物を全く使わないと言っている訳ではない。
「コーディングルールが1.4」と言うのは、1.5や1.6を使っても、templateやassertは使わないと言う意味だ。
assertを否定するのは、Tomcat用に1.5で書かれたソースをWeblogic用（VM1.4）に持って来た時に、
コンパイルエラーが出たからだ。
使うか使わないかを選んでいるだけで、新しい物を全く使わないと言っている訳ではない。
「コーディングルールが1.4」と言うのは、1.5や1.6を使っても、templateやassertは使わないと言う意味だ。
assertを否定するのは、Tomcat用に1.5で書かれたソースをWeblogic用（VM1.4）に持って来た時に、
コンパイルエラーが出たからだ。
JUnitあるから態々言語レベルで用意しなくてもいいじゃないってことなんじゃないの？>assert
下位互換のない記述されてたら、そりゃエラーになるわなぁ。
assertは1.4からだろ。コンパイルオプションがおかしいだけ。
>>575
「だから」って言われても困るなー、言いたいことがサッパリ分からん
>>910
確かにCore Libraryや、Commonsとかが中途半端にしかGeneric化されてない
から今のところ意味ないんだよね・・・・GenericsはJ.Goslingが入れることを決定
したからコミュニティは反論できんでしょ
逆に、どうせソースレベルの互換性が無くなるなら、色々なところを直すベキだった
と思うよ。C++の過ち再びって感じ・・・まあOOPSとは直接関係しないけどModern
C++ DesignにあるようなGenericsによるDesign patternsの利用には必要になる
から、javax.xxxとして新しいCore Libraryを記述する人には必要なんだけどさ・・
確かに一般の人がそれを使う方向に行くとは考えられないし、理解が乏しいまま
使っちゃって無意味なソースを書いて欲しくないよ
「だから」って言われても困るなー、言いたいことがサッパリ分からん
>>910
確かにCore Libraryや、Commonsとかが中途半端にしかGeneric化されてない
から今のところ意味ないんだよね・・・・GenericsはJ.Goslingが入れることを決定
したからコミュニティは反論できんでしょ
逆に、どうせソースレベルの互換性が無くなるなら、色々なところを直すベキだった
と思うよ。C++の過ち再びって感じ・・・まあOOPSとは直接関係しないけどModern
C++ DesignにあるようなGenericsによるDesign patternsの利用には必要になる
から、javax.xxxとして新しいCore Libraryを記述する人には必要なんだけどさ・・
確かに一般の人がそれを使う方向に行くとは考えられないし、理解が乏しいまま
使っちゃって無意味なソースを書いて欲しくないよ
Javaでソースレベルの後方互換なんて、いままでだってご利益あったためしがないよ。
コアライブラリのインタフェースに互換性がないんだから。
それとも、新しいコアライブラリで追加されたメソッドなんかは極力つかわないようにしてんのか？
コアライブラリのインタフェースに互換性がないんだから。
それとも、新しいコアライブラリで追加されたメソッドなんかは極力つかわないようにしてんのか？
deprecated はSUNの免罪符
>>922
そうだよ。それのせいで前方互換すらないじゃん。
そうだよ。それのせいで前方互換すらないじゃん。
924 ：仕様書無しさん：2007/06/05(火) 22:31:50
>>915
日立じゃないけど、全てのクラス名が画面IDとか機能IDになってる。
気が狂いそうになる。可読性もなんもあったもんじゃない。
ここまで徹底してるのは珍しいけど、時々こういう設計はみかける。
何のメリットがあるのか俺にはさっぱり分からない。
日立じゃないけど、全てのクラス名が画面IDとか機能IDになってる。
気が狂いそうになる。可読性もなんもあったもんじゃない。
ここまで徹底してるのは珍しいけど、時々こういう設計はみかける。
何のメリットがあるのか俺にはさっぱり分からない。
台帳による管理さ
ドメインの名詞をそのまま使った方がよっぽど分かり易いと思うんだが。やっぱり分からん。
汎用機はファイル名が８桁までだったから、そのなごりだろ
>>924
> 全てのクラス名が画面IDとか機能IDになってる。
> 何のメリットがあるのか俺にはさっぱり分からない。
長年そのシステムで飯を食ってる奴が大きな顔ができるメリットがある
新規で入ってきた人間にはまず理解できないだろう
> 全てのクラス名が画面IDとか機能IDになってる。
> 何のメリットがあるのか俺にはさっぱり分からない。
長年そのシステムで飯を食ってる奴が大きな顔ができるメリットがある
新規で入ってきた人間にはまず理解できないだろう
>>924
俺そうゆうのちまちま解析しててて
だいたい理解できた頃に追い出された事あるよw
お前みたいなのがいると俺達は仕事がなくなるとか
言ってたなぁwまぁかかわらない方がいいよどのみち
保守性も開発効率も最悪グダグダだから
俺そうゆうのちまちま解析しててて
だいたい理解できた頃に追い出された事あるよw
お前みたいなのがいると俺達は仕事がなくなるとか
言ってたなぁwまぁかかわらない方がいいよどのみち
保守性も開発効率も最悪グダグダだから
930 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/06(水) 02:15:37
F1ドライバーは運転技術を覚えればいい。
細かいエンジンや車体構造を頭に詰め込むのは間違いよ
細かいエンジンや車体構造を頭に詰め込むのは間違いよ
日本語でおｋ
>>930
細かい構造・セッティングその他もろもろを理解してないドライバーなどアマチュアレベルでも存在しない。
技術だけしかない香具師は運転代行でもやってろ。
今更ながら、電球の底の浅さに改めて驚いた。ｱﾌｫか。
細かい構造・セッティングその他もろもろを理解してないドライバーなどアマチュアレベルでも存在しない。
技術だけしかない香具師は運転代行でもやってろ。
今更ながら、電球の底の浅さに改めて驚いた。ｱﾌｫか。
>930
お前F1ナメてんだろ
お前F1ナメてんだろ
だから
× F1ドライバーは運転技術を覚えればいい。
○ 一般のドライバーは運転技術だけを覚えればいい。
× F1ドライバーは運転技術を覚えればいい。
○ 一般のドライバーは運転技術だけを覚えればいい。
789 名前： ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. 投稿日： 2007/06/02(土) 20:47:37
java のfinalは定数じゃなくてマクロだよ
java のfinalは定数じゃなくてマクロだよ
936 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/06(水) 20:10:44
>>電球
つーか、少しはF1ドライバーがどういう物か調べてみた方がいいんじゃね？
その後で、F1ドライバーの人に謝れ。
つーか、少しはF1ドライバーがどういう物か調べてみた方がいいんじゃね？
その後で、F1ドライバーの人に謝れ。
937 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/06(水) 20:23:42
マクロだよ
#defineとおなじ
#defineとおなじ
938 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/06(水) 20:27:26
また息をするように嘘をつく
プロのドライバーだった人知ってるけど、なんでハンドルが重いのか知らないで手の皮むきながら運転してた話がある。
整備員が知ってたみたいだけど何も教えてくれなかった。
プロのドライバーだった人知ってるけど、なんでハンドルが重いのか知らないで手の皮むきながら運転してた話がある。
整備員が知ってたみたいだけど何も教えてくれなかった。
なんの話してんの？
ソフトウェアのエンドユーザーは、システムの内部の仕組みを知らなくてもいい。
開発者（SE・PG）はシステムの内部のことを知らないとだめ。
そういう話？
ソフトウェアのエンドユーザーは、システムの内部の仕組みを知らなくてもいい。
開発者（SE・PG）はシステムの内部のことを知らないとだめ。
そういう話？
普通の車を運転する人ならともかく、
F1レーサーは細かいエンジンや車体構造を知らないとダメだろ？
ただ単に走ればいいだけの人と、誰よりも速く走らないといけない人では
必要となる知識に違いがある。
細かいエンジンや車体構造を知ることで、
少しでもより速く走れるようになる可能性があるのなら、
当然知っておくべきだ。
（まあ知らなくてもいいが、そいつは遅いレーサーで一生を終えるだろうね）
F1レーサーは細かいエンジンや車体構造を知らないとダメだろ？
ただ単に走ればいいだけの人と、誰よりも速く走らないといけない人では
必要となる知識に違いがある。
細かいエンジンや車体構造を知ることで、
少しでもより速く走れるようになる可能性があるのなら、
当然知っておくべきだ。
（まあ知らなくてもいいが、そいつは遅いレーサーで一生を終えるだろうね）
三輪車とかは車体構造知らないと命取りだけどな・・・
F1ドライバーは開発能力も重要な評価ポイント
F1なめるのもいい加減にしろアホコテ
F1なめるのもいい加減にしろアホコテ
F1がテーマではないんだからF1信者は黙っていらばいいのに
いらば
ろくな知識もないくせに例えに出すからだ、糞コテ
947 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/06(水) 22:06:18
脳内妄想で反論してもだめ。
948 ：仕様書無しさん：2007/06/06(水) 23:58:42
949 ：仕様書無しさん：2007/06/07(木) 00:08:15
さておまいらは、PGなわけだがコンピュータのハードについてどれぐらい知っている？
ハードの設計は出来なくてもハードの説明やそれを有効に使う方法ぐらい知ってるよな。
まさか、知らないでソフトの開発してないよな。
だれかPCI-Expressにいて特徴などの説明頼む。優秀なおまいらならどんなものか説明できるだろ。
ハードの設計は出来なくてもハードの説明やそれを有効に使う方法ぐらい知ってるよな。
まさか、知らないでソフトの開発してないよな。
だれかPCI-Expressにいて特徴などの説明頼む。優秀なおまいらならどんなものか説明できるだろ。
ぐぐれかす
ここまでの流れでアホコテが名無し自演してるらしいことが発覚
952 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/07(木) 00:37:02
俺ハード屋さんだったけどそんなもん知らんな。
WorkViewなら知ってるが
WorkViewなら知ってるが
>>949
もまえPGだよな仕様書よんでね
http://www.pcisig.com/members/downloads/specifications/pciexpress/PCI_Express_CEM_r2.0_cb.pdf
もまえPGだよな仕様書よんでね
http://www.pcisig.com/members/downloads/specifications/pciexpress/PCI_Express_CEM_r2.0_cb.pdf
コテハン二人が完全に荒らしてるな
あからさまな自演も悲惨すぎる
あからさまな自演も悲惨すぎる
田舎の走り屋レベルでも車体構造分かってるよ
田舎の痛車使いですら、それぐらい解かってるのになw
957 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/07(木) 10:16:18
>>949
じゃ、半導体の共有結合の話からいってみようか。
じゃ、半導体の共有結合の話からいってみようか。
>>658 先生！
知らないんで、そ、その半導体の共有結合に説明お願いします。
知らないんで、そ、その半導体の共有結合に説明お願いします。
>>959
真性半導体であるところのSiやGeはIV属だからして、最外殻の電子は4個なわけだが
共有結合することにより8個あるように振舞うわけさ。んで僅かな不純物を入れることで
電子が余ったり (N型半導体)、足りなくなったり (P型半導体) するわけだね。
でもって、めんどくさいからあと自習。ぐぐれ。
真性半導体であるところのSiやGeはIV属だからして、最外殻の電子は4個なわけだが
共有結合することにより8個あるように振舞うわけさ。んで僅かな不純物を入れることで
電子が余ったり (N型半導体)、足りなくなったり (P型半導体) するわけだね。
でもって、めんどくさいからあと自習。ぐぐれ。
以下、各自予習しておくこと。
ダイオードとトランジスタ
バイポーラかユニポーラか
論理ゲートとデコーダ
フリップフロップ、カウンタ
ワイアードロジックからマイクロコンピュータへ
高級言語の登場
制御の抽象化、データの抽象化
ソフトウェア・パターン
でも職業PGやSEはなーんも知らんでもなれるらしい。
ダイオードとトランジスタ
バイポーラかユニポーラか
論理ゲートとデコーダ
フリップフロップ、カウンタ
ワイアードロジックからマイクロコンピュータへ
高級言語の登場
制御の抽象化、データの抽象化
ソフトウェア・パターン
でも職業PGやSEはなーんも知らんでもなれるらしい。
電子回路専攻だから前半はなんとかなる
でさらに後半のものも勉強したら潰しが利いて使い捨てにされないプログラマになれますか？
でさらに後半のものも勉強したら潰しが利いて使い捨てにされないプログラマになれますか？
>>964
薄いのは俺の知識。関数型とかSmalltalk系OOPLとか知らんし。
薄いのは俺の知識。関数型とかSmalltalk系OOPLとか知らんし。
> ワイアードロジックからマイクロコンピュータへ
> 高級言語の登場
この間に
ノイマン型アーキテクチャの発明
マシン語の登場
アセンブラ出現
Unixの製造
Unixを移植しやすくするための言語C登場
さまざまなプログラム言語、言語の方言乱立により規格化の機運が高まる
とかが入る必要があると思う
> 高級言語の登場
この間に
ノイマン型アーキテクチャの発明
マシン語の登場
アセンブラ出現
Unixの製造
Unixを移植しやすくするための言語C登場
さまざまなプログラム言語、言語の方言乱立により規格化の機運が高まる
とかが入る必要があると思う
オブジェクト的プログラムの話は多いけど、設計の話は少ないからじゃね？
968 ：仕様書無しさん：2007/06/07(木) 23:11:34
オブジェクト指向分析が今一流行らない理由。それは、多分、日本の平均的な
技術者の英語力不足も一因だと思うんだ。
オブジェクト指向分析の基本は、ドメインに存在する概念を擬物化し、名詞を
クラスや属性に、動作や振る舞いをメソッドへと、抽象化していく作業なのに、
その仮定で、ドキュメント（DB設計書やクラス設計書）へ記載されるキーワード
の扱いが中途半端で、trnsts とか shipdt とか chkflg とか何だかぱっと見、
よく意味のわからない識別子が使われてしまうんだよな。
メソッド名にしても、addSyohizei みたいに和洋折衷になったり、isExist みた
いに、間違った英語表現になったりしてるのをよく見かける。
エラーもせっかく例外という抽象化表現があるのに、いまだに旧態依然のエラー
番号で管理してたりとか。
そもそもプログラミング言語の文法が英語をもとにしてて、英語名と相性がいい
ものなのに、そのメリットを無視して変な名前をつけてるせいで、オブジェクト
指向が本来もたらす分かり易さという恩恵が、日本人に対しては半減されているん
じゃないかと思ったりする。
技術者の英語力不足も一因だと思うんだ。
オブジェクト指向分析の基本は、ドメインに存在する概念を擬物化し、名詞を
クラスや属性に、動作や振る舞いをメソッドへと、抽象化していく作業なのに、
その仮定で、ドキュメント（DB設計書やクラス設計書）へ記載されるキーワード
の扱いが中途半端で、trnsts とか shipdt とか chkflg とか何だかぱっと見、
よく意味のわからない識別子が使われてしまうんだよな。
メソッド名にしても、addSyohizei みたいに和洋折衷になったり、isExist みた
いに、間違った英語表現になったりしてるのをよく見かける。
エラーもせっかく例外という抽象化表現があるのに、いまだに旧態依然のエラー
番号で管理してたりとか。
そもそもプログラミング言語の文法が英語をもとにしてて、英語名と相性がいい
ものなのに、そのメリットを無視して変な名前をつけてるせいで、オブジェクト
指向が本来もたらす分かり易さという恩恵が、日本人に対しては半減されているん
じゃないかと思ったりする。
>>968
addSyohizei に関してはアレだけど、isExist は英語圏の人でも普通にやるぞ。
Goggleのソースコードサーチでもかけてみろ、禿。
英語力は重要だが、それは最新技術を読むためと、英語をベースとしたプログラミング言語になれる為。
英語の文法能力なんていらねーんだよ。
addSyohizei に関してはアレだけど、isExist は英語圏の人でも普通にやるぞ。
Goggleのソースコードサーチでもかけてみろ、禿。
英語力は重要だが、それは最新技術を読むためと、英語をベースとしたプログラミング言語になれる為。
英語の文法能力なんていらねーんだよ。
ワンモアセッ！
ここでビリーバンドなしで参加しているブリジェットを見てみよう
JavaのBean規約で、述語にはisをつけるって決まってるから
isExistはしかたなくやってるんだよ。
isExistはしかたなくやってるんだよ。
英語英語って、
おまぃらかぶれるのは結構だが、
作業してる連中が「英語ができること」で集められてるか？
言語と経験年数だけだろ。
たまにメソッド名や変数名に必死になって英語表記しようとする奴がいるが、
英語にこだわりすぎて、逆に可読性が落ちてることに気づかない奴がいる
重要なのはそういうセンス。英語がどうこうなんてのは二の次。
おまぃらかぶれるのは結構だが、
作業してる連中が「英語ができること」で集められてるか？
言語と経験年数だけだろ。
たまにメソッド名や変数名に必死になって英語表記しようとする奴がいるが、
英語にこだわりすぎて、逆に可読性が落ちてることに気づかない奴がいる
重要なのはそういうセンス。英語がどうこうなんてのは二の次。
977 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/07(木) 23:53:20
インチキだから流行らない
>>976 例を書いてくれなきゃ解りにくい。もしかして自分のこと言ってんのかw
979 ：仕様書無しさん：2007/06/07(木) 23:59:19
>>977 インチキな奴に言われたかない。
>>978
似非PG発見
似非PG発見
>>980
なんだよ書けねぇのかよ、説得力無い奴だなぁ。もう辞めたら？
なんだよ書けねぇのかよ、説得力無い奴だなぁ。もう辞めたら？
>>981
電球自演やめたら？
電球自演やめたら？
984 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/08(金) 00:15:58
TOEIC一級です
ちっ、バレたか。
>>984
新しいな
新しいな
あれだ策士策におぼれる。ってやつ
オーバーライドを多用することだけを考えて作ったりとか。
そーゆーことでそ？
javaで構造化、これでいいよ。インターフェイスは定数書き込むだけ。
だけどフレームワークと職場には多多異性が必要だよね。
オーバーライドを多用することだけを考えて作ったりとか。
そーゆーことでそ？
javaで構造化、これでいいよ。インターフェイスは定数書き込むだけ。
だけどフレームワークと職場には多多異性が必要だよね。
TOEICって級じゃないだろw
ん？
おれは2段だぞ
おれは2段だぞ
990 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/08(金) 10:00:25
実際、OOは慣れの問題でもある。
初めての言語がJavaでOOで組んでいる人もいるが、論理を明確に説明出来なくても、
問題なく設計出来ている人も多い。その人達に聞くと、構造化の方が難しいと言っている。
確かにそうだ。OOの場合は最初は物体をオブジェクトにして考えるからブレが少ない。
それに対して構造化は要求をフローに変換してから考える。つまり変換作業が必要だ。
問題なのは「変換に慣れてしまった人」が「新たにOOをやる場合」である。
まあ、やらなくてもいいんじゃね？
初めての言語がJavaでOOで組んでいる人もいるが、論理を明確に説明出来なくても、
問題なく設計出来ている人も多い。その人達に聞くと、構造化の方が難しいと言っている。
確かにそうだ。OOの場合は最初は物体をオブジェクトにして考えるからブレが少ない。
それに対して構造化は要求をフローに変換してから考える。つまり変換作業が必要だ。
問題なのは「変換に慣れてしまった人」が「新たにOOをやる場合」である。
まあ、やらなくてもいいんじゃね？
992 ：おじゃばさま ◆GxjxF3yEw6 ：2007/06/08(金) 19:19:56
なんといういい加減さ、それがおじゃばクオリティー
994 ：仕様書無しさん：2007/06/08(金) 22:01:38
>>990
OOは勉強を始めた所なのでなんともいえないが、
構造化ってのは人間側の思考とプロセッサの最大効率との折衷案という側面を持つ。
人間にある程度わかりやすく、かつプロセッサに都合のいいように
合理的な細分化を行う必要がある。
もともとは大規模なシステムを多数の小規模の物にして普通の人間でも
把握しやすいようにという思想が根底にあるし、それが目的。
対するオブジェクトなんちゃらはコンサルが放つ銀の弾丸という側面を持つんだろ。
ここでその本質を目にすることは無茶苦茶少ないし。
OOは勉強を始めた所なのでなんともいえないが、
構造化ってのは人間側の思考とプロセッサの最大効率との折衷案という側面を持つ。
人間にある程度わかりやすく、かつプロセッサに都合のいいように
合理的な細分化を行う必要がある。
もともとは大規模なシステムを多数の小規模の物にして普通の人間でも
把握しやすいようにという思想が根底にあるし、それが目的。
対するオブジェクトなんちゃらはコンサルが放つ銀の弾丸という側面を持つんだろ。
ここでその本質を目にすることは無茶苦茶少ないし。
だから、業務フローを表現するのにはオブジェクト設計は適さないんだって
せいぜい画面に貼り付けるチェックボックスとか、プルダウンとか、
文字列とかの「部品」を設計するのに役に立つぐらい
せいぜい画面に貼り付けるチェックボックスとか、プルダウンとか、
文字列とかの「部品」を設計するのに役に立つぐらい
996 ：ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84. ：2007/06/08(金) 22:24:59
業務フローはフローチャートが適する
データーベースは変化していく集合を扱うのでOOは適さない。
データーベースは変化していく集合を扱うのでOOは適さない。
.NET Framework にしても、JavaAPI にしても、STLにしても、
オブジェクト指向で、とってもきれいに使い易く設計してある。
構造化設計より、よっぽど合理的で解り易い。
これみて、ＯＯを否定する奴は、自分にこういう設計ができない
からひがんでるだけとしか思えないんだが。
オブジェクト指向で、とってもきれいに使い易く設計してある。
構造化設計より、よっぽど合理的で解り易い。
これみて、ＯＯを否定する奴は、自分にこういう設計ができない
からひがんでるだけとしか思えないんだが。
多分オレが頭悪いからなんだけど、OO勉強しだした頃は、どうあがいてもうまくｲﾒｰｼﾞが湧かなくて、挫折しそうになった。
習うより慣れろってな
1000 ：仕様書無しさん：2007/06/08(金) 23:14:32
せん
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。