Tại sao mảng covariant nhưng generic là bất biến?

Từ Java hiệu quả của Joshua Bloch,

1. Mảng khác với loại chung theo hai cách quan trọng. Mảng đầu tiên là covariant. Thế hệ là bất biến.

2. Covariant đơn giản có nghĩa là nếu X là kiểu con của Y thì X [] cũng sẽ là kiểu con của Y []. Mảng là covariant Vì chuỗi là kiểu con của Object So

   String[] is subtype of Object[]

   Bất biến đơn giản có nghĩa là không phân biệt X có phải là kiểu con của Y hay không,

    List<X> will not be subType of List<Y>.

Câu hỏi của tôi là tại sao quyết định tạo mảng covariant trong Java? Có các bài viết SO khác như Tại sao Mảng bất biến, nhưng Danh sách covariant? , nhưng họ dường như tập trung vào Scala và tôi không thể theo dõi.

Qua wikipedia :

Các phiên bản ban đầu của Java và C # không bao gồm thuốc generic (hay còn gọi là đa hình tham số).

Trong một thiết lập như vậy, làm cho các mảng bất biến quy tắc ra các chương trình đa hình hữu ích. Ví dụ, hãy xem xét việc viết một hàm để xáo trộn một mảng hoặc một hàm kiểm tra hai mảng về sự bằng nhau bằng cách sử dụng Object.equalsphương thức trên các phần tử. Việc thực hiện không phụ thuộc vào loại phần tử chính xác được lưu trữ trong mảng, do đó có thể viết một hàm duy nhất hoạt động trên tất cả các loại mảng. Thật dễ dàng để thực hiện các chức năng của loại

boolean equalArrays (Object[] a1, Object[] a2);
void shuffleArray(Object[] a);

Tuy nhiên, nếu các kiểu mảng được coi là bất biến, thì chỉ có thể gọi các hàm này trên một mảng có chính xác kiểu Object[]. Chẳng hạn, người ta không thể xáo trộn một chuỗi các chuỗi.

Do đó, cả Java và C # đều xử lý các kiểu mảng một cách ngẫu nhiên. Chẳng hạn, trong C # string[]là một kiểu con của object[]và trong Java String[]là một kiểu con của Object[].

Này trả lời cho câu hỏi "Tại sao các mảng hiệp biến?", Hay chính xác hơn, "Tại sao là mảng làm hiệp biến vào thời điểm đó ?"

Khi thuốc generic được giới thiệu, chúng cố tình không tạo ra sự đồng biến vì những lý do được chỉ ra trong câu trả lời này của Jon Skeet :

Không, a List<Dog>không phải là a List<Animal>. Xem xét những gì bạn có thể làm với một List<Animal>- bạn có thể thêm bất kỳ động vật nào vào đó ... bao gồm cả một con mèo. Bây giờ, bạn có thể thêm một cách hợp lý một con mèo vào một lứa chó con? Tuyệt đối không.

// Illegal code - because otherwise life would be Bad
List<Dog> dogs = new List<Dog>();
List<Animal> animals = dogs; // Awooga awooga
animals.add(new Cat());
Dog dog = dogs.get(0); // This should be safe, right?

Đột nhiên bạn có một con mèo rất bối rối.

Động lực ban đầu để tạo ra các mảng đồng biến được mô tả trong bài viết trên wikipedia không áp dụng cho khái quát vì các ký tự đại diện có thể biểu thị hiệp phương sai (và chống chỉ định), ví dụ:

boolean equalLists(List<?> l1, List<?> l2);
void shuffleList(List<?> l);

Lý do là mọi mảng đều biết loại phần tử của nó trong thời gian chạy, trong khi bộ sưu tập chung không vì loại xóa.

Ví dụ:

String[] strings = new String[2];
Object[] objects = strings;  // valid, String[] is Object[]
objects[0] = 12; // error, would cause java.lang.ArrayStoreException: java.lang.Integer during runtime

Nếu điều này được cho phép với các bộ sưu tập chung:

