Study (8) 썸네일형 리스트형 포인트컷, 어드바이스, 어드바이저 스프링에서 프록시를 적용할 떄 사용하는 3가지 개념 포인트컷 : 어떤 시점에 적용할 것인가에 대한 개념 Pointcut 인터페이스를 기반으로 동작하며 구현하려면 상속받아서 구현하면 된다. ClassFilter와 MethodMatcher 두가지를 제공하는데 클래스조건, 메소드관련 조건을 걸 수 있다. @Test void advisorTest1() { ServiceInterface target = new ServiceInterfaceImpl(); ProxyFactory proxyFactory = new ProxyFactory(target); DefaultPointcutAdvisor advisor = new DefaultPointcutAdvisor(Pointcut.TRUE, new TimeAdvice()); .. Proxy Factory 스프링에서는 프록시를 생성할 때 프록시 팩토리를 제공해준다. MethodInterceptor 인터페이스를 구현해주면 되는데 기존에 cglib이 아닌 org.aopalliance.intercept 패키지에 있는 인터페이스다. MethodInterceptor를 구현 import lombok.extern.slf4j.Slf4j; import org.aopalliance.intercept.MethodInterceptor; import org.aopalliance.intercept.MethodInvocation; @Slf4j public class TimeAdvice implements MethodInterceptor { @Override public Object invoke(MethodInvocation invo.. Cglib dynamic proxy 원래는 서드파티였으나 지금은 스프링이 기본으로 사용하는 방식 바이트코드를 조작는 방식이며 구체클래스 기반으로 동작한다. jdk dynamic proxy와 다르게 인터페이스가 필요하지 않으나 상속을 통해서 사용하다보니 class에 final이 붙은것은 프록시처리를 하면 예외가 발생한다 메소드도 마찬가지 그 외에 특이점은 인자에 들어있는 Method.invoke를 사용하기보단 MethodProxy를 통한 하용을 추천한다는 점 (성능상 이점이 있다고 한다.) import lombok.extern.slf4j.Slf4j; import org.springframework.cglib.proxy.MethodInterceptor; import org.springframework.cglib.proxy.MethodProxy.. JDK Dynamic Proxy 프록시를 관리할 떄 직접 target클래스를 상속받은 클래스를 만들 수 있으나 만약 만들어야할 프록시 클래스가 매우 많다면 마찬가지고 중복코드가 가득한 클래스가 많이 만들어지게 된다. 어차피 동일한 로직이 수행되는 프록시라면 Java의 Reflection을 이용해서 프록시를 동적으로 생성할 수 있다. Java에서 제공하는 동적 프록시를 이용해서 만들 수 있는데 JDK Dynamic Proxy는 인터페이스 기반으로 프록시 클래스를 만들어 준다. java.lang.reflect.InvocationHandler 인터페이스를 상속받아 클래스를 구현해서 invoke 부분을 작성하면 해당 프록시가 적용된 모든 인터페이스 기반 프록시에 invoke가 동작하게 된다. import lombok.extern.slf4j.S.. 인터페이스 기반 vs 구체 클래스 기반 프록시 프록시 패턴은 인터페이스 기반과 구체클래스 기반 모두 가능한데 인터페이스 기반의 단점은 매번 인터페이스를 생성해야 한다는 점 구체클래스기반의 단점은 불필요한 상속코드 super(null)을 작성해줘야 한다는 점 실무에서는 구체클래스 기반으로 많이들 쓴다. 실제로 인터페이스 기반 설계처럼 인터페이스 : 구현체가 1:N이 아니고 1:1인경우가 많아서 구체클래스 하나만 구현하는 방식이 널리 이용됨 이론상으로는 인터페이스 기반으로 가는게 맞으나 실용적으로는 꼭 그럴 필요는 없을 것 같다. 프록시 패턴 & 데코레이터 패턴 중요 구현체는 거의 비슷 프록시 패턴은 클라이언트 > 프록시 > 서버 데코레이터 패턴은 클라이언트 > 데코레이터 > 서버 클라이언트 > 데코레이터1 > 데코레이터2 > 서버 으로 유사하지만 의도가 다르다 프록시패턴은 접근에 대한 제어 호출부분에 값이 있거나 없거나 혹은 접근이 가능하거나 불가능하거나에 따라서 실제객체를 호출할지 혹은 프록시에서 이미 기억하고있는 처리를 할것인지에 대한 부분을 구현한다 데코레이터패턴은 호출부분에 결과값을 더한다던가 뺀다던가 혹은 다른 부가기능을 추가한다던가 해서 사용하는데 여러 데코레이터를 연속적으로 호출하게끔 하는 의도를 가진다. 중요부분 클라이언트는 서버에게 요청할 때 서버의 구현체에 의존하지 않고 인터페이스에만 의존하게 구현후 각 프록시와 데코레이터를 서버의 인터페이스.. 프록시 프록시의 개념은 클라이언트 > 서버 모델(요청주체 > (요청) > 요청이행자의 개념)에서 클라이언트가 서버에 직접적으로 요청을 하는 경우와 비교해 중간에서 요청을 대신 처리해주는 주체를 말한다 클라이언트 > 프록시 > 서버 의 형태로 변형되며 요청의 흐름에는 큰 변화가 없다 클라이언트는 요청이 어떻게 되는지 내부적인건 몰라도 내가 요청한거를 원하는 결과대로 받음 이런 프록시를 사용하는 패턴은 프록시 패턴과 데코레이터 패턴으로 나뉘는데 프록시 패턴은 요청에 대한 접근을 제어하는 데 주로 쓰이고 데코레이터 패턴은 요청에 부가적인 기능을 추가하는데 주로 쓰인다. 템플릿 메소드 패턴 부모클래스(추로 추상클래스)를 만들고 자식클래스를 만들어서 부모클래스의 필요한 부분만 재정의해서 사용하는 방식 변하는 코드에 집중할 수 있지만 부모클래스를 상속받아야 하는 단점을 그대로 유지한다. 즉, 부모클래스의 안쓰는 많으 부분도 가져가야 하는 셈 추가로 클래스를 매번 만들거나 익명클래스를 작성하는 부분도 단점이다. 이전 1 다음