小猪盖房子(策略者模式)
很久之前，有只小猪要盖自己的房子，因为猪的本性就是懒得动弹，就最先用茅草盖了一座房子。一个大风萧瑟的夜，小猪的房子被风吹倒了。没地方住的小猪，只能重新盖房子，这次小猪相对聪明且勤奋了些许，用木板来盖了一座房子可以挡住大风。但是没想到的是又是一个萧瑟的夜，发生了小型地震，房子又倒了。备受煎熬的小猪只能勤勤恳恳的去用砖头盖一个牢牢的房子。这下终于可以抵挡一切风雨地震了。由于小猪时间都浪费在了重新捣鼓房子，从此小猪成为了一只有房大龄单身猪。
这里我们就可以看到，有着三个策略我们可以知道，分别是用茅草、木板和砖头来盖房子。
这些策略都有着一个共同点就是盖房子。我们可以把这些策略抽出一个策略接口，然后分别去实现：
//盖房子策略接口
public interface Startegy {
void building();
}
下面是小猪开始的第一次选择最容易改成的策略，茅草房子：
public class StartegyGrass implements Startegy {
@Override
public void building() {
System.out.println("用茅草盖房子=====茅草房子完成");
}
}
其次是小猪为了能挡住大风，采取第二种策略用木板盖房子：
public class StartegyWood implements Startegy {
@Override
public void building() {
System.out.println("用木板盖房子=====木板房子完成");
}
}
最后，小猪痛定思痛选择里最复杂但是最安全的策略，用砖头盖房子：
public class StartegyWall implements Startegy {
@Override
public void building() {
System.out.println("用砖头盖房子=====砖头房子完成");
}
}
当然这些策略都是在小猪的脑袋里装着的，因此我们当然要定义一个猪脑袋（容器类）：
public class Context {
//盖房子的策略
private Startegy startegy = null;
//构造函数传递策略
public Context(Startegy startegy) {
this.startegy = startegy;
//小猪比较懒就直接在构造函数里面执行盖房子
//开发不建议这么做哈
//最好还是提出来一个单独的方法去这么搞
this.startegy.building();
}
}
好，我们最后看一下这个事情的经过吧
//场景类
public class Client {
public static void main(String[] args) {
//现在小猪要盖房子了，最容易实现的是什么房子呢
System.out.println("小猪要盖房子了，用什么盖呢？？？");
Context context = new Context(new StartegyGrass());
System.out.println("现在开始刮风了，房子被吹倒了！");
System.out.println("小猪需要重新盖房子");
context = new Context(new StartegyWood());
System.out.println("现在开始地震了，房子又倒了！");
System.out.println("小猪又需要重新盖房子");
context = new Context(new StartegyWall());
System.out.println("现在刮风下雨房子都没有倒！");
System.out.println("最终小猪成了一名有房大龄单身猪");
}
}
我们看一下执行结果：
小猪要盖房子了，用什么盖呢？？？
用茅草盖房子=====茅草房子完成
现在开始刮风了，房子被吹倒了！
小猪需要重新盖房子
用木板盖房子=====木板房子完成
现在开始地震了，房子又倒了！
小猪又需要重新盖房子
用砖头盖房子=====砖头房子完成
现在刮风下雨房子都没有倒！
最终小猪成了一名有房大龄单身猪
接下来，我们看看策略模式是到底怎么定义的：
策略模式：定义一组算法，将每个算法都封装起来，并且使他们之间可以互换。
我们的三个盖房子策略就是三个算法，"将每个算法都封装起来"而我们的封装类Content恰恰就是。他们实现的是同一个接口肯定是可以互换的。
策略模式的重点其实就是在封装类上，这块是借用了代理模式的思路，可以想一下，它和代理模式的区别是什么？区别就是策略模式的封装类和封装的策略类用的不是同一个接口，如果是同一个接口就成了代理模式。
在场景中，调用的话，可以看出来比较简单。想用哪个策略，就去new 出它对象。然后放到封装类中完成任务。
策略模式其实就是采用了面向对象的继承和多态机制。但是我们在日常的业务中真的就这么简单？一个类实现多个接口很正常，这样就需要我们很清楚的区分哪些接口是哪个策略的接口，哪些和这个并没有关系。
当然这里就要引出这个策略模式的缺点了：
-
策略类数量增多
每一个策略就是一个类，而且复用的概率很小，你自己说最后多不多就完事了。
-
所有的策略类都需要向外暴露
也就是调用的人必须清楚知道每个策略接口策略类的内容，然后才能决定使用哪个。这个做法是与米特法则是相违背的，我只是想盖房子，我凭什么就要了解这个房子是要用什么盖的？那我还要你这个封装类干什么吃？这样一来，就暴露出了一个问题，但是我们可以其他模式来一起使用解决这个棘手的问题，比如工厂方法模式，代理模式等我们以后会在公众号中讲出哈。
好了，我们吐槽了那么久，也说说这个好处吧，不能逮着坏处一直说呀：
-
每个算法可以自由切换
这个本身就是策略模式定义中就有的，每个算法的自由切换，提高了整个系统的灵活性。比如现在大方向上来说有A和B两个策略，A用来实现平日的系统的所用策略，B是应急灾难的策略，我们现在平日出问题了，立刻切换至B可最大程度的减少受灾损失。
-
扩展性良好
这个当然非常的良好，比如现在A策略我们认为老了，想用一个C策略来维持平日系统的所用策略来替换A，我们就可以不用再对A进行修改，完全可以在不动用A的情况下（我们也知道以前的代码，谁敢动啊，出个问题都找不到北了），我们可以新建一个C策略去实现这个接口，然后在场景中去替换掉A。就实现了对原有代码的零改动，还可以实现需求啦，既方便又快捷。何乐而不为呢～
这里是三个java猪，今天的小猪盖房子的故事就先到这里了，我们后期再见👏👏👏
