Vận dụng các mẫu thiết kế để giải quyết bài toán quản lý theo công nghệ hướng đối tượng : Luận văn ThS. Công nghệ thông tin: 1.01.10

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Nguyễn Đức Toàn

VẬN DỤNG CÁC MẪU THIẾT KẾ ĐỂ GIẢI
QUYẾT BÀI TOÁN QUẢN LÝ THEO CÔNG
NGHỆ HƯỚNG ĐỐI TƯỢNG

LUẬN VĂN THẠC SỸ

Hà nội, 11/2006


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Nguyễn Đức Toàn

VẬN DỤNG CÁC MẪU THIẾT KẾ ĐỂ GIẢI
QUYẾT BÀI TOÁN QUẢN LÝ THEO CÔNG
NGHỆ HƯỚNG ĐỐI TƯỢNG
Ngành: Công nghệ thông tin
Mã số: 1.01.10

LUẬN VĂN THẠC SỸ

Người hướng dẫn khoa học :
PGS. TS Nguyễn Văn Vỵ

Hà nội, 11/2006

Hanoi, November 2006


CÁC THUẬT NGỮ VIẾT TẮT
Design pettern
GOF(gang of five)
Creational patterns
Structual patterns
Behavioral pattern
Framework
IDOMS
Abstract factory pattern
Factory pattern
Base- object
Base- class
Singleton pattern
Proxy pattern
Proxy class
Remote Proxy
Virtual Proxy
Monitor Proxy
Protection proxy
Cache proxy
Firewall proxy
Smart reference proxy
Synchoronization Proxy
Copy_ on_write proxy.
Adapter pattern

Mẫu thiết kế

Nhóm 5 thành viên
Các mẫu tạo sinh
Các mẫu cấu trúc
Các mẫu hành vi
Khung làm việc
Thành ngữ
Mẫu chế tạo trừu tượng
Mẫu chế tạo
Đối tượng cơ sở
Lớp cơ sở
Mẫu đơn chiếc
Mẫu uỷ nhiệm
Lớp uỷ nhiệm
Uỷ nhiệm từ xa
Uỷ nhiệm ảo
Uỷ nhiệm màn hình
Chống uỷ nhiệm
Không gian lưu trữ tạm thời
Uỷ nhiệm bảo vệ
Kiểm soát các đối tượng bổ sung
Uỷ nhiệm đồng bộ
Cho phép ghi vaò đĩa mọi lúc
Mẫu thích nghi


MỤC LỤC
CHƢƠNG I ......................................................................................................... 6
MẪU THIẾT KẾ ................................................................................................ 6
1.1. Mẫu thiết kế là gì? .............................................................................................. 6
1.2. Lịch sử các mẫu .................................................................................................. 7

1.3. Các thành phần của mẫu thiết kế ...................................................................... 8
1.3.1. Tên mẫu ........................................................................................................ 8
1.3.2. Vấn đề ........................................................................................................... 9
1.3.3. Giải pháp ....................................................................................................... 9
1.3.4. Hệ quả ........................................................................................................... 9
1.4. Mô tả mẫu thiết kế .............................................................................................. 9
1.4.1. Tên gọi và phân loại ...................................................................................... 9
1.4.2. Mục đích ..................................................................................................... 10
1.4.3. Các tên gọi khác .......................................................................................... 10
1.4.4. Lý do sử dụng ............................................................................................. 10
1.4.5. Khả năng áp dụng ....................................................................................... 10
1.4.6. Cấu Trúc ...................................................................................................... 10
1.4.7. Kết Quả ....................................................................................................... 10
1.4.8.Triển Khai .................................................................................................... 11
1.5. Vai trò của mẫu trong phát triển phần mềm ................................................... 11
1.6. Mẫu thiết kế và kỹ nghệ phần mềm ................................................................. 12
1.6.1. Những mẫu thiết kế trong vòng đời phát triển phần mềm .......................... 12
1.6.2. Vòng đời mẫu.............................................................................................. 13
1.7. Đặc điểm chung của mẫu ................................................................................. 14

CHƢƠNG 2 ...................................................................................................... 15
CÁC LOẠI MẪU THIẾT KẾ ......................................................................... 15


Luận văn thạc sỹ

Nguyễn Đức Toàn

2.1. Phân loại mẫu ................................................................................................... 15
2.2. Mẫu thiết kế với từng bài toán ......................................................................... 15

2.3. Mẫu chế tạo (Factory Pattern) ......................................................................... 16
2.3.1. Định nghĩa ................................................................................................... 16
2.3.2. Đặc điểm ..................................................................................................... 17
2.3.3. Phân loại ...................................................................................................... 17
2.3.4. Một biểu đồ lớp bằng UML của mẫu chế tạo ............................................. 18
2.4. Mẫu chế tạo trừu tượng (Abstract Factory Pattern) ....................................... 18
2.4.1. Định nghĩa ................................................................................................... 18
2.4.2. Thiết kế động với mẫu chế tạo trừu tượng .................................................. 18
2.4.3. Biểu đồ lớp bằng UML của mẫu ................................................................. 19
2.5. Mẫu đơn chiếc (Singleton Pattern) .................................................................. 19
2.5.1. Định nghĩa ................................................................................................... 20
2.5.2. Lợi ích ......................................................................................................... 20
2.5.3. Trường hợp sử dụng .................................................................................... 20
2.5.4. Cách thực hiện ............................................................................................ 21
2.5.5. Ứng dụng của mẫu đơn chiếc ..................................................................... 21
2.5.6. Nhận xét ...................................................................................................... 22
2.6. Mẫu uỷ nhiệm (Proxy Pattern) ......................................................................... 22
2.6.1. Định nghĩa ................................................................................................... 22
2.6.2. Phân loại ...................................................................................................... 22
2.6.3. Đặc điểm chung .......................................................................................... 24
2.6.4 Biểu đồ lớp bằng UML của mẫu .................................................................. 24
2.7. Mẫu thích nghi (Adapter Pattern) .................................................................... 24
2.7.1. Định nghĩa ................................................................................................... 24
2.7.2. Đặc điểm ..................................................................................................... 25
2.7.3. Phạm vi ứng dụng ....................................................................................... 25
2


Luận văn thạc sỹ

Nguyễn Đức Toàn

2.7.4 Biểu đồ lớp bằng UML của mẫu .................................................................. 25
2.8. Sơ đồ mối liên kết các mẫu thiết kế .................................................................. 26

CHƢƠNG 3 ...................................................................................................... 27
ỨNG DỤNG MẪU ........................................................................................... 27
Phân tích, thiết kế hệ thống “ Quản lý khám chữa bệnh “ .......................... 27
3.1 Mô tả bài toán .................................................................................................... 27
3.1.1 Bài toán ........................................................................................................ 27
3.1.2 Các vấn đề cần giải quyết ............................................................................ 27
3.2 Phát triển hệ thống ............................................................................................ 28
3.2.1 Các chức năng của hệ thống ........................................................................ 28
3.2.2 Các khái niệm và mô hình lĩnh vực ............................................................. 29
3.3 Xác định các tác nhân, các ca sử dụng và mô tả các ca sử dụng .................... 35
3.3.1 Xác định các tác nhân .................................................................................. 35
3.3.2 Xác định các ca sử dụng .............................................................................. 39
3.3.3 Mô hình ca sử dụng...................................................................................... 44
3.3.4 Mô tả chi tiết ca sử dụng .............................................................................. 48
3.4 Phân tích hệ thống ............................................................................................. 59
3.4.1 Ca sử dụng cập nhật thông tin phòng khám (Clinic) ................................... 59
3.4.2 Ca sử dụng cập nhật thông tin loại phòng khám (Provider Type) ............... 61
3.4.3 Ca sử dụng cập nhật loại quyền sử dụng (BenefitScheme) ......................... 63
3.4.4 Ca sử dụng cập nhật thanh toán theo đợt tới từng công ty (Invoice). .......... 67
3.4.5 Ca sử dụng cập nhật thông tin khám (EmpVisit) ......................................... 70
3.5 Biểu đồ lớp .......................................................................................................... 73
3.5.1 Áp dụng mẫu Uỷ nhiệm (Proxy) .................................................................. 73
3.5.2 Áp dụng mẫu tạo (Factory) .......................................................................... 74
3.5.3 Áp dụng mẫu đơn chiếc (Singleton) ............................................................ 75
3.5.4 Biểu đồ lớp khi chưa áp dụng mẫu ................................................................ 77

3


Luận văn thạc sỹ

Nguyễn Đức Toàn

3.5.5 Biểu đồ lớp sau khi áp dụng mẫu................................................................... 78
3.6 Mô tả chi tiết các đối tượng ............................................................................... 79
3.6.1 ClinicVO ...................................................................................................... 79
3.6.2 ClinicRdb ..................................................................................................... 79
3.6.3 ProviderTypeVO .......................................................................................... 79
3.6.4 ProviderTypeRdb ......................................................................................... 80
3.6.5 DiagnosisVO ................................................................................................ 80
3.6.6 DiagnosisRdb ............................................................................................... 80
3.6.7 DrugVO ........................................................................................................ 80
3.6.8 DrugRdb ....................................................................................................... 81
3.6.9 LabVO .......................................................................................................... 81
3.6.10 LabRdb ....................................................................................................... 81
3.6.11 XRayVO .................................................................................................... 82
3.6.12 XRayRdb .................................................................................................... 82
3.6.13 GroupVO .................................................................................................... 82
3.6.14 GroupRdb ................................................................................................... 83
3.6.15 UserVO ...................................................................................................... 83
3.6.16 UserRdb ..................................................................................................... 83
3.6.17 UserRoleTypeVO ...................................................................................... 84
3.6.18 UserRoleTypeRdb...................................................................................... 84
3.6.19 UserRoleVO ............................................................................................... 84
3.6.20 UserRoleRdb .............................................................................................. 84
3.6.21 CompanyVO .............................................................................................. 85

3.6.22 CompanyRdb ............................................................................................. 85
3.6.23 BenefitSchemeVO ..................................................................................... 85
3.6.24 BenefitSchemeRdb .................................................................................... 86
3.6.25 BSInPanelVO ............................................................................................. 86
4


Luận văn thạc sỹ

Nguyễn Đức Toàn

3.6.26 BSInPanelRdb ............................................................................................ 87
3.6.27 VisitDisplayVO.......................................................................................... 87
3.6.28 VisitDisplayRdb ......................................................................................... 87
3.6.29 BatchVO .................................................................................................... 88
3.6.30 BatchRdb .................................................................................................... 88
3.6.31 InvoiceVO .................................................................................................. 88
3.6.32 InvoiceRdb ................................................................................................. 89
3.6.33 PaymentAdviceVO .................................................................................... 89
3.6.34 PaymentAdviceRdb ................................................................................... 89
3.6.35 EmployeeVO.............................................................................................. 89
3.6.36 EmployeeRdb ............................................................................................. 90
3.6.37 DependantVO ............................................................................................ 90
3.6.38 DependantRdb............................................................................................ 91
3.6.39 EmpVisitVO .............................................................................................. 91
3.6.40 EmpVisitRdb.............................................................................................. 92
3.6.41 DrugVisitVO .............................................................................................. 92
3.6.42 DrugVisitRdb ............................................................................................. 92
3.6.43 LabVisitVO ................................................................................................ 93
3.6.44 LabVisitRdb ............................................................................................... 93

3.6.45 XRayVisitVO ............................................................................................. 93
3.6.46 XRayVisitRdb ............................................................................................ 93
3.7 Cấu hình phần cứng .......................................................................................... 94
3.8 Thiết kế giao diện ............................................................................................... 95

KẾT LUẬN ....................................................................................................... 98

5


Luận văn thạc sỹ

Nguyễn Đức Toàn

CHƢƠNG I
MẪU THIẾT KẾ
1.1. Mẫu thiết kế là gì?
Nhìn chung, một mẫu là mô tả các vấn đề thường xuyên xuất hiện trong thiết kế, triển
khai phần mềm và các giải pháp cho nó theo cách có thể sử dụng lại được. Những mẫu
thiết kế có ý nghĩa thực tế tốt, chúng là phương tiện thiết kế để làm tài liệu và để truyền
đạt kiến thức, những kinh nghiệm của các chuyên gia cho những người mới học.
Mẫu còn mô tả một giải pháp chung đối với một vấn đề nào đó trong thiết kế thường
được “lặp lại” trong nhiều dự án. Nói một cách khác, một mẫu có thể được xem như một
“khuôn dạng” có sẵn có thể áp dụng được cho nhiều tình huống khác nhau để giải quyết
một vấn đề cụ thể. Trong bất kỳ hệ thống phần mềm hướng đối tượng nào, chúng ta cũng
có thể bắt gặp các vấn đề lặp lại.
a. Các mẫu phân tích
Các mẫu phân tích (Analysis Patterns) là để hiểu các vấn đề từ các yêu cầu bên ngoài.
Martin Fowler đã định nghĩa các mẫu phân tích như “ Nhóm những khái niệm được đại
diện cho một cấu trúc chung trong các mô hình nghiệp vụ”.

