자바 추상 ​​인터페이스

예를 들어보십시오 (Java로 컴파일)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

인터페이스를 "선언"해야하는 이유는 무엇입니까? 추상 인터페이스에 적용되는 다른 규칙이 있습니까?

마지막으로 : abstract더 이상 사용되지 않는 경우 왜 Java에 포함됩니까? 추상 인터페이스에 대한 이력이 있습니까?

인터페이스를 "선언"해야하는 이유는 무엇입니까?

그렇지 않습니다.

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

인터페이스와 해당 메소드는 내재적으로 abstract있으며 수정자를 추가해도 아무런 차이가 없습니다.

추상 인터페이스에 적용되는 다른 규칙이 있습니까?

아니요, 동일한 규칙이 적용됩니다. 이 방법은 (구체적인) 구현 클래스로 구현해야합니다.

초록이 더 이상 사용되지 않으면 왜 Java에 포함됩니까? 추상 인터페이스에 대한 이력이 있습니까?

흥미로운 질문입니다. 나는 JLS 의 첫 번째 판을 찾았고 심지어 "이 수정자는 더 이상 사용되지 않으며 새로운 Java 프로그램에서 사용되어서는 안된다" 고 말합니다 .

좋아, 더 파고 ... 많은 깨진 링크를 친 후, 나는 원래의 오크 0.2 사양 (또는 "수동") 의 사본을 찾을 수있었습니다 . 내가 말해야 할 매우 흥미로운 읽을 거리와 총 38 페이지! :-)

섹션 5, 인터페이스에서 다음 예제를 제공합니다.

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

그리고 여백에

앞으로 인터페이스에서 메소드 선언의 "= 0"부분이 사라질 수 있습니다.

키워드 =0로 대체 되었다고 가정하면 인터페이스 메소드에 대해 필수 사항 abstract이라고 생각합니다 abstract.

관련 기사 : Java : 추상 인터페이스 및 추상 인터페이스 메소드

public인터페이스 메소드 와 마찬가지로 필요하지 않으며 선택 사항 입니다.

이에 대한 JLS를 참조하십시오.

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 추상 인터페이스 모든 인터페이스는 암시 적으로 추상입니다. 이 수정자는 더 이상 사용되지 않으며 새 프로그램에서 사용해서는 안됩니다.

과

9.4 추상 메소드 선언

[...]

이전 버전의 Java 플랫폼과의 호환성을 위해 스타일에 따라 인터페이스에 선언 된 메소드에 대한 추상 수정자를 중복 지정하는 것이 허용되지만 권장되지 않습니다.

인터페이스 방법에 대해 공개 수정자를 중복 지정하는 것은 허용되지만 스타일 문제로 강력히 권장하지 않습니다.

인터페이스 추상을 선언 할 필요는 없습니다.

모든 인터페이스를 공개 (인터페이스가 공개 인 경우) 또는 추상 (이미 인터페이스에있는) 메소드를 선언하는 것처럼 중복됩니다.

그러나 아무도 당신을 막을 수 없습니다.

명시 적으로 말할 수 있지만 다음과 같은 것은 아닙니다.

• 생성자의 첫 번째 줄에서 super ()를 호출하십시오.
• extends Object
• 상속 된 인터페이스 구현

추상 인터페이스에 적용되는 다른 규칙이 있습니까?

인터페이스는 이미 "추상적"입니다. 해당 키워드를 다시 적용해도 아무런 차이가 없습니다.

봄에는 학문적 의미가 없다는 점에 유의하십시오. 추상 인터페이스는 개발자에게이를 사용하지 말 것을 경고하는 것입니다 @Autowired. 나는 그 봄 / 일식을 바랍니다@Autowired 가이 속성을보고 그러한 사용법에 대해 경고 / 실패하기를 바랍니다.

