đồ án 1 nghiên cứu và áp dụng design pattern trong phát triển phần mềm

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.89 MB, 77 trang )

<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

<b>ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINHTRƯỜNG ĐẠI HỌC CƠNG NGHỆ THƠNG TIN</b>

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

<b>ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINHTRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN</b>

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

Bên cạnh đó, chúng em xin cảm ơn các bạn bè trong lớp đã động viên, thảo luận vàgóp ý cho em đồng thời đã khơi thêm nguồn động lực cho em trong suốt q trìnhđầy khó khăn.

Mặc dù đã cố gắng hoàn thành báo cáo với tất cả nỗ lực song báo cáo của em chắcchắn không tránh khỏi những thiếu sót, em rất mong nhận được sự thơng cảm vàgóp ý chân thành từ thầy. Em xin chân thành cảm ơn.

<i><b>Thành phố Hồ Chí Minh, tháng 6 năm 2023</b></i>

Nguyễn Thúc BảoNguyễn Bùi Đức Kiên

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

GIỚI THIỆU... 9

Chương 1. KIẾN THỨC NỀN TẢNG...10

1.1. Lịch sử phát triển của phát triển phần mềm... 10

1.2. Phát triển phần mềm hướng đối tượng... 10

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

Chương 2. CÁC PHƯƠNG PHÁP ĐO LƯỜNG ĐỘ PHỨC TẠP... 56

2.1. Depth of Inherit Tree - DIT... 57

2.2. Number of Children - NOC... 58

2.3. Coupling Between Object - CBO... 58

Chương 3. ĐÁNH GIÁ ĐỘ PHỨC TẠP...59

Chương 4. GIẢI PHÁP CHUNG...62

4.1. Tổng quan... 62

4.2. Chi tiết... 63

4.2.1. Phân tích cú pháp (Parse Code)... 63

4.2.2. Tính tốn các thơng số (Extract Information)...67

4.2.3. Huấn luyện mơ hình (train-test model)... 68

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

[Hình 1] Sơ đồ cấu trúc Abstract Factory... 14

[Hình 2] Sơ đồ cấu trúc Factory...16

[Hình 3] Sơ đồ cấu trúc Builder... 18

[Hình 4] Sơ đồ cấu trúc Prototype... 19

[Hình 5] Sơ đồ cấu trúc Singleton...21

[Hình 6] Sơ đồ cấu trúc Adapter... 22

[Hình 7] Sơ đồ cấu trúc Bridge... 24

[Hình 8] Sơ đồ cấu trúc Composite...26

[Hình 9] Sơ đồ cấu trúc Decorator... 28

[Hình 10] Sơ đồ cấu trúc Facade...29

[Hình 11] Sơ đồ cấu trúc Flyweight...31

[Hình 12] Sơ đồ cấu trúc Proxy... 33

[Hình 13] Sơ đồ cấu trúc Chain of Responsibility... 35

[Hình 14] Mã nguồn lớp “Client" trong Chain of Responsibility...36

[Hình 15] Sơ đồ cấu trúc Command... 38

[Hình 16] Sơ đồ cấu trúc Interpreter... 40

[Hình 17] Sơ đồ cấu trúc Iterator... 42

[Hình 18] Sơ đồ cấu trúc Mediator... 44

[Hình 19] Sơ đồ cấu trúc Memento...46

[Hình 20] Sơ đồ cấu trúc Observer... 48

[Hình 21] Sơ đồ cấu trúc State... 50

[Hình 22] Sơ đồ cấu trúc Strategy...52

[Hình 23] Sơ đồ cấu trúc Template... 54

[Hình 24] Sơ đồ cấu trúc Visitor... 56

[Hình 25] Sơ đồ mẫu biểu diễn các kế thừa và phụ thuộc các lớp...57

[Hình 26] Cây phân tích - Parsed tree...64

[Hình 27] Sơ đồ cấu trúc Prototype... 65

[Hình 28] Sơ đồ mạng neural với 2 lớp ẩn...69

[Hình 29] Màn hình upload...73

[Hình 29] Màn hình kết quả... 74

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

[Bảng 1] Bảng thống kê các giá trị của dự án sử dụng prototype... 59

[Bảng 2] Bảng thống kê các giá trị trung bình của mẫu Prototype... 59

[Bảng 3] Bảng thống kê các giá trị trung bình của 23 mẫu thiết kế...61

[Bảng 4] Bảng thống kê các giá trị của dự án sử dụng prototype... 68

[Bảng 5] Bảng thống kê các giá trị và mẫu dự đoán của dự án sử dụng prototype.. 70

