상황

Redis Cache 를 사용해서 List<?> 를 저장하려고 했습니다.

직렬화해서 데이터 저장까지는 잘 되었는데 다시 역직렬화 하려고 하니 에러가 발생하며 실패했습니다.


@Cacheable(cacheNames = "members", key = "'all'")
public List<Member> findAll() {
    List<Member> members = store.values().stream().toList();
    return members;
}

캐싱한 데이터는 위와 같습니다.

List<Member> 를 응답으로 내려주고 members 라는 캐시의 all 이라는 키값으로 저장됩니다.

Redis 설정으로 Value 는 GenericJackson2JsonRedisSerializer 를 사용하여 직렬화했습니다.


Redis 를 확인해보면 제대로 저장된 것을 확인할 수 있습니다.


에러 로그

com.fasterxml.jackson.databind.exc.MismatchedInputException: Unexpected token (START_OBJECT), expected VALUE_STRING: need JSON String, Number of Boolean that contains type id (for subtype of java.lang.Object)
 at [Source: (byte[])"[{"@class":"com.example.springbootcache.model.Member","id":1,"name":"ChulSoo","age":50}]"; line: 1, column: 2]

원인

List<?> 를 그대로 저장해서 그렇습니다.

사실 정확한 원인은 저도 모릅니다.

그래도 확신은 없지만 나름대로 추측을 해보겠습니다.

GenericJackson2JsonRedisSerializer 는 직렬화 할 때 @class 라는 Key 값에 클래스의 패키지 정보까지 전부 저장됩니다.

그런데 List 를 통째로 저장하면 위 사진과 같이 { "@class": "..." } 이 아니라 [{ "@class": "..."}] 로 저장되어 찾지 못해서 발생하는 이슈 같습니다.


해결

List 를 감싸는 Wrapper 클래스를 만들어 주면 해결됩니다.


Members 클래스 정의

@Getter
@NoArgsConstructor
public class Members {
    private List<Member> members = new ArrayList<>();

    public Members(List<Member> members) {
        this.members = members;
    }
}

캐싱 대상 변경

@Cacheable(cacheNames = "members", key = "'all'")
public Members findAll() {
    List<Member> members = store.values().stream().toList();
    return new Members(members);
}

Redis 저장 확인

Overview

Docker 공식 홈페이지에 있는 Ubuntu 설치를 보고 따라하면 됩니다


1. Docker 설치

$ sudo apt-get update
$ sudo apt-get install \
    ca-certificates \
    curl \
    gnupg

2. Docker 공식 GPG 키 추가

$ sudo mkdir -m 0755 -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

3. Docker Repository 설치

$ echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

4. Docker 설치

$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

5. Docker 실행 테스트

$ sudo docker run hello-world

# 실행된 도커 컨테이너 확인
$ sudo docker ps

# 이미지 확인
$ sudo docker images

테스트 용으로 hello-world 라는 이미지를 실행합니다.

docker image 를 따로 받지 않아도 없으면 자동으로 pull 을 먼저 땡깁니다.

Issue

Ruby Grape 와 Grape Entity 를 사용할 때 클래스를 참조하지 못하고 자꾸 NameError (uninitialized constant {Class}) 에러가 발생했습니다.

처음에는 Rails 버전과 Grape 버전이 호환되지 않아서 발생하는 이슈인가 해서 다운그레이드도 해봤지만 해결되지 않았습니다.


Solution

제가 이런 오류를 겪게된 이유는 크게 두가지였는데요.

첫번째는 제가 Ruby 에 익숙하지 않아서 발생한 일이고 다른 하나는 Grape 문서를 제대로 읽지 않아서 발생했습니다.


1. Ruby File 형식을 준수하고 파일 이름과 Class 이름이 일치해야 함

SimpleResponseEntity 라는 클래스를 사용한다고 하면 파일 이름을 simple_response_entity.rb 로 만들어야 합니다.

무심코 Java 에서의 버릇처럼 Camel Case 로 작성했던게 문제였습니다.


2. Grape 프레임워크는 Module 과 파일의 경로가 일치해야 함

Ruby Grape Docs > Mounting > Rails 파트를 보면 다음과 같은 문장이 있습니다.

Place API files into app/api. Rails expects a subdirectory that matches the name of the Ruby module and a file name that matches the name of the class. In our example, the file name location and directory for Twitter::API should be app/api/twitter/api.rb.


즉, Grape 관련된 기능을 사용하기 위해선 파일을 app/api 하위에 만들어야 하며 subdirectory 와 module 이름까지 일치해야 한다는 뜻입니다.

Rails 자체도 파일이나 경로를 굉장히 중요시하는 것처럼 Grape 도 비슷한 특징을 갖고 있는 것 같습니다.


Reference

Overview

MySQL 테이블을 설계할 때 보통 자주 사용하는 조건 컬럼에는 Index 를 추가합니다.

다양한 쿼리를 사용하는 경우 인덱스를 여러 개 추가하는데, 인덱스의 컬럼이 겹치면 원하지 않는 인덱스를 타서 Slow Query 가 발생할 수 있습니다.

Slow Query 의 발생가능한 원인과 해결 방법에 대해 간단히 알아봅니다.


1. Optimizer

SQL 쿼리를 호출하면 DBMS 에 존재하는 Optimizer 가 SQL 실행계획을 만들어줍니다.

옵티마이저는 두 가지 종류로 나뉩니다.

  • RBO (Rule Based Optimizer)
    • 미리 정해진 규칙대로만 쿼리를 수행
    • 인덱스가 존재하면 무조건 인덱스를 탐
    • 예측 가능하기 때문에 설계하기 쉽지만 그만큼 쿼리 자체를 잘 짜야함
  • CBO (Cost Based Optimizer)
    • 통계 정보 (Record 수, Index 컬럼 값 갯수) 를 기반으로 옵티마이저가 생각하는 가장 효율적인 쿼리를 수행
    • 인덱스가 존재해도 Table Full Scan 이 더 효율적이라고 생각하면 Full Scan 함
    • 예측이 힘들기 때문에 우리가 생각한 실행계획과 달라 Slow Query 가 발생할 수 있음
      • 특히 로컬, 개발 환경과 실제 운영 환경에서는 데이터의 갯수가 달라 같은 쿼리여도 다르게 수행될 수 있음

최근 대부분의 RDBMS 는 CBO 를 사용한다고 합니다.

예를 들어 우리가 WHERE ~ AND ~ 조건을 사용할 때 Index 컬럼 순서를 지키지 않았지만 자동으로 인덱스를 태우는 것도 다 CBO 덕분입니다.

하지만 CBO 를 사용하는 경우 우리 생각과는 다르게 동작할 수 있습니다.

여러 인덱스가 존재할 때 A 인덱스를 타는게 더 효율적임에도 B 인덱스를 타는 경우가 있습니다.

이런 경우에 사용하는 것이 바로 Index Hint 입니다. (쿼리 최적화의 또다른 방법으로 Optimizer Hint 라는 것도 있는데 이번 포스팅에서는 다루지 않습니다)


2. Index Hint

인덱스 힌트는 이름 그대로 옵티마이저가 인덱스를 선택할 때 도움을 줍니다.

특정 인덱스를 사용하지 않길 원하면 IGNORE, 사용하길 원하면 USE, FORCE 를 사용할 수 있습니다.

그렇다면 USEFORCE 의 차이는 뭘까요?

Stackoverflow - MySQL : FORCE INDEX vs USE INDEX 를 참고해보면 둘은 다음과 같은 차이가 있습니다.

  • USE INDEX
    • DB 옵티마이저에게 지정한 인덱스를 사용하라고 권장
    • 하지만 만약 Table Scan 이 더 빠르다면 옵티마이저는 인덱스 대신 Table Scan 수행 가능
  • FORCE INDEX
    • Table Sacan 이 더 효율적이어도 무조건 인덱스 사용
    • Index 를 사용할 수 없는 쿼리 (인덱스가 걸려있지 않은 컬럼이 조건) 인 경우에만 다른 방법 선택 가능

