《研磨设计模式》读书笔记之:策略模式、状态模式

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_37882382/article/details/97758390

前言:本篇系看完《研磨设计模式》一书的个人理解和总结,可能存在不正确的地方,看时需要持怀疑态度。另外,所有的图都是示意图,示意,示。

策略模式(Strategy):

几点解释:

  1. 多个if、elif 相连的代码我们实际开发中肯定经常遇到,如果 if、elif的方法体都很大,那就可以考虑使用策略模式,抽象出统一的接口,并将方法体的逻辑剥离出来封装为接口的不同实现类。这样做扩展性得到了提高。
  2. 各个策略类之间是平等的,可以相互替换。选择策略可以是客户端来主动选择,也可以是上下文对象自动的进行选择(容错恢复)。
  3. 从结构上看,策略模式只有一层或者说是一级,如果需要多级的类似于折上折的功能,可以考虑装饰模式。
  4. 如果去掉了Context类,则策略模式就变成了最常见的面向接口编程的 接口-实现类的结构。但是,上下文对象在策略模式中扮演了重要的角色,我们从Strategy接口的 someOperation(Context context)方法可以看出,上下文对象提供给策略实现类一个统一的获取所需数据的方式,甚至是回调上下文的某些方法;另外,客户端直接持有和使用上下文对象,意味着策略对象可以独立于客户端而变化,并且可以在上下文中动态的切换策略。
  5. 本质是 分离算法,并封装为具体的类,自由的选择算法的实现。

状态模式(State):

几点解释:

  1. 这图是上面策略模式的图改的,状态模式的结构和策略模式一模一样。但是二者明显的区别在于:状态模式中,一个状态对应一个行为,行为完全不同并且不可替代,是平行的,而 策略模式中,不同的策略类之间平等的,即 彼此可以灵活替换。
  2. 状态模式的重心在于:首先,分离总结出业务中的 几种状态,然后再将各个状态对应的行为剥离出来,封装为同一个抽象的不同实现。
  3. 通常,业务中的状态应当是固定的几种,而 不同的状态也对应了特定的行为。因此,通常在上下文对象中实现好根据状态选择具体行为的逻辑,客户端不必参与。这点也不同于策略模式,策略模式由于策略类的平等性,客户端和上下文对象都可以灵活的选择对应的策略。
  4. 策略模式和状态模式有一个共同的问题,会产生很多的细粒度对象,而且 策略类和状态类一般是无状态的,所以在频繁使用的情况下,很适合使用 享元模式来达到延迟创建并缓存共享的功能。
展开阅读全文

没有更多推荐了,返回首页