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