Proxy 패턴은 실제 동작할 object는 뒤에 숨겨놓고 client의 요청을 바로 object에 전달하는 대신,
앞단에서 필요한 처리들을 해준 후에 실제 object로 전달을 해주거나 거부하는 패턴입니다.
중요한 점은 사용자 입장에서는 proxy를 쓰고 있는지 실제 object를 쓰는지 모릅니다.
자동차 운전을 예시로 들면 자동차 운전은 운전면허가 있는 사람만 가능하게 해야합니다.
이 때, 자동차 구조체와 운전자 구조체는 서로 의존되지 않아야 합니다.
그럼 바로 코드로 구현해보겠습니다.
1
2
3
|
type Driven interface {
Drive()
}
|
cs |
Car 구조체와 CarProxy 구조체를 같이 다루기 위해 interface 타입을 하나 만들어줍니다.
1
2
3
4
5
6
7
8
9
|
type Car struct {}
func (c *Car) Drive() {
fmt.Println("driving..")
}
type Driver struct {
License bool
}
|
cs |
위처럼 자동차 구조체와 운전자 구조체가 있습니다.
운전자 구조체의 License 필드가 true여야만 운전이 가능하게 해야합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
type CarProxy struct {
car Car
driver *Driver
}
func (c *CarProxy) Drive() {
if c.driver.License {
c.car.Drive()
} else {
fmt.Println("Driver has no license")
}
}
func NewCarProxy(driver *Driver) *CarProxy {
return &CarProxy{Car{}, driver}
}
|
cs |
Proxy 패턴을 이용하여 CarProxy 구조체를 만들었습니다.
인터페이스를 적용하기 위해 Drive 메서드를 구현해주었는데 여기서 운전자의 라이센스 여부에 따라 필터링을 합니다.
1
2
|
car := NewCarProxy(&Driver{false})
car.Drive()
|
cs |
이렇게 사용자 입장에서는 Proxy 객체를 사용해도 Drive 메서드를 사용할 수 있으며,
코드상에서는 자동차와 운전자를 분리할 수 있었습니다.
'golang > design pattern' 카테고리의 다른 글
golang design pattern #13 Observer (0) | 2021.11.23 |
---|---|
golang design pattern #11 Chain of Responsibility (0) | 2021.11.16 |
golang design pattern #9 Flyweight (0) | 2021.11.14 |
golang design pattern #8 Decorator (0) | 2021.11.13 |
golang design pattern #7 Composite (0) | 2021.11.12 |