[Bảng 6] Bảng thống mô tả của màn hình upload...74

[Bảng 7] Bảng danh sách các biến cố và xử lý của màn hình upload...74

[Bảng 8] Bảng thống mơ tả của màn hình kết quả...75

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

2 CK metrics Chidamber & Kemerer metrics suite

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

<b>GIỚI THIỆU</b>

Christopher Wolfgang John Alexander (1936 – 2022) được coi là cha đẻ của cácmẫu thiết kế. Năm 1970, ông lần đầu tiên giới thiệu khái niệm về Pattern languagevốn để áp dụng trong lĩnh vực kiến trúc. Nhận thấy tiềm năng và phạm vi ứng dụngrộng rãi của các mẫu thiết kế,năm 1994, bốn tác giả Erich Gamma, Richard Helm,Ralph Johnson và John Vlissides đã cho xuất bản một cuốn sách với tiêu đềDesignPatterns – Elements of Reusable Object-Oriented Software. Kế thừa và phát triểnkhái niệm mà C.Alexander đề ra, xác định 23 mẫu thiết kế cơ bản, đây là khởinguồn của khái niệm Design pattern trong lập trình.Cho đến hiện tại, design patternlà một phần không thể thiếu trong lĩnh vực phát triển phần mềm, chúng là giải phápchung cho các vấn đề thường gặp mà các lập trình viên cần phải giải quyết. Cácmẫu thiết kế giúp chúng ta xây dựng phần mềm có cấu trúc rõ ràng và linh hoạt.Chúng tạo ra một kiến trúc dễ bảo trì và dễ mở rộng bằng cách tạo ra thành cácmodule, cho phép các nhà phát triển phân tách và sửa đổi các thành phần riêng biệtmà khơng ảnh hưởng đến tồn bộ hệ thống, từ đó giúp chúng ta dễ dàng thay đổi vàmở rộng chức năng của phần mềm mà không gây ra sự bất đồng trong toàn bộ dựán. Hơn nữa, design pattern còn hướng đến việc tái sử dụng mã nguồn, điều nàygiúp giảm thời gian và chi phí, nâng cao hiệu suất. Trong xã hội với những tiến bộcông nghệ đang ngày càng phát triển, không ngừng thách thức các nhà phát triển,nhu cầu và yêu cầu cũng ngày càng khắt khe, kéo theo độ phức tạp của phần mềmngày càng lớn. Điều này càng nhấn mạnh độ quan trọng của các mẫu thiết kế. DPkhông bị giới hạn ở một ngơn ngữ hoặc framework cụ thể, có thể nói chúng là cáckhái niệm tập trung vào high-level design và tương tác giữa các thành phần.Báo cáo này sẽ hướng đến phân tích từng Design pattern và áp dụng các mẫu thiếtkế trong phát triển phần mềm, đồng thời giới thiệu dự án Design pattern detecting.

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

<b>C<small>HƯƠNG</small>1.KIẾN THỨC NỀN TẢNG</b>

<b>1.1.Lịch sử phát triển của phát triển phần mềm</b>

Từ những năm 1950, Phát triển phần mềm là một hoạt động khá phức tạp. Việc lậptrình chỉ được thực hiện ở một vài nơi trên thế giới. Ngôn ngữ phổ biến tại thờiđiểm đó là Assembly nên việc viết code trở nên phức tạp, khơng có hỗ trợ cấu trúcvà khả năng tái sử dụng

Cho đến những năm 1960, các cấu trúc điều khiển (if, else, for, while,…) và các quytrình con ra đời, phương pháp Lập trình hướng cấu trúc (Procedure OrientedProgramming – POP) dần được phổ biến. POP là một kĩ thuật truyền thống, trongđó chương trình được chia thành các chương trình con và liên kết bằng biến cục bộvà con trỏ, giúp đơn giản hóa công việc mã lệnh. Việc này cải thiện khả năng tổchức của mã lệnh, và tăng khả năng tái sử dụng. Tuy nhiên, sự phụ thuộc vào biếntoàn cục (global variable) gây khó khăn trong việc quản lý dữ liệu

<b>1.2.Phát triển phần mềm hướng đối tượng</b>

