469,600 Members | 2,235 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,600 developers. It's quick & easy.

Generalized "observer" pattern


Two issues here:

a) What is the accepted definition of "observer pattern". While I can't
point to anything specific, I do remember having issues with
inconsistency in the definition.

b) Generic observer design in C++. I have been pushing the Austria
"Twin" interface for a while and more recently the multi threaded
version of it "TwinMT" (see the 6129 alpha on sourceforge)

I am trying to distill the "fundamental" hard problems in software
development, especially regarding C++ and I've seen too many issues
relating to the observer pattern I think it is elevated to "fundamental".

By fundamental issues I mean, "avoiding deadlock conditions", object
lifetime management etc.

There is no specific question really, just an invitiation for thoughts
on the topic.
Sep 23 '07 #1
4 4411

Gianni Mariani wrote:
a) What is the accepted definition of "observer pattern". While I can't
point to anything specific, I do remember having issues with
inconsistency in the definition.
Aside, and probably OT, I've written a little generic class that
performs
RAII subscription/unsubsription. I attempted to make it definition
independent, handling either attach/detach, subscribe/unsubscribe or
add/remove as potential interface. It was merely a nice exercise for
SFINAE (and credit to some posts in c.l.c++, as well as boost
archives).

CAVEAT: Does not use weak pointer yet as described in my other
mail. I just at the time of writing this have not thought of that
problem
yet.

Here goes:

namespace AviGen {
namespace GenSubPriv{

typedef char (&subscribe)[0];
typedef char (&add)[1];
typedef char (&attach)[2];
template < typename T, void (T::*)() >
struct ptmf_helper {};

template< typename T subscribe get_method_literal( ... ); //
Subscribe
template< typename T add
get_method_literal( ptmf_helper<T,&T::add>* );
template< typename T attach
get_method_literal( ptmf_helper<T,&T::attach>* );

template <class PubT, class SubT, std::size_t>
class GenSubBase;

// Used subscribe/unsubscribe to subscribe.
template <class PubT, class SubT>
class GenSubBase<PubT, SubT, sizeof(subscribe): public SubT
{
protected:
GenSubBase( PubT& publisher ): publisher_( publisher )
{ publisher_.subscribe( *this ); }
virtual ~GenSubBase()
{ publisher_.unsubscribe( *this ); }
private:
PubT* publisher_;
};

// Used add/remove to subscribe.
template <class PubT, class SubT>
class GenSubBase<PubT, SubT, sizeof(add): public SubT
{
protected:
GenSubBase( PubT& publisher ): publisher_( publisher )
{ publisher_.add( *this ); }
virtual ~GenSubBase()
{ publisher_.remove( *this ); }
private:
PubT* publisher_;
};

// Used attach/detach to subscribe.
template <class PubT, class SubT>
class GenSubBase<PubT, SubT, sizeof(attach): public SubT
{
protected:
GenSubBase( PubT& publisher ): publisher_( publisher )
{ publisher_.attach( *this ); }
virtual ~GenSubBase()
{ publisher_.detach( *this ); }
private:
PubT* publisher_;
};

}//end namespace GenSubPriv

//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//
// Author : werasmus
// Date : Sep 22, 2007 7:41:39 PM
// Description:
// This class provides the ability to subscribe/unsubscribe in a RAII
fashion.
// Currently it caters for the publisher to outlive the subscriber,
hence the
// publisher is accepted as reference in the constructor.
// Note:
// Currently works for Publishers with interface <add/remove>, <attach/
detachand
// <subscribe/unsubscribe>.
// TODO:
// We could modify the publisher member iaw. a policy at later stage,
the default
// probably being weak pointer.
//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//
template <class PubT, class SubT>
class GenSubscriber
: public GenSubPriv::GenSubBase<PubT,
SubT,sizeof(GenSubPriv::get_method_literal<PubT>(0 ))>
{
protected:
typedef typename GenSubPriv::GenSubBase<PubT,
SubT,sizeof(GenSubPriv::get_method_literal<PubT>(0 ))Base;
//_____________ operations _____________//
GenSubscriber( PubT& publisher ): Base( publisher ){ }
};

Sep 24 '07 #2
On Sep 24, 12:17 am, Gianni Mariani <gi3nos...@mariani.wswrote:
Two issues here:
a) What is the accepted definition of "observer pattern".
While I can't point to anything specific, I do remember having
issues with inconsistency in the definition.
I don't know if there is anything really formal, but I'd tend to
go with the description in the GoF book, if only because it
seems to be the most widespread.
b) Generic observer design in C++. I have been pushing the Austria
"Twin" interface for a while and more recently the multi threaded
version of it "TwinMT" (see the 6129 alpha on sourceforge)
I'm not sure, but "Twin" sounds like you're managing a
one-to-one relationship. In my experience, it's almost always a
1->n relationship: each Observable will have many Observer.
I am trying to distill the "fundamental" hard problems in
software development, especially regarding C++ and I've seen
too many issues relating to the observer pattern I think it is
elevated to "fundamental".
By fundamental issues I mean, "avoiding deadlock conditions",
object lifetime management etc.
And persistency?

You're not the first. Back in the early 1990's, there was a lot
of discussion of "relationship management", with the hope of
finding some nice generic solution. As far as I know, there
were no real useful results, but the issue still seems to be
considered important---Java's hyping "container-managed
relations" in EJB.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 24 '07 #3
On 2007-09-24 00:17, Gianni Mariani wrote:
Two issues here:

a) What is the accepted definition of "observer pattern". While I can't
point to anything specific, I do remember having issues with
inconsistency in the definition.
I would assume that it is the one given in the GoF book, if you do not
have it the wikipedia article is more or less a copy from the book,
especially the "Participant classes" section.
b) Generic observer design in C++. I have been pushing the Austria
"Twin" interface for a while and more recently the multi threaded
version of it "TwinMT" (see the 6129 alpha on sourceforge)

I am trying to distill the "fundamental" hard problems in software
development, especially regarding C++ and I've seen too many issues
relating to the observer pattern I think it is elevated to "fundamental".
I do not see how there can any issues with the observer pattern, it is
very simple, however I perhaps not very useful either. I prefer a more
advanced version (I am sure this is some pattern but I do not know its
name) where the observing class is not only informed that something has
happened, but also what. So instead of just having a notify() function
the observing class has a onFoo(Bar& sender, FooArgs arguments) function
that tells the observing class what happened (the arguments) and to whom
(the sender). Anyone know the name of this pattern?

--
Erik Wikström
Sep 24 '07 #4

Erik Wikström wrote:

not see how there can any issues with the observer pattern, it is
very simple, however I perhaps not very useful either. I prefer a more
advanced version (I am sure this is some pattern but I do not know its
name) where the observing class is not only informed that something has
happened, but also what. So instead of just having a notify() function
the observing class has a onFoo(Bar& sender, FooArgs arguments) function
that tells the observing class what happened (the arguments) and to whom
(the sender). Anyone know the name of this pattern?
Aspect observer, perhaps? Notify( aspect) or Notify( state ). But
our observers only tend to observer a very concise aspect. One
could register for notification wrt. a particular concern or aspect.

Register: Observer. // where the observer has interface GetAspect.

Sep 24 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Allan Ebdrup | last post: by
28 posts views Thread by fred.haab | last post: by
94 posts views Thread by Samuel R. Neff | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.