소프트웨어 아키텍처 패턴이란?

소프트웨어 시스템을 설계할 때 사용되는 일련의 설계 원칙과 가이드라인이다

설계 원칙과 가이드라인은 소프트웨어 시스템을 구성하는 구성 요소들의 역할과 책임, 그리고 이들 간의 관계를 말하는 것이다

만약 가이드 라인이 없다면 협업을 하면서 다른 사람의 짠 코드를 이해할 수 없을 것이다.

Android에서 대중적으로 사용되는 아키텍처 패턴 3가지

MVC(Model-View-Controller)

• Model
  데이터와 비즈니스 로직을 처리하는 역할
  모델은 데이터를 관리하고, 비즈니스 로직을 구현한다.

• View
  사용자에게 보이는 화면이다
  사용자가 시스템과 상호작용하는 인터페이스를 제공한다.

• Controller
  모델과 뷰 사이에서 상호작용을 조정하는 역할
  컨트롤러는 사용자 입력을 처리하고, 모델에 변경 사항을 알리며, 뷰를 업데이트한다.

MVC 아키텍처 패턴의 장점

• 각 역할에 대한 역할 분담과 책임 분담을 명확하게 할 수 있다
• 뷰와 모델 간의 의존성이 없으므로 뷰나 모델을 변경해도 다른 요소에 영향을 미치지 않는다
• 시스템의 구조를 분리하여 유지보수성을 높일 수 있다.

MVC 아키텍처 패턴의 단점

• Model, View, Controller가 서로 높은 결합도를 가지기 때문에, 이들 중 하나의 변경이 다른 컴포넌트에 영향을 미칠수 있다.
  -> 애플리케이션의 유지보수성을 떨어뜨린다.
• View와 Controller가 서로 밀접하게 연결되어 있기 때문에, View와 Controller의 복잡성이 증가할 가능성이 높다.
  -> 코드의 가독성과 유지보수성을 낮출 수 있다.
• MVC 패턴에서는 컨트롤러가 모든 비즈니스 로직을 처리하므로, 이를 담당하는 클래스가 매우 복잡해질 수 있다.
  -> 코드의 재사용성을 낮출 수 있다

---

MVP(Model-View-Presenter)

• Model
  데이터와 비즈니스 로직을 담당한다.
  네트워크나 데이터베이스와 같은 데이터 소스와 상호작용하여 데이터를 가져오고, 처리
• View
  사용자 인터페이스를 담당한다.
  사용자의 입력을 받아 처리하고, 화면에 결과를 출력
• Presenter
  Model과 View를 중개하는 역할을 담당
  View에서 사용자 입력을 받으면, Presenter는 Model에서 데이터를 가져와 처리한 후,
  결과를 View에 전달한다. 또한 Model에서 데이터 변경이 일어나면, 이를 View에 전달하여 업데이트

MVP 아키텍처 패턴의 장점

• Model과 View가 서로 독립적이며, Presenter가 중재하는 구조로 설계
  -> View와 Model 사이의 의존성이 줄어들어 유지보수와 테스트가 용이
• 비즈니스 로직을 Presenter로 이동시킴
  -> View는 단순히 UI 표현에만 집중할 수 있으므로, 코드의 가독성과 유지보수성이 높아짐

MVP 아키텍처 패턴의 단점

• Presenter가 View와 Model 사이의 중재자 역할을 수행하며, 이는 Presenter가 많은 책임
  -> Presenter의 복잡성을 증가시키고, 테스트의 어려움
  이유

  Presenter가 View와 Model을 연결하기 때문에, Presenter를 테스트하기 위해서는 View와 Model에 대한 모의 객체(mock objects)를 만들어야 한다 또한 Presenter가 View와 Model 사이의 중재자 역할을 수행하면서, Presenter에서 발생한 오류가 View와 Model에서 발생한 오류와 혼동

• MVP 패턴에서는 View가 Presenter와 밀접하게 결합되어 있다
  -> View의 재사용성을 낮출 수 있다.
  이유

  View와 Presenter가 함께 동작하여 사용자 인터페이스를 제어하고 이벤트 처리를 수행하기 때문에 View가 Presenter와 밀접하게 겹합되어 있음