Lý thuyết về OOP bắt đầu từ những năm 1960, và được thực hiện lần đầu tiên bằngngôn ngữ Simula và tiếp tục phát triển đến những năm 80 với ngôn ngữ Smalltalk.Đến tận những năm 1980, lập trình hướng đối tượng mới được sử dụng rộng rãi nhờsự phổ biến của các ngôn ngữ lập trình hướng đối tượng C++ hay Eiffel. OOP càngtrở nên đột phá khi có sự ra đời của ngơn ngữ JAVA vào những năm 90. Đến năm2002, Microsoft đã giới thiệu ngơn ngữ lập trình hướng đối tượng C#, khiến OOPtrở thành phương pháp chủ đạo và được dùng trong nhiều lĩnh vực khác nhau.

Phần mềm hướng đối tượng tập trung vào việc định nghĩa các đối tượng, trong đókiến trúc của phần mềm dựa trên sự tương tác giữa các đối tượng với nhau để hồnthành một cơng việc. Sự tương tác này có dạng các thơng điệp được gửi qua lại giữacác đối tượng. Để trả lời một thơng điệp, một đối tượng có thể thực hiện một hànhđộng hoặc một phương thức.

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

<b>1.2.1 Thành phần chính</b>

<b>OOP được cấu thành từ 2 phần chính: Class và Object.</b>

<i><b>Trong đó Class sẽ bao gồm Attribute và Methods, đóng vai trị là thành phần cơ bản</b></i>

<b>định nghĩa nên đối tượng. Class được định nghĩa như một bản thiết kế để xây dựng</b>

đặc tính của một đối tượng cụ thể như đặc điểm và hành vi.

<i>Attribute: định nghĩa thông tin, đặc điểm của đối tượng.Methods: là phương thức, hành vi thường có của đối tượng.</i>

<b>Trong khi đó Object là 1 đối tượng cụ thể của 1 Class, được xây dựng dựa trên 1</b>

Class và có các trạng thái và hành vi riêng.

<i>Ví dụ: Lớp Computer bao gồm các thuộc tính như Brand, Color và có các phương</i>

thức như Start() và Shutdown(). Đối tượng myComputer được tạo từ lớp Computersẽ có các đặc điểm riêng như Brand=DELL hay Color=WHITE và cũng sở hữu cácphương thức Start() và Shutdown().

<b>1.2.2 Bốn tính chất của hướng đối tượng</b>

<i>Encapsulation (Đóng gói): Đối tượng chỉ cần công khai các phương thức public để</i>

tương tác với các lớp khác, giúp ẩn các chi tiết bên trong đối tượng nhằm tăng tínhbảo mật.

<i>Inheritance (Kế thừa): Cho phép một lớp con có thể kế thừa và sử dụng thuộc tính</i>

và phương thức lớp cha. Cho phép thêm thuộc tính hoặc mở rộng và sửa đổiphương thức (Polymorphism)

<i>Abstraction (Trừu tượng): Tạo ra các khái niệm trừu tượng để chỉ định các phương</i>

thức và thuộc tính chung mà các lớp đối tượng cần tuân thủ.

<i>Polymorphism (Đa hình): Cho phép phương thức kế thừa trong lớp con ghi đè lên</i>

phương thức lớp cha. Từ đó có thể thực hiện nhiều hành động theo nhiều cách khácnhau tùy vào đối tượng đang thực hiện nó.

<b>1.2.3 Nguyên tắc SOLID</b>

SOLID là từ viết tắt bởi 5 nguyên tắc thiết kế phần mềm hướng đối tượng đượcsoạn ra bởi Robert C. Martin và Michael Feathers.

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">

● Single responsibility principle: Việc một lớp sở hữu quá nhiều chức năng sẽ trởnên cồng kềnh và khó đọc hơn. Do đó, nguyên tắc thứ nhất yêu cầu mỗi mộtclass chỉ mang 1 trách nhiệm duy nhất. Điều này còn giúp việc sửa chữa trở nêndễ dàng hơn.

● Open/Closed principle: Nguyên tắc này yêu cầu khi muốn thêm chức năng chochương trình, ta khơng nên sửa đổi Class cũ. Việc đó sẽ phát sinh thêm mâuthuẫn với các Class khác, từ đó ta phải sốt lại tồn bộ. Thay vào đó, ngun tắcu cầu tạo 1 class mới kế thừa từ class đã có. Tuy sẽ làm tăng số lượng lớptrong chương trình nhưng bù lại ta có thể tách những phần dễ sửa đổi ra riêngbiệt, đảm bảo không ảnh hưởng đến các phần cịn lại

● Liskov substitution principle: Ngun tắc nói rằng các phương thức lớp cha cóthể bị thay thế bởi các phương thức của lớp con mà không làm thay đổi tínhđúng đắn của chương trình.

