はじめに
本記事は、デザインパターン学習中の私が学習中に詰まったポイント、間違えてしまったポイントをもとに学んだことを書いたものです。
個人の理解に基づいておりますため、間違いがあれば教えていただけると幸いです。
★9ヶ月前くらいにデザインパターンの勉強のために執筆し、社内で公開していた記事をこちらにも投稿したものとなります。
「それ、Stateパターンじゃない？」
Strategyパターンの勉強としてクラス図とコードを作ってみたところ、こんな指摘をいただきました。
私が学習の題材として作成したコードは以下のようなもの。（オンラインショップの送料や割引などの料金計算をイメージしていました）
- 料金の計算方法が三通りある
- 入力した金額をもとに料金計算の方法を切り替える
書籍と比べてもクラス図は合っていそう。ちゃんとStrategyごとに実体のクラスも分けている。切り替えられるようにも作っている。
じゃあいったい何が違うんだ……？
何が違ったのか
まず、Strategyパターンとは、
アルゴリズムをプログラムの他の部分から分離し、アルゴリズムの動的な切り替えを可能とすることを目的としたパターンです。アルゴリズムをクラスとして定義し、プログラムから委譲によって利用します。
次に、私が意図せず作成したStateパターンとは、その名の通り、システムの状態をクラスで表すことを目的としたパターンです。状態をクラスとして定義し、状態に依存した振る舞いをそのクラスのメソッドとして定義しています。プログラムが持っているクラスが変わることで状態が変わり、その時の状態に応じて処理が変わります。
つまり、Strategyパターンはクライアント側が能動的にStrategy（戦略）を切り替えることで処理が変更されるパターンであり、
Stateパターンは何かしらの要因でState（状態）が切り替わり、それによって処理が変わるパターンです。
クラス図を比較すると全く同じですが、目的が異なっています。
最初に私が作成したコードでは、料金という状態が切り替わることで処理（計算方法）が変更されていました。「料金の入力」というユーザーの操作を前提としたことでわかりにくくなっていましたが、ユーザーが能動的に料金計算方法を切り替えているわけではないため、これはStrategyパターンには当てはまりません。
もしこの題材でStrategyパターンのプログラムを作成するなら、
- 料金の支払方法をStrategyにする（カードか、コンビニ払いか、はたまた着払いか……など）
- 入力金額ではなく、ユーザーが能動的に支払方法を変更できるようにする
……というわけで、以下のようなプログラムであればよかったのでしょう。
まとめ
デザインパターンは、 「設計を行ううえでよく突き当たる問題を解決するための設計のノウハウをまとめたもの」 です。
しかし、いくらノウハウを知っていても間違えて使ってしまっては意味がありません。間違った理解のまま学習を終えなくてよかったと思いました。
デザインパターンを学ぶうえで、
このパターンのメリットは何か
どんな設計の問題を解決できるのか
という部分をきちんと学習で理解して、設計に活用できるようになりたいです。
そのためには、今回のように「似ているけれど目的が違う」パターンには注意する必要があると感じました。
◆◆◆
最後まで読んでいただき、ありがとうございました。
こんな感じのデザインパターン記事を何本か投稿するつもりなので、良ければまた読んでいただけると嬉しいです。