Design pattern: Which one to choose?

Question

First of all this is all just concept, I have no actual programming done yet. This is the situation:

I have a Class A which uses the Filesystemwatcher to watch for changes in a folder. (using events)

Then I have a 'Collection Class' B which has a List of A's.

Now what I want to happen is as follows,

A Change happens with the folder, A detects this and sends a message to B, B transfers this message to Class C. Class C then begins a method which updates the GUI. (What changes were made etc..)

Now I have searched and thought pretty long on this subject, but can't find the solution. But, I have found 2 design patterns:

Mediator and Observer.

As a software engineer I have to some degree once made the Observer pattern so I know some of the basics there.

Now to my questions:

• What pattern is best to use in this situation?

• How do I make it so that B transmits the message to C?

• Do I need custom Events / delegates to make A transmit data to B or can I use the Built-in events?

P.S.: I'm using C# as my programming language.

edit: Thanks to everyone for helping me, votes are on the way.

Answer 1

Observer is fine. You can either make C an observer of B (so that B transmits events from A's to C), or make C listen directly to A's (this is probably the worse choice as it creates a direct dependency from C to A).

Note that this basically a variation of Model-View-Controller, where A are the models and C the view. Now whether or not B would make a proper controller depends largely on its responsibilities: if it is only a collection of A's, it is not a good idea to make it a controller. Without more details about your classes and responsibilities, it is hard to say more.

Answer 2

You can think about chain of responsibility where certain task is dependent of series of subtask

As in ur case ,you can use event ands delegate which is .net implement of observer.

Answer 3

I ended up using nearly the same scenario for a demo of Reactive Extensions.

RX is a formalism of the observer pattern - but generalized to be the inverse/dual of the iterator pattern.

Details and source code - http://code.msdn.microsoft.com/RxDemos

Answer 4

public class A
{
    public event FileSystemEventHandler FileSystemEvent;

    A()
    {
        this.fsw = new FileSystemWatcher();
        this.fsw.OnFileSystemEvent += (sender, e) => 
            { if(this.FileSystemEvent != null) 
                 this.FileSystemEvent(this,e); };
    }
}

public class B
{
    public event FileSystemEventHandler FileSystemEvent;

    B()
    {
        this.RegisterAClasses();
        foreach( A item in this.AClasses )
             item.FileSystemEvent += (sender, e) =>
                 { if(this.FileSystemEvent != null) 
                      this.FileSystemEvent(sender, e) };
    }
}

public class C
{
    C()
    {
        this.RegisterBClass();
        this.BClass.FileSystemEvent += (sender, e) => 
             { /* update gui... */ };
    }
}

(psuedo code...)

Answer 5

Observer is a proper pattern here. I don't understant why u said this:

Then I have a 'Collection Class' B which has a List of A's.

because, to Observer pattern, I think B should observe A, so in class A, there some Bs for listen an event fire by A(a folder be changed). Similarly, class C should observe B, so in class B there are some objects C register for listening event fire by B. The neccesary for a custom event or build in event depend on you class. If its .NET's class, I think there's some event for notifying a change in a dicrectory. If not, you should write your own events / delegate.

Answer 6

For what I make out of this, there are a bunch of 'A' objects that pass on events asynchronously to a single B, that in turn passes that info on to a single C.

So, let B contain and observe the A's and let C observe B.

If you got a lot of A's, you might want to have B do some gathering/caching of A's events before notifying C. Especially if C is serving a user interface.

Side note: don't over-patternize your software. Try to be open-minded and always find the simplest and easiest solution. Only use a pattern where its appropriate, and not just because it's possible. I have seen many people throwing in proxies, command-patterns, observers, MVC's, mediators etc, where they were unneccesary.

Good luck.