1つだけ過去を変えられるとしたら?

定数につけるべき修飾子はなんでしょうか?

経験上「static final」としていることが圧倒的に多いです。
どんなときも必ずそうする意味はあるのでしょうか?

私には、考慮不足でとりあえず「static final」としているだけで
実際には場合によって使い分けたほうがいいのではないだろうかと思っています。
しかしあまりにも「static final」としている数が多いので
何か特別な意味があるのでは無いかと思っています。

例えば
・24時間365日稼動のシステム
・1日1回バッチ処理を行なう
・そのバッチ処理の中だけで使用する定数

こういう場合にはメモリ上の展開を考慮すると
「static final」よりも「final」にした方がいいように思えます。
でもそうせずに「static final」としていることが多いです。


定数の修飾子は、その使われ方・場合によって使い分けるべきでしょうか?
それともどんなときも「static final」とすべきでしょうか?
どちらであるか(もしくはそれ以外)とその理由を教えてください。

よろしくお願いします。

A 回答 (4件)

誰もそもそもの概念に触れていないのが気になりますね。

「staticのついていないフィールドはstaticメソッドからアクセスできない」というのが近いといえば近いですが。

おそらくご存知だと思いますが、staticメンバ「変数」というのは、そのクラスそのものに依存する変数であることを意味します。一方staticがつかない変数はクラスではなく、オブジェクトに依存する変数です。つまりstaticがつくかつかないかは、概念上の区別に基づいて決められるのです。これが「staticメソッドからはstaticでない変数にはアクセスできない」という実際のふるまいとして表れてきます。

では定数についてはどうか。これも変数と同じで、オブジェクト依存の定数にはstaticをつけないのが基本です。例えば、

final int number;

という定義をして、コンストラクタで、例えば引数に応じて値を代入することができます。これでオブジェクトごとに異なる定数が作れますよね。

というわけで、概念に応じてstaticを使い分けるのが基本です。クラスの設計段階で、ある変数・定数がクラスに基づくものかオブジェクトに依存するものかをきちんと区別すべきです。
これはJavaに限らずCなどでも共通認識ですので、メリットはそのままです。つまりstaticがつくものはクラス依存の定数なのだな、と他人が見て一目で分かることです。メモリ効率やアクセス速度などの点からこのルールを逸脱する場合は、コメントなりドキュメントなりに残すべきでしょうね。
    • good
    • 0
この回答へのお礼

>オブジェクト依存の定数にはstaticをつけないのが基本です。

なるほど。すっきりしました。


>概念に応じてstaticを使い分けるのが基本です。
>クラスの設計段階で、ある変数・定数がクラスに基づくものか
>オブジェクトに依存するものかをきちんと区別すべきです。

やはりそうですよね。本来そうすべきな気がするのに
何も考えずなんとなくstaticをつけているとしか思えない
ケースが多いように感じ質問をしてみました。

自分の考えに自信が持てました。
大変参考になりました。ありがとうございました。

お礼日時:2009/11/19 11:27

>「static final」でも「final」でもどっちでもいい、


>「static final」が多く使われることに何も根拠は無い、
>ということでしょうか?

staticやfinal修飾詞の意味は理解されている前提で話をしておりますが、このへんは開発される方、そのプロジェクトのコーディングルールなり定数やプロパティの扱いの仕方次第ではないかと。
(なので決まった答えはない)

メモリやその他を気にするよりも、そのプロジェクト内での取り決めに従えばいいのでは?ということです。

>・そのバッチ処理の中だけで使用する定数
こういうのはローカル定数でもいいとは思います。

この回答への補足

質問は「決まった答えがあるのか無いのか」ではありません。

プロジェクトの取り決めでも開発者個人の考えでも何でもいいのですが
すべての人が何の根拠もなく選択しているのか、
何か根拠があって選択しているのか、根拠があるのなら
どのような根拠に基づいているのかそれを教えていただきたいのです。

「…のような違い・メリットがあるから、この方法を選択している」
等の説明を期待しています。

この世のすべてのパターンを網羅して答えてください
といっているつもりはまったくありません。
メジャーなもの1パターンでもいいので例を挙げて説明していただきたいです。
よろしくお願いします。

補足日時:2009/10/22 13:05
    • good
    • 0
この回答へのお礼

ありがとうございました。

お礼日時:2011/11/06 10:40

staticのついていないフィールドはstaticメソッドからアクセスできません。

下のコード例のメソッドcはコンパイルエラーになります。
一方、staticフィールドならばstaticメソッドからもそうでないメソッドからも問題なくアクセスできて便利です。

public class A {
private final int TEISUU1 = 123;
private static final int TEISUU2 = 789;

public int a() { return TEISUU1; }
public int b() { return TEISUU2; }
public static int c() { return TEISUU1; } ← コンパイルエラー
public static int d() { return TEISUU2; }
}
    • good
    • 0
この回答へのお礼

>staticフィールドならばstaticメソッドからもそうでないメソッドからも問題なくアクセスできて便利です。

あぁ、なるほど。確かにそうですね。
staticメソッドから呼ばれることは無いと確定しているときに「final」にし、
staticメソッドから呼ばれるかもというときに「static final」にするということですね。
その視点は抜けていました。

参考になりました。ありがとうございました。

お礼日時:2009/10/22 13:13

よほどメモリ管理がシビアなものでなければそれほど気にする必要もないのではないでしょうか?

この回答への補足

「static final」でも「final」でもどっちでもいい、
「static final」が多く使われることに何も根拠は無い、
ということでしょうか?

補足日時:2009/10/21 16:45
    • good
    • 0
この回答へのお礼

ありがとうございました。

お礼日時:2011/11/06 10:41

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!


おすすめ情報