快速入门设计模式

设计原则

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
• 针对接口编程，而不是针对实现编程。
• 多用组合，少用继承。
• 为了交互对象之间的松耦合设计而努力。
• 类应该对扩展开放，对修改关闭。
• 要依赖抽象，不要依赖具体类。
• 最小知识原则：只和你的密友谈话。
• 别调用我们，我们会调用你。
• 一个类应该只有一个引起变化的原因

策略模式

我们知道，并非“所有”的子类都具有飞行和呱呱叫的行为，所以继承并不是适合的解决方式。虽然Flyable与Quackable可以解决“一部分”问题，但是却造成代码无法复用。

设计原则

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

我们知道Duck类内的fly()和quack()会随着鸭子的不同而改变。为了要把这两个行为从从Duck类分开，我们将把它们从Duck类中取出来，建立一组新类代表每个行为。从现在开始，鸭子的行为将被放在分开的类中，此类专门提供某行为接口的实现。这样，鸭子类就不再需要知道行为的实现细节。

设计原则

针对接口编程，而不是针对实现编程。

所以这次鸭子类不会负责实现Flying与Quick接口，反而是由我们制造一组其他类专门实现。FlyBehavior与QuackBehavior，这就称为“行为”类。由行为类而不是Duck类来实现行为接口。在我们的新设计中，鸭子的子类将使用接口(FlyBehavior与QuackBehavior)所表示的行为，所以实际的“实现”不会被绑死在鸭子的子类中。

这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。而我们可以新增一些行为，不会影响到既有的行为类，也不会影响"使用"到飞行行为的鸭子类。

下面是整个重新设计后的类结构：鸭子继承Duck，飞行行为实现FlyBehavior接口，呱呱叫行为实现QuackBehavior接口。

“有一个”可能比“是一个”更好。每一个鸭子都有一个FlyBehavior和一个QuackBehavior，好将飞行和呱呱叫委托给它们代为处理。当你将两个类结合起来使用，这就是组合。这种做法和继承不同之处在于，鸭子的行为不是继承来的，而是和适当的行为对象“组合”来的。

设计原则

多用组合，少用继承。

策略模式定义了算法簇，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

观察者模式

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

观察者提供了一种对象设计，让主题和观察者之间松耦合。关于观察者的一切，主题只知道观察者实现了某个接口。主题不需要知道观察者的具体类是谁，做了些什么或其他细节。

任何时候我们都可以增加新的观察者。因为主题唯一依赖的东西是一个实现Observer接口的对象列表，所以我们可以随时增加观察者。改变主题或者观察者其中一方，并不会影响另一方。因为两者是松耦合的，所以只要他们之间的接口仍被遵循，我们就可以自由地改变他们