대부분의 경우에는 USE INDEX 만 사용해도 되지만 Full Scan 도 허용하지 않는 경우에는 FORCE INDEX 를 사용하면 될 것 같습니다.


Reference

'공부 > Database' 카테고리의 다른 글

MySQL Index 특징 및 유의사항 정리  (2) 2022.05.22
Cache 전략  (0) 2022.05.20
Redis 설치 및 명령어  (0) 2021.08.07

Overview

한 프로젝트를 여러 사람이 작업하면 각자의 feature 브랜치에서 수정한 내용을 하나의 통합 브랜치 (main) 에 합치는 방식으로 진행합니다.

이렇게 브랜치를 통합할 때 사용하는 명령어가 git merge 입니다.

이 merge 는 각 브랜치의 상황에 따라 다르게 동작하고 방법도 다양하기 때문에 어떤 방법들이 있는지 알아봅니다.


1. Git Merge

CLI 또는 GUI 에서 사용하는 경우입니다.

크게 Merge, Fast-Forward, Squash, Rebase 가 있습니다.


1.1. Merge

$ git switch main
$ git merge feature

main 브랜치에 추가 작업 내역이 있다면 새로운 Merge Commit 을 만들게 됩니다.

가장 일반적인 Merge 방법입니다.

feature 의 모든 커밋 로그와 하나로 합친 Merge Commit 로그가 전부 남습니다.


1.2. Fast-Forward

$ git switch main
$ git merge feature # main 에 추가 작업 내역 없음

feature 브랜치를 딴 이후로 main 브랜치에 아무런 커밋이 없다면 merge 할 때 Fast-Forward 방식으로 합쳐집니다.

Fast-Forward 를 그대로 직역하면 "빨리감기" 라는 뜻입니다.

이 말 그대로 별도의 Merge 기록 없이 원래 main 에서 작업한 것처럼 로그가 남습니다.

병합하려는 main 브랜치에 커밋이 존재한다면 Fast-Forward Merge 가 되지 않습니다.


1.3. No Fast-Forward (--no-ff)

$ git switch main
$ git merge --no-ff feature # main 에 추가 작업 내역 없지만 머지 커밋 생성

만약 main 에 추가 작업 내역이 없어도 새로운 Merge Commit 을 만들고 싶다면 --no-ff 옵션을 추가합니다.

feature 브랜치의 존재를 남기고 싶을 때 사용할 수 있습니다.


1.4. Squash (--squash)

$ git switch main
$ git merge --squash feature
$ git commit -m "Merge Squash feature/squash"

Squash Merge 는 feature 의 모든 커밋을 하나의 커밋으로 만들어 main 에 머지합니다.

feature 에서 리뷰 반영, 버그 수정 등으로 쓸데없는 커밋이 많아진 경우 이를 다 기록하지 않고 하나의 새로운 커밋으로 남길 수 있습니다.

대신 feature 브랜치의 수정사항이 큰 경우 하나의 커밋으로 전부 표현하기 보다 커밋을 잘개 쪼개는게 알아보기 더 편할 수 있기 때문에 신중히 사용해야 합니다.


1.5. Rebase

$ git switch main
$ git rebase feature

main 에 아무런 추가 커밋이 없다면 Fast-Forward 와 동일하게 HEAD 만 이동합니다.

하지만 다른 커밋이 있다면 이름 그대로 커밋을 재배치 합니다.

재배치 하고 나면 현재 브랜치의 커밋이 rebase 하려는 브랜치의 뒤로 이동합니다.

main 브랜치에서 git rebase feature 를 했다면 feature 의 커밋 내역이 먼저 찍히고 이후 main 브랜치의 커밋이 찍힙니다.

