Spring AOP - (1) 프록시 패턴, 데코레이터 패턴

📎  글또 6기 포스팅

1. 미치도록 더웠던 7월의 회고

 

2. 사용자가 게시물을 작성할 때의 트랜잭션 처리

 

3. Spring AOP - (1) 프록시 패턴, 데코레이터 패턴

 

4. [MySQL] - 트랜잭션의 격리 수준(Isolation level)

 

5. Spring AOP - (2) AOP 개념 및 실습

 

6. 인텔리제이(IntelliJ) - 디버깅(Debugging) 하기

 

7. [Java, 디자인패턴] - 싱글턴 패턴(Singleton Pattern)

 

8. 월간 코드리뷰 Ver_0.1: 커리어 성장 CODE 세미나 정리

 

9. 포스트맨(API 테스트) 활용하기

 

10. 뜻깊은 2021년 회고

 

---

📎  Spring AOP(Aspect Oriented Programming)

포스팅에 작성한 예제 코드는 깃허브에서 확인하실 수 있습니다 :)

 

안녕하세요, 이번 시간에 정리할 내용은 스프링 AOP(Aspect Oriented Programming) 입니다.

 

최근 몇몇 면접에서 AOP에 대해 질문을 받은적이 있었고, 실제 적용을 해보거나 정확하게 이해를 하고 있는 상태는 아니었기 때문에 이번 기회에 확실하게 이해를 하기 위해 포스팅을 작성하게 되었습니다. 😂

 

먼저 포스팅의 목적인 스프링 AOP에 대해 알아보기 전에 부가 기능을 위임하는 전통적인 방법으로 프록시와 데코레이터에 대해

정리를 한 후 스프링 AOP에 대해 알아보겠습니다.

 

포스팅의 목차 입니다.

• 부가 기능을 위임하는 전통적인 방법 1 - 프록시 패턴
• 부가 기능을 위임하는 전통적인 방법 2 - 데코레이터 패턴
• Spring AOP 개념
• Spring AOP 특징
• Spring AOP 용어
• Spring AOP 실습 1
• Spring AOP 어노테이션
• Spring AOP 실습 2
• 마무리

이번 포스팅에서는 부가 기능을 위임하는 전통적인 방법 - 프록시 패턴, 데코레이터 패턴에 대해 알아보겠습니다 :)

 

 

 

🎯  부가 기능을 위임하는 전통적인 방법 1 - 프록시 패턴

프록시(Proxy)

https://milkye.tistory.com/202

• 컴퓨터 프로그래밍에서 소프트웨어 디자인 패턴의 하나
• 다른 무언가와 이어지는 인터페이스 역할을 하는 클래스
• 어떤 객체에 대한 접근을 제어하는 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴

 

https://fastcampus.co.kr/

• 프록시와 리얼 서브젝트가 공유하는 인터페이스(Subject)가 존재하고, 클라이언트는 인터페이스 타입으로 프록시를 사용합니다.
• 클라이언트는 프록시를 거쳐 리얼 서브젝트를 사용하기 때문에 프록시는 리얼 서브젝트에 대한 접근 관리, 부가기능 제공, 리턴값 변경 등을 수행할 수 있습니다.
• 리얼 서브젝트는 자신이 해야 할 일(핵심 기능)만 수행하면서 프록시를 사용해 부가기능(로깅, 트랜잭션 등)을 제공하고자 할 때 이와 같은 프록시 패턴을 주로 사용합니다.
• 클라이언트는 프록시(대리인, 비서)를 거쳐서 리얼 서브젝트를 사용하게 됩니다.

 

 

프록시 패턴의 이해를 위해 로그인을 하는 기능에 대해 고려해보겠습니다.

위 상황에서 login() 메소드에는 로그인 기능을 나타내는 핵심 기능과 로깅, 트랜잭션 등과 같은 부가 기능을 모두 수행하게 됩니다.

하나의 메소드에서 여러 가지 기능을 수행하다보니 응집도도 낮아지게 되고 테스트 코드를 작성하더라도 핵심 기능 뿐만 아니라 부가 기능도 테스트를 해야 하기 때문에 좋지 않은 코드가 될 가능성이 높아지게 됩니다.

 

핵심 기능과 더불어 부가 기능도 포함된다면 여러 패키지에 의존하고 있을 확률이 높기 때문에 의존성또한 높아지게 되고,

이러한 의존성이 높은 코드는 리팩토링을 하기가 어렵고, 변화에 민첩하게 대응하기가 어려울 수 있습니다.

