luận văn kỹ thuật dệt may Mẫu dáng thiết kế mẫu thiết kế và ứng dụng

Chương 1 LỜI NÓI ĐẦU
Phần mềm ngày càng trở nên phức tạp, thách thức trong những năm tới
không phải là vấn đề tốc độ, kinh phí hay sức mạnh của nó mà sẽ là độ phức
tạp.Vỡ vậy chúng ta phải dần loại bỏ chúng. Một cách tổng quan khi xây dựng
phần mềm thì ta phải quan tâm đến tổ chức, các quan hệ cấu trúc hình thành
nên hệ thống. Do khả năng của con người là có giới hạn khi khảo sát các vấn
đề phức tạp như tổng thể. Thông qua mô hình hoá ta sẽ giới hạn vấn đề bằng
cách nghiên cứu tập trung vào một khía cạnh của vấn đề và vào một thời điểm.
Không nên giải quyết tất cả các vấn đề vào một lần thiết kế, cần tranh thủ sử
dụng lại những trường hợp đã làm, khi ta tìm được một giải pháp tốt, cần phát
huy nó cho lần sau.
Xu thế áp dụng phương pháp hướng đối tượng thay cho phương pháp cấu
trúc ngày càng phổ biến khi xây dựng các hệ thống phần mềm lớn và phức tạp.
Do tầm quan trọng và tính linh hoạt của phương pháp phân tích thiết kế hướng
đối tượng được sử dụng rộng rãi tại các nước đang phát triển và đã được áp
dụng tại Việt Nam.
Phân tích hướng đối tượng là một vấn đề khó, càng khó hơn cho người
thiết kế mới vì họ thường lúng túng trong vấn đề chọn lựa phương pháp nào tối
ưu cho dự án, cho hệ thống của họ; đồng thời làm sao sử dụng lại và nâng cấp
từ những thuật toán hướng đối tượng đã được sử dụng trước đó. Điều này cũng
gây trở ngại cho những người cần tìm hiểu về hệ thống đang tồn tại, vỡ tính ưu
việt và đặc trưng của các ngôn ngữ hướng đối tượng nên họ thường hay khó
khăn nhận biết các lớp, các đối tượng kế thừa đặc biệt là trong các dự án lớn,
hệ thống lớn Khi gặp một vấn đề, người thiết kế đã lựa chọn một phương pháp
tối ưu, sao cho nó tốt nhất, phù hợp nhất, sử dụng dễ, giảm thiểu được độ phức
tạp cũng như tiết kiệm công sức cho những lần phát triển lần sau, cũng như
những lần tái sử dụng lại chỳng. Thụng thường khi tìm ra một giải pháp tốt, ta
thường lưu lại để sử dụng chúng cho lần sau, để lần sau sẽ ít tốn thời gian để
tìm hiểu mà vẫn có thể áp dụng chúng tốt. Chớnh vỡ dựa vào khái niệm mẫu
thiết kế của Christopher Alexander khi áp dụng trong thiết kế các toà nhà, giúp
cho người kiến trúc sư dựa vào một số khuôn dạng sẵn có mà thiết kế theo, hoặc

cải tiến nó. Cỏc chuyên gia trong vấn đề thiết kế và lập trình đã đúc rút ra kinh
nghiệm để đưa ra một số khuôn dạng chung về mẫu thiết kế phần mềm mà khi áp
dụng đáp ứng được phần nào yêu cầu khắt khe của công nghệ phần mềm hiện
đại. Và các nhà thiết kế sau này coi đó là một từ vựng chung để thiết kế cũng
như khi áp dụng và hiểu chúng để lập trình.
Trên thực tế không thể có một mẫu hoàn chỉnh cho phần mềm, nhưng chắc
chắn có thể tìm ra một khuôn dạng chung hoàn chỉnh cho các mẫu này.
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ế.
Phân tích và thiết kế hướng đối tượng là khó, nhưng mục đích thiết kế
hướng đối tượng nhằm được sử dụng lại lần sau lại càng khó hơn. Ta cần phải
tìm ra các đối tượng, các phần(factor) thích hợp cho từng lớp, từng đối tượng,
xác định được hệ thống giao diện cần phải kế thừa như thế nào và thiết lập mối
quan hệ giữa chúng.
Chớnh vì những phức tạp đó mà rất khó và lâu dài các chuyên gia mới tìm
ra được một khuôn dạng chung cho phần mềm, mặt khác các dự án và các hệ
thống phần mềm khi phát triển đều có mức độ trừu tượng hoá cao, nên ngôn ngữ
đôi khi cũng ở mức trừu tượng hoá và rất khó cho người sử dụng khi tìm hiểu về
chúng. Ngay cả các chuyên gia khi hoàn thành nghiên cứu cũng thừa nhận họ
không hiều về những gì mà họ viết ra trong lần viết đầu tiên.
Đặc biệt là khi hiểu được và thiết kế theo hướng đối tượng, để áp dụng các
mẫu thiết kế này vào trong hệ thống, dự án của mỡnh thỡ người áp dụng cần phải
nắm rõ và vững ít nhất một ngôn ngữ lập trình hướng đối tượng và phải có kinh
nghiệm trong thiết kế hướng đối tượng. Theo kinh nghiệm làm việc, và bằng
chính khả năng của mình, cũng như độ nhạy cảm trong phân tích mà người phát
triển mới có khả năng áp dụng chúng vào trong hệ thống của mình, và kết hợp
chúng một cách tối ưu nhất.
Tại Việt nam, do đõy là một vấn đề mới, và rất khó để tìm hiểu nên chưa
có nhóm nghiên cứu cụ thể nào về các mẫu thiết kế, và chúng hầu hết được áp
dụng theo phán đoán của người thiết kế, do ngôn ngữ mang tính trừu tượng cao

nên khó có thể áp dụng chúng một cách chính xác nhất để phát huy tính năng ưu
việt của nó. Nhưng một khi đã áp dụng các mẫu này vào thiết kế thì người thiết
kế sẽ thấy rất thuận lợi và giảm thiểu công sức cũng như độ phức tạp đi rất
nhiều. Hiểu và áp dụng các mẫu thiết kế này vào trong hệ thống cũng là một tiêu
chuẩn quan trọng của các nhà lập trình viên ở các nước công nghệ phần mềm
phát triển.
1.2. Mục đích của đồ án.
Mục đích của đồ án trong đợt thực tập tốt nghiệp và đồ án tốt nghiệp là
nghiên cứu cụ thể và chi tiết đến các vấn đề nhỏ của các mẫu thiết kế mà trong
đợt thực tập tốt nghiệp chưa có điều kiện tiếp cận và tìm hiểu đến và hoàn thiện
một cách căn bản các hiểu biết về Design Patern. Đõy là giai đoạn chuyển tiếp
quan trọng và tiến hành các công việc áp dụng các mẫu thiết kế này vào trong
thực tế, sử dụng các kiến thức đã nghiên cứu được cùng với các công cụ sẵn có
như UML, C++, VC++ để thiết kế và áp dụng chúng một cách hoàn thiện và đầy
đủ.
Tuy nhiên, các mẫu thiết kế là một vấn đề rất khú, nó khó đối với cả những
chuyên gia lập trình đầy kinh nghiệm, và bản thân nó cũng rất trừu tượng, đòi
hỏi người tìm hiểu về nó phải có một kiến thưcs nhất định và rất cần thiết trên
một mảng rộng các vấn đề, đặc biệt là cần phải có giác quan phán đoán mà chỉ
có thể có được khi người đú có kiến thức vững về phần mềm, có kinh nghiệm
chuyờn sõu. Do kinh nghiệm thực tế chưa có nhiều, và cũng chưa có một tài liệu
nào ở Việt Nam đã có nghiên cứu về vấn đề này, các tài liệu mà em tiếp xúc
cũng như tìm hiểu đều là dựa theo các thông tin trong nghiên cứu của các chuyên
gia mà cụ thể là của bốn chuyên gia: Erich Gamma, Richard Helm, Ralph
Johnson và John Vlissides cùng với rất nhiều các nghiên cứu của các chuyên gia
khác, và các dự án mà em tìm hiểu khi áp dụng các mẫu dự án này đều ở mức
trừu tượng cao, mà để hiểu được nó, chỉ có các nhà lập trình và thiết kế dày dặn
kinh nghiệm mới có thể hiểu được chúng một cách cặn kẽ và đầy đủ nhất. Vì
vậy, trong đồ án này, em nghiên cứu tất cả 23 mẫu thiết kế mà được cụ thể hoá,
và được coi là đầy đủ cho khuôn dạng chung của phần mềm hiện đại, nhưng để

áp dụng được tất cả chúng là điều rất phức tạp, vì tuỳ vào từng dự án và từng hệ
thống cụ thể mà ta có thể áp dụng từng mẫu thiết kế một, hay là ta kết hợp nhuần
nhuyễn chúng để đưa ra hiệu quả cao nhất. Trên thực tế, ở nước ngoài cũng như
ở Việt Nam, chưa có một dự án nào áp dụng đầy đủ 23 mẫu thiết kế này, và ở
Việt Nam hiện nay cũng cú ớt công ty áp dụng chúng trong thiết kế. Trong quá
trình nghiên cứu và tìm hiểu, em có điều kiện thực tập, và được tạo điều kiện
tham gia vào nghiên cứu và áp dụng một số mẫu trong thiết kế dự án của công ty
sản xuất phần mềm Khai Trí, và thấy được hiệu quả hơn hẳn khi áp dụng chúng
vào trong thiết kế của dự án công ty.
Đó là các mẫu:
Abstract Factory
Singleton
Adapter
Facade
Template Method
State Method
Factory Method
Do đõy là một dự án đươc phát triển và được nghiên cứu từ lâu, sản phẩm
đưa ra thị trường và đã được chấp nhật một cách có hiệu qủa, và trong thực tế, nó
đã đáp ứng được yêu cầu đòi hỏi của phần mềm hiện đại. Việc áp dụng các mẫu
thiết kế này đã có kết quả cụ thể và thực tiễn trong sản phẩm của công ty.
1.3. Việc nghiên cứu đồ án giải quyết điều gì
Như trên đã núi, cỏc mẫu thiết kế là một vấn đề rất khó và rất trừu tượng,
nó không phải là dễ cho những người mới tìm hiểu lần đầu, nhưng không thể
thiếu nếu bạn muốn trở thành một chuyên gia lập trình.
Nghiên cứu về các mẫu thiết kế trước hết là một nghiên cứu kỹ thuật phần
mềm mới. Tất nhiên nhiên là nghiên cứu một cách cặn kẽ các vấn đề và chi tiết
nhỏ ở từng mẫu thiết kế một là có thể nắm được một cách cơ bản và có thể áp
dụng thực tế được. Kết quả của nghiên cứu này là một tài liệu làm việc về các
mẫu thiết kế, với các nội dụng cụ thể để giúp cho bạn có thể phần nào hiểu được

và phần nào áp dụng được trong thực tế. Nhưng muốn tìm hiểu sâu hơn, thì cần
phải bằng chính khả năng của người cần tìm hiểu mới có thể rút ra được hiểu
biết thấu đáo về các mẫu thiết kế.
Sau đó là so sánh việc áp dụng các mẫu thiết kế này so với việc khi chưa áp
dụng chúng. Trong nhiệm vụ này cú thờm yêu cầu tìm hiểu dự án cụ thể và để từ
đó thấy được khi áp dụng chúng thấy hiệu quả và phù hợp. Đồng thời đưa ra
được một dự án cụ thể khi áp dụng chúng, và chi tiết hoá từng phần khi áp dụng
và giải quyết vấn đề khi áp dụng các mẫu này.
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?
Trong giai đoạn đồ ỏn tụt nghiệp, em nghiên cứu thờm, vì đõy là vấn đề
khó và phức tạp, trở ngại lớn nhất là chưa có một nghiên cứu cụ thể nào ở Việt
Nam, và được tham gia khi áp dụng chúng vào trong một dự án cụ thể. Trong lần
thực hiện này, em phải nghiên cứu sâu hơn về UML, các kiến thức về Rational
Rose, và các quy trình phần mềm. Do kiến thức thực tế chưa có nhiểu và hạn chế
về thời gian để tìm hiểu về một dự án đã được phát triển từ lâu, cũng như thời
gian nâng cấp chỳng nờn hạn chế thời gian chưa sâu sắc vấn đề. Và tôi chỉ tập
trung vào giải quyết một số mẫu trong dự án, phù hợp với dự án phát triển.
Ngoài ra để áp dụng các mẫu thiết kế này còn yêu cầu rất nhiều nội dung nữa, tôi
chỉ thực hiện nghiên cứu lý thuyết và chỉ áp dụng phần nào lý thuyết vào thực tế,
và còn nhiều mẫu thiết kế chưa thể đưa vào dự án này được, đồng thời cú ít điều
kiện được nghiên cứu các dự án đã áp dụng các mẫu này ở Viờt nam cũng như
các phần mềm cụ thể khác.
Chương 2 ĐẶT VẤN ĐỀ
Tóm tắt chương
Chương mở đầu này tôi xin được giới thiệu một số nét chung về đồ án tốt
nghiệp mà tôi lựa chọn để thực hiện. Đồng thời, trong phần này, tôi cũng trình
bày một số nét tổng quan về đề tài của đồ án tốt nghiệp, về những lý do, động cơ
thúc đẩy nghiên cứu và tìm hiểu đề tài của tôi, về những mục đích đặt ra và yêu
cầu của đề tài mà tụi đó nghiên cứu thực hiện trong thời gian qua.

2.1. Mục đích của đề tài
Như tên của đề tài đồ án “ Các mẫu thiết kế phần mềm hướng đối tượng
và áp dụng”, chính là thể hiện mục đích chính của đề tài. Việc nghiên cứu các
mẫu dáng thiết kế không chỉ là nghiên cứu một kỹ thuật phân tích, thiết kế mới,
mà hơn thế nữa là phương pháp tiếp cận khoa học và giải quyết vấn đề theo
những phương pháp tối ưu hóa mà các chuyên gia phân tích , thiết kế và lập trình
đã xây dựng thành các mẫu cụ thể. Nó giải quyết được những yêu cầu kiến thức
cơ bản đối với người áp dụng và thiết kế theo các mẫu cũng như cần phải nắm rõ
hơn để thiết kế tốt hơn, đáp ứng được yêu cầu của xu thế phát triển phần mềm
hiện nay.
2.2. Giới thiệu bài toán, nhiệm vụ của đề tài
Nhiệm vụ của đề tài có hai phần rất rõ ràng đó là :
 Nghiên cứu về Mẫu thiết kế
 Áp dụng Mẫu thiết kế đã nghiên cứu vào giải quyết một dự án và một số bài
toán con.
Về lý thuyết nghiên cứu về Mẫu thiết kế, tôi xin trình bày tổng quan về tư
tưởng chính mang tính cốt lõi của các tác giả để phát triển và hình thành nên
Mẫu thiết kế. Do Mẫu thiết kế không đơn thuần là một công nghệ mớI mà nó
thực sự là một hướng tiếp cận mớI và đầy đủ cho các nhà lập trình và phân tích
thiết kế. Vì Mẫu thiết kế chỉ thích hợp vớI các ngôn ngữ lập trình hướng đốI
tượng và cách phân tích thiết kế hướng đốI tượng. Trong khi sử dụng, nó khụng
tách khỏI UML, cũng đã cho ta cách ứng dụng trực tiếp các mẫu thiết kế này.
Về phần áp dụng Mẫu thiết kế vào thực hiện một dự án, tôi xin trình bày
nộI dung của dự án lớn và phần thực hiện của tôi trong dự án lớn đó, là một phần
của dự án nhỏ. Qua đó để bạn đọc xem được tổng quan về dự án lớn và nắm
được chi tiết các ưu điểm của dự án này khi áp dụng Mẫu thiết kế vào thiết kế so
vớI dự án khi áp dụng kiểu phân tích thiết kế cũ, cũng như nhìn ra được cách
thiết kế giúp cho dự án được nâng cấp lên dựa trên bản thiết kế cũ. Dựa vào các
thiết kế dự án cụ thể này mà ta có thể nhìn thấy rõ ràng cách thiết kế dựa trên
Mẫu thiết kế và những ưu điểm của nó.

2.3. Lý do chọn đề tài.
Làm phần mềm không chỉ là lập trình, tạo mã một cách đơn thuần để cuối
cùng ra một chương trình có khả năng chạy được. Điều đó chỉ thích hợp với các
dự án thật nhỏ, và rất nhỏ, hay đúng hơn là các chương trình đơn giản. Với các
dự án phần mềm còn có rất nhiều điều quan trọng hơn thế, ở mức phân tích thiết
kế, ở mức quản lý, phối kết hợp các nguồn nhân lực trong dự án một cách hiệu
quả và thực tế thành công của các dự án phần mềm ngày càng nhiều phụ thuộc
vào các yếu tố đó. Và cũng có nhiều lý thuyết, tư tưởng ra đời để thực hiện các
công việc đó, đó là các mẫu thiết kế, hay còn gọi là Mẫu thiết kế.
Trong nhà trường, tụi đó được học về phân tích thiết kế có cấu trúc, việc
nghiên cứu thực sự sâu sắc về một phân tích thiết kế mới trong một dự án cụ thể
là không có điều kiện , do hạn chế về thời gian. Và do nhận thức dự án, tầm quan
trọng của thiết kế hướng đốI tượng đối với các dự án phần mềm, nờn tụi chọn đề
tài “Mẫu dáng thiết kế Mẫu thiết kế và ứng dụng” là đề tài tốt nghiệp của mình.
Với tất cả các kiến thức cơ sở đã được học trong nhà trường cùng sự hướng dẫn
của thầy, cũng như sự hướng dẫn nhiệt tình của project manager của công ty sản
xuất phần mềm Khai Trí tôi cố gắng, tìm hiểu nghiên cứu Mẫu thiết kế, là những
mẫu thiết kế được áp dụng nhiều và rất hiện đại hiện nay. Điều này, đối với một
sinh viên chưa có thực tế thì hơn khó khăn vì nghiên cứu và hiểu các mẫu thiết
kế và tham gia vào dự án cụ thể trong thực tế thì ngoài yêu cầu kiến thức ở mức
nhất định thì cần thiết phải có những trải nghiệm thực tế. Tuy nhiên, điều đó chỉ
là yếu tố khách quan, trong thời gian qua, được sự hướng dẫn tận tình của thầy
giáo Phạm Đăng Hải, bộ môn khoa học máy tính, khoa Công nghệ thông tin,
trường Đại học Bách Khoa Hà Nội, và sự cố gắng của bản thân, tôi đã thực hiện
hoàn thành đề tài. Với việc nghiên cứu các mẫu thiết kế Mẫu thiết kế và ứng
dụng nó vào thực tế, tôi nghĩ đó là một bước chuyển tiếp nghiên cứu rất quan
trọng, từ hàn lâm sang công nghiệp, là bước chuẩn bị quan trọng. Do đó, theo tôi
nghĩ đây là một đề tài rất hay, và thiết thực, và rất tin tưởng thực hiện đề tài này
Chương 3 TỔNG QUAN VỀ MẪU THIẾT KẾ
3.1. Lịch sử về mẫu dáng thiết kế.

Theo các nghiên cứu của các chuyên gia trong việc thuận lợi của ngôn ngữ
đã chỉ ra rằng kiến thức và kinh nghiệm không thể được tổ chức đơn giản xoay
quanh vấn đề cú pháp. Nhưng trong các cấu trúc khái niệm lớn hơn như thuật
toán, cấu trúc dữ liệu thì cần được lập kế hoạch và thiết kế một cách hoàn thiện.
Người thiết kế không nghĩ đến cú pháp mà họ đang sử dụng để thiết kế nhiều
như khi họ cố ghộp cỏc thiết kế hiện tại mà không phù hợp vớI thuật toán, cấu
trúc dữ liệu và các căn bản ăn sâu mà họ đã học.
Các nhà khoa học máy tính đã đặt tên và sắp xếp các thuật toán, cấu trúc dữ
liệu nhưng họ không thường đặt tên cho các mẫu khác. Mẫu thiết kế cung cấp
một từ vựng chung cho các nhà thiết kế để kết nốI, lập tài liệu và tìm hiểu thiết
kế mới. Mẫu thiết kế làm cho hệ thống đơn giản hơn bằng cách hiểu nó dựa trên
mức trừu tượng hoá cao hơn là các ký pháp thiết kế hoặc ngôn ngữ lập trình.
Mẫu thiết kế làm tăng mức độ thiết kế giỳp cỏc thành viên trong một nhóm
có thể dễ dàng hiểu và thảo luận cùng nhau trong một vấn đề cần giải quyết.
Biết được các mẫu dáng thiết kế giúp cho ta hiểu dễ dàng về các hệ thống
hiện tại. Hầu hết các hệ thống hướng đối tượng sử dụng các mẫu thiết kế này.
Những người nghiên cứu chương trình hướng đốI tượng thường phàn nàn rằng
các hệ thống đã từng nghiên cứu hoặc thực hiện sử dụng tính kế thừa rất phức
tạp khó có thể kiểm soát được chúng. Thực tế xảy ra rất nhiều vì họ không hiểu
được các mẫu thiết kế trong hệ thống.
Các mẫu dáng thiết kế giúp người nghiên cứu trở thành một nhà thiết kế
giỏi hơn, hơn thế nữa, mô tả hệ thống theo các mẫu thiết kế sẽ làm cho hệ thống
dễ hiểu hơn. Do có vốn từ vựng chung nên bạn không phải mô tả toàn bộ các
mẫu thiết kế, chỉ cần đặt tên cho mẫu thiết kế đú, thỡ người đọc sẽ hiểu rõ ràng
về vấn đề đó như thế nào?
Chúng ta sử dụng chúng để đặt tên cho các lớp, để nghiên cứu tốt hơn và
thiết kế để mô tả các mẫu thiết kế.
3.1.1. Mục đích của các mẫu thiết kế.
Giúp cho người thiết kế tái sử dụng lại thành công bởi việc dựa trên nền
thiết kế mới và kinh nghiệm. Một nhà thiết kế áp dụng chúng và hiểu được

