设计模式之行为模式模型

行为型模式

观察者模式(Observer)

         观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使他们能够自动更新自己。

1.将一个系统分割成一系列相互协作的类有一个很不好的副作用,那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,这样会给维护、扩展和重用都带来不便;

2.当一个对象的改变需要同时改变其他对象,而且它不知道具体有多少对象有待改变时,应该考虑使用观察者模式;

3.一个抽象有两个方面,其中一方面依赖于另一方面,这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用;

总之,观察者模式所做的工作其实就是解除耦合。让耦合的双方都依赖于抽象,而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

使用:当一个对象的改变需要同时改变其他对象,且不知道其他对象的个数的时候,使用观察者模式。

点评:这就是典型的间谍呀,利用间谍来给组织传输情报,组织在根据情报的不同做出相应的调整。

模板方法模式(TemplateMethod)

         定义一个操作中的算法的骨架,而将一些不走延迟到子类中。模板方法使得子类可以不改变一个算法的结构既可以重定义该算法的某些特定步骤,把不变行为搬到超类,去除子类中重复代码体现它的优势。

代码重复在编程中是常见的现象,如果我们在一个以上的地方看到重复的代码,那么我们就该想办法把他们合二为一,程序就会变的更好。微妙的重复会出现在不同但本质相同的结构或步骤中。

点评:想想我们考试的试题吧,总不能把全国好几百万的考生的试卷重复几百万遍吧,继承的重要性。

命令模式(Command)

         将请求封装为一个对象,从而使你可用不同的请求对客户进行参数化,队请求排队或记录请求日志,以及支持可撤销的操作。

将调用操作的对象鱼知道如何实现该操作的对象解耦,这就意味着我们可以在这两者之间做很多的事情,比如在不同的时刻指定,排列和执行请求,支持撤销和重做的操作等。

点评:分工合作,效率才是最好的,做好单一职责。

命令模式VS中介者模式VS观察者模式:三者都是运用中间者来进行类与类之间的沟通,中介者模式是解决许多类之间的相互交互,而命令模式是将调用操作的对象与指导如何实现该操作的对象解耦,主题对象在状态发生变化时,会通知所有观察者对象,使他们能够自动更新自己。中介者仅仅是为了交互的简洁和维护的方便,而命令模式的有点确实可以记录整个操作的日志,以便在日后的系统出问题时查找出原因,支持事务。观察者模式是一种一对多的解耦方式,切多到自己不需要知道。

职责链模式(Chain of ResPonsiblity)

         使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系,将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理为止。

就像我们送快递,我们不能把快递直接给顺丰快递的小哥,而是通过一个点,然后他在给总公司,总公司在根据条件往下分发,一级一级的处理,最后才能到顺丰快递的小哥那里。但是我们却不需要知道到底经过了那些流程,我们只是需要快递,仅此而已。

点评:做好单一职责原则,但是小心邮件地址写错无人收件。

状态模式(State)

当一个对象的内在状态改变时容许改变其行为,这个对象看起来像是改变了其类。将特定的状态相关的行为都放在一个对象中,由于所有与状态相关的代码都存放在一个具体的状态类中,所以通过定义新的子类可以很容易地增加新的状态和转换。

由于状态的改变行为也会随着状态的变化而变化,所以我们要把状态分开,这样维护才会更用以。

点评:开放-封闭原则真实无处不在。

职责链模式VS状态模式:两者的出现都是在程序需要做出判断的情况下才出现的模式,职责链的需要一个顺序的抉择,而状态模式不需要具体的顺序,但是我们知道程序是不断的变化的,正所谓变才是不变的,所以我们需要把这些分支单独封装的子类中,这样才能让我们动态的去添加或者去修改这些我们需要选择的条件。从而不再需要If或者swith。

解释器模式(interpreter)

         给定一个语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。可以很容易的扩展和改变文法,

如果一种特定类型的问题发生的频率足够高,那么就可以考虑将该问题的各个实例表述为一个简单语言中的句子,也就是说,通过构建一个解释器,该解释其解释这些句子来解决该问题。这样就不用为没疑问字符串模式都构造一个特定的算法。

点评:专业的东西,咱们就用专业的工具来解决,简单,快捷。

中介者模式(Mediator)

         用一个中介对象来封装一些列的交互对象的交互,中介者使各个对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变他们之间的交互。一般应用于一组对对象,定义良好,但是复杂的方式进行通信的场所。

由于在面向对象中,我们倡导的是单一职责原则,所以在一个项目中可能会存在非常多的类,这样两个类之间的交互就会形成蜘蛛网型的错乱,对于维护是非常不利的。这时我们就可以建立一个中介者,利用中介者来进行类与类之间的交互,为类之间的交互起到搭桥牵线的作用。

点评:我们的操作系统,是不是就是一个中介者模式呢。

访问者模式(Visitor)

         表示一个作用于某对象结构中的各个元素的操作,它使你可以再不改变各元素的类的前提下作用于这些元素的新操作。

元素稳定,但是关于元素的状态的变化确实可以变化的,对于元素稳定,但是对于依赖于复杂对象结构的构建的操作就变的非常的容易,仅需要增加一个新的访问者即可在一个对象的结构上增加一个新的操作。

点评:结构足够稳定,运转变化很多,才能容易使用。

策略模式(Strategy)

用来封装几乎任何类型的规则,只要在分析过程中发现有在不同时间需要不同的业务规则,都可以用策略模式,例如商场的打折、积分都可以。

