1、第一组：王言 肖晓琳 何一帆,Strategy 设计模式,设计模式,官方：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,当人们遇到问题是，总是能在这二十三中解决方案中找到一个或者多个设计模式的组合事的问题得到满意的解决,什么是设计模式？,设计模式,六要素：,参与者与协作者：模式包括的实体,解决方案： 效果： 描述了模式应用的效果及使用模式应权衡的问题,实现：怎样实现模式,模式名称,意图 ：目的 问题： 描述了应该在何时使用模式。,设计模式,设计原则：,开闭原则: 扩展性是开放的,更改性是封闭的.,Liskov替换原则:子类可以替换父
2、类出现在父类能出现的任何地方.,依赖倒置原则:依赖关系应该是尽量依赖接口(或抽象类),而不是具体的类.,接口分离原则:采用多个与特定客户类有关的接口比采用一个通用的接口要好.,定义简单的方法:一个类中的方法不应该太复杂,如果一个方法太大,很可能是这个方法包含的功能太多.,设计模式,设计原则：,泛化的深度要适中:类之间的泛化关系增加了类之间耦合性,一般不要设计超过3层的泛化关系.,尽量使用组合或聚合,而非泛化:组合或聚合的耦合性比泛化关系弱得多.,这些原则性问题呢， 请大家在例子当中作深刻理解！,四人团中的设计模式的使用原则：,针对接口编程，而不是针对实现编程 优先使用对象组合，而不是类继承 考
3、虑你的设计中哪些是可变的,Just like D&D!,在开始我们的游戏之旅之前，我们需要定义玩家可以选择的角色。我们首先想到了四个角色职业：野蛮人(Barbarian)、佣兵(Soldier)、圣骑士(Paladin)、法师(Wizard)。,DisplayInfo()：显示角色的基本信息。(比如圣骑士：追求至善的热情、维护法律的意志、击退邪恶的力量 - 这就是圣骑士的三件武器 . ) Walk()：让角色行走。 Stay()：让角色站立。,可是有一天，万恶的策划告诉程序员说，现在让角色配备武器，于是你改变你的设计：,可是没过几天，你的项目经理又觉得这样子每个角色的个性不鲜明，于是他要求，野
4、蛮人用斧。 法师不用武器。,这样一来，就是系统必须面临选择，如果是法师，就不给他可以使用武器的功能，野蛮人就要给他使用斧头（而不是剑）的功能。 如果这个时候，你选择用if.else 或者case，我只能说你弱爆了！ 用条件语句解决上述问题，我们成为硬编码(hard code)，如果我们需要增加一种角色，就需要修改封装好的源代码，或者客户端的代码。这样也就违背了开闭性原则。,另外一种方法是：给基类添加实体方法，使得不应该拥有此方法的子类也拥有了此方法，也使得所有子类方法拥有了完全一样的实现。,这种方法似乎很好的解决了这个问题，既然野蛮人和法师不同，那我们只需要让野蛮人和法师覆盖基类的 UseWe
5、apon() 方法就可以了，与此同时，我们将基类方法声明为 virtual 虚拟方法，并给出实现。这个实现，可以视为角色的默认实现(默认角色用剑)。,可是没过两天，万恶的分析师又告诉你，需要新添角色： 战士(Warrior)，他也使用斧。 需要新添角色 牧师(Cleric)，他也不使用武器。,于是就有了新的问题： 我们没有实现代码重用，对于 野蛮人 和战士，他们对UseWeapon()的实现是相同的(都用斧)，但我们不得不将完全一样的代码在每个子类中都写一遍。 如果这个方法的实现需要经常改动，我们需要反复修改所有相关子类中的方法。 牧师 和 法师都不使用武器，但是他们都继承了UseWeapon
6、()方法，即便是用一个什么都不做的(空的)UseWeapon()方法覆盖基类方法，他们仍会暴露出 UseWeapon() 的能力(可以从他们的实例中访问此方法)。,因此，用继承来解决问题是非常不科学滴！,这一次，我们使用接口来实现。 我们定义一个 IWeaponable 接口，然后从基类中去除UseWeapon()方法，然后对于可以使用武器的子类，实现这个接口；对于不可以使用武器的子类(牧师、法师)，不去实现这个接口。,牧师、法师 不再具有使用武器的能力，它们的实例也不会暴露出UseWeapon()方法。 同时实现了依赖倒置原则。,可是这样一来，又产生了一些问题: 因为接口只是一个契约，而不包
7、含实现，于是将有大量的子类需要实现此接口。 代码没有重用，所有用剑、用斧的角色，其UseWeapon()的实现方式都相同。如果将来需要修改，所有的相关子类都需要改动。,雪上加霜的是，你的项目经理跟你说，现在是所有的角色，要么用剑，要么用斧，要么什么都不用。如果我想让同一个角色先用斧，再用剑，也就是动态地给他分配武器。然后你就有悲催了！,OO有一个原则称作“Encapsulate what varies”，也就是俗称的“封装变化”。,在当前情况下，UseWeapon()这个行为是不断变化的，那么我们就应该想办法将它封装起来。这一次，我们依然要使用接口，但是实现此接口的类不再是我们定义的角色的基类
8、或者子类，而是专用于UseWeapon()这个行为的类。,我们将对接口的实现分放到了它自己的继承体系中，而不是放到我们的角色类中。,我们通过Character的UseWeapon()方法实际去调用 IWeaponable 接口的UseWeapon()方法(实际上调用了其实体类的UseWeapon()方法)。 这就实现了开闭性原则。 这样的方法叫做对象组合。,Strategy,策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类
9、中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。,Strategy 设计模式,Strategy 结构,环境类(Context):用一个ConcreteStrategy对象来配置。维护一个对Strategy对象的引用。可定义一个接口来让Strategy访问它的数据,抽象策略类(Strategy):定义所有支持的算法的公共接口。 Context使用这个接口来调用某ConcreteStrategy定义的算法。,具体策略类(ConcreteStrategy):以Strategy接口实现某具体算法。,Strategy 特征,意图：让你可以使用不同的业务规则或算法取决于它们出现的
10、场景,问题：解决需要根据发出请求的客户或被处理的数据对算法做出选择的问题,解决方案：将算法的选择和算法的实现相分离。让客户可以基于场景做出选择,参与者与协作者： Strategy规定如何使用不同的算法 ConcreteStrategy实现这些不同的算法 Context通过类型为Strategy的引用使用特定的ComcreteStrategy。,Strategy 特征,效果： Strategy模式定义了一些列的算法 switch语句或条件语句得到了避免 必须用相同的方式调用所有的算法，接口是相同的,实现：让使用算法的类（Context）包含一个抽象类（Strategy）抽象类中有一个抽象方法制定
11、如何调用算法。每个派生类根据需要实现算法。,Strategy,当存在以下情况时使用Strategy模式：,许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间 /时间权衡的算法。当这些变体实现为一个算法的类层次时 ,可以使用策略模式。 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代
12、替这些条件语句,Strategy,优点：,相关算法系列 Strategy类层次为Context定义了一系列的可供重用的算法或行为,提供了可以替换继承关系的办法,消除了一些if else条件语句,实现的选择 Strategy模式可以提供相同行为的不同实现。,Strategy,缺点：,客户端必须知道所有的策略类，并自行决定使用哪一个策略类,Strategy和Context之间的通信开销,策略模式将造成产生很多策略类,总结与分析,策略模式是一个比较容易理解和使用的设计模式，策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。策略模式通常把一个系列的算法封装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。 2）在策略模式中，应当由客户端自己决定在什么情况下使用什么具体策略角色。 3）策略模式仅仅封装算法，提供新算法插入到已有系统中，以及老算法从系统中“退休”的方便，策略模式并不决定在何时使用何种算法，算法的选择由客户端来决定。这在一定程度上提高了系统的灵活性，但是客户端需要理解所有具体策略类之间的区别，以便选择合适的算法，这也是策略模式的缺点之一，在一定程度上增加了客户端的使用难度。,Thanks for your attention！,
