Strategyパターンとは何か？ストラテジーパターンの定義と概要を事例を交えてわかりやすく徹底解説

Strategyパターンとは何か？ストラテジーパターンの定義と概要を事例を交えてわかりやすく徹底解説

「Strategy（ストラテジー）」パターンとは、プログラムの振る舞いに関するデザインパターンの一種です。その名の通り「戦略」を意味し、アルゴリズム（処理方法）をオブジェクトとして独立させ、必要に応じて差し替えられるようにする設計手法を指します。簡単に言えば、処理の具体的な実装をそれぞれ別クラスに切り出し、実行時に自由に選択・変更できるようにすることで、柔軟で拡張性の高いコードを実現します。

Strategyパターンでは、ある目的（問題を解決すること）は共通でも、その達成手段（アルゴリズム）が複数存在する場合に威力を発揮します。例えば、同じ計算や処理でも入力データや要件に応じて異なる手法を使いたい場面があります。そのような場面でStrategyパターンを用いると、条件分岐に頼らずに処理手段を差し替え可能となり、コードのメンテナンス性が向上します。

Strategyパターンの定義：アルゴリズムを戦略として分離し実行時に自由に切り替え可能にするデザインパターンの概要

Strategyパターンの定義を改めて整理すると、「アルゴリズム（戦略）をクラスとして分離し、実行時に柔軟に切り替えられるようにする」という点にあります。具体的には、処理の手段を抽象的なインタフェース（または親クラス）で定義し、各手段ごとにそのインタフェースを実装した具体クラス（戦略クラス）を用意します。そして、利用側のクラス（コンテキスト）が実行時に適切な戦略クラスを選択して利用することで、同じ目的の処理であっても内部のアルゴリズムを差し替え可能にします。

このデザインパターンは、GoF（Gang of Four）のデザインパターンの中でも振る舞いに関するパターンに分類されます。Strategyパターンにより、アルゴリズムの選択ロジックを汎用化・オブジェクト化することで、if-elseのような条件分岐を減らし、コードの柔軟性を高めることができます。

Strategyパターンの目的と特徴とは？アルゴリズムの戦略的分離で柔軟な設計と拡張性を実現するデザインパターン

ここではStrategyパターンの狙い（目的）と、その設計上の特徴について解説します。Strategyパターンを採用することで得られる効果や、他のアプローチと異なるポイントを見ていきましょう。

Strategyパターンの目的：コードの柔軟性・拡張性・保守性を高める設計上の狙いと効果について解説

Strategyパターンの主な目的は、コードの柔軟性・拡張性・保守性を向上させることにあります。具体的には、アルゴリズムを個別のクラスに分離することで、新しいアルゴリズム（戦略）の追加や変更が容易になります。これにより「オープン/クローズドの原則 (OCP)」に従った設計が可能になり、既存のコードに手を加えることなく機能拡張できます。

また、各戦略が独立したクラスになっているため、一つのクラスやメソッドが過剰な責任を持たずに済み、「単一責任の原則 (SRP)」を守ることにもつながります。結果としてコードの保守性が高まり、変更に強い構造になります。Strategyパターンの導入によって、処理ロジックを柔軟に差し替えつつ、将来的な拡張や変更にも対応しやすいコード基盤を築くことができるのです。

加えて、アルゴリズムごとにクラスが分かれていることで、特定の戦略（アルゴリズム）の再利用や単体テストが容易になるという効果もあります。例えば、新しいアルゴリズムを追加する際には既存のコードを変更せず新たなクラスを作成するだけで済み、他の部分への影響を最小限に抑えられます。このように、Strategyパターンの目的はコードを柔軟かつ拡張可能に保つことで、開発や保守の効率を上げることにあります。

Strategyパターンの特徴：アルゴリズムをカプセル化し実行時に切り替え可能にする柔軟なデザイン手法

Strategyパターンの大きな特徴は、「アルゴリズムのカプセル化」と「実行時の切り替え」が可能な点です。アルゴリズムをカプセル化するとは、処理の詳細（戦略）をそれぞれ独立したクラス（ConcreteStrategy）に封じ込めることです。これにより、各アルゴリズムは互いに干渉せず独立に動作します。

コンテキスト（利用側のクラス）は抽象的なStrategyインタフェースだけを意識して動作し、具体的な処理内容は外部から与えられる戦略オブジェクトに委ねます。そのため、実行時に戦略オブジェクトを差し替えることで、プログラムの動作を動的に切り替えることができます。例えば、同じ計算処理でも「高速だがメモリ使用量が多いアルゴリズム」から「低速だがメモリ節約なアルゴリズム」に実行中にスイッチする、といった柔軟な動作が可能です。

また、Strategyパターンでは共通のStrategyインタフェースを用いるため、コンテキストはどの戦略を使っているかを意識せずに同じ手順で処理を呼び出せます。これは「アルゴリズムの交換可能性」を高め、コード上もシンプルなインタフェース呼び出しで処理が完結するという利点につながります。まとめると、「アルゴリズムを入れ替え可能な部品として扱える」のがStrategyパターンの特徴であり、これによってシステム全体の柔軟性が飛躍的に向上します。

なぜStrategyパターンが必要なのか？複雑な条件分岐の解消とOCP/SRP実現による保守性向上

では、そもそもなぜStrategyパターンが必要とされるのでしょうか。その理由は、Strategyパターンを使わない従来の実装方法ではコードが複雑化し、保守が困難になる問題があるからです。具体的に、複数のアルゴリズムを切り替える処理を直接書く場合、しばしば巨大な条件分岐（if-else文やswitch文）が発生します。その結果、コードの見通しが悪くなり、修正や拡張のたびにその条件分岐部分を変更する必要が生じます。

従来アプローチの問題点：if-elseによるアルゴリズム分岐が増大しOCP/SRPに反する設計に陥る

Strategyパターンを適用しない場合の問題点を整理すると、以下のような設計上の課題があります。

• 条件分岐の肥大化 – アルゴリズムの選択をif-elseやswitchで記述すると、戦略（処理手段）の種類が増えるごとに分岐が増え、コードが肥大化して読みづらくなります。
• OCP違反 – 新しいアルゴリズムを追加する際に既存の条件分岐コードを修正しなければならず、コードが「拡張に対して閉じていない」状態になります。これはオープン/クローズドの原則に反し、変更のたびに既存コードに手を加えるためバグの誘発や影響範囲の増大につながります。
• SRP違反 – 一つのクラスやメソッドが複数の処理手段のロジックを担うため、責務が過剰に集中します。その結果、コードの再利用性が低下し、特定の処理だけを個別にテストすることも難しくなります。
• 保守性・可読性の低下 – 条件分岐だらけのコードは修正箇所の特定が難しく、処理の流れも追いにくくなります。アルゴリズムを追加・変更するたびに分岐を追加するような実装では、将来的な保守負担が大きくなります。

以上のように、Strategyパターンを使わずに複数の処理を条件分岐で切り替える設計では、ソフトウェア設計原則への違反やコードの肥大化による問題が生じがちです。Strategyパターンはこれらの課題を解決するために必要となるアプローチなのです。

Strategyパターンの構造：Strategy(戦略インタフェース)・ConcreteStrategy(具体戦略)・Context(利用クラス)各役割

Strategyパターンのクラス構造は比較的シンプルで、主に以下の3つの役割から成ります。それぞれの役割と責務を理解することで、パターン全体の動きを把握できます。

Strategy（戦略インタフェース）の役割：共通インタフェースを定義してアルゴリズムの枠組みを提供する

Strategy（戦略インタフェース）は、戦略となるアルゴリズムの共通のインタフェースを定義する役割を担います。これは抽象クラスやインターフェースとして実装され、戦略ごとに共通となるメソッド（操作）を宣言します。コンテキスト（後述）はこのStrategyインタフェースに依存し、具体的な戦略の中身については知らないまま利用することができます。

例えば支払い処理の例では、PaymentStrategyというインタフェースを定義し、そこにpay(int amount)のような共通メソッドを宣言します。どの支払い方法であっても「支払う」という操作自体は共通なので、その操作の枠組み（シグネチャ）をStrategyインタフェースで提供するわけです。これにより、コンテキストは具体的な支払い方法によらずPaymentStrategyのpayメソッドを呼び出すだけで処理を実行できるようになります。

ConcreteStrategy（具体戦略）の役割：Strategyインタフェースを実装して個別のアルゴリズムを提供する

