[Gof의 디자인패턴] 프록시 패턴

🐙 프록시 패턴이란?

- 특정한 객체에 접근하기 전에 프록시를 지나서 접근하는 패턴, 여기서 프록시는 대리인이라는 뜻

- 미리 만들었지만 사용이 안된다면 메모리 낭비가 되기 때문에 실제로 사용되는 시점에서 초기화 지연하기 위해서 사용

- 유저가 권한이 있어야만 접근할 수 있도록 접근 제어 가능

- 프록시 내에 미리 캐싱을 해둔 데이터가 있다면 오퍼레이션까지 가지 않고 반환

 

- RealSubject 는 실제로 사용을 해야 하는 객체

- proxy는 인터페이스 타입으로 필드를 갖고 있음. 해당 필드를 통해 real subject 를 참조하고, 이를 감싸서 프록시로 들어오는 operation 중에 real subject 를 사용해야 하는 경우에는 사용하고, 추후에 작업을 할 수 있도록 함.

 

만일, 초기화 지연에 사용된다면 해당하는 객체가 이미 있는지 프록시에서 확인하고 없는 경우에만 새로 생성

만일, 권한 확인에 사용된다면 프록시를 거쳐서 권한 확인을 하고, 권한이 확인된 경우에만 해당 객체에 접근할 수 있도록

만일, 캐싱에 사용된다면 캐싱된 데이터 목록을 확인하고 해당 목록에 없는 경우에만 오퍼레이션으로 이동할 수 있도록

 

🐙 프록시 패턴 구현해보기

게임을 실행하는 GameService 클래스가 있다고 가정해보자.

public class GameService {
    public GameService() {
    }

    public void startGame() {
        System.out.println("게임을 시작합니다.");
    }
}

public static void main(String[] args) {
        GameService gameService = new GameService();
        gameService.startGame();
    }

위의 상황에서 실행시간을 측정하는 기능을 추가하고자 한다고 가정해보자. 

 

우선은, GameService 를 인터페이스로 바꾸어 위의 다이어그램에 따르면 Subject의 역할을 하도록 한다.

public interface GameService {
    void startGame();
}

 

해당 인터페이스를 구현한 RealSubject 를 생성한다.

public class RealSubject implements GameService {

    @Override
    public void startGame() {
        System.out.println("게임을 시작합니다.");
    }
}

 

public class Proxy implements GameService {
    private GameService gameService;

    @Override
    public void startGame() {
        long before = System.currentTimeMillis();

        if (gameService == null) {
            gameService = new RealSubject();
        }
        gameService.startGame();

        System.out.println(System.currentTimeMillis() - before);
    }
}

프록시 패턴에서는 데코레이터 패턴과 같이 해당 오퍼레이션으로 이동하기 전과 후에 프록시 패턴을 거치도록 한다.

전과 후에 시간을 재도록 하고, gameService를 주입받지 않고 null 인 경우에만 새로 객체를 생성하도록 하여 초기화를 미룬다. 만일, 프록시 패턴을 통해서 lazy initialization 이 이루어지지 않는다면 어떻게 될까?

게임 서비스가 실제로 사용되지 않는데 RealSubject 가 미리 생성되어 주입되게 된다면 메모리의 낭비를 부르게 되는 것이다.

 

 

🐙 프록시 패턴의 장점 / 단점

장점

1. 기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있다.

2. 기존 코드가 해야 하는 일만 유지할 수 있다.

3. 실제 객체의 public, protected 메소드를 숨기고 인터페이스를 통해 노출시킬 수 있다.

4. 사이즈가 큰 객체의 경우 로딩되기 전에 프록시를 통해 참조를 할 수 있다.

 

단점

1. 코드의 복잡도가 증가한다. -> 인터페이스를 만들고 구현하게 되면 더 유연해진다.

2. 스레드의 생성과 동기화가 되어야 하는 경우에 성능이 저하될 수 있다.