Home > General Development > Publish and Subscribe Using C++ and the Observer Pattern

Publish and Subscribe Using C++ and the Observer Pattern

General Development 20 Comments

Separation of concerns is increasingly on the programmer’s radar. Given the growing range of data access products and platforms, it is now essential to separate data producers from data consumers. The observer pattern provides a simple but powerful model for achieving this crucial design goal.

About The Author

Eugenia Loli

Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.

Follow me on Twitter @EugeniaLoli

20 Comments

  1. 2005-06-01 4:54 am
    Anonymous

    That page is compeltely broken in Opera..

  2. 2005-06-01 5:11 am
    Anonymous

    Broken in Opera

    Somehow, I’m not surprised. Opera doesn’t even render 100% compliant pages correctly all the time (not that this one is compliant).

  3. 2005-06-01 6:04 am
    Anonymous

    Works fine in Firefox

  4. 2005-06-01 8:31 am
    Anonymous

    Looks fine with Opera 7.54.

  5. 2005-06-01 9:19 am
    Anonymous

    It’s always funny when OSNews.com puts up actual programming stories. The silence is deafening, particularly compared with the hundred or so comments to follow every Ubuntu story.

    Personlly, the page renders find for me in both Firefox and Opera, and I’d wager it renders fine in Internet Explorer too. I’m off to read it (beautifully rendered as it is), cause lately I’ve been trying to figure out how to work with the MVC when you’re manually managing memory

  6. 2005-06-01 9:23 am
    Anonymous

    But unfortunately, this is not to be the case. The description is too simplified to be useful in real world examples.

    Ho-hum

  7. 2005-06-01 9:38 am
    Anonymous

    Separation of concerns is increasingly on the programmer’s radar. Given the growing range of data access products and platforms, it is now essential to separate data producers from data consumers. The observer pattern provides a simple but powerful model for achieving this crucial design goal.

    Wow, that description sounded really complex for something as simple as the oberserver pattern ;)

  8. 2005-06-01 11:06 am
    Anonymous

    Welcome to eXtreme Writing.

  9. 2005-06-01 12:44 pm
    Anonymous

    Haha…nice one. Making simple concepts sound complex comes with the territory in this field.

  10. 2005-06-01 12:59 pm
    Anonymous

    When I developed on the mac during System 7 days there was a C++ frame work called PowerPlant that had several really nice classes which implemented a publish and subscribe interface. Does anyone know if PowerPlant is still around and if so does it support the latest mac interface (Cococa)?

    By the way, the page renders fine in IE…

  11. 2005-06-01 1:32 pm
    Anonymous

    Nice article, though you may find the pattern better explained in

  • 2005-06-01 1:34 pm
    Anonymous

    By the way, the page renders fine in Mozilla 1.7.8 (the application suite)

  • 2005-06-01 2:20 pm
    Anonymous

    Check Observer interface and Observable class in Java. that is one of the reasons why C++ is a pain in the ass.

  • 2005-06-01 2:49 pm
    Anonymous

    Sorry about this html-spaces problem, let’s try it again 🙁

    class Subject

    {

    public:

    virtual ~Subject();

    virtual void Attach(Observer*);

    virtual void Detach(Observer*);

    virtual void Notify();

    protected:

    Subject();

    private:

    List<Observer*> *_observers;

    };

    void Subject::Attach (Observer* o)

    {

    _observers->Append(o);

    }

    void Subject::Detach (Observer* o)

    {

    _observers->Remove(o);

    }

    void Subject::Notify()

    {

    ListIterator<Observer*> i(_observers);

    for (i.First(); !i.IsDone(); i.Next())

    {

    i.CurrentItem()->Update(this);

    }

    }

  • 2005-06-01 4:08 pm
    Anonymous

    I’m sick and tired of seeing these “articles”. In reality, they are just balls of over-hyped lingo wrapped up in an attempt to over-complicate even the most basic concept. Call it what you will, but “design patterns” are not some grace upon the programming profession. You want to educate your architect on some terms to make common ground with I, the programmer? How about just keeping the architect in his or her own area and me in mine? I can’t stand all the fools who somehow come to this grand conclusion that the programming sun rises and sets on these pretentious abstractions.

  • 2005-06-01 5:16 pm
    Anonymous

    Well, I see only limited use for this Observer stuff, at least as it’s implemented in this example.

    What if I have an Object that emits 10 different kinds of events, but not every observer is interested in every event??

  • 2005-06-01 5:28 pm
    Anonymous

    Design patterns for programming are merely the codification of what a general solution looks like, that describes the general intention of something seen more than once. They are not unique to programming, that’s true: you can also use design patterns to describe commonly seen types of writing, be it prose or poetry. Design patterns also apply to building architecture as well: when you ask, “what sort of building is it?” you may get an answer, “It’s a ranch style house” which translates (in many parts of the US) into a single story house with some general characteristics, but it isn’t necessarily identical to the ranch down the road. Design patterns cover a wide variety of fields; it was only a matter of time before they entered into the computer science field. It also applies to cars, our old favorite analog to the digital world ;)

    All that being said, just because something may be classified as a design pattern, doesn’t mean that it’s actually a good pattern: all it means is that it has been seen before, and has been given a name that can be used as a convenient shorthand when communicating to someone else that knows what the names of patterns refer to in terms of concepts. A lot of people that have looked at patterns know about the originally described Visitor pattern. Those that understand that pattern and also understand about managing dependencies so they are acyclic will avoid that pattern, because it creates a very cyclic system. Just because it’s famous doesn’t make it great to use, as stated above.

    Other than using names of patterns to describe an general idea of architecture, it’s useful to know what has been done before to avoid reinventing the wheel again, where an appropriate pattern already exists for what you need to do. Where an appropriate pattern hasn’t been documented, then it’s time to go and create something different, but at least it’s less likely to be a waste of time.

  • 2005-06-02 6:28 am
    Anonymous

    Put in a more simple way:

    Design patterns are not supposed to be a huge revelation, nor are they supposed to be complicated, nor are they supposed to be elite.

    They are just names that we give to certain object structures, so we don’t have to explain them. Like, I can say, “This uses the Observer pattern, the observer is the Frame class, the subject is the Image class” and you understand it. Instead of me saying “The Image class keeps a list of all the Frames that watch it, so that when the Image updates, it notifies all the Frames and they can update to keep track of it”.

    See, much simpler.

    It’s just like me saying “I’m using a bubble sort”, which is easier than saying “I sort it by comparing pairs of objects and swapping them around if they’re not in the right order, and keep doing it until everything is in the right order”.

  • 2005-06-02 5:01 pm
    Anonymous

    What a bunch of crap. These are the patterns I deal with daily.

    How about the goto pattern

    the way too long method pattern

    the indeciperable variable pattern

    the cyclical reference pattern

    the check is in the mail pattern