Observer
The Observer pattern, quite simply, lets one component notify other components that something happened. The pattern is used all over the place: for example, when binding data to UI, we can program domain objects such that when they change, they generate notifications that the UI can subscribe to and update the visuals.
Events can be members of a class and are decorated with the event keyword.
Event handlers – methods that are called whenever an event is raised – are attached to the event with the += operator and are detached with the -= operator.
- An event handler typically takes two arguments:
An object reference to who exactly fired the event
An object that (typically) derives from EventArgs that contains any necessary information about the event
The exact type of an event that is used is typically a delegate. Just like the Action/Func wrappers for lambdas, the delegate wrappers for events are called EventHandler and exist in both nongeneric (that takes an EventArgs) and a generic (that takes a type parameter that derives from EventArgs) second argument. The first argument is always an object.
As you can see, we are using a strongly typed EventHandler delegate to expose a public event. The CatchACold() method is used to raise the event, with the safe access ?. operator being used to ensure that if the event doesn’t have any subscribers, we don’t get a NullReferenceException.
The event handler can be an ordinary (member) method, a local function, or a lambda – your choice. The signature is mandated by the original delegate; since we’re using a strongly typed EventHandler variant, the second argument is FallsIllEventArgs. As soon as CatchACold() is called, the CallDoctor() method is triggered.
Any given event can have more than one handler (C# delegates are multicast, after all). Removal of event handlers is typically done with the -= operator. When all subscribers have unsubscribed from an event, the event instance is set to null.
Weak Event Pattern
Did you know that .NET programs can have memory leaks? Not in the C++ sense, of course, but it is possible to keep holding on to an object for longer than necessary. Specifically, you can make an object and set its reference to null but it will still be alive. How? Let me show you.
The reason why the window reference is still alive is that it has a subscription to the button. When a button is clicked, the expectation is that something sensible happens: since there is a subscription to this event, the object that happens to have made this subscription cannot be allowed to die, even if the only reference to that object has been set to null. This is a memory leak in the .NET sense.
Repeating the scenario again, this Window2 implementation gives a windowRef.IsAlive result of False, as desired.
Event Streams
With all these discussions of Observer, you might be interested to learn that the .NET Framework comes with two interfaces: IObserver<T> and IObservable<T>. These interfaces, which were coincidental with the release of Reactive Extensions (Rx), are meant primarily to deal with reactive streams. While it is not my intention to discuss the entirety of Reactive Extensions, these two interfaces are worth mentioning.
Let’s start with IObservable<T>. This is an interface that is generally similar to the interface of a typical .NET event. The only difference is that instead of using the += operator for subscription, this interface requires that you implement a method called Subscribe(). This method takes an IObserver<T> as its only parameter. Remember, this is an interface, and unlike in the case of events/delegates, there is no prescribed storage mechanism. You are free to use anything you want.
There is some extra icing on the cake: the notion of unsubscription is explicitly supported in the interface. The Subscribe() method returns an IDisposable with the understanding that the return token (Memento pattern at work!) has a Dispose() method that unsubscribes the observer from the observable.
OnNext(T) gets invoked whenever a new event occurs.
OnCompleted() gets invoked when the source has no more data to give.
OnError() gets invoked whenever the observer has experienced an error condition.
Once again, this is just an interface, and how you handle this is up to you. For example, you can completely ignore both OnCompleted() and OnError().
I’m sure you’ll agree that this is a lot more complicated than just publishing a single event for clients to subscribe to! But there are advantages to this: for example, you can choose your own policy with respect to repeat subscriptions, that is, situations when a subscriber is trying to subscribe to some event again. One thing worth noting is that HashSet<Subscription> is not a thread-safe container. This means that if you want Subscribe() and CatchACold() to be callable concurrently, you would need to either use a thread-safe collection, locking or perhaps something even fancier, like an ImmutableList.
This is, once again, quite a mouthful. We could have simplified the subscription by using a special Observable.Subscribe() static method, but Observable (without the I) is part of Reactive Extensions, a separate library that you may or may not want to use.
Property Observers
One of the most common Observer implementations in .NET is getting notifications when a property changes. This is necessary, for example, to update UI when the underlying data changes. This mechanism uses ordinary events as well as some interfaces that have become standard within .NET.
Property observers can get really complicated, so we’ll cover them in steps, starting from basic interfaces and operations and moving onto the more complicated scenarios.
Basic Change Notification
There is a lot to discuss here. First of all, the property gets a backing field. This is required in order to look at the previous value of the property before it is assigned. Notice that the invocation of the OnPropertyChanged() method happens only if the property did change. If it didn’t, there’s no notification.
As far as the IDE-generated OnPropertyChanged() method is concerned, this method is designed to take in the name of the affected property via [CallerMemberName] metadata and then, provided the PropertyChanged event has subscribers, notify those subscribers that the property with that name did, in fact, change.
You can, of course, build your own change notification mechanisms, but both WinForms and WPF are intrinsically aware of INotifyPropertyChanged, as are many other frameworks. So, if you need change notifications, I’d stick to this interface.
A special note needs to be added about INotifyPropertyChanging – an interface that is intended to send events indicating that a property is in the process of changing. This interface is very rarely used, if ever. It would have been nice to be able to use this property to cancel a property change, but sadly the interface makes no provisions for this. In actual fact, cancellation of property changes can be one of the reasons why you would want to implement your own interfaces instead of these.
Bidirectional Bindings
The INotifyPropertyChanged is very useful for notifying the user interface about the change of a property some label is bound to. But what if you have an edit box instead, and that edit box also needs to update the code element behind the scenes?
This is actually doable and doesn’t even result in infinite recursion! This problem generalizes to the following: how do you bind two properties such that changing the one changes the other, in other words, their values are always identical?
Common sense dictates that this code, when triggered, would cause a StackOverflowException: window affects product, product affects window, and so on. Except it doesn’t happen. Why? Because the setter in both properties has a guard that checks that the value did, in fact, change. If it didn’t, it does a return and no further notifications take place. So we’re safe here.
The preceding solution works, but frameworks such as WinForms try to shrink-wrap situations such as these into separate data binding objects. In a data binding, you specify the objects and their properties and how they tie together. Windows Forms, for example, uses property names (as strings), but nowadays we can be a little bit smarter and use expression trees instead.
The owner of the first property
An expression tree accessing the first object’s property
The owner of the second property
An expression tree accessing the second object’s property
Sadly, it is impossible to reduce the number of parameters in this scenario, but at least they will be more or less human-readable. We’ll also avoid using generics here, though they can, in theory, introduce additional type safety.
Each expression tree is expected to be a MemberExpression.
Each member expression is expected to access a property (thus, PropertyInfo).
If these conditions are met, we subscribe each property to each other’s changes. There’s an additional dispose guard added to this class to allow the user to stop processing the subscriptions if necessary.
The preceding is a trivial example of the kinds of things that can happen behind the scenes in frameworks that intend to intrinsically support data binding.
Property Dependencies
In Microsoft Excel, you can have cells contain calculations using values of other cells. This is very convenient: whenever a particular cell’s value changes, Excel recalculates every single cell (including cells on other sheets) that this cell affected. And then those cells cause the recalculation of every cell dependent on them. And so it goes forever until the entire dependency graph is traversed, however long it takes. It’s beautiful.
The problem with properties (and with the Observer pattern generally) is exactly the same: sometimes a part of a class not only generates notifications but affects other parts of the class, and then those members also generate their own event notifications. Unlike Excel, .NET doesn’t have a built-in way of handling this, so such a situation can quickly turn into a real mess.
In the preceding code, changes to a person’s age should affect their ability to vote. However, we would also expect to generate appropriate change notifications for CanVote… but where? After all, CanVote has no setter!
As you can see, the only way to determine that CanVote has been affected is to cache its old value, perform the changes on age, then get its new value and check if it’s been modified, and only then perform the notification.
Even without this particular pain point, the approach we’ve taken with property dependencies does not scale. In a complicated scenario where properties depend on other properties, how are we expected to track all the dependencies and make all the notifications? Clearly, some sort of centralized mechanism is needed to track all of this automatically.
This class is complicated, so let’s go through this slowly and figure out what’s going on here.
First, we have affectedBy, which is a dictionary that lists every property and a HashSet of properties affected by it. For example, if voting ability is affected by age and whether or not you’re a citizen, this dictionary will contain a key of "CanVote" and values of {"Age", "Citizen"}.
We then modify the default OnPropertyChanged() implementation to ensure that the notifications happen both on the property itself and all properties it affects. The only question now is – how do properties get enlisted in this dictionary?
Notice that we restrict ourselves to the declaring type of the owning class – handling a situation with property dependencies between classes is doable, but a lot more complicated.
So it works. But our implementation is still far from ideal. If I were to change the age to 10 in the preceding code, CanVote would still receive a notification, even though it shouldn’t! That’s because, at the moment, we’re firing these notifications unconditionally. If we wanted to fire these only when the dependent properties have changed, we would have to resort to INotifyPropertyChanging (or a similar interface) where we would have to cache the old value of every affected property until the INotifyPropertyChanged call and then check that those have, in fact, changed. I leave this as an exercise for the reader.
Notice that, in the preceding code, we must do propertyName propagation because the [CallerMemberName] attribute inside OnPropertyChanged() will no longer work for us out of the box.
Views
There’s a big, huge, glaring problem with property observers: the approach is intrusive and clearly goes against the idea of Separation of Concerns. Change notification is a separate concern, so adding it right into your domain objects might not be the best idea.
Why not? Well, imagine you decide to change your mind and move from the use of INotifyPropertyChanged (INPC) to the user of the IObservable interface. If you were to scatter INPC use throughout your domain objects, you’d have to meticulously go through each one, modifying each property to use the new paradigm, not to mention the fact that you’d have to modify those classes as well to stop using the old interfaces and start using the new ones. This is tedious and error-prone, and precisely the kind of thing we’re trying to avoid.
So, if you want change notifications handled outside of the objects that change, where would you add them? It shouldn’t be hard – after all, we’ve seen patterns such as Decorator that are designed for this exact purpose.
One approach is to put another object in front of your domain object that would handle change notifications and other things besides. This is what we would typically called a view – it is this thing that would be bound to UI, for example.
The preceding code is, of course, a Decorator. It wraps the underlying object with mirroring getters/setters that perform the notifications. If you need even more complexity, this is the place to get it. For example, if you want property dependencies tracked in an expression tree, you’d do it in this constructor rather than in the constructor of the underlying object.
You’ll notice that, in the preceding listing, I’m trying to be sly by hiding any implementation details. We simply inherit from some class View and we don’t really care how it handles notifications: maybe it uses INotifyPropertyChanged, maybe it uses IObservable, maybe something else. We don’t care.
The only real issue is how to call this class’ setter considering that we want it to have information about both the name of the property we’re assigning (just in case it’s needed) and the value being assigned. There’s no uniform solution to this problem, and obviously, the more information you pack into this improvised setValue() method, the better. If person.Name had been a field, things would be greatly simplified because we could simply pass a reference to that field to be assigned, but we’d still have to pass a nameof() for the base class to notify via INPC if necessary.
Observable Collections
If you bind a List<T> to a list box in either WinForms or WPF, changing the list won’t update the UI. Why not? Because List<T> does not support the Observer pattern, of course – its individual members might, but the list as a whole has no explicit way of notifying that its contents have changed. Admittedly, you could just make a wrapper where methods such as Add() and Remove() generate notifications. However, both WinForms and WPF come with observable collections – classes BindingList<T> and ObservableCollection<T>, respectively.
Both of these types behave as a Collection<T>, but the operations generate additional notifications that can be used, for example, by UI components to update the presentation layer when the collections change. For example, ObservableCollection<T> implements the INotifyCollectionChanged interface which, in turn, has a CollectionChanged event. This event will tell you what action has been applied to the collection and will give you a list of both old and new items, as well as information about old and new starting indices: in other words, you get everything that you need in order to, say, redraw a list box correctly depending on the operation.
Inherit from an observable collection and just put common collection operations such as Add() behind a lock.
Inherit from a concurrent collection (e.g., a ConcurrentBag<T>) and add INotifyCollectionChanged functionality.
You can find implementations of both of these approaches on StackOverflow and elsewhere. I prefer the first option as it’s a lot simpler.
Observable LINQ
When we discussed property observers, we also managed to discuss the idea of properties that affect other properties. But that’s not all they affect. For example, a property might be involved in a LINQ query which yields some result. So, how can we know that we need to requery the data in a particular query when a property it depends on changes?
Over time, there had been frameworks such as CLINQ (Continuous LINQ ) and Bindable LINQ that attempted to solve the problem of a LINQ query generating the necessary events (i.e., CollectionChanged) when one of its constituent parts failed. Other frameworks exist, and I can offer no recommendations here about which one I would recommend you use. Keep in mind that these frameworks are attempting to solve a really difficult problem.
Declarative Subscriptions in Autofac
So far, most of our discussions have centered around the idea of explicit, imperative subscription to events, whether via the usual .NET mechanisms, Reactive Extensions, or something else. However, that’s not the only way event subscriptions can happen.
You can also define event subscriptions declaratively. This is often made possible by the fact that applications make use of a central IoC container where the declarations can be found and event wireups can be made behind the scenes.
There are two popular approaches for declarative event wireups. The first uses attributes: you simply mark some method as [Publishes("foo")] and some other method, in some other class, as [Subscribes("foo")] and the IoC container makes a connection behind the scenes.
First, we register all assembly types that implement ISend<>. There are no special steps that need to be taken there because they just need to exist somewhere. For the sake of simplicity, we register them as singletons – if that were not the case, the situation with the wireups would become even more complicated because the system would have to track each constructed instance.2
We then register the types that implement IHandle<>. This is where things get crazy because we specify an additional OnActivated() step that must be performed before an object is returned.
Then, given this IHandle<Foo> type, we locate all types which implement the ISend<Foo> interface using reflection. This is a rather tedious process.
For each of the located types, we wire up the subscription. Again, this is done using reflection, and you can also see some magic strings here and there.
In a similar fashion, you could implement declarative subscriptions using attributes instead. And if you don’t use Autofac, don’t worry: most popular IoC containers are capable of implementing these sorts of declarative event wireups.
Summary
Generally speaking, we could have avoided discussing the Observer pattern in C# because the pattern itself is baked right into the language. That said, I have demonstrated some of the practical uses of the Observer (property change notifications) as well as some of the issues related to that (dependent properties). Furthermore, we looked at the way in which the Observer pattern is supported for reactive streams.
Thread safety is one concern when it comes to Observer, whether we are talking about individual events or entire collections. The reason why it shows up is because several observers on one component form a list (or similar structure) and then the question immediately arises as to whether that list is thread-safe and what exactly happens when it’s being modified and iterated upon (for purposes of notification) at the same time.