Tôi đã cố gắng đọc nhiều bài báo trên dofactory , wikipedia và nhiều trang. Tôi không biết về sự khác biệt giữa mô hình cầu và mô hình chiến lược.
Tôi biết cả hai đều tách một phần trừu tượng khỏi việc triển khai của nó và có thể thay đổi việc triển khai tại thời điểm chạy.
Nhưng tôi vẫn chưa biết mình nên sử dụng chiến thuật hay tình huống nào thì nên dùng cầu.
Câu trả lời:
Ngữ nghĩa học. Từ wikipedia :
Biểu đồ lớp UML cho mẫu Chiến lược giống như biểu đồ cho mẫu Cầu. Tuy nhiên, hai mẫu thiết kế này không giống nhau về mục đích của chúng. Trong khi mô hình Chiến lược dành cho hành vi, thì mô hình Cầu có nghĩa là cho cấu trúc.
Sự kết hợp giữa bối cảnh và các chiến lược chặt chẽ hơn sự kết hợp giữa phần trừu tượng và phần triển khai trong mẫu Bridge.
Theo tôi hiểu, bạn đang sử dụng mẫu chiến lược khi bạn đang trừu tượng hóa hành vi có thể được cung cấp từ nguồn bên ngoài (ví dụ: cấu hình có thể chỉ định để tải một số lắp ráp plugin) và bạn đang sử dụng mẫu cầu nối khi bạn sử dụng các cấu trúc giống nhau để làm cho mã của bạn gọn gàng hơn một chút. Mã thực tế sẽ trông rất giống nhau - bạn chỉ đang áp dụng các mẫu vì những lý do hơi khác nhau .
Bridge pattern là một mẫu cấu trúc (LÀM THẾ NÀO ĐỂ BẠN XÂY DỰNG MỘT THÀNH PHẦN PHẦN MỀM?). Mô hình Chiến lược là một mô hình động (BẠN MUỐN CHẠY MỘT HÀNH VI TRONG PHẦN MỀM NHƯ THẾ NÀO?).
Cú pháp tương tự nhưng mục tiêu khác nhau:
Chiến lược:
Intent là khả năng hoán đổi hành vi trong thời gian chạy
class Context {
IStrategy strategyReference;
void strategicBehaviour() {
strategyReference.behave();
}
}
Cầu
Mục đích là tách hoàn toàn phần Trừu tượng khỏi phần Triển khai
interface IAbstraction {
void behaviour1();
.....
}
interface IImplementation {
void behave1();
void behave2();
.....
}
class ConcreteAbstraction1 implements IAbstraction {
IImplementation implmentReference;
ConcreteAbstraction1() {
implmentReference = new ImplementationA() // Some implementation
}
void behaviour1() {
implmentReference.behave1();
}
.............
}
class ConcreteAbstraction2 implements IAbstraction {
IImplementation implmentReference;
ConcreteAbstraction1() {
implmentReference = new ImplementationB() // Some Other implementation
}
void behaviour1() {
implmentReference.behave2();
}
.............
}
Tôi cũng nghĩ như vậy, nhưng gần đây tôi đã phải sử dụng cầu nối và nhận ra rằng cầu nối đang sử dụng chiến lược và thêm tính trừu tượng vào ngữ cảnh để sau này bạn có thể thực hiện nhiều thay đổi hơn mà không cần thay đổi ứng dụng khách. Khi sử dụng Strategy mà không có phần trừu tượng, thiết kế sẽ không linh hoạt và có thể yêu cầu khách hàng thay đổi sau này. Nhưng khi sử dụng toàn bộ cây cầu, thiết kế thậm chí còn trở nên linh hoạt hơn. Tại đây bạn có thể biết cách chuyển từ Chiến lược sang Cầu nối mang lại sự linh hoạt hơn. Ngoài ra, chúng tôi giả định rằng bây giờ "visa" và "master" không chỉ có sẵn trên thẻ mà còn trên điện thoại và chip; và nếu chúng ta sử dụng cầu nối thì việc thêm hỗ trợ đó sẽ dễ dàng hơn nhiều.
Cầu : (Một mẫu cấu trúc)
Mẫu cầu nối tách rời sự trừu tượng và việc thực hiện và cho phép cả hai thay đổi một cách độc lập.
Sử dụng mẫu này khi:
Chiến lược: (Mô hình hành vi)
Các mẫu chiến lược cho phép bạn chuyển đổi giữa nhiều thuật toán từ một nhóm thuật toán tại thời điểm chạy.
Sử dụng mẫu Chiến lược khi:
Bài viết liên quan:
Khi nào bạn sử dụng Bridge Pattern? Nó khác với mẫu Adapter như thế nào?
Các kiểu thiết kế
Cầu (Kết cấu)
Tách một phần trừu tượng khỏi việc triển khai của nó để mỗi phần có thể khác nhau. một cách độc lập.
Lấy điều khiển từ xa. Điều khiển từ xa có các nút 1-6. Đây là lớp bê tông trong sơ đồ trên. Mỗi nút sẽ hoạt động khác nhau tùy thuộc vào việc điều khiển từ xa được sử dụng cho TV hay DVD. Chức năng cho mỗi nút được trừu tượng hóa từ việc triển khai bởi giao diện người triển khai.
Điều này cho phép chúng tôi thay đổi cách điều khiển từ xa sẽ hoạt động cho từng thiết bị.
Chiến lược (hành vi)
Xác định một nhóm thuật toán, đóng gói từng thuật toán và làm cho chúng có thể hoán đổi cho nhau.
Về chiến lược, nếu chúng ta đang nhìn vào viễn cảnh từ xa. "Trạng thái" là toàn bộ điều khiển từ xa mà chúng tôi hoán đổi bằng cách thay đổi tham chiếu trạng thái của ngữ cảnh. "Bê tôngStateA" (Điều khiển TV) "Bê tôngStateB" (Điều khiển Từ xa DVD).
Đọc thêm:
Mô hình Chiến lược được sử dụng cho các quyết định Hành vi, trong khi Mô hình Cầu nối được sử dụng cho các quyết định Cấu trúc.
Brigde Pattern tách các phần tử trừu tượng khỏi các chi tiết triển khai, trong khi Strategy Pattern quan tâm đến việc làm cho các thuật toán có thể hoán đổi cho nhau nhiều hơn.
Mô hình chiến lược trong Swift:
protocol PrintStrategy {
func print(_ string: String) -> String
}
class Printer {
let strategy: PrintStrategy
init(strategy: PrintStrategy) {
self.strategy = strategy
}
func print(_ string: String) -> String {
return self.strategy.print(string)
}
}
class UpperCaseStrategy: PrintStrategy {
internal func print(_ string: String) -> String {
return string.uppercased()
}
}
class LowerCaseStrategy: PrintStrategy {
internal func print(_ string: String) -> String {
return string.lowercased()
}
}
var lower = Printer(strategy: LowerCaseStrategy())
lower.print("I love Software Patterns")
var upper = Printer(strategy: UpperCaseStrategy())
upper.print("I love Software Patterns")
Mẫu Brigde trong Swift:
protocol Appliance {
func run()
}
protocol Switch {
let appliance: Appliance {get set}
func turnOn()
}
class RemoteControl: Switch {
var appliance: Appliance
init(appliance: Appliance) {
self.appliance = appliance
}
internal func turnOn() {
appliance.run()
}
}
class TV: Appliance {
internal func run() {
print("TV is ON")
}
}
class Stereo: Appliance {
internal func run() {
print("Stereo is ON")
}
}
var tvRemote = RemoteControl.init(appliance: TV())
tvRemote.turnOn()
var stereoRemote = RemoteControl.init(appliance: Stereo())
stereoRemote.turnOn()
Stereovới TVvà mã chỉ hoạt động.
Thêm vào câu trả lời của willcodejavaforfood, chúng có thể giống nhau, trong cách triển khai. Tuy nhiên, bạn sử dụng chiến lược để hoán đổi các chiến lược, chẳng hạn như chiến lược sắp xếp, trong khi bạn sử dụng cầu nối để kết nối việc triển khai của hai đối tượng nói rằng một trình bao bọc cơ sở dữ liệu và một bộ điều hợp mạng để mã máy khách có thể sử dụng hoạt động với cùng một API. Vì vậy, việc đặt tên thực sự nói lên tất cả
Từ wiki về mẫu chiến lược
Biểu đồ lớp UML cho mẫu Chiến lược giống như biểu đồ cho mẫu Cầu. Tuy nhiên, hai mẫu thiết kế này không giống nhau về mục đích của chúng. Trong khi mô hình Chiến lược dành cho hành vi, thì mô hình Cầu có nghĩa là cho cấu trúc.
Sự kết hợp giữa bối cảnh và các chiến lược chặt chẽ hơn sự kết hợp giữa phần trừu tượng và phần triển khai trong mẫu Bridge.
Chỉ để thêm vào những gì đã nói về so sánh mẫu (sự khác biệt về mục đích, ...): mẫu Cầu cũng được cấu trúc có chủ ý để cho phép mặt phân cấp trừu tượng thay đổi. Trong các ngôn ngữ như C #, điều này có thể ngụ ý rằng bạn có một cơ sở trừu tượng có chứa các phương thức ảo như một cách để cho phép các biến thể dự kiến không gây ra vấn đề cho người tiêu dùng hiện tại. Ngoài ra, hai mẫu có thể trông giống hệt nhau trong hầu hết các phần.
Mẫu chiến lược được sử dụng khi bạn muốn cài đặt thuật toán hoặc chiến lược tại thời điểm chạy. Như thể loại của mẫu cũng ngụ ý rằng nó xử lý hành vi của các đối tượng. Mặt khác, cây cầu là mô hình cấu trúc và giải quyết hệ thống phân cấp cấu trúc của các đối tượng. Nó tách biệt phần trừu tượng khỏi việc triển khai bằng cách giới thiệu một phần trừu tượng tinh tế giữa chúng. Sự trừu tượng đã được trau chuốt có thể bị nhầm lẫn với chiến lược thời gian chạy được cài đặt sẵn (Trong mẫu Chiến lược). Bridge pattern xử lý các khía cạnh cấu trúc bằng cách cung cấp một cơ chế để tránh tạo ra n số lớp.
Đối với mô hình chiến lược chỉ khác nhau việc triển khai.
Giả sử, lớp A đang sử dụng lớp B có nhiều triển khai có sẵn. Vì vậy, trong trường hợp đó B sẽ trừu tượng với việc triển khai thực tế được cung cấp trong thời gian chạy. Đây là mô hình chiến lược
Bây giờ nếu bản thân A là trừu tượng. Cả A và B có thể khác nhau. Bạn sẽ sử dụng mô hình Cầu.
Tôi nghĩ rằng có một chút khác biệt giữa chúng trong bối cảnh chúng đang được sử dụng.
Tôi sử dụng mô hình Cầu để phân tách các khái niệm trực giao mà cả hai đều thuộc về một khái niệm lớn hơn - để chúng khác nhau một cách độc lập. Nó thường liên quan đến nhiều sự trừu tượng.
IMO, mô hình Chiến lược đơn giản hơn hoặc phẳng hơn. Nó phục vụ cho OCP chắc chắn nhưng không nhất thiết phải là một phần của một khái niệm khác và lớn hơn như mô hình Bridge.