辻（忠）です。
>○月△日(月)
>173 と 984の積を計算しなくてはならなくなったので
関数を作りました。
>
>int times173and984(){ return 170232; }
（中略）
>○月△+3日(木)
>今日は 173と734の積を計算する必要がありました。
>火曜と水曜に作った関数に似ているのでまとめました。
>リファクタリングの醍醐味ここにありです。
>
>int times[1000][1000];
>
>int times( int x, int y ){
> times[173, 984] = 170232;
> times[728, 734] = 534532;
> times[173, 42] = 7266;
> times[173, 734] = 126982;
> return times[x, y];
>}
大変興味深いです。
初めてXPについての説明を受けた場合に
漠然と浮かんでくる疑問の一つが
こんな、
「汎用性を無視した作りによる構造の甘さ」
が生じる状況でしょうね。
私も同じ事で悩んだことがあります。
>一般化したらだめだっていうことは、
△日に times()を作らないということですよね。
>何週間か後にやってくる△+ω日に、
任意のxとyについて積が必要になったら、
>そのときはじめてtimes()を作るんですよね。
>
>一般化するほうが問題が簡単になる場合もあると
どこかで読んだしそう思うのですが、
>XPでははっきりとそれを禁止していますよね。
私としてはこの正解は
「3回目以上同じ形式の関数を作る必要が出てきたら、
一般化していく。」
だと思います。
これは確か「リファクタリング」に載っていた基準です。
いっそ
「3回目からは一般化する。
すべきであり、しなければいけない。」
くらいの捉え方でもいいと思います。
ですから、○月△+3日(木)の部分は
＞＞＞＞＞
いままで作った関数と同等の関数がまた必要になった。
一般的な方法を模索し、以下のように変更。
int times( int x, int y ){
return x * y;
}
これぞリファクタリング！！
＜＜＜＜＜
といったものになるべきではないかと。
もしくは、配列を使った明らかにおかしいコーディングを見た誰かが
それを指摘・変更していくべきでしょう。
一人で考えているとこういった
袋小路的な思考になりそうですが、
そこをカバーするのがコードの共有化・ペアプロだと思うわけです。
＃実践していないので憶測です。
大事なのは
「リファクタリングするタイミングでは設計について悩む」
って事だと思います。
コーディングを進める時点では
簡単＆即興（ハック＆スラッシュ！）の方法を。
リファクタリングでは
読みやすさ・設計のありかたを考えた方法を。
被る帽子で思考パターンも変えることだと思います。
以上です。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
辻 忠一 mailto:tsujit@....jp
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/