- PR -

空文字を共用する効果

«前のページへ 1|2
投稿者投稿内容
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-25 18:04
引用:

Wataさんの書き込み (2004-05-25 17:28) より:
引用:

スペース３千個の共有定義なら３ｋ分の読み込み時間が高速化される可能性がありますが・・・

public static final の Stringやプリミティブ型の定数はコンパイラにインライン展開
されてしまうので、それもないのでは

ああ、そうですね、
定義の頻度にもよりますが、コンパイル時間が短縮される程度ですね。

引用:

なお、この問題は定数ではなく、staticメソッドを使うことで避けることができます。

うーん・・でも「意味的に」メソッドを使いたくはないよねぇ・・・・。
private static final String EMPTY = Hoge.constEmpty();
...?なんかかえってわかりにくいかも・・・

まあ、リビルドは仕方ないということで。
デプロイ直前に全コンパイルする癖をつけましょう・・・
yuzy
大ベテラン
会議室デビュー日: 2002/02/14
投稿数: 117
投稿日時: 2004-05-25 18:55
引用:

デプロイ直前に全コンパイルする癖をつけましょう・・・


脱線気味ですが、
うちのプロジェクトでは ant を使って、全てコンパイルするようにしています。
まりり
ぬし
会議室デビュー日: 2001/12/05
投稿数: 329
投稿日時: 2004-05-25 23:11
引用:

本人の方にも聞いたのですが、「なんとなく」が回答でした (^^;

これだったら何もしてくれないほうがいいと思うのは私だけ？
どんな無茶なルールでも理由をはっきりさせてほしいですね。

私が想像したのはtak3さんのおっしゃるマジックナンバーを
なくすってことですが、
引用:

全ての""をEMPTYという定数に置き換えているのですが、

を読んで意味ないやって思い直しました。

あるStringのフィールドに対して「空」という状態は
""かもしれないしnullかもしれないし"****"という文字列かもしれない。
こういうときにEMPTY=""とかしておいて代入したり比較したりすると
ソースが読みやすくなりそうです。
（""とnullのような混乱もなくなるでしょう）

そういう意図がないのであれば、反って混乱を招きそうなので
やめたほうがいいかもしれませんね。
性能面では支障はないでしょうけど。
tak3
ベテラン
会議室デビュー日: 2004/04/15
投稿数: 80
お住まい・勤務地: 菜の花・銀杏
投稿日時: 2004-05-26 09:34
EMPTYは、かならずHoge.EMPTY 定数を使うように規定するとEMPTYの判断に

stringHoge.equals("") とか、 stringHoge.equals(EMPTY)　の代わりに
stringHoge == Hoge.EMPTY なんて比較ができるようになりますね。

メリットと思ったけど、実際はEMPTYの定義をまもらなくてバグが多発しそうな気も・・・

Wata
ぬし
会議室デビュー日: 2003/05/17
投稿数: 279
投稿日時: 2004-05-26 10:41
[quote]
zaxx_MDさんの書き込み (2004-05-25 18:04) より:
引用:
なお、この問題は定数ではなく、staticメソッドを使うことで避けることができます。/quote]
うーん・・でも「意味的に」メソッドを使いたくはないよねぇ・・・・。
private static final String EMPTY = Hoge.constEmpty();
...?なんかかえってわかりにくいかも・・・

そうですね。私も使ったことはありません。 (^^;
おっしゃる通り、デプロイ前に全コンパイルするようにすればよいので、
javaの標準ライブラリやjakartaなどの、広く公開する目的のAPIやフレームワークを
作る人ではなければ大きな問題はないと思います。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-26 10:49
引用:

まりりさんの書き込み (2004-05-25 23:11) より:
そういう意図がないのであれば、反って混乱を招きそうなので
やめたほうがいいかもしれませんね。


うーん・・・だいたいそういう定義をするときは、
設計初期に意図をもっていたことが多くて、
それを他人に伝えるのは経緯から整理して説明しないといけないですよね。
で、
引用:

本人の方にも聞いたのですが、「なんとなく」が回答でした (^^;

と答えてしまうことってありませんか？

特にリファクタリングをするのが面倒になって途中から
意図が曖昧になって重複した意味を持ってしまうと・・・・

定数定義するなら最後まで責任を持って管理することと、
きっちりJavaDocコメントを書くとミンナシアワセになれると信じています。
まりり
ぬし
会議室デビュー日: 2001/12/05
投稿数: 329
投稿日時: 2004-05-26 23:24
引用:

特にリファクタリングをするのが面倒になって途中から
意図が曖昧になって重複した意味を持ってしまうと・・・・

定数定義するなら最後まで責任を持って管理することと、
きっちりJavaDocコメントを書くとミンナシアワセになれると信じています。

（強調は引用者による）

手を出したら面倒でも最後までやらないとだめですよね。
人が見る可能性のあるソースであればなおさら。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）