📌[디자인 패턴] 방문자 (Visitor)

📖 01. Visitor란?

기존 코드를 건드리지 않고 새로운 기능을 추가하는 방법을 제안하는 패턴

• 기능을 추가하기 위해선 기존에 클래스에 코드를 추가한다.
• 그러나 그럴 수 없는 상황이 존재한다.
  예를 들어 SRP를 지키고 싶어서 더 이상 이 클래스가 가지고 있는 책임을 늘리고 싶지 않은 경우가 존재한다. 혹은 비슷한 코드가 여러 군데 생겨 한곳으로 모아놓고 싶을 때 visitor 패턴을 사용 할 수 있다.

📖 02. Visitor 패턴 예시

01. Visitor 패턴 사용 전

• 기존 Shape가 존재하고 디바이스 마다 다르게 출력하고 싶다고 가정하자.
  

• 과연 출력하는 것이 Shape의 역할일까?
  -> SRP가 깨졌다고 생각 할 수 있다.

• 만약 Shape 이나 Device가 추가된다고 하면 코드가 굉장히 늘어난다.
  -> 또한 Device가 늘어나면 기존 Shape 구현체의 코드도 추가해야 한다.
  
  

• 이렇게 하다보면 새로운 Shape 구현체를 만들었을 때 거대한 if문 때문에 코드를 놓칠 수 있다.
  -> 어떻게 해야 할까?

-> 메소드가 늘어나지만 실수 할 확률은 줄어든다!
그러나 이 코드의 문제점은 무엇일까?
(cf, 캡쳐 한번에 하려고 인터페이스에 class를 잠시 옮겨둔 것이다. 오류 X)

• 컴파일 타임에 해당하는 타입을 지원하는 메서드를 호출하게끔 한다.
  -> 즉, 스태틱한 맵핑을 한다.
• 이렇게 체크하지 않고 런타임으로 넘어가게 되면 특정 구현체로 구현된 메서드가 존재하지 않을 수 있기 때문이다.

• 그렇다면 기존 코드에 손대지 않고 기능을 추가 하고 싶다면 어떻게 해야 할까?
  -> 기능을 Device(Visitor)에 넣으면 된다.

Visitor 패턴

• visitor 패턴은 더블 디스패치(Dispatch)를 활용한다.

• 디스패치가 뭐야?
  -> 어떤 다형성이나 분배, 배치 어떤 요청이 들어오면 처리할 구체적인 클래스, 구체적인 메소드를 찾아서 배치하는 과정을 Dispatch라고 한다.

• 언제 더블 디스패치야?
  1. 클라이언트에서 Element(Shape)와 같은 인터페이스에 의존하고 있고 의존성 주입으로 구체화된 클래스를 모른다고 가정했을 때 하위 클래스와 해당 메서드를 찾는 과정
  2. 구체화 된 클래스에서 다시 한 번 인터페이스에 의존하여 구체 클래스를 모른 상태에서 그 클래스를 찾는 과정
  

• Element는 변경하면 안되는 인터페이스
  -> accept는 추가 해야 한다.

02. Visitor 패턴 사용 후

• 이제 비지터 패턴을 이용하여 해당 코드의 의존성을 제거해 보도록 하자.
• 방문자 패턴의 핵심은 더블 디스패치. 기존의 Shape 구현체에서 일어나던 비지니스 로직을 Device 에게 직접 처리하도록 수정한것이다.

📖 03. Visitor 패턴 장단점

• 장점

1. 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있다. (1차 디스패치기능은 추가해야함)
   -> ex) 패드에서 출력하고 싶다면 Device의 구현체로 만들면 끝!
2. 추가 기능을 한 곳에 모아둘 수 있다.

• 단점

1. 새로운 Element 를 추가하거나 제거할 때 모든 Visitor 코드를 변경해야 한다.
2. visit 메소드의 return 타입을 각각 파악하고 있어야 한다.

참고 자료)
https://thalals.tistory.com/402 - 힘차게, 열심히 공대생