インターフェースで保護

interface定義内のすべてのメソッドが暗黙的にあるのはなぜpublicですか？protectedメソッドが許可されないのはなぜですか？

なぜなら、インターフェースは「クラスの外から見えるもの」を意味することになっているからです。非公開メソッドを追加しても意味がありません。

よく引用される理由は「インターフェースがパブリックAPIを定義する」ということですが、それは単純化しすぎだと思います。（そして、それは循環論理の「におい」も。）

アクセス修飾子が混在するインターフェースがあることは無意味ではありません。たとえば、一部はパブリックで、一部はインターフェースと同じパッケージ内の他のクラスに制限されています。実際、これは場合によっては非常に便利なIMOです。

実際、インターフェースのメンバーを暗黙的にパブリックにする理由の一部は、Java言語を単純にすることだと思います。

• 暗黙的にパブリックインターフェイスメンバーを使用すると、プログラマーが処理しやすくなります。メソッドアクセス修飾子がランダムに選択されたコード（クラス）を何回目にしましたか？多くの「普通の」プログラマーは、Java抽象化境界を管理する最善の方法を理解することが困難です¹。インターフェイスにpublic / protected / package-privateを追加すると、インターフェイスがさらに難しくなります。

• 暗黙的なパブリックインターフェースメンバーは、言語仕様を単純化します。そのため、Javaコンパイラの作成者と、Reflection APIを実装する人々の作業が簡素化されます。

「インターフェースがパブリックAPIを定義する」という考え方は、おそらく、言語設計の決定を単純化した結果（または特性）であり、逆ではありません。しかし実際には、Java設計者の頭の中では、おそらく2つの考え方が並行して発展してきました。

いずれにしても、中RFEに公式対応JDK-8179193それは、Javaの設計チームが決めたことを明らかにし^2を許可することをprotectedインターフェイス上では少しの本当の利益のために複雑になります。証拠を見つけたことを@skomisaに感謝します。

RFEの証拠が問題を解決します。それが追加されていない公式の理由です。

^{1-もちろん、一流のプログラマーはこれらのことについて問題はなく、アクセス制御機能の豊富なパレットを歓迎するかもしれません。しかし、彼らのコードが他の誰かに引き渡されて維持されるとどうなりますか？}

^{2-あなたは彼らの決定または彼らの述べられた推論に同意しないかもしれませんが、それは愚かです。}

この質問は、Java 8のデフォルトメソッドの導入によって再開されたと言わざるを得ません。現在取り組んでいるプロジェクトは、インターフェースの基本的な性質と同様に、実装から意図を抽象化することを目的としています。

「デフォルトの保護」メソッドを使用してコードを大幅に簡略化できる場合がいくつかあります。インターフェースは依然としてJava 7ロジックに固執しているため、実際には機能しないことがわかりました。上記の理由から、通常の保護されたメソッドは特に意味がありません。しかし、デフォルトのパブリックメソッドが、変更される可能性が低く、保護されたメソッドによって提供できる低レベルのリソースを必要とする場合、「デフォルトの保護」機能を使用すると、よりクリーンなコードが維持されるだけでなく、将来のユーザーが保護されます。偶発的な虐待。

（これにより、コードを過度に複雑にする必要があるという事実は変わりませんが、不要な要約を使用します。ただし、機能のリクエストをOracleに送信するつもりです。）

インターフェイスがパブリックAPIを定義しているためです。保護されているものはすべて、インターフェースに属さない内部の詳細です。

保護された抽象メソッドで抽象クラスを使用できますが、インターフェースはパブリックメソッドとパブリック静的最終フィールドに制限されています。

おそらく、それはインターフェースであるため、つまり、クライアントにインスタンスで何ができるかを伝えるのではなく、何ができないかをクライアントに伝えるためです。

インターフェイスは保護されたメソッドを許可するべきだと私は強く感じています。インターフェースは全世界の誰にでも見えるようにすべきだと誰が言ったのですか？「通常の」（read：incompetent）プログラマーを混乱させる可能性があるという点について：OOPの多くは、オブジェクト、クラス、パッケージなどを適切に構造化することです。はるかに大きな問題。Javaはその種のもののために構築されました。

ここでのいくつかの回答では、循環メソッドを使用して、インターフェイスメソッドを保護できない理由を説明しています。

