在关于鸭子的设计中，鸭子有飞行的行为，也有呱呱叫的行为。
橡皮鸭就不会飞，也不会叫，但是绿毛鸭会飞，也会呱呱叫。
设计模式中有几个原则：
1、原则一：找出应用中变化的行为，把它们独立出来，不和那些不需要变化的的代码混合在一起。
变化的就是叫和飞这两个行为，在设计的时候就可以抽离出来。从而设计一个行为的类以及一个制造声音的类。
2、原则二：针对接口编程而不是针对实现编程。
//针对实现编程 Dog d = new Dog(); d.bak(); //针对接口编程 Animal animal = new Dog(); animal.makesound();
子类实例化的动作不在需要在代码中硬性编码，而是在运行的时候才指定具体实现的类。
3、原则三 ：多用组合，少用继承。"有一个"比"是一个"更好。原则就是多用组合，少用继承，继承会太死板。
根据抽离出来的鸭子的变化项目，可以抽离出两个行为，FlyBehavior 和 QuackBehavior， 是这两个类。
操作的时候可以这样做，在Duck中添加两个实例的变量，然后
class Duck { public: FlyBehavior flyBehavior; QuackBehavior quckBehavior; public: void performQuack() { quckBehavior.quack(); } //鸭子对象不亲自处理呱呱叫的行为，而是委托给quckbehavior 引用的对象。 };
3、可以动态的设定行为，让对象有不同的行为。
class Duck { public: FlyBehavior flyBehavior; QuackBehavior quckBehavior; public setFlyBehavior(FlyBehavior fb) { flyBehavior = fb; } public setQuackBehavior(QuackBehavior qb) { quckBehavior = qb; } public: void performQuack() { quckBehavior.quack(); } //鸭子对象不亲自处理呱呱叫的行为，而是委托给quckbehavior 引用的对象。 void performfly() { flyBehavior.fly(); } //都是委托的关系 };
正如备注中所说，我们总是花许多时间来系统的维护和变化上。
我们把鸭子的行为想成是一组算法的话，这就是保证了算法的可替换。
策略模式 定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户，在这个例子中，鸭子就是客户，而飞行和叫的行为就是算法，就是这个道理。
