6장

AOP?

Aop는 IoC/DI, 서비스 추상화와 더불어 스프링 3대 기반기술의 하나.

Aspect Oriented Programming의 약자로 핵심관점, 부가적인 관점으로 나눠서 보고 그 관점을 기준으로 모듈화 하는 프로그래밍 기법

6.1 트랜잭션 코드의 분리

6.1.1 메소드 분리

public void upgradeLevels() throws Exception { 
    Transactionstatus status = this.transactionManager.getTransaction(new DefaultTransactionDefinition());
    try {
				// 비지니스 로직 구간
        List<User> users = userDao.getAll(); 
				for (User user : users) {
            if (canUpgradeLevel(user)) { upgradeLevel(user); } 
        }
        this.transactionManager.commit(status); 
				// 비지니스 로직 구간
    } catch (Exception e) {
        this.transactionManager.rollback(status) ;
        throw e; 
    }
}

비즈니스 로직 코드를 사이에 두고 트랜잭션 시작과 종료를 담당하는 코드가 앞 뒤에 위치하고 있음.
트랜잭션 경계설정의 코드와 비즈니스 로직 코드 간에 서로 주고 받는 정보가 없음

→ 성격이 다른 코드를 두 개의 메소드로 분리할 수 있지 않을까?

public void upgradeLevels() throws Exception {
    TransactionStatus status = this.transactionManager
                        .getTransaction(new DefaultTransactionDefinition());
    try {
        upgradeLevelsInternal();
        this.transactionManager.commit(status);
    } catch (Exception e) {
        this.transactionManager.rollback(status);
        throw e;
    }
}

private void upgradeLevelsInternal(){
        List<User> users = userDao.getAll();
    for (User user : users) {
        if (canUpgradeLevel(user)) {
            upgradeLevel(user);
        }
    }
}

비즈니스 로직을 담당하는 코드와 트랜잭션 관련 코드가 깔끔하게 분리됨
그러나 여전히 트랜잭션을 담당하는 기술적인 코드가 UserService안에 존재

6.1.2 DI를 이용한 클래스의 분리

DI 적용을 이용한 트랜잭션 분리

우리는 인터페이스를 통해 클라이언트와 구현 클래스의 직접 결합을 막고 유연한 확장을 가능하게 해왔음
만약 한 번에 두 개의 구현 클래스를 동시에 이용한다면?
트랜잭션 관련 책임을 맡는 UserServiceTx를 구현
UserServiceTx는 비즈니스 로직을 담고 있지 않기 때문에 UserServiceImpl에 실제적인 로직 처리 작업은 위임함.
결국 클라이언트가 볼 때 결국 트랜잭션이 적용된 비즈니스 로직의 구현이라는 기대하는 동작이 일어남

UserService 인터페이스 도입

UserServiceImpl은 비즈니스 로직만 가지는 구현 클래스

@Service
public class UserServiceImpl implements UserService {

    private UserDao userDao;
    private MailSender mailSender;
        //...

    @Override
    public void upgradeLevels() {
                List<User> users = userDao.getAll();
                for(User user : users)
                        if(canUpgradeLevel(user)) {
                                upgradeLevel(user);
                        }
                }                
    }

}

public class UserServiceTx implements UserService {

    private UserService userService;
    private PlatformTransactionManager transactionManager;

    public void setTransactionManager(PlatformTransactionManager transactionManager) {
        this.transactionManager = transactionManager;
    }

    public void setUserService(UserService userService) {
        this.userService = userService;
    }

    public void add(User user) {
        userService.add(user);
    }

    public void upgradeLevels() {
        TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());
        try {
            userService.upgradeLevels();
            transactionManager.commit(transaction);
        } catch (RuntimeException e) {
            transactionManager.rollback(transaction);
            throw e;
        }
    }
}

사용자 관리라는 비즈니스 로직을 전혀 갖지 않고 UserService 구현 오브젝트에 기능을 위임함.
이를 위해 UserService 오브젝트를 DI받을 수 있어야 함.

트랜잭션을 적용을 위한 DI 설정

클라이언트는 UserServiceTx 빈을 호출해서 사용해야함.

트랜잭션 경계설정 코드 분리의 장점

비즈니스 로직을 담당하고 있는 UserServiceImpl의 코드를 작성할 때는 트랜잭션과 같은 기술적인 내용에는 전혀 신경쓰지 않아도 됨.
비즈니스 로직에 대한 테스트를 손쉽게 만들어 낼 수 있음

