通过回调或事件引发处理多种消息类型的设计模式

Question

I read about Strategy pattern in this question. I ran into a problem when wrapping all this in MessageProcessor, and cannot give the user of my class any strong typed callback.

public class MessageProcessor
{
    private IMessageProcessing Processing {get; set;} // a processing strategy

    public void ProcessMessage(HubMessage message) //SignalR data message
    {
        ContentBase content = MessageProcessingBase.GetMessageContent(message); //just get content object from message

        if (content is DocumentFile) //this content holds info about file to download
               Processing = new DocumentFileProcessing();//implementation of IMessageProcessing strategy interface

        Processing.ProcessMessage(message); //here a file is being downloaded and I want to raise event or call a callback method to inform a client (this class's caller) about a path of downloaded file
    }
}

I tried to explain my problem in code comments. Is it possible to give a user of my DLL any typed callback if I only provide a MessageProcessor class that determines a type of message and calls typed strategy class? Or I should leave the user to write strategy determination code (in this case MessageProcessor)?

I know I can have event to call when processing is done, but that event would be in base MessageProcessing class, so it cannot have typed event arguments. EDIT I provided some more code, to help understand what I need.

//lib code
public class Message
{
    public string From { get; set; }
    public string To { get; set; }
    public MessageContentBase Conent{get;set;}
}
public class MessageContentBase
{
    public string Note{get; set;}
}
public class DocumentFile: MessageContentBase
{
    public string FilePath { get; set; }
}
public abstract class MessageProcessing
{
    public abstract void ProcessMessage(Message message);
}
public class DocumentFileMessageProcessing:MessageProcessing
{
    public override void ProcessMessage(Message message)
    {
        DocumentFile df = message.Conent as DocumentFile;
        //1. download file
        //2. raise event or do callback in client code with parameter df.FilePath
    }
}
public class SomeOtherProcessing : MessageProcessing
{
    public override void ProcessMessage(Message message)
    {
        MessageContentBase content = message.Conent;
        //log.WriteLine("Message was from " + message.From);
    }
}
public class MessageProcessor
{
    MessageProcessing processing;
    public void ProcessMessage(Message message)
    {
        if (message.Conent is DocumentFile)
            processing = new DocumentFileMessageProcessing();
        //else if, else if.....
        processing.ProcessMessage(message);
    }
}
// end lib code

public class Program //client code
{
    public static void Main(string[] args)
    {
        Message m = new Message();
        MessageProcessor mp = new MessageProcessor();
        mp.ProcessMessage(m);
        // need something to call return-result-type-dependent post processing code
    }
}

Answer 1

It is not strictly necessary to use an interface for the strategy pattern. You can declare an abstract class MessageProcessing and a method ProcessMessage which uses the template pattern. In his logic, the code executes internal processing method and then raises an event.

Something like this:

internal abstract class MessageProcessing {
  // TODO: declare event variable
  abstract string ProcessInternalMessage(HubMessage message);

  void ProcessMessage(HubMessage message) {
    // Here he call the ProcessInternalMessage which returns
    // the path. Depending on the derived class the logic or the processor.
    string path = this.ProcessInternalMessage(message);
    // here we raise event with the path in the parameters
  }
}

As you can see, the ProcessMessage acts as a template. This means that it has a logic flow (very simple, just two lines of code) in which first executes an abstract method. After that, it raise the event.

The abstract method must be implemented for each class that derives from this class. This method has the logic of your classes that implement your current interface.

With this, you only execute methods on the abstraction, and internally the event is raised.

Is that what you need?

Greetings!

Answer 2

I ran into a problem when wrapping all this in MessageProcessor, and cannot give the user of my class any strong typed callback.

The problem here is that MessageProcessor creates all MessageProcessing instances.

Or I should leave the user to write strategy determination code (in this case MessageProcessor)?

The solution is to write a MessageProcessor , that can be configured by the user by registering MessageProcessing instances.

Is it possible to give a user of my DLL any typed callback if I only provide a MessageProcessor class that determines a type of message and calls typed strategy class?

Configuration phase:

1. The user creates a MessageProcessor instance provided by the library
2. The user creates all necessary MessageProcessings , provided by the library or by the user, registers callbacks and subscribes to MessageProcessings events
3. The user registers all created MessageProcessings in the MessageProcessor

Message processing phase:

1. The user calls the configured MessageProcessor to process a Message
2. The configured MessageProcessor looks though registered MessageProcessings for a MessageProcessing , capable of processing the Message
3. The MessageProcessor passes the Message to the found MessageProcessing
4. The MessageProcessing makes all necessary callbacks and raises events to interact with the user

Hint:

To check if MessageProcessing is capable of processing a Message add abstract bool CanProcess(Message) method to the base MessageProcessing class and override it in concrete MessageProcessing classes.