デザインパターンを学び直す - Strategyパターン

デザインパターン。

今回はStrategyパターンを学び直します。

Strategyパターンはデザインパターンの中でも、簡単で理解しやすいもののようです。

ネットで色々見てみると、if文やswitch文で処理が長々と書かれているものに利用すると良いといわれています。

さっそく例を見てみましょう。

以下の処理があったとします。

public class Main {
    public static void main(String[] args){
        if (args.length == 0) {
            //条件なしでDBからデータとってくる
            //Aパターンでデータを加工する
            //DBに登録する
        } else if (args.length == 1) {
            //条件=args[0]でDBからデータとってくる
            //Bパターンでデータを加工する
            //DBに登録する
        } else if (args.length == 2) {
            //条件=args[0], args[1]でDBからデータとってくる
            //Cパターンでデータを加工する
            //DBに登録する
        }
    }
}

このままでも処理を理解することができますが、上記の処理を下のように変更するとすっきりします。

   public static void main(String[] args){
        Strategy strategy = null;
        if (args.length == 0) {
            strategy = new StrategyA();
        } else if (args.length == 1) {
            strategy = new StrategyB();
        } else if (args.length == 2) {
            strategy = new StrategyC();
        }
        strategy.doit();
    }

処理をクラス化することで利用する側は処理(アルゴリズム)の内容を意識しなくても良くなります。その結果、処理部分の拡張性、再利用性が高まります。

public interface Strategy {
    public abstract void doit();
}

public class StrategyA implements Strategy {
    @Override
    public void doit() {
        //条件なしでDBからデータとってくる
        //Aパターンでデータを加工する
        //DBに登録する
    }
}

public class StrategyB implements Strategy {
    @Override
    public void doit() {
        //条件=args[0]でDBからデータとってくる
        //Bパターンでデータを加工する
        //DBに登録する
    }
}

public class StrategyC implements Strategy {
    @Override
    public void doit() {
        //条件=args[0], args[1]でDBからデータとってくる
        //Cパターンでデータを加工する
        //DBに登録する
    }
}

個人的な意見としては、確かにモジュールが疎結合になって、再利用性や拡張性が高くなると思いますが、クラスが増えてしまうのが難点だと思います。なかなか使いどころが難しいかもしれないです。実際の現場で使っているところはあるのでしょうか。

後でわかったことですが、実際には、Strategyパターンは条件分岐を使わずに、Strategyの具象クラスをnewすることで処理を行うようです。さらにはStrategyの状態を保持するcontextクラスを用意して、newするクラスを動的に設定することもできます。