만약 같은 범위를 수정해서 rebase 과정에서 충돌이 발생한다면 각 커밋 별로 충돌을 해결해야 합니다.

별도의 Merge Commit 이 남지 않는다는 점은 Fast-Forward 와 동일하지만 Rebase 는 각 브랜치에 다른 커밋이 있어도 하나의 줄기로 합쳐줄 수 있다는 장점이 있습니다.


위 사진과 같이 어디 브랜치에서 시작하냐에 따라 커밋의 순서가 바뀝니다.

현재 checkout 한 브랜치의 커밋이 가장 최신에 위치하는 걸 볼 수 있습니다.


2. Github Merge

Github 에서도 Merge 를 할 수 있습니다.

아마 Github 에서 Pull Request 로 코드 리뷰를 받은 후에 Merge 하는 경우가 더 많을 것 같습니다.

Github 에서 지원하는 Merge 는 크게 세종류입니다.


2.1. Create a merge commit

Create a merge commit 을 사용하면 main 브랜치에 커밋이 있건말건 무조건 --no-ff 옵션으로 머지됩니다.

커밋 로그가 전부 남으며 새로운 Merge Commit 이 함께 만들어집니다.


2.2. Squash and merge

Git 과 마찬가지로 feature 의 커밋 이력들 대신 새로운 Merge Commit 하나만 남깁니다.

저는 리뷰 수정사항이 많아서 기능에 비해 커밋 수가 너무 많을 때 사용하는 방법입니다.


2.3. Rebase and merge

Rebase 는 feature 의 커밋 로그를 main 브랜치 커밋 로그 뒤에 붙여줍니다.

위에서 설명할 때 rebase 를 하면 현재 브랜치의 커밋이 대상 브랜치의 커밋 뒤로 이동한다고 했습니다.

이 특성을 이용해서 우선 feature 브랜치에서 main 브랜치를 rebase 한 뒤, feature -> main 으로 Fast-Forward Merge 한 셈입니다.

Git 명령어로 나타내면 아래와 같습니다.


# feature 브랜치로 이동
$ git switch feature

# main 브랜치의 커밋내역을 feature 브랜치 이전으로 끼워넣기
# 이렇게 하면 최신 main 브랜치에서 feature 를 딴 뒤 수정한 것처럼 됨
$ git rebase main 

# 다시 main 브랜치로 이동
$ git switch main

# main 에 feature 브랜치 머지
# rebase 를 했기 때문에 HEAD 만 이동하는 fast-forward merge 실행
$ git merge feature

이렇게 하면 깔끔하게 main 브랜치 뒤에 feature 브랜치 커밋 로그를 남길 수 있습니다.

다만, feature 브랜치의 커밋이 엄청 많은 경우 전부 rebase merge 해버리면 트리만 봤을 때 작업의 큰 줄기가 잘 보이지 않는다는 단점이 있습니다.


Conclusion

그래서 어떤걸 사용하는게 좋냐? 라고 한다면 정해진 답은 없습니다.

여러 개의 커밋을 남기고 싶다면 --no-ff 머지를 사용하고 하나만 깔끔하게 남긴다면 Squash 또는 Rebase 를 사용합니다.

현재 제가 사용하는 방식을 그림으로 나타내면 아래와 같습니다.


저는 대부분의 머지를 PR 에서 하기 때문에 PR 을 최대한 작은 단위로 나눈 후 전부 Squash Merge 하는 걸 선호했습니다.

코드리뷰를 받다보면 추가 수정 사항이 발생하고 자잘한 커밋들을 전부 남기면 지저분하게 느껴서 없애고 싶었어요.

회사에 와서 git rebase main 으로 feature 브랜치를 최신화 하고 --no-ff 옵션으로 Merge Commit 을 남기는 방법을 알게 되었는데 굉장히 깔끔한 것 같습니다.

