- - PR -
static修飾子は多用するべきか
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-12-16 11:13
同一クラスの全てのインスタンスで共有される『staticフィールド』や『staticメソッド』。
これについては、『メモリ領域を共有する』という説明がされています。 メモリ領域を共有するなら、各インスタンスで持つよりメモリの節約になりそうだし、 publicも併用すればインスタンスを作るまでもなく『クラス名.フィールド名』や『クラス名.メソッド』といった使い方もできるので、 私としては、スレッドセーフであるなら（もしくはセーフでなくても構わないなら）、staticはガンガン使うべきだ、というふうに思っています。 ですが、以前Javaに非常に詳しい人に話を聞いたところ、 『staticはダメだ。staticがあるからJavaがダメだという評価もあるほどだ』と言われて驚きました。 その時は理由を聞けなかったのですが、正直言って、staticがダメだという理由がわかりません。 staticがダメって、どういう理由によるのでしょうか？ そして、どういう場合ならstaticを使うべきで、どういう場合だと使わない方がよいのでしょうか？ ご存知の方、ご教授をお願いします。 | ||||||||
|
投稿日時: 2005-12-16 11:55
初心者がやってしまいがちな、
・とりあえずコンパイルできるように static に ・なんでもかんでも static は良くないと思います。 使用すべきか、すべきでないかはケースバーケースでしょう。 意味を理解した上で利用する分には問題ないし、不要なインスタンス変数を減らすという意味でも賛成です。 簡単なツールを作るとき全部 main() とそれから呼び出される static メソッド、static 変数からなるプログラムを書いてしまうのもアリかと。必要に応じてリファクタリングしていけば良いし。 また、スレッドセーフかどうか等の感覚がない初心者に対して「なるべく static は使うな」というサジェスチョンをするのは良いことかと思います。 | ||||||||
|
投稿日時: 2005-12-16 11:57
Polymorphismが無意味になるからでしょう。
staticはSingletonやユーティリティメソッド等に限定すべきだと思います。 定数などクラスの内部的な実装の目的なら使うべきだと思いますが。 インスタンスを無駄に作りまくるような場合はともかく、それ以外の場合で、 共有してメモリを多少節約できるくらいじゃメリットが少なすぎるかと。 自分的な基準では、staticしか考えられないのであれば利用し、 多少なりとも迷う場合は使わないようにしています。 | ||||||||
|
投稿日時: 2005-12-16 12:48
staticにはきちんとした目的があるものであって、
使えばいい・ダメで判断されるものではないと思います。 また、便利か便利じゃないかでも判断できませんし、 必要があって利用されるものです。 ちなみに、staticならメモリの節約に、という観点は間違いです。 staticなフィールドにインスタンスを保持させると、 そのクラスがGCの対象になるまで そのインスタンスもGCの対象とはなりません。
Javaに詳しいか疑問を感じます。 | ||||||||
|
投稿日時: 2005-12-16 13:04
まず、staticというのは「メモリの節約」や「インスタンスを作らずにメンバにアクセスする」ためのものではないので、そのような発想で使用するのはお門違いです。 というか、何でもかんでもstaticにしたら、かなり不自然なクラス設計になってしまうと思いますが…… 
私の場合、シングルトンやユーティリティクラスを除いて、クラスに定数やファクトリーメソッド以外のstaticなメンバ(あるいはstaticにするかどうか迷うメンバ)が多くなった場合、クラスの設計が適切かどうか見直すようにしてます。
いや、ダメなのはstaticじゃなくてその人だと思います。 | ||||||||
|
投稿日時: 2005-12-16 13:23
インギさん、あしゅさん、かつのりさん、まいるどきゃっとさん
ご返答ありがとうございます。 どうやら、忌避が必要なほどデメリットがあるわけではないようですが、 使わずに済むなら使わずに済ませたほうがよいようですね。 私としては、例えば以下のような状況を想定していたのです。 定義するクラス：固定名のファイルの内容を取得して保持しておき、要求に応じて情報を提供するクラス 呼び出し元：同時進行が予想される複数のスレッド（スレッド数不定） このような状況だと、スレッド毎にインスタンスを作成して同じファイルの内容を取得するのは不合理かと思い、staticを使うべきか考えたのです。 staticならファイルの読み込みも保持も１回で済みますので軽量・高速化が期待できる反面、 単一のstaticフィールドに複数スレッドから同時参照があるともしや却って重くなったりしないか、迷いました。 まだ少し迷うところもありますが、staticはスレッド間でなんらかの情報のやり取りが必要な場合を除いては使わない事にします。 >staticなフィールドにインスタンスを保持させると、 >そのクラスがGCの対象になるまで >そのインスタンスもGCの対象とはなりません。 なるほど、知りませんでしたが、理屈から言えば確かにそうなるはずですね。 （『クラス』がGCの対象になる、という事自体知りませんでした。） | ||||||||
|
投稿日時: 2005-12-16 13:28
私も、数十文字程度で大まかに書くと、この「Javaに非常に詳しい人」と同じような意見になります(ニュアンスが分からないのでどこまで同意見かは分かりませんが)。 static がなくても良いとまでは言いませんが、普通のアプリケーションを書く分には、static は不要です。もっとも public static final int HOGE = 12345; みたいなやつは構いません。あと、static なメソッドはあっても構いません。焦点は static なフィールドを持つかどうかです(メソッドが static になるかどうかはフィールドが static かどうかに依存するので)。 大抵の状態を管理するために static を使うのは混乱の元です。また、今インスタンスがひとつで済んでいたとしても将来複数になる可能性はほとんどのケースでつきまといます。逆に言えば main が static なのは、そういう可能性がないからです。 ただ、ケータイ Java などではメモリーをケチケチにケチるために static を使うとも聞いたことはありますが、それは便法だと考えたほうが良いでしょう。 | ||||||||
|
投稿日時: 2005-12-16 13:52
ところでstaticなメソッドに多態性がないのは何故でしょうかね
これはどの言語にも無いと思うのだけど,確か昔ARMか何かで それについての理由が書かれていて実装上の困難に引き合うほどの利点が それほど無いというようなことが書かれていたように思うのです (良く覚えていないので間違っているかも)原理的には仮想テーブルを 持つだけで出来そうに思えるのですが,実装上不可能なのでしょうか あるいは別の理由で実装しないという明確な理由があるのでしょうか? 単にC++がそうだったからjavaもそうなったというわけでも無いでしょ | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。