Tại sao Clonizable không được phản đối?

Người ta thường hiểu rằng Cloneablegiao diện trong Java bị hỏng. Có nhiều lý do cho việc này, mà tôi sẽ không đề cập; những người khác đã làm điều đó. Đó cũng là vị trí của chính các kiến ​​trúc sư Java .

Do đó, câu hỏi của tôi là: tại sao vẫn chưa được phản đối? Nếu nhóm Java cốt lõi đã quyết định rằng nó bị hỏng, thì họ cũng phải xem xét khấu hao. Lý do của họ chống lại việc đó là gì (trong Java 8 vẫn không được phản đối )?

Có một lỗi được gửi vào năm 1997 cho Cơ sở dữ liệu lỗi Java về việc thêm clone()phương thức vào Cloneable, vì vậy nó sẽ không còn vô dụng nữa. Nó đã được đóng lại với độ phân giải "sẽ không sửa chữa" và biện minh như sau:

Ủy ban đánh giá kỹ thuật của Sun (TRC) đã xem xét vấn đề này từ lâu và khuyến nghị không nên thực hiện bất kỳ hành động nào ngoài việc cải thiện tài liệu của giao diện Clonizable hiện tại . Dưới đây là toàn văn khuyến nghị:

Các API nhân bản đối tượng Java hiện có là vấn đề. Có một phương thức "nhân bản" được bảo vệ trên java.lang.Object và có một giao diện java.lang.Clonizable. Ý định là nếu một lớp muốn cho phép người khác sao chép nó, thì nó nên hỗ trợ giao diện Clonizable và ghi đè phương thức nhân bản được bảo vệ mặc định bằng phương thức nhân bản công khai. Thật không may, vì lý do thuận tiện bị mất trong thời gian, giao diện Clonizable không xác định phương pháp nhân bản.

Sự kết hợp này dẫn đến một sự nhầm lẫn khá lớn. Một số lớp yêu cầu hỗ trợ Clonizable, nhưng vô tình quên hỗ trợ phương thức clone. Các nhà phát triển bối rối về cách Clonizable được cho là hoạt động và những gì được cho là nhân bản.

Thật không may, việc thêm một phương thức "nhân bản" vào Clonizable sẽ là một thay đổi không tương thích. Nó sẽ không phá vỡ tính tương thích nhị phân, nhưng nó sẽ phá vỡ tính tương thích nguồn. Bằng chứng giai thoại cho thấy rằng trong thực tế có một số trường hợp các lớp hỗ trợ giao diện Clonizable nhưng không cung cấp phương thức nhân bản công khai. Sau khi thảo luận, TRC nhất trí khuyến nghị rằng chúng ta KHÔNG nên sửa đổi giao diện Clonizable hiện có, vì tác động tương thích.

Một đề xuất thay thế là thêm giao diện mới java.lang.PubliclyClonizable để phản ánh mục đích dự định ban đầu của Clonizable. Theo đa số 5 đến 2, TRC khuyến nghị chống lại điều này. Mối quan tâm chính là điều này sẽ thêm sự nhầm lẫn (bao gồm cả nhầm lẫn chính tả!) Cho một hình ảnh đã bị nhầm lẫn.

TRC nhất trí khuyến nghị rằng chúng ta nên thêm tài liệu bổ sung vào giao diện Clonizable hiện có để mô tả rõ hơn cách sử dụng nó và để mô tả "các thực tiễn tốt nhất" cho người triển khai.

Vì vậy, mặc dù điều này không trực tiếp về việc phản đối , nhưng lý do không khiến Clonizable "không dùng nữa" là vì Tạp chí Kỹ thuật Comitee đã quyết định rằng sửa đổi tài liệu hiện có sẽ đủ để làm cho giao diện này hữu ích. Và họ đã làm như vậy. Cho đến Java 1.4, Cloneableđã được ghi lại như sau:

Một lớp thực hiện giao diện Clonizable để chỉ ra phương thức Object.clone () rằng phương thức đó là hợp pháp để tạo một bản sao trường cho các trường hợp của lớp đó.

Nỗ lực sao chép các trường hợp không triển khai giao diện Clonizable dẫn đến ngoại lệ CloneNotSupportedException bị ném.

Giao diện Clonizable tuyên bố không có phương pháp.

Kể từ Java 1.4 (được phát hành vào tháng 2 năm 2002) cho đến phiên bản hiện tại (Java 8), nó trông như thế này:

Một lớp thực hiện giao diện Clonizable để chỉ ra phương thức Object.clone () rằng phương thức đó là hợp pháp để tạo một bản sao trường cho các trường hợp của lớp đó. Gọi phương thức nhân bản của Object trên một cá thể không triển khai kết quả giao diện Clonizable trong trường hợp ngoại lệ CloneNotSupportedException bị ném.

Theo quy ước, các lớp thực hiện giao diện này sẽ ghi đè lên Object.clone (được bảo vệ) bằng một phương thức công khai. Xem Object.clone () để biết chi tiết về ghi đè phương thức này.

Lưu ý rằng giao diện này không chứa phương thức sao chép. Do đó, không thể sao chép một đối tượng chỉ nhờ vào thực tế là nó thực hiện giao diện này. Ngay cả khi phương pháp nhân bản được gọi một cách phản xạ, không có gì đảm bảo rằng nó sẽ thành công.

Câu trả lời ngắn gọn cho "tại sao không Cloneableđược tán thành?" (hoặc thực sự, tại sao không Xđược phản đối, vì bất kỳ X) là đã không có nhiều sự chú ý để phản đối họ.

Hầu hết những thứ bị phản đối gần đây đều bị phản đối vì có một kế hoạch cụ thể để loại bỏ chúng. Ví dụ, addPropertyChangeListenervà removePropertyChangeListenercác phương thức của LogManager không được dùng trong Java SE 8 với ý định loại bỏ chúng trong Java SE 9. (Lý do là chúng phụ thuộc lẫn nhau vào mô-đun phức tạp không cần thiết.) Thật vậy, các API này đã bị xóa khỏi quá trình phát triển JDK 9 ban đầu. xây dựng. (Lưu ý rằng các lệnh gọi người nghe thay đổi thuộc tính tương tự cũng bị xóa khỏi Pack200; xem JDK-8029806 .)

Không có kế hoạch tương tự như vậy tồn tại cho Cloneablevà Object.clone().

Câu trả lời dài hơn sẽ liên quan đến việc thảo luận các câu hỏi tiếp theo, chẳng hạn như những gì người ta có thể mong đợi xảy ra với các API này, chi phí hoặc lợi ích nào sẽ tích lũy cho nền tảng nếu chúng không được chấp nhận và những gì được truyền đạt tới các nhà phát triển khi API bị từ chối. Tôi đã khám phá chủ đề này trong cuộc nói chuyện, Nợ và Khấu hao JavaOne gần đây của tôi . (Các slide có sẵn tại liên kết đó; video ở đây .) Hóa ra chính JDK đã không nhất quán trong việc sử dụng khấu hao. Nó được sử dụng để chỉ một số điều khác nhau, bao gồm cả, ví dụ,

• Đây là nguy hiểm và bạn cần phải nhận thức những nguy cơ của việc sử dụng nó (ví dụ: Thread.stop(), Thread.resume(), và Thread.suspend()).

• Điều này sẽ được gỡ bỏ trong một bản phát hành trong tương lai

• Điều này đã lỗi thời và bạn nên sử dụng một cái gì đó khác biệt (ví dụ: nhiều phương pháp trong java.util.Date )

Tất cả đều là những ý nghĩa riêng biệt và các tập hợp con khác nhau của chúng áp dụng cho những thứ khác nhau không được dùng nữa. Và một số tập hợp con trong số chúng áp dụng cho những thứ không được dùng nữa (nhưng có lẽ không nên dùng nữa).

Cloneablevà Object.clone()bị "phá vỡ" theo nghĩa là chúng có lỗi thiết kế và khó sử dụng chính xác. Tuy nhiên,clone() vẫn là cách tốt nhất để sao chép mảng và nhân bản có một số hữu ích hạn chế để tạo các bản sao của các thể hiện của các lớp được thực hiện cẩn thận. Loại bỏ nhân bản sẽ là một thay đổi không tương thích sẽ phá vỡ rất nhiều thứ. Một hoạt động nhân bản có thể được thực hiện lại theo một cách khác, nhưng nó có thể sẽ chậm hơn Object.clone().

Tuy nhiên, đối với hầu hết mọi thứ, một nhà xây dựng sao chép thích hợp hơn để nhân bản. Vì vậy, có lẽ đánh dấuCloneable là "lỗi thời" hoặc "thay thế" hoặc một cái gì đó tương tự sẽ là phù hợp. Điều này sẽ nói với các nhà phát triển rằng họ có thể muốn tìm ở nơi khác, nhưng nó sẽ không báo hiệu rằng cơ chế nhân bản có thể bị xóa trong một bản phát hành trong tương lai. Thật không may, không có điểm đánh dấu như vậy tồn tại.

Khi mọi thứ đứng vững, "sự phản đối" dường như ngụ ý loại bỏ cuối cùng - mặc dù thực tế là một số lượng nhỏ các tính năng bị phản đối đã bị loại bỏ - và vì vậy sự phản đối dường như không được bảo đảm cho cơ chế nhân bản. Có lẽ trong tương lai, một dấu hiệu thay thế có thể được áp dụng để hướng các nhà phát triển sử dụng các cơ chế thay thế.

CẬP NHẬT

Tôi đã thêm một số lịch sử bổ sung vào báo cáo lỗi . Frank Yellin, một người triển khai JVM sớm và là đồng tác giả của đặc tả JVM, đã đưa ra một số nhận xét để phản hồi lại nhận xét "bị mất trong thời gian" trong khuyến nghị TRC được trích dẫn trong câu trả lời khác . Tôi đã trích dẫn các phần có liên quan ở đây; thông báo đầy đủ là trong báo cáo lỗi.

Clonizable không có phương thức nào cho cùng một lý do mà serializable không có. Clonizable chỉ ra một thuộc tính của lớp, thay vì nói cụ thể bất cứ điều gì về các phương thức mà lớp hỗ trợ.

Trước khi phản ánh, chúng tôi cần một phương thức riêng để tạo một bản sao nông của Object. Do đó Object.clone () đã ra đời. Rõ ràng là nhiều lớp sẽ muốn ghi đè phương thức này và không phải lớp nào cũng muốn được sao chép. Do đó Clonizable được sinh ra để chỉ ra ý định của lập trình viên.

Vì vậy, trong ngắn hạn. Mục đích của Clonizable không phải là để chỉ ra rằng bạn có phương thức clone () công khai. Đó là để chỉ ra rằng bạn sẵn sàng được nhân bản bằng Object.clone () và tùy thuộc vào việc triển khai để quyết định có công khai clone () hay không.

Tại sao nó không được phản đối?

Bởi vì JCP chưa thấy phù hợp để làm như vậy và có thể không bao giờ làm như vậy. Hỏi họ. Bạn đang hỏi sai chỗ.

Các lý do đằng sau việc giữ điều này trong API Java là gì

Không ai sẽ xóa bất cứ thứ gì khỏi API Java, vì yêu cầu tương thích ngược. Lần cuối cùng xảy ra là sự thay đổi trong mô hình sự kiện AWT giữa 1.0 và 1.1 vào năm 1996/7.