BTL Design Patterns

Design pattern là một kỹ thuật dành cho lập trình hướng đối tượng. Nó cung cấp cho ta cách tư duy trong từng tình huống của việc lập trình hướng đối tượng, và phân tích thiết kế hệ thống phần mềm. Nó cần thiết cho cả các nhà lập trình và nhà phân tích thiết kế. Đối với những người chuyên về lập trình thì việc nắm vững công cụ lập trình thôi chưa đủ,họ cần phải có một tư duy, một kỹ năng giải quyết các tình huống nhỏ của công việc xây dựng phần mềm mà họ là người thi hành. Việc giải quyết này phải đảm bảo tính ổn định là họ có thể giải quyết được trong mọi tình huống, với thời gian đúng tiến độ, phương pháp giải quyết hợp lý và đặc biệt là phải theo một chuẩn nhất định. Những nhà phân tích thiết kế mức cao, việc nắm vững công cụ lập trình có thể là không cần thiết, nhưng họ cũng cần phải biết được ở những khâu nhỏ nhất chi tiết nhất của thiết kế của họ đưa ra có thể thực hiện được hay không và nếu thực hiện được thì có thể thực hiện như thế nào, và sẽ theo một chuẩn ra sao.

BỘ CÔNG THƯƠNG TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

- -

-BÀI TẬP LỚN

Môn : Design Patterns.

Giáo viên hướng dẫn : Nhóm sinh viên thực hiện : Lớp: ĐH KTPM CLC K9

Hà Nội, tháng 11 năm 2016

Mục lục

Lời nói đầu 1

Phần I: Tổng quan về Design pattern 2

I Vấn đề trong thiết kế phần mềm hướng đối tượng 2

II Lịch sử design pattern 2

III Design pattern là gì ? 3

Phần II: Hệ thống các mẫu design pattern 5

I Hệ thống các mẫu 5

1 Nhóm Creational 5

2 Nhóm Structural 5

3 Nhóm Behavioral 5

II Sưu liệu chuẩn của mẫu 6

III Quy tắc biểu diễn mẫu trong UML 6

Phần III: Nội dung các mẫu Design pattern 8

I Nhóm Creational 8

1 Abstract Factory 8

2 Factory Method 12

3 Builder 18

4 Prototype 26

5 Singleton 28

II Nhóm Structural 33

1 Adapter 33

2 Bridge 39

3 Composite 43

4 Decorator 48

5 Façade 52

6 Proxy 56

7 Flyweight 60

III Nhóm Behavioral 66

1 Interpreter 66

2 Template Method 73

3 Chain of Responsibility 78

4 Command 84

6 Mediator 92

7 Memento 96

8 Observer 99

9 State 104

10 Strategy 109

11 Visitor 112

Bảng phân công thực hiện của nhóm: 118

Lời nói đầu

Design pattern là một kỹ thuật dành cho lập trình hướng đối tượng Nó cung cấp cho tacách tư duy trong từng tình huống của việc lập trình hướng đối tượng, và phân tích thiết

kế hệ thống phần mềm Nó cần thiết cho cả các nhà lập trình và nhà phân tích thiết kế.Đối với những người chuyên về lập trình thì việc nắm vững công cụ lập trình thôi chưađủ,họ cần phải có một tư duy, một kỹ năng giải quyết các tình huống nhỏ của công việcxây dựng phần mềm mà họ là người thi hành Việc giải quyết này phải đảm bảo tính ổnđịnh là họ có thể giải quyết được trong mọi tình huống, với thời gian đúng tiến độ,phương pháp giải quyết hợp lý và đặc biệt là phải theo một chuẩn nhất định Những nhàphân tích thiết kế mức cao, việc nắm vững công cụ lập trình có thể là không cần thiết,nhưng họ cũng cần phải biết được ở những khâu nhỏ nhất chi tiết nhất của thiết kế của họđưa ra có thể thực hiện được hay không và nếu thực hiện được thì có thể thực hiện nhưthế nào, và sẽ theo một chuẩn ra sao

Design pattern được dùng khắp ở mọi nơi, trong các phần mềm hướng đối tượng các hệthống lớn Trong các chương trình trò chơi, Và cả trong các hệ thống tính toán songsong,

