🎨 디자인 패턴 적용기 - 팩토리 메서드 패턴, 전략 패턴 ✨ (feat. 템플릿 메서드, 템플릿 콜백)

🚪 들어가기에 앞서... 

먼저, 이 포스트에서는 내가 얼마나 디자인 패턴에 대해서 열심히 공부했는지, 얼마나 많은 디자인 패턴을 아는지 보다 디자인 패턴으로 어떤 문제를 해결 했는지에 포커스를 맞춰 보고 싶다.

왜냐하면 디자인 패턴을 잘 알고 학습하는 것도 중요하지만, 디자인 패턴으로 어떤 문제를 해결 했는지가 더 중요하다고 생각하기 때문이다 

 

디자인 패턴 각각에 대한 자세한 설명은 노션에 상세히 기록을 해 놓았다..! 😊

 

디자인 패턴에 대해서 학습하고 정리한 노션 링크

23가지 디자인 패턴에 대해서 | Notion

1. 디자인 패턴 이란

디자인 패턴이란 소프트웨어 디자인 과정에서 자주 발생하는 문제들에 대한 해결책을을 말한다.

SOLID 원칙에 따라 객체지향적으로 프로그래밍하는 데 있어서 여러 상황에 대한 공통점들을 모아 놓은것이 디자인 패턴이라고 한다.

 

디자인 패턴을 처음에 나도 접했을 때는, 이런 패턴이 이전부터 존재했구나?! 라고 생각했다.

하지만 학습을 하고 보니, 고대 많은 개발자 분들이 비즈니스 요구사항을 프로그래밍으로 처리하며 마주친 문제들에 대한 해결 책 중 많은 사람들이 인정한 Best Practice를 정리한 것으로, 1994년 GoF(Gang of Four)라고 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vissides가 집필한 GoF 디자인 패턴  책을 통해 정리되고 발전되었다고 한다.

 

디자인 패턴은 객체지향의 특성과 객체지향 설계 원칙(SOLID)를 기반으로 구현된 설계 문제를 해결해주는 패턴이기 때문에 학습이 필요하다는 것을 느꼈다..!

 

2. 나는 디자인 패턴으로 어떤 문제를 해결 했는가?

✨ 1️⃣ 팩토리 메서드 패턴(Factory Method Pattern) 적용 사례

📢 팩토리 메서드 패턴에 대한 간단한 설명

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

출처: https://refactoring.guru/ko/design-patterns/factory-method

위 구조에서 볼 수 있듯, Creator가 최상위 팩토리 클래스로 팩토리 메서드를 추상화해 ConcreteCreatorA, ConcreteCreatorB과 같은 서브 클래스가 Product를 구현하도록 해 객체간의 결합도를 낮추고 유지보수를 용이하게 해준다.

 

📍 언제 팩토리 메서드 패턴을 사용했는가?

데브코스 최종프로젝트 Space Club 프로젝트에서 알림 기능을 구현 하고 있을 때다.

먼저, 알림 기능 구현은 의존성 사이클을 줄이기 위해서 이벤트 publish/listen 하는 방식으로 처리 했다.

따라서 notification 패키지가 아닌 외부에서 메일 기능을 사용하고 싶다면,  ApplicationEventPublisher 객체의 publishEvent() 메서드의 인자로 MailEvent 객체를 생성해서 넘겨 주면 되었다.

 

그런데 MailEvent 객체를 생성해 메일 이벤트를 발생시키는데, 알림이 필요한 경우는 두 경우 였다.

1. 회원가입이 완료 되었을 경우 웰컴 메일

2. 사용자가 행사 신청을 하고 관리자가 승인 or 행사 취소 했을 때 관리자가 취소확인 한 경우 행사 신청 상태 변경 메일

 

그런데 이 각각의 케이스를 각각의 이벤트로 만든다면?

 

그러면 메일 발송을 담당하는 MailService에서 아래와 같이 각 이벤트 마다 메일 발송 메서드를 만들어 주어야 한다.

지금 당장 필요한 메일 기능은 회원가입과 행사 신청 상태 변경, 두 가지 경우이지만 확장성에 있어서는 좋지 못하다는 생각이 들었다.

// 확장성에 있어 좋지 못한 이유
@Service
@RequiredArgsConstructor
public class MailService {

    private final JavaMailSender emailSender;
    private final SpringTemplateEngine templateEngine;
    
