Phương thức có cùng cách xóa với phương thức khác trong loại

Tại sao không hợp pháp khi có hai phương thức sau trong cùng một lớp?

class Test{
   void add(Set<Integer> ii){}
   void add(Set<String> ss){}
}

Tôi hiểu compilation error

Phương thức add (Set) có cùng phương thức erasure (Set) như một phương thức khác trong kiểu Test.

Trong khi tôi có thể làm việc xung quanh nó, tôi đã tự hỏi tại sao javac không thích điều này.

Tôi có thể thấy rằng trong nhiều trường hợp, logic của hai phương thức đó sẽ rất giống nhau và có thể được thay thế bằng một

public void add(Set<?> set){}

phương pháp, nhưng điều này không phải lúc nào cũng đúng.

Điều này cực kỳ khó chịu nếu bạn muốn có hai constructorsđối số lấy các đối số đó vì sau đó bạn không thể thay đổi tên của một trong số đó constructors.

Quy tắc này nhằm tránh xung đột trong mã kế thừa vẫn sử dụng các loại thô.

Đây là một minh họa về lý do tại sao điều này không được phép, được rút ra từ JLS. Giả sử, trước khi thuốc generic được giới thiệu cho Java, tôi đã viết một số mã như thế này:

class CollectionConverter {
  List toList(Collection c) {...}
}

Bạn mở rộng lớp học của tôi, như thế này:

class Overrider extends CollectionConverter{
  List toList(Collection c) {...}
}

Sau khi giới thiệu thuốc generic, tôi quyết định cập nhật thư viện của mình.

class CollectionConverter {
  <T> List<T> toList(Collection<T> c) {...}
}

Bạn chưa sẵn sàng để thực hiện bất kỳ cập nhật nào, vì vậy bạn rời khỏi Overriderlớp học của mình. Để ghi đè chính xác toList()phương thức, các nhà thiết kế ngôn ngữ đã quyết định rằng một loại thô là "tương đương ghi đè" với bất kỳ loại tổng quát nào. Điều này có nghĩa là mặc dù chữ ký phương thức của bạn không còn chính thức bằng chữ ký của siêu lớp của tôi, phương thức của bạn vẫn ghi đè.

Bây giờ, thời gian trôi qua và bạn quyết định bạn đã sẵn sàng để cập nhật lớp học của mình. Nhưng bạn làm hỏng một chút và thay vì chỉnh sửa toList()phương thức thô, hiện có , bạn thêm một phương thức mới như thế này:

class Overrider extends CollectionConverter {
  @Override
  List toList(Collection c) {...}
  @Override
  <T> List<T> toList(Collection<T> c) {...}
}

Do sự tương đương ghi đè của các loại thô, cả hai phương thức đều ở dạng hợp lệ để ghi đè toList(Collection<T>)phương thức. Nhưng tất nhiên, trình biên dịch cần giải quyết một phương thức duy nhất. Để loại bỏ sự mơ hồ này, các lớp không được phép có nhiều phương thức tương đương với ghi đè, đó là nhiều phương thức có cùng loại tham số sau khi xóa.

Điều quan trọng là đây là một quy tắc ngôn ngữ được thiết kế để duy trì khả năng tương thích với mã cũ bằng cách sử dụng các loại thô. Nó không phải là một giới hạn theo yêu cầu của việc xóa các tham số loại; bởi vì độ phân giải phương thức xảy ra tại thời gian biên dịch, việc thêm các kiểu chung vào mã định danh phương thức sẽ là đủ.

Java generic sử dụng kiểu xóa. Bit trong dấu ngoặc nhọn ( <Integer>và <String>) bị xóa, do đó, bạn kết thúc bằng hai phương thức có chữ ký giống hệt nhau ( add(Set)bạn thấy trong lỗi). Điều đó không được phép vì thời gian chạy sẽ không biết nên sử dụng cho từng trường hợp.

Nếu Java từng có các tổng quát thống nhất, thì bạn có thể làm điều này, nhưng điều đó có lẽ không thể xảy ra bây giờ.

Điều này là do Java Generics được triển khai với Type Erasure .

Các phương thức của bạn sẽ được dịch, tại thời điểm biên dịch, thành một cái gì đó như:

Phương pháp giải quyết xảy ra tại thời gian biên dịch và không xem xét các tham số loại. ( xem câu trả lời của erickson )

void add(Set ii);
void add(Set ss);

Cả hai phương thức có cùng chữ ký mà không có tham số loại, do đó lỗi.

Vấn đề là điều đó Set<Integer>và Set<String>thực sự được coi là một Settừ JVM. Chọn một loại cho Tập hợp (Chuỗi hoặc Số nguyên trong trường hợp của bạn) chỉ là đường cú pháp được sử dụng bởi trình biên dịch. JVM không thể phân biệt giữa Set<String>và Set<Integer>.

Xác định một Phương thức duy nhất không có kiểu như void add(Set ii){}

Bạn có thể đề cập đến loại trong khi gọi phương thức dựa trên sự lựa chọn của bạn. Nó sẽ làm việc cho bất kỳ loại thiết lập.

Có thể trình biên dịch dịch Set (Integer) thành Set (Object) trong mã byte java. Nếu đây là trường hợp, Set (Integer) sẽ chỉ được sử dụng ở giai đoạn biên dịch để kiểm tra cú pháp.

Tôi đã va vào điều này khi cố gắng viết một cái gì đó như: Continuable<T> callAsync(Callable<T> code) {....} và Continuable<Continuable<T>> callAsync(Callable<Continuable<T>> veryAsyncCode) {...} chúng trở thành trình biên dịch cho 2 định nghĩa về Continuable<> callAsync(Callable<> veryAsyncCode) {...}

Kiểu xóa theo nghĩa đen có nghĩa là xóa thông tin đối số kiểu từ tổng quát. Điều này thật phiền phức, nhưng đây là một hạn chế sẽ xảy ra với Java trong một thời gian. Đối với trường hợp hàm tạo không thể thực hiện được nhiều, 2 lớp con mới chuyên với các tham số khác nhau trong hàm tạo chẳng hạn. Hoặc sử dụng các phương thức khởi tạo thay vì ... (các hàm tạo ảo?) Với các tên khác nhau ...

đối với các phương thức hoạt động tương tự, việc đổi tên sẽ giúp ích, như

class Test{
   void addIntegers(Set<Integer> ii){}
   void addStrings(Set<String> ss){}
}

Hoặc với một số tên mô tả nhiều hơn, tự viết tài liệu cho các trường hợp oyu, như addNamesvà addIndexeshoặc như vậy.