プログラムを作る時、
大抵はいくつかのパーツに分ける。
プロパティファイルを読み込むリーダーを作るなら
BinaryFileReader <- TextFileReader <- LineFileReader <- PropertyFileReader
な感じだろうか。
普通ならPropertyFileReaderに使うプロパティファイルをパラメータで指定し、
BinaryFileReader <- TextFileReader <- LineFileReader
の部分は何も変更が無く、大抵のファイルならそのまま流用ができる。
この場合の正統派なコピペは、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
PropertyFileReader pfr2 = new PropertyFileReader(“xxxxxxx-2.property”);
PropertyFileReader pfr3 = new PropertyFileReader(“xxxxxxx-3.property”);
となる。
ところが実際には・・・
String [] fileNameList = {
“xxxxxxx-1.property”
,”xxxxxxx-2.property”
,”xxxxxxx-3.property”
};
List <PropertyFileReader> pfrLst = new List <PropertyFileReader>();
for( propertyFileList in propertyFile) {
pfrLst.Add( new PropertyFileReader(“xxxxxxx-1.property”) );
}
の様に、やりたい事に比べて助長過ぎるソースが美しいとされるが、何もメリットは無いし、
static final int   PROPERTY_FILE_INDEX_1  =0;
static final int   PROPERTY_FILE_INDEX_2  =1;
static final int   PROPERTY_FILE_INDEX_3  =2;
pfrLst[PROPERTY_FILE_INDEX_1 ].get(PROPERTY_MEBMER_1);
pfrLst[PROPERTY_FILE_INDEX_2 ].get(PROPERTY_MEBMER_2);
pfrLst[PROPERTY_FILE_INDEX_3 ].get(PROPERTY_MEBMER_3);
のように面妖なConst 定数を使ってプロパティファイルにアクセスしなくてはならなくなり、また勢いソースの行は妙に長くなってしまう。
悪い例のレビュー前： 　pfr1.get(“1”);
悪い例のレビュー後：　pfrLst[PROPERTY_FILE_INDEX_1 ].get(PROPERTY_MEBMER_1);
つまり、やりたい事を理解せずにソースレビューだけするとたった３行のコピペが上の様な有様に至ってしまう。
更に、ファイル名をConstクラスに差し込んだり、あるいは・・・プロパティファイルに入れてみたりすると、もう終わってる感じがする。
これはWEBでよく見かける見栄えの良いコーディングとは

無駄の塊

でしかないことを意味する。
では、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
という1文は見栄えが悪いのかと云えば、そんなことは無い。
ただ、
PropertyFileReader pfr1 = new PropertyFileReader(“xxxxxxx-1.property”);
・・・(98行中略)・・・
PropertyFileReader pfr100 = new PropertyFileReader(“xxxxxxx-100.property”);
となれば何か方法は無いのか？と云いたくなるだけだ。
こうなると、先の無駄の塊がなんとなく見栄えが良く見えてくるから不思議である。
但し、１００個もファイルを開いて何をするつもりなのか？という根本的な問題をまず考えるべきである。
その結果が、

１００個ファイルを開いても大丈夫なことを確認したかっただけ

だったりすると、１００行のコピペで十分な気がする。（大笑
ただ世の中には尋常ではないコピペが存在する。
JCLである。
古い話で恐縮だが、JCLに渡せるパラメータは1個のINT型だけだった古い時代。
Aファイルを読み、書式を変換し、Bファイルに書き出す。
のような単純なことでも
Aファイルが１０個あれば
JCL00001
・・・
JCL00010
と違うプログラムを流さないといけなかった。
そう、この１０個のプログラムで異なる部分は入力ファイル名と出力ファイル名だけである。
なせなら、C言語が出現する前にも文字列型変数はあったが、概ね固定長であった。
このためJCLのパラメータに文字列型変数を使える様にすると
main( char parameter[10] ) {
・・・
}
にするしかなく、とてもかっこが悪かった。
更に、文字列型のパラメータの数を増やしたりしたら
main( char parameters[5] [10] ) {
・・・
}
とかになっても、どうやって読めばいいのか直観的に判らないシロモノになってしまうからだ。
もっとも、JCLごとにパラメータの数が違うような仕組みは考えられなかったのだろう。
なんたって、１バイトのメモリは血の一滴。とても貴重だった時代なのだから・・・
 
もっとも、パラメータが１～１０の場合にファイル名をＩＦ文で振り分ければいいハズだが、ソースレベルデバッガどころがラインデバッガさえ使わせて貰えない時代。つまりＶＤＴな画面とキーボードなんて高値の華だったころは、パ ンチカードな時代で、ＩＦ文を書くより、ファイル名の１行（カード１枚）を差し替える方が簡単で動作も確認しやすかったのだ。
ただ、その流れが現在も続いている（もちろん機能は色々拡張されている）のはかなりウザいなぁと思う次第だ。
※もちろん、ＭＭＯＲＰＧのマクロはＪＣＬ系ではある。
しかしＪＣＬを使うのが金稼ぎに来たプログラマなのに対して、
マクロを使うのはお金を払ってくれるユーザであるため、
使いにくいとは云われつつも、ＪＣＬの数億倍もパラメータが使いやす。
ＪＣＬに似ているが全くの別物である。