Я намагався прочитати багато статей про dofactory , wikipedia та багатьох сайтах. Я не маю уявлення про відмінності між мостовою схемою та схемою стратегії.
Я знаю, що обидва вони відокремлюють абстракцію від її реалізації та можуть змінити реалізацію під час виконання.
Але я досі не знаю, в якій ситуації я повинен використовувати стратегію або в якій ситуації я повинен використовувати мост.
Відповіді:
Семантика. З Вікіпедії :
Діаграма класу UML для шаблону стратегії така ж, як діаграма для шаблону Bridge. Однак ці дві моделі дизайну не однакові за своїм наміром. Хоча модель стратегії призначена для поведінки, модель Bridge призначена для структури.
Зв'язок між контекстом і стратегіями є більш жорстким, ніж зв'язок між абстракцією та реалізацією в мостовій схемі.
Як я розумію, ви використовуєте шаблон стратегії, коли ви абстрагуєтесь від поведінки, яку можна надати із зовнішнього джерела (наприклад, config може вказати для завантаження деякої збірки плагінів), а ви використовуєте шаблон мосту, коли ви використовуєте ті ж конструкти, щоб зробити ваш код трохи охайнішим. Фактичний код буде виглядати дуже схоже - ви просто застосовуєте шаблони з дещо інших причин .
Шаблон Bridge є структурним малюнком (ЯК ВИ ЗБРОЮЄТЬСЯ КОМПОНЕНТ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ?). Шаблон стратегії - це динамічний малюнок (ЯК ВИ ХОЧЕТЕ ЗАПИТАТИ ПОВЕДІНКУ В ПЗ?).
Синтаксис схожий, але цілі різні:
Стратегія:
Намір - це здатність міняти поведінку під час виконання
class Context {
IStrategy strategyReference;
void strategicBehaviour() {
strategyReference.behave();
}
}
Міст
Намір полягає в тому, щоб повністю відірвати абстракцію від реалізації
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();
}
.............
}
Я думав так само, але нещодавно мені довелося скористатися мостом і зрозумів, що міст використовує стратегію і додає абстракцію контексту, щоб згодом ви могли вносити більше змін, не змінюючи клієнта. При використанні стратегії без абстракції дизайн не настільки гнучкий і може зажадати клієнта змін пізніше. Але при використанні всього моста конструкція стає ще більш гнучкою. Тут ви можете зрозуміти, як перехід від стратегії до мосту дає більшу гнучкість. Також ми припускаємо, що зараз "віза" та "майстер" доступні не лише на картках, але й на телефонах та мікросхемах; і якщо ми використовуємо міст, набагато простіше додати цю підтримку.
Міст : (структурний зразок)
Модель мосту деакулює абстракцію та реалізацію і дозволяє обидві змінюватись незалежно.
Скористайтеся цією схемою, коли:
Стратегія: (поведінковий зразок)
Шаблони стратегій дозволяють перемикатися між декількома алгоритмами з сімейства алгоритмів під час виконання.
Використовуйте шаблон стратегії, коли:
Схожі повідомлення:
Коли ви використовуєте шаблон моста? Чим вона відрізняється від моделі адаптера?
Типи шаблонів дизайну
Міст (конструкційний)
Розв'яжіть абстракцію від її реалізації, щоб кожна могла відрізнятися. незалежно.
Візьміть пульт. У пульті є кнопки 1-6. Це конкретний клас на наведеній вище схемі. Кожна кнопка працюватиме по-різному, залежно від того, чи використовується пульт дистанційного керування для телевізора чи DVD-диска. Функціональність кожної кнопки обмежується реалізацією інтерфейсом реалізації.
Це дозволяє нам змінити, як буде працювати пульт для кожного пристрою.
Стратегія (поведінкова)
Визначте сімейство алгоритмів, інкапсулюйте кожен і зробіть їх взаємозамінними.
У стратегії, якби ми дивилися на віддалений сценарій. "Стан" - це все дистанційне управління, яке ми замінюємо, змінюючи посилання на стан контексту. "ConcreteStateA" (дистанційний телевізор) "concreteStateB" (DVD Remote).
Додаткове читання:
Шаблон стратегії використовується для поведінкових рішень, тоді як мостовий шаблон використовується для структурних рішень.
Brigde Pattern відокремлює абстрактні елементи від деталей реалізації, тоді як стратегія Шаблон стосується того, щоб алгоритми були взаємозамінними.
Шаблон стратегії в 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")
Бриґдський візерунок у Свіфті:
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()
Stereoз TVі код просто працює.
Додавши до відповіді willcodejavaforfood, вони можуть бути однаковими, при здійсненні. Однак ви використовуєте стратегію для обміну стратегіями, такими як стратегія сортування, в той час як ви використовуєте міст для перенесення реалізацій двох об'єктів, наприклад, обгортки бази даних та мережевого адаптера, щоб клієнтський код міг використовувати або працюючи проти того ж API. Тож найменування насправді все це говорить
З вікі про шаблон стратегії
Діаграма класу UML для шаблону стратегії така ж, як діаграма для шаблону Bridge. Однак ці дві моделі дизайну не однакові за своїм наміром. Хоча модель стратегії призначена для поведінки, модель Bridge призначена для структури.
Зв'язок між контекстом і стратегіями є більш жорстким, ніж зв'язок між абстракцією та реалізацією в мостовій схемі.
Просто для додання того, що вже було сказано про порівняння шаблонів (різниця намірів, ...): модель Bridge також навмисно структурована, щоб дати можливість ієрархії абстракції змінюватися. У таких мовах, як C #, це може означати, що у вас є база абстрагування, яка містить віртуальні методи як спосіб дозволити передбачувані зміни, які не створюють проблем існуючим споживачам. Крім цього, ці два візерунки можуть здебільшого здаватися однаковими.
Шаблон стратегії використовується, коли ви хочете підключити алгоритм або стратегію під час виконання. Як категорія шаблону також мається на увазі, що він має справу з поведінкою об'єктів. З іншого боку міст є структурною схемою і стосується структурної ієрархії об'єктів. Це відокремлює абстракцію від реалізації, вводячи між собою вишукану абстракцію. Вдосконалене абстрагування можна сплутати із підключеною стратегією часу виконання (у шаблоні стратегії). Модель мосту стосується структурних аспектів, забезпечуючи механізм уникнення створення n кількості класів.
Для структури стратегії змінюється лише реалізація.
Припустимо, клас A використовує клас B, у якому доступно кілька реалізацій. Так що в такому випадку B буде абстрактним з реальною реалізацією, наданою під час виконання. Це стратегія
Тепер якщо A є абстрактним. І А, і В можуть відрізнятися. Ви б використовували шаблон моста.
Я думаю, що між ними є незначна різниця в контексті, яким вони користуються.
Я використовую схему Бридж, щоб розділити ортогональні поняття, до яких вони належать до більшого - щоб вони змінювалися незалежно. Зазвичай це включає кілька абстракцій.
IMO, модель стратегії є простішою або більш простою. Він слугує OCP точно, але не обов'язково є частиною іншої та більшої концепції, як, наприклад, модель Bridge.