chúng nhanh chóng mà không cần phải tìm hiểu và thiết kế lại chúng. Làm cho
tái sử dụng lại các thiết kế và phân tích tốt hơn.
Mẫu thiết kế là một kỹ thuật mới giúp cho người phát triển của hệ thống
mới dễ dàng truy nhập hơn. Mẫu thiết kế giúp cho việc lựa chọn thiết kế có thứ
tự làm cho hệ thống tối ưu và tránh được những rủi ro không đáng có.
3.1.2. Các mẫu thiết kế giải quyết vấn đề như thế nào?
Tìm kiếm đối tượng thích hợp: Cái khó của phân tích thiết kế hướng đối
tượng là phân tích hệ thống thành các đối tượng, chúng đều ảnh hưởng đến
phân tích, thường xuyên phương pháp hoá cách tiếp cận
Xác định tính chất của đối tượng: Các đối tượng có thể biến đổi lớn về số
lượng và kích cỡ, chúng có thể biểu diễn mọi thứ, và có thể tổng thể ứng
dụng lựa chọn các đối tượng như thế nào để phù hợp bài toán và khả năng
chia nhỏ đối tượng lớn thành các đối tượng nhỏ hơn, là một vấn đề cần phải
có quyết định đúng.
Định nghĩa giao diện đối tượng: Mẫu thiết kế giúp xác định giao diện bằng
cách nhận dạng cỏc khoỏ thành phần của nó và các dạng dữ liệu được nhận
biết qua giao diện.
Mẫu thiết kế còn xác định mối quan hệ giữa các giao diện. Đặc biệt chỳng
cũn yêu cầu một số lớp có giao diện tương tự nhau, hoặc chúng định vị trớ
cỏc ràng buộc trong giao thức của những lớp này.
Xác định các thực hiện đối tượng: Cách thực hiện của đối tượng được thông
qua các lớp của nó. Một lớp được chỉ ra dữ liệu bên trong đối tượng và biểu
diễn , xác định các thao tác các đối tượng thực hiện
Lớp và giao thức kế thừa: Theo quy tắc: Programming to an Interface, not an
Implementation
Vấn đề tái sử dụng và tham số hoỏ cỏc dạng Mẫu thiết kế.
3.1.3. Các phương pháp để chọn các mẫu thiết kế
Phải tìm được các Mẫu thiết kế nào là phù hợp với vấn đề nhất, do đó có
một số cách tiếp cận sau:
Đi đến quyết định các Mẫu thiết kế giải quyết vấn đề như thế nào?

Kiểm tra các nội dung mục đích cần sử dụng.
Nghiên cứu các mẫu có liên quan với nhau như thế nào.
Nghiên cứu các mẫu phù hợp với mục đích.
Kiểm tra nguyên nhân thiết kế lại.
Xem xét những vấn đề có thể thay đổi trong thiết kế của bạn.
3.1.4. Làm thế nào để thiết kế một mẫu thiết kế
Khi chọn được Mẫu thiết kế làm thế nào để sử dụng ?.
Nghiên cứu về mẫu đó.
Nghiên cứu các thành phần cấu trúc và các vấn đề liên quan.
Lựa chọn cỏc tờn cho các phần mẫu mà hiệu quả trong ngữ cảnh.
Xác định các lớp. Khai báo giao diện, xác lập quan hệ thừa kế và xác định các
trường hợp biến biểu diễn dữ liệu và kết quả đối tượng. Nhận dạng các lớp
hiện có trong ứng dụng của bạn mà mẫu sẽ tác động sửa đổi chúng cho phù
hợp.
Xác định ứng dụng, cỏc tờn đặc trưng cho các thao tác trong mẫu
Thực hiện các thao tác để đưa ra quyền hạn trách nhiệm và cộng tác trong các
mẫu.
3.2. Các mẫu dáng thiết kế (Mẫu thiết kế)
3.2.1. Khái quát chung về Mẫu thiết kế.
Mẫu thiết kế định tên, thúc đẩy và giải thích một cách có hệ thống các
thiết kế mà được địa chỉ hoá trong hệ thống hướng đối tượng. Nó mô tả
vấn đề, giải pháp, khi áp dụng các giải pháp và các kết quả của nó. Nó
cũng nêu ra các gợi ý và các ví dụ cụ thể trong từng bước thực hiện.
Giải pháp là sự sắp sếp các đối tượng và các lớp để giải quyết vấn đề.
Giải pháp được tuỳ biến và thực hiện để giải quyết các vấn để trong từng
ngữ cảnh riêng biệt.
Chúng tôi chia các mẫu thiết kế theo hai tiêu chí. Tiêu chí đầu tiên, là
mục đích, ánh xạ những vấn đề mà mẫu thiết kế thực hiện. Các mẫu có
thể thuộc vào một trong những mục đích như khởi tạo, cấu trúc và hoạt
động.

Các mẫu khởi tạo liên quan đến quá trình tạo đối tượng, các mẫu cấu
trúc( structural mẫu) giải quyết thành phần của các lớp và các đối
tượng. Các mẫu hoạt động( behavioral mẫu) cụ thể hoá phương pháp mà
các lớp và các đối tượng thực hiện và phân quyền trách nhiệm.
Theo tiêu chí thứ hai, là phạm vi (scope), định nghĩa liệu mẫu áp dụng
đầu tiên vào các lớp các đối tượng. Các mẫu class giải quyết mối quan hệ
giữa các lớp và các lớp con của nó. Mối quan hệ này được thiết lập thông
qua tính kế thừa, nờn chỳng được gắn kết tĩnh tại thời gian biên dịch.
Các mẫu đối tượng giải quyết mối quan hệ giữa các đối tượng, mà có thể
được thay đổi tại thời gian chạy và chúng linh động hơn. Hầu hết các
mẫu sử dụng tính kế thừa ở một số khía cạnh nào đó. Nên chỉ có mẫu
mang tên là “ các mẫu lớp” là tập trung vào mối quan hệ giữa các lớp.
Còn lại hầu hết các mẫu đều thuộc vào phạm vi đối tượng.
Có nhiều cách tổ chức thành các mẫu. Và một số mẫu được sử dụng
cùng nhau để làm trong sáng thiết kế. Sử dụng mẫu nào còn phụ thuộc
vào công việc bên trong mà chúng thực hiện, chúng so sánh, và khi nào
thì áp dụng chúng.
3.2.2. Mẫu khởi tạo
Mẫu khởi tạo trừu tượng hoá quá trình khởi tạo(tạo nấc). Mẫu khởi tạo
giúp cho hệ thống độc lập vào các đối tượng của nó được tạo ra như thế
nào, soạn như thế nào, và biểu diễn như thế nào. Một lớp mẫu khởi tạo sử
dụng tính kế thừa để biến đổi lớp đã khởi tạo, nhưng ngược lại một đối
tượng mẫu khởi tạo sẽ giao việc khởi tạo tới đối tượng khác.
Creational trở nên quan trọng khi các hệ thống có nhiều sự phụ thuộc vào
thành phần đối tượng hơn là lớp kế thừa.
Có hai vấn đề tuần hoàn trong các mẫu này là : Chúng đều bao gói kiến
thức(nội dung) về những lớp thực hiện mà hệ thống sử dụng. Thứ hai là
chúng đều ẩn đi làm thế nào mà các thể hiện của các lớp này được tạo ra và
được đặt cạnh nhau.
Kết quả là mẫu khởi tạo đều đưa ra nhiều hiệu quả hơn trong cái gì đã được

