设计模式-行为篇

设计模式-行为篇_第1张图片

状态模式

有限状态机

1:状态转换较多,但每个状态的转换业务不复杂的,推荐使用查表法。
通过二维数组等方式确定下一个转换的状态,并处理对应业务
2:状态转换业务较复杂的,推荐使用状态模式,使用单独的类来定义状态和状态业务
3:业务非常简单,状态也很少,直接使用if else就可以实现,不需要过度设计

迭代器模式

通过模拟游标的滑动来遍历集合中的数据
迭代器需要实现 hasNext,currentItem,next三个方法,用于滑动游标和判断是否迭代结束
遍历过程中不支持元素的添加和删除操作,因为会引起未决结果

访问者模式

一个或多个操作应用到一组对象上,设计的意图是解耦操作和对象本身,保持类的职责单一、满足开闭原则已应对代码的复杂性。
推荐使用策略模式替代访问者模式。1:访问者模式使用重载实现,容易让访问者代码爆炸。2:不巧妙,不灵活,将一组操作封装在一起,增加功能时需要修改的代码太多。
支持Double Dispatch的语言不需要访问者模式,直接动态执行就可以了

备忘录模式

1:备份以便于恢复数据
2:不能破坏封装原则
3:低频率全量备份结合高频率增量备份(redis RDF和AOF)

命令模式

1:将行为封装成对象进行传递
2:和策略模式的区别在于,每个命令执行的是不同的业务;策略模式指同一个业务的不同实现。
例如:控制电灯的开,关属于命令;是交流电还是直流电给电灯供电属于策略。

解释器模式

典型的场景是编译器的语法解释。
解释器是针对特定的语句进行解释,调用特定的业务代码进行执行的过程。

中介模式

1:接口对象之间的交互关系,将多对多关系通过中介类转换为一对多。
2:中介模式和观察者模式的区别在于,观察者关系是单向固定的,中介则可以是双向的。
3:中介模式接收消息后进行业务编排调度。
4:副作用:可能会产生一个大而全的上帝类,包含类所有的业务代码。(是否可以用命令模式进行拆分?)

你可能感兴趣的:(设计模式)