BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT

TP. HỒ CHÍ MINH

KHOA ĐÀO TẠO CHẤT LƯỢNG CAO

BÁO CÁO ĐỒ ÁN

ĐỀ TÀI:

TÌM HIỂU LÝ THUYẾT VÀ CÁC

MẪU THIẾT KẾ PHẦN MỀM CÓ
TRONG SPRING FRAMEWORK
Giảng viên hướng dẫn : Nguyễn Minh Đạo
Môn : Mẫu Thiết Kế Phần Mềm
Lớp : Sáng thứ 6, Tiết 1-4
Mã lớp : DEPA330879_21_2_03CLC
Thực hiện đề tài: Nhóm 09

STT Họ tên SV MSSV

1 Quách Diệu Khánh 191102
26
2 Phan Tấn Thành 191102
3 Phạm Ngọc Đức 88

4 Võ Hữu Giàu 191101

57
191101
96

Tên đề tài: Tìm hiểu Spring Framework và các mẫu thiết kế phần mềm có
trong spring framework

Thời gian thực hiện: : 01/04/2022 – 20/05/2022

NHẬN XÉT CỦA GIẢNG VIÊN

......................................................................................................................................

......................................................................................................................................

......................................................................................................................................

......................................................................................................................................

......................................................................................................................................

......................................................................................................................................

2
 Tp. Hồ Chí Minh, ngày …., tháng …., năm 2022

Giảng viên hướng dẫn

Nguyễn Minh Đạo

LỜI CẢM ƠN 6
2. Overview of GOF Design Patterns - Core Design Patterns 7
Giới thiệu về sức mạnh của các mẫu Design Patterns 7
Tổng quan về mô hình thiết kế GOF 7
Creational design patterns 9
3. Consideration of Structural and Behavioral Patterns 18
Phân tích cốt lõi của mẫu thiết kế 18
Mẫu cấu trúc 18
Mẫu hành vi 27
Mẫu thiết kế J2EE 32
4. Wiring Beans using the Dependency Injection Pattern. 34
The dependency injection pattern 34
Types of dependency injection patterns 34
Constructor-based dependency injection 34
Setter-based dependency injection 35
Configuring the dependency injection pattern with Spring 36
Annotating beans for autowiring Lookup-method injection pattern 36
Implementing the Abstract Factory Pattern in Spring 37
Implementation of FactoryBean interface in Spring 37
5. Ví dụ 22 mẫu đã học và 7 mẫu bổ sung 38

3
Structural Pattern: 38
1. Mẫu Adapter: 38
2. Bridge: 39
3. Mẫu Composite: 40
4. Mẫu Decorator: 40
5. Mẫu Facade: 41
6. Mẫu Flyweight: 42
7. Mẫu Proxy: 42
Creational Pattern: 43
8. Mẫu Factory Method: 43
9. Abstract Factory: 44
10. Builder: 44
11. Singleton: 45
12. Prototype: 45
Behavior Pattern: 46
13. Chain of Responsibility: 46
14. Command: 47
15. Iterator: 48
16. Mediator: 49
17. Memento: 50
18. Observer: 51
19. Strategy: 51
20. Template Method: 52
21. Visitor: 53

4
 22. State: 54
Các mẫu mở rộng: 55
23. Null object: 55
24. Interpreter Pattern: 56
25. MVC Pattern: 58
26. Dependency Injection Pattern: 59
27. Dao Pattern: 60
28. Intercepting Filter 61
29. DataAccessObjectPattern 63
Tài Liệu Tham Khảo 63

5
 LỜI CẢM ƠN

Chúng em xin gửi lời cảm ơn chân thành đến Khoa Đào tạo Chất lượng cao, Trường
Đại học Sư phạm Kỹ thuật TP.HCM đã tạo điều kiện thuận lợi cho chúng em học tập và
hoàn thành đề tài báo cáo này. Đặc biệt, chúng em xin bày tỏ lòng biết ơn sâu sắc đến
thầy Nguyễn Minh Đạo đã truyền đạt kiến thức và hướng dẫn chúng em trong quá trình
hoàn thành báo cáo.
Nhóm em đã cố gắng vận dụng những kiến thức đã học được trong học kỳ qua để
hoàn thành bài báo cáo. Nhưng do kiến thức hạn chế và không có nhiều kinh nghiệm thực
tiễn nên khó tránh khỏi những thiếu sót trong quá trình nghiên cứu và trình bày. Rất kính
mong sự góp ý của thầy để bài báo cáo của nhóm em được hoàn thiện hơn.
Một lần nữa, nhóm em xin trân trọng cảm ơn sự quan tâm giúp đỡ của thầy đã giúp
đỡ nhóm em trong quá trình thực hiện bài báo cáo này.
Xin trân trọng cảm ơn!

6
 2. Overview of GOF Design Patterns - Core
Design Patterns
1. Giới thiệu về sức mạnh của các mẫu Design Patterns

Trên thực tế, cụm từ Design Pattern không liên quan đến bất kỳ ngôn
ngữ lập trình nào và nó cũng không cung cấp các giải pháp cụ thể cho các
vấn đề về ngôn ngữ, là một khái niệm kỹ thuật phần mềm mô tả các giải
pháp định kỳ cho các vấn đề phổ biến trong thiết kế phần mềm. Các mẫu
này cũng đại diện cho các thực tiễn tốt nhất được sử dụng bởi các nhà phát
triển phần mềm có kinh nghiệm.

Một mô hình thiết kế có ba đặc điểm chính:

+ Mẫu thiết kế dành riêng cho một kịch bản cụ thể hơn là một nền
tảng. Vì vậy, bối cảnh của nó là điều kiện xung quanh mà vấn đề tồn tại.
Bối cảnh phải được ghi lại trong khuôn mẫu.
+ Các mẫu thiết kế đã được phát triển để cung cấp các giải pháp tốt
nhất cho một số vấn đề nhất định gặp phải trong quá trình phát triển phần
mềm.Vì vậy, điều này nên được giới hạn bởi bối cảnh mà nó đang được
xem xét.
+ Các mẫu thiết kế là phương thuốc cho các vấn đề đang được xem
xét.
2. Tổng quan về mô hình thiết kế GOF

Tác giả của cuốn sách có tiêu đề là GOF này là nhóm 4 người gồm
có Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides. Vấn đề
trong cuốn sách liên quan đến các yếu tố của phần mềm hướng đối tượng

7
có thể tái sử dụng, đã khởi xướng khái niệm về các mẫu thiết kế trong phát
triển phần mềm.

Các mẫu Gang of Four (GoF) gồm 23 mẫu thiết kế phần mềm cổ
điển cung cấp các giải pháp cho các vấn đề phổ biến trong thiết kế phần
mềm. Các mẫu này được phân loại thành hai loại chính:

+ Core Design Patterns .

+ J2EE Design Patterns.

Core Design Patterns được chia thành ba loại chính của mẫu thiết kế,
như sau:

+ Creational Design Pattern: các mẫu trong danh mục này cung cấp
một cách để xây dựng các đối tượng khi các nhà thầu sẽ không phục vụ
mục đích của bạn. Logic sáng tạo của các đối tượng được ẩn. Các chương
trình dựa trên các mẫu này linh hoạt hơn trong việc quyết định tạo đối
tượng theo yêu cầu của bạn và các trường hợp sử dụng của bạn cho ứng
dụng.
+ Structural Design Pattern: các mẫu trong danh mục này liên quan
đến thành phần của các lớp hoặc đối tượng. Trong ứng dụng doanh nghiệp,
có hai kỹ thuật thường được sử dụng để tái sử dụng chức năng trong các hệ
thống hướng đối tượng: một là kế thừa lớp và hai là khái niệm thành phần
đối tượng của thừa kế. hái niệm thành phần đối tượng của kế thừa được sử
dụng để soạn thảo giao diện và xác định các cách để soạn thảo các đối
tượng để có được các chức năng mới.
+ Behavioral Design Pattern: các mẫu trong danh mục này, đặc
trưng cho các cách mà các lớp hoặc đối tượng tương tác và phân phối trách

8
nhiệm. Các mẫu thiết kế này đặc biệt quan tâm đến giao tiếp giữa các đối
tượng. Mô hình thiết kế hành vi được sử dụng để kiểm soát và giảm luồng
ứng dụng phức tạp trong ứng dụng doanh nghiệp.

Hơn nữa, JEE Design patterns, là loại chính khác của các mẫu thiết
kế. Thiết kế ứng dụng có thể được đơn giản hóa vô cùng bằng cách áp
dụng các mẫu thiết kế Java EE. Các mẫu thiết kế của Java EE đã được ghi
lại trong các bản thiết kế Java của Sun.

Các mẫu thiết kế Java EE này cung cấp các hướng dẫn giải pháp
được thử nghiệm theo thời gian và các thực tiễn tốt nhất để tương tác đối
tượng trong các lớp khác nhau của ứng dụng Java EE. Các mẫu thiết kế
này đặc biệt quan tâm đến các lớp được liệt kê sau:

+ Design pattern at the presentation layer.

+ Design pattern at the business layer.
+ Design pattern at the integration layer.
3. Creational design patterns

Các mẫu thiết kế sáng tạo( Creational design patterns ) được liên kết
với phương pháp tạo đối tượng. Logic tạo của đối tượng được ẩn cho người
gọi của đối tượng này.

Cách này không phù hợp với một số trường hợp, bởi vì nó là một
cách tạo mã cứng để tạo ra một đối tượng. Nó cũng không phải là một thực
tiễn tốt nhất để tạo ra một đối tượng bởi vì đối tượng có thể được thay đổi
theo bản chất của chương trình.

9
 Do đó, mô hình thiết kế sáng tạo( Creational design patterns ) cung
cấp sự linh hoạt để tạo ra một đối tượng theo bản chất của chương trình.

Factory design pattern

Xác định một giao diện để tạo một đối tượng, nhưng hãy để các lớp
con quyết định lớp nào sẽ khởi tạo. Phương pháp này cho phép một lớp trì
hoãn việc khởi tạo cho các lớp con.

Theo mẫu thiết kế nhà máy(Factory) này, ta nhận được một đối
tượng của một lớp mà không phơi bày logic cơ bản cho máy khách(client).
Nó gán một đối tượng mới cho người gọi bằng cách sử dụng một giao diện
chung hoặc lớp trừu tượng. Điều này có nghĩa là mô hình thiết kế che giấu
logic thực tế của việc thực hiện một đối tượng, cách tạo nó và lớp nào khởi
tạo nó. Chịu trách nhiệm cho các nhiệm vụ này. Mô hình nhà máy(Factory)
là một trong những mẫu thiết kế được sử dụng nhiều nhất trong Java.

Những lợi ích của mẫu thiết kế nhà máy(Factory)

Mẫu nhà máy thúc đẩy khớp nối lỏng lẻo giữa các thành phần hoặc
lớp hợp tác bằng cách sử dụng các giao diện thay vì ràng buộc các lớp
dành riêng cho ứng dụng vào mã ứng dụng bằng cách sử dụng mẫu này.

Ta có thể thực hiện một đối tượng của các lớp thực hiện giao diện,
khi chạy vòng đời đối tượng được quản lý bởi nhà máy được thực hiện bởi
mô hình này.

Một số vấn đề chung nên sử dụng mẫu thiết kế này

+ Mẫu này loại bỏ gánh nặng cho nhà phát triển để tạo và quản lý
các đối tượng.

10
 + Mẫu này loại bỏ sự kết hợp chặt chẽ giữa các thành phần cộng tác
vì một thành phần không biết các lớp con nào sẽ được yêu cầu để tạo.
+ Tránh mã cứng để tạo một đối tượng của lớp.

Thực thi mẫu nhà máy(Factory) vào Spring Framework

Spring Framework sử dụng mẫu này để thực thi container(nơi chứa

đựng tất cả các beans) sử dụng giao diện BeanFactory và
ApplicationContext.

Spring container hoạt động dựa trên mô hình nhà máy để tạo ra các
beans cho ứng dụng Spring và cũng như quản lý vòng đời của mỗi beans.

BeanFactory và ApplicationContext là các giao diện nhà máy và

Spring có rất nhiều lớp thực hiện. Phương pháp GetBean () là phương pháp
nhà máy cung cấp beans sao cho phù hợp.

Abstract factory design pattern

Cung cấp một giao diện để tạo các mối liên hệ giữa các đối tượng
liên quan hoặc phụ thuộc mà không cần chỉ định các lớp cụ thể của nó.

Đây là một mô hình thiết kế cao cấp so với mô hình thiết kế phương
pháp nhà máy. Theo mẫu thiết kế này, bạn chỉ cần xác định một giao diện
hoặc lớp trừu tượng để tạo một đối tượng phụ thuộc có liên quan mà không
cần chỉ định lớp con cụ thể của nó.

Trong mô hình nhà máy trừu tượng, một giao diện chịu trách nhiệm
tạo ra một nhà máy gồm các đối tượng liên quan mà không chỉ định rõ ràng
các lớp của chúng. Mỗi nhà máy được tạo ra có thể cung cấp cho các đối
tượng theo mẫu nhà máy.

11
 Những lợi ích của mô hình nhà máy trừu tượng(Abstract
factory)

+ Cung cấp khớp nối lỏng lẻo giữa các thành phần liên quan. Nó
cũng cách ly mã máy khách(client) với các lớp cụ thể.
+ Mô hình thiết kế này là một thiết kế cấp cao hơn mô hình nhà máy.
+ Mẫu này cung cấp tính nhất quán tốt hơn trong thời gian xây dựng
của các đối tượng trên toàn ứng dụng.
+ Mô hình này dễ dàng hoán đổi các thành phần liên quan.

Một số vấn đề chung nên sử dụng mẫu thiết kế

này(Abstract factory)

Khi bạn thiết kế một mẫu nhà máy để tạo đối tượng trong ứng dụng
của bạn, có những lúc bạn muốn một tập hợp các đối tượng liên quan cụ
thể được tạo với các ràng buộc nhất định và áp dụng logic mong muốn trên
các đối tượng liên quan trong ứng dụng của bạn. Bạn có thể đạt được thiết
kế này bằng cách tạo một nhà máy khác bên trong nhà máy cho một bộ các
đối tượng liên quan và áp dụng các ràng buộc cần thiết. Bạn cũng có thể
lập trình logic cho một tập hợp các đối tượng liên quan.

Khi bạn muốn tùy chỉnh logic khởi tạo của các đối tượng liên quan,
thì bạn có thể sử dụng mẫu thiết kế này.

Thực thi mẫu nhà máy trừu tượng(Abstract Factory) vào

Spring Framework

Trong Spring Framework, giao diện FactoryBean dựa trên mô hình

thiết kế Abstract Factory, Spring cung cấp nhiều phương thức thực thi giao
diện này, chẳng hạn như là ProxyFactoryBean, Jndi Factory Bean,

12
LocalSessionFactoryBean,

LocalContainerEntityManagerFactoryBean, và một số khác.

Một FactoryBean cũng hữu ích để giúp xây dựng đối tượng Spring
mà bản thân nó không dễ dàng tự xây dựng được.Thường thì điều này
được sử dụng để xây dựng các đối tượng phức tạp có nhiều phụ thuộc. Nó
cũng có thể được sử dụng khi bản thân logic xây dựng rất biến động và phụ
thuộc vào cấu hình.

Singleton design pattern

Đảm bảo một lớp chỉ có một trường hợp và cung cấp một điểm truy
cập toàn cầu cho nó.

Mẫu singleton này là một trong những mẫu thiết kế đơn giản nhất
trong Java.Theo mẫu thiết kế này, lớp cung cấp cùng một đối tượng cho
mỗi cuộc gọi-nghĩa là nó đang hạn chế việc khởi tạo một lớp cho một đối
tượng và cung cấp một điểm truy cập toàn cầu vào lớp đó.

Vì vậy, lớp sẽ chịu trách nhiệm tạo một đối tượng và cũng đảm bảo
rằng chỉ nên tạo một đối tượng cho mỗi cuộc gọi của khách hàng(client)
cho đối tượng này.

Lớp này không cho phép khởi tạo trực tiếp một đối tượng của lớp
này. Nó cho phép có được một thể hiện đối tượng chỉ bằng một phương
thức tĩnh được tiếp xúc.

Điều này rất hữu ích khi chính xác một đối tượng là cần thiết để phối
hợp các hành động trên hệ thống. Bạn có thể tạo một mẫu duy nhất bằng
hai biểu mẫu, như được liệt kê ở đây:

13
 + Early instantiation: Tạo phiên bản vào thời điểm tải.
+ Lazy instantiation: Tạo phiên bản khi được yêu cầu.

Những lợi ích của mô hình Singleton

+ Nó cung cấp quyền truy cập bộ điều khiển vào các lớp quan trọng
(thường là đối tượng nặng), chẳng hạn như lớp kết nối cho DB và lớp
sessionFactory trong Hibernate.
+ Nó giúp tiết kiệm hàng đống bộ nhớ.
+ Nó là một thiết kế rất hiệu quả cho môi trường đa luồng.
+ Nó linh hoạt hơn vì lớp kiểm soát quá trình khởi tạo và lớp có tính
linh hoạt để thay đổi quá trình khởi tạo.
+ Nó có độ trễ thấp.

Một số vấn đề chung nên sử dụng mẫu thiết kế

này(Singleton)

Mẫu Singleton chỉ giải quyết được một vấn đề nếu bạn có một tài
nguyên chỉ có thể có một thể hiện duy nhất và bạn cần quản lý trường hợp
đó, thì bạn cần một singleton.

Thông thường, nếu muốn tạo kết nối cơ sở dữ liệu với cấu hình đã
cho trong môi trường phân phối và đa luồng, nếu không tuân theo thiết kế
singleton thì mọi luồng có thể tạo kết nối cơ sở dữ liệu mới với một đối
tượng cấu hình khác.

Với mẫu singleton, mỗi luồng có cùng đối tượng kết nối cơ sở dữ
liệu với cùng một đối tượng cấu hình trên hệ thống. Nó chủ yếu được sử
dụng trong các ứng dụng đa luồng và cơ sở dữ liệu. Nó được sử dụng trong
ghi nhật ký, lưu trữ, nhóm luồng, cài đặt cấu hình,...

14
 Thực thi mẫu Singleton vào Spring Framework

Spring Framework cung cấp một phạm vi singleton bean như là mô hình
singleton, nó tương tự mẫu singleton, nhưng không giống hẳn singleton trong java.
Theo mẫu singleton, một phạm vi bean trong Spring framework có nghĩa là một bean
duy nhất trên mỗi container và mỗi bean. Nếu bạn xác định một bean cho một lớp cụ
thể trong một Spring container, thì sẽ tạo một và chỉ một thể hiện của lớp được xác
định bởi định nghĩa bean đó.

Prototype design pattern

Chỉ định loại đối tượng để tạo bằng cách sử dụng một thể hiện
nguyên mẫu và tạo các đối tượng mới bằng cách sao chép nguyên mẫu này.

Mẫu này được sử dụng để tạo các đối tượng bằng cách sử dụng
phương thức nhân bản của các đối tượng. Nó được xác định bởi một ví dụ
nguyên mẫu. Trong ứng dụng doanh nghiệp, việc tạo đối tượng là tốn kém
về mặt tạo và khởi tạo các thuộc tính ban đầu của các đối tượng. Nếu một
loại đối tượng như vậy đã có trong tay, thì ta sẽ tìm mẫu prototype này.
Bạn chỉ cần sao chép một đối tượng tương tự hiện có thay vì tạo nó, đó là
tốn thời gian.

Mẫu này liên quan đến việc thực hiện giao diện nguyên mẫu, nó tạo
ra một bản sao của đối tượng hiện tại. Mẫu này được sử dụng khi tạo trực
tiếp đối tượng là tốn kém.

Những lợi ích của mô hình Prototype

+ Giảm thời gian để tạo các đối tượng tốn thời gian.
+ Mô hình này làm giảm lớp con.
+ Mẫu này thêm và xóa các đối tượng trong thời gian chạy.
+ Mẫu này cấu hình ứng dụng với các lớp một cách linh hoạt.

15
 Builder design pattern

Tách biệt việc xây dựng một đối tượng phức tạp khỏi biểu diễn của
nó để quá trình xây dựng tương tự có thể tạo ra các biểu diễn khác nhau.

Logic và quá trình tạo đối tượng phải là chung để bạn có thể sử dụng
nó để tạo các triển khai cụ thể khác nhau của cùng loại đối tượng. Mẫu này
đơn giản hóa việc xây dựng các đối tượng phức tạp và nó ẩn các dựng
được sử dụng để xây dựng một đối tượng phức tạp từng bước và cuối cùng
nó sẽ trả về đối tượng hoàn chỉnh chi tiết về cấu trúc của đối tượng từ mã
người gọi máy khách.

Khi bạn đang sử dụng mẫu này, hãy nhớ rằng bạn phải xây dựng nó
từng bước một, điều đó có nghĩa là bạn phải chia đăng nhập xây dựng đối
tượng thành nhiều giai đoạn, không giống như các mẫu khác, chẳng hạn
như nhà máy trừu tượng và mẫu nhà máy, mà đối tượng trong một bước
duy nhất.

Những lợi ích của mô hình Prototype

+ Mô hình này cung cấp cho bạn sự cô lập hoàn toàn giữa việc xây
dựng và biểu diễn của một đối tượng.
+ Mẫu này cho phép bạn xây dựng đối tượng theo nhiều giai đoạn,
vì vậy bạn có quyền kiểm soát nhiều hơn đối với quy trình xây dựng.
+ Mẫu này cung cấp sự linh hoạt để thay đổi biểu diễn bên trong của
đối tượng.

Thực thi mẫu Singleton vào Spring Framework

Spring Framework thực hiện mô hình thiết kế xây dựng(builder) một

cách minh bạch trong một số chức năng .Các lớp sau dựa trên mẫu thiết kế

16
xây dựng(builder) trong Spring Framework:

+ EmbeddedDatabaseBuilder.
+ AuthenticationManagerBuilder.
+ UriComponentsBuilder.
+ BeanDefinitionBuilder.
+ MockMvcWebClientBuilder.

Một số vấn đề chung nên sử dụng mẫu thiết kế

này(Builder)

Trong một ứng dụng doanh nghiệp, bạn có thể áp dụng mẫu trình xây
dựng trong đó việc tạo đối tượng đã được thực hiện bằng cách sử dụng
nhiều bước. Trong mỗi bước, bạn thực hiện một phần của quy trình. Trong
quy trình này, bạn đặt một số tham số cần thiết và một số tham số tùy chọn
và sau bước cuối cùng, bạn sẽ nhận được một đối tượng phức tạp.

Mẫu builder là một mẫu thiết kế phần mềm tạo đối tượng. Mục đích
là để trừu tượng các bước xây dựng để các triển khai khác nhau của các
bước này có thể xây dựng các biểu diễn khác nhau của các đối tượng.
Thông thường, mẫu xây dựng được sử dụng để xây dựng các sản phẩm
theo mẫu tổng hợp.

17
 3. Consideration of Structural and Behavioral
Patterns
Tiếp tục các phần tiếp theo của GOF design pattern đó là structural and
behavioral design patterns

1. Phân tích cốt lõi của mẫu thiết kế

● Structural design pattern: các mẫu trong danh mục này sẽ đảm
nhiệm các thành phần của các class hoặc các đối tượng.
● Trong phần mềm doanh nghiệp thì có 2 kĩ thuật cơ bản để tái sử
dụng các chức năng của hệ thống hướng đối tượng đó là:
o  Inheritance (Kế thừa): kế thừa các trạng thái và biểu hiện của
class khác
o Composition: Được sử dụng như là các thành phần của các
đối tượng khác như một biến của class, Thành phần hóa các
đối tượng để nhận các tính năng
● Behavioral design pattern: các mẫu trong danh mục này nêu rõ đặc
điểm và các cách thức để các class và object tương tác với nhau và
đóng góp nhiệm vụ. Các mẫu này xác định các phương thức để mà
giao tiếp giữa các object với nhau trong phần mềm. Giảm thiểu độ
phức tạp của luồng điều khiển, đóng gói các thuật toán và linh hoạt
trong việc chọn 1 trong số các thuật toán để sử dụng
3.1. Mẫu cấu trúc

-        Structural patterns cho phép chúng ta giải quyết nhiều vấn đề liên quan
tới cấu trúc quan hệ giữa các object.

-        Liên kết các phần khác nhau của hệ thống lại với nhau và dễ dàng mở
rộng.

-        Và đảm bảo việc 1 thành phần bị thay đổi thì các phần khác trong cấu
trúc hệ thống không phải thay đổi theo

Mẫu adapter

18
 -        2 class không thể làm việc chung do không tương thích interface

-        Mẫu adaper được sử dụng khi 2 interface trong phần mềm không tương
thích chức năng nhưng vẫn có thể tích hợp với nhau được

Lợi ích của mẫu Adapter

-       Cho phép giao tiếp và tương tác được với 2 hay nhiều object không tương
thích nhau

-        Phát triển khả năng tái sử dụng các chức năng đã triển khai trong phần
mềm

Yêu cầu chung khi dùng mẫu Adapter

-        Phải có sẵn class với interface không tương thích

-        Dùng adapter pattern khi muốn tạo 1 class mà có thể kết hợp với các
class khác không tương thích nhau

-        1 object của adapter có thể mô phỏng interface của class cha

Triển khai mẫu Adapter trên Spring Framework

-        Spring framework sử dụng các mẫu adapter để triển khai ra nhiều chức
năng tách biệt của framework

-        The Target Interface: giao diện cho clients

19
 -        The Adapter class: Là class bọc bên ngoài triển khai các interface mong
muốn và chỉnh sửa yêu cầu có trong class Adapee

-        The Adaptee class: Class được class Adapter sử dụng để tái sử dụng
chức năng và chỉnh sửa chức năng sử dụng

-        Client: Class này sẽ giao tiếp với Adapter class

Mẫu cầu nối

-        Mẫu bridge cho ta 1 cách thức để giao tiếp giữa 2 phần tử độc lập nhau

