策略模式

记得刚开始看大话设计模式的时候,傻里傻气的.认为策略模式就是这样的.他们的类图就只能是这样的.(这里就不在给出具体的类结构图了) 看大话的时候.给我的感觉是这样的.设计原则常常挂在嘴边,总有种宏观感,没有具体的细节.而且实现起来却常常的丢掉.这或许就是常常所说的缺少练习吧.

学习HeadFirst的设计模式后,又有了一种另外的一种认识.设计模式原来还可以学习的.从感觉到认识,细节逐渐添加,直到所有都堆到渠成,豁然开朗的认识.认识到原则的应用是这样应用的.可以设计一些简单的结构图.

 

最后请记住:直到抽象,继承,多态这些概念,并不会马上让你变成好的面向对象设计者.设计大师关心的是建立弹性的设计,可以维护,可以应付改变.

 

这大概就是学习的循循渐进吧.好了现在就来叙述策略模式

所有设计模式都遵循的原则

抽象

封装

针对接口编程,不针对实现

 

实例

 要模拟鸭子游戏.会出现各种鸭子,一边游泳,一遍呱呱叫.一般我们会想到用超类的方法,设计一个鸭子超类,让各种鸭子集成超类.

 

 

当我们需要会飞的鸭子时,如何设计,如果平时就在超类中添加一个fly()方法，让所有的子类都继承，这就显示了面向对象的身手了。

 

然而这样并没有显示继承的优越性。例如当我们需要增加一个不会飞的橡皮鸭或是增加一个既不会飞也不会叫的木鸭子。这样就会导致那些不具备fly（）的子类也无法免除。当然我们可以用覆盖的方法将方法覆盖，什么也不做，但是这样做会导致经常性的修改，不是很好。如何更好的修改？

 

利用接口编程

 

我们可以把fly（）方法从超类中抽取出来，放进一个Flyable接口中。这么一来，只有会飞的鸭子才实现此方法。quck（）方法于此相同，放进一个Quackable接口中。从现在开始鸭子的行为将被分开放在不同的类中，此类专门提供某行为接口的实现，这样鸭子类就不需要知道行为的实现细节。

 

分离变化和不变化的部分

 

为了把这两个行为从Duck类中分类，我们将把他们从Duck类中取出来，建立一组新类来代表行为

 

 

 

设计鸭子的行为

针对接口编程，而不是实现编程。

 

 

 

最后的整合

 

关键在于将飞行和呱呱叫的动作委托别人处理，而不是使用定义在Duck类内的飞行方法。

 

综合类图

 

小结:

以上说明的就是策略模式.

策略模式定义了算法族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化独立于使用算法的客户.

 

与以前学习的方式是不同的.这里更强调如何能更好的维护而不是进行直接的强加方式告诉你.综合设计原则,步步为营的进行更好,这就是经验的积累.