java:並行開発を行うためのテクニック

何も考えずにクラス分割を行いクラス毎に開発者を割り当てると、未完成のクラスを取り込むことができず、他のクラスが完成するのを待つ必要が出てきてしまいます。
今回は、他のクラスが完成するのを待たずに並行開発するテクニックを、javaの例を用いて説明します。


下記は何も考えずにクラス分割した場合の例です。
HelloProductクラスを取り込みたいのですが、HelloProductクラスが完成していないため、コンパイルができず、HelloProductクラスが完成するまで実行確認を行うことができません。

【サンプルコード】

・HelloMain.java(新規)

【実行結果】


そこで、Interfaceを用いる手があります。
Interfaceの下に、最終的に取り込みたいクラス(HelloProductクラス)と、実行確認時に暫定的に取り込むクラス(HelloTestクラス)を定義することで、最終的に取り込みたいクラスの完成を待たずに、実行確認時に暫定的に取り込むクラスを用いてテストが可能になります。
下記は、暫定的にクラスを取りこんで実行確認を行う例です。

【サンプルコード】

・HelloMain.java(修正)

・HelloInterface.java(新規)

・HelloTest.java(新規)

【実行結果】


そして、最終的に取り込みたいクラスが完成したら、newの箇所を変更することでそのクラスの取り込みが可能になります。

【サンプルコード】

・HelloMain.java(修正)

・HelloProduct.java(新規)

【実行結果】


以上のようにInterfaceの機能を用いて並行開発を行うのは、実際の開発でもよく使われる手段です。

補足すると、この手段は若干古典的な手段となります。
より発展的な手段としては、DI(Dependecy Injection)という手段があり、SpringFramework等のフレームワークの機能を用いることで容易に実現することが可能になります。
DIは、newの箇所(上記のサンプルコードで「 = new HelloTest();」や「 = new HelloProduct();」としていた箇所)の定義を何かしらの方法で不要とすることで、ソースコードを変更することなく取り込むクラスを変更できるようにする、という手段です。
SpringFrameworkでは、特定のアノテーションをソースコードに付与することで、取り込むクラスをxmlファイルで指定することが可能になります。上記のサンプルコードの例で言うと、HelloTestクラスを取り込むのかHelloProductクラスを取り込むのかをxmlファイルに定義することが可能になります。

DIについてはこの記事では詳しく触れませんが、現在の開発ではDIが使われることも多く、書籍やWebの文献も豊富です。
実際に使おうと思った時に実装方法がわからずに困る、ということは少ないでしょう。


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

実際に多人数で開発していると、全てのソースコードが完成しないとコンパイルできないというのはかなり不便で、スケジュールにも影響してきます。
多人数で開発する場合は、今回の記事のようにInterface、フレームワークを使用しているならDIの機能を使用すると良いでしょう。

javaの記事が続いてきましたが、今後はC#の記事も書いていきたいと思っています。
ではまた次回!

java:WEBからHTMLファイルを取得するサンプルプログラム

HTML形式のログを定期的に取得しているのですが、その時に使用しているサンプルプログラムを公開します。
Javaの実行環境が整っているWindowsOSで、LogGet.java と LogGet.bat を同じディレクトリに置き、LogGet.bat を実行すると、「html」フォルダが出来上がりそこにHTMLファイルが格納されます。
取得するHTMLファイルのURL、及びHTMLファイルのローカルでのファイル名は、LogGet.java を修正して変更します。
HTMLファイルの文字コードは「EUC-JP」を前提としていますので、他の文字コードが使用されている場合は LogGet.java の「EUC-JP」の箇所を適宜修正してください。

【サンプルコード】

・LogGet.java

・LogGet.bat


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

定期的にHTMLファイルを取得する機会があったので、javaでプログラムを作ってみました。
複雑なWebページを取得するには不向きですが、単純なHTMLで書かれたページを定期的に取得する時に便利だと思います。

便利な機能を見つけたら、また紹介したいと思います!

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パターンをまだ紹介していませんので、これらのパターンも今後紹介していきたいと思います!