여러 회사들의 기술 블로그를 보면 각 팀마다 사용하는 Merge 전략이 있는데 여러 가지를 찾아보고 본인이 느끼기에 가장 좋아보이는 전략을 선택하면 됩니다.

'공부 > Git' 카테고리의 다른 글

Gitmoji (for Git Commit Convention)  (0) 2022.06.18
Git Directory 이름 변경  (0) 2020.04.26

Overview

Gitmoji 란 Git + Emoji 입니다.

여러 사람이 커밋 메시지를 작성하다보면 일관성이 없고 나중에는 히스토리를 알아보기 힘들어집니다.

Gitmoji 는 이모지를 사용하여 커밋 메시지를 일정하게 작성하도록 도와주는 툴입니다.

커밋 메시지 타이틀 앞에 특정 이모지를 넣으면서 이모지만 보고도 어떤 목적으로 한 커밋인지 알아볼 수 있습니다.

gitmoji 에 대한 설명은 gitmoji 공식에서 볼 수 있지만 사용하기 위해서는 gitmoji-cli 를 참고해야 합니다.


1. Install

# use brew
$ brew install gitmoji

# use npm
$ npm i -g gitmoji-cli

brew 또는 npm 을 사용해서 설치할 수 있습니다.


2. Configuration

gitmoji 를 사용하기 전에 미리 설정을 해두는게 좋습니다.

gitmoji -g 명령어를 사용해서 여러가지 옵션을 설정할 수 있습니다.

저는 대부분 기본값을 사용하는데 Select how emojis should be used in commits 옵션만 text 대신 emoji 를 선택했습니다.


Github 에서 볼 때는 별 문제 없으나 이렇게 이모지를 지원하지 않는 외부 툴에서는 Text 그대로 노출됩니다.

그래서 이모지 자체를 커밋 메시지에 넣을 수 있도록 설정했습니다.


3. Usage

gitmoji 의 사용법은 크게 어렵지 않습니다.

그냥 평범한 사용법에서 git commit 대신 gitmoji -c 를 입력해주면 됩니다.


3.1. Choose Gitmoji

gitmoji -c 를 입력하면 위 그림처럼 이모지 선택이 나옵니다.

위아래 방향키를 사용해서 다른 이모지들을 찾아볼 수도 있고, 직접 원하는 기능을 검색할 수도 있습니다.


위 그림처럼 refactor 를 검색하면 그에 맞는 이모지를 띄워줍니다.


3.2. Input Commit Message

원하는 이모지를 선택했다면 Commit Title, Message 를 입력합니다.

Message 는 생략해도 됩니다.

전부 입력 후 엔터를 누르면 커밋이 완료됩니다.

이후에는 똑같이 git push 를 사용해서 원격 저장소에 반영할 수 있습니다.


3.3. Repository 확인

이제 커밋 로그를 확인하면 이렇게 이모지가 잘 들어간 것을 볼 수 있습니다.

제가 실제로 두번 커밋한거고 중복해서 로그가 쌓인건 아닙니다.


4. Plugin 및 GUI

IntelliJ 는 Plugin, VSCode 는 Extension 으로 지원하기도 합니다.

IDE 에서 직접 커밋 메시지를 작성하는 스타일이었다면 이용해보는 게 좋습니다.

Source Tree, GitKraken, Git Fork 등등 별도 GUI 를 사용할 때는 아쉽게도 지원되지 않는 것 같아요.

개인적으로 CLI 대신 GUI 를 많이 사용하기 때문에 이 부분이 참 아쉬웠습니다.

그래서 그냥 add, push, pull 등은 전부 GUI 를 이용하고 오로지 커밋만 gitmoji -c 를 사용합니다.

만약 이게 싫다면 이모지를 직접 복사해서 GUI 커밋 메시지에 붙여넣는 방법도 가능합니다.

Gitmoji Dev 사이트에서 원하는 이모지를 검색할 수 있고 그림을 누르면 자동으로 복사되기 때문에 GUI 에서 작성하는 경우 편리하게 이용할 수 있습니다.


