Mẫu Thiết Kế Phần Mềm và Ứng Dụng: Hướng Dẫn Chi Tiết

Khám phá luận văn thạc sĩ về phát triển mẫu thiết kế phần mềm và ứng dụng, cung cấp kiến thức và giải pháp sáng tạo trong lĩnh vực công nghệ.

• Tác giả: Nghiêm Văn Triệu
• Người hướng dẫn: PGS. TS Đoàn Văn Ban
• Trường học: Đại Học Quốc Gia Hà Nội
• Chuyên ngành: Công Nghệ Thông Tin
• Đề tài: Phát Triển Mẫu Thiết Kế Phần Mềm Và Ứng Dụng
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2010
• Địa điểm: Hà Nội

Tóm tắt

I. Tổng Quan Mẫu Thiết Kế Phần Mềm Khái Niệm Lợi Ích

Trong lĩnh vực phát triển phần mềm, khả năng tái sử dụng là một tiêu chí quan trọng để đánh giá chất lượng. Dù mỗi dự án phần mềm có tính chất phức tạp và riêng biệt, nhưng sự lặp lại ở một hoặc nhiều điểm vẫn xuất hiện. Các chuyên gia đã nghiên cứu và đưa ra giải pháp cho các vấn đề lặp đi lặp lại, hình thành nên khái niệm mẫu thiết kế (Software Design Patterns). Cuốn sách "Elements of Reusable Object-Oriented Software" của Erich Gamma và cộng sự đã đánh dấu sự ra đời của thiết kế mẫu. Mẫu thiết kế giúp giải quyết bài toán nhanh chóng, có khả năng tái sử dụng. Dựa trên nguyên lý thiết kế hướng đối tượng (Object-Oriented Design), mẫu thiết kế là công cụ để phát hiện và mô tả bài toán ở mức trừu tượng cao. Erich Gamma và cộng sự đã đưa ra 23 mẫu thiết kế nổi tiếng, được gọi là mẫu GOF (Gang of Four). Tuy nhiên, sự phát triển nhanh chóng của công nghiệp phần mềm đòi hỏi những mẫu thiết kế mới phù hợp hơn.

1.1. Định Nghĩa Chi Tiết về Mẫu Thiết Kế Phần Mềm

Mẫu thiết kế mô tả một vấn đề lặp đi lặp lại và các giải pháp cho vấn đề đó. Nó là một khuôn mẫu áp dụng để giải quyết các trường hợp của cùng một loại vấn đề. Trong công nghệ phần mềm, mẫu thiết kế là các giải pháp cho vấn đề trong thiết kế các hệ thống phần mềm. Đây là tập các giải pháp đã được công nhận có giá trị và người phát triển phần mềm áp dụng để giải quyết các vấn đề tương tự. Khả năng tái sử dụng các giải pháp chuẩn đối với vấn đề xảy ra thường xuyên là mục tiêu quan trọng trong việc sử dụng mẫu thiết kế. Theo Christopter Alexander, "Mỗi mẫu mô tả một vấn đề mang tính chất xuất hiện lặp đi lặp lại trong môi trường của chúng ta, một giải pháp cho vấn đề đó."

1.2. Lợi Ích Của Việc Sử Dụng Mẫu Thiết Kế Trong Phát Triển Phần Mềm

Sử dụng mẫu thiết kế mang lại nhiều lợi ích quan trọng. Đầu tiên, giúp tăng tốc độ phát triển phần mềm bằng cách cung cấp các giải pháp đã được kiểm chứng cho các vấn đề thường gặp. Điều này giúp giảm thời gian và công sức cần thiết để thiết kế và triển khai các giải pháp mới. Thứ hai, tăng tính tái sử dụng của mã nguồn, cho phép các nhà phát triển sử dụng lại các giải pháp đã được xây dựng trước đó trong các dự án khác nhau. Cuối cùng, cải thiện tính bảo trì và mở rộng của phần mềm bằng cách cung cấp một cấu trúc rõ ràng và dễ hiểu, giúp các nhà phát triển dễ dàng sửa đổi và nâng cấp phần mềm theo thời gian.

II. Thách Thức Thiết Kế Phần Mềm Hướng Đối Tượng Giải Pháp

Việc thiết kế phần mềm hướng đối tượng (Object-Oriented Design) là một thách thức. Thiết kế phải đảm bảo giải quyết được vấn đề mong muốn và có khả năng mở rộng trong tương lai mà không cần thiết kế lại. Tuy nhiên, không thể đảm bảo rằng thiết kế đó là đúng và đáp ứng được các yêu cầu trên. Do đó, cần đưa ra một vài phương án để từ đó lựa chọn được phương án tốt nhất. Phương án này đôi khi được dùng lại nhiều lần khi gặp các vấn đề tương tự. Ta hay gặp những vấn đề tương tự nhau được phát triển thành các mẫu thiết kế, để sử dụng cho các hệ thống phần mềm ứng dụng. Vấn đề chung là làm sao để tạo ra các thành phần phần mềm có thể tái sử dụng, dễ bảo trì và mở rộng.

2.1. Vấn Đề Độ Phức Tạp Cyclomatic và Code Smell trong Thiết Kế

Một trong những thách thức lớn nhất trong thiết kế phần mềm là quản lý độ phức tạp. Độ phức tạp Cyclomatic đo lường số lượng đường dẫn độc lập tuyến tính thông qua một đoạn mã. Mã có độ phức tạp cao thường khó hiểu, khó kiểm tra và dễ mắc lỗi. Code Smell là những dấu hiệu cho thấy có vấn đề tiềm ẩn trong thiết kế mã nguồn, chẳng hạn như mã trùng lặp, lớp lớn, hoặc phương thức dài. Việc nhận diện và giải quyết các code smell sớm có thể giúp cải thiện chất lượng và khả năng bảo trì của phần mềm. Refactoring là một kỹ thuật quan trọng để loại bỏ code smell và giảm độ phức tạp.

2.2. Vấn Đề Phân Tích Yêu Cầu Phần Mềm Thiếu Sót Ảnh Hưởng Thế Nào

Phân tích yêu cầu phần mềm là một bước quan trọng trong quá trình phát triển phần mềm. Nếu yêu cầu không được phân tích kỹ lưỡng và đầy đủ, điều này có thể dẫn đến các vấn đề như thiết kế không chính xác, bỏ sót chức năng, hoặc hiểu sai về nhu cầu của người dùng. Việc này có thể gây ra sự chậm trễ trong dự án, tăng chi phí và giảm chất lượng của phần mềm. Do đó, cần chú trọng vào việc thu thập, phân tích và xác minh yêu cầu một cách kỹ lưỡng.

III. Nguyên Tắc SOLID Nền Tảng Vững Chắc Cho Mẫu Thiết Kế

Các nguyên tắc SOLID đóng vai trò quan trọng trong việc thiết kế phần mềm hướng đối tượng và là nền tảng cho nhiều mẫu thiết kế. SOLID là viết tắt của 5 nguyên tắc thiết kế cơ bản: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), và Dependency Inversion Principle (DIP). Việc tuân thủ các nguyên tắc này giúp tạo ra các thành phần phần mềm linh hoạt, dễ bảo trì và mở rộng. Các nguyên tắc SOLID giúp giảm sự phụ thuộc giữa các thành phần, tăng tính tái sử dụng và giảm thiểu rủi ro khi thay đổi mã nguồn.

3.1. Tìm Hiểu Nguyên Lý Đóng Mở và Ứng Dụng Thực Tế

Nguyên lý Đóng Mở (Open/Closed Principle) phát biểu rằng một lớp nên mở cho việc mở rộng, nhưng đóng cho việc sửa đổi. Điều này có nghĩa là ta có thể thêm chức năng mới vào lớp mà không cần thay đổi mã nguồn hiện có của lớp. Để đạt được điều này, ta có thể sử dụng các kỹ thuật như kế thừa, giao diện, hoặc mẫu thiết kế Strategy. Ví dụ, nếu ta muốn thêm một loại báo cáo mới vào hệ thống, ta có thể tạo một lớp con của lớp báo cáo gốc và ghi đè các phương thức cần thiết, thay vì sửa đổi trực tiếp lớp báo cáo gốc.

3.2. Giải Thích Chi Tiết Nguyên Lý Nghịch Đảo Phụ Thuộc

