5. ViewModel Class? or Struct?
MVVM에서 가장 중요시 되는 ViewModel에 대해서 이야기를 해볼까 합니다.
MVVM자체가 개념만 있는 상황이다 보니 각 단체에 따라서 ViewModel을 구성하는 방법이 다릅니다.
이 와중에 가장 첫번째로 대두 되는 고민은 ViewModel은 Struct이냐? Class?이냐 일거 같아요.
그럼 어떤것이 더 ViewModel에 어울리냐에 먼저 Struct와 Class가 어떻게 다른지 간략하게 짚어보고 넘어가겠습니다.
5-1.Struct vs Class
애플 개발자들 사이에 "Struct가 Class보다 더 좋다!"라는 이야기가 가끔 나옵니다.
그 이유는 애플 공식 문서에 보면 다음과 같은 말이 나오기 때문입니다.
번역하면 "기본적으로 Struct를 써라"정도 입니다.
그리고 이에 대한 이류를 바로 밑에서 설명해줍니다.
이유를 보시면 Struct는 value type이기 때문에 지역적 변경(local changes)이 앱 전반에 걸쳐 영향을 끼치지 않고, 결과적으로
보이지 않게 접근(tangentially)되어 있는 함수가 변경되는 것 보다, 어느 한 섹션의 대한 객체 변경은 명시적으로 그 섹션에서만 변화를 일으킨다는 자신감을 가질수 있기 때문이다.
쉽게 설명하자면 Struct는 값이 복사되어 넘겨지기 때문에 Class A() 에서 struct S를 Class B()로 넘겨준 경우
만약 S가 class였다면 참조 타입 이었기 때문에 B에서 S에 대한 정보를 조작하면 A도 영향을 받지만, S가 struct라 B에서 S에 대한 정보를 변경하더라도 A는 영향 받지 않는다는 것입니다.
그러면 Class 어떤 상황에서 쓰라고 권장할까요.
바로 다음과 같은 상황입니다.
- Use classes when you need Objective-C interoperability
- use classes when you need to control the identity of the data you're modeling
한국어로 번역하자면 다음과 같습니다.
- 옵젝C와 상호작용을 할 경우
- 동일성이 보장되어야 할 경우
옵젝C와 상호작용을 하기 위해선 왜 Class여만 할까요? 이유는 다음과 같습니다.
이유는 간단합니다. Objective-C framework의 경우 많은 경우가 Class로 이루어져 있기 때문이라네요.
물론 Objective-C에도 struct가 존재하긴 합니다만, ARC가 도입된 이후로 struct안에 class 선언이 안된다고 하네요.
Swift에 비해 약간 실용 범위가 떨어지긴 하는 것 같습니다.
그리고 두번째 이유는 동일성이 보장되어야 할 경우입니다.
동일성이 보장되어 서로 다른 두 개의 객체가 같은 값을 가지고 있을지라도 === 연산자로 인하여 다른것으로 취급된다.
그리고 또한 한 객체(x)를 앱 전반적으로 공유하고 있으면 x를 변경하는 순간 x를 참조하고 있는 모든 곳에서 변경사항이 일어난다.
이렇게 애플에서 소개한 Struct 와 Class의 차이점을 보았습니다.
5-2. 결국 결론은?
결론은 결국에는 팀바팀이다라고 밖에 말씀을 못 드리겠네요.
하지만 제 기준으로는 class가 오히려 조금더 안전할 수 있지 않나 생각합니다.
흔히들 struct를 사용하면 memoryleak로부터 안전하다고 생각할 수 있는데 이는 struct안에 value-type만 있을때의 이야기입니다.
또한 struct는 따로 deinit()이라는 함수가 없어 제대로 메모리가 릴리즈 됬는지 파악할 수 없습니다.
또 struct는 상속을 할려면 protocol을 사용해야만 하는 제약사항이 있습니다.
따라서 저는 ViewModel을 주로 class로 작성하는 편이고, Cell이나 이런 SubView에는 별다른 로직이 들어있지 않을때 struct로
하는 편입니다.
'iOS' 카테고리의 다른 글
Tuist(2) - 기존 프로젝트에 도입하기 (0) | 2023.02.13 |
---|---|
TUIST(1) - 설치,실행,기본구조 (0) | 2023.02.12 |
MVVM(5) - Coordinator (0) | 2023.01.05 |
MVVM(4) - Coordinator (0) | 2022.12.27 |
MVVM(3) - Coordinator (0) | 2022.12.23 |