在关于鸭子的设计中,鸭子有飞行的行为,也有呱呱叫的行为。
橡皮鸭就不会飞,也不会叫,但是绿毛鸭会飞,也会呱呱叫。
设计模式中有几个原则:
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(); } //都是委托的关系 };
正如备注中所说,我们总是花许多时间来系统的维护和变化上。
我们把鸭子的行为想成是一组算法的话,这就是保证了算法的可替换。
策略模式 定义了算法族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化独立于使用算法的客户,在这个例子中,鸭子就是客户,而飞行和叫的行为就是算法,就是这个道理。