iOS앱 개발🍎: 의미 있는 데이터 모델3

을 본 iOS 개발자는 이렇게 생각할 수 있습니다. 페이스북에서 사용하는 피드를 모델링한 Feed 모델을 API 모듈에서 사용하는 모델과 Persistence 모듈에서 사용하는 모델로 분리하는 대신, Feed 모델을 몇 가지 속성을 가지는 Protocol로 만들고 각각의 모듈에서 모델에 대한 extension을 만드는 접근 방식은 어떨까? 이 방식의 단점이 있다면 무엇일까? 💡 당연히 Feed 모델을 Protocol로 만들 수 있습니다. 하지만, Feed 모델은 불변 데이터입니다. 상태만 존재할 뿐이지 동작이 없습니다. 따라서 Protocol은 getter만 노출합니다. 게다가 Protocol로 만들어도 많은 모듈이 여전히 Feed Protocol에 의존하기 때문에 높은 결합도의 문제를 해결할 수 없습니다. 따라서 Protocol을 변경하면 여러 모듈이 손상될 수 있습니다. 데이터를 표현할 때는 Protocol보다는 Struct를 사용하는 것이 좋습니다. 가장 큰 단점은 Struct를 사용함으로써 얻을 수 있는 장점을 잃게 된다는 것입니다. 예를 들어, Feed Protocol을 구현하는 Class가 있습니다. Class는 변경할 수 있는 공유 상태를 가진 참조 타입입니다. 참조 타입의 변경 가능성은 복잡성을 유발하고 코드를 예측하기 어렵게 만듭니다. 변경할 수 있는 공유 상태는 스레딩 문제도 일으킵니다. 따라서 시스템을 개발, 테스트 및 유지 관리하기가 더 어려워질 수 있습니다. 이것이 바로 데이터 모델을 표현할 때 구조를 권장하는 이유입니다. ✅