Dofactory , wikipedia ve birçok site hakkında birçok makale okumaya çalıştım . Köprü modeli ile strateji modeli arasındaki farklar hakkında hiçbir fikrim yok.
Her ikisinin de bir soyutlamayı uygulamasından ayırdığını ve uygulamayı çalışma zamanında değiştirebileceğini biliyorum.
Ama yine de hangi durumda strateji kullanmalıyım veya hangi durumda briç kullanmalıyım bilmiyorum.
Yanıtlar:
Semantik. Gönderen wikipedia :
Strateji modeli için UML sınıf diyagramı, Köprü modelinin diyagramı ile aynıdır. Bununla birlikte, bu iki tasarım modeli amaçlarında aynı değildir. Strateji modeli davranış içindir, Köprü modeli ise yapı içindir.
Bağlam ve stratejiler arasındaki bağlantı, Köprü modelindeki soyutlama ve uygulama arasındaki bağlantıdan daha sıkıdır.
Anladığım kadarıyla, harici bir kaynaktan sağlanabilecek davranışı soyutlarken strateji modelini kullanıyorsunuz (ör. Config, bazı eklenti derlemelerini yüklemeyi belirtebilir) ve kullandığınızda köprü modelini kullanıyorsunuz kodunuzu biraz daha düzgün hale getirmek için aynı yapılar. Gerçek kod çok benzer görünecektir - sadece kalıpları uyguluyorsunuz biraz farklı nedenlerle .
Köprü kalıbı yapısal bir kalıptır (BİR YAZILIM BİLEŞENİNİ NASIL YAPARSINIZ?). Strateji modeli dinamik bir modeldir (YAZILIMDA NASIL BİR DAVRANIŞI ÇALIŞTIRMAK İSTİYORSUNUZ?).
Sözdizimi benzerdir ancak hedefler farklıdır:
Strateji:
Amaç, çalışma zamanında davranışı değiştirebilme yeteneğidir
class Context {
IStrategy strategyReference;
void strategicBehaviour() {
strategyReference.behave();
}
}
Köprü
Amaç, Soyutlamayı Uygulamadan tamamen ayırmaktır.
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();
}
.............
}
Ben de aynı şeyi düşünüyordum, ancak son zamanlarda bridge'i kullanmak zorunda kaldım ve köprünün stratejiyi kullandığını ve bağlama soyutlama eklediğini fark ettim, böylece daha sonra müşteriyi değiştirmeden daha fazla değişiklik yapabilirsiniz. Stratejiyi soyutlama olmadan kullanırken, tasarım o kadar esnek değildir ve daha sonra müşteride değişiklikler gerektirebilir. Ancak tüm köprüyü kullanırken tasarım daha da esnek hale gelir. Burada, Stratejiden Bridge'e geçmenin nasıl daha fazla esneklik sağladığını görebilirsiniz. Ayrıca artık "visa" ve "master" ın yalnızca kartlarda değil, telefonlarda ve çiplerde de mevcut olduğunu varsayıyoruz; ve eğer köprü kullanırsak bu desteği eklemek çok daha kolay.
Köprü : (Yapısal bir model)
Köprü paterni, soyutlamayı ve uygulamayı ayırır ve her ikisinin de bağımsız olarak değişmesine izin verir.
Bu kalıbı şu durumlarda kullanın:
Strateji: (Davranışsal kalıp)
Strateji kalıpları, çalışma zamanında bir algoritma ailesinden birden çok algoritma arasında geçiş yapmanızı sağlar.
Şu durumlarda Strateji modelini kullanın:
İlgili Mesajlar:
Köprü Modelini ne zaman kullanıyorsunuz? Adaptör modelinden farkı nedir?
Tasarım deseni türleri
Köprü (Yapısal)
Her birinin farklı olabilmesi için bir soyutlamayı uygulamasından ayırın. bağımsız.
Uzaktan kumandayı al. Uzaktan kumandanın 1-6 düğmeleri vardır. Bu, yukarıdaki şemadaki somut sınıftır. Uzaktan kumandanın TV veya DVD için kullanılıp kullanılmadığına bağlı olarak her düğme farklı çalışacaktır. Her düğmenin işlevselliği, uygulayıcı arabirimi tarafından uygulamadan soyutlanmıştır.
Bu, uzaktan kumandanın her cihaz için nasıl çalışacağını değiştirmemize olanak tanır.
Strateji (Davranışsal)
Bir algoritma ailesi tanımlayın, her birini kapsülleyin ve birbirinin yerine kullanılabilir hale getirin.
Stratejide, uzak senaryoya bakarsak. "Durum", bağlamın durum referansını değiştirerek değiştirdiğimiz uzaktan kumandanın tamamıdır. "ConcreteStateA" (TV uzaktan kumandası) "ConcreteStateB" (DVD Uzaktan Kumandası).
Ek okuma:
Strateji Modeli, Davranışsal kararlar için kullanılırken, Yapısal kararlar için Köprü Modeli kullanılır.
Brigde Pattern, soyut öğeleri uygulama ayrıntılarından ayırırken, Strategy Pattern algoritmaları daha değiştirilebilir hale getirmekle ilgilenir.
Swift'de Strateji Modeli:
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")
Swift Brigde Deseni:
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()
Stereoile TVve kod sadece çalışır.
Willcodejavaforfood'un cevabına ek olarak, uygulamada aynı olabilirler. Ancak, iki nesnenin uygulamalarını köprülemek için köprü kullanırken, örneğin bir veritabanı sarmalayıcısı ve bir ağ bağdaştırıcısının istemci kodunun aynı API'ye karşı her iki çalışmayı da kullanabilmesi için strateji kullanırken, sıralama stratejisi gibi stratejileri değiştirmek için stratejiyi kullanırsınız. Yani adlandırma aslında her şeyi söylüyor
Strateji kalıbı üzerine wiki'den
Strateji modeli için UML sınıf diyagramı, Köprü modelinin diyagramı ile aynıdır. Bununla birlikte, bu iki tasarım modeli amaçlarında aynı değildir. Strateji modeli davranış içindir, Köprü modeli ise yapı içindir.
Bağlam ve stratejiler arasındaki bağlantı, Köprü modelindeki soyutlama ve uygulama arasındaki bağlantıdan daha sıkıdır.
Model karşılaştırması hakkında daha önce söylenenlere eklemek için (niyet farkı, ...): Köprü modeli, soyutlama hiyerarşisi tarafının değişmesine izin verecek şekilde kasıtlı olarak yapılandırılmıştır. C # gibi dillerde bu, mevcut tüketiciler için sorun yaratmayan amaçlanan varyasyonlara izin vermenin bir yolu olarak sanal yöntemler içeren bir soyutlama tabanına sahip olduğunuz anlamına gelebilir. Bunun dışında iki model çoğu zaman aynı görünebilir.
Strateji kalıbı, çalışma zamanında algoritma veya strateji eklemek istediğinizde kullanılır. Kalıp kategorisi aynı zamanda nesnelerin davranışlarıyla ilgilendiğini ima eder. Öte yandan köprü yapısal bir modeldir ve nesnelerin yapısal hiyerarşisiyle ilgilenir. Aralarına rafine bir soyutlama getirerek soyutlamayı uygulamadan ayırır. Rafine soyutlama, çalıştırma süresi stratejisi takılıyken karıştırılabilir (In Strategy modeli). Köprü modeli, n sayıda sınıf oluşturmaktan kaçınmak için bir mekanizma sağlayarak yapısal unsurlarla ilgilenir.
Yalnızca strateji modeli için uygulama değişir.
Diyelim ki, sınıf A, birden fazla uygulamaya sahip olan B sınıfını kullanıyor. Yani bu durumda B, çalışma zamanında sağlanan gerçek uygulama ile soyut olacaktır. Bu strateji modelidir
Şimdi eğer A'nın kendisi soyutsa. Hem A hem de B değişebilir. Köprü desenini kullanırsınız.
Bence kullanıldıkları bağlamda aralarında küçük bir fark var.
Köprü modelini, her ikisinin de daha büyük bir tanesine ait olduğu ortogonal kavramları ayırmak için kullanıyorum - bağımsız olarak değişmelerine izin vermek için. Genellikle birden fazla soyutlamayı içerir.
IMO, Strateji modeli daha basit veya daha düz. Kesinlikle OCP'ye hizmet eder, ancak Köprü modeli gibi başka ve daha büyük bir konseptin parçası olması gerekmez.