2015-09-22 25 views
11

Java 7 đã giới thiệu lớp Objects chứa các phương pháp “null an toàn hoặc null -tolerant”, bao gồm compare(T, T, Comparator<T>). Nhưng khi tôi sẽ không bao giờ sử dụngMục đích của phương thức Objects.compare() là gì?

Objects.compare(left, right, comparator); 

hơn chỉ đơn giản gọi

comparator.compare(left, right); 

?

Objects.compare chỉ là nullđã an toàn nếu comparator cũng vậy, vậy tại sao tôi nên thực hiện cuộc gọi so sánh? Việc tối ưu hóa kiểm tra đầu tiên đối với nhận dạng đối tượng có vẻ giống như một cái gì đó cần được thực hiện trong chính bộ so sánh. Và sự khác biệt thực sự duy nhất trong hành vi tôi có thể thấy là comparator.compare(left, right) ném một NullPointerException nếu tất cả comparator, leftrightnull, trong khi Objects.compare thì không; điều này dường như không thực sự quan trọng để đảm bảo một phương pháp thư viện chuẩn mới.

Tôi có thiếu điều gì đó hiển nhiên ở đây không?

+2

Phương pháp này là hoàn toàn ngu ngốc, tôi đồng ý. [Đặt hàng 'của ổi] (https://code.google.com/p/guava-libraries/wiki/OrderingExplained) thực hiện một công việc tốt hơn để giải quyết vấn đề đó. –

+0

Phương pháp này không được sử dụng ở bất kỳ đâu trong JDK :) có thể vô ích. – ZhongYu

+0

điều duy nhất phương pháp này làm là kiểm tra xem cả hai đối số là null, trong trường hợp so sánh của bạn không kiểm tra cho trường hợp đó. khá vô dụng, giống như hầu hết các lớp học – njzk2

Trả lời

14

Điều này thật thú vị khi tìm hiểu. Lớp Objects, cùng với phương thức .compare() này, được giới thiệu trong số 3b45b809d8ff của Joe Darcy và thông báo cam kết trích dẫn Bug 6797535 và cho biết "Sherman" (Xueming Shen?) Đã đăng xuất trên đó. Ngoài lỗi có this thread từ tháng 9 năm 2009, thảo luận về các tính năng cần thêm vào Objects. Trong các chủ đề, thảo luận thêm các phương thức so sánh nguyên thủy compare(int, int) (và tương tự), và cuối cùng quyết định chúng nên nằm trong các lớp bao bọc tương ứng của chúng (xem Integer.compare()). Phương pháp này được giới thiệu later in that thread nhưng không có bất kỳ bình luận nào mà tôi có thể tìm thấy.

Sau a patch is sent out for review chứa Objects.compare(), và Joshua Bloch replies:

Tôi không nghĩ bạn nên thêm phương pháp này (so sánh (T một, T b, Comparator c)). Tiện ích của nó không rõ ràng, và nó không có tỷ lệ công suất trên của các phương thức khác trong lớp này.

Darcy responds:

Yeah, tôi có điều này với "Item 12: Xem xét việc thực hiện tương đương" từ EJv2 trong tâm trí.

Nó không rõ ràng với tôi những gì phương pháp này mang đến cho bảng liên quan đến Item 12, nhưng vấn đề dường như không được nâng lên một lần nữa. Tôi suy luận rằng mục đích là để cung cấp một phương pháp tương đương với nguyên thủy của compare() vì lý do phong cách, nhưng tôi đã không tìm thấy bằng chứng đó thực sự là lý do.


Đó là cần lưu ý rằng trong việc trao đổi giống nhau giữa Darcy và Bloch phương pháp Objects.toString() được tương tự chỉ trích bởi Bloch:

tôi sẽ chắc chắn/không/thêm phương pháp này (Objects.toString).Nó không mang gì đến cái bàn chưa có ở đó. Mọi người biết và sử dụng String.valueOf. Chúng ta hãy không bùn nước bằng cách thêm một lựa chọn khác.

Nhưng như chúng ta đều biết đó không bị xóa, Darcy chỉ đơn giản trả lời:

Vì vậy, lưu ý.


Vì vậy, trong kết luận, có vẻ như với tôi như thế này đã được giới thiệu mà không có nhiều ý định. Nó đã được đề xuất và các phản đối đã được nêu ra không chặn nó được kiểm tra. Tôi tưởng tượng rằng một đánh giá thiết kế nghiêm ngặt hơn sẽ có sai lầm về phía rời bỏ nó ra, như Bloch gợi ý.

Bạn cũng có thể quan tâm câu hỏi tương tự này (mặc dù đó là về một chi tiết thực hiện, không phải là một sự thay đổi API): Why is Arrays.fill() not used in HashMap.clear() anymore?

+2

Tiền thưởng đến. Cảm ơn bạn đã nghiên cứu và câu trả lời tuyệt vời của bạn. Một phần thưởng cho điều này là những gì chúng ta có thể học hỏi từ lịch sử: chủ yếu là những hiểu biết về thiết kế API nói chung, và những hiểu biết sâu sắc về các quy trình của Oracle. Cấp độ thần thánh Josh Bloch đã được xác nhận. Đó là một sự xấu hổ anh chàng không được hiển thị công khai nhiều hơn nữa. –

+1

Niềm vui của tôi :) Tôi luôn thích tìm hiểu tại sao các quyết định như thế này được thực hiện. – dimo414

Các vấn đề liên quan