学习-输出-再学习，形成一个闭环，才是最有效果的学习方式。如果只有学习，没有输出，那学到的只是就像一团浆糊塞到你的脑子里，无法融会贯通，形成自己的有效知识体系。因此希望在这里对自己学习的知识通过博文的方式进行输出，也希望自己不要半途而废。输出时，尽量不看书籍的内容，或者只看书籍中的章节名；凭印象和思考，复盘学习到的内容。复盘完，再回去对照书中内容，看看有哪些缺漏。
==================================================================
第一个例子，介绍了如何使用策略模式。
本例中，涉及到两个重要的设计原则：
1. 封装原则：在软件设计时要区分容易发生变化的部分以及不会经常发生变化的部分；对于容易发生变化的部分，应将其封装起来，使对其的改动不会影响到其他部分。
2. 针对接口进行设计而不是针对实现进行设计。
例子：
有一个游戏开发公司，设计了一款模拟鸭子的游戏。首先设计了一个类,类中实现了一些鸭子的基本行为，比如嘎嘎叫，游泳等等:
class Duck {
public void quack()
{...}
public void swim()
{...}
}
该公司设计的所有鸭子类，都继承自Duck类，那么这些子类都会继承quack和swim行为的代码。
突然有一天，市场有新需求，需要对鸭子增加fly的行为，面对这个需求，最直观最简单的做法，就是在Duck类中，新增实现fly()行为，如下：
class Duck {
public void quack()
{...}
public void swim()
{...}
public void fly()
{...}
}
但是这么做以后，不好的后果出现了，所有鸭子的子类都直接继承了fly行为。那些本来不可能飞的鸭子，也被迫实现了飞行的功能，比如玩具鸭，出现了如此大的bug，程序员紧急修复，因此在玩具鸭类中，覆盖Duck中的fly接口：
public class RubberDuck extends Duck {
public void fly()
{
//do nothing;
}
...
}
这样做确实是临时解决了玩具鸭会飞的尴尬情况。但却不是长久之计，假如以后需要新增一种鸭子种类,这种鸭子不仅不会飞，也不是嘎嘎叫，而是吱吱叫，那么这个鸭子类就得同时覆盖quack和fly行为；如果又要新增一种鸭子，会飞，但不会游泳，。。。 这样每新增一种鸭子，都要检查是否要覆盖某些方法， 简直是无穷无尽的噩梦。
于是优化方案1.0：
将Duck类中的quack, fly 等会变化的行为从类删除，提取出来，做成接口的形式：
public interface quackable
{
public void quack();
}
public interface flyable
{
void fly();
}
当要定义一个鸭子类时，先继承Duck类，然后选择性地实现行为接口，比如class RubberDuck就可以改为：
public class RubberDuck extends Duck implements quack
{
public void quack{...}
//不实现flyable接口，因此就不会飞
}
这个方案的优点是，再也不用一一检查哪些类需要重写，哪些不用，并且每种鸭子可以定义自己的行为。
但是新的问题又出现了，有一天，领导要求对鸭子的fly行为增加一段代码。因为现在所有的鸭子类的fly行为都是在各自类中实现的，所以我们要把所有鸭子的fly代码都改写一遍。。。如果游戏中有几百种鸭子类型，简直无法想象。这里就牵涉到第一条设计原则：封装的原则。如果那些拥有相同代码的函数，从一开始就被设计成可复用的，就不会有现在的困恼了。
因此优化方案2.0：
仍然设计行为接口,flyBehavior, quackBehavior等等，但现在不再由鸭子类来实现具体的行为方法，而是定义一些行为类，这些行为类实现具体不同的fly和quack方法：
public interface quackBehavior
{
public void quack();
}
public interface FlyBehavior
{
void fly();
}
class NormalFly implements flyBehavior
{
public void fly()
{
//最通用的飞行方式
}
}
class FlyNoWay implements flyBehavior
{
public void fly()
{
//do nothing; 针对无法飞行的鸭子类
}
}
在Duck类中，持有这些行为接口的引用，并利用多态（所谓多态，就是对同一个消息，可以有不同的响应。编写代码时，不需要关心是调用了哪个子类的方法，只需关心调用了哪个接口。这里就牵涉到第二个设计原则，针对接口编程而不是针对实现编程）：
public class Duck
{
FlyBehavior flyBehavior;
public void performFly
{
//利用多态，对不同的flyBehavior的引用，会调用到不同的fly实现方法
flyBehavior.fly();
}
}
这样定义一个鸭子类：
public class RubberDuck extends Duck
{
//构造函数：
public RubberDuck()
{
flyBehavior = new FlyNoway(); //别忘了，flyBehavior是从父类Duck中继承的
}
}
这样，RubberDuck就不会飞行， 而其他鸭子类只要给flyBehavior new一个NormalFly的行为对下，就很方便的设定了fly行为。而且所有的NormalFly行为代码都是可复用的。
