设计模式：选择哪一个？

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?

PS: 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

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.

Answer 3

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 4

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 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.