Fastest way to hold and parse through a collection of Enums?

Fastest way to hold and parse through a collection of Enums? - c#

In the program I am creating, I have a large amount of enums
enum kEvents
{
Start = 0,
End,
EntityCreated,
}
In this program, there is a huge list of Entities.
Each entity holds a list of "kEvents" that it is "Registered to"
Every time an object says "Call the Start event" I have to iterate through every single entity in the game, and find out if they are "listening" for that event.
Note: I know that c# has event handlers, but I was hoping to create this enum system from the ground up instead.
This being the case, what is the best way to:
Hold the collection of enums in each entity object
Check if the entity holds the triggered enum
I am wondering if Enums, being basically numbers, have a lower level, quicker way to handle this than a List<T> of objects.

Every time an object says "Call the Start event" I have to iterate through every single entity in the game, and find out if they are "listening" for that event.
You're doing it wrong! Iterating over every single object and checking if they're registered for an event is very inefficient! This is the typical Observer design pattern and there are several ways to go about this, here are a couple:
Have a single event which gets raised and has an enum parameter for event type (every subscriber gets it).
Have a dictionary of enums and corresponding events.
Here is what option 1 might look like:
delegate void OnEventDelegate(kEvents anEvent);
public class MyEventObservable
{
public event OnEventDelegate OnEvent;
}
public class MyEventObserver
{
// Constructors and all
// ...
public void OnEventReceived(kEvents anEvent)
{
switch(anEvent)
{
// switch through all the events and handle the ones that you need
}
}
}
MyEventObserver observer = new MyEventObserver();
MyEventObservable observable = new MyEventObservable();
observable.OnEvent += new OnEventDelegate(observer.OnEventReceived);
Here is option 2:
public class MyEventObservable
{
private Dictionary<kEvents, List<IObserver>> _observers;
MyEventObservable()
{
// Initialize the dictionary with all the events
}
public void RegisterObserver(kEvents event, IObserver observer)
{
_observers[event].Add(observer);
}
}
interface class IObserver
{
void Notify(kEvents anEvent);
}
public MyEventObserver: IObserver
{
// Constructors and all
// ...
// Override the IObserver
public void Notify(kEvents anEvent)
{
switch(anEvent)
{
// switch through all the events and handle the ones that you need
}
}
}
MyEventObserver observer = new MyEventObserver();
MyEventObservable observable = new MyEventObservable();
observable.RegisterObserver(kEvents.Start, observer);
Option two will reduce the number of events each observer has to handle, but it comes at the cost of having to register for every event separately (which adds coding complexity). This means that option 2 will work faster because there are fewer function calls to make. Depending on how "crazy" you want to get with the performance, there might be other options that can help you to speed it up but this should set you on the right track.
P.S. I have not compiled any of the code, but it should give you a general idea of how things ought to work.

It seems to me that you want to implement some kind of publish/subscribe scheme, some centralized event sink that the Entities can subscribe to events and provide a callback when that event happens, then other Entities would Rise the event and the event sink would call all the Entities that are subscribed to that event.... but I may have not understood the question :)
Something like:
How to access controls in other class

Every time an object says "Call the Start event" I have to iterate
through every single entity in the game, and find out if they are
"listening" for that event.
If I have correctly understood what you are doing then you are doing it backwards. the knowledge of which events an entity is listening to cannot be (only) in the event itself. There must be another data structure that holds this information.
That other data structure could be something as simple as a Map from the enum constant to a list of entities.

Related

Alternative to enumerators in AI

I'm working on a server for a multi-player game that has to control a few thousand creatures, running around in the world. Every creature has an AI with a heartbeat method that is called every few ms/s, if a player is nearby, so they can react.
Currently the AI uses enumerators as "routines", e.g.
IEnumerable WanderAround(int radius)
{
// Do something
}
which are called from "state methods", which are called in foreachs, yielding in the heartbeat so you get back to the same spot on every tick.
void OnHeartbeat()
{
// Do checks, maybe select a new state method...
// Then continue the current sequence
currentState.MoveNext();
}
Naturally the routines have to be called in a loop as well, because they wouldn't execute otherwise. But since I'm not the one writing those AIs, but newbies who aren't necessarily programmers, I'm pre-compiling the AIs (simple .cs files) before compiling them on server start. This gives me AI scripts that look like this:
override IEnumerable Idle()
{
Do(WanderAround(400));
Do(Wait(3000));
}
override IEnumerable Aggro()
{
Do(Attack());
Do(Wait(3000));
}
with Do being replaced by a foreach that iterates over the routine call.
I really like this design because the AIs are easy to understand, yet powerful. It's not simple states but it's not a hard to understand/write behavior tree either.
Now to my actual "problem", I don't like the Do wrapper, I don't like having to pre-compile my scripts. But I just can't think of any other way to implement this without the loops, that I want to hide because of verbosity and the skill level of the people who're gonna write these scripts.
foreach(var r in Attack()) yield return r;
I'd wish there'd be a way to call the routines without an explicit loop, but that's not possible because I have to yield from the state method.
And I can't use async/await because it doesn't fit the tick design that I depend on (the AIs can be quite complex and I honestly don't know how I would implement that using async). Also I'd just trade Do() against await, not that much of an improvement.
So my question is: Can anyone think of a way to get rid of that loop wrapper? I'd be open to using other .NET languages that I can use as scripts (compiling them on server start) if there's one that supports this somehow.

Every creature has an AI with a heartbeat method that is called every few ms/s,
Why not go full SkyNet and have each creature responsible for its own heartbeat?
Such as creating each creature with a timer (the heart so to speak with a specific heartbeat). When each timer beats it does what it was designed to do, but also checks with the game as to whether it needs to shut-down, be idle, wander or other items.
By decentralizing the loop, you have gotten rid of the loop and you simply have a broadcast to subscribers (the creatures) on what to do on a global/basic level. That code is not accessible to the newbies, but it is understood what it does on a conceptual level.

You could try turning to the .NET framework for help by using events in your server and having the individual AIs subscribe to them. This works if the Server is maintaining the heartbeat.
Server
The server advertises the events that the AIs can subscribe to. In the heartbeat method you would call the OnIdle and OnAggro methods to raise the Idle and Aggro events.
public class GameServer
{
// You can change the type of these if you need to pass arguments to the handlers.
public event EventHandler Idle;
public event EventHandler Aggro;
void OnIdle()
{
EventHandler RaiseIdleEvent = Idle;
if (null != RaiseIdleEvent)
{
// Change the EventArgs.Empty to an appropriate value to pass arguments to the handlers
RaiseIdleEvent(this, EventArgs.Empty);
}
}
void OnAggro()
{
EventHandler RaiseAggroEvent = Aggro;
if (null != RaiseAggroEvent)
{
// Change the EventArgs.Empty to an appropriate value to pass arguments to the handlers
RaiseAggroEvent(this, EventArgs.Empty);
}
}
}
Generic CreatureAI
All of your developers will implement their creature AIs based on this class. The constructor takes a GameServer reference parameter to allow the events to be hooked. This is a simplified example where the reference is not saved. In practice you would save the reference and allow the AI implementors to subscribe and unsubsrcibe from the events depending on what state their AI is in. For example subscribe to the Aggro event only when a player tries to steal your chicken's eggs.
public abstract class CreatureAI
{
// For the specific derived class AI to implement
protected abstract void IdleEventHandler(object theServer, EventArgs args);
protected abstract void AggroEventHandler(object theServer, EventArgs args);
// Prevent default construction
private CreatureAI() { }
// The derived classes should call this
protected CreatureAI(GameServer theServer)
{
// Subscribe to the Idle AND Aggro events.
// You probably won't want to do this, but it shows how.
theServer.Idle += this.IdleEventHandler;
theServer.Aggro += this.AggroEventHandler;
}
// You might put in methods to subscribe to the event handlers to prevent a
//single instance of a creature from being subscribe to more than one event at once.
}
The AIs themselves
These derive from the generic CreatureAI base class and implement the creture-specific event handlers.
public class ChickenAI : CreatureAI
{
public ChickenAI(GameServer theServer) :
base(theServer)
{
// Do ChickenAI construction
}
protected override void IdleEventHandler(object theServer, EventArgs args)
{
// Do ChickenAI Idle actions
}
protected override void AggroEventHandler(object theServer, EventArgs args)
{
// Do ChickenAI Aggro actions
}
}

Create a special dictionary<T, EventDelegate<T>> with generic delegate EventDelegate<T>(T e) where T : GameEventBase

I have a game with many classes that need to listen to events. But under certain circumstances, those classes are destroyed or disabled. When that happens, I need to remove their listening methods from the events manager delegate table.
I don't want to modify the EventsManager and I would like to each class that adds any events to it to know which events it added.
I'm currently using something like this do add and remove the events in each class:
void AddEventsListeners() {
EventsManager.AddListener<OnClickDown>(OnClickDownHandler);
EventsManager.AddListener<OnClickUp>(OnClickUpHandler);
EventsManager.AddListener<OnClick>(OnClickHandler);
}
void RemoveEventsListeners() {
EventsManager.RemoveListener<OnClickDown>(OnClickDownHandler);
EventsManager.RemoveListener<OnClickUp>(OnClickUpHandler);
EventsManager.RemoveListener<OnClick>(OnClickHandler);
}
Those OnClick are all derived from GameEventBase, and the OnClickHandler are methods declared as
void OnClickDown(OnClickHandler e) {}
to match the delegate that is used in the EventsManager, which is declared as
delegate void EventDelegate<T>(T e) where T : GameEventBase;
I want to be able to fill a special hash table named, say, events, that has keyvalue pairs like
<T, EventDelegate<T>> where T: GameEventBase
That is, I want to be able to do events.add(OnClick, OnClickHandler), where OnClickHandler is declared as
OnClickHandler(OnClick e) {}
And I want adding to fail if OnClickHandler where defined, for example, as
OnClickHandler(OtherGameEventBaseDerivedEvent e) {}
That requirement translates to me wanting type safety in that special dictionary.
One of my attempts involved not a dictionary, but a way to decide which method to call, between the AddListener and RemoveListener
I didn't like it because it introduces a parameter to the method and the code reads really weird with it. It does work, and does reduce the repetition, but is too ugly.
I create a AddOrRemoveAllListeners(AddOrRemove addOrRemove), which I populated with calls to AddOrRemoveListener for each event.
Now all I had to do is AddOrRemoveAllListeners(AddOrRemove.Remove) or AddOrRemoveAllListeners(AddOrRemove.Add), to add or remove my events.
enum AddOrRemove {
Remove,
Add
}
void AddOrRemoveListener<T>(EventsManager.EventDelegate<T> del, AddOrRemove addOrRemove)
where T : GameEventBase {
switch (addOrRemove) {
case AddOrRemove.Remove:
EvMan.RemoveListener<T>(del);
break;
case AddOrRemove.Add:
EvMan.AddListener<T>(del);
break;
}
}
Another attempt involved creating the type
class EventsDictionary<T> : Dictionary<T, EventsManager.EventDelegate<T>> where T : GameEventBase { }
And using it like this:
EventsDictionary<GameEventBase> events = new MyCustomDictionary<GameEventBase>();
void AddEventHandlerPairToEventsDictionary<T>(T e, EventsManager.EventDelegate<T> handler) where T : GameEventBase {
if (!events.ContainsKey(e)) {
events.Add(e, handler);
}
}
But the events.Add(e, handler) fails and forces me to declare the handler as
EventsManager.EventDelegate<GameEventBase>
instead of
EventsManager.EventDelegate<T>
If I do that, I could add keyvalue pairs that don't make sense in that events type, i.e., I lose the event handling type safety.
I want to have such a structure because I don't like all those repetitions. It would be really bad if someone forgot to remove an event in the RemoveEventsListeners().
Having such a dictionary, I could use a foreach loop to add/remove the handlers to the EventsManager, which would be really nice.
As for performance, this is for a game and it needs to have good performance. Those adding/removing of events can happen a lot (sometimes hundreds of times per frame) because a lot of objects are destroyed (can't leave null handlers in the EventsManager) or disabled (need to stop listening to everything until enabled again) all the time. This means reflection and lots of casting/boxing or anything that creates lots of garbage collected objects is out.
I'm, of course, open to suggestions as to other ways to approach this.
Thanks for your assistance!
I'm attaching the relevant parts of the EventsManager being used (The RemoveListener() is analogous to the AddListener). The GameEventBase is just an empty shell. It isn't a .NET event nor uses EventArgs.
public class EventsManager : ManagedBase {
public delegate void EventDelegate<T>(T e) where T : GameEventBase;
private delegate void EventDelegate(GameEventBase e);
private readonly Dictionary<Type, EventDelegate> delegates = new Dictionary<Type, EventDelegate>();
private readonly Dictionary<Delegate, EventDelegate> delegateLookup = new Dictionary<Delegate, EventDelegate>();
public void AddListener<T>(EventDelegate<T> del) where T : GameEventBase {
// Early-out if we've already registered this delegate
if (delegateLookup.ContainsKey(del)) {
return;
}
// Create a new non-generic delegate which calls our generic one.
// This is the delegate we actually invoke.
EventDelegate internalDelegate = (e) => del((T) e);
delegateLookup[del] = internalDelegate;
EventDelegate tempDel;
if (delegates.TryGetValue(typeof (T), out tempDel)) {
delegates[typeof (T)] = tempDel + internalDelegate;
}
else {
delegates[typeof (T)] = internalDelegate;
}
}
public void Raise(GameEventBase e) {
EventDelegate del;
if (delegates.TryGetValue(e.GetType(), out del)) {
del.Invoke(e);
}
}
}

Your problems seem to be solved if you use the EventAggregator pattern.
There is a short description of it by Martin Fowler
Some very good implementations of it already exist, for example in caliburn micro and
Microsoft Prism
The general idea is that you simplify event registration and deregistration and have a single source of events for many objects.
I never had performance issues with it. You simply put a _eventAggregator.Subscribe(this) when you want to start listening to events for an object and Unsubscribe if you want to stop. Whereever you want to fire an event, just publish it, EventAggregator does the routing.

This once again looks like an XY problem. OP seems to want to have a central place to handle event handlers, registration and disposal. The OP has gone down the route of trying to create a pattern that deal with this in a generic way, but has not looked into the state of the art regarding how this problem is typically solved. He has now come up against a problem in his design and is now asking for a solution to THAT problem, rather than the original problem of event handlers.
There are two good solutions to event handler registration lifecycle management that I know of in .net.
Weak Event Handler
You state that "It would be really bad if someone forgot to remove an event in the RemoveEventsListeners()." Yet do not actually mention WHY it is bad. Typically the only reason for this being bad is that the event handler will now keep an object in reference, that should be collected. With weak reference event handlers, the GC will still be able to collect your object, even when it subscribes to an object that is still alive.
Rx.Net
Rx.Net abstracts event registrations into IDisposables, which you can tie to the object's lifetime, assuming of course you want to control the lifetime of the registrations.
However I actually find the IObservable pattern much nicer to work with than event handler pattern, mostly because C# lacks first class support for event handlers (this is not the case with F#).
F#
Most of your problems will have stemmed from the short sighted design of events keyword handling in C# (specifically not making events a first class construct). F# however does support first class events, and thus should be able to support the pattern you are trying to construct.
Thus with this option you should scrap your code base and rewrite it in F#.
*EDIT added tongue in cheek option of rewriting in F#.

.Net - Using Action/Delegate to pass data back up the navigation stack

I have multiple levels of nested classes. I need a better way to notify my parent class by sending a value up the nested stack.
To expand on the above, in my inner class I have an asynchronous method call. Now I need to notify my parent class once My asynchronous method has completed its execution. Is there a way in which I could use an Action to get the value?
Thanks

Rather than try and pass values "up the stack" (which will get very messy, very quickly), might I suggest you implement some kind of Observer or other event pattern of your choosing, and have the parent auto-magically notified and avoid trying to return values to the parent "up the stack"?
As a simple example, I'll assume your current predicament is akin to this:
public void DoSomething(Action callback)
{
DoSomethingElse(callback);
}
public void DoSomethingElse(Action callback)
{
WeMustGoDeeper(callback);
}
public void WeMostGoDeeper(Action callback)
{
// I have no idea who I am anymore.
}
It would be far better to implement even a simple observer/event system. In essence you'd have some kind of an observer that raises an event (note: this is grossly simplified):
public class Observer
{
public delegate void SomethingHappenedDelegate();
public void NoReallySomethingHappened()
{
if(SomethingHappened != null)
SomethingHappened();
}
public event SomethingHappenedDelegate SomethingHappened;
}
You'd create an instance of this class somewhere, and your last function needs to do something along the lines of:
whateverTheObserver.NoReallySomethingHappened();
ANY class can subscribe to this and be notified when something happened. How you deal with that observer is entirely up to you. It could be passed down the call-stack, or be available from a factory, or some other accessible class.

What use cases exist for non-static private or protected events?

What purpose do protected or private (non-static) events in .NET really serve?
It seems like any private or protected event is more easily handled via a virtual method. I can (somewhat) see the need for this in static events, but not for normal events.
Have you had a use case before that clearly demonstrates a need or advantage for a non-static protected or private event?

Here's a slightly bizarre but real-world scenario I implemented once. You have machine-generated and user-generated halves of a partial class. The machine-generated half contains code which wishes to inform the user-generated half when some event occurs. But the user-generated half might not care to do anything, or it might care to do rather a lot. It seems rude of the machine-generated half to require that the user-generated half implement a particular method in order to handle a message they don't have any interest in listening to.
To solve this problem, the machine-generated half could fire on a private event. If the user-generated half cares, it can subscribe the event. If not, it can ignore it.
This scenario is now addressed more elegantly by partial methods in C# 3, but that was not an option back in the day.

Seems to me that a good example of where a private event is useful is in component/control building, often you may have a component that is a composite of 1 or more other components, private events that contained components can subscribe to is a handy and easy implementation of an observer pattern.
Edit:
Let me give an example...
Say you are writing a Grid type control, and inside of this control you would most likely have a bunch of contained classes that are created dynamically Rows, Cols, headers etc for example, say you want to notify these contained classes that something they care about has happend, say a Skinning change or something like that, something that you don't necesarrily want to expose as an event to the grid users, this is where private events are handy, simply have one or 2 handlers and as you create each instance of your row or col or whatever attach the handler, as otherwise you just have to write your own observer mechanism, not hard, but why when you dont have to and you can just use multicast events.

Nested types have access to the enclosing type's private and protected events. I've used this feature to notify child controls (the nested type) of state changes in the parent control (the enclosing type) in a Silverlight application.

Sorry to drag up an old thread, but I use private events with impunity in one of my projects, and personally, I find it's a good way of solving a design issue:
Here's the abbreviated code:
public class MyClass
{
private event EventHandler _myEvent;
public ExternalObject { get; set; }
public event EventHandler MyEvent
{
add
{
if (_myEvent.GetInvocationList().Length == 0 && value != null)
ExternalObject.ExternalEvent += HandleEvent;
_myEvent+= value;
}
remove
{
_myEvent-= value;
if (_myEvent.GetInvocationList().Length == 0)
ExternalObject.ExternalEvent -= HandleEvent;
}
}
private void HandleEvent(object sender, EventArgs e)
{
_myEvent.Raise(this, EventArgs.Empty); // raises the event.
}
}
Basically, MyEvent is only ever raised in the event handler of ExternalObject.ExternalEvent, so if there's no handlers for MyEvent then I don't need to attach a handler to the external event, speeding up the code slightly by saving a stack frame.

Not only the current instance can access a private member. Other instances of the same type can too! This enables some scenarios where this access control may be useful.
I am thinking of a tree structure where all nodes inherit a certain type and a private/protected event allows to propagate leaf events to their parents. Since they are the same type, the parent can register to the child's private event. Yet any client of the tree structure cannot.
I can definitely see a use case in a directory like storage system where where each directory needs to propagate its last modified date to its parent for example.

How you would you describe the Observer pattern in beginner language?

Currently, my level of understanding is below all the coding examples on the web about the Observer Pattern. I understand it simply as being almost a subscription that updates all other events when a change is made that the delegate registers. However, I'm very unstable in my true comprehension of the benefits and uses. I've done some googling, but most are above my level of understanding.
I'm trying to implement this pattern with my current homework assignment, and to truly make sense on my project need a better understanding of the pattern itself and perhaps an example to see what its use. I don't want to force this pattern into something just to submit, I need to understand the purpose and develop my methods accordingly so that it actually serves a good purpose. My text doesn't really go into it, just mentions it in one sentence. MSDN was hard for me to understand, as I'm a beginner on this, and it seems more of an advanced topic.
How would you describe this Observer pattern and its uses in C# to a beginner?
For an example, please keep code very simple so I can understand the purpose more than complex code snippets. I'm trying to use it effectively with some simple textbox string manipulations and using delegates for my assignment, so a pointer would help!

The best example I can come up with is that of a mailing list (as an example).
You, the observer, subscribe to a mailing list and you observe the list. When you are no longer interested in the list, you unsubscribe.
This concept is the observer pattern. Two or more classes are involved. One or more class, subscribes to a publisher class (there are different names) and then the first class (and every subscribing class) will get notified when ever the publisher desires.
This is how I explained it to my wife, who often listens to my rantings about programming and design theory. It made sense to her. I realize this might be too simple for you but is a good start...
Regards,
Frank

Check out "Head First: Design Patterns" for some really, smack-your-forehead easy to follow descriptions of the major patterns.
For Observer it is important to understand that it describes a one-to-many relationship and uses a subscription model for telling other classes when there has been a change. RSS, Atom, and Twitter work along these lines.

The Observer wants to know when anything changes, so it subscribes to the Subject. The Subject does not know the Observer. This is the important part. The Subject just defines the Interface (or delegate) the Observer needs to provide, and allows the registration.
In short: The Observer pattern allows your observer to be called from a subject, that does not care who the observer is and if it even exists.

There are two objects NOTIFIER and OBSERVER. NOTIFIER knows nothing about OBSERVER, while OBSERVER knows that NOTIFER implements a event.
OBSERVER uses the event to inform other objects that something happened. Simply spoken an event is a list of methods. Because OBSERVER wants to be notified if something happend, OBSERVER adds a method, that should be called if something happens, to the event of NOTIFER.
So if the thing happens, that NOTIFIER publishes with this event, NOTIFIER just walks over the list of methods and calls them. When the method added by OBSERVER is called, OBSERVER knows that the thing happend and can do what ever is required in this case.
Here is a example notifier class with a ValueChanged() event.
// Declare how a method must look in order to be used as an event handler.
public delegate void ValueChangedHandler(Notifier sender, Int32 oldValue, Int32 newValue);
public class Notifier
{
// Constructor with an instance name.
public Notifier(String name)
{
this.Name = name;
}
public String Name { get; private set; }
// The event that is raised when ChangeValue() changes the
// private field value.
public event ValueChangedHandler ValueChanged;
// A method that modifies the private field value and
// notifies observers by raising the ValueChanged event.
public void ChangeValue(Int32 newValue)
{
// Check if value really changes.
if (this.value != newValue)
{
// Safe the old value.
Int32 oldValue = this.value;
// Change the value.
this.value = newValue;
// Raise the ValueChanged event.
this.OnValueChanged(oldValue, newValue);
}
}
private Int32 value = 0;
// Raises the ValueChanged event.
private void OnValueChanged(Int32 oldValue, Int32 newValue)
{
// Copy the event handlers - this is for thread safty to
// avoid that somebody changes the handler to null after
// we checked that it is not null but before we called
// the handler.
ValueChangedHandler valueChangedHandler = this.ValueChanged;
// Check if we must notify anybody.
if (valueChangedHandler != null)
{
// Call all methods added to this event.
valueChangedHandler(this, oldValue, newValue);
}
}
}
Here a example observer class.
public class Observer
{
// Constructor with an instance name.
public Observer(String name)
{
this.Name = name;
}
public String Name { get; private set; }
// The method to be registered as event handler.
public void NotifierValueChanged(Notifier sender, Int32 oldValue, Int32 newValue)
{
Console.WriteLine(String.Format("{0}: The value of {1} changed from {2} to {3}.", this.Name, sender.Name, oldValue, newValue));
}
}
A small test application.
class Program
{
static void Main(string[] args)
{
// Create two notifiers - Notifier A and Notifier B.
Notifier notifierA = new Notifier("Notifier A");
Notifier notifierB = new Notifier("Notifier B");
// Create two observers - Observer X and Observer Y.
Observer observerX = new Observer("Observer X");
Observer observerY = new Observer("Observer Y");
// Observer X subscribes the ValueChanged() event of Notifier A.
notifierA.ValueChanged += observerX.NotifierValueChanged;
// Observer Y subscribes the ValueChanged() event of Notifier A and B.
notifierA.ValueChanged += observerY.NotifierValueChanged;
notifierB.ValueChanged += observerY.NotifierValueChanged;
// Change the value of Notifier A - this will notify Observer X and Y.
notifierA.ChangeValue(123);
// Change the value of Notifier B - this will only notify Observer Y.
notifierB.ChangeValue(999);
// This will not notify anybody because the value is already 123.
notifierA.ChangeValue(123);
// This will not notify Observer X and Y again.
notifierA.ChangeValue(1);
}
}
The output will be the following.
Observer X: The value of Notifier A changed from 0 to 123.
Observer Y: The value of Notifier A changed from 0 to 123.
Observer Y: The value of Notifier B changed from 0 to 999.
Observer X: The value of Notifier A changed from 123 to 1.
Observer Y: The value of Notifier A changed from 123 to 1.
To understand delegate types I am going to compare them with class types.
public class Example
{
public void DoSomething(String text)
{
Console.WriteLine(
"Doing something with '" + text + "'.");
}
public void DoSomethingElse(Int32 number)
{
Console.WriteLine(
"Doing something with '" + number.ToString() + "'.");
}
}
We defined a simple class Example with two methods. Now we can use this class type.
Example example = new Example();
While this works the following does not work because the types do not match. You get a compiler error.
Example example = new List<String>();
And we can use the variable example.
example.DoSomething("some text");
Now the same with a delegate type. First we define a delegate type - this is just a type definition like the class definition before.
public delegate void MyDelegate(String text);
Now we can use the delegate type, but we cannot store normal data in a delegate type variable, but a method.
MyDelegate method = example.DoSomething;
We have now stored the method DoSomething() of the object example. The following does not work because we defined MyDelegate as a delegate taking one string parameter and returning void. DoSomethingElse returns void but takes an integer parameter so you get a compiler error.
MyDelegate method = example.DoSomethingElse;
And finally you can use the variable method. You cannot perform data manipulation because the variable stores no data but a method. But you can call the method stored in the variable.
method("Doing stuff with delegates.");
This calls the method we stored in the variable - example.DoSomething().

The observer pattern is just like it sounds -
It's a means for some objects to watch an object, observing it for changes.
In C#, this becomes somewhat simple, since events are basically a language-specific means of implementing the observer pattern. If you've ever used events, you've used the observer pattern.
In other languages, this isn't built in, so there have been many attempts to formalize approaches to handling this.

Observer is like a direct line of communication. Rather than have all your relatives call you to find out how you are, when you get sick write a card and everyone who is interested gets it (or a copy). When you get better, you send out a card. When you stub your toe, you send out a card. When you get an A, you send out a card.
Anyone who cares gets on your mass mailing list and can respond however they see fit.
This dependency is great for UI. If I have a process that is slow (for example), it can fire an even when progress is made. A progress bar element could observe that and update its coverage. An OK button could observe that and become active at 100%. A cursor could observe that an animate until the progress is 100%. None of these observers needs to know about each other. Furthermore, none of these elements strictly needs to know what is driving them either.

This pattern is probably one of the most basic, if not the most basic pattern there is.
There are two "people" involved; the publisher and the subscriber/observer.
An observer simply asks the publisher to notify him when there is "news". News can be anything of importance here. It can be the temperature of the air, it can be a new post on a website, it can be the time of day.

Probably the thing you are having trouble with is defining the proper interfaces. The interface defines the interaction between the Subscriber and the Publisher.
First make a C# WinForms application
Setup Program.cs like this
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
interface IObserver
{
void Refresh(List<string> DisplayList);
}
class ObserverList : List<IObserver>
{
public void Refresh(List<String> DisplayList)
{
foreach (IObserver tItem in this)
{
tItem.Refresh(DisplayList);
}
}
}
}
We are making two things here. The first the interface which the subscribers will implement. Then a list for the publisher to hold all the subscribers.
Then make form one with two buttons, one labeled Form 2 and the other Labeled Form 3. Then add a textbox, then another button labeled Add
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
private List<string> DataList= new List<string>();
private ObserverList MyObservers = new ObserverList();
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frmNewForm = new Form2();
MyObservers.Add(frmNewForm);
frmNewForm.Show();
MyObservers.Refresh(DataList);
}
private void button2_Click(object sender, EventArgs e)
{
Form3 frmNewForm = new Form3();
MyObservers.Add(frmNewForm);
frmNewForm.Show();
MyObservers.Refresh(DataList);
}
private void Form1_Load(object sender, EventArgs e)
{
}
private void button3_Click(object sender, EventArgs e)
{
DataList.Add(textBox1.Text);
MyObservers.Refresh(DataList);
textBox1.Text = "";
}
}
}
I deliberately set up the Form2 button and the FOrm3 button to make multiple copies of each type of Form. For example, you can have twelve up at once.
You will notice that after creating each form I put it into the Observers list. I am able to do this because both Form2 and Form3 implement IObserver. After I show the Form I call refresh on the Observer list so the new form is updated with the latest data. Note I could have cast it to a variable of IObserver and updated just that form. I am trying to be as brief as possible.
Then for the Add button 'Button3' I pull the text from the textbox store it in my DataList and then refresh all the observers.
Then make Form2. Add a list box and the following code.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form2 : Form,IObserver
{
public Form2()
{
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
}
void IObserver.Refresh(List<string> DisplayList)
{
this.listBox1.Items.Clear();
foreach (string s in DisplayList)
{
this.listBox1.Items.Add(s);
}
this.listBox1.Refresh();
}
}
}
Then Add Form3, a combobox and add the following code.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form3 : Form,IObserver
{
public Form3()
{
InitializeComponent();
}
private void Form3_Load(object sender, EventArgs e)
{
}
void IObserver.Refresh(List<string> DisplayList)
{
this.comboBox1.Items.Clear();
foreach (string s in DisplayList)
{
this.comboBox1.Items.Add(s);
}
this.comboBox1.Refresh();
}
}
}
You will notice that each form implements the refresh method of the IObserver interface slightly different. One is for a listbox the other for a combo box. The use of interfaces is the key element here.
IN a real world application this example would be more complex. For example instead of passing the string list in the Refresh Interface. It would not have any parameters. Instead the Publisher (Form1 in this example) would implement a publisher interface and register itself with the Observers as they are being initialized. Each observer would be able to accept a publisher in it's initialization routine. Then when it is refreshed it would pull the string list out of the Publisher via a method exposed through the interface.
For more complex applications with multiple types of data this allows you customize what data the form implementing IObserver is pulling out of the publisher.
Of course if you ONLY want the Observer to be able to display a string list or specific data. Then pass it as part of the parameters. The Interface makes explicit what want each layer to do. This way 5 years from now you can look at the code and code "Oh that what it is doing."

