OOP: từ object đến thiết kế dễ thay đổi

Bổ sung · ví dụ thiết kế và kiểm chứng

Biến invariant thành điều kiện kiểm tra được

Với ví dụ này, viết rõ balance ≥ 0, đầu vào hợp lệ là 0 < amount ≤ balance, và một lần rút bị từ chối phải giữ nguyên số dư. Constructor phải tạo state hợp lệ; mọi đường cập nhật sau đó phải giữ cùng quy tắc. Đó là một contract có thể test, không chỉ là quy ước đặt tên field.

Bài tập bổ sung · lưu thành BankAccountCheck.java · chạy độc lập, không cần thư viện.

public class BankAccountCheck {
    static final class Account {
        private long balance;

        Account(long initialBalance) {
            if (initialBalance < 0) {
                throw new IllegalArgumentException("Negative balance");
            }
            balance = initialBalance;
        }

        void withdraw(long amount) {
            if (amount <= 0 || amount > balance) {
                throw new IllegalArgumentException("Invalid amount");
            }
            balance -= amount;
        }

        long balance() { return balance; }
    }

    static void rejected(Account account, long amount) {
        long before = account.balance();
        try {
            account.withdraw(amount);
            throw new AssertionError("Expected rejection");
        } catch (IllegalArgumentException expected) {
            if (account.balance() != before) {
                throw new AssertionError("State changed after rejection");
            }
        }
    }

    public static void main(String[] args) {
        Account account = new Account(100);
        rejected(account, 0);
        rejected(account, -1);
        rejected(account, 101);
        account.withdraw(100);
        if (account.balance() != 0) {
            throw new AssertionError("Wrong balance");
        }
        rejected(account, 1);
        System.out.println("PASS: invariant and rejected transitions");
    }
}

Acceptance: ba đầu vào 0, −1, 101 bị từ chối khi số dư là 100; rút đúng 100 thành công; rút thêm 1 thất bại; mọi lần thất bại đều không đổi state. Output: PASS: invariant and rejected transitions. Thử bỏ guard rồi chạy lại để thấy test bắt được lỗi.

Bổ sung · phân biệt contract và implementation

Một boundary phải nói cả cách thất bại

Trong ví dụ PaymentGateway.charge(), abstraction cho client một contract; encapsulation bảo vệ cách adapter giữ state và thông tin cấu hình. Đề xuất khi thiết kế contract: ghi rõ đầu vào, kết quả thành công, lỗi nghiệp vụ, timeout và trách nhiệm retry. Ẩn vendor SDK không có nghĩa là giấu luôn mọi kết quả thất bại.

Từ CardPayment implements PaymentMethod, hãy đọc là subtyping qua interface: một kiểu thực thi contract của kiểu khác, không phải kế thừa mutable state từ một superclass. Java tách hai việc này; bảng bốn trụ cột là mental model, không phải bốn keyword tương ứng một-một. [O1] [O2]

Bổ sung · đã đối chiếu tài liệu

Hai bước độc lập: chọn signature, rồi chọn implementation

Bài tập bổ sung · DispatchDemo.java · dự đoán hai dòng output trước khi chạy.

public class DispatchDemo {
    static class Base {
        String pay(Object order) { return "Base/Object"; }
    }

    static class Card extends Base {
        @Override
        String pay(Object order) { return "Card/Object"; }

        String pay(String order) { return "Card/String"; }
    }

    public static void main(String[] args) {
        Base method = new Card();
        System.out.println(method.pay("order")); // Card/Object
        Card card = new Card();
        System.out.println(card.pay("order"));   // Card/String
    }
}

Ở lời gọi đầu, static type Base khiến compiler chọn pay(Object); object thực là Card nên runtime chạy override của signature đó. Lời gọi thứ hai có static type Card, nên overload pay(String) được chọn. Runtime không quay lại chọn overload theo kiểu thật của đối số. [O4]

Không thể overload chỉ bằng kiểu trả về. static method có thể bị hide, không override; private method và constructor không được kế thừa để override. Dùng @Override để compiler phát hiện việc vô tình tạo overload thay vì override. [O1] [O2]

Bổ sung · quy tắc chẩn đoán và trade-off

Dùng substitutability để quyết định, không chỉ nhìn tên class

Một phép thử tự biên soạn: client nhận PaymentMethod và đã được phép gọi pay(order) với một order hợp lệ. Một subtype bất ngờ đòi client downcast trước, hoặc luôn ném lỗi cho thao tác mà base contract cam kết hỗ trợ, là tín hiệu cần xem lại hierarchy. Không tăng precondition và không làm yếu postcondition mà caller đang dựa vào.

Trong CheckoutService, constructor injection cho phép truyền adapter thật hoặc test double. Đề xuất thêm kiểm tra non-null cho dependency và kiểm thử cùng một contract trên các adapter. Trade-off: composition thêm bước ủy quyền và cấu hình; inheritance vẫn phù hợp khi quan hệ is-a, extension points và lifecycle thực sự ổn định.