それは何の説明にもなりませんが、幸いなことに、数年前に誰かがインターフェースの保護されたメソッドの拡張リクエストをJDKバグとして提起し、問題に光を当てました：

インターフェイスの保護されたメソッド：パッケージ間で共有

Javaでは修飾子が少し制限されているため、パッケージ間でメソッドを共有する方法はパブリックメソッドに制限されています。メソッドを公開するのは危険な場合がありますが、適切な修飾子がないために必要です。私のソリューションはこの制限を克服しています。

現在、Java言語仕様では、インターフェースメソッドの保護修飾子を許可していません。この事実を利用して、この新しい機能のインターフェースメソッドにprotectedを使用できます。

インターフェースメソッドが保護されているとマークされていて、インターフェースが別のパッケージのクラスによって実装されている場合、メソッドはパブリックである必要はありませんが、プライベートまたは少なくともパッケージで保護されている可能性もあります。メソッドは表示されますが、クラスがそれを宣言し、さらにインターフェイスのソースパッケージ（およびサブパッケージ）で表示されるものは何ですか。

このようにして、よく知られたパッケージ間で特定のメソッドを共有できます。

そして、これはステータスで閉じられたその拡張リクエストへの応答Won't fixです：

この提案は、実際の利益がほとんど得られない複雑さと特殊なケースを追加する方法で問題を解決しようとします。この問題を解決する一般的な方法は、パブリックインターフェイスを実装するプライベートクラスを用意することです。実装メソッドはパブリックですが、プライベートクラス内にあるため、プライベートのままです。

Java 9以降で利用可能な代替手段は、クラスとメソッドをパブリックにすることですが、一般的なパブリックにエクスポートされるのではなく、特定の「フレンド」モジュールへの限定エクスポートを持つモジュール内にあります。

したがって、そのバグレポートからの信頼できるポイントは次のとおりです。

• 現在の状況は変わりません。インターフェイスがprotectedメソッドをサポートすることはほとんどありません。
• protectedインターフェイスでメソッドをサポートしないことの正当性は、「実際の利益がほとんどないために複雑さと特別なケースが追加される」ことです。
• Java 9以降、パッケージレベルのメソッドへのアクセスを提供するための代替アプローチがあります。Javaプラットフォームモジュールシステム（JPMS）を使用して、「クラスとメソッドをパブリックにしますが、一般のパブリックにエクスポートするのではなく、特定の「フレンド」モジュールに限定エクスポートされたモジュール内で使用します。

実装クラスはインターフェースで宣言されたすべてのメソッドを実装する必要があるため、実装クラスが別のパッケージにある場合はどうなりますか？

インターフェイス説明したようなものを使用したい場合は、抽象クラスまたはネストされたインターフェイスを使用してください。

インターフェイススタイルに関するコードスタイルの抜粋ですが、メソッドにも適用されます。

インターフェースは、Javaプログラマーが自分のアプリケーションで参照および実装するために完全にアクセス可能なアプリケーションプログラミングインターフェース（API）を提供することを目的としているため、インターフェース変数は暗黙的にパブリックです。インターフェースは独自のものとは異なる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子孫の下位レベルの実装の詳細へのアクセスを提供するためにメソッドがよく使用されます。しかし、公開する下位レベルの実装がないため、インターフェースで宣言することは意味がありません。

そして、パッケージのシナリオでさえ、実際のインターフェースとは異なります。

おそらく必要なことを実現するには、2つのインターフェイスが必要です。1つは内部で使用するインターフェイスで、もう1つはパブリックAPIで公開するインターフェイスです。（内部のものは可能ですが、必ずしも公開のものを拡張する必要はありません。）または、他の人が指摘したように、抽象スーパークラス。

プロテクトメソッドは、サブクラスが基本クラスを拡張する場合にのみ、サブクラスから常にアクセスできます。

インターフェースの場合、サブクラスはインターフェースを拡張しません。インターフェースを実装しています。

保護された方法は、を介してアクセスされている拡張ではない実装します。

インターフェイスは、メソッドを外部の世界に公開することを目的としています。したがって、これらのメソッドは本質的にパブリックです。ただし、同じクラスファミリー内に抽象化を導入したい場合は、インターフェイスと実装クラスの間に抽象化の別のレベル、つまり抽象クラスを作成することで可能です。以下に例を示します。

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
    }
}