실제 예 : @Transnational에서 @Repository로 @Service 프록시는 동일한 기본 메소드를 사용해야하지만로 인해이 추상 인터페이스를 확장하는 다른 인터페이스를 사용해야합니다 @Autowired. (이 XXXSpec 인터페이스라고 부릅니다)

모든 인터페이스는 암시 적으로 추상적입니다.
이 수정자는 더 이상 사용되지 않으며 새 프로그램에서 사용해서는 안됩니다.

[Java 언어 사양-9.1.1.1 abstract인터페이스]

또한 인터페이스 멤버 메소드는 암시 적 public abstract입니다.
[Java 언어 사양-9.2 인터페이스 멤버]

왜 이러한 수정자가 암시 적입니까? 여기에 유용한 다른 수정 자 ( ' no modifier'- modifier도 없음)가 없으므로 명시 적으로 입력 할 필요가 없습니다.

필요하지 않습니다. 언어의 특징입니다.

인터페이스의 모든 메소드가 추상적이므로 인터페이스는 기본적으로 추상적이므로 필요하지 않습니다.

이론상으로 추상 인터페이스는 모든 사람이 말하는 것처럼 중복되지 않습니다.

클래스처럼 인터페이스를 확장 할 수 있습니다. 응용 프로그램의 인터페이스 계층 구조를 디자인하면 '기본'인터페이스가있을 수 있습니다. 다른 인터페이스를 확장하지만 객체 자체는 원하지 않습니다.

예:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

클래스가 MyBaseInterface를 구현하는 것을 원하지 않고 다른 두 MMyDog 및 MyBoat 만 구현하지만 두 인터페이스 모두 MyBaseInterface 인터페이스를 공유하므로 'name'속성이 있습니다.

나는 그것의 일종의 학문을 알고 있지만, 나는 그것이 흥미로울 것이라고 생각했다. :-)

이 경우 실제로 구현 된 것이 아닌 인터페이스의 구현 자에게 신호를 보내는 것은 실제로 '마커'일뿐입니다. 컴파일러를 지적해야합니다 (적어도 sun / ora 1.6으로 시도해 보았습니다)는 추상 인터페이스를 구현하는 클래스를 컴파일합니다.

'Abstract Interface'는 어휘 구조입니다 : http://en.wikipedia.org/wiki/Lexical_analysis .

컴파일러에서 필요하며을 쓸 수도 있습니다 interface.

컴파일 과정에서 특수한 경우 또는 이전 버전과의 호환성을 위해 컴파일 모호성을 해결하기 위해 언어의 Lexical 구성에 너무 많이 들어 가지 마십시오. 핵심 Lexical 구성에 중점을 두십시오.

`인터페이스의 본질은 구현이 다양 할 수있는 추상 개념 (아이디어 / 생각 / 고차적 사고 등)을 포착하는 것입니다. 즉, 다중 구현이있을 수 있습니다.

인터페이스는 캡처하거나 나타내는 객체의 기능을 나타내는 순수한 추상 데이터 형식입니다.

기능은 공간 또는 시간으로 표현할 수 있습니다. 공간 (메모리 저장 장치)으로 표시되면 구체적인 클래스가 해당 필드 또는 시간에 따라 작동하는 필드 및 메소드 / 메소드를 구현한다는 것을 의미합니다. 즉, 기능을 구현하는 작업은 전적으로 계산적입니다 (더 많은 CPU 클럭이 필요함) 처리를 위해) 따라서 기능 구현을위한 공간과 시간 사이의 균형을 유지해야합니다.

구체적인 클래스가 모든 기능을 구현하지 않으면 생각이나 아이디어 또는 추상적 구현이 완료되었지만 완전하지 않기 때문에 다시 추상화됩니다. abstract . 클래스 .

구체적 클래스는 클래스 XYZ를 캡처하려는 추상화를 완전히 캡처하는 클래스 / 클래스 세트입니다.

패턴은

Interface--->Abstract class/Abstract classes(depends)-->Concrete class