ConcreteStrategy（具体戦略）は、Strategyインタフェースを実装した具体的なアルゴリズムクラスです。各ConcreteStrategyがそれぞれ異なる処理内容（戦略）を提供します。例えば、支払い処理の例ではCashPaymentクラスやCreditCardPaymentクラスがConcreteStrategyにあたり、それぞれPaymentStrategyインタフェースのpayメソッドを実装して「現金で支払う」「カードで支払う」といった具体的な処理を記述します。

ConcreteStrategyはStrategyインタフェースが定めた契約（メソッド仕様）に従って実装するため、コンテキストから見るとどのConcreteStrategyを使っていても同じメソッド（例：pay()）を呼び出すだけで済みます。新しいConcreteStrategyクラスを追加すれば、それが新たなアルゴリズムの追加となります。これによってStrategyパターンの拡張性が実現されます。ConcreteStrategy間で共通する処理がある場合、それをStrategyのデフォルト実装に入れるか、もしくはヘルパークラスで共有することで重複を避けることも可能です。

Context（利用クラス）の役割：Strategyを利用してアルゴリズムの実行と動的な切り替えを管理する

Context（コンテキスト、利用クラス）は、Strategyパターンを利用するクラスで、Strategyインタフェースを保持し、必要に応じて具体戦略を切り替えながら処理を実行します。Contextは内部にStrategyインタフェース型のフィールドを持ち（あるいはメソッド呼び出し時に戦略を受け取り）、そのメソッドを呼ぶことで実際の処理を委譲します。

コンテキストは具体的なアルゴリズムの詳細には立ち入りません。例えば、コンテキストがstrategy.execute()と呼び出すと、実際には現在設定されているConcreteStrategyのexecuteメソッドが動作します。Contextは適切なタイミングで戦略を変更するためのメソッド（セッターなど）を備えている場合もあり、これにより実行中に戦略を動的に切り替えることが可能です。

具体例として、支払い処理コンテキストPaymentServiceがPaymentStrategyをフィールドに持ち、setStrategy()メソッドで支払い方法戦略を差し替えられる設計を考えます。クライアントコードがコンテキストに対して「今はクレジットカード戦略を使え」と設定し、processPayment()を呼ぶと、内部で設定済みの戦略オブジェクト（この場合クレジットカード戦略）のpay()が呼ばれます。こうした構造により、Contextは戦略の切り替えと実行の管理役を果たし、アルゴリズムの具体的内容から独立した形で振る舞いを制御できます。

Strategyパターンのメリット：保守性・拡張性・再利用性の向上と条件分岐削減などの利点を紹介

Strategyパターンを導入することで、コードの設計面で様々なメリットが得られます。主な利点を整理すると以下のとおりです。

• 処理の動的な切り替えが容易 – 実行時にアルゴリズム（戦略）を差し替えできるため、if-else文を多用せずとも柔軟に処理内容を変更できます。条件分岐の削減によりコードがシンプルになり、可読性も向上します。
• 拡張が容易（OCPの遵守） – 新しい戦略（アルゴリズム）を追加する場合でも、既存のコンテキストや他の戦略クラスを修正せずに済みます。これはオープン/クローズドの原則に適った設計であり、追加要件への対応時にバグを混入しにくくなります。
• コードの再利用・テスト性向上 – 戦略ごとにクラスが分かれているため、それぞれのアルゴリズムをモジュール化できます。共通のインタフェースで呼び出せるので、他のコンテキストでも戦略クラスを再利用可能です。また個々の戦略クラス単位で振る舞いをテストできるため、単体テストが容易になります。
• 単一責任の徹底 – 戦略クラスごとに扱う処理が一つに絞られるため、各クラスが担当する責務が明確になります（SRPの遵守）。結果として各クラスはシンプルになり、保守・管理がしやすくなります。

このように、Strategyパターンは柔軟性と拡張性を高め、設計原則に沿ったコードを書く上で強力なツールとなります。特に大規模なシステムや要件変更が頻繁な開発において、そのメリットが顕著に現れます。

Strategyパターンのデメリット・注意点：クラス数増加による冗長化や戦略選択の困難さなど、小規模プロジェクトでは過剰設計になる点に注意

便利なStrategyパターンですが、一方で注意すべきデメリットやトレードオフも存在します。導入にあたって留意すべき点を挙げます。

