strategy设计模式.pptVIP

第一组：王言 肖晓琳 何一帆 Strategy 设计模式 设计模式 官方：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结 当人们遇到问题是，总是能在这二十三中解决方案中找到一个或者多个设计模式的组合事的问题得到满意的解决 什么是设计模式？ 设计模式 六要素： 参与者与协作者：模式包括的实体 解决方案： 效果： 描述了模式应用的效果及使用模式应权衡的问题 实现：怎样实现模式 模式名称 意图 ：目的 问题： 描述了应该在何时使用模式。 设计模式 设计原则： 开闭原则: 扩展性是开放的,更改性是封闭的. Liskov替换原则:子类可以替换父类出现在父类能出现的任何地方. 依赖倒置原则:依赖关系应该是尽量依赖接口(或抽象类),而不是具体的类. 接口分离原则:采用多个与特定客户类有关的接口比采用一个通用的接口要好. 定义简单的方法:一个类中的方法不应该太复杂,如果一个方法太大,很可能是这个方法包含的功能太多. 设计模式 设计原则： 泛化的深度要适中:类之间的泛化关系增加了类之间耦合性,一般不要设计超过3层的泛化关系. 尽量使用组合或聚合,而非泛化:组合或聚合的耦合性比泛化关系弱得多. 这些原则性问题呢， 请大家在例子当中作深刻理解！！ 四人团中的设计模式的使用原则： 针对接口编程，而不是针对实现编程 优先使用对象组合，而不是类继承 考虑你的设计中哪些是可变的 Just like DD! 在开始我们的游戏之旅之前，我们需要定义玩家可以选择的角色。我们首先想到了四个角色职业：野蛮人(Barbarian)、佣兵(Soldier)、圣骑士(Paladin)、法师(Wizard)。 DisplayInfo()：显示角色的基本信息。(比如圣骑士：追求至善的热情、维护法律的意志、击退邪恶的力量 -- 这就是圣骑士的三件武器 ... ) Walk()：让角色行走。 Stay()：让角色站立。 可是有一天，万恶的策划告诉程序员说，现在让角色配备武器，于是你改变你的设计： 可是没过几天，你的项目经理又觉得这样子每个角色的个性不鲜明，于是他要求，野蛮人用斧。 法师不用武器。 这样一来，就是系统必须面临选择，如果是法师，就不给他可以使用武器的功能，野蛮人就要给他使用斧头（而不是剑）的功能。 如果这个时候，你选择用if...else 或者case，我只能说你弱爆了！ 用条件语句解决上述问题，我们成为硬编码(hard code)，如果我们需要增加一种角色，就需要修改封装好的源代码，或者客户端的代码。这样也就违背了开闭性原则。 另外一种方法是：给基类添加实体方法，使得不应该拥有此方法的子类也拥有了此方法，也使得所有子类方法拥有了完全一样的实现。 这种方法似乎很好的解决了这个问题，既然野蛮人和法师不同，那我们只需要让野蛮人和法师覆盖基类的 UseWeapon() 方法就可以了，与此同时，我们将基类方法声明为 virtual 虚拟方法，并给出实现。这个实现，可以视为角色的默认实现(默认角色用剑)。 可是没过两天，万恶的分析师又告诉你，需要新添角色： 战士(Warrior)，他也使用斧。 需要新添角色 牧师(Cleric)，他也不使用武器。 于是就有了新的问题： 我们没有实现代码重用，对于 野蛮人 和战士，他们对UseWeapon()的实现是相同的(都用斧)，但我们不得不将完全一样的代码在每个子类中都写一遍。 如果这个方法的实现需要经常改动，我们需要反复修改所有相关子类中的方法。 牧师 和 法师都不使用武器，但是他们都继承了UseWeapon()方法，即便是用一个什么都不做的(空的)UseWeapon()方法覆盖基类方法，他们仍会暴露出 UseWeapon() 的能力(可以从他们的实例中访问此方法)。 因此，用继承来解决问题是非常不科学滴！ 这一次，我们使用接口来实现。 我们定义一个 IWeaponable 接口，然后从基类中去除UseWeapon()方法，然后对于可以使用武器的子类，实现这个接口；对于不可以使用武器的子类(牧师、法师)，不去实现这个接口。 牧师、法师 不再具有使用武器的能力，它们的实例也不会暴露出UseWeapon()方法。 同时实现了依赖倒置原则。 可是这样一来，又产生了一些问题: 因为接口只是一个契约，而不包含实现，于是将有大量的子类需要实现此接口。 代码没有重用，所有用剑、用斧的角色，其UseWeapon()的实现方式都相同。如果将来需要修改，所有的相关子类都需要改动。 雪上加霜的是，你的项目经理跟你说，现在是所有的角色，要么用剑，要么用斧，要么什么都不用。如果我想让同一个角色先用斧，再用剑，也就是动态地给他分配武器。然后你就有悲催了！ OO有一个原则称作“Encapsul