List<String> strings = new ArrayList<String>();
List<Object> objects = strings;  // let's say it is valid
objects.add(12);  // invalid, Integer should not be put into List<String> but there is no information during runtime to catch this

Nhưng điều này sẽ gây ra vấn đề sau này khi ai đó sẽ cố gắng truy cập danh sách:

String first = strings.get(0); // would cause ClassCastException, trying to assign 12 to String

Có thể là sự giúp đỡ này : -

Generics không covariant

Mảng trong ngôn ngữ Java là covariant - có nghĩa là nếu Integer mở rộng Số (mà nó làm), thì không chỉ là Số nguyên mà còn là Số, mà còn là một Số nguyên Number[], và bạn có thể tự do chuyển hoặc gán Integer[]trong đó a Number[]được gọi là (Chính thức hơn, nếu Number là một siêu kiểu của Integer, thì đó Number[]là một siêu kiểu của Integer[].) Bạn có thể nghĩ điều tương tự cũng đúng với các loại chung - đó List<Number>là một siêu kiểu List<Integer>, và bạn có thể vượt qua List<Integer>nơi mà một người List<Number>được mong đợi. Thật không may, nó không hoạt động theo cách đó.

Hóa ra có một lý do chính đáng để nó không hoạt động theo cách đó: Nó sẽ phá vỡ các loại thuốc an toàn được cho là sẽ cung cấp. Hãy tưởng tượng bạn có thể gán a List<Integer>cho a List<Number>. Sau đó, đoạn mã sau sẽ cho phép bạn đặt thứ gì đó không phải là Số nguyên vào List<Integer>:

List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // illegal
ln.add(new Float(3.1415));

Bởi vì ln là một List<Number>, thêm một Float vào nó có vẻ hoàn toàn hợp pháp. Nhưng nếu ln được đặt bí danh li, thì nó sẽ phá vỡ lời hứa an toàn kiểu ẩn trong định nghĩa của li - rằng đó là một danh sách các số nguyên, đó là lý do tại sao các loại chung không thể đồng biến.

Mảng là covariant vì ít nhất hai lý do:

• Nó rất hữu ích cho các bộ sưu tập chứa thông tin sẽ không bao giờ thay đổi thành covariant. Để một tập hợp T là covariant, cửa hàng sao lưu của nó cũng phải là covariant. Mặc dù người ta có thể thiết kế một Tbộ sưu tập bất biến không sử dụng T[]làm cửa hàng sao lưu của nó (ví dụ: sử dụng một cây hoặc danh sách được liên kết), một bộ sưu tập như vậy sẽ khó có thể thực hiện cũng như được hỗ trợ bởi một mảng. Người ta có thể lập luận rằng một cách tốt hơn để cung cấp cho các bộ sưu tập bất biến đồng biến sẽ là xác định loại "mảng bất biến covariant" mà họ có thể sử dụng một cửa hàng sao lưu, nhưng đơn giản là cho phép hiệp phương sai có thể dễ dàng hơn.

• Mảng sẽ thường xuyên bị đột biến bởi mã mà không biết loại sự việc nào sẽ xảy ra trong chúng, nhưng sẽ không đưa vào mảng bất cứ thứ gì không được đọc từ cùng một mảng. Một ví dụ điển hình của việc này là sắp xếp mã. Về mặt khái niệm, các kiểu mảng có thể bao gồm các phương thức để hoán đổi hoặc hoán vị các phần tử (các phương thức đó có thể áp dụng như nhau cho bất kỳ loại mảng nào) hoặc định nghĩa một đối tượng "trình điều khiển mảng" có tham chiếu đến một mảng và một hoặc nhiều điều đã được đọc từ nó và có thể bao gồm các phương thức để lưu trữ các mục đã đọc trước đó vào mảng mà chúng đã đến. Nếu các mảng không phải là biến số, mã người dùng sẽ không thể xác định loại như vậy, nhưng thời gian chạy có thể bao gồm một số phương thức chuyên biệt.