• クラス数の増加による冗長化 – 戦略ごとに別クラスを定義するため、扱うアルゴリズムの種類が多い場合はクラスの数が増えてコード構成が煩雑になる可能性があります。処理内容がごく簡単な場合や戦略のバリエーションが少ない場合、かえって過剰設計となり、小規模プロジェクトでは冗長に感じられることがあります。
• 戦略の選択を利用者が理解する必要 – Strategyパターンでは、どの戦略を使うかを決めるのは多くの場合コンテキストの利用側（クライアント）です。そのため、利用者は各戦略の違いを理解して適切に選択しなければなりません。誤った戦略を選ぶと期待した結果が得られず、使い方を誤るリスクがあります。
• 共通インタフェースによる制約 – すべての戦略クラスが同じインタフェース（メソッド群）に従う必要があるため、戦略間でインタフェースに差異があると柔軟性が下がります。無理に共通のメソッドシグネチャに当てはめると各戦略の実装が複雑になる場合もあります。

以上の点から、Strategyパターンは強力な反面、状況によっては「クラスを分けすぎてしまう」「利用者に戦略選択の負担がかかる」といった弊害もありえます。そのため、特に規模の小さい開発ではシンプルなif文で十分かどうか検討し、パターン適用が本当に有効かを判断することが重要です。適材適所でStrategyパターンを使うことで、デメリットを最小限に抑えながらメリットを享受できるでしょう。

Strategyパターンの具体例：支払い方法・通知手段・ソートアルゴリズムでの活用シナリオ

ここでは、Strategyパターンが現実の問題でどのように役立つかを具体例で示します。支払い方法の切り替え、通知手段の選択、ソートアルゴリズムの選択など、複数の戦略パターンが存在する典型的なシナリオを見てみましょう。

支払い方法の例：現金・カード・電子マネーなど決済手段をStrategyで柔軟に切り替え可能な設計例を紹介

ECサイトやPOSシステムでは、支払い方法として現金、クレジットカード、電子マネー、QRコード決済など複数の手段を提供する場合があります。通常であれば支払い処理のコードに条件分岐を設け、選択された支払い方法に応じて処理を切り替えますが、Strategyパターンを使うことでこの部分を洗練できます。

まず、共通のインタフェースとしてPaymentStrategy（支払い戦略）を定義し、pay(int amount)というメソッドを宣言します。次に、CashPayment（現金戦略）、CreditCardPayment（カード戦略）、QrCodePayment（QR決済戦略）などのConcreteStrategyクラスを用意し、それぞれpayメソッド内で異なる決済処理を実装します。コンテキストとなる支払い処理クラスは、現在選択されているPaymentStrategyを保持し、そのpay()を呼び出すことで支払い処理を実行します。

こうすることで、新しい決済手段（例えばポイント払い）を追加したい場合でも、新たなクラスを実装しコンテキストに戦略としてセットするだけで対応できます。if-elseを修正する必要がないため既存コードへの影響はなく、OCPに沿った拡張が可能です。またユーザの選択によって容易に支払いロジックを切り替えられるため、柔軟な機能提供が実現できます。

通知手段の例：メール・SMS・プッシュ通知など複数チャネルをStrategyで使い分け可能な設計例を紹介

ユーザーへの通知機能を考えると、通知手段にはメール、SMS、プッシュ通知、Slack連携など様々なチャネルがあります。システムによってはユーザーの希望や状況に応じて通知方法を切り替えたいケースもあるでしょう。Strategyパターンを適用すれば、このような通知チャネルの切り替えもスムーズに行えます。

通知処理の共通インタフェースとしてNotifier（通知戦略）を定義し、notify(String message)のようなメソッドを用意します。ConcreteStrategyとしてEmailNotifier（メール通知）、SmsNotifier（SMS通知）、PushNotifier（プッシュ通知）等のクラスを実装し、それぞれのnotifyメソッド内で対応するチャネルへメッセージを送る処理を書きます。コンテキスト側では、例えばユーザー設定に応じて適切なNotifier戦略を選択し、notify()を呼び出すだけで通知が送信されます。

この設計により、通知手段を追加・変更する場合でも他の部分に影響を与えずに拡張が可能です。ユーザーごとに通知チャネルを切り替える場合でも、Strategyオブジェクトを差し替えるだけで実現できます。条件分岐を散りばめることなく多彩な通知方法を管理できるのは、Strategyパターンの実例として非常にわかりやすいケースです。

