Một số công nghệ áp dụng kiến trúc MODEL VIEW CONTROLLER luận văn ths công nghệ thông tin 1 01 10

Đ Ạ I H Ọ C Q U Ố C G IA H À N Ộ I
TR Ư Ờ N G ĐẠI HỌC CÔ N G N G H Ệ

CÁN XUÂN HOÀN

M Ộ T SỐ CÔ N G N G H Ệ Á P DỤNG
K IÉ N T R Ủ C M O D E L - V IE W - C O N T R O L L E R

N gành: C ô n g n g h ệ th ô n g tin
C huyên nghành: C ô n g n g h ệ th ô n g tin
M ã số: 1.01.10

L U Ậ N V Ă N T H Ạ C SỸ

NGƯỜI HƯ ỞNG DÃN KHOA HỌC
P G S .T S V Ũ Đ Ứ C T H I

H à N ội - 2005


M

Ụ

C

L

Ụ

C

M Ụ C L Ụ C .................................................................................................................................1
LỜ I C Ả M Ơ N ........................ .............................................................................................. 4
D A N H M Ụ C C Á C H ÌN H VẼ T R O N G LU Ậ N V Ă N ...............................................5
MỜ Đ Ằ Ư .................................................................................................................. 6
C H Ư Ơ N G I TỒ N G Q U A N VỀ M V C ........................................................................... 9
1.1. Lịch sử phát triển của M V C ...................................................................................9
1.2. Thiết kế theo m ô hình m ẫu (design p a tte rn )................................................... 12
1.2.1. Đ ịnh n g h ĩa .........................................................................................................12
1.2.2. Lợi ích của thiết kế theo mô hình m ẫ u .................................................... 12
1.2.3. Phân loại các m ầu thiết k ế ........................................................................... 13
1.3. K iến trúc M V C .........................................................................................................14
1.3.1. M odel (M ô hình dừ liệu )...............................................................................14
1.3.2. View (H iền thị hay giao diện người d ù n g ) .............................................15
1.3.3. C ontroller (Đ iều khiển hay Q uán lý chức n ă n g )...................................15
1.3.4. Sự tương tác giữa các thành phần cùa M V C ......................................... 16
1.3.5. M ột số đặc điểm cơ bản của M V C ............................................................17
1.4. M ột số các m ẫu thiết kế trong M V C ................................................................. 18
1.4.1. C om posite P attern ...........................................................................................18
1.4.2. O bserver P a tte rn .............................................................................................20
1.4.3. Strategy P a tte r n ...............................................................................................21
1.4.4. A dapter P a tte rn ............................................................................................... 23
1.4.5. C om m and P a tte rn .......................................................................................... 24
1.4.6. Factory P a tte rn .................................................................................................26
1.4.7. M ediator P a tte rn ............................................................................................. 27
1.4.8. D ecorator P a tte rn ............................................................................................28
1.4.9. So sánh các m ẫu thiết k ế .............................................................................. 29
1.5. Giới thiệu m ột số công nghệ nền tả n g ...............................................................31
1.5.1. H TTP, H T M L và các sự k iệ n ...................................................................... 31
1.5.2. Chu trình request/response (hỏi/đáp) của H T T P ................................. 32

1.5.3. C ác phiên làm việc (S e ssio n )..................................................................... 32
1.5 4 X M L .......... .........................................................................................................33
1.5.5. N gôn ngừ Java và các ứng dụng F ram e w o rk .........................................34
1.5.6. J a v a B e a n s ......................................................................................................... 34
1.5.7. J a v a S e rv le t....................................................................................................... 35
1.5.8. B ộ lọc th ô n g t i n .............................................................................................. 36
1.5.9. Di chuyển các yêu c ầ u ..................................................................................36
1.5.10. Java S erver Page, Taglib, Java S erv er F a c e .........................................37
1.5.11. C ác m essag e-reso u rce............................................................................... !37
C H Ư Ơ N G II Á P D Ự N G M V C T R O N G T H IẾ T K É G IA O D IỆN Đ Ô H Ọ A 39

Một số công nghệ áp dụng kiến trúc Model - View - Controller


2

II. 1. G iới th iệ u ..................................................................................................................39
11.2. Áp dụn g M V C tro n g ngôn ngữ lập trình S m a llT a lk ................................. 39
11.2.1. G iới t h i ệ u .........................................................................................................39
11.2.2. Thành p h ận M o d e l........................................................................................ 40
11.2.3. Thành p h ận V ie w ......................................................................................... 42
11.2.4. Thậnh p h ần C o n tro lle r.................................................................................44
11.2.4. Phối hợp các th àn h phần trong M V C ..................................................... 45
11.3. Áp dụn g M V C tro n g thiết kế các thành p h ần Java S w in g ....................... 46
11.3.1. G iới t h i ệ u .........................................................................................................46
11.3.3. Jav a S w ing và th iết kế M V C .................................................................... 48
11.3.3.1. Thành phận M o d e l............................................................................... 49
11.3.3.2. T hành phần giao d iện ........................................................................... 51
11.3.4. M ột ví dụ v ề S w in g ......................................................................................53
C H Ư Ơ N G III Á P D Ự N G M V C TR O N G CÁ C Ứ N G D Ụ N G W E B ...................57

III. 1. Lựa chọn kiến trú c tổng thể cho m ột ứng d ụ n g .........................................57
111.2. Áp dụng M V C tro n g m ột ứng dụng w eb tổng q u á t ................................. 59
111.2.1. X ây dự ng th àn h phần C o n tro lle r............................................................59
111.2.1.1. X ác địn h phirơng thức xử lý yêu c ầ u ........................................... 59
111.2.1.2. C h u y ền yêu cầu người dùng ch o chức năng xử lý .................. 60
111.2.1.3. Lựa ch ọ n trang m àn hình hiển thị tiếp th e o ................................62
111.2.1.4. Đ a điều k h iể n .......................................................................................66
111.2.2. X ây d ự ng thành phần V ie w ......................................................................68
III.2.2.1. T hiết kế m ẫu cho m àn hình hiển th ị.............................................. 68
Ịn .2 .2 .2 Á nh x ạ U R L tới m ột trang m àn hình hiển t h ị ............................ 70
111.2.3. X ây d ự n g th àn h phần M o d e l....................................................................71
111.3. Áp dụng M V C tro n g công nghệ J2EE của S u n .......................................... 73
111.3.1. Giới thiệu về công nghệ J 2 E E .................................................................73
111.3.2. Thành p h ần V ie w ........................................................................................ 73
111.3.3. T hành p h ần M o d e l......................................................................................74
111.3.4. Thành p h ần C o n tro lle r.............................................................................. 76
111.3.5. Tirơng tác giữa các thành phần M V C ...................................................78
111.4. Áp dụng M V C tro n g Struts F ra m e w o rk .......................................................80
111.4.1. Giới thiệu về Struts F ra m e w o rk .............................................................80
in .4 .2 . T hành p h ần M o d e l...................................................................................... 81
111.4.3. T hành p h ần V ie w ........................................................................................ 82
111.4.4. T hành p h ần C o n tro lle r.............................................................................. 82
111.4.5. Phối hợp các thành phần M V C ............................................................... 82
111.5. Á p dụng M V C trong ngôn ngữ lập trình P H P ........................................... 85
in .5 .1 . Giới th iệu về P H P .......................................................................................85
111.5.2. Xây d ự ng thành phần M o d e l................................................................... 86
M ột số công nghệ áp (lụng kiến trúc M odel - View - Controller


3

111.5.3. X ây dựng thành phận V ie w ......................................................................89
111.5.4. X âỵ dựng thành phần C o n tro lle r............................................................ 91
111.5.5. Phối hợp các thành phần M V C ............................................................... 92
C H Ư Ơ N G IV X Â Y D ự N G HỆ TH Ố N G ISP B ILLIN G SY STEM TRÊN
STR U TS F R A M E W O R K ... . ..................................................................................... 94
IV. 1. Đ ặt bài t o á n ...........................................................................................................94
IV .2. Sơ đồ chức năng hệ th ố n g .................................................................................95
IV 3. T hiết kế C S D L ......................................................................................................97
IV .4. G iao diện chư ơng tr in h ..................................................................................... 98
IV .5. X ây dựng các thành phần ứng d ụ n g ............................................................100
IV.5.1. X ây dựng thành phận M o d e l.................................................................100
IV .5.2. Xây dựng thành phận V ie w ....................................................................101
IV .5.3. X ây dựng thành phần C o n tro lle r......................................................... 103
IV .6. Đ ánh giá kết quà và hướng phát triể n ......................................................... 104
KÉT L U Ậ N .........................................................................................................................105
TÀJ LIỆU TH A M K H Ả O ............................................................................................. 106
PH Ụ LỤ C
... ............... ......... ........................................................................................107

Một sổ công nghệ áp dụng kiến trúc Model - View - Controller


5

DANH MỤC CÁC HỈNH VẼ TRONG LUẬN VĂN
Hình 1.3.3. C ác thành phần Model, View, Controller trong thanh cuộn
Hình 1.3.4. Sự tương tác giữa các thành phần của MVC
Hình 1.4.2. Các cách hiển thị khác nhau của cùng một dữ liệu
Hình 1.5.2. C hu trình hỏi/đáp (request/response) cùa H T TP

Hình II.3.1. Kiến trúc Java Foundation Classes
Hình II.3.2. Kiến trúc tách Model trong Java Swing
Hình II.3.4. Giao diện chương trình Toolbar Example
Hình III.2.1.3. a. Lược đồ lựa chọn màn hình hiển thị tiếp theo
Hình III.2.1.3. b. Lược đồ lựa chọn màn hình hiển thị đăng xuất
Hình III.2.1.4. Sơ đồ Đơn điều khiển
Hình III.2.1.4.b. Sơ đồ Đa điều khiển
Hình III.2.1 4.C. Sơ đồ Đa điều khiển kết hợp Router
Hình III.2.2.1. Bố cục mẫu của một trang web
Hình II 1.3.5. Lược đồ cấu trúc một ứng dụng w eb trên kiến trúc J2EE
Hỉnh III.5.4. M ô hình UML
Hình IV. 1. Mô hình hoạt động của hệ thổng ISP Billing System
Hình IV.3. Sơ đồ phân rã chức năng hệ thống ISP Billing System
Hình IV.2. Sơ đồ quan hệ thực thể của chức năng Sercurity
Hình IV.4.a. Giao diện Đăng nhập hệ thống
Hình IV.4.b. Giao diện thêm mới một Admin
Hình IV.4.C. Giao diện Danh sách các Admin
Hình IV.4.d. Giao diện Cập nhật thông tin Admin

Một số công nghệ áp dụng kiến trúc Model - View - Controller


6

MỞ ĐÀU
Phân tích và thiết kế là khâu đầu tiên và có ý nghĩa quyết định cho sự
:hành công của hệ thống phần mềm được xây dựng. Các yêu cầu chủ yếu đổi
với một phần mềm tốt như: tính có thể bào trì được, độ tin cậy cao, tính mềm

đèo, có giao diện sứ dụng thích hợp... được quyết định trước hết ở giai đoạn
phân tích và thiết kế. Một thống kê trước đây cho thấy: một lỗi trong phân
tích hệ thống bị bò qua, khi thiết kế xong mới phát hiện thì chi phí sừa chữa
lăng lên 10 lần; và nếu bị bỏ qua cho đến khi cài đặt mới phát hiện ra thì chi
phí tăng lên 40 lần; nếu đến khi vận hành mới phát hiện ra thì chi phí sửa
chữa lên tới 90 lần. M ặt khác, chi phí cho khâu phân tích và thiết kế phần
mềm ờ các nước phát triển (như Mỹ, Anh, Ấn Đ ộ ...) có thể lên đến trên 30%
tồng chi phí phát triển phần mềm. Trong khi đó, chi phí cho khâu lập trình có
dự án đã giảm xuống dưới 10%. Điều này cho thấy vai trò cùa phân tích và
thiết kế phần mềm ngày càng trở nên quan trọng, nhất là trong điều kiện các
hệ thống phần mềm ngày càng có quy mô lớn và độ phức tạp ngày càng cao,
các công cụ lập trình ngày càng phong phú và tiện lợi.
Trong những năm gần đây, thiết kế theo mô hình mẫu nổi lên như một
lĩnh vực mới mẻ được các nhà khoa học quan tâm nghiên cứu bời tính ứng
dụng cao trong lĩnh vực thiết kế phần mềm. Với hàng loạt các nghiên cứu, đề
xuất được thử nghiệm và ứng dụng thành công vào các sàn phẩm công nghệ
cao đã chứng minh thiết kế theo mô hình mẫu là lĩnh vực nghiên cứu có nền
tàng lý thuyết vững chắc. Thiết kế theo mô hình mẫu được ứng dụng trong rất
nhiều khâu của quá trình thiết kế một ứng dụng. Từ việc lựa chọn kiến trúc
tồng thể của ứng dụng cho tới thiết kế tương tác bên trong mỗi thành phần
con của hệ thống.
M odel - View - Controller (M VC) là một mẫu thiết kế phần mềm
Một số công nghệ áp dụng kiến trúc Model - View - Controller


7

cược đánh giá là một trong những phương pháp thiết kế hướng đối tượng
tìành công nhất hiện nay. M VC đà được nhiều nhà khoa học tìm hiểu, nghiên
cứu và đã thu được nhiều thành công lớn.

Với một lĩnh vực khoa học công nghệ mới còn nhiều triển vọng trong
tirơng lai, em đã chọn hướng nghiên cứu về “ M ột số công nghệ áp dụng kiến
trúc Model - View - Controller” cho luận văn của mình. Luận văn này được
xày dựng và tổng hợp các nội dung dựa trên nền một số nghiên cứu về thiết
kế theo mô hình mầu mà trọng tâm là kiến trúc M V C của các nhà nghiên cứu
tiong những năm gần đây và rất nhiều các bài báo được công bố trên các tạp
chí chuyên nghành cũng như trên Internet.
Nội dung của luận văn gồm các chương mục sau:
C h ư ơ n g I: T ổ n g q u a n về M V C

Chương này trình bày những nét khái quát nhất về kiến trúc Model View - Controller bao gồm các kiến thức về lịch sử phát triền của MVC, về
thiết kế theo mô hình mầu, các thành phần trong M VC, sự tương tác giữa các
thành phần M odel, View, Controller và một số các mẫu thiết kế cơ bản để tạo
thành kiến trúc MVC.
C h ư ơ n g II : Á p d ụ n g M V C tr o n g cá c ứ n g d ụ n g đ ỗ h ọ a

Trong chương này trình bày về việc áp dụng M VC trong việc xây
dựng các ứng dụng đồ họa bao gồm việc áp dụng M VC trong ngôn ngữ lập
trình SmallTalk và việc áp dụng MVC trong các thành phần của Java Swing.
C h ư ơ n g I I I : Á p d ụ n g k iế n tr ú c M V C tr o n g c á c ứ n g d ụ n g w eb

Chương này trình bày về cách thức áp dụng kiến trúc M VC trong các
ưng dụng web nói chung bao gồm các kiến thức về việc lựa chọn mô hình
tổng thể cho một dự án web, cách thức phân tách các thành phần của một ứng
Một số công nghệ áp dụng kiến trúc Model - View - Controller


8

dụng thành các thành phần M odel, View, C ontroller cũng như cách thức phối

hợp các thành phần đó lại để tạo thành m ột ứng dụng w eb hoàn chinh.
Chương này cùng trình bày về một số công nghệ áp dụng kiến trúc M VC như:
Công nghệ J2EE, Struts Fram ework , PHP.
C h ư ơ ĩig I V : X â y d ự n g ứ n g d ụ n g w e b I S P B i llin g S y s te m b ằ n g
A p a c h e S tr u ts F r a m e w o r k

Chương này trình bày về cách thức xây dụng m ột ứng dụng w eb cụ
thể trên Apache Struts Framework: Hệ thống ISP Billing System.

Một sổ công nghệ áp dụng kiến trúc Model —View - Controller


9

CHƯƠNG I
TỎNG QUAN VÉ MVC
1.1. Lịch s ử phát triển cùa MVC
Tháng 8 năm 1973, tại thành phố Oslo của Na Uy, Tiến sỹ Trygve
Reenskaug lúc đó đang làm việc cho Viện Nghiên cứu Công nghiệp Trung
ương (Central Institute for Industrial Research) đã viết bài báo “Quản lý điều
hành trong xưởng đóng tàu” (Administrative Control in the Shipyard) và đã
công bố lần đầu tiên tại hội thào quốc tế về các ứng dụng máy tính trong
ngành đóng tàu vào mùa thu năm đó. Trong bài báo của mình, Reenskaug đã
phân tích xưởng đóng tàu hiện đại như một hệ thống thông tin và đưa ra nhiều
kliía cạnh kỳ thuật cũng như các khía cạnh xã hội phức tạp vốn có của một
xường đóng tàu. Với mục tiêu làm giảm độ phức tạp cho một ứng dụng máy
tính, ông đă đề xuất hàng loạt các công nghệ nên được sử dụng trong việc mô
tá một hệ thống. Ý tưởng trung tâm trong chiến lược của ông là “phân rã một
hệ thống lớn hay một hệ thống phức tạp thành các m ô đun thành phần” .
Tiếp đến, Reenskaug mô tả các yêu cầu tổng quát mà một framework

cần có để có thể xây dựng các hệ thống mới trên nền một hệ thống đã có, phù
hợp với cái đã có và hệ thống mới có đủ tính mềm dẻo để có thể thích ứng với
các thay đồi trong tồ chức, ô n g đưa ra các tính chất mà một framework cần
có là:
1. Có thể can thiệp thủ công vào hệ thống một cách dễ dàng.
2. Các nhóm trong xưởng tàu phải có trách nhiệm, quyền hạn và năng
lực phù hợp. Hệ thống xử lý dữ liệu tổng hợp phải được chia thành các hệ
thống con gẳn với từng vùng trách nhiệm. Các hệ thống con sẽ được điều
khiển và phát triển dựa trên từng nhóm cụ thể.
3. M ột hệ thống con phải có trách nhiệm rõ ràng để những người trong
Một số công nghệ áp dụng kiến trúc Model —View —Controller


10

hệ thống đó có thể hiểu về các hoạt động của nó một cách đầy đủ.
4. Tất cả các hệ thống con phải có tính mở để có thề gắn kết với các
hệ thống con khác cùng nhóm hoặc khác nhóm trách nhiệm.
5. Hệ thống tổng thể phải có khả năng phát triển tiếp; có thể thêm vào
các hệ thống con mới hay thay đổi các hệ thống con cũ mà không cần xây
dựng lại toàn bộ hệ thống. Nó có thể nhúng một hệ thống lạ vào mà không
cần thiết lập lại hệ thống. Việc chuyển đổi thế hệ của một hệ thống là đơn
giàn.
M ặc dù, nền tàng về một framework cùa Reenskaug rất vững chẳc,
nhưng lại thiếu m ột ngôn ngữ lập trình hướng đối tượng để có thể trờ thành
cái được gọi là M VC.
M ột vài năm sau đó, tại Califonia, Reenskaug đã được tiếp cận với
chiếc máy tính ALTO , đây là “chiếc máy vi tính đầu tiên trên thế giới có khả
năng điều khiển thông qua các giao diện” . N hờ đó, nó đã giúp ông và các
đồng nghiệp của mình phát hiện thấy “M VC là một giải pháp cho việc điều

khiển các tập dữ liệu lớn và phức tạp” - khi đó là vào năm 1978, tại Xerox
Palo Alto R esearch Center (PARC).
M ô tả m ột fram ework để làm công việc này là một vấn đề không dễ
dàng. Công việc khó nhất là tìm tên cho các thành phần kiến trúc khác nhau
của hệ thống, Reenskaug viết “M odel - View - Editor là tập thứ nhất” . Trong
bài báo “ Thing - M odel - View - Editor” ông đã định nghĩa các khái niệm
sau:

Thing: “N hững cái mà người sử dụng quan tâm ” (khái niệm về thế
giới thực).

Model: “ M ột trình diễn tích cực cùa việc trừu tượng hóa trong một
Một sổ công nghệ áp dụng kiến trúc Model - Vietv —Controller


11

định dạng dừ liệu trong một hệ thống máy tính). (Trừu tượng hóa của Thing).

View: “ M ột hoặc nhiều trình diễn hình tượng của M odel” .
Editor: “ Một giao diện giữa một người dùng và một hoặc nhiều
View” (Sau này gọi là “Controller” và “Tool”).
Từ các thiết kế ban đầu này, kiến trúc M V C được ra đời và xuất hiện
lần đầu tiên trong ngôn ngữ lập trình SmallTalk-80. Trong đó, Model là sự
trừu tượng hóa của thế giới thực, View là trình diễn trực quan và Controller là
các nút bấm, các thanh trượt cho phép người dùng tương tác với hệ thống.
Các thành phần trong MVC được kết nối với nhau và mồi thành phần có thề
liên kết với hai thành phần còn lại, vi thế không còn phức tạp trong việc phân
tầng và trừu tượng hóa. Khi đó, Reenskaug thích sử dụng khái niệm Tool hơn
là Controller.

Không lâu sau đó, Tiến sỹ Reenkaug rời phòng thí nghiệm PARC và
cộng tác làm việc với Jim Althoff và Dan Ingalls. Vì tính hiệu quả của M VC
trong ngôn ngừ lập trìng SmallTalK-80 mà M V C được tiếp tục phát triển đến
ngày nay, nó là một mẫu thiết kế hiệu quả và phù hợp cho thiết kế các thành
phần giao diện người dùng.
Tiến sỹ Reenskaug đã không ngừng nghiên cứu về M VC và trong
những năm gần đây ông bắt đầu xuất bản tài liệu về ngôn ngừ mẫu thiết kế
MVC. Tuy nhiên, ông chưa bao giờ nói đến việc mẫu thiết kế MVC có thể
được sử dụng để giãi quyết bài toán cho các ứng dụng trên các kiến trúc nhiều
tầng. [4]
Sau này, M V C được áp dụng nhiều trong các GUI Framework như:
NeXTSTEP, OPENSTEP, Cocoa, M icrosoft Foundtion Class (MFC) hay
trong thư viện đồ hoạ của Java Swing. Gần đây, bat đầu từ 1998, M VC đã
được áp dụng cho các ứng dụng web, giúp những nhà phát triền phần mềm có
Một số công nghệ áp dụng kiến trúc Model - View - Controller


12

thể xây dựng được các ứng dụng web có độ phức tạp cao, qui mô lớn mà với
cách tiếp cận truyền thống khó có thể đáp ứng được. Các W eb Framework nồi
tiếng hiện nay là: JavaServer Face (JSF), Apache Struts, W ebwork2,
FuseBox, M ach-II, M aypole, Catalyst, ZNF, A pache Cocoon, Ruby on Rails
và nhiều các ứng dụng khác như: W ebObject, Tapestry.
Nghiên cứu về M VC là một công việc khó. Do vậy, để có thể hiểu rõ
về M VC được dễ dàng hơn, trước hết chúng ta cần có kiến thức vể thiết kế
theo mô hình mẫu (design pattern).

1.2. Thiết kế theo mô hình mẫu (design pattern)
1 .2.1. Đ ị n h n g h ĩ a

Trong kỹ nghệ phần mềm, mẫu thiết kế là một giải pháp chung cho
inột vấn đề thường gặp trong thiết kế. v ấ n đề này thường được “lặp đi lặp
lại” trong nhiều dự án. Nói cách khác, mẫu thiết kế được xem như là một
“ khuôn mẫu” có sằn áp dụng được với nhiều tình huống khác nhau để giải
quyết một vấn đề trong một hoàn cảnh cụ thể. [7]
Thiết kế theo mô hình mẫu là quá trình áp dụng các mẫu có sẵn vào
một ứng dụng cụ thể nào đó. v ấ n đề then chốt của thiết kế theo mô hình mẫu
là hiểu rõ về từng mẫu bao gồm các ưu điểm, nhược điềm và khả năng thành
công cũng như cách thức áp dụng các mầu đó vào từng hoàn cảnh cụ thể.
1 .2.2. L ợ i í c h c ủ a t h i ế t k é t h e o m ô h ì n h m ẫ u

Thông thường, mọi người thường chỉ hiểu cách thức áp dụng m ột kỳ
thuật thiết kế phần mềm cho một vấn đề cụ thể nào đó. Do vậy, chúng khó có
thể được áp dụng cho các vấn đề ờ một phạm vi lớn hơn. Thiết kế theo mô
hình mầu cung cấp một giải pháp chung để giải quyết nhiều vấn đề khác
nhau.[7][l]. Thiết kế theo mô hình mẫu có rất nhiều các lợi ích có thể kể ra
sau đây:
Một số công nghệ áp dụng kiến trúc Model - View - Controller


13

- Giúp các nhà phát triển nhanh chóng tìm ra các giải pháp.
- Giúp những nhà nghiên cứu này sinh nhiều ý tưởng mới và độc đáo.
- Giúp các nhà thiết kế trao đổi với nhau một cách dễ dàng.
- Có thể đưa ra các lời giải cho một vấn đề cụ thề.
- Tận dụng được các kinh nghiệm của những người đi trước.
- Biết được hiệu quả của mồi giải pháp trong từng hoàn cành cụ thể.

- Có thề tìm đư ợc lời giái tốt nhất cho một vấn đề.
Tóm lại: "thiết kế theo mô hình mẫu giúp người thiết kế học được sự
thành công từ người khác và tránh đi các thất bại cho bản thân".
1 .2 .3 . P h â n l o ạ i c á c m ẫ u t h i ế t k é

Ngày nay, có rất nhiều các mẫu thiết kế khác nhau được sử dụng vào
quá trình thiết kế phần mềm. Tuy nhiên, các mẫu thiết kế này đều được xây
dựng dựa trên 23 mẫu thiết kế cơ bàn của G o f (Gang o f Four - có nghĩa là
“nhóm 4 người bạn” - quốc tịch Trung Quốc). G of chia các mẫu thành 3
nhóm chính sau đây:
- Nhóm cấu thành: bao gồm các mẫu thiết kế về khởi tạo các đối
tượng là: Factory Pattern, Abstract Factory, Singleton Pattern, Prototype
Pattern, Builder Pattern.
- N h ó m c ấ u t r ú c : bao gồm các mẫu thiết kế về cách thức liên kết các
đối tượng thành các cấu trúc lớn hơn: A dapter Pattern, Brigde Pattern,
Com posite Pattern, Decorator Pattern, Façade Pattern, Flyweight Pattern,
Proxy Pattern.
- N h ó m tư ơ n g tác đ ộ n g bao gồm các mẫu thiết kế về cách thức để

các đối tượng có thề liên lạc được VỚI nhau: Chain of Resp Pattern, Command
Một sổ công nghệ áp dụng kiến trúc Model - Vieyv - Controller


14

Pattern, Interpreter Pattern, Iterator Pattern, M ediator Pattern, Memento
Pattern, Observer Pattern, State Pattern, Strategy Pattern, Template Method,
Visitor Pattern.
Ngoài các mẫu thiết kế cơ bản cùa Gof, rất nhiều các mẫu thiết kế
tổng hợp khác đã được xây dựng lên và cũng đã rất thành công.

1.3. Kiến trúc MVC
M VC là một kiến trúc phần mềm chia M odel (mô hình dừ liệu), View
(phần hiển thị hay giao diện người dùng), Controller (phần điều khiển hay
điều khiển chức năng) của một thành phần hay một ứng dụng thành ba phần
tách biệt, vì thế khi thay đồi trên một trong ba thành phần đó sẽ ảnh hưởng ít
nhất đến các thành phần còn lại.
M VC thường được hiểu là một mẫu thiết kế phần mềm. Tuy nhiên,
MVC mang nhiều ý nghĩa về kiến trúc phần mềm hơn một mầu thiết kế thông
thường. Vi thế, M VC thường được gọi là một kiến trúc phần mềm
(Bruschmann đưa ra năm 1996), mầu thiết kế phần mềm tổng hợp hay mẫu
của mẫu thiết kế. M V C được tổng họp từ nhiều các mẫu thiết kế nhỏ hơn:
View áp dụng mẫu Com posite Pattern, giao tiếp giữa View và Model sừ dụng
mẫu O bserver Pattern;

Controller sử dụng mẫu

Strategy Pattern

hay

Command Pattern; và một số mẫu khác như: M ediator Pattern, Decorator
Pattern, A daptor Pattern, Factory Pattern... [7]
1 .3.1. M o d e l ( M ô h ì n h d ữ l i ệ u )

M odel nắm giữ các dừ liệu, thực hiện các chức năng liên quan đến
việc truy cập dừ liệu hay thay đồi các dữ liệu của chương trình. Model thường
được chia thành hai hệ thống con đó là: các trạng thái nội tại của hệ thống và
các hành động làm thay đồi các trạng thái cùa hệ thống, v ề mặt ngữ pháp học,
có thể hiểu các trạng thái nội tại của hệ thống như các danh từ và các hành

M ột số công nghệ áp (lụng kiến trúc M odel - View —Controller


15

động làm thay đổi các trạng thái của hệ thống là các động từ.
Mỗi một ứng dụng (hoặc thành phần) có một Model khác nhau. Ví dụ,
Model của một thanh cuộn (scrollbar) có thể chứa các thông tin hiện tại của
nó, giá trị lớn nhất, nhỏ nhất hay độ rộng của thumb. M odel có thể chịu trách
nhiệm giao tiếp một cách gián tiếp với View và Controller. Gián tiếp có nghĩa
là Model không hề biết các View và Controller của nó - nó không duy trì các
tham chiếu đến chúng. Thay vào đó, Model gửi đi các thông báo đến View và
Controller khi có sự thay đổi trạng thái của hệ thống.
1 .3 .2 . V i e w ( H i ể n t h ị h a y g i a o d i ệ n n g ư ờ i d ù n g )

View liên quan đến việc bạn nhìn thấy các thành phần trên màn hình
như thế nào. Một ví dụ dễ thấy về sự khác nhau giữa các hiển thị, hãy nhìn
vào một ứng dụng cừa sồ (window) trên hai hệ điều hành khác nhau. Hầu hết
các cửa sồ có một thanh tiêu đề nằm ở phía trên. Tuy nhiên, thanh tiêu đề có
thể có một nút close (dấu X) phía bên trái trong hệ điều hành MAC, hoặc có
một nút close (dấu X) phía bên phải trong hệ điều hành W indows.
View xác định việc hiển thị trực quan dữ liệu của Model. View chịu
trách nhiệm cập nhật những thay đồi của nó trên màn hình. View có thể nhận
những thông báo gián tiếp từ Model hoặc các thông điệp từ Controller.
1 .3.3. C o n t r o l l e r ( Đ i ê u k h i ể n h a y Q u ả n l ý c h ứ c n ă n g )

Controler là hành vi của ứng dụng. Nó tập trung việc nhận các yêu cầu
cùa người dùng, chuyển các yêu cầu của người dùng đến chức năng xử lý yêu
cầu của M odel và chuyền kết quả trả về cho View hiển thị.
Controller có thể nhận thông điệp từ View và những thông điệp gián

tiếp từ Model.
Hình dưới chỉ ra M odel, View, C ontroller làm việc với nhau như thế
M ột số công nghệ áp (lụng kiến trúc M odel - View - Controller


16

nào để tạo ra một thanh cuộn (scrollbar). M odel nắm giữ thông tin về giá trị
nhò nhất (min), lớn nhất (max). View xác định chính xác vẽ scrollbar như thế
nào và vẽ ở vị trí nào. Cuối cùng Controller chịu trách nhiệm xử lý các sự
kiện chuột. Kết quả scrollbar mang đầy đủ chức năng của MVC.

View'.
yểàmsi**}
&ãiúwa~ịl&

I

ị

Acte#
íMsứimd
tmtnm
ỂÍ3ÍÌírt t5vj:rè

<

1

1

:
ị

*

Hình 1.3.3. Các thành phần M odel, View, Controller trong thanh cuộn
1.3 .4 . S ự t ư ơ n g t á c g i ữ a c á c t h à n h p h ầ n c ủ a M V C

Trong kiến trúc M V C, M odel chịu trách nhiệm thông báo cho View
biết khi có sự thay đổi và cho phép View có thể lấy các thông tin về trạng thái
và Controller có thể truy cập vào các chức năng của Model. View lấy dừ liệu
từ Model và chịu trách nhiệm hiền thị chúng. Nó tự động cập nhật việc hiển
thị khi có sự thay đổi trong Model. Đồng thời, View cũng làm nhiệm vụ là
chuyển các yêu cầu của người dùng đến Controller. Controller lựa chọn chức
năng xử lý yêu cầu của người dùng và lựa chọn thành phần hiển thị tiếp theo.
Trong các ứng dụng đồ họa, các yêu cầu có thể là các sự kiện bàn phím, chuột
hoặc từ việc lựa chọn các menu. Trong các ứng dụng web, chúng còn là các
yêu cầu HTTP PO ST, G E T ... Controller lựa chọn thành phần hiển thị tiếp
theo dựa vào tương tác của người dùng hoặc dựa vào kết quả xử lý trả về từ
Model.
Một số công nghệ áp dụng kiến trúc Model - Vieyv - Controller


17

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRUNG TAM THONvc» TINTHU VIEN
V “ LO / 6 4 3
'

í

'ế mm ip Evw»s
Hình 1.3.4. Sự tương tác giừa các thành phần của M VC
M ột ứng dụng thông thường sử dụng một bộ điều khiển cho một nhóm
các chức năng liên quan nào đó. M ột số ứng dụng khác có thể sử dụng nhiều
bộ điều khiển độc lập cho mỗi loại người dùng vì có thể có nhiều View khác
nhau úng với mỗi loại người dùng khác nhau.
1 .3.5. M ộ t s ó đ ặ c đ i ể m c ơ b ả n c ù a M V C

Một điều dễ nhận ra là các View thường xuyên được thay đổi theo
thời gian cho phù hợp với từng loại người dùng, trong khi M odel thì lại rất ít
khi thay đổi. Do đó, việc phân tách giữa M odel và View giữ cho Model không
bị thay đồi khi viết lại giao diện. Hơn nữa, hoạt động cùa mỗi chức năng trong
hệ thống thường là phức tạp và khó hiểu cho tới khâu thực thi cuối cùng. Vì
thế, trong một số dự án, các View có thể được thiết kế ngay trong các khâu
đầu tiên của quá trình thiết kế còn M odel sẽ được hoàn thiện dần trong suốt
quá trình phát triển.
Mặc dù M odel và Controller là hai khái niệm riêng rẽ trong kiến trúc
MVC nhưng thực tế chúng lại có mối quan hệ rất chặt chẽ. Mồi thay đổi liên
Một số công nghệ áp dụng kiến trúc Model - View - Controller


18

quan đến Model sẽ tạo ra một thay đổi tương ứng đến Controller.
Kiến trúc M V C cho phép một ứng dựng có thể được xây dựng trên
nhiều ngôn ngữ lập trình khác nhau. Do M odel và Controller là độc lập với
View nên View chỉ cần thông báo cho Controller các sự kiện người dùng và

cập nhật nhũng thay đổi của Model.

1.4. Một số các mẫu thiết kế trong MVC
M VC là một mầu thiết kế tổng hợp được cấu thành từ nhiều mẫu thiết
kế cơ bản: View áp dụng mẫu C om positePattem kết hợp với D ecoratorPattem
để xây dựng thành phần hiển thị, giao tiếp giữa View và Model sừ dụng mẫu
O bserverPattem ; Controller sử dụng mẫu StrategyPattem đề phân phối các
yêu cầu của người dùng cho các chức năng của Model; M odel sử dụng
M ediatorPattem để quản lý các đối tượng trong hệ thống; View sử dụng
A dapterPattem để chuyển giao diện của M odel sang một giao diện chuẩn mà
View có thể hiểu được; Ngoài ra M VC còn sử dụng rất nhiều các mẫu thiết kế
khác để hỗ trợ quá trình xây dựng cũng như liên kết các thành phần Model,
View, C ontroller...
1 .4 .1 . C o m p o s i t e P a t t e r n

Trong một hệ thống, mỗi thành phần có thể là một đối tượng độc lập
hoặc một tập các đối tượng. Com posite Pattern thường được sử dụng để xây
dựng các cấu trúc dữ liệu hình cây. Tóm tại, Com posite Pattern là một tập hợp
các đối tượng mà bất kỳ một đối tượng con nào của nó lại có thể là một
C om positePattem hoặc là một đối tượng cơ sở. Với khái niệm cây, một số đối
tượng được gọi là các "điểm nút" (node) và một số khác được gọi là "lá"
(leaf).
Vấn đề ở đây là xác định được một giao diện duy nhất để có thể dề
dàng truy cập vào các đối tượng trong cây đồng thời đảm bảo việc phân biệt
Một số công nghệ áp dụng kiến trúc Model - View - Controller


19

được các điểm nút và lá. Điểm nút là đối tượng chứa các đối tượng con (các

nút khác hoặc lá) và các con có thể được xóa bỏ hoặc thêm vào nút hiện thời.
Lá là các đối tượng không chứa các đối tượng con.
Một số tác giả đưa ra giải pháp phân tách giữa nút và lá bằng cách xây
dựng các phương thức khác nhau cho các đối tượng nút và lá. Trong đó, các
đối tượng lá có thể có các phương thức như:
public String getNameO; //Lây tên đối tượng
public String getValueO; //Lấy giá trị đối tượng

và các đối tượng nút có thêm các phương thức như:
public Enumeration elemer»ts(); //Lấy danh sách các con cúa nút
public Node getChild(String nodeName); //Lấy một con nào đó
public void add(Object obj); //Bố sung một con
public void remove(Object obj); //Loại bỏ một con

Tuy nhiên, m ột cách tiếp cận khác được khuyên dùng là coi tất cả các
đối tượng trong cây đều là các Composite Pattern. Khi đó sẽ có một giao diện
duy nhất cho tất cà các đối tượng. Bằng việc sử dụng phương thức elements(),
có thể dễ dàng xác định được đổi tượng nào là nút (nếu trà về một danh sách
các đối tượng con) và đối tượng nào là lá (trả về một danh sách rỗng).
Một ứng dụng thông thường đòi hỏi các trang màn hình hiển thị phải
có một bố cục thống nhất được gọi là template. Template là một thành phần
hiển thị được tồng hợp từ nhiều thành phần hiển thị nhỏ hơn theo một cách bố
trí nhất định. M ồi thành phần hiển thị nhỏ hơn như phần tiêu đề trang, các
menu, phần nội dung hay phần cuối của một trang là các thành phần độc lập.
Chúng có thể là một thành phần đơn lẻ hoặc bao gồm các thành phần hiền thị
nhổ hơn.
Việc sử dụng các template trong thiết kế ứng dụng làm cho việc bào
trì trở nên dề dàng hơn. Việc thay đổi bố cục của tem plate sẽ làm thay đổi bố
cục của tất cả các trang màn hình áp dụng tem plate đó. Hơn thế, các thành
Một số công nghệ áp dụng kiến trúc Model - Vieìv —Controller

20

phần hiển thị được chia nhỏ thành các thành phần hiền thị nhỏ hơn, mồi thành
phần hiển thị nhò hơn này được gọi đến bàng cách tham chiếu. Vì thế, việc
thay đổi một thành phần hiển thị đồng nghĩa với việc thay đổi tên tham chiếu
(tên file nguồn, hay đường dẫn) của nó trong thành phần hiển thị lớn hơn. [1]
Trong kiến trúc M V C, thành phần View được xây dựng trên mẫu thiết
kế Composite Pattern kết hợp với mẫu D ecorator Pattern.
1.4.2. O b s e r v e r P a t t e r n

Trong the giới phức tạp của các ứng dụng window, chúng ta thường
mong muốn tại một thời điềm xác định có thể có nhiều kiểu hiển thị khác
nhau cho cùng một nội dung dữ liệu và tất cả các thể hiện đó đều có thề phản
ánh được những thay đổi bên trong nội dung cùa dừ liệu đó. Ví dụ, khi mô tả
các thay đổi về giá cả hàng hóa bán ra bầng cả hình ảnh lẫn bảng báo cáo.
Mỗi lần giá cả thay đổi, chúng ta mong muốn cả hai trình diễn đều cùng tự
động thể hiện thay sự thay đổi đó.

cmnvrẬ
ếmmtằ \

C o n tro lle r

Hình 1.4.2. C ác cách hiển thị khác nhau của cùng một dữ liệu
O bserverPattem già sử đối tượng chứa dữ liệu là độc lập với đối tượng
hiển thị và đối tượng hiển thị sẽ theo dối các thay đồi của đối tượng chứa dừ
liệu.
Một số công nghệ áp dụng kiến trúc Model - View —Controller

21

Gọi đối tượng mang dữ liệu là các Subject (M odel) và đối tượng hiền
thị là các O bserver (View). Mỗi một Observer đăng ký theo dõi một Subject
bầng cách gọi một hàm công khai (public) của Subject. Khi đó, mỗi Observer
cần một giao diện để Subject gọi khi dữ liệu thay đổi.
abstract interface Observer{
//Gửi thông báo cho các Observer biết đã có sự thay đối
public void sendNotify(String s);
>
abstract interface Subject{
//Đăng ký theo dõi với Subject
public void registerInterest(Observer obj);
}

Để có thể theo dõi đối tượng Subject, mỗi Observer cần đăng ký với
Subject bằng cách gọi hàm registerlnterest của Subject. Khi có các sự kiện
làm thay đổi dữ liệu, Subject sẽ gọi phương thức sendNotify của Observer và
Observer sẽ tự động thay đồi các hiền thị của mình.
Trong kiến trúc M VC, việc giao tiếp giữa M odel và View sử dụng
mẫu thiết kế O bserver Pattem . Model đóng vai trò là đối tượng mang dữ liệu
(Subject) và View đóng vai trò là đối tượng hiền thị (Observer). Model chịu
trách nhiệm thông báo cho View biết khi có sự thay đổi và cung cấp khả năng
cho phép View có thể lấy các thông tin về trạng thái cùa hệ thống. View lấy
dừ liệu từ M odel và chịu trách nhiệm hiển thị các nội dung đó. Nó tự cập nhật
việc hiển thị khi có sự thay đổi trong mô hình. [1 ] [2] [3] [4]
1.4.3. S t r a t e g y P a t t e r n

Strategy Pattern bao gồm một tập các thuật toán được bao gói trong
một lớp điều khiển được gọi là Context. Chương trình client có thề lựa chọn
một trong những thuật toán đó, đôi khi Context tự lựa chọn thuật toán tốt nhất
cho client. M ục đích của Strategy Pattern là chuyển đổi các thuật toán một
cách dễ dàng m à không cần sử dụng các câu lệnh điều khiển. Tại một thời
Một số công nghệ áp dụng kiến trúc Model - VieìV - Controller


22

điểm chỉ có một thuật toán được lựa chọn. Các thuật toán trong Strategy
Pattern nhiều hay ít đều cùng giải quyết một vấn đề.
Có thề có nhiều thuật toán để xử lý m ột chức năng cùa một chương
trình. Chương trình có thể lựa chọn một trong số các thuật toán này dựa vào
tính hiệu quả của chúng hoặc do người dùng lựa chọn. Các thuật toán này có
thể được thêm vào, bớt đi hay thay đổi tại bất kỳ thời điểm nào. Strategy
Pattern cho phép lựa chọn động một trong các thuật toán đó.
Một sổ trường hợp có thể có các lựa chọn làm cùng một việc bầng
nhiều cách thức khác nhau như:
- Lưu file trong các định dạng khác nhau.
- N én file sử dụng các thuật toán khác nhau.

- Thu video bàng các định dạng khác nhau.
- Sử dụng các chiến lược ngắt dòng khác nhau đế hiển thị văn bản.
- Biểu diễn cùng một dữ liệu bằng nhiều định dạng khác nhau như:
biểu đồ đường thẳng, biểu

đ ồ

hình tròn ...

Trong mồi trường hợp, chương trình sẽ yêu cầu Context lựa chọn một
trong các thuật toán để thực hiện.
Ỷ tường đằng sau Strategy Pattern là bao gói nhiều chiến lược khác
nhau và cung cấp m ột giao diện đơn giàn cho phép chọn lựa một trong những
chiến lược đó. Các chiến lược có cùng một giao diện chương trình, tuy nhiên
mỗi thành phần của nó không cần có cùng cấu trúc.
Già sừ cần xây dựng một chương trình sắp xếp các số tự nhiên bằng
các thuật toán khác nhau như: Q uicksort, Shell Sort, M ergeSort, các thuật toán
này có thể được lựa chọn một cách ngầu nhiên. Khi đó, sử dụng Strategy
Pattern bằng cách xây dựng các đối tượng sau đây:
Một số công nghệ áp dụng kiến trúc Model - View - Controller


23

- SortStrategy (Strategy): Mô tà một giao diện chung cho tất cả các
thuật toán. Đối tượng SortList (Context) sê sử dụng giao diện này để gọi một
thuật toán xác định được định nghĩa trong các đối tượng thực thi.
- QuickSort, ShellSort, M ergeSort (Concrete Strategy): Là các đối
tượng cụ thể thực thi giao diện SortStrategy.
- SortList (Context): Tham chiếu đến SortStrategy và gọi một trong
các đối tượng cụ thể thực thi các thuật toán QuickSort, ShellSort, MergeSort.
SortList chứa một thể hiện biến của SortStrategy. SortList cũng có thể định
nghĩa một giao diện cho phép SortStrategy có thể truy cập vào dừ liệu cùa
mình.
Khi thực thi chương trình, SortList sẽ khởi tạo biến thể hiện của
SortStrategy trong nó bằng một trong các đối tượng cụ thể như QuickSort,
ShellSort, M ergeShort. Và sau đó gọi các phương thức thực thi của các đối
tượng cụ thể đó. N hư vậy, một trong các thuật toán (QuickSort, ShellSort,

M ergeSort) có thể được thực hiện trong lúc chương trình đang chạy, tùy thuộc
vào lựa chọn cùa người dùng hay việc tính toán hiệu quả cùa hệ thống. [1]
1 .4.4. A d a p t e r P a t t e r n

Apdapter Pattem được sử dụng để chuyền đồi giao diện của một đối
tượng này sang một giao diện khác mà Client có thể hiểu được. Sử dụng
Apdater Pattem trong trường hợp muốn ghép nối các đối tượng có các giao
diện khác nhau bằng cách tạo ra một đối tượng mới có giao diện thích hợp,
sau đó liên kết với các đối tượng liên quan.
Có hai cách đề làm việc này là kế thừa và liên kết. Cách thứ nhất, tạo
ra một đối tượng mới kế thừa đối tượng cần chuyển giao diện, sau đó thêm
các phương thức cần thiết để có thể chuyển nó sang giao diện mong muốn.
Cách thứ hai, tạo ra m ột đối tượng mới chứa một biến thể hiện cùa đối tượng
Một số công nghệ áp dụng kiến trúc Model - View - Controlỉer


24

cần chuyển giao diện, sau đó xây dựng các phương thức đề chuyển các lời gọi
đến đối tượng cũ thông qua giao diện của đối tượng mới.
Adapter Pattern tập trung vào giải quyết sự tương thích giữa hai giao
diện đang tồn tại, giàm công sức viết lại m ã lệnh xuống một mức tối thiểu có
thể được. A dapter Pattern hướng tới việc tái sử dụng các giao diện có sẵn và
chỉ thực sự cần thiết khi mọi thứ đã được xây dựng từ trước. Adapter Pattern
được ứng dụng trong các trường hợp sau:
- Cần tích họp một vài mô đun vào chương trình.
- Không thể sát nhập trực tiếp mô đun vào chương trình.
- Mô đun đang tồn tại không có giao diện như mong muốn: cần nhiều
các phương thức hơn cho mô đun đó hoặc một số phương thức cần phải viết
lại (chồng phương thức). [1] [2] [3] [4]

Trong kiến trúc M VC, View thường sừ dụng Adapter Pattern để
chuyển Model sang một giao diện chuần mà View có thể sử dụng được.
1.4.5. C o m m a n d P a t t e r n

Khi xây dựng một ứng dụng cần cung cấp một danh sách các menu
lựa chọn các chức năng như m ở file, thoát hay thay đổi màu nền... M ỗi khi
người dùng lựa chọn một chức năng, chương trình sẽ gọi một hàm xử lý
tương ứng bằng m ột cấu trúc điều khiển như sau:
public void action Performed(ActionEvent e) {
Object obj = e.getSourceO;
if(obj == mnuOpen) fi!eOpen();//mở file
if(obj == mnuExit) exitClicked();//thoát chương trình
if (obj == btnRed) redClicked();//chuyển màn màu đỏ
}

Với một số ít các menu thì chương trình có thể chạy rất tốt. Tuy nhiên,
khi có rất nhiều các menu và nút bấm, phương thức actionPerformed sẽ trở
Một số công nghệ áp dụng kiến trúc Model — View —Controller


25

nên cồng kềnh. Hơn nữa, các ngôn ngữ lập trình hướng đối tượng thường cố
gang tránh sử dụng một dãy các câu lệnh điều khiển để quyết định đổi tượng
nào được lựa chọn.
Command Pattern tập trung vào giải quyết vấn đề đó bằng cách chẳn
chắn rằng các đối tượng sẽ luôn nhận trực tiếp các lệnh. Command Pattern
thực hiện việc bao gói một chức năng cùa ứng dụng trong một đối tượng. Đối
tượng này thực thi một giao diện cho phép giao tiếp với các chương trình
client, ứ n g dụng sẽ thực hiện các chức năng thông qua lời gọi hàm trên giao

diện đó. Các client không biết gì về hoạt động bên trong đối tượng và các thay
đổi bên trong đối tượng cũng không ảnh hưởng tới các chương trình phía
client.
Để chắc chắn mỗi đối tượng sẽ nhận đúng lệnh ứng dụng yêu cầu,
chúng ta sử dụng một đối tượng tên là Command, đổi tượng này luôn chứa
phương thức Execute như sau:
public interface Command{
public void ExecuteO;
>

Bây giờ, phương thức actionPerformed trở thành:
public void actionPerformed(ActionEvent e) {
Command cmd = (Command) e.getSourceO;
cmd.ExecuteO;
>

Sau đó, xây dựng phương thức Execute cho mỗi đối tượng xử lý các
chức năng mong đợi. Khi đó, chỉ cần quan tâm đến chức năng của đối tượng
chửa chức năng đó mà bỏ qua thành phần chương trình thực hiện việc lựa
chọn quyết định.
M ột mục đích quan trọng nữa của Command Pattern là phân tách
chương trình khỏi giao diện sử dụng. Nói cách khác, các đối tượng chương
Một sổ công nghệ áp dụng kiến trúc Model - View —Controller