디자인 패턴
안드로이드는 데이터와 UI에 대한 여러가지 디자인 패턴을 가진다.
- MVC : (Model - View - Controller)
- MVP : (Model - View - Presenter)
- MVVM : (Model - View - ViewModel)
- MVI : (Model - View - Intent)
MVC
Model : 애플리케이션에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분이다.
View : 사용자에게 보이는 UI 부분이다.
Controller : 사용자로부터 액션을 받고 처리하는 부분이다.
- MVC는 모바일 앱 특성상 Activity 그러니까 뷰 딴에 모든 데이터 로직과 UI 로직을 처리하는 부분을 쭉 늘려 놓는 것으로 하나의 클래스에서 메서드와 하여 쭉 구현하는것을 말할 수 있겠다. 이에 단점으로는 데이터와 UI가 처리하는 방식에 있어서 복잡하고 한눈에 보이지 않는다는 단점이 있을 수가 있다.
MVP
Model : 애플리케이션에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분이다.
View : 사용자에게 보이는 UI 부분이다.
Presenter : View에서 요청한 정보를 가공하여 View로 전달하는 부분이다.
UI와 데이터 로직간에 1대1 의존성이 증가함에 따라서 데이터를 하나 바꿨는데 여기에 엮여있는 모든 UI가 영향을 받을 수도 있다는 단점이 존재 할 수 있다..이게 기능이 추가될 수록 신경을 써야하는 부분이 많다.
MVVM
Model : 애플리케이션에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분이다.
View : ViewModel의 데이터들을 바라보고만 있고 실질적으로 영향을 받는건 데이터가 변할때 UI 업데이트를 한다.
ViewModel : Model과 상호작용하며 View에 종속되지 않고 1:N 구조를 갖는다.
View와 Model이 독립이 되어있다는게 가장 큰 장점이고 View는 옵저버를 통해 UI가 업데이트가 되는 로직을 갖는다.
MVI
Model : Intent로 전달받은 객체에 맞추어 새로운 불변객체를 Model로 생성한다.
View : Model의 결과물인 상태를 보고 있다가 변경시 UI를 업데이트 한다.
Intent : 앱의 상태를 바꾸려는 의도를 의미함 Model에게 앱의 상태를 전달한다.
이는 불변성이기 때문에 SideEffect를 통해 예외 처리를 할 수 있는 부분이 있다. 예를 들어 서버에서 예상하는 값과 다르게 나타난다면 앱이 팅기거나 어려가지 오류를 뱉을 수 있다.
마무리하며
이렇게 안드로이드에는 적용할 수 있는 디자인 패턴이 많은것을 할 수가 있다. 이를 통해 Model은 View와 최대한 멀어져야하며 데이터의 변동에 따른 업데이트 즉, View는 의존성을 줄여 보여주기만 하는것으로 해야 할것 같다. 실제로 앱이 런칭되고 예측할 수 없는 사용자들의 경우의 수가 있기 때문이고 물론 모든 경우의 수를 파악하고 모든 예외처리....라는건 불가능 할것 같다. 이에 로직을 분리하고 분리한 로직에서 어떠한 쓰임이 있는 클래스인지 한눈에 볼 수 있고 파악을 할 수 있다면 치명적인 fatal 오류가 발생하여도 바로 찾아 갈 수 있기 때문에 디자인 패턴의 도입과 코드를 유지보수와 가독성에 있어서 적용을 해야할것이다.
'앞으로의 도전, 새로운 시작' 카테고리의 다른 글
안드로이드 스튜디오 네이티브의 한계 (2) | 2024.07.16 |
---|---|
형상 관리 툴 SVN (5) | 2024.03.04 |
회고록의 끝과 시작, 목표를 향해[새로운 시작] (2) | 2024.01.17 |