ソートアルゴリズムの例：Strategyパターンで並べ替えアルゴリズムを動的に選択可能な設計例を紹介

データの並べ替え（ソート）において、データ量や特性に応じて異なるアルゴリズムを使いたい場面があります。例えば、小規模データではシンプルな挿入ソート、大規模データではクイックソートやマージソートなどを選択すると効率が良い場合があります。このような異なるソートアルゴリズムの切り替えにもStrategyパターンが利用できます。

共通のインタフェースとしてSortStrategyを定め、sort(List list)といったメソッドを宣言します（ジェネリクスを用いて任意の型Tのリストをソートできるように設計）。ConcreteStrategyとしてQuickSortStrategy、MergeSortStrategy、InsertionSortStrategyなどを実装し、それぞれのsortメソッド内で対応するアルゴリズムを用いたソート処理を実装します。コンテキスト（例えばSortProcessorクラス）は、与えられたデータの状況に応じて最適なSortStrategyを選択し、sort()を呼び出すだけで並べ替えを実行します。

これにより、プログラムの実行時にデータ量などを判断してアルゴリズムを動的に変更するといった高度な挙動も可能になります。Strategyパターンを使わない場合、もし逐次条件分岐でソート手法を選んでいたなら、アルゴリズムの追加や調整時にバグのリスクが伴いますが、Strategyパターンならクラスの追加・差し替えで対応できるため安全です。このように、アルゴリズムそのものを交換可能な部品として扱えるのがStrategyパターンの強みと言えます。

Strategyパターンの実装例：Javaでの解説・Goで学ぶ実践例・TypeScriptでの実装方法

最後に、Strategyパターンの具体的な実装方法をいくつかのプログラミング言語で見てみましょう。Javaのようなオブジェクト指向言語では典型的な実装が可能ですし、Goのような言語でもインタフェースや関数を使ってStrategyパターンを表現できます。TypeScriptではクラスとインターフェースを用いた実装ができます。

JavaでのStrategyパターン実装例：インタフェースとクラスを用いてアルゴリズムを柔軟に切り替える実装方法

JavaではStrategyパターンはインタフェースとクラスのポリモーフィズムを活用して実装します。典型的な例として、支払い方法の切替をStrategyパターンで表現してみます。

interface PaymentStrategy { void pay(int amount); }
// Concrete Strategy: 現金支払い class CashPayment implements PaymentStrategy { @Override public void pay(int amount) { System.out.println(amount + "円を現金で支払いました。"); } }
// Concrete Strategy: カード支払い class CreditCardPayment implements PaymentStrategy { @Override public void pay(int amount) { System.out.println(amount + "円をクレジットカードで支払いました。"); } }
// Context: 支払い処理を行うクラス class PaymentService { private PaymentStrategy strategy; public void setStrategy(PaymentStrategy strategy) { this.strategy = strategy; } public void executePayment(int amount) { strategy.pay(amount); // 現在設定されている戦略で支払いを実行 } }
// 利用シーン: 戦略の切り替えと実行 PaymentService service = new PaymentService(); service.setStrategy(new CashPayment()); service.executePayment(1000); // 現金で1000円支払い service.setStrategy(new CreditCardPayment()); service.executePayment(2000); // クレジットカードで2000円支払い 

上記のコードでは、PaymentStrategyインタフェースが戦略（アルゴリズム）の共通のメソッドpay()を定義しています。現金やクレジットカードといった具体的手段はそれぞれPaymentStrategyを実装するクラスとして定義され、実際の処理内容（標準出力への表示で代用）を記述しています。PaymentServiceクラス（コンテキスト）はPaymentStrategyを保持し、executePaymentメソッドで戦略オブジェクトのpay()を呼び出すことで支払い処理を委譲しています。

この設計により、PaymentServiceは支払い方法の違いを意識せず動作できます。新しい支払い手段を追加したい場合はPaymentStrategyを実装したクラスを作成するだけでよく、PaymentServiceのコードには変更不要です。Javaのインタフェースと動的バインディング（多態性）を活用することで、Strategyパターンのメリットを活かした実装が実現できます。

GoでのStrategyパターン実装例：関数とインタフェースを活用した戦略アルゴリズムの柔軟な切り替えを実現する仕組み

Go言語はオブジェクト指向の継承構造を持ちませんが、インタフェースと関数値を活用してStrategyパターンに相当する設計を行うことができます。Goでの実装方法を、例として数値演算の戦略で考えてみましょう。

まず、インタフェースによる方法です。たとえば、何らかの計算を行う戦略を表すOperationインタフェースを定義し、Execute(a int, b int) intのようなメソッドを宣言します。ConcreteStrategyに相当する構造体型（例えばAddOperationやMultiplyOperation）を定義し、このインタフェースを実装するメソッドExecuteを各々実装します。コンテキストとなる構造体はop Operationのフィールドを持ち、SetOperation(op Operation)で戦略を差し替え、DoExecute(a, b)で内部のop.Execute(a, b)を呼ぶようにします。

package main
import "fmt"
// Strategy interface type Operation interface { Execute(a, b int) int }
// Concrete Strategies type AddOperation struct{} func (AddOperation) Execute(a, b int) int { return a + b }
type MultiplyOperation struct{} func (MultiplyOperation) Execute(a, b int) int { return a * b }
// Context type Calculator struct { op Operation } func (c Calculator) SetOperation(op Operation) { c.op = op } func (c Calculator) Calculate(a, b int) int { return c.op.Execute(a, b) }
func main() { calc := Calculator{} calc.SetOperation(AddOperation{}) fmt.Println(calc.Calculate(3, 4)) // 出力: 7 （加算） calc.SetOperation(MultiplyOperation{}) fmt.Println(calc.Calculate(3, 4)) // 出力: 12 （乗算） } 

上記のGoコードでは、Operationインタフェースが戦略の共通メソッドExecuteを定義し、AddOperationとMultiplyOperationがそれぞれ加算と乗算のアルゴリズムを提供しています。Calculator（コンテキスト）がOperationを保持し、実行時に戦略を差し替えながらCalculateを呼ぶことで、柔軟にアルゴリズムを切り替えています。

さらに、Goならではの方法として、関数そのものを戦略として扱うやり方もあります。Goではファーストクラス関数（関数リテラルや関数値）を変数に代入できるため、インタフェースを使わずに関数型を定義することで戦略を表現できます。例えば、type SortFunc func([]int)のように関数型を定義し、QuickSortやMergeSort関数をその型に適合させれば、変数に代入して戦略のように切り替えて呼び出すことが可能です。これはStrategyパターンの関数型プログラミング的な応用と言えるでしょう。

Goではコードがシンプルな分、設計パターンを厳密に意識せずとも実現できるケースがあります。しかし上記のようにインタフェースや関数を組み合わせることで、Strategyパターンと同様のメリット（動的な挙動切替、OCPへの準拠など）を享受できます。

TypeScriptでのStrategyパターン実装例：クラスとインタフェースで柔軟な戦略切り替えを実現する実装方法

TypeScriptはJavaScriptに型付けとクラスの概念を導入した言語であり、Strategyパターンもクラスとインタフェースを使って実装できます。例として、通知戦略の切り替えをTypeScriptで表現してみます。

// Strategy interface interface Notifier { notify(message: string): void; }
// Concrete Strategy: Email通知 class EmailNotifier implements Notifier { notify(message: string): void { console.log(メール送信: ${message}); } }
// Concrete Strategy: SMS通知 class SMSNotifier implements Notifier { notify(message: string): void { console.log(SMS送信: ${message}); } }
// Concrete Strategy: Push通知 class PushNotifier implements Notifier { notify(message: string): void { console.log(プッシュ通知: ${message}); } }
// Context class NotificationService { private notifier: Notifier; constructor(notifier: Notifier) { this.notifier = notifier; } setNotifier(notifier: Notifier): void { this.notifier = notifier; } send(msg: string): void { this.notifier.notify(msg); } }
// 利用例 const service = new NotificationService(new EmailNotifier()); service.send("テストメッセージ"); // Emailで送信 service.setNotifier(new SMSNotifier()); service.send("確認コード:1234"); // SMSで送信 

このTypeScriptコードでは、Notifierインタフェースが通知戦略の共通メソッドnotify()を定義しています。EmailNotifierやSMSNotifierなど各ConcreteStrategyクラスがそれぞれの方法でメッセージを通知する処理を実装します。NotificationService（コンテキスト）はNotifierを保持し、send()内で現在設定されている戦略のnotify()を呼び出します。

TypeScriptではインタフェースとクラスを用いることで、Javaや他のOOP言語と同様にStrategyパターンを実現できます。加えて、JavaScript由来の柔軟さを活かし、戦略として関数（コールバック）を受け取るようにすることも可能です（例えばconstructor(private notifyFunc: (msg: string) => void)のように関数を渡し、sendでその関数を呼ぶ実装など）。このように、TypeScriptでも状況に応じてStrategyパターンを適用することで、コードの拡張性やテスト容易性を高めることができます。

Strategyパターンと他パターンの違い：StateパターンやTemplate Methodパターンとの役割や適用場面の比較

Strategyパターンは他のデザインパターンと構造が似ているため混同されやすい場合があります。特に、状態によって振る舞いを変化させるStateパターンや、処理の一部をサブクラスに任せるTemplate Methodパターンとは一見すると類似していますが、目的と適用場面が異なります。それぞれの違いを比較してみましょう。

Stateパターンとの違い：状態の変化による振る舞い変更と戦略アルゴリズム切り替えの目的の違いを解説

StateパターンとStrategyパターンは、クラス構造がよく似ています。どちらもコンテキストと共通インタフェース、複数の具体クラスという構成を取り、実行時にオブジェクトを差し替える点は共通です。しかし、その目的と適用シナリオには明確な違いがあります。

Stateパターンは、あるオブジェクトの内部状態に応じて振る舞いを変えることを目的としています。コンテキストの内部に現在の状態（ConcreteState）が保持されており、状態が変化する（イベントが発生する）とコンテキストが別のConcreteStateに遷移します。各ConcreteStateは次に遷移すべき状態を決定したり、コンテキストに働きかけて状態変更を引き起こすことがあります。つまり、Stateパターンでは状態遷移のロジックが組み込まれており、コンテキスト自身がその状態変化を管理します。

一方、Strategyパターンは純粋にアルゴリズムの選択肢を切り替えることに焦点があります。コンテキストが保持する戦略（ConcreteStrategy）は、状態パターンのように内部で次の戦略に勝手に切り替わることはありません。どの戦略を使うかはコンテキストの外部から設定されるか、あるいはコンテキストが能動的に切り替えメソッドを提供しているだけです。例えば、Stateパターンの典型例は「オブジェクトが現在どの状態（例：接続済みか切断状態か）かによって異なる振る舞いをとる」場面ですが、Strategyパターンは「やり方の異なる複数のアルゴリズムを用途に応じて使い分けたい」場面に適しています。

もう一つの違いは、利用者側が振る舞いの切り替えを意識するか否かです。Strategyでは上述のように利用側が戦略を選択・指定しますが、Stateではオブジェクトが自律的に状態を遷移させるため、利用者はそれを意識せずに使えます。この点で、Strategyは「選択肢を外部から与える戦略の切り替え」、Stateは「内部状態による振る舞い変化」と整理できます。

結論として、両者は実装構造が似ているものの、Strategyパターンはアルゴリズムのバリエーションをクライアントの要求によって切り替えるためのパターン、Stateパターンはオブジェクトの状態管理を分離し状態遷移を表現するためのパターンと、目的が異なります。設計時にはこの違いを意識して、適切な方を選ぶと良いでしょう。

Template Methodパターンとの違い：継承を使ったアルゴリズム部分差し替えと委譲による戦略全体差し替えの違いを解説

Template MethodパターンとStrategyパターンは、一つの処理フロー内で一部の実装を差し替え可能にするという点では目的が近いです。しかし、そのアプローチは大きく異なります。

Template Methodパターンでは、抽象クラスに処理の骨組み（テンプレート）を定義し、具体的な可変部分を抽象メソッドとして宣言します。サブクラス側でその抽象メソッドをオーバーライドして具体処理を埋め込むことで、全体の処理手順は変えずに一部の挙動だけを変更できます。これは継承を利用した実装であり、処理の流れ自体は基底クラスで固定されます。

一方、Strategyパターンは、処理手順そのものを交換可能な部品（Strategyオブジェクト）として扱います。具体的には、コンテキストが実行する処理全体をStrategyに委譲しているため、アルゴリズムの構造自体を丸ごと差し替えることができます。こちらは委譲（コンポジション）を活用したアプローチと言えます。

例えば、テンプレートメソッドの例としてレポート生成処理を考えると、基底クラスで「データ取得→データ加工→出力」という流れを定義し、「データ加工」の部分だけ抽象メソッドにしてサブクラスで実装を変える、といった使い方をします。流れ全体（テンプレート）は同じです。一方Strategyパターンでレポート生成を考えると、データ取得から出力までの一連のアルゴリズムをStrategyとして定義し、例えばPDF出力戦略やHTML出力戦略に丸ごと差し替える、といった使い方になります。つまり、Template Methodが「共通の手順の中の一部分を差し替える」のに対し、Strategyは「手順全体を取り替える」イメージです。

Template Methodパターンは継承関係を前提とするため、サブクラスを増やすことでバリエーションに対応しますが、クラスのコンテキスト（this）を共有するのでサブクラス間で状態を共有しやすい利点があります。一方Strategyはコンテキストとは独立したオブジェクトとして戦略を実装するため、複数の戦略間で共通する処理があっても直接共有できない場合があります（必要に応じて共通部分をコンテキスト側で持つなどの工夫が必要）。

総じて、Template Methodはアルゴリズムの骨格を固定しつつ一部分だけを変えたい場合（不変の手順があり、その一部だけ各種バリエーションがあるケース）に向き、Strategyはアルゴリズムをまるごと交換したい場合（手順自体が異なる複数の処理を切り替えたいケース）に向いています。両者は競合するというより、解決したい問題の粒度に応じて使い分ける関係と言えるでしょう。

Strategyパターンを使うべき場面・使いどころ：適用が有効なケースと判断基準

最後に、どのような場合にStrategyパターンを採用すると効果的か、その判断材料を示します。パターンは万能ではないため、適切な場面で使うことが重要です。

Strategyパターンが適している状況：複数の戦略が存在し、状況に応じて柔軟に切り替える必要がある場合

以下のようなケースではStrategyパターンの採用が有効です。

• 同じ目的を達成する複数の処理方法（戦略）が存在し、実行時にそれらを簡単に切り替えたいとき
  例：支払い方法・通知手段・圧縮アルゴリズムなど、結果は同じでも手段が複数あり状況に応じて使い分けたい場合。
• 処理ごとの実装を分離・拡張しやすくしたいとき
  例：新しいアルゴリズムを追加する可能性があり、既存コードを変更せずに拡張したい（将来の機能追加に柔軟に対応したい）場合。
• 処理ごとに再利用や単体テストを行いたいとき
  例：個々のアルゴリズムを別クラスとして切り出すことで、特定の処理を他の箇所でも再利用したり、単独でテストしやすくしたい場合。

上記のように、バリエーションが多く将来的な変更も見込まれる箇所や、処理単位でモジュール化して管理したい場合にはStrategyパターンが適しています。特にif文の分岐が増えてコードが煩雑になっている部分に対して適用すると、コードが整理され拡張もしやすくなるでしょう。

Strategyパターンが適さない状況：処理が単純でStrategyパターン導入が冗長になる場合には使用を避けるべき

逆に、以下のような場合はStrategyパターンは必要ない、もしくは導入しない方がよいでしょう。

• アルゴリズムにバリエーションがほとんどない場合 – 実質1種類の処理しかないのにStrategyパターンを使ってクラスを分けるのは過剰設計です。将来的にも増えそうにないならシンプルな実装で十分です。
• 処理内容が非常に単純な場合 – 分岐が2〜3個程度でコードも短い場合、わざわざクラス化することで却って理解しづらくなることがあります。小規模なスクリプトや一時的な処理なら、まず簡単な実装で済ませる方が良いでしょう。

要するに、Strategyパターンは「戦略を切り替える必要性」が明確にあるときにこそ力を発揮します。必要性が低い場面で無理に使うとコードが冗長になり、理解や保守が難しくなるだけです。設計の段階で、パターンを適用すべきかどうかを判断する際には、将来の拡張可能性や現在の分岐の複雑さを考慮しましょう。適切な場面でStrategyパターンを活用することで、コードの柔軟性と品質を高めることができます。