Bounded Types và Generic Invariance trong Java

TL;DR: Bounded Type Parameters <T extends Bound> cho phép đặt giới hạn kiểu dữ liệu tham số hóa, mở quyền truy cập các phương thức nghiệp vụ của lớp biên mà không cần ép kiểu thủ công. Cơ chế Generic Invariance quy định rằng List<PrintedBook> không phải là lớp con của List<LibraryItem>, giúp loại bỏ hoàn toàn nguy cơ ClassCastException tại thời điểm biên dịch. Trái lại, mảng (Array) trong Java mang tính Covariant từ thời sơ khai, phải trả giá bằng việc kiểm tra kiểu tốn kém ở runtime và tiềm ẩn nguy cơ ném lỗi ArrayStoreException.

1. Bounded Type Parameters (<T extends Bound>) giải quyết bài toán gì?

Trong hệ thống quản lý ấn phẩm thư viện, giả sử bạn muốn viết một hàm tiện ích để tính tổng chi phí bảo hiểm của một danh mục các ấn phẩm vật lý (PhysicalMedia có phương thức getInsuranceValue()):

// Using Unbounded Type Parameter:
public static <T> double calculateInsuranceTotal(List<T> items) {
    double total = 0.0;
    for (T item : items) {
        // total += item.getInsuranceValue(); // COMPILE ERROR: Cannot find symbol!
    }
    return total;
}

Trình biên dịch từ chối vì T có thể là bất kỳ kiểu dữ liệu nào (kể cả String hay Thread), vốn không hề có phương thức getInsuranceValue().

Để giải quyết, ta sử dụng Bounded Type Parameter:

public static <T extends PhysicalMedia> double calculateInsuranceTotal(List<T> items) {
    double total = 0.0;
    for (T item : items) {
        total += item.getInsuranceValue(); // Valid: T is guaranteed to be PhysicalMedia
    }
    return total;
}

Từ khóa extends ở đây được dùng cho cả Class lẫn Interface. Cú pháp này truyền thông điệp cho trình biên dịch: "Kiểu T bắt buộc phải là PhysicalMedia hoặc bất kỳ lớp con nào kế thừa từ nó".

2. Áp dụng Multiple Bounds (<T extends A & B>) trong ngữ cảnh nào?

Trong các hệ thống phân tán hoặc xử lý lưu trữ tập trung, một thực thể nghiệp vụ thường phải thỏa mãn nhiều tiêu chí kỹ thuật đồng thời: vừa có thể so sánh thứ tự (Comparable), vừa có thể tuần tự hóa lưu trữ xuống ổ đĩa (Serializable):

public class CatalogDistributionService {
    // T must be both Comparable and Serializable:
    public static <T extends Comparable<? super T> & Serializable> void sortAndArchive(
            List<T> items, 
            OutputStream out
    ) throws IOException {
        Collections.sort(items); // Valid: T extends Comparable
        
        try (ObjectOutputStream oos = new ObjectOutputStream(out)) {
            oos.writeObject(items); // Valid: T extends Serializable
        }
    }
}

Quy tắc bất biến khi khai báo Multiple Bounds

1. Chỉ được phép chứa tối đa một lớp cụ thể (Class), tất cả các thành phần còn lại phải là giao diện (Interface).
2. Nếu có lớp cụ thể, lớp đó bắt buộc phải đứng ở vị trí đầu tiên:
   • ✅ Hợp lệ: <T extends LibraryItem & Serializable & Cloneable>
   • ❌ Lỗi biên dịch: <T extends Serializable & LibraryItem> (Interface đứng trước Class)
   • ❌ Lỗi biên dịch: <T extends LibraryItem & DigitalMedia> (Java không hỗ trợ đa kế thừa Class)

3. Quá trình Type Erasure xử lý Bounded Type khác Unbounded Type ra sao?

Tại bước biên dịch (Compile-time), Java thực hiện cơ chế xóa kiểu (Type Erasure):

• Với Unbounded Type (<T>): Trình biên dịch xóa T và thay thế bằng Object. Mọi lời gọi phương thức sau đó phải chèn lệnh ép kiểu checkcast.
• Với Bounded Type (<T extends PhysicalMedia>): Trình biên dịch xóa T về kiểu biên đầu tiên (First Bound) là PhysicalMedia.

// Source code before compilation:
public static <T extends PhysicalMedia> void inspect(T item) {
    item.verifyCondition();
}

// Equivalent bytecode after Type Erasure:
public static void inspect(PhysicalMedia item) {
    item.verifyCondition(); // Invoked directly without casting via Object
}

Nhờ đó, bytecode sinh ra gọn gàng hơn, loại bỏ các chỉ thị ép kiểu thừa và phát hiện toàn bộ sai lệch kiểu ngay từ bước biên dịch.

4. Vì sao Java bắt buộc Generic phải có tính chất Invariance?

Invariance (Bất biến phân cấp) phát biểu rằng: Dù PrintedBook là lớp con của LibraryItem, thì List<PrintedBook> hoàn toàn không phải là lớp con của List<LibraryItem>.

Hãy phân tích hậu quả nghiêm trọng nếu Java cho phép phép gán này:

// Hypothetical scenario if Java did NOT enforce Invariance:
List<PrintedBook> books = new ArrayList<>();
List<LibraryItem> items = books; // Supposing this assignment were valid...

items.add(new AudioBook("AB-99")); // Valid for List<LibraryItem>!

// When reading from original list:
PrintedBook book = books.get(0); // Throws ClassCastException at runtime!

Một danh sách books vốn được định kiểu nghiêm ngặt để chỉ chứa PrintedBook đã bị "nhiễm độc" bởi một đối tượng AudioBook. Để bảo vệ tính toàn vẹn kiểu dữ liệu của chương trình, Java áp đặt Invariance để dập tắt lỗi này ngay tại thời điểm biên dịch.

5. Vì sao Mảng (Array) Covariance lại là thiết kế lịch sử nguy hiểm?

Ngược lại với Generics, mảng trong Java mang tính chất Covariant (Hiệp biến) từ thời Java 1.0 (trước khi Generics ra đời): nếu S kế thừa từ T, thì S[] cũng kế thừa từ T[].

PrintedBook[] books = new PrintedBook[5];
LibraryItem[] items = books; // Compiler permits this (Covariant)

items[0] = new AudioBook("AB-01"); // Throws ArrayStoreException at runtime!

Để phát hiện sai lệch này, JVM buộc phải thực hiện phép kiểm tra kiểu (arraystore check) tại mỗi một thao tác ghi vào mảng, gây lãng phí chu kỳ CPU. Generics với tính chất Invariance đã sửa chữa sai lầm lịch sử này: không tốn chi phí kiểm tra ở runtime, bảo đảm an toàn tuyệt đối lúc biên dịch.

6. Phân biệt Bounded Type Parameter và Bounded Wildcard khi nào?

Lập trình viên thường bối rối giữa <T extends Number> và ? extends Number. Hãy nhớ quy tắc đơn giản:

• Dùng Bounded Type Parameter (<T extends Bound>) khi:
  1. Bạn cần thiết lập mối liên kết giữa nhiều tham số đầu vào hoặc giữa tham số và kiểu trả về (ví dụ: T process(T input)).
  2. Bạn cần sử dụng nhiều biên cùng lúc (Multiple bounds với &).
  3. Bạn cần khai báo biến cục bộ cùng kiểu bên trong thân phương thức.
• Dùng Bounded Wildcard (? extends Bound) khi:
  1. Bạn chỉ cần nới lỏng giới hạn đầu vào của Collection để đọc dữ liệu theo nguyên tắc PECS (xem chi tiết tại Bài 03 — Wildcard và PECS).

7. Recursive Type Bound (<T extends Comparable<T>>) hoạt động thế nào?

Một trong những ứng dụng cao cấp và tinh tế nhất của Bounded Type là Recursive Type Bound (Ràng buộc kiểu đệ quy):

public static <T extends Comparable<T>> T findMax(List<T> list) {
    if (list.isEmpty()) throw new NoSuchElementException();
    T max = list.get(0);
    for (T item : list) {
        if (item.compareTo(max) > 0) {
            max = item;
        }
    }
    return max;
}

Cú pháp <T extends Comparable<T>> có nghĩa là: "Kiểu T là một kiểu có thể so sánh trực tiếp với chính các đối tượng cùng kiểu T".

Phiên bản nâng cao chuẩn mực trong JDK: <T extends Comparable<? super T>>

Nếu một lớp cha LibraryItem cài đặt Comparable<LibraryItem>, và lớp con PrintedBook kế thừa từ LibraryItem. Lúc này, PrintedBook chỉ cài đặt Comparable<LibraryItem> chứ không phải Comparable<PrintedBook>.

Nếu dùng cú pháp cứng nhắc <T extends Comparable<T>>, lời gọi findMax(printedBooks) sẽ bị từ chối! Để khắc phục, chữ ký chuẩn của JDK (như trong Collections.max()) luôn kết hợp với Wildcard:

public static <T extends Comparable<? super T>> T findMax(List<T> list)

Chữ ký này cho phép so sánh cả khi giao diện Comparable được cài đặt ở bất kỳ lớp cha nào trong cây phả hệ kế thừa.

8. Đọc thêm từ tài liệu Oracle và các liên kết liên quan

9. Tóm tắt các điểm mấu chốt

• Bounded Type Parameter mở rộng khả năng của biến generic bằng cách bảo đảm các phương thức của lớp biên luôn sẵn sàng.
• Multiple Bounds hỗ trợ nhiều interface nhưng tối đa chỉ một class và class đó phải đứng đầu tiên.
• Generic Invariance ngăn chặn việc gán sai kiểu ở thời điểm biên dịch, triệt tiêu nguy cơ ClassCastException.
• Mảng mang tính Covariant tiềm ẩn lỗi ArrayStoreException ở runtime và tốn chi phí kiểm tra kiểu của máy ảo.
• Ràng buộc kiểu đệ quy <T extends Comparable<? super T>> là mẫu thiết kế tối ưu nhất khi làm việc với các thực thể có quan hệ kế thừa so sánh.

10. Câu hỏi tự kiểm tra

Bài tiếp theo: Mini Challenge — Thiết kế bộ nhớ đệm LRU Cache