    @Async
    @Transactional(propagation = REQUIRES_NEW)
    @TransactionalEventListener
    public void sendEmail(MailEvent1 mailEvent1) {
    // MailEvent1에 대한 메일 전송
    }
    
    @Async
    @Transactional(propagation = REQUIRES_NEW)
    @TransactionalEventListener
    public void sendEmail(MailEvent2 mailEvent1) {
    // MailEvent2에 대한 메일 전송
    }
    ...
    // 이벤트 처리 하는 sendEmail() 메서드 개수 == 발행하는 이벤트 종류 개수

 

따라서 메일을 처리하는 이벤트는 동일한 이벤트 MailEvent 객체로 발행되어야 했다.

 

그런데, 문제점이 발생했다.

1. 회원가입이 완료 되었을 경우 웰컴 메일

2. 사용자가 행사 신청을 하고 관리자가 승인 or 행사 취소 했을 때 관리자가 취소확인 한 경우 행사 신청 상태 변경 메일

 

각 두 경우에 따라 필요한 정보가 달랐다.

회원가입 할 경우, 이메일만 알면 된다. 왜냐하면 그냥 웰컴 이메일 보내면 되니까!

 

하지만 2번 행사 상태 변경 고지해주는 이메일은?

사용자의 이메일도 필요할 뿐 아니라, 행사를 주최하는 클럽이름, 행사이름, 그리고 행사 상태가 어떻게 변경했는지가 추가적으로 필요했다.

 

이 것을 어떻게 구현할까 생각하다.. 도입한 것이 팩토리 메서드 패턴이다.

 

메일을 보내기 위해서 Spring Mail을 사용할때 메일을 전송하는 방법으로 MimeMessage를 생성해서 JavaMailSender에인 아래 emailSender 객체에 send()함수의 인자로 넘겨줬어야 했다.

이 MailInfo안에는 이메일 주소의 배열과 이메일의 제목과 템플릿 이름이 존재해야 했다.

 

메일을 보낼 때는 항상 동일한 MailInfo를 통해 처리해야 했다.

부가적으로 어느 html 템플릿을 사용할지, 제목은 어떻게 보낼지는 각 이벤트마다 다르게 설정해줘야 했다.

따라서 MailInfo를 다음과 같이 추상 클래스로 만들었다.

public abstract class MailInfo {

    private final String[] addresses;

    public MailInfo(String[] addresses) {
        this.addresses = addresses;
    }

    public String[] email() {
        return this.addresses;
    }

    public abstract String title();

    public abstract String templateName();

    @Override
    public String toString() {
        return new StringJoiner(", ", MailInfo.class.getSimpleName() + "[", "]")
                .add("addresses=" + Arrays.toString(addresses))
                .toString();
    }

}

일단 TemplateName이라는 enum을 만들어 WELCOME, EVENT_STATUS_CHANGED 같이 템플릿 이름과 템플릿 제목, DB의 html 템플릿 id 를 모아 관리함으로서 응집도를 높혔다.

public enum TemplateName {

    WELCOME("[Space Club] 스페이스 클럽에 가입해주셔서 감사합니다.", "welcome", 1L),
    EVENT_STATUS_CHANGED("[Space Club] 신청한 행사 상태 변경 알림", "event-status-change", 2L),
    ;

    private final String title;

    private final String templateName;

    private final Long templateId;
    ...

 

그리고 다형성을 이용해 각 보내는 메일 종류에 따라서 구체화를 시켜주었다.

 

먼저 회원가입 시 웰컴 메일을 보내는 메일 정보이다

public class WelcomeMailInfo extends MailInfo {

    public WelcomeMailInfo(String[] addresses) {
        super(addresses);
    }
    
    @Override
    public String title() {
        return WELCOME.getTitle();
    }

    @Override
    public String templateName() {
        return WELCOME.getTemplateName();
    }
...

 

그리고 행사 상태 변경을 고지하는 메일 정보는 다음과 같다.

public class EventStatusChangeMailInfo extends MailInfo {

    private final String clubName;
    private final String eventName;
    private final String eventStatus;
    
    public EventStatusChangeMailInfo(String[] addresses, String clubName, String eventName, String eventStatus) {
        super(addresses);
        this.clubName = clubName;
        this.eventName = eventName;
        this.eventStatus = eventStatus;
    }
    
    @Override
    public String title() {
        return EVENT_STATUS_CHANGED.getTitle();
    }

