뿌대식: 응답 모델 개선

개선 전

 

기존 프로젝트의 모델들(식당, 기숙사, 네트워크 응답, …)은 처음 모델을 생성한 의도와 다르게 필요에 따라 메서드가 하나씩 추가되었고, 메서드 간 종속성이 강하게 묶여있어 하나의 메서드를 수정하면 연관되는 모든 메서드를 수정했어야 했습니다.

 

그리고, 학생 식당과 기숙사의 응답 형식이 달라 각 응답을 보여주는 뷰가 2개 존재했습니다.

 

개선 목표는 학생 식당과 기숙사의 응답을 하나로 합치고, 뷰 또한 하나의 구조체로 표현하고자 했습니다.

추가로, 필요에 따라 추가한 메서드들(예를 들어, static으로 선언된 rawValue를 통해 캠퍼스를 반환하는 메서드)을 재사용 가능하게 수정하는 것이었습니다.

 

 

개선 후

 

 

의도 결과를 설명하기 전, 오랜만에 열어본 프로젝트는 한눈에 보기 힘들 정도로 로직이 엉켜있었습니다.

 

예를 들어, 메인 뷰가 onAppear 되는 시점에 필요한 설정 메서드들을 수행하도록 되어 있었습니다.

고민해 본 결과 뷰 요소들에 필요한 데이터이긴 하지만 굳이 메인 뷰에서 수행할 필요가 없다고 생각했고 해당 설정 메서드들을 메인 뷰 모델이 init 되는 시점으로 이동했습니다.

 

모델은 기숙사 모델(Domitory), 학생 식당 모델(Restaurant)이 존재하던 걸 통합 식당 모델(Integrated Cafeteria)을 생성한 뒤 두 모델에서 공통으로 사용하는 멤버를 추가한 후, 각 모델의 init을 정의해 구현을 마친 뒤 기존 모델과 교체하였습니다.

(지금 보니까 기숙사 철자도 틀렸네요.)

 

개선 전 모델

/// 기숙사 enum
enum Domitory: Int, CaseIterable, Hashable, Codable { ... }
/// 식당 enum
enum Restaurant: String, CaseIterable, Hashable, Codable { ... }

/// 기숙사 데이터베이스 응답
struct DomitoryResponse: Codable, Serializable { ... }
/// 학생 식당 데이터베이스 응답
struct RestaurantResponse: Codable, Hashable, Serializable { ... }

// MainView.swift
...
/// 식당 식단 뷰
private struct RestaurantMenuView: View { ... } 
/// 기숙사 식단 뷰
private struct DomitoryMenuView: View { ... }

 

 

개선 후 모델

/// 기숙사, 식당 통합한 enum
enum Cafeteria: Codable, CaseIterable { ... }

/// 기숙사, 학생 식당 응답
struct CafeteriaResponse: Serializable { ... }

/// 식단 뷰
private struct MenuView: View { ... }

 

 

요약

각각 호출하고, 각각 표현하던 식단 데이터에 대한 로직을 하나의 구조로 표현할 수 있도록 개선했습니다.

(기숙사와 식단은 key는 다르지만 식당 정보와 식단에 대한 동일한 데이터를 제공하며 학생 식당은 식단 명이 추가됩니다.)