投稿のタイトルで提起された質問に対する詳細な回答は、2015年11月25日の文言でブルース・エクケルの記事に記載されています。 この記事の翻訳をここに投稿し、Javaでの関数型プログラミングについてどう思うか、そのような本の関連性を尋ねることにしました。
素敵な読書を！
要するに-もちろんはい。
より詳細な答えを出すために、まだ理解してみましょう。なぜ彼らと協力しているのでしょうか？
行動の抽象化基本的に、ラムダ式は、実行方法ではなく、実行する計算を記述するために必要です。 従来、私たちは外部のイテレーションを使用して作業を行いました。このイテレーションでは、操作のシーケンス全体とその実行方法を明確に示していました。
外部ループは
forループで実行され、このループはその実行方法を正確に示します。 このようなコードは冗長であり、プログラムで繰り返し再現されます。 ただし、
forEachループでは、各要素に対してプログラムを呼び出して（ここでは-ラムダよりも簡潔なメソッド参照を使用して）呼び出すように指示しますが、ループの仕組みを説明する必要はありません。 反復は
forEachループレベルで内部的に処理されます。
ラムダ式の場合の「どのようにではなく、何を」というこのような動機は基本です。 しかし、クロージャを理解するためには、関数型プログラミングの動機付けをより詳細に検討する必要があります。
関数型プログラミングラムダ式/クロージャーは、関数型プログラミングを簡素化するように設計されています。 もちろん、Java 8は関数型言語ではありませんが、（Pythonのように）関数型プログラミングのサポートを提供します。これらの機能は、基本的なオブジェクト指向のパラダイムの上に構築されています。
関数型プログラミングの基本的な考え方は、関数の作成と操作、特に実行時に関数を作成できることです。 したがって、プログラムはデータだけでなく関数でも動作できます。 プログラマーにどんな機会が開かれるか想像してみてください。
純粋に機能的なプログラミング言語には、特にデータ不変性の他の制限があります。 つまり、変数はなく、不変の値しかありません。 一見、この制限は過剰に思えます（どのように変数なしで機能しますか？）、しかし、本質的に、値の助けを借りれば、すべてが変数の場合と同じです（確認したい-Scalaを試してください、この言語は純粋に機能的ではありません、ただしどこでも値を使用する機能を提供します）。 不変関数は引数を取り、環境を変更せずに結果を返します。 したがって、不変関数は共有リソースをブロックしないため、並列プログラミングで使用する方がはるかに簡単です。
Java 8より前のバージョンでは、実行時に1つの方法で関数を作成できました。バイトコードの生成と読み込み（これはかなり複雑で複雑な作業です）。
次の2つの機能は、ラムダ式の特徴です。
- 関数を作成するためのより簡潔な構文
- 実行時に関数を作成する機能。 その後、これらの関数を別のコードに転送したり、別のコードを操作したりできます。
閉鎖は2番目の可能性に関連しています
閉鎖とは何ですか？閉じるとき、関数のスコープ外の変数が使用されます。 従来の手続き型プログラミングでは、これは問題になりません-変数を使用するだけです-しかし、実行時に関数の作成を開始するとすぐに問題が発生します。 この問題を説明するために、最初にPythonの例を示します。 ここで、
make_fun()は
make_fun()という関数を作成して返します。この関数は、プログラムの残りの部分で使用されます。
func_to_returnは、スコープ内にない2つのフィールド
nおよび
arg （特定のケースに応じて、
argはコピーまたはスコープ外の何かを参照できる）で動作することに注意してください。 Pythonデバイス自体のおかげで、非ローカル宣言は必須です。変数を操作し始めたばかりの場合、この変数はローカルであると見なされます。 ここで、コンパイラー（はい、Pythonにはコンパイラーがあり、はい、確かに、非常に限定的な静的型チェックを行います）
n += argは
func_to_returnのスコープで初期化されていないnを使用するので、メッセージが生成されますエラー。 しかし、
nが
nonlocalであると言えば、Pythonは関数のスコープ外で定義された
nを使用していると推測し、初期化されているので、すべて問題ありません。
したがって、この問題に直面しています：
func_to_return返すだけの場合、
func_to_returnの範囲外にある
nは
func_to_returnますか？ 通常、nはスコープから出てアクセスできなくなると予想されますが、その場合は
func_to_returnは機能しません。 関数の動的作成をサポートするには、
func_to_returnはnを「閉じ」て、関数が戻るまで存続するようにします。 したがって、「クロージャ」という用語。
make_fun()をテストするために、2回呼び出して、関数の結果をxとyに保存します。 xとyがまったく異なる結果を与えるという事実は、
make_fun()呼び出すたびに、
n独自の閉じたストレージで完全に独立した
func_to_return関数が
func_to_returnを示しています。
Java 8のラムダ式ラムダ式を使用した同じJavaの例を考えてみましょう。
あいまいなこと：本当にnに変えることができますが、nを変更しようとするとすぐに問題が始まります。 エラーメッセージは次のとおりです。ラムダ式から参照されるローカル変数は最終または実質的に最終でなければなりません（ラムダ式から参照されるローカル変数は最終または実際に最終でなければなりません）。
Javaのラムダ式は値の周りでのみ閉じられ、変数の周りでは閉じられないことがわかります。 Javaは、これらの値が不変であることを要求します。まるでそれらが最終宣言されているかのようです。 したがって、そのように宣言したかどうかに関係なく、最終的なものでなければなりません。 つまり、「実際の最終」です。 したがって、Javaには「完全な」クロージャーではなく「制約のあるクロージャー」がありますが、これは非常に便利です。
ヒープ上にないオブジェクトを作成する場合、コンパイラはリンク自体が変更されないことを確認するだけなので、そのようなオブジェクトを変更できます。 例：
すべてが問題なくコンパイルされます
nの定義に
finalキーワードを挿入できることを確認してください。 もちろん、このような動きを競合に適用する場合、可変共有状態に問題が発生します。
ラムダ式-少なくとも部分的に-目的を達成できます：関数を動的に作成できるようになりました。 海外に行くとエラーメッセージが表示されますが、通常これらの問題は解決できます。 出力はPythonほど単純ではありませんが、Javaのままです。 そして、最終結果は、いくつかの制限がないわけではありません（認めましょう、Javaでの結果には制限がないわけではありません）。
これらの構造が「クロージャ」だけでなく「ラムダ」と呼ばれた理由を尋ねました。すべての表示から、これらは純粋なクロージャだからです。 「閉鎖」は失敗し、過負荷の用語だと言われました。 誰かが「本当の閉鎖」と言うとき、彼はしばしば、「閉鎖」と呼ばれる実体があった最初のマスタープログラミング言語で出会った「閉鎖」を意味します。
ここではOOPとFPの論争は見られませんが、手配するつもりはありませんでした。 さらに、ここには「短所」さえありません。 OOPはデータの抽象化に適しています（Javaがオブジェクトの操作を強制する場合でも、オブジェクトを使用してタスクを解決できるという意味ではありません）。FPは動作を抽象化するためのものです。 両方のパラダイムは有用であり、私の意見では、PythonとJava 8の両方でそれらを組み合わせるとさらに便利になります。最近、純粋に機能するHaskell言語で書かれたコンバーターであるPandocを使用する機会がありました。ポジティブな印象。 したがって、純粋に関数型の言語も太陽の下での価値があります。