According to Microsoft, observer pattern is a behavioral design that allows one object to notify other objects about changes in its state.
Many beginner programmers (and even more experienced ones) have a hard time understanding the link between delegates and events, and the core upon which this link is built is represented precisely by the observer pattern. To make this concept easy to understand, so you can learn the transition to events easier, let’s take a simple example. Let’s imagine that we want to implement a system that will alert cars when a train is coming, so that they stop. The first building block of this system will be represented by a class named TrainSignal:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
using System; namespace HelloWorld { public class TrainSignal { public Action TrainsAreComing; public void HereComesATrain() { // pretend there is a bunch of logic here, // like blinking lights, lowering bariers, alarms, etc // invoke the delegate TrainsAreComing(); } } public class Program { public static void Main() { Console.Read(); } } } |
There is nothing complicated about my class: I added an Action, TrainsAreComing, and remember, an Action is just a delegate that takes between 0 and 16 parameters and returns void. This will represent our train signal. Finally, I added a public method named HereComesATrain(), that will perform all the necessary actions when a train is coming, and also inform anyone that is interested in the train coming, by invoking the TrainsAreComing delegate.
The next step is to declare the objects that are actually interested in the fact of a train coming, so, I will add a Car class:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
using System; namespace HelloWorld { public class TrainSignal { public Action TrainsAreComing; public void HereComesATrain() { // pretend there is a bunch of logic here, // like blinking lights, lowering bariers, etc TrainsAreComing(); } } public class Car { public Car(TrainSignal trainSignal) { trainSignal.TrainsAreComing += StopTheCar; } private void StopTheCar() { Console.WriteLine("Stop the car immediately, a train is coming!"); } } public class Program { public static void Main() { Console.Read(); } } } |
In my Car class, I have an overload constructor that accepts a TrainSignal instance, and inside this constructor I am adding a method named StopTheCar() to the delegate chain of TrainsAreComing. This can also be understood as “I am subscribing my StopTheCar() method to the TrainsAreComing delegate, so that when this delegate is invoked, my method will be called too”, or simply “hey, add me to the list of subscribers of this delegate”.
And this is precisely the .NET way of doing the observer pattern, by subscribing our methods to the chain of methods of a delegate, whenever that delegate will be invoked, all the methods that subscribed to it will get called, so, they will “observe” that the delegate was invoked. In my example, all the Car instances that will subscribe to TrainsAreComing delegate will observe when this delegate will be invoked (when the train signal will be triggered and all the subscribing methods will be notified).
Now, all it remains to be done is to actually put this whole system to work:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
using System; namespace HelloWorld { public class TrainSignal { public Action TrainsAreComing; public void HereComesATrain() { // pretend there is a bunch of logic here, // like blinking lights, lowering bariers, etc TrainsAreComing(); } } public class Car { public Car(TrainSignal trainSignal) { trainSignal.TrainsAreComing += StopTheCar; } private void StopTheCar() { Console.WriteLine("Stop the car immediately, a train is coming!"); } } public class Program { public static void Main() { // create a new train signal TrainSignal trainSignal = new TrainSignal(); // subscribe some car objects to that signal new Car(trainSignal); new Car(trainSignal); new Car(trainSignal); new Car(trainSignal); new Car(trainSignal); // trigger the signal and inform all cars that a train is coming trainSignal.HereComesATrain(); Console.Read(); } } } |
First thing to remember is that a delegate keeps track not only of the method that it will later call, but also of the object that that method belongs to. I explained in the lesson about delegates that they have two important properties: Method and Target. For this reason, I don’t actually have to declare a name for my Car instances, I can instantiate them anonymously, using the new operator directly. Since they all subscribe to TrainsAreComing delegate inside their constructor, the delegate will remember each instance that subscribed to it.
Next, notice that when I am calling HereComesATrain() method, it will invoke the delegate, which means that the delegate will call any StopTheCar() method of any Car that subscribed to it, effectively notifying each subscriber.
This is the output that proves the fact that all our 5 subscriber Car instances stopped when the train signal delegate was invoked:
Tags: Action, delegate chaining, delegates, observer, observer pattern, subscriber