5. 장단점

가장 큰 장점은 커밋 로그를 시각적으로 확인할 수 있다 입니다.

단점은 이모지가 뭘 의미하는지 알고 있어야 하고 GUI 와 같이 쓰기 번거롭다는 점인것 같아요.

Gitmoji 를 처음 봤을 때 생각난건 feat:, fix:, refactor: 등을 사용하는 Angular Git Commit Guidelines 였는데요.

시각적으로는 그림인 이모지가 더 잘들어오긴 하지만 가독성은 개인에 따라 다르기 때문에 뭐가 더 낫다고 단언할 수는 없을 것 같아요.

Angular Convention 과 비교했을 때 가장 큰 장점을 뽑자면 Search 기능이라고 생각합니다.

파일을 수정하고 어떤 prefix 를 붙여야할 까 고민될 때 gitmoji 는 대충 이런 목적이다~ 검색을 하면 그에 맞는 이모지를 추천해줍니다.


Conclusion

사실 Gitmoji 가 뭔지 잘 모르다가 회사에서 사용하면서 알게 되었는데요.

처음에는 CLI 와 GUI 를 왔다갔다 하는게 불편했지만 적응해보니 생각보다 쓸만한 것 같습니다.

특히 Search 기능이 강력해서 적당히 입력해도 알아서 추천해주니 큰 고민 없이 넣을 수 있다는게 좋았습니다.


Reference

'공부 > Git' 카테고리의 다른 글

Git Merge (feat. Github)  (0) 2022.06.20
Git Directory 이름 변경  (0) 2020.04.26

1. Overview

전략 패턴은 여러 알고리즘 (로직) 을 캡슐화 하여 상호 교환 가능하게 하는 패턴입니다.

단순히 패턴만 보면 어떤 목적인지 이해하기 힘들지만 템플릿 메서드 (Template Method) 패턴과 비교해서 생각해보면 됩니다.

템플릿 메서드 패턴은 추상 클래스에 공통된 로직을 놓고 변경되는 로직은 상속을 통해 구현했습니다.

이 패턴의 단점은 부모 클래스에 의존도가 생긴다는 점이었습니다.

전략 패턴은 변하지 않는 부분을 Context 에 두고 변하는 부분을 Strategy 인터페이스의 구현체에 작성합니다.

전략에 해당하는 Strategy 인터페이스와 구현체에는 비즈니스 로직 외에 아무런 로직이 없기 때문에 공통된 로직이 변경되어도 아무런 영향이 없습니다.


2. Strategy Example

간단한 예시 코드를 작성해봅니다.

  • 비즈니스 로직 1 존재
  • 비즈니스 로직 2 존재
  • 각 비즈니스 로직의 실행 시간을 측정하는 공통된 로직 존재

2.1. Before

public class BeforeStrategyApp {

    public static void main(String[] args) {
        logic1();
        logic2();
    }

    private static void logic1() {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        System.out.println("비즈니스 로직 1 실행");
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }

    private static void logic2() {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        System.out.println("비즈니스 로직 2 실행");
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }
}

요구사항을 단순하게 구현하면 이렇게 공통된 로직이 존재합니다.

위 코드에서 다른 부분은 "비즈니스 로직 실행" 하나뿐이고 나머지는 전부 중복된 코드입니다.

전략 패턴을 적용해서 리팩토링 해봅시다.


2.2. Strategy (변경되는 부분)

public interface Strategy {
    void call();
}

public class StrategyLogic1 implements Strategy {

    @Override
    public void call() {
        System.out.println("비즈니스 로직 1 실행");
    }
}

public class StrategyLogic2 implements Strategy {

    @Override
    public void call() {
        System.out.println("비즈니스 로직 2 실행");
    }
}

Strategy 인터페이스와 각 비즈니스 로직을 담당하는 하위 구현체들을 선언합니다.