6.2 고립된 단위 테스트

가장 편하고 좋은 테스트 방법은 가능한 작은 단위로 쪼개서 테스트 하는것
- 테스트 실패 시 원인을 찾기 쉽기 때문
- 테스트 의도가 분명해지고 만들기도 쉬워짐

6.2.1 복잡한 의존관계 속의 테스트

현재 UserService는 UserDao, MailSender, PlatformTransactionManager 세 가지 타입의 의존 오브젝트가 필요함.

UserServiceTest는 UserService의 코드가 바르게 작성되어 있으면 성공, 아니면 실패여야함.
하지만 세가지 의존 관계를 갖는 오브젝트들이 테스트가 진행되는 동안에 같이 실행됨
따라서 UserService를 테스트 하는 것 처럼 보이지만 사실 그 뒤에 존재하는 훨씬 더 많은 오브젝트와 환경, 서비스, 서버, 심지어 네트워크까지 함께 테스트하는 셈
- 테스트 준비도 힘들고 수행속도 느리고 오류 찾기도 힘듦

6.2.2 테스트 대상 오브젝트 고립시키기

위와 같은 이유 때문에 테스트의 대상이 환경이나 외부 서버, 다른 클래스 코드에 종속되고 영향받지 않도록 고립시킬 필요가 있음. → 대역을 사용

테스트를 위한 UserServiceImpl 고립

고립된 테스트가 가능하도록 UserService를 재구성하면 이러한 구조가 됨
하지만 의존 오브젝트나 외부 서비스에 의존하지 않는 고립된 테스트 방식으로 만든 UserServiceImpl은 결과를 확인하기 힘듦. → UserDao에게 어떤 요청을 했는지 확인하는 작업 필요
그래서 UserDao와 같은 역할을 하면서 UserServiceImpl과의 사이에서 주고받은 정보를 저장해뒀다가, 테스트의 검증에 사용할 수 있게 하는 목 오브젝트를 만들 필요가 있음.

6.2.3 단위 테스트와 통합 테스트

단위 테스트: 테스트 대상 클래스를 목 오브젝트 등의 테스트 대역을 이용해 의존 오브젝트나 외부의 리소스를 사용하지 않도록 고립시켜서 테스트 하는 것
통합 테스트: 두 개 이상의 성격이나 계층이 다른 오브젝트가 연동하도록 만들어 테스트하거나, 또는 외부의 DB나 파일, 서비스 등의 리소스가 참여하는 테스트

6.2.4 목 프레임워크

단위 테스트를 만들기 위해서는 스텁이나 목 오브젝트의 사용이 필수적

Mockito 프레임워크

Mockito는 목 오브젝트를 편리하게 작성하도록 도와주는 프레임워크
사용도 편리하고 코드도 직관적

6.3

6.3.1 프록시와 프록시 패턴, 데코레이터 패턴

단순히 확장성을 고려해서 한 가지 기능을 분리한다면 전형적인 전략 패턴을 사용하면 됨.
트랜잭션 기능에는 추상화 작업을 통해 이미 전략 패턴이 적용되어 있지만 전략 패턴으로는 트랜잭션 기능의 구현 내용을 분리해냈을 뿐 트랜잭션을 적용한다는 사실은 코드에 남아있음
구체적인 코드는 제거했을지라도 위임을 통해 기능을 사용하는 코드는 핵심 코드와 함께 남아있음
핵심기능은 부가기능을 가진 클래스 존재 자체를 모름. 따라서 부가기능이 핵심기능을 사용하는 구조가 되는 것
부가 기능은 자신이 핵심기능을 가진 클래스인 것처럼 꾸며서 클라이언트가 자신을 거쳐 핵심기능을 사용하도록 만들어야함.
그러기 위해 클라이언트는 인터페이스를 통해서만 핵심기능을 사용하고 부가기능 자신도 같은 인터페이스를 구현한 뒤 자신이 그 사이에 끼어들어야함.
이렇게 자신이 실제 대상인 것처럼 위장해서 클라이언트의 요청을 받아주는 것을 프록시라고 부름.
프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트를 타깃, 실체라고 부름

