第八讲设计模式

第八讲设计模式内容摘要：

10%的折扣，后期可能会对超出 200元的销售给予 10%的折扣，并且还会存在其他大量变化。 我们如何对这些各种各样的定价算法进行设计。 策略（ GoF）  名称：策略（ Strategy）  问题：如何设计变化但相关的算法或政策。 如何设计才能是这些算法或政策具有可变更的能力。  解决方案（建议）：在单独的类中分别定义每种算法 /政策 /策略，并且使其具有共同接口。 策略（ GoF） 定价策略类 策略（ GoF） 协作中的策略 策略（ GoF） 语境对象需要其策略的属性可视性 使用工厂创建策略 创建策略 工厂 总结  对于动态变化的定价策略的防止变异可以通过策略和工厂模式实现。 建立在多态和接口基础上的策略可以实现具有可插拔的对象设计 组合（ Composite） GoF  问题：我们如何来处理多个互相冲突的定价策略。 例如商店在今天（星期一）有效的政策有：  对老年人有 20%的折扣政策  对于购物金额满 400元的优先客户给予折 15%的折扣  在星期一，购物金额满 500美元享受 50元的折扣  买一罐咖啡，则所有购物物品都享受 15%的折扣 假设一个老年人同时也是优先客户，他买了一罐咖啡和600元的物品。 此时应该适用哪个定价政策。 组合（ GoF ）  名称：组合（ Composite）  问题：如何能够像处理非组合（原子）对象一样，（多态地）处理一组对象或具有组合结构的对象呢。  解决方案（建议）：定义组合和原子对象的类，使它们实现相同的接口 组合（ GoF ） 示例 组合模式 组合（ GoF ） 示例 与组合的协作 创建多个 SalePricingStrategies  使用组合模式，我们使一组多个（有冲突）的定价策略对于 Sale对象来说与单个定价策略一样。 包含该组的组合对象也实现了 ISalePricingStrategy接口。 对于该设计问题更具有挑战性（并且更有趣）的部分是：我们什么时候创建这些策略。 创建多个 SalePricingStrategies  良好的设计应该在开始时为商店创建一个包含当前所有折扣政策（如果没有有效折扣，可以设为 0%）的组合，例如某个PercentageDiscountPricingStrategy。 然后，如果在该场景的下一步中，发现还需要应用另一个定价策略（例如老年人折扣），此时通过使用继承来的 ，能够轻松地在组合中增加这一策略。  在该场景中，可能有三个地方需要在组合中增加策略：  商店当前定义的折扣，在创建销售时增加  顾客类型折扣，在 POS获知顾客类型时增加  产品类型折扣（如果购买一罐咖啡，则所有购物物品都享受 15%的折扣），在向销售输入该产品条目时增加 创建多个 SalePricingStrategies 创建组合策略 第二种顾客类型折扣 为客户折扣创建定价策略（第一部分） 为客户折扣创建定价策略（第二部分） 外观（ Fa231。 ade） GoF 问题：  假设创建新销售时，可能要识别该销售是否以礼券方式进行支付（这是可能并且普遍的做法）。 然后，商店可能会规定如果使用礼券只可以购买一件商品。 此时， enterItem在完成第一次操作后应该变为无效。  如果销售使用礼券支付，在对该顾客找零时，除了礼券之外所有其他支付类型的找零都应该置为无效。 例如，如果收银员请求现金找零或更新顾客在其商店帐户上的积分时，这些请求都应该被判断为无效。  假设创建新销售时，可以识别其为慈善捐助（从商店到慈善机构）。 商店可能会规定每次输入的条目价值只能低于 250元，并且只有当前登录者为经理时才允许对该销售添加条目。 外观（ GoF）  名称：外观（ Fa231。 ade）  问题：对一组完全不同的实现或接口（例如子系统中的实现和接口）需要公共统一的接口。 可能会与子系统内部的大量事物产生耦合，或者子系统的实现可能会改变。 怎么办。  解决方案（建议）：对子系统定义唯一的接触点 — 使用外观对象封装子系统。 该外观对象提供了唯一和统一的接口，并负责与子系统构件进行协作 外观（ GoF） 具有外观的 UML包图 外观 总结  外观模式很简单并且应用广泛。 它将子系统隐藏在一个对象之后。  外观通常通过单例。