Spring에서 자주 사용되는 디자인 패턴

디자인 패턴이란

• 소프트웨어를 설계할 때 특정 맥락에서 자주 발생하는 고질적인 문제들이 또 발생했을 때 재사용할 할 수있는 훌륭한 해결책
• 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 ‘규약’ 형태로 만들어 놓은 것

디자인 패턴의 종류는 다양하지만, 그 중 스프링과 관련이 있는 패턴인 싱글톤 패턴, 템플릿 메소드 패턴, 팩토리 메소드 패턴, 프록시 패턴에 대해 살펴보고자 한다.

 

싱글톤 패턴

하나의 클래스에 오직 하나의 인스턴스만 갖도록 하고, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴이다.

 

사용처

보통 싱글톤 패턴이 적용된 객체가 필요한 경우는 그 객체가 리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 적합하다.

대표적으로 데이터베이스 접속, 디스크 연결, 네트워크 통신, DBCP 커넥션풀, 스레드풀, 캐시, 로그 기록 객체 등에 이용된다.

 

장점

• 한번의 new 연산자를 통해서 고정된 메모리 영역을 사용하기 때문에 추후 해당 객체에 접근할 때 메모리 낭비를 방지할 수 있다. 
•  다른 클래스 간에 데이터 공유가 쉽다.

단점

• 테스트가 어렵다.
  싱글톤 인스턴스는 자원을 공유하고 있기 때문에 테스트가 결정적으로 격리된 환경에서 수행되려면 매번 인스턴스의 상태를 초기화시켜주어야 한다. 그렇지 않으면 어플리케이션 전역에서 상태를 공유하기 때문에 테스트가 온전하게 수행되지 못한다.
• 멀티쓰레드 환경에서 컨트롤이 어렵다.
• 모듈 간 의존성이 높아진다.
  하나의 싱글톤 클래스를 여러 모듈들이 공유를 하니까, 만일 싱글톤의 인스턴스가 변경되면 이를 참조하는 모듈들도 수정이 필요하게 된다.
• S.O.L.I.D 원칙이 위배되는 경우가 많다.

일반적으로 Singleton Object는 어플리케이션에서 글로벌하게 유일해야하지만, Spring에서는 이러한 제약이 완화된다. Spring에서는 하나의 Spring IoC Container 당 하나의 Singleton Object를 갖도록 제한하여 Spring Framework는 모든 Bean들을 Singleton으로 생성한다.

위 그림과 같은 형태로 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다.

 

템플릿 메소드 패턴

템플릿 메소드 패턴은 특정 작업을 처리하는 일부분을 서브 클래스로 캡슐화하여 전체적인 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내용을 바꾸는 패턴이다. 상위 클래스에 공통적인 메소드가 정의되어 있고, 세부적인 메소드는 추상 메소드로 두어 하위클래스에서 구현한다.

 

장점

• 중복코드를 줄일 수 있다.
• 자식 클래스의 역할을 줄여 핵심 로직의 관리가 용이하다.
•  좀더 코드를 객체지향적으로 구성할 수 있다.

단점

• 추상 메소드가 많아지면서 클래스 관리가 복잡해진다.
•  클래스간의 관계와 코드가 꼬여버릴 염려가 있다.

 

 

이 패턴은 스프링 내부에서는 DispatcherServlet (HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러) 에서 사용되고 있다. 

DispatcherServlet의 doService() 메소드는 http 요청에 대해 처리하는 메소드인데, FrameworkServlet을 상속 받아 메소드 오버라이딩을 통해 기능을 구현한다.

 

또한 다른 예시로, JDBCTemplate 클래스를 이용하여 DB 연동은 해당 클래스 내의 템플릿 메소드를 사용하고, 개발자는 달라지는 SQL문과 설정값을 따로 세팅하여 활용할 수도 있다.

 

팩토리 메서드 패턴

팩토리 메서드는 부모 클래스에서 객체들을 생성할 수 있는 인터페이스를 제공하지만, 자식 클래스들이 생성될 객체들의 유형을 변경할 수 있도록 하는 생성 패턴이다.

부모 추상 클래스는 인터페이스에만 의존하고 실제로 어떤 구현 클래스를 호출할 지는 서브 클래스에서 구현하고, 인스턴스 생성을 서브 클래스에 위임하는 형태다.