프록시의 특징
- 타깃과 같은 인터페이스를 구현
- 타깃을 제어할 수 있는 위치에 있음
프록시는 사용 목적에 따라 두 가지로 구분할 수 있음
- 클라이언트가 타깃에 접근하는 방법을 제어하기 위함 → 프록시 패턴
- 타깃에 부가적인 기능을 부여해주기 위함 → 데코레이터 패턴

데코레이터 패턴

데코레이터 패턴은 타깃에 부가적인 기능을 런타임 시 다이나믹하게 부여해주기 위해 프록시를 사용하는 패턴을 말함.
다이나믹하게 기능을 부가한다는 의미는 컴파일 시점에 어떤 방법과 순서로 프록시와 타겟이 연결되어 사용되는지 정해져있지 않다는 뜻.
데코레이터 패턴이라 불리는 이유는 마치 제품이나 케익 등을 여러 겹으로 포장하고 그 위에 장식을 붙이는 것처럼 실제 내용물은 동일하지만 부가적인 효과를 부여해줄 수 있기 때문.
프록시가 여러개라면 순서를 정해서 단계적으로 위임하는 구조로 만들면 됨.
프록시로서 동작하는 각 데코레이터는 위임하는 대상에도 인터페이스로 접근하기 때문에 타깃으로 위임하는지, 아니면 다음 단계의 프록시로 위임하는지 알지 못함.
- → 생성자나 수정자 메소드를 통해 위임 대상을 외부에서 런타임 시에 주입받을 수 있도록 만들어야함.
UserServiceTx도 데코레이터 패턴을 적용한 것

프록시 패턴

프록시를 사용하는 방법 중 타깃에 대한 접근 방법을 제어하려는 목적을 가진 경우 사용하는 패턴.
프록시 패턴의 프록시는 타깃의 기능을 확장하거나 추가하지 않는 대신 클라이언트가 타깃에 접근하는 방식을 변경해줌.
타깃 오브젝트를 생성하기가 복잡하거나 당장 필요하지 않은 경우에는 꼭 필요한 시점까지 오브젝트를 생성하지 않는 편이 좋지만 타깃 오브젝트에 대한 레퍼런스가 미리 필요할 수 있음 → 프록시 패턴 적용
클라이언트에게 타깃에 대한 레퍼런스 대신 프록시를 넘겨준 후 이후 타깃을 사용하려 하면 그때 프록시가 타깃 오브젝트를 생성하고 요청을 위임해주는 방식
특별한 상황에서 타깃에 대한 접근권한을 제어하기 위해 프록시 패턴을 사용할 수 있음 ex)readonly
구조적으로는 프록시와 데코레이터 패턴이 비슷하나 프록시는 코드에서 자신이 만들거나 접근할 타깃 클래스 정보를 알고 있는 경우가 많음. 생성을 지연하는 프록시라면 구체적인 생성 방법을 알아야 하기 때문에 타깃 클래스에 대한 직접적인 정보를 알아야함.

6.3.2 다이내믹 프록시

프록시는 기존 코드에 영향을 주지 않으면서 타깃의 기능을 확정하거나 접근 방법을 제어할 수 있는 유용한 방법
하지만 프록시를 만드는 일이 상당히 번거롭게 느껴짐
자바에는 이런 부분을 해결하기 위해 java.lang.reflect 패키지 안에 프록시를 손쉽게 만들 수 있도록 지원해주는 클래스들이 존재

프록시 구성과 프록시 작성의 문제점

프록시는 다음 두 가지 기능으로 구성됨
- 타깃과 같은 메소드를 구현하고 있다가 메소드가 호출되면 타깃 오브젝트로 위임
- 지정된 요청에 대해 부가기능을 수행
프록시를 만들기가 번거로운 이유
- 타깃의 인터페이스를 구현하고 위임하는 코드를 작성하기가 번거로움.
- 부가기능 코드가 중복될 가능성이 많음
JDK의 다이내믹 프록시를 사용하면 이러한 문제를 해결할 수 있음

리플렉션

컴파일 시간이 아닌 실행 시간에 동적으로 특정 클래스의 정보를 추출할 수 있는 프로그래밍 기법
구체적인 클래스 타입을 알지 못하더라도 그 클래스의 메서드, 타입, 변수들에 접근할 수 있도록 해주는 자바 API
다이내믹 프록시는 리플렉션 기능을 이용해 프록시를 만들어줌
리플렉션은 자바의 코드 자체를 추상화해서 접근하도록 만든것

