AOP (Aspect Oriented Programming)
- 관점 지향 프로그래밍
- 관점을 나눠 각각 모듈화 (코드를 부분적으로 나눠 모듈화 하겠다는 의미)
- 각 다른 부분에서 반복적으로 쓰이는 코드 == 흩어진 관심사
- 이런 흩어진 괌심사를 Aspect로 모듈화하고 핵심적인 비즈니스 로직에서 분리하여 재사용하겠다는 것
:: As 구성
Aspect는 부가될 기능을 정의한 Advice와,
해당 Advice를 어디에 적용할 지를 결정하는 Pointcut 정보로 구성
:: AOP 주요 개념
- Aspect
- 흩어진 관심사를 모듈화
- 주로 부가기능을 모듈화
- 부가될 기능을 정의한 Advice와,
해당 Advice를 어디에 적용할 지를 결정하는 Pointcut 정보로 구성
- Target
- Aspect를 적용하는 곳 (클래스, 메서드 .. )
- Advice
- 실질적으로 어떤 일을 해야할 지에 대한 것
- 실질적인 부가기능을 담은 구현체
- JointPoint
- Advice가 적용될 위치, 끼어들 수 있는 지점
- 메서드 진입 지점, 생성자 호출 시점, 필드에서 값을 꺼내올 때 등 다양한 시점에 적용가능
- PointCut
- JointPoint의 상세한 스펙을 정의한 것
- 'A란 메서드의 진입 시점에 호출할 것'과 같이 더욱 구체적으로 Advice가 실행될 지점을 정할 수 있음
:: AOP 특징
- 프록시 패턴 기반의 AOP 구현체
- 프록시 객체를 쓰는 이유는 접근 제어 및 부가기능을 추가하기 위해
- Bean에만 적용 가능
- IoC와 연동하여 엔터프라이즈 애플리케이션에서 가장 흔한 문제에 대한 해결책을 지원하는 것이 목적
(중복코드, 프록시 클래스 작성의 번거로움, 객체들 간 관계 복잡도 증가 ...)
학교 다닐 때보면 보충학습반을 a~d반 정도로 나눠 진행했던 적이 있다.
아마도 이게 aop로 보면 되지 않을까 싶다.
각 학생들의 이해도가 다르고 성적이 다르니 궁금한 부분들도 다를텐데,
매번 그 학생들이 와서 같은걸 물어보고 가고, 또 다른 학생들이 또 같은걸 궁금해한다고 할 때
이걸 매번 반복해서 가르쳐 주는 것이 아닌 단적으로 성적으로 나눠 궁금해하고, 힘들어하는걸 한번에 알려주는 그런거라고 이해하면 될 것 같다.