Mẫu thiết kế (design pattern) giải thích: 23 mẫu của Gang of Four

Mẫu thiết kế là gì

Mẫu thiết kế không phải là thư viện hay đoạn mã để sao chép. Nó là mô tả về một vấn đề lặp đi lặp lại, cốt lõi của lời giải và những đánh đổi khi dùng. Bạn vẫn tự viết mã, điều chỉnh theo ngôn ngữ và chương trình của mình.

Cuốn sách GoF mô tả mỗi mẫu bằng bốn thành phần thiết yếu:

• Tên: một hai từ giúp lập trình viên trao đổi về thiết kế, chẳng hạn "ta có thể bọc nó bằng mẫu Decorator".
• Vấn đề: khi nào áp dụng mẫu, và tình huống khiến nó cần thiết.
• Lời giải: các lớp hoặc đối tượng tham gia, trách nhiệm của chúng và cách chúng phối hợp.
• Hệ quả: chi phí và lợi ích, chẳng hạn linh hoạt hơn nhưng đổi lại có thêm nhiều lớp.

Ý tưởng này đến từ kiến trúc. Cuốn A Pattern Language (1977) của Christopher Alexander mô tả các lời giải lặp lại cho công trình và đô thị, và các tác giả GoF áp dụng cùng ý tưởng cho phần mềm hướng đối tượng.

Cuốn sách Gang of Four

Design Patterns: Elements of Reusable Object-Oriented Software được Addison-Wesley xuất bản năm 1994. Ví dụ trong sách dùng C++ và Smalltalk, nhưng các mẫu áp dụng cho mọi ngôn ngữ hướng đối tượng, gồm Java, C#, TypeScript, Python và Kotlin.

Ngoài danh mục, cuốn sách đề xuất hai nguyên tắc chung xuyên suốt hầu hết các mẫu:

• Lập trình theo interface, không theo cách triển khai. Mã nên phụ thuộc vào việc một đối tượng làm được gì, không phải lớp cụ thể của nó.
• Ưu tiên kết hợp đối tượng (composition) hơn kế thừa lớp. Xây dựng hành vi bằng cách kết hợp các đối tượng thường linh hoạt hơn xây các cây kế thừa sâu.

Cuốn sách cũng phân loại mỗi mẫu theo phạm vi: mẫu lớp dùng kế thừa và cố định lúc biên dịch (Factory Method, Adapter dạng lớp, Interpreter, Template Method), còn mẫu đối tượng dùng composition và có thể thay đổi lúc chạy (tất cả các mẫu còn lại).

Cả 23 mẫu GoF theo nhóm

Mẫu khởi tạo (creational) lo việc đối tượng được tạo ra thế nào. Mẫu cấu trúc (structural) lo việc ghép lớp và đối tượng thành cấu trúc lớn hơn. Mẫu hành vi (behavioral) lo việc các đối tượng giao tiếp và chia sẻ trách nhiệm ra sao.

Một mẫu trong thực tế: mẫu Strategy bằng TypeScript

Đây là một ví dụ nhỏ về mẫu đang hoạt động. Một quy trình thanh toán phải tính phí vận chuyển theo nhiều cách. Thay vì chuỗi if/else ngày càng dài, mỗi quy tắc trở thành một đối tượng có thể thay thế sau cùng một interface:

interface ShippingStrategy {
  cost(weightKg: number): number;
}
class FlatRate implements ShippingStrategy {
  cost(): number { return 5; }
}
class PerKilogram implements ShippingStrategy {
  cost(weightKg: number): number { return 2 * weightKg; }
}
class Checkout {
  constructor(private shipping: ShippingStrategy) {}
  setShipping(s: ShippingStrategy): void { this.shipping = s; }
  total(itemsPrice: number, weightKg: number): number {
    return itemsPrice + this.shipping.cost(weightKg);
  }
}
const checkout = new Checkout(new FlatRate());
console.log(checkout.total(40, 3)); // 45
checkout.setShipping(new PerKilogram());
console.log(checkout.total(40, 3)); // 46

Trong TypeScript, hàm là giá trị, nên cùng thiết kế có thể viết với ít mã hơn. Đây là một chủ đề thường gặp: nhiều mẫu trở nên đơn giản hơn, hoặc biến mất, trong các ngôn ngữ có hàm hạng nhất (first-class function).

type Shipping = (weightKg: number) => number;
const flatRate: Shipping = () => 5;
const perKilogram: Shipping = (w) => 2 * w;
function total(itemsPrice: number, weightKg: number, shipping: Shipping): number {
  return itemsPrice + shipping(weightKg);
}
console.log(total(40, 3, flatRate));    // 45
console.log(total(40, 3, perKilogram)); // 46

Cách chọn mẫu

Hãy bắt đầu từ vấn đề, đừng bao giờ bắt đầu từ mẫu. Một mẫu chỉ đáng với số lớp thêm vào khi nó gỡ được một nỗi đau thật trong mã của bạn. Những câu hỏi sau chỉ ra các ứng viên thường gặp:

1. Trước hết hãy viết đoạn mã đơn giản nhất mà chạy được.
2. Khi cùng một thay đổi cứ gây khó chịu (ví dụ mỗi loại thanh toán mới phải sửa năm tệp), hãy đặt tên cho vấn đề.
3. Tra cứu những mẫu giải quyết vấn đề đó và đọc phần hệ quả của chúng.
4. Áp dụng phiên bản nhỏ nhất của mẫu đủ gỡ được nỗi đau, rồi dừng lại.

Phê bình và hạn chế

Mẫu thiết kế hữu ích, nhưng thường bị dùng sai. Nên biết những lời phê bình phổ biến:

• Lạm dụng: thêm factory, interface và manager "phòng khi cần" làm mã đơn giản trở nên khó đọc. Đôi khi điều này được gọi là bệnh mẫu (pattern fever).
• Thiếu tính năng ngôn ngữ: năm 1996 Peter Norvig chỉ ra rằng 16 trong 23 mẫu GoF là vô hình hoặc đơn giản hơn trong các ngôn ngữ động như Lisp và Dylan. Hàm hạng nhất thay cho Strategy và Command, còn iterator tích hợp thay cho Iterator.
• Riêng mẫu Singleton được nhiều người coi là phản mẫu (anti-pattern) khi dùng làm trạng thái toàn cục, vì nó che giấu các phụ thuộc và làm kiểm thử khó hơn.
• Danh mục này có từ năm 1994. Thực tiễn sau đó bổ sung các mẫu nổi tiếng khác không có trong sách, như dependency injection, repository và các biến thể Model-View-Controller.

Giá trị lâu dài của cuốn sách là vốn từ chung và thói quen suy nghĩ về các đánh đổi. Nói "đây là một Adapter" cho lập trình viên khác biết rất nhiều chỉ bằng hai từ.

Các nguyên lý liên quan

Các mẫu thường được giải thích cùng các nguyên lý SOLID của thiết kế hướng đối tượng. Ví dụ, Strategy và Decorator là cách trực tiếp để tuân theo nguyên lý đóng/mở (open/closed), còn Abstract Factory là cách thường dùng để áp dụng nguyên lý đảo ngược phụ thuộc (dependency inversion). Học các nguyên lý giúp bạn hiểu vì sao một mẫu có hình dạng như vậy.