1つのパッケージ内のすべてのタイプをロードするインポートを記述するオーバーヘッドに関する違いがあると思いますか(import Java.*
);特定のタイプ(つまりimport Java.lang.ClassLoader
)? 2番目の方法は、他の方法よりも使用するのが望ましい方法でしょうか?
特定のタイプのインポートとインポート。*の実行には、パフォーマンスやオーバーヘッドのコストはありません。ただし、importを使用しないことがベストプラクティスであると考えています。 。
Java APIを見てください。異なるパッケージに同じ名前の多くのクラスとインターフェースがあります。
例えば:
Java.lang.reflect.Array
Java.sql.Array
したがって、Java.lang.reflect.*
とJava.sql.*
をインポートすると、Array型で衝突が発生し、コード内で完全に修飾する必要があります。
代わりに特定のクラスをインポートすると、この手間が省けます。
これは実際には非常に悪い問題です。
あなたが書くと仮定します
import a.*;
import b.*;
...
Foo f;
クラスFooはパッケージaに存在します。
ここで、完全にコンパイルされたコードをチェックインし、6か月後、誰かがクラスFooをパッケージbに追加します。 (おそらく、最新バージョンでクラスを追加したのはサードパーティのライブラリです)。
失礼!これで、コードはコンパイルを拒否します。
Neverimport-on-demandを使用します。悪だ!
詳細については、 http://javadude.com/articles/importondemandisevil.html を参照してください。
REパフォーマンス:
import a.*;
対
import a.X;
実行時に違いはありません。コンパイラは、解決されたクラス名を生成された.classファイルに組み込みます。
マイノリティビュー:私のコードでは、いくつかのパッケージの多数のクラスと、いくつかの奇妙なクラスをあちこちで使用する傾向があります。インポートリストを小さくして、何が起こっているか一目でわかるようにしています。これを行うには、しきい値を4つのクラスに設定します。その上、Eclipseは私のコードに*を使用します。これにより、パッケージのインポートが読みやすくなり、クラスを見るときに最初に行うこととして参照する傾向があります。
名前の衝突について:競合するクラス名を持つ2つのパッケージから4つ以上のクラスをインポートする可能性は何ですか?時間が10%を超える場合は、クラスが依存するパッケージの数を検討することをお勧めします(たとえば、より小さなクラスにリファクタリングします)。
Import xxx。*を使用しないのは、明確なビジョン dependencies を持っているためです。
ソースファイルの先頭にリストされているため、別のパッケージの特定のクラスを使用していることがすぐにわかります。
さらに情報を探した後、私はこのウェブサイトに出会いました。 インポートの問題 および インポートステートメントで*を使用するとパフォーマンスに影響しますか? 。
これら2つのスタイルの間に効率の問題はありますか?おそらく、インポート宣言は実際にはプログラムに何もインポートしないため、違いはごくわずかです。コンパイルユニットの上部には暗黙的なインポートJava.lang。*があり、JDK 1.2.2のJava.langには75のクラスとインターフェースが含まれていることに注意してください。調べなければならない数千のクラス名の使用を含む、人為的な例を使用した実験では、コンパイル速度の無視できる変化が示されました。したがって、ある形式を別の形式よりも選択する場合、コンパイルのパフォーマンスをおそらく考慮すべきではありません。
輸入申告に関して関心のある最後の角度が1つあります。内部クラスを使用するとします:
package P;
public class A {
public static class B {}
}
別のコンパイルユニットからAにアクセスする場合は、次のように言います。
import P.*;
または:P.Aをインポートします。ただし、資格なしでBにアクセスする場合は、次のように言う必要があります。
import P.A.*;
または:P.A.Bをインポートします。これらの最初のものは、パッケージPで見つかったクラスA内で使用可能な型を作成します。2番目は、パッケージPでクラスAで見つかったタイプBのみを使用可能にします.
同じパッケージから20を超えるクラスをインポートする場合は、import xxx。*を使用することをお勧めします。 「クリーンコード」は、パッケージ全体のインポートにも有利です。
IDEデフォルトは何でも使用する傾向があります。パフォーマンスへの影響はなく、依存関係のチェックはさまざまなツールで処理できるため、心配する価値はありません。
インポートはバイトコードレベルでは関係ないため、実行時の違いはありません。
A)すべてのインポートをリストすることで明示的にするb)IDEで管理する。主要なIDEのいずれかがインポートを自動的に更新、ソート、および完了できるようにする。
IDE内のリファクタリングのコンテキスト外で手動で再パッケージを行う場合、a)が数回役立つことがわかりました。たとえば、マーケティングが製品の名前を変更し、すべてのパッケージの名前を変更する必要があると判断した場合などです。
コードを読んでいる人は、ファイルの先頭にあるインポートブロックを調べるだけで、特定のクラスで使用されているクラスをすぐに知ることができますが、ワイルドカードを使用したかどうかを調べるにはDigが必要です。