オブジェクト指向は難しすぎ
1 ：仕様書無しさん：
なんであんなもんが必要になるの？
遅いしコード量が増えるし無駄じゃん。
抽象クラスって何よ？
中何も書いて無いじゃん。そんなもんつくってどうすんの？
無駄じゃん。
privateって何よ？ なんでprivateなんて指定するわけ？
常に変数にアクセスできたほうが便利じゃん。
オブジェクト指向って何がなんだかわかんねーーーーー
遅いしコード量が増えるし無駄じゃん。
抽象クラスって何よ？
中何も書いて無いじゃん。そんなもんつくってどうすんの？
無駄じゃん。
privateって何よ？ なんでprivateなんて指定するわけ？
常に変数にアクセスできたほうが便利じゃん。
オブジェクト指向って何がなんだかわかんねーーーーー
|
|
|
なんで糞スレが必要になるの？
遅いし糞スレ量が増えるし無駄じゃん。
糞スレって何よ？
中何無いじゃん。そんなもんつくってどうすんの？
無駄じゃん。
糞スレって何よ？ なんで糞スレなんて指定するわけ？
常に糞にアクセスできたほうが便利じゃん。
糞スレって何がなんだかわかんねーーーーー
遅いし糞スレ量が増えるし無駄じゃん。
糞スレって何よ？
中何無いじゃん。そんなもんつくってどうすんの？
無駄じゃん。
糞スレって何よ？ なんで糞スレなんて指定するわけ？
常に糞にアクセスできたほうが便利じゃん。
糞スレって何がなんだかわかんねーーーーー
実際はメインプログラマにとって
手足のように使えるフレームワークを整えるための道具
フレームワークの使い方を覚えさせられる立場になると
凄く惨めな気分になるよ
逆に俺色のフレームワークに染めたプロジェクトは
やはり俺の仕事の効率が鬼スピードになる
けど仕事量も鬼のように増える罠
けど俺色に染めるスタイルのほうが好きだな～
手足のように使えるフレームワークを整えるための道具
フレームワークの使い方を覚えさせられる立場になると
凄く惨めな気分になるよ
逆に俺色のフレームワークに染めたプロジェクトは
やはり俺の仕事の効率が鬼スピードになる
けど仕事量も鬼のように増える罠
けど俺色に染めるスタイルのほうが好きだな～
とりあえず過去スレ一覧を貼れ。話はそれからだ。
6 ：仕様書無しさん：04/09/06 20:55
【関連スレ】
マ板のPGにオブジェクト指向を覚えさせたい!
http://pc5.2ch.net/test/read.cgi/prog/1081700132/l20
ガンダムでオブジェクト指向を語るスレ
http://pc5.2ch.net/test/read.cgi/prog/1068040637/l20
【過去スレ】
結局オブジェクト指向って
http://pc3.2ch.net/prog/kako/1080/10807/1080724890.html
オブジェクト指向を理解できんとが何で悪いとや？
http://makimo.to/2ch/pc_prog/1060/1060622436.html
オブジェクト指向は戦場では必要なし
パート１ http://pc.2ch.net/tech/kako/1011/10119/1011997945.html
パート２ http://pc.2ch.net/tech/kako/1013/10132/1013266554.html
パート３ http://pc.2ch.net/tech/kako/1013/10138/1013875413.html
パート４ http://pc3.2ch.net/tech/kako/1021/10214/1021468476.html
パート５ http://pc3.2ch.net/tech/kako/1027/10279/1027983898.html
パート６ http://pc3.2ch.net/tech/kako/1029/10292/1029297075.html
パート７ http://pc3.2ch.net/tech/kako/1030/10300/1030029357.html
パート８ http://pc3.2ch.net/tech/kako/1031/10310/1031028125.html
パート９ http://pc3.2ch.net/tech/kako/1032/10329/1032985885.html
パート１０ http://pc.2ch.net/prog/kako/1033/10339/1033919004.html
マ板のPGにオブジェクト指向を覚えさせたい!
http://pc5.2ch.net/test/read.cgi/prog/1081700132/l20
ガンダムでオブジェクト指向を語るスレ
http://pc5.2ch.net/test/read.cgi/prog/1068040637/l20
【過去スレ】
結局オブジェクト指向って
http://pc3.2ch.net/prog/kako/1080/10807/1080724890.html
オブジェクト指向を理解できんとが何で悪いとや？
http://makimo.to/2ch/pc_prog/1060/1060622436.html
オブジェクト指向は戦場では必要なし
パート１ http://pc.2ch.net/tech/kako/1011/10119/1011997945.html
パート２ http://pc.2ch.net/tech/kako/1013/10132/1013266554.html
パート３ http://pc.2ch.net/tech/kako/1013/10138/1013875413.html
パート４ http://pc3.2ch.net/tech/kako/1021/10214/1021468476.html
パート５ http://pc3.2ch.net/tech/kako/1027/10279/1027983898.html
パート６ http://pc3.2ch.net/tech/kako/1029/10292/1029297075.html
パート７ http://pc3.2ch.net/tech/kako/1030/10300/1030029357.html
パート８ http://pc3.2ch.net/tech/kako/1031/10310/1031028125.html
パート９ http://pc3.2ch.net/tech/kako/1032/10329/1032985885.html
パート１０ http://pc.2ch.net/prog/kako/1033/10339/1033919004.html
8 ：仕様書無しさん：04/09/06 21:12
>>7
その、萎んだの、触りたい。
触らせて。
俺、男だけど。
トイレ行くの？
一緒に行こう。
……ほら、二人きり。
はい。出してみなよ。
……わあ。可愛いな。
色もキレイ。薄い桜色。
震えているのかい？ こういうコト、はじめて？ 大丈夫、怖くないよ。
いい？ 触るよ？
柔らかい。すごく。気持ちいい？ あ……。大きくなって来た。
感じる？ すごい。こんな硬くなって来た。
しゃぶっていい？ してあげる。ほら、チカラ、抜いて……。
その、萎んだの、触りたい。
触らせて。
俺、男だけど。
トイレ行くの？
一緒に行こう。
……ほら、二人きり。
はい。出してみなよ。
……わあ。可愛いな。
色もキレイ。薄い桜色。
震えているのかい？ こういうコト、はじめて？ 大丈夫、怖くないよ。
いい？ 触るよ？
柔らかい。すごく。気持ちいい？ あ……。大きくなって来た。
感じる？ すごい。こんな硬くなって来た。
しゃぶっていい？ してあげる。ほら、チカラ、抜いて……。
9 ：ほんたま：04/09/06 22:29
なんでオブジェクト指向理解できないもんがPGになるの？
何でプログラム組むの？
コンビニでバイトすればいいじゃん。土方やればいいじゃん。
プログラム組んで何すんの？
ひーーーーわかんねーーーーー
何でプログラム組むの？
コンビニでバイトすればいいじゃん。土方やればいいじゃん。
プログラム組んで何すんの？
ひーーーーわかんねーーーーー
>>9＝沢村
/ 人 。 ミミミ/川川川＼ミミミ
/ /| ミミ〇川|||/ ヽ|||||〇ミミ
/ / | ／干＼| |川メ 卅川
＼ ＼ | | （|| ＞ ＜ ||） _ や…やめてくらさい！！
＼ Ｖ_⌒ｖ⌒＼〉 ゝ UⅴU ノ 赤ちゃんができちゃうのれす！！
＼__ξ 丶／⌒ - - ヽ
/ ＼ | | / |
/ ノ＼＿_| |＿__,＿ノ |
ビュクッ…ビュル | | ゜ ゜ | |
ドクッドクッ
/ 人 。 ミミミ/川川川＼ミミミ
/ /| ミミ〇川|||/ ヽ|||||〇ミミ
/ / | ／干＼| |川メ 卅川
＼ ＼ | | （|| ＞ ＜ ||） _ や…やめてくらさい！！
＼ Ｖ_⌒ｖ⌒＼〉 ゝ UⅴU ノ 赤ちゃんができちゃうのれす！！
＼__ξ 丶／⌒ - - ヽ
/ ＼ | | / |
/ ノ＼＿_| |＿__,＿ノ |
ビュクッ…ビュル | | ゜ ゜ | |
ドクッドクッ
11 ：仕様書無しさん：04/09/08 01:33
コボラーでロリコンで浮気癖と浪費癖がある奴のスレ。
>>6 乙
13 ：ほんたま：04/09/08 22:48
おみゃ～らよ、オブジェクト指向はなくてもいい。だがあったほうが便利だ。
同様に、構造体もなくてもいい。だがあったほうが便利だ。
おみゃ～らよ、構造体を使わないやつはいなだろう？
なくてもいいのにだ。
なくてもいい例を示す。
onnaという構造体に、
nameと
sizeがあったとする。
そしてonna[1]を{"大下容子",160}
onna[2]を{"樋口可南子",167}と初期化する。
するとonna[1].nameで大下容子に、onna[2].sizeで167に自動的にアクセスできとても便利だ。
だが、おみゃ～らよ、
これは変数onnanameとonnasizeを使ってもまったく同じだぞ！！
onnaname[1]を"大下容子"onnaname[1]を"樋口可南子",
onnasize[1]を160で、onnasize[2]を167で初期化したとしても、
onnaname[1]で"大下容子"に、onnasize[2]で167に自動的にアクセスでき、
onna[1].nameで大下容子に、onna[2].sizeで167に自動的にアクセスできるのとまったく一緒だろ？
にもかかわらずおみゃ～らは、構造体はふつーに使うわけだ。
構造体は別に使わずに、変数でやってもまったく同じなのに、おみゃ～らは、何故構造体を使う？
おみゃ～らよ、まずそれを考えろ！！そして答えろ！
おみゃ～らが納得のいく答えを出したら、次はいよいよオブジェクト指向の真の便利だについて説明してやるぞ♪
どれ、自分じ答えちみろ？
同様に、構造体もなくてもいい。だがあったほうが便利だ。
おみゃ～らよ、構造体を使わないやつはいなだろう？
なくてもいいのにだ。
なくてもいい例を示す。
onnaという構造体に、
nameと
sizeがあったとする。
そしてonna[1]を{"大下容子",160}
onna[2]を{"樋口可南子",167}と初期化する。
するとonna[1].nameで大下容子に、onna[2].sizeで167に自動的にアクセスできとても便利だ。
だが、おみゃ～らよ、
これは変数onnanameとonnasizeを使ってもまったく同じだぞ！！
onnaname[1]を"大下容子"onnaname[1]を"樋口可南子",
onnasize[1]を160で、onnasize[2]を167で初期化したとしても、
onnaname[1]で"大下容子"に、onnasize[2]で167に自動的にアクセスでき、
onna[1].nameで大下容子に、onna[2].sizeで167に自動的にアクセスできるのとまったく一緒だろ？
にもかかわらずおみゃ～らは、構造体はふつーに使うわけだ。
構造体は別に使わずに、変数でやってもまったく同じなのに、おみゃ～らは、何故構造体を使う？
おみゃ～らよ、まずそれを考えろ！！そして答えろ！
おみゃ～らが納得のいく答えを出したら、次はいよいよオブジェクト指向の真の便利だについて説明してやるぞ♪
どれ、自分じ答えちみろ？
いいから日本語喋れﾁﾝｶｽ
なんであんなもんが必要になるの？
感触悪いし気分が萎えるし無駄じゃん。
コンドームって何よ？
中に出せてないじゃん。そんなもんつくってどうすんの？
無駄じゃん。
避妊って何よ？ なんで避妊なんて推奨するわけ？
常に子宮にアクセスできたほうが快感じゃん。
ご懐妊って何がなんだかわかんねーーーーー
感触悪いし気分が萎えるし無駄じゃん。
コンドームって何よ？
中に出せてないじゃん。そんなもんつくってどうすんの？
無駄じゃん。
避妊って何よ？ なんで避妊なんて推奨するわけ？
常に子宮にアクセスできたほうが快感じゃん。
ご懐妊って何がなんだかわかんねーーーーー
昔、オブジェクト指向を勉強していたのだが、
UMLに落胆して、やめてしまいました。
正直言って、UML使うと要件定義から実装まで
シームレスな開発が出来るの？
UMLに落胆して、やめてしまいました。
正直言って、UML使うと要件定義から実装まで
シームレスな開発が出来るの？
18 ：仕様書無しさん：04/09/09 20:24
>>16
> 正直言って、UML使うと要件定義から実装まで
> シームレスな開発が出来るの？
できるわけないじゃない。機能外仕様、GUI仕様、
データベース設計、通信インターフェイス仕様などなど
書けない仕様がたくさんある。
UMLで全部できると思うのは初心者の陥りやすい勘違い。
実務でUMLをつかっている人ならみんなわかっていること。
> 正直言って、UML使うと要件定義から実装まで
> シームレスな開発が出来るの？
できるわけないじゃない。機能外仕様、GUI仕様、
データベース設計、通信インターフェイス仕様などなど
書けない仕様がたくさんある。
UMLで全部できると思うのは初心者の陥りやすい勘違い。
実務でUMLをつかっている人ならみんなわかっていること。
このスレ見てたら、うんこしたくなった。
これからしてくる。
これからしてくる。
>>17
>>18
私はねぇ。オブジェクト指向でシームレスな開発ができると期待してたの。
古い話で申し訳ないが、
OMTとユースケースとオブジェクトパターン、デザインパターンを組み合わせれば、
それが可能じゃないかって思ってたんだよね。
だから、統一手法を作るってランボーとヤコブソンが手を組むと聞いたとき、
（ブーチはどっちでも良かった）、小躍りしたもんさ。
そしたら、出てきたのが単なる図の表記法だけ。
本当にがっかりして、オブジェクト指向の勉強をやめてしまった。
元々、コードは多くなるし、オブジェクト指向を他の人に理解させるのが、
難しいという課題には気づいていたからね。
なんか今やUMLは常識らしいから勉強しなきゃいけないかなぁなんて思ってる。
若いヤツらにバカにされるしさ。
なにやらOOやUMLのスレ見ると「最強」みたいな書き方しているから、
もしかして、俺の勉強やめてた間にめざましい進歩があったのかと思ったよ。
>>17さん、>>18さんのような人がいてホッとした。
何となく盲目的にOOやUMLを信じている気がしたから。
そして、追加質問。
私が勉強していた時には、本質的に理解している人は日本でも数人しか
いないんじゃないかと思ってたよ。
それが、今やオブジェクト指向出来なきゃクズみたいな書き方している人がいる。
本当にみんなオブジェクト指向って理解できてるの？
非常に俗人的で分かりやすい考え方じゃないと思うんだけどねぇ。
>>18
私はねぇ。オブジェクト指向でシームレスな開発ができると期待してたの。
古い話で申し訳ないが、
OMTとユースケースとオブジェクトパターン、デザインパターンを組み合わせれば、
それが可能じゃないかって思ってたんだよね。
だから、統一手法を作るってランボーとヤコブソンが手を組むと聞いたとき、
（ブーチはどっちでも良かった）、小躍りしたもんさ。
そしたら、出てきたのが単なる図の表記法だけ。
本当にがっかりして、オブジェクト指向の勉強をやめてしまった。
元々、コードは多くなるし、オブジェクト指向を他の人に理解させるのが、
難しいという課題には気づいていたからね。
なんか今やUMLは常識らしいから勉強しなきゃいけないかなぁなんて思ってる。
若いヤツらにバカにされるしさ。
なにやらOOやUMLのスレ見ると「最強」みたいな書き方しているから、
もしかして、俺の勉強やめてた間にめざましい進歩があったのかと思ったよ。
>>17さん、>>18さんのような人がいてホッとした。
何となく盲目的にOOやUMLを信じている気がしたから。
そして、追加質問。
私が勉強していた時には、本質的に理解している人は日本でも数人しか
いないんじゃないかと思ってたよ。
それが、今やオブジェクト指向出来なきゃクズみたいな書き方している人がいる。
本当にみんなオブジェクト指向って理解できてるの？
非常に俗人的で分かりやすい考え方じゃないと思うんだけどねぇ。
どこまでをOOPにするか悩む時はある。
そんな事で悩むのはＯＯＰをわかってない証拠
↑？
OOPS
16はOOPを複雑に考えすぎてない？
>>25
うん、多分複雑に考えてる。
そして、UML覚えるの面倒だなぁと思ってる。
昔は自分のOO分かってるつもりだったんだけどね。
抽象クラスばっかり作ってたよｗ
実は今はOOよりもDOAの方に興味がある。
うん、多分複雑に考えてる。
そして、UML覚えるの面倒だなぁと思ってる。
昔は自分のOO分かってるつもりだったんだけどね。
抽象クラスばっかり作ってたよｗ
実は今はOOよりもDOAの方に興味がある。
Javaから始めたのでオブジェクト指向以外の作り方がわからない
Perlの後から付け足したようなOOPから初めて、
今Javaやってる。鬱。
今Javaやってる。鬱。
>>27
そういう人間で本当にオブジェクト指向分かってる奴は存在しない。
そういう人間で本当にオブジェクト指向分かってる奴は存在しない。
だからさっきから"本当に分かって無い"とかホザいてる奴、
"本当のOOP"を見せてくれよ
"本当のOOP"を見せてくれよ
32 ：仕様書無しさん：04/09/09 23:47
>>31
とりあえずこんなんだよ。
Human ojiisan = new Human("おじいさん");
Human obaasan = new Human("おばあさん");
ojiisan.go(yama);
obaasan.go(kawa);
ojiisan.cut(shiba);
obaasan.wash();
Fruit momo = new Momo();
obaasan.find(momo);
obaasan.get(momo);
obaasan.go(home);
ojiisan.go(home);
ojiisan.cut(momo);
Human momotaro = momo.born();
とりあえずこんなんだよ。
Human ojiisan = new Human("おじいさん");
Human obaasan = new Human("おばあさん");
ojiisan.go(yama);
obaasan.go(kawa);
ojiisan.cut(shiba);
obaasan.wash();
Fruit momo = new Momo();
obaasan.find(momo);
obaasan.get(momo);
obaasan.go(home);
ojiisan.go(home);
ojiisan.cut(momo);
Human momotaro = momo.born();
例が意味不明過ぎてﾊｹﾞﾜﾛﾀ
34 ：(^ｰ')b ◆EoOYgmEaZE ：04/09/10 00:07
便利になればなるほど必要な仕事は増えるものです
35 ：仕様書無しさん：04/09/10 01:53
>>32
これは悪い実装の例だろ？
ojiisan.wash(); //通りそうだし
//引数によって処理を変えるわけ？
ojiisan.cut(shiba);
ojiisan.cut(momo);
せっかくだからHumanを継承してOjiisanやObaasanクラスを作れよ
これは悪い実装の例だろ？
ojiisan.wash(); //通りそうだし
//引数によって処理を変えるわけ？
ojiisan.cut(shiba);
ojiisan.cut(momo);
せっかくだからHumanを継承してOjiisanやObaasanクラスを作れよ
別に若い人じゃなくても、おれは昔からSmalltalkでオブジェクト指向を
勉強してたぞ。でもＣやＣＯＢＯＬも一応わかるぞ。
すまん、FORTRANだけは勘弁して。リアルプログラマーならFORTRAN
をやるべきなんだろうが....
勉強してたぞ。でもＣやＣＯＢＯＬも一応わかるぞ。
すまん、FORTRANだけは勘弁して。リアルプログラマーならFORTRAN
をやるべきなんだろうが....
やっぱmayersが神だよな
39 ：仕様書無しさん：04/09/10 04:57
40 ：仕様書無しさん：04/09/10 04:58
41 ：仕様書無しさん：04/09/10 05:00
おおむね、
Human.cut(ICuttable cut)
{
cut.cut();
}
Human.cut(ICuttable cut)
{
cut.cut();
}
・・・識別子をローマ字で書くな
> Fruit momo = new Momo();
> obaasan.find(momo);
こうはどうだ？
Fruit& momo = dynamic_cast<Fruit&>(obaasan.find());
> obaasan.find(momo);
こうはどうだ？
Fruit& momo = dynamic_cast<Fruit&>(obaasan.find());
>>42
cnut
cnut
>>44
cunt
cunt
オブジェクト指向と聞くと継承やらポリフォルミズムやらを云々する人が多いようだが
本質的なのはそこじゃないだろうと言いたい。
本質的なのはそこじゃないだろうと言いたい。
こらこら、みんな日本語を使わなくちゃいけないよ。
>>36
私の場合は、お金が無かったので、
Cで抽象化プログラムってので頑張ってました。
しかし、みんなが付いてきてくれないので途中でやめましたｗ
会社の若いのがラップ(綴りが分からないｗ）がどうのこうのと言っています。
これはどうなんでしょう？読んだ方、感想が聞きたいです。
設計の属人性を排除できますか？シームレスな・・・
できれば日本語でｗ
>>36
私の場合は、お金が無かったので、
Cで抽象化プログラムってので頑張ってました。
しかし、みんなが付いてきてくれないので途中でやめましたｗ
会社の若いのがラップ(綴りが分からないｗ）がどうのこうのと言っています。
これはどうなんでしょう？読んだ方、感想が聞きたいです。
設計の属人性を排除できますか？シームレスな・・・
できれば日本語でｗ
私の発言ってメチャクチャスレ違いだよね。
私はSEでプログラムも作ります（副業でPMもやってますｗ）。
オブジェクト指向(特にUML)やWEBは好きではないけど、
標準だというので仕方なく勉強しようかなぁと思っているところです。
でも、本質的にオブジェクト指向っていいものなのって
したたかな目で取り組みたいと思っています。
うざいと思っている方々、こんな私を誰か誘導して；；
私はSEでプログラムも作ります（副業でPMもやってますｗ）。
オブジェクト指向(特にUML)やWEBは好きではないけど、
標準だというので仕方なく勉強しようかなぁと思っているところです。
でも、本質的にオブジェクト指向っていいものなのって
したたかな目で取り組みたいと思っています。
うざいと思っている方々、こんな私を誰か誘導して；；
49 ：仕様書無しさん：04/09/10 23:03:41
>>35
> せっかくだからHumanを継承してOjiisanやObaasanクラスを作れよ
そうやって初期設定が違うだけのオブジェクトを作るのに、いちいちクラスを
こさえると、クラスがたくさんできちゃう場合もある。
型を増やさないで Prototype パターンでやる方法もある。
> せっかくだからHumanを継承してOjiisanやObaasanクラスを作れよ
そうやって初期設定が違うだけのオブジェクトを作るのに、いちいちクラスを
こさえると、クラスがたくさんできちゃう場合もある。
型を増やさないで Prototype パターンでやる方法もある。
50 ：仕様書無しさん：04/09/10 23:05:08
Prototype パターンには Factory Method パターンが使えるね。
Human ojiisan = HumanFactory.createOjiisan();
Human obaasan = HumanFactory.createObaasan();
Human ojiisan = HumanFactory.createOjiisan();
Human obaasan = HumanFactory.createObaasan();
51 ：18：04/09/10 23:36:21
>>47
オブジェクト指向が難しいといってるけど、それってファウラー
がいっているようなアナリシスパターンや各種方法論がいっている
要求分析やそこからからOOD(オブジェクト指向設計)への落とし方
なんかのことをいっているんだよね。
個人的な感想を言わせてもらうとこれらのことをきちんと形式知
として理解していて、俗にアーキテクトと呼ばれる仕事ができる人
は少ないと思う。じゃあ、アーキテクトがいないのにどうやって設計を
やっているというと個人の経験でなんとなくでやっていことが多いん
じゃないかな。個人の経験のなんとなく(暗黙知)でやっているから
属人性が排除できない。
大体、RUPなんかの方法論で提唱されている方法自体が
本当に「実践」するのが簡単かっていうとかなりあやしいところ。
勉強すればするほど思うのが、本当に普通の人にできるのか?
と疑問が深くなっていく。
ユースケースひとつをとってもまともに書くのが難しい。
ユースケースの粒度をそろえるだけでも大変だし、書いたとしても
そこから直接シーケンス図なんかの動的モデルやクラス図なんかの
静的モデルに落としてモデリングのは難しいところ。このギャップを
埋めるためにCRC分析をはじめとして色々あるけど。
なので人によってはユースケース自体を肯定的に受け止めて
いない人も存在する。自分もそう。
で、結局、このあたりの設計の属人性が排除できるか?というと
みんなそこに苦労して試行錯誤している感じ。色々あるけど
決定打はない。そもそも銀の弾丸は存在しないとは思うけど。
オブジェクト指向が難しいといってるけど、それってファウラー
がいっているようなアナリシスパターンや各種方法論がいっている
要求分析やそこからからOOD(オブジェクト指向設計)への落とし方
なんかのことをいっているんだよね。
個人的な感想を言わせてもらうとこれらのことをきちんと形式知
として理解していて、俗にアーキテクトと呼ばれる仕事ができる人
は少ないと思う。じゃあ、アーキテクトがいないのにどうやって設計を
やっているというと個人の経験でなんとなくでやっていことが多いん
じゃないかな。個人の経験のなんとなく(暗黙知)でやっているから
属人性が排除できない。
大体、RUPなんかの方法論で提唱されている方法自体が
本当に「実践」するのが簡単かっていうとかなりあやしいところ。
勉強すればするほど思うのが、本当に普通の人にできるのか?
と疑問が深くなっていく。
ユースケースひとつをとってもまともに書くのが難しい。
ユースケースの粒度をそろえるだけでも大変だし、書いたとしても
そこから直接シーケンス図なんかの動的モデルやクラス図なんかの
静的モデルに落としてモデリングのは難しいところ。このギャップを
埋めるためにCRC分析をはじめとして色々あるけど。
なので人によってはユースケース自体を肯定的に受け止めて
いない人も存在する。自分もそう。
で、結局、このあたりの設計の属人性が排除できるか?というと
みんなそこに苦労して試行錯誤している感じ。色々あるけど
決定打はない。そもそも銀の弾丸は存在しないとは思うけど。
オブジェクト指向的パラダイムでは属人性云々の排除は無理。
ララァ＝エルメス的パラダイムのように属人性をマシンが平均化
してしまうようなあり方への移行という選択枝が実装されたら...
つことで、誰か、ビヨンドしてくれ。w
ララァ＝エルメス的パラダイムのように属人性をマシンが平均化
してしまうようなあり方への移行という選択枝が実装されたら...
つことで、誰か、ビヨンドしてくれ。w
アジャイルは属人を基本としたプロセスですね。
56 ：仕様書無しさん：04/09/11 02:36:59
>>55
うｐろだって知ってますか？
うｐろだって知ってますか？
57 ：仕様書無しさん：04/09/11 03:40:18
58 ：仕様書無しさん：04/09/11 04:13:11
ねずみ＝千恵先生（仕事人）の自演バレましたとさ
☆ Ｎ Ｗ Ｏ アンコール！ ☆
http://music4.2ch.net/test/read.cgi/musice/1094750724/
以下やりとり
205 ：千恵先生 ◆rdNWOq77Og ：04/09/10 22:38:02 ID:uCSQSbL2
209 ：ねずみ ◆Fuck.wc4XU ：04/09/10 22:39:42 ID:VfhL37dZ
221 ：ねずみ ◆rdNWOq77Og ：04/09/10 22:50:35 ID:uCSQSbL2
↑
ＩＤに注目。
いつの間にか>205「千恵先生」（ID:uCSQSbL2 ）が
>221では「ねずみ」に
またも下手な自演で醜態を見せた涙の引き篭もり女
・ねずみ様と洋楽について語り合うスレ！
世の中に出るのが怖い、2ちゃんねる命のヘタレ自演キチガイ女、
もう消えていいよ。
パパに病院連れていってもらいな。心安らかに（ﾌﾟﾌﾟﾌﾟ
☆ Ｎ Ｗ Ｏ アンコール！ ☆
http://music4.2ch.net/test/read.cgi/musice/1094750724/
以下やりとり
205 ：千恵先生 ◆rdNWOq77Og ：04/09/10 22:38:02 ID:uCSQSbL2
209 ：ねずみ ◆Fuck.wc4XU ：04/09/10 22:39:42 ID:VfhL37dZ
221 ：ねずみ ◆rdNWOq77Og ：04/09/10 22:50:35 ID:uCSQSbL2
↑
ＩＤに注目。
いつの間にか>205「千恵先生」（ID:uCSQSbL2 ）が
>221では「ねずみ」に
またも下手な自演で醜態を見せた涙の引き篭もり女
・ねずみ様と洋楽について語り合うスレ！
世の中に出るのが怖い、2ちゃんねる命のヘタレ自演キチガイ女、
もう消えていいよ。
パパに病院連れていってもらいな。心安らかに（ﾌﾟﾌﾟﾌﾟ
59 ：仕様書無しさん：04/09/11 11:48:13
動作と状態とを規定された「オブジェクト」というものが
互いに協力しながら全体として目的のプロセスを実行する
・・・というのが本質かと。
ポリやら継承なんかより、むしろカプセル化とかが本質。
互いに協力しながら全体として目的のプロセスを実行する
・・・というのが本質かと。
ポリやら継承なんかより、むしろカプセル化とかが本質。
仕 様 書 っ て も ん が あ る だ ろ う
>>60
そりゃ構造化の頃からある。
そりゃ構造化の頃からある。
63 ：仕様書無しさん：04/09/11 13:53:02
いまどきオブジェクト指向も理解できない奴はカス
この業界のゴミ以下
この業界のゴミ以下
65 ：仕様書無しさん：04/09/11 14:08:24
OOで何ができて何ができないのか分かってないとなぁ・・・
システム開発ってプログラム作るだけじゃ無いし
システム開発ってプログラム作るだけじゃ無いし
とうか、「この板の住人には」というのを頭に追加すべきだ
67 ：仕様書無しさん：04/09/11 15:02:54
要は、モデリングがすべて。
へぼいクラス作られても迷惑、デスマの根源。
へぼいクラス作られても迷惑、デスマの根源。
ポリフォルミズムってなんだ？
69 ：仕様書無しさん：04/09/11 15:57:08
>>68
オーガズムと親戚のようなものだと考えれば、大きな間違いはありません。
オーガズムと親戚のようなものだと考えれば、大きな間違いはありません。
>>69先生、一つかしこくなりました。
そうだねー、同じ大卒レベルの香具師ら集めてセミナーやって理解度を客観的にみると、
優秀な理系卒のやつらほど習得は速いねぇ。逆に文系三流大卒や体育会系の連中ほど飲み込み遅い。
抽象化、インタフェイスとまで、なんとなくはわかっても、いざ、自分で設計・コーディングとなると
とたんに根をあげる。そいつの戦闘値が高いかどうかを判断するにはオブジェクト指向は有用な物差しといえるｗ
優秀な理系卒のやつらほど習得は速いねぇ。逆に文系三流大卒や体育会系の連中ほど飲み込み遅い。
抽象化、インタフェイスとまで、なんとなくはわかっても、いざ、自分で設計・コーディングとなると
とたんに根をあげる。そいつの戦闘値が高いかどうかを判断するにはオブジェクト指向は有用な物差しといえるｗ
なんかやたらに複雑な構造のクラス類を作るやついない？
なんか分かりにくいぞ～って中身を読んでたら、
ここは普通クラス分けるだろ、とかこれなんで分かれてんだ？とかばっかり。
そういうやつが、デザインパターンがどうとかオブジェクト指向がどうとかほざく。
なんか分かりにくいぞ～って中身を読んでたら、
ここは普通クラス分けるだろ、とかこれなんで分かれてんだ？とかばっかり。
そういうやつが、デザインパターンがどうとかオブジェクト指向がどうとかほざく。
>>73
ペアプロでリファクタリングしる
ペアプロでリファクタリングしる
ありがちですなあ。
学校の課題程度で「OOPの手法に則って継承関係をry」とか
得意げにレポートに書いてるやつを見て唖然とした。
そういうのに限って
if (a == true) return true;
なんていう糞コードを平気で書くし・・・。
学校の課題程度で「OOPの手法に則って継承関係をry」とか
得意げにレポートに書いてるやつを見て唖然とした。
そういうのに限って
if (a == true) return true;
なんていう糞コードを平気で書くし・・・。
>>51
そうですね。私はOOA、OOD、OOPを繋ぐモノを期待していることに
気づきました。
銀の弾丸はないとは言いますが、やっぱり求めてしまいますね。
せめて、自分なりのやり方を確立したいのですが、毎回、迷いが出てしまい、
常に苦労します。RUPなどもなかなか甘くは無さそうですね。
毎回苦労するのは割り切って考えられればいいのでしょうが、
いつか破綻する気がして怖いです（実はもう破綻しているかもｗ）。
>>53
やっぱり、時代はニュータイプの出現を期待しているのでしょうか。
「あと5年ぐらいすればコードを書かなくて良くなる」と豪語していた
ツールベンダーがいましたが、生温い目で見てました。
>>54
最初、アジャイルって聞いたとき、インドの都市の名前？と思ってしまったｗ
XPは少数精鋭を前提にしている気がしますね。少数精鋭ならどんなやり方をしても
うまくいくんですけどね。
とにかく、私は若い人たちのUML語が理解できないので、サルでも分かるUMLでも
読んでボチボチやっていきます。
そうですね。私はOOA、OOD、OOPを繋ぐモノを期待していることに
気づきました。
銀の弾丸はないとは言いますが、やっぱり求めてしまいますね。
せめて、自分なりのやり方を確立したいのですが、毎回、迷いが出てしまい、
常に苦労します。RUPなどもなかなか甘くは無さそうですね。
毎回苦労するのは割り切って考えられればいいのでしょうが、
いつか破綻する気がして怖いです（実はもう破綻しているかもｗ）。
>>53
やっぱり、時代はニュータイプの出現を期待しているのでしょうか。
「あと5年ぐらいすればコードを書かなくて良くなる」と豪語していた
ツールベンダーがいましたが、生温い目で見てました。
>>54
最初、アジャイルって聞いたとき、インドの都市の名前？と思ってしまったｗ
XPは少数精鋭を前提にしている気がしますね。少数精鋭ならどんなやり方をしても
うまくいくんですけどね。
とにかく、私は若い人たちのUML語が理解できないので、サルでも分かるUMLでも
読んでボチボチやっていきます。
みなさんの意見を聞いていると、やはりOOでの開発は難しいというのが
分かります。
私はOOは象牙の塔ではないかと思い、勉強するのをやめました。
その直後から、OOが主流になってきました。
やはり、OOには職人芸的な要素があるんだなぁと思います。
頭のいい人だけが出来るというのでは、エンジニアリングとは呼べません。
それが辛いところだと思います。
OOは素人（エンドユーザ）にも分かりやすいという触れ込みもありましたが、
その辺はどんなものなのでしょう？
前提知識なしにユースケースを見せた場合、ちゃんと理解してくれるんでしょうか？
分かります。
私はOOは象牙の塔ではないかと思い、勉強するのをやめました。
その直後から、OOが主流になってきました。
やはり、OOには職人芸的な要素があるんだなぁと思います。
頭のいい人だけが出来るというのでは、エンジニアリングとは呼べません。
それが辛いところだと思います。
OOは素人（エンドユーザ）にも分かりやすいという触れ込みもありましたが、
その辺はどんなものなのでしょう？
前提知識なしにユースケースを見せた場合、ちゃんと理解してくれるんでしょうか？
＞頭のいい人だけが出来る
練習してるうちにコツがわかってくると思うが。
なんだかんだ言ってみんなに便利だから主流になるんだし。
練習してるうちにコツがわかってくると思うが。
なんだかんだ言ってみんなに便利だから主流になるんだし。
あと、エンドユーザがユースケース図そのものを理解する必要はない。
>>78
便利と言えば便利だね。でも、オブジェクト指向してないと叩かれるでしょ。
まさか、デザインパターン云々とみんなが言う時代が来るとは思わなかったなぁ。
主流になったのは、Webアプリの登場が大きいですよね。
私はWebアプリも嫌いだったりするのだがｗ
>>79
するとユーザさんと話をするときのツールは何を使うのですか？
便利と言えば便利だね。でも、オブジェクト指向してないと叩かれるでしょ。
まさか、デザインパターン云々とみんなが言う時代が来るとは思わなかったなぁ。
主流になったのは、Webアプリの登場が大きいですよね。
私はWebアプリも嫌いだったりするのだがｗ
>>79
するとユーザさんと話をするときのツールは何を使うのですか？
81 ：仕様書無しさん：04/09/11 23:53:39
OO自体は象牙の塔ではないと思うけど、
OOAってのはうまくいってるのを見たことが無いな。
俺的にはユースケース作ったあとは、いきなりテーブル定義にいっちゃうのが一番楽。
プログラムの設計過程ではデザインパターンも頻繁に使うけど、
それが必須かといわれればそんなことはもちろん無い。
正直データ定義さえちゃんとできてれば
プログラムなんかどんなやりかたで作っても大きな差が出るとは思えない。
頭でっかちの方法論オタクはやりかたにこだわって全体を見失うケースが多い。
自分が絶対に正しい、なぜなら本にこう書いてあるから・・・議論になりません
OOAってのはうまくいってるのを見たことが無いな。
俺的にはユースケース作ったあとは、いきなりテーブル定義にいっちゃうのが一番楽。
プログラムの設計過程ではデザインパターンも頻繁に使うけど、
それが必須かといわれればそんなことはもちろん無い。
正直データ定義さえちゃんとできてれば
プログラムなんかどんなやりかたで作っても大きな差が出るとは思えない。
頭でっかちの方法論オタクはやりかたにこだわって全体を見失うケースが多い。
自分が絶対に正しい、なぜなら本にこう書いてあるから・・・議論になりません
83 ：仕様書無しさん：04/09/12 01:19:30
OOは象牙の塔だとしても、
>>1が使うと、砂上の楼閣になる。
>>1が使うと、砂上の楼閣になる。
84 ：仕様書無しさん：04/09/12 01:26:32
おれ的に最低限でも、ユースケース->クラス->シーケンスだな。
中規模以上はＯＯＰでないとつらいんじゃない？
とくに仕様変更の時に実感するよ。
ただ、strutsは好きじゃないが。
中規模以上はＯＯＰでないとつらいんじゃない？
とくに仕様変更の時に実感するよ。
ただ、strutsは好きじゃないが。
中規模以上とかいうが、どんなアプリでOOP使ってるの？
GUI依存のアプリなら、例えばマルチウィンドウのエディタ
なんか書く場合はOOPじゃないと大変なことになるのはわかるけど。
非GUIなアプリ（例えばサーバーのデーモンみたいなやつ）でも
OOPって使うわけ？
なんでも、OOPつーのもしんどいような気がする。
GUI依存のアプリなら、例えばマルチウィンドウのエディタ
なんか書く場合はOOPじゃないと大変なことになるのはわかるけど。
非GUIなアプリ（例えばサーバーのデーモンみたいなやつ）でも
OOPって使うわけ？
なんでも、OOPつーのもしんどいような気がする。
>>85
やってれば自然に設計の部品の単位がオブジェクト単位になってくし・・・。
オブジェクト単位でないとなると、
構造体と、その処理単位で考えるわけで。
数増えると、くくる単位が小さい、ってだけでも大変だと思うだろ。
やってれば自然に設計の部品の単位がオブジェクト単位になってくし・・・。
オブジェクト単位でないとなると、
構造体と、その処理単位で考えるわけで。
数増えると、くくる単位が小さい、ってだけでも大変だと思うだろ。
87 ：仕様書無しさん：04/09/12 11:10:31
>>64
まず藻前はオブジェクト指向の何を知らないのかな？
藻前の知らない事にあわせて質問に答えてあげることは不可能ではないぞ。
それと、予備知識として本は読んだかな。
これも読みなされ。
マ板のPGにオブジェクト指向を覚えさせたい！
http://pc5.2ch.net/test/read.cgi/prog/1081700132/
まず藻前はオブジェクト指向の何を知らないのかな？
藻前の知らない事にあわせて質問に答えてあげることは不可能ではないぞ。
それと、予備知識として本は読んだかな。
これも読みなされ。
マ板のPGにオブジェクト指向を覚えさせたい！
http://pc5.2ch.net/test/read.cgi/prog/1081700132/
>>73
> なんかやたらに複雑な構造のクラス類を作るやついない？
> なんか分かりにくいぞ～って中身を読んでたら、
> ここは普通クラス分けるだろ、とかこれなんで分かれてんだ？とかばっかり。
> そういうやつが、デザインパターンがどうとかオブジェクト指向がどうとかほざく。
>
東大生がかいたコードにそういうのが多かったりする。
すごいことやっているのはわかるが、コメント書いていないことが多い。
調べてみると分かれている理由はわかるんだが。
しかし詰めが甘いなっておもうこともある。
どうせなら、もっともっと分割統治してくれってな
> なんかやたらに複雑な構造のクラス類を作るやついない？
> なんか分かりにくいぞ～って中身を読んでたら、
> ここは普通クラス分けるだろ、とかこれなんで分かれてんだ？とかばっかり。
> そういうやつが、デザインパターンがどうとかオブジェクト指向がどうとかほざく。
>
東大生がかいたコードにそういうのが多かったりする。
すごいことやっているのはわかるが、コメント書いていないことが多い。
調べてみると分かれている理由はわかるんだが。
しかし詰めが甘いなっておもうこともある。
どうせなら、もっともっと分割統治してくれってな
UMLって言語は使えない素人向きなんだけど。
91 ：仕様書無しさん：04/09/12 12:34:21
ＵＭＬをタカをくくってなめてかかっているバカにとってはそう思えてくるんだろうけれどね。
>>90みたいなヴァカなことをいう香具師ってえのは。
英語って言語は使えない素人向きなんだけど。
とかいって英語も勉強しようとせずに
日本語を無理矢理押しつけてアメリカ人と取引交渉しているようなものだよ。
アメリカ人に相手にされず仕事もできないヴァカと一緒だよこりゃ
>>90みたいなヴァカなことをいう香具師ってえのは。
英語って言語は使えない素人向きなんだけど。
とかいって英語も勉強しようとせずに
日本語を無理矢理押しつけてアメリカ人と取引交渉しているようなものだよ。
アメリカ人に相手にされず仕事もできないヴァカと一緒だよこりゃ
例の出し方に無理がある。
言語知らなくてもUMLを使いこなすことが可能なのは事実だ。
言語知らなくてもUMLを使いこなすことが可能なのは事実だ。
小規模開発にはオブジェクト指向はいらないね。
オブジェクトは使うことになるけど、使い捨てになる可能性が高いロジックを
クラスに分ける必要ないし。
同様にRAD開発でも最初はペタに書いておけばいいんじゃないかな。
オブジェクトは使うことになるけど、使い捨てになる可能性が高いロジックを
クラスに分ける必要ないし。
同様にRAD開発でも最初はペタに書いておけばいいんじゃないかな。
95 ：仕様書無しさん：04/09/12 13:44:11
もまいら勘弁してしてくれよーーーー。
そんなことだから、プロジェクトに火がつくんだよ。
そもそもオブジェクト指向が出てきたそもそも理由を勉強してみなよ。
>>業務ﾏﾝｾなＰＬ、ＰＭ、おやじＰＧ、汎用機系ゾンビＳＥ
そんなことだから、プロジェクトに火がつくんだよ。
そもそもオブジェクト指向が出てきたそもそも理由を勉強してみなよ。
>>業務ﾏﾝｾなＰＬ、ＰＭ、おやじＰＧ、汎用機系ゾンビＳＥ
>>88
なんで知ってる！
なんで知ってる！
97 ：仕様書無しさん：04/09/12 13:58:56
>>95
> そもそもオブジェクト指向が出てきたそもそも理由を勉強してみなよ。
そういうことを踏まえたうえでいってる人が多いと思うよ。
優秀な人が作ったシステムはそれは美しい構造をしているものだけど、
要は属人的ってことだからね
ちゃちい業務システム作るのにそんな優秀な人ばかりそろえられないもん。
アホでもマシなものが作れる仕組みがほしいのよ
> そもそもオブジェクト指向が出てきたそもそも理由を勉強してみなよ。
そういうことを踏まえたうえでいってる人が多いと思うよ。
優秀な人が作ったシステムはそれは美しい構造をしているものだけど、
要は属人的ってことだからね
ちゃちい業務システム作るのにそんな優秀な人ばかりそろえられないもん。
アホでもマシなものが作れる仕組みがほしいのよ
98 ：仕様書無しさん：04/09/12 14:13:27
>>80
うちでは本格的なOOPすると叩かれますが何か？
うちでは本格的なOOPすると叩かれますが何か？
完全なオブジェクト指向プログラムって、そもそもないんだよな。
smalltalkって言語がそうだったらしいが、
C++なんかはそもそも構造化プログラミング用の処理系をもってる。
ステートメントで書いてる時点で構造化を受け入れてるんだよ。
ただそれを、オブジェクトにまで高める必要があるかどうかという問題。
smalltalkって言語がそうだったらしいが、
C++なんかはそもそも構造化プログラミング用の処理系をもってる。
ステートメントで書いてる時点で構造化を受け入れてるんだよ。
ただそれを、オブジェクトにまで高める必要があるかどうかという問題。
100 ：うずまら( 'A`)ﾉ⑩ ◆2Gex/8ct1s ：04/09/12 14:32:59
＿＿＿ 、、
| ＼ ┬ し； |─┼─ │ _、_
￣|￣＼ ┼┼┐く | │ ─┼┼─ ヽ( ,_ﾉ`)ノ
| | ￣￣|.│││； | ._| │┘ へﾉ /
／ ￣ ﾉ..│└─ ﾚ （ﾉ＼ └──→ ω ノ
>
.＿＿＿ ＿ ＿＿＿ 「「
|＿＿ | _ _. ││◎ |＿＿ |
＿／ ／ . | | | | ┌┘└┐ ＿＿＿ ／／
|＿ .＼ | | | | └┐┌┘ └──┘ ／ く
／／＼＼ // |└ ┐ ◇││◇ ／／＼ ＼
￣ .￣ ~ .￣￣ ￣ ￣ ￣
n n
（ヨ ） （ E）
/ | ∧_∧ ∧_∧ | ヽ
＼ ＼/（ ＾＾ ）／（ ＾＾ ）ヽ／ ／
＼(uu / uu)／
| ＼ ┬ し； |─┼─ │ _、_
￣|￣＼ ┼┼┐く | │ ─┼┼─ ヽ( ,_ﾉ`)ノ
| | ￣￣|.│││； | ._| │┘ へﾉ /
／ ￣ ﾉ..│└─ ﾚ （ﾉ＼ └──→ ω ノ
>
.＿＿＿ ＿ ＿＿＿ 「「
|＿＿ | _ _. ││◎ |＿＿ |
＿／ ／ . | | | | ┌┘└┐ ＿＿＿ ／／
|＿ .＼ | | | | └┐┌┘ └──┘ ／ く
／／＼＼ // |└ ┐ ◇││◇ ／／＼ ＼
￣ .￣ ~ .￣￣ ￣ ￣ ￣
n n
（ヨ ） （ E）
/ | ∧_∧ ∧_∧ | ヽ
＼ ＼/（ ＾＾ ）／（ ＾＾ ）ヽ／ ／
＼(uu / uu)／
オブジェクト指向の目標→ソフトウェアの再利用
102 ：仕様書無しさん：04/09/12 16:11:57
>>96
> >>88
> なんで知ってる！
東大生はプライドが高いから
何か凄いことやらなくちゃ恥だと感じて
初めのうちはあまり意味が感じれら内クラスを沢山つくろうとする傾向にあるようだ。
あとから拡張するときに無意味だと思われたクラスの真価がはっきされるみたいだが、
上司や顧客にせかされて中途半端におわることもしばしば。
すでにさ、標準APIとかにコレクションクラスとか揃っているのに
わざわざスタックとかハッシュとか
それらを自作する香具師とかが結構多い。高学歴にそういう
ことするのが好きな香具師が多い。
> >>88
> なんで知ってる！
東大生はプライドが高いから
何か凄いことやらなくちゃ恥だと感じて
初めのうちはあまり意味が感じれら内クラスを沢山つくろうとする傾向にあるようだ。
あとから拡張するときに無意味だと思われたクラスの真価がはっきされるみたいだが、
上司や顧客にせかされて中途半端におわることもしばしば。
すでにさ、標準APIとかにコレクションクラスとか揃っているのに
わざわざスタックとかハッシュとか
それらを自作する香具師とかが結構多い。高学歴にそういう
ことするのが好きな香具師が多い。
>>103
こないだまで取ってた東大の授業では他人の提出したレポート閲覧できたんだけど、
ホントにそんなやつが多かった。
宿題程度で拡張性とかオブジェクト指向の理念がどうとか言われてもなあ。
そのくせソースには１行のコメントも書かないし。
そういうやつは職業プログラマになってもそのままなんだね。
こないだまで取ってた東大の授業では他人の提出したレポート閲覧できたんだけど、
ホントにそんなやつが多かった。
宿題程度で拡張性とかオブジェクト指向の理念がどうとか言われてもなあ。
そのくせソースには１行のコメントも書かないし。
そういうやつは職業プログラマになってもそのままなんだね。
105 ：仕様書無しさん：04/09/12 16:30:05
クラス一切使わないコードよりはましだけれどもね。
コメントさえ書いてくれれば。
東大に限らず、東工大、慶応大にもそういう学生や卒業生がいるらしい。
コメントさえ書いてくれれば。
東大に限らず、東工大、慶応大にもそういう学生や卒業生がいるらしい。
「俺はコメントさえ書けば読めるコードを書いている」と思いこんでいる人は少なくないね。
ファウラーは「コメントなしでも読めるようなコードを目指しましょう」と言っているぞ。（この記述は権威に弱い人用）
俺も同意見だ
ファウラーは「コメントなしでも読めるようなコードを目指しましょう」と言っているぞ。（この記述は権威に弱い人用）
俺も同意見だ
コメントには「意図」を書くんだよ。
どんなに読みやすいコードだろうと、意図を書かない香具師はカス。
どんなに読みやすいコードだろうと、意図を書かない香具師はカス。
108 ：仕様書無しさん：04/09/12 16:54:39
>>106
コメントをダラダラ書くやつはたしかに嫌だな。
お前コメントの方が時間かかってんじゃないかってくらいw
メソッド名や変数名を上手につけてれば、確かにコメントはあまりいらんね。
読む人を意識して書くってのはコメントをつけるつけないだけの話ではないから。
つけるにしても目次くらいの感じで
コメントをダラダラ書くやつはたしかに嫌だな。
お前コメントの方が時間かかってんじゃないかってくらいw
メソッド名や変数名を上手につけてれば、確かにコメントはあまりいらんね。
読む人を意識して書くってのはコメントをつけるつけないだけの話ではないから。
つけるにしても目次くらいの感じで
>>コメントをダラダラ書くやつはたしかに嫌だな。
逃亡前の準備ですから～、 御免、お先に失礼！
逃亡前の準備ですから～、 御免、お先に失礼！
ちょっと聞きたいんだけどいい？
あるモジュールを開発するとする。
そのモジュールは新規開発であり一から作ることになっている（メンテナンスではない）。
そのモジュール開発はほぼ自分一人でおこなう。したがってクラス設計から何から何まで自分の思い通りにできる。
これからの拡張性・保守性を考え、試行錯誤しながら設計をしていったとする。
すると、納期が迫ってきた。
時間的に間に合わない…。
API部分がまだ甘かったり、コメント部分がまだ書ききれてなかったりする。
書きかけのコードはコメントアウトにしておく。
まぁこれらは次のバージョンの時に完成させよう。今のバージョンでも機能は満たしているしバグも無いし問題ない。
【次のバージョン開発の際】
上司「モジュール担当が代わったから」
俺「( ・ ｘ ・ ;)エッ!?そんなん聞いてない！」
残りの作業はいったいどうすれば…。
機能的には問題ないけど、メンテナが苦労するのでは…。
なんてこと普通にあるんでしょうか。俺はあった。
中途半端にしてしまったことを未だに反省してるし後悔してて胃が痛い。
設計１ヶ月、コーディング＆テストで３ヶ月、コード数約3万行。（Javaでだが）
当時入社２年目の俺には限界まで頑張った末での結果です…。
あるモジュールを開発するとする。
そのモジュールは新規開発であり一から作ることになっている（メンテナンスではない）。
そのモジュール開発はほぼ自分一人でおこなう。したがってクラス設計から何から何まで自分の思い通りにできる。
これからの拡張性・保守性を考え、試行錯誤しながら設計をしていったとする。
すると、納期が迫ってきた。
時間的に間に合わない…。
API部分がまだ甘かったり、コメント部分がまだ書ききれてなかったりする。
書きかけのコードはコメントアウトにしておく。
まぁこれらは次のバージョンの時に完成させよう。今のバージョンでも機能は満たしているしバグも無いし問題ない。
【次のバージョン開発の際】
上司「モジュール担当が代わったから」
俺「( ・ ｘ ・ ;)エッ!?そんなん聞いてない！」
残りの作業はいったいどうすれば…。
機能的には問題ないけど、メンテナが苦労するのでは…。
なんてこと普通にあるんでしょうか。俺はあった。
中途半端にしてしまったことを未だに反省してるし後悔してて胃が痛い。
設計１ヶ月、コーディング＆テストで３ヶ月、コード数約3万行。（Javaでだが）
当時入社２年目の俺には限界まで頑張った末での結果です…。
111 ：仕様書無しさん：04/09/12 18:03:34
>>106
すくなくとも、コメントをかかないときは、
クラス名やメソッド名を見ただけでどんな振る舞いをするかがわかるようになればそれでもええがな。
たとえばJavaならJavadocという機能があるので
何かしらクラスやメソッドには書いてくれるとありがたい。
すくなくとも、コメントをかかないときは、
クラス名やメソッド名を見ただけでどんな振る舞いをするかがわかるようになればそれでもええがな。
たとえばJavaならJavadocという機能があるので
何かしらクラスやメソッドには書いてくれるとありがたい。
すくなくともクラス名は名詞、メソッド名は動詞という原則を守り
わかりやすい名前をつければどうにかなる場合もある。
わかりやすい名前をつければどうにかなる場合もある。
114 ：仕様書無しさん：04/09/12 18:16:56
でも、オブジェクト指向をろくにやらないようなコードで統一されてる
環境で、自分だけクラスをバンバン作ったりすると、コードが浮いちゃうのもたしかなんだよな。
おまけに、不精で本格的なOOPやらないんじゃなくてほんとに理解できない香具師も
いたりするから、その後のコードの保守も全部自分がやらなきゃいけなかったり
して、作業量が増えたりもする。
環境で、自分だけクラスをバンバン作ったりすると、コードが浮いちゃうのもたしかなんだよな。
おまけに、不精で本格的なOOPやらないんじゃなくてほんとに理解できない香具師も
いたりするから、その後のコードの保守も全部自分がやらなきゃいけなかったり
して、作業量が増えたりもする。
頼むから引数と戻り値ぐらい書いてね＞＞
「そんなのメソッドの最初と最後を見ればすぐわかるじゃん」
「わかんねーよばか」
118 ：仕様書無しさん：04/09/12 20:26:33
>>110
もまいの作ったモジュールが糞と評価されたんだと思うが、違うの。
東大生並のモジュールしか作れなかったんだろ。
マジで言うと、３万行のモジュールなら、解析するより、新設計を選ぶよ、漏れなら。
もまいの作ったモジュールが糞と評価されたんだと思うが、違うの。
東大生並のモジュールしか作れなかったんだろ。
マジで言うと、３万行のモジュールなら、解析するより、新設計を選ぶよ、漏れなら。
119 ：いなむらきよし：04/09/12 20:55:27
キケー！
120 ：仕様書無しさん：04/09/12 21:10:05
121 ：仕様書無しさん：04/09/12 21:16:57
>>110
＞これからの拡張性・保守性を考え、試行錯誤しながら設計をしていったとする。
＞すると、納期が迫ってきた。
＞時間的に間に合わない…。
今時ウォーターフォールですか？イテレーション計画立てろよ。
＞API部分がまだ甘かったり、コメント部分がまだ書ききれてなかったりする。
そしてこうなる。スコープ管理して一つ一つ完成させるのが正解。
＞書きかけのコードはコメントアウトにしておく。
シンプルデザインって知ってますか？迷惑です。
＞【次のバージョン開発の際】
＞上司「モジュール担当が代わったから」
見るに見かねてクビでしたとさ。あと
＞設計１ヶ月、コーディング＆テストで３ヶ月、コード数約3万行。（Javaでだが）
リファクタリング一切してないでしょ。
Javaってきちんと作ればコード量増えないぞ。大迷惑。
＞これからの拡張性・保守性を考え、試行錯誤しながら設計をしていったとする。
＞すると、納期が迫ってきた。
＞時間的に間に合わない…。
今時ウォーターフォールですか？イテレーション計画立てろよ。
＞API部分がまだ甘かったり、コメント部分がまだ書ききれてなかったりする。
そしてこうなる。スコープ管理して一つ一つ完成させるのが正解。
＞書きかけのコードはコメントアウトにしておく。
シンプルデザインって知ってますか？迷惑です。
＞【次のバージョン開発の際】
＞上司「モジュール担当が代わったから」
見るに見かねてクビでしたとさ。あと
＞設計１ヶ月、コーディング＆テストで３ヶ月、コード数約3万行。（Javaでだが）
リファクタリング一切してないでしょ。
Javaってきちんと作ればコード量増えないぞ。大迷惑。
122 ：仕様書無しさん：04/09/12 22:00:39
>>81
ユースケースから直接テーブル定義ができるのはエキスパート
だからだと思うんだけど。業務に詳しくて設計に熟練している
ならいいんだけど、それがもろに属人的。それじゃ、初心者は
できないって。
普通の教科書にのっているやり方でもユースケースから
1.ドメインモデリング(概要的なクラス図)
2.シナリオ分析(シーケンス図、CRC)
3.ER分析
ぐらいの過程を経ないとテーブル定義までいきつかないと
思うけど、これでも難しいっていう人もいると思う。
ユースケースから直接テーブル定義ができるのはエキスパート
だからだと思うんだけど。業務に詳しくて設計に熟練している
ならいいんだけど、それがもろに属人的。それじゃ、初心者は
できないって。
普通の教科書にのっているやり方でもユースケースから
1.ドメインモデリング(概要的なクラス図)
2.シナリオ分析(シーケンス図、CRC)
3.ER分析
ぐらいの過程を経ないとテーブル定義までいきつかないと
思うけど、これでも難しいっていう人もいると思う。
123 ：仕様書無しさん：04/09/12 22:07:52
ユースケース・サタンマリア
ま、おまえら糞ＰＧだから、
メンテフェーズには、転職していて責任ないから
どんなコード書き残したっていいわけだよな。(藁
俗人コード万歳！ 氏ねや。w
メンテフェーズには、転職していて責任ないから
どんなコード書き残したっていいわけだよな。(藁
俗人コード万歳！ 氏ねや。w
126 ：仕様書無しさん：04/09/12 22:31:01
聞きたいんだが、本気で属人性が無くなると思ってるのか？
物好きと言われながら家でもコード書いてるような人間と
仕事だから嫌々やってて「動けばいいよ」って言ってる人間が書いたソースが
一緒になるわけないと思うんだが。
誰が書いても変わらないくらい簡単になればそれもあり得るだろうが、
無理だろ。
物好きと言われながら家でもコード書いてるような人間と
仕事だから嫌々やってて「動けばいいよ」って言ってる人間が書いたソースが
一緒になるわけないと思うんだが。
誰が書いても変わらないくらい簡単になればそれもあり得るだろうが、
無理だろ。
属人性を無くすのが無理だという結論に達したから、
ペアプロとかテストファーストとかリファクタリングとかで、
継続的に改善するプロセスが生まれているんだよ。
ペアプロとかテストファーストとかリファクタリングとかで、
継続的に改善するプロセスが生まれているんだよ。
128 ：仕様書無しさん：04/09/12 22:41:14
属人性がなくなるとは思わないけど。
>物好きと言われながら家でもコード書いてるような人間
でも難しい過ぎるのは問題。家でもコードを書いている
人間ならできるって程度には簡単になってほしい。
現実には家でもコード書いている人間でもクソ設計してるだろ。
できてると思う人もいるかもしれないが、自分はそうは
思わないな～。
>物好きと言われながら家でもコード書いてるような人間
でも難しい過ぎるのは問題。家でもコードを書いている
人間ならできるって程度には簡単になってほしい。
現実には家でもコード書いている人間でもクソ設計してるだろ。
できてると思う人もいるかもしれないが、自分はそうは
思わないな～。
みなさん、元気だねぇ。こっちは休みなしで疲れたよ。
どこから話していいのか分からないけど、まず批判を受けてるところから。
まず、最初に言っておきたいのは私はXPは全くやったことありませんし、
ちゃんとしたOOも５年以上やっていないので、あくまで想像での話です。
私はOOやXPは中規模システムまでで大規模システムには
向かないのでは無いかと思っています。
理由として、それだけのある一定レベル以上の人を集めるのが
難しいからです。また、人が多ければ多いほど、統制を取るのが難しくなります。
そのようなわけで少数精鋭では無いかと考えているのです。
もし、大規模システムでも出来ているというのであれば謝ります。
属人性に関しては、やはりエンジニアリングというならば、
そうでないと困るわけです。私はデスマーチはソフトウェア開発が
エンジニアリングになっていないから発生していると考えています。
また、オブジェクト指向の考え方も数学を基礎としているなら、
そうなる可能性があるのでは無いかと想像しています。
ちなみに属人性排除というのは家でたとえればツーバイフォーみたいな感じです。
基本的にある手順を踏めば誰でも作れるけど、それなりの訓練は必要ということです。
どこから話していいのか分からないけど、まず批判を受けてるところから。
まず、最初に言っておきたいのは私はXPは全くやったことありませんし、
ちゃんとしたOOも５年以上やっていないので、あくまで想像での話です。
私はOOやXPは中規模システムまでで大規模システムには
向かないのでは無いかと思っています。
理由として、それだけのある一定レベル以上の人を集めるのが
難しいからです。また、人が多ければ多いほど、統制を取るのが難しくなります。
そのようなわけで少数精鋭では無いかと考えているのです。
もし、大規模システムでも出来ているというのであれば謝ります。
属人性に関しては、やはりエンジニアリングというならば、
そうでないと困るわけです。私はデスマーチはソフトウェア開発が
エンジニアリングになっていないから発生していると考えています。
また、オブジェクト指向の考え方も数学を基礎としているなら、
そうなる可能性があるのでは無いかと想像しています。
ちなみに属人性排除というのは家でたとえればツーバイフォーみたいな感じです。
基本的にある手順を踏めば誰でも作れるけど、それなりの訓練は必要ということです。
OOとXPを並列に並べて議論するなよ。
OOてそんなに難しいんすか？
俺なんとなく理解した気分になってるけど何もわかってませんか？
俺なんとなく理解した気分になってるけど何もわかってませんか？
>>129
>私はOOやXPは中規模システムまでで大規模システムには
>向かないのでは無いかと思っています。
逆だろ？
大規模＆複雑化で一人の人間で把握できる限界を超えるから、
多人数で情報が共有しやすいオブジェクトの考え方が導入されたんだと思うが。
>私はOOやXPは中規模システムまでで大規模システムには
>向かないのでは無いかと思っています。
逆だろ？
大規模＆複雑化で一人の人間で把握できる限界を超えるから、
多人数で情報が共有しやすいオブジェクトの考え方が導入されたんだと思うが。
138 ：でんべえ ◆YcUnSgKinM ：04/09/12 23:29:14
>>129
>そうでないと困るわけです。私はデスマーチはソフトウェア開発が
>エンジニアリングになっていないから発生していると考えています。
どちらかというと、管理工学と経営学、コミニケーション能力かな？
>そうでないと困るわけです。私はデスマーチはソフトウェア開発が
>エンジニアリングになっていないから発生していると考えています。
どちらかというと、管理工学と経営学、コミニケーション能力かな？
>>133 じゃないが、実際にやってみた人の意見が聞きたい。
「XP はこういうもんだ」的な本の受け売りはもういいよ。
>>134
> あとEngineeringだけじゃなくてSoftware Engineeringの勉強もしろ。
こういう空虚な用語ばかり振り回す奴は困るね。
「XP はこういうもんだ」的な本の受け売りはもういいよ。
>>134
> あとEngineeringだけじゃなくてSoftware Engineeringの勉強もしろ。
こういう空虚な用語ばかり振り回す奴は困るね。
>>137 実際にやってその程度のことしか言えないんじゃ困ったね。
XPってなに？ウインドウズ？
>>139
でもどんな手法でも
「本当にこれ役に立つのか？or 役に立っているのか？」
という疑問は出てくるね。
成功したのは本当にその手法のお陰なのか？
（属人性ではないのか？）
本当にその手法は成功しているのか？
（従来の手法でもっといい成果が出ていたのではないのか？
みたいな。
でもどんな手法でも
「本当にこれ役に立つのか？or 役に立っているのか？」
という疑問は出てくるね。
成功したのは本当にその手法のお陰なのか？
（属人性ではないのか？）
本当にその手法は成功しているのか？
（従来の手法でもっといい成果が出ていたのではないのか？
みたいな。
>>137
あら、実践しているか。煽ってみたけど失礼。
もどきでないXPやっているって1件知っているだけなので
これで2件目だな。
XP実践しているってペアプログラミングとか共同所有権
とかオンサイト顧客とか常に実現できてんの?
実現しているんだったら上司や顧客の説得なんかに
苦労していると思うけど、経験者として16に何か
いいアドバイスをしてくれ。
自分の立場でいわせてもらうと、TDDだったら担当者の
がんばりで実現できると思うけどXPは無理だ。
あら、実践しているか。煽ってみたけど失礼。
もどきでないXPやっているって1件知っているだけなので
これで2件目だな。
XP実践しているってペアプログラミングとか共同所有権
とかオンサイト顧客とか常に実現できてんの?
実現しているんだったら上司や顧客の説得なんかに
苦労していると思うけど、経験者として16に何か
いいアドバイスをしてくれ。
自分の立場でいわせてもらうと、TDDだったら担当者の
がんばりで実現できると思うけどXPは無理だ。
>>142
エクストリーム・プログラミングだそうだ。
よく知らんが、オブジェクト指向でも開発効率が上がらない点に対しての改善案みたいな。
プロトタイプをまず作って、機能追加するたびにテストみたいな。中規模システムが
理想だとさ。
まあ抽象論はどうでもいいが・・・。
エクストリーム・プログラミングだそうだ。
よく知らんが、オブジェクト指向でも開発効率が上がらない点に対しての改善案みたいな。
プロトタイプをまず作って、機能追加するたびにテストみたいな。中規模システムが
理想だとさ。
まあ抽象論はどうでもいいが・・・。
だが145が言うように、
>XP実践しているってペアプログラミングとか共同所有権
>とかオンサイト顧客とか常に実現できてんの?
このあたりは難しくくね？
逆にネックになると思うんだが。
実践者詳しく教えて。
>XP実践しているってペアプログラミングとか共同所有権
>とかオンサイト顧客とか常に実現できてんの?
このあたりは難しくくね？
逆にネックになると思うんだが。
実践者詳しく教えて。
>>145
結論から言うと20人以下のプロジェクトなら失敗する気がしない。
100人以上のプロジェクトは部分的な請負しか経験無いから何とも言えない。
ちなみにオンサイトユーザとペアプロを完全に実践するのはまだ無理。
ただし、顧客と開発者のコミュニケーションは十分に整備してる。
あと、一環したペアプロの代わりにポイント絞って低スキル＋高スキル組ませてる。
それから、イテレーティブな契約は難しいけど、
勝手に内部線表引いて定期的に顧客テストしてもらってる。
要は完璧じゃなくてもポイント外さずエッセンスを組み込めば成果は出る。
後はリーダーの勉強量と勇気の問題だね。
ゼロから浸透させたいなら、OOとテストコードとバージョン管理極めて、
いち開発者としてメンバーを巻き込む所から始めると近道。
俺も３年前くらいにそういう苦労を積み重ねた。
結論から言うと20人以下のプロジェクトなら失敗する気がしない。
100人以上のプロジェクトは部分的な請負しか経験無いから何とも言えない。
ちなみにオンサイトユーザとペアプロを完全に実践するのはまだ無理。
ただし、顧客と開発者のコミュニケーションは十分に整備してる。
あと、一環したペアプロの代わりにポイント絞って低スキル＋高スキル組ませてる。
それから、イテレーティブな契約は難しいけど、
勝手に内部線表引いて定期的に顧客テストしてもらってる。
要は完璧じゃなくてもポイント外さずエッセンスを組み込めば成果は出る。
後はリーダーの勉強量と勇気の問題だね。
ゼロから浸透させたいなら、OOとテストコードとバージョン管理極めて、
いち開発者としてメンバーを巻き込む所から始めると近道。
俺も３年前くらいにそういう苦労を積み重ねた。
>結論から言うと20人以下のプロジェクトなら失敗する気がしない。
こりゃすげー。
>要は完璧じゃなくてもポイント外さずエッセンスを組み込めば成果は出る。
ケントベックは全部のプラクティスをやれっていっているけど
それはそうだよな。
>俺も３年前くらいにそういう苦労を積み重ねた。
やっぱり苦労するでしょ。
俺の職場だと「変化を受けれろ」なんていっても、
本質を理解できないから無理な仕様変更を
ねじ込むための口実につかわれる。
シンプルデザインを実践できればいいんだろうけど、
自分の思いつきで複雑な仕様をいってくるし、
それを無理強いされる。
普通の会社だとこんなもんだ。
こりゃすげー。
>要は完璧じゃなくてもポイント外さずエッセンスを組み込めば成果は出る。
ケントベックは全部のプラクティスをやれっていっているけど
それはそうだよな。
>俺も３年前くらいにそういう苦労を積み重ねた。
やっぱり苦労するでしょ。
俺の職場だと「変化を受けれろ」なんていっても、
本質を理解できないから無理な仕様変更を
ねじ込むための口実につかわれる。
シンプルデザインを実践できればいいんだろうけど、
自分の思いつきで複雑な仕様をいってくるし、
それを無理強いされる。
普通の会社だとこんなもんだ。
>>150
>>133のレス同様「変化を受け入れろ」なんて机上の言葉は普通受け入れられない。
自分だけでも実践して高パフォーマンス見せる事こそが全ての始まり。
そんで自分のやってる事をアピール。褒められた時なんかは入れ食いタイム。これでOK。
あと思い付きの仕様は計画ゲームによって管理出来るし、
必要な要求なら複雑でも（シンプルに）実現するのが開発者の使命です。
人のコード邪魔でシンプルデザイン無理？
共通クラス作るとか何とか言ってリファクタリング進めましょう。
では40時間労働を実践する為にそろそろ寝ます。
>>133のレス同様「変化を受け入れろ」なんて机上の言葉は普通受け入れられない。
自分だけでも実践して高パフォーマンス見せる事こそが全ての始まり。
そんで自分のやってる事をアピール。褒められた時なんかは入れ食いタイム。これでOK。
あと思い付きの仕様は計画ゲームによって管理出来るし、
必要な要求なら複雑でも（シンプルに）実現するのが開発者の使命です。
人のコード邪魔でシンプルデザイン無理？
共通クラス作るとか何とか言ってリファクタリング進めましょう。
では40時間労働を実践する為にそろそろ寝ます。
>>151
すまん、愚痴なんだが。
>必要な要求なら複雑でも（シンプルに）実現するのが開発者の使命です。
シンプルデザインに関しては自分の信条だし、シンプルデザイン
能力は社内では自分より上の人間はいない自信はあるんだが、
それでも実現できないことが多い。俺にシンプルにできないことは
だれもシンプルに実装できんっつーの。どうしてそれが実装できるか
っていうと、みんな根性で実装してる。で、実装すると図にのるし。
なんか腹が立ってきた(藁
すまん、愚痴なんだが。
>必要な要求なら複雑でも（シンプルに）実現するのが開発者の使命です。
シンプルデザインに関しては自分の信条だし、シンプルデザイン
能力は社内では自分より上の人間はいない自信はあるんだが、
それでも実現できないことが多い。俺にシンプルにできないことは
だれもシンプルに実装できんっつーの。どうしてそれが実装できるか
っていうと、みんな根性で実装してる。で、実装すると図にのるし。
なんか腹が立ってきた(藁
153 ：仕様書無しさん：04/09/13 01:58:43
自慢大会が始まりました。
実例見てないからなんとも判断しようがないってのがいつもの結論。
まぁ２ちゃんだから仕方ないけど
実例見てないからなんとも判断しようがないってのがいつもの結論。
まぁ２ちゃんだから仕方ないけど
XP導入できた人とできなかった人で多数決でもとるか。
ココ読んでたら、うんこしたくなった。
これからしてくる。
これからしてくる。
XPのスレじゃないのだが、流れみたいなので、乗ります。
>>148
すごい。
20人の仕事と言えば、私の感覚から言えば、最低でも1億円超の仕事でしょう。
それを失敗しないのなら、かなり出来る方なのですね。
そこで、質問があります。
XPは一度、本を読んだだけで、大方忘れているのですが、
ユーザが協力的でないと成功しない印象を受けました。
私はある企業の子会社に属していますが、仕事は外部から請負ばかりです。
余程、重要なシステムでなければ、あれほどユーザの方を巻き込むのは、
難しい話と思います。システム開発に関する打合せも自分の業務を
邪魔するものでしかないと思われているような非協力的な方もいます。
そのあたり、どうやって積極的に参加させたのか聞きたいです。
また、通常プロジェクト開始時にはコスト・期間・要件が決めなければなりませんが、
XPは、コスト、期間、リソースが決めて、あとはどれぐらいの要件を盛り込むかは
途中で決めるという印象を持っています。
どれほどの機能を盛り込むか分からないというシステムにユーザさんが
お金を出してくれるとはどうしても思えないのです。
その辺りは、どのように納得して貰ったのでしょうか？
また、どのような見積りを行ったかも聞きたいです。
システムは「小さく産んで大きく育てる」のが一番だと考えているのですが、
現実は厳しく、全システムを一発稼働させたいというユーザさんがほとんどです。
会社は国と同じように部署ごとに年間予算ってものがありますから、
申請して上役の方に了承して貰わないといけないし、今年予算が出たからといって、
来年出る保障は無いですからね。なかなか難しいです。
私が少数精鋭と言ったのは、気心が知れているという意味も含んでいます。
七人の侍を連れてきたからと言って、必ずしも農村は守れませんからね。
>>148
すごい。
20人の仕事と言えば、私の感覚から言えば、最低でも1億円超の仕事でしょう。
それを失敗しないのなら、かなり出来る方なのですね。
そこで、質問があります。
XPは一度、本を読んだだけで、大方忘れているのですが、
ユーザが協力的でないと成功しない印象を受けました。
私はある企業の子会社に属していますが、仕事は外部から請負ばかりです。
余程、重要なシステムでなければ、あれほどユーザの方を巻き込むのは、
難しい話と思います。システム開発に関する打合せも自分の業務を
邪魔するものでしかないと思われているような非協力的な方もいます。
そのあたり、どうやって積極的に参加させたのか聞きたいです。
また、通常プロジェクト開始時にはコスト・期間・要件が決めなければなりませんが、
XPは、コスト、期間、リソースが決めて、あとはどれぐらいの要件を盛り込むかは
途中で決めるという印象を持っています。
どれほどの機能を盛り込むか分からないというシステムにユーザさんが
お金を出してくれるとはどうしても思えないのです。
その辺りは、どのように納得して貰ったのでしょうか？
また、どのような見積りを行ったかも聞きたいです。
システムは「小さく産んで大きく育てる」のが一番だと考えているのですが、
現実は厳しく、全システムを一発稼働させたいというユーザさんがほとんどです。
会社は国と同じように部署ごとに年間予算ってものがありますから、
申請して上役の方に了承して貰わないといけないし、今年予算が出たからといって、
来年出る保障は無いですからね。なかなか難しいです。
私が少数精鋭と言ったのは、気心が知れているという意味も含んでいます。
七人の侍を連れてきたからと言って、必ずしも農村は守れませんからね。
>>152
シンプルデザインは、実はとてもアカデミックで奥が深い。
時には業務分析の方をリファクタリングした方が良い事もあるし。
言語、OO、設計パターン、分析パターン、構造化、もっと基本的なプログラム作法、
DB、ネットワーク、ハードウェア、とにかくあらゆる知識によって、もっと上を目指せる。
だからと言って焦る必要も実は無い。OOで複雑な問題領域隔離すればリスクが下がる。
そんで納期に収まる範囲でリファクタリングしつつ上を目指せばいいんだ。
さて、上を目指すには「何がシンプルか」を議論する場が必要。
「ペアプロ」「コードレビュー」「立ち話」、何でもいいから場を作れ。
お勧めは「押し売りペアプロ」。ウザがられる時もあるけどめげるな。
シンプルデザインは、実はとてもアカデミックで奥が深い。
時には業務分析の方をリファクタリングした方が良い事もあるし。
言語、OO、設計パターン、分析パターン、構造化、もっと基本的なプログラム作法、
DB、ネットワーク、ハードウェア、とにかくあらゆる知識によって、もっと上を目指せる。
だからと言って焦る必要も実は無い。OOで複雑な問題領域隔離すればリスクが下がる。
そんで納期に収まる範囲でリファクタリングしつつ上を目指せばいいんだ。
さて、上を目指すには「何がシンプルか」を議論する場が必要。
「ペアプロ」「コードレビュー」「立ち話」、何でもいいから場を作れ。
お勧めは「押し売りペアプロ」。ウザがられる時もあるけどめげるな。
>>156
オンサイトユーザは通常無理。でも常時の連絡手段、定期的な打ち合わせ、
「動いてる物」を触らせる習慣は作る事が出来る。来てくれないならノート駆使。
どうしても顧客が協力しない？考えさせるきっかけ（Doc？ツール？サンプル？）を与えろ。
それでも駄目なら、マジで説教しろ。協力しない道理は無い。
オンサイトユーザは通常無理。でも常時の連絡手段、定期的な打ち合わせ、
「動いてる物」を触らせる習慣は作る事が出来る。来てくれないならノート駆使。
どうしても顧客が協力しない？考えさせるきっかけ（Doc？ツール？サンプル？）を与えろ。
それでも駄目なら、マジで説教しろ。協力しない道理は無い。
コスト・期間・要件について。ぶっちゃけ仕事取った時点でほぼ決まってる。
でも「要件」って捉え方がとても広いし、思い付きのアイデアも入りやすい。
”サイトにアクセスする顧客データの集計システム”という要件があったとして、
すごく色々想像出来るよね？集計するのはログイン回数？購入回数？クリック回数？
集計単位は？期間は？項目は？分析機能は？帳票は？マーケティング部門への連携データは？
そうやって顧客巻き込んでアイディア広げて、それぞれ技術者視点で見積もっていけば、
当然総コストは払えないから真剣に優先順位とスケジュールを議論する事になる。
でも「要件」って捉え方がとても広いし、思い付きのアイデアも入りやすい。
”サイトにアクセスする顧客データの集計システム”という要件があったとして、
すごく色々想像出来るよね？集計するのはログイン回数？購入回数？クリック回数？
集計単位は？期間は？項目は？分析機能は？帳票は？マーケティング部門への連携データは？
そうやって顧客巻き込んでアイディア広げて、それぞれ技術者視点で見積もっていけば、
当然総コストは払えないから真剣に優先順位とスケジュールを議論する事になる。
＞全システムを一発稼働させたいというユーザさんがほとんど
これも当然の考え。ビジネスはタイミングが命だからね。（知ったかぶり
でも、本番に近いテストはいつでも出来るんだよ。
マスタスケジュールとは別に、顧客テストを節目としたスケジュールを立てること。
その際、求められる成果物は必ず抑えておく。それが作れる体制にする。
顧客の役職に対しては「ウォーターフォールで進んでます」との報告強要される場合もあるけど、
現場の理解さえ得られていれば問題は無い。
結局動いてる物触れば機嫌が直る。
これも当然の考え。ビジネスはタイミングが命だからね。（知ったかぶり
でも、本番に近いテストはいつでも出来るんだよ。
マスタスケジュールとは別に、顧客テストを節目としたスケジュールを立てること。
その際、求められる成果物は必ず抑えておく。それが作れる体制にする。
顧客の役職に対しては「ウォーターフォールで進んでます」との報告強要される場合もあるけど、
現場の理解さえ得られていれば問題は無い。
結局動いてる物触れば機嫌が直る。
ちと他のOOスレみたのだが、こっちの方が落ち着いてていいね。
で、OOやってる人に質問。
OOには部品化という考え方がありますよね。
流行始めた頃には「車を作るのにいちいちタイヤを開発しない」、
「プログラムもそうあるべきだ」と言われていました。
皆さんのところでは、ちゃんと部品化できてますか？
その部品は、他のシステムでも活用できてますか？
あと、継承を使うとスーパークラスの機能を省けるので、
プログラミングが楽になると言われました。
でも、継承されるクラスをちゃんと作っておかないと、単なるツギハギのプログラムになり、
ドンドンひどくなっちゃいませんか？
私がやってたときは、部品化などといいつつ、毎回部品を作り直してましたｗ
だから、完全抽象クラスばっかり作ってた気がしますデス
で、OOやってる人に質問。
OOには部品化という考え方がありますよね。
流行始めた頃には「車を作るのにいちいちタイヤを開発しない」、
「プログラムもそうあるべきだ」と言われていました。
皆さんのところでは、ちゃんと部品化できてますか？
その部品は、他のシステムでも活用できてますか？
あと、継承を使うとスーパークラスの機能を省けるので、
プログラミングが楽になると言われました。
でも、継承されるクラスをちゃんと作っておかないと、単なるツギハギのプログラムになり、
ドンドンひどくなっちゃいませんか？
私がやってたときは、部品化などといいつつ、毎回部品を作り直してましたｗ
だから、完全抽象クラスばっかり作ってた気がしますデス
>>162
回答では無いけど。そこが一番の耳の痛いところだと思うよ。
オブジェクト指向の本体の目的はソフトウェアの再利用（部品化）であるはずだからね。
部品化が容易になったのは確かだけど、部品化そのものは実現できていないところは多いと思うよ。
制度的/社会学的/組織構造的な、理由で。
まあ「勿論さ」という回答が返ってくることを個人的には望むのだけどね。
回答では無いけど。そこが一番の耳の痛いところだと思うよ。
オブジェクト指向の本体の目的はソフトウェアの再利用（部品化）であるはずだからね。
部品化が容易になったのは確かだけど、部品化そのものは実現できていないところは多いと思うよ。
制度的/社会学的/組織構造的な、理由で。
まあ「勿論さ」という回答が返ってくることを個人的には望むのだけどね。
えっと、Jakarta なやつとか。激しく再利用されてる部品なんだけど。
素晴らしいフレームワークいっぱいあるし。
素晴らしいフレームワークいっぱいあるし。
>>162
昔は使い回せる部品を開発するべき、という思想があったけど、今は変わりました。
プロジェクト間で使い回せるような部品は、各ベンダーやjakartaプロジェクト、
そしてJDK自身が提供してくれています。（そして充実し続けています。）
開発者に求められる事が、流動的な仕様に対して変更に強いシステムを作る事に変わりました。
それは「将来使えるかもしれない部品」を作る事から、
「要求を実現する最もシンプルな部品」を作る事に変わった事を意味します。
＃某スレの議論じゃないですが、個々人が全体を見渡す事は強力な助けになります。
仕様が変更された時、変更するコード量、変更箇所に依存するコード量は最低限ですか？
これが今の、OOADPの成功を表すバロメーターであり、目標です。
昔は使い回せる部品を開発するべき、という思想があったけど、今は変わりました。
プロジェクト間で使い回せるような部品は、各ベンダーやjakartaプロジェクト、
そしてJDK自身が提供してくれています。（そして充実し続けています。）
開発者に求められる事が、流動的な仕様に対して変更に強いシステムを作る事に変わりました。
それは「将来使えるかもしれない部品」を作る事から、
「要求を実現する最もシンプルな部品」を作る事に変わった事を意味します。
＃某スレの議論じゃないですが、個々人が全体を見渡す事は強力な助けになります。
仕様が変更された時、変更するコード量、変更箇所に依存するコード量は最低限ですか？
これが今の、OOADPの成功を表すバロメーターであり、目標です。
>>165
おいおい、ライブラリやミドルウェアを作る人たちは「開発者」じゃないような言い方だな。
おいおい、ライブラリやミドルウェアを作る人たちは「開発者」じゃないような言い方だな。
168 ：仕様書無しさん：04/09/17 08:01:27
業務系の部品は再利用っても限界があるからね。
会社独自の仕様が多いから。
ECOneのコンポーネントコンソーシアムとかも失敗してるし
会社独自の仕様が多いから。
ECOneのコンポーネントコンソーシアムとかも失敗してるし
170 ：仕様書無しさん：04/09/17 11:16:04
業務ドメインフレームワーク？
やはり、今は部品の再利用って流行では無いようですね。
部品といってもフレームワークとかミドルウェアは、それけでは動かないので、
私の考える部品とはニュアンスが違っています。
やはり、部品を組み立てる感じでアプリ（制御系でもいいけど）を
出来るという感じでないと・・・100%は無理ですけどね。
ソフトウェアのある分野の大家が
「一度しか使えないモノは部品とは呼ばないんだよなぁ」と冗談交じりに
話してたのを思い出したです。
余談ですが、
昔はフレームワークと言えば、ERP的な考え方で、業務アプリの大枠となる
モデルっていう意味だったような記憶があります。財務会計フレームワークとか。
3年ほど前に後輩から「フレームワークの勉強がしたい」と言われて何を
言っているのか全く分からずトンチンカンな答えをしたことがありますｗ
業務ドメインフレームワークってのがそれなのかなぁ。
部品といってもフレームワークとかミドルウェアは、それけでは動かないので、
私の考える部品とはニュアンスが違っています。
やはり、部品を組み立てる感じでアプリ（制御系でもいいけど）を
出来るという感じでないと・・・100%は無理ですけどね。
ソフトウェアのある分野の大家が
「一度しか使えないモノは部品とは呼ばないんだよなぁ」と冗談交じりに
話してたのを思い出したです。
余談ですが、
昔はフレームワークと言えば、ERP的な考え方で、業務アプリの大枠となる
モデルっていう意味だったような記憶があります。財務会計フレームワークとか。
3年ほど前に後輩から「フレームワークの勉強がしたい」と言われて何を
言っているのか全く分からずトンチンカンな答えをしたことがありますｗ
業務ドメインフレームワークってのがそれなのかなぁ。
> やはり、今は部品の再利用って流行では無いようですね。
おいおい何をもとにそういう結論に達したんだ。
匿名掲示板の数人の意見で納得したのか？
> 部品といってもフレームワークとかミドルウェアは、それけでは動かないので、
> 私の考える部品とはニュアンスが違っています。
> やはり、部品を組み立てる感じでアプリ（制御系でもいいけど）を
> 出来るという感じでないと・・・100%は無理ですけどね。
君の考えてる「部品」とはどういうニュアンスなんだ？
OOをちゃんと理解している組織では、クラス設計＝部品設計というのは常識として
やってるよ。
おいおい何をもとにそういう結論に達したんだ。
匿名掲示板の数人の意見で納得したのか？
> 部品といってもフレームワークとかミドルウェアは、それけでは動かないので、
> 私の考える部品とはニュアンスが違っています。
> やはり、部品を組み立てる感じでアプリ（制御系でもいいけど）を
> 出来るという感じでないと・・・100%は無理ですけどね。
君の考えてる「部品」とはどういうニュアンスなんだ？
OOをちゃんと理解している組織では、クラス設計＝部品設計というのは常識として
やってるよ。
よく考えてみたら、つい最近、strutsを使ったプロジェクトに携わっていました。
私は技術的な点については、ノータッチだったので忘れてましたｗ
あれって、Webアプリ(httpプロトコル）の弱点を補うために存在する気が
したのですが違いますか？
私は不勉強なので、フレームワークってそんなのしか思い浮かばない・・・
しかし、あれは苦労したなぁ。
一カ所、定義体が間違ってるだけで全然動かないんだものなぁ。
ちょっとした雑談でした。
私は技術的な点については、ノータッチだったので忘れてましたｗ
あれって、Webアプリ(httpプロトコル）の弱点を補うために存在する気が
したのですが違いますか？
私は不勉強なので、フレームワークってそんなのしか思い浮かばない・・・
しかし、あれは苦労したなぁ。
一カ所、定義体が間違ってるだけで全然動かないんだものなぁ。
ちょっとした雑談でした。
>>173
前にも書きましたが、私は毎回違う会社のシステムを開発しています。
例えば、Ａ社で使っていた社員というクラスが、
差分修正だけでＢ社でも使えるかということです。
さらにいえば、組織クラス（モデル？）を異なる企業で使えれば、
よいかなぁと思います。
突き詰めれば、貸借対照表などはどこの企業でも必要なので、
クラス（あるいはモデル）化すれば、どこでも使える気がします。
そんな感じです。
外資系メーカーがやってたサンフランシスコプロジェクトってまだあるんかなぁ。
前にも書きましたが、私は毎回違う会社のシステムを開発しています。
例えば、Ａ社で使っていた社員というクラスが、
差分修正だけでＢ社でも使えるかということです。
さらにいえば、組織クラス（モデル？）を異なる企業で使えれば、
よいかなぁと思います。
突き詰めれば、貸借対照表などはどこの企業でも必要なので、
クラス（あるいはモデル）化すれば、どこでも使える気がします。
そんな感じです。
外資系メーカーがやってたサンフランシスコプロジェクトってまだあるんかなぁ。
差分修正てのは普通部品とは言わないんでは？
# 取り方によりけりだが…
差分修正みたいなことはできる分にはどこでもやるだろうし…
# 取り方によりけりだが…
差分修正みたいなことはできる分にはどこでもやるだろうし…
業務要件をシステム化する際、「触ってはいけない」コードは大きな制約となります。
そしてユーザーの要求はプロジェクト毎に異なる為、
修正の必要が無い「部品」を見つける事は困難です。（JDKやJakartaは別ですよ。）
また、ユーザーに「部品」に合わせる事を強要した場合、そのシステムは満足されないでしょう。
結局のところ、ナレッジとして個人に蓄積された「部品」を、
プロジェクトにコピーした後、リファクタリングを行うのが良い選択です。
例外があるとすれば、一切のカスタマイズが無くとも、
ある領域の顧客にとってビジネス的な価値のある「部品」です。
こういうの「パッケージソフト」って言うんでしたね。そのまま売って下さい。
そしてユーザーの要求はプロジェクト毎に異なる為、
修正の必要が無い「部品」を見つける事は困難です。（JDKやJakartaは別ですよ。）
また、ユーザーに「部品」に合わせる事を強要した場合、そのシステムは満足されないでしょう。
結局のところ、ナレッジとして個人に蓄積された「部品」を、
プロジェクトにコピーした後、リファクタリングを行うのが良い選択です。
例外があるとすれば、一切のカスタマイズが無くとも、
ある領域の顧客にとってビジネス的な価値のある「部品」です。
こういうの「パッケージソフト」って言うんでしたね。そのまま売って下さい。
jakartaなんかにあるような、公開されているライブラリ、出来合いの物ってのは
そもそも作成する段階でソース修正しなくても使えるようにしなきゃいけないから
そのまま柔軟に使えるように作られてるんだよ。
分野的にほんとにいろんなプロジェクトでいじらなくて使える部品ならそうだが、
無理に使えるようにするよりも各プロジェクトにあわせて修正した方が現実的。
そもそも作成する段階でソース修正しなくても使えるようにしなきゃいけないから
そのまま柔軟に使えるように作られてるんだよ。
分野的にほんとにいろんなプロジェクトでいじらなくて使える部品ならそうだが、
無理に使えるようにするよりも各プロジェクトにあわせて修正した方が現実的。
で、なぜか「覚えさせたい」スレの次スレにされてる；；
あともう一つオブジェクト指向をやってたときに悩んだのが、
データベースとの繋ぎのところ。
オブジェクト指向DB使うなら良いのですが、
業務系の場合、RDBを使う場合多いでしょ。
RDBからクラスにデータを格納させるじゃないですか。
そこの部分がオブジェクト指向にならずに悩んでました。
結局、クラスにデータをセットしてから「さて、オブジェクト指向するか」状態に
なっちゃってたんですよ。そこが何となく気持ちが悪かったです。
そもそもSQLがオブジェクト指向じゃないから仕方ないのですが・・・。
ファクトリーパターン使えば綺麗に書けるのかな。
JDBCのクラスを継承しちゃったりするのかな。
みなさん、どうしてます？
あともう一つオブジェクト指向をやってたときに悩んだのが、
データベースとの繋ぎのところ。
オブジェクト指向DB使うなら良いのですが、
業務系の場合、RDBを使う場合多いでしょ。
RDBからクラスにデータを格納させるじゃないですか。
そこの部分がオブジェクト指向にならずに悩んでました。
結局、クラスにデータをセットしてから「さて、オブジェクト指向するか」状態に
なっちゃってたんですよ。そこが何となく気持ちが悪かったです。
そもそもSQLがオブジェクト指向じゃないから仕方ないのですが・・・。
ファクトリーパターン使えば綺麗に書けるのかな。
JDBCのクラスを継承しちゃったりするのかな。
みなさん、どうしてます？
>>16
俗にいうオブジェクト指向とRDBのインピーダンスミスマッチ
っつーやつですか。
DBとかよー知らんけど、最近ならORMとかつかうんじゃないの。
http://www.atmarkit.co.jp/fjava/rensai3/ormap01/ormap01.html#11
思うんだけど16さんって疑問投げるときにある程度返ってくる
答えがわかってて聞いているように感じる。質問が一般的な
問題が多いような気がする。
俗にいうオブジェクト指向とRDBのインピーダンスミスマッチ
っつーやつですか。
DBとかよー知らんけど、最近ならORMとかつかうんじゃないの。
http://www.atmarkit.co.jp/fjava/rensai3/ormap01/ormap01.html#11
思うんだけど16さんって疑問投げるときにある程度返ってくる
答えがわかってて聞いているように感じる。質問が一般的な
問題が多いような気がする。
インピーダンスマッチという言葉があるんですね。
でも、R/Oマッピングというヤツでも
RDBの良さを殺しちゃってる感じがしますね。
やっぱり、SQLは出来れば書きたくない、
書いてもJOINは御法度ということがあるのでしょうか。
>>182さん
別に答えが分かって質問している訳ではないです。
自分がOOしてたときは、周りにやっている人がいなくて、
インターネットも普及していなかったので、
誰も聞く相手がいなかったのです。
ここ数年は、OOを追っかけなくなり、雑誌も読まなくなってしまったので、
最新の動向に関しては疎いだけです。
そんなわけで、昔疑問に思っていたことを、ここで質問させて貰っています^^;
会社の若いのに聞いても、納得できる答えが聞けないので・・・
ちなみに、
セッターゲッターという言葉も、去年始めて聞いて、何を言っているのか
理解できませんでした。
OOやってたときに、「メンバ変数に対するI/Oって全部メソッド作るのかなぁ、
でも、そんな面倒なことするかなぁ。他の人はどうしてるんだろ」と悩んでいました。
その頃はそんな言葉、どこにも載ってませんでしたから。
Delphiのpropertyは便利だったなぁ。と思い出話。
でも、R/Oマッピングというヤツでも
RDBの良さを殺しちゃってる感じがしますね。
やっぱり、SQLは出来れば書きたくない、
書いてもJOINは御法度ということがあるのでしょうか。
>>182さん
別に答えが分かって質問している訳ではないです。
自分がOOしてたときは、周りにやっている人がいなくて、
インターネットも普及していなかったので、
誰も聞く相手がいなかったのです。
ここ数年は、OOを追っかけなくなり、雑誌も読まなくなってしまったので、
最新の動向に関しては疎いだけです。
そんなわけで、昔疑問に思っていたことを、ここで質問させて貰っています^^;
会社の若いのに聞いても、納得できる答えが聞けないので・・・
ちなみに、
セッターゲッターという言葉も、去年始めて聞いて、何を言っているのか
理解できませんでした。
OOやってたときに、「メンバ変数に対するI/Oって全部メソッド作るのかなぁ、
でも、そんな面倒なことするかなぁ。他の人はどうしてるんだろ」と悩んでいました。
その頃はそんな言葉、どこにも載ってませんでしたから。
Delphiのpropertyは便利だったなぁ。と思い出話。
184 ：仕様書無しさん：04/09/19 09:10:47
> 会社の若いのに聞いても、納得できる答えが聞けないので・・・
それしか知らないやつに聞いても他の方法との比較はできないからな。
俺はSQL知ってるならO/Rマッピング組み込むなんて無駄だと思ってるよ。
ってか、RDB使うのにSQL知らないなんてのが間違ってるんだけどな。
ただ、実際の現場では他のやつのやりかたに合わせるけどな。
論争の時間の方がそれこそ無駄だから。
納得できないことでもうまくやるのがプロの仕事だろう
> Delphiのpropertyは便利だったなぁ。と思い出話。
Delphiのプロパティは仕組みがスマートだよね。
はじめてJavaやったとき、なんてダサいことさせるんだと思ったよ
それしか知らないやつに聞いても他の方法との比較はできないからな。
俺はSQL知ってるならO/Rマッピング組み込むなんて無駄だと思ってるよ。
ってか、RDB使うのにSQL知らないなんてのが間違ってるんだけどな。
ただ、実際の現場では他のやつのやりかたに合わせるけどな。
論争の時間の方がそれこそ無駄だから。
納得できないことでもうまくやるのがプロの仕事だろう
> Delphiのpropertyは便利だったなぁ。と思い出話。
Delphiのプロパティは仕組みがスマートだよね。
はじめてJavaやったとき、なんてダサいことさせるんだと思ったよ
>「メンバ変数に対するI/Oって全部メソッド作るのかなぁ、
>でも、そんな面倒なことするかなぁ。他の人はどうしてるんだろ」
僕は、そんな面倒なことをしてました。１つのI／O値に対して、
setメソッドとgetメソッド両方ね。
DelphiのPropertyって知らないけど、VBのプロパティとどう違うの？
>でも、そんな面倒なことするかなぁ。他の人はどうしてるんだろ」
僕は、そんな面倒なことをしてました。１つのI／O値に対して、
setメソッドとgetメソッド両方ね。
DelphiのPropertyって知らないけど、VBのプロパティとどう違うの？
186 ：仕様書無しさん：04/09/19 12:26:54
テンプレートってオブジェクト指向の一種？
188 ：仕様書無しさん：04/09/19 12:28:45
>>178
継承はクラス間の関係を密にするため
そんなやり方はお勧めできない。
継承 + 集約 + 委譲の組み合わせを使え。
そのためにはGoFデザインパターンなどを勉強しろ。
とくに、Bridgeパターンのところをよく嫁。
クラス間の関係を密にしすぎないように上手に拡張する方法が載っている。
継承はクラス間の関係を密にするため
そんなやり方はお勧めできない。
継承 + 集約 + 委譲の組み合わせを使え。
そのためにはGoFデザインパターンなどを勉強しろ。
とくに、Bridgeパターンのところをよく嫁。
クラス間の関係を密にしすぎないように上手に拡張する方法が載っている。
>>187
日本語をしゃべれ。
なんのテンプレートだ。
ＧｏＦデザインパターンの異種テンプレートメソッドパターン
のこと言っているのか
Ｇｅｎｅｒｉｃｓのことをのこと言っているのか
それとも何のことか？
日本語をしゃべれ。
なんのテンプレートだ。
ＧｏＦデザインパターンの異種テンプレートメソッドパターン
のこと言っているのか
Ｇｅｎｅｒｉｃｓのことをのこと言っているのか
それとも何のことか？
C++の
191 ：仕様書無しさん：04/09/19 12:32:08
>>181
いまならカイエンを使う。
プロダクトレビュー
話題のO/Rマッピングツール「Cayenne」を使う
http://www.atmarkit.co.jp/fjava/products/cayenne/cayenne_1.html
いまならカイエンを使う。
プロダクトレビュー
話題のO/Rマッピングツール「Cayenne」を使う
http://www.atmarkit.co.jp/fjava/products/cayenne/cayenne_1.html
192 ：仕様書無しさん：04/09/19 12:34:16
>>184
> > 会社の若いのに聞いても、納得できる答えが聞けないので・・・
>
> それしか知らないやつに聞いても他の方法との比較はできないからな。
> 俺はSQL知ってるならO/Rマッピング組み込むなんて無駄だと思ってるよ。
おまえのソースコード拡張性が低くてグロそうだな。
テーブルにカラムを追加するために面倒な修正を強いられて
> > 会社の若いのに聞いても、納得できる答えが聞けないので・・・
>
> それしか知らないやつに聞いても他の方法との比較はできないからな。
> 俺はSQL知ってるならO/Rマッピング組み込むなんて無駄だと思ってるよ。
おまえのソースコード拡張性が低くてグロそうだな。
テーブルにカラムを追加するために面倒な修正を強いられて
>>192
もうカイエン使った開発を経験しているのでしょうか？
あれって、内部的には、結局SQLを発行しているわけでしょう・・・。
動的SQLとたいして変わらない気が・・・。
>テーブルにカラムを追加するために面倒な修正を強いられて
SQLだって面倒な修正の必要は無いと思うが・・・。
もうカイエン使った開発を経験しているのでしょうか？
あれって、内部的には、結局SQLを発行しているわけでしょう・・・。
動的SQLとたいして変わらない気が・・・。
>テーブルにカラムを追加するために面倒な修正を強いられて
SQLだって面倒な修正の必要は無いと思うが・・・。
194 ：仕様書無しさん：04/09/19 13:28:55
実際にDBプログラミング経験も無いバカ=>>193が
何をほざいているのか。
カラム追加・属性変更すればゲッタセッタの変更がどれだけ面倒なことかもわかってないようだな。
こいつの発言を見ただけででろくにJDBCプログラミング経験すらないことがすぐにわかる。
SQLベタ書きでやってみてinsert,delete,updateの使い回しが面倒だと思ったからこそ
O-Rマッピングツールの有り難みってもんがわかるんだろうが。
何をほざいているのか。
カラム追加・属性変更すればゲッタセッタの変更がどれだけ面倒なことかもわかってないようだな。
こいつの発言を見ただけででろくにJDBCプログラミング経験すらないことがすぐにわかる。
SQLベタ書きでやってみてinsert,delete,updateの使い回しが面倒だと思ったからこそ
O-Rマッピングツールの有り難みってもんがわかるんだろうが。
195 ：仕様書無しさん：04/09/19 13:34:13
>>193
このスレに逝ってこい。
お前みたいな中身も本質も良く分かっていない
物わかりが悪いヴァカは擦り潰されるぞ
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
http://pc5.2ch.net/test/read.cgi/tech/1090653286/
このスレに逝ってこい。
お前みたいな中身も本質も良く分かっていない
物わかりが悪いヴァカは擦り潰されるぞ
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
http://pc5.2ch.net/test/read.cgi/tech/1090653286/
>>188
＞クラス間の関係を密にしすぎないように上手に拡張する方法が載っている。
そういうことじゃなくて、例えうまく出来てもそのままソースレベルで書く（or修正する）のが
早い場合が多いってだけの話。現実にはね。
# 継承ってのは話の流れでたまたま出てきただけで本質にはそれほど関係なし。
＞クラス間の関係を密にしすぎないように上手に拡張する方法が載っている。
そういうことじゃなくて、例えうまく出来てもそのままソースレベルで書く（or修正する）のが
早い場合が多いってだけの話。現実にはね。
# 継承ってのは話の流れでたまたま出てきただけで本質にはそれほど関係なし。
関係が疎になる≒差分が大きくなる
場合が多い。
場合が多い。
198 ：仕様書無しさん：04/09/19 15:03:56
>>187
ぜんぜんちゃう
ぜんぜんちゃう
メソッドの再利用とはいえない？
パターンを受け継ぐという考え方もありかと思うんですがどうでしょうか
再利用してたらオブジェクト指向ですかそうですか
オブジェクト指向に厳密な定義てあるの？
コンポーネント指向のちっこい版でしょ
コンポーネント指向のちっこい版でしょ
「属性」と「動作」をもつ「オブジェクト」どうしの相互作用
確かにその通りでした
でも何かモヤモヤしてるっていうか
オブジェクト指向だけでは片手落ちのような気がしてしまう
テンプレートってオーバーライドやオーバーロードの目的とする所と
そんなに違いがあるの？
でも何かモヤモヤしてるっていうか
オブジェクト指向だけでは片手落ちのような気がしてしまう
テンプレートってオーバーライドやオーバーロードの目的とする所と
そんなに違いがあるの？
だから、目的が一緒だからって別にそうはならんでしょ？ってだけの話。
ああ、俺、別にオブジェクトの細かい定義とかどうでもいいし、
オブジェクト指向にこだわってるわけでもなんでもなくて、
単に上のことが言いたかっただけで、まあ正直言うとどうでもいい。
ところでテンプレートとオーバーライドの目的はかみ合わんと思うが…
まあ広い見方をすれば別だが…
ああ、俺、別にオブジェクトの細かい定義とかどうでもいいし、
オブジェクト指向にこだわってるわけでもなんでもなくて、
単に上のことが言いたかっただけで、まあ正直言うとどうでもいい。
ところでテンプレートとオーバーライドの目的はかみ合わんと思うが…
まあ広い見方をすれば別だが…
メソッドを抽象化したものがテンプレートではないかなあと
オブジェクト指向の一環としてオーバーライドなどがあるわけで
＞メソッドを抽象化したものがテンプレート
ならばオブジェクト指向の仲間に入れてやってもいいんじゃないかと思うんですが
＞メソッドを抽象化したものがテンプレート
ならばオブジェクト指向の仲間に入れてやってもいいんじゃないかと思うんですが
>オブジェクト指向の一環としてオーバーライドなどがある
という前提がおかしいから結論がおかしいんだわ。
という前提がおかしいから結論がおかしいんだわ。
馬鹿な僕に知恵をつけてください(´･ω･`)
>>194
PRO-Cの場合を想定していたんだけど、
JDBCでもカラムの追加なんてそんなに面倒なんですかねえ？
セッター・ゲッターなんて機械的に作るものと思っていましたけど・・・。
>>SQLベタ書きでやってみてinsert,delete,updateの使い回しが面倒
これも正直、全然面倒と思わないけど。
（私がこれまで担当した5人月程度のシステムで想定しちゃってますけど。）
PRO-Cの場合を想定していたんだけど、
JDBCでもカラムの追加なんてそんなに面倒なんですかねえ？
セッター・ゲッターなんて機械的に作るものと思っていましたけど・・・。
>>SQLベタ書きでやってみてinsert,delete,updateの使い回しが面倒
これも正直、全然面倒と思わないけど。
（私がこれまで担当した5人月程度のシステムで想定しちゃってますけど。）
継承ってオブジェクト指向のひとつの象徴と思うんだけど
（異論を唱える人もいると思うがﾏﾝﾄﾞｸｻｸなるのでｽﾙｰしる）
オーバーライドは
ただ継承するだけでは解決できない開発上の現実的な都合で
本来そっくりそのまま継承されるはずのものを
例外的に上書きしてしまう、ある意味オブジェクト指向と
反する部分なんやね。
テンプレートは、ひとつのメソッドで
突っ込まれるオブジェクトがなんであれ
アハンウフンと解決できるという
どこかブラックボックス的なオブジェクト指向のニオイがするけど
オブジェクトという単位がメッセージを受け取って
自発的に解決しようというオブジェクト指向の根本的な思想と
直接的には関係ないんだな。
これC言語であっても基本型を対象に導入すれば成立するわけ。
オーバーロードは実質Cにも導入されているわけだし。
現実的にはOOPでこそ見かけるものであるし
仲間と言えなくはないが、本質的には無関係と思いますわ。
話長くて誰も読んじゃいない罠。
（異論を唱える人もいると思うがﾏﾝﾄﾞｸｻｸなるのでｽﾙｰしる）
オーバーライドは
ただ継承するだけでは解決できない開発上の現実的な都合で
本来そっくりそのまま継承されるはずのものを
例外的に上書きしてしまう、ある意味オブジェクト指向と
反する部分なんやね。
テンプレートは、ひとつのメソッドで
突っ込まれるオブジェクトがなんであれ
アハンウフンと解決できるという
どこかブラックボックス的なオブジェクト指向のニオイがするけど
オブジェクトという単位がメッセージを受け取って
自発的に解決しようというオブジェクト指向の根本的な思想と
直接的には関係ないんだな。
これC言語であっても基本型を対象に導入すれば成立するわけ。
オーバーロードは実質Cにも導入されているわけだし。
現実的にはOOPでこそ見かけるものであるし
仲間と言えなくはないが、本質的には無関係と思いますわ。
話長くて誰も読んじゃいない罠。
オブジェクト指向はオブジェクト指向であって万能ではないんでつね
オブジェクト自体も変更のないくらい小粒なほうがいいんだろうか
オブジェクト自体も変更のないくらい小粒なほうがいいんだろうか
213 ：仕様書無しさん：04/09/19 21:40:23
たくさん経験をつんでいく中で、適切な粒度ってものを見つけていくんだなぁ
まさに職人芸！
まさに職人芸！
普通は小粒であればあるほど自立してくれると思うので
砂どうしならいろんな形のオブジェが作れる柔軟さはあるけど
砂をピンセットでつまんで作業するのはえらく骨が折れるんだわ。
逆にでっかい岩だと組み合わせて作れるオブジェは限定されてしまう。
何事もケースバイケースで程よいのがよか。
砂どうしならいろんな形のオブジェが作れる柔軟さはあるけど
砂をピンセットでつまんで作業するのはえらく骨が折れるんだわ。
逆にでっかい岩だと組み合わせて作れるオブジェは限定されてしまう。
何事もケースバイケースで程よいのがよか。
>たくさん経験をつんでいく中で、適切な粒度ってものを見つけていくんだなぁ
幻想に近い気が最近している、関数型言語のように結論めがけて突進できるようなのものが流行んないかな・・・
幻想に近い気が最近している、関数型言語のように結論めがけて突進できるようなのものが流行んないかな・・・
オブジェクトの組み合わせ方には思想みたいなものは無いんですか？
突進していって行き詰るから
パラダイムシフトが発生したわけなんだが。
類似のスレでも書いたけど
OOでも手続き型でも
エントリポイントに類するものがあって処理が流れていく点で
まったく同じだと思うゾ。
パラダイムシフトが発生したわけなんだが。
類似のスレでも書いたけど
OOでも手続き型でも
エントリポイントに類するものがあって処理が流れていく点で
まったく同じだと思うゾ。
>>215
>幻想に近い気が最近している、関数型言語のように結論めがけて突進できるようなのものが流行んないかな・・・
関数型って「結論めがけて突進」せずに「一見回りくどい」から
流行らないんだと思うが・・・
>>217
>OOでも手続き型でも
>エントリポイントに類するものがあって処理が流れていく点で
>まったく同じだと思うゾ。
ていうか、世間では一般にそういうのを「手続き型」と
呼んでいるのだが・・・
>幻想に近い気が最近している、関数型言語のように結論めがけて突進できるようなのものが流行んないかな・・・
関数型って「結論めがけて突進」せずに「一見回りくどい」から
流行らないんだと思うが・・・
>>217
>OOでも手続き型でも
>エントリポイントに類するものがあって処理が流れていく点で
>まったく同じだと思うゾ。
ていうか、世間では一般にそういうのを「手続き型」と
呼んでいるのだが・・・
>>219
オブジェクト指向を補完するパラダイムとして
C++では関数型プログラミングが、JavaやC#では
アスペクト指向がちょっとづつ浸透してきている。
STLとかBoostとか関数型プログラミングのエッセンス
がたくさん入っているよ。たとえば高階関数やラムダ式とか。
正式なBoostにはまだ入っていないけど、FC++という
C++で関数型プログラミングをするためのライブラリが
フォーマルレビュー中だったと思う。
http://page.freett.com/shelarcy/programm/translate/fcpp-one-huge-file.html
オブジェクト指向を補完するパラダイムとして
C++では関数型プログラミングが、JavaやC#では
アスペクト指向がちょっとづつ浸透してきている。
STLとかBoostとか関数型プログラミングのエッセンス
がたくさん入っているよ。たとえば高階関数やラムダ式とか。
正式なBoostにはまだ入っていないけど、FC++という
C++で関数型プログラミングをするためのライブラリが
フォーマルレビュー中だったと思う。
http://page.freett.com/shelarcy/programm/translate/fcpp-one-huge-file.html
>>221
オブジェクトの動作を手続きで表すのは仕方ないんじゃないですかね
オブジェクトの動作を手続きで表すのは仕方ないんじゃないですかね
>>221
抽象度が高すぎて直感と一致しなくなってしまうというのなら分るけれど、
「回りくどい」というのにはちょとどうだろう？
UNIXコマンドが良く似た状況になってますね cat でディスプレイに表示とか。
コマンドの意味が原型をとどめいてないです。
抽象度が高すぎて直感と一致しなくなってしまうというのなら分るけれど、
「回りくどい」というのにはちょとどうだろう？
UNIXコマンドが良く似た状況になってますね cat でディスプレイに表示とか。
コマンドの意味が原型をとどめいてないです。
>>221
オブジェクト指向を手続き型と一般的に言うのか？わからんなぁ
オブジェクト指向を手続き型と一般的に言うのか？わからんなぁ
>>226
221じゃないですが、
そういう先生も居る事はいるけれど、オブジェクト指向を手続き型と考えないのはどうも感触的に何か違うと思うよ。
あらゆる場所に手続きを用意していますから、あえていうなら超手続き型って呼びたいですね。
221じゃないですが、
そういう先生も居る事はいるけれど、オブジェクト指向を手続き型と考えないのはどうも感触的に何か違うと思うよ。
あらゆる場所に手続きを用意していますから、あえていうなら超手続き型って呼びたいですね。
228 ：仕様書無しさん：04/09/19 23:10:56
なんか関数手続き型言語を知らずに育った世代がいるようだな。
ものごとが複雑になりすぎ関数じゃこんがらかるから、もう少し
プログラムの単位を概念的に捕らえようとしているのがオブジェクト指向
だと漏れは理解するわけだ。ちょっと油断すると単なる関数になったり、
どっかのおやじが共通クラスと叫んでみたりすることになるんだな。
ものごとが複雑になりすぎ関数じゃこんがらかるから、もう少し
プログラムの単位を概念的に捕らえようとしているのがオブジェクト指向
だと漏れは理解するわけだ。ちょっと油断すると単なる関数になったり、
どっかのおやじが共通クラスと叫んでみたりすることになるんだな。
229 ：仕様書無しさん：04/09/19 23:18:59
>>225
コマンドの意味が原形をとどめていないというのには同意だが、
「catでディスプレイに表示」という記述は痛いぞ。
普通のUNIX頭で考えると、「標準出力に出す」だろ？
まさかcatだけでドキュメントを読んでんじゃねぇだろうな。
コマンドの意味が原形をとどめていないというのには同意だが、
「catでディスプレイに表示」という記述は痛いぞ。
普通のUNIX頭で考えると、「標準出力に出す」だろ？
まさかcatだけでドキュメントを読んでんじゃねぇだろうな。
>>228
その文章自体は失敗気味の釣りか天然だとは思うが
>プログラムの単位を概念的に捕らえようとしているのがオブジェクト指向
>だと漏れは理解するわけだ
というような認識は間違ってるでしょ。
オブジェクト指向は
概念うんぬんと表現されるような
あいまいなパラダイムではない。
正直、君はオブジェクト指向で開発していないだろう。
その文章自体は失敗気味の釣りか天然だとは思うが
>プログラムの単位を概念的に捕らえようとしているのがオブジェクト指向
>だと漏れは理解するわけだ
というような認識は間違ってるでしょ。
オブジェクト指向は
概念うんぬんと表現されるような
あいまいなパラダイムではない。
正直、君はオブジェクト指向で開発していないだろう。
なんか今日は為になったよ
おいらも偽になったよ
>関数手続き型言語
それはC見たいな言語の事であって、関数型でもなんでもないと思われ
それはC見たいな言語の事であって、関数型でもなんでもないと思われ
234 ：仕様書無しさん：04/09/20 02:20:04
オブジェクト指向なんぞ、まともなプログラマならオブジェクト指向言語を
使うまでもなく、それに近いプログラミングをしているだろう。
アスペクト指向だって、なーーにをいまさらと言う感じだね。
と、某Javaフレームワーク開発会社のコンサルタントとけんかしたのは漏れだが。
どう考えても、フレームワークを使うとその昔の手続き型っぽいんだよね。
で、そいつら、半日いるだけで、８０万だよ。ぺっ、
使うまでもなく、それに近いプログラミングをしているだろう。
アスペクト指向だって、なーーにをいまさらと言う感じだね。
と、某Javaフレームワーク開発会社のコンサルタントとけんかしたのは漏れだが。
どう考えても、フレームワークを使うとその昔の手続き型っぽいんだよね。
で、そいつら、半日いるだけで、８０万だよ。ぺっ、
結局、オブジェクト指向やそれに付随する周辺知識が
土台として身に付いてなければコンサルやとっても意味がない
ってところでしょうか。何言っているか理解できなければ意味がない。
ということで半日で80万円ドブに捨ててもったいなかったな。
土台として身に付いてなければコンサルやとっても意味がない
ってところでしょうか。何言っているか理解できなければ意味がない。
ということで半日で80万円ドブに捨ててもったいなかったな。
それは独立性云々の話でオブジェクト指向とはまた別の話では
238 ：仕様書無しさん：04/09/20 12:08:09
>>197
> 関係が疎になる≒差分が大きくなる
> 場合が多い。
こんなにハードディスクの大容量化した時代では
大した問題じゃないが。
それでもどうしてもきになるというなら、アスペクト指向を使うこった。
> 関係が疎になる≒差分が大きくなる
> 場合が多い。
こんなにハードディスクの大容量化した時代では
大した問題じゃないが。
それでもどうしてもきになるというなら、アスペクト指向を使うこった。
239 ：仕様書無しさん：04/09/20 12:13:20
>>196
> >>188
> ＞クラス間の関係を密にしすぎないように上手に拡張する方法が載っている。
> そういうことじゃなくて、例えうまく出来てもそのままソースレベルで書く（or修正する）のが
> 早い場合が多いってだけの話。現実にはね。
> # 継承ってのは話の流れでたまたま出てきただけで本質にはそれほど関係なし。
その修正が後ほど他に大きな変更を与えるものでなければ
直接修正しても構わない。だが、メソッドシグネチャを変更したという場合は
まずい。リファクタリングだけでは耐えられないこともある。
そういうときこど、
せっかくオブジェクト指向があるならできれば、
修正せずに追加するだけで済むように設計した方が楽であることか確か。
ポリモーフィズムをうまく使って。例えばあるクラスX(またはインターフェースX)を継承するだけ済む形にすると。
新たな追加があったときは再びクラスXを別のクラスで継承するという形にする。
> >>188
> ＞クラス間の関係を密にしすぎないように上手に拡張する方法が載っている。
> そういうことじゃなくて、例えうまく出来てもそのままソースレベルで書く（or修正する）のが
> 早い場合が多いってだけの話。現実にはね。
> # 継承ってのは話の流れでたまたま出てきただけで本質にはそれほど関係なし。
その修正が後ほど他に大きな変更を与えるものでなければ
直接修正しても構わない。だが、メソッドシグネチャを変更したという場合は
まずい。リファクタリングだけでは耐えられないこともある。
そういうときこど、
せっかくオブジェクト指向があるならできれば、
修正せずに追加するだけで済むように設計した方が楽であることか確か。
ポリモーフィズムをうまく使って。例えばあるクラスX(またはインターフェースX)を継承するだけ済む形にすると。
新たな追加があったときは再びクラスXを別のクラスで継承するという形にする。
240 ：仕様書無しさん：04/09/20 12:15:17
>>202
> オブジェクト指向に厳密な定義てあるの？
> コンポーネント指向のちっこい版でしょ
>
逆だろコンポーネント指向がオブジェクト指向の機能を削ぎ落とした
機能限定版オブジェクト指向だろ。
何せコンポーネント指向はオブジェクト指向の機能のひとつ、
『コンポジション集約』の塊だからな。
> オブジェクト指向に厳密な定義てあるの？
> コンポーネント指向のちっこい版でしょ
>
逆だろコンポーネント指向がオブジェクト指向の機能を削ぎ落とした
機能限定版オブジェクト指向だろ。
何せコンポーネント指向はオブジェクト指向の機能のひとつ、
『コンポジション集約』の塊だからな。
>>204
> 確かにその通りでした
> でも何かモヤモヤしてるっていうか
> オブジェクト指向だけでは片手落ちのような気がしてしまう
> テンプレートってオーバーライドやオーバーロードの目的とする所と
> そんなに違いがあるの？
ガタガタ言う前に実際に使ってみろと。
使いもしないでテンプレートやらオーバーライドやらとぬかさないように。
とりあえずJava Genericsについて調べてこい。
Collection系でGenerics(テンプレート)の有り難みがわかる。
> 確かにその通りでした
> でも何かモヤモヤしてるっていうか
> オブジェクト指向だけでは片手落ちのような気がしてしまう
> テンプレートってオーバーライドやオーバーロードの目的とする所と
> そんなに違いがあるの？
ガタガタ言う前に実際に使ってみろと。
使いもしないでテンプレートやらオーバーライドやらとぬかさないように。
とりあえずJava Genericsについて調べてこい。
Collection系でGenerics(テンプレート)の有り難みがわかる。
243 ：仕様書無しさん：04/09/20 12:28:04
>>210
> >>194
> PRO-Cの場合を想定していたんだけど、
> JDBCでもカラムの追加なんてそんなに面倒なんですかねえ？
> セッター・ゲッターなんて機械的に作るものと思っていましたけど・・・。
カラムを追加するためにセッタゲッタメソッドを修正し、それらのメソッドを呼び出している
クラスの方もいちいち修正するという手間を掛けているのか藻前は。
> >>SQLベタ書きでやってみてinsert,delete,updateの使い回しが面倒
> これも正直、全然面倒と思わないけど。
> （私がこれまで担当した5人月程度のシステムで想定しちゃってますけど。）
まさかとは思うが、セッションに値を保持せずにinsertするたびに毎回DBにログイン
するというコードを書いているんじゃなかろうな。
はっきりいって一番面倒なのはselectとinsert, updateを組み合わせた複雑な
複問い合わせを複数実現したいときだ。
お前はテーブルを一つ追加するたびにわざわざ同じコードを毎回書き続けるのか？
やるだけばかばかしい。カラムの定義も数もそれぞれ異なる
テーブルを10追加してくれと言われて同じようなコードを10も書くのか？
お前の作っているシステムはテーブルの数もクエリーの数も大したことがないからそういうことが
言えるだけだ。
ちょっとしたinsert, select処理を一つ書く程度だけなO-Rマッピングツールを使うまでもない。
だが複雑で様々なinsert, select処理を追加したい場合はどうする？
カラムを一つ追加しただけで数十にも及ぶinsert, selectを実装したメソッドを修正しないと
いけなくなる。
> >>194
> PRO-Cの場合を想定していたんだけど、
> JDBCでもカラムの追加なんてそんなに面倒なんですかねえ？
> セッター・ゲッターなんて機械的に作るものと思っていましたけど・・・。
カラムを追加するためにセッタゲッタメソッドを修正し、それらのメソッドを呼び出している
クラスの方もいちいち修正するという手間を掛けているのか藻前は。
> >>SQLベタ書きでやってみてinsert,delete,updateの使い回しが面倒
> これも正直、全然面倒と思わないけど。
> （私がこれまで担当した5人月程度のシステムで想定しちゃってますけど。）
まさかとは思うが、セッションに値を保持せずにinsertするたびに毎回DBにログイン
するというコードを書いているんじゃなかろうな。
はっきりいって一番面倒なのはselectとinsert, updateを組み合わせた複雑な
複問い合わせを複数実現したいときだ。
お前はテーブルを一つ追加するたびにわざわざ同じコードを毎回書き続けるのか？
やるだけばかばかしい。カラムの定義も数もそれぞれ異なる
テーブルを10追加してくれと言われて同じようなコードを10も書くのか？
お前の作っているシステムはテーブルの数もクエリーの数も大したことがないからそういうことが
言えるだけだ。
ちょっとしたinsert, select処理を一つ書く程度だけなO-Rマッピングツールを使うまでもない。
だが複雑で様々なinsert, select処理を追加したい場合はどうする？
カラムを一つ追加しただけで数十にも及ぶinsert, selectを実装したメソッドを修正しないと
いけなくなる。
>>211
> 継承ってオブジェクト指向のひとつの象徴と思うんだけど
> （異論を唱える人もいると思うがﾏﾝﾄﾞｸｻｸなるのでｽﾙｰしる）
> オーバーライドは
> ただ継承するだけでは解決できない開発上の現実的な都合で
> 本来そっくりそのまま継承されるはずのものを
> 例外的に上書きしてしまう、ある意味オブジェクト指向と
> 反する部分なんやね。
アフォか、お前はオブジェクト指向のことを良く分かっていなさすぎだ。
例えばJavaなら、super.メソッド名()を実行すれば、上書きしなくてく済むようにできるわけだが。
テンプレートの事もCのことも良く分かってないようだし、
お前のだらだら書いた戯言もスルー。
> 継承ってオブジェクト指向のひとつの象徴と思うんだけど
> （異論を唱える人もいると思うがﾏﾝﾄﾞｸｻｸなるのでｽﾙｰしる）
> オーバーライドは
> ただ継承するだけでは解決できない開発上の現実的な都合で
> 本来そっくりそのまま継承されるはずのものを
> 例外的に上書きしてしまう、ある意味オブジェクト指向と
> 反する部分なんやね。
アフォか、お前はオブジェクト指向のことを良く分かっていなさすぎだ。
例えばJavaなら、super.メソッド名()を実行すれば、上書きしなくてく済むようにできるわけだが。
テンプレートの事もCのことも良く分かってないようだし、
お前のだらだら書いた戯言もスルー。
>>244
それって一番表面のメソッドが呼び出されるってだけでは？
それって一番表面のメソッドが呼び出されるってだけでは？
246 ：仕様書無しさん：04/09/20 12:36:24
>>234
> オブジェクト指向なんぞ、まともなプログラマならオブジェクト指向言語を
> 使うまでもなく、それに近いプログラミングをしているだろう。
> アスペクト指向だって、なーーにをいまさらと言う感じだね。
> と、某Javaフレームワーク開発会社のコンサルタントとけんかしたのは漏れだが。
>
> どう考えても、フレームワークを使うとその昔の手続き型っぽいんだよね。
どういうフレームワークだ一体。
どうせお前はオブジェクト指向もろくにわかってないから
デザインパターンもJakartaのフレームワークも全部手続き型に見えるんだろ。
> オブジェクト指向なんぞ、まともなプログラマならオブジェクト指向言語を
> 使うまでもなく、それに近いプログラミングをしているだろう。
> アスペクト指向だって、なーーにをいまさらと言う感じだね。
> と、某Javaフレームワーク開発会社のコンサルタントとけんかしたのは漏れだが。
>
> どう考えても、フレームワークを使うとその昔の手続き型っぽいんだよね。
どういうフレームワークだ一体。
どうせお前はオブジェクト指向もろくにわかってないから
デザインパターンもJakartaのフレームワークも全部手続き型に見えるんだろ。
247 ：仕様書無しさん：04/09/20 12:37:33
248 ：仕様書無しさん ：04/09/20 12:40:49
>246
おまえが理解してるようにも思えないがなｗ
おまえが理解してるようにも思えないがなｗ
それで?
>>234は、多分、あれだ。
フレームワークを使って開発すると、
一番下位の実装部分を記述するコーダからは、
実装を書き込むメソッドはインタフェースで縛られていて、
処理は全て、すでに用意されているフレームワーク標準のメソッドを使用するだけになるから、
書かされるほうからは、手続き型に見える。
下位コーダからは、完成されたフレームワークでの開発は、
限りなく、手続き型だろ。
この場合、
極力余計な事をやらせないように縛るのがフレームワークだと言ってもいい。
フレームワークを使って開発すると、
一番下位の実装部分を記述するコーダからは、
実装を書き込むメソッドはインタフェースで縛られていて、
処理は全て、すでに用意されているフレームワーク標準のメソッドを使用するだけになるから、
書かされるほうからは、手続き型に見える。
下位コーダからは、完成されたフレームワークでの開発は、
限りなく、手続き型だろ。
この場合、
極力余計な事をやらせないように縛るのがフレームワークだと言ってもいい。
>>250
そうだろうな。そしてそれは現実にあわせてわざとやってんだよ。
そうだろうな。そしてそれは現実にあわせてわざとやってんだよ。
>>239
つまりね、後々の要件（これは別プロジェクトとかだよ）に耐えられるような
部品として柔軟性を確保した設計をすると、
現状のプロジェクトや別のプロジェクトではそんなことする必要がないのに
複雑さ（構造のだよ）が増すわけだよ。
かつ、再利用できる部分は少なくなるわけだ（差分が大きくなるということ）。
本当の部品を作っているような場合、あるいは部品化しないとまずい場合は別だけど、
こうなるとプロジェクトごとにソース修正とかした方が早い。
念のため、もちろん一つのプロジェクト内での話は別だよ。
この場合は当然後々修正が容易になるように設計するべき。
でも、別のプロジェクトで必要な機能が変わったりする場合ってのは、
影響範囲はそのプロジェクトだけなんだから、これまでの部分を変更なんて事はない。
※ていうか、初めからそういう場合の話なわけで。
つまりね、後々の要件（これは別プロジェクトとかだよ）に耐えられるような
部品として柔軟性を確保した設計をすると、
現状のプロジェクトや別のプロジェクトではそんなことする必要がないのに
複雑さ（構造のだよ）が増すわけだよ。
かつ、再利用できる部分は少なくなるわけだ（差分が大きくなるということ）。
本当の部品を作っているような場合、あるいは部品化しないとまずい場合は別だけど、
こうなるとプロジェクトごとにソース修正とかした方が早い。
念のため、もちろん一つのプロジェクト内での話は別だよ。
この場合は当然後々修正が容易になるように設計するべき。
でも、別のプロジェクトで必要な機能が変わったりする場合ってのは、
影響範囲はそのプロジェクトだけなんだから、これまでの部分を変更なんて事はない。
※ていうか、初めからそういう場合の話なわけで。
>>252
> >>238
> だれがディスク容量を問題にしてるんだよ…
> 差分が大きくなる→元のコードをそのまま再利用できる割合が少ない
> →ソース修正したり新たに書く方が手っ取り早い
> ってことだよ。
それで手っ取り早いと思う事態に直面したと言うことは
エクステンションポイントを設ける場所を間違えたか
しっかりと設けていなかったかだろうな。
モジュール間の関係が疎になると、逆にコードを新たに書き直す
手間を省きやすくなって、書き直すという無駄がなくせて手っ取り早くなるよ。
従来のやり方が以下だとすると
┌────┐▲uses ┌────┐
│ クラスA ├───→│ クラスB │
└────┘ └────┘
このやり方はクラスBを修正するとクラスAも修正しないと逝けないと言う欠点を持つことが多々ある。
> >>238
> だれがディスク容量を問題にしてるんだよ…
> 差分が大きくなる→元のコードをそのまま再利用できる割合が少ない
> →ソース修正したり新たに書く方が手っ取り早い
> ってことだよ。
それで手っ取り早いと思う事態に直面したと言うことは
エクステンションポイントを設ける場所を間違えたか
しっかりと設けていなかったかだろうな。
モジュール間の関係が疎になると、逆にコードを新たに書き直す
手間を省きやすくなって、書き直すという無駄がなくせて手っ取り早くなるよ。
従来のやり方が以下だとすると
┌────┐▲uses ┌────┐
│ クラスA ├───→│ クラスB │
└────┘ └────┘
このやり方はクラスBを修正するとクラスAも修正しないと逝けないと言う欠点を持つことが多々ある。
255 ：仕様書無しさん：04/09/20 13:43:17
ここで新しいやり方は以下のように間に他のクラスを挟ませることだ。
クラスＣというクラスBのスーパークラスを用意する。
こうすることで、クラスBを変更しても、クラスAには影響を
及ぼさないようにすることができる。
また、クラスAがクラスBを取り扱うときは、あたかもクラスC
に対してプログラミングしているように見えるので、
クラスBの中身を全く知らなくてもプログラミングできるようになるのである。
┌────┐▲uses ┌────┐
│ クラスA ├───→│ クラスＣ │
└────┘ └────┘
△
│
│
┌─┴──┐
│クラスB │
└────┘
クラスＣというクラスBのスーパークラスを用意する。
こうすることで、クラスBを変更しても、クラスAには影響を
及ぼさないようにすることができる。
また、クラスAがクラスBを取り扱うときは、あたかもクラスC
に対してプログラミングしているように見えるので、
クラスBの中身を全く知らなくてもプログラミングできるようになるのである。
┌────┐▲uses ┌────┐
│ クラスA ├───→│ クラスＣ │
└────┘ └────┘
△
│
│
┌─┴──┐
│クラスB │
└────┘
256 ：仕様書無しさん：04/09/20 13:49:50
さらに、クラスを修正せずに追加するだけで更新可能に
するということとは、どういうことかというと、
以下のように、クラスCを継承してクラスDを一追加るだけで
修正完了できるようにするということである。
この場合、若干クラスAに修正することがあるが、
しなくても良いように設計することも可能である。
┌────┐▲uses ┌────┐
│ クラスA ├───→│ クラスＣ │
└────┘ └────┘
△
│
│
┌──┴──┐
┌─┴──┐┌─┴──┐
│クラスB ││クラスD │
└────┘└────┘
するということとは、どういうことかというと、
以下のように、クラスCを継承してクラスDを一追加るだけで
修正完了できるようにするということである。
この場合、若干クラスAに修正することがあるが、
しなくても良いように設計することも可能である。
┌────┐▲uses ┌────┐
│ クラスA ├───→│ クラスＣ │
└────┘ └────┘
△
│
│
┌──┴──┐
┌─┴──┐┌─┴──┐
│クラスB ││クラスD │
└────┘└────┘
>>253
> >>239
> つまりね、後々の要件（これは別プロジェクトとかだよ）に耐えられるような
> 部品として柔軟性を確保した設計をすると、
> 現状のプロジェクトや別のプロジェクトではそんなことする必要がないのに
> 複雑さ（構造のだよ）が増すわけだよ。
オブジェクト指向使っただけで複雑さが増す？
そりゃオブジェクト指向の使い方が悪いか、
設計が悪いかのどちらかだろ。単純に言えば。
> >>239
> つまりね、後々の要件（これは別プロジェクトとかだよ）に耐えられるような
> 部品として柔軟性を確保した設計をすると、
> 現状のプロジェクトや別のプロジェクトではそんなことする必要がないのに
> 複雑さ（構造のだよ）が増すわけだよ。
オブジェクト指向使っただけで複雑さが増す？
そりゃオブジェクト指向の使い方が悪いか、
設計が悪いかのどちらかだろ。単純に言えば。
なんで長文書く奴はバカばっかなんだ？
長文書いてる野史なんていないんだけど
図書いているから長文にみえるだけでない？
図書いているから長文にみえるだけでない？
260 ：仕様書無しさん：04/09/20 16:15:46
最近のぷろぐらまはマウスでぺこぺこやるだけでできる
261 ：仕様書無しさん：04/09/20 17:13:26
>>まさかとは思うが、セッションに値を保持せずにinsertするたびに毎回DBにログイン
>>するというコードを書いているんじゃなかろうな。
やばいよ、にいちゃん。通常、毎回ＤＢとはコネクション張るだろ。
なんか、にいちゃんのシステム、とても恐ろしげでつよ。
>>するというコードを書いているんじゃなかろうな。
やばいよ、にいちゃん。通常、毎回ＤＢとはコネクション張るだろ。
なんか、にいちゃんのシステム、とても恐ろしげでつよ。
262 ：仕様書無しさん：04/09/20 17:14:17
q
>>261
同意。
同意。
264 ：仕様書無しさん：04/09/20 17:27:48
>>264
>>243がいってんのは、Session値の中に、接続状態のConnectionを保持する、ってんだろ。
ちなみにお前、コネクションプーリングでも、
コード上からは毎回Open/Close、Commit/Rollbackしないといけないのは分かってんだろうな？
>>243がいってんのは、Session値の中に、接続状態のConnectionを保持する、ってんだろ。
ちなみにお前、コネクションプーリングでも、
コード上からは毎回Open/Close、Commit/Rollbackしないといけないのは分かってんだろうな？
>>257
「オブジェクト指向を使っただけで複雑さが増す」
なんて書いてない気がするけど？
ただ、「別プロジェクトに耐えられるよう」に「部品」を柔軟にするってのは
どんな行為を指しているのか全くわからん
オブジェクト指向において部品であるクラス自体に柔軟性をもたせる必要が
必ずしもあるとは思えないし。
オブジェクト指向をやると「一見複雑に見える」ってのはあるんじゃない？
C上がりのおっさんが「ファイル一杯でわけわからん」とか言ってたよ。
ちなみに254のやり方でクラスＢを変更したときにクラスＡも変更しなくちゃいけないような
インターフェース設計する奴は255でも256でも結果は同じだと思う。
というより、254で発生する問題が255,256で解決できると思っている254が不思議でならん。
「オブジェクト指向を使っただけで複雑さが増す」
なんて書いてない気がするけど？
ただ、「別プロジェクトに耐えられるよう」に「部品」を柔軟にするってのは
どんな行為を指しているのか全くわからん
オブジェクト指向において部品であるクラス自体に柔軟性をもたせる必要が
必ずしもあるとは思えないし。
オブジェクト指向をやると「一見複雑に見える」ってのはあるんじゃない？
C上がりのおっさんが「ファイル一杯でわけわからん」とか言ってたよ。
ちなみに254のやり方でクラスＢを変更したときにクラスＡも変更しなくちゃいけないような
インターフェース設計する奴は255でも256でも結果は同じだと思う。
というより、254で発生する問題が255,256で解決できると思っている254が不思議でならん。
>>265
open/closeとconnect/disconnectとでは、コストが違うでしょ。
たしかに、HttpSessionにConnectionのインスタンスを保持するのは、同時接続ユーザ数が多いシステムでは問題だが...
open/closeとconnect/disconnectとでは、コストが違うでしょ。
たしかに、HttpSessionにConnectionのインスタンスを保持するのは、同時接続ユーザ数が多いシステムでは問題だが...
「変更したときの影響範囲を把握しやすい」ように作るのがポイントでは
基地外がまざってるな・・・('A`)
>>267
は？
この際、>>243はおいといて。
分かってんのか、分かってないのか分からないが、
コネクションプーリングってのは、
コード上から、切断、とした資源を、APサーバに相当するプロセスが回収して、
別の場所で、接続、とされた場合に、切断しないで保持していた接続を再割り当てする手法のこと。
と、知ってんなら、これは余計なお世話だが。
で。
つまり、コード上から、接続／切断を意識することはない。
コードでは普通にopen/closeをしないといけない、ということだ。
Javaだと、JNDIで設定された接続先へのコネクションをプールした、
DataSourceオブジェクトに対するgetConnection()と、取得した接続に対する、
close()は、当然やらないといけない、ってこった。
コーダからはopen/closeも、connect/disconnectも関係ない。
というか、普通、open/closeもconnect/disconnectも同じ意味だろ。
接続を開く、閉じる、の儀式は普通にやるの。やんなけりゃいけないの。
は？
この際、>>243はおいといて。
分かってんのか、分かってないのか分からないが、
コネクションプーリングってのは、
コード上から、切断、とした資源を、APサーバに相当するプロセスが回収して、
別の場所で、接続、とされた場合に、切断しないで保持していた接続を再割り当てする手法のこと。
と、知ってんなら、これは余計なお世話だが。
で。
つまり、コード上から、接続／切断を意識することはない。
コードでは普通にopen/closeをしないといけない、ということだ。
Javaだと、JNDIで設定された接続先へのコネクションをプールした、
DataSourceオブジェクトに対するgetConnection()と、取得した接続に対する、
close()は、当然やらないといけない、ってこった。
コーダからはopen/closeも、connect/disconnectも関係ない。
というか、普通、open/closeもconnect/disconnectも同じ意味だろ。
接続を開く、閉じる、の儀式は普通にやるの。やんなけりゃいけないの。
>>271
コーディングのコストのことを言ったわけじゃないんだが...
コーディングのコストのことを言ったわけじゃないんだが...
Connection をどうラップしたところで Serializable にはならないんだが。
そんなコンテナ依存コード書いてるの？
そんなコンテナ依存コード書いてるの？
>>274
ASPだとそのまま乗っけられたな。
ASPだとそのまま乗っけられたな。
まぁ、ここで熱弁振るってるようなやつらは駄目だな
というかこんなところに来てる自体
冴えない感じだな
冴えない感じだな
>>254-257
あーえーとやね、例えば>>254みたいのから>>256みたいな構造にしたとして
# 何を解決できるってのはこの際置いといて
再利用できるようにするためには単純にAからのインターフェイスは統一する必要があるわけ。
このとき、>>254の構造の場合、そのプロジェクト専用なのだから、
そこで必要なインターフェイスにすればすむわけだが、
>>257みたいにするためには、後々に使用されるDのために、
汎用性のあるインターフェイスにする必要がある。
あたりまえのことで、やり方もいろいろあるんだろうけど、
現実はそんな先のことを想定してインターフェイスまで設計するより、
プロジェクト専用に作ってしまうほうが効率がいい。
次のプロジェクトでは、今回のを元にしてソースから差分修正すればいい。
今回のプロジェクトと今後のプロジェクトでインターフェイスをあわせるメリットが少ないって事。
現実を見たときの話だよ。
こういう設計をしようと思ったら、それなりの人間が設計、保守する必要が出てくる。
設計の意図を正しく理解してる人間で無いと、今後のプロジェクトでも利用できないことになる。
で、その辺のリスクを被ってまでソース修正しないでよい部品を作ることにメリットがない事が多い。
何のために再利用できるようにするのか、それはトータルの労力を削るため。
現実にはトータルで労力を削ることにならないことが多いって事。
あーえーとやね、例えば>>254みたいのから>>256みたいな構造にしたとして
# 何を解決できるってのはこの際置いといて
再利用できるようにするためには単純にAからのインターフェイスは統一する必要があるわけ。
このとき、>>254の構造の場合、そのプロジェクト専用なのだから、
そこで必要なインターフェイスにすればすむわけだが、
>>257みたいにするためには、後々に使用されるDのために、
汎用性のあるインターフェイスにする必要がある。
あたりまえのことで、やり方もいろいろあるんだろうけど、
現実はそんな先のことを想定してインターフェイスまで設計するより、
プロジェクト専用に作ってしまうほうが効率がいい。
次のプロジェクトでは、今回のを元にしてソースから差分修正すればいい。
今回のプロジェクトと今後のプロジェクトでインターフェイスをあわせるメリットが少ないって事。
現実を見たときの話だよ。
こういう設計をしようと思ったら、それなりの人間が設計、保守する必要が出てくる。
設計の意図を正しく理解してる人間で無いと、今後のプロジェクトでも利用できないことになる。
で、その辺のリスクを被ってまでソース修正しないでよい部品を作ることにメリットがない事が多い。
何のために再利用できるようにするのか、それはトータルの労力を削るため。
現実にはトータルで労力を削ることにならないことが多いって事。
念のため聞くんだけど、
┌────┐▲uses ┌────┐
│クラスＡ ├───→│ クラスＢ │
└────┘ └────┘
これはＢをＡが継承している図なの？
superはＢだよね？ね？
┌────┐▲uses ┌────┐
│クラスＡ ├───→│ クラスＢ │
└────┘ └────┘
これはＢをＡが継承している図なの？
superはＢだよね？ね？
>>279 そうだね
再利用は、（そのためのメカニズムがあっても）コストゼロという事にはならないね。
本当に再利用をするのなら、そのためのコストを負担しなくてはならないと思う。
結局、開発組織としてコストを負担する覚悟がなければ、再利用なぞ出来はしない。
現場レベル／個人レベルの努力では無理だろうう。
再利用は、（そのためのメカニズムがあっても）コストゼロという事にはならないね。
本当に再利用をするのなら、そのためのコストを負担しなくてはならないと思う。
結局、開発組織としてコストを負担する覚悟がなければ、再利用なぞ出来はしない。
現場レベル／個人レベルの努力では無理だろうう。
282 ：仕様書無しさん：04/09/21 11:19:08
>>280
基本からやり直せ
基本からやり直せ
286 ：仕様書無しさん：04/09/21 14:36:55
287 ：仕様書無しさん：04/09/21 14:38:07
288 ：仕様書無しさん：04/09/21 14:40:12
>>266
> >>257
> 「オブジェクト指向を使っただけで複雑さが増す」
> なんて書いてない気がするけど？
じゃあ具体的にオブジェクト指向でどうしたら複雑さが増すと主張しているのだ？
>
> オブジェクト指向をやると「一見複雑に見える」ってのはあるんじゃない？
> C上がりのおっさんが「ファイル一杯でわけわからん」とか言ってたよ。
余計なこと考えすぎて冷静さが足りないだけだろ。
Javaなら、ちゃんとJavadocを見せるなりの工夫をすればいい。
EclipseのようなIDEを使えばさらに読みやすくなるが。
> ちなみに254のやり方でクラスＢを変更したときにクラスＡも変更しなくちゃいけないような
> インターフェース設計する奴は255でも256でも結果は同じだと思う。
> というより、254で発生する問題が255,256で解決できると思っている254が不思議でならん。
そりゃ解決できないケースもあるさ。だが解決できるケースもあるとして、例を示したまでだ
> >>257
> 「オブジェクト指向を使っただけで複雑さが増す」
> なんて書いてない気がするけど？
じゃあ具体的にオブジェクト指向でどうしたら複雑さが増すと主張しているのだ？
>
> オブジェクト指向をやると「一見複雑に見える」ってのはあるんじゃない？
> C上がりのおっさんが「ファイル一杯でわけわからん」とか言ってたよ。
余計なこと考えすぎて冷静さが足りないだけだろ。
Javaなら、ちゃんとJavadocを見せるなりの工夫をすればいい。
EclipseのようなIDEを使えばさらに読みやすくなるが。
> ちなみに254のやり方でクラスＢを変更したときにクラスＡも変更しなくちゃいけないような
> インターフェース設計する奴は255でも256でも結果は同じだと思う。
> というより、254で発生する問題が255,256で解決できると思っている254が不思議でならん。
そりゃ解決できないケースもあるさ。だが解決できるケースもあるとして、例を示したまでだ
香ばしい香具師を相手にするなよ。
ここは、あたまがわるいヒトのインターネットですね :)
>>261
> >>まさかとは思うが、セッションに値を保持せずにinsertするたびに毎回DBにログイン
> >>するというコードを書いているんじゃなかろうな。
>
> やばいよ、にいちゃん。通常、毎回ＤＢとはコネクション張るだろ。
> なんか、にいちゃんのシステム、とても恐ろしげでつよ。
やばいのはおまえ。
無駄に重複したコードはほかのところに書く。
これ常識。
> >>まさかとは思うが、セッションに値を保持せずにinsertするたびに毎回DBにログイン
> >>するというコードを書いているんじゃなかろうな。
>
> やばいよ、にいちゃん。通常、毎回ＤＢとはコネクション張るだろ。
> なんか、にいちゃんのシステム、とても恐ろしげでつよ。
やばいのはおまえ。
無駄に重複したコードはほかのところに書く。
これ常識。
293 ：仕様書無しさん：04/09/21 14:47:00
_ ∩
( ﾟ∀ﾟ)彡 た・し・ろ!た・し・ろ!
⊂彡
_ ∩
( ﾟ∀ﾟ)彡 た・し・ろ!た・し・ろ!
⊂彡
ﾀｲ━━━━||Φ|(|´|Д|`|)|Φ||━━━━ﾎ!!祭り
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!遅れるな！
( ﾟ∀ﾟ)彡 た・し・ろ!た・し・ろ!
⊂彡
_ ∩
( ﾟ∀ﾟ)彡 た・し・ろ!た・し・ろ!
⊂彡
ﾀｲ━━━━||Φ|(|´|Д|`|)|Φ||━━━━ﾎ!!祭り
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!遅れるな！
>>286
そんなつもりはないよ。
昔から、ソフトウェア再利用というのは「ライフサイクルにおけるコストの低減に一番有効」
だと言われていて、自分もそう思う。
ただソフトウェア再利用のための道具として、オブジェクト指向を採択したしても、
「自動的にソフトウェア再利用が可能になるかどうか」という命題に対して「否」だと言っているのだ。
組織的／制度的に「再利用のためのコスト」を負担しなければ再利用は出来ないのだ。
#まあ「無料では何も手に入らない」という当然の話の言い換えに過ぎないのだが
そんなつもりはないよ。
昔から、ソフトウェア再利用というのは「ライフサイクルにおけるコストの低減に一番有効」
だと言われていて、自分もそう思う。
ただソフトウェア再利用のための道具として、オブジェクト指向を採択したしても、
「自動的にソフトウェア再利用が可能になるかどうか」という命題に対して「否」だと言っているのだ。
組織的／制度的に「再利用のためのコスト」を負担しなければ再利用は出来ないのだ。
#まあ「無料では何も手に入らない」という当然の話の言い換えに過ぎないのだが
295 ：仕様書無しさん：04/09/21 17:14:50
>>294
> ただソフトウェア再利用のための道具として、オブジェクト指向を採択したしても、
> 「自動的にソフトウェア再利用が可能になるかどうか」という命題に対して「否」だと言っているのだ。
そんな百も承知な当たり前なことを偉そうに語って何が言いたいのだか。
とにかくオブジェクト指向を使わない方がいいという主張したいのかな？
> ただソフトウェア再利用のための道具として、オブジェクト指向を採択したしても、
> 「自動的にソフトウェア再利用が可能になるかどうか」という命題に対して「否」だと言っているのだ。
そんな百も承知な当たり前なことを偉そうに語って何が言いたいのだか。
とにかくオブジェクト指向を使わない方がいいという主張したいのかな？
296 ：仕様書無しさん：04/09/21 18:10:04
ここは、あたまがわるいヒトのインターネットですね :)
> ホントにバカばっかりだな、ここ。
そそ。
だから、自ら晒しageするなよ > バカ
そそ。
だから、自ら晒しageするなよ > バカ
>>288
>> というより、254で発生する問題が255,256で解決できると思っている254が不思議でならん。
>そりゃ解決できないケースもあるさ。だが解決できるケースもあるとして、例を示したまでだ
「解決できないケースがある」ではない。
254でA,Bともに変更しなければ行けない場合、255,256でも「確実に」同じことが起きる。
254においてBを変更した結果Aも変更しなくてはいけないと言うことはBのインターフェースが
変わったと言うことであり、256におけるB,DはCのインターフェースを継承する継承クラスなので
254において前述のような問題が起きる場合は当然基底クラスであるCのインターフェースが
変更されなければいけないと言うことだ。
＞じゃあ具体的にオブジェクト指向でどうしたら複雑さが増すと主張しているのだ？
いや、別に俺が主張してるわけじゃないんだが、、、
予測不可能な将来の機能拡張のことにまで頭を悩ませて設計＆作成した場合。じゃない？
経験的にか、機能の性質的にか、何らかの理由で将来拡張される姿が予測できるなら
それなりに考えて設計すればいい。
それができないなら、または考え出すときりがないなら、無駄な時間を費やさずに必要な機能を
実現するためのオブジェクト構成を考えればいい。問題領域がクラス単位になるだけで、作成＆改変が楽になるだろう？
そういう匙加減をわかってない人間が事を無駄に複雑にする
>> というより、254で発生する問題が255,256で解決できると思っている254が不思議でならん。
>そりゃ解決できないケースもあるさ。だが解決できるケースもあるとして、例を示したまでだ
「解決できないケースがある」ではない。
254でA,Bともに変更しなければ行けない場合、255,256でも「確実に」同じことが起きる。
254においてBを変更した結果Aも変更しなくてはいけないと言うことはBのインターフェースが
変わったと言うことであり、256におけるB,DはCのインターフェースを継承する継承クラスなので
254において前述のような問題が起きる場合は当然基底クラスであるCのインターフェースが
変更されなければいけないと言うことだ。
＞じゃあ具体的にオブジェクト指向でどうしたら複雑さが増すと主張しているのだ？
いや、別に俺が主張してるわけじゃないんだが、、、
予測不可能な将来の機能拡張のことにまで頭を悩ませて設計＆作成した場合。じゃない？
経験的にか、機能の性質的にか、何らかの理由で将来拡張される姿が予測できるなら
それなりに考えて設計すればいい。
それができないなら、または考え出すときりがないなら、無駄な時間を費やさずに必要な機能を
実現するためのオブジェクト構成を考えればいい。問題領域がクラス単位になるだけで、作成＆改変が楽になるだろう？
そういう匙加減をわかってない人間が事を無駄に複雑にする
メソッド厨ってのはこういうものです。
方法論の議論にばかり時間を費やして、全然前に進みません。
製造をほとんど経験していないコンサルの人とか、
勉強好きの若手プログラマにこのような傾向が良く見られます。
若い人の場合、そのまま歳をとらないよう祈ります
方法論の議論にばかり時間を費やして、全然前に進みません。
製造をほとんど経験していないコンサルの人とか、
勉強好きの若手プログラマにこのような傾向が良く見られます。
若い人の場合、そのまま歳をとらないよう祈ります
301 ：仕様書無しさん：04/09/22 03:06:10
漏れは、継承はほとんど使わんな。
たいがい委譲をつかう。勝手に親クラスのメソッドをたたかれても困るんでな。
たいがい委譲をつかう。勝手に親クラスのメソッドをたたかれても困るんでな。
あれか、既存のコードを修正するよりも継承などにより
コードの追加により対応するっていってんのは要するに
Opne-Closed-Principleのことをいってんのか。
> 経験的にか、機能の性質的にか、何らかの理由で将来
> 拡張される姿が予測できるなら それなりに考えて設計
> すればいい。
> それができないなら、または考え出すときりがないなら、
> 無駄な時間を費やさずに必要な機能を 実現するための
> オブジェクト構成を考えればいい。問題領域がクラス単位に
> なるだけで、作成＆改変が楽になるだろう？
これはYAGNIだな。昔から一般的にいわれていることだから
当たり前って言ったら当たり前だけど、まあ、確かに守れてない
奴も多いのは確かだな。
再利用するコンポーネントとしては継承ベースで再利用する
というのはあまり洗練されているとは思えないな。コンポーネントの
開発の初期段階では確かに継承ベースでもいいんだけど、
継承をつかうとTemplateパターンみたいなのはStrategyパターン
に置き換えたほうがいいというのはどこかのえらい人がいってたような
記憶がある。継承ベースだとどうしてもホワイトボックス的な再利用
になるのでできれば委譲ベースのブラックボックスにしたいところ。
コンポーネントがプロジェクトを転がしている間に修正が
入るのはしかたないと思う。というかそれがあるべき姿だと思う。
つかっていくうちに洗練されていくのは当たり前。
ナレッジベースでコンポーネントや構造の再利用するのは
アナリシスパターンでこれもありだと思う。
コードの追加により対応するっていってんのは要するに
Opne-Closed-Principleのことをいってんのか。
> 経験的にか、機能の性質的にか、何らかの理由で将来
> 拡張される姿が予測できるなら それなりに考えて設計
> すればいい。
> それができないなら、または考え出すときりがないなら、
> 無駄な時間を費やさずに必要な機能を 実現するための
> オブジェクト構成を考えればいい。問題領域がクラス単位に
> なるだけで、作成＆改変が楽になるだろう？
これはYAGNIだな。昔から一般的にいわれていることだから
当たり前って言ったら当たり前だけど、まあ、確かに守れてない
奴も多いのは確かだな。
再利用するコンポーネントとしては継承ベースで再利用する
というのはあまり洗練されているとは思えないな。コンポーネントの
開発の初期段階では確かに継承ベースでもいいんだけど、
継承をつかうとTemplateパターンみたいなのはStrategyパターン
に置き換えたほうがいいというのはどこかのえらい人がいってたような
記憶がある。継承ベースだとどうしてもホワイトボックス的な再利用
になるのでできれば委譲ベースのブラックボックスにしたいところ。
コンポーネントがプロジェクトを転がしている間に修正が
入るのはしかたないと思う。というかそれがあるべき姿だと思う。
つかっていくうちに洗練されていくのは当たり前。
ナレッジベースでコンポーネントや構造の再利用するのは
アナリシスパターンでこれもありだと思う。
>>Opne-Closed-Principle
すまん、Open-Closed-Principleの間違い。
すまん、Open-Closed-Principleの間違い。
> 継承をつかうとTemplateパターンみたいなのはStrategyパターン
> に置き換えたほうがいいというのはどこかのえらい人がいってたような
これを
> 継承をつかって基底クラスの動作を変更するTemplateパターン
> みたいなのはStrategyパターン に置き換えたほうがいいというの
> はどこかのえらい人がいってたような
に修正。
> に置き換えたほうがいいというのはどこかのえらい人がいってたような
これを
> 継承をつかって基底クラスの動作を変更するTemplateパターン
> みたいなのはStrategyパターン に置き換えたほうがいいというの
> はどこかのえらい人がいってたような
に修正。
305 ：仕様書無しさん：04/09/22 04:04:22
カスが何人集まってもダメってことがよくわかるスレだなｗ
本嫁、本。ﾊﾞｶｧ！
大体、掲示板に書ききれるか、ﾎﾞｹ！
この本で使用してる言語知らないからﾑﾘｨ、なんて言う奴はﾌﾟﾛｸﾞﾗﾏ名乗るんじゃねぇ！
大体、掲示板に書ききれるか、ﾎﾞｹ！
この本で使用してる言語知らないからﾑﾘｨ、なんて言う奴はﾌﾟﾛｸﾞﾗﾏ名乗るんじゃねぇ！
>>306
>本嫁、本。ﾊﾞｶｧ！
本を読まずに発言している奴は居ない様に思うが。ただ読んでも理解できていない奴が(ry
>大体、掲示板に書ききれるか、ﾎﾞｹ！
ごもっともだが・・・。エッセンスみたいな表現は無理か？
>この本で使用してる言語知らないからﾑﾘｨ、なんて言う奴はﾌﾟﾛｸﾞﾗﾏ名乗るんじゃねぇ！
同意
>本嫁、本。ﾊﾞｶｧ！
本を読まずに発言している奴は居ない様に思うが。ただ読んでも理解できていない奴が(ry
>大体、掲示板に書ききれるか、ﾎﾞｹ！
ごもっともだが・・・。エッセンスみたいな表現は無理か？
>この本で使用してる言語知らないからﾑﾘｨ、なんて言う奴はﾌﾟﾛｸﾞﾗﾏ名乗るんじゃねぇ！
同意
311 ：仕様書無しさん：04/09/22 21:06:39
おぶじぇくと歯垢
>>312
何に疑問を抱いたのかわからないが、メソッドを「たたく」が「呼び出す」の意味であるならば、
サブクラス以外から呼び出して欲しくないメソッドは「protected」等の指定をするでしょ？
サブクラスから呼んで欲しくなければ「private」にするよね。
ということでは？
何に疑問を抱いたのかわからないが、メソッドを「たたく」が「呼び出す」の意味であるならば、
サブクラス以外から呼び出して欲しくないメソッドは「protected」等の指定をするでしょ？
サブクラスから呼んで欲しくなければ「private」にするよね。
ということでは？
314 ：仕様書無しさん：04/09/22 23:33:05
>>300
つまりメソッド厨ってのはインスタンスフィールド(インスタンス属性、インスタンスメンバ変数)
をろくに使わず機能面だけに着目しすぎてUMLでクラス図を設計してしまうC厨みたいな
やつのことを言うのですね。
つまりメソッド厨ってのはインスタンスフィールド(インスタンス属性、インスタンスメンバ変数)
をろくに使わず機能面だけに着目しすぎてUMLでクラス図を設計してしまうC厨みたいな
やつのことを言うのですね。
>>313
いや、>>301の話は単にGoｆ本の序文に書いてあることまんまだろ。
>>301のカキコ自体はなんのために書いたんだかよう分からん馬鹿丸出しだが、
継承より委譲っての自体は割りとコンセンサスだし、突っ込みいれるほどのところではなかろう。
まぁ、どっちでもいいんだけど
>>314
この場合、単に方法論厨って意味じゃないのかな？＞メソッド厨
いや、>>301の話は単にGoｆ本の序文に書いてあることまんまだろ。
>>301のカキコ自体はなんのために書いたんだかよう分からん馬鹿丸出しだが、
継承より委譲っての自体は割りとコンセンサスだし、突っ込みいれるほどのところではなかろう。
まぁ、どっちでもいいんだけど
>>314
この場合、単に方法論厨って意味じゃないのかな？＞メソッド厨
>>315
「継承より委譲」ってのは適用範囲はどの程度なんでしょうね？
個人的には「継承も委譲も」で使い分けてるつもりなんですが。
「勝手に親クラスのメソッドをたたかれても困る」の正解は？
理論に疎い人間なので申し訳ないです。
「継承より委譲」ってのは適用範囲はどの程度なんでしょうね？
個人的には「継承も委譲も」で使い分けてるつもりなんですが。
「勝手に親クラスのメソッドをたたかれても困る」の正解は？
理論に疎い人間なので申し訳ないです。
根幹となる構造、構造の根幹部分には継承は余り使わない。
それを利用した、あるいはそれに合わせる形の各種実装クラス等には
実装を楽にするために継承を使う事がある。
それを利用した、あるいはそれに合わせる形の各種実装クラス等には
実装を楽にするために継承を使う事がある。
>316
犬も呼吸するが、猫も呼吸する。
が、猫は犬を継承しない。
それは、生物の呼吸する機能を委譲して実現する。
犬は呼吸する、柴犬も呼吸する。
その場合は、犬から継承する。
よって、スーパークラスとサブクラスの関係によっては、
継承になりえるし、委譲でないといけない場合もある。
犬も呼吸するが、猫も呼吸する。
が、猫は犬を継承しない。
それは、生物の呼吸する機能を委譲して実現する。
犬は呼吸する、柴犬も呼吸する。
その場合は、犬から継承する。
よって、スーパークラスとサブクラスの関係によっては、
継承になりえるし、委譲でないといけない場合もある。
>318
逆を言えば、柴犬は犬からかならず継承すべきで、
呼吸を委譲によって実現してはいけない。
っていうのが、業務なんかでわかれば苦労しないんだけどな(つД`)
逆を言えば、柴犬は犬からかならず継承すべきで、
呼吸を委譲によって実現してはいけない。
っていうのが、業務なんかでわかれば苦労しないんだけどな(つД`)
>318
>犬も呼吸するが、猫も呼吸する。
>が、猫は犬を継承しない。
>それは、生物の呼吸する機能を委譲して実現する。
逆にこう書けば、「哺乳類から継承しろよ」という話になるが、
じゃ哺乳類というクラスが見出せるかというのは、
その実現すべき機能によっては、見出せるし、出せない場合もある。
スーパークラスを発見するさいには、実現するべき機能が、
どこまで共通化が必要か？を把握する必要がある。
よって、これと言った指針は、結局は実現すべき機能(業務)と
向きあわない限り、出てこないはず。
>犬も呼吸するが、猫も呼吸する。
>が、猫は犬を継承しない。
>それは、生物の呼吸する機能を委譲して実現する。
逆にこう書けば、「哺乳類から継承しろよ」という話になるが、
じゃ哺乳類というクラスが見出せるかというのは、
その実現すべき機能によっては、見出せるし、出せない場合もある。
スーパークラスを発見するさいには、実現するべき機能が、
どこまで共通化が必要か？を把握する必要がある。
よって、これと言った指針は、結局は実現すべき機能(業務)と
向きあわない限り、出てこないはず。
んー、なんかｵﾚはレベルが低いので消えます(つД`)
この程度はIDEのリファクタリング機能でどうとでも変えられる
>>318
> 猫は犬を継承しない。
これはむしろ当然ですよね。
>>320
> じゃ哺乳類というクラスが見出せるかというのは
この例に即して考えれば、「呼吸」はすべての生物に共通する機能なので、
「生物」クラス(抽象)に「呼吸」メソッド（抽象）を宣言する
「動物」「植物」「菌類」などの抽象クラスで実装する
が適当ではないかと思うのですが。
「呼吸」を委譲にしなければならない理由がよくわかりません (泣
> 猫は犬を継承しない。
これはむしろ当然ですよね。
>>320
> じゃ哺乳類というクラスが見出せるかというのは
この例に即して考えれば、「呼吸」はすべての生物に共通する機能なので、
「生物」クラス(抽象)に「呼吸」メソッド（抽象）を宣言する
「動物」「植物」「菌類」などの抽象クラスで実装する
が適当ではないかと思うのですが。
「呼吸」を委譲にしなければならない理由がよくわかりません (泣
324 ：仕様書無しさん：04/09/23 10:56:08
「呼吸」は継承と思う。
漏れの考える委譲をつかうケースは、
「犬」から、「サイボーグ犬」をつくる場合だ。
この場合、「サイボーグ犬」はかなり生物に近いとして、
それでも、「生物」でない為、委譲により作成し、一部の「生物」
にあって、「サイボーグ犬」では不要なもの、たとえば「寝る」など
を制限する。これを安易に継承してしまうと「サイボーグ犬」なのに
新人ＰＧなどに寝かされてしまい「サイボーグ犬」が登場する意味がない。
漏れの考える委譲をつかうケースは、
「犬」から、「サイボーグ犬」をつくる場合だ。
この場合、「サイボーグ犬」はかなり生物に近いとして、
それでも、「生物」でない為、委譲により作成し、一部の「生物」
にあって、「サイボーグ犬」では不要なもの、たとえば「寝る」など
を制限する。これを安易に継承してしまうと「サイボーグ犬」なのに
新人ＰＧなどに寝かされてしまい「サイボーグ犬」が登場する意味がない。
鳥とペンギンの関係は有名ですね。
詳しく
もう少しわかりやすく・・・・。
たとえば、下記の２つの要件がある。
1.全世界の生物のシミュレーション
2.ペットショップの販売管理
両方とも、犬と猫のクラスが見出せたが、
1の犬と猫のスーパークラスは「生物」になり(さらに下の哺乳類とかもありえる)
2のスーパークラスは「売り物」(値段などの属性がある)になった。
(売り物クラスからは「ペットの餌」とかも派生)
2の方はさらに展示用の犬と猫があり、この２つは「売り物」クラスからの派生ではなく
「展示物」のクラスからの派生になった(「展示物」には展示期間とかの状態を持つ)
たとえば、下記の２つの要件がある。
1.全世界の生物のシミュレーション
2.ペットショップの販売管理
両方とも、犬と猫のクラスが見出せたが、
1の犬と猫のスーパークラスは「生物」になり(さらに下の哺乳類とかもありえる)
2のスーパークラスは「売り物」(値段などの属性がある)になった。
(売り物クラスからは「ペットの餌」とかも派生)
2の方はさらに展示用の犬と猫があり、この２つは「売り物」クラスからの派生ではなく
「展示物」のクラスからの派生になった(「展示物」には展示期間とかの状態を持つ)
しかし、1 2とも犬猫は餌を食う
その場合に、1の場合はスーパークラスに実装を行い継承をおこなうだろう。
2は、「売り物」と「展示物」の2つのツリーがあるのだが、餌を食うのは
その具象化クラスであるわけだから、それぞれの犬と猫に「餌を食う」(+状態とか属性)を委譲で補う。
その場合に、1の場合はスーパークラスに実装を行い継承をおこなうだろう。
2は、「売り物」と「展示物」の2つのツリーがあるのだが、餌を食うのは
その具象化クラスであるわけだから、それぞれの犬と猫に「餌を食う」(+状態とか属性)を委譲で補う。
ここで、よく突っ込みが入るのだが、
展示物の犬も猫も、売り物の犬も猫も、1つから継承し、「売り物」「展示物」を委譲しろよ
という話になるのだが、どちらの場合がベストチョイスなのかは、その要件の詳しい内容を
把握していない限り無理だ。
ここで記載されている内容で、どちらから継承をおこなうかの、ベストチョイスを判断するのは不可能であり
ある程度ペットショップの知識があるか、さらに詳しい機能要件が出てこない限り思いつかないはず。
さらに新しい機能要件が出てきた結果「売物」でも「展示物」でも無い新しい継承ツリーが見つかる可能性もある。
何が委譲で何が継承かはすべては機能要件を把握しない限り、導き出せないのであろうか？
展示物の犬も猫も、売り物の犬も猫も、1つから継承し、「売り物」「展示物」を委譲しろよ
という話になるのだが、どちらの場合がベストチョイスなのかは、その要件の詳しい内容を
把握していない限り無理だ。
ここで記載されている内容で、どちらから継承をおこなうかの、ベストチョイスを判断するのは不可能であり
ある程度ペットショップの知識があるか、さらに詳しい機能要件が出てこない限り思いつかないはず。
さらに新しい機能要件が出てきた結果「売物」でも「展示物」でも無い新しい継承ツリーが見つかる可能性もある。
何が委譲で何が継承かはすべては機能要件を把握しない限り、導き出せないのであろうか？
長文および、乱文ｽﾏｿ
反論あったら、対抗案求む(;´Д｀)
反論あったら、対抗案求む(;´Д｀)
> 2のスーパークラスは「売り物」(値段などの属性がある)になった。
> (売り物クラスからは「ペットの餌」とかも派生)
>
> 2の方はさらに展示用の犬と猫があり、この２つは「売り物」クラスからの派生ではなく
> 「展示物」のクラスからの派生になった(「展示物」には展示期間とかの状態を持つ)
これは多重分類というやつですね。ドメインモデリングなど
実装に直結しないレベルの設計ではときどきあるケースけど
普通のOO言語ではそのまま実装できないことが多いらしい。
「らしい」というのはあまりつかったことがないのでよく知らない。
で、多重分類はどうやって実装するかどうか?というのが
あるんだけど失念してしまった。
多重分類については「UMLモデリングの本質」という本に
詳しく書いてあったけど、手元にその本がいないので
内容が確認できません。
誰か詳しい人フォローしてくれ。
> (売り物クラスからは「ペットの餌」とかも派生)
>
> 2の方はさらに展示用の犬と猫があり、この２つは「売り物」クラスからの派生ではなく
> 「展示物」のクラスからの派生になった(「展示物」には展示期間とかの状態を持つ)
これは多重分類というやつですね。ドメインモデリングなど
実装に直結しないレベルの設計ではときどきあるケースけど
普通のOO言語ではそのまま実装できないことが多いらしい。
「らしい」というのはあまりつかったことがないのでよく知らない。
で、多重分類はどうやって実装するかどうか?というのが
あるんだけど失念してしまった。
多重分類については「UMLモデリングの本質」という本に
詳しく書いてあったけど、手元にその本がいないので
内容が確認できません。
誰か詳しい人フォローしてくれ。
>>330
＞何が委譲で何が継承かはすべては機能要件を把握しない限り、導き出せないのであろうか？
当然のことだと思うけど、、
モノがどのように扱われるかを無視して抽象化してどうすんのよ。
ちなみに販売管理システムにおいて商品が「犬であるか猫であるか」は重要な情報だと思うけど
犬と猫をそれぞれクラスとして派生する必要なんて出ないと思うぞ。
犬、猫それぞれに固有な動作が販売管理に影響を及ぼす事なんてなさそうだし。
それと通常ペットショップでは展示されている動物＝商品なので「展示物」という別の基底クラスを
想定する必要も多分出てこないと思う
ショーケースの中の犬を指さして「この犬ください」と言った場合に、裏の倉庫から同じ種類の
別の犬が連れてこられるペットショップなんて見たことないべ？
＞何が委譲で何が継承かはすべては機能要件を把握しない限り、導き出せないのであろうか？
当然のことだと思うけど、、
モノがどのように扱われるかを無視して抽象化してどうすんのよ。
ちなみに販売管理システムにおいて商品が「犬であるか猫であるか」は重要な情報だと思うけど
犬と猫をそれぞれクラスとして派生する必要なんて出ないと思うぞ。
犬、猫それぞれに固有な動作が販売管理に影響を及ぼす事なんてなさそうだし。
それと通常ペットショップでは展示されている動物＝商品なので「展示物」という別の基底クラスを
想定する必要も多分出てこないと思う
ショーケースの中の犬を指さして「この犬ください」と言った場合に、裏の倉庫から同じ種類の
別の犬が連れてこられるペットショップなんて見たことないべ？
> 犬、猫それぞれに固有な動作が販売管理に影響を及ぼす事なんてなさそうだし。
> それと通常ペットショップでは展示されている動物＝商品なので「展示物」という別の基底クラスを
> 想定する必要も多分出てこないと思う
それこそ機能要件次第だと思うが
> それと通常ペットショップでは展示されている動物＝商品なので「展示物」という別の基底クラスを
> 想定する必要も多分出てこないと思う
それこそ機能要件次第だと思うが
>>334
勿論そうだけど？
販売管理をするという要件には通常必要ないだろうと言ってるだけだよ
で、ペットショップの販売管理システムに於いて
犬と猫を別クラス扱いしなければいけない要件とか
思い付くのか？
ていうか、そんなシステムを入れたペットショップは
新しくグリーンイグアナを取り扱うことにしたら
『爬虫類』クラスとか『イグアナ』クラスとかを
増やすためにシステムを更新するわけですか？
何て不便な、、、
勿論そうだけど？
販売管理をするという要件には通常必要ないだろうと言ってるだけだよ
で、ペットショップの販売管理システムに於いて
犬と猫を別クラス扱いしなければいけない要件とか
思い付くのか？
ていうか、そんなシステムを入れたペットショップは
新しくグリーンイグアナを取り扱うことにしたら
『爬虫類』クラスとか『イグアナ』クラスとかを
増やすためにシステムを更新するわけですか？
何て不便な、、、
もし犬を販売したら保健所に届けることが条例で義務付けられているとかの
要件があったらどうするつもりなのかな？
要件があったらどうするつもりなのかな？
337 ：仕様書無しさん：04/09/23 22:28:02
犬が売れたら保健所への届け出情報テーブルに
未届けなレコードを追加する
まぁその辺はどのような手順で届け出されるかによる
売れたのが犬か猫かを判別する必要があることと
犬と猫を別個に派生させる必要があるかどうかは
全く別の問題なんだけどその辺分かってるか？
未届けなレコードを追加する
まぁその辺はどのような手順で届け出されるかによる
売れたのが犬か猫かを判別する必要があることと
犬と猫を別個に派生させる必要があるかどうかは
全く別の問題なんだけどその辺分かってるか？
340 ：仕様書無しさん：04/09/23 22:45:34
class 台帳
{
...
OnSold(Item item)
{
if(item.GetKind() == ItemKind.DOG)
{
保健所へ届ける();
}
}
}
{
...
OnSold(Item item)
{
if(item.GetKind() == ItemKind.DOG)
{
保健所へ届ける();
}
}
}
341 ：仕様書無しさん：04/09/23 22:46:47
YAGNI・・・代々木ア(ry
343 ：仕様書無しさん：04/09/23 22:54:23
>>336
変更は以下のとうり
①「犬登録抽象クラス」を追加。
②「犬クラス」は「犬登録抽象クラス」を継承するよう変更
以上。
コードは想像にまかすがこんなもんかな。
もちろん他の「○○犬クラス」は変更なし。
「○○犬クラス」のユーザクラスは以下のような感じで登録済みか取得する
if(isRegist.○○犬クラス){
//○○犬クラスは登録済み
}
変更は以下のとうり
①「犬登録抽象クラス」を追加。
②「犬クラス」は「犬登録抽象クラス」を継承するよう変更
以上。
コードは想像にまかすがこんなもんかな。
もちろん他の「○○犬クラス」は変更なし。
「○○犬クラス」のユーザクラスは以下のような感じで登録済みか取得する
if(isRegist.○○犬クラス){
//○○犬クラスは登録済み
}
じゃあ犬と猫を別クラスにするのはどういうケースなのかな？
そのシステムでその対象をどう扱うかによってクラス設計は変わってくる。
「販売管理システムなら商品別にクラスを分ける必要はない」と断定する
根拠がよくわからん。
そのシステムでその対象をどう扱うかによってクラス設計は変わってくる。
「販売管理システムなら商品別にクラスを分ける必要はない」と断定する
根拠がよくわからん。
書いてるうちに、間に何件かレスがあったようだが
344は >>338に対するレスってことでよろしく
344は >>338に対するレスってことでよろしく
>>340
俺の言い方がちょっとおかしかったかもしれないが、
「犬と猫とで販売後の事務手続きが違っていたらどうする？」
ということが言いたかった。
その場合、基底クラスに販売後処理（）というメソッドを設けて、犬クラス猫クラスでそれぞれ
その販売後処理（）をオーバーライドするという設計をとるということもありえるだろう。
とにかく「販売管理システムだったら犬と猫を別クラスにすることはありえない」という主張には
納得できない。
俺の言い方がちょっとおかしかったかもしれないが、
「犬と猫とで販売後の事務手続きが違っていたらどうする？」
ということが言いたかった。
その場合、基底クラスに販売後処理（）というメソッドを設けて、犬クラス猫クラスでそれぞれ
その販売後処理（）をオーバーライドするという設計をとるということもありえるだろう。
とにかく「販売管理システムだったら犬と猫を別クラスにすることはありえない」という主張には
納得できない。
>>343
そんなばかげた変更するなよ。
・商品が売れたときに、商品種別に対応付けられたアクティビティ群を起動するようにしておく
・犬という商品種別に、保健所に登録を届け出るアクティビティを対応付ける
という変更で済むはず。
class WorkflowProcess {
protected abstract doExecute();
public final execute() throws WorkflowException {
this.doExecute();
List activityList = this.getRelatedActivity();
for (Iterator i = activityList.iterator(); i.hasNextr(); ) {
Activity activity = (Activity)i.next();
activity.execute(this.getWorkflowContext());
}
}
}
そんなばかげた変更するなよ。
・商品が売れたときに、商品種別に対応付けられたアクティビティ群を起動するようにしておく
・犬という商品種別に、保健所に登録を届け出るアクティビティを対応付ける
という変更で済むはず。
class WorkflowProcess {
protected abstract doExecute();
public final execute() throws WorkflowException {
this.doExecute();
List activityList = this.getRelatedActivity();
for (Iterator i = activityList.iterator(); i.hasNextr(); ) {
Activity activity = (Activity)i.next();
activity.execute(this.getWorkflowContext());
}
}
}
↑↑↑ 最新20レスほどを見ての結論 ↑↑↑
「オブジェクト指向はやっぱり難しい」
ただし、約半数の人にとって。
「オブジェクト指向はやっぱり難しい」
ただし、約半数の人にとって。
351 ：仕様書無しさん：04/09/23 23:30:43
無いと断言したわけではない
ただ避けるべき設計だとは思っている
理由は335
335で言ったイグアナのように新しい商品を
市場の動向に合わせて追加するという、
店舗ではごくありふれた流れさえも阻害する設計が
許容されるほどのメリットがあるならやれば良い
おれにはそういうケースが思い付かない
ただ避けるべき設計だとは思っている
理由は335
335で言ったイグアナのように新しい商品を
市場の動向に合わせて追加するという、
店舗ではごくありふれた流れさえも阻害する設計が
許容されるほどのメリットがあるならやれば良い
おれにはそういうケースが思い付かない
354 ：仕様書無しさん：04/09/23 23:40:24
多分、328はペットショップの例をあげたのは、ただ単に
要件ごとに分類の仕方が違うという話がしたかっただけ
だと思うんだけど、ペットショップという実際の案件に近い
内容だったために突然議論が具体的になってきたな。
実際の販売管理システムの場合、商品ごとに
別クラスにすることはありえないというのはそうなんだろうけど。
要件ごとに分類の仕方が違うという話がしたかっただけ
だと思うんだけど、ペットショップという実際の案件に近い
内容だったために突然議論が具体的になってきたな。
実際の販売管理システムの場合、商品ごとに
別クラスにすることはありえないというのはそうなんだろうけど。
358 ：仕様書無しさん：04/09/24 00:02:24
そしてデスマですよ。
360 ：仕様書無しさん：04/09/24 00:12:10
いくらYAGNIっつーても340はちょっとアドホックすぎるかなぁと
思うんだけど。仕様変更に強いのは349のほうだとは思うけど、
どうなんだろう。
そもそも349のように仕様変更が後からかかりそうなワークフロー
(orビジネスロジック)は台帳から切り離したほうがベターだと思う。
思うんだけど。仕様変更に強いのは349のほうだとは思うけど、
どうなんだろう。
そもそも349のように仕様変更が後からかかりそうなワークフロー
(orビジネスロジック)は台帳から切り離したほうがベターだと思う。
答えは一つしかないわけじゃないからな
オブジェクト指向はあくまでモデリング技法なわけだから、
ある事例に対して正解が求まるというものでもないよな。
ある事例に対して正解が求まるというものでもないよな。
UML設計とオブジェクト指向を切り離して考えるところから
始めよう。
始めよう。
366 ：仕様書無しさん：04/09/24 10:03:18
切り離しちゃダメだろ
下手釣りだと思われる。
368 ：仕様書無しさん：04/09/24 12:47:53
こんなにバカが多いスレ、ここが初めてだ。
370 ：仕様書無しさん：04/09/24 16:24:25
371 ：仕様書無しさん：04/09/24 19:52:04
そんなドキュメント書かないよ いまどき。
書かされるのはNECぐらいだろ !
書かされるのはNECぐらいだろ !
Ｒｕｂｙ ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ 歩ｂじゅけうと思考。
> 今更何を言ってるんだ
> スレタイからしてマトモな奴が集うはずがなかろう
> 今更何を言ってるんだ
> スレタイからしてマトモな奴が集うはずがなかろう
> 今更何を言ってるんだ
> スレタイからしてマトモな奴が集うはずがなかろう
ま っ た く だ ！！
ばかばっか。( ´,_ゝ`)=3
> スレタイからしてマトモな奴が集うはずがなかろう
> 今更何を言ってるんだ
> スレタイからしてマトモな奴が集うはずがなかろう
> 今更何を言ってるんだ
> スレタイからしてマトモな奴が集うはずがなかろう
ま っ た く だ ！！
ばかばっか。( ´,_ゝ`)=3
375 ：ｌｐ－－－－－－－－－－－－－－－：04/09/24 20:37:13
Ｒｕｙｂｙ！！！！！！！！！！！！！！！！！！！！！
Rubyのためなら死ねろ
377 ：仕様書無しさん：04/09/24 20:47:36
このスレに参加している香具師は、バカしかいないな。
378 ：仕様書無しさん：04/09/24 20:48:17
Ｒｕｂｙ！
またｽｺﾞｲあれっぷりだな(つД`)
ちなみに、「継承より委譲を使うこと」とかって
初出典はなんなの？
ちなみに、「継承より委譲を使うこと」とかって
初出典はなんなの？
Ruby!!!!!!!!
381 ：仕様書無しさん：04/09/26 00:03:47
世の中不思議なことっていろいろありますよね。
あのね、うちの家のガスの元栓がね、閉めても開けても関係なかったの。
あのね、こないだ間違えて火を消そうとしたのね。元栓を締めて火が付いてるの。
それでね、管理人さんに聞いたらその元栓はいつも開いてるんだって。
本当の元栓は奥にあるんだって。
だからね、いままで信じて閉めていた元栓は関係なかったのね。どうよそれ。
閉めた感だけ？
たぶんほかの部屋の人も知らないんだと思う。
あのね、うちの家のガスの元栓がね、閉めても開けても関係なかったの。
あのね、こないだ間違えて火を消そうとしたのね。元栓を締めて火が付いてるの。
それでね、管理人さんに聞いたらその元栓はいつも開いてるんだって。
本当の元栓は奥にあるんだって。
だからね、いままで信じて閉めていた元栓は関係なかったのね。どうよそれ。
閉めた感だけ？
たぶんほかの部屋の人も知らないんだと思う。
382 ：仕様書無しさん：04/09/26 05:41:40
>>371
だよね、いきなりコーディングだもんな。
だよね、いきなりコーディングだもんな。
>>381
すっげぇなぁ、喪前。変数隠しをうまく表現してるよ！
すっげぇなぁ、喪前。変数隠しをうまく表現してるよ！
オブジェクト指向と
オブジェクト指向モデリングを
混同してるやつが多すぎる。
それが混乱の元だな。
「オブジェクト指向でなぜ作るのか」
という本を一度よんだらいい。
オブジェクト指向モデリングを
混同してるやつが多すぎる。
それが混乱の元だな。
「オブジェクト指向でなぜ作るのか」
という本を一度よんだらいい。
漏れは、せっかくなら、
「憂鬱なﾌﾟﾛｸﾞﾗﾏのためのｵﾌﾞｼﾞｪｸﾄ指向入門」がええと思う。
「憂鬱なﾌﾟﾛｸﾞﾗﾏのためのｵﾌﾞｼﾞｪｸﾄ指向入門」がええと思う。
るｂｙＬ＜＜＜＜＜＜＜＜＜＜＜＜＋ＬＫＪＫＪおあｗｐ＠っっっｄｗ＞＞＞＞＞＞＞＞ｄっっっっっっっｌｐっっっｗ
387 ：仕様書無しさん：04/09/26 15:32:37
世の中不思議なことっていろいろありますよね。
あのね、うちの家のガスの元栓がね、閉めても開けても関係なかったの。
あのね、こないだ間違えて火を消そうとしたのね。元栓を締めて火が付いてるの。
それでね、管理人さんに聞いたらその元栓はいつも開いてるんだって。
本当の元栓は奥にあるんだって。
だからね、いままで信じて閉めていた元栓は関係なかったのね。どうよそれ。
閉めた感だけ？
たぶんほかの部屋の人も知らないんだと思う。
あのね、うちの家のガスの元栓がね、閉めても開けても関係なかったの。
あのね、こないだ間違えて火を消そうとしたのね。元栓を締めて火が付いてるの。
それでね、管理人さんに聞いたらその元栓はいつも開いてるんだって。
本当の元栓は奥にあるんだって。
だからね、いままで信じて閉めていた元栓は関係なかったのね。どうよそれ。
閉めた感だけ？
たぶんほかの部屋の人も知らないんだと思う。
388 ：仕様書無しさん：04/09/27 00:40:35
C++が解らないからといって本に当たるなよ。
世の中に出回っているオブジェクト指向本の多くは
著者がオブジェクト指向を理解していなくて
文章に気品とセンスがなくて
解説がわかりにくくて
訳書の場合は原本の方がわかりやすい。
そんななか
>>385の本は
文章に気品とセンスがないだけで、内容はすばらしいから
評価は高い。
著者がオブジェクト指向を理解していなくて
文章に気品とセンスがなくて
解説がわかりにくくて
訳書の場合は原本の方がわかりやすい。
そんななか
>>385の本は
文章に気品とセンスがないだけで、内容はすばらしいから
評価は高い。
俺、正直いって憂鬱本の評価は高くないんだよね。
良さが分からない。憂鬱なプログラマじゃないからかな
良さが分からない。憂鬱なプログラマじゃないからかな
基本的に高い評価をしている人は、内容をある程度知っていて
学習のためでなく、雑談って感じで読んでいるからな。
面白い雑談でちょっと知っている知識を整理するのはいいけど、
これを使って知識をつけようとすると使えない。
また、自分で知識を整理しきっている人にも使えない。
学習のためでなく、雑談って感じで読んでいるからな。
面白い雑談でちょっと知っている知識を整理するのはいいけど、
これを使って知識をつけようとすると使えない。
また、自分で知識を整理しきっている人にも使えない。
393 ：仕様書無しさん：04/09/27 11:39:01
憂鬱本はオブジェクト指向がまだ市民権を得てない頃にDDJに連載されていたもの。
オブジェクト指向が完全に常識化した今では、少し不満もあるかもしれないが、
あの本のはたした功績は大きい。
オブジェクト指向が完全に常識化した今では、少し不満もあるかもしれないが、
あの本のはたした功績は大きい。
394 ：仕様書無しさん：04/09/27 15:51:16
>>394
いや、あからさまに釣りじゃねぇのか。
いや、あからさまに釣りじゃねぇのか。
>>396
もしや、>394自身が釣りだったのではないだろうか?
もしや、>394自身が釣りだったのではないだろうか?
つまり「釣られてやがんの(ﾌﾟ」を釣り上げるためのエサか
実に再帰的な構造だな
実に再帰的な構造だな
憂鬱本は特にいい本ではないと思うよ。冗長だし。
「こんな厚い本読まないとOOで書けないのかなぁ」
と思われたら害ですらあると思ってる。
他に読みやすい本があるかって言うと俺は知らないんだけどね。
「こんな厚い本読まないとOOで書けないのかなぁ」
と思われたら害ですらあると思ってる。
他に読みやすい本があるかって言うと俺は知らないんだけどね。
つまり憂鬱本は>>400が知っている中ではbestってことか。
「オブジェクト指向でなぜ作るのか」の感想ｷﾎﾞｰﾝ
ｸﾞｸﾞﾚとでつか、そうでつか。。。
ｸﾞｸﾞﾚとでつか、そうでつか。。。
>>402
身構えずにオブジェクト指向に接することができるようになる。
身構えずにオブジェクト指向に接することができるようになる。
デザインパターンってポリもーフィズムをいかに
うまく使うかってばっかを追求しすぎてる。
あんなの、オブジェクト指向の弊害に近い。
素人でもクラスがどんな動作するかを把握するようにするのが
大事じゃないか？
うまく使うかってばっかを追求しすぎてる。
あんなの、オブジェクト指向の弊害に近い。
素人でもクラスがどんな動作するかを把握するようにするのが
大事じゃないか？
デザインパターンはオブジェクト指向の弊害だって？
どこに目つけてんだよｗ
どこに目つけてんだよｗ
>>405
そうか?パターンやイディオムといった定石を
積み重ねることで複雑な表現ができると思う
んだけど。名前の付いていない複雑な構造だと
意思の疎通が難しいけど、名前がついている
パターンだと少々複雑でも名前を出せば意思の
疎通ができる。
とはいっても
・愚直でシンプルなコード
と
・定石を積み重ねた洗練されたコード
どちらがいいかは難しいところですが。
そうか?パターンやイディオムといった定石を
積み重ねることで複雑な表現ができると思う
んだけど。名前の付いていない複雑な構造だと
意思の疎通が難しいけど、名前がついている
パターンだと少々複雑でも名前を出せば意思の
疎通ができる。
とはいっても
・愚直でシンプルなコード
と
・定石を積み重ねた洗練されたコード
どちらがいいかは難しいところですが。
>>407
いいこと言うね。確かにどちらがよいか難しいところ。
>>405の言ってるクラスの挙動に対する理解といった話も
大事とは思うしある意味正しい気もするが、弊害とは思わないな。
ポリモはOOらしさの象徴と思う。
いいこと言うね。確かにどちらがよいか難しいところ。
>>405の言ってるクラスの挙動に対する理解といった話も
大事とは思うしある意味正しい気もするが、弊害とは思わないな。
ポリモはOOらしさの象徴と思う。
>400
冗長なのはしょうがないじゃん。エッセイみたいなもんだろ、あれは。
とっつきやすくていいと思うよ。
漏れは関連を説明する部分以外は特に感銘を受けなかったが、
まあそれだけでも読む価値はあったと思ってる。
>「こんな厚い本読まないとOOで書けないのかなぁ」
H生田氏はバートランド・メイヤー読まなきゃ駄目とかいってるしなあ。
冗長なのはしょうがないじゃん。エッセイみたいなもんだろ、あれは。
とっつきやすくていいと思うよ。
漏れは関連を説明する部分以外は特に感銘を受けなかったが、
まあそれだけでも読む価値はあったと思ってる。
>「こんな厚い本読まないとOOで書けないのかなぁ」
H生田氏はバートランド・メイヤー読まなきゃ駄目とかいってるしなあ。
問題はデザインパターンだけを知って、
それがオブジェクト指向だと思い込み、
自分だけが判るポリモーフィズム満載のソースコードを連発するコーダーだ。
素人にも判るソースが良いに決まってる。
パターンを知らなくては判らないソースは、その時点で上記より劣っている。
それがオブジェクト指向だと思い込み、
自分だけが判るポリモーフィズム満載のソースコードを連発するコーダーだ。
素人にも判るソースが良いに決まってる。
パターンを知らなくては判らないソースは、その時点で上記より劣っている。
>>411
そうです。
美しさを追求したものがデザパタです。
よく見かけるデザインなんて、ありふれてて美しくありません。
また素人に判るようなのも、そっけなくて美しいとは言えません。
あくまでOOマニアが舌なめずりし、味覚をかみ締めるのがデザパタ
の目的です。
そうです。
美しさを追求したものがデザパタです。
よく見かけるデザインなんて、ありふれてて美しくありません。
また素人に判るようなのも、そっけなくて美しいとは言えません。
あくまでOOマニアが舌なめずりし、味覚をかみ締めるのがデザパタ
の目的です。
> そうです。
> 美しさを追求したものがデザパタです。
そんなことだれも言っていません。
> 美しさを追求したものがデザパタです。
そんなことだれも言っていません。
結局オブジェクト指向にコンプレックスを持つ人間の意見が
大半を占めてきたな。
大半を占めてきたな。
416 ：仕様書無しさん：04/09/28 09:18:34
まともなプログラマなら、デザインパターンなどわざわざ勉強しなくても、
ある程度デザインパターンにプログラムがなっているはずだ。
問題はデザインパターンにあわせようと四苦八苦しているタコプログラマ。
ある程度の規模のプログラム（コンポーネント、パッケージ）を経験すれば、
そこから、これはJava風ではないとかあれこれ考えているうちにデザインパターン
はもとより、オブジェクト指向の発想になっていく。漏れも初めはＣ風Javaを
書いていたが、オブジェクト指向はプログラムを作る上でこの上なく都合がよいこと
に気がついた。
Web系のプログラマで決まりきったメソッドを突貫工事で作っている奴は一生ダメかもな。
ある程度デザインパターンにプログラムがなっているはずだ。
問題はデザインパターンにあわせようと四苦八苦しているタコプログラマ。
ある程度の規模のプログラム（コンポーネント、パッケージ）を経験すれば、
そこから、これはJava風ではないとかあれこれ考えているうちにデザインパターン
はもとより、オブジェクト指向の発想になっていく。漏れも初めはＣ風Javaを
書いていたが、オブジェクト指向はプログラムを作る上でこの上なく都合がよいこと
に気がついた。
Web系のプログラマで決まりきったメソッドを突貫工事で作っている奴は一生ダメかもな。
418 ：仕様書無しさん：04/09/28 10:45:55
> まともなプログラマなら、デザインパターンなどわざわざ勉強しなくても、
> ある程度デザインパターンにプログラムがなっているはずだ。
馬鹿だなぁ。パターンの意義はあくまでカタログ化だろ。
言葉を覚えたてのおこちゃまにはこまったもんだ。
> ある程度デザインパターンにプログラムがなっているはずだ。
馬鹿だなぁ。パターンの意義はあくまでカタログ化だろ。
言葉を覚えたてのおこちゃまにはこまったもんだ。
釣りですか？
知ってる人より知らない人の方が多く、難解なものなら、使う
べきでないのかも。
べきでないのかも。
言い換えると、誰でも知っているようなものを
知らないくらいスキルの低いところでは使うべきではないということだな。
確かに一気にデザインパターンを使うよりか基礎を固めたほうがいいかも知れんな。
知らないくらいスキルの低いところでは使うべきではないということだな。
確かに一気にデザインパターンを使うよりか基礎を固めたほうがいいかも知れんな。
高校時代。DOSがメインでデザインパターンはあったかも知れないが
一般には知られていなかった時代。ありがちに趣味でゲーム作っていたんだが、
あるときゲームを効率よく開発するための仕組みを考えているうちに
オブジェクト指向の考え方ができるようになったなぁ。
この仕組みは、複数の人で作りやすく個々のキャラクターを担当者を簡単に分けられ
その担当者は全体を意識することなく自分のキャラクターだけを集中して作れるというもの。
もちろん共通部分は共通に作り再利用し、拡張性も高くする。
オブジェクト指向で楽に作るというより、楽に作ろうとしていたらオブジェクト指向になったって感じ。
それまでは同じキャラクターのインスタンスを一つ追加するだけでも一苦労だった。
始めはキャラクターの動き（コード）とキャラクターの絵などのデータが分離していてデータを配列でもたせて
そのデータをコードでうんぬんとしていたんだけど、汎用かつ拡張性を高くするには配列の型が複雑になってしまう。
それに間違って他の人が変なデータを修正してしまったりしたら、複数の人で作りにくくなってしまう。
それからキャラクターは他のキャラクターを意識せずに独立して並列に動くべきだ。・・・などなど。
そこでそれよりもコードとデータをまとめた方が管理がしやすいってことでクラスを理解し、
個々のキャラクターだけに必要なデータを他人が間違って（または故意に）変更することを禁止できるってことでカプセル化を理解し、
ほとんど同じだけどちょっとだけ違うキャラクターを作りやすくするためにってことで継承を理解し、
個々のキャラクターを描画するための共通のインターフェースが必要ってことで多態性を理解し、
それらのキャラクター協調して動作させるために、一つの管理システムに登録していろいろ組み合わせてなんたらってことで
デザインパターン（もちろん当時はそんな用語は知らないが）の考え方に行き着いた。
あとでデザインパターンを知ったときには、昔あれこれ試行錯誤作ったのと同じような仕組みが
書かれていたりして、当時これがあったらもっと楽に作れたのになぁと思ったよ。
一般には知られていなかった時代。ありがちに趣味でゲーム作っていたんだが、
あるときゲームを効率よく開発するための仕組みを考えているうちに
オブジェクト指向の考え方ができるようになったなぁ。
この仕組みは、複数の人で作りやすく個々のキャラクターを担当者を簡単に分けられ
その担当者は全体を意識することなく自分のキャラクターだけを集中して作れるというもの。
もちろん共通部分は共通に作り再利用し、拡張性も高くする。
オブジェクト指向で楽に作るというより、楽に作ろうとしていたらオブジェクト指向になったって感じ。
それまでは同じキャラクターのインスタンスを一つ追加するだけでも一苦労だった。
始めはキャラクターの動き（コード）とキャラクターの絵などのデータが分離していてデータを配列でもたせて
そのデータをコードでうんぬんとしていたんだけど、汎用かつ拡張性を高くするには配列の型が複雑になってしまう。
それに間違って他の人が変なデータを修正してしまったりしたら、複数の人で作りにくくなってしまう。
それからキャラクターは他のキャラクターを意識せずに独立して並列に動くべきだ。・・・などなど。
そこでそれよりもコードとデータをまとめた方が管理がしやすいってことでクラスを理解し、
個々のキャラクターだけに必要なデータを他人が間違って（または故意に）変更することを禁止できるってことでカプセル化を理解し、
ほとんど同じだけどちょっとだけ違うキャラクターを作りやすくするためにってことで継承を理解し、
個々のキャラクターを描画するための共通のインターフェースが必要ってことで多態性を理解し、
それらのキャラクター協調して動作させるために、一つの管理システムに登録していろいろ組み合わせてなんたらってことで
デザインパターン（もちろん当時はそんな用語は知らないが）の考え方に行き着いた。
あとでデザインパターンを知ったときには、昔あれこれ試行錯誤作ったのと同じような仕組みが
書かれていたりして、当時これがあったらもっと楽に作れたのになぁと思ったよ。
つーか、デザインパターンも知らん奴が作ったらデスマになるからな。
そんな技術力の低い奴な奴はさっさと消えてほしい。
そうすればデザパタを知っている人のほうが多くなるしｗ
そんな技術力の低い奴な奴はさっさと消えてほしい。
そうすればデザパタを知っている人のほうが多くなるしｗ
何年前からそう思ってる？ その時からみて、状況が目に見えて
改善されてる？
次々とこの業界に入ってくる新人は、そういう教育を受けてきている？
改善されてる？
次々とこの業界に入ってくる新人は、そういう教育を受けてきている？
デザパタも知らんような奴はこの業界に入ってくるな。
知らん奴のせいで一向に状況が改善されない。
知らん奴のせいで一向に状況が改善されない。
>>428
それは拡張可能で再利用可能な業務システムを作ろうとしないからだろ。
どうせ同じような画面で同じようなコードを毎回作っているんだろ？
商品コード入力とかあったとして、それを共通のコントロールにせずに
enter押したときに○○関数を呼び出すという同じコードを
商品コード入力項目があるたびに毎回記述していたりしているだろ。
それは拡張可能で再利用可能な業務システムを作ろうとしないからだろ。
どうせ同じような画面で同じようなコードを毎回作っているんだろ？
商品コード入力とかあったとして、それを共通のコントロールにせずに
enter押したときに○○関数を呼び出すという同じコードを
商品コード入力項目があるたびに毎回記述していたりしているだろ。
オブジェクト指向にはパラダイムシフトが必要だそうだけど、
それはつまり構造化プログラミングの常識を捨てるということ？
上から下へ流れるプログラム、入口と出口が１つずつで、
モジュールの結合度が低いプログラムを捨てて、gotoびしばし
他モジュールに依存しまくりのスパゲッティを作れということ？
「メッセージを介した協調動作」の図とかはその代表っぽいしね。
カプセル化とか、
データと関数を意味のあるひとまとまりとして扱うこととか、
そのまとまりを雛形として複数の実体を作る方法なんかは、
構造化プログラミングの重要な手法だけど、これも捨てちゃって、
クラスに移行するんだよね？
誤解の塊だけど。
ここらが「難しいオブジェクト指向」の根源なんじゃなかろうか。
それはつまり構造化プログラミングの常識を捨てるということ？
上から下へ流れるプログラム、入口と出口が１つずつで、
モジュールの結合度が低いプログラムを捨てて、gotoびしばし
他モジュールに依存しまくりのスパゲッティを作れということ？
「メッセージを介した協調動作」の図とかはその代表っぽいしね。
カプセル化とか、
データと関数を意味のあるひとまとまりとして扱うこととか、
そのまとまりを雛形として複数の実体を作る方法なんかは、
構造化プログラミングの重要な手法だけど、これも捨てちゃって、
クラスに移行するんだよね？
誤解の塊だけど。
ここらが「難しいオブジェクト指向」の根源なんじゃなかろうか。
431 ：仕様書無しさん：04/09/28 15:25:59
>>428
禿げ同
業務アプリのような単純な開発の場合、多少冗長であっても小賢しいテクニックなど使わずに
単純なつくりにしたほうが保守も含めた効率はよい。
このような開発は、開発者個人の判断による特殊な実装は避け、VBのように
ほとんど知識のない人でもいじれる言語で作らせたほうが結局は高品質なものになる。
業務アプリは、元々紙と鉛筆を使って人手で行った作業を、機械化しているだけのもの。
そこにエンジニエリング系の技術を無理やりとりこんでもうまくいかない。
業務アプリは、客とSEとコーダという「事務屋」でつくるもの。事務屋が勘違いして一夜漬けの知識で
「技術屋」のまねごとをしても中途半端なものができるだけ。
禿げ同
業務アプリのような単純な開発の場合、多少冗長であっても小賢しいテクニックなど使わずに
単純なつくりにしたほうが保守も含めた効率はよい。
このような開発は、開発者個人の判断による特殊な実装は避け、VBのように
ほとんど知識のない人でもいじれる言語で作らせたほうが結局は高品質なものになる。
業務アプリは、元々紙と鉛筆を使って人手で行った作業を、機械化しているだけのもの。
そこにエンジニエリング系の技術を無理やりとりこんでもうまくいかない。
業務アプリは、客とSEとコーダという「事務屋」でつくるもの。事務屋が勘違いして一夜漬けの知識で
「技術屋」のまねごとをしても中途半端なものができるだけ。
単純な作り方こそデザインパターンなんだが。
要するに勉強するのが億劫だから初心者の
冗長なやり方をしているとしか思えない。
客にとっては業務アプリプログラマもプログラマ。
プログラミングに詳しいと思って仕事を頼んでいるんだよ。
それにいくら自分が事務屋と思っていてもライバル会社は
事務屋ではない。それでは競争に負ける。
もっとプロ意識持とうね。
要するに勉強するのが億劫だから初心者の
冗長なやり方をしているとしか思えない。
客にとっては業務アプリプログラマもプログラマ。
プログラミングに詳しいと思って仕事を頼んでいるんだよ。
それにいくら自分が事務屋と思っていてもライバル会社は
事務屋ではない。それでは競争に負ける。
もっとプロ意識持とうね。
事務屋には仕事は頼みません。
事務なら私達の方がはるかに詳しいです。
私達にかけている部分。すなわち
ソフトウェアエンジニアに仕事を頼んでいるのです。
ソフトウェアシステム開発のプロとして仕事を頼んでいるのです。
事務屋でいいと思う人たちには仕事は頼みません。
もっとプロ意識を持ってください。
事務なら私達の方がはるかに詳しいです。
私達にかけている部分。すなわち
ソフトウェアエンジニアに仕事を頼んでいるのです。
ソフトウェアシステム開発のプロとして仕事を頼んでいるのです。
事務屋でいいと思う人たちには仕事は頼みません。
もっとプロ意識を持ってください。
>>432
単純ってのが抽象度が高いという意味なら
まさにその通り。
でも業務系は必ずしも抽象度の高さが
作業の単純さには直結しないのよねえー
って話じゃないんですかね。
とはいえ、プロ意識は勿論持った方がいいですな。
単純ってのが抽象度が高いという意味なら
まさにその通り。
でも業務系は必ずしも抽象度の高さが
作業の単純さには直結しないのよねえー
って話じゃないんですかね。
とはいえ、プロ意識は勿論持った方がいいですな。
プロ意識の問題ではなく、
モデリング時に、お客に説明するときに、
デザインパターンが入ったようなモデリングは難解すぎ
お客に「あんた、プロ意識もった方が良いですよ」とか、言うのか？
オブジェクト指向で業務アプリを作る場合には、
あとで、社内SEの人がクラス図シーケンス図を見ても、
理解できないようではだめだろ
実装に近い設計でも、見たらどういう動作なのかを
社内SEや業務担当者などが判別できるように書くべき。
クラス名メソッド名が英語なのがきついんだけどな・・・。
モデリング時に、お客に説明するときに、
デザインパターンが入ったようなモデリングは難解すぎ
お客に「あんた、プロ意識もった方が良いですよ」とか、言うのか？
オブジェクト指向で業務アプリを作る場合には、
あとで、社内SEの人がクラス図シーケンス図を見ても、
理解できないようではだめだろ
実装に近い設計でも、見たらどういう動作なのかを
社内SEや業務担当者などが判別できるように書くべき。
クラス名メソッド名が英語なのがきついんだけどな・・・。
客は、要求するものがどんな方法論で作成されたものであるかなんてことは気にしない。
客は、自ら定義する品質の定義に従った評価を行うだけなんだよ
客は、自ら定義する品質の定義に従った評価を行うだけなんだよ
何言ってんですか >>433
プロ意識が少しでもあれば、業務アプリなんかに関わりませんよ。
業務アプリなんて、ド素人がちょこちょこって入門書読んで、経歴ごまかしてどっかにもぐりこんで、
適当にコピペで作ってるんですよ？
つーか、あんたら客ももうちょっと厳しい目で評価しないと、ますます悪徳SIerのいいカモになるだけでっせ？
プロ意識が少しでもあれば、業務アプリなんかに関わりませんよ。
業務アプリなんて、ド素人がちょこちょこって入門書読んで、経歴ごまかしてどっかにもぐりこんで、
適当にコピペで作ってるんですよ？
つーか、あんたら客ももうちょっと厳しい目で評価しないと、ますます悪徳SIerのいいカモになるだけでっせ？
438 ：仕様書無しさん：04/09/28 17:24:00
>>435
そりは、論理クラス図から設計クラス図というオブジェクト指向設計を
していない。論理クラス図なら、でてくるクラスは業務のキーワードだけ
のはずだ。ほらこのスレでもいきなりコードを乗っける奴がいるだろ。
ちなみに論理クラス図の導出はいわゆる基本設計フェーズだと思うのだが
そもそも基本設計でクラス図を書かかないプロジェクトが少なくない。
で、いきなり実装まで意識したクラス図を作るんだな。これは、ＳＥとかＰＭ
とかの認識不足が問題なので根が深い。結局オブジェクト指向設計なんかしない。
けど、オブジェクト指向プログラミングはやれというのが実情だと思う。
そりは、論理クラス図から設計クラス図というオブジェクト指向設計を
していない。論理クラス図なら、でてくるクラスは業務のキーワードだけ
のはずだ。ほらこのスレでもいきなりコードを乗っける奴がいるだろ。
ちなみに論理クラス図の導出はいわゆる基本設計フェーズだと思うのだが
そもそも基本設計でクラス図を書かかないプロジェクトが少なくない。
で、いきなり実装まで意識したクラス図を作るんだな。これは、ＳＥとかＰＭ
とかの認識不足が問題なので根が深い。結局オブジェクト指向設計なんかしない。
けど、オブジェクト指向プログラミングはやれというのが実情だと思う。
>>435
> モデリング時に、お客に説明するときに、
> デザインパターンが入ったようなモデリングは難解すぎ
いったいなにを説明しようとしているのかと。オブジェクト指向じゃなくても
客に説明するか？アルゴリズムやらソースコードの組み合わせとか。
デザインパターンとはそういうレベルのものだぞ。
> お客に「あんた、プロ意識もった方が良いですよ」とか、言うのか？
プロ意識をもつのは客じゃないくて開発者。
そりゃ客のために客にわかりやすい説明をするのはかまわないさ。
でもわかりやすい説明をするために、デザインパターンの勉強は怠りましたじゃいかんだろ。
客への説明は別にわかりやすい図でもいい。でも開発者同士はもっと確実ものを使うべき。
> あとで、社内SEの人がクラス図シーケンス図を見ても、
> 理解できないようではだめだろ
それでは社内のSEに何を見せる気だ？ クラス図シーケンス図に
変わるものを社内で作ってあるのか？ 実は適当な図を書いているだろ。
例え社内で標準化されていたとしても、社内でしか使えない図だと
他の会社と連携ができない。
> 実装に近い設計でも、見たらどういう動作なのかを
> 社内SEや業務担当者などが判別できるように書くべき。
自分の力を過信しないように。ちゃんと言いたいことが伝わる図などそう簡単には作れない。
自分で作り出したものを相手がきちんと判別できたかなんてわからない。だから共通のものを使う。
> モデリング時に、お客に説明するときに、
> デザインパターンが入ったようなモデリングは難解すぎ
いったいなにを説明しようとしているのかと。オブジェクト指向じゃなくても
客に説明するか？アルゴリズムやらソースコードの組み合わせとか。
デザインパターンとはそういうレベルのものだぞ。
> お客に「あんた、プロ意識もった方が良いですよ」とか、言うのか？
プロ意識をもつのは客じゃないくて開発者。
そりゃ客のために客にわかりやすい説明をするのはかまわないさ。
でもわかりやすい説明をするために、デザインパターンの勉強は怠りましたじゃいかんだろ。
客への説明は別にわかりやすい図でもいい。でも開発者同士はもっと確実ものを使うべき。
> あとで、社内SEの人がクラス図シーケンス図を見ても、
> 理解できないようではだめだろ
それでは社内のSEに何を見せる気だ？ クラス図シーケンス図に
変わるものを社内で作ってあるのか？ 実は適当な図を書いているだろ。
例え社内で標準化されていたとしても、社内でしか使えない図だと
他の会社と連携ができない。
> 実装に近い設計でも、見たらどういう動作なのかを
> 社内SEや業務担当者などが判別できるように書くべき。
自分の力を過信しないように。ちゃんと言いたいことが伝わる図などそう簡単には作れない。
自分で作り出したものを相手がきちんと判別できたかなんてわからない。だから共通のものを使う。
客に見せるのはどんなものにしろ、ユースケースを軸にした図になるよな。
この客に見せる図と、開発に使う設計図で使用される、図の「単位」が同じになるから、
UML/オブクジェクト指向はいいのだよ。
この客に見せる図と、開発に使う設計図で使用される、図の「単位」が同じになるから、
UML/オブクジェクト指向はいいのだよ。
>>440
他スレにもあったけど、
ユースケースは納品物にゃどうなのかなあと思う。
きっちり仕様固めようとしたらユースケース記述を
みっちりかかないといかん。
ユースケースはユースケース図だけじゃ成り立たないから
結局文字だらけになって読んでくれなさそう。
客にユースケース記述しっかり読めってのは
客に「プロ意識持った方がいいですよ」っていうのと
あまり変わらない気がします。
>>439のいってるのが落とし所なんじゃない？
昔ながらのVisioで書いたような図の方がいいと思う。
結構ローカルルールの絵の方が直感的だったりはしますわな。
時々ひどいのもあるけどね。同じ種類の矢印が物の流れだったり
処理の順番だったりで混在してたりとか。
他スレにもあったけど、
ユースケースは納品物にゃどうなのかなあと思う。
きっちり仕様固めようとしたらユースケース記述を
みっちりかかないといかん。
ユースケースはユースケース図だけじゃ成り立たないから
結局文字だらけになって読んでくれなさそう。
客にユースケース記述しっかり読めってのは
客に「プロ意識持った方がいいですよ」っていうのと
あまり変わらない気がします。
>>439のいってるのが落とし所なんじゃない？
昔ながらのVisioで書いたような図の方がいいと思う。
結構ローカルルールの絵の方が直感的だったりはしますわな。
時々ひどいのもあるけどね。同じ種類の矢印が物の流れだったり
処理の順番だったりで混在してたりとか。
>>439
実は、デザインパターンはもう詳細設計だけでなくて
基本設計時の概念モデルでも使おうぜって流れに
なってるんですよこれが。
例えば簡単な例ですまんけど、
ユーザーに管理者と通常ユーザーがあるとして
ユーザーの属性にユーザー区分みたいなのを持つってのは
お客さんも判ると思うんですよ、まだ。
それをStateパターンみたくユーザー区分を別クラスにして
設計すべしとか書いてる本が結構ある。
多分M・ファウラーの影響だね。
勿論納品する仕様書にもその建て付けは書かなきゃいかんわけで
そうなるともうお客さんもオブジェクト指向的な考え方しないと
仕様書からすんなり仕様が浮き上がってこない事態になるんじゃないかと。
そりゃちょっと現実的にどうなのかなって思いますよ。
実は、デザインパターンはもう詳細設計だけでなくて
基本設計時の概念モデルでも使おうぜって流れに
なってるんですよこれが。
例えば簡単な例ですまんけど、
ユーザーに管理者と通常ユーザーがあるとして
ユーザーの属性にユーザー区分みたいなのを持つってのは
お客さんも判ると思うんですよ、まだ。
それをStateパターンみたくユーザー区分を別クラスにして
設計すべしとか書いてる本が結構ある。
多分M・ファウラーの影響だね。
勿論納品する仕様書にもその建て付けは書かなきゃいかんわけで
そうなるともうお客さんもオブジェクト指向的な考え方しないと
仕様書からすんなり仕様が浮き上がってこない事態になるんじゃないかと。
そりゃちょっと現実的にどうなのかなって思いますよ。
だから客にやさしい図を見せて
自分らはちゃんとした図を使えばいいだけじゃん。
客のせいにするなと。
自分らはちゃんとした図を使えばいいだけじゃん。
客のせいにするなと。
> 実は、デザインパターンはもう詳細設計だけでなくて
> 基本設計時の概念モデルでも使おうぜって流れに
> なってるんですよこれが。
手持ちの教科書ではドメインモデリングにはパターンを
つかうなとかいてあるんですが、この流れはどこからきている
んでしょうか。出典の文章(ネットの文章でも可)があれば
教えていただきたいのですが。
> 基本設計時の概念モデルでも使おうぜって流れに
> なってるんですよこれが。
手持ちの教科書ではドメインモデリングにはパターンを
つかうなとかいてあるんですが、この流れはどこからきている
んでしょうか。出典の文章(ネットの文章でも可)があれば
教えていただきたいのですが。
いわれているパターンっていうのはデザインパターンの
ような実装/設計レベルのパターンではなく、分析の
パターン(アナリシスパターン)のことをいっているのでしょうか?
ような実装/設計レベルのパターンではなく、分析の
パターン(アナリシスパターン)のことをいっているのでしょうか?
壊れたドアじゃあるまいし、パタンパタン五月蝿いんだよ！
>>405
ど素人揃いの会社にいるからそう思うんだよ。
GOFのパターンくらい素人でも普通に読めるとおもう。
うちの会社もど素人揃いだけどね。
>>429
そんなソースが金になる以上、技術を学ぶ動機がないんだよ。
人事考課でも技術はほとんど評価されないしね。
だからこの業界はいつまでも腐ったままだよ。
>>430
パラダイムシフトを前面に押し出したのは確かに失敗だったかもね。
>>437
名言だ……。
ど素人揃いの会社にいるからそう思うんだよ。
GOFのパターンくらい素人でも普通に読めるとおもう。
うちの会社もど素人揃いだけどね。
>>429
そんなソースが金になる以上、技術を学ぶ動機がないんだよ。
人事考課でも技術はほとんど評価されないしね。
だからこの業界はいつまでも腐ったままだよ。
>>430
パラダイムシフトを前面に押し出したのは確かに失敗だったかもね。
>>437
名言だ……。
>443
ってことは>440の言は無効、って事でいいのかな。
基本設計書が顧客と開発でダブルスタンダードにするってのは
なかなか豪気な試みと思われます。
>444
これこれ。
http://www.amazon.co.jp/exec/obidos/ASIN/4822221180/qid%3D1096365516/249-6502127-5618747
実務で使うかはさておき、かなり面白かったです。
結局永続化の所で、OODBMSじゃないと、なんて話しになってがっくしが。
他にもどっかで読んだと思う。webかな。
アナパタにもデザインパターンのstateと
同じ形のがあったよ。
責任関係に早速出てくるpower typeってそう思えます。
実装だからデザパタ、分析だからアナパタって
名前を使い分けてるだけで形は一緒だと。
「一気通貫」って言葉好きですよね、オブ指向関連の記事とか。
まさにそういう事でしょう。
ってことは>440の言は無効、って事でいいのかな。
基本設計書が顧客と開発でダブルスタンダードにするってのは
なかなか豪気な試みと思われます。
>444
これこれ。
http://www.amazon.co.jp/exec/obidos/ASIN/4822221180/qid%3D1096365516/249-6502127-5618747
実務で使うかはさておき、かなり面白かったです。
結局永続化の所で、OODBMSじゃないと、なんて話しになってがっくしが。
他にもどっかで読んだと思う。webかな。
アナパタにもデザインパターンのstateと
同じ形のがあったよ。
責任関係に早速出てくるpower typeってそう思えます。
実装だからデザパタ、分析だからアナパタって
名前を使い分けてるだけで形は一緒だと。
「一気通貫」って言葉好きですよね、オブ指向関連の記事とか。
まさにそういう事でしょう。
>> 448
あー。それ持っているし一度精読したよ。けどパターンうんぬんは
全然記憶にない。暇なときに読み返してみます。基本的にこの本
っていい本だよね。
あー。それ持っているし一度精読したよ。けどパターンうんぬんは
全然記憶にない。暇なときに読み返してみます。基本的にこの本
っていい本だよね。
UMLモデリングの本はゴマンとあるが
それをシームレスに実際のコードまでつなげようとしている
本はみたことがないです。
UMLモデリングから実装までのシームレスな開発
というものは単なる幻想にすぎないのでしょうか。
それをシームレスに実際のコードまでつなげようとしている
本はみたことがないです。
UMLモデリングから実装までのシームレスな開発
というものは単なる幻想にすぎないのでしょうか。
>>450
本質を見抜けよこの間抜け！
本質を見抜けよこの間抜け！
452 ：在日外国人参政権反対：04/09/28 19:33:49
＞450
UMLにこだわれば無理かも
UMLもどきとソースの等価的な結合ならできると思う．
UMLにこだわれば無理かも
UMLもどきとソースの等価的な結合ならできると思う．
オブジェクト指向やデザパタみたいな一時のはやりもんに
物作り職人たる俺たちが安易に迎合するのはどうかと思うな。
思想の一つであって、決して実践的なソリューションではないからね。
むしろパターンに縛られて視野を狭くする危険性がある。
物作り職人たる俺たちが安易に迎合するのはどうかと思うな。
思想の一つであって、決して実践的なソリューションではないからね。
むしろパターンに縛られて視野を狭くする危険性がある。
>>453
何才でつか？どちらかと言うと、アンチパターンを適用して、視野を狭くしている希ガス
何才でつか？どちらかと言うと、アンチパターンを適用して、視野を狭くしている希ガス
ここで熱弁されているレベルの話はそろそろコンセンサスにして、
さっさと次のステップに進みたいものだな。
一所懸命語ってるうちは駄目でしょ
業務用件のキャプチャーの方がオブジェクト指向やらパターンやらよりよっぽどむずい
さっさと次のステップに進みたいものだな。
一所懸命語ってるうちは駄目でしょ
業務用件のキャプチャーの方がオブジェクト指向やらパターンやらよりよっぽどむずい
>>450
「単なる幻想」でないことを証明するのは君だ！
社会人になったら、そんなことをする時間はない。
UMLを書いたら、「まともな」コードが生成されるツールを開発したら、君は億万長者だ。
期待してるよ！
「単なる幻想」でないことを証明するのは君だ！
社会人になったら、そんなことをする時間はない。
UMLを書いたら、「まともな」コードが生成されるツールを開発したら、君は億万長者だ。
期待してるよ！
459 ：仕様書無しさん：04/09/29 01:30:50
>>業務用件のキャプチャーの方がオブジェクト指向やらパターンやらよりよっぽどむずい
ほら、また別々で考えてる。だからだめなんだよ。
ほら、また別々で考えてる。だからだめなんだよ。
460 ：仕様書無しさん：04/09/29 01:36:54
いやそれは別々なんじゃ。。
少しレベルが違う話の気がする
少しレベルが違う話の気がする
>>449
デザパタ、アナパタに関する記述が
ちょこちょこ出てきてますね。
特にアナパタ読んでもいまいちはっきりしなかった
部分がかなりわかり易く書いてあって
勉強になりました。
でも、実践するかというと、やっぱりなあ。
OODBなんてオッケー出るはずもないし
積極的に本番で使いたいとは思わないしなあ。
デザパタ、アナパタに関する記述が
ちょこちょこ出てきてますね。
特にアナパタ読んでもいまいちはっきりしなかった
部分がかなりわかり易く書いてあって
勉強になりました。
でも、実践するかというと、やっぱりなあ。
OODBなんてオッケー出るはずもないし
積極的に本番で使いたいとは思わないしなあ。
>>448
俺もその本読んだ。かなり勉強になった。
俺もその本読んだ。かなり勉強になった。
463 ：仕様書無しさん：04/10/01 00:59:55
>>UMLを書いたら、「まともな」コードが生成されるツールを開発したら、君は億万長者だ。
そげなもん、もう売ってるで、
そげなもん、もう売ってるで、
>463
おまえじゃ釣れないな
おまえじゃ釣れないな
465 ：仕様書無しさん：04/10/01 15:35:16
漏れの会社では中国に実装をまかしてるんだけど、
実装するとクラスが増えたりするから、こっちにもってきたらＵＭＬツール
でコードからクラス図生成させてそれを納品ドキュメントにするんだぜ。
そのソフトは一本１００万くらいするらしいね。
実装するとクラスが増えたりするから、こっちにもってきたらＵＭＬツール
でコードからクラス図生成させてそれを納品ドキュメントにするんだぜ。
そのソフトは一本１００万くらいするらしいね。
>465
納品ドキュメントにクラス図ってなんだよｗ
そんなのほしがる客いねーだろ
派遣先ってことか？
納品ドキュメントにクラス図ってなんだよｗ
そんなのほしがる客いねーだろ
派遣先ってことか？
おいおい、クラス図は普通に納品物だよ。
顧客に必要なさそうでも、コンサルが要求してくるからね。
ちっちゃいプロジェクトばかりやってきたんだね・・・
顧客に必要なさそうでも、コンサルが要求してくるからね。
ちっちゃいプロジェクトばかりやってきたんだね・・・
うちはソースを納品しないので
当たり前のようにクラス図なんぞ要求されない
ソースを納品するなら要求されても
仕方ないと思う
ソースを納品しないのにクラス図納品ってのは
なんの役に立つのか分からないな
当たり前のようにクラス図なんぞ要求されない
ソースを納品するなら要求されても
仕方ないと思う
ソースを納品しないのにクラス図納品ってのは
なんの役に立つのか分からないな
ソース納品しないんだぁ
471 ：仕様書無しさん：04/10/02 00:38:47
おまえらクラス図も作らずオブジェクト指向か？
472 ：仕様書無しさん：04/10/02 02:23:36
え、ソース納品するの?
そんなの、この数年やったことない。
(perl, php, jsp, asp など以外)
保守でも、儲けようぜ
そんなの、この数年やったことない。
(perl, php, jsp, asp など以外)
保守でも、儲けようぜ
プロトタイプベースOOの場合はクラス図って作るのかね。
>>471
現在主流の C++ や Java がクラスベースのオブジェクト指向言語だから
UML でもクラス図ってのがあるけど、本来オブジェクト指向とクラスとは関係ないもの
(というかクラスなんかがあるほうがオブジェクト指向としては不自然)。
効率その他の面からクラスベースの方が主流なのは仕方ないがな。
現在主流の C++ や Java がクラスベースのオブジェクト指向言語だから
UML でもクラス図ってのがあるけど、本来オブジェクト指向とクラスとは関係ないもの
(というかクラスなんかがあるほうがオブジェクト指向としては不自然)。
効率その他の面からクラスベースの方が主流なのは仕方ないがな。
インスタンスベースってJavaで言うところの無名クラスだっけ？
だとするとインスタンスと同じだけクラスがあるようなかんじ？
だとするとインスタンスと同じだけクラスがあるようなかんじ？
477 ：仕様書無しさん：04/10/02 04:12:03
あんたの言ってるオブジェクト指向って、超次元に存在するのかい。
ＰＧの漏れらが必死でクラスを作っていうるとき、「うーん、違うなー」って言ってるだろ。
まぁ、いいや、いずれにしても漏れら下っ端ＰＧはクラス作らねーと仕事が終わんねーだよ。
ＰＧの漏れらが必死でクラスを作っていうるとき、「うーん、違うなー」って言ってるだろ。
まぁ、いいや、いずれにしても漏れら下っ端ＰＧはクラス作らねーと仕事が終わんねーだよ。
結局、誰のためのオブジェクト指向なのか漏れには分かりません。
479 ：仕様書無しさん：04/10/02 09:58:45
愛の為さ
なるほど。プログラマのためになると、
プログラムの質が向上したり開発スピードが上がったりして
それがユーザの為になるわけですか。
プログラムの質が向上したり開発スピードが上がったりして
それがユーザの為になるわけですか。
納得できるな。
オブジェクト指向っていうのは、
Win2000⇒WinXP
と似ている。
違いといえば、
動作が重いこと、実はわかりずらくなったこと
実に似ている・・・・。
オブジェクト指向っていうのは、
Win2000⇒WinXP
と似ている。
違いといえば、
動作が重いこと、実はわかりずらくなったこと
実に似ている・・・・。
485 ：仕様書無しさん：04/10/03 01:43:37
「オブジェクト指向的に作られたモノ」は、
「非オブジェクト指向で作られたモノ」に比べて非常に分かりやすい。
オブジェクト指向的には作られていないモノを、
オブジェクト指向的に作られているように想定して理解しようとすると、とても難しい。
「非オブジェクト指向で作られたモノ」に比べて非常に分かりやすい。
オブジェクト指向的には作られていないモノを、
オブジェクト指向的に作られているように想定して理解しようとすると、とても難しい。
クラス設計して作っても再利用したことあんまないね（´･∀･｀）
Javaなんかでも再利用可能なクラスはほとんど標準APIになってるからな
しかしへっぽこな自作クラスを処理の統一と称して再利用したがるアフォも居る罠
まぁうちの上司のことなんだが・・・（鬱
しかしへっぽこな自作クラスを処理の統一と称して再利用したがるアフォも居る罠
まぁうちの上司のことなんだが・・・（鬱
488 ：仕様書無しさん：04/10/03 06:37:45
「オブジェクト指向」って「愛」という言葉と同じで、
人によって捉え方が違うのさ
人によって捉え方が違うのさ
俺みたいな脳みそのスタックが一段しかない人間には
オブジェクト指向は激しく向いてない。
クラスの数だけ、メンバ変数とかコンストラクタとか親とか子とか
アクセス修飾とか、余計な能書きをクラス間の依存関係と共に
脳内スタックに積まなきゃいかん。これはキツイ。
やっぱCが一番楽だ。やりたい処理だけをズラズラ書けばよい。
オブジェクト指向は激しく向いてない。
クラスの数だけ、メンバ変数とかコンストラクタとか親とか子とか
アクセス修飾とか、余計な能書きをクラス間の依存関係と共に
脳内スタックに積まなきゃいかん。これはキツイ。
やっぱCが一番楽だ。やりたい処理だけをズラズラ書けばよい。
公開されていないメンバやメソッドは脳内スタックにつまなくてもいいぞ。
利用するだけであれば publicメソッドだけ覚えとけばOK。
利用するだけであれば publicメソッドだけ覚えとけばOK。
491 ：仕様書無しさん：04/10/03 16:51:35
privateメソッド見てデバックでもしてるの？
492 ：仕様書無しさん：04/10/03 18:28:45
はっきり言うが、オブジェクト指向は簡単すぎ
>公開されていないメンバやメソッドは脳内スタックにつまなくてもいいぞ。
>利用するだけであれば publicメソッドだけ覚えとけばOK。
下手な奴はそれが見えてないから、publicだらけのクラス書くんだよな。
あんなクラス読めるかっての。
>利用するだけであれば publicメソッドだけ覚えとけばOK。
下手な奴はそれが見えてないから、publicだらけのクラス書くんだよな。
あんなクラス読めるかっての。
>>490
んー、そこんとこ俺はダメなんだよね。
privateで隠すということは、他のクラスから見られたくない
何らかの「まずい関係」があるわけでしょ。
だって見られてもいいなら全てpublicでいいわけだからね。
その関係が気になって、全てのクラスの関係を親まで遡って
調査してしまうんだよね。JavaのAPIも含めて。
するとすぐに脳内がパンクする。
んー、そこんとこ俺はダメなんだよね。
privateで隠すということは、他のクラスから見られたくない
何らかの「まずい関係」があるわけでしょ。
だって見られてもいいなら全てpublicでいいわけだからね。
その関係が気になって、全てのクラスの関係を親まで遡って
調査してしまうんだよね。JavaのAPIも含めて。
するとすぐに脳内がパンクする。
>>494
カプセルの基本から勉強しなおした方がいいぞ
べつに「まずい関係」を隠すためにprivateで隠蔽してるわけじゃない
外部から直接いじらせないことで
設計者の意図しないオブジェクトの状態を避けるとかいろいろ目的はあるだろ？
カプセルの基本から勉強しなおした方がいいぞ
べつに「まずい関係」を隠すためにprivateで隠蔽してるわけじゃない
外部から直接いじらせないことで
設計者の意図しないオブジェクトの状態を避けるとかいろいろ目的はあるだろ？
誤字スマソ
×カプセル
○カプセル化
×カプセル
○カプセル化
>>下手な奴はそれが見えてないから、publicだらけのクラス書くんだよな。
下手とかいう以前の問題な希ガス
アクセス修飾子を全く理解してないとか・・・
下手とかいう以前の問題な希ガス
アクセス修飾子を全く理解してないとか・・・
>>494
OOじゃない設計でも、例えばコンポーネント化、モジュール化なんてしてれば
公開するインタフェースと公開しないインタフェースの二つに分かれるでしょ。
非公開部分で何をしていようが、公開部分だけ知っていればそいつを利用できる。
OOもそうでないのも、再利用性とか考えたときの公開、非公開の制御方法が
増えただけで、本質的な違いは無いよ。
そういうブラックボックス化になじめなくて、中まで知らないと心配で使えないってんなら
まあ、それまでだけど。
>>499
アクセス修飾子などの構文的な意味は理解してるんじゃないの?
なんでそうするのかが理解できてないだけで。
OOじゃない設計でも、例えばコンポーネント化、モジュール化なんてしてれば
公開するインタフェースと公開しないインタフェースの二つに分かれるでしょ。
非公開部分で何をしていようが、公開部分だけ知っていればそいつを利用できる。
OOもそうでないのも、再利用性とか考えたときの公開、非公開の制御方法が
増えただけで、本質的な違いは無いよ。
そういうブラックボックス化になじめなくて、中まで知らないと心配で使えないってんなら
まあ、それまでだけど。
>>499
アクセス修飾子などの構文的な意味は理解してるんじゃないの?
なんでそうするのかが理解できてないだけで。
>>494
＞だって見られてもいいなら全てpublicでいいわけだからね。
マイクロソフトがWindowsの全てのコードをpublicに公開しないのは
見られたらやばいものがあるからだ、と言いたいのですね?
＞その関係が気になって、全てのクラスの関係を親まで遡って
＞調査してしまうんだよね。JavaのAPIも含めて。
＞するとすぐに脳内がパンクする。
windowsでのプログラミングなんてとても出来ないですね。
全てのAPI呼び出しをI/Oポート操作まで遡って調査してたら
HelloWorldすら書けやしない。
君のレスは、オブジェクト指向以前の問題。
＞だって見られてもいいなら全てpublicでいいわけだからね。
マイクロソフトがWindowsの全てのコードをpublicに公開しないのは
見られたらやばいものがあるからだ、と言いたいのですね?
＞その関係が気になって、全てのクラスの関係を親まで遡って
＞調査してしまうんだよね。JavaのAPIも含めて。
＞するとすぐに脳内がパンクする。
windowsでのプログラミングなんてとても出来ないですね。
全てのAPI呼び出しをI/Oポート操作まで遡って調査してたら
HelloWorldすら書けやしない。
君のレスは、オブジェクト指向以前の問題。
>>494は、
JavaのAPIを含めて親までたどらないと気がすまない
→JavaVMの挙動が気になる
→JavaVMのソースを見る
→JavaVMの実行バイナリが気になる
→実行バイナリを見る
→以下、分子レベルまでさかのぼる…
ということにはならないだろ？
その理由は、オブジェクトとして背景の構造を隠蔽しているから。
隠蔽してブラックボックスにしたほうが簡単だろ？
たかだかJavaAPIより後ろを隠蔽していながら、
どうしてJavaAPI内部でそれができないんだ。
JavaのAPIを含めて親までたどらないと気がすまない
→JavaVMの挙動が気になる
→JavaVMのソースを見る
→JavaVMの実行バイナリが気になる
→実行バイナリを見る
→以下、分子レベルまでさかのぼる…
ということにはならないだろ？
その理由は、オブジェクトとして背景の構造を隠蔽しているから。
隠蔽してブラックボックスにしたほうが簡単だろ？
たかだかJavaAPIより後ろを隠蔽していながら、
どうしてJavaAPI内部でそれができないんだ。
504 ：仕様書無しさん：04/10/05 11:04:55
みんな知らないうちにファサードパターン使ってんだよ
505 ：仕様書無しさん：04/10/05 11:42:57
○○パターンとかいって、使い慣れない単語の付いた、中身と名前の関連が
分かりにくい事を丸暗記せなあかんのか・・・ ウザいのぉ・・・ だれか日本語
に直してくれや・・・
分かりにくい事を丸暗記せなあかんのか・・・ ウザいのぉ・・・ だれか日本語
に直してくれや・・・
506 ：仕様書無しさん：04/10/05 11:54:43
実生活に置き換えれる、オブジェクト指向がわからん香具師は、
実生活でもマヌケなことをやっているんだろうな。
実生活でもマヌケなことをやっているんだろうな。
>>507
松葉くずしは何パターンに該当しますか？
松葉くずしは何パターンに該当しますか？
>>508
【松葉くずし】インタフェース
【松葉くずし】インタフェース
>>505
＞使い慣れない単語の付いた
これはデザパタの問題じゃなくて言語の問題だな。
デザパタの名前はあくまでも英語圏の人間にとって
わかりやすいようになっているからな。
建築機パターンとか訪問者パターンとか呼べば?
＞使い慣れない単語の付いた
これはデザパタの問題じゃなくて言語の問題だな。
デザパタの名前はあくまでも英語圏の人間にとって
わかりやすいようになっているからな。
建築機パターンとか訪問者パターンとか呼べば?
パターンは日本語にしないんかい
おめーらモジュール名日本語にするんかい？
いくらなんでもパターンを暗記する必要はないと思うけど。
暗記するつーのははWindowsプログラミングをするのに
Win32API全部暗記するのと一緒だぞ。
実際につかうときや話にでたときに本を読めば済むこと。
とりあえずGoFの本買ってきてざっと読んでエッセンスだけ
わかったら後は本棚の肥やしにでもしとけばいい。
実際によくつかうデザインパターンってそんなに多くないし
やってるうちに自然と覚えてくるもんだぞ。
暗記するつーのははWindowsプログラミングをするのに
Win32API全部暗記するのと一緒だぞ。
実際につかうときや話にでたときに本を読めば済むこと。
とりあえずGoFの本買ってきてざっと読んでエッセンスだけ
わかったら後は本棚の肥やしにでもしとけばいい。
実際によくつかうデザインパターンってそんなに多くないし
やってるうちに自然と覚えてくるもんだぞ。
514 ：仕様書無しさん：04/10/05 23:07:42
おまっ、マジすげぇーョ！！！こんなスレたてるなんてさ。
できねえよ凡人の俺にはさ。まじキレテルョ。
エッジ効いてるよおまっ！きっとお前は盗んだバイクで走るんだろうな。
俺には出来ねェョ！！！ うまく言えねぇけどこのスゴさってなんだろう？
「北斗の拳」でいう闘気？「聖闘士星矢」でいう小宇宙？
「頭文字D」でいうオーラ？「セーラームーン」でいうエナジー？
「Zガンダム」でいう最終回のアレ？「Vガンダム」でいう最終回のアレ？
「ドラゴンボール」でいうかめはめ波？「ジャイアントロボ」でいうビッグバンパンチ？
「るろうに剣心」でいう天賭ける龍の閃き？「Gガンダム」でいうハイパーモード？
「マクロス７」でいうアニマスピリチア？お母さんって呼んでいいデスカ。
ていうか俺さー、実はここ１週間ずうっとみんなが楽しめる楽しいスレッド
を立てようって考えていたんだよね。
毎日毎日ひたすら考えていてさあ、でも全然思い付かないんだよね。
やっぱり俺の才能じゃ、そういう楽しいスレッド立てるのって無理なんだろうなあって、
あきらめたとこなんだよ。
それなのにさ、今ここ見たら、どうよ。こんな面白いスレッドが立ってるじゃない。
ホントびっくりしたよね。マジ、え、ホント、こんな面白いスレッド立てられる奴
がいたのかよーって、マジで驚いたよ。すごいね、あんたマジですごいよ。最高だよ。
どうやったらこんな面白いスレッドを思いつくんだろう。感心しちゃうよ。
俺じゃ絶対無理だよ。不可能だよ。あんた天才だよ。すごすぎるよ。
ホント才能がスレッドの題名にあふれ出てるよ。並じゃないよ。とび抜けた才能だよ。
こんな才能の持ち主がどうして２chなんかにいるのか不思議になっちゃたよ。
ホント、俺あんたに惚れたよ。あんたの立てるスレッドをもっと見てみたいよ。
もっといっぱい立ててよ。この板をあんたのスレッドで埋め尽くしてくれよ。
そしたら、ここも盛り上がるよ。きっとあんたの立てたスレッドを見に世界中の人たちが
やってくるよ。インド人もやってくるよ。中国人だって見に来るよ。アメリカ人だって、
ホント世界中の人たちがここに集まってくるよ。みんなあんたの立てたスレッドに驚嘆するよ。
ニッポン人にもこんなすごい奴がいるのかってみんな感心するよ。
できねえよ凡人の俺にはさ。まじキレテルョ。
エッジ効いてるよおまっ！きっとお前は盗んだバイクで走るんだろうな。
俺には出来ねェョ！！！ うまく言えねぇけどこのスゴさってなんだろう？
「北斗の拳」でいう闘気？「聖闘士星矢」でいう小宇宙？
「頭文字D」でいうオーラ？「セーラームーン」でいうエナジー？
「Zガンダム」でいう最終回のアレ？「Vガンダム」でいう最終回のアレ？
「ドラゴンボール」でいうかめはめ波？「ジャイアントロボ」でいうビッグバンパンチ？
「るろうに剣心」でいう天賭ける龍の閃き？「Gガンダム」でいうハイパーモード？
「マクロス７」でいうアニマスピリチア？お母さんって呼んでいいデスカ。
ていうか俺さー、実はここ１週間ずうっとみんなが楽しめる楽しいスレッド
を立てようって考えていたんだよね。
毎日毎日ひたすら考えていてさあ、でも全然思い付かないんだよね。
やっぱり俺の才能じゃ、そういう楽しいスレッド立てるのって無理なんだろうなあって、
あきらめたとこなんだよ。
それなのにさ、今ここ見たら、どうよ。こんな面白いスレッドが立ってるじゃない。
ホントびっくりしたよね。マジ、え、ホント、こんな面白いスレッド立てられる奴
がいたのかよーって、マジで驚いたよ。すごいね、あんたマジですごいよ。最高だよ。
どうやったらこんな面白いスレッドを思いつくんだろう。感心しちゃうよ。
俺じゃ絶対無理だよ。不可能だよ。あんた天才だよ。すごすぎるよ。
ホント才能がスレッドの題名にあふれ出てるよ。並じゃないよ。とび抜けた才能だよ。
こんな才能の持ち主がどうして２chなんかにいるのか不思議になっちゃたよ。
ホント、俺あんたに惚れたよ。あんたの立てるスレッドをもっと見てみたいよ。
もっといっぱい立ててよ。この板をあんたのスレッドで埋め尽くしてくれよ。
そしたら、ここも盛り上がるよ。きっとあんたの立てたスレッドを見に世界中の人たちが
やってくるよ。インド人もやってくるよ。中国人だって見に来るよ。アメリカ人だって、
ホント世界中の人たちがここに集まってくるよ。みんなあんたの立てたスレッドに驚嘆するよ。
ニッポン人にもこんなすごい奴がいるのかってみんな感心するよ。
オブジェクト指向を採用した結果、従来の開発手法に比べ
何か具体的なメリット・成果が得られたという実例はある？
概念ばかりで実用性に薄い技術であるなら、
これから学ぼうとする人にとって時間の無駄だと思うんだが。
何か具体的なメリット・成果が得られたという実例はある？
概念ばかりで実用性に薄い技術であるなら、
これから学ぼうとする人にとって時間の無駄だと思うんだが。
他人のふんどしパターン ： 他人の書いたコードをそのままコピペ
おいらいきなりコーディング型C++のパッケージPG。
新期開発もやりながらだけど、三ヶ月くらいで書いた7万行くらいのコードをメンテしてる。
三ヶ月っても家に帰っても同じコードいじり続けてるから実質6か月分くらいはコード書いてたかもね。
リファクタリングと組み合わせることで、将来あるかもしれない拡張への対策コストが必要なくなり
実際に拡張する段階になっても、柔軟かつ安全に拡張しやすい形に内部仕様を変更できた。
もちろん拡張にかかるコストはかなり低く。
最初はひどかったな。勢いだけだったし。
内部設計はずいぶん変わったけど、品質を落とさないまま大規模な仕様変更も受け入れてる。
コードは減ったよ。半分くらいに。ははは。
ロジックをどんどん外部定義に追い出してって、中には構文解析ロジックとカーネル、それと
どうしても泥臭くてはずせない部分だけ残った。
仕事は忙しいけど、ほとんどの時間趣味のリファクタリング。余った時間とか気が向いたときに
本業の開発とか拡張作業やってる。工数的にもモンク言われたことはないな。
こないだも開発計画に無かったけど性能改善しといた。
ホットスポット見つけてオブジェクトを切り分け複雑度を落としてから、ずばっと重い部分を直す。
設計レベルのメリットはいまいち享受してない気もするが、Cでゴリゴリ書いてたころに比べると
設計者や開発者の負担が減ったんじゃないかと思う。
三日前にいじったクラスは、もう覚えてない。けど、公開メソッドと貧弱なコメント、コードを眺めれば
「そのとき知らなきゃいけない事項｣はすぐに思い出す。必要になるまではその分忘れててOK。
そう、俺みたいな馬鹿でもそれなりに仕事できた気になるよ。
新期開発もやりながらだけど、三ヶ月くらいで書いた7万行くらいのコードをメンテしてる。
三ヶ月っても家に帰っても同じコードいじり続けてるから実質6か月分くらいはコード書いてたかもね。
リファクタリングと組み合わせることで、将来あるかもしれない拡張への対策コストが必要なくなり
実際に拡張する段階になっても、柔軟かつ安全に拡張しやすい形に内部仕様を変更できた。
もちろん拡張にかかるコストはかなり低く。
最初はひどかったな。勢いだけだったし。
内部設計はずいぶん変わったけど、品質を落とさないまま大規模な仕様変更も受け入れてる。
コードは減ったよ。半分くらいに。ははは。
ロジックをどんどん外部定義に追い出してって、中には構文解析ロジックとカーネル、それと
どうしても泥臭くてはずせない部分だけ残った。
仕事は忙しいけど、ほとんどの時間趣味のリファクタリング。余った時間とか気が向いたときに
本業の開発とか拡張作業やってる。工数的にもモンク言われたことはないな。
こないだも開発計画に無かったけど性能改善しといた。
ホットスポット見つけてオブジェクトを切り分け複雑度を落としてから、ずばっと重い部分を直す。
設計レベルのメリットはいまいち享受してない気もするが、Cでゴリゴリ書いてたころに比べると
設計者や開発者の負担が減ったんじゃないかと思う。
三日前にいじったクラスは、もう覚えてない。けど、公開メソッドと貧弱なコメント、コードを眺めれば
「そのとき知らなきゃいけない事項｣はすぐに思い出す。必要になるまではその分忘れててOK。
そう、俺みたいな馬鹿でもそれなりに仕事できた気になるよ。
>>517
たぶん入社1年目の新人・・・がんばっているね。
その心意気を長年持ち続けてくれよ。
顧客に言われないことでも、進んでやるってのは個人的に好感が持てますね。
そのかわりそれでトラブルが起きたら・・・たぶん首・・・。
たぶん入社1年目の新人・・・がんばっているね。
その心意気を長年持ち続けてくれよ。
顧客に言われないことでも、進んでやるってのは個人的に好感が持てますね。
そのかわりそれでトラブルが起きたら・・・たぶん首・・・。
>517
つまらん
ネタにもならねー
つまらん
ネタにもならねー
520 ：仕様書無しさん：04/10/06 02:37:21
（´∀｀|Д・)っ|） ＜これでも一応10数年やってるんだけどね。
パッケージ開発には大体どこにも魔物が一人か二人はいるもんだよ。
漏れが、とは言わんが。
パッケージ開発には大体どこにも魔物が一人か二人はいるもんだよ。
漏れが、とは言わんが。
522 ：仕様書無しさん：04/10/06 08:24:52
>>517
> リファクタリングと組み合わせることで、将来あるかもしれない拡張への対策コストが必要なくなり
> 実際に拡張する段階になっても、柔軟かつ安全に拡張しやすい形に内部仕様を変更できた。
> もちろん拡張にかかるコストはかなり低く。
って、ちゃんと CppUnit 使ってるわけ？
> リファクタリングと組み合わせることで、将来あるかもしれない拡張への対策コストが必要なくなり
> 実際に拡張する段階になっても、柔軟かつ安全に拡張しやすい形に内部仕様を変更できた。
> もちろん拡張にかかるコストはかなり低く。
って、ちゃんと CppUnit 使ってるわけ？
ちゃんとじゃないけど使ってるよ。
GUIは他の人に任せてるから、担当分はほとんどUTの対象になるし。
100% UTを適用してるわけじゃない。
テストコードの書き方によると思うけど、UTが効くのは細かいリファクタリングのときだけ。
データモデルに変更を加えたときなんかだと、テストコードの変更にかける時間の方が
長くなって逆に作業が遅くなる。
だから、大きなブロックレベルでの最終的なアウトプットだけ保障できるような
UTを行ってる。
そういう意味ではほんとの意味でのUTじゃないな。
CppUnitが無いころもリファクタリングっぽいことやってたけど、作業ミスによる
デグレが結構あったね。
いじる->拡張->テストでNG->アー、ここ間違えてた
ってサイクルだけど、手は早いほうなんでスケジュールに悪影響は出なかったな。
まあ、それでも手戻りが減った分作業効率が格段に上がってるよ。
GUIは他の人に任せてるから、担当分はほとんどUTの対象になるし。
100% UTを適用してるわけじゃない。
テストコードの書き方によると思うけど、UTが効くのは細かいリファクタリングのときだけ。
データモデルに変更を加えたときなんかだと、テストコードの変更にかける時間の方が
長くなって逆に作業が遅くなる。
だから、大きなブロックレベルでの最終的なアウトプットだけ保障できるような
UTを行ってる。
そういう意味ではほんとの意味でのUTじゃないな。
CppUnitが無いころもリファクタリングっぽいことやってたけど、作業ミスによる
デグレが結構あったね。
いじる->拡張->テストでNG->アー、ここ間違えてた
ってサイクルだけど、手は早いほうなんでスケジュールに悪影響は出なかったな。
まあ、それでも手戻りが減った分作業効率が格段に上がってるよ。
524 ：仕様書無しさん：04/10/06 09:01:05
最近、マ板の技術・言語議論スレ痛すぎ。
っていうか、ム板でやれ。
っていうか、ム板でやれ。
痛い議論はマ板でやるのがマナーでは？
>>525
(´-`).｡ｏＯ（最近？）
(´-`).｡ｏＯ（最近？）
>525
ここは落ちこぼれのくせにうんちく語りたがりが集まるスレだが？
ここは落ちこぼれのくせにうんちく語りたがりが集まるスレだが？
529 ：仕様書無しさん：04/10/07 00:18:57
オブジェクト指向とはつまり機能とかプログラムとかはとりあえず忘れて
実世界についてを考えよう、という方法です。
実世界で使われる概念を「オブジェクト」としてきちんと定義して、
それがどんなものかを明確にしようという考え方です。
いったん概念が明確になってしまえば、その間の関係や機能や動作は
すらすらと出てきます。オブジェクトは「機能のまとまり」ではありません。
「概念のまとまり」なのです。「機能」はとりあえず忘れよう、
というのが合言葉であることを忘れてはいけません。
オブジェクト指向に限らず、システムはシンプルイズベストです。
問題を領域に分け、その領域の中で必要かつ十分な定義をします。
慣れてくると実世界をより精密にモデリングしようとたくさんの
オブジェクトを含んだ図を書いてしまいがちですが、
それが対象領域(ドメイン)にとって本当に必要なのかを
取捨選択しなければなりません。たくさんオブジェクトを定義して
複雑なモデルを作るより、少ないオブジェクトでシンプルな定義をする方が
ずっと有用なのです。
実世界についてを考えよう、という方法です。
実世界で使われる概念を「オブジェクト」としてきちんと定義して、
それがどんなものかを明確にしようという考え方です。
いったん概念が明確になってしまえば、その間の関係や機能や動作は
すらすらと出てきます。オブジェクトは「機能のまとまり」ではありません。
「概念のまとまり」なのです。「機能」はとりあえず忘れよう、
というのが合言葉であることを忘れてはいけません。
オブジェクト指向に限らず、システムはシンプルイズベストです。
問題を領域に分け、その領域の中で必要かつ十分な定義をします。
慣れてくると実世界をより精密にモデリングしようとたくさんの
オブジェクトを含んだ図を書いてしまいがちですが、
それが対象領域(ドメイン)にとって本当に必要なのかを
取捨選択しなければなりません。たくさんオブジェクトを定義して
複雑なモデルを作るより、少ないオブジェクトでシンプルな定義をする方が
ずっと有用なのです。
>>529
今頃なにいってんのおまいは
今頃なにいってんのおまいは
531 ：仕様書無しさん：04/10/07 00:22:25
どっかからのコピペじゃないの？
実務こなしてたら
恥ずかしくてこんな事いえないよねえ。
実務こなしてたら
恥ずかしくてこんな事いえないよねえ。
俺は記憶力がザルなんで、クソ長いメソッド読めば最初のほうは覚えてないし、
else ifだのcaseだので分岐が増えると把握しきれなくなる。
ある程度きちんとオブジェクト指向でコードが書けるようになって、自分のソースを
追うのが格段に楽になったんだが、これだけでもオブジェクト指向じゃないのかな。
逆に汚いコード書いてる連中見てると、「よくこんな腐れコード把握できるよな」って感心する。
よっぽど頭よくないとあんなのメンテ不能だと思うんだが。
else ifだのcaseだので分岐が増えると把握しきれなくなる。
ある程度きちんとオブジェクト指向でコードが書けるようになって、自分のソースを
追うのが格段に楽になったんだが、これだけでもオブジェクト指向じゃないのかな。
逆に汚いコード書いてる連中見てると、「よくこんな腐れコード把握できるよな」って感心する。
よっぽど頭よくないとあんなのメンテ不能だと思うんだが。
×これだけでもオブジェクト指向じゃないのかな。
○これだけでもオブジェクト指向のメリットじゃないのかな。
何書いてるんだ、俺・・・
○これだけでもオブジェクト指向のメリットじゃないのかな。
何書いてるんだ、俺・・・
>>531
おまえは実世界というのをそのまんまに捕らえすぎ
おまえは実世界というのをそのまんまに捕らえすぎ
>533
たぶんおまえが低レベルすぎるんだろ。
PGやめたほうがいいな。
たぶんおまえが低レベルすぎるんだろ。
PGやめたほうがいいな。
>533
汚いコードに苦情言ったとき、
そんな返され方したらブチ切れますよ？
汚いコードに苦情言ったとき、
そんな返され方したらブチ切れますよ？
538 ：仕様書無しさん：04/10/07 19:37:14
×>533
○>536
○>536
>>537
ぶち切れて辞めてくれたらこっちも正論を言った甲斐があるってもんだ
ぶち切れて辞めてくれたらこっちも正論を言った甲斐があるってもんだ
なぜこんな簡単な物がわからんのだろうか。
俺なんか消防のころ。ぜんぜんプログラムがわからんうちから
オブジェクト指向でやろうとしていたぜ。
上から、頭、肩、胸、手、体、尻、足、とオブジェクトを
配置していけば、女の子の裸が拝めるはずだと。
俺なんか消防のころ。ぜんぜんプログラムがわからんうちから
オブジェクト指向でやろうとしていたぜ。
上から、頭、肩、胸、手、体、尻、足、とオブジェクトを
配置していけば、女の子の裸が拝めるはずだと。
オブジェクト指向でないと「きれいなコード」は書けない
とまでは言わんよな
とまでは言わんよな
OOでも粒度をうまくコントロールしないと目も当てられない様に
544 ：仕様書無しさん：04/10/07 22:26:37
つまりオブジェクト指向って関数の再利用だよな
>>544
その手の餌には誰も食いつかないよ
その手の餌には誰も食いつかないよ
546 ：仕様書無しさん：04/10/07 22:34:01
そうでしたか
すれ汚しｽﾏｿ
すれ汚しｽﾏｿ
オブジェクト指向は多態が全てだと思う。
いや、まあ全部じゃないけど、ほとんどというか
多態便利だよ多態
いや、まあ全部じゃないけど、ほとんどというか
多態便利だよ多態
>547
モデリング経験してから言え
モデリング経験してから言え
＞547
いや同意。
田態するようにしてくとおのずから再利用できるようにもなるしきれいにモデル作るようにできるってことを言いたいんだよね?
いや同意。
田態するようにしてくとおのずから再利用できるようにもなるしきれいにモデル作るようにできるってことを言いたいんだよね?
オブジェクト指向はカプセル化が全てだと思う。
いや、まあ全部じゃないけど、ほとんどというか
カプセル化便利だよカプセル化
いや、まあ全部じゃないけど、ほとんどというか
カプセル化便利だよカプセル化
オブジェクト指向は継承が全てだと思う。
いや、まあ全部じゃないけど、ほとんどというか
継承便利だよ継承
いや、まあ全部じゃないけど、ほとんどというか
継承便利だよ継承
OOA/OODでモデリングしたものを出来るだけその形で実装するためにOOP
554 ：仕様書無しさん：04/10/08 10:26:30
また、糞プログラムのごとく、このスレが無限ループを始めたな。
>>554、他の言語関係のスレもだな...
うぜぇから、ム板でやってほしいよな。
うぜぇから、ム板でやってほしいよな。
>>555
こーゆー「理解不足から来る間抜けな話のループ」はこっちで。
こーゆー「理解不足から来る間抜けな話のループ」はこっちで。
おれも多態は重要だと思う
多態を使うと分岐が減ってコードがスッキリするし機能追加とかもしやすい
Ｉ／Ｆの仕様変更とかは影響が全体に及ぶがそれは態を使わなくても同じこと
極論だが継承は差分プログラミングのためのシンタックスシュガーで
カプセル化は馬鹿なやつらのために最小限のＩ／Ｆだけを公開して
余計なことを考えさせない＆余計なところをいじらせないためのテクニック
どりらもＯＯ以前から同じようなことは行われていたと思う
たとえばＣ言語でもスコープ指定子でカプセル化のようなことや
ソースファイルごとのモジュール分割＆再利用で継承のようなことはできる
多態を使うと分岐が減ってコードがスッキリするし機能追加とかもしやすい
Ｉ／Ｆの仕様変更とかは影響が全体に及ぶがそれは態を使わなくても同じこと
極論だが継承は差分プログラミングのためのシンタックスシュガーで
カプセル化は馬鹿なやつらのために最小限のＩ／Ｆだけを公開して
余計なことを考えさせない＆余計なところをいじらせないためのテクニック
どりらもＯＯ以前から同じようなことは行われていたと思う
たとえばＣ言語でもスコープ指定子でカプセル化のようなことや
ソースファイルごとのモジュール分割＆再利用で継承のようなことはできる
>>558
＞どりらもＯＯ以前から同じようなことは行われていたと思う
もちろんそうなんだが、それを言えば多態だってそう。
典型的にはC言語のqsort関数とかだな。
OOの重要な点は、それらが明示的・意識的・体系的に
行われるようになったってことなんだよ。
＞どりらもＯＯ以前から同じようなことは行われていたと思う
もちろんそうなんだが、それを言えば多態だってそう。
典型的にはC言語のqsort関数とかだな。
OOの重要な点は、それらが明示的・意識的・体系的に
行われるようになったってことなんだよ。
>>558
>>たとえばＣ言語でもスコープ指定子でカプセル化のようなことや
>>ソースファイルごとのモジュール分割＆再利用で継承のようなことはできる
これには同意。
>>559
>>もちろんそうなんだが、それを言えば多態だってそう。
>>典型的にはC言語のqsort関数とかだな。
これも基本的には同意。
ただ、アクセス制御や継承って静的なものだけど、多態って動的なものじゃない？
そういう意味では所詮、静的なＣ言語の関数ポインタを多態と呼ぶことには、すこし抵抗があるかも・・・
>>たとえばＣ言語でもスコープ指定子でカプセル化のようなことや
>>ソースファイルごとのモジュール分割＆再利用で継承のようなことはできる
これには同意。
>>559
>>もちろんそうなんだが、それを言えば多態だってそう。
>>典型的にはC言語のqsort関数とかだな。
これも基本的には同意。
ただ、アクセス制御や継承って静的なものだけど、多態って動的なものじゃない？
そういう意味では所詮、静的なＣ言語の関数ポインタを多態と呼ぶことには、すこし抵抗があるかも・・・
561 ：仕様書無しさん：04/10/09 03:14:42
関数ポインタや、FILE * なんていちいちやってらんねーから文法から OOP に
合うようにしたんじゃねーの。
合うようにしたんじゃねーの。
C++で書けばＯＯでＣで書いたらＯＯじゃない、ってことだね。
563 ：仕様書無しさん：04/10/09 06:45:05
564 ：仕様書無しさん：04/10/09 06:50:13
565 ：仕様書無しさん：04/10/09 09:14:10
566 ：仕様書無しさん：04/10/09 12:12:26
567 ：仕様書無しさん：04/10/09 12:35:05
>>562
天才。
天才。
つり名人登場
569 ：仕様書無しさん：04/10/09 19:50:17
いや、ＣでＯＯしないでよ。学者や、優等生はできるらしいがな。
CでOOしません。構造化プログラミングもしません。
571 ：仕様書無しさん：04/10/09 21:37:48
↑ＣＯＢＯＬＥＲ
俺は行番号つきベーシッカーです。低脳ｺﾎﾞﾗなんかと一緒にしないでください。
オブジェクト指向っていうより、
継承やオーバーロードなんていう考え方がコーディング量を減らしてくれてる
ってことに意味があるんだと思うけどな。プリプロセッサの力だよ。
あと、動的型情報や遅い呼び出し方法、ガベコレなど、処理系の力もあって、
こういうのがオブジェクト指向って言葉に仮体してるんだとおもう。
オブジェクト指向ってのはコンセプトではなくて、昨今のプログラミング環境の標語
みたいなもんなんだよ。
継承やオーバーロードなんていう考え方がコーディング量を減らしてくれてる
ってことに意味があるんだと思うけどな。プリプロセッサの力だよ。
あと、動的型情報や遅い呼び出し方法、ガベコレなど、処理系の力もあって、
こういうのがオブジェクト指向って言葉に仮体してるんだとおもう。
オブジェクト指向ってのはコンセプトではなくて、昨今のプログラミング環境の標語
みたいなもんなんだよ。
>>継承やオーバーロードなんていう考え方がコーディング量を減らしてくれてる
その考え方は初心者のはまりやすい落とし穴だな
昨今、継承より委譲が重要視される傾向が強いのも
継承がコーディング量を減らすためだけに安易に乱用されることへの反発から
単純にコーディング量を減らすだけならマクロやテンプレのプリプロ系のが強力だし
その考え方は初心者のはまりやすい落とし穴だな
昨今、継承より委譲が重要視される傾向が強いのも
継承がコーディング量を減らすためだけに安易に乱用されることへの反発から
単純にコーディング量を減らすだけならマクロやテンプレのプリプロ系のが強力だし
575 ：tom ◆q6w1pW48lY ：04/10/10 01:19:08
ある迷路プログラムがあります
自分で書きました
C++でクラスとか使いました
それがどれくらいオブジェクト指向になってるか判定してもらいたいんですが
暇な人いませんか？
実行ファイルだけならHPに置いてます
自分で書きました
C++でクラスとか使いました
それがどれくらいオブジェクト指向になってるか判定してもらいたいんですが
暇な人いませんか？
実行ファイルだけならHPに置いてます
実行ファイルだけならHPに置いてます
↑
ソースきぼんぬ
↑
ソースきぼんぬ
577 ：tom ◆q6w1pW48lY ：04/10/10 01:43:38
>>576
レスちょっと遅れてごめん
とりあえず実行ファイル置いてるとこだしたあと
ソースを圧縮します
http://www3.pf-x.net/~tom/junkprog.html
ってか連投にひっかかったから待ってる間にUP完了
http://77483.org/upload/source/77483_0966.lzh
レスちょっと遅れてごめん
とりあえず実行ファイル置いてるとこだしたあと
ソースを圧縮します
http://www3.pf-x.net/~tom/junkprog.html
ってか連投にひっかかったから待ってる間にUP完了
http://77483.org/upload/source/77483_0966.lzh
578 ：tom ◆q6w1pW48lY ：04/10/10 01:48:28
オブジェクト指向を理解するためにC++のからくり買ったりしてる・・・
もっとよさそうな本探せばみつかるだろうけど
好きなサイトの管理者が読書ってコーナーですすめてたからこれにした
もっとよさそうな本探せばみつかるだろうけど
好きなサイトの管理者が読書ってコーナーですすめてたからこれにした
ずいぶんすっきりしたコード書くじゃねえか
あまりコード読んでないがfriendがカプセルかを台無しにしてることだけは確か
あまりコード読んでないがfriendがカプセルかを台無しにしてることだけは確か
580 ：tom ◆q6w1pW48lY ：04/10/10 02:02:24
>>579
ちょっとしたレビューでもかなりうれしいです・・・
知り合いにプログラマの人一人もいないんで・・・
すっきりしてますか？
こういうコード量産したら実力つくかな・・
friendは色々めんどくさくなってつけたんです
ポリモフィーズムとか使ったのも作りたいな・・・
てか一応ageとこっと・・・
ちょっとしたレビューでもかなりうれしいです・・・
知り合いにプログラマの人一人もいないんで・・・
すっきりしてますか？
こういうコード量産したら実力つくかな・・
friendは色々めんどくさくなってつけたんです
ポリモフィーズムとか使ったのも作りたいな・・・
てか一応ageとこっと・・・
>>577
オメーのサイト、目が痛くなるぞｗ
オメーのサイト、目が痛くなるぞｗ
確かに思ったよりすっきりしてんな。
あとは大きなプログラムを沢山書いて、
様々な要素同士の関連性を綺麗に管理できるようになれば
能力を上げることができるだろう。
それより微妙に板違いだ。
プログラミングの話をしたいならム板行った方がいいぞ。
あとは大きなプログラムを沢山書いて、
様々な要素同士の関連性を綺麗に管理できるようになれば
能力を上げることができるだろう。
それより微妙に板違いだ。
プログラミングの話をしたいならム板行った方がいいぞ。
直しどころは多い
OOとは直接関係ないがリファクタリング系の本読んどけ
オブジェクトの切り分けは悪くない
さっき書いたようにfriendをやめてオブジェクト間の依存度を減らすべきだな
OOとは直接関係ないがリファクタリング系の本読んどけ
オブジェクトの切り分けは悪くない
さっき書いたようにfriendをやめてオブジェクト間の依存度を減らすべきだな
584 ：tom ◆q6w1pW48lY ：04/10/10 02:12:46
>>581
えー やっぱ？
最初は白地に黒だったんだよね
プロフィール見ればなんでそんなんにしてるか理由わかるよ
>>582
なるほどふむふむ・・・・・・・
大きなプログラムを書くのはほんとやりたいです・・
要素が多くなると混乱します
例えばウィンドウ２つのソフトとかは作るときかなり時間かかる
メッセンジャーのクライアント作ろうとしてログインするとこまでできたけど
会話窓を作るのに失敗してやめたのが残ってる・・・
精進します・・・
えー やっぱ？
最初は白地に黒だったんだよね
プロフィール見ればなんでそんなんにしてるか理由わかるよ
>>582
なるほどふむふむ・・・・・・・
大きなプログラムを書くのはほんとやりたいです・・
要素が多くなると混乱します
例えばウィンドウ２つのソフトとかは作るときかなり時間かかる
メッセンジャーのクライアント作ろうとしてログインするとこまでできたけど
会話窓を作るのに失敗してやめたのが残ってる・・・
精進します・・・
ざっと見てみた
オブジェクト指向だから、ヘッダのみ。
ソースは読んでない。
で、読んで思ったことは
コメントが皆無のために、各クラスの責務がわからん。
directionあたりはソースを読まない限り
何のクラスかは、ほぼわからないのでは？
エリアとフィールドは名前が似すぎ
画面全体のフィールドと、1コマを管理するクラスとしては
名前が似すぎでは？
名前は、読めば責務がはっきりするように書くべき。
あと、各クラスにdrawはあってはいけない。
とりあえず、君が考えた各クラスの責務範疇をきぼん
オブジェクト指向だから、ヘッダのみ。
ソースは読んでない。
で、読んで思ったことは
コメントが皆無のために、各クラスの責務がわからん。
directionあたりはソースを読まない限り
何のクラスかは、ほぼわからないのでは？
エリアとフィールドは名前が似すぎ
画面全体のフィールドと、1コマを管理するクラスとしては
名前が似すぎでは？
名前は、読めば責務がはっきりするように書くべき。
あと、各クラスにdrawはあってはいけない。
とりあえず、君が考えた各クラスの責務範疇をきぼん
586 ：tom ◆q6w1pW48lY ：04/10/10 02:15:05
>>583
自分でもそう思う
friendにしたのはやっぱり失敗だったか・・
リファクタリングは興味あるけど
自分が作る規模のソフトでは必要ないかなって思ってました・・
（とかいいながらデザインパターンの本持ってるけど・・
オブジェクトの切り分けがうまくいってるってのはうれしい・・・
自分でもそう思う
friendにしたのはやっぱり失敗だったか・・
リファクタリングは興味あるけど
自分が作る規模のソフトでは必要ないかなって思ってました・・
（とかいいながらデザインパターンの本持ってるけど・・
オブジェクトの切り分けがうまくいってるってのはうれしい・・・
まあ荒れるよりはマシな流れだな。
>>584
このスレでの話が終わったら
http://pc5.2ch.net/tech/
こっちに行きな。
まだ職業プログラマじゃないんなら、プログラムの話をしてた方が楽しいだろう。
>>584
このスレでの話が終わったら
http://pc5.2ch.net/tech/
こっちに行きな。
まだ職業プログラマじゃないんなら、プログラムの話をしてた方が楽しいだろう。
588 ：tom ◆q6w1pW48lY ：04/10/10 02:23:22
>>585
見てくれてありがとう
ヘッダのみか なるほど そういう読み方もあるか
コメントはごめんなさい言い忘れました・・・
directionは前スリザーリンク（パズル）を解くプログラムを作るときに使ったから
これを作り始めたときにすぐ作ったクラスです
ちょっと自己流がかなり入ってるクラスだからコードみたほうがわかりやすいと思います
フィールドはマップ全体でエリアが□1個って感じです
たしかに名前にてますね・・・いい名前が思いつかなかった
drawは別のクラスに任せればよかったか？
なんかWindows関係のコードをクラスにいれるときにけっこうためらったけど・・
クラスの配分は
field マップ全体
direction 迷路作成時に掘る方向とか決めるのに使う
area マップの最小単位 となりのareaとどういう関係かの情報をもっている
maze 迷路を作ったり フィールドを作ったりするクラス
ファイルについて
main.cpp Windows関係のコードばっかり
見てくれてありがとう
ヘッダのみか なるほど そういう読み方もあるか
コメントはごめんなさい言い忘れました・・・
directionは前スリザーリンク（パズル）を解くプログラムを作るときに使ったから
これを作り始めたときにすぐ作ったクラスです
ちょっと自己流がかなり入ってるクラスだからコードみたほうがわかりやすいと思います
フィールドはマップ全体でエリアが□1個って感じです
たしかに名前にてますね・・・いい名前が思いつかなかった
drawは別のクラスに任せればよかったか？
なんかWindows関係のコードをクラスにいれるときにけっこうためらったけど・・
クラスの配分は
field マップ全体
direction 迷路作成時に掘る方向とか決めるのに使う
area マップの最小単位 となりのareaとどういう関係かの情報をもっている
maze 迷路を作ったり フィールドを作ったりするクラス
ファイルについて
main.cpp Windows関係のコードばっかり
589 ：tom ◆q6w1pW48lY ：04/10/10 02:24:06
>588
バウンダリ(この場合はDraw)は別で作るべき。
今回は、Windowsアプリだが、
これが、IDOSXや他の表示方法(ひょっとしたら表示させないで内部で処理)
などになった場合に、すべてのクラスに手が入ることになる。
そこは、MVCの形に添うと、良い感じになる。
バウンダリ(この場合はDraw)は別で作るべき。
今回は、Windowsアプリだが、
これが、IDOSXや他の表示方法(ひょっとしたら表示させないで内部で処理)
などになった場合に、すべてのクラスに手が入ることになる。
そこは、MVCの形に添うと、良い感じになる。
IDOSXってなんだよ
DOSの間違いです。
DOSの間違いです。
592 ：tom ◆q6w1pW48lY ：04/10/10 02:36:57
>>590-591
IDOSXのことぐぐってた・・DOSですかやっぱり
バウンダリという用語も初めてです・・（プロの方はよく使うんですか？
MVCは概要は知ってる・・
DOSで表示とか1回やってみたいから（見るだけ）ためしにやってみようかな・・
表示しないってのもいつか使うかも
areaのdrawを書きなおすのが一番大変そうだ・・・
次からDOSに移植する可能性のあるのはもっと考えて書こうっと
IDOSXのことぐぐってた・・DOSですかやっぱり
バウンダリという用語も初めてです・・（プロの方はよく使うんですか？
MVCは概要は知ってる・・
DOSで表示とか1回やってみたいから（見るだけ）ためしにやってみようかな・・
表示しないってのもいつか使うかも
areaのdrawを書きなおすのが一番大変そうだ・・・
次からDOSに移植する可能性のあるのはもっと考えて書こうっと
593 ：仕様書無しさん：04/10/10 02:58:41
( ﾟДﾟ)＜↓このリンク、絶対開いちゃだめだ！
http://sakura02.bbspink.com/test/read.cgi/mature/1097343008/l50
ほんとに、絶対ダメだぞ！
http://sakura02.bbspink.com/test/read.cgi/mature/1097343008/l50
ほんとに、絶対ダメだぞ！
>>593
殺されてーのかハゲ！
殺されてーのかハゲ！
ブラクラを期待してたのに。つまらん
リンク先がbbspinkでブラクラって、あんた・・
597 ：577：04/10/11 19:02:36
スレ違いで悪いんだけど
>>577のファイル消しといたほうがいいかな？
>>577のファイル消しといたほうがいいかな？
いいじゃん、性欲は生物の基本クラスだよ。偶には原点回帰しようよ。
>>574
それも、どこまでをオブジェクト指向と呼ぶかだよね。
委譲って、コンポーネント指向や、エージェント指向に近いでしょ。
広義ではオブジェクト指向だけどさ。
そのうちシリアライズや XML までオブジェクト指向で一括りにされるのかも
しれないけどね。
それも、どこまでをオブジェクト指向と呼ぶかだよね。
委譲って、コンポーネント指向や、エージェント指向に近いでしょ。
広義ではオブジェクト指向だけどさ。
そのうちシリアライズや XML までオブジェクト指向で一括りにされるのかも
しれないけどね。
大体、オブジェクト指向って、構造化手法のアンチパシーじゃないですか。
何で一方が手法で他方が指向なのかと考え出すと長くなるのでやらないけど、
結局のところ、
構造化手法ってのは、ノイマン型であることを大いに利用した実装手法であって、
オブジェクト指向というのはそこから抽象化した方向へ進んだものを言ってるんだと
捉えるべきじゃないかな。
もっと言うと、作業手順書に代表される「プロセス」を否定して成り立つ、
色即是空、空即是色な「世界」がオブジェクト指向なんじゃないかな。
わかる？
何で一方が手法で他方が指向なのかと考え出すと長くなるのでやらないけど、
結局のところ、
構造化手法ってのは、ノイマン型であることを大いに利用した実装手法であって、
オブジェクト指向というのはそこから抽象化した方向へ進んだものを言ってるんだと
捉えるべきじゃないかな。
もっと言うと、作業手順書に代表される「プロセス」を否定して成り立つ、
色即是空、空即是色な「世界」がオブジェクト指向なんじゃないかな。
わかる？
どこかにシナリオライターがいて、矛盾のない世界を書こうとするのではなく、
あくまで小道具や役者を揃えて、あとは好きにやれと。
そうやって創発的に生まれる振る舞いがプログラムなんだと。
ここまで言うと、アンチアルゴリズムみたいになるね。
オブジェクト指向は最適化問題を扱うのに潜在的に適しているってことだろうか。
あくまで小道具や役者を揃えて、あとは好きにやれと。
そうやって創発的に生まれる振る舞いがプログラムなんだと。
ここまで言うと、アンチアルゴリズムみたいになるね。
オブジェクト指向は最適化問題を扱うのに潜在的に適しているってことだろうか。
601はオブジェクト指向に幻想を抱いている
人間の典型的な例に思える。
人間の典型的な例に思える。
でも、そんな言い古された比喩でオブジェクト指向を捉えたところで
オブジェクト指向なプログラミングのたいしたヒントにはならないんだよね。
そういうと、オブジェクトになった気持ちで配役を決めればいいという方々が
いたけど、そんなことすると無秩序極まってしまって、あとで動作が予想できなくなっちゃう。
結局、管理者みたいなオブジェクトをおいて、そいつが「プロセス」をこなす内に、
労働者オブジェクトへ仕事を振り分けるという構造になっていく。
そこで、労働者っていうのが専門家であるエージェントだと立場を定める指向なんかが考案される。
そういう役割分担が優れてるかどうかは、誰にも解らない。
ところで、ここで歴史を振り返ると、「プロセス」を否定した「世界」が更に否定されて「プロセス」に
頼ってるわけだ。 歴史は繰り返すというか、当面の答えはこの辺をうまくバランスさせるところに
あるのかもしれないね。
オブジェクト指向なプログラミングのたいしたヒントにはならないんだよね。
そういうと、オブジェクトになった気持ちで配役を決めればいいという方々が
いたけど、そんなことすると無秩序極まってしまって、あとで動作が予想できなくなっちゃう。
結局、管理者みたいなオブジェクトをおいて、そいつが「プロセス」をこなす内に、
労働者オブジェクトへ仕事を振り分けるという構造になっていく。
そこで、労働者っていうのが専門家であるエージェントだと立場を定める指向なんかが考案される。
そういう役割分担が優れてるかどうかは、誰にも解らない。
ところで、ここで歴史を振り返ると、「プロセス」を否定した「世界」が更に否定されて「プロセス」に
頼ってるわけだ。 歴史は繰り返すというか、当面の答えはこの辺をうまくバランスさせるところに
あるのかもしれないね。
実際のところはオブジェクト指向は構造化手法を内包してるわけだから、
否定するのではなく拡張だと思うんだけど。
俺は二つの関係を教えるときに、
「どっちも整理術の一種で、机の上を整理するのが構造化手法だとしたら、
机そのものを整理するのがオブジェクト指向」
って教えてるよ。
否定するのではなく拡張だと思うんだけど。
俺は二つの関係を教えるときに、
「どっちも整理術の一種で、机の上を整理するのが構造化手法だとしたら、
机そのものを整理するのがオブジェクト指向」
って教えてるよ。
でも、文字にあるオブジェクトっていうところから考えてみると、
結局ノイマン型という記述する側の都合を離れて、記述される側の都合を優先させようという
考えととらえるべきなんじゃないかな。 オブジェクト指向ってやつは。
モノは方法を内包する？
プログラムは方法を内包するけど、”物”はしないよね。
原義を考えるとしない。
結局ノイマン型という記述する側の都合を離れて、記述される側の都合を優先させようという
考えととらえるべきなんじゃないかな。 オブジェクト指向ってやつは。
モノは方法を内包する？
プログラムは方法を内包するけど、”物”はしないよね。
原義を考えるとしない。
＞60２
自分もそういうイメージですよ
どちらかというとオブジェクトは自分の知り合いのことしか考えてないというイメージに近い。
自分もそういうイメージですよ
どちらかというとオブジェクトは自分の知り合いのことしか考えてないというイメージに近い。
”モノ”が内包するのは、敢えて言うと構造でしょ。
ただ、構造化手法のいう構造は、方法を簡潔に表現するための構造。
ループや分岐などのステートメントをコンビネーションによって発達させた構造。
これは自然言語の中にあるものを当てはめると、例えば文体、構成、修辞、文法。
決して記述する対象の構造についてはこれを含むものではない。 と解するべき。
そうでないなら、構造化手法がオブジェクト指向を包含することになってしまい、
リアルではネオナチのように、２ｃｈではキティとして扱われる。
ただ、構造化手法のいう構造は、方法を簡潔に表現するための構造。
ループや分岐などのステートメントをコンビネーションによって発達させた構造。
これは自然言語の中にあるものを当てはめると、例えば文体、構成、修辞、文法。
決して記述する対象の構造についてはこれを含むものではない。 と解するべき。
そうでないなら、構造化手法がオブジェクト指向を包含することになってしまい、
リアルではネオナチのように、２ｃｈではキティとして扱われる。
蛇足。オブジェクトには目的の意味もある。
目的の為なら手段選ばず。 これなら何でも入るし最強かな。 以上。
目的の為なら手段選ばず。 これなら何でも入るし最強かな。 以上。
おまえらよくこんな会話が理解出来ますね
某一人の書き込みがオナーニみたいだね
某一人の書き込みがオナーニみたいだね
>>610
何も内容なんかねえから心配するな。
何も内容なんかねえから心配するな。
でも実際、構造化手法でかいた動作確認コードをつかって
クラス化していくとき、単にモジュール化する以上のこの
作業の意味はなんなんだろうって考えるよね。
カプセル化とオーバーロード以上の意味がないことが多い。
コーディングやってるだけでは、これ以上の意味はないのかもしれない。 やっぱ分析や設計の段階で一番真価が現れるんだろう。
クラス化していくとき、単にモジュール化する以上のこの
作業の意味はなんなんだろうって考えるよね。
カプセル化とオーバーロード以上の意味がないことが多い。
コーディングやってるだけでは、これ以上の意味はないのかもしれない。 やっぱ分析や設計の段階で一番真価が現れるんだろう。
>606 にあるように、記述される側の都合を優先させている
と考えると、コーディングという記述作業をやってる場合にはメリットがそれほどないということなのかな。
反面、記述することを考えていないわけだから、アーキテクチャやフレームワークの動作を理解してない人間には
使いやすくなってる。
オブジェクト指向がプログラマにとって難しいのは、そういうことなのかもしれない。
と考えると、コーディングという記述作業をやってる場合にはメリットがそれほどないということなのかな。
反面、記述することを考えていないわけだから、アーキテクチャやフレームワークの動作を理解してない人間には
使いやすくなってる。
オブジェクト指向がプログラマにとって難しいのは、そういうことなのかもしれない。
現実に扱う事物に当てはめてクラスを作っていくという作業は、物事の本質を
見抜く力がないと出来ないような気がする。
見抜く力がないと出来ないような気がする。
>>615
逆に、物事の本当の本質をとらえようとすると、
ガチガチなオブジェクト指向に懐疑的になる。
特に業務系の本質は、台帳だよ。
O/Rマッピングだのなんだの、すんごい複雑な集計する
会計帳票を出す事考えると、どうすんのかと。
最近のO/Rマッピングは割りとゴリゴリSQL書けるみたいだけども
それはなんでもオブジェクトでナビゲーションするってのは
限界があるなって気が付いたって事なんでしょかねー。
逆に、物事の本当の本質をとらえようとすると、
ガチガチなオブジェクト指向に懐疑的になる。
特に業務系の本質は、台帳だよ。
O/Rマッピングだのなんだの、すんごい複雑な集計する
会計帳票を出す事考えると、どうすんのかと。
最近のO/Rマッピングは割りとゴリゴリSQL書けるみたいだけども
それはなんでもオブジェクトでナビゲーションするってのは
限界があるなって気が付いたって事なんでしょかねー。
カプセル化がそもそもの発端で、あとは後付のよかーん。
>>616
逆だぞ。
既存の業務というものが台帳をもとにした構造になっていて、
それを写像すれば台帳が基本になってしまう。
いまの考えでもって、リアルタイム、並行、などを考えて業務プロセスを見直せば、
まったく異なる業務にもたどり着ける。
逆だぞ。
既存の業務というものが台帳をもとにした構造になっていて、
それを写像すれば台帳が基本になってしまう。
いまの考えでもって、リアルタイム、並行、などを考えて業務プロセスを見直せば、
まったく異なる業務にもたどり着ける。
>>616
>O/Rマッピングだのなんだの、すんごい複雑な集計する
>会計帳票を出す事考えると、どうすんのかと。
賛成。
でも、俺には >>616 も同じ陥穽に陥っているように思える。
俺は、「業務系の世界は "台帳" こそが本質だ」と言っている奴の発言は、
絶対信用しないことにしている。
プログラマにとって台帳は実に扱いやすい。
だからこそ、それが「本質」に見えてしまう。
もし台帳だけで事が済むなら、チェックディジットのような
余計な機能が必要とされることは絶対無かっただろう。
>>616 は、チェックディジットは
業務システムにおいて、本質的な機能（の一部）だと
考えた事はないの？
業務の現場で働いた経験がない奴に、
そのような考え方は一生理解できないものだ。
>O/Rマッピングだのなんだの、すんごい複雑な集計する
>会計帳票を出す事考えると、どうすんのかと。
賛成。
でも、俺には >>616 も同じ陥穽に陥っているように思える。
俺は、「業務系の世界は "台帳" こそが本質だ」と言っている奴の発言は、
絶対信用しないことにしている。
プログラマにとって台帳は実に扱いやすい。
だからこそ、それが「本質」に見えてしまう。
もし台帳だけで事が済むなら、チェックディジットのような
余計な機能が必要とされることは絶対無かっただろう。
>>616 は、チェックディジットは
業務システムにおいて、本質的な機能（の一部）だと
考えた事はないの？
業務の現場で働いた経験がない奴に、
そのような考え方は一生理解できないものだ。
class 帳票 {
protected:
validation();
};
protected:
validation();
};
チェックディジットって、コードのヴァリデーションに
使うんだと思ってたけど、それが台帳だけで事がすむなら
要らないってのがよく分からないんですが。
業務初心者なものですみません。
使うんだと思ってたけど、それが台帳だけで事がすむなら
要らないってのがよく分からないんですが。
業務初心者なものですみません。
俺も>>619が何を言ってるのかよくわからん
業務が理解できないんでチェックディジットの部分しかコーディングさせて
もらえなかったんだよ。
もらえなかったんだよ。
もしかして、「台帳」ってのを、紙に出力された
物理的な台帳の事と思ったのかな？
紙だとコードとか印刷されても経年劣化する。
↓
チェックディジットによるヴァリデーションが不可欠。
ストーリーは通るけど・・・・まさかねぇ。
物理的な台帳の事と思ったのかな？
紙だとコードとか印刷されても経年劣化する。
↓
チェックディジットによるヴァリデーションが不可欠。
ストーリーは通るけど・・・・まさかねぇ。
要するに、業務系はDOAで必要十分ということでFA
エンティティを捉えるには、
ユースケースから名詞を抜き出して云々とよく本に書いてありますが
ユーザーが一番理解しやすい画面、帳票から捉えていった方が
ユーザーを交えてのモデリングセッションにおいて
間違いが起こりにくいという実感があります。
それってDOAじゃんって話ですよねーマイッタ。
まああとから責務割付とかで振る舞いをくっつけたりってのは
ありましょうが、いいとこどりでいいんじゃないでしょか。
ユースケースから名詞を抜き出して云々とよく本に書いてありますが
ユーザーが一番理解しやすい画面、帳票から捉えていった方が
ユーザーを交えてのモデリングセッションにおいて
間違いが起こりにくいという実感があります。
それってDOAじゃんって話ですよねーマイッタ。
まああとから責務割付とかで振る舞いをくっつけたりってのは
ありましょうが、いいとこどりでいいんじゃないでしょか。
>626
画面帳票のバウンダリ部分を除けば
りっぱなエンティティだと思われ
画面帳票のバウンダリ部分を除けば
りっぱなエンティティだと思われ
エンティティ・・・ バウンダリ・・・ 意味の通る日本語に出来ないのか？
>>628
漢字になってれば満足なのか？
漢字になってれば満足なのか？
普段使いそうもない横文字並べられても、その単語から大した連想
出来ない。
辞書見たらエンティティはコンピュータ用語では構成要素だってよ。
だったらそう言えばいいのに。
バウンダリは境界表現・・・？？ なんのこっちゃ？
出来ない。
辞書見たらエンティティはコンピュータ用語では構成要素だってよ。
だったらそう言えばいいのに。
バウンダリは境界表現・・・？？ なんのこっちゃ？
＞628
実体・・・、境界・・・ これで満足？
実体・・・、境界・・・ これで満足？
実体だと、インスタンスやオブジェクトではダメだったのか？
境界だと、ボーダーではダメなのか？
英語圏の連中には使い分ける合理的理由があるのだろうが、英語を使いこな
していない俺にはその違いがよう分からんわ。
オブジェクト指向が難しいのではなく、次々と出てくる聞き慣れない英単語が、
理解を妨げる自己暗示をかけるのではないかと・・・・
境界だと、ボーダーではダメなのか？
英語圏の連中には使い分ける合理的理由があるのだろうが、英語を使いこな
していない俺にはその違いがよう分からんわ。
オブジェクト指向が難しいのではなく、次々と出てくる聞き慣れない英単語が、
理解を妨げる自己暗示をかけるのではないかと・・・・
言葉として捉えようとするから時間がかかるんだよ。
周辺を理解していれば記号として取り扱うことができる。
ただし、他者とのコミュニケーションには共通の認識が必要。
なのでレベルが違いすぎる人との会話は平行線で終わることが多々ある。
周辺を理解していれば記号として取り扱うことができる。
ただし、他者とのコミュニケーションには共通の認識が必要。
なのでレベルが違いすぎる人との会話は平行線で終わることが多々ある。
どうでも(･∀･)ｲｲ!!が、ほとんどのソフトハウスは社内向けや、クライアント向けに必要もないUML仕様書を書かされている予感
記号として曖昧とするより日本語に置換したほうが意味が理解しやすい語もあるし
横文字そのものを書かれるより無理矢理なカタカナが難しかったりする
原語で読んでる方が楽なのとかもあるんだよな…
横文字そのものを書かれるより無理矢理なカタカナが難しかったりする
原語で読んでる方が楽なのとかもあるんだよな…
記号にして、それを分類(classify)することで定義すりゃいいじゃん。
>>632のように
entity
→(不自然な邦訳)→実体
→(もとの概念を知らない者による英訳)→instance
entity と instance は *まったく* 意味が違うだろ。
そんな面倒な不整合は起こしたくないな。
>>632のように
entity
→(不自然な邦訳)→実体
→(もとの概念を知らない者による英訳)→instance
entity と instance は *まったく* 意味が違うだろ。
そんな面倒な不整合は起こしたくないな。
訳したら訳したで、判りにくいって意見も出るもんです。
哲学なんかはそうです。
representation って書くと、もう一回現れるとか再度存在するとか
そんな感じなんだろうなあって判るけど、
それを「表象」と訳されてもさっぱりだ。
訳しても、その言葉の持つ一部のニュアンスが捨てられたり
逆に訳した日本語の持つ余計なニュアンスが付いちゃう事もある。
instance/entity の2つが1つの実体って日本語にまとまっちゃうと
不整合が起きる、とか。
なんかの本でパターン名を、無理に日本語訳して評判悪かった本もあった。
なんだっけな、observerパターンのsubjectが対象事象だっけな。
哲学なんかはそうです。
representation って書くと、もう一回現れるとか再度存在するとか
そんな感じなんだろうなあって判るけど、
それを「表象」と訳されてもさっぱりだ。
訳しても、その言葉の持つ一部のニュアンスが捨てられたり
逆に訳した日本語の持つ余計なニュアンスが付いちゃう事もある。
instance/entity の2つが1つの実体って日本語にまとまっちゃうと
不整合が起きる、とか。
なんかの本でパターン名を、無理に日本語訳して評判悪かった本もあった。
なんだっけな、observerパターンのsubjectが対象事象だっけな。
そうそう、ニュースとかでOSの事を律儀に基本ソフトっていうけど
違和感ないですか？
還暦すぎたうちのおとんおかんだってOSくらい知ってるよ。
違和感ないですか？
還暦すぎたうちのおとんおかんだってOSくらい知ってるよ。
ＯＳの何たるか、なぜ必要かまでは理解していないと思われ。
かといって基本ソフトと訳した所で
状況はかわりませんでしょう。
状況はかわりませんでしょう。
それが何をさしているかは分からなくても、基本的な事をやってるソフト
なんだなぁ、という事が漠然と理解できます。
複雑な事をする時でも、基本的な事をおさえとく必要がある事は、誰でも
なんとなく理解できのです。
なんだなぁ、という事が漠然と理解できます。
複雑な事をする時でも、基本的な事をおさえとく必要がある事は、誰でも
なんとなく理解できのです。
でもまあ、OSの訳として基本ソフトというのは微妙に違う気がしないでもないね
演算大系みたいに直訳しなかっただけマシかも
「基本ソフト」はまだいい。「応用ソフト」って何だよ。Wordが何を「応用」してるんだ？
応用ていうか「利用」が正しいのかな？
そのハードとOSを利用しているのがアプリケーション。
そのハードとOSを利用しているのがアプリケーション。
汎用演算機用の機械語形式一連制御記述物は基本記述物と応用記述物とに分かれる。
基本記述物は、応用記述物の為に演算機の機能を効率的に提供する為に存在する。
応用記述物は、基本記述物の提供機能を組み合わせ、効果的に特定情報を処理する事を目的としている。
その為、応用記述物は基本記述物に拘束され、その意味においてはあくまで基本記述物の「応用」である。
・・・・・・・・・やってみたが、やはりデムパのようだ
基本記述物は、応用記述物の為に演算機の機能を効率的に提供する為に存在する。
応用記述物は、基本記述物の提供機能を組み合わせ、効果的に特定情報を処理する事を目的としている。
その為、応用記述物は基本記述物に拘束され、その意味においてはあくまで基本記述物の「応用」である。
・・・・・・・・・やってみたが、やはりデムパのようだ
おまいら日本語は英語も日本語に取り入れられるので何とかなってるが
中国語ではどうなってるのか。ものすごい漢字が当てはめられてる予感。
新しい言葉を作りまくるMSのことは大嫌いなんじゃないだろうか?
中国語ではどうなってるのか。ものすごい漢字が当てはめられてる予感。
新しい言葉を作りまくるMSのことは大嫌いなんじゃないだろうか?
英語で思考するんだ！
中国語
ActiveX 行動的謎
COM 電
WindowsDNA 窓的遺伝子
.NET 点網
ActiveX 行動的謎
COM 電
WindowsDNA 窓的遺伝子
.NET 点網
652 ：仕様書無しさん：04/10/17 00:24:26
あなたは、かっぱえびせんはやめられるし止められますか？
653 ：仕様書無しさん：04/10/17 00:25:22
654 ：仕様書無しさん：04/10/17 00:26:29
Application Software の訳で「応用ソフト」。それに対応して「基本ソフト」なのやろ。
655 ：645：04/10/17 00:29:35
>653
じゃ、「応用ソフト」って何だよ。具体的に挙げてくれ。
じゃ、「応用ソフト」って何だよ。具体的に挙げてくれ。
656 ：仕様書無しさん：04/10/17 01:11:24
ＯＳは「基礎プログラム」で、アプリは「機能プログラム」というのは？
658 ：仕様書無しさん：04/10/17 01:24:19
OS は「操作系」で、アプリは「応用」というのでは。
オブジェクト指向スレだろ、オブジェクト指向を日本語にしてよ
660 ：仕様書無しさん：04/10/17 01:29:06
はしのえみ大好き！ はしのえみ大好き！
もう、何度でも言おう。
はしのえみ大好き！ はしのえみ大好き！
はしのえみ大好き！ はしのえみ大好き！
はしのえみ大好き！ はしのえみ大好き！
はしのえみ大好き！ はしのえみ大好き！
は し の え み 大 好 き ！
もう、何度でも言おう。
はしのえみ大好き！ はしのえみ大好き！
はしのえみ大好き！ はしのえみ大好き！
はしのえみ大好き！ はしのえみ大好き！
はしのえみ大好き！ はしのえみ大好き！
は し の え み 大 好 き ！
661 ：仕様書無しさん：04/10/17 01:29:49
662 ：仕様書無しさん：04/10/17 01:30:55
>>659
究極対指向
究極対指向
>>659
概念指向
概念指向
>>659
現物主義
現物主義
>>659
現ナマ主義
現ナマ主義
667 ：仕様書無しさん：04/10/17 12:32:46
信用取引主義。
668 ：仕様書無しさん：04/10/17 12:35:39
オブシディアン・オーダー。
森の木々から石ころまで神々が宿っているのれす。
オプジェクと指向とは神々を宿らせるということなのれす。
万物入魂れす。
オプジェクと指向とは神々を宿らせるということなのれす。
万物入魂れす。
このレビューでも似たような話題。
http://www.amazon.co.jp/exec/obidos/ASIN/4797314397/ref=pd_ir_b/249-1404324-3520318
具象対象、反応体、かっちょえー。
http://www.amazon.co.jp/exec/obidos/ASIN/4797314397/ref=pd_ir_b/249-1404324-3520318
具象対象、反応体、かっちょえー。
671 ：仕様書無しさん：04/10/18 13:49:10
次々と現れては消えていく、新しい概念や方法論。 要するに、この業界の
人は飽きっぽいのではないかと。
いつまでも同じ事をやるのが嫌だから、全く新しいやり方を作り出して、モチ
ベーションを維持しようとしてるんだ。 そうに決まってる。
人は飽きっぽいのではないかと。
いつまでも同じ事をやるのが嫌だから、全く新しいやり方を作り出して、モチ
ベーションを維持しようとしてるんだ。 そうに決まってる。
そうしないとお金になりまへん、という人たちの陰謀です。
673 ：仕様書無しさん：04/10/18 14:19:22
つーかSimula67の頃から始めてもう30年以上オブジェクト指向プログラミング
をしている漏れにとって何でわからないというのかがわからない。
をしている漏れにとって何でわからないというのかがわからない。
674 ：仕様書無しさん：04/10/18 14:31:20
ジジィうざ。
>>659
生が好き
生が好き
バカか？いちいち存在価値を考えるなよ。かっこいいからＯＯＰしてるにきまってる。
>>671
いいか。常に進化の連続である。
進化とはより良いものへの飽くなき探求というわけだ。
実際「俺はグローバルスコープで全部やったほうがいい」と言うならば、
それでやればいいだけのことだ。
実際は多くの人が支持するものが生き残り、他は淘汰される、それは当然。
だから調子にのって名誉欲で"編み出した"新しい技法とかそういうのは、本当に良いものでない限り消えていくんだよ。
まぁどうやら消えていくのは>>671のような奴等だろうが
いいか。常に進化の連続である。
進化とはより良いものへの飽くなき探求というわけだ。
実際「俺はグローバルスコープで全部やったほうがいい」と言うならば、
それでやればいいだけのことだ。
実際は多くの人が支持するものが生き残り、他は淘汰される、それは当然。
だから調子にのって名誉欲で"編み出した"新しい技法とかそういうのは、本当に良いものでない限り消えていくんだよ。
まぁどうやら消えていくのは>>671のような奴等だろうが
678 ：仕様書無しさん：04/10/18 15:35:16
正味の話、煽りの文章がヘタクソだと萎えるな
英語の授業／講義をさぼってた奴は大変だね。
半年ほどシンガポールに遊びに行ってこいよ。誰でもTOEC900レベルには到達できるぞ。
半年ほどシンガポールに遊びに行ってこいよ。誰でもTOEC900レベルには到達できるぞ。
それは放射線の被爆量か何かの値ですか？
＞673
参考までにどんな仕事をどんな風に進められてるのかを教えてもらえませんか？
参考までにどんな仕事をどんな風に進められてるのかを教えてもらえませんか？
UML設計の本でも1冊よめばわかる
てか、俺としては、情報処理とかよりも、
Ｃ++の資格試験とか、オブジェクト思考の資格試験とかあってほしい。
Ｃ++の資格試験とか、オブジェクト思考の資格試験とかあってほしい。
UMLはあるな
Java、.net、C#、D、デザパタ、UMLなどなど、オブジェクト指向関連技術がぐんぐん普及しつつあるから、
最近は昔みたいに躍起になって啓蒙しなくてもよくなったねぇ。
>>1みたいなのはほっといても勝手に淘汰されるでしょう…。
最近は昔みたいに躍起になって啓蒙しなくてもよくなったねぇ。
>>1みたいなのはほっといても勝手に淘汰されるでしょう…。
ＸＭＬの登場でオブジェクト指向の勢いはちょっと怯んだきがするね。
データそのものが可変な構造をもって扱い可能になったわけで、
いままでデータをカプセル化してたオブジェクトが、データ自信のオブジェクト
化によって大きく存在価値を減らしてしまった。
ＤＯＡとＸＭＬによるアプローチなんてのも、今後有力になるんじゃないかな。
ＭＳのInfoPathなんて、既にそうなのかもしれないね。
データそのものが可変な構造をもって扱い可能になったわけで、
いままでデータをカプセル化してたオブジェクトが、データ自信のオブジェクト
化によって大きく存在価値を減らしてしまった。
ＤＯＡとＸＭＬによるアプローチなんてのも、今後有力になるんじゃないかな。
ＭＳのInfoPathなんて、既にそうなのかもしれないね。
Java厨がろくにOOも理解せずにつまらんコマースサイトを構築し始めて
オブジェクトの永続化程度のことに注力してるからXMLに足元を掬われるんだ。
オブジェクトの永続化程度のことに注力してるからXMLに足元を掬われるんだ。
つーかシリアライザもない非オブジェクト指向言語でXMLを扱うのってすげぇ面倒なのでは？
いまだにＸＭＬはメタデータとしてしか捕らえてないんだが、どうなのこれ？
693 ：仕様書無しさん：04/10/20 09:24:39
オブジェクト指向って、下層がきれいにオブジェクトで整理されてると、
上層でオブジェクト化を行ったり考えたりしなくていいっていう性質があるよね。
いや、良くはないんだけどさ、
作るのと使うのは別で、既に用意されてるんなら作る必要はないってことだな。
本来、オブジェクト指向でもデータ構造に応じたクラスが設計されるべきなんだけど、
ＤＯＭはＤＯＭツリーとして柔軟な扱いを可能としたまま整理したデータを提供するわけで、
クラス設計しなくても、ＤＯＭツリーをうまく扱うことで変更の波及なんかを押さえられるようになった。
上層でオブジェクト化を行ったり考えたりしなくていいっていう性質があるよね。
いや、良くはないんだけどさ、
作るのと使うのは別で、既に用意されてるんなら作る必要はないってことだな。
本来、オブジェクト指向でもデータ構造に応じたクラスが設計されるべきなんだけど、
ＤＯＭはＤＯＭツリーとして柔軟な扱いを可能としたまま整理したデータを提供するわけで、
クラス設計しなくても、ＤＯＭツリーをうまく扱うことで変更の波及なんかを押さえられるようになった。
DOMの操作は汎用化できたとしても、
DOMによって表されるデータ構造に対する処理自体は、
当然のことながらそのデータ構造に特化したものになるわけで、
その辺はCSVファイルをsedやawkで処理するのと大差ないんだよね。
やはりXMLの強みはDOM云々よりもデータ構造としての柔軟性だと思う。
DOMによって表されるデータ構造に対する処理自体は、
当然のことながらそのデータ構造に特化したものになるわけで、
その辺はCSVファイルをsedやawkで処理するのと大差ないんだよね。
やはりXMLの強みはDOM云々よりもデータ構造としての柔軟性だと思う。
ところでXML SchemaなりDTDなりからそのデータ構造を表すBeanのようなクラスを自動生成するツールがあれば便利だと思わんか？
Castor
digester
betwixt
digester
betwixt
DTDでもXML Schemaでもないけど、relaxerもいちおういれておこうか。
手続き型のほうが絶対開発効率いい
でかくなってごちゃごちゃして、自分の頭だけで管理できなくなったら仕方なくオブジェクトにする
でかくなってごちゃごちゃして、自分の頭だけで管理できなくなったら仕方なくオブジェクトにする
まぁ、そういうふうにわりきるのも現実的にはありかもね。
サービス指向って外向けに公開するのはパラメーターと戻り値と処理内容、
これって言ってみれば手続き指向だよね。
現実的にはいろいろ折衷しながらやってくってことかな、結局のところ
サービス指向って外向けに公開するのはパラメーターと戻り値と処理内容、
これって言ってみれば手続き指向だよね。
現実的にはいろいろ折衷しながらやってくってことかな、結局のところ
>>699
http://www.google.co.jp/search?hl=ja&q=%E6%89%8B%E7%B6%9A%E3%81%8D%E6%8C%87%E5%90%91&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
へー495件もあるんだ・・・
もう「専門用語」と呼んでも、おかしくないな。
http://www.google.co.jp/search?hl=ja&q=%E6%89%8B%E7%B6%9A%E3%81%8D%E6%8C%87%E5%90%91&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
へー495件もあるんだ・・・
もう「専門用語」と呼んでも、おかしくないな。
パラダイムとしての「構造化」ってのは
なかった事になってるのか、
それとも「バカばっか」って事なのか…
なかった事になってるのか、
それとも「バカばっか」って事なのか…
>>701
>パラダイムとしての「構造化」ってのは
>なかった事になってるのか、
大丈夫。それもしっかりある。
ほら、こんなに・・・
http://www.google.co.jp/search?hl=ja&q=%E6%A7%8B%E9%80%A0%E5%8C%96%E6%8C%87%E5%90%91&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
>パラダイムとしての「構造化」ってのは
>なかった事になってるのか、
大丈夫。それもしっかりある。
ほら、こんなに・・・
http://www.google.co.jp/search?hl=ja&q=%E6%A7%8B%E9%80%A0%E5%8C%96%E6%8C%87%E5%90%91&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
>>698
オブジェクト指向を理解できない奴の典型的な言い訳ですな。
オブジェクト指向を理解できない奴の典型的な言い訳ですな。
オブジェクト指向を理解できない人は、データをオブジェクトというもので包む方法論だと勘違いしていますね。
そしてメッセージがどうとか、継承がどうとかって話になってくるとたちまち理解できなくなってくる。
オブジェクト指向とは、異なるオブジェクトのインターフェイスを共有することと、
オブジェクトの責任範囲の明確化に、肝があるわけです。
継承とか隠蔽とかデータのカプセル化なんてのはそれを実現するための手段に過ぎないのです。
手段から目的を探るのは非常に困難であると思います。
オブジェクト指向を理解する最善策は、できるだけ優れたクラスライブラリを使い込んでみることかと。
そうすればそんなに難しくは無いはずです。つまり.netでフォームとかコンポーネントとか使ってりゃいいんですよ。
簡単に自然と覚えられます。JavaとかVCLとかでもいいけど。
そしてメッセージがどうとか、継承がどうとかって話になってくるとたちまち理解できなくなってくる。
オブジェクト指向とは、異なるオブジェクトのインターフェイスを共有することと、
オブジェクトの責任範囲の明確化に、肝があるわけです。
継承とか隠蔽とかデータのカプセル化なんてのはそれを実現するための手段に過ぎないのです。
手段から目的を探るのは非常に困難であると思います。
オブジェクト指向を理解する最善策は、できるだけ優れたクラスライブラリを使い込んでみることかと。
そうすればそんなに難しくは無いはずです。つまり.netでフォームとかコンポーネントとか使ってりゃいいんですよ。
簡単に自然と覚えられます。JavaとかVCLとかでもいいけど。
重箱野郎の理論につきあってたらきりがないので、理論は自分で適当なところで見切りをつけてプログラミングしたほうがよい。
>>704
「理解することは簡単。使いこなすのが難しい。」
「理解することは簡単。使いこなすのが難しい。」
カプセル化って意味ねーよな。
実務でしっかりした動作をさせようと思うなら
結局クラスの中身を知らなけりゃならんもん。
俺たちは、オブジェクト指向という言葉に
翻弄・洗脳されているだけなんだよ。
実務でしっかりした動作をさせようと思うなら
結局クラスの中身を知らなけりゃならんもん。
俺たちは、オブジェクト指向という言葉に
翻弄・洗脳されているだけなんだよ。
＞708
そんなまずいつりえさには釣られんぞ
そんなまずいつりえさには釣られんぞ
＞710
そんなまずいつりえさには釣られんぞ
そんなまずいつりえさには釣られんぞ
たしかにいくら
スマートなオブジェクト指向プログラミングをしようとも
ドキュメントが貧弱だから
結局ソースコードを読まなきゃならんという事態は
よくあるような気がする。
フリーのフレームワークとか特に。
スマートなオブジェクト指向プログラミングをしようとも
ドキュメントが貧弱だから
結局ソースコードを読まなきゃならんという事態は
よくあるような気がする。
フリーのフレームワークとか特に。
だからドキュメント整備、隠蔽しているリソースの他の処理との関連性が問題なのであって、
それはカプセル化のせいではないだろう。
OSになってるレベルでさぞかし隠蔽されてますが？
それはカプセル化のせいではないだろう。
OSになってるレベルでさぞかし隠蔽されてますが？
隠蔽、カプセル化とは何か。
他のオブジェクトにアクセスさせないことによって、そのオブジェクトの責任を保障できます。
例えばメンバ変数Ａが更新されたらメンバ変数Ｂも同時に更新しなければならないという契約があるとします。
メンバ変数Ａに外部からアクセスできたらこの契約を果たせなくなります。
だから他のオブジェクトに対してアクセスを限定することで、この契約を守るわけです。
またそのクラスだけがその契約を保守管理すればよくなり、管理が楽になります。
つまり隠蔽やカプセル化は、別にプログラマーに対するものではありません。
その実装内部が見えたとしても隠蔽されていないことにはならないのです。
このへんをしっかり理解していないから>>708のような誤解が生まれるわけです。
他のオブジェクトにアクセスさせないことによって、そのオブジェクトの責任を保障できます。
例えばメンバ変数Ａが更新されたらメンバ変数Ｂも同時に更新しなければならないという契約があるとします。
メンバ変数Ａに外部からアクセスできたらこの契約を果たせなくなります。
だから他のオブジェクトに対してアクセスを限定することで、この契約を守るわけです。
またそのクラスだけがその契約を保守管理すればよくなり、管理が楽になります。
つまり隠蔽やカプセル化は、別にプログラマーに対するものではありません。
その実装内部が見えたとしても隠蔽されていないことにはならないのです。
このへんをしっかり理解していないから>>708のような誤解が生まれるわけです。
そんなすばらしいライブラリ、どんな方法論で作られたとしてもなかなかないのでは？
ていうか、構造化手法だけで作られたライブラリのほうが、中を読まなければならなくなる羽目になるか、
あるいはドキュメントで内部構造を把握しなければならなくなる場合がずっと多い。
ていうか、構造化手法だけで作られたライブラリのほうが、中を読まなければならなくなる羽目になるか、
あるいはドキュメントで内部構造を把握しなければならなくなる場合がずっと多い。
正直理論的にどうこうというより、自分で作りたいものをがんがん作ってるとそのうちにどんな風にまとめたらいいかわかってくると思う。
そこで隠蔽のありがたさなど実感すれば(・∀・)ｲｲ!!。
そこで隠蔽のありがたさなど実感すれば(・∀・)ｲｲ!!。
勉強するのが面倒だから難癖つけて逃げてるだけだよ。
自分の経験では、たとえ先入観を持っている人でも、
基本的にデキる技術者ならば、しばらくC++でも使わせていれば
ちょっとアドバイスする程度で簡単にクリアしてくるね。
そして彼らがオブジェクト指向を捨てて構造化に戻ってくることでは、
自分の知人に限れば、１００％ないです。
自分の経験では、たとえ先入観を持っている人でも、
基本的にデキる技術者ならば、しばらくC++でも使わせていれば
ちょっとアドバイスする程度で簡単にクリアしてくるね。
そして彼らがオブジェクト指向を捨てて構造化に戻ってくることでは、
自分の知人に限れば、１００％ないです。
じぶんはC++ からプログラムは言ったようなものだけど、オブジェクトすてて構造化でやる必要がまったく見出せない。
オブジェクトに責任を持たせる＆多態させる＆他のクラスとあまりからませないのが設計の基本
オブジェクトに責任を持たせる＆多態させる＆他のクラスとあまりからませないのが設計の基本
オブジェクト指向プログラミングと設計を混同するな
プログラムからオブジェクト指向に入ると、
機能の継承をおこなおうとするPGが乱発するだけだ
プログラムからオブジェクト指向に入ると、
機能の継承をおこなおうとするPGが乱発するだけだ
>>720
だからスレタイの通りなんだよ
単純なコーディングでは済まされない、
コーディングする人間ひとりひとりが設計に自覚的に
ならないといかん。
じゃなきゃできる人ががっつりと詳細までクラス図書くしかない。
だからスレタイの通りなんだよ
単純なコーディングでは済まされない、
コーディングする人間ひとりひとりが設計に自覚的に
ならないといかん。
じゃなきゃできる人ががっつりと詳細までクラス図書くしかない。
722 ：在日外国人参政権反対：04/10/26 05:48:56
＞720
混同するというより不可分だろ？
その設計の具体化なんだから。
こういうとまたたくさんつれると思うが
混同するというより不可分だろ？
その設計の具体化なんだから。
こういうとまたたくさんつれると思うが
OOは指向、思考であって設計時に必要な概念だ
つまり設計せずいきなりコーディングするタイプの人には
向かないということだな
わからないと嘆いているのはそういう人たちだろ
つまり設計せずいきなりコーディングするタイプの人には
向かないということだな
わからないと嘆いているのはそういう人たちだろ
いきなりコーディングする時も便利な気がするけど。 徐々に拡張
していけるし。
していけるし。
725 ：在日外国人参政権反対：04/10/26 12:23:59
あのうなんでそんなにPGと設計を分けたがるんですか？
プログラムするときのこと考えて設計して、でプルグラムしながらまた設計修正したりするの当たり前にやってますが。
プログラムするときのこと考えて設計して、でプルグラムしながらまた設計修正したりするの当たり前にやってますが。
なぜOOPを覚えた後にOOを覚えてはいかんの？
>プログラムからオブジェクト指向に入ると、
>機能の継承をおこなおうとするPGが乱発するだけだ
それはまだOOPを覚えた段階だよね。
そこからOOを覚えていけばよいのでは。
たとえ今はそうでも、いずれ実装継承とインターフェイス継承の違いも
説明すれば理解できるようになっていくと思われ。
>プログラムからオブジェクト指向に入ると、
>機能の継承をおこなおうとするPGが乱発するだけだ
それはまだOOPを覚えた段階だよね。
そこからOOを覚えていけばよいのでは。
たとえ今はそうでも、いずれ実装継承とインターフェイス継承の違いも
説明すれば理解できるようになっていくと思われ。
OOP覚える前にOOでいいじゃん
そっちの方がオブジェクト指向の考え方としては自然
OOPやってオブジェクト指向を覚えた気にならないでほしいな
クラスの意味もわからずに、継承や多相を連発すんなって
それ間違ってる可能性が高いから。
そっちの方がオブジェクト指向の考え方としては自然
OOPやってオブジェクト指向を覚えた気にならないでほしいな
クラスの意味もわからずに、継承や多相を連発すんなって
それ間違ってる可能性が高いから。
OOを覚えてからOOPを覚えた人っているの？
たいていの人は同時並行的に覚えていくものだと思うけど。
たいていの人は同時並行的に覚えていくものだと思うけど。
よく考えたら、クラスの意味が解らずに継承を連発するってのは、
それOOPですらないのでは。
OO言語を使えばOOPになるわけじゃないよ。
それOOPですらないのでは。
OO言語を使えばOOPになるわけじゃないよ。
731 ：在日外国人参政権反対：04/10/26 23:35:43
作りながら出ないとわからんよ
732 ：仕様書無しさん：04/10/27 22:21:46
オブジェクト指向とはこういうものだっていうふうに、
きれいに割り切れる概念ではないと思うんだよね。
結局、経験則から帰納的に導かれた、割と泥臭い概念だろう。
そこを勘違いして、一貫性のある完璧な概念だなんて誤解するやつがいるから、
世の中に使えないMDAツールや自称モデラーがあふれるんだよ。
前のプロジェクトで、製造工程を経験したことのないモデラーいたのにはびびったねw
きれいに割り切れる概念ではないと思うんだよね。
結局、経験則から帰納的に導かれた、割と泥臭い概念だろう。
そこを勘違いして、一貫性のある完璧な概念だなんて誤解するやつがいるから、
世の中に使えないMDAツールや自称モデラーがあふれるんだよ。
前のプロジェクトで、製造工程を経験したことのないモデラーいたのにはびびったねw
クソみたいなOO設計(と言えるのかすら疑問だが)の
プロジェクトに途中から入るのが最悪。
どうにもこうにも拡張性がなくて、再利用が利くように
リファクタリングをさせてくれと言ったら言葉すら知らなかった。
結局コピペか継承しかやりようがなくて後者を選んだわけだが・・・
プロジェクトに途中から入るのが最悪。
どうにもこうにも拡張性がなくて、再利用が利くように
リファクタリングをさせてくれと言ったら言葉すら知らなかった。
結局コピペか継承しかやりようがなくて後者を選んだわけだが・・・
OO初心者って単なる差分プログラミングな継承好きだよね
あとコンパイル通すために全部クラスメソッドにしたりするの
まぁうちの上司のことなんだけどさ・・・orz
上のほうでだれか言ってたけど
JavaでもC#でも標準ライブラリのクラス構造を理解するのは勉強になるよ
デザインパターンの具体例としても参考にできるし
あとコンパイル通すために全部クラスメソッドにしたりするの
まぁうちの上司のことなんだけどさ・・・orz
上のほうでだれか言ってたけど
JavaでもC#でも標準ライブラリのクラス構造を理解するのは勉強になるよ
デザインパターンの具体例としても参考にできるし
>732
オブジェクト指向の道標は先人達の努力で存在しているが、
現状では、その道標を辿らずに、その道標を作るための道具を
喜んで使っているのみ(UMLしかり、Javaしかり)
同じ道を歩んでこそ、本質は見える。
文献を読め、Booch、OMT、OOSEは必須だ。
そして考えろ、オブジェクト指向で思考しろ。
自分で答えを導き出せたときが、理解したときだ。
オブジェクト指向の道標は先人達の努力で存在しているが、
現状では、その道標を辿らずに、その道標を作るための道具を
喜んで使っているのみ(UMLしかり、Javaしかり)
同じ道を歩んでこそ、本質は見える。
文献を読め、Booch、OMT、OOSEは必須だ。
そして考えろ、オブジェクト指向で思考しろ。
自分で答えを導き出せたときが、理解したときだ。
つまりやっぱりOOは難しいってところに行き着きそうだ
オブジェクト指向なんて時代遅れだよ。
これからは55歳現役PGｳﾗﾓﾃｨこと浦本勝久さん考案のサブジェクト指向だよ。
SOについては氏のホームページを見てみろ。
これからは55歳現役PGｳﾗﾓﾃｨこと浦本勝久さん考案のサブジェクト指向だよ。
SOについては氏のホームページを見てみろ。
本当に難しいのは、プログラム設計そのものの難しさ。
OOはプログラム設計という難しい分野を扱っているから難しく見えるだけで、
OOそのものはその難しいプログラム設計を整理して楽にするものだよ。
OOはプログラム設計という難しい分野を扱っているから難しく見えるだけで、
OOそのものはその難しいプログラム設計を整理して楽にするものだよ。
部屋が片付いてる方が彼女を呼んでも差別されないけど
部屋をちらかすより片付ける方が難しい
って事ですね。
部屋をちらかすより片付ける方が難しい
って事ですね。
そのたとえは理解できないけど…。
構造化設計もソフトウェア設計の難しさを簡易化するためのものだけど、
ソフトウェア設計の全ての側面を網羅しているとは言えなかった。むしろザル。
だから構造化設計そのものの奥は比較的浅い。
一方、オブジェクト指向は構造化設計を含有する、
ソフトウェア設計をより広くサポートしている設計手法。
だからこれまで分析し切れなかった、設計の難しい面も分析しなければならなくなる。
構造化設計もソフトウェア設計の難しさを簡易化するためのものだけど、
ソフトウェア設計の全ての側面を網羅しているとは言えなかった。むしろザル。
だから構造化設計そのものの奥は比較的浅い。
一方、オブジェクト指向は構造化設計を含有する、
ソフトウェア設計をより広くサポートしている設計手法。
だからこれまで分析し切れなかった、設計の難しい面も分析しなければならなくなる。
しかしその難しい部分をサポートしているがゆえに、
オブジェクト指向が難しいと誤解してしまう人がいるってこと。
オブジェクト指向が難しいと誤解してしまう人がいるってこと。
742 ：仕様書無しさん：04/10/28 22:53:56
構造化だって奥深いじゃん
スパゲティプログラムだってなかなかに奥深いぞ。
744 ：仕様書無しさん：04/10/28 23:22:07
素晴らしいプログラムは「なんだこんなもんか」と思えるくらい簡単です。
オブジェクト指向が話題になりはじめた10年くらい前、
まだVBが流行っていた頃、最初に言われてたメリットって、
完成したオブジェクトの「使いまわし」
でいかに楽にシステムを構築するかってことだったと記憶しているんだよね。
でも、実際、10経った今も、システム規模に対するコストの比って変わってない
というか悪化している面もあるような・・・。
なんか、気に入っていたソフトがバージョンアップして、重くなったり、
使いにくくなったりしてがっかりすることってあるじゃない？
それと、今のオブジェクト指向って、似ていると思っちゃうのよね。
釣りじゃないよ。正直な感想。
まだVBが流行っていた頃、最初に言われてたメリットって、
完成したオブジェクトの「使いまわし」
でいかに楽にシステムを構築するかってことだったと記憶しているんだよね。
でも、実際、10経った今も、システム規模に対するコストの比って変わってない
というか悪化している面もあるような・・・。
なんか、気に入っていたソフトがバージョンアップして、重くなったり、
使いにくくなったりしてがっかりすることってあるじゃない？
それと、今のオブジェクト指向って、似ていると思っちゃうのよね。
釣りじゃないよ。正直な感想。
VBなんかは変わってないと思うが、
Java .NETなんかの、フレームワークは揃ってきた。
EJB並みのものが昔あったか？
Webサーバもアプリケーションサーバも全部使いまわし。
それは、オブジェクト指向の再利用性に沿ったものだ。
OOSEにも書いてある。
Java .NETなんかの、フレームワークは揃ってきた。
EJB並みのものが昔あったか？
Webサーバもアプリケーションサーバも全部使いまわし。
それは、オブジェクト指向の再利用性に沿ったものだ。
OOSEにも書いてある。
開発者の使いまわしのほうが効果あるじゃん
749 ：仕様書無しさん：04/10/29 10:33:21
>>745
10年位前にVBなんか流行ってないよ。 Ver. 2 位だろ？
10年位前にVBなんか流行ってないよ。 Ver. 2 位だろ？
750 ：仕様書無しさん：04/10/29 11:23:22
結局、折衷技術だから、参考書で出てくるような理想的なＯＯを実践でやることは希だよね。
理想的なＯＯっていうのも、現実的な仕様変更なんかと照らしてみると、実はピントがはずれていて、
書かれているようなクラス作ってもちっとも楽にならなかったりするし。
理想的なＯＯっていうのも、現実的な仕様変更なんかと照らしてみると、実はピントがはずれていて、
書かれているようなクラス作ってもちっとも楽にならなかったりするし。
>>751
多分理想的な、というか普通レベルのクラスが作れていないんじゃないの？
多分理想的な、というか普通レベルのクラスが作れていないんじゃないの？
753 ：在日外国人参政権反対：04/10/30 01:07:49
参考書というのはよくわからんが･･･でざぱたレベルなら通常で作ってると思う･･･
754 ：仕様書無しさん：04/10/30 05:23:07
どうしてDesign Patternに「定石」という訳語を充てなかったんだろう。
OOPは分かりやすくて好きだけどな
Javaみたいに全てがオブジェクトと強制させるスタイルが複雑にしたんじゃないの？
次世代候補のアスペクトJの仕様覗いたら(´д｀)ってなったよ
もうね、OOPなんて便利な構造体ってポジションから抜けんなや
Javaみたいに全てがオブジェクトと強制させるスタイルが複雑にしたんじゃないの？
次世代候補のアスペクトJの仕様覗いたら(´д｀)ってなったよ
もうね、OOPなんて便利な構造体ってポジションから抜けんなや
756 ：仕様書無しさん：04/10/30 09:15:01
OOPって構造化プログラミングに比べると用語の
訳化がされてないのが多いから、それでアレルギー
起こしてる人もいるのかな。
訳化がされてないのが多いから、それでアレルギー
起こしてる人もいるのかな。
757 ：仕様書無しさん：04/10/30 15:55:21
発症してます、はい・・・
多態、継承、汎化。なんだよそれ。
もう少しマシな訳語はないの？
もう少しマシな訳語はないの？
まずおまいがマシな訳語案を出せ
要するにOOPというのはコピペ奨励という訳ね。
>760
正反対
正反対
設計しなけりゃコーディング始められないなんて糞の証拠だ
実装前から完全な設計が出来ると思ってるやつはアフォ
自分はＳＥだからプログラミングなんか出来なくても設計は出来ると思ってるやつはさらにアフォ
あなたの会社にも居ませんか？こんなアフォな上司
自分はＳＥだからプログラミングなんか出来なくても設計は出来ると思ってるやつはさらにアフォ
あなたの会社にも居ませんか？こんなアフォな上司
大手の営業系又は運用保守系SEにはそういう人はいるけど、
それは、そもそもプログラムする機会に乏しいワケだから
しょうがないと思うけど。
それは、そもそもプログラムする機会に乏しいワケだから
しょうがないと思うけど。
>>763
彼はバリバリのコボラーだったんですよきっと。
彼はバリバリのコボラーだったんですよきっと。
>762
設計しないと誰もコーディングできねーだろ
頭で考えるのも設計のうちだ
設計しないと誰もコーディングできねーだろ
頭で考えるのも設計のうちだ
要はバランスだね。
ポイント抑えつつ無駄な事やらないっていう。
ポイント抑えつつね。
ポイント抑えつつ無駄な事やらないっていう。
ポイント抑えつつね。
個人の趣味グラマならともかく
業務の開発ではきちんと設計書書いて
何回もレビューして承認のハンコもらって
それからコーディング開始だろ
開発手法が何であれこれは変わらない
業務の開発ではきちんと設計書書いて
何回もレビューして承認のハンコもらって
それからコーディング開始だろ
開発手法が何であれこれは変わらない
井の中の蛙…
>>770
権威に逆らえないタイプ
権威に逆らえないタイプ
>>770
それは開発方法論だ
それは開発方法論だ
ウォーターフォールだよ
>>770
それはｺﾎﾞﾗに汚染された組織での話。
それはｺﾎﾞﾗに汚染された組織での話。
>>776
コボラの書いたコードでんなことできるわけあるまい？
コボラの書いたコードでんなことできるわけあるまい？
コボラとコラボ
オブジェクト指向は俺に聞け。
なんでも答えてやるよ。
なんでも答えてやるよ。
>>779
ぶっちゃけ何がいいんですか？
ぶっちゃけ何がいいんですか？
>780
隠蔽化
はい、次は？
隠蔽化
はい、次は？
あなたの性行における一連の動作を、オブジェクト指向を使って
表現してください。
表現してください。
>782
要件定義書と仕様書を書いてください。
はい次。
要件定義書と仕様書を書いてください。
はい次。
説明になってないよ。
>784
782は質問になってないよ。
はい、次。
782は質問になってないよ。
はい、次。
オブジェクト指向は難しい
現実の事物に即してオブジェクト指向を分かりやすく解説してくれる
事を期待しての質問だったのに、何も語らないばかりか、質問者に
質問してるよこのヒト・・・
事を期待しての質問だったのに、何も語らないばかりか、質問者に
質問してるよこのヒト・・・
>787
現実の事物をどこまでモデリングするか要件定義が無いとできないだろ。
それが答えになってるよ。
性交における何をモデリングするんだ？
筋肉の動きか？精神状態か？ わかんねーだろ。
だから、要件定義しろといってんだよ。
現実の事物をどこまでモデリングするか要件定義が無いとできないだろ。
それが答えになってるよ。
性交における何をモデリングするんだ？
筋肉の動きか？精神状態か？ わかんねーだろ。
だから、要件定義しろといってんだよ。
>>787
メタファで解説されても「解った気になる」だけ。
メタファで解説されても「解った気になる」だけ。
もうIT業界でウォーターフォールなんてWebページ製作くらいのもんじゃないの？
便利な構造体＝OOP
わかりやすい
これ以上の解釈なんていらへんよ
わかりやすい
これ以上の解釈なんていらへんよ
でもないな
>>791 はC++厨まるだしだな
>791
構造体の無い言語はどうすんだ？
構造体の無い言語はどうすんだ？
795 ：仕様書無しさん：04/11/03 04:38:32
詳細設計とコーディングは同時進行で設計にフィードバックかけるのが効率的
設計段階でクライアントのレビュー受けて承認されるとコーディングなんで
コーディング始まってからのフィードバックで設計変更とか許されないんです
こんなうちの会社って終わってますか？
コーディング始まってからのフィードバックで設計変更とか許されないんです
こんなうちの会社って終わってますか？
コーディング前の設計に間違いがないと想定出る神経が信じられん。
誰でも、どの段階でも、間違いをおかす可能性はある。
下流工程にのみ失敗のしわ寄せをする連中の程度など、たかが知れ
ているが、上流工程の｢上流｣という言葉で、自分達が人一倍高度な事
をやっているという錯覚に陥っている奴が多すぎる。
誰でも、どの段階でも、間違いをおかす可能性はある。
下流工程にのみ失敗のしわ寄せをする連中の程度など、たかが知れ
ているが、上流工程の｢上流｣という言葉で、自分達が人一倍高度な事
をやっているという錯覚に陥っている奴が多すぎる。
>>796
上流工程の人間が非常に優秀で、なおかつ
その後の仕様変更の要因になる顧客の要望を
上手く断れるなら、ウォーターフォールほど楽な
もんはないよ。
本当に優秀な人間は、柔軟な思考の持ち主だと
思うけどね。
日本でアジャイルプロセスってどれぐらい浸透してる
んだろうか・・・
上流工程の人間が非常に優秀で、なおかつ
その後の仕様変更の要因になる顧客の要望を
上手く断れるなら、ウォーターフォールほど楽な
もんはないよ。
本当に優秀な人間は、柔軟な思考の持ち主だと
思うけどね。
日本でアジャイルプロセスってどれぐらい浸透してる
んだろうか・・・
800 ：在日外国人参政権反対：04/11/03 12:09:02
＞799
500人月なんかやりたくない仕事だなおい･･･
がんがれ。
500人月なんかやりたくない仕事だなおい･･･
がんがれ。
>>798
小さいところで上手に採用してるところはあるらしいが…
ほとんどは単価下げるための売り文句＆誤用に終わっている。
だいたい、費用＆期日がカッチリ決まってて「アジャイル」なんて、恥ずかし過ぎて言えるはずないんだがナ…。
小さいところで上手に採用してるところはあるらしいが…
ほとんどは単価下げるための売り文句＆誤用に終わっている。
だいたい、費用＆期日がカッチリ決まってて「アジャイル」なんて、恥ずかし過ぎて言えるはずないんだがナ…。
アジャイルをわかってない素人がいるようだな
どうせ一時的な流行で終わるんだから、必死になって理解する必要なし。
ひっきりなしに革命的な手法が出て来る訳ねーだろ。 おおげさなんだよ。
ひっきりなしに革命的な手法が出て来る訳ねーだろ。 おおげさなんだよ。
その通り。OOなんてあと数年もすりゃ消え去る。
言語も開発手法も、結局はシンプルなものが残る。
ウォーターフォール＋OOでない伝統のCOBOLが最強ということ。
言語も開発手法も、結局はシンプルなものが残る。
ウォーターフォール＋OOでない伝統のCOBOLが最強ということ。
消えるとは言わないが、
理解してる人は希少種だからなぁ
コンサルなんて人もいるくらい。
理解もしてないのに使って失敗ってのもありすぎ。
理解してる人は希少種だからなぁ
コンサルなんて人もいるくらい。
理解もしてないのに使って失敗ってのもありすぎ。
プロマネが理解してればアジャイル出来るよ。
あと、これだけ時間経つと流石に結構浸透してるよ。
あと、これだけ時間経つと流石に結構浸透してるよ。
>>794
OOPを名乗らなければいい
OOPを名乗らなければいい
OOが消えるなら、本当に良いと思うが。そんな事には成りそうにないな。
構造化自体も、構造化をサポートする言語が出てから、普及には二十年ほどかかっている。
OOも同様だろう。いやもっとかかるかもシレン
構造化自体も、構造化をサポートする言語が出てから、普及には二十年ほどかかっている。
OOも同様だろう。いやもっとかかるかもシレン
ポリモフィズムってようはキャストだろ？
インヘリタンスってようはラップだろ？
細かい違いなんてどうでもいいねん、わざわざ分かりにくい言葉で伝えるな
インヘリタンスってようはラップだろ？
細かい違いなんてどうでもいいねん、わざわざ分かりにくい言葉で伝えるな
>>810
もう少しうまい餌にしなよ
もう少しうまい餌にしなよ
言いえて妙だろ
そして「機能追加はいつでも要求できる」ってのもアジャイルの誤用。
金と時間くれるんなら、喜んでやらせていただきます。
しみったれが人並みの要求すんなよ、この貧乏ったれ。 という事です。
しみったれが人並みの要求すんなよ、この貧乏ったれ。 という事です。
age
コボラー世代が上流工程を握ってる間は普及しないだろ
あと１０～２０年は無理だな
あと１０～２０年は無理だな
コボラー世代がいるような業務系では永遠に普及しない
理系では当然のように普及している
理系では当然のように普及している
818 ：仕様書無しさん：04/11/04 22:01:50
この間、妹がパックをしとったんや。
いつもズボンばかりはいとる妹で男っぽい性格やってんけど、
このときばかりは女を感じてん。
みなはんは、そないなことありまっか？
いつもズボンばかりはいとる妹で男っぽい性格やってんけど、
このときばかりは女を感じてん。
みなはんは、そないなことありまっか？
>>819
803が一時の流行と言ってるのはアジャイル開発のことだろ
803が一時の流行と言ってるのはアジャイル開発のことだろ
おそらく９９％以上（もっとか？）の人は、Smalltalkを知らないと思う。
情報処理の言語の歴史に出てくる言語ってだけで・・・。
純粋なオブジェクト指向ってことだか、その後
３０年ちかく業務系のメインストリームから離れたわけで、
そうなってしまったのは、何でなの？
普及するのに時間がかかったからってのは何かウソくせー
情報処理の言語の歴史に出てくる言語ってだけで・・・。
純粋なオブジェクト指向ってことだか、その後
３０年ちかく業務系のメインストリームから離れたわけで、
そうなってしまったのは、何でなの？
普及するのに時間がかかったからってのは何かウソくせー
あるデータとデータの関連が、設計してコーディング始めた後にわかったとする
普通の構造化言語だと、両方のデータを引数にとる関数作っておしまい
オブジェクト指向だとこういうときってどうするんだ？
普段はほとんど関連しないオブジェクト間の操作のために、
オブジェクトの本質と関係ないメソッドを後からくっつけにゃならないなんて
普通の構造化言語だと、両方のデータを引数にとる関数作っておしまい
オブジェクト指向だとこういうときってどうするんだ？
普段はほとんど関連しないオブジェクト間の操作のために、
オブジェクトの本質と関係ないメソッドを後からくっつけにゃならないなんて
業務では
COBOL,VB,CがメインでそこからC++,JAVAになったからでしょう。
SmallTalkはメインフレームでもMSでもメインでなかった。UNIXはCでしょ。
COBOL,VB,CがメインでそこからC++,JAVAになったからでしょう。
SmallTalkはメインフレームでもMSでもメインでなかった。UNIXはCでしょ。
かつ、PerlやPHPのように、ニッチでもなかった、って所ですか？
>>823
×SmallTalk
○Smalltalk
Smalltalkが普及しなかった理由は幾つかあるだろうが
単なる言語ではなく環境を含むというのも大きいだろうな
その点Javaは実行モジュールと実行環境をきっちりと分離して
さらにそれを利用してマルチプラットフォームに持っていったところが上手かった
×SmallTalk
○Smalltalk
Smalltalkが普及しなかった理由は幾つかあるだろうが
単なる言語ではなく環境を含むというのも大きいだろうな
その点Javaは実行モジュールと実行環境をきっちりと分離して
さらにそれを利用してマルチプラットフォームに持っていったところが上手かった
826 ：仕様書無しさん：04/11/05 08:02:00
>>822
簡単な静的メソッド一つ作るにしても、クラスの階層下に作られるオブジェクト指向の方が管理が簡単だと思うんだが。
sample.util.Convertなんて作り方だって、ただの関数ライブラリより、コーディング時には使いやすい。
簡単な静的メソッド一つ作るにしても、クラスの階層下に作られるオブジェクト指向の方が管理が簡単だと思うんだが。
sample.util.Convertなんて作り方だって、ただの関数ライブラリより、コーディング時には使いやすい。
827 ：ｺﾋﾟﾍﾟ推奨：04/11/05 10:22:44
┗┳┳━ |＿| ━━━┳┳┛
┃┃ ／ ヽ ┃┃ もういくつ寝ると 出て行くの
┏┻┻ |======| ━━┻┻┓
┗┳┳ ヽ__ ¶_ ノ ━━┳┳┛ 朝鮮人は ウソついて
┃┃ （／） ┃┃
┃┃ （／） ┃┃ 日本に居座り たかります
凸┃┃ （／） ┃┃凸
Ш┃┃ （／） ┃┃Ш 早く出て行け 朝鮮人♪
.|| ┃┃ （／） ┃┃.||
∧＿∧ （／） ∧＿∧ ∧ ∧
（ ・∀・） （／）（´∀｀ ） <゜Д゜ > 元歌：童謡「お正月」
（つ つミ （／）（⊃⊂ ） ⊂ ⊃
|＿|＿|＿⑩（／）_|＿|＿|＿＿| |
／／／／／ノ,,,,,,ヽ ／／／／|| |～
／／／／／／／／／／／／ |∪∪
|￣￣￣￣￣￣￣￣￣￣￣| |
| 奉 納 |
┃┃ ／ ヽ ┃┃ もういくつ寝ると 出て行くの
┏┻┻ |======| ━━┻┻┓
┗┳┳ ヽ__ ¶_ ノ ━━┳┳┛ 朝鮮人は ウソついて
┃┃ （／） ┃┃
┃┃ （／） ┃┃ 日本に居座り たかります
凸┃┃ （／） ┃┃凸
Ш┃┃ （／） ┃┃Ш 早く出て行け 朝鮮人♪
.|| ┃┃ （／） ┃┃.||
∧＿∧ （／） ∧＿∧ ∧ ∧
（ ・∀・） （／）（´∀｀ ） <゜Д゜ > 元歌：童謡「お正月」
（つ つミ （／）（⊃⊂ ） ⊂ ⊃
|＿|＿|＿⑩（／）_|＿|＿|＿＿| |
／／／／／ノ,,,,,,ヽ ／／／／|| |～
／／／／／／／／／／／／ |∪∪
|￣￣￣￣￣￣￣￣￣￣￣| |
| 奉 納 |
828 ：ｺﾋﾟﾍﾟ推奨：04/11/05 10:25:54
http://www.geocities.com/naverchat/CyberTerrorism01/
特にヨーロッパ・アメリカ・オーストラリアなど先進国たちの一部ネチズンたちはチャット空間で韓国人だと明らかにすれば弾き出す
とか集団的に退場して捨てるなど韓国人に対して反感を持っていることで現われた.
バンクフェワンドルの海外ペンパル(http://www.prkorea.com/vankop10_5.html)と海外チャットサイト訪問経験(http://www.prkorea.com/vankop10_4.html)
を打ち明けた掲示板には外国ネチズンたちに ‘門前薄待’当ぎりネチズンたちの事情が並んでいる.
海外チャットを始めてからひと月頃なったと言うバンクフェワン精米領さんは
“韓国出身だと言えば有り難がらない場合が 70%ほどされた”と “その時ごとに気持ちが悪かった”と打ち明けた
特にヨーロッパ・アメリカ・オーストラリアなど先進国たちの一部ネチズンたちはチャット空間で韓国人だと明らかにすれば弾き出す
とか集団的に退場して捨てるなど韓国人に対して反感を持っていることで現われた.
バンクフェワンドルの海外ペンパル(http://www.prkorea.com/vankop10_5.html)と海外チャットサイト訪問経験(http://www.prkorea.com/vankop10_4.html)
を打ち明けた掲示板には外国ネチズンたちに ‘門前薄待’当ぎりネチズンたちの事情が並んでいる.
海外チャットを始めてからひと月頃なったと言うバンクフェワン精米領さんは
“韓国出身だと言えば有り難がらない場合が 70%ほどされた”と “その時ごとに気持ちが悪かった”と打ち明けた
>822
それだけの説明だとちょっと足らないな・・・・。
けど、
>あるデータとデータの関連が、設計してコーディング始めた後にわかったとする
こう書いて
>オブジェクトの本質と関係ないメソッドを後からくっつけにゃならないなんて
これは無いと思うが、やはり情報が足らないな・・・・。
それだけの説明だとちょっと足らないな・・・・。
けど、
>あるデータとデータの関連が、設計してコーディング始めた後にわかったとする
こう書いて
>オブジェクトの本質と関係ないメソッドを後からくっつけにゃならないなんて
これは無いと思うが、やはり情報が足らないな・・・・。
830 ：在日外国人参政権反対：04/11/05 11:14:39
＞822
それって問題のデータ（クラス）に対する操作の問題であって、2者間の設計に関することじゃないと思うんだが。
該当するクラスに対して関数（もしくは別のクラスでその二つを引数ととる性的メソッド）をつくるとして構造体とクラスの違いは内部データへのアクセス権限以外にないでしょ？
その関数で行う操作が既存のパブリックメソッドで十分ならば設計に問題ないしないならアクセス方法に不備があるとして追加すればいいだけ。
互いのクラスに相手を認識させることを言ってるのかもしれないが、それがクラスの本質ならば設計ミスだろうが、その責任を他のクラスが負うべきならば互いのクラスに背負わすのは間違い。
それって問題のデータ（クラス）に対する操作の問題であって、2者間の設計に関することじゃないと思うんだが。
該当するクラスに対して関数（もしくは別のクラスでその二つを引数ととる性的メソッド）をつくるとして構造体とクラスの違いは内部データへのアクセス権限以外にないでしょ？
その関数で行う操作が既存のパブリックメソッドで十分ならば設計に問題ないしないならアクセス方法に不備があるとして追加すればいいだけ。
互いのクラスに相手を認識させることを言ってるのかもしれないが、それがクラスの本質ならば設計ミスだろうが、その責任を他のクラスが負うべきならば互いのクラスに背負わすのは間違い。
>>822
＞普通の構造化言語だと、両方のデータを引数にとる関数作っておしまい
ああ、これぞ理解不能プログラムのモトだな。
後にその関数には、
/*よく分からんからとりあえず触らないでおく↓*/
という具合のコメントが追加されることになるわけだ。
これを連発した挙句に行き付くモノを避けるためのオブジェクト指向。
無節操にアドホックな関数を量産できてしまうのは、
つまりは設計が不在だという証拠なんだよね。
オブジェクト指向だと、その処理はどのクラスが責任を負うべきかという
最低限の設計が常に強制されることになる。
＞普通の構造化言語だと、両方のデータを引数にとる関数作っておしまい
ああ、これぞ理解不能プログラムのモトだな。
後にその関数には、
/*よく分からんからとりあえず触らないでおく↓*/
という具合のコメントが追加されることになるわけだ。
これを連発した挙句に行き付くモノを避けるためのオブジェクト指向。
無節操にアドホックな関数を量産できてしまうのは、
つまりは設計が不在だという証拠なんだよね。
オブジェクト指向だと、その処理はどのクラスが責任を負うべきかという
最低限の設計が常に強制されることになる。
抜け道があるから一緒。 馬鹿にいじらせたら、その時点で
どんな強制も存在しなくなる。
どんな強制も存在しなくなる。
ここまで読んで思ったのだが、ＯＯを語るには、やはり設計手法から語るべきなんじゃないかな。
結局ＣＰＵが実行するマシン語に翻訳されるという点では、処理系や言語に差異はないか、
寧ろ高級言語ほど不利になっていく傾向がある。そして、その裏として寧ろ設計におけるシンプルで
柔軟な哲学を持つという点で高級言語に存在価値があるわけだ。
ＯＯについて考えるには、例えばＵＭＬ記法を用いた設計手法についてまず考察する必要が
あるんだと思う。
>822
”関連”クラスを作って、各データを有するクラスを委譲。
オブジェクト指向「設計」のフォーカスは、クラスのインターフェイス設計ではなく、
クラス間の関連だよ。関連が重要だからUMLやデザインパターンが重宝される。
オブジェクトを小さく保つことでオブジェクトが背負うべき責任が小さくなり、
実装がシンプルになる。しかしそのぶん関連は複雑になる。
だから関連を整理する設計手法が整備されてきた。
関連を語らずしてオブジェクト指向を語る事なかれ。
クラス間の関連だよ。関連が重要だからUMLやデザインパターンが重宝される。
オブジェクトを小さく保つことでオブジェクトが背負うべき責任が小さくなり、
実装がシンプルになる。しかしそのぶん関連は複雑になる。
だから関連を整理する設計手法が整備されてきた。
関連を語らずしてオブジェクト指向を語る事なかれ。
Smalltalkが普及しなかった最大の理由は、
「遅いから」だ。
「遅いから」だ。
Javaも出始め頃はどっこいどっこいだったのに普及したぞ？
839 ：仕様書無しさん：04/11/06 00:26:00
クラスの粒度が小さいと責務が明確になってわかりやすくなるし
テストもしやすくなるんだけど、その分クラス間の依存関係が複雑になるんだよね。
依存関係が複雑にならないようにクラス間の依存関係はなるべく一方方向にするとか
循環参照はしないとか、またパッケージ間の依存関係にもそれを応用するなんてことが
必要になる。
カプセル化の概念をクラスの中だけでなく外まで拡大するとよりわかりやすくなる。
テストもしやすくなるんだけど、その分クラス間の依存関係が複雑になるんだよね。
依存関係が複雑にならないようにクラス間の依存関係はなるべく一方方向にするとか
循環参照はしないとか、またパッケージ間の依存関係にもそれを応用するなんてことが
必要になる。
カプセル化の概念をクラスの中だけでなく外まで拡大するとよりわかりやすくなる。
OOPは理解できるプログラマと理解できないプログラマがいるのは確かだ。
まずクラスとモジュールの区別がつかない人が多い。
クラス＝設計図、インスタンス＝設計図を元に作られた実体
という事を言うと、そういう現実世界の物をプログラムに当てはめるの
おかしくない？とかいう返答が帰ってくる事がある・・・
まずクラスとモジュールの区別がつかない人が多い。
クラス＝設計図、インスタンス＝設計図を元に作られた実体
という事を言うと、そういう現実世界の物をプログラムに当てはめるの
おかしくない？とかいう返答が帰ってくる事がある・・・
>843
最終的に親にメソッドが集まってる場合には、
継承が機能の継承になってる場合が多い
内包の継承が正しくおこなわれているのならば、
親クラスに集中するのは仕方ない。
最終的に親にメソッドが集まってる場合には、
継承が機能の継承になってる場合が多い
内包の継承が正しくおこなわれているのならば、
親クラスに集中するのは仕方ない。
>>842
関係するオブジェクトとは、少なくとも一方が他方のポインタを有しているか取得可能な状態にあって、
それよりもう少し深く関係するオブジェクトは、一方が他方のメソッドを呼び出せる状態にあるわけだよな。
更に深く関係するオブジェクトは、相互にポインタを有しているか取得可能な状態にあるとすると、
俺たちが考える結合度合いというのは、２段階目のバリエーション、つまり、あるメソッドを呼び出す
その方法-呼び出し手順と呼び出される手順とからなる一連の手順-によって計られるものなわけだ。
もちろん、単一のメソッドの呼び出しで済むとは限らないわけだけど。
関係するオブジェクトとは、少なくとも一方が他方のポインタを有しているか取得可能な状態にあって、
それよりもう少し深く関係するオブジェクトは、一方が他方のメソッドを呼び出せる状態にあるわけだよな。
更に深く関係するオブジェクトは、相互にポインタを有しているか取得可能な状態にあるとすると、
俺たちが考える結合度合いというのは、２段階目のバリエーション、つまり、あるメソッドを呼び出す
その方法-呼び出し手順と呼び出される手順とからなる一連の手順-によって計られるものなわけだ。
もちろん、単一のメソッドの呼び出しで済むとは限らないわけだけど。
>>843
数じゃなくて、機能性だろうな。
高機能でインテリジェントなメソッドこそ使いやすい。
ただおせっかいは困るので、低機能→高機能なメソッドがずらっと付くこともある。
この場合は、数も関係してくるかな。
数じゃなくて、機能性だろうな。
高機能でインテリジェントなメソッドこそ使いやすい。
ただおせっかいは困るので、低機能→高機能なメソッドがずらっと付くこともある。
この場合は、数も関係してくるかな。
まさに群盲象をなでる感を否めないな。
一人が象の鼻先をなでて象は蛇のような生き物だといい、
一人が足をなでて亀のような生き物だといい、
別の一人は脚をなでて巨木のような生き物だと言う。
名前忘れたけどポインタ本の著者のOO論なんかもこの類だよねえ。
一段抽象度が高い概念を、無理に即物的に理解しようとするとこうなる。
この混乱の原因は、個人的にはOOの要素に関して単に工学的な観点の分類――何物であるか――
しか行われておらず、機能主義的な観点の分類――どういう有り難味か――が
不十分なためだと思う。
一人が象の鼻先をなでて象は蛇のような生き物だといい、
一人が足をなでて亀のような生き物だといい、
別の一人は脚をなでて巨木のような生き物だと言う。
名前忘れたけどポインタ本の著者のOO論なんかもこの類だよねえ。
一段抽象度が高い概念を、無理に即物的に理解しようとするとこうなる。
この混乱の原因は、個人的にはOOの要素に関して単に工学的な観点の分類――何物であるか――
しか行われておらず、機能主義的な観点の分類――どういう有り難味か――が
不十分なためだと思う。
愚にも付かない能書きたれるなよ。 余計混乱するわ。
個別の機能をバラバラに議論してもだめだな。それはわかる。
OOPもね、チームや会社単位で啓蒙活動しないと
自分だけがOOP極めてもあんまり意味がない。
それどころか、わけがわからないとクレームが殺到して
コードのメンテを全部自分がさせられたりする罠orz
自分だけがOOP極めてもあんまり意味がない。
それどころか、わけがわからないとクレームが殺到して
コードのメンテを全部自分がさせられたりする罠orz
自力でついて来れないやつはついてこなくていい。邪魔なだけだ。
それなりのところでは数年前から当たり前のように普及しているわけだが。
ただ業務アプリみたいに簡単な仕事では、いかに手っ取り早く安い技術者を見つけて
金を浮かせるかのほうが重要だから、多少の冗長性には目をつむって馬鹿でも理解できるような
単純なつくりにしといたほうがいい。
ただ業務アプリみたいに簡単な仕事では、いかに手っ取り早く安い技術者を見つけて
金を浮かせるかのほうが重要だから、多少の冗長性には目をつむって馬鹿でも理解できるような
単純なつくりにしといたほうがいい。
>>853
＞多少の冗長性には目をつむって馬鹿でも理解できるような単純なつくりにしといたほうがいい。
という思想でやってきた結果、膨大な冗長性が生じて、天才にも理解できないような
奇怪なコードが量産された反省からオブジェクト指向が普及したってわけだな。
＞多少の冗長性には目をつむって馬鹿でも理解できるような単純なつくりにしといたほうがいい。
という思想でやってきた結果、膨大な冗長性が生じて、天才にも理解できないような
奇怪なコードが量産された反省からオブジェクト指向が普及したってわけだな。
業務系の場合、多態なんか理解できないレベルの人間が多いし、多態を使ったところで
生産性拡張性保守性が上がるような複雑な処理でもないんだから禁止したほうがいい。
カプセル化だけ徹底しとけ。
つうか業務アプリ用にカプセル化だけをサポートした言語を作ったほうがいいな。
継承や多態を覚えたての素人がわけのわからん糞コードを書くのを物理的に禁止できるように
したほうがいい。
生産性拡張性保守性が上がるような複雑な処理でもないんだから禁止したほうがいい。
カプセル化だけ徹底しとけ。
つうか業務アプリ用にカプセル化だけをサポートした言語を作ったほうがいいな。
継承や多態を覚えたての素人がわけのわからん糞コードを書くのを物理的に禁止できるように
したほうがいい。
>継承や多態を覚えたての素人がわけのわからん糞コードを
単にお前が他人のコードを読めないだけとちゃうんかと小一時間・・・
単にお前が他人のコードを読めないだけとちゃうんかと小一時間・・・
オブジェクト指向についてこのスレッドで勉強させて頂きました。
中々面白いですね。
ＰＭが全体を把握していれば、ＰＧは全体把握せずとも機能単位での修正ができる。
確かに今までのプログラムってサブルーチンや関数を作って上手く細分化したつもりでも、
変数の局所化の具合を調査したり関数呼び出し元の前後ソースを読む必要があったんだけど
この方法だとそれはしなくて良くなる感じがした。
事故でＰＧが急遽減った場合など次のＰＧが凄く入り安い。
でも思う所オブジェクト指向しかしたことないＰＧはこの先もずっとＰＧしかできなくなる感じがする。
その辺りもご教授お願いします。
ＰＭ、ＳＥ、ＰＧの細分化も目指されているのでしょうか？
中々面白いですね。
ＰＭが全体を把握していれば、ＰＧは全体把握せずとも機能単位での修正ができる。
確かに今までのプログラムってサブルーチンや関数を作って上手く細分化したつもりでも、
変数の局所化の具合を調査したり関数呼び出し元の前後ソースを読む必要があったんだけど
この方法だとそれはしなくて良くなる感じがした。
事故でＰＧが急遽減った場合など次のＰＧが凄く入り安い。
でも思う所オブジェクト指向しかしたことないＰＧはこの先もずっとＰＧしかできなくなる感じがする。
その辺りもご教授お願いします。
ＰＭ、ＳＥ、ＰＧの細分化も目指されているのでしょうか？
>>でも思う所オブジェクト指向しかしたことないＰＧはこの先もずっとＰＧしかできなくなる感じがする。
これは何故そう感じたんだ？
これは何故そう感じたんだ？
多態を理解するより、冗長だらけの「コピペ指向」
のコードを読むほうがよほど時間かかるんだが・・・
のコードを読むほうがよほど時間かかるんだが・・・
860 ：仕様書無しさん：04/11/07 01:36:37
>>857
>>でも思う所オブジェクト指向しかしたことないＰＧはこの先もずっとＰＧしかできなくなる感じがする。
これは、真偽は別としてものすごい反感買いそうな発言だな。
オレも根拠を聞きたい。
察すると、
客や要件定義やってるような人間は究極的に馴染めないだろうってことだろうか。
でもさ、現状、設計はＵＭＬじゃないとオフショアで仕事受けてくれないよ。
組み込みは先にＵＭＬにいっちゃってるし。例外もあるだろうけど。
>>でも思う所オブジェクト指向しかしたことないＰＧはこの先もずっとＰＧしかできなくなる感じがする。
これは、真偽は別としてものすごい反感買いそうな発言だな。
オレも根拠を聞きたい。
察すると、
客や要件定義やってるような人間は究極的に馴染めないだろうってことだろうか。
でもさ、現状、設計はＵＭＬじゃないとオフショアで仕事受けてくれないよ。
組み込みは先にＵＭＬにいっちゃってるし。例外もあるだろうけど。
>>853
もうさ、現状を見てると、（カスタマイズ可能な）パッケージが市場を席巻するっていうことが
明らかになってるわけよ。
これは、おそらく市場が世界規模へと吸収統一されていったからなんだろうけどね。
実際、業務用ではパッケージ導入＆カスタマイズ屋さんになってるＳＩｅｒも少なくないでしょ。
中小規模の新規開発の事例をパンフでみても、どっかで見たようなやつだし。
コストも、この方が安いしね。
言いたいことはわかるけど、>>853の認識は古くないかな。
もうさ、現状を見てると、（カスタマイズ可能な）パッケージが市場を席巻するっていうことが
明らかになってるわけよ。
これは、おそらく市場が世界規模へと吸収統一されていったからなんだろうけどね。
実際、業務用ではパッケージ導入＆カスタマイズ屋さんになってるＳＩｅｒも少なくないでしょ。
中小規模の新規開発の事例をパンフでみても、どっかで見たようなやつだし。
コストも、この方が安いしね。
言いたいことはわかるけど、>>853の認識は古くないかな。
862 ：仕様書無しさん：04/11/07 01:50:01
>>851
でもさ、誰かが志を高く持ってやり始めないと、日本のＩＴ技術は壊滅までいくんじゃないかな？
周りが駄目だから自分がやっても無駄だっていうのは、落ちこぼれの発想だと思わないか？
わざわざ休日に、２ｃｈのスレに書き込むんだったら、どうせだし、ポジティブにいこうぜ。
でもさ、誰かが志を高く持ってやり始めないと、日本のＩＴ技術は壊滅までいくんじゃないかな？
周りが駄目だから自分がやっても無駄だっていうのは、落ちこぼれの発想だと思わないか？
わざわざ休日に、２ｃｈのスレに書き込むんだったら、どうせだし、ポジティブにいこうぜ。
>>でもさ、誰かが志を高く持ってやり始めないと、日本のＩＴ技術は壊滅までいくんじゃないかな？
日本とは言わないまでも自分の会社の現状とか見ても危機感はあるね
しかし現実問題として危機感すらないやつらがあまりにも多すぎるんだよ
日本とは言わないまでも自分の会社の現状とか見ても危機感はあるね
しかし現実問題として危機感すらないやつらがあまりにも多すぎるんだよ
864 ：仕様書無しさん：04/11/07 02:03:59
>>862-863
具体的に何を始めればいいですか？
具体的に何を始めればいいですか？
>>855
他の技術者と比べた場合の、プログラマのレベルの低さは目立つよな。
オレが詳しいからかもしれないけど。 あ、オレはソフトに関わるけど専門じゃないです。
やっぱり、学問体系ができてないからだろうかね。
電磁気学みたいに普遍的真理が大成されてるわけじゃないでしょ。
特に、業務系はハードウェア・リソースが潤沢で、開発環境もバカチョン化に向かってる。
こういう現状を踏まえてＯＯの利点を考えると、やっぱりプロジェクト管理の容易性なんか
に目がいくよね。 あと、品質の保証、コードの再利用とか。そうすると、業務系なんかでは
設計者がこういった点を考慮してしっかり継承なんかを設計しておく必要があるわけだ。
低レベルなプログラマ（コーダ？）にクラスなんて作らせちゃだめだと。
裏を返すと、おまいがしっかりＯＯを勉強して設計し、きっちりしたコーディング規約を設定しろということになる。
他の技術者と比べた場合の、プログラマのレベルの低さは目立つよな。
オレが詳しいからかもしれないけど。 あ、オレはソフトに関わるけど専門じゃないです。
やっぱり、学問体系ができてないからだろうかね。
電磁気学みたいに普遍的真理が大成されてるわけじゃないでしょ。
特に、業務系はハードウェア・リソースが潤沢で、開発環境もバカチョン化に向かってる。
こういう現状を踏まえてＯＯの利点を考えると、やっぱりプロジェクト管理の容易性なんか
に目がいくよね。 あと、品質の保証、コードの再利用とか。そうすると、業務系なんかでは
設計者がこういった点を考慮してしっかり継承なんかを設計しておく必要があるわけだ。
低レベルなプログラマ（コーダ？）にクラスなんて作らせちゃだめだと。
裏を返すと、おまいがしっかりＯＯを勉強して設計し、きっちりしたコーディング規約を設定しろということになる。
>>863
ＯＯを語るスレなんで、愚痴るのは他のスレにしようよ。
ＯＯを語るスレなんで、愚痴るのは他のスレにしようよ。
>>864
個人が自発的に学習し、その内容について他人と議論することで創発的に集団が学習するのが理想
だとおもう。この場合、まず個人が自発的であって、指示待ち人間でないことが必要になるわけだけど、
当然質問することは良いことなんで、僕個人としての意見を述べると、（長い前置き完読ご苦労）
ネットや書籍で学習し、自分で実践したり問答したりして、その過程や得た知識を２ｃｈのスレに書き込む
というのはどうだろうか。 つまり、例えばこのスレに貢献しろってこった。
個人が自発的に学習し、その内容について他人と議論することで創発的に集団が学習するのが理想
だとおもう。この場合、まず個人が自発的であって、指示待ち人間でないことが必要になるわけだけど、
当然質問することは良いことなんで、僕個人としての意見を述べると、（長い前置き完読ご苦労）
ネットや書籍で学習し、自分で実践したり問答したりして、その過程や得た知識を２ｃｈのスレに書き込む
というのはどうだろうか。 つまり、例えばこのスレに貢献しろってこった。
>>856
そういうお前は煽りたいだけちゃうんかと。
そういうお前は煽りたいだけちゃうんかと。
>>867
当たり前すぎて腰が抜けた。
当たり前すぎて腰が抜けた。
「コードの再利用」というと様々な場面が想定されやすいので、
重要な要素を明確にしておきたい。
「コードの再利用」の中で最も重要な要素とは「汎用部分のパッケージ化」だ。
翼システムのSVFみたいな完全に分離できてるものが一番わかりやすいね。
ああいうのはオブジェクト指向の中でもプロダクト指向と言った方がいいかな。
半端に入り組んだビジネスロジックは、
「コードの再利用」を行おうとすると逆に手直しが多くて混乱を招くことが多い。
かといってある程度固まった仕様の中からカスタマイズのみで対応するものだと
特殊な要件を実現できなくなり場合によっては競争力を欠いてしまうこともありえる。
したがって今後重要視されるべきなのは、完全に分離できる部分の確立、
要するに確実に再利用できる部分の確立だ。
こんなの車のパーツにでも例えれば一発でわかることだと思うんだが、
高い技術力を持っていながら提案できる立場にもいる人間が思ったより少ないせいで、
プロジェクトメンバー総火の玉で突っ込んでグダグダで終わらせて
あとは何も考えず満足ってケースが思ったより多い。
実際は上手くプロダクト指向を確立できるとしてもなかなか気付かない。
力技でゴリ押しして、中国インドでも済むような仕事をしてるところは
そのうち痛い目見るだろうね。
重要な要素を明確にしておきたい。
「コードの再利用」の中で最も重要な要素とは「汎用部分のパッケージ化」だ。
翼システムのSVFみたいな完全に分離できてるものが一番わかりやすいね。
ああいうのはオブジェクト指向の中でもプロダクト指向と言った方がいいかな。
半端に入り組んだビジネスロジックは、
「コードの再利用」を行おうとすると逆に手直しが多くて混乱を招くことが多い。
かといってある程度固まった仕様の中からカスタマイズのみで対応するものだと
特殊な要件を実現できなくなり場合によっては競争力を欠いてしまうこともありえる。
したがって今後重要視されるべきなのは、完全に分離できる部分の確立、
要するに確実に再利用できる部分の確立だ。
こんなの車のパーツにでも例えれば一発でわかることだと思うんだが、
高い技術力を持っていながら提案できる立場にもいる人間が思ったより少ないせいで、
プロジェクトメンバー総火の玉で突っ込んでグダグダで終わらせて
あとは何も考えず満足ってケースが思ったより多い。
実際は上手くプロダクト指向を確立できるとしてもなかなか気付かない。
力技でゴリ押しして、中国インドでも済むような仕事をしてるところは
そのうち痛い目見るだろうね。
871 ：仕様書無しさん：04/11/07 05:17:08
>>プロジェクトメンバー総火の玉で突っ込んでグダグダで終わらせて
>>あとは何も考えず満足ってケースが思ったより多い。
こないだまでやってたプロジェクトがまんまそれだった
しかも糞システム納品しておいて当人達は満足顔なのがとこが・・・
>>あとは何も考えず満足ってケースが思ったより多い。
こないだまでやってたプロジェクトがまんまそれだった
しかも糞システム納品しておいて当人達は満足顔なのがとこが・・・
872 ：仕様書無しさん：04/11/07 06:52:05
ＮＴＴデータ系はオブジェクト指向をまったく無視している。
自前のへなちょこフレームワーク作ってさ。
ＭＶＣモデルにさえなってない。
クラス設計は不要という。
まぁ、どうでもいいけどさ。
自前のへなちょこフレームワーク作ってさ。
ＭＶＣモデルにさえなってない。
クラス設計は不要という。
まぁ、どうでもいいけどさ。
MVCモデルは選択肢の一つでしかない罠。
オブジェクト指向にこだわって予算と納期が見えない技術者は馬鹿。
オブジェクト指向にこだわって予算と納期が見えない技術者は馬鹿。
業務アプリにオブジェクト指向を取り込もうとする奴は馬鹿
おまいらの言ってる業務アプリってどんなのよ？
＞873
目先の納期にこだわって同じものを垂れ流す結果になるPMも馬鹿だと思うぞ。
＞873
目先の納期にこだわって同じものを垂れ流す結果になるPMも馬鹿だと思うぞ。
おまいら再利用可能な部品を集めた社内ライブラリとかありまつか？
うちにはまったくないが。
うちにはまったくないが。
>>876
うちの部門で共通ライブラリ構築をしようとしたけど
運用ルール作りやツール・言語の進化に合わせた
メンテナンス、下手すりゃバグ管理までしなきゃならんでしょ。
誰がするんだ、ということになり、暗礁に乗り上げた。
人員削減でメンテ部隊を持つ余裕がない。
うちの部門で共通ライブラリ構築をしようとしたけど
運用ルール作りやツール・言語の進化に合わせた
メンテナンス、下手すりゃバグ管理までしなきゃならんでしょ。
誰がするんだ、ということになり、暗礁に乗り上げた。
人員削減でメンテ部隊を持つ余裕がない。
＞878
何ツーか･･･作ってもつまらなそうな門ばっかりだな･･･
何ツーか･･･作ってもつまらなそうな門ばっかりだな･･･
DQNなとこだと、既にライブラリ化されているものさえ自作ライブラリで置き換えようと張り切る馬鹿が
出てきて、収集がつかなくなるからやめとけ。
出てきて、収集がつかなくなるからやめとけ。
業務系でOOごっこなんかやる意味ないって。
業務系の大半はDBのデータを操作するのがメインなわけだから、テーブル設計さえきちんとしてればいい。
ゲームや通信制御・マルチメディア等のアプリケーションのように「様々な種類の複数のオブジェクトがメモリ上に
あって、それらが連携しながら処理を進めていく」という状況自体が余りない。
そんなアプリに無理にオブジェクト指向を当てはめる必要はない。
業務アプリの場合「入出力とビジネスロジックとデータ（DB)の層をきちんとわける」という鉄則さえ守れば十分。
業務系の大半はDBのデータを操作するのがメインなわけだから、テーブル設計さえきちんとしてればいい。
ゲームや通信制御・マルチメディア等のアプリケーションのように「様々な種類の複数のオブジェクトがメモリ上に
あって、それらが連携しながら処理を進めていく」という状況自体が余りない。
そんなアプリに無理にオブジェクト指向を当てはめる必要はない。
業務アプリの場合「入出力とビジネスロジックとデータ（DB)の層をきちんとわける」という鉄則さえ守れば十分。
ｹﾞﾗｹﾞﾗ
>885
DBのデータをオブジェクトとして捕らえれば、それらが相互作用して処理を進めていくという考えもできるが。
けど、やっぱり君の言うとおり業務系OOは意味はないな。
DBと画面がメインだから、そこさえしっかり出来てれば後は人月で終了。
こんな土方作業にOOなんて持ち込んだら混乱して作業が進まなくなるだけ。
DBのデータをオブジェクトとして捕らえれば、それらが相互作用して処理を進めていくという考えもできるが。
けど、やっぱり君の言うとおり業務系OOは意味はないな。
DBと画面がメインだから、そこさえしっかり出来てれば後は人月で終了。
こんな土方作業にOOなんて持ち込んだら混乱して作業が進まなくなるだけ。
＞885
著しくつまらないプログラムだなそれ。
ネット証券のシステムを作ったときは萎えた。
著しくつまらないプログラムだなそれ。
ネット証券のシステムを作ったときは萎えた。
オブジェクト指向の生まれた背景の一つは「独立性の高い部品の相互作用によって、
複雑な処理を簡潔に記述できるようにすること」。
業務アプリは、（面倒な処理はあっても）複雑な処理自体がほとんどないんだから（ｒｙ
複雑な処理を簡潔に記述できるようにすること」。
業務アプリは、（面倒な処理はあっても）複雑な処理自体がほとんどないんだから（ｒｙ
部品の形が決まってるなら部品の組み合わせだけで出来ないの？
>>890
できるよ。
ただし、出来たら出来たで、もっと便利にならないかもっと高度なことができないかと
いう欲求が生まれる。
しかもソフトウェアの場合、それを試すのが簡単なので、また新しい部品作りが始まる。
ゆえに他の工業分野のように規格化された部品が末永く再利用されることは少なくなりがち。
できるよ。
ただし、出来たら出来たで、もっと便利にならないかもっと高度なことができないかと
いう欲求が生まれる。
しかもソフトウェアの場合、それを試すのが簡単なので、また新しい部品作りが始まる。
ゆえに他の工業分野のように規格化された部品が末永く再利用されることは少なくなりがち。
＞891
でもそういうんでは今でもいろいろな部品があるといえばあるだろうし、工業分野のようにすることも可能なんだろうね。
でも実際はまだまったく成熟していない。
基盤となるOSや言語がころころと変わり開発手法といったものも変遷してる。
流通市場といったものも成熟してないからまだまだこれから炉もいえますね。
でもそういうんでは今でもいろいろな部品があるといえばあるだろうし、工業分野のようにすることも可能なんだろうね。
でも実際はまだまったく成熟していない。
基盤となるOSや言語がころころと変わり開発手法といったものも変遷してる。
流通市場といったものも成熟してないからまだまだこれから炉もいえますね。
業務系だからアプリケーション自体の設計に本格的な
OOを導入しないって発想も一理あるが、そういうのを
勘違いしてるのが多いんだよ、ほんと。
業務系とかなんとかいう以前に常識はずれがあまりに
多くて、そのくせ仕様変更が多いから修正に無駄な時間が
かかって本当に困る。
仕様が複雑になったからってリファクタリングするなんて発想を
みんなが持ってると思ったら大間違い。
OOを導入しないって発想も一理あるが、そういうのを
勘違いしてるのが多いんだよ、ほんと。
業務系とかなんとかいう以前に常識はずれがあまりに
多くて、そのくせ仕様変更が多いから修正に無駄な時間が
かかって本当に困る。
仕様が複雑になったからってリファクタリングするなんて発想を
みんなが持ってると思ったら大間違い。
895 ：仕様書無しさん：04/11/08 00:10:56
>>869
当たり前のことをはっきり書くのがマイ・ブーム。
嘘や誇大表現、自明でない省略はオレが思ってたよりも遙かに高い割合で誤解を招くという
事実に２年前に気づいた。読み飛ばして頂いても腰を抜かして頂いても、誤解なければ結構。
>>870
そうだね、非機能的な単位でのソースのコピペまで再利用と呼ぶのはおかしい。
少なくともその各単位で個別のテストが不要な単位であるべきだね。
>>873-874 等
オレは >>865 でプログラマのレベルの低さについて書いたんだけどさ、
今、そのレベルの低さの一因はコミュニケーション能力の低さだと解ったよ。
これもよく言われている当たり前の話なんだろうけど。
「○○は馬鹿」ってのは、「○○するべきではない」って事なんだろうけどさ、
皆が課題に集中して解を探して協調してる雰囲気で、こういう表現はやっぱり適切でないと
オレは思う訳よ。それは技術的に十分な根拠を伴うものでないという意味でもそうだし、
人間の精神面にも良い影響がある。最近、攻殻GIG2見てて考えたんだけど、
そう言うのって、改善や改良を仕事とする技術者っていう職種が求める人格の要素だと思うんよ。
ところでブレーンストーミングって知ってる？
当たり前のことをはっきり書くのがマイ・ブーム。
嘘や誇大表現、自明でない省略はオレが思ってたよりも遙かに高い割合で誤解を招くという
事実に２年前に気づいた。読み飛ばして頂いても腰を抜かして頂いても、誤解なければ結構。
>>870
そうだね、非機能的な単位でのソースのコピペまで再利用と呼ぶのはおかしい。
少なくともその各単位で個別のテストが不要な単位であるべきだね。
>>873-874 等
オレは >>865 でプログラマのレベルの低さについて書いたんだけどさ、
今、そのレベルの低さの一因はコミュニケーション能力の低さだと解ったよ。
これもよく言われている当たり前の話なんだろうけど。
「○○は馬鹿」ってのは、「○○するべきではない」って事なんだろうけどさ、
皆が課題に集中して解を探して協調してる雰囲気で、こういう表現はやっぱり適切でないと
オレは思う訳よ。それは技術的に十分な根拠を伴うものでないという意味でもそうだし、
人間の精神面にも良い影響がある。最近、攻殻GIG2見てて考えたんだけど、
そう言うのって、改善や改良を仕事とする技術者っていう職種が求める人格の要素だと思うんよ。
ところでブレーンストーミングって知ってる？
896 ：仕様書無しさん：04/11/08 00:13:13
修正
誤：人間の精神面にも良い影響がある
↓
正：人間の精神面にも良い影響があるとは思えない。
誤：人間の精神面にも良い影響がある
↓
正：人間の精神面にも良い影響があるとは思えない。
897 ：仕様書無しさん：04/11/08 00:14:21
修正２
誤：改善や改良
↓
正：創造や改良
誤：改善や改良
↓
正：創造や改良
業務アプリなんてOOの必要まったくないと思うね。
顧客に対して、業者はなるべく高くて、継続して稼げそうな
ものを売りつけようとするだろ？
クライアントをブラウザにしてバカみたいに無理やりLINUX＋JAVAで組んだりね。
それがOOがここまで流行った理由の一つだと思うよ。
損をしたのは、実は顧客だけっていうのが本当のとこじゃないかな？
顧客に対して、業者はなるべく高くて、継続して稼げそうな
ものを売りつけようとするだろ？
クライアントをブラウザにしてバカみたいに無理やりLINUX＋JAVAで組んだりね。
それがOOがここまで流行った理由の一つだと思うよ。
損をしたのは、実は顧客だけっていうのが本当のとこじゃないかな？
業務系でOOの設計を使えないって？
思考停止しているとしか思えない。
動的な検索条件(具体的にはSQLのWHILE部)を構築するのにどう設計するか。
検索条件のモデルは？
検索条件をSQLにどう翻訳する？
こんなトピック一つだけでも、
すべてif文と文字列の連結で済ます奴から
Criteriaクラスを構築する奴まで様々だ。
で、作り方によってSQL Injection への対応難度も変わる。
仕様変更への対応難度も変わる。
人間様の都合で無駄に思えるほど複雑化された仕様を、
すぐれた設計手法で局所化できたりするのは面白い。
思考停止しているとしか思えない。
動的な検索条件(具体的にはSQLのWHILE部)を構築するのにどう設計するか。
検索条件のモデルは？
検索条件をSQLにどう翻訳する？
こんなトピック一つだけでも、
すべてif文と文字列の連結で済ます奴から
Criteriaクラスを構築する奴まで様々だ。
で、作り方によってSQL Injection への対応難度も変わる。
仕様変更への対応難度も変わる。
人間様の都合で無駄に思えるほど複雑化された仕様を、
すぐれた設計手法で局所化できたりするのは面白い。
>>894
まともな技術者なら別にOOなんて意識しなくともまともなプログラムを書くさ。
優れた技術者ならCOBOLを使ってさえも優れた設計をするんだろう。
劣悪な技術者にまともなプログラムを書かせるためには一定の方法論を
強制するしかないわけだが、その方法論にも当然、優劣がある。
で、近頃ではOOという方法論が優れているって評判なわけだ。
え? うちのプログラマは劣悪な上にOOを学ぶことすら嫌がる??
そんなの捨てちゃえば良いんでない?
どうせ、どこかの三重派遣屋から別なのを買ってこれるんでしょ?
まともな技術者なら別にOOなんて意識しなくともまともなプログラムを書くさ。
優れた技術者ならCOBOLを使ってさえも優れた設計をするんだろう。
劣悪な技術者にまともなプログラムを書かせるためには一定の方法論を
強制するしかないわけだが、その方法論にも当然、優劣がある。
で、近頃ではOOという方法論が優れているって評判なわけだ。
え? うちのプログラマは劣悪な上にOOを学ぶことすら嫌がる??
そんなの捨てちゃえば良いんでない?
どうせ、どこかの三重派遣屋から別なのを買ってこれるんでしょ?
>>892
ＯＳや基盤技術は変わるけど、（開発手法∋）設計手法の、構造化解析、ＤＯＡという流れで
ＯＯは当然だったようにオレには思えるけどな。
ただ、
ソフトウェアライフサイクルプロセス（ＳＬＣＰ）って、契約社会の米国文化にピッタリ
くっついてるプロセスに思える。 結局、客が納得するかどうかの問題なわけで、例えばウォーターフォール
なんて方法でやっても、日本だったらモノを見せた後、絶対修正入る。
もうこれは、日本人ってそういう連中の集団でしょうとしか言いようがない。
そこで、そういう無茶な理想プロセスを、ちょっとずつ日本の実態に合わせていってる。まるで
白馬の王子様からイケメン高学歴、定職に就いてるリーマンへと女の男を見る目が適応するように、
顧客の持つ理想にあわせて、今はプロセス妥協し変化していってる段階なんだと思うよ。
顧客には、費用に応じた現実を見せておく必要がある。
>>885-891
業務システムの実態っていうのがシャドーされてて、かゆいところに手が届かない感じですね。
適当に業務システムの要件を定義して、みんなでＯＯなモデリングをして互いにつつき合うと
心地よくなれるかも。
ＯＳや基盤技術は変わるけど、（開発手法∋）設計手法の、構造化解析、ＤＯＡという流れで
ＯＯは当然だったようにオレには思えるけどな。
ただ、
ソフトウェアライフサイクルプロセス（ＳＬＣＰ）って、契約社会の米国文化にピッタリ
くっついてるプロセスに思える。 結局、客が納得するかどうかの問題なわけで、例えばウォーターフォール
なんて方法でやっても、日本だったらモノを見せた後、絶対修正入る。
もうこれは、日本人ってそういう連中の集団でしょうとしか言いようがない。
そこで、そういう無茶な理想プロセスを、ちょっとずつ日本の実態に合わせていってる。まるで
白馬の王子様からイケメン高学歴、定職に就いてるリーマンへと女の男を見る目が適応するように、
顧客の持つ理想にあわせて、今はプロセス妥協し変化していってる段階なんだと思うよ。
顧客には、費用に応じた現実を見せておく必要がある。
>>885-891
業務システムの実態っていうのがシャドーされてて、かゆいところに手が届かない感じですね。
適当に業務システムの要件を定義して、みんなでＯＯなモデリングをして互いにつつき合うと
心地よくなれるかも。
>>898
ＯＯに直接関係ないから、突っ込むのは勘弁してほしんだけど…
＞クライアントをブラウザにしてバカみたいに無理やりLINUX＋JAVAで組んだりね。
＞損をしたのは、実は顧客だけ（以下略）
これは、保守契約のコストの関係なんかがあるようです。
クリーンインストールした状態以上のものは、リスクを避けるため保守契約を結ぶことが
多く、ブラウザとＶＭだけでＯＫ（今はＭＳのＶＭ外されちゃいましたけど）ならこれを削れると。
聞いた話。ｳｿかもしれん。
ＯＯに直接関係ないから、突っ込むのは勘弁してほしんだけど…
＞クライアントをブラウザにしてバカみたいに無理やりLINUX＋JAVAで組んだりね。
＞損をしたのは、実は顧客だけ（以下略）
これは、保守契約のコストの関係なんかがあるようです。
クリーンインストールした状態以上のものは、リスクを避けるため保守契約を結ぶことが
多く、ブラウザとＶＭだけでＯＫ（今はＭＳのＶＭ外されちゃいましたけど）ならこれを削れると。
聞いた話。ｳｿかもしれん。
＞901
後半部分についてだけど。
それってアナリシスパターンがやってることそのままでない？
後半部分についてだけど。
それってアナリシスパターンがやってることそのままでない？
>>899
Criteriaクラスってどんなクラス？
Criteriaクラスってどんなクラス？
検索条件（WHERE句の中身）を生成するクラスを
独立させるって話だと思います。
独立させるって話だと思います。
where句の生成をクラス化して誰が喜ぶんだ？
んなもんselect句と密接にかかわってるから
ORマッピングとして１個のクラスにしとけば良いんだよ。
SQL文は１個のクラスで凝集させとけっての。
んなもんselect句と密接にかかわってるから
ORマッピングとして１個のクラスにしとけば良いんだよ。
SQL文は１個のクラスで凝集させとけっての。
OOわかったつもり君が、無理やり見当違いなところにOOを無理やりはめ込んで
回りに迷惑掛ける典型例だな。
業務アプリ程度じゃOOを取り込むメリットよりデメリットのほうがはるかに大きいんだから
禁止しとけって。
回りに迷惑掛ける典型例だな。
業務アプリ程度じゃOOを取り込むメリットよりデメリットのほうがはるかに大きいんだから
禁止しとけって。
検索するカラムをユーザが選択できる形式で、
ＧＵＩや検索式などの複数の検索用ヒューマンインタフェースを有していて、
しかも、検索条件のパラメタ値をチェックして、変換したり、入力規制を調べたり、
その結果、文法エラーを表示させたりする場合は、クラス化する価値があるんじゃないでしょうか。
文法解析メソッドと、ＧＵＩから条件を取り込むメソッドを個別に作成して、switch文をぐるぐる回す？
これだと、カラム判別の機能と、各カラムに対応する検索条件のチェック機能の纏まりが悪いよね。
クラス化しておけば、生成したＳＱＬをチェックして投げるクラスは汎用部品にできるし。
まぁ、規模の問題だろうけどね。 小さければ直接ＳＱＬ文を合成してもいいかも。
システムの要件をまとめて、みんなでモデリングは面白そう。
情報処理の過去問を改変してお題につかえるかも。
それとも、マクドや吉野家の店舗をモデル化してもいいかも。
ＵＭＬでユースケース図にまずまとめてさ。
ＧＵＩや検索式などの複数の検索用ヒューマンインタフェースを有していて、
しかも、検索条件のパラメタ値をチェックして、変換したり、入力規制を調べたり、
その結果、文法エラーを表示させたりする場合は、クラス化する価値があるんじゃないでしょうか。
文法解析メソッドと、ＧＵＩから条件を取り込むメソッドを個別に作成して、switch文をぐるぐる回す？
これだと、カラム判別の機能と、各カラムに対応する検索条件のチェック機能の纏まりが悪いよね。
クラス化しておけば、生成したＳＱＬをチェックして投げるクラスは汎用部品にできるし。
まぁ、規模の問題だろうけどね。 小さければ直接ＳＱＬ文を合成してもいいかも。
システムの要件をまとめて、みんなでモデリングは面白そう。
情報処理の過去問を改変してお題につかえるかも。
それとも、マクドや吉野家の店舗をモデル化してもいいかも。
ＵＭＬでユースケース図にまずまとめてさ。
自分自身の内容を書き出すＳＱＬ文字列を作成する処理を、
クラスの中に実装したらダメなのか？
クラスの中に実装したらダメなのか？
>>906-907
人によってというよりも、システムによって違うから一概には言えない問題なんだが。
で、「このシステムの場合はどうするのがいいか?」って考えるのが設計なんだが
考えようとせずに
＞SQL文は１個のクラスで凝集させとけっての。
って初っ端っから決めてかかると、糞システムが出来上がる。
人によってというよりも、システムによって違うから一概には言えない問題なんだが。
で、「このシステムの場合はどうするのがいいか?」って考えるのが設計なんだが
考えようとせずに
＞SQL文は１個のクラスで凝集させとけっての。
って初っ端っから決めてかかると、糞システムが出来上がる。
簡単な業務アプリにOOを持ち込もうとするのは、鉛筆削るのに日本刀を持ち出すようなもの。
日本刀のほうがよりシャープに削れるという達人もいるだろうが、大抵の場合危険で無意味なだけ。
業務アプリの中にも複雑な連携処理を必要とする部分があることもあるが、そういう場合は
その部分だけをライブラリ化してOO設計すればいいだけのこと。
紙と鉛筆と電話でやっていた業務を効率化のため電子化しただけの業務アプリではOOなんて必要なし。
日本刀のほうがよりシャープに削れるという達人もいるだろうが、大抵の場合危険で無意味なだけ。
業務アプリの中にも複雑な連携処理を必要とする部分があることもあるが、そういう場合は
その部分だけをライブラリ化してOO設計すればいいだけのこと。
紙と鉛筆と電話でやっていた業務を効率化のため電子化しただけの業務アプリではOOなんて必要なし。
>>912
ユーザーとDBをつなぐだけのそこらへんに
転がってる業務システムでEAだのなんだの騒ぐなって話
↓
tp://nekop.programmers.jp/diary/?date=20041024
ファウラーとかが説いてる世界とお前らは違うんだ、と。
身の程を知れ、と、そこまで言ってないか、でも
そんなん言われた感じですねー。
まあ真実なんでしょうねー。あーつまんねーオチだ。
ユーザーとDBをつなぐだけのそこらへんに
転がってる業務システムでEAだのなんだの騒ぐなって話
↓
tp://nekop.programmers.jp/diary/?date=20041024
ファウラーとかが説いてる世界とお前らは違うんだ、と。
身の程を知れ、と、そこまで言ってないか、でも
そんなん言われた感じですねー。
まあ真実なんでしょうねー。あーつまんねーオチだ。
日本の場合、「プログラマ」と言っても大部分は「業務アプリのコーダ」なわけだ。
理学工学の専門教育を受けるどころか、高校レベルの数学もろくにわからないようなレベルの
人間が技術者気取りでいる。
で、日本でソフト関連の書籍を出すとなると、そういう層をターゲットにした陳腐な内容のほうが
売上は上がる。
そうしてますます、いらんことして回りを混乱させる「なんちゃってエンジニア」が増えていくと。
ま、せいぜいがんばってや。
理学工学の専門教育を受けるどころか、高校レベルの数学もろくにわからないようなレベルの
人間が技術者気取りでいる。
で、日本でソフト関連の書籍を出すとなると、そういう層をターゲットにした陳腐な内容のほうが
売上は上がる。
そうしてますます、いらんことして回りを混乱させる「なんちゃってエンジニア」が増えていくと。
ま、せいぜいがんばってや。
全ての工業製品が、ネジの一本までカスタムメイドである必要はないのと
同じで、ソフトウェアも、既存のソフトウェア部品を組み合わせて目的の機能
を実現させる事に罪悪感を感じる必要は、全くない。
同じで、ソフトウェアも、既存のソフトウェア部品を組み合わせて目的の機能
を実現させる事に罪悪感を感じる必要は、全くない。
そんなわかりきったことを なぜわざわざ？
なんちゃって技術者とやらを槍玉に挙げる人は、そうは思ってなさそうだから。
理学工学の専門教育を受けたプログラマさんが
借方貸方とか有効在庫・実在庫のうまい
モデリングとか、ちゃんと勉強してもらえれば
俺のようななんちゃってエンジニアの出番は無くなるんだが。
業務知らない技術バカに何度泣かされた事か
>914に期待する、頼むぜ。
借方貸方とか有効在庫・実在庫のうまい
モデリングとか、ちゃんと勉強してもらえれば
俺のようななんちゃってエンジニアの出番は無くなるんだが。
業務知らない技術バカに何度泣かされた事か
>914に期待する、頼むぜ。
悲しいかな理学工学の専門教育を受けた人は、
借方方貸とか有効在庫・実在庫とかいう世界には
興味を持たない。
悲しいかな文系の優秀な人材はプログラミングには
興味を持たない。
結果的に「技術もダメ、業務もダメ、コミュニケーションもダメ」
という人たちが業務アプリに逃げ込んでくる。
借方方貸とか有効在庫・実在庫とかいう世界には
興味を持たない。
悲しいかな文系の優秀な人材はプログラミングには
興味を持たない。
結果的に「技術もダメ、業務もダメ、コミュニケーションもダメ」
という人たちが業務アプリに逃げ込んでくる。
おまいらそんなに自分を卑下すんな
せつねーよ
せつねーよ
いっそ業務系にはOOは有害ってキャンペーンでも日経辺りでやってくれよ(w
アホ上司も騙されずに(いや騙されるのか)すむし。
こっちも914の言う低レベルな作業に邁進すれば良いしな。
アホ上司も騙されずに(いや騙されるのか)すむし。
こっちも914の言う低レベルな作業に邁進すれば良いしな。
低レベルって言葉も、日本語だと誤解を生むよなあ。
おれはなんちゃって技術者だけど、
「低レベル」な所をやってる人には何時も
感謝していますよ。
愚痴レスはそれくらいにして話題をOOに戻そうぜ。
おれはなんちゃって技術者だけど、
「低レベル」な所をやってる人には何時も
感謝していますよ。
愚痴レスはそれくらいにして話題をOOに戻そうぜ。
つーか業務アプリのOO浸透度はどれくらいよ？
ゲーム開発とかで「OOなんて必要ない」とか言う奴はまずいないだろうし、ゲーム開発に関わってなくても
OOをある程度わかっているやつらは「ゲームとかならかなり有効だろうな」と感じていると思う。
でも業務アプリとなると不要論を唱えてる奴の意見も一理あるし、ほんとうに有効なのかどうかは半信半疑
なんじゃないの？
実際そういう現場にいる奴はどう思ってるわけ？
・お前らの現場じゃOOは浸透してる？
・OOは実際効果を発揮してる？
ゲーム開発とかで「OOなんて必要ない」とか言う奴はまずいないだろうし、ゲーム開発に関わってなくても
OOをある程度わかっているやつらは「ゲームとかならかなり有効だろうな」と感じていると思う。
でも業務アプリとなると不要論を唱えてる奴の意見も一理あるし、ほんとうに有効なのかどうかは半信半疑
なんじゃないの？
実際そういう現場にいる奴はどう思ってるわけ？
・お前らの現場じゃOOは浸透してる？
・OOは実際効果を発揮してる？
うちはC/S中心だから浸透してないねぇ。
C/S中心だからって理由にはならんと思うけど
まあ惰性というかなんというか。
画面のイベントにゴリゴリ業務ロジック書く
VBの流れでしたね。Delphiだったけど、まあ同じだ。
俺は一人で会計部分をやったんだけど、
そこは好きにやらせて貰って、OOで設計しました。
かなりコーディング量は減りましたね。
例えば支払管理機能だと、普通に仕入に対する支払から
手形の返却、売掛金返却まで、最小限の変更で対応出来たし、
支払明細の持ち方で仕様変更あった時も対応が楽だった。
VBみたくやってたら死ぬ所でした。
C/S中心だからって理由にはならんと思うけど
まあ惰性というかなんというか。
画面のイベントにゴリゴリ業務ロジック書く
VBの流れでしたね。Delphiだったけど、まあ同じだ。
俺は一人で会計部分をやったんだけど、
そこは好きにやらせて貰って、OOで設計しました。
かなりコーディング量は減りましたね。
例えば支払管理機能だと、普通に仕入に対する支払から
手形の返却、売掛金返却まで、最小限の変更で対応出来たし、
支払明細の持ち方で仕様変更あった時も対応が楽だった。
VBみたくやってたら死ぬ所でした。
ああでもOOとか言っても、
ファウラーとか好きな人からすりゃ
ただの差分プログラムじゃねぇかとか怒られそうな
レベルかも知れないです。
エンティティクラスにSQL書いてDBとつなげてるし。
流石にDAOだのなんだの考える余裕は無かったです。
ただ普通に共通関数で外出しにして
どういう支払かを区分で引数で送って
条件分岐であーだこーだやるよりは、
すっきりしたと思います。
プロジェクト全体の標準から外れたんで
問題ないこともないと思いますが
どうせ会計とか仕訳とか判るの俺だけだし
後からいじるの俺だけなの確実だったから
えいやってやっちゃいました。
ファウラーとか好きな人からすりゃ
ただの差分プログラムじゃねぇかとか怒られそうな
レベルかも知れないです。
エンティティクラスにSQL書いてDBとつなげてるし。
流石にDAOだのなんだの考える余裕は無かったです。
ただ普通に共通関数で外出しにして
どういう支払かを区分で引数で送って
条件分岐であーだこーだやるよりは、
すっきりしたと思います。
プロジェクト全体の標準から外れたんで
問題ないこともないと思いますが
どうせ会計とか仕訳とか判るの俺だけだし
後からいじるの俺だけなの確実だったから
えいやってやっちゃいました。
ゲームとか組み込みとか、リソースに関して
制約が大きそうだもんね。
ゲームや組み込みならOOが有効ってのは、
業務系でOOが使いにくい
↓
他の分野なら使いやすいはず
って所から来た願望混じりの神話なのかなあ。
業務系もそれ以外もみんな事情は一緒か・・・。
制約が大きそうだもんね。
ゲームや組み込みならOOが有効ってのは、
業務系でOOが使いにくい
↓
他の分野なら使いやすいはず
って所から来た願望混じりの神話なのかなあ。
業務系もそれ以外もみんな事情は一緒か・・・。
>>895
>当たり前のことをはっきり書くのがマイ・ブーム。
・・・
>ところでブレーンストーミングって知ってる？
どうやら >>895 のマイ・ブームは
たった１４行で過ぎ去ってしまったらしい・・・
>当たり前のことをはっきり書くのがマイ・ブーム。
・・・
>ところでブレーンストーミングって知ってる？
どうやら >>895 のマイ・ブームは
たった１４行で過ぎ去ってしまったらしい・・・
>>926
それは設計が悪いと言える･･･。と、指摘しておく。
リソースやパフォーマンスとOOはほとんど関係しない。そこはGems辺りでも参考にして下さい。
むしろ同じ機能で、管理が楽になるだろ･･･。
業務系は、インフラだけバチッとOO設計して、後は突貫工事みたいな事やっている。
そのうちMDA駆動になるのかな･･･とか思うけど、少なくとも数年はこのままだろうね。
それは設計が悪いと言える･･･。と、指摘しておく。
リソースやパフォーマンスとOOはほとんど関係しない。そこはGems辺りでも参考にして下さい。
むしろ同じ機能で、管理が楽になるだろ･･･。
業務系は、インフラだけバチッとOO設計して、後は突貫工事みたいな事やっている。
そのうちMDA駆動になるのかな･･･とか思うけど、少なくとも数年はこのままだろうね。
>>911
話逸れるけどさ、
結局、ソフトウェアの技術が体系的に教えられてないから現場が混乱してるんだろうな。
他の分野なら、そういう技術体系を学習する段階で、個別具体的な知識の他に、
「技術」に共通の緻密なコミュニケーション方法や、考え方なんかを学習していくわけだけど、
プログラマの場合は、そういうのないでしょ。たいてい独学で、無知な人間ほど井の中の蛙に
なってる、もちろん本人は気づいてない。
そこでさ、全員で謙虚にいこうよ。 夏休みの自由研究みたいにさ、みんなに解るように。
主張や批判をやるなら、相応の根拠を書くべきだと思う。でないといつまでも現状が変わらない
ような気がする。
話逸れるけどさ、
結局、ソフトウェアの技術が体系的に教えられてないから現場が混乱してるんだろうな。
他の分野なら、そういう技術体系を学習する段階で、個別具体的な知識の他に、
「技術」に共通の緻密なコミュニケーション方法や、考え方なんかを学習していくわけだけど、
プログラマの場合は、そういうのないでしょ。たいてい独学で、無知な人間ほど井の中の蛙に
なってる、もちろん本人は気づいてない。
そこでさ、全員で謙虚にいこうよ。 夏休みの自由研究みたいにさ、みんなに解るように。
主張や批判をやるなら、相応の根拠を書くべきだと思う。でないといつまでも現状が変わらない
ような気がする。
932 ：仕様書無しさん：04/11/08 20:33:10
>>929
＞業務系は、インフラだけバチッとOO設計して、後は突貫工事みたいな事やっている。
これが現実的な理想だろうな（ｗ
業務アプリへのＯＯ適用反対派も、結局これがやりたいんじゃないのか？
ホントに根っからいやなら、こんなスレ来ないだろうし、古いコボルでも使ってるよな。
でも、インフラの範囲の解釈でいろんな考え方がありそう。
最小で解釈すると、ＯＯ言語のクラスライブラリをつかえば、ＧＵＩ部品やＤＢへのアクセス
なんかがＯＯとして既に提供されてるわけで、もうちょっと広く解釈すると、
こういったクラスを特化したクラスを作れば専用のインフラになるし。
＞業務系は、インフラだけバチッとOO設計して、後は突貫工事みたいな事やっている。
これが現実的な理想だろうな（ｗ
業務アプリへのＯＯ適用反対派も、結局これがやりたいんじゃないのか？
ホントに根っからいやなら、こんなスレ来ないだろうし、古いコボルでも使ってるよな。
でも、インフラの範囲の解釈でいろんな考え方がありそう。
最小で解釈すると、ＯＯ言語のクラスライブラリをつかえば、ＧＵＩ部品やＤＢへのアクセス
なんかがＯＯとして既に提供されてるわけで、もうちょっと広く解釈すると、
こういったクラスを特化したクラスを作れば専用のインフラになるし。
933 ：仕様書無しさん：04/11/08 20:38:32
てすと
そしてぬるぽ
そしてぬるぽ
>>929
メモリは結構ギリギリまで使うし、パフォーマンスもシビアだと
ガーベージコレクション搭載のメモリマネージャーの導入って厳しくない？
あとは仕様の変更が多すぎて・・・ある程度は頑張って対応するけどね。
メモリは結構ギリギリまで使うし、パフォーマンスもシビアだと
ガーベージコレクション搭載のメモリマネージャーの導入って厳しくない？
あとは仕様の変更が多すぎて・・・ある程度は頑張って対応するけどね。
>>934
別にJavaとかじゃなくてもC++使えば良いじゃん。
ガーベージコレクションはLispにあることからも分かるように、
OOとは独立の要素だよ。
＞あとは仕様の変更が多すぎて
まさにこれに対応するためにOOを導入するんじゃないか。
別にJavaとかじゃなくてもC++使えば良いじゃん。
ガーベージコレクションはLispにあることからも分かるように、
OOとは独立の要素だよ。
＞あとは仕様の変更が多すぎて
まさにこれに対応するためにOOを導入するんじゃないか。
ん、論理的にちとおかしかったな。
Lispにあることから分かるのは、OOに特有の要素でないって事だった。
一方で、C++にないことからOOに必須の要素でもないことも分かる。
Lispにあることから分かるのは、OOに特有の要素でないって事だった。
一方で、C++にないことからOOに必須の要素でもないことも分かる。
業務系ではOOは全く無用だし、普及もしてない
とまでは言わないが、せいぜいプチOOレベルじゃないの？
クラスを抽出して属性洗い出して、カプセル化して操作メソッドを作ってというレベル。
ただし、DB主体でトランザクションごとに処理が完結するような仕様だと、クラスすら作る意味が
あまりなくなってくる。
抽象化・多態になると有効な状況はもう極端に限られるのではないか。
「せっかく覚えたんだから使いたい」みたいな厨がいると悲惨である。
とまでは言わないが、せいぜいプチOOレベルじゃないの？
クラスを抽出して属性洗い出して、カプセル化して操作メソッドを作ってというレベル。
ただし、DB主体でトランザクションごとに処理が完結するような仕様だと、クラスすら作る意味が
あまりなくなってくる。
抽象化・多態になると有効な状況はもう極端に限られるのではないか。
「せっかく覚えたんだから使いたい」みたいな厨がいると悲惨である。
非同期ガベコレは、メモリ管理技法の中では最も効率がわるい部類の技術だよ。
もっと工夫したメモリ管理クラスを作るべきじゃない？
>929
ゲームや組み込みは、やることいっぱいあるけど、
業務系のＯＯっていうと、結局ＤＯＡになるんじゃないですかね。
データの加工が全てでしょ？複雑なトランザクション除くと。
だから、これだけORマッピングなんかも問題になってきてるわけだし。
業務系ＯＯの極意はDOAにあり！ じゃないでしょうか。
もっと工夫したメモリ管理クラスを作るべきじゃない？
>929
ゲームや組み込みは、やることいっぱいあるけど、
業務系のＯＯっていうと、結局ＤＯＡになるんじゃないですかね。
データの加工が全てでしょ？複雑なトランザクション除くと。
だから、これだけORマッピングなんかも問題になってきてるわけだし。
業務系ＯＯの極意はDOAにあり！ じゃないでしょうか。
940 ：仕様書無しさん：04/11/08 21:11:01
>>935
いや、C++使ってましたよ。
ガーベージコレクションないと、好きなときにオブジェクトをnew、deleteができない。
でもメモリ上限ギリギリまで使ってると虫食いが起きるようなメモリ管理は命取り。
巨大なグラフィックデータがコレクションでmemmoveしたりすると処理落ちする。
あとソースが１０００以上もあって複数で開発してる状態で、
とっぴょうしもない仕様の変更にも対応するのってやっぱ厳しいよ。
それで柔軟に対応できる設計ができたらそれこそ神だと思う。
いや、C++使ってましたよ。
ガーベージコレクションないと、好きなときにオブジェクトをnew、deleteができない。
でもメモリ上限ギリギリまで使ってると虫食いが起きるようなメモリ管理は命取り。
巨大なグラフィックデータがコレクションでmemmoveしたりすると処理落ちする。
あとソースが１０００以上もあって複数で開発してる状態で、
とっぴょうしもない仕様の変更にも対応するのってやっぱ厳しいよ。
それで柔軟に対応できる設計ができたらそれこそ神だと思う。
>>937
この手のOO不要論レスにずっと違和感を抱いていたんだが、
その正体がようやく分かった。
アンチOOの人達って、オブジェクト指向を
抽象化 + 多態 + foo + bar + …
という、個別のテクニックの集合としか認識していないんだな。
業務アプリをオブジェクト指向という「指向」で分析・設計した結果として
多態というテクニックは必要ないと言うのであれば、それは別にOO的にも
全く問題ないんだが。
この手のOO不要論レスにずっと違和感を抱いていたんだが、
その正体がようやく分かった。
アンチOOの人達って、オブジェクト指向を
抽象化 + 多態 + foo + bar + …
という、個別のテクニックの集合としか認識していないんだな。
業務アプリをオブジェクト指向という「指向」で分析・設計した結果として
多態というテクニックは必要ないと言うのであれば、それは別にOO的にも
全く問題ないんだが。
>>930
>>928は「お前は質問することで遠まわしに何かを言おうとしてるだろ」
って言いたいんだろうな。
>928の勘ぐりすぎだと思うわ。
>>895
> 「○○は馬鹿」ってのは、「○○するべきではない」って事なんだろうけどさ、
> 皆が課題に集中して解を探して協調してる雰囲気で、こういう表現はやっぱり適切でないと
> オレは思う訳よ。それは技術的に十分な根拠を伴うものでないという意味でもそうだし、
> 人間の精神面にも良い影響があるとは思えない。最近、攻殻GIG2見てて考えたんだけど、
> そう言うのって、創造や改良を仕事とする技術者っていう職種が求める人格の要素だと思うんよ。
「嘘や誇大表現、自明でない省略はオレが思ってたよりも遙かに高い割合で誤解を招く」
っての、お前の説明能力の低さが問題なんじゃないのか？
上の文章を要約すれば
「技術者が他人の意見を否定するのであれば、
『○○するのは馬鹿』という言い方をするのではなく、
具体的な技術的根拠の提示と、他人の精神面への配慮を行うことが必要だ。
そして、創造や改良を生業とする類の技術者は、人格にこういった要素を求める」
ってとこなんだろうが、
はっきり言ってお前の言い方じゃちゃんと伝わるか疑問だぞ。
話したい内容があちこちの文にゴチャゴチャに入り組んでスパゲッティになってるし、
改行の位置も内容を考慮してない。
ちゃんと日本語を勉強しろ。
>>928は「お前は質問することで遠まわしに何かを言おうとしてるだろ」
って言いたいんだろうな。
>928の勘ぐりすぎだと思うわ。
>>895
> 「○○は馬鹿」ってのは、「○○するべきではない」って事なんだろうけどさ、
> 皆が課題に集中して解を探して協調してる雰囲気で、こういう表現はやっぱり適切でないと
> オレは思う訳よ。それは技術的に十分な根拠を伴うものでないという意味でもそうだし、
> 人間の精神面にも良い影響があるとは思えない。最近、攻殻GIG2見てて考えたんだけど、
> そう言うのって、創造や改良を仕事とする技術者っていう職種が求める人格の要素だと思うんよ。
「嘘や誇大表現、自明でない省略はオレが思ってたよりも遙かに高い割合で誤解を招く」
っての、お前の説明能力の低さが問題なんじゃないのか？
上の文章を要約すれば
「技術者が他人の意見を否定するのであれば、
『○○するのは馬鹿』という言い方をするのではなく、
具体的な技術的根拠の提示と、他人の精神面への配慮を行うことが必要だ。
そして、創造や改良を生業とする類の技術者は、人格にこういった要素を求める」
ってとこなんだろうが、
はっきり言ってお前の言い方じゃちゃんと伝わるか疑問だぞ。
話したい内容があちこちの文にゴチャゴチャに入り組んでスパゲッティになってるし、
改行の位置も内容を考慮してない。
ちゃんと日本語を勉強しろ。
XPの本なんか読んでると業務系でのOO適用が間違いとは
考えにくいな。
問題は、改革をしてより効率的な開発プロセスを導入しよう
という発想のない人間が業務系に多すぎる事だろう。
良く言えば保守的、悪く言えば（というより真実）怠け者が多い。
考えにくいな。
問題は、改革をしてより効率的な開発プロセスを導入しよう
という発想のない人間が業務系に多すぎる事だろう。
良く言えば保守的、悪く言えば（というより真実）怠け者が多い。
せっかく有意義な流れになってんのに。
煽り合戦やめてこっちに混ざろうぜ。
>>939
DOAうんぬんは、全くその通りですね。
分析方法としてはやっぱり落ち着く。
ガチガチのOOAだと本読んだりすると
おおーかっちょえーとは思うけど
実装レベルで、一体どうすりゃいいの、となる。
OODB使いますなんて提案出来ないもんなあ。
>>942
胸のつかえがとれた感じ。
でも抽象も多態も、業務系でも
そう極端な例でなくて使うけどなあ。
煽り合戦やめてこっちに混ざろうぜ。
>>939
DOAうんぬんは、全くその通りですね。
分析方法としてはやっぱり落ち着く。
ガチガチのOOAだと本読んだりすると
おおーかっちょえーとは思うけど
実装レベルで、一体どうすりゃいいの、となる。
OODB使いますなんて提案出来ないもんなあ。
>>942
胸のつかえがとれた感じ。
でも抽象も多態も、業務系でも
そう極端な例でなくて使うけどなあ。
>>944
うちの会社とその周りの会社がおかしいだけかも知れないけど、
技術者を流れ作業で弁当に具を詰めてるパートのおばちゃんか何かと同列に見てるふしがある。
要するに、「新しい開発プロセスを導入したいと思っています。理由は……」ときちんと説明しても、
「君達は金を稼ぐ訳じゃないんだから黙って今まで通りやれ」と言われる。
猛烈にやる気が削がれる。何度言っても駄目だからもう諦めた。
会社変えた方がいいかな。
うちの会社とその周りの会社がおかしいだけかも知れないけど、
技術者を流れ作業で弁当に具を詰めてるパートのおばちゃんか何かと同列に見てるふしがある。
要するに、「新しい開発プロセスを導入したいと思っています。理由は……」ときちんと説明しても、
「君達は金を稼ぐ訳じゃないんだから黙って今まで通りやれ」と言われる。
猛烈にやる気が削がれる。何度言っても駄目だからもう諦めた。
会社変えた方がいいかな。
Torqueとかなかなか便利そうじゃん。
.NETにもこういうクラスってないのかな？
.NETにもこういうクラスってないのかな？
>>948
開発プロセスの問題で仕様変更頻発→コード変更が必要→ＯＯなら変更部分を減らせる鴨。
根から絶つなら、開発プロセスに手を付けるべきなんだろうな。
でも、開発プロセスの問題って、結局要求定義の問題になりそうな気がする。
やることが決まれば、最適な手順って決まっちゃうし。
で、仕様変更が少なくなるような要求定義→ＵＭＬとなるのかな。
でも、客は抽象度の高い話に付いてこれないから難しいよな。
開発プロセスの問題で仕様変更頻発→コード変更が必要→ＯＯなら変更部分を減らせる鴨。
根から絶つなら、開発プロセスに手を付けるべきなんだろうな。
でも、開発プロセスの問題って、結局要求定義の問題になりそうな気がする。
やることが決まれば、最適な手順って決まっちゃうし。
で、仕様変更が少なくなるような要求定義→ＵＭＬとなるのかな。
でも、客は抽象度の高い話に付いてこれないから難しいよな。
OODは必要ないが、C++などのOOPL使えばプログラミングが楽になるんじゃ？
その程度でいいっしょ。
その程度でいいっしょ。
>>926
Linux(Unix)やWindowsはメモリに関して非常に高度な割り当てを行ってる。
PCで開発するにはフラグメンテーションは殆ど気にする必要はないよ。
他のOS等では連続領域を先に確保しておくマネージャの導入をすればいい。
もちろんPCで組む場合も使える技術だ。
>>939
所詮はデータの塊ですね。
クラス図よりER図があった方がありがたい世界です。
ゲーム系もデータを表示しているだけなんですけどね･･･ｗ
Linux(Unix)やWindowsはメモリに関して非常に高度な割り当てを行ってる。
PCで開発するにはフラグメンテーションは殆ど気にする必要はないよ。
他のOS等では連続領域を先に確保しておくマネージャの導入をすればいい。
もちろんPCで組む場合も使える技術だ。
>>939
所詮はデータの塊ですね。
クラス図よりER図があった方がありがたい世界です。
ゲーム系もデータを表示しているだけなんですけどね･･･ｗ
>>929
その連続領域ってのでやってました。
PC以外のゲーム開発だとほぼデフォルトですよね・・・
ガベコレはないし、メモリ状況を正確に測れる事はシビアなメモリ環境では有利ですが、
その仕組みだと、好きなときに任意のサイズのオブジェクトをnewしたり、
いらなくなったのをdeleteするのって難しくないですか？
その連続領域ってのでやってました。
PC以外のゲーム開発だとほぼデフォルトですよね・・・
ガベコレはないし、メモリ状況を正確に測れる事はシビアなメモリ環境では有利ですが、
その仕組みだと、好きなときに任意のサイズのオブジェクトをnewしたり、
いらなくなったのをdeleteするのって難しくないですか？
>>954
スレ違いだが、汎用のnewやmallocを使わないで、既に割り当ててある
メモリを好きなサイズ分取得できる仕掛けを作る。
あまり洗練されていない（と私は思う）が、GameProgrammingGemsの
1.9フレームベースのメモリ割り当てを参照されてはどうか？
スレ違いだが、汎用のnewやmallocを使わないで、既に割り当ててある
メモリを好きなサイズ分取得できる仕掛けを作る。
あまり洗練されていない（と私は思う）が、GameProgrammingGemsの
1.9フレームベースのメモリ割り当てを参照されてはどうか？
>>954
＞好きなときに任意のサイズのオブジェクトをnew
と、
＞メモリ状況を正確に測れる事
は、本気でシビアな環境下では、別にオブジェクト指向とか関係なく
両立困難だと想うんだが。
設計上の工夫でオブジェクトをnewするタイミングやそのオブジェクトの
サイズを限定する事でシビアなメモリ要件を満たすというのはありうるし、
オブジェクト指向はその「設計上の工夫」の助けになるだろう。
また、C++の機能をフルに使えるなら、new演算子の再定義ってのも
バランスの良い落し所を得るためのツールとなる。
＞好きなときに任意のサイズのオブジェクトをnew
と、
＞メモリ状況を正確に測れる事
は、本気でシビアな環境下では、別にオブジェクト指向とか関係なく
両立困難だと想うんだが。
設計上の工夫でオブジェクトをnewするタイミングやそのオブジェクトの
サイズを限定する事でシビアなメモリ要件を満たすというのはありうるし、
オブジェクト指向はその「設計上の工夫」の助けになるだろう。
また、C++の機能をフルに使えるなら、new演算子の再定義ってのも
バランスの良い落し所を得るためのツールとなる。
もちろん汎用のnew、mallocなんか使わないです。
GEMSは見てないですが、たぶん、あるクラスのインスタンスの最大数は
１０個だからインスタンスサイズ１０個分のメモリブロックを作って、
クラスのnewをオーバーロードして、そこから割り当てる
というようなやり方だと思うんですが・・・
GEMSは見てないですが、たぶん、あるクラスのインスタンスの最大数は
１０個だからインスタンスサイズ１０個分のメモリブロックを作って、
クラスのnewをオーバーロードして、そこから割り当てる
というようなやり方だと思うんですが・・・
>>957
そうそう、バランスの良い落としどころを得ることになるんですよ。
でも、それはメモリがたくさんあって、new、deleteがいつでもできて
虫食いが多少出来ようが、ちゃんとコレクションされて
メモリオーバーには絶対ならないような環境と比べると、
設計の幅が狭まってしまうと思うんですよね。
リソースがシビアでもOOPはできる。けど、やっぱりリソースが有り余ってる
環境に比べたら設計の限界が出てくるってことを言いたかったんですよ。
そうそう、バランスの良い落としどころを得ることになるんですよ。
でも、それはメモリがたくさんあって、new、deleteがいつでもできて
虫食いが多少出来ようが、ちゃんとコレクションされて
メモリオーバーには絶対ならないような環境と比べると、
設計の幅が狭まってしまうと思うんですよね。
リソースがシビアでもOOPはできる。けど、やっぱりリソースが有り余ってる
環境に比べたら設計の限界が出てくるってことを言いたかったんですよ。
日記はちらしの裏に書いてくださいね。
俺の周りでは、クライアントがブラウザだったら、ほぼJAVAだな。
WEB系なら有無をいわさずJAVAって感じだね。
業務アプリと同程度のものでもJAVA。
set、getメソッドうぜえって感じ。
WEB系なら有無をいわさずJAVAって感じだね。
業務アプリと同程度のものでもJAVA。
set、getメソッドうぜえって感じ。
962 ：在日外国人参政権反対：04/11/09 00:10:31
＞947
この業界でやってくんなら会社換わるなりしたほうがいいんじゃないでしょうか。
この業界でやってくんなら会社換わるなりしたほうがいいんじゃないでしょうか。
なんか、極端だよ。
業務系の話をしたかと思うと、次はゲームのメモリ管理なんて。
質問するやつも答えるヤツも、流れを無視していいのか？
業務系の話をしたかと思うと、次はゲームのメモリ管理なんて。
質問するやつも答えるヤツも、流れを無視していいのか？
| ／,／´ .i'／ ノ／ ヾt､
!i ! ,.: ----- :...,_,......!.,,__ _,.. ::--' ´= :..,,_ 'j'ヽ
t ! /´::::::::::::::::::::::::::ヾ,~｀`'ヽ::::::::::::::::::::::::::::::`'':::..,t,
ヾ i:::: : : : :.. :::::::::!j t`:::::: :: : : : : : : :::::::::::::::::':,
':, i::: : : : :::: : : : : : :ノ,: ゝ ﾐ: : : : : :::: : : : : :::::::::::!
ヽ .'､...;;;;;;;;;;;;;..... ,.ｲ ,' ヽ : ..:::::: ::.... : : ::::::丿
__,...r-‐ヽ:ゝ.,,_:::::::,..r'´. ;' `: 、::::::::::::::: : ::ノ!
/ ! ヽ｀~t / `'- =::- ''´ ﾉ
/ | ）.:-+--‐‐k.、 ゝk,.....イ/
/ . i ./='''"_,,'y.', "''`ヽ､:: ゝ :.,,~,.ノ´
/ .! ._/,,,,../'--' ':.、 -='::,=-- ヽ ,,.._,..イ バカだからさ。
.! ／''"~~ ~`"'t--.,,＼ .....'.; :: ~' : . ,,__
,r ' !／ !...,,丿__＼ __,,..ノ .:::,..r ' : : :
.i ／ ,......k-'' ‐-‐ '´ ｀~T~k, . . ;' _,..:::''´ : : ,.. r:''"
,|.(´ _,,,,,.... -'"-=`',,k___ ,r '"~~`y''/‐‐ '''": : :,. r:::''": : : :
/ /''"´ ~~`ヽ, ::/ : : : : .ノ.;:' ,..r:'ヽ,,/.,,......,_
!i ! ,.: ----- :...,_,......!.,,__ _,.. ::--' ´= :..,,_ 'j'ヽ
t ! /´::::::::::::::::::::::::::ヾ,~｀`'ヽ::::::::::::::::::::::::::::::`'':::..,t,
ヾ i:::: : : : :.. :::::::::!j t`:::::: :: : : : : : : :::::::::::::::::':,
':, i::: : : : :::: : : : : : :ノ,: ゝ ﾐ: : : : : :::: : : : : :::::::::::!
ヽ .'､...;;;;;;;;;;;;;..... ,.ｲ ,' ヽ : ..:::::: ::.... : : ::::::丿
__,...r-‐ヽ:ゝ.,,_:::::::,..r'´. ;' `: 、::::::::::::::: : ::ノ!
/ ! ヽ｀~t / `'- =::- ''´ ﾉ
/ | ）.:-+--‐‐k.、 ゝk,.....イ/
/ . i ./='''"_,,'y.', "''`ヽ､:: ゝ :.,,~,.ノ´
/ .! ._/,,,,../'--' ':.、 -='::,=-- ヽ ,,.._,..イ バカだからさ。
.! ／''"~~ ~`"'t--.,,＼ .....'.; :: ~' : . ,,__
,r ' !／ !...,,丿__＼ __,,..ノ .:::,..r ' : : :
.i ／ ,......k-'' ‐-‐ '´ ｀~T~k, . . ;' _,..:::''´ : : ,.. r:''"
,|.(´ _,,,,,.... -'"-=`',,k___ ,r '"~~`y''/‐‐ '''": : :,. r:::''": : : :
/ /''"´ ~~`ヽ, ::/ : : : : .ノ.;:' ,..r:'ヽ,,/.,,......,_
＿ ＿ ＿ ＿
／::. ｿ . :;;ヽ ／::. ｿ . :;;ヽ
/::. ..:::;;;ヽ /::. ..:::;;;ヽ
/::. ..::;;;;ヽ /::. ..::;;;;ヽ
/::. ..::::;;;;i /::. ..::::;;;;i
（::. ..::;;;丿 （::. ..::;;;丿
>::...＿＿＿..::::;;;イ >::...＿＿＿..::::;;;イ
!ヾ.￣⌒_＿￣彡| !ヾ.￣⌒_＿￣彡|
iﾐ:::ミＣ＝ ≡..::: ） iﾐ:::ミＣ＝ ≡..::: ）
|::: ″. ´/ |::: ″. ´/
|::: （' （ ::;;;| |::: （' （ ::;;;|
|::: | ﾐ ヽ＼| |::: | ﾐ ヽ＼|
|::: 丶ヽ ..:ヽ ） |::: 丶ヽ ..:ヽ ）
（ ＼ l. | ..:;;;;;;| （ ＼ l. | ..:;;;;;;|
|::＼∨丿 ″..:;;;;;| |::＼∨丿 ″..:;;;;;|
|::: | ﾐ ヽ＼| |::: | ﾐ ヽ＼|
|::: 丶ヽ ..:ヽ ） |::: 丶ヽ ..:ヽ ）
（ ＼ l. | ..:;;;;;;| （ ＼ l. | ..:;;;;;;|
|::＼∨丿 ″..:;;;;;| |::＼∨丿 ″..:;;;;;|
|::: （ ( ﾞ ..:;;;;;| |::: （ ( ﾞ ..:;;;;;|
（ ＼ l. | ..:;;;;;;| （ ＼ l. | ..:;;;;;;|
|::＼∨丿 ″..:;;;;;| |::＼∨丿 ″..:;;;;;| サワッテモ
|::: （ ( ﾞ ..:;;;;;| |::: （ ( ﾞ ..:;;;;;| イイデスカー
／::. ｿ . :;;ヽ ／::. ｿ . :;;ヽ
/::. ..:::;;;ヽ /::. ..:::;;;ヽ
/::. ..::;;;;ヽ /::. ..::;;;;ヽ
/::. ..::::;;;;i /::. ..::::;;;;i
（::. ..::;;;丿 （::. ..::;;;丿
>::...＿＿＿..::::;;;イ >::...＿＿＿..::::;;;イ
!ヾ.￣⌒_＿￣彡| !ヾ.￣⌒_＿￣彡|
iﾐ:::ミＣ＝ ≡..::: ） iﾐ:::ミＣ＝ ≡..::: ）
|::: ″. ´/ |::: ″. ´/
|::: （' （ ::;;;| |::: （' （ ::;;;|
|::: | ﾐ ヽ＼| |::: | ﾐ ヽ＼|
|::: 丶ヽ ..:ヽ ） |::: 丶ヽ ..:ヽ ）
（ ＼ l. | ..:;;;;;;| （ ＼ l. | ..:;;;;;;|
|::＼∨丿 ″..:;;;;;| |::＼∨丿 ″..:;;;;;|
|::: | ﾐ ヽ＼| |::: | ﾐ ヽ＼|
|::: 丶ヽ ..:ヽ ） |::: 丶ヽ ..:ヽ ）
（ ＼ l. | ..:;;;;;;| （ ＼ l. | ..:;;;;;;|
|::＼∨丿 ″..:;;;;;| |::＼∨丿 ″..:;;;;;|
|::: （ ( ﾞ ..:;;;;;| |::: （ ( ﾞ ..:;;;;;|
（ ＼ l. | ..:;;;;;;| （ ＼ l. | ..:;;;;;;|
|::＼∨丿 ″..:;;;;;| |::＼∨丿 ″..:;;;;;| サワッテモ
|::: （ ( ﾞ ..:;;;;;| |::: （ ( ﾞ ..:;;;;;| イイデスカー
__
i＜´ }＼ , - 、
ヽ.._＼./ .ﾝく r-兮、 ＿_
∠｀ヽ.! / ヾﾆEｦぐ ,ゝ-＞
/＿｀ｼ'Ｋ-───‐-､l∠ イ さすがゴッグだ、 何ともないぜ！
l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤
. l'___|⌒ヾ''ｰ＝=､ｰr='ｲ ｉ二|
/ .｣ i /./7r‐く lー!
. ｆ. ヽ‐ｉ人.∠'＜ ＿i. l,.-ゝ.
ﾄiﾍﾍ｢ﾄ〈 ｀X ﾄﾚi7__|
〉ﾄ:ﾄﾊj｀! i. / ﾄｰ┤lﾙj,ﾘ
/‐+----+‐l iｰ--i---ヾ'〃
. ｌ＿i＿＿__i__| |＿__i,＿＿i_|
i＜´ }＼ , - 、
ヽ.._＼./ .ﾝく r-兮、 ＿_
∠｀ヽ.! / ヾﾆEｦぐ ,ゝ-＞
/＿｀ｼ'Ｋ-───‐-､l∠ イ さすがゴッグだ、 何ともないぜ！
l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤
. l'___|⌒ヾ''ｰ＝=､ｰr='ｲ ｉ二|
/ .｣ i /./7r‐く lー!
. ｆ. ヽ‐ｉ人.∠'＜ ＿i. l,.-ゝ.
ﾄiﾍﾍ｢ﾄ〈 ｀X ﾄﾚi7__|
〉ﾄ:ﾄﾊj｀! i. / ﾄｰ┤lﾙj,ﾘ
/‐+----+‐l iｰ--i---ヾ'〃
. ｌ＿i＿＿__i__| |＿__i,＿＿i_|
>>963
でもまあスレタイには逢ってるから、いいんでないの？
でもまあスレタイには逢ってるから、いいんでないの？
>>909のような要件で、Criteriaというか検索条件クラスを作った。
複数の条件を任意にWebブラウザで取捨できる。
条件ごとに、その入力内容は異なり、OrやAndが入り混じる。
□ Foo
〇 branchA 〇 branchB
□ Bar
□ optionP □ optionQ
□ Baz
〇 branchX
〇 branchY
〇 range [yyyy/mm/dd]～[yyyy/mm/dd]
□ Zot [ ]
こんなの if ～ "xxx" + "yyy" なんてやってられない。
複数の条件を任意にWebブラウザで取捨できる。
条件ごとに、その入力内容は異なり、OrやAndが入り混じる。
□ Foo
〇 branchA 〇 branchB
□ Bar
□ optionP □ optionQ
□ Baz
〇 branchX
〇 branchY
〇 range [yyyy/mm/dd]～[yyyy/mm/dd]
□ Zot [ ]
こんなの if ～ "xxx" + "yyy" なんてやってられない。
業務系のOOってあれだよ。
かっぱ巻きとかんぴょう巻きと玉子焼きしかメニューのない寿司屋みたいなもの。
たしかにそれらも寿司には違いないけどね。
かっぱ巻きとかんぴょう巻きと玉子焼きしかメニューのない寿司屋みたいなもの。
たしかにそれらも寿司には違いないけどね。
>968
仕様追加でカラムのMAX値を取得する必要性が出てきました。
select MAX(xx) を書く必要があります。
さて、どういう風に取り込みますか？
仕様追加でカラムのMAX値を取得する必要性が出てきました。
select MAX(xx) を書く必要があります。
さて、どういう風に取り込みますか？
業務系のＯＯってさ、ＤＢに入ってるデータから派生して
必要になるデータが少ないのと、いつでも高速にＤＢへ
アクセスできるって言う前提があるから、データをＤＢ以外の
部分で管理する必要がないという理由で不要だと考えられる
わけだよな。これはＤＯＡ派の言い分になるのかな。
でも、データへのアクセスを抽象性を持たせて階層化して
おくことで、仕様変更に柔軟に対応できるという点で意味はある
とも考えられるわけだよな。
じゃ、業務系でＯＯの効果を得るには、業務系の抽象性って
いうのが、どうあるべきかって問題になるってこと、
具体的には、まずＭＶＣの分離が行われているとすると、
次にいかにＭ（モデル）を階層化するかって問題なわけだ。
必要になるデータが少ないのと、いつでも高速にＤＢへ
アクセスできるって言う前提があるから、データをＤＢ以外の
部分で管理する必要がないという理由で不要だと考えられる
わけだよな。これはＤＯＡ派の言い分になるのかな。
でも、データへのアクセスを抽象性を持たせて階層化して
おくことで、仕様変更に柔軟に対応できるという点で意味はある
とも考えられるわけだよな。
じゃ、業務系でＯＯの効果を得るには、業務系の抽象性って
いうのが、どうあるべきかって問題になるってこと、
具体的には、まずＭＶＣの分離が行われているとすると、
次にいかにＭ（モデル）を階層化するかって問題なわけだ。
カラムってなんだよ列のことか？ろくにDB触ったことのないゲーム系はすっこんでろ。
なに、ゲームじゃない、S○NY様のプログラマだって？MDBなんかつかってるから
あちこち不具合が出るんだよ。奏じゃなくても何でもいいがOOとRDBの関係がどんなものか
二晩考えてからで直して来い。
で、取ってくる列の属性としてクエリ式を持たせるのが普通じゃないの？
検索条件と取ってくる式は別オブジェクトだから、この際まとめて考えなくてもいいと思うんだが。
なに、ゲームじゃない、S○NY様のプログラマだって？MDBなんかつかってるから
あちこち不具合が出るんだよ。奏じゃなくても何でもいいがOOとRDBの関係がどんなものか
二晩考えてからで直して来い。
で、取ってくる列の属性としてクエリ式を持たせるのが普通じゃないの？
検索条件と取ってくる式は別オブジェクトだから、この際まとめて考えなくてもいいと思うんだが。
「オブジェクト指向とはオブジェクト同士の相互作用としてシステムの振る舞いを捉える考え方である」
（wikipediaより）
業務アプリの大半は伝票や台帳がDBに替わって、鉛筆がマウスやキーボードに変わっただけだろ？
一体その中で何をオブジェクトにするねん という話。
データはDBが管理してくれるし、データの操作はSQLでできる。
データの整合性のチェックや、連携操作（カスケード式にデータを削除する機能とか）もDBがやってくれる。
なんだ結局全部DBがやってくれるんじゃん。
分析はオブジェクト指向分析でもいいが、そのアウトプットはクラス図やシーケンス図じゃなくて、
DBのテーブル設計やデータフロー。
あとは「はい、コーダーさん、このトランザクションが発生したらこのテーブルとこのテーブルを更新してね。
こっちのコーダーさんはこの画面でこのボタンが押されたら、このテーブルからデータ取ってきて
ここに表示してね」でも十分な場合が多い。
オブジェクト指向が世に出て数十年、さまざまな入門書/解説書が溢れ、特定の分野の現場ではすでに
常識になっているのに業務アプリの分野ではさほど普及しておらず、まったく理解していない人も
多いのが何よりの答え。
適用することによるメリットがよくわからないから「オブジェクト指向は難しい」となってしまう。
それを使わなくてもそれほど不自由のない状況で新しい道具を与えられても、無理して使い方を覚えようと
する人はあまりいない。
（wikipediaより）
業務アプリの大半は伝票や台帳がDBに替わって、鉛筆がマウスやキーボードに変わっただけだろ？
一体その中で何をオブジェクトにするねん という話。
データはDBが管理してくれるし、データの操作はSQLでできる。
データの整合性のチェックや、連携操作（カスケード式にデータを削除する機能とか）もDBがやってくれる。
なんだ結局全部DBがやってくれるんじゃん。
分析はオブジェクト指向分析でもいいが、そのアウトプットはクラス図やシーケンス図じゃなくて、
DBのテーブル設計やデータフロー。
あとは「はい、コーダーさん、このトランザクションが発生したらこのテーブルとこのテーブルを更新してね。
こっちのコーダーさんはこの画面でこのボタンが押されたら、このテーブルからデータ取ってきて
ここに表示してね」でも十分な場合が多い。
オブジェクト指向が世に出て数十年、さまざまな入門書/解説書が溢れ、特定の分野の現場ではすでに
常識になっているのに業務アプリの分野ではさほど普及しておらず、まったく理解していない人も
多いのが何よりの答え。
適用することによるメリットがよくわからないから「オブジェクト指向は難しい」となってしまう。
それを使わなくてもそれほど不自由のない状況で新しい道具を与えられても、無理して使い方を覚えようと
する人はあまりいない。
だから糞レベルのSョが威張り散らす世界になるわけなんだ。
http://www.unisys.co.jp/dotnet/pdf/shinwa.pdf
オブジェクト指向は決して万能ではありません。メリットもあればデメリットもあります。
それにもかかわらずオブジェクト指向技術が神話化され、利用すること自体が「目的」
となってしまっているプロジェクトもあるようです。
オブジェクト指向を盲目的に信じるのではなく・・・
オブジェクト指向は決して万能ではありません。メリットもあればデメリットもあります。
それにもかかわらずオブジェクト指向技術が神話化され、利用すること自体が「目的」
となってしまっているプロジェクトもあるようです。
オブジェクト指向を盲目的に信じるのではなく・・・
業務系は確かに、複雑な非線形方程式を解くと言うより、
多連立一次方程式を如何に効率よく解くかというのに似てるよな。
高尚な思想なんてなしに、ごりごりと代入法だけで解くヤツもいると。
でも、ＯＯのスレなんだから、とりあえずＯＯを適応することを考えて、
そのメリットとデメリットについて語るべきだろうな。
ＵＭＬ２がでてきたのも、この業務系の単調さを考慮してのことなんだろうかね。
多連立一次方程式を如何に効率よく解くかというのに似てるよな。
高尚な思想なんてなしに、ごりごりと代入法だけで解くヤツもいると。
でも、ＯＯのスレなんだから、とりあえずＯＯを適応することを考えて、
そのメリットとデメリットについて語るべきだろうな。
ＵＭＬ２がでてきたのも、この業務系の単調さを考慮してのことなんだろうかね。
.NETのDataSetって結局DOAだよな
980 ：仕様書無しさん：04/11/09 19:49:18
｢OOは万能｣そう考えていた時期が私にもありました。
それが妄想だったと認めるのはつらいですが、これもOOが認知され成熟した結果だと受け止めています。
今の私にできることは，かつての私と同じように目が見えなくなってしまっている人をケアしてあげることだと思っています。
それが妄想だったと認めるのはつらいですが、これもOOが認知され成熟した結果だと受け止めています。
今の私にできることは，かつての私と同じように目が見えなくなってしまっている人をケアしてあげることだと思っています。
>>1
超遅レスでスマソが、OOはコード量減るよね？
超遅レスでスマソが、OOはコード量減るよね？
>981
OOで減るのではなく、継承により減る。
OOで設計をした結果ではなく、OO言語の恩恵によるだけ
OOで設計したからって、Cで書いたらおんなじだろ
むしろ増えそう
OOで減るのではなく、継承により減る。
OOで設計をした結果ではなく、OO言語の恩恵によるだけ
OOで設計したからって、Cで書いたらおんなじだろ
むしろ増えそう
さらに言えば、機能の継承を連発すればもっと減る。
けど、それはオブジェクト指向プログラミングではない。
機能の継承と内包の継承の差を理解してるかしてないか
ここがオブジェクト指向の入り口
けど、それはオブジェクト指向プログラミングではない。
機能の継承と内包の継承の差を理解してるかしてないか
ここがオブジェクト指向の入り口
けど、
内包の継承と機能の継承が相反するものではない。
内包の継承の結果、機能が継承されるし、
何も考えず機能の継承をした結果、内包になっていることもある
内包の継承と機能の継承が相反するものではない。
内包の継承の結果、機能が継承されるし、
何も考えず機能の継承をした結果、内包になっていることもある
>984
お前がわかってないだけだよ
お前がわかってないだけだよ
コード量の話から、いきなりis-aとhas-aの関係の講釈を垂れ始める理由が分からん。
>>986
ほんとにそう思ってるなら重傷だ。
厨房、工房なら寝ろ。素人で意見を求めたいなら、そういう
文体で書け。
一応、今回だけ注釈入れといてやる。
＞OOで減るのではなく、継承により減る。
＞OOで設計をした結果ではなく、OO言語の恩恵によるだけ
設計がヘタレてればどんな言語でも、似たような関数やクラスが
多数現れ、コードが嵩張る。
＞OOで設計したからって、Cで書いたらおんなじだろ
例えば、ポインタを使うことでＣ＋＋で書けるコードは、
僅かな変更でＣのコードに直せる。
＞さらに言えば、機能の継承を連発すればもっと減る。
無駄にクラスを増やせばコードが伸びるのは自明。
＞機能の継承と内包の継承の差を理解してるかしてないか
＞ここがオブジェクト指向の入り口
なんでそんな話になるのかわからん。そもそも表現がおかしい。
機能の継承？has-aは継承とはいわん。
ほんとにそう思ってるなら重傷だ。
厨房、工房なら寝ろ。素人で意見を求めたいなら、そういう
文体で書け。
一応、今回だけ注釈入れといてやる。
＞OOで減るのではなく、継承により減る。
＞OOで設計をした結果ではなく、OO言語の恩恵によるだけ
設計がヘタレてればどんな言語でも、似たような関数やクラスが
多数現れ、コードが嵩張る。
＞OOで設計したからって、Cで書いたらおんなじだろ
例えば、ポインタを使うことでＣ＋＋で書けるコードは、
僅かな変更でＣのコードに直せる。
＞さらに言えば、機能の継承を連発すればもっと減る。
無駄にクラスを増やせばコードが伸びるのは自明。
＞機能の継承と内包の継承の差を理解してるかしてないか
＞ここがオブジェクト指向の入り口
なんでそんな話になるのかわからん。そもそも表現がおかしい。
機能の継承？has-aは継承とはいわん。
989 ：仕様書無しさん：04/11/10 01:00:07
内包の継承ってなに？
集約 or コンポジットのこと？
集約 or コンポジットのこと？
OOのコード量が構造化よりも減る事が感覚的にわからないなら、
それはきっとクラスを使いこなせていないんですよ。
それはきっとクラスを使いこなせていないんですよ。
991 ：仕様書無しさん：04/11/10 01:49:19
ヘタレ設計のくせにＯＯな言語でコードが減るのは、
単にフレームワークがクラスライブラリとして既に提供されてるから。ライブラリが見えない部分で使われてるだけのこと。
それが言語仕様と別の話なのがわからない>>986は、適性なしだな。
単にフレームワークがクラスライブラリとして既に提供されてるから。ライブラリが見えない部分で使われてるだけのこと。
それが言語仕様と別の話なのがわからない>>986は、適性なしだな。
993 ：仕様書無しさん：
このスレっていい感じだけど次スレあるの？