+972 52-548-6969
Design patterns in the test of timeProxy
A proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate.
Proxies are just about everywhere. Whenever you use NHibernate, WCF or Remoting – you are using proxies. In fact, proxies are such a success that they are literally baked into both the language and the platform. In .NET we have TransparentProxy and in Java has java.lang.reflect.Proxy.
At any rate, proxies are really useful, especially when you think about dynamic proxies. I am far less fond of static proxies, although we use them as well. Dynamic proxies are quite useful to add behavior, especially cross cutting behavior, at very little cost.
That said, one of the major issues that arises from using proxies is an inherit assumptions that the proxy is the same as its target. Commonly you see this happening with remote proxies, where it isn’t obvious that actually making the call is expensive as hell.
Proxies also tend to be used mostly for the infrastructure of your application, rather than for actual application code. In particular, business logic, rather than cross cutting concerns, is really hard to figure out / debug when you have it spread around in proxies.
Recommendation: Use it for infrastructure or cross cutting concerns. Try doing so using dynamic proxies, rather than by generating proxies by hand. Avoid putting business logic there and be aware that by using proxies you are hiding what is going on (that is pretty much the point), so doing non obvious things should be avoided.
More posts in "Design patterns in the test of time" series:
- (21 Jan 2013) Mediator
- (18 Jan 2013) Iterator
- (17 Jan 2013) Interpreter
- (21 Nov 2012) Command, Redux
- (19 Nov 2012) Command
- (16 Nov 2012) Chain of responsibility
- (15 Nov 2012) Proxy
- (14 Nov 2012) Flyweight
- (09 Nov 2012) Façade
- (07 Nov 2012) Decorator
- (05 Nov 2012) Composite
- (02 Nov 2012) Bridge
- (01 Nov 2012) Adapter
- (31 Oct 2012) Singleton
- (29 Oct 2012) Prototype
- (26 Oct 2012) Factory Method
- (25 Oct 2012) Builder
- (24 Oct 2012) A modern alternative to Abstract Factory–filtered dependencies
- (23 Oct 2012) Abstract Factory
Comments
Hi, let me mention here one of my favourite classes - TypeDelegator. http://msdn.microsoft.com/en-us/library/system.reflection.typedelegator.aspx
~proxy on the type metadata level (used in scenarios where TypeProvider comes into picture). Practically where any kind of string metadata is used for binding (WWF, WPF, SL typically) it's good to know.
Also wanted to mention the lack of class loader (and facilities around it) on managed level (compared to Java which has it). In my view this is why dynamic proxies are used for interception, behavior injection.
With functional patterns it could be done on the design level though (these are typically considered weird pollution later :-D )
Cheers, Miklos
Proxies are also very useful in user interface code. Let's say you have a WPF application that pulls data from IMDB and lists movies with their posters. As you scroll the list the posters will load dynamically as they become visible. The simplest way to implement this is to use a proxy for the image and call some method (or respond to some event) as the list scrolls and the poster becomes visible. The proxy should mimic the interface of an actual image, more or less.
Wake me up on when this pattern talk ends... YAAAAAWN
"Avoid putting business logic there" definitely true: I did such a mistake in the past and was a pain until refactor.
Comment preview