최근에 AOP(Aspected Oriented Programming) 관련해서 과제 연구 주제를 찾고 있었는데, 흥미롭게도 AOP의 어플리케이션 중에 하나가 DBC(Design By Contract)의 구현이다. 사실 아직 AOP 초보인지라, 사용 사례를 로깅이나 보안 쪽 정도 밖에 생각 못하고 있었는데, DBC의 Pre/Post-Condition과 Invariant도 business logic과는 별개의 separate concern으로 생각할 수 있었다.
실제로 Developers@Work에 실린
Contract enforcement with AOP를 보면 AspectJ를 이용해 자바에서 DBC를 구현하는 간단한 예를 보여주고 있다. 간단하게 생각하면 Precondition는 메쏘드 실행 전에, Postcondition는 메쏘드 실행 후에 불러주고, Invariant는 실행 전후로 확인하면 되므로,
<
Contract enforcement with AOP에서 발췌한 코드>
public abstract aspect AbstractContract
{
/**
* Define the pointcut to apply the contract checking
* MUST CONTAIN A METHOD CALL
*/
public abstract pointcut targetPointcut();
/**
* Define the ContractManager interface implementor to be used
*/
public abstract ContractManager getContractManager();
/**
* Perform the logic necessary to perform contract checking
*/
Object around(): targetPointcut()
{
ContractManager cManager = getContractManager();
System.out.println("Checking contract using:" +
cManager.getClass().getName());
if (cManager!=null)
{
System.out.println("Performing initial invariants check");
cManager.checkInvariants(thisJoinPoint.getTarget());
}
if (cManager!=null)
{
System.out.println("Performing pre-conditions check");
cManager.checkPreConditions(thisJoinPoint.getTarget(), thisJoinPoint.getArgs());
}
Object obj = proceed();
if (cManager!=null)
{
System.out.println("Performing post conditions check");
cManager.checkPostConditions(thisJoinPoint.getTarget(),
obj, thisJoinPoint.getArgs());
}
if (cManager!=null)
{
System.out.println("Performing final invariants check");
cManager.checkInvariants(thisJoinPoint.getTarget());
}
return obj;
}
}
위 코드의 예처럼 Template 메쏘드를 사용하면 일반적인 Contract enforcement가 구현 가능하다. 따라서 사용자는 targetPointcut을 override해서 어디에 삽입할 것인지를 정하고, ContractManager를 통해 실제 구현을 집어넣을 수 있다.
이 아이디어를 발전시켜서 실제로 DBC 구현에 Aspect를 사용한 예가
Contract4J이다. 해당 프로젝트 홈페이지에 나온 AOP와 DBC의 관계는 다음과 같다.
Design by Contract and Aspect-Oriented Programming
So what does DbC have to do with Aspect-Oriented Programming (AOP)? On the one hand, the component's contract is an essential part of the complete, logical component specification that clients must support. For example, an interface for a bank account may have a contract requirement that all methods that return a balance must always return a non-negative number (ignoring overdraft features). However, in practical terms, contracts often include implementation concerns that may have little relationship to the domain logic of the application. For example, the code implementing the bank account may prohibit passing null values as method parameters.
For both types of contract details, AOP allows us to specify the details with sufficient "proximity" to the interface so that clients can see the constraints and AOP gives us an elegant way of testing the constraints at runtime without cluttering the code with logic to run the tests and handle failures.
More generally, AOP is a new approach to modularizing "concerns" that need to be handled by a component, but which tend to obscure the main logic of the component, often compromising clarity, maintainability, reusability, etc. For example, modern web and enterprise applications typically must support secure access, transactional behavior, persistence of data, and mundane support issues like logging. Without AOP, the code for these "concerns" gets mixed in with the domain logic, thereby cluttering the code and diminishing the "ilities" we all strive for. AOP keeps these concerns in separate modules and provides powerful facilities for "injecting" the concern behavior in the specific execution points where needed. Contract4J5 uses AOP techniques to find the contract specifications and test them at runtime at the appropriate execution points.
AOP is a good approach to supporting DbC because it permits DbC concerns to be managed in a modular and minimally-intrusive way, without cluttering application logic, while still allowing the contracts to be integrated into the runtime environment for development and testing. Contract4J5 uses the best-known AOP language, AspectJ, to support DbC for Java.
For more information on AOP, see the references below.
요약하면 application logic에서 DBC를 분리해 @pre ( ), @post ( ) 같은 방식으로 써준다. 이렇게 하면 DBC 관련 코드와 application code가 뒤섞여서 생기는 문제를 해결할 수 있다. 하지만 실제 실행 시에 해당 코드를 메쏘드 앞 뒤로 자연스럽게 껴 넣을 수 있기 때문에 AOP가 DBC 구현에 좋다.