Method lengthMethod = String.class.getMethod("length");
int length = lengthMethod.invoke(name); // int length = name.length();

다이내믹 프록시 적용

다이내믹 프록시는 프록시 팩토리에 의해 런타임시 다이내믹하게 만들어지는 오브젝트
다이내믹 프록시 오브젝트는 타깃의 인터페이스와 같은 타입으로 만들어짐
클라이언트는 다이내믹 프록시 오브젝트를 타깃 인터페이스를 통해 사용할 수 있음
- → 프록시를 만들 때 인터페이스를 모두 구현해가면서 클래스를 정의하는 수고를 덜 수 있음
- 프록시 팩토리에게 인터페이스 정보만 제공해주면 해당 인터페이스를 구현한 클래스의 오브젝트를 자동으로 만들어주기 때문
부가기능 제공 코드는 직접 작성해야함.
부가기능은 프록시 오브젝트와 독립적으로 InvocationHandler를 구현한 오브젝트에 담음

public Object invoke(Object proxy, Method method, Object[] args)

다이내믹 프록시 오브젝트는 클라이언트의 모든 요청을 리플렉션 정보로 변환해서 InvocationHandler 구현 오브젝트의 invoke() 메소드로 넘김
- → 모든 메소드 요청이 하나의 메소드로 집중되기 때문에 중복되는 기능을 효과적으로 제공

public class UppercaseHandler implements InvocationHandler {
    Hello target;

    public UppercaseHandler(Hello target) { 
        this.target = target;
    }

    public Object invoke(Object proxy, Method method, Object!] args) throws Throwable {
        String ret = (String)method.invoke(target, args); //형변환?
        return ret.toUpperCase();
    }
}

다이내믹 프록시를 통해 요청이 전달되면 리플렉션 API를 이용해 타깃 오브젝트의 메소드를 호출
- 이때 타깃 오브젝트는 생성자를 통해 미리 전달받음

//프록시 생성하는 코드 
Hello proxiedHello = (Hello)Proxy.newProxyInstance( 
    getClass().getClassLoader(), // 동적으로 생성되는 다이내믹 프록시 클래스의 로딩에 사용할 클래스 로더
    new Class[] {Hello.class}, // 구현할 인터페이스
    new UppercaseHandler (new HelloTarget())); //부가기능과 위임 코드를 담은 invocationHandler

6.3.3 다이내믹 프록시를 이용한 트랜잭션 부가기능

트랜잭션 부가기능을 제공하는 다이내믹 프록시를 만들면 효율적으로 트랜잭션 기능 제공 가능

public class TransactionHandler implements InvocationHandler {
    private Object target;
    private PlatformTransactionManager transactionManager;
    private String pattern; //트랜잭션을 적용할 메소드 이름 패턴
    
    public void setTarget(Object target) {
        this.target = target;
    }
    
    public void setTransactionManager(PlatormTransactionManager transactionManager) {
        this.transactionManager = transactionManager;
    }
    
    public void setPattern(String pattern) {
        this.pattern = pattern;
    }
    
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if(method.getName().startsWith(pattern)) {
            return invokeInTransaction(method, args);
        } else {
            return method.invoke(target, args);
        }
    }
    
    private Object invokeInTransaction(Method method, Object[] args) throws Throwable {
        TransactionStatus status = this.transactionManager.getTransaction(new DefaultTransactionDefinition());
        try {
            Object ret = method.invoke(target, args);
            this.transactionManager.commit(status); //타깃 호출후 예외가 발생하지 않으면 commit
            return ret;
        } catch (InvocationTargetException e) { //예외가 발생하면 트랜잭션 롤백
            this.transactionManager.rollback(status);
            return e.getTargetException();
        }
    }
}

요청을 위임할 타깃을 DI로 제공받음
타깃을 저장할 변수는 Obect로 선언해 트랜잭션 적용이 필요한 어떤 타깃 오브젝트에도 적용 가능
롤백을 적용하기 위한 예외는 RuntimeException 대신 InvocationTargetException 사용해야함
- 리플렉션 메소드인 Method.invoke()를 이용해 타깃 오브젝트의 메소드를 호출할 때는 타깃 오브젝트에서 발생하는 예외가 InvocationTargetException으로 한번 포장돼서 전달받기 때문.
- 따라서 일단 InvocationTargetException으로 받은 후 getTargetException() 메소드로 중첩되어 있는 예외를 가져와야함.

6.3.4 다이내믹 프록시를 위한 팩토리 빈

TransactionHandler와 다이내믹 프록시를 스프링의 DI를 통해 사용할 수 있도록 만들어야함
하지만 다이내믹 프록시 오브젝트는 일반적인 스프링의 빈으로는 등록할 방법이 없음
다이내믹 프록시는 Proxy 클래스의 newProxyInstance()라는 스태틱 팩토리 메서드를 통해서만 만들 수 있음

팩토리 빈

스프링은 팩토리 빈을 이용한 빈 생성도 지원함.
팩토리 빈은 스프링을 대신해서 오브젝트의 생성로직을 담당하도록 만들어진 특별한 빈을 의미
팩토리 빈 클래스의 오브젝트의 getObect()메소드를 이용해 오브젝트를 가져오고, 이를 빈 오브젝트로 사용할 수 있음

public interface FactoryBean<T> {
    T getObject() throws Exception; //빈 오브젝트를 생성해서 돌려준다.
    Class<? extends T> getObjectType(); //생성되는 오브젝트 타입을 알려준다.
    boolean isSingleton(); //getObject가 돌려주는 오브젝트가 항상 같은 싱글톤 오브젝트인지 알려준다.
}

다이내믹 프록시를 만들어주는 팩토리 빈

팩토리 빈 방식을 통해 아래 그림과 같은 구조로 관계가 설정됨
팩토리 빈은 다이내믹 프록시가 위임할 타깃 오브젝트(UserServiceImpl)에 대한 레퍼런스를 프로퍼티를 통해 DI 받아둬야함. 다이내믹 프록시와 함께 생성할 TransactionHandler에게 타깃 오브젝트를 전달해줘야 하기 때문.

6.3.5 프록시 팩토리 빈 방식의 장점과 한계

프록시 팩토리 빈의 재사용

한번 부가기능을 가진 프록시를 생성하는 팩토리 빈을 만들어두면 타깃의 타입에 상관없이 재사용할 수 있음

프록시 패토리 빈 방식의 장점

인터페이스 구현 클래스 만들지 않아도 됨
부가기능 코드 중복 제거
다이내믹 프록시에 팩토리 빈을 이용한 DI까지 더해주면 번거로운 다이내믹 프록시 생성 코드도 제거 가능
이 과정에서 스프링 DI는 매우 중요한 역할

프록시 팩토리 빈의 한계

프록시를 통해 타깃에 부가기능을 제공하는 것은 메소드 단위
한 번에 여러개의 클래스에 공통적인 부가기능을 제공하는 일은 지금까지 살펴본 방법으로는 불가능함.
하나의 타깃에 여러 개의 부가기능을 적용하는 것도 문제.
TransactionHandler 오브젝트가 프록시 팩토리 빈 개수만큼 만들어진다는 점도 문제임
TransactionHandler는 타깃 오브젝트를 프로퍼티를 갖고 있음. 따라서 트랜잭션 부가기능을 제공하는 동일한 코드임에도 불구하고 타깃 오브젝트가 달라지면 새로운 TransactionHandler 오브젝트를 만들어야함

6.4 스프링 프록시 팩토리 빈

6.4.1 ProxyFactoryBean

스프링은 프록시 오브젝트를 생성해주는 기술을 추상화한 팩토리 빈을 제공
스프링의 ProxyFactoryBean은 프록시를 생성해서 빈 오브젝트로 등록하게 해주는 팩토리 빈
이전 챕터에서 사용했떤 FactoryBean과 달리, 순수하게 프록시를 생성하는 작업만 담당하고 프록시를 통해 부가기능은 별도의 빈에 둘 수있음
ProxyFactoryBean이 생성하는 프록시에서 사용할 부가기능은 MethodInterceptor 인터페이스를 구현해서 만든다
MethodInterceptor는 InvocationHandler와 비슷하지만 한 가지 다른 점이 있음
- InvocationHandler의 invoke() 메소드는 타깃 오브젝트에 대한 정보를 제공하지 않음
  - → 타깃은 InvocationHandler를 구현한 클래스가 직접 알고 있어야함.
