質問: 連投になってしまってすみません。 どうしても気になることがあり、連投させていただきました。 私は今、Visual Basic 2008 でプログラムの改修作業を行っています。 以前に書かれたソースコードに機能を追加したり、バグを修正したりする作業です。 今は ActiveReports for .NET 3.0J を使用した帳票出力のプログラムの改修作業を行っています。 そのソースコードは、一つのフォームクラス内ですべての処理を行っています。 * フォームに入力された値のチェック * 入力ミスの部分のスタイルを変え(背景色を目立つ色にする)、ステータスバーにエラーメッセージを表示する * SQL文の生成、パラメータの値をバインド、クエリの発行、結果の取得 * 結果を帳票出力形式にフォーマット(日付を"yyyy/MM/dd"形式にしたりなど) このようなソースコードに新たに機能を追加したりしようとしていますが、私はまずこのソースコードをきれいに分割したいと考えています。 (この判断が正しいかどうかも知りたいです...) 次のようなクラスに分割したいと考えています。 * フォーム用クラス * 入力値チェック用クラス * Data Access Object...SQL文の作成、結果となるDataTableオブジェクトを返す * ActiveReports のクラス...帳票出力形式への変換はこのクラスで行う しかし、うまく分割することができません。 例えば、SQL文を作成するとき、フォーム内のチェックボックスにチェックが入っているかどうかでSQL文が異なります。 このようなとき、チェックボックスが一つか二つ程度ならいいのですが、五つ以上あったりすると、それらすべてを引数としてData Access Objectに渡すのも憚られます。 フォームの状態によって幾通りものSQL文が生成されるとき、どのように設計すれば綺麗に解決するかがわかりません。 「入力値チェック用クラス」というのもうまく分割できません。 どのように設計すれば、この問題をうまく解決できるのでしょうか?何か適用できるデザインパターンがあるのでしょうか。 何か知っている方がいましたら、教えていただけると嬉しいです。
回答: > このようなソースコードに新たに機能を追加したりしようとしていますが、私はまずこのソースコードをきれいに分割したいと考えています。 > (この判断が正しいかどうかも知りたいです...) プログラマとしてはごく自然な判断だと思います。 ただ、会社の文化によってはそれを良しとしないところもあります。今後のメンテナンスを効率よく行うために絶対必要だということを上司や同僚に理解してもらえて、なおかつ修正のコストをかけることが許されるかによって、実施できるかどうかが変わってきます。 > このようなとき、チェックボックスが一つか二つ程度ならいいのですが、五つ以上あったりすると、それらすべてを引数としてData Access Objectに渡すのも憚られます。 > フォームの状態によって幾通りものSQL文が生成されるとき、どのように設計すれば綺麗に解決するかがわかりません。 実際のソースを見ていないので的確かどうかわかりませんが、できるだけData Access Objectをシンプルに作った方が良いのではないかと思います。 チェックボックスなどの状態による分岐処理はフォーム側でさせて、分岐の結果を番号などでData Access Objectに渡す、Data Access Objectはその番号に対応したSQLを実行して結果を返す、というような形です。多少冗長になるでしょうが、後からメンテナンスするのに楽になるのではないかと思います。