Design Patterns: 23 mẫu thiết kế mà dev nào cũng nên nằm lòng

Bạn đã bao giờ ngồi review code của chính mình từ 6 tháng trước và tự hỏi: "Ai viết cái đống này vậy?" — rồi nhận ra đó chính là mình chưa? Mình thì có. Nhiều lần.

Và một trong những thứ giúp mình thoát khỏi vòng xoáy "code xong rồi sợ đọc lại" chính là Design Patterns. Không phải thứ gì cao siêu, không phải lý thuyết hàn lâm — mà là những bài học đúc kết từ hàng chục năm kinh nghiệm của cộng đồng developer toàn cầu.

Design Patterns thực ra là cái gì?

Nói đơn giản thôi: Design Patterns là những giải pháp đã được kiểm chứng cho các vấn đề lặp đi lặp lại trong thiết kế phần mềm. Bạn không cần phát minh lại bánh xe — ai đó đã gặp đúng vấn đề của bạn, đã thử nhiều cách, và đã tìm ra cách tối ưu nhất.

Điều quan trọng cần nhớ: Design Patterns không phải là code cụ thể mà bạn copy-paste vào project. Nó là một template tư duy, một cách tiếp cận vấn đề. Bạn có thể implement nó bằng Java, C#, Python, TypeScript, hay bất kỳ ngôn ngữ OOP nào.

Theo kinh nghiệm của mình, nhiều bạn junior hay nghĩ Design Patterns là thứ chỉ senior mới cần biết. Sai. Bạn càng hiểu sớm, bạn càng tránh được những sai lầm mà mình đã mắc phải. Tuy nhiên, có một điều kiện tiên quyết: bạn cần nắm vững OOP trước. Nếu bạn chưa rõ về inheritance, polymorphism, abstraction, encapsulation thì hãy ôn lại đã rồi quay lại đây.

Tại sao dev nên quan tâm đến Design Patterns?

Mình liệt kê vài lý do thực tế, không phải lý thuyết sách vở:

Nói chuyện với đồng đội dễ hơn hẳn. Thay vì giải thích 15 phút về cách bạn tổ chức code tạo object, bạn chỉ cần nói: "Chỗ này mình dùng Factory Method." Xong. Ai cũng hiểu. Design Patterns tạo ra một ngôn ngữ chung giữa các developer.

Code dễ maintain và mở rộng. Điều mình thấy hay là khi áp dụng đúng pattern, code tự nhiên trở nên modular hơn. Thêm feature mới không cần sửa lung tung, mà chỉ cần extend đúng chỗ.

Tránh được bug tiềm ẩn. Những pattern này đã được hàng triệu developer sử dụng và kiểm chứng qua hàng chục năm. Bạn tự nghĩ ra giải pháp thì có thể chạy được, nhưng liệu nó có handle được edge case mà bạn chưa nghĩ tới?

Tăng tốc development. Nghe paradox nhưng đúng — bỏ thời gian học pattern ban đầu, nhưng sau đó mỗi lần gặp vấn đề tương tự, bạn đã có sẵn giải pháp trong đầu.

Ba nhóm Design Patterns bạn cần biết

23 mẫu Design Pattern kinh điển (từ cuốn sách huyền thoại của Gang of Four) được chia thành 3 nhóm theo mục đích sử dụng.

Creational Patterns — Nhóm khởi tạo

Gồm 5 mẫu: Singleton, Factory Method, Abstract Factory, Builder, Prototype.

Nhóm này giải quyết câu hỏi: "Tạo object như thế nào cho hợp lý?" Thay vì new object trực tiếp khắp nơi trong code (rồi sau này khóc khi cần thay đổi), các pattern này giúp bạn che giấu logic khởi tạo và linh hoạt hơn.

Ví dụ thực tế mình hay gặp nhất:

• Singleton: Database connection pool — bạn chỉ muốn duy nhất một instance quản lý connections.
• Factory Method: Khi bạn có nhiều loại notification (email, SMS, push) và muốn tạo chúng mà không cần biết class cụ thể.
• Builder: Tạo object phức tạp có nhiều optional fields — như một query builder hay config object.

Structural Patterns — Nhóm cấu trúc

Gồm 7 mẫu: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

Nhóm này trả lời câu hỏi: "Tổ chức các object và class quan hệ với nhau thế nào?" Khi hệ thống lớn dần, việc các object giao tiếp và kết nối với nhau trở nên phức tạp. Structural patterns giúp bạn giữ mọi thứ gọn gàng.

Mấy cái mình dùng thường xuyên:

• Adapter: Wrap một third-party library để nó phù hợp với interface của project bạn. Sau này đổi library? Chỉ cần sửa adapter.
• Facade: Tạo một interface đơn giản che đi hệ thống phức tạp bên dưới — kiểu như bạn gọi orderService.placeOrder() mà bên trong nó xử lý inventory, payment, notification.
• Decorator: Thêm tính năng cho object mà không sửa class gốc. Mình hay thấy trong logging, caching middleware.

Behavioral Patterns — Nhóm hành vi

Gồm 11 mẫu: Interpreter, Template Method, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor.

Đây là nhóm lớn nhất, giải quyết câu hỏi: "Các object giao tiếp và phân chia trách nhiệm với nhau thế nào?"

Mấy pattern mình thấy xuất hiện nhiều nhất trong thực tế:

• Observer: Cơ chế pub/sub — một object thay đổi state thì tự động notify các object khác. React state management, event systems đều dựa trên ý tưởng này.
• Strategy: Cho phép thay đổi algorithm tại runtime. Ví dụ: hệ thống thanh toán hỗ trợ nhiều payment method, mỗi method là một strategy.
• Chain of Responsibility: Middleware pipeline trong Express.js hay ASP.NET chính là pattern này.

Sai lầm phổ biến khi học Design Patterns

Theo kinh nghiệm của mình, có hai cái bẫy mà nhiều bạn hay rơi vào:

Bẫy thứ nhất: Cố nhồi pattern vào mọi thứ. Học xong Singleton thì cái gì cũng muốn Singleton. Học xong Observer thì event khắp nơi. Design Patterns là công cụ — bạn không dùng búa để vặn ốc vít. Hãy hiểu vấn đề trước, rồi mới chọn pattern phù hợp.

Bẫy thứ hai: Học thuộc lòng mà không hiểu "tại sao". Bạn có thể vẽ được class diagram của Abstract Factory, nhưng nếu không hiểu khi nào nên dùng và khi nào không nên, thì kiến thức đó vô nghĩa.

Lời khuyên chân thành: hãy bắt đầu với 5-6 pattern phổ biến nhất (Singleton, Factory Method, Observer, Strategy, Adapter, Decorator), hiểu thật sâu, rồi mở rộng dần.

Những điều mình muốn chia sẻ thêm

Sau hơn 5 năm đi làm, mình nhận ra Design Patterns không phải thứ bạn học một lần rồi xong. Mỗi lần đọc lại, mỗi lần gặp bài toán mới, bạn sẽ hiểu chúng sâu hơn một chút.

Nếu bạn muốn đi sâu, mình recommend mấy tài liệu sau:

• Refactoring.Guru (https://refactoring.guru/design-patterns) — miễn phí, có hình minh họa cực đẹp, giải thích dễ hiểu.
• Head First Design Patterns — sách viết theo kiểu storytelling, đọc không buồn ngủ.
• Dive into Design Patterns — compact hơn, phù hợp khi bạn muốn tra cứu nhanh.

Đừng cố học hết 23 patterns trong một tuần. Hãy học một pattern, áp dụng vào code thật, refactor một đoạn code cũ bằng pattern đó. Khi nào thấy "à ha, hóa ra dùng chỗ này hợp lý thật", thì bạn đã thực sự hiểu nó rồi.

Design Patterns không làm bạn trở thành developer giỏi chỉ sau một đêm. Nhưng nó cho bạn bộ công cụ tư duy để giải quyết vấn đề một cách có hệ thống — và đó là thứ phân biệt một developer viết code chạy được với một developer viết code đáng để maintain.