    @Override
    public String templateName() {
        return EVENT_STATUS_CHANGED.getTemplateName();
    }
...

 

이렇게 만든 각각의 MailInfo에 대한 구현체는 MailEvent에서 정적 팩토리 메서드를 통해서 각 메일을 보내는 상황에 맞게 이벤트를 생성할 수 있도록 메서드 오버로딩(overloading)를 통해 생성하도록 해주었다.

public record MailEvent(MailInfo mailInfo) {

    public static MailEvent createMailEvent(String email) {
        WelcomeMailInfo welcomeMailInfo = WelcomeMailInfo.from(email);
        return new MailEvent(welcomeMailInfo);
    }

    public static MailEvent createMailEvent(String email, String clubName, String eventName, String eventStatus) {
        EventStatusChangeMailInfo mailInfo = EventStatusChangeMailInfo.from(email, clubName, eventName, eventStatus);
        return new MailEvent(mailInfo);
    }
}

 

다시 위 팩토리 메서드 패턴을 간단히 설명할때 구조로 돌아가본다면,

MailInfo가 Product가 되고, EventStatusChangeMailInfo,WelcomeMailInfo가 concrete product가 된다.

MailEvent가 Creator로서  정적 팩토리 메서드를 통해 각 concrete product를 생성하도록 한다.

 

다만 전통적인 팩토리 메서드 패턴에서는 Creator가 인터페이스로서 Concrete Creator를 통해 Concrete Product를 생성하도록 하지만, 나는 Concrete Creator 대신 Creator에서 바로 정적 팩토리 메서드를 통해 Product를 생성하고, 그것을 Creator로 한번 감싸는 과정을 거치는 차이가 있다.

 

OCP와 DIP원칙을 지키고 있고, 추가적으로 메일을 보내는 상황이 생기더라도 응집도가 높기 때문에 유지보수하기 용이한 코드를 작성할 수 있었다.

 

새로운 메일을 보내는 상황이 생기면 MailEvent에서 정적 팩토리 메서드를 추가적으로 생성하고, MailInfo를 override해서 새로운 Concrete Product를 생성해주고 MailService의 sendMail()은 재사용 할 수 있기 때문이다.

 

현재 프로젝트를 다시 보니 좀 더 리팩토링 할 상황들이 보이긴한다 😅

 

⭐️ 관련 PR: https://github.com/Space-Club/Backend/pull/300

feat: 스페이스 클럽 메일 시스템 구현 by juno-junho · Pull Request #300 · Space-Club/Backend

 

 

🤔  템플릿 메서드 패턴(Template Method Pattern)과 팩토리 메서드 패턴(Factory Method Pattern)의 차이

템플릿  메서드 패턴에 대한 간단한 설명

템플릿 메서드 패턴이란 부모 클래스에서 알고리즘 골격을 정의하고, 해당 알고리즘 구조를 변경하지 않고 자식 클래스들이 알고리즘의 특정 단계를 재정의(override)할 수 있도록 하는 패턴이다.

출처: https://refactoring.guru/ko/design-patterns/template-method

상위 추상 클래스의 템플릿 메서드에서 하위 클래스가 재정의(override)한 메서드를 호출하는 패턴을 말한다.

→ 팩토리 메서드 패턴은 템플릿 메서드 패턴의 특수화라고 생각 할 수 있다. 대규모 템플릿 메서드의 한 단계의 역할을 팩토리 메서드가 할 수 있다.

 

 

✨  2️⃣ 전략 패턴(Strategy Pattern) 적용 사례

📢  전략 패턴에 대한 간단한 설명

전략 패턴은 디자인 패턴의 꽃이라고 불릴만큼 자주 사용하는 패턴이라고 한다.

전략 패턴은 런타임에 전략을 선택해 객체 동작을 동적으로 바뀌도록 할 수 있는 디자인 패턴이다.

출처: https://refactoring.guru/ko/design-patterns/strategy

위에서 볼 수 있듯, 전략은 interface로 정의되어 있고, 구체적인 ConcreteStrategy들은 각각 인터페이스를 구현하고 있다.

그리고 Context는 특정 동작을 실행할 때 마다 해당 동작과 연결된 ConcreteStrategy의 메서드를 호출한다.

Client는 ConcreteStrategy 특정 전략 객체를 컨텍스트에 전달 함으로서 전략을 등록하거나 변경해 전략 알고리즘을 실행한 결과를 얻는다.

 

📍 언제 전략 패턴을 사용했는가?

이때까지 코딩을 하면서 알게 모르게 많이 전략 패턴을 사용해 왔을 거라고 생각한다.

하지만 기억에 남는 전략 패턴 사용 예시가 있는데, 작년 NEXTSTEP 교육기관에서 진행하는 TDD, 클린 코드 with Java 16기 과정을 진행할 때였다.

 

그때 레이싱 게임 미션을 진행하면서 전략 패턴에 대해서 처음 접하고 학습해 미션에 적용했는데, 구현해야할 상황은 다음과 같았다.

1. 자동차 이름 리스트와 시도 횟수를 입력 받는다. 

2. 시도 횟수만큼 계산을 하는데, 0부터 9까지의 난수를 생성해 해당 값이 4이상이면 한칸 전진, 4미만이면 전진하지 못한다.

3. 해당 횟수만큼 게임을 진행 후, 가장 많이 전진 한 자동차 이름 (여러대일 경우 자동차 리스트)의 이름을 출력하는 것이였다.

 

이 때 여러 Car라는 도메인 클래스를 만들고, Car 클래스 안에서 전진 할 수 있는지 없는지를 판단해 자동차 위치 값을 증가 시켜야 했다.

public class Car {
    private final Position position;
    private final CarName carName;

    public static final int MOVABLE_LOWER_BOUND = 4;
    
    public static boolean isMovable() {
        Random random = new Random();
        int value = random.nextInt(10);
        return value >= MOVABLE_LOWER_BOUND;
    }
    ...

 

따라서 isMovable() 메서드 내부에서 랜덤 값을 생성해 4보다 큰지 안큰지 확인을 해줬는데, 이렇게 코드를 작성하는 것에 대한 문제점으로 해당 메서드를 테스트 하기 힘들어 진다는 문제가 있었다.

해당 메서드를 테스트 하기 위해서는 테스트 하기 힘든 값(난수)을 내부에서 처리하는게 아니라 외부에서 주입 해 줘야 했다.

 

그리고 객체지향적으로 생각해 봤을때, 해당 난수를 생성하는 기능은 비즈니스 요구사항이므로, 정책이 변경될 수 도 있었다.

 

따라서 나는 전략 패턴을 사용해 외부에서 랜덤 값을 주입해 줌(DI)으로서 테스트 하기 쉬운 코드로 Car 도메인 객체를 변환할 수 있었다.

@FunctionalInterface
public interface NumberGenerator {
    int generate();
}

public class RandomNumberGenerator implements NumberGenerator{

    private static final Random random = new Random();
    public static final int RANDOM_BOUND_NUMBER = 10;

    @Override
    public int generate() {
        return random.nextInt(RANDOM_BOUND_NUMBER);
    }
}

public class Car {
    private final Position position;
    private final CarName carName;

    public static final int MOVABLE_LOWER_BOUND = 4;
    
    public static boolean isMovable(NumberGenerator numberGenerator) {
        int value = numberGenerator.generate();
        return value >= MOVABLE_LOWER_BOUND;
    }
    ...

 

그리고 게임을 진행하는 외부 RacingCarGame이라는 객체 안에서 Car를 전진시켜 주었다.

public class RacingCarGame {

   private final NumberGenerator numberGenerator;
   ...
   