- MethodInterceptor의 invoke() 메소드는 ProxyFactoryBean으로부터 타깃 오브젝트에 대한 정보까지도 함께 제공받음.
  - → 타깃 오브젝트에 상관 없이 독립적으로 만들어질 수 있음 → MethodInterceptor 오브젝트는 타깃이 다른 여러 프록시에서 함께 사용할 수 있고 싱글톤 빈으로 등록 가능

public void simpleProxy() {
    Hello proxiedHello = (Hello)Proxy.newProxyInstance( //  JDK 다아내믹 프록시 생성
        getClass().getClassLoader(),
        new Class[] {Hello.class},
        new UppercaseHandler(new HelloTarget())
    );
}

public void proxyFactoryBean() {
    ProxyFactoryBean pfBean = new ProxyFactoryBean();
    pfBean.setTarget(new HelloTarget());    //  타깃 설정
    pfBean.addAdvice(new UppercaseAdvice());    //  부가기능을 담은 어드바이스를 추가한다. 여러 개를 추가할 수도 있다.

    Hello proxiedHello = (Hello) pfBean.getObject();    //  FactoryBean이므로 getObject()로 생성된 프록시를 가져온다.
    System.out.println(proxiedHello.sayHello("JaeDoo"));
    System.out.println(proxiedHello.sayHi("JaeDoo"));
    System.out.println(proxiedHello.sayThankYou("JaeDoo"));
}

static class UppercaseAdvice implements MethodInterceptor {

    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
        /*
            리플렉션의 Method와 달리 MethodInvocation은 
            메소드 정보와 함께 타깃 오브젝트를 알고 있기 때문에
            메소드 실행 시 타깃 오브젝트를 전달할 필요가 없다.
        */
        String ret = (String)invocation.proceed();
        return ret.toUpperCase();   //  부가기능 적용
    }
}

public interface Hello {            //  타깃과 프록시가 구현할 인터페이스
    String sayHello(String name);
    String sayHi(String name);
    String sayThankYou(String name);
}

static class HelloTarget implements Hello { //  타깃 클래스

    @Override
    public String sayHello(String name) { return "Hello " + name;}

    @Override
    public String sayHi(String name) { return "Hi " + name;}

    @Override
    public String sayThankYou(String name) {return "Thank You " + name;}
}

어드바이스: 타깃이 필요 없는 순수한 부가기능

MethodInterceptor로는 메소드 정보와 함께 타깃 오브젝트가 담긴 MethodInvocation 오브젝트가 전달됨.
MethodInterceptor은 타깃 오브젝트의 메소드를 실행할 수 있기 때문에 MethodInterceptor는 부가기능을 제공하는 데만 집중할 수 있음
MethodInvocation은 일종의 콜백 오브젝트로 타깃 오브젝트의 메소드를 내부적으로 실행해주는 기능이 있음. → MethodInvocation 구현 클래스는 일종의 공유 가능한 템플릿처럼 동작하는 것.
ProxyFactoryBean은 작은 단위의 템플릿/콜백 구조를 응용해 적용했기 때문에 템플릿 역할을 하는 MethodInvocation을 싱글톤으로 두고 공유할 수 있음
MethodInterceptor처럼 타깃 오브젝트에 적용하는 부가기능을 담은 오브젝트를 스프링에서는 어드바이스라고 부름

포인트컷: 부가기능 적용 대상 메소드 선정 방법

MethodInterceptor는 타깃에 대한 정보를 들고 있지 않기에 싱글톤 빈으로 등록할 수 있었다. 따라서 확장성까지 고려하면 적용 대상 메소드를 선정하는 로직은 분리하는 것이 올바름.
MethodInterceptor에는 재사용 가능한 순수한 부가기능 코드만 남기고 프록시에 부가기능 적용 메소드를 선택하는 기능을 넣자!

ProxyFactoryBean 방식은 부가기능과 메소드 선정 알고리즘을 활용하는 유연한 구조를 제공
메소드 선정 알고리즘을 담은 오브젝트를 포인트컷(PointCut)이라고 함.
어드바이스와 포인트컷은 모두 프록시에 DI로 주입돼서 사용됨.
두 가지 모두 여러 프록시에서 공유가 가능하도록 만들어지기 때문에 스프링의 싱글톤 빈으로 등록이 가능
어드바이스와 포인트컷을 묶은 오브젝트를 어드바이저라고함.

[6주차](김수환, 오형석, 김동하) #4

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions