Question observer design pattern .. more

Would it be safe to state that the observer design pattern supports
bidirectional commuication where the subject and observed are aware of
each other?

Alot of what I read promotes the 'one to many' aspect of the observer
design pattern, however it also (based on a handful of source I
peruse) supports bidirectional communication in my opinion. I've got
a server client relationship that I'm trying to put together in source
code. Messages between server/client are bi-directional and each
message is routed through a gateway. I dont think an observer pattern
is the right choice since servers and client shouldn't be aware of
each other. Thoughts?

forums_mp@hotmail.com wrote:

> Would it be safe to state that the observer design pattern supports
> bidirectional commuication where the subject and observed are aware
> of each other?

Well, it is safe to say that the Subject and Observer are aware of
each-other, but bidirectional communication is not required or implied.
A subject must send messages to its observer(s), but it need not be the
case that the observer(s) send messages to the subject.

IMHO, if the observer *does* send messages to the subject (as opposed to
simply requesting state information,) the system is completely muddled.

> I've got a server client relationship that I'm trying to put
> together in source code. Messages between server/client are
> bi-directional and each message is routed through a gateway. I
> dont think an observer pattern is the right choice since servers
> and client shouldn't be aware of each other.

Servers and Clients must be aware of each other if messages between them
are bi-directional.

"Daniel T." <daniel_t@earthlink.net> writes:
> forums_mp@hotmail.com wrote:
[ . . . ]
>> I've got a server client relationship that I'm trying to put
>> together in source code. Messages between server/client are
>> bi-directional and each message is routed through a gateway. I
>> dont think an observer pattern is the right choice since servers
>> and client shouldn't be aware of each other.
>
> Servers and Clients must be aware of each other if messages between
> them are bi-directional.

True, but that coupling can be reduced by having both Clients and
Servers viewing each other only through interfaces. It can also be
made dynamic and extensible by using a discovery protocol to connect
Clients to Servers at runtime rather than compiling in explicit class
references.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Patrick May <pjm@spe.com> wrote:
> "Daniel T." <daniel_t@earthlink.net> writes:
> > forums_mp@hotmail.com wrote:
> [ . . . ]
> > > I've got a server client relationship that I'm trying to put
> > > together in source code. Messages between server/client are
> > > bi-directional and each message is routed through a gateway. I
> > > dont think an observer pattern is the right choice since
> > > servers and client shouldn't be aware of each other.
> >
> > Servers and Clients must be aware of each other if messages
> > between them are bi-directional.
>
> True, but that coupling can be reduced by having both Clients and
> Servers viewing each other only through interfaces.

That's a given in OOD.

> It can also be made dynamic and extensible by using a discovery
> protocol to connect Clients to Servers at runtime rather than
> compiling in explicit class references.

That doesn't reduce the logical coupling, it may reduce *physical*
coupling (a nice optimization if physical design issues are causing a
problem,) but I wouldn't start out with such a design.

On Sep 7, 3:45*pm, forums...@hotmail.com wrote:
> Would it be safe to state that the observer design pattern supports
> bidirectional commuication where the subject and observed are aware of
> each other?

I looked high and low for a solution (thought well.. this is done all
the time so I searched the web for every combination of observer and
communication you could think of) to a similar problem weeks ago.
Based on your setup the approach I opted for :

Gateway was used as an interface - if you will.
Assuming multiple servers, servers were derived off a serverObserver
with each servers registering as observer with Gateway.
Gateway held a pointer to Client (in my case I only had one).

The trick then was to institute generic send and receive (also
handleCmd and handleStatus) methods that could be used by both Clients
and Servers. I think I've redesigned the class 4 times already since
I keep butchering this.

"Daniel T." <daniel_t@earthlink.net> writes:
> Patrick May <pjm@spe.com> wrote:
>> "Daniel T." <daniel_t@earthlink.net> writes:
>> > forums_mp@hotmail.com wrote:
>> [ . . . ]
>> > > I've got a server client relationship that I'm trying to put
>> > > together in source code. Messages between server/client are
>> > > bi-directional and each message is routed through a gateway. I
>> > > dont think an observer pattern is the right choice since
>> > > servers and client shouldn't be aware of each other.
>> >
>> > Servers and Clients must be aware of each other if messages
>> > between them are bi-directional.
>>
>> True, but that coupling can be reduced by having both Clients and
>> Servers viewing each other only through interfaces.
>
> That's a given in OOD.

That's a given in _good_ OOD, eventually. If there is only one
client type and one server type, an XP team wouldn't add interfaces
(YAGNI and DTSTTCPW). In any case, it's worth mentioning because
comp.object isn't just about good OOD. ;-)

>> It can also be made dynamic and extensible by using a discovery
>> protocol to connect Clients to Servers at runtime rather than
>> compiling in explicit class references.
>
> That doesn't reduce the logical coupling, it may reduce *physical*
> coupling (a nice optimization if physical design issues are causing
> a problem,) but I wouldn't start out with such a design.

I use Jini fairly often, so I get it for "free."

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

> That's a given in _good_ OOD, eventually. If there is only one
> client type and one server type, an XP team wouldn't add interfaces
> (YAGNI and DTSTTCPW).

Yet if XP works better with dynamic typing, then the point is moot. (-:

Responding to Forums_mp...

> Would it be safe to state that the observer design pattern supports
> bidirectional commuication where the subject and observed are aware of
> each other?

Yes and No. B-) The way the GoF describe the pattern such communication
is certainly *possible* because they stipulate that the Observers are
known to the Subject and each ConcreteObserver has a reference to the
ConcreteSubject.

However that degree of coupling is neither necessary nor desirable in
most practical situations where Observer is applicable. In particular,
there is no reason for either ConcreteObserver or ConcreteSubject to
know that the other exists, much less have an explicit association at
the subclass level. Thus one of the more common variants of Observer is
a registration process such as:

[Subject]
| *
|
| R1
|
| notifies
| 1
[Registrar]
| 1
| registers with
|
| R2
|
| forwards messages to
| *[Listener]

IOW, the Registrar is the Observer from the pattern but it is limited to
providing redirection via a mapping between Subject messages and the
real Listeners who actually care about those messages. The Listeners are
then fully decoupled from Subject. Note that in this scheme the R2
registration can be instantiated by any object that understands the
context, not necessarily the Listener (though that is most common). Also
note that the registration can be based on the message ID rather than
who actually generates the message. (Obviously the Subject needs to
"register" its messages with the Registrar as well.)

The fundamental thing the pattern provides is notification. The Subject
does something to change the state of the solution and it generates a
message to announce that state change. There may be one to more other
entities in the solution that care about that state change. The Observer
pattern simply provides a mechanism for addressing that message when the
entities interested in the state change can change dynamically during
the solution execution. Note that:

(A) when Subject generates the announcement message it doesn't care who
-- if anyone -- will respond; it just needs to understand what it did.

(B) the state change does not need need to be recorded as a state
variable (object knowledge attribute) value; it could just be the
condition that a subject behavior was executed. (This is actually quite
common in asynchronous, event-based systems with handshaking protocols.)

(C) there is no need for the entity that cares about the state change to
know who was responsible for changing the state; all it needs to know is
that the state change occurred to do its thing.

So one really doesn't need or want two-way communication in the pattern.
Introducing it inevitably implies a more carnal level of collaboration
between the entities. That intimacy might be necessary in a specific
problem context, but good OOA/D practice says that one should look for
ways to avoid it whenever it is not critical.

Finally, if Subject has state information that the Listener needs to
execute its response to the state change, the Listener should navigate
back to the state data via an existing association path that has nothing
to do with the state change. That is, the state change triggers a
behavior responsibility in Listener via the notification process but
once that behavior is triggered it accesses the data needs in a
conventional manner. So the GetState() activity in the GoF pattern is
really peripheral to the pattern because it only depends on what the
Listener behavior needs, not the collaboration that triggered its execution.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Patrick May <pjm@spe.com> wrote:
> "Daniel T." <daniel_t@earthlink.net> writes:
> > Patrick May <pjm@spe.com> wrote:
> > > "Daniel T." <daniel_t@earthlink.net> writes:
> > > > forums_mp@hotmail.com wrote:
> > > [ . . . ]
> > > > > I've got a server client relationship that I'm trying to
> > > > > put together in source code. Messages between
> > > > > server/client are bi-directional and each message is routed
> > > > > through a gateway. I dont think an observer pattern is the
> > > > > right choice since servers and client shouldn't be aware of
> > > > > each other.
> > > >
> > > > Servers and Clients must be aware of each other if messages
> > > > between them are bi-directional.
> > >
> > > True, but that coupling can be reduced by having both Clients
> > > and Servers viewing each other only through interfaces.
> >
> > That's a given in OOD.
>
> That's a given in _good_ OOD, eventually. If there is only one
> client type and one server type, an XP team wouldn't add interfaces
> (YAGNI and DTSTTCPW). In any case, it's worth mentioning because
> comp.object isn't just about good OOD. ;-)

Let's not start that war! :-) I would expect in a "good" XP team, there
is never simply one client and one server, there are always at least the
production client/server and the test client/server.

> > > It can also be made dynamic and extensible by using a discovery
> > > protocol to connect Clients to Servers at runtime rather than
> > > compiling in explicit class references.
> >
> > That doesn't reduce the logical coupling, it may reduce
> > *physical* coupling (a nice optimization if physical design
> > issues are causing a problem,) but I wouldn't start out with such
> > a design.
>
> I use Jini fairly often, so I get it for "free."

Nothing is free, but then I expect you knew that and that's why you put
it in scare quotes.

>
> However that degree of coupling is neither necessary nor desirable in
> most practical situations where Observer is applicable. In particular,
> there is no reason for either ConcreteObserver or ConcreteSubject to
> know that the other exists, much less have an explicit association at
> the subclass level. Thus one of the more common variants of Observer is
> a registration process such as:
>
> [Subject]
> * * *| *
> * * *|
> * * *| R1
> * * *|
> * * *| notifies
> * * *| 1
> [Registrar]
> * * *| 1
> * * *| registers with
> * * *|
> * * *| R2
> * * *|
> * * *| forwards messages to
> * * *| *
>[Listener]
>
> IOW, the Registrar is the Observer from the pattern but it is limited to
> providing redirection via a mapping between Subject messages and the
> real Listeners who actually care about those messages. The Listeners are
> then fully decoupled from Subject. Note that in this scheme the R2
> registration can be instantiated by any object that understands the
> context, not necessarily the Listener (though that is most common). Also
> note that the registration can be based on the message ID rather than
> who actually generates the message. (Obviously the Subject needs to
> "register" its messages with the Registrar as well.)
>
Are you registering R1, R2s or are you registering a listener? I'm
trying to put together source (only way I sometimes envision these
patterns) code based on your response which I think would suite nicely
- in my case.