Java の作成者が行った 2 つの決定があり、Java の設計方法を導きました。1つは、パフォーマンスが優先され、遅すぎるために使用できないと判断されてはならないということでした。もう 1 つの決定は、C および C++ の開発者を対象とし、採用を容易にするために、Java を彼らが慣れ親しんだものに似せたものにするというものでした。
そのため、Java は C++ のようにパブリック、プライベート、および保護されたアクセスを取得しました。package-private が登場した場所と、それがデフォルトである理由は明確ではありません。彼らは、開発者がメソッド呼び出しのオーバーヘッドを節約するために変数に直接アクセスしたいと考えているかもしれません。昔、Marimba のプロフェッショナル サービス担当者と一緒にプロジェクトに取り組んでいました。多くのパッケージ プライベート メンバーで作成された実装コードの一部を調査する機会がありました。なぜ説明したのかと尋ねると、それはパフォーマンスのためでした。これは JIT のような最適化が行われる前のことなので、アクセサー メソッドを使用して頻繁に使用されるスーパークラス メンバーにアクセスするのが遅すぎるという懸念があった可能性があります。一方で、それはスタイルの好みだったのかもしれませんし、進化するデザインの一部としてより自由なアプローチを使用していたのかもしれません。そしておそらく、package-private をデフォルトにする背後にあるアイデアは、この種の自由が期待されるべきだということでした。(これは、私が読んだ他のコードから判断して引っかかるものではありません。) それは Jonathon Payne と Arthur Van Hoff によって書かれたコードでした。
James Gosling が彼の理由について語っているインタビューがあります。
... 私が早い段階でやりたかったことの 1 つは、設定を形式化し、言語で何かを取得することでした。JavaBeans には、setter メソッドと getter メソッドを記述するというこの種の規則があることをご存知ですか? しかし、私は当時、開発者がこれを望んでいるかどうかについて、多くの調査を行いました. そして、平均的な人は「オーマイゴッド!」と言いました。
そして、私はそれをしませんでした。でも、振り返ってみると、彼らの音楽を聞くべきではなかったと思います。私はそれをやったはずです。なぜなら、Beans は基本的に、私がとにかくやりたかったこの機能の上に重ねられたということですが、Beans は一種の後付けとしてそれを行ったからです。
また、命名規則として階層化されているため、うまく適合しないものもあります. したがって、たとえば、インスタンス変数のデフォルトの保護を非公開にすることは非常に理にかなっています。そして、システムがはるかに深いレベルで知っていたゲッターとセッターを公開またはパッケージ化します。
スタイルが進化した方向は、インスタンス変数を非公開にすることを好み、必要に応じてゲッターを介してそれらを公開することです。次のように、private アクセス修飾子を指定できます。
private int humidity;
変数はサブクラスから見えなくなります。