b. Các mẫu kiến trúc
Các mẫu kiến trúc (Structual Patterns) mô tả sơ đồ tổ chức với cấu trúc cơ bản cho hệ
thống phần mềm. Nó cung cấp một tập hợp các định nghĩa về các hệ thống con hoặc các
thành phần. Đồng thời chỉ rõ trách nhiệm của các thành phần đó cùng các qui tắc và các
nguyên tắc cho việc tạo lập mối quan hệ giữa chúng. Những mẫu kiến trúc là phương tiện
của kiến trúc, cung cấp tài liệu cho những hệ thống hỗn tạp và phức tạp. Do đó nó giúp
quản lý các ứng dụng phức tạp.
c. Mẫu thiết kế
Mẫu thiết kế (Design pettern) cung cấp một sơ đồ để làm mịn các hệ thống con, các
thành phần của một hệ thống phần mềm hoặc mối quan hệ giữa chúng. Nó mô tả một cấu
trúc, xác định những thành phần truyền thông nhằm giải quyết một vấn đề thiết kế chung
trong một ngữ cảnh đặc biệt. Mẫu chiến lược, mẫu trạng thái và mẫu uỷ nhiệm là những
ví dụ cho phạm trù này.
d. Thành ngữ
6


Luận văn thạc sỹ

Nguyễn Đức Toàn

Thành ngữ (idoms) là một loại mẫu đặc biệt mức thấp dành cho một ngôn ngữ lập
trình. Một thành ngữ miêu tả làm sao để thực hiện những khía cạnh đặc biệt của thành
phần hoặc mối quan hệ giữa chúng khi sử dụng những đặc tính của một ngôn ngữ lập
trình đã cho như: C++, Java hoặc Smalltalk.
Các mẫu là các kinh nghiệm thiết kế đã được kiểm chứng. Phần lớn những mẫu được
tìm ra hoặc được làm tài liệu là các mẫu được xây dựng lên từ nhiều dự án đã được tiến
hành trong thực tế hơn là những mẫu được sáng chế ra. Các mẫu là cách mô tả ngắn gọn
và hiệu quả để truyền đạt những khái niệm và kinh nghiệm của các nhà phát triển từ các
vấn đề thực tế.

1.2. Lịch sử các mẫu
Ý tưởng của mẫu phần mềm được phát triển rất đa dạng. Kiến trúc sư Christopher
Alexander trường đại học California ở Berkeley là người phát triển nền tảng của mẫu. Từ
“mẫu” đã gần như gắn liền với sự nghiệp hoạt động của giáo sư. Giáo sư và nhóm nghiên
cứu của ông đã mất khoảng hơn 20 năm để phát triển một cách tiếp cận tới các kiến trúc
thông thường có sử dụng các mẫu. Alexander đã giới thiệu hơn 250 mẫu với nhiều mức
độ trừu tượng từ kiến trúc của một thành phố đến các thiết kế phòng. Kiến trúc sư đã
thành lập khung mẫu miêu tả cơ bản của một mẫu như một giải pháp của vấn đề ở mức
ngữ cảnh. Ông đã phát triển một nguyên mẫu từ các mẫu dùng trong công việc của ông về
kiến trúc.
Kent Beck và Ward Cunningham[1] đã rất say mê áp dụng ý tưởng của Alexander để
phát triển các mẫu phần mềm. Họ đã tập hợp các mẫu đầu tiên nói về đặc tả giao diện
người dùng. Kent tập trung vào các thành ngữ cho Smalltalk và Ward diễn đạt kinh
nghiệm của mình bằng các hệ thống nghiệp vụ (hệ thống kế toán).
Erich Gamma đã xuất bản ấn phẩm đầu tiên về vấn đề sử dụng các mẫu trong phát
triển phần mềm năm 1991. Cuốn sách được viết ở Đức, nhưng cuốn sách này không được
chú ý nhiều. Bruce Anderson là một trong những nhà lãnh đạo trong cộng đồng mẫu. Ông
thành lập một ngân hàng mẫu ở OOPSLA vào đầu những năm 1990. Jim Coplien miêu tả
thành ngữ trên C++ trong quyển lập trình C++ tiên tiến . Theo một cách nào đó, những
thành ngữ này có liên quan tới ý tưởng của những giải pháp cung cấp tài liệu cho những
vấn đề thường xuyên. Một nhóm có tên là Hillside Group được hình thành nhằm khai thác
sâu hơn những ý tưởng này và thúc đẩy sử dụng mẫu trong quá trình phát triển phần mềm.
Họ xây dựng mẫu nhằm dẫn dắt và hỗ trợ những thành viên mới trong cộng đồng mẫu.
Nhóm này được hình thành đầu tiên với tên PLOP vào năm 1994.

7


Luận văn thạc sỹ

Nguyễn Đức Toàn

Những kiến thức cơ bản của quá trình phát triển mẫu được Gang of Four (GoF) xuất
bản trong cuốn” những mẫu thiết kế”. Những phần tử của phần mềm hướng đối tượng đã
được giới thiệu và được miêu tả dễ hiểu với mẫu thiết kế hướng đối tượng. Gamma,
Helm, Johnson, and Vlissides' work là đại diện cho lĩnh vực phân loại những giải pháp
thiết kế, và việc sử dụng thông dùng bên trong mẫu hướng đối tượng. Họ xây dựng một
tập hợp gồm 23 mẫu chia làm 3 phạm trù: theo hành vi, theo cấu trúc, và tạo sinh.
Peter Coad gần đây cũng nghiên cứu về các mẫu hướng đối tượng. Trong đó, ông đã
mô tả 7 loại mẫu cơ bản trong phân tích và thiết kế hướng đối tượng. Ông làm việc dựa
trên các mẫu, tức là nhờ vào việc phân tích một ứng dụng của miền đã được đưa ra và sử
dụng công nghệ hướng đối tượng để xây dựng các ứng dụng. Douglas Schmidt cũng là
một người dẫn dắt những người mới tham gia vào lĩnh vực dùng mẫu. Ông là tác giả của
rất nhiều mẫu trong lĩnh vực các hệ thống truyền thông và các ứng dụng phân tán.
Douglas Schmidt đã làm việc trên mẫu về các ứng dụng cho vấn đề phát triển khung
làm việc. Ông đã tạo ra các yếu tố cơ bản của cấu trúc vào trong các siêu mẫu được sử
dụng để phát triển các khung làm việc và điền địa chỉ Hot - Sport và Hooks/templates tiếp
cận trong việc phát triển khung làm việc.
Kiến trúc phần mềm hướng mẫu: Một hệ thống mẫu còn được gọi “Gang of five”,
hướng vào việc sử dụng các mẫu ở mức kiến trúc trong quá trình phát triển phần mềm.
Nhiều tác giả phân loại các mẫu phần mềm thành mẫu kiến trúc, mẫu thiết kế và thành
ngữ. Hầu hết sự đóng góp của họ được hướng về khía cạnh mẫu kiến trúc. Những quyển
sách của họ cùng với những quyển sách của Gof đánh dấu điểm bắt đầu của những người
mới trong cộng đồng mẫu.

1.3. Các thành phần của mẫu thiết kế
Mỗi mẫu thiết kế (Design Pattern) trước tiên mô tả một bài toán mà ta gặp nhiều lần,
rồi mô tả những yếu tố căn bản nhất để giải quyết bài toán theo cách mà ta có thể áp dụng
lại nhiều lần. Dựa trên mô tả như trên về các mẫu thiết kế, ta thấy chúng bao gồm những

thành phần cơ bản sau:

1.3.1. Tên mẫu
Tên mẫu (Pattern Name) là tên gọi qua đó ta có thể hình dung được bài toán cần giải
quyết và giải pháp thực hiện hay kết quả. Việc đặt tên mẫu thiết kế cho phép mô tả các bài
toán và giải pháp một cách ngắn gọn. Nó tạo thành một ngôn ngữ trong cộng đồng những
người thiết kế. Ví dụ, khi nói đến mẫu thiết kế "Facade " (bề mặt), ta hình dung ngay đến

8


Luận văn thạc sỹ

Nguyễn Đức Toàn

mô hình thiết kế một đối tượng với vai trò “interfacce” (giao diện) của một tập các thành
phần nhỏ hơn.

1.3.2. Vấn đề
Vấn đề (Problem) cho phép xác định trong trường hợp nào thì áp dụng mẫu thông qua
mô tả bài toán và ngữ cảnh của bài toán đó.

1.3.3. Giải pháp
Giải pháp (Solution) mô tả những thành phần tạo nên mẫu thiết kế cùng mối quan hệ,
vai trò và cách thức phối hợp giữa chúng. Giải pháp không đề cập đến cách thức thiết kế
hay thực hiện cụ thể nào vì nó được áp dụng trong rất nhiều tình huống khác nhau. Thay
vào đó, giải pháp của mẫu thiết kế được mô tả với tính khái quát cao, với cách thức tổ
chức chung nhất của các thành phần trong việc giải quyết bài toán.

1.3.4. Hệ quả

Hệ quả (Consequences) cho thấy việc áp dụng các giải pháp để giải quyết những vấn
đề có hiệu quả hay không. Nói cách khác, hệ quả đặt ra cho bạn cách lựa chọn, từ đó bạn
có thể xem xét lựa chọn nào là phù hợp nhất, tốt nhất.
Ngoài ra, một số tác giả (như Craig Larma, Kent Beck và Ward Cunningham) còn bổ
sung thêm một số thành phần khác nữa.

1.4. Mô tả mẫu thiết kế
Cách thức mô tả góp phần quan trọng trong việc hiểu và áp dụng mẫu thiết kế. Những
tiêu chí cơ bản trong mô tả các mẫu thiết kế bao gồm: đơn giản, chính xác và đầy đủ. Như
vậy, cần có một khuôn dạng mô tả thích hợp để đáp ứng các mẫu thiết kế khác nhau.
Đồng thời, khuôn dạng này cũng cho phép người xây dựng và người sử dụng có chung
một cách nhìn và tiếp cận đối với mẫu thiết kế.
Theo GOF (Gang of Five), một mẫu thiết kế được mô tả với các nội dung sau:

1.4.1. Tên gọi và phân loại
Tên gọi cần chuyển tải những yếu tố căn bản nhất của mẫu thiết kế, thường tên gọi chỉ
bao gồm một đến hai từ. Hơn nữa, tên gọi của mẫu thiết kế sẽ trở thành một phần trong bộ
từ vựng để trao đổi về các mô hình thiết kế nên cần được cân nhắc và lựa chọn kỹ lưỡng.
Việc phân loại cho phép xác định mẫu thiết kế thuộc nhóm nào. Theo GOF, các mẫu thiết

9


Luận văn thạc sỹ

Nguyễn Đức Toàn

kế đựơc phân thành ba nhóm: nhóm mẫu tạo sinh (creational), nhóm cấu trúc (structural)
và nhóm hành vi (behavioral).

1.4.2. Mục đích
Mẫu thiết kế cho biết:
- Mẫu thiết kế có chức năng gì.
- Lý do và mục đích của mẫu thiết kế
- Mẫu thiết kế giải quyết bài toán cụ thể nào.

1.4.3. Các tên gọi khác
Một mẫu thiết kế có thể có nhiều tên gọi khác nhau tuỳ theo cách gọi tên của người
thiết kế . Ví dụ, với mẫu thiết kế Factory Method, người ta có thể gọi nó với tên Virtual
Constructor. Cả hai tên gọi trên đều đúng để chỉ mô hình thiết kế với việc tạo ra một giao
diện trong việc khởi tạo các đối tượng và việc tạo đối tượng cụ thể thì do các lớp triển
khai giao diện này thực hiện.

1.4.4. Lý do sử dụng
Mẫu chỉ ra một ngữ cảnh trong đó mô tả bài toán thiết kế gặp phải và cách thức giải
quyết vấn đề của các lớp, đối tượng được thiết kế theo mẫu.

1.4.5. Khả năng áp dụng
Mẫu cho biết có thể áp dụng trong trường hợp nào. Đồng thời, chỉ ra những trường
hợp thiết kế chưa tốt mà mẫu có thể khắc phục được cùng với cách nhận biết những lỗi
thiết kế đó.

1.4.6. Cấu Trúc
Cấu trúc mẫu là mô tả bằng hình ảnh của các đối tượng được sử dụng trong thiết kế
mẫu.
Các thành phần tham gia, các lớp/ đối tượng tham gia vào mẫu và vai trò của chúng.

1.4.7. Kết Quả
Mẫu cho biết:
- Thiết kế mẫu này có tác động thế nào tới mục tiêu thiết kế.

- Những ràng buộc giữa các yếu tố và kết quả trong mẫu.
10


