CODEWITHSUNDEEP
oopdesign-patternsobserver-pattern
Aquarius_Girl
Aquarius_Girl

Reputation: 22936

Observer pattern-The subject keeps track of the items to be observed by the observer

Observer pattern-
Assumption:

Now, is it subject's responsibility to send the updates pertaining to only 3 items to the observer?
OR
Subject can simply tell the observer that there are updates - go fetch whichever you want out of 10?

Which is the correct way out? Does it matter?

Upvotes: 0

Views: 549

Answers (3)

Kleenestar
Kleenestar

Reputation: 799

It's the Subject to keep a list of Observers who are interested in this subject, and notify these Observers by calling its update method. Observer does NOT keep a list of subjects which it is interested in.

Based on this, when a subject is updated, the subject will call the update(..) method or something similar of those Observers in its list. subject can either encapsulate the changes in an object as a parameter of the method, Or pass the this object of this subject (observers get the interested data by calling subject's methods themselves).

Upvotes: 1

Don Roby
Don Roby

Reputation: 41137

Now, is it subject's responsibility to send the updates pertaining to only 3 items to the observer?

OR

Subject can simply tell the observer that there are updates - go fetch whichever you want out of 10?

Which is the correct way out? Does it matter?

There is no absolute right answer here.

These are implementation choices, and in fact are mentioned in the implementation section for Observer in Design Patterns:

_6. Avoiding observer-specific update protocols: the push and pull models. Implementations of the Observer pattern often have the subject broadcast additional information about the change. The subject passes this information as an argument to Update. The amount of information may vary widely.

At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.

The pull model emphasizes the subject's ignorance of its observers, whereas the push model assumes subjects know something about their observers' needs. The push model might make observers less reusable, because Subject classes make assumptions about Observer classes that might not always be true. On the other hand, the pull model may be inefficient, because Observer classes must ascertain what changed without help from the Subject.

_7. Specifying modifications of interest explicitly. You can improve update efficiency by extending the subject's registration interface to allow registering observers only for specific events of interest. When such an event occurs, the subject informs only those observers that have registered interest in that event. One way to support this uses the notion of aspects for Subject objects. To register interest in particular events, observers are attached to their subjects using

void Subject::Attach(Observer*, Aspect& interest);

where interest specifies the event of interest. At notification time, the subject supplies the changed aspect to its observers as a parameter to the Update operation. For example:

void Observer::Update(Subject*, Aspect& interest);

If it makes more sense in your situation to use the push model, so the subject has a bit more knowledge of the observers' needs, and to use an aspect model so that the observers can register interest in particular portions of the subject's data, go for it!

I usually prefer to use the pull model and accept that the observer has a bit of detailed knowledge of the subject (it's simpler to implement), but what you're proposing is probably fine in your situation.

Upvotes: 0

Sergey Berezovskiy
Sergey Berezovskiy

Reputation: 236268

I'd rather go with specific notifications about different events. Usually with push model. Like Hey, I just earned some money. Here is actual amount I have earned. Instead of Hey, something happened to me.. Latter moves all logic to clients (observers). Clients should verify what has changed and this verification logic will be duplicated if you have several clients. Actually if you don't have other observers, you don't need this pattern :)

Also specific notifications allow to subscribe only to events which clients are interested in. So, observers will not be bothered when something other happened (i.e. when subject watched a movie).

Upvotes: 0

Related Questions