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:
0 comments:
Post a Comment