6장) 6.3 다이내믹 프록시와 팩토리 빈

6장 AOP

6.3 다이내믹 프록시와 팩토리 빈

• 프록시와 프록시 패턴, 데코레이터 패턴
  • 프록시
    • 트랜잭션은 비즈니스 로직과는 성격이 다르기 때문에 분리, 독립
      • UserServiceTx, UserServiceImpl
    • 핵심 기능(비즈니스 로직)을 담은 클래스를 부가 기능을 가진 트랜잭션 클래스에서 이용
    • 클라이언트가 핵심 기능을 가진 클래스를 직접 사용하지 않도록, 부가 기능을 담은 클래스가 핵심 기능인 것 처럼 위장 ~> 핵심 기능 클래스를 이용
    • 실제 대상인 것 처럼 위장해서 요청을 받아주는 대리자 역할을 한다고 해서 프록시라고 부름
    • 요청을 위임받아 실제 처리하는 오브젝트를 타깃 or 실체(real subject) 라고 부름
    • 클라이언트 --> 프록시 --> 타깃
    • 사용 목적
      • 클라이언트가 타깃에 접근하는 것을 제어하기 위함
      • 부가적인 기능을 부여하기 위함
  • 데코레이터 패턴
    • 타깃에 부가적인 기능을 런타임 시 다이나믹하게 부여하기 위해 프록시를 사용하는 패턴
      • 컴파일 시점에서 프록시와 타깃이 연결되어 사용되는지 정해져있지 않음
    • 프록시가 한 개로 제한되지 않고, 프록시가 타깃을 직접 사용하도록 고정시킬 필요 X
      • 인터페이스를 구현한 타겟과 여러 프록시를 사용할 수 있음 (단계적 위임)
    • 데코레이터 프록시의 다음 위임 대상은 인터페이스로 선언하고 생성자나 수정자 메소드를 통해 위임 대상을 외부에서 런타임 시에 주입받도록 구현해야함
      • 자바 IO 패키지의 InputStream과 OutputStream 구현 클래스가 대표적인 예시
        • InputStream is = new BufferedInputStream(new FileInputStream("a.txt"));
      • 스프링의 DI를 이용하여 편하게 위임
    • 타깃 코드에 손대지 않고, 클라이언트가 호출하는 방법도 변경하지 않은 채로 새로운 기능을 추가할 때 유용한 방법
    • 클라이언트 --> 여러 데코레이터(deco1 --> deco2) --> 타깃
  • 프록시 패턴
    • 프록시를 사용하는 방법 중에서 타깃에 대한 접근 방법을 제어하려는 목적을 가진 경우
    • 프록시 패턴의 프록시는 타깃의 기능을 확장하거나 추가하지 않고, 클라이언트가 타깃에 접근하는 방식을 변경
    • 타깃 오브젝트를 생성하기가 복잡하거나 당장 필요하지 않은 경우, 필요한 시점까지 오브젝트를 생성하지 않는 것이 좋지만, 타깃 오브젝트에 대한 레퍼런스가 미리 필요한 경우가 있을 때 프록시 패턴을 사용
      • 프록시의 메소드를 통해 타깃을 사용하려고 시도할 때, 프록시가 타깃 오브젝트를 생성하고 요청을 위임
      • 많은 작업이 진행되는 경우, 생성을 최대한 늦춤으로써 장점을 가짐
    • 리모팅 기술을 사용해 다른 서버에 존재하는 오브젝트를 사용하는 경우에도 장점
    • 특별한 상황에 타깃에 대한 접근권한을 제어할 때도 장점
      • 수정 가능한 오브젝트를 읽기 전용으로만 동작하게 해야하는 경우, 오브젝트 프록시를 만들어서 read 이외에 예외를 발생하도록 구현
        • Collections의 unmodifiableCollection()을 통해 만들어지는 오브젝트가 대표 예시
    • 클라이언트 --> 접근 제어 프록시 --> 여러 데코레이터 --> 타깃
• 다이내믹 프록시(Dynamic Proxy)
  • 프록시를 만드는 일이 번거로워서 등장
    • 일일이 프록시 클래스를 정의하지 않고 몇 가지 API를 이용해 프록시처럼 동작하는 오브젝트를 다이나믹하게 생성
  • 프록시 구성과 프록시 작성의 문제점
    • 프록시의 기능
      • 타깃과 같은 메소드를 구현하고 있다가 메소드가 호출되면 타깃 오브젝트로 위임
      • 지정된 요청에 대한 부가기능 수행
    • 프록시 구현이 번거로운 이유
      • 타깃의 인터페이스를 구현하고 위임하는 코드를 작성하기 번거로움
        • 타깃 인터페이스의 메소드가 추가되거나 변경될 때마다 함께 수정해야함
      • 부가기능 코드가 중복될 가능성이 높음
        • 트랜잭션의 경우 DB 사용하는 로직에 적용될 확률이 높음
        • 위의 경우, 트랜잭션 기능을 제공하는 유사한 코드가 여러 메소드에 중복됨
  • 리플렉션
    • 자바 코드를 추상화해서 접근하도록 만든 것
    • 다이내믹 프록시는 리플렉션 기능을 이용해서 프록시를 생성
    • 자바의 모든 클래스는 그 자체의 구성정보를 담은 Class 타입의 오브젝트를 하나씩 가지고 있음
      • 클래스이름.class or 오브젝트의 getClass() 메소드로 호출 가능
      • 특정 클래스 정보에서 특정 이름을 가진 메소드 정보를 가져올 수 있음
        • Method lengthMethod = String.class.getMethod("length");
        • 메소드 실행은 invoke() 메소드를 사용
        • int length = lengthMethod.invoke(name);
  • 프록시 클래스
    • 다이나믹 프록시를 이용한 프록시 생성
    • 다이내믹 프록시 동작 방식
      • 
      • 프록시 팩토리에 의해 런타임 시 다이내믹하게 만들어짐
      • 프록시에서 필요한 부가기능 제공 코드는 직접 작성
        • 부가 기능은 프록시 오브젝트와 독립적으로 InvocationHandler를 구현한 오브젝트에 담음

    • interface Hello {
          String sayHello(String name);
          String sayHi(String name);
          String sayThankYou(String name);
      }

    • public class HelloTarget implements Hello {
          public String sayHello(String name) {
              return "Hello " + name;
          }
          public String sayHi(String name) {
              return "Hi " + name;
          }
          public String sayThankYou(String name) {
              return "Thank you " + name;
          }
      }

    • 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();
          }
      }

    • Hello proxiedHello = (Hello)Proxy.newProxyInstance(
          getClass().getClassLoader(), // 다이나믹 프록시 오브젝트는 Hello 인터페이스를 구현하고 있으므로 캐스팅 세이프
          new Class[] { Hello.class }, // dynamic proxy 클래스 로딩에 사용될 클래스 로더
          new UppercaseHandler(new HelloTarget()) // invocationHandler
      );

    • 첫 번째 파라미터로 다이내믹 프록시가 정의되는 클래스 로더 지정
    • 두 번째 파라미터로 다이내믹 프록시가 구현해야 할 인터페이스 지정(한 번에 하나 이상의 인터페이스를 구현할 수 있기 때문에 배열을 사용)
    • 마지막 파라미터로 부가기능과 위임 관련 코드를 담고 있는 InvocationHandler 구현 오브젝트 제공
  • 다이내믹 프록시의 확장
    • Hello 인터페이스의 메소드가 증가하는 경우, 다이내믹 프록시에 자동으로 포함되고, 부가 기능은 invoke() 메소드에서 처리됨
    • 타깃의 타입에 상관없이 InvocationHandler를 통해 적용 가능

    • public class UppercaseHandler implements InvocationHandler { // 확장
          Object target;
          private UppercaseHandler(Object target) {
              this.target = target;
          }
      
          public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
              Object ret = method.invoke(target, args);
              return ret instanceof String ? (String)ret.toUpperCase() : ret;
          }
      }

    • public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 메소드를 선별해서 부가기능을 적용하는 invoke
          Object ret = method.invoke(target, args);
          return ret instanceof String && method.getName().startsWith("say") ?
              (String)ret.toUpperCase() : ret;
      }

