Sealed class — kiểm soát tập subtype với pattern matching exhaustive

TL;DR: Sealed class và interface (Java 17+) cho phép kiểm soát chính xác những lớp nào được phép kế thừa thông qua mệnh đề permits. Khi kết hợp với Record và Switch Pattern Matching (Java 21), lập trình viên có thể xây dựng cấu trúc Algebraic Data Types (ADT) an toàn tuyệt đối tại thời điểm biên dịch, loại bỏ nguy cơ sót trường hợp xử lý mà không cần dùng đến nhánh default.

Trước Java 17, để biểu diễn một tập hữu hạn các lựa chọn, lập trình viên thường dùng enum. Nhưng enum chỉ biểu diễn các hằng số đơn lẻ, không thể cho phép mỗi nhánh mang các cấu trúc dữ liệu với kiểu khác nhau. Java 17 chuẩn hoá Sealed Classes (JEP 409), mở ra kỷ nguyên lập trình hướng dữ liệu (Data-Oriented Programming) hiện đại trong Java.

1. Tại sao cây kế thừa mở tự do lại gây rủi ro cho nghiệp vụ?

Trong hệ thống quản lý mượn trả ấn phẩm của thư viện, kết quả của một giao dịch mượn sách (BorrowResult) chỉ có thể rơi vào một trong ba tình huống xác thực:

1. Success: Mượn thành công, trả về ngày hết hạn và mã mượn.
2. ItemReserved: Thất bại vì ấn phẩm đang được giữ chỗ bởi bạn đọc khác.
3. AccountSuspended: Thất bại vì thẻ thư viện bị khoá, đi kèm lý do và số tiền phạt tồn đọng.

Nếu BorrowResult là một interface thông thường (mở tự do), một lập trình viên khác có thể tạo thêm class PendingApproval implements BorrowResult. Toàn bộ các module thanh toán hay quầy mượn sách đang chạy sẽ hoàn toàn không biết cách xử lý lớp con mới này, dẫn đến nguy cơ rơi vào nhánh lỗi hoặc gây sụp đổ logic lúc chạy.

Sealed Interface ra đời để khoá chặt tập khả năng này:

public sealed interface BorrowResult permits Success, ItemReserved, AccountSuspended {
}

public record Success(String loanId, LocalDate dueDate) implements BorrowResult { }
public record ItemReserved(String reservedByMemberId) implements BorrowResult { }
public record AccountSuspended(String reason, double outstandingFine) implements BorrowResult { }

Compiler cam kết với bạn: ngoài ba trường hợp trên, không một lớp nào khác trong toàn bộ dự án có thể tự tiện implements BorrowResult.

2. Cú pháp Sealed Class và từ khoá permits

Sealed có thể áp dụng cho cả class lẫn interface. Khi khai báo, lớp cha liệt kê danh sách subtype được phép qua từ khoá permits:

public abstract sealed class LibraryAsset permits PhysicalBook, DigitalMedia, Periodical {
    private final String barcode;
    private final String title;

    protected LibraryAsset(String barcode, String title) {
        this.barcode = barcode;
        this.title = title;
    }

    public String getBarcode() { return barcode; }
    public String getTitle() { return title; }
}

Nếu một lớp khác cố tình kế thừa LibraryAsset:

// Loi bien dich ngay lap tuc: class is not allowed to extend sealed class: LibraryAsset
public class CustomEquipment extends LibraryAsset {
    public CustomEquipment(String barcode, String title) {
        super(barcode, title);
    }
}

Nếu tất cả các lớp con được khai báo trong cùng một file .java với sealed parent, bạn có thể lược bỏ hoàn toàn mệnh đề permits. Compiler sẽ tự động suy luận danh sách cho phép từ các lớp con có mặt trong file đó.

3. Ba lựa chọn bắt buộc cho Subtype: final, sealed và non-sealed

Một quy tắc bất di bất dịch của Java: Mọi lớp con trực tiếp kế thừa từ sealed class/interface bắt buộc phải chọn chính xác một trong ba trạng thái kế thừa:

Minh hoạ tổ chức cây phân cấp:

// 1. final: Dong han
public final class PhysicalBook extends LibraryAsset {
    private final String shelfNumber;

    public PhysicalBook(String barcode, String title, String shelfNumber) {
        super(barcode, title);
        this.shelfNumber = shelfNumber;
    }
}

// 2. sealed: Tiep tuc kiem soat cac lop con cap 2
public abstract sealed class DigitalMedia extends LibraryAsset permits AudioBook, EbookArchive {
    protected DigitalMedia(String barcode, String title) {
        super(barcode, title);
    }
}

public final class AudioBook extends DigitalMedia {
    public AudioBook(String barcode, String title) { super(barcode, title); }
}

public final class EbookArchive extends DigitalMedia {
    public EbookArchive(String barcode, String title) { super(barcode, title); }
}

// 3. non-sealed: Mo tu do cho plugin hoac client tu extends
public non-sealed class Periodical extends LibraryAsset {
    public Periodical(String barcode, String title) {
        super(barcode, title);
    }
}

// Cac lop khac duoc phep extends Periodical tu do vi no la non-sealed
public class MedicalJournal extends Periodical {
    public MedicalJournal(String barcode, String title) { super(barcode, title); }
}

Nhờ cơ chế này, bạn có thể thiết kế kiến trúc phân tầng kết hợp (hybrid): phần cốt lõi được niêm phong để đảm bảo an toàn nghiệp vụ, trong khi các điểm mở rộng (extension points) được cởi mở bằng non-sealed.

4. Kiểm tra vét cạn (Exhaustive Pattern Matching) với Switch

