Ba Paradigm lập trình

01 Ba paradigm: mỗi cái lấy đi một thứ

Rào cản tích cực, không phải công cụ mới

Một paradigm (hướng lập trình) cho ta biết dùng cấu trúc lập trình nào, khi nào dùng — gần như độc lập với ngôn ngữ. Đến nay chỉ có ba, và nhiều khả năng sẽ không bao giờ có thêm. Lý do nằm ở một quy luật chung mà Martin cố tình bày ra:

Ba mối quan tâm này chính là xương sống của cả cuốn sách: Structured lo cách viết function, OO lo cách chia tách & nối ghép component, Functional lo cách quản lý dữ liệu & trạng thái.

02 Structured Programming

goto có hại — và vì sao

Năm 1968, Edsger Dijkstra chỉ ra rằng việc dùng goto bừa bãi (unrestrained jumps) có hại cho cấu trúc chương trình. Vấn đề không phải thẩm mỹ: một số cách dùng goto khiến module không thể phân rã đệ quy thành các đơn vị nhỏ hơn — chặn mất chiến lược chia-để-trị cần thiết để chứng minh tính đúng.

Dijkstra phát hiện những cách dùng goto "tốt" lại đúng bằng các cấu trúc lựa chọn (if/then/else) và lặp (do/while). Và Böhm–Jacopini đã chứng minh: mọi chương trình đều dựng được chỉ từ ba cấu trúc — tuần tự, lựa chọn, lặp (sequence, selection, iteration). Đúng bộ tối thiểu khiến module chứng minh được lại là bộ đủ để dựng mọi thứ. Structured programming ra đời.

Phân rã chức năng & chứng minh được

Vì cho phép phân rã đệ quy thành đơn vị chứng minh được, structured programming sinh ra functional decomposition: tách bài toán lớn thành function cấp cao, rồi cấp thấp hơn, mãi mãi — mỗi mảnh đều dùng đúng bộ cấu trúc hạn chế ấy. Ở tầm kiến trúc, đây vẫn là một best practice: chia hệ thống thành module, component, service nhỏ và dễ kiểm thử.

03 Object-Oriented & đảo ngược phụ thuộc

Ba "từ khóa ma thuật" — và cái duy nhất quan trọng

OO hay được định nghĩa bằng encapsulation · inheritance · polymorphism. Martin lập luận thẳng: hai cái đầu bị thổi phồng — C đã có encapsulation hoàn hảo, và OO thực ra còn làm yếu nó đi; inheritance chỉ là thủ thuật C đã làm được từ trước. Với kiến trúc sư, chỉ một thứ thật sự đáng giá:

Đảo ngược phụ thuộc (Dependency Inversion)

Trong cây gọi truyền thống, phụ thuộc mã nguồn luôn đi cùng hướng với luồng điều khiển: để gọi một hàm, bạn buộc phải #include/import tên module chứa nó. Kiến trúc sư gần như không có lựa chọn. Nhờ polymorphism an toàn, ta chèn một interface vào giữa, và phụ thuộc mã nguồn (quan hệ kế thừa) chỉ ngược hướng với luồng điều khiển:

flowchart LR
  HL["HL1
(business rule)"]:::core -->|"luồng điều khiển →"| F["F() trong ML1
(chi tiết: DB/UI)"]:::out
  ML["ML1"]:::out -.->|"phụ thuộc mã nguồn ↩ ngược hướng"| I(["interface I"]):::core
  classDef core fill:#dbeee8,stroke:#0f7d72,color:#14233b;
  classDef out fill:#e2edf3,stroke:#2f6d93,color:#14233b;
            

Quyền năng đó cho phép sắp xếp để UI và Database phụ thuộc vào business rule, chứ không phải ngược lại. Khi đó UI và DB trở thành plugin cắm vào business rule; mã nguồn business rule không bao giờ nhắc tới UI hay DB. Ba thứ biên dịch thành ba đơn vị triển khai tách rời ⟶

Dependency inversion qua lăng kính RAG

RAG  Hệ Hỏi–đáp tài liệu cần embed và lưu/truy hồi vector. Nếu pipeline gọi thẳng FAISS, đổi sang pgvector là sửa khắp nơi. Định nghĩa interface ở tầng pipeline (business rule) rồi để FAISS/pgvector cắm vào như plugin — phụ thuộc mã nguồn đảo hướng đúng tinh thần OO:

from typing import Protocol

# Lõi pipeline ĐỊNH NGHĨA interface — chi tiết phải tuân theo (phụ thuộc đảo hướng)
class Embedder(Protocol):
    def embed(self, text: str) -> list[float]: ...

class VectorStore(Protocol):
    def search(self, vec: list[float], k: int) -> list[str]: ...

def retrieve(q: str, emb: Embedder, store: VectorStore) -> list[str]:
    return store.search(emb.embed(q), k=5)   # đổi FAISS↔pgvector = thay plugin, lõi không đổi

04 Functional Programming & tính bất biến

"Biến" trong ngôn ngữ chức năng không hề biến đổi

Functional programming là paradigm ra đời sớm nhất về ý tưởng (λ-calculus của Alonzo Church, 1936) nhưng được áp dụng muộn nhất. Cốt lõi là tính bất biến (immutability): biến được khởi tạo rồi không bao giờ đổi giá trị — nói cách khác, ngôn ngữ không có phép gán (no assignment).

Với kiến trúc sư quan tâm tới concurrency, đây là một kết luận mạnh: đẩy được code sang vùng bất biến tới đâu, vô hiệu hóa cả lớp lỗi đa luồng tới đó. Nhưng bất biến tuyệt đối đòi hỏi bộ nhớ và tốc độ vô hạn — nên trong thực tế cần các thỏa hiệp:

Immutability qua lăng kính RAG

RAG  Pipeline RAG chunk và embed hàng loạt tài liệu — môi trường lý tưởng để xử lý song song. Nếu chunk/embedding là bất biến, nhiều worker cùng chạy mà không có race condition hay concurrent update; không cần khóa, không lo deadlock:

from dataclasses import dataclass
from concurrent.futures import ThreadPoolExecutor

@dataclass(frozen=True)          # bất biến: tạo xong KHÔNG đổi
class Chunk:
    doc_id: str
    text: str

def embed(c: Chunk) -> tuple[Chunk, list[float]]:
    return c, model.encode(c.text)            # thuần chức năng, không gán biến chung

with ThreadPoolExecutor() as pool:
    vectors = list(pool.map(embed, chunks))   # nhiều worker — không race vì không có mutable state

Ở ranh giới service, tầng web PHP (Laravel) chỉ gửi yêu cầu sang pipeline Python qua HTTP — nó không tự xử lý vòng đời chunk/embedding, nên không kéo trạng thái thay đổi vào ranh giới:

// Web/API chỉ chuyển tiếp; pipeline bất biến nằm bên Python
$res = Http::post('http://rag:8000/ingest', [
    'doc_id' => $doc->id,
    'text'   => $doc->content,   // gửi dữ liệu thô, không giữ trạng thái embed
]);
return response()->json($res->json());

05 Ghi nhớ nhanh