• 다이내믹 프록시를 이용한 트랜잭션 부가기능
  • 앞서 작성했던 UserServiceTx를 다이내믹 프록시 방식으로 수정
  • 트랜잭션 InvocationHandler

    • 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(PlatformTransactionManager transactionManager) {
              this.transactionManager = transactionManager;
          }
      
          public void setPattern(String pattern) {
              this.pattern = pattern;
          }
      
          public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
              return Method.getName().startsWith(pattern) ?
                  invokeInTransaction(method, args) :
                  method.invoke(target, args);
          }
      
          private Object invokeInTransaction(Method method, Object[] args) throws Throwable {
              TransactionStatus status = this.getTransaction(new DefaultTransactionManager());
      
              try {
                  Object ret = method.invoke(target, args);
                  this.transactionManager.commit(status);
                  return ret;
              } catch (InvocationTargetException exception) {
                  this.transactionmanager.rollback(status);
                  throw exception.getTargetException();
              }
          }
      }

    • 요청을 위임할 타깃을 DI로 제공받고, Object로 선언
      • UserServiceImpl 외에 트랜잭션 적용이 필요한 어떤 타깃 오브젝트에도 적용 가능
    • UserServiceTx와 마찬가지로 트랜잭션 추상화 인터페이스인 PlatformTransactionManager를 DI 받음
    • 타깃 오브젝트의 모든 메소드에 무조건 트랜잭션이 적용되지 않도록 트랜잭션을 적용할 메소드 이름의 패턴을 DI 받음
    • InvocationHandler의 invoke() 메소드는 적용할 대상을 선별해서 트랜잭션을 적용하고, 아니라면 부가기능 없이 타깃 오브젝트의 메소드를 호출해서 결과를 리턴
  • TransactionHandler와 다이내믹 프록시를 이용하는 테스트

    • @Test
      public void upgradeAllOrNothing() throws Exception {
          ...
          TransactionHandler txHandler = new TransactionHandler();
          txHandler.setTarget(testUserService);
          txHandler.setTransactionManager(transactionManager);
          txhandler.setPattern("upgradeLevels");
          UserService txUserService = (UserService)Proxy.newProxyInstance(
              getClass().getClassLoader(),
              new Class[] { UserService.class },
              txHandler
          );
      }

• 다이내믹 프록시를 위한 팩토리 빈
  • TransactionHandler와 다이내믹 프록시를 스프링 DI를 통해 사용하도록 수정
    • 스프링은 내부적으로 리플렉션 API를 이용해서 빈 정의에 나오는 클래스 이름을 가지고 빈 오브젝트를 생성
      • 다이내믹 프록시 오브젝트는 리플렉션을 통해 오브젝트 생성 X
      • Proxy 클래스의 newProxyInstance() 스태틱 팩토리 메소드를 통해서만 생성 가능
  • 팩토리 빈
    • 스프링을 대신해서 오브젝트의 생성로직을 담당하도록 만들어진 특별한 빈
    • FactoryBean 인터페이스를 구현

    • public interface FactoryBean<T> {
          T getObject() throws Exception; // 빈 오브젝트를 생성해서 반환
          Class<? extends T> getObjectType(); // 생성되는 오브젝트 타입 반환
          bollean isSingleton(); // getObject()가 돌려주는 오브젝트가 항상 싱글톤인지 여부 반환
      }

    • public class Message {
          String text;
      
          private Message(String text) {
              this.text = text;
          }
      
          public String getText() {
              return text;
          }
      
          public static Message newMessage(String text) {
              return new Message(text);
          }
      }
      
      public class MessageFactoryBean implements FactoryBean<Message> {
          String text;
      
          public void setText(String text) {
              this.text = text;
          }
      
          public Message getObject() throws Exception {
              return Message.newMessage(this.text);
          }
      
          public Class<? extends Message> getObjectType() {
              return Message.class;
          }
      
          public boolean isSingleton() {
              return false;
          }
      }

      • 스프링은 private 생성자를 가진 클래스를 빈으로 등록해주면 리플렉션을 이용해 오브젝트로 만들어줌
        • 리플렉션이 private 접근 규약을 위반할 수 있기 때문
      • 하지만, 스태틱 메소드를 통해 오브젝트가 만들어져야 하는 중요한 이유가 있을 것이기 때문에 강제로 생성하면 위험
  • 팩토리 빈의 설정
    • FactoryBean 인터페이스를 구현한 클래스를 스프링 빈으로 만들어두면 getObject()라는 메소드가 생성해주는 오브젝트가 실제 빈의 오브젝트로 대치됨
    • 팩토리 빈이 만들어주는 빈 오브젝트가 아니라 팩토리 자체를 가져오고 싶은 경우, &를 빈 이름 앞에 붙여주면 팩토리 빈 자체를 반환함

      • @Test
        public void getFactoryBean() throws Exception {
            Object factory = context.getBean("&Message");
            assertThat(factory, is(MessageFactoryBean.class));
        }

  • 다이내믹 프록시를 만들어주는 팩토리 빈
    • 
    • 팩토리 빈은 다이내믹 프록시가 위임할 타깃 오브젝트인 UserServiceImpl에 대한 레퍼런스를 프로퍼티를 통해 DI 받아둬야함
      • TransactionHandler에게 타깃 오브젝트를 전달해줘야 하기 때문
      • TransactionHandler를 생성할 때 필요한 정보를 팩토리 빈의 프로퍼티로 설정해뒀다가 다이내믹 프록시를 만들면서 전달
  • 트랜잭션 프록시 팩토리 빈

    • public class TxProxyFactoryBean implements FactoryBean<Object> {
          Object target;
          PlatformTransactionManager transactionManager;
          String pattern; // 이상 3개는 TransactionHandler 생성시 필요
          Class<?> serviceInterface; // 다이내믹 프록시 생성시 필요
      
          // set properties
      
          public Object getObject() throws Exception {
              TransactionHandler txHandler = new TransactionHandler();
              txHandler.setTarget(target);
              txHandler.setTransactionManager(transactionManager);
              txHandler.setPattern(pattern);
              return Proxy.newProxyInstance(
                  getClass().getClassLoader(),
                  new Class[] { serviceInterface },
                  txHandler
              );
          }
      
          public Class<?> getObjectType() {
              return serviceInterface;
          }
      
          public boolean isSingleton() {
              return false; // getObject()가 매번 같은 오브젝트를 리턴하지 않음
          }
      }

  • 트랜잭션 프록시 팩토리 빈 테스트
    • 수동 DI를 통해 직접 다이내믹 프록시를 만들었던 코드에 팩토리 빈 적용
      • 타깃 Object에 대한 레퍼런스를 TransactionHandler 오브젝트가 가지고 있으므로, factory의 getObject에 의한 DI가 아닌, FactoryBean을 직접 가져와서 프록시를 생성하도록 수정

      • public class UserServiceTest {
            @Test
            @DirtiesContext
            public void upgradeAllOrNothing() throws Exception {
                TestUserService testUserService = new TestUserService(users.get(3).getId());
                testUserService.setUserDao(userDao);
                testUserService.setMailSender(mailSender);
        
                TxProxyFactoryBean txProxyFactoryBean = context.getBean("&userService", TxProxyFactoryBean.class);
                txProxyFactoryBean.setTarget(testUserService);
                UserService txUserService = (UserService) txProxyFactoryBean.getObject();
        
                userDao.deleteAll();
                users.forEach(user -> userDao.add(user));
        
                try {
                    txUserService.upgradeLevels();
                    fail("TestUserServiceException expected");
                } catch (TestUserServiceException e) {
        
                }
                checkLevelUpgraded(users.get(1), false);
            }
        }

• 프록시 팩토리 빈 방식의 장점과 한계
  • 부가기능을 가진 프록시를 생성하는 팩토리 빈을 만들어두면 타깃의 타입에 상관없이 재사용
  • 프록시 팩토리 빈의 재사용
    • UserService 외에 트랜잭션 경계설정 기능을 부여해줄 필요가 있는 클래스가 있을 경우, 앞서 만들었던 TxProxyFactoryBean을 적용
    • 코드 한 줄 만들지 않고 기존 코드에 부가적인 기능을 추가할 수 있음
  • 프록시 팩토리 빈의 장점
    • 데코레이터 패턴이 적용된 프록시의 문제점 두 가지
      • 프록시를 적용할 대상이 구현하고 있는 인터페이스 구현 프록시 클래스를 일일이 만들어야함
      • 부가적인 기능이 여러 메소드에 반복적으로 나타나서 코드 중복 발생
    • 프록시 팩토리 빈은 위의 두 문제점을 해결
      • 팩토리 빈 + DI를 통해 다양한 타깃 오브젝트 적용 및 중복코드 제거
  • 프록시 팩토리 빈의 한계
    • 프록시를 통해 타깃에 부가기능을 제공하는 것은 메소드 단위로 일어남
    • 한 번에 여러 클래스에 공통 부가기능을 제공하기에 어려움
      • 데코레이터를 이용하여 여러 메소드에 부가기능을 한번에 제공하는 것이 가능했지만, 팩토리 빈에서는 불가능해짐
    • XML 설정 라인이 대폭 증가
      • 이 부분은 Spring Boot + Java Config로 인해 현재는 문제 X
    • 타깃과 인터페이스만 다른 비슷한 설정 반복
    • TransactionHandler 오브젝트가 프록시 팩토리 빈 개수만큼 만들어짐