---
# System prepended metadata

title: Untitled

---

- [그라운드 룰](https://amusing-syzygy-b9c.notion.site/Week7-8-cb736fce3d7a42f889d49376b7f13194)
## 작업 목록
- [x] 제품 상세 화면 구현
- [x] Pay 화면 UI 구성
- [x] CoreData에 나만의 메뉴 저장 완료 


## 실행 화면
![Oct-19-2021 21-56-27](https://user-images.githubusercontent.com/40790219/137913843-b844a96f-6dd8-4715-bd53-9b59883212ea.gif)


## 고민과 해결
나만의 메뉴를 위한 Persistant 저장소로 기존에 사용하던 UserDefaults가 아닌 CoreData를 사용해보았습니다.
상세 주문 화면에서 보여지는 정보 그대로를 나만의 메뉴에서도 보여주어야 했기 때문에 UserDefaults 보다는 CoreData에 담아두는 구조가 더욱 좋아보였습니다. 

## 리뷰 포인트와 질문거리
### **NotificationCenter를 통한 Notification을 자주 보내도 괜찮은가요?**
> BarcodeView.swift, line: 161

![](https://i.imgur.com/0cvoQaP.png)
제한 시간을 나타내기 위해 Timer를 사용하였습니다.
이 때 뷰와 Timer를 분리하고 Timer의 재사용성을 높이기 위해 서로를 분리하였는데, Timer의 동작을 UI로 업데이트 하기위해 UILabel을 주입하는 방법과 Notification을 이용하는 방법 중 결국 Notification을 사용하기로 하였습니다.
우려되는 것은 Notification이 너무 자주 발생하지 않는 것인가? 하는 걱정이 있는데 이렇게 잦은 Notification을 발생해도 괜찮을까요?

---

### **UseCase와 ViewModel에 중복된 데이터는 어떻게 처리할까요?**

DetailViewController의 예시입니다. 

    1. viewDidLoad() 에서 DetailViewModel을 생성합니다.
    2. DetailViewModel의 fetchData() 와 fetchImage()를 실행시킵니다.
    3. fetchData()는 useCase의 fetchMenuDetail()을 실행시킵니다.
    4. useCase에 fetchMenuDetail()은 networkManager에 get요청을 보내고 get요청의 결과를 제공해주는 Publisher를 return합니다.
    5. return된 Publisher를 viewModel에서 @Published 객체에 값을 넣습니다.
    6. view는 bind되어있는 @Published 객체가 업데이트되면 업데이트합니다.

다음과 같은 구조로 되어있는데 useCase에서 repository에서 단순히 값을 꺼내기만 (MainScreen, MenuList 등등) 해도 되었을 땐 ViewModel의 @Publisher에 값을 저장하여 사용하는 방식을 이용하였습니다.

하지만 DetailViewController에서 CoreData에 값을 저장해야하는 요구사항을 해결하기 위해 UseCase 또한 값을 저장하도록 구현하였습니다. 하지만 이 값은 ViewModel에 있는 값과 똑같은 값을 사용하게 되어 궁금한 점이 생겼습니다.
1. 저장해야하는 값으로 UseCase의 Property를 사용하는 것이 아니라 ViewModel의 Property를 매개변수로 받아서 사용하는 쪽이 더 나은 구조일까요?
2. 반대로 UseCase가 값을 저장하고 있고, ViewModel은 View -> databind -> ViewModel 구조처럼 ViewModel -> databind -> UseCase 된 구조로 설계하여 ViewModel이 값을 저장하지 않고 flow를 전달해주는 역할만 하는게 더 좋을까요?


## 지난 리뷰에 대한 응답
**객체 내부의 변수의 self. 키워드 이용**

- self 수정 
    1. 리뷰어님 말대로 클로저에서 캡쳐된 객체의 self와 혼동될 여지가 충분히 있다고 생각하였습니다. 
    2. 저희는 self를 명시적으로 class property인지 나타내기 위해서 모두 붙여썼고 self를 써야한다고 주장하는 글들을 보면 clarity를 강조하고 있습니다.
    3. 하지만 clarity를 위해서라면 변수명을 명확하게 하고, 객체와 함수를 잘 구현하는 편이 더 낫다는 의견에 동의를 하게 되었습니다.
