Spring에서의 템플리 메서드 패턴과 콜백 패턴

hoyong.eom·2023년 9월 13일
JavaSpring디자인패턴콜백패턴탬플릿매서드패턴
0

스프링

목록 보기
41/59
post-thumbnail

Spring

템플릿 메서드 패턴

템플릿 메서드 패턴에 대해서 공부하기 전에 아래의 코드는 템플릿 메서드 패턴을 적용하기 위한 예제 코드이다.

   @Test
    void templateMethodV0() {
        logic1();
        logic2();
    }

    private void logic1() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        log.info("비즈니스 로직1 실행");
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }

    private void logic2() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        log.info("비즈니스 로직2 실행");
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }

위 코드에서 logic1()과 logic2()는 시간을 측정하는 부분과 비지니스 로직을 실행하는 부분이 함께 존재한다.

변하는 부분 : 비지니스 로직(핵심 기능)
변하지 않는 부분 : 시간 측정(부가 기능)

템플렛 메서드 패턴을 이용해서 변하는 부분과 변하지 않는 부분을 분리해서 코딩 할 수 있다.

템플릿 메서드 패턴을 구현하기 위한 추상 클래스
@Slf4j
public abstract class AbstractTemplate {

    public void execute() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        call(); //상속
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }

    protected abstract void call();
}

템플릿 메서드 패턴은 이름 그대로 템플릿을 사용하는 방식이다. 템플릿은 기준이 되는 거대한 틀이다. 템플릿이라는 틀에 변하지 않는 부분을 몰아둔다. 그리고 일부 변하는 부분을 별도로 호출해서 해결한다.

AbstractTemlate 코드를 보면 변하지 않는 부분(부가 기능)인 시간 측정 로직을 몰아둔것을 확인할 수 있다. 이제 이것이 하나의 템플릿이 된다.
그리고 템플릿 안에서 변하는 부분은 call() 메서드를 호출해서 처리한다.
템플릿 몌서드 패턴은 부모 클래스에 변하지 않는 템플릿 코드를 둔다. 그리고 변하는 부분은 자식 클래스에 두고 상속과 오버라이딩을 사용해서 처리한다.

@Slf4j
public class SubClassLogic1 extends AbstractTemplate {
    @Override
    protected void call() {
        log.info("비즈니스 로직1 실행");
    }
}
@Slf4j
public class SubClassLogic2 extends AbstractTemplate {
    @Override
    protected void call() {
        log.info("비즈니스 로직2 실행");
    }
}

위 코드는 변하는 부분인 비지니스 로직1과 비지니스 로직2를 처리하는 자식 클래스이다. 템플릿이 호출하는 대상인 call() 메서드를 오버라이딩한다.

이제 앞선 예제코드에 템플릿 메서드 패턴을 적용하면 아래처럼 2가지 모양의 코드로 구현될 수 있다.

    /**
     * 템플릿 메서드 패턴 적용
     */
    @Test
    void templateMethodV1() {
        AbstractTemplate template1 = new SubClassLogic1();
        template1.execute();

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


template1.execute()를 호출하면 템플릿 로직인 AbstractTemplate.execute()를 실행한다. 여기서 중간에 call() 메서드를 호출하는데, 이 부분ㅇ이 오버라이딩 되어있다. 따라서 현재 인스턴스인 SubClassLogic1인스턴스의 SubClasLogic1.call() 메서드가 호출된다.

템플릿 메서드 패턴은 이렇게 다형성을 사용해서 변하는 부분과 변하지 않는 부분을 분리하는 방법이다.

익명 내부 클래스 사용하기

템플릿 메서드 패턴은 SubClassLogic1, SubClassLogic2처럼 클래스를 계속 만들어야하는 단점이 있다. 익명 내부 클래스를 사용하면 이런 단점을 보완할 수 있따.
익명 내부 클래스를 사용하면 객체 인스턴스를 생성하면서 동시에 생성할 클래스를 상속 받은 자식 클래스를 정의할 수 있다. 이 클래스는 SubClassLogic1처럼 직접 지정하는 이름이 없고 클래스 내부에 선언되는 클래스여서 익명 내부 클래스라 한다.

    @Test
    void templateMethodV3() {
        AbstractTemplate template1 = new AbstractTemplate() {
            @Override
            protected void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        log.info("클래스 이름1={}", template1.getClass());
        template1.execute();
        AbstractTemplate template2 = new AbstractTemplate() {
            @Override
            protected void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        log.info("클래스 이름2={}", template2.getClass());
        template2.execute();
    }

실행해보면 자바가 임의로 만들어주는 익명 내부 클래스 이름은 TemplateMethod$1, TemplateMethod$2인것을 확인할 수 있다.

참고
제네릭에서 반환타입이 필요한데 반환할 내용이 없으면 Void 타입을 사용하고 null을 반환하면 된다. 제네릭은 기본 타입인 void, int 등을 선언할 수 없다.

좋은 설계란?
좋은 설계라는것은 바로 변경이 일어날 때 자연스럽게 드러난다.
강의에서는 로그를 남기는 부분을 모아서 하나로 모듈화하고 비지니스 로직 부분을 분리했다. 여기서 만약 로그를 남기는 로직을 변경해야 한다고 생각해보자. 그래서 AbstractTemplate 코드를 변경해야 한다고 가정하자.
단순히 AbstractTemplate 코드만 변경하면 된다.

템플릿 메서드 패턴 - 정의

GOF 디자인 패턴에서는 템플릿 메서드 패턴을 다음과 같이 정의했다.

템플릿 메서드 패턴의 목적은 다음과 같습니다.
"작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기합니다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있습니다."

풀어서 설명하면 다음과 같다.
부모 클래스에 알고리즘 의 골격인 템플릿(부가 기능)을 정의하고 일부 변경되는 로직은 자식 클래스(핵심 기능)에 정의하는것이다. 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고 특정 부분만 재정의할 수 있다.
결국 상속과 오버라이딩을 통한 다형성 문제를 해결하는것이다.

하지만
템플릿 메서드 패턴은 상속을 사용한다 따라서 상속에서 오는 단점들을 그대로 안고간다. 특히 자식 클래스가 부모 클래스와 컴파일 시점에 강하게 결합되는 문제가 있다. 이것은 의존관계에 대한 문제이다. 자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는다.
그럼에도 불구하고 템플릿 메서드 패턴을 위해 자식 클래스는 부모 클래스를 상속받고 있따.

상속을 받는 다는 것은 특정 부모 클래ㅅ에 의존하고 있다는 것이다. 잣기 클래스의 extends 다음에 바로 부모 클래스가 코드상에 지정되어 있다. 따라서 부모 클래스의 기능을 사용하든 사용하지 않든 간에 부모 클래스를 강하게 의존하게 된다. 여기서 강하게 의존한다는 뜻은 자식 클래스의 코드에 부모 클래스의 코드가 명확하게 적혀있다는 뜻이다. UML에서 상속을 받으면 삼각형 화살표가 자식 -> 부모를 향하고 있는것은 이런 의존관계를 반영하는것이다.

자식 클래스 입장에서는 부모 클래스의 기능을 전혀 사용하지 않는데, 부모 클래스를 알아야 한다. 이것은 좋은 설계가 아니다.그리고 이런 잘못된 의존 관계 때문에 부모 클래스를 수정하면 자식 클래스에도 영향을 줄 수 있다.

추가로 템플릿 메서드 패턴은 상속 구조를 사용하기 때문에 별도의 클래스나 익명 내부 클래스를 만들어야 하는 부분도 복잡하다.

이러한 부분을 더 깔끔하게 개선된 디자인 패턴이 바로 전략 패턴이다.

전략 패턴

전략 패턴을 공부하기 위해서 동일한 예제를 사용한다.

    @Test
    void strategyV0() {
        logic1();
        logic2();
    }

    private void logic1() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        log.info("비즈니스 로직1 실행");
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }

    private void logic2() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        log.info("비즈니스 로직2 실행");
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }

위 예제를 템플릿 메서드 패턴이 아닌 전략패턴으로도 해결이 가능하다.
템플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결했다.

전략 패턴은 변하지 않는 부분을 Context 라는 곳에 두고 변하는 부분을 Strategy라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다. 상속이 아니라 위임으로 문제를 해결하는것이다.
전략패턴에서 Context는 변하지 않는 템플릿 역할을 하고 Strategy는 변하는 알고리즘 역할을 한다.

GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.

알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

아래의 코드는 전략 패턴을 구현한 예시이다.

public interface Strategy {
    void call();
}

이 인터페이스는 변하는 알고리즘 역할을 한다.(핵심 코드)

@Slf4j
public class StrategyLogic1 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직1 실행");
    }
}


@Slf4j
public class StrategyLogic2 implements Strategy {
    @Override
    public void call() {
        log.info("비즈니스 로직2 실행");
    }
}

변하는 알고리즘은 Strategy 인터페이스를 구현하면 된다.

/**
 * 필드에 전략을 보관하는 방식
 */
@Slf4j
public class ContextV1 {

    private Strategy strategy;

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

    public void execute() {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        strategy.call(); //위임
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

ContextV1은 변하지 않는 로직을 가지고 있는 템플릿 역할을 하는 코드이다. 전랙 패턴에서는 이것을 컨텍스트(문맥)이라 한다.
쉽게 이야기해서 컨텍스트(문맥)은 크게 변하지 않지만 그 문맥속에서 strategy를 통해 일부 전략이 변경된다 생각하면 된다.

Context는 내부에 Strategy strategy필드를 가지고 있다. 이 필드에 변하는 부분인 Strategy의 구현체를 주입하면 된다.
전력 패턴의 핵심은 Context는 Strategy 인터페이스에만 의존한다는 점이다. 덕분에 Strategy의 구현체를 변경하거나 새로 만들어도 Context 코드에 영향을 주지 않는다.

바로 스프링에서 의존관계 주입에서 사용하는 방식이 바로 전략 패턴이다.

  /**
     * 전략 패턴 사용
     */
    @Test
    void strategyV1() {
        StrategyLogic1 strategyLogic1 = new StrategyLogic1();
        ContextV1 context1 = new ContextV1(strategyLogic1);
        context1.execute();

        StrategyLogic2 strategyLogic2 = new StrategyLogic2();
        ContextV1 context2 = new ContextV1(strategyLogic2);
        context2.execute();
    }

위 코드는 전략패턴을 사용한 코드이다. 코드를 보면 의존관계 주입을 통해 ContextV1에 Strategy의 구현체인 strategyLogic1를 주입하는 것을 확인할 수 있다. 이렇게 해서 Context안에 원하는 전략을 주입한다. 이렇게 원하는 모양으로 조립을 완료하고 난 다음에 context1.execute()를 호출해서 context를 실행한다.

    1. Context에 원하는 Strategy 구현체를 주입한다.
    1. 클라이언트는 context를 실행한다.
    1. context는 context 로직을 시작한다.
    1. context 로직 중간에 strategy.call()을 호출해서 주입 받은 strategy 로직을 실행한다.
    1. context는 나머지 로직을 실행한다.

전략 패턴 - 익명 내부 클래스

전략 패턴도 익명 내부 클래스를 사용할 수 있다.


    @Test
    void strategyV2() {
        Strategy strategyLogic1 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        };
        ContextV1 context1 = new ContextV1(strategyLogic1);
        log.info("strategyLogic1={}", strategyLogic1.getClass());
        context1.execute();

        Strategy strategyLogic2 = new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        };
        ContextV1 context2 = new ContextV1(strategyLogic2);
        log.info("strategyLogic2={}", strategyLogic2.getClass());
        context2.execute();
    }

