Mục đích cuối cùng và được đóng dấu

Question

Tại sao bất kỳ ai muốn đánh dấu một lớp học là cuối cùng hoặc niêm phong?

Answer 1

Theo Wikipedia, "Các lớp được niêm phong chủ yếu được sử dụng để ngăn chặn dẫn xuất. Chúng thêm một mức độ nghiêm ngặt khác trong thời gian biên dịch, cải thiện mức sử dụng bộ nhớ và kích hoạt tối ưu nhất định để cải thiện hiệu quả thời gian chạy."

Ngoài ra, từ Patrick Smacchia's blog:

• Versioning: Khi một lớp được bịt kín ban đầu, nó có thể thay đổi để niêm phong trong tương lai mà không vi phạm tương thích. (…)

• Hiệu suất: (…) nếu trình biên dịch JIT nhìn thấy một cuộc gọi đến một phương pháp ảo bằng cách sử dụng một loại niêm phong, trình biên dịch JIT có thể tạo ra mã hiệu quả hơn bằng cách gọi phương thức không gần như (…)

• Tính bảo mật và khả năng dự đoán: Một lớp học phải bảo vệ trạng thái của chính nó và không cho phép chính nó trở nên bị hỏng. Khi một lớp được niêm phong, một lớp dẫn xuất có thể truy cập và thao tác nhà nước lớp cơ sở nếu bất kỳ lĩnh vực dữ liệu hoặc các phương pháp mà trong nội bộ thao tác các lĩnh vực có thể truy cập và không tin. (...)

Đó là tất cả khá tốt lý do - Tôi thực sự không nhận thức được ý nghĩa lợi ích hiệu suất cho đến khi tôi tìm kiếm nó ngay bây giờ :)

Điểm phiên bản và bảo mật có vẻ như là một lợi ích lớn về độ tin cậy mã. của dự án lớn. Nó không có drop-in cho thử nghiệm đơn vị, tất nhiên, nhưng nó sẽ giúp đỡ.

Answer 2

Bởi vì việc tạo kiểu cho kế thừa là công việc khó khăn hơn nhiều so với hầu hết mọi người nghĩ. Tốt nhất là đánh dấu tất cả các loại theo cách này theo mặc định vì điều này sẽ ngăn người khác kế thừa từ loại không bao giờ được dự định mở rộng.

Loại có nên được mở rộng hay không là quyết định của nhà phát triển đã tạo nó, chứ không phải nhà phát triển đến sau và muốn mở rộng nó.

Answer 3

Joshua Bloch trong cuốn sách Các cuộc đàm phán Java hiệu quả về nó. Anh ta nói "tài liệu thừa kế hoặc không cho phép nó". Vấn đề là lớp học là loại hợp đồng giữa tác giả và khách hàng. Cho phép khách hàng kế thừa từ lớp cơ sở làm cho hợp đồng này nghiêm ngặt hơn nhiều. Nếu bạn sẽ kế thừa từ nó, bạn rất có thể sẽ ghi đè lên một số phương thức, nếu không bạn có thể thay thế thừa kế bằng bố cục. Phương pháp nào được phép ghi đè và những gì bạn phải thực hiện chúng - phải được ghi lại hoặc mã của bạn có thể dẫn đến kết quả không thể đoán trước. Theo như tôi nhớ, ông cho thấy ví dụ như vậy - đây là một lớp thu thập với phương pháp

public interface Collection<E> extends Iterable<E> {  
    ... 
    boolean add(E e); 
    boolean addAll(Collection<? extends E> c); 
    ... 
} 

Có một số triển khai, ví dụ: ArrayList. Bây giờ bạn muốn kế thừa từ nó và ghi đè lên một số phương thức, do đó, nó in để điều khiển một thông báo khi phần tử được thêm vào. Bây giờ, bạn có cần ghi đè cả hai số thêm và addAll hoặc chỉ thêm? Nó phụ thuộc vào cách addAll được triển khai - có hoạt động với trạng thái nội bộ trực tiếp (như ArrayList không) hoặc gọi thêm (như AbstractCollection).Hoặc có thể ở đó là addInternal, được gọi là bởi cả hai thêm và addAll. Không có câu hỏi như vậy cho đến khi bạn quyết định kế thừa từ lớp này. Nếu bạn chỉ sử dụng nó - nó không làm phiền bạn. Vì vậy, tác giả của lớp học phải ghi lại nó, nếu anh ta muốn bạn kế thừa từ lớp của mình.

Và nếu anh ta muốn thay đổi triển khai trong tương lai thì sao? Nếu lớp học của anh ta chỉ được sử dụng, không bao giờ được thừa kế, không có gì ngăn cản anh ta thay đổi việc thực hiện để hiệu quả hơn. Bây giờ, nếu bạn được kế thừa từ lớp đó, hãy xem nguồn và thấy rằng addAll gọi thêm, bạn chỉ ghi đè thêm. Sau đó tác giả thay đổi triển khai để addAll không còn gọi số thêm - chương trình của bạn bị hỏng, thư không được in khi số addAll được gọi. Hoặc bạn nhìn vào nguồn và thấy rằng addAll không gọi thêm, vì vậy bạn ghi đè thêm và addAll. Bây giờ tác giả thay đổi triển khai, do đó, addAll gọi thêm - chương trình của bạn bị hỏng một lần nữa, khi addAll được gọi là tin nhắn được in hai lần cho mỗi phần tử.

Vì vậy - nếu bạn muốn lớp học của bạn được kế thừa từ, bạn cần ghi lại cách thức. Nếu bạn nghĩ rằng bạn có thể cần phải thay đổi một cái gì đó trong tương lai có thể phá vỡ một số lớp con - bạn cần phải suy nghĩ làm thế nào để tránh nó. Bằng cách cho phép khách hàng của bạn kế thừa từ lớp của bạn, bạn sẽ tiết lộ nhiều chi tiết triển khai nội bộ hơn khi bạn chỉ cho phép họ sử dụng lớp học của bạn - bạn phơi bày quy trình làm việc nội bộ, thường có thể thay đổi trong các phiên bản sau.

Nếu bạn tiết lộ một số chi tiết và khách hàng dựa vào chúng - bạn không còn có thể thay đổi chúng. Nếu nó là ok với bạn, hoặc bạn tài liệu những gì có thể và những gì không thể được overriden - đó là tốt. Đôi khi bạn chỉ không muốn nó. Đôi khi bạn chỉ muốn nói - "chỉ sử dụng lớp này, không bao giờ kế thừa từ nó, bởi vì tôi muốn có quyền tự do thay đổi chi tiết thực hiện nội bộ".

Vì vậy, về cơ bản nhận xét "Vì lớp học không muốn có con và chúng tôi nên tôn trọng mong muốn của nó" là chính xác.

Vì vậy, ai đó muốn đánh dấu một lớp là cuối cùng/niêm phong, khi ông nghĩ rằng các thay đổi chi tiết thực hiện có thể có giá trị hơn thừa kế. Có nhiều cách khác để đạt được kết quả tương tự như thừa kế.