ステファンD.：
私はいくつかのメンバーを持つクラスを持っているし、メンバーはクラス自体よりも制限アクセス修飾子を持っていると言います。
具体的な例は次のようになります。
package apples;
class A { // package private
public int foo() { // public (=> less restrictive than *package private*)
return 42;
}
}
私が理解するためのクラスのアクセス修飾子よりも制限されるメンバーのアクセス修飾子を、より制限の少ない上書きされますメンバーのアクセス修飾子を。だから、制限の少ないメンバーのアクセス修飾子はまったく効果がないはずです。
- 私の理解は正しいですか？
- そうでない場合、結果は何ですか？
- 正当な理由が制限の少ないメンバーのアクセス修飾子を持つことは何だろうか？
- 最後に、そこに何のベストプラクティスに従うには？
私はしかし、その後もアクセス修飾子は関係していないようです、私は周りの関数参照を渡し始めると、それは結果をもたらすかもしれないと思ったので、私はまた、いくつかの実験でした。
私が構築されている状況は以下の通りであります：
apples.Bパブリックメソッドを提供bla()への参照を返しますapples.A.foo。- 次に
pizzas.C呼び出すapples.B.blaへの参照を取得A.fooし、それを呼び出します。 - だから、
A.foo()直接見えないCが、間接的にしかアクセス経由でB.bla()
私はそれをテストし、私はのアクセス修飾子作るかどうか、それは違いはありませんfoo() パッケージがプライベートか。
package apples;
import java.util.function.IntSupplier;
public class B {
public IntSupplier getReferenceToAFoo() {
A aInstance = new A();
return aInstance::foo;
}
}
package pizzas;
import apples.B;
import java.util.function.IntSupplier;
public class C {
private int callAFooIndirectly() {
B bInstance = new B();
IntSupplier intsupplier = bInstance.getReferenceToAFoo();
return intsupplier.getAsInt();
}
public static void main(String[] args) {
C cInstance = new C();
int i = cInstance.callAFooIndirectly();
System.out.println(i);
assert 42 == i;
}
}
TJクラウダー：
私の理解は正しいですか？
はい。
正当な理由が制限の少ないメンバーのアクセス修飾子を持つことは何だろうか？
二つの理由：
- 時には、あなたはインターフェイスを実装しています。インタフェースメソッドでなければなりません
public - それは、それが簡単にあなたのクラスの全体的なアクセスを変更することができます。あなたは今までに公共になりたいだろうと、すべてのメソッドをマークしている場合例えば、
public偶数パッケージ・プライベートクラスでは、その後のすべてのあなたは、クラスのパブリックがアドオンであることを確認するためにしなければならないpublicクラス宣言に。
最後に、ベストプラクティスは従うために何がありますか？
それはとてもスタックオーバーフローの質問または回答によく適していない、意見の問題です。あなたおよび/またはあなたのチームに合理的なようで何をすべきか、および/またはあなたのチームのスタイルガイドを行うことを示しています何。