🗺️ MOC - OOP cho người đi làm

30 dot notes tách từ ebook của Nguyễn Thế Huy. Sách đi từ nền tảng (OOP là gì, 4 trụ cột) → nguyên tắc thiết kế → SOLID → 11 Design Pattern thực chiến. Đọc tuần tự lần đầu, sau đó dùng từng note như tài liệu tra cứu độc lập.

Tư tưởng xuyên suốt của cả cuốn sách: Code tốt = code dễ thay đổi. Mọi trụ cột, nguyên tắc và pattern trong sách đều phục vụ 2 mục tiêu: Code Reuse (tái sử dụng) và Extensibility và Flexibility (dễ mở rộng khi nghiệp vụ đổi). Chìa khoá để đạt được: phụ thuộc vào trừu tượng, không phụ thuộc chi tiết → Program to Interface - Tập trung vào trừu tượng.

🧭 Lộ trình học đề xuất (học theo thứ tự 5 level)

Level 0 - Nền tảng: OOP là gì & 4 trụ cột (đọc trước tiên)

Nắm bản chất OOP và 4 đặc trưng không thể thiếu. Không chắc level này thì SOLID và Design Pattern chỉ là học vẹt.

OOP là gì - mô hình gói dữ liệu + hành vi vào object. Bắt đầu từ đây!
Encapsulation - Đóng gói - chiếc khiên: giấu chi tiết, chỉ chìa ra thứ cần thiết
Abstraction - Trừu tượng - mô hình hoá đối tượng giới hạn trong một ngữ cảnh
Inheritance - Kế thừa - xây class mới dựa trên class cũ (quan hệ “LÀ MỘT”)
Polymorphism - Đa hình - cùng lời gọi, class thực quyết định hành vi

Level 1 - Bốn nguyên tắc thiết kế nền tảng ⭐

“Kim chỉ nam” để đánh giá một thiết kế tốt hay tồi - nền của mọi SOLID và pattern phía sau.

Code Reuse - mục tiêu 1: đừng copy-paste, hãy tái sử dụng
Extensibility và Flexibility - mục tiêu 2: “thay đổi là thứ cố định duy nhất”
Đóng gói (Nguyên tắc thiết kế) - cô lập phần hay thay đổi (khác trụ cột Encapsulation)
Program to Interface - Tập trung vào trừu tượng - phụ thuộc vào interface, không phải implementation ⭐⭐
Composition over Inheritance - ưu tiên quan hệ “CÓ MỘT” hơn “LÀ MỘT” ⭐⭐

Level 2 - SOLID: 5 nguyên tắc + IoC/DI 🔥 (phần cốt lõi)

Uncle Bob’s 5 nguyên tắc giúp thiết kế dễ hiểu, linh hoạt, dễ bảo trì. Đọc SOLID trước để có bức tranh tổng, rồi đào từng chữ.

SOLID - bản đồ 5 chữ cái, đọc đầu tiên trong level này
Single Responsibility Principle - S: một class, một lý do để thay đổi
Open Closed Principle - O: mở để mở rộng, đóng để sửa đổi
Liskov Substitution Principle - L: class con thay được class cha, không phá vỡ app
Interface Segregation Principle - I: client chỉ phụ thuộc thứ nó CẦN
Dependency Inversion Principle - D: cả hai cấp phụ thuộc vào trừu tượng
Inversion of Control - đảo quyền điều khiển: framework/container gọi code của bạn
Dependency Injection - cách hiện thực IoC: bài toán “bóng đèn - đui đèn”

Level 3 - Design Pattern: nhập môn (đọc trước khi vào từng pattern)

Design Pattern là gì - giải pháp điển hình cho vấn đề lặp lại; GoF & 3 nhóm pattern

Level 4 - 11 Design Pattern thực chiến (kho vũ khí)

Đọc lướt để biết chúng tồn tại, quay lại khi gặp đúng tình huống. Mỗi note có dấu hiệu nhận biết + ví dụ code.

🏭 Nhóm khởi tạo (Creational) - “kéo” việc new ra một chỗ riêng: 20. Factory Pattern - tạo nhiều loại object mà không cần biết chính xác loại nào 21. Builder Pattern - dựng object phức tạp TỪNG BƯỚC 22. Singleton Pattern - đảm bảo chỉ MỘT instance toàn cục

🧱 Nhóm cấu trúc (Structural) - ghép/bọc object: 23. Adapter Pattern - cầu nối 2 interface không tương thích 24. Decorator Pattern - bọc object để thêm hành vi mà không sửa code gốc

🎭 Nhóm hành vi (Behavioral) - cách các object giao tiếp: 25. Chain of Responsibility Pattern - truyền request qua chuỗi handler 26. Command Pattern - biến request thành object độc lập 27. Observer Pattern - cơ chế đăng ký / thông báo sự kiện (pub-sub) 28. State Pattern - đổi hành vi khi trạng thái bên trong đổi 29. Strategy Pattern - nhóm thuật toán hoán đổi được tại runtime 30. Template Method Pattern - khung xử lý ở class cha, chi tiết ở class con

🚀 Lối vào nhanh theo vấn đề (tra cứu khi gặp chuyện)

Bạn đang gặp gì?	Đọc note
Code lặp lại nhiều nơi, sửa 1 chỗ sót chỗ khác	Code Reuse → Composition over Inheritance
Một thay đổi nhỏ làm hỏng nhiều chỗ khác	Đóng gói (Nguyên tắc thiết kế)
Mỗi lần thêm tính năng phải sửa class cũ	Open Closed Principle → Strategy Pattern
Class phình to, làm quá nhiều việc	Single Responsibility Principle
Kế thừa xong class con “vỡ trận” khi thay class cha	Liskov Substitution Principle
Interface quá lớn, class buộc implement hàm không dùng	Interface Segregation Principle
Code cấp cao dính chặt vào class cụ thể, khó test	Dependency Inversion Principle → Dependency Injection
Cần khởi tạo nhiều loại object tuỳ điều kiện	Factory Pattern
Object có quá nhiều tham số khởi tạo	Builder Pattern
Cần đúng 1 instance dùng chung toàn app	Singleton Pattern
Tích hợp thư viện/API có interface lạ	Adapter Pattern
Muốn thêm chức năng mà không sửa code cũ	Decorator Pattern
Một request qua nhiều bước kiểm tra/xử lý	Chain of Responsibility Pattern
Nhiều thuật toán tương tự, muốn hoán đổi runtime	Strategy Pattern
Object cần “phát thông báo” cho nhiều nơi	Observer Pattern
Object hành xử khác nhau theo trạng thái	State Pattern
Nhiều quy trình chung khung, khác vài bước	Template Method Pattern

🧠 5 câu thần chú rút gọn cả cuốn sách

“Code tốt = code dễ thay đổi” - Extensibility và Flexibility
“Phụ thuộc vào trừu tượng, không phụ thuộc chi tiết” - Program to Interface - Tập trung vào trừu tượng
“Ưu tiên CÓ MỘT (composition) hơn LÀ MỘT (inheritance)” - Composition over Inheritance
“Một class, một lý do để thay đổi” - Single Responsibility Principle
“Design Pattern là ngôn ngữ chung, không phải code copy-paste” - Design Pattern là gì

🗺️ OOP cho người đi làm - Reading Map

Sơ đồ cấu trúc & thứ tự đọc ebook của Nguyễn Thế Huy. Nguyên tắc: đọc tuần tự lần đầu (phần sau xây trên phần trước), sau đó dùng từng phần như tài liệu tra cứu.

Tổng quan: thứ tự đọc 5 phần

