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