Wavi Books · Kỹ nghệ phần mềm & Clean Code

Design Pattern là gì? Khi nào nên dùng mẫu thiết kế phần mềm

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Design Pattern là gì, các nhóm creational, structural, behavioral và cách chọn mẫu thiết kế phù hợp mà không làm code phức tạp.

## Design Pattern là gì

## Điều đáng nhớ trước khi áp dụng nguyên tắc

Design Pattern là gì, các nhóm creational, structural, behavioral và cách chọn mẫu thiết kế phù hợp mà không làm code phức tạp. Mục tiêu không phải làm code trông đẹp hơn, mà là giúp con người hiểu và thay đổi phần mềm an toàn hơn.

Một đoạn code không có bug vẫn có thể khiến cả đội sợ thay đổi. Tên biến mơ hồ, hàm quá dài và test thiếu khiến mỗi lần sửa giống như dò mìn. Khi đó, chất lượng code không còn là chuyện thẩm mỹ; nó trở thành thời gian, rủi ro và chi phí thật của dự án.

Design Pattern rất dễ biến thành bộ tên gọi để khoe kiến thức. Giá trị thật chỉ xuất hiện khi một mẫu giúp cả đội nhận ra vấn đề quen thuộc và nói về giải pháp bằng cùng một ngôn ngữ.

Design pattern là giải pháp khái quát cho vấn đề thiết kế lặp lại trong một bối cảnh cụ thể. Pattern cung cấp ngôn ngữ chung để thảo luận, nhưng không phải đoạn code có thể sao chép nguyên xi.

Một pattern chỉ hữu ích khi làm rõ quan hệ và điểm thay đổi. Nếu áp dụng quá sớm, nó tạo thêm lớp trừu tượng, file và chi phí hiểu hệ thống.

## Những khái niệm cốt lõi cần nắm

## Học vấn đề trước khi học tên mẫu

Pattern không phải đoạn code để sao chép nguyên xi. Nó là cách tổ chức trách nhiệm đã được dùng nhiều lần cho một nhóm vấn đề, kèm theo ưu điểm và cái giá phải trả.

## Chuyện gì xảy ra khi đem vào dự án thật?

Nếu áp dụng pattern quá sớm, một chức năng đơn giản có thể bị chia thành nhiều lớp và interface khó theo dõi. Ngược lại, không nhận ra cấu trúc lặp lại sẽ khiến code ngày càng chắp vá.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Mỗi khi học một pattern, hãy trả lời ba câu: vấn đề nào dẫn đến nó, đánh đổi là gì và khi nào không nên dùng. Ba câu đó hữu ích hơn việc thuộc sơ đồ lớp.

- Creational kiểm soát cách tạo đối tượng.

- Structural tổ chức quan hệ giữa thành phần.

- Behavioral điều phối hành vi và giao tiếp.

- Context quyết định lợi ích và đánh đổi.

## Lộ trình thực hành từng bước

- Bước 1: Mô tả vấn đề và điểm thay đổi.

- Bước 2: Thử giải pháp đơn giản trước.

- Bước 3: Chọn pattern khi nhóm hiểu rõ lợi ích và kiểm thử được.

## Những sai lầm thường gặp

- Cố nhét pattern vào mọi class.

- Học thuộc sơ đồ nhưng không hiểu đánh đổi.

- Tạo abstraction chỉ có một triển khai không cần thiết.

## Góc nhìn dành cho người học và developer Việt Nam

Developer Việt Nam chuẩn bị phỏng vấn nên giải thích được vì sao chọn pattern, phương án đơn giản hơn là gì và chi phí bảo trì, thay vì chỉ nêu định nghĩa.

## Nên học tiếp như thế nào?

## Bài tập học Design Pattern từ vấn đề

Lấy một đoạn code có nhiều câu lệnh điều kiện theo loại đối tượng. Viết ra điều gì sẽ xảy ra nếu thêm hai loại mới, rồi thử tổ chức lại bằng Strategy hoặc Factory. Sau đó làm phiên bản đơn giản không dùng pattern và so sánh số lớp, khả năng mở rộng, mức dễ đọc. Bài học nằm ở đánh đổi giữa hai phiên bản, không nằm ở việc phiên bản nào dùng nhiều thuật ngữ hơn.

## Ví dụ xuyên suốt để nối kiến thức

Một hệ thống thanh toán phải hỗ trợ thẻ, chuyển khoản và ví điện tử. Nếu mọi nhánh nằm trong một hàm, thêm phương thức mới dễ làm hỏng nhánh cũ. Strategy có thể tách thuật toán, nhưng nếu chỉ có một phương thức cố định, pattern lại tạo thêm lớp không cần thiết.

## Khung triển khai từ thử nghiệm đến thực tế

Pattern nên xuất hiện sau khi vấn đề và lực thay đổi đã rõ. Hãy hỏi phần nào thường đổi, phần nào cần ổn định và team có thực sự hiểu abstraction mới hay không.

### Bốn bước nên đi theo thứ tự

- Viết phiên bản đơn giản để quan sát điểm thay đổi.

- Nhận diện code smell và trách nhiệm đang bị trộn.

- So sánh ít nhất một giải pháp không dùng pattern.

- Áp dụng tối thiểu, viết test và ghi lại đánh đổi trong review.

## Trade-off cần nhìn thẳng

Pattern giảm phụ thuộc ở đúng bối cảnh nhưng tăng số khái niệm, file và đường gọi. Chi phí nhận thức là chi phí thật, đặc biệt với đội nhỏ hoặc domain còn thay đổi nhanh.

## Đánh giá bằng kết quả thay vì cảm giác

Đánh giá số nơi phải sửa khi thêm hành vi, mức dễ test và thời gian đồng đội hiểu luồng. Đừng dùng số lượng pattern như thước đo chất lượng thiết kế.

## Giá trị đối với năng lực nghề nghiệp

Biết nói “chưa cần pattern” với lý do rõ ràng thể hiện tư duy thiết kế trưởng thành hơn việc cố gắn tên mẫu vào mọi đoạn code.

## Câu hỏi tự kiểm tra trước khi chuyển chủ đề

Bạn có thể giải thích Design Pattern là gì bằng ngôn ngữ của mình, nêu một trường hợp nên dùng, một trường hợp không nên dùng và chỉ ra cách đo kết quả hay chưa? Nếu chưa, hãy quay lại ví dụ nhỏ trong bài, thay đổi một ràng buộc rồi quan sát điều gì buộc giải pháp phải thay đổi. Đây là cách biến kiến thức đọc được thành khả năng ra quyết định.

## Góc nhìn dành cho developer Việt Nam

Với developer đang làm việc trong các đội sản phẩm tại Việt Nam, hãy dùng nguyên tắc như câu hỏi để review chứ đừng biến chúng thành luật cứng. Mục tiêu là giúp đồng đội đọc nhanh hơn, sửa an toàn hơn và trao đổi chính xác hơn về ý định của code.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Clean Code, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/clean-code-robert-c-martin-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.