Truy cập trường riêng của một đối tượng khác trong cùng một lớp

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;
   }
}

Xin vui lòng quên về thiết kế. Tôi biết rằng OOP chỉ định rằng các đối tượng riêng tư là riêng tư đối với lớp. Câu hỏi của tôi là, tại sao OOP được thiết kế để các trường riêng có quyền truy cập mức lớp chứ không phải quyền truy cập mức đối tượng ?

Tôi cũng hơi tò mò với câu trả lời.

Câu trả lời hài lòng nhất mà tôi tìm thấy là từ Artemix trong một bài đăng khác ở đây (Tôi đang đổi tên AClass bằng lớp Person): Tại sao lại có các công cụ sửa đổi quyền truy cập cấp lớp thay vì cấp đối tượng?

Công cụ sửa đổi riêng thực thi nguyên tắc đóng gói.

Ý tưởng là 'thế giới bên ngoài' không nên thực hiện các thay đổi đối với các quy trình nội bộ của Người vì việc triển khai Người có thể thay đổi theo thời gian (và bạn sẽ phải thay đổi toàn bộ thế giới bên ngoài để khắc phục sự khác biệt trong việc thực hiện - điều này gần như là không thể).

Khi phiên bản Person truy cập vào nội bộ của cá thể Person khác - bạn có thể chắc chắn rằng cả hai phiên bản luôn biết chi tiết về việc triển khai Person. Nếu logic của các quy trình nội bộ với Người được thay đổi - tất cả những gì bạn phải làm là thay đổi mã Người.

CHỈNH SỬA: Hãy bình chọn câu trả lời của Artemix. Tôi chỉ sao chép và dán nó.

Xem Đặc tả ngôn ngữ Java, Phần 6.6.1. Xác định khả năng tiếp cận

Nó nói

Ngược lại, nếu thành viên hoặc hàm tạo được khai báo private, thì quyền truy cập được cho phép nếu và chỉ khi nó xảy ra trong phần thân của lớp cấp cao nhất (§7.6) bao quanh khai báo của thành viên hoặc hàm tạo.

Nhấp vào liên kết ở trên để biết thêm chi tiết. Vì vậy, câu trả lời là: Bởi vì James Gosling và các tác giả khác của Java đã quyết định nó theo cách đó.

Câu hỏi hay. Có vẻ như công cụ sửa đổi quyền truy cập mức đối tượng sẽ thực thi nguyên tắc Đóng gói hơn nữa.

Nhưng thực ra thì ngược lại. Hãy lấy một ví dụ. Giả sử bạn muốn sao chép sâu một đối tượng trong một phương thức khởi tạo, nếu bạn không thể truy cập vào các thành viên riêng của đối tượng đó. Sau đó, cách duy nhất có thể là thêm một số người truy cập công khai vào tất cả các thành viên riêng tư. Điều này sẽ làm cho các đối tượng của bạn trần trụi đối với tất cả các phần khác của hệ thống.

Vì vậy, đóng gói không có nghĩa là đóng cửa với tất cả phần còn lại của thế giới. Nó có nghĩa là chọn lọc đối tượng mà bạn muốn công khai.

Điều này hoạt động bởi vì bạn đang ở trong class Person- một lớp được phép chọc vào bên trong loại lớp của chính nó. Điều này thực sự hữu ích khi bạn muốn viết một hàm tạo bản sao, ví dụ:

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; }
};

Hoặc nếu chúng ta muốn viết operator+và operator-cho lớp số lớn của chúng ta.

Chỉ 2 xu của tôi cho câu hỏi tại sao ngữ nghĩa của khả năng hiển thị riêng tư trong Java là cấp lớp chứ không phải cấp đối tượng.

Tôi có thể nói rằng sự tiện lợi dường như là chìa khóa ở đây. Trên thực tế, khả năng hiển thị riêng tư ở mức đối tượng sẽ buộc phải hiển thị các phương thức cho các lớp khác (ví dụ trong cùng một gói) trong kịch bản được minh họa bởi OP.

Trong thực tế, tôi không thể hiểu và cũng không thể tìm thấy một ví dụ cho thấy rằng khả năng hiển thị ở cấp độ lớp riêng tư (như được cung cấp bởi Java) tạo ra bất kỳ vấn đề nào nếu so sánh với khả năng hiển thị ở cấp độ đối tượng-riêng.

Điều đó nói rằng, các ngôn ngữ lập trình có hệ thống chính sách khả năng hiển thị chi tiết hơn có thể đủ khả năng hiển thị đối tượng ở cấp đối tượng và cấp lớp.

Ví dụ: Eiffel , cung cấp tính năng xuất có chọn lọc: bạn có thể xuất bất kỳ đối tượng địa lý nào của lớp sang bất kỳ lớp nào bạn chọn, từ {NONE} (đối tượng-riêng tư) đến {ANY} (tương đương với công khai và cũng là mặc định), sang {PERSON} (lớp-riêng tư, xem ví dụ của OP), cho các nhóm lớp cụ thể {PERSON, BANK}.

Cũng rất thú vị khi nhận xét rằng trong Eiffel, bạn không cần đặt một thuộc tính là riêng tư và viết một getter để ngăn các lớp khác gán cho nó. Các thuộc tính công khai trong Eiffel theo mặc định có thể truy cập ở chế độ chỉ đọc, vì vậy bạn không cần getter chỉ để trả lại giá trị của chúng.

Tất nhiên, bạn vẫn cần một setter để đặt một thuộc tính, nhưng bạn có thể ẩn nó bằng cách xác định nó là "người gán" cho thuộc tính đó. Điều này cho phép bạn, nếu bạn muốn, sử dụng toán tử gán thuận tiện hơn thay vì lời gọi setter.

Bởi vì công cụ private sửa đổi truy cập hiển thị nó chỉ hiển thị trong lớp . Phương thức này vẫn ở trong lớp .

các privatelĩnh vực có thể truy cập vào các lớp / đối tượng, trong đó lĩnh vực này được khai báo. Nó là riêng tư đối với các lớp / đối tượng khác bên ngoài lớp / đối tượng mà nó nằm trong đó.

Điều đầu tiên ở đây chúng ta phải hiểu là tất cả những gì chúng ta phải làm là phải tuân theo các nguyên tắc oops, vì vậy đóng gói được nói là bọc dữ liệu bên trong gói (tức là lớp) và đại diện cho tất cả dữ liệu dưới dạng đối tượng và dễ truy cập. vì vậy nếu chúng tôi đặt trường là không riêng tư hơn là trường được truy cập một cách riêng lẻ. và nó dẫn đến một mệnh đề xấu.

Với khái niệm phản chiếu trong Java, có thể sửa đổi các trường và phương thức riêng

Modificando metodos y campos privados con Refleccion en Java