tạo ra, ai tạo ra chỳng, nó được tạo ra như thế nào, và khi nào thì tạo ra
chỳng. Chỳng cho phép ta cấu hình một hệ thống với các “product” object,
biến đổi rộng trong cấu trúc và chức năng. Cấu hình có thể tĩnh(được chỉ
định trong thời gian biên dịch) hoặc động(được chỉ định trong thời gian
chạy).
Trong 23 mẫu thiết kế mà tôi nghiên cứu và tìm hiểu, thì trong mẫu khởi tạo
có những mẫu sau:
Abstract Factory
Builder
Factory Method
Prototype
Singleton
Do các mẫu khởi tạo có mối liên quan gần với nhau, ở đây ta nghiên cứu có
5 mẫu mà làm nổi bật nên sự tương đồng và khác nhau của chúng.
Chọn mẫu nào còn phụ thuộc vào nhiều yếu tố, và tuỳ vào mục đích dự án
của mình mà ta sử dụng các mẫu cụ thể cũng như khi ta kết hợp các mẫu
này với nhau trong dự án của mình.
Sau đây tôi xin trình bày tổng quan về mục đích, cấu trúc và các mẫu thiết
kế của từng mẫu cụ thể trong phần mẫu khởi tạo cũng như khi ta áp dụng
chúng vào trong thiết kế dự án cũng như từng phần của dự án thì thu được
những kết quả gì.
3.2.2.1. Abstract Factory.
3.2.2.1.1 Mục đích
Cung cấp một giao diện để tạo ra các họ của các đối tượng phụ
thuộc hoặc liên quan đến nhau mà không phải xác định chính
xác các lớp thực hiện của chúng.
3.2.2.1.2 Ví dụ
Coi bộ dụng cụ giao diện người dùng cung cấp các tiêu chuẩn đa giao diện
như là Motif và Presentation Manager. Các thể hiện và hoạt động khác
nhau cho giao diện người dựng” widgets” giống như scroll bar, window, và

cỏc nỳt.Theo tiêu chuẩn này, một ứng dụng có thể khụng khú mó hoỏ cỏc
widget của nó cho từng khía cạnh cảm nhận và nhỉn. Các lớp khởi tạo của
widget thông qua ứng dụng này làm cho nó khú mà chuyển đổi sau đó.
Giải pháp đặt ra là định nghĩa một lớp WidgetFactory ảo, khai báo một giao
diện cho việc tạo từng loại cơ bản trong widget. Cũng có một lớp ảo cho
từng loại trong widget, và các lớp con thực hiện cài đặt các widget. Giao
diện WidgetFactory có một thao tác trả về một đối tượng widget cho từng
lớp widget ảo. Các client gọi những thao tác này để sử dụng các thể hiện
widget, nhưng các client không nhận biết được các lớp cụ thể mà chúng sử
dụng. Có một lớp con cụ thể của WidgetFactory cho từng tiêu chuẩn một.
Mỗi lớp con cài đặt các thao tác để tạo các widget tương ứng. Ví dụ, hàm
CreateScrollBar trong MotifWidgetFactory thể hiện và trả về một Motif
scroll bar, trong khi các thao tác tương ứng trong PMWidgetFactory trả về
một scroll bar cho Presentation Manager. Các client tạo các widget đơn nhất
thông qua giao diện WidgetFactory và các lớp cài đặt các widget cho
chúng.
Một WidgetFactory cũng tuân thủ sự phụ thuộc giữa các lớp widget cụ thể.
Một Motif scroll bar có thể được sử dụng với nút Motif và một soạn thảo
text Motif, và ràng buộc này phải tự động tuân theo như kết quả khi sử dụng
MotifWidgetFactory.
3.2.2.1.3 Ứng dụng
Một hệ thống có thể độc lập vào sản phẩm của nó được tạo ra, kết cấu và
biểu diễn như thế nào.
Một hệ thống có thể được định dạng với một trong nhiều họ của sản phẩm.
Một họ của các đối tượng sản phẩm liên quan được thiết kế để được sử dụng
cùng nhau và cần thiết tuân thủ các ràng buộc này.
Bạn muốn cung cấp một thư viện lớp của các sản phẩm và muốn chỉ đưa ra
giao diện của chúng, mà không cần đưa ra cách cài đặt của chúng.
3.2.2.1.4 Cấu trúc
AbstractFactory

CreateproductA()
CreateproductB()
ConcreteFactory
CreateproductA()
CreateproductB()
ConcreteFactory
CreateproductA()
CreateproductB()
Client
AbstractProductA
ProductA2 ProductA1
AbstractProductB
ProductB2 ProductB1
3.2.2.1.5 Các thành phần
• AbstractFactory: Khai báo một giao diện cho các thao tác mà tạo các đối
tượng sản phẩm trừu tượng.
• ConcreteFactory: Cài đặt các thao tác để tạo các đối tượng sản phẩm cụ thể.
• AbstractProduct: Khai báo một giao diện cho một dạng của đối tượng sản
phẩm.
• ConcreteProduct: Định nghĩa một đối tượng sản phẩm được tạo bởi concrete
factory tương thích.
o thực hiện giao thức AbstractProduct.
• Client: Chỉ sử dụng cho các giao diện được khai báo bởi AbstractFactory và
các lớp AbstractProduct.
3.2.2.1.6 Phối hợp cộng tác với các mẫu khác:
Thường là một thể hiện lớp ConcreteFactory đơn lẻ được tạo tại thời gian
chạy, concrete factory này tạo các đối tượng sản phẩm cài đặt trường hợp
riêng biệt. Để tạo các đối tượng sản phẩm khác nhau, client có thể sử dụng
một concrete factory khác nhau.
AbstractFactory làm theo việc tạo của các đối tượng sản phẩm tới lớp con

