LSP · ISP · DIP

01 Ba nguyên lý còn lại của SOLID

SRP và OCP (chủ đề 03) lo việc chia trách nhiệm và mở rộng không sửa. Ba nguyên lý còn lại bàn về các phần ghép lại với nhau ra sao — và đặc biệt là phụ thuộc giữa chúng nên chạy theo hướng nào.

02 LSP · Tính thay thế

Barbara Liskov (1988) định nghĩa subtype như sau: nếu mọi chương trình P viết theo kiểu T vẫn cư xử y hệt khi ta thay một đối tượng kiểu S vào chỗ của T, thì S là một subtype của T. Nói gọn: phần thay thế phải tôn trọng hợp đồng của phần bị thay.

Ví dụ kinh điển: Square / Rectangle

Cho Square kế thừa Rectangle nghe rất "toán học", nhưng vi phạm LSP. Rectangle cho phép đổi width và height độc lập; Square thì buộc hai cạnh luôn đổi cùng nhau. Một User tưởng mình cầm Rectangle sẽ vỡ trận:

Rectangle r = makeRectangle();   // ...nhưng thực ra trả về một Square
r.setW(5);
r.setH(2);
assert(r.area() == 10);          // ✗ Square sẽ cho 4 hoặc 25 → assertion thất bại

LSP leo lên kiến trúc: vụ taxi dispatch

LSP không chỉ về inheritance. Nó áp cho mọi interface & implementation: interface kiểu Java, các lớp Ruby cùng method signature, hay nhiều dịch vụ cùng đáp một REST interface chung. Hãy nhìn điều gì xảy ra khi vi phạm:

Một hệ tổng hợp nhiều taxi dispatch service gửi lệnh điều xe qua REST, lấy URI từ hồ sơ tài xế. Mọi hãng phải tuân cùng một interface — cùng các trường pickupAddress, pickupTime, destination. Rồi lập trình viên của hãng Acme không đọc kỹ spec, viết tắt destination thành dest:

// Acme không substitutable → buộc phải có nhánh đặc biệt
if (driver.getDispatchUri().startsWith("acme.com")) {
    // ...dựng URI bằng /dest/ thay vì /destination/
}

03 ISP · Đừng phụ thuộc thứ bạn không dùng

Xét lớp OPS có ba thao tác op1, op2, op3. Ba user: User1 chỉ cần op1, User2 chỉ cần op2, User3 chỉ cần op3. Trong ngôn ngữ statically typed (Java), mã của User1 phụ thuộc cả OPS — nên nếu op2 đổi (thứ User1 chẳng quan tâm), User1 vẫn bị recompile & redeploy oan.

ISP là vấn đề kiến trúc, không chỉ ngôn ngữ

Ngôn ngữ dynamically typed (Ruby, Python) suy ra phụ thuộc lúc runtime, không có source dependency cứng ⟶ dễ tưởng ISP chỉ là chuyện ngôn ngữ. Nhưng gốc rễ sâu hơn: phụ thuộc vào thứ mang theo "hành lý" (baggage) thừa luôn có hại.

04 DIP · Đảo ngược phụ thuộc

Hệ thống linh hoạt nhất là hệ mà mọi source code dependency chỉ trỏ tới abstraction, không tới concretion. Trong Java: import/use chỉ nên trỏ tới interface, abstract class — không gì cụ thể bị phụ thuộc cả.

Chỉ tránh concretion volatile

Coi mọi thứ cụ thể là cấm kỵ thì phi thực tế: String trong Java cũng cụ thể nhưng cực kỳ stable — không cần trừu tượng hóa. Thứ cần tránh là các volatile concrete element: những module đang phát triển tích cực, thay đổi liên tục.

Tạo đối tượng cụ thể bằng Abstract Factory

Khởi tạo một concrete object lại buộc có source dependency tới định nghĩa cụ thể của nó. Lối thoát: Abstract Factory. Application gọi makeSvc() trên interface ServiceFactory; phần ServiceFactoryImpl mới thật sự new ConcreteImpl rồi trả về dưới dạng Service trừu tượng — policy không bao giờ phải gọi tên lớp chi tiết.

Ranh giới kiến trúc & sự đảo chiều

Đây là ý cốt lõi nối sang phần Kiến trúc: interface trừu tượng vẽ nên một đường ranh giới kiến trúc. Mọi source dependency cắt qua ranh giới chỉ theo một hướng — về phía abstract. Nhưng flow of control lại đi ngược lại. Source dependency bị đảo so với luồng điều khiển — đó là lý do gọi là Dependency Inversion.

05 Ba nguyên lý qua lăng kính RAG

Cùng hệ "Hỏi–đáp tài liệu": pipeline Python (FastAPI) lo chunk→embed→retrieve→generate; PHP (Laravel) chỉ chạm ở ranh giới service. Ba nguyên lý soi rõ ba quyết định khác nhau.

DIP · pipeline phụ thuộc abstraction

RAG  Pipeline là high-level policy. Nó không được nhắc tên OpenAI hay FAISS (concretion volatile) — chỉ phụ thuộc interface VectorStore/LLM (stable abstraction). Một Abstract Factory dựng concrete; mọi vi phạm DIP gom về module main:

class VectorStore(Protocol):                 # stable abstraction
    def search(self, q: list[float], k: int) -> list[Chunk]: ...

class LLM(Protocol):
    def generate(self, prompt: str) -> str: ...

def answer(q, store: VectorStore, llm: LLM):  # high-level policy, 0 concretion
    ctx = store.search(embed(q), k=5)
    return llm.generate(build(ctx, q))

# module `main` (vùng "bẩn") — nơi DUY NHẤT gọi tên lớp volatile
def make_store() -> VectorStore: return FaissStore(...)   # Abstract Factory
def make_llm()   -> LLM:        return OpenAILLM(...)

ISP · client chỉ cần search()

RAG  Web client (PHP) chỉ truy hồi — đừng bắt nó phụ thuộc cả interface admin-index (upsert, reindex, drop). Tách Retriever khỏi IndexAdmin để đổi pipeline nạp dữ liệu không buộc client redeploy:

interface Retriever {            // U1Ops của RAG: client chỉ cần đúng cái này
    public function search(string $q, int $k): array;
}
// interface IndexAdmin { upsert(); reindex(); drop(); }  ← client KHÔNG phụ thuộc

class AskController {
    public function __construct(private Retriever $rag) {}   // không dính "baggage" admin
    public function ask(string $q): array { return $this->rag->search($q, 5); }
}

LSP · mọi VectorStore thay thế được nhau

RAG  FaissStore và PgVectorStore phải thật sự substitutable: cùng nhận vector, trả top-k cùng ngữ nghĩa. Nếu một store lén đổi nghĩa tham số k (vd "ngưỡng điểm" thay vì "số kết quả"), pipeline buộc phải có nhánh if isinstance(...) — chính là vết rò Square/Rectangle.

06 Ghi nhớ nhanh