ĐẠ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
- Xem thêm -