行为类模式分析

行为类模式包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法、访问者模式,我去,好多。。。下面主要挑选几个比较容易混淆且比较重要的模式进行对比说明。

一、命令模式VS策略模式

1、关注点不同

策略模式关注的是算法替换的问题:一个新的算法投产,旧算法退休,或者提供多种算法由调用者自己选择使用,算法的自由更替是它实现的要点。换句话说,策略模式关注的是算法的完整性、封装性,只有具备了这两个条件才能保证其可以自由切换。

命令模式则关注的是解耦问题,如何让请求者和执行者解耦是它需要首先解决的,解耦的要求就是把请求的内容封装为一个一个的命令,由接收者执行。由于封装成了命令,就同时可以对命令进行多种处理,例如摊销、记录等。

2、角色功能不同

策略模式中的具体算法是负责一个完整算法逻辑,它是不可再拆分的原子业务单元,一旦变更就是对算法整体的变更。

命令模式傲游命令的实现,也就是功能的实现。例如我们在分支中也提到接收者的变更问题,它只影响到命令族的变更,对请求者没有任何影响,从这方面来说,接收者对命令负责,而与请求者无关,命令模式中的接收者只要符合六大设计原则,完全不用关心它是否完成了一个具体逻辑,它的影响范围也仅仅是抽象命令和具体命令,对它的修改不会扩散到模式外的模块。当然,如果在命令模式中需要指定接收者,则需要考虑接收者的变化和封装。

3、使用场景不同

策略模式适用于算法要求变换的场景,而命令模式适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景。

二、策略模式VS状态模式

1、环境角色的职责不同

两者都有一个叫Context环境角色的类,但是两者的区别很大,策略模式的环境角色只是一个委托作用,负责算法的替换;而状态模式的环境角色不权权是委托行为,它还具体登记状态变化的功能,与具体的状态类协作,共同完成状态切换行为随之切换的任务。

2、解决问题的重点不同

策略模式旨在解决内部算法如何改变的问题,也就是将内部算法的改变对外界的影响降低到最小程序,它保证的是算法可以自由地切换;而状态模式旨在解决内在状态的改变而引起行为改变的问题,它的出发点是事物的状态,封装状态而暴露行为,一个对象的状态改变,从外界来看就好像是行为改变。

3、解决问题的方法不同

策略模式只是确保算法可以自由切换,但是什么时候用什么算法它决定不了;而状态模式对外暴露的是行为,状态的变化一般是由环境角色和具体状态共同变化的,也就是说状态模式封装了状态的变化而暴露了不同的行为或行为结果。

4、应用场景不同

策略模式只是一个算法的封装,可以是一个有意义的对象,也可以是一个无意义的逻辑片段,比如MD5加密算法。其算法必须是平行的,可以相互替换,否则策略模式就封装了一堆垃圾。状态模式则要深圳市一系列状态发生变化的场景,它要求的是有状态且有行为的场景,也就是一个对象必须具有二维(状态和行为)描述才能采用状态模式,如果只有状态而没有行为,则状态的变化就失去了意义。

5、复杂度不同

从设计模式的角度分析,通常策略模式比较简单,这里的简单指的是结构简单,扩展比较容易,而且代码也容易阅读。而状态模式则通常比较复杂,因为它要从两个角色看到一个对象状态和行为的改变,也就是说它封装的是变化,要知道变化是无穷尽的,因此相对来说状态模式通常都比较复杂,涉及面很多,虽然也很容易扩展,但是一般不会进行大规模的扩张和修正。

三、观察者模式VS责任链模式

这两个好像没什么相似的?观察者模式中一个具体的角色既可以是观察者,也可以是被观察者,这样就形成了观察者链。这与责任链模式非常类似,它们都实现了事务的链条化处理。

1、链中的消息对象不同

从首节点开始到最终的尾节点,两个链中传递的消息对象是不同的。责任链模式基本上不改变消息对象的结构,虽然每个节点都可以参与消费,但是它的结构不会改变。但是在观察者模式中是允许的,链中传递的对象可以自由变化,只要上下级节点对传递对象了解即可,它不要求链中的消息对象不可变化
,它只要求链中相邻两个节点的消息对象固定。

2、上下节点的关系不同

在责任链模式中,上下节点没有关系,都是接收同样的对象,所有传递的对象都是链首传递过来,上一节点是什么没有关系,只要按照自己的逻辑处理就成,而观察者模式就不同了,它的上下级关系很亲密,下级对上级顶礼膜拜,上级对下级绝对信任,链中的任意两个相邻节点都是一个牢固的独立团体。

3、消息的分销渠道不同

在责任链模式中,一个消息从链首传递进来后,就开始沿着链条向链尾运动,方向是单一的、固定的;而观察者模式则不同,有非常大的灵活性,一个消息传递到链首后,具体怎么传递是不固定的,可以以广播方式传递,也可以以跳跃方式传递,这取决于处理消息的逻辑。

时间: 2024-10-10 17:11:36

行为类模式分析的相关文章

深入浅出设计模式——享元模式(Flyweight Pattern)

模式动机 面向对象技术可以很好地解决一些灵活性或可扩展性问题,但在很多情况下需要在系统中增加类和对象的个数.当对象数量太多时,将导致运行代价过高,带来性能下降等问题.享元模式正是为解决这一类问题而诞生的.享元模式通过共享技术实现相同或相似对象的重用. 在享元模式中可以共享的相同内容称为内部状态(Intrinsic State),而那些需要外部环境来设置的不能共享的内容称为外部状态(Extrinsic State),由于区分了内部状态和外部状态,因此可以通过设置不同的外部状态使得相同的对象可以具有

深入浅出设计模式——职责链模式(Chain of Responsibility Pattern)

模式动机 职责链可以是一条直线.一个环或者一个树形结构,最常见的职责链是直线型,即沿着一条单向的链来传递请求.链上的每一个对象都是请求处理者,职责链模式可以将请求的处理者组织成一条链,并使请求沿着链传递,由链上的处理者对请求进行相应的处理,客户端无须关心请求的处理细节以及请求的传递,只需将请求发送到链上即可,将请求的发送者和请求的处理者解耦.这就是职责链模式的模式动机. 模式定义职责链模式(Chain of Responsibility Pattern):避免请求发送者与接收者耦合在一起,让多个

深入浅出设计模式——策略模式(Strategy Pattern)

模式动机 完成一项任务,往往可以有多种不同的方式,每一种方式称为一个策略,我们可以根据环境或者条件的不同选择不同的策略来完成该项任务.在软件开发中也常常遇到类似的情况,实现某一个功能有多个途径,此时可以使用一种设计模式来使得系统可以灵活地选择解决途径,也能够方便地增加新的解决途径. 在软件系统中,有许多算法可以实现某一功能,如查找.排序等,一种常用的方法是硬编码(Hard Coding)在一个类中,如需要提供多种查找算法,可以将这些算法写到一个类中,在该类中提供多个方法,每一个方法对应一个具体的

深入浅出设计模式——状态模式(State Pattern)

模式动机 在很多情况下,一个对象的行为取决于一个或多个动态变化的属性,这样的属性叫做状态,这样的对象叫做有状态的 (stateful)对象,这样的对象状态是从事先定义好的一系列值中取出的.当一个这样的对象与外部事件产生互动时,其内部状态就会改变,从而使得系统的行为也随之发生变化.在UML中可以使用状态图来描述对象状态的变化. 模式定义状态模式(State Pattern) :允许一个对象在其内部状态改变时改变它的行为,对象看起来似乎修改了它的类.其别名为状态对象(Objects for Stat

深入浅出设计模式——解释器模式(Interpreter Pattern)

模式动机 如果在系统中某一特定类型的问题发生的频率很高,此时可以考虑将这些问题的实例表述为一个语言中的句子,因此可以构建一个解释器,该解释器通过解释这些句子来解决这些问题.解释器模式描述了如何构成一个简单的语言解释器,主要应用在使用面向对象语言开发的编译器中. 模式定义解释器模式(Interpreter Pattern) :定义语言的文法,并且建立一个解释器来解释该语言中的句子,这里的“语言”意思是使用规定格式和语法的代码,它是一种类行为型模式.Interpreter Pattern: Give

深入浅出设计模式——迭代器模式(Iterator Pattern)

模式动机 一个聚合对象,如一个列表(List)或者一个集合(Set),应该提供一种方法来让别人可以访问它的元素,而又不需要暴露它的内部结构.针对不同的需要,可能还要以不同的方式遍历整个聚合对象,但是我们并不希望在聚合对象的抽象层接口中充斥着各种不同遍历的操作.怎样遍历一个聚合对象,又不需要了解聚合对象的内部结构,还能够提供多种不同的遍历方式,这就是迭代器模式所要解决的问题.在迭代器模式中,提供一个外部的迭代器来对聚合对象进行访问和遍历,迭代器定义了一个访问该聚合元素的接口,并且可以跟踪当前遍历的

深入浅出设计模式——中介者模式(Mediator Pattern)

模式动机 在用户与用户直接聊天的设计方案中,用户对象之间存在很强的关联性,将导致系统出现如下问题:? 系统结构复杂:对象之间存在大量的相互关联和调用,若有一个对象发生变化,则需要跟踪和该对象关联的其他所有对象,并进行适当处理.? 对象可重用性差:由于一个对象和其他对象具有很强的关联,若没有其他对象的支持,一个对象很难被另一个系统或模块重用,这些对象表现出来更像一个不可分割的整体,职责较为混乱.? 系统扩展性低:增加一个新的对象需要在原有相关对象上增加引用,增加新的引用关系也需要调整原有对象,系统

设计模式学习之命令模式

模式动机 在软件设计中,我们经常需要向某些对象发送请求,但是并不知道请求的接收者是谁,也不知道被请求的操作是哪个,我们只需在程序运行时指定具体的请求接收者即可,此时,可以使用命令模式来进行设计,使得请求发送者与请求接收者消除彼此之间的耦合,让对象之间的调用关系更加灵活. 命令模式可以对发送者和接收者完全解耦,发送者与接收者之间没有直接引用关系,发送请求的对象只需要知道如何发送请求,而不必知道如何完成请求.这就是命令模式的模式动机. 模式定义 命令模式(Command Pattern):将一个请求

解释器模式 深度解析(2)

上一章已经初步介绍了解释器模式 这一章将 通过模式的 适用环境 ,解决方案,解决问题 ,模式应用来进一步介绍解释其模式 模式定义: 解释器模式(Interpreter Pattern) :定义语言的文法,并且建立一个解释器来解释该语言中的句子,这里的"语言"意思是使用规定格式和语法的代码,它是一种类行为型模式. 适用环境: 在以下情况下可以使用解释器模式: 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树. 一些重复出现的问题可以用一种简单的语言来进行表达. 文法较为简单. 效