Work is worship...
The observer design pattern is a very popular design pattern in the Object Oriented world. I must admit, I first saw the usefulness of this design pattern while studying the document view architecture of the MFC source code.
Later on, I used this pattern in many places.
There is a lot of similarity between the Observer Pattern, the Callback mechanism, and the Event Handler pattern in Java. Usually, the callback method is used when there is only one observer who awaits the signal from the subject.
So, let me put it in this fashion.
Suppose, there is a central document that is viewed by a few applications - someone is viewing it in a spreadsheet, someone as a Pie chart, and so on.
Now if the data in the document is updated, all the viewers must be updated and they should synchronise their views with the latest data set. So basically all the viewers were observing the central data. The moment it changes, all the observers get their respective views updated.
The class diagram and the sequence diagram of the observer pattern will be as follows.
Here goes an example of Observer Pattern written in Rust.
trait Observer {
fn update(&self,data:&str);
}
struct Subject<'a> {
observers: Vec<&'a dyn Observer>,
state: String,
}
impl<'a> Subject<'a> {
fn new(state: String) -> Self {
Self {
observers: Vec::new(),
state: state,
}
}
fn attach(&mut self, observer: &'a dyn Observer) {
self.observers.push(observer);
}
fn detach(&mut self, observer: &dyn Observer) {
self.observers.retain(|o| !std::ptr::eq(*o, observer));
}
fn notify(&self) {
for o in &self.observers {
o.update(&self.state);
}
}
fn set_state(&mut self, state: String) {
self.state = state;
self.notify();
}
}
struct ConcreteObserver {
name: String,
}
impl Observer for ConcreteObserver {
fn update(&self,data:&str) {
println!("{} received data: {}",self.name,data);
}
}
fn main() {
let mut subject = Subject::new("initial data".to_string());
let observer1=ConcreteObserver {
name: "Observer 1".to_string(),
};
let observer2=ConcreteObserver {
name: "Observer 2".to_string(),
};
subject.attach(&observer1);
subject.attach(&observer2);
subject.set_state("updated_data".to_string());
subject.detach(&observer2);
subject.set_state("Again updated data".to_string());
subject.detach(&observer1);
}
Explanation of Key Concepts:
Lifetimes ('a):
to the lifetime of the Subject. This ensures that all observer
references in the vector remain valid as long as the Subject
exists.
Trait Objects (dyn Observer):
The dyn Observer in the Vec<&'a dyn Observer> denotes a trait
object. A trait object allows different types that implement
the Observer trait to be stored in the same collection (Vec).
This enables polymorphism, where the exact type of the observer
is determined at runtime.
Important Considerations
Lifetime Management:Ensure that the lifetimes of all observers are correctly managed
to avoid dangling references.
Trait Object Overhead:
Using trait objects (dyn Trait) introduces some runtime overhead
due to dynamic dispatch.
&mut self:
&mut self in a method signature allows the method to modify the state of the object it's called on.mut) to call such a method