Thực tế là các mảng là covariant có thể được xem là một hack xấu xí, nhưng trong hầu hết các trường hợp, nó tạo điều kiện cho việc tạo mã làm việc.

Một tính năng quan trọng của các loại tham số là khả năng viết các thuật toán đa hình, tức là các thuật toán hoạt động trên cấu trúc dữ liệu bất kể giá trị tham số của nó, chẳng hạn như Arrays.sort().

Với thuốc generic, điều đó được thực hiện với các loại ký tự đại diện:

<E extends Comparable<E>> void sort(E[]);

Để thực sự hữu ích, các loại ký tự đại diện yêu cầu chụp ký tự đại diện và điều đó đòi hỏi phải có khái niệm về một tham số loại. Không có cái nào có sẵn tại các mảng thời gian được thêm vào Java và việc tạo các mảng của kiểu tham chiếu kiểu tham chiếu cho phép một cách đơn giản hơn nhiều để cho phép các thuật toán đa hình:

void sort(Comparable[]);

Tuy nhiên, sự đơn giản đó đã mở một lỗ hổng trong hệ thống kiểu tĩnh:

String[] strings = {"hello"};
Object[] objects = strings;
objects[0] = 1; // throws ArrayStoreException

yêu cầu kiểm tra thời gian chạy của mọi truy cập ghi vào một mảng kiểu tham chiếu.

Tóm lại, cách tiếp cận mới hơn được thể hiện bằng khái quát làm cho hệ thống loại phức tạp hơn, nhưng cũng an toàn hơn về mặt tĩnh, trong khi cách tiếp cận cũ đơn giản hơn và loại an toàn tĩnh hơn. Các nhà thiết kế ngôn ngữ đã chọn cách tiếp cận đơn giản hơn, có nhiều việc quan trọng hơn là đóng một lỗ hổng nhỏ trong hệ thống loại hiếm khi gây ra vấn đề. Sau này, khi Java được thiết lập và các nhu cầu cấp thiết được quan tâm, họ có tài nguyên để thực hiện đúng cho các tổng quát (nhưng thay đổi nó thành các mảng sẽ phá vỡ các chương trình Java hiện có).

Generics là bất biến : từ JSL 4.10 :

... Subtyping không mở rộng thông qua các loại chung: T <: U không ngụ ý rằng C<T><: C<U>...

và một vài dòng nữa, JLS cũng giải thích rằng
Mảng là covariant (viên đạn đầu tiên):

4.10.3 Phân nhóm giữa các loại mảng

Tôi nghĩ rằng họ đã đưa ra một quyết định sai lầm ngay từ đầu đã tạo ra sự đồng biến mảng. Nó phá vỡ sự an toàn kiểu như được mô tả ở đây và họ đã bị mắc kẹt vì điều đó vì tính tương thích ngược và sau đó họ đã cố gắng không mắc lỗi tương tự cho chung chung. Và đó là một trong những lý do khiến Joshua Bloch thích liệt kê danh sách của arra ys trong Mục 25 của cuốn sách "Java hiệu quả (ấn bản thứ hai)"

Của tôi: Khi mã đang mong đợi một mảng A [] và bạn cung cấp cho nó B [] trong đó B là một lớp con của A, chỉ có hai điều cần lo lắng: điều gì xảy ra khi bạn đọc một phần tử mảng và điều gì xảy ra nếu bạn viết nó Vì vậy, không khó để viết các quy tắc ngôn ngữ để đảm bảo rằng an toàn loại được bảo toàn trong mọi trường hợp (quy tắc chính là ArrayStoreExceptioncó thể bị ném nếu bạn cố gắn A vào B []). Tuy nhiên, đối với một người chung chung, khi bạn khai báo một lớp SomeClass<T>, có thể có bất kỳ cách nào Tđược sử dụng trong phần thân của lớp và tôi đoán rằng nó quá phức tạp để tìm ra tất cả các kết hợp có thể để viết quy tắc khi nào mọi thứ được cho phép và khi chúng không.