Observer pattern in Rust - driven by intrinsic motivation...

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.

Class Diagram

Sequence Diagram

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):

The lifetime 'a ties the lifetimes of the observers

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.

It’s part of Rust's strict ownership and borrowing rules, ensuring safe and concurrent access to data.

You must declare the instance as mutable (mut) to call such a method