Báo cáo cuối kỳ môn Thiết kế phần mềm đề tài "Tìm hiểu về Design Pattern trong C++ | Đại học Sư phạm Kỹ thuật Thành phố Hồ Chí Minh

lOMoARcPSD| 36625228
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT TP.HCM
KHOA CÔNG NGHỆ THÔNG TIN BÁO CÁO CUỐI KÌ
TÌM HIỂU VỀ DESIGN PATTERN TRONG C++ lOMoARcPSD| 36625228
ĐỒ ÁN MÔN HỌC MẪU THIẾT KẾ PHẦN MỀM
HỌC KÌ II, NĂM HỌC 2022 – 2023
- Tên đề tài: TÌM HIỂU VỀ DESIGN PATTERN TRONG C++
- Thời gian thực hiện: Từ: 26/03/2022 Đến: 5/6/2022
- Giáo viên hướng dẫn: TS. Huỳnh Xuân Phụng -
Yêu cầu của đề tài:
1. SOLID Design principle in C++ 2. Pattern: ▪ Builder ▪ Adapter ▪ Composite ▪ Facade ▪ Command ▪ Memento ▪ Visitor ▪ Strategy 3. Project minh họa
- Lớp: 212DEPA330879_04CLC -
Sinh viên thực hiện : ST HỌ TÊN MSSV KÝ THAM GIA T TÊN ( % ) 1 100 % 2 100 % Ghi chú: Tỷ lệ % = 100% NHẬN XÉT ĐIỂM SỐ TIÊU NỘI DUNG TRÌNH BÀY TỔNG CHÍ ĐIỂM lOMoARcPSD| 36625228 Mục Lục LỜI CẢM ƠN 1
ĐỒ ÁN MÔN HỌC MẪU THIẾT KẾ PHẦN MỀM 2 NHẬN XÉT 3 MỞ ĐẦU 5 SOLID principle in C++ 10
S -Single responsibility principle ( Nguyên tắc trách nhiệm đơn lẻ ) 10
Open/closed principle ( Nguyên tắc đóng mở ) 10
L - Liskov substitution principle 11
I - Interface segregation principle ( Nguyên tắc phân tách giao diện ) 12
D - Dependency inversion principle ( Nguyên tắc đảo ngược phụ thuộc ) 13 Builder Method Pattern 14
Builder Method Pattern là gì? 14
Sử dụng Builder Pattern khi nào? 14
Lợi ích của Builder Pattern là gì? 15 Adapter Pattern 15
Adapter Pattern là gì? 15
Lợi ích của Adapter Pattern là gì? 16
Sử dụng Adapter Pattern khi nào? 16 Composite pattern 16
Composite Pattern là gì? 16
Lợi ích của Composite Pattern là gì? 17
Sử dụng Composite Pattern khi nào? 17 Facade pattern 17
Facade Pattern là gì? 18
Lợi ích của Facade Pattern là gì? 18
Sử dụng Facade Pattern khi nào? 18 Command pattern 19
Command pattern là gì? 19
Lợi ích của Command Pattern là gì? 20
Sử dụng Command Pattern khi nào? 20 lOMoARcPSD| 36625228 Memento Pattern 20
Memento Pattern là gì? 20
Lợi ích của Memento Pattern là gì? 21
Sử dụng Memento khi nào? 21 Visitor Pattern 21
Visitor Pattern là gì? 21
Lợi ích của Visitor Pattern là gì? 21
Sử dụng Visitor Pattern khi nào? 21 Strategy Pattern 22
Strategy Pattern là gì? 22
Lợi ích của Strategy Pattern là gì? 22
Sử dụng Strategy Pattern khi nào? 22 TỔNG KẾT 23
TÀI LIỆU THAM KHẢO 24 MỞ ĐẦU LỜI MỞ ĐẦU
Ngày nay, công nghệ thông tin được coi là ngành quyền lực bậc nhất với hàng
loạt ứng dụng trong mọi lĩnh vực của đời sống - từ sản xuất, kinh doanh đến giáo dục,
y tế, văn hóa... Đặc biệt, ở thời kỳ Cách mạng 4.0 - mà tại Việt Nam cơ bản là ứng
dụng như công nghệ tự động hóa, trao đổi dữ liệu. Trong công nghệ sản xuất, công
nghệ thông tin càng khẳng định được tầm quan trọng của mình - vừa là nền tảng, vừa
là động lực để bắt kịp đà phát triển của thế giới.
Vậy để hệ thống có tính tái sử dụng cao, tăng tính đóng gói, không lặp lại cũng
như phạm vi logic được thu hẹp thì áp dụng Design Pattern trong phát triển phần
mềm là một sự lựa chọn thích hợp.
Với mong muốn được tìm hiểu sâu về việc phát triển phần mềm nên em đã chọn
đề tài “Desgin Pattern trong Java” Trong quá trình thực hiện đồ án, do còn hạn chế
về thời gian, kinh nghiệm thực tế và dịch bệnh COVID, nhóm chúng em mong nhận
được những góp ý chân thành từ thầy và các bạn.
Đề tài giới thiệu về những lý thuyết cơ bản của Design Pattern, phân tích đánh giá
các kỹ thuật và xây dựng ứng dụng thực nghiệm. lOMoARcPSD| 36625228
KẾ HOẠCH THỰC HIỆN 8 Tìm hiểu Visitor 02 /05/ 20 05 /05/ 20 √ 22 22 9 Tìm hiểu Strategy 06 /05/ 20 10 /05/ 20 √ 22 22 1 Xây dựng project minh 16 /05/ 20 21 /05/ 20 0 họa 22 22 1 Hoàn tất project và báo 22 / 5/202 22 / 5/202 1 cáo 2 2 lOMoARcPSD| 36625228 .Phân cô 1.2 ng nhiệm vụ T Tên sinh viên Mô tả công việc Đóng T góp
- Lập kế hoạch thực hiện, phân chia công
việc các thành viên trong nhóm, và lên ý tưởng Project. 1
- Phụ trách tìm hiểu Builder, 100 % Adapter, Composite, Command.
- Phụ trách tổng hợp nội dung, code và làm báo cáo
- Phụ trách tìm hiểu SOLID, Façade, Memento, Visitor, 2 100 Stratergy. %
- Phụ trách xây dựng Project.
- Phụ trách báo cáo phần thực hiện.
2. BỐ CỤC BÀI BÁO CÁO
Đồ án được tổ chức làm 6 phần như sau:
- Mở đầu: Trình bày rõ lý do chọn đề tài, mục tiêu nghiên cứu đồ án kế hoạch
thực hiện và bố cục của đồ án.
- Chương 1: Kiến thức cơ bản. Chương này trình bày các khái niệm cơ bản, đặc
điểm, phân loại, ưu và nhược điểm của Design Pattern.
- Chương 2: Các kỹ thuật của Design Pattern. Chương này trình bày chi tiết về
các kỹ thuật cũng như cách xây dựng mẫu trong thiết kế phần mềm.
- Chương 3: Project minh họa. Chương này trình bày chủ yếu về phân tích thiết
kế hệ thống hướng đối tượng và áp dụng Design Pattern vào bài toán.
- Tổng kết: Phần này đưa ra những kết quả đồ án đạt được, những thiếu sót chưa
thực hiện được và hướng phát triển đề tài trong tương lai.
- Tài liệu tham khảo: Phần này đưa ra những đường dẫn website và sách tham
khảo mà nhóm đã xem và áp dụng vào bài báo cáo. lOMoARcPSD| 36625228 SOLID principle in C++
S -Single responsibility principle ( Nguyên tắc trách nhiệm đơn lẻ )
Một class chỉ nên thực hiện một công việc. Nói cho dễ hiểu thì một class chỉ nên thực hiện
một công việc, thay vì thực hiện nhiều việc trong một class thì chúng ta có thể cho mỗi
class thực hiện một công việc. Ví dụ :
Với việc chia nhỏ ra ta thấy ta có thể dễ dàng gọi đến lớp tương ứng với từng công việc, nó
cũng dễ hơn khi maintain code và không phải sửa ở lớp chính quá nhiều, các đối tượng đã
được tách biệt hoàn toàn về nhiệm vụ.
Open/closed principle ( Nguyên tắc đóng mở )
Theo nguyên tắc này mỗi khi ta muốn thêm chức năng cho chương trình, chúng ta nên viết
class mới mở rộng class cũ bằng cách kế thừa hoặc sở hữu class cũ chứ không nên sửa đổi class cũ.
Việc này dẫn đến tình trạng phát sinh nhiều class, nhưng chúng ta sẽ không cần phải test lại
các class cũ nữa, mà chỉ tập trung vào test các class mới, nơi chứa các chức năng mới.
Ví dụ : Khi trang web muốn tăng một số cơ chế nhuận bút mới chúng ta thường sẽ thêm thuộc tính cho class Blogger lOMoARcPSD| 36625228
Theo cách làm trên hoàn toàn đúng. Tuy nhiên, nếu bạn thiết kế chương trình như thế này thì
thực sự có nhiều điểm không hợp lí lắm, nếu chúng ta lại có thêm 1 kiểu nhuận bút nữa thì
sao, khi đó chúng ta lại phải vào sửa lại hàm để đáp ứng dược nhu cầu mới hay sao? Code
mới lúc đó sẽ ảnh hưởng tới code cũ, như vậy có khả năng là sẽ làm hỏng luôn code cũ, …
Rõ ràng là chúng ta nên có một phương pháp an toàn và thân thiện hơn.
Có thể thấy rằng, cách thiết kế này làm cho lớp Blogger trở nên: ĐÓNG với mọi sự thay đổi
bên trong, nhưng luôn MỞ cho sự kế thừa để mở rộng sau này.
L - Liskov substitution principle
Nội dung nguyên tắc này là: Trong một chương trình, các object của class con có thể thay thế
class cha mà không làm thay đổi tính đúng đắn của chương trình.
Ví dụ khi ta muốn viết một chương trình để mô tả các loài chim bay được nhưng chim cánh
cụt không bay được. Vì vậy khi viết đến hàm chim cánh cụt thì khi gọi hàm bay của chim
cánh cụt, ta sẽ quăng NoFlyException. lOMoARcPSD| 36625228
Tuy nhiên, quay laị vòng lặp for ở hàm main, nếu như trong danh sách các con chim đó mà có
một con chim cánh cụt thì sao?
Chương trình mình sẽ quăng Exception vì chương trình của chúng ta đã vi phạm Liskov substitution principle.
Để có thể giải quyết vấn đề này ta sẽ tách class chim cánh cụt ra một interface riêng.
I - Interface segregation principle ( Nguyên tắc phân tách giao diện )
Nội dung: Nếu Interface quá lớn thì nên tách thành các interface nhỏ hơn, với nhiều mục đích cụ thể.
Nguyên lý này khá dễ hiểu. Hãy tưởng tượng chúng ta có 1 interface lớn, khoảng 100
methods. Việc implements sẽ khá cực khổ, ngoài ra còn có thể dư thừa vì 1 class không cần dùng hết 100 method.
Khi tách interface ra thành nhiều interface nhỏ, gồm các method liên quan tới nhau, việc
implement và quản lý sẽ dễ hơn.
Ví dụ : Chúng ta có một interface Animal như sau :
Chúng ta có 2 class Dog và Snake implement interface Animal. Nhưng thật vô lý, Dog thì
làm sao có thể fly(), cũng như Snake không thể nào run() được? Thay vào đó, chúng ta nên
tách thành 3 interface như thế này: lOMoARcPSD| 36625228
D - Dependency inversion principle ( Nguyên tắc đảo ngược phụ thuộc )
DIP là nguyên tắc cuối cùng cũng là nguyên tắc khó hiểu nhất trong SOLID. Nội dung nguyên
tắc này là các module cấp cao không nên phụ thuộc vào các modules cấp thấp. Cả 2 nên phụ thuộc vào abstraction.
Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại (Các class giao tiếp với
nhau thông qua interface, không phải thông qua implementation.)
Ví dụ: Khi ta thiết kế một chương trình gửi thông báo từ email đến user
Nhưng bây giờ khách hàng muốn gửi cả SMS và Email đến cho user, bạn phải làm sao?
Tạo một lớp SMSSender và chỉnh sửa class Notificaiton. Như vậy bạn vi phạm một lúc hai
nguyên tắc, Dependency Inversion về sự đảo ngược phụ thuộc và Open close principle.
Software đóng cho việc thay đổi nhưng mở cho việc mở rộng. lOMoARcPSD| 36625228
Để thỏa mãn hai nguyên tắc trên, bạn phải Refactoring code theo chiều hướng giảm sự phụ
thuộc cứng bằng cách tạo ra một interface ISender dùng chung giữa hai class EmailSender và SMSSender.
Giờ đây class Notification phụ thuộc mềm vào interface ISender, nếu khách hàng yêu cầu thêm
một phương thức để chuyển tin nhắn ta có thể thêm vào dễ dàng bằng cách sử dụng interface ISender. Builder Method Pattern
Builder Method Pattern là gì?
Builder pattern là loại design pattern thuộc loại Creational Pattern, mô hình này cung cấp một
trong những cách tốt nhất để tạo ra một đối tượng.
Builder Pattern là mẫu thiết kế đối tượng được tạo ra để xây dựng một đôi tượng phức tạp
bằng cách sử dụng các đối tượng đơn giản và sử dụng tiếp cận từng bước, việc xây dựng các
đối tượng đôc lập với các đối tương khác.
Sử dụng Builder Pattern khi nào?
Builder Pattern được sử dụng khi:
Khi muốn thay đổi thiết kế cho việc lồng nhau của các hàm khởi tạo (Telescoping
Constructor Pattern). Vấn đề này phát sinh khi lập trình viên làm việc với một lớp mà có
chứa rất nhiều các thuộc tính và cần phải tạo ra nhiều hàm khởi tạo với số lượng các thuộc tính tăng dần. lOMoARcPSD| 36625228
Khi cần tạo ra một đối tượng phức tạp, một đối tượng mà thuật toán để tạo tạo lập các thuộc
tính là độc lập đối với các thuộc tính khác.
Lợi ích của Builder Pattern là gì?
Lợi ích của Builder Pattern:
Hỗ trợ, loại bớt iệ phải iết nhiều onѕtru tor.Code dễ đọ , dễ bảo trì hơn khi ѕố ᴠ ᴄ ᴠ ᴄ ᴄ
ᴄ lượng thuộ tính (properу) bắt buộ để tạo một obje t từ 4 hoặ 5 properу.ᴄ ᴄ ᴄ ᴄ
Giảm bớt ѕố lượng onѕtru tor, không ần truуền giá trị null ho á tham ѕố không ѕử ᴄ ᴄ ᴄ ᴄ ᴄ ᴄ dụng.
Ít bị lỗi do iệ gán ѕai tham ѕố khi mà ó nhiều tham ѕố trong onѕtru tor: ᴠ ᴄ ᴄ ᴄ
ᴄ Bởi ì ngườiᴠ dùng đã biết đượ hính хá giá trị gì khi gọi phương thứ tương ứng.ᴄᴄ ᴄ ᴄ
Đối tượng đượ хâу dựng an toàn hơn: ᴄ Bởi ì nó đã đượ tạo hoàn hỉnh trướ khi ѕử ᴠ ᴄ ᴄ ᴄ dụng.
Cung ấp ho bạn kiểm ѕoát tốt hơn quá trình хâу dựng: ᴄ ᴄ Chúng ta ó thể thêm
хử lý ᴄ kiểm tra ràng buộ trướ khi đối tượng đượ trả ề người dùng.ᴄ ᴄ ᴄ ᴠ Có
thể tạo đối tượng immutable. Adapter Pattern
Adapter Pattern là gì?
Adapter pattern là một mẫu thiết kế phần mềm, Adapter Pattern nằm trong nhóm Cấu trúc —
Structural Pattern — liên quan đến cấu trúc cho toàn hệ thống, tập trung vào các mối quan hệ
giữa các thực thể, các component, làm cho chúng tương tác dễ dàng với nhau hơn. Adapter
Pattern đóng vai trò trung gian, tương thích cho hệ thống sẵn có đối ứng với các component
mới mà không cần phải sửa đổi code, cho phép các interface không liên quan đến nhau có thể làm việc cùng nhau.
Lợi ích của Adapter Pattern là gì? lOMoARcPSD| 36625228
● Sử dụng cho dự án một lớp riêng mà không đụng tới những code cũ, hay còn gọi là code gốc
Tăng tính minh bạch và khả năng tái sử dụng của lớp, đóng gói việc triển khai, và khả năng tái sử dụng rất cao.
● Tính sẵn sàng luôn có. Tính linh hoạt và khả năng mở rộng rất tốt.
● Thông qua việc sử dụng các tệp cấu hình, Adapter pattern có thể dễ dàng được thay thế và có
thể thêm các lớp Adapter mà không cần sửa đổi mã gốc, tuân theo nguyên tắc mở và đóng trong lập trình.
Sử dụng Adapter Pattern khi nào?
Trường hợp mà sử dụng nhiều nhất có lẽ là sử dụng và nâng cấp một hệ thống mới và không
muốn đụng vào mô hình của các thế hệ trước kia.
Tình huống được sử dụng tiếp theo đó là sử dụng third party, nhưng developer sẽ định nghĩa
lại những interface do chính dự án yêu cầu. Xem thêm: third party là gì? Khi nào sử dụng third party. Composite pattern
Composite Pattern là gì?
Composite là một mẫu thiết kế thuộc nhóm Structural Pattern. Composite Pattern là một sự
tổng hợp những thành phần có quan hệ với nhau để tạo ra thành phần lớn hơn.
Nó cho phép thực hiện các tương tác với tất cả đối tượng trong mẫu tương tự nhau. lOMoARcPSD| 36625228
Composite Pattern bao gồm các thành phần:
• Component protocol: Đảm bảo tất cả các thành phần trong cây phải được xử lí theo cùng 1 hướng.
• Leaf: Là một thành phần trong cây nhưng không có thành phần con.
• Composite: Là một container chứa các đối tượng leaf và các composite khác. Tất cả các
nút composite và leaf đều xuất phát từ component protocol. Chúng ta có thể tổ chức
một vài lớp leaf khác nhau trong đối tượng composite.
Lợi ích của Composite Pattern là gì?
● Cung cấp cùng một cách sử dụng đối với từng đối tượng riêng lẻ hoặc nhóm các đối tượng với nhau.
Sử dụng Composite Pattern khi nào?
• Composite Pattern chỉ nên được áp dụng khi nhóm đối tượng phải hoạt động như một
đối tượng duy nhất (theo cùng một cách).
• Composite Pattern có thể được sử dụng để tạo ra một cấu trúc giống như cấu trúc cây. lOMoARcPSD| 36625228 Facade pattern
Facade Pattern là gì?
Facade là một mẫu thiết kế thuộc nhóm cấu trúc (Structural Pattern). Facade là một đối tượng
và đối tượng này cung cấp một interface đơn giản để che giấu đi các xử lý phức tạp bên trong nó.
Lợi ích của Facade Pattern là gì?
● Ta có thể tách mã nguồn của mình ra khỏi sự phức tạp của hệ thống con
● Hệ thống tích hợp thông qua Facade sẽ đơn giản hơn vì chỉ cần tương tác với Facade thay vì
hàng loạt đối tượng khác.
● Tăng khả năng độc lập và khả chuyển, giảm sự phụ thuộc.
● Có thể đóng gói nhiều hàm được thiết kế không tốt bằng 1 hàm có thiết kế tốt hơn.
Sử dụng Facade Pattern khi nào?
Dưới đây chúng ta có thể liệt kê một số trường hợp mà khi gặp sẽ phải cân nhắc sử dụng Facade pattern:
● Muốn gom nhóm chức năng lại để Client dễ sử dụng. Khi hệ thống có rất nhiều lớp làm người
sử dụng rất khó để có thể hiểu được quy trình xử lý của chương trình. Và khi có rất nhiều hệ
thống con mà mỗi hệ thống con đó lại có những giao diện riêng lẻ của nó nên rất khó cho việc
sử dụng phối hợp. Khi đó có thể sử dụng Facade Pattern để tạo ra một giao diện đơn giản cho
người sử dụng một hệ thống phức tạp.
● Giảm sự phụ thuộc. Khi bạn muốn phân lớp các hệ thống con. Dùng Façade Pattern để
địnhnghĩa cổng giao tiếp chung cho mỗi hệ thống con, do đó giúp giảm sự phụ thuộc của các
hệ thống con vì các hệ thống này chỉ giao tiếp với nhau thông qua các cổng giao diện chung đó.
● Tăng khả năng độc lập và khả chuyển
● Khi người sử dụng phụ thuộc nhiều vào các lớp cài đặt. Việc áp dụng Façade Pattern sẽ tách
biệt hệ thống con của người dùng và các hệ thống con khác, do đó tăng khả năng độc lập và
khả chuyển của hệ thống con, dễ chuyển đổi nâng cấp trong tương lai. lOMoARcPSD| 36625228
● Đóng gói nhiều chức năng, che giấu thuật toán phức tạp.
● Cần một interface không rắc rối mà dễ sử dụng. Command pattern
Command pattern là gì?
Command Pattern là một trong 23 design pattern Gang of Four nổi tiếng. Command pattern thuộc
nhóm các pattern hành vi: Đóng gói tất cả thông tin cần thiết vào 1 đối tượng để thực hiện hành
động hay kích hoạt một sự kiện thực hiện sau đó.
Các thông tin có thể bao gồm tên phương thức, các biến và giá trị cần thiết...hay đơn giản hơn đó
là nó cho phép chuyển yêu cầu thành đối tượng độc lập, có thể được sử dụng để tham số hóa các
đối tượng với các yêu cầu khác nhau như log, queue (undo/redo), transtraction. Dưới đây là các
thành phần cần có của 1 command pattern Trong đó:
• Command : là một interface hoặc abstract class, chứa một phương thức trừu tượng thực
thi (execute) một hành động (operation). Request sẽ được đóng gói dưới dạng Command.
• ConcreteCommand : là các implementation của Command. Định nghĩa một sự gắn kết
giữa một đối tượng Receiver và một hành động. Thực thi execute() bằng việc gọi
operation đang hoãn trên Receiver. Mỗi một ConcreteCommand sẽ phục vụ cho một case request riêng.
• Client : tiếp nhận request từ phía người dùng, đóng gói request thành
ConcreteCommand thích hợp và thiết lập receiver của nó.
• Invoker : tiếp nhận ConcreteCommand từ Client và gọi execute() của
ConcreteCommand để thực thi request. lOMoARcPSD| 36625228
• Receiver : đây là thành phần thực sự xử lý business logic cho case request. Trong
phương thức execute() của ConcreteCommand chúng ta sẽ gọi method thích hợp trong Receiver.
Lợi ích của Command Pattern là gì?
• Dễ dàng thêm các Command mới trong hệ thống mà không cần thay đổi trong các lớp
hiện có. Đảm bảo Open/Closed Principle.
• Tách đối tượng gọi operation từ đối tượng thực sự thực hiện operation. Giảm kết nối giữa Invoker và Receiver.
• Cho phép tham số hóa các yêu cầu khác nhau bằng một hành động để thực hiện.
• Cho phép lưu các yêu cầu trong hàng đợi. Đóng gói một yêu cầu trong một đối tượng.
Dễ dàng chuyển dữ liệu dưới dạng đối tượng giữa các thành phần hệ thống.
Sử dụng Command Pattern khi nào?
• Khi cần tham số hóa các đối tượng theo một hành động thực hiện.
• Khi cần tạo và thực thi các yêu cầu vào các thời điểm khác nhau.
• Khi cần hỗ trợ tính năng undo, log , callback hoặc transaction. Memento Pattern
Memento Pattern là gì?
Memento là một Design Pattern thuộc loại Behavior. Nó cho phép chúng ta lưu trữ và khôi
phục trạng thái của một đối tượng mà không tiết lộ chi tiết bên trong của nó. Memento Pattern
gồm các thành phần chính như sau:
Originator: là Object có trạng thái được lưu trữ hoặc khôi phục.
Mementor: là trạng thái (State) của Object khi đang được lưu trữ.
CareTaker: đóng vai trò lưu trữ và cấp phát các Memento. lOMoARcPSD| 36625228
Lợi ích của Memento Pattern là gì?
Bảo bảo nguyên tắc đóng gói: sử dụng trực tiếp trạng thái của đối tượng có thể làm lộ thông
tin chi tiết bên trong đối tượng và vi phạm nguyên tắc đóng gói.
Đơn giản code của Originator bằng cách để Memento lưu giữ trạng thái của Originator và
Caretaker quản lý lịch sử thay đổi của Originator.
Sử dụng Memento khi nào?
Memento Pattern được sử dụng bất cứ khi nào chúng ta muốn lưu và sau đó khôi phục trạng thái của một Object.
Ví dụ như khi chúng ta chơi game, chúng ta muốn lưu lại tất cả những trạng thái chúng ta đã
chơi trước đó để sau khi quit game và mở lại thì chúng ta có thể tiếp tục chơi, khi đó ta có thể
áp dụng Memento Pattern để giải quyết bài toán này. Visitor Pattern
Visitor Pattern là gì?
Visitor Pattern là một trong những Pattern thuộc nhóm hành vi (Behavior Pattern). Visitor cho phép
định nghĩa các thao tác (operations) trên một tập hợp các đối tượng (objects) không đồng nhất (về
kiểu) mà không làm thay đổi định nghĩa về lớp (classes) của các đối tượng đó.
Để đạt được điều này, trong mẫu thiết kế visitor ta định nghĩa các thao tác trên các lớp tách biệt gọi
các lớp visitors, các lớp này cho phép tách rời các thao tác với các đối tượng mà nó tác động đến.
Với mỗi thao tác được thêm vào, một lớp visitor tương ứng được tạo ra.
Lợi ích của Visitor Pattern là gì?
Cho phép một hoặc nhiều hành vi được áp dụng cho một tập hợp các đối tượng tại thời điểm
run-time, tách rời các hành vi khỏi cấu trúc đối tượng.
Đảm bảo nguyên tắc Open/ Close: đối tượng gốc không bị thay đổi, dễ dàng thêm hành vi mới
cho đối tượng thông qua visitor.
Sử dụng Visitor Pattern khi nào?
Khi có một cấu trúc đối tượng phức tạp với nhiều class và interface. Người dùng cần thực hiện một
số hành vi cụ thể của riêng đối tượng, tùy thuộc vào concrete class của chúng. lOMoARcPSD| 36625228
Khi chúng ta phải thực hiện một thao tác trên một nhóm các loại đối tượng tương tự. Chúng ta có
thể di chuyển logic hành vi từ các đối tượng sang một lớp khác.
Khi cấu trúc dữ liệu của đối tượng ít khi thay đổi nhưng hành vi của chúng được thay đổi thường xuyên.
Khi muốn tránh sử dụng toán tử instanceof. Strategy Pattern
Strategy Pattern là gì?
Strategy pattern (mẫu chiến lược): Hiểu một cách đơn giản thì đây là mẫu thiết kế giúp bạn
trừu tượng hóa những hành vi (behavior, method, function) của một đối tượng bằng cách đưa
ra những cài đặt vào những lớp khác nhau.
Lợi ích của Strategy Pattern là gì?
Nó cung cấp một sự thay thế cho các class con.
Nó định nghĩa mỗi hành vi trong lớp riêng, loại bỏ sự cần thiết cho các câu lệnh có điều kiện.
Nó giúp dễ dàng mở rộng và kết hợp hành vi mới mà không thay đổi ứng dụng.
Sử dụng Strategy Pattern khi nào?
Khi nhiều lớp chỉ khác nhau về hành vi.
Khi bạn cần các biến thể khác nhau của thuật toán. TỔNG KẾT
Design Pattern là một vấn đề hết sức quan trọng đối với các tổ chức phát triển
phần mềm hiện nay. Trong quá trình thực hiện đồ án do thời gian nghiên cứu và kinh
nghiệm bản thân còn hạn chế nên một số phần của đồ án nghiên cứu chưa được sâu.
Sau 03 tháng thực hiện nghiên cứu đề tài, dưới sự hướng dẫn tận tình của Tiến sỹ Huỳnh
Xuân Phụng, đồ án của em đã đạt được những kết quả sau:
Kết quả đạt được:
▪ Tìm hiểu và nghiên cứu cơ sở lý thuyết của Design Pattern
▪ Nắm được một số kỹ thuật hay sử dụng và cách sử dụng
▪ Biết áp dụng Design Pattern vào bài toán đơn giản Hạn chế: lOMoARcPSD| 36625228
Trong thời gian qua, chúng em đã cố gắng hết sức để tìm hiểu thực hiện đề tài.
Tuy nhiên với kinh nghiệm và thời gian hạn chế nên không thể tránh khỏi những thiếu
sót trong đồ án. Cụ thể:
▪ Chưa nghiên cứu sâu vào các kỹ thuật của Design Patterns
▪ Đồ án mới tập trung vào một bài toán nhỏ nên vẫn chưa toát nên được tầm
quan trọng của Design Patterns
▪ Trình bày thiếu logic, cách diễn đạt còn kém
Hướng phát triển của đề tài trong tương lai:
Với mong muốn trở thành lập trình viên phần mềm trong tương lai nên trong thời
gian tới em sẽ tiếp tục tìm hiểu và nghiên cứu cũng như hoàn thiện đồ án của mình ở
mức cao nhất. Và sau đó sẽ nghiên cứu và áp dụng Design Patterns vào bài toán Quản
lý mầm non để thấy được tầm quan trọng của nó. Rồi từ đó rút ra kinh nghiệm của
bản thân và cải thiện các kỹ năng cần thiết.
TÀI LIỆU THAM KHẢO
[1]. https://shorturl.at/tADFK
[2]. https://tuanitpro.com/design-pattern-la-gi
[3]. https://blog.duyet.net/2015/02/oop-design-patterns-la-gi
[4]. https://refactoring.guru/design-patterns/catalog
[5]. https://developer.ibm.com/languages/java/
[6]. https://www.journaldev.com/1827/java-design-patterns-example-tutorial