Luận văn thạc sỹ

Nguyễn Đức Toàn

- Những yếu tố của kiến trúc hệ thống có thể thay đổi mà không ảnh hưởng đến thiết
kế mẫu.

1.4.8.Triển Khai
Mẫu cho biết :
- Những khó khăn, những dấu hiệu hoặc những công nghệ cần phải lưu ý khi triển
khai mô hình.
- Có những yếu tố phụ thuộc vào từng ngôn ngữ cụ thể hay không

1.5. Vai trò của mẫu trong phát triển phần mềm
Khi sự phức tạp của các hệ thống phần mềm gia tăng, chúng ta tìm kiếm cách tiếp cận
để làm đơn giản hoá sự phát triển của các ứng dụng phần mềm. Các mẫu thiết kế hứa hẹn
sớm đem lại lợi ích của việc tái sử dụng trong vòng đời phát triển. Để có được lợi ích
trong quá trình triển khai những giải pháp thiết kế đã được khẳng định này, chúng ta cần
phải định nghĩa các kỹ thuật cấu thành thiết kế để xây dựng ứng dụng sử dụng các mẫu.
Những mô hình thiết kế linh hoạt cần phải được phát triển để hỗ trợ cho kỹ thuật này.
Tái sử dụng phần mềm trong các ứng dụng thực tế là một nhiệm vụ khó. Nó thực sự
quan trọng để giảm bớt công sức phát triển và đảm bảo chất lượng phần mềm cao hơn.
Các mẫu thiết kế có tác dụng thúc đẩy trong việc sử dụng lại các sản phẩm trong pha thiết
kế, bởi vì chúng cung cấp một tập hợp các từ vựng thông thường cho thiết kế. Chúng còn
cung cấp một ngữ nghĩa giúp cho việc hiểu các thiết kế và chúng chỉ ra các khối xây dựng
từ các ứng dụng phức tạp hơn đã được xây dựng. Sự tập hợp từ nhiều danh mục mẫu sẵn

có đã khuyến khích hình thành các ý tưởng xa hơn về việc làm sao để sử dụng những giải
pháp có thể tin cậy được để phát triển các ứng dụng. Các nhà nghiên cứu và thiết kế có
kinh nghiệm đã mất nhiều công sức trong việc làm tài liệu có chất lượng cao trong thiết
kế phần mềm như những mẫu thiết kế. Trong khi có rất nhiều sự chú ý được quan tâm để
tìm và làm tài liệu cho các mẫu thiết kế, thì các kỹ thuật để triển khai và gắn kết các giải
pháp thiết kế đã được chứng minh này vẫn còn thiếu các hệ thống hỗ trợ.
Thiết kế các ứng dụng bằng cách triển khai có hệ thống các mẫu thiết kế không phải
là một quá trình bình thường. Mặc dù cách tiếp cận cho thiết kế sử dụng công nghệ mẫu
cấu thành đã được đề xướng, nhưng còn thiếu tiến trình hệ thống làm chúng nhanh tới
đích.

11


Luận văn thạc sỹ

Nguyễn Đức Toàn

1.6. Mẫu thiết kế và kỹ nghệ phần mềm
1.6.1. Những mẫu thiết kế trong vòng đời phát triển phần mềm
Nhiều người thiết kế ứng dụng được khuyến khích để dùng những thành phần có thể
sử dụng lại nhằm giảm công sức và thời gian phát triển phần mềm. Mức độ sử dụng lại
được quyết định bởi những nhà tham gia phát triển ứng dụng. Một quyết định thiết kế đơn
giản như việc sử dụng lại một thư viện lớp hoặc một giao diện lập trình ứng dụng(API) là
những thứ thông thường nhất và dễ sử dụng. Một mức phức tạp hơn của sử dụng lại là sử
dụng lại những mẫu và những khung làm việc, trong đó người thiết kế có sẵn một tập hợp
rất nhiều mẫu với nội dung rộng hơn rất nhiều so với những quyết định thiết kế cần thiết.
Bất kỳ một vòng đời phát triển phần mềm nào cũng bao gồm một số pha phát triển:
phân tích, thiết kế, trình bày chi tiết thiết kế, triển khai và kiểm thử. Các mẫu có thể đóng
một vai trò quan trọng trong một hoặc trong mọi pha của vòng đời phát triển phần mềm.

Tuy nhiên, các mẫu đầu tiên được giới thiệu chỉ nhằm phục vụ vấn đề sử dụng lại trong
pha thiết kế. Nhưng rất nhiều nhà triển khai đã tận dụng lợi ích của mẫu trong tất cả các
pha của vòng đời phát triển phần mềm.
Các mẫu thiết kế sẽ tồn tại rất lâu. Càng nhiều nhà thiết kế và nhà phát triển dùng các
mẫu thì họ càng được thuyết phục rằng, chúng phải là một quá trình bộ phận được hợp
thành từ bất kỳ một tiến trình phát triển phần mềm nào. Tính đa dạng của các ứng dụng
với các mẫu được sử dụng và sự hữu ích của chúng là bằng chứng cụ thể về tính bền vững
của những mẫu thiết kế.
Phiên bản tiếp theo của các ứng dụng hướng đối tượng và các khung làm việc sẽ chứa
các mẫu rõ ràng. Các mẫu cũng sẽ tiếp tục được sử dụng để làm tài liệu mẫu và nội dung
của các khung làm việc. Những miền và những chủ đề chính khác cũng đem lại nhiều lợi
ích từ quá trình tập hợp các mẫu nhỏ cụ thể như sau:
a. Phân phối các đối tượng
Những ứng dụng tính toán song song và các đối tượng được nối mạng đã làm được tài
liệu trong thập niên qua.
b. Các hệ thống thời gian thực và các hệ thống nhúng
Một số lượng lớn các hệ thống tính toán gia tăng là hệ thống nhúng. Chúng bao gồm
các hệ thống điều khiển tự động, các ứng dụng trong ô tô, các phần mềm điều khiển cho
các thiết bị tự động hoá nhà máy và các thiết bị tính toán cầm tay. Nhiều hệ thống trong

12


Luận văn thạc sỹ

Nguyễn Đức Toàn

số các hệ thống này là đối tượng của việc tính toán chặt chẽ các tài nguyên hạn hẹp. Đặc
biệt là vấn đề lần vết và thời gian đã sử dụng trước đó.
Với khuynh hướng gia tăng trong việc khám phá và thiết kế các mẫu trong nhiều miền

ứng dụng, sự phổ biến ngày càng tăng của việc áp dụng mẫu trong phát triển phần mềm,
những phương pháp phát triển phần mềm là rất quan trọng.

1.6.2. Vòng đời mẫu

Các tác giả

Cộng đồng xây
dựng mẫu

Người dùng mẫu

Hình 1.1 Minh hoạ vòng đời của mẫu
Trên đây (hình 1.1) là vòng đời để tăng tính tin cậy của các mẫu đã được chọn cho các
thành phần thiết kế. Công việc này cho thấy có sự lặp đi lặp lại có cải tiến được phát triển
trên mẫu trước khi nó được làm tài liệu cho việc sử dụng lại.

13


Luận văn thạc sỹ

Nguyễn Đức Toàn

1.7. Đặc điểm chung của mẫu
Mẫu được hiểu theo nghĩa tái sử dụng ý tưởng hơn là mã lệnh: Mẫu cho phép các nhà
thiết kế có thể cùng ngồi lại với nhau và cùng giải quyết một vấn đề nào đó mà không
phải mất nhiều thời gian bàn cãi. Trong rất nhiều trường hợp, dự án phần mềm thất bại là
do các nhà phát triển không có được sự hiểu biết chung trong các vấn đề kiến trúc phần
mềm. Ngoài ra, mẫu cũng cung cấp những thuật ngữ và khái niệm chung trong thiết kế.

Nói một cách đơn giản, khi đề cập đến một mẫu nào đấy, bất kỳ ai có hiểu biết về mẫu đó
đều có thể nhanh chóng hình dung ra “bức tranh “ của giải pháp. Và cuối cùng, nếu áp
dụng mẫu hiệu quả thì việc bảo trì phần mềm cũng được tiến hành thuận lợi hơn, nắm bắt
kiến trúc hệ thống nhanh hơn.
Mẫu hỗ trợ tái sử dụng kiến trúc và mô hình thiết kế phần mềm theo qui mô lớn. Ở
đây chúng ta cần phân biệt mẫu thiết kế với khung làm việc. Khung làm việc hỗ trợ tái sử
dụng mô hình thiết kế và mã nguồn ở mức chi tiết hơn. Trong khi đó mẫu thiết kế được
vận dụng ở mức tổng quát hơn, giúp các nhà phát triển hình dung và ghi nhận các cấu trúc
tĩnh và động cũng như quan hệ tương tác giữa các giải pháp trong quá trình thiết kế ứng
dụng đối với các lĩnh vực riêng biệt.
Mẫu đa tương thích: Mẫu không phụ thuộc vào ngôn ngữ lập trình, công nghệ hoặc
các nền tảng lớn như J2W của Sun hay Microsofft, NET framework.
Tiềm năng ứng dụng của mẫu là rất lớn. Các thiết kế dựa trên mẫu được sử dụng khá
nhiều ở các phần mềm mã nguồn mở. Trong các dạng ứng dụng này, có thể dễ dàng nhận
ra một số tên lớp chứa các tiền tố hoặc hậu tố như Factory, Proxy, Adapter...

14


CHƢƠNG 2
CÁC LOẠI MẪU THIẾT KẾ
2.1. Phân loại mẫu
Mẫu được phân loại ra làm 3 nhóm chính sau đây:
a. Các mẫu tạo sinh
Các mẫu tạo sinh (Creational Pattern) gồm: Factory, Abstract Factory, Singleton,
Prototype, Builder… Liên quan đến quá trình khởi tạo đối tượng cụ thể từ một định nghĩa
trừu tượng(abstract class, interface).
b. Các mẫu cấu trúc
Các mẫu cấu trúc (Structural Pattern) gồm: Proxy, Adapter, Wrapper, Bridge, Facade,
Flyweight, visitor… Liên quan đến vấn đề làm thế nào để các lớp và đối tượng kết hợp

với nhau tạo thành các cấu trúc lớn hơn.
c. Các mẫu hành vi
Các mẫu hành vi (Behavioral pattern) observer, state, command, Interator…Mô tả
cách thức để các lớp hoặc các đối tượng có thể giao tiếp với nhau.

2.2. Mẫu thiết kế với từng bài toán
Trong quá trình thiết kế, chúng ta luôn gặp những sự kiện đó là sự phụ thuộc lẫn
nhau giữa các đối tượng trong hệ thống. Sự phụ thuộc này đôi khi cho phép ta giải quyết
các vấn đề trước mắt thật nhanh chóng. Nhưng phần mềm được tạo ra thường không chỉ
để giải quyết các vấn đề trước mắt, nó luôn thay đổi vì các yêu cầu thay đổi chức năng
không chỉ là cập nhật chức năng đã có mà còn thêm mới các chức năng mới.
Mỗi khi phần mềm cần thêm một yêu cầu mới, chúng ta thường phải thiết kế lại, thậm
chí cài đặt lại và kiểm thử lại xem các chức năng mới thêm vào có tương thích với các
chức năng cũ hay không, và các chức năng cũ có cần thay đổi để phù hợp với các chức
năng mới hay không... những điều đó làm chúng ta mất nhiều thời gian và tiền bạc. Vì
thế, mục tiêu của bất kì nhà thiết kế nào là có thể dự đoán được các thay đổi trong tương
lai của phần mềm. Trên cơ sở đó, thiết kế một hệ thống sao cho bất kỳ sự thay đổi nào
trong tương lai cũng không làm ảnh hưởng đến những phần còn lại của hệ thống.


Luận văn thạc sỹ

Nguyễn Đức Toàn

Một phần mềm không kiên định, phức tạp hoá và có quá nhiều các thành phần lệ thuộc
vào nhau, cần phải thiết kế lại đều do xuất phát từ những nguyên nhân sau:
- Các đối tượng đều được tạo ra từ các lớp cụ thể thay vì sử dụng các lớp ảo (interface)
làm cho việc thay đổi và cập nhật trong tương lai sẽ trở lên phức tạp. Vì vậy, sử dụng
các mẫu: Abstract Factory, Factory Method, Prototype.
- Phần mềm phụ thuộc vào phần cứng hệ điều hành. Một chương trình được thiết kế

trên Windows sẽ chạy không hiệu qủa trên Linux vì các hàm APIs và platform hoàn
toàn khác biệt nhau. Do đó, cần phải thiết kế chương trình có thể linh hoạt chuyển đổi
không phụ thuộc vào bất kỳ hệ điều hành, phần cứng nào... Vì vậy, sử dụng các mẫu:
Abstrac Factory, Bridge.
- Phần mềm phụ thuộc vào chi tiết của đối tượng như cách thức hoạt động như thế
nào, được lưu trữ tại stack nào, thực thi ra sao, có ràng buộc quan hệ nào không... Nếu
Client biết quá nhiều về đối tượng mà nó gọi tới thường luôn có xu hướng thay đổi
nếu đối tượng thay đổi. Chính vì thế, chúng ta cần giấu đi những thông tin không cần
thiết của đối tượng với client. Vì vậy, sử dụng Abstract Factory, Bridge, Memento,
proxy.
- Cách giải quyết một bài toán nào đó tại thời điểm này có thể chưa tốt và nó phải cần
được mở rộng thay thế hoặc tối ưu hoá. Việc phụ thuộc vào một vấn đề cụ thể thường
làm thay đổi các đối tượng liên quan, thậm chí gây ra sự thay đổi dây chuyền...Do đó,
các thuật toán càng độc lập bao nhiêu thì càng hạn chế được sự ràng buộc bấy nhiêu.
Vì vậy sử dụng các mẫu: Builder. Iterator, Strategy, Template, Method, Visitor.
- Phần mềm phụ thuộc chặt chẽ giữa các đối tượng. Do lớp đối tượng A và đối tượng
B liên kết phụ thuộc với nhau quá chặt nên rất khó có thể thay đổi lớp A nếu không
hiểu rõ về lớp B. Vì vậy sử dụng Abstract Factory, Bridge, Command, Observer.
Thiết kế mẫu đưa ra ý tưởng để khắc phục các vấn đề trên, cho phép ta xây dựng các
kiến trúc độc lập nhau, sao cho bất cứ sự thay đổi của phần nào trong hệ thống cũng
không làm ảnh hưởng hoặc ảnh hưởng rất ít đến các phần còn lại của hệ thống, từ đó làm
cho phần mềm trở nên kiên định và linh động hơn.

2.3. Mẫu chế tạo (Factory Pattern)
2.3.1. Định nghĩa
Mẫu chế tạo (Factory Pattern) định nghĩa một lớp (interface, abstract, class) đóng vai
trò như một “ nhà xưởng” có nhiệm vụ trừu tượng hoá quá trình khởi tạo đối tượng “ cụ
thể” khi ứng dụng chạy. Tại thời điểm thiết kế, đối tượng được định nghĩa trừu tượng.
16

Luận văn thạc sỹ

Nguyễn Đức Toàn

Các mẫu này giúp hệ thống không phải phụ thuộc vào cách một đối tượng được tạo ra,
xây dựng và thể hiện.

2.3.2. Đặc điểm
Mẫu chế tạo kiểm soát được các hoạt động trong suốt chu kỳ sống của đối tượng, như
khởi tạo đối tượng, huỷ đối tượng…Đảm bảo cho các đối tượng được thực thi an toàn.
Nắm được thông tin về những đối tượng nào được tạo ra và được khởi tạo ra sao. Nói
cách khác, các đối tượng được quản lý tốt và an toàn hơn Factory. Đối tượng của Factory
thường được đặt tên theo những chuẩn khác nhau nhưng vẫn có thể dễ dàng nhận ra thiết
kế Factory chứa trong đó. Ví dụ: BankFactory…
Tính chất đóng gói thể hiện rõ trong mẫu Factory, các thông tin liên quan đến truy cập
đối tượng được che giấu trong Factory. Thiết kế Factory luôn có một thủ tục khởi tạo đối
tượng, ví dụ creatObject().
Mẫu Factory luôn tuân thủ nguyên tắc thiết kế (Dependency inversion Principle - DIP)
không nên phụ thuộc vào những thứ quá cụ thể.

2.3.3. Phân loại
Mẫu Factory được thiết kế theo một trong hai cách sau đây:
a. Lớp cơ sở (Base- class) : mẫu này sử dụng tính chất thừa kế để phân loại các đối
tượng được tạo ra.
b. Đối tượng cơ sở(Base – object): Sử dụng mối quan hệ kết hợp để tham chiếu tới
một đối tượng sẽ được tạo ra. Đối tượng được tạo ra sẽ trở thành một phần hay thuộc tính
của lớp Factory. Chúng ta thường hay gặp loại này trong mẫu chế tạo trừu tượng(Abstrac
Factory Pattern).

17


Luận văn thạc sỹ

Nguyễn Đức Toàn

2.3.4. Một biểu đồ lớp bằng UML của mẫu chế tạo

Hình 2.1 Biểu đồ lớp của lớp chế tạo

2.4. Mẫu chế tạo trừu tƣợng (Abstract Factory Pattern)
2.4.1. Định nghĩa
Mẫu Abstract Factory cung cấp một giao diện lớp có chức năng tạo ra một tập hợp các
đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra đó là những lớp cụ thể nào
tại thời điểm thiết kế.
Về bản chất, mẫu Abstract Factory chỉ khác mẫu Factory ở chỗ bản thân đối tượng
factory không được chỉ ra cụ thể tại thời điểm thiết kế. Nó là một giao diện hoặc lớp trừu
tượng (interface, absstract). Nếu như mẫu Factory phân loại đối tượng dựa trên tham số
đầu vào, thì đối với mẫu Abstract Factory Pattern, thủ tục createObject() còn phụ thuộc
vào các yếu tố phụ khác như môi trường hệ điều hành. Ứng với mỗi yếu tố phụ thứ hai ta
có một lớp Factory cụ thể.

2.4.2. Thiết kế động với mẫu chế tạo trừu tƣợng
Một trong những vấn đề gặp phải là khung giao diện Abstract Factory thường hay bị
sửa đổi, thí dụ như bổ sung thủ tục chẳng hạn, khi đó các lớp cụ thể thực thi giao diện này
sẽ phải được dịch và triển khai lại. Để giảm nhẹ vấn đề này người ta thường thiết kế giao
diện Abstract Factory một cách linh hoạt.
18

Luận văn thạc sỹ

Nguyễn Đức Toàn

2.4.3. Biểu đồ lớp bằng UML của mẫu

Hình 2.2 Biểu đồ lớp của mẫu chế tạo trừu tượng

2.5. Mẫu đơn chiếc (Singleton Pattern)
Mẫu đơn chiếc (Singleton Pattern) đảm bảo một lớp chỉ có một thể hiện duy nhất được
tạo ra và đồng thời cung cấp một truy cập toàn cục đến đối tượng được tạo ra.

Hình 2.3 Minh hoạ biểu đồ lớp của mẫu đơn chiếc
19


Luận văn thạc sỹ

Nguyễn Đức Toàn

2.5.1. Định nghĩa
Mẫu đơn chiếc là mẫu đảm bảo rằng, một lớp chỉ có một thể hiện duy nhất và trong đó
cung cấp một cổng giao tiếp chung nhất để truy cập vào lớp đó.
Hộp thoại Find, là ví dụ cụ thể cho mẫu đơn chiếc chỉ một hộp thoại duy nhất xuất
hiện dù chọn menu nhiều lần.

Hình 2.4 Ví dụ mẫu đơn chiếc

Một số ví dụ về mẫu Singleton: file system, file manager, window manager

2.5.2. Lợi ích
Việc sử dụng mẫu Singleton đem lại các lợi ích sau:
- Quản lý việc truy cập tốt hơn vì chỉ có một thể hiện đơn nhất.
- Cho phép cải tiến các tác vụ (operations) và các thể hiện (representation) do mẫu có
thể được kế thừa và tuỳ biến lại thông qua một thể hiện của lớp con.
- Quản lý số lượng thể hiện của một lớp, không nhất thiết chỉ có một thể hiện mà có số
thể hiện xác định.
- Khả chuyển hơn so với việc dùng một lớp có thuộc tính là tĩnh, vì việc dùng lớp tĩnh
chỉ có thể sử dụng một thể hiện duy nhất, còn mẫu đơn chiếc cho phép quản lý các thể
hiện tốt hơn và tuỳ biến theo điều kiện cụ thể.

2.5.3. Trƣờng hợp sử dụng
Ta có thể sử dụng mẫu đơn chiếc trong những trường hợp sau:
- Chỉ cần một thể hiện duy nhất của một lớp.
- Khi thể hiện duy nhất có thể thay đổi thông qua việc thừa kế, người dùng có thể sử
dụng thể hiện thừa kế đó mà không cần thay đổi các đoạn mã của chương trình.

20


Luận văn thạc sỹ

Nguyễn Đức Toàn

2.5.4. Cách thực hiện
Thực hiện mẫu đơn chiếc theo các bước sau:
- Định nghĩa một thuộc tính riêng (Private) và tĩnh (static) trong các lớp Singleton:
instance.
- Định nghĩa tất cả các constructor thành các protected hoặc các private để người dùng

không thể tạo thực thể trực tiếp từ lớp.
- Định nghĩa một accessor Public và static trong lớp: getInstance().
- Thực hiện "Lazzy initialization"- khởi động chậm, khởi tạo khi yêu cầu trong
getInstance(): trả về một thể hiện mới hay một giá trị rỗng (null) tuỳ thuộc vào một
biến boolean, biến này như một cờ hiệu dùng báo xem lớp đó đã có thể hiện hay chưa.
- Client chỉ dùng getInstance() để tạo đối tượng của lớp Singleton.
Thừa kế cũng được hỗ trợ, nhưng không nạp chồng (overridden) các phương thức
Static: lớp cơ sở phải được khai báo là friend với lớp dẫn xuất (để truy xuất đến
prrotected constructor).

Hình 2.5 Biểu đồ lớp trong mẫu đơn chiếc
Trong chế độ đa luồng, mẫu Singleton có thể làm việc không tốt: hai thread có thể gọi
phương thức sinh đối tượng cùng thời điểm và hai thể hiện sẽ được tạo ra.

2.5.5. Ứng dụng của mẫu đơn chiếc
Ứng dụng rõ rệt nhất của mẫu đơn chiếc có thể thấy trong dịch vụ web khi triệu gọi
các đối tượng từ xa. Ở đó đối tượng nằm trên server hoặc sẽ phục vụ chung cho tất cả các
21


Luận văn thạc sỹ

Nguyễn Đức Toàn

ứng dụng khách (singleton) hoặc sẽ chỉ đáp ứng một ứng dụng khách riêng lẻ nào đó rồi
tự bị phá huỷ sau đó(single call).

2.5.6. Nhận xét
Chúng ta xét trường hợp có nhiều đối tượng có cùng chung một số tính chất nào đó
được tạo ra ứng với mỗi một yêu cầu từ các đối tượng khách (client). Lúc này độ phức tạp

sẽ tăng lên và ứng dụng sẽ chiếm dụng nhiều vùng nhớ hơn. Mẫu đơn chiếc là một giải
pháp đặc biệt của mẫu chế tạo ở chỗ, đối tượng sinh ra là điểm truy cập toàn cục “duy
nhất” đối với mọi chương trình gọi đến, hay nói một cách khác, tất cả các đối tượng khách
gọi đến đều chia sẻ đối tượng được tạo ra.

2.6. Mẫu uỷ nhiệm (Proxy Pattern)
2.6.1. Định nghĩa
Mẫu uỷ nhiệm (Proxy pattern): là mẫu thiết kế mà ở đó tất cả các truy cập trực tiếp
một đối tượng nào đó sẽ được chuyển hướng vào một đối tượng trung gian của lớp uỷ
nhiệm (Proxy class).
Mẫu uỷ nhiệm không những giúp quản lý đối tượng tốt hơn mà còn có nhiệm vụ bảo
vệ việc truy cập một đối tượng bằng cách thông qua proxy, hay còn gọi là truy cập gián
tiếp. Mẫu Proxy được uỷ quyền về phía ứng dụng khách cho phép tương tác với đối tượng
đích theo những cách khác nhau, như gửi yêu cầu một dịch vụ nào đó, theo dõi trạng thái
và vòng đời đối tượng, xây dựng lớp vỏ bảo vệ đối tượng…Thí dụ, chúng ta phát hiện ra
một đối tượng như một thư viện DLL có thể bị khai thác truy cập vào trong một số trường
quan trọng, khi đó chúng ta không thể mở mã nguồn thư viện đã được dịch để vá lỗ hổng.
Giải pháp lúc này là xây dựng một proxy ngăn chặn truy cập các trường đó và cuối cùng
biên dịch lại thành một DLL mới.

2.6.2. Phân loại
Độ phức tạp của giải pháp sử dụng mẫu uỷ nhiệm phụ thuộc vào tình huống bài toán
đưa ra.
- Ủy nhiệm từ xa (Remote Proxy): Máy khách truy cập qua remote proxy để tham
chiếu tới một đối tượng được bảo vệ nằm bên ngoài ứng dụng như dịch vụ Windows,
dịch vụ web, ứng dụng từ xa. . . Mô hình này “ che giấu” đối tượng được triệu gọi
đang nằm ở rất xa đâu đó và client có vẻ như truy cập vào đối tượng nằm trên cùng
một miền làm việc.
22