디자인 패턴(Design Pattern)

객체 지향 프로그래밍 설계 시 자주 발생하는 문제를 해결하기 위해 디자인 패턴을 사용합니다. 특히 여러 사람이 협업하는 개발 환경에서, 다른 사람이 작성한 코드나 기존 코드를 이해하고 수정하는 것은 매우 어려운 작업입니다. 코드를 변경하거나 새로은 기능을 추가할 때 의도하지 않은 결과나 버그를 발생할 수 있으며, 성능 최적화도 까다롭습니다. 이러한 문제를 방지하고 개발 시간 및 비용을 절약하기 위해 디자인 패턴을 활용합니다. 디자인 패턴은 공통 문제에 대한 검증된 해결책을 제공함으로써, 코드의 가독성과 재사용성을 높이고, 팀 내의 기술적 의사소통을 원활하게 합니다.

MVC, MVP, MVVM 패턴
https://velog.io/@roel_dev/디자인-패턴MVC-MVP-MVVM-패턴

MVC, MVP, MVVM 같은 패턴들은 관심사의 분리를 통해 테스트 코드의 작성을 용이하게 해주는 등, 대규모 개발에 있어서 필수 불가결한 요소가 되었습니다.

MVC 패턴의 View와 Model 사이의 높은 결합도는 MVP, MVVM 패턴을 파생시켰고, 데이터와 뷰를 분리함으로써 얻는 장점으로 인해 현재는 많은 프로젝트에 MVP, MVVM 패턴을 사용하고 있습니다. 패턴의 View와 Model 사이의 높은 결합도는 MVP, MVVM 패턴을 파생시켰고, 데이터와 뷰를 분리함으로써 얻는 장점으로 인해 현재는 많은 프로젝트에 MVP, MVVM 패턴을 사용하고 있습니다.

하지만, 이들도 마냥 장점만 있는 것은 아니었습니다.

MVP, MVVM 패턴을 적용하면서 직면하는 문제로 두 가지가 발생하였습니다

상태 문제

• 안드로이드는 어떻게 보면 상태의 집합입니다. 화면에 나타나는 모든 정보나, 버튼 활성화 등 상태들로 구성되어 있습니다.
• 상태들을 관리하기 힘들어지고, 의도하지 않는 방향으로 제어가 된다면 상태 문제가 됩니다.

상태 문제의 좋은 예시로, 로그인이 실패했을 때 지속적으로 다음 화면이 보여 지는 상황이 발생합니다.

부수 효과

• 네트워크 통신, 데이터베이스 접근 등의 부수 효과들로 인해 발생합니다.
• 다이얼로그, 토스트 메시지, 액티비티의 이동도 이에 포함됩니다.
• 여러 비동기 작업들이 섞여서 어떤 결과를 얻을 지 예상할 수 없고 이에 따라 상태변화에 어려움을 겪습니다.
  위 문제들을 MVI에서 어떻게 풀어나가는지 확인해 보면서, MVI에 대해 알아보겠습니다.

MVI

MVI ⇒ Model + View + Intent 를 합친 용어

MVI는 Model, View, Intent로 이루어져 있으며, 데이터베이스, 네트워크 통신등의 작업을 진행하기 위해 SideEffect를 포함합니다.

• 사용자 또는 시스템의 Action을 포함하는 Intent가 발생합니다.
• Intent를 통해 Model이 reducing되고, Model을 Observing 하고 있던 View는 Rendering을 통해 View를 업데이트 합니다.

Intent

• 사용자 또는 앱 내의 상태를 바꾸려는 의도
• 모델은 인텐트를 통해서, 새로운 상태로 변화할 수 있다.
  • MVI의 단점 중 하나로, 가벼운 변경 사항도 이를 적용해야 합니다.

기존의 MVC나 MVVM 같은 디자인 패턴은, 어떠한 형식에 따라 개발자가 직접 설계하는 방식이었습니다. MVI 패턴 같은 경우에도 직접 작성할 수 있으나, MVI 패턴은 제공되는 프레임워크를 통해 설계 하는것이 좋습니다.

참고

https://small-stepping.tistory.com/1137
https://medium.com/@kimdohun0104/mvi-패턴에-대한-고찰-이유와-방법-그리고-한계-767cc9973c98
https://dev.to/kaleidot725/implementaing-jetpack-compose-orbit-mvi-3gea