设计模式入门-策略模式.pptVIP

设计模式系列讲座 ——入门 广联达软件股份有限公司 计价产品部 张祖兴 2010年3月31日 从简单的模拟鸭子游戏开始 模拟鸭子游戏 面向对象技术（OO） 鸭子超类（Duck） Quack() Swim() Display() 继承的子类 MallardDuck Display(){// 外观是绿头} RedheadDuck Display(){//外观是红头} 现在我们得让鸭子能飞 为提高竞争力，需要会飞的鸭子！！！ 怎么办？ 基类Duck中增加Fly()方法，所有子类都会继承Fly()方法 可怕的问题发生了…… 橡皮鸭会飞了…… 如何解决？ 想到继承 橡皮鸭覆盖Fly()方法，什么都不做 但是 木头鸭，既不会飞，也不会叫，这样必须覆盖Fly()和Quack()两个方法，什么都不做 每当有新的鸭子子类出现，都 要被近检查并可能需要覆盖Fly()和Quack()…… 利用接口？ 将Fly()和Quack()抽取出来，设计成接口 Flyable Fly() Quackable Quack() 只有会飞或会叫的鸭子才实现此接口 此设计如何？ 通过继承覆盖几个方法算是差劲？ 通过接口，那么所有子类都 要修改一下飞行的行为，又怎么说？ 这样的设计造成代码无法复用！！！ 从一个恶梦跳进另一个恶梦了…… 软件开发的一个不变真理 CHANGE 设计原则1 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起 建立两组类，一个与Fly相关，一个与Quack相关 鸭子类 飞行行为 叫行为 鸭子行为 取出易变部分 设计原则2 针对接口编程，而不是针对实现编程 以前做法（2种） 行为来自Duck超类的具体实现 或继承某个接口并由子类自行实现 新设计 子类将使用接口（FlyBehavior与QuackBehavior）所表示的行为 好处 实际的“实现”不会被绑死在子类中 特定的具体行为编写在实现了FlyBehavior与QuackBehavior的类中 实现鸭子的行为 飞行接口 interface FlyBehavior Fly() 对应实现类 FlyWithWings Fly(){// 实现鸭子的飞行} FlyNoWay Fly(){// 什么都不做，不会飞} 飞行的动作可被其他对象复用，飞行行为与鸭子类无关了 可以新增一些行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类 整合鸭子的行为 Duck FlyBehavior flyBehavior PerformFly() { flyBehavior.Fly(); } 子类MallardDuck MallardDuck(){ flyBehavior = new FlyWithWings;} 测试Duck的代码 Duck d = new MallardDuck(); D.PerformFly(); 动态设定行为 Setter Method Public void SetFlyBehavior(FlyBehavior fb) { flyBehavior = fb;} Duck d = new MallardDuck(); D.PerformFly(); D. SetFlyBehavior(new FlyRocketPowered()); D.PerformFly(); “有一个”可能比“是一个”更好 设计原则3 多用组合，少用继承 恭喜你，学会第一个设计模式了！ 策略模式（Strategy Pattern） 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。 设计原则回顾 设计原则1 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起 设计原则2 针对接口编程，而不是针对实现编程 设计原则3 多用组合，少用继承 出个多选题 利用继承来提供Duck行为，会导致哪些缺点？ （多选） 代码在多个子类中重复 运行时的行为不容易改变 不能让鸭子跳舞 很难知道所有鸭子的全部行为 鸭子不能同时又飞又叫 改变会牵一发动全身，造成其他鸭子不想要的改变 谢谢大家！