Design Pattern

Design Pattern?

---

특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이고, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿으로 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.

→ 정해진 형식을 따를 필요는 없지만(필수는 아님) Design Pattern 형식에 맞게 구성하면 쉽게 형식에 짜여져 있어 프로그래밍 가이드라인이라 생각하면 쉽다.

출처 : https://ko.wikipedia.org/wiki/소프트웨어_디자인_패턴

 

디자인 패턴의 가장 큰 목적 >>>> 유닛 테스트 <<<<

깔끔한 코드 분리 보다는, UI 와 분리하여 기능을 테스트 하는데 있어 독립적으로 실행하기 위해 나누는것이 디자인 패턴의 가장 큰 목적이다.

1. MVC (Model-View-Controller)

---

• MVC는 Model, View, Controller로 이루어져있다.View : 앱의 데이터를 보여주는 방식(UI)을 정의앱의 사용자로부터 입력에 대한 응답으로 모델/뷰를 업데이트하는 로직을 포함
• Controller : 간단하게 이벤트들을 처리하는 부분을 뜻함(모델과 뷰의 중개자)
• Model : 앱이 포함해야할 데이터가 무엇인지 정의
• MVC의 장점
  → 비즈니스 처리 로직과 사용자 인터페이스 요소들을 분리시켜 영향없이 개발하기 수월하다.
• MVC의 단점
  → Model과 View가 서로 의존성을 띄게됨→ 큰 규모의 앱이라면 Controller가 지나치게 무거워 질 수 있음
• ※ 새 기능을 추가할때마다 소스분석과 테스트가 어려워짐
  →화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있다.

출처)  https://medium.com/@jang.wangsu/디자인패턴-mvc-패턴이란-1d74fac6e256

 

I. general MVC Pattern

---

1. View는 'add to cart'라는 버튼을 보여주고 user가 버튼을 클릭한다.
2. 처리된 이벤트를(추가된 데이터를) Model에 반영한다.
3. Update후 View에 보여준다.

https://blog.kakaocdn.net/dna/G9SCW/btqAICyaZjD/AAAAAAAAAAAAAAAAAAAAALl28l9zJ0V9kGVX7QHPzd6CAfyFQJmjc3_6aM_UUQHf/img.jpg?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1772290799&allow_ip=&allow_referer=&signature=1LRXFUAjhYLF7gJDc3ul8Jx0ofg%3D

1. 사용자의 요청은 Controller가 받는다.
2. 받은 요청을 처리하기 위해 Model에게 정보를 요청한다.
3. 정보에 대한 응답을 Controller에게 넘겨준다.
4. Controller는 View에게 Model의 정보를 넘겨주어 사용자에게 데이터를 표시해준다.

II. iOS MVC Pattern

---

https://velog.io/@zooneon/iOS-MVC-패턴에-대해-알아보자

iOS의 MVC패턴은 View와 Controller가 밀접하게 연결되어있다.

UIView와 UIViewController은 서로의 LifeCycle까지 관여하기 때문에 분리하기가 어렵다. (실질적으로 UIView는 아무것도 하지 않음)따라서 Controller는 비대해 질 수 밖에 없고 비대해진다면 유지보수가 힘들어진다.

주의사항

---

MVC Pattern을 찾아보면서 참고하면 좋을 사항들

1. Model
   1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
   2. 뷰나 컨트롤러에 대해 어떤 정보도 알지 말아야 한다.
   3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야 한다.
2. View
   1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
   2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다.
   3. 변경이 일어날 시 변경 통지에 대한 처리방법을 구현해야 한다.
3. Controller
   1. 모델과 뷰에 대해 알고 있어야 한다.
   2. 모델이나 뷰의 변경을 모니터링 해야 한다.

출처) https://m.blog.naver.com/jhc9639/220967034588

2. MVP (Model-View-Presenter)

---

 

MVC 패턴에서 파생된 패턴

 

MVC패턴에서 Controller대신 Presenter를 도입했는데(MVP 패턴이 나온 이유),

→ MVC패턴에서 View와 Model은 상호의존적인 특징 때문 완전한 분리를 위한 Present를 도입

Presenter는 View에서 요청한 정보로 Model을 가공해 View에게 전달해주는 역할을 한다.

iOS에서의 Model과 View는 밀접하게 연관이 되어있지만 MVP패턴의 경우에는 UIViewController LifeCycle에 관여하지 않는다.

1. Model : MVP에서는 View와 Model의 분리를 위한 디자인 패턴으로 Model은 View와 Presenter에 의존하지 않은 독립적인 영역이다
2. View :

