私は数年間、新しいアプリケーションと既存のアプリケーションの移行の両方で Java 8 でコーディングしてきましたが、非常に役立つことがわかったいくつかの「ベスト プラクティス」について書く時期が来たと感じました。私は個人的に「ベスト プラクティス」という用語が好きではありません。なぜなら、それは「画一的な」ソリューションを意味するからです。コーディングの仕組みはそうではありません。どのようなソリューションが機能するかを自分で発見する必要があるからです。しかし、Java 8 コードで役立つオプションをいくつか見つけたので、見てみましょう。
Optionalは非常に過小評価されている機能であり、私たちを悩ませている多くのNullPointerExceptionを削除する可能性があります。これは、コード境界内 (使用されている API または公開されている API) 内で特に役立ちます。これにより、ユーザーと呼び出しコードが何を期待するかを推論できるようになります。
ただし、何も考えず設計せずにOptionalを適用すると、多数のクラスに影響を与え、可読性が悪化する可能性があります。ここでは、Optional を効果的に使用する方法についてのヒントをいくつか紹介します。
Optionalは戻り値の型にのみ使用する必要があります
…パラメータやフィールドではありません。幸いなことに、IntelliJ IDEA では、これらの推奨事項に従っているかどうかを確認するチェックをオンにすることができます。
オプションの値は、出現した場所で処理する必要があります。 IntelliJ IDEA の提案により、コード内の Optional リークが防止されるため、Optional を見つけた場合は忘れずに処理し、迅速に行動してください。
単に get() を呼び出すべきではありません
Optional の機能は、値が空である可能性があることを表現し、この状況に対処できるようにすることです。したがって、何かを行う前に、値があるかどうかを必ず確認してください。最初に isPresent() をチェックせずに get() を呼び出すだけでは、ある時点で null ポインタが生成される可能性があります。幸いなことに、IntelliJ IDEA にはこれを思い出させるためのチェックもあります。
もっとエレガントな方法があるかもしれません
もちろん isPresent() と get() を組み合わせるのは素晴らしいでしょう...
...しかし、よりエレガントな解決策もあります。 orElse を使用すると、値が null の場合に代替を提供できます。
…または、値が空の場合に呼び出すメソッドを orElseGet を使用して指定することもできます。これは上記の例と同じように見えますが、サプライヤー メソッドは必要な場合にのみ呼び出されるため、これが高価なメソッドである場合は、ラムダを使用した方がパフォーマンスが向上します。
ラムダ式はJava 8の主な機能の1つです。まだ Java 8 を使用したことがない場合でも、おそらくすでに Java 8 についての基本的な理解はできているでしょう。これらは Java でプログラミングする新しい方法であり、「ベスト プラクティス」が何であるかはまだ明らかではありません。ここでは私が従うべきガイドラインをいくつか紹介します。
短くしてください
関数型プログラマーは長いラムダ式のほうが満足しますが、長年 Java に没頭してきた人は、ラムダ式をわずか数行のコードに抑える方が簡単だと感じるでしょう。コードを 1 行に制限すると、長い式をメソッドに簡単にリファクタリングできます。
これらはメソッド参照になることもあります。メソッド参照は最初は少し馴染みがないように感じるかもしれませんが、特定の状況での読みやすさに役立つため、実際にはメソッド参照に固執する価値があります。これについては後で説明します。
明示的な
ラムダ式には型情報が欠落しているため、パラメーターの型情報を含めると便利な場合があります。
ご覧のとおり、今回はかなりぎこちなくなりました。したがって、私はパラメータに便利な名前を付けることを好みます。もちろん、これを行ったかどうかに関係なく、IntelliJ IDEA ではパラメーターの型情報を確認できます。
ラムダで表される関数型インターフェースも:
ラムダ式はジェネリックスに少し似ていると思います - ジェネリックスと一緒によく使用しますが(たとえば、型情報を Lista8093152e673feb7aba1828c43532094 に追加するなど)、できればメソッドを設計できますまたはジェネリック型のクラス (Person8742468051c85b06f0a0af9e3e506b5c など)。同様に、Streams API などを使用する場合はラムダ式を渡しますが、ラムダ パラメータを必要とするメソッドを作成する方がさらに良いでしょう。
しかし、もしこのような状況に陥ったなら、ここにいくつかの素晴らしいヒントがあります。
IntelliJ IDEA は関数パラメータの導入に役立ちます
これにより、オブジェクトの代わりにラムダを渡すパラメータを作成できます。この機能の利点は、既存の機能インターフェイスが仕様に一致していることを示すことです。
この結果は...
既存の関数型インターフェイスの使用
開発者が Java 8 コードに慣れるにつれ、Supplier や Consumer などのインターフェイスを使用し、ローカルの ErrorMessageCreator (例)混乱を招き、無駄が生じる可能性があります。すでに利用可能なものについては、このパッケージをご覧ください。
[email protected]/* */
本当に独自の関数インターフェースを作成する必要がある場合は、このアノテーションを使用してこのようにマークしてください。これにはあまり効果がないように見えますが、IntelliJ IDEA は、インターフェイスが関数型インターフェイスに使用される例外と一致しない場合に通知します。オーバーライドするメソッドを指定しない場合、フラグが付けられます:
メソッドを指定しすぎると、フラグが付けられます:
そして、それをインターフェイスではなくクラスに適用すると、
ラムダ式は、単一の抽象メソッドを持つ任意のインターフェイスで使用できますが、同じ基準を満たす抽象クラスでは使用できません。非論理的に思えますが、そういうことなのです。
Stream API は Java 8 のもう 1 つの大きな機能ですが、これによってコーディングの方法がどれだけ変わるかは本当にわかりません。ここでは私が役に立ったものをいくつか紹介します。
ドット演算子をキューに入れる
私は個人的にストリーム操作をキューに入れることを好みます。もちろん、これを行うと便利だとわかったので、これを行う必要はありません:
どのような操作があるかが一目でわかります
デバッグが簡単になります (ただし、IntelliJ IDEA には、多くの操作をセットアップする機能が用意されています)ラムダ式を 1 行で自由に表現 ブレークポイント機能もあるが、別の行に分割すると簡単になる)
テスト中のアクションをコメントアウト
デバッグやテストのために簡単に Peak() を挿入
また、私の見解では さあ、そのほうがすっきりします。このパターンに従った場合、コード行を減らすという点ではあまりメリットがありません。
ドット演算子を配置するには書式設定を調整する必要がある場合があります。
メソッド参照を使う
はい、この奇妙な構文に慣れるまでには時間がかかります。ただし、正しく使用すると、可読性が向上します。参照してください:
(比較的) 新しい Objects クラスのヘルパー メソッドと比較してください:
後者のコードは、どの値が保存されるかについてより明確です。 IntelliJ IDEA は通常、ラムダをメソッド参照に折りたたむことができる時期を通知します。
コレクションを反復処理するときは、可能な場合は Streams API を使用してください
…または forEach のような新しいコレクション メソッドを使用します。 IntelliJ IDEA は次のアドバイスを提供します:
一般に、Streams API を使用する方が、ループと if ステートメントを組み合わせて使用するよりも明確です。例:
IntelliJ IDEA は、これを次のようにリファクタリングできることを示唆しています:
私が行ったパフォーマンス テストでは、このリファクタリングが驚くべきものであることがわかりました。パフォーマンスは常に予測できるわけではなく、同じままで向上しており、さらに悪化しています。いつものように、アプリケーションでパフォーマンスが重要な場合は、あるスタイルを別のスタイルにコミットする前にパフォーマンスを測定してください。
配列を反復処理する場合はループを使用します
ただし、Java 8 を使用するからといって、必ずしもどこでもストリームや新しいコレクション メソッドを使用する必要があるわけではありません。 IntelliJ IDEA はストリームへの変換を提案しますが、これは「はい」と答える必要があるという意味ではありません (チェックは抑制またはオフにできることに注意してください)。
特に、プリミティブ型の小さな配列のループは、パフォーマンスを向上させるためにほぼ確実に使用され、おそらく (少なくともストリームに慣れていない Java 開発者にとっては) 読みやすくなります。
他の手法と同様、ルールは明確に設定されているわけではありませんが、可能な限り Streams API を使用するか、一部の操作にはループを使用するかを決定する必要があります。要するに、一貫性を保つことです。
私は毎日新しいことを発見していますが、好みが変わることもあります。たとえば、以前はコードでの使用を嫌い、避けていたメソッド参照などです。ぜひヒントを聞きたいです!
上記は Java 8 の 5 つの開発スキルの内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。