Nguyên lý Nghịch Đảo Phụ Thuộc (Dependency Inversion Principle) phát biểu rằng các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào các abstraction. Abstraction không nên phụ thuộc vào details. Details nên phụ thuộc vào abstraction. Điều này có nghĩa là thay vì các lớp phụ thuộc trực tiếp vào các lớp khác, chúng nên phụ thuộc vào các giao diện hoặc lớp trừu tượng. Ví dụ, nếu một lớp cần sử dụng một dịch vụ ghi nhật ký, nó nên phụ thuộc vào một giao diện ghi nhật ký, thay vì một lớp ghi nhật ký cụ thể. Điều này giúp lớp dễ dàng thay đổi dịch vụ ghi nhật ký mà không cần sửa đổi mã nguồn của lớp.

IV. UML Unified Modeling Language Công Cụ Mô Hình Hóa Phần Mềm

UML (Unified Modeling Language) là một ngôn ngữ mô hình hóa tiêu chuẩn được sử dụng để trực quan hóa, đặc tả, xây dựng và ghi lại các thành phần của một hệ thống phần mềm. UML cung cấp một tập hợp các ký hiệu và quy tắc để mô tả các khía cạnh khác nhau của hệ thống, chẳng hạn như cấu trúc, hành vi và tương tác. UML giúp các nhà phát triển hiểu rõ hơn về hệ thống, giao tiếp hiệu quả hơn và thiết kế các giải pháp tốt hơn. Sử dụng UML giúp giảm thiểu rủi ro và tăng khả năng thành công của dự án.

4.1. Các Loại Biểu Đồ UML Phổ Biến và Mục Đích Sử Dụng

UML cung cấp nhiều loại biểu đồ khác nhau để mô tả các khía cạnh khác nhau của hệ thống. Một số loại biểu đồ phổ biến bao gồm biểu đồ lớp (class diagram), biểu đồ đối tượng (object diagram), biểu đồ trình tự (sequence diagram), biểu đồ trạng thái (state diagram), biểu đồ hoạt động (activity diagram) và biểu đồ thành phần (component diagram). Mỗi loại biểu đồ có một mục đích sử dụng riêng. Biểu đồ lớp được sử dụng để mô tả cấu trúc tĩnh của hệ thống, biểu đồ trình tự được sử dụng để mô tả tương tác giữa các đối tượng theo thời gian, và biểu đồ trạng thái được sử dụng để mô tả trạng thái của một đối tượng và các chuyển đổi giữa các trạng thái.

4.2. Cách Sử Dụng UML để Thiết Kế Mẫu Thiết Kế Hiệu Quả

UML có thể được sử dụng để mô tả các mẫu thiết kế một cách rõ ràng và chính xác. Bằng cách sử dụng biểu đồ lớp, ta có thể mô tả cấu trúc của mẫu thiết kế, bao gồm các lớp, giao diện và mối quan hệ giữa chúng. Bằng cách sử dụng biểu đồ trình tự, ta có thể mô tả tương tác giữa các đối tượng trong mẫu thiết kế. Việc sử dụng UML giúp các nhà phát triển hiểu rõ hơn về mẫu thiết kế, dễ dàng triển khai và tái sử dụng nó trong các dự án khác nhau. Ví dụ, sơ đồ lớp mẫu Abstract Factory giúp minh họa rõ mối quan hệ giữa các lớp AbstractFactory, ConcreteFactory, AbstractProduct và Product.

V. Ứng Dụng Mẫu Thiết Kế Ví Dụ Trường Hợp Nghiên Cứu Thực Tế

Mẫu thiết kế không chỉ là lý thuyết mà còn có nhiều ứng dụng thực tế trong các dự án phần mềm. Việc áp dụng mẫu thiết kế giúp giải quyết các vấn đề phức tạp một cách hiệu quả, tăng tính tái sử dụng của mã nguồn và giảm thiểu rủi ro trong quá trình phát triển. Nhiều dự án phần mềm lớn đã sử dụng mẫu thiết kế để xây dựng các hệ thống linh hoạt, dễ bảo trì và mở rộng. Các mẫu MVC (Model-View-Controller), Singleton Pattern, Factory Pattern được áp dụng rộng rãi.

5.1. Phân Tích Chi Tiết Mô Hình MVC và Ứng Dụng Trong Web Development

Mô hình MVC (Model-View-Controller) là một mẫu thiết kế phổ biến trong phát triển ứng dụng web. MVC chia ứng dụng thành ba thành phần chính: Model (dữ liệu và logic nghiệp vụ), View (giao diện người dùng) và Controller (điều khiển tương tác giữa Model và View). MVC giúp tách biệt các mối quan tâm, tăng tính tái sử dụng của mã nguồn và dễ dàng bảo trì. Nhiều framework web phổ biến như Spring MVC (Java), Django (Python), Ruby on Rails (Ruby) sử dụng mô hình MVC.