나중에 비즈니스 로직 3 이 추가된다면 인터페이스나 다른 구현체 변경 없이 새로 추가하기만 하면 됩니다.


2.3. Context (공통된 부분)

public class Context {

    private final Strategy strategy;

    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    public void execute() {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        strategy.call();
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }
}

공통된 로직이 작성되어 있는 Context 클래스입니다.

Strategy 를 생성자로 받기 때문에 어떤 구현체를 받느냐에 따라 비즈니스 로직이 달라집니다.

비즈니스 로직을 위임 한다고도 표현합니다.


2.4. Application (Client)

public class AfterStrategyApp {

    public static void main(String[] args) {
        Strategy strategy1 = new StrategyLogic1();
        Context context1 = new Context(strategy1);
        context1.execute();

        Strategy strategy2 = new StrategyLogic1();
        Context context2 = new Context(strategy2);
        context2.execute();
    }
}

구현을 원하는 로직에 따라 다른 Strategy 를 생성자로 넘겨줍니다.

Spring 에서는 Bean 주입 설정만 바꾸면 쉽게 로직을 변경할 수 있습니다.


3. 장단점

  • 장점
    • 공통 로직이 부모 클래스에 있지 않고 Context 라는 별도의 클래스에 존재하기 때문에 구현체들에 대한 영향도가 적음
    • ContextStrategy 라는 인터페이스를 의존하고 있기 때문에 구현체를 갈아끼우기 쉬움
  • 단점
    • 로직이 늘어날 때마다 구현체 클래스가 늘어남
    • ContextStrategy 를 한번 조립하면 전략을 변경하기 힘듬

4. Template Callback 패턴

전략 패턴은 생성자 파라미터로 한번 주입하고 나면 동적으로 변경할 수 없다는 단점이 있습니다.

이러한 단점을 극복하기 위해 Context 의 생성자가 아닌 execute() 메서드의 파라미터로 Strategy 를 넘겨주기도 합니다.

이런 패턴을 Template Callback (템플릿 콜백) 패턴이라고도 부릅니다.

템플릿 콜백 패턴도 전략 패턴과 동일하지만 동적으로 비즈니스 로직을 설정할 수 있다는 장점이 있습니다.


5. Template Callback Example

위에서 사용했던 예제를 템플릿 패턴으로 다시 구현해봅니다.


5.1. Callback (Strategy)

public interface Callback {
    void call();
}

전략 패턴과 동일하게 인터페이스 하나를 정의합니다.

실제 비즈니스 로직은 런타임에 넘겨줄거라서 별다른 구현체를 만들지 않아도 됩니다.


5.2. Template (Context)

public class TimeLogTemplate {

    public void execute(Callback callback) {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        callback.call();
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }
}

전략 패턴의 Context 에 해당하는 부분이지만 생성자로 받는 대신 execute() 의 파라미터로 전략을 넘겨받습니다.


5.3. Application (Client)

public class AfterTemplateCallbackApp {

    public static void main(String[] args) {
        TimeLogTemplate timeLogTemplate = new TimeLogTemplate();
        timeLogTemplate.execute(() -> System.out.println("비즈니스 로직 1 실행"));
        timeLogTemplate.execute(() -> System.out.println("비즈니스 로직 2 실행"));
    }
}

Callback 이 함수형 인터페이스라서 람다식으로 간단하게 표현할 수 있습니다.

이제 새로운 로직이 추가되어도 클래스를 만들지 않고 파라미터의 값만 변경해주면 됩니다.

Spring 에서 JdbcTemplate, RestTemplatexxxTemplate 의 형태를 하면 대부분 템플릿 콜백 패턴을 사용한 거라고 생각하시면 됩니다.


Reference

1. Overview

코드를 작성하다보면 로깅, 예외 처리 등등 반복되어 작성하는 코드가 발생합니다.

이런 경우 코드의 중복을 없애기 위한 패턴 중 하나가 템플릿 메서드 패턴입니다.

