I was looking at the Proxy Pattern, and to me it seems an awful lot like the Decorator, Adaptor, and Bridge Patterns. Am I misunderstanding something? What's the difference? Why would I use the proxy pattern veses the others? How have you used them in the past in real world projects?
I use it quite often when consuming web services. The Proxy Pattern should probably be renamed to something more pragmatic, like 'Wrapper Pattern". I also have a library that is a Proxy to MS Excel. It makes it very easy to automate Excel, without having to worry about background details such as what version is installed (if any).
They are quite similar, and I the lines between them are quite gray. I would suggest you read the entries in the c2 wiki about both of them;
http://c2.com/cgi/wiki?ProxyPattern http://c2.com/cgi/wiki?DecoratorPattern
The entries and discussions there are quite extensive, and they also link to other relevant articles. By the way, the c2 wiki is excellent when wondering about the neuances between different patterns.
To sum the C2 entries up, I would say a Decorator adds/changes behavior, but a proxy has more to do with access control (lazy instantiation, remote access, security etc). But like I said, the lines between them are gray, and I see references to proxies that could easily be viewed as decorators and vice versa.
Hope this helps.
Regards, Bent André Solheim
Proxy, Decorator, Adapter, and Bridge are all variations on "wrapping" a class. But their uses are different.
Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you're calling a remote service, or control access to the object.
Decorator is also called "Smart Proxy." This is used when you want to add functionality to an object, but not by extending that object's type. This allows you to do so at runtime.
Adapter is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface.
Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you're not adapting to some legacy or third-party code, you're the designer of all the code but you need to be able to swap out different implementations.
Facade is a higher-level (read: simpler) interface to a subsystem of one or more classes. Think of Facade as a sort of container for other objects, as opposed to simply a wrapper.
There's a great deal of overlap in many of the GoF patterns. They're all build on the power of polymorphism and sometimes only really differ in intent. (strategy vs state)
My understanding of patterns increased 100 fold after reading Head First Design Patterns.
I highly recommend it!