MVP(Model-View-Presenter)
MVP 패턴은 Model, View, Presenter를 사용하는 디자인 패턴이다. MVP는 MVC(Model-View-Controller) 패턴의 파생 패턴으로 MVC 패턴의 Model 수정에 따른 View 의존성에 대한 문제를 해결하고자 생겨났다.
MVC 패턴은 아직 다룬 적이 없으므로, 해당 패턴을 알기 위해서는 다른 곳을 참고하길 바란다. ( 이후 추가가 된다면 수정할 예정임 )
위 이미지는 MVP 패턴의 작동 방식에 대해서 간략하게 소개하였으며, 구조는 다른 블로그의 내용과 다르게 서술되었으나, 유니티 공식 Git Repo에서 제공하는 게임 디자인 패턴 코드를 기반으로 작성했다. 문제가 있을 경우 댓글로 남겨주시면 감사하겠다.
위와 같이 MVP 패턴에서는 Model과 View 사이의 직접적인 상호작용은 존재하지 않는다. 그렇기 때문에 구현 로직과 UI 로직의 효과적인 분리가 가능해진다. MVP가 가진 내용을 아래에서 천천히 정리해보자.
Model
실질적으로 사용되는 구현 로직이다. Model은 언제, 어디서나 상태가 변경되는 객체로 구성된다. 해당 객체에서 일어나는 값 변동 혹은 상태 변동을 가지고 다른 일들을 처리한다.
View
UI를 담당한다. 유저가 바라보는 Interface적인 역할로 생각하면 된다. 유니티에서 예시를 든다면 Slider, Button, Text, 등 다양한 UI Component들을 예시로 들 수 있다. 해당 패턴에서는 Presenter를 통해서 값 변동이 일어나기 때문에 둘의 연관성은 매우 짙다.
Presenter
Model과 View 사이를 이어주는 매니저 역을 한다. 반응이 들어오면, Model에게 피드백을 보내고 돌아온 피드백을 가지고 View에 전달한다. 이때, 값을 가공하거나 수정하는 역할은 하지 않고 아무런 가공도 거치지 않은 순수 데이터를 View에 보낼 수 있도록 한다.
값에 대한 수정은 View에서 이루어진다.
왜 사용하는가?
앞서 말했듯이 MVC의 View <-> Controller 간의 의존성 문제를 해소하였고 Model에서 데이터가 추가 되었을 경우에도 대응할 수 있는 확장성이 매우 높다. 구현 로직과 UI 로직을 분리할 수 있기 때문에 코드 가독성에서도 도움이 된다.
단점이 무엇인가?
View와 Presenter는 MVC 패턴과 다르게 1대1로 매칭된다. 이후, Model에서 바라는 점이 많아져서 View가 추가되고 Presenter에 추가되는 값을이 많아진다면 과도하게 성장한 Presenter를 만날 수 있다.