Kể từ đó, các design pattern đã được sử dụng rộng rãi trong ngành phần mềm để giải quyết các vấn đề thiết kế và trở thành một phần quan trọng của quá trình phát triển phần mềm đối tượng.
Trang 1
TRƯỜNG ĐẠI HỌC ĐIỆN LỰC
KHOA ĐIỀU KHIỂN VÀ TỰ ĐỘNG HÓA
BÁO CÁO BỘ MÔN CÔNG NGHỆ PHẦN MỀM
ĐỀ TÀI TÌM HIỂU:
TÌM HIỂU VỀ DESIGN PATTERN
Sinh viên thực hiện : BÙI VĂN HƯNG
NGUYỄN HOÀNG PHÚC Giảng viên hướng dẫn : LÊ HOÀN
Lớp : D16THDK&TDH1
Hà Nội, tháng 5/2022
Trang 2MỤC LỤC LỜI MỞ ĐẦU
Trang 3KẾT LUẬN
DANH MỤC TÀI LIỆU THAM KHẢO
Trang 4LỜI MỞ ĐẦU
Cùng với sự phát triển của nền kinh tế, của thời đại 4.0 và sắp chuẩn bị quá độ lên 5.0 Việc cập nhật thông tin là rất dễ dàng, đưa con người ta càng dễ tiếp cận tớicác kiến thức trên thế giới Và một điều đáng mừng và đáng lo ngại đang diễn ra từng giờ từng phút mà chúng ta có lẽ không hề hay biết, đó là theo báo cáo của Tổ chức Sở hữu Trí tuệ Thế giới (WIPO) vào năm 2019, đã có khoảng 3,3 triệu đơn xin cấp bằng sáng chế được nộp trên toàn thế giới trong năm đó Điều này có nghĩa
là trung bình, có khoảng 9.041 đơn xin cấp bằng sáng chế được nộp mỗi ngày Tức
là trung bình 10 giây sẽ có 1 phát minh ra đời và yêu cầu cấp bằng sáng chế còn chưa tính tới những sáng chế mà họ chưa mang đi yêu cầu cấp bằng Xã hội ngày càng phát triển đó vừa là một đòn bẩy giúp chúng ta “bay” xa hơn nếu chúng ta biếtcách chọn lọc, và cũng vừa là một cục tạ đè nén sự phát huy của chúng ta bởi kiến thức của nhân loại thực sự là quá khổng lồ Và sự thật rằng nếu ta muốn phát minh hay làm một việc gì đó mà không có sự hướng dẫn, không có mẫu thì rất khó chúng
ta có thể thành công Chả nhẽ cứ một vấn đề nào đó sảy ra chúng ta lại phải mò mẫm xử lí từng lỗi bug, nhỏ, hay tạo một phần mềm nào đó mà vấn đề gặp lại nhiều lần chúng ta lại phải fix lại từng lỗi một Để tối ưu thời gian Christopher Alexander người giới thiệu Degign Pattern – một giải pháp có thể tái sử dụng cho một vấn đề thiết kế, đã đươc điều chình cho nhiều ngành khác nhau, đặc biệt là công nghệ phần mềm Chúng em xin phép được trình bày bản báo cáo này tới thầy Hoàn sau một thời gian tìm hiểu về Degign Pattern
Mặc dù đã cố gắng với tất cả nỗ lực của cả hai để hoàn thiện bản báo cáo, nhưng
do thời gian có hạn, năng lực và kinh nghiệm còn hạn chế nên bản báo cáo không thể tránh khỏi những thiếu sót Do tìm tham khảo một số tài liệu quốc tế, nên khi dịch thuật có chỗ sai sót mong quí thầy cô thông cảm Kính mong nhận đượ sự góp
ý từ phía thầy cô để chúng em nâng cao kiến thức và hoàn thiện bản báo cáo tốt hơn
Chúng em xin chân thành cảm ơn !
Trang 5PHẦN 1: KIẾN THỨC CƠ BẢN
1.1 Vấn đề trong thiết kế phần mềm đối tượng
-Thiếu kiến thức về lĩnh vực: Khi không hiểu rõ về lĩnh vực cần thiết kế, người thiết kế sẽ khó có thể xác định được các đối tượng, thuộc tính, và phương thức cần thiết cho hệ thống
Không xác định được đối tượng chính xác: Nếu không xác định được các đối tượngquan trọng của hệ thống và mối quan hệ giữa chúng, thiết kế có thể dẫn đến các lỗ hổng hoặc sai sót trong hệ thống
-Thiếu quá trình phân tích yêu cầu: Nếu không tiến hành phân tích yêu cầu đầy đủ hoặc không hiểu yêu cầu của khách hàng, người thiết kế sẽ khó có thể thiết kế một
hệ thống đáp ứng được nhu cầu của khách hàng
-Thiếu sự linh hoạt: Đôi khi, hệ thống cần phải thay đổi hoặc mở rộng trong tương lai Nếu thiết kế không linh hoạt, việc thay đổi hoặc mở rộng hệ thống sẽ rất khó khăn hoặc thậm chí là không thể
-Thiếu sự tương tác giữa đối tượng: Nếu thiết kế không xác định được các mối quan hệ giữa các đối tượng, hệ thống có thể trở nên phức tạp và khó hiểu
-Không tập trung vào người dùng cuối: Nếu thiết kế không tập trung vào người dùng cuối, hệ thống có thể trở nên khó sử dụng và gây khó khăn cho người dùng khi sử dụng
- Không áp dụng chính xác: Khi sử dụng một design pattern, nếu không áp dụng đúng cách hoặc áp dụng vào sai vị trí có thể dẫn đến việc mã nguồn không đáp ứng được yêu cầu, hoặc trở nên phức tạp và khó hiểu
-Thiếu kiến thức về các design pattern: Nếu không có đủ kiến thức về các design pattern, người thiết kế có thể không lựa chọn được design pattern phù hợp cho vấn
đề cần giải quyết
-Thiếu linh hoạt: Mỗi design pattern được thiết kế để giải quyết một vấn đề cụ thể Nếu không có đủ linh hoạt để sử dụng nhiều design pattern một cách kết hợp, có thể dẫn đến việc thiết kế không hoàn hảo
-Không phù hợp với yêu cầu: Nếu không chọn được design pattern phù hợp với yêucầu của hệ thống, có thể dẫn đến việc thiết kế sẽ trở nên phức tạp và khó hiểu.-Thiếu tính tái sử dụng: Nếu không thiết kế các design pattern để có thể tái sử dụng,việc phát triển và bảo trì hệ thống sẽ trở nên khó khăn
Trang 6-Thiếu tương tác giữa các design pattern: Nếu không thiết kế các design pattern saocho chúng tương tác với nhau một cách hiệu quả, thiết kế có thể trở nên rắc rối và khó hiểu.
1.2 Lịch sử hình thành của Design Pattern
Design pattern là một khái niệm được định nghĩa bởi ba tác giả Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides vào năm 1994 Tuy nhiên, ý tưởngcủa việc sử dụng các patterns để thiết kế phần mềm đã xuất hiện từ khá lâu trước đó
Trong những năm 1960 và 1970, các nhà nghiên cứu đã bắt đầu sử dụng các kỹ thuật kiến trúc để thiết kế phần mềm Trong thập niên 1980, Grady Booch, James Rumbaugh và Ivar Jacobson đã phát triển UML (Unified Modeling Language) - một ngôn ngữ mô hình hóa đối tượng để đại diện cho các cấu trúc trong thiết kế phần mềm
Sau đó, vào cuối những năm 1980 và đầu những năm 1990, các nhà nghiên cứu đã phát hiện ra rằng khi thiết kế phần mềm, có thể sử dụng lại các patterns đã được kiểm chứng để giải quyết các vấn đề Các patterns này đã được gọi là "design patterns" và được định nghĩa và công bố trong cuốn sách "Design Patterns:
Elements of Reusable Object-Oriented Software" của bốn tác giả Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides năm 1994
Kể từ đó, các design pattern đã được sử dụng rộng rãi trong ngành phần mềm để giải quyết các vấn đề thiết kế và trở thành một phần quan trọng của quá trình phát triển phần mềm đối tượng
Sau khi được công bố, cuốn sách "Design Patterns: Elements of Reusable Oriented Software" đã trở thành một tài liệu tham khảo quan trọng đối với các nhà phát triển phần mềm Các design pattern được định nghĩa trong cuốn sách được chia thành ba loại: Creational, Structural và Behavioral
Object-Các Creational Patterns bao gồm Singleton, Factory Method, Abstract Factory, Builder và Prototype Những patterns này tập trung vào cách tạo ra các đối tượng.Các Structural Patterns bao gồm Adapter, Bridge, Decorator, Composite, Facade, Flyweight và Proxy Những patterns này tập trung vào cách tổ chức các đối tượng
để tạo thành các cấu trúc lớn hơn
Các Behavioral Patterns bao gồm Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method và
Trang 7Visitor Những patterns này tập trung vào cách các đối tượng tương tác với nhau trong hệ thống.
Sau khi cuốn sách được xuất bản, các design pattern đã trở thành một phần quan trọng của ngành phát triển phần mềm đối tượng và đã được sử dụng rộng rãi trong các hệ thống phần mềm
Hiện nay, có nhiều nguồn tài liệu trực tuyến và sách về các design pattern, giúp chocác nhà phát triển phần mềm có thể sử dụng chúng một cách hiệu quả để giải quyết các vấn đề trong quá trình thiết kế và phát triển phần mềm
1.3 Khái niệm
Design pattern (mẫu thiết kế) là một giải pháp được định nghĩa trước để giải quyết các vấn đề phát sinh trong quá trình thiết kế phần mềm Design pattern giúp các nhà phát triển phần mềm sử dụng lại các giải pháp đã được kiểm chứng để giải quyết các vấn đề tương tự trong ứng dụng khác
Một design pattern bao gồm các thành phần cơ bản, bao gồm:
1 Mô tả của vấn đề: Mô tả vấn đề sẽ được giải quyết bằng design pattern
2 Giải pháp: Mô tả các thành phần và quan hệ giữa chúng để giải quyết vấn đề
3 Hiệu quả: Lợi ích của việc sử dụng design pattern, bao gồm tính linh hoạt và tái sử dụng
Các design pattern thường được phân loại thành ba loại chính:
1 Creational patterns: Tập trung vào cách tạo ra các đối tượng, bao gồm
Singleton, Factory Method, Abstract Factory, Builder và Prototype
2 Structural patterns: Tập trung vào cách tổ chức các đối tượng để tạo thành các cấu trúc lớn hơn, bao gồm Adapter, Bridge, Decorator, Composite, Facade, Flyweight và Proxy
3 Behavioral patterns: Tập trung vào cách các đối tượng tương tác với nhau trong hệ thống, bao gồm Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method và Visitor
Trang 8Việc sử dụng design pattern giúp cho quá trình thiết kế phần mềm trở nên hiệu quả hơn, tăng tính tái sử dụng của mã nguồn, và giảm thiểu thiếu sót hoặc lỗi trong quá trình phát triển.
Một trong những lợi ích quan trọng của việc sử dụng design pattern đó là giúp cho các nhà phát triển phần mềm có thể áp dụng kiến thức và kinh nghiệm đã có đểgiải quyết các vấn đề phức tạp trong quá trình thiết kế phần mềm Thay vì phải tìm kiếm một giải pháp mới cho mỗi vấn đề, người thiết kế có thể áp dụng một design pattern đã được kiểm chứng và tin tưởng để giải quyết vấn đề
Các design pattern cũng giúp cho việc phát triển phần mềm trở nên dễ dàng hơn
và tiết kiệm thời gian hơn Việc sử dụng lại các giải pháp đã được kiểm chứng trong các design pattern giúp cho các nhà phát triển phần mềm không cần phải tiêu tốn quá nhiều thời gian và công sức để tìm ra một giải pháp mới Thêm vào đó, các design pattern cũng giúp cho mã nguồn trở nên dễ hiểu và dễ bảo trì hơn, bởi vì cácthành phần của chúng đã được định nghĩa rõ ràng và có tính tái sử dụng cao
Tuy nhiên, việc sử dụng design pattern cũng có một số hạn chế Việc áp dụng các design pattern không phù hợp hoặc không chính xác có thể dẫn đến các lỗi và vấn đề trong quá trình phát triển phần mềm Thêm vào đó, việc sử dụng quá nhiều design pattern trong một ứng dụng cũng có thể làm cho mã nguồn trở nên phức tạp
và khó hiểu
Trong tổng quát, việc sử dụng design pattern là một phương pháp thiết kế phần mềm hiệu quả và đã được sử dụng rộng rãi trong ngành công nghệ thông tin Tuy nhiên, để sử dụng chúng một cách hiệu quả, người thiết kế cần phải có đủ kiến thức
và kinh nghiệm về các design pattern và biết cách áp dụng chúng một cách chính xác và linh hoạt.
1.4 Đặc điểm chung
Các Design pattern có những đặc điểm chung sau:
1.Giải quyết các vấn đề phổ biến: Các design pattern được sử dụng để giải quyết các vấn đề thường gặp trong quá trình thiết kế phần mềm Chúng được tạo ra để giúp cho việc thiết kế phần mềm trở nên dễ dàng hơn và hiệu quả hơn
2.Mẫu chuẩn: Các design pattern được định nghĩa trước và đã được kiểm chứng trong quá trình sử dụng Chúng được xem là một mẫu chuẩn để thiết kế phần mềm.3.Tính tái sử dụng: Việc sử dụng các design pattern giúp cho mã nguồn trở nên dễ dàng tái sử dụng Những giải pháp đã được kiểm chứng và tích luỹ kinh nghiệm của các nhà phát triển trước đó có thể được áp dụng lại trong các ứng dụng khác
Trang 94.Tính linh hoạt: Mỗi design pattern có thể được áp dụng vào nhiều tình huống khác nhau Chúng không bị giới hạn bởi một số điều kiện cụ thể và xoay quanh ý tưởng cơ bản để giải quyết các vấn đề thiết kế.
5.Được tài liệu hóa: Các design pattern đã được tài liệu hóa và được công bố để người dùng có thể áp dụng chúng vào việc thiết kế phần mềm
6.Tồn tại lâu dài: Các design pattern không phải là một giải pháp tạm thời, mà là một mẫu thiết kế đã được kiểm chứng trong nhiều năm và vẫn sử dụng rộng rãi chođến ngày nay
-Tóm lại, các Design pattern là một công cụ thiết kế phần mềm hiệu quả và tiết kiệm thời gian, giúp cho quá trình thiết kế phần mềm trở nên dễ dàng và hiệu quả hơn
-Các Design pattern phù hợp cho việc xử lý các vấn đề khác nhau trong thiết kế phần mềm Ví dụ, các Creational patterns thường được sử dụng để tạo ra các đối tượng với các thuộc tính cụ thể Các Structural patterns có thể được sử dụng để tổ chức các đối tượng và quan hệ giữa chúng để tạo thành các cấu trúc lớn hơn Các Behavioral patterns giúp các đối tượng trong hệ thống tương tác với nhau và cải thiện tính linh hoạt của mã nguồn
Các Design pattern không chỉ bao gồm kiến thức về cách thiết kế phần mềm mà còn liên quan đến các nguyên tắc thiết kế phần mềm Các nguyên tắc này bao gồm:1.Nguyên tắc đơn trách nhiệm: Mỗi lớp hoặc đối tượng trong hệ thống có trách nhiệm duy nhất
2.Nguyên tắc mở rộng - đóng gói: Đối tượng phải được thiết kế để mở rộng hoặc
mở rộng các tính năng mà không làm thay đổi mã nguồn hiện có
3.Nguyên tắc thay thế Liskov: Các đối tượng con phải có thể thay thế cho đối tượng cha mà không làm thay đổi tính năng của hệ thống
4.Nguyên tắc phân chia ứng dụng: Hệ thống phải được phân chia thành các thành phần riêng biệt để giảm thiểu sự phụ thuộc và tăng tính linh hoạt
5.Nguyên tắc giao diện người dùng: Giao diện người dùng phải được thiết kế để dễ
sử dụng và cung cấp trải nghiệm tốt cho người dùng
6.Nguyên tắc lặp đi lặp lại: Mã nguồn không nên bị lặp lại trong hệ thống
Trang 10Các Design pattern cũng liên kết tới các khái niệm quan trọng như SOLID, Clean Code và Refactoring Các nguyên tắc này giúp cho việc thiết kế phần mềm trở nên
dễ hiểu, bảo trì và mở rộng hơn
1.5 Ưu và nhược điểm của Design Pattern
1.5.1 Ưu điểm
Các ưu điểm của việc sử dụng design pattern trong thiết kế phần mềm bao gồm:1.Tái sử dụng mã nguồn: Các design pattern giúp cho việc tái sử dụng mã nguồn trở nên dễ dàng hơn, nhờ vào các giải pháp đã được kiểm chứng và tích luỹ kinh nghiệm của các nhà phát triển trước đó
2.Hiệu quả trong thiết kế: Việc sử dụng các design pattern giúp cho việc thiết kế phần mềm trở nên hiệu quả hơn và tiết kiệm thời gian hơn Thay vì tìm kiếm một giải pháp mới cho mỗi vấn đề, người thiết kế có thể áp dụng một design pattern đã được kiểm chứng và tin tưởng để giải quyết vấn đề
3.Mã nguồn dễ hiểu và dễ bảo trì: Các design pattern giúp cho mã nguồn trở nên dễhiểu và dễ bảo trì hơn, bởi vì các thành phần của chúng đã được định nghĩa rõ ràng
và có tính tái sử dụng cao
4.Tính linh hoạt và mở rộng: Các design pattern giúp cho hệ thống trở nên linh hoạt
và dễ mở rộng hơn Các thành phần của chúng được tách biệt ra, giúp cho việc thayđổi và cập nhật trở nên dễ dàng hơn
5.Tăng tính khả chuyển: Việc sử dụng các design pattern giúp cho mã nguồn trở nên dễ di chuyển và khả chuyển hơn giữa các ứng dụng khác nhau Điều này giúp cho việc tái sử dụng mã nguồn trở nên dễ dàng hơn và giảm thiểu thời gian phát triển
Tóm lại, việc sử dụng design pattern là một phương pháp thiết kế phần mềm hiệu quả và đã được sử dụng rộng rãi trong ngành công nghệ thông tin Các ưu điểm củaviệc sử dụng design pattern giúp cho quá trình thiết kế phần mềm trở nên hiệu quả hơn, tăng tính tái sử dụng và giảm thiểu lỗi trong quá trình phát triển
Trang 11
1.5.2 Nhược điểm
Các nhược điểm của việc sử dụng design pattern trong thiết kế phần mềm bao gồm:1.Tăng độ phức tạp của mã nguồn: Việc sử dụng quá nhiều design pattern có thể làm cho mã nguồn trở nên phức tạp hơn và khó hiểu hơn Điều này có thể làm cho việc bảo trì và phát triển ứng dụng trở nên khó khăn hơn
2.Không phù hợp với mọi vấn đề: Mỗi design pattern được thiết kế để giải quyết một vấn đề cụ thể, không phải mọi vấn đề Khi áp dụng sai design pattern hoặc sử dụng quá nhiều design pattern không phù hợp, các lỗ hổng và lỗi có thể xuất hiện trong ứng dụng
3.Yêu cầu kiến thức chuyên môn cao: Các design pattern đòi hỏi người thiết kế phải có kiến thức chuyên môn cao để hiểu và áp dụng chúng một cách chính xác vàhiệu quả Người mới bắt đầu trong lĩnh vực này có thể gặp khó khăn khi sử dụng các design pattern
4.Khó khăn trong việc thay đổi: Việc sử dụng các design pattern trong ứng dụng cóthể làm cho việc thay đổi và cập nhật trở nên khó khăn hơn Do các thành phần của chúng được tách biệt ra, việc thay đổi một thành phần có thể ảnh hưởng đến toàn
bộ hệ thống
5.Có thể giới hạn sự sáng tạo: Sử dụng quá nhiều design pattern có thể khiến cho người thiết kế bỏ qua các cách tiếp cận thiết kế khác và hạn chế tính sáng tạo của họ
Tóm lại, việc sử dụng design pattern trong thiết kế phần mềm có những nhược điểm nhất định Người thiết kế cần phải áp dụng chúng một cách linh hoạt và chínhxác để đạt được các lợi ích của chúng và tránh được các nhược điểm này
Một nhược điểm khác của việc sử dụng design pattern trong thiết kế phần mềm là:6.Không phù hợp với ứng dụng đơn giản: Các design pattern thường được sử dụng
để giải quyết các vấn đề phức tạp trong thiết kế phần mềm Tuy nhiên, khi áp dụng chúng vào các ứng dụng đơn giản hoặc nhỏ, chúng có thể làm cho mã nguồn trở nên rườm rà và không cần thiết
7.Lỗi và lỗ hổng: Việc sử dụng các design pattern không đúng cách hoặc không phù hợp có thể gây ra các lỗi và lỗ hổng trong ứng dụng Do đó, quá trình kiểm tra
và xác minh các design pattern cần được thực hiện cẩn thận để đảm bảo không có lỗi xảy ra trong ứng dụng
Trang 128.Sự hiểu nhầm về design pattern: Một số người thiết kế có thể hiểu sai hoặc sử dụng các design pattern không đúng cách, dẫn đến việc thiết kế mã nguồn không đáp ứng được yêu cầu hoặc không thực sự giải quyết được vấn đề.
9.Không phù hợp với các công nghệ mới: Các design pattern được phát triển và sử dụng từ rất lâu, do đó chúng không phù hợp hoặc không có thể áp dụng cho các công nghệ mới như Internet of Things (IoT) hay trí tuệ nhân tạo (AI)
10.Chi phí phát triển: Việc sử dụng các design pattern có thể tăng chi phí phát triển ứng dụng Người thiết kế phải tốn thời gian để học và hiểu các design pattern, và thao tác mã nguồn cũng có thể tốn nhiều thời gian hơn so với việc thiết kế từ đầu.Tóm lại, việc sử dụng design pattern trong thiết kế phần mềm không phải là giải pháp hoàn hảo cho mọi vấn đề Người thiết kế cần phải xem xét và áp dụng chúng một cách thông minh và linh hoạt để đạt được các lợi ích của chúng và tránh các nhược điểm này
1.6 Phân loại Design Pattern
1.6.1 Nhóm Crearional
Trong mô hình thiết kế phần mềm, nhóm Creational là một trong số 3 nhóm chính, bao gồm các mẫu thiết kế cung cấp các giải pháp để tạo ra các đối tượng và các thành phần của chúng
Là một lập trình viên, chắc chắn bất cứ ai trong chúng ta cũng đều dành phần lớn thời gian để khởi tạo các lớp và đối tượng Đó cũng chính là lý do mà các design patterns này đã ra đời nhằm giúp cho việc khởi tạo các lớp và đối tượng mộtcách thông minh, khoa học và hiệu quả hơn trong một số trường hợp cụ thể
Việc khởi tạo một đối tượng mới chỉ cần new ClassName là đủ rồi mà, có gì khókhăn đâu mà cần phải có cả một nhóm design pattern? Đúng là như vậy, trong hầu hết các trường hợp để khởi tạo một đối tượng chúng ta sẽ sử dụng trực tiếp câu lệnhnew ClassName Nhưng không chỉ dễ dàng như vậy, đâu phải lúc nào cũng thích new là new được đâu Việc khởi tạo ra một đối tượng mới đôi khi phải trải qua một vài điều kiện, vài logic thì mới có thể được thực hiện được
Sau nhiều năm tích lũy kinh nghiệm, trải qua nhiều dự án, các bậc tiền bối xưa
đã sáng tạo ra một số design pattern để phục vụ cho việc khởi tạo đối tượng
1.6.2 Nhóm Structural
Trang 13Nhóm các design patterns này ra đời nhằm giải quyết các vấn đề liên quan đến cách tổ chức, thiết lập và định nghĩa lớp, đối tượng sao cho linh hoạt, ngăn nắp để
dễ dàng thay đổi, hay mở rộng code về sau
Thông thường một phần mềm thay đổi tính năng là điều xảy ra như “cơm bữa” Nếu như bạn không muốn mỗi lần thay đổi chức năng là một lần phải đập đi làm lại
cả hệ thống Thì bạn nên có cách tổ chức linh hoạt để có thể thực hiện sự thay đổi,
Biết rằng: mỗi lớp, đối tượng trong dự án sẽ chịu một trách nhiệm riêng, nhưng khi
dự án của mình trở nên lớn và công kềnh thì rất khó để đảm bảo được điều đó Vì vậy các design pattern loại này sẽ giúp bạn quản lý hành vi, trách nhiệm của các lớp một cách dễ dàng hơn
Trang 14PHẦN 2: CÁC KỸ THUẬT CỦA DESIGN PATTERN
2.1 Nhóm Crearional
Các pattern thuộc nhóm Creational bao gồm:
1 Factory Method Pattern: cho phép tạo ra các đối tượng mà không cần biết chitiết về cách thức tạo ra chúng
Định nghĩa
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)
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
Trang 15và 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 1 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
public class AnimalFactory {
public static IAnimal CreateAnimal ( AnimalType type)
Trang 17 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
ConcreteCrator: ghi đè factory method để trả về một instance của concreteproduct
4 Ư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 đích tạo mới object
và không cần quan tâm đến cách nó được tạo ra)
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
Trang 185 Khi nào thì sử dụng
Factory method được sử dụng khi:
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
2 Abstract Factory Pattern: cung cấp một giao diện để tạo ra các đối tượng có liên quan hoặc phụ thuộc lẫn nhau mà không cần chỉ định các lớp cụ thể
1 Giới thiệu
Abstract Factory (Kit) là một design pattern thuộc nhóm
Creational Pattern Design – những mẫu thiết kế cho việc khởi tạo đối tượng của lớp
Được xây dựng dựa trên Factory Pattern và nó được xem là mộtfactory cao nhất trong hệ thống phân cấp Pattern này sẽ tạo racác factory là class con của nó và các factory này được tạo ra giống như cách mà factory tạo ra các sub-class
Mục đích: Cung cấp một interface cho việc khởi tạo các tập hợpcủa những object có đặc điểm giống nhau mà không cần quan tâm object đó là gì
Tần suất sử dụng: cao
Trang 192 Mục đích ra đời
Abstract Factory Pattern giúp đảm bảo rằng các product mà bạn nhận được từ một factory đều tương thích với nhau
Abstract Factory Pattern giúp hạn chế sự phụ thuộc giữa
creator và concrete products
Abstract Factory Pattern 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
Với Abstract Factory Pattern, chúng ta có thể thoải mái thêm nhiều loại product mới vào chương trình mà không làm thay đổicác đoạn code nền tảng đã có trước đó
Ví dụ, lấy trường hợp của một người quản lý điện thoại, người quản lý các số điện thoại Số điện thoại tuân theo một quy tắc tạo mã cụ thể theo khu vực cho từng quốc gia Nếu tại một thờiđiểm nào đó, ứng dụng phải được thay đổi để hỗ trợ thêm số tạo thành một quốc gia mới, mã của ứng dụng sẽ phải được thay đổi và nó sẽ ngày càng trở nên phức tạp hơn Để ngăn chặn nó, Abstract Factory được sử dụng
Trang 203 Kiến trúc
Các thành phần trong mô hình:
Trang 21 AbstractFactory: Khai báo dạng interface hoặc abstract class chứa các phương thức để tạo ra các đối tượng Abstract Product.
ConcreteFactory: Xây dựng, cài đặt, thực hiện các phương thức được tạo nên từ Abstract Factory Mỗi ConcreteFactory tương ứng với một biến thể khác của product và chỉ tạo ra những biếnthể của sản phẩm đó Ví dụ: AbstractFactory là Document thì ConcreteFactory sẽ là FancyDocument, MordernDocument
AbstractProduct: Khai báo dạng interface hoặc abstract class cho một tập hợp các product riêng biệt nhưng có liên quan đến nhau Ví dụ: AbstractProduct của AbstractFactory Document là CreateLetter, CreatePage, CreateResume
ConcreteProduct: Là các cách triển khai khác nhau của
AbstractProduct gồm nhiều các biến thể Mỗi nhóm
AbstractProduct phải được thực hiện cùng các biến thể nhất định Ví dụ ở trên ta có:
o AbstractFactory là Document thì ConcreteFactory sẽ là FancyDocument, MordernDocument
o AbstractProduct của AbstractFactory Document là
CreateLetter, CreatePage, CreateResume Thì ConcreteProduct sẽ là FacyCreateLetter, FancyCreatePage, FancyCreateResume
Client: là đối tượng sử dụng AbstractFactory, AbstractProduct
và client cũng có thể làm việc với bất kỳ biến thể nào của
ConcreteFactory, ConcreteProduct, miễn là nó có giao tiếp với đối tượng (object) thông qua abstract interface
4 Ưu & nhược điểm
Nguyên tắc mở/ đóng: có thể khởi tạo những bản mới của
product mà không cần phá vỡ client code hiện có
Nhược điểm
Trang 22 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.
5 Khi nào thì sử dụng
Sử dụng Abstract Facotry khi cần làm việc với các product có tính chất gần giống nhau và liên quan đến nhau và không cần phụ thuộc vào các định nghĩa có sẵn trong class đó:
Phía client sẽ không phụ thuộc vào việc những sản phẩm được tạo ra như thế nào
Ứng dụng sẽ được cấu hình với một hoặc nhiều họ sản phẩm
Các đối tượng cần phải được tạo ra như một tập hợp để có thể tương thích với nhau
6 Source code minh họa với C#
Tạo Abstract Factory
Trang 23public string GetMyDetails()
{
return my.GetModelDetails(); }
}
Trang 26MonNuocFactory loaiNac = new LoaiNacFactory();
Client NacClient = new Client(loaiNac);
MonNuocFactory loaiGio = new LoaiGioFactory();
Client GioClient = new Client(loaiGio);
Console.WriteLine("********* HU TIEU **********"); Console.WriteLine(NacClient.GetHuTieuDetails());
Console.WriteLine(GioClient.GetHuTieuDetails());
3 Builder Pattern: cho phép tạo ra các đối tượng phức tạp từ các thành phần đơn giản và độc lập với nhau
Trang 27 Cho phép bạn xây dựng các đố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 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
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áclớ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ệ
Trang 28thố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
Trang 29nhỏ 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
Solution
Vì vậy Builder Pattern gợi ý rằng bạn trích xuất object construction code ra khỏi lớp của chính nó và di chuyển nó đến các object riêng biệt được gọi là Builder
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ạncầ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ộtcabin 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áchkhá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
Trang 30dựng) để tạo ra các loại object khác nhau.
Ví dụ, hãy tưởng tượng 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ườithứ 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
Director
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ủabuilder 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
Trang 31Lớ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 hoàn toàn cần thiết Bạn luôn 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
Ngoài ra, lớp director hoàn toà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
Trang 323 Kiến 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 tuân theo giao diện chung
Trang 33 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
Tuy nhiên, có một cách tiếp cận thay thế khi client chuyển builder object sang production method của director Trong trường hợp này, bạn có thể sử dụng một builder khác mỗi khi bạn sản xuất nội dung
Trang 34nào đó với director.
Ví dụ: Class Director không trực tiếp tạo vào lắp ráp thành product là Car và Manual Thay vào đó class Director chí đến Builder Interface
để tạo nên các bộ phận của một complex object, làm cho Director độc lập với các lớp cụ thể nào được khởi tạo (biểu diễn nào được tạo ra)
Lớp CarBuilder triển khai giao diện Builder bằng cách tạo và lắp ráp các đối tượng Car và tương tự lớp CarManualBuilder triển khai giao diện Builder bằng ac1ch tạo và lắp ráp các đối tượng Manual
Trang 354 Ưu & nhược điể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
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
Trang 36 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ừngbướ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 đủ.
6 Source code minh họa với C#
//Builder Interface: chỉ 8 định các phương phương pháp để8 tạo các phầA n khác nhau Product object
public interface IBuilder
private Product _product = new Product()
4 Singleton Pattern: đảm bảo rằng chỉ có một phiên bản duy nhất của một đối tượng được tạo ra và cung cấp truy cập toàn cục đến nó
Trang 375 Prototype Pattern: cho phép sao chép hoặc tạo ra các đối tượng mới từ một đối tượng đã tồn tại, giúp tăng hiệu suất và giảm chi phí khi tạo ra các đối tượng.Tất cả các pattern trong nhóm Creational đều giúp cho việc tạo ra các đối tượng trở nên dễ dàng hơn và tăng tính linh hoạt và tái sử dụng của mã nguồn.
1 Giới thiệu
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
2 Mục đích ra đời
Đôi khi, 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
Trang 38Lập trình hướng đối tượng.
Để giải bài toán trên, người ta hướng đến một giải pháp là sử dụng Singleton pattern
Trang 394 Ưu & nhược điểm
Ư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
5 Khi nào thì sử dụng
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,…
Trang 406 Source code minh họa với C#
No Thread Safe Singleton
public sealed class Singleton1 {
private Singleton1() {}
private static Singleton1 instance = null;
public static Singleton1 Instance {
Thread Safety Singleton
public sealed class Singleton2 {