BaoCao_22DesignPatterns.docx

Mục lục
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT THÀNH PHỐ HỒ CHÍ MINH
KHOA ĐÀO TẠO CHẤT LƯỢNG CAO
NGÀNH CÔNG NGHỆ THÔNG TIN
MẪU THIẾT KẾ PHẦN MỀM
BÁO CÁO NỘI DUNG LÝ THUYẾT 22 MẪU
DESIGN PATTERNS
GVHD: ThS. Nguyễn Minh Đạo
SVTH: Nguyễn Ngọc Thuyên MSSV: 19110296
SVTH: Lê Quốc Vinh MSSV: 19110029
SVTH: Đặng Huỳnh Hoàng Long MSSV: 17110173
Thành phố Hồ Chí Minh, tháng 03 năm 2022

Tổng quan về 22 mẫu Design Patterns:................................................................................. 3
I. Creational design patterns:.................................................................................................. 4
1. Factory Method:................................................................................................................ 4
2. Abstract Factory:............................................................................................................... 6
3. Builder:.............................................................................................................................10
4. Prototype:.........................................................................................................................13
5. Singleton: .........................................................................................................................15
II. Structural design patterns:...............................................................................................17
1. Adapter:............................................................................................................................17
2. Bridge:..............................................................................................................................22
3. Composite:.......................................................................................................................24
4. Decorator:.........................................................................................................................26
5. Façade:..............................................................................................................................28
6. Flyweight: ........................................................................................................................30
7. Proxy: ...............................................................................................................................34
III. Behavioral design patterns: ............................................................................................38
1. Chain of responsibility:.......................................................................................................38
a. Khái niệm .........................................................................................................................38
b .Mục đích sử dụng mẫu thiết kế .....................................................................................38
c. Cấu trúc: ...........................................................................................................................39
d. Những trường hợp sử dụng mẫu...................................................................................40
e. Ưu nhược điểm................................................................................................................40
2. Command: .............................................................................................................................40
a. Khái niệm .........................................................................................................................40
c. Cấu trúc: ...........................................................................................................................41
e. Ưu nhược điểm................................................................................................................42
3. Iterator: ..................................................................................................................................42
a. Khái niệm .........................................................................................................................42
c. Cấu trúc: ...........................................................................................................................44
e. Ưu nhược điểm................................................................................................................45
4. Mediator:................................................................................................................................45
a. Khái niệm .........................................................................................................................45
c. Cấu trúc: ...........................................................................................................................47
e. Ưu nhược điểm................................................................................................................48
5. Memento: ...............................................................................................................................49
a. Khái niệm:........................................................................................................................49

c. Cấu trúc: ...........................................................................................................................50
e. Ưu nhược điểm................................................................................................................51
6. Observer:................................................................................................................................52
a. Khái niệm .........................................................................................................................52
c. Cấu trúc: ...........................................................................................................................54
e. Ưu nhược điểm................................................................................................................55
7. State: .......................................................................................................................................55
a. Khái niệm .........................................................................................................................55
c. Cấu trúc: ...........................................................................................................................57
e. Ưu nhược điểm................................................................................................................58
8. Strategy: .................................................................................................................................59
a. Khái niệm .........................................................................................................................59
c. Cấu trúc: ...........................................................................................................................59
e. Ưu nhược điểm................................................................................................................61
9. Template Method:................................................................................................................61
a. Khái niệm .........................................................................................................................61
c. Cấu trúc: ...........................................................................................................................62
e. Ưu nhược điểm................................................................................................................63
10. Visitor:..................................................................................................................................63
a. Khái niệm .........................................................................................................................63
c. Cấu trúc: ...........................................................................................................................64
e. Ưu nhược điểm................................................................................................................66
Tổng quan về 22 mẫu Design Patterns:
Bao gồm có 3 loại:

- Creational patterns: Các mẫu này cung cấp các cơ chế tạo đối tượng khác nhau, giúp
tăng tính linh hoạt và khả năng tái sử dụng mã hiện có.
- Structural patterns: Các mẫu này giải thích cách tập hợp các đối tượng và lớp thành các
cấu trúc lớn hơn trong khi vẫn giữ cho các cấu trúc này linh hoạt và hiệu quả.
- Behavioral patterns: Các mẫu này liên quan đến các thuật toán và sự phân công trách
nhiệm giữa các đối tượng.
I. Creational design patterns:
1. Factory Method:
Factory method (hay còn gọi là virtual constructor) là một mẫu thiết kế thuộc nhóm
Creational Patterns – những mẫu thiết kế cho việc khởi tạo đối tượng của lớp khi chúng ta
muốn tạo ra một object của một type nào đấy, nhưng chúng ta không biết rõ mình sẽ phải
tạo ra cái gì, mà nó phải dựa vào một số điều kiện business logic đầu vào để tạo ra object
tương ứng, thì chúng ta có thể sử dụng Factory Method này.
a. Khái niệm
Factory Method cung cấp một interface, phương thức trong việc tạo nên một đối tượng
(object) trong class. Nhưng để cho class con kế thừa của nó có thể ghi đè để chỉ rõ đối
tượng (object) nào sẽ được tạo. Factory method giao việc khởi tao một đối tượng (object)
cụ thế cho lớp con (subclass).
b. Mục đích sử dụng của mẫu thiết kế
Vấn đề:
Chúng ta tạo ra 1 app tạo Button và xử lý nó. Đầu tiên chúng ta ra app chỉ có 1 loại Button
là Rectangle Button. Và chúng ta viết hàng đống code ở bên trong class.
Sau này, khi app trở nên nổi tiếng, và Circle Button đang là trend. Vì thế ta thêm Circle
Button. Thế là ta sửa lại code từ đầu, chỗ nào có Rectangle Button thì chúng ta cũng phải
sửa thêm cho Circle Button. Tuy mệt, nhưng cũng chẳng có gì khó khăn.
Thế nhưng sau này app muốn thêm 100 loại Button, hay các chức năng khác, obj khác, ta
có sẵn sàng ngồi viết lại từ trên xuống dưới?
Vậy ta phải làm sao?

Ý tưởng:
Tạo 1 nhà máy, thay vì gọi trực tiếp để tạo obj, thì ta sẽ thông qua method của nhà máy
trả về đối tượng.
Nếu nhìn qua, ta thấy nó chẳng có gì mới, thay vì tạo biến ở class hiện tại, thì ta để vào
một class khác. Nhưng ta có thể override Factory class và thay đổi method tạo obj.
Hạn chế là ở factory method method tạo obj phải có kiểu dữ liệu là base class hoặc
interface của class con.
c. Cấu trúc
Các thành phần trong mô hình:
- Product : Định nghĩa một khuôn mẫu (interface) của các đối tượng mà factory method
tạo ra.
- Concreteproduct: các lớp được cài đặt khuôn mẫu product.
- Creator: Khai báo factory method, trả về kiểu đối tượng thuộc kiểu product. Creator
cũng có thể định nghĩa một cài đặt mặc định của factory method mà giá trị trả về là một
đối tượng concreteproduct mặc định.
- Gọi factory method để tạo đổi tượng kiểu product.
- ConcreteCreator: ghi đè factory method để trả về một instance của concreteproduct.
d. Những trường hợp sử dụng

- Chúng ta có một super class với nhiều class con và dựa trên đầu vào, chúng ta cần trả về
một class con. Mô hình này giúp chúng ta đưa trách nhiệm của việc khởi tạo một lớp từ
phía người dùng (client) sang lớp Factory, giúp tiết kiệm tài nguyên hệ thống vì nhờ vào
việc tái sử dụng các object đã có thay vì xây dựng lại mỗi phần có thêm product
- Chúng ta không biết sau này sẽ cần đến những lớp con nào nữa. Khi cần mở rộng, hãy
tạo ra sub class và implement thêm vào factory method cho việc khởi tạo sub class này.
e. Ưu nhược điểm
Ưu điểm
- Che giấu quá trình xử lý logic của phương thức khởi tạo
- Hạn chế sự phụ thuộc giữa creator và concrete products
- Dễ dàng mở rộng, thêm những đoạn code mới vào chương trình mà không cần phá vỡ
các đối tượng ban đầu
- Giúp gom các đoạn code tạo ra product vào một nơi trong chương trình, nhờ đó giúp dễ
theo dõi và thao tác.
- Giảm khả năng gây lỗi compile, trong trường hợp chúng ta cần tạo một đối tượng mà
quên khai báo lớp, chúng ta cũng có thể xử lý lỗi trong Factory và khai báo lớp cho chúng
sau.
=> Vì những đặc điểm trên nên factory pattern thường được sử dụng trong các thư viện
(người sử dụng đạt được mục đíchtạo mới object và không cần quan tâm đến cách nó được
tạo ra)
Nhược điểm
- Source code có thể trở nên phức tạp hơn mức bình thường do đòi hỏi phải sử dụng nhiều
class mới có thể cài đặt được pattern này.
- Việc refactoring ( tái cấu trúc ) một class bình thường có sẵn thành một class có Factory
Method có thể dẫn đến nhiều lỗi trong hệ thống, phá vỡ sự tồn tại của Clients
- Factory method pattern lệ thuộc vào việc sử dụng private constructornên các class không
thể mở rộng và kế thừa
2. Abstract Factory:
a. Khái niệm
Abstract Factory pattern là một trong những Creational pattern. Nó là phương pháp tạo
ra một Super-factory dùng để tạo ra các Factory khác. Hay còn được gọi là Factory của các
Factory. Abstract Factory Pattern là một Pattern cấp cao hơn so với Factory Method
Pattern.

Trong Abstract Factory pattern, một interface có nhiệm vụ tạo ra một Factory của các
object có liên quan tới nhau mà không cần phải chỉ ra trực tiếp các class của object. Mỗi
Factory được tạo ra có thể tạo ra các object bằng phương pháp giống như Factory pattern.
Hãy tưởng tượng, Abstract factory như là một nhà máy lớn chứa nhiều nhà máy nhỏ,
trong các nhà máy đó có những xưởng sản xuất, các xưởng đó tạo ra những sản phẩm khác
nhau.
b .Mục đích sử dụng mẫu thiết kế
Đặt vấn đề
Giả sử chúng ta có một nhà máy sản xuất thời trang với nhiều phân xưởng. Cái thì phụ
trách sản xuất giày, cái sản xuất váy, cái thì sản xuất mũ,..Yêu cầu đặt ra là chúng ta cần
tạo ra nhà máy sao cho nó đáp ứng được hầu hết các thay đổi thị hiếu người dùng và thị
trường, như mùa hè thì sản xuất mẫu A, mùa đông lại sản xuất mẫu B cho từng dòng sản
phẩm giày, váy, quần áo...Với điều kiện là không phải đầu tư thêm máy móc và nhân công
hay sắp xếp lại bộ máy nhân sự vì rất tốn kém và mất nhiều thời gian. Điều này cũng tượng
tự như việc thiết kế hệ thống phần mềm, ở bài viết này tôi giả sử phần mềm này là một nhà
máy sản xuất thời trang như vậy.
Với yêu cầu đặt ra như vậy chúng ta cần một cách để tạo ra các dòng sản phẩm một cách
riêng biệt. Ví dụ mùa hè thì có giày mùa hè, váy mùa hè và mua đông lại có giày và váy
của mùa đông.
Giải pháp
Điều đầu tiên Abstract Factory pattern đề suất khai báo một cách rõ rằng interfaces cho
mỗi loại product riêng biệt cho từng dòng product (Ví dụ: giãy, váy, áo, mũ,...). Tiếp theo,
bạn cần làm tất cả biến thể của product theo các interfaces. Ví dụ, tất cả các biến thể của
giày (shoe) sẽ implement Ishoe interface, các biến thể của váy sẽ implement IDress
interface,..Các bạn có thể hình dung như hình bên dưới:

Tiếp đến bạn khai báo Abstract Factory, một interface với một danh sách các phương thức
để tạo tất cả các product thuộc cùng dòng product (dòng ở đây được hiểu là các mẫu mùa
hè, mùa đông)
Bây giờ, làm thế nào với các biến thể product ? Với mỗi loại biến thể của dòng product,
chúng ta tạo ra một factory class tách biệt dựa trên AbstractFactory interface. Một factory
class là một class mà trả về product của một loại riêng biệt. Ví dụ SummerFashion sẽ chỉ
tạo ra các đối tượng SummerShoe, SummerDress,…
c. Cấu trúc:

- Abstract Products: Khai báo các interfaces cho các loại riêng biệt nhưng các product
có liên quan sẽ tạo thành một dòng product.
- Concrete Products: Là các implement khác nhau của abstract product, được nhóm lại
bởi các biến thể. Mỗi abstract product (Shoe, Dress) phải được implement trong tất cả các
biến thể (Summer, Winter).
- Abstract Factory: Interface khai báo một tập các phương thức cho việc tạo mỗi
abstract product
- Concrete Factories: Implement các phương thức tạo product của abstract factory. Mỗi
concrete factory có trách nhiệm đến một biến thể của product và chỉ tạo các product của
biến thể này.
- Client: Mặc dù concrete factories tạo ra concrete products, kiểu trả về của các phương
thức tạo product phải trả về abstract products tương ứng. Với cách này client code sử
dụng một factory không được kết hợp với một biến thể của product mà nó nhận về một
factory. Client có thể làm việc với bất kì concrete factory nào (biến thể product), miễn là
nó giao tiếp với objects của chúng thông qua abstract interfaces.
d. Những trường hợp sử dụng mẫu
Sử dụng Abstract Factory khi code của bạn cần làm việc với các biến thể của các product
liên quan, nhưng không muốn phụ thuộc vào concrete class của những product đó (Chúng
có thể không được biết trước hoặc đơn giản là bạn muốn mở rộng trong tương lai).
Abstract Factory cung cấp cho bạn một interface cho việc tạo các objects từ mỗi class của
dòng product. Miễn là code của bạn tạo objects thông qua interface này, bạn không phải lo
lắng về việc tạo sai biến thể của product (sai ở đây có nghĩa là nó không khớp với bất kì
product nào đã được tạo trong ứng dụng của bạn).
Xem xét dùng Abtract Factory khi bạn có một class với một tập các Factory Method.
Trong một chương trình được thiết kế tốt thì mỗi một class có trách nhiệm chỉ cho một
việc. Khi một class giải quyết nhiều kiểu products, nó nên tách các factory method thành
một factory class hay nói cách khách là sử dụng Abstract Factory.
Ưu điểm:
- Có thể đảm bảo rằng products mà bạn nhận từ factory tương thích với những cái khác.
- Tránh được việc gắn chặt giữa một concrete products và client code.
- Single Responsibility Principle. Bạn có thể tách code tạo product tới một nơi, giúp code
dễ dàng để hỗ trợ

- Open/Closed Principle. Dễ dàng để thêm biến thể sản phẩm mới mà không làm ảnh ảnh
hưởng đến code cũ
Nhược điểm:
- Code có thể trở nên phức tạp hơn mức cần thiết nếu như có nhiều interfaces và classes
được thêm vào.
3. Builder:
a. Khái niệm
Builder pattern đượ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.
Đặt vấn đề
Ở ngôn ngữ Java, trong mỗi lớp đều có những hàm constructor và nếu chúng không được
khai báo thì trình biên dịch sẽ tự động xây dựng một hàm constructor mặc định cho lớp
ấy.
Khi chúng ta xây dựng, chúng ta cũng thể tùy ý lựa chọn những tham số truyền vào
cho constructor miễn là nó hữu ích cho chúng ta.
Như vậy, vấn đề đặt ra ở đây khi một đối tượng của chúng ta có thể được khởi tạo với rất
nhiều những tham số truyền vào và có thể một vài trong số đó không nhất thiết phải truyền
vào trong lúc khởi tạo(có thể có hoặc không).
Giải pháp
Builder Pattern sinh ra để giải quyết vấn đề trên, nó cho phép việc khởi tạo đối tượng với
số lượng tham số tùy chọn cho phép việc tạo đối tượng một cách linh hoạt hơn. Vậy hãy
xem Builder Pattern hoạt động như thế nào:
 Tạo một ClassBuilder với tất cả các tham số bắt buộc.
 ClassBuilder này nên có public constructor với tất cả các tham số bắt buộc.

 Tạo các phương thức để có thể lấy ra được giá trị của các tham số tùy chọn. Các
phương thức này sẽ trả ra cùng một đối tượng chứa các phương thức tùy chọn sau
khi bạn thêm những giá trị tùy chọn vào.
 Cuối cùng là cung cấp một phương thức build() trong ClassBuilder để trả ra đối
tượng mong muốn mà chúng ta vừa tạo.
c. Cấu trúc:
Builder Pattern sẽ gồm có 4 thành phần chính:
- Product : đại diện cho đối tượng cần tạo, đối tượng này phức tạp, có nhiều thuộc tính.
- Builder : là abstract class hoặc interface khai báo phương thức tạo đối tượng.
- ConcreteBuilder : kế thừa Builder và cài đặt chi tiết cách tạo ra đối tượng. Nó sẽ xác
định và nắm giữ các thể hiện mà nó tạo ra, đồng thời nó cũng cung cấp phương thức để
trả các các thể hiện mà nó đã tạo ra trước đó.
- Director: là nơi sẽ gọi tới Builder để tạo ra đối tượng.

Builder được sử dụng khi:
- Sử dụng mẫu Builder để tránh sử dụng “telescopic constructor” ( Gọi là telescopic
constructor là vì khi một class có nhiều constructor với nhiều parameter trong constructor
sẽ gây khó khăn cho người lập trình để nhớ và sử dụng cái nào cho đúng ). Builder
Pattern cho phép bạn xây dựng các object từng bước, chỉ sử dụng những bước bạn thực
sự cần. Sau khi triển khai pattern, bạn không phải nhồi nhét hàng tá tham số vào các
constructor của mình nữa.
- Sử dụng Builder Pattern khi bạn muốn code của mình có thể tạo các cách thể hiện khác
nhau của một số sản phẩm (ví dụ: nhà bằng đá và bằng gỗ). Builder Pattern có thể được
áp dụng khi việc xây dựng các bản trình bày khác nhau của sản phẩm bao gồm các bước
tương tự chỉ khác nhau về chi tiết.
- Sử dụng Builder để tạo cây Composite hoặc các đối tượng phức tạp khác. Builder
Pattern cho phép bạn tạo sản phẩm theo từng bước. Bạn có thể trì hoãn việc thực hiện
một số bước mà không làm hỏng sản phẩm cuối cùng. Bạn thậm chí có thể gọi đệ quy các
bước, điều này rất hữu ích khi bạn cần xây dựng một cây đối tượng. Một Builder không
để lộ sản phẩm chưa hoàn thành khi đang chạy các bước xây dựng. Điều này ngăn không
cho client code tìm nạp kết quả không đầy đủ.
Ưu điểm
- Có thể xây dựng các đối tượng theo từng bước, trì hoãn các bước xây dựng hoặc chạy
các bước một cách đệ quy
- Có thể sử dụng lại cùng một Construction Code khi xây dựng các thể hiện khác nhau
của sản phẩm.
- Nguyên tắc Trách nhiệm Đơn lẻ. Có thể tách biệt Construction Code phức tạp khỏi
Business Logic Layer của sản phẩm.
- Cho phép bạn thay đổi các thể hiện khác nhau của từng sản phẩm.
- Tính đóng gói code cho construction.
- Cung cấp khả năng kiểm soát các bước của quy trình construction.
Nhược điểm
- Độ phức tạp tổng thể của mã tăng lên vì bạn cần xây dựng nhiều class mới.
- Mỗi ConcreteBuilder riêng biệt phải được tạo cho từng loại sản phẩm.
- Các lớp Builder phải có thể thay đổi được

4. Prototype:
a. Khái niệm
Prototype là một design pattern thuộc nhóm Creational Pattern - những mẫu thiết kế cho
việc khởi tạo object của lớp.
Prototype quy định loại của các đối tượng cần tạo bằng cách dùng một đối tượng mẫu,
tạo mới nhờ vào sao chép đối tượng mẫu này mà không làm cho code phụ thuộc vào các
lớp của chúng.
Prototype Pattern được dùng khi việc tạo một object tốn nhiều chi phí và thời gian trong
khi bạn đã có một object tương tự tồn tại.
Prototype Pattern cung cấp cơ chế để copy từ object ban đầu sang object mới và thay đổi
giá trị một số thuộc tính nếu cần.
Đặt vấn đề
Giả sử bạn có một object và bạn muốn tạo một bản sao chính xác của nó. Bạn sẽ làm điều
này như thế nào? Đầu tiên, bạn phải tạo một object mới của cùng một lớp. Sau đó, bạn
phải đi qua tất cả các fieldcủa object gốc và sao chép các giá trị của chúng sang object
mới.
Không phải tất cả các object đều có thể được sao chép theo cách đó vì một số field của
object có thể là phương thức private và không thể sử dụng từ bên ngoài object.
Giải pháp
Prototype pattern delegate (ủy nhiệm) quá trình cloning cho các object thực tế đang được
clone lại. Pattern một giao diện chung cho tất cả các đối tượng hỗ trợ nhân bản. Giao diện
này cho phép bạn sao chép một đối tượng mà không cần ghép mã của bạn với lớp của đối
tượng đó. Thông thường, một giao diện như vậy chỉ chứa một phương thức sao chép duy
nhất.
Việc triểnkhai phương thức clone là rất giống nhau trong tất cả các lớp. Phương thức này
tạo một object của lớp hiện tại và chuyển tất cả các giá trị field của object cũ sang một
object mới. Thậm chí có thể sao chép các private fieldvì hầu hết các ngôn ngữ lập trình
đều cho phép các object truy cập vào các private fieldcủa các object khác thuộc cùng một
lớp.

Một object hỗ trợ sao chép được gọi là prototype. Khi các object có hàng chục field và
hàng trăm configuration, thì việc cloning chúng có thể là một giải pháp thay thế cho phân
lớp con.
Tạo một tập hợp các object, được xác định cấu hình theo nhiều cách khác nhau. Khi cần
một object giống như object bạn đã định cấu hình, chỉ cần clone một prototype thay vì xây
dựng một object mới từ đầu.
c. Cấu trúc:
 Prototype: khai báo một đối tượng cho việc sao chép của nó.
 ConcretePrototype: thực thi một hoạt động cho việc sao chép của nó.

 Client: tạo ra một đối tượng mới bằng việc yêu cầu một kiểu mẫu để sao chép của
