인터페이스에서 보호

interface정의의 모든 메서드가 암시 적 으로있는 이유는 무엇 public입니까? protected방법을 허용하지 않는 이유는 무엇 입니까?

인터페이스는 "클래스 외부에서 볼 수있는 것"을 의미하기 때문입니다. 비공개 메서드를 추가하는 것은 의미가 없습니다.

자주 인용되는 이유는 "인터페이스가 공용 API를 정의"하기 때문이지만, 이는 지나치게 단순화 된 것이라고 생각합니다. (그리고 그것은 순환 논리의 "냄새"이기도합니다.)

액세스 수정자가 혼합 된 인터페이스를 갖는 것은 의미가 없습니다. 예를 들어 부분적으로 공개되고 부분적으로 인터페이스와 동일한 패키지의 다른 클래스로 제한됩니다. 사실, 어떤 경우에는 IMO가 매우 유용 할 수 있습니다.

사실, 난의 일부라고 생각 추론 암시 적으로 공개 인터페이스의 제작 회원 뒤에이 있다는 것이다 는 자바 언어 간단합니다 :

• 암시 적 공용 인터페이스 멤버는 프로그래머가 처리하기가 더 간단합니다. 메소드 액세스 수정자가 무작위로 선택된 코드 (클래스)를 몇 번이나 보셨습니까? 많은 "일반"프로그래머는 Java 추상화 경계를 관리하는 가장 좋은 방법을 이해하는 데 어려움을 겪습니다 ¹ . 공용 / 보호 / 패키지-개인을 인터페이스에 추가하면 인터페이스가 더욱 어려워집니다.

• 암시 적으로 공용 인터페이스 멤버는 언어 사양을 단순화하므로 Java 컴파일러 작성자 및 Reflection API를 구현하는 사람들의 작업이됩니다.

"인터페이스가 공용 API를 정의한다"는 생각은 언어 디자인 결정을 단순화 한 결과 (또는 특성) 일 것입니다. 그 반대는 아닙니다. 그러나 실제로는 두 가지 생각이 Java 디자이너의 마음 속에서 병렬로 발전했을 것입니다.

여하튼 JDK-8179193 의 RFE에 대한 공식적인 응답 은 Java 디자인 팀이 인터페이스 를 허용 하는 것이 실질적인 이점이 거의없이 복잡성을 추가 한다고 ² 결정했음을 분명히합니다 protected. 증거 를 찾기 위해 @skomisa에게 찬사를 보냅니다 .

RFE의 증거가 문제를 해결합니다. 그것이 추가되지 않은 공식적인 이유입니다.

^{1-물론, 최고 수준의 프로그래머는 이러한 일에 어려움이 없으며 더 풍부한 액세스 제어 기능 팔레트를 환영 할 수 있습니다. 그러나 유지 관리를 위해 코드가 다른 사람에게 넘겨지면 어떻게됩니까?}

^{2-당신은 그들의 결정이나 그들의 진술 된 이유에 동의하지 않을 수 있지만 그것은 논쟁의 여지가 있습니다.}

이 질문은 Java 8의 기본 메소드 도입으로 다시 열렸다고 말해야합니다. 지금 작업중인 프로젝트는 인터페이스의 기본 특성과 유사하며 구현 의도를 추상화하기위한 것입니다.

"기본 보호"메서드를 사용하여 코드를 대폭 단순화 할 수있는 몇 가지 경우가 있습니다. 인터페이스가 여전히 Java 7 논리에 충실하기 때문에 실제로 작동하지 않는 것으로 나타났습니다. 위에서 언급 한 이유로 정상적인 보호 방법은 특별히 의미가 없습니다. 그러나 기본 공용 메서드에 변경 가능성이없고 보호 된 메서드에서 제공 할 수있는 저수준 리소스가 필요한 경우 "기본 보호"작업을 사용하면 더 깨끗한 코드를 유지할뿐만 아니라 향후 사용자를 다음으로부터 보호 할 수 있습니다. 우발적 학대.

(이것은 내가 여전히 불필요한 추상으로 내 코드를 지나치게 복잡하게 만들 필요가 있다는 사실을 비극적으로 바꾸지는 않는다. 그러나 나는 오라클에 기능 요청을 넣을 계획이다.)

인터페이스는 공용 API를 정의하기 때문입니다. 보호되는 모든 것은 인터페이스에 속하지 않는 내부 세부 사항입니다.

보호 된 추상 메서드와 함께 추상 클래스를 사용할 수 있지만 인터페이스는 공용 메서드 및 공용 정적 최종 필드로 제한됩니다.

아마도 인터페이스 이기 때문에 클라이언트에게 할 수없는 일을 알리기보다는 인스턴스로 할 수있는 일을 클라이언트에게 알리기 위해있을 수 있습니다.

나는 강하게 인터페이스 보호 방법을 허용해야한다고 생각; 인터페이스는 전 세계 모든 사람이 볼 수 있어야한다고 누가 말했습니까? "평범한"(읽기 : 무능한) 프로그래머를 혼동 할 수 있다는 점에 관해서 : OOP의 대부분은 객체, 클래스, 패키지 등을 적절하게 구성하는 것입니다. 프로그래머가 모든 작업을 제대로 수행하는 데 어려움을 겪는다면 그는 훨씬 더 큰 문제. Java는 이러한 유형을 위해 만들어졌습니다 .

여기에 몇 가지 답변은 순환 추론을 사용하여 인터페이스 메서드를 보호 할 수없는 이유를 설명합니다. 이는 공용이어야하므로 분명히 보호 할 수 없기 때문입니다!

아무 것도 설명하지 않지만 다행히도 누군가 가 몇 년 전에 인터페이스에서 보호 된 메서드에 대한 개선 요청을 JDK 버그 로 제기하여 문제에 대해 밝힙니다.

인터페이스의 보호 된 메서드 : 패키지간에 공유

수정자는 Java에서 약간 제한되어 있으므로 패키지간에 메서드를 공유하는 방법은 공용 메서드로 제한됩니다. 때로는 메소드를 공개하는 것이 위험하지만 적절한 수정자가 없기 때문에 그럴 필요가 있습니다. 내 솔루션은이 한계를 극복합니다.

Java 언어 사양은 현재 인터페이스 메서드에 대한 protected 수정자를 허용하지 않습니다. 이 사실을 활용하고이 새로운 기능에 대한 인터페이스 메서드에 protected를 사용할 수 있습니다.

인터페이스 메서드가 보호 됨으로 표시되고 인터페이스가 다른 패키지의 클래스에 의해 구현되는 경우 메서드는 공용 일 필요는 없지만 개인용이거나 적어도 패키지 보호 대상 일 수도 있습니다. 메서드는 표시됩니다. 클래스가 선언 한 것이 무엇이든 인터페이스의 소스 패키지 (및 하위 패키지?)에서 추가로 표시됩니다.

이렇게하면 잘 알려진 패키지간에 특정 방법을 공유 할 수 있습니다.

그리고 이것은 상태로 마감 된 개선 요청에 대한 응답입니다 Won't fix.

이 제안은 약간의 실제 이득을 위해 복잡성과 특별한 경우를 추가하는 방식으로 문제를 해결하려고합니다. 이 문제를 해결하는 일반적인 방법은 공용 인터페이스를 구현하는 개인 클래스를 갖는 것입니다. 구현 메서드는 공용이지만 전용 클래스 내에 있으므로 전용으로 유지됩니다.

Java 9에서 사용할 수있는 대안은 클래스와 메소드를 공개하는 것이지만 일반 대중에게 내보내는 대신 특정 "친구"모듈에 대한 정규 내보내기가있는 모듈 내에서 가능합니다.

따라서 해당 버그 보고서의 권위있는 내용은 다음과 같습니다.

• 현재 상황은 변하지 않을 것입니다. 인터페이스는 protected메소드를 지원하지 않을 것입니다 .
• protected인터페이스에서 메소드를 지원하지 않는 이유 는 " 실제 이득이 거의없는 경우 복잡성과 특수한 경우를 추가 "한다는 것 입니다.
• Java 9부터 메서드에 대한 패키지 수준 액세스를 제공하는 다른 접근 방식이 있습니다. 사용하여 자바 플랫폼 모듈 시스템 (JPMS을) 에 " "대신에 일반 대중에 수출되는 모듈 친구 메이크업 클래스와 공개 방법,하지만 특정에 자격을 갖춘 수출을 가진 모듈 내 " ".

구현 클래스는 인터페이스에 선언 된 모든 메서드를 구현해야하므로 구현 클래스가 다른 패키지에 있으면 어떻게됩니까?

인터페이스 설명했던 것과 같은 것을 사용하려면 추상 클래스 또는 중첩 인터페이스를 사용하십시오.

인터페이스 변수에 대한 코드 스타일 에서 발췌 했지만 여전히 메서드에 적용됩니다.

인터페이스는 Java 프로그래머가 자신의 애플리케이션에서 참조하고 구현하기 위해 완전히 액세스 할 수있는 API (Application Programming Interface)를 제공하기위한 것이므로 인터페이스 변수는 암시 적으로 공개됩니다. 인터페이스가 자체와 다른 Java 패키지에서 사용될 수 있기 때문에 공개 가시성을 통해 프로그램 코드가 변수에 액세스 할 수 있습니다.

내부 서브 인터페이스를 선언하는 것은 좋은 습관이지만 protected, 기술적으로는 Java의 인터페이스 에서처럼 내부 메소드를 선언 할 수 없습니다 .

물론 공용 인터페이스를 확장하는 내부 용으로 다른 인터페이스를 만들 수 있습니다.

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

InternalInterface패키지 내 에서 인터페이스를 사용할 수 있지만 PublicInterface(공용 메서드에서) 다음 의 모든 하위 유형을 허용해야합니다 .

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

패키지 외부 사용자는 PublicInterface문제없이 사용할 수 있습니다.

일반적으로 프로그래머는 유사한 상황에서 추상 클래스를 만듭니다. 그러나이 경우 다중 상속의 이점을 잃게됩니다.

의미가있는 유일한 시나리오는 동일한 패키지에 대한 가시성을 제한하려는 경우입니다. 의 다른 모든 용도는 protected적용되지 않습니다. 특히 protected메서드는 하위 항목에 대한 하위 수준 구현의 세부 정보에 대한 액세스를 제공하는 데 자주 사용됩니다. 그러나 노출 할 하위 수준 구현이 없기 때문에 인터페이스에서 선언하는 것은 의미가 없습니다.

그리고 패키지 시나리오조차도 실제로 인터페이스가 무엇인지가 아닙니다.

원하는 것을 얻으려면 두 개의 인터페이스가 필요합니다. 하나는 내부 용이고 다른 하나는 공용 API에 노출됩니다. (내부적 인 것이 가능하지만 반드시 공개적인 것을 확장하는 것은 아닙니다.) 또는 다른 사람들이 지적했듯이 추상 수퍼 클래스입니다.

보호 된 메서드는 하위 클래스가 기본 클래스를 확장하는 경우에만 항상 하위 클래스에서 액세스 할 수 있습니다.

인터페이스의 경우 하위 클래스는 인터페이스를 확장하지 않습니다. 인터페이스를 구현합니다.

보호 된 메서드는 구현이 아닌 extend 를 통해 액세스 할 수 있습니다 .

인터페이스는 외부 세계에 메서드 를 노출하기위한 것입니다 . 따라서 이러한 방법은 본질적으로 공개됩니다. 그러나 동일한 클래스 계열 내에서 추상화 를 도입하려는 경우 인터페이스와 구현 클래스 사이에 다른 수준의 추상화, 즉 추상 클래스를 만들면됩니다. 아래에 예가 나와 있습니다.

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}