求知 文章 文库 Lib 视频 Code iProcess 课程 角色 咨询 工具 火云堂 讲座吧   建模者  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
我所理解的设计模式(四)
 
火龙果软件    发布于 2014-02-24
 

十三、责任链模式(Chain Of Responsibility Pattern)

概述

辛辛苦苦了工作了一年,终于可以加薪了,向主管提交了加薪申请,主管一看不得了,自己职权不够,批不了,主管把申请上交总监,总监发现自己也批不了,申请到了总经理手中,总经理一看,小伙子口气不小了,有胆识敢申请,先来谈下心。预知后事如何,请看下回分解。

这就是典型的职责链模式,请求的处理形成了一条链,直到有一个对象处理请求。责任链模式是一种对象的行为模式。在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。

类图和样例

抽象处理者(Handler)角色:定义出一个处理请求的接口。如果需要,接口可以定义出一个方法,以设定和返回对下家的引用。这个角色通常由一个抽象类或接口实现。

具体处理者(ConcreteHandler)角色:具体处理者接到请求后,可以选择将请求处理掉,或者将请求传给下家。由于具体处理者持有对下家的引用,因此,如果需要,具体处理者可以访问下家。

样例:

#include <iostream>
#include <string>
using namespace std;
// 请求
class Request
{
public:
int m_nNumber;
};
// 管理者
class Manager
{
public:
Manager(string temp) { name = temp; }
void SetSuccessor(Manager* temp) { manager = temp; }
virtual void GetRequest(Request* request) = 0;
protected:
Manager* manager;
string name;
};
// 经理
class CommonManager : public Manager
{
public:
CommonManager(string strTemp) : Manager(strTemp) {}
virtual void GetRequest(Request* request);
};
void CommonManager::GetRequest(Request* request)
{
if (request->m_nNumber>=0 && request->m_nNumber<1000)
{
cout << name << " 处理了请求: " << request->m_nNumber << endl;
}
else
{
manager->GetRequest(request);
}
}
// 总监
class Majordomo : public Manager
{
public:
Majordomo(string strTemp) : Manager(strTemp) {}
virtual void GetRequest(Request* request);
};
void Majordomo::GetRequest(Request* request)
{
if (request->m_nNumber <= 5000)
{
cout << name << " 处理了请求: " << request->m_nNumber << endl;
}else
{
manager->GetRequest(request);
}
}
//总经理
class GeneralManager: public Manager
{
public:
GeneralManager(string name):Manager(name) {}
virtual void GetRequest(Request* request) //总经理可以处理所有请求
{
cout << name << " 处理了请求: " << request->m_nNumber << endl;
}
};
int main(){
Manager* common = new CommonManager("张经理");
Manager* major = new Majordomo("李总监");
GeneralManager* general = new GeneralManager("赵总");
common->SetSuccessor(major);
major->SetSuccessor(general);
Request* rq = new Request();
rq->m_nNumber = 999;
common->GetRequest(rq);

rq->m_nNumber = 4999;
common->GetRequest(rq);
rq->m_nNumber = 6999;
common->GetRequest(rq);
delete rq;
delete major;
delete common;
delete general;
return 0;
}

要点与实现:

1.要注意的是:一个请求到链的最后可能也没有处理,所以一定要配置得当.

2.责任链模式并不创建责任链。责任链的创建必须由系统的其它部分创建出来。

3.责任链模式降低了请求的发送端和接收端之间的耦合,使多个对象都有机会处理这个请求。一个链可以是一条线,一个树,也可以是一个环。如下图所示,责任链是一个树结构的一部分。

十四、命令模式(Command Pattern)

概述:

我们去餐厅吃饭,我们是通过服务员来点菜,具体是谁来做这些菜和他们什么时候完成的这些菜,其实我们都不知道。抽象之,“菜单请求者”我们和“菜单实现者”厨师,2者之间是松耦合的,我们对这些菜的其他一些请求比如“撤销,重做”等,我们也不知道是谁在做。其实这就是本文要说的Command模式。

将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤消的操作。[GOF 《设计模式》]

类图与实例:

角色用途:

客户(Client)角色:创建了一个具体命令(ConcreteCommand)对象并确定其接收者。

命令(Command)角色:声明了一个给所有具体命令类的抽象接口。这是一个抽象角色。

具体命令(ConcreteCommand)角色:定义一个接受者和行为之间的弱耦合;实现Execute()方法,负责调用接收考的相应操作。Execute()方法通常叫做执行方法。

请求者(Invoker)角色:负责调用命令对象执行请求,相关的方法叫做行动方法。

接收者(Receiver)角色:负责具体实施和执行一个请求。任何一个类都可以成为接收者,实施和执行请求的方法叫做行动方法。

实例:

#include <iostream>
#include <vector>
using namespace std;// 烤肉师傅
class RoastCook
{
public:
void MakeMutton() { cout << "烤羊肉" << endl; }
void MakeChickenWing() { cout << "烤鸡翅膀" << endl; }
};// 抽象命令类
class Command
{
public:
Command(RoastCook* temp) { receiver = temp; }
virtual void ExecuteCmd() = 0;
protected:
RoastCook* receiver;
};
// 烤羊肉命令
class MakeMuttonCmd : public Command
{
public:
MakeMuttonCmd(RoastCook* temp) : Command(temp) {}
virtual void ExecuteCmd() { receiver->MakeMutton(); }
};
// 烤鸡翅膀命令
class MakeChickenWingCmd : public Command
{
public:
MakeChickenWingCmd(RoastCook* temp) : Command(temp) {}
virtual void ExecuteCmd() { receiver->MakeChickenWing(); }
};
// 服务员类
class Waiter
{
public:
void SetCmd(Command* temp);
// 通知执行
void Notify();
protected:
vector<Command*> m_commandList;
};
void Waiter::SetCmd(Command* temp)
{
m_commandList.push_back(temp);
cout << "增加订单" << endl;
}
void Waiter::Notify()
{
vector<Command*>::iterator it;
for (it=m_commandList.begin(); it!=m_commandList.end(); ++it)
{
(*it)->ExecuteCmd();
}
}
int main()
{
// 店里添加烤肉师傅、菜单、服务员等顾客
RoastCook* cook = new RoastCook();
Command* cmd1 = new MakeMuttonCmd(cook);
Command* cmd2 = new MakeChickenWingCmd(cook);
Waiter* girl = new Waiter();
// 点菜
girl->SetCmd(cmd1);
girl->SetCmd(cmd2);
// 服务员通知
girl->Notify();
return 0;
}

效果与实现要点:

1.Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦,在面向对象语言中,常见的实现手段是“将行为抽象为对象”。

2.实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。

3.通过使用Compmosite模式,可以将多个命令封装为一个“复合命令”MacroCommand。

4.Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别:Command以面向对象中的“接口-实现”来定义行为接口规范,更严格,更符合抽象原则;Delegate以函数签名来定义行为接口规范,更灵活,但抽象能力比较弱。

5.使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个,几百个甚至几千个具体命令类,这会使命令模式在这样的系统里变得不实际。

适用性:

在下面的情况下应当考虑使用命令模式:

1.使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上,然后在以后调用此函数。

2.需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之,原先的请求发出者可能已经不在了,而命令对象本身仍然是活动的。这时命令的接收者可以是在本地,也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。

3.系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来,等到客户端需要撤销命令所产生的效果时,可以调用undo()方法,把命令所产生的效果撤销掉。命令对象还可以提供redo()方法,以供客户端在需要时,再重新实施命令效果。

4.如果一个系统要将系统中所有的数据更新到日志里,以便在系统崩溃时,可以根据日志里读回所有的数据更新命令,重新调用Execute()方法一条一条执行这些命令,从而恢复系统在崩溃前所做的数据更新。

十五、模板方法模式(Template Method Pattern)

概述:

我们最近在开发一个支持多种压缩类型文件的解压缩且制作成pdf的一个应用。对我们的架构来说我们需要支持多种压缩文件类型,但却有固定的操作顺序(先解压缩,在读取里面的文件分析、制作pdf)。我们抽取他们的共同点:这些操作的固定顺序,把他放到我们的父类里;他们的变化点:这些个具体的操作,去留给不同的子类去实现。这个就是模板方法模式,他定义一个操作中的算法的骨架(例子中的固定的操作顺序),而将一些步骤延迟到子类中(例子中的多种压缩文件的解压缩)。

Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。是一种比较简单的设计模式,但却是代码复用的一项基本技术,在类库中尤其重要。使用的也比较普遍。

类图与实例:

这里涉及到两个角色:

抽象模版(AbstractClass)角色:

定义了一个或多个抽象操作,以便让子类实现。这些抽象操作叫做基本操作,它们是一个顶级逻辑的组成步骤。

定义并实现了一个模版方法。这个模版方法一般是一个具体方法,它给出了一个顶级逻辑的骨架,而逻辑的组成步骤在相应的抽象操作中,推迟到子类实现。顶级逻辑也有可

调用一些具体方法。这个就是定义了我们的固定的操作顺序。

具体模版(ConcreteClass)角色:

实现父类所定义的一个或多个抽象方法,它们是一个顶级逻辑的组成步骤。

每一个抽象模版角色都可以有任意多个具体模版角色与之对应,而每一个具体模版角色都可以给出这些抽象方法(也就是顶级逻辑的组成步骤)的不同实现,从而使得顶级逻辑的实现各不相同。就是对我们的多个压缩文件的不同的解压缩的支持。

实例:

#include <iostream>
template <typename T> class CaffeineBeverage //咖啡因饮料
{
public:
void PrepareRecipe() //咖啡因饮料冲泡法
{
BoilWater(); //把水煮沸
Brew(); //冲泡
PourInCup(); //把咖啡因饮料倒进杯子
AddCondiments(); //加调料
}
void BoilWater()
{std::cout << "把水煮沸" << std::endl;}
void Brew()
{static_cast<T *>(this)->Brew();}
void PourInCup()
{std::cout << "把咖啡倒进杯子" << std::endl;}
void AddCondiments()
{static_cast<T *>(this)->AddCondiments();}
};
class Coffee : public CaffeineBeverage<Coffee>
{
public:
void Brew()
{std::cout << "用沸水冲泡咖啡" << std::endl;}
void AddCondiments()
{std::cout << "加糖和牛奶" << std::endl;}
};
class Tea : public CaffeineBeverage<Tea>
{
public:
void Brew()
{std::cout << "用沸水浸泡茶叶" << std::endl;}
void AddCondiments()
{std::cout << "加柠檬" << std::endl;}
};
int main(void)
{
std::cout << "冲杯咖啡:" << std::endl;
Coffee c;
c.PrepareRecipe();
std::cout << std::endl;
std::cout << "冲杯茶:" << std::endl;
Tea t;
t.PrepareRecipe();
return 0;
}

适用性:

1.一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现。

2.各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是Opdyke和Johnson所描述过的“重分解以一般化”的一个很好的例子。首先识别现有代码中的不同之处,并且将不同之处分离为新的操作。最后,用一个调用这些新的操作的模板方法来替换这些不同的代码。

3.控制子类扩展。模板方法只在特定点调用“Hook”操作,这样就只允许在这些点进行扩展。

实现要点:

1.Template Method模式是一种非常基础性的设计模式,在面向对象系统中有着大量的应用。它用最简洁的机制(虚函数的多态性)为很多应用程序框架提供了灵活的扩展点,是代码复用方面的基本实现结构。

2.除了可以灵活应对子步骤的变化外,“不用调用我,让我来调用你”的反向控制结构是Template Method的典型应用。

3.在具体实现方面,被Template Method调用的虚方法可以具有实现,也可以没有任何实现(抽象方法,纯虚方法),但一般推荐将它们设置为protected方法。

十六、观察者模式(Observer Pattern)

概述:

最近中国股市起起伏伏,当然了起伏就用商机,小明发现商机后果断想入市,买入了中国证券,他想在电脑客户端上,网页上,手机上,iPad上都可以查看到该证券的实时行情,这种情况下我们应该怎么设计我们的软件呢?我们可以这样:小明的所有客户端上都订阅中国证券这个股票,只要股票一有变化,所有的客户端都会被通知到并且被自动更新。

这就是我们的观察者模式,她定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。

类图与实例:

可以看出,在这个观察者模式的实现里有下面这些角色:

抽象主题(Subject)角色:主题角色把所有对观察考对象的引用保存在一个聚集里,每个主题都可以有任何数量的观察者。抽象主题提供一个接口,可以增加和删除观察者对象,主题角色又叫做抽象被观察者(Observable)角色,一般用一个抽象类或者一个接口实现。

抽象观察者(Observer)角色:为所有的具体观察者定义一个接口,在得到主题的通知时更新自己。这个接口叫做更新接口。抽象观察者角色一般用一个抽象类或者一个接口实现。在这个示意性的实现中,更新接口只包含一个方法(即Update()方法),这个方法叫做更新方法。

具体主题(ConcreteSubject)角色:将有关状态存入具体现察者对象;在具体主题的内部状态改变时,给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者角色(Concrete Observable)。具体主题角色通常用一个具体子类实现。

具体观察者(ConcreteObserver)角色:存储与主题的状态自恰的状态。具体现察者角色实现抽象观察者角色所要求的更新接口,以便使本身的状态与主题的状态相协调。如果需要,具体现察者角色可以保存一个指向具体主题对象的引用。具体观察者角色通常用一个具体子类实现。

从具体主题角色指向抽象观察者角色的合成关系,代表具体主题对象可以有任意多个对抽象观察者对象的引用。之所以使用抽象观察者而不是具体观察者,意味着主题对象不需要知道引用了哪些ConcreteObserver类型,而只知道抽象Observer类型。这就使得具体主题对象可以动态地维护一系列的对观察者对象的引用,并在需要的时候调用每一个观察者共有的Update()方法。这种做法叫做"针对抽象编程"。

这里我们提供一个简单化的实例:

#include <iostream>
#include <vector>
#include <string>
using namespace std;
class Secretary;
// 看股票的同事类(观察对象,观察者)
class StockObserver
{
public:
StockObserver(string strName, Secretary* strSub)
{
name = strName;
sub = strSub;
}
void Update();
private:
string name;
Secretary* sub;
};
// 秘书类(主题对象,通知者)
class Secretary
{
public:
string action;
void Add(StockObserver ob) { observers.push_back(ob); }
void Remove(int addIndex)
{
if(addIndex >=0 && addIndex < observers.size())
observers.erase(observers.begin() + addIndex);
}
void Notify()
{
vector<StockObserver>::iterator it;
for (it=observers.begin(); it!=observers.end(); ++it)
{
(*it).Update();
}
}
private:
vector<StockObserver> observers;
};


void StockObserver::Update()
{
cout << name << " : " << sub->action << ", begin to work" << endl;
}
int main()
{
// 创建通知者
Secretary* p = new Secretary();
// 观察者
StockObserver* s1 = new StockObserver("Lazy", p);
StockObserver* s2 = new StockObserver("SnowFire", p);
// 加入通知队列
p->Add(*s1);
p->Add(*s2);
// 事件
p->action = "The boss is coming...";
// 通知
p->Notify();
// 动态删除
p->Remove(0);

p->Notify();
return 0;
}

适用性:

1.当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。

2.当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。

3.当一个对象必须通知其它对象,而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。

优缺点:

观察者模式的效果有以下几个优点:

1.观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体现察者聚集,每一个具体现察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体观察者,它只知道它们都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起,因此它们可以属于不同的抽象化层次。

2.观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。

观察者模式有下面的一些缺点:

1.如果一个被观察者对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间。

2.如果在被观察者之间有循环依赖的话,被观察者会触发它们之间进行循环调用,导致系统崩溃。在使用观察考模式时要特别注意这一点。

3.如果对观察者的通知是通过另外的线程进行异步投递的话,系统必须保证投递是以自恰的方式进行的。

4.虽然观察者模式可以随时使观察者知道所观察的对象发生了变化,但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。

其他:

1.在.NET中可以利用Delegate与Event机制来实现观察者模式。

2.Java提供了Observer 和Observable来帮助我们简化实现观察者模式。

相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
 
分享到
 
 


重构-使代码更简洁优美
Visitor Parttern
由表及里看模式
设计模式随笔系列
深入浅出设计模式-介绍
.NET中的设计模式
更多...   

相关培训课程

J2EE设计模式和性能调优
应用模式设计Java企业级应用
设计模式原理与应用
J2EE设计模式指南
单元测试+重构+设计模式
设计模式及其CSharp实现


某电力公司 设计模式原理
蓝拓扑 设计模式原理及应用
卫星导航 UML & OOAD
汤森路透研发中心 UML& OOAD
中达电通 设计模式原理
西门子 嵌入式设计模式
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号