Concrete Factory.
3.2.2.1.7 Kết quả
Cô lập với các lớp thực hiện : Giúp bạn kiểm soát được các lớp trong
các đối tượng mà ứng dụng tạo ra.Vỡ, một factory bao gói trách nhiệm
và quá trình tạo các đối tượng sản phẩm, nó cô lập các client từ các lớp
cài đặt của nó. Client sử dụng các thể hiện thông qua các giao diện trừu
tượng của chúng. Cỏc tờn của lớp sản phẩm được cô lập trong quá
trình cài đặt của các factory cụ thể; nờn chỳng khụng xuất hiện trong
mã của client.
Tạo ra sự thay đổi các họ sản phẩm một cách dễ dàng : Lớp của
Concrete factory chỉ xuất hiện một lần trong ứng dụng, tại vị trí mà nó
được tạo ra.Cú thể sử dụng các định dạng sản phẩm khác nhau một
cách đơn giản bằng cách thay đổi concrete factory. Do một abstract
factory tạo một họ đầy đủ các sản phẩm.
Tăng mối quan hệ vững chắc giữa các sản phẩm . Khi các đối tượng
sản phẩm trong một họ được thiết kế để làm việc cùng nhau, điều quan
trọng là một đối tượng sử dụng các đối tượng chỉ từ một họ, tại một
thời điểm.
Đưa ra các kiểu dạng mới của sản phẩm là khó. Do vì mở rộng các
factory trừu tượng để tạo các dạng mới của Product là không đơn giản.
Điều đó có nghĩa là giao diện AbstractFactory cố định một tập các sản
phẩm có thể được tạo. Để đưa ra các dạng mới của các sản phẩm thì
cần yêu cầu mở rộng giao diện factory, điều đó cũng có nghĩa là giải
quyết sự thay đổi lớp AbstractFactory và tất cả các lớp con của nó.
3.2.2.1.8 Cài đặt
Factory là đơn lẻ : Một ứng dụng riêng biệt chỉ cần một thể hiện của
Concrete Factory cho mỗi họ sản phẩm. Trong trường hợp này nờn
dựng mẫu Singleton.
Tạo các sản phẩm : Abstract Factory chỉ khai báo một giao diện cho
việc tạo các sản phẩm. Tuỳ thuộc vào các lớp con ConcreteProduct để

tạo chúng. Phương pháp chung để thực hiện việc này là định nghĩa
một factory method cho từng sản phẩm.
Định nghĩa các factory có thể được mở rộng.Mỗi dạng sản phẩm
thường được AbstractFactory định nghĩa một thao tác khác nhau. Các
loại sản phẩm được mó hoỏ trong các thao tác ký pháp. Do vậy, thêm
một loại mới của sản phẩm yêu cầu sự thay đổi giao diện
AbstractFactory và tất cả các lớp con phụ thuộc vào nó. Một giải pháp
thiết kế hiệu quả và ít rủi ro hơn là thêm vào một tham số tới các thao
tác tạo đối tượng. Tham số này chỉ ra dạng đối tượng có thể tạo được.
Nó có thể là một lớp nhận dạng, một số nguyên, một xâu, hoặc có thể
chỉ ra dạng của sản phẩm. Với phương pháp này, AbstractFactory chỉ
cần một thao tác “Make” đơn với một tham số để chỉ ra một dạng đối
tượng cần tạo.
3.2.2.1.9 Các mẫu thiết kế liên quan
Các lớp Abstract Factory thường được cài đặt với factory method, nhưng
chúng cũng có thể được cài đặt bằng cách sử dụng Prototype.
Một concrete factory thường là đơn nhất.
3.2.2.2. Builder
Mục đích : Phân tách việc xây dựng của đối tượng phức tạp dựa trên
biểu diễn của nó, do đó cùng một tiến trình xây dựng có thể tạo ra các
biểu diễn khác nhau.
3.2.2.2.1 Ví dụ
Reader đối với dữ liệu RTF có thể thay đổi định dạng, và chuyển sang một
số dạng text khác như ASCII hoặc text wigdet. Và số lượng khả năng
chuyển đổi là không kết thúc. Nờn nó có thể dễ dàng thêm vào một chuyển
đổi mới mà không cần phải chỉnh sửa.
Giải pháp tốt là định dạng lớp RTFReader với đối tượng TextConverter,
chuyển đổi RTF sang biểu diễn text khác. Như khi RTFReader phân tách
dữ liệu RTF, nó sử dụng TextConverter để thực hiện việc chuyển đổi
này,dưới dạng chuyển đổi thẻ bài. Các đối tượng TextConverter là có trách

nhiệm cho việc thực hiện chuyển đổi dữ liệu và đối với việc biểu diễn một
thẻ bài trong từng định dạng một. Các lớp con của TextConverter chỉ ra
trong các chuyển đổi và các định dạng khác nhau.
Từng dạng lớp chuyển đổi có kỹ thuật tạo và cài đặt đối tượng phức tạp, và
đặt chúng dưới dạng một giao diện trừu tượng. Việc chuyển đổi như thế
nào là do reader phân tách. Trong mẫu này mỗi lớp chuyển đổi được gọi là
builder, và một reader được gọi là director.
Trong v í dụ này ta nên áp dụng mẫu Builder, và mẫu Builder phân tách
thuật toán cho việc dịch một định dạng text, làm thế nào để một chyển đổi
định dạng đã tạo, đã biểu diễn. Nó cho phép sử dụng lại thuật toán chuyển
đổi của RTFReader để tạo các biểu diễn text khác nhau từ tài liệu RTF- chỉ
được định dạng RTFReader với các lớp con của TextConverter.
3.2.2.2.2 Ứng dụng
Sử dụng một thuật toán xây dựng một đối tượng phức tạp nên có thể độc
lập với các thành phần tạo nên đối tượng cũng như việc chúng được lắp
ghép lại với nhau như thế nào.
Quá trình xây dựng phải cho phép các biểu diễn khác nhau đối với đối
tượng mà nó xây dựng.
3.2.2.2.3 Cấu trúc:
Director
Contruct()
Builder
BuilPart()
ConcreteBuilder
BuilPart()
GetResult()
For all objects in struscture{
Builder->BuildPart()
}
Product

3.2.2.2.4 Thành phần
Builder : Định nghĩa một giao diện trừu tượng để tạo các thành
phần của Product object.
ConcreteBuilder:
o Xây dựng và lắp ráp các phần của sản phẩm bằng cách
cài đặt giao diện Builder.
o Định nghĩa và theo dõi biểu diễn mà nó tạo ra.
o Cung cấp một giao diện cho việc thu được sản phẩm.
Director: Xây dựng một đối tượng bằng việc sử dụng giao diện
Builder.
Product
o Biểu diễn đối tượng phức tạp dưới dạng xây dựng.
ConcreteBuilder xây dựng biểu diễn bên trong của sản phẩm
và định nghĩa tiến trình xử lý mà nó được lắp ráp.
o Bao hàm các lớp mà định nghĩa các phần hợp thành, bao
gồm các giao diện đối với việc cài đặt các phần vào kết quả
cuối cùng.
3.2.2.2.5 Phối hợp cộng tác.
Client tạo đối tượng Director và cấu hình nó với việc yêu cầu đối tượng
Builder.
Director thông báo cho builder bất kỳ khi nào một phần của product có thể
được xây dựng.
Builder nắm giữ các yêu cầu từ director và thờm cỏc phần tới sản phẩm.
Client thu lại sản phẩm từ builder
3.2.2.2.6 Kết quả
Cho phép thay đổi biểu diễn bên trong của sản phẩm. Đối tượng Buider
cung cấp cho director một giao diện trừu tượng để xây dựng sản phẩm
Giao diện này cho phép ẩn đi cách biểu diễn và cấu trúc trong của sản
phẩm, cũng ẩn sản phẩm đã lắp ghép như thế nào từ các thành phần cấu
thành. Do, sản phẩm được xây dựng qua một giao diện trừu tượng nên tất

