Click here to Skip to main content
15,911,315 members
Articles / Programming Languages / C++

Understanding and Implementing Observer Pattern in C++

Rate me:
Please Sign up or sign in to vote.
4.72/5 (23 votes)
25 Mar 2012CPOL2 min read 225.1K   1.6K   39   29
This article presents the basics of Observer Pattern, when to use it and how to implement it in C++.

Introduction

This article presents the basics of Observer Pattern, when to use it and how to implement it in C++. I have posted a similar article that talks about the Observer pattern in C#. The main aim of this article will be to implement the observer pattern in C++.

Background

Many a times, we need one part of our application updated with the status of some other part of the application. One way to do this is to have the receiver part repeatedly check the sender for updates but this approach has two main problems. First, it takes up a lot of CPU time to check the new status and second, depending on the interval we are checking for change we might not get the updates "immediately".

This problem has one easy solution, i.e., Observer Pattern. This is my own second article on Observer Pattern. I have a similar article talking about Observer Implementation in C#. I think this article is also worth sharing, as it could be useful for the C++ beginners and also the valuable comments I get on the article will let me learn more.

Here is the class diagram for Observer Pattern(Reference:  GoF Design Patterns)

Image 1

Using the Code

Let us now discuss all the classes one by one:

  • Subject: This class keeps track of all the observers and provides the facility to add or remove the observers. Also it is the class that is responsible for updating the observers when any change occurs. In our solution, we have ASubject implemented for the same purpose.
  • ConcreteSubject: This class is the real class that implements the Subject. This class is the entity whose change will affect other objects. We have DummyProject class implemented for the same.
  • Observer: This represents an interface that defines the method that should be called whenever there is change. We have implemented this as IObserver.
  • ConcreteObserver: This is the class which needs to keep itself updated with the change. This class just needs to implement the Observer and register itself with the ConcreteSubject and it is all set to receive the updates. We have Shop class in our application serving the same purpose.

The Subject: ASubject

C++
//Header File
#pragma once
#include <vector>
#include <list>
#include "shop.h"

class ASubject
{
    //Lets keep a track of all the shops we have observing
    std::vector<Shop*> list;

public:
    void Attach(Shop *product);
    void Detach(Shop *product);
    void Notify(float price); 
};

//CPP File
#include "ASubject.h"
#include <algorithm>

using namespace std;

void ASubject::Attach(Shop *shop)
{
    list.push_back(shop);
}
void ASubject::Detach(Shop *shop)
{    
    list.erase(std::remove(list.begin(), list.end(), shop), list.end());    
}

void ASubject::Notify(float price)
{
    for(vector<Shop*>::const_iterator iter = list.begin(); iter != list.end(); ++iter)
    {
        if(*iter != 0)
        {
            (*iter)->Update(price);
        }
    }
}

The ConcreteSubject: DummyProduct

C++
//Header File
#pragma once
#include "ASubject.h"

class DummyProduct : public ASubject
{
public:
    void ChangePrice(float price);
};

//CPP File
#include "DummyProduct.h"

void DummyProduct::ChangePrice(float price)
{
    Notify(price);
}

The Observer: IObserver

C++
#pragma once

class IObserver
{
public:
    virtual void Update(float price) = 0;
};

The ConcreteObserver: Shop

C++
//Header File
#pragma once
#include <iostream>
#include <string>
#include "IObserver.h"

class Shop : IObserver
{
    //Name of the Shop
    std::string name;
    float price;
public:
    Shop(std::string n); 
    void Update(float price);          
};

//CPP File
#include "Shop.h"

Shop::Shop(std::string name)
{
    this->name = name;
}

void Shop::Update(float price)
{
    this->price = price;

    //Lets print on console just to test the working
    std::cout << "Price at "<< name << " is now "<< price << "\n";
}

Testing the Code

C++
int main(int argc, char* argv[])
{
    DummyProduct product;
                    
    // We have four shops wanting to keep updated price set by product owner
    Shop shop1("Shop 1");
    Shop shop2("Shop 2");

    product.Attach(&shop1);
    product.Attach(&shop2);

    //Now lets try changing the products price, this should update the shops automatically
    product.ChangePrice(23.0f);

    //Now shop2 is not interested in new prices so they unsubscribe
    product.Detach(&shop2);            

    //Now lets try changing the products price again
    product.ChangePrice(26.0f);

    getchar();
    return 0;
}

Points of Interest

This article covers the basics of Observer pattern and provides a basic implementation in C++. I have also implemented the same in C#. What I learnt from it is how the observer pattern works and what are the similarities and differences in implementing it in C++ and C#.

History

  • 10 Feb, 2012: Simple and rudimentary implementation of Observer pattern in C++
  • 26 March 2012: Changed the class diagram.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Architect
India India

I Started my Programming career with C++. Later got a chance to develop Windows Form applications using C#. Currently using C#, ASP.NET & ASP.NET MVC to create Information Systems, e-commerce/e-governance Portals and Data driven websites.

My interests involves Programming, Website development and Learning/Teaching subjects related to Computer Science/Information Systems. IMO, C# is the best programming language and I love working with C# and other Microsoft Technologies.

  • Microsoft Certified Technology Specialist (MCTS): Web Applications Development with Microsoft .NET Framework 4
  • Microsoft Certified Technology Specialist (MCTS): Accessing Data with Microsoft .NET Framework 4
  • Microsoft Certified Technology Specialist (MCTS): Windows Communication Foundation Development with Microsoft .NET Framework 4

If you like my articles, please visit my website for more: www.rahulrajatsingh.com[^]

  • Microsoft MVP 2015

Comments and Discussions

 
GeneralMy vote of 1 Pin
zennie19-Mar-12 21:49
zennie19-Mar-12 21:49 
SuggestionUsing templates Pin
John Wellbelove13-Feb-12 22:15
John Wellbelove13-Feb-12 22:15 
GeneralMy vote of 4 Pin
KjellKod.cc13-Feb-12 10:20
KjellKod.cc13-Feb-12 10:20 
GeneralRe: My vote of 4 Pin
Stefan_Lang14-Feb-12 0:41
Stefan_Lang14-Feb-12 0:41 
GeneralRe: My vote of 4 Pin
KjellKod.cc15-Feb-12 3:19
KjellKod.cc15-Feb-12 3:19 
GeneralRe: My vote of 4 Pin
Stefan_Lang16-Feb-12 23:12
Stefan_Lang16-Feb-12 23:12 
GeneralRe: My vote of 4 Pin
KjellKod.cc17-Feb-12 2:07
KjellKod.cc17-Feb-12 2:07 
GeneralRe: My vote of 4 Pin
Stefan_Lang17-Feb-12 4:25
Stefan_Lang17-Feb-12 4:25 
KjellKod.cc wrote:
Meaning this is not clear in the Observer pattern either,. at least not if a clear interface structure is being used.

Ah, you've got me there. In fact, we did use separate objects at first to implement the callback interface that was to notify the observers. That way we didn't have to use multiple inheritance for the observers. However, we later realized that there really was no point in creating individual objects for each and every connection. And also, when it became apparent we couldn't afford to keep all connections active all of the time, the logical step was to move that logic into the observers. Cool | :cool:

KjellKod.cc wrote:
There is nothing to stop you from using signals-n-slots and using a connect/disconnect though an interface is there?

Yes, in fact there is: As I pointed out, the connection in that case I mentioned often depended on the observers inner state. That means any external object activating or deactivating that connection would have had to be notified of a change of that state, turning it into an observer! It would be rather ironic to decouple an observer from its duty to maintain its connections by introducing an observer to that observer! D'Oh! | :doh:

KjellKod.cc wrote:
Nothing says you cannot do this using signals-n-slots either.

Well, yes, of course. If we had known about that 10 years ago we might have considered it. That doesn't mean we would have used it. Wink | ;)
KjellKod.cc wrote:
OO design need both composition and inheritance.

Yes, and that is my whole point. There are times when you need inheritance, and others where you need composition. Going purely by OO principles, you should make your design based on the relationship of the individual objects. That's what we did. That's why we implemented the observer pattern (although at the time I didn't even know it by that name). I am well aware of the possible drawbacks of inheritance, but we didn't suffer any, so we had no reason to look for another solution.

KjellKod.cc wrote:
(regarding performance)
If you then are unlucky enough to have an "Observer" that needs to receive several types of data and use multiple-inheritance to get it then you are on a downhill slope.

In the project I was talking about there was no notable cost for using virtual or multiple inheritance. Avoiding it wouldn't have gained us anything at all. But there was a notable cost for extra traffic between threads, context switching, waking up sleeping threads unnecessarily, and the like. Therefore minimizing communication was top priority.

I can easily see how - depending on the system you're on and the priorities you face - using virtual inheritance indiscriminately may bog down your application to a standstill. But that simply wasn't the case for us.

In the end, what pattern you should use depends on the problem at hand. Java | [Coffee]
GeneralRe: My vote of 4 Pin
KjellKod.cc17-Feb-12 6:06
KjellKod.cc17-Feb-12 6:06 
QuestionGood Article Pin
godistwo11-Feb-12 5:31
godistwo11-Feb-12 5:31 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.