nó.
- Giống như những mẫu thiết kế tạo lập khác (Builder, Abstract Factory và Factory
Method), mẫu thiết kế Prototype ẩn việc tạo đối tượng từ client.
- Tính linh hoạt nhờ vào sự đa xạ của phương thức clone(), ta có thể tạo lập 1 đối tượng
mới mà không hề cần viết mã gọi hàm tạo lập một cách cụ thể (việc cần tạo cụ thể 1 kiểu
nào đó thì ta giao cho các quá trình tiền xử lý khác, và các quá trình tiền xử lý này hẳn
cũng ko phụ thuộc vào hàm tạo lập cụ thể, một lần nữa ta lại được giải phóng…)
- Tránh việc tạo nhiều lớp con cho mỗi tượng như của Abstract Factory Pattern
- Giảm chi phí đáng kể so với tạo lập 1 đối tượng theo phương thức chuẩn, gọi toán tử
new (gọi hàm tạo lập cụ thể)
- Ta có thể tùy chỉnh các thuộc tính đối tượng mẫu để tạo ra những đối tượng mẫu mới.
Hay có thể hiểu là ta tạo ra một “chuẩn” class mới từ class có sẵn mà không cần viết code
để định nghĩa.
- Ngoài ra còn rất nhiều lợi ích khác từ Design pattern: Prototype mà ta có thể ứng dụng
vào trong việc lập trình.
Ưu điểm
- Thêm và loại bỏ lớp concrete lúc run-time
- Khởi tạo object mới bằng cách thay đổi một vài attribute của object (các object có ít
điểm khác biệt nhau.
- Khởi tạo object mới bằng cách thay đổi cấu trúc.
- Giảm việc phân lớp
Nhược điểm
- Clone các object phức tạp có phụ thuộc vòng (Circular Reference) có thể rất khó.
5. Singleton:
a. Khái niệm
Singleton là một trong số 5 design patterns thuộc nhóm Creational Design Pattern - nhóm
hỗ trợ khởi tạo class. Nó đảm bảo một class chỉ có duy nhất một instance được khởi tạo và
nó cung cấp phương thức truy cập đến instance đó từ mọi nơi (global access).

Sử dụng Singleton khi chúng ta muốn:
 Đảm bảo rằng chỉ có một instance của lớp.
 Việc quản lý việc truy cập tốt hơn vì chỉ có một thể hiện duy nhất.
 Có thể quản lý số lượng thể hiện của một lớp trong giới hạn chỉ định.
Đặt vấn đề
Trong quá trình phân tích thiết kế một hệ thống, chúng ta mong muốn có những đối tượng
cần tồn tại duy nhất và có thể truy xuất mọi lúc mọi nơi. Vậy làm thế nào để hiện thực
được một đối tượng như thế khi xây dựng mã nguồn? Chúng ta có thể nghĩ tới việc sử
dụng một biến toàn cục (global variable : public static final). Tuy nhiên, việc sử dụng biến
toàn cục nó phá vỡ quy tắc đóng gói của Lập trình hướng đối tượng.
c. Cấu trúc:
Cách sử dụng:
 Đặt constructor là private để client không thể khởi tạo object của class
 Tạo một biến static private là instance của class đó để đảm bảo rằng nó là duy nhất
và chỉ được tạo ra trong class đó thôi
 Tạo một public static method trả về instance vừa khởi tạo bên trên, đây là cách
duy nhất để các class khác có thể truy cập vào instance của class này

Singleton được sử dụng khi:
 Có thể chắc chắn rằng một lớp chỉ có một instance
 Có khả năng truy cập đến instance từ mọi nơi (global access)
 Đối tượng singleton chỉ được khởi tạo duy nhất một lần khi nó được yêu cầu lần
đầu.
 Vì class dùng Singleton chỉ tồn tại 1 Instance (thể hiện) nên nó thường được dùng
cho các trường hợp giải quyết các bài toán cần truy cập vào các ứng dụng như:
Shared resource, Logger, Configuration, Caching, Thread pool, …
 Một số design pattern khác cũng sử dụng Singleton để triển khai: Abstract
Factory, Builder, Prototype, Facade,…
Ưu điểm
- Có thể chắc chắn rằng một lớp chỉ có một instance
- Có khả năng truy cập đến instance từ mọi nơi (global access)
- Đối tượng singleton chỉ được khởi tạo duy nhất một lần khi nó được yêu cầu lần
đầu.
- Kiểm soát truy cập đến instance duy nhất
- Giảm namespace
Nhược điểm
- Vi phạm Single Responsibility Principle. Mẫu này giải quyết hay vấn đề trên cùng
một thời điểm.
- Singleton pattern có thể thể hiện thiết kế kém (bad design), chẳng hạn, khi các
thành phần của chương trình biết quá nhiều về nhau.
- Có thể sinh ra khó khăn trong việc unit test client code của Singleton bởi nhiều
test frameworks dựa vào kế thừa khi sản sinh mock objects.
II. Structural design patterns:
1. Adapter:
a. Khái niệm

Adapter Pattern là một trong những mẫu thiết kế cho phép các inteface không liên quan tới
nhau có thể làm việc cùng nhau. Đối tượng giúp kết nối các interface gọi là Adapter.
Đặt vấn đề
Hãy tưởng tượng rằng bạn đang tạo một ứng dụng theo dõi thị trường chứng khoán. Ứng
dụng tải xuống dữ liệu kho từ nhiều nguồn ở định dạng XML. Sau đó, bạn quyết định cải
thiện ứng dụng bằng cách tích hợp thư viện phân tích của bên thứ ba. Nhưng thư viện phân
tích chỉ hoạt động với dữ liệu ở định dạng JSON.
Bạn có thể thay đổi thư viện để làm việc với XML. Tuy nhiên, điềunày có thể phá vỡ code
hiện có dựa trên thư viện. Và có khi bạn có thể không có quyền truy cập vào mã nguồn của
thư viện, khiến cho phương pháp này không thể thực hiện được.
Giải pháp
Tạo một adapter đây là một đối tượng đặc biệt chuyển đổi giao diện của một đối tượng để
đối tượng khác có thể hiểu được nó.
Adapter bao bọc một trong các đối tượng để che giấu sự phức tạp của quá trình chuyển đổi
diễn ra đằng sau hậu trường. Đối tượng được bọc thậm chí không biết về adapter. Ví dụ:
bạn có thể bọc một đối tượng hoạt động theo đơn vị mét và ki lô mét bằng bộ chuyển đổi
có thể chuyển đổi tất cả dữ liệu sang các đơn vị đo lường Anh như feet và dặm.
Adapter không chỉ có thể chuyển đổi dữ liệu thành nhiều định dạng khác nhau mà còn có
thể giúp các đối tượng có giao diện khác nhau cộng tác. Đây là cách nó hoạt động:
Adapter có giao diện, tương thích với một trong các đối tượng hiện có.
Sử dụng giao diện này, đối tượng hiện có có thể gọi các phương thức của bộ điều hợp một
cách an toàn.
Khi nhận được cuộc gọi, adapter sẽ chuyển yêu cầu đến đối tượng thứ hai, nhưng theo một
định dạng và thứ tự mà đối tượng thứ hai mong đợi.
Đôi khi, thậm chí có thể tạo adapter hai chiều có thể chuyển đổi theo cả hai hướng.

Để giải quyết vấn đề nan giải về các định dạng không tương thích, bạn có thể tạo adapter
XML sang JSON cho mọi lớp của thư viện phân tích mà code của bạn làm việc trực tiếp.
Sau đó, điều chỉnh code của mình để chỉ giao tiếp với thư viện thông qua các adapter này.
Khi một adapter được gọi, nó sẽ dịch dữ liệuXML đếnthành một cấu trúc JSON và chuyển
lệnh gọi đến các phương thức thích hợp của một đối tượng phân tích được bao bọc.
c. Cấu trúc:
Object Adapter – Composition

- Client là một class chứa business logic của chương trình
- Client interface mô tả một giao thức mà các lớp khác phải tuân theo để có thể
collab với client code
- Service: là một class hữu ích (thường là bên thứ 3 hoặc kế thừa). Client không thể
sử dụng trực tiếp lớp này vì nó có interface không tương thích.
- Adapter: là một class có thể hoạt động với cả client và service: nó implements
client interface, trong khi đóng gói service object. Adapter khi được gọi từ Client
thông qua Adapter Interface sẽ chuyển chúng thành các cuộc gọi service object
được bao bọc ở định dạng mà nó có thể hiểu được.
Class Adapter – Inheritance

Các thành phần:
- Class Adapter: không cần phải bọc bất kỳ object nào vì nó kế thừa các hành vi từ
client và service. Adaptation xảy ra trong các phương thức bị ghi đè. Kết quả của
Adapter có thể được sử dụng thay cho một client class hiện có
Adapter được sử dụng khi:
 Muốn sử dụng một số class có sẵn nhưng interface của nó không tương thích với
code hiện tại
 Muốn sử dụng lại một số subclass hiện có thiếu một số chức năng và không thể
thêm vào lớp cha Adapter thường được sử dụng trong môi trường lập trình nơi các
thành phần mới hoặc ứng dụng mới cần được tích hợp và hoạt động cùng với các
thành phần hiện có.
Ưu điểm

Single Responsibility Principle: Có thể tách interface hoặc các đoạn code chuyển đổi dữ
liệu khỏi logic nghiệp vụ chính của chương trình
Open/Closed Principle: Giúp code không bị ảnh hưởng từ các thay đổi hoặc các lần cập
nhật phiên bản mới từ API hoặc dịch vụ từ bên thứ ba (thay đổi tên hàm, tên lớp,…)
Nhược điểm
Độ phức tạp tổng thể của mã tăng lên vì bạn cần giới thiệu một tập hợp các Khuôn mẫu
và lớp mới. Đôi khi, việc thay đổi lớp dịch vụ sao cho phù hợp với phần còn lại của mã
của bạn sẽ đơn giản hơn.
2. Bridge:
a. Khái niệm
Bridge Pattern là một trong những Pattern thuộc nhóm Structural Pattern. Ý tưởng của nó
là tách tính trừu tượng (abstraction) ra khỏi tính hiện thực (implementation) của nó. Từ đó
có thể dễ dàng chỉnh sửa hoặc thay thế mà không làm ảnh hưởng đến những nơi có sử
dụng lớp ban đầu. Sử dụng Bridge Patern khi chúng ta muốn:
 Khi bạn muốn tách ràng buộc giữa Abstraction và Implementation, để có thể dễ
dàng mở rộng độc lập nhau.
 Cả Abstraction và Implementation của chúng nên được mở rộng bằng subsclass.
 Sử dụng ở những nơi mà những thay đổi được thực hiện trong implement không
ảnh hưởng đến phía client.
Đặt vấn đề
Việc thêm các loại hình dạng và màu sắc mới vào hệ thống thì sẽ phải tạo thêm nhiều lớp
kế thừa.
Vấn đề này xảy ra khi chúng ta cố gắng mở rộng Shape và Color theo hai chiều độc lập,
một vấn đề rất phổ biến đối với Kế thừa trong lập trình hướng đối tượng.
Giải pháp
Trong lớp Shape có một thuộc tính là Color, Color thì có thể thêm các màu kế thừa như
Xanh Đỏ Tím Vàng tùy ý. Khi đó muốn Hình Chữ Nhật Đỏ ta chỉ cần Hình Chữ Nhật có
thuộc tính Màu là đỏ thôi, tương tự với các hình khác mà không cần phải kế thừa nhiều.

c. Cấu trúc:
 Abstraction (Shape): định nghĩa giao diện của lớp trừu tượng, quản lý việc tham
chiếu đến đối tượng hiện thực cụ thể (Implementation).
 Refined Abstraction (Circle, Square): kế thừa Abstraction.
 Implementation (Color): định nghĩa giao diện cho các lớp hiện thực. Thông
thường nó là interface định ra các tác vụ nào đó của Abstraction.
 ConcreteImplementation (Red, Blue): kế thừa Implementation và định nghĩa chi
tiết hàm thực thi.
Bridge được sử dụng khi:
 Khi muốn tách ràng buộc giữa Abstraction và Implementation, để có thể dễ dàng
mở rộng độc lập nhau.
 Khi cả Abstraction và Implementation của chúng nên được mở rộng bằng
subclass.

 Thay đổi trong thành phần được bổ sung thêm của một Abstraction mà không ảnh
hưởng đối với các Client
Ưu điểm
- Giảm sự phục thuộc giữa abstraction và implementation (loose coupling)
- Giảm số lượng những lớp con không cần thiết
- Code sẽ gọn gàn hơn và kích thước ứng dụng sẽ nhỏ hơn: do giảm được số class
không cần thiết.
- Dễ bảo trì hơn
- Dễ dàng mở rộng về sau
- Cho phép ẩn các chi tiết implement từ client.
-
Nhược điểm
- Có thể làm tăng độ phức tạp khi áp dụng cho một lớp có tính gắn kết cao
3. Composite:
a. Khái niệm
Composite là một mẫu thiết kế thuộc nhóm cấu trúc (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.
Composite Pattern được sử dụng khi chúng ta cần xử lý một nhóm đối tượng tương tự
theo cách xử lý 1 object. Composite pattern sắp xếp các object theo cấu trúc cây để diễn
giải 1 phần cũng như toàn bộ hệ thống phân cấp. Pattern này tạo một lớp chứa nhóm đối
tượng của riêng nó. Lớp này cung cấp các cách để sửa đổi nhóm của cùng 1 object.
Pattern này cho phép Client có thể viết code giống nhau để tương tác với composite object
này, bất kể đó là một đối tượng riêng lẻ hay tập hợp các đối tượng.
Đặt vấn đề
Ví dụ: bạn có hai loại đối tượng: Sản phẩm và Hộp. Một Hộp có thể chứa nhiều Sản phẩm
cũng như một số Hộp nhỏ hơn. Những chiếc Hộp nhỏ này có thể cũng giữ một số Sản
phẩm hoặc thậm chí các Hộp nhỏ hơn, v.v.

Giả sử bạn quyết định tạo một hệ thống đặt hàng. Làm thế nào bạn sẽ xác định tổng giá
của một đơn đặt hàng như vậy? Bạn có thể mở tất cả các hộp, xem qua tất cả các sản phẩm
và sau đó tính tổng. Nhưng cách tiếp cận này khi thực thi chương trình đòi hỏi mức độ
lồng ghép và cấu trúc phức tạp.
Giải pháp
Mẫu Composite cho phép làm việc với Sản phẩm và Hộp thông qua một giao diện chung
khai báo một phương pháp tính tổng giá. Đối với một hộp, nó sẽ đi qua từng mục trong
hộp chứa, hỏi giá của nó và sau đó trả lại tổng giá cho hộp này. Lợi ích lớn nhất của
phương pháp này là không cần phải quan tâm đến các lớp cụ thể của các đối tượng tạo ra
và xử lý chúng với cùng một phương thức.
c. Cấu trúc:
 Component: là một interface hoặc abstract class quy định các method chung cần
phải có cho tất cả các thành phần tham gia vào mẫu này
 Leaf: là lớp hiện thực (implements) các phương thức của Component - các object
không có con.

 Composite: lưu trữ tập hợp các Leaf và cài đặt các phương thức của Component.
Composite cài đặt các phương thức được định nghĩa trong interface Component
bằng cách ủy nhiệm cho các thành phần con xử lý.
 Client: sử dụng Component để làm việc với các đối tượng trong Composite.
 Khi bạn muốn tạo ra các đối tượng trong các cấu trúc cây để biểu diễn hệ thống
phân lớp.
 Có thể khó cung cấp một interface chung cho các lớp có chức năng khác nhau quá
nhiều. Trong một số trường hợp nhất định, bạn cần tổng quát hóa quá mức
interface thành phần khiến nó khó hiểu hơn.
Ưu điểm
Bạn có thể làm việc với các cấu trúc cây phức tạp thuận tiện hơn.
Nguyên tắc mở/ đóng: có thể khởi tạo các loại phần tử mới vào ứng dụng mà không phá
vỡ code hiện có đang hoạt động với đối tượng cây.
Nhược điểm
Code có thể trở nên phức tạp hơn mức bình thường, vì có rất nhiều interfaces và classes
được khởi tạo cùng với mẫu.
4. Decorator:
a. Khái niệm
Decorator pattern là 1 pattern thuộc nhóm structural pattern. Decorator sinh ra để cho phép
người dùng thêm các tính năng mới vào một đối tượng đã có mà không làm thay đổi cấu
trúc lớp của nó
b. Cấu trúc:

 Component: Protocol (interface) chung sẽ được triển khai của các đối tượng cần
thêm chức năng trong quá trình runtime.
 ConcreteComponent: Định nghĩa một đối tượng cần thêm các chức năng trong
quá trình chạy.
 Decorator: Một lớp chứa duy trì một tham chiếu của đối tượng thành phần và
đồng thời cài đặt các thành phần của Component.
 ConcreteDecorator: Một cài đặt của Decorator, nó cài đặt thêm các thành phần
vào đầu của các đối tượng thành phần.
c. Những trường hợp sử dụng mẫu
 Khi muốn thêm tính năng mới cho các đối tượng mà không ảnh hưởng đến các đối
tượng này.
 Khi không thể mở rộng một đối tượng bằng cách thừa kế (inheritance). Chẳng hạn,
một class sử dụng từ khóa final, muốn mở rộng class này chỉ còn cách duy nhất là
sử dụng decorator.
 Trong một số nhiều trường hợp mà việc sử dụng kế thừa sẽ mất nhiều công sức
trong việc viết code.
d. Ưu nhược điểm
Ưu điểm
- Bạn có thể mở rộng hành vi của đối tượng mà không cần tạo lớp con mới.

- Bạn có thể thêm hoặc xoá tính năng của một đối tượng trong lúc thực thi.
- Một đối tượng có thể được bao bọc bởi nhiều wrapper cùng một lúc.
- Single Responsibility Principle - Có thể chia nhiều cách thực thi của một phương
thức trong một lớp cho nhiều lớp nhỏ hơn.
Nhược điểm
- Khó để xóa một wrapper cụ thể khỏi stack.
- Khó để triển khai decorator theo cách mà phương thức của nó không phụ thuộc
vào thứ tự trong stack.
5. Façade:
a. Khái niệm
 Facade là một mẫu thiết kế thuộc nhóm cấu trúc (Structural Pattern).
 Facade Pattern cung cấp cho chúng ta một giao diện chung đơn giản thay cho
một nhóm các giao diện có trong một hệ thống con (subsystem). Facade Pattern
định nghĩa một giao diện ở cấp độ cao hơn để giúp cho người dùng có thể dễ
dàng sử dụng hệ thống con này.
 Facade Pattern cho phép các đối tượng truy cập trực tiếp giao diện chung này
để giao tiếp với các giao diện có trong hệ thống con. Mục tiêu là che giấu các
hoạt động phức tạp bên trong hệ thống con, làm cho hệ thống con dễ sử dụng
hơn.
Đặt vấn đề
Khi ta chúng ta có chuỗi các hành động được thực hiện theo thứ tự, và các hành động
này lại được yêu cầu ở nhiều nơi trong phạm vi ứng dụng của chúng ta (ví dụ khi làm
việc với một số lượng lớn các đối tượng trong hệ thống hay một thư viện phức tạp,
chúng ta cần phải tự khởi tạo tất cả đối tượng này, thường xuyên theo dõi các thay đổi
của nó, thứ tự logic cũng phải xử lý chính xác với bên thứ 3. Từ đó logic nghiệp vụ của
các lớp trở nên gắn kết chặt chẽ với thư viện thử 3)
=> Vậy mỗi lúc bạn cần dùng đến nó bạn lại phải copy/paste hoặc viết lại đoạn code
đó vào những nơi cần sử dụng trong ứng dụng. Điều này có vẻ cũng giúp ta nhanh hơn,
nhưng nếu chúng ta nhận ra cần phải thay đổi lại cấu trúc và hoặc một đoạn code nào
đó trong hầu hết chuỗi hành động đó, vậy chúng ta phải xử lý như thế nào?

Giải pháp
Chúng ta cần thiết kế một Facade, và trong đó phương thức của Facade sẽ xử lý các
đoạn code được sử dụng với nhiều, lặp lại. Với Facade, chúng ta sẽ chỉ cần gọi Facade
để thực thi các hành động dựa trên các parameters được cung cấp.
=> Bây giờ nếu chúng ta cần bất kỳ thay đổi nào trong quá trình trên, công việc sẽ đơn
giản hơn rất nhiều, chỉ cần thay đổi các xử lý trong façade, mọi thứ sẽ được đồng bộ
c. Cấu trúc:
 Facade: Facade nắm rõ được hệ thống con nào đảm nhiệm việc đáp ứng yêu
cầu của client, nó sẽ chuyển yêu cầu của client đến các đối tượng hệ thống con
tương ứng.
 Addition Facade: có thể được tạo ra để tránh việc làm phức tạp một facade. Có
thể được sử dụng bởi cả client và facade.

 Complex Subsystems: Bao gồm nhiều object khác nhau, được cài đặt các chức
năng của hệ thống con, xử lý công việc được gọi bởi Facade. Các lớp này
không cần biết Facade và không tham chiếu đến nó.
 Client: Đối tượng sử dụng Facade để tương tác với các subsystem thay vì gọi
subsystem trực tiếp
 Muốn gom nhóm chức năng lại để Client dễ sử dụng
 Giảm sự phụ thuộc.
 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.
 Đó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.
Ưu điểm
- 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.
Nhược điểm
- Class Facade của bạn có thể trở lên quá lớn, làm quá nhiều nhiệm vụ với nhiều
hàm chức năng trong nó.
- Dễ bị phá vỡ các quy tắc trong SOLID.
- Việc sử dụng Facade cho các hệ thống đơn giản, ko quá phức tạp trở nên dư thừa.
6. Flyweight:
a. Khái niệm

 Flyweight là một mẫu thiết kế thuộc nhóm Structural Pattern – những mẫu thiết kế
giúp dễ dàng thiết kế bằng cách xác định một cách hiện thực hóa mối quan hệ giữa
các thực thể.
 Mẫu thiết kế Flyweight là một mẫu thiết kế cấu trúc cho phép bạn lắp nhiều đối
tượng hơn vào dung lượng RAM có sẵn bằng cách chia sẻ, phân phối các phần
trạng thái chung - riêng giữa nhiều đối tượng thay vì giữ tất cả dữ liệu trong mỗi
đối tượng.
Đặt vấn đề
Chẳng hạn bạn tạo ra một game FPS open world người chơi sẽ di chuyển quanh bản đồ và
bắn nhau. Thêm vào rất nhiều hiệu ứng kỹ xảo, cháy nổ, ánh sáng. Số lượng lớn đạn, tên
lửa và mảnh bom từ các vụ nổ sẽ trải dài khắp thế giới trong game và mang lại trải nghiệm
thú vị cho người chơi.
Sau khi hoàn thành game và gửi nó cho bạn bè của bạn để chơi thử. Mặc dù trò chơi đang
chạy hoàn hảo trên máy của bạn, nhưng trên các máy khác không thể chơi được lâu. Trò
chơi liên tục gặp sự cố sau vài phút chơi. Sau vài giờ tìm hiểu các bản debug log, bạn phát
hiện ra rằng trò chơi bị lỗi do không đủ dung lượng RAM. Hóa ra là thiết bị khác kém hơn
nhiều so với máy tính của bạn và đó là lý do tại sao vấn đề lại xuất hiện rất nhanh trên các
máy khác.
Chẳng hạn như một viên đạn, một tên lửa hoặc một mảnh đạn được thể hiện bằng một đối
tượng riêng biệt chứa nhiều dữ liệu. Tại một số thời điểm, khi rất nhiều đối tượng xảy ra
trên màn hình của người chơi lên đến đỉnh điểm, các đối tượng mới được tạo ra không còn
đủ với bộ nhớ RAM còn lại, do đó chương trình bị lỗi.
Dễ đoán ra được, lý do là vì mỗi class Particle chứa quá nhiều thông tin: vị trí, tọa độ,
vector, tốc độ, màu sắc, sprite. Trong khi đó, có những loại thông tin luôn thay đổi theo
từng unit và những loại thông tin thường giống nhau giữa các loại unit. Nếu không biết về
flyweight pattern, một người sẽ đành bó tay chịu đựng, và dự định sẽ nâng system
requirement của ứng dụng - quả là một nước đi không khôn ngoan.
Giải pháp
Khi kiểm tra kỹ hơn Class Particle, bạn có thể nhận thấy rằng các biến color và sprite tiêu
tốn nhiều bộ nhớ hơn các trường khác. Điều tồi tệ hơn là hai biến này lưu trữ dữ liệu gần
như giống hệt nhau trên tất cả các particle. Ví dụ, tất cả các viên đạn có cùng màu và
sprite.

Như tọa độ, vectơ chuyển động và tốc độ, là những biến duy nhất của mỗi particle. Giá trị
của các biến này thay đổi theo thời gian. Dữ liệu này đại diện cho context luôn thay đổi
trong đó có sự xuất hiện của particle đó, trong khi màu sắc và sprite không đổi.
Dữ liệu không đổi này của một đối tượng thường được gọi là trạng thái intrinsic. Nó tồn
tại bên trong đối tượng; các đối tượng khác chỉ có thể đọc nó, không thay đổi nó. Phần còn
lại của trạng thái của đối tượng, thường bị thay đổi “từ bên ngoài” bởi các đối tượng khác,
được gọi là trạng thái extrinsic.
c. Cấu trúc:
 Mô hình Flyweight chỉ đơn thuần là một sự tối ưu hóa cho hệ thống. Trước khi áp
dụng nó, hãy đảm bảo rằng chương trình có vấn đề tiêu thụ RAM liên quan đến
việc có một số lượng lớn các đối tượng tương tự trong bộ nhớ cùng một lúc.
 Class Flyweight chứa phần trạng thái ban đầu của đối tượng có thể được chia sẻ
giữa nhiều đối tượng. Cùng một đối tượng flyweight có thể được sử dụng trong
nhiều context khác nhau. Trạng thái được lưu trữ bên trong một flyweight được

gọi là “intrinsic”. Trạng thái được truyền cho các phương thức của flyweight được
gọi là “extrinsic”.
 Class Context chứa trạng thái extrinsic. Khi một context được ghép nối với một
trong các đối tượng flyweight, nó đại diện cho trạng thái đầy đủ của đối tượng ban
đầu.
 Thông thường, hành vi của đối tượng ban đầu vẫn thuộc lớp Flyweight.Trường
hợp này, bất cứ khi nào gọi một phương thức của flyweight cũng phải chuyển các
giá trị thích hợp của extrinsic state vào các tham số của phương thức. Mặt khác,
hành vi có thể được chuyển sang lớp Context, lớp này sẽ sử dụng flyweight được
liên kết đơn thuần như một đối tượng dữ liệu
 Client ( Các class sử dụng Flyweight ) tính toán hoặc lưu trữ trạng thái extrinsic
của Flyweights. Từ góc độ client, Flyweight là một đối tượng mẫu có thể được cấu
hình trong thời gian chạy bằng cách chuyển một số dữ liệu theo ngữ cảnh vào các
tham số của các phương thức của nó.
 Flyweight Factory quản lý một nhóm các flyweight hiện có. Các client sẽ không
tạo ra flyweights trực tiếp. Thay vào đó, họ gọi factory, chuyển cho nó intrinsic
state mong muốn của flyweight. factory xem xét các flyweight được tạo trước đó
và trả về một cái hiện có phù hợp với tiêu chí tìm kiếm hoặc tạo một cái mới nếu
không tìm thấy gì.
 Khi có một số lớn các đối tượng được ứng dụng tạo ra một cách lặp đi lặp lại.
 Khi việc tạo ra đối tượng đòi hỏi nhiều bộ nhớ và thời gian
 Khi muốn tái sử dụng đối tượng đã tồn tại thay vì phải tối thời gian để tạo mới
 Khi nhóm đối tượng chứa nhiều đối tượng tương tự và hai đối tượng trong nhóm
không khác nhau nhiều
Ưu điểm
- Giảm số lương đối tượng được tạo ra bằng cách chia sẻ đối tượng. Vì vậy tiết kiệm
bộ nhớ và các thiết bị lưu trữ cần thiết
- Cải thiện khả năng cache dữ liệu vì thời gian đáp ứng nhanh
- Tăng Performance cho hệ thống
Nhược điểm

- Đánh đổi về mặt sử dụng CPU khi các flyweight object bị truy cập nhiều lần.
- Code trở nên phức tạp hơn nhiều. Các thành viên mới trong team sẽ luôn thắc mắc
tại sao trạng thái của một thực thể lại được tách ra theo cách như vậy. Độ dễ hiểu
(understandability) thấp
7. Proxy:
a. Khái niệm
 Proxy (hay còn gọi là Surrogate) là một mẫu thiết kế thuộc nhóm cấu trúc
(Structural Pattern).
 Điều khiển gián tiếp việc truy xuất đối tượng thông qua một đối tượng được ủy
nhiệm
 Cung cấp 1 class đại diện để quản lí sự truy xuất đến thành phần của 1 class khác
Đặt vấn đề
Giả sử ta có một bài toán truy cập vào 1 object lớn. Object này chiếm nhiều tài nguyên hệ
thống. Ta cần nó thường xuyên, nhưng không phải luôn luôn. Ví dụ như khi ta truy vấn cơ
sở dữ liệu.
Ta có thể implement lazy initialization, tức là chỉ tạo khi cần. Khi đó client muốn truy cập
đều phải chạy qua đoạn code này, tuy nhiên vấn đề phát sinh là sẽ khiến code duplicate
Điều hay nhất là có thể là đưa dòng code này vào chính đối tượng đó. Nhưng nếu lớp này
là 3rd party thì không thể.
Một vấn đề khác về mặt security, hoặc ta muốn validate nó mà không cần đến client, như
khi upload 1 file nào đó.
Giải pháp
Proxy nói rằng ta cần tạo 1 lớp mới đại diện cho lớp service đang có với cùng 1 interface,
lớp này gọi là proxy. Sau đó khi update ứng dụng thì nó sẽ truyền đối tượng proxy cho tất
cả client phía đối tượng gốc. Khi nhận 1 yêu cầu từ phía client, proxy tạo 1 service thật và
delegate tất cả nhiệm vụ đến nó.

Nếu phải chạy thứ gì đó trước hay sau logic chính của lớp, proxy cho phép làm điều đó
mà không làm thay đổi lớp đó. Bởi vì Proxy implement cùng interface với lớp chính, nó
có thể kết nối với bất cứ client nào đang chờ liên lạc từ server thật.
Trả lời hai câu này để quyết định cài proxy hay không:
 Có 1 “expensive resource” nhưng chỉ khởi tạo khi cần đến nó?
 Có 1 resource cần kiểm tra security, availability hay validation mà không muốn
làm ở phía Client?
=> Wrap 1 object và cung cấp các phương thức để truy cập vào object đó
Proxy giải quyết các vấn đề:
 Có những tình huống mà khách hàng không hoặc không thể tham chiếu trực tiếp
đến một Đối tượng, nhưng vẫn muốn tương tác với đối tượng.
 Đối tượng proxy có thể hoạt động như trung gian giữa máy khách và đối tượng
đích.
 Đối tượng proxy có cùng giao diện với đối tượng đích.
 Proxy giữ một tham chiếu đến đối tượng mục tiêu và có thể chuyển tiếp các yêu
cầu đến mục tiêu theo yêu cầu
 Proxy hữu ích ở bất cứ nơi nào có nhu cầu tham chiếu phức tạp hơn đến một đối
tượng hơn là con trỏ đơn giản hoặc tham chiếu đơn giản có thể cungười cấp
c. Cấu trúc:

 ServiceInterface: Định nghĩa giao diện chung cho Service và Proxy để Proxy có
thể được sử dụng bất kỳ nơi nào mà Service được mong đợi.
 Service: Định nghĩa ServiceInterface mà Proxy đại diện.
 Proxy:
o Duy trì một tham chiếu cho phép Proxy truy cập vào Service . Proxy có thể
tham chiếu đến ServiceInterface nếu Service và ServiceInterface giống
nhau.
o Cung cấp interfaces giống với ServiceInterface để Proxy có thể thay thế
cho Service .
o Kiểm soát quyền truy cập vào Service và chịu trách nhiệm cho việc tạo và
xóa nó.
o Một vài trách nhiệm khác phụ thuộc vào loại Proxy:
o Remote proxies chịu trách nhiệm mã hóa một yêu cầu và các đối số của nó
và gửi yêu cầu được mã hóa đến Service trong một không gian địa chỉ khác.
o Virtual proxies có thể cache thông tin bổ xung về Service để trì hoãn việc
truy cập nó.

o Protectionproxies kiểm tra xem có quyền truy cập cần thiết để thực hiện
yêu cầu hay không.
 azy initialization (virtual proxy): Khi bạn có một đối tượng dịch vụ nặng gây lãng
phí tài nguyên hệ thống do luôn hoạt động, mặc dù thỉnh thoảng bạn chỉ cần nó.
 Access control (protection proxy): Khi bạn muốn chỉ những khách hàng cụ thể
mới có thể sử dụng đối tượng dịch vụ.
 Local execution of a remote service (remote proxy): Đây là khi đối tượng service
được đặt trên một máy chủ từ xa.
 Logging requests (logging proxy): Khi bạn muốn giữ lịch sử của các yêu cầu đối
với đối tượng service.
 Caching request results (caching proxy): Khi bạn cần lưu trữ kết quả của các yêu
cầu máy khách và quản lý vòng đời của bộ nhớ cache này, đặc biệt nếu kết quả
khá lớn.
 Smart reference: Khi bạn cần loại bỏ một đối tượng nặng khi không có máy khách
nào sử dụng nó.
Ưu điểm
- Open/Closed Principle: Bạn có thể thêm proxy mới mà không cần thay đổi service
hoặc clients.
- Cải thiện Performance thông qua lazy loading.
- Nó cung cấp sự bảo vệ cho đối tượng thực từ thế giới bên ngoài.
- Giảm chi phí khi có nhiều truy cập vào đối tượng có chi phí khởi tạo ban đầu lớn.
Nhược điểm
- Mã có thể trở nên phức tạp hơn vì bạn cần phải thêm lớp mới.
- Phản hồi từ service có thể bị trì hoãn.

III. Behavioral design patterns:
1. Chain of responsibility:
a. Khái niệm
 Chain of Responsibility là một mẫu thiết kế thuộc nhóm hành vi (Behavioral
Pattern).
 Mục đích: cho phép một đối tượng gửi một yêu cầu nhưng không biết đối tượng
nào sẽ nhận và xử lý nó. Điều này được thực hiện bằng cách kết nối các đối tượng
nhận yêu cầu thành một chuỗi (chain) và gửi yêu cầu theo chuỗi đó cho đến khi có
một đối tượng xử lý nó.
 Chain of Responsibility Pattern hoạt động như một danh sách liên kết (Linked list)
với việc đệ quy duyệt qua các phần tử (recursive traversal).
Đặt vấn đề
Giả sử bạn làm việc với một hệ thống đặt hàng online. Bạn muốn hạn chế quyền truy cập
vào hệ thống, chỉ cho user đã đăng nhập tạo các đơn đặt hàng. Mặt khác những user có
quyền admin sẽ được toàn quyền truy cập vào các đơn đặt hàng.
Sau 1 hồi lên kế hoạch, bạn nhận ra những giai đoạn kiểm tra (như kiểm tra user đã đăng
nhập, user có quyền admin) cần phải thực hiện tuần tự. Ví dụ nếu việc kiểm tra user đăng
nhập bị thất bại thì chúng ta ko có lí do gì để kiểm tra tiếp tục các điều kiện khác.
Một hồi sau mình thêm chức năng cache để skip nếu yêu cầu giống nhau, kiểm tra
Password có đúng format hay không... Mỗi khi thêm 1 chức năng hàm kiểm tra ngày càng
phức tạp, cho đến khi 1 ngày bạn refactor code.
Giải pháp
Chuyển từng hành vi thành những đối tượng cụ thể gọi là handlers. Mỗi kiểm tra sẽ
extract thành 1 hàm duy nhất. Yêu cầu sẽ được truyền dọc theo các hàm này. Tất cả tạo
nên 1 chuỗi liên kết, cho đến khi yêu cầu được xử lý, đến hết mắt xích cuối.
Một ví dụ khác trong lập trình windows forms. Các control trên một form chứa đựng nhau
tạo ra một chuỗi object. Giả sử bạn click vào một nút bấm, sự kiện “click” sẽ chạy ngược

chuỗi object từ Button tới Window (cấp cao nhất) để tìm đến đúng control có khả năng xử
lý nó.
Mẫu này gắn liền với nhiều hệ thống xử lý yêu cầu. Ví dụ tổng đài hay bất kì quy trình
làm việc nào cũng sẽ đi theo tư tưởng của Chain of Responsibility. Có lỗi thì sẽ chọn đưa
cho người có liên quan tiếp theo hoặc chấm dứt yêu cầu tại điểm đó.
c. Cấu trúc:
 Client: tạo ra các yêu cầu và yêu cầu đó sẽ được gửi đến các đối tượng tiếp nhận.
 ConcreteHandler: xử lý yêu cầu. Có thể truy cập đối tượng successor (thuộc class
Handler). Nếu đối tượng ConcreateHandler không thể xử lý được yêu cầu, nó sẽ
gởi lời yêu cầu cho successor của nó.
 Handler: định nghĩa 1 interface để xử lý các yêu cầu. Gán giá trị cho đối tượng
successor (không bắt buộc).

 BaseHandler: lớp trừu tượng không bắt buộc. Có thể cài đặt các hàm chung cho
Chain of Responsibility ở đây.
 Có nhiều hơn một đối tượng có khả thực xử lý một yêu cầu trong khi đối tượng cụ
thể nào xử lý yêu cầu đó lại phụ thuộc vào ngữ cảnh sử dụng.
 Muốn gửi yêu cầu đến một trong số vài đối tượng nhưng không xác định đối tượng
cụ thể nào sẽ xử lý yêu cầu đó.
 Khi cần phải thực thi các trình xử lý theo một thứ tự nhất định..
 Khi một tập hợp các đối tượng xử lý có thể thay đổi động: tập hợp các đối tượng
có khả năng xử lý yêu cầu có thể không biết trước, có thể thêm bớt hay thay đổi
thứ tự sau này.
Ưu điểm
- Giảm kết nối (loose coupling): Thay vì một đối tượng có khả năng xử lý yêu cầu
chứa tham chiếuđến tất cả các đối tượng khác, nó chỉ cần một tham chiếu
đến đối tượng tiếptheo. Tránh sự liênkết trực tiếpgiữa đối tượng gửi yêu
cầu (sender) và các đối tượng nhận yêu cầu (receivers).
- Tăng tính linh hoạt : đảm bảo Open/Closed Principle
- Phân chia trách nhiệm cho các đối tượng: đảm bảo Single Responsibility Principle
- Có khả năng thay đổi dây chuyền (chain) trong thời gian chạy.
Nhược điểm
- Một số yêu cầu có thể không được xử lý: Trường hợp tất cả Handler đều không xử
lý
2. Command:
a. Khái niệm

Command Pattern là một trong những Pattern thuộc nhóm hành vi (Behavior Pattern).
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ễ 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.
c. Cấu trúc:
Các thành phần tham gia trong Command Pattern:
● 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.
● Receiver : đây là thành phần thực sự xử lý business logic cho case request.
Trong phương execute() của ConcreteCommand chúng ta sẽ gọi method
thích hợp trong Receiver.
Như vậy, Client và Invoker sẽ thực hiện việc tiếpnhận request. Còn việc thực
thi request sẽ do Command, ConcreteCommand và Receiver đảm nhận.
● 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.
Ưu điểm
- Đảm bảo nguyên tắc Single Responsibility
- Đảm bảo nguyên tắc Open/Closed
- Có thể thực hiện hoàn tác
- Giảm kết nối phụ thuộc giữa Invoker và Receiver
- Cho phép đóng gói yêu cầu thành đối tượng, dễ dàng chuyển dữ liệu giữa các
thành phần hệ thống
Nhược điểm
- Khiến code trở nên phức tạp hơn, sinh ra các lớp mới gây phức tạp cho mã nguồn.
3. Iterator:
a. Khái niệm
Iterator Pattern là một trong những Pattern thuộc nhóm hành vi (Behavior Pattern). Cho
phép bạn duyệt qua các phần tử của một tập hợp mà không để lộ biểu diễn cơ bản của nó
(danh sách, ngăn xếp, cây, v.v.).

Một Iterator được thiết kế cho phép xử lý nhiều loại tập hợp khác nhau bằng cách truy cập
những phần tử của tập hợp với cùng một phương pháp, cùng một cách thức định sẵn, mà
không cần phải hiểu rõ về những chi tiết bên trong của những tập hợp này.
Iterator thường được viết trong Java như là những lớp độc lập. Ý tưởng thiết kế này là một
trong những kỹ thuật được gọi là “Single responsibility principle (SRP)” – một lớp chỉ có
duy nhất một công việc để làm. Tách biệt trách nhiệm giữa các lớp rất hữu dụng khi một lớp
bị thay đổi. Nếu có quá nhiều thứ bên trong một lớp đơn lẻ, sẽ rất khó khăn để viết lại mã
nguồn.
Đặt vấn đề
Với Interface iterator trong gói java.util.Iterator:
+Hàm next() : trả về phần tử kế tiếp trong tập hợp
+Hàm hasNext() : trả về giá trị True nếu vẫn còn phần tử trong tập hợp và trả về false
trong trường hợp ngược lại.
Giả sử rằng Client phải làm việc với một tập hợp phức tạp và rắc rối: không biết cách thức
làm việc với nó như thế nào.
Giải pháp
Client có thể sử dụng iterator để làm cầu nối với tập hợp, và client có thể sử dụng các
phương thức cơ bản của Iterator để giao tiếp với tập hợp.

Iterator đóng gói các chi tiết làm việc với cấu trúc dữ liệu phức tạp, cung cấp cho client
một số phương pháp đơn giản để truy cập các phần tử của bộ sưu tập. Mặc dù cách tiếp cận
này rất thuận tiện cho client, nhưng nó cũng bảo vệ tập hợp khỏi các hành động bất cẩn hoặc
độc hại mà máy khách có thể thực hiện nếu làm việc trực tiếp với tập hợp.
c. Cấu trúc:
Cấu trúc tổng quan của Iterator Pattern bao gồm 5 thành phần chính là: Aggregate,
ConcreteAggregate(s), Iterator, ConcreteIterator(s) và Client.
Các thành phần tham gia Iterator Pattern:
 Aggregate: là một interface định nghĩa định nghĩa các phương thức để tạo Iterator
object.
 ConcreteAggregate: cài đặt các phương thức của Aggregate, nó cài đặt interface tạo
Iterator để trả về một thể hiện của ConcreteIterator thích hợp.
 Iterator: là một interface hay abstract class, định nghĩa các phương thức để truy cập
và duyệt qua các phần tử.

 ConcreteIterator: cài đặt các phương thức của Iterator, giữ index khi duyệt qua các
phần tử.
 Client: đối tượng sử dụng Iterator Pattern, nó yêu cầu một iterator từ một đối tượng
collectionđể duyệt qua các phần tử mà nó giữ. Các phương thức của iterator được sử
dụng để truy xuất các phần tử từ collectiontheo một trình tự thích hợp.
 Cần truy cập nội dung của đối tượng trong tập hợp mà không cần biết nội dung cài
đặt bên trong nó.
 Hỗ trợ truy xuất nhiều loại tập hợp khác nhau.
 Cung cấp một interface duy nhất để duyệt qua các phần tử của một tập hợp.
Ưu điểm:
 Đảm bảo nguyên tắc Single responsibilityprinciple (SRP): chúng ta có thể tách
phần cài đặt các phương thức của tập hợp và phần duyệt qua các phần tử (iterator)
theo từng class riêng lẻ.
 Đảm bảo nguyên tắc Open/Closed Principle (OCP): chúng ta có thể implement các
loại collectionmới và iterator mới, sau đó chuyển chúng vào code hiện có mà không
vi phạm bất cứ nguyên tắc gì.
 Chúng ta có thể truy cập song song trên cùng một tập hợp vì mỗi đối tượng iterator có
chứa trạng thái riêng của nó.
Nhược điểm:
 Sử dụng iterator có thể kém hiệu quả hơn so với việc duyệt qua các phần tử của bộ
sưu tập một cách trực tiếp.
 Có thể không cần thiết nếu ứng dụng chỉ hoạt động với các collectionđơn giản.
4. Mediator:
a. Khái niệm

 Mediator Pattern là một trong những Pattern thuộc nhóm hành vi (Behavior
Pattern). Mediator có nghĩa là người trung gian. Pattern này nói rằng “Định nghĩa
một đối tượng gói gọn cách một tập hợp các đối tượng tương tác.
 Mediator thúc đẩy sự khớp nối lỏng lẻo (loose coupling) bằng cách ngăn không
cho các đối tượng đề cập đến nhau một cách rõ ràng và nó cho phép bạn thay đổi
sự tương tác của họ một cách độc lập”.
Đặt vấn đề
Giả sử bạn có một cái dialog để tạo và chỉnh sửa thông tin khách hàng. Nó gồm nhiều
thành phần như text fields, buttons, checkboxes,…
Một vài thành phần sẽ tương tác với vài thành phần khác. Ví dụ chọn checkbox "Có con"
thì sẽ hiện ra text field bị ẩn để nhập vào số lượng con của người dùng.
Nếu triển khai những logic này trực tiếp vào từng thành phần, bạn sẽ làm cho các thành
phần này khó tái sử dụng hơn.
Giải pháp
Mediator đề xuất bạn nên ngừng tất cả các giao tiếp trực tiếp giữa các thành phần.
Thay vào đó, các thành phần này sẽ giao tiếp gián tiếp với nhau bằng cách gọi một đối
tượng Mediator đặc biệt để đối tượng này chuyển lời gọi đó đến các thành phần thích hợp
giùm bạn.
Các thành phần lúc này sẽ chỉ phụ thuộc vào một lớp Mediator duy nhất thay vì phải kết
nối với rất nhiều thành phần khác như ban đầu.
Thay đổi quan trọng nhất xảy ra đối với các thành phần trong form. Hãy xem xét submit
button. Trước đây, mỗi lần người dùng nhấp vào button, nó phải xác thực các giá trị của
tất cả các phần tử biểu mẫu riêng lẻ. Bây giờ công việc duy nhất của nó là thông báo cho
dialog về cú nhấp chuột.
Khi nhận được thông báo này, dialog sẽ tự thực hiện việc xác thực hoặc chuyển nhiệm vụ
cho các phần tử riêng lẻ. Do đó, thay vì bị ràng buộc với hàng tá phần tử biểu mẫu, button
chỉ phụ thuộc vào lớp dialog.

Bạn cũng có thể làm cho sự phụ thuộc trở nên lỏng lẽo hơn bằng cách tríchxuất interface
chung cho tất cả các loại của các dialog.
Interface sẽ khai báo phương thức thông báo, cái mà tất cả phần tử đều có thể sử dụng để
thông báo đến dialog về những sự kiện xảy ra với chúng. Và như vậy, lúc này submit
button có thể làm việc với tất cả dialog có triển khai interface này.
Bằng cách này, Mediator cho phép bạn đóng gói một mạng lưới phức tạp các mối liên hệ
giữa nhiều đối tượng vào trong một đối tượng mediator duy nhất. Một lớp càng ít sự phụ
thuộc thì càng dễ điều chỉnh, mở rộng hay tái sử dụng.
c. Cấu trúc:
 Các Component là các lớp khác nhau có chứa vài logic nghiệp vụ như Button,
TextField,... Mỗi component đều có một tham chiếu đến một Mediator, được khai
báo với kiểu là Mediator interface. Component không quan tâm đến các lớp thật sự
của Mediator. Vì vậy, có thể tái sử dụng component ở các chương trình khác và
chỉ việc liên kết nó với một mediator khác.
 Mediator interface khai báo các phương thức để giao tiếp với các component,
thường chỉ bao gồm một phương thức thông báo duy nhất. Component có thể

truyền bất kỳ ngữ cảnh nào làm các đối số của phương thức này, bao gồm cả các
đối tượng của chúng, nhưng chỉ theo cách không xảy ra sự ghép nối nào giữa
thành phần nhận và lớp gửi.
 Concrete Mediator đóng gói các mối quan hệ giữa các component khác nhau. Các
Concrete mediator thường giữ các tham chiếu đến tất cả component mà chúng
quản lý và thường thậm chí quản lý cả vòng đời.
 Các component không cần quan tâm đến các component khác. Nếu có điều gì xảy
ra với component thì chúng chỉ cần thông báo đến mediator. Khi mediator nhận
thông báo, nó có thể dễ dàng xác định nơi gửi (điều này có thể vừa đủ để quyết
định xem component nào nên được kích hoạt).
 Sử dụng khi khó thay đổi một vài lớp vì chúng đã được kết nối chặt chẽ với rất
nhiều lớp khác.
 Sử dụng khi không thể tái sử dụng một component ở các chương trình khác vì
chúng quá phụ thuộc vào các component khác.
 Sử dụng khi cảm thấy mình đang tạo ra rất nhiều lớp con component chỉ để tái sử
dụng một vài hành vi đơn giản ở các ngữ cảnh khác nhau.
 Sử dụng khi tập hợp các đối tượng giao tiếp theo những cách thức được xác định
rõ ràng nhưng cách thức đó quá phức tạp. Sự phụ thuộc lẫn nhau giữa các đối
tượng tạo ra kết quả là cách tổ chức không có cấu trúc và khó hiểu.
 Sử dụng khi cần tái sử dụng một đối tượng nhưng rất khó khăn vì nó tham chiếu
và giao tiếp với nhiều đối tượng khác.
 Sử dụng khi điều chỉnh hành vi giữa các lớp một cách dễ dàng, không cần chỉnh
sửa ở nhiều lớp.
 Thường được sử dụng trong các hệ thống truyền thông điệp (message-based
system), chẳng hạn như hệ thống chat.
 Khi giao tiếp giữa các object trong hệ thống quá phức tạp, có quá nhiều quan hệ
giữa các object trong hệ thống. Một điểm chung để kiểm soát hoặc giao tiếp là cần
thiết.
Ưu điểm

 Đảm bảo nguyên tắc Single Responsibility Principle (SRP): chúng ta có thể trích
xuất sự liên lạc giữa các component khác nhau vào trong một nơi duy nhất, làm
cho nó được bảo trì dễ dàng hơn.
 Đảm bảo nguyên tắc Open/Closed Principle (OCP): chúng ta có thể tạo ra các
mediator mới mà không cần thay đổi các component.
 Giảm thiểu việc gắn kết giữa các component khác nhau trong một chương trình.
 Tái sử dụng các component đơn giản hơn.
 Đơn giản hóa cách giao tiếp giữa các đối tượng, Một Mediator sẽ thay thế mối
quan hệ nhiều nhiều (many-to-many) giữa các component bằng quan hệ một-nhiều
(one-to-many) giữa một mediator với các component.
 Quản lý tập trung, giúp làm rõ các component tương tác trong hệ thống như thế
nào trong hệ thống

Nhược điểm
 Qua thời gian thì Mediator có thể trở thành God object.
5. Memento:
a. Khái niệm:
Memento là một DesignPattern 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. Nó có trách nghiệm
lưu trữ các State ở dạng Memento và cấp phát các State cho các Object khi cần.
Đặt vấn đề

Tưởng tượng bạn đang tạo 1 text editor. Bao gồm các chức năng như chỉnh sửa text,
format text, thêm ảnh, v.v..
Để phát triển thêm app, bạn quyết định cho phép người dùng undo và redo bất kỳ thao tác
nào thực hiện trên tệp văn bản. Bằng cách trước khi thực hiện bất kì thao tác nào, app sẽ
lưu state tất cả object vào trong một storage (take snapshot, lưu vào history). Sau đó, khi
user cần undo 1 thao tác, app lấy state đã được lưu trước đó trong storage và dùng nó để
restore state của tất cả object.
Nhưng cái khó ở đây là, làm thế nào để thật sự take snapshot? Bạn sẽ phải cần duyệt qua
tất cả field của object để lưu nó vào storage. Tuy nhiên, việc đó là không khả thi vì thực tế
hầu hết các objects thường giấu phần lớn data trong các trường private.
Có vẻ như chỉ để take snapshot, ta đã đưa app vào một tình thế rất gian nan: ta public tất
cả các private fields của editor object khiến nó trở nên mong manh và tạo ra 1 class
chuyên để copy editor object luôn phải thay đổi mỗi khi editor object thay đổi. Vậy còn
cách nào khác để triển khai undo redo không?
Giải pháp
Memento pattern giao việc tạo ra snapshot cho chính chủ nhân của state đó (originator
object). Chính object đó sẽ dễ dàng tạo ra snapshot vì nó có toàn quyền truy cập state của
nó.
Memento gợi ý ta nên lưu state được copy từ object vào một object gọi là memento.
Content của memento object không được truy cập từ các object khác ngoại trừ originator
object. Các object khác phải giao tiếp với memento thông qua interface bị giới hạn chỉ cho
phép lấy metadata của snapshot (metadata - những data về data chứ không phải là data:
ngày tạo, tên action, v.v.)..
c. Cấu trúc:

 Originator: Là class sản xuất ra snapshots từ các state của chính nó, đồng thời
restore state từ snapshots khi cần.
 Memento: Là object lưu giá trị, được xem như là một snapshot của Originator.
Trong thực tiễn nó là immutable class (class không thay đổi được) và truyền data
vào 1 lần duy nhất khi construct.
 Caretaker: Giữ câu trả lời cho các câu hỏi "khi nào" và "vì sao" cho những thời
điểm capture lại state của Originator và lúc restore lại state. Caretaker lưu trữ 1
stack các mementos. Khi Originator cần đi lùi về history, Caretaker lấy memento
trên cùng của stack và truyền vào restore method của Originator.
 Các ứng dụng cần chức năng cần Undo/ Redo: lưu trạng thái của một đối tượng
bên ngoài và có thể restore/ rollback sau này.
 Thích hợp với các ứng dụng cần quản lý transaction.

Ưu điểm
 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.
 Một số vấn đề cần xem xét khi sử dụng Memento Pattern:
 Khi có một số lượng lớn Memento được tạo ra có thể gặp vấn đề về bộ nhớ,
performance của ứng dụng.
 Khó đảm bảo trạng thái bên trong của Memento không bị thay đổi.
Nhược điểm
 App tiêu thụ nhiều RAM và xử lý nếu clients tạo mementos quá thường xuyên.
 Caretakers phải theo dõi vòng đời của originator để có thể hủy các mementos
không dùng nữa.
 Hầu hết các ngôn ngữ hiện đại, hay cụ thể hơn là dynamic programming
languages, ví dụ như PHP, Python và Javascript, không thể đảm bảo state bên
trong memento được giữ không ai đụng tới.
6. Observer:
a. Khái niệm
 Observer Pattern là một mẫu thiết kế thuộc nhóm Behavioral Pattern
 Định nghĩa mối phụ thuộc một - nhiều giữa các đối tượng để khi mà một đối tượng
có sự thay đổi trạng thái, tất cả 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.
Đặt vấn đề
Tưởng tượng rằng bạn có hai loại đối tượng: Khách hàng và Cửa hàng. Khách hàng rất
quan tâm đến một thương hiệu sản phẩm cụ thể (giả sử là một mẫu iPhone mới) chuẩn bị
được bày bán tại cửa hàng.

Khách hàng có thể ghé thăm cửa hàng mỗi ngày để kiểm tra đã có sản phẩm chưa. Nhưng
trong khi sản phẩm vẫn chưa được tung ra, hầu hết những chuyến đi tới cửa hàng này sẽ là
vô nghĩa.
Mặt khác, cửa hàng có thể gửi hàng tấn email (mà sẽ có khách hàng nghĩ là thư rác) cho
tất cả khách hàng mỗi khi có sản phẩm mới. Điều này sẽ giúp một số khách hàng đỡ phải
mất công đến cửa hàng vô số lần, tuy nhiên, đồng thời, điều này sẽ làm khó chịu những
khách hàng khác không quan tâm đến sản phẩm mới.
Có vẻ như có một sự xung đột xảy ra ở đây. Hoặc là khách hàng lãng phí thời gian kiểm
tra xem sản phẩm đã có hàng hay chưa, hoặc là cửa hàng lãng phí nguồn lực khi thông báo
cho khách hàng không muốn nhận thông báo.
Giải pháp
Đối tượng mà có một số trạng thái mà đối tượng khác quan tâm thường được gọi
là subject, nhưng vì nó cũng sẽ thông báo cho các đối tượng khác về những thay đổi đối
với trạng thái của nó, chúng tôi sẽ gọi nó là publisher. Tất cả các đối tượng khác muốn
theo dõi các thay đổi đối với trạng thái của publisher được gọi là subscribers.
Observer DP gợi ý rằng chúng ta nên thêm cơ chế subscribe vào class publisher để các đối
tượng riêng lẻ có thể subscribe hoặc hủy subscribe khỏi luồng sự kiện đến từ publisher đó.
Nghe có vẻ phức tạp, nhưng thực tế sẽ đơn giản hơn bạn nghĩ đấy. Trên thực tế, cơ chế
này bao gồm 1) một mảng để lưu trữ danh sách các tham chiếu đến các đối tượng
subscriber và 2) một số public method cho phép thêm và xóa subscriber.
Giờ đây, bất cứ khi nào một sự kiện quan trọng xảy ra với publisher, publisher sẽ chạy qua
mảng subscriber và gọi phương thức thông báo cụ thể của các đối tượng ấy.
Các ứng dụng thực có thể có hàng chục class subscriber khác nhau quan tâm đến việc theo
dõi các sự kiện của cùng một class publisher. Trong trường hợp này, chúng ta không nên
couple publisher vào tất cả các class đó. Bên cạnh đó, chúng ta có thể thậm chí không biết
trước về một số trong số những class đó nếu class publisher của chúng ta viết ra với mục
đích được người khác sử dụng.
Đó là lý do tại sao điều quan trọng là tất cả các subscriber phải implement cùng một giao
diện và publisher chỉ giao tiếp với các subscriber qua giao diện đó. Giao diện này nên khai
báo phương thức thông báo cùng với một tập hợp các tham số mà publisher có thể sử dụng
để chuyển một số dữ liệu theo ngữ cảnh cùng với thông báo.

