javaでのCommandパターン

Commandパターンとはデザインパターンの一種で、1つ1つのコマンド(命令)をそのままオブジェクトとして表現するパターンです。
コマンドをオブジェクトとして表現することで、コマンドの管理(追加・削除・実行)が可能になるというメリットがあります。

今回は、ファイルやフォルダを作成するコマンドを管理するサンプルコードを作成してみました。
Commandクラスが1つ1つのコマンドを表し、コマンドの管理はInvokerクラスで行い、コマンドの実際の処理はReceiverクラスで記述します。

【サンプルコード】

・Command.java

・ConcreteCommandForOperation.java

・ConcreteCommandForTemporary.java

・Receiver.java

・ConcreteReceiverMkfil.java

・ConcreteReceiverMkdir.java

・Invoker.java

・CommandMain.java

【実行結果】

・コンソール出力

・ファイルやフォルダの生成確認


いかがでしたでしょうか。

デザインパターンに出てくる設計は、自力ではなかなか思いつかない勉強しがいがあるものが少なくないと思います。
「コマンドをオブジェクトとして表現することで、管理(追加・削除・実行)を可能とする」というCommandパターンの発想も、その一つなのではないかと思います。

ここしばらくの間はデザインパターンの紹介を行ってきましたが、一旦一区切りつけたいと思います。
次週からはまた別の観点で役に立つ記事を発信して行きたいと思いますので、今後もよろしくお願いします!

javaでのStateパターン

Stateパターンとはデザインパターンの一種で、1つ1つの状態をそのままクラスとして表現するパターンです。
通常のコーディングだとIF文で状態毎の処理を記述させるためそれぞれの状態でどのような処理が行われるのか読み取りにくいのですが、このパターンを適用すれば状態遷移図上の状態とクラスが1対1で結びつくようになるので、処理が単純明快になります。

今回は、朝・昼・夜の各状態で出現モンスターが変わるサンプルコードを作成してみました。
このパターンは記述内容としては決して難しくないので、サンプルコードを見た方が理解が早いと思います。

【サンプルコード】

・StateEnum.java

・State.java

・UnknownState.java

・MorningState.java

・DayState.java

・NightState.java

・Context.java

・StateMain.java

【実行結果】


いかがでしたでしょうか。

設計を行う際に、状態遷移図を書くことがあると思います。
その状態遷移図をコードとして表したものが、Stateパターンです。
コードの可読性が上がるだけでなく、状態を追加するような時にも影響を局所化できるので、覚えておいて損は無いパターンだと思います。

次回は、Commandパターンについて取り扱いたいと思います!

javaでのMediatorパターン

Mediatorパターンはデザインパターンの一つで、複雑に絡み合ったオブジェクト間の関係をMediator(調停者)が整理するパターンです。
例えば、10個のオブジェクト間で連携を取る必要がある場合、オブジェクト同士で直接連携を取ると、「自分以外の9個のオブジェクトに対する調整処理 × 10個のオブジェクト」で90通りの調整処理が必要になってしまいます。
しかし、調停者のオブジェクトを新たに作成し、その調停者を通して調整することにすれば、「調停者に対する調整処理 ×10個のオブジェクト」で10通りの調整処理で済みます。

ある資源に対して作用するプロセスやボタン等が多い場合に効果を発揮するパターンです。

以下、サンプルコードです。
誰かが実施すれば良い作業に対して、複数の作業者が作業しようとする例です。

【サンプルコード】

・Mediator.java

・ConcreteMediatorA.java

・ConcreteMediatorB.java

・Colleague.java

・ConcreteColleagueA.java

・ConcreteColleagueB.java

・MediatorMain.java

【実行結果】


いかがでしたでしょうか。

今回紹介した Mediatorパターンは、前述の通り複数のオブジェクト間の連携が多い時に効果を発揮するパターンです。
調停者クラスを用意して連携を調整するという発想は、自力ではなかなか思い浮かばないと思います。
そこでこのパターンを頭に入れておけば、オブジェクト間の連携が多く処理が煩雑になりそうな場合に、調停者クラスを定義することで整理するという発想が思い浮かぶようになると思います。

StateパターンやCommandパターンをまだ紹介していませんので、これらのパターンも今後紹介していきたいと思います!

javaでのChainOfResponsibilityパターン

Chain of Responsibilityパターンとは、その名の通り責任が連鎖する構造を表すためのパターンです。
あるオブジェクトで解決できない問題を別のオブジェクトにたらい回すようにするのがツボで、そうすることで解決できなかった場合の処理を簡略化できます。

ソースコードを見た方が理解が早いと思うので、いつも通りサンプルコードを示したいと思います。
某有名RPGを模した例で、3匹の味方モンスターが色々な敵モンスターと戦い、その結果を表示するというサンプルコードです。
(なお、今回のサンプルコードでは、このデザインパターンとは直接関係のないEnumクラスも出てきますが、これは同じ定数が何度も出てくるサンプルであるために簡略化のために使用しているので、「責任をたらい回す」という本質とは関係ありません)

【サンプルコード】

・MonsterAttributeEnum.java

・EnemyMonster.java

・AllyMonster.java

・MonsterBattleMain.java

【実行結果】


いかがでしたでしょうか。

今回紹介した Chain of Responsibilityパターンは、ある要求を処理するオブジェクトが複数存在する場合に適用することで、プログラムの再利用が容易になるというパターンです。
ある業務命令をどの役職の社員で処理するか(一般社員なのか、課長なのか、部長なのか、社長なのか)、あるイベントをどのレベルのメッセージで出力するか(正常なのか、警告なのか、異常なのか)、といった場面で利用すると有効です。

まだ紹介していない便利なデザインパターンとしては、Mediatorパターン、Stateパターン、Commandパターンといったものがあります。
これらのパターンもおいおい紹介していきたいと思います!