设计模式读书笔记(8)

类别:软件工程 点击:0 评论:0 推荐:

行为模式,涉及到算法和对象间职责分配,涉及到描述类和对象间的通信。

 

职责链模式 Chain of Responsibility

名称:职责链模式、责任链模式

问题:

考虑一个联机帮助系统,我们根据用户点击帮助关键词上下文来显示帮助,如果没有合适的我们显示尽可能近的主题,例如文本对话框按钮同窗口的按钮帮助不同。很自然的我们需要一个界面对象中的对象来处理帮助请求,至于示哪一个对象则需要根据现场以及可用的帮助内容来决定。但提交问题的对象(例如按钮)并不知道最终的帮助提供者是谁,我们需要一种机制来将提交帮助信息的对象与可能的提供帮助信的对象解藕。

解决:

给多个对象以处理请求的机会,从而解藕发送者和接收者。该请求沿着处理链传到每个对象,直到其中的一个对象处理它。

效果:

解藕对象间紧密关系。使得处理请求的对象可以运行时刻确定(而不需要设计时候确定);而且在不明确指定对象时候向多个对象传递请求,从而使得链上的对象可以不确定。但是注意,并没有保证请求一定被处理(所以我们需要指定对策保证请求可被处理)

图:

                                           

 

 

 

命令模式 Command

名称:命令模式、行为模式(action) 、交易模式(transaction)

问题:

当我们向对象发出请求,但是并不知道被请求的对象关于请求的操作的细节和接收者的细节。例如,工具条包括菜单和按钮,响应用户输入,但是工具条设计者无法知道请求得接收者(是谁)或执行的操作。

解决:

将请求变成一个对象,使得工具条可以向任何对象发出请求(传递请求对象即可),该对象可被存储和转发。即定义一个Command类,定义执行操作的接口,具体的命令类的字类实现具体操作,实现操作者应当实现的行为,此时接收者由于有命令请求的全部信息,所以可以顺利执行命令子类。

效果:

将调用操作的对象同实现操作的对象解藕

Command对象可以被扩展

可以将多个命令复合

也可以扩充新的命令而无需修改现有类。

图:

 

 

 

解释器模式

名称:解释器模式

问题:

如果一个特定类型的问题出现的频率很高,我们就值得将问题的各个实例描述为一个句子,而通过一个专门的解释器来处理句子而解决问题。例如搜索字符串的模式匹配问题,我们采用证则表达式来解决。

解决:

将问题常见部分归纳,然后以通用解释方式来处理,设计解释器,针对具体实例来撰写语句,利用解释器来解释语句。

效果:

易于改变和扩充语法。

易于实现解释器文法,但是对于较为复杂的文法,解释器的实现和维护很困难。

增加了新的表达方式,有助于针对问题的多样解决。

图:

 

 

 

迭代器模式

名称:迭代器模式(Iterator)、游标模式(Cursor)

问题:

对于聚合对象,不希望对外暴露自己的内部结构,而又希望可以被不同方式访问到。但是即使预计到所有遍历操作,也不可能愚蠢到在接口中充斥着各种方式的遍历操作。

解决:

将访问和遍历操作分离出来到一个Itrator(迭代器)中,该迭代器定义了一个访问该列表的接口,且跟踪当前状态。而不同的列表对象刻意实现自己的迭代器具体实现。

效果:

可以以多种方式遍历一个聚合,但是简化了聚合的接口,在同一个聚合上可以实现多个遍历(因为状态维护由每一个Iterator维护)。

图:

 

 

 

 

本文地址:http://com.8s8s.com/it/it33415.htm