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)