Third Shelf

A proxy aspect approach is one of many approaches in Aspect Oriented Programming. The general idea behind AOP is to deal with the problem of cross-cutting concerns.

Let’s say you want to check the permissions of a user before executing a method (this is the type of aspect that we want to apply to our object). You can appreciate that when a system is beyond “Hello World!” that this can turn out to be quite a thing to remember and apply on every method.

To solve this problem we would need to inject this call into the methods where this security check needs to be done. This can be done in various ways, such as creating a proxy at runtime that performs the check or alter the assemblies with another tool after compilation.

Over the next couple of weeks, I will walk you through the requirements, design and construction of one of these approaches that I call; you guessed it; the proxy aspect approach.

At a high level, the idea is to create a proxy for every object that needs to have certain functionality executed as soon as, for example, a method is entered or a property is changed. In effect, the object will have multiple layers or proxies to which all calls; that are intended for the target instance; are directed.

One proxy is created for each aspect that is applied, and every proxy object carries a reference to the instance of the target instance. This target instance can either be another proxy object or the final domain object, say.

When the call is made to the proxy object it will execute the aspect code and then forward the call to the target instance. If the target instance is a proxy, the same process will happen again until it reaches the inner most target instance where the call is finally handled. If there are results that need to be returned, it passes back up through every proxy until it reaches the original caller.

Next, we’ll have a look at the requirements.