ポリモーフィズムを使ったリファクタリングの実践例

ポリモーフィズムを使ってないひどいコード設計を見たので、どうリファクタリングするべきだったのかを書いておく。

やばい匂いのするコード

そのシステムでは、複数の銀行とのやりとりを行うため、銀行コードに基づいて処理を分岐していた。そうこんな風に

void 入金(銀行コード, ユーザID, 金額){
    if(銀行コード==0001){
        // A銀行用の処理
        ...
    } else if(銀行コード==0002){
        // B銀行用の処理
        ...
    } else {
       // エラー
    }
}

void 出金(銀行コード, ユーザID, 金額)
    if(銀行コード==0001){
        // A銀行用の処理
         ...
    } else if(銀行コード==0002){
        // B銀行用の処理
         ...
    } else {
      　// エラー
    }
}

ここでは2つしか出してないけど、実際はもっと数が多いと思って欲しい。30個くらいはあったかもしれないがよく覚えてない。
考えてみてほしい。銀行コードを判定して処理を切り替えるというコードが何十個もそこかしこに散らばってる様を。そしてそのそれぞれの箇所に修正を入れて、テストをしなければならない手間を。

これは「もともと対応していた銀行が１つしか無かったところに、突貫工事でコードを追加したからこうなった。」と聞いているが、それにしたってもっと賢いやり方があっただろう。技術的負債とはまさにこういった設計の事だ。

リファクタリング

こんな時こそポリモーフィズムの出番だ。ポリモーフィズムをうまく使うと条件分岐を削減できる。
まず銀行用のインターフェースを抽出する。入金とか、出金とか、営業時間内かどうかの判定とか、そういったまさに銀行とのインターフェースとなるメソッドを抽出するのだ。

interface 銀行 {
    void 入金(ユーザID, 金額);
    void 出金(ユーザID, 金額);
    boolean 営業時間内判定(日時);
}

そいで、次に、各銀行ごとにこのインターフェースを実装したクラスを作る。

A銀行 implements 銀行{
    void 入金(ユーザID, 金額){

    }
    void 出金(ユーザID, 金額){

    }
    boolean 営業時間内判定(日時){
        // 9:00から18:00までならtrueを返す
    }
}

B銀行 implements 銀行{
    void 入金(ユーザID, 金額){

    }
    void 出金(ユーザID, 金額){

    }
    boolean 営業時間内判定(日時){
　       // 9:00~20:00までならtrueを返す
    }
}

こうすることで、営業時間が違うとか、電文パラメータが違うとか、そういった銀行の違いは個別の銀行クラスの中に閉じ込める事ができる。

あとは、各処理で銀行コードを判定していた処理の代わりに、銀行ごとのオブジェクトを作る際に1回だけ銀行コードを判定して作ってやればいい。そうすれば、この銀行インターフェースを使っている限りはビジネスロジック側で銀行ごとの違いを気にする必要は無くなる。

ビジネスロジック側はこうなる。

銀行オブジェクト bank;

if(銀行コード==0001){
    // A銀行用のインスタンス生成
    bank = new A銀行();
} else if(銀行コード==0002){
    // B銀行用のインスタンス生成
    bank = new B銀行();
} else {
    // エラー
}

if( bank.営業時間内判定()){
    bank.入金(ユーザID,　金額);
} else {
    // 取り扱い時間外メッセージ表示
}