I'm trying to create a model with observer design pattern. I'm wondering that my subject can have only one observer. I usually see one subject and many observers in examples.
Related
I am learning the basics of software engineering independently.
And there's something I did not understand about the observer design template.
I have this diagram, in this diagram I marked what each part says, whether it is an observer, subject, concreteObserver or adapter.
From this chart I did not understand if it is a model of push or pull.
In my opinion it's a pull, but I'm not sure.
I think it's Pull, because we inform our Observers that there was a change, and the Observers go and check what the change was and interrogate the subject's state.
I would be happy if you could help me.
Clearly the ColourHandler is a Subject and the ColourSelectors are its Observers. Colour itself is a simple data structure. I have no idea why it would have a set_colour() method. An enum would be sufficient. Adapter is a separate design pattern, unrelated to Observer.
No implementation of the update() method is shown; however, we can see it takes no arguments. That is a strong indication of a pull model: the ColourSelectors must query the ColourHandler to determine the new Colour. Another indication is the circular dependency between Subject and Observer. In a push model, the Observer needn't be coupled to the Subject.
Also see the GoF description of push vs pull.
I'm studying the observer, a kind of design pattern.
The observable object contains a list of observers. A list can accept redundant an observer instance. So we can limit this redundancy using a hash set instead of a list.
My question is, if we allow redundant registration of the same observer instance, is there any example that the observer is registered more than one time? Why the same observer is registered to the same observable multiple times?
One observable may produce several different types of event notifications. One observer may be interested in registering for a number of these notifications. Obviously you could design this scenario in different ways; but one way is to maintain all registrations in a single list.
The GoF does mention on page 296,
It's up to the observer to handle or ignore a notification.
This implies an observer needs to be aware of any potential for redundancy and react appropriately.
Is it a good OO practice to implement Observer and Observable interface to the same class in cases like given below?
"News server application that notified if there are new news items. Then the subscribers of news categories get notified via the server when that happens"
It sounds like you are implementing the Composite pattern. You have a Composite Observer that receives events and then emits them to its children. Combining the Observer and Composite patterns is perfectly acceptable.
I am new to design patterns , I am learning Observer pattern for that I went to many sites ,where I found the below UML diagram
So my question is on the UML or class design.If the purpose of the observer pattern is to notify the observers about the change in state of subject/object, Why the subject needs to be abstract can’t it be a ConcreteSubject directly as shown below:
What are the disadvantages or violations if we create a Subject as ConcreteSubject.
I understand that the purpose of defining the abstract subject class is to provide a base implementation of the properties and methods needed for the Observers to subscribe and receive notifications.
A more generic alternative would be to provide an interface. Or perhaps the abstract class is in fact implementing a more generic interface that only defines the methods that have to be implemented.
In other words the advantage of providing an interface is that you don't need to know the class that implements it.
The advantage of using an abstract class is that you have a base implementation of the methods needed to add or remove observers and to send them notifications. And you take advantage of this by deriving the class.
Making Concrete Observer dependent upon Concrete subject will solve one problem [Type casting in update method as update(ConcreteSubject cs)] but at the cost of generic nature of Pattern.
Concrete Subject and Abstract Subject (Observable) have clear demarcation of responsibilities namely - Implement Business logic and be an Observable across application and take care of Observers.
In case we avoid using Subject, every business class requiring Observers (May be added down the line) will have to repeat the code of Subject. (Extending one Concrete Subject from Another Concrete Subject is OO violation).
Best way will be to use Abstract Subject and keep extensions and code reuse open.
Observer pattern-
Assumption:
Out of the 10 items, the observer only wants to be subscribed to 3.
Subject calls a function of the observer to let him know that there
are some updates.
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?
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).
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).
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.