(1.6)--第5.1章-策略模式软件设计与体系结构.ppt

第5.1章 策略模式1鸭子模拟游戏SimUDuck第5.1章 策略模式2变化让鸭子起飞第5.1章 策略模式3问题：所有的鸭子都可以飞？为了实现复用而使用集成，带来了不必要的麻烦第5.1章 策略模式4解决方案1把橡皮鸭中的fly()方法重载每当有新的鸭子子类出现，我们就要检查并可能需要覆盖fly()和quark()方法第5.1章 策略模式5解决方案2把fly()从超类中抽取出来，放在一个Flyable接口中，使得只有会飞的鸭子才实现此接口代码无法复用继承关系复杂第5.1章 策略模式6问题第5.1章 策略模式7我们的目标当变化发生时，可以用一种对既有代码影响最小的方式来修改软件。设计原则找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起如何把会变化的部分抽取并封装起来，以后可以轻易地改动此部分，而不影响不需要变化的其他部分第5.1章 策略模式8分开变化和不变的部分Duck类内的fly()和quack()会随着鸭子的不同而改变第5.1章 策略模式9设计鸭子的行为Duck类不会负责实现Flying与Quacking接口，而是由一组其它类专门实现FlyBehavior与QuackBehavior，这称之为行为类。由行为类而不是Duck类实现行为接口。以往做法：行为来自Duck超类的具体实现，或是继承某个接口并由子类自行实现。Duck的子类将使用接口所表示的行为，所以实际的实现不会被绑定在Duck的子类中。第5.1章 策略模式10实现鸭子的行为飞行和鸣叫的动作已经和鸭子类无关了，可以被其他任何对象复用第5.1章 策略模式11SimUDuck的代码FlyBehavior接口第5.1章 策略模式12SimUDuck的代码QuackBehavior接口第5.1章 策略模式13整合鸭子的行为Duck会将飞行和鸣叫动作委托别人处理，而不是使用定义在Duck类内的飞行和鸣叫方法在Duck类中加入两个实例变量第5.1章 策略模式14整合鸭子的行为实现performQuack()第5.1章 策略模式15设计鸭子的行为设计子类当当MallardDuckMallardDuck实例化时，它的构造器会把继承来的实例化时，它的构造器会把继承来的quackBehaviorquackBehavior实例变量初始化成实例变量初始化成QuackQuack类型的新实例类型的新实例第5.1章 策略模式16SimUDuck的代码Duck类第5.1章 策略模式17SimUDuck第5.1章 策略模式18测试SimUDuck第5.1章 策略模式19扩展：动态设定行为在Duck类中，加入两个新方法：第5.1章 策略模式20扩展：动态设定行为新建一个ModelDuck类第5.1章 策略模式21扩展：动态设定行为新建一个新的FlyBehavior类型第5.1章 策略模式22扩展：动态设定行为测试SimUDuck第5.1章 策略模式23设计原则针对接口编程，而不是针对实现编程接口：Interface、超类型、概念变量的声明类型是超类型，只要是具体实现该超类型的类所产生的对象，都可以被指定给这个变量。声明类时不用理会以后执行时的真正对象类型，进而真正的行为只有在执行时根据实际状况确定。针对实现编程针对接口编程Dog d=new Dog();d.makeSound();Animal a=new Dog();a.makeSound();a=getAnimal();a.makeSound()第5.1章 策略模式24问题我们是不是一定要先把系统做出来，再看看有哪些地方需要变化，然后才回头去把这些地方分离/封装？不一定。通常在设计系统时要预先考虑到有哪些地方未来可能需要不一定。通常在设计系统时要预先考虑到有哪些地方未来可能需要变化，于是提前在代码中加入这些弹性。变化，于是提前在代码中加入这些弹性。Duck是不是也该设计成一个接口？这么做并不恰当，让这么做并不恰当，让DuckDuck成为一个具体类，可以让衍生的特定类具成为一个具体类，可以让衍生的特定类具有有DuckDuck共同的属性和方法。原先共同的属性和方法。原先DuckDuck类中的变化的部分已经被删除，类中的变化的部分已经被删除，因而不需要把因而不需要把DuckDuck设计成接口。设计成接口。用一个类代表一个行为，感觉似乎有点奇怪。类不是应该具有某种“东西”吗？类不是应该同时具备状态与行为吗？即使是行为，也仍然可以有状态和方法。比如飞行的行为可以有一即使是行为，也仍然可以有状态和方法。比如飞行的行为可以有一些属性（翅膀拍动频率、飞行高度、速度、些属性（翅膀拍动频率、飞行高度、速度、）第5.1章 策略模式25第一种设计模式：策略模式（Strategy Pattern）策略模式定义了算法族，并分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。第5.1章 策略模式26Alice:“我要一份涂了奶酪及果酱的白面包，加了香草冰激凌的巧克力汽水，夹了培根的火烤起司三明治，鱿鱼色拉吐司，有冰激凌和香蕉片的香蕉船，一杯夹了奶精和两块糖的咖啡哦还有一个烧烤汉堡”Flo:“给我一份C.J.福特，一个黑与白，一份杰克班尼，一份Radio，一份主厨船，一个普通咖啡，还有给我烧一个！”Flo与厨师之间有共享的词汇第5.1章 策略模式27Rick:“我建立了这个广播类，它能够追踪所有的倾听对象，而且任何时候只要有新资料进来，就会通知每个倾听类。最棒的是，倾听者可以随时加入此广播系统，甚至可以随时退出。这样的设计方式相当动态和松耦合。”Tim:“我使用观察者模式设计我们的系统。”设计模式设计模式让你和其他开发人员之间有共享的词汇，进而使可发人员之间的沟通变得容易设计模式可以让你的思考架构的层次提高到模式层面，而不是仅停留在琐碎的对象上第5.1章 策略模式28设计模式 vs 库/框架库/框架实现特定的功能（Java API：网络、GUI、IO）无法帮助将应用组织成容易了解、容易维护、具有弹性的架构第5.1章 策略模式29问题如果设计模式这么棒，为何没有人建立相关的库呢？设计模式比库的等级更高，设计模式告诉我们如何组织类和对象以设计模式比库的等级更高，设计模式告诉我们如何组织类和对象以解决特定问题，而采纳何种设计使之适用于特定的应用是开发人员解决特定问题，而采纳何种设计使之适用于特定的应用是开发人员的任务。的任务。库和框架是设计模式吗？库和框架提供了特定功能的具体实现，它们本身会用到设计模式，库和框架提供了特定功能的具体实现，它们本身会用到设计模式，只有了解设计模式才能更容易的了解只有了解设计模式才能更容易的了解APIAPI是如何围绕设计模式来构造是如何围绕设计模式来构造的。的。模式只不过在利用OO设计原则而已，懂得运用封装、继承、多态等OO原则，是否还有必要考虑设计模式？懂得懂得OOOO基础概念并不意味着就能设计出弹性的、可复用的、可维护基础概念并不意味着就能设计出弹性的、可复用的、可维护的系统，而构造的系统，而构造OOOO系统的隐含经验是必不可少的。系统的隐含经验是必不可少的。第5.1章 策略模式30总结知道OO基础，并不足以让你设计出良好的OO系统。良好的OO设计必须具备可复用、可扩充、可维护三个特点。模式可以让我们建造出具有良好OO设计质量的系统。模式被认为是历经验证的OO设计经验。模式不是代码，而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中。模式不是被发明，而是被发现。大多数的模式和原则，都着眼于软件变化的主题。大多数的模式都允许系统局部改变独立于其他部分。我们常把系统中会变化的部分抽出来封装。模式让开发人员之间有共享的语言，能够最大化沟通的价值。