gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

リファクタリング:お題を考察してみる

以前書いた
http://d.hatena.ne.jp/gallu/20061228/p1
で、Jittaさんから

> 特に「SQL発行している部分」が散らかっているのは全力で忌避しませう。
ここねぇ。。。
 例えば、「顧客マスタ」と「商品マスタ」があるとする。
1.顧客マスタや商品マスタに「データベースからデータを持ってくる」処理を持たせる?
2.「データベースとお話しするクラス」に、「顧客マスタを取得する」処理、「商品マスタを取得する」処理持たせる?
3.「マスタのマスタクラス」を作り、この中で「データベースとお話しする処理」を実装。お話の方法(SQL 文の生成(もちろん、パラメータ使った))は、各派生クラスに任せる?

というお話しを頂戴してまして。
…いえ別に「コメントを返そうと思ってすっかり忘れてた」わけではないのですええ。脳内で色々と考察を重ねていただけなのですが(笑
以下、思考の流れにそって、ちょっと散文的になりますが、書いてみたいと思います。


前提:
「顧客マスタ」と「商品マスタ」がある


思考1
とりあえず「テーブル」があるわけなので、そのまま「顧客クラス」と「商品クラス」を計上する。
class 顧客
class 商品


思考2
そもこれらはDBに格納されているものなので、DBとお話しするクラス(多分実際には、DB HandleのクラスとSQL文関連のクラスとの2 lineが必要になりますが、とりあえず概念的に一括りにしておきます)を用意します。
なお、これと前述のクラスは、いわゆる「継承」はさせずにおきます(理由はとりあえず省略:DBMS「以外」を想定してみよう、がひとつの理由)。
class 顧客
class 商品
class DBとお話しする


思考3
マスタテーブル系は、多分どれも似通った動きになるので。ならばその部分については「親クラスに持ち上げた」ほうが、多分後々なにかと楽。
class マスタテーブル基本
class 顧客 継承 マスタテーブル基本
class 商品 継承 マスタテーブル基本
class DBとお話しする


とりあえずこんな風な「設計を」先に切ってみます。
んで、実際ですが。
多分私だと、まず「class DBとお話しする」を作るですっていうか多分持ってるです(持ってなきゃ作る)。このクラスは確定で「どこでも使える」ので。
次に「class マスタテーブル基本」を作るです。これも、特に業務系だと結構汎用的なクラスになるんじゃないでしょうか?
ここまでが「ある程度汎用的だからもしかしたら既にあるかも」な部分です。
「class 顧客」「class 商品」を実装するだけしておきます。
ここまでが「現在のプログラムにまったく影響しない」部分です。
次につなぎこむのですが。
私の場合まず「現在動いているソースの中から、顧客マスタテーブル、商品マスタテーブルを触っている部分にコメントを入れ込んで」いきます。マーキングですね。普通影響は出ない「はず」なのですが。ソースコードをいじるわけですから、影響の可能性は無視しないでおきます。
次に、各マスタを使っている場所の先頭で、実装したクラス(顧客 | 商品)のインスタンスを「作るだけ作って」おきます。
最後に、各マスタを「思い思いに」使っている場所を、ひとつづつ「新しいクラスを使ってごにょごにょする」ように修正しておきます。ついでに「マーキングコメント」を消してください。この方法だと、作業途中でも平気でソースコードがcommitできます。改修案件とかと並行する際には(つまり恒常的に常に必ずいつでも)大切ですね。
とどめ。grepでマーキングがなくなれば、作業は完了です。


まぁ色々な流儀とかあるかと思うのですが。ひとつのアイデアってことで見てもらいつつ、いつものことながら「突っ込みどころがあったら大歓迎」で。