设计模式入门一：策略模式

一．设计模式入门

1.设计原则

   No.1找出应用中需要变化之处，把他们独立出来，不要和那些需要变化的代码混在一起

   解释：把变化的部分取出来，并“封装”起来，好让其他部分不受到影响。

   好处：代码变化引起的不经意后果变少，系统变得更有弹性

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

   针对接口编程，真正的意思是针对超类型supertype编程，关键就在于多态，执行时会根据实际状况选择执行到的真正的行为，不会被绑死在超类型的行为上。针对超类型编程这句话，可以更明确地说成“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象都可以指定给这个变量。这也意味着，声明时不用理会以后执行时的真正对象类型”

   解释：我们利用接口代表每个行为，而行为的每个实现都将实现其中的一个接口，实际的实现工作没有绑死在某个子类上。

     以前的做法：父类实现，然后子类继承或者是子类继承某个接口，并由子类自行实现，

  我们都被实现绑的死死的，没办法更改行为（除非写更多代码）

   No3:多用组合，少用继承

    解释：使用组合建立系统具有很大的弹性，不仅可将算法足分装成类，更可以“在运行时动态的改变行为”，只要组合的行为对象符合正确的接口标准即可。

   

 

2.鸭子问题分析：

父类Duck，子类是各种不同的鸭子，现在需要每种鸭子有不同的功能，木鸭不会飞，其他鸭子会飞，以及每种鸭子的叫声都不一样 如何实现这样的功能？

1.采用继承的方法，然后在子类中重写方法子类的方法，

问题：并不是所有子类都有这样的行为，如果在以后的过程中忘记覆盖这些行为，可能导致不会不会叫的鸭子，反而具有这些功能，因为从父类那继承来。

继承的缺点：

  1.代码在多个子类中重复，有的子类并不需要这样的代码

  2.很难知道这个子类所有拥有的所有方法

  3，运行时的行为不容易改变

  3. 改变会牵一发而动全身，造成其他对象不想要的改变。

 

2.把飞和叫的行为抽出来单独做一个接口，然后子类实现这样的接口

 问题：代码不能复用，而且如果后期需要修改一下飞的行为，那么就需要进入每一个类中修改这些行为，明显效率很低，且容易出错。

3.飞行的行为FlyBehavior单独抽象成一个接口，然后定义具体的类实现这些接口（FlyWithWings，FlyNoway）然后在Duck（父类）中申明一个接口类型FlyBehavior flyBehavior，以及一个调用该行为的方法flyBehavior.fly() ，其中利用了多态来具体调用哪个对象的方法，在子类中的构造函数中 父flyBehavior=new FlyWithWings（），（父类已经申明了flyBehavior，子类直接使用）

 效果：可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了，

而我们可以新增一些行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类，这样一来，有了继承的“复用”好处，却没有了继承所带来的包袱。

 问题：在子类的构造器中制造了具体的实现类的实例。 在子类中添加一个set方法，方法的参数就是FyBehavior的具体实现类，可以动态改变flyBehavior的行为。

 

归纳总结：

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

解释：算法族，就是上述鸭子的一系列行为，也就是能做的事，封装起来就是独立的放在一个类中，这些类都实现了公共接口，所以因为多态的原因可以互相代替！