回答。

Javaにおける関数型プログラミングは、ラムダ式と関数型インターフェースの導入（Java 8から）により発展しました。

問題の歴史

Java 8以前は、すべてのインターフェースが抽象メソッドの集まりであり、パラダイムはOOP（オブジェクト指向プログラミング）に焦点を当てていました。関数型インターフェースとラムダ式の導入により、より簡潔なコードを書くことができ、FP（関数型プログラミング）の原則に従うことが可能になり、コードの可読性と表現力が向上しました。

問題

イベント処理、コレクション、または非同期ロジックに関連するコードは冗長になりがちで、別のクラスや匿名内部クラスを作成する必要がありました。これにより、コードの保守性やスケーラビリティが困難になりました。

解決策

関数型インターフェースは、正確に1つの抽象メソッドを持つインターフェースです。これはラムダ式のターゲットとして使用することができます。標準ライブラリには、Function<T, R>、Predicate<T>、Supplier<T>、Consumer<T>などの典型的な関数型インターフェースがあり、独自のインターフェースを作成することも可能です。

コード例：

import java.util.function.Function;

public class FunctionalExample {
    public static void main(String[] args) {
        // 標準の関数型インターフェースFunction
        Function<String, Integer> stringLength = s -> s.length();
        System.out.println(stringLength.apply("Java")); // 4と表示されます
    }
}

主な特徴：

簡潔なラムダ式を使用できます。
特にストリーム操作において可読性が大幅に向上します。
ボイラープレートコードを防ぎ、イベント処理やフィルタリング、コレクションの操作を洗練されたものにします。

ひっかけ問題。

関数型インターフェースを、他のメソッドがデフォルト実装や静的である場合に複数の抽象メソッドを持つように宣言できますか？

いいえ、関数型インターフェースは1つの抽象メソッドしか含むことができません。デフォルトメソッド（default）や静的メソッドを持つことは許可されています。

関数型インターフェースを、複数の抽象メソッドを持つ別のインターフェースから継承できますか？

いいえ、最終的なインターフェースが1つ以上の抽象メソッドを持つ場合、それは関数型インターフェースではなくなり、ラムダ式の代入に使用することはできません。

Javaの関数型インターフェースは、C#など他の言語のSAMインターフェースとどのように異なりますか？

Javaには、@FunctionalInterfaceアノテーションが導入される前にSAMインターフェースを宣言するための直接的なキーワードはありません。C#とは異なり、delegateがシグネチャを明確に指定するのに対して、Javaでは1つの抽象メソッドとオプションのアノテーションだけでコンパイラが対応できます。

よくある誤りとアンチパターン

@FunctionalInterfaceアノテーションの忘却 — インターフェースが関数型でなくなると、コンパイラはすぐにはエラーを出しません。
インターフェースに抽象メソッドを無意識に追加し、それが機能を損なうこと。
振る舞いが論理の表現ではなくエンティティを記述する場合にラムダを使用すること（可読性の喪失）。

実生活の例

ネガティブなケース

大規模なプロジェクトで、ビジネスロジックに直接関係のないデータを示すエンティティでもラムダを広く使用することに決定しました。その結果、複雑なロジックの追跡が困難になり、ラムダがコードの意図を隠し、デバッグが難しくなりました。

利点：

簡潔なコード。
ボイラープレートが減少。

欠点：

可読性の喪失。
インターフェースの変更時のエラー。

ポジティブなケース

別のプロジェクトでは、関数型プログラミングに適したインターフェースを慎重に分析しました。コレクションやイベントの処理にPredicate、Function、および独自のインターフェースを使用しました。エンティティとデータストレージにはFPを適用しませんでした。