Re: [請教] bridge versus strategy pattern

看板OOAD作者leondemon (狗狗)時間13年前 (2011/04/17 01:20)推噓2(2推 0噓 0→)

留言2則, 2人參與討論串2/3 (看更多)

wiki: http://en.wikipedia.org/wiki/Strategy_pattern "However, these two design patterns aren't the same in their intent. While the Strategy pattern is meant for behavior, the Bridge pattern is meant for structure." OOD(strategy): http://www.oodesign.com/strategy-pattern.html "Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it." OOD(bridge): http://www.oodesign.com/bridge-pattern.html "The intent of this pattern is to decouple abstraction from implementation so that the two can vary independently." Strategy和Bridge兩者就UML上看起來類似但是使用意圖卻大為不同 Stragety: 講求的是「同一類別」的物件能夠「彈性地擴充」其物件的行為來滿足客戶的需求也就是在不動到原本的物件的程式碼的情況下另外創造一個物件來處理行為的演算法而提供一個隨時可以改變的行為物件 Bridge: 講求的是在「不同類別」的物件而行為類似時訂立一個相同interface或abstraction 這些類別在realize或subclass時應該是以某一個特定原因去創造不同的類別當有兩個以上的原因而需要進行subclass時你就必須想想這兩個原因是否為獨立若這兩個原因完全是獨立的那麼根據SRP的原則他們必須分開而把這個class hierarchy有關的SRP留下另外一個原因則獨立出來再「橋接」在一起也因此這兩種implementation的動機可以完全獨立進行 Strategy主要是避免一個類別利用if...else...或switch...case...的方法來選擇行為而可避免在有新的需求時去修改原本類別而bridge主要訴求是將不同需要subclass的因素分散出去給不同的hierarchy 以避免單一類別被過度的subclass strategy使用時機通常顯而易見但bridge則有時候會讓人模糊當你一個class會兩種以上不同的理由是否真的就一定要用bridge？答案是不一定因為如果你只會subclass 2-3次就解決的話你大概會懶得搞pattern (不過我會去搞它... XD) 但是當一個class hierarchy(某類別及其徒子徒孫)被subclass的次數過於頻繁的時候你則該考慮bridge的可行性(也就是為了因應某些特定需求而時常需要做subclass) 或是當一個「改變」的需求出現時你發現這個class的hierarchy有幾個subclass 需要再被subclass時那就表示該class hierarchy的設計出現了問題需要重新檢討和design 所以簡單的說strategy是避免去動到原本的code Bridge則是避免過度的subclass -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.80.157.210 ※ 編輯: leondemon 來自: 111.80.157.210 (04/17 12:18)