Design pattern thể hiện tính kinh nghiệm của công việc lập trình, xây dựng và thiết kếphần mềm Có thể chúng ta đã gặp design pattern ở đâu đó, trong các ứng dụng, cũng cóthể chúng ta đã từng sử dụng những mẫu tương tự như design pattern để giải quyết nhữngtình huống của mình, nhưng chúng ta không có một khái niệm gì về nó cả Trong nộidung báo cáo môn học này chúng em xin trình bày những hiểu biết của mình về Designpattern theo hướng tiếp cận mang tính kinh nghiệm Việc cài đặt các mẫu được trình bàytrên một tài liệu đi kèm

Trong quá trình làm bài không tránh khỏi được sai sót, rất mong được sự phản hồi vàgóp ý của quý thầy cô và các bạn Chúng em xin chân thành cảm ơn!

Các tài liệu tham khảo

 Design Patterns, Elements of Reusable Object Oriented Software của nhóm cáctác giả Gang of Four ( Erich Gamma, Richard Helm, Ralph Johnson và JohnVlissides)

 Các trang web trực tuyến http://laptrinh.vn và https://www.tutorialspoint.com

Phần I: Tổng quan về Design pattern.

Người ta nói rằng, việc thiết kế một phần mềm hướng đối tượng là một công việc khó,

và việc thiết kế một một phần mềm hướng đối tượng phục vụ cho mục đích dùng lại cònkhó hơn Chúng ta phải tìm ra những đối tượng phù hợp, đại diện cho một lớp các đốitượng Sau đó thiết kế giao diện và cây kế thừa cho chúng, thiết lập mối quan hệ giữachúng Thiết kế của chúng ta phải đảm bảo là giải quyết được các vấn đề hiện tại, có thểtiến hành mở rộng trong tương lai mà tránh phải thiết kế lại phần mềm Và một tiêu tríquan trọng là phải nhỏ gọn Việc thiết kế một phần mềm hướng đối tượng phục vụ chomục đích dùng lại là một công việc khó, phức tạp vì vậy chúng ta không thể mong chờthiết kế của mình sẽ là đúng, và đảm bảo các tiêu trí trên ngay được Thực tế là nó cầnphải được thử nghiệm sau vài lần và sau đó nó sẽ được sửa chữa lại Đứng trước một vấn

đề, một người phân tích thiết kế tốt có thể đưa ra nhiều phương án giải quyết, anh ta phảiduyệt qua tất cả các phương án và rồi chọn ra cho mình một phương án tốt nhất Phương

án tốt nhất này sẽ được anh ta dùng đi dùng lại nhiều lần, và dùng mỗi khi gặp vấn đềtương tự Mà trong phân tích thiết kế phần mềm hướng đối tượng ta luôn gặp lại nhữngvấn đề tương tự như nhau

Ý tưởng dùng mẫu xuất phát từ ngành kiến trúc, Alexander, Ishikawa, Silverstein,Jacobson, Fiksdahl-King và Angel (1977) lần đầu tiên đưa ra ý tưởng dùng các mẫu chuẩntrong thiết kế xây dựng và truyền thông Họ đã xác định và lập sưu liệu các mẫu có liênquan để có thể dùng để giải quyết các vấn đề thường xảy ra trong thiết kế các cao ốc Mỗimẫu này là một cách thiết kế, chúng đã được phát triển hàng trăm năm như là các giảipháp cho các vấn đề mà người ta làm trong lĩnh vực xây dựng thường gặp Các giải pháptốt nhất có được ngày hôm nay là qua một quá trình sàng lọc tự nhiên Mặc dù nghànhcông nghệ phần mềm không có lịch sử phát triển lâu dài như nghành kiến trúc, xây dựngnhưng Công nghệ phần mềm là một nghành công nghiệp tiên tiến, tiếp thu tất cả những gìtốt đẹp nhất từ các nghành khác Mẫu được xem là giải pháp tốt để giải quyết vấn đề xâydựng hệ thống phần mềm

Suốt những năm đầu 1990,thiết kế mẫu được thảo luận ở các hội thảo workshop, sau đóngười ta nổ lực để đưa ra danh sách các mẫu và lập sưu liệu về chúng Những người thamgia bị dồn vào việc cần thiết phải cung cấp một số kiểu cấu trúc ở một mức quan niệm caohơn đối tượng và lớp để cấu trúc này có thể được dùng để tổ chức các lớp Đây là kết quả

mang lại những cải tiến đáng kể đối với chất lượng cũng như hiệu quả của công việc pháttriển phần mềm Mẫu được xem là cách tổ chức việc phát triển hướng đối tượng, cáchđóng gói các kinh nghiệm của những ngưòi đi trước và rất hiệu quả trong thực hành.Năm 1994 tại hội nghị PLoP( Pattern Language of Programming Design) đã được tổchức Cũng trong năm này quyển sách Design patterns : Elements of Reusable ObjectOriented Software (Gamma, Johnson,Helm và Vhissdes,1995) đã được xuất bản đúng vàothời điểm diễn ra hội nghị OOPSLA’94 Đây là một tài liệu còn phôi thai trong việc làmnỗi bật ảnh hưởng của mẫu đối với việc phát triển phần mềm, sự đóng

góp của nó là xây dựng các mẫu thành các danh mục (catalogue) với định dạng chuẩnđược dùng làm tài liệu cho mỗi mẫu và nổi tiếng với tên Gang of Four (bộ tứ), và các mẫu

nó thường được gọi là các mẫu Gang of Four Còn rất nhiều các cuốn sách khác xuất hiệntrong 2 năm sau, và các định dạng chuẩn khác được đưa ra

Năm 2000 Evitts có tổng kết về cách các mẫu xâm nhập vào thế giới phần mềm (sáchcủa ông lúc bấy giờ chỉ nói về những mẫu có thể được sử dụng trong UML chứ chưa đưa

ra khái niệm những mẫu thiết kế một cách tổng quát) Ông công nhận Kent Beck và WardCunningham là những người phát triển những mẫu đầu tiên với SmallTalk trong công việccủa họ được báo cáo tại hội nghị OOPSLA’87 Có 5 mẫu mà Kent Beck và WardCunningham đã tìm ra trong việc kết hợp các người dùng của một hệ thống mà họ đangthiết kế Năm mẫu này đều được áp dụng để thiết kế giao diện người dùng trong môitrường Windows

Design patterns là tập các giải pháp cho cho vấn đề phổ biến trong thiết kế các hệthống máy tính Đây là tập các giải pháp đã được công nhận là tài liệu có giá trị, nhữngngười phát triển có thể áp dụng giải pháp này để giải quyết các vấn đề tương tự Giốngnhư với các yêu cầu của thiết kế và phân tích hướng đối tượng (nhằm đạt được khả năng

sử dụng các thành phần và thư viện lớp), việc sử dụng các mẫu cũng cần phải đạt đượckhả năng tái sử dụng các giải pháp chuẩn đối với vấn đề thường xuyên xảy ra

Christopher Alexander nói rằng : “Mỗi một mẫu mô tả một vấn đề xảy ra lặp đi lặp lạitrong môi trường và mô tả cái cốt lõi của giải pháp để cho vấn đề đó.Bằng cách nào đóbạn đã dùng nó cả triệu lần mà không làm giống nhau 2 lần”

Mối quan hệ giữa các Pattern

Design pattern không phải là một phần của UML cốt lõi, nhưng nó lại đựơc sử dụngrộng rãi trong thiết kế hệ thống hướng đối tượng và UML cung cấp các cơ chế biểu diễnmẫu dưới dạng đồ hoạ.

Phần II: Hệ thống các mẫu design pattern.

Hệ thống các mẫu design pattern hiện có 23 mẫu được định nghĩa trong cuốn “Designpatterns Elements of Reusable Object Oriented Software” Hệ thống các mẫu này có thểnói là đủ và tối ưu cho việc giải quyết hết các vấn đề của bài toán phân tích thiết kế vàxây dựng phần mềm trong thời điểm hiện tại Hệ thống các mẫu design pattern được chiathành 3 nhóm: Creational, nhóm Structural, nhóm behavioral

1 Nhóm Creational

Gồm có 5 pattern: AbstractFactory, Abstract Method, Builder, Prototype, và Singleton.Nhóm này liên quan tới việc tạo ra các thể nghiệm (instance) của đối tượng, tách biệt vớicách được thực hiện từ ứng dụng Muốn xem xét thông tin của các mẫu trong nhóm nàythì phải dựa vào biểu đồ nào phụ thuộc vào chính mẫu đó, mẫu thiên về hành vi hay cấutrúc

2 Nhóm Structural

Gồm có 7 mẫu : Adapter, Bridge, Composite, Decorator, Facade, Proxy, và Flyweight.Nhóm này liên quan tới các quan hệ cấu trúc giữa các thể nghiệm, dùng kế thừa, kết tập,tương tác Để xem thông tin về mẫu này phải dựa vào biểu đồ lớp của mẫu

3 Nhóm Behavioral