● Interface segregation principle: Ngun tắc cho rằng các interface cần đượcphần chia thành nhiều Interface nhỏ với nhiều mục đích khác nhau, tránh việcimplement thừa method

● Dependency inversion principle: Nguyên tắc này đề cập tới phụ thuộc củamodule và các lớp trong hệ thống. Các module cấp cao không thể phụ thuộc vàocác module cấp thấp, thay vào đó cả 2 nên phụ thuộc vào các nguyên tắc trừutượng ít biến động như Interface. Như vậy chương trình sẽ trở nên linh động vàcó thể thay đổi bất cứ lúc nào.

<b>1.3.Các Design Patterns phổ biến1.3.1. Creational Patterns</b>

<b>1.3.1.1.Abstract Factory</b>

<i><b>a. Định nghĩa</b></i>

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

- Mẫu thiết kế Abstract Factory cung cấp một interface để tạo ra các đốitượng liên quan hoặc phụ thuộc mà không cần xác định lớp cụ thể.

- Mẫu thiết kế này đặc biệt hữu ích khi hệ thống tạo ra, kết hợp và biểudiễn các đối tượng.

- Mẫu thiết kế Abstract Factory giải quyết vấn đề của việc tạo ra và kết nốinhiều loại đối tượng khác nhau trong hệ thống đồng thời đảm bảo chúngtương thích với nhau.

- Bằng cách sử dụng mẫu thiết kế Abstract Factory, việc tạo ra và kết nốicác đối tượng này trở nên linh hoạt và dễ quản lý hơn.

Participants (Các lớp/Đối tượng):

- AbstractFactory: Định nghĩa interface để tạo ra một họ các sản phẩm.- ConcreteFactory: Kế thừa từ AbstractFactory để tạo ra một họ các sản

phẩm cụ thể.

- AbstractProduct: Định nghĩa interface cho một loại sản phẩm.

- ConcreteProduct: Triển khai interface AbstractProduct để xác định mộtsản phẩm cụ thể.

- Client: Sử dụng các interface được định nghĩa bởi AbstractFactory vàAbstractProduct để làm việc với các sản phẩm.

Cấu trúc:

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

[Hình 1] Sơ đồ cấu trúc Abstract Factory

- Prototype: Abstract Factory có thể được sử dụng cùng với mẫu thiết kếPrototype để tạo ra các đối tượng mới bằng cách sao chép các đối tượnghiện có, cho phép tạo ra các đối tượng với các biến thể khác nhau.

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

<b>1.3.1.2.Factory Method</b>

<i><b>a. Định nghĩa</b></i>

- Trong mẫu thiết kế này, một interface được xác định để tạo ra các đốitượng, những loại cụ thể của đối tượng sẽ được tạo ra lại để cho các lớpcon quyết định.

- Điều này cho phép các lớp con cung cấp hàm triển khai riêng của mìnhđể tạo ra các đối tượng với các loại khác nhau được dẫn xuất từ cùng mộtinterface. Điều này mang lại tính linh hoạt và thúc đẩy khả năng tái sửdụng mã nguồn.

- Mẫu thiết kế Factory Method định nghĩa một interface để tạo ra một đốitượng, nhưng nó để lại việc lựa chọn loại đối tượng cho các lớp con, tạora một đối tượng của một trong nhiều lớp có thể có.

- Nó cho phép một lớp trì hỗn việc khởi tạo đối tượng cho các lớp con củanó, cho phép một lớp chuyển trách nhiệm tạo đối tượng cho các lớp concủa nó.

Participants (Các lớp/Đối tượng):

- Creator: Khai báo Factory Method, trả về một đối tượng kiểu Product.- ConcreteCreator: Triển khai Factory Method để tạo và trả về một phiên

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

[Hình 2] Sơ đồ cấu trúc Factory

<i><b>d. Mẫu tương đồng</b></i>

- Abstract Factory: Factory Method thường được sử dụng kết hợp vớiAbstract Factory. Trong khi Factory Method tạo ra một sản phẩm duynhất, Abstract Factory tạo ra nhóm các sản phẩm liên quan.

- Singleton: Mẫu Singleton có thể được kết hợp với Factory Method đểđảm bảo hệ thống chỉ có một đối tượng duy nhất của một tạo ra cụ thể,kiểm soát quyền truy cập vào việc khởi tạo các lớp tạo ra.

- Template Method: Factory Method là một sự đặc biệt hóa của mẫuTemplate Method. Trong Factory Method, phương pháp mẫu là FactoryMethod chính và các bước là q trình tạo ra sản phẩm.

