バッチの作り

月末までに引き継がなきゃいけないものの１つに、C#で作られたバッチがあります。（バッチの部分については、実際に携わったのは1日ぐらいですが、他に知っている人がいないもので。。）
で、このバッチプログラムはメイン処理では、テンプレートメソッドっぽい作り、機能群では、ストラテジっぽい作りでした。テンプレートメソッドはis-a,継承とオーバーライドによる処理の変更、ストラテジはhas-a,インターフェースとコンポジションによる処理の変更の意味で話していますが、デザインパターンは使ったことがないのでデザインパターンの理解が間違っているかも。。。
で、後任がオブジェクト指向の言語に慣れていないとちょっと戸惑うかも。
非オブジェクト指向の言語では、静的解析でも、充分に追跡可能だけども、オブジェクト指向言語だと、静的解析では追跡不可能になってしまう。
具体的に言うと、非オブジェクト指向言語では、問題のプログラムの最初から、呼び出し先に移動→呼び出し元に戻るという操作を繰り返していけば、最後まで到達可能だけれど、オブジェクト指向言語で作られている場合、呼び出し先に移動したところでベースクラスのメソッドやインターフェースのメソッド宣言に移動してしまい、ベースクラスの処理の中で(サブクラスでオーバーライドする処理でも)、ベースクラスのメソッドに移動してしまう。静的解析の場合は、これが限界のような気がします。
トラブルが起きたときに、普通にピンポイントで見たり、流れを順に追っていくとつらいことになりそう。
スーパークラスの役割を理解しておかないと何をやっているかさっぱり分からなくなるからね。

だから、デザインパターンは私にとって使うメリットがさっぱり理解できないです。私はアンチオブジェクト指向派です。
さらにこのスーパークラスで、サブクラスから呼び出すメソッドがあったりして、間違ったデザインパターンの作りになっています。
（テンプレートメソッドでは、スーパークラスに処理の流れが書いてあって、処理の流れの一部、他と違う処理をする機能のメソッドだけをサブクラスでオーバーライドする形で作りこむんだけど、今回のはスーパークラスに何故かユーティリティクラスみたいな機能を追加しています。ユーティリティの機能については、継承関係は全くないので、保守時の混乱を取り除くために別途ユーティリティクラスを起こすべきなのに。。。）

・・・わたくし、コピペ万歳の人なので。。。でも、コピペの作法を間違っているプログラムの作りをしてあって、さらにコピペ処理を失敗しているのを見るともっといらいらしてしまうのだけれど。。。


コピペの作法について、
コピペって、極力変更しないで使うもので、コピー元のプログラムの作りに工夫しておかなきゃいけないのに、その辺の工夫を全くしていないと酷いことになってしまう。（さらに変更しなきゃいけなくなった部分で変更していなかったりしてね。）