P. 1
Wiley.pattern.oriented.software.architecture.volume.4.May.2007

Wiley.pattern.oriented.software.architecture.volume.4.May.2007

|Views: 170|Likes:
Published by Arun Nair

More info:

Published by: Arun Nair on Jun 09, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/24/2015

pdf

text

original

In a LAYERS (185), MODEL-VIEW-CONTROLLER (188), PRESENTATION-
ABSTRACTION-CONTROL (191), SHARED REPOSITORY (202), ITERATOR (298),
HALF-OBJECT PLUS PROTOCOL (324), REPLICATED COMPONENT GROUP (326),
INTERCEPTOR (444), MEDIATOR (410), COMPONENT CONFIGURATOR (490), or
DATABASE ACCESS LAYER (538) arrangement . . .

. . . we must provide a means to keep the state of a set of cooperating
component objects consistent with each other.

Consumer objects sometimes depend on the state of, or data
maintained by, another provider object. If the state of the
provider object changes without notice, however, the state of
the dependent consumer objects can become inconsistent.

Common solutions to this problem are to hard-code connections
from the provider object to all its dependent consumer objects, or to
have the consumers poll the provider. These approaches are often
impractical, however, since a consumer may not be dependent on the
provider indefinitely, and new instances and types of consumers may
emerge over an application’s lifetime. Moreover, polling may either
consume excessive resources, or may not detect changes quickly
enough.

Therefore:

Define a change-propagation mechanism in which the provider—
known as the ‘subject’—notifies registered consumers—known
as the ‘observers’—whenever its state changes, so that the
notified observers can perform whatever actions they deem nec-
essary.

Observer

void notify ()
begin

// Notify all registered observes.

for all registered observers do
observer.update ();

rof

end

register with subject

change
state

start change
propagation

notify
observers

pull changed data

update

service

register

unregister

get_data

notify

set_data

update

service

1

2

3

4

5

Subject

406

Object Interaction

Observers must define a specific update interface that is notified by
the subject when its state changes. This interface is the primary cou-
pling between the subject and its observers. Observers can register
and unregister from the subject dynamically. When the subject noti-
fies its observes, it can either push the state to the observers along
with the state change notification, or the observers can selectively
pull the changed state from the subject at their discretional after
being notified.

In an OBSERVER arrangement, the dynamic registration of observers
with the change notification mechanism avoids hard-coding depen-
dencies between the subject and its observers: they can join and leave
at any time, and new types of observer that implement the update
interface can be integrated without changing the subject. The active
propagation of changes by the subject avoids polling and ensures
that observers can update their own state immediately in response to
state changes in the subject.

In a typical OBSERVER implementation, an EXPLICIT INTERFACE (281)
defines the update interface to be supported by observers. Concrete
observers implement this interface to define their specific update pol-
icy in response to notifications by the subject. The subject, in turn,
offers an interface for observers to register with and unregister from,
the change notification mechanism. Internally, the subject manages
its registered observers within a collection, such as a hashed set or a
linked list.

The OBSERVER change notification protocol can be implemented in
several ways. The simplest option is based on a generic pull model:
when the subject changes its state, it notifies all registered observers
that a state change has occurred. The notified observers can then
call back to the subject to retrieve more detailed information. This
protocol works well if all observers depend on all state that the
subject maintains. If different observers depend on different state
in the subject, however, the generic pull model causes unnecessary
updates, because the subject notifies all observers, not just those
who depend on the state that has changed.

Observer **

407

If subject and observer execute in different address spaces, the ‘chat-
tiness’ of thegeneric pull model can consume networkandprocessing
resources unnecessarily. In this case, a categorized pull model can
be used to allow observers to register with one or more different types
of state changes in the subject. These observers are only notified if
particular types of state change. The pull model therefore may still
be inappropriate for remote communication, due to the overhead of
having all the observers call back to the subject to obtain the state.

To minimize interactions between subject and observer, there are
two other options for implementing the change notification protocol,
both based on a push model rather than a pull model. In the generic
push model, the subject pushes a snapshot of its attribute state
to the observers along with each notification, using a DATA TRANSFER
OBJECT (418) to communicate the attributes. This model is useful if all
observers depend on the entire state being pushed, or when the cost
of communicating all the state is less than the cost of having each
observer call back for specific state.

A variant of the generic push model is the categorized push model,
which is based on some type of filtering [GoF95]. If a change in the
subject affects only a small portion of its entire state, this portion
is pushed only to those observers who are interested in it. If these
observers can also decide to not update themselves each time they
are notified, however, even the categorized push model produces
overhead, because many ‘expensive’ data pushes are unnecessary.

Choosing the best option for the change notification mechanisms
in a specific OBSERVER configuration is also influenced by coupling
issues. Pull models generally result in a looser coupling between the
subject and the observers than push models, and the generic pull
model decouples subject and observers better than the categorized
pull model.

408

Object Interaction

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->