C++设计模式之观察者模式

前言

之前做了一个性能测试的项目,就是需要对现在的产品进行性能测试,获得测试数据,然后书写测试报告,并提出合理化的改善意见。项目很简单,我们获得了一系列性能测试数据,对于数据,我们需要在Excel中制作测试数据的折线图、饼状图和柱状图,以直观的表现出性能的变化。在实际操作时,我发现,如果我修改了一个数据,折线图、饼状图和柱状图就都发生了变换。这个是如何做到的?这就要说到今天总结的观察者模式了,作为设计模式大家庭中最重要的一个,我们不得不去好好的学习一下观察者模式。

观察者模式

在GOF的《设计模式:可复用面向对象软件的基础》一书中对观察者模式是这样说的:定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化,关注它的对象就会得到通知;这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发布者,它发出通知时并不需要知道谁是它的观察者。

再说说上面的数据和图之间的关系;不管是折线图、饼状图,还是柱状图,它们都依赖于数据;当数据发生变化时,数据对象会通知依赖于它的对象去更新;所以就有了Excel中,当数据发生变化时,对应的统计图也会自动的重绘。

UML类图

Subject(目标)
——目标知道它的观察者。可以有任意多个观察者观察同一个目标;
——提供注册和删除观察者对象的接口。

Observer(观察者)
——为那些在目标发生改变时需获得通知的对象定义一个更新接口。

ConcreteSubject(具体目标)
——将有关状态存入各ConcreteObserver对象;
——当它的状态发生改变时,向它的各个观察者发出通知。

ConcreteObserver(具体观察者)
——维护一个指向ConcreteSubject对象的引用;
——存储有关状态,这些状态应与目标的状态保持一致;
——实现Observer的更新接口以使自身状态与目标的状态保持一致。

观察者模式按照以下方式进行协作:

1.当ConcreteSubject发生任何可能导致其观察者与其本身状态不一致的改变时,它将通知它的各个观察者;

2.在得到一个具体目标的改变通知后,ConcreteObserver对象可向目标对象查询信息。ConcreteObserver使用这些信息以使它的状态与目标对象的状态一致。

以下是调用时序图:

使用场合

在以下任一情况下都可以使用观察者模式:

1.当一个抽象模型有两个方面,其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立的改变和复用;
2.当对一个对象的改变需要同时改变其它对象,而不知道具体有多少对象有待改变;
3.当一个对象必须通知其它对象,而它又不能假定其它对象是谁;也就是说,你不希望这些对象是紧密耦合的。

代码实现

代码如下:

#include <iostream>
#include <list>
using namespace std;
 
class Observer
{
public:
     virtual void Update(int) = 0;
};
 
class Subject
{
public:
     virtual void Attach(Observer *) = 0;
     virtual void Detach(Observer *) = 0;
     virtual void Notify() = 0;
};
 
class ConcreteObserver : public Observer
{
public:
     ConcreteObserver(Subject *pSubject) : m_pSubject(pSubject){}
 
     void Update(int value)
     {
          cout<<"ConcreteObserver get the update. New State:"<<value<<endl;
     }
 
private:
     Subject *m_pSubject;
};
 
class ConcreteObserver2 : public Observer
{
public:
     ConcreteObserver2(Subject *pSubject) : m_pSubject(pSubject){}
 
     void Update(int value)
     {
          cout<<"ConcreteObserver2 get the update. New State:"<<value<<endl;
     }
 
private:
     Subject *m_pSubject;
};
 
class ConcreteSubject : public Subject
{
public:
     void Attach(Observer *pObserver);
     void Detach(Observer *pObserver);
     void Notify();
 
     void SetState(int state)
     {
          m_iState = state;
     }
 
private:
     std::list<Observer *> m_ObserverList;
     int m_iState;
};
 
void ConcreteSubject::Attach(Observer *pObserver)
{
     m_ObserverList.push_back(pObserver);
}
 
void ConcreteSubject::Detach(Observer *pObserver)
{
     m_ObserverList.remove(pObserver);
}
 
void ConcreteSubject::Notify()
{
     std::list<Observer *>::iterator it = m_ObserverList.begin();
     while (it != m_ObserverList.end())
     {
          (*it)->Update(m_iState);
          ++it;
     }
}
 
int main()
{
     // Create Subject
     ConcreteSubject *pSubject = new ConcreteSubject();
 
     // Create Observer
     Observer *pObserver = new ConcreteObserver(pSubject);
     Observer *pObserver2 = new ConcreteObserver2(pSubject);
 
     // Change the state
     pSubject->SetState(2);
 
     // Register the observer
     pSubject->Attach(pObserver);
     pSubject->Attach(pObserver2);
 
     pSubject->Notify();
 
     // Unregister the observer
     pSubject->Detach(pObserver);
 
     pSubject->SetState(3);
     pSubject->Notify();
 
     delete pObserver;
     delete pObserver2;
     delete pSubject;
}

总结

观察者模式在23个设计模式中的地位是非常高的,我们基本上各大框架中都是随处可见。真正的理解了整个模式,对我们去理解别人的代码有非常大的帮助;在我们日后的工作中也会或多或少的使用该设计模式。这里总结的不是很全面,在日后如果碰到了需要补充的内容,我会继续补充的;同时也希望大家提出更好的建议。

(0)

相关推荐

  • 详解C++设计模式编程中建造者模式的实现

    建造者模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.这是建造者模式的标准表达,不过看着让人迷惑,什么叫构建和表示的分离?一个对象使用构造函数构造之后不就固定了,只有通过它方法来改变它的属性吗?而且还要同样的构建过程搞出不同的表示,怎么可能呢?多写几个构造函数? 其实多写几个构造函数,根据不同参数设置对象不同的属性,也可以达到这样的效果,只是这样就非常麻烦了,每次要增加一种表示就要添加一个构造函数,将来构造函数会多得连自己都不记得了,这违背了开放-封闭的原则. 要

  • 详解C++设计模式编程中策略模式的优缺点及实现

    策略模式(Strategy):它定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换.策略模式让算法的变化不会影响到使用算法的客户.策略模式和 Template 模式要解决的问题是相同(类似)的,都是为了给业务逻辑(算法)具体实现和抽象接口之间的解耦.策略模式将逻辑(算法)封装到一个类(Context)里面,通过组合的方式将具体算法的实现在组合对象中实现,再通过委托的方式将抽象接口的实现委托给组合对象实现.State 模式也有类似的功能,他们之间的区别将在讨论中给出. UML图

  • 使用设计模式中的单例模式来实现C++的boost库

    线程安全的单例模式 一.懒汉模式:即第一次调用该类实例的时候才产生一个新的该类实例,并在以后仅返回此实例. 需要用锁,来保证其线程安全性:原因:多个线程可能进入判断是否已经存在实例的if语句,从而non thread safety. 使用double-check来保证thread safety.但是如果处理大量数据时,该锁才成为严重的性能瓶颈. 1.静态成员实例的懒汉模式: class Singleton { private: static Singleton* m_instance; Sing

  • C++设计模式编程中的观察者模式使用示例

    概述: 最近中国股市起起伏伏,当然了起伏就用商机,小明发现商机后果断想入市,买入了中国证券,他想在电脑客户端上,网页上,手机上,iPad上都可以查看到该证券的实时行情,这种情况下我们应该怎么设计我们的软件呢?我们可以这样:小明的所有客户端上都订阅中国证券这个股票,只要股票一有变化,所有的客户端都会被通知到并且被自动更新. 这就是我们的观察者模式,她定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新. 类图: 可以看出,在这个观察者模式的实现里

  • 举例解析设计模式中的工厂方法模式在C++编程中的运用

    工厂方法模式不同于简单工厂模式的地方在于工厂方法模式把对象的创建过程放到里子类里.这样工厂父对象和产品父对象一样,可以是抽象类或者接口,只定义相应的规范或操作,不涉及具体的创建或实现细节. 其类图如下: 实例代码为: #pragma once class IProduct { public: IProduct(void); virtual ~IProduct(void); }; #pragma once #include "iproduct.h" class IPad : public

  • C++设计模式之中介者模式

    前言 我们都知道,这个国际政治是一门很深的学问,不玩政治的人是搞不懂的.那么多的国家,国家之间的关系又及其复杂:就好比现在,美国和中国有经济利益关系,美国又和日本有盟友关系,朝鲜又和中国有说不清道不明的关系:这些复杂的关系,稍微处理不好,就可能引发局部战争,更有可能引发第三次世界大战.如果出现了国与国之间出现了利益纠纷,那么该怎么办呢?这个时候,联合国出现了.联合国就是一个处理国与国之间纠纷的中介者. 中介者模式 在GOF的<设计模式:可复用面向对象软件的基础>一书中对中介者模式是这样说的:用

  • 简单了解设计模式中的装饰者模式及C++版代码实现

    由遇到的问题引出的装饰模式 在 OO 设计和开发过程,可能会经常遇到以下的情况:我们需要为一个已经定义好的类添加新的职责(操作),通常的情况我们会给定义一个新类继承自定义好的类,这样会带来一个问题(将在本模式的讨论中给出).通过继承的方式解决这样的情况还带来了系统的复杂性,因为继承的深度会变得很深. 而装饰提供了一种给类增加职责的方法,不是通过继承实现的,而是通过组合. 有关这些内容在讨论中进一步阐述. 模式选择 装饰模式典型的结构图为: 在 结 构 图 中 , ConcreteComponen

  • C++设计模式之职责链模式

    前言 最近心情很差,因为生活,因为工作:所以想请几天假去丽江玩玩.就向项目经理提交了休假申请,我的项目经理向项目主管提交了我的休假申请,项目主管向部门经理提交了我的休假申请:最后,部门经理同意了我的休假申请.是的,一个简单的休假申请,需要这么复杂的流程,这也是一个公司保证它正常运行的必要.如果部门经理休假了,那么我的休假申请由谁审批呢?这个时候由项目主管代替部门经理进行审批.一个休假申请的审批制度有着严格的要求.而在处理这个请假审批时,各个人员就好比在一条链上的节点,我不知道我的请求由谁审批,但

  • 实例解析C++设计模式编程中简单工厂模式的采用

    简单工厂模式中专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类.它又称为静态工厂方法模式,属于类的创建型模式. 简单工厂模式的UML类图 简单工厂模式的程序通过封装继承来降低程序的耦合度,设计模式使得程序更加的灵活,易修该,易于复用. 简单工厂是在工厂类中做判断,从而创造相应的产品. 简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类(这些产品类继承自一个父类或接口)的实例.   该模式中包含的角色及其职责   1.工厂(Creator)角色  

  • C++设计模式之装饰模式

    前言 在实际开发时,你有没有碰到过这种问题:开发一个类,封装了一个对象的核心操作,而这些操作就是客户使用该类时都会去调用的操作:而有一些非核心的操作,可能会使用,也可能不会使用:现在该怎么办呢? 1.将这些非核心的操作全部放到类中,这样,一个类就包含了很多核心的操作和一些看似有关,但是又无关的操作:这就会使核心类发生"爆炸"的现象,从而使核心类失去了一定的价值,也使使用核心类的客户在核心操作和非核心操作中挣扎: 2.使用继承来扩展核心类,需要使用核心类时,直接建立核心类对象:当需要使用

随机推荐