A few months ago I finished reading Pattern Oriented Software Architecture Volume 1. This was an absolutely awesome book. Just about all the patterns in the book target stateful applications, which was just what I was looking for. Some of my favorite patterns were "Pipes and Filters", "Proxy", and "Command Processor".
The book starts off with a great discussion on what a pattern is, what makes a pattern, and why they are useful. Then it goes through a catalog of patterns and offers examples for each. Then it goes on to discuss pattern systems, the patterns community and where patterns are going.
The book broke down the proxy pattern in to several different types of proxies. They are:
- Remote Proxy: Clients of remote components should be sheilded from network addresses and inter-process communication protocols.
- Protection Proxy: Components must be protected from unauthorized access.
- Cache Proxy: Multiple local clients can share results from remote components.
- Synchronization Proxy: Multiple simultaneous accesses to a component must be synchronized.
- Counting Proxy: Accidental deletion of components must be prevented or usage statistics collected.
- Virtual Proxy: Processing or loading a component is costly, while partial information about the component may be sufficient.
- Firewall Proxy: Local clients should be protected from the outside world.
In the .NET realm the Castle Dynamic Proxy project makes it pretty darn easy to implement some of the different types of pattern proxies.
The book described 2 major liabilities of the Proxy pattern. It is less efficient due to the indirection, and it can be overkill. Although the proxy pattern is very much like the decorator pattern the major difference between the two is their intent. The decorator adds functionality, and the proxy frees the original from very specific housekeeping code.
Separates the request for a services from its execution. A command processor component manages requests as separate objects, schedules their execution, and provides additional services such as the storing of request objects for later undo.
Let's take a look at an asynchronous command processor that I wrote quite some time ago. AsynchronousCommandProcessor
The way it works is that one thread is placing commands to execute in to a queue, and another thread is processing the commands waiting on the queue. This is useful for keeping the user interface thread responsive, and allows for scheduling long running background tasks.
To see an example of an application using this technique check out my Mo Money application.
If you develop Windows Forms or WPF based applications than I highly recommend that you pick up this book. It is excellent!