java:文字コード・改行コードを指定してファイルを出力する

javaでは、実行環境に応じたデフォルトの文字コード・改行コードを用いてファイルを出力するようにコーディングすることができます。
そのことにより、実行環境毎でコーディングを変更せずとも、実行環境に合わせた文字コード・改行コードを採用することができます。

しかし、他の環境向けのファイルを出力するような場合は、実行環境のデフォルトの文字コード・改行コードが採用されると困ることがあります。
そのような場合、FileOutputStreamクラスを用いれば、指定した文字コード・改行コードを採用することができます。

なお、FileWriterクラスを用いる場合は、setPropertyで実行環境のデフォルトを変更しても文字コードは変更できませんでした。
公式ドキュメント(https://docs.oracle.com/javase/jp/8/docs/api/java/io/FileWriter.html)では「文字ファイルを書き込むための簡易クラスです。このクラスのコンストラクタは、デフォルトの文字エンコーディングとデフォルトのbyteバッファのサイズが許容できることを前提としています。」と書かれており、まさにその通りの挙動となっています。

【テストコード】

【標準出力】

【ファイル出力結果】


入門書では文字コードや改行コードについて触れられることは少ないと思うのですが、システム間でファイル連携を行う場合は必ずと言って良いほど文字コードや改行コードを意識する必要があります。
システム間連携でなくとも、モジュールとモジュールの間でファイルを連携する時にも意識する必要がある場合があります。
入門書には出てこなくとも実務での重要性は高いと思います。

来週からも、実務で役立つ情報を中心に提供していきたいと思います!

java:シリアルバージョンUIDの用途

実務で使用するjavaには、シリアルバージョンUIDが使われていることが良くあります。
シリアルバージョンUIDを知らなくともテストが通ってしまうことが多いと思うのですが、それだと思わぬ失敗をしかねないので、今回の記事で紹介したいと思います。

【シリアルバージョンUIDの用途】

javaではインスタンスをバイナリファイルとして保存することができます。
しかし、インスタンスのクラスの設計を変更した場合、前の設計のバイナリファイルを読み込むと、現在の設計のクラスとの整合性が取れずに処理結果が不正になる恐れがあります。

その際に、クラスにシリアルバージョンUIDを定義しておくことで、前の設計のバイナリファイルを読み込んだ際に例外を吐き出すことができるようになります。
シリアルバージョンUIDはバイナリファイルに保存されるのですが、現在のクラスのシリアルバージョンUIDとバイナリファイルのシリアルバージョンUIDが異なる場合に例外として判定されます。
そのため、クラスの設計を変更する度にシリアルバージョンUIDを変更していれば、前の設計のバイナリファイルを読み込んだ際に例外となります。

【テストコード】

以下、実際に挙動を確認した結果です。

■Item.java

■MainInput.java

■MainOutput.java

【実行結果】

■当初のクラス設計(①を有効、②をコメントアウト)

・MainInputを実行

インスタンスがファイルとして保存される。

・MainOutputを実行

インスタンスを読み込めていることを確認できる。

■クラス設計変更(①をコメントアウト、②を有効)

・MainOutputを実行(変更前のクラス設計時のファイルを読み込んでみる)

インスタンス内に保存されたシリアルバージョンUIDが現在のクラスのシリアルバージョンUIDと異なるため、現在のクラスに対応したインスタンスではないと判断して異常終了する。
(シリアルバージョンUIDを変更しないと、現在のクラスに対応したインスタンスでなくても読み込み時にエラーにならずに後続に進んでしまう。不正なインスタンスを用いることで後続処理の処理結果が不正になる可能性が出てしまう。)

・MainInputを実行→MainOutputを実行

新しいクラスでインスタンスを作り直せば正常に処理できる。


今回取り扱ったシリアルバージョンUIDもそうですが、研修で習うことは少なくても実務での使用頻度は高い、という文法は少なくありません。
そのような文法を見つけたら、また紹介したいと思います。

これからも、実務で役に立つ情報をお伝えできればと思います。
では、また来週!

java:インターフェースを用いることでクラス毎の重複した記述を無くす

javaにはインターフェースという機能があります。
インターフェースとは、メソッドの仕様(メソッド名、戻り値、引数)のみを定義したものです。
インターフェース単独では処理を実行できませんが、そのインターフェースを実装したクラスを定義することで処理を実行可能になります。

インターフェースを利用するメリットとしては、重複した記述を無くせることがあります。
オブジェクトを参照する際にインターフェース名を指定することで、そのインターフェースを実装している全てのクラスを指すことができます。一つの記述で複数のクラスに対応させることができるので、クラスごとに同じ記述を行う必要が無くなり、保守性が向上します。

言葉だと通じにくいと思うので、サンプルコードを用意しました。

【サンプルコード】

まず、インターフェースとして、金融商品インターフェース(FinancialProductsインターフェース)を定義します。
このインターフェースは、1ヶ月後の商品価格を計算するメソッドを持ちます。

・FinancialProducts.java

 

次に、金融商品インターフェースを実装します。
単利商品クラス(SingleInterestProductsクラス)と、複利商品クラス(ComplexInterestProductsクラス)を実装します。
この2つのクラスは、共に1ヶ月後の商品価格を計算するメソッドを実装していますが、その実装内容(計算ロジック)は異なります。

・SingleInterestProducts.java

・ComplexInterestProducts.java

 

そして、単利商品クラスと複利商品クラスを使用するメインクラスです。
メインクラス内で定義している2ヶ月後の商品価格計算メソッドにて、金融商品インターフェースを参照することで、単利商品クラスと複利商品クラスを同じ記述で使用することができているのがポイントです。

・Main.java

【実行結果】


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

インターフェースはjavaの基礎的な文法の一つです。
しかし、インターフェースは様々な形で応用されています。
例えば、配列のソートで独自定義を行う時にインターフェースの理解が必要になりますし、デザインパターンやフレームワークといったオブジェクト指向の設計手法でもインターフェースは頻出です。
そのため、単純に読める・コンパイルエラーにならないコードを書ける、というレベルの理解ではなく、これを使うと何が嬉しいのか、というレベルで理解するのが望ましい、と個人的には思います。

これからも、実務で役に立つ情報をお伝えできればと思います。
では、また来週!

マッチング処理のサンプルプログラム

マッチング処理(マスタデータとトランザクションデータを突き合わせる)のロジックについて、前回の記事で紹介しました。
サンプルプログラムを作成しましたので、参考までに紹介します。
言語はCOBOL(opensource COBOL)です。

【サンプルプログラム】

【マスタファイル】

・C:\tmp\a.txt

【トランザクションファイル】

・C:\tmp\b.txt

【出力ファイル】

・C:\tmp\c.txt

【標準出力】


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

マッチング処理はそこそこ複雑なロジックなので、マッチング処理を使用するプログラムを前知識無しで目にすると戸惑うと思います。
しかし、前回の記事で紹介したフローが頭に入っていれば、プログラムも読めるようになると思います。
業務で開発するバッチプログラムでは頻出のロジックなので、前回の記事の内容と合わせて頭に入れておくことをお勧めします。

これからも、実務で役に立つ情報をお伝えできればと思います。
では、また来週!

マッチング処理のロジック

今回は、バッチプログラムで使われるロジックの一つである「マッチング処理」について説明します。
「マッチング処理」とは特にCOBOLではよく目にするロジックであり、マスタデータ(業務の基盤となるデータ。商品一覧、取引先一覧等。)とトランザクションデータ(業務で日々発生するデータ。販売履歴、入金履歴等。)を突き合わせる処理です。
マッチング処理を覚えておけば、実業務でバッチプログラムを作る時のヒントになりますし、開発者同士のコミュニケーションもスムーズになります。

突き合わせを行う時は、マスタデータとトランザクションデータで同じキー項目(商品コード、取引先コード等)を使用し、そのキー項目で昇順にソートした後、マスタデータとトランザクションデータを1件ずつ読み、キー項目が一致するかどうかで突き合わせを行います。
マスタデータとトランザクションデータでキー項目が一致した場合(マスタで管理しているもので取引が発生した)と、マスタのみキー項目が存在している場合(マスタで管理しているが取引は発生しなかった)は正常ケースですが、トランザクションのみキー項目が存在している場合(マスタで管理していないものが取引された)は異常ケースとなります。

マスタデータの一つのキー項目に対して、トランザクションデータの0~1つのレコードが対応する場合は、1対1マッチングと呼ばれます。2つ以上のレコードが対応することがある場合は1対nマッチングと呼ばれ、処理が少しだけ複雑になります。

フローチャートと例は以下の通りとなります。

【フローチャート】

【例】

・要件

商品名が管理されている商品マスタと、商品の販売履歴(トランザクション)をファイル形式で読み込み、商品名と販売日を別ファイルで出力したい。

・商品マスタのフォーマット

カンマ区切りの固定長ファイル。
商品コードでレコードを一意に特定できるようにデータをセットする。

・販売履歴のフォーマット

カンマ区切りの固定長ファイル。
商品コード・販売日でレコードを一意に特定できるようにデータをセットする。

・出力ファイルのフォーマット

・商品マスタのレコード

・販売履歴のレコード

・処理の流れ

・出力ファイル


以上、「マッチング処理」でした。
少し複雑なロジックですが、ファイルをキーの昇順に並べて順番に読み込むことと、キーがマッチする場合・しない場合は具体的にどのような状況なのかをイメージすることがポイントになります。

次回は、サンプルプログラムを書いてより具体的に説明したいと思います。
では、また来週!