또한 객체지향 설계원칙(SOLID) 중 하나인 단일책임원칙(Single Responsibility Principle)에도 어긋나게 됩니다.

 

따라서 위와 같은 상황을 프록시 패턴을 통해 다음과 같이 개선할 수 있습니다.

위의 구조에서 클라이언트의 입장에서는 로그인 기능을 사용하는 것과 아무런 차이점이 존재하지 않습니다.

클라이언트가 로그인 기능을 수행하면 프록시 패턴에 의해 부가 기능이 수행되고, 핵심 기능이 수행되기 때문에 결과는 동일합니다.

 

 

 

프록시 패턴 예제

@Getter
@Setter
public class Book {
    private String title;
}


/* 서브젝트 역할 */
public interface BookService {
    void rent(Book book);
}

/* 프록시 */
public class BookServiceProxy implements BookService {

    // 프록시는 리얼 서브젝트를 가지고 있어야 함(delegate ->)
    private final RealBookService realBookService;

    public BookServiceProxy(RealBookService realBookService) {
        this.realBookService = realBookService;
    }

    // 프록시에서 부가기능을 추가
    @Override
    public void rent(Book book) {
        System.out.println("트랜잭션 처리");
        realBookService.rent(book); // 프록시 -> 리얼 서브젝트
        System.out.println("로깅");
    }
}

/* 리얼 서브젝트 역할 */
@Service
public class RealBookService implements BookService {

    /*
     rent(): 책을 빌리는(핵심 기능) 메소드
     책을 빌리기 전 후 트랜잭션 & 로깅(부가 기능) 추가
    */
    public void rent(Book book) {
        System.out.println("rent: " + book.getTitle());
    }
}

/* 클라이언트 */
public class Client {
    public static void main(String[] args) {
        BookService bookService = new BookServiceProxy(new RealBookService());
        bookService.rent(new Book());
    }
}


트랜잭션 처리
rent: null
로깅

 

위 코드와 아래 그림을 비교해가며 확인하시면 이해하기가 더 수월합니다 :)

위 예제코드에서 각 클래스는 다음과 같습니다.

• Client = Client
• BookService = Subject
• BookServiceProxy = Proxy
• RealBookService = RealSubject

 

따라서 프록시의 역할을 하는 BookServiceProxy는 리얼 서브젝트인 RealBookService 객체를 가지고 있습니다.

이를 통해 프록시는 부가 기능도 수행하며 핵심 기능인 책을 빌리는 기능도 수행할 수 있습니다.

 

프록시 부분의 코드만 다시 살펴보면 다음과 같습니다.

/* 프록시 */
public class BookServiceProxy implements BookService {

    // 프록시는 리얼 서브젝트를 가지고 있어야 함(delegate ->)
    private final RealBookService realBookService;

    public BookServiceProxy(RealBookService realBookService) {
        this.realBookService = realBookService;
    }

    // 프록시에서 부가기능을 추가
    @Override
    public void rent(Book book) {
        System.out.println("트랜잭션 처리");
        realBookService.rent(book); // 프록시 -> 리얼 서브젝트
        System.out.println("로깅");
    }
}

 

 

 

 

🎯  부가 기능을 위임하는 전통적인 방법 2 - 데코레이터 패턴

데코레이터 패턴을 설명하기 전에 왜 필요한지 상속을 통한 확장과 함께 살펴보겠습니다.

 

내비게이션 SW에서 도로를 표시하는 기능에 대해 생각해보겠습니다.

기본적인 기능은 도로를 간단한 선으로 표시하는 것이고, 내비게이션에 따라 도로의 차선을 표시하는 기능은

(추가적으로) 제공할 수 있습니다.

이러한 상황에서 도로를 표시하는 기능의 클래스를 다음과 같이 나타내보겠습니다.

• RoadDisplay 클래스: 기본 도로 표시 기능을 제공
• RoadDisplayWithLane 클래스: 추가적으로 차선을 표시하는 기능을 제공

public class RoadDisplay { // 기본 도로 표시 기능
    public void draw() {
        System.out.println("기본 도로 표시");
    }
}


public class RoadDisplayWithLane extends RoadDisplay { // 기본 도로 표시 + 차선 표시

    @Override
    public void draw() {
        super.draw(); // 상위 클래스(기본 도로 표시)
        drawLine();   // 추가적으로 차선 표시
    }

    private void drawLine() {
        System.out.println("차선 표시");
    }
}


public class Client {
    public static void main(String[] args) {
        RoadDisplay road = new RoadDisplay();
        road.draw(); // 기본 도로만 표시

        RoadDisplay roadWithLane = new RoadDisplayWithLane();
        roadWithLane.draw(); // 기본 도로 + 차선 표시
    }
}

기본 도로 표시
기본 도로 표시
차선 표시

RoadDisplay 클래스는 기본 도로 표시 기능을 위한 draw() 메소드를 구현합니다.

RoadDisplayWithLane 클래스는 기본 도로 + 차선 표시를 위해 상속받은 draw() 메소드를 오버라이드 합니다.

 

 

문제점

• 차선 표시가 아닌 또 다른 기능을 추가로 구현하고 싶다면 어떻게 해야할까요? ex) 기본 도로 표시 + 교통량 표시
• 다양한 추가 기능을 조합해 제공하고 싶다면 어떻게 해야 할까요? ex) 기본 도로 표시 + 차선 표시 + 교통량 표시

위 문제점을 해결하기 위해 RoadDisplay 클래스를 상속받아 교통량을 표시하는 RoadDisplayWithTraffic 클래스를 만들어보겠습니다.

RoadDisplayWithTraffic 클래스를 생성하고 난 후의 클래스 다이어그램은 다음과 같습니다.

 

// 기본 도로 표시 + 교통량 표시
public class RoadDisplayWithTraffic extends RoadDisplay {

    @Override
    public void draw() {
        super.draw(); // 상위 클래스(기본 도로 표시)
        drawTraffic(); // 교통량 표시
    }

    private void drawTraffic() {
        System.out.println("교통량 표시");
    }
}

RoadDisplay 클래스의 하위 클래스로 도로 표시에 추가적인 기능(차선 표시, 교통량 표시 등)을 제공하는 것은 적절한 설계 방법이 될 수 있습니다. 그러나 다양한 기능의 조합을 고려해야 하는 경우 상속을 통한 확장은 각 기능별 클래스를 추가해야 한다는 단점이 존재합니다.

 

예를 들어 도로 표시를 하는 기본 기능에 추가로 제공할 수 있는 기능으로 차선 표시, 교통량 표시, 교차로 표시를 3가지의 추가 기능이 존재한다고 했을때, 조합할 수 있는 경우의 수는 다음과 같이 총 8가지의 조합이 가능합니다.

경우	기본 기능 (도로 표시)	추가 기능			클래스 이름
		차선 표시	교통량 표시	교차로 표시
1	O				RoadDisplay
2	O	O			RoadDisplayWithLane
3	O		O		RoadDisplayWithTraffic
4	O			O	RoadDisplayWithCrossing
5	O	O	O		RoadDisplayWithLaneTraffic
6	O	O		O	RoadDisplayWithLaneCrossing
7	O		O	O	RoadDisplayWithTrafficCrossing
8	O	O	O	O	RoadDisplayWithLaneTrafficCrossing

위 표와 같이 각 조합별로 RoadDisplay 클래스를 상속받는 7개의 하위 클래스를 추가해야 합니다.

더 확장해서 추가 기능이 n개라면 (2^n - 1)개의 하위 클래스를 추가해야 하는 엄청난 작업을 해야합니다.

 

이와 같이 상속을 이용한 기능 추가 방법을 통해 해결할 수 있지만, 추가되는 기능의 조합별로 하위 클래스를 구현해야 하는 문제점이 있습니다. 이렇게 조합 수가 늘어나는 문제를 해결할 수 있는 설계를 하기 위해서는 각 추가 기능별로 개별적인 클래스를 설계하고, 기능을 조합할 때 각 클래스의 객체 조합을 이용함으로써 해결할 수 있습니다.

 

데코레이터 패턴을 통해 위 문제점을 해결해보도록 하겠습니다.

※ 추가 기능을 확장할 일이 없다는 가정하에 상속으로 설계를 했더라도, 실제 소프트웨어 개발은 어떻게 될 지 모르는 일이기에 처음부터 설계를 제대로 한다면 이러한 상속 확장의 문제를 더 간단하게 해결할 수 있습니다.

 

상속 방식의 추가 기능 문제점 해결(데코레이터 패턴)

기본 기능(기본 도로 표시)만 이용할 때는 RoadDisplay 클래스의 객체를 생성하면 충분합니다.

하지만 차선을 표시하는 기능이 추가적으로 필요하다면 LaneDecorator 클래스의 객체가 필요합니다.

