같은 클래스에 있는 다른 개체의 개인 필드에 액세스합니다.

같은 클래스에 있는 다른 개체의 개인 필드에 액세스합니다.

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는 왜 개인 필드가 객체 수준의 액세스가 아닌 클래스 수준의 액세스가 가능하도록 설계되었는가 하는 것입니다.

저도 답이 좀 궁금해요.

가장 만족스러운 답변은 Artemix의 다른 투고입니다(AClass의 이름을 Person class로 변경합니다).오브젝트 레벨이 아닌 클래스 레벨의 액세스 수식자가 있는 이유는 무엇입니까?

개인 수식자는 캡슐화 원칙을 적용합니다.

개인의 구현이 시간이 지남에 따라 변경될 수 있기 때문에 '외부 세계'는 개인의 내부 프로세스를 변경하지 않아야 합니다(또한 구현의 차이를 수정하기 위해 외부 세계 전체를 변경해야 합니다(이는 거의 불가능에 가깝습니다).

사용자 인스턴스가 다른 사용자 인스턴스의 내부에 접근할 때, 두 인스턴스가 항상 사용자 구현에 대한 세부사항을 알고 있는지 확인할 수 있습니다.사용자 내부 프로세스의 논리가 변경된 경우 - 사용자는 사용자 코드를 변경하기만 하면 됩니다.

편집: Artemix의 답변에 투표해 주세요.그냥 복사해서 붙이는 거예요.

좋은 질문입니다.오브젝트 레벨의 액세스 수식자에 의해 캡슐화 원칙이 한층 더 적용된다고 생각됩니다.

하지만 사실은 그 반대입니다.예를 들어보자.객체의 개인 멤버에 액세스할 수 없는 경우 해당 객체를 생성자에 자세히 복사하려고 합니다.가능한 유일한 방법은 모든 개인 구성원에 일부 퍼블릭액세서를 추가하는 것입니다.이렇게 하면 시스템의 다른 모든 부분에 물체가 노출됩니다.

따라서 캡슐화가 다른 모든 세계와 폐쇄되는 것을 의미하지는 않습니다.그것은 당신이 누구에게 마음을 열고 싶은지 선택하는 것을 의미합니다.

Java 언어 사양 섹션 6.6.1을 참조하십시오. 접근성 판단

기재되어 있습니다.

이외의 경우 컨스트럭터가 ""로 private멤버 또는 컨스트럭터의 선언을 둘러싼 톱레벨클래스(param7.6)의 본문 내에서 발생한 경우에만 액세스가 허용됩니다.

자세한 내용은 위의 링크를 클릭하십시오.답은 제임스 고슬링과 자바 저자들이 그렇게 결정했기 때문입니다.

이 자리에 가 있습니다.class Person는 자신의 수 - 자기 클래스 내부를 들여다볼 수 있습니다. 컨스트럭터( constructor)를 카피 컨스트럭터( constructor)는 과 같습니다.

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-우리 빅 넘버클래스를 위해서.

왜 자바에서 개인 가시성의 의미가 오브젝트 수준이 아닌 클래스 수준인지에 대한 질문에 대한 나의 2센트입니다.

여기에서는 편리함이 관건인 것 같습니다.실제로 객체 수준의 비공개 가시성은 OP에 의해 설명되는 시나리오에서 다른 클래스(예: 동일한 패키지의)에 메서드를 노출시켜야 한다.

실제로 클래스-프라이빗 레벨에서의 가시성(Java가 제공하는 것과 같이)이 오브젝트-프라이빗 레벨에서의 가시성과 비교하면 문제가 발생한다는 것을 나타내는 예를 찾을 수 없었다.

즉, 보다 세분화된 가시성 정책 시스템을 사용하는 프로그래밍 언어는 객체 수준과 클래스 수준 모두에서 객체 가시성을 제공할 수 있습니다.

예를 들어 Eiffel은 선택적 내보내기를 제공합니다. {NONE}(개체-전용)에서 {ANY}(공용에 해당하며 기본값도 해당)로 선택한 모든 클래스로 클래스 기능을 {Person, BANK}의 특정 클래스 그룹으로 내보낼 수 있습니다.

에펠에서는 속성을 비공개로 하고 다른 클래스가 할당하지 않도록 getter를 작성할 필요가 없다는 점도 흥미롭다.에펠의 공용 속성은 기본적으로 읽기 전용 모드로 액세스할 수 있으므로 값을 반환하기 위해 getter가 필요하지 않습니다.

물론 Atribute를 설정하려면 setter가 필요하지만 Atribute의 "assigner"로 정의하여 숨길 수 있습니다.이를 통해 설정기 호출 대신 보다 편리한 할당 연산자를 사용할 수 있습니다.

냐하 because는private 액세스 수식자는 클래스 내에서만 표시할 수 있도록 합니다.이 메서드는 아직 클래스에 있습니다.

private필드가 선언된 클래스/오브젝트에서 필드에 액세스할 수 있습니다.이 클래스는 자신이 위치한 클래스 이외의 다른 클래스/개체에는 비공개입니다.

여기서 가장 먼저 이해해야 할 것은 ops 원칙을 따르는 것입니다.따라서 캡슐화는 데이터를 패키지(클래스) 내에서 랩하고 모든 데이터를 오브젝트로 나타내며 접근하기 쉽도록 하는 것입니다.필드를 비공개로 만들면 비개인적으로 접근하게 되고 결과적으로 잘못된 파라티스로 이어지게 됩니다.

Java에서 리플렉션 개념이 가능하여 필드 및 메서드를 수정할 수 있습니다.

Modifando metodos y campos privados con Reflexion en Java

언급URL : https://stackoverflow.com/questions/17027139/access-private-field-of-another-object-in-same-class