Gồm có 11 mẫu : Interpreter,Template Method,Chain of Responsibility,Command,Iterator,Mediator,Memento,Observer,State,Strategy và Visitor.Nhóm này liên quan đếncác quan hệ gán trách nhiệm để cung cấp các chức năng giữa các đối tượng trong hệthống Đối với các mẫu thuộc nhóm này ta có thể dựa vào biểu đồ cộng tác và biểu đồdiễn tiến Biểu đồ cộng tác và biểu đồ diễn tiến sẽ giải thích cho ta cách chuyển giao củacác chức năng

II.Sưu liệu chuẩn của mẫu

Mẫu được phân loại thành 2 nhóm Pattern catalogue (danh mục mẫu) và patternlanguage (ngôn ngữ mẫu) Một pattern catalogue là một nhóm mẫu có quan hệ với nhau

có thể được sử dụng cùng nhau hoặc độc lập Một pattern language sẽ lập sưu liệu mẫucho các mẫu làm cùng nhau và có thể được áp dụng để giải quyết các vấn đề trong mộtlĩnh vực nào đó.Các mẫu được lập sưu liệu bằng cách dùng các template, các templatecung cấp các heading bên dưới có chứa chi tiết của mẫu và cách thức nó làm việc chophép người dùng biết mẫu dó có thích hợp với vấn đề của họ hay không, nếu có thì ápdụng mẫu này để giải quyết vấn đề Có 4 loại template khác nhau, hai trong số đó thườngđược sử dụng nhất là Coplien và Gamma.Các heading được liệt kê dưới đây là templatecủa Coplien

 Name – Tên của mẫu, mô tả ý tưởng, giải pháp theo một số cách

 Problem - Vấn đề mà mẫu giúp giải quyết

 Context - Ngữ cảnh ứng dụng của mẫu (kiến trúc hoặc nghiệp vụ) và các yếu tốchính đề mẫu làm việc thành công trong một tình huống nào đó

 Force – Các ràng buộc hoặc các vấn đề phải được giải quyết bởi mẫu; chúng tạo ra

sự mất cân đối, mẫu sẽ giúp ta cân đối

 Solution - Giải pháp để cân đối các ràng buộc xung đột và làm cho hợp với ngữcảnh của chúng

 Sketch - Bản phác thảo tượng trưng của các ràng buộc và cách giải quyết

 Resulting context - Ngữ cảnh sau khi thay đổi giải pháp

 Rationale - Lý do và động cơ cho mẫu

Sưu liệu có thể gồm mã và các biểu đồ tiêu biểu Các biểu đồ UML có thể được dùng

để minh hoạ cho cách làm việc của từng mẫu Việc lựa chọn kiểu biểu đồ phụ thuộc vàobản chất của mẫu

Một trong những mục tiêu của UML là hỗ trợ các khái niệm ở cấp cao, như thànhphần, cộng tác, framework và mẫu Việc hỗ trợ này được thực hiện bằng cách cung cấpmột cơ chế nhằm định nghĩa rõ ràng ngữ nghĩa của chúng, từ đó việc sử dụng các kháiniệm đựơc dễ dàng hơn nhằm đạt được khả năng tái sử dụng mà các phương pháp hướngđối tượng yêu cầu Khía cạnh thuộc cấu trúc của mẫu được biểu diễn trong UML bằngcách dùng các cộng tác mẫu

Cộng tác mẫu được biểu diễn bằng một hình Ellipse nét đứt và một hình chữ nhật nétđứt nằm chồng lên phần cung phía trên bên phải của nó như sau:

Ký hiệu cho mẫu cộng tác Các vai trò liên quan trong mẫu Facade

Collaboration name

Role name 1Role name 2

ade

Facade

Subsystem class

Phần III: Nội dung các mẫu Design pattern

1.2 Cấu trúc

o Sơ đồ UML

- AbstractProduct: AnCo, AnThit

- Product: DeNui, BoBison (cài đặt theo lớp AnCo); SuTu,

Soi (cài đặt theo lớp AnThit)

- Client: Main(TheGioiDongVat) sử dụng các lớp được khai

báo bởi các lớp DongVat và AnThit, AnCo

o Code

 Output

2 Factory Method

2.1 V ấn đề đặt ra

Các Framework thường sử dụng các lớp trừu tượng để định nghĩa và duy trì mối quan

