Learning Hub
Thiết kế hệ thống & Kiến trúc

Design pattern qua một ứng dụng nhỏ

6 phút đọc·Cập nhật 2026-09-09

Design pattern đặt tên cho tradeoff và cách sắp trách nhiệm lặp lại; nó hữu ích khi context phù hợp chứ không phải đồ trang trí cho code đơn giản.

Design pattern đặt tên cho tradeoff và cách sắp trách nhiệm lặp lại; nó hữu ích khi context phù hợp chứ không phải đồ trang trí cho code đơn giản.

Nhìn nhanh

Câu hỏi Câu trả lời thực tế
Dùng khi nào? Trong một tình huống thực tế nhỏ, hãy vẽ các thành phần, theo dõi một request hoặc quyết định từ đầu đến cuối và đánh dấu bằng chứng tạo ra ở từng bước.
Cần làm gì? Build notification app đơn giản rồi thêm Strategy cho channel, Adapter cho provider và Observer cho event; so change cost trước/sau.
Biết là đúng bằng cách nào? Người khác có thể làm lại từ ghi chú của bạn và mỗi nhận định quan trọng đều có output, số đo, kết quả truy vấn hoặc artifact để review.
Lỗi hay gặp? Lỗi phổ biến là chọn công cụ hoặc pattern trước khi nêu rõ bài toán, ràng buộc và cách đo thành công.
flowchart LR
  A[Câu hỏi] --> B[Design pattern qua một ứng dụng nhỏ]
  B --> C[Ví dụ nhỏ]
  C --> D[Bằng chứng]

Điểm quan trọng của sơ đồ là không dừng ở định nghĩa: hãy nối khái niệm với một ví dụ nhỏ và bằng chứng có thể quan sát.

Ví dụ đã phân tích

Trong một tình huống thực tế nhỏ, hãy vẽ các thành phần, theo dõi một request hoặc quyết định từ đầu đến cuối và đánh dấu bằng chứng tạo ra ở từng bước.

Trước khi làm, hãy viết dấu hiệu thành công. Sau đó chỉ thay đổi một yếu tố, quan sát kết quả và ghi lại assumption. Với Design pattern qua một ứng dụng nhỏ, cách này giúp tách điều bạn biết khỏi điều bạn chỉ đang đoán.

Thực hành trong 20–30 phút

Mục tiêu: Build notification app đơn giản rồi thêm Strategy cho channel, Adapter cho provider và Observer cho event; so change cost trước/sau.

  1. Ghi lại trạng thái ban đầu và điều bạn dự đoán.
  2. Thực hiện phiên bản nhỏ nhất, không thêm công cụ chưa cần thiết.
  3. Thay đổi đúng một input hoặc constraint rồi chạy lại.
  4. Lưu command, screenshot, output hoặc checklist làm bằng chứng.

Kết quả mong đợi: Người khác có thể làm lại từ ghi chú của bạn và mỗi nhận định quan trọng đều có output, số đo, kết quả truy vấn hoặc artifact để review.

Sai ở đâu và sửa thế nào

Lỗi phổ biến là chọn công cụ hoặc pattern trước khi nêu rõ bài toán, ràng buộc và cách đo thành công.

Khi kết quả khác dự đoán, đừng đổi nhiều thứ cùng lúc. Kiểm tra input, version, environment, quyền truy cập và log trước; sau đó lặp lại từ ví dụ nhỏ nhất.

Định nghĩa hoàn thành

  • Tôi giải thích được khái niệm bằng ngôn ngữ của mình.
  • Tôi đã hoàn thành ví dụ nhỏ và giữ bằng chứng.
  • Tôi biết một failure mode và cách kiểm tra nó.
  • Người khác có thể làm lại mà không phải đoán bước còn thiếu.

Đi sâu hơn

Mở resource hoặc repository đi kèm ở cuối trang khi bạn cần implementation đầy đủ. Hãy kiểm tra version hiện hành trước khi dùng command trong dự án thật.