c. Cấu trúc:
Một Observer Pattern bao gồm các thành phần sau:
Subject : chứa danh sách các observer, cung cấp phương thức để có thể
thêm và loại bỏ observer.
Observer : định nghĩa một phương thức update() cho các đối tượng sẽ
được subject thông báo đến khi có sự thay đổi trạng thái.
ConcreteSubject : cài đặt các phương thức của Subject, lưu trữ trạng thái
danh sách các ConcreateObserver, gửi thông báo đến các observer của nó
khi có sự thay đổi trạng thái.
ConcreteObserver : cài đặt các phương thức của Observer, lưu trữ trạng
thái của subject, thực thi việc cập nhật để giữ cho trạng thái đồng nhất với
subject gửi thông báo đến.
- Thường được sử dụng trong mối quan hệ 1-n giữa các object với nhau.
- Được sử dụng đa phần trong mẫu mô hình MVC (Model View Controller
Pattern) hoặc quản lí sự kiện.
- Đa phần ứng dụng trong dự án liên quan đến phương tiện truyền thông, liên
lạc, thông báo.

Ưu điểm
- Đảm bảo nguyên tắc Open/Closed Principle (OCP): Cho phép thay đổi Subject và
Observer một cách độc lập. Chúng ta có thể tái sử dụng các Subject mà không cần
tái sử dụng các Observer và ngược lại. Nó cho phép thêm Observer mà không sửa
đổi Subject hoặc Observer khác.
- Thiết lập mối quan hệ giữa các objects trong thời gian chạy.
- Sự thay đổi trạng thái ở 1 đối tượng có thể được thông báo đến các đối tượng khác
mà không phải giữ chúng liên kết quá chặt chẽ.
- Không giới hạn số lượng Observer
Nhược điểm
- Unexpected update: Bởi vì các Observer không biết về sự hiện diện của nhau, nó
có thể gây tốn nhiều chi phí của việc thay đổi Subject.
- Subscriber được thông báo theo thứ tự ngẫu nhiên.
7. State:
a. Khái niệm
 State Pattern là một mẫu thiết kế thuộc nhóm Behavioral Pattern – những mẫu