hệ giữa các đối tượng.Một framework thường đảm nhiệm việc tạo ra các đối tượng hoànchỉnh Việc xây dựng một framework cho ứng dụng mà có thể đại diện cho nhiều đốitượng tài liệu cho người dùng Có 2 loại lớp trừu tượng chủ chốt trong framework này làlớp ứng dụng và tài liệu Cả 2 lớp đều là lớp trừu tượng, và trình khách phải xây dựng cácdẫn xuất, các lớp con để hiện thực hoá, tạo ra đối tượng phù hợp với yêu cầu của ứngdụng Chẳng hạn để tạo ra một ứng dụng drawing, chúng ta định nghĩa một lớpDrawingApplication và một lớp DrawingDocument Lớp ứng dụng chịu trách nhiệm quản

lý tài liệu và chúng ta sẽ tạo ra chúng khi có nhu cầu ( chẳng hạn khi người dùng chọnOpen hoặc New từ menu)

Bởi vì một lớp Document cá biệt như thế này được tạo ra từ các dẫn xuất của lớpAbstractDocument (trong framework) để đưa ra các thể nghiệm cho một ứng dụngDrawing, lớp ứng dụng không thể biết trước được lớp dẫn xuất của AbstractDocumentnào sẽ được tạo ra để trình bày, mà nó chỉ biết khi nào một đối tượng tài liệu nào nênđược tạo chứ không biết loại đối tượng tài liệu nào để tạo Điều này tạo ra một sự tiếnthoái lưỡng nan: framework phải thể nghiệm một lớp, nhưng nó chỉ biết về lớp trừu tượngcủa nó, mà lớp trừu tượng này lại không thể thể nghiệm trực tiếp được.Nếu ai từng làmviệc với giao diện ứng dụng đơn tài liệu và đa tài liệu trong ngôn ngữ Visual C++, chúng

ta cũng sẽ bắt gặp một vấn đề tương tự Đối tượng MainFrame có thể tạo ra một dối tượngview mỗi khi người dùng nhấn chuột vào menu View hay Open, nhưng MainFrame hoàntoàn không hề biết một chút thông tin nào trước đó về View vì nó không chứa bất cứ mộtthể nghiệm nào của View

Mẫu Abstract Method đưa ra một giải pháp cho vấn đề này.Nó đóng gói thông tin vềlớp dẫn xuất Document nào được tạo và đưa ra ngoài framework

Lớp dẫn xuất ứng dụng định nghĩa lại một phương thức trừu tượng CreateDocument()trên lớp Application để trả về một đối tượng thuộc lớp dẫn xuất của lớp document

Khi một đối tượng thuộc lớp dẫn xuất của Application được tạo ra, nó có thể tạo

ra luôn các đối tượng tài liệu đặc biệt cho ứng dụng mà không cần biết về các lớpđó.Chúng ta gọi CreateDocument là một factory method bởi vì nhiệm vụ của nó là sảnxuất ra các đối tượng

2.2 Định nghĩa

Factory Method là một giao diện cho việc tạo ra một đối tượng, nhưng để cho lớp dẫnxuất quyết định lớp nào sẽ được tạo.Factory method để cho một lớp trì hoãn sự thểnghiệm một lớp con

- Khai báo Factory Method mà trả về một đối tượng của kiểu Product Sự kiến tạonày cũng có thể định nghĩa một cài đặt mặc định của Factory Method trả về mộtđối tượng ConcreteProduct mặc định.

- Có thể gọi Factory Method để tạo ra một đối tượng Product

 ConcreteCreator

- Chồng lên Factory Method để trả về một thể nghiệm của một ConcreteProduct

2.4 Sử dụng Factory Method khi nào?

Factory Method cho phép client sử dụng một interface cho việc tạo ra một đối tượngtrong khi vẫn duy trì kiểm soát Mục tiêu chính của fatory Method là khả năng mở rộng.Factory Method thường được sử dụng trong các ứng dụng để quản lý, bảo trì và tính toánnhững tập hợp các đối tượng khác nhau nhưng có những thuộc tính tương tự nhau trongcùng một thời điểm Chẳng hạn, một hệ quản trị tài liệu có khả năng mở rộng hơn nếu bạntham chiếu các tài liệu của bạn như một tập hợp các IDocument Những tài liệu này có thể

là các tập tin Text, các tài liệu Word, các lược đồ Visio… Nhưng chúng lại có một tác giả,một tựa đề, một kiểu, một kích cỡ, một nơi lưu trữ… Khi một loại tài liệu mới đưa ra, đơngiản nó thực thi IDocument interface và nó sẽ phù hợp với phần còn lại của các tài liệu

Để hỗ trợ loại tài liệu mới này, Factory Method có thể phải hoặc không phải điều chỉnh lại(phù thuộc vào cách nó được thực thi, và có hoặc không có tham số)

Factory Method thường được sử dụng trong những thành phần “quản lý”, chẳng hạnnhư document manager, account manager, permission manager…

Trong những chương trình của bạn, bạn hầu như tạo ra các phương thức trả về các đốitượng mới Tuy nhiên, không phải tất cả các phương thức trả về đối tượng mới là FactoryMethod Vậy khi nào bạn biết được Fatory Method hoạt động? Quy tắc là:

- Phương thức tạo ra đối tượng mới

- Phương thức trả về một lớp trừu tượng hoặc interface

- Lớp trừu tượng hoặc interface được thực thi bởi một số lớp

2.5 Code và ví dụ

Chúng ta sẽ tạo ra một giao diện Shape và các lớp thực hiện các giao diện Shape Một lớp nhà máy ShapeFactory được định nghĩa như là một bước tiếp theo.

FactoryPatternDemo , lớp demo sẽ sử dụng ShapeFactory để có được một đối tượng Shape Nó sẽ chuyển thông tin ( CIRCLE / RECTANGLE / SQUARE) để ShapeFactory để

có được các loại đối tượng cần thiết

o Sơ đồ lớp UML

o Code

1) Tạo một giao diện Shape

2) Tạo các lớp thực hiện giao diện Shape

3) Tạo lớp ShapeFactory

4) Tạo lớp FactoryPatternDemo

5) Output

2.6 Mẫu liên quan

Abstract Factory thường được cài đặt cùng với Factory Method Lớp FactoryMethod thường được gọi là Template Method Trong ví dụ về ứng dụng Drawingtrên,NewDocument là một template method

Prototype không cần đến một lớp con Creator, tuy nhiên thường đòi hỏi mộtphương thức để tạo thể nghiệm trên lớp dẫn xuất

3 Builder

3.1 Vấn đề đặt ra

Trong những ứng dụng lớn, với nhiều các chức năng phức tạp và mô hình giao diện đồ

sộ Chúng ta không thể dồn tất cả công việc khởi tạo này cho một hàm khởi tạo Vì nhưthế sẽ rất khó kiểm soát hết, và hơn nữa không phải lúc nào các thành phần của ứng dụngcũng được khởi tạo một cách đồng bộ Có thành phần được tạo ra vào lúc dịch chươngtrình nhưng cũng có thành phần tuỳ theo từng yêu cầu của người dùng, tuỳ vào hoàn cảnhcủa ứng dụng, mà nó sẽ được tạo ra Như vậy việc khởi tạo ứng dụng thường gặp nhiềukhó khăn

3.2 Giải pháp

Để giải quyết vấn đề trên, người ta giao công việc này cho một đối tượng chịu tráchnhiêm khởi tạo, và chia việc khởi tạo ứng dụng riêng rẽ, để có thể tiến hành khởi tạo riêngbiệt ở các hoàn cảnh khác nhau Hãy tưởng tượng việc tạo ra đối tượng của ta giống nhưnhư việc chúng ta tạo ra chiếc xe đạp Đầu tiên ta tạo ra khung xe, sau đó tạo ra bánh xe,chúng ta tạo ra buđông xe, xích, líp,… Việc tạo ra các bộ phận này không nhất thiết phảiđựơc thực hiện một cách đồng thời hay theo một trật tự nào cả, và nó có thể được tạo ramột cách độc lập bởi nhiều người Nhưng trong một mô hình sản xuất như vậy, bao giờviệc tạo ra chiếc xe cũng được khép kín để tạo ra chiếc xe hoàn chỉnh, đó là nhà máy sảnxuất xe đạp.Ta gọi đối tượng nhà máy sản xuất xe đạp này là builder ( người xây dựng)

3.3 Định nghĩa

Builder là mẫu thiết kế hướng đối tượng được tạo ra để chia một công việc khởi tạo phứctạp của một đối tượng ra riêng rẽ từ đó có thể tiến hành khởi tạo đối tượng ở các hoàncảnh khác nhau Builder Pattern 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 Đây là loại design pattern thuộccreational pattern, mô hình này cung cấp một trong những cách tốt nhất để tạo ra một đốitượng

3.4 Cấu trúc

- Xác định và theo dõi của các đại diện nó tạo ra

- Cung cấp một giao diện để lấy các sản phẩm

- Bao gồm các lớp học để xác định các bộ phận cấu thành, bao gồm cả giaodiện để lắp ráp các bộ phận thành kết quả cuối cùng

3.5 Sử dụng Builder pattern khi nào?

Một lập trình viên muốn sử dụng Builder pattern khi:

 Anh ấy muốn thay đổi thiết kế cho việc lồng nhau của các hàm khởi tạo(Telescoping Constructor Pattern) Vấn đề này phát sinh khi lập trình viên làmviệc với một lớp mà có chứa rất nhiều các thuộc tính và cần phải tạo ra nhiềuhàm khởi tạo với số lượng các thuộc tính tăng dần

 Anh ấy cần tạo ra một đối tượng phức tạp, một đối tượng mà thuật toán để tạotạo lập các thuộc tính là độc lập đối với các thuộc tính khác

3.6 Ví dụ và code

Chúng ta xem xét một trường hợp kinh doanh của nhà hàng thức ăn nhanh, nơi mộtbữa ăn điển hình có thể là một burger và một thức uống lạnh Burger có thể hoặc là một

Burger chay (Veg Burger) hay Burger gà (Chicken Burger) và sẽ được đóng gói bằng một

Wrapper Đồ uống lạnh có thể là một cốc (Coke) hoặc Pepsi và sẽ được đóng gói trong

một chai (Bottle).

Chúng ta sẽ tạo ra một giao diện đại diện cho các mặt hàng thực phẩm như burgers và

đồ uống lạnh (Item) cùng các lớp thực hiện giao diện đó và một giao diện đại diện cho bao bì của các mặt hàng thực phẩm (Packing) và các lớp thực hiện các giao diện như

Burger sẽ được đóng gói trong bao bọc và thức uống lạnh sẽ được đóng gói bằng chai

Sau đó chúng ta tạo ra một lớp bữa ăn Meal có một danh sách các mặt hàng Item và một lớp MealBuilder để xây dựng các loại khác nhau của đối tượng bữa ăn bằng cách kết hợp các Item Lớp demo BuilderPatternDemo của chúng tôi sẽ sử dụng MealBuilder để xây dựng một bữa ăn Meal.

o Sơ đồ lớp UML

o Code

1) Tạo interface Item và Packing

2) Tạo các lớp Wrapper và Bottle kế thừa Packing interface

3) Tạo các lớp trừu tượng kế thừa Item interface với các chức năng mặc định

4) Tạo các lớp kế thừa Burger và ColdDrink

5) Tạo lớp Meal chứa danh sách các Item

6) Tạo một lớp MealBuilder, lớp xây dựng thực tế có trách nhiệm để tạo các đối

tượng Meal

7) BuiderPatternDemo sử dụng MealBuider để chứng minh mô hình xây dựng

8) Xác minh đầu ra

3.7 Các mẫu liên quan

Builder thường được cài đặt cùng với các mẫu như Abstract Factory Tầm quan trọngcủa Abstract Factory là tạo ra một dòng các đối tượng dẫn xuất (cả đơn giản và phức tạp).Ngoài ra Builder còn thường được cài đặt kèm với Composite pattern Compositepattern thường là những gì mà Builder tạo ra

4.5 Dùng Prototype pattern khi nào?

 Khởi tạo object mới bằng cách thay đổi một vài thuộc tính 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

4.6 Ví dụ

o Sơ đồ lớp UML

4.7 Mẫu liên quan

Prototype và Abstract Factory liên quan đến nhau chặt chẽ, có thể đối chọi nhau theonhiều kiểu.Tuy nhiên chúng cũng có thể kết hợp cùng nhau.Một Abstract Factory có thểchứa một tập các Prototype vô tính và trả về các đối tượng sản xuất

5 Singleton

5.1 Vấn đề và giải pháp

Ta hãy xem xét về một đối tượng quản lý tài nguyên trong các ứng dụng Mỗi ứngdụng có một bộ quản lý tài nguyên, nó cung cấp các điểm truy cập cho các đối tượng kháctrong ứng dụng Các đối tượng (ta gọi là đối tượng khách) có thể thực hiện lấy ra từ bộquản lý tài nguyên những gì chúng cần và thay đổi giá trị nằm bên trong bộ quản lý tàinguyên đó Để truy cập vào bộ quản lý tài nguyên đối tượng khách cần phải có một thểnghiệm của bộ quản lý tài nguyên, như vậy trong một ứng dụng sẽ có rất nhiều thểnghiệm của bộ quản lý tài nguyên được tạo ra

