C# – “Handler” pattern


I've come across a design pattern that's been referred to as a "Handler Pattern," but I can't find any real references to this pattern anywhere. It's basically just a one-method interface that allows you to easily extend the functionality on the back-end without making clients recompile. Might be useful for a web-service that has to handle many different types of requests. Here's an example:

public interface IHandler
    IDictionary<string, string> Handle(IDictionary<string, string> args);

The args would typically include one key like "Action" with a value that tells the implmentation what to do. Additional args can be passed in to give the impl more information. The impl then passes back an arbitrary list of args that the client "should" understand.

Is this an anti-pattern, or maybe another pattern in disguise? Is this type of design recommended?

A little more info: The way I've seen this implemented, the "root" Handler would act as a dispatcher to other concrete handlers (maybe?). The root handler has a "HandlerResolver," which decides which concrete handler should get the message based on it's contents. Maybe it's actually like a "dispatcher" pattern, although I don't know if that's really a pattern either. I guess it could also have a chain-of-responsibility pattern in the root, that allows you to chain together a bunch of concrete handlers, then let them decide which one will handle it.

Best Solution

it's the OOP way to do closures on languages that doesn't have them. it didn't have a 'pattern' name because on functional languages it's the obvious way to work. on OOP languages, OTOH, you have to do some work, so it seems a nameable idiom. 'Handler' sounds right.

(it's not a singleton, BTW)