flowchart TD
    Start(["📖 Bắt đầu"]) --> P1

    subgraph P1["1️⃣ NỀN TẢNG - OOP là gì & 4 trụ cột"]
        direction TB
        A0["OOP là gì<br/>(gói dữ liệu + hành vi vào object)"]
        A1["Encapsulation - Đóng gói<br/>(giấu chi tiết, chìa ra thứ cần)"]
        A2["Abstraction - Trừu tượng<br/>(mô hình hoá trong 1 ngữ cảnh)"]
        A3["Inheritance - Kế thừa<br/>(quan hệ LÀ MỘT)"]
        A4["Polymorphism - Đa hình<br/>(class thực quyết định hành vi)"]
        A0 --> A1 --> A2 --> A3 --> A4
    end

    P1 --> P2

    subgraph P2["2️⃣ NGUYÊN TẮC THIẾT KẾ NỀN TẢNG ⭐"]
        direction TB
        B1["Code Reuse<br/>(đừng copy-paste)"]
        B2["Extensibility & Flexibility<br/>(sẵn sàng cho thay đổi)"]
        B3["Đóng gói - nguyên tắc<br/>(cô lập phần hay thay đổi)"]
        B4["Program to Interface<br/>(phụ thuộc trừu tượng)"]
        B5["Composition over Inheritance<br/>(ưu tiên CÓ MỘT)"]
        B1 --> B2 --> B3 --> B4 --> B5
    end

    P2 --> P3

    subgraph P3["3️⃣ SOLID + IoC/DI 🔥 (cốt lõi)"]
        direction TB
        C0["SOLID - bản đồ 5 chữ cái"]
        C1["S: Single Responsibility<br/>O: Open/Closed"]
        C2["L: Liskov Substitution<br/>I: Interface Segregation"]
        C3["D: Dependency Inversion<br/>→ IoC → Dependency Injection"]
        C0 --> C1 --> C2 --> C3
    end

    P3 --> P4

    subgraph P4["4️⃣ DESIGN PATTERN - nhập môn"]
        direction TB
        D1["Design Pattern là gì<br/>(GoF • 3 nhóm • ngôn ngữ chung)"]
    end

    P4 --> P5

    subgraph P5["5️⃣ 11 DESIGN PATTERN THỰC CHIẾN (kho vũ khí)"]
        direction TB
        E1["🏭 Khởi tạo:<br/>Factory • Builder • Singleton"]
        E2["🧱 Cấu trúc:<br/>Adapter • Decorator"]
        E3["🎭 Hành vi:<br/>Chain of Responsibility • Command<br/>Observer • State • Strategy • Template Method"]
        E1 --> E2 --> E3
    end

    P5 --> Done(["✅ Dùng từng pattern làm tài liệu tra cứu"])

    style P2 fill:#fff3cd,stroke:#e0a800,stroke-width:3px
    style P3 fill:#f8d7da,stroke:#c82333,stroke-width:2px
    style Start fill:#d4edda,stroke:#28a745
    style Done fill:#d4edda,stroke:#28a745

Hai mục tiêu chi phối tất cả

flowchart LR
    T1["♻️ Code Reuse<br/>(tái sử dụng, đừng copy-paste)"] --> X["Mọi trụ cột,<br/>nguyên tắc & pattern"]
    T2["🔧 Extensibility & Flexibility<br/>(code dễ thay đổi khi nghiệp vụ đổi)"] --> X
    X --> R1["Vì sao có 4 nguyên tắc thiết kế"]
    X --> R2["Vì sao có SOLID"]
    X --> R3["Vì sao có 11 Design Pattern"]
    K["🔑 Chìa khoá chung:<br/>phụ thuộc vào TRỪU TƯỢNG,<br/>không phụ thuộc CHI TIẾT"] --> X

Chọn Design Pattern nào? (tra nhanh theo vấn đề)

flowchart TD
    Q(["🤔 Cần một Design Pattern?"]) --> G{"Vấn đề thuộc nhóm nào?"}

    G -- "Tạo / khởi tạo object" --> C1{"Tình huống?"}
    C1 -- "Nhiều loại tuỳ điều kiện" --> F1["Factory Pattern"]
    C1 -- "Object nhiều tham số, dựng từng bước" --> F2["Builder Pattern"]
    C1 -- "Cần đúng 1 instance dùng chung" --> F3["Singleton Pattern"]

    G -- "Ghép / bọc object" --> C2{"Tình huống?"}
    C2 -- "2 interface không tương thích" --> F4["Adapter Pattern"]
    C2 -- "Thêm chức năng, không sửa code gốc" --> F5["Decorator Pattern"]

    G -- "Cách object giao tiếp / hành xử" --> C3{"Tình huống?"}
    C3 -- "Request qua chuỗi bước xử lý" --> F6["Chain of Responsibility"]
    C3 -- "Đóng gói request thành object" --> F7["Command Pattern"]
    C3 -- "Phát thông báo cho nhiều nơi" --> F8["Observer Pattern"]
    C3 -- "Hành vi đổi theo trạng thái" --> F9["State Pattern"]
    C3 -- "Nhiều thuật toán hoán đổi runtime" --> F10["Strategy Pattern"]
    C3 -- "Chung khung, khác vài bước" --> F11["Template Method"]

    style Q fill:#f8d7da,stroke:#c82333
    style F1 fill:#d4edda,stroke:#28a745
    style F2 fill:#d4edda,stroke:#28a745
    style F3 fill:#d4edda,stroke:#28a745
    style F4 fill:#d4edda,stroke:#28a745
    style F5 fill:#d4edda,stroke:#28a745
    style F6 fill:#d4edda,stroke:#28a745
    style F7 fill:#d4edda,stroke:#28a745
    style F8 fill:#d4edda,stroke:#28a745
    style F9 fill:#d4edda,stroke:#28a745
    style F10 fill:#d4edda,stroke:#28a745
    style F11 fill:#d4edda,stroke:#28a745

🪴ttuan's garden