|
|
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
| potian Joined: Aug 10, 2001 Posts: 50 From:  |
 投递日期：2001-08-22
14:27首先，两者的意图是不同的。策略用来处理算法变化，而状态则是透明地处理状态变化。 造成混淆的原因可能是两者好像都能成为继承的替代。 策略主要处理算法变化的意思是算法可能是要变的，但是这种变化却是由用户来决定到底采用何种算法。这些算法之间一般来说没有状态变迁的问题，并且你总是从几个算法中间选取一个。策略最经典的用法是和observe一起组成MVC，其中V通过Observe观察M,而V通过strategy控制C. 策略使用的另一个最频繁的地方就是消除大量的Case或if else ，但是条件是这些case中每个条件可以归纳为一个算法，最好它们只需要相同的参数。当然，在strategy中,Context可以提供接口让strategy，但是我一般不太喜欢这么用，因为这样可能造成一系列的不必要耦合和开销。 对这些case，if else使得strategy有了一个policy的别名，还有一个常用的地方叫做validator，譬如在输入框内进行检查时可以把它实现为Validator。有时候，if else的嵌套层次可能很深，这时候策略可能不能用，那么你可能需要更加复杂或者更加专注的Rule模式。 状态模式则有所不同，她实现的一个概念可以叫做动态继承，也就是继承的子类（每一个状态）可以发生变化。这些状态的变化是一个整体，组成了一个状态变化图。而一般来说，使用该模式的状态之间存在着一种线性变化的关系，也就是一个状态变为另一个，然后是第三个。客户代码并不清楚这些状态在何时发生变化，这样做的好处是在组成你整个变化过程中某些状态之间需要插入一个新的状态，或者状态的顺序之间发生变化，对客户是不可见。实现模式一方面，修改的也只是相领的状态。在处于不同的状态时，客户代码可以执行的方法也是不同的。但它的问题就是必须在Context和所有的状态实现所有状态可能的方法。 这两个之间的区别有时候可能没有，譬如在面向连结的TCPConnection例子中，不同的状态可能具有不同的方法。但是在我刚刚实现的一个无连结的P2P底层协议中，所有状态需要处理地就是一个processXML方法，这时候，你可以叫它状态或者策略都可以。但由于还是又状态变迁的问题，所以我喜欢把它叫做状态。 |
