아키텍쳐 디자인 패턴 - MVP란?

이전 포스팅의 MVC에 이어서 MVP 패턴에 대해 알아보겠습니다.

 

MVP란?

 Model, View, Presenter로 구성된 디자인 패턴입니다. MVP의 핵심 설계는 MVC와 다르게 UI(View)와 로직(Model)을 분리하고, 서로 간에 상호작용을 다른 객체(Presenter)에 그 역할을 줌으로써, 서로의 영향(의존성)을 최소화하는 것에 있습니다.

 

MVP 구조

각 객체들의 특징은 아래와 같습니다.

 

Model

 - 프로그램 내부적으로 쓰이는 데이터를 저장하고, 처리하는 역할(비즈니스 로직).

 - View 또는 Presenter 등 다른 어떤 요소에도 의존적이지 않은 독립적인 영역.

 

View

 - UI를 담당하며 안드로이드에서는 Activity, Fragment가 대표적인 예.

 - Model에서 처리된 데이터를 Presenter를 통해 전달받아서 유저에게 보여줌.

 - 유저의 행동(Action) 및 Activity 생명 주기 상태 변경을 주시하며 Presenter에 전달하는 역할.

 - Presenter를 이용하여 데이터를 주고받기 때문에 Presenter에 매우 의존적임.

 

Presenter

 - Model과 View사이의 매개체.

 - Model과 View를 매개체라는 점에서 Controller와 유사하지만, View에 직접 연결되는 대신 인터페이스를 통해 상호작용한다는 차이가 있음.

 - 인터페이스를 통해 상호작용하므로 MVC가 가진 테스트 문제와 함께 모듈화/유연성 문제 역시 해결할 수 있음.

 -  View에게 표시할 내용(Data)만 전달하며 어떻게 보여줄 지는 View가 담당.

 

 

MVP의 장점

 - MVC와는 다르게 코드가 깔끔해지고, Model과 View의 결합도를 낮추면, 새로운 기능 추가 및 변경을 할때 마다 관련된 부분만 코드를 수정하면 되기 때문에 확장성이 개선됩니다.

 또한, UI, Data 각각 파트를 나누어서 해야할 일(역할)이 명확해지고, 쉽고 빠른 코딩이 가능합니다.

 

MVP의 단점

 - 어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 강해지는 문제가 있습니다. MVC의 Controller처럼 추가 비즈니스 로직에 집중되는 경향이 있습니다.

 개발자는 오랜 시간 앱을 개발하는 어느 순간, 거대해지며 문제가 발생하기 쉽고, 분리하기 어려운 Presenter를 발견하게 됩니다. (물론, 초기에 설계/기획을 잘하면서 앱의 다양한 변화에 따라 대응한다면 위와 같은 문제는 발생하지 않지만, 그것마저도 쉽지 않다.)

 

 

 

위에서 이해한 내용을 바탕으로 실제 앱에서의 행동 절차와 코드는 아래와 같습니다. 코드를 살펴보면, Presenter에서 각 행동의 의도가 더 단순하고 명확해진 것을 확인할 수 있습니다. View에게 특정 정보를 표시하는 방법을 지시하는 대신, 표시할 내용만 전달합니다.

 

public class TicTacToePresenter implements Presenter {

    private TicTacToeView view;
    private Board model;

    public TicTacToePresenter(TicTacToeView view) {
        this.view = view;
        this.model = new Board();
    }

    // Here we implement delegate methods for the standard Android Activity Lifecycle.
    // These methods are defined in the Presenter interface that we are implementing.
    public void onCreate() { model = new Board(); }
    public void onPause() { }
    public void onResume() { }
    public void onDestroy() { }

    /** 
     * When the user selects a cell, our presenter only hears about
     * what was (row, col) pressed, it's up to the view now to determine that from
     * the Button that was pressed.
     */
    public void onButtonSelected(int row, int col) {
        Player playerThatMoved = model.mark(row, col);

        if(playerThatMoved != null) {
            view.setButtonText(row, col, playerThatMoved.toString());

            if (model.getWinner() != null) {
                view.showWinner(playerThatMoved.toString());
            }
        }
    }

    /**
     *  When we need to reset, we just dictate what to do.
     */
    public void onResetSelected() {
        view.clearWinnerDisplay();
        view.clearButtons();
        model.restart();
    }
}

 

Activity를 Presenter에 묶지않고, 해당 작업을 수행하려면, Activity가 구현할 인터페이스를 생성해야 합니다. 테스트에서는 이 인터페이스를 기반으로 한 가상 객체를 만들어서 Presenter의 View와의 상호작용을 테스트합니다.

 

public interface TicTacToeView {
    void showWinner(String winningPlayerDisplayLabel);
    void clearWinnerDisplay();
    void clearButtons();
    void setButtonText(int row, int col, String text);
}

 

 이를 통해, 안드로이드 고유의 View와 API가 연결되지 않는 것을 확인할 수 있습니다. 또한, 위 코드처럼 인터페이스를 구현했다면 어떤 View와도 작업할 수 있어서 Presenter 로직을 쉽게 테스트할 수 있습니다.

 

 

 (코드의 출처: https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/)