Observer Design Pattern

[Krivenok Dmitry]

Hello All!

I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer. Also describes implementation
via ChangeManager (Mediator + Singleton)
2) Pattern hatching by John Vlissides
Describes Observer's implementation via Visitor Design Pattern.
3) Design Patterns Explained by Alan Shalloway and James Trott
Describes Observer's implementation via Adaptor Design Pattern.
4) CUJ's article : "Prying eyes : A Policy-Based Observer I,II" by
Andrei Alexandrescu
Very interesting articles, which describes attempt to implement
a policy-based Observer and several serious problems:
a) Mutual recursion (potential infinite loops, etc...)
b) Active observers problem (iteration problem)
c) Notification order problem
d) GetState()'s return value problem

I am trying to combine best aspects of each approach.

Consider the following pseudo-code example:

class Subject
{
public:
virtual void Attach(Observer *) = 0;
virtual void Detach(Observer *) = 0;
virtual void Notify() = 0;

virtual @@@ GetState() = 0; // !!! What type should be
returned???
};

class Observer
{
public:
virtual void Update(Subject* ) = 0;
};

class MySubject : public Subject
{
public:
void Attach(Observer *)
{
/// Add pair
}
void Detach(Observer *)
{
/// Delete pair
}
void Notify()
{
/// Call observer->Update(this) for each observer in mapping
}

@@@ GetState()
{
/// Return MySubject-specific data. BUT HOW???
}
private:
// Subject-Observer mapping
// MySubject-specific data
};

class YourSubject : public Subject
{
public:
// Along similar lines
private:
// Subject-Observer mapping
// YourSubject-specific data
};

class MyObserver : public Observer /// This class represents MySubject
and YourSubject
{
public:
void Update(Subject* s)
{
/// Only Subject's interface is available here (not MySubject
or YourSubject)
/// I know one bad solution - type switch via dynamic_cast.
if TypeOf(s) == MySubject
{
/// Update MySubject-specific part of representation
}
else if TypeOf(s) == YourSubject
{
/// Update YourSubject-specific part of representation
}
}
private:
/// MyObserver-specific data (e.g. GUI widgets for subjects
representation)
};
The problem lies in poor Subject's interface.
Subject doesn't know anything about MySubject's private data.

I don't understand why GoF includes GetState method in Subject's
interface.
Type of GetState()'s return value depends up concrete subclass of
Subject, i.e.
class ConcreteSubject : Subject
{
public:
ReturnValue<Con creteSubject> GetState();
...
};

Main question:
How to avoid type switching in ConcreteObserve r::Update(Subje ct* s)?

Thanks!

P.S.
Sorry for my english :)

[boaz_sade]

Krivenok Dmitry wrote:

Hello All!

I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer. Also describes implementation
via ChangeManager (Mediator + Singleton)
2) Pattern hatching by John Vlissides
Describes Observer's implementation via Visitor Design Pattern.
3) Design Patterns Explained by Alan Shalloway and James Trott
Describes Observer's implementation via Adaptor Design Pattern.
4) CUJ's article : "Prying eyes : A Policy-Based Observer I,II" by
Andrei Alexandrescu
Very interesting articles, which describes attempt to implement
a policy-based Observer and several serious problems:
a) Mutual recursion (potential infinite loops, etc...)
b) Active observers problem (iteration problem)
c) Notification order problem
d) GetState()'s return value problem

I am trying to combine best aspects of each approach.

Consider the following pseudo-code example:

class Subject
{
public:
virtual void Attach(Observer *) = 0;
virtual void Detach(Observer *) = 0;
virtual void Notify() = 0;

virtual @@@ GetState() = 0; // !!! What type should be
returned???
};

class Observer
{
public:
virtual void Update(Subject* ) = 0;
};

class MySubject : public Subject
{
public:
void Attach(Observer *)
{
/// Add pair
}
void Detach(Observer *)
{
/// Delete pair
}
void Notify()
{
/// Call observer->Update(this) for each observer in mapping
}

@@@ GetState()
{
/// Return MySubject-specific data. BUT HOW???
}
private:
// Subject-Observer mapping
// MySubject-specific data
};

class YourSubject : public Subject
{
public:
// Along similar lines
private:
// Subject-Observer mapping
// YourSubject-specific data
};

class MyObserver : public Observer /// This class represents MySubject
and YourSubject
{
public:
void Update(Subject* s)
{
/// Only Subject's interface is available here (not MySubject
or YourSubject)
/// I know one bad solution - type switch via dynamic_cast.
if TypeOf(s) == MySubject
{
/// Update MySubject-specific part of representation
}
else if TypeOf(s) == YourSubject
{
/// Update YourSubject-specific part of representation
}
}
private:
/// MyObserver-specific data (e.g. GUI widgets for subjects
representation)
};
The problem lies in poor Subject's interface.
Subject doesn't know anything about MySubject's private data.

I don't understand why GoF includes GetState method in Subject's
interface.
Type of GetState()'s return value depends up concrete subclass of
Subject, i.e.
class ConcreteSubject : Subject
{
public:
ReturnValue<Con creteSubject> GetState();
...
};