-        Phân tách abstract class và implementer class

-        Bridge pattern sử dụng 1 interface như là cầu nối giữa các class và
abstract class và các class đang triển khai interface. Dễ dàng thay đổi
chúng mà không ảnh hưởng đến mã nguồn của client

Lợi ích của mẫu cầu nối

-        Cho phép phân tách các triển khai và các lớp thuần ảo

-        Linh hoạt trong việc thay đổi không ảnh hưởng code bên ngoài client

-        Che giấu các triển khai không cho client thấy bằng cách chỉ cho client
sử dụng các lớp abstract

20
Các vấn đề thường thấy đã bị loại bỏ khi áp dụng mẫu cầu

-        Xóa đi các liên kết giữa các chức năng ảo hóa và triển khai của nó

-        Dễ dàng thay đổi các lớp đang triển khai mà không ảnh hưởng client

-        Mở rộng abstraction và các triển khai bằng các lớp con

Triển khai mẫu cầu nối trong Spring Framework

       Các module spring dưới đây là dựa vào mẫu bridge:

-        ViewRenderServlet: Là bridge servlet, sử dụng cho hỗ trợ Portlet MVC

-        Mẫu cầu nối: The Bridge design pattern được sử dụng trong tiến trình
Spring logging

Mẫu composite

-        Các object trong hệ thống được gom trong cấu trúc cây, cấu trúc cây là
sự liên kết của các nút lá và nhánh

Các vấn đề thường thấy được giải quyết bằng mẫu composite

-        Mẫu Composite cho phép ta thiết kế các object để sử dụng các object

này như là 1 thành phần của các object khác và là 1 object riêng lẻ khác

-        Tạo ra cấu trúc cây có thứ bậc rõ ràng để cung cấp client với cách sử

21
dụng tương tự nhau

Cấu trúc UML của mẫu composite

       Mẫu composite dựa trên thành phần của cấu trúc cây, cây có 3 phần
là nhánh, node và lá

-        Component: là nhánh của cây, 1 nhánh thường có nhiều nhánh

nhỏ, nút, lá khác. Component cung cấp sự trừu tượng cho tất cả
thành phần bao gồm cả composite object. Trong mẫu Composite,
component là interface của các đối tượng

-        Leaf: là object triển khai các phương thức của component

-        Composite: Là node của cấu trúc cây, nó có nhiều node khác

và lá khác. Nó có các method để thêm con như là một collection
có cùng 1 kiểu object, nó bao gồm nhiều phương thức component
cho con

Lợi ích của mẫu composite

-        Cung cấp tính linh hoạt trong việc thêm component trong tiến trình, và
thay đổi trong các component hiện có

-        Cho phép tạo class có lớp cấp bậc rõ ràng bao gồm các object riêng rẻ
và các object hỗn hợp

22
 

Mẫu decorator

-        Decoratior design pattern cho phép thêm và loại bỏ các hành vi của các
object trong quá trình runtime một cách linh hoạt hoặc tĩnh mà không cần
thay đổi hành vi hiện có của các object từ cùng 1 class

-        Chia chức năng thành các concrete class

Lợi ích của mẫu decorator

-        Mở rộng chức năng một cách linh hoạt và tĩnh mà không phải thay đổi
cấu trúc của các object hiện có

-        Thêm linh hoạt các nhiệm vụ mới cho 1 object

-        Mẫu decorator còn được biết đến như là Warper

-        Sử dụng các thành phần cho các quan hệ của các object để duy trì
nguyên tắc SOLID

-        Triển khai mới class cho mỗi chức năng mới thay vì thay đổi code hiện
tại của ứng dụng

Các vấn đề thường thấy được giải quyết bằng mẫu Decorator

23
Các lớp và đối tượng tương tác với nhau:

-        Component (Account): Là interface của các object có trách nhiệm thêm

một cách linh hoạt

-        ConcreteComponent (SavingAccount): là concrete class của component

interface và nó khai báo 1 object mà trách nhiệm thêm có thể được đính
vào

-        Decorator (AccountDecorator): Liên quan đến component object và

khai báo interface phù hợp

-        ConcreteDecorator (SeniorCitizen and Privilege): là triển khai concrete

của mẫu decorator và nó thêm trách nhiệm đến các component

Mẫu Facade

       Lợi ích của mẫu Facade:

-        Giảm thiểu tính phức tạp cho client khi tương tác với các hệ thống con

-        Mẫu này kết hợp tất cả bussiness service như là một interface để dễ
dàng hiểu rõ

-         Mẫu giảm thiểu các phụ thuộc của mã nguồn client trong phần làm
việc của hệ thống

Nhân biết được khi cần sử dụng mẫu facade

       Ví dụ bạn cần phát triển một phần mềm bank cho doanh nghiệp với
nhiều service để làm việc bạn cần (AccountService, TranferService), Mã
nguồn của client sẽ tương tác với tất cả service này để chuyển tiền từ tài
khoản này sang tài khoản khác

24
      Mã nguồn client trực tiếp tương tác với các class trong hệ thống con,
có thể mô tả 1 hoặc nhiều interface giúp cho hệ thống con dễ sử dụng hơn

Mẫu ủy quyền

-        Cung cấp 1 đối tượng của 1 class với chức năng của tất cả class còn lại
cần tới nó

-        Mục đích của mẫu là cung cấp một class thay thế cho class khác, đi
cùng với đó là chức năng

25
Mục đích của mẫu ủy quyền

-        Mẫu Proxy ẩn giấu object xử lí không cho bên ngoài xem được

-        Tạo object theo nhu cầu nên có thể nâng cao hiệu suất

Cấu trúc UML của mẫu ủy quyền

-        Subject: Interface thật sự được triển khai bởi mẫu Proxy và RealSubject

-        RealSubject: Thực tế việc triển khai Subject, là một object thật sự rằng
được đại diện bởi Proxy

-        Proxy: Nó là một proxy object và nó cũng là triển khai của object thật
sự của Subject, nó duy trì việc giới thiệu đến object thật sự

3.2. Mẫu hành vi

-        Mẫu thuộc loại Behavioral là giao tiếp và hợp tác giữa các object để
vận hành một nhiệm vụ mà không một object nào có thể vận hành được

-        Mẫu thuộc loại này triển khai các phương pháp mà các class và object
liên kết và đóng góp nhiệm vụ

Mẫu xâu chuỗi nhiệm vụ

-        Mẫu chain of responsibility thuộc mẫu thể loại behavioral từ GOF

26
-        Sender và receivers của request được tách ra, sender gửi request đến
chuỗi của receivers và 1 trong số receiver object có thể đảm nhận request

Lợi ích của mẫu Chain of Responsibility:

-        Giảm thiểu sự liên kết giữa sender và receiver object trong hệ thống để
giải quyết request

-        Mềm dẻo trong việc xử lí các object được tham chiếu

-        Tạo một chuỗi object sử dụng tính thành phần, và tập các object này
làm việc như một đơn vị duy nhất

-        Handler: Là lớp ảo hoặc interface của hệ thống để xử lí request

-        ConcreteHandler: Là các concrete class mà thực thi những xử lí

request, hoặc đưa request đến phiên xử lí tiếp theo

-        Client: lớp ứng dụng để khởi tạo nên request cho các object xử lí
request trong chuỗi

Mẫu yêu cầu

-        Đóng gói request data trong 1 object và đưa các object đó như là mệnh
lệnh tới phương thức, trả về là mệnh lệnh là 1 object.

-        Cho phép truyền data như là object giữa các phần tử trong hệ thống
người gửi và nhận

-        Cho phép tham số hóa các object bởi action

27
-        Thêm các lệnh trong hệ thống mà không phải thay đổi class hiện tại

-        Command: Là interface hoặc lớp ảo có 1 action để xử lí hệ thống

-        ConcreteCommand: Là triển khai concrete của command interface và

tạo action

-        Client: Là class main, tạo ra một Concrete command object và gán cho
receiver

-        Invoker: Là Caller để kích request tới command object

-        Receiver: Là phương thức xử lí mà hiện thực các hoạt động bởi

concrete command

Mẫu thông dịch viên

       Mẫu interpreter cho phép bạn thông dịch một thể hiện ngôn ngữ
trong lập trình để khởi tạo một bản trình bày .

-        Cho phép thay đổi và kế thừa grammar dễ dàng

-        Sử dụng ngôn ngữ tự nhiên rất dễ

28
-        AbstractExpression: Là interface để thực thi nhiệm vụ bởi sử dụng
interpreter operation

-        AbstractExpression: Là các triển khai của interface và nó triển khai

hàm interpret()

-        NonterminalExpression: là triển khai của phần còn lại của interface và

nó triển khai interpret() operation

-        Context: Là chuỗi operation và nó bao gồm thông tin cục bộ cho thông
dịch

-        Client: Là class main để hành xử operation thông dịch

Mẫu trình lặp lại

-        Dễ dàng truy cập các item trong collection

-        Có thể truy cập nhiều item cùng lúc từ collection bởi vì nó hỗ trợ nhiều
các biến thể

-        Cung cấp một uniform interface để vượt qua nhiều cấu trúc khác nhau
trong collection

29
-        Iterator: Là interface hoặc lớp ảo để truy cập các items của collection

-        ConcreteIterator: Là triển khai của Iterator interface

-        Aggregate: Là interface để tạo ra iterator object

-        ConcreteAggregate: Là triển khai của Aggregate interface, nó triển khai

hàm tạo Iterator interface để trả về là instance của ConcreteIterator thích
hợp

Mẫu bản mẫu

       Trong mẫu template, một lớp ảo sẽ bao gói các khởi tạo vào method.
Method đó sẽ cho phép kế thừa không được sửa method này. Có thể sử
dụng concrete class trong phần mềm bạn để hành xử một số loại hành
động

       Lợi ích việc sử dụng mẫu template:

-        Giảm thiểu code bản mẫu trong phần mềm bằng việc sử dụng lại code

-        Mẫu tạo ra một số template hoặc cách thức để sử dụng lại nhiều thuật
toán để hiện thực các yêu cầu bài toán

30
-        AbstractClass: Là lớp ảo bao gồm các method của template là xương
sống của thuật toán

-        ConcreteClass: Là concrete class con của AbstractClass triển khai các

hoạt động của thuật toán

2. Mẫu thiết kế J2EE

       Mẫu thiết kế của Java EE cung cấp phương pháp kiểm thử và luyện
tập cho các tương tác của object trong nhiều tầng khác nhau của ứng dụng.
Bao gồm 3 phân lớp

·       Mẫu thiết kế của tầng presentation

·       Mẫu thiết kế của tầng business (xử lý login)

·       Mẫu thiết kế của tầng integration

Mẫu thiết kế của tầng trình bày:

·       View helper: Nó phân tách các view từ business logic của ứng dụng
J2EE doanh nghiệp

·       Front Controller: Cung cấp một điểm hành động để đảm nhiệm các
request đến ứng dụng J2EE, đưa các request đến các controller để truy cập
model và view cho tầng trình bày có dữ liệu

31
·       Application Controller: Request dược đảm nhiệm bởi controller, nó như
là một controller helper đứng bên ngoài. Phản hồi cho việc phối hợp với
tầng bussiness và view

·       Dispatcher View: Liên quan đến view và chỉ hoạt động mà không có
bussiness logic để sẵn sàng cho view tiếp theo

·       Intercepting filters: Cấu hình nhiều bộ lọc cho pre và post và request từ
user và kiểm kê các request từ user

Mẫu thiết kế trong tầng business:

·       Business Delegate: Là cầu nối giữa controller và business logic

·       Application service: Cung cấp các business logic để triển khai model
như là các java object cho tầng trình bày

Mẫu thiết kế trong tầng hội nhập:

· Data Access Object: được triển khai để truy cập data và nó phân tách
data truy cập logic từ business logic trong ứng dụng

· Web service broker: Đóng gói logic để truy cập tài nguyên ứng dụng và
nó lộ ra như là một web service

32
 4. Wiring Beans using the Dependency Injection Pattern.

1. The dependency injection pattern

Dependency injection là một mẫu thiết kế, thúc đẩy các lớp được
ghép nối lỏng lẻo trong ứng dụng. Điều này có nghĩa là các lớp trong hệ
thống phụ thuộc vào hành vi của những lớp khác, và không phụ thuộc vào
việc khởi tạo đối tượng của các lớp. Mẫu injection phụ thuộc cũng thúc
đẩy lập trình đến giao diện thay vì lập trình để thực thi. Các phụ thuộc đối
tượng phải nằm trên một giao diện chứ không phải trên các lớp cụ thể. Một
cấu trúc được kết hợp lỏng lẻo cung cấp cho bạn khả năng tái sử dụng, khả
năng bảo trì và khả năng test cao hơn.

2. Types of dependency injection patterns

4.1. Constructor-based dependency injection

Dependency injection là một mẫu thiết kế để giải sự phụ thuộc của

các lớp phụ thuộc, và các phụ thuộc chính là các thuộc tính. Injection phải
được xây dựng cho các đối tượng phụ thuộc bằng cách sử dụng một trong
các cách inject constructor hoặc setter. Việc chèn hàm tạo là một trong
những cách hoàn thành các thuộc tính đối tượng này tại thời điểm tạo để
khởi tạo đối tượng. Một đối tượng có một phương thức khởi tạo công khai
nhận các lớp phụ thuộc làm đối số của phương thức khởi tạo để đưa các
thành phần phụ thuộc vào. Bạn có thể khai báo nhiều hơn một hàm tạo vào
lớp phụ thuộc.

Điểm mạnh

Dựa trên cấu trúc phù hợp hơn với các phụ thuộc bắt buộc và nó tạo ra một
hợp đồng phụ thuộc mạnh mẽ.

Cung cấp một cấu trúc mã nhỏ gọn hơn các cấu trúc khác.

33
Hỗ trợ kiểm tra bằng cách sử dụng các phụ thuộc được chuyển làm đối số
của hàm tạo cho lớp phụ thuộc.

Sử dụng các đối tượng bất biến, và không phá vỡ nguyên tắc che giấu
thông tin.

Điểm Yếu
Nó có thể gây ra sự phụ thuộc vòng tròn

4.2. Setter-based dependency injection

Một trong những cách để thực hiện khởi tạo các phụ thuộc này là cung
cấp một phương thức setter trong lớp phụ thuộc. Đối tượng có một phương
thức setter public nhận các lớp phụ thuộc làm đối số phương thức để đưa
vào các phụ thuộc. Đối với việc tiêm phụ thuộc dựa trên setter, hàm tạo
của lớp phụ thuộc không bắt buộc. Không có thay đổi nào được yêu cầu
nếu bạn thay đổi các phụ thuộc của lớp phụ thuộc.

Điểm mạnh

Dễ đọc hơn so với chèn constructor

Giải quyết vấn đề phụ thuộc vòng tròn trong ứng dụng

Cho phép các tài nguyên hoặc dịch vụ tốn kém được tạo càng muộn càng
tốt và chỉ khi cần thiết

Không yêu cầu thay đổi hàm tạo, nhưng các phụ thuộc được chuyển qua
các thuộc tính công khai được hiển thị

Điểm Yếu

Tính bảo mật thấp hơn trong mẫu chèn setter, vì nó có thể bị ghi đè.

Việc chèn phụ thuộc dựa trên setter không cung cấp cấu trúc mã nhỏ gọn
như chèn hàm tạo Hãy cẩn thận bất cứ khi nào bạn sử dụng setter
injection, vì nó không phải là phụ thuộc bắt buộc

1. Configuring the dependency injection pattern with Spring

34
Cấu hình dựa trên Java — đó là một file cấu hình rõ ràng trong Java
(AppConfig.java).

Cấu hình dựa trên chú thích — nó là một khám phá bean ngầm và liên kết
tự động.

Cấu hình dựa trên XML — nó là một file cấu hình rõ ràng trong
XML(Application.XML).
2. Annotating beans for autowiring Lookup-method injection
pattern

Spring hỗ trợ tự động tiêm phụ thuộc. Điều này có nghĩa là Spring tự động
giải quyết các phụ thuộc được yêu cầu bằng cách tìm các bean cộng tác
trong ngữ cảnh ứng dụng. Bean Autowiring là một cách khác của cấu hình
mẫu DI. Nó làm giảm tính dài dòng trong ứng dụng. Chú thích
@Autowired mong muốn của Spring được sử dụng để nối dây đậu tự
động. Chú thích @Autowired này cho biết rằng sẽ thực hiện tự động khởi
tạo cho bean này.

Có thể dùng trên Constructor, setter và cả Field.

3. Implementing the Abstract Factory Pattern in Spring

Spring Framework cung cấp FactoryBean như một phần triển khai
của mẫu Nhà Máy. FactoryBean là một mẫu để đóng gói logic xây dựng
đối tượng thú vị trong một lớp. Giao diện FactoryBean cung cấp một cách
để tùy chỉnh logic khởi tạo của Spring IoC container. Bạn có thể triển khai

35
giao diện này cho các đối tượng tự là nhà máy. Bean thực hiện
FactoryBean được tự động phát hiện.

4. Implementation of FactoryBean interface in Spring

FactoryBean được sử dụng rộng rãi trong Spring:

a) EmbeddedDatabaseFactoryBean

b) JndiObjectFactoryBean

c) LocalContainerEntityManagerFactoryBean

d) DateTimeFormatterFactoryBean

e) ProxyFactoryBean

f) TransactionProxyFactoryBean

g) MethodInvokingFactoryBean

5. Ví dụ 22 mẫu đã học và 7 mẫu bổ sung

5.1. Structural Pattern:

1. Mẫu Adapter:

- Adapter Pattern giữ vai trò trung gian giữa hai lớp, chuyển đổi interface
của một hay nhiều lớp có sẵn thành một interface khác, thích hợp cho lớp
đang viết. Điều này cho phép các lớp có các interface khác nhau có thể dễ

36
dàng giao tiếp tốt với nhau thông qua interface trung gian, không cần thay
đổi code của lớp có sẵn cũng như lớp đang viết.

- Code ví dụ: ta có một ứng dụng chỉ tương thích với class hiển thị tiếng
Việt bây giờ ta muốn chương trình hoạt động bằng tiếng Anh. Nhờ mẫu
Adapter ta dễ dàng có thể triển khai một lớp mới mà không cần phải thay
đổi bên trong lớp tiếng Việt.

- Class diagram:

2. Bridge:

- Bridge Pattern dùng để tách phần trừu tượng ra khỏi phần hiện thực. Có
nghĩa là ban đầu chúng ta thiết kế một class với rất nhiều xử lý, bây giờ
chúng ta không muốn để những xử lý đó trong class đó nữa. Vì thế, chúng
ta sẽ tạo ra một class khác và move các xử lý đó qua class mới. Khi đó,
trong lớp cũ sẽ giữ một đối tượng thuộc về lớp mới, và đối tượng này sẽ
chịu trách nhiệm xử lý thay cho lớp ban đầu.

- Code ví dụ: ta xây dựng một hệ thống cung cấp các loại tài khoản cho

37
khách hàng và hỗ trợ nhiều ngân hàng khác nhau, nếu không áp dụng mẫu
Bridge thì bấy nhiêu ngân hàng và bấy nhiêu loại tài khoản sẽ có bấy nhiêu
class. Vậy ta sẽ tách phần tài khoản ra khỏi ngân hàng

- Class diagram:

3. Mẫu Composite:

- Code ví dụ: ta có các phòng ban, có các phòng ban trực thuộc phòng
ban khác và các phòng ban trực thuộc này lại có phòng ban khác trực
thuộc khác, tạo nên một cây phân cấp. Ta muốn biết tên của các phòng ban
này. Rất khó nếu tiếp cận với cách bình thường là lặp qua mọi phòng ban
để lấy tên bởi vì ta khó mà biết được số cấp của phòng ban và kiểu dữ liệu
để chứa mỗi phòng ban là khác nhau.

- Ở mẫu composite, các phòng ban sẽ triển khai chung một interface có
phương thức trả về tên phòng ban. Mỗi phòng ban có nhiệm vụ chính là trả
về tên. Đối với phòng ban có phòng ban khác trực thuộc nó sẽ lặp qua mỗi
phòng ban trực thuộc và lấy tên.

- Class diagram:

38
 4. Mẫu Decorator:

- Code ví dụ: ta có một chương trình có chức năng nén, mã hóa khi ghi
ra file. Đồng thời có chức năng giải nén, giải mã khi đọc file. Lúc đầu ta
có thể nghĩ đến mẫu bridge để áp dụng cho ví dụ này nhưng có yêu cầu ở
đây là bên phía client có thể tùy ý thêm nhiều các chức năng ngoài nén và
mã hóa.

- Ý tưởng của mẫu Decorator khá là giống với mẫu Adapter là sử dụng
đối tượng bọc nhưng mục đích của hai mẫu này là khác nhau. Adapter là
cung cấp (biến đổi) interface của đối tượng, còn Decorator là tăng cường
thêm hành vi cho interface

- Các class trong mẫu Decorator thực hiện chung một interface. Mẫu
này hoạt động dựa vào đệ quy, khi đối tượng này thực hiện phương thức
này sẽ ủy thác cho đối tượng được bọc thực hiện phương thức tương tự.

- Class diagram:

39
 5. Mẫu Facade:

- Code ví dụ: ta có các lớp là thành phần của động cơ. Để khởi động
động cơ ta cần phải trải qua nhiều bước, qua nhiều hệ thống. Ta cần phải
có một class để điều khiển các hoạt động này, cách làm này khá giống với
controller trong MVC

- Mẫu Façade cách làm khá giống với mẫu Mediator vì hai mẫu này sinh
ra để tổ chức sự hợp tác của các lớp. Điều khác ở đây ở mẫu Façade là các
hệ thống con có thể tương tác được với nhau là các hệ thống con không hề
biết gì về Façade.

- Mẫu Façade thường dùng để tạo giao tiếp giữa các hệ thống này qua hệ
thống khác hay là lúc ta sử dụng framework.

- Class Diagram:

6. Mẫu Flyweight:

- Mẫu Flyweight đúng với cái tên của nó là làm giảm bộ nhớ của hệ thống

40
hay còn gọi là cache. Bằng cách lưu các trạng thái không đổi của đối
tượng sang một đối tượng cache, khi tạo đối tượng ta sẽ lấy trạng thái
không đổi ở trong cache đưa vào.

- Code ví dụ: ta muốn vẽ hoa trên canvas, các trạng thái không đổi của hoa
là tên và màu sẽ được đưa vào class FlowerFactory. Khi đối tượng Garden
thực hiện phương thức plantFlower, ta sẽ tạo đối tượng hoa ta lấy trạng
thái không đổi từ đối tượng Factory đưa vào constructor của Flower.

- Class Diagram:

7. Mẫu Proxy:

- Mục đích của mẫu proxy là thay vì truy cập trực tiếp vào đối tượng thì
ta sẽ truy cập vào đối tượng đại diện. Đối tượng proxy sẽ triển khai giao
diện giống với đối tượng thực và bọc nó. Khi đối tượng proxy thực hiện
phương thức nó sẽ gọi phương thức của đối tượng thực.

- Class Digram:

5.2. Creational Pattern:

41
 8. Mẫu Factory Method:

- Mẫu Factory được dùng để tạo đối tượng, mục đích của mẫu này khá
nhiều. Dùng mẫu khi chưa biết trước các loại đối tượng nào sẽ được khởi
tạo (if else). Trong mẫu factory method các lớp con là lớp chính chịu trách
nhiệm tạo đối tượng vì thế hệ thống rất dễ dàng mở rộng bằng cách tạo lớp
con mới triển khai lớp cha đã có. Ta có thể tiết kiệm tài nguyên khi phải
tạo các đối tượng giống nhau nhiều lần. Thường trong hệ thống lớn các đối
tượng phải hoạt động ăn khớp với nhau, sử dụng mẫu factory để kiểm soát
đối tượng được tạo để hệ thống được hoạt động trơn tru.

- Code ví dụ: ta có các text view: text dành cho window và text dành cho
web. Tùy thuộc vào hệ thống thì sẽ render các text khác nhau. Ví dụ này là
lợi ích đầu tiên của mẫu factory là chưa biết trước là đối tượng nào sẽ
được khởi tạo.

- Class Diagram:

9. Abstract Factory:

- Mẫu Factory có mục đích là tạo một loại đối tượng, nếu ta muốn tạo ra
một bộ các đối tượng ăn khớp với nhau thì như thế nào. Trong 22 mẫu của
GoF đã giới thiệu một mẫu có tên là Abstract Factory, mẫu này kế thừa
những ưu điểm của Factory Method và cho phép chúng ta tạo ra các bộ đối
tượng.

- Code ví dụ: ta có bộ các GUI là Input và Label, ta muốn cho các GUI
này hoạt động được trên cả window và macOS.

- Class Diagram:

42
 10. Builder:

- Mẫu Builder giúp ta tạo đối tượng bằng cách các tùy chọn, tinh chỉnh.
Giúp ta xây dựng đối tượng phức tạp từng bước.

- Code ví dụ: ta muốn tạo ra chương trình để tạo ta câu lệch SQL, để tạo
ra câu lệch sql rất phức tạp, các câu lệch thêm bớt tùy chỉnh rất linh hoạt vì
vậy mẫu builder rất phù hợp.

- Class Diagram:

11. Singleton:

- Singleton là một mẫu dùng để tạo ra instance duy nhất trên hệ

43
thống thường dùng để truy cập vào tài nguyên như File hay Database.

- Ví dụ dưới đây là tạo ra instance duy nhất để kết nối vào database

12. Prototype:

- Mẫu prototype dùng để sao chép đối tượng, mẫu này cực hữu ích
khi được dùng để sao chép các đối tượng phức tạp được tạo từ mẫu như
Composite và Decorator giúp giảm thời gian để tạo lại từ đầu

- Code ví dụ: Máy tính trong nhà trường gồm: Hệ điều hành (os), Phần
mềm văn phòng (office), Phần mềm diệt virus (antivirus), Trình duyệt
(Browser), và một số phần mềm khác (others). Việc cài đặt tất cả phần
mềm trên rất tốn thời gian, nên anh IT đã nghĩ ra một cách là sẽ tạo ra một
bản chuẩn cho một máy tính và có thể clone() lại cấu hình đó từ đầu.

- Class Diagram

44
 5.3. Behavior Pattern:

13. Chain of Responsibility:

- Mẫu Chain of Responsibility là mẫu dùng để chuyển yêu cầu xử lý

từ đối tượng này sang đối tượng khác. Khi đối tượng nhận được yêu cầu
nó sẽ có quyền quyết định là nó xử lý yêu cầu này không hay chuyển qua
cho đối tượng khác.

- Mẫu này thường được sử dụng khi chương trình sẽ đi qua các trình
xử lý yêu cầu khác nhau nhưng ta vẫn chưa biết chính xác là cần bao nhiêu
trình xử lý.

- Code ví dụ: ta có một chương trình để filter việc login của người
dùng. Khi người dùng login vào hệ thống, thì sẽ qua các giai đoạn filter
như sau: kiểm tra tải hệ thống → kiểm tra tài khoản mật khẩu → kiểm tra
quyền người dùng. Tài khoản của người dùng sẽ trải qua từng filter, nếu
filter này pass thành công sẽ chuyển qua cho filter khác nếu không sẽ dừng
lại.

- Class diagram:

45
 14. Command:

- Mẫu Command có mục đích dùng để tách rời logic thực hiện hành
động ra khỏi đối tượng yêu cầu hành động, ngoài ra nhờ cách tách rời
logic yêu cầu hành động ta có thể đưa các yêu cầu này cho nhiều đối tượng
khác nhau. Ví dụ: khi ta đến nhà hàng ngồi vào bàn và gọi nhân viên sẽ
đến và ghi lại menu chuyển qua cho đầu bếp, ở đây khách hàng không trực
tiếp đưa menu cho đầu bếp mà đã đóng gói command (menu) cho phục vụ.
Ưu điểm: ta có thể thực hiện hành động undo/redo, bằng cách đóng gói các
lệnh lại ta có thể dàng tái sử dụng.

- Code ví dụ: ta có một hệ thống ngân hàng cung cấp ứng dụng cho khách
hàng (client) có thể mở (open) hoặc đóng (close) tài khoản trực tuyến.

- Class Diagram:

46
 15. Iterator:

- Iterator như với cái tên, mẫu này được dùng để lặp qua các phần tử
của một collection mà không cần phải biết chi tiết bên trong các tử này,
chỉ cần cho các item triển khai cùng một interface. Ví dụ: ta có các cấu
trúc như: HashTabel, Stack, Queue, LinkedList... Để truy cập vào từng
item của các cấu trúc khá là khó khăn dó cách truy xuất item của mỗi cấu
trúc là khác nhau. Sử dụng mẫu Iterator tuyên bố một interface chung triển
khai method để truy cập đến từng phần tử.

