
行为型设计模式
文章平均质量分 67
行为型设计模式
so~what
这个作者很懒,什么都没留下…
展开
-
设计模式之~中介者模式
Colleague叫做抽象同事类,而ConcreteColleague是具体同事类,每个具体同事只知道自己的行为,而不了解其他同事类的情况,但它们却都认识中介者对象,Mediator是抽象中介者,定义了同时对象到中介者对象的接口,ConcreteMediator是具体中介者对象,实现抽象类的方法,它需要知道所有具体同事类,并从具体同事接收消息,向具体同事发出命令。中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合,以及想定制一个分布在多个类中的行为,而又不想生成太多的子类的场合。原创 2023-06-01 19:11:32 · 967 阅读 · 0 评论 -
设计模式之~解释器模式
抽象语法树(abstract syntax code,AST)是源代码的抽象语法结构的树状表示,树上的每个节点都表示源代码中的一种结构,之所以说是抽象的,抽象表示把js代码进行了结构化的转化,转化为一种数据结构。抽象语法树并不依赖于源语言的语法,也就是说语法分析阶段所采用的上下文无文法,因为在写文法时,经常会对文法进行等价的转换(消除左递归,回溯,二义性等),这样会给文法分析引入一些多余的成分,对后续阶段造成不利影响,甚至会使合个阶段变得混乱。终结符表达式,实现与文法中的终结符相关联的解释操作。原创 2023-06-01 19:10:03 · 1743 阅读 · 0 评论 -
设计模式之~访问者模式
很多系统可以按照算法和数据结构分开,如果这样的系统有比较稳定的数据结构,又有易于变化的算法的话,使用访问者模式就是比较合适的,因为访问者模式使得算法操作的增加变得容易。反之,如果这样的系统的数据结构对象易于变化,经常要有新的数据对象增加进来,就不适合使用访问者模式。(访问者模式的优点就是增加新的操作很容易,因为增加新的操作就意味着增加一个新的访问者。访问者模式表示一个作用于某对象结构中的各元素的操作。ObjectStructure类:能枚举它的元素,可以提供一个高层的接口以允许访问者访问它的元素。原创 2023-06-01 08:54:19 · 1213 阅读 · 0 评论 -
设计模式之~迭代器模式
迭代器(Iterator)模式就是分离了集合对象的遍历行为,抽象出一个迭代器类来负责,这样既可以做到不暴露集合的内部结构,又可让外部代码透明地访问集合内部的数据。迭代器模式是针对集合对象而生的,对于集合对象而言,肯定会涉及到对集合的添加和删除操作,同时也肯定支持遍历集合元素的操作,我们此时可以把遍历操作放在集合对象中,但这样的话,集合对象既承担太多的责任了,面向对象设计原则中有一条就是单一职责原则,所有我们要尽可能地分离这些职责,用不同的类取承担不同的责任,迭代器模式就是用迭代器类来承担遍历集合的职责。原创 2023-06-01 08:52:27 · 1053 阅读 · 0 评论 -
设计模式之~策略模式
这本身并没有解除客户端需要选择判断的压力,而策略模式与简单工厂模式结合后,选择具体实现的职责也可以由Context来承担,这就最大化地减轻了客户端的职责。策略模式就是用来封装算法的,但在实践中,我们发现可以用来封装几乎任何类型的规则,只要在分享过程中听到需要在不同时间应用不同的业务规则,就可以考虑使用策略模式处理这种变化的可能性。如果在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。多个类只有算法或行为上稍有不同的场景。原创 2023-06-01 08:50:46 · 938 阅读 · 0 评论 -
设计模式之~备忘录模式
Memento模式比较适用于功能比较复杂的,但需要维护或记录属性历史的类,或者需要保存的属性只是众多属性中的一小部分时,Originator可以根据保存的Memento信息还原到前一状态。有时一些对象的内部信息必须保存在对象以外的地方,但是必须要由对象自己读取,这时使用备忘录可以把复杂的对象内部信息对其他的对象屏蔽起来。在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。如果在某个系统中使用命令模式时,需要实现命令的撤销功能,那么命令模式可以使用备忘录模式来存储可撤销操作的状态。原创 2023-06-01 08:49:38 · 1128 阅读 · 0 评论 -
设计模式之~状态模式
将特定的状态相关的行为都放入一个独立对象中,由于所有与状态相关的代码都存在于某个ConcreteState中,所以通过定义新的子类可以很容易地增加新的状态和转换。另外如果业务需求某项业务有多个状态,通常都是一些枚举常量,状态的变化都是依靠大量的多分支判断语句来实现,此时应该考虑将每一种业务状态定义为一个State的子类。这个时候“根据状态决定行为”的状态模式的引入也许是个不错的主意。对于支持状态切换的状态类违反了开闭原则,因为一旦状态修改或者中间要新增状态,则需要修改对应的源代码,否则会出现状态切换错误。原创 2023-06-01 08:46:08 · 872 阅读 · 0 评论 -
设计模式之~职责链模式
接收者和发送者都没有对方的明确信息,且链中的对象自己也并不知道链的结构。责任链模式主要是解耦了请求与处理,用户只需要将请求发送到链上即可,无需关心请求的具体内容和处理细节,请求会自动进行传递直至有节点进行处理。当客户提交一个请求时,请求是沿链传递直至有一个ConcreteHandler对象负责处理它,这样做的好处是请求者不用管哪个对象来处理,反正该请求会被处理就对了。允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况,且一个请求可以最终不被任何接收端对象所接收。原创 2023-06-01 08:44:43 · 1288 阅读 · 0 评论 -
设计模式之~模板方法模式
每一个AbstractClass都可以有任意多个ConcreteClass与之对应,而每一个ConcreteClass都可以给出这些抽象方法(也就是顶级逻辑的组成步骤)的不同实现,从而使得顶级逻辑的实现各不相同。(当不变的和可变的行为在方法的子类实现中混合在一起的时候,不变的行为就会在子类中重复出现。这个模板方法一般是一个具体方法,它给出了一个顶级逻辑的骨架,而逻辑的组成步骤在相应的抽象操作中,推迟到子类实现。通过一个父类调用其子类的操作,通过对子类的扩展增加新的行为,实现了反向控制 ,符合“开闭原则。原创 2023-05-31 08:35:40 · 1371 阅读 · 0 评论 -
设计模式之~命令模式
命令模式会通过在行为请求者和执行者之间引入一个抽象接口来将请求者和执行者进行解耦,这样如果需要修改行为时,只需要增加对应行为的命令就可以了,完全不需要修改请求者的源代码。在我们的软件开发系统中,行为请求者和真正的执行者通常都是一种紧耦合关系,但是这种情况下,当我们需要修改行为时,如需要撤销或者重做时,只能修改请求者的源代码,命令模式的结果其实就是接收方的执行结果,但是为了以命令的形式进行架构、解耦请求与实现,引入额外类型结构(引入请求方与抽象命令接口)。第二,在需要的请情况下,可以较容易地将命令记入日志;原创 2023-05-31 08:37:14 · 1870 阅读 · 0 评论 -
设计模式之~观察者模式
Observer类,抽象观察者,为所有的具体观察者定义一个接口,在得到主题的通知时更新自己。但委托也是由前提的,那就是委托对象所搭载的所有方法必须具有相同的原形和形式,也就是拥有相同的参数列表和返回值类型。尽管已经用了依赖倒转原则,但是‘抽象通知者’还是依赖‘抽象观察者’,也就是说,万一没有了抽象观察者这样的接口,通知的功能就完不成了。让耦合的双方都依赖于抽象,而不是依赖于具体。“看股票观察者”类和“看NBA观察者”类,去掉了父类“抽象观察类”,所以补上一些代码,并将“更新”方法名改为各自适合的方法名。原创 2023-05-31 08:37:46 · 1292 阅读 · 0 评论