ラムダ式には、コード行を保存する以外の用途がありますか？

ラムダ式には、コード行を保存する以外の用途がありますか？

簡単に解決できない問題を解決するラムダの特別な機能はありますか？私が見た典型的な使用法はこれを書く代わりに：

Comparator<Developer> byName = new Comparator<Developer>() {
  @Override
  public int compare(Developer o1, Developer o2) {
    return o1.getName().compareTo(o2.getName());
  }
};

ラムダ式を使用してコードを短縮できます。

Comparator<Developer> byName =
(Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName());

ラムダ式は、Javaで一般的に解決できる一連の問題を変更しませんが、特定の問題の解決を確実に容易にします。これは、私たちがアセンブリ言語でプログラミングしていないのと同じ理由からです。プログラマーの作業から冗長なタスクを削除することで、作業が楽になり、（手動で）作成する必要があるコードの量だけのために、他の方法では触れられないことも実行できます。

しかし、ラムダ式はコード行を節約するだけではありません。ラムダ式を使用すると、以前に回避策として匿名の内部クラスを使用できた関数を定義できます。そのため、これらのケースでは匿名の内部クラスを置き換えることができますが、一般的にはできません。

特に、ラムダ式は、変換先の機能インターフェイスとは独立して定義されているため、アクセスできる継承されたメンバーはなく、機能インターフェイスを実装する型のインスタンスにはアクセスできません。ラムダ式の中で、thisそしてsuper周囲の文脈におけるものと同じ意味を持ち、また参照のこの答えを。また、周囲のコンテキストのローカル変数をシャドウする新しいローカル変数を作成することもできません。関数を定義するという意図されたタスクでは、これにより多くのエラーソースが削除されますが、他のユースケースでは、関数型インターフェイスを実装していてもラムダ式に変換できない匿名の内部クラスが存在する可能性があることも意味します。

さらに、構成 new Type() { … }newは、常に新しいインスタンスを生成することを保証します。匿名の内部クラスインスタンスは、非staticコンテキストで作成された場合、常に外部インスタンスへの参照を保持します。これとは対照的に、ラムダ式は唯一の参照キャプチャthis、彼らがアクセスした場合、すなわち、必要なときにthisまたは非staticメンバー。そして、意図的に指定されていないIDのインスタンスを生成します。これにより、実装は既存のインスタンスを再利用するかどうかを実行時に決定できます（「ラムダ式は、実行されるたびにヒープ上にオブジェクトを作成しますか？」も参照してください）。

これらの違いは、例に適用されます。匿名の内部クラスコンストラクトは常に新しいインスタンスを生成しますが、外部インスタンスへの参照をキャプチャすることもありますが、(Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName())が、通常の実装ではシングルトンに評価される非キャプチャラムダ式です。さらに、.classハードドライブにファイルを作成しません。

セマンティックとパフォーマンスの両方の違いを考えると、ラムダ式は、もちろん、新しいAPIが新しい言語機能を利用した関数型プログラミングのアイデアを取り入れているため、将来の特定の問題の解決方法を変える可能性があります。Java 8のラムダ式とファーストクラスの値もご覧ください。

プログラミング言語は、マシンが実行するためのものではありません。

彼らはプログラマが考えるためのものですです。

言語は、私たちの考えをマシンが実行できるものに変えるためのコンパイラとの会話です。他の言語から、それに来る（または人からのJavaについての主訴の一つ残して、それをするために他の言語では）それということに使用される力プログラマに一定のメンタルモデルを（つまり、すべてがクラスです）。

それが良いのか悪いのかを検討するつもりはありません。すべてがトレードオフです。しかし、Java 8ラムダにより、プログラマーは関数の観点から考えることができますことができます。これは、以前はJavaでは不可能でした。

手続き型プログラマが考えることを学ぶのと同じことですがJavaに関してクラスの観点です。構造化された構造体であるクラスから徐々に移動し、一連の静的メソッドを持つ「ヘルパー」クラスがあり、より合理的なOO設計に似ています（平均culpa）。

匿名の内部クラスを表現するためのより短い方法としてそれらを単に考えれば、おそらく上記の手続き型プログラマーがクラスが大きな改善であるとは考えなかったのと同じように、それらを非常に印象的に見つけることはできないでしょう。

コード行の保存は、他の人が読んで理解するのにかかる時間がかからない、より短時間で明確な方法で大量のロジックを記述できる場合、新機能と見なすことができます。

ラムダ式（またはメソッド参照、あるいはその両方）Streamがなければ、パイプラインははるかに読みにくくなります。

たとえば、Stream各ラムダ式を匿名クラスインスタンスに置き換えた場合、次のパイプラインがどのように見えるかを考えてください。

List<String> names =
    people.stream()
          .filter(p -> p.getAge() > 21)
          .map(p -> p.getName())
          .sorted((n1,n2) -> n1.compareToIgnoreCase(n2))
          .collect(Collectors.toList());

それはそのようになります：

List<String> names =
    people.stream()
          .filter(new Predicate<Person>() {
              @Override
              public boolean test(Person p) {
                  return p.getAge() > 21;
              }
          })
          .map(new Function<Person,String>() {
              @Override
              public String apply(Person p) {
                  return p.getName();
              }
          })
          .sorted(new Comparator<String>() {
              @Override
              public int compare(String n1, String n2) {
                  return n1.compareToIgnoreCase(n2);
              }
          })
          .collect(Collectors.toList());

これはラムダ式のバージョンよりも書くのがはるかに難しく、エラーが発生しやすくなります。理解するのも難しいです。

そして、これは比較的短いパイプラインです。

ラムダ式やメソッド参照なしでこれを読みやすくするには、ここで使用されているさまざまな機能インターフェイスインスタンスを保持する変数を定義する必要があり、パイプラインのロジックが分割され、理解が難しくなります。

内部反復

Javaコレクションを反復するとき、ほとんどの開発者は要素を取得して処理する傾向があります。これは、その項目を取り出してから使用するか、再挿入するなどです。Javaの8より前のバージョンでは、内部クラスを実装して次のようなことができます。

numbers.forEach(new Consumer<Integer>() {
    public void accept(Integer value) {
        System.out.println(value);
    }
});

Java 8を使用すると、次のことを行うことで、より優れた冗長な操作を実行できます。

numbers.forEach((Integer value) -> System.out.println(value));

以上

numbers.forEach(System.out::println);

引数としての動作

次のケースを推測してください：

public int sumAllEven(List<Integer> numbers) {
    int total = 0;

    for (int number : numbers) {
        if (number % 2 == 0) {
            total += number;
        }
    } 
    return total;
}

Java 8 Predicateインターフェースを使用すると、次のようにすることができます。

public int sumAll(List<Integer> numbers, Predicate<Integer> p) {
    int total = 0;

    for (int number : numbers) {
        if (p.test(number)) {
            total += number;
        }
    }
    return total;
}

次のように呼び出す：

sumAll(numbers, n -> n % 2 == 0);

出典：DZone-Javaでラムダ式が必要な理由

次のように、内部クラスの代わりにラムダを使用することには多くの利点があります。

• 言語構文のセマンティクスを追加せずに、コードをよりコンパクトで表現力のあるものにします。あなたはすでにあなたの質問に例を挙げました。

• ラムダを使用することで、コレクションのマップリデュース変換など、要素のストリームに対する関数スタイルの操作を使用してプログラミングできます。java.util.functionおよびjava.util.streamパッケージのドキュメントを参照してください。

• コンパイラーによってラムダ用に生成される物理クラスファイルはありません。したがって、提供されるアプリケーションが小さくなります。メモリはどのようにラムダに割り当てますか？

• ラムダがスコープ外の変数にアクセスしない場合、コンパイラはラムダの作成を最適化します。つまり、ラムダインスタンスはJVMによって一度だけ作成されます。詳細については、質問に対する@Holgerの回答をご覧ください。Java8 では、メソッド参照キャッシュは良いアイデアですか？ 。

• Lambdasは、関数型インターフェースに加えてマルチマーカーインターフェースを実装できますが、匿名の内部クラスはそれ以上のインターフェースを実装できません。次に例を示します。

  //                 v--- create the lambda locally.
  Consumer<Integer> action = (Consumer<Integer> & Serializable) it -> {/*TODO*/};

ラムダは、匿名クラスの構文糖衣です。

ラムダの前は、匿名クラスを使用して同じことを実現できます。すべてのラムダ式は匿名クラスに変換できます。

IntelliJ IDEAを使用している場合は、変換を実行できます。

• ラムダにカーソルを置きます
• Alt / Option + Enterを押します

あなたの質問に答えるために、実際の問題は、ラムダでは java-8より前にできなかったことは何もできないようにすることです。むしろ、より簡潔なコードを書くことができます。これの利点は、コードがより明確でより柔軟になることです。

まだ言及していませんが、ラムダを使用すると、使用する機能を定義できます。。

したがって、いくつかの単純な選択関数がある場合は、ボイラープレートの束を使用して別の場所に配置する必要はなく、簡潔でローカルに関連するラムダを記述するだけです。

はい、多くの利点があります。

• クラス全体を定義する必要はなく、参照として関数の実装自体を渡すことができます。
  • 内部でクラスを作成すると.classファイルが作成されますが、ラムダを使用する場合、ラムダではクラスではなく関数の実装を渡すため、クラスの作成はコンパイラーによって回避されます。
• コードの再利用性は以前よりも高い
• そしてあなたが言ったように、コードは通常の実装よりも短いです。