cả những gì bạn cần làm để thay đổi cách biểu diễn bên trong của product
là định nghĩa một Builder mới.
Xây dựng và biểu diễn có mã nguồn tách biệt. Mẫu Builder tăng tính
modul hoá bằng cách bao gói phương pháp một đối tượng phức tạp đã
được tạo ra và cỏch nó được biểu diễn như thế nào. Client không cần biết
gì về các lớp định nghĩa cấu trúc bên trong của sản phẩm, các lớp như thế
không xuất hiện trong giao diện Builder. Mỗi ConcreteBuilder chứa tất cả
mã nguồn để tạo và lắp ráp một dạng product cụ thể. Mã nguồn được viết
một lần và các director có thể sử dụng lại để xây dựng các biến thể khác
của sản phẩm từ một tập các thành phần.
Giúp kiểm soát tốt hơn trong quá trình xây dựng: Không giống như các
creational mẫu khác xây dựng các sản phẩm trong một lần ( one shot).,
Builder mẫu xây dựng sản phẩm từng bước một dưới kiểm soát của
director. Chỉ khi nào sản phẩm được hoàn thành thì director thu lại nó từ
Builder. Do đó, giao diện Builder phản ánh quá trình xây dựng product
đầy đủ rõ ràng hơn các mẫu khởi tạo khỏc. Giỳp điều khiển quá trình xây
dựng tốt hơn.
3.2.2.2.7 Cài đặt
Đặc thù là có một lớp Builder trừu tượng định nghĩa một thao tác cho từng
thành phần, director có thể hỏi đến nó để tạo. Lớp ConcreteBuilder ghi
lồng các thao tác cho các thành phần
Cài đặt và xây dựng giao diện : Các Builder xây dựng sản phẩm của chúng
theo từng bước một, vấn đề thiết kế chính liên quan đến mô hình cho việc
xử lý xây dựng và cài đặt.
Tại sao không có lớp trừu tượng nào cho các sản phẩm? Trong những
trường hợp chung chung, các sản phẩm tạo ra bởi các builder concrete
khác rất nhiều so với việc biểu diễn của chúng, trong đó số nhỏ thu được
từ việc đưa ra các sản phẩm khác nhau từ một lớp cha thông thường.
Các phương pháp rỗng như là sự lựa chọn trong Builder: Trong C++,
Build method thường mang tính chất thực hiện không khai báo các thành

viên chức năng ảo. Chúng được định nghĩa như một phương pháp rỗng,
cho phép các client ghi đè chỉ khi các thao tác mà chúng liên quan mật
thiết tới.
3.2.2.2.8 Các Mẫu quan hệ
Abstract Factory thường tương tự với Builder trong đó nó cũng có thể xây
dựng các đối tượng phức tạp. Cái khác nhau trước hết là Builder mẫu tập
trung vào việc xây dựng một đối tượng phức tạp từng bước một. Tầm
quan trọng của Abstract Factory là trong một họ các đối tượng sản phẩm
(đơn giản hoặc phức tạp). Builder đưa ra sản phẩm như là bước cuối cùng,
nhưng tới một chừng mực nào đó mà Abstract Factory được quan tâm, sản
phẩm được đưa ra một cách trực tiếp và nhanh chóng (get returned
immediately).
3.2.2.3. Factory Method
3.2.2.3.1 Mục đích
Định nghĩa một giao diện cho việc tạo một đối tượng, nhưng cho phép
các lớp con quyết định lớp nào khởi tạo, factory method để một lớp dựa
theo việc khởi t ạo đó để tới các lớp con.
3.2.2.3.2 Ví dụ
Framework sử dụng các lớp trừu tượng để định nghĩa và duy trì quan hệ giữa
các đối tượng. Một framework thường chịu trách nhiệm tạo những đối tượng.
Coi một framework đối với việc áp dụng có thể biểu diễn nhiều document
tới user. Hai lớp trừu tượng chính trong framework này là các lớp
Application và Document. Cả hai lớp này là trừu tượng, và các client phải
phân lớp chúng để thực hiện các application-specific của chúng. Để tạo một
ứng dụng vẽ, ví dụ, chúng ta định nghĩa các lớp DrawingApplication và
DrawingDocument. Lớp Application có nhiệm vụ chính là quản lý
Document và sẽ tạo chúng theo yêu cầu – khi mà user chọn Open hoặc là
New từ menu.
Factory Method đề ra được một giải pháp. Nó bao gói các hiểu biết
của lớp con Document nào tạo và dịch chuyển hiểu biết này ra khỏi

framework.
Các lớp con Application định nghĩa lại một thao tác CreateDocument
trừu tượng trong Application để trả về một lớp con Document tương
ứng. Chúng ta gọi CreateDocument là một factory method do nó cú
nhiệm vụ đối với việc sản xuất một đối tượng.
3.2.2.3.3 Thành phần
Một lớp không thể biết trước lớp của các đối tượng nó phải tạo.
Một lớp muốn các lớp con của nó định nghĩa các đối tượng mà nó tạo.
3.2.2.3.4 Cấu trúc:


3.2.2.3.5 Thành phần:
Product:
Định nghĩa một giao diện của các đối tượng một factory method tạo.
ConcreteProduct:
Product
ConcreteProduct
Creator
FactoryMethod
AnOperation()
ConcreteCretor
FactoryMethod
Product=FactoryMethod()
Return new CreteProduct
Thực hiện giao diện Product.
Creator:
Khai báo factory method, mà đưa ra một đối tượng của của dạng Product.
Creator có thể cũng định nghĩa là một default implementation của factory
method để trả về một đối tượng ConcreteProduct mặc định.
Có thể gọi factory method để tạo một đối tượng Product.

