import java.*
1 つのパッケージ ( )内のすべての型をロードするインポートを作成するオーバーヘッドに関する違いはあると思いますか? 特定のタイプ(つまりimport java.lang.ClassLoader
)だけではありませんか?2番目のものは、他のものよりも使用するのに適した方法でしょうか?
10 に答える
Java API を見ると、異なるパッケージに同じ名前のクラスとインターフェースが多数あることがわかります。
例えば:
java.lang.reflect.Array
java.sql.Array
そのため、インポートするjava.lang.reflect.*
とjava.sql.*
Array タイプで衝突が発生し、コードでそれらを完全に修飾する必要があります。
代わりに特定のクラスをインポートすると、この手間が省けます。
import .* と特定の型をインポートすることによるパフォーマンスやオーバーヘッドのコストはありません。ただし、 import .* を使用しないことがベストプラクティスであると考えています。これの主な理由は、物事を単純明快に保ち、可能な限りあいまいさをなくしたいからです。.* import を使用すると、それが失われると思います。 .
これは実際には非常に悪い問題です。
あなたが書くと仮定します
import a.*;
import b.*;
...
Foo f;
クラス Foo はパッケージ a に存在します。
完璧にコンパイルされたコードをチェックインすると、6 か月後に誰かがクラス Foo をパッケージ b に追加します。(おそらく、最新バージョンでクラスを追加したのはサードパーティのライブラリです)。
ふふっ!これで、コードはコンパイルを拒否します。
インポート オンデマンドは使用しないでください。悪だ!
詳細については、 http://javadude.com/articles/importondemandisevil.htmlを参照してください。
再性能:
import a.*;
対
import a.X;
実行時に違いはありません。コンパイラは、解決されたクラス名を生成された .class ファイルに固定します。
少数派の意見:私のコードでは、いくつかのパッケージの大量のクラスと、あちこちのいくつかの奇妙なクラスを使用する傾向があります。何が起こっているのか一目でわかるように、インポート リストを小さくしておくのが好きです。これを行うために、しきい値を 4 クラスに設定しました。その上で、Eclipse はコードに * を使用します。これにより、パッケージのインポートが読みやすくなり、クラスを確認するときに最初に行うこととして参照する傾向があり、次の質問に答えます: 誰と対話しますか?
名前の衝突について:競合するクラス名を持つ 2 つのパッケージから 4 つ以上のクラスをインポートする可能性はどのくらいですか? 時間の 10% を超える場合は、クラスが依存するパッケージの数を検討することをお勧めします (たとえば、より小さなクラスにリファクタリングします)。
さらに詳しい情報を探したところ、非常によく説明されているこのウェブサイトに出くわしました。インポートの問題と、インポート ステートメントで * を使用するとパフォーマンスに影響しますか? .
これら 2 つのスタイルの間に効率上の問題はありますか? おそらくですが、インポート宣言は実際にはプログラムに何もインポートしないため、違いはごくわずかです。コンパイル単位の先頭に暗黙的なインポート java.lang.* があり、JDK 1.2.2 の java.lang には 75 個のクラスとインターフェイスが含まれていることに注意してください。何千ものクラス名が使用されており、検索する必要がある不自然な例を使用した実験では、コンパイル速度の変化はごくわずかでした。そのため、ある形式を別の形式よりも選択する際に、コンパイルのパフォーマンスを考慮する必要はおそらくありません。
import 宣言について、最後にもう 1 つ興味深い点があります。内部クラスを使用するとします。
package P;
public class A {
public static class B {}
}
別のコンパイル単位から A にアクセスしたい場合は、次のように言います。
import P.*;
または: PA をインポートします。しかし、修飾なしで B にアクセスしたい場合は、次のように言う必要があります。
import P.A.*;
または: PAB をインポートします。これらの最初のものは、パッケージ P にあるクラス A 内で型を使用可能にします。2 番目は、パッケージ P のクラス A にある型 B のみを使用可能にします。
import xxx.* を使用しない正当な理由は、依存関係を明確に把握するためです。
ソース ファイルの先頭にリストされているため、別のパッケージの特定のクラスを使用していることをすぐに知ることができます。
私は、IDE のデフォルトを何でも使用する傾向があります。パフォーマンスへの影響はなく、依存関係のチェックはさまざまなツールで処理できるため、特に心配する必要はありません。
インポートはバイトコード レベルでは問題にならないため、実行時の違いはないはずです。
a) すべてのインポートを一覧表示して明示的にする b) IDE に管理させる。主要な IDE のいずれかで、インポートを自動的に更新、並べ替え、および完了することができます。
IDE内リファクタリングのコンテキスト外で手動で再パッケージ化を行うときに、a)が数回便利になることがわかりました。たとえば、マーケティングが製品の名前を変更し、すべてのパッケージの名前を変更する必要があると判断した場合などです。
ワイルドカードを使用したかどうかを調べるために掘り下げる必要があるのに対し、コードを読む人は、ファイルの上部にあるインポート ブロックを見るだけで、特定のクラスで使用されているクラスをすぐに知ることができるため、より良いコーディング プラクティスです。