Evidence: viết một bộ contract tests chạy cho ít nhất hai implementation; cùng đầu vào hợp lệ phải đáp ứng cùng postcondition. Không chỉ test từng concrete class bằng bộ giả định riêng.

Bổ sung · làm rõ phạm vi thuật ngữ

Ownership là một quyết định thiết kế, không phải hiệu ứng của cú pháp

“Composition” ở mục 4 được dùng theo nghĩa rộng: ghép behavior bằng collaborator. “Composition” trong bảng quan hệ object nhấn mạnh ownership/lifecycle. Chỉ nhìn một field hay constructor injection chưa đủ kết luận quan hệ lifecycle: gateway có thể được nhiều service dùng chung.

Khi review, ghi lại ai tạo part, ai được sửa nó, ai chịu trách nhiệm kết thúc sử dụng/đóng resource, và có alias nào giữ part ngoài whole hay không. final khóa việc gán lại reference, không tự đóng băng object được tham chiếu. [O1]

Bổ sung · đã đối chiếu tài liệu

Chọn kiểu theo điều cần bảo vệ

Bảng này triển khai các lựa chọn ở phần nguồn; cú pháp và giới hạn class/interface theo JLS. [O1] [O2]

Bài tập bổ sung · ValueTypesDemo.java · defensive snapshot và exhaustive switch.

import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public class ValueTypesDemo {
    record Labels(List<String> values) {
        Labels {
            values = List.copyOf(values);
        }
    }

    sealed interface PaymentResult permits Approved, Declined {}
    record Approved(String receiptId) implements PaymentResult {}
    record Declined(String reason) implements PaymentResult {}

    static String describe(PaymentResult result) {
        return switch (Objects.requireNonNull(result)) {
            case Approved a -> "approved:" + a.receiptId();
            case Declined d -> "declined:" + d.reason();
        };
    }

    public static void main(String[] args) {
        var original = new ArrayList<>(List.of("java"));
        var labels = new Labels(original);
        original.add("changed");
        if (!labels.values().equals(List.of("java"))) {
            throw new AssertionError("Alias leaked");
        }
        try {
            labels.values().add("oops");
            throw new AssertionError("Expected unmodifiable list");
        } catch (UnsupportedOperationException expected) {
            // The public accessor does not expose a mutable list.
        }
        System.out.println(labels.values());
        System.out.println(describe(new Approved("R1")));
        System.out.println(describe(new Declined("blocked")));
    }
}

Expected output: lần lượt là [java], approved:R1, declined:blocked. List.copyOf tạo kết quả không phản ánh những lần sửa cấu trúc list đầu vào về sau, không cho phép sửa qua accessor và từ chối null list/null elements. Đây không phải deep copy; bài dùng String immutable làm phần tử. Với component là một mutable object, cần quyết định copy đến mức nào. [O7]

Thử làm hỏng: bỏ List.copyOf để thấy alias leak; thêm một subtype mới vào sealed model và quan sát yêu cầu cập nhật switch. Objects.requireNonNull ở đây chủ động từ chối null; exhaustiveness theo subtype không thay thế chính sách null. [O4] [O6]

Liên hệ equality: Object.equals mặc định kiểm identity; value type cần contract equality phù hợp. Khi tự override equals, phải giữ consistency với hashCode. Đừng dùng mutable state đang thay đổi làm nền tảng cho key trong hash collection. [O8]

Bổ sung · phân tích thiết kế tự biên soạn

Từ một nguyên tắc đến bằng chứng thay đổi

Đề xuất cách dùng bảng SOLID: chọn một thay đổi đã xảy ra, liệt kê những nơi phải sửa, rồi xác định dependency nào khiến thay đổi lan rộng. Ví dụ đổi vendor thanh toán: ưu tiên giữ business policy và contract ổn định, để vendor mapping nằm trong adapter. Nếu chỉ thêm một lớp chuyển tiếp không bảo vệ được gì, abstraction đó chưa có lý do tồn tại.

DIP là định hướng dependency vào abstraction phù hợp; dependency injection chỉ là cách cung cấp object cộng tác. Một constructor nhận trực tiếp vendor SDK vẫn có injection, nhưng business policy có thể còn phụ thuộc vendor. Đây là phân tích thiết kế, không phải lỗi mà compiler tự bắt.

Bổ sung · interview evidence

Biến 6 mục checklist thành bài trả lời có bằng chứng

Lệnh chạy các chương trình bổ sung sau khi lưu mỗi block vào đúng tên file.

javac --release 21 BankAccountCheck.java DispatchDemo.java ValueTypesDemo.java
java BankAccountCheck
java DispatchDemo
java ValueTypesDemo

Acceptance của buổi học: cả ba chương trình chạy đúng output đã ghi; người học giải thích được các lỗi khi bỏ guard hoặc bỏ defensive snapshot. Lưu source thử nghiệm, phiên bản java -version, stdout và câu trả lời cho 6 mục. Đây là bài kiểm chứng trong chuyên đề, không cộng vào tổng lab của Part 01.