(source: headfirstlabs.com)
As said Check out "Head First: Design Patterns" they also have some forums regarding the book and a design meditation.
Observer Pattern follow the Hollywood principle "Don't call us we call you"
Good site for patterns
http://www.dofactory.com/Patterns/PatternObserver.aspx

In it's very simplest terms, there are two components: Observer and Observed.
Externally, the Observed needs a way to add (register) and remove an Observer.
Internally, the Observed needs a list of registered Observers.
The observer needs a public method such as Notify() or Notify(params).
Any time a particular thing happens to the Observed, it will loop through the list and call Notify() on every registered observer.
In the simplest case, it's a simple notification that says "Hey, Observer, My Data Changed, come and refresh yourself"
In more complex versions, parameters can be past letting the observer know what has changed.
In a Model-View-Controller, the Observed is usually an entity object -- Something that holds data. The Controller is the Observer. It watches for changes in the Model, and tells the View to update itself if it is interested in the change.
Java event listeners are a real world implementation of this pattern.

Imagine that you have a object whose behavior (or state) you want to observe. For example, when field A hits value 10, you want to get informed on that event without actually getting coupled with the implementation details of this complex object you want to observe.
You define an interface, call it Observable and let your target implement this interface, it should have at least two methods to register and unregister an Observer, which in turn is the object which will get called by Observer when field A hits 10. Your Observer simply calls Observable to register (and unregister when done). Observable normally maintain a list of Observers and notifies them at once, or as you please. It can also be done synchronously or asynchronously, it's up to you. This is very simplistic explanation without writing code. Once you understand it, the implementations can differ in details to fit your particular needs.

Observer (Publish/Subscribe)
When an object changes state, it notifies other objects that have registered their interest at runtime.
The notifying object (publisher) sends an event (publication) to all its observers (subscribers).

In one sentence:
An object (the Subject) allows other objects (Observers) to sign up for notifications.
Practical example:
Let's say you've got an app and you want to let other devs build plugins.
You could create a PluginSubject class, and put a method on it called NotifyOrderCreated. Whenever a new order is created on your order screen, it calls PluginSubject.NotifyOrderCreated.
When that happens, the PluginSubject gets a list of PluginObservers and calls PluginObserver.Notify on each of them, passing in a message describing the event.
That enables some really neat functionality.
Way More Than You Want to Know:
I actually did this recently, so I will take the example one step deeper - if you require your Observers to implement a special interface, let's say IPluginObserver, you can use reflection to walk the types in your assembly and instantiate the plugins on the fly.
Then you can allow users to sign up their own assemblies (you have to store a list of assembly names somewhere and then walk it), and bam, you've got extensibility!

Observer is a means of decoupling, that is, loosening the connections between two objects. You want that because it makes your code neater and easier to maintain. That's pretty much the goal of all design patterns: easier to read, easier to maintain code.
In this pattern, you have two classes, two objects: publisher and observer. Publisher is a class that actually does some work, then it every so often will call methods on any observers to tell them about it. It knows which classes to call because it keeps a list of observers who subscribed.
So your Publisher might look something like this:
class Publisher
{
List<Observer> observers = new List<Observer>();
public Add(Observer o)
{
observers.Add(o);
}
private AlertObservers()
{
foreach(Observer o in observers)
{
o.Alert();
}
}
Publisher really does most of the work. All the Observer needs to do is get added to the list and implement the called method. Like so:
class Observer
{
public Observer(Publisher pub)
{
pub.Add(this);
}
public Alert()
{
System.Console.WriteLine("Oh no, stuff is happening!");
}
}
That's a pretty barebones idea of how it works. Now, why is that valuable? Looks pretty well coupled up huh? One reason for that is because I don't use an Interface, which would allow me to set up many classes with Observer functionality, and Publisher need never know anything more about them except that they can receive an Alert() call. Also note that Publisher will attempt to call Alert on any and all Observers it has, even if it has none.
Now, in the C# world, the language has a built in version of this pattern through it's Event objects. Events are very powerful and make use of Delegates, which is a way of passing a method as a parameter in another method call. They allow for some serious decoupling, but I'd save that for a new question.

Very few real time Examples:
Newspaper/Magazine/Mailing List
Subscription or any subscription in general
Tagging a colleague in MS Office
Communicator
Twitter

Those who've suggested that events in .NET really are an implementation of the Observer pattern aren't pulling your chain; it's true. As for how this actually works, both from a high level perspective and in terms of more implementation-specific details, I'll use an analogy.
Think of a newspaper publisher. In OOP terms we might think of a newspaper as an observable thing. But how does it work? Clearly the implementation details of the newspaper itself (that is, in this analogy, the journalists, writers, editors, etc. all working back at the office to put the newspaper together) are not publicly exposed. People (observers) do not gather together and watch the employees of the newspaper publisher doing their work. They can't just do that, because there is no protocol (or interface) in place for doing that.
This is how you observe (i.e., read) a newspaper: you subscribe to it. You get your name on a list of subscribers to that paper, and then the publisher knows to deliver one on your doorstep every morning. If you don't want to observe (read) it anymore, you unsubscribe; you get your name taken off that list.
Now, this might seem like an abstract analogy; but it's actually an almost perfect parallel to how .NET events work.
Given some class intended to be observable, its implementation in general need not be known to the public. However, it will expose a particular kind of interface to the public, and that interface is an event. Code that wants to observe this event essentially registers itself as a subscriber:
// please deliver this event to my doorstep
myObject.SomeEvent += myEventHandler;
When this same code decides it doesn't want to be notified of this event anymore, it unsubscribes:
// cancel my subscription
myObject.SomeEvent -= myEventHandler;
Now for a quick discussion of delegates and how this code actually works. A delegate, as you may or may not know, is essentially a variable that stores the address of a method. Typically, this variable has a type -- just like value variables declared as int, double, string, etc. all have types. In the case of delegate types, this type is defined by the method's signature; that is, its parameters and its return value. A delegate of a particular type can point to any method, that performs any action, as long as that method has the appropriate signature.
So to come back to the newspaper analogy: in order to successfully subscribe to a newspaper, you have to actually follow a particular pattern. Specifically, you need to provide a valid address where you want the newspaper delivered. You can't just say, "Yeah, send it to Dan." You can't say, "I'll have a bacon cheeseburger." You have to give the publisher information that they can meaningfully work with. In the world of .NET events, this translates to needing to supply an event handler of the correct signature.
In most cases, this signature ends up being some method like this:
public void SomeEventHandler(object sender, EventArgs e) {
// anything could go in here
}
The above is a method that could be stored in a delegate variable of type EventHandler. For more specific cases, there's the generic EventHandler<TEventArgs> delegate type, which desribes a method similar to the above, but with an e parameter of some type derived from EventArgs.
Keeping in mind that delegates are really variables pointing to methods, it isn't hard to make the final connection between .NET events and newspaper subscriptions. The way events are implemented is via a list of delegates, to/from which items may be added and removed. This is really just like a newspaper publisher's list of subscribers, each of whom receives a copy when the newspapers are distributed every morning.
Anyway, hopefully this has helped you get your head around the Observer pattern somewhat. There are many other kinds of implementations of this pattern, of course, but .NET events is a paradigm with which the majority of .NET developers are familiar, so I think it's a good starting point from which to develop one's understanding.

Develop Reference

C# (C-Sharp) is a programming language developed by Microsoft that runs on the .NET Framework.