Tìm hiểu tình hình phát triển công nghệ phần mềm và sử dụng mẫu thiết kế
Chương 1 LỜI NÓI ĐẦU 1
1.1. Khó khăn khi phát triển công nghệ phần mềm và sử dụng Mẫu thiết kế. 2
1.2. Mục đích của đồ án. 3
1.3. Việc nghiên cứu đồ án giải quyết điều gỡ 4
1.4. Việc giải quyết đồ án ở giai đoạn tốt nghiệp được thực hiện như thế nào? 4
Chương 2 ĐẶT VẤN ĐỀ 6
2.1. Mục đích của đề tài 6
2.2. Giới thiệu bài toán, nhiệm vụ của đề tài 6
2.3. Lý do chọn đề tài. 7
Chương 3 TỔNG QUAN VỀ MẪU THIẾT KẾ 8
3.1. Lịch sử về mẫu dỏng thiết kế. 8
3.1.1. Mục đích của các mẫu thiết kế. 8
3.1.2. Các mẫu thiết kế giải quyết vấn đề như thế nào? 9
3.1.3. Các phương pháp để chọn các mẫu thiết kế 9
3.1.4. Làm thế nào để thiết kế một mẫu thiết kế 10
3.2. Cỏc mẫu dỏng thiết kế (Mẫu thiết kế) 10
3.2.1. Khỏi quỏt chung về Mẫu thiết kế. 10
3.2.2. Mẫu khởi tạo 11
3.2.2.1. Abstract Factory. 12
3.2.2.1.1 Mục đích 12
3.2.2.1.2 Vớ dụ 12
3.2.2.1.3 Ứng dụng 13
3.2.2.1.4 Cấu trỳc 13
3.2.2.1.5 Cỏc thành phần 14
3.2.2.1.6 Phối hợp cộng tỏc với cỏc mẫu khỏc: 14
3.2.2.1.7 Kết quả 14
3.2.2.1.8 Cài đặt 15
3.2.2.1.9 Cỏc mẫu thiết kế liờn quan 15
3.2.2.2. Builder 16
3.2.2.2.1 Vớ dụ 16
3.2.2.2.2 Ứng dụng 16
3.2.2.2.3 Cấu trỳc: 17
3.2.2.2.4 Thành phần 17
3.2.2.2.5 Phối hợp cộng tỏc. 17
3.2.2.2.6 Kết quả 18
3.2.2.2.7 Cài đặt 18
3.2.2.2.8 Cỏc Mẫu quan hệ 19
3.2.2.3. Factory Method 19
3.2.2.3.1 Mục đích 19
3.2.2.3.2 Vớ dụ 19
3.2.2.3.3 Thành phần 20
3.2.2.3.4 Cấu trỳc: 20
3.2.2.3.5 Thành phần: 20
3.2.2.3.6 Kết quả 21
3.2.2.3.7 Cài đặt 21
3.2.2.3.8 Cỏc mẫu liờn quan: 22
3.2.2.4. Prototype 23
3.2.2.4.1 Mục đích 23
3.2.2.4.2 Vớ dụ 23
3.2.2.4.3 Kết quả 24
3.2.2.4.4 Cấu trỳc 25
3.2.2.4.5 Thành phần : 25
3.2.2.4.6 Phối hợp cộng tỏc 25
3.2.2.4.7 Kết qủa 25
3.2.2.4.8 Cài đặt 26
3.2.2.4.9 Cỏc mẫu liờn quan 26
3.2.3. Singleton 26
3.2.3.1. Mục đích 26
3.2.3.2. Vớ dụ 26
3.2.3.3. Ứng dụng 27
3.2.3.4. Cấu trỳc 27
3.2.3.5. Thành phần 27
3.2.3.6. Cộng tỏc: 27
3.2.3.7. Kết quả : 28
3.2.3.8. Cài đặt 28
3.2.3.9. Cỏc mẫu liờn quan 29
3.2.4. Cỏc mẫu cấu trỳc(Structural Mẫu) 30
3.2.4.1. Adapter mẫu 30
3.2.4.1.1 Mục đích 30
3.2.4.1.2 Vớ dụ: 30
3.2.4.1.3 Ứng dụng 31
3.2.4.1.4 Cấu trỳc: 31
3.2.4.1.5 Thành phần: 32
3.2.4.1.6 Cỏc cộng tỏc 32
3.2.4.1.7 Kết quả. 33
3.2.4.1.8 Cài đặt. 33
3.2.4.1.9 Cỏc mẫu liờn quan: 33
3.2.4.2. Bridge mẫu 34
3.2.4.2.1 Mục đích 34
3.2.4.2.2 Vớ dụ 34
3.2.4.2.3 Ứng dụng 35
3.2.4.2.4 Cấu trỳc: 35
3.2.4.2.5 Thành phần: 35
3.2.4.2.6 Một số kết quả thu được khi áp dụng Bridge Error! Bookmark not defined.
3.2.4.2.7 Một số vấn đề cần lưu ý khi sử dụng Brigde mẫu: Error! Bookmark not defined.
3.2.4.2.8 Cỏc mẫu liờn quan 36
3.2.4.3. Composite 37
3.2.4.3.1 Mục đích 37
3.2.4.3.2 Vớ dụ 37
3.2.4.3.3 Ứng dụng 38
3.2.4.3.4 Cấu trỳc: 38
3.2.4.3.5 Thành phần 39
3.2.4.3.6 Kết quả. 40
3.2.4.3.7 Phối hợp cộng tỏc 40
3.2.4.3.8 Cài đặt 40
3.2.4.3.9 Cỏc mẫu liờn quan: 41
3.2.4.4. Decorator 41
3.2.4.4.1 Mục đích 41
3.2.4.4.2 Ứng dụng 41
3.2.4.4.3 Cấu trỳc: 42
3.2.4.4.4 Thành phần: 42
3.2.4.4.5 Phối hợp cộng tỏc. 42
3.2.4.4.6 Kết quả. 43
3.2.4.4.7 Cài đặt 43
3.2.4.4.8 Cỏc mẫu liờn quan: 43
3.2.4.5. Facade 43
3.2.4.5.1 Mục đích 43
3.2.4.5.2 Vớ dụ 43
3.2.4.5.3 Ứng dụng 44
3.2.4.5.4 Cấu trỳc 45
3.2.4.5.5 Thành phần 45
3.2.4.5.6 Phối hợp cộng tỏc 45
3.2.4.5.7 Kết quả 45
3.2.4.5.8 Cài đặt 46
3.2.4.5.9 Cỏc mẫu liờn quan 47
3.2.4.6. Flyweight mẫu 47
3.2.4.6.1 Mục đích 47
3.2.4.6.2 Ứng dụng 47
3.2.4.6.3 Cấu trỳc: 48
3.2.4.6.4 Thành phần: 48
3.2.4.6.5 Phối hợp cộng tỏc. 49
3.2.4.6.6 Kết quả. 49
3.2.4.6.7 Cài đặt 50
3.2.4.6.8 Cỏc mẫu liờn quan: 50
3.2.4.7. Proxy 51
3.2.4.7.1 Mục đích 51
3.2.4.7.2 vớ dụ 51
3.2.4.7.3 Ứng dụng 52
3.2.4.7.4 Cấu trỳc: 52
3.2.4.7.5 Thành phần: 53
3.2.4.7.6 Phối hợp cộng tỏc 53
3.2.4.7.7 Kết quả. 53
3.2.4.7.8 Cài đặt 54
3.2.4.7.9 Những mẫu liờn quan: 54
3.2.5. Các mẫu hoạt động (BEHAVIOR Pattern) 56
3.2.5.1. CHAIN OF RESPONSIBILITY. 57
3.2.5.1.1 Mục đích 57
3.2.5.1.2 Ứng dụng: 57
3.2.5.1.3 Cấu trỳc: 58
3.2.5.1.4 Thành phần: 58
3.2.5.1.5 Kết quả 59
3.2.5.1.6 Cài đặt 59
3.2.5.1.7 Mẫu liờn quan: 59
3.2.5.2. COMMAND. 59
3.2.5.2.1 Mục đích 59
3.2.5.2.2 Ứng dụng 59
3.2.5.2.3 Thành phần: 60
3.2.5.2.4 Cộng tỏc: 60
3.2.5.2.5 Kết quả: 61
3.2.5.2.6 Cài đặt 61
3.2.5.2.7 Cỏc mẫu liờn quan: 61
3.2.5.3. INTERPRETER 61
3.2.5.3.1 Mục đích 61
3.2.5.3.2 Ứng dụng 61
3.2.5.3.3 Cấu trỳc: 62
3.2.5.3.4 Thành phần: 62
3.2.5.3.5 Cộng tỏc: 63
3.2.5.3.6 Kết quả 63
3.2.5.3.7 Cài đặt 64
3.2.5.3.8 Cỏc mẫu liờn quan: 64
3.2.5.4. ITERATOR 64
3.2.5.4.1 Mục đích 64
3.2.5.4.2 Ứng dụng 64
3.2.5.4.3 Cấu trỳc: 65
3.2.5.4.4 Thành phần: 65
3.2.5.4.5 Cộng tỏc: 65
3.2.5.4.6 Kết quả 65
3.2.5.4.7 Cài đặt 66
3.2.5.4.8 Cỏc mẫu liờn quan: 66
3.2.5.5. MEDIATOR. 66
3.2.5.5.1 Mục đích 66
3.2.5.5.2 Ứng dụng 67
3.2.5.5.3 Cấu trỳc: 67
3.2.5.6. MEMENTO. 68
3.2.5.6.1 Mục đích 68
3.2.5.6.2 Ứng dụng 68
3.2.5.6.3 Cấu trỳc: 68
3.2.5.6.4 Thành phần: 68
3.2.5.6.5 Cộng tỏc: 69
3.2.5.6.6 Kết quả 69
3.2.5.6.7 Cài đặt 69
3.2.5.6.8 Cỏc mẫu liờn quan: 69
3.2.5.7. OBSERVER. 70
3.2.5.7.1 Mục đích 70
3.2.5.7.2 Ứng dụng 70
3.2.5.7.3 Kết quả 70
3.2.5.7.4 Cài đặt 70
3.2.5.8. STATE. 71
3.2.5.8.1 Mục đích 71
3.2.5.8.2 Ứng dụng 71
3.2.5.8.3 Cấu trỳc: 71
3.2.5.8.4 Thành phần: 72
3.2.5.8.5 Kết qủa 72
3.2.5.8.6 Cài đặt 72
3.2.5.9. STRATEGY. 72
3.2.5.9.1 Mục đích 72
3.2.5.9.2 Ứng dụng 72
3.2.5.9.3 Kết quả. 73
3.2.5.9.4 Cài đặt 73
3.2.5.10. TEMPLATE. 73
3.2.5.10.1 Mục đích 73
3.2.5.10.2 Vớ dụ 74
3.2.5.10.3 Ứng dụng 74
3.2.5.10.4 Cấu trỳc: 74
3.2.5.10.5 Thành phần: 75
3.2.5.10.6 Phối hợp cộng tỏc 75
3.2.5.10.7 Kết quả 75
3.2.5.10.8 Cài đặt 76
3.2.5.11. VISITOR. 76
3.2.5.11.1 Mục đích 76
3.2.5.11.2 Ứng dụng 76
3.2.5.11.3 Kết quả 76
3.2.5.11.4 Cài đặt 77
3.3. Giới thiệu nội dung dự ỏn 77
Bạn đang xem trước 20 trang tài liệu Tìm hiểu tình hình phát triển công nghệ phần mềm và sử dụng mẫu thiết kế, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
c lớp, tạo sự mềm dẻo khi thao tỏc với cỏc lớp, Khụng nhất thiết là tạo ra thể hiện duy nhất. Mẫu Singleton cho phộp tạo nhiều hơn một thể hiện, hơn nữa với hướng tiếp cận như vậy cú thể điều khiển được số lượng thể hiện mà ứng dụng sử dụng. Chỉ mỗi hàm cho phộp truy xuất đến thể hiện của Singleton là phải thay đổi.
Cài đặt
Đảm bảo một trường hợp duy nhất. Cỏch chung nhất để thực hiện điều này là ẩn đi hàm tạo và thể hiện dưới dạng một hàm của lớp( hoặc là một chức năng tĩnh hoặc một class method). Điều đú đảm bảo chỉ một duy nhất một thể hiện được tạo ra, hàm đú truy xuất đến biến cú thể hiện duy nhất và nú chắc chắn rằng biến đú được khởi tạo với thể hiện duy nhất truúc khi trả về giỏ trị của nú.
Lớp Singleton được khai bỏo như sau:
class Singleton {
public:
static Singleton* Instance():
protect:
Singleton();
private:
static Singleton* _instance;
};
Chức năng của việc cài đặt trong này là:
Singleton*Singleton:_ instance = 0;
Singleton* Singleton:: Instance(){
if (_instance == 0) {
_instance = new Singleton;
}
return _ instance;
}
Từ đoạn mó cài đặt và chức năng của lớp Singleton, đó nờu rừ được kết quả khi ỏp dụng mẫu Singleton vào trong thiết kế. Nú kiểm soỏt được truy xuất tới trường hợp duy nhất và giảm thiểu khụng gian tờn, cũng như cho phộp số lượng biến mà nú thể hiện.
Phõn lớp con trong lớp Singleton.
Cỏc mẫu liờn quan
Một số mẫu cú thể được thực hiện bằng việc sử dụng Singleton mẫu. (Abstract factory, Builder, và Prototype).
Kết luận: Như vậy cú hai cỏch để tham số hoỏ hệ thống bởi cỏc lớp đối tượng nú tạo ra. Cỏch một là sắp xếp cỏc lớp tạo đối tượng, việc này cho phộp sử dụng mẫu Factory Method. Mặt hạn chế chớnh của bước này là nú cú thể yờu cầu tạo một lớp con mới để thay đổi lớp của sản phẩm. Sự thay đổi này cú thể là trường hợp thay thế.
Một mặt khỏc để tham số hoỏ hệ thống là dựa trờn nhiều thành phần kết cấu đối tượng. Xỏc định một đối tượng chức năng đối với việc nhận biết lớp của sản phẩm đối tượng, và nú làm cho nú tham số hoỏ hệ thống. Đõy là khớa cạnh chủ yếu của Abstract Factory, Builder và Prototype. Ba mẫus này liờn quan đến việc tạo một đối tượng factory mới mà tớnh năng của nú là để tạo ra cỏc đối tượng sản phẩm. Abstract Factory cú đối tượng factory tạo đối tượng thuộc một số lớp.
Trong khung soạn thảo, Factory method là cỏch dễ nhất để sử dụng đầu tiờn. Nú rất dễ để xỏc định một lớp con mới.
Cỏc mẫu cấu trỳc(Structural Mẫu)
Cỏc mẫu cấu trỳc được quan tõm về cỏc lớp và cỏc đối tượng như thế nào để hợp thành một cấu trỳc lớn hơn. Cỏc mẫu lớp cấu trỳc đều dựng tớnh kế thừa để tạo giao diện hoặc thực hiện. Structural đối tượng mụ tả cỏc phương phỏp để tạo cỏc đối tượng thu được nhiều chức năng mới. Giữa cỏc mẫu cấu trỳc cú cỏc thành phần giống nhau, đặc biệt là thành phần tham gia và cộng tỏc của chỳng. Điều này là cú thể vỡ cỏc mẫu cấu trỳc dựa trờn một bộ nhỏ giống nhau của cỏc cơ chế ngụn ngữ về mó cấu trỳc và sự vật.
Cú thể chia chỳng thành 2 loại:
Structural class pattern: Sử dụng tớnh kế thừa để tạo cỏc giao diện hay cỏc thực hiện: vớ dụ, ta thừa kế trộn 2 hay nhiều lớp thành một lớp. Lớp tạo ra chứa tất cả cỏc thuộc tớnh của cỏc lớp cha của nú.
Structural object pattern: là phương phỏp để hợp cỏc đối tượng để thực hiện chức năng mới.
Trong cỏc mẫu cấu trỳc cú cỏc mẫu mà tụi đó nghiờn cứu sau:
Adapter mẫu
Bridge mẫu
Composite mẫu
Decorator mẫu
Facade mẫu
Flyweight mẫu
Proxy mẫu
Adapter mẫu
Mục đớch
Chuyển đổi giao diện của một lớp sang giao diện khỏc mà client muốn.
Cho phộp cỏc lớp cú giao diện khụng tương thớch làm việc với nhau.
Vớ dụ:
Một soạn thảo đồ hoạ, giỳp người dựng cú thể vẽ hoặc sắp xếp cỏc thành phần đồ hoạ như là đường thẳng, text, đa giỏc... vào cỏc tranh vẽ hoặc cỏc biểu đồ. Vấn đề trừu tượng chớnh của soạn thảo vẽ ở đõy là đối tượng đồ hoạ, hỡnh dỏng cú thể tự sửa đổi được. Giao diện cho cỏc vấn đề đồ hoạ ở đõy được định nghĩa bởi một lớp trừu tượng gọi là Shape. Soạn thảo vẽ định nghĩa một lớp con của Shape cho từng loại như LineShape cho đường kẻ, PolygonShape cho đa giỏc...
Cỏc lớp ứng với cỏc hỡnh dỏng hỡnh hoạ cơ bản như LineShape, PolygonShape là đơn giản hơn trong việc cài đặt vỡ cỏc khả năng vẽ và sửa đổi của chỳng là hạn chế. Nhưng một lớp con TextShape cho phộp hiển thị và sửa đổi text rất khú cài đặt, do việc sửa đổi text đến cỏc phộp cập nhật màn hỡnh quản lý bộ đệm phức tạp.
Trong khi đú, bộ dụng cụ trong giao diện người dựng cung cấp lớp TextView cho hiển thị và soạn thảo. Ở đõy ta muốn sử dụng lại TextView để thực hiện TextShape, nhưng dụng cụ khụng được thiết kế với Shape nờn khụng thể sử dụng đối tượng TextView và TextShape một cỏch tớch hợp.
Như vậy yờu cầu ở đõy đặt ra là làm thế nào để cỏc lớp sẵn cú và khụng liờn quan như TextView và TextShape cú thể làm việc với nhau trong khi giao diện khụng tương thớch với nhau.
Một giải phỏp đặt ra là cú thể thay đổi lớp TextView để cho nú phự hợp với giao diện Shape, nhưng sẽ khụng thực hiện nếu khụng cú mó nguồn trong bộ dụng cụ. Chớnh vỡ thế, thay vỡ định nghĩa TextShape để thớch ứng với giao diện TextView với giao diện Shape. Chỳng ta cú thể định nghĩa điều này theo 2 cỏch: bằng cỏch kế thừa giao diện Shape và thực hiện TextView hoặc kết nối thể hiện TextView vào một TextShape và cài đặt TextShape dưới dạng giao diện của TextView. Cả hai phương phỏp này tương ứng với hai phiờn bản của mẫu Adapter: class Adapter pattern, và Object Adapter Pattern.
Ứng dụng
Muốn sử dụng một lớp hiện hành và giao diện của nú nhưng khụng phự hợp với cỏi bạn cần.
Muốn tạo một lớp sử dụng lại mà cỏc kết nối với cỏc lớp khụng liờn quan, khụng biết trước, nghĩa là cỏc lớp khụng cần phải cú giao diện tương thớch.
Cần sử dụng một số cỏc lớp con hiện hành, nhưng nú được ứng dụng trong thực tế để điều hợp giao diện của chỳng bằng việc phõn lớp. Một đối tượng Adapter cú thể điều hợp giao diện của lớp cha.
Cấu trỳc:
Phương phỏp I: Một lớp adapter sử dụng tớnh kế thừa để thớc ứng một giao diện tới giao diện khỏc.
Client
Target
Request()
Adapter
Request()
Adaptee
SpecificRequest()
Return uniqueInstance
(Implementation)
Một đối tượng adapter dựa trờn tổ hợp đối tượng.
Client
Target
Request()
Adapter
Request()
Adaptee
SpecificRequest()
Return uniqueInstance
adaptee
Thành phần:
Target : định nghĩa giao diện domain-specific mà Client sử dụng.
Client : Cộng tỏc với cỏc đối tượng tuõn theo giao diện Target .
Adaptee : Định nghĩa một giao diện cú sẵn cần thiết cho việc thớch nghi.
Adapter:Giao diện này cần phải sửa đổi cho phự hợp với giao diện Target.
Cỏc cộng tỏc
Client gọi cỏc lệnh trong thể hiện Adapter. Từ đú, adapter gọi cỏc lệnh Adaptee để thực hiện yờu cầu.
Kết quả.
Class Adapter và object Adapter cú nhiều yếu tố để đỏnh giỏ khỏc nhau để đạt được hiệu quả tốt nhất. Việc làm cho Adapter tương thớch với Target được làm cho một lớp cụ thể. Dẫn đến, một lớp adapter sẽ khụng hoạt động khi chỳng ta muốn điều hợp một lớp và cỏc lớp con của nú.
Điều hợp Adapter tới Target bằng cỏch chuyển đến lớp Adapter cụ thể.
Cho phộp Adapter ghi đố một số hoạt động của Adapter, từ khi Adapter là một lớp con của Adaptee.
Giới thiệu duy nhất một đối tượng, và khụng cần điểm giỏn tiếp nào để nhận đến adaptee.
Một đối tượng adapter:
Cho phộp một adapter làm việc với nhiều adaptee.
Làm cho khú ghi đố cỏc hàm của Adaptee hơn, nú yờu cầu tạo lớp con Adaptee và bắt Adapter tham chiếu đến lớp con chứ khụng phải là bản thõn Adaptee.
Một số vấn đề khi sử dụng Adapter mẫu:
Adapter biến đổi trong một lượng cụng việc chỳng thực hiện để tương thớch Adatee tới giao diện Target. Adapter là khụng trong suốt với client.
Cài đặt.
Cài đặt lớp Adater trong C++ : Adapter cú thể kế thừa chung từ Target và riờng từ Adaptee. Do đú Adapter là một dạng con thuộc Target chứ khụng thuộc Adaptee.
Sử dụng cỏc thao tỏc trừu tượng.
Sử dụng cỏc đối tượng thành phần.
Cỏc Adapter đó được tham số hoỏ.
Cỏc mẫu liờn quan:
Bridge cú cấu trỳc tương tự như một đối tượng adapter, nhưng Bridge cú nội dung khỏc: Nú được hiểu là để phõn chia một giao diện từ việc thực hiện của nú nờn cú thể biến đổi rừ ràng và độc lập. Một adapter được hiểu là để thay đổi một giao diện của đối tượng sẵn cú.
Decorator tăng cường đối tượng khỏc mà khụng cần thay đổi giao diện của nú. Một Decorator vỡ thế sẽ trong suốt hơn đối với ứng dụng hơn là một adapter. Từ đú đưa ra kết quả, Decorator hỗ trợ cỏc thành phần đệ quy, mà nú khụng cú hỗ trợ cho một adapter trong suốt.
Proxy định nghĩa một biểu diễn hoặc thay thế cho đối tượng khỏc và khụng thay đổi giao diện của nú.
Bridge mẫu
Mục đớch
Phõn tỏch việc trừu tượng hoỏ khỏi cỏc cài đặt của chỳng để cho cả hai cú thể biến đổi một cỏch độc lập.
Vớ dụ
Việc cài đặt của vấn đề trừu tượng hoỏ trong cửa sổ Window trong bộ dụng cụ giao diện người dựng, cho phộp cỏc user cú thể ghi cỏc ứng dụng làm việc trong cả hai hệ thống X Window System và Presentation Manager. Sử dụng tớnh kế thừa, chỳng ta định nghĩa một lớp Window, cỏc lớp con XWindow và PMWindow cài đặt giao diện Window cho cỏc nền khỏc nhau.
Nhưng chớnh phương phỏp này cú hai điều hạn chế lớn nhất, đú là:
Khụng thuận tiện khi mở rộng Window để bao hàm cỏc dạng khỏc của window hoặc cỏc nền mới. Tưởng tượng là một lớp con IconWindow của Window chỉ ra bởi cỏc icon trong Window. Để hỗ trợ Icon Window cho cả hai nền này, chỳng ta cài đặt 2 lớp mới, XIconWindow và PMIconWindow. Trong trường hợp xấu nhất, chỳng ta sẽ định nghĩa 2 lớp cho mọi cửa sổ. Như vậy cần một nền thứ 3 yờu cầu lớp con Window mới cho tất cả cỏc dạng cửa sổ.
Làm cho mó nguồn Client độc lập với nền. Bất kỳ khi nào client tạo một cửa sổ, nú khỏi tạo một lớp thực hiện, mà nú chỉ ra cài đặt. Trong trường hợp này, ạo một đối tượng XWindow kết nối với Window cho việc cài đặt X Window, tạo mó nguồn client độc lập với cài đặt X Window, chớnh vỡ thế, nú rất khú để chuyển mó nguồn client tới cỏc nền khỏc.
Khi ỏp dụng mẫu Bridge, nú lập địa chỉ những vấn đề này bằng cỏch đặt Window và cài đặt của nú trong biểu đồ lớp phõn chia. Chỉ cú một lớp kế thừa cho cỏc cửa sổ giao diện (Window, IconWindow, TransientWindow) và biểu đồ lớp phõn chia cho cỏc cài đặt cửa sổ chỉ ra nền, coi WindowImp là gốc. Lớp con XWindowImp cung cấp một cài đặt dựa trờn X Window System.
Tất cả cỏc lớp con Window được cài đặt trong cỏc thao tỏc ảo từ giao diện WindowImp. Điều này tỏch riờng cỏc cửa sổ khỏi cỏc cài đặt. Mối quan hệ gió Window và WindowImp như một cầu nối, do nú bắc cầu giữa vấn đề trừu tượng này và việc cài đặt của nú, cho phộp chỳng biến đổi một cỏch độc lập.
Ứng dụng
Cần trỏnh một kết nối cố định giữa vấn đề ảo và việc cài đặt của nú.
Cả vấn đề ảo và việc cài đặt của nú cú thể mở rộng việc phõn lớp con. Trong trường hợp này Bridge cho phộp bạo tổ hợp cỏc vấn đề ảo và cỏc cài đặt khỏc nhau và mở rộng chỳng một cỏch độc lập.
Thay đổi cài đặt của một vấn đề ảo cú thể khụng ảnh hưởng đến client; cú nghĩa là mó của chỳng khụng cần phải dịch lại.
Muốn ẩn việc thực hiện của vấn đề ảo hoàn toàn từ cỏc client.
Muốn dựng chung cài đặt giữa nhiều đối tượng, và điều này cú thể được ẩn từ client.
Cấu trỳc:
Client
Abstraction
Operation()
Abstraction
Operation()
RelinedAbstraction
imp->OperationImp()
ConcreteimplementorA
OperationImp()
ConcreteimplementorB
OperationImp()
Thành phần:
Abstraction:
Định nghĩa một giao diện trừu tượng.
Duy trỡ một tham chiếu tới một đối tượng của dạng Implementor.
RefinedAbstraction :
Mở rộng một giao diện được định nghĩa bởi Abstraction.
Implementor:
Định nghĩa một giao diện để cài đặt cỏc lớp. Giao diện này khụng cần phải thực hiện một cỏch chớnh xỏc tới giao diện của Abstraction; thực tế hai giao diện cú quỏ nhiều điểm khỏc nhau. Điển hỡnh giao diện Implementor cung cấp cỏc thao tỏc cơ bản, và Abstraction định nghĩa cỏc thao tỏc mức cao dựa trờn những ưu tiờn này.
ConcretImplementor:
Thực hiện giao diện Implementor và định nghĩa cài đặt cụ thể. của nú.
Kết quả
Phõn tỏch giao diện và cài đặt. Do việc thực hiện của vấn đề ảo cú thể được định dạng tại thời gian chạy. Phõn tỏch được Abstraction và Implementation cũng loại bỏ được sự phụ thuộc của thời gian biờn dịch vào cài đặt, thay đổi việc cài đặt lớp khụng yờu cầu phải biờn dịch lại
lớp Abstraction và cỏc client của nú.
Khả năng mở rộng được cải thiện. Cú thể mở rộng biểu đồ Abstraction và Implementation một cỏch độc lập.
Ẩn đi cỏc chi tiết cài đặt từ Client.
Cài đặt
Trong quỏ trỡnh thực hiện khi ỏp dụng Bridge mẫu vào, sẽ phỏt sinh một số vấn đề sau :
Chỉ cú một Implementor.
Tạo đỳng đối tượng Implementation
Sử dụng chung Implementor.
Sử dụng tớnh đa kế thừa.
Cỏc mẫu liờn quan
Abstract Factory cú thể tạo và cấu hỡnh một phần Bridge.
Adapter mẫu lớn hơn toward việc tạo cỏc lớp khụng phụ thuộc làm việc cựng nhau. Nú thường được ỏp dụng vào hệ thống sau khi chỳng đó được thiết kế. Bridge, trong một khớa cạnh nào đú, được sử dụng up-front trong thiết kế để cho phộp cỏc trừu tượng hoỏ và việc cài đặt biến đổi một cỏch độc lập.
Composite
Mục đớch
Tạo nờn một cỏch tổng thể cỏc đối tượng thành cấu trỳc cõy để biểu diễn cỏc hệ thống part-whole. Composite cho phộp cỏc client sử dụng cỏc đối tượng và cỏc thành phần riờng lẻ của cỏc đối tượng thống nhất.
Vớ dụ
Ứng dụng đồ hoạ như soạn thảo vẽ và hệ thống biểu diễn dưới dạng bản đồ cho phộp người dựng xõy dựng một biểu đồ phức tạp từ những thành phần đơn giản. Người dựng cú thể nhúm cỏc thành phần để tổ chức thành thành phần lớn hơn. Một cỏch thực hiện đơn giản là cú thể định nghĩa cỏc lớp cho cỏc mẫu đồ hoạ như Text, Line, và cỏc lớp cú cỏc hoạt động này.
Khi sử dụng phương phỏp này, sẽ xuất hiện một vấn đề: Mó nguồn mà sử dụng cỏc lớp này phải xử lý được màu gốc và cỏc đối tượng trong nội dung đú một cỏch khỏc nhau. Để phõn biệt những đối tượng này sẽ làm cho hệ thống phức tạp hơn. Mẫu Composite mụ tả làm thế nào để sử dụng thành phần đệ quy nờn cỏc client khụng cần phải tạo sự khỏc biệt đú.
Nhưng vấn đề chủ yếu ở đõy là: một lớp ảo biểu diễn cả gốc và nội dung của nú. Đối với hệ thống đồ hoạ, lớp này là Graphic, Graphic khai bỏo cỏc thao tỏc Draw, dựng để chỉ ra cỏc đối tượng đồ hoạ. Nú cũng khai bỏo cỏc thao tỏc mà tất cả cỏc thành phần của nú sử dụng chung, vớ dụ như thao tỏc truy xuất và quản lớ cỏc lỏ con của nú.
Cỏc lớp con như là Line, Rectangle, và Text, định nghĩa cỏc đối tượng đồ hoạ cơ bản. Những lớp này cài đặt thao tỏcDraw để vẽ cỏc đường, hỡnh chữ nhật, và dạng text, từ đú cỏc đối tượng đồ hoạ cơ bản khụng cú cỏc đồ hoạ con, khụng cú lớp con nào trong số đú cài đặt cỏc thao tỏc con- quan hệ.
Do lớp Picture định nghĩa một kết tập với đối tượng Graphic, nờn Picture cài đặt Draw để gọi Draw trong cỏc con của nú, và nú cài đặt cỏc thao tỏc con-quan hệ. Do giao diện Picture tương thớch với với giao diện Graphic, đối tượng Picture cú thể tổ hợp cỏc đệ quy Picture khỏc.
aPicture
aLine
aPicture
aText
aLine
aRectangle
aRectangle
Ứng dụng
Muốn biểu diễn cỏc biểu đồ part-whole của cỏc đối tượng.
Muốn client cú thể bỏ qua sự khỏc nhau giữa cỏc composition của cỏc đối tượng và đối tượng riờng lẻ. Client sẽ vận dụng tất cả cỏc đối tượng trong cấu trỳc thành phần một cỏch đồng bộ.
Cấu trỳc:
Client
Component
Operation
Add(Component)
Remove(Component)
GetChild(int)
Composite
Operation()
Add(Component)
Remove(Component)
GetChild(int)
Leal
Operation()
For all in children
g.Operation();
Cỏc đối tượng typically Composite cú thể được quan sỏt dưới dạng:
aComposite
aleaf
aLeaf
aComposite
aLeaf
aLeaf
aleaf
aleaf
Thành phần
Component:
Khai bỏo một giao diện cho cỏc đối tượng trong composition
Cài đặt mặc định hàm cho giao diện chung tới tất cả cỏc lớp con của nú.
Khai bỏo một giao diện cho việc truy xuất và quản lớ cỏc thành phần con của nú.
Định nghĩa một giao diện cho việc truy xuất một thành phần cha trong cấu trỳc đệ quy, và cài đặt nú nếu nú thớch hợp.
Leaf:
Biểu diễn cỏc đối tượng lỏ trong thành phần. Một lỏ khụng cú con nào.
định nghĩa hoạt động của cỏc đối tượng ưu tiờn trong thành phần.
Composite
Định nghĩa hoạt động cho cỏc thành phần chứa cỏc lớp con.
Lưu cỏc thành phần con.
Cài đặt cỏc thao tỏc con-quan hệ trong giao diện Component.
Client.
vận dụng cỏc đối tượng vào thành phần thụng qua giao diện Component.
Kết quả.
Định nghĩa cỏc biểu đồ lớp bao hàm cả cỏc đối tượng ưu tiờn và cỏc đối tượng thành phần. Đối tượng ưu tiờn cú thể được kết cấu vào nhiều đối tượng phức tạp. Bất cứ khi nào mó client muốn một đối tượng ưu tiờn, nú cũng cú thể sử dụng đối tượng thành phần.
Tạo client đơn giản. Client cú thể xử lý cỏc cấu trỳc thành phần và cỏc đối tượng riờng lẻ một cỏch khụng đồng bộ.
Dễ dàng thờm vào cỏc dạng mới của cỏc thành phần.
Cú thể làm cho thiết kế tổng quỏt hơn.
Phối hợp cộng tỏc
Cỏc client sử dụng giao diện lớp Component để tương thớch với cỏc đối tượng trong cấu trỳc thành phần. Nếu nơi nhận là nỳt Leaf, thỡ cỏc yờu cầu được nắm giữ một cỏch trực tiếp. Nếu nơi nhận là Composite, thỡ cỏc yờu cầu thường được gửi tới cỏc thành phần con của nú, cỏc thao tỏc thờm vào trước hoặc sau khi gửi tới và xử lý.
Cài đặt
Đưa ra tham chiếu cha : Duy trỡ cỏc tham chiếu từ cỏc thành phần con tới cha của chỳng cú thể làm đơn giản hoỏ việc thực hiện và quản lớ của cấu trỳc thành phần.
Chia sẻ thành phần : Sử dụng chung cỏc thành phần thường cú lợi hơn
Tối đa hoỏ giao diện Component.
Khai bỏo cỏc thao tỏc quản lớ con : Mặc dự lớp Composite thực hiện cỏc thao tỏc Add và Remove đối với con, một vấn đề quan trọng trong Composite là những lớp nào khai bỏo những thao tỏc này trong biểu đồ lớp Composite. Một quyết định bao hàm sự cõn bằng giữa độ an toàn và trong suốt là định nghĩa giao diện quản lớ con tại gốc của biểu đồ lớp, đồng thời trong suốt đối với bạn.
Component cú thể thực hiện được một danh sỏch cỏc thành phần khụng?
Nắm giữ để cải thiện việc cài đặt
Ai cú thể xoỏ cỏc thành phần.
Đõu là cấu trỳc dữ liệu tốt nhất cho việc lưu trữ Component ?.
Cỏc mẫu liờn quan:
Thụng thường kết nối thành phần – cha được dựng cho Chain of Responsibility.Decorator thường được dựng với Composite. Khi cỏc decorator và composite được sử dụng cựng nhau, chỳng sẽ cú lớp nỳt cha chung. Nờn cỏc decorator sẽ phải hỗ trợ giao diện Component với cỏc thao tỏc như là Add, Remove, GetChild.Flyweight cho phộp bạn sử dụng cỏc thành phần, nhưng chỳng khụng yờu cầu xa hơn đến cỏc cha của chỳng.Iterator cú thể được sử dụng để chuyển đổi thành phần. Visitor khoanh vựng cỏc thao tỏc và hoạt động cú thể phõn phối tới cỏc lớp Composite và Leaf.
Decorator
Mục đớch
Gắn cỏc chức năng thờm cú thể thờm vào một đối tượng một cỏch động. Decorator cung cấp một lựa chọn hiệu quả để phõn lớp cho việc mở rộng chức năng.
Ứng dụng
Thờm cỏc chức năng tới cỏc đối tượng riờng lẻ một cỏch động và trong suốt, khụng cần ảnh hưởng tới cỏc đối tượng khỏc.
Sử dụng Decorator đối với cỏc nhiệm vụ mà cú thể được rỳt lại.
Sử dụng Decorator khi việc mở rộng bằng phõn lớp là khụng thực tế. Thỉnh thoảng một số lớn cỏc mở rộng độc lập là cú thể và tạo ra một phỏt triển nhanh của cỏc lớp con để hỗ trợ mọi kết nối. Hoặc một định nghĩa lớp cú thể được ẩn đi hoặc nếu khụng khụng cú giỏ trị với việc phõn lớp.
Cấu trỳc:
Component
Creation()
ConcreteDecoratorB
Operation()
AddedBehavior()
ConcreteComponent
Operation
Decocrator
Creation()
Component->Operation()
ConcreteDecoratorA
Operation()
addedState
Decorator::Operation():
AddedBehavior():
Thành phần:
Component:
Định nghĩa một giao diện cho cỏc đối tượng mà cú chức năng được thờm vào chỳng một cỏch động.
ConcreteComponent
Định nghĩa một đối tượng mà cỏc chức năng cú thể được gắn lại
Decorator
Duy trỡ một tham chiếu tới đối tượng Component và định nghĩa một giao diện mà phự hợp với giao diện Component.
ConcreteDecorator
Thờm vào cỏc chức năng tới cỏc thành phần.
Phối hợp cộng tỏc.
Decorator hướng cỏc yờu cầu tới đối tượng Component của chỳng. Nú cú thể mang tớnh lựa chọn để thực hiện cỏc thao tỏc thờm vào trước và sau khi hướng tới cỏc yờu cầu.
Kết quả.
Hiệu quả hơn đối với kế thừa tĩnh.
Trỏnh cỏc lớp mức cao trong biểu đồ.
Một decorator và component của nú khụng đồng nhất.
Nhiều đối tượng nhỏ.
Cài đặt
Giao diện phự hợp.
Khụng chỳ trọng lớp Decorator trừu tượng.
Giữ cỏc lớp thành phần ớt quan trọng.
Thay đổi lớp vỏ của đối tượng ngược lại với thay đổi lớp lừi trong nú.
Cỏc mẫu liờn quan:
Adapter: Một Decorator là khỏc biệt với một adapter trong đú, decorator chỉ thay đổi cỏc nhiệm vụ đối tượng, khụng thay đổi giao diện của nú. Một adapter sẽ đưa một đối tượng cho một giao diện mới một cỏch đầy đủ.
Composite: Một Decorator cú thể nhỡn nhận như một thành phần suy giảm với chỉ một thành phần.
Strategy: Một decorator cho phộp bạn thay đổi skin của một đối tượng. một chiến lược cho phộp bạn thay đổi bờn trong của nú. Đú là những phương phỏp lựa chọn của việc thay đổi một đối tượng.
Facade
Mục đớch
Đưa ra một giao diện đồng nhất thay cho một tập cỏc giao diện trong hệ thống con. Định nghĩa một giao diện mức cao giỳp đơn giản hoỏ trong việc sử dụng hệ thống con.
Vớ dụ
Khi định dạng một hệ thống sang nhiều hệ thống con, mục đớch chớnh là làm giảm độ phức tạp, tối thiểu hoỏ hệ thống, giỳp cho người phỏt triển nhỡn từ đơn lẻ đến tổng thể.
Một phương phỏp để đạt được hiệu quả là đưa ra một đối tượng bao quỏt đơn nhất, cung cấp một giao diện đơn giản để nhỡn được chức năng tổng thể của một hệ thống con.
Vớ dụ, trong mụi trường lập trỡnh, cỏc ứng dụng truy xuất đến hệ thống con biờn dịch của nú, chứa cỏc lớp như Scanner, Parser, ProgramNode, BytecodeStream và ProgramNodeBuilder cài đặt compiler. Một số ứng dụng riờng cần truy cập những lớp này một cỏch trực tiếp. Nhưng hầu hết cỏc client của một compiler khụng chi tiết như phõn tớch cỳ phỏp hoặc bộ sinh mó nguồn. Nú chỉ đơn thuần dịch phần ớt mó. Như vậy, giao diện cú hiệu quả mạnh nhhung ở mức thấp trong hệ thống con biờn dịch và chỉ kết nối phần nhiệm vụ của chỳng.
Để cung cấp mức cao mà cú thể che cho client khỏi cỏc lớp này, hệ thống con biờn dịch cũng bao hàm một lớp Compiler, lớp này định nghĩa một giao diện đồng nhất chức năng của compiler. Lớp Compiler hoạt động giống như một giao diện tổng quỏt, ở đõy là facade; Nú đưa ra một giao diện đơn giản và đơn hỡnh cho hệ thống con compiler. Nú kết hợp cỏc lớp này để cài dặt chức năng compiler mà khụng cần ẩn đi hoàn toàn về chỳng. Ở đõy, Compiler facade làm đơn giản hơn cho hầu hết cỏc nhà lập trỡnh khụng cần ẩn đi cỏc cụng việc và chức năng ở mức thấp.
Ứng dụng
Cần cung cấp một giao diện đơn giản tới hệ thống con phức tạp. Làm cho hệ thống con cú khả năng sử dụng lại được và dễ dàng thay đổi thớch nghi, nhưng cũng khú hơn khi sử dụng cho client mà khụng cần thay đổi chỳng. Faỗade cú thể cung cấp một khung nhỡn mặc định đơn giản đơn giản của hệ thống con khi phự hợp cho hầu hết cỏc client. Chỉ cú cỏc client cần nhiều tuỳ biến sẽ cần phải quan sỏt rộng ra faỗade.
Cú một số sự phụ thuộc giữa cỏc client và cỏc lớp thực hiện của khỏi niệm trừu tượng. Đưa ra một faỗade để phõn tỏch hệ thống con từ client và cỏc hệ thống con khỏc, từ đú, phỏt triển hệ thống con một cỏch độc lập và hữu hiệu.
Muốn phõn tầng hệ thống con. Sử dụng faỗade để định nghĩa một điểm đầu vào tới từng mức hệ thống con. Nếu cỏc hệ thống con là phụ thuộc, chỳng cú thể đơn giản hoỏ sự phụ thuộc giữa chỳng bằng cỏch tạo kết nối chỳng với từng phần riờng lẻ khỏc thụng qua faỗade của chỳng.
Cấu trỳc
Facade
Subsystem classes
Thành phần
Faỗade:
Biết cỏc lớp hệ thống con nào hoạt động theo yờu cầu.
Client yờu cầu cỏc đối tượng của hệ thống con phải phự hợp.
Subsystem classes:
Thực hiện chức năng hệ thống con.
Chịu sự phõn cụng cụng việc của Faỗade Object.
Phối hợp cộng tỏc
Client giao tiếp với hệ thống con bằng cỏch gửi cỏc yờu cầu tới Faỗade, và Faỗade này sẽ hướng client đến đối tượng hệ thống con phự hợp. Mặc dự, cỏc đối tượng hệ thống con thực hiện cụng việc thực nhưng faỗade cú thể thực hiện cụng việc của chớnh nú để chuyển giao diện của nú tới giao diện của hệ thống con.
Cỏc client sử dụng Faỗade khụng cần phải truy cập vào cỏc đối tượng hệ thống con một cỏch trực tiếp.
Kết quả
Bảo vệ khỏch hàng từ những thành phần của hệ thống con, vỡ thế sẽ giảm được số lượng cỏc đối tượng mà khỏch hàng phải giải quyết và làm cho hệ thống con được sử dụng dễ dàng.
Tăng cường mối liờn kết giữa hệ thống con và cỏc client của nú. Cỏc thành phần trong hệ thống con được kết nối chặt chẽ. Mối liờn kết giỳp bạn thay đổi cỏc thành phần của hệ thống con mà khụng ảnh hưởng đến cỏc client của nú.
Faỗade giỳp phõn lớp hệ thống và sự phụ thuộc giữa cỏc đối tượng. Cỏc faỗade cú thể lọc bỏ sự phức tạp hoặc những lệ thuộc cú tớnh chất lũng vũng. Điều này cú thể là kết quả quan trọng khi khỏch hàng và hệ thống con hoạt động độc lập.
Giảm sự phụ thuộc biờn dịch là cần thiết trong hệ thống phần mềm lớn. Bạn muốn tiết kiệm thời gian bằng cỏch tối thiểu hoỏ việc biờn dịch lại khi cỏc lúp hệ thống con thay đổi. Giảm sự lệ thuộc biờn dịch với Faỗade cú thể giới hạn việc biờn dịch lại cần thiết cho sự thay đổi nhỏ trong hệ thống con quan trọng. Faỗade cú th
Các file đính kèm theo tài liệu này:
DAN207.doc
