Tôi đã không ở trong một tình huống mà một lỗi biên dịch gây ra bởi các từ khóa này sẽ cứu tôi khỏi một lỗi.
Sẽ không quá nhiều để cứu các tác giả ứng dụng khỏi các lỗi khi để các tác giả thư viện quyết định phần nào trong quá trình thực hiện của họ mà họ cam kết duy trì.
Nếu tôi có một thư viện
class C {
public void foo() { ... }
private void fooHelper() { /* lots of complex code */ }
}
Tôi có thể muốn có thể thay thế fooviệc thực hiện và có thể thay đổi fooHelpertheo những cách triệt để. Nếu một nhóm người đã quyết định sử dụng fooHelperbất chấp tất cả các cảnh báo trong tài liệu của tôi thì tôi có thể không làm được điều đó.
privatecho phép các tác giả thư viện chia các thư viện thành các phương thức có kích thước có thể quản lý (và privatecác lớp trợ giúp) mà không sợ rằng họ sẽ bị buộc phải duy trì các chi tiết nội bộ đó trong nhiều năm.
Điều gì sẽ làm cho nó đáng giá cho trình biên dịch để thực thi ẩn thông tin?
Mặt khác, trong Java privatekhông phải do trình biên dịch thực thi, mà bởi trình xác minh mã byte của Java .
Phản xạ có thể ghi đè lên cơ chế này? Điều gì sẽ làm cho nó đáng giá cho trình biên dịch để thực thi ẩn thông tin?
Trong Java, không chỉ sự phản chiếu có thể ghi đè lên cơ chế này. Có hai loại privatetrong Java. Loại privatengăn không cho một lớp bên ngoài truy cập vào privatecác thành viên của lớp bên ngoài khác được kiểm tra bởi trình xác minh mã byte, nhưng cũng privateđược sử dụng bởi một lớp bên trong thông qua phương thức truy cập tổng hợp riêng tư gói như trong
public class C {
private int i = 42;
public class B {
public void incr() { ++i; }
}
}
Do lớp B(thực sự được đặt tên C$B) sử dụng i, trình biên dịch tạo ra một phương thức Btruy cập tổng hợp cho phép truy cập C.itheo cách vượt qua trình xác minh mã byte. Thật không may, vì ClassLoadercho phép bạn tạo một lớp từ một byte[], khá đơn giản để có được các phần riêng tư Cđã tiếp xúc với các lớp bên trong bằng cách tạo một lớp mới trongC gói có thể nếu Cbình không được niêm phong.
Việc privatethực thi đúng cách đòi hỏi sự phối hợp giữa các trình nạp lớp, trình xác minh mã byte và chính sách bảo mật có thể ngăn chặn truy cập phản chiếu đến các vùng riêng.
Nó có thể được sử dụng để bảo đảm trạng thái bí mật của một lớp khỏi bị tấn công không?
Vâng. "Phân tách an toàn" có thể có khi các lập trình viên có thể cộng tác trong khi mỗi bảo toàn các thuộc tính bảo mật của các mô-đun của họ - Tôi không phải tin tưởng tác giả của một mô-đun mã khác không vi phạm các thuộc tính bảo mật của mô-đun của tôi.
Các ngôn ngữ Khả năng đối tượng như Joe-E sử dụng ẩn thông tin và các phương tiện khác để thực hiện phân tách an toàn:
Joe-E là một tập hợp con của ngôn ngữ lập trình Java được thiết kế để hỗ trợ lập trình an toàn theo nguyên tắc khả năng của đối tượng. Joe-E nhằm tạo điều kiện cho việc xây dựng các hệ thống an toàn, cũng như tạo điều kiện đánh giá bảo mật cho các hệ thống được xây dựng trong Joe-E.
Bài viết được liên kết từ trang đó đưa ra một ví dụ về cách privatethực thi giúp phân tách an toàn có thể.
Cung cấp đóng gói an toàn.
Hình 1. Một cơ sở ghi nhật ký chỉ phụ lục.
public final class Log {
private final StringBuilder content;
public Log() {
content = new StringBuilder();
}
public void write(String s) {
content.append(s);
}
}
Xem xét hình 1, minh họa cách người ta có thể xây dựng một cơ sở nhật ký chỉ nối thêm. Với điều kiện phần còn lại của chương trình được viết bằng Joe-E, một người đánh giá mã có thể hiểu rằng các mục nhật ký chỉ có thể được thêm vào và không thể sửa đổi hoặc xóa. Đánh giá này là thực tế vì nó chỉ yêu cầu kiểm tra Log
lớp và không yêu cầu xem lại bất kỳ mã nào khác. Do đó, việc xác minh tài sản này chỉ yêu cầu lý luận cục bộ về mã đăng nhập.