<i><b>a. Định nghĩa</b></i>

</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">

- Mẫu Builder tách rời quá trình xây dựng một đối tượng phức tạp khỏiviệc biểu diễn nó, cho phép q trình xây dựng cùng một đối tượng có thểtạo ra các biểu diễn khác nhau.

- Bằng cách sử dụng một lớp builder, mã khách có thể chỉ định các bướcxây dựng độc lập với biểu diễn cụ thể của đối tượng được xây dựng.- Điều này tạo ra sự linh hoạt và khả năng tái sử dụng trong việc tạo đối

- Mẫu thiết kế Builder tách quá trình xây dựng một đối tượng phức tạpkhỏi biểu diễn của nó, cho phép cùng một quy trình xây dựng tạo ra cácbiểu diễn khác nhau.

- Mã khách chỉ định loại và nội dung của đối tượng cần tạo, và mẫuBuilder cung cấp một loạt các bước để xây dựng nó.

Participants (Các lớp/Đối tượng):

- Director: Quản lý quá trình xây dựng bằng cách sử dụng interfaceBuilder.

- Builder: Khai báo các bước xây dựng cho sản phẩm.

- ConcreteBuilder: Thực hiện interface Builder để xây dựng và lắp ráp cácphần của sản phẩm.

- Product: Đại diện cho đối tượng phức tạp đang được xây dựng.- Client: Yêu cầu Director xây dựng sản phẩm.

Cấu trúc:

</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">

[Hình 3] Sơ đồ cấu trúc Builder

<i><b>d. Mẫu tương đồng</b></i>

- Abstract Factory: Trong khi Builder tập trung vào việc xây dựng một đốitượng phức tạp, Abstract Factory liên quan đến việc tạo ra nhóm các đốitượng liên quan hoặc phụ thuộc vào nhau.

- Prototype: Builder có thể được sử dụng với Prototype để tạo ra các đốitượng mới bằng cách sao chép một đối tượng hiện có, cho phép xây dựngcác đối tượng phức tạp với các biến thể khác nhau.

- Composite: Mẫu Builder có thể được sử dụng kết hợp với Composite đểxây dựng các đối tượng phức tạp có thể có cấu trúc giống như cây.

<i><b>a. Định nghĩa</b></i>

</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">

- Tạo ra đối tượng mới bằng cách sao chép một đối tượng đã tồn tại, đượcgọi là nguyên mẫu.

Participants (Các lớp/Đối tượng):

- Prototype: Khai báo một interface để sao chép chính nó.

- ConcretePrototype: Thực hiện interface sao chép để tạo ra một bản saomới của chính nó.

- Client: Tạo ra các đối tượng mới bằng cách yêu cầu nguyên mẫu củachúng và sau đó sao chép chúng.

Cấu trúc:

[Hình 4] Sơ đồ cấu trúc Prototype

<i><b>d. Mẫu tương đồng</b></i>

</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">

- Memento: Prototype tương tự như Memento trong việc cả hai mẫu thiếtkế đều liên quan đến việc sao chép trạng thái của một đối tượng. Tuynhiên, Prototype tập trung vào việc sao chép toàn bộ đối tượng, trong khiMemento tập trung vào việc lưu giữ và khôi phục trạng thái của nó.

<i><b>a. Định nghĩa</b></i>

- Đây là một mẫu thiết kế cơ bản được sử dụng rộng rãi trong thiết kế phầnmềm để kiểm soát quyền truy cập đến một điểm kiểm soát hoặc điều phốiduy nhất, như một bộ quản lý cấu hình duy nhất, bộ ghi chú, hoặc kết nốicơ sở dữ liệu.

- Mẫu thiết kế Singleton quan trọng cho các tình huống khi cần chính xácmột đối tượng của một lớp để điều phối các hành động trên toàn hệ thống,ngăn chặn việc tạo nhiều đối tượng và đảm bảo một điểm truy cập toàncầu duy nhất.

- Đảm bảo lớp chỉ có một lần khởi tạo.

- Kiểm soát quyền truy cập đến đối tượng duy nhất để ngăn chặn việc tạonhiều đối tượng.

- Cung cấp một điểm kiểm soát tập trung cho các hành động yêu cầu sựđiều phối trên toàn hệ thống.

Participants (Các lớp/Đối tượng):

- private static Singleton instance: Biến tĩnh riêng để giữ đối tượng duynhất.

- private Singleton(): Hàm tạo riêng để ngăn chặn khởi tạo từ bên ngoài.- public static Singleton getInstance(): Phương thức công cộng để lấy hoặc