• 장점: 수정에 닫혀있고 확장에는 열려있는 OCP 원칙을 지킬 수 있다.
• 단점: 간단한 기능을 사용할 때보다 많은 클래스를 정의해야 하기 때문에 코드량이 증가한다.

 

스프링 컨테이너(스프링의 빈을 생성하고 관리하는 컨테이너)인 ApplicationContext는 스프링 빈을 관리하고 조회하는 BeanFactory를 상속하여, bean을 주입 받기 위해 필요한 getBean() 팩토리 메소드를 사용할 수 있게 된다.

ApplicationContext는 BeanFactory + 부가 기능(국제화 기능, 환경 변수 관련 처리, 애플리케이션 이벤트, 리소스 조회)을 가진다.

public interface BeanFactory {

    Object getBean(String name) throws BeansException;

    <T> T getBean(String name, Class<T> requiredType) throws BeansException;

    Object getBean(String name, Object... args) throws BeansException;

    <T> T getBean(Class<T> requiredType) throws BeansException;

    <T> T getBean(Class<T> requiredType, Object... args) throws BeansException;
    
    //...
}

 

프록시 패턴

어떤 객체를 사용하고자 할때, 객체를 직접적으로 참조하는 것이 아닌 해당 객체를 대항하는 객체를 통해 대상 객체에 접근하는 방식이다. 이러한 방식을 사용하면  해당 객체가 메모리에 존재하지 않아도 기본적인 정보를 참조하거나 설정할 수 있다.

https://www.youtube.com/watch?v=tes_ekyB6U8

프록시 패턴을 사용하는 이유

프록시 객체는 원래 객체를 감싸고 있는 객체로, 원래 객체와 타입은 동일하다. 프록시 객체가 원래 객체를 감싸서 client의 요청을 처리하게 하는 패턴이다.

• 접근 권한을 부여할 수 있다
• 부가 기능을 추가할 수 있다
• 실제 객체의 기능이 필요한 시점까지 객체의 생성을 미룰 수 있다. 
• 로깅, 캐싱 등에 다양하게 응용 해 사용할 수 있다.

 

장점

• 사이즈가 큰 객체가 로딩되기 전에도 프록시를 통해 참조를 할 수 있다.
• 원래 객체에 접근에 대해 사전처리를 할 수 있다.

단점

• 객체를 생성할 때 한 단계를 거치게 되므로, 빈번한 객체 생성이 필요한 경우 성능이 저하될 수 있다.
• 프록시 내부에서 객체 생성을 위해 스레드가 생성, 동기화가 구현되어야 하는 경우 성능이 저하될 수 있다.
• 로직이 난해해져 가독성이 떨어질 수 있다.

 

스프링 내에서는 AOP 방식에 주로 사용된다.

특히 대표적인 것에는 @Transactional이 있는데, @Transactional을 메소드 또는 클래스에 명시하면 AOP를 통해 타겟이 상속하고 있는 인터페이스 또는 타겟을 상속한 프록시 객체가 생성된다. 이때 프록시 객체의 메소드를 호출하면 타겟 메소드 전 후로 트랜잭션 처리를 수행한다.

 

 

 

참고자료

https://tecoble.techcourse.co.kr/post/2020-11-07-singleton/

싱글톤(Singleton) 패턴이란?

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%8B%B1%EA%B8%80%ED%86%A4Singleton-%ED%8C%A8%ED%84%B4-%EA%BC%BC%EA%BC%BC%ED%95%98%EA%B2%8C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

[GOF] 💠 싱글톤(Singleton) 패턴 - 꼼꼼하게 알아보자

https://coding-factory.tistory.com/712

[Design Pattern] 템플릿 메소드 패턴(Template Method Pattern)에 대하여

https://velog.io/@sangmin7648/Spring%EC%9D%98-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4%EB%93%A4

https://velog.io/@weekbelt/%ED%8C%A9%ED%86%A0%EB%A6%AC-%EB%A9%94%EC%84%9C%EB%93%9CFactory-Method-%ED%8C%A8%ED%84%B4

팩토리 메서드(Factory Method) 패턴

https://velog.io/@newtownboy/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-%ED%94%84%EB%A1%9D%EC%8B%9C%ED%8C%A8%ED%84%B4Proxy-Pattern