初探设计模式——策略模式

我将初次学习设计模式的一些思维活动记录如下，如有谬论请不吝斧正。

策略模式

定义算法族，分别封装起来，让他们之家可以互相替换，让算法的变化独立于使用算法的客户。

当我们有一个超类（Organism）和它的一些子类，对于相同的属性行为可以在超类中直接给出实现 不同的行为可以在超类中声明抽象方法 在子类中给出实现。
但同时存在一些问题 在后期维护需要添加新的子类但不含有这个抽象行为时该怎么处理？
新子类有超类中具体实现的方法，但实现不一样该怎么办，难道要时刻关注是否进行方法覆盖？

第一个设计原则：把变化的部分取出并“封装”起来，好让其他部分不会受到影响，让系统变得更有弹性。

既然继承并不是适当的解决方式，那么用接口来抽象出这些不同时具有的方法，子类如果有该行为再直接实现接口。

这样又带来了新的问题，一部分子类要实现相同的接口方法，代码冗余。
怎么为某个子类指定特定的行为且可以复用代码？

第二个设计原则：针对超类型（接口，抽象类）编程，从而利用超类型进行多态调用（向上转型）；而不是针对实现编程。

	如果一个行为是变化的我们就把这个行为抽象出来放到一个接口中，不同子类实现接口那么同一行为就有了不同表现，通过多态的调用复用代码。

面向实现编程：
	Dog d=new Dog(); d.bark(); Cat c=new Cat(); c.meow();

面向接口编程：
	把bark 和 meow抽象成makeSound方法放到CryWay接口中，CryDog和CryCat是接口子类，子类将方法分别实现成bark meow  
public class CryDog implements CryWay {
	public void makeSound { bark(); } 
	void bark() {….}
}

CryWay a=new CryDog();  a.makeSound();

软编码，不需要知道子类的实例化动作，在运行时指定具体实现对象：
	a=getAnimal(); a.makeSound(); 

这样不同叫声的行为就独立了起来，接下来演示下网红是怎么学猫叫的

在Organism中加入这个接口类型的实例变量，代码块中我们不用自己实现喵叫不用关心接口对象是什么，只关心该对象可以实现喵叫
public abstract class Organism{
	CryWay a ；
	public void play{ a.makeSound();}
} 

假设Organism的网红子类(InternetCelebrity)都会学猫叫, 代码块中保证接口CrWay的对象是是实现了meow的CryCat
public class InternetCelebrity extends Organism{
 	Public internetCelebrity { a=new CryCat（）;}
	a.makeSound (); 
}
测试 Organism ic=new InternetCelebrity();ic.makeSound();
继承下来Organism的构造器将a实例化成实现了meow的CryCat，这样网红就会喵喵叫了。与此同时也制造了一个具体的CryCat实例，仍在面向具体实现编程！！！

动态设定行为
不在Organism的构造器中实例化，而是在方法中，这样就可以动态指定行为
此时，网红对粉丝说让他学喵叫还是讲笑话可以弹幕告诉他

在Organism中加入setCryWay函数，接口引用参数化
public void setCryWay(CryWay cw){
	a=cw;
}

网红子类自然就继承了这个方法
Organism ic=new InternetCelebrity();
弹幕指定他还是继续学猫叫吧
ic.setcryWay(new CryCat());
这样网红就开始开始表演了
ic.makeSound();
//把学猫叫讲笑话。。这一组行为称为一个算法族

网红对象从Organism继承来所以是一个生命体，他有一个算法族（一组CryWay的行为）
“是一个”是继承来的，“有一个”是CryWay的行为对象组合来的

第三个设计原则：多用组合，少用继承 组合使系统具有弹性，算法族可以封装成类，还可以动态改变行为

总结;继承提高代码复用性，组合提高可维护性和扩展性