Tại sao không có công cụ sửa đổi truy cập 'chỉ phân lớp' trong Java?

Trong Java, có bốn công cụ sửa đổi truy cập có sẵn cho các phương thức:

public - bất kỳ lớp nào cũng có thể sử dụng phương pháp này.

protected - các lớp trong cùng một gói và các lớp con trong bất kỳ gói nào có thể sử dụng phương thức này.

private - chỉ có lớp này có thể sử dụng phương pháp này.

no modifier ("gói riêng") - chỉ các lớp trong cùng một gói có thể sử dụng phương thức này.

Điều thường xảy ra là tôi muốn có các phương thức hữu ích trong một siêu lớp, mà tất cả các lớp con có thể sử dụng. Nhưng nó sẽ không có ý nghĩa đối với các lớp khác để truy cập phương thức này và theo một nghĩa nào đó, nó sẽ phá vỡ sự đóng gói.

Vì vậy, tôi phải khai báo các phương thức hữu ích này trong lớp cha publichoặc protected, chúng hiển thị chúng cho tất cả các lớp khác ít nhất là trong gói. Mặc dù chúng chỉ được sử dụng bởi các lớp con.

Có một lý do tại sao không có một công cụ subclasses-onlysửa đổi truy cập trong Java? Nó có vẻ rất kỳ lạ với tôi. Tui bỏ lỡ điều gì vậy?

Ngoài ra, một công cụ subclasses-onlysửa đổi truy cập cũng sẽ hữu ích khi bạn muốn chỉ hiển thị các biến cho các lớp con. Mà với tôi xảy ra rất nhiều.

Bởi vì bạn có thể mô phỏng công cụ sửa đổi chỉ các lớp con bằng cách sử dụng công cụ sửa đổi được bảo vệ và thực thi rằng chỉ có lớp cha và các lớp con của nó nằm trong cùng một gói.

Đó thực sự là một thực tiễn tốt, bởi vì các gói không chỉ giúp tổ chức các dự án lớn về sự gắn kết, mà chúng còn cho thấy rằng các lớp trong cùng một gói có thể có một số mức độ khớp nối.

Java ban đầu có một sửa đổi như vậy. Nó đã được viết private protectednhưng bị xóa trong Java 1.0.

Tôi cho rằng đó là một lời kêu gọi phán xét rằng sự phức tạp thêm không đáng giá.

Mỗi tính năng ngôn ngữ đều có một chi phí: trong việc dạy nó cho các lập trình viên mới; trong tài liệu; trong việc thực hiện nó trong trình biên dịch, JVM và các công cụ dev; trong lý luận về tính đúng đắn của chương trình; trong việc kìm hãm sự phát triển ngôn ngữ trong tương lai; và hơn thế nữa. Các tính năng ngôn ngữ tương tác với nhau, có khả năng tương tác N ² .

Bao nhiêu phần trăm lập trình viên Java đã đọc qua thông số kỹ thuật Java và thông số VM? Tôi cá rằng đó là một tỷ lệ nhỏ, lập luận cho một ngôn ngữ thậm chí đơn giản hơn vì mục đích dễ hiểu và các sản phẩm kỹ thuật mà chúng ta có thể phụ thuộc vào

Lợi ích của private protectedtính năng là nhỏ vì gói là đơn vị chính của mô đun.

Kiểm soát Acess có thể được coi là kết quả của sự bao trùm với một nhà phát triển tưởng tượng đang làm việc với lớp của bạn về các phương thức và phương pháp của lớp ...

BẠN: Giả sử bạn muốn làm x, bạn gọi phương thức doX .. DEV: Nói cho tôi biết thêm .. các đối số là gì?

Đây là công khai ...

BẠN: Bên trong doX tôi gọi ... DEV: Whoa, quá nhiều thông tin, tôi không quan tâm đến điều đó. Tôi chỉ muốn biết làm thế nào để sử dụng nó. Nói cho tôi một cái gì đó khác.

Đây là riêng tư ...

BẠN: Khi phân lớp, tôi có doX và doY gọi doIt mà .. DEV: Vâng, tôi sẽ phân lớp, nói cho tôi biết thêm ...

Điều này được bảo vệ ...

BẠN: Tôi sẽ đi nghỉ trong một giờ, tôi sẽ đi trong 6 tháng tới. Ông chủ nói con chó con này là của bạn! Tạm biệt. DEV: Đợi chưa đi, nói cho tôi biết tất cả ...

Đây là gói.

BẠN: Phương thức doItWhen chỉ được gọi bởi lớp này và nó đã không thay đổi trong mười năm. Nó ... DEV: Whoa, chúng tôi xuống còn 50 phút. Tài sản tiếp theo, và nói chuyện nhanh hơn.

Điều này được bảo vệ riêng tư ...

Điều này đã tồn tại. Nó được bảo vệ.

Bạn có quyền kiểm soát những gì các lớp tồn tại trong gói. Nếu không có lớp nào khác trong gói và một biến hoặc phương thức đã cho được bảo vệ, thì đó là 'chỉ các lớp con'.

Điều đó nói rằng, một lần nữa, bạn có quyền kiểm soát những lớp tồn tại trong gói. Bạn có thể chọn không sử dụng các phương thức hoặc biến được bảo vệ.