ConcreteCreator:
Ghi đè factory method để trả về một thể hiện của ConcreteProduct thích
hợp.
3.2.2.3.6 Kết quả
Factory method bỏ qua sự cần thiết để nối kết các lớp định nghĩa ứng
dụng (application – specific) vào trong mã nguồn. Mã nguồn chỉ thực
hiện với giao diện Product;. Ngoài ra cũn có :
Cung cấp các móc nối cho các lớp con.: tạo các đối tượng bên trong một lớp
với một factory method hữu hiệu hơn là tạo một đối tượng một cách trực
tiếp. Factory method đưa cho các lớp con một kết nối để cung cấp một
phiên bản mở rộng của đối tượng.
Kết nối các biểu đồ lớp song song .Các biểu đồ lớp song song đưa ra kết
quả khi một lớp đưa ra các thành phần để phân chia lớp.
3.2.2.3.7 Cài đặt
Có hai dạngbiến đổi chính :Trước hết là khi lớp Creator là lớp trừu tượng và
không cung cấp một cài đặt nào cho factory method mà nó khai báo, trường
hợp này yêu cầu lớp con định nghĩa một cài đặt.
Trường hợp thứ hai là : Khi Creator là lớp thực hiện, và cung cấp mặc định
cài đặt cho factory method.
Tham số hoá factory method. Factory method sử dụng một tham số để
phân biệt được dạng của đối tượng để tạo. Tất cả các đối tượng mà factory
method tạo sẽ được sử dụng trong giao diện Product.
Sử dụng template để tránh việc phân lớp. Một vấn đề cơ bản khác với
factory method là phải phân lớp khi tạo các đối tượng Product tương thích.
class Creator {
public:
virtual Product*CreateProduct() = 0;
};
template<class TheProduct>
class StandardCreator : public Creator {

public:
virtual Product * CreateProduct();
};
template <class TheProduct>
Product * StandardCreator<TheProduct>:: CreatorProduct(){
return new TheProduct;
}
Với template này, client cung cấp một product class – không phân lớp
Creator.
class MyProduct : public Product{
public :
Myproduct();
//
};
StandardCreator<MyProduct>myCreator;
Đặt tên sự chuyển đổi.
3.2.2.3.8 Các mẫu liên quan:
Abstract Factory thường được thực hiện với factory method. Factory
method thường đựoc gọi cùng Template Method. Trong ví dụ Document,
NewDocument là template method.
Prototype không yêu cầu việc phân lớp Creator. Tuy nhiên, chúng thường
yêu cầu một thao tác khởi tạo trong lớp Product. Creator sử dụng Initialize
để khởi tạo một đối tượng. Factory Method không yêu cầu như một thao
tác.
3.2.2.4. Prototype
3.2.2.4.1 Mục đích
Chỉ ra các dạng của nhiều đối tượng để tạo bằng cách dùng một thể
hiện mẫu ban đầu, và tạo các đối tượng mới bằng việc sao chép mẫu
này.
3.2.2.4.2 Ví dụ

Có thể xây dựng một soạn thảo cho các điểm nhạc bằng cách làm theo một
khung tổng quát cho các soạn thảo đồ hoạ và thêm vào các đối tượng mới
để biểu diễn ghi chú, các điểm dừng,cỏc đoạn nhạc. Khung soạn thảo có
thể có một bảng công cụ đối với việc thờm cỏc đối tượng nhạc tới các
điểm. Bảng công cụ cũng có thể chứa công cụ để cho phép chọn lựa, di
chuyển, hay các thao tác xử lý dựa trên đối tượng âm nhạc đó.
Giả sử, framework cung cấp một lớp ảo Graphic cú cỏc thành phần đồ hoạ,
giống như là các ghi chú, và các đoạn nhạc. Hơn nữa, nó cũng cung cấp một
lớp Tool ảo cho việc định nghĩa các công cụ giống các thao tác trong bảng
công cụ. Framework cũng định nghĩa trước một lớp con GraphicTool cho
các công cụ tạo các thể hiện của các đối tượng đồ hoạ và thờm chỳng vào
dữ liệu.
Nhưng Graphic Tool biểu diễn một vấn đề cho thiết kế framework. Các
lớp cho các ghi chú và các đoạn chỉ ra phần ứng dụng, nhưng lớp
GraphicTool thuộc về framework. GraphicTool không biết làm thế nào để
tạo các thể hiện của đối tượng nhạc, nhưng cũng tạo rất nhiều lớp con.
Chúng ta cũng biết thành phần đối tượng là sự lựa chọn hiệu quả tới việc
phân lớp. Một câu hỏi đặt ra là, làm thế nào một framework sử dụng nó để
tham số hoá thể hiện của GraphicTool bởi lớp nào của Graphic mà chúng
hỗ trợ để tạo ra?Giải pháp được nằm trong GraphicTool tạo một Graphic
mới bằng cách sao chép hoặc nhân bản một thể hiện của lớp con Graphic.
Chúng ta gọi thể hiện này là mẫu. GraphicTool được tham số hoá bởi mẫu,
nó có thể nhân bản và thêm vào tới document. Nếu tất cả các lớp con
Graphic thwcj hiện thao tác Clone, sau đó GraphicTool có thể nhân bản
bất kỳ một dạng nào của Graphic.
Nên trong soạn thảo nhạc, mỗi công cụ tạo một đối tượng nhạc là một thể
hiện GraphicTool mà nó tạo với các mẫu khác nhau. Mỗi GraphicTool sẽ
tạo ra một đối tượng nhạc khi nhân bản mẫu của nó và thêm một nhân bản
tới điểm nhạc.
Có thể sử dụng Prototype pattern để làm giảm số lượng các lớp thậm chí

con số này còn nhiều hơn nữa. Ta chia các lớp cho toàn bộ ghi chú hoặc
phân nửa các ghi chú, nhưng cũng có thể không cần thiết. Thay vào đó
cỏc thể hiện của cùng một lớp được khởi tạo bởi các hình ảnh và thời gian
khác nhau.
3.2.2.4.3 Kết quả
Sử dụng Prototype khi một hệ thống độc lập với sản phẩm của nó được
tạo ra, kết cấu, và biểu diễn như thế nào.
Khi các lớp để khởi tạo được xác định tại thời gian chạy ; hoặc
Để tránh việc xây dựng một biểu đồ lớp của các factory tương đương với
biểu đồ lớp của các sản phẩm.
Khi các thể hiện của một lớp có thể có một trong một số các tổ hợp trạng
thái khác nhau. Nó thuận tiện hơn để cài đặt một số lượng các mẫu tương
đương và nhân bản chúng hơn là phải khởi tạo một lớp, tương đương với
mỗi thời điểm của trạng thái.
3.2.2.4.4 Cấu trúc
3.2.2.4.5 Thành phần :
Prototype: Khai báo một giao diện cho việc nhân bản bản thân nó.
ConcretePrototype: Thực hiện một thao tác để tự nhân bản nó.
Client: Tạo một đối tượng mới bởi việc yêu cầu nhân bản nguyên mẫu.
3.2.2.4.6 Phối hợp cộng tác
Một client yêu cầu một mẫu để tự nhân bản.
3.2.2.4.7 Kết qủa
Nó ẩn một số lớp sản phẩm concrete từ client, làm giảm số lượng tên của các
client biết về nó.
Các mẫu tạo điều kiện kết hợp một lớp sản phẩm thực hiện mới vào một hệ
thống một cách đơn giản bằng việc đăng kí một thể hiện mẫu với client. Hiệu
quả hơn là những mẫu khởi tạo khác, do một client có thể cài đặt và bác bỏ
các mẫu tại thời gian chạy.
Định nghĩa các đối tượng mới bằng cách biến đổi các giá trị. Các hệ thống
biến đổi động cao cho phép bạn định nghĩa hoạt động mới thông qua thành

phần đối tượng, bởi việc xác định các giá trị cho biến đối tượng.Vớ dụ bằng
Client
Operation()
Prototype
Clone()
P= prototype->Clone()
Return cocy of sell Return cocy of sell
ConcretePrototype1
Clone()
ConcretePrototype2
Clone()