TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN BÁO CÁO ĐỒ ÁN 1: PATTERNS ĐỂ ĐỊNH NGHĨA GIẢI PHÁP PHẦN MỀM

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

BÁO CÁO ĐỒ ÁN 1
Đề tài: SỬ DỤNG PATTERNS ĐỂ ĐỊNH NGHĨA GIẢI PHÁP PHẦN MỀM (USING
PATTERNS TO DEFINE A SOFTWARE SOLUTION)

Lớp: SE121.M21.PMCL
Giảng viên: ThS. Nguyễn Công Hoan
Sinh viên: Phan Mạnh Phát – 15520605

Thành phố Hồ Chí Minh, 6/2022


NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
………………………………………………………………………………………...
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………

…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
………………………………………………………………………………………....


LỜI CẢM ƠN
Để thực hiện tốt đề tài này, với tất cả sự kính trọng, nhóm em xin kính gửi lời
cảm ơn đến thầy Nguyễn Công Hoan đã trực tiếp giảng dạy, truyền đạt và hỗ trợ cho
nhóm trong quá trình nghiên cứu để nhóm em hồn thành đề tài này.
Trong quá trình thực hiện, cũng như quá trình làm báo cáo, chúng em khó
tránh khỏi những sai sót, nhóm em hi vọng thầy bỏ qua cũng như chúng em rất
mong nhận được ý kiến đóng góp của thầy để có thể học thêm được nhiều kinh
nghiệm để hồn thành tốt những đồ án lần sau. Một lần nữa nhóm em xin chân thành
cảm ơn thầy. Chúng em xin chân thành cảm ơn!
Nhóm nghiên cứu
Tp. Hồ Chí Minh, tháng 6 năm 2022


Báo cáo đồ án
I. Giới thiệu tổng quan ...................................................................................... 3
1. Thơng tin nhóm ............................................................................................. 3

2. Giới thiệu đề tài ............................................................................................. 3
2.1

Phạm vi nghiên cứu ................................................................................ 3

2.2

Nội dung nghiên cứu ............................................................................... 3

2.3

Nội dung nghiên cứu ............................................................................... 4

2.4

Kết quả hướng tới ................................................................................... 4

3. Công cụ sử dụng ............................................................................................ 4
II.

Design Patterns ........................................................................................... 4

1. Giới thiệu chung ............................................................................................ 4
2. Định nghĩa ..................................................................................................... 4
3. Ưu điểm ......................................................................................................... 5
4. Phân loại design patterns .............................................................................. 5
4.1

Nhóm khởi tạo (Creational pattern) ...................................................... 5

4.2Nhóm cấu trúc (Structural pattern) ........................................................... 6
4.3Nhóm hành vi (Behavioral Pattern) ............................................................ 6
III. Factory Method ........................................................................................... 7
1. Giới thiệu ....................................................................................................... 7
1.1 Định nghĩa .................................................................................................. 7
1.2 Đặt vấn đề ................................................................................................... 7
Giả sử ta có 3 class Dog, Cat, Duck cùng implement interface Animal. ............. 7
2. Cấu trúc ......................................................................................................... 9
3. Ưu điểm .......................................................................................................10
4. Nhược điểm .................................................................................................11
IV.

Abstract Factory ....................................................................................... 11

1.2 Vấn đề ...........................................................................................................11
2.Cấu trúc ...........................................................................................................14
V. Builder .......................................................................................................... 15
VI.Prototype ....................................................................................................... 23
1.2Đặt vấn đề ...................................................................................................... 24


2.Cấu trúc ........................................................................................................... 26
3.Ưu điểm ...........................................................................................................28
4.Khuyết điểm ....................................................................................................29
VII. Adapter ....................................................................................................... 29
VIII. Bridge ........................................................................................................ 34
IX. Composite ..................................................................................................... 38
X. Decorator ....................................................................................................... 42
XI. Faỗade ........................................................................................................... 54
XII.Flyweight ...................................................................................................... 56

XIII. Proxy .......................................................................................................... 59
XIV. Intepreter ................................................................................................... 62
XV. Template Method ........................................................................................ 65
XVI. Chain of Responsibility ............................................................................. 68
XVII. Command ................................................................................................. 71
XXVIII. Iterator ................................................................................................. 78
XIX. Mediator .................................................................................................... 81
XX. Memento...................................................................................................... 84
XXI. Observer .................................................................................................... 88
XXII. State .......................................................................................................... 92
XXIII. Strategy ................................................................................................... 98
XXIV. Visitor.................................................................................................... 101
XXV.Kinh nghiệm rút ra ................................................................................. 104
Tài liệu tham khảo ........................................................................................... 105


Giới thiệu tổng quan

I.

1. Thơng tin nhóm
MSSV

Họ tên

Email

15520605

Phan Mạnh Phát

2. Giới thiệu đề tài
Với các phần mềm và ứng dụng lớn hiện này, cần một thiết kế rõ ràng và hướng
tới những việc củng cố, chỉnh sửa trước và sau khi hoạt động là điều rất cần thiết.
Trong quá trình phát triển và vận hành sẽ xảy ra nhiều vấn đề khác nhau về nhiều
mặt nên việc đảm bảo ứng dụng có thể có tính chỉnh sửa và chạy tốt thì cần một số
chuẩn bị tốt kể từ khâu thiết kế hệ thống cũng như có nhưng quy tắc, các bước cụ thể
trong việc lập trình để hệ thống có thể là một khối thống nhất từ đó sẽ có một phần
mềm tốt sau này.
 Xét về vấn đề: những nhà nghiên cứu và phát triển các vấn đề trong việc thực
hiện các dự án để hạn chế và giải quyết các vấn đề có thể xảy ra trong lập
trình đã tiến tới phát triển các mẫu thiết kế.
 Xét về ứng dụng: vì đây là những phương pháp trong lập trình nên có thể ứng
dụng trong nhiều dự án khác nhau với các ngơn ngữ lập trình khác nhau.
2.1 Phạm vi nghiên cứu
Hiện nay, có rất nhiều mẫu thiết kế với mỗi mẫu sẽ gắn liền giải quyết một vấn đề
nhất định trong lập trình. Nhưng nổi bật hơn cả và được ứng dụng nhiều ta có 23
mẫu thiết kế được sử dụng nhiều.
2.2 Nội dung nghiên cứu
Tìm hiểu về các mẫu, đặc biệt là 23 mẫu thiết kế (Tìm hiểu các vấn đề mà các
mẫu hướng tới để giải quyết vấn đề lập trình)


2.3 Nội dung nghiên cứu
Tìm hiểu 23 mẫu thiết kế với những ưu nhược điểm của từng mẫu.
Tìm hiểu vấn đề và ứng dụng của từng mẫu trong việc giải quyết vấn đề.
2.4 Kết quả hướng tới
Hiểu được các vấn đề trong lập trình, có thể ứng dụng từng mẫu để thiết kế và giải

quyết các vấn đề lập trình để được một ứng dụng tốt kể cả trong việc vận hành lẫn
chỉnh sửa hoặc bảo trì.
3. Cơng cụ sử dụng
Trong q trình xây dựng phần mềm, nhóm đã sử dụng phần mềm sau:
● Eclipse IDE: IDE hỗ trợ xây dựng ứng dụng phía server (Spring Boot).
● Visual Studio Code: hỗ trợ xây dựng giao diện người dùng (ReactJS)
II.

Design Patterns

1. Giới thiệu chung
Design Pattern là một giải pháp chung để giải quyết các vấn đề phổ biến khi thiết
kế phần mềm trong lập trình hướng đối tượng OOP.
2. Định nghĩa
 Design pattern: là các giải pháp được nghiên cứu để giải quyết các vấn đề
thường gặp trong lập trình. Được tái sử dụng nhiều trong việc thiết kế phần
mềm nhằm giải quyết các vấn đề phần mềm.
 Là một kỹ thuật trong lập trình hướng đối tượng, là một kĩ thuật lập trình nên
được ứng dụng trong mọi ứng dụng với mọi ngơn ngữ lập trình khác nhau như
java, C#, python,…
 Sử dụng các patterns vì đây là các phương pháp tối ưu được nghiên cứu.


 Giải quyết các vấn đề một cách tối ưu trong việc lập trình hướng đối tượng,
phù hợp với các chuyên viên vững về lập trình OOP, thiết kế và hiểu rõ một
ngơn ngữ lập trình cụ thể.
3. Ưu điểm
 Tăng tốc độ phát triển phần mềm: Cung cấp cho các developers một công
