Áp dụng quy tắc “trừu tượng đặt trong code và chi tiết đặt trong metadata” và mẫu Factory Method, tôi sử dụng mẫu Dynamic Factory [13] để giải quyết vấn đề tạo/thay đổi một đối tượng khi đang chạy chương trình bằng cách sử dụng thông tin được lưu trữ trong metadata
Trước khi trình bày mẫu thiết kế Dynamic Factory, tôi trình bày tổng quát về mẫu Factory Method.
4.3.3.1 Mẫu Factory Method
Factory Method [5] là một mẫu thiết kế hướng đối tượng nhằm giải quyết vấn đề tạo một đối tượng mà không cần thiết chỉ ra một cách chính xác lớp nào sẽ được khởi tạo. Factory method giải quyết vấn đề này bằng cách định nghĩa một phương thức cho việc tạo đối tượng, và các lớp con thừa kế có thể cài đặt lại để chỉ rõ đối tượng nào sẽ được tạo.
Áp dụng: mẫu Factory Method thường được áp dụng khi • Một lớp không tham gia vào lớp tạo đối tượng
• Một lớp mong muốn lớp con xác định đối tượng mà nó tạo ra
• Lớp giao trách nhiệm cho một trong các lớp con giải quyết và bạn muốn lớp đó cài đặt lại
Cấu trúc mẫu:
Các thành phần trong hình 4-8 được mô tả chi tiết như sau:
• Product: Định nghĩa giao diện/lớp đối tượng mà factory method tạo ra • ConcreteProduct: Cài đặt giao diện/Kế thừa lớp Product
• Creator:
o Khai báo factory method, trả về đối tượng thuộc kiểu Product o Có thể gọi factory method để tạo đối tượng Product
o ConcreteCreator: cài đặt lại factory method, trả về đối tượng thuộc kiểu ConcreteProduct
Thuận lợi và hạn chế:
• Thuận lợi là đối tượng trả về của factory method là con trỏ đến Product, do đó mà hàm sản xuất có thể trả về bất kỳ đối tượng nào. Điều này loại bỏ việc phải tạo lập một cách trực tiếp một ConcreteProduct trong code, vốn làm hạn chế sự linh động khi sửa đổi chương trình (tight-coupling)
• Hạn chế là mỗi khi cần tạo một đối tượng mới ta phải kế thừa lại lớp Creator và cài đặt phương thức tạo lập
4.3.3.2 Mẫu Dynamic Factory - cải tiến của mẫu Factory Method
Ý nghĩa: N hằm giải quyết vấn đề tạo/thay đổi một đối tượng khi đang chạy chương trình bằng cách sử dụng thông tin được lưu trữ trong metadata.
Cấu trúc mẫu:
Chúng ta nhận thấy cấu trúc mẫu Dynamic Factory trong hình 4-6 và cấu trúc mẫu Factory Method trong hình 4-5 là tương tư nhau. Tuy nhiên trong cấu trúc mẫu ở hình 4-6 có bổ sung 3 thành phần sau:
• MetaData: Thông tin cấu hình trong cơ sở dữ liệu, xml…
• MetaDataReader: Cài đặt giao diện/lớp dùng để đọc thông tin cấu hình. • Information: Cài đặt giao diện/lớp lưu trữ thông tin về concrete Product được
đọc từ metadata.
&hận xét: Mẫu cải tiến này ngoài ưu điểm của Factory Method còn có những ưu điểm sau:
• Tính linh hoạt: Các đối tượng có thể được tạo động với thông tin được lưu trữ trong metadata. Khi sử dụng các kỹ thuật lập trình Reflection trong Java [6] (hay bất kỳ các kỹ thuật tương tự khác), các đối tượng có thể được chỉnh sửa hay xóa và đối tượng mới có thể thêm vào ngay lúc chạy chương trình. • Tính cấu hình: Có thể dễ dàng thay đổi hành vi ứng dụng bằng cách thay đổi
thông tin cấu hình của chúng. Điều này có thể thực hiện mà không cần bất kỳ sự thay đổi code nào cũng như không cần khởi động lại ứng dụng.
• Tuy nhiên mẫu cải tiến này vẫn còn một số hạn chế như: N guy cơ lỗi khi chạy: Các lỗi khi chạy ứng dụng có thể phát sinh khi sử dụng mẫu cải tiến này. Vào lúc biên dịch có thể không phát hiện lỗi nhưng khi thêm hay sửa metadata lúc chạy chương trình thì các lỗi có thể xảy ra.
Áp dụng vào hệ thống đang xây dựng
Tôi áp dụng mẫu Dynamic Factory vào việc xây dựng thành phần controller trong mô hình MVC của ứng dụng. Các nhà phát triển thay vì mã hóa cứng các lớp xử lý ứng với từng yêu cầu của người dùng vào chương trình Java thì có thể lưu trữ thông tin các lớp xử lý của ứng dụng trong tệp tin cấu hình xml. Điều này nhằm mục đích hỗ trợ nhà phát triển không cần phải thay đổi hay biên dịch lại ứng dụng khi cần thay đổi thông tin xử lý. Khi đó, các nhà phát triển web có thể tập trung hơn vào công việc cụ thể của họ mà không cần quan tâm đến tổng thể của hệ thống.
(adsbygoogle = window.adsbygoogle || []).push({});