继承提供了一种支持多种算法或行为的方法,我们可以直接生成一个类A的子类B,C,D,从而给他们不同的行为,但是这样会将行为硬编进A中,对于A的维护是非常不利的,但是我们仔细分析就会发现其实他们只是算法或者行为不同,将算法封装在独立的策略类(Strategy)中,使得你可以独立于A类去改变其他的类,使他已于切换,易于理解,易于扩展,这显然是组合要优于继承。

点评:先组合,在继承。

备忘录模式 Memeton

备忘录模式在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样以后就可以将该对象恢复到原先保存的状态了。

可以避免暴露一些只应由对象A管理却又必须存在对象A之外的信息,备忘录模式把可能很复杂的对象A的内部信息对其他对象屏蔽起来,从而保持了封装边界。

评价:还记得我们当年的游戏吗?

设计模式之行为模式模型

时间: 2024-11-05 18:17:44

设计模式之行为模式模型的相关文章

设计模式3 创建型模型

设计模式3 创建型模型 目录: 简单工厂模式 工厂方法模式 抽象工厂模式 单例模式 简单工厂 模型 [email protected]:~$ cat main.cpp  //设计模式:简单工厂 模型 #include<iostream> using namespace std; class Fruit { public: Fruit(string kind) { this->kind = kind; if(kind == "apple") {} else if (ki

【大话设计模式】——代理模式

对于面向对象的程序设计语言而言,继承和多态是两个最基本的概念.Hibernate 的继承映射可以理解持久化类之间的继承关系.例如:人和学生之间的关系.学生继承了人,可以认为学生是一个特殊的人,如果对人进行查询,学生的实例也将被得到. Hibernate支持三种继承映射策略: 使用 subclass 进行映射:将域模型中的每一个实体对象映射到一个独立的表中,也就是说不用在关系数据模型中考虑域模型中的继承关系和多态. 使用 joined-subclass 进行映射: 对于继承关系中的子类使用同一个表

[设计模式] Typed Message模式与Event Sourcing

引言 在<设计模式沉思录>(Pattern Hatching: Design Patterns Applied,[美]JohnVlissides著)一书的第4章中,围绕事件Message传递的推-拉模型(Push-Pull),谈到了一个最初被称为Multicast,之后被定型为Typed Message的设计模式. 该模式的初衷是希望得到一个可扩展的.类型安全的事件传递机制,并能符合两点要求: 通过推模型来将事件传递给消费者. 特有的每个事件只需要最多新增一个类,而不需要对已有代码进行修改.

【设计模式】——原型模式

原型模式(Prototype),用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象. 下图是原型模式的结构图: 原型模型其实就是一个对象再创建另外一个可定制的对象,而且不需任何创建的细节,我们来看看基本的原型模式代码. //原型类 class Prototype { private: string id; public: Prototype(string id) { this->id=id; } string GetId() { return id; } virtual Protot

C#设计模式-创建型模式(转)

一.简单工厂模式 简单工厂模式Simple Factory,又称静态工厂方法模式.它是类的创建模式.是由一个工厂对象决定创建出哪一种产品类的实例,是不同的工厂方法模式的一个特殊实现. 优点: u 模式的核心是工厂类,该类中含有必要的判断逻辑,可以决定在什么时候创建哪一个产品类的实例,客户端可以免除直接创建产品对象的责任,而仅仅负责"消费"产品. u 简单工厂模式实现了对责任的分割. 缺点: u 当产品类有复杂的多层次等级结构时,工厂类只有它自己.以不变应万变. u 模式中工厂类集中了所

java设计模式------装饰着模式

java设计模式-------装饰者模式 装饰者模式 Decorator模式(别名Wrapper):动态将职责附加到对象上,若要扩展功能,装饰者提供了比继承更具弹性的代替方案.主要有组件(components)和装饰器(Decorator)组成.要求components和Decorator实现相同的接口或者抽象类(具体类的局限性太大). 设计原则.模式特点.适用性 - 1. 多用组合,少用继承. 利用继承设计子类的行为,是在编译时静态决定的,而且所有的子类都会继承到相同的行为.然而,如果能够利用

设计模式3——建造者模式

1解释 1.1定义 将一个复杂对象的构建与他的表示分离,使得同样的构建可以创建不同的表示. 1.2分析 首先我们看看一般的实例化对象的方法,如下面代码: Roboter roboter = new Roboter(); roboter.setmArm("arm"); roboter.setmBody("body"); roboter.setmHead("head"); roboter.setmFoot("foot"); 对于R

游戏开发设计模式之原型模式 &amp; unity3d JSON的使用(unity3d 示例实现)

命令模式:游戏开发设计模式之命令模式(unity3d 示例实现) 对象池模式:游戏开发设计模式之对象池模式(unity3d 示例实现) 实现原型模式 原型模式带来的好处就是,想要构建生成任意独特对象的生成类,只需要一个生成类和一个原型即可.当我们有一个抽象的敌人Monster类就有很多继承它的各种各样的敌人,人类.动物.龙等等,如果我们想为每个敌人做一个生成器父类Spawner,也会有与monster对应数量的子类,也许就会这样: 这样就会产生类的数量变多,而且这些类的功能是重复的.开始的spa

JavaScript设计模式之策略模式(学习笔记)

在网上搜索“为什么MVC不是一种设计模式呢?”其中有解答:MVC其实是三个经典设计模式的演变:观察者模式(Observer).策略模式(Strategy).组合模式(Composite).所以我今天选择学习策略模式. 策略模式:定义了一系列家族算法,并对每一种算法单独封装起来,让算法之间可以相互替换,独立于使用算法的客户. 通常我并不会记得“牛顿第一定律”的具体内容,所以我也难保证我会对这个定义记得多久……用FE经常见到的东西来举个例子说明一下: $("div").animation(