익명 내부 클래스를 변수에 담아두지 말고 바로 Context에 전달해도 된다.

    @Test
    void strategyV3() {
        ContextV1 context1 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context1.execute();

        ContextV1 context2 = new ContextV1(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
        context2.execute();
    }

익명 내부 클래스를 자바8부터 제공하는 람다로 변경할 수도 있다. 람다로 변경하려면 인터페이스에 메서드가 1개만(함수적 인터페이스) 있으면 되는데, 여기에서 제공하는 Strategy 인터페이스는 메서드가 1개만 있으므로 람다로 사용할 수 있다.

정리
전략 패턴은 변하지 않는 부분을 Context에 두고 변하는 부분을 Strategy를 구현해서 만든다. 그리고 Context의 내부 필드에 Strategy를 주입해서 사용했다.

선 조립 후 실행

Context의 내부 필드에 Strategy를 두고 사용하는 부분에서 좀더 자세히 살 펴볼 필요가 있다.
이 방싱은 Context와 Strategy를 실행전에 원하느 모양으로 조립해두고 그 다음에 Context를 실행하는 선 조립 후 실행 방식에서 유용하다.
Context와 Strategy를 한번 조립하고 나면 이후로는 Context를 실행하기만 하면 된다. 우리가 스프링으로 애플리케이션을 개발할때 애플리케이션 로딩 시점에 의존관계주입을 통해 의존관계를 모두 맺어두고 난 다음에 실제 요청을 처리하는 것과 같은 원리이다.

이 방식의 단점은 Context와 Strategy를 조립한 이후에는 전략을 변경하기가 힘들다. 물론 Context에 setter를 제공해서 Strategy를 넘겨받아 변경하면 되지만, Context를 싱글톤으로 사용할때는 동시성 이슈가 발생할 수 있어 추가로 고려해야할 사항들이 생긴다. 그래서 실시간으로 전략을 변경해야하면 차라리 이전에 개발한 테스트 코드 처럼 Context를 하나 더 생성하고 그곳에 다른 Strategy를 주입하는것이 더 나은 선택일 수 있다.

유연한 전략 패턴

전략 패턴을 유연하게 사용하기 위해서 선 조립 후 실행이 아닌 전략을 실행할때 직접 파라미터로 전달하는 방식을 구현해본다.

/**
 * 전략을 파라미터로 전달 받는 방식
 */
@Slf4j
public class ContextV2 {

    public void execute(Strategy strategy) {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        strategy.call(); //위임
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}

ContextV2는 전략을 필드로 갖지 않는다. 대신에 전략을 execute(..)가 호출될때 마다 항상 파라미터로 전달받는다.

    /**
     * 전략 패턴 적용
     */
    @Test
    void strategyV1() {
        ContextV2 context = new ContextV2();
        context.execute(new StrategyLogic1());
        context.execute(new StrategyLogic2());
    }

    /**
     * 전략 패턴 익명 내부 클래스
     */
    @Test
    void strategyV2() {
        ContextV2 context = new ContextV2();
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });
        context.execute(new Strategy() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
    }

    /**
     * 전략 패턴 익명 내부 클래스2, 람다
     */
    @Test
    void strategyV3() {
        ContextV2 context = new ContextV2();
        context.execute(() -> log.info("비즈니스 로직1 실행"));
        context.execute(() -> log.info("비즈니스 로직2 실행"));
    }

위 코드에서 Context와 Strategy는 선 조립 후 실행 하는 방식이 아니라 Context를 실행할대마다 전략을 인수로 전달한다.

클라이언트는 Context를 실행하는 시점에 원하는 Strategy를 전달할 수 있다.따라서 이전 방식과 비교해서 원하는 전략을 더욱 유연하게 변경할 수 있따.
테스트 코드를 보면 하나의 Context만 생서한다. 그리고 하나의 Context에 실행 시점에 여러 전략을 인수로 전달해서 유연하게 실행하는것을 확인할 수 있다.

    1. 클라이언트는 Context를 실행하면서 인수로 Strategy를 전달한다.
    1. Context는 execute() 로직을 실행한다.
    1. Context는 파라미터로 넘어온 strategy.call() 로직을 실행한다.
    1. Context의 execute() 로직이 종료된다.

마찬가지로 익명 내부 클래스와 람다 사용이 가능하다.

정리

  • ContextV1은 필드에 Strategy를 저장하는 방식으로 전략 패턴을 구사했다.
    - 선 조립, 후 실행 방법에 적합하다.
    • Context를 실행하는 시점에는 이미 조립이 끝났기 때문에 전략을 신경쓰지 않고 단순히 실행만 하면 된다.
  • ContextV2는 파라미터에 Strategy를 전달받는 방식으로 전략패턴을 구사했다.
    - 실행할때 마다 전략을 유연하게 변경할 수 있다.
    • 단점 역시 실행할때 마다 전략을 계속 지정해주어야 한다는 점이다.

템플릿

지금까지 해결하고 싶은 문제는 변하는 부분과 변하지 않는 부분을 분리하는 것이다.
변하지 않는 부분을 템플릿이라 하고, 그 템플릿 안에서 변하는 부분에 약간 다른 코드 조각을 넘겨서 실행하는것이 목적이다.
ContextV1과 ContextV2 두 가지 방식 다 문제를 해결할 수 있지만 어떤 방식이 조금 더 나아 보일까?
확실한건 ContextV2가 좀 더 유연하다는 점이다.

템플릿 콜백 패턴

ContextV2는 변하지 않는 템플릿 역할을 한다. 그리고 변하는 부분은 파라미터로 넘어온 Strategy의 코드를 실행해서 처리한다. 이렇게 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 콜백이라 한다.

콜백 정의
프로그래밍에서 콜백 또는 콜애프터 함수는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고 아니면 나중에 실행할 수도 있다.

쉽게 이야기해서 callback은 코드가 호출(call)은 되는데 코드를 넘겨준곳의 뒤(back)에서 실행된다는 뜻이다.

  • Context2예제에서 콜백은 Strategy이다.
  • 여기에서는 클라이언트에서 직접 Strategy를 실행하는것이 아니라 클라이언트가 ContextV2.execute(..)를 실행할때 Strategy를 넘겨주고 ContextV2 뒤에서 Strategy가 실행된다.

자바 언어에서 콜백

  • 자바 언어에서 실행 가능한 코드를 인수로 넘기려면 객체가 필요하다. 자바8부터는 람다를 사용할 수 있다.
  • 자바 8 이전에는 보통 하나의 메서드를 가진 인터페이스를 구현하고 주로 익명 내부 클래스를 사용했다.
  • 최근에는 주로 람다를 사용한다.

템플릿 콜백 패턴

  • 스프링에서는 ContextV2와 같은 방식의 전략 패턴을 템플릿 콜백 패턴이라 한다. 전략 패턴에서 Context가 템플릿 역할을 하고 Strategy 부분이 콜백으로 넘어온다 생각하면 된다.
  • 참고로 템플릿 콜백 패턴은 GOF 패턴은 아니고, 스프링 내부에서 이런 방식을 자주 사용하기 때문에 스프링 안에서만 이렇게 부른다. 전략 패턴에서 템플릿과 콜백 부분이 강조된 패턴이라 생각하면된다.
  • 스프링에서는 JdbcTemplate, RestTemplate, TransactionTemplate, RedisTemplate처럼 다양한 템플릿 콜백 패턴이 사용된다. 스프링에서 이름에 XXXTemplate가 있다면 템플릿 콜백 패턴으로 만들어져 있다 생각하면 된다.

템플릿 콜백 패턴은 전략패턴의 유연한 방식과 동일하다.

  • Context -> Template
  • Strategy -> Callback
public interface Callback {
    void call();
}

@Slf4j
public class TimeLogTemplate {

    public void execute(Callback callback) {
        long startTime = System.currentTimeMillis();
        //비즈니스 로직 실행
        callback.call(); //위임
        //비즈니스 로직 종료
        long endTime = System.currentTimeMillis();
        long resultTime = endTime - startTime;
        log.info("resultTime={}", resultTime);
    }
}


@Slf4j
public class TemplateCallbackTest {

    /**
     * 템플릿 콜백 패턴 - 익명 내부 클래스
     */
    @Test
    void callbackV1() {
        TimeLogTemplate template = new TimeLogTemplate();
        template.execute(new Callback() {
            @Override
            public void call() {
                log.info("비즈니스 로직1 실행");
            }
        });

        template.execute(new Callback() {
            @Override
            public void call() {
                log.info("비즈니스 로직2 실행");
            }
        });
    }

    /**
     * 템플릿 콜백 패턴 - 람다
     */
    @Test
    void callbackV2() {
        TimeLogTemplate template = new TimeLogTemplate();
        template.execute(() -> log.info("비즈니스 로직1 실행"));
        template.execute(() -> log.info("비즈니스 로직2 실행"));
    }

}

정리
템플릿 메서드 패턴, 전략 패턴, 그리고 템플릿 콜백 패턴까지 진행하면서 변하는 코드와 변하지 않는 코드를 분리했다. 그리고 최종적으로 템플릿 콜백 패턴을 적용하고 콜백을 람다를 사용해서 코드 사용도 최소화했다.

한계
하지만 위 방식들도 결국에는 원본 코드를 수정해야한다.
클래스가 수백개이면 수백개를 더 힘들게 수정하는가 또는 조금 덜 힘들게 수정하는 가의 차이가 있을뿐 본질적으로는 코드를 다 수정해야하는것은 마찬가지이다.
하지만 여기에도 방법은 있으며 그게 바로 원본 코드는 손대지 않고 수정하는 프록시 방식이다.

참고

해당 포스팅은 아래의 강의를 공부하여 정리한 내용입니다.
김영한님의 템플릿메서드패턴

profile
hoyong.eom
Hello
이전 포스트

Spring에서의 ThreadLocal

다음 포스트

Spring에서의 프록시 패턴과 데코레이터 패턴

0개의 댓글