프록시 패턴과 프록시 서버

프록시 패턴과 프록시 서버

---

프록시 패턴

• 특정 객체에 대한 접근을 제어하거나 기능을 추가할 수 있는 패턴
• 특정 객체에 접근하기 전에 프록시 객체를 먼저 지난 후 접근하게 한다.
  • 초기화 지연, 접근 제어, 로깅, 캐싱 등 다양하게 응용하여 사용할 수 있다.

위키백과

프록시 패턴 사용전

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

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

프록시 패턴 사용 후

public class Client {
    public static void main(String[] args) throws  InterruptedException {
        GameService gameService = new GameService (); //프록시 사용
        gameService.startGame();
    }
}

public class GameService {
    public void startGame() throws InterruptedException{
        System.out.println("게임을 시작합니다");
        Thread.sleep(1000L);
    }
}

public class GameServiceProxy extends GameService{
    @Override
    public void startGame() throws InterruptedException {
        long before = System.currentTimeMillis();
        super.startGame();
        System.out.println(System.currentTimeMillis() - before);
    }
}

장점

• 기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있다(OCP)
• 기존 코드가 해야 하는 일만 유지할 수 있다. (SRP)
• 기능 추가 및 추기화 지연등으로 다양하게 활용할 수 있다

단점

• 코드의 복잡도가 증가한다.

MVC 패턴

MVC (Model - View - Controller) 으로 각자의 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다. 재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.

1. Model : 데이터와 비즈니스 로직을 관리한다.
2. View : 레이아웃과 화면을 처리한다.
3. Controller : 명령을 모델과 뷰 부분으로 라우팅한다.

Model

데이터를 가진 객체를 모델이라 지칭한다. 데이터는 내부의 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다. 모델의 상태에 변화가 있을 때 Controller와 View에 이를 통보해야한다.

이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있다.

모델의 규칙

• 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.
• 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야한다.
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야한다.

View

Client 측 기술은 HTML / CSS / JavaScript 들을 모아둔 컨테이너이다. 사용자가 볼 결과물을 생성하기 위해 모델로 부터 정보를 얻어온다.

뷰의 규칙

• 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
• 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야한다.
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다.

Comtroller

사용자가 접근한 URL에 따라 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model을 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다.

컨트롤러의 규칙

• 모델이나 뷰에 대해서 알고 있어야한다.
• 모델이나 뷰의 변경을 모니터링해야 한다.

MVC 패턴의 한계

MVC패턴에서 View는 Controller에 연결되어 화면을 구성하는 단위 요소이므로 다수의 View를 가질 수 있다. 그리고 Model은 Controller를 통해서 View와 연결되지만, Controler에 의해서 하나의 View에 연결될 수 있는 Model도 여러 개가 될 수 있어 View와 Model이 서로 의존성을 띄게 된다. 즉, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 발생할 수 도 있다.

프록시 패턴과 프록시 서버

---

프록시 패턴

• 특정 객체에 대한 접근을 제어하거나 기능을 추가할 수 있는 패턴
• 특정 객체에 접근하기 전에 프록시 객체를 먼저 지난 후 접근하게 한다.
  • 초기화 지연, 접근 제어, 로깅, 캐싱 등 다양하게 응용하여 사용할 수 있다.

위키백과

프록시 패턴 사용전

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

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

프록시 패턴 사용 후

public class Client {
    public static void main(String[] args) throws  InterruptedException {
        GameService gameService = new GameService (); //프록시 사용
        gameService.startGame();
    }
}

public class GameService {
    public void startGame() throws InterruptedException{
        System.out.println("게임을 시작합니다");
        Thread.sleep(1000L);
    }
}

public class GameServiceProxy extends GameService{
    @Override
    public void startGame() throws InterruptedException {
        long before = System.currentTimeMillis();
        super.startGame();
        System.out.println(System.currentTimeMillis() - before);
    }
}

장점

• 기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있다(OCP)
• 기존 코드가 해야 하는 일만 유지할 수 있다. (SRP)
• 기능 추가 및 추기화 지연등으로 다양하게 활용할 수 있다

단점

• 코드의 복잡도가 증가한다.

MVC 패턴

MVC (Model - View - Controller) 으로 각자의 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다. 재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.

1. Model : 데이터와 비즈니스 로직을 관리한다.
2. View : 레이아웃과 화면을 처리한다.
3. Controller : 명령을 모델과 뷰 부분으로 라우팅한다.

Model

데이터를 가진 객체를 모델이라 지칭한다. 데이터는 내부의 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다. 모델의 상태에 변화가 있을 때 Controller와 View에 이를 통보해야한다.

이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있다.

모델의 규칙

• 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.
• 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야한다.
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야한다.

View

Client 측 기술은 HTML / CSS / JavaScript 들을 모아둔 컨테이너이다. 사용자가 볼 결과물을 생성하기 위해 모델로 부터 정보를 얻어온다.

뷰의 규칙

• 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
• 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야한다.
• 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다.

Comtroller

사용자가 접근한 URL에 따라 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model을 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다.

컨트롤러의 규칙

• 모델이나 뷰에 대해서 알고 있어야한다.
• 모델이나 뷰의 변경을 모니터링해야 한다.

MVC 패턴의 한계

MVC패턴에서 View는 Controller에 연결되어 화면을 구성하는 단위 요소이므로 다수의 View를 가질 수 있다. 그리고 Model은 Controller를 통해서 View와 연결되지만, Controler에 의해서 하나의 View에 연결될 수 있는 Model도 여러 개가 될 수 있어 View와 Model이 서로 의존성을 띄게 된다. 즉, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 발생할 수 도 있다.