The essence of the famous observer/observable pattern is that you have an observable object that produces events of various kinds, and one or more observer objects that register themselves as interested in notification when these events occur.
Of course, we represent each kind of event as a type, usually a class, though nothing prevents us from using an interface type as an event type.
For example:
class Started() {}
class Stopped() {}
An event type may even be generic:
class Created<out Entity>
(shared Entity entity)
given Entity satisfies Object {
string => "Created[``entity``]";
}
class Updated<out Entity>
(shared Entity entity)
given Entity satisfies Object {
string => "Updated[``entity``]";
}
class Deleted<out Entity>
(shared Entity entity)
given Entity satisfies Object {
string => "Deleted[``entity``]";
}
Of course, we have powerful mechanisms for abstracting over event types, for example:
alias Lifecycle<Entity>
given Entity satisfies Object
=> Created<Entity> |
Updated<Entity> |
Deleted<Entity>;
An observer, usually, is in essence nothing more than a function that accepts a certain type of event as a parameter.
For example, this anonymous function observes the creation of Users:
(Created<User> userCreated)
=> print("new user created: " + userCreated.entity.name)
This anonymous function observes lifecycle events of any kind of entity:
(Lifecycle<Object> event)
=> print("something happened: " + event)
Union and intersection types give us a nice way to express conjunction and disjunction of event types:
void (Created<User>|Deleted<User> userEvent) {
switch (userEvent)
case (is Created<User>) {
print("user created: " + userEvent.entity.name);
}
case (is Deleted<User>) {
print("user deleted: " + userEvent.entity.name);
}
}
Now here’s where we can do something really cute. Typically, in other languages, the observable object provides various observer registration operations, one for each kind of event the object produces. We’re going to define a generic class Observable that works for any event type, and uses reified generics to map events to observer functions.
shared class Observable<in Event>()
given Event satisfies Object {
...
}
The type parameter Event captures the various kinds of events that this object produces, for example, an Observable<Lifecycle<User>> produces events of type Created<User>, Updated<User>, and Deleted<User>.
We need a list to store observers in:
value listeners = ArrayList<Anything(Nothing)>();
Here, Anything(Nothing) is the supertype of any function with one parameter.
The addObserver() method registers an observer function with the Observable:
shared void addObserver<ObservedEvent>
(void handle(ObservedEvent event))
given ObservedEvent satisfies Event
=> listeners.add(handle);
This method only accepts observer functions for some subset of the events actually produced by the Observable. This constraint is enforced by the upper bound given ObservedEvent satisfies Event.
The raise() method produces an event:
shared void raise<RaisedEvent>(RaisedEvent event)
given RaisedEvent satisfies Event
=> listeners.narrow<Anything(RaisedEvent)>()
.each((handle) => handle(event));
Again, the upper bound enforces that this method only accepts event objects that are of an event type produced by the Observable.
This method uses the new narrow() method of Iterable in Ceylon 1.2 to filter out observer functions that don’t accept the raised event type. This method is implemented using reified generics. Here’s its definition in Iterable<Element>:
shared default {Element&Type*} narrow<Type>()
=> { for (elem in this) if (is Type elem) elem };
That is, if we have a stream of Elements, and we call narrow<Type>(), explicitly passing an arbitrary type Type, then we get back a stream of all elements of the original stream which are instances of Type. This is, naturally, a stream of Element&Types.
Now, finally, if we define an instance of Observable:
object userPersistence
extends Observable<Lifecycle<User>>() {
shared void create(User user) {
...
//raise an event
raise(Created(user));
}
...
}
Then we can register observers for this object like this:
//observe User creation events
userPersistence.addObserver(
(Created<User> userCreated)
=> print("new user created: " + userCreated.entity.name));
//observe User creation and deletion events
userPersistence.addObserver(
void (Created<User>|Deleted<User> userEvent) {
switch (userEvent)
case (is Created<User>) {
print("user created: " + userEvent.entity.name);
}
case (is Deleted<User>) {
print("user deleted: " + userEvent.entity.name);
}
});
Notice how with union and intersection types, subtyping, and variance, we find ourselves with a powerful expression language for specifying exactly which kinds of events we’re interested in, in a typesafe way, right in the parameter list of the observer function.
For the record, here’s the complete code of Observable:
shared class Observable<in Event>()
given Event satisfies Object {
value listeners = ArrayList<Anything(Nothing)>();
shared void addObserver<ObservedEvent>
(void handle(ObservedEvent event))
given ObservedEvent satisfies Event
=> listeners.add(handle);
shared void raise<RaisedEvent>(RaisedEvent event)
given RaisedEvent satisfies Event
=> listeners.narrow<Anything(RaisedEvent)>()
.each((handle) => handle(event));
}
Finally, a caveat: the precise code above does not compile in Ceylon 1.1, because the narrow() method is new, and because of a fixed bug in the typechecker. But it will work in the upcoming 1.2 release of Ceylon.
| Reference: | Unique approach to observer/observable pattern in Ceylon from our JCG partner Gavin King at the Ceylon Team blog blog. |
