정확히 하나의 추상 메소드가있는 몇 개의 인터페이스가 있다고 가정합니다. 약간의 트릭이 나 람다에 대한 인터페이스 A
를 사용하여 제한하고 그렇게 할 시도에서 빌드를 실패 해킹 :특정 인터페이스에서 람다 제한
interface A {
int c();
}
interface B {
int c();
}
public class Main {
public static void main(String... args) {
A a =() -> 42;
B b =() -> 42;
}
}
짧은 질문 : 이러한 인터페이스를 갖는, 나는 그것으로 람다를 선언 할 수 있습니까? 더러운 것이 든 더러운 것이 든 환영합니다 ('더티'는 편집/바이트 코드 수준의 해킹을 의미합니다. 소스 코드와 바람직하게는 공개 계약에 영향을주지 않습니다).
긴 이야기 : 일부 인터페이스 구현 자의 경우 계약의 일부로 equals/hashCode
을 정의하는 것이 좋습니다. 또한 빌드시에 자동으로 equals/hashCode
을 생성합니다.
이 문맥에서 람다는 말썽 꾸러기입니다. 인터페이스 A
의 일반 및 익명 구현자를 위해 .class
파일을 찾고 빌드시 바이트 코드를 계측 할 수 있습니다. 람다에게는 런타임에 생성 된 VM 익명 클래스가 있습니다. 그러한 클래스에 영향을 미치는 것은 빌드시에는 불가능한 것처럼 보이기 때문에 적어도 특정 인터페이스 집합에 대해서는 그러한 경우를 금지해야합니다.
"긴 이야기"에서 이미 모든 이유를 설명했습니다. 충분히 상세하지 않니? – skapral
잘 람다는'equals'와'hashCode'를 가질 수 없으므로, 왜이 인터페이스가'@ FunctionalInterface'로 사용되는 것을 금지합니까? – Eugene
@Eugene, equals와 hashCode를 정의하면 인터페이스 'A'가 제공하는 계약의 일부라고 상상해보십시오. 그것의 javadoc에서 말하고있는 것처럼 -'인터페이스 A의 모든 구현자는 equals와 hashCode를 정의해야하고 지침은 ... 도구 X가 생성 할 수있다 '. 그리고 누군가는 람다 (lambdas)와 함께 계약을 맹렬히 깨우고 도구 X는 그것에 대해 아무 것도 할 수 없습니다. 인터페이스 'A'를 정의 할 때 함수 인터페이스라고 생각하지 않았습니다. 나는 그것이 하나의 방법을 가진 인터페이스 일 뿐이라고 원했다. – skapral