class Person
{
private BankAccount account;
Person(BankAccount account)
{
this.account = account;
}
public Person someMethod(Person person)
{
//Why accessing private field is possible?
BankAccount a = person.account;
}
}
デザインを忘れてください。OOPは、プライベートオブジェクトがクラスに対してプライベートであることを指定していることを知っています。私の質問は、プライベートフィールドがオブジェクトレベルのアクセスではなくクラスレベルのアクセスを持つようにOOPが設計されたのはなぜですか？
someMethod有効ではありません。何も返しません。でなければなりませんvoid。
回答:
私もその答えに少し興味があります。
私が見つけた最も満足のいく答えは、ここにある別の投稿のArtemixからのものです（私はAClassの名前をPersonクラスに変更しています）： なぜオブジェクトレベルではなくクラスレベルのアクセス修飾子があるのですか？
プライベート修飾子は、カプセル化の原則を適用します。
Personの実装は時間の経過とともに変化する可能性があるため、「外界」はPersonの内部プロセスに変更を加えるべきではないという考え方です（実装の違いを修正するには、外界全体を変更する必要があります。これはほぼ不可能です）。
Personのインスタンスが他のPersonインスタンスの内部にアクセスする場合、両方のインスタンスが常にPersonの実装の詳細を知っていることを確認できます。Personプロセスの内部のロジックが変更された場合、必要なのはPersonのコードを変更することだけです。
編集：Artemixの回答に投票してください。コピーして貼り付けているだけです。
Personクラス内ののフィールドにアクセスする開発者は、クラスPerson全体の実装を知る必要はありません。アクセサがどのような操作を行うかを知らなくても、アクセサを使用することをお勧めします。
equals(Object)、Javaクラスにメソッドを実装して、Personオブジェクトとの別のインスタンスとの同等性をチェックするとしますPerson。2つのインスタンスが等しいかどうかを外部が確認できるようにすることもできますが、パブリックアクセサメソッドを使用して外部との同等性を確認するために必要なクラスのプライベートフィールドをすべて公開したくない場合があります。privateフィールドへのクラスレベルのアクセス権があると、そのようなパブリックメソッドを実装する必要なしにそのようなメソッドを実装できます。
equals）。
equalsプライベートアクセサーを呼び出すことで実行できます。
privateクラスレベルのアクセスを許可する必要があるということです。アクセサーを使用することは一般的に良い習慣であることに同意しますが、この場合、それは主にコンテキストと個人的なスタイルの問題です。このDr.Dobbsの記事のJoshuaBloch in Effective Java（アイテム8）とTal Cohenはどちらも、実装方法について説明するときに、コードリストのプライベートフィールドに直接アクセスすることに注意してください。equals
Java言語仕様のセクション6.6.1を参照してください。アクセシビリティの決定
それは述べています
それ以外の場合、メンバーまたはコンストラクターが宣言
privateされている場合、アクセスは、メンバーまたはコンストラクターの宣言を囲む最上位クラス（§7.6）の本体内で発生する場合にのみ許可されます。
詳細については、上のリンクをクリックしてください。つまり、答えは次のとおりです。JamesGoslingと他のJavaの作成者は、そのように決定したからです。
良い質問。オブジェクトレベルのアクセス修飾子は、カプセル化の原則をさらに強化するようです。
しかし、実際にはその逆です。例を見てみましょう。オブジェクトのプライベートメンバーにアクセスできない場合は、コンストラクターでオブジェクトをディープコピーするとします。次に、可能な唯一の方法は、すべてのプライベートメンバーにパブリックアクセサーを追加することです。これにより、オブジェクトがシステムの他のすべての部分に対して裸になります。
したがって、カプセル化は、世界の他のすべての地域に閉鎖されることを意味するものではありません。それはあなたが誰に開かれたいかについて選択的であることを意味します。
o.deepCopy()。同じメカニズムであるかどうかは関係ありません。
これが機能するのはclass Person、クラスが独自のタイプのクラス内を突くことが許可されているためです。これは、次のようなコピーコンストラクターを作成する場合に非常に役立ちます。
class A
{
private:
int x;
int y;
public:
A(int a, int b) x(a), y(b) {}
A(A a) { x = a.x; y = y.x; }
};
または、私たちが書きたい場合operator+、そしてoperator-私たちの大きな数のクラスのために。
Javaのプライベート可視性のセマンティクスがオブジェクトレベルではなくクラスレベルである理由についての私の2セント。
ここでは利便性がカギだと思います。実際、オブジェクトレベルでのプライベートな可視性により、OPで示されているシナリオでは、メソッドを他のクラス（たとえば、同じパッケージ内）に公開する必要があります。
実のところ、オブジェクトプライベートレベルでの可視性と比較した場合、クラスプライベートレベルでの可視性（Javaによって提供されるような）が問題を引き起こすことを示す例を作成することも見つけることもできませんでした。
とはいえ、可視性ポリシーのよりきめ細かいシステムを備えたプログラミング言語は、オブジェクトレベルとクラスレベルの両方でオブジェクトの可視性を提供できます。
たとえば、Eiffelは、選択的なエクスポートを提供します。{NONE}（object-private）から{ANY}（publicに相当し、デフォルト）、{PERSON}まで、任意のクラス機能を任意のクラスにエクスポートできます。 （class-private、OPの例を参照）、クラスの特定のグループ{PERSON、BANK}。
また、エッフェル塔では、属性をプライベートにして、他のクラスが属性に割り当てないようにするためのゲッターを作成する必要がないことにも注目してください。Eiffelのパブリック属性は、デフォルトで読み取り専用モードでアクセスできるため、値を返すためだけにゲッターは必要ありません。
もちろん、属性を設定するにはセッターが必要ですが、その属性の「割り当て者」として定義することで非表示にできます。これにより、必要に応じて、setter呼び出しの代わりに、より便利な代入演算子を使用できます。
のでprivate 、アクセス修飾子は唯一の中、それは目に見えるレンダリングするクラス。このメソッドはまだクラス内にあります。
ここで最初に理解する必要があるのは、oopsの原則に従う必要があることです。カプセル化とは、パッケージ（つまりクラス）内でデータをラップし、すべてのデータをオブジェクトとして表し、アクセスしやすいということです。したがって、フィールドを個別にアクセスするよりも非プライベートにする場合。そしてそれは悪いパラチスになります。
Javaのリフレクションの概念により、フィールドとメソッドのプライベートを変更できます
Modificando metodos y campos privados con Refleccion en Java