AbstractClass (추상 클래스) 는 템플릿을 제공하고 이를 상속 받는 하위 클래스가 구체적인 로직을 작성합니다.

추상 클래스가 전체적인 골격을 정의하고 일부 로직은 하위 상속 클래스에서 구현합니다.

중복된 로직은 추상 클래스에 정의하고 달라지는 비즈니스 로직만 상속 클래스에서 재정의 (오버라이딩) 합니다.

여기서 중복된 로직은 일반적으로 "변하지 않는 부분" 이고 비즈니스 로직은 "변하는 부분" 이라고 할 수 있습니다.


2. Example

간단한 예시 코드를 작성해봅니다.

  • 비즈니스 로직 1 존재
  • 비즈니스 로직 2 존재
  • 각 비즈니스 로직의 실행 시간을 측정하는 공통된 로직 존재

2.1. Before

public class BeforeTemplateMethodApp {

    public static void main(String[] args) {
        logic1();
        logic2();
    }

    private static void logic1() {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        System.out.println("비즈니스 로직 1 실행");
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }

    private static void logic2() {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        System.out.println("비즈니스 로직 2 실행");
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }
}

요구사항을 단순하게 구현하면 이렇게 공통된 로직이 존재합니다.

위 코드에서 다른 부분은 "비즈니스 로직 실행" 하나뿐이고 나머지는 전부 중복된 코드입니다.

템플릿 메서드 패턴을 적용해서 리팩토링 해봅시다.


2.2. Abstract Class

public abstract class AbstractTemplate {

    public void execute() {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 비즈니스 로직 시작
        call();
        // 비즈니스 로직 종료

        stopWatch.stop();
        System.out.println("실행 시간 = " + stopWatch.getTotalTimeMillis());
    }

    protected abstract void call();
}

공통된 로직을 갖고 있는 추상 클래스 입니다.

execute() 메서드 내부에서 비즈니스 로직 부분은 call() 메서드 호출로 대체합니다.

call() 메서드는 이 추상 클래스를 상속하는 자식 클래스에서 오버라이딩 합니다.


2.3. Sub Class

public class SubClassLogic1 extends AbstractTemplate {

    @Override
    protected void call() {
        System.out.println("비즈니스 로직 1 실행");
    }
}

public class SubClassLogic2 extends AbstractTemplate {

    @Override
    protected void call() {
        System.out.println("비즈니스 로직 2 실행");
    }
}

추상 클래스를 상식하는 SubClass 입니다.

비즈니스 로직만 정의해둔 간단한 메서드입니다.

이후에 또다른 비즈니스 로직 3 이 필요하다면 SubClassLogic3 을 정의해서 사용하면 됩니다.


2.4. Application (Client)

public class AfterTemplateMethodApp {

    public static void main(String[] args) {
        AbstractTemplate template1 = new SubClassLogic1();
        template1.execute();

        AbstractTemplate template2 = new SubClassLogic2();
        template2.execute();
    }
}

실제로 사용하는 부분입니다.

execute() 메서드를 호출하는 건 동일하지만 어떤 객체를 만드냐에 따라 로직이 달라집니다.


3. 장단점

  • 장점
    • 중복된 코드를 없애고 SubClass 에서는 비즈니스 로직에만 집중할 수 있음 (SRP)
    • 나중에 새로운 비즈니스 로직이 추가되어도 기존 코드를 수정하지 않아도 됨 (OCP)
  • 단점
    • 클래스 파일을 계속 만들어야 함
    • 자식 클래스는 실제로 부모 클래스를 사용하지 않는데 단순히 패턴 구현을 위한 상속 때문에 의존 관계를 갖고 있음

템플릿 메서드 패턴과 비슷한 역할을 하면서 상속의 단점을 제거할 수 있는 디자인 패턴으로 Strategy (전략) 패턴이 있습니다.


Reference

+ Recent posts