5.2. Nghiên Cứu Trường Hợp Áp Dụng Singleton Pattern Trong Hệ Thống Logging

Singleton Pattern là một mẫu thiết kế đảm bảo rằng một lớp chỉ có một thể hiện duy nhất và cung cấp một điểm truy cập toàn cục đến thể hiện đó. Singleton thường được sử dụng trong các hệ thống logging, quản lý cấu hình hoặc quản lý kết nối cơ sở dữ liệu. Ví dụ, trong một hệ thống logging, ta có thể sử dụng Singleton Pattern để đảm bảo rằng chỉ có một instance của lớp Logger được tạo ra, và tất cả các thành phần khác trong hệ thống có thể truy cập đến instance này để ghi nhật ký.

VI. Tương Lai Mẫu Thiết Kế Phần Mềm Xu Hướng Triển Vọng Mới

Với sự phát triển không ngừng của công nghệ phần mềm, mẫu thiết kế cũng đang tiếp tục phát triển và thích nghi với các xu hướng mới. Các mẫu thiết kế mới đang được phát triển để giải quyết các vấn đề phức tạp hơn, chẳng hạn như trong lĩnh vực Microservices, điện toán đám mây và trí tuệ nhân tạo. Ngoài ra, sự phát triển của các ngôn ngữ lập trình mới và các framework phần mềm cũng đang ảnh hưởng đến cách thức các mẫu thiết kế được triển khai và sử dụng. Nắm bắt các xu hướng mới và liên tục cập nhật kiến thức về mẫu thiết kế là rất quan trọng để các nhà phát triển có thể xây dựng các hệ thống phần mềm chất lượng cao.

6.1. Mẫu Thiết Kế Trong Kiến Trúc Microservices Thách Thức và Giải Pháp

Microservices là một kiến trúc phần mềm phân tách ứng dụng thành các dịch vụ nhỏ, độc lập, giao tiếp với nhau thông qua các API. Kiến trúc Microservices mang lại nhiều lợi ích, chẳng hạn như tăng tính linh hoạt, khả năng mở rộng và khả năng phục hồi. Tuy nhiên, nó cũng đặt ra nhiều thách thức mới trong việc thiết kế và quản lý các dịch vụ. Các mẫu thiết kế như Circuit Breaker, API Gateway và CQRS (Command Query Responsibility Segregation) đang được sử dụng để giải quyết các thách thức này.

6.2. Vai Trò Của AI và Machine Learning trong Việc Phát Triển Mẫu Thiết Kế Mới

Trí tuệ nhân tạo (AI) và học máy (Machine Learning) đang ngày càng được sử dụng rộng rãi trong phát triển phần mềm. AI và Machine Learning có thể được sử dụng để tự động hóa các tác vụ lặp đi lặp lại, phát hiện các vấn đề tiềm ẩn và đưa ra các đề xuất thiết kế tốt hơn. Điều này có thể dẫn đến việc phát triển các mẫu thiết kế mới, giúp các nhà phát triển xây dựng các hệ thống phần mềm thông minh hơn và hiệu quả hơn. Ví dụ, AI có thể được sử dụng để phân tích mã nguồn và đề xuất các refactoring để loại bỏ code smell.

Trích đoạn nội dung tài liệu

MỞ ĐẦU Một trong những tiêu chuẩn quan trọng để đánh giá chất lƣợng phần mềm là khả năng tái sử dụng. Thực tế cho thấy mỗi dự án phần mềm là một thực thể phức tạp và duy nhất. Nhƣng giữa các thực thể đó ta vẫn tìm thấy sự lặp lại ở một hoặc nhiều điểm. Qua quá trình nghiên cứu, hƣớng giải quyết cho các vấn đề mang tính chất lặp đi lặp lại khi phát triển các hệ thống phần mềm đã đƣợc các chuyên gia đúc kết và nâng lên mức tổng quát.

Từ đó hình thành khái niệm mẫu thiết kế. Năm 1995, Erich Gamma và các cộng sự của ông đã công bố cuốn sách “Elements of reusable Object Oriented Software” và đã đánh dấu sự ra đời của thiết kế mẫu. Đây là bƣớc tiến vô cùng quan trọng đối với việc thiết kế phần mềm hƣớng đối tƣợng. Hiện nay, nhiều hệ thống phần mềm đƣợc thiết kế theo cách tiếp cận hƣớng đối tƣợng và áp dụng mô hình mẫu thiết kế (Design Pattern).

Mẫu thiết kế giúp ta giải quyết bài toán nhanh gọn, có khả năng tái sử dụng mà không cần phải thiết kế lại. Mẫu thiết kế dựa trên nguyên lý thiết kế hƣớng đối tƣợng và nó đƣợc xem nhƣ là công cụ để phát hiện và mô tả bài toán ở mức trừu tƣợng cao mà vẫn bao hàm đầy đủ ngữ nghĩa của bài toán ứng dụng. Erich Gamma và các cộng sự đã đƣa ra 23 mẫu thiết kế nổi tiếng (các mẫu GOF – Gang of Four). Các mẫu thiết kế đó đã đƣợc áp dụng rất thành công trong thiết kế các phần mềm hƣớng đối tƣợng.

Tuy nhiên với sự phát triển nhanh chóng của công nghiệp phần mềm và phƣơng pháp thiết kế hƣớng đối tƣợng, đã nảy sinh rất nhiều tình huống đòi hỏi và phát sinh những mẫu thiết kế mới cho phù hợp. Cho đến nay đã có rất nhiều các mẫu thiết kế đã đƣợc đƣa ra dựa trên việc cải biến các mẫu trên cũng nhƣ các mẫu thiết kế mới. Do đó cần thiết có những nghiên cứu phƣơng pháp luận về mẫu thiết kế. Đồng thời trên cơ sở đó đƣa ra các phƣơng pháp để xây dựng lên các mẫu thiết kế trong những tình huống phát sinh.

Vì vậy tôi đã lựa chọn đề tài “Phát triển mẫu thiết kế phần mềm và ứng dụng” để tìm lời giải đáp cho những vấn đề trên.dung TIEU LUAN MOI download : [e-mail] CHƢƠNG 1. TỔNG QUAN VỀ MẪU THIẾT KẾ PHẦN MỀM 1. Vấn đề trong thiết kế phần mềm hƣớng đối tƣợng Việc thiết kế phần mềm nói chung và phần mềm hƣớng đối nói riêng là một việc khó. Thiết kế phần mềm hƣớng đối tƣợng phải đảm bảo giải quyết đƣợc vấn đề mong muốn, đồng thời phải đảm bảo có thể đƣợc mở rộng trong tƣơng lai mà không hải thiết kế lại.

Tuy nhiên khi thiết kế hƣớng đối tƣợng một phần mềm, không thể đảm bảo rằng thiết kế đó là đúng và đáp ứng đƣợc các yêu cầu trên. Do đó cần đƣa ra một vài phƣơng án để từ đó lựa chọn đƣợc phƣơng án tốt nhất. Phƣơng án này đôi khi đƣợc dùng lại nhiều lần khi gặp các vấn đề tƣơng tự. Ta hay gặp những vấn đề tƣơng tự nhau đƣợc phát triển thành các mẫu thiết kế, để sử dụng cho các hệ thống phần mềm ứng dụng.

Khái niệm Mẫu thiết kế Mẫu đã tồn tại trong một thời gian dài trong quá trình phát triển phần mềm, tuy nhiên chƣa có một định nghĩa hoàn thiện cho nó. Mẫu mô tả vấn đề một cách lặp đi lặp lại và các giải pháp cho vấn đề đó. Nó đƣợc xem nhƣ là một khuôn mẫu đƣợc áp dụng để giải quyết các trƣờng hợp của cùng một loại vấn đề. Mẫu thiết kế đƣợc dùng trong công nghệ phần mềm là các giải pháp cho vấn đề trong thiết kế các hệ thống phần mềm.

Đây là tập các giải pháp đã đƣợc công nhận có giá trị và ngƣời phát triển phần mềm áp dụng để giải quyết các vấn đề tƣơng tự. Cũng nhƣ trong phân tích và thiết kế hƣớng đối tƣợng, việc sử dụng mẫu thiết kế cần phải đạt đƣợc khả năng tái sử dụng các giải pháp chuẩn đối với vấn đề xảy ra thƣờng xuyên. Christopter Alexander đã định nghĩa [1]: “Mỗi mẫu mô tả một vấn đề mang tính chất xuất hiện lặp đi lặp lại trong môi trƣờng của chúng ta, một giải pháp cho vấn đề đó”. Một định nghĩa khác về mẫu của Gamma [1]: “Một mẫu thể hiện bản chất cốt lõi của một giải pháp cho một vấn đề xuất hiện lặp đi lặp lại trong một ngữ cảnh đƣợc chỉ định rõ”.

