设计模式之策略模式

Posted 2020-08-04

　　设计模式重点在于代码风格的实现，使项目易于开发维护以及更新，同时，在底层代码中存在着各种设计模式，使之易于拓展。总而言之，学会设计模式非常重要，在学习了《Head first 设计模式》之后，根据个人见解将里面的知识与个人知识经验结合提炼出来，方便以后自己回头查阅复习，也同大家一起学习，如有不足，欢迎留言提出。

　　设计模式的第一个重点便是使项目易于修改维护，减少重复代码，不同的模式就有不同的设计方法，但也有一定共同的特点，我们可以在之后的介绍其他的设计模式中发现。

　　第一个设计原则：多用组合，少用继承

　　学习继承的时候有一个很好的例子

 

　　这样继承的作用可以根据类名很容易理解到继承的作用，同时子类Apple和Banana继承了父类的方法。但是如果此时项目多了一个要求，要求要编写一个塑料苹果plasticApple，

　  

　　此时如果再继承fruits类的话便会出现错误，因为plasticApple并不能食用。

　　好像这个时候最简单的做法是重写编写一个父类或者什么的，根据需求再重写编写，小项目尚且过得去，但是如果这是一个大项目，而且新的要求是出现在项目成行后，要进行更新项目的时候，这总做法很明显不明智。因此我们要少用继承。

　　即便如此，plasticApple和Apple还是存在着相同的地方，isRed(),仔细一想，我们自然而然就会想到，要是能够做到把相同的作用放在一起，减少重复代码，子类（或者具体类）自己开发编写不同功能，那就好了。

　　第二个设计原则：找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起

　　所以，我们应该把变化之处，即canEat()从Fruit中提取出来，但是这个时候我们应该怎么处理这个变化之处呢？这就涉及第三个设计原则了。

　　第三个设计原则：针对接口编程，而不是针对实现编程

　　这个设计原则自然而然就是针对这个变化了，也就是我们只希望修改我们想要改变的类，而不影响到其他地方。

　　针对接口编程，以下摘抄《Head first 设计模式》上的讲解，针对接口编程，真正的意思是针对超类型编程。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。“针对超类型编程”，更确切的说是“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口”。如此，只要是具体实现此超类型的类所产生的对象，都可以知道给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型。（脑补一下多态的知识便容易理解了）

 　　针对实现类的做法会是如此，这个假设plasticApple 实现了different类

plasticApple p=new plasticApple();
p.canEatOrNot();

　　但是针对接口编程的方法如下

different d=new plasticApple();//声明类型是超类
d.canEatOrNot();

　　子类实例化的动作不再需要在代码中硬编码，而是在“运行时才指定具体实现的对象”。

　　接下来我们整合一下代码，看看完整的流程是如何。

　　

public class Fruit
{
  Different different;
  //其他代码
  public void can(){
  different.canEatOrNot();//Fruit对象不进行判断能否食用，而是交给                            
                                        // different引用的对象  
}  
}                    

　　

public DifferentFruit extends Fruit
{
plasticApple(){
different=new plasticApple();//继承，子类可是使用父类的实例变量
}

}

public class plasticApple implements Different
{
  pubic void canEatOrNot(){
  System.out.println("I can be eat");
}  
}

　　总结一下，便是将会变化的行为脱离出来，采用接口规范变化之后，子类实现不同的方法，其中要采用面向接口编程。

　　上面的做法可以有进一步的修改空间，便是将类Fruit设计成抽象类，使之更符合面向接口编程，有兴趣的读者可以自己尝试。

　　遇到任何改变都无需担心，这就是策略模式，定义如下,策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变法独立于使用算法的客户 。