[Chapter 07] 왜 @Around 어드바이스만 차별하는 것인가

[corock]

제목은 어그로입니다.

1. p.395 하단부에서 @Around 어드바이스는 반드시 ProceedingJoinPoint 를 주입받아야 한다고 하는데, JoinPoint 를 받으면 안 되는가?
2. 왜 JoinPoint, ProceedingJointPoint 인터페이스는 꼭 어드바이스 메서드의 첫 번째 인자로 줘야만 하는가?
   스프링 프레임워크에서 인자의 위치를 지켜야 하는 다른 것들은 어떤 것이 있을까?

[BvrPark]

1. @Around 어드바이스가 특정 메서드의 실행 전과 후 또는 예외가 발생했을 때 실행되는 역할이 proceed()라는 메서드를 통해서 이루어진다고 합니다.
   그런데 이 proceed()라는 메서드를 ProceedingJoinPoint인터페이스는 가지고 있지만 JoinPoint인터페이스는 가지고 있지 않아서
   @Around 어드바이스는 반드시 ProceedingJoinPoint를 주입받아야 된다고 합니다.

2. JoinPoint, ProceedingJoinPoint가 어드바이스 메서드의 첫 번째 인자로 줘야되는 이유는 여러 가지가 있다고 합니다.

   2-1. 근본적으로 스프링 AOP 설계 자체를 그렇게 만들었다.
   JoinPoint는 메서드 실행의 특정 지점을 나타내고
   ProceedingJoinPoint는 어드바이스가 메서드 실행을 진행하거나 중단할 수 있는 기능을 추가로 가지는데
   이 두 인터페이스를 첫번째 인자로 받으면 스프링 AOP가 런타임 시에 두 인터페이스의 구현체를 적절하게 주입할 수 있어서 설계를 첫번째 인자로 받게 만들었다고 합니다.

   2-2. 스프링 AOP는 어드바이스 메서드의 인자 위치에 일정한 규칙을 가지고 있다.
   스프링 AOP는 어드바이스 메서드의 인자 위치에 일정한 규칙을 가지고 있는데 이를 관례적으로 지켜야 다른 개발자들이 읽었을 때, 코드 가독성이 좋아진다고 하고 그런 규칙 중에 하나가 JoinPoint, ProceedingJoinPoint를 어드바이스 메서드의 첫 번째 인자로 줘야되는 것이라고 합니다.

3. 스프링 프레임워크에서 인자의 위치를 지켜야 하는 다른 것들은 어떤 것이 있을까?
   간단하게는 의존성 주입이 있을 것 같고 @RequestParam과 같은 어노테이션이 붙으면 파라미터는 위치를 지켜서 사용해야 되기 때문에 이런 어노테이션들이 주로 인자의 위치를 지켜야 될 것 같습니다.

[corock]

3번 내용은 한번 테스트 해보겠습니다.

[corock]

e.g. BindingResult

[corock]

e.g. 어떤 개발자는 Pagable 인터페이스 위치를 앞에 위치시키고, 다른 개발자는 끝에 위치시키고, 각자 스타일 대로 두는 방법도 있고...

[Irisation23]

금주 CheckPoint

• @RequestParam 파라미터 위치에 결과 테스트 추가해 볼 것