Các lý do tại sao Map.get (Khóa đối tượng) không chung chung (đầy đủ)

Các lý do đằng sau quyết định không có một phương thức get hoàn toàn chung chung trong giao diện của java.util.Map<K, V>.

Để làm rõ câu hỏi, chữ ký của phương pháp là

V get(Object key)

thay vì

V get(K key)

và tôi tự hỏi tại sao (điều tương tự cho remove, containsKey, containsValue).

Như đã đề cập bởi những người khác, lý do tại sao get(), v.v. không chung chung vì khóa của mục bạn đang truy xuất không phải cùng loại với đối tượng mà bạn chuyển đến get(); đặc tả của phương thức chỉ yêu cầu chúng bằng nhau. Điều này xuất phát từ cách equals()phương thức lấy một đối tượng làm tham số, không chỉ cùng loại với đối tượng.

Mặc dù có thể đúng là nhiều lớp đã equals()định nghĩa sao cho các đối tượng của nó chỉ có thể bằng với các đối tượng của lớp của chính nó, có nhiều nơi trong Java không phải là trường hợp này. Ví dụ, đặc tả cho List.equals()biết hai đối tượng List bằng nhau nếu cả hai đều là List và có cùng nội dung, ngay cả khi chúng là các cách triển khai khác nhau List. Vì vậy, quay trở lại ví dụ trong câu hỏi này, theo đặc điểm kỹ thuật của phương thức có thể có một Map<ArrayList, Something>và để tôi gọi get()với một LinkedListđối số là, và nó sẽ lấy ra khóa là một danh sách có cùng nội dung. Điều này sẽ không thể xảy ra nếu get()chung chung và hạn chế loại đối số của nó.

Một lập trình viên Java tuyệt vời tại Google, Kevin Bourrillion, đã viết về chính xác vấn đề này trong một bài đăng trên blog cách đây một thời gian (phải thừa nhận trong bối cảnh Setthay vì Map). Câu liên quan nhất:

Đồng nhất, các phương thức của Khung bộ sưu tập Java (và Thư viện bộ sưu tập của Google cũng vậy) không bao giờ hạn chế các loại tham số của chúng trừ khi cần thiết để ngăn bộ sưu tập bị hỏng.

Tôi không hoàn toàn chắc chắn rằng tôi đồng ý với nguyên tắc này - .NET dường như vẫn ổn khi yêu cầu đúng loại khóa, chẳng hạn - nhưng nó đáng để tuân theo lý luận trong bài đăng trên blog. (Đã đề cập đến .NET, đáng để giải thích rằng một phần lý do tại sao nó không phải là vấn đề trong .NET là có vấn đề lớn hơn trong .NET về phương sai hạn chế hơn ...)

Hợp đồng được thể hiện như vậy:

Chính thức hơn, nếu bản đồ này chứa ánh xạ từ khóa k đến giá trị v sao cho (key == null? K == null: key.equals (k) ), thì phương thức này trả về v; nếu không nó trả về null. (Có thể có nhiều nhất một ánh xạ như vậy.)

(nhấn mạnh của tôi)

và như vậy, việc tra cứu khóa thành công phụ thuộc vào việc triển khai phương thức bình đẳng của khóa đầu vào. Điều đó không nhất thiết phụ thuộc vào lớp k.

Đó là một ứng dụng của Luật Postel, "hãy thận trọng trong những gì bạn làm, hãy tự do trong những gì bạn chấp nhận từ người khác."

Kiểm tra bình đẳng có thể được thực hiện bất kể loại; các equalsphương pháp được định nghĩa trên Objectlớp và chấp nhận bất kỳ Objectnhư một tham số. Vì vậy, nó có ý nghĩa đối với sự tương đương chính và các hoạt động dựa trên sự tương đương chính, để chấp nhận bất kỳ Objectloại nào .

Khi bản đồ trả về các giá trị chính, nó sẽ bảo tồn càng nhiều thông tin loại càng tốt, bằng cách sử dụng tham số loại.

Tôi nghĩ phần này của Generics Tutorial giải thích tình huống (sự nhấn mạnh của tôi):

"Bạn cần chắc chắn rằng API chung không bị hạn chế quá mức, nó phải tiếp tục hỗ trợ hợp đồng ban đầu của API. Hãy xem xét lại một số ví dụ từ java.util.Collection. API tiền chung giống như:

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

Một nỗ lực ngây thơ để khái quát nó là:

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

Mặc dù điều này chắc chắn là an toàn, nhưng nó không tuân theo hợp đồng ban đầu của API. Phương thức chứa All () hoạt động với bất kỳ loại bộ sưu tập nào đến. Nó sẽ chỉ thành công nếu bộ sưu tập đến thực sự chỉ chứa các phiên bản của E, nhưng:

• Kiểu tĩnh của bộ sưu tập đến có thể khác nhau, có lẽ vì người gọi không biết loại chính xác của bộ sưu tập được truyền vào hoặc có thể vì đó là Bộ sưu tập <S>, trong đó S là một kiểu con của E.
• Việc gọi hàm ALL () với một bộ sưu tập thuộc loại khác là hoàn toàn hợp pháp. Các thói quen nên làm việc, trả lại sai. "