이 때 LaneDecorator에서는 차선 표시 기능만 직접적으로 제공하고, 기본 도로 표시 기능은 RoadDisplay 클래스의 draw() 메소드를 호출하는 방식으로 구현합니다.

이를 위해 LaneDecorator 클래스는 RoadDisplay 객체에 대한 참조가 필요한데, 이를 상위 클래스인 DisplayDecorator 클래스에서 Display 클래스로의 컴포지션(composition) 관계를 통해 표현되고 있습니다.

 

위 방식으로 설계된 클래스의 코드를 살펴보겠습니다.

public abstract class Display {
    public abstract void draw();
}


// 기본 도로 표시
public class RoadDisplay extends Display {

    @Override
    public void draw() {
        System.out.println("기본 도로 표시");
    }

}


// 다양한 추가 기능에 대한 공통 클래스
public abstract class DisplayDecorator extends Display {
    private final Display decoratedDisplay;

    public DisplayDecorator(Display decoratedDisplay) {
        this.decoratedDisplay = decoratedDisplay;
    }

    public void draw() {
        decoratedDisplay.draw();
    }

}


// 차선 표시
public class LaneDecorator extends DisplayDecorator {
    
    // 기존 표시 클래스 설정
    public LaneDecorator(Display decoratedDisplay) {
        super(decoratedDisplay);
    }
    
    public void draw() {
        super.draw(); // 설정된 기존 표시 기능 수행
        drawLane();   // 추가적으로 차선 표시
    }

    private void drawLane() {
        System.out.println("\t차선 표시");
    }
}


// 교통량 표시
public class TrafficDecorator extends DisplayDecorator {

    // 기존 표시 클래스 설정
    public TrafficDecorator(Display decoratedDisplay) {
        super(decoratedDisplay);
    }

    public void draw() {
        super.draw(); // 설정된 기존 표시 기능 수행
        drawTraffic();
    }

    private void drawTraffic() {
        System.out.println("\t교통량 표시");
    }
}


// 클라이언트, new -> 객체와의 조합
public class Client {
    public static void main(String[] args) {
        Display road = new RoadDisplay();
        road.draw(); // 기본 도로 표시

        Display roadWithLane = new LaneDecorator(new RoadDisplay());
        roadWithLane.draw(); // 기본 도로 표시 + 차선 표시

        Display roadWithTraffic = new TrafficDecorator(new RoadDisplay());
        roadWithTraffic.draw(); // 기본 도로 표시 + 교통량 표시
        
        Display roadWithLaneAndTraffic = 
        	new TrafficDecorator(new LaneDecorator(new RoadDisplay()));
        roadWithLaneAndTraffic.draw(); // 기본 도로 표시 + 차선 표시 + 교통량 표시
    }
}



기본 도로 표시

기본 도로 표시
    차선 표시
    
기본 도로 표시
    교통량 표시
    
기본 도로 표시
    차선 표시
    교통량 표시

위 코드에서 살펴볼 점은 road, roadWithLane, roadWithTraffic 객체의 접근이 모두 Display 클래스를 통해 이루어진다는 점입니다.

즉 다음과 같은 기능에 관계없이 Client 클래스는 모두 Display 클래스만을 통해 일관성 있는 방식으로 도로 정보를 표시할 수 있습니다.

• road: 기본 도로 표시
• roadWithLane: 기본 도로 표시 + 차선 표시
• roadWithTraffic: 기본 도로 표시 + 교통량 표시
• roadWithLaneAndTraffic: 기본 도로 표시 + 차선 표시 + 교통량 표시

이전 상속의 방식에서는 추가 기능 조합별로 별도의 클래스를 구현을 해야했지만, 위와 같은 방식의 설계를 이용하면 조합별 별도의 클래스를 구현하는 대신 각 추가 기능에 해당하는 클래스의 객체를 조합해 추가 기능의 조합을 구현할 수 있습니다.

이러한 설계는 추가 기능의 수가 많을수록 조합의 경우의 수도 많아지므로 효과가 큽니다.

 

예를 들어 차선 표시 + 교통량 표시의 추가 기능에 교차로를 표시하는 추가 기능을 지원하는 경우 아래 UML과 같이 단순히 CrossingDecorator 클래스만 추가한 후 객체와의 조합을 통해 적용을 할 수 있습니다.

// 교차로 표시
public class CrossingDecorator extends DisplayDecorator {
    
    // 기존 표시 클래스 설정
    public CrossingDecorator(Display decoratedDisplay) {
        super(decoratedDisplay);
    }
    
    public void draw() {
        super.draw();   // 설정된 기존의 표시 기능 수행
        drawCrossing(); // 추가적으로 교차로 표시
    }

    private void drawCrossing() {
        System.out.println("\t교차로 표시");
    }

}


// 클라이언트
public class Client {
    ...
    
    // new ...(new ...(new ...( -> 객체 조합
    Display roadWithCrossingAndLandAndTraffic
        = new LaneDecorator(new TrafficDecorator(new CrossingDecorator(new RoadDisplay())));
    roadWithCrossingAndLandAndTraffic.draw(); // 기본 도로 표시 + 차선 표시 + 교통량 표시 + 교차로 표시
}


기본 도로 표시
	교차로 표시
	교통량 표시
	차선 표시

 

 

 

데코레이터(Decorator) 패턴

• 기본 기능에 추가할 수 있는 기능의 종류가 많은 경우 각 추가 기능을 Decorator 클래스로 정의한 후 필요한 Decorator 객체를 조합함으로써 추가 기능의 조합을 설계
• 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴
• 기능 확장이 필요할 때 서브클래스 대신 사용할 수 있는 유연한 대안이 될 수 있음
• 앞으로의 변경이 얼마나 될지 모르는 상황에서 상속을 사용한 프로그래밍은 변경에 유연하지 못함

 

데코레이터 패턴의 UML입니다.

• Component: 기본 기능을 뜻하는 ConcreteComponent와 추가 기능을 뜻하는 Decorator의 공통 기능을 정의, 즉 클라이언트는 Component를 통해 실제 객체를 사용
• ConcreteComponent: 기본 기능을 구현하는 클래스
• Decorator: 많은 수가 존재하는 구체적인 Decorator의 공통 기능을 제공
• ConcreteDecoratorA, ConcreteDecoratorB: Decorator의 하위 클래스로 기본 기능에 추가되는 개별적인 기능

 

데코레이터 패턴의 시퀀스 다이어그램입니다.

ConcreteComponent가 c로 정의되어 있고, ConcreteDecoratorA의 객체 a와 이에 대한 데코레이터로 ConcreteDecoratorB의 객체 b가 있다고 가정해보곘습니다.

즉, 다음과 같이 객체가 생성된 경우입니다.

Component c = new ConcreteComponent();
Component a = new ConcreteDecoratorA(c);
Component b = new ConcreteDecoratorB(a);

위 코드에서 Client가 객체 b의 operation 메소드를 호출하면 객체 b가 가리키는 Component, 즉 ConcreteDecoratorA 객체 a의 operation 메소드를 호출합니다.

객체 a 역시 자신이 가리키는 Component, 즉 ConcreteComponent 객체 c의 operation 메소드를 호출한 후 자신의 addedBehavior 메소드를 호출합니다.

객체 b 역시 객체 a의 operation 메소드를 호출한 후 자신의 addedBehavior 메소드를 호출합니다.

 

 

AOP에 대한 정리를 하려고 했지만 ..... 이번 포스팅에서는 부가 기능을 위임하는 전통적인 방법인 프록시와 데코레이터 패턴에 대해 정리를 해보았습니다. 평소 자바를 사용하면서 입력을 받을 때, 가끔 BufferedReader 클래스를 사용한 적이 있었는데 이 클래스를 사용해서 객체를 생성할 때 다음과 같이 생성을 했었는데, 이것이 데코레이터 패턴을 사용했던 예제 인 것 같습니다.

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

 

개인적으로 데코레이터 패턴의 경우 이해하기까지 몇 번을 계속해서 보았는데, 완전히 이해를 했다고는 보기 힘들겠지만 계속 보다보니 대략적으로나마 이해가 되는 것 같습니다.

사실 이렇게 정리를 하는 것도 좋지만, 가장 좋은 방법은 실제 적용을 해 보는 방식이라고 생각합니다. 다음에 실무에서 이러한 패턴을 적용해보고, 경험을 통해 제 것으로 만들고 싶습니다 :)

그 때 기회가 된다면, 다시 정리를 해보도록 하겠습니다.

 

AOP까지 정리를 하기엔 내용이 너무 방대해질 것 같아 AOP에 대한 정리는 다음 포스팅에서 하도록 하겠습니다. 🤣

 

 

 

 

References

• https://fastcampus.co.kr/
• https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C
• https://milkye.tistory.com/202
• https://www.inflearn.com/course/the-java-code-manipulation/dashboard
• http://www.yes24.com/Product/Goods/12501269