   private void execute(Car car) {
        if (Car.isMovable(numberGenerator)) {
            car.move();
        }
        OutputView.printCarNameAndStatus(car);
    }
    ...

그리고 NumberGenerator에 대한 구현체인 RandomNumberGenerator는 외부 Application에서 주입해 주었다.

public class Application {
    public static void main(String[] args) {
        RacingCarGame racingCarGame = new RacingCarGame(new RandomNumberGenerator());
        racingCarGame.run();
    }
}

 

다시 전략 패턴의 구조로 돌아가 내 구조를 설명하자면,

NumberGenerator는 Strategy 인터페이스, RandomNumberGenerator는 ConcreteStrategy가 된다.

구현체를 주입해주는 Client는 Application이, Context는 RacingCarGame이 된다.

 

이렇게 전략 패턴을 사용해 strategy가 확장가능한 OCP 원칙를 지키며, DIP 원칙을 통해 구체적인 것이 아닌 인터페이스에 의존해 동적으로 strategy가 주입될 수 있었다.

테스트 하기 힘든 strategy를 외부에서 주입해 주어 관계를 끊어냄으로서 도메인 객체에 대한 테스트를 용이하게 만들어 주었다.

 

⭐️ 관련 레포지토리 링크 :

https://github.com/juno-junho/java-racingcar/blob/step5/src/main/java/study/racingcar/strategy/RandomNumberGenerator.java

 

🤔 전략 패턴(Strategy Pattern)과 템플릿 콜백 패턴(Template Callback Pattern) 차이

템플릿 콜백 패턴은 전략 패턴의 변형된 형태이다.

전략 패턴과 모든것이 동일하다. 다만, 전략을 익명 내부 클래스로 정의해서 사용한다는 것이 특징이다

 

위 전략 패턴에서 Client 역할을 하는 Application이 전략 객체인 RandomNumberGenerator를 Context인 RacingCarGame 객체에 전달 했다.

 

템플릿 콜백 패턴에서는 Context가 Template이 되고, Strategy를 RandomNumberGenerator 처럼 만들어 두는 것이 아닌 익명 클래스나 람다로 정의해 client에서 호출 시 바로 정의해 주는 패턴을 말한다.

 

즉, 위 레이싱 게임의 코드를 템플릿 콜백 패턴으로 변경해 보자면, 아래와 같이 변경할 수 있다.

public class Application {
    public static void main(String[] args) {
    // 익명 클래스 사용
        RacingCarGame racingCarGame = new RacingCarGame(
                new NumberGeneratePolicy() {
                    @Override
                    public int generate() {
                        return new Random.nextInt(10);
                    }
                });
        racingCarGame.run();
    }
}

public class Application {
    public static void main(String[] args) {
    // 람다식 사용
        RacingCarGame racingCarGame = new RacingCarGame(() -> new Random().nextInt(10));
        racingCarGame.run();
    }
}

 

단위 테스트시 NumberGenerator 인터페이스를 테스트 더블 dummy 객체로 만들어 테스트를 진행했는데,

이때도 사용했던 패턴이 지금 보니 템플릿 콜백 패턴였다.

@Nested
    @DisplayName("Movable 메서드 검증")
    class MoveableValidationTest {
        public static final int lowerBoundNum = Car.MOVABLE_LOWER_BOUND;

        @DisplayName("차가 움직일 수 없는 경우 false를 반환한다")
        @ParameterizedTest(name = "{0}을 넣었을때 false를 반환한다")
        @ValueSource(ints = {lowerBoundNum - 1, lowerBoundNum - 2, lowerBoundNum - 3, lowerBoundNum - 4})
        void when_NumberUnderLowerBound_Expects_False(int num) {
            // given, when
            boolean actualResult = Car.isMovable(() -> num);

            // then
            assertThat(actualResult).isFalse();
        }

        @DisplayName("Moveable 할 경우 true를 반환한다.")
        @ParameterizedTest(name = "{0}을 넣었을때 true를 반환한다")
        @ValueSource(ints = {lowerBoundNum, lowerBoundNum + 1, lowerBoundNum + 2, lowerBoundNum + 3})
        void when_NumberIsEqualToOrOverLowerBound_Expects_True(int num) {
            // given, when
            boolean actualResult = Car.isMovable(() -> num);

            // then
            assertThat(actualResult).isTrue();
        }
    }

⭐️ 관련 레포지토리 링크 :

https://github.com/juno-junho/java-racingcar/blob/step5/src/test/java/study/racingcar/domain/CarTest.java

 

🔚 끝맺음..

디자인 패턴에 대해서 프로그래머스 데브코스 과정동안 학습하고, 적용도 해보기도 해서 뿌듯했다.

실무에 가서는 디자인 패턴을 적재적소에 자유자재로 사용할 수 있도록 하고 싶다.

 

멘토님도 모든 디자인 패턴을 달달 외우기 보다는 많이 사용하는 특정 패턴들이 있는데, 코드를 보고 아 이게 그 패턴으로 되어있구나!를 알면 된다고는 하셨다.

 

추가적으로 꾸준히 학습과 적용이 필요해 보인다.

 

Reference

https://refactoring.guru/ko/design-patterns/what-is-pattern

디자인 패턴이란?

https://product.kyobobook.co.kr/detail/S000001628116

스프링 입문을 위한 자바 객체 지향의 원리와 이해 | 김종민 - 교보문고

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%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-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90

💠 팩토리 메서드(Factory Method) 패턴 - 완벽 마스터하기

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%A0%84%EB%9E%B5Strategy-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90

💠 전략(Strategy) 패턴 - 완벽 마스터하기

 

 

 

 

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-Template-Callback-%EB%B3%80%ED%98%95-%ED%8C%A8%ED%84%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

💠 Template Callback 디자인 패턴