cụ cụ thể để giải quyết các vấn đề thơng dụng trong lập trình và thiết kế phần
mềm. Ngay cả khi khơng gặp vấn đề, vẫn có thể sử dụng các patterns để lập

trình, dựa vào các nguyên tắc cụ thể mà patterns cung cấp.
 Code tường minh, dễ dàng Team work: Do cung cấp một nguyên tắc cụ thể
nên việc lập trình của các developers sẽ dựa vào các patterns với các cấu trúc
cụ thể => Tối ưu thời gian.
 Tái sử dụng code: Giúp các developers tái sử dụng và sửa chữa code dễ dàng
hơn.
 Hạn chế lỗi tiềm ẩn, dễ dàng nâng cấp: Việc thực hiện dự án theo một cấu
trúc cụ thể sẽ tránh được các lỗi phát sinh sau này, dễ quản lý hơn, dễ chỉnh
sửa nâng cấp hơn.
4. Phân loại design patterns
Hiện nay, có rất nhiều mẫu được nghiên cứu và phát triển. Về cơ bản ta có 3 nhóm
patterns chính và 23 mẫu phổ biến thường được ứng dụng.
 Nhóm khởi tạo (Creational pattern)
 Nhóm cấu trúc (Structural pattern)
 Nhóm hành vi (Behavioral pattern)
4.1 Nhóm khởi tạo (Creational pattern)
Gồm 5 mẫu:
- Singleton
- Factory Method
- Abstract Factory


- Builder
- Prototype
Các patterns loại này cung cấp giải pháp để tạo ra các đối tượng và che giấu được
logic của việc tạo ra nó thay vì tạo ra đối tượng theo cách trực tiếp (sử dụng từ khoá
new). Điều này giúp chương trình trở nên mềm dẻo hơn trong việc quyết định đối
tượng nào cần được tạo ra trong những tình huống khác nhau.
4.2Nhóm cấu trúc (Structural pattern)
Gồm 7 mẫu:

- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy
Những patterns loại này liên quan tới class và các thành phần của đối tượng. Nó
dùng để thiết lập, định nghĩa quan hệ giữa các đối tượng. Hệ thống càng lớn thì mẫu
này càng đóng vai trị quan trọng. Ta có thể dựa vào class diagram để theo dõi mẫu
này.
4.3Nhóm hành vi (Behavioral Pattern)
Gồm 11 mẫu:
- Interpreter
- Template Method
- Chain of Responsibility
- Command
- Iterator


- Mediator
- Memento
- Observer
- State
- Strategy
- Visitor
III.

Factory Method

1. Giới thiệu
Factory method là một mẫu thiết kế thuộc nhóm khởi tạo.
1.1 Định nghĩa
Factory Method cung cấp một interface. 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 tạo một đối tượng (object) cụ thể cho lớp con (subclass).
1.2 Đặt vấn đề
Giả sử ta có 3 class Dog, Cat, Duck cùng implement interface Animal.


Khi mà chúng ta muốn khởi tạo ra một object có type là Animal, nhưng mà ta
chưa biết sẽ phải tạo ra con chó, mèo hay con vịt mà nó phụ thuộc vào một số
điều kiện, hoàn cảnh cụ thể nào đó. Thì thơng thường ta sẽ khởi tạo như thế
này.

Nhưng mà nếu như chúng ta cần sử dụng những logic để tạo ra object này ở
nhiều nơi khác nhau, thì những đoạn code này sẽ bị lặp đi lặp lại.


Đặc biệt là khi chúng ta muốn thay đổi, chỉnh sửa hay mở rộng, ta đều phải sửa
tất cả những nơi có logic đó gây mất thời gian và dễ bị sót hay lỗi.

Từ đó thì Factory Method ra đời, với vai trò là một cái interface với một
method mà nó sử dụng để gói cái việc khởi tạo một object vào cái method đó.
Tức là chúng ta sẽ đưa ra những cái business logic để khởi tạo ra những object
này vào một cái factory method.
Khi đó nó sẽ giúp cho code của chúng ta được gọn đi rất là nhiều so với việc sử
dụng logic đấy ở nhiều nơi khác nhau. Đặc biệt là nó giúp code của bạn có tính
đa hình, có nghĩa là tùy vào từng trường hợp cụ thể, chúng ta có thể chọn sử
dụng factory method với parameter khác nhau để quyết định khởi tạo ra object

nào.

2. Cấu trúc


Một Factory bao gồm các thành phần cơ bản sau:
● Superclass: mơt supperclass trong Factory Pattern, có thể là một interface,
abstract class hay một class thông thường.
● Subclasses: các subclass sẽ implement các phương thức của supperclass theo
nghiệp vụ, business riêng của nó.
● Factory: một class chịu tránh nhiệm khởi tạo và trả về các đối tượng
subclass dựa theo tham số đầu vào.
Lớp này là Singleton hoặc cung cấp một public static method cho việc truy xuất
và khởi tạo đối tượng. Factory class sử dụng if-else hoặc switch-case để xác
định class con đầu ra
● Client: nơi sẽ gọi và sử dụng Factory để tạo lập đối tượng mong muốn.
3. Ư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 đích tạo mới object và khơng cần quan
tâm đến cách nó được tạo ra)

4. 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 constructor nên các

class không thể mở rộng và kế thừa.
IV.

Abstract Factory

1.Giới thiệu
Abstract Factory là một design pattern thuộc nhóm khởi tạo.
1.1 Định nghĩa
Là một interface được sử dụng để tạo ra các đối tượng có quan hệ gần gũi với nhau
mà khơng cần chỉ định đến lớp cụ thể của chúng.
1.2 Vấn đề
Bạn có một dự án làm một trang bán đồ nội thất. Ứng dụng của bạn bao gồm các lớp
sau:

1. Các sản phẩm có quan hệ với nhau như: Sofa, Chair và CoffeTable.
2. Các biến thể của nhóm sản phẩm đó. Ví dụ như
nhóm Sofa + Chair + CoffeTable có các biến thể
như Modern, Victorian và ArtDeco.

Bạn cần có cách để khi tạo một đồ nội thất đơn lẻ, nó phải phù hợp với các đồ vật
khác trong nhóm của nó. Khách hàng sẽ khó chịu khi họ nhận về những đồ vật trong
nhóm có biến thể khác nhau.
Bên cạnh đó, bạn khơng muốn thay đổi code mỗi khi thêm sản phẩm hoặc nhóm sản
phẩm trong chương trình. Danh mục nội thất được cập nhật rất thường xuyên, và bạn
khơng muốn thay đổi code mỗi khi nó diễn ra.
1.3 Giải pháp
Việc đầu tiên cần làm theo Abstract Factory là khai báo inteface rõ ràng cho mỗi sản
phẩm riêng biệt trong nhóm sản phẩm. Và tạo tất cả biến thể của sản phẩm theo sau
inteface đó.
Ví dụ tất cả biến thể của ghế được triển khai trong interface Chair, tất cả sofa được
triển khai trong interface Sofa ,...


Bước tiếp theo là khai báo Abstract Factory - là interface chứa tất cả phương thức tạo
cho tất cả sản phẩm trong nhóm sản phẩm
(vd: createChair, createSofa và createCoffeTable). Các phương thức này trả về một
kiểu sản phẩm trừu tượng (abstract) được biểu diễn bởi interface mà chúng ta trích
xuất trước đó: Chair, Sofa, CoffeTable,...

Vậy cịn các biến thể của sản phẩm?
Với từng biến thể của nhóm sản phẩm, ta tạo ra một lớp factory riêng biệt dựa trên
interface Abstract Factory. Factory là lớp trả về kiểu sản phẩm riêng biệt. Ví

dụ, ModernFurnitureFactory có thể tạo ra các đối
tượng ModernChair, ModernSofa hay ModernCoffeTable.
Code client làm việc với factory hay sản phẩm thơng qua interface trừu tượng. Vì
vậy có thể thay đổi kiểu factory hay biến thể của sản phẩm cho code client nhận mà
khơng gây ra bất kỳ lỗi gì.
Giả sử client muốn một factory để tạo ghế (chair). Nó sẽ khơng cần quan tâm
kiểu của lớp factory đó, cũng như kiểu ghế nhận về. Dù là Modern hay Victorian, nó
cũng sẽ xử lý theo cùng một cách là thông qua interface trừu tượng Chair. Với cách
tiếp cận này client chỉ cần quan tâm là ghế sẽ triển khai phương thức sitOn như thế
nào. Bên cạnh đó, bất kỳ biến thể nào của chair, nó cũng sẽ phù hợp
với sofa và coffe-table được tạo cùng đối tượng factory.
2.Cấu trúc

1. Abstract Product là inteface cho các sản phẩm riêng biệt nhưng có quan hệ
với nhau tạo nên một nhóm sản phẩm.


2. Concrete Product là các triển khai biến thể của abstract product, được gom
nhóm theo biến thể. Mỗi abstract product (chair/sofa) sẽ được triển khai tất cả
biến thể (modern, victorian).
3. Abstract Factory là interface có tập hợp phương thức khởi tạo cho từng
abstract product.
4. Concrete Factory là triển khai phương thức khởi tạo của abstract factory.
Mỗi concrete factory tương ứng với biến thể cụ thể của sản phẩm và chỉ tạo
sản phẩm theo biến thể đó.
3.Ưu điểm
 Bạn có thể chắc chắn rằng các sản phẩm lấy từ một factory sẽ tương thích với
nhau.
 Tránh được kết hợp quá chặt chẽ giữa code client và concrete product.
 Single Responsibility Principle. Bạn có thể di chuyển code tạo sản phẩm vào

một nơi trong chương trình, giúp hỗ trợ code dễ dàng hơn.
 Open/Closed Principle. Bạn có thể thêm các biến thể mới vào chương trình,
mà khơng làm ảnh hưởng đến code client hiện tại.
4.Nhược điểm
❌ Code có thể trở nên phức tạp khi bạn thêm vào quá nhiều interface và lớp để triển
khai pattern.

V.

Builder

1. Giới thiệu
Là mẫu thiết kế thuộc nhóm khởi tạo

1.1 Định nghĩa




Builder Pattern là một mẫu thiết kế được dùng để cung cấp một giải pháp linh
hoạt cho các vấn đề tạo đối tượng (object) khác nhau trong lập trình hướng đối
tượng.



Cho phép bạn xây dựng các đối tượng phức tạp bằ ng cách sử du ̣ng các đố i
tươṇ g đơn giản và sử du ̣ng tiế p câ ̣n từng bước. Builder Pattern còn cho phép
bạn tạo ra các kiểu thể hiện khác nhau của một đối tượng bằng cách sử dụng
cùng một constructor code.

1.2 Vấn đề

Hãy tưởng tượng một đối tượng phức tạp địi hỏi nhiều cơng sức, khởi tạo từng
bước của nhiều trường và các đối tượng lồng nhau. Code khởi tạo như vậy thường
được chôn bên trong một hàm constructor khổng lồ với rất nhiều tham số. Hoặc thậm
chí tệ hơn: nằm rải rác trên tồn bộ client code.
Ví dụ: hãy nghĩ về cách tạo object House. Để xây dựng một ngôi nhà đơn giản, bạn
cần xây dựng bốn bức tường và nền nhà, lắp cửa ra vào, lắp một cặp cửa sổ và xây


dựng một mái nhà. Nhưng nếu bạn muốn một ngôi nhà lớn hơn, sáng sủa hơn, có sân
sau và các tiện ích khác (như hệ thống sưởi, hệ thống ống nước và hệ thống dây điện)?
Giải pháp đơn giản nhất là mở rộng lớp House và tạo một tập hợp các lớp con để
bao gồm tất cả các tổ hợp của các tham số. Nhưng cuối cùng bạn sẽ có một số lượng
đáng kể các lớp con. Bất kỳ thông số mới nào, chẳng hạn như kiểu hiên nhà, sẽ yêu
cầu phát triển hệ thống phân cấp này nhiều hơn nữa.

Có một cách tiếp cận khác khơng liên quan đến việc lai tạo các lớp con. Bạn có thể
tạo một phương thức constructor khổng lồ ngay trong lớp House với tất cả các tham
số có thể điều khiển object house. Mặc dù cách tiếp cận này thực sự loại bỏ sự cần
thiết của các lớp con, nhưng nó lại tạo ra một vấn đề khác.
Trong hầu hết các trường hợp, hầu hết các tham số sẽ không được sử dụng, làm
cho các lần gọi constructor khá rắc rối. Ví dụ, chỉ một phần nhỏ các ngơi nhà có bể
bơi, vì vậy các thông số liên quan đến bể bơi sẽ vô dụng với các trường hợp khác.

