2009년 12월 13일 일요일

AOP(aspect-oriented programming) 개념-2

대부분의 기술이 그러하듯, AOP(aspect-oriented programming)에도 역시 AOP(aspect-oriented programming)만의 전문 용어가 존재한다.
AOP에서 가장 중요한 용오로는 어드바이스(advice), 포인트컷(pointcut), 조인포인트(joinpoint)이며, AOP에서 이야기하는 핵심 용어들을 알아보자.


어드바이스(advice)
Aspect가 해야 할 작업을 AOP 용어로 어드바이스(advice)라고 하며, Aspect가 '무엇'을 '언제' 할지를 정의.
즉, 어드바이스(advice)는 Aspect가 해야 하는 작업과 언제 그 작업을 수행해야 하는지를 정의하는 것이다. 어드바이스(advice)에서 말하는 '언제'는 해당 작업이 메소드 호출 이전인지 이후인지, 아니면 이전/이후 모두인지, 이도저도 아니면 메소드에서 예외가 던져졌을 때만 적용되는 것인지를 의미한다.


조인포인트(joinpoint)
어드바이스(advice)를 적용할 수 있는 곳을 조인포인트(joinpoint)라고 함.
조인포인트(joinpoint)는 애플리케이션 실행에 Aspect를 끼워 넣을 수 있는 지점을 말함.
이렇게 끼워 넣을 수 있는 지점으로는 메소드 호출 지점, 예외 발생 지점, 필드 값 수정 지점 등이 있으며, 이러한 지점에서 Aspect 코드가 삽입되어 애플리케이션의 정상 흐름에 추가 작업을 더할 수 있게 된다.


포인터컷(pointcut)
포인터컷(pointcut)은 Aspect가 어드바이스할 조인포인트의 영역을 좁히는 일을 한다. Aspect가 무엇을 언제 할 것이냐를 정의하는 것이 어드바이스라면, 포인트컷은 '어디서' 하는 것인지를 정의한다.
포인트컷을 지정하는 방법은 클래스나 메소드명을 직접 사용하는 것이지만, 매칭 패턴을 나타내는 정규 표현식(regular expression)으로 나타내는 방법도 있다. 다른 AOP 프레임워크 중에는 동적 포인트컷을 사용할 수 있는 것도 있다. 동적 포인트컷은 메소드 인자 값처럼 실행시간(runtime)에나 얻을 수 있는 정보를 이용해서 어드바이스 적용 여부를 결정할 수 있게 해주기도 한다.


Aspect
어드바이스와 포인트컷을 합친 것을 말한다. 두 가지 정보가 합쳐지면 Aspect가 무엇을 언제 어디서 할지 정의할 수 있게 된다.


인트로덕션(introduction)
기존 클래스에 코드 변경 없이도 새 메소드나 멤버 변수를 추가하는 기능.


타깃(target)
어드바이스가 적용될 객체를 타깃(target)이라고 한다. 직접 작성한 객체 또는 서드파티 객체 모두가 타깃이 될 수 있다. AOP에서의 타깃 객체는 다른 주제 또는 관심사항은 고려할 필요 없이 오직 자신의 주요 관심사항에만 집중 할 수 있게 된다.


프록시(proxy)
스프링 AOP에서 프록시(proxy)는 어드바이스를 타깃 객체에 적용하면 생성되는 객체다.


위빙(weaving)
타깃 객체에 Aspect를 적용해서 새로운 프록시 객체를 생성하는 절차를 위빙(weaving)이라고 한다.

  • 컴파일 시간(compile time) - 타깃 클래스가 컴파일될 때 Aspect가 위빙되며 별도의 컴파일러가 필요. AspectJ의 위빙 컴파일러는 이러한 목적으로 사용.
  • 클래스로드 시간(Classload time) - 클래스가 JVM에 적재될 때 Aspect가 위빙된다. 이렇게 하려면 애플리케이션에서 사용되기 전에 타깃 클래스의 바이트코드를 인핸스(enhance)하는 특별한 ClassLoader가 필요. AspectJ의 로드시간 위빙(LTW:load-time weaving) 기능을 사용하면 클래스로드시간에 위빙된다.
  • 실행 시간(runtime) - 애플리케이션 실행 중에 Aspect가 위빙된다. 보통 타깃 객체에 호출을 위임하는 구조의 프록시 객체를, 위빙 중에 APO 컨테이너가 동적으로 만들어 낸다. 스프링 자체 AOP의 Aspect는 실행시간 위빙을 사용


AOP(aspect-oriented programming) 개념-1

근래에 들어 AOP(aspect-oriented programming)에 관한 내용을 많이 접하고 있을 것이다. 아니 이미 익숙한 용어가 되어져 있는 것 같다.


과거에 프로그램을 개발하다 보면 주요 로직 외에도 로깅(logging), 권한 등등의 처리를 위해서 각 업무상의 주요 로직 내에 해당 기능을 추가로 수행하기 위한 코드가 삽입되어져 왔었다.
애플리케이션 내의 여러 부분에 걸쳐 있는 기능을 시스템 공통 기능이라 보고, 이를 가리켜서 AOP 용어로는 횡단관심사(cross-cutting concerns)라고도 한다.
횡단관심사는 한 애플리케이션에서 여러 부분에 영향을 주는 기능이라고 할 수 있다.
아래의 그림처럼 특정 클래스 내의 메소드 내부에 시스템 공통 기능을 수행할 수 있는 메소드 호출들을 함으로써 주요 업무로직 외에 공통 기능도 추가됨으로써 개발자의 코드 작성 및 유지보수가 어렵웠었다.







이러한 부분을 개선하기위한 방법으로 나타난 AOP는 클래스의 상속 및 위임을 통해서 구현하지 못하는 영역들을 아주 자연스럽게 해결해주는 방법이 아닐 수 없었다.
Aspect 지향 프로그래밍(AOP: aspect-oriented programming)은 이러한 횡단 관심사를 애플리케이션의 업무 로직과는 분리하기 위한 것이다. AOP의 목적은 횡단관심사와 이에 영향을 받는 객체간의 결합도를 떨어뜨리기 위해 횡단관심사를 모듈화 하는데 있다.
즉, AOP에서는 횡단관심사를 Aspect라는 특별한 객체로 모듈화 하며, AOP가 다른 기법과 달리 차별화 되는 장점은 2가지가 있다.

  1. 전체 코드 베이스에 흩어져 있는 관심사항이 하나의 장소로 응집
  2. 서비스 모듈이 자신의 주요 관심사항(또는 핵심기능, 업모로직 등)에 대한 코드만 포함하고 그 외의 관심사항은 모두 Aspect로 옮겨져서 코드가 깔끔해짐

이러한 AOP의 여러 장점들로 인해 주목을 받고 있으며, OOP에서 구현하지 못하는 아니 구현하기 힘든 사항들을 보완하는 하나의 기술로 보면 될 것 같다.