策略模式:
定义了算法族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计原则:
找出应用中可能需要变化之处,把它们独立并"封装"起来,不要和那些不变的代码混在一起,以便以后可以轻易的改动或扩充此内容,而不影响不需要变化的其他部分。这样做的好处是代码变化引起的不经意后果变少,系统变得更有弹性。
针对接口编程Animmal dog = new Dog(),而不是针对实现编程Dog dog = new Dog()。
多用组合,少用继承。这就是"有一个"比"是一个"更好的地方。
用例:
比如要想写一个关于Duck的应用,里面涉及到各种各样的Duck,它们有共同的特征(如:有脚、有翅膀。。。),同时也有不同的特征(如:叫声不同、飞行能力不同。。。),那么该如何涉及呢?
思路:
首先创建一个Duck的超类,将相同的属性(有脚、有翅膀)都封装到这个超类,这一点是可以肯定的。但是我们如何处理不同的特征呢?我想到了一下几种思路:
1. 直接在Duck中实现两个方法quack()和fly(),但是这样做就不能起到区分的作用了,所有的子类都会相同;
2. 在Duck类中创建一个抽象的方法,然后让所有的子类都去实现这个方法,这样做看似可以达到效果,但是如果duck的种类特别多呢?那样每个子类都要去分别实现这个方 法,如果其中还有很多方法是相同的,那样就会让代码显示得臃肿,不方便维护,所以还是舍弃这种;
3. 创建一个FlyBehavier接口,然后再根据动作的不同分别去实现这个接口。然后在Duck超类中引用FlyBehavier的代理对象,在Duck的fly()方法中去调用 flyBehavier.fly(),然后再提供一个 setFlyBehavier()的方法去动态的设置FlyBehavier 的实例。这样做的好处是我们只需要在Duck中去调用这个接口,而不需要去管它的具体实现,并且还实现了这些不同的部分与相同的部分的一个分离。
具体的实现UML: