hyeffie / juice-maker-ios Goto Github PK

지금까지 템플릿으로 제공되었던 main 스토리보드 파일을 활용해 구현을 하고 있었다.

Main 안에 화면에 view가 추가되어 있고, 해당 view controller 인스턴스를 생성할 때는

1. 스토리보드 파일에서 해당 scene의 storyboard identifier를 view controller 타입 이름과 동일한 리터럴로 설정해주고
2. UIStoryboard의 instantiateViewController(identifier:creator:) API에 �위에서 설정한 identifier와 같은 값을 전달하고
3. 해당 vc의 적절한 이니셜라이저를 creator 에서 활용하는 방식으로 구현했다.

이때 vc 타입의 이름을 하드 코딩하는 방식이 적절하지 않다고 생각해서 StoryboardIdentifiable 프로토콜과 기본 구현을 만들어서 타입으로 접근할 수 있도록 했다.
그런데 여전히 스토리보드를 사용함에 있어서 crash 발생 가능성은 존재했고, 리뷰어한테 이 부분에 대해 조언을 구했다.

리뷰어는 다음과 같은 조언을 해주셨다.

결과적으로 API 내부적으로 발생하는 에러를 막는다기 보다는.. 구현으로서 위험을 최대한 방지하는 쪽의 구현을 추천해주신 것 같다.

암튼 최대한 에러를 프로젝트 시스템적으로 막을 수 있도록 구현해보자.

실질적인 문제는
커스텀으로 초기화할 수 밖에 없는데 이게 init 에서 안 된다는 것이다.
왜 안되냐면 ...
// TBD

• StoryboardIdentifiable
• StoryboardBased
• static custom init 구현
• app delegate 구현 보완

• Fruits enum
• 각 과일 재고 (Hashable) 타입 또는 딕셔너리 typaliase
• FruitStore
• JuiceFlavor enum (recipe)
• JuiceMaker

과일을 store에서 제거하고나면 끝인 프로세스. 리턴하거나 리턴 받는 과일들을 전달하지는 않는 것 같다.

1. presening vc에 presented vc의 dismiss에 대한 처리를 위임하는 방식 (delegation) ✅
2. presented vc 생성할 때 closure 전달하는 방식
3. presenting vc의 viewWillAppear 구현 .... (고민해보고 사용할 것) 🧐
4. presenting vc에 UIAdaptivePresentationControllerDelegate 구현하는 방식

구현 수정 이유

• PR 코멘트 중에 JuiceMaker 로직이 논리적인 오류로 이어질 수 있다는 지적이 있는 코멘트가 있었음
  • 그럼 원본을 수정하는 게 문제가 되는 거라 구조체로 바꿔야 할 것 같다는 생각이 들었음
• JuiceMaker가 사실상 store를 사용하는 use case 라고 보이는데, value semantics가 좀 더 적절해 보였음

TODO

• struct로 바꾸고 로직 mutaing vs. 새 인스턴스 리턴 중에서 선택해서 구현 수정
• JuiceMaker 오류 로직 구현 수정

• VC outlet 연결
• model (request, response, view model)
• use case (StockDisplayer)
• converter
• displaying (vc)
• vc life cycle

요구사항 분석

StockManager scene

어떤 Use Case가 있을까

• 화면 진입시 재고 현황 표시 → StockDisplay
• stepper valueChanged 이벤트 발생하면 해당 과일 재고 레이블 업데이트 → StockModifier

기타

• navigation bar 설정
• 이전 화면 appear 전에 재고 현황 업데이트 (viewWillAppear)
• 화면 닫기 관련*?

StockModifier

use case 분석

고민 고민

• 스텝퍼 이벤트는 한 과일의 한 변경에 대한 이벤트인데?
  • 이걸로 전체를 fetch 하도록 하는 게 맞나?
  • 아니면 한 레이블씩 바꾸는 게 맞나 ✅
• 한 레이블씩 바꾼다면
  • fetch: 전체 현황을 참조해 해당 레이블만 바꾸기
  • update: 레이블을 위한 데이터를 전달해 해당 레이블을 업데이트 ✅

domain

• 과일 주스 때처럼 조건부 증감
• 안 되면 [stock에서 throw] > [store에서 throw] > [use case 에서 error 처리]
• result
  • (stock 사본)? 해당 stock만? 어쩌면 제일 적절할 수도 있겠다.
  • 아니면 store 사본? store는 클래스인데 ?

converter

• view model
  • 과일을 전달받기는 해야 할 것 같음 > 왜? 어떤 레이블 업데이트할 건지를 봐야해서
  • (과일, 개수)?
  • 아니면 호출한 과일의 개수만? Int?

display

• 전달받은 과일 정보로 해당 레이블을 찾는다… 그리고 숫자로 업데이트
• 과일이 전달되면 레이블을 찾아야 하는데 그 로직은 어떻게 할까?
  • 그냥 switch
  • 딕셔너리? (속성을 따로 두는 건 Fruit을 알아야 할텐데)

지금 EachFruitStore 로 구현되어 있는 속성을 딕셔너리로 바꿔보기

재활용할 수 있는 메서드 만들기, 라우터