• View 에서 발생하는 이벤트는 직접 핸들링 할 수 있으나 Presenter 에 위임하도록 한다
  → 이렇게 하면 특정 뷰와 결합되지 않고 가상 뷰를 구현해서 간단한 유닛 테스트를 실행할 수 있음
• Presenter로 View와 독립하여 Model의 정보를 가공하여 View에게 넘겨주기 때문에 독립성을 유지할 수 있다.
• 하지만 View는 Presenter와 1:1관계를 유지하면서 Presenter의 의존성 문제가 생긴다.
• MVC의 경우에는 Controller가 UIViewController의 기능을 수행해 소스가 비대해 지지만
  → 위임하는 방법은 액티비티가 뷰 인터페이스를 구현해서 Presenter에서 코드를 만들 인터페이스를 갖도록 하면 됨

1. Presenter :

• Model과 View 사이의 매개채
• Model의 로직으로부터 나온 결과를 전달받아서 View에 보내 UI변경
  ⭐본질적으로는 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 인터페이스로 연결된다는 점이 다름⭐
  ⇒ MVC와의 가장 큰 차이점
  ⇒ 따라서 View는 Presenter안에서 인터페이스로 연결되므로 Presenter의 의존성이 높음
• 이에 따라 MVC가 가진 테스트 가능성 문제와 함께 모듈화/유연성 문제 역시 해결할 수 있음
• 프리젠터(Presenter)의 역할을 한줄로 표현한다면 뷰(View)와 모델(Model) 사이에서 자료 전달 역할을 함

예시)https://aspdotnet.tistory.com/1111

참고자료 : https://nightohl.tistory.com/entry/iOS-아키텍처-패턴-MVP

https://beomseok95.tistory.com/212

c# MVP Pattern Example)https://www.technical-recipes.com/2015/the-model-view-presenter-pattern-in-c-a-minimalist-implementation/

3. MVVM (Model-View Model-View)

---

View는 ViewModel을 subscribe(구독)하고 observe(관찰) 한다. (반대x)

Model의 데이터가 변경이 있다면 ViewModel에 알린다.

ViewModel-View는 Data Binding이 되어있기 때문에 View에서는 발표(publish)하기만 하면 된다.

장점

MVC 패턴의 View와 Model의 독립성을 유지하고, 테스트 또한 나누어 실행할 수 있어 효율적인 유닛 테스트가 가능하다.

단점

데이터 바인딩이 필수적으로 요구된다. 다양한 방법을 통해 바인딩이 가능하지만 그 작업을 위해 Boilerplate code를 짜야 한다.

출처 : https://wnstkdyu.github.io/2018/04/20/mvvmdesignpattern/

예제)https://www.youtube.com/watch?v=ak8x-p-q8tU

예제 설명)https://lena-chamna.netlify.app/post/ios_design_pattern_mvvm/

https://42kchoi.tistory.com/292

 

Data Binding

Data Binding은 View와 ViewModel의 사이를 연결해 데이터 변경을 알려주는 방법이다.

 

MVVM vs MVP

MVP는 View와 Presenter이 1:1로 연결되어야한다는 특징이있음

→ A View와 유사한 B View를 구현했을 경우 하나의 Presenter에만 연결이 가능하므로

A Presenter과 B Presenter을 구현해야함

MVVM패턴에서는 ViewModel은 View를 전혀 모르는 구조이므로 1:1뿐 아니라 다:다 관계도 가능함

※ MVVM은 중복 로직을 줄이고 결합도를 낮출 수 있음

 

4. Singleton Pattern

---

특정 클래스의 인스턴스에 접근 시 항상 동일한 인스턴스만을 반환하도록 하는 패턴

특정 클래스 값을 여러 클래스에서 공유하거나 하나씩 순서대로 처리 할때 주로 사용된다.

Singleton은 static을 사용하여 클래스 생성을 선언한다.

 

클래스에서 static let으로 생성된 클래스 인스턴스는 struct와 다르게 값이 아닌 주소를 전달하기 때문에 오직 하나의 인스턴스만 존재하고, 따라서 이 특성 때문에 값을 변경했을 경우 다른쪽에서 호출했을 때 변경된 값이 적용된다.

 

예제코드)

class Singleton {
    static let shared = Singleton()
    
    fileprivate init() {  }
    func isSingletonFunction(){ }
}

// 정적 요소 사용시
ClassName.shared.somevaliable
ClassName.shared.isSingletonFunction()

출처) https://woongsios.tistory.com/2