web-dev-qa-db-ja.com

Javaにサブクラスの可視性修飾子がないのはなぜですか？

複数の機会で、Javaでは不可能である変数の可視性を望んでいることに気づきました。特定のメンバーを自分のクラス内およびサブクラス内で表示できるようにしたいが、パッケージの他の部分や他の世界には表示しないようにしたかった。言い換えれば、私はこれが欲しかった：

Modifier        Class     Package   Subclass  World
sub-class       Y         N         Y         N

しかし、Javaの設計者は私に this を与えただけです：

Modifier        Class     Package   Subclass  World
public          Y         Y         Y         Y
protected       Y         Y         Y         N
no modifier     Y         Y         N         N
private         Y         N         N         N

このようなものが欲しい典型的なケースは、抽象クラスを作成するときです。時々私は抽象的な親が特定のメンバーへのアクセスを必要とするのを見つけますが、具体的な子供も同様です。メンバーをprotectedにすることで、このアクセス権を与えることができますが、本当にしたくない場合は、パッケージの残りの部分にアクセスできるようになります。

完全に明確にするために、そのような修飾子はJavaではできないことを知っています。私の質問は、なぜそのような修飾子がJavaに含まれていないのですか？ （私にとっては）protectedやデフォルトよりも自然な可視性レベルのようです。その理由が含まれているほど十分に重要ではないのですか、それとも私が考慮していない可能性のある副作用に関連しているのですか？

javalanguage-designvisibility
71
Michael McGowan

非線形のアクセス階層を持つことで、複雑さが増すのを避けたいと思っています。

パッケージを制御する必要があるため、これらの保護されたメソッドをそこで呼び出さないでください。

（ところで、protectedは_sub-class and package_とまったく同じではありません。静的でない保護されたメソッド（同じパッケージ内にない場合）は宣言クラスの任意のオブジェクトで呼び出すことができないためです。ただし、コードが含まれているのは、サブクラスのオブジェクトのみです（これはObject.clone()で確認できます。これは、オブジェクトが複製されているクラスからのみ呼び出すことができます）。

19
Paŭlo Ebermann

どうやら彼らはbeing-a-subtype-ofをbeing-in-same-package-ofほど「密接な関係」ではないと考えています。そして、あなたが提案する修飾子については、サブクラスが実際に別のパッケージに含まれていない限り、それはprotectedとそれほど変わらないでしょう。完全に異なるパッケージのサブクラスであるよりも。

7
aioobe

クラスを独自のパッケージに入れ、メンバー（インスタンス変数またはメソッド）を保護対象としてマークする必要があります。この方法では、サブクラスが保護対象としてマーケティングするそのメンバーにアクセスできることを除いて、他のクラスはありません。サブクラスだけがその保護されたメンバーにアクセスすることを切望したい場合は、1つのパッケージに1つのクラスが作成されます。

3
jumping-jack