Trong ví dụ trên hàm DoSomething() của ClientObject1 khi truy cập vào đối tượng thuộc lớp ResourceManager sẽ in ra màn hình X = 0 và đặt vào đó x = 100.

Sau đó hàm Dosomething() của ClientObject2 khi truy cập vào đối tượng thuộc lớp

ResourceManager sẽ in ra màn hình X = 0 và đặt vào đó x = 500 Rõ ràng là tài nguyên

mà các đối tượng khách truy cập vào không thể hiện sự thống nhất lẫn nhau Điều mà lẽ

ra khi giá trị x trong ResourceManager bị ClientObject1 thay đổi thì ClientObject2 phải

nhận biết được điều đó và in ra màn hình X=100 Nhưng theo logic cài đặt ở trên thì khi

đối tượng thuộc lớp ClientObject1 truy cập đến ResourceManager nó tạo ra một Instance

và đặt thuộc tính x = 100; Đối tượng ClientObject2 truy cập đến ResourceManager nó tạo

ra một Instance và đặt thuộc tính x = 500 Hai Instance này hoàn toàn độc lập nhau vềvùng nhớ do đó mà tài nguyên x mà nó quản lý cũng là 2 tài nguyên độc lập với nhau.Vấn

đề đặt ra là phải tạo ra một bộ quản lý tài nguyên hoàn hảo tạo ra mọi thể nghiệm giốngnhau tại nhiều nơi nhiều thời điểm khác nhau trong ứng dụng Singleton cung cấp cho tamột cách giải quyết vấn đề này

5.4 Ví dụ và code

o Sơ đồ lớp UML

o Code

1) Tạo lớp Toi

2) Tạo lớp main để chứng minh

5.5 Các mẫu liên quan

Có rất nhiều mẫu có thể cài đặt bổ sung từ việc sử dụng Singleton, chẳng hạn nhưAbstract Factory, Builder, và Prototype

Ta cần sử dụng một vài lớp con đã tồn tại, nhưng để làm cho các giao diện của chúngtương thích với nhau bằng việc phân lớp các giao diện đó là việc làm không thực tế.

1.2 Giải pháp

Để giải quyết vấn đề trên, ta dùng một đối tượng adapter để chuyển đổi giao diện thànhmột giao diện khác mà phù hợp với yêu cầu và kết nối các lớp có giao diện không tươngthích để làm việc với nhau

1.3 Định nghĩa

Mẫu Adapter là mẫu thiết kế dùng để thay đổi interface của một lớp thành mộtinterface khác phù hợp với yêu cầu người sử dụng lớp Giúp kết nối các lớp có giao diệnkhông tương thích để làm việc với nhau

1.4 Cấu trúc

o Sơ đồ lớp UML

o Các thành phần tham gia

 Target: Định nghĩa một miền giao diện đặc biệt mà Client sử dụng.

 Client: Cộng tác với các đối tượng tương thích với giao diện Target.

 Adaptee: Định nghĩa một giao diện đã tồn tại mà cần phải làm biến đổi cho

thích hợp

 Adapter: làm tương thích giao diện của Adaptee với giao diện của Target.

1.5 Sử dụng Adapter pattern khi nào?

- Khi ta muốn chuyển đổi một lớp với một giao diện thành giao diện mà tamong muốn

- Xậy dựng, mở rộng các phương thức của lớp có sẵn phù hợp với yêu cầu

- Tái sử dụng giao diện cũ Giảm thiểu việc viết lại mã lệnh

1.6 Ví dụ và code

Chúng ta xem xét một ví dụ sử dụng Adapter pattern như sau:

Chúng ta có một giao diện MediaPlayer và một lớp Audioplayer thực hiện giao diện

MediaPlayer, đối tượng audioplayer có thể chơi các định dạng mp3 file âm thanh theo

và sử dụng đối tượng AdvancedMediaPlayer để chơi các định dạng cần thiết.

Audioplayer sử dụng lớp adaptor MediaAdapter để chơi các định dạng mong muốn.

Lớp AdapterPatternDemo là lớp demo sẽ sử dụng Audioplayer để chơi các định dạng

khác nhau

o Sơ đồ lớp UML

o Code

1) Tạo giao diện Media Player và Advanced Media Player