아키텍쳐 패턴
어떠한 제한을 걸어 오류가 발샐할 수 있는 부분을 줄이는 것!
여기서 중요한 것은 적젉한 제한을 걸어 생산성, 가독성을 높이고 버그유발을 줄이는 것
최근 모자일에서의 전쟁은 조그마한 기기에서 제한된 리소스를 적잘하게 활용할 수 있도록 하는 것이다!
MVP 아키텍쳐
모델, 뷰, 프레센터로 이루어진 아키텍쳐이다
- 모델 : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
- 뷰 : 사용자에게 보여지는 UI 부분
- 프레센터 : 뷰에서 요청한 정보를 모델이 가공하여 뷰에게 전달하는 부분
즉 Presneter 는 Back에서 내려주는 데이터를 정리하여 View에게 전달하는 것이다.
여기서 중요한 부분은 View는 Presenter를 인지하고 Presenter또한 View를 인지한다는 것이다.
또한 2가지는 서로 1:1매칭이 된다는 것이다.(재활용성도 매우 떨이짐)
여기서 문제가 발생하는데 바로 Memory leak 이 발생할 수 있다.
사용안하는 객체, 메모리가 누적되어 메모리가 터지는 현상
그렇다멘 Memory leak 이 발생하는 원인은 무엇일까?🤔 !!순환참조!!
처음에는 순환참조가 뭐지... 했지만 멘토님의 설명을 통해 알 수 있었다.
순환참조는 a가 b를 생성하고 b가 a를 생성하는 즉 서로가 서로를 바라보는 상황에서 발생할 수 있다.
해당 경우 필요에 따라 참조를 끊어야 하지만 해당 과정을 생략할 경우 메모리에 남아있어 메모리 릭이 발생한다.
이를 해결하기 위해 Prenster가 View를 알지 못하게 할 필요가 있다.
(순환참조 예제 코드)
struct ContentView: View {
let presenter = MyPresenter()
var string = "Hello"
var body: some View {
VStack {
Spacer()
Button("Hello") {
presenter.provideData()
}
Spacer()
}
.onAppear {
presenter.view = self
}
}
}
class MyPresenter {
var view: ContentView!
func provideData() {
view.string = "some word"
}
}해당 문제를 해결하기 위해 Swift에서는 약한참조 즉 weak keyword를 제공한다.
MVVM
위의 MVP의 문제를 해결하기 위해 등장한 것이 바로 MVVM이다.
Memory leak의 발생을 막기위해 2가지 방법을 사용하는데
- View만 ViewModel을 알고있다.
- 옵저버 아키텍처를 사용한다. -> 옵져버 패턴을 사용해 View에 데이터를 전달한다!!(중요)
그렇다면 옵져버 패턴은??
- View가 요청을 하고 ViewModel이 요청받으면 이후 데이터가 변화되었음을 View에 전달하고 View가 다시 확인하여 데이터를 가져온다
- 1 : n 관계 -> subect(ViewModel) : Observer
그렇다면 MVVM에서는 어떻게 사용할까
- View는 ViewModel에 의해 수동적으로 움직여야 한다.
- 즉 읽기 쓰기에서 쓰기가 막혀있어야 한다.- 캡슐화와 관련이 있음.
- View가 View에 나타날 데이터를 수정하는 것은 단일책임원칙에서 어긋난다.
싱글톤 패턴
- 가장 최신의 정보를 유지하고 어디서든 참조 할 수 있도록 하는 것
- Eager Initialization(이른 초기화)
- 가장 기본적인 유형이다- private staic 사용하여 인스턴스화 상관없이 접근 가능
- 클래스 로더에 의해 클래스 로딩시 객체 생성
- 싱글톤 객체 사용유무와 상관없이 메모리를 잡고있음
- Lazy Initialization(늦은 초기화 방식)
- 객체가 팰요시 인스턴스를 얻어 메모리 누수 방식- 멀티 쓰레드 확녕에서 동시 호출할 경우 두번 생성될 수 있다 -> 싱글톤이 깨진다
캡슐화
- 객체의 정보를 바꿔야 하는 권한이 없는 곳에서 바꿀 수 없도록 만드는 것
- 이유 없이 데이터를 바꿀 수 있다면 캡슐화를 지키지 못한것!