Lợi ích thực tế lớn nhất của Sealed Class xuất hiện khi phối hợp cùng biểu thức switch trong Java 21:

public String generateNotification(BorrowResult result) {
    return switch (result) {
        case Success s -> "Muon thanh cong! Ma: " + s.loanId() + ", han tra: " + s.dueDate();
        case ItemReserved r -> "Khong the muon: Sach da bi giu boi ma ban doc " + r.reservedByMemberId();
        case AccountSuspended a -> "The bi khoa do: " + a.reason() + ". Tien phat: " + a.outstandingFine() + " VND";
    };
}

Điểm đặc biệt ở đây: Khối switch hoàn toàn không cần mệnh đề default. Compiler biết chính xác BorrowResult chỉ có 3 thể hiện cụ thể và xác nhận rằng cả 3 trường hợp đều đã được xử lý đầy đủ.

Sự an toàn khi bảo trì và tái cấu trúc hệ thống

Hãy hình dung 6 tháng sau, nghiệp vụ thư viện mở rộng thêm tình huống: tài liệu quý hiếm chỉ được đọc tại chỗ (ReferenceOnly):

public sealed interface BorrowResult permits Success, ItemReserved, AccountSuspended, ReferenceOnly {
}

public record ReferenceOnly(String readingRoom) implements BorrowResult { }

Ngay khi bạn thêm ReferenceOnly vào mệnh đề permits, hàm generateNotification và tất cả mọi vị trí switch trên BorrowResult trong toàn bộ dự án sẽ lập tức báo đỏ:

error: the switch expression does not cover all possible input values

Bạn không thể nào vô tình quên xử lý nghiệp vụ mới. Trình biên dịch chuyển đổi một nguy cơ lỗi nghiêm trọng lúc chạy (quên xử lý dẫn đến hành vi sai ngầm) thành lỗi biên dịch rõ ràng tại từng dòng mã.

5. Hiệu năng JVM và tính toàn vẹn bất biến

Khi tìm hiểu về sealed class, nhiều người đặt câu hỏi: "Sealed có giúp chương trình chạy nhanh hơn không?"

1. Hiệu năng thực tế: HotSpot JVM đã thực hiện kỹ thuật Devirtualization và Inline Caching thông qua phân tích cây phân cấp (CHA) từ rất lâu trước khi Sealed Class ra đời. Do đó, việc chuyển đổi một cây kế thừa sang sealed không tạo ra bước nhảy vọt đáng kể về tốc độ thực thi. Bạn không nên dùng sealed chỉ vì kỳ vọng tối ưu micro-benchmark.
2. Giá trị cốt lõi là Domain Invariants: Giá trị thực sự của sealed class nằm ở tính toàn vẹn kiến trúc (Architecture Integrity) và an toàn biên dịch (Compile-time Safety). Bạn tự tin khẳng định với toàn bộ hệ thống rằng dữ liệu chỉ có thể tồn tại ở những trạng thái hợp lệ đã được quy định trước.

6. So sánh Sealed Types với Enum

7. Ứng dụng Sealed Class mô hình hoá State Machine

Sealed types là công cụ hoàn hảo để mô hình hoá máy trạng thái hữu hạn (Finite State Machine). Hãy quan sát vòng đời mượn sách:

public sealed interface LoanLifecycle permits ActiveLoan, ReturnedOnTime, OverdueLoan, ClaimedLost {
}

public record ActiveLoan(String loanId, LocalDate borrowedAt, LocalDate dueDate) implements LoanLifecycle { }

public record ReturnedOnTime(String loanId, LocalDate returnedAt) implements LoanLifecycle { }

public record OverdueLoan(String loanId, LocalDate dueDate, int daysOverdue, double fine) implements LoanLifecycle { }

public record ClaimedLost(String loanId, double compensationCost) implements LoanLifecycle { }

Mỗi trạng thái mang theo đúng các trường thông tin cần thiết của trạng thái đó. Trạng thái ActiveLoan không cần mang trường fine (tiền phạt), và trạng thái ReturnedOnTime không cần mang trường compensationCost (tiền đền bù mất sách). Thiết kế này loại bỏ hoàn toàn các trường dữ liệu mang giá trị null vô nghĩa trong mô hình hướng đối tượng cũ.

8. Những cạm bẫy thường gặp khi sử dụng Sealed Class

❌ Bẫy 1: Quên khai báo một trong ba modifier trên lớp con

public sealed class Base permits Child { }
public class Child extends Base { } // Loi bien dich!

Mỗi lớp con trực tiếp bắt buộc phải được đánh dấu rõ là final, sealed, hoặc non-sealed.

❌ Bẫy 2: Khai báo lớp con khác package hoặc khác module Tất cả các lớp được cấp phép trong mệnh đề permits phải thuộc cùng một package (nếu không dùng module) hoặc cùng một Java Module (module-info.java). Bạn không thể permit một lớp nằm ở package khác thuộc một JAR khác.

❌ Bẫy 3: Gượng ép dùng sealed cho các điểm mở rộng thư viện (Plugin API) Nếu bạn đang viết một SDK và muốn người dùng bên ngoài có thể tự do mở rộng các plugin hoặc adapter tuỳ biến, việc đánh dấu sealed ở tầng giao tiếp ngoài cùng sẽ chặn đứng khả năng tích hợp của họ. Hãy sử dụng interface mở hoặc kết hợp non-sealed tại các điểm nối cần thiết.

9. Deep Dive Oracle & OpenJDK References

10. Tự kiểm tra kiến thức

Bài tiếp theo: Composition over inheritance — khi nào không kế thừa