Skip to content

Conversation

@Rudy-009
Copy link
Collaborator

No description provided.

Copy link
Collaborator

@Yeonnies Yeonnies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

코드 잘 읽었습니다!
제가 이해한 것이 맞나 확실하진 않지만, 제가 잘 모르는 방식으로 코드를 짠 거 같아요..! 혹시 이 방식을 선택하신 배경이나 의도가 있다면 이후에 공유해주셔도 좋을 것 같습니다.

지금 코드 구조가 계산의 핵심 로직은 CalculatorService에 있고 ViewModel은 단순히 이벤트를 전달하는 역할만 하는 것 같은데, 혹시 이런 방식으로 코드를 짜신 이유가 있으실까요?

테스트 코드 관점에서는,
Input / Output을 직접 생성하고 send를 호출하는 방식이 ViewModel의 행위를 검증하기보다는 Combine 내부 구현이 정상적으로 연결되어 있는지 테스트코드의 목적에 적합한지는 의문이 들었습니다.

꼭 뷰를 구현해야하는 건 아니지만, 현재 구조에서는 뷰모델의 책임이 다소 모호해지고 서비스가 원래 뷰모델이 해야할 일을 하고, 뷰모델은 Combine 로직을 담는 컨테이너처럼 사용되고 있는 인상을 받아 개인적으로 아쉬웠습니다..

--(여기서부터는 편지)--
개인적으로 항상 스터디 열심히 준비해와서 동기부여도 되고 항상 좋은 인상을 가지고 있었습니다!
실제로 사담은 많이 못해봤지만 누구보다 아요에 대한 열정이 강하신 분인거 같아요..
스매싱 대박나길 바랍니다 화이팅!!

import Combine

class CalculatorViewModel {
struct Input {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

갠취지만 인풋 아웃풋 패턴 프로토콜로 만들고 뷰모델에서 채택해주면 더 좋을 것 같습니당

import Then
import SnapKit

class CalculatorViewController: UIViewController {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

뷰는 안구현 하신건가요..?

let displayText = CurrentValueSubject<String, Never>("0")
}

private let service: CalculatorServiceType // DI 적용
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

과제의 의도를 명확하게 파악하셨군요 좋습니다

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants