MỤC LỤC

BẢNG CHỮ VIẾT TẮT 5

DANH MỤC CÁC HÌNH VẼ VÀ ðỒ THỊ 6

MỞ ðẦU 9

1. Cơ sở khoa học và thực tiễn của ñề tài: 9

2. Mục tiêu và phạm vi nghiên cứu của luận văn 11

3. Nội dung nghiên cứu và thực hiện của luận văn 11

4. Tóm tắt cấu trúc của luận văn 12

CHƯƠNG 1 13

TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI 13

1.1. Giới thiệu chung 13

1.2. Tổng quan về các mẫu thiết kế 13

1.2.1. Mẫu thiết kế là gì ? 13

1.2.1.1. Các ñịnh nghĩa về mẫu thiết kế [4,9] 13


- 2 -

TỔNG QUAN VỀ HỆ THỐNG HOẠCH ðỊNH NGUỒN LỰC DOANH NGHIỆP -
ERP 36

2.1. Lịch sử hình thành 36

2.2. ERM- Sự tích hợp ERP và Nghiệp vụ sản xuất kinh doanh 40

2.3. Lợi ích của danh nghiệp khi sử dụng ERP 43

2.3.1 Tiếp cận thông tin quản trị ñáng tin cậy 43

2.3.2 Công tác kế toán chính xác hơn 43

2.3.3 Cải tiến quản lý hàng tồn kho 43

2.3.4 Tăng hiệu quả sản xuất 43

2.3.5 Quản lý nhân sự hiệu quả hơn 44

2.3.6 Các qui trình kinh doanh ñược xác ñịnh rõ ràng hơn 44

CHƯƠNG 3 45

ỨNG DỤNG CÁC MẪU THIẾT KẾ ðỂ XÂY DỰNG CÁC PHÂN HỆ TRONG HỆ
THỐNG QUẢN LÝ DOANH NGHIỆP 45

3.1. Phân hệ chính: Các lớp cơ sở, quản lý bảo mật, báo cáo. 45



3.2.3.4. Các yêu cầu của phân hệ quản lý mua bán vật tư-nguyên liệu80

3.2.3.5. Các chức năng của Phân hệ quản lý mua bán vật tư-nguyên
liệu 80

3.2.3.6. Từ ñiển dữ liệu và mô hình lĩnh vực nghiệp vụ 81

3.2.4. ðặc tả hệ thống 83

3.2.4.1. Các tác nhân của hệ thống 83

3.2.4.2. Các ca sử dụng tiêu biểu của hệ thống 85

3.2.4.3. Mô hình ca sử dụng tổng thể 88

3.2.4.4. Mô tả chi tiết các ca sử dụng 89

3.2.5. Phân tích hệ thống 95

3.2.5.1. Phân tích các ca sử dụng 95

3.2.5.1. Phân tích các lớp 101

3.2.6. Thiết kế hệ thống 105

3.2.6.1. Kiến trúc vật lý của ứng dụng 105

3.2.6.2. Xác ñịnh các gói thiết kế 106


Tài liệu tiếng Việt 117

Tài liệu tiếng Anh 117

Các trang Web 118

Bộ công cụ 118 BẢNG CHỮ VIẾT TẮT
Chữ viết tắt Tên ñầy ñủ
APICS American Production and Inventory Control Society
BOM Bill of Materials
CSDL Cơ Sở Dữ Liệu
ERP Enterprise Resource Planning
ERM Enterprise Resource Management
GOF Gang Of Four
GUI Graphic User Interface
MRP Material Requirements Planning
MRP II Manufacturing Resource Planning
NCC Nhà cung cấp
SQL Strured-Query Languague
VT-NL Vật tư- Nguyên liệu DANH MỤC CÁC HÌNH VẼ VÀ ðỒ THỊ
Hình 1.1: Sơ ñồ mối quan hệ giữa các mẫu thiết kế 17


Hình 2.2 ERM – Sự tích hợp ERP và nghiệp vụ 41

Hình 2.3 ðịnh nghĩa mô hình ERM. 42

Hình 3.1. Kiến trúc hệ thống dựa trên mẫu MVC 47

Hình 3.2. Kiến trúc các lớp giao tiếp CSDL sử dụng mẫu thiết kế 48

Hình 3.3. Sử dụng Table Definition ñể giảm thiểu thay ñổi. 50

Hình 3.4. Cấu trúc các phân lớp quản lý các gói của mỗi Phân hệ trong hệ thống 51

Hình 3.5. Lược ñồ lớp xử lý dữ liệu của ñối tượng Nhân viên. 53

Hình 3.6. Quá trình ñăng nhập hệ thống. 54

Hình 3.7. Mô hình tổng thể các ca sử dụng liên quan ñến bảo mật. 54

Hình 3.8. Các lớp thực thi ca sử dụng ðăng nhập 59

Hình 3.9. Biểu ñồ cộng tác ca sử dụng ðăng nhập. 60

Hình 3.10. Các lớp thực thi ca sử dụng ðổi mật khẩu. 60

Hình 3.11. Biểu ñồ cộng tác ca sử dụng ðổi mật khẩu 61

Hình 3.12. Các lớp trong ca sử dụng Cập nhật nhóm quyền 61

Hình 3.13. Biểu ñồ cộng tác ca sử dụng Cập nhật nhóm quyền. 62

Hình 3.27. Các lớp thiết kế trong ca sử dụng cập nhật nhóm bảng áp dụng mẫu 73

Hình 3.28. Các lớp thiết kế trong ca sử dụng Cập nhật bảng 73

Hình 3.29. Các lớp thiết kế trong ca sử dụng Cập nhật bảng áp dụng mẫu 73

Hình 3.30. Kiến trúc lớp của phần Quản lý cấu trúc bảng 74

Hình 3.31. Mô hình phân cấp quản lý trong doanh nghiệp 76

Hình 3.32: Sơ ñồ tiến trình quản lý mua bán VT-NL 79

Hình 3.33: Mô hình khái niệm của chức năng Quản lý mua bán VT-NL 83

Hình 3.34: Mô hình ca sử dụng tổng thể của Phân hệ Quản lý mua bán VT-NL 88

Hình 3.35: Các lớp thực thi ca sử dụng Lập phiếu yêu cầu mua 95

Hình 3.36: Biểu ñồ cộng tác các lớp ca sử dụng Lập phiếu yêu cầu mua 96

Hình 3.37: Các lớp thực thi ca sử dụng Lập yêu cầu báo giá 96

Hình 3.38: Biểu ñồ cộng tác các lớp ca sử dụng Lập yêu cầu báo giá 97

Hình 3.39: Các lớp thực thi ca sử dụng Lập yêu cầu ñặt hàng 97

Hình 3.40: Biểu ñồ cộng tác các lớp ca sử dụng Lập yêu cầu ñặt hàng 98

Hình 3.41: Các lớp phân tích thực thi ca sử dụng Lập phiếu Nhận hàng 98


a. Cơ sở khoa học và ý nghĩa thực tiễn của việc nghiên cứu và ứng dụng các mô
hình sử dụng lại vào quá trình thiết kế phần mềm:
Một trong những giải pháp ñể nâng cao năng suất của quá trình phát triển phần
mềm là xây dựng những giải pháp ñể có thể sử dụng lại trong các bước tiếp theo hoặc
trong các dự án phần mềm khác. Sự ra ñời của những giải pháp hướng ñối tượng mà
chủ yếu là phân tích thiết kế và lập trình hượng ñối tượng ñã ñem lại những bước tiến
ñáng kể. Trong ñó, thiết kế hướng ñối tượng ñóng vai trò ñịnh hướng và quyết ñịnh
ñến việc sử dụng lại những tài nguyên trong quá trình phát triển phần mềm.
Thiết kế hướng ñối tượng cho phép chúng ta theo dõi và quản lý ñược sự phụ
thuộc giữa các mô ñun trong kiến trúc của hệ thống. Tuy nhiên, thiết kế một phần mềm
hướng ñối tượng ñã khó, việc thiết kế phần mềm hướng ñối tượng với các thành phần
có thể sử dụng lại thậm chí còn khó hơn nhiều. Trước tiên, cần phải tìm ra các ñối
tượng thật chính xác, thể hiện chúng dưới các lớp ñối tượng với mức ñộ trừu tượng
phù hợp. ðồng thời, ta cũng cần chỉ ra ñược sơ ñồ thừa kế, mối liên hệ và giao tiếp của
những ñối tượng này. Những yêu cầu trên cần thiết kế ñể ñáp ứng ñược yêu cầu của
bài toán hiện tại song cũng cần có tính tổng quát và linh hoạt ñủ ñể có thể giải quyết
một phần hoặc toàn bộ các bài toán có thể gặp trong tương lai.
Một kinh nghiệm thường ñược áp dụng trong quá trình thiết kế là không tìm cách
giải quyết mọi vấn ñề bằng những thành phần căn bản. Thay vào ñó, ta cần tìm cách áp
dụng những mô hình ñã thành công trong thực tế ñối với một số bài toán tương tự ñã
từng gặp. Một khi mô hình giải quyết ñã ñủ hoàn thiện, nó có thể ñược sử dụng lại
nhiều lần trong những lớp bài toán với yêu cầu nhất ñịnh. Khi ñó, người thiết kế khi
gặp một bài toàn nào ñó, qua xem xét ñể xác ñịnh ñược lớp bài toán, họ có thể tìm ra
ñược mô hình thiết kế phù hợp và áp dụng ngay những mô hình ñó vào thiết kế của
mình mà không cần phải xem xét lại từ ñầu.
Việc nghiên cứu và ứng dụng các mô hình sử dụng lại vào quá trình thiết kế phần
mềm là một bước tiếp cận mới trong khâu phân tích và thiết kế phần mềm hướng ñối
tượng. Việc áp dụng các mô hình sử dụng lại vào quá trình thiết kế làm giảm thiểu thời
gian và chi phí ñể thiết kế phần mềm, nâng cao khả năng ứng dụng và mở rộng phát
triển trong tương lai của phần mềm ứng dụng. Thiết kế phần mềm là một trong những

tích thiết kế phần mềm, luận văn ñã chọn ñề tài với tên gọi “Nghiên cứu các mẫu thiết
kế và ứng dụng ñể xây dựng Hệ thống Quản lý thông tin tổng thể doanh nghiệp”.
Mục tiêu của bài toán “Xây dựng Hệ thống Quản lý thông tin tổng thể cho doanh
nghiệp” là xây dựng một hệ thống quản lý thông tin bao gồm nhiều Phân hệ. Mỗi một
Phân hệ giải quyết ñược chọn vẹn một hay một số yêu cầu của bài toán nghiệp vụ-
quản lý thông tin của doanh nghiệp.
Hệ thống ñược xây dựng sử dụng các công nghệ kỹ thuật mới như: ứng dụng
hướng tiếp cận áp dụng các mẫu thiết kế, sử dụng công cụ mô hình hoá UML ñể phân
tích và thiết kế bài toán theo mô hình hướng ñối tượng; ứng dụng công nghệ ứng dụng
- 11 -

chủ-khách (COM+) ñể cập nhật và xử lý thông tin. ðồng thời hệ thống cũng ñược thiết
kế ñể có thể chạy ñược cả trên nền Web lẫn desktop application.
Với hướng tiếp cận phân tích và thiết kế hệ thống áp dụng công nghệ hướng ñối
tượng sử dụng các mẫu thiết kế, và sử dụng công nghệ .NET của Microsoft ñể xây
dựng và phát triển hệ thống, cho phép hệ thống dễ bảo trì và phát triển mở rộng trong
tương lai ñáp ứng ñược các yêu cầu thay ñổi và phát triển ngày càng cao của xã hội.
Hệ thống ñược xây dựng hoàn toàn khả thi khi ñược áp dụng vào các tổ chức và doanh
nghiệp có kết nối mạng máy tính.
2. Mục tiêu và phạm vi nghiên cứu của luận văn
– Nghiên cứu các mô hình sử dụng lại và nắm bắt ñược mục tiêu, ý nghĩa và
cách thức, tình huống áp dụng các mô hình sử dụng lại vào giải quyết các vấn
ñề cụ thể. Qua ñó, tổng hợp lại một số mẫu ñiển hình về hành vi và trình diễn,
và một số mẫu tiêu biểu ứng dụng trong các hệ thống quản lý doanh nghiệp.
– Nắm bắt ñược phương pháp phân tích thiết kế hướng ñối tượng một hệ thống.
Sử dụng phương pháp phân tích thiết kế hướng ñối tượng, áp dụng các mẫu
thiết kế ñể phân tích, thiết kế hệ thống quản lý thông tin tổng thể cho các
doanh nghiệp.
– Từ kết quả phân tích và thiết kế tiến hành xây dựng hệ thống dựa trên các
công cụ và môi trường ñã lựa chọn.

dựng một số Phân hệ trong hệ thống Quản lý thông tin tổng thể cho doanh nghiệp.
CHƯƠNG 4: Cài ñặt
Chương này nêu các yêu cầu và môi trường cài ñặt, triển khai hệ thống. Giới
thiệu một số chức năng chính và ñưa ra một số màn hình nhập liệu, báo cáo của
chương trình. Khả năng triển khai áp dụng chương trình trong thực tiễn.
KẾT LUẬN: Phần này nêu kết quả ñạt ñược của luận văn và ñề xuất phương
hướng nâng cấp và mở rộng ứng dụng ñề tài vào thực tiễn trong tương lai.
CHƯƠNG 1
TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI
1.1. Giới thiệu chung
Thiết kế phần mềm là một công ñoạn quan trọng trong quy trình xây dựng và
phát triển phần mềm. Cũng như việc thiết kế phần mềm truyền thống, việc thiết kế
phần mềm hướng ñối tượng cần phải ñáp ứng ñược yêu cầu của bài toán, song cũng
cần có tính tổng quát và linh hoạt ñủ ñể có thể giải quyết một phần hoặc toàn bộ các
bài toán có thể gặp trong tương lai.
Trong quá trình xây dựng và phát triển phần mềm, các thay ñổi do yêu cầu từ
phía khách hàng, các ñiều kiện phát sinh hay việc thiết kế một cách cứng nhắc trong
quá trình thiết kế thường làm cho hệ thống trở nên rối rắm, các mô ñun càng ngày càng
bị phụ thuộc vào nhau. Sự phụ thuộc này làm cho phần mềm ngày càng trở nên phình
to và khó bảo trì, thậm chí dẫn ñến thất bại.
Phương pháp lập trình hướng ñối tượng ra ñời góp phần giúp cho việc thiết kế
phần mềm trở nên dễ dàng và linh ñộng hơn. Thiết kế hướng ñối tượng cho phép theo
dõi và quản lý ñược sự phụ thuộc giữa các mô ñun trong kiến trúc của hệ thống.
Việc tìm cách áp dụng những mô hình ñã thành công trong thực tế ñối với một số
bài toán tương tự ñã từng gặp và áp dụng những mô hình ñó vào thiết kế của mình mà
không cần phải xem xét lại từ ñầu, ñảm bảo tiết kiệm chí phí, thời gian xây dựng và
phát triển phần mềm, nâng cao ñộ tinh cậy và chất lượng phần mềm.
Năm 1995, Erich Gamma, Richard Helm, Join Vlissides, và Ralph Johnson
(Gang of Four - GOF) ñã công bố cuốn sách của họ “Elements of reusable Object-
Oriented Software” ñánh dấu sự ra ñời của “Mẫu thiết kế”. ðây là một bước tiến vô

pháp một cách ngắn gọ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ế “Façade”, ta hình dung ngay ñến mô
hình thiết kế một ñối tượng với vai trò giao dịch của một tập các thành phần nhỏ
hơn.
 Bài toán: Cho phép xác ñịnh trong trường hợp nào thì áp dụng mẫu thiết kế
thông qua mô tả bài toán và ngữ cảnh của bài toán ñó.
 Giải pháp giải quyết bài toán: Mô tả những thành phần tạo nên mẫu thiết kế
(các lớp, các ñối tượng) cùng mối quan hệ, vai trò và cách thức phối hợp giữa
chúng (cấu trúc, thừa kế). 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.
- 15 -

Ví dụ như mẫu thiết kế ñược gọi như một thành ngữ (mẫu GRASP), mẫu thiết kế
có thể mô tả bằng lời hoặc mô hình thiết kế hay bằng mã nguồn.
 Hệ quả: Là những gì thu nhận ñược cùng với những yếu tố cần cân nhắc khi áp