Lý do là ngăn chặn được xác định bởi equalsvà hashCodeđó là các phương thức trên Objectvà cả hai đều lấy Objecttham số. Đây là một lỗ hổng thiết kế ban đầu trong các thư viện tiêu chuẩn của Java. Cùng với các hạn chế trong hệ thống loại của Java, nó buộc mọi thứ liên quan đến bằng và hashCode phải thực hiện Object.

Cách duy nhất để có bảng băm kiểu an toàn và bình đẳng trong Java là để tránh né Object.equalsvà Object.hashCodevà sử dụng để thay thế chung. Java chức năng đi kèm với các lớp loại cho mục đích này: Hash<A>và Equal<A>. Một trình bao bọc HashMap<K, V>được cung cấp có Hash<K>và Equal<K>trong hàm tạo của nó. Do đó, các phương thức getvà lớp này containscó một đối số chung về kiểu K.

Thí dụ:

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

Khả năng tương thích.

Trước khi thuốc generic có sẵn, chỉ có get (Object o).

Nếu họ thay đổi phương thức này để có được (<K> o) thì nó sẽ có khả năng buộc phải bảo trì mã lớn cho người dùng java chỉ để làm cho mã hoạt động được biên dịch lại.

Họ có thể đã giới thiệu một phương thức bổ sung , giả sử get_checked (<K> o) và không dùng phương thức get () cũ để có đường dẫn chuyển tiếp nhẹ nhàng hơn. Nhưng vì một số lý do, điều này đã không được thực hiện. (Tình huống hiện tại của chúng tôi là bạn cần cài đặt các công cụ như findBugs để kiểm tra tính tương thích của loại giữa đối số get () và loại khóa được khai báo <K> của bản đồ.)

Các đối số liên quan đến ngữ nghĩa của .equals () là không có thật, tôi nghĩ vậy. .

Có một lý do nặng nề hơn, nó không thể được thực hiện về mặt kỹ thuật, bởi vì nó làm hỏng Bản đồ.

Java có cấu trúc chung đa hình như thế nào <? extends SomeClass>. Đánh dấu tham chiếu như vậy có thể trỏ đến loại đã ký với <AnySubclassOfSomeClass>. Nhưng chung đa hình làm cho tham chiếu đó chỉ đọc . Trình biên dịch cho phép bạn chỉ sử dụng các kiểu chung như kiểu trả về của phương thức (như các getters đơn giản), nhưng các khối sử dụng các phương thức trong đó kiểu chung là đối số (như setters thông thường). Nó có nghĩa là nếu bạn viết Map<? extends KeyType, ValueType>, trình biên dịch không cho phép bạn gọi phương thức get(<? extends KeyType>)và bản đồ sẽ vô dụng. Giải pháp duy nhất là làm cho phương thức này không chung chung : get(Object).

Tương thích ngược, tôi đoán. Map(hoặc HashMap) vẫn cần hỗ trợ get(Object).

Tôi đã nhìn vào điều này và nghĩ tại sao họ làm theo cách này. Tôi không nghĩ bất kỳ câu trả lời hiện có nào giải thích lý do tại sao họ không thể làm cho giao diện chung mới chỉ chấp nhận loại thích hợp cho khóa. Lý do thực tế là mặc dù họ đã giới thiệu thuốc generic nhưng họ KHÔNG tạo ra giao diện mới. Giao diện Bản đồ là bản đồ không chung chung cũ, nó chỉ đóng vai trò là cả phiên bản chung và không chung. Bằng cách này nếu bạn có một phương thức chấp nhận Bản đồ không chung chung, bạn có thể vượt qua nó Map<String, Customer>và nó vẫn hoạt động. Đồng thời hợp đồng nhận được đối tượng nên giao diện mới cũng hỗ trợ hợp đồng này.

Theo tôi, họ nên đã thêm một giao diện mới và triển khai cả trên bộ sưu tập hiện có nhưng họ đã quyết định ủng hộ các giao diện tương thích ngay cả khi nó có nghĩa là thiết kế tồi hơn cho phương thức get. Lưu ý rằng bản thân các bộ sưu tập sẽ chỉ tương thích với các phương thức hiện có.

Chúng tôi đang thực hiện tái cấu trúc lớn ngay bây giờ và chúng tôi đã bỏ lỡ get () được gõ mạnh này để kiểm tra xem chúng tôi đã không bỏ lỡ một số get () với loại cũ.

Nhưng tôi đã tìm thấy một cách giải quyết / mẹo xấu để kiểm tra thời gian biên dịch: tạo giao diện Bản đồ với kiểu gõ mạnh get, chứaKey, xóa ... và đặt nó vào gói java.util của dự án của bạn.

Bạn sẽ nhận được các lỗi biên dịch chỉ khi gọi get (), ... với các loại sai, mọi thứ khác có vẻ ổn đối với trình biên dịch (ít nhất là bên trong kepler nhật thực).

Đừng quên xóa giao diện này sau khi kiểm tra bản dựng của bạn vì đây không phải là thứ bạn muốn trong thời gian chạy.