Giáo trình tổng quan

1. OOP — Object-Oriented Programming

OOP là paradigm (mô hình lập trình) tổ chức code quanh các đối tượng (object) chứa cả data (thuộc tính / state) và behavior (phương thức / hành vi). Đối lập với procedural programming nơi data và function tách rời.

Alan Kay (cha đẻ Smalltalk, 1970s) định nghĩa OOP qua 3 ý chính:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

3 ý chính của Kay:

• Messaging — object nói chuyện qua message (= method call), không truy cập state lẫn nhau trực tiếp.
• Local state hiding — mỗi object giấu state của mình.
• Late binding — quyết định method nào chạy ở runtime, không compile-time.

1.1. Lịch sử ngắn

2. 4 Trụ cột OOP

2.1. Encapsulation (đóng gói)

State của object chỉ truy cập được qua method công khai. Các trường nội bộ là private. Người dùng không cần biết object lưu data thế nào → có thể đổi implementation mà không phá API.

2.2. Abstraction (trừu tượng hóa)

Tách cái gì object làm khỏi cách nó làm. Abstract class / interface mô tả contract, không lo implementation. Người gọi chỉ cần biết "tôi gọi save()" — không quan tâm là DB nào, file nào.

2.3. Inheritance (kế thừa)

Class B kế thừa từ class A → B có mọi field/method của A + có thể thêm/override. "is-a" relationship: Dog is-a Animal.

Cảnh báo: kế thừa quá tay là nguyên nhân hàng đầu của code khó maintain (sẽ bàn ở Ch3 — composition over inheritance).

2.4. Polymorphism (đa hình)

Cùng 1 method, nhiều type khác nhau cho hành vi khác nhau. animal.speak() → Dog kêu "woof", Cat kêu "meow", Cow kêu "moo". Code gọi không cần biết type cụ thể — chỉ biết Animal.

3 dạng polymorphism:

• Subtype polymorphism (overriding) — phổ biến nhất, qua inheritance.
• Parametric polymorphism (generics) — cùng code, nhiều type: List<T>.
• Ad-hoc polymorphism (overloading) — cùng tên function, chữ ký khác nhau.

3. SOLID — 5 nguyên lý kinh điển

Robert C. Martin (Uncle Bob) đặt tên 5 nguyên lý vào 2000:

SOLID không phải luật bất biến — chúng là heuristic. Áp dụng đúng → code dễ thay đổi. Áp dụng cứng nhắc → over-engineer.

4. Design Patterns — 23 GoF

Năm 1994, "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) xuất bản "Design Patterns: Elements of Reusable Object-Oriented Software". Quyển sách là vốn từ vựng chung cho thiết kế phần mềm. Khi đồng nghiệp nói "đây là Decorator" — bạn hiểu cấu trúc ngay, không cần giải thích.

23 pattern chia 3 nhóm:

4.1. Pattern không phải tất cả

Sau 1994, cộng đồng phát triển thêm rất nhiều pattern hữu ích:

• Dependency Injection — popularized bởi Spring/Angular, gần như thay Factory trong nhiều case.
• Repository / Unit of Work — DDD patterns cho persistence.
• CQRS — tách read và write model.
• Event Sourcing — lưu chuỗi event thay vì state.
• Saga — distributed transaction qua compensating action.
• Hexagonal / Ports & Adapters — kiến trúc, không phải pattern lẻ.

23 GoF là nền tảng. Nắm vững GoF → tự đọc và áp dụng pattern hiện đại dễ dàng.

5. Khi nào nên (và KHÔNG nên) dùng pattern

5.1. Anti-pattern: "Pattern Hammer"

Sau khi đọc xong sách Design Patterns, dev mới thường cố ép mọi vấn đề thành 1 pattern. Mọi class có Factory, mọi flow có State Machine, mọi event có Observer. Code biến thành mê cung 50 file cho việc 1 file đủ.

Pattern là giải pháp cho vấn đề cụ thể. Trước khi áp dụng, phải có vấn đề rõ ràng. Code over-engineered còn tệ hơn code "thô" mà rõ.

5.2. Khi pattern KHÔNG cần thiết

• App nhỏ, không có biến thể — không cần Factory, dùng new.
• Logic 2-3 nhánh — if/else rõ hơn Strategy.
• Code chỉ chạy 1 lần — không cần abstraction phức tạp.
• Không có 2nd reader / không scale teamsize — đơn giản trước, refactor khi cần.

5.3. Khi pattern THỰC SỰ giúp

• Codebase team > 3 người, lifetime > 6 tháng.
• Logic thay đổi thường xuyên (vd: pricing rules, validation rules).
• Cần hỗ trợ plugin / extensibility (vd: payment gateway).
• Test phức tạp — DI giúp mock dễ.
• Phải tích hợp với code legacy — Adapter, Facade vào việc.

6. Refactoring & Code Smells

Martin Fowler (sách Refactoring, 1999) định nghĩa refactoring: "Cải thiện cấu trúc nội bộ của code mà không thay đổi hành vi quan sát được."

Trigger để refactor là code smell — dấu hiệu code có vấn đề:

• Long Method — function dài > 30 dòng.
• Large Class — class > 500 dòng, > 20 method.
• Long Parameter List — > 4 tham số.
• Duplicated Code — copy-paste 3 chỗ trở lên.
• Feature Envy — method 1 class dùng nhiều cái của class khác hơn của chính nó.
• Data Clumps — 2-3 field luôn đi cùng nhau → tạo VO.
• Primitive Obsession — dùng string cho email, address, money — nên có type riêng.
• Switch Statements — thường là dấu hiệu thiếu polymorphism.
• Shotgun Surgery — thay đổi nhỏ ở 1 chỗ → phải sửa 10 file khác.
• God Object — class biết và làm tất cả, vi phạm SRP nặng.

Sẽ đào sâu Ch8.

7. DDD-lite — vốn ngắn cho project hiện đại

Eric Evans (sách Domain-Driven Design, 2003) đặt nền cho cách tổ chức code phức tạp xoay quanh business domain. Bạn không cần đọc cả sách 500 trang — chỉ cần nắm 5 building block:

Sẽ phân tích Ch8 với case study e-commerce.

8. Lộ trình học đề xuất

1. Tuần 1: Ch1 + Ch2. Code 4 mini-class minh họa 4 trụ cột. Refactor 1 đoạn code mình từng viết theo SOLID.
2. Tuần 2: Ch3. Tạo 1 immutable Money class. Áp dụng DI cho 1 service. Đọc Item 17–18 Effective Java (composition vs inheritance).
3. Tuần 3: Ch4 + Ch5. Implement 5 creational + 7 structural pattern bằng TypeScript. Mỗi pattern 1 file ngắn ~50 dòng.
4. Tuần 4: Ch6 + Ch7. 11 behavioral pattern. Đặc biệt chú ý phân biệt: Strategy vs State, Template vs Strategy, Visitor vs Iterator.
5. Tuần 5: Ch8. Refactor 1 codebase nhỏ có sẵn (open-source) theo cataloged code smells. Áp dụng DDD-lite cho 1 ý tưởng app cá nhân.

Sẵn sàng chưa? Bắt đầu từ Chương 1 — OOP Fundamentals & 4 Pillars.