最近开坑策略模式，我之后就按照head first 设计模式的顺序 介绍我学习到的设计模式
首先是策略模式
策略模式的核心是把易于改变的部分抽取出来，做一个策略类，原来类通过接口来保持与策略类的关联，策略类用组合的方式添加到原来类中。
这样做的好处是 1封装了变化（策略类内部的改变 不影响原来类的实现） 2 减少耦合（基类通过接口调用策略类 两者耦合度降低）
3可以再运行时修改策略类的实现
举一个不太合适的例子来说明
如果我们此时需要声明一个人的接口
<pre name="code" class="java">public abstract class people{
//打招呼
public abstract void great();
}
我们可以知道根据语种，不同人打招呼的方式可能不一样，按照上面的抽象类 我们可能需要按照打招呼的方式来实现各种现实类，但是如果假如我们还有肤色这方法的时候，我们会发现，如果有3个打招呼的方式和4中肤色，那么我们就要实现12个实现类，中间的代码重复量很大，而且如果某种打招呼的方式修改了，如果原来说HELLO 的人改说 how are you了 这样代码的修改就成了很大的问题，我们也不可以通过部分类来完整了解 great 方式的实现种类。
总的来说 弊端有3种 1 代码重复大 2修改困难 3无法得知方法实现的全部模式
按照策略模式 我们可以这样来实现
public abstract class people{
//打招呼
private Great great；
public void great(){
great.sayHello();
}
}
public interface Great{
public void sayHello();
}
我们把打招呼这个方法提取出来 封装成一个接口，然后之后我们通过实现Great接口来实现各种打招呼的方式，我们在生成实现类的时候 我们只要将对应的打招呼类赋值给他就行了，这样做似乎无法减少一开始我们提出的那个问题，但是已经把重复的代码量减少到最小，同时人的类与打招呼的类的耦合度降低，我们对打招呼的修改对基类是透明的，在运行的时候 我们可以修改打招呼类的实现方式