Main question:
How to avoid type switching in ConcreteObserve r::Update(Subje ct* s)?

Thanks!

P.S.
Sorry for my english :)

Maybe you should try to avoid reading to many design books. You can
start by forgeting everything you read in the GoF book (unless you
interested in making your life as programmer harder and your code more
complicated)

[Jeff Flinn]

bo*******@yahoo .com wrote:

Krivenok Dmitry wrote:

Hello All!

I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer. Also describes implementation
via ChangeManager (Mediator + Singleton)
2) Pattern hatching by John Vlissides
Describes Observer's implementation via Visitor Design Pattern.
3) Design Patterns Explained by Alan Shalloway and James Trott
Describes Observer's implementation via Adaptor Design Pattern.
4) CUJ's article : "Prying eyes : A Policy-Based Observer I,II" by
Andrei Alexandrescu
Very interesting articles, which describes attempt to implement
a policy-based Observer and several serious problems:
a) Mutual recursion (potential infinite loops, etc...)
b) Active observers problem (iteration problem)
c) Notification order problem
d) GetState()'s return value problem

I am trying to combine best aspects of each approach.

Consider the following pseudo-code example:
[snipped code]
Main question:
How to avoid type switching in ConcreteObserve r::Update(Subje ct* s)?

Maybe you should try to avoid reading to many design books. You can
start by forgeting everything you read in the GoF book (unless you
interested in making your life as programmer harder and your code
more complicated)

Maybe you could back that up with some specific instances?

Jeff Flinn

[Daniel T.]

Krivenok Dmitry wrote:

Hello All!

I am trying to implement my own Design Patterns Library.
You can't do that in general. Design Patterns are at a level higher
than simple code reuse. That said...

The classic "pull model" can be implemented like this:

class Observer
{
public:
virtual ~Observer() { }
virtual void update() = 0;
};

class Subject
{
std::set< Observer* > observers;
public:
void attach( Observer* o ) {
observers.inser t( o );
}

void detach( Observer* o ) {
observers.erase ( o );
}

void notify() {
for_each( observers.begin (), observers.end() ,
mem_fun( &Observer::upda te ) );
}
};
class MySubject : public Subject
{
int state;
public:
int getState() const { return state; }
void setState( int value ) { state = value; notify(); }
};

class MyObserver : public Observer
{
MyObserver( const MyObserver& );
MyObserver& operator=( const MyObserver& );

MySubject* subject;

public:
MyObserver( MySubject* subject_ ): subject( subject_ ) {
subject->attach( this );
}

~MyObserver() {
subject->detach( this );
}

void update() {
// do something with subject->getState();
}
};

However, I have found the "push model" to be much more useful:

template < typename Observer >
class Subject {
std::set< Observer* > observers;

public:
void attach( Observer* o ) {
observers.inser t( o );
}

void detach( Observer* o ) {
observers.erase ( o );
}

template < typename ConcreteSubject >
void notify( const ConcreteSubject * cs, void (Observer::*fn) ( const
ConcreteSubject * ) ) {
std::set< Observer* >::iterator it = observers.begin ();
while ( it != observers.end() ) {
Observer* ob( *it++ );
(ob->*fn)( cs );
}
}
};
I don't understand why GoF includes GetState method in Subject's
interface.
They did that because they were looking at SmallTalk examples which
didn't translate well to C++
Main question:
How to avoid type switching in ConcreteObserve r::Update(Subje ct* s)?

As I showed above.

[Joe Van Dyk]

Krivenok Dmitry wrote:

Hello All!

I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer. Also describes implementation
via ChangeManager (Mediator + Singleton)
2) Pattern hatching by John Vlissides
Describes Observer's implementation via Visitor Design Pattern.
3) Design Patterns Explained by Alan Shalloway and James Trott
Describes Observer's implementation via Adaptor Design Pattern.
4) CUJ's article : "Prying eyes : A Policy-Based Observer I,II" by
Andrei Alexandrescu
Very interesting articles, which describes attempt to implement
a policy-based Observer and several serious problems:
a) Mutual recursion (potential infinite loops, etc...)
b) Active observers problem (iteration problem)
c) Notification order problem
d) GetState()'s return value problem

I am trying to combine best aspects of each approach.

You might want to try out "Head First Design Patterns". Pretty decent book.

Joe

[Joe Van Dyk]

Daniel T. wrote:

Krivenok Dmitry wrote:

Hello All!

I am trying to implement my own Design Patterns Library.

You can't do that in general. Design Patterns are at a level higher
than simple code reuse. That said...

I'm not sure what you mean by this. Can you elaborate?

Joe

[Jeremy Jurksztowicz]

> > You can't do that in general. Design Patterns are at a level higher

than simple code reuse. That said...

I'm not sure what you mean by this. Can you elaborate?

I think what he means is that the patterns in the GoF book are not code
patterns per se, in that they were not meant to be reused as a unit of
code, but rather DESIGN patterns, which you could use to solve common
design problems. In other words, you may have to write and modify the
pattern code from scratch to solve the coding problem, but the design
problem is addressed by the design pattern you select.

This is somewhat subtle, especially in C++ where generic programming
has such a foothold. Often times we want to make an ideal instance of a
pattern in highly reusable C++ code. I think this is a great idea, even
if only for practices sake.

[boaz_sade]

Jeff Flinn wrote:

bo*******@yahoo .com wrote:

Krivenok Dmitry wrote:

Hello All!

I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer. Also describes implementation
via ChangeManager (Mediator + Singleton)
2) Pattern hatching by John Vlissides
Describes Observer's implementation via Visitor Design Pattern.
3) Design Patterns Explained by Alan Shalloway and James Trott
Describes Observer's implementation via Adaptor Design Pattern.
4) CUJ's article : "Prying eyes : A Policy-Based Observer I,II" by
Andrei Alexandrescu
Very interesting articles, which describes attempt to implement
a policy-based Observer and several serious problems:
a) Mutual recursion (potential infinite loops, etc...)
b) Active observers problem (iteration problem)
c) Notification order problem
d) GetState()'s return value problem

I am trying to combine best aspects of each approach.

Consider the following pseudo-code example:
[snipped code]
Main question:
How to avoid type switching in ConcreteObserve r::Update(Subje ct* s)?

Maybe you should try to avoid reading to many design books. You can
start by forgeting everything you read in the GoF book (unless you
interested in making your life as programmer harder and your code
more complicated)

Maybe you could back that up with some specific instances?

Jeff Flinn

To be more specific will take too mach of my time bust generaly I think
that in many of those advice books (not just in programming books) they
think that the have those silver bults that they discovor and now its
their job to convince you that once you will use them you can "kill"
all of your problems with them. Take for exaple the books about "how to
become rigch in X days" - do you really belive that by following their
advices you will become richer - if you do then by all means you can
coninue along this road. Presonlly I don't think (coming back to
programmning) that someone who don't know my system, the truble I have
implementing it and that I don't know too mach about him/her eigher can
give me solutions. If I need advice I will at least let my advicer see
my personl problem then I belive that he/she can truly help me. Anther
thing is - reading those books give you the impration that those people
never really wrote production code and their solutions are to academic

[Dave Steffen]

"Jeremy Jurksztowicz" <ju**********@g mail.com> writes:

You can't do that in general. Design Patterns are at a level higher
than simple code reuse. That said...
I'm not sure what you mean by this. Can you elaborate?

I think what he means is that the patterns in the GoF book are not code
patterns per se, in that they were not meant to be reused as a unit of
code, but rather DESIGN patterns, which you could use to solve common
design problems. In other words, you may have to write and modify the
pattern code from scratch to solve the coding problem, but the design
problem is addressed by the design pattern you select.

Precisely. I recomment that the OP head directly to "Modern C++
Design" by Alexandrescu. Most of that book is generic implementations
of design patterns.
This is somewhat subtle, especially in C++ where generic programming
has such a foothold. Often times we want to make an ideal instance
of a pattern in highly reusable C++ code. I think this is a great
idea, even if only for practices sake.

And extremely difficult, as anyone who has read Alexandrescu (or
looked at the various Boost libraries that do similar things) can
attest.

----------------------------------------------------------------------
Dave Steffen, Ph.D. Fools ignore complexity.
Software Engineer IV Pragmatists suffer it.
Numerica Corporation Some can avoid it.
ph [phone] x27 Geniuses remove it.
fax [phone] -- Alan Perlis
dgsteffen at numerica dot us

[Jeff Flinn]

bo*******@yahoo .com wrote:

Jeff Flinn wrote:

bo*******@yahoo .com wrote:

Krivenok Dmitry wrote:
Hello All!

I am trying to implement my own Design Patterns Library.
I have read the following documentation about Observer Pattern:
1) Design Patterns by GoF
Classic description of Observer. Also describes implementation
via ChangeManager (Mediator + Singleton)
2) Pattern hatching by John Vlissides
Describes Observer's implementation via Visitor Design Pattern.
3) Design Patterns Explained by Alan Shalloway and James Trott
Describes Observer's implementation via Adaptor Design Pattern.
4) CUJ's article : "Prying eyes : A Policy-Based Observer I,II" by
Andrei Alexandrescu
Very interesting articles, which describes attempt to implement
a policy-based Observer and several serious problems:
a) Mutual recursion (potential infinite loops, etc...)
b) Active observers problem (iteration problem)
c) Notification order problem
d) GetState()'s return value problem

I am trying to combine best aspects of each approach.

Consider the following pseudo-code example:

[snipped code]

Main question:
How to avoid type switching in ConcreteObserve r::Update(Subje ct*
s)?

Maybe you should try to avoid reading to many design books. You can
start by forgeting everything you read in the GoF book (unless you
interested in making your life as programmer harder and your code
more complicated)

Maybe you could back that up with some specific instances?

Jeff Flinn

To be more specific will take too mach of my time bust generaly I

[snipped baseless opinion]

How about focusing on just Design Patterns by GoF?

Jeff Flinn