head first 设计模式 U1

1.0版本：初始实现
duck类有quack，swin，display方法
mallardduck和redheadduck继承duck类并改写display方法

需求：增加会飞的鸭子
1.1版本：继承
解决的操作：duck增加fly方法
->问题：橡皮鸭子不会飞，但是继承了fly方法，所以会飞了
->解决的操作：橡皮鸭子覆盖fly方法重写为空方法
->
问题1：橡皮鸭子不会飞但是有fly方法，容易引起误解
问题2：加入其他类型鸭子，不同的行为都需要重写代码，比方说木头假鸭，不会飞也不会叫，需要重写quack和fly方法为空
缺点：代码重复，运行时行为不能改变，很难知道鸭子的真正行为，改一发而动全身

2.0版本：接口
解决：
1.duck类去除fly和quack方法，增加flyable接口和quackable接口
2.所有鸭子继承自duck类，且实现了flyable接口和quackable接口
缺点：
1.代码重复，无法复用。所有鸭子类型都要写自己的fly和quack方法。
2.改一发而动全身。只要修改了某种fly方法，就要修改相同实现的所有鸭子类型。

3.0版本：策略模式
设计原则：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。即，把会变化的部分取出并封装起来，以便以后可以轻易的改动或扩充此部分，而不影响不需要变化的其他部分。
解决的问题：把会变化的部分封装起来，改动时好让其他地方不会受到影响

设计原则：针对接口编程，而不是针对实现编程。即，将特定的具体行为编写在了接口中。
解决的问题：没有办法改变对象行为

针对接口编程的真正意思是针对超类型编程。抽象超类型可以是抽象类或接口
很好的例子：
针对实现编程：
dog d = new dog()
d.bark()
针对接口/超类型变成：
animal animal = new dog();
animal.makeSound() //子类dog的makeSound调用bark方法
优化：子类实现的动作不需要硬编码，可以在运行时才指定具体实现的对象
a = getAnimal()
a.makeSound()

设计原则：多用组合，少用继承
当你把两个类结合起来使用，就是组合
使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以在运行时动态的改变行为，只要组合的行为对象符合正确的接口标准即可。

实现：duck抽象类，flybehavior接口，quackbehavior接口
行为类flywithwings，flynoway实现flybehavior接口（策略模式）
行为类quack，squeak，mutequack实现quackbehavior接口（策略模式）
duck类中有两个实例变量flybehavior和quackbehavior，声明为接口类型
duck类中使用performQuack代替quack方法委托给quackbehavior实例，performFly代替fly方法委托给flybehavior实例
duck类中加入setflybehavior和setquackbehavior方法，可以在运行时调用以动态改变鸭子行为

总结：
oo基础：抽象，封装，多态，继承
oo原则：封装变化，多用组合少用继承，针对接口编程而不是实现
oo模式：策略模式：定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户