commons-langでtoStringメソッドをも〜っと簡単に実装する
最終回となる第10回は、toStringメソッドをさらに簡単に実装するためのクラス「ReflectionToStringBuilder」を扱う。
ReflectionToStringBuilder
ReflectionToStringBuilderは、前回のToStringBuilderと同様、toStringメソッドの実装を簡単にするためのメソッドである。
今回もテスト用コードとその実行結果から見てみよう。
public class ReflectionToStringBuilderTest {
private String testStr;
private boolean testBoolean;
private int testInt;
private String[] testArray;
public String toString() {
return new ReflectionToStringBuilder(this).toString();
}
public static void main(String[] args) {
// インスタンスを生成して出力する
ReflectionToStringBuilderTest test = new ReflectionToStringBuilderTest();
System.out.println(test);
// フィールド値をセットして再度出力する
test.setTestStr("ABC");
test.setTestBoolean(true);
test.setTestInt(1);
test.setTestArray(new String[]{"aaa","bbb"});
System.out.println(test);
}
// 以下アクセサ(getter/setter)は省略
処理内容は前回と同じである。ただし、toStringメソッドの実装で「ToStringBuilder」ではなく、「ReflectionToStringBuilder」を使用している。
mainメソッドを実行した結果は以下のようになる。
ReflectionToStringBuilderTest@fe748f[testStr=<null>,testBoolean=false,testInt=0,testArray=<null>]
ReflectionToStringBuilderTest@fe748f[testStr=ABC,testBoolean=true,testInt=1,testArray={aaa,bbb}]
クラス名以外は前回と同じ結果が出力されていることがわかるだろう。
ReflectionToStringBuilderを使用する場合、ToStringBuilderを使用する場合とは異なりフィールドの定義を個別に指定する必要がなく、極めて簡単にtoStringメソッドを実装できる。
フィールドに変更があった場合でもtoStringメソッドを修正する必要がないため保守性も良い。
また、以下のように記述することで任意のフィールドを除外することができる。「基本的に全てのフィールドを出力するが、一部のフィールドのみtoStringメソッドの結果に含みたくない」という場合に有効である。
public String toString() {
return new ReflectionToStringBuilder(this)
.setExcludeFieldNames(new String[]{"testStr"})
.toString();
}
この場合の実行結果は以下のようになる。
ReflectionToStringBuilderTest@fe748f[testBoolean=false,testInt=0,testArray=<null>]
ReflectionToStringBuilderTest@fe748f[testBoolean=true,testInt=1,testArray={aaa,bbb}]
setExcludeFieldNamesメソッドで指定した「testStr」の情報が出力されていないことを確認できる。
toStringの結果をログに出力する可能性を考えれば、会員のパスワードのような項目はこの方法で除外するのが良いだろう(情報セキュリティの観点からいえば、この種の情報をログに出力するのは好ましくないため)。
ここまで読んで、ReflectionToStringBuilderがあればToStringBuilderは必要ないのではないか?と思われた方がいるかもしれない。しかし、そうではないのだ。
ReflectionToStringBuilderは内部でリフレクションを使用するため、ToStringBuilderに比べて速度的に劣るのだ。
速度がどの程度異なるか検証してみよう。
以下の内容はtoStringメソッドを10万回実行して、その処理時間を出力するコードだ。
ReflectionToStringBuilderTest test = new ReflectionToStringBuilderTest();
long start = System.currentTimeMillis();
for(int i=0;i<100000;i++){
test.toString();
}
long end = System.currentTimeMillis();
System.out.println(end-start);
筆者の環境では、このコードの実行時間は900ms前後になった。それに対して、ToStringBuilderを使って実装した場合の実行時間は400ms前後である。
10万回実行してこの程度の差であれば問題になることはまずないだろう。しかし、クラスのフィールドの数を追加したり、除外フィールドを指定することで処理時間の差はさらに開いていく。
筆者は基本的にReflectionToStringBuilderを使用しており、状況に応じてToStringBuilderの使用を検討している。
判断のポイントとしては以下が挙げられる。
- 運用環境で頻繁にログに出力するか(toStringメソッドが呼ばれるか)
- ログに出力する必要のないフィールドの数が多いか
- 除外フィールドの数が多いか
早いもので、この連載も今回が最終回となる。全10回の連載では、筆者が使う機会の多い機能を中心に紹介してきたが、紙面の都合で今回取り上げることのできなかった便利な機能はまだある。
続きはこの記事を読んでいるあなたが研究してみて欲しい。この連載を通してcommons-langに興味を持ってもらえたら幸いだ。
- 特集: commons-langの便利メソッド (10件)
- 今日のトップ記事
- 昨日
- 2日前
- 3日前
- 4日前
- ホワイトペーパー
- 企画特集
情報大洪水時代を生き抜くソリューション
Touch Diamond VS iPhone 3G
グローバル競争に金融不安……
ただのERPだけじゃもう足りない!
IT技術者はもっと幸せになれる!
国内シェアNo1
局所冷却に注目。
REAL IT COOL PROJECT
グリーンデータセンターの新潮流
今なら無料! IBMの「グリーンIT化診断」
Green Enterprise
価格から質へと変わるアウトソーシング市場
次のキーワードは、SOIとITFM
仲間と情報を共有・公開する楽しみ方は?
NECのグリーンITの本気度「PUEは1.58」
- ERP,CRMのレスポンスの遅さを劇的改善!
- データバックアップで事業継続力を向上!
- メーカー型番で選べる専用サーバ
- なぜ、ERP 導入は敷居が高いのか?
- Web2.0時代におけるセキュリティ上の課題
- 解約率わずか1%のホスティングサービス
- エンタープライズサーチ特集!
- MicrosoftもOracleもDWH市場に参入!
- 所有から利用へ。拡大するiDC市場
- 市場のニーズに応えた帳票ソリューション
- 運用管理こそ業務の背骨
- 話題のタグ
Javaの父:「Javaはレガシーか?」「その表現は妥当ではない」と反論
マルチコア、マルチスレッド時代に果たすOSの役割
ゴスリング氏、Javaの最新動向を説明:JavaFXとWiiの連携アプリも登場
サン・マイクロシステムズ、RIA用開発プラットフォーム「JavaFX 1.0」をリリース
CSS 3のボックスレイアウトでコンテンツを画面の中央に配置する
ローカルへのデータの保存を可能にするDOM Storage
iPhoneアプリ開発苦労話ベスト3―伝説の開発者に訊く(その1)
あなたの知らないPKI(2)--PKIのコア要素/電子証明書と認証局
不況に強いITを目指す--不況時に高い需要が望める分野はこれだ