メッセージは外部ファイルよりEnumで定義の方がいいのでは?

2016/07/26

JavaでWebアプリを作る場合、メッセージ類は普通は外部ファイルに定義する。
スタンダードなのはmessage.propertiesのような外部ファイルを作って、そこにkey-value形式でメッセージIDとメッセージを書いていく。 そしてResourceBundle クラスを使用して、プロパティファイルを読み取る。

messages_ja.properties

messages_en.properties

定数や画面に表示する内容は簡単に変えられるように、外部にまとめて定義するというのは王道。それに外部ファイルに定義すればビルドをやり直さなくていい。

しかし実際問題、TomcatでJavaのWebアプリを本番環境で動かすという状況を考えると、これらの利点は失われると考えている。

まず、普通リリースするときはまとめてアプリをサーバにアップする。
本番環境のメッセージ用プロパティファイルを直接書き換える事態は早々起こらない。
バージョン管理システムへのコミット→検証環境での試験→本番環境という正規の手順を踏むべき。

次に、本番運用する場合は、Tomcatを再起動しない限りプロパティファイルを変更しても読み直さない設定にすることが普通なので、どうせ再起動するのであればビルド不要という利点も大したものではなくなる。

これらの利点が失われるのであれば、EnumとしてJavaのソースコードに組み込んだ方が、別の利点を取り込めていいのではないか?

プロパティファイルのデメリット Enumで解消されるか?
メッセージIDが直書きなので、存在しないメッセージIDを書いてしまうかもしれない。
定数クラスを作ったとしても、直書きする人が出てくるかもしれない。
解消できる。
Enumは存在する値しか指定できないから。
プロパティファイルとJavaソースの定義箇所と参照箇所のジャンプができない。
できたとしてもEclipseにプラグイン入れたりする必要あり。
解消できる。
Javaソースに書いてあれば、Eclipseのジャンプや呼び出し元の確認ができる。
日本語と英語の両方に同じメッセージIDがあることを担保できない。
うっかり日本語だけ追加する人や、日本語だけ修正する人が出てくるかもしれない。
解消できる。
(これはデメリットがあって、メッセージ定義書としてみると、日英両方が一ファイルに書いてあるので煩雑に見える。
しかし裏を返せば一覧で両方把握できるというメリットあり。)

プロパティファイルのデメリットが全てEnumで解決できるし、Enumにすることでプロパティファイルより明らかに劣る部分もない。

コードは次のようなイメージ。

-Java