자바 추상 ​​인터페이스

자바 추상 ​​인터페이스

---

예를 들어보십시오 (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가이 속성을보고 그러한 사용법에 대해 경고 / 실패하기를 바랍니다.

A real example: @Service proxy under @Transnational to a @Repository need to use same basic methods however they should use different interfaces that extends this abstract interface due to @Autowired. (I call this XXXSpec interface)

---

Every interface is implicitly abstract.
This modifier is obsolete and should not be used in new programs.

[The Java Language Specification - 9.1.1.1 abstract Interfaces]

Also note that interface member methods are implicitly public abstract.
[The Java Language Specification - 9.2 Interface Members]

Why are those modifiers implicit? There is no other modifier (not even the 'no modifier'-modifier) that would be useful here, so you don't explicitly have to type it.

---

It isn't necessary. It's a quirk of the language.

---

It's not necessary, as interfaces are by default abstract as all the methods in an interface are abstract.

---

An abstract Interface is not as redundant as everyone seems to be saying, in theory at least.

An Interface can be extended, just as a Class can. If you design an Interface hierarchy for your application you may well have a 'Base' Interface, you extend other Interfaces from but do not want as an Object in itself.

Example:

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

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

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

You do not want a Class to implement the MyBaseInterface, only the other two, MMyDog and MyBoat, but both interfaces share the MyBaseInterface interface, so have a 'name' property.

I know its kinda academic, but I thought some might find it interesting. :-)

It is really just a 'marker' in this case, to signal to implementors of the interface it wasn't designed to be implemented on its own. I should point out a compiler (At least the sun/ora 1.6 I tried it with) compiles a class that implements an abstract interface.

---

Well 'Abstract Interface' is a Lexical construct: http://en.wikipedia.org/wiki/Lexical_analysis.

It is required by the compiler, you could also write interface.

Well don't get too much into Lexical construct of the language as they might have put it there to resolve some compilation ambiguity which is termed as special cases during compiling process or for some backward compatibility, try to focus on core Lexical construct.

The essence of `interface is to capture some abstract concept (idea/thought/higher order thinking etc) whose implementation may vary ... that is, there may be multiple implementation.

An Interface is a pure abstract data type that represents the features of the Object it is capturing or representing.

Features can be represented by space or by time. When they are represented by space (memory storage) it means that your concrete class will implement a field and method/methods that will operate on that field or by time which means that the task of implementing the feature is purely computational (requires more cpu clocks for processing) so you have a trade off between space and time for feature implementation.

If your concrete class does not implement all features it again becomes abstract because you have a implementation of your thought or idea or abstractness but it is not complete , you specify it by abstract class.

A concrete class will be a class/set of classes which will fully capture the abstractness you are trying to capture class XYZ.

So the Pattern is

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

참고URL : https://stackoverflow.com/questions/7202616/java-abstract-interface