Spring

스프링빈 등록 예제 3가지

스프링빈을 등록하는 3가지 방법은 모두 실무에서 자주 사용된다.

인터페이스와 구현 클래스 - 스프링빈 수동 등록

아래의 코드는 인터페이스와 그 구현 클래스들을 스프링빈에 수동 등록하는 방법이다.

public interface OrderRepositoryV1 {
    void save(String itemId);
}

public class OrderRepositoryV1Impl implements OrderRepositoryV1 {
    @Override
    public void save(String itemId) {
        //저장 로직
        if (itemId.equals("ex")) {
            throw new IllegalStateException("예외 발생!");
        }
        sleep(1000);
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

public interface OrderServiceV1 {
    void orderItem(String itemId);
}
public class OrderServiceV1Impl implements OrderServiceV1 {

    private final OrderRepositoryV1 orderRepository;

    public OrderServiceV1Impl(OrderRepositoryV1 orderRepository) {
        this.orderRepository = orderRepository;
    }

    @Override
    public void orderItem(String itemId) {
        orderRepository.save(itemId);
    }
}

@RequestMapping//스프링은 @Controller 또는 @RequestMapping 이 있어야 스프링 컨트롤러로 인식
@ResponseBody
public interface OrderControllerV1 {

    @GetMapping("/v1/request")
    String request(@RequestParam("itemId") String itemId);

    @GetMapping("/v1/no-log")
    String noLog();
}
public class OrderControllerV1Impl implements OrderControllerV1 {

    private final OrderServiceV1 orderService;

    public OrderControllerV1Impl(OrderServiceV1 orderService) {
        this.orderService = orderService;
    }

    @Override
    public String request(String itemId) {
        orderService.orderItem(itemId);
        return "ok";
    }

    @Override
    public String noLog() {
        return "ok";
    }
}

• @RequestMapping : 스프링MVC는 타입에 @Controller 또는 @RequestMapping 애노테이션이 있어야 스프링 컨트롤러로 인식한다. 그리고 스프링 컨트롤러로 인식해야 HTTP URL이 매핑되고 동작한다. 이 애노테이션은 인터페이스에 사용해도 된다.
• @RequestBody : HTTP 메시지 컨버터를 사용해서 응답한다. 이 애노테이션은 인터페이스에 사용해도된다.
• @RequestParam("itemId") String itemId : 인터페이스에는 @RequestParam("itemId")의 값을 생략하면 itemId 단어를 컴파일 이후 자바 버전에 따라 인식하지 못할 수 있다. 인터페이스에서는 꼭 넣어주자. 클래스에는 생략해도 대부분 잘 지원된다.(기본 타입은 생략해도 된다. 참조 타입은 안된다.)

@Configuration
public class AppV1Config {

    @Bean
    public OrderControllerV1 orderControllerV1() {
        return new OrderControllerV1Impl(orderServiceV1());
    }

    @Bean
    public OrderServiceV1 orderServiceV1() {
        return new OrderServiceV1Impl(orderRepositoryV1());
    }

    @Bean
    public OrderRepositoryV1 orderRepositoryV1() {
        return new OrderRepositoryV1Impl();
    }

}

위 코드는 일반적으로 사용했던 스프링빈을 수동으로 등록하는 코드이다.
물론 AppV1Config도 스프링빈으로 등록된다.

@Import(AppV1Config.class)
//@Import({AppV1Config.class, AppV2Config.class})
//@Import(InterfaceProxyConfig.class)
//@Import(ConcreteProxyConfig.class)
//@Import(DynamicProxyBasicConfig.class)
//@Import(DynamicProxyFilterConfig.class)
//@Import(ProxyFactoryConfigV1.class)
//@Import(ProxyFactoryConfigV2.class)
//@Import(BeanPostProcessorConfig.class)
//@Import(AutoProxyConfig.class)
//@Import(AopConfig.class)
@SpringBootApplication(scanBasePackages = "hello.proxy.app") //주의
public class ProxyApplication {

	public static void main(String[] args) {
		SpringApplication.run(ProxyApplication.class, args);
	}

	@Bean
	public LogTrace logTrace() {
		return new ThreadLocalLogTrace();
	}

}

• @Import(AppV1Config.class) : 클래스를 스프링 빈으로 등록한다. 여기서는 AppV1Config.class를 스프링빈으로 등록한다. 일반적으로 @Configuration 같은 설정 파일을 등록할 떄 사용하지만, 스프링 빈을 등록할때도 사용할 수 있다.
• @SpringBootApplication(scanBasePackages = "hello.proxy.app"): @ComponentScan의 기능과 같다. 컴포넌트 스캔을 시작할 위치를 지정한다. 이값을 설정하면 해당 패키지와 그 하위 패키지를 컴포넌트 스캔한다. 이 값을 사용하지 않으면 ProxyApplication이 있는 패키지와 그 하위 패키지를 스캔한다.

참고
스프링부트 3.0(스프링 프레임 워크 6.0)부터는 클래스 레벨에 @RequestMapping이 있어도 스프링 컨트롤러로 인식하지 않는다. 오직 @Controller가 있어야 스프링 컨트롤러로 인식한다. 참고로 @RestController는 해당 애노테이션 내부에 @Controller를 포함하고 있으므로 인식된다.

인터페이스 없는 구체 클래스 - 스프링 빈 수동 등록

내용 없음

컴포넌트 스캔 - 스프링 빈 자동 등록

@RestController, @Service, @Repository 애노테이션을 사용해서 구체 클래스를 작성한다. 따라서 컴포넌트 스캔의 대상이 되어 자동으로 스프링빈으로 등록된다.

프록시, 프록시 패턴, 데코레이터 패턴 소개

다음 상황을 가정한다.
웹 애플리케이션에서 동작하는 Controller, Service, Repository에서 수행하는 모든 함수에서 로깅을 하도록 기능을 추가한다.
하지만, 이 요구 사항을 만족하기 위해서는 기능 코드를 많이 수정해야한다.
코드 수정을 최소화하기 위해서 템플릿 메서드 패턴, 콜백 패턴(전략 패턴)을 사용했지만 여전히 많은 클래스의 수정이 불가피하다.
원본 코드를 수정하지 않고 로그 추적기를 도입하려면 프록시를 사용해야한다.

프록시

클라이언트와 서버라고 하면 개발자들은 보통 서버 컴퓨터를 생각한다. 사실 클라이언트와 서버의 개념은 상당히 넓게 사용된다. 클라이언트는 의뢰인이라는 뜻이고 서버는 서비스나 상품을 제공하는 사람이나 물건을 뜻한다. 따라서 클라이언트와 서버의 기본 개념을 정의하면 클라이언트는 서버에 필요한것을 요청하고, 서버는 클라이언트의 요청을 처리하는 것이다.

이 개념을 우리가익숙한 컴퓨터 네트워크에 도입하면 클라이언트는 웹 브라이저 가 되고 요청을 처리하는 서버는 웹 서버가 된다.
이 개념을 객체에 도입하면 요청하는 객체는 클라이언트가 되고 요청을 처리하는 개체는 서버가 된다.

클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고 처리 결과를 직접 받는다. 이것을 직접 호출이라 한다.

그런데 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있다. 예를 들어 내가 직접 마트에서 장을 볼 수도 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수도 있다.
여기서 대신 장을 보는 대리자를 영어로 프록시라 한다.

프록시의 기능은 일반적으로 접근제어 ,캐시, 부가 기능 추가, 프록시 체인등의 기능을 수행한다.

객체에서 프록시가 되려면 클라이언트는 서버에게 요청을 한것인지, 프록시에게 요청을 한 것인지 조차 몰라야한다.
쉽게 이야기 해서 서버와 프록시는 같은 인터페이스를 사용해야한다. 그리고 클라이언트가 사용하는 서버 객체는 프록시 객체로 변경해도 클라이언트 코드를 변경하지 않고 동작할 수 있어야 한다. 이를 대체 가능이라 한다.

클래스 의존관계를 보면 클라이언트는 서버 인터페이스에만 의존한다. 그리고 서버와 프록시가 같은 인터페이스를 사용한다. 따라서 DI를 사용해서 대체 가능하다.

이번에는 런타임 객체 의존관계를 살펴보자. 런타임(애플리케이션 실행 시점)에 클라이언트 객체에 DI를 사용해서 client->Server에서 Client->Proxy로 객체 의존관계를 변경해도 클라이언트 코드를 전혀 변경하지 않아도 된다. 클라이언트 입장에서는 변경 사실 조차 모른다.(스프링의 DI를 사용하기 떄문에!) DI를 사용하면 클라이언트 코드의 변경 없이 유연하게 프록시를 주입할 수 있따.

프록시의 주요 기능

프록시를 통해서 할 수 있는 일은 크게 2가지로 분류할 수 있다.

• 접근 제어
  - 권한에 따른 접근 차단
  • 캐싱
  • 지연 로딩
• 부가 기능 추가
  - 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.

둘다 프록시를 사용하는 방법이지만 GOF디자인 패턴에서는 이 둘의 의도에 따라서 프록시패턴과 데코레이터 패턴으로 구분한다.

• 프록시 패턴 : 접근 제어가 목적
• 데코레이터 패턴 : 새로운 기능 추가가 목적

둘다 프록시를 사용하지만 의도가 다르다는 점이 핵심이다. 용어가 프록시 패턴이라고 해서 이 패턴만 프록시를 사용하는 것은 아니다. 데코레이터 패턴도 프록시를 사용한다.

프록시 패턴

간단한 예시를 통해서 프록시 패턴을 학습해본다.

public interface Subject {
    String operation();
}

@Slf4j
public class RealSubject implements Subject {
    @Override
    public String operation() {
        log.info("실제 객체 호출");
        sleep(1000);
        return "data";
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

RealSubect는 Subject 인터페이스를 구현했다. operation()은 데이터 조회를 시뮬레이션하기 위해 1초 쉬도록한다. 예를 들어서 데이터를 DB나 외부에서 조회하는데 1초가 걸린다고 생각하면 된다.

public class ProxyPatternClient {

    private Subject subject;

    public ProxyPatternClient(Subject subject) {
        this.subject = subject;
    }

    public void execute() {
        subject.operation();
    }
}

클라이언트는 Subject인터페이스에 의존하고 Subject를 호출하는 클라이언트코드이다. execute()를 실행하면 subject.operation()를 호출한다.

public class ProxyPatternTest {

    @Test
    void noProxyTest() {
        RealSubject realSubject = new RealSubject();
        ProxyPatternClient client = new ProxyPatternClient(realSubject);
        client.execute();
        client.execute();
        client.execute();
    }
}

실행 결과는 아래와 같다.

RealSubject - 실제 객체 호출(1초)
RealSubject - 실제 객체 호출(1초)
RealSubject - 실제 객체 호출(1초)

그런데 이 데이터가 한번 조회하면 변하지 않는 데이터라면 어딘가에 보관해두고 이미 조회한 데이터를 사용하는 것이 성능상 좋다. 이런것을 캐시랗고 한다 .프록시 패턴의 주요 기능은 접근 제어이다 .캐시도 접근 자체를 제어하는 기능 중 하나이다.
이미 개발된 로직을 전혀 수정하지 않고 프록시 객체를 통해서 캐시를 적용해보자.

@Slf4j
public class CacheProxy implements Subject {

    private Subject target;
    private String cacheValue;

    public CacheProxy(Subject target) {
        this.target = target;
    }

    @Override
    public String operation() {
        log.info("프록시 호출");
        if (cacheValue == null) {
            cacheValue = target.operation();
        }
        return cacheValue;
    }
}

앞서 설명한것처럼 프록시도 실제 객체와 그 모양이 같아야하기 떄문에 Subject 인터페이스를 구현해야한다.

• private Subject target: 클라이언트가 프록시를 호출하면 프록시가 최종적으로 실제 객체를 호출해야한다. 따라서 내부에 실제 객체 참조를 가지고 있어야 한다.이렇게 프록시가 호출하는 대상을 target이락 한다.
• operation() : 구현한 코드를 보면 cacheValue에 값이 없으면 실제 객 체의 target을 호출해서 값을 구한다. 그리고 구한 값을 cacheValue에 저장하고 반환한다. 만약 cacheValue에 값이 있으면 실제 값을 전혀 호출하지 않고 캐시 값을 그대로 반환한다. 따라서 처음 조회 이후에 캐시에서 매우 빠르게 데이터를 조회할 수 있다.

    void cacheProxyTest() {
        RealSubject realSubject = new RealSubject();
        CacheProxy cacheProxy = new CacheProxy(realSubject);
        ProxyPatternClient client = new ProxyPatternClient(cacheProxy);
        client.execute();
        client.execute();
        client.execute();
    }

cacheProxyTest() 는 realSubject와 cacheProxy를 생성하고 둘을 ㅇ녀결한다. 결과적으로 cacheProxy가 realSubject를 참조하는 런타임 의존관계가 완성된다. 그리고 마지막으로 client에 realSubject가 아닌 cacheProxy를 주입한다. 이 과정을 통해 client->cacheProxy->realsubject 런타임 의존관계가 완성된다.

결과적으로 캐시 프록시 도입 이후에는 최초에 한번만 1초가 걸리고 이후에는 거의 즉시 반환한다.

정리
프록시 패턴의 핵심은 RealSubject코드와 클라이언트 코드를 전혀 변경하지 않고 프록시를 도입해서 접근 제어를 했다는 점이다. 그리고 클라이언트 코드의 변경 없이 자유롭게 프록시를 넣고 뺄 수 있다. 실제 클라이언트 입장에서는 프록시가 주입되었는지 실제 객체가 주입되었는지 알지 못한다.

데코레이터 패턴

데코레이터 패턴을 이해하기 위한 예제코드를 본다.

public interface Component {
    String operation();
}

@Slf4j
public class RealComponent implements Component {
    @Override
    public String operation() {
        log.info("RealComponent 실행");
        return "data";
    }
}

@Slf4j
public class DecoratorPatternClient {

    private Component component;

    public DecoratorPatternClient(Component component) {
        this.component = component;
    }

    public void execute() {
        String result = component.operation();
        log.info("result={}", result);
    }
}

@Slf4j
public class DecoratorPatternTest {

    @Test
    void noDecorator() {
        Component realComponent = new RealComponent();
        DecoratorPatternClient client = new DecoratorPatternClient(realComponent);
        client.execute();
    }
}

위 코드의 실행 결과는 아래와 같다.

RealComponent - RealComponent 실행
DecoratorPatternClient - result=data

앞서 공부한것처럼 프록시를 통해서 할 수 있는 기능을 크게 접근 제어와 부가 기능 추가라는 2가지로 구분한다.앞선 예제에서는 프록시 패턴에서 캐시를 통한 접근 제어를 공부했다. 이번에는 프록시를 활용해서 부가 기능을 추가해본다. 이렇게 프록시로 부가 기능을 추가하는것을 데코레이터 패턴이라 한다.

데코레이터 패턴 : 원래 서버가 제공하는 기능에 더해서 부가 기능을 수행한다.

• 예) 요청 값이나 응답 값을 중간에 변형한다.
• 예) 실행 시간을 측정해서 추가 로그를 남긴다.

@Slf4j
public class MessageDecorator implements Component {

    private Component component;

    public MessageDecorator(Component component) {
        this.component = component;
    }

    @Override
    public String operation() {
        log.info("MessageDecorator 실행");

        //data -> *****data*****
        String result = component.operation();
        String decoResult = "*****" + result + "*****";
        log.info("MessageDecorator 꾸미기 적용 전={}, 적용 후={}", result, decoResult);
        return decoResult;
    }
}

MessageDecorator는 Component인터페이스를 구현한다.
프록시가 호출해야하는 대상을 component에 저장한다.
operation()을 호출하면 프록시와 연결된 대상을 호출하고 그 응답값에 ***을 더해서 꾸며준 다음 반환한다.

    @Test
    void decorator1() {
        Component realComponent = new RealComponent();
        Component messageDecorator = new MessageDecorator(realComponent);
        DecoratorPatternClient client = new DecoratorPatternClient(messageDecorator);
        client.execute();
    }

아래는 실행 결과다.

MessageDecorator - MessageDecorator 실행
RealComponent - RealComponent 실행
MessageDecorator - MessageDecorator 꾸미기 적용 전=data, 적용 후=*****data*****
DecoratorPatternClient - result=*****data*****

여기서 생각해보면 Decorator 기능에는 일부 중복이 있다. 꾸며주는 역할을 하는 Decorator들은 스스로 존재할 수 없다. 항상 꾸며줄 대상이 있어야 한다. 따라서 내부에 호출 대상인 component를 가지고 있어야 한다. 그리고 component를 항상 호출 해야한다. 이부분이 중복이다. 이런 중복을 제거하기 위해 component를 속성으로 가지고 있는 decorator라는 추상 클래스를 만드는 방법도 고민할 수 있다. 이렇게 하면 추가로 클래스 다이어그램에서 어떤 것이 실제 컴포넌트인지 데코레이터인지 명확하게 구분할 수 있다.

프록시 패턴과 데코레이터 패턴 정리

사실 프록시 패턴과 데코레이터패턴은 그 모양이 거의 같고 상황에 따라 정말 똑같을 떄도 있다. 그러면 둘을 어떻게 구분할까?
디자인 패턴에서 중요한것은 해당 패턴의 모양이 아니라 그 패턴을 만든 의도가 더 중요하다 .따라서 의도에 따라 패턴을 구분한다.

• 프록시 패턴의 의도 : 다른 객체에 대한 접근을제어하기 위해 대리자를 제공
• 데코레이터 패턴의 의도 : 객체 추가 책임(기능)을 동적으로 추가하고 기능을 확장하기 위한 유연한 대안을 제공

정리
프록시를 사용하고 해당 프록시가 접근제어 목적이라면 프록시 패턴이고 새로운 기능을 추가하는것이 목적이라면 데코레이터패턴이 된다.

인터페이스 기반 프록시

• 프록시 패턴을 사용하면서 객체의 의존관계를 설정하는게 굉장히 중요한데, 프록시를 실제 스프링 빈 대신에 등록해줘야한다. 실제 객체는 스프링빈으로 등록하지 않는다.
• 프록시 내부에서 실제 객체를 참조해서 사용하도록 한다.
• 스프링 빈으로 실제 객체 대신에 프록시 객체를 등록하기 떄문에 스프링빈으로 주입 받으면 실제 객체 대신에 프록시 객체가 주입된다.

구체 클래스 기반 프록시

인터페이스가 없어도 프록시를 사용할 수 있을까? 당연하다.
구체 클래스를 상속받는 프록시 객체를 만들면 된다.

참고
자바언어에서 다형성은 인터페이스나 클래스를 구분하지 않고 모두 적용된다. 해당 타입과 그 타입의 하위 타입은 모두 다형성의 대상이 된다.

다만, 클래스 기반 프록시의 단점이 존재한다.

• super(null) : 자바 기본 문법에 의해 자식 클래스를 생설할떄는 항상 super()로 부모 클래스의 생성자를 호출한다. 이 부분을 생략하면 기본 생성자가 호출된다. 그런데 부모 클래스에 기본 생성자가 없고 생성자에서 파라미터 1개를 필수로 받는다면? 따라서 파라미터를 넣어서 super(..)라는 의미없는 코드를 호출해주게 된다.
• 프록시는 부모 객체의 기능을 사용하지 않기 때문에 super(null)을 입력해도 된다.
• 인터페이스 기반 프록시는 이런 고민을 하지 않아도 된다.

인터페이스 기반 프록시 VS 구체 클래스 기반 프록시

• 인터페이스가 없어도 클래스 기반으로 프록시를 생성할 수 있다.
• 클래스 기반 프록시는 해당 클래스에만 적용할 수 있다. 인터페이스 기반 프록시는 인터페이스만 같으면 모든곳에 적용할 수 있다.
• 클래스 기반 프록시는 상속을 사용하기 떄문에 몇가지 제약이 있다.
  - 부모 클래스의 생성자를 호출해야 한다.
  • 클래스에 final 키워드가 붙으면 상속이 불가능하다.
  • 메서드에 final 키워드가 붙으면 해당 메서드를 오버라이딩 할 수 없다.

이렇게 보면 인터페이스 기반의 프록시가 더 좋아보인다. 맞다. 인터페이스 기반의 프록시는 상속이라는 제약에서 자유롭다. 프로그래밍 관점에서도 인터페이스를 사용하는 것이 역할과 구현을 명확하게 나누기 때문에 더 좋다.
인터페이스 기반 프록시의 단점은 인터페이스가 필요하다는 그 자체이다. 인터페이스가 없으면 인터페이스 기반 프록시를 만들 수 없다.

참고

해당 포스팅은 아래의 강의를 공부하여 정리한 내용입니다.
김영한님의 - 프록시패턴과 데코레이터패턴