1.3 Giải pháp


Pattern sắp xếp việc xây dựng object thành một tập hợp các bước (buildWalls,
buildDoor, v.v.). Để tạo một object, bạn thực hiện một loạt các bước này trên một

builder object. Phần quan trọng là bạn không cần phải gọi tất cả các bước. Bạn chỉ
có thể gọi những bước cần thiết để tạo ra một cấu hình cụ thể của một object.

Một số bước construction có thể yêu cầu thực hiện khác nhau khi bạn cần xây
dựng các thể hiện đại diện khác nhau của sản phẩm (build various representations
of the product). Ví dụ, các bức tường của một cabin có thể được xây dựng bằng gỗ,
nhưng các bức tường của lâu đài phải được xây dựng bằng đá.

Trong trường hợp này, bạn có thể tạo một số class builder khác nhau triển khai
cùng một tập hợp các bước xây dựng, nhưng theo một cách khác. Sau đó, bạn có
thể sử dụng các builder này trong quá trình xây dựng (tức là một tập hợp các lệnh
gọi có thứ tự đến các bước xây dựng) để tạo ra các loại object khác nhau.


Ví dụ, một người thợ xây dựng mọi thứ từ gỗ và kính, người thứ hai xây dựng
mọi thứ bằng đá và sắt và người thứ ba sử dụng vàng và kim cương.

Bằng cách gọi cùng một nhóm các bước, bạn sẽ có được một ngơi nhà bình
thường từ người xây dựng đầu tiên, một lâu đài nhỏ từ người thứ hai và một cung
điện từ người thứ ba.

Tuy nhiên, điều này sẽ chỉ hoạt động nếu client code gọi các bước xây dựng có
thể tương tác với các builder bằng giao diện chung.


Bạn có thể đi xa hơn và trích xuất một loạt lệnh gọi đến các bước của builder
mà bạn sử dụng để xây dựng một sản phẩm thành một lớp riêng biệt có tên là
director.
Lớp Director xác định thứ tự thực hiện các bước xây dựng, trong khi trình xây
dựng cung cấp việc triển khai cho các bước đó.

Việc có một lớp director trong chương trình của bạn là khơng hồn tồn cần
thiết. Bạn ln có thể gọi các bước xây dựng theo thứ tự cụ thể trực tiếp từ client
code. Tuy nhiên, lớp director có thể là một nơi tốt để đưa các quy trình xây dựng
khác nhau để bạn có thể sử dụng lại chúng trong chương trình của mình.

Ngồi ra, lớp director hồn tồn ẩn các product construction với client code.
Client chỉ cần liên kết builder với director, khởi chạy construction với director và
nhận kết quả từ builder.

2.Cấu trúc


Các thành phần trong mơ hình:


Builder: Giao diện Builder khai báo các bước product construction chung cho
tất cả các loại builder. Abstract interface để tạo nên các đối tượng sản phẩm
( object product )



Concrete Builder: cung cấp các cách triển khai khác nhau của các bước
construction cho Builder. Các concrete builder có thể tạo ra các product khơng
tn theo giao diện chung.



ConcreBuilder: là một object có thể xây dựng nên các object khác. Xây dựng
và lắp ráp các phần để xây dựng object.



Products: là các đối tượng kết quả. Các product do các builder khác nhau tạo
ra không nhất thiết phải thuộc cùng một hệ thống phân cấp hoặc giao diện lớp.



Director: Lớp Director xác định thứ tự gọi các bước construction, vì vậy bạn
có thể tạo và sử dụng lại các cấu hình cụ thể của product.




Client: Client phải liên kết một trong các đối tượng trình tạo với director.
Thơng thường, nó chỉ được thực hiện một lần, thông qua các tham số của hàm
tạo của director. Sau đó, director sử dụng builder object đó cho tất cả các
construction tiếp theo.

3. Ưu điểm
- Có thể xây dựng các đối tượng theo từng bước, trì hỗ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 sốt các bước của quy trình construction.

4.Nhược điểm