tạo đối tượng (Khởi tạo Lười biếng).

- public void showMessage(): Phương thức ví dụ đại diện cho chức năng.

</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">

- Client: public void useSingleton(): Phương thức đối tượng cách lấy và sửdụng đối tượng Singleton.

<b>1.3.2. Structural Patterns1.3.2.1.Adapter</b>

</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">

- Nó giúp đạt được tính tái sử dụng và tương tác bằng cách cho phép cáclớp có các interface khác nhau làm việc cùng nhau một cách mượt mà.

Participants (Các lớp/Đối tượng):

- Target: Định nghĩa interface chuyên ngành mà mã nguồn của khách hàngmong đợi.

- Adaptee: Đại diện cho interface hiện tại cần phải được chuyển đổi.

- Adapter: Thực hiện interface Target có tham số là một đối tượng củaAdaptee. Hoạt động như một cầu nối giữa Target và Adaptee, dịch cácyêu cầu từ Target sang Adaptee.

- Sự khác biệt chính là mẫu thiết kế Adapter tập trung vào việc làm cho cáclớp hiện tại làm việc cùng nhau, trong khi mẫu thiết kế Bridge quan tâmđến việc cung cấp các biến thể cho cả trừu tượng và triển khai.

</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">

- Nó cho phép mở rộng cả hai thứ bậc của trừu tượng và triển khai mộtcách độc lập, thúc đẩy tính linh hoạt, dễ bảo trì và có thể mở rộng.

Participants (Các lớp/Đối tượng):

- Abstraction: Định nghĩa giao diện của lớp trừu tượng và duy trì một thamchiếu đến một đối tượng của Implementor.

- RefinedAbstraction: Mở rộng trừu tượng được định nghĩa bởiAbstraction.

- Implementor: Khai báo một giao diện cho các lớp triển khai cụ thể.- ConcreteImplementor: Thực hiện giao diện Implementor.

Cấu trúc:

</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">

[Hình 7] Sơ đồ cấu trúc Bridge

<i><b>d. Mẫu tương đồng</b></i>

- Trong khi mẫu thiết kế Adapter tập trung hơn vào việc làm cho các lớphiện tại làm việc cùng nhau bằng cách cung cấp một giao diện khác, nócó sự tương đồng với mẫu thiết kế Bridge về mặt cung cấp một cơ chế đểlàm việc với các giao diện khác nhau.

- Sự khác biệt chính là mẫu thiết kế Bridge quan tâm đến việc tách biệt cácthứ bậc của trừu tượng và triển khai, cho phép chúng biến đổi độc lập.

</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">

<i><b>a. Định nghĩa</b></i>

- Mẫu thiết kế Composite là một mẫu thiết kế cấu trúc cho phép tổ chứccác đối tượng thành cấu trúc cây để đại diện cho các phân cấp tồn bộ.- Nó cho phép khách hàng xử lý các đối tượng cá thể và các sự kết hợp của

đối tượng một cách đồng đều.

Participants (Các lớp/Đối tượng):

- Component: Khai báo giao diện cho các đối tượng trong sự kết hợp.- Leaf: Đại diện cho các đối tượng cá thể trong sự kết hợp. Thực hiện giao

diện của Component.

- Composite: Đại diện cho một sự kết hợp của các đối tượng. Thực hiệngiao diện của Component. Có thể chứa một tập hợp các thành phần con.Cấu trúc:

</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">

[Hình 8] Sơ đồ cấu trúc Composite

<i><b>d. Mẫu tương đồng</b></i>

- Mẫu thiết kế Decorator có sự tương đồng với mẫu thiết kế Compositetrong việc cả hai liên quan đến các cấu trúc được tạo thành từ các đốitượng.

- Tuy nhiên, sự khác biệt chính là mẫu thiết kế Composite được thiết kếcho các cấu trúc cây đại diện cho các phân cấp toàn bộ, trong khi mẫuthiết kế Decorator tập trung vào việc đính kèm các trách nhiệm bổ sungcho các đối tượng.

<i><b>a. Định nghĩa</b></i>

- Mẫu thiết kế Decorator là một mẫu thiết kế cấu trúc cho phép thêm hànhvi cho một đối tượng cụ thể, cả tĩnh và động, mà không ảnh hưởng đếnhành vi của các đối tượng khác từ cùng một lớp.

</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">

Participants (Các lớp/Đối tượng):

- Component: Khai báo giao diện cho các đối tượng có thể thêm tráchnhiệm cho chúng một cách động.

