반환 값이 있는 메서드 참조를 Java의 소비자 인터페이스에 할당할 수 있는 이유는 무엇입니까?

소비자 인터페이스를 사용한 메소드 참조 이해

Java에서는 메소드 참조를 사용하여 기능적 인터페이스의 인스턴스를 생성할 수 있습니다. 그러나 특정 시나리오에서는 메서드 참조의 반환 유형이 Consumer 인터페이스의 accept 메서드와 일치하지 않으면 혼란이 발생할 수 있습니다.

다음 코드를 고려하세요.

Consumer<String> lambda1 = s -> {};
Function<String, String> lambda2 = s -> s;

Consumer<String> lambda3 = LambdaTest::consume; // but s -> s doesn't work!
Function<String, String> lambda4 = LambdaTest::consume;

예상할 수도 있지만 소비 메서드(문자열)의 반환 유형이 수락의 예상 void 유형과 일치하지 않기 때문에 소비자에 대한 Lambda3 할당이 실패해야 합니다.

그런데 놀랍게도 Lambda3의 할당은 성공합니다. 이는 메서드를 호출할 수 있는 것과 동일한 방식으로 기능적 인터페이스에 메서드를 적용할 수 있도록 하는 설계 결정 때문입니다. 즉, 모든 값 반환 메서드를 소비자에 할당할 수 있으며 해당 반환 값은 무시됩니다.

람다 식의 경우 규칙이 약간 더 복잡합니다. 람다 표현식에는

1. (args) -> 표현식
2. (args) -> { 명령문* }

첫 번째 형식((args) -> 표현식)은 표현식이 값으로 평가되는 경우에만 값 호환이 가능합니다. 두 번째 형식((args) -> { 문* })은 값을 반환하려고 시도하는 코드 경로가 없는 경우 호환되지 않을 수 있습니다.

표현식 s -> s는 명령문이 아니기 때문에 s는 void 호환이 아닙니다. 그러나 메소드 호출과 같은 부작용이 있는 표현식은 명령문으로 사용될 수 있습니다. 이는 s -> s.toString() 및 s -> i는 void 호환 가능합니다.

따라서 LambdaTest::consume의 경우 소비 메소드를 호출할 수 있고 해당 반환 값을 무시할 수 있으므로 메소드 참조가 Consumer 인터페이스에 할당됩니다. 이러한 설계 결정을 통해 반환 유형이 일치하지 않는 경우에도 메서드와 기능 인터페이스 간의 적응성이 가능해졌습니다.

위 내용은 반환 값이 있는 메서드 참조를 Java의 소비자 인터페이스에 할당할 수 있는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!