코드를 작은 단위로 잘 쪼개신 것 같습니다. 이렇게 세분화하면 확장성과 유지보수 측면에서 유리할 수 있겠지만, 한편으로는 코드가 다소 복잡해질 수 있다는 생각도 듭니다.
코드를 잘게 쪼갤수록 유지보수는 유리하지만, 가독성이 떨어진다는 단점 또한 생기게 됩니다. 저는 아직 이러한 균형 잡기가 어려운데 혹시 이에 대해서 어떤 생각을 가지고 계신지 궁금합니다.
코드를 작은 단위로 잘 쪼개신 것 같습니다. 이렇게 세분화하면 확장성과 유지보수 측면에서 유리할 수 있겠지만, 한편으로는 코드가 다소 복잡해질 수 있다는 생각도 듭니다.
코드를 잘게 쪼갤수록 유지보수는 유리하지만, 가독성이 떨어진다는 단점 또한 생기게 됩니다. 저는 아직 이러한 균형 잡기가 어려운데 혹시 이에 대해서 어떤 생각을 가지고 계신지 궁금합니다.
입력을 안내하는 가이드 메시지의 경우에는 InputView가 담당해도 괜찮을 것 같아 이렇게 진행했습니다!
그렇지만, 피드백 주신것처럼 OutputView가 콘솔에 출력하는 책임을 담당하도록 `printMessage()` 같은
메서드를 만들어서 사용하는 것도 괜찮을 것 같아요!
감사합니다 👍
생각을 잘 정리해주신거 같아서 밑에 남깁니다.
이와 같이 간단한 도메인 에서는 getter 를 써도 문제가 없습니다.
하지만 getter 를 사용하면, 코드의 중복이 발생하게 됩니다.
예시로, 여기서 더하기 말고, 빼기를 하는 기능 요구사항이 추가되면 어떻게 될까요?
더하기 하는 부분도 구분자를 `getDelimiters` 로 받고, 빼...
지금은 되게 어려운 리뷰일 수 있으나
요구 사항을 모르는 사람이 봐도 대략적으로 알 수 있게 좋은 코드를 작성하도록 하는걸 추천합니다.
이는, 객체 지향적으로 할 수 있다면 매우 좋겠지만 어렵다면 함수로 부터 분리하는 걸 추천합니다. 함수로 잘 분리한 후, 이걸 객체가 역할을 가지게 할 수 없을까? 부터가 객체지향의 시작점인 거 같아요. 🙂
안녕하세요 6기 코레아 팀의 조이썬 입니다.
코드 잘봤습니다 🙂 중간 중간 신경 쓴 부분들이 잘 보인거 같습니다.
현재, MVC 패턴(?) 을 도입하려고 한 거 같은데
Controller - Service 가 조금 더 역할을 가져도 좋을거 같습니다!
추가로, 객체지향적인 관점을 가지려고 노력해도 괜찮을 거 같습니다.
현재는, 서비스가 모든...
안녕하세요 6기 코레아 팀의 조이썬 입니다.
코드 잘봤습니다 🙂 중간 중간 신경 쓴 부분들이 잘 보인거 같습니다.
현재, MVC 패턴(?) 을 도입하려고 한 거 같은데
Controller - Service 가 조금 더 역할을 가져도 좋을거 같습니다!
추가로, 객체지향적인 관점을 가지려고 노력해도 괜찮을 거 같습니다.
현재는, 서비스가 모든...
mvc 패턴에서 콘트롤러가 view의 요청을 받아서 service 나 repository와 메시지를 주고 받는 것을 생각해보면 view 클래스와 의존관계를 설정하는 건 어떨까요? input view -> controller (과정 생략) -> outputview 요청과 반환이 일어나니까요.