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();