Geeks With Blogs
Greg Young Greg.ToString()

I am leaning towards re-implementing my dynamic proxy as open source (BSD license of course).

As with any open source project my biggest problem was not a shortage of ideas but in finding a really cool name that I could also have the domain for :) In this process I have come across something odd. In AOP Ido not actually use dynamic proxies! I use Dynamic Decorators.







  • The Proxy Pattern is similar in structure to the Decorator Pattern.
    • Both describe how to provide a level of indirection to an object.
    • Both keep a reference to another object to which requests are forwarded.
    • The difference again is the intent.
  • Like the Decorator, the Proxy composes an object and provides an identical interface to clients.
  • Unlike the Decorator, the Proxy
    • Does not attach and detach properties dynamically
    • Is not designed for recursive composition.
  • The intent of the Proxy is to stand in for a subject when it is inconvenient or undesirable to access the subject directly.
    • Ie the subject may reside on a remote machine or have restricted access.
  • In the Proxy pattern, the subject defines the key functionality and the proxy provides or refuses access to it.
  • In the Decorator, the component provides a subset of the functionality and the decorators provide the rest.
  • The Decorator addresses the situation where the objects totally functionality may need to be determined at run-time.
  • The Proxy focuses on the relationship between the proxy and its subject which can be expressed statically.
  • The differences between the Proxy and Decorator Pattern are significant but that does not mean they can not be combined.
    • A Proxy-decorator might add functionality to a proxy
    • A Decorator-proxy might embellish a remote object.


It sure seems to me that what we are actually using is a dynamic decorator not a dynamic proxy in the first place. I mean we are explicitly adding functionality to the object (aspects) at run time.

I think the key item in the list is

“The Decorator addresses the situation where the objects totally functionality may need to be determined at run-time.”

This is absolutely the case when we are dealing with aspects.

One major problem I see with using true decorators is the subject setter, I currently don't use it and I cannot in my mind come with anyway that I could possible use it.

In order for me to be able to use an instance setter I would need to cast the proxy to another type in order to be able to access it. This in my mind removes the transparency of the proxy itself. I should never have code that does something along the lines of

Foo foo = new Foo();
IProxy fooproxy = ProxyFactory.CreateProxy(typeof(Foo));
because I am now readily aware that I am not dealing with the original type. I preferred instead to make my objects immutable as I never really saw them being reused anyways.
That being said, because I am not using an instance setter, am I actually using a decorator pattern?! One of the key points of the decorator pattern is the instance setter that allows for multiple subjects through out the lifespan of the instance. Am I actually generating some weird form of hybrid between a proxy and a decorater (a decoroxy perhaps) .
Anyways I was able to register the domain and .net so I am happy :)
I am considerring some other changes to the ways I was doing things as I move things to OS. One thought that I have been mulling over for quite some time now is that the dynamic aggregation part used in mixins is useful on its own, perhaps I should actually pull that out into its own factory and pull the decoroxying out into its own factory then provide a service which combines the two.
    More reusable
    Clearer / vastly simplifies the code
    Better seperation of concerns
    Two types instead of one
    Probably a bit slower
Posted on Tuesday, January 31, 2006 12:20 PM AOP | Back to top

Comments on this post: Decoroxy - Dynamic Decorator

# re: Decoroxy - Dynamic Decorator
Requesting Gravatar...
Left by Anonymous on Aug 13, 2009 6:10 AM

Your comment:
 (will show your gravatar)

Copyright © Greg Young | Powered by: