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

1. Overview

Factory 패턴 시리즈의 마지막인 추상 팩토리 패턴입니다.

추상 팩토리는 얼핏 보면 팩토리 메서드 패턴과 비슷하다고 느낄 수도 있습니다.

가장 큰 차이점은 팩토리 메서드 패턴은 어떤 객체를 생성 할지에 집중하고 추상 팩토리 패턴은 연관된 객체들을 모아둔다는 것에 집중합니다.


2. Abstract Method

추상 팩토리 패턴은 연관된 객체들의 생성을 하나의 팩토리에서 담당합니다.


3. Example

스포츠 팀을 만든다고 가정합니다.

스포츠 팀에는 플레이어와 매니저가 필수로 존재하기 때문에 팀의 구성요소라고 볼 수 있습니다.


3.1. ProductA (Manager)

public interface Manager {
}

public class SoccerManager implements Manager {
}

public class TennisManager implements Manager {
}
  • Manager 인터페이스와 클래스를 정의합니다.
  • 축구팀과 테니스팀이 존재하기 때문에 두 개의 Manager 구현 클래스를 정의합니다.

3.2. ProductB (Player)

public interface Player {
}

public class SoccerPlayer implements Player {
}

public class TennisPlayer implements Player {
}
  • Player 인터페이스와 클래스를 정의합니다.
  • 매니저와 마찬가지로 축구 선수와 테니스 선수를 정의합니다.

3.3. Factory (StaffFactory)

public interface StaffFactory {
    Manager createManager();
    Player createPlayer();
}

public class SoccerStaffFactory implements StaffFactory {

    @Override
    public Manager createManager() {
        return new SoccerManager();
    }

    @Override
    public Player createPlayer() {
        return new SoccerPlayer();
    }
}

public class TennisStaffFactory implements StaffFactory {

    @Override
    public Manager createManager() {
        return new TennisManager();
    }

    @Override
    public Player createPlayer() {
        return new TennisPlayer();
    }
}
  • Product 를 생성하는 Factory 클래스를 정의합니다.
  • Manager, Player 는 축구라는 하나의 공통점으로 묶을 수 있습니다.
  • 그래서 SoccerManager, SoccerPlayer 를 생산하는 SoccerStaffFactory 와 반대로 테니스 객체들을 생성하는 TennisStaffFactory 를 정의합니다.
  • 단순하게 생각하면 팩토리 메서드 패턴과 동일하지만 공통된 집합을 모아둔다는 점이 특징입니다.

3.4. Client

public class AbstractFactoryApp {
    public static void main(String[] args) {
        use(new SoccerStaffFactory());
        use(new TennisStaffFactory());
    }

    private static void use(StaffFactory factory) {
        Manager manager = factory.createManager();
        Player player = factory.createPlayer();
    }
}
  • 구체 클래스가 아닌 인터페이스에 의존하게 작성할 수 있습니다.
  • 어떤 Factory 를 넘겨받는지에 관계 없이 클라이언트는 Manager, Player 를 생성해서 사용할 수 있습니다.

3.5. 의존 관계 다이어그램

의존 관계 그림을 보면 맨 처음에 봤던 다이어그램과 동일한 것을 볼 수 있습니다.


4. 장단점

  • 장점
    • 팩토리 메서드 패턴과 마찬가지로 수정에는 닫혀 있고 확장에는 열려 있습니다.
    • 여러 개의 비슷한 집합 객체 생성을 하나의 팩토리에 모아둘 수 있습니다. (위 예시 뿐만 아니라 자동차의 부품 등)
  • 단점
    • 팩토리 메서드 패턴과 마찬가지로 클래스 갯수가 늘어납니다.

Reference

1. Overview

Factory 패턴은 객체 생성과 관련된 디자인 패턴입니다.

1편에서 봤던 Simple Factory 는 객체 생성 역할을 담당하면서 각 클라이언트에서 구현 클래스에 직접 의존하지 않도록 분리했습니다.

하지만 새로운 클래스가 추가되었을 때 Factory 클래스를 수정해야 한다는 한계가 있었습니다.

기존 코드의 변경 없이 확장하기 위한 디자인 패턴이 Factory Method 패턴입니다.


2. Factory Method

Factory Method Pattern (팩토리 메소드 패턴) 은 생성 패턴 중 하나로 객체를 생성할 때 어떤 클래스의 인스턴스를 만들 지 서브 클래스에서 결정하게 합니다.

즉, 인스턴스 생성을 서브 클래스에게 위임합니다.

부모 추상 클래스는 인터페이스에만 의존하고 실제로 어떤 구현 클래스를 호출할 지는 서브 클래스에서 구현합니다.

이렇게 하면 새로운 구현 클래스가 추가되어도 기존 Factory 코드의 수정 없이 새로운 Factory 를 추가하면 됩니다.


3. Example

사용자 관리 프로그램이 있고 네이버 계정으로 가입할 수 있다고 가정합니다.


2.1. Product (User)

public interface User {
    void signup();
}
  • User 인터페이스 정의

public class NaverUser implements User {
    @Override
    public void signup() {
        System.out.println("네이버 아이디로 가입");
    }
}
  • User 인터페이스를 구현하는 NaverUser 클래스 정의
  • 오버라이드한 메서드에는 네이버 유저 전용 로직 추가

2.2. Creator (UserFactory)

public abstract class UserFactory {

    public User newInstance() {
        User user = createUser();
        user.signup();
        return user;
    }

    protected abstract User createUser();
}
  • 추상 클래스로 UserFactory 를 정의
  • 외부에서 User 객체를 생성할 때는 newInstance() 메서드를 호출하면 되고, 실제로 어떤 객체를 생성할 지는 추상 메서드로 정의해서 하위 클래스에서 정의
  • Java 8 부터는 인터페이스에서 default 메서드를 사용할 수 있기 때문에 인터페이스로 정의할 수도 있지만 protected 키워드를 사용해 접근을 제한하고 싶어서 추상 클래스를 사용

public class NaverUserFactory extends UserFactory {
    @Override
    protected User createUser() {
        return new NaverUser();
    }
}
  • UserFactory 를 상속받는 NaverUserFactory 를 정의
  • NaverUser 를 반환하도록 오버라이드

2.3. Client

UserFactory userFactory = new NaverUserFactory();
User user = userFactory.newInstance();
  • 클라이언트 코드에서 NaverUser 클래스에 대한 의존성 없이 사용 가능
  • 의존성 주입을 사용해서 외부에서 Factory 클래스를 받아온다면 NaverUserFactory 에 대한 의존성도 제거 가능

3. 스펙 확장

팩토리 메서드 패턴의 장점은 확장할 때 기존 코드의 변경이 없어도 된다는 점이라고 했습니다.

카카오 서비스가 오픈되고 사용자가 많아져서 카카오 계정으로도 가입할 수 있게 확장되었다고 가정합니다.

Simple Factory 에서는 UserFactory 코드를 수정해야 했습니다.

깜빡하고 switch-case 문을 추가하지 않으면 코드에 오류가 생기며 Enum 으로 어느정도 방어할 수는 있지만 수정에도 열려있다는 단점은 변하지 않습니다.

하지만 우리는 Factory Method 패턴을 적용했기 때문에 기존 코드 (User, NaverUser, UserFactory, NaverUserFactory) 의 수정 없이 새로운 코드를 추가만 하면 됩니다.


3.1. 새로운 Product 와 Creator

public class KakaoUser implements User {
    @Override
    public void signup() {
        System.out.println("카카오 아이디로 가입");
    }
}
  • NaverUser 클래스와 동일하게 User 인터페이스를 구현하는 KakaoUser 클래스 추가

public class KakaoUserFactory extends UserFactory {
    @Override
    protected User createUser() {
        return new KakaoUser();
    }
}
  • NaverUserFactory 클래스와 동일하게 KakaoUserFactory 정의

UserFactory userFactory = new NaverUserFactory();
User user = userFactory.newInstance();

// 위 클라이언트 코드 수정 없이 다른 곳에서 사용 가능
UserFactory kakaoUserFactory = new KakaoUserFactory();
User kakaoUser = kakaoUserFactory.newInstance();
  • 기존 코드의 변경 없이 새로 선언한 클래스만 사용하여 확장 가능

4. 장단점

  • 장점: Factory Method 패턴의 가장 큰 장점은 지금까지 본 것처럼 수정에 닫혀있고 확장에는 열려있는 OCP 원칙을 지킬 수 있다는 점입니다.
  • 단점: 간단한 기능을 사용할 때보다 많은 클래스를 정의해야 하기 때문에 코드량이 증가합니다.

Reference

