본문 바로가기

Spring/Core

 (43)
[Core] 템플릿 콜백 패턴 이전 장(링크) 에서는 전략 패턴에 대해서 알아보았다. 이번 장에서는 템플릿 콜백 패턴에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. 콜백 이전 장에서 전략 패턴을 살펴보면서 마지막 부분에서 전략인 Strategy를 Context의 파라미터로 전달하여 실행되도록 하였다. 이렇게 다른 코드의 파라미터로 넘기는 실행 가능한 코드를 콜백(callback)이라고 한다. 콜백 정의 프로그래밍에서 콜백(callback) 또는 콜애프터 함수(call-after function)는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고, 아니면 나중에 실행할 수도 있다. 위키백과 자바에서 실행 가능한 코드를 파라미터로 전달하려면 ..
[Core] 전략 패턴 이전 장(링크) 에서 살펴본 템플릿 메서드 패턴에 이어 전략 패턴에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. 전략 패턴(Strategy Pattern) 템플릿 메서드 패턴에서는 상위 클래스에 변화지 않는 기능(템플릿)을 만들고 자주 변하는 부로직은 하위 클래스에 만들고 상속을 사용하였다. 상속을 활용한 패턴이기 때문에 상속이 가지고 있는 단점을 그대로 가지게 되었다. 전략 패턴은 변하지 않는 부분을 Context라는 곳에 두고, 변하는 부분을 Strategy라는 인터페이스를 만들고 이를 구현한 구현체에게 위임하는 방식이다. Context는 자주 변하지 않는 주로직(템플릿) 역할을 하고, Strategy는 자주 변하는 주로직(서비스 로직) 역할을 한다. 알고리즘 제품군을 정의하고 각각을..
[Core] 템플릿 메서드 패턴 이번 장부터는 템플릿 메서드 패턴을 시작으로 스프링이 많이 사용하거나 스프링을 사용하면서 많이 사용하게 되는 디자인 패턴에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. 정의 템플릿 메서드 패턴의 목적은 다음과 같다. 작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기한다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있다. 상위 클래스에서 자주 변경되지 않는 템플릿을 정의하고 자주 변경되는 로직은 하위 클래스에서 정의하는 것이다. 이러한 방식으로 설계하면 하위 클래스가 전체 구조를 변경하지 않고, 필요한 특정 부분만 재정의할 수 있다. 상속과 오버라이딩을 통한 다형성을 활용한 디자인 패턴이다. 좋은 설계 일반..
[Core] ThreadLocal 이전 장(링크) 에서는 필드 동기화를 도입하면서 다중 스레드가 경합하는 경우에 동시성 문제가 발생하는 것을 확인하였다. 이번 장에서는 동시성 문제를 해결하기 위한 방법 중 하나인 ThreadLocal에 대해서 알아보도록 한다. 모든 코드는 깃허브(링크) 에 올려두었다. ThreadLocal ThreadLocal은 해당 스레드만 접근할 수 있는 저장소를 의미하며 스레드 관점에서는 프라이빗 저장소가 된다. 일반 변수 필드에 값을 저장하면 아래의 이미지처럼 모든 스레드가 공유하게 된다. ThreadLocal을 사용하면 각 스레드마다 별도의 저장소를 사용하기 때문에 다중 스레드가 같은 인스턴스의 ThreadLocal 필드에 접근하여도 동시성 문제가 발생하지 않는다. ThreadLocal 예제 이전 장에서 사용한..
[Core] 필드 동기화와 동시성 문제 이전 장(링크) 에서는 서비스의 로그를 출력하는 방법에 대해서 알아보았다. 이번 장에서는 이전 장에서 발생한 문제를 해결하기 위해 필드 동기화를 도입하고 동시성 문제에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. 개요 이전 장에서는 요청에 대한 트랜잭션 아이디를 로그에 출력하기 위해 파라미터로 TraceId를 넘겼다. 하지만 로그를 위한 트랜잭션 아이디는 서비스 로직과는 무관하기 때문에 서비스 로직을 위한 메서드의 파라미터로 전달하는 것은 AOP 관점에서 잘못된 방식이다. 이번 장에서는 주로직(서비스 로직)과 부로직(로그를 출력하는 로직)을 분리하기 위해 필드 동기화를 도입해본다. 구현 LogTrace 로그를 출력하기 위한 기능 명세를 가지고 있는 LogTrace 추상 클래스를 생성한다...
[Core] 서비스 로그 이번 장에서는 APM 툴의 힘을 빌리지 않고 직접 서비스 로그를 출력하는 기능을 구현하는 방법에 대해서 알아본다. 모든 코드는 깃허브(링크) 에 올려두었다. 개요 시중에 많은 APM 툴을 사용하면 아래와 같이 하나의 요청(트랜잭션)이 들어오고 나가는 모든 과정을 기록해준다. 네이버 Pinpoint 이번 장에서는 이러한 APM 툴의 도움없이 마치 툴이 만들어주는 것과 같은 기능을 만들어본다. 우리가 기능을 구현하고 나면 아래와 같이 요청이 들어오고 나갈 때까지의 과정이 출력되어야 한다. [2fa0a4b2] OrderController.request() [2fa0a4b2] |--> OrderService.orderItem() [2fa0a4b2] | |--> OrderRepository.save() [2fa0..
[Core] Web Scope 이번 장에서는 빈의 프로토타입 스코프(링크)에 이어 웹 스코프에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 사항은 강의나 공식문서에서 확인한다. 모든 코드는 깃허브 (링크)에 올려두었다. 웹 스코프 웹 스코프는 이름에서 알 수 있듯이 웹 환경에서만 동작한다. 웹 스코프는 프로토타입 스코프와는 다르게 해당 스코프의 종료시점까지 관리되기 때문에 소멸 메서드가 호출된다. 웹 스코프의 종류는 아래와 같다. request: HTTP요청이 들어와서 나갈 때까지 유지되는 스코프이며 요청마다 별도의 빈 객체가 생성되고 관리된다. session: HTTP의 Session과 동일한 생명주기를 갖는 스코프 application: 서블릿 컨텍스트와 동일한 생명주기를 갖는 스코프 we..
[Core] Prototype Scope 이번 장에서는 빈의 프로토타입 스코프에 대해서 알아본다. 글의 하단부에 참고한 강의와 공식문서의 경로를 첨부하였으므로 자세한 사항은 강의나 공식문서에서 확인한다. 모든 코드는 깃허브 (링크)에 올려두었다. 빈 스코프 우리는 지금까지 스프링이 실행되면서 DI 컨테이너가 실행되어 빈을 관리하고 DI 컨테이너가 종료되면서 빈이 사라지는 것을 확인하였다. 이것은 빈의 기본 스코프가 싱글톤 스코프로 생성되기 때문이다. 스코프는 빈이 존재할 수 있는 범위를 뜻한다. 싱글톤: 기본 스코프로 DI 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프. 프로토타입: 빈의 생성과 의존관계 주입까지 유지되는 스코프. 이외의 웹 관련 스코프는 다음 장에서 알아보도록 한다. 프로토타입 스코프 프로토타입 스코프의 경우 빈..

티스토리툴바