【ITニュース解説】Strategy Pattern in Java

ソフトウェア開発の現場では、同じような処理に見えても、特定の状況に応じて内部の動作を切り替えたい場面が頻繁に現れる。たとえば、オンラインショップで顧客が商品を購入する際、支払い方法にはクレジットカード、PayPal、銀行振込など、さまざまな選択肢がある。システムはこれら異なる支払い方法に応じて、それぞれに特化した処理を実行する必要がある。システムエンジニアを目指す初心者が最初に思いつくアプローチとして、支払い方法の種類ごとにif-else文を多用して、それぞれの処理ロジックを記述することが考えられる。

しかし、このようなif-else文が連なったコードにはいくつかの問題点が存在する。まず、支払い方法の種類が増えるたびにif-elseの条件分岐が際限なく長くなり、コード全体の可読性が著しく低下する。また、新しい支払い方法を追加する際には、既存の支払い処理ロジック全体を修正する必要が生じやすく、誤って他の支払い方法の処理に影響を与えてしまうリスクが高まる。このようなコードは「変更に弱い」と言われ、保守や拡張に多大なコストがかかることになる。ソフトウェアは常に変化する要件に対応する必要があるため、このような脆弱な設計は避けたい。

Strategy Pattern（戦略パターン）は、このような問題を解決するために考案されたデザインパターンの一つである。このパターンの核心は、特定のタスクを実行するためのアルゴリズムや処理手順（戦略）を、それを実際に利用する側（コンテキスト）から完全に分離し、独立したオブジェクトとしてカプセル化することにある。これにより、利用する側はどの具体的な戦略が使われるかを知ることなく、共通のインターフェースを通じて戦略を呼び出すだけでよいという柔軟な関係が構築される。

Strategy PatternをJavaで実現する基本的な考え方は次のようになる。まず、すべての戦略に共通の操作を定義する「インターフェース」または「抽象クラス」を作成する。例えば、支払い処理であればPaymentStrategyというインターフェースを定義し、その中にprocessPayment(amount)のような共通のメソッドを宣言する。次に、このPaymentStrategyインターフェースを実装する形で、具体的な支払い方法ごとのクラスをそれぞれ独立して作成する。例えば、CreditCardPaymentクラス、PayPalPaymentクラス、BankTransferPaymentクラスなどがこれに該当する。それぞれのクラスは、processPaymentメソッド内で、その支払い方法に特化した固有のロジックを記述する。

そして、実際に支払い処理を実行する主体となるクラス、例えばShoppingCartやOrderProcessorといったクラスがコンテキストとなる。このコンテキストクラスは、特定の支払い方法に直接依存するのではなく、PaymentStrategyインターフェース型のインスタンスを内部に保持する。支払いを行う際には、コンテキストクラスに適切なPaymentStrategyのインスタンスを渡して設定するか、または支払いメソッドの引数として渡す。コンテキストは、保持しているPaymentStrategyインターフェースのprocessPaymentメソッドを呼び出すだけでよく、具体的なクレジットカード決済の詳細やPayPal決済の詳細を知る必要はない。このようにして、コンテキストは「どのような支払い方法で処理するか」という詳細な情報から解放され、「支払い処理を実行する」という上位の責務に集中できる。

Strategy Patternをシステムに適用することで、多くの利点が得られる。最も顕著なのは、システムの柔軟性が大幅に向上することである。実行時に動的に戦略を切り替えることが可能になるため、ユーザーの選択に応じて瞬時に適切な処理ロジックを適用できる。たとえば、ユーザーがクレジットカードを選択すればクレジットカードの戦略が、PayPalを選択すればPayPalの戦略が、シームレスに適用される。

次に、コードの保守性が高まる。各戦略が独立したクラスとして存在するため、ある支払い方法のロジックを変更する必要が生じても、その変更が他の支払い方法やコンテキストクラスに影響を与えるリスクがほとんどない。これにより、変更箇所が局所化され、システムの安定性を保ちながら機能改善やバグ修正を行える。

さらに、システムの拡張性が向上する。新しい支払い方法を追加する場合でも、既存のPaymentStrategyインターフェースを実装する新しいクラスを一つ作成するだけでよく、OrderProcessorのようなコンテキストクラスのコードに修正を加える必要がない。これは、ソフトウェア設計における「オープン・クローズドの原則」（既存のコードは修正に対して閉じていて、新しい機能の追加に対しては開かれているべき）に従うものであり、システムの寿命を延ばす上で非常に重要な設計原則である。複雑なif-else分岐が解消されるため、コードの可読性も向上し、それぞれのクラスが担当する責務が明確になる。また、各戦略クラスは独立しているため、それぞれを単体でテストすることが容易になり、全体的なテストコストの削減にも寄与する。

Strategy Patternは、支払い方法の選択だけでなく、データのソートアルゴリズムの切り替え、ファイルの出力形式の選択、異なるデータ検証ルールなど、状況に応じて複数の異なるアルゴリズムや振る舞いを柔軟に切り替えたいあらゆる場面で適用できる。このパターンを理解し活用することは、変化する要件に対応できる柔軟で保守性の高いシステムを構築するために、システムエンジニアが身につけるべき重要なスキルのひとつである。