Câu trả lời (1)
Có thể ứng dụng Strategy trong những trường hợp sau: Nhiều lớp liên quan chỉ khác nhau ở cách xửlý yêu cầu. Với 1 lựa chọn trong những cách xử lý Strategy giúp ta thực hiện trách nhiệm của 1 lớp. Có nhiều cách thực hiện cùng một thuật toán. Phải cho khách hàng khả nng lựa chọn cách ưu việt nhất trong sử dụng tài nguyên như chỗ và thời gian. Nên dùng Strategy khi các thuật toán này được thể hiện như môt cơcấu lớp của các thuật toán. Thuật toán dùng dữ liệu mà khách hàng không biết tới. Dùng Strategy để thay thế việc công khai hoá những cấu trúc dữ liệu phức tạp, đặc thù cho thuật toán. Khách hàng định nghĩa nhiều cách xử lý khác nhau và những cách xử lý này có thể coi nhưcâu lệnh chia nhánh ( if- then- elsif, switch) trong phương thức. Thay vì dùng cấu trúc điều kiện ta dùng các lớp Strategy cài đặt riêng từng nhánh.
Cấu trúc
Các lớp tham gia(Participants) Strategy (Compositor) - Địng nghĩa giao diện chung cho các thuật toán được cài đặt. Context dùng giao diện này để gọi những thuật toán được thực hiện trong những ConcreteStrategy (Strategey cụ thể) ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor) - Cài đặt các thuật toán sử dụng giao diện Strategy Context (môi trường)- (Composition) - Được hiệu chỉnh bằng 1 đối tượng Strategy -Bảo dưỡng tham chiếu tới đối tượng Strategy - Có thể định nghĩa giao diện cho Strategy dùng được dữ liệu của nó
Phối hợp(Colaboration) - Strategy và Context trao đổi thông tin để thực hiện thuật toán. Context có thể chuyển cho Strategy tất cả dữ liệu khi thuật toán được gọi. Giải pháp khác là Context chuyển chính nó cho Strategy như một hàm số. Strategy gọi lại những phương thức được định nghĩa trong giao diện của Context để hỏi dữ liệu. - Context chuyển lời gọi phương thức từ khách hàng của nó cho Strategy. Khách hàng thường tạo ra và chuyển cho Context một ConcreteStrategy, sau đó khách hàng chỉ trao đổi thông tin với Context. Thông thường khách hàng có thể lựa chọn ConcreteStrategy từ 1 tập hợp thuật toán cho trước.
Kết quả(Consequences) Strategy có những ưu khuyết điểm sau: Tập trung và hệ thống hóa những thuât toán có liên quan. Hệ thống thừa kế của các lớp Strategy định nghĩa một gia đình của các thuật toán hoặc cách xử lý hiện tượng cho môi trường dùng. Thừa kế giúp ta thể hiện được phần chung trong tác dụng của các thuật toán. Một sự chọn lựa khác thay cho thừa kế. Bằng thừa kế ta cũng có thể phối hợp nhiều kiểu thuật toán và cách xử lý hiện tượng. Ta có thể thừa kế trực tiếp từ Context và cho nónhững sử sự khác nhau. Nhưng giải pháp này gắn chặt cách xử lý hiện tượng vào đối tượng Context, gây ra lẫn giữa cài đặt thuật toán và Context, gây khó khăn cho việc học, bảo dưỡng, mở rộng Context, vàchúng ta không thể kết hợp các thuật toán một cách ling động. Giải pháp này sẽ tạo ra rất nhiều lớp tương tự, chỉ khác nhau ở thuật toán hoặc cách xử lý hiện tượng mà chúng thực hiện. Bao bọc thuật toán bởi các lớp khác nhau cho ta kết hợp các thuật toán độc lập đối với môi trường sử dụng, đơn giản hoá việc hiểu, chọn và mở rộng từng thuật toán. Bỏ đi các câu lệnh điều kiện (if-then-else, switch). Mẫu thiết kế Strategy cho ta một cách giải quyết khác ngoài cách dùng câu lệnh điều kiện trong quá trình chọn cách xử lý thích hợp. Khi những cách xử lý khác nhau bị gói vào một lớp, dùng câu lệnh điều kiện để chọn thao tách thích hợp rất khó khăn. Ta có thể thay những câu lệnh này bằng cách bao bọc các thuật toán bởi các lớp khác nhau. Ví dụ nếu không có Strategy, việc "chia dòng" được thực hiện như sau:
void Composition::Repair ()
{
switch (_breakingStrategy)
{
case SimpleStrategy:
ComposeWithSimpleCompositor();
break;
case TeXStrategy:
ComposeWithTeXCompositor();
break;
// ...
}
// merge results with existing composition, if necessary (gắn kết
//quảvới phần đã làm được)
}
Mẫu thiết kế Strategy thay việc sử dụng câu lệnh điều kiện bằng ủy nhiệm việc chia dòng cho đối tượng Strategy:
void Composition::Repair ()
{
_compositor->Compose();
// merge results with existing composition, if necessary(gắn kết
// quả với phần đã làm được)
}
Mã nguồn chứa câu lệnh điều kiện nhiều nhánh làtrường hợp khi ta lên nghiên cứu xem dùmg mẫu Strategy có phải làgiải pháp thích hợp hơn không. Lựa chọn về cách cài đặt. Strategycó thể cài đặt cùng một kiểu xử lý bằng nhiều cách khác nhau. Khách hàng có điều kiện chọn giữa nhiều cách thực hiện với yêu cầu về chỗ và thời gian khác nhau. (khách hàng sẽ chọn cách thực hiện tối ưu nhất đối với nó trong từng trường hợp cụ thể) Khách hàng phải biết vềcác Strategy. Nhược điểm hiển nhiên của Strategy là khách hàng phải nhận biết về các Strategy trước khi chọn cái thích hợp, như vậy khách hàng cóthể bị "gò ép" theo những yêu cầu nảy sinh trong quátrình cài đặt cụthể.Chỉ nên dùng Strategy khi sự thay đổi về cách xử lý là rất quan trọng đối với khách hàng. Quá tải thông tin giữa Strategy và Context. Giao diện của Context được công khai hoá cho tất cảStrategy cụ thể, dù thuật toán được thực hiện phức tạp hay đơn giản. Rõràng là nhiều Strategy sẽ không dùng hết những thông tin có thểnhận được thông qua giao diện này, Strategy đơn giản thậm chí hoàn toàn không dùng giao diện. Điều này có nghĩa là Context có thể tạo ra và cho giá trị mặc định cảnhững tham chiếu mà nó không bao giờ được dùng đến. Khi đó bạn sẽ có mối quan hệ qua khăng khít giữa Strategy vàContext. Tăng số đối tượng. Strategy làm tăng số đối tượng trong hệ thống. Ta có thể giảm bớt bằng cách làm những Strategy vô trạng thái (dữ liệu) để nhiều đối tượng dùng chung (share). Những trạng thái cần thiết sẽ được bảo dưỡng bởi môi trường và được chuyển cho trategy như các tham chiếu. Strategy dùng chung không bảo dưỡng được trạng thái qua những lần được sử dụng. Mẫu thiết kế Flightweight(195) sẽ đề cập cụ thể hơn đến vấn đề này.
Cấu trúc
Các lớp tham gia(Participants) Strategy (Compositor) - Địng nghĩa giao diện chung cho các thuật toán được cài đặt. Context dùng giao diện này để gọi những thuật toán được thực hiện trong những ConcreteStrategy (Strategey cụ thể) ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor) - Cài đặt các thuật toán sử dụng giao diện Strategy Context (môi trường)- (Composition) - Được hiệu chỉnh bằng 1 đối tượng Strategy -Bảo dưỡng tham chiếu tới đối tượng Strategy - Có thể định nghĩa giao diện cho Strategy dùng được dữ liệu của nó
Phối hợp(Colaboration) - Strategy và Context trao đổi thông tin để thực hiện thuật toán. Context có thể chuyển cho Strategy tất cả dữ liệu khi thuật toán được gọi. Giải pháp khác là Context chuyển chính nó cho Strategy như một hàm số. Strategy gọi lại những phương thức được định nghĩa trong giao diện của Context để hỏi dữ liệu. - Context chuyển lời gọi phương thức từ khách hàng của nó cho Strategy. Khách hàng thường tạo ra và chuyển cho Context một ConcreteStrategy, sau đó khách hàng chỉ trao đổi thông tin với Context. Thông thường khách hàng có thể lựa chọn ConcreteStrategy từ 1 tập hợp thuật toán cho trước.
Kết quả(Consequences) Strategy có những ưu khuyết điểm sau: Tập trung và hệ thống hóa những thuât toán có liên quan. Hệ thống thừa kế của các lớp Strategy định nghĩa một gia đình của các thuật toán hoặc cách xử lý hiện tượng cho môi trường dùng. Thừa kế giúp ta thể hiện được phần chung trong tác dụng của các thuật toán. Một sự chọn lựa khác thay cho thừa kế. Bằng thừa kế ta cũng có thể phối hợp nhiều kiểu thuật toán và cách xử lý hiện tượng. Ta có thể thừa kế trực tiếp từ Context và cho nónhững sử sự khác nhau. Nhưng giải pháp này gắn chặt cách xử lý hiện tượng vào đối tượng Context, gây ra lẫn giữa cài đặt thuật toán và Context, gây khó khăn cho việc học, bảo dưỡng, mở rộng Context, vàchúng ta không thể kết hợp các thuật toán một cách ling động. Giải pháp này sẽ tạo ra rất nhiều lớp tương tự, chỉ khác nhau ở thuật toán hoặc cách xử lý hiện tượng mà chúng thực hiện. Bao bọc thuật toán bởi các lớp khác nhau cho ta kết hợp các thuật toán độc lập đối với môi trường sử dụng, đơn giản hoá việc hiểu, chọn và mở rộng từng thuật toán. Bỏ đi các câu lệnh điều kiện (if-then-else, switch). Mẫu thiết kế Strategy cho ta một cách giải quyết khác ngoài cách dùng câu lệnh điều kiện trong quá trình chọn cách xử lý thích hợp. Khi những cách xử lý khác nhau bị gói vào một lớp, dùng câu lệnh điều kiện để chọn thao tách thích hợp rất khó khăn. Ta có thể thay những câu lệnh này bằng cách bao bọc các thuật toán bởi các lớp khác nhau. Ví dụ nếu không có Strategy, việc "chia dòng" được thực hiện như sau:
void Composition::Repair ()
{
switch (_breakingStrategy)
{
case SimpleStrategy:
ComposeWithSimpleCompositor();
break;
case TeXStrategy:
ComposeWithTeXCompositor();
break;
// ...
}
// merge results with existing composition, if necessary (gắn kết
//quảvới phần đã làm được)
}
Mẫu thiết kế Strategy thay việc sử dụng câu lệnh điều kiện bằng ủy nhiệm việc chia dòng cho đối tượng Strategy:
void Composition::Repair ()
{
_compositor->Compose();
// merge results with existing composition, if necessary(gắn kết
// quả với phần đã làm được)
}
Mã nguồn chứa câu lệnh điều kiện nhiều nhánh làtrường hợp khi ta lên nghiên cứu xem dùmg mẫu Strategy có phải làgiải pháp thích hợp hơn không. Lựa chọn về cách cài đặt. Strategycó thể cài đặt cùng một kiểu xử lý bằng nhiều cách khác nhau. Khách hàng có điều kiện chọn giữa nhiều cách thực hiện với yêu cầu về chỗ và thời gian khác nhau. (khách hàng sẽ chọn cách thực hiện tối ưu nhất đối với nó trong từng trường hợp cụ thể) Khách hàng phải biết vềcác Strategy. Nhược điểm hiển nhiên của Strategy là khách hàng phải nhận biết về các Strategy trước khi chọn cái thích hợp, như vậy khách hàng cóthể bị "gò ép" theo những yêu cầu nảy sinh trong quátrình cài đặt cụthể.Chỉ nên dùng Strategy khi sự thay đổi về cách xử lý là rất quan trọng đối với khách hàng. Quá tải thông tin giữa Strategy và Context. Giao diện của Context được công khai hoá cho tất cảStrategy cụ thể, dù thuật toán được thực hiện phức tạp hay đơn giản. Rõràng là nhiều Strategy sẽ không dùng hết những thông tin có thểnhận được thông qua giao diện này, Strategy đơn giản thậm chí hoàn toàn không dùng giao diện. Điều này có nghĩa là Context có thể tạo ra và cho giá trị mặc định cảnhững tham chiếu mà nó không bao giờ được dùng đến. Khi đó bạn sẽ có mối quan hệ qua khăng khít giữa Strategy vàContext. Tăng số đối tượng. Strategy làm tăng số đối tượng trong hệ thống. Ta có thể giảm bớt bằng cách làm những Strategy vô trạng thái (dữ liệu) để nhiều đối tượng dùng chung (share). Những trạng thái cần thiết sẽ được bảo dưỡng bởi môi trường và được chuyển cho trategy như các tham chiếu. Strategy dùng chung không bảo dưỡng được trạng thái qua những lần được sử dụng. Mẫu thiết kế Flightweight(195) sẽ đề cập cụ thể hơn đến vấn đề này.
22/04/2010
QA.congchua
Giới thiệu về câu hỏi này
Điểm thưởng cho câu trả lời hay nhất 10 điểm
966 lượt xem
1 câu trả lời đã đăng
x