- ConcreteComponent: Thực hiện giao diện của Component và định nghĩachức năng cơ bản.

- Decorator: Cũng thực hiện giao diện của Component. Duy trì một thamchiếu đến một Component và định nghĩa một giao diện tuân theo giaodiện của Component.

- ConcreteDecorator: Mở rộng chức năng của Decorator bằng cách thêmcác trách nhiệm mới.

Cấu trúc:

</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">

[Hình 9] Sơ đồ cấu trúc Decorator

<i><b>d. Mẫu tương đồng</b></i>

- Mẫu thiết kế Proxy có sự tương đồng với mẫu thiết kế Decorator, đặc biệtlà khi sử dụng Proxy để kiểm soát quyền truy cập đến một đối tượng.- Tuy nhiên, sự khác biệt chính là mẫu thiết kế Proxy tập trung vào việc

kiểm soát quyền truy cập đến một đối tượng, trong khi mẫu thiết kếDecorator tập trung vào việc thêm trách nhiệm một cách động.

</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">

- Nó hoạt động như một cổng, che đi sự phức tạp của hệ thống con và hiểnthị một cái nhìn đơn giản cho khách hàng.

- Nó khuyến khích sự lỏng lẻo trong kết nối bằng cách ngăn chặn kháchhàng phải tương tác trực tiếp với nhiều thành phần hệ thống con.

Participants (Các lớp/Đối tượng):

- Facade: Biết rõ các lớp hệ thống con chịu trách nhiệm cho một yêu cầu.Chuyển giao yêu cầu của khách hàng cho các đối tượng hệ thống conthích hợp.

- Subsystem: Thực hiện chức năng của hệ thống con. Xử lý công việc đượcgiao bởi Facade.

</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">

- Tuy nhiên, sự khác biệt chính là mẫu thiết kế Proxy tập trung vào việckiểm soát quyền truy cập đến một đối tượng duy nhất, trong khi mẫu thiếtkế Facade cung cấp một giao diện đơn giản cho toàn bộ hệ thống con.

<i><b>a. Định nghĩa</b></i>

- Mẫu thiết kế Flyweight là một mẫu thiết kế cấu trúc với mục tiêu làmgiảm thiểu việc sử dụng bộ nhớ hoặc chi phí tính tốn bằng cách chia sẻcàng nhiều càng tốt với các đối tượng liên quan.

- Điều này được đạt được bằng cách cho phép chia sẻ trạng thái chung giữanhiều đối tượng thay vì mỗi đối tượng giữ một bản sao của nó.

- Mục đích chính của mẫu thiết kế Flyweight là giảm thiểu dấu vết bộ nhớvà cải thiện hiệu suất bằng cách chia sẻ trạng thái chung, không thay đổigiữa nhiều đối tượng.

- Điều này đặc biệt hữu ích khi có nhiều đối tượng tương tự có một số đặcđiểm chung, và trạng thái chung có thể được bên ngồi hóa.

Participants (Các lớp/Đối tượng):

- Flyweight: Khai báo một giao diện thơng qua đó flyweights có thể nhậnvà thực hiện trạng thái bên ngoại.

- ConcreteFlyweight: Thực hiện giao diện Flyweight và đại diện cho cácflyweights được chia sẻ. Chứa trạng thái nội tại có thể được chia sẻ.- UnsharedConcreteFlyweight: Thực hiện giao diện Flyweight nhưng

khơng có trạng thái được chia sẻ. Mọi trạng thái mà nó có là nội tại.- FlyweightFactory: Quản lý việc tạo ra và chia sẻ các đối tượng flyweight.

Đảm bảo rằng các flyweights được chia sẻ và tái sử dụng.Cấu trúc:

</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31">

[Hình 11] Sơ đồ cấu trúc Flyweight// FlyweightFactory class

