Khái niệm:
Cung cấp một interface cho việc tạo ra một “dòng” (family) các loại đối tượng liên quan hoặc phụ thuộc mà không cần xác định những lớp cụ thể của chúng.
Mức độ sử dụng: cao
UML Class Diagram:
Những lớp và/hoặc các đối tượng trong mẫu thiết kế này:
- AbstractFactory (ContientFactory): khai báo một interface cho các hoạt động tạo các abstract product.
- ConcreteFactory (Africafactory, AmericaFactory): thực thi các hoạt động để tạo các đối tượng concrete product.
- AbstractProduct (Herbivore, Carnivore): khai báo một interface cho một kiểu đối tượng product.
- Product (Wildebeest, Lion, Bison, Wolf): định nghĩa một đối tượng product được tạo bởi concrete factory tương ứng thực thi AbstractFactory interface.
- Client (AnimalWorld): sử dụng các interface được khai báo bởi các lớp AbstractFactory và AbstractProduct.
Abstract Factory: khi nào sử dụng và sử dụng ở đâu
Mẫu thiết kế Abstract Factory cung cấp một lớp tạo ra các đối tượng khác liên quan bởi một “khuôn mẫu” (theme) chung. Ví dụ điển hình là một factory thành phần UI tạo ra các UI control cho các hệ thống cửa sổ khác nhau như Windows, Motif hay MacOS.
Trải qua thời gian, ý nghĩa của mẫu thiết kế Abstract Factory đã phát triển tương ứng theo khái niệm của GoF (Gangs of Four). Ngày nay, khi lập trình viên nói về mẫu thiết kế này, họ không chỉ đề cập đến ý nghĩa của việc tạo ra một “dòng” (family) các đối tượng liên quan hoặc phụ thuộc mà còn có một ý kiến khá đơn giản nữa, đó là việc tạo ra “individual object instances”.
Bạn có thể tự hỏi rằng tại sao lại tạo ra các đối tượng bằng việc dùng một lớp khác (được gọi là Abstract Factory) hơn là gọi trực tiếp hàm dựng của nó. Sau đây là một vài lý do:
- Các hàm dựng bị hạn chế trong việc kiểm soát của chúng qua các tiến trình tạo lập tổng thể. Nếu ứng dụng của bạn cần nhiều sự điều khiển hơn, hãy xem xét dùng Factory.
- Ngoài ra, có những lần khi client không biết chính xác kiểu nào cần xây dựng. Điều đó sẽ trở nên dễ dàng hơn để code đối với một kiểu cơ bản hoặc một interface và sau đó để cho factory quyết định giúp cho client. Ví dụ cho vấn đề này đó là các đối tượng ADO.NET provider (DbConnection, DbCommand, DbAdapter,…)
- Các hàm dựng không liên lạc tốt vì chúng phải được đặt tên sau khi lớp của nó đã đặt tên. Có nhiều hàm dựng quá tải (overloaded constructor) có thể làm cho việc này trở nên khó khăn cho lập trình viên client quyết định chọn hàm dựng nào để dùng. Dưới đây là một ví dụ với 4 overloaded constructor. Thật không rõ ràng để chọn ra một constructor để sử dụng.
Mẫu thiết kế Factory làm code trở nên có hàm ý nhiều hơn
Demo: