この機能を言語に追加した理由について、厳密に必要ではないことが明らかになったときに、いくつかの観点を提供しましょう（すべてのメソッドrefはラムダとして表現できます）。
正解なしがあることに注意してください。 「ラムダの代わりに常にメソッドrefを使用する」または「メソッドrefの代わりに常にラムダを使用する」と言う人は無視してください。
この質問は、「名前付きクラスと匿名クラスをいつ使用する必要があるか」に非常に似ていますか？そして、答えは同じです：読みやすくなったとき。間違いなく間違いなく1つまたは間違いであるケースがありますが、中間に灰色のホストがあり、判断を使用する必要があります。
メソッドrefの背後にある理論は単純です：names matter。メソッドに名前がある場合、最終的にそれを単に回して呼び出すコードの命令バッグではなく、名前で参照すると、多くの場合（常にではありません！）より明確で読みやすくなります。
パフォーマンスや文字のカウントに関する議論は、ほとんどが赤いニシンであり、無視する必要があります。目標は、何をするのかが明確なコードを書くことです。非常に頻繁に（常にではありません！）メソッドの参照がこのメトリックで勝つため、これらの場合に使用するオプションとしてそれらを含めました。
メソッドrefが意図を明確にするか難読化するかについての重要な考慮事項は、表現されている関数の形状がコンテキストから明らかかどうかです。場合によっては（たとえばmap(Person::getLastName)）、あるものを別のものにマッピングする関数が必要であることはコンテキストから非常に明確であり、このような場合にはメソッド参照が輝いています。読者はどのような関数が記述されているのか疑問に思う;これはラムダがより長くてもより読みやすいかもしれないという警告サインである。
最後に、私たちが発見したのは、ほとんどの人が最初メソッド参照から遠ざかるということです。なぜなら、ラムダよりも新しくて奇妙だと感じるからです。それらは構文に慣れ、一般に動作を変更し、可能な場合はメソッド参照に引き寄せられます。したがって、あなた自身の主観的な「読みにくい」反応は、ほぼ間違いなく家族性バイアスの何らかの側面を伴うことに注意してください。スタイルの意見を述べる前に、両方に満足する機会を与えてください。
いくつかのステートメントで構成される長いラムダ式は、コードの読みやすさを減らす可能性があります。このような場合、メソッド内でこれらのステートメントを抽出して参照する方が適切な場合があります。
他の理由は再利用可能性かもしれません。少数のステートメントのラムダ式をコピーして貼り付ける代わりに、メソッドを作成して、コードのさまざまな場所から呼び出すことができます。