class FlyweightFactory {

private Map<String, Flyweight> flyweights = new HashMap<>();

public Flyweight getFlyweight(String key) {if (!flyweights.containsKey(key)) {

}

</div><span class="text_page_counter">Trang 32</span><div class="page_container" data-page="32">

<i><b>a. Định nghĩa</b></i>

- Mẫu thiết kế Proxy là một mẫu thiết kế cấu trúc cung cấp một đại diệnhoặc giữ chỗ cho một đối tượng khác để kiểm sốt quyền truy cập đến nó.- Nó hoạt động như một trung gian, cho phép kiểm soát thêm đối với tương

tác với đối tượng thực.

- Mục đích chính của mẫu thiết kế Proxy là kiểm soát quyền truy cập đếnmột đối tượng bằng cách đóng vai trị như một đại diện hoặc giữ chỗ.- Điều này có thể hữu ích trong các tình huống như tải chậm, kiểm soát

truy cập, đăng nhập, hoặc theo dõi, nơi đối tượng thực có thể tốn nhiều tàinguyên hoặc yêu cầu xử lý đặc biệt.

Participants (Các lớp/Đối tượng):

- Subject: Định nghĩa giao diện chung cho RealSubject và Proxy để Proxycó thể được sử dụng ở mọi nơi RealSubject được mong đợi.

- RealSubject: Đại diện cho đối tượng thực mà Proxy đại diện.- Proxy:

- Duy trì một tham chiếu đến RealSubject.

- Thực hiện cùng một giao diện như RealSubject.

</div><span class="text_page_counter">Trang 33</span><div class="page_container" data-page="33">

- Kiểm soát quyền truy cập đến RealSubject và có thể thực hiện các nhiệmvụ bổ sung.

</div><span class="text_page_counter">Trang 34</span><div class="page_container" data-page="34">

xử lý yêu cầu hoặc chuyển tiếp nó cho xử lý viên tiếp theo trong chuỗi.Nó tách rời người gửi yêu cầu từ người nhận và cho phép nhiều đối tượngxử lý yêu cầu mà không cần người gửi biết đối tượng nào cuối cùng sẽ xửlý nó.

- Mục đích chính của mẫu thiết kế Chain of Responsibility là tránh sự kếtnối giữa người gửi yêu cầu và người nhận bằng cách cho nhiều đối tượngcó cơ hội xử lý yêu cầu. Nó cho phép tạo ra một chuỗi động của các xử lýviên, và mỗi xử lý viên trong chuỗi quyết định liệu có xử lý yêu cầu haychuyển tiếp nó cho xử lý viên tiếp theo.

Participants (Các lớp/Đối tượng):- Handler:

- Định nghĩa một giao diện để xử lý yêu cầu.

- Tùy chọn khai báo một tham chiếu đến xử lý viên tiếp theo trongchuỗi.

- ConcreteHandler:

- Thực hiện giao diện Handler.

- Xử lý các yêu cầu mà nó chịu trách nhiệm hoặc chuyển tiếp chúngcho xử lý viên tiếp theo trong chuỗi.

Cấu trúc:

</div><span class="text_page_counter">Trang 35</span><div class="page_container" data-page="35">

[Hình 13] Sơ đồ cấu trúc Chain of Responsibility

</div><span class="text_page_counter">Trang 36</span><div class="page_container" data-page="36">

[Hình 14] Mã nguồn lớp “Client" trong Chain of Responsibility

<i><b>d. Mẫu tương đồng</b></i>

- Command:

- Mẫu thiết kế Command có sự tương đồng với mẫu thiết kế Chain ofResponsibility, đặc biệt là trong việc tách rời người gửi và người nhận.- Tuy nhiên, sự khác biệt chính là mẫu thiết kế Command đóng gói một

yêu cầu như một đối tượng, cho phép hàng đợi, đăng nhập hoặc hỗ trợcác hoạt động có thể hồn tác, trong khi mẫu thiết kế Chain ofResponsibility tập trung vào việc truyền yêu cầu qua một chuỗi động củacác xử lý viên.

<i><b>a. Định nghĩa</b></i>

- Mẫu thiết kế Command là một mẫu thiết kế hành vi đóng gói một yêu cầunhư một đối tượng, cho phép tham số hóa khách hàng với các yêu cầukhác nhau, hàng đợi yêu cầu và đăng nhập các yêu cầu. Nó cũng cungcấp khả năng hồn tác các hoạt động.

- Mục đích chính của mẫu thiết kế Command là tách rời người gửi yêu cầutừ đối tượng thực hiện yêu cầu. Nó cho phép tạo ra một đối tượng lệnhđóng gói tất cả các chi tiết của một yêu cầu, bao gồm cả lời gọi phươngthức, đối số của phương thức và đối tượng thực hiện phương thức.

- Thực hiện giao diện Command.

- Kết hợp một hoạt động cụ thể và đối tượng thực hiện hoạt động đó.

</div><span class="text_page_counter">Trang 38</span><div class="page_container" data-page="38">

[Hình 15] Sơ đồ cấu trúc Command

<i><b>d. Mẫu tương đồng</b></i>

- Mẫu thiết kế Chain of Responsibility có sự tương đồng với mẫu thiết kếCommand, đặc biệt là trong việc tách rời người gửi và người nhận.

</div>