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.
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:
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