Tài liệu Phát triển mẫu thiết kế phần mềm và ứng dụng

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGHIÊM VĂN TRIỆU PHÁT TRIỂN MẪU THIẾT KẾ PHẦN MỀM VÀ ỨNG DỤNG LUẬN VĂN THẠC SĨ HÀ NỘI - 2010 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGHIÊM VĂN TRIỆU PHÁT TRIỂN MẪU THIẾT KẾ PHẦN MỀM VÀ ỨNG DỤNG Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS ĐOÀN VĂN BAN HÀ NỘI - 2010 MỤC LỤC MỞ ĐẦU ..................................................................................................................... 1 CHƢƠNG 1. TỔNG QUAN VỀ MẪU THIẾT KẾ PHẦN MỀM ................................ 2 1.1. Vấn đề trong thiết kế phần mềm hƣớng đối tƣợng ......................................... 2 1.2. Khái niệm Mẫu thiết kế ................................................................................. 2 1.3. Nội dung các mẫu thiết kế GOF [6] ............................................................... 2 1.3.1. Nhóm mẫu tạo lập .................................................................................. 2 1.3.2. Nhóm Mẫu cấu trúc .............................................................................. 12 1.3.3. Nhóm mẫu hành vi ............................................................................... 25 1.4. Tổng kết chƣơng ......................................................................................... 47 CHƢƠNG 2. CÁC NGUYÊN LÝ THIẾT KẾ MẪU PHẦN MỀM ........................... 49 2.1. Các nguyên lý thiết kế hƣớng đối tƣợng [10] ............................................... 49 2.1.1. Nguyên lý đóng mở .............................................................................. 49 2.1.2. Nguyên lý Nghịch đảo phụ thuộc ......................................................... 52 2.1.3. Nguyên lý Thay thế Liskov .................................................................. 54 2.1.4. Nguyên lý Phân tách giao diện ............................................................. 55 2.2. Các nguyên lý xây dựng mẫu thiết kế phần mềm ......................................... 58 2.2.1. Tình huống phát sinh mẫu thiết kế là từ nguyên lý thiết kế và thực tiễn 58 2.2.2. Mẫu thiết kế là giải pháp cụ thể ............................................................ 58 2.2.3. Mục tiêu thiết kế mẫu là hƣớng tới ngƣời dùng .................................... 59 2.2.4. Các thuật ngữ trong mẫu thiết kế điển hình và gợi vấn đề ..................... 60 2.2.5. Lựa chọn các tình huống áp dụng điển hình .......................................... 60 2.3. Tổng kết chƣơng ......................................................................................... 61 CHƢƠNG 3. PHƢƠNG PHÁP THIẾT KẾ MẪU PHẦN MỀM................................ 62 3.1. Các thành phần cơ bản của mẫu thiết kế ...................................................... 62 3.1.1. Tên khuôn mẫu..................................................................................... 62 3.1.2. Vấn đề .................................................................................................. 62 3.1.3. Giải pháp .............................................................................................. 62 3.1.4. Hệ quả .................................................................................................. 63 3.2. Các định dạng mẫu thiết kế.......................................................................... 63 3.2.1. Định dạng Alexandrian......................................................................... 63 3.2.2. Định dạng GOF .................................................................................... 64 3.2.3. Định dạng Porland ................................................................................ 64 3.2.4. Định dạng Coplien ............................................................................... 65 3.2.5. Định dạng POSA .................................................................................. 65 3.2.6. Định dạng P of EAA ............................................................................ 65 3.3. Định dạng GoF của mẫu thiết kế ................................................................. 65 3.4. Việc lựa chọn định dạng mẫu thiết kế .......................................................... 67 3.5. Tổng kết chƣơng ......................................................................................... 67 CHƢƠNG 4. PHÁT TRIỂN MẪU THIẾT KẾ VÀ ỨNG DỤNG .............................. 69 4.1. Các mẫu thiết kế đối tƣợng .......................................................................... 69 4.1.1. Mẫu đối tƣợng trống............................................................................. 69 4.1.2. Mẫu đối tƣợng vai trò ........................................................................... 74 4.1.3. Mẫu đối tƣợng mở rộng ........................................................................ 83 4.1.4. Mẫu đối tƣợng kiểu .............................................................................. 90 4.2. Mẫu thiết kế Ajax ........................................................................................ 96 4.2.1. Tổng quan về Ajax ............................................................................... 96 4.2.2. AJAX là gì ........................................................................................... 97 4.2.3. AJAX hoạt động nhƣ thế nào ............................................................... 97 4.2.4. Các ứng dụng AJAX phổ biến .............................................................. 99 4.2.5. Tổng quan về mẫu thiết kế Ajax ........................................................... 99 4.3. Ứng dụng mẫu thiết kế trong thiết kế khung cho tầng truy cập dữ liệu ....... 101 4.3.1. Đặt vấn đề .......................................................................................... 101 4.3.2. Mô hình 3 tầng ................................................................................... 101 4.3.3. Cài đặt mô hình khung cho tầng truy cập dữ liệu ................................ 102 4.4. Tổng kết chƣơng ....................................................................................... 106 KẾT LUẬN ............................................................................................................. 107 TÀI LIỆU THAM KHẢO........................................................................................ 108 DANH MỤC HÌNH VẼ Hình 1.1. Sơ đồ lớp mẫu Abstract Factory ................................................................... 3 Hình 1.2. Sơ đồ lớp mẫu Abstract Factory ................................................................... 4 Hình 1.3. Sơ đồ lớp mẫu Builder.................................................................................. 7 Hình 1.4. Sơ đồ lớp mẫu Factory Method .................................................................... 9 Hình 1.5. Sơ đồ lớp mẫu Prototype ............................................................................ 10 Hình 1.6. Sơ đồ lớp mẫu Singleton ............................................................................ 12 Hình 1.7. Sơ đồ lớp mẫu Adapter ............................................................................... 13 Hình 1.8. Sơ đồ lớp mẫu Bridge ................................................................................. 14 Hình 1.9. Sơ đồ lớp minh họa .................................................................................... 16 Hình 1.10. Sơ đồ phân cấp ......................................................................................... 16 Hình 1.11. Sơ đồ lớp mẫu Composite ........................................................................ 17 Hình 1.12. Sơ đồ lớp mẫu Decorator .......................................................................... 19 Hình 1.12. Sơ đồ minh họa ........................................................................................ 20 Hình 1.13. Sơ đồ lớp mẫu Facade .............................................................................. 20 Hình 1.14. Sơ đồ lớp mẫu Flyweight.......................................................................... 22 Hình 1.15. Sơ đồ lớp mẫu Proxy ................................................................................ 24 Hình 1.16. Sơ đồ tƣơng tác ........................................................................................ 26 Hình 1.17. Biểu đồ cộng tác ....................................................................................... 26 Hình 1.18. Mô hình lớp.............................................................................................. 27 Hình 1.19. Sơ đồ lớp mẫu Chain of Responsibility .................................................... 27 Hình 1.20. Mô hình tƣơng tác .................................................................................... 29 Hình 1.21. Sơ đồ lớp mẫu Command ......................................................................... 29 Hình 1.22. Mô hình cấu trúc ...................................................................................... 31 Hình 1.22. Mô hình cây phân cấp .............................................................................. 32 Hình 1.23. Sơ đồ lớp mẫu Interperter ......................................................................... 33 Hình 1.24. Mô hình tƣơng tác .................................................................................... 35 Hình 1.25. Sơ đồ lớp mẫu Iterator .............................................................................. 35 Hình 1.26. Hộp thoại biểu diễn các widget ................................................................. 37 Hình 1.27. Biều đồ đối tƣợng ..................................................................................... 38 Hình 1.28. Biều đồ diễn tiến ...................................................................................... 38 Hình 1.29. Biều đồ lớp ............................................................................................... 39 Hình 1.30. Sơ đồ lớp mẫu Mediator ........................................................................... 39 Hình 1.31. Sơ đồ lớp mẫu Memento .......................................................................... 41 Hình 1.32. Sơ đồ lớp mẫu Observer ........................................................................... 42 Hình 1.33. Sơ đồ lớp mẫu State ................................................................................. 43 Hình 1.34. Sơ đồ lớp mẫu Strategy ............................................................................ 44 Hình 1.35. Sơ đồ lớp mẫu Template Method .............................................................. 45 Hình 1.36. Sơ đồ lớp mẫu Visitor .............................................................................. 46 Hình 2.1. Mô hình thừa kế lớp ................................................................................... 56 Hình 2.2. Mô hình thừa kế lớp cải tiến ....................................................................... 57 Hình 4.1. Sơ đồ lớp mẫu Null Object ......................................................................... 70 Hình 4.2. Sơ đồ lớp nghiệp vụ ngân hàng .................................................................. 75 Hình 4.3. Sơ đồ phân lớp ........................................................................................... 76 Hình 4.4. Sơ đồ lớp mẫu Role Object......................................................................... 77 Hình 4.5. Sơ đồ lớp mẫu Role Object đệ quy ............................................................. 81 Hình 4.6. Sơ đồ tƣơng tác giữa các vai trò và lõi ........................................................ 81 Hình 4.7. Sơ đồ lớp minh họa .................................................................................... 85 Hình 4.8. Sơ đồ lớp mẫu Extension Object ................................................................ 86 Hình 4.9. Sơ đồ lớp mẫu Extension Object rút gọn .................................................... 88 Hình 4.10. Sơ đồ lớp Movie, Videotape ..................................................................... 91 Hình 4.11. Sơ đồ lớp, đối tƣợng ................................................................................. 91 Hình 4.12. Sơ đồ lớp mẫu Type Object ...................................................................... 92 Hình 4.13. Sơ đồ lớp, đối tƣợng mẫu Type Object ..................................................... 93 Hình 4.14. Ứng dụng web truyền thống (trái) và ứng dụng AJAX ............................. 98 Hình 4.15. Tƣơng tác đồng bộ trong ứng dụng web truyền thống (trên) và dị bộ trong ứng dụng AJAX. ........................................................................................................ 98 Hình 4.16. Nhóm các mẫu AJAX. ............................................................................ 100 Hình 4.17. Mô hình ứng dụng 3-tầng ....................................................................... 101 Hình 4.18. Biểu đồ lớp của tầng truy cập dữ liệu ..................................................... 103 HỆ THỐNG CÁC TỪ VIẾT TẮT Kí hiệu viết tắt Tên tiếng Anh GoF Gang of Four OMT Object Modeling Technique AJAX Asynchronous Ý nghĩa Kỹ thuật mô hình hóa đối tƣợng JavaScript JavaScript và XML không đồng and XML bộ UI User Interface Giao diện ngƣời dùng PL Presentation Layer Tầng trình diễn BL Business Layer Tầng nghiệp vụ DL Data Layer Tầng dữ 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. 1 CHƢƠNG 1. TỔNG QUAN VỀ MẪU THIẾT KẾ PHẦN MỀM 1.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. 1.2. 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. 1.3. Nội dung các mẫu thiết kế GOF [6] 1.3.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. 2 1.3.1.1. 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.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 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ể. Hình 1.2. 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ể. 4  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. }; 5 //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. 1.3.1.2. 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. Tƣởng tƣợng việc tạo ra đối tƣợng giống nhƣ tạo ra chiếc xe đạp: đầu tiên tạo ra khung xe, sau đó tạo ra bánh xe, buđông xe, xích, líp,… Việc tạo ra các bộ phận này không nhất thiết phải đựơc thực hiện một cách đồng thời hay theo một trật tự nào cả, và cũng có thể đƣợc tạo ra một cách độc lập bởi nhiều ngƣời. Nhƣng trong một mô hình sản xuất nhƣ vậy, bao giờ việc tạo ra chiếc xe cũng đƣợc khép kín để tạo ra chiếc xe hoàn chỉnh, đó là nhà máy sản xuất xe đạp. Ta gọi đối tƣợng nhà máy sản xuất xe đạp này là builder (ngƣời xây dựng). Định nghĩa: Builder là mẫu thiết kế chia một công việc khởi tạo phức tạp của một đối tƣợng thành các công việc riêng rẽ, từ đó có thể tiến hành khởi tạo đối tƣợng ở các ngữ cảnh khác nhau. 6 Hình 1.3. Sơ đồ lớp mẫu Builder  Builder (VehicleBuilder): giao diện trừu tƣợng cho việc tạo ra các phần của một đối tƣợng Product.  ConcreteBuilder (MotorCycleBuilder, CarBuilder, ScooterBuilder)  Xây dựng và lắp ráp các phần của dẫn xuất bằng việc cài đặt bổ sung giao diện Builder.  Định nghĩa và giữ liên kết đến đại diện mà nó tạo ra.  Cung cấp một giao diện cho việc gọi dẫn xuất.  Director (Shop): xây dựng đối tƣợng sử dụng giao diện Builder.  Product (Vehicle):  Biểu diễn các đối tƣợng phức tạp. ConcreteBuilder dựng nên các đại diện bên trong của dẫn xuất và định nghĩa quá trình xử lý bằng các thành phần lắp ráp của nó.  Gộp các lớp định nghĩa các bộ phận cấu thành, bao gồm các giao diện cho việc lắp ráp các bộ phận trong kết quả cuối cùng. Builder thƣờng đƣợc cài đặt cùng với các mẫu nhƣ Abstract Factory. Abstract Factory tạo ra một dòng các đối tƣợng dẫn xuất (cả đơn giản và phức tạp). Ngoài ra Builder còn thƣờng đƣợc cài đặt kèm với Composite pattern. Composite pattern thƣờng là những gì mà Builder tạo ra. 1.3.1.3. Factory Method Các Framework thƣờng sử dụng các lớp trừu tƣợng để định nghĩa và duy trì mối quan hệ giữa các đối tƣợng. Một framework thƣờng đảm nhiệm việc tạo ra các đối tƣợng hoàn chỉnh. Việc xây dựng một framework cho ứng dụng có thể đại diện cho nhiều đối tƣợng tài liệu cho ngƣời dùng. Có 2 loại lớp trừu tƣợng chủ chốt trong 7 framework này là lớp ứng dụng và tài liệu. Cả 2 đều là lớp trừu tƣợng, và trình ứng dụng phải xây dựng các dẫn xuất để tạo ra đối tƣợng phù hợp. Chẳng hạn để tạo ra một ứng dụng drawing, ta định nghĩa một lớp DrawingApplication và một lớp DrawingDocument. Lớp ứng dụng chịu trách nhiệm quản lý tài liệu và ta sẽ tạo ra chúng khi có nhu cầu ( chẳng hạn khi ngƣời dùng chọn Open hoặc New từ menu). Lớp Document đƣợc tạo ra từ các dẫn xuất của lớp AbstractDocument (trong framework) để đƣa ra các thể nghiệm cho một ứng dụng Drawing, lớp ứng dụng không thể biết trƣớc đƣợc lớp dẫn xuất của AbstractDocument nào sẽ đƣợc tạo ra để trình bày, mà nó chỉ biết khi nào một đối tƣợng tài liệu nào đƣợc tạo. Điều này tạo ra một sự tiến thoái lƣỡng nan: framework phải thể nghiệm một lớp, nhƣng nó chỉ biết về lớp trừu tƣợng của nó, mà lớp trừu tƣợng này lại không thể tạo ra thể nghiệm. Nếu làm việc với giao diện ứng dụng đơn tài liệu và đa tài liệu trong ngôn ngữ Visual C++, chúng ta sẽ gặp một vấn đề tƣơng tự. Đối tƣợng MainFrame có thể tạo ra một dối tƣợng view mỗi khi ngƣời dùng nhấn chuột vào menu View hay Open, nhƣng MainFrame hoàn toàn không biết về View vì nó không chứa bất cứ một thể nghiệm nào của View. Mẫu Abstract Method đƣa ra giải pháp cho vấn đề này. Nó đóng gói thông tin về lớp dẫn xuất Document nào đƣợc tạo ra và đƣa ra ngoài framework. Lớp dẫn xuất định nghĩa lại một phƣơng thức trừu tƣợng CreateDocument() trên lớp Application để trả về một đối tƣợng thuộc lớp dẫn xuất của lớp Document. Class Application{ //Các khai báo khác public: Document* CreateDocument(); //Các khai báo khác }; Document* Application::CreateDocument(){ Document* newDocument = new MyDocument(); Return newDocument; } Khi một đối tƣợng thuộc lớp dẫn xuất của Application đƣợc tạo ra, nó có thể tạo ra các đối tƣợng tài liệu mà không cần biết về các lớp đó. Chúng ta gọi CreateDocument là một Factory Method bởi vì nhiệm vụ của nó là sản xuất ra các đối tƣợng. Định nghĩa: Factory Method là một giao diện cho việc tạo ra một đối tƣợng, nhƣng để cho lớp dẫn xuất quyết định lớp nào sẽ đƣợc tạo. Factory Method để cho một lớp trì hoãn sự thể nghiệm một lớp con. 8 Hình 1.4. Sơ đồ lớp mẫu Factory Method  Product (Page): định nghĩa giao diện của các đối tƣợng mà Factory Method tạo ra.  ConcreteProduct (SkillsPage, EducationPage, ExperiencePage): cài đặt giao diện Product.  Creator (Document):   Khai báo Factory Method trả về một đối tƣợng Product. Sự kiến tạo này cũng có thể định nghĩa một cài đặt mặc định của Factory Method trả về một đối tƣợng ConcreteProduct mặc định.  Có thể gọi Factory Method để tạo ra một đối tƣợng Product. ConcreteCreator (Report, Resume): chồng lên Factory Method để trả về một thể nghiệm của một ConcreteProduct. Abstract Factory thƣờng đƣợc cài đặt cùng với Factory Method. Lớp Factory Method thƣờng đƣợc gọi là Template Method. Trong ví dụ về ứng dụng Drawing trên, NewDocument là một template method. Prototype không cần đến một lớp con Creator, tuy nhiên thƣờng đòi hỏi một phƣơng thức để tạo thể nghiệm trên lớp dẫn xuất. 1.3.1.4. Prototype Prototype Pattern giúp cho việc khởi tạo đối tƣợng bằng một đối tƣợng nguyên mẫu (prototype), là copy của object “mẫu” đó. Ý tƣởng của mẫu là chúng ta đƣợc cung cấp một đối tƣợng và sẽ dùng đối tƣợng này nhƣ là một hình mẫu (template) khi cần tạo lập một đối tƣợng mới. Việc tạo lập đối tƣợng mới sẽ dựa trên đối tƣợng mẫu không sử dụng toán tử new hoặc constructor,… đƣợc cụng cấp bởi ngôn ngữ lập trình. Lý do là chúng ta không biết đƣợc thông tin chi tiết bên trong đối tƣợng và đối tƣợng có thể che dấu và chỉ cung cấp ra bên ngoài một lƣợng thông tin giới hạn. Do vậy ta không thể dùng toán tử new và sao chép những dữ liệu đƣợc đối tƣợng cung cấp (vốn 9 không đầy đủ) cho một đối tƣợng mới. Cách tốt nhất là để cho chính đối tƣợng “mẫu” tự xác định thông tin và dữ liệu sao chép. Định nghĩa: Prototype là mẫu thiết kế chỉ định ra một đối tƣợng đặc biệt để khởi tạo, nó sử dụng một thể nghiệm sơ khai rồi sau đó sao chép ra các đối tƣợng khác từ mẫu đối tƣợng này. Hình 1.5. Sơ đồ lớp mẫu Prototype  Prototype: khai báo giao diện cho dòng vô tính của chính nó.  ConcretePrototype: cài đặt một thao tác cho dòng vô tính của nó.  Client: tạo ra một đối tƣợng mới bằng việc yêu cầu một nguyên mẫu từ dòng vô tính của nó Prototype và Abstract Factory liên quan đến nhau chặt chẽ, có thể đối chọi nhau theo nhiều kiểu. Tuy nhiên chúng có thể kết hợp cùng nhau. Một Abstract Factory có thể chứa một tập các Prototype vô tính và trả về các đối tƣợng sản xuất. 1.3.1.5. Singleton Xét về một đối tƣợng quản lý tài nguyên trong các ứng dụng. Mỗi ứng dụng có một bộ quản lý tài nguyên, nó cung cấp các điểm truy cập cho các đối tƣợng khác trong ứng dụng. Các đối tƣợng (khách) có thể lấy ra từ bộ quản lý tài nguyên những gì chúng cần và thay đổi giá trị bên trong bộ quản lý tài nguyên đó. Để truy cập vào bộ quản lý tài nguyên, đối tƣợng khách cần phải có một thể nghiệm của bộ quản lý tài nguyên. Nhƣ vậy trong một ứng dụng sẽ có nhiều thể nghiệm của bộ quản lý tài nguyên đƣợc tạo ra. class ResourceManager{ 10 private: int x; public: ResourceManager(){x =0;....} void SetX(int _x){ x = _x;} void GetX(){ return x;} } class Client1 { public: void DoSomething(){ ResourceManager rm; printf(“x = %d”,rm.GetX()); x = 100; } } class Client2{ public: void DoSomething(){ ResourceManager rm; printf(“x = %d”,rm.GetX()); x = 500; } } Trong ví dụ trên, hàm DoSomething() của Client1 khi truy cập vào đối tƣợng thuộc lớp ResourceManager sẽ in ra màn hình x = 0 và đặt vào đó x = 100. Sau đó hàm DoSomething() của Client2 khi truy cập vào đối tƣợng thuộc lớp ResourceManager sẽ in ra màn hình x = 0 và đặt vào đó x = 500. Rõ ràng là tài nguyên mà các đối tƣợng khách truy cập vào không thể hiện sự thống nhất. Điều mà lẽ ra khi giá trị x trong ResourceManager bị Client1 thay đổi thì Client2 phải nhận biết và in ra màn hình x =100. Nhƣng theo logic cài đặt ở trên thì khi đối tƣợng thuộc lớp Client1 truy cập đến ResourceManager tạo ra một instance và đặt thuộc tính x = 100. Đối tƣợng Client2 truy cập đến ResourceManager tạo ra một instance và đặt thuộc tính x = 500. Hai instance này độc lập nhau về vùng nhớ, do đó tài nguyên x mà chúng quản lý cũng là 2 tài nguyên độc lập với nhau. Vấn đề đặt ra là phải tạo ra một bộ quản lý tài nguyên tạo ra mọi thể nghiệm giống nhau tại nhiều nơi và ở các thời điểm khác nhau. Singleton cung cấp cho ta cách giải quyết vấn đề này. Định nghĩa: Singleton là mẫu thiết kế nhằm đảm bảo chỉ có duy nhất một thể nghiệm và cung cấp điểm truy cập của nó một cách thống nhất toàn cục. 11 Hình 1.6. Sơ đồ lớp mẫu Singleton Singleton (LoadBalancer)  Định nghĩa một thao tác tạo thể nghiệm cho phép đối tƣợng khách truy nhập đến thể nghiệm đồng nhất của nó nhƣ một thao tác của lớp.  Chịu trách nhiệm về việc tạo ra và duy trì thể nghiệm đồng nhất của chính nó. Có rất nhiều mẫu có thể cài đặt bổ sung từ việc sử dụng Singleton, chẳng hạn nhƣ Abstract Factory, Builder, và Prototype. 1.3.2. Nhóm Mẫu cấu trúc Nhóm gồm có 7 mẫu: Adapter, Bridge, Composite, Decorator, Facade, Proxy và Flyweight. Nhóm này liên quan tới các quan hệ cấu trúc giữa các thể nghiệm, sử dụng thừa kế, kết tập và tƣơng tác. Để xem thông tin về mẫu này phải dựa vào biểu đồ lớp của mẫu. 1.3.2.1. Adapter Đôi khi một lớp công cụ đƣợc thiết kế cho việc sử dụng lại, lại không thể sử dụng lại chỉ bởi giao diện không thích hợp với miền giao diện đặc biệt mà một ứng dụng yêu cầu. Adapter đƣa ra một giải pháp cho vấn đề này. Trong một trƣờng hợp khác ta muốn sử dụng một lớp đã tồn tại và giao diện của nó không phù hợp với giao diện của một lớp mà ta yêu cầu.Ta muốn tạo ra một lớp có khả năng đƣợc dùng lại, lớp đó cho phép kết hợp với các lớp không liên quan hoặc không đƣợc dự đoán trƣớc, các lớp đó không nhất thiết phải có giao diện tƣơng thích với nhau. Định nghĩa: Adapter là mẫu thiết kế dùng để biến đổi giao diện của một lớp thành một giao diện khác mà clients yêu cầu. Adapter ngăn cản các lớp làm việc cùng nhau đó không thể làm bằng cách nào khác bởi giao diện không tƣơng thích. 12 Hình 1.7. Sơ đồ lớp mẫu Adapter  Target: định nghĩa một miền giao diện đặc biệt mà Client sử dụng.  Client: cộng tác với các đối tƣợng tƣơng thích với giao diện Target.  Adapter: định nghĩa một giao diện đã tồn tại mà cần phải làm biến đổi cho thích hợp.  Adapter: làm tƣơng thích giao diện của Adaptee với giao diện của Target. Bridge có một cấu trúc tƣơng tự nhƣ một đối tƣợng của Adapter, nhƣng Bridge có một mục đích khác.Nó chia giao diện từ các phần cài đặt của nó ra riêng rẽ để từ đó có thể linh hoạt hơn và độc lập nhau. Sử dụng một Adapter đồng nghĩa với việc thay đổi giao diện của một đối tƣợng đã tồn tại. Decorator nâng cấp một đối tƣợng khác mà không làm thay đổi giao diện của nó. Một Decorator do đó mà trong suốt với ứng dụng hơn là một Adapter. Nhƣ một hệ quả Decorator hỗ trợ cơ chế kết tập đệ quy mà điều này không thể thực hiện đƣợc đối với các Adapter thuần tuý. Proxy định nghĩa một đại diện cho một đối tƣợng khác và không làm thay đổi giao diện của nó. 1.3.2.2. Bridge Khi một lớp trừu tƣợng (abstraction) có thể có một vài thành phần bổ sung thêm thì cách thông thƣờng phù hợp với chúng là sử dụng kế thừa. Một lớp trừu tƣợng định nghĩa một giao diện cho trừu tƣợng đó, và các lớp con cụ thể thực hiện nó theo các cách khác nhau. Nhƣng cách tiếp cận này không đủ mềm dẻo. Sự kế thừa ràng buộc một thành phần bổ sung thêm là cố định cho abstraction, điều này làm nó khó thay đổi, 13