Java 인터페이스 메소드를 추상으로 선언하는 이유는 무엇입니까?
저는 오늘 Eclipse의 "풀 인터페이스"리팩토링 기능을 사용하여 기존 클래스를 기반으로 인터페이스를 만들었습니다. 대화 상자는 새로운 인터페이스의 모든 새로운 메소드를 "추상적 인"메소드로 작성하도록 제공했습니다.
그것의 이점은 무엇입니까?
인터페이스 메소드를 추상으로 선언 할 수 있다는 사실은 특별히 권장되지 않는 언어의 불필요한 기능입니다.
이클립스가 왜 그런 스타일을 지원 하는가, 왜 누군가가 자발적으로 그렇게 선택 하는가?
설명 : 인터페이스 방법이 추상적 인 이유는 묻지 않습니다. 나는 그들이 인터페이스에 있다면 어쨌든 추상적이기 때문에 왜 그것들을 추상적으로 표시하기로 선택했는지 묻고 있습니다.
에 따르면 Java 언어 사양 의 abstract인터페이스에 대한 키워드는 무효이며, 더 이상 사용할 수 있어야합니다. (9.1.1.1 항)
즉, 이전 버전과의 호환성에 대한 Java의 성향으로 인해 abstract키워드가 있는지 여부에 차이가 있을지 의심됩니다 .
이클립스에서 "그것의 이점"(인터페이스 메소드 선언에 요약 추가) 은 jdk1.3의 jdt 이클립스 컴파일러 와의 오래된 호환성 문제입니다.
1.4 이후, jdk 라이브러리는 더 이상 기본 추상 메소드를 포함하지 않습니다 (인터페이스를 구현하는 추상 클래스에서).
구현이 자신의 존재에 의존하기 때문에 Eclipse 1.3 컴파일러 진단을 속이는 것입니다.
Javac 1.3은 1.4 라이브러리 (-bootclasspath 옵션 사용)에 대해 수행을 거부합니다.
Eclipse 컴파일러는 1.4 준수 레벨 Workbench>Preferences>Java>Compiler>JDK Compliance에 있거나 (참조 ) 1.3 준수 모드를 사용하는 경우 1.3 개 이상의 클래스 라이브러리를 사용하기 때문에 현재의 대부분의 이클립스 프로젝트에서 "abstract"가 필요하지 않습니다.
로부터 자바 SE 7 JLS (Java 언어 사양) : "중복 방법의 공개 및 / 또는 추상적 인 수정을 지정, 허용하지만 스타일의 문제로 낙담하는 인터페이스에서 선언했다."
를 들어 자바 SE 5.0 : "Java 플랫폼의 이전 버전과의 호환성을 위해이가 허용되지만 스타일의 문제로, 낙담, 중복 방법에 대한 추상적 인 수정이 인터페이스에 선언 지정합니다."
인터페이스의 JLS 메소드에 따르면 기본적으로 추상적이므로 키워드가 중복됩니다. 이것을 알고, 나는 그것을 "프레젠테이션 혼란을 피하기 위해"사용하지 않을 것입니다.
참고 URL : https://stackoverflow.com/questions/641536/why-would-one-declare-a-java-interface-method-as-abstract
'development' 카테고리의 다른 글
| REST 거래? (0) | 2020.06.21 |
|---|---|
| ! = 점검 스레드는 안전한가요? (0) | 2020.06.21 |
| ARC 가능 코드에서 "이 블록에서 [오브젝트]를 강력하게 캡처하면 유지주기가 발생할 수 있습니다." (0) | 2020.06.21 |
| SQL Server에서 상수 1 또는 0으로 비트를 암시 (0) | 2020.06.21 |
| .toArray (new MyClass [0]) 또는 .toArray (new MyClass [myList.size ()])? (0) | 2020.06.21 |