Conversation
There was a problem hiding this comment.
코드 잘 읽었습니다!
제가 이해한 것이 맞나 확실하진 않지만, 제가 잘 모르는 방식으로 코드를 짠 거 같아요..! 혹시 이 방식을 선택하신 배경이나 의도가 있다면 이후에 공유해주셔도 좋을 것 같습니다.
지금 코드 구조가 계산의 핵심 로직은 CalculatorService에 있고 ViewModel은 단순히 이벤트를 전달하는 역할만 하는 것 같은데, 혹시 이런 방식으로 코드를 짜신 이유가 있으실까요?
테스트 코드 관점에서는,
Input / Output을 직접 생성하고 send를 호출하는 방식이 ViewModel의 행위를 검증하기보다는 Combine 내부 구현이 정상적으로 연결되어 있는지 테스트코드의 목적에 적합한지는 의문이 들었습니다.
꼭 뷰를 구현해야하는 건 아니지만, 현재 구조에서는 뷰모델의 책임이 다소 모호해지고 서비스가 원래 뷰모델이 해야할 일을 하고, 뷰모델은 Combine 로직을 담는 컨테이너처럼 사용되고 있는 인상을 받아 개인적으로 아쉬웠습니다..
--(여기서부터는 편지)--
개인적으로 항상 스터디 열심히 준비해와서 동기부여도 되고 항상 좋은 인상을 가지고 있었습니다!
실제로 사담은 많이 못해봤지만 누구보다 아요에 대한 열정이 강하신 분인거 같아요..
스매싱 대박나길 바랍니다 화이팅!!
| import Combine | ||
|
|
||
| class CalculatorViewModel { | ||
| struct Input { |
There was a problem hiding this comment.
갠취지만 인풋 아웃풋 패턴 프로토콜로 만들고 뷰모델에서 채택해주면 더 좋을 것 같습니당
| import Then | ||
| import SnapKit | ||
|
|
||
| class CalculatorViewController: UIViewController { |
| let displayText = CurrentValueSubject<String, Never>("0") | ||
| } | ||
|
|
||
| private let service: CalculatorServiceType // DI 적용 |
There was a problem hiding this comment.
과제의 의도를 명확하게 파악하셨군요 좋습니다
2 participants
No description provided.