Mỗi một mẫu mô tả một vấn đề xảy ra lặp đi lặp lại trong môi trƣờng và mô tả cái cốt lõi của giải pháp để cho vấn đề đó. Bằng cách nào đó bạn đã dùng nó cả triệu lần mà không làm giống nhau 2 lần. Nội dung các mẫu thiết kế GOF [6] 1. Nhóm mẫu tạo lập Nhóm gồm có 5 mẫu: AbstractFactory, Abstract Method, Builder, Prototype và Singleton.

Nhóm này liên quan tới việc khởi tạo các thể nghiệm của đối tƣợng, tách biệt với cách đƣợc thực hiện từ ứng dụng. Xem thông tin của các mẫu trong nhóm dựa vào biểu đồ phụ thuộc vào mẫu đó, mẫu thiên về hành vi hay cấu trúc.dung TIEU LUAN MOI download : skknchat@gmail. Abstract Factory Trong các hệ điều hành giao diện đồ hoạ, bộ công cụ cung cấp giao diện ngƣời dùng dựa trên chuẩn xem và cảm nhận (look-and–feel). Có rất nhiều kiểu giao diện xem và cảm nhận và giao diện ngƣời dùng khác nhau thanh cuộn tài liệu (scroll bar), cửa sổ (window), nút bấm (button), hộp soạn thảo (editbox),.

Nếu xem chúng là các đối tƣợng thì chúng có một số thuộc tính và hành vi khá giống nhau về mặt hình thức nhƣng lại khác nhau về cách thực hiện. Chẳng hạn đối tƣợng button, window và editbox có cùng các thuộc tính là chiều dài, rộng, cao, toạ độ,… các phƣơng thức là Resize(), SetPosition(),. Tuy nhiên các đối tƣợng này không thể gộp vào một lớp vì theo nguyên lý xây dựng lớp, các đối tƣợng thuộc cùng 1 lớp phải có các phƣơng thức hoạt động nhƣ nhau, trong khi tuy rằng các đối tƣợng ở đây có cùng giao diện nhƣng cách thực hiện các hành vi lại hoàn toàn khác nhau. Vấn đề đặt ra là xây dựng một lớp tổng quát, chứa những điểm chung của các đối tƣợng để từ đó có thể dễ dàng sử dụng lại.

Ta gọi lớp này là lớp WidgetFactory. Các lớp đối tƣợng window, button và editbox thừa kế lớp này. Trong thiết kế hƣớng đối tƣợng, ta xây dựng mô hình các lớp đó nhƣ sau: Hình 1. Sơ đồ lớp mẫu Abstract Factory Lớp WidgetFactory có 2 phƣơng thức là CreateScrollBar() và CreateWindow().

Đây là lớp trừu tƣợng tổng quát cho MotifWidgetFactory và PMWidgetFactory. Các lớp MotifWidgeFactory và PMWidgetFactory thừa kế lớp WidgetFactory. Các nhóm lớp Window và ScrollBar là các lớp trừu tƣợng. Lớp Window có các lớp con cụ thể là PMWindow và MotifWindow.

Lớp ScrollBar có các lớp con cụ thể là PMScrollBar và MotifScrollBar. Các đối tƣợng thuộc lớp này đƣợc các đối tƣợng thuộc lớp 3 (LUAN.dung TIEU LUAN MOI download : [e-mail] WidgetFactory (MotifWidgetFactory và PMWidgetFactory) gọi trong các hàm khởi tạo đối tƣợng. Đối tƣợng client thông qua lớp giao diện của các đối tƣợng MotifWidgetFactory, PMWidgetFactory, Window và ScrollBar để làm việc với các đối tƣợng PMWindow, MotifWindow, PMScrollBar,MotifScrollBar. Điều này có thể thực hiện đƣợc nhờ cơ chế binding trong các ngôn ngữ hỗ trợ lập trình hƣớng đối tƣợng nhƣ C++, C#, Java, SmallTalk,… Các đối tƣợng PMWindow, MotifWindow, PMScrollBar, MotifScrollBar đƣợc tạo trong thời gian chạy chƣơng trình nên trình ứng dụng (đối tƣợng thuộc lớp client) chỉ cần giữ một con trỏ trỏ đến đối tƣợng thuộc lớp WidgetFactory, và thay đổi địa chỉ con trỏ để có thể làm việc với các đối tƣợng trên.

Các tình huống này thƣờng có cùng một cách giải quyết đã đƣợc chứng tỏ là tối ƣu. Nó đƣợc tổng quát hoá thành một mẫu thiết kế gọi là AbstractFactory. Định nghĩa: mẫu Abstract Factory cung cấp cho trình khách một giao diện cho một tập các đối tƣợng thuộc các lớp khác nhau mà không phải trực tiếp làm việc với từng lớp con cụ thể. Sơ đồ lớp mẫu Abstract Factory  AbstractFactory (ContinentFactory): khai báo một giao diện cho các lớp dẫn xuất cụ thể.dung TIEU LUAN MOI download : [e-mail]  ConcreteFactory (AfricaFactory, AmericaFactory): cài đặt các thao tác để tạo ra các đối tƣợng dẫn xuất chi tiết.

 AbstractProduct (Herbivore, Carnivore): khai báo một giao diện trừu tƣợng cho đối tƣợng dẫn xuất.  Product (Wildebeest, Lion, Bison, Wolf): định nghĩa một đối tƣợng dẫn xuất đƣợc tạo ra bởi một factory cụ thể tƣơng ứng, cài đặt giao diện AbstractProduct.  Client (AnimalWorld): sử dụng giao diện đƣợc khai báo bởi các lớp AbstractFactory và AbstractProduct. Ví dụ sau đây là các lớp trên đƣợc cài đặt trong C++: //Cài đặt cho lớp WidgetFactory: class WidgetFactory{ public: virtual Window* CreateWindow(); virtual ScrollBar* CreateScrollBar(); }; //Cài đặt cho lớp MotifWidgetFactory và PMWidgeFactory: class MotifWidgetFactory:public WidgetFactory{ public: Window* CreateWindow(){ return new MotifWindow(); } ScrollBar* CreateScrollBar(){ return new MotifScrollBar(); } }; class PMWidgetFactory:public WidgetFactory{ public: Window* CreateWindow(){ return new PMWindow(); } ScrollBar* CreateScrollBar(){ return new PMScrollBar(); } }; //Lớp đối tượng Window: class Window{ //định nghĩa các thuộc tính và phương thức.

}; class MotifWindow:public Window{ //định nghĩa các thuộc tính và các phương thức. }; class PMWindow:public Window{ //định nghĩa các thuộc tính và các phương thức.dung TIEU LUAN MOI download : [e-mail] //Các lớp thuộc nhóm ScrollBar. class ScrollBar{ //định nghĩa các thuộc tính và phương thức. }; class MotifScrollBar:public ScrollBar{ //định nghĩa các thuộc tính và phương thức.

}; class PMScrollBar:public ScrollBar{ //định nghĩa các thuộc tính và phương thức. }; //Để truy cập đến các đối tượng này tại chương trình ứng dụng //ta có thể thực hiện như sau: class Client{ private: WidgetFactory* wf; }; Các mẫu liên quan: AbstractFactory thƣờng đƣợc cài đặt cùng với Singleton, FactoryMethod và đôi khi cả Prototype. Các lớp con cụ thể thƣờng đƣợc cài đặt bằng singleton. Bởi singleton có thể tạo ra những đối tƣợng đồng nhất cho dù chúng ta gọi nó ở đâu đó trong chƣơng trình.

Builder Trong những ứng dụng lớn với các chức năng phức tạp và giao diện đồ sộ, việc khởi tạo ứng dụng thƣờng gặp nhiều khó khăn. Chúng ta không nên dồn các việc này cho một hàm khởi tạo, vì nhƣ thế sẽ rất khó kiểm soát và không phải lúc nào các thành phần của ứng dụng cũng đƣợc khởi tạo một cách đồng bộ. Có thành phần đƣợc tạo lúc dịch chƣơng trình nhƣng cũng có thành phần tuỳ theo từng yêu cầu của ngƣời dùng, hoàn cảnh của ứng dụng mà nó sẽ đƣợc tạo ra. Do vậy ngƣời ta giao việc này cho một đối tƣợng chịu trách nhiêm khởi tạo và chia việc khởi tạo ứng dụng một cách riêng rẽ để có thể khởi tạo riêng biệt ở các hoàn cảnh khác nhau.