1. Overview

Factory 패턴은 객체 생성 역할을 별도의 클래스 (Factory) 에게 위임하는 것이 가장 궁극적인 목표입니다.

디자인 패턴 중 Facotry 와 관련된 패턴은 크게 두 가지가 있습니다.

팩토리 메서드 패턴과 추상 팩토리 패턴인데요.

이 두 가지 패턴의 베이스가 되는 가장 단순한 형태의 Factory 패턴이 존재합니다.

엄밀히 따지면 디자인 패턴이 아니라 객체 지향 프로그래밍에서의 자주 쓰이는 관용구 느낌이라 별도의 이름은 없지만 Simple Factory 라는 이름으로 많이 불립니다.

이 글에서는 Simple Factory 에 대해 알아보고 이후 나머지 두 패턴에 대해 알아볼 예정입니다.


2. Simple Factory

Simple Factory 는 굉장히 단순합니다.

객체는 여러 곳에서 생성될 수 있는데, 호출하는 쪽이 객체의 생성자에 직접 의존하고 있으면 나중에 변경되었을 때 수정되어야 하는 코드가 많이 발생합니다.

그래서 생성자 호출 (new) 을 별도의 클래스 (Factory) 에서 담당하고 클라이언트 코드에서는 팩토리를 통해 객체를 생성합니다.


3. Example

public interface Pet {
}

public class Cat implements Pet {
}

public class Dog implements Pet {
}

애완 동물을 한번 예시로 들어봅니다.

공통 인터페이스인 Pet 을 정의하고 이를 구현하는 Cat, Dog 클래스를 만들었습니다.

이제 클라이언트 코드에서 Cat, Dog 을 사용하기 위해 생성할 수 있습니다.


3.1. Before

Pet cat = new Cat();
Pet dog = new Dog();

일반적인 사용법은 new 를 사용해 구현 클래스를 생성한 후 호출하는 겁니다.

하지만 이렇게 하면 Client 와 클래스들 사이에 다음과 같은 의존관계가 생깁니다.


이렇게 구현 클래스를 직접 의존하고 있으면 해당 클래스의 생성자나 전처리 코드가 변경되었을 때 사용하는 모든 Client 코드를 변경해야 합니다.

그래서 객체의 생성만을 담당하는 별도의 Factory 클래스를 만들어 생성 역할을 넘겨봅니다.


3.2. After

public interface Pet {
    enum Type {
        CAT, DOG
    }
}

우선 Pet 인터페이스에 enum 으로 타입을 선언합니다.


public class PetFactory {

    public Pet createPet(Pet.Type petType) {
        switch (petType) {
            case CAT:
                return new Cat();
            case DOG:
                return new Dog();
            default:
                throw new IllegalArgumentException("Pet 타입이 아닙니다");
        }
    }
}

PetFactory 를 만든 후 Pet.Type 에 따라 다른 객체를 생성해서 반환합니다.


PetFactory petFactory = new PetFactory();
Pet cat = petFactory.createPet(Pet.Type.CAT);
Pet dog = petFactory.createPet(Pet.Type.DOG);

PetFactory 를 선언한 후 생성 메서드만 호출하면 실제 구현 클래스인 Cat, Dog 에 의존하지 않은 코드를 작성할 수 있습니다.


의존 관계를 그림으로 표현하면 위와 같이 변경됩니다.

Client 에서 구현 클래스를 직접 의존하지 않기 때문에 나중에 클래스 이름이 변경되거나, 생성자가 변경되는 경우에도 PetFactory 내부만 수정하면 됩니다.


4. Simple Factory 의 한계

Simple Factory 는 앞서 말했듯이 디자인 패턴으로 분류되지는 않습니다.

이 패턴은 객체의 생성 역할을 담당하며 확장이 용이하다는 장점이 있지만 변경에 닫혀 있어야 한다는 OCP 원칙에 위배됩니다.

만약 새로운 애완 동물 구현 클래스로 Bird 가 추가 되었다고 가정합니다.

그럼 PetFactory 내부에 존재하는 switch 문에 해당 클래스를 추가해줘야 합니다.

객체지향 원칙은 확장을 할 때 기존 코드에 영향을 주지 않는 것을 지향합니다.

팩토리 메서드나 추상 팩토리 패턴을 활용한다면 기존 클래스에 영향을 주지 않고 확장이 가능합니다.

+ Recent posts