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)