重要度：★★★★★

　本記事ではGoFのデザインパターンのプログラムの振る舞いに関するパターンの一つである「Strategy」パターンを解説します。このパターンを一言で説明するならば、「処理方法（戦略）をオブジェクトとして分離し、実行時に自由に切り替えられるパターン」と言えるでしょう。「Strategy」パターンをサンプルを踏まえて解説します。

Strategyパターンとは

　「Strategy」は戦略を意味する単語です。処理方法（戦略）を別のクラスに分離します。この時、一つのインタフェースを実装する形で分離するため、実行時にその処理方法（戦略）を自由に切り替えることが可能になります。

　このパターンは、最終的なゴールは一緒だが、その過程が違うような場合に有効です。日常生活の例で例えると以下のような場合が挙げられます。

• 支払い方法の切り替え
  • 現金、クレジットカード、電子マネー、QRコードなど
• 通知手段の切り替え
  • メール、SMS、プッシュ通知、Slack通知など
• ルート検索アルゴリズムの切り替え
  • 最短距離、最速時間、有料道路回避、徒歩優先など（カーナビ・地図アプリ）
• 認証方式の変更
  • パスワード認証、指紋認証、顔認証、OTPなど

　これらはすべて、Strategyパターンを使うことで処理の差し替えや拡張が簡単になります。

Strategyパターンの構成要素

　Strategyパターンの構成要素は主に３つあり、とてもにシンプルなパターンです。

Strategyパターンの書き方

　実際に日常生活の例の「支払い方法の切り替え」例でStrategyパターンを実装します。

❌ Strategyを使わない場合

　まずStrategyパターンを利用しない方法で「支払い方法の切り替え」の仕組みを実装するとどのようになるでしょうか。おそらく下記のように利用側で支払い方法と金額を指定して、指定された支払い方法によって処理をif文やswitch文で切り替えることになるかと思います。

public enum PaymentMethod {
    CASH, // 現金
    CREDIT_CARD, // クレジットカード
    QR_CODE // QRコード
}

public class NoStrategyPaymentService {
    public void pay(PaymentMethod method, int amount) {
        if (method == PaymentMethod.CASH) {
            System.out.println("現金で" + amount + "円を支払いました。");
        } else if (method == PaymentMethod.CREDIT_CARD) {
            System.out.println("クレジットカードで" + amount + "円を支払いました。");
        } else if (method == PaymentMethod.QR_CODE) {
            System.out.println("QRコードで" + amount + "円を支払いました。");
        } else {
            System.out.println("未対応の支払い方法です。");
        }
        // 支払い処理を追加するにはif文を追加する必要がある。
    }

    public static void main(String[] args) {
        NoStrategyPaymentService service = new NoStrategyPaymentService();

        service.pay(PaymentMethod.CASH, 1000);
        service.pay(PaymentMethod.CREDIT_CARD, 2000);
        service.pay(PaymentMethod.QR_CODE, 1500);
    }
}

　この実装でも正常に動作します。ではなぜ問題があるのでしょうか。　このコードの問題点を下記の表にまとめます。

○ Strategyを使う場合

　上記の問題点を解決できるのがStrategyパターンです。では実際にStrategyパターンを利用して「支払い方法の切り替え」の仕組みを実装していきます。

　まずはStrategy（戦略インタフェース）を定義します。

public interface PaymentStrategy {
    void pay(int amount);
}

　「お金を支払う」という動作（ゴール）はどの支払い方法も同じです。そのため、戦略インターフェースでは、全ての支払い方法で共通の動作（pay()メソッド）を定義します。

　次にこのPaymentStrategyを実装して、いくつかの支払い方法の戦略を作ります。

public class CashPayment implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("現金決済： " + amount + "円");
    }
}

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("クレジットカード決済： " + amount + "円");
    }
}

public class QRCodePayment implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("QRコード決済： " + amount + "円");
    }
}

　全てPaymentStrategyを実装しています。本記事ではStrategyパターンの紹介のため、詳細な処理は行わずそれぞれの支払い方法の標準出力を行なっています。本来であれば、ここに支払い方法の具体的な処理を記述します。

　次にこのStrategyを利用する、Contextに該当するクラス（PaymentContext）を作ります。

public class PaymentContext {
    private PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    public void executePayment(int amount) {
        paymentStrategy.pay(amount);
    }
}

　このクラスはPaymentStrategyをフィールドに持っており、このフィールドに入るインスタンスを切り替えていくことで、支払い方法を切り替えることができるようになっています。実際に支払い処理をするのはStrategyインターフェースで定義されているpay()メソッドをexecutePayment()メソッド内で実行します。

　最後に、このPaymentContextとPaymentStrategyを使って支払い方法を切り替えてログを出してみます。

public class StrategySample {
    public static void main(String[] args) {
        
        PaymentContext context = new PaymentContext();
        
        context.setPaymentStrategy(new CreditCardPayment());
        context.executePayment(1000); // クレジットカード決済： 1000円

        context.setPaymentStrategy(new CashPayment());
        context.executePayment(2000); // 現金決済： 2000円

        context.setPaymentStrategy(new QRCodePayment());
        context.executePayment(3000); // QRコード決済： 3000円
    }
}

>> 実行結果
クレジットカード決済： 1000円
現金決済： 2000円
QRコード決済： 3000円

　これでStrategyを利用して、「支払い方法の切り替え」の仕組みを実装することができました。if文やSwitch文を利用していないため非常に拡張しやすい構造となっています。

StrategyパターンとStateパターンの違い

　余談ですが、このStrategyパターンはStateパターンと構造が大変よく似ています。インターフェースを実装したクラスを切り替えることで処理を切り替える部分はほとんど同じです。ただこの２つのパターンには明確な違いがあります。

これらの違いから、利用者が処理方法を選びたい（処理手段の切り替え）場合はStrategyパターンを、状態の変化によって動作を自律的に変えたい（内部ロジック）場合はStateパターンを選択するようにしましょう。

　Stateパターンの説明は下記の記事で紹介しています。ぜひ参考にしてみてください。

メリットとデメリット

メリット

デメリット

　Strategyパターンには上記のメリットとデメリットがあります。これらのメリットとデメリットから、Strategyパターンが有効に働くシチュエーションには下記のような場合があります。

• 同じ目的に対して複数の処理方法（戦略）が存在し、切り替えたいとき
  • 例：支払い方法、通知手段、圧縮方式など
• 処理ごとの実装を分離・拡張しやすくしたいとき
  • 例：新しい戦略を追加したい、変更を既存コードに影響させたくない
• 処理ごとにテストや再利用が必要なとき
  • 例：各処理を個別にテストしたい、他の場所でも使い回したい

まとめ

　Strategyパターンは、同じ目的に対して異なる処理方法（戦略）を柔軟に切り替えるための設計手法です。支払い方法や通知手段など、処理の「過程」が複数ある場面に適しています。

　処理をクラスごとに分離することで、拡張性・再利用性・テストのしやすさが向上します。ただし、小規模なケースでは設計が複雑になるため、使いどころを見極めることが大切です。

　本記事で利用したサンプルケースのクラス図は下記になります。

　最後に「Strategy」パターンとは「処理方法（戦略）をオブジェクトとして分離し、実行時に自由に切り替えられるパターン」です。うまく使っていきましょう。

　本記事で利用したコードは下記のgit上で公開しております。

https://github.com/tamotech1028/strategy

デザインパターン講座　目次

第１章　導入

• 1.1. デザインパターンって何？
• 1.2. 実務で本当に使うJavaデザインパターンはどれ？

第２章　オブジェクトの「生成」に関するパターン

• 2.1. Abstract Factory
• 2.2. Builder
• 2.3. Factory Method
• 2.4. Prototype
• 2.5. Singleton

第３章　プログラムの「構造」に関するパターン

• 3.1. Adapter
• 3.2. Bridge
• 3.3. Composite
• 3.4. Decorator(Filter)
• 3.5. Facade
• 3.6. Flyweight
• 3.7. Proxy

第４章　オブジェクトの「振る舞い」に関するパターン

• 4.1. Chain of Responsibility
• 4.2. Command
• 4.3. Interpreter
• 4.4. Iterator
• 4.5. Mediator
• 4.6. Memento
• 4.7. Observer
• 4.8. State
• 4.9. Strategy
• 4.10. Template Method
• 4.11. Visitor