CategoryRefactoring /RefactoringLanguage - an instance of AspectOrientedRefactoring

See "Extract concurrency control" for an example of extracting read and write locks, with corresponding try-catch-finally blocks, into using AspectOrientedProgramming techniques.
* http://www.theserverside.com/articles/article.tss?l=AspectOrientedRefactoringPart2

From this:
	public <type> <methodName>(<parameters>) {
	try {
		_lock.writeLock().acquire();
		''< business logic here >'' 
	} catch (InterruptedException ex) {
		throw new InterruptedRuntimeException(ex);
	} finally {
		_lock.writeLock().release();
	}
	}
To this:
	public <type> <methodName>(<parameters>) {
	''< business logic here >'' 
	}
and a pointcut to define which methods need which kinds of locks, and reusable definitions of how to aquire and release locks:
	before() : writeOperations() {
	_lock.writeLock().acquire();
	}
	after() : writeOperations() {
	_lock.writeLock().release();
	}
For Java/AspectJ definitions not in-line in the article, see:
* 'http://www.theserverside.com/articles/content/AspectOrientedRefactoringPart2/ReadWriteLockSynchronizationAspect.java.html'

----
The first code is bad, admittedly, but in any normal program the concurrency control would be implemented via delegation, as a decorator or via message queues.  How does aspect orientation help in that situation?  The only effects I see are negative (hidden dependencies, for example).

Also, where is _lock defined in the AspectJ version?

''Generally aspects inject the lock object into the business object (inter-type field declaration) without polluting namespace of the business logic or other aspects, like this:''

	private final Lock BusinessLogicClass._lock=new ReentrantLock();

----
CategoryRefactoring