Javaでは、メソッドに4つの利用可能なアクセス修飾子があります。
public
-すべてのクラスがこのメソッドを使用できます。
protected
-同じパッケージ内のクラスと任意のパッケージ内のサブクラスは、このメソッドを使用できます。
private
-このクラスのみがこのメソッドを使用できます。
no modifier
( "package private")-同じパッケージ内のクラスのみがこのメソッドを使用できます。
よくあるのは、すべてのサブクラスが使用できる、スーパークラスに便利なメソッドが欲しいということです。しかし、他のクラスがこのメソッドにアクセスすることは意味がなく、ある意味でカプセル化が壊れます。
したがって、これらの便利なメソッドをスーパークラスpublic
またはprotected
で宣言する必要があります。これらのメソッドは、少なくともパッケージ内の他のすべてのクラスにそれらを公開します。サブクラスでのみ使用されることを意図していますが。
Javaにsubclasses-only
アクセス修飾子がない理由はありますか?それは私には非常に奇妙に思えます。何か不足していますか?
また、subclasses-only
アクセス修飾子は、変数をサブクラスのみに公開したい場合にも役立ちます。これはよく起こります。
protected修飾子を使用し、親クラスとそのサブクラスのみが同じパッケージに含まれるように強制することで、subclasses-only修飾子をエミュレートできるためです。
パッケージはまとまりの観点から大きなプロジェクトを整理するのに役立つだけでなく、同じパッケージ内のクラスがある程度のカップリングを持っている可能性があることも示しているため、これは確かに良い習慣です。
Javaには元々そのような修飾子がありました。 private protected
と書かれていましたが、Java 1.0で削除されました。
これは、余分な複雑さはコストに見合わないという判断の呼びかけだったと思います。
すべての言語機能にはコストがかかります。それを新しいプログラマーに教えるには、ドキュメンテーション;コンパイラー、JVM、および開発ツールでの実装。プログラムの正確さについての推論。将来の言語進化を制約すること。もっと。言語機能は相互に、場合によってはNと相互作用します2 相互作用。
JavaプログラマーがJava言語仕様およびVM仕様を読んだことがあるか?理解しやすく、信頼できるエンジニアリング製品のために、さらに単純な言語を主張している
パッケージがモジュール化の主要な単位であるため、private protected
機能の利点はわずかでした。
アクセス制御は、クラスのメソッドとプロパティについてクラスで作業している架空の開発者とのカバーの結果と考えることができます...
YOU:xを実行したいとします。メソッドdoXを呼び出します。DEV:詳細を教えてください。引数は何ですか?
これは公開されています...
YOU:doXの中で私は... DEV:おっと、情報が多すぎて気にしません。使い方が知りたい。他に教えてください。
これはプライベートです...
あなた:サブクラス化するとき、doXとdoYを呼び出してdoItを呼び出します。
これは保護されています...
あなた:私は休暇で1時間後に出発します、私は次の6か月間行方不明になります。ボスは、この子犬はあなたのものだと言っています!さようなら。 DEV:まだ行かないで、全部教えて...
こちらはパッケージです。
YOU:doItWhenメソッドはこのクラスによってのみ呼び出され、10年間変更されていません。それ... DEV:おっと、50分になりました。次のプロパティ、そしてより速く話します。
これはプライベートに保護されています...
これはすでに存在しています。保護されています。
パッケージ内に存在するクラスを制御できます。パッケージに他のクラスがなく、指定された変数またはメソッドが保護されている場合、それは「サブクラスのみ」です。
つまり、パッケージ内に存在するクラスを制御できます。保護されたメソッドまたは変数を使用しないことを選択できます。