5

最近、構成を「プロパティー・ファイル」に依存している Java コードを多数目にするようになりました。ただし、単純な古い文字列リテラルの代わりに、コードは定数 (静的な最終文字列) を使用してプロパティ値を取得します。

どちらか一方の方向で 2 つのルックアップを実行する必要があるため、この余分なレベルの間接性が煩わしいと思います。構成ファイルで観察されたプロパティから始める場合、最初にプロパティ名を検索して Java 定数を見つけ、次に再度検索してコード内の定数への参照を見つける必要があります。コードから始めると、構成ファイル内のプロパティの値を決定する前に、定数の実際の値を見つける必要があります。

ポイントは何ですか？

リソースバンドル内のキーを参照するために定数を使用することの価値を理解しています。通常は i18n をサポートしています。私は単純で、ユーザー向けではない構成値について言及しています。私が考えることができる唯一の理由は、後でプロパティ名を簡単に変更できるようにすることですが、この利点は、特にグローバルな検索と置換の容易さを考えると、私見の煩わしさよりもはるかに少ない.

4

5 に答える 5

12

1 つには、コンパイラ エラーを発生させずに定数を使用するときに、キーの入力を間違えることはありません。

于 2009-02-15T15:20:51.380 に答える
6

簡単なグローバル検索と置換 (これは新しいことではありません) の時代でも、定数を使用すると、文字列がそのプロパティ ファイル専用であることを知ることができます。これは次の理由で優れています。

  • 定数は、タイプミスがコンパイラ エラーになることを意味しますが、文字列はそうではありません。
  • 定数を使用すると、あるプロパティ ファイルのキー「ID」と別の XML ファイルのキー「ID」を分離できます。同じ文字列、異なる意味。
  • グローバルな検索と置換は多くのものを破壊する可能性がありますが、IDE では定数のすべての使用箇所を非常に簡単に検索し、関連するものだけを変更できます。

多くの場合、それはプログラマーが身につけた単なる良い習慣ですが、良い習慣には理由があります。

于 2009-02-15T15:20:57.870 に答える
6

再コンパイルせずに値を変更する必要がある場合、必然的に何らかのリダイレクトが必要になりますが、キーを複数の場所で参照する必要がない限り、さらに別のことを行うのはかなりばかげています (それ自体、関心の分離が不十分である可能性がある兆候です)。

キー文字列は、そのスコープ (通常はクラス) の外にある他の文字列と衝突できないように十分に説明的であるべきであり、単一のクラス内でリテラルを一意に保つことは、複雑ではなく、単一のブロックで宣言する価値があるほど深刻な問題になる可能性もありません。したがって、（IMO）この慣行は、ルールの本来の意図を理解せずにルールに奴隷的に従う人にすぎません。

このガイドラインを緩和することを正当化するために、別のガイドラインを引用する必要がある場合は、KISS をお勧めします。

于 2009-02-15T15:38:20.747 に答える
0

オートコンプリートは定数の識別子に対してより適切に機能するためですが、すべてのキー値が「com.foo.bar.whatever」である場合、フィードバックは得られません。

于 2009-02-15T16:48:31.733 に答える
0

私は以前にもこの慣習を見たことがあります。実際、定数ファイルを検索しなければならないプロジェクトに参加したときに、探していたプロパティ名を最終的に与える XML ファイルにたどり着きました。そして、値が本当に欲しかったものだったので、プロパティ ファイルも確認する必要がありました。

これは、Jeff と Joel が前回のポッドキャストで話していたことの例だと思います。そこでは、開発者が聞いたことのある慣行 (この場合、コードに文字列リテラルを決して持たないという慣行) にやみくもに従っています。目の前の問題を考えると、それが本当に適切かどうかを考えずに。

于 2009-02-15T15:19:49.793 に答える