thiết kế xác định các mẫu giao tiếp chung giữa các object. Từ đó các mẫu này
tăng tính linh hoạt trong việc thực hiện việc giao tiếp giữa các object.
Đặt vấn đề
Trong thực tế, có rất nhiều thứ tại bất kỳ thời điểm nào cũng có một số trạng thái hữu hạn
khác nhau, và chúng có thể chuyển từ trạng thái này sang trạng thái khác. Trong các trạng
thái khác nhau đó, chúng có những đặc tính và hành vi khác nhau,
Bạn cũng có thể áp dụng cách tiếp cận này cho các object. Ta có một class Document. Và
class Document có thể ở một trong ba State (trạng thái):Draft, Moderation, Published.

Publish method của class Document hoạt động hơi khác nhau ở mỗi State:
 Trong Draft, chuyển Document sang trạng thái Moderation.
 Trong Moderation, chuyển Document sang trạng thái Public
 Trong Published, không thực hiện điều gì nữa.
Để diễn tả sự thay đổi hành vi và chức năng này, ta có thể sử dụng if-then hoặc switch-
case. Tuy nhiên, khi các hành vi và chức năng thay đổi quá nhiều, ta sẽ cần tốn rất nhiều
công sức để cài đặt hết trường hợp hành vi thay đổi.
Điểm yếu lớn nhất của State Machine dựa trên các điều kiện tự bộc lộ khi chúng ta bắt đầu
thêm nhiều State và các state-dependent behavior vào lớp Document.
Project càng lớn thì càng gặp nhiều trở ngại, khó khăn trong việc dự đoán tất cả các trạng
thái và quá trình chuyển đổi trong giai đoạn phát triển
Ví dụ:
 Hãy xem xét một lớp TCPConnection đại diện cho một kết nối mạng. Đối tượng
kết nối TCPConnection có thể ở một trong một số trạng thái khác nhau:
Established, Listening, Closed. Khi một đối tượng TCPConnection nhận được yêu
cầu từ các đối tượng khác, nó sẽ thực hiện hành vi khác nhau tùy thuộc vào trạng
thái hiện tại của nó.
 Kết quả đạt được của một Open request phụ thuộc vào việc kết nối ở trạng thái
Closed hay Established. State pattern mô tả cách TCPConnection thể hiện hành vi
khác nhau tùy vào mỗi trạng thái.
 Ý tưởng chính trong mẫu này là giới thiệu một lớp trừu tượng gọi là TCPState để
đại diện cho các trạng thái của kết nối mạng. Lớp TCPState khai báo một interface
chung cho tất cả các lớp thể hiện các trạng thái hoạt động khác nhau. Các lớp con
của TCPState sẽ được cài đặt những hành vi cụ thể.
 Lớp TCPEstablished và TCPClosed sẽ triển khai hành động cụ thể cho trạng thái
Established và Closed của TCPConnection
Giải pháp
State pattern cho rằng nên tạo các class mới cho tất cả các trạng thái có thể có của một
object và tríchxuất tất cả các hành vi dành riêng cho trạng thái vào các class đó.

Thay vì tự thực hiện tất cả các hành vi, đối tượng ban đầu, được gọi là ngữ cảnh, lưu trữ
một tham chiếu đến một trong các đối tượng trạng thái đại diện cho trạng thái hiện tại của
nó và ủy quyền tất cả các công việc liên quan đến trạng thái cho đối tượng đó.
Để chuyển context sang state khác, hãy thay thế state object hoạt động bằng một object
khác đại diện cho state mới đó. Điều này chỉ có thể thực hiện được nếu tất cả các state
class tuân theo cùng một interface và context hoạt động với các object này thông qua
interface đó.
c. Cấu trúc:
 Context: Là lớp có nhiều trạng thái, hành vi lớp sẽ bị thay đổi bởi trạng thái. Được
sử dụng bởi Client. Client không truy cập trực tiếp đến State của Object. Lớp
Context này chứa thông tin của ConcreteState object, cho hành vi nào tương ứng
với trạng thái nào hiện đang được thực hiện
 State Interface: Là interface hoặc abstract class xác định các đặc tính cơ bản của
tất cả ConcreteState Object. Chúng sẽ được sử dụng bởi đối tượng Context để truy
cập chức năng có thể thay đổi.

 Concrete States: Là lớp cụ thể của state ứng với từng trạng thái của context
 Cả Context và ConcreteState đều có thể thiết lập trạng thái tiếp theo của ngữ cảnh
và thực hiện chuyển đổi trạng thái thực tế bằng cách thay thế đối tượng trạng thái
được liên kết với ngữ cảnh.
 Sử dụng State pattern khi bạn có một object hoạt động khác nhau tùy thuộc vào
trạng thái hiện tại của nó, số lượng trạng thái là rất lớn và code của trạng thái cụ
thể thường xuyên thay đổi.
 Sử dụng State pattern khi bạn có một lớp với nhiều các điều kiện lớn làm thay đổi
cách class hoạt động theo các giá trị hiện tại của các trường của class.
 Sử dụng State Pattern khi bạn có nhiều code trùng lặp qua các trạng thái và chuyển
đổi tương tự của State Pattern dựa trên điều kiện.
 Thay đổi hành vi object dựa trên trạng thái object
 Thay thế việc sử dụng rất nhiều điều kiện thay đổi cách lớp hành động dựa trên
các giá trị của lớp
Ưu điểm
 Đảm bảo nguyên tắc Single Responsibility (SRP): Tách biệt mỗi State tương ứng
với 1 class riêng biệt.
 Đảm bảo nguyên tắc Open/Closed Principle (OCP): chúng ta có thể thêm một
State mới mà không ảnh hưởng đến State khác hay Context hiện có.
 Giữ hành vi cụ thể tương ứng với mỗi State (trạng thái).
 Giúp chuyển State một cách rõ ràng.
 Loại bỏ các câu lệnh xét trường hợp (If, Switch case) giúp đơn giản code của
context
Nhược điểm
 Việc sử dụng state pattern có thể quá mức cần thiết nếu state machine chỉ có một
vài trạng thái hoặc hiếm khi thay đổi có thể dẫn đến việc tăng độ phức tạp của
code

8. Strategy:
a. Khái niệm
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.
Định nghĩa một tập hợp các thuật toán giống nhau, encapsulate chúng và khiến chúng có
thể thay thế cho nhau. Strategy làm cho phần thuật toán độc lập khỏi client sử dụng nó.
Giả sử chúng ta cần xây dựng một app giúp tìm đường đi trong thành phố. Ban đầu app
chỉ giúp những người đi bộ tìm đường đi, chúng ta chỉ việc viết thuật toán này ở bất kỳ
chỗ nào cần. Nhưng sau này khi yêu cầu tăng lên như phải hỗ trợ thêm việc tìm đường
bằng xe hơi, xe đạp,.. Điều này dẫn đến phải thay đổi thuật toán ở những chỗ đã sử dụng,
Điều này có thể khiến chương trình trở nên khó maintain và nhiều khi còn gây nên những
bug trên những phần đang hoạt động tốt
Để giải quyết việc này, strategy pattern nói chúng ta cần tạo cho mỗi thuật toán một class
riêng gọi là strategy. Phần code sử dụng thuật toán này sẽ thay thế phần hardwire code
bằng reference tới strategy object. Phần code đó sẽ không cần biết chi tiết về loại strategy
mà nó sử dụng, nó có thể sử dụng mọi strategy với phần interface mà strategy cung cấp
Như vậy phần thuật toán được tách biệt khỏi phần sử dụng, giờ chúng ta có thể chỉnh sửa
thuật toán hoặc thêm thuật toán mới mà không cần chỉnh sửa phần code nào khác ngoài
các bên trong strategy class tương ứng
c. Cấu trúc:

 Context: Class sử dụng các strategy object và chỉ giao tiếp với các strategy object
thông qua interface
 Strategy: Cung cấp một interface chung cho context giao tiếp với các strategy
object
 Concrete Strategy: Implement các thuật toán khác nhau cho context sử dụng
 Client: Có trách nhiệm tạo ra các strategy object và truyền vào cho context sử
dụng

 Muốn sử dụng các biến thể khác nhau của một xử lý trong một đối tượng và có thể
chuyển đổi giữa các xử lý trong runtime.
 Khi có nhiều lớp tương đương chỉ khác cách chúng thực thi một vài hành vi.
 Khi muốn tách biệt business logic của một lớp khỏi implementation details của các
xử lý.
 Khi lớp có toán tử điều kiện lớn chuyển đổi giữa các biến thể của cùng một xử lý.
Ưu điểm
 Có thể thay thế các thuật toán linh hoạt với nhau
 Tách biệt phần thuật toán khỏi phần sử dụng thuật toán
 Có thể thay thế việc kế thừa bằng việc encapsulate thuật toán
 Tăng tính open-closed: Khi thay đổi thuật toán hoặc khi thêm mới thuật toán,
không cần thay đổi code phần context
Nhược điểm
 Không nên áp dụng nếu chỉ có một vài xử lý và hiếm khi thay đổi.
 Client phải nhận biết được sự khác biệt giữa các strategy.
9. Template Method:
a. Khái niệm
Template Method Pattern là một trong những Pattern thuộc nhóm hành vi
(Behavior Pattern). Pattern này nói rằng “Định nghĩa một bộ khung của một thuật toán
trong một chức năng, chuyển giao việc thực hiện nó cho các lớp con. Mẫu Template
Method cho phép lớp con định nghĩa lại cách thực hiện của một thuật toán, mà không
phải thay đổi cấu trúc thuật toán“.
Điều này có nghĩa là Template method giúp cho chúng ta tạo nên một bộ khung
(template) cho một vấn đề đang cần giải quyết. Trong đó các đối tượng cụ thể sẽ có cùng
các bước thực hiện, nhưng trong mỗi bước thực hiện đó có thể khác nhau. Điều này sẽ tạo
nên một cách thức truy cập giống nhau nhưng có hành động và kết quả khác nhau.

Mẫu Template Method đề xuất nên chia nhỏ một thuật toán thành một loạt các bước,
chuyển các bước này thành các phương thức và đặt một loạt các lệnh gọi đến các phương
thức này bên trong một template method duy nhất. Các bước có thể là trừu tượng hoặc có
thể có vài triển khai mặc định.
Template Method là một mẫu thiết kế hành vi định nghĩa khung của một thuật toán
trong lớp cha nhưng cho phép các lớp con ghi đè các bước cụ thể của thuật toán mà
không thay đổi cấu trúc của nó.
c. Cấu trúc:
Cách thành phần trong :
- Abstract Class:
o Định nghĩa các phương thức trừu tượng (operation()) cho từng bước có thể
được điều chỉnh bởi các lớp con.
o Cài đặt một phương thức duy nhất (Template method()) điều khiển thuật
toán và gọi các bước riêng lẻ đã được cài đặt ở các lớp con.
- Concreate Class: là một thuật toán cụ thể, cài đặt các phương thức của
AbstractClass. Các thuật toán này ghi đè lên các phương thức trừu tượng để cung
cấp các triển khai thực sự. Nó không thể ghi đè phương thức duy nhất đã được cài
đặt ở AbstractClass (templateMethod).

 Khi có một thuật toán với nhiều bước và mong muốn cho phép tùy chỉnh chúng
trong lớp con.
 Mong muốn chỉ có một triển khai phương thức trừu tượng duy nhất của một thuật
toán.
 Mong muốn hành vi chung giữa các lớp con nên được đặt ở một lớp chung.
 Các lớp cha có thể gọi các hành vi trong các lớp con của chúng một cách thống
nhất (step by step).
Ưu điểm
 Tái sử dụng code (reuse), tránh trùng lặp code (duplicate): đưa những phần trùng
lặp vào lớp cha (abstract class).
 Cho phép người dùng override chỉ một số phần nhất định của thuật toán lớn, làm
cho chúng ít bị ảnh hưởng hơn bởi những thay đổi xảy ra với các phần khác của
thuật toán.
Nhược điểm
 Template method có càng nhiều bước để override càng khó bảo trì.
10. Visitor:
a. Khái niệm
 Visitor là một mẫu thiết kế thuộc nhóm Behavior Pattern
 Visitor còn được biết đến như là Double dispatch
 Cho phép định nghĩa các operation trên một tập hợp các đối tượng không đồng
nhất về kiểu mà không làm thay đổi định nghĩa về lớp của các đối tượng đó.
 Cho phép tách các thuật toán khỏi các đối tượng mà chúng hoạt động.
 Giúp phục hồi lại kiểu dữ liệu bị mất (thay vì dùng instanceof).

Đặt vấn đề
Ví dụ ta đang xây dựng ứng dụng vẽ bản đồ, mỗi địa điểm là một node, mỗi node là một
đối tượng của các lớp khác nhau tương ứng với các loại công trình (nhà, công ty, công
viên,...). Nhiệm vụ ở đây là xuất cả bản đồ thành file xml.
Thoạt nhìn công việc có vẻ rõ ràng, ta sẽ xuất từng node riêng biệt thành từng file xml lẻ,
rồi nối tất cả lại thành một file xml lớn bằng cách thêm phương thức xuất file vào từng lớp
node, duyệt qua và thực thi phương thức này của từng node.
Tuy nhiên, việc định nghĩa phương thức xuất file trong mỗi lớp làm tăng độ phức tạp
không mong muốn cho lớp và dễ gây ra lỗi. Không những thế, khi phát triển thêm một
cách xuất file có định dạng khác ta lại phải tiếp tục sửa code bên trong lớp một lần nữa.
Mẫu Visistor sẽ hỗ trợ giải quyết vấn đề này bằng cách đặt hành vi mới vào một lớp riêng
biệt được gọi là visitor, thay vì cố gắng tích hợp nó vào các lớp hiện có. Đối tượng muốn
thực hiện hành vi sẽ được truyền vào một trong các phương thức của visitor dưới dạng đối
số, cung cấp cho phương thức này quyền truy cập vào tất cả dữ liệu cần thiết có trong đối
tượng
Giải pháp
Mẫu Visitor đề xuất ta đặt hành vi phát sinh đó vào một lớp riêng biệt gọi là visitor, thay
vì đưa nó vào lớp có sẵn. Đối tượng ban đầu sẽ được truyền vào một trong các phương
thức của visitor, cung cấp cho phương thức đó các thông tin cần thiết để thực hiện hành
động mong muốn.
Visitor lường trước được vấn đề đó, nên nó thường đi kèm với một kỹ thuật được gọi là
Double Dispatch. Double dispatch giúp ta thực thi phương thức với đúng đối tượng mà
không cần phải xét điềukiện. Thay vì để client lựa chọn nên dùng phương thức nào cho
đối tượng nào, giờ ta để trách nhiệm đó cho chính đối tượng xử lý.
Vì một đối tượng luôn biết nó thuộc lớp nào, nó sẽ tự chọn một phương thức đúng của
visitor. Có thể nói, nó "accept" một visitor và nói cho visitor phương thức nào nên được
thực thi.
c. Cấu trúc:

 Visitor interface khai báo một tập hợp các phương thức thăm có thể lấy các phần
tử cụ thể của cấu trúc đối tượng làm đối số. Các phương thức này có thể trùng tên
nếu chương trình được viết bằng ngôn ngữ có hỗ trợ nạp chồng, nhưng kiểu tham
số của chúng phải khác nhau.
 Mỗi Concrete Visitor triển khai một số phiên bản của các hành vi giống nhau,
được điều chỉnh cho các lớp phần tử cụ thể khác nhau.
 Element interface khai báo một phương thức để "chấp nhận" các visitor. Phương
thức này phải có một tham số được khai báo với kiểu là visitor interface.

 Mỗi Concrete Element phải triển khai thực hiện phương thức chấp nhận. Mục đích
của phương thức này là chuyển hướng cuộc gọi đến phương thức của visitor thích
hợp tương ứng với lớp phần tử hiện tại. Cần biết rằng ngay cả khi một lớp phần tử
cơ sở triển khai phương thức này, tất cả các lớp con vẫn phải ghi đè phương thức
này trong các lớp của chính chúng và gọi phương thức thích hợp trên đối tượng
visitor.
 Client thường đại diện cho một tập hợp hoặc một số đối tượng phức tạp khác (ví
dụ, một cây Composite). Thông thường, các client không biết tất cả các lớp phần
tử cụ thể vì chúng làm việc với các đối tượng từ tập hợp đó thông qua một số
interface trừu tượng.
Visitor được sử dụng khi:
 Sử dụng khi cần thực hiện thao tác trên tất cả các phần tử của cấu trúc đối tượng
phức tạp.
 Sử dụng để làm sạch logic nghiệp vụ của các hành vi phụ trợ.
 Sử dụng khi một hành vi chỉ có ý nghĩa trong một số lớp của hệ thống phân cấp
lớp, nhưng không có ý nghĩa trong các lớp khác.
Ưu điểm
 Open/Closed Principle: có thể giới thiệu một hành vi mới có thể hoạt động với các
đối tượng của các lớp khác nhau mà không cần thay đổi các lớp này.
 Single Responsibility Principle: có thể chuyển nhiều phiên bản của cùng một hành
vi vào cùng một lớp.
 Một đối tượng visitor có thể tích lũy một số thông tin hữu ích khi làm việc với
nhiều đối tượng khác nhau. Điều này có thể giúp ích khi ta muốn duyệt qua một số
cấu trúc đối tượng phức tạp, chẳng hạn như cây đối tượng và áp dụng visitor cho
từng đối tượng của cấu trúc này.
Nhược điểm
 Cần cập nhật tất cả visitor mỗi khi một lớp được thêm vào hoặc xóa khỏi hệ thống
phân cấp phần tử.
 Các visitor có thể thiếu quyền truy cập cần thiết vào các trường riêng tư và phương
thức của các phần tử mà họ phải làm việc với.

BaoCao_22DesignPatterns.docx

More Related Content

Similar to BaoCao_22DesignPatterns.docx (20)

Recently uploaded (6)

BaoCao_22DesignPatterns.docx