- Ở các ngôn ngữ hiện đại (c#...), vòng lặp for sử dụng interface rất
giống với mẫu Iterator để lặp qua các item, sử dụng mẫu Iterator để bạn có
thể tùy chỉnh cho vòng lặp của mình

- Code ví dụ: ta muốn tạo đối tượng Iterator để lưu trữ các từ sau đó
dùng vòng lặp để in ra các thành phần có trong nó.

- Class Diagram:

47
 16. Mediator:

- Đây là một mẫu dùng để kiểm soát sự phụ thuộc hỗn loạn giữa các
đối tượng với nhau. Thay vì cho phép các đối tượng phụ thuộc trực tiếp
với nhau như vậy, ta sẽ ràng buộc các đối tượng để giao tiếp được với các
đối tượng khác phải qua đối tượng trung giang.

- Mẫu này khá giống mẫu Façade chỉ khác nhau đó chính là các đối
tượng con biết về đối tượng trung gian và không giao tiếp trực tiếp, còn
Façade thì các đối tượng con không giao tiếp với nhau cũng không biết
đến đối tượng trung giang.

- Code ví dụ: ta có một chương trình chat nhóm khi một thành viên chat thì
tất cả các thành viên khác trong room đều nhận được. Thay vì cho phép
lớp user tự phải tìm các thành viên trong room, kiểm tra xem thành viên có
đang online hay là thành viên đó có muốn nhận chat từ mình không. Ta sử
dụng mẫu Mediator thì user không cần phải quan tâm, chỉ cần gửi chat cho
mediator lo liệu.

- Class Diagram

48
 17. Memento:

- Đôi khi chúng ta cần phải ghi lại trạng thái bên trong của một đối
tượng. Chúng ta cần lưu các trạng thái này ở đối tượng nào đó. Nhưng có
vấn đề ở đây là các thuộc tính của đối tượng lưu trữ để public thì dễ bị tác
nhân bên ngoài thay đổi, private thì khó mà truy cập được. Mẫu memento
sẽ giúp ta giải quyết vấn đề này.

- Code ví dụ: ta muốn tạo chương trình để quản lý tọa độ, chương
trình cho phép chúng ta khôi phục lại dữ liệu tại thời điểm trước đó

- Class Diagram:

49
 18. Observer:

- Trong trường hợp khi một số đối tượng nhất định cần được thông
báo thường xuyên về những thay đổi xảy ra trong các đối tượng khác. Mẫu
Observer có thể được sử dụng bất cứ khi nào mà một đối tượng có sự thay
đổi trạng thái, tất các thành phần phụ thuộc của nó sẽ được thông báo và
cập nhật một cách tự động.

- Code ví dụ: ta có một đối tượng chứa các số liệu về thời tiết và các
đối tượng dùng để hiển thị các số liệu này, dùng mẫu Observer để khi số
liệu trong đối tượng thời tiết thay đổi thì các đối tượng hiển thị sẽ ngay lập
tức cập nhật số liệu mới.

- Class Diagram:

19. Strategy:

- Có một vài trường hợp, các lớp chỉ khác nhau về hành vi của

50
chúng. Trong trường hợp như vậy, ý tưởng tốt là chúng ta sẽ tách biệt các
thuật toán trong các lớp riêng biệt để có khả năng lựa chọn các thuật toán
khác nhau trong thời gian chạy (run-time). Ý tưởng này được gọi là
Strategy Pattern, một pattern giúp chúng ta giải quyết vấn đề về sự thay
đổi.

- Code ví dụ: ta có một chương trình triển khai nhiều giải thuật sắp
xếp khác nhau (QuickSort, MergeSort…) để sắp xếp lại danh sách. Bằng
cách sử dụng mẫu Strategy ta có thể hoán đổi linh hoạt các giải thuật mà
không cần phải tạo thêm class mới, ví dụ: SortedList, MergeSort…

- Class Diagram:

20. Template Method:

- Trong quá trình phát triển ứng dụng một số lớp có các thuật toán
gần như giống nhau, chỉ khác nhau ở vài chi tiết nhỏ, do đó ta phải sửa đổi
lại thuật toán ban đầu.

- Template Method là mẫu dùng để định nghĩa trước bộ khung cho

thuật toán còn chi tiết về cách triển khai thì sẽ giao lại cho các lớp con
đảm nhận.

- Thông thường trong giải thuật sắp xếp, các thành phần trong
collection đều là các con số nguyên thủy nếu ta muốn thực hiện sắp xếp
cho các thành phần có cấu trúc dữ liệu phức tạp thì như thế nào.

- Code ví dụ: sử dụng mẫu Template Method để sắp xếp theo tuổi,

51
theo tên cho cấu trúc dữ liệu học sinh.

- Class Diagram:

21. Visitor:

- 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.

- Code ví dụ: ta có một chương trình truy cập vào các trường của các
shape để xuất ra định dạng XML

- Class Diagram:

52
 22. State:

- State Pattern là mẫu cho phép đối tượng có nhiều hành vi dựa vào
trạng thái bên trong của nó, đối tượng có được hành vi nhờ ủy thác cho đối
tượng mang trạng thái. Mẫu State khá giống với mẫu Strategy, nhưng mẫu
State thay đổi hành vi dựa vào trạng thái của nó, mẫu Strategy tự mình
quyết định nên sử dụng hành vi nào.

- Code ví dụ: ta cần xây dựng một ứng dụng quản lý Document. Một
Document có thể bao gồm các trạng thái: tạo mới (New), đã đăng
(Submitted), phê duyệt (Approved) và từ chối (Rejected).

- Class Diagram:

53
 5.4. Các mẫu mở rộng:

23. Null object:

- Null Object Pattern là một trong những Pattern thuộc nhóm hành vi
(Behavior Pattern). Null Object pattern không phải là một Gang of Four
Design Pattern.

Tư tưởng của Null Object là sử dụng một đối tượng Null đặc biệt để
gói gọn sự vắng mặt của một thể hiện bằng cách cung cấp một sự thay thế
hành xử theo cách thụ động phù hợp.

Các thành phần tham gia Null Object Pattern:

AbstractObject : định nghĩa các hành vi mà một đối tượng có thể có.

RealObject : một triển khai thực sự của AbstractObject thực hiện

một số hành động thực tế.

NullObject : một triển khai không làm gì hoặc trả về giá trị mặc định
của AbstractObject, để cung cấp một đối tượng không null cho Client.

Client : nhận được một triển khai của AbstractObject và sử dụng nó.
Nó không thực sự quan tâm đó là một NullObject hoặc RealObject vì cả
hai đều được sử dụng theo cùng một cách.

54
 24. Interpreter Pattern:

- Interpreter Pattern là một trong những Pattern thuộc nhóm hành vi

(Behavior Pattern).

Interpreter nghĩa là thông dịch, mẫu này nói rằng “để xác định một
biểu diễn ngữ pháp của một ngôn ngữ cụ thể, cùng với một thông dịch
viên sử dụng biểu diễn này để diễn dịch các câu trong ngôn ngữ”.
nterpreter Pattern có hạn chế về phạm vi áp dụng. Mẫu này thường được
sử dụng để định nghĩa bộ ngữ pháp đơn giản (grammar), trong các công cụ
quy tắc đơn giản (rule), …

Các thành phần tham gia mẫu Interpreter:

· Context : là phần chứa thông tin biểu diễn mẫu chúng ta cần
xây dựng.

· Expression : là một interface hoặc abstract class, định nghĩa

phương thức interpreter chung cho tất cả các node trong cấu trúc cây phân
tích ngữ pháp. Expression được biểu diễn như một cấu trúc cây phân cấp,
mỗi implement của Expression có thể gọi một node.

55
 · TerminalExpression (biểu thức đầu cuối): cài đặt các phương
thức của Expression, là những biểu thức có thể được diễn giải trong một
đối tượng duy nhất, chứa các xử lý logic để đưa thông tin của context
thành đối tượng cụ thể.

· NonTerminalExpression (biểu thức không đầu cuối): cài đặt

các phương thức của Expression, biểu thức này chứa một hoặc nhiều biểu
thức khác nhau, mỗi biểu thức có thể là biểu thức đầu cuối hoặc không
phải là biểu thức đầu cuối. Khi một phương thức interpret() của lớp biểu
thức không phải là đầu cuối được gọi, nó sẽ gọi đệ quy đến tất cả các biểu
thức khác mà nó đang giữ.

· Client : đại diện cho người dùng sử dụng lớp Interpreter

Pattern. Client sẽ xây dựng cây biểu thức đại diện cho các lệnh được thực
thi, gọi phương thức interpreter() của node trên cùng trong cây, có thể
truyền context để thực thi tất cả các lệnh trong cây.

56
 25. MVC Pattern:

· Model – View – Controller (MVC) Pattern là một mẫu thiết kế

nhằm mục tiêu chia tách phần giao diện và code để dễ quản lý, phát triển
và bảo trì.

· MVC Pattern là một dạng Architectural Design Pattern được

áp dụng để xử lý các vấn đề liên quan đến kiến trúc ứng dụng.

· MVC Pattern tuân thủ nguyên tắc thiết kế Separation of

Concern, giúp phân tách logic của các tầng (layer) khác nhau trong một
chương trình thành các đơn vị độc lập.

· MVC chia ứng dụng phần mềm ra làm 3 phần có tương tác với
nhau: Model (dữ liệu), View (giao diện), Controller (điều khiển tương tác
giữa Model và View).

Các thành phần tham gia MVC Pattern:

· Model : là nơi lưu trữ dữ liệu người dùng, chứa business logic.
Nó cho phép truy xuất dữ liệu để hiển thị hoặc thu thập dữ liệu. Model là
cầu nối giữa thành phần View và Controller. Mục đích quan trọng nhất của
nó là kết nối cơ sở dữ liệu (database), xử lý dữ liệu và chuẩn bị dữ liệu để
chuyển đến các thành phần khác.

· View : là giao diện của hệ thống, nơi dữ liệu (Model) được hiển
thị, nhận tương tác trực tiếp với người dùng. Trong ứng dụng web, View là
một phần của hệ thống, nơi mà các mã HTML được sinh ra và hiển thị.
Một vấn đề quan trọng là View không được lấy dữ liệu trực tiếp từ
Controller mà phải thông qua Model.

· Controller : nhận yêu cầu, dữ liệu từ người dùng, sau đó cập

nhật sang Model và cuối cùng trả kết quả lại View để show kết quả cho
người dùng. Controller không chứa bất kỳ logic nghiệp vụ nào.

57
 26. Dependency Injection Pattern:

Với lập trình hướng đối tượng, chúng ta thường xuyên làm việc với
rất nhiều class trong một chương trình, các class được liên kết với nhau
theo một mối quan hệ nào đó. Dependency là một loại quan hệ giữa 2 class
mà trong đó một class hoạt động độc lập và class còn lại phụ thuộc bởi
class kia. Sự phụ thuộc chặt chẽ này gây rất nhiều khó khăn khi hệ thống
cần thay đổi, nâng cấp. Để giải quyết vấn đề này chúng ta có thể sử dụng
Dependency Injection (DI), một dạng design pattern được thiết kế nhằm
ngăn chặn sự phụ thuộc nêu trên.

58
 27. Dao Pattern:

Data Access Object (DAO) Pattern là một trong những Pattern thuộc
nhóm cấu trúc (Structural Pattern). Mẫu thiết kế DAO được sử dụng để
phân tách logic lưu trữ dữ liệu trong một lớp riêng biệt. Theo cách này, các
service được che dấu về cách các hoạt động cấp thấp để truy cập cơ sở dữ
liệu được thực hiện. Nó còn được gọi là nguyên tắc Tách logic (Separation
of Logic).

Các thành phần tham gia mẫu Data Access Object (DAO) Pattern:

· BusinessObject : đại diện cho Client, yêu cầu truy cập vào
nguồn dữ liệu để lấy và lưu trữ dữ liệu.

· DataAccessObject (DAO): là một interface định nghĩa các

phương thức trừu tượng việc triển khai truy cập dữ liệu cơ bản cho
BusinessObject để cho phép truy cập vào nguồn dữ liệu (DataSource).

· DataAccessObjectConcrete : cài đặt các phương thức được

59
định nghĩa trong DAO, lớp này sẽ thao tác trực tiếp với nguồn dữ liệu
(DataSource).

· DataSource : là nơi chứa dữ liệu, nó có thể là database, xml,

json, text file, webservice,.

· TransferObject : là một POJO (Plain old Java object) object,

chứa các phương thức get/set được sử dụng để lưu trữ dữ liệu và được sử
dụng trong DAO class.

28. Intercepting Filter

Intercepting filter pattern là một Java EE pattern, được sử dụng khi

muốn thực hiện một vài xử lý trước (pre-processing) khi request được ứng
dụng đích (target) xử lý hoặc sau (post-processing) khi response được trả
về từ target.

Các Filter được định nghĩa và áp dụng trên yêu cầu (request) khi
chuyển request đến ứng dụng đích thực tế (target). Các Filter có thể thực
hiện xác thực (authentication), ủy quyền (authorization), nén dữ liệu
(compressing), ghi nhật ký (logging) hoặc theo dõi yêu cầu (tracking) và
sau đó chuyển yêu cầu đến các trình xử lý tương ứng.

Các thành phần tham gia mẫu Intercepting filter pattern:

· Filter : chịu trách nhiệm thực hiện một vài xử lý trước khi
request được target xử lý hoặc sau khi response được trả về từ target.

· Target : là một đối tượng xử lý lý chính, một trình xử lý yêu

cầu.

· Filter chain : chứa một chuỗi các Filter sẽ được thực hiện trên
target theo thứ tự được xác định.

· Filter manager : quản lý các Filter và Filter Chain.

· Client : đối tượng gửi request đến target hoặc nhận response từ
target.

60
 29. Service locator Pattern

Service Locator là một design pattern thông dụng cho phép tách rời
(decouple) một class với các dependency (hay được gọi là service) của nó.
Service Locator có thể coi là một đối tượng trung gian trong việc liên kết
class và các dependency.

Service Locator pattern mô tả cách để đăng ký và lấy các

dependency để sử dụng. Thông thường Service Locator được kết hợp với
Factory Pattern hoặc Dependency Injection Pattern để có thể tạo ra các
instance của service.

61
 Tài Liệu Tham Khảo

Spring 5 design pattern

https://libribook.com/ebook/7950/spring-5-design-patterns-pdf/?
bookid=45368

Behavior Pattern

https://gpcoder.com/category/design-pattern/behavior-pattern/

Creational Pattern

https://gpcoder.com/category/design-pattern/creational-pattern/

Structural Pattern

https://gpcoder.com/category/design-pattern/structuaral-pattern/

62