dụng mẫu thiết kế ñể giải quyết bài toán. Hệ quả thường không ñược ñề cập khi
nói ñến một mẫu thiết kế nhưng ñây là yếu tố quyết ñịnh khi cần chọn lựa hoặc
phân tích chi phí và lợi ích khi áp dụng các mẫu thiết kế.
1.2.2. Danh mục các mẫu thiết kế và phân loại [9]
Erich Gamma và các ñồng sự của ông ñề xuất 23 mẫu thiết kế, và ñã ñưa ra hai
tiêu chí ñể phân loại các mẫu thiết kế này. ðó là phân loại theo mục ñích sử dụng
(purpose) và phạm vi áp dụng của mẫu (scope).
a. Theo mục ñích sử dụng: Các mẫu thiết kế ñược phân thành 3 nhóm: mẫu
kiến tạo, mẫu cấu trúc, mẫu hành vi.
 Mẫu kiến tạo (Creational Patterns): mẫu kiến tạo trừu tượng hoá quá trình khởi
tạo ñối tượng. 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.
 Mẫu thiết kế kiến tạo bao gồm các mẫu sau: Abstract Factory, Builder, Factory

Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor. - 17 -

1.2.3. Sơ ñồ mối quan hệ giữa các mẫu thiết kế [9]

Hình 1.1: Sơ ñồ mối quan hệ giữa các mẫu thiết kế
1.3. Một số mẫu thiết kế ñiển hình trong các ứng dụng quản lý.
Với phạm vi thực hiện của luận văn, phần này chỉ tổng hợp và giới thiệu một số
mẫu thiết kế ñiển hình về hành vi và trình diễn hay ñược dùng trong các ứng dụng
quản lý doanh nghiệp như là các mẫu thiết kế dành cho lý luận nghiệp vụ (domain
logic) hoặc các mẫu về hành vi quan hệ của các ñối tượng hoặc cấu trúc quan hệ của
các ñối tượng.
- 18 -

1.3.1. Mẫu Quan sát
1.3.1.1. Ý nghĩa

ðối tượng ConcreteSubject sẽ gửi thông báo tới các ñối tượng Observer của nó bất
cứ khi nào có sự thay ñổi trạng thái của các ñối tượng Observer.
Sau khi xác nhận sự thay ñổi trong ñối tượng ConcreteSubject, ñối tượng
ConcreteObserver có thể truy vấn thông tin của các ñối tượng Observer. ðối tượng
ConcreteObserver sử dụng thông tin này ñể ñồng bộ trạng thái của nó với các ñối tượng
Observer ñó.

Hình 1.3: Biểu ñồ cộng tác của mẫu Observer
1.3.1.5. Các tình huống áp dụng
Mẫu Observer thường ñược áp dụng khi: Ứng dụng có mối quan hệ phụ thuộc,
ñối tượng này phụ thuộc vào ñối tượng kia. Hoặc khi một sự thay ñổi ở ñối tượng này
dẫn ñến sự thay ñổi ở ñối tượng khác và chúng ta không biết chính xác có bao nhiêu
ñối tượng phải thay ñổi theo
1.3.1.6. Thuận lợi và hạn chế
Mẫu Observer giúp chúng ta sử dụng các ñối tượng chủ thể (Subject) và các ñối
tượng phụ thuộc vào trạng thái của nó (Observer) một cách ñộc lập.
Chúng ta có thể sử dụng lại những ñối tượng chủ thể Subject mà không phải sử
dụng lại các ñối tượng phụ thuộc trạng thái Observer của nó và ngược lại.
- 20 -

Chúng ta có thể thêm vào một hoặc nhiều ñối tượng phụ thuộc trạng thái
(Observer) mà không phải sửa ñổi lại ñối tượng chủ thể Subject hoặc các ñối tượng
Observer phụ thuộc trạng thái khác.
1.3.2. Mẫu Thực hiện lệnh
1.3.2.1. Ý nghĩa
Mẫu Thực hiện lệnh (Command) dùng ñể ñóng gói các yêu cầu khác nhau thành
từng ñối tượng thực hiện lệnh riêng biệt, do ñó cho phép tham số hoá các tác vụ từ
client với ñối tượng thực hiện lệnh khác nhau, ñưa vào hàng ñợi hoặc tệp tin sổ ghi
(log file) các yêu cầu, hỗ trợ việc phục hồi các tác vụ ñã thực hiện.
1.3.2.2. Mô tả

hiện lại lệnh tương ứng. ðể làm ñược ñiều này, trong lớp ConcreteCommand (kế thừa từ
lớp Command) phải xây dựng sẵn chức năng Phục hồi của chính nó. Khi ñó, một tập
hợp các lệnh ñã ñược thực hiện sẽ ñược Phục hồi bằng chức năng Thực hiện lại của
từng lệnh chứa trong nó.
1.3.2.6. Thuận lợi và hạn chế
Có thể dễ dàng thêm mới một Lệnh bởi vì chúng ta không phải sửa lại những lớp
cũ. Có thể tập hợp các Lệnh khác nhau lại thành một Lệnh tổng hợp.
Các ñối tượng Command có thể ñược xử lý và kế thừa giống như các ñối tượng
khác - 22 -

1.3.3. Mẫu Trạng thái
1.3.3.2. Ý nghĩa
Mẫu Trạng thái (State) cho phép ñối tượng có thể tự ñiều chỉnh hành vi khi trạng
thái của nó thay ñổi (hành vi của ñối tượng phụ thuộc vào trạng thái của nó).
1.3.3.2. Mô tả
Mẫu này dùng ñể mô tả làm thế nào ñối tượng có thể tự ñưa ra các ứng xử khác
nhau tương ứng với mỗi trạng thái vào thời ñiểm chạy.
Mẫu này ñưa ra một lớp trừu tượng (Abstract) ñại diện cho các trạng thái của ñối
tượng trong ngữ cảnh hiện tại (Context), ở ñây ta gọi là lớp State. Lớp này cung cấp
giao diện chung cho tất cả các lớp ñại diện các trạng thái khác nhau của ngữ cảnh
Context. Các lớp con, kế thừa từ lớp State này (ConcreteStateA, ConcreteStateB, …), sẽ
cung cấp chi tiết các ứng xử tương ứng với trạng thái của nó. ðối tượng State có thể
truy xuất ñối tượng Context khi cần thiết ñể nắm giữ các yêu cầu của ñối tượng Context
.
Lớp Context sẽ giữ một biến ñối tượng trạng thái (một lớp con của lớp State sẽ
lưu giữ trạng thái hiện hành). Lớp Context sẽ uỷ nhiệm tất cả các lời gọi trạng thái ñến
cho biến ñối tượng này.

thuộc vào ngữ cảnh cụ thể.
1.3.4.2. Cấu trúc mẫu

Hình 1.7: Cấu trúc mẫu Template Method - 24 -

Các thành phần tham gia vào cấu trúc mẫu Template Method:
 Lớp AbstractClass là lớp trừu tượng ñịnh nghĩa khung của thuật toán trong
phương thức mẫu (Template Method).
 Lớp ConcreteClass cài ñặt cách thực hiện các hành vi cụ thể
(PrimitiveOperation). Trong phương thức mẫu, các hành vi cụ thể sẽ ñược
thực hiện theo một thứ tự nhất ñịnh. Mỗi lớp con có một cách cài ñặt cách
thực hiện các hành vi cụ thể này khác nhau.
1.3.4.3. Các tình huống áp dụng
Sử dụng mẫu Template Method khi cần ñịnh nghĩa thứ tự của một thuật toán và
chuyển cho các lớp con thực thi những hành vi cụ thể của thuật toán. Lớp cha sẽ cài
ñặt các hành vi chung, các lớp con sẽ kế thừa và sử dụng lại các phương thức này và
chỉ cần cài ñặt lại các hành vi riêng của nó.
1.3.4.4. Thuận lợi và hạn chế
Sử dụng mẫu này, các phương thức chung ñược cài ñặt ở lớp cha, các lớp con chỉ
cần kế thừa và sử dụng mà không cần cài ñặt lại. ðiều này giúp tránh ñược sự trùng
lắp mã chương trình.
Mẫu này thường ñược sử dụng trong các lớp thư viện dùng ñể gọi các hàm hook.
ðây là những hàm có sẵn trong các thư viện cho phép người dùng kế thừa và cài ñặt
lại.
1.3.5. Mẫu Chuỗi các trách nhiệm
1.3.5.1. Ý nghĩa
Mẫu Chuỗi các trách nhiệm cho phép ñối tượng gửi yêu cầu (Sender), có thể