AOP 등장
C 언어에서 시작된 절차적 프로그래밍을 걸쳐 유지보수성과 확장성을 가지는 객체지향(OOP)적 프로그래밍을 현재 밟고 있다.
현재 객체지향적인 프로그래밍을 지향하면서 개발자들은 좀 더 편리하고 유지보수가 편한 방법을 찾게 되었고... 그에 맞춰 등장한것이 AOP 관점 지향 프로그래밍이다...
공통적인 쓰이는 관심사들... 즉 로깅, 트랜잭션 처리, 통계 처리, 권한 처리등 모든 모듈에서 공통적으로 쓰이는 코드들.. 하나의 클래스를 완성하기 위해서 여러 군데 동일한 코드를 복사해서 갖다붙이는 코드들을 공통 관심사라고 볼수 있다. AOP 는 이 공통 관심사를 좀더 유연하게 중복되지 않게 처리하기 위한 OOP 의 보완적인 프로그래밍 구조를 지원하기 위해 탄생하게 되었다.
AOP 개념
Aspect Oriented Programming.. 관점 지향 프로그래밍...
어플리케이션은 다향한 공통 기능을 필요로 한다. 어플리케이션에서 전반적으로 걸쳐 적용되는 공통 기능들은 특정 모듈들에서만 적용 되는게 아니다. 이런 공통 기능들을 공통 관심 사항(cross-cutting concern) 으로 표현하고 공통 관심 사항을 제외한 핵심 로직을 핵심 관심 사항(core concern) 으로 표현한다. AOP는 이런 공통 관심 사항과 핵심 관심 사항을 관점적으로 분리해서 보자는 의미이다.
아래와 같이...
기존 프로그래밍 구조에서 Class A에 대해 로깅 -> 핵심로직 처리 -> 통계처리의 종단적인 관점을
Class A 와 B 와 C 의 공통적인 관심사인 로깅과 통계처리를 횡단적인 관심사로 보고 Class A와 B 와 C는 핵심 로직만 구현 하고 공통적인 관심사인 로깅과 통계처리는 모든 클래스에 공통적인 소스로 뽑아내어 중복 제거와 뛰어난 유지보수성을 보장하게 해준다.
만약 로깅 -> 핵심로직 처리 -> 통계처리를 종단 적인 관점으로 봤을때 로깅에 대해 로깅 정책이 변경 되어 수정이 필요하게 된다면 모든 클래스를 까서 수정 후 테스트를 진행 해야 된다. 위와 같이 클래스 세개만 수정 해야 된다만 모를까 만약 수십개의 클래스가 공통된 로깅 처리를 하고 있다면 수십개의 클래스를 열어서 한줄 고치는 작업을 진행 해야 되지만 AOP 가 적용된 소스라면 로깅을 처리하는 공통 관심사의 소스 코드만 수정하면 변경된 로깅 정책을 적용 시킬수 있다.
AOP의 장점은..
첫째, 중복되는 코드 제거...
둘째, 첫째에 따른 코드의 간결성
셋째, 둘째에 따른 생산성 향상
넷째, 공통기능 빠진 클래스는 재사용성 증가
다섯째, 첫째부터 넷째까지의 결과인 유지보수성 향상
AOP 용어
JoinPoint : 공통 관심 기능 삽입되어 동작하는 특정 위치를 말한다. 메서드 호출, 필드 값 변경등 이에 해당
Advice : 언제 공통 관심 기능을 핵심 로직에 적용 할지 정의한다. 메소드를 호출하기 전/후, 트랜잭션을 시작하기 전..
PointCut : JoinPoint 의 부분집합.. 실제 Advice 가 적용되는 JoinPoint 를 의미한다.
Weaving : 포인트컷에 의해 결정된 조인포인트에 지정된 어드바이스를 삽입하는 것을 말한다.
즉 핵심로직코드에 공통코드를 삽입되는 행위...
AOP Weaving 방식
핵심로직 코드에 공통 코드가 삽입되는 행위를 Weaving 이라고 한다.
AOP 툴인 AspectJ , Spring AOP, AspectWerkz 등은 각각 다른 Weaving 을 사용하며 현재 세가지 방식이 존재 한다.
첫째. 컴파일시 Weaving
대표적인 AOP 지원툴인 AspectJ 가 사용하는 방식이다. 일반 자바 컴파일러가 아닌 AspectJ 가 지원하는 컴파일러를 통해 컴파일시 핵심로직을 구현한 소스에 알맞은 위치에 공통 기능 코드를 삽입하게 된다. 초기에는 AspectJ가 지원하는 컴파일러를 통해 컴파일을 해야 한다는 제약에 따라 포인트컷에 변경에 따른 관련된 모든 클래스를 매번 재컴파일을 진행해야 되는 문제점이 있었지만 최근 IDE 툴이 지원되면서 대표적인 AOP 지원툴로 자리매김 하였다.
둘째, 클래스 로딩시 Weaving
JVM이 클래스를 로딩할 때 클래스 정보를 변경할수 있는 에이전트를 제공함으로써 클래스의 바이너리 정보를 변경하여 알맞은 위치에 공통 코드를 삽입한 새로운 클래스 바이너리 코드를 사용하도록 한다. 즉 원본 클래스 파일은 변경하지 않고 클래스를 로딩할 때 JVM이 변경된 바이트 코드를 사용한다. AspectWerkz가 이에 해당한다.
셋째, 런타임시 Weaving
컴파일이나 클래스 로딩시 Weaving 과 달리 런타임시 Weaving 방식은 소스코드나 클래스를 변경하지 않는다. 런타임시 Weaving은 프록시를 이용해 AOP를 적용한다. 즉 핵심로직을 구현한 객체에 직접 접근하지 않고 중간에 공통코드가 적용된 프록시를 생성하여 프록시를 통해 핵심로직에 접근하게 된다. Spring AOP 가 이에 해당한다.
단지 단점은 핵심로직을 실행하기 전/후에만의 JoinPoint 만 적용 가능 하며, 필드값 변경 같은 JoinPoint 에 대해서는 적용이 불가능하다.
AOP 전망?
AOP는 앞으로 OOP를 대체하는 프로그램 방법이 아니다. 단지 OOP를 보완하고 좀더 개발이 쉽게 도와주는 툴이라고 볼 수 있다.
일부 AOP 비판자들은 AOP는 객체지향언어의 중요 맹점인 캡슐화를 깨트리고 있다고 보며 비판하고 있다.
또한 AOP는 학습 자체가 매우 어려우며 실제 개발에 있어 그만큼 위험성이 뒤따르고 있다는 점이다.
하지만 AOP를 비판하기만 하기에는 매우 가치가 있는 방법론이다. AOP를 적용하기전에 팀원들과 함께 학습을 진행하며 점진적으로 프로젝트에 적용해 가면 모든면에서 뛰어난 어플리케이션을 만들수 있는 매혹적인 도구이다.
댓글