メソッドの静的インポートは良いアイデアではなかったというレビューコメントを受け取りました。静的インポートは、ほとんどが静的メソッドである DA クラスのメソッドのインポートでした。そのため、ビジネス ロジックの途中に、現在のクラスに属していると思われる da アクティビティがありました。
import static some.package.DA.*;
class BusinessObject {
void someMethod() {
....
save(this);
}
}
レビュー担当者はコードの変更にあまり乗り気ではなく、私も変更しませんでしたが、彼の意見にはある程度同意しています。静的インポートを行わなかった理由の 1 つは、メソッドが定義されている場所がわかりにくいことでした。メソッドは現在のクラスにもスーパークラスにも定義されていなかったため、定義を特定するのに時間がかかりました (Web ベースのレビュー システムには、IDE のようなクリック可能なリンクがありません :-)。これはあまり問題ではないと思います。静的インポートはまだ非常に新しいため、すぐに見つけることに慣れるでしょう。
しかし、私が同意するもう 1 つの理由は、修飾されていないメソッド呼び出しは現在のオブジェクトに属しているようで、コンテキストをジャンプすべきではないということです。しかし、それが本当に属しているのであれば、そのスーパークラスを拡張するのは理にかなっています。
そうするときするメソッドを静的にインポートするのは理にかなっていますか? いつそれを行いましたか? 修飾されていない呼び出しの見た目は気に入りましたか?
編集: 一般的な意見は、現在のクラスのメソッドと混同する人がいなければ、メソッドを静的にインポートするというものと思われます。たとえば、java.lang.Math や java.awt.Color のメソッドなどです。しかし、abs と getAlpha が曖昧でないなら、readEmployee が曖昧な理由がわかりません。多くのプログラミングの選択肢と同様に、これも個人の好みの問題だと思います。
ベストアンサー1
これは、Sun がこの機能をリリースしたときのガイドからの抜粋です (強調は原文のまま):
では、静的インポートはいつ使用すればよいのでしょうか?非常に控えめに！定数のローカル コピーを宣言したり、継承を乱用したり (定数インターフェイスのアンチパターン) する誘惑にかられる場合にのみ、これを使用してください。... 静的インポート機能を過度に使用すると、インポートしたすべての静的メンバーで名前空間が汚染され、プログラムが読みにくくなり、保守できなくなります。コードを読む人 (コードを作成してから数か月後のあなた自身も含む) は、静的メンバーがどのクラスからのものかわかりません。クラスからすべての静的メンバーをインポートすると、特に読みやすさに悪影響を与える可能性があります。必要なメンバーが 1 つまたは 2 つだけの場合は、個別にインポートしてください。
（静的インポート）
特に指摘したい部分が 2 つあります。
- 静的インポートを使用するのみ「継承を乱用」したくなったとき。この場合、 BusinessObject を使用する誘惑に駆られたでしょうか
extend some.package.DA? もしそうなら、静的インポートはこれを処理するよりクリーンな方法かもしれません。 を拡張することを夢にも思わなかったならsome.package.DA、これはおそらく静的インポートの不適切な使用法です。入力時に数文字を節約するためだけに使用しないでください。 - 個々のメンバーをインポートします。
import static some.package.DA.saveの代わりに と言いましょうDA.*。こうすることで、インポートされたメソッドがどこから来ているのかがずっと簡単にわかるようになります。
個人的に、私はこの言語機能を使ってきましたとてもめったにありませんが、ほとんどの場合、定数または列挙型でのみ使用され、メソッドでは決して使用されません。私にとって、トレードオフはほとんど価値がありません。