• MVP 패턴은 구현이 상대적으로 복잡
  -> 애플리케이션의 코드 양이 많아지고, 유지보수성을 저하
  이유

  MVP 패턴이 MVC 패턴에 비해 Presenter 레이어를 추가하여 구조가 복잡해진다는 것과, Presenter와 View 간의 인터페이스 정의 및 구현을 수동으로 처리해야함

  Presenter와 View 간의 인터페이스 정의 및 구현을 수동으로 처리??

  Presenter가 View에서 발생하는 이벤트를 수신하기 위한 메서드들을 선언하는 것을 의미
  Presenter에서는 View 인터페이스를 구현하는 코드를 작성해야 하고, View에서는 Presenter 인터페이스를 구현하는 코드를 작성해야 합니다. 이러한 과정은 수동으로 처리

---

MVVM(Model-View-ViewModel)

• Model
  데이터를 나타낸다.
  데이터베이스, 파일 또는 웹 서비스와 같은 데이터 소스와 상호작용

• View
  UI를 나타내며 사용자와 상호작용한다.
  사용자 인터페이스 이벤트를 처리하고, ViewModel에서 제공하는 데이터를 표시

• ViewModel
  View와 Model 간의 매개체(중개자,인터페이스)
  비즈니스 로직을 처리하고 View에서 표시할 데이터를 준비
  View와 Model 사이에서 데이터를 변환하고 필요한 데이터를 가져오는 역할

MVVM 아키텍처 패턴의 장점

• 뷰와 모델을 분리하여 애플리케이션의 유지 보수성을 높인다.
  -> 뷰와 모델은 서로 독립적이기 때문에 변경 사항이 있을 때 서로 영향을 주지 않는다.

• 데이터 바인딩을 지원하여 뷰와 모델 간의 데이터 전달을 간소화
  -> 뷰 모델은 뷰에 대한 변경 사항을 감지하고 자동으로 업데이트

  정확히는 ViewModel클래스 안에 있는 LiveData이 뷰에 대한 변경 사항을 감지하고 ViewModel이 업데이트 해준다

• 뷰와 모델을 분리하여 뷰 없이 모델을 테스트하는 것이 가능
  -> 개발자가 뷰의 영향을 받지 않고 모델의 동작을 테스트할 수 있도록 도와준다.

• 뷰와 모델 간의 중개자 역할을 수행하는 뷰 모델을 제공
  -> 뷰와 모델의 변경이 발생해도 뷰 모델만 업데이트하면 되기 때문에 애플리케이션을 유연하게 변경할 수 있다.

  ViewModel은 View와 Model 사이에서 매개체 역할
  UI와 비즈니스 로직을 분리하는 데에 중요한 역할

• 뷰와 모델을 분리하여 코드의 재사용성을 높인다
  -> 모델은 다른 뷰와 함께 사용될 수 있으며, 뷰 모델은 다른 뷰에서도 재사용될 수 있다

MVVM 아키텍처 패턴의 단점

• 다른 패턴에 비해 복잡한 구조
  -> 데이터 바인딩과 RxJava 같은 추가적인 라이브러리를 이해해야 하기 때문에 어렵다

• 뷰 모델이 과도하게 커질 수 있다
  -> 뷰 모델은 뷰와 모델 사이의 중개자 역할을 하기 때문에, 뷰 모델에 많은 로직이 집중될 수 있습니다

• 양방향 데이터 바인딩이 남용될 수 있다
  -> 데이터 바인딩은 뷰와 뷰 모델 간의 데이터 흐름을 관리하는 데 사용된다. 그러나 양방향 데이터 바인딩이 남용되면, 앱의 복잡성이 증가할 수 있다

  남용?

  복잡한 비즈니스 로직이 포함된 경우
  양방향 데이터 바인딩은 데이터가 변경될 때 즉시 UI에 반영된다.
  -> 비즈니스 로직이 복잡하고 데이터가 많은 경우 이를 모두 반영하려면 많은 양의 데이터 바인딩이 필요할 수 있습니다
  이전 값과 새 값이 계속해서 변경되고 UI에 반영될 때마다 메모리가 누